Re: Debian LTS?
On Thu, Oct 6, 2011 at 12:24 AM, Noah Meyerhans <firstname.lastname@example.org> wrote:
> On Wed, Oct 05, 2011 at 09:15:18PM +0100, Bart Swedrowski wrote:
>> I have been "forced" to use switch from Debian to RedHat and clones
>> in my last job specifically because usual life time of a server was
>> 3.5 - 4 years.
> Same here. In my exerience, large sites typically use a 3-5 year
> lifetime for hardware, and the OS is never upgraded once a host goes
> into production. If you've got thousands of hosts, all of which are
> doing just fine in terms of software functionality and are in a static,
> generally unchanging production configuration, there's very little
> benefit to performing an OS upgrade.
In my experience: if a company does not perform operative system
upgrades, the company does not have more than 5 years and does not
understand how open source, and in special linux kernel, works.
You can migrate data between service versions or environments, have
rollbacks, backups and etc.
The monolitic "one server, all services, never upgrade" maybe just an
architecture issue, totally outside of the Debian issues.
If Debian needs to match company rules, to be "in the edge like the
others", lets start by do not purge firmwares.
> On the other hand, many of these large environments don't see a lot of
> value in Debian's major contributions. The Social Contract is not
> typically not a very important consideration when large enterprises
> choose a software platform. The OS environments are pretty strictly
> defined and generally don't change much, so they don't see a lot of
> value in Debian's package management tools.
> Canonical and Redhat both need to earn money, and it's worth a lot of
> money to big companies to have an LTS software platform. Debian doesn't
> need money, and (afaict) there's not a particularly large community of
> volunteers interested in the difficult task of maintaining an LTS
> platform. It's a generally thankless task that involves working on
> ancient versions of packages, often coming up with new fixes to old bugs
> so you can maintain existing interfaces, when the obvious fix would
> involve changing the behavior of a program or a library's API or some
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> -----END PGP SIGNATURE-----