Time to move from Red Hat to Debian?

Posted Nov 6, 2003 12:51 UTC (Thu) by evgeny (subscriber, #774)
Parent article: Time to move from Red Hat to Debian?

> Stability. Debian's release cycle, at an average of about one stable
> release every two years, is slow by any standard. Yet, this conservative
> approach means that the releases are extremely well-tested and
> comparatively bug-free.

It's true, but what's good in the stability if it comes at the expense of a serious feature lacking? And being one-two years behind the mainstream releases of most packages means just that: feature lacking. Whenever one needs a newer PHP/Postgres/SpamAssassin/... the answer is either install them manually (and then what's the point of apt-get and all the greatness behind it) or to move to testing/unstable. At this point one usually hears "Well, Debian/testing is as stable as most other 'stable' distros". I agree mostly, BUT:

(from http://www.debian.org/security/faq)

Q: How is security handled for testing and unstable?

A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release.

Which literally means you'll have to leave with security holes unpatched for an unspecified amount of time - not a pleasant feeling, I'd say. And mixing stable/unstable on the same box is quite a hell of maintenance, given mutually incompatible versions of libc etc (and while running an unstable version of SpamAssassin isn't very risky, an unstable libc probably is).

Time to move from Red Hat to Debian?

Posted Nov 6, 2003 13:47 UTC (Thu) by ladislav (guest, #247) [Link]

the answer is either install them manually (and then what's the point of apt-get and all the greatness behind it) or to move to testing/unstable

There is another option: look for backports to stable. This is one example, (SpamAssassin 2.60 is there) but if your desired package is not listed, you'll be unlucky not to find it with Google. Many of those backports are in fact maintained by the Debian developers themselves.

Of course, this is not an ideal situation either, but if you desperately need a new feature, it will beat the other two options you mentioned.

Time to move from Red Hat to Debian?

Posted Nov 6, 2003 14:09 UTC (Thu) by wookey (guest, #5501) [Link] (3 responses)

You make important points. These are considerations to take into account. There is a fundamental tension between stability (=old) and being up-to-date. Debian at least lets you choose. In practice security updates happen for unstable nearly as fast as they do for stable. They can happen for testing very slowly indeed as they just percolate down from unstable and that can take a while. This is important for those thinking they'll compromise between stable(old) and unstable(new) (and thus pick testing) - testing is a bad idea for a net-facing machine. This could of course be fixed if enough (competent!) people volunteered to be a testing security team - it's just manpower (old-stable, stable, unstable * 11 architectures is already more than enough security work for the team)

There is a genuine problem with running stable server machines but wanting some packages kept fresher (spamassasin is a particularly good example). You can now mix packages from stable,testing and unstable but things can break if you do this. You can also apt-get the source and recompile the packages for stable but that's work and you can still run into problems if it needs newer things to build.

What I do is use the backports apt repositories maintained by some Debian developers to solve exactly this problem. These provide quickly-updated packages for stable in a reasonably consistent form - apt-get.org lists the repositories. This works for me. I'd like to see the process made more official at some point - it probably will be one day.

All these things provide interesting compromises. Debian's entirely open process gives you various ways of managing them, or even collectively improving things.

Time to move from Red Hat to Debian?

Posted Nov 6, 2003 14:51 UTC (Thu) by mduregon (subscriber, #3792) [Link]

thanks wookey,

this posting of yours has cleared some questions I had in my mind about stable/testing/unstable ...

duri

Time to move from Red Hat to Debian?

Posted Nov 6, 2003 21:40 UTC (Thu) by evgeny (subscriber, #774) [Link]

> There is a fundamental tension between stability (=old) and being up-to-date.

Right, and this tension grows exponentially with the development cycle period. Two years is just too much. Probably it was tolerable a few years ago, but not now, with the fast-growing rate of free software packages (both in number and, as more developers join, feature additions per unit time).

> Debian at least lets you choose.

It lets me choose only between the two limit cases. I want a smoother function ;-)

> In practice security updates happen for unstable nearly as fast as they
> do for stable. They can happen for testing very slowly indeed as they
> just percolate down from unstable and that can take a while. This is
> important for those thinking they'll compromise between stable(old) and
> unstable(new) (and thus pick testing) - testing is a bad idea for a
> net-facing machine.

I realized it, too. But doesn't it defeat the whole idea of "testing" if many potential testers are effectively discouraged from testing (sic!) of server-level networked apps? And which machine is not net-facing nowadays?

> What I do is use the backports apt repositories maintained by some Debian
> developers to solve exactly this problem. These provide quickly-updated
> packages for stable in a reasonably consistent form - apt-get.org lists
> the repositories. This works for me. I'd like to see the process made
> more official at some point - it probably will be one day.

Yes, hopefully.

Time to move from Red Hat to Debian?

Posted Nov 11, 2003 6:38 UTC (Tue) by MLKahnt (guest, #6642) [Link]

I have spoken of this to questions on the Debian-User mailing list, but think of it this way:

Stable: About as current and a bit more frequently updated than MS Windows, but vastly more reliable.

Testing: Usually more current than all but the version shipped in the last week by any other Linux distributions, and while the least secure of the Debian editions, it still puts MS to shame. About equivalent to sitting in a software wholesaler's warehouse, trying everything that comes in.

Unstable: Very current - about equivalent to sitting at the Beta tester's desk for currency of code, but with the polish of software ready to be used by most users. Still more stable than MS Windows.

I've had breakage with Debian when I tried to install Experimental packages for Gnome 2, but they are just that - still being tuned and integrated to install properly and consistently. I've had Red Hat up2date install software that left the DSL code trying to execute the configuration files for network access - leaving the system offline. I've read reports of breakage with not perfect installation scripts in Debian Unstable, but by the time it reaches Testing, all but the most obscure problems are caught.

If security is a concern - a recently discovered worm unveiling an unknown exploit and this being the patch to seal the hole - it is rare for a Testing user to not be able to move to the Unstable edition of the program - only occasionally requiring noticeable updates in the recent string of glibc updates. Debian packaging policy, edition pinning and apt will resolve which packages must be updated, and what must be removed in the process. Alternately, it is always possible to grab the fixed unstable source and build it against Testing as a Debian package, and install that. Sure, on Windows you wouldn't do that, but on Windows, you wouldn't have the fix that quickly.

Debian needs a level between "testing" and "stable"

Posted Nov 6, 2003 19:45 UTC (Thu) by dwheeler (guest, #1216) [Link] (1 responses)

Debian has three levels: "Stable" (aka "obsolete"), "testing" ("needs to be tested"), and "unstable" ("just got the code patches"). Okay, those parenthetical comments are somewhat unfair, but I think they illustrate the problem. Many server users will find "stable" exactly what they want, but for many desktop users, "stable" is far too obsolete, yet "testing" hasn't undergone any significant system testing.

In my mind, Debian needs a level between "stable" and "testing"; let's call it "ready". This "ready" level would take the "testing" version and run the system through a number of regression tests and uses of the system as a whole (say for a more intensive 1-month period before release). This "ready" level would be released every 6-9 months, with patches as necessary.

I'm interested in Debian, but its poor initial installation approach is a problem. But even after I get it installed, it simply doesn't have a level I want. The old Red Hat Linux did do this. I think that the Debian community could do this without fundamentally destroying their community.

Debian needs a level between "testing" and "stable"

Posted Nov 6, 2003 22:25 UTC (Thu) by evgeny (subscriber, #774) [Link]

> Many server users will find "stable" exactly what they want, but for many
> desktop users, "stable" is far too obsolete

Well, I believe "stable" is far too obsolete also for many server uses - unless the server is supposed to do some very archaic tasks like serving static HTML content or providing SMB services to Win95 clients.

> In my mind, Debian needs a level between "stable" and "testing"; let's call
> it "ready". This "ready" level would take the "testing" version and run the
> system through a number of regression tests and uses of the system as a
> whole (say for a more intensive 1-month period before release). This
> "ready" level would be released every 6-9 months, with patches as necessary.

I don't know. Regression tests are a great thing anyway, but IMHO, it's the security policy (or a lack thereof) that diverges potential testers from "testing".

> I'm interested in Debian, but its poor initial installation approach is a problem.

Hmm. Actually, this is what bothered me the least. Of course, having started with SLS back in 1993, I'm not very picky about graphical installers ;-). In fact, I installed Debian on one of my servers that was running a Slackware distro without disturbing the services, in a chrooted environment. Then rebooted, noticed some sharp edges, rebooted back into slack, fixed the problems (again, in chroot), repeated it once or twice more, and was done. The total downtime was around 15 minutes or so.

> But even after I get it installed, it simply doesn't have a level I want.

Level of what? I personally got used to it quite quickly. Probably, because I met an old friend of mine - apt-get (I used it on RH boxes prior to it -;)).