I've been following FreeBSD development for a long time, and I've been wondering if changes to the support model would be forthcoming and would help simplify things so that if I build on top of FreeBSD I can be guaranteed some sort of stability in the longer term.
This announcement while welcome doesn't give me a really good idea of what is going to change. It would be absolutely fantastic if some examples could have been included instead of just stable/X.
For example, using hypothetical released named X.0-RELEASE and Y.0-RELEASE and Z.0-RELEASE what are the branch names going to be called, how often are they going to be created, and how long are they going to be supported?
How does this compare to LTS from Canonical/Red Hat? How easy is it going to be to keep up with the changes between the minor releases? What guarantees does the community have that driver modifications/fixes are not going to get stuck in -CURRENT or the next major release only, or have to be manually back-ported?
How does this compare to LTS from Canonical/Red Hat?
Ubuntu has a LTS release every 2 years, which is supported for 5 years. FreeBSD will have a release every 2ish years, which is supported for 5 years.
How easy is it going to be to keep up with the changes between the minor releases?
It's already relatively straightforward by using freebsd-update, but work is underway to simplify this further.
What guarantees does the community have that driver modifications/fixes are not going to get stuck in -CURRENT or the next major release only, or have to be manually back-ported?
None. This is, after all, a volunteer project; if nobody is interested in backporting a driver, it isn't going to get backported. Also, from time to time there are new devices which require significant changes to the underlying kernel architecture (video drivers and virtual memory come to mind, for example), and those are often impossible to merge back because doing so would break internal interfaces used by third-party drivers.
I understand that major devices will be impossible or difficult to merge back, especially if there are invasive changes. In the past though even relatively simple changes were not MFC'ed until someone asked for it, and once MFC'ed it took a long time for it to appear in a point -RELEASE. Tracking stable/ isn't for the faint of heart, and especially isn't for those of us that want to do binary upgrades.
Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Rather than some of the 8+ months that have happened in the past between point releases?
even relatively simple changes were not MFC'ed until someone asked for it
To a certain extent that's always going to happen in volunteer projects. That said, at least on the server side, the "ecosystem" of FreeBSD-using companies with committers on staff is expanding, and they're doing an increasing amount of this sort of maintenance. The topic of how we can make sure important MFCs happen has certainly come up.
Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable?
Maybe. Certainly there is significant support for doing more frequent point releases; but some of the reason they have been so slow lately has been due to operational issues (aka. re@ juggling too many balls at once) so these policy changes aren't going to have a dramatic effect overnight, but they might contribute to things improving.
Given the limited resources available, what are you expecting to occur? Why would they dedicate staff to back porting drivers that may literally never be used? If the person implementing the driver doesn't personally have a need to run it in an older version of the OS, they aren't going waste precious time back porting it just for the sake of back porting it.
In the case of drivers, a lot depends on the specific hardware. Some drivers are written by employees of the hardware manufacturer, some are written by employees of companies using FreeBSD, and some are written by interested volunteers.
Hardware vendors have an interest in supporting whichever FreeBSD versions are of interest to their customers, and often merge to all supported branches.
FWIW, this was how long we typically supported releases anyway -- FreeBSD 6.x was supported from November 2005 until November 2010, FreeBSD 7.x was supported from February 2008 until February 2013, FreeBSD 8.x from November 2009 until June 2015, and FreeBSD 9.x from January 2012 until December 2016 -- but we heard from users that a promise was far more useful than a vague "well, typically...".
Whenever a new point release is made (e.g. 11.1) all previous point releases will be deprecated after 3 months (e.g. 11.0)
This is really the most important change, and addresses a problem we've had for a while: When a point release comes out, we have no idea how long it will be until the next point release. For both users and the security team, knowing the end of the support period relative to the arrival of the next point release (i.e., the overlap time) turns out to be more important than knowing the end of the support period relative to the start of the support period.
Please don't call me lazy. I tried to understand the announcement and it just didn't make a whole lot of sense so I asked questions about it.
@cperciva answered those questions for me in a much more pleasant way than you did.
That being said, the reason I am confused is because it doesn't really change anything. Releases were already for the most part supported for 5 years, and new releases were already cut once every two years (look at 9.0-RELEASE and 10.0-RELEASE).
The timeline for dropping support of point releases is important. The rest is mainly about improving communication: Many users were not aware that we supported releases for 5 years, for example, because all they ever saw was the advertised "12 months" or "24 months" for point releases.
Yes, the understanding for how long point releases will be supported makes a lot of sense and will definitely help. The rest (5 year support timeline) was already something I understood from having followed the project for some time, I just didn't understand if this announcement changed my understanding thereof.
Phrases like "will not occur before two years after" are not particularly straight-forward. I found some of the prose in this release curly and baroque; if you have to re-read a sentence a few times to get the meaning right, it's not clear language.
I'd really like to hear your thoughts with regards to this announcement, given how you've been vocal in your frustration of the FreeBSD support methodology [1][2]
Five year support for a release every two years still means three balls in the air.
Yes. Although this is probably better characterized as "two balls actively being thrown and one ball on its way down", since we've never done new point releases in the last year of a major branch (and I doubt that will change).
No dedicated timeline for minor releases. Could still be 13 months between 11.1 and 11.2.
Correct. We decided many years ago that FreeBSD worked better if we did releases "when they were ready" rather than working to a calendar. I'm sure OpenBSD's schedule works well for OpenBSD, but our projects are quite different (e.g., OpenBSD development is more centralized in a small number of hands).
Doesn't address question of what actually gets back ported. Will new em updates go into stable?
FreeBSD is a volunteer project. Updates get merged if someone merges them. Aside from policy restrictions, which are not changing (e.g., we won't merge ABI or API-breaking changes, because we insist on supporting third-party software), it's entirely up to people having the time and interest.
Five years seems like a long time to support an OS release, especially for a volunteer project. Do you know if there was any consideration/discussion around a shorter lifecycle (like 3 or 4 years)?
Yes, there have been people who want to reduce the support timeline. There are also people (mostly vendors who build products on FreeBSD, but also companies which run lots of FreeBSD servers) who wanted a longer support timeline.
Like most things, five years was a compromise. :-)
In a followup post to my original January 2012 rant, I suggested the following[1][2]:
- A major release every 5 years
- A minor release every 4-6 months
- total focus on the major release for essentially that entire 5 year period
Obviously there are more details than that, but the point is, it's not the five year number that matters - it's the number of branches floating around simultaneously that is the real problem.
"Instead of having a legacy branch and two production branches, you would
have legacy (8) production (9) and ... nothing. Or if you need to have it
out there, 10 is the development branch. Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15
at the end of the cycle."
So ... in looking at this new announcement, it seems like they are addressing some points that I have brought up in the past, but in reality I think they are addressing completely different issues, especially with regard to applying security errata, etc.
The problem I see is the (short) two year embargo on a new release, which means that over the five year lifecycle of a release, potentially two other releases come out, which is basically what we have now. Bug fixes and driver updates get written and applied to the sexy new tree[3], and the "supported" release that's all of two years old gets none of it.
That's great that it's around for five years, and I appreciate the clarity there - but there is more to support than the ports tree and security errata. True support is the developer community working in and with a release for years, and that hasn't happened since 4.x.
The problem I see is the (short) two year embargo on a new release
If support for a new device can't be merged into older releases because it relies on ABI/API breaking changes, do you want to be told that you won't be able to use your shiny new hardware in a FreeBSD release for the next five years?
Two years is a compromise between "don't try to support too much at once" and "make sure that people don't have to wait too long to access new features".
"If support for a new device can't be merged into older releases because it relies on ABI/API breaking changes, do you want to be told that you won't be able to use your shiny new hardware in a FreeBSD release for the next five years?"
Yes.
As a business user of FreeBSD, with shareholders and a board of directors, etc., we make very conservative hardware decisions and we try to amortize our investments over as long a period as is practically possible.
I've never thought this argument was that convincing, especially given the propensity to see FreeBSD as a server OS. The fancy things are never ready in the first release they go into anyway, so it's not like we gain much, from a practical standpoint.
Then maintain your own branch like other business users who want to have a stable branch for extended periods of time. And back port the drivers internally if you need them back ported. Literally nobody is preventing you from doing so. There are, however, people that donate extremely large sums of money to the FreeBSD foundation who do support their current release cycles.
First, my suggestions above were made originally in January of 2012, at which time I committed $50,000 to the FreeBSD project in return for adopting something like those suggestions.
So your "put your money where your mouth is" trump card was not quite what you thought it was. Thanks for playing.
Second, I reject the notion that nobody but core developers and big business has useful viewpoints as to the direction of the FreeBSD project (or any project, for that matter). You think you know what kind of resources you are talking about, above, when you speak of developing and maintaining a custom branch and backporting drivers, etc. Take that number and triple it and that's a starting point for the true amount of cost something like that would take in a real organization with real HR and QA and benefits and shareholders and a functioning board, etc. ...
... and that's out of the realm of even mid sized shops.
Spacing major releases out by five years doesn't guarantee that the bug fixes and driver updates you want will make it into the stable release. It's completely plausible that volunteers will instead develop on HEAD and commit their work there, and the changes won't be merged to the stable branch at all.
I started as a FreeBSD developer in the 4.x era. It was somewhat of an anomaly. The SMP work that went into (and delayed) 5-CURRENT was absolutely necessary, but it introduced significant instability and ongoing breakage. That was a strong disincentive to using it as a day-to-day development platform. I needed a stable development and build machine, so it ran 4.x.
Since then as a project we've done increasingly well at keeping -CURRENT in a working state. It is completely feasible for a volunteer developer to run only -CURRENT.
I was quite delighted to hear that this new model will apparently improve their ability to provide up-to-date package builds and ports.
The main reason I switched over from Linux to BSD was being tired of dealing with deciding between a bleeding-edge roll-your-own distro that breaks all the time, or a decrepit one loaded down with packages that've been out of date for 4 or 5 years.
I've been seeing a lot of new activity around FreeBSD and it's great... I think it has a bit of an opening given the outrageous fragmentation of the Linux ecosystem. There are what... three different inits?
Is it really that fragmented? There's essentially RedHat, Debian, and Slackware. At the level of app development for servers, everything seems pretty compatible.
As a desktop user I just switched from Xubuntu to Debian+Xfce and it's nearly identical.
I'm sure that people who work at the OS level see a lot of fragmentation and headaches, but to their credit it's largely hidden from the masses.
I think the opening for FreeBSD and everyone else is that with containers and virtualization, the movement is towards picking an OS per app, not an OS to run your entire business on.
And SUSE enterprise is another actually popular version, at least what I've seen in the telecom industry. So that's at least 4.
Then, there's Arch which is popular with enthusiasts, and Ubuntu has become sufficiently different from Debian that it requires thinking when switching from one to the other. Gentoo seems to be getting less and less popular, but it's still kicking.
And yes as the parent post said, it's the unexpected differences that are stressful: different init systems, selinux vs apparmour vs nothing, different locations of config files, different whole /etc structures, that sort of things. The distros are diverging fast, and switching from RHEL to Ubuntu nowadays feels like it's a whole new system.
> I just switched from Xubuntu to Debian+Xfce and it's nearly identical.
So you went from downstream to upstream and the view was largely the same. Yeah that's expected.
> I think the opening for FreeBSD and everyone else is that with containers and virtualization
FreeBSD has had container based virtualization for 15 years. I know it's the Brittany Spears of the linux dev group ATM, but I doubt it and Docker are as big a thing as it seems now. Container based virtualization is great, but it's not a substitute for a real hypervisor. As more people realize the last fact, the shine will wear off.
I think it has a bit of an opening given the outrageous fragmentation of the Linux ecosystem. There are what... three different inits?
And in BSD the fragmentation is not only in inits, but the whole kernel and base system. We have FreeBSD, NetBSD, OpenBSD, and DragonFly BSD. Then there are sort-of-forks like Darwin and JunOS.
If we divide the number of active developers by the number of variants, I am pretty sure that Linux is doing much better.
There are good reasons for using BSD, but the lack of fragmentation is not one of them.
Linux has enormously more developers than all the BSDs put together. However the BSDs still manage to provide useful platforms that work well for large numbers of use cases, and provide innovation.
What I would like to understand is, will features/versions of packages (not ports) be frozen between point releases and security and stability fixes be backported?
Does this mean that version numbers for software in ports and pkg will be frozen and security fixes backported? That sounds like the relatively new quarterly model but with support lasting for 5 years instead of phasing out after 3 months. Given the sentiment elsewhere on this page that "this doesn't really change anything outside of providing guarantees," my guess is the answer is no.
Sure would be nice. Coming from Debian, I long for a similar model in FreeBSD.
There might be semi-official repos for those somewhere as well. Or you can always build your own with poudriere.
> Coming from Debian, I long for a similar model in FreeBSD.
Oh hell no. This gives silly issues like Lenny's pigz being broken for like 4 years. Or OpenSuse's crappy model which shipped a shitty version of kde4 long after it had become stable elsewhere.
If you ship software for Debian and you've been frustrated that your users get stuck with a lousy version of a dependency, I can understand that.
I've been admining Debian boxes for more than a decade so I'm aware of the drawbacks of its policies. That's why my desktop tracks unstable. But for a sysadmin, freezing everything for long periods of time makes for an enormous reduction in churn-related administration time. Having nothing but security updates to install until the next version comes out 2+ years later is excellent. For the exceptions, pinning can often solve the problem. And if pinning doesn't work, there's always building from source.
Like I said above, I'm new to FreeBSD so I'm not sure how much churn I'll have to endure, but I'm looking forward to finding out.
I understood why you like tracking a security branch as I have been admining *nix boxes for 15+ years.
Where that approach fails is that as a sysadmin one of the responsibilities is to provide good tools to the user, not reduce work for the sysadmin. The user might be a SaaS platform, developers or more traditional (l)users. Regardless, you want your platform to be stable and efficient from a user perspective. Tracking a "Security" branch only give you one of those in many cases.
It's an apples to oranges in some regards because FreeBSD OS patchsets are essentially the "Security" branch while ports is a different issue(and one the user is most likely concerned about).
I think he meant branches which are supported for an extended duration. The quarterly branches are (currently, and as far as I know this isn't going to change) supported only for the quarter in question.
Thanks for your response, understood. I'm new to FreeBSD and as a result I didn't find the announcement clear enough to know.
Is there any chance the quarterly approach may get stretched out to cover a longer time period? Anything would be helpful to give busy sysadmins breathing room.
This announcement while welcome doesn't give me a really good idea of what is going to change. It would be absolutely fantastic if some examples could have been included instead of just stable/X.
For example, using hypothetical released named X.0-RELEASE and Y.0-RELEASE and Z.0-RELEASE what are the branch names going to be called, how often are they going to be created, and how long are they going to be supported?
How does this compare to LTS from Canonical/Red Hat? How easy is it going to be to keep up with the changes between the minor releases? What guarantees does the community have that driver modifications/fixes are not going to get stuck in -CURRENT or the next major release only, or have to be manually back-ported?