<p>Static Web Hosting on the Intel N150: FreeBSD, SmartOS, NetBSD, OpenBSD and Linux Compared</p><p>Update: This post has been updated to include Docker benchmarks and a comparison of container overhead versus FreeBSD Jails and illumos Zones.</p><p><a href="https://it-notes.dragas.net/2025/11/19/static-web-hosting-intel-n150-freebsd-smartos-netbsd-openbsd-linux/" rel="nofollow" class="ellipsis" title="it-notes.dragas.net/2025/11/19/static-web-hosting-intel-n150-freebsd-smartos-netbsd-openbsd-linux/"><span class="invisible">https://</span><span class="ellipsis">it-notes.dragas.net/2025/11/19</span><span class="invisible">/static-web-hosting-intel-n150-freebsd-smartos-netbsd-openbsd-linux/</span></a></p><p><a href="/tags/itnotes/" rel="tag">#ITNotes</a> <a href="/tags/freebsd/" rel="tag">#freebsd</a> <a href="/tags/illumos/" rel="tag">#illumos</a> <a href="/tags/jail/" rel="tag">#jail</a> <a href="/tags/linux/" rel="tag">#linux</a> <a href="/tags/netbsd/" rel="tag">#netbsd</a> <a href="/tags/openbsd/" rel="tag">#openbsd</a> <a href="/tags/ownyourdata/" rel="tag">#ownyourdata</a> <a href="/tags/server/" rel="tag">#server</a> <a href="/tags/smartos/" rel="tag">#smartos</a> <a href="/tags/sysadmin/" rel="tag">#sysadmin</a> <a href="/tags/zoneshosting/" rel="tag">#zoneshosting</a></p>
Edited 137d ago
<p>This morning, I took my wife to the hospital for routine blood tests that had been scheduled for some time. Everything was going smoothly: check-in, number, waiting room. Suddenly, everything came to a halt and shut down. I was connected to the hospital’s public Wi-Fi and noticed that my connection also went down.</p><p>Having managed a couple of similar facilities, I immediately understood what had happened. I saw the staff panicking and calling the technicians, but they quickly reorganized within 10 minutes. They managed to process everyone who already had a number and then proceeded with the others in the order of their arrival. Despite the ten-minute delay (even though people started complaining right away), they were extremely efficient.</p><p>I later confirmed that the entire booking, check-in, and queue system is “in the cloud.” The hospital experienced a connectivity interruption, and all related services stopped. The staff no longer had access to anything, so a technician sent the lists to a manager via another channel, and everything resumed manually.</p><p>For years, I’ve insisted that certain things MUST be local. The healthcare facilities I manage have all the necessary systems for the operation of the facility internally, including patient records. External services like websites, emails, etc., are secondary.</p><p>Everything essential must always be accessible locally and, in special cases, it should be possible to physically access the servers and connect directly to them, bypassing any network/switch failures.</p><p>There has been only one interruption in the past, due to human error. Today, we have redundant servers (not HA on virtualizers, but two machines running the same software with replicated databases - on separate power lines) so such an issue shouldn’t happen anymore.</p><p>Not everything can be anticipated, but history is a great teacher. The Internet connection will eventually be interrupted :-)</p><p>When it comes to the health and survival of people, there are no compromises.</p><p><a href="/tags/it/" rel="tag">#IT</a> <a href="/tags/internet/" rel="tag">#Internet</a> <a href="/tags/networking/" rel="tag">#Networking</a> <a href="/tags/outage/" rel="tag">#Outage</a> <a href="/tags/health/" rel="tag">#Health</a> <a href="/tags/ha/" rel="tag">#HA</a> <a href="/tags/cloud/" rel="tag">#Cloud</a> <a href="/tags/cloudcomputing/" rel="tag">#CloudComputing</a> <a href="/tags/ownyourdata/" rel="tag">#OwnYourData</a></p>
Edited 1y ago
Publishing a photo of approximately 4MB from my snac instance (at home with 20 Mbit/sec uplink) meant overwhelming everything.<br>This happened because, for every remote instance, Nginx was requesting the multimedia file from snac. However, due to saturated connections, it took several seconds, leading to thread exhaustion in snac.<br>I resolved this issue by caching the multimedia files myself using Nginx, which significantly improved performance.<br><br>This matter will be covered in a subsequent (simple) blog post.<br><br><a href="/tags/snac/" rel="tag">#snac</a> <a href="/tags/snac2/" rel="tag">#snac2</a> <a href="/tags/ownyourdata/" rel="tag">#OwnYourData</a> <a href="/tags/selfhosting/" rel="tag">#SelfHosting</a><br>
Updated Version of the apache http caching setup for snac, including proxy media<br><br>I already wrote about caching <a href="https://snikket.de/social/menel/p/1738788742.236526" rel="nofollow">here</a>.<br>Now I extended what I cache a bit.<br>This was because after enabling the option to <a href="https://comam.es/snac-doc/snac.8.html#proxy_media" rel="nofollow">proxy media</a>, I've seen access to the file paths /x/ and /y/ in addition to the path were snac stores the media that I include in my own posts ( /s/ ).<br>There are two locations to proxy media, depending if you requests the media via the mastodon api or via the web. (/x/ and /y/), oh and I added the nodeinfo2.0 path too, because I've noticed it was queried all the time by a lot of instances and it gives me pleasure to see something cached handed out in the access logs. 🙂 (I guess it is actually irrelevant for the system resources)<br>This is the updated setup:<br>Enable the relevant modules:<br><br>a2enmod expires cache cache_disk<br><br>Be sure "htcacheclean" is running to clean up the old disk cache. (under debian see /etc/default/apache-htcacheclean or else the relevant systemd service or whatever)<br>Then add this to the httpd Virtualhost config:<br><br><p><LocationMatch "^/social/[^/]+/[xys]/|^/social/nodeinfo_2_0"><br>CacheEnable disk<br>Header set Cache-Control "max-age=86400, public" "expr=%{REQUEST_STATUS} == 200"<br>ExpiresActive On<br>ExpiresDefault "access plus 86400 seconds"<br></LocationMatch><br></p>This will use the disk cache to cache everything under the $username/s/, /x/ and /y/ paths, as well as for the /nodeinfo_2_0 path, utilizing mod_expires to generate the appropriate cache headers (for lazy ones like me). In this case caching it for 1 day.<br>Further reading and all options are explained under <a href="https://httpd.apache.org/docs/2.4/caching.html" rel="nofollow" class="ellipsis" title="httpd.apache.org/docs/2.4/caching.html"><span class="invisible">https://</span><span class="ellipsis">httpd.apache.org/docs/2.4/cach</span><span class="invisible">ing.html</span></a> (and ff)<br><br>The Header that I set here, on the condition of Status code 200, is needed for the path /y/, because snac set no-cache on that location and mod_expires will honor that if we don't override it. I set it to the same Cache-Control value as mod_expires would. (I use mod_expires because it will additionally calculate the date and put that in the expires header. (hence the name I guess 😀 )<br><br><a href="/tags/fediverse/" rel="tag">#Fediverse</a> <a href="/tags/hosting/" rel="tag">#Hosting</a> <a href="/tags/itnotes/" rel="tag">#ITNotes</a> <a href="/tags/apache2/" rel="tag">#apache2</a> <a href="/tags/httpd/" rel="tag">#httpd</a> <a href="/tags/ownyourdata/" rel="tag">#Ownyourdata</a> <a href="/tags/server/" rel="tag">#Server</a> <a href="/tags/snac/" rel="tag">#Snac</a> <a href="/tags/snac2/" rel="tag">#Snac2</a> <a href="/tags/tipsandtricks/" rel="tag">#Tipsandtricks</a> <a href="/tags/tutorial/" rel="tag">#Tutorial</a> <a href="/tags/debian/" rel="tag">#Debian</a> <a href="/tags/caching/" rel="tag">#caching</a><br><img src="https://neodb.social/media/emoji/snikket.de/xmpp.png" class="emoji" alt=":xmpp:" title=":xmpp:"><br>
Edited 1y ago
<p>Fortunately, <span class="h-card"><a href="https://snac.nya.pub/voron" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>voron</span></a></span> 's site on snac themes still has this screenshot, which I'm happy to share. </p><p>This response from the author of snac motivated me to continue, study, and appreciate this fantastic software for the Fediverse. <br>Snac is an example of true internet democracy: it runs everywhere and allows anyone to have their own autonomous, personal space in the Fediverse. </p><p>"Don't despair or quit", says an author who cares. And the Fediverse cares about them.</p><p>For today's <a href="/tags/thankyoutuesday/" rel="tag">#ThankYouTuesday</a>, I want to thank grunfink - <span class="h-card"><a href="https://comam.es/snac/grunfink" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>grunfink</span></a></span> - for the excellent work they do, quietly and with passion. I suggest that if you think snac is a good idea and you have the means, you offer them at least a coffee.</p><p><a href="https://codeberg.org/grunfink/snac2" rel="nofollow"><span class="invisible">https://</span>codeberg.org/grunfink/snac2</a></p><p><a href="/tags/snac/" rel="tag">#snac</a> <a href="/tags/snac2/" rel="tag">#snac2</a> <a href="/tags/fediverse/" rel="tag">#Fediverse</a> <a href="/tags/ownyourdata/" rel="tag">#OwnYourData</a></p>
Edited 222d ago
Under the hood update!<br><br>I’ve finally retired the old cron + sh setup for the weather bots. It served us well, but it had a major flaw: if I rebooted the server while it was posting, the job just died halfway. If the server was down during a scheduled slot, the forecast was lost forever.<br><br>So, I wrote a custom Python daemon to run inside the FreeBSD Jails.<br><br><p>It’s stateful now. If a crash happens at city 15 of 50, it resumes exactly there on reboot.</p><p>If the server naps/is rebooting during a scheduled run, the bot realizes it missed a slot and runs immediately upon waking up.</p><a href="/tags/fedimeteo/" rel="tag">#FediMeteo</a> <a href="/tags/sysadmin/" rel="tag">#SysAdmin</a> <a href="/tags/python/" rel="tag">#Python</a> <a href="/tags/freebsd/" rel="tag">#FreeBSD</a> <a href="/tags/coding/" rel="tag">#Coding</a> <a href="/tags/selfhosted/" rel="tag">#SelfHosted</a> <a href="/tags/ownyourdata/" rel="tag">#OwnYourData</a> <a href="/tags/staytuned/" rel="tag">#StayTuned</a><br>
This message is proudly delivered by an instance running on a fanless server in my basement, at an ambient temperature of 12 degrees<br><br><a href="/tags/fediverse/" rel="tag">#Fediverse</a> <a href="/tags/ownyourdata/" rel="tag">#OwnYourData</a><br>
<p>As the <span class="h-card"><a href="https://bsd.network/@bsdcan" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>bsdcan</span></a></span> lists of talks and tutorials have been posted, I can officially announce my presentation:</p><p>Don't Freeze in the Cloud: Reclaiming Home Control with NetBSD</p><p>In 2010, I was taking more flights than cups of coffee. After a two-week trip, I returned home to a nasty, albeit expected, surprise: an indoor temperature of 7.8°C (46 F). Possessing more time than money, I decided to solve the problem my own way. I built a custom Python-based control system, accessible only via VPN, to manage my heating.</p><p>In 2015, after moving houses, this system was demoted to a secondary role, replaced by a shiny, commercial "smart" thermostat. However, I continued to maintain and update my custom solution for fun.</p><p>Fast forward to October 2025: major cloud providers faced significant outages. My commercial thermostat became dumber than a mechanical switch. I was reduced to manual two-hour overrides, with no visibility into settings or usage. It was a wake-up call: keeping my home warm should not depend on someone else's server.</p><p>I dusted off my solution and adapted it to modern needs - powered, of course, by NetBSD, running on the very same hardware that served my previous home for years.</p><p>In this talk, I will share the journey, the technical challenges, and the architectural decisions behind the project. I will demonstrate how NetBSD’s stability and low footprint make it the ideal operating system for long-term, "set-and-forget" home automation, allowing us to reclaim control from the cloud.</p><p><a href="/tags/netbsd/" rel="tag">#NetBSD</a> <a href="/tags/bsdcan/" rel="tag">#BSDCan</a> <a href="/tags/bsdcan2026/" rel="tag">#BSDCan2026</a> <a href="/tags/runbsd/" rel="tag">#RunBSD</a> <a href="/tags/ownyourdata/" rel="tag">#OwnYourData</a> <a href="/tags/presentation/" rel="tag">#Presentation</a> <a href="/tags/talk/" rel="tag">#Talk</a></p>
Edited 53d ago
<p>After quite some time, I’m finally ready to share this.</p><p>MastoBlaster is now available in public testing on TestFlight.</p><p>It is a lightweight, privacy-first Fediverse client for iOS, built around a simple idea: fast, small, predictable behavior, and first-class support for snac.</p><p>What makes it different:<br>• snac-first by design, not "compatible by accident"<br>• Works with all Mastodon API compatible software, including Mastodon, snac, GoToSocial, Akkoma, and others<br>• EXIF stripping on upload (HDR and orientation preserved)<br>• Optional on-device alt text generation via Apple Intelligence for your uploads and for images in your timeline<br>• Markdown posting for snac<br>• Granular notifications, grouping, multi-account<br>• Blocking and moderation tools<br>• Very small footprint, very low RAM usage</p><p>Alt text generation happens entirely on device via Apple APIs on supported hardware. Nothing is sent to external services.</p><p>It is built around my own workflow and priorities. It may not be for everyone, and that is perfectly fine.</p><p>Important note:<br>MastoBlaster will always be free for BSD Cafe users, illumos Cafe users, and for anyone connecting to a snac instance, including self-hosted ones.</p><p>The app is already usable, but this is still a test phase. I am looking for feedback, bug reports, and real-world usage insights.</p><p>TestFlight link:<br><a href="https://testflight.apple.com/join/Pkxa5R1k" rel="nofollow" class="ellipsis" title="testflight.apple.com/join/Pkxa5R1k"><span class="invisible">https://</span><span class="ellipsis">testflight.apple.com/join/Pkxa</span><span class="invisible">5R1k</span></a></p><p>Stay tuned.</p><p><a href="/tags/mastoblaster/" rel="tag">#MastoBlaster</a> <a href="/tags/ios/" rel="tag">#iOS</a> <a href="/tags/fediverse/" rel="tag">#Fediverse</a> <a href="/tags/mastodon/" rel="tag">#Mastodon</a> <a href="/tags/snac/" rel="tag">#snac</a> <a href="/tags/snac2/" rel="tag">#snac2</a> <a href="/tags/akkoma/" rel="tag">#Akkoma</a> <a href="/tags/gotosocial/" rel="tag">#GoToSocial</a> <a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/ownyourdata/" rel="tag">#OwnYourData</a></p>
Edited 47d ago