Slashdot Mirror
Debian Woody Nearing Release
willybur submits word of this Debian Planet story on the upcoming release of its next stable version. The article says: "According to Anthony Towns (our beloved Release Manager), woody is nearing release. All but three RC base bugs are fixed now, and the bugsquashing party is working through the RC bugs in standard. It's not all good news though.
The bad news is that this means we're probably releasing soon, and that of the hundreds of less important packages with RC bugs (eg, bugzilla, craft, crossfire-{client,server}, epic4, fvwm95, gmc, gnome-admin, intuitively, kdepim, moon-lander, tkdesk, wine, and xosview) will be getting randomly ripped out of testing ... Check the stuff that's important to you and get it fixed before it's too late." Says willybur:
"See the announcement on debian-devel-announce."
You should've installed Woody then. Most of the time you have three versions to choose from: stable, testing/frozen and unstable. When you need a system which will not ever crash after years of heavy load, use stable. If you want more decent software, use testing. If you want the newest versions of software from yesterday, use unstable. It's Good Thing because you have a choice, so don't complain that you're not forced to use the latest untested software, it's up to you. And remember that unstable Debian is usually more stable than any other distro.
~shiny
WILL HACK FOR $$$
List of all the Release Critical bugs (15 feb. 2002)
I think Debian needs a 2.4 kernel as the default if Debian is going to shake its image as hopelessly outdated. For instance, even now you can apt-get up-to-date packages, but most people don't go beyond the defaults. As for me, I go beyond a little: I like to get security patches. Love those. But I'm wary of upgrading other things -- I've tried a KDE 2.1 to 2.2 upgrade that really made my system screwy, and a SuSE 2.4.10 kernel upgrade to 2.4.14 that lost my ext3 functionality. Of course I fixed these things, but I'm wary now. It took time, which is valuable to me. Even with Debian, you can apt-get yourself into trouble. So as someone on the sidelines (well, maybe more than that, I've done a lot of Debian installs), I would encourage the Debian folks to either reconsider the default install, or actively plan for a 3.1 (or even 3.0.1) release that will happen soon after 3.0.
My Greasemonkey scripts for Digg &
Sorry, you can use 2.2.20 or 2.4.13 2.4.14, 2.4.16 and 2.4.17.
See the list of base packages.
(and always you can build your own kernel of course)
~shiny
WILL HACK FOR $$$
From discussion with Debain users (and time spent administering Debian boxed at my workplace) Debian's rpm support doesn't work that well for anything apart from large self-contained statically compiled packages. The problem being that the Linux Standards Base will probably be considered the definition of what a Linux distro is in a couple of years (and is starting to be used as a yardstick these days). Yes Debian ostensibly supports the LSB via alien, but how well?
/opt have had to change, and if they haven't, they've been looked upon negatively (and rightly so) for their lack of standards support. So how well does alien work, and would you use it to install some, or even most software on your system? A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer that's tired of maintaining different sets of packages for Red hat, Suse, Debian, Mandrake, Connectiva, and every other distro out there. Theoretically, the KDE people (for example) should only have to release one set of packages per OS. Doing otherwise wastes a great amoutn of time that could be used elsewhere.
/me waits for the inevitable negative moderations from people who disagree with what I'm saying but can't voice their own opinions and repond maturely.
The distributions which put initscripts in nonstandard places have had to change, those install packages into
And yeah, I'm a Red Hat user who has posted a non 100% supportive comment about Debian in a Debian release news item.
That's insightful and informative indeed, but wrong. Why won't you just check it? You can use "2.4.16 or .17",
they're in binary base packages and have been for some time now.
~shiny
WILL HACK FOR $$$
Just to be clear, OpenSSH 3.0.2 is included in Woody (and has been for some time).
Sure, most people using Debian as a server are running the stable release, but I was under the impression that almost all desktop users were tracking unstable for want of the hundreds of packages missing in the age-old 2.2 release.
Having all these things fixed for Woody release would be nice, but I'm guessing there's almost nobody out there who'd be affected by these vanishing.
How many of you Debian folk are using stable for something other than a server?
- Debian stable version (today it's Potato),
- Debian testing version (Woody) and
- Debian unstable version (Sid).
Have you read The Myth of Open Source Security Revisited ? That means that you won't see the latest untested toys in Debian stable, like you won't see them in OpenBSD. There is no point in arguing that Debian stable doesn't have the newest software, because if you want to run the newest (which also means untested) software, that means you don't want Debian stable. You should use one of the other available versions, unstable or testing. I usually find the testing version the best for my own use, but I still use stable Potato on few mission critical machines, which have never disappointed me so far.~shiny
WILL HACK FOR $$$
Why is it that every time there is a release announcement, this same lame joke gets modded up?
Blah...
I've had enough abrasive sigs. Kittens are cute and fuzzy.
nop@family-values:/tmp$ wget ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i
[...]
nop@family-values:/tmp$ od -t x1 ash-0.3.7-2.i386.rpm | head -1
0000000 ed ab ee db 04 00 00 00 00 01 61 73 68 2d 30 2e
You will note the "04 00" after the magic number. Is this accusation still unjustified?
The place I first saw these in the wild was source RPMs. In several cases, I've gotten SRPMs that I could not extract due to version mismatches. (Extraction of SRPMs is not a LSB issue, however.)
I'm not complaining that Red Hat was not a good player in the LSB standardization process; I've no reason to think otherwise. I'm complaining about the attitude that "interoperability with Red Hat" is an important goal for Debian or other distros. It's more important to interop via standards, not testing against a perceived market leader.
Thanks for your insightful [0] comments on our release process. Could you give me a URL for the webpage of your Linux distribution? Given your cutting insight into the issues of building one, I assume you have one with some useful features we could learn from. I also presume it's quite stable, secure, and up-to-date, and already runs on a half dozen hardware architectures and at least two kernels.
Thanks,
Daniel
[0] or is that inciteful?
Hurry up and jump on the individualist bandwagon!
It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable. Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information, effectively shell scripts that rely on the filesystem of the intended distribution. Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts), the control information isn't portable.
/opt directory was completely unsed by Debian, and AFAIK has always been that way. Since the release of Potato, something as laborious as moving every single changelog, readme, info page, man page and other textual file from its previous location (usuallt /usr/doc) into the FHS mandated /usr/share/doc hierarchy. This was of dubious benefit at best, other than strict adherence to the FHS.
.TGZ archives, and Free Software Operating systems should respect the conventions... especially in the common case where the software project existed longer than the OS in question. For the most part, the Free Software BSDs have done this. FreeBSD developed their Ports system allowing them to keep a tree of makefiles which would aid in compilation of software packages that isn't part of the standard system. The exception is that the BSDs tend to have integrated XFree86 into their "base system", so they have modified XFree86 from the standard distribution. Debian has gone much further than this, packaging almost any Free Software of interest, for inclusion into their system... making Debian the largest, most versatile system to date.
The Linux Standards Base is a fairly useful effort, but it includes the Linux Filesystem Hierarchy Standard, which seems to be what you intended to take Debain to task for. AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB. So you meant "Debian supports the FHS via alien..."
The FHS is full of good intentions, but unfortunately the reality falls far short. DJB has a number of valid criticisms that are as of yet not addressed by the LSB, or more accurately, the FHS. While I tend to think that standards are a good thing, I don't think that you should ignore convention in favor of provably flawed standards, so the FHS is not as desireable as I once felt. Without regard to the benefit of the FHS, I will argue that Debian supports it, in fact the Debian Project has made FHS support a specific requirement in their official policy manual.
The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant. Rather, the standard RPM format is that defined in the publication Maximum RPM, and Redhat has continues development of their RPM format since that time. That means that the average RPM distributed with Redhat is not FHS compliant. Offical standard RPMs are handled by Debian via Alien flawlessly, and likely by Redhat and SuSE as well.
More importantly, the "Maximum RPM" RPM format isn't the most important feature of the FHS. More important is adherence to the recommendations of where in the directory tree different types of files should be. It seems that Debian is the most compliant distro, closely followed by SuSE last time I saw a comparison. You may have noticed when you administered the Debian Boxen that the
Just a small point of contention, every "Linux distribution" can arguably be called a distinct OS -- Unless you support that they are all just implementations of the GNU OS. But NetBSD and FreeBSD are just distributions of 386BSD. OpenBSD is just another version of NetBSD. AIX and IRIX are just distributions of UNIX. Even if all Linux distros are unified by the LSB, that's not much different than how all Unices have been unified by the POSIX standard. And Remember, Debian keeps their own Linux tree, as does Redhat, both distinct from the Official Linux at Kernel.org.
Theoretically, software developers should only have to release their files as
As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen. Perhaps you would have realised that you were likely using a non standard RedHat 7.x (e.g.) specific RPM. Even Mandrake, which directly descended from Redhat, has enough of a delta from Redhat that not all RPMs will interchange between the two. RPMs intended for other distros will tend to fare much worse. Even an RPM for Redhat 6.0 isn't recommended for Redhat 7.3, so it was a bit naive to expect a non-FHS RPM to work. Better would have been to type:
apt-cache search pppoe
If you wanted to install Roaring Penguin's PPPoE RPM to see it it was available, and what the APT package is named. If you had an RPM that you needed to install, then odds are that it was available. Then you type:
apt-get install pppoe
and all would have been well. Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.
I am heartened to see that you haven't been down modded, I I hope that my post has been informative.
-castlan
Ok, ok, ok... I admit in a fit of boredom a bit of trolling was hard to pass up. But in all honesty the central issues I was trolling about are real issues and are causing problems. Of course it is better to be part of the solution instead of part of the problem but sometimes discussion of issues is enlightening. Debian people most likely do not want to discuss people leaving their project, the problems with their project, the release schedule ("it'll be released when it's done"), etc.
Obviously Debian is a not a commercial product but if people who did this out of the good of their heart get so sick of the slow release schedule that they are leaving it seems obvious that there are a number of problems. Of course you can say "slashdot troll" and so can I but all criticism of Debian is pretty much ignored. The Debian project is a very insular project that isn't very open to criticism or change.
Those things are pretty obvious from the outside. I don't know what people think of these issues on the inside and frankly I don't really care. All I care about is progress.
The funny part of this whole thread is that I'm replying on a machine running unstable. But the fact is I don't think I'd use Debian on a server. As a sysadmin the core release makes sense but the fact that other non-essential packages like Apache are never upgraded in a release does not. I'd rather run the mainstream release of a package with perhaps only a few modifications for install location than the Debianized patched to hell version.
So I currently run FreeBSD and RedHat (sigh) on my servers. I'd love to run Debian but it simply doesn't make any sense.
Ok, now you can reply with six million reasons why I'm wrong, how this university runs Debian stable on 3,000 boxes, yadda yadda.
I simply wonder why you would want 6 kazillion packages in the distrib when it could simply be the base system.
/. headlines, you will have only a narrow and sensationalized view of matters.
Why not? Having precompiled packages that integrate with the system is a very valuable thing to me and many other developers and users.
As for "just the base system"...the primary reason the freeze was held up was because of bugs in the base system, many of them bugs from the upstream source relating to failures on obscure hardware or when using charsets other than the default one.
The primary reason the freeze is now progressing again is because the base system is down to under five "makes the package unsuitable for release" bugs.
Packages not in base or standard will simply be dumped if they aren't ready in time (about two weeks from now), as you'd know if you had read the article.
the fact remains that people are leaving debian, debian is lagging behind, the release process is very slow, etc.
The fact remains that a handful of maintainers have left in the last year due to burnout, the number of Debian maintainers is increasing overall, woody is a very impressive distribution, and it is (at long last) moving towards release.
The fact remains that if you only read
The fact remains that sometimes experience matters, and uninformed opinions are uninformed. "I don't know a thing about aeronautics, engineering, or fluid dynamics, but I've flown on lots of planes, and I have this great idea about how you can make your 747s go faster.."
Everyone has seen the accusation that "all those crufty packages" are holding up the release, it's been discussed dozens of times on the mailing lists, and not one person has yet produced a specific and concrete example of a way in which so-called "package bloat" is holding up the release. Hand-waving arguments, personal attacks, and oblique references to Fred Brooks are easier, I guess. *shrug*
Daniel
Hurry up and jump on the individualist bandwagon!
Debian people most likely do not want to discuss people leaving their project
:)
:)
:) In any event, it's a huge technical improvement.
:) ). The number of packages has little to do with it, as far as I can see.
You keep bringing this up. Only a few people (less than ten, probably less than five; I don't have an exact count and not all the announcements were public) have left in the last year, and most of those were burn-outs who have continued their involvement with Debian as users. (that is to say, they are still active on the mailing lists and submit bugs/patches; they just don't take on the commitment of maintaining packages, etc) Only one person cited the release schedule as a reason for leaving. That's hardly droves.
Do you really expect 6000 people to be continually happy with everything about the project? I hope you don't think we're the Borg
I also never said I think the release process was perfect; I merely disagreed with what you claimed were the flaws in it.
all criticism of Debian is pretty much ignored. The Debian project is a very insular project that isn't very open to criticism or change.
It's quite hard to take it seriously when most of the criticism is making the same few claims without providing a shred of hard evidence, and when most of the changes suggested are the same one we've heard before.
If people are terse in replying, it's because these specific issues have been discussed for years in gigantic threads already, and the list traffic is high enough that no-one wants to waste more bandwidth on it. The consensus each time has been that the number of packages is a red herring, and we need to look elsewhere for the problems.
Ben Collins recently observed that the "Debian is dying, it has too much bloat" thread has been around, in various forms, since he became involved with the project, and I can say pretty much the same thing. Some people even suggested, only somewhat facetiously, that it's been around ever since Ian realized he couldn't maintain the entire distribution himself
I don't know what people think of these issues on the inside and frankly I don't really care. All I care about is progress.
How admirably utilitarian of you. It also absolves you from making any constructive suggestions that people will listen to..
Oh, and if you want my personal opinion: there have been a lot of technical measures taken to streamline Debian releases in the past year or two. Many people have suggested that woody's long cycle implies that these measures are failures. I personally suspect, although I'm not yet sure I believe, that these measures are responsible for the fact that woody is being *released at all*.
Compared to what I remember from previous releases, the number of coordination problems we've had with coordination and dependency issues does not seem *to me* to have increased proportionally to the package count; in fact, I think it may actually have gone down. (this is all a very fuzzy estimate, and should not be taken particularly seriously)
Automatic dependency checks to ensure an internally consistent "testing" distribution, BTS enhancements for all manner of things, automatic lists of base system bugs, continual improvements in the package maintainence tools (debhelper, debconf, lintian, etc)...all of these have addressed particular problems in the distribution. I think that claiming that they didn't work simply because they didn't solve every single problem at once is failing to see the forest for the trees.
And finally, since I said I don't think your explanation is correct, here are some specific things I have seen that probably held things up, based on my personal experience within the Debian Project:
* Effort was diverted from boot-floppies to debian-installer; then, when it appeared that debian-installer wouldn't be releasable in time for woody, it was put on hold and the installation team scrambled to get boot-floppies to work again (since it had since been broken by changes to the base system) We lost at least several months here.
A major problem here (and the reason we want to get rid of boot-floppies) is that the boot-floppies code is fragile and tends to break whenever it is so much as sneezed upon. It's been a culprit in past delays as well.
debian-installer will be used for woody+1, and to hear joeyh talk about it, it's the coolest thing since debhelper
* Many new architectures were added, some at the "last minute". This resulted in many more "interesting" ways that packages can fail to build, especially since the build tools often behave subtly differently on different archs. In some cases, we actually have to use completely separate branches of code! (gcc 2.95, 2.96, and 3.0 are all required for at least one arch, for instance, so all code must compile with all three of them)
(I should add that Debian has probably made a tremendous contribution to the portability of free software in general, simply by building every single program in the archive, no matter how exalted or humble, for architectures the author often never heard of, and submitting patches for the failures)
At the same time, some core packages always seemed to be broken on some obscure arch, generally due to the immaturity of that port of the program. Today g++ wouldn't compile hppa code; tomorrow libc didn't build from source on s390. And the kinds of platform bugs that crop up in these packages tend to be hairy and hard to solve.
* Many maintainers became too busy to maintain their packages (perfectly ok) but left themselves as the official maintainer in the package system (not ok!) This meant that many packages became buggy and went unattended to for far too long before anyone noticed. In fact, this is still a problem, although measures (technical and social) have been and are still being put in place to combat it.
This is the one place where size hurts: with so many maintainers, so-called "MIA"-ness seems to be somewhat inevitable. The main fix here appears to be breaking down the semi-feudal "one maintainer, one package" paradigm that has become ingrained in the distribution.
I think that sums up the major things I have seen slowing the project down, and they're based on hard (or at least firmly mushy
And of course, remember: these are only my personal opinions. I may be wrong, and other maintainers probably disagree violently with me.
Daniel
Hurry up and jump on the individualist bandwagon!
Anyone who says Debian is out of date is just wrong.