I'm honoured that you'd ask. I was, however, intending to sit out this one entirely: People will always have their preferences in distributions, because their criteria are so various, and it's largely a matter of individual taste. Further, people curious about a distribution need only install it and torture-test it for a few weeks, which will give you much more valuable information than will asking its proponents to sing its praises.

Further still, doesn't Karsten have a pretty articulate TWiki entry ("[link|http://twiki.iwethey.org/twiki/bin/view/Main/WhyDebianRocks|WhyDebianRocks]") on this subject?

Also, I largely agree with other people's reasons for liking many distributions. For example, you like SuSE because it's a very polished, smoothly running desktop distribution. I agree. Why would I want to convince you to use something else? Is there something in it for me? I recommend SuSE highly. [link|http://linuxmafia.com/~rick/faq/#distro|See for yourself.]

And: I dunno, don't distribution-advocacy wars seem pretty silly in 2002?

Let me approach the requested topic from a less-wearisome angle than "Prove to me that DebianRulez[tm]." Let's try Real Reasons to Not Like Debian:

1. There are no centralised administration tools. No YaST/YaST2, in other words. Instead, there are maybe a dozen smaller admin tools covering major tasks, generally ncurses-based rather than X11, such as ppp-config, sndconfig (Thank you, Red Hat Software), dpkg-reconfigure for lots of individual packages like XFree86, mdetect for mice, update-rc.d for SysVInit scripts, and so on.

2. You have to go out of your way to find a graphical installer, one that immediately installs a 2.4 kernel, or one that extensively autoprobes your hardware. If you take the path of least resistance, you end up with an ncurses installer that defaults to a 2.2 kernel, and (in the name of conservative operation and ability to succeed with difficult hardware) barely probes your hardware at all. You probably won't find the others unless you think to ask.

3. The bastards keep failing to document the cool stuff -- or it seems that way, anyway. I mentioned this elsewhere: You stumble across a really cool piece of system structure, and wonder why you never heard about this. Hmmpf. There are manpages, but.... Was /etc/alternatives/ or make-kpkg mentioned in the Debian Installation Manual or the Debian Linux User's Guide or the Debian System Administrator's Manual? You can't remember; maybe it wasn't then, and is now. Unnerving, anyway.

4. The emphasis on supporting 11 CPU architectures is a pain. Don't they know that Everyone Who Matters runs i686 and up? Who cares about supporting m68k? I want KDE 3.1RC3 now, for my P4! And what do you mean, "We'll release XFree86 4.2 when it's ready?" I want it now!

5. Some packages have early access only from unofficial apt-get repositories, as opposed to the main Debian package mirrors. Of course, it's not like they're [link|http://apt-get.org/|difficult to find].

6. The punctiliousness about observing other people's licence requirements is a pain, too. I (still a hypothetical "I", not a Rick Moen "I") don't care about whether University of Washington claims they'll sue anyone who distributes modified Pine packages: I get Pine/Pico by default on SuSE; why should I have to do "apt-get build-dep pine; apt-get source --compile pine; dpkg -i *.deb" just to get it on Debian? Who cares about the sanctity of Policy and not getting sued for copyright violation? I want my warez.

Am I piling it on a bit too thick? Sorry about that. The point is that this is a matter of perspective, and that if you either violently disagree with the Debian way of doing things or don't understand the rationale, it can seem annoyingly arbitrary and opaque.

Let's try Bogus Reasons to Not Like Debian:

1. "I don't like the name GNU/Linux". Well, don't use it, then. Take out your $EDITOR_OF_CHOICE and hack it out of /etc/issue. There, it's gone. Similar measures apply elsewhere.

2. "I don't like the politics." Well, don't partake of that. The notion that a free-software-uber-alles political stance is inherent in Debian will come as a huge shock to Xandros, Corel, Libra Computer Systems, Ltd., and Storm Technologies, all of whom chose to build largely proprietary Linux distributions on Debian specifically because Debian's extreme care about observing other people's licence terms means they could reliably build a superset on the Debian core without legal worries.

Debian subjects the licensing of all software (and other content, such as typefaces) to paranoid scrutiny, to determine if it can be included, and in what category. Some software cannot be packaged at all, not even using a patch-and-build-from-source trick such as described for pine (also used for qmail, ezmlm, djbdns, et al.), on account of too-severe licence restrictions. Otherwise, it gets put in one of four bins: "main" is software that's licensed with terms that meet the free/open-source acid test, the [link|http://www.debian.org/social_contract#guidelines|DFSG], which is functionally identical to the [link|http://www.opensource.org/docs/definition_plain.html|Open Source Definition] (which is the DFSG with Debian-specific references removed), and that has dependencies only on other such packages. "non-free" is software that doesn't (i.e., is proprietary), but that can still be lawfully distributed in some form that can be made [link|http://www.debian.org/doc/debian-policy/|Policy]-compliant -- in extreme cases, by patch-and-build. "non-US" is software that for crypto, patent, or other reasons might not be legally exportable from the USA. "contrib" (a terrible name, but just try to think up a less misleading one) is software that is itself DFSG-compliant, but is dependent on at least one other package that isn't.

The point is that, rhetoric from loudmouths notwithstanding, if a proprietary package can be lawfully packaged for Debian at all, and someone has bothered to do so, then it's neither more or less difficult to install and use on Debian than is a DFSG-free one.

3. "I don't like the attitude." Smeg off, technopeasant.^W^W^W Er..., I mean, {shrug}. Only joking -- or maybe not. But the attitude is a strictly optional feature.

P.S.: On the separate but overlapping "GRUB is better than LILO" argument, I have only [link|http://linuxmafia.com/~rick/linux-info/zen-of-lilo|this] to say (also included in the current issue of Linux Gazette, in the Answer Gang column).

Rick Moen
rick@linuxmafia.com

Scott wrote:

Alternatively, I once messed with my boot files before/after reading LILO documentation, shot myself in the foot, and therefore now use a boot manager that allows me to shoot myself in the foot and gracefully recover without rebooting/editing/trying it all again... ;-)

I like that.

The main problem with lilo isn't with lilo intrinsically, but rather with the usual default configuration: If (like most people) you have a lilo.conf that lacks a fallback stanza for a known-good kernel, it's an accident waiting to happen, the first time you experiment with new kernels or with changed boot configurations.

In the worst-case scenario, it's your only computer, one that you dual-boot. You're new to Linux, you've finally mustered up the courage to compile a new kernel, everything seemed to go well, you tried to reboot, and... "LI", followed by a system halt. You're temporarily frozen out of both Linux and your legacy-proprietary OS, until you figure out how to use either a maintenance floppy or a maintenance CD to fix lilo. Which might be easy, except you now have no manpages and no access to /usr/share/doc/*, because your one and only system can't boot.

Whereas, if you're an experienced user, you have a fallback stanza in lilo, and already know how to do "/sbin/lilo -r /mnt" from a floppy well enough to do it in your sleep. Which means messed-up lilo is a trivial problem if you're experienced, but a traumatic catastrophe if you aren't.

Anyhow: The advantage you cite for GRUB amounts to "it can read the filesystem". The attached disadvantage is "it must be able to read the filesystem": (1) If /boot is even slightly corrupted, you may not be able to boot. This wouldn't faze lilo, because at boot-time it operates solely from memorised physical locations of objects, and doesn't read the filesystem at all. (2) Wish to have /boot on a new and fancy filesystem type that GRUB doesn't yet know how to read? Sorry, you can't. Even use of ReiserFS necessitates the "notail" mount option. Omit that on /boot, and you're likely to have serious problems. (3) Because GRUB not only can read the filesystem but also must do so, you can't leave /boot normally unmounted. All of my systems do the latter, as a (admittedly minor) precaution against root-user mishap. (The /etc/fstab entry has a "noauto" option.) I mount /boot only when updating boot files, then umount it again.

So: I have no problem with people preferring GRUB, but they almost invariably are gravitating that way almost entirely because they never used lilo competently.

Rick Moen
rick@linuxmafia.com

Yes, having to reboot a lot of times to test not-quite-working kernels would suck. I've never faced the situation you described. I've had cases where some aspect of my newly compiled kernel was wrong such that it required many recompile cycles to get right, but the kernel was working well enough to support the recompile process. And I've made bonehead errors that rendered the kernel completely unusable (the classics: omit console support; omit support for your HD host adapter), but that took only one fallback reboot, recompile, and reboot to correct.

If I had a non-usable kernel that I was trying to fix through iterative boot-attempt cycles, I'd probably install GRUB for the duration, for the reasons you cited. Or VMware.

But then I'd switch back to lilo when I was done. Not a huge thing, just a Works for Me[tm] one.

Rick Moen
rick@linuxmafia.com