'Topontwikkelaars Linux veel bezig met managen'

Greg Kroah-Hartman, de ontwikkelaar die verantwoordelijk is voor de usb- en pci-code van Linux, heeft geconstateerd dat de topmensen in het kernelteam steeds minder tijd hebben om zelf code te schrijven.

Twee jaar geleden kwam 80% van de nieuwe code van twintig mensen af, maar in de meest recente release kwam de top dertig gezamenlijk nog maar aan 30%. 'Het enige wat ik vandaag de dag doe is patches doorlezen', verklaarde Kroah-Hartman vorige maand op een symposium. Ieder stuk code moet door een aantal lagen heen om uiteindelijk in de officiële release terecht te komen. Het is niet ongebruikelijk dat een bijdrage door vier afzonderlijke mensen geaccepteerd moet worden. 'Het is een zooitje', aldus de gefrustreerde ontwikkelaar. Toch zijn er ook voordelen: toen men nog aparte versies onderhield - een stabiele tak en een voor het experimentele werk - duurde het veel langer voor nieuwe features in handen van de gebruiker kwamen.

Door de sterk toegenomen interesse in Linux lijkt een strakke organisatie bovendien gewoon nodig te zijn: in twee jaar tijd groeide het aantal actieve kernelontwikkelaars van 475 naar 920, waardoor er nu ieder kwartier wel een stuk nieuwe code wordt ingezonden. Een groot deel van die bijdragen komt van bedrijven: Red Hat en Novell staan voorop met 11,8% en 9,7%, gevolgd door IBM, Intel en SGI. Toch is er zeker ook nog ruimte voor zelfstandig werkende hackers, die gezamenlijk 4% van de verbeteringen aanleveren. Door de snelle ontwikkelingen binnen het 8,2 miljoen regels tellende project is het bijna onmogelijk om geïsoleerd aan een bepaald stuk te werken. 'Je kunt het niet bijhouden, dat is fysiek gewoon onmogelijk.' De enige manier om de ontwikkeling te beïnvloeden is door er actief aan mee te doen.

Ondanks alle hectiek lijkt men het aantal bugs redelijk onder controle te hebben. Volgens de ontwikkelaar is het aantal meldingen van problemen de laatste paar jaar gelijk gebleven, terwijl het tempo van veranderingen flink is toegenomen. Ruimte voor verbetering is er wel. Op dit moment is de ontwikkeling gebaseerd op vertrouwen: mensen die code insturen worden geacht de kwaliteit daarvan te bewaken en waar nodig te verbeteren: 'dat is belangrijker dan het in een keer goed krijgen.' Een centraal iemand die het oplossen van bugs coördineert zou echter wel een stap voorwaarts zijn.

Reacties (32)

[Verwijderd]

De ontwikkelingfase van de kernel is nu heel anders. Twee jaar geleden was het veel meer beta. Nu is de kernel in maintainance mode. Kortom, er komen geen grote lappen nieuwe code meer bij, er worden nu bugs gefixt. Heel logisch eigelijk.

[OddesE]

Een centraal iemand die het oplossen van bugs coördineert zou echter wel een stap voorwaarts zijn.

Dat is altijd een probleem bij open Source. Een stukje erbij hacken aan de Linux kernel, da's leuk, dat doe je als hobby.. maar issue management als hobby? Aargh.

[SirBlade]

Dan moeten ze aan de bedrijven die nu coders leveren voor Linux vragen een paar managers beschikbaar te stellen en deze managers ook de macht geven die ze nodig hebben hun taak te volbrengen. Als dat groepje top-coders geen manager boven zich wil hebben, tsja, dan moeten ze niet klagen dat ze zelf manager moeten spelen.

[Gomez12]

Alhoewel je dan wel een paar principiele problemen gaat krijgen omdat linux tot nu toe altijd "free" was, hierdoor kon iedere jan boerenlul met een goed idee en goede code opgenomen worden, als je managers van bedrijven instelt ( die dus betaalt worden door bedrijven ) dan kan je wel eens zoiets krijgen dat manager a alleen de ideeen / code van bedrijf a goed vind en manager b alleen de ideeen / code van bedrijf b etc etc.
Ik zeg niet dat dit gaat gebeuren, maar om de schijn te vermijden is huidige opzet beter.

P.S. 80 % van de nieuwe code door 20 mensen ( 2 jaar geleden ) nee, dat OS model werkt echt fantastisch als iedereen eraan kan meewerken en er nog steeds maar 20 mensen het leeuwendeel verzetten... Nooit gedacht dat de verhoudingen zo zouden zijn in OS.

[Verwijderd]

Vind ik toch niet zo gek hoor. De kernel is maar een van de vele projecten binnen Linux (en de OSS werels is wel groter dan Linux). Hoeveel mensen zijn in staat om een kernel aktief te ontwikkelen en hoeveel mensen hebben daarvan de tijd en de wil ? Je moet ook nog ergens van leven. Dus veel programmeurs zullen waarschijnlijk gesponsord worden door hun werkgever die dan toch weer invloed heeft op een project.

[Gomez12]

De kernel is misschien maar een van de vele projecten binnen linux, maar imho wel de belangrijkste. En dat OSS wereld groter is dan Linux kernel weet ik, maar niet erg veel groter dan linux os. Imho is ongeveer 90% van de OSS wereld begonnen of afgeleid van een project op linux.

En linux is niets meer zonder kernel.
Dus 30 developers die (nu) 30% van de code verzorgen vind ik toch wel enigszins zorgwekkend als ik zie hoeveel commerciele distro's er zijn die afhankelijk zijn van een paar man.

[Verwijderd]

Linux is ook niets meer zonder ... de GNU C-compiler, Gnome/KDE, Apache, OpenOffice, BASH, etc.... Strip dat alles eraf en je komt op een soort extreem gebooste MS-Dos uit. Ze hebben het hier in het verhaal dan ook voornamenlijk over de Linux Kernel en niet over Linux in het algemeen (die verwaring krijgt geloof ik niemand er meer uit).

[Verwijderd]

Het zouden er wel wat meer mogen zijn maar volgens het artikel neemt het aantal mensen dus wel behoorlijk toe. Kennelijk lukt het met zo'n beperkt team toch prima om een zeer succesvol en stabiel product op te leveren.

Je stelt dat er wel meer OSS is dan Linux, maar niet zo heel veel meer. Ik denk dat je teveel projecten ziet als onderdeel van Linux. Om eens wat bekende OSS projecten te noemen die niet of niet alleen onderdeel zijn van Linux.

OpenOffice (multiplatform incl. Windows)
VLC (multiplatform incl. Windows)
KDE (Linux, BSD).
Azureus (multiplatform torrent client)
.....

[raptorix]

LOL, er zijn duizenden actieve OS projecten, dat ze minder bekend zijn (voor jou) betekend niet dat ze er niet zijn.

Om er maar paar te nomen:

-Joomla
-Apache
-PHP
-Mysql
-BSD
-Firefox
-Perl
-Python
-Subversion
-Java
-Lucene
-Ruby
-Eclipse

etc

[OddesE]

... was effe suf... mod maar -1 :-)

[Reactie gewijzigd door OddesE op 11 augustus 2024 03:11]

[Borromini]

Linux is alleen maar een kernel. Het OS heet GNU/Linux, en dat is zoals een Lego-doos: iedereen kan ermee bouwen wat hij wil.

Er is dus maar één project 'binnen Linux' - en dat is Linux zelf. Simpel, toch?

[Borromini]

Ik zie niet in waarom je me moet doorverwijzen naar Wikipedia als je het toch allemaal zo goed weet?

Linux is géén GNU project.

[OddesE]

Beweren dat Linux één project is... komop

[user109731]

P.S. 80 % van de nieuwe code door 20 mensen ( 2 jaar geleden ) nee, dat OS model werkt echt fantastisch als iedereen eraan kan meewerken en er nog steeds maar 20 mensen het leeuwendeel verzetten... Nooit gedacht dat de verhoudingen zo zouden zijn in OS.

Helemaal niet 'nog steeds'. Tegenwoordig is dat dus 30% door de top-30 man Veel van de top-contributors zijn full-time in dienst, daar kun je als amateur natuurlijk moeilijk tegenop. Bovendien is kernel development heel wat anders dan een open-source forum pakketje waar iedere tweaker aan kan sleutelen. De drempel ligt nu eenmaal een stuk hoger en daarom kun je IMHO een kernel niet vergelijken met een normaal stuk open-source software.

Ook uit het bron artikel:

In the past two years, 3,200 developers have contributed at least one patch, with half contributing two or more, one quarter contributing three or more, and so on in a "long tail" exponential curve.

Niet verkeerd. Dat zijn toch wel duizenden patches door honderden mensen, die niet in de top zitten. Zouden die patches er ook geweest zijn als de kernel niet open-source zou zijn?

[Reactie gewijzigd door user109731 op 11 augustus 2024 03:11]

[Jeanpaul145]

Het ironische is dat terwijl de hele "ik vind dit leuk dus doe ik dit" mindset prima werkt voor een kleine groep, deze "kleine groep" is uitgegroeid naar een niet-zo-kleine groep.
En terwijl het misschien niet zo goed aansluit bij de originele gedachte, is het op termijn (ff aangenomen dat m.n. Linux blijft groeien) onvermijdelijk dat er een gestructureerde organisatie ontstaat. Als dit niet gebeurt wordt het gewoon onhandelbaar, dat is nu al enigszins te merken lijkt me

[siepeltjuh]

Niet alleen nu, maar in de afgelopen 10 jaar is er zoveel verandert aan de structuur. Ik kan me nog wel wat mailts van Linus herinneren waar hij weer loopt te vloeken en te tieren. Om het feit dat een systeem niet meer toereikend is door de groei en dat hij weer meer bezig is met coordineren ten koste van het schrijven. En vele lead developers met hem (meestal met wat minder gevloek)

[Gomez12]

Helemaal niet 'nog steeds'. Tegenwoordig is dat dus 30% door de top-30 man Veel van de top-contributors zijn full-time in dienst, daar kun je als amateur natuurlijk moeilijk tegenop.

Waarbij die 30 core-man dus tegenwoordig meer het gevoel heeft manager te zijn dan programmeur, want ze moeten dus per 2 jaar 3200 codestukken van "onbekende" personen die 1 patch inleveren nakijken of dit wel compatibel is met hun code, ja dat gevoel kan ik wel enigszins begrijpen.

En toch is dit steeds het argument wat "de meeste mensen" over OS hebben dat iedereen eraan kan bijdragen, terwijl de top het "irritant" vind om al die code na te moeten kijken.

Heel simpel voorbeeld, ik heb ooit eens een OS project opgestart. Na 1 maand was ik 100% programmeur ( oftewel ik leverde alle code aan ), na 3 maanden was ik 100% code-controlleur ( oftewel ik was alleen maar aan het controleren of andermans code zich wel aan mijn api hield ). Dit isleuk als je ervan houdt, maar na 6 maanden had ik het project maar afgeblazen omdat ik er te veel vrije tijd instak in dingen die ik niet wilde doen ( code controleren )

[jms]

Google heeft al een tijdje een vacature lopen voor deze functie, er zijn alleen weinig mensen die dat ook goed kunnen en woonzaam zijn in california

http://www.google.com/sup...in/answer.py?answer=53317

[_JGC_]

Google heeft een sollicitatietraject van een halfjaar, waar de meesten halverwege uitgegooid worden. Heb zelf ook 3 maanden gesolliciteerd bij Google voor een baan in Groningen, werd ik er na 6 interviews uitgegooid omdat ik niet enthousiast genoeg zou zijn. De vacature staat nu trouwens nog open, is vorig jaar oktober online gezet. Het is niet een kwestie van geen mensen kunnen vinden, het is een kwestie van mensen willen aannemen.

[g4wx3]

Zou je niet zoiest kunnen maken in linux zoals bij firefox, dat je iets heel goed en stabiel hebt, waar je dan addons aan toevoegd (PCI /USB /PROC-ondersteuning) ?
Zo werkt alles meer in blokken, en is een blok bovendien makelijk te vervangen door een update, hoef je dus niet opnieuw de hele kernel te downloaden / compilen

[Gomez12]

Dat is bij linux te bereiken door loadable modules ( =addons )
Alleen zijn modules altijd trager dan kernel functies en voor sommige dingen heb je gewoon snelheid nodig.

In principe is bijna alles als module te laden, maar als jij een FS ( voor een interne schijf ) als module wilt laden dan wens ik u veel succes.
Het kan wel, maar het vereist gewoon extra checks.

[Onno]

In principe is bijna alles als module te laden, maar als jij een FS ( voor een interne schijf ) als module wilt laden dan wens ik u veel succes.

Dat doet zo'n beetje elk besturingssysteem anders wel hoor..

[Gomez12]

Noem eens 3 mainstream os'en waarbij het FileSystem voor een interne hdd ( dus waar ook het OS zelf op kan draaien ) als module draait?

Ik zou er geen een weten die mainstream is.

[Borromini]

Linux?

Je kan best al je bestandssystemen als modules compileren. Veel distributies doen dat ook. Natuurlijk zal je kernel dan van geen enkel bestandssysteem kunnen booten (zelfstandig), maar dat wordt dan weer opgelost via een ramdisk, die al die modules laadt voordat de kernel boot .

[Verwijderd]

Noem 3 mainstream OS's die dit doen..hmmmm
moelijk..

RedHat / Fedora / CentOS
SuSE
Mandriva
Ubuntu
Debian
enz. enz.

Zucht

[Niemand_Anders]

@KayKay:
Blijkbaar is dat wel moeilijk, want je noemt nu tig van distributies welke allemaal het OS Linux gebruiken. Had je nou Minix, Unix, Linux en BSD genoemd dat had je misschien een punt gehad.

Nogmaals een distributie is dus geen OS. Distributies van BSD zijn onder andere FreeBSD, OpenBSD en NetBSD. (Dure) Unix distributies zijn o.a. HP-UX en SCO Unix.

[Verwijderd]

Nogmaals een distributie is dus geen OS. Distributies van BSD zijn onder andere FreeBSD, OpenBSD en NetBSD. (Dure) Unix distributies zijn o.a. HP-UX en SCO Unix.

FreeBSD, OpenBSD en NetBSD zijn wel degelijk verschillende OSen, verschillende codebases, eigen ontwerp, eigen sterke en zwakke punten (een FreeBSD kernelmodule kun je bv niet in OpenBSD laden, of omgekeerd... waar er tussen bv RedHat en Ubuntu geen verschil is).
Net als HP-UX en SCO Unix overigens.
Unix is meer een familienaam van OSen, een soort standaard. Net als Windows dat is.
Windows 9x is toch een volstrekt ander OS dan Windows 2000. Verschillende kernel, andere technologie etc. Net als bovenstaande OSen.
Bij linux is de technologie overal gelijk, RedHat, Ubuntu etc gebruiken allemaal dezelfde kernel en 'world'. De naam 'distributie' zegt het al, het gaat om de manier waarop het verspreid wordt. Het is net wat anders 'ingepakt', net wat andere tooltjes, net wat andere configuraties. Maar het 'hart' van het OS is identiek. Dit is dus niet zo bij bovenstaande OSen, die zijn op eigen kernels, eigen technologie en eigen tools gebouwd, al werken ze overeenkomstig.

[Reactie gewijzigd door Verwijderd op 11 augustus 2024 03:11]

[_JGC_]

Windows en linux sowieso.

[elmuerte]

Dat is nou het idee van een micro kernel

[Little Penguin]

Aangezien Linux de mogelijkheid heeft om uitbreidingen als modules toe te voegen is dit er al...

Natuurlijk zou je ook een microkernel kunnen gaan schrijven, maar dan moet je echt vanaf nul beginnen. Dus de mogelijkheid om de Linux kernel met modules uit te breiden is op dit moment de beste optie...

[Yoozer]

Natuurlijk zou je ook een microkernel kunnen gaan schrijven, maar dan moet je echt vanaf nul beginnen

Als alle applicaties er voor aangepast moeten worden, ja - maar de microkernel zelf leeft nog - L4, Mach, QNX, en Minix 3 .