Debian Sarge Declared Stable
Despite only a minor increment in the version number (from 3.0 to 3.1), sarge represents a substantial improvement incorporating many new technologies and packages that have been provided by their respective upstream maintainers over the past three years. In terms of included packages, sarge is on a conservative side of things since most packages were in a state of "semi-freeze" several months prior to the release. The default kernel is 2.4.27 (an optional 2.6.8 kernel is also available in the initial GRUB boot menu after installation), the X window system is provided by XFree86 4.3.0, GNOME is at 2.8 and KDE at 3.3.2. While all of these packages are somewhat behind the current stable releases, sarge is still a major upgrade from woody. Just remember that if you had installed the then stable version of Debian just two weeks ago, your system would be running kernel 2.2.20 and GNOME 1.4!
Debian 3.1 has broken a number of interesting records. With a total of 16,792 individual DEB packages, it is, without a doubt, the largest Linux distribution release ever produced. Its source code comes on no fewer than fifteen 650 MB compact discs. If one were to download all CD images for all 11 supported architectures, plus the images for the unofficial AMD64 port, and source code, this would amount to a total of 177 compact discs, or over 105 GB of data! No wonder it took almost three years to put it all together! Another interesting tidbit: the official release announcement was simultaneously published in 18 different languages, while the comprehensive 33-page release notes are available in 15 different languages. The installation of Debian can now be accomplished in one of the 43 available languages, including some obscure ones, such as Galician or Welsh. All this clearly demonstrates that a well-organized community of volunteer developers and contributors can often accomplish more than a large commercial company employing dozens of well-paid software engineers!
Besides package upgrades, probably the most noticeable improvement in sarge is the brand new Debian Installer. Gone are the days when one had to navigate the unintuitive interface of "dselect" to select packages to install. Instead, the installer makes some intelligent partitioning and package selection guesses based on a preferred "scheme" as chosen by the user. As an example, selecting "workstation" as the preferred scheme, the installer would create separate partitions for /usr, /var, /tmp and /home, then install GNOME, KDE and many development packages. On the other hand, choosing "desktop" as the preferred scheme would result in a root partition with only one separate partition for /home, plus GNOME and KDE, and without the development packages. The available file systems include ext3, JFS, ReiserFS and XFS, while GRUB has replaced LILO as the default boot loader. The new installer also comes with a hardware auto-detection module enabled by default, although first reports indicate that these are not as powerful and reliable as the ones found in most other major distributions.
Sarge supports 11 processor architectures, which is the same as woody. One interesting omission is the increasingly popular AMD64 platform, which has been in development for some time, but has not been included in the main Debian archive due to disk space limitations. Nevertheless, the AMD64 edition of Debian sarge was released as an "unofficial" port, complete with the full package tree, CD and DVD images, as well as support provided by the Debian Security Team throughout the lifetime of sarge. Despite its "unofficial" status, the AMD64 port has been able to keep pace with the main Debian archive and the debian-amd64 mailing list is now the second most active among the ports, only slightly behind the debian-powerpc list.
Not everything went well with the release. An oversight while building the
sarge ISO images caused that the sources.list entry for security updates
pointed to the "testing" instead of the "stable" branch. This easily
rectifiable problem only affected users installing from full CD or DVD
images, which meant that these had to be rebuilt under a new version number
- 3.1r0a. However, there was also a much more serious problem - a complete
breakdown of the sarge security update infrastructure right after the
release: "So, it looks like we'll be without security updates for
quite a while,
" reported Martin Schultze in his web blog.
Now that sarge is out of the bag, what's next? Naturally, the development
continues unabated in the unstable and testing branches, the latter of
which has now been renamed to "etch". Etch will eventually become the new
stable release. In the meanwhile, the unstable branch has already received
a large number of new package upgrades from the experimental branch,
including upgrades to some of the important base packages, such as Perl.
GNOME 2.10 has also been moved to unstable. Next, we will slowly start
seeing major upgrades to glibc and GCC 4.x, as well as a big migration to
apt 0.6 with its newly added support for cryptographic verification of the
origin of packages. XFree86 will be replaced with X.Org and KDE should also
be updated to 3.4.x in the not too distant future.
Index entries for this article | |
---|---|
GuestArticles | Bodnar, Ladislav |
Posted Jun 16, 2005 2:54 UTC (Thu)
by joey (guest, #328)
[Link] (1 responses)
No, a 2.6.8 kernel is available as a boot option for the installer. It's also the default on several architectures (powerpc, amd64, hppa). Sure, you can choose to install two kernels and get a choice in the resulting grub boot menu, but that is not default behavior.
> the installer makes some intelligent partitioning and package
No, partitioning schemes and software installation tasks are not connected, and do not influence one another at all. Although I hope the installer does begin to connect them post sarge.
> The new installer also comes with a hardware auto-detection
Despite, oddly enough, being nearly identical to the one used to install Ubuntu, which LWN has glowingly reviewed in the past.
Posted Jun 17, 2005 1:15 UTC (Fri)
by ladislav (guest, #247)
[Link]
Posted Jun 16, 2005 16:29 UTC (Thu)
by davidw (guest, #947)
[Link] (2 responses)
export LD_ASSUME_KERNEL=2.4.1
Posted Jun 18, 2005 13:00 UTC (Sat)
by debacle (subscriber, #7114)
[Link] (1 responses)
Could you please explain what fixes were not included? For some newer
applications NPTL is a must and not supporting NPTL properly is a grave
glibc bug that should be reported.
Posted Jun 18, 2005 19:18 UTC (Sat)
by davidw (guest, #947)
[Link]
http://lists.debian.org/debian-glibc/2005/06/msg00134.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276312
And the original bug I reported against Tk, and our efforts to figure out what the heck was going on:
http://sourceforge.net/tracker/index.php?func=detail&...
Out of curiousity (how much *do* they track Debian? Are they any more responsive?) I think I'm going to check and see if Ubuntu has the same problem, report it there, and see what happens.
Posted Jun 17, 2005 23:00 UTC (Fri)
by alspnost (guest, #2763)
[Link]
I can also inform you that said developer's home now includes 11 of the 12 Debian supported architectures. The missing one is, of course, S/390, since IBM mainframes don't fit very easily in small Cambridge appartments :-)
Anyway, well done guys, looking forward to Etch even more now!
Posted Jun 20, 2005 3:06 UTC (Mon)
by hazelsct (guest, #3659)
[Link]
This issue is now Debian Bug #315004.
This problem entered sarge just days before release. Unlike potato and woody, there were no testing cycles this time. Thanks guys!
> an optional 2.6.8 kernel is also available in the initial GRUB boot corrections
> menu after installation
> selection guesses based on a preferred "scheme" as chosen by the user.
> As an example, selecting "workstation" as the preferred scheme,
> the installer would create separate partitions for /usr, /var, /tmp
> and /home, then install GNOME, KDE and many development packages. On
> the other hand, choosing "desktop" as the preferred scheme would
> result in a root partition with only one separate partition for
> /home, plus GNOME and KDE, and without the development packages.
> module enabled by default, although first reports indicate that these
> are not as powerful and reliable as the ones found in most other major
> distributions.
No, a 2.6.8 kernel is available as a boot option for the installer. It's also the default on several architectures (powerpc, amd64, hppa). Sure, you can choose to install two kernels and get a choice in the resulting grub boot menu, but that is not default behavior.corrections
You are right. I noticed that the GRUB menu was automatically populated with several other entries of distributions that I had installed on the same machine, including some with the 2.6 kernels, so I wrongly assumed, without looking at the menu very carefully, that a 2.6 kernel was installed by sarge. My mistake - sorry about that.
It seems as if the C library's NTPL implementation hasn't included fixes that have made it into other distributions, so things like Tcl and Java that use threads may have weird, random lockups, something I found out at my own expense after having to delay machines shipping to clients. The fix, luckily, is simple - don't use NPTL on Debian:"Stable"
"Stable"
Unfortunately it's a bug I ran across after the sarge release. Here is the information though:"Stable"
Living in Cambridge (UK), I was fortunate enough to meet several key Debian developers this week, for a combined beer session with our local LUG. It's bizarre to be sitting next to a 'random' guy you've never met, having a drink, and to realise that he was 'the one' that built all the sarge release ISOs, that are now being busily downloaded in every corner of the world.Debian Sarge Declared Stable
The rushed release let another major problem slide in unnoticed: former users of raidtools2 with more than one RAID array suddenly have their arrays switched in unpredictable ways. The old /etc/raidtab is completely ignored by the new mdadm package, and one has the choice of either autodetecting arrays (with the /dev/md* order totally unrelated to raidtab), or not doing so -- in which case none of the arrays are brought up at all. Anyone running a RAID array will have to deal with absence or rearrangement of RAID arrays at the next reboot with zero notice, unless you happened to read all of the mdadm documentation thoroughly between upgrade and reboot and took all necessary action to check the autodetection order in advance. (The debconf information doesn't mention this at all.)"Stable" Part II: RAID confusion