Sarge is coming [LWN.net]

August 11, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

Sarge is, finally, approaching. Last week, Steve Langasek announced a proposed timeline for Sarge and that Anthony Towns had stepped down as release manager for Debian. Langasek and Colin Watson are filling the post for the Sarge release. According to Watson's follow-up on Saturday, the release target for Sarge is now September 19. Joey Hess also announced release candidate 1 of the new Debian-Installer for Sarge on Saturday.

With the release so close at hand, we decided to take a look at the state of Sarge. We touched base with Langasek on the status of the release, and also asked Towns for comment on his decision to step down. In Langasek's announcement, he alluded to "the recrimination and hostility towards some of our most dedicated developers" as a possible reason for Towns' departure from the release manager post. Towns declined to elaborate on his decision to step down from the release manager position, but said that Sarge is in good hands:

I've got complete confidence that Colin and Steve can do a better job getting sarge out than I could, and are doing so. They might think differently, but if so, the resolution to that little quandary is quite simple: they're wrong. :)

We also asked Langasek about the statement, and whether he feels that the internal conflicts in Debian have gotten worse.

For my part, I'm well aware that there's always a certain amount of off-topic digression and conflict on the mailing lists -- this is nothing new in Debian, it's part and parcel of the kind of rough-and-tumble development model that's always been in effect in this community. One thing that *has* changed recently, however, is that the General Resolution process... has become unstuck in the past year, after having been held up for quite some time by a committee charged with fixing some subtle bugs in our constitution. Suddenly, the GR process seems like a good way to address lots of problems in the project, and lots of changes are being proposed without necessarily considering the full effects in the context of Debian, or sometimes without much consideration of whether this is something that *can* be legislated in Debian.

It's also true that as the project has grown, it has tended to become more politicized as it's harder for everyone to know everyone else personally. I don't think this is inevitable, though; it's simply something we need to learn to deal with as we grow. Since Debian has essentially been growing for its entire existence, we have a fair amount of experience with learning to address growing pains.

In any case, I definitely don't think AJ's decision represents any sort of crisis in Debian. The release manager's job is a hard one even when everything seems to be going right, so it's perfectly understandable that he would decide to step down.

With that unpleasant topic behind us, we also asked Langasek about the release schedule, and whether the schedule was realistic.

The important message to bring away from the announced release schedule is that we're close enough now to being able to release that it's time for developers to change focus. The schedule may slip a few days here or there, but the truth is that's something we have to contend with no matter how aggressive our proposed schedule is. So we might as well be ambitious!

Our brief tests of the RC1 of the Debian installer were quite positive. The installer is still a text-based system, but consists of a fairly easy set of choices for the average Linux user to follow. We tested RC1 on a dual-PIII Xeon system, and tried out both the normal and "expert" installer modes. Users have the choice of installing the 2.4 or 2.6 kernel in either mode. The "expert" mode is largely unnecessary unless one wants (or needs) to dabble more directly with the kernel modules that are loaded or if one wishes to experiment with installer modules that are not part of the default installation.

The new installer also offers to partition the disk for the user, no doubt a welcome addition for many Linux users who aren't familiar with disk partitioning. The user has a choice between an all-in-one partition, a separate /home partition, or a multi-user partitioning scheme if they choose to let the installer do the work for them. Both the /home and multi-user schemes provided sane partition layouts on a 40GB disk, using the Ext3 filesystem. We might have chosen more swap space (the installer opted for 512MB on a system with 1GB of RAM), but both partition layouts were quite usable.

The hardware detection worked fine for the test system, though the system admittedly contained a sparse selection of components -- an add-on IDE controller, network card and generic video card, PS/2 keyboard and mouse, no sound card. This writer found it very nice not to have to know which module is appropriate for the system's network card while in the middle of an install.

Users have the option of choosing packages manually, or selecting from seven pre-selected groups of packages like "desktop," "Web server," and "DNS." These can be mixed and matched, so users who want a print server and desktop in one machine can choose both at install time. The desktop set of packages provided both the KDE and GNOME desktops, and a fair selection of desktop apps and games.

There were only two things we didn't like, overall and neither can rightly be considered a bug -- though there is a bug report for our first complaint. Though the machine in question is a dual-CPU machine, neither the normal or expert install gave the option of an SMP-enabled kernel. Though it's not at all difficult to download a suitable SMP kernel (or compile your own) it's an additional step that should be unnecessary.

Likewise, it seems to this writer that OpenSSH should be installed by default on any network-connected system. While not difficult to do after the fact, one would think that including OpenSSH is a no-brainer on almost any Linux system. It is certainly as likely to be used as wget or nano, which are installed by default.

Those are extremely minor grumbles, however. It appears that Sarge is just about ready to make its debut. The schedule is a bit ambitious, but it doesn't seem unrealistic based on our tests of the RC1 of the installer and packages now in testing. Langasek asks that users start banging on the new installer and install manual to help the process along:

Now that the first release candidate of the debian-installer is available, we also need users to help test this new installer, and to also help review the installation manual to check for omissions and accuracy.

We hope to soon have security support available for testing, at which point we will also send out a general call for users to test the upgrade path from woody to sarge.

And, of course, Langasek asks that users report bugs wherever they find them "particularly if they're using testing or unstable." As users are trying out the new Debian installer, they might wish to read the d-i retrospective, which recounts the history of d-i and gives perspective on the work that went into the installer. Langasek says that the work has paid off:

Debian-installer stands head and shoulders above the boot-floppies system we used for woody, and we owe a lot of thanks to the developers responsible for giving us an installer that people can actually be enthusiastic about contributing to. :-)

Indeed, this writer is enthusiastic about the installer as well. Though the old installer was usable enough (as evidenced by the enormous Debian user base), the new installer is much improved. The final Sarge release should do a great deal to help Debian's popularity with newer Linux users.

(Log in to post comments)

SSH?

Posted Aug 12, 2004 5:15 UTC (Thu) by Duncan (guest, #6647) [Link]

Why should SSH be installed by default? How many users are there out
there that have an internet connection, but no desire to connect to their
home computer from another location, or to some other location from home
in "shell" mode? I'd venture there's a lot. If that functionality is
unneeded, why include SSH by default, since every unnecessary inclusion is
one more possible security vuln, and it's JUST this type of person that's
least likely to keep their system updated in terms of security fixes and
the like.

How many folks on the Gentoo lists ask how to connect to their home system
via SSH, saying it "just worked" on <whatever>? We tell them that Gentoo
(which does come with SSH in the system install, tho I don't agree with
that), doesn't turn on such things by default, and they must configure it
to allow X via TCP and remote forwarding. That's a Good Thing (r)! How I
did battle to try and turn off those ports on Mandrake, that /shouldn't/
have been listening AT ALL, as I didn't need nor want remote access
functionality!

Sure, have it /available/ by default, but not /installed/ by default,
unless someone chooses a "remote desktop functionality" package or some
such. Again, it's /just/ the folks who don't need it that are most likely
to fail to update their systems regularly and properly, and therefore the
most likely to get cracked in part due to something they never needed or
asked that it be installed! All it does is waste disk space, increase
complexity, and provide yet another unneeded bit of functionality that
must be kept up to date to keep the system secure.

Duncan

SSH?

Posted Aug 12, 2004 5:45 UTC (Thu) by sjlyall (subscriber, #4151) [Link]

I think what was requested was that ssh be installed, not that the ssh daemon be run by default.

I would suspect that a large number of debian users would want to connect to a remote ssh server from their newly installed machine.

SSH?

Posted Aug 12, 2004 12:56 UTC (Thu) by zonker (subscriber, #7867) [Link]

I think what was requested was that ssh be installed, not that the ssh daemon be run by default.

Yes, that's correct -- though I run sshd on most of my machines, I do not want sshd turned on by default, but I do want it available and I certainly want ssh available at any machine that I'm going to be working at. I probably should have made it a bit clearer in the original article.

SSH -- we love it

Posted Aug 12, 2004 15:17 UTC (Thu) by stuart (subscriber, #623) [Link]

fear not, Gentoo has copied Debian traditions again.

In Debian (well let's say in Woody/Debian 3.0 for clarity):
SSH client is installed...which makes sense
The dameon (as mentioned already) is installed but not started by default.

<troll> Mind you I'd worry more about a Gentoo SSHd -- with all those users who insist on shonky pointless recompilation for some nefarious goal of speed -- who's to say important crypto code will not get miscompiled? </troll>

Stu.

SSH -- we love it

Posted Aug 13, 2004 2:48 UTC (Fri) by dberkholz (subscriber, #23346) [Link]

You say "copied" as if it's a bad thing. You should be proud that Debian's ideas are being used -- it means people think they're good.

SSH -- we love it

Posted Aug 13, 2004 19:38 UTC (Fri) by set (guest, #4788) [Link]

First, the speculation about miscompiled crypto code is almost pure fud;
we arent baking soufles here-- compilation should be deterministic, modulo
flakey hardware or compiler bugs. If you have the former, you arent any
safer running someone elses binary, and if you have the latter, so could
your distributer.
Second, its not about the speed, its about control, customisation, and
integration. Ones goal may be 'speed', in optimizing for a specific
arch, or it may something else, like 'size'. The point is that compiling
from source allows you to make those decisions. (and compiler flags are
just the tip of the iceberg in what you can configure.) Gentoo isnt for
everyone, but if you had to mischaracterize them, it might be more as
control freaks rather than speed freaks;)

SSH?

Posted Aug 12, 2004 23:00 UTC (Thu) by Ross (guest, #4065) [Link]

Then why bundle telnet by default? I don't see these as "remote desktop
functionality" but simple network clients. I could see an argument about
security but it would be simple and transparent for most users if ssh were
not suid by default -- I don't know if that's how Debian ships it. (The
suid part is only needed to emulate rsh... my opinion is that it should just
execute rsh in that case).

Look out world, Sarge is coming

Posted Aug 14, 2004 18:41 UTC (Sat) by a_hippie (guest, #34) [Link]

After reading the last DWN, I decided to download the installer and give
it another shakedown. Yeah, SSH was not installed, nor was the lovely and
simple FTP client! When I needed to look at a man page, I was surprised
that 'less' was overlooked too. No worries, apt-get install took care of
these issues, but still, reading a man page with 'more' sucks broken glass
through a straw.

When the install was done, I couldn't help wondering about the magic sound
configuration. I didn't see a single mention of sound. Oh, no sound
available at all . . . No sound configuration tools either. Worse yet,
no mention of sound tools at all in the FAQ or the install instructions.
Hmm, perhaps there is opportunity here eh!

After reading/searching the D-I lists, the only mention was the sndconfig.
After installing that (very old) tool, I realized that it was too old to
be worthy of setting up sound. It failed to find the sound chip (that
every other distro finds and sets up hassle free--bugger.)

Last thing I didn't like was the 'ext3' by default. I really hadn't even
noticed until after hitting the ENTER key. I'm going to dig into it again
later when I have faster hardware to perform more tests. Still, very good
to see a simple default of entire drive during that part of the install.

One picky thing I would have preferred was to choose either KDE or Gnome
(a sub-category?). I really only wanted one or the other for this simple
test box.

Finally, I loved the 2.6 kernel. On this old 300MHz k6 boxen, the new
kernel ran circles around the 2.4 kernel I originally had on it.

Good work D-I folks! I can't wait to see rc2.

--
Wishing you well.