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



## Peter Zinck Wulff (Mar 28, 2017)

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.


----------



## SirDice (Mar 28, 2017)

> 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.


----------



## Peter Zinck Wulff (Mar 28, 2017)

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.


----------



## SirDice (Mar 28, 2017)

> 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.


----------



## Peter Zinck Wulff (Mar 28, 2017)

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


----------



## SirDice (Mar 28, 2017)

Peter Zinck Wulff said:


> 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.


----------



## ShelLuser (Mar 28, 2017)

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.


----------



## ekingston (Mar 28, 2017)

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.


----------



## SirDice (Mar 28, 2017)

ekingston said:


> 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.


There's work being done to make updates/upgrades of the base OS possible by using pkg(8).

https://wiki.freebsd.org/PkgBase


----------



## drhowarddrfine (Mar 29, 2017)

I think that's kind of a dangerous proposition. Updating an OS unattended?


----------



## Alexander Huemeyer (Mar 29, 2017)

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.


----------



## Kiki Novak (Mar 29, 2017)

ShelLuser said:


> 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.


----------



## IPTRACE (Mar 29, 2017)

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.


----------



## max21 (Mar 29, 2017)

gpatrick said:


> 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!


----------



## Alexander Huemeyer (Mar 29, 2017)

IPTRACE said:


> 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.


----------



## IPTRACE (Mar 29, 2017)

Alexander Huemeyer said:


> 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.


----------



## Alexander Huemeyer (Mar 29, 2017)

IPTRACE said:


> 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.
> ...



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.


----------



## SirDice (Mar 29, 2017)

Kiki Novak said:


> 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.


----------



## Kiki Novak (Mar 29, 2017)

SirDice said:


> 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.



Yes, I know that very well, and don't get me wrong. I'm running a small IT company in South France, and for the record, my production servers are running Slackware Linux. Speaking of manpower.


----------



## Alexander Huemeyer (Mar 29, 2017)

SirDice said:


> 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.


----------



## drhowarddrfine (Mar 29, 2017)

Alexander Huemeyer said:


> But in greater company projects, this is a showstopper.


You mean like Netflix and WhatsApp and Yahoo and Juniper?


----------



## forquare (Mar 29, 2017)

Alexander Huemeyer said:


> 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?


----------



## Alexander Huemeyer (Mar 29, 2017)

drhowarddrfine said:


> 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.


----------



## Alexander Huemeyer (Mar 29, 2017)

forquare said:


> 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.
> 
> ...



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.


----------



## drhowarddrfine (Mar 29, 2017)

Alexander Huemeyer said:


> 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.


----------



## ekingston (Mar 29, 2017)

Alexander Huemeyer said:


> ... some it guy has to do a `yum update -y` every few months. And they were fine. Even heartbleed didn't affect them.



Oh yes it did. Heartbleed most definitely affected RHEL. Or more accurately, every single web server that uses OpenSSL including Apache and NGINX.

To fix it on RHEL all you had to do was `yum update -y`.

On FreeBSD all you had to do was `pkg update && pkg upgrade and type the letter 'y'` when it asked for confirmation to proceed.

I want to be able to put the pkg update && pkg upgrade into a cron job (and also the freebsd-update related commands for the core OS). Some people say that is crazy/scary/too risky. They have legitimate arguments based on their risk apatite. Some of us believe we have sufficient mitigating controls in-place to bring the risk within acceptable levels for our particular risk apatite.


----------



## gkontos (Mar 29, 2017)

ekingston said:


> To fix it on RHEL all you had to do was `yum update -y`.


A friendly advice. Avoid using the -y flag. Some day you might end up with a non operational system.


----------



## scottro (Mar 29, 2017)

There is a -y flag for pkg as well, but I tend to agree with gkontos, sooner or later it will (with pkg, yum, apt, or anything) do something to make you say, "Oh darn. I shouldn't have used -y there."


----------



## Maxnix (Mar 29, 2017)

ekingston said:


> On FreeBSD all you had to do was `pkg update && pkg upgrade`


You don't need `pkg update` before upgrading your packages. pkg(8) will take care of updating your repositories by itself, if there is the need.


----------



## ANOKNUSA (Mar 29, 2017)

This thread's not going to resolve anything or pose any meaningful solutions, because no-one's bothered to define what the actual problem is. Are we complaining about upgrades to FreeBSD? To installed packages? Or are we simply complaining about the lack of paid, cover-your-ass support contracts that let us shift blame onto faceless nobodies we don't care about, poor schmucks working in the bowels multi-million-dollar companies that our employers' tiny legal departments would never be stupid enough to mess with, just so our ignorant bosses will shut up? Without knowing what the real concern is there's not much further this thread can go.


----------



## Deleted member 9563 (Mar 30, 2017)

ANOKNUSA said:


> no-one's bothered to define what the actual problem is.



I was wondering that myself. I'm not a production user, just some old guy who fiddles with a lot of stuff. However, the only problems I've encountered with FreeBSD upgrade over the years have been because my own lack of expertise and basically my own fault. Looking back on the kinds of problems I've had with Linux (which I've used since it came out) have been because of (largely) unwanted modernizations of the software.

On a side note; Frankly, regardless of one's personal preferences or professional needs, I don't think one can ever win. It always amuses me how people go on about the importance of their particular verdict when deciding what they argue is the only logical choice for them or their situation. To me it looks more like just defensive ammunition. When people are happy with what they have, they'll make it work. This goes for the corporate as well as the home user.


----------



## Oko (Mar 30, 2017)

Kiki Novak said:


> 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 happen to work with one of those enterprise-grade Linux systems. For starters in a serious business environment here in U.S. we typically use desktops for about three years and servers about five. That time coincide with a typical manufacturer warranty. I have quite a few servers which are over five years old but no server older than 8 years after one of them recently died during the planned power shutdown. To be frank with you LTS beyond 5 years makes little sense as those machines should be replaced with new hardware.

Speaking of Red Hat derivatives you mentioned, you probably know the upgrade among major versions is not supported. As a mater of fact Red Hat 6 used Ext2 for a root partition while Red Hat 7 completely moved to XFS. As somebody who works daily with RHEL, FreeBSD, and OpenBSD I see no major advantage or disadvantage of RHEL over the BSDs (FreeBSD 10 and later supports binary updates just like OpenBSD via openup). Actually FreeBSD installed on the ZFS pool is the safest system to update as you can always go back to the previous snapshot via *beadm*.

https://blather.michaelwlucas.com/archives/2363

In terms of upgrading between releases OpenBSD is the easiest (but it could be due to my familiarity with the system).

FreeBSD has a lots of problems. Please check my post in this thread

https://forums.freebsd.org/threads/59058/

but LTS is definitely not the one of them. RHEL really has an edge in terms of automatic, unattended installation over FreeBSD if I need to point one advantage of RHEL.

Comparing to RHEL/Ubuntu (with few exceptions all other so called distributions bring nothing except custom wallpapers)  any of BSDs and FreeBSD in particular could be considered hobby projects if not for the rich UNIX history. I don't understand Linux guys who come onto this forum and say FreeBSD should do this or that. FreeBSD has no Red Hat, Canonical, HP, Oracle, IBM behind itself like Linux (iXsystems is moms and paps shop at best) so it should not act as one.

IMHO not replacing OpenSSL with LibreSSL is far bigger FreeBSD problem than LTS.


----------



## Terry_Kennedy (Mar 30, 2017)

SirDice said:


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


I'm generally satisfied with the current model. What I would like to see added is security-fix-only support for the last release of one major version (let's call it 10.3) until the .1 release of the next major version (11.1 in this case) has been out for 6 months.

A bunch of us with multiple production servers are wary of going with any .0 release. This wariness is reinforced by the number of threads we see here with people reporting problems either going from 10.3 to 11.0 or once they are on 11.0. While we don't use freebsd-update (we build new system images from scratch and then use a deployment script to push them to production servers), there are enough other issues to make us wary. Consider my "Who the heck tested this?" post here, which also links to another thread where someone had their mfi(4) controller (a very popular device) fail to be detected in 11.0 after working fine in 10.x.

And practically, it will take us a few months to get all our locally-developed stuff tested and approved for a new major release. Hence my request for "11.1 + 6 months". This could be called "extended support" or "mature version support" once the standard support for 10.3 ends, to indicate that the only support coming is security fixes and there won't be any MFCs of enhancements or errata fixes.

It will be important to get developers on board with this. Right now, there are a few developers [you know who you are] that seem to delight in ripping out support for old versions within a few weeks of the version going out of support. Conversely, there are other developers who apparently feel "if it isn't a big problem, why not MFC". 9-STABLE still gets regular commits, 8-STABLE has had at least 5 commits in the last year, etc.


----------



## SirDice (Mar 30, 2017)

Oko said:


> IMHO not replacing OpenSSL with LibreSSL is far bigger FreeBSD problem than LTS.


You can already use LibreSSL for a lot of ports and if I recall correctly there's also some work being done to replace the OpenSSL in the base with LibreSSL.

https://wiki.freebsd.org/LibreSSL

We may not get there fast but we'll get there in the end


----------



## SirDice (Mar 30, 2017)

Terry_Kennedy said:


> What I would like to see added is security-fix-only support for the last release of one major version (let's call it 10.3) until the .1 release of the next major version (11.1 in this case) has been out for 6 months.


FreeBSD 10 is a bit tricky as that still falls in the 'old' support scheme. But it's likely there's still support for at least one major version before the current one (not counting -CURRENT). So there will be, for example, 12.1 and 11.4 (just guessing the minor version) support at the same time. The 5 year starts counting after the _last_ release of a major branch. Depending on how fast they're going to release new versions you may even see 11.4, 12.2 and 13.0 being supported.


----------



## Deleted member 9563 (Mar 31, 2017)

Terry_Kennedy said:


> This wariness is reinforced by the number of threads we see here with people reporting problems either going from 10.3 to 11.0 or once they are on 11.0.



It is always difficult to judge by these things, but I think there have been a lot of threads reporting situations that a professional or more skilled user would not encounter.

Being one of the ones who screwed up royally on going to 11.0, I've noted many of those threads. This is just anecdotal, but it seems that many of those were because of misunderstanding the process. It is pretty simple when you know, but there are at least two things which have caused that in many instances. One of them could be fixed with trivial effort.

One it that going from 10.1 to 11.0 requires an intermediate step. That makes sense, but it doesn't make sense that the process wouldn't either do it for you, or warn you to do it manually. It's a reasonable assumption for people to make and I think that the upgrade code should take into account some of the basic errors that a user might make. Another is that the handbook layout is poor when it comes to upgrading. If one is in a hurry and doesn't look carefully, one will miss the part where it says you have to reinstall all programs. It says that, but only much later on the page after a long section which is irrelevant to most people. I'm sure I'm not the only one who thought they were finished following the instructions and didn't discover that there was more important information far down on the page.


----------



## ANOKNUSA (Apr 1, 2017)

SirDice said:


> The 5 year starts counting after the _last_ release of a major branch.



I thought it started with *.0-RELEASE? That would give roughly two years of support via binary updates, followed by roughly three years of support through the -STABLE branch (or just 5 straight years through the -STABLE branch) for those willing to use it. I thought the whole point was to give users a reasonably long support period and a predictable release schedule while also cutting down on the number of supported releases to alleviate the burden on the development team. It makes sense for users, since if they so chose they could just upgrade once every couple years to the last, well-tested minor release of each major version, and the development team could relax a bit.

Starting the countdown after the last minor release would result in an absolute minimum of 6.5-7 years of support for every major version, and since a new major version comes out every 1.5-2 years, we'd end up with four supported major versions at once. I could be looking at this from the wrong angle or misunderstanding something, but it seems like there wouldn't be any significant change...


----------



## crypt47 (Aug 25, 2018)

Hi! After RedHat decided to make a big renovation between it's 6.x and 7.x major releases I started to investigate FreeBSD release cycle. 5 years of support for major version sounds promising but it's 2 days of reading and testing and I can't comprehend the idea of the new FreeBSD release model. The aim is to setup a system with 5 years ABI stability.

Starting point: https://www.freebsd.org/security/

"Effective FreeBSD 11.0-RELEASE, the support model has been changed ... 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."

That's great, but what does it mean? I guess if freebsd-version shows 11.0-RELEASE-p16 we are in the clear. Is it? No, I still get infamous '/lib/libz.so.6: version ZLIB_1.2.9 required by /usr/local/lib/libpng16.so.16 not found'. WTF? What have I missed? Evidently I have a point release. Then how to move to a STABLE branch? freebsd-update -r 11-STABLE upgrade? freebsd-update -r 11.0-STABLE upgrade? No, nothing like this exists on the mirror.

This link ( https://www.freebsd.org/doc/en/books/dev-model/release-branches.html ) doesn't explain to me should I consider -STABLE a line of minor releases in stable branch of just one release in the end of that series. Considering the doc is about 3rd release it's probably obsoleted anyway.

SirDice sujests 'The 5 year starts counting after the _last_ release of a major branch'. That's fun, so I should wait for the last in the line to be released to get my ABI stability? Let's see when this is going to happen...

https://www.freebsd.org/security/

```
Branch          Release                   Type Release  Date                  Expected EoL
stable/11         n/a                       n/a     n/a                                    September 30, 2021
releng/11.1  11.1-RELEASE       n/a     July 26, 2017                  September 30, 2018
```

Ok, now it's stable vs releng and what all this n/a mean? How should I interpret this? If stable/11 has no release date it means it is not a release but a line of multiple releases. What about SirDice's suggestion? No, it can't be true otherwise stable/11 wouldn't end in 2021 or it should be present right now.

Now I have two systems:

one as a result of upgrade: 11.0-RELEASE-p16 and a fresh install 11.0-RELEASE-p1
in both cases pkg upgrade says all my packages are up to date.

What a mess...

Looks like FreeBSD (with binary packages) is just a short-term release like Fedora. Words about 5 year support are just words. As well I you can run Fedora, update it every 6 month and call it a 5 year support.


----------



## ShelLuser (Aug 25, 2018)

First: you're responding to a thread which has been idle for over a year. Might want to keep that in mind because with older threads there's no guarantee that participants are still active (there's also the issue that things could have changed drastically over time as well).



crypt47 said:


> "Effective FreeBSD 11.0-RELEASE, the support model has been changed ... 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."
> 
> That's great, but what does it mean?


Just what it says. FreeBSD knows major versions (10, 11, 12) and minor versions / releases (10.4, 11.1, 11.2). A major release will be supported for 5 years whereas support for a minor release (or point release I suppose) heavily depends on the release of the next version. Support will only be valid for 3 months after that release date.



crypt47 said:


> No, I still get infamous '/lib/libz.so.6: version ZLIB_1.2.9 required by /usr/local/lib/libpng16.so.16 not found'. WTF? What have I missed?


Impossible to comment on without any more context. You could have missed /usr/ports/UPDATING, you could have made the classic mistake of mixing ports (`# make install clean`) and binary packages (`# pkg install`), you could have decided not to upgrade your FreeBSD version and let its support expire (the ports collection is only build against supported releases) and of course you could also have made plenty of mistakes during the installation of graphics/png.

This issue is hardly as infamous as you try to make it sound:

```
peter@zefiris:/usr/local/lib $ ldd ./libpng16.so.16
./libpng16.so.16:
        libz.so.6 => /lib/libz.so.6 (0x80123b000)
        libm.so.5 => /lib/libm.so.5 (0x801453000)
        libc.so.7 => /lib/libc.so.7 (0x800823000)
```



crypt47 said:


> Evidently I have a point release. Then how to move to a STABLE branch? freebsd-update -r 11-STABLE upgrade? freebsd-update -r 11.0-STABLE upgrade? No, nothing like this exists on the mirror.


And now you're making me wonder how much research you _really_ did. Because it looks like you just skimmed over the whole lot.

Why would you want to use a STABLE branch in the first place? STABLE is a so called snapshot release, aka a developers version. It is less bleeding edge than CURRENT but even so it's still an experimental release which isn't officially supported. Developer snapshots are provided 'as is' and basically don't get any guarantees that they'll even run.

Major difference being that STABLE is, as mentioned, far less experimental and therefor even supported on these forums, but even so: if you're worried about support options then you really don't want STABLE. Stick with the production releases instead.

There's no mess here at all, the major issue is that with this material it's expected that users carefully read and also pay attention to the details.


----------



## crypt47 (Aug 25, 2018)

Doesn't the thread goes up? Anyway, I repeate, the aim is to setup a system with 5 years ABI stability. What you say 'A major release will be supported for 5 years whereas support for a minor release (or point release I suppose) heavily depends on the release of the next version.' doesn't explain why library linkage is broken between minor releases. The same way you take Fedora and update it every half a year. What's the point if application compiled for a [minor] release is broken after update? I mentioned RHEL because it allows exactly that: compile your app for minor release and then run it till the EoF without problem. This is what I call 'support' and 'abi stability'.

https://access.redhat.com/articles/rhel-abi-compatibility


----------



## crypt47 (Aug 25, 2018)

ShelLuser said:


> This issue is hardly as infamous as you try to make it sound:


i'm not the only one...

http://www.null.nl/?p=36


----------



## ShelLuser (Aug 25, 2018)

crypt47 said:


> Anyway, I repeate, the aim is to setup a system with 5 years ABI stability.


Then you don't want developer snapshots, but stick with RELEASE.



crypt47 said:


> What you say 'A major release will be supported for 5 years whereas support for a minor release (or point release I suppose) heavily depends on the release of the next version.' doesn't explain why library linkage is broken between minor releases.


It isn't.

Most likely this is the result of an improper upgrade, but as I mentioned above there's hardly enough information to comment on it in detail.


----------



## scottro (Aug 25, 2018)

Yeah, I find that confusing. What should you use if you're running a production server,  11.0-RELEASE?   I do wish they'd be a bit more explicit.   One is usually advised to upgrade, but if you're in production, and upgrade to 11.1, then 11.2 comes out, breaks things, including VirtualBox, which may be used in production. (If it's used for graphic editing, NVidia, another broken package may also be used.)


May be similar to RedHat/CentOS, you accept the tradeoff of older packages and systems for stability. 
You definitely don't want to move to STABLE.  See Fred Cash's explanation, which, while written for 4x, 5x, and 6x releases is still valid.  http://srobb.net/release.html


----------



## crypt47 (Aug 25, 2018)

ShelLuser said:


> Then you don't want developer snapshots, but stick with RELEASE.



But I am! You can see it from my post. And I don't use ports cause I understand the implication. No, the linkage for package is broken just because I'm on 11.0 which is now obsoleted.


----------



## crypt47 (Aug 25, 2018)

scottro said:


> May be similar to RedHat/CentOS, you accept the tradeoff of older packages and systems for stability.



I surely accept this trade-offs in my case. Cause we have our own repo with very new versions of whatever we need. And breaking of a library interface between minor (sic!) updates is a no-go.


----------



## crypt47 (Aug 25, 2018)

scottro said:


> See Fred Cash's explanation, which, while written for 4x, 5x, and 6x releases is still valid.  http://srobb.net/release.html



I think in 2018 we have the opposite situation.
"-STABLE refers to the programming API/ABI used by the kernel and base applications and libraries. IOW, developers can write applications and drivers for 6.0 and that same binary and driver will work on 6.9 " - this is actually what i needed but can't get with a new FreeBSD release model.

"This is contrary to the Linux world, where "stable" means stable running code and not stable programming APIs/ABIs " - which is untrue in my case cause RHEL gave me just that. Though their new initiative "make a new base, change everything" breaks things again.


----------



## crypt47 (Aug 25, 2018)

```
peter@zefiris:/usr/local/lib $ ldd ./libpng16.so.16
./libpng16.so.16:
        libz.so.6 => /lib/libz.so.6 (0x80123b000)
        libm.so.5 => /lib/libm.so.5 (0x801453000)
        libc.so.7 => /lib/libc.so.7 (0x800823000)
```


```
freebsd ~ # strings /usr/local/lib/libpng.so |grep ZLIB
ZLIB_1.2.9
ZLIB_1.2.4.0
freebsd ~ # strings /lib/libz.so.6 |grep ZLIB
ZLIB_1.2.4.0
ZLIBprivate_1.0
ZLIB_1.2.7.0
ZLIB_1.2.7.1
```

As you see libpng has higher requirements then base system provides...


----------



## crypt47 (Aug 25, 2018)

... and that how it looks after a minor (!) update 11.0->11.2


```
[root@freebsd2 ~]# strings /lib/libz.so.6 |grep ZLIB
ZLIB_1.2.4.0
ZLIBprivate_1.0
ZLIB_1.2.7.0
ZLIB_1.2.7.1
ZLIB_1.2.9
```


----------



## ShelLuser (Aug 25, 2018)

Not to mention the problem that LTS doesn't solve anything, it only postpones the inevitable. Sooner (in that case later) you are going to have to perform that upgrade and when you do (and you have no other alternatives left) then things can become quite messy when you're effectively upgrading between three or four major releases.

The time and alleged money you "safe" by using LTS can then easily get burned up, and more.

A faster release cycle can also have it's hiatus, but it is something you can anticipate for, and with a bit of proper planning and testing things don't have to be that problematic.

Of course many want less effort and not having to deal with their OS too much if possible. But for a server that's usually not a viable option.


----------



## Terry_Kennedy (Aug 25, 2018)

crypt47 said:


> I think in 2018 we have the opposite situation.
> "-STABLE refers to the programming API/ABI used by the kernel and base applications and libraries. IOW, developers can write applications and drivers for 6.0 and that same binary and driver will work on 6.9 " - this is actually what i needed but can't get with a new FreeBSD release model.


I think there's a bunch of confusion here. Let me see if I can explain some things:

1) A "major version" of FreeBSD is supported for a minimum of 5 years from the release of the x.0 version. So FreeBSD 11 is supported for 5 years. That doesn't mean you can install 11.0 and expect support for 11.0 for the whole 5 years. First, you need to keep up with security patches (the -p# in the release name). After 11.1 comes out, you have 3 months to update your system before 11.0 becomes unsupported. You get to 11.1 via the same method you installed the -p# patches (there are a variety of methods, freebsd-update is the one normally suggested for end users).

2) There is a difference between FreeBSD "base" (what the developers are 100% responsible for [more or less - contrib and some other parts are special cases]) and "ports" (which are adaptations of other software, for example net/samba48). Ports have a defined maintainer in the FreeBSD development environment, but that maintainer is just responsible for keeping the port up-to-date with "upstream" and dealing with any bug reports that seem to be FreeBSD-specific. There are a number of different ways to update your installed ports, and again you need to stick with one method.

3) There is no guarantee that new installs of ports (pulling pre-built binaries from a FreeBSD distribution server) will work properly on anything but the latest release of a particular version. That is another reason to keep your base system up-to-date (see item 1 above).

4) Mix-and-match definitely does *not work*. You use freebsd-update, build from source, or some other method to keep "base" updated. You either use packages (pre-built binaries) for "ports", or you build from source. You use one of the 2 methods to keep your ports updated if you build from source - portmaster or portupgrade. You *cannot* start with one method and then change to the other, unless you are an expert and understand the steps you need to take to handle the conversion (and any ensuing fallout).

5) The issue you seem to have is an installation of a new port (from packages) on an unsupported release. Remember, you have 3 months after the next "dot" release comes out to update your system. Refer to https://www.freebsd.org/releases/ for supported and unsupported releases. It is likely that if you built the port from source, it would not give you this error. However, see the previous item about not mixing and matching methods of installing / updating ports.

6) The FreeBSD ABI is quite stable and upwardly compatible on any given major version. Note that I said upwardly compatible - a program built on 11.0 should run on 11.2 without any problems, but a program built on 11.2 may or may not run on 11.0. I think this is what you ran into with your port. Additionally, the ABI is compatible with most programs compiled under [much] older FreeBSD versions. The kernel part of this is controlled by the "COMPAT_FREEBSDx" build options (default on). This provides backward compatibility with specific older versions of FreeBSD (except for COMPAT_FREEBSD32, which is for 32-bit support on 64-bit systems). The library part of this is handled by various ports - for example, misc/compat10x for compatibility with user binaries from FreeBSD 10. I just checked and I can run a (non-trivial - 500K source lines) binary compiled on FreeBSD 6.3 i386 on FreeBSD 11.2 amd64.


----------



## kpa (Aug 25, 2018)

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.


----------



## scottro (Aug 30, 2018)

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.


----------



## drhowarddrfine (Aug 30, 2018)

scottro said:


> Let me blame the docs for no examples.


I get blamed for everything.


----------



## Terry_Kennedy (Aug 31, 2018)

scottro said:


> 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.


----------



## scottro (Aug 31, 2018)

Thanks, Terry, that makes it clearer.


----------



## ekingston (Aug 31, 2018)

Terry_Kennedy said:


> 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.


----------



## fscorrea (Sep 4, 2018)

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...


----------



## initd (Dec 27, 2018)

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.


----------



## SirDice (Dec 27, 2018)

initd said:


> 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.


----------



## drhowarddrfine (Dec 27, 2018)

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.


SirDice said:


> 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.


----------



## JAW (Dec 27, 2018)

And herein is the root of your problem;


initd said:


> 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.


----------



## Bobi B. (Dec 29, 2018)

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.


----------



## jpierri (Dec 29, 2018)

Bobi B. said:


> Besides with nanobsd updates are atomic, and rollback to the previous version is also possible


That is precisely the reason we selected nanobsd (and Asterisk) for an internal PBX appliance.


----------



## PacketMan (Jan 4, 2019)

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.


----------



## usdmatt (Jan 4, 2019)

> 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.


----------



## shkhln (Jan 4, 2019)

Afaik, both major and minor releases are strictly schedule-based. Feature-based release model is not a good fit for an operating system anyway.


----------



## SirDice (Jan 4, 2019)

PacketMan said:


> 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.


----------



## PacketMan (Jan 4, 2019)

shkhln said:


> 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.


----------



## shkhln (Jan 4, 2019)

PacketMan said:


> 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.



PacketMan said:


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



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



PacketMan said:


> 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.


----------



## reddy (Jan 7, 2019)

SirDice said:


> 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).


----------



## Sevendogsbsd (Jan 7, 2019)

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.


----------



## SirDice (Jan 7, 2019)

reddy said:


> 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.


----------



## reddy (Jan 7, 2019)

Sevendogsbsd said:


> 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.





SirDice said:


> 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.


----------



## Sevendogsbsd (Jan 7, 2019)

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...


----------

