Differences between revisions 11 and 17 (spanning 6 versions)
Revision 11 as of 2007-05-23 10:17:45
Size: 38024
Editor: GerberGraaf
Comment:
Revision 17 as of 2012-11-04 12:17:55
Size: 38763
Editor: PaulWise
Comment: snapshot is an official service now
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== Vertalingen: ==
 *
WhyDebian: english
#language nl
Vertalingen: [[WhyDebian|English]]
Line 10: Line 10:
[[TableOfContents([2])]] <<TableOfContents(2)>>
Line 44: Line 44:
== Utility and usability ==

Assuming I have not totally lost the pragmatists amongst you, the criteria that the vast majority of people hold highest while choosing an operating system are, after cost, utility and usability. Of course, utility depends on what your goals and requirements are, but there broad areas we can still address.

There is more to an operating system than a kernel with a hodge-podge of software thrown on the top - systems integration is a topic usually given short shift when discussing the merits of a system. But a well-integrated system - where each piece dovetails with and accommodates other parts of the system - has greatly increased utility over the alternative.

Debian, in my experience, and the experience of a number of my respondents, is the best integrated OS out there. Debian packages trace their relationships to each other not merely through a flat dependency/conflicts mechanism, but a richer set of nuanced relationships - Pre dependencies, ordinary dependencies, recommendations, suggestions, conflicts, and enhances relationships. Apart from this, packages are categorized according to priority (Essential through extra), and their function. This richness of the relationships, of which the packaging system is aware and pays attention to, indicates the level at which packages fit in with each other.

Debian is developed by about 1000 volunteers. That means that every developer is free to maintain programs he is interested in or he needs for his special tasks in real life. That's why Debian is able to cover different fields of specializations - its developers just want to solve their own special problems. This broad focus is different from commercial distributions which just try to cover mainstream tasks.

I have found that the Debian machines at work take less hand holding, are easier to update, and just plain don't break as often as the Red Hat and Mandrake boxes I manage. I am told that dealing with SunOS, for example, is far more, umm, interesting.

One of the reasons for selecting Debian over other distributions is its sheer size of the project which strongly suggest that Debian won't suddenly disappear and one is suddenly left without any support. Debian can't go bankrupt. Its social contract doesn't allow the project to abruptly decide not to support non enterprise versions of the distribution. I do not want my OS to be held hostage to anyones business plan!

You can fine-tune the degree of risk you want to take, since Debian has three separate releases: Stable, Testing, and Unstable. On some of our machines (the server, the kiosk machines) we run 'stable'. Some of the other systems (individual work-stations) run various combinations of testing/unstable. (Note that there are no security updates for testing). I run some stuff from experimental on my own work-station. What's great is the ability to make finely graded decisions for different machines serving different functions. But even the more adventurous choices are solid enough that they virtually never break. And `stable' just never breaks ;-).

Debian provides a great deal of feedback upstream. For example, the XFree project does not itself maintain or debug X on all the architecture Debian supports -- it relies on Debian for that. There have been a number of deep fixes to libc (there was a recent reference counting flaw in glibc when dlopening a shared object with certain ELF dependencies discovered by the Debian developers). This attention to detail is hard for any other Linux distribution to match. The level of knowledgeable, fast, and friendly help available for end users is just extraordinary -- and nothing I have been able to match from old style commercial companies like DEC -- unless you are paying them really big bucks. This can provide third party support without in house expertise, for businesses building upon Debian.

For derivative systems, DFSG and "main" simplify building systems with predictable licensing.

== Qualiteit van implementatie ==

People often say how they came to Debian because of apt-get, or that apt is the killer app for Debian. But apt-get is not what makes the experience so great: apt-get is a feature readily reproduced (and, in my opinion, never equalled), by other distributions -- call it urpmi, apt4rpm, yum, or what have you. The differentiating factor is Debian policy, and the stringent package format QA process (look at things like apt-listchanges, apt-list-bugs, dpkg-builddeps, pbuilder, pbuilder-uml -- none of which could be implemented so readily lacking a policy (imagine listchangelog without a robust changelog format)). It is really really easy to install software on a Debian box.

This resembles cargo cult (http://en.wikipedia.org/wiki/Cargo_cult) religions: that is, apt-get is the visible aspect of Debian's policy system, the same way that cargo-cult practices saw runways and other characteristics as the source of western goods ("cargo"), and built their own replicas, complete with fake wooden headphones for control towers. In the same way, other distributions have created the shallow visible aspect of Debian's packaging infrastructure, without addressing the deep issues of policy. Worse: the conflicts of technical requirements and marketing / economic imperatives often work at cross purposes. Less perversely for most GNU/Linux distros than for proprietary software, but still clearly present.

Red Hat, Mandrake, and other distributions in the class have really massive base installations. Why? I do believe it's because it's a PITA to install software. Even with RPM, it's a kludgey procedure, impossible to codify. With Debian, it was a breeze.

So the killer app is really Debian policy, the security team, the formal bug priority mechanisms, and the policy about bugs (namely: any binary without a man page is an automatic bug report. Any interaction with the user not using debconf is a bug). As the Wiki page Why Debian Rocks (http://twiki.iwethey.org/Main/WhyDebianRocks) puts it:

== Practisch nut en gebruik ==

Verondersteld dat ik niet helemaal de pragmatici onder jullie ben kwijtgeraakt, de criteria die de grootste meerderheid het meest belangrijk acht wanneer men een besturingssyteem kiest zijn, na de kosten, het nut en het gebruik. Natuurlijk, het nut hangt af wat je doelen en benodigdheden zijn, maar er is een groot gebied dat...

Of course, utility depends on what your goals and requirements are, but there broad areas we can still address.

Er is meer in een besturingssyseem dan een kernel met een hutspot van software erbovenop - systeem integratie is een onderdeel waar meestal weinig aandacht aan wordt geschonken wanneer de voor-en nadelen van een syteem worden bediscussieerd. Maar een goed geintegreed systeem - waar ieder onderdeel precies past en andere delen van het systeem aanpast - heeft het practisch nut sterk vergroot boven het alternatief.

Debian, in mijn ervaring en in die van mijn respondenten, is het best geintegreerd besturingssysteem dat bestaat. Debian paketten hebben een spoor van relaties met elkaar, niet alleen door een platte afhankelijkheids-en conflict mechanisme, maar een rijke verzameling van genuanceerde relaties. Voor- afhankelijkheden, gewone afhankelijkheden, aanbevelingen, suggesties, conflicten en evenwichtige verhoudingen. Apart hiervan, de pakketten zijn geordend naar prioriteit (), en hun functie. Deze rijkdom van relaties, welke het pakketsysteem herkent en er rekening mee houdt, geeft het niveau aan hoe paketten bij elkaar passen.

Debian wordt door ongeveer 1000 vrijwillegers ontwikkeld. Dat betekend dat iedere ontwikkelaar vrij is om programma's te onderhouden waarin hij is geinteresseerd of die hij nodig heeft voor bepaalde doelstellingen in het gewone leven. Dat is de reden waarom Debian in staat is om zoveel verschillende specialismes te dekken -- haar ontwikkelaars willen gewoon hun eigen problemen oplossen. Deze brede focus verschilt van commerciele distributies welke alleen algemene taken proberen te omvatten.

Ik heb ervaren dat Debian machines op werk minder aandacht vragen, gemakkelijker zijn om te vernieuwen en breken gewoonweg niet zo vaak als Red Hat en Mandrake systemen die ik beheer. Ik heb me laten vertellen dat het werken met SunOS, bijvoorbeeld, is veel meer, ummm, uitdagend.

Een van de redenen om Debian te verkiezen boven andere distros is haar enorme afmeting van het project, wat sterk suggereerd dat Debian niet zomaar zal verdwijnen en men opeens achtergelaten wordt zonder enig ondersteuning. Debian kan niet failliet gaan. Haar sociale contract laat niet toe dat het project opeens beslist om geen ondersteuning meer te geven aan niet-bedrijfsversies van de distro. Ik wil niet dat mijn OS wordt gegijzeld door wie dan ook zijn 'business plan'!

Je kunt het niveau van risico dat je wilt nemen fijn afregelen, sinds Debian drie verschillende releases heeft: Stabiel, Testing en Onstabiel. Op enkele van onze machines (de server, de kiosk machines) draaien we Stabiel. Enkele andere systemen (individuele werkstations) draaien verschillende combinaties van Testing/Onstabiel. (Merk op dat er geen veiligheids-updates zijn voor Testing.) Sommige dingen draai ik vanaf een Onstabiel systeem op mijn eigen werkstation. Wat zo mooi is is de mogelijkheid om fijn afgestemde beslissingen te nemen voor verschillende systemen met verschillende functies. Maar zelfs de meest avontuurlijke keuzes zijn solide genoeg zodat zij bijna nooit breken. En Stabiel breekt gewoon nooit ;-).

Debian voorziet een grote dienst van respons opwaarts. Bijvoorbeeld, het XFree project onderhoud zelf niet alle architecturen die Debian ondersteund - **Het hangt wat dat betreft van Debian af **. Er zijn zelfs een aantal diepe bug reparaties voor libc (er was een fout in de referentie teller in glibc wanneer dlopen een 'shared object' ... Deze aandacht voor detail is voor ieder andere Linux distro zeer moeilijk te evenaren. Het nievau van beschikbare hoogwaardige, snelle en vriendelijke hulp voor eindgebruikers is gewoon bijzonder - en geen enkele oude-stijl comercieel bedrijf die ik ermee kan vergelijken, zoald DEC, kan zich daaraan meten, tenzij je er zeer veel geld ervoor betaald. Op deze manier kan ondersteuning worden gegeven door derden, zonder de kennis in huis te hebben, voor bedrijven die op Debian bouwen.

Voor afgeleide system, DFSG en "main" vereenvoudigen het opbouwen van systemen met voorspelbare licenties.


== Kwaliteit van implementatie ==

Mensen zeggen vaak dat ze tot Debian besloten hebben vanwege apt-get of dat apt de 'killer aplicatie' is van Debian. Maar apt-get is niet de oorzaak waarom Debian zo goed is: apt-get is een kenmerk gereproduceerd (en, naar mijn mening, nooit geevenaard), door andere distro's -- noem het urpme, apt4rpm, yum of welke dan ook. De bijzondere factor in Debian is haar beleid en het strikte pakket formaat Kwaliteits Garantie proces (kijk naar bijvoolbeeld apt-listchanges, apt-list-bugs, dpkg-builddeps, pbuilder, pbuilder-uml -- geen van deze kon worden geimplementeerd zonder een beleid (denk je eens listchangelog in zonder een robuust changelog formaat). Het is werkelijk zeer, zeer eenvoudig om software op een Debian box te installeren.

Dit lijkt op Cargo Cult religie, wat inhoud: apt-get is het zichtbare aspect van Debian haar beleidsysteem, op eenzelfde manier dat cargo-cult beoefenaren snelwegen en andere karakteristieken zagen als de bron van westerse goederen ("cargo"), en maakten hun eigen replica's, compleet met namaak houten koptelefoons voor verkeerstorens. Op dezelfde manier hebben andere distros het oppervlakkige, zichtbare aspect van Debian haar pakket-infrastructuur gebouwd. Nog erger: de tegenstellingen tussen technische benodigdheden en marketing / economische noodzaak werken vaak op het scherp van de snede. Minder erg voor de meeste GNU/Linux distros dan voor eigendomssoftware, maar ze zijn duidelijk aanwezig.

Red Hat, Mandrake en andere distro's hebben werkelijk massieve basis installaties. Waarom? Ik denk omdat het installeren van software vreselijk lastig is. Zelfs met RPM is het een klunzige procedure, onmogelijk om te automatiseren. Met Debian is het een fluitje van een cent.


Dus de werkelijke 'killer app' is Debian beleid, het veiligheidsteam, de officiele bug prioriteits mechanismen en het beleid over bugs (namelijk: ieder programma zonder een handleiding levert automatisch een fouten rapport. Iedere interactie met de gebruiker zonder debconf te gebruiken is een fout). Zoals de Wiki bladzijde Why Debian Rocks (http://twiki.iwethey.org/Main/WhyDebianRocks) het zegt:
Line 75: Line 81:
This is the crux, the narthex, the throbbing heart of Debian and what makes it so utterly superior to all other operating systems. Policy is defined. It is clear. It is enforced through the tools you use every day. When you issue apt-get install foo, you're not just installing software. You're enforcing policy - and that policy's objective is to give you the best possible system.

What Policy defines are the bounds of Debian, not your own actions on the system. Policy states what parts of the system the package management system can change, and what it can't, how to handle configuration files, etc. By limiting the scope of the distribution in this way, it's possible for the system administrator to make modifications outside the area without fear that Debian packages will affect these changes. In essence, Policy introduces a new class of bugs, policy bugs. Policy bugs are release-critical -- a package which violates policy will not be included in the official stable Debian release.

Let me reiterate, because that is the whole secret: A package which violates policy will not be included in the official stable Debian release.
Dit is de kern, het hart van Debian en wat haar zo superieur maakt boven alle andere systemen. Het beleid ligt vast. Het is duidelijk. Het wordt bekrachtigd door de gereedschappen die je iedere dag gebruikt. Wanneer je 'apt-get install foo' uitvoerd, installeer je niet alleen software. Je bekrachtigd het beleid. En dat beleidsdoel is om je het best mogelijke systeem te geven.

Wat in het Beleid beschreven staat is het bindmiddel van Debian, niet je eigen acties op het syteem. Het Beleid bepaald welke delen van het systeem het pakket-management systeem mag veranderen en wat het niet kan, hoe om te gaan met configuratie bestanden etc. Door het beperken van het zicht van de distro op deze manier is het voor de systeembeheerder mogelijk om veranderingen aan te brengen zonder de angst hoeven te hebben dat Debian pakketten deze veranderingen beinvloeden. In essentie** (werkelijkheid?), Beleid introduceert een nieuw type fouten: beleidsfouten. Beleidsfouten zijn release-kritiek -- een pakket dat niet met het Beleid overeenstemt wordt niet opgenomen in de Stabiel Debian versie.

Laat me dit herhalen, want dit is het grote geheim: Een pakket dat niet met het beleid overeenkomt wordt niet in de Debian Stabiel opgenomen.
Line 82: Line 89:
Add to that the Debian QA team which does non maintainer uploads (NMUs), helps with bug cleanup, performs security updates, and ensure that there is someone looking at the system holistically, and working to create an integrated OS, as opposed to merely fixing individual packages in isolation. That is what makes people swear by Debian. There are a lot of tools in the QA subsystem to help developers take care of their packages -- just look at http://qa.debian.org/developer.php?login=srivasta Voeg hier aan toe het Debain Kwaliteits team welke niet-onderhoud-uploads (NMU's) doen, helt met het opschonen van fouten, voert zekerheids updates uit en zorgt er voor dat iemans het gehele systeem overziet en bewaakt, en werken om een geintegreerd besturingssysteem te creeren, ** bovenop het repraren van individuele pakketten.** Dit maakt dat mensen zweren bij Debian. Er zijn veel gereedschappen in het Kwaliteits Garantie systeem om ontwikkelaars met hun pakketten te helpen -- kijk naar http://qa.debian.org/developer.php?login=srivasta
Line 86: Line 94:
The fact that Debian supports as many architectures as it does also feeds into the quality of packages: Porting software often uncovers flaws in the underlying code. Add to the fact that all software in Debian goes though 10 or so automatic build daemons, and needs be bug free when building on these different environments, requires that the build and install scripts be very robust, and requires a very strict tracking of build time dependencies. Add source archive mirrors and version tracking, and you have a fairly robust system (snapshot.debian.net provides for easy rollbacks) The fact that Debian supports as many architectures as it does also feeds into the quality of packages: Porting software often uncovers flaws in the underlying code. Add to the fact that all software in Debian goes though 10 or so automatic build daemons, and needs be bug free when building on these different environments, requires that the build and install scripts be very robust, and requires a very strict tracking of build time dependencies. Add source archive mirrors and version tracking, and you have a fairly robust system (snapshot.debian.org provides for easy rollbacks)
Line 252: Line 260:
 * [http://www.us.debian.org/doc/FAQ/ Debian GNU/Linux FAQ]
 * [http://twiki.iwethey.org/Main/WhyDebianRocks Why Debian Rocks]
 * [http://news.netcraft.com/archives/2005/12/05/strong_growth_for_debian.html Netcraft.com, strong growth for Debian]
 * [[http://www.us.debian.org/doc/FAQ/|Debian GNU/Linux FAQ]]
 * [[http://twiki.iwethey.org/Main/WhyDebianRocks|Why Debian Rocks]]
 * [[http://news.netcraft.com/archives/2005/12/05/strong_growth_for_debian.html|Netcraft.com, strong growth for Debian]]

Vertalingen: English


"Waarom Debian?", zou je vragen. Debian is een ander GNU/Linux distributie, en is en ander Unix-like operating systeem. Wat maakt het beter dan de rest? Waarom zou ik Linux gebuiken? Wel, dit word in het volgende document uitgelegd:

http://people.debian.org/~srivasta/talks/why_debian/talk.html

Om zeker te zijn dat dit document voor iedereen beschikbaar is, en in uw moedertaal, is het hier gearchiveerd:

Waarom Linux? Waarom Debian?

Door Manoj Srivastava (srivasta at debian.org)

Ik ben zeker niet de goede persoon om zonder emoties een vergelijking te maken over besturingssystemen, gedeeltelijk omdat ik bevooroordeeld ben en door mijn beperkte kennis met besturings systemen die niet mijn eerste keuze zijn. Ik ben ook niet de geschikte kandidaat om mijn keuze te verdedigen, omdat de redenen van mijn voorkeur waarschijnlijk niet universeel zijn en de omstandigheden waarin ik mijn keuze maakte ondertussen veranderd zijn.

Ik heb echter geprobeerd dit artikel in een breder perspectief te zetten dan alleen mijn inzichten en heb daarom ook gekeken naar de meningen van anderen die dezelfde keuze hebben gemaakt -- maar gezien de subjectiviteit van dit onderwerp zal ik voornamelijk vanuit mijn eigen perspectief spreken en die van mensen die reeds voor Debian hebben gekozen.

Gezien het karakter van de doelgroep van dit artikel, ga ik niet veel tijd besteden waarom men een UNIX besturingssysteem zou moeten kiezen boven een Microsoft besturingssysteem. Het is voldoende om te vertellen welke volgende criteria me van Windows afhaalden: Veiligheid. Flexibiliteit. Controle over mogelijkheden. Filosofie. Kosten. Snelheid. Doelmatigheid. Betrouwbaarheid. Beschikbaarheid en keuzes in programmatuur. Gevoeligheid voor Wormen en Virussen. Openheid en snelheid van het oplossen van bekende fouten. Klusteren. Veel-gebruikers OS. Het ontbreken van een GUI of een HTTP browser als een integraal geheel van het besturingssysteem.

http://www.michaelhorowitz.com/Linux.vs.Windows.html geeft een relatief objectieve vergelijking van Linux en Windows en kan dienen als een inleiding van Linux voor Windows gebruikers. Het is meer gericht naar de commerciele aspecten dan dit artikel (met betrekking tot het succes van Linux distributies/bedrijven, bijvoorbeeld).

Filosofie en Gemeenschap

Uiteindelijk, filosofie is het meest duurzame kriterium tussen de bestuurssystemen die we bespreken. Prestaties veranderen. Gebruiksvriendelijkheid, betrouwbaarheid, beschikbaarheid van programmatuur -- al deze eigenschappen veranderen in de loop van de tijd en je moet die iedere keer weer opnieuw evalueren.

Ik moet bekennen dat filosofie en gemeenschap me in eerste instantie naar het Linux kamp leidde en daarna naar Debian; en ik denk dat dit nog steeds de meest belangrijke kriteria zijn, en deze worden vaak onderschat.

Waarom is vrije software een goed iets? Gedurende de bijna twee decennia dat ik betrokken ben bij vrije software heb ik mensen deze vraag gesteld (en me vaak verbaasd over de antwoorden). De populaire antwoorden schijnen te zijn omdat het 'cool' is of gratis. De motivatie van de auteurs zijn ook gevarieerd, maar de prijs die zij er vaak voor krijgen is erkenning, aanmoediging van collega's, of ervaring die kan worden gebruikt voor de werkplek.

Maar ik denk dat dit het 'raison d'être' van vrije software mist -- het aspect van het op de schouders staan van meesters. Ik zou graag de analogie willen geven van de manier waarop wetenschappelijk onderzoek wordt uitgevoerd. Als onderzoekers iedere keer weer het wiel zouden moeten uitvinden en voor zichzelf zouden moeten ontdekken wat in literatuur beschreven staat, dan zou de voortgang in de onderzoekswereld worden belemmerd. De meeste van mijn collega's begonnen hun onderzoek met een literatuurstudie, zoeken naar interesante vindingen en misschien verbinden van ongerelateerde artikelen, voortbouwen op de ideeen en technieken van andere onderzoekers in het veld. In de meeste laboratoria bestaat het geheime aspect van het onderzoek alleen tot het moment van publikatie -- daarna delen zij de technieken, ideeen en resultaten -- inderdaad, reproduceerbaarheid is een belangrijke factor van succes.

In tegenstaelling tot eigendoms software, waar we altijd vanaf het prille begin moeten starten -- Ik denk dat we vleugels zouden krijgen als we alleen al ideeen en werkuren vrijelijk zouden delen en daarop voortbouwen. Dit zou de tijd, moeite en kosten van innovatie verlagen, het bevorderen van optimaal gebruik en ontwerp methoden om te ontwikkelen en rijpen, en het zwoegen van programmeren verminderen, wat de drempel verhoogd van het zelf ontwikkelen van oplossingen.

We moeten verzekeren dat de stimulans voor prestatie nog bestaat (en dat hoeft niet alleen een winstmotief te zijn).

Deze overtuiging heeft mij geleid tot de keuze van GPL, en de vrije software stichting inzicht op de dingen, in tegenstelling tot de BSD licentie, wat ook vrije software licenties zijn, en leidden eventueel tot de keus van Debian. Volgens mijn persoonlijke mening betreft de BSD licentie meer persoonlijke trots in het schrijven van vrije software, zonder zich zorgen te maken wat er met de software zal gaan gebeuren: ik wil meer dan alleen da. Ik wel mijn collega's helpen met een syergetische gemeenschap; terug te geven aan een bron van bruikbare software.

Debian is een oefening in het bouwen van een gemeenschapsstal; samen kunnen we veel meer bereiken dan een ieder alleen kan. Het Debian sociaal contract is een belangrijke factor in mijn keuze voor Debian, met zijn combinatie van verplichtingen aan vrije software en de pragmatische herkenning dat er gevallen zullen zijn waar bruikbaarheid vraagt om software die niet aan onze richtlijnen voldoen.

Gemeenschap is de andere reden dat ik naar Linux ging, meer dan naar BSD's. Toen ik op zoek was naar een vrije Unix-achtig besturingssysteem om op mijn nieuwe universiteits 386 te installeren, de BSD's waren veel meer robuust en presteerden veel beter, en ik had vrienden die zworen bij de BSD's. Wat me afstootte was het kasten systeem zoals die bestaat in de BSD gemeenschap. Er waren kernontwikkelaars hoog op, en je begint beneden onderaan als een nieuweling **contributer**. De Linux gemeenschap, hoewel recalcitrant, leek veel meer alomvattend -- je voorgeschiedenis deed er minder toe dan de software die je produceerde. En ik kon direct bijdragen aan het ontwikkelen van het besturingssyteem dat ik zou gebruiken. I vermoed dat dit een andere reden is dat ik de voorkeur geef aan Debian -- Ik ben er lang genoeg om het in de richting te sturen zoals ik denk een besturingssysteem zou moeten zijn.

Practisch nut en gebruik

Verondersteld dat ik niet helemaal de pragmatici onder jullie ben kwijtgeraakt, de criteria die de grootste meerderheid het meest belangrijk acht wanneer men een besturingssyteem kiest zijn, na de kosten, het nut en het gebruik. Natuurlijk, het nut hangt af wat je doelen en benodigdheden zijn, maar er is een groot gebied dat...

Of course, utility depends on what your goals and requirements are, but there broad areas we can still address.

Er is meer in een besturingssyseem dan een kernel met een hutspot van software erbovenop - systeem integratie is een onderdeel waar meestal weinig aandacht aan wordt geschonken wanneer de voor-en nadelen van een syteem worden bediscussieerd. Maar een goed geintegreed systeem - waar ieder onderdeel precies past en andere delen van het systeem aanpast - heeft het practisch nut sterk vergroot boven het alternatief.

Debian, in mijn ervaring en in die van mijn respondenten, is het best geintegreerd besturingssysteem dat bestaat. Debian paketten hebben een spoor van relaties met elkaar, niet alleen door een platte afhankelijkheids-en conflict mechanisme, maar een rijke verzameling van genuanceerde relaties. Voor- afhankelijkheden, gewone afhankelijkheden, aanbevelingen, suggesties, conflicten en evenwichtige verhoudingen. Apart hiervan, de pakketten zijn geordend naar prioriteit (), en hun functie. Deze rijkdom van relaties, welke het pakketsysteem herkent en er rekening mee houdt, geeft het niveau aan hoe paketten bij elkaar passen.

Debian wordt door ongeveer 1000 vrijwillegers ontwikkeld. Dat betekend dat iedere ontwikkelaar vrij is om programma's te onderhouden waarin hij is geinteresseerd of die hij nodig heeft voor bepaalde doelstellingen in het gewone leven. Dat is de reden waarom Debian in staat is om zoveel verschillende specialismes te dekken -- haar ontwikkelaars willen gewoon hun eigen problemen oplossen. Deze brede focus verschilt van commerciele distributies welke alleen algemene taken proberen te omvatten.

Ik heb ervaren dat Debian machines op werk minder aandacht vragen, gemakkelijker zijn om te vernieuwen en breken gewoonweg niet zo vaak als Red Hat en Mandrake systemen die ik beheer. Ik heb me laten vertellen dat het werken met SunOS, bijvoorbeeld, is veel meer, ummm, uitdagend.

Een van de redenen om Debian te verkiezen boven andere distros is haar enorme afmeting van het project, wat sterk suggereerd dat Debian niet zomaar zal verdwijnen en men opeens achtergelaten wordt zonder enig ondersteuning. Debian kan niet failliet gaan. Haar sociale contract laat niet toe dat het project opeens beslist om geen ondersteuning meer te geven aan niet-bedrijfsversies van de distro. Ik wil niet dat mijn OS wordt gegijzeld door wie dan ook zijn 'business plan'!

Je kunt het niveau van risico dat je wilt nemen fijn afregelen, sinds Debian drie verschillende releases heeft: Stabiel, Testing en Onstabiel. Op enkele van onze machines (de server, de kiosk machines) draaien we Stabiel. Enkele andere systemen (individuele werkstations) draaien verschillende combinaties van Testing/Onstabiel. (Merk op dat er geen veiligheids-updates zijn voor Testing.) Sommige dingen draai ik vanaf een Onstabiel systeem op mijn eigen werkstation. Wat zo mooi is is de mogelijkheid om fijn afgestemde beslissingen te nemen voor verschillende systemen met verschillende functies. Maar zelfs de meest avontuurlijke keuzes zijn solide genoeg zodat zij bijna nooit breken. En Stabiel breekt gewoon nooit ;-).

Debian voorziet een grote dienst van respons opwaarts. Bijvoorbeeld, het XFree project onderhoud zelf niet alle architecturen die Debian ondersteund - **Het hangt wat dat betreft van Debian af **. Er zijn zelfs een aantal diepe bug reparaties voor libc (er was een fout in de referentie teller in glibc wanneer dlopen een 'shared object' ... Deze aandacht voor detail is voor ieder andere Linux distro zeer moeilijk te evenaren. Het nievau van beschikbare hoogwaardige, snelle en vriendelijke hulp voor eindgebruikers is gewoon bijzonder - en geen enkele oude-stijl comercieel bedrijf die ik ermee kan vergelijken, zoald DEC, kan zich daaraan meten, tenzij je er zeer veel geld ervoor betaald. Op deze manier kan ondersteuning worden gegeven door derden, zonder de kennis in huis te hebben, voor bedrijven die op Debian bouwen.

Voor afgeleide system, DFSG en "main" vereenvoudigen het opbouwen van systemen met voorspelbare licenties.

Kwaliteit van implementatie

Mensen zeggen vaak dat ze tot Debian besloten hebben vanwege apt-get of dat apt de 'killer aplicatie' is van Debian. Maar apt-get is niet de oorzaak waarom Debian zo goed is: apt-get is een kenmerk gereproduceerd (en, naar mijn mening, nooit geevenaard), door andere distro's -- noem het urpme, apt4rpm, yum of welke dan ook. De bijzondere factor in Debian is haar beleid en het strikte pakket formaat Kwaliteits Garantie proces (kijk naar bijvoolbeeld apt-listchanges, apt-list-bugs, dpkg-builddeps, pbuilder, pbuilder-uml -- geen van deze kon worden geimplementeerd zonder een beleid (denk je eens listchangelog in zonder een robuust changelog formaat). Het is werkelijk zeer, zeer eenvoudig om software op een Debian box te installeren.

Dit lijkt op Cargo Cult religie, wat inhoud: apt-get is het zichtbare aspect van Debian haar beleidsysteem, op eenzelfde manier dat cargo-cult beoefenaren snelwegen en andere karakteristieken zagen als de bron van westerse goederen ("cargo"), en maakten hun eigen replica's, compleet met namaak houten koptelefoons voor verkeerstorens. Op dezelfde manier hebben andere distros het oppervlakkige, zichtbare aspect van Debian haar pakket-infrastructuur gebouwd. Nog erger: de tegenstellingen tussen technische benodigdheden en marketing / economische noodzaak werken vaak op het scherp van de snede. Minder erg voor de meeste GNU/Linux distros dan voor eigendomssoftware, maar ze zijn duidelijk aanwezig.

Red Hat, Mandrake en andere distro's hebben werkelijk massieve basis installaties. Waarom? Ik denk omdat het installeren van software vreselijk lastig is. Zelfs met RPM is het een klunzige procedure, onmogelijk om te automatiseren. Met Debian is het een fluitje van een cent.

Dus de werkelijke 'killer app' is Debian beleid, het veiligheidsteam, de officiele bug prioriteits mechanismen en het beleid over bugs (namelijk: ieder programma zonder een handleiding levert automatisch een fouten rapport. Iedere interactie met de gebruiker zonder debconf te gebruiken is een fout). Zoals de Wiki bladzijde Why Debian Rocks (http://twiki.iwethey.org/Main/WhyDebianRocks) het zegt:

Dit is de kern, het hart van Debian en wat haar zo superieur maakt boven alle andere systemen. Het beleid ligt vast. Het is duidelijk. Het wordt bekrachtigd door de gereedschappen die je iedere dag gebruikt. Wanneer je 'apt-get install foo' uitvoerd, installeer je niet alleen software. Je bekrachtigd het beleid. En dat beleidsdoel is om je het best mogelijke systeem te geven.

Wat in het Beleid beschreven staat is het bindmiddel van Debian, niet je eigen acties op het syteem. Het Beleid bepaald welke delen van het systeem het pakket-management systeem mag veranderen en wat het niet kan, hoe om te gaan met configuratie bestanden etc. Door het beperken van het zicht van de distro op deze manier is het voor de systeembeheerder mogelijk om veranderingen aan te brengen zonder de angst hoeven te hebben dat Debian pakketten deze veranderingen beinvloeden. In essentie** (werkelijkheid?), Beleid introduceert een nieuw type fouten: beleidsfouten. Beleidsfouten zijn release-kritiek -- een pakket dat niet met het Beleid overeenstemt wordt niet opgenomen in de Stabiel Debian versie.

Laat me dit herhalen, want dit is het grote geheim: Een pakket dat niet met het beleid overeenkomt wordt niet in de Debian Stabiel opgenomen.

Voeg hier aan toe het Debain Kwaliteits team welke niet-onderhoud-uploads (NMU's) doen, helt met het opschonen van fouten, voert zekerheids updates uit en zorgt er voor dat iemans het gehele systeem overziet en bewaakt, en werken om een geintegreerd besturingssysteem te creeren, ** bovenop het repraren van individuele pakketten.** Dit maakt dat mensen zweren bij Debian. Er zijn veel gereedschappen in het Kwaliteits Garantie systeem om ontwikkelaars met hun pakketten te helpen -- kijk naar http://qa.debian.org/developer.php?login=srivasta

The evaluation process each package has to undergo in the unstable distribution before it makes it into testing adds to the quality of the finished product. Once a package has not shown any important problem for a certain time period, it goes into the testing distribution. This distribution is the release candidate for the future stable distribution, which is released only when all release critical bugs are resolved. This careful testing process is the reason why Debian has a longer release cycle than other distributions. However, in terms of stability this is an advantage. (Note: RH Enterprise Linux is apparently shooting for 12 - 24 month release cycles. Closer to what Debian's historically had.)

The fact that Debian supports as many architectures as it does also feeds into the quality of packages: Porting software often uncovers flaws in the underlying code. Add to the fact that all software in Debian goes though 10 or so automatic build daemons, and needs be bug free when building on these different environments, requires that the build and install scripts be very robust, and requires a very strict tracking of build time dependencies. Add source archive mirrors and version tracking, and you have a fairly robust system (snapshot.debian.org provides for easy rollbacks)

The Debian bug tracking system is a key to the quality of the distribution. Since releases are linked to the numbers of release critical bugs in the system, it ensure that the quality of the release is better than any proprietary UNIX I have run. The Release Manager is fairly ruthless about throwing out any non essential package with RC bugs if they do not get fixed -- or delaying the release if it is a critical package with the bug.

Compared to commercial Linux distributions, Debian has far higher developer to package ratios. Added to the lack of business cycle driven deadlines, Debian tends to do things right, rather than do things to get a new version out in time for Christmas.

According to a recent Slashdot story, there are more distributions based on Debian now than there are for the market leader, RedHat (63 and counting, including Ubuntu, Xandros, Knoppix, Lycoris, Lindows (Lind--s ?), Libranet, mophix ...).

Fault recovery is absolutely bar-none the best. (see http://www.linuxworld.com/story/32607.htm) See also the script (http://linuxmafia.com/faq/Debian/package-database-rebuild.html) about recovering a Debian system without having a backup of /var/lib/dpkg.

Feature set and Selection of Software

Debian has over 10000 packages now. The chances are that anything you need is already packaged and integrated into the system, with a person dedicated to keeping it (and a small number of other packages) up to date, integrated, and bug free.

Debian has a huge internationalization effort, translating not only the documentation (I have people who send me translated manual pages for the packages I maintain), but also the configuration and install scripts (all debconf interaction can be fully internationalized). It helps to have a massively geographically distributed community -- we have native speakers in tonnes of languages. I think the internationalization effort in Debian matches that for Gnome and KDE.

Other notables, for which I have too little time to pay proper attention to, are: The Debian documentation project, Alioth, Debian installer, Debian CD, Lintian, and the package tracking system.

Some other things which will keep me using Debian until they're supported by something else:

  1. debconf and the ability to pre-seed the database
  2. make-kpkg with all the install-time prompts turned off
  3. /usr/share/doc/{Changelog.Debian,changelog,copyright,README.Debian}

Debian also has a great set of tools for kernel or distribution hackers and systems integrators debbootstrap, chroots, user mode Linux, Xen. All kinds of neat tools to help hack on installation mechanisms, kernels and drivers.

There are a number of niche communities that have found a home with Debian. These are sub projects; Debian-Jr, Debian-med, Debian-Edu, Debian-non-profit, and Debian-lex. A number of Debian developers are blind, and as a result, Debian is very very friendly to the blind. There is additional material on Custom Debian distributions (http://people.debian.org/~tille/debian-med/talks/paper-cdd/debian-cdd.html/)

Kernels

The BSD kernels, from all accounts, seem to be stabler, and of better quality than Linux kernels seem to be. BSD kernels are much easier to read and understand. On the flip side, Linux kernels more feature rich, and the quality has improved significantly, seem to perform much better, and better hardware support than the BSD kernels do. Indeed, I've heard comments that when it comes to driver support, the BSD's are where Linux was 5 years ago. I'll talk more about hardware support below. Personally, the supposed added bugginess of the Linux kernels have not exceeded my threshold of acceptability. And, overall, I don't think that a Debian box feels any less robust and stable than, say, a FreeBSD box. Of course, the recent spate of holes in Linux kernels are beginning to strain that. (However, we should keep in mind that having more features is a contributory factor: the two latest holes were in the mremap(2) call that is not available for any of the *BSD.)

Of course, Debian Gnu/FreeBSD may provide the best of both worlds.

User Land

The BSD user land is different from the GNU user land. I have grown up with the GNU user land installed on Ultrix/Aix/HP-UX boxes for consistency, and for me the GNU userland feels far more comfortable.

It should be noted that you can install the GNU userland on a BSD box, and a number of people do so (/usr/local/gnu/*, for example). Of the installations that do have both sets of utilities installed, the reports are that the user-base overwhelmingly uses the GNU utilities, even though that's not the default. In general, the FreeBSD utilities appear to be lighter weight but feature poor, and on modern hardware the small amount of memory savings just doesn't matter.

It also doesn't help that they don't provide good command line help; it's much easier to tell a newbie that if they type foo --help they will get something that might be useful.

OpenBSD's base userland is quite complete. I prefer the GNU userland because I am used to it, but OBSD's base system is quite workable. FBSD is quite a different story - In FBSD they strive to produce a minimal base system, and they don't expect people to only use that - they expect people to install many ports. FreeBSD becomes the most Debian-like system in the BSD family - you have a base system and you build on top of that. Its userland is whatever you choose it to be.

Maintenance and administration

Upgrades have been said to be the killer advantage for Debian. More than most other OS's, the network is the distribution and upgrade mechanism for Debian. Policy, the thought that has gone into the maintainer scripts, and the ways in which they can be called, the full topographical sorting over the dependency web done by apt and friends, all work together to ensure that upgrades in place work smoothly (I've never had to reinstall my machines, though some have been upgraded in place for over 5 years). Reinstalls are not unheard of in an recommended BSD upgrade path (Since 2.8 or 2.9, OpenBSD said at least two times to i386 users "upgrade not supported / not recommended, do a fresh install").

This ease of upgrades also plays into security of the system; security upgrades are far more convenient on Debian than they are on other systems, thanks to the Security team. For us mere mortals not on vendor-sec, having security.debian.org in our sources list ensure that our boxes get updated conveniently, and quickly, after any exploit is made public -- since the security team was already working on a fix before the details went public. This means that systems get updated in minutes, whereas the recommended way to do an upgrade on a BSD OS involves recompiling the entire system (at least, the "world").

Debian attempts to ensure smooth upgrades skipping a major release - which is not something that I have seen supported elsewhere. I keep coming back to quality of packaging

Administering Debian is the primary reason most people stay with it. I know no other distribution where you can type in apt-get install sendmail, and walk away with a fully functional mail server, complete with SASL and TLS, fully configured, complete with certificates. All administration can be done over SSH given only dial-up speeds.

The Debian guarantee that user changes to configuration files shall be preserved, and that all configuration files shall live in /etc (as opposed to being all over the file system) makes for easier backups (I have my /etc living under version control).

Debian is compliant with the FHS, and LSB compliance is a release goal.

The distributed nature of Debian development and distribution makes it really easy to set up a separate repository of custom packages that can then be distributed in house; and the policy and build mechanisms ensure that third parties can build the system just as easily in a reproducible fashion.

Portability and Hardware Support

Linux tends to support more of the esoteric hardware than BSD does. whether that is a problem, depends on your needs. Support for the high quality hardware is mostly the same. A notable exception is for RAID hardware; the 3ware RAID cards are just becoming supported in BSD, but have had Linux support for a while. IBM's assurance of Linux support on all their hardware, and that of HP, is also an advantage for Linux. I also like the multiple journaling file systems that have come into the Linux kernel recently. For desktop, the killer factor is drivers. And Linux leaves all the other X86 Unixes behind by a mile.

When it comes to portability, NetBSD is supposed to be the byword. However, I went and had a good, hard look at what is supported by NetBSD, and Debian: I found that Debian supports ibm s/390 and ia64, while NetBSD has support for sun2 (m68010), PC532 (whatever that is [apparently a custom machine of which only 200 models were ever made]), and VAX. I am sure which set I am more interested in (though it might be cool to have a VAX puttering around in the basement). Note that what NetBSD call architectures are often labeled sub-architectures by Debian, and thus do not count in the 11 supported architecture count.

Source Builds

I have heard a lot of things about the ports mechanism of BSD, and the portage systems of gentoo. I have also heard about how people have problems actually getting things to compile in the ports system. Apart from the fact that compiling everything rapidly gets old (I have been there, done that, when I used Soft Landing Systems (SLS) distribution back in '93).

It is not as if you can't do a port like auto build of Debian -- we have auto-builders on 11 architectures that do that, continuously, every single day -- the question is why would one want to? I have yet to see a single, replicable test demonstrating any palpable performance improvement by local, tailored optimized compilations -- and certainly none that justifies, in my eyes, the time spent tweaking and building the software all over.

Someone said that when they were younger and felt like playing a prank they would adjust some meaningless parameters on someone's computer and tell them "this will make it run about 5% faster, but you probably won't notice it". With such a challenge they usually responded by becoming totally convinced that their machines had been improved considerably and that they could feel the 5% difference!

Conventional wisdom seems to indicate overall system performance increases are less than 1%. Specific programs can benefit greatly, though, and you can always tweak a critical app for your environment in Debian. I think whatever time is saved by running an optimized system is more than compensated for by the time spent building the system, and building upgrades of the system (I've heard of people running doing their daily update in the background while doing other things in the foreground.)

Not to mention how integration suffers by not having a central location where interoperability of the pieces can be ever tested well, since every system would differ wildly from the reference.

A source build system is also far more problematic when it comes to major upgrades -- I have anecdotal evidence of it not being as safe and sane as the Debian upgrade mechanisms.

Anyway, if I do want to build packages from source on Debian, I can use apt-get source -b, apt-src, or any of a number of tools. And when doing local builds I do trust that locally built deb's will be installed in a safe and sane way, replacing properly the old stuff. The build depends pull in any required dependencies for builds, and I routinely build in pbuilder-user-mode-linux to ensure uniform builds.

The real point here is that Gentoo is a distro for hobbyists and übergeeks / hard-core linux users, who can spare the time building their apps. I know Gentoo also provides pre compiled binaries -- but does that not defeat their supposed advantage? For an enterprise environment where down time does cost money this is simply inadmissible and Debian provides the best solution. Those of use which administer more than a handful machines can really appreciate how convenient it is to be able to issue apt-get update && apt-get upgrade at once instead of having to go downloading, configuring, compiling and installing software machine per machine, without any sort of automated help ( I am not completely doing justice to emerge / portage here, but the point is clear, I hope ). I can emphasize this enough: for "serious"/production usage, binary distros are the best and only viable solution; Amongst them, Debian ( not only because of APT but also because of all the hard work done by DD to ensure correctness of the packaging ) is the best [I have tried SuSE, RedHat and Mandrake, and I wouldn't go back even if offered lots of money; Gentoo is not an option either]

Security and Reliability

There is always a trade off between security and convenience -- the ultimately secure computer is one that is never turned on. Secure, but not very useful. You have to decide where your comfort zone lies.

What does one think of when one says Security and Unix like OS? OpenBSD, with some justification. It is audited and has the small size, small system requirements AND the pure text based install. If you stick to the core install, you get an audited system, with no services turned on by default and an assurance that there are no holes in the default install that can lead to a remote root compromise. However, you tend to end up with old software, and the default install really does very little. W^X and protection against stack overflows (?ProPolice) on OpenBSD http://www.openbsd.org/33.html, and exec-shield and Adamantix (PaX) patches for Linux (you may have to recompile your kernel on Debian for these). Most people agree that the secure and audited portion of OpenBSD does not provide all the software they require. Also, OpenBSD's performance numbers are, umm, poor, compared to SELinux on a 2.6.3 kernel.

OpenBSD's secure reputation is justified - but only when you know the project, when you are familiar with what does it really cover. OpenBSD may be a great firewall, maybe even mail or static Web server - As long as you keep out of the ports tree, you do have an audited, security-conscious system. I know few applications, however, for such a system. The OpenBSD userland ports break more often than stable Debian -- but, in OpenBSD, ports are officially not part of the system, and should a security problem appear in one of them, you are on your own.

Arguably, Debian stable equals or beats the exact claims -- and there appears to be little real world difference between Debian and openbsd at this time. One has to work a bit to harden the default Debian install with just Standard priority packages, but this is just a few minutes work for experienced admins. Code audits are in a more advanced stage for OpenBSD; though one must bear in mind that despite all the audits there have been high profile bugs in OpenSSH recently -- so take the audited label with a pinch of salt.

The Debian GNU/Linux distribution has a strong focus on security and stability. We have an Security team, automated build systems to help the security team quickly build versions across all the architectures that are supported, and policy geared towards those goals. Here is more on a security oriented comparison (http://lists.debian.org/debian-user/2003/debian-user-200308/msg00541.html) of OpenBSD and Debian.

Even though you don't quite need a tool chain on every target BSD system to roll out security updates ("make release", or "make package" to build on one machine and install elsewhere), it is quite a bit more inconvenient than the Debian packaging system. Debian handles binary package distribution much better. One can have his own aptable archive and feed all productive servers from is, using Debian's native mechanisms.

When it comes to real security, however, without mandatory access controls you have very little assurance. So SELinux (and the still nascent TrustedBSD) would be far better choices than OpenBSD or base Debian Stable.

Even without SELinux, I find the rock solid stability of Debian stable, with the peace of mind that comes from back ported security fixes provided by the Security team, very persuasive. It is easy for an untrained recipient to keep up to date with security; and reduces the likelihood of compromise. This is very important in a commercial environment with a large number of computers, where is it important that the software NOT be upgraded every few months.

There is another benefit of the Debian's Security team when it comes to the stable distribution. There is, however, only one version of the ports tree. Whereas in Debian, you have multiple versions of, e.g., apache, KDE, and X11 -one for every suite with security updates for the stable suite- there is no such thing on FreeBSD. Although, of course, the port makefile will be updated if a vulnerability has been found in a given package, the only way to plug the hole on your system in such a situation is to install the new version of the package, with all possible problems that may cause. Compare to Debian, where you have the ability to install the same version of the software, with the security fix back-ported. Also, if you're working with a ports-installed version of the vulnerable package, you'll stay vulnerable for as long as the compilation runs, which may or may not be a considerable amount of time.

I have some data comparing Linux distributions and the time to patch known security vulnerabilities, no data of BSDs, however. It's available at http://people.debian.org/~jfs/debconf3/security/data/.

Scalability and Performance

I was not initially going to talk at all about performance and numbers, since these have mattered little to me personally, and performance numbers change from release to release. However, I realize that these are important decision criteria for some people, and I have attempted to look up a recent look at the numbers.

The full set of benchmarks, complete with code, is available here. http://bulk.fefe.de/scalability/ Here are his words, from the conclusion section, updated to reflect the latest benchmarks.

Linux 2.6 scales O(1) in all benchmarks. Words fail me on how impressive this is. If you are using Linux 2.4 right now, switch to Linux 2.6 now!

NetBSD has better scalability than FreeBSD.

FreeBSD 5.1 has very impressive performance and scalability. (Note that it is as yet unreleased) I foolishly assumed all BSDs to play in the same league performance-wise, because they all share a lot of code and can incorporate each other's code freely. I was wrong. FreeBSD has the second best performance of the BSDs and it even comes close to Linux 2.6.

Linux 2.4 is not too bad, but it scales badly for mmap and fork.

OpenBSD 3.4 performed really poorly in these tests. The disk performance sucks, the kernel was unstable, and in the network scalability department it was even outperformed by it's father, NetBSD. OpenBSD also gets points deducted for the sabotage they did to their IPv6 stack. If you are using OpenBSD, you should move away now.

Conclusie

Voor zover ik weet is er geen ander besturingssysteem of distributie welke precies deze samenstelling heeft (gemak van onderhoud, betaalbaarheid, stabiliteit, grootte, aanpasbaarheid, sterke ondersteuning). Voor het grootste gedeelte wil ik niet aan mijn werkstation sleutelen en debuggen. Ik wil gewoon mijn werk gedaan krijgen, makkelijk, veilig en met minimale zorg over de infrastructuur die ik gebruik. Debian helpt mij daaraan te voldoen.

En dat is nog steeds de primaire reden waarom ik het vandaag gebruik, gezien vanuit een technisch standpunt. Software installatie en vernieuwing. De pakketten zijn top kwaliteit, installeren en vernieuwen gaat per definitie perfect. Software onderhoud is nog steeds een groot gedeelte van een systeembeheerder zijn werk en met Debian is het eenvoudig triviaal. Breng het zelfs niet ter sprake wanneer er over wat voor problemen dan ook met Debian wordt gesproken, het is niet de moeite waard. Niet ter zake doende.

Acknowledgement

  1. Wouter Verhelst <wouter@grep.be>

  2. José Luis Tallón <jltallon@adv-solutions.net>

  3. Andrew Suffield <asuffield@debian.org>

  4. Javier Fernández-Sanguino Peña <jfs@computer.org>

  5. Russell Coker <russell@coker.com.au>

  6. Andreas Metzler <ametzler@downhill.at.eu.org>

  7. Steve <sgbirch@imsmail.org>

  8. Toni Mueller <toni@debian.org>

  9. Marc Haber <mh+debian-devel@zugschlus.de>

  1. George Danchev <danchev@spnet.net>

  2. Lionel Elie Mamane <lionel@mamane.lu>

  3. Greg Folkert <greg@gregfolkert.net>

  4. Rudy Godoy <rudy@kernel-panik.org>

  5. Andreas Tille <tillea@rki.de>

  6. Nathanael Nerode <neroden@twcny.rr.com>

  7. Mark Ferlatte <ferlatte@cryptio.net>

  8. Gunnar Wolf <gwolf@gwolf.cx>

  9. Jim ?McCloskey <mcclosk@ucsc.edu>

  10. Bill Wohler <wohler@newt.com>

  11. Bill Richardson <bill@bothan.net>

  12. Alex Perry <alex.perry@qm.com>

  13. Woodrow Kirton <wkirton@surfwayx.net>

  14. David B Harris <dbharris@eelf.ddts.net>

  15. Joost van Baal <joostvb@mdcc.cx>

  16. Bill Allombert <allomber@math.u-bordeaux.fr>

  17. <root.man@earthlink.net>

  18. Viktor Rosenfeld <rosenfel@informatik.hu-berlin.de>

  19. "Adrian 'Dagurashibanipal' von Bidder <avbidder@fortytwo.ch>

  20. Razvan Petrescu <rpetrescu@montran.ro>

  21. s. keeling <keeling@spots.ab.ca>

  22. Karsten M. Self <kmself@ix.netcom.com>

Thanks also to the participants in the thread (http://lists.debian.org//debian-devel/2004/02/thrd2.html#00594) on the developers mailing list for their input.

Other Resources