3 ms·

I find it alarming that releases are EOL after 1 year, whereas RedHat Linux releases are supported for 10 years.

by XERQ 12y ago

deleted 12y ago
[deleted]
danieldk 12y ago
That's a point release. Red Hat point releases are also not supported for 10 years (you follow along the point releases on the major version for that length of support). It seems to be pretty much the same on FreeBSD. However, the support for major versions is also shorter. E.g. 8.0 was released in 2009, and 8.x is not supported anymore.
- crest 12y ago
  FreeBSD 8.4 is supported until 2015-06-30. FreeBSD 8.0 was released on 2009-11-25. Odd numbered minor releases and the last minor releases in a major release are supported for 2 years. Migration two newer minor releases of the same major release preserves binary compatibility. There are ports to preserve binary compatibility with previous major releases. Why would want to run 10 year old binaries if a compatible and improved version exists? Run FreeBSD 8.4 and 10.1 on the same hardware and perform a bunch of benchmarks. Even if none of the new features are relevant to you it offers improved performance.
  - danieldk 12y ago
    FreeBSD 8.4 is supported until 2015-06-30. FreeBSD 8.0 was released on 2009-11-25. Odd numbered minor releases and the last minor releases in a major release are supported for 2 years. Sorry, I misread the release table. Then, that is pretty impressive, 6 years for a major release! Why would want to run 10 year old binaries if a compatible and improved version exists? Personally, I don't but in many enterprises a new stable release is often only introduced after a 1-3 years. Then it is to expensive if support runs out quickly. When I was involved with CentOS (ca. CentOS 4 & 5) era, there were still many companies running 2.1 and 3.
  - rsync 12y ago
    Yes, that is what it says on paper, but I would submit that both 5.x and 7x were essentially EOL the day they came out. Since 4.x there has been a huge focus on the upcoming releases. By the time the x.0 release comes out, all of the cool kids are working hard on x+1 and x+2 - you saw this especially during 8.0 and 8.1 when a lot of mailing list chatter from core developers revolved around nitty gritty details of 10.x. By the time 7.1 came out (for instance) all new driver bug fixes, etc., stopped being applied to the 7 tree and the answer to every question was "it will be in (8/9)". I do appreciate the fact that an 8.4 was created - it's a step in the right direction and a sign of some real understanding of the problems the end users are having with an inability to invest in FreeBSD and make long-term plans with their own platforms. However, I still would like to see a release ... any release ... get to x.10 or x.11 - like 4 did. I even committed $50k to that end a few years ago (although I suppose that's small fries these days :) If people would like to know my specific critiques, there was a long mailing list discussion in 2012: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037294.html http://lists.freebsd.org/pipermail/freebsd-hackers/2012-Janu...
    - kev009 12y ago
      I expect this would be a big deal for the appliance manufacturers (think Juniper, NetApp, Isilon) that need to support long life cycles . I'd also expect those type of companies to pony up for long term support (and they do, at least internally, with staff developers and trees) But in an ops context, why not simply install compat<version> packages? Or worst case, run the obsolete apps in a <version> jail? With containers, I think we're rapidly approaching a point where the software that touches the hardware can evolve faster than the libraries/support around applications, and this quite frankly is awesome!
- feld 12y ago
  I don't think that's entirely true. I've been told you can get support for older RedHat point releases but you have to pay RedHat an obscene amount of money.

I find it alarming that releases are EOL after 1 year, whereas RedHat Linux releases are supported for 10 years.

by XERQ 12y ago

I find it alarming that releases are EOL after 1 year, whereas RedHat Linux releases are supported for 10 years.

deleted 12y ago

[deleted]

danieldk 12y ago

That's a point release. Red Hat point releases are also not supported for 10 years (you follow along the point releases on the major version for that length of support). It seems to be pretty much the same on FreeBSD. However, the support for major versions is also shorter. E.g. 8.0 was released in 2009, and 8.x is not supported anymore.

crest 12y ago
FreeBSD 8.4 is supported until 2015-06-30. FreeBSD 8.0 was released on 2009-11-25. Odd numbered minor releases and the last minor releases in a major release are supported for 2 years. Migration two newer minor releases of the same major release preserves binary compatibility. There are ports to preserve binary compatibility with previous major releases. Why would want to run 10 year old binaries if a compatible and improved version exists? Run FreeBSD 8.4 and 10.1 on the same hardware and perform a bunch of benchmarks. Even if none of the new features are relevant to you it offers improved performance.
- danieldk 12y ago
  FreeBSD 8.4 is supported until 2015-06-30. FreeBSD 8.0 was released on 2009-11-25. Odd numbered minor releases and the last minor releases in a major release are supported for 2 years. Sorry, I misread the release table. Then, that is pretty impressive, 6 years for a major release! Why would want to run 10 year old binaries if a compatible and improved version exists? Personally, I don't but in many enterprises a new stable release is often only introduced after a 1-3 years. Then it is to expensive if support runs out quickly. When I was involved with CentOS (ca. CentOS 4 & 5) era, there were still many companies running 2.1 and 3.
- rsync 12y ago
  Yes, that is what it says on paper, but I would submit that both 5.x and 7x were essentially EOL the day they came out. Since 4.x there has been a huge focus on the upcoming releases. By the time the x.0 release comes out, all of the cool kids are working hard on x+1 and x+2 - you saw this especially during 8.0 and 8.1 when a lot of mailing list chatter from core developers revolved around nitty gritty details of 10.x. By the time 7.1 came out (for instance) all new driver bug fixes, etc., stopped being applied to the 7 tree and the answer to every question was "it will be in (8/9)". I do appreciate the fact that an 8.4 was created - it's a step in the right direction and a sign of some real understanding of the problems the end users are having with an inability to invest in FreeBSD and make long-term plans with their own platforms. However, I still would like to see a release ... any release ... get to x.10 or x.11 - like 4 did. I even committed $50k to that end a few years ago (although I suppose that's small fries these days :) If people would like to know my specific critiques, there was a long mailing list discussion in 2012: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037294.html http://lists.freebsd.org/pipermail/freebsd-hackers/2012-Janu...
  - kev009 12y ago
    I expect this would be a big deal for the appliance manufacturers (think Juniper, NetApp, Isilon) that need to support long life cycles . I'd also expect those type of companies to pony up for long term support (and they do, at least internally, with staff developers and trees) But in an ops context, why not simply install compat<version> packages? Or worst case, run the obsolete apps in a <version> jail? With containers, I think we're rapidly approaching a point where the software that touches the hardware can evolve faster than the libraries/support around applications, and this quite frankly is awesome!
feld 12y ago
I don't think that's entirely true. I've been told you can get support for older RedHat point releases but you have to pay RedHat an obscene amount of money.