Interview with Debian Project Leader

brunotorres writes "I've interviewed Martin Michlmayr, Debian project leader. In this interview we talked about the upcoming Debian release, Sarge. An excerpt: 'We heard for years that Debian is hard to install and the old installer wasn't very easy to maintain or advance, so we we decided to throw the installer away and start from scratch. The new installer is much more modular, which makes it easier to maintain and extend.'" Reader ron_ivi points out that new Debian/Hurd CDs are available. Newsforge and Slashdot are both part of OSTG.

Comments

I like the debian installer.

[Anonymous Coward]

The only system out of about a dozen (including about 2/3 headless systems, with no monitor) that I've installed Debian, the only one that didn't work was VirtualPC-with-over-500MB-of-Ram.

All the other architectures I tried (Suns, _old_ x86s, _new_ x86s) worked great.

I really reall really like the fact that the minimal install and the installer itself doesn't require the X-windows bloat.

What?

[northcat]

So now, is HURD so unimportant to slashdot that news related to it is just grouped under some other news? The same slashdot that carries a front page story about even release candidates of the Linux kernel?

Re:What?

[Anonymous Coward]

When has HURD ever been important to _anyone_ except HURD developers?

Re:What?

[MemoryDragon]

Sorry to rant here, but hurd is a nice ongoing research project doomed to fail in the long run.... The reasons, to few developers, not to much interest by the people who initiated the project in the first run as it seems, almost no moving forward, critical things after 10 years not implemented (a decent filesystem etc...) hurd is a nice concept with a partial implementation after 10 years, the time it will reach the finally usable status, Stallman and others will have died of age.

Why Debian over Gentoo?

[bonch]

Well, I wondered the same thing until I tried out Debian and realized you could do interesting things like downgrade packages to previous versions. In general, the install system had features Portage doesn't, until the next version of Portage anyway.

That didn't stop me from happily moving to FreeBSD, however. :)

Re:Why Debian over Gentoo?

[molnarcs]

Well, I don't think so. I had the opportunity to play with gentoo for two months (see this post and this was my experience with it:

To get a usable system, we had to hunt for the description of various use-flags, and some of those descriptions were not exactly helpful: MOTIF= this will install motif on your sytem - well, thank you very much. Had to recompile kdebase to get plugin support for konqi. I was frustrated, while others on gentooforums, after learning that they have to recompile just as we did, began to praise the power of use-flags (I still don't understand how?).

Anyway, seeing that there were 300+ use-flags, and you have to remember at least a few dozen of them and their relationship and effect on your installed packages, I realized that gentoo was not (this was in april-may last year) that different from slackware without swaret. In slack, you had to remember package dependencies, but since repos grouped packages logically, this wasn't that difficult or daunting (nor was it in gentoo), but I still felt that what was referred as dependency-hell is simply exhanged in gentoo with what we may call a use-flag hell. Basically this was the result of portage (or ebuild) maintainers' unwillingness to come up with defaults (read: configure portage for you to the best of their abilities) that would suit 90% of the users (most users want a combination of most functionality + leanest packages). Don't tell me its not possible, because it is, they just don't do it. Moreover (and this bothers me a bit) they advertise this (forcing the user to memorize and spend days configuring use-flags) as a feature.

In a binary distribution, I'd end up with a couple hundred megs worth of QT and KDE anyway, but with Gentoo I can USE="-qt -kde" and eliminate it entirely.

Explain. I don't really understand how the first part of your sentence relates to the second. (I think that if I want debian, or ubuntu or [insert distro here] to be kde-free, I can do it, without use-flags. Hell, I can do it in freebsd, which doesn't have useflags - thankfully, progs present you with an ncurses based options screen if there are multiple build-knobs, so there is no need to learn a list of use-flags or tweak configuration files for days just to get package management working)

Why does every distribution need to reinvent wheel

[Anonymous Coward]

Why does each and every distribution need to reinvent the installer and the package management tools and the portage system and the system layout?

Can't we have just one installer, one package management tool and one portage system that is shared by all the linux distributions, the bsd variants, OS X fink, windows cygwin, the comercial vendors, and all the rest?

I mean really, reinventing a new tool to do something that people have been doing for 30 years is the height of arrogance. And even if they do invent their own package management system, does it only have to run with their own custom portage system? Can we have multiple interfaces to just one portage system that works across all posix systems?

Ideally I should be able to pop in a DVD, and have a single installer come up that lets me mix and match my kernel with my package management system and select what packages I want to install and then have it install them in a known location that is the same as everyone elses in the world.

I should be able to deploy a software package one time and just have it compile and install itself on any unix like system. And work.

All you separate distributions and operating systems need to get off your high horses and share the labor for things that are common between all of you. This is why we don't have unix on every desktop right now. The fragmentation is killing adoption of unix on the desktop.

Re:Wait wait wait....

[EnronHaliburton2004]

I've always thought there should be two versions of linux: bleeding edge, and ignorant housewife editions.

There's a third: A powerful version that is stable. I need to spend my time using Linux to do things for my job, I don't like to spend time debugging the OS.

DHCP?

[cxreg]

Wow, defaulting to DHCP without even asking seems like an awfully annoying idea to me :P

Re:Why does every distribution reinvent the wheel

[flossie]

... because the old square wheels weren't good enough. And the newer triangular wheels weren't much better.

Why does it matter if the wheel is constantly re-invented? No one is forcing you to do the reinvention and you don't have to use the new wheels.

Freedom to tinker is a major part of the driving force behind free software at the moment. As for fragmentation "killing adoption of unix on the desktop" (assuming that you are including GNU/Linux with unix), there are more *nix systems on desktops now than there ever have been previously. Strength through diversity, etc.

Re:Why does every distribution need to reinvent wh

[mccalli]

Can't we have just one installer, one package management tool and one portage system that is shared by all the linux distributions, the bsd variants, OS X fink, windows cygwin, the comercial vendors, and all the rest?

Well, Debian and OS X Fink do share an install system - apt-get. "All the Linux distributions"? Would be nice, but there are a fair few .deb-based ones out there now. RedHat and Cygwin share a system I believe (I'm prepared to be corrected here), because Cygwin was originally has ties to RedHat.

Ideally I should be able to pop in a DVD, and have a single installer come up...

Ah, well you've lost me there already you see. A DVD? I run Debian on a old laptop that hasn't got a CD drive, let alone a DVD. I also run it on a Cobalt RaQ - not even a floppy drive there. A single installer? But on my flashy new hardware I like graphical installs, whereas I would spit blood at anything requiring a graphical install if I was trying to put it onto the Cobalt.

All you separate distributions and operating systems need to get off your high horses and share the labor for things that are common between all of you.

OK. So who gets off whose horse first? I know - let's dump RPM, I always hated it. But hold on, it's used with some of the most popular and commercially supported distros right? So I know, let's dump .deb, after all it's only minority. But hang on, some of the most stable distributions there are use .deb so there must be some merit in it. I know, let's dump RPM...and repeat ad nauseam.

Cheers,
Ian

Refreshing interview

[Anonymous Coward]

It's nice to read an interview from a distro project member where the problems/limitations of the distro, (such as the long release cycle), are openly admitted. All too often distro maintainers (and users) make excuses for current limitations in their distros and stubbornly refuse to address them in a rational manner.

Re:Refreshing interview

[Anonymous Coward]

In my experience it's mostly the users that are so religious about their distribution that they would rather kill you than acknowledge that there might be a problem.

Try to talk with some gentoo users about an installer or with debian users about the long release cycle and you'll see what I mean.

On the other hand, I think developers are much more rational about their distribution. Case in point, gentoo is going to get an installer and debian will address the long release cycle.

Re:Get your distro upgrade procedures sorted out!!

[Dionysus]

1) Sarge hasn't been released yet, so upgraded from Woody to Sarge is not guaranteed to work *yet*
2) Gnome 2.8 was just recently moved into Sarge, so some unstability was to be expected.

You just chose a really unfortunate time to do the upgrade (when I went from Woody to Sarge, Sarge had been relatively stable for a couple of weeks, as in no major packages had been moved into Sarge for awhile)

Getting bigger?

[plasticsquirrel]

8700 packages for Debian GNU/Linux? Great. New installer? Nice. If I buy a small server, though, I can't even get a stable version that ships with SATA support. Debian may be a wonderful community project, but it is becoming too bloated to move forward like it used to.

Re:Getting bigger?

[Chandon Seldon]

This is nothing new, and not a real problem. Debian Stable has always been a step or two behind the hardware curve.

If you want to run a server on Debian you are almost assuredly capible of getting it installed and working with a custom kernel on SATA drives.

Re:Why yet another new installer?

[bogie]

That is what I was going to answer because its true.Anaconda doesn't run on every arch. But why should x86 users, ie 80%+ of Debian users have to suffer without a great installer like Anaconda just so somebody using some obsure arch has the same aweful install experience(yes I know the installer has improved). Cater to your base which is x86. Let the rest get by with a lesser installer. They have till now and won't go away just because x86 as usual gets all of the goodies.

That or continue to watch as all of your users flee to distros like Ubuntu.

Not bad, but...

[Mock]

The new installer is not too bad, but once again it goes for far too much complexity and ambiguity.

An example:

For the X Window System graphical user interface to operate correctly, it is necessary to select a video card driver for the X server.

Drivers are typically named for the video card or chipset manufacturer, or for a specific model or family of chipsets.

Select the desired X server driver.

siliconmotion
sis
tdfx
tgz
trident
tseng
v esa

Here we have the typical video driver selection screen. Can you seriously expect anyone who wasn't weaned with a transistorized soother to understand this screen?

Who but the eternal geek will know that VESA is only used for ancient systems or vmware, or that trident means the old, ancient trident chipset, and probably not the one that could show up in their laptop? - actually I don't even know myself on this one. I'd just have to try a bunch of installs to see, something a user should not have to do.

A little description beside each cryptic 4-5 letter identifier would be EXTREMELY helpful here.
Better yet would be some kind of auto-detection mechanism for the most common modern cards like other distros do.

Debian is not the only offender in this category.

Here's my favorite:

Please choose a method for selecting your monitor characteristics:

Simple
Medium
Advanced

This is priceless.
What the hell is Simple, or Medium, or Advanced? Who's going to know what method will get their windowing environment working properly? (and really, that's all the user wants anyway)

Debian seriously needs a real user-interface designer to do their installer. So long as it's done by geeks, it will continue to be useable only by geeks. The folks at debian are assuming too much arcane knowledge upon their users, and because of that, they will continue to alienate the majority of users right from the outset.

Re:Why does every distribution need to reinvent wh

[Phleg]

Why does each and every distribution need to reinvent the installer and the package management tools and the portage system and the system layout?

Debian is "reinventing" the installer, because it needed to be. The Debian project needed an installer that could be run on any of the dozen or so architectures it supports. Not only that, but they did an excellent job of separating the installer from the frontend it uses. Now that the installer is near completion, it shouldn't be hard to create a GUI frontend to the install scripts.

Not to mention, your question can be answered with the same answer that is used to argue why we shouldn't all just use one operating system, one brand of processor, and one computer manufacturer.

Re:Why does every distribution need to reinvent wh

[fucksl4shd0t]

RedHat and Cygwin share a system I believe (I'm prepared to be corrected here), because Cygwin was originally has ties to RedHat.

Ok. Cygwin has the *worst* package management ever, but one of the best front-ends. Go figure.

A package in Cygwin is a tarball, basically run from /. So you can download a Cygwin package with, say, your web browser, cd / in your cygwin install, tar -xzvf *thefile*, and that installs it. It's crap, it's nothing but crap. Dependency resolution? Don't know how they do it, really, unless the database they use to store packages also contains dependency information.

RPM, on the other hand, stores dependency information and some other useful metadata in the package itself. So theoretically an rpm *can* be installed on a non-rpm-based distribution, provided the rpm program (a perl script, of all things) is available, as well as the other tools needed (tar, a few others). Practically, it doesn't work out so well, and I wouldn't really try ot install an rpm into a non-rpm-based system, and there's even incompatibility between rpm-based systems, but it's not the fault of the package manager, it's the fault of the fools that arranged the system in incompatible ways, and for what? Vendor lock-in? Anyway, the problems come in with some of the optional flags. Some rpms can be installed anywhere if you pass a flag to rpm, but some rpms (anything built by Mandrake, one of my pet peeves with them) *must* be installed where they specify. Furthermore, some package maintainers specify specific versions of dependencies that they really don't need to specify, making it so that their package can only install on a narrow range of distributions that came out when that particular dependency was standard at that version. Luckily, most package maintainers don't do that, myself for example. When I put dependencies on pyAlarm, I just specified "pyao" and "pymad", no versions. So it would install if you had them, or if you used urpmi you could install the dependencies too, and it worked fine. (Granted, there were no doubt numerous bugs on numerous other systems that I never heard about, the new system in pyAlarm's much better, because it does its own dependency checking at runtime, but that's not an optimal solution for every program)

Anyway, Cygwin wasn't developed by RedHat. It was developed by someone else (I forget who), and RedHat acquired them. So now Cygwin is owned by RedHat, where previously it wasn't.