User: Password:
|
|
Subscribe / Log in / New account

Grover: Fedora for short-lifespan server instances

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 5:21 UTC (Wed) by rahulsundaram (subscriber, #21946)
In reply to: Grover: Fedora for short-lifespan server instances by dlang
Parent article: Grover: Fedora for short-lifespan server instances

You got some details wrong.

https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#...

So, you don't have to necessarily upgrade every release. Every *other* release would be ok since say Fedora 17 would be maintained till Fedora 19 is released and you can afford to skip Fedora 18.

Ubuntu (not LTS) schedule doesn't allow for that and LTS is supported for 5 years while RHEL is supported for 7 to 10 years.


(Log in to post comments)

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 5:33 UTC (Wed) by dlang (subscriber, #313) [Link]

since it takes time to test a new version and roll it out, you need to have the support for the old version extend at least a couple months past the release of the new version.

So I stand by my statement that 12 months of support with 6 month releases means that you have to upgrade every release to remain supported.

Ubuntu LTS with 2year release cycle and 5 years of support allows you to skip releases there as well. But I would actually argue against doing so, there are enough new features over two years, and enough bugfixes (most of which are not going to be backported, to Ubuntu or RHEL) that after two years or so you really should upgrade.

RHEL being supported for 7-10 years is a bug, not a feature as far as I'm concerned :-)

It allows people to stay so far behind that when the support finally does run out they have probably had close to complete turnover of their staff (very possibly a couple of times) and so end up without anyone around who knows how the apps/systems were actually built. This puts them in a real bind when they are forced to upgrade.

Besides, I just don't believe that any company has the resources to properly backport all the bugfixes over that much time. Linux development is just too rapid.

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 6:16 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

The maintenance schedule is still approx 13 months or more depending release cycle and not a fixed 12 despite whatever you claim. How long it takes to test a new release depends on when you start testing and what you are going to use it for. One could test it in the time between say beta and final release using the test candidates and deploy it pretty much right after a new release since only blocker bugs are fixed during this time. Even some enterprise customers do this with EL.

Red Hat's lifecyle was extended to support paying customers and reach parity with the competition and can hardly be called a bug considering how many years it takes for some certifications. Have you looked at how long Windows on the server is support or Solaris is supported? Also Red Hat doesn't promise to backport all bugfixes. Instead the support progressively gets confined according to https://access.redhat.com/support/policy/updates/errata/. So the last point doesn't apply.

Grover: Fedora for short-lifespan server instances

Posted Jun 6, 2013 20:17 UTC (Thu) by dag- (subscriber, #30207) [Link]

It is a weird idea that it's better to renew your OS every 2 years just because people and knowledge may not be around after 4 years or more. The cost of renewing 4000 Linux systems every 2 years is just enormous. We're not talking about 4000 identical Linux systems, but about 700 different business projects with specific needs and possibly custom software.

In large enterprises a renewal cycle used to be 4 years, which is the lease-time or support time of hardware, with virtualization becoming more the standard rather than the exception, renewal cycles of 8 to 10 years become a possibility.

That is a good thing. If you are concerned about knowledge and people leaving the company, start to document and evaluate documentation. Make this part of the process, rather than an afterthought.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds