Alexander, since I met you and answered some of your questions and work with your brother, I felt I ought to just provide some of my thoughts on your review, "A User Review of Debian GNU/Linux". I'll just start with saying that my answers are colored by my experience of being a Debian user since version 1.3, a Debian developer since 1998, the install system documenter for Slink, and the maintainer for Potato. Of course, Debian is a large project and others have other expierences
I can relieve you right away by saying I agree with that I thought the review was pretty balanced, I don't see anything in there that was unfair. Some things maybe I think had too much stress placed on them. A few comments along the lines of tech support. This probably points to some additional documentation we could use: | I ran into this problem when I tried the get the latest version of | AirSnort to run on my system. I was having trouble running it, so I | wanted to get the latest version of wireless-tools package. Apt-get | only got me an older version from the stable repository, but I saw | there was an up-to-date version in Debian unstable, so I downloaded | the .deb file from the Debian web site. Trying to install that | brought up the complaint that libc6 was out of date, so I grabbed an | updated libc6 and crammed it in there. Needless to say this broke | quite a lot, and my old friend apt-get was of little help in this | situation since it could only pull from a large database of programs | that relied on the original libc6, and the default settings are such | that broken packages aren't automatically downgraded. Yes. I would suggest that the way you should have gone about doing this was by having this in /etc/apt/sources.list: deb http://http.us.debian.org/debian stable main contrib non-free deb http://http.us.debian.org/debian unstable main contrib non-free And this in /etc/apt/preferences: Package: * Pin: release a=stable,o=Debian Pin-Priority: 850 Package: * Pin: release a=unstable,o=Debian Pin-Priority: 100 This not-so-well-documented feature will make 'apt-get install foo' get foo from stable, but 'apt-get install foo/unstable' get foo from unstable. You might have to do 'apt-get install foo/unstatble dependency/unstable' as well. There might even be better ways to do it, this is just how I do it. | This is the biggest problem when Debian sources become too out of | date - regardless of how technically brilliant Debian's package | system is, it won't do much good if you have to circumvent it to | install the latest software. Well, as a volunteer organization, we set our own priorities. Each developer is different, but generally, we don't upload new upstream versions (even so-called bug-fix releases) unless we can satisfy ourselves that they are as good or better than the previous version. Packages like mozilla and xfree86-server and such are very large and very complex and often involved significant packaging rework before they are ready. | Compounding this problem is that Woody will never officially get | significant upgrades of ANY of its packages, unless they're found to | have memory leaks or major security flaws. That means that Woody will | never officially see a version of Mozilla newer than 1.0, or any | version of OpenOffice.org. This system seems to sometimes run against | the actual software projects by ignoring the fixes they make, in | favor of the original code the developers themselves sometimes regard | as broken. What's surprising is that Debian doesn't even update to | the bug fix releases like Mozilla 1.0. Well, I don't find it suprising at all. It's true, we basically do release stable and forget about it (well, team security still worries about it, and the stable install system maintainers, and often kernel packagers...). Why is that? Well, you already noticed that sometimes maintainers have a hard time keeping up with new upstream versions. You're asking that they not only do that but also test and build updates of software to deploy on stable? That just isn't practical. No one would really do it, at least, not consistently. It would require that each such developer has one box (or chroot, or user-mode-linux, whatever) running 'unstable' and another with 'stable'. We do have a policy, in fact, of now new upstream versions go into stable after it's released. Even security or bug-fix releases need to be back-ported to the version in stable, except for some exceptions (kernels and the install system). But this is just a recognition of the fact that no (or, at least, very few) Debian developers actively target stable. We have our hands full just fixing the bugs, working with upstream maintainers, packaging the new upstream versions, etc. | The awful truth is that if you want to run the latest software, or | anything close to it, currently you have two choices on Debian: run | Woody and use the wealth of unofficial backports or run unstable and | churn through the frequent changes. This means that currently, | there's next to no incentive to run Sarge, which will ultimately | become the next release, since it's the worst of both worlds, old | software, incompatible in some instances with the backports. | | This will likely change in time as newer packages make their ways into | Sarge, but right now that's the case. While I thought this was due to | Debian's being overly diligent with security and stability, it was | pointed out to me that there is an issue with the glibc (the one I | hosed earlier in this review) due to Sun's contract that conflicts | with Debian's software guidelines and developers are trying to work | this out. Both of your explanations for the lag in testing are wrong, actually. The Sun license thing has been revealed as a Red Herring sadly propogated pretty widely by Debian Planet. In fact, the licensing issues go back very far, even before stable release, so that wouldn't hold up glibc. The real reason is that we're making a major ABI change, similar to the transition to glibc6 or from a.out to ELF format. This takes a lot of time to get right. I think it's nearing stablity, but I don't follow this very closely. I feel like you put an awful lot of stress on the current lag in testing, and it doesn't really feel all that fair. The wider perspective is that we put the whole concept of archive "pools", which the infrastructure which enables the whole "testing" distribution, just over 2 years ago (Dec, 2000 to be exact). Woody is the first release where "testing" became "frozen" and then "stable". Right now we're experiencing a pretty large desync between testing and unstable, but, as I said, it's to be expected considering the circumstances, and it's also just a transient condition. In summary, to me, Debian, as the largest and I think most dynamic free software group in the world, is on some level an ongoing story of scaling issues and infrastructure. Debian generally increase 50% in size with every release (every 2 to 3 years, generally). Infrastructure is added or improved when the inability to scale up Debian with its current infrastructure becomes acute. You could also use this perspecttive to look at the evolution of Debian Policy and subpolicies (and the tightness of getting things into the core policy), the Debian Constitution, the New Maintainer apparatus (still needing improvement, I understand), the voting system, etc., etc. I don't mean to pooh pooh Debian's #1 complaint (old versions of packages) and the #2 complaint (the install system). As for #2, the install system, now in alpha, has been rewritten from the ground up to be modular, maintainable, and user-friendly. It might take a while for it to quite get there, of course. As for #1, package versions, in a way that really boils down to shortening the release cycles, that I think is probably the hardest problem in Debian to solve. I think the package pool system is a vast improvement in the scalability of the Debian archive maintenance itself, but at least in Woody, it didn't seem to solve the problem of very long freeze periods. There's a whole cluster of problems that we're going to have to keep working on, including release-critical bug turn-around and the interdependancies between the install system, the base system, kernels and other critical packages which are required to have a functioning, installable, consistent release. Our goal, ultimately, is the ability to do releases annually or even semi-annually. Until then, our solution for the version problem is to run stable and pull from testing or, if you're daring, pull from unstable. In the future, if you're doing a review, I'd be happy to proof a document for things that could be improved or things that I think aren't quite right. -- ...Adam Di Carlo...<[EMAIL PROTECTED]>.......<URL:http://www.onshored.com/>
