I’ve been following 13.0 starting around the same time last year. It was my coming back to FreeBSD after few years break. I instantly felt at home with it and I also wanted to use all the things “my way”. I customized /etc/make.conf and /etc/src.conf, I switched to git repositories whenever they were available etc. All the fun stuff. FreeBSD behaved on my NUC rock solid all the time – I did bring some rain onto myself (you can’t avoid it when you mess around with bleeding edge), but never to a degree that wouldn’t be recoverable (thank goodness for bectl) this way or another. At some point this year I started preparing for this release and was going more and more towards defaults and eventually I switched back to freebsd-update and portsnap. Being able to do these things without a hitch is a testament of how good of operating system FreeBSD is. Now go try it out!

Jim Salter writes on Ars Technica:

Unfortunately for Netgate, neither its sponsored code nor the week-long sprint by Donenfeld, Dunwoodie, and Evans seem likely to make it into FreeBSD 13.0. Presented with one deeply flawed port and another massively rushed overhaul, the FreeBSD team will most likely disable the WireGuard module entirely for 13.0-RELEASE and revisit for 13.1-RELEASE.

As expected, WireGuard support has been dropped in RC3 of 13.0-RELEASE. What’s even worse of not having WireGuard in is the fact that developers who tried their best to fix everything that was wrong with its implementation received… Bashing from Scott Long. It’s not the first time when Netgate’s CEO is acting like a 5 year old. I’m not linking to his “article” on the Netgate’s blog cause it’s simply not worth anybody’s time.

It is worthwhile though to have a look into this mailing list post by Jason A. Donenfeld (WireGuard’s author). Just to give you some idea:

It makes sense to communicate with your customers about things with your upcoming products if you feel it’s necessary. But threatening that you’re going to highlight “that extreme caution should be taken in any future dealings with you” sounds to me like a threat of some intense slander. And again, attacking security researchers and kernel programmers who took time to rewrite code to make it better before a release deadline… That’s …wow. I wish you would not go on the attack like that.

Wow indeed.

Daniel Morante writes on Unibia:

GlusterFS (GFS) is the open source equivalent to Microsoft’s Distributed Filesystem (DFS). It’s a service that replicates the contents of a filesystem in real time from one server to another. Clients connect to any server and changes made to a file will replicate automatically. It’s similar to something like rsync or syncthing, but much more automatic and transparent. A FreeBSD port has been available since v3.4, and (as of this post) is currently at version 8.0 with 9.0 being released soon.

Full disclosure: I never heard of DFS 🤷🏻‍♂️ When it comes to clustered systems, Microsoft definitely wouldn’t be my first choice. I did however work with AIX GPFS and also with VxFS on multiple platoforms, including Solaris and Linux. There’s also of course cLVM, its implementation on AIX via HACMP and Linux has got something too. I did play with GlusterFS in production for the first time in ~2014 – it was not great. There were many broken parts and some of the things were not really self-contained and relied on userland tools like rsync to be supported and in the right versions. But it did leap forward, eventually stabilized and became, well, to me at least, a golden standard for clustered filesystems on Linux. I’m really happy to see that there is an attempt to get it ported to FreeBSD – it seems to me that it has the potential to combine excellent ZFS baking in this OS with the distributed capabilities as a cherry on top of it.

GlusterFS on FreeBSD is not yet what I would call production quality. There are a few know bugs and performance problems that could ruin your day. The most notable is the fact that GlusterFS uses poll instead of kqueue/kevent. There is also an issue where GlusterFS is (sometimes) unable to correctly find the process ID of the self-heal daemon, causing volume heal commands to fail[…] Other annoyances include the fact that there are still some Linuxisms within the codebase and testing framework. This means GlusterFS might make some Linux specific system calls or look for certain files to be in unexpected locations.

I get it, it’s not there yet, but from the looks of it, it seems that there’s not a lot missing. I’m gonna keep my eye on and fingers crossed for this one 🤞🏻 In the meantime, the linked post is a great introduction not only to GlusterFS, but also to bhyve.

I learned about Project 365 from this post by Joe Hribar. By the end of 2019 I decided to give it a shot myself for 2020 – little did I know how difficult of a year it’s going to be. It was also a leap year, so my Project 365 became Project 366.

Jeff Geerling, writes on his blog:

Anyways, there’s more nuance to the entire debacle, but the main thing this points to is the fact that while increasing revenue via licensing might not be the only motive Red Hat had in this move, it was certainly a major factor. And the downfall of Scientific Linux and CentOS makes those who’ve built their careers or companies around Red Hat compatibility without paying the subscription fees nervous.

I was quite surprised when Red Hat “adopted” CentOS – it seemed to me that they were always hostile and against the latter to really succeed as it was, well, not ideal for their business model. But Red Hat did (and still does) so many good things for the open source community in general and GNU/Linux specifically that it was fine to turn a blind eye. Personally I couldn’t care less, Red Hat or its derivatives was never my first choice and my go-to distribution. Regardless of this all, after acquistion by IBM, I lost hope that there will be anything good coming out of it as a result. I worked for IBM and, pretty much, owe to them my entire career. But I also know that the technical and enterprise/business side of this company are two different worlds – quite often opposed to each other.

Well, Elastic dealt with it by switching to a new license, which many in the FOSS, or Free and Open Source Software Community, have decried as not being truly open source.

Didn’t this entire relicensing drama start with MongoDB? Or was it Redis? Or all of these? Does any of this actually matter? The point is that the large-scale cloud providers and AWS especially are breaking their part of the deal. The real problem though is different: there is no deal. There never was one. Either you are open source and free and you allow for a free ride or you are not and you don’t. That’s it. Relicensing and trying to play the open source card is simply dishonest, even if it’s only to help with the business side of things – and believe me, I’m first in line to cheer for open source success.