[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian failed



On Thu, Dec 15, 2022 at 06:25:35AM -0500, Dan Ritter wrote:
> hw wrote: 
> > On Sat, 2022-12-10 at 23:05 -0600, David Wright wrote:
> > > On Sun 11 Dec 2022 at 04:39:02 (+0100), hw wrote:
> > > > 
> > > > How can Debian be so old?
> > > 
> > > Maturity takes a little ageing.
> > 
> > Then Debian needs to figure out how to become sufficiently mature
> > without becoming outdated.
> > 

Further to what Dan said:

A release cycle starts as soon as a new stable release is made.
What was testing becomes stable: a new testing is forked.

The stable release remains supported and bug fixed for an average of three
years. Security fixes are fixed, some fixes are backported, some fast-moving
packages - like Firefox - get updated in the course of the release as 
upstream removes support for older versions.

Testing has two or so years to develop on average before release. The final
choice of kernel is normally one that is LTS by the upstream kernel 
developers.

Nvidia and other video card manufacturers: most require workarounds.
Nvidia requires more than most - that's the way of it. The Nouveau
drivers are improving but many people want and need the proprietary
drivers. That carries with it the need to use dkms, potentially, and to
sacrifice secure boot.

We do provide more up to date kernels in debian-backports and more up to date
firmware where we can. 

Stability _is_ paramount: that's why Stable changes relatively rarely and
almost always to provide major fixes (or to remove packages we can no longer
support for whatever reason).

Testing is testing - and should always be installable.

Sid is permanently unstable - is not intended as a current release version:
if it breaks, you get to keep both pieces :) Unless you are experienced and
can fix package conflicts / groups of packages being uninstallable for a while
no one should contemplate daily use of Sid.

Codenames are good: they follow the release from testing -> stable -> 
oldstable -> oldoldstable. using the code names means that you don't 
get nasty surprises round release day as things slip under you.

There are always trade-offs: there's a reason that Linux takes longer
to support brand new hardware than Windows, potentially. Linux allows
you to use older hardware for longer in many cases.

With every good wish as ever,

Andy Cater

> > How is this working anyway?  Debian waits like 2 years or longer to
> > become mature while the rest of the world has already moved on to more
> > recent (versions of the same) software which has the bugs now fixed
> > Debian is still struggling with?  Or is Debian fixing the bugs in
> > outdated versions in order to continue to use those for some reason?
> 
> If an upstream project makes changes that fix bugs, and the bugs
> are important, Debian will apply those changes if possible. If
> the upstream project makes those bug-fix changes in a way which
> changes other behaviors, Debian will avoid those changes.
> 
> 
> That's "stable". You should be able to build on it without
> having APIs or command line arguments change underneath you.
> 
> 
> Meanwhile, a new stable version is being created, and exposed to
> people who want to work on it in two releases:
> 
> unstable is not a real release. It's a repository to hold
> packages that are being worked on. Every so often, someone
> decides to rely on a package in unstable because it has a
> feature that they want. They often regret it. unstable is for
> developers, and it is not for their main machine.
> 
> testing is almost a real release, but it is never quite there
> except in the months leading up to it being frozen as the new
> stable. testing has packages that have met a minimal set of
> criteria to be promoted out of unstable. It has not been tested,
> it is in the process of testing.
> 
> If you can stand the occasional failure, a person might use
> testing for some things. It's not a good idea to run production
> on it.
> 
> -dsr-
> 


Reply to: