Tired of upgrading, where's my LTS?!?

FreeBSD needs LTS releases (>=5y)


  • Total voters
    57
There is one very big difference to Linux distros that hasn't been mentioned yet. FreeBSD separates the base system and ported software from each other as mentioned but in a very strict fashion. The advertised stable API/ABI covers only the base system, I repeat only the base system.

When it comes to ports and packages, nothing is enforced for what the ported software exports as software APIs/ABIs, nothing at all, nada,zip. Only thing you can rely on is that a port/package installed on any given minor version will continue to work as it is if only the base system gets upgrade to a higher minor version. This is in stark contrast to just about any Linux distro where the whole repository of available software is bound by a common ABI. You can for example install a package from any source for Ubuntu 18 just as long as it's truly built for Ubuntu18 because the ABI contract holds over everything that you install for Ubuntu 18. FreeBSD ports doesn't have anything like this in place and this trips up many people expecting the same guarantees to exist.

The quarterly branches are sort of a step in the direction of a stable ABI for ports but they are not bound by any particular release or branch of FreeBSD, they are just a measure to limit the pace of change in the ports tree that is by it's nature a rolling release one.
 
I kept hoping someone else would ask, but I guess I'll publicly demonstrate my obtuseness. So, I am still not clear on this. Let me blame the docs for no examples. :)
Seriously, so, I want to install a production server. What RELEASE do I choose, the latest 11.x (at this time) and then, to take advantage of the 5 year stable/number, keep upgrading the point RELEASE, e.g., 11.2 goes EOL so upgrade to 11.3, and so on?

Thanks. (And Hi, Terry, haven't said chatted with you on the forums in years, it seems.)
From what I got from the docs, I was under the impression that I would be using 11.0, but from other posts, at least realize that I have misunderstood that part.

Thanks to all those who have been, with patience, explaining this.
 
I kept hoping someone else would ask, but I guess I'll publicly demonstrate my obtuseness. So, I am still not clear on this. Let me blame the docs for no examples. :)
Seriously, so, I want to install a production server. What RELEASE do I choose, the latest 11.x (at this time) and then, to take advantage of the 5 year stable/number, keep upgrading the point RELEASE, e.g., 11.2 goes EOL so upgrade to 11.3, and so on?
If you want the full 5 years, then you need to install x.0 pretty much as soon as it comes out - that's when the timer starts ticking. So you either a) have had test systems tracking the branch as soon as it was branched off -CURRENT, b) are going to jump in with both feet the day x.0 gets released, and hope any bugs you report get fixed ASAP, or c) wait either a few months or for x.1 to come out and accept the shortened lifetime because you're late to the party, but hopefully avoided any of the .0 gotcha's.

If there's a higher point release out (like 11.2) there is no reason to install 11.1 as it will soon be out of support (if it isn't already by the time you do this) and no reason at all to install 11.0 because it is already out of support.

And you need a plan to keep moving forward. This includes tracking both the -p# fixes to the point release you're on, as well as the n+1 point releases. And, starting about a year from the version's EOL, you need to start looking at the next major version. Note that by that point, the next major version has probably been out for some time, so you won't get the full 5 years there unless you start with (for example) 12.0 when it comes out.

This has led me to add an even greater separation between FreeBSD components and "my stuff" - on my file servers, I can pop out the OS SSD (in a hot-swap tray) and pop in a new one with a different major release, and with a few edits I'm good to go. The same with the nameservers I operate. Where things bog down are various specialized servers, where they are one-of-a-kind installs.
 
This has led me to add an even greater separation between FreeBSD components and "my stuff" - on my file servers, I can pop out the OS SSD (in a hot-swap tray) and pop in a new one with a different major release, and with a few edits I'm good to go. The same with the nameservers I operate. Where things bog down are various specialized servers, where they are one-of-a-kind installs.

I use a very similar set-up but don't have the funding that Terry does. Of course, mine is just my home server.

I created 2 root slices (or partitions for those who think in MS terminology) and a separate data slice. When it comes to upgrade time, I sync the content of the two slices (this is just a script). Then I switch the default boot slice to the other one and proceed to perform the upgrade on that slice only. This way if something screws up, I just switch back to the original boot slice.

I could skip the "switch the default boot slice" step but by doing this I verify that the spare will actually boot.

I'm sure others have better solutions but this works on a single disk system. The only risk is when there are ZFS update. However, with ZFS you update it separately with a ZFS command. So, I just wait a few weeks in case I have to revert. If all is good, ZFS update is run on all systems and I sync the two root slices again.
 
I'm... not actually seeing another thread about this... am I? No, it's the old one necrobumped. And how that makes it any better again...? That's it, I forgot: it does not.

First and foremost, allow me to check if I got it straight:
  • It all started by installing FreeBSD 11.0
  • Something required libpng16.so
  • That "something" was built from ports and, at first, worked with libpng16 no issues noted
  • For it's "impossible" to perform update in the "real" world (where "real" people pay "real" money to get "real" work done instead of being promised wonders that, suddenly, turn into a charming voice on the phone, deeeply apologizing for an "uncalled matter" yet "sure to be solved soon" - as long as you don't argue about when, exactly, that "soon" is meant to be, of course), nothing was changed - including whatever was built and needs libpng16.so
  • Then one day, suddenly, that thing stopped working, allegedly for another lib got outdated.
  • That is, for no updates are done, nothing have ever changed, yet something got broken
Is this correct? If not, allow me to present a slightly alternative scenario:
  • For the first two statements, it remains the same as previously stated
  • At third step, however, I've got it wrong and libpng16 was never needed
  • Goes the same until the "one day" where everything went upside down
  • At this day, however, instead of libpng16 unexplained start of complainings, the application built before is what changed for what reason might be, thus requiring a .so which was either absent or, when obtained, required something that was lacking, for it belongs to updated versions - and updating, as previously stated by more than one people, it's "impossible to be done without my boss barking at me".
Is this it? Somehow, I still get this feeling of having overlooked something. Let's have another try, shall we?
  • Once again, the beginning is pretty much the same
  • However, now I think I noticed what pointed I had missed: not every update is impossible. Some of them are, that is.
  • Therefore, pieces of the box were kept whereas others remained "stable" (you are saying, not me)
  • Since the thing-to-be-run was later implied to have been built from ports at the very beginning, it was either rebuilt against other libs and versions or, alternatively, no port rebuild took place but the libpng16.so, unfortunately, was in the "not-impossible-to-update" list, but its upgraded version is what had a requirement missing. And this requirement, as tragic as it is, was not listed in the "not-impossible-to-update" relation.

OK, now I'm more or less satisfied. Thus, without further ado, let's proceed to the main part. What, exactly, all of this means?

For starters, why some updates should be possible whereas other would have you barked at? Here in my utter ignorance I could swear the process is just the same in cohesion and logic, of course. Unless one's not concerned about these matters, but why would someone like this work in this business anyway? My secretary could update Windows - anyone is able to click "OK", right? I'd rather think a real professional, responsible for things like "production systems" is either concerned about system management, as let's say libs and linking, or have some colleague at work taking care of this part.

However, Rosie Bunny Linux does it magically. It updates what I need, doesn't update what I don't need, and whenever a possibility of conflict arises, its pack manager quickly delivers the right version of whatever it is

Well, that poses a problem to what I just said. For there are ways of doing business without keeping track of those complicated stuff. Who cares about science or engineering? Rosie Bunny would do it without my paying wages to one of those jackasses know-it-all types! On a second thought, the ones developing Rosie Bunny Linux also have a product named Rosie Bunny Enterprise Linux. I better keep my distance of this one, for otherwise I would be not only paying wages of know-it-all types, as they wouldn't even actually work for me in a truest sense. However, it's quite safe to rely on their support 99% of the time, right? As for the one percent remaining, let's pretent I never made a fuss about my clients regarding the "perils of update". After all, Rosie Bunny Enterprise is both to take the blame and keep those things to a minimal - a minimal that'd probably be left unknown by whoever hires me though, and that perhaps could've been avoided or reduced by a single know-it-all, but working here at my place, focused in my business, and able to update my system. Better yet, I could learn to do it myself! Yes, that's better. Let's, then, forget about the "Enterprised" thing and be reminded of CentOS, that is, the Rosie Bunny Enterprise-based Linux - which is free of charge!

Not only free of charge! They care for security and for keeping things running! With as little as a bit of effort on setting, I could have 20 years of updating just essentials, never ever risking any danger of this nature or others might it be!

Well, whoever thinks even nearly I just said has an odd sense of hardship, for I strive to remember something as tiresome as dealing with Anaconda, yet have no problems with either BSDs (this here and Open, at least) and Solaris (11.3).

SirDice already mentioned how limited manpower would affect the issue. And for why would that be, I can only guess. But not so hard to imagine how better can a limited number of people do well a focused, more centered job, compared to spending hours figuring how that vuln found last week in version X.Y of libfoo could be patched whilst keeping as good as ever when put to work. Work together with thousand of other pieces, of course - each and every one of them just as prone to vulns and such, to make things worse. Therefore, I can understand why their effort is to deliver the best they can - at the cost, little to my opinion, of restarting from scratch some parts that went wrong. And that, of course, would require the rest to be aware of whatever it comes to be, now. That it's fixed. That it's better. Even if my built from last spring stop working because went behind the schedule.

Yet, I can't help but find this argument just a tip of the thing as it really is. I won't judge anyone here nor there for messing around with, say, "hacking". I'm about to graduate on CS and have my interests in many topics there related, but the very field I chose to do my work and research is somewhat far from sec. I do work with algorithm analysis and development, comp. complexity and other formal stuff like spec and verification. Then again, the basics of many stuff are surely taught along the path. Be it while studying computer networks, operating systems (both of these I'd owe looots of time sleeping over Tanenbaum's works), or the very specific classes on the topic of security itself. Regardless. I'm no hacker, have no interest in being one, nor am I worth of particular note and interest. But I do know people, and these know people too. Friends, friends of friends, friends of friends of friends, and so on. Also I do know IRC and spend some time chatting there, as well as nearly forgotten protocols such as DC. And let's just leave the Onion outside this conversation for it's already longer than I'd like it to be. Back to what is relevant, I had a disagreement at the beginning of this year, memory failing to recall when exactly, but pretty sure it was before March. This little incident led me to stop meeting a certain group of people online, whose hobbies were a bit controversial or unethical in a sense, ranging from website defacing to exploiting any machine they found vulnerable and to be exploited. Even if doing so for merely the joy of saying they've done so. Actually, it was one of them who introduced me to FreeBSD, to which I was totally oblivious thus far. For a couple of years or so I've spent some time in their space, discussing lots of stuff, exchanging useful knowledge (about programming, for example), and eventually, reading about their "deeds". And when access was somehow got, before they proceeded to "deface" or whatever they aimed to, they used to paste in the channel the output of $ uname -a.


I won't answer how many of these had the word "CentOS" in the output string. After all, I took my time and wrote all this to some people stop and think. Think about that stuff about stuff made five years ago being safe because it does not break and CentOS "promised you so". Sure they did, I guess. I promise you I can fly too. Just like Superman. And just as I have some magical stone for selling. The likes of charcoal, but everlasting. A single piece would kept burning for more than 50 years without the slightest sign of degrading. But you surely understand how rare is this, right? So, if by any chance I sell what looks like just charcoal and it lasts just as much, don't blame me. Blame your bad luck, for 99% of my stuff is really magical, but with you something uncalled for is sure to had happened, and my staff is working 24/7 to make sure your pile of ashes get back to a burning stone soon. When? Just soon...
 
My two cents:

TL;DR: commercially speaking, it is unfeasible to use servers without LTS for most companies, except perhaps Netflix or Sony with very specific needs.

Long explanation:
We run a 50+ servers cloud/dev services company and we do plan carefully our upgrades. Our infrastructure is based mostly on Debian and proper plans are in place when LTS comes to EOL. We do full regression tests when upgrading, and migration takes place smoothly, but takes a lot of time during which all other operations are frozen or delayed.
It can take something between 3 months and 6 months to test all and ensure that new versions of PHP, MySQL, and so on work smoothly with the underlying OS and nothing breaks.
From business standpoint, we can't do upgrades every two years. That's simply not a commercially acceptable option, the cost is too high.

We would like to use FreeBSD but we can't. We are moving to CentOS because even 5 years is not enough.

You must also factor-in the VPS support. Most VPS providers stick to the distro support timelines, so using poudriere is possible but makes things harder.
Nobody supports anything beyond the support time, aside of Amazon, and even though, it is not easy and you must rely on third parties. Therefore, a LTS is required if you want to have multiple redundant VPS providers for security or cost.

We will encourage FreeBSD to have a 10+ LTS cycle like RHEL and will for sure use it for production purposes.
 
We will encourage FreeBSD to have a 10+ LTS cycle like RHEL and will for sure use it for production purposes.
You can encourage all you want, fact remains that FreeBSD simply doesn't have the resources to make this feasible.

And the RHEL cycle of 10 years isn't all that's cracked up to be. Do you really want to be "stuck" with a PHP version that's been EoL'ed upstream for years? I mean, the latest and greatest RHEL 7.5 is still using PHP 5.4 for example.

Which brings me to the lifetime cycle of FreeBSD, it is for the base OS only. There is no lifetime cycle for ports. So even if FreeBSD would support 12.0 for the next 10 years all ports will be updated regardless. So you still end up upgrading PHP because it's been EoL'ed and therefor removed from the ports tree.

But this actually makes keeping the base OS up to date a lot easier. Because all versions of FreeBSD use the same ports you can easily update the base OS without touching any of the versions of the ports you have installed. So your FreeBSD 11.2 with PHP 5.6 will be upgraded to 12.0 and you still keep PHP 5.6. Now try that with RHEL, upgrade from RHEL 6 to RHEL 7 and see what happens to PHP.
 
For all the reasons SirDice mentioned, I've never understood the LTS thing at all. My company only ran 10 servers at a time and always updated just fine but it's only 10 servers so maybe there's something I'm missing.
So your FreeBSD 11.2 with PHP 5.6 will be upgraded to 12.0 and you still keep PHP 5.6. Now try that with RHEL, upgrade from RHEL 6 to RHEL 7 and see what happens to PHP.
And maybe that's the part that Linux users miss. Linux users often try to compare how FreeBSD works compared to Linux and miss out on the good stuff.
 
And herein is the root of your problem;
It can take something between 3 months and 6 months to test all and ensure that new versions of PHP, MySQL, and so on work smoothly with the underlying OS and nothing breaks.
From business standpoint, we can't do upgrades every two years. That's simply not a commercially acceptable option, the cost is too high.
 
We started to use nanobsd for our products. This way we can test updates before we push them to our customers. Works fine, so far, on a scale of less than 100 servers across multiple sites. Besides with nanobsd updates are atomic, and rollback to the previous version is also possible.
 
I still think we should be having more longer minor release path, and less shorter major release path. I really struggle to believe that FreeBSD is ungoing major enough changes to warrant a new major release ever time the weather changes. We should be discussing version 10.8-RELEASE, not 11.0, 12.0., etc, so soon. It seems there is an obsession with marketing announcements of puffing up feathers "hey here is another major new release", when really its not that major at all. Then you have the folks at Emby that are doing the opposite. The coming new version of Emby media server (which is awesome by the way) is a complete major software overhaul, yet in their minds its just a minor release.

The developers of the world, need to get back on track with the old major.minor.maintence versioning schema of software versioning. That just said, I don't agree with the LTS system that we see in Linux. Sir Dice nailed that one; see his previous post.
 
I still think we should be having more longer minor release path, and less shorter major release path. I really struggle to believe that FreeBSD is ungoing major enough changes to warrant a new major release ever time the weather changes. We should be discussing version 10.8-RELEASE, not 11.0, 12.0., etc, so soon. It seems there is an obsession with marketing announcements of puffing up feathers "hey here is another major new release", when really its not that major at all. Then you have the folks at Emby that are doing the opposite. The coming new version of Emby media server (which is awesome by the way) is a complete major software overhaul, yet in their minds its just a minor release.

I said something similar on the "what are you excited for in FreeBSD 12" thread. There was pretty much nothing to be excited for because it was basically just a minor release. I preferred the system whereby major releases were reserved for big changes and there were regularly a large number of "point" releases in the mean time (FreeBSD 4 being the most obvious one when they redid SMP support - we got up to 4.11). With the current system SMP would of been a side project and 5 would of been released anyway, with the new feature waiting in the sidelines, possibly to end up appearing in a minor release.

I see no reason to release a full new version number which is not really any different from a previous release than something like 11.1 is to 11. We've passed the "version 10" milestone, and already got up to 12, and yet I don't see anything particularly interesting to account for so many major jumps. MacOS X as an example, used version 10 as a major release, and they haven't moved off version 10 since. 8 years without a major version increase, precisely because nothing since has been a big enough change to warrant it.

I guess there are some changes in the major versions that were considered too big for a point release, that otherwise would of had to wait (or features/updates that changed the ABI which isn't allowed during a point release). However personally I would of been perfectly happy to see 12 wait for pkg base and ZFS encryption (now a full re-port to ZoL), making it an obvious upgrade from 11

I've no doubt it was discussed in length by the dev teams, and the benefits of the current system outweighed the negatives. It's just that, as you say, we're flying through major releases and nothing really seemed to have changed much.
 
Afaik, both major and minor releases are strictly schedule-based. Feature-based release model is not a good fit for an operating system anyway.
 
It seems there is an obsession with marketing announcements of puffing up feathers "hey here is another major new release", when really its not that major at all.
I remember Slackware making the jump from 4.0 to 7.0 just to make their versions more "in sync" with versions of the other distributions.
 
Afaik, both major and minor releases are strictly schedule-based. Feature-based release model is not a good fit for an operating system anyway.

If that is true then why even have a major.minor convention. Just called it FreeBSD version 132, 133, 134, etc. Regarding your other comment, I respectfully disagree. Using a major.minor.maintence convention in most software, if not all, including OS, makes great sense.
 
If that is true then why even have a major.minor convention.

There does not exist any common convention, except maybe that leftmost numbers signify more potential breakage. Even then, Ubuntu-style year.month numbers would be an exception from this rule.

Just call it FreeBSD version 132, 133, 134, etc.

It is already called 10, 11, 12, etc.

Regarding your other comment, I respectfully disagree. Using a major.minor.maintence convention in most software, if not all, including OS, makes great sense.

What is a breaking change to you is a vital feature (say, driver update) for another person. With all the different use cases a general purpose OS can serve, there is no common ground on which "major" vs "minor" features can be decided.
 
But this actually makes keeping the base OS up to date a lot easier. Because all versions of FreeBSD use the same ports you can easily update the base OS without touching any of the versions of the ports you have installed. So your FreeBSD 11.2 with PHP 5.6 will be upgraded to 12.0 and you still keep PHP 5.6. Now try that with RHEL, upgrade from RHEL 6 to RHEL 7 and see what happens to PHP.

Can you please elaborate on this? I do not have much experience with Linux so I am curious about the difficulties to use old/different version of software on Linux. Knowing the type of troubles FreeBSD saves us from is useful to better appreciate the merits of the system (and better understand its design philosophy).
 
FreeBSD core OS is completely separate from the user installed software. The update tools for the core OS are different than the tools to install and update user software. This differentiates it from Linux because Linux mixes all of the user software into the same installation areas as the core OS. Software installed in Linux can have an effect on the core OS because there is no virtual separation.
 
Can you please elaborate on this? I do not have much experience with Linux so I am curious about the difficulties to use old/different version of software on Linux. Knowing the type of troubles FreeBSD saves us from is useful to better appreciate the merits of the system (and better understand its design philosophy).
Most Linux distributions (RHEL included) contain a plethora of software. Things like PHP, Apache, MySQL and a whole bunch of other things. With RHEL (and a lot of other distributions) the versions of the 'extra' software are also tied to the distribution version. RHEL 6 for example has PHP 5.3 and RHEL 7 has PHP 5.4. So if you upgrade your webserver from RHEL6 to RHEL7 you will inadvertently also upgrade PHP. And yes, RHEL has such a thing as EPEL. But this is unsupported, even if you pay RedHat a big pile of cash for support contracts. You could build everything from source of course. Just don't ask me to maintain it because it's utterly hopeless if you have to maintain a few hundred servers.

FreeBSD simply doesn't "suffer" from this because the OS and the ports (third party software) are two separate entities. So it's quite easy to have a FreeBSD 12.0 with PHP 5.6 and a FreeBSD 11.2 with PHP 7.2. And it's just as easy to keep the exact same versions of PHP, MySQL, Apache, etc, when you upgrade a major version of the OS. This basically makes the version of the OS irrelevant and can therefor be easily updated/upgraded without influencing the things that are actually important (for a web developer the version of PHP is much more important than the version of the OS it runs on).

I've taken the example of PHP because it makes it easier to explain the difference. But the same holds true for other components like Ruby, MySQL, MariaDB, PostgreSQL, and a whole lot more.
 
FreeBSD core OS is completely separate from the user installed software. The update tools for the core OS are different than the tools to install and update user software. This differentiates it from Linux because Linux mixes all of the user software into the same installation areas as the core OS. Software installed in Linux can have an effect on the core OS because there is no virtual separation.
Most Linux distributions (RHEL included) contain a plethora of software. Things like PHP, Apache, MySQL and a whole bunch of other things. With RHEL (and a lot of other distributions) the versions of the 'extra' software are also tied to the distribution version. RHEL 6 for example has PHP 5.3 and RHEL 7 has PHP 5.4. So if you upgrade your webserver from RHEL6 to RHEL7 you will inadvertently also upgrade PHP. And yes, RHEL has such a thing as EPEL. But this is unsupported, even if you pay RedHat a big pile of cash for support contracts. You could build everything from source of course. Just don't ask me to maintain it because it's utterly hopeless if you have to maintain a few hundred servers.

FreeBSD simply doesn't "suffer" from this because the OS and the ports (third party software) are two separate entities. So it's quite easy to have a FreeBSD 12.0 with PHP 5.6 and a FreeBSD 11.2 with PHP 7.2. And it's just as easy to keep the exact same versions of PHP, MySQL, Apache, etc, when you upgrade a major version of the OS. This basically makes the version of the OS irrelevant and can therefor be easily updated/upgraded without influencing the things that are actually important (for a web developer the version of PHP is much more important than the version of the OS it runs on).

I've taken the example of PHP because it makes it easier to explain the difference. But the same holds true for other components like Ruby, MySQL, MariaDB, PostgreSQL, and a whole lot more.

Thank you so much this was very helpful. I really think this insight should be provided in the Handbook in the section dealing with the installation of third party software. I'm pretty sure I met the notion that "the base OS is separated from third party software in FreeBSD", however, it didn't mean much to me until this insight.
 
Right - everything the end user installs (xorg, firefox, etc) is installed under /usr/local. Nothing gets mingled into directories above this. You can literally get rid of everything under this directory and the OS will still boot. Of course you won't have any user software so I wouldn't recommend that but you can...:)
 
Back
Top