Slashdot Mirror
Interview: Ask the Debian Project Leader
Wichert Akkerman, our interview guest this week, describes himself: "I'm a simple MSc Computer Science student who likes to work on Linux projects. I have been the Debian Project leader since February and that has taken most of my time. Debian is a project to produce a completely free operating system and as such we currently have a GNU/Linux distribution and are working on GNU/HURD as well." So ask away. One question per post, please. Moderators & assorted others will select the 10 - 15 questions we forward to Wichert Tuesday afternoon. His answers will appear Friday.
To what extent are you seeing Corel feeding back these changes to the Debian community? How good for Debian has Corel been, so far?
What's the best way to get involved with the Debian project? Do you have a list of tasks that need to be done along with the required skills?
I ask because that seems to be one barrier keeping more people from helping out various free software projects -- they don't know where to start. If we could point to a list and say "The boot disks need testing; we expect these error messages:" or "The foo package has these ugly functions that need to be rewritten:" it would give us more concrete goals to reach.
--
how to invest, a novice's guide
With the things that have been learned from those attempts, is there likely to be some sort of dselect-ng ?
If you're not part of the solution, you're part of the precipitate.
Now that Qt 2 is free software, under the QPL, will Debian include KDE 2 when it is released, based on Qt 2?
Also, do you feel it is better to keep Linux entirely DSFG free software only, or to include software in some way restricted, such as Pine, Qt 1.x and Netscape?
Since you are working on both Linux (established) and the HURD (experimental), could you please tell what the advantages of using the HURD over Linux would be, once the HURD would near completion?
What are your feelings on RPM vs. dpkg? Would it be better for Debian to add any missing functionality to RPM, and then switch to that? In what way might Debian users benefit from sticking with dpkg over a modified RPM with equivalent functionality? From personal experience, the thing that really stood out in Debian was dselect, but that could sit on top of RPM just as well as it does on dpkg. Presumably the same applies to apt (although I haven't looked at Debian recently enough to know about apt).
"The invisible and the non-existent look very much alike." -- Delos B. McKown
1. Eric Raymond has stated (during a speech, NYC :) that he believes that the Debian project is making it difficult for Linux to adopt a standard packaging system. What do you have to say in response?
2. I'm rather disturbed by the GNU Hurd's Debian-like appearance now. I was hoping for a radically different OS but I was disappointed with seeing a different underlying OS that still looks much like Debian. Does Debian have a legitimate reason for doing this?
3. Now from the GNU Hurd to Debianizing FreeBSD. My only question is: Why? Does this help improve the state of the world or simply help glorify Debian itself? I don't see a practical reason for doing this.
I am trying to understand your motives. Not ridicule them. Thank you for your time.
To my mind, the main problem that Debian has to sort out is its release cycle. It's one thing to have a well-tested distribution by the time it's released, but it's going too far to have packages a year or more out of date still in the current release. What steps are being taken to address this? Or is there an expectation that everyone is happy to use unstable?
11.0010010000111111011010101000100010000101101000
I was looking over the info on the attempt to integrate FreeBSD's kernel, and was shocked to find that the people doing it were using BSD libc! Since glibc was designed with a certian amount of portability in mind, why not port glibc to FreeBSD's kernel? This would seem to be to make the overall port MUCH easier, as the rest of the debian code should be far simpler to port to a different kernel platform, but the same libc....
Debian seems to be getting too big to be managed. (by the user and wakkerman)
There are many packages and they are getting more and more. ("What? There is a new window manager? - Package it!") - I don't think this is the responsibility of a distribution.
A distribution should be the base system to run linux. Every more advanced system should be installed by the unix administrator.
To make it even more worse, packages like netstd get split up in many others and packages which should be split, don't. (Look at tetex-bin. You only need xlib6g because there is xdvi in it. - If you drop xdvi in it's own package you don't have to install xlib6g and xbase on your servers)
As an enthusiastic user of Debian, one of its greatest weaknesses to me has been the apparent "orphaning" of stable releases once they are released. All further development (security updates aside) appears to be done for the new, unstable development version. Even new versions of existing, well defined and stable products are rarely backported into the stable tree, resulting in the stable version of Debian quickly consisting mostly of outdated software.
Is there any provision being made to allow for and support a more aggressive backporting of newly released software in current, stable releases, such as newer versions of xmms, netscape, mozilla, and so forth?
I understand and recognize that some software (e.g. gcc, glibc, X, perl) may affect too many other dependent packages to be supported in both stable and development trees, but other software such as xmms and enlightenment don't fall into that category at all, yet debian packages often are never created to support the current stable release.
The Future of Human Evolution: Autonomy
I've been using Debian for a long time now, and I'd like to contribute back to the project. However, I've been put off by what looks to me like excessive bureaucracy and some infighting among Debian developers. Are there any plans to streamline the process to become a developer/maintainer, and the developer contribution process itself? What about fostering a more civil peer review process?
I started using Linux at home with Debian 1.3, and stayed with it through 2.1. After that though, I switched to TurboLinux (though it might just as well have been RH or SuSE) for two reasons:
1) it seems Debian will forever be compiled i486,
and thus never benefit from the oft-huge speed increase of egcs/pgcc
2) the size and growth rate of Debian are, IMHO,
inexcusable. The main section no longer fits on one CD!
If it were just #1, I could probably live with it and just install a seperate compiler and library to compile and run the apps that I really need the speed from. But #2 is just nuts. The multi-CD method of install is very rough and difficult to figure out / use, and installing via ftp is simply not an option for those of us with 28.8 modems. Worse yet, this has caused the pace of Debian to slow to a crawl. "Stable" released versions contains libraries and apps of ancient (by the linux time scale) version, and the dependency structure of dpkg makes substituting self-compiled versions effectively impossible. In short, it's very difficult to have a Debian system that is at all current.
So, my questions are these:
1. Is the Debian project planning, at any point, to create a Pentium-optimized release?
2. Is the Debian project planning, at any point,
to create something like a Debian-lite, that includes only a core of packages such as commonly used libraries, X, popular user agents such as mutt, lftp, and lynx, essential and popular server daemons like sendmail, yp[stuff], nfs, and apache...? Basically, a distro of similar size to the more popular distros that fit easily onto one CD.
If Debian were to do those things, which I see as modernizing and streamlining respectively, I would switch back (or at least try it out in vmware =]).
MoNsTeR