Filip Chabik

DevOps Engineer, Husband & Dad.

Why FreeBSD? →

Vermaden writes:

When you install a Linux system its just a bunch of RPM or DEB packages. For example of you install CentOS 7.8 Minimal variant you end up with several hundred RPM packages installed. After a week or month many of these packages will get updates sometimes making this CentOS system unusable or even unbootable (recent GRUB Boothole problem for example).

“Sometimes making this CentOS system unusable or even unbootable[…]” and sometimes it simply works, updates & upgrades just fine and serves for years to come. Look, I know it’s easy to bash on Linux these days and showcase FreeBSD as a remedy to all worlds problems. You can have an awesome experience using Linux and shitty using FreeBSD or the other way around – it’s not the OSes fault how they are being used or misused. I get it, I very often wholeheartedly agree and nod my head when reading articles praising UNIX over Linux, but I do have a problem with setting these two in opposition.

The moment where you focus on comparing every single good part of FreeBSD to every single shitty part (which is very often subjective) of Linux, you are not making any favors to the former. To me it’s admitting that Linux has won (because it did) and the only way to showcase how good BSD is is to bash1 on Linux. I don’t think it’s right. I think focusing solely on the virtues FreeBSD has is good enough. Otherwise it tends to get tedious to read how something is so much better than in Linux. So what if it is? There are plenty of things done better in Linux, does it prove anything?

There are good reasons and good places to use Linux and there are good reasons and places to use FreeBSD – or any other UNIX really. SmartOS always comes to my mind whenever I think about virtualization – I don’t think there ever was an OS that solved this problem cleaner than them, PowerVM coming second place.2 Does this make bhyve worse? No, it has no impact on the quality of it. I also find Solaris Zones to be the best container solution ever made. Does it make Docker worse? Or jails for that matter? Not really.

Overall it’s a great article and source of good parts of FreeBSD (and also good reasons to use it), well worth reading 👍🏻

  1. Pun intended. 

  2. My personal opinion, don’t at me. 

FreeBSD Virtual Data Centre with Potluck: DevOps & Infrastructure as Code →

Honeyguide sums up:

Yes, FreeBSD Lacks Kubernetes - But It Does Not Really Matter…

I like that approach. Recently I switched over from dedicated server running in Hetzner to a self-hosted, FreeBSD powered NUC.1 I can’t see going back to anything else than that at this point. Running BSD server on daily basis brought back so much sanity (and, sincerely, loads of joy) to my life and “SysAdmining” that I find it harder to do things differently.

Here’s a great series of posts showcasing how FreeBSD is still relevant in modern day and age, not shying away from running latest and greatest software in the industry. The components, among other, list Nomad, which I had on my radar for quite some time, Consul, which I love and Traefik, which I tolerate.2

Sure, it lacks Docker & Kubernetes. But it honestly doesn’t matter.

  1. NUC7i3BNK to be exact. 

  2. But still prefer NGINX. 

How we migrated Dropbox from Nginx to Envoy →

Here’s yet another wonderful technical deep dive from the Dropbox team. Setting apart their recent drama in the Apple world and failure after failure in trying to find something more to offer than “just” the basic syncing feature, their sheer scale and infrastructure related topics are always interesting to me. No doubts the shortcomings are not part of the engineering team as their syncing function is still number one in the industry. Here I learned few more things about their infra, NGINX + lua setup and migration to Envoy. It’s a long read but well written and very rewarding.

NGINX Extended 1.18 update

24th July 2020

I realized that I did status updates for security fixes in NGINX Extended… 1.14 (sic!). The thing is that in the meantime the entire stable 1.16 went through and here we are now, 1.18 is ready. I did communicate subsequent releases on Twitter, but there were a few changes that deserve at least a small blogpost.

First, not only Ubuntu LTS are now supported. Interim releases will receive builds too, but they will stay in the given version when that release reaches EOL. Here’s a good looking chart on when that might be: The Ubuntu lifecycle and release cadence. For now Xenial is the only affected release.

Second, there are now mainline builds available. Should you need to use them or for testing purposes, here’s how to add the relevant PPA:

sudo add-apt-repository ppa:hadret/nginx-mainline
sudo apt-get update

At this moment it equals the stable branch, but the new 1.19 NGINX releases are coming early next month.

Finally, I backported ModSecurity 3.01 to Bionic (18.04) and NGINX Extended incorporates official SpiderLabs ModSecurity-nginx module. Be sure to give it a try!

Last time I made plans for “what’s next?”. Xenial did stop at 1.14, pagespeed was dropped (it was too much of a hassle to maintain it), ldap and upsync stayed where they are and brotli support has been introduced.

This time around I’m planning on modernizing my build environment a little bit and pushing few Extended changes towards Debian directly.2 Let’s see what the future holds.

  1. v3.0.4 to be exact. 

  2. VTS should be a standard these days.