I wrote this in 2012 - almost exactly ten years ago - and it remains true.
Looking at freebsd.org right now I see that my options for production, release systems are 12.3 and 13.0 ...
... which means that if 12.1-RELEASE came out at the end of 2019 and 13.0-RELEASE came out in April of 2021, you had all of 16 months to make investments in the 12 branch before it was hopelessly passe and all queries regarding it would be answered with:
"That's fixed in current ..."
The 4.x nostalgia is justified: it was polished and polished and polished over many years and many organizations were incentivized to invest in that branch
> ... which means that if 12.1-RELEASE came out at the end of 2019 and 13.0-RELEASE came out in April of 2021, you had all of 16 months to make investments in the 12 branch before it was hopelessly passe and all queries regarding it would be answered with:
So basically the same as Debian and Ubuntu LTS? Debian releases every ~2 years with 5 years of Security+LTS support, which is the same as Ubuntu (LTS):
- Resolving our arbitrary (and unofficial) 5-year branch lifetime
guarantee. The support policy is that the stable/X branch will be
supported for 5 years (minimum) from the point X.0-RELEASE is released.
We now guarantee a 5-year lifetime on the branch, regardless of how many
releases are built from the branch. Additionally, a "last minute"
release from the stable/X branch does not constitute expanding the support
lifetime for the branch as a whole for an additional two years.
[…]
- A new stable/ branch release will not occur before two years after the
X.0-RELEASE from the prior branch. This limits the number of
simultaneous supported branches, which will greatly reduce the overall
number of branches that must be maintained and build-tested for
Security Advisories and Errata Notices, reducing turnaround time.
1. GP makes me wonder whether the FreeBSD definition of LTS is less than people expect.
2. Maybe to properly admin a modern FreeBSD box the admin is supposed to be making the underlying system version easily replaceable. i.e. Make the actual OS files changing have no effect upon hosted system/application stability.
I would still have built rsync.net on FreeBSD because of how familiar I was with it and how much I had personally (and institutionally) invested in it from JohnCompanies.
Since ZFS is now so core to what we do, it was a very natural evolution.
I have zero experience with Dragonfly BSD.
I love that FreeBSD is still a very simple UNIX without complications like systemd. I was recently tinkering with a raspberry pi and had to work out wifi connectivity and had to interface with ... what is that weird wifi subsystem that linux uses ? Supplicant ? Wow.
I just want to pipeline commands and edit config files. I don't care that it's inefficient or doesn't scale. It has scaled just fine for me.
As someone without skin in this particular game, I'm curious to hear your view of the OS landscape today. Have you considered (or perhaps even tried) migrating rsync.net out of FreeBSD given these issues?
Either there is a code contributor pushing for functionality (Example sendfile/nginx) or a donor suggesting a path forward or a volunteer given free time.
Every foundation goals can be driven via sponsorship. At the end everything is simplify as who pays the bills at the end of the month?
This raises the old question: Who pays for the free in free software?
> "It's difficult to escape the notion that FreeBSD is becoming an operating
system by, and for, FreeBSD developers."
I don't know how many FreeBSD devs are paid full time and how much of it is voluntary, but this is the outcome that I would expect absent a traditional customer-vendor relationship. This is basically every open source project ever where most of the work being done is non-commercial.
We could quibble about what exactly "primarily" means, but that's not the phrase he used which is "by, and for" without the qualifier. So here's two reasons to make FreeBSD for others as well:
- They use a lot of code that they don't develop. If FreeBSD is not for others then those external projects and developers would be disinclined to make their stuff work on FreeBSD.
- Every new FreeBSD developer comes from a non-FreeBSD developer who is interested in FreeBSD and probably uses it. More developers ~= better FreeBSD for FreeBSD developers.
- More users (very roughly) means more money. Whether that's money to pay for more FreeBSD developers, or incentive to make your hardware work with FreeBSD or port your software to it, there are some positive effects on the system and possibly your wallet.
- Personal satisfaction to develop software lots of people use. Also the recognition that comes with that can get you a job or help you meet people and go places.
So lots of reasons. Even being purely selfish and hoping to extract the most from it, there are plausible reasons why some amount of focus on others might be the best way to go about developing a the project.
If you have a large installation, why depend on FreeBSD releases at all instead of choosing (arbitrarily) a newer STABLE snapshot, testing it and eventually rolling into production same way you’d do with a release?
The transition from the 4.x branch of FreeBSD to 5.x.
5.x had all kinds of problems and then 6.x was the first release that barely got out into public use before 7.x undercut it ... and that is the cycle we have been in ever since.
4.x had minor releases going all the way to 4.11. Nowadays, major versions generally stop at X.3 (for instance, 11.3).
It also seems like 10 years ago folks were a lot more willing to have discourse, where today… if you have difference(s) of opinion, it's not received as well.
Is this true? When I was a kid using the internet to learn to code on the 2000s people seemed a lot meaner in general than they are now. It was hard to ask a question on a forum without being made to feel like an idiot.
I wonder if I’m the only one who read your comment and flashed back to a time in the distant past when some genuinely, maliciously, irredeemably batshit crazy people used to post on the FreeBSD mailing lists. One memorable guy who I will not name went on later to become of all things an investor and finance blogger and apparently claims to have helped found the Tea Party, which is all just absurdly hilarious.
> ... which means that if 12.1-RELEASE came out at the end of 2019 and 13.0-RELEASE came out in April of 2021, you had all of 16 months to make investments in the 12 branch
A worst-case 16 months sounds like an absurdly long support window by the standards of most actively developed projects; anything but the largest and most corporate of projects is unlikely to do better than that.
And it seems contradictory to complain that stable releases aren't supported long enough but you're waiting too long for new functionality. Of course everyone wants daily releases that are supported forever, but realistically with finite development effort most projects have to settle on something equivalent to "you can run -CURRENT or you can run LTS, pick your poison".
This has not been my experience over the last 20 years across multiple industries. Generally I'd expect (and have written into an SLA) a minimum of 2 years support for anything even vaguely critical. If using Open Source I'd be buying from a vendor who would guarantee that level of support. I acknowledge it's different if you're working for an early stage startup designing the next tinder for marmosets or whatever in which case you probably don't care about support windows because you're likely to crash and burn within your support window.
As others have pointed out LTS exists elsewhere - the truth is LTS is minimum level of support necessary for most users. Everything else is essentially bleeding edge - too much work to maintain, constantly bugged, etc.
The previous model where a major change could have support last for decades, where the system was modular in that patches could apply to any major version - that was gold.
Unfortunately today we have this "yesterday's tech is garbage" attitude, and honeslty it is mostly making all software garbage.
Do you ever think about your toaster? No of course you don't. It turns on when you need it, toasts the bread, and then turns off. It doesn't require your attention. Ever.
Then you look at your computer and wonder what buggy hell you'll end up with if you roll the dice with the latest updates.
Something is fundamentally wrong about how we are using computers.
Well, now your toaster is slowly getting wifi modems and processors so it can be "cloud connected" and require a subscription. So don't worry - the same excitement you have updating your computer today will soon come to your toast and bagel situation.
If you're running Debian Stable or RHEL, updates aren't buggy hell. If you're running Arch, Gentoo, or Alpine: of course updates are buggy hell, that's what you signed up for.
Here's a summary of what happened: Firefox got a new password database format. Originally, it would write the new database file and use it if present, but leave the old one there indefinitely. A little while later, people realized this was a security vulnerability: if you create or change your master password, the old database will still let attackers in without one or with the old one. The vulnerability was fixed by having Firefox delete the old database on startup.
The code to read and write the new password database was a new feature, so Red Hat deemed it unworthy to add to their "stable" distro. The code to delete the old password database was a security fix, so Red Hat cherry-picked it into their distro.
But now the problem should be obvious: Red Hat's version of Firefox now deleted the old password database on startup, but lacked the code to write out the new version of it. As a result, as soon as you started Firefox, your saved passwords would be completely wiped from disk. This problem was inherent to the "stable" model that RHEL uses, and would have never happened with distros that just take new upstream versions and avoid cherry-picking patches, like Arch.
Arch at least is super stable in terms of bugs. The problem comes with changes in software versions. Too often people think that stability means only bugs. I would even argue that Arch has even less bugs than Debian.
An operating system dedicated to toasting bread would be fully possible to make in a way that did not need updates or attention, as long as it had enough testing first.
Is this partly because there is no (or very little) commercial support for FreeBSD and therefore nobody is all that interested in the boring bits like long-term stability releases such as the 5 year release, 5 years of support suggestion in that thread? The volunteers want to do new and interesting things. They don't want to backport fixes for 5 year old bugs anymore when most likely the subsystem that contained that bug has already been replaced in current anyway, so "what's the point?". And if nobody is being paid to do it, if there's nobody _to pay_ to do it, then nobody is going to do it. This has always been the problem with FreeBSD. Despite some great technology the operating system itself has mostly fallen by the wayside in the grand scheme of things. There's way too much FreeBSD "religion" in that community IMO.
There is plenty of commercial support, though, nobody publish anything publicly thanks to the BSD license, thus everybody re-invent the wheel internally.
Btw, I'm an ex proprietary-solution-based-on-FreeBSD developer.
Differentiation from Linux is a hot topic whenever FreeBSD is discussed. I could get behind “converge to a fixed scope, and polish relentlessly” as the primary ethos.
Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished? At the moment, all OS releases are just waymarkers on an endless, goalless roadmap of perpetual development.
>Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished?
I don't mean this in a rude or dismissive way but these comments make me want to pull my hair out. Deciding your software has a fixed scope and is finished doesn't stop the wheels of progress from turning. Worst case, the rest of the world will decide the scope you chose was crap, for reasons beyond your control, and then your project is dead. I get that it is an engineer's fantasy to build a theoretically "perfect" system but such a thing can't exist in practice. I think you'd have a better chance of proving P=NP or something.
I don’t mean finish FreeBSD forever and go home - I mean finish a release.
Set some goals, release software that achieves those goals, and keep fixing bugs that are found.
If you have some new goals (support new hardware, add new feature), work on those in the next release. But don’t abandon the old release, because it still works to achieve the original goals.
What I’m suggesting to avoid is the situation where a bug is found and the user is told “it’s fixed in the next release”. If the bug compromises the goals of a release, it should be fixed in that release!
Sure you’d have to support old releases for much longer, but that’s not the hard part.
The hard part is deciding what the goals are in a precise and coherent way (for this purpose, goals should be the set of promises made to the user, which when broken give rise to a bug). I don’t think any large software project has good discipline here. I don’t think it’s been done before for an OS. But I’m talking about differentiation here.
Spend any amount of time in the FreeBSD kernel, and you'll figure out that "polish" aspect is just a myth. The Linux kernel is MUCH cleaner.
Kernel subsystem are written by a couple developers at most, in private, and submitted as a +20k/-5k single file diff on a public ML for "discussion".
Some developers I spoke with privately were able to make things move a bit by getting their commit bit and start making aggressive changes without discussions / consensus. That wasn't my style.
> Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished?
Hardware eventually fails. Replacement hardware is eventually incompatible with previous hardware. "Finished" would in this case be a synonym for "dead".
> I could get behind “converge to a fixed scope, and polish relentlessly” as the primary ethos.
> Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished?
By OS do you mean just the kernel or also the userspace?
Then I think the challenge is to determine what gets included under the purview of relentless polishing.
Assuming you mean just the kernel, then probably bug fixes are included. But what about drivers for new hardware? And when researchers at Stanford develop a new file system algorithm with foo bar baz properties? Or a new scheme for sandboxing user programs?
Maybe all new features in new Major version? New FS=Next. But drivers should be buildable by the HW vendor right? And shouldn't the next kernel version be not crazy-hard to port the driver?
All the companies making tivoed devices with walled gardens on BSD/MIT-basis would absolutely love it, if the worldwide group of enthusiasts would finally come together to eliminate most of their in-house software development costs by delivering the perfect free solution, that only needs some branding, marketing and lock-in applied.
Sarcasm aside, I agree, that lots of software could feel more "finished"/refined. I'm trying to think, which of the xkcd comics fits the best here...
The non-portable part of MS-DOS essentially is implemented in the BIOS. When PCs no longer support BIOS booting then MS-DOS will not work, but until then it is sustained by a stable interface.
Am I understanding this correctly? FreeBSD y releases (x.y) are not snapshots of CURRENT, but rather are backports that are maintained separately from the really LTS x release?
I always assumed FreeBSD had a major release and then minor releases that were snapshots of CURRENT like Ubuntu's non-LTS releases were of Debian Unstable.
Ubuntu's numbering scheme is year.month, not major.minor. FreeBSD's major releases are branches of CURRENT. Minor releases are branches from the stable branch.
FreeBSD creates a branch off current very close to a major release. So work for a new major release happens on current. At some point current blocks new features and focusses on fixing bugs. Then a branch for the major version is created and current can work on the next major release.
After that, minor releases mostly contain backported material.
Who uses FreeBSD those days? As a company that runs on the cloud, AWS/GCP/Azure you run windows/linux, and on desktop people mainly run MacOS/Windows/Linux.
I am really asking as for what is the main use case of FreeBSD in 2022?
We[1] have our entire infrastructure on FreeBSD - and always have.
That's why this has been frustrating - we have a history of committing real money[2][3] to the project in an attempt to make investments ... but there is never a fixed target to make those investments in.
It is a matter of fact that our own use of FreeBSD - in live production for a business - is completely divorced from the experience and day to day usage of FreeBSD developers.
It's funny you wrote that because when browsing HackerNews, for me the 3rd item above this was:
We're migrating many of our servers from Linux to FreeBSD (dragas.net)
The (currently) top-voted comment of that thread is somebody describing, how they went back to Linux after the honeymoon-period with FreeBSD, among others because of systemd.
The BSDs always had a following in network-related roles, since Linux has had some issues in the past (e.g. accept filters used to be useful, iptables more complicated than pf), and OpenBSD cultivated a security-minded reputation.
Have you done any writing about that experience and setup? Both Postgres and ZFS are COW, I seem to recall some warnings back in the day about conflicts between the two systems but I have no first hand experience.
It's used to build and distribute closed source operating systems and devices to users. Every Mac and iPhone user has a little bit of 2003-era FreeBSD running that provides XNU its BSD "flavor".
SwitchOS is not based on FreeBSD. It has a net stack forked from FreeBSD code but if that makes it a FreeBSD than Windows and Linux are both BSDs I guess.
Readit News
Looking at freebsd.org right now I see that my options for production, release systems are 12.3 and 13.0 ...
... which means that if 12.1-RELEASE came out at the end of 2019 and 13.0-RELEASE came out in April of 2021, you had all of 16 months to make investments in the 12 branch before it was hopelessly passe and all queries regarding it would be answered with:
"That's fixed in current ..."
The 4.x nostalgia is justified: it was polished and polished and polished over many years and many organizations were incentivized to invest in that branch
So basically the same as Debian and Ubuntu LTS? Debian releases every ~2 years with 5 years of Security+LTS support, which is the same as Ubuntu (LTS):
* https://en.wikipedia.org/wiki/Debian_version_history#Release...
* https://en.wikipedia.org/wiki/Ubuntu#Releases
From "Changes to the FreeBSD Support Model":
[…] * https://lists.freebsd.org/pipermail/freebsd-announce/2015-Fe...* https://www.freebsd.org/security/
1. GP makes me wonder whether the FreeBSD definition of LTS is less than people expect.
2. Maybe to properly admin a modern FreeBSD box the admin is supposed to be making the underlying system version easily replaceable. i.e. Make the actual OS files changing have no effect upon hosted system/application stability.
- if you could start all over fresh, what OS (and why) would you run your business on?
- what’s your opinion about Dragonfly? Any experience with it?
- what are the things you love about FreeBSD, as well as what still needs improvement (besides release cycle topic)?
Since ZFS is now so core to what we do, it was a very natural evolution.
I have zero experience with Dragonfly BSD.
I love that FreeBSD is still a very simple UNIX without complications like systemd. I was recently tinkering with a raspberry pi and had to work out wifi connectivity and had to interface with ... what is that weird wifi subsystem that linux uses ? Supplicant ? Wow.
I just want to pipeline commands and edit config files. I don't care that it's inefficient or doesn't scale. It has scaled just fine for me.
Every foundation goals can be driven via sponsorship. At the end everything is simplify as who pays the bills at the end of the month?
This raises the old question: Who pays for the free in free software?
https://freebsdfoundation.org/our-donors/donors/?donationYea...
I don't know how many FreeBSD devs are paid full time and how much of it is voluntary, but this is the outcome that I would expect absent a traditional customer-vendor relationship. This is basically every open source project ever where most of the work being done is non-commercial.
Did anything come of it?
I'm curious: Why _shouldn't_ it be an OS primarily for its developers? Why should they focus on others when they're the one building it?
- They use a lot of code that they don't develop. If FreeBSD is not for others then those external projects and developers would be disinclined to make their stuff work on FreeBSD.
- Every new FreeBSD developer comes from a non-FreeBSD developer who is interested in FreeBSD and probably uses it. More developers ~= better FreeBSD for FreeBSD developers.
- More users (very roughly) means more money. Whether that's money to pay for more FreeBSD developers, or incentive to make your hardware work with FreeBSD or port your software to it, there are some positive effects on the system and possibly your wallet.
- Personal satisfaction to develop software lots of people use. Also the recognition that comes with that can get you a job or help you meet people and go places.
So lots of reasons. Even being purely selfish and hoping to extract the most from it, there are plausible reasons why some amount of focus on others might be the best way to go about developing a the project.
How many people run TempleOS these days, I wonder?
5.x had all kinds of problems and then 6.x was the first release that barely got out into public use before 7.x undercut it ... and that is the cycle we have been in ever since.
4.x had minor releases going all the way to 4.11. Nowadays, major versions generally stop at X.3 (for instance, 11.3).
There wasn't a "STABLE" release of it until FreeBSD 5.3 https://en.wikipedia.org/wiki/FreeBSD_version_history#FreeBS...
FreeBSD may not be a perfectly-run project but I honestly can't imagine using anything else :)
Discourse used to be a thing.
> Discourse used to be a thing.
That is adorable.
A worst-case 16 months sounds like an absurdly long support window by the standards of most actively developed projects; anything but the largest and most corporate of projects is unlikely to do better than that.
And it seems contradictory to complain that stable releases aren't supported long enough but you're waiting too long for new functionality. Of course everyone wants daily releases that are supported forever, but realistically with finite development effort most projects have to settle on something equivalent to "you can run -CURRENT or you can run LTS, pick your poison".
The previous model where a major change could have support last for decades, where the system was modular in that patches could apply to any major version - that was gold.
Unfortunately today we have this "yesterday's tech is garbage" attitude, and honeslty it is mostly making all software garbage.
Do you ever think about your toaster? No of course you don't. It turns on when you need it, toasts the bread, and then turns off. It doesn't require your attention. Ever.
Then you look at your computer and wonder what buggy hell you'll end up with if you roll the dice with the latest updates.
Something is fundamentally wrong about how we are using computers.
Deleted Comment
Computers as appliances used to be more true than it is today on significantly worse hardware.
The “instant on”- of a commodore64 is a distant thing of the past but it needn’t be.
One of the major reasons for systemd coming to prominence was boot times, so people do care.
If your machine could start and stop in 500ms flat then it would fundamentally change the way you interact with it.
Here's a summary of what happened: Firefox got a new password database format. Originally, it would write the new database file and use it if present, but leave the old one there indefinitely. A little while later, people realized this was a security vulnerability: if you create or change your master password, the old database will still let attackers in without one or with the old one. The vulnerability was fixed by having Firefox delete the old database on startup.
The code to read and write the new password database was a new feature, so Red Hat deemed it unworthy to add to their "stable" distro. The code to delete the old password database was a security fix, so Red Hat cherry-picked it into their distro.
But now the problem should be obvious: Red Hat's version of Firefox now deleted the old password database on startup, but lacked the code to write out the new version of it. As a result, as soon as you started Firefox, your saved passwords would be completely wiped from disk. This problem was inherent to the "stable" model that RHEL uses, and would have never happened with distros that just take new upstream versions and avoid cherry-picking patches, like Arch.
Btw, I'm an ex proprietary-solution-based-on-FreeBSD developer.
Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished? At the moment, all OS releases are just waymarkers on an endless, goalless roadmap of perpetual development.
I don't mean this in a rude or dismissive way but these comments make me want to pull my hair out. Deciding your software has a fixed scope and is finished doesn't stop the wheels of progress from turning. Worst case, the rest of the world will decide the scope you chose was crap, for reasons beyond your control, and then your project is dead. I get that it is an engineer's fantasy to build a theoretically "perfect" system but such a thing can't exist in practice. I think you'd have a better chance of proving P=NP or something.
There is no good reason why one should strive for a piece of software to be eternal.
It would be much better to say, well this is what we wanted to accomplish. The program does a good job now.
Later it might be time to build something else.
You build a nice warm and cozy cabin in the woods, and you like it. Keeps you warm and dry. Success.
Now 15 years later, the area is no longer in the woods, rather it is now zoned within a city to have duplexes.
You can then think that you built such a great building that now you need to remodel it into a duplex, and then a quadplex and then a skyscraper.
I think saying "my cabin was very good, now I have to let go of it and and build something else" is a much better approach.
It is nearly delusional to think that you will write a program that will be good enough to be prepared for what the future brings.
We need ot let things die and build again.
Set some goals, release software that achieves those goals, and keep fixing bugs that are found.
If you have some new goals (support new hardware, add new feature), work on those in the next release. But don’t abandon the old release, because it still works to achieve the original goals.
What I’m suggesting to avoid is the situation where a bug is found and the user is told “it’s fixed in the next release”. If the bug compromises the goals of a release, it should be fixed in that release!
Sure you’d have to support old releases for much longer, but that’s not the hard part.
The hard part is deciding what the goals are in a precise and coherent way (for this purpose, goals should be the set of promises made to the user, which when broken give rise to a bug). I don’t think any large software project has good discipline here. I don’t think it’s been done before for an OS. But I’m talking about differentiation here.
Kernel subsystem are written by a couple developers at most, in private, and submitted as a +20k/-5k single file diff on a public ML for "discussion".
Some developers I spoke with privately were able to make things move a bit by getting their commit bit and start making aggressive changes without discussions / consensus. That wasn't my style.
Hardware eventually fails. Replacement hardware is eventually incompatible with previous hardware. "Finished" would in this case be a synonym for "dead".
> Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished?
By OS do you mean just the kernel or also the userspace?
Then I think the challenge is to determine what gets included under the purview of relentless polishing.
Assuming you mean just the kernel, then probably bug fixes are included. But what about drivers for new hardware? And when researchers at Stanford develop a new file system algorithm with foo bar baz properties? Or a new scheme for sandboxing user programs?
Sarcasm aside, I agree, that lots of software could feel more "finished"/refined. I'm trying to think, which of the xkcd comics fits the best here...
I always assumed FreeBSD had a major release and then minor releases that were snapshots of CURRENT like Ubuntu's non-LTS releases were of Debian Unstable.
This chart attempts to draw the relationship in ASCII: https://github.com/freebsd/freebsd-src/blob/main/share/misc/...
After that, minor releases mostly contain backported material.
I am really asking as for what is the main use case of FreeBSD in 2022?
That's why this has been frustrating - we have a history of committing real money[2][3] to the project in an attempt to make investments ... but there is never a fixed target to make those investments in.
It is a matter of fact that our own use of FreeBSD - in live production for a business - is completely divorced from the experience and day to day usage of FreeBSD developers.
[1] rsync.net and, previously, JohnCompanies
[2] https://www.rsync.net/resources/notices/2007cb.html
[3] USD 50k donation offered - https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan...
Cool to see people still building on FreeBSD, sad to see that it's an uphill battle to stay relevant with it.
"Serving Netflix Video at 400Gb/s on FreeBSD" https://people.freebsd.org/~gallatin/talks/euro2021.pdf
https://freebsdfoundation.org/freebsd/
[1] https://news.ycombinator.com/item?id=30057549
Deleted Comment
But in reality there is a big risk of nobody putting money on the table for that maintenance. Am I right?