Interview with Debian Project Leader 287
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.
I like the debian installer. (Score:5, Insightful)
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? (Score:5, Insightful)
Why Debian over Gentoo? (Score:3, Insightful)
That didn't stop me from happily moving to FreeBSD, however.
Why does every distribution need to reinvent wheel (Score:4, Insightful)
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:What? (Score:3, Insightful)
Re:What? (Score:3, Insightful)
Re:Wait wait wait.... (Score:4, Insightful)
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? (Score:1, Insightful)
Re:Why does every distribution reinvent the wheel (Score:3, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Insightful)
Re:Get your distro upgrade procedures sorted out!! (Score:4, Insightful)
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)
Re:Refreshing interview (Score:1, Insightful)
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.
Getting bigger? (Score:2, Insightful)
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? (Score:3, Insightful)
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? (Score:4, Insightful)
That or continue to watch as all of your users flee to distros like Ubuntu.
Not bad, but... (Score:5, Insightful)
An example:
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:
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 Debian over Gentoo? (Score:3, Insightful)
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)
Re:Why does every distribution need to reinvent wh (Score:3, Insightful)
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 (Score:3, Insightful)
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.