It is the reference to xfree86-common that is the problem
As I explained in private mail before I checked here, xfree86-common is just a bunch of documentation and skeleton files to support X clients and servers. It doesn't install any programs or configuration, and it doesn't start an X server.
It is being pulled in because xlibs now depends on it, not because of emacs; it is far less bloated than emacs itself; and the X maintainer has a history of making good decisions about his packages, so I presume he did this for a sound reason unless I hear otherwise.
I think it's a great idea that Debian has developed wherein they are able to slide distributions through different levels of stability: Stable, Testing, Unstable. This is really something that is ahead of every other Linux distro out there
To be fair, there's little new in the idea, although I'd like to think that our implementation is somewhat more advanced:)
But in reading the posts here, it seems that more people are concerned with the newest fad feature over stability
Because of some unusual situations within the Linux software world, potato's age is more critical than it might otherwise be. Many very useful software packages have been created or have come to maturity in the last year and a half. For instance, the web browser I'm typing this into (galeon) did not exist when potato was released...at least, not in any usable form.
There are interdependencies that are being forced into the installation that are getting very expensive to manage. Examples are: Apache now requires mysql-client to be installed. But it is only used if you are interested in using mysql for authentication. That's a rather heavy handed requirement for a rather specialized function.
I suspect that people who want to use mysql for authentication might differ with you on that:)
In any event, this dependency seems to have been removed in unstable.
Similarly, I was very happy with emacs until they make a package requirement for XFree86 in order to install emacs.
Ok, you win. You've completely stumped me here. I cannot find an emacs package that depends on an X server. Could you post the control information for that package here so I can put together a bug report?
Oh, in case this is it, depending on xlibs isn't a bug -- the X support in emacs is very useful, and it can't be enabled without this. Having xlibs installed will do nothing to you if you don't install the rest of X.
Now some random general comments:
Things that one person considers bloat are usually a feature request from another person.
Some maintainers compile their package dozens of times, once for each useful combination of compilation options...this lets you be selective about what options you have installed, but tends to (IMO) bloat the archive and package list, and make things confusing for the user. Striking a balance is very difficult, and the only certain thing is that some people will be upset no matter what we do:)
Ehh. stable/unstable mixes are not supported or encouraged, at least not by me:) If you're adventurous, sure, do it and file bugs against packages whose dependencies are wrong.
But most people should stick with stable. If stable is too out-of-date, the proper solution is to release more often.
So you're saying that the Debian doesn't have a slow release problem? That is only a/. sensationalized view of Debian? I think not.
I quote you:
the fact remains that people are leaving debian, debian is lagging behind
"people are leaving debian" is sensationalized. See my other post.
And honestly, the "lagging behind" bit is overdramatized in my opinion. 6-month cycles for major new releases are not a necessity, folks.
I was referring more to the "Debian is Dying" overtones, a meme that some people seem to have picked up lately. I don't know where they got it from. Maybe they like the alliteration.
(although I'm not sure/. really has been that complicit in this)
Maybe that is because people are getting so frustrated at a lack of progress in the change that they'll suggest anything
Fine, but it doesn't mean that these repetitive "suggestions" do anything more than clog up the communication channels every time they have to be discarded. (about every three months on average)
It's easy to shoot people down but I don't really see you coming back with any response besides "this isn't an issue and you aren't fit to question/make suggestions" and ignoring things that are an issue.
Likewise, it's easy to make broad claims about what things are serious "issues" without backing them up. When someone does indeed do this, and comes up with the same "new" idea as many other people who are unfamiliar with the situation, I tend to dismiss the comment as coming from a person who doesn't have enough information or experience to assess the situation accurately.
Maybe part of that is because these people are partly right. FreeBSD has a nice steady release process and the ports system works well. Obviously Debian isn't FreeBSD but it doesn't hurt to look at other ways of doing things.
Another explanation is that "for every complex problem, there is a solution which is simple, obvious, straightforward, and wrong"...
Actually, it's you should mention that, because someone started a thread about that just the other day on debian-devel. It's still going; I'm browsing the most recent few messages in another window. Many people in the thread agree that some changes are a good idea, based on the experience of this cycle; however, we can't change the entire process this close to a release.
Personally, I think the closest thing to the "split it up" approach is that we could put out several quick releases on a frozen core -- but changing the core will be a pain anyway, we can't get around that. It's the nature of the core.
And I'm not really convinced this is as simple as it seems. In this area, the devil is generally in the details. Two years ago, we thought "testing" was going to issue in a golden age of quick releases. It really has been a tremendous help (IMO), but it hasn't lived up to some of the overly high expectations that some people had of it.
That should of course be ~1000 at last count.
I was somehow thinking people=packages or something.:)
Also, I realized it looks like I'm contradicting myself a bit: first "size doesn't matter" and then "technical measures to deal with issues are helping us release.."
Basically, I think that archive size has not been much of a problem precisely because people have been addressing some specific technical problems. Even if they weren't meaning to work on that:) -- the improvements in our infrastructure have enabled us to greatly expand the archive with relatively little trouble.
Debian people most likely do not want to discuss people leaving their project
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:) In any event, it's a huge technical improvement.
* 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:) ). The number of packages has little to do with it, as far as I can see.
And of course, remember: these are only my personal opinions. I may be wrong, and other maintainers probably disagree violently with me.
I simply wonder why you would want 6 kazillion packages in the distrib when it could simply be the base system.
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/. headlines, you will have only a narrow and sensationalized view of matters.
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*
If you have a package installed which is removed from testing, it will still be installed on your personal machine. ajt won't come to your house and wipe it from your disk:)
But you won't get upgrades from apt (unless you have it set to download from unstable or the new testing) until or unless the package is placed back into the archive.
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.
For instance, even now you can apt-get up-to-date packages
That's talking about an entirely different thing: to install up-to-date packages, you have to put unstable (or testing) in sources.list, and deal with the issues that arise from that.
The 2.4 kernels will be *in woody*, distributed on woody CDs, and available in the same way as the rest of the woody software. They just weren't planned to be the default kernel, although I've also heard rumors that some install disks are being built around 2.4.
He was especially concerned about the development of new biological weapons that could easily fall into the hands of dissonant groups
...and here I thought that Schönberg was scary enough already..
Picture this: a deceased Austrian composer, shown on national TV standing next to a control panel. "If you do not listen to my music and enjoy it, I shall press this button and rain fire, pestilence, and death down on your cities. You will love my tone rows. LOVE THEM. LOVE THEM! BWAHAHAHAHA!"
In light of this, I have to say that some of those more paranoid security measures sound a lot more sensible.
In the future I think that freeware (gpl, or bsd) will be a lot bigger then shareware for this reason
It's clear that it already is. To take just a tiny number of examples: could you point me at a widely-used shareware operating system, compiler, or Web server?
mutt opens HTML mail for me, and it even only displays the text portion (leaving out those nasty images and Javascript whizbangs)
Add "auto_view html" to.muttrc, assuming you have a decent text browser (links or w3m) installed and mailcap is set accordingly. (it is out of the box on Debian, anyway)
This is a very interesting article, and I'm sure that it will be food for thought for many people.
However, I think that some important benchmarks were accidentally omitted. Could you include your comparison of the Intel, Microsoft, and GNU compilers on powerpc, sparc, alpha, mips, arm, and hppa?
Well, there's always Everybuddy, which I used for a while. I never used the non-AIM services much though, so these days I've reverted to Gaim. It has support for ICQ and other protocols (MSN, Jabber, IRC, Zephyr,..?), but I've never tried it myself.
The asymptotic performance of an algorithm is not everything; if you actually want to use it, constants matter too. (ask your algorithms teacher why everyone isn't using the linear-time mediant algorithm for their quicksorts, for instance)
The point the previous poster was making (which I will remain agnostic on) is that if someone manages (heh) to prove that P=NP, solving a given NP-complete problem might have such a large constant or (worse) exponent that for PRACTICAL PURPOSES it doesn't allow us to do anything new.
Ah, I was wondering why everyone's user ID had suddenly incremented by..uh..a bunch.
(obviously I don't read/. much these days:P )
Daniel
Re:"Debian fanatics"? No ... Here are the facts.
on
The LDP and Debian
·
· Score: 2
(adding to what I wrote before, I guess)
I find it fascinating that lots of people seem to think that Debian is somehow beating its chest, stirring trouble, or being generally obnoxious.
I don't know if you read/. much, Chris, but this is par for the course. People prefer attacking straw men -- they don't fight back nearly as much.
And hatred, or at least distrust, of RMS and Debian runs fairly high here as well as most other Internet venues I've seen. You probably know the caricature, judging from your comments. If you don't, reading a few of the posts will give you a feel for it. It doesn't help that some of the more..uh..immature Debian *users* hang out here. [1]
Luckily, being in good graces with/. posters was not the reason I became involved with Debian, so I can remain mostly calm while reading a board such as this one. I've even managed to restrain myself from angrily shooting down every stupid comment here. (the 2-minute time limit is helping:) )
One thing I've always wondered is whether Slashdot is just being Slashdot, or whether the world at large despises us as well. But my impression is that this is limited to online discussion groups, which are in any event the Jerry Springer of the technical world.
(sorry, not in a good mood right now. I can't *always* keep my cool reading/., but it's a good exercise..)
I actually read the GPL before I started using Linux regularly (maybe even before I installed it at all; this was ages ago) -- I think it was when I was trying an early version of Cygwin out, and the installer popped the GPL up. I normally clicked right through the license agreements, but I read this one, because the first few lines were totally different from any license I'd seen before.
I remember being extremely amused at the cleverness of the GPL. I still am, in fact. Good hack, that.
Daniel
Re:"Debian fanatics"? No ... Here are the facts.
on
The LDP and Debian
·
· Score: 2
Pshaw! Facts? On a/. board? You gotta be kidding!
(and I note, with some sad humor, that your post is still at the default 2, while a post describing your actions as "cutting off your nose to spite your face" as at 5.....Insightful)
You would take an existing open source word processor that was close to what you wanted, and modify it. Same thing with installers.
That presumes that there is a word processor or installer "close to what you wanted". I don't think (eg) a modified RedHat installer would be sufficient, at least not without more work than it's worth to avoid a rewrite. Evidently the maintainers of the install system agree with me.
Of course, from your posts on this thread, I presume you have a vast amount of experience with install systems and putting together distributions. I know the debian-boot and debian-installer teams welcome contributions and constructive criticism. You can reach them at debian-boot@debian.org. Thank you for your help.
Daniel
(PS: If you can manage to avoid telling them how stupid you know they are for a few minutes, you'll do much better. For some reason, people don't respond well to insulting language, even if you happen to be right)
I like the current debian installer. Its not X based which means it can run quickly on old Pentiums etc. and it is pretty self explanatory.
No-one that I've heard of is planning to change the ability to run without X (although I have heard suggestions that an alternative graphical install will be provided)
What will be changed is the internal design of the code and the build system and stuff, so that it's easier to maintain and keep up to date. (my recollection is that a number of freeze delays have been caused by boot-floppies being broken) See Adam's recent comments.
Slashdot Mirror
It is the reference to xfree86-common that is the problem
As I explained in private mail before I checked here, xfree86-common is just a bunch of documentation and skeleton files to support X clients and servers. It doesn't install any programs or configuration, and it doesn't start an X server.
It is being pulled in because xlibs now depends on it, not because of emacs; it is far less bloated than emacs itself; and the X maintainer has a history of making good decisions about his packages, so I presume he did this for a sound reason unless I hear otherwise.
Daniel
I think it's a great idea that Debian has developed wherein they are able to slide distributions through different levels of stability: Stable, Testing, Unstable. This is really something that is ahead of every other Linux distro out there
:)
:)
:)
To be fair, there's little new in the idea, although I'd like to think that our implementation is somewhat more advanced
But in reading the posts here, it seems that more people are concerned with the newest fad feature over stability
Because of some unusual situations within the Linux software world, potato's age is more critical than it might otherwise be. Many very useful software packages have been created or have come to maturity in the last year and a half. For instance, the web browser I'm typing this into (galeon) did not exist when potato was released...at least, not in any usable form.
There are interdependencies that are being forced into the installation that are getting very expensive to manage. Examples are: Apache now requires mysql-client to be installed. But it is only used if you are interested in using mysql for authentication. That's a rather heavy handed requirement for a rather specialized function.
I suspect that people who want to use mysql for authentication might differ with you on that
In any event, this dependency seems to have been removed in unstable.
Similarly, I was very happy with emacs until they make a package requirement for XFree86 in order to install emacs.
Ok, you win. You've completely stumped me here. I cannot find an emacs package that depends on an X server. Could you post the control information for that package here so I can put together a bug report?
Oh, in case this is it, depending on xlibs isn't a bug -- the X support in emacs is very useful, and it can't be enabled without this. Having xlibs installed will do nothing to you if you don't install the rest of X.
Now some random general comments:
Things that one person considers bloat are usually a feature request from another person.
Some maintainers compile their package dozens of times, once for each useful combination of compilation options...this lets you be selective about what options you have installed, but tends to (IMO) bloat the archive and package list, and make things confusing for the user. Striking a balance is very difficult, and the only certain thing is that some people will be upset no matter what we do
Daniel
Ehh. stable/unstable mixes are not supported or encouraged, at least not by me :) If you're adventurous, sure, do it and file bugs against packages whose dependencies are wrong.
But most people should stick with stable. If stable is too out-of-date, the proper solution is to release more often.
Daniel
Testing is the release candidate; that is its purpose. (AIUI, anyway)
Daniel
So you're saying that the Debian doesn't have a slow release problem? That is only a /. sensationalized view of Debian? I think not.
/. really has been that complicit in this)
I quote you:
the fact remains that people are leaving debian, debian is lagging behind
"people are leaving debian" is sensationalized. See my other post.
And honestly, the "lagging behind" bit is overdramatized in my opinion. 6-month cycles for major new releases are not a necessity, folks.
I was referring more to the "Debian is Dying" overtones, a meme that some people seem to have picked up lately. I don't know where they got it from. Maybe they like the alliteration.
(although I'm not sure
Maybe that is because people are getting so frustrated at a lack of progress in the change that they'll suggest anything
Fine, but it doesn't mean that these repetitive "suggestions" do anything more than clog up the communication channels every time they have to be discarded. (about every three months on average)
It's easy to shoot people down but I don't really see you coming back with any response besides "this isn't an issue and you aren't fit to question/make suggestions" and ignoring things that are an issue.
Likewise, it's easy to make broad claims about what things are serious "issues" without backing them up. When someone does indeed do this, and comes up with the same "new" idea as many other people who are unfamiliar with the situation, I tend to dismiss the comment as coming from a person who doesn't have enough information or experience to assess the situation accurately.
Maybe part of that is because these people are partly right. FreeBSD has a nice steady release process and the ports system works well. Obviously Debian isn't FreeBSD but it doesn't hurt to look at other ways of doing things.
Another explanation is that "for every complex problem, there is a solution which is simple, obvious, straightforward, and wrong"...
Actually, it's you should mention that, because someone started a thread about that just the other day on debian-devel. It's still going; I'm browsing the most recent few messages in another window. Many people in the thread agree that some changes are a good idea, based on the experience of this cycle; however, we can't change the entire process this close to a release.
Personally, I think the closest thing to the "split it up" approach is that we could put out several quick releases on a frozen core -- but changing the core will be a pain anyway, we can't get around that. It's the nature of the core.
And I'm not really convinced this is as simple as it seems. In this area, the devil is generally in the details. Two years ago, we thought "testing" was going to issue in a golden age of quick releases. It really has been a tremendous help (IMO), but it hasn't lived up to some of the overly high expectations that some people had of it.
Daniel
A few corrections..
:)
:) -- the improvements in our infrastructure have enabled us to greatly expand the archive with relatively little trouble.
6000 people
That should of course be ~1000 at last count.
I was somehow thinking people=packages or something.
Also, I realized it looks like I'm contradicting myself a bit: first "size doesn't matter" and then "technical measures to deal with issues are helping us release.."
Basically, I think that archive size has not been much of a problem precisely because people have been addressing some specific technical problems. Even if they weren't meaning to work on that
Daniel
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
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
Yes, sort of.
:)
If you have a package installed which is removed from testing, it will still be installed on your personal machine. ajt won't come to your house and wipe it from your disk
But you won't get upgrades from apt (unless you have it set to download from unstable or the new testing) until or unless the package is placed back into the archive.
Daniel
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?
For instance, even now you can apt-get up-to-date packages
That's talking about an entirely different thing: to install up-to-date packages, you have to put unstable (or testing) in sources.list, and deal with the issues that arise from that.
The 2.4 kernels will be *in woody*, distributed on woody CDs, and available in the same way as the rest of the woody software. They just weren't planned to be the default kernel, although I've also heard rumors that some install disks are being built around 2.4.
Daniel
Your subject line is puzzling me. I'm trying to figure out what relevance, if any, this has to the book "Homo Faber". Could you elucidate?
Daniel
From the article:
He was especially concerned about the development of new biological weapons that could easily fall into the hands of dissonant groups
...and here I thought that Schönberg was scary enough already..
Picture this: a deceased Austrian composer, shown on national TV standing next to a control panel. "If you do not listen to my music and enjoy it, I shall press this button and rain fire, pestilence, and death down on your cities. You will love my tone rows. LOVE THEM. LOVE THEM! BWAHAHAHAHA!"
In light of this, I have to say that some of those more paranoid security measures sound a lot more sensible.
Daniel
In the future I think that freeware (gpl, or bsd) will be a lot bigger then shareware for this reason
It's clear that it already is. To take just a tiny number of examples: could you point me at a widely-used shareware operating system, compiler, or Web server?
For that matter, I think it always was.
Daniel
mutt opens HTML mail for me, and it even only displays the text portion (leaving out those nasty images and Javascript whizbangs)
.muttrc, assuming you have a decent text browser (links or w3m) installed and mailcap is set accordingly. (it is out of the box on Debian, anyway)
Add "auto_view html" to
Daniel
Open letter to the authors:
This is a very interesting article, and I'm sure that it will be food for thought for many people.
However, I think that some important benchmarks were accidentally omitted. Could you include your comparison of the Intel, Microsoft, and GNU compilers on powerpc, sparc, alpha, mips, arm, and hppa?
Thanks,
Daniel
Well, there's always Everybuddy, which I used for a while. I never used the non-AIM services much though, so these days I've reverted to Gaim. It has support for ICQ and other protocols (MSN, Jabber, IRC, Zephyr, ..?), but I've never tried it myself.
Daniel
Large in this case usually means infinite:)
Yes, I'm sure the previous poster knew that.
The asymptotic performance of an algorithm is not everything; if you actually want to use it, constants matter too. (ask your algorithms teacher why everyone isn't using the linear-time mediant algorithm for their quicksorts, for instance)
The point the previous poster was making (which I will remain agnostic on) is that if someone manages (heh) to prove that P=NP, solving a given NP-complete problem might have such a large constant or (worse) exponent that for PRACTICAL PURPOSES it doesn't allow us to do anything new.
Daniel
Company A can't promise to buy a lot of copies to encourse Company B to add feature X.
I'm sure many free software developers would be willing to accept payment in exchange for changing/accelerate their development schedule.
Daniel
Ah, I was wondering why everyone's user ID had suddenly incremented by..uh..a bunch.
/. much these days :P )
(obviously I don't read
Daniel
(adding to what I wrote before, I guess)
/. much, Chris, but this is par for the course. People prefer attacking straw men -- they don't fight back nearly as much.
/. posters was not the reason I became involved with Debian, so I can remain mostly calm while reading a board such as this one. I've even managed to restrain myself from angrily shooting down every stupid comment here. (the 2-minute time limit is helping :) )
/., but it's a good exercise..)
I find it fascinating that lots of people seem to think that Debian is somehow beating its chest, stirring trouble, or being generally obnoxious.
I don't know if you read
And hatred, or at least distrust, of RMS and Debian runs fairly high here as well as most other Internet venues I've seen. You probably know the caricature, judging from your comments. If you don't, reading a few of the posts will give you a feel for it. It doesn't help that some of the more..uh..immature Debian *users* hang out here. [1]
Luckily, being in good graces with
One thing I've always wondered is whether Slashdot is just being Slashdot, or whether the world at large despises us as well. But my impression is that this is limited to online discussion groups, which are in any event the Jerry Springer of the technical world.
(sorry, not in a good mood right now. I can't *always* keep my cool reading
Daniel
[1] if the shoe fits, wear it.
I actually read the GPL before I started using Linux regularly (maybe even before I installed it at all; this was ages ago) -- I think it was when I was trying an early version of Cygwin out, and the installer popped the GPL up. I normally clicked right through the license agreements, but I read this one, because the first few lines were totally different from any license I'd seen before.
I remember being extremely amused at the cleverness of the GPL. I still am, in fact. Good hack, that.
Daniel
Pshaw! Facts? On a /. board? You gotta be kidding!
(and I note, with some sad humor, that your post is still at the default 2, while a post describing your actions as "cutting off your nose to spite your face" as at 5.....Insightful)
Daniel
You would take an existing open source word processor that was close to what you wanted, and modify it. Same thing with installers.
That presumes that there is a word processor or installer "close to what you wanted". I don't think (eg) a modified RedHat installer would be sufficient, at least not without more work than it's worth to avoid a rewrite. Evidently the maintainers of the install system agree with me.
Of course, from your posts on this thread, I presume you have a vast amount of experience with install systems and putting together distributions. I know the debian-boot and debian-installer teams welcome contributions and constructive criticism. You can reach them at debian-boot@debian.org. Thank you for your help.
Daniel
(PS: If you can manage to avoid telling them how stupid you know they are for a few minutes, you'll do much better. For some reason, people don't respond well to insulting language, even if you happen to be right)
I like the current debian installer. Its not X based which means it can run quickly on old Pentiums etc. and it is pretty self explanatory.
No-one that I've heard of is planning to change the ability to run without X (although I have heard suggestions that an alternative graphical install will be provided)
What will be changed is the internal design of the code and the build system and stuff, so that it's easier to maintain and keep up to date. (my recollection is that a number of freeze delays have been caused by boot-floppies being broken) See Adam's recent comments.
Daniel