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

FreeBSD needs LTS releases (>=5y)


  • Total voters
    57
I'm getting tired of upgrading all the time, why can't we have Long Term Supported releases, like some of the more popular Linux distributions?!?

Almost every response I see in the forum boils down to Oh, x is broken because its no longer supported on your version y, so you need to upgrade. :-(

The binary packagemanager pkg was a step in the right direction, but now it is also broken on Release 10.1, which makes me want to change my entire setup from FreeBSD to Ubuntu, because I just don't wanna spend all that time upgrading every <=2y.
 
Effective FreeBSD 11.0-RELEASE, the support model has been changed to allow more rapid development while also providing timely security updates for all supported releases.

Under the new support model, each major version's stable branch is explicitly supported for 5 years, while each individual point release is only supported for three months after the next point release.
https://www.freebsd.org/security/security.html#sup

https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html

Even under the new scheme you'd still need to update your 10.1 to 10.3.
 
Thanks for the answer, SirDice! :)

However, I have a bad track record of upgrading, something almost always breaks, and I have had systems die entirely on me, which makes the upgrade a big hassle compared to the Linux approach to LTS, Install -> maintain doing update/upgrade of the packages. It's not that I don't understand what I'm doing, having run FreeBSD since release 2.x, I'm just getting too old to use a lot of time on this. So I would prefer a more Linuxlike LTS model.
 
which makes the upgrade a big hassle compared to the Linux approach to LTS, Install -> maintain doing update/upgrade of the packages.
For one client I have to maintain around 500 Linux servers, I can assure you it breaks a lot more often than my FreeBSD setup at another client. And I'm not even going to mention the hassle of upgrading one LTS version to the next (even LTS versions expire at some point in time).

If you haven't done so already switch to the quarterly package branches. Or, if you have a couple of servers to maintain, set up your own repository using ports-mgmt/poudriere (personal favorite) or ports-mgmt/synth. Having your own repository allows you to have complete control over versions, build options, etc. while keeping the ease of use of packages. It will also allow you to catch build issues before touching any of your production systems.
 
Hmm, not a bad idea about running my own repository, I'll have to look into that. I guess I've been blessed with the Linux servers I maintain, since I haven't seen many problems with them so far. But you're right, upgrading from one LTS to the next is almost always a fail, but now a days you have chef/puppet to take care of provisioning a new server.

And since puppet is also available on FreeBSD and is reported to run fine with pkgng, I guess there's no excuse not to start making some scripts for my FreeBSD servers.

I'd still like an Linux-Like LTS though :)
 
And since puppet is also available on FreeBSD and is reported to run fine with pkgng, I guess there's no excuse not to start making some scripts for my FreeBSD servers.
I have that working for the FreeBSD client. Works like a charm, especially in combination with your own repository. I can recommend adding the zleslie-pkgng module, this allows you to control which repositories are available on your puppet agents.
 
I have to politely disagree with the suggestion. Quite frankly I believe that FreeBSD already has such a support model, and a working one at that.

When looking at the 10 version you'll notice that it got released in January 2014 (source: FreeBSD release information), in the mean time we've seen 3 small "side releases" (10.1 to 10.3) and that's basically it. Now, if you look at the FreeBSD support cycle you'll notice that 10.3 gets supported until April next year (April 2018). So that's effectively four years worth of support for the 10 version. You were saying? ;)

And let's be honest here: even on Linux an LTS version requires updates from time to time. I've been using several of them and the only thing which matters is that you don't have to perform a major version upgrade. Yet, as shown above, the same applies to FreeBSD.

Another important difference; in my experience a Linux LTS isn't really an LTS. It's simply a version which receives (security) updates and that's basically it. Yet the moment when you need to upgrade you'll come to conclude that the LTS is merely a "version freeze" while other development still went on. More than often effectively resulting in the inability to upgrade from one LTS version to the other because you're basically skipping several major OS versions by doing so.

FreeBSD on the other hand supports one version for years, while also making sure that the gap between versions doesn't widen too much (basically only 2 versions are supported). Resulting in the need to do a major upgrade, but one which has been calculated for and which is also fully supported by the system. That is of course no guarantee that nothing can go wrong, but it is a guarantee that if something does go wrong then you won't be looking at the need to install 4 or 5 versions in order to upgrade your system because of the massive underlying changes between those versions.

FreeBSD doesn't need a change in its support model because it's doing an excellent job so far and in my opinion even better than those on Linux. The main thing is that you simply need to adapt to the way it works and use it as intended.

(Edit)

Another very important thing here, which I think you're horribly overlooking, is the reason why you need to upgrade. That's not just for fun, but also for your own safety as well. Sure, it can be a drag. But it'll be more of a drag when your system got overrun because you were using something which contained exploitable bugs.
 
I think plenty of people have pointed out that FreeBSD does indeed have support of a major version for quite a long time with the current support model. So, I'm going to get grouched at for changing the topic a bit. ;-)

My problem with FreeBSD is the lack of fully automated update/upgrade tools. To be clear, I mean automatic unattended updates of the core OS between minor versions. Since I'm sure some of you are going to claim this is a bad idea, I'll put the arguments against it right here...

Fully automatic updating of the OS (and software for that matter) is a bad idea if you don't do it right because you can royally mess up your system. Of course, you can royally mess up your system even if you perform the upgrade manually, review all of the various release notes, and verify the content of all your configurations. I should know. I've done it. Had to completely re-build from the ground up after a badly failed upgrade from 9 to 10.

But, there are at least 2 situations where fully automated and unattended updates make sense.

1) The home user who's FreeBSD system is not essential or can very quickly be restored to previous state (VMs with snapshots, ZFS with snapshots).

2) Large environments with a proper testing environment. Everything can be tested and confirmed to upgrade properly in the test environment before allowing the update to happen in production. Yes, this can be done with other tools and yes a proper large environment should have it's own repository for the updates. The point is, we shouldn't need those third party update/upgrade tools when FreeBSD has them built-in if only we could automate the update.


I used to be in #2. It was a while ago, and I simply modified the package and base update scripts to force them to not need user interaction. The major advantage, I didn't have to go in at 3AM (you have heard of corporate change windows, and staggered installs, right?) for 4 week running to manually update the various sets of systems. Verified it all worked in the lab, then let the systems run their own updates as scheduled.

I am now in #1. My only somewhat production FreeBSD system is my home media server. The media is on a separate NAS (FreeBSD just runs the server part). If the FreeBSD system goes down, I can suffer for a few hours or a day before I find the time to restore it (ZFS is handy).

Should automatic unattended upgrades be the default? No.

Should I be able to do it by adding a cron job and setting a flag? Yes.

Okay, granted I've been around FreeBSD since 2.1 so maybe this functionality does exist and I just need to RTFM. but if not, it's about time.

It is default in Debian (or at least in the distro that got installed by default in a cloud VM I use). It is as simple as adding a cron job in CentOS.
 
I also would appreciate LTS Releases. It's not about the features, therefor the present releasecycle is fine. It's only about security updates. 10 years like RHEL / CentOS would be great, but also 8 years would fit the typical lifecycle of a server.

It's not about things actually break when updating, it's about the things that could break. So nevertheless if i update, first i have to make a backup / test, because there are also new features (which i dont need on this server). LTS with only security updates would make life easier.
 
And let's be honest here: even on Linux an LTS version requires updates from time to time. I've been using several of them and the only thing which matters is that you don't have to perform a major version upgrade. Yet, as shown above, the same applies to FreeBSD.

On enterprise-grade Linux systems like RHEL, CentOS, Oracle Linux and similar spinoffs, you have no less than ten years of low-risk upgrades. The odd new feature may be introduced in a minor release without any drama. And I know for sure that a CentOS server that I setup back in 2014 can be kept as is until 2024, because bug corrections and security fixes will eventually be backported until then.
 
I'm upgrading my FreeBSD (host and VMs) from 10.0 release to current releases and patches.
Every time I need to compile kernels with several options. I've never had a problem with that.
Sometimes I have problems with third party applications but it's not the FreeBSD issue.

Concluding, I upgrade FreeBSD au courant and everything works fine.
 
I hear you and agree completely. It may seem silly, ridiculous, stupid, insert your own word here, but I'm thinking of moving my firewall, web and mail servers to OS/2 (eComStation) because I just want it to run and not worry about constant updates or being hacked. I think I'd have that with eCS.
Me too, but don’t throw in the towel just yet unless you have to. If it was not for this forum and the very few dedicated developers, FreeBSD would have no help.

Most of you are light-years ahead of me but I do know that if anything can be accomplish on any other system you know darn well it can be done near to better on FreeBSD. Sometime you have to lay down the book, once read, then think outside the box and invent your own tricks (rip, tear or add) where possible. Really, there is no need to upgrade when you already had the best of the best and did not know you were running the finest of them all already, then here comes the update to throw things slightly off, or total destruction for what you had. I been there and now I’m constructing my own handles, and I might go back to 10.2 to reinvent to my needs, thanks to all the great solutions that best of the best who are still providing all the solutions, RIGHT HERE … and that includes you too! We all know who you and they are and you guy have been correct, back to back, all year long. It been UNBELIEVABLE! 24/7 … Now even I is on the one. You have no rights to give in. I’ll be the first to jump out my 1 1/2 story windows, head first, if you do.

We’re near to Maximum, at least I know I am.

Thanks!
 
I'm upgrading my FreeBSD (host and VMs) from 10.0 release to current releases and patches.
Every time I need to compile kernels with several options. I've never had a problem with that.
Sometimes I have problems with third party applications but it's not the FreeBSD issue.

Concluding, I upgrade FreeBSD au courant and everything works fine.

Now imagine you have to do this on 50 Systems, test every system afterwards, and explain your boss why you are wasting 5 x 8h/day or more of your time, whilst you could have used to RHEL. Yes, FreeBSD has much benefits, but there are few domains where you really can argue for FreeBSD over RHEL/CentOS when it comes to time effort.
 
Now imagine you have to do this on 50 Systems, test every system afterwards, and explain your boss why you are wasting 5 x 8h/day or more of your time, whilst you could have used to RHEL. Yes, FreeBSD has much benefits, but there are few domains where you really can argue for FreeBSD over RHEL/CentOS when it comes to time effort.
I have more than 50 systems and upgrades takes me up to 1 day.

I've created some scripts so semi-automatic upgrading works and system is not available for maximum 25 seconds during restarts.
I have a redundant systems for every service so even restart does not stop clients services.

I test new releases with my systems so my clients are sure that It will work.
 
I have more than 50 systems and upgrades takes me up to 1 day.

I've created some scripts so semi-automatic upgrading works and system is not available for maximum 25 seconds during restarts.
I have a redundant systems for every service so even restart does not stop clients services.

I test new releases with my systems so my clients are sure that It will work.

It's fine as it works for you, but not all requirements are the same. Testing every system with new versions *would* take me some days. And often there are no resources for redundant systems. Yes - if its important there *should* be another system. But in reality costs often more important.
 
On enterprise-grade Linux systems like RHEL, CentOS, Oracle Linux and similar spinoffs, you have no less than ten years of low-risk upgrades.
FreeBSD simply doesn't have the resources or the manpower to make this feasible. Don't forget, these are reasonably big companies backing those distributions.
 
FreeBSD simply doesn't have the resources or the manpower to make this feasible. Don't forget, these are reasonably big companies backing those distributions.

I know, thats not the point here. FreeBSD is great, i honor all the work. I personally use FreeBSD everywhere i could, cause i know of its powers. But in greater company projects, this is a showstopper. Perhaps supporting every second release about 3 years longer (only security) would make a great deal in this environments.
 
Now imagine you have to do this on 50 Systems, test every system afterwards, and explain your boss why you are wasting 5 x 8h/day or more of your time, whilst you could have used to RHEL. Yes, FreeBSD has much benefits, but there are few domains where you really can argue for FreeBSD over RHEL/CentOS when it comes to time effort.

All you are doing is prolonging the inevitable and becoming less practiced. I've been in a few large companies that had shed loads of infrastructure on versions of RHEL that were coming close to EOL, and while you'd have thought perhaps that a longer time between major upgrades allows for more thorough planning, that certainly wasn't the case. What ensued was a mad panic as well defined software acceptance processes were bypassed to get things replaced on a newer release.

In large enterprise and small companies alike, I've found that there is little thought of or time for proper documentation of the infrastructure until something critical happens. Six months to EOL is no time to remember that a core server that plugs into half a dozen other systems will be affected, and yet time and time again this is what I've seen.

I must admit I've not been in companies that use FreeBSD or similar. My imagination would be that with regular upgrades would come a more practiced IT team of doing said upgrades, such that procedures and process can be defined and agreed by, and then used to justify to, management.

Maybe the grass is always greener on the other side?
 
You mean like Netflix and WhatsApp and Yahoo and Juniper?

Okay.. i mean greater in 50-500 employees. But.. Yahoo? Not a good example. The reason why WhatsApp and Netflix stick to BSD is the TCP Stack and how Ngnix/Apache can use roundbuffers and co.. less userspace switches. - Facebook is trying to port some of these features to Linux right now. And Juniper? It's all about the license. Non of your examples uses BSD for the convenience of updating.
 
All you are doing is prolonging the inevitable and becoming less practiced. I've been in a few large companies that had shed loads of infrastructure on versions of RHEL that were coming close to EOL, and while you'd have thought perhaps that a longer time between major upgrades allows for more thorough planning, that certainly wasn't the case. What ensued was a mad panic as well defined software acceptance processes were bypassed to get things replaced on a newer release.

In large enterprise and small companies alike, I've found that there is little thought of or time for proper documentation of the infrastructure until something critical happens. Six months to EOL is no time to remember that a core server that plugs into half a dozen other systems will be affected, and yet time and time again this is what I've seen.

I must admit I've not been in companies that use FreeBSD or similar. My imagination would be that with regular upgrades would come a more practiced IT team of doing said upgrades, such that procedures and process can be defined and agreed by, and then used to justify to, management.

Maybe the grass is always greener on the other side?

Perhaps you are right, and yes, the grass is always greener.. But noone ever gets fired for using rhel. And now, the time has come to upgrade all the old, stable, rock solid, rhel 5 servers. But - I (or - to be honest, someone else) installed this servers for about 10 years. And they are still running, doing their stuff, some it guy has to do a yum update -y every few months. And they were fine. Even heartbleed didn't affect them.
 
Okay.. i mean greater in 50-500 employees.
You mean like Netflix and WhatsApp and Yahoo and Juniper?

I find it interesting that people disavow any listings of FreeBSD usage as "they only use it for <insert reasons here>" but the reality is simple: they use FreeBSD for reasons that made them not use something else and FreeBSD was the better choice.

Did I mention Sony? They have more than 500 employees I think.
 
Back
Top