Interview: Debian Project Leader Tells All

There are over 500 Debian maintainers today, up from 100 only a few years ago. Wichert Akkerman has been Project Leader for this brilliant, sometimes unruly (but always interesting) gang since February. Monday you posted questions for Wichert. Today you get answers. (Lots more below)

Packaging Front End
by Christopher B. Brown
Considerable improvements have gone into the "back end," apt-get; while there has been some experimentation with gnome-apt and console-apt, there doesn't seem to yet be anything that unambiguously improves on dselect in terms of functionality.

With the things that have been learned from those attempts, is there likely to be some sort of dselect-ng?

Wichert:
I really hope so. The reason that we don't have a super-glitchy-totally-awesome apt frontend at the moment is that we have nobody who is willing and able to invest the time and effort into making it. Unlike a commercial distribution, we can't just say `oh, this would be cool. You there! Write this for us and we'll give you some money.' Somebody has to decide for himself that it is an interesting project and make it. We can only encourage people to do something and be very thankful when they do. At this moment the only interactive frontends (that I know off) are dselect, gnome-apt, console-apt, Corel Update (formerly/also called get_it) and aptitude. I would like to ab^H^Huse this opportunity to invite people to write a good frontend or finish console-apt. The apt library is really powerful and does everything you want it to do, the only thing missing is the frontend...

2) When will KDE be included in Debian?
by grrussel
Now that Qt 2 is free software, under the QPL, will Debian include KDE 2 when it is released, based on Qt 2?

Wichert:
Short answer: yes. Long answer: we will include it when we're sure that all license issues have been resolved. The QPL is a major step forward over the previous license and allows you to use it in Free Software projects. There is still a slight problem though: it is not compatible with the GPL. This doesn't mean that it's not free, but it does mean that if you want to use code that has been licensed with the GPL and use it with something that is licensed under the QPL (like Qt) you have a problem. There are two ways to fix that: change the license for the GPL'ed part to add a special clause stating it is okay to do this, or replace the GPL'ed part with something under a different license. KDE has stated that they are indeed going to make or request the necessary license changes so all these problems should be fixed for KDE

Once that has been done there is nothing to stop us from including KDE in Debian. Right now we are mostly waiting for the KDE team to release the first beta of KDE 2 so we actually have something to study and package.

More from grrussel
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?

Wichert:
I'm not so worried about having non-free applications for Linux. What does worry me is the explosion of different licenses. Everything used to be relatively simple when almost everything was either GPL, LGPL, BSD or MIT-licensed. But now we have the MPL, QPL, SCSL, APSL, Artistic, Wine and other licenses as well. It seems that every time someone starts a big project they want to have their own license. The result is more licenses that conflict with each other in various subtle ways. A lot of the licenses are based on the same principles, which suggests that it would be possible to replace them with a common one. I would love to see an effort in which people from various backgrounds would try to design a couple of good licenses which are acceptable by both the existing Free Software community and the commercial world.

3) Choose HURD over Linux?
by sanderb
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?

Wichert:
The HURD is a very different thing from Linux, and we will have to see what the advantages will be. Unlike Linux, the HURD is a micro-kernel based system. (Remember the flamewars between Linus Torvalds and Andre Tanenbaum?) This means that unlike Linux you don't have one big kernel, but a lot of very small objects working together. This gives you a very flexible system where various parts are easily replaced. Right now most of the effort is being put into stabilizing the systems and building the set of objects that will offer you a Linux-like interface to the system. Once that has been done we will probably see more interesting developments where non-Unix-like elements are being combined with the other interfaces to produce.

4) RPM vs. dpkg
by Tet
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?

Wichert:
That's not really possible. The differences between rpm and dpkg are bigger then just the format in which packages are stored; the interesting differences are in the way relations between packages are declared and how the details of package installation and removal are done. For example, rpm allows you to have multiple versions of a single package installed. dpkg does not allow you to do that; it demands that you change the name of the package.

This might seem unlogical, but the result is that we can always be sure exactly what is installed and not have to worry about exactly which versions of a package are installed, and it allows us to upgrade and maintain multiple versions of a library in parallel. Another really big differences is the way package installation is done: with Debian packages there are separate scripts that are run before and after package installation and removal. Using those we can do all kinds of special-case upgrades, handle error-recovery in failed and aborted upgrades, etc.

More from Tet
In what way might Debian users benefit from sticking with dpkg over a modified RPM with equivalent functionality?

Wichert:
It's indeed possible to modify rpm, dpkg or create a new tool to handle both formats. Once that has been done the reason to stick to one single tool will mostly depend on what you are used to, which one is the most stable, etc.

More from Tet
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).

Wichert:
Apt was actually designed to be reasonably independent of package format. It's indeed possible to modify it to use rpm-packages. One problem with rpm-packages is that it is harder to satisfy dependency due to the concept of file-dependencies. Instead of being able to say `I need package b to be able to use package a' it can become `I need file /usr/lib/libfoo.so.3.14 to be able to use package a' and then you'll have to find some way to scan all packages to see which ones include that file, and then you're not even sure if they have the right version of that file..

5) Slow release cycle
by Stephen
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?

Wichert:
The slow release cycle is indeed something we don't like and would like to change. There have been plenty of discussions on possible new approaches, and good proposals have been made. Unfortunately, changing the release process is difficult.

The most popular idea is a new approach we call package pools. Instead of dividing all available packages into distributions like we do now, we put them in a single big pool. Then we create a database with information about all available packages and use that for distributions.

A distribution will then be nothing more then a Packages-file which lists the packages in the distribution. This means that we don't need to do things like move packages physically from one distribution to another or maintain a forest of symlinks; all that is necessary is to create a new Packages-file. This makes it possible to create more distributions and play with new release systems.

The only thing we would need to do is determine how the list of packages for a distribution is selected. We could use it to keep stable and unstable distributions like we have now, but we can also create new distributions such as a reasonably-stable or even things like stable-with-new-X or stable-with-new-kernel, etc. Basically it gives us a lot of possiblities to create and manage distributions, which should result in shorter and more regular release cycles.

Implementing this will take time, and we want to do something for the near future as well. What we plan to do for potato once it is released is create update-packs on a regular basis. An update-pack is a set of packages that you can install on top of stable and extend or upgrade it in some way. Examples could be a Y2K pack, a GNOME pack or a KDE pack.

6) Debian GNU/FreeBSD
by ajs
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 certain 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...

Wichert:
The current idea seems to be to build a small system with the FreeBSD kernel and system utilities, and use the Linux compatibility support to run the already existing Linux userland. With this approach you don't have to work on most of the packages at all, which makes things a lot simpler. The effort is still in the beginning stages though, so things might change at some point.

7) Debian bureaucracy
by Big Dave Diode
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?

Wichert:
I won't argue that Debian has no problems at all. We have rapidly grown (100 people in 1995, 200 in 1997, and 500 now) from a small group of people to a big project. That growth has indeed forced us to establish some rules and set some guidelines. Where Debian started out with a single mailing list we now have over 50 mailing lists, a couple of teams with dedicated functions, a constitution, and policy guidelines.

This may sound excessive, but it's not as bad as it sounds. 99% of all decisions are announced and discussed on lists such as Debian-devel and Debian-project, and everybody is free to contribute to the discussion. Since all lists are public, you will also see people arguing a lot, and emotions can get heated at times, but I wouldn't call that infighting.

The new-maintainer process will indeed be revised. We have a proposal for a new process that will hopefully reduce the load for the new-maintainer team and also help new maintainers. I hope that we'll start using that soon. When we do, we will announce it on the Debian-announce list.

A lot of this is a learning process for everyone involved. How do you handle growing from a small group where everbody knows each other to a large group where you only know a couple of people? How do you assure that everybody is working together and no conflicts arise? How do you handle managing the necessary resources? How do you handle relations with companies? All very real issues, and we are learning at every of the road. A very interesting road, I might add.

8) Debian and Pentiums
by MoNsTeR
Is the Debian project planning, at any point, to create a Pentium-optimized release?

Wichert:
No. Some people have stated an interest in recompiling Debian with Pentium optimization (there are even some scripts to automate that). However we feel it doesn't make much sense for a couple of reasons:

• if you compile something with Pentium-optimization it will be faster on an Intel Pentium, and (possibly much) slower all other chips (ie AMD chips, other versions of Pentiums, etc) or simply not work at all (on 486s for example). This means that only a small group of people will benefit.
• it doesn't really help you: if you look at benchmarks you will see that only a relatively small number of programs benefit from this. So you do a whole lot of extra work and gain very little.
• If you are that crazy for speed you probably want to look for either a faster system or a different architecture. Debian has been released for the alpha,for example, which gives you a fast 64-bit architecture. Or you can try powerpc or ultrasparc.

9) Debian lite
(also by MoNsTeR)
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.

Wichert:
Yes. This closely ties in with the archive changes I mentioned earlier: with the current system it is hard to create a subset of the distribution since you will essentialy have to create a tree of symlinks into the full distribution, and managing all those symlinks is a difficult problem. Using the package pools all we would need to do is create a set of guidelines for what should be in Debian-lite and the system will build it automatically.

10) Core
by Anonymous Coward
What do you feel about Corel Linux, Stormix, and other Debian-based distributions? Do you think Debian may eventually form a common core or base OS that others build distributions on top of?

Wichert:
I'm quite happy with all the Debian-based distributions. For both sides it is an unusual situation: the people basing their system on Debian can start off with a complete distribution and they don't have to worry about maintaining that, and can focus and their specific goals. Most of the derivates also release all their changes, which means we get a lot of bugfixes and new things such as graphical installers, management tools, etc. We can use those to improve Debian again, and the cycle is round.

You could call Debian the common core on which Corel Linux, Stormix and others are based in much the same way Red Hat is the common core of Mandrake and others. Some people have mentioned it might be a good idea to use the Debian base-system as a common core for the LSB. Since Debian is a community effort this does make some sense since it means nobody will have complete control of it. If that is the best approach, or if others (or even the LSB) will accept such a situation is something I'm not sure of. We will have to see what happens.

----------

Next week's interview: Curtis Chong, Director of Technology for the National Federation of the Blind, discusses computer and Internet disability issues.

Comments

I love debian and wish it to continue.

[slashdot-terminal]

I have found linux bliss in debian I just wish someone would release a CD a little sooner with some of the more recent packages like an updated version of some more of the packages. I have slink 2.1 r 3 but sometimes it is a little difficult to get the packages from the net.

first post!

[wichert]

sorry, couldn't resist :)

Re:first post!

[Signal 11]

Do you realize you're the "first post" poster in the history of slashdot to be marked up?

How does it feel, wichert, to have accomplished something previously thought to be impossible to accomplish on slashdot?

Re:first post!

[Anonymous Coward]

Jesus Christ, man!

Lay off wichert! He/she's not bad!

Re:first post!

[Anonymous Coward]

Do you realize you're the "first post" poster in the history of slashdot to be marked up?


If not he most likely soon will.

How does it feel, wichert, to have accomplished something previously thought to be impossible to accomplish on slashdot?


Probably quite good for a little while. However I think that will soon be remedied.

Re:first post!

[Anonymous Coward]

what do you mean by marked up?

Re:first post!

[Anonymous Coward]

what do you mean by marked up?

moderated up

Re:first post!

[Chalst]

Indeed. I've long thought there to be a fine line between troll/flamebait and funny, but a first post? I... ah... never mind.

Re:first post!

[Anonymous Coward]

Do you realize you're the "first post" poster in the history of slashdot to be marked up?

You mean, 'you're the first "first post" poster...'. That was just tres cool :)

--ac

Re:first post!

[Chalst]

I suspect the first poster to receive a total of 17 moderator points (and counting) attached to a single post...

Re:first post!

[luge]

21 now, and back down to 2 from 3. jeez. I wish I hadn't blown all my points this morning- I almost never ever mark anything as funny, but this deserves it big time.
~luge

Re:first post!

[matman]

dont be discriminatory. Anyone who tried first post should be moderated down. I think that its sorta wrong to allow eleetism. i mean, its good to be funny. but i mean, it is off topic and flame bait. hehe and yes, it is funny :)

Re:first post!

[craw]

The pragmatic purpose of moderation is to allow a reader to filter out useless garbage. As you point out, this was funny. I think that it is absolutely hilarious. I believe that most ppl would also find it amusing. Hence, giving it negative points will deprive others from this very unique and funny post. The other nice thing is that it indicates that Wiechert obviously knows this site. That in itself is Insightful and Informative.

Off-topic? Nah, the interviewee just poked fun at himself. When someone is interviewed, you want to get a sense of his attitude. This showed me that he has a sense of humor.

To me this wasn't elitism in action. It's a great joke; personal self-depreciation. I think that it elitism for the moderators to downgrade this.

What if a Linus interview was posted, or one with RMS? What if they then submitted, "First Post"? That would be ROFL! It would also indicate that they are reading /.

I understand what you are saying about being non-discriminatory, but you sometimes you need to be flexible.

Re:first post!

[wichert]

Hey, if we are out to change the world and try to
get everyone to use Linux we might as well start
here and prove that the impossible might in fact
not be impossible at all :)

Re:first post!

[Jonas �berg]

FWIW; RMS doesn't read Slashdot. But sometimes some nice GNUers who does read Slashdot (such as myself) forward interesting comments to RMS and he usually takes time off from his work to answer them via email to the poster.

Re:first post!

[habib23]

I think it is nice to see that he has a good sense of humor. Also this is certainly one of the more interesting examples of moderation wars I've seen yet...

Re:I knew it

[slashdot-terminal]

he is a nazi

What because he has a German name? Reality check there are more Nazis in Idaho than there are in all of modern day Germany get your facts straight.

Re:I knew it

[Anonymous Coward]

Jesus Christ, dude! Lay off the Nazis and the states! They're not bad!

Future

[Star Traveller]

The question is, if Linux becomes very popular, would it still be Linux?

There are probably many people who would not like to see the power of Linux in the hands of "the unwashed masses" and leave.

Will this happen?

"The mistake of the young is to think that knowledge can replace experience.
The mistake of the old is to thing experience can replace knowledge"

Re:Future

[slashdot-terminal]

The question is, if Linux becomes very popular, would it still be Linux?

I think it would nothing changes from it's core.

There are probably many people who would not like to see the power of Linux in the hands of "the unwashed masses" and leave.

For what? to something that has a more difficult method of doing things? I see most of the people using linux as a replacement for development and such from the windows experience and not for the arcane nature (only) of it.

Will this happen?

Well in computer science they use windows machines in a great deal of universities for general programming has this actually hurt the practice of standard nature of the ANSI standard of C++ as most people program it. I guess if they stress the win32 API but then that isn't usually covered in CS courses (at least not in the ones I know of). It may be with a few people but the core of the people who made it a good system will remain. Most of the alternatives are not as vocal with recruiting members as the linux community. The alternatives are arcane and wish to stay that way. So I see no real decrease of followers.

Re:Future

[Anonymous Coward]

Jesus Christ, man!

Lay off the future! It's not bad!

Re:Future

[ripcrd]

Who cares if it becomes popular? That adds eyeballs, bug reports, etc. It forces software companies to listen to users and create games and apps for Linux. Is this a Bad Thing? If all the voulunteers take off it may change, but companies like Red Hat can take up the slack or hire them.Unless you make all your income from Win95 support then it would be a Good Thing for the "Unwashed Masses" to be using it. They may use Linux for Dummies (TM), or something with a standard GUI frontend (how about Linux LSB Distro)but it would still be something that you could get under the hood and fix or give them the keys to once they learned what the hell they were doing. "Will this happen?" It already is. Amen, brother.

Re:Future

[firstnevyn]

It has come to my attention that in your post to slashdot you infringed upon IDGpublishing's Tradmarked and copywrited Words "linux for Dummies" and "for Dummies" As you are no doubt aware IDG are extremly concerned at the dilution of their Trademark "for dummies" label.

Question to all

[ciurana]

Good morning!

Just a quick question: What is the meaning of the word "debian"?

Thanks!

E

Re:Question to all

[wichert]

Debian is a combination of the names `Deborah'
and `Ian'. It was chosen by Ian Murdock who started the Debian project.

Re:Question to all

[Ray Dassen]

See http://www.debian.org/doc/FAQ/ :

How does one pronounce Debian and what does this word mean?

The project name is pronounced Deb'-ian, with a short e, and emphasis on the first syllable. This word is a contraction of the names of Debra and Ian Murdock, who founded the project. (Dictionaries seem to offer some ambiguity in the pronunciation of Ian (!), but Ian prefers ee'-an.)

Re:Question to all

[Anonymous Coward]

Why was this moronic post allowed to have a score of +2? I don't care if that was the default score, it should've been marked -9 STUPIDASFUCK!

Secure version of Debian?

[shub]

I didn't see any of the questions about Bastille Linux versus Debian, or if there are any plans to try to do a secure version of Debian, so that the Linux community can finally have something that might be approaching the inherent default security that is available with OpenBSD.

What about it, guys?

Re:Secure version of Debian?

[mistalinux]

Bastille Linux is a secure addon to redhat, i believe. You can find this at http://bastille-linux.sourceforge .net/bastille.html

Re:Secure version of Debian?

[slashdot-terminal]

I didn't see any of the questions about Bastille Linux versus Debian, or if there are any plans to try to do a secure version of Debian, so that the Linux community can finally have something that might be approaching the inherent
default security that is available with OpenBSD.

If you wish to make debian secure there are numberous packages that are in the non-us directory on the main ftp site (and mirrors) which can make it secure. As far as making a "secure distribution" that is similar to OpenBSD that would create too many problems with being able to export the standard core part of the OS. Therefore it is seperate.

Re:Secure version of Debian?

[slashdot-terminal]

Bastille Linux is a secure addon to redhat, i believe. You can find this at http://bastille-linux.sourceforge .net/bastille.html

Interesting how they name the most secure version of linux after a rather infamous French prison that was sacked rather easily by a bunch of angry peseants. Oh well I could have chosen a rather non-ironic name.

Re:Secure version of Debian?

[Anonymous Coward]

Jesus Christ, man!

Lay off the secure version of Debian! What has it ever done to you? It's not bad!

Re:Secure version of Debian?

[Anonymous Coward]

would Maginot Line Linux been better?

Re:Secure version of Debian?

[Brett Viren]

Debian itself takes security pretty seriously. Often it is Debian releasing a security related bug fix long before other big distributions. There was a recent bug fix which RH trumpeted but which had been fixed by Debian more than a year previously.

The only time I have had one of my Debian machines broken into is when I had failed to head the Debian Security Advisories.

great interview

[mistalinux]

That was a very good interview, and very informative. As a die-hard everything-but-debian user (by accident, I've just never happened to have used debian or any of its derivatives), I'm very tempted to drop debian on a machine or two. The release history seems to suck, but isnt that fixed by using something like apt to update all of your packages? The pool of fresh packages seems like an awesome idea.

Re:great interview

[slashdot-terminal]

That was a very good interview, and very informative. As a die-hard everything-but-debian user (by accident, I've just never happened to have used debian or any of its derivatives), I'm very tempted to drop debian on a machine or
two. The release history seems to suck, but isnt that fixed by using something like apt to update all of your packages? The pool of fresh packages seems like an awesome idea.

Quite easy. I use floppies to upgrade most of my packages and I have a reasonably up to date system just by using dpkg -i package.deb. Works great with just a couple of glitches with a few packages that don't want to uninstall (the different povray front-ends).

Re:great interview

[autechre]

As a RedHat-only person for a while, I've recently begun using Debian. It's GREAT.

Basically, you give it a pool of FTP sites, from which you want to choose packages. When you want to install a package, you tell it. If there are any dependent packages not installed, it asks your permission, then installs them. As packages are installed, it asks you questions so that they'll be configured and ready-to-run.

I use the unstable tree, and it's not :) For the most part, "unstable" right now means "sometimes dependencies might be wrong, oops". I've never gotten a broken package, or had any trouble using potato rather than slink.

apt is indeed incredibly powerful. I, for one, think that console-apt is DONE. It does everything I need it to, AT THE CONSOLE, with what is (to me) a great interface.

Re:great interview

[Stephen]

The release history seems to suck, but isnt that fixed by using something like apt to update all of your packages?

To some extent. In theory one ought to be able to upgrade one package at a time. But there's a particular problem at the moment as stable uses libc 2.0.7 but the packages in unstable use libc 2.1, and so won't run on a "stable" system.

Re:great interview

[slashdot-terminal]

To some extent. In theory one ought to be able to upgrade one package at a time. But there's a particular problem at the moment as stable uses libc 2.0.7 but the packages in unstable use libc 2.1, and so won't run on a "stable" system.

I think that the most important update is the one for libc. Just upgrade the libc version and you will be set. Right now you get just download it on a floppy and install as follows

prompt~# mount -t msdos /dev/fd0 /floppy
prompt~# dpkg -i /floppy/libc.deb

or something similar. Solves all your problems really quickly.

Re:great interview

[Gurlia]

I've been living off unstable for over a year now, from hamm through slink now on potato. :-) It did break a few times.. some people probably remember that notorious bash/libreadline breakage, for example, and the dependency nightmares when migrating from libc5 to glibc2 (libc6). But other than the occasional glitch, "unstable" is pretty much stable, and up-to-date system. One thing I learned is that when upgrading "critical" packages like bash/libreadline, libc6, dpkg, to name a few, these should be done separately from upgrading the rest of the system and monitored more carefully. This way, you get to immediately fix problems with the critical packages, without having your system crippled by other partially-upgraded packages whose installation stopped because one of the "critical" packages broke something.

Re:great interview

[Anonymous Coward]

The problem with console-apt is that it simply is no-where near as powerful as dselect.
It does the simple things more simply, but doesn't do the more complex things at all.

The future as I see it.

[Delta-9]

The question is, if Linux becomes very popular, would it still be Linux?

Depends on your definition of "very popular."

Nonetheless, I don't think it "would still be Linux" in the same sense. IMO, for it to become "very popular" a solid release/version/what-have-you would have to be released which had support out the a$$ -- that normal idiots could get to work. A version like this is not freeforming and "open," as I see it. So, it would not be the ever-changing linux of today.

-d9

Re:The future as I see it.

[slashdot-terminal]

Depends on your definition of "very popular."

As popular as windows it I guess.

Nonetheless, I don't think it "would still be Linux" in the same sense. IMO, for it to become "very popular" a solid release/version/what-have-you would have to be released which had support out the a$$ -- that normal idiots could
get to work. A version like this is not freeforming and "open," as I see it. So, it would not be the ever-changing linux of today.

Hmm.. Well we have "upgrade" versions of Windows 95/98 and We have NT service packs. It could happen. However that would still not be the only version of linux out there at all. Debian will always be there. The most likely candiate for my description would be Red Hat of maybe Caldera. This however would not really cause it to be stangant.

Re:Intervew???????

[Anonymous Coward]

Oh an interview :)

Yeah funny if you read the description of the article before posting it works wonders.

Re:QUESTION ABOUT OPEN SOURCE.

[Anonymous Coward]

WHEN WILL THE RECENT SLASHDOT SOURCE BE RELEASED??? Are we for open source, or not?

Never you fool. You see the fact that we at the great directorate of mankind meeting in the secret brotherhood of the holy ones decided that the time has not come for man to have access to this relic of the distant future.

Until you repent of all your sins you will not have access to the one true source.

Re:Intervew???????

[Anonymous Coward]

Jesus Christ, man!

Lay off the interview! It's not bad!

Re:I knew it

[Anonymous Coward]

I really can't see how that could be flamebait considering that it is officially illegal to be a member of the Natzi party or wear any of their insignia in Germany. Most of the current hate related crimes are actually carried out in America.

Perhaps I know

[Anonymous Coward]

If he has moderatored priviledges then that would be a cool thing to do.

Re:I knew it

[Anonymous Coward]

His name is not german, and he is not german.
Its a typical Name for a person from the Netherlands, and in fact he is dutch.

Telling Quote From Wichert

[mochaone]

by Christopher B. Brown Considerable improvements have gone into the "back end," apt-get; while there has been some experimentation with gnome-apt and console-apt, there doesn't seem to yet be anything that unambiguously improves on dselect in terms of functionality. With the things that have been learned from those attempts, is there likely to be some sort of dselect-ng?

Wichert: I really hope so. The reason that we don't have a super-glitchy-totally-awesome apt frontend at the moment is that we have nobody who is willing and able to invest the time and effort into making it. Unlike a commercial distribution, we can't just say `oh, this would be cool. You there! Write this for us and we'll give you some money.' Somebody has to decide for himself that it is an interesting project and make it. We can only encourage people to do something and be very thankful when they do.

This is the exact reason why a Redhat is needed. Now that they have the market capitalization they don't need to wait until someone wants to work on a particular project. They have talented people on the payroll that they can assign to work on needed technology. The Open Source attitude has been very successful to date, particularly because of the attitude expressed by Wichert that solutions arise from need and interest, but to grow Linux so that it can truly compete with MS and others, it needs to support technologies quickly. No more of this USB in the 2.3 kernel stuff or Firewire being supported who knows when. Linux needs to take off its training wheels and go play with the big boys. Adopting a big business attitude that can coexist peacefully with its Open Source origins will get it there and is Linux's greatest challenge.

Re:Telling Quote From Wichert

[sterwill]

I have the feeling you've never actually tried Debian, and I can fully understand your "support" of Red Hat if that's the case. Debian's distribution mechanism (not any specific release, but the development model) is, by far, the most advanced out there. Red Hat won't soon equal the number of packages and flexibility of Debian, billions of dollars or not, because they just don't have the masses of developers.

I find it odd how you make a training wheels analogy, and single out Red Hat (these days, the "first" distribution of the masses) as the company most likely to take them off.

--

Re:Telling Quote From Wichert

[Gurlia]

Well, there are both sides to the story. OT1H my personal choice of Linux distro will always be Debian, because I think the Debian philosophy is closest to Linux's Open Source roots: everything done by volunteers, no commercial $$$ bottomline driving you to compromise, but genuinely interested programmers and developers adding quality to the system.

OTOH being a volunteer community means that if nobody's willing to volunteer in a particular area, you've a problem. IMHO this is where commercial distros like RedHat are a good "motivation": they are commercial, so they can hire people to do a job that they see is necessary, but where nobody seems to be volunteering. As a result, the commercial distro gets the new feature/tool, which causes somebody out there to think, "hey won't it be nice if we had a similar tool in our free distro". Bingo, now you have a volunteer to do the job. (Of course, in most scenarios like this we'd probably just adapt the package from the commercial distro, assuming it's GPL'd, so there's no reduplication of effort. Another beauty of Open Source.)

Re:Telling Quote From Wichert

[sboss]

I have worked with Red Hat, Debian, SLS (forgot about that one didn't ya), Slackware, Caldera, kha0s, and several other distros. I think, and this is personal opinion, that the Debian way of using apt-get with the .deb files is the best way to maintain machines. I have an crontab entry that runs every night to update the list of packages out there and I can upgrade my system or install a new package very quickly and easily.

Debian is the Linux for the Community by the Community. Whereas Caldera & Red Hat have money and developers that can be put on any project (application/utility) that their boss tells them to. I can understand why Red Hat has a nicer looking installer, but functionality wise there is no way they can beat Debian. If someone could just write the front end the life would be good for Debian.

Thanks for listening to my ramblings,
Scott

Scott
C{E,F,O,T}O
sboss dot net
email: scott@sboss.net

Re:Telling Quote From Wichert

[termigan]

Ok, so he didn't quite have the right analogy, I think he's right. He also latched onto the fact that there are other things besides the UI that is holding Linux back. There are certain things that are keeping MS Windows alive. If there were an alternate that met these conditions there would be flocks going to it, even average consumers. This is our goal as the Linux community: "Beat Microsoft by being better than Microsoft." These are the things I see:

1. Software support - The average consumer wants lots of software. This is one of the bigest things holding challengers back. Even Macintosh is held back by this by a large extent.
2. Hardware Support - If an OS isn't up with the new hardware that comes out at a sometimes frenzied pace, MS will sell big becuase it has the hardware support. People like new toys.
3. Good instalation and update - Only give users choices they can understand. There are definite classes of users; newbie, partially seasoned, seasoned and power users. They are typically willing to identify what class they feel they're in. Capitalize on their assessment, give them help, give them more online help when they ask, and correct their assessment if you see they're asking for too much un-offered help.
4. Pretty User Interface - The Companies who build software with nice interfaces spend many hours studying the average user. I think this is the only way to understand them. They don't think like programmers, and they're not neccessarily going to gripe to the people who can change the the interface.

So where does Linux stand? Argue as much as you want, but I think we're behind the curve on all these areas, but we'll catch up. Take off your evangelist hat and ask yourself, "what would my parents or grandparents do with this?"

Make no mistake, those are big tasks, some of the tasks (like guiding a user at the proper level, polishing a UI.) aren't typically the ones that we as programmers flock to, we'd rather get something done rather than make sure that everyone else can do it too. At some point we'll get more help from the hardware and software industry at large. After all, even MS doesn't write all the software and drivers for its OS. Maybe it takes some money to get Linux to a place so we can get up some more steam. Red Hat is simply the first company with enough money to start working on these things.

Re:Telling Quote From Wichert

[Anonymous Coward]

ok here is my question

Redhat makes most of its money by selling user
support correct?

so what is compelling them to make a quality
product that is easy to use?

If they made a great distrabution that had no
problems and was easy to use they would go out of
bussness.

I say this as a relitivly new user who has had a
lot of problems with redhat that I don't
belive should be there

Re:Telling Quote From Wichert

[LetterJ]

I think of this idea like this. Imagine I live in a small town with one doctor/pharmacist. He is the only accessible medical professional. Now imagine that the whole town gets a mildly irritating rash. Not deadly, not even really a problem, just irritating. The doc might not stock calamine(sp) lotion . . . that is until he gets the rash. Then the itch hits him. The problem is that the whole town could be itching, but until he gets the rash, nothing is done about it.

That's kind of the way that OSS works now. There can be tons of people who have an itch: easy install, simple modem config, etc., but until someone with the skill is added to the group wanting it, nothing can be done about it.
LetterJ
Writing Geek/Pixel Pusher
jwynia@earthlink.net
http://home.earthlink.net/~jwynia

Re:Telling Quote From Wichert

[Patrik Nordebo]

If they don't make a quality product that is easy to use, why would people buy their product instead of Joebob's Easy Quality Linux, which is a quality, easy to use Linux? And if people don't buy their product, then why would they go to them for support, instead of Linuxcare or IBM? Even if they do intend to make most of their money from support, the distribution is what gets them the customers.
If they had a monopoly, they might be able to get away with poor products, but when there is competition, you need to compete, or you lose.

Re:Telling Quote From Wichert

[Anonymous Coward]

This is the exact reason why a Redhat is needed. Now that they have the market capitalization they don't need to wait until someone wants to work on a particular project. They have talented people on the payroll that they can assign to work on needed technology.

But they won't work on "needed technology" except by accident. All this money will be thrown at getting programmers to write things that will maximize revenue for Red Hat first and foremost. Sure, if Red Hat sticks to the GPL, it's unlikely that other distributions, even non-commercial ones, won't see some beneift. But let's not forget what motivates Red Hat. Let's also remember Bob Young's words. Users of other Linux distributions are not, to his mind, members of the "Linux community." So when Red Hat does things to benefit the "Linux community", they don't mean what every one else does.

Re:Telling Quote From Wichert

[Anonymous Coward]

I could care less if the motivation is recognition, altruism or money. As long as they contribute to the Open Source cause, they are all right with me.

Re:Telling Quote From Wichert

[Anonymous Coward]

Imagine I live in an absolutely massive community, that many doctors consider to be very worthwhile to live in. So much that >90% (guess) of medical professionals in the world, live in this community.

Now say some parts of the community get an itch, maybe even a large group. One doctor, out of the thousands of doctors out there, takes notice, and devises a cure.

However, this itch might be a strange itch which seems to only affect people new to the community, the people who've been there a while seem to be "miraculously" immune. One of these people, who have been previously struck by this new itch points the new community member to the local library which has specific instructions on how to deal with the itch, and lo, the new member is healed for life.

This is the way OSS works now. There can be tons of people who have a problem: can't install, can't understand modem configuration, etc., but the tools, documentation and resources are out there, and so are the people with the skill. But for the people with the itch, unless the go and help themselves to the feast of information out there, ... nothing can be done about it JML

Re:Telling Quote From Wichert

[reptilian]

"Support" doesn't necessarily mean end-user support. They offer it, but that's not where the big bucks come from here. It comes from big corporations who want Linux-based solutions for whatever reason (stability, cost, and now for the first time in linux history, vendor support).

Support could mean anything from a phone call from a confused end-user to outright training of some company's employees on how to work with linux.

In the corporate arena, quality is just as important as a support contract, or else company's considering RedHat solutions would have a lot less motivation to adopt them.

Man's unique agony as a species consists in his perpetual conflict between the desire to stand out and the need to blend in.

OT: Re:QUESTION ABOUT OPEN SOURCE.

[El Volio]

Hear hear!

CmdrTaco, we need the Slash code!

Re:OT: Re:QUESTION ABOUT OPEN SOURCE.

[Anonymous Coward]

I am pretty sure we will see the source to "slash" when hell freezez over.

Andover.net knows that the real way to make money is cater to the paranoia of Linux users but keep the benefits of proprietary code.

No releasing the code to "slash" in a timely fashion gave them a distinct competative advantage for enough time to establish a market lead. This led to the buyout worth millions.

The lesson is clear, use all the OpenSource tools you can, pay lip service to the concept and keep your code private.

As long as you let 'em rant against MS on your site, no one will care.

Reflections on the FreeBSD port

[Chalst]

My initial thoughts about grafting Debian on top of FreeBSD were:
uh-oh, the `pile anything on top of each other approach' to package
management is coming to the BSD world.

On reflection I think it is a good idea: getting Debian to work of
top of FreeBSD is a good test of the Linux compatibility mode. Its a
shame the Debian effort doesn't look very ambitious, but I guess its a
voluntary effort. A port of glibc would be a very good thing for
BSD...

Re:Reflections on the FreeBSD port

[Caelum]

> uh-oh, the `pile anything on top of each other
> approach' to package management is coming to the
> BSD world.

I don't know what you mean, but you probably haven't tried Debian. Package management is very fine grained, when you install a package a menu entry gets added to every installed window manager for example.

> Its a shame the Debian effort doesn't look
> very ambitious, but I guess its a voluntary
> effort.

Are you trolling or just misinformed?

Re:Reflections on the FreeBSD port

[Chalst]

I'm sorry if this looked to you like an anti-Linux/Debian flame, it
certainly wasn't meant to be. I do think there is a more casual
approach to building operating systems in the Linux world than in the
BSD world, and that isn't always a bad thing. `Fine grained' package
management is very much a symptom of this difference.

As for my remark about the unambitious nature of the grafting of Debian
onto the FreeBSD kernel, I was referring to Wichert's comment about it
being done through the Linux compatibility patches. This was less
ambitious than I first understood the effort to be, namely a port of
glibc and a recompilation of the source against BSD libraries.

pentium optimization

[jajuka]

One constantly hears conflicting opinions on pentium optimiaztion. Advocates say it will give you a performance hit on 486s and the like but you should see an improvement on any pentium class machine. Opponents frequently say it wont run at all on a 486 and you'll see no improvement or a hit on AMD or other p class chips. I'd like to see these benchmarks people keep mentioning.

As for Wichert's statement that it only really helps with certain programs, I'd like to say the ones it does help with seem to be important ones. I'm currently using a Dual PII box on which I have run both Debian and Stampede, and while I didnt sit around doing benchmarks all day, I did notice a very large difference in the performance of KDE. Even if pentium optimization only helps out with things like KDE I'd say it's worth it.

Re:pentium optimization

[MoNsTeR]

Agreed, which is why I asked the question.

The one I've heard most often, and the one that makes the most sense to me is that pentium-optimized binaries will not run at all on 486's. Personally, I don't see this is a problem any more, since I can't fathom that any significant number of linux boxes are 486's anymore.

As for optimizations not making much of a difference, that's what I said when it was first mentioned to me. I thought, "yeah, right. what can a few compiler optimizations *really* do for most of my programs?" Then I tried it. I tried Stampede, and now run TurboLinux and I'll tell you, the difference can be huge. I said this in a reply post in the original story, but I'll repeat it here. Comparing MP3 encoding speed using BladeEnc, my Celeron 450 beats my friend's dual Celeron 466 by about 25% in encoding speed. At the time of the test, he was running Debian 2.1, I was (and still am) running TurboLinux 3.6. Lots of people complain about how many CPU cycles XMMS chews up. Me? I compiled it with -06 -mpentiumpro and top shows each xmms thread using 0.0% of my CPU time. For each program, it might make only a small difference, but it tends to add up.

MoNsTeR

Re:pentium optimization

[Anderson]

Okay, here's some perspective on this from a computer architecture standpoint. "Pentium Optimization" is only some specialized scheduling to take into account the weird structural conflicts that arise in the original Pentium (and MMX) chip from Intel. This can give as much as a 30% performance increase (that's the number Intel likes to bandy about, so add salt) on integer code. But this -only- applies to the original Pentium and the Pentium MMX. Any other CPU out there gets no benefit, and some (e.g. 486's, AMD K5, Cyrix 5x86) actually slow down either from the increased memory bandwidth utilization, or because their own internal resource usage requirements conflict with those of the original Pentium.

Now the fun part -- what about the K6, the Cyrix 6x86, Pentium Pro/II/III/Celeron, and the Athlon chips? Well, you can schedule specifically for them as well, but you won't see as large of a performance gain. The reason is that all of these CPUs have much better on-chip dynamic scheduling (out-of-order execution, register renaming, speculative execution, etc.) and thus don't need really good scheduling back-ends to achieve fast performance. This is especially true of the Athlon and Intel P6 core chips -- if you didn't know, the Pentium Pro, Pentium II, Pentium III, and Celeron are all very close architecturally, and are known as the P6 series (and oddly, they have almost -nothing- in common with the original Pentium and Pentium MMX).

When are these machine-specific optimizations important? Well, for compute-intensive stuff that you execute a lot. So if you want 99% of the benefit of using a compiler that schedules for your CPU, recompile your C libraries, your X server, and any large applications (KDE is a good one). I will say that a lot of the performance difference you probably see between a "Pentium optimized" distribution like Mandrake or Stampede and something like Debian is not really due to scheduling for the Pentium -- it's probably in the makefiles used for compilation, in the choice of compiler code optimizations like -O2 vs. -O3 (the fastest instructions, after all, are the ones you don't execute :), etc. That doesn't mean "Pentium optimization" doesn't help, but it only makes a major difference for the original Pentium and Pentium MMX, AFAIK. The dynamic scheduling hardware in more recent CPUs can in effect "Pentium optimize" (e.g. reschedule) any code they encounter on the fly.

Also, don't discount the user perception optimization factor. Tiny differences in latency, load speed, and just the knowledge that you're using a "pentium optimized" distribution can make a large perceived difference in the speed of a system, regardless of the actual performance delta.

Re:pentium optimization

[Anderson]

To elaborate on my other post below, while I don't have the numbers to back it up I'd be willing to bet that 95% of your performance difference is both in the -O6 and the version of gcc you're using, not the -mpentiumpro switch (although that helps a bit). Perhaps Debian should be more aggressive in their use of compiler optimizations (standard Debian flags are -O2 -pg, then strip the binaries), but again, I don't think architecture-specific optimizations are the real difference here. Especially not for Celerons, which have robust dynamic scheduling onboard.

Re:pentium optimization

[jajuka]

*nod* Yeah, I probably should be more specific when speaking about optimization. AFAIK all the distros which do "pentium" optimization include a healthy amount of -06 type optimization as well, which may well be the source of good chunk of the benefit.
Perhaps you can answer something else for me, the scheduling optimizations aside, I was under the impression that a portion of "pentium" optimization was the utilization of instructions not present on 386 and 486 cpus but are present on the non-intel pentium class chips. Is that true?

Re:pentium optimization

[Shadow Knight]

I'd have to disagree with you here... it's definately the architecture specific optimizations. I also have a Celeron 450, so I decided to perform a test: xmms compiled with -O2 uses more cpu than xmms compiled with -O2 -march=pentiumpro, which does more than optimize: it uses PentiumPro specific instructions, and *will not* run on anything else. Compiled that way, it never shows up as using any cpu cycles at all, which is obviously ridiculous, but I guess it's just falling beneath the tenth of a percent threshold.


Supreme Lord High Commander of the Interstellar Task Force for the Eradication of Stupidity

Re:pentium optimization

[RelliK]

I didnt sit around doing benchmarks all day, I did notice a very large difference in the performance of KDE Even if pentium optimization only helps out with things like KDE I'd say it's worth it.

Same here! I don't have dual PII. I used to have Cyrix 200 and 2 weeks ago upgraded to AMD K6/2-300. (So much for slowing down non-Intel CPUs). (Oh, I'm running Mandrake, not Stampede). I noticed a significant improvement of KDE performace in Mandrake compared to SuSE or RedHat.

Secondly, you can't really run KDE on a 486 anyway (even KDE developers admit it). Pentium optimizations for just KDE (or just GUI for that matter) would help.

Finally, from reading comp.os.linux.mandrake, I heard that Mandrake actually does run on a 486, despite what some people claim.

That is not to say that I want 486-optimized distributions to die. I am happily running Debian 2.1 on my 486 which I use as a IP masq gateway and a ftp / samba server.

Re:pentium optimization

[David Greene]

Just one more point to add:

Compiler scheduling can make a difference on an out-of-order machine. After all, the instructions are still fetched and decoded in-order. You compiler can schedule for decoder hazards and latency. This might be useful on a P6-style machine, where the decoding of different types of instructions use different resources (there are some limited number of simple, complex and microcode decoder engines).

The compiler can look much further down the code than the limited instruction window in an O-O-O processor. So even traditional scheduling can help on O-O-O machine because the compiler can grab code from "far away."

--

Re:pentium optimization

[RelliK]

Comparing MP3 encoding speed using BladeEnc, my Celeron 450 beats my friend's dual Celeron 466 by about 25% in encoding speed.

Important point - dual or not dual is irrelevant in this test. Bladeenc is a single process and will use only one CPU. In order to use both CPUs you'd need to run several instances of bladeenc simultaneously (i.e. encode at least 2 files at a time).

Re:pentium optimization

[Anonymous Coward]

The thing that gets me, is that they say: "This only helps those on Pentium boxes, and wont be of any use to those on non-Pentium boxes. However, you might want to get an Alpha and try the Alpha port." This is like saying: "The Alpha port only helps those running Alphas, and doesn't do any good for x86 users. Therefore, since it won't help out x86 users, were not gonna do an Alpha port." I'm not advocating that the x86 port be turned into a Pentium optimized port, instead, keep the generic x86 port, but have a Pentium optimized (along with a K7 optimized, etc.) port and treate them the same as a Sparc, Alpha, or PPC port.

Re:pentium optimization

[jmweeks]

The pentium did add instructions to the x86 set that earlier processors can not execute. PPro added a few more. But the first real performance-enhancing instructions, as far as I understand, were the MMX instructions in later Pentiums and up.

I'd list a few of the added instructions for you if I had the documentation here, but I don't have it in front of me.

The vast majority of (and this is from an assembly-language perspective, so I don't know how well it comes into play for optimizing compilers) optimizations on the pentium rely mostly on using the second arithmetic core as much as possible (the first core was always used, the second only in special situations, so ordering instructions to use both as much as possible could theoretically cut execution time in half), careful use of the cache, and avoiding branching (which was a good optimization strategy for any x86 processor).

The point here is that to optimize, the best strategy is basically to eliminate big, uncommon (this would include the new) instructions (stick to ADD, SUB, shifts, and string instructions when possible). Using such a strategy will likely do little for 486- processors either in faster or slower execution, but would allow for execution on such machines.

Jose M. Weeks

Re:pentium optimization

[c-A-d]

Finally, from reading comp.os.linux.mandrake, I heard that Mandrake actually does run on a 486, despite what some people claim.
For the record, Mandrake will run on an ALi m1489 motherboard with an AMD486DX4-100 and 32MB of EDO RAM... I couldn't really tell you if I took a performance hit because KDE is slow on a 486. (Word to the wise, BlackBox is best on a 486), but it did seem to run fine.

Completely unrelated, but the Mandrake I installed defaulted to XDM/KDM which doesn't make me happy...

Somewhat related, my box is quite snappy for a 486 and KDE runs acceptably slow (no slower than Win95 OSR2) so maybe I am an exception to the rule.

Re:pentium optimization

[rcw-home]

I'd imagine the Celeron 450 was running at 100mhz bus speed though... 66mhz to 100mhz is a 50% bus speed increase.

Re:pentium optimization

[jajuka]

AC wrote:
The thing that gets me, is that they say: "This only helps those on Pentium boxes, and wont be of any use to those on non-Pentium boxes. However, you might want to get an Alpha and try the Alpha port." This is like saying: "The Alpha port only helps those running Alphas, and doesn't do any good for x86 users. Therefore, since it won't help out x86 users, were not gonna do an Alpha port." I'm not advocating that the x86 port be turned into a Pentium optimized port, instead, keep the generic x86 port, but have a Pentium optimized (along with a K7 optimized, etc.) port and treate them the same as a Sparc, Alpha, or PPC port.

Someone should have moderated this guy up instead of wasting points bouncing Wichert's "first post" post up and down.

That would be extremely cool, and considerably easier than an actual "port". There is the issue of available disk space for such a project, I dont know if that's easily available or not.

If they choose not to do something like that an "apt-get build -mk7 -O6 mypackage" type command would be a good substitute for those with bandwidth to spare.

Re:pentium optimization

[Anonymous Coward]

That hard part about that apt-get build command is that it's close to impossible to pass options to the build process in a consistent way. You can already do "env CFLAGS=options apt-get -b source ; dpkg -i .deb", but while that's the most portable way to do it, it will still only work for ~15% of build scripts (number made up). And modifying build scripts so that it will work can be highly non-trivial, and is generally impractical for package maintainers. And even if you did that, then as soon as a new version of the package came out (I run unstable, and download ~10-20 updated packages a day), yours would either be replaced, or, if you put that package on hold, become out of date. Finally, even this will have to wait until the new Build dependencies are used more often. All in all, a tricky problem.

Re:pentium optimization

[MoNsTeR]

"Important point - dual or not dual is irrelevant in this test. Bladeenc is a single"

I am aware that single-threaded apps benefit not from an SMP system, as I own and treasure one myself. However, when a program that wants as much CPU as it can get, such as BladeEnc, is run on an SMP system that is not bearing any other significant load, it's pretty much guaranteed to get one entire CPU to itself. So on Jonny's dual 466, BladeEnc had 466MHz all to itself, whereas on my 450, some of those cycles were going to the system daemons. Not very significant, probably a total of 3% or less, but still non-zero.

MoNsTeR

Re:pentium optimization

[MoNsTeR]

Yes, 100MHz FSB versus 66MHz is a 50% increase. But BladeEnc is CPU limited, not bandwidth limited. It might as well be running on a 1GHz FSB, it wouldn't make any significant difference in this or most other tests/cases. Intel would like you to believe otherwise ;)

If anyone else has an -O6 -mpentiumpro BladeEnc running on an egcs-compiled distro / 466MHz CPU, would they care to do some encodes (at the console, of course) and report the *.**X results for comparison?

MoNsTeR

Re:pentium optimization

[demon]

No, it's a little different than that. Basically, for each processor group (Pentium, Pentium/MMX, PPro, PII, PIII, K6 and friends, K7) you'd hafta do a different build of EVERY package. That's a lot of wasted space just to support one platform. I'll agree with Wichert, and say it's pretty wasteful - may as well use the space that'd otherwise be wasted on variation-specific binary packages for x86 systems for supporting the different platforms.

Re:pentium optimization

[Anderson]

The optimal instruction selection is, as expected, different for the different CPUs. I was lumping that into "good scheduling" rather unprecisely. There are additional instructions defined by the Pentium and P6-series processors -- for the Pentium MMX processors, this is mainly the MMX instructions. The problem is that MMX is only applicable to algorithms that do significant amounts of vector-like integer work, and is furthermore a little difficult to code in an automated manner (e.g. by a compiler). The Pentium Pro (Cyrix 6x86 and Athlon also have this, I believe) adds some conditional move (CMOV) instructions, which can be used to fold control dependencies (branches) out of the way. In a deeply pipelined processor like the PPro or Athlon it's a big win. I'm not sure of non-MMX instructions added by the Pentium, but there are probably a few. There's of course the 3dNow! instructions from AMD (and iSSE from Intel) for SIMD floating point that accelerate things much like MMX -- again, no one has put compiler support for those out in the world at large yet, to my knowledge.

Re:pentium optimization

[Anderson]

Yeah -- for more precise timing measures, you might try running xmms in a non-interactive mode (is that possible?) and using the "time" command to get better measures of CPU cycles used. For floating point (and I forgot to mention this, duh) the P6 processor series can *really* benefit from architecture-specific scheduling. It has to do with the floating-point pipelines having a shared multiplier, and good scheduling can really boost the floating-point performance of the P6-series CPUs. Silly me for forgetting that. For the context of this thread, you might try seeing if "-O2 -march=pentium" gives you much of a performance boost -- after all, I don't think there are any "Pentium Pro/II/III/Celeron Optimized" Distributions out there, regardless of how much more efficient xmms is. :) Another (IMHO better) test would be to recompile something like the Python or Perl interpreter with these optimizations, and see what sort of speed benefit you get. gzip is also a good candidate for architecure-specific optimizations ... but in any case, test this on something that isn't so floating-point heavy, since you're right that the Celeron (being a P6-core processor) really likes good floating-point scheduling. That doesn't change my assertion that a "Pentium Optimized" distribution gains most of its speed from better non-architectural compiler optimization.

Re:I knew it

[Anonymous Coward]

I know a guy at work with a german name, but he isn't nazi, I asked him.

I know nazi's can lie about being nazi's, but I belief him, because he doesn't lie, because he said he didn't.

and that is why you have to pay for commerical software, dam redmond people.

apt libraries aren't perfect (yet)

[Daniel]

The apt library is really powerful and does everything you want it to do,



In fact, the poor and out of date libapt documentation aside, this isn't true. Among other things, libapt isn't good at:

-> keeping track of automatically performed selections and removals; each frontend has to do this itself
-> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs)
-> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.

Not that it isn't a wonderful tool, but it's not perfect -- not by a long shot.

Daniel

Shameless plug: I have a very early prototype of an alternative apt frontend at
aptitude.sourceforge.net

. Please download it and send me comments so I can fix problems in the next version!

Re:apt libraries aren't perfect (yet)

[FagFace]

Among other things, libapt isn't good at: -> keeping track of automatically performed selections and removals; each frontend has to do this itself

Which is as it should be. If a user want to keep logs, she can use shell redirection.

-> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs)

Again, this is exactly the kind of thing which should be handled by a front-end. In any case, a user can always hit Ctrl-C during a download, edit the command line, and apt-get will recover quite nicely.

-> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.

You can put packages on hold using dselect (an annoying program, IMO, but functional), though admitedly I've had apt loudly proclaim it was going to over-ride my hold on a package, and then proceed to enthusiasticly upgrade it without even prompting me. I should probably submit a bug report on this, I suppose, but at least it acknowledged the hold was there.

Re:apt libraries aren't perfect (yet)

[wichert]

I mentioned your project. I was kind of surprised to see there was such a project while it was never mentioned on any debian list as far as I know.

But, to address your points: dpkg and the package system in general will see some modifications once potato has been released. To give two examples: dpkg will be able to log all changes made to packages (longstanding wishlist item), and you will be able to tag a package with a Origin. This allows you to only upgrade to newer versions from the same origin which is very useful if there are multiple versions available.

It has been possible to put a package on hold for ages though, perhaps you missed something?

Re:apt libraries aren't perfect (yet)

[Anonymous Coward]

Poor and out of date documentation? For one thing, all of the source code comments and out-of-source documents (such as the cache and method documents, man pages etc) are meticulously kept up to date with source changes. If there is any 'out of date' commentry, it is certianly not in the majority.

As for the quality of documentation, it could be better, but there is already 4 thousand lines of out of source documents! Each module also has a heck of alot of commentry and there are many example cases from the various available GUIs.

Your first point was explained in your question to the mailing list, the second point is IMHO against the spirit of the download code and the third was also answered on the mailing list.

One thing I haven't said, is that the apt-pkg feature set is based on the demands of the programs actually using it, it is not static - and I haven't seen any detailed feature proposals lately :>

Anyhow, your GUI is really quite nifty, it reminds me of the original unfinished APT gui - see http://www.debian.org/~jgg/apt/screenshots/

Jason

Re:apt libraries aren't perfect (yet)

[Daniel]

I didn't notice that you mentioned it. Thanks!
I haven't announced it in any official way yet, simply because I want to get a reasonable amount of functionality (ie, downloading and installing packages) first -- I don't want to announce total vapor on the mailing lists; I feel comfortable doing it on Slashdot, I guess. I'm not sure what that says about me.. :-\

It has been possible to put a package on hold for ages though, perhaps you missed something?
Can you actually put a package on hold from /libapt/? I've been thinking that I'll have to write my own routines to handle the dpkg status file if I want to do that.

Thanks,
Daniel

Re:apt libraries aren't perfect (yet)

[Anonymous Coward]

To put a package on hold, you might be able to use the libdpkg library (what _is_ that thing, anyway?), or, for sure, you can just do the C equivalent of "echo hold | dpkg --set-selections".

Re:apt libraries aren't perfect (yet)

[Daniel]

Which is as it should be. If a user want to keep logs, she can use shell redirection.
No, you misunderstand totally (I think Wichert did too, I may not have expressed myself clearly). I don't mean keeping track of what *was* installed, but rather keeping track of what's *going to be* installed. That is: I decide to install package foo, so I tell the frontend to mark foo for installation. The frontend does, and happily marks bar, baz, and frobozz as well. I have no direct way of finding this out via libapt; moreoever, the *frontend* doesn't know. The latter problem prevents the implementation of an undo command.

There's a workaround for this, but I personally think it's ugly. This isn't really the worst problem, though, and libapt is arguably correct in its behavior here.

-> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs)
Again, this is exactly the kind of thing which should be handled by a front-end. In any case, a user can always hit Ctrl-C during a download, edit the command line, and apt-get will recover quite nicely.
Perhaps you didn't read what I wrote? There is *no* *exposed* *way* in the libapt API (at least, none that I can find, and I've looked for a while) to terminate a single download process. That is, if the user starts a large download and then decides that everything's ok, but that one Netscape package shouldn't be installed, the *whole* download has to be stopped and restarted.

The Acquire system is also not very well suited for background downloading (ie, in a separate thread).

-> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.

You can put packages on hold using dselect (an annoying program, IMO, but functional), though admitedly I've had apt loudly proclaim it was going to over-ride my hold on a package, and then proceed to enthusiasticly upgrade it without even prompting me. I should probably submit a bug report on this, I suppose, but at least it acknowledged the hold was there.

Yes, and my frontend automatically inherits dselect's selections when it starts (err..the CVS version does, got to upload the tree to Sourceforge one of these days..) but there is no way to modify the saved state from apt (unless I'm mistaken, Wichert said he thinks I am, so I may very well be), which makes it useless as a replacement for dselect at the moment.

I expect that some of these will eventually be fixed, or that people will yell at me to be more creative in working around them ;), but my point was that libapt is very far from supplying 'everything you could want' to build a frontend.

Daniel

Re:apt libraries aren't perfect (yet)

[Daniel]

I'll see whether that works -- but I believe that apt locks the dpkg status file when told to lock anything (with good reason!), so I doubt that the dpkg call will work. libdpkg might.

Daniel

Re:apt libraries aren't perfect (yet)

[Daniel]

Jason, I apologize for the negative and critical tone of the earlier post. libapt is truly wonderful; I was just attempting to point out a few things that could be improved. I'm still not convinced about point #1, and I don't remember getting an answer to #3. I'll go check my mail archives.
I actually queried the mailing list on #2, but I haven't gotten an answer. I think this is an important ability, mainly because it's required for a really nice (IMO) UI feature I have in mind :) I believe my message to debian-deity has more information. Could you explain at length why this is not a good idea, and what (if anything) could be done to make it a good idea?

And finally, I'm sorry but I still don't agree on the documentation issue. I have several times run into stuff that the files in /usr/doc claim exists but has turned out to not be useful (I believe I actually asked you about InstallVersion and xstatus, and was told that they were experiments that weren't relevant anymore), and it's difficult to find out what any given function does in full.
Usually I just end up tracing through the source code to find out; a brief collection of documentation that gives a more high-level overview of Workers, CacheFiles, Acquire queues, and all the other stuff would make it a lot easier to get up to speed; while you can guess in general what these do, the specific relationships between them are not always clear and the documentation in the headers is somewhat spotty. If you want, I could actually probably write up some general libapt documentation -- but I have to admit that I'm also guilty of "I'd rather code" :-\.
How the system works can be pieced together from the source and headers, but that doesn't necessarily mean that the documentation can't be improved.

In general: it's no secret that libapt, like any piece of software, has missing functionality and is constantly changing. But I think that it still has a little ways to go before it does 'anything you want'. It might never be there, since everyone (as I've just demonstrated) defines 'anything' differently. So maybe my complaining is totally pointless. Or something... :-/

Thanks,
Daniel

I'm really starting to think that that post was a mistake. Chewed out by you and Wichert in the same day..it has to be some sort of record..

Re:Anti-Semitism

[hattig]

Okay....

Things like this make me happy not to live in America. How about an option on Slashdot where posts can be moderated to 'free speech -1' and so we can select not to view the posts that are here due to free speech (but still view low rated posts). The fact is that the poster has no responsibilities for the other people on Slashdot, so the overall experience is ruined for those people. With rights comes responsibilities. If you abuse your responsibilities you should lose your rights!

Just my opinion anyway.

Nice to see that Debian is moving towards a FreeBSD style packaging system, but looking even more advanced. A hierarchical packaging system would kick ass:

• All
• • Server
  • Mail
  • Web
  • Other
• Games
• • Terminal
  • X
  • SVGAlib
• KDE
• • Basic Components
  • Games
  • Apps
• Gnome
• • You get the idea

So you could include as many or as few of the packages as you wanted in a distribution, that would be great.

I don't get it.

[AntEater]

I still don't understand why KDE and related programs can't be packaged under "non-free" and distributed as such. QT doesn't seem that much less open than, say the pine sources or the GIF plugins for gimp. What am I missing here?

Re:I don't get it.

[PiMan]

The reason for this is that, technically, KDE is illegal. pine and libgif (or gimp-nonfree) are just that - non-free. However, there are legal grounds for modification and redistribution (or lack thereof).

KDE, on the other hand, is linking GPLd source (KDE) with QPLd source (Qt). The QPL is not compliant with the GPL, however, and you reach a slew of legal problems were this issue to come up in court. Now, like they said, KDE 2.0 should either change the QPL a bit to be GPL-compliant, or should change the KDE license to contain a QPL exception clause (much like the one LyX has right now).

Re:I don't get it.

[ptw]

Read the licence. Qt lib is definately not gpl or DFSG compliant. KDE is non-free and belongs in non-free. If Troll Tech feels so inclined to review and change thier licence to be compliant with the GPL they are free to do so. Same for GIF and the WU licence

Re:I don't get it.

[Anonymous Coward]

Qt had a licensing conflict back in the day that stated something like....

if you put our crap on your CD and sell it, you have to give us some money...

etc etc etc.. but they fixed that all and now the entire world can live as one (- that lyric was open sourced by john lennon)

Re:I don't get it.

[Anonymous Coward]

Packages in non-free still have a valid license that allows them to be there. The problem with KDE was that some apps are licensed under the GPL and linked to Qt. Since the GPL is not compatible with Qt in the first place, the license is void.
If you wrote the software, it's easy to change the license to something else. It's more difficult when many people contributed (as authors or by contributing substantial patches) because they all have to be reached and all have to agree. It's more difficult when you port someone else's GPL code to Qt, because the copyright holder presumably never wanted to allow you to do that in the first place (and hence licensed under the GPL).
Having said that, I don't enough about KDE to tell how much of it falls into each of the above categories.
Peter Galbraith psg@debian.org

Re:I don't get it.

[Arandir]

"The reason for this is that, technically, KDE is illegal."

Nonsense! This is just Redhat propaganda. If it is illegal, what grounds would you give a judge to issue an injunction on

The -old- Qt license gives explicit and upfront permission to link Qt to GPL apps. So KDE is in full accord with the old Qt license. KDE is KDE is KDE (a is a), thus KDE is in full accord with its own license. So what's the problem?

Debian's problem with this is that they have too many chiefs that they have to please.

Re:I don't get it.

[Arandir]

The status of the -old- Qt lib does not put KDE in the non-free directory, only in the contrib directory. Bone up on your debian policies.

The new Qt lib is fully DFSG compliant. GPL compliance has nothing to do with it, and you can find hundreds of non-GPL stuff in dist.

Debian thinks that there is a license conflict, but this conflict is is free versus free, so nothing belongs in non-free. Perhaps they need a new directory called "politically incorrect".

But why should Qt be made GPL compliant? After all, it is the GPL that is incompatible with the QPL, and not the other way around.

Re:I don't get it.

[Anonymous Coward]

Technically, some of the KDE programs are ports of software that was originally released under the GPL. Debian takes the view that GPL-licensed software prohibits linking with Qt, so as far as they are concerned, some KDE programs are in violation of the GPL. They don't want to ship any software that is in possible violation of a license until everything is sorted out between the KDE people and the original authors of these GPL programs.

Re:I don't get it.

[isenguard]

As you note, the GPL is incompatible with the QPL (though the KDE developers can add an exception to the GPL to allow linking against QT). It isn't a problem with QT 2, which satisfies the DFSG. The problem is that it is not legal for Debian to distributed KDE without a license change.

Re:I don't get it.

[Arandir]

"The problem is that it is not legal for Debian to distributed KDE without a license change."

It's perfectly legal. If you don't believe me, just ask any KDE developer whether you have permission to redistribute their work. Everyone of them will say yes.

That there is a possible confusion over whether the GPL allows GPL applications to be redistributed is mind boggling to me.

Taking a pre-existing GPL application and modifying it to run with a QPL library could possibly be against the license, but that is not the case with KDE.

Re:I don't get it.

[Ian Bicking]

Taking a pre-existing GPL application and modifying it to run with a QPL library could possibly be against the license, but that is not the case with KDE.

By jove, I think he's got it.

That's exactly the issue with KDE. Like any good open source project, KDE reused code from other projects. That code was GPLed. The original authors specifically chose to use the GPL, and that specifically excludes Qt. (though perhaps the system library clause of the GPL allows Qt, but that's a different issue)

Now, to make KDE legal they have to relicense their programs where they used the GPL (there is a push for Artistic licensing in KDE apps) or add an exception to the GPL. To add an exception to someone else's licensing requires the person's permission. To become legal, KDE has to get the permission of a lot of people. It's not an insignificant issue.

Re:I don't get it.

[Anonymous Coward]

That was basically the kfloppy utility. It apparently contains some code from Linus Thorvalds.

All other KDE code was written by the KDE team _with_ Qt. It's anal of Debian to state there was a license conflict. Why don't they ship everything but kfloppy?

Re:I don't get it.

[Anonymous Coward]

Wrong. Read the former Qt Free Edition license: Money was never an issue. It was freely redistributable (in fact, Debian distributed it).

Re:I don't get it.

[Anonymous Coward]

It is an insignificant issue because your "third party GPLed applications" are simply not exisiting in KDE: KDE is written from scratch.

The huge amount of "thurd-party" code is pure Debian propaganda. Don't believe everything you read. Last time they discussed that, they came up with the kfloppy utility. A few hundred lines of code from Linux Thorvalds in order to justify the exclusion of over 1.000.000 completely unrelated lines of newly written free source-code in Debian? And that despite the fact that Linus stated in public that he likes both Qt and KDE.

Re:I don't get it.

[screeching weasel]

open sourced my ass. try recording and releasing your own version of John Lennon's "Imagine" without getting permission and see how fast the lawyers come knocking.


one down, three to go....

Re:I don't get it.

[rcw-home]

What everyone else is saying is that that is the case with KDE.

Re:I don't get it.

[rcw-home]

Ok, so you can link Qt to GPL apps. Can you link GPL apps to Qt though?

The grounds are unlikely but possible. A copyright holder of an originally-non-Qt'd GPL app would have to file a suit against someone who was distributing (GPL covers distribution) the Qt version of the app.

Re:I don't get it.

[Phil Hands]

Debian takes licenses seriously

I do hope that you are not suggesting that we should ignore people's licenses.

Last time I looked at the KDE source, it was licensed under the GPL. If that's changed, fine, good, it's about time, but I think you'll find that they've still not actually changed it.

OK so if you read the GPL, you'll find that it conflicts with the Qt license, and that it insists that you not distribute GPLed software under these circumstances.

[BTW, the QPL makes no difference here. a) it conflicts with the GPL as well, and b) Qt is not yet under the QPL anyway]

Yes, that's right folks. Debian doesn't distribute KDE because the KDE developers asked us not to (in the code, by using the GPL).

Rumours that the KDE team are going to fix the license are very encouraging, but unfortunately we're talking about a legal contract here, so it's what the contract says that's important, not what the person that hands you the contract says.

N.B. I have nothing against KDE, or Troll Tech, or the QPL, or non-free software or people choosing any license they like for their own work.

I do have something against being told to distribute software without a valid license. People who call for Debian to ignore the KDE license problem are asking me personally to distribute something that I have no license to distribute (I own the UK mirror).

OK, so I know that the KDE crew have no intention to sue me for illegally copying their software, so why am I worried about it?

1. I'm paranoid. How about if someone evil bought Troll Tech, for the sole purpose of killing the Free Software movement by suing each and every one of us for illegal distribution of Qt?
2. I like the GPL, and so I don't like it when it's mis-applied, because I think that allowing that to pass might tend to dissipate the power of the GPL.

Cheers, Phil.

Re:I don't get it.

[Phil Hands]

KDE is written from scratch.

If that's true, they can just change the license to a valid one, right?

So any time they want to do that, Debian will end up distributing it. That's how legal contracts work.

Would you sign a contract to work for me for the next ten years, for no money? How about if I told you that I didn't mean what the contract said, and that I'd actually be paying you 10,000 pounds a month? Would that make you sign?

I think perhaps you'd want the contract changed to reflect my claimed intentions.

Re:I don't get it.

[Anonymous Coward]

> Nonsense! This is just Redhat propaganda. If it
> is illegal, what grounds would you give a judge
> to issue an injunction on

*Sigh*
There's so much misinformation on both sides.

Didn't you read the article?

> The -old- Qt license gives explicit and upfront
> permission to link Qt to GPL apps. So KDE is in
> full accord with the old Qt license. KDE is KDE
> is KDE (a is a), thus KDE is in full accord
> with its own license. So what's the problem?

Qt can link with the GPL, but the GPL explicitely
states that you can't link in non-operating system
libraries. The reason for this was that it was
trying to close a loophole in the GPL.

If Qt were an operating system library, there
won't be a problem with KDE, but it isn't. Thus,
KDE is illegal.

To get around this, KDE can't use the GPL --
KDE either has to use another license or use a
modified version of the GPL that allows linking
to Qt. Troll Tech doesn't have to change the QPL
to accommodate Debian or Red Hat.

If that's the case, then why is Debian and Red
Hat distributing an illegal version of KDE? I
suspect that it's because the KDE people have
promised to solve the licencing issues by the
next version. It's a good faith measure. I'm
sure that they would have waited for the KDE
license change if it weren't for the popularity
of KDE.

> Debian's problem with this is that they have
> too many chiefs that they have to please.

That's a strength (increased quality of software,
and decreased ambiguity), not a weakness.

Re:I don't get it.

[Anonymous Coward]

b) Qt is not yet under the QPL anyway Yes it is. This whole situation has been completely blown out of all proportions. What GPLed code in KDE is taken from other projects? I don't know of any. We are arguing about whether KDE developers are going to sue people for using KDE, it is a bit silly.

Re:I don't get it.

[Arandir]

"If that's true, they can just change the license to a valid one, right?"

Even though KDE was written from scratch, there was more than one developer. You still need to get "The KDE Team" to agree.

Re:I don't get it.

[Anonymous Coward]

Personally I think the KDE developers agree to allow use of their code in KDE when they check the code into CVS. They do so with full knowledge that it will be linked against QT and redistributed.

KDE developers suing people for using KDE would be like offering my hand for someone else to shake and then suing them for assault when they touch me. (As technically it's assault if I really didn't want them to touch me).

It's a non issue.

Re:I don't get it.

[Arandir]

"Qt can link with the GPL, but the GPL explicitely states that you can't link in non-operating system
libraries. The reason for this was that it was
trying to close a loophole in the GPL."

This clause does not refer to the licensor, KDE. And it doesn't say what you think it says. The paragraph in question is talking about source code. It is merely requiring that the source code for all modules be included in the distribution. Whether or not Qt is a module of KDE is beside the point, the Qt source code is already available from the same places you get KDE.

Simply, it says if you distribute KDE then you should also distribute Qt.

Re:I don't get it.

[Phil Hands]

Oops.

I'd missed the fact that Qt2 has actually been released now, and is so now (as you say) under the QPL.

Sorry about that.

KDE is still linked against Qt1 though (or have I missed that announcement too ?)

Re:I don't get it.

[Anonymous Coward]

The last stable release of KDE, 1.1.2, onlys links against QT 1.4x. I'm actually not sure whether these earlier QTs have been released under the QPL or not.

KDE in head branch is linked against QT 2.1 (which is under development) snapshots. An alpha release of this is due in two weeks.

Re:I don't get it.

[PiMan]

OK, let's go over this one more time...

First of all, a standard GPLd app cannot be linked with Qt, due to the fact Qt is not GPLd. This is due to the clause in the GPL stating all code linked to GPLd code must also be GPLd, or be under a more free license (BSD, PD).

The problem here is that you're not realizing the QPL and the GPL are incompatible licenses. KDE (GPLd) is free. Qt (QPLd) is free. That doesn't mean you can mix them.

As for your last statement, I'm completely lost. Qt and KDE are not on the same site, they're not even coded by the same people. What the operating systems clause refers to is something like libc, libm, C++ STL, or Motif - libraries that are essential to program operation, and that have a GPLd equivilant.

As for the accusation of me buying Red Hat propoganda, I'm very offended. I'm not FUDing here. KDE does violate the GPL. That's not a comment on the quality of any desktop, or whether or not the QPL or GPL are good or bad licenses.

My recommendation is you go back, read the GPL, read the QPL, and read Debian policy.

Re:I don't get it.

[PiMan]

Actually, this happened. The maintainer of libapt placed it under the GPL (for reasons described in 'Why you should not use the LGPL for your next library'). However, in Corel's Debian-based distribution, they coded a Qt frontend for it. The author of libapt granted permission for his library to be linked with QPLd applications (ex post facto, after a bit of argumentation on some mailing lists about it). This license, usually called a 'GPL with exception clause', is what LyX uses, and what KDE 2.0 will probably use. What is basically says is that "While this does link with a non-GPLd library, for all other purposes, this code is GPLd".

Re:I don't get it.

[Phil Hands]

On a personal use basis, I agree with you, and I have pointed people at the KDE web site so they can pick up the Debian packages that they can find there.

Putting those files on our servers is a different matter though. By doing that, I'm claiming that I have the right to redistribute it, and I'm also making that decision for anyone who owns a mirror of the Debian archive. I don't think I have the right to do that, and I will not put up with someone else trying to make that decision for me (i.e. I'll exclude those files from the UK mirror if someone tries it prior to their licenses being fixed).

It pretty simple. If they care whether Debian distributes KDE, they'll fix their license. If they don't then APT allows Debian users to list the KDE site as one of their package sources, and not notice the difference, so there's no real hardship to anyone that wants to use KDE.

You're not going to get a compromise out of the Debian developers on this one, because Debian doesn't attract people who are willing to compromise their principles. That's all there is to it.

Cheers, Phil.

Re:I don't get it.

[Anonymous Coward]

"Debian doesn't attract people who are willing to compromise their principles."

I'll believe that the day Debian officially apologizes for removing kdelibs, which is not GPL'd claiming it conflicts with a license that it has no connection to the package (I hadn't realized that that until I saw the question about it here)

Add to it that I will believe Red Hat has principles the day the apologize publicly for putting an article in their front page saying KDE developers were commiting a crime, and then PROCEEDED TO DO THE VERY THING THEY CLAIMED WAS ILLEGAL, removing the article.

Finally, I'll believe all the amateur crap that debian-legal spews, the day someone can give me a reasonable explanation as to why companies who have actual lawyers (Corel, Caldera, Red Hat themselves, SuSE) redistribute KDE without any apparent fear of litigation.

Perhaps it is that all the amateurs know copyright law better than actual lawyers? ROTFL.

Re:I don't get it.

[Roberto]

"Last time I looked at the KDE source, it was licensed under the GPL. "

Not all of it. All of kdesupport is under LGPL or has special permission to be used in KDE (that's basically mimelib).

All of kdelibs is LGPL or freer.

KWM is Artistic.
KPanel is artistic.

A dozen other apps are artistic, too.

Now, I MAY understand that Debian didn't feel like splitting kdebase to remove all the GPLd software they are so afraid of, but why not redistribute kdesupport and kdelibs?

After KRASH is released, they could even put them in main.

Re:I don't get it.

[Phil Hands]

I'll believe that the day Debian officially apologizes for removing kdelibs

The copy of kdelibs that was removed claimed (in it's copyright file) that it included some code that was GPLed. IIRC it turned out that the same code was also available under the LGPL, so this was actually a bug in the copyright file, but given that the copyright file did say that at the time, it was a reasonable thing to do. You'll find that Coolo has recently uploaded a new kdelibs package, which is presumably just delayed in Incoming for the normal admin-bottleneck reasons that means that ``new'' packages often sit in Incoming for a few weeks. I'm not sure what there is to apologise about.

Anyway, how does the allegation that we were precipitate in our actions towards kdelibs imply that we are without principle?

I really cannot comment about RedHat's position on this, but it does strike me (as an outsider) as being somewhat inconsistent.

The situation with the commercial distributions is different to Debian. If the owners of one of these companies decides that the chances of a legal case being successfully brought in relation to this is so small that it can be ignored, then they are only betting their own money (and I think that they are on a fairly safe bet, so that's fine).

If one of the Debian developers makes the same decision, they are betting the money of all the owners of the Debian mirror sites, and all the CD Vendors. Debian doesn't exist as a legal entity, so if anyone gets sued it will be us as individuals. We're measuring the risk using a different standard, which probably explains the different decision.

Of course, there is also the feeling that the KDE developers have sinned against the GPL, by misapplying it as they have, which probably explains why Debian developers are not being more pragmatic about this. This is a largely emotional response, which is another reason why you'll not persuade the Debian developers to change their minds.

Re:I don't get it.

[Ian Bicking]

Finally, I'll believe all the amateur crap that debian-legal spews, the day someone can give me a reasonable explanation as to why companies who have actual lawyers (Corel, Caldera, Red Hat themselves, SuSE) redistribute KDE without any apparent fear of litigation.

It's not just about litigation. It's pretty easy to see that litigation was never going to come out of this -- litigation against KDE would bring rifts in the community that would dwarf the bad feelings up until now. And the people who would potentially bring litigation are mostly volunteer coders who don't have the resources to do that sort of thing. Litigation is a corporate thing.

But there is such a thing as principle. The GPL doesn't seem to allow KDE's situation. Some people who have released code under the GPL feel this way, and to use their code like that is to disrespect them and to disrespect the intention of the GPL. If the authors had meant for their GPLed code to be used that way, they would have used the LGPL.

If you've ever read the GNU Manifesto or similar documents, you'll have seen that the GPL isn't about litigation and legal obligation, it is about a moral imperative and the legal means it uses (the GPL) is only a tool to that end. Debian didn't decide not to distribute KDE because of a fear of litigation -- it decided to do so because KDE was not respecting the GPL.

There is a package converter

[DanMilburn]

It's called Alien, and I can't remember anything about it except I found it on Freshmeat a while ago.

The one time I used it to convert from dpkg to rpm it worked fine.

A Commercial Open Source License

[ripcrd]

First off, IANAL, but how about calling it the COSL (see subject) or just CPL (Commercial Public License. COSL is probably most accurate.
Now get reps from several companies (IBM, Sun, Troll, Redhat, etc.) that are interested in doing Open Source work and allow one Contract law lawyer each in a room with ESR, Bruce Perens, and the GPL lawyers. Let them hash out the items that they feel a company needs in order to release a product with the source code available! Don't make it mandatory that the license be used for every product, but if they want the Open Source seal of approval or whatever then the source MUST be available!
The software the license applies to could be shareware, demo, free (gratis), or regular off- the-shelf-pay-me-fifty-bucks software, but the source must be available as well as a method for submitting Bug reports publicly and public request for feature improvements/changes. I'm not saying the company would have to accept each and every bug fix to include in the next release, but they should consider them and use their programming standards to fix the problem in a reasonable amount of time. And test that it doesn't break something else. (Hello, Microsoft products.) My idea about feature changes/requests is that if the users have a hard time getting to or using a feature that is used all the time, then this would improve useablity. Kind of like Ergonomics, also if the company mistakenly moves a feature around in the menus from one release to the next without improving useablity I want to be able to let them know. (In IE 4.0 the internet options are in one place and in a different one in IE 5.0. Hello MS are you listening, didn't think so. They also change the name of features for no reason.) Basically I want the software companies to act differently than MS. Big surprise!
Now, make the license available on the net for peer review and later for use by any Commercial company that wants to do Open Source software. They can just place their companies name and the name of the software in a blank in the contract. Just like the generic standard mortgage contracts.
Well, that's my two cents, I'll crawl back in my cave now.

Re:A Commercial Open Source License

[Anonymous Coward]

There is one big problem with these licenses: they amount to an attempt to get free bug fixes without compensation. (sure, I can look at the source code, and fix your bugs, but I can't use it in any other programs, share it with my friends, or sell it...)

Few open source programmers are going to be willing to fix other companies' bugs for free. As a result, it's not entirely clear that such a license would actually result in better quality software.

Re:A Commercial Open Source License

[ripcrd]

If you don't want better software then, fine, don't contribute. My idea is to give users some voice and see the source. Programmers in school and entering the industry need to look at well thought out programs that will be more useful than 'Hello World'.
The idea of submitting bug fixes and reports is to thank the companies for being Open Source. I was just trying to think of a way a company could do so and still make money.
Later

dpkg pre and post install script question

[Alan Shutko]

Now, I haven't used Debian, but how do the scripts run before and after (un)installs differ from RPM pre and post scripts?

Re:I knew it

[Anonymous Coward]

Jesus Christ, dude! Way to persecute me, the defender of the persecuted. I mean, I'm not bad! Oh, and your jokes stink.

Re:I knew it

[Anonymous Coward]

Jesus Christ, man! You call yourself the defender of the persecuted? You're persecuting him because you say his jokes aren't funny. He's not bad, dude! Lay off him.

In defence of RPM.

[Hawke]

From Above:

Another really big differences is the way package installation is done: with Debian packages there are separate scripts that are run before and after package installation and removal. Using those we can do all kinds of special-case upgrades, handle error-recovery in failed and aborted upgrades, etc.

You mean like the %pre, %post, %preun and %postun scripts in RPM?

Re:In defence of RPM.

[joey]

You mean like the %pre, %post, %preun and %postun scripts in RPM?

You're ignoring the bit where Wichert says "special-case upgrades, handle error-recovery in failed and aborted upgrades, etc." Debian postinst scripts can each be called in multiple ways, with informative parameters. So for example, if all files in a package are replaced by files from other packages and the package "disappears", its postrm is run with parameters that let it know what's going on. Or if you install a package that is replacing a package it conflicts with, and the new package's postinst fails, the conflicting package's postinst gets a chance to deal with this situation. There are all kinds of complex situations like this, enumerated here. I'm not aware of RPM scripts having access to such detailed information.

--

Re:Anti-Semitism

[Anonymous Coward]

Jesus Christ, man! Lay off of Yahweh! He's not bad.

Corel and Stormix helping out

[Keepiru]

Perhaps Corel and Stormix can assist with the development of new tools for debian package management, such as the GUI or new version of dselect. Or other Debian specific packages. I like the idea of Debian, but it's currently too far out of date for me to use.

Re:Corel and Stormix helping out

[FagFace]

I like the idea of Debian, but it's currently too far out of date for me to use.

You can have as up-to-date a Debian system as you want: just use "unstable". Mine's currently a hybrid between an ancient Slackware libc5 installation, Debian Slink, and Debian Potato (2.2.13 kernel and an Xserver from 3.3.5-1)--all working very well together and with very few problems.

Re:first post! --MODERATORS READ THIS--

[Enoch Root]

Just a little bit of advice... Try reading the article before moderating posts. In this case, what you fail to realise and that is glaringly obvious to anyone who read the article, is that wichert is said Debian Project Leader. The fact that he got the first post is quite a clever and amusing joke. So stop marking him as flamebait, troll or offtopic, and understand the context.

Wish I didn't have to explain all this, but I want to believe the moderation system actually works, and isn't being used mainly by people whose sole concern is to mark posts according to a blind logic of popularity.

Update packs - a great idea!

[Ravenfeather]

I was pleased to see that the idea of update packages was raised in the interview. It seems to me that one might want a very different upgrade philosophy for certain fast-developing sets of interrelated applications (e.g. GNOME) than for other more stable programs (e.g. tetex). For the former, the rapid pace of improvements in functionality and stability make it desirable to upgrade relatively frequently, even at a small stability cost with respect to distribution testing etc. For the latter, the current "make-it-bulletproof-before-release" philosophy of Debian seems ideal.

Thus it would be nice to have a way to decouple the upgrade process for sets of applications like GNOME from that for sets of applications like tetex. The upgrade-pack idea seems to be a fine solution.

Re:QUESTION ABOUT OPEN SOURCE.

[divec]

You don't have to release source to be DFSG-compliant (Open Source). You just have to allow the source to be distributed as wide as the binaries. Since Slashdot binaries are not available, Slashdot source doesn't need to be either.

A response to some of your own quotes

[A nonymous Coward]

but to grow Linux so that it can truly compete with MS and others

The major reason Linux specifically and free source software in general is more robust and useful than proprietary software is because the authors WANTED to write it, and WANT to work on it, and it's written in public where everyone can see it. Now if RedHat or Corel wants to pay someone to write free source software, that's fine, but it doesn't have the same motivation.

Quality will suffer. Innovation will suffer.

Linux needs to take off its training wheels and go play with the big boys

Common M$ FUD here. Linux got to where it is with your so-called "training wheels" and doesn't need to take anything off to keep on going. Success with Linux is measured in how well it works, not in inflated market capitalizations.

--

Re:A response to some of your own quotes

[Teach]

I don't think this would happen to the degree you are suggesting. It's true that OSS gets some of its power from programmers who work on something they want to. But the "thousand pairs of eyes" factor is a bigger deal, IMHO, and I think it would ameliorate anything but a horrid first attempt.

You may have answered this already, but what projects are so heinous that no one wants to work on them? I can see nobody wanting to do it bad enough to start in the first place, but to not want to do it at all?

For example, I'd never take a free Saturday to add FireWire support to the Linux kernel. My free time is too precious, and there are other projects I'd rather spend my time on. But if Red Hat approached me and said "We'll pay you 30k/yr to work on adding FireWire support to Linux." I'd get real interested in a hurry.

There are a hundred projects I'd never start on my own which I'd still be interested in if it meant I was quitting my Real Job and had time to work on them.

In addition, I think the "disgruntled Red Hat worker" (to borrow from Booker) is less likely to occur in a free software setting, because many of the Dilbert-esque factors that make programming for a living no fun are far less frequent in such environments:

• far fewer clueless pointy-haired bosses
• decisions are made by the ones who understand the technical aspects
• seldom have to work around someone else's crappy code, since if it's crappy it's probably not adopted by any real distro
• don't have to tech support for dumb users (clientele would largely be other developers, who don't ask things like "What do you mean, shift-click?")
• ...and probably a dozen others which I can't think of since I don't program for a living

Anyway, I love my job, but I think I could find any number of less-popular programming tasks very rewarding even if I wouldn't choose to spend my time on them now, limited as it is.

Re:I knew it

[Anonymous Coward]

Nice try, loser-boy.

Before moderating this down: Please read

[PD]

The person who posted this is the same guy that was interviewed. That's right! He's the featured man of the day.

It's FUNNY. Just mark the think up to 5 and leave it there. Right now the struggle between moderators is wasting a lot of points.

This article posted with my default of +2 in an effort to make it appear close to the FUNNY comment. Please leave it at +2 for that purpose.

Thanks

Release Comments and Other Ideas.

[Anonymous Coward]

The release history seems to suck, but isnt that fixed by using something like apt to update all of your packages?

Yes, I more or less am continuously up-to-date from unstable. The whole notion of periodic releases looses much importance when you aren't updating your system that way.

I do like the package pool idea though, as it would be fun to make micro-distributions by listing all the packages needed. It would also be nice to make meta-packages, such that you could install mike-graphics and get a nice set of graphics related packages, or pick hardcore-crypto for cryptography packages, etc.

My other recommendation is to move as many packages to source-only distribution as possible, and have them compile on install, so that the packages would become platform independent. Note that you can still distribute binary packages, but the way to do this is to treat them as cached intermediate objects, not the actual packages themselves. This would also solve the 'can I get a pentium-optimized version', you could distribute stripped binaries or debug versions, and it would be much easier to support and move to more platforms.

Lastly, I think the BSD distribution is a great idea. At the very least it helps keep all the packages source-compatable between the two systems.

Package Choice, Sometimes Default to OpenBSD-like

[Anonymous Coward]

If I understand correctly, OpenBSD audits all source code added to a distro. I can't imagine that too many distros could afford the effort and time this takes, let alone have the capability of doing it properly.

That said, Debian installs by default or offers a number of critical packages that are not necessarily mainstream (but should be), presumably because security and ease of configuration are being kept in mind. Take for instance, the OpenBSD ftp server, ssh, a number of SSL'd tools like telnet, exim as a mail transport, gpg, mason, etc.

Debian's security depends upon the maintainers of individual packages, and my impression is that these maintainers are qualified and experienced individuals. Security may not be the ultimate priority, but it is not exactly ignored, either. A great indicator is the speed in which new packages are issued in Potato, especially when a security bug has been reported.

It seems to me that a separate "secure version" is something to be avoided. Ideally, the default version would already be secure. Remember, too, that most security holes are the result of poor administration. I'd say that the default configurations in Debian are a pretty good balance of usefullness and security. However, an admin who doesn't set up firewalling and lock down unused ports is being naive, and no distro can prevent that. Someone who specifically demands a secure version is probably a little too paranoid about others and should be more paranoid about themselves.

Re:Anti-Semitism

[Anonymous Coward]

I don't think Debian is moving towards the FreeBSD packaging system. More like Debian is going repackage up some of FreeBSD in Debian way.

Akkerman...

[Kismet]

...What is your function?

:)

Re:Akkerman...

[ajk]

It grows faster than anything...

Ah, but that's Ackermann's function. Sorry.

Re:Anti-Semitism

[JabberWokky]

.

> Grow up. I believe there is a fameous quote that to have free speech we must also tolerate the speech we hate for us to truly be free.

to which, you (hattig) replied:

> Things like this make me happy not to live in America.

Which is ironic, as I believe the quote he was referring to was: "I disagree with what you say, but I will fight to the death for your right to say it", often attributed to Voltare, a French philosopher. (Of course, it could be said that a great deal of American concepts of freedom come from the French and visa-versa).

As to if this quote is correctly attributed, I have some question (I've seen it in print and on a billboard, but some academic types have recently disputed it). But the common attribution is to a Frenchman.

Are you now happy that you don't live in France?

--
Evan (Sick of "geeks" who complain about the term "hacker" in the media slamming someone for their "nationality").

Too much for debian?

[jrs]

They've got Debian Linux, HURD, and FreeBSD, isn't anyone else a little worried that they've taken on too much? In the end, it will probally delay each dist a lot longer then the long awaited 2.2

Re:Too much for debian?

[qazwsx]

The point here is: if there is anyone wanting to do something, why should we disallow him to do it?

If he can't hurt you, why should you refuse his work?

Re:Too much for debian?

[guacamole]

They've got Debian Linux, HURD, and FreeBSD,

Don't forget that Debian Linux as of potato release will support i386, sparc, alpha, PPC, and m68k. They also have unstable ports to ARM, MIPS and sparc64 (though sparc port runs fine on sparc64 machines in 32 bit mode). Just Debian Linux is huge, Hurd. well.

I think the Debian/FreeBSD was a bad idea. It will only increase archive bloat and arguably be more work for developers. As a Debian GNU/Linux users I don't see any advantages that Debian/FreeBSD will give me. If I want FreeBSD I run FreeBSD. Debian/FreeBSD is a bad deal, really ..

Re:Too much for debian?

[broonie]

It could, but OTOH unreleased ports don't slow released ones much (so if everything is really bad then the port just won't be released) and generally Unix applications are pretty portable. Most porting work is pretty automatic - it's only a small set of problem packages that cause much hassle.

And to some of yours... :)

[Booker]

The major reason Linux specifically and free source software in general is more robust and useful than proprietary software is because the authors WANTED to write it ... Quality will suffer. Innovation will suffer.

Possibly - but I think that once the "hard work" is done with issuing the first release (with code of course, since we're talking about Red Hat) then that puts a lot of momentum behind the project. So yes, maybe you'll have "disgruntled Red Hat worker in her cube" (if there is such a thing...) releasing the first version, but then it's out there for all the people who didn't have time to do it from scratch, and the beauty of open source takes over...

Unless the initial design was fundamentally flawed, I think great software can still arise from a corporate-sponsored beginning.
----

Debian Install Follow-UP

[HomerJ]

In the earlier article my question was basicly "With Slink being out of date, and Potato having a flaky install, how does one do a fesh install of Debian now, and have all the recient packages (Xfree 3.3.5, 2.2.13, etc.)

Here's what I did, and thanks to the reply to my post that was helpful:

1) Installed Slink, with all the packages I wanted. (installed flawlessly, as it should)

2) Compiled my own kernel. I tried to do skip this step and alot of the Potato packages chocked because I wasn't running a 2.2.x kernel. SO I had to start over.

3) changed /etc/apt/sources.list to unstable

4) apt-get update udates your package database to the latest version that are in unstable.

5) apt-get install dist-upgrade upgraded all my packages that I installed with Slink. Updated packages included XFree86 3.3.5, Enlightenment DR16.3, Latest GNOME, etc. It failed to to update a couple packages, but they weren't needed and I just apt-get remove

6) Went though the set-up process. Uncluding XF86Setup, untar'ing my old home directory, etc.

That's about it. I have a full Debian distro with later stuff then I even had with RedHat 6.1 Apt-get served me so far when I didn't have libgnome-dev(compiled a couple gnome aps). Unstead of looking for RPMS like I did with RH, I just typed apt-get install libgnome-dev and waited a few minutes and had then already installed and read to go.

Been running fine for 4 days now, and it's great.

I encurage anyone thinking about Debian to give it a try. My only gripe is that I didn't install it months ago =)

Re:Debian Install Follow-UP

[Anonymous Coward]

I am planning to upgrade slink in the next few days, and in order to make it go more smoothly i would like to ask for a bit more detail.

First, i know there are several problems with programs like init and syslog when switching kernels, is it still possible to boot with a new kernel and an old init, or do these have to be installed at the same time, and if so, what are the important packages. Even better would be a kernel package that would be installed during the dist-upgrade - is this possible.

Any other advice would also be greatly appreciated

Re:Debian Install Follow-UP

[Helish]

The init scripts shouldn't have any problems with kernel 2.0.x. They check the kernel version you are currently running and take appropriate actions.

One week ago I have installed potato which was running kernel 2.0.36.

Also kernel 2.2.13 is in potato, so you might want to install it as well.

Debian GUI?

[Anonymous Coward]

Is there an installation GUI in the works?

Re:Debian GUI?

[Anonymous Coward]

This is a GUI. Right after you boot from disk you get a nice menu that walks you through the process, and once the base system is installed you get to select packages with the dselect gui.

Re:Debian GUI?

[penguinhead]

I posted a question about this on the debian devel newsgroup and no-one seemed interested but the best way to get something done is to do it yourself. Get in there and hack some code!

Re:Debian GUI?

[HiThere]

Sort of. The Corel distribution is based on Debian, and has a graphical installer, and is (to be?) GPL'd, or at least open source. This would make it v. easy to port it back to Debian Linux.
(Or, perhaps, to create a derivitive work). Only current problem is that it depends on QPL. Oops! Need to wait for version 2.

Re:Debian GUI?

[wichert]

Right now we are working on getting everything ready for the potato release (the state of the
boot-floppies was one of the major reasons for postponing the freeze). Once that has been finished and potato is released we will probably take a good look at our current design and see how we can improve it. A GUI installation is definately on the TODO-list, as are things like hardware detection and automated installs. We also have access to the installation systems from Corel and Stormix, which should make things easier for us.

Why do we need glibc?

[Anonymous Coward]

I hear a lot of people saying that FreeBSD needs glibc. I wonder what we
BSDers are missing. We have our own libc you know.
As far as I know it works great. Why fix it when it ain't broken?

Re:Why do we need glibc?

[Daniel]

Because this isn't FreeBSD, it's *Debian* BSD. The Debian system is based on glibc, and using a single library across all Debian systems would theoretically make it a lot easier to debug problems and so on.
Also, you'd get some level of binary compatibility if all programs were ELF and dynamically linked against libc -- only direct syscalls would have to be fixed up, and I don't think there are many of those..I've heard that even syscalls (from C) can go through libc, so mainly you'd need to worry about assembly code.

Daniel

Pentiums and new package pool

[MostlyHarmless]

This problem could tie in very nicely to the new package system. There could be two versions of every kind of distro: A pentium version and an amd/x86 version. I, for one, installed Debian on my 386 w/ 4 megs (Dad won't let me partition the main computer :-( ), and I would be very disappointed if Debian made their distribution Pentium-based.

OK, maybe I'm a special case, but lots of other companies use old 486's for routers etc while using Pentium workstations. They would also be very happy with the new package pool + Pentium/non-pentium distros.

A REAL open source license.

[matman]

The problem with the GPL and a lot of different open source licenses and not open source licenses is this... they're too complicated, and restrictive... the opposite of what 'free' and 'open' mean.

The optimal OSS license would be this:
One may do whatever they wish with this source code and may take credit of only those changes which they make, if any. The source code of the original unmodified software must remain available and the modifications must acknowledge their being based on the original software, however, the changes made to it may be put under any license which the developer wishes.


whatcha think?

personally, when i write software, i say in my license... this software is now YOURs, it is your property, you may do what you wish with it - change it, copy it, sell it.

Re:A REAL open source license.

[ripcrd]

I agree with some of what you say, however, I was speaking of a general commercial vendor Open Source license. The intent of my posting was to elicit work on a licence that could fit a variety of situations without adding confusion.My intent was to make the vendor the maintainer of the code (Duh) and to retain ownership, that could later be placed under the GPL as the product ages and has paid for its development costs and profit, but sales have dropped. Maybe a statement that the purchaser or user could reuse the code for personal use only or improve upon it for specific application (i.e. clustering kernel adaptation). But I would like to see bug reports and fixes submitted to the company for approval for inclusion in next distribution. This way the they could adjust the fix to adhere to internal coding standards. Some stuff people write is too confusing to maintain. If the fix doesn't make the next distro, then it would go to the website or ftp.The purchaser would have to keep ownership of the original source of the product (i.e. it can't be taken away), since for special applications or uses it is necessary to keep a copy on file. I can give specific examples if this is not clear.I'm not entirely sure how derivitive works should be handled, but that's why the pros need to meet. Derivitive ideas should be allowed as you can't control thought and we shouldn't stifle innovation. That would be treated different than reusing the actual code snippets. Maybe say that parts of the code may be reused, but not in a product competing in the same area as the exact same application unless it is to maintain standards with LSB, W3C, ISO, ANSI, etc.I don't claim to have all the answers, but I wonder just how far apart the existing commercial open source licenses are.

Free the Souce, the rest will follow.

Not necessarily...

[jmweeks]

Well, to run all the unstable stuff (which include the newest versions of E, GNOME, etc.) you need to have libc 2.1 installed... which is a serious download, and requires upgrading gcc and a few other packages. But I think the connotation of this post is that you have to make a choice that your whole system depends on (bet. 2.0 and 2.1), while in my experience the vast majority of the packages will be just fine after upgrading to 2.1.

In other words, the upgrade to 2.1 seems to me more of a dependancy issue (such as e.g. needing gtk+ and imlib and so on to install E) than a "you can't do this on this system" issue.

Jose M. Weeks

not even first ..

[guacamole]

ncurses

[guacamole]

Debian uses ncurses based GUI during installation. ncurses IS a library for GUIs. What is wrong with ncurses?

Wrong.

[Anonymous Coward]

KDE doesn't use any GPL code from other projects. The only GPLed code in KDE is by KDE developers.

Debian and Pentiums

[Rizzer]

Referring to the idea of a pentium build, Wichert said:

it doesn't really help you: if you look at benchmarks you will see that only a relatively small number of programs benefit from this. So you do a whole lot of extra work and gain very little.

Which programs are those exactly which will benefit? I wouldn't mind putting some time into recompiling some key applications for my PII if it was going to help some.

p.s. I'm using Debian potato ("unstable") and it works just great!

Time between releases

[greydmiyu]

The time between releases issue has been raised constantly and I have the same answer each time.

1: If the person on the other end wants bleeding-edge stuff installed they can always compile their own or ride the unstable tree. For example, I've been running 2.2 on all my Debian machines since the day 2.2.0 came out.

2: If one looks at the release cycle of the main distributions (Red Hat, Slackware, SUSE, Debian) one will note that Debian's release cycle isn't slower. The logest release so far was 2.1 at 7 months. All the others have had 7 month release cycles in their past. The others have had release cycles as low as 3 months. Interestingly enough the low month releases were also the most buggy for the other distributions. Debian's stable tree has been just that, stable as rock. If a quicker release cycle means less stability (which I think it does) then ride unstable and be done with it!

Yes.

[Anonymous Coward]

Yes I think you understand the issue. To answer your question. I don't know of any GPLed code in KDE (in CVS) that is taken from other projects without permission.

Re:Package Choice, Sometimes Default to OpenBSD-li

[shub]

OpenBSD audits everything under /usr/src. Most of the auditing is fixing bugs, so that buffer overruns simply can't happen, stack smashing attacks are impossible, etc.... When a bug is found anywhere in the code, it is fixed -- even if there is not a known exploit, the bug is fixed anyway.

That's the biggest part of the default security that is inherent in OpenBSD -- Simply eliminating bugs.


There's another part -- where strong crypto is integrated by default into all those places where it can be of help, but as recent references on /. to papers written by Bruce Schneier demonstrate, crypto is actually a very small part of the overall security picture, albeit a critical part.


Fixing all the known bugs in the kernel and stuff under /usr/src has nothing to do with the integration of the crypto. These are things that should be done with all OSes, not just OpenBSD.

You could leave the strong crypto in packages that could be added appropriately (via the 'net), according to the location of the user -- RSA implemented with RSAREF in the US, but implemented with faster (and publicly available source, so it is likely to be more bug-free, and avoid embarassing things like buffer overflows in the RSAREF libraries) for overseas customers. But you might always get one package or the other by default, depending on where you are.


Of course, when it comes to packages and ports, you have to depend on the respective authors, but if they have the time and the necessary tools, it wouldn't hurt to have the same auditing procedures applied to them by the same auditing team, and then fixes offered back to the authors.

That way, everything in the OS would be more bug-free (and less susceptible to being exploited), and the system as a whole would tend to be more secure.

Moderation Totals

[jfunk]

Moderation Totals:Offtopic=6, Flamebait=2, Troll=2, Funny=15, Overrated=2, Total=27

That's quite a power struggle. Wichert's karma has been having a bumpy little ride, indeed.

For the record, *I* think it's damn funny.

Re:Moderation Totals

[Anonymous Coward]

For the record, *I* think it's damn funny.

I think the _moderation_ is the funniest part.
BTW, it's not up to 30 moderations points used on this single comment!

Ncurses...

[Deus Ex Machina]

\RANT mode=1
I agree... people seem to want to run as fast as they can from ncurses and upgrade to X-based installations. The problem is, a lot of people (read: me) don't want to deal with the extra overhead, instability, and even complexity associated with an X-based installation. While converting 22 Macs over to Linux, the LinuxPPC/Redhat ncurses installation method was the only feasible meathod that I could install the OS from... the X version (which was also the "recommended install method") wouldn't work correctly, and often crashed out entirely.

People really need to understand here that though ncurses might be ugly as sin, it sure as hell beats crashing during an OS installation! \RANT mode=0

More defence of RPM

[kinkie]

The point about the install-script has already been made in another post.

I'll object to the others:
"For example, rpm allows you to have multiple versions of a single package installed."
That's not entirely true: RPM will allow that by default (provided that there's no file conflict), and this can sometimes be useful if you wish to have multiple versions of a library on your system for backwards compatibility purposes.

However, the packager is given the choice to state a "conflicts" clause, which supports version information. So to emulate dpkg, packagers should simply assert that some version conflicts with all earlier versions, and the trick is done.

Now about the other one:
"One problem with rpm-packages is that it is harder to satisfy dependency due to the concept of file-dependencies. Instead of being able to say `I need package b to be able to use package a' it can become `I need file /usr/lib/libfoo.so.3.14 to be able to use package a' and then you'll have to find some way to scan all packages to see which ones include that file, and then you're not even sure if they have the right version of that file.. "

Again, this is not entirely accurate: RPM allows a packager to specify a "Virtual capability": Simply put, a package foo can assert to provide a capability bar, and other packagers can express dependencies to the bar capability, rather than the libfoo file.

I'm not saying this to bash dpkg in favor of RPM, but just to set some facts straight.
For instance, I like dpkg's "recommended" dependencies (as opposed to RPM's only "hard" dependencies).
I think the two technologies are roughly equivalent, and that Wichert is oh-so-right in saying that in the end the choice boils down to personal tastes, familiarity and stability.

Re:More defence of RPM

[wichert]

The problem with a `virtual capability' is that
sometimes a specific implementation of that ability can introduce unexpected problems. An example is the /usr/lib/sendmail (or /usr/sbin/sendmail now) interface: while all
MTAs implement this, they are not exactly the same. As a result debbugs didn't work with qmail originaly since qmail couldn't handle the `name ' style of specifying addresses. So the interface was there, but it was different in a subtle way.

I think what you mean with a `virtual capability' is more like what we do with a `virtual package': with that system one package can `Provide' another (possibly not existing )package and state in that way that it implements the some specific functionality.

Re:More defence of RPM

[kinkie]

The issue you talk about then is not as much a technical one as an organizational one.
The point in your example would be for the packagers to agree on an appropriate set of capabilies to specify.
In your example, one possible solution could lie in specifying virtual capabilities ("provides") akin to these:

package sendmail:
provides: MTA MTA-name

package qmail:
provides: MTA

package debbugs:
requires: MTA MTA-name

and the icompatibility would be correctly handled when installing (provided that such incompatibilities be known: it could very well be that you discovered this one while trying to install debbugs).

Such an package dependencies tracking mechanism wouldn't be exceptionally easy to maintain, especially with the kind of organization model debian uses, because it requires a lot of timely inter-packager communication, and a very flexible work model (notice: I am NOT a debian package maintainer, so I have no clue about how tightly knit is the packagers' network: I am assuming that it must be a tad looser than a company's communications network, for no other reason that a company's employees usually work full-time on that company's projects, thus drastically cutting answer times). BUT it would handle the problem elegantly.

Also notice: I have NOT mentioned any package-manager here. This solution works equally well with any package manager that supports virtual capabilities and dependencies tracking.

That makes it easier!

[Anonymous Coward]

That's great!
That should make it easier to fix the license on the KDE side.

Peter Galbraith psg@debian.org

he means the Debian/FreeBSD effort

[Beethoven]

... I think.

MODERATE THIS UP! (INSIGHTFUL)

[Anonymous Coward]

My god, this just puts the question to Debian fair and square.

Enough double talk/propaganda from Debian!

Slow release cycle

[Ricardo Casals]

Ya think it could be sped up just a LITTLE if they didn't have like 1billion packages to worry about? Also, packages that nobody really gives half a rats ass about? Maybe, just maybe ...

If I trolled, don't 0 me, if I flaimbated, don't 0 me, and please just don't 0 me I've had enough of that!!! :o)

Re:Slow release cycle

[cdwiegand]

That's why the Release Packs will help. you can have a "basic Debian" pack with a few hundred packages, just your basic stuff; a "developer Debian" with lots of developer stuff; and a "everything-under-the-sun Debian" with everything. Sounds really great, I think I'll finally switch back from RedHat (those long release cycles scared my boss away...)

Re:Slow release cycle

[broonie]

Most of the packages have very little to do with holding up the release - generally, a package can always be dropped if nobody feels like fixing it.

What holds up releases are those really important things that we can't release without - anything else can just be dropped from the distribution if nobody wants to fix it. Being an all-voulenteer project, we can't really compel people to work on these things. Currently, it's the boot floppies but they seem to be coming together.

binarys?

[delmoi]

Isn't slashdot made in perl? so how could there be binarys?

Re:binarys?

[divec]

You can make perl binaries. But my point was that the right to not publish something at all is compatible with the DFSG.

Moderation totals for this post (#4)

[Anonymous Coward]

As of 2:56AM CST:

Moderation Totals:Offtopic=6, Flamebait=2, Troll=2, Funny=18, Overrated=3, Total=31.

wow

Lst post!!!

[Last Post!]

Think about it, is it DEBIAN or LESBIAN? Kinda makes you wonder about amazgon Linuz dirbibutions, doens't it?

YOU GOTS SHORT MONEY, BOIIIII!

Thius ez ownage last post brought to you by shots of Bsacardi 151 proof rum. ez.

_.......................__
||.....__...._._||_..||-\\..._...._._||_
||......_\\.(/_'..||....||-//.//.\\.(/_'..||
||__((_||_,_/).||_..||....\\_//.,_/).\\_
The final word; anything following is redundant.

Hiring programmers

[Jonas �berg]

Here's an idea; let SPI sell Debian CD's and manuals and use the profits from that sale to hire people to write a new dselect (and other things that are needed in Debian) -- just like the FSF develops some of their software.
There's a common misconception in the world today that free software "simply happens" because someone needs a tool. There's some truth to that of course, but things like the GNU libc, GNU CC and other projects where started and paid for by the FSF because they saw a need for that software.

mmmmm, benchmark(et)ing :)

[Anderson]

Okay, I did some experiments on this end with bzip2, a completely integer code. I compared the default Debian compilation (flags -O2 -g, then stripped) against a couple of other compilation options. The test runs were to compress and decompress a 700K-ish file connecting the two processes via a pipe, a la: bzip2 -c file | bzip2 -cd file > file.0. I then compared file to file.0 to make sure that they were the same (and I found no errors for all of these runs). All runs were on my practically-idle P2-233 laptop.

Flags -O2 -march=pentiumpro: 2.6% slower (a bit unexpected)
Flags -O6: 1.2% slower (odd, again)
Flags -O3 -march=pentiumpro -fomit-frame-pointer -funroll-loops -finline-functions -fstrict-aliasing: 3.6% faster

I can't say these are scientific (although I did run each test four or five times, and took the mean score after throwing out the fastest and slowest), but they might help in guaging general performance increases for machine-specific optimizations. The majority of code is integer code not too unlike bzip2 ... the floating-point-intensive codes like xmms will probably benefit more, although I tried the same experiments with that and found similar results. (Hard to put real numbers on that since xmms is an interactive graphical program.) Ummm, I dunno. Since this is a Debian thread, another thing to note is that slink (Debian stable at the moment) was compiled with a completely different compiler than potato/unstable. So if you compare between the two, you'll probably find that potato (unstable) is a fair bit faster overall because of being compiled with the newer egcs compiler (which has the faster Intel-sponsored x86 code generation backend). As I've said before, for real (original) Pentiums the difference is probably significant, but for newer CPUs the optimizations get lost in the noise of everything else. Or that's how it seems to me.

Hey! What's wrong with dselect?

[blue]

I think dselect is very efficient and isn't as difficult as its made out to be as long as you read the documentation and familiarize yourself with the keystrokes, which are straightforward. Plus, the functionality is there (or am I missing something?), and I don't find it very annoying. Surely, alternatives are good, but there are hostilities towards it and, for some reason, blamed for the difficulty of installing Debian.

Roll your own..

[MikeFM]

If you want Slashdot source and it isn't available clone it. I good point to start is PHP Slash. Slashdot is great but it can't be that complex a site. The hardest part I'd imagine is keeping it from being /.'d into total lag.

Well then....

[Rogain]

why don't one or some of you guys volunteer to become Debian Maintainers for 'pentium opimizations', and recompile various programs that might benefit from these opitmizations, and make the appropriate .debs. Pentium users could then download them and use them instead of the normal ones.

TM Issue was Re:Future

[ripcrd]

That's why I put in the faky looking TM. Besides, IDG and the rest of those Dummies can BITE ME! I personally would feel embarrassed buying one of those yellow covered advertisements that you're a moron, unless of course is were something like Quantum String Theory for Dummies or Plotting the Human Genome for Dummies. Cliff Notes (TM) should sue them for taking their idea of the yellow cover.
Later,
Ripcrd

Sigh, because it's mainly an adminstrative change

[skids]

A group should form to get this finally pushed
through... I'm a very happy Debian user but was
disappointed to the answer to this question.
So many people are running 586s and higher
these days the old "won't work on a 386/486"
argument is no longer valid.
Problem is it's not coding that needs to be done,
it's convincing. Debian needs to be changed
to allow "arch-i586" and "arch-i686" machines which
are able to install arch-i486 packages too.