Debian Sarge Coming Soon

daria42 writes "The long awaited 3.1 release of the Debian GNU/Linux distribution - codenamed Sarge - is due out next week on the 6th of June, according to the project's release team. Around 50 release-critical bugs remain to be fixed. One more update to Debian 3.0 will also be released prior to that date. And it's about time - the last formal release was back in July 2002. Debian 3.0 will probably be supported with security patches for another 12 months."

And the point is?

[coolsva]

Not to troll, but what is the main advantage of sarge vis-a-vis other distributions based on the debian unstable/testing tree (like knoppix/ubunto and a dozen other main ones)

good stuff...

[professorhojo]

Releasing Sarge will be hugely cathartic for Debian, it will get a monkey off of their back so they can move forward on the reduced platform list.

People need to remember that Debian is not trying to be Fedora or Gentoo. There are already numerous distros providing the bleeding edge with various degrees of config assistance/packaging options etc. Debian is offering the "must work" (as opposed to "just work" which seems less mission-critical) alternative, and its useful for someone to perform the heavy testing and fixing they do.

I am satisfied that the Debian crowd is making moves to keep itself relevant with a new team leader, a new set of targets, and a release in the bag. Having been burned in the past by the "maybe it works" distros in the past, I will be seriously considering their future offerings.

On a slightly related tangent: just who do those Ubuntu guys think they are? They are releasing a Distro that claims to be Debian compatible, and yet their packages are not 3.5 years old. What's worse, they seem to be a popular distro. If this doesn't stop, we might have to cooperate with someone else in the Debian space! We might end up like (gasp!) Fedora, and have to deal with multiple repositories in a Bazaar-like fashion instead of doing things in the Cathedral-like fashion that we are accustomed to. Where will it all end?

Child Distro Effect?

[Blahbooboo3]

Could someone tell me how long until this trickles into the debian based distros?

Thanks!

Recently announced, Munich has choosen Debian

[MarkEst1973]

Munich, if you didn't know, is making a much publicized switch from Windows NT to Linux. They recently (April 18, 2005) announced to use a customized distribution of Debian for the 14,000 city desktops.

You can read more about it here: Munich chooses Debian [zdnet.com.au]

Re:Starting the book now...

[gowen]

TeX really does have a release schedule like that. The last major release was v3. That was followed by release 3.1, then 3.14, then 3.141.

The most recent version is 3.14159, as the release numbers are slowly asymptoting toward pi.

OT: coLinux

[AnomalyConcept]

What version of Windows are you using? For me, the coLinux installer (0.6.2) created those for me. I might have told it to, but I had more difficulty getting my firewall to play nicely than configuring the networking.

Re:Recently announced, Munich has choosen Debian

[Wudbaer]

It could still happen in the (for Munich currently perhaps still not too likely case) of a change in local government. While the Social Democrats and Greens who currently rule in Munich are much in favour of the Linux migration, the Christian Democrats who currently are winning out all over Germany are definitely not.

Re:And the point is?

[grumbel]

No, Debians QA process is more like "If there aren't any RC bug reports it gets included", unless there was some major change latly Debian doesn't test each and every package, which for less seldomly used packages means that even a completly non-working one (SEGFAULT at startup) can slip into a stable distribution, not much an issue of x86, but for the other archs there is quite a bit of stuff that will compile, but not work.

Testing before deployment takes time

[DragonHawk]

"It's just a matter of issuing "apt-get dist-upgrade" on the console..."

For individuals who don't have anything major to loose or anything special to worry about, sure. But not for large organizations with a support structure (help desk, local docs, procedures, etc.) that needs to be ramped up to support new changes. And not for anyone doing anything special or mission-critical that needs to test things before deployment. The rule in any production environment is "Test, test, test, and then test some more". You simply cannot just type "apt-get dist-upgrade" (or "yum upgrade" or any other variation on the theme) in the Real World, I'm afraid.

In general, I find that this whole concept (which is a major part of the disipline called "configuration management") appears to be alien to Debian people. When your business/mission is on the line, answers like "Just pull from sid" or "Just apt-get the fix" and so on just don't cut it.

Re:Testing before deployment takes time

[noahm]

For individuals who don't have anything major to loose or anything special to worry about, sure. But not for large organizations with a support structure (help desk, local docs, procedures, etc.) that needs to be ramped up to support new changes. And not for anyone doing anything special or mission-critical that needs to test things before deployment. The rule in any production environment is "Test, test, test, and then test some more". You simply cannot just type "apt-get dist-upgrade" (or "yum upgrade" or any other variation on the theme) in the Real World, I'm afraid.

Yay, another believer! I've been using Debian for ~8 years now, and have been combating the idea that 'apt-get dist-upgrade' between versions is transparent and that backports or mixed stable/unstable systems are a good idea for much of that time.

As a sysadmin at a large Debian site, I need to know, for example, that postgresql is going to come up and serve the right data to the right people after an upgrade (and not do it an order of magnitude slower, as was the case on one system we upgraded recently). I also need to know that the commercial software that the users depend on, such as Matlab, Sun's JDK, and Allegro Common Lisp will all still work after an upgrade. I need to make sure that an upgrade of the mail server is going to continue routing all the mail to the right places, store it as expected, and allow the users to access it via the supported mechanisms. I need to be sure that the NFS and AFS file servers are going to continue serving their 10s of terabytes of mission-critical data to the users. These are all Debian systems, but none of them will get an 'apt-get dist-upgrade' without thorough testing.

In preparation for the sarge release, I've been using user-mode linux to test the upgrades of our critical servers. It's pretty easy to build a system that looks just like an existing system and then test the upgrade. When I'm done, I can simply delete or archive the filesystem image and move on to the next server. Thus far things are mostly going well, but there have definitely been some situations that made me really glad I wasn't working on a production machine at the time!

noah