4 ms·

This means that for over a year there has been no good answer to the question "which version of FreeBSD should I use". Not true at all. The answer is: 1. If

This means that for over a year there has been no good answer to the question "which version of FreeBSD should I use". Not true at all. The answer is: 1. If you have systems which are already running 10.x, you should run the latest 10.x release. 2. If you're deploying a new system now, you should deploy it with the latest 11.x release. 3. If you're building a product which you will be selling next year, you should build it on top of FreeBSD HEAD, so that it will be running a recent release when it ends up being deployed. Old STABLE branches get updates and new releases because there are deployed systems which are using them. Think of 10.3 as "FreeBSD 10, service pack 3".

ksec 9y ago
Those are exactly my thoughts. Long time ago we didnt upgrade Business Systems from XP to Windows 7, you apply the Services Pack for as long as possible. Of coz you should be upgrading now because XP is no longer supported. A long time ago I thought it was stupid not to upgrade to the latest and greatest. It turns out in business stability triumph over everything else. ( That is assuming you have a decent security measures put in place already )
laumars 9y ago
It's also very easy to upgrade FreeBSD from one major release to the next. I've been steadily upgrading FreeBSD since version 8.x.
alberth 9y ago
@cperciva, I think rsync point is that it hasn't been since 4.x that a release had had more than 3-4 dot release. Just look at the version history. Most major releases are only developed for approx 2 years. https://en.m.wikipedia.org/wiki/FreeBSD#Version_history https://en.m.wikipedia.org/wiki/FreeBSD#Version_history @rsync, is there any other BSD out there that has a better model than FreeBSD? (E.g. netbsd, openbsd, dragonflybsd)
rsync 9y ago
"If you're deploying a new system now, you should deploy it with the latest 11.x release." Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD. I think that's a decent heuristic in general - for instance, I don't buy a car until they've been rolling off the line for 9-12 months - but in the case of FreeBSD it is a concrete rule based on experience - not a superstition. So again, the cool kids all stopped working on 10.x[1] over a year ago, and 11.1 was not released. In our case, 10.x was working fine for us and nothing was terribly broken driver-wise (unlike 8.x when we desperately needed intel NIC fixes circa 8.2 that all went to 9 and never got backported).[2] So we kept deploying 10.3. [1] Driver fixes all go to 11, non-critical bugs all "committed to stable", etc. [2] Well, except for some nice new bhyve features that all went to stable were not available to us for the last 12-18 months (and will never go to 10).
- reanimator 9y ago
  Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD. If FreeBSD were to accommodate this kind of SOP given their current resources, what could they do other than just call the first release x.1 instead of x.0?
- emaste 9y ago
  > It is very appropriate that you remember the 4.x days like that since that is the last time there was a long term, stable target for FreeBSD development (and investment). > Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD. The important thing to keep in mind is that these are two consequences of the state of the FreeBSD tree in the early 5.x days. There's no question the first couple of 5.x releases had a great number of stability and other issues, and I can certainly understand that experience leading to an approach of "never use a .0 release." But it is precisely because early 5.x was in such bad shape that 4.x continued to receive ongoing development for so long.
- cperciva 9y ago
  Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD. Frankly, if that's the lesson you learned from FreeBSD 5.0, I don't know that there's anything I can say to help you. A more appropriate lesson to learn from FreeBSD 5.0 would have been "don't use releases which are cut from HEAD and announced as being for 'early adopters'". The FreeBSD 5.x stable branch started at FreeBSD 5.3.
  - emaste 9y ago
    I think the long-standing impression left by 5.0 (despite carrying explicit warnings about being appropriate for early adopters) carries a good lesson for us: this sort of lore is surprisingly sticky. It doesn't matter that 5.0 was very much an anomaly that wasn't repeated, and that recent .0 releases were very stable. I suspect end-users like John are going to avoid .0 releases for as long as they use FreeBSD.

ksec 9y ago

Those are exactly my thoughts. Long time ago we didnt upgrade Business Systems from XP to Windows 7, you apply the Services Pack for as long as possible. Of coz you should be upgrading now because XP is no longer supported. A long time ago I thought it was stupid not to upgrade to the latest and greatest. It turns out in business stability triumph over everything else. ( That is assuming you have a decent security measures put in place already )

laumars 9y ago

It's also very easy to upgrade FreeBSD from one major release to the next. I've been steadily upgrading FreeBSD since version 8.x.

alberth 9y ago

@cperciva, I think rsync point is that it hasn't been since 4.x that a release had had more than 3-4 dot release. Just look at the version history. Most major releases are only developed for approx 2 years. https://en.m.wikipedia.org/wiki/FreeBSD#Version_history https://en.m.wikipedia.org/wiki/FreeBSD#Version_history @rsync, is there any other BSD out there that has a better model than FreeBSD? (E.g. netbsd, openbsd, dragonflybsd)

rsync 9y ago

"If you're deploying a new system now, you should deploy it with the latest 11.x release." Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD. I think that's a decent heuristic in general - for instance, I don't buy a car until they've been rolling off the line for 9-12 months - but in the case of FreeBSD it is a concrete rule based on experience - not a superstition. So again, the cool kids all stopped working on 10.x[1] over a year ago, and 11.1 was not released. In our case, 10.x was working fine for us and nothing was terribly broken driver-wise (unlike 8.x when we desperately needed intel NIC fixes circa 8.2 that all went to 9 and never got backported).[2] So we kept deploying 10.3. [1] Driver fixes all go to 11, non-critical bugs all "committed to stable", etc. [2] Well, except for some nice new bhyve features that all went to stable were not available to us for the last 12-18 months (and will never go to 10).

reanimator 9y ago
Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD. If FreeBSD were to accommodate this kind of SOP given their current resources, what could they do other than just call the first release x.1 instead of x.0?
emaste 9y ago
> It is very appropriate that you remember the 4.x days like that since that is the last time there was a long term, stable target for FreeBSD development (and investment). > Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD. The important thing to keep in mind is that these are two consequences of the state of the FreeBSD tree in the early 5.x days. There's no question the first couple of 5.x releases had a great number of stability and other issues, and I can certainly understand that experience leading to an approach of "never use a .0 release." But it is precisely because early 5.x was in such bad shape that 4.x continued to receive ongoing development for so long.
cperciva 9y ago
Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD. Frankly, if that's the lesson you learned from FreeBSD 5.0, I don't know that there's anything I can say to help you. A more appropriate lesson to learn from FreeBSD 5.0 would have been "don't use releases which are cut from HEAD and announced as being for 'early adopters'". The FreeBSD 5.x stable branch started at FreeBSD 5.3.
- emaste 9y ago
  I think the long-standing impression left by 5.0 (despite carrying explicit warnings about being appropriate for early adopters) carries a good lesson for us: this sort of lore is surprisingly sticky. It doesn't matter that 5.0 was very much an anomaly that wasn't repeated, and that recent .0 releases were very stable. I suspect end-users like John are going to avoid .0 releases for as long as they use FreeBSD.