Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 107, views: 19.450 •

Linux-pionier Alan Cox heeft het beheer van het tty-subsysteem laten vallen. Hij weigert nog verder bij te dragen aan de ontwikkeling na een dispuut met Linus Torvalds over de invloed van veranderingen van de tty-code op Linux-software.

Alan CoxCox is al vanaf het prille begin betrokken bij de ontwikkeling van Linux en werd lange tijd gezien als de rechterhand van Torvalds. Woensdag heeft hij echter na een flinke ruzie zijn werk aan de tty-software neergelegd. Tty is het voor Linux essentiële subsysteem dat het draaien van zowel fysieke als dynamische terminals mogelijk maakt. De invloed van veranderingen in de tty-code op de werking van Linux-programma's is groot en volgens Cox is het onvermijdelijk dat er dan af en toe iets niet meer werkt.

Linus Torvalds is het hier niet mee eens: "Dat gebruikersapplicaties kapot gaan, is simpelweg niet acceptabel. Om dan een probleem met de kernel af te schuiven op een applicatie en te claimen dat die buggy is, is niet ok, en bijna een week lang ageren tegen het herstellen is gewoon zot." De discussie ging over het kdesu-programma, dat instabiel werd na een tty-patch van Cox. Deze vond dat hij hier niets aan kon doen omdat kdesu niet goed zou zijn geprogrammeerd.

Na de opmerkingen van Linus verklaarde Cox dat hij er genoeg van had. "Als je denkt dat het probleem makkelijk te verhelpen is, maak het dan maar zelf. Veel plezier", schreef Cox op de Linux Kernel-mailinglijst. Het is nog niet bekend wie de nieuwe beheerder wordt.

Reacties (107)

Reactiefilter:-11070105+170+211+31
Altijd jammer om dit soort dingen te zien. Bij closed source gebeuren dit soort dingen natuurlijk net zo goed, maar daar zijn de discussies doorgaans veel minder openbaar. Kan me voorstellen dat de kans op dit soort problemen vergroot wordt doordat deze mensen -en- erg goed zijn in wat ze doen, -en- daar daar sterke meningen over hebben. Wie dat laatste niet heeft zal zich immers vaker schikker naar anderman's wil.

[Reactie gewijzigd door Recursio op 31 juli 2009 10:30]

Af en toe moeten er inderdaad grote wijzigingen plaats vinden in de kernel, om de in de tijd toegevoegde brij van patches te vervangen, door meer gestructureerde code.

Maar net zoals bij Windows Vista, zijn er dan inderdaad programma's die niet meer werken, waar de maker weer tijd in moeten stoppen om deze te fixen. En veel gebruikers ook gaan klagen over de nieuwe OS versie en mensen jaren wachten met updaten ....

[Reactie gewijzigd door djexplo op 31 juli 2009 10:34]

Al in het verleden is uit gelekte code van Windows duidelijk geworden dat de Windows code vol zit met hacks om bepaalde specifieke third party software producten te blijven ondersteunen omdat ze bij windows aanpassingen zo min mogelijk softwar van derden willen stukmaken.

Het is een keuze natuurlijk maar waar in linux voorheen misschine de gebruikers wat minder belangrijk waren zijn ze nu wel belangrijker aan het worden en is compatibiliteit waarbij aanpassingen geen andere software van gebruikers zal breken nu belangrijker dan vroeger.
Inderdaad. Het grootste probleem van Linux is de steeds veranderende kernel. Een applicatie, library of driver maken die aan de Linux kernel hangt is onderhoudstechnisch een ramp.
Een applicatie, library of driver maken die aan de Linux kernel hangt is onderhoudstechnisch een ramp.
Een gemiddelde library of applicatie hoort helemaal niet aan de kernel te hangen, hooguit in de vorm van 2.4.x. Tuurlijk zijn er uitzonderingen, maar doorgaans blijven de APIs in de kernel gelijk zodat functionaliteit blijft werken. Soms hangen programmeurs dingen af aan ongedocumenteerde of niet-ondersteunde functionaliteit in de API, waardoor er problemen ontstaan wanneer de API wordt herschreven of een niet-gerelateerde bug wordt gefixt. Daar heeft dan imo de programmeur van de applicatie dan meer schuld aan dan de 'verandering' in de kernel.

Daarnaast is het schrijven van een driver onvermijdelijk gekoppeld aan de rest van de kernel in die versie. Intern veranderen dingen veel regelmatiger en niet voor niks ligt een driver dan ook een niveau lager dan een applicatie. Dat is dus echt niet te vergelijken.
Soms hangen programmeurs dingen af aan ongedocumenteerde of niet-ondersteunde functionaliteit in de API
Aan gezien de kernel OSS is kun je die toch juist als volledig gedocumenteerd zien en zouden er dus geen undocumented API features in kunnen zitten ?!?!?
Gedocumenteerde features in de zin van 'deze blijven zoals ze zijn'. Als een developer iets toevoegt aan de kernel en deze niet documenteert, dan is dat simpelweg omdat het niet zeker is dat deze features zo zullen blijven. Als je deze gebruikt, en je programma stopt met werken bij een volgende update, dan is dat gewoon je eigen schuld.

We weten allemaal dat iets nooit van de eerste keer goed is, en dat je wel eens iets wil testen voor je het als stabiel verklaart. Deze ongedocumenteerde features zijn dan ook meestal experimenteel, en daarbij is het niet de bedoeling dat elke applicatie ze gaat gebruiken. (Misschien enkel testversies van bepaalde software om te zien of het beter werkt op de nieuwe manier)
OSS != documentatie, er zullen vast wel features in zitten die nog niet helemaal mainstream zjin en dus niet gedocumenteerd zijn :)

Het gebeurt inderdaad dat sommige programma's bepaalde patches van de kernel nodig hebben om te werken, als die patch door een kernel update niet meer werkt dan werkt het programma ook meteen niet meer (goed), kijk naar bijvoorbeeld bootsplash etc.
Schrijf jij weleens Linux software? Dan zou je weten dat er aardig wat zaken zijn die via via uit de kernel naar boven komen. Dan zou je weten dat de Linux kernel vrijwel niet gedocumenteerd is. Dan zou je weten dat 'dingen veel regelmatiger veranderen' neerkomt op 'je eigen drivers werken niet meer' als de kernel 8 subversies verder is.

Dat heeft Microsoft toch echt veel beter voor elkaar. Bij MS duurt het jaren (>5) voordat je echt aan de bak moet om nieuwe drivers te maken of je software aan te passen. Bij Linux ben je als je pech hebt iedere paar maanden de pineut.
Fout. Intern verandert er idd heel veel, maar de API naar userland toe is altijd vrij stabiel geweest. Als er dingen breken buiten de kernel als er iets in de kernel verandert, dan heeft de userland programmeur iets verkeerd gedaan. Als je echter in de kernel zelf gaat werken weet je van te voren dat dingen vrij snel kunnen veranderen, wat overigens een goed ding is, omdat je dan weet dat bugs snel opgelost kunnen worden, en dat de code niet volgebloat wordt met legacy (lees inferieure code) support, iets waar windows (pak een versie, hoe nieuwer, hoe erger) wel last van heeft.

Hiernaast zorgen de maintainers van drivers automatisch ervoor dat die overgezet worden naar nieuwe code als er iets relevant voor ze verandert, dat is het hele voordeel van je drivercode in de kernel krijgen.
Blijkbaar is het de 'policy' van Linus om niks aaan te passen aan de kernel dat het gedrag van user code zouu veranderen, zelfs als die user code 'buggy' is. Linus zegt namelijk in dezelfde thread:
> > Well, I thought we were expected to avoid breaking existing user space, even
> > if that were buggy etc.
>
> I don't know where you got that idea from. Avoiding breaking user space
> unneccessarily is good but if its buggy you often can't do anything about
> it.

Alan, he got that idea from me.

We don't do regressions. If user space depended on old behavior, we don't
change behavior.

Linus
Dus het lijkt er op dat Linus dezelfde filosofie hanteert als Microsoft. Maar om dit ook altijd voor elkaar te krijgen is nog niet zo makkelijk. Als je een bepaalde vulnerability moet fixen maar je komt niet om zo'n gedragsverandering heen moet je lastige keuzes gaan maken.
In deze discussie worden userspace en kernelspace door elkaar gehaald. De userspace API wordt vrijwel nooit veranderd in linux, dus applicaties blijven werken. Kernelspace wordt wel overhoop gehaald want dat is intern - drivers horen thuis in de kernel zelf en worden dan door de maintainers omgebouwd. Tja, en als je perse closed source externe drivers wil leveren aan je klanten dan heb je pech en moet je ze steeds aanpassen. Moet je ook niet willen.
En daarom is het hele process hoe een voorgestelde patch de kernel binnen komt heel erg gestroomlijnd en best lang.

Als het geen security-patch is komt hij 99% altijd eerst binnen in de huidige 'test' / 'unstable' branch. Dus de huidige kernel blijft gewoon lekker doorwerken. Als ontwikkelaar (van een populaire tool / product) hoort het er nou eenmaal bij - in mijn visie - om eens in de zoveel tijd te kijken wat de huidige unstable branch doet met je software. Tegen de tijd dat die branch bij eindgebruikers komt heb je er al lang mee kunnen testen.

Microsoft geen toch ook bergen builds van hun OS aan hun development partners, om te zorgen dat hun software lekker werkt tegen de tijd dat het OS in de winkel ligt?
Sommige mensen zien dit juist als een groot voordeel, ook onderhoudstechnisch. Drivers met name worden steeds verbeterd. Zo heeft de linux kernel zeer compacte en up to date usb code, in plaats van een moeras van jaren en jaren van backwards compatible meuk.

Maar als je een applicatie voor de lange termijn schrijft moet je natuurlijk niet direct aan de kernel gaan zitten hangen. Dan maak je gewoon gebruik van de posix interfaces en stabiele libraries. Hetzelfde geldt voor libraries, of je doet gewoon moeite om up to date te blijven.
Zo heeft de linux kernel zeer compacte en up to date usb code, in plaats van een moeras van jaren en jaren van backwards compatible meuk.
Dat klinkt wel leuk, maar hoe groot is het verschil in de praktijk met Windows? Ik heb zelden problemen met USB onder Windows terwijl ik het toch met genoeg verschillende apparaten gebruik.
Leuk en aardig, maar voor hardware fabrikanten kost iedere keer de driver aanpassen, testen en vrijgeven handen vol met geld. Dat willen fabrikanten dus niet. Er wordt vaak geroepen dat fabrikanten meer Linux drivers moeten leveren, maar ik denk dat de Linux ontwikkelaars eerst de hand eens in eigen boezem moet steken door met een vast drivermodel te gaan werken (en zich daaraan te houden) en een roadmap te maken voor de toekomst.
Nee, drivers horen thuis in de kernel - dat is linus' filosofie. Stuur je driver naar hen, zorg dat ie kwalitatief goed genoeg is om in de kernel te komen en je hebt geen probleem. Je driver wordt dan ook nog eens door de kernel community onderhouden dus het is ook goed voor jouw. Er is geen ondersteuning (stabiele ABI/API) voor proprietary drivers en die gaat er ook nooit komen.
Ik zie het probleem niet zo...
Patch voor een onderliggend systeem veroorzaakt compatibiliteitsissue met een specifieke applicatie. Herprogrammeer/patch die specifieke applicatie en het probleem is opgelost. Komen deze dependency issues niet vaker voor op Linux systemen? Wa's het probleem om ook een KDESU updateje te maken?
Met dit argument sta je aan Cox zijn zijde. Het tegenargument is dat Linux ondersteunend moet zijn en bij een upgrade volwaardige backwards compatibilty moet garanderen. Dat laatste is het moeilijkst voor de programmeur en het beste voor de gebruiker. Diezelfde gebruiker is van Cox zijn argument het dupe. Het moet gezegd worden dat programmeurs niet met alles rekening hoeven te houden, ze moeten zich namelijk ook kunnen concentreren op de toekomst en dus verbetering. Daartegen zeg ik wel weer dat gebruikers altijd het voordeel moeten hebben. Zij zijn namelijk diegenen waar de programmeur het voor doet.

Cox schaar ik op dit moment onder de hoed techneut die vaak vanuit de applicatie denkt en niet vanuit de gebruiker. Als ze dan vanuit de gebruiker denken nemen ze vaak zichzelf als referentie. Of dit volledig geldt voor Cox weet ik natuurlijk niet, het is alleen jammer dat hij vanwege de gebruiker nu zijn werk neerlegt. Hij zou beter moeten weten...
De discussie an sich gaat er meer om wat bepaalde wijzigingen aan code tot gevolg kan hebben. Die patch die is gesubmit is gedaan om te zorgen dat dingen die stuk zijn worden opgelost (dat is het hele idee van patchen), dat doe je omdat een gebruiker een defect meldt. Daarmee loop je bij complexe systemen zoals de Linux kernel echter ook het risico dat dingen op andere gebieden stuk kunnen gaan. Dat meldt een gebruiker weer (het begin van de thread en de gewraakte discussie) en de programmeur (Alan Cox) kijkt hier naar. Hij komt alleen tot de conclusie dat het volgens hem eerder in de kdesu zit en dat de kdesu verantwoordelijken het moeten fixen. Linus bemoeit zich er echter mee en brult dat Cox dingen verkeerd ziet, weigert de boel te fixen, etc. Dat escaleert tot een dusdanig niveau dat Cox zich niet meer als maintainer van de tty code beschikbaar stelt. Daarop wordt hij door velen bedankt voor zijn jarenlange inzet en harde werk aan de tty code. Dat krijg je niet als je niet vanuit de gebruikers denkt die hiermee werken. Daarbij moet je echter wel opmerken dat gebruikers die veel met tty bezig zijn niet bepaald als "onhandig" of "niet zo technisch" zijn te bestempelen. Dat is van het niveau vissen in eigen vijver (veelal ook techneuten die zelf ontwikkelen of systemen beheren). Iets wat je bij Linux sowieso al vrij snel hebt. Er zit een groot verschil tussen iemand die net weet hoe hij een programma moet opstarten en iemand die het principe van tty's en kdesu snapt en weet hoe hij een bug moet melden.

De vraag is eerder in hoeverre Linus zich er mee had moeten bemoeien en waarom dat nou weer op flamewar niveau moet gebeuren. Het was waarschijnlijk beter geweest om de kdesu en tty mensen eens gezamenlijk naar het probleem te laten kijken ipv als big boss van de Linux kernel 1 van je mensen publiekelijk uit te foeteren. Het gaat hier dus eerder om de manier waarop men met elkaar als ontwikkelaars onderling omgaat (aka het botsen van al die ego's) dan om het technische verhaal. Dat is bij Linux qua ontwikkeling nog altijd het grootste probleem. Dat ego probleem leidt helaas ook tot de nodige problemen op technisch vlak.

Jouw verhaal gaat helemaal niet over het patchen van dingen maar over functionaliteit van de software en hoe dit aan de gebruiker wordt gepresenteerd. Dat is iets heel anders dan dingen die stuk zijn repareren. Daarmee breng je Alan Cox en technici in zijn algemeenheid onnodig mee in diskrediet. Overigens heeft Alan Cox alleen zijn maintainer functie neergelegd, hij blijft nog wel aan de code werken en ook aan het probleem wat is ontstaan. Als je die hele thread op de mailinglist bekijkt zie je ook dat hij mensen nog steeds netjes helpt en code submit. Mensen bedanken 'm dan ook niet voor niets voor al dat harde werk. Ik kan je aanbevelen om vooral ook eens die thread te lezen op de mailinglist (slashdot.org heeft de links naar de betreffende artikelen in hun nieuwsitem staan), maakt veel dingen duidelijk.

Nou kun je overigens nog beargumenteren dat die patch niet in het eindresultaat had mogen komen maar dat kun je niet aan Alan Cox verwijten. Dat is nou het fundamentele probleem in de manier waarop Linux ontwikkeld wordt en waarmee bijv. Linus Torvalds met ontwikkeling om gaat. De ontwikkeling gaat namelijk op basis van web of trust waarbij men op elkaar vertrouwd. Er wordt dus simpel gezegd op elkaar vertrouwd dat wat ergens in een repository zit ook goed is. Het gaat zelfs zo ver dat Linus om die reden geen backups maakt, hij vertrouwd erop dat anderen wel een checkout hebben (zoals hij ooit eens claimde in een Google filmpje over git). Ik vind dat nogal een behoorlijk riskante keuze die daar gemaakt wordt. Het is vanwege die manier van werken ook niet raar dat patches ineens dingen stuk maken. Als je alleen maar op een ander vertrouwd en niks zelf nog eens grondig test (iedereen maakt wel eens een fout) dan loop je nou eenmaal het risico dat dingen stuk gaan.

[Reactie gewijzigd door ppl op 31 juli 2009 12:19]

Goed verhaal, dit is tenminste een beargumenteerde manier van het brengen van het nieuws, het wordt dus alweer groter gemaakt dan het is. Alleen wil ik nog even wat zeggen over de laatste alinea.

De snelheid van de ontwikkeling is sinds 2.6 flink omhoog gegaan, ik denk dat dit komt door dit web of trust. Doordat de kwaliteit van de mensen in dit web dermate hoog is kan er m.i. wel mee gewerkt worden. Als je het anders zou doen moet er iedere keer zeer uitgebreid getest worden voordat er iets uitkomt. Terwijl de praktijk misschien wel de beste plek is om te testen. En we hebben in alle laatste kernel releases geen schrikbarende bugs gehad zodat helemaal niets meer werkte. Dus blijkbaar werkt de methode! En we hebben allerlei fancy zaken in de kernel, het is tegenwoordig lastig voor andere OS'sen om de snelheid van 1337 features in de Linux kernel bij te benen.
Let wel, dat ook ik als techneut die begrijpt wat een tty is mijn kernel wil kunnen upgraden zonder dat mijn systeem dan instabiel wordt. Als je toe gaat laten is het einde zoek, dan krijg je versies van software die alleen met specifieke kernels werken. Ik zit aan de zijde van Torvalds, het is niet acceptabel dat kernels niet compatibel met oudere versies zijn.
Het mes snijdt aan twee kanten: er zit een bug in tty waar gebruikers last van hebben en die opgelost moet worden. Die oplossing is er maar maakt kdesu weer stuk waar gebruikers ook last van hebben. Wat er nu gebeurd is dat beide partijen argumenten naar voren brengen om te pleiten voor het een. Dat is allemaal dom tijdsverlies en er is geen enkele gebruiker die daar baat aan heeft. Het probleem zit ergens tussen tty en kdesu waardoor de enige logische conclusie is dat je beide teams eens ff goed naar de problematiek laat kijken.

Als Torvalds echt gebruikers voor ogen heeft zou hij de huidige ontwikkelmethodiek niet hanteren maar het aanpassen door diverse checks in te bouwen. Het is nogal onacceptabel dat patches zomaar toegevoegd kunnen worden op basis van vertrouwen. Vertrouwen is prima maar iedereen kan fouten maken dus testen is cruciaal. Dan was de gebruiker nu niet met een impasse opgezadeld en had de boel achter de schermen opgelost kunnen worden zonder de gebruiker te lopen irriteren. Het maakt dus eigenlijk niet uit wie van de twee op technisch vlak gelijk heeft, het gaat om de manier waarop het allemaal weer eens wordt uitgevoerd.

Dat is namelijk het grote probleem van het alleen maar hanteren van zo'n web of trust. Zoals niekniek al terecht opmerkt zit er echter ook wel een voordeel aan: ontwikkelen kan daardoor wat sneller verlopen. Het aparte is dat een project als OpenBSD dat echter ook kan met code die goed in elkaar steekt en welke goed getest is. Je kunt dus wel degelijk snel ontwikkelen en goede code opleveren. De vraag is alleen of die web of trust die ze nu gebruiken daar wel het juiste gereedschap voor is.
Nochtans loopt OpenBSD driver wise toch wel wat achter op de Linux kernel. Tenminste zover ik weet werkt er toch meer op linux dan een BSD.
Het probleem zit ergens tussen tty en kdesu waardoor de enige logische conclusie is dat je beide teams eens ff goed naar de problematiek laat kijken.
Je maakt het iets simpeler dan het helaas is. Kdesu gebruikt gewoon de daarvoor bedoelde, gedocumenteerde API functies. Maar een functie staat niet op zichzelf. Je roept er meerdere aan, in bepaalde volgorde en met bepaalde argumenten, waardoor je het gewenste resultaat krijgt. De patch verandert op subtiele wijze het gedrag bij de specifieke combinatie van aanroepen die Kdesu doet.

Die combinatie van aanroepen zou je kunnen veranderen door Kdesu aan te passen. Echter, elke programmeur zou deze combinatie van aanroepen kunnen gebruiken. En aangezien Kdesu ze nuttig vindt is er grote kans dat ook andere minder bekende programma's dergelijke code bevatten. De combinatie van aanroepen heeft altijd gewerkt, dus is het raar als dat ineens niet meer het geval is. Het aantal programma's dat aangepast zou moeten worden is dus minstens één (kdesu), maar het zouden er ook honderden of zelfs duizenden kunnen blijken te zijn. Voordat je zoiets doet moet je wel behoorlijk hard kunnen maken dat de combinatie van aanroepen die je breekt zeker als 'buggy' omschreven kan worden, dus dat je als programmeur nooit had mogen verwachten dat ze zouden werken. Blijkbaar vindt Linus (en meerdere mensen in de thread) dat die combinatie wél gewoon zou moeten werken.
Volgens mij legt Cox z'n werk neer omdat ie zich door Linus geschoffeerd voelt en niet zozeer om het verschil van inzicht an sich. Laten we niet vergeten dat Linus helemaal niet zo'n makkelijk figuur is en dat een belangrijke kernel-ontwikkelaar en public 'zot' noemen niet echt netjes is.

Je klassieke instelling 'gebruikerservaring / backwards compability voor alles' is een zeer belangrijk basisprincipe, maar in de praktijk moeten er soms offers gebracht worden om vooruitgang mogelijk te maken. Volgens jou redenering zou een eventuele bug niet opgelost mogen worden als daar de backwards-compatibility mee verloren gaat.

Dat Linus dat principe aanhangt (de belangen van de gebruikers verdedigen) is gezien zijn rol de enige juiste, maar als Cox gelijk heeft dat KSEDU zich simpelweg niet aan de regels/API houdt (en dus eigenlijk buggy is), dan zou er toch voor de technisch correcte oplossing gekozen moeten worden omdat dat op de lange termijn de belangen van Linux en haar gebruikers juist het beste vertegenwoordigt.
In dit geval zijn de "gebruikers" die de dupe zijn de applicatie programmeurs. Zij moeten hun software herschrijven daar waar de kernel API veranderde door het werk van Cox.
De gewone gebruikers zijn ook de dupe; zij moeten wachten met upgraden van de kernel totdat hun apps gefixed zijn en daarna ook al hun apps die affeced zijn updaten.
Als ze dan vanuit de gebruiker denken nemen ze vaak zichzelf als referentie.
zo beschrijf je dus ook 99% van de tweakers..
het zal niet zo zeer over deze patch in het bijzonder zijn gegaan maar over een filosofisch verschil in hoe deze 2 mensen denken dat kernel updates geregeld moeten worden in de toekomst.

moet de kernel worden aangepast aan 3de party software, of moet 3de party software aangepast worden aan gebruikers.

nu is het 1 programma wat het niet doet helemaal goed doet, straks zijn het er 10 en de volgende keer 100 bij wijze van.

van de andere kant, met elke 3de party patch in de kernel kan het de vooruitgang tegenhouden worden, of word er in de kernel een workaround geprogrammeerd voor dat programma, maar daar word de kernel steeds groter van. (en het kost tijd voor de kernel programmeurs om 'fouten' van 3de party developers op te lossen)

beide opties zijn niet ideaal
Bij closed-source kan dit niet gebeuren omdat een ontwikkelaar een contract heeft met zijn werkgever, en dus ook een opzegtermijn heeft. Je kan dus niet van de ene op de andere dag een hoofdprogrammeur kwijtraken.

Dit doet me denken aan dhr Reiser die zijn vrouw vermoordde, en als gevolg hiervan was opeens een fs niet meer in ontwikkeling.

Dit geeft iig de zwakte van open source aan. Of iig open source waar mensen aan werken zonder contract.
Beetje naief. Als een ontwikkelaar er geen zin meer in heeft, dan is het gewoon einde oefening. Closed source of open source, contract of geen contract, dat maakt niks uit.
Ach, als een werknemer weigert te werken, kan die dus een lawsuit verwachten. Dus normaal gesproken zal iemand met een contract niet zomaar weglopen.
Normaal gesproken kan je niet zomaar weglopen of wegblijven. Maar als iemand een probleem heeft in de normale dagelijkse 'niet perse open source' wereld dan zie je al snel dat ze echt geen motivatie meer hebben om iets te doen of zich zelfs ziek melden.

Wat is dan erger? iemand die de vrijheid heeft en neemt om te zeggen "dit werkt niet meer zo, tot ziens" of het dagelijkse model "dit werkt niet meer zo, maar ik moet blijven hangen contractueel"
Ontwikkelaar stapt voor de intercity bij de onbewaakte overweg.
Ontwikkelaar neemt een overdosis medicatie.
Ontwikkelaar krijgt een hartstilstand.
Ontwikkelaar wordt van z'n sokken gereden.
Ontwikkelaar wordt ziek.
Ontwikkelaar vindt het best en vertrekt met de noorderzon.
Ontwikkelaar meldt zich ziek wegens arbeidsconflict met de baas.

Om maar even een aantal dingen te noemen waardoor je een ontwikkelaar net zo hard kwijt kunt raken als bij open source. Dat soort zaken kunnen altijd spelen eveneens als diverse andere zaken. Wat echter wel zo is, is dat je bij closed source eerder aan een contract vast zit en niet zomaar weg kunt als je ontslag zou nemen. Bij een open source project als de Linux kernel zeg je gewoon aju paraplu en daarmee is de kous dan af.

Dat van Reiser is een slecht voorbeeld omdat je daar nou juist een bedrijf te pakken hebt ;) De man had zijn eigen bedrijf en was de hoofdontwikkelaar van het filesystem (het heet niet voor niets ReiserFS). Dat moet je zien als wanneer bij voetbal je team afhankelijk is van je beste speler of bij de Formule 1 je sterk afhankelijk bent van een bepaalde rijder (bijv. een Schumacher). Op moment dat die mensen weg gaan valt alles ineens stil. Je zag exact hetzelfde gebeuren bij de LPF toen hun frontman werd vermoord. Door alles aan 1 persoon op te hangen maak je een single point of failure. Als die persoon om wat voor reden dan ook wegvalt dan valt het hele project gewoon compleet stil. Dat is absoluut geen zwakte van open source omdat open source er helemaal niets mee te maken heeft. Dat is een zwakte van het systeem waarbij je alles van 1 persoon laat af hangen.

Kortom: wat je zegt klopt eigenlijk totaal niet. Bij zowel closed source als open source kun je een programmeur van de ene op de andere dag kwijt raken en kan alles tot stilstand komen. Waarom? Omdat dat helemaal niets te maken heeft met het feit of de broncode nou openbaar is of niet.

[Reactie gewijzigd door ppl op 31 juli 2009 23:35]

Bij closed-source kan dit niet gebeuren omdat een ontwikkelaar een contract heeft met zijn werkgever, en dus ook een opzegtermijn heeft.
Wanneer ego's botsen en er een onwerkbare situatie ontstaat, zie bovenstaand artikel, wil je de betrokken persoon/personen z.s.m. uit het project hebben. Ook bij closed source, dat maakt echt geen verschil. En contract of geen contract, rotte appels en moddergevechten kun je niet gebruiken binnen een project.

Beetje vreemd om hier de verspreidingsvorm (open versus closed) als oorzaak aan te gaan wijzen. Het enige verschil is dat er hier publiekelijk met modder wordt gegooid, bij closed source zal het moddergooien makelijker binnen de kantoormuren blijven.
Pffffff.... kindjes :'). Wel heeeel erg herkenbaar (ontwikkelaars die star vast blijven houden aan hun visie/religie, komt bij mij op het werk ook vaak voor).

Maar dit soort ruzies is slecht voor het imago van Linux als besturingssysteem/kernel, vooral omdat ze in het openbaar uitgevochten worden.

Wel neig ik naar de visie van Torvalds. Als je zo'n belangrijk subsysteem als TTY wilt patchen, dan moet je verrekte goed uitkijken in hoeverre dat userland-software stuk kan maken. Zelfs ALS kdesu niet goed geprogrammeerd zou zijn (niet helemaal volgens de interfacing richtlijnen met TTY), dan nog zou Alan Cox eens kritisch moeten kijken of die patch daadwerkelijk noodzakelijk is voor de stabiliteit van het subsysteem en eventueel van te voren aankondigen dat in kernel versie X.y.z of X.y een bepaalde patch doorgevoerd zal worden. Dan kan kdesu en andere software hier rekening mee houden.
Maar dit soort ruzies is slecht voor het imago van Linux als besturingssysteem/kernel, vooral omdat ze in het openbaar uitgevochten worden.
Tja, bij Open Source is alles open, he :+
Nee ik vind het juist goed. Alan en Linus zijn beiden zeer gepassioneerder programmeurs. Dat je dan af en toe botst hoort er gewoon bij. Er zijn wel meer heftige discussies geweest tussen kernel ontwikkelaars. En Linus is over het algemeen niet subtiel als hij kritiek ergens over heeft. Maar eerlijk is eerlijk zonder een dictator als Linus zou Linux echt niet zover zijn gekomen als het nu is.
Dat is niet waar. Er zijn ook succesvolle open source projecten die zonder dictatorschap werken,, zoals Apache of FreeBSD.
Maar dit soort ruzies is slecht voor het imago van Linux als besturingssysteem/kernel, vooral omdat ze in het openbaar uitgevochten worden.
Als je het over imago hebt: Die website LKML kan écht niet meer anno 2009. :X Ik weet wel dat het bedoeld is voor de ontwikkelaars, maar dat zij via zo'n site goed kunnen communiceren en werken spreekt boekdelen.
Het is volgens mij een mailinglist, dus ze hebben het waarschijnlijk via hun favoriete email client gedaan. De link is gewoon het mailinglist archief.
Dat doen ze dan ook niet via die site. De site is slechts een weergave van de mailing list. Dingen uitvechten doen ze dus per e-mail.
Naast de opmerkingen van madman2003 en Qione lijkt het me handiger om een simpele site te hebben zonder toeters en bellen om met je werk bezig te zijn ipv een fancy fancy ajax interface, omdat de lay out mooi moet zijn.

Heb je kernel.org wel eens gezien? Als je de maillijst al een simpel iets vind moet je die maar eens bekijken. De site is zeer doel gericht en effectief ingedeelt. :)
Principiele verandering versus Pragmatisme.
Ja, altijd moeilijk.
Als je een principiele verandering doorvoert krijg je brokken, tenzij "alles" meeverandert (zoals bij MacOS -> OS X). Anders moet je constant ondersteuning inbouwen voor legacy spul (zoals bij Windows).
Dubbel gevoel... vanuit het perspectief van de eindgebruiker en developer is het natuurlijk te verkopen dat je software ineens niet meer werkt. Niet dat het om commerciele insteek gaat uiteraard, maar de simpele gebruiker loopt wellicht weg uit de community als de software ineens niet meer werkt.

Echter hebben dit soort major overhauls in het verleden op de langer termijn goed gewerkt in commerciele initiatieven.... in hoeverre dit toepasbaar is op linux en de community is uiteraard maar de vraag. Een kernel change die software onbruikbaar maakt kan vanuit de gebruikers en software ontwikkelaars natuurlijk gewoon totaal averechts uitwerken.

Lijkt me ook een behoorlijke uitdaging voor de distributiegroepen.
In het geval van kdesu is het blijkbaar toeval dat het werkt met de oude code. Als je je niet aan de regels houdt breken je applicaties gewoon.
Zie bijvoorbeeld die null pointer dereference bug in de kernel van laatst. De code in de kernel was gewoon ongeldige C code die in userspace direct zou crashen, maar omdat de kernel niet crasht op die instructies maar het gewoon niet uitvoert werkte het. Vervolgens optimaliseert de compiler een check weg die onnodig lijkt en heb je een DoS of root exploit te pakken. Is het dan de schuld van de compiler die in nieuwere versies dat soort dingen wegoptimaliseert?
Daar ging de hele discussie dan ook om. Technisch gezien hoort een programma zich aan de regels te houden en dan ontstaan er geen problemen. Echter door de ogen van een gebruiker is het niet aanvaardbaar en elk gebruiksvriendelijk OS moet dus soms principes laten gaan om 3rd party support toch in orde te krijgen.
Userspace apps die zich niet aan de specs houden zijn te patchen. Kdesu is gewoon te patchen. Wat wel een punt is, is dat emacs blijkbaar iets doet wat binnen verwachting ligt en ook breekt. Zoiets zou niet mogen gebeuren, en dat is ook iets waar Alan mee bezig was voordat ie het werk neerlegde.
Verder is het de taak van de distributeurs dat dingen blijven werken. Als de kernel veranderingen krijgt waardoor bepaalde buggy userspace apps niet meer werken, moet de distributie zorgen dat of die kernel niet in de distributie komt, of de buggy userspace app gefixt wordt.
Ik vroeg me al af wat Linus met zijn kernel nu met de gebruikers wil ! Natuurlijk moeten grote beslissingen tussen partijen onderling overlegd worden. Maar zoiets als dit zie ik nu als een klein probleem omdat alleen kdsu afhankelijk is. En dat mis ik nu ook in GNU/Linux de afhankelijkheden zijn niet overzichtelijk te bekijken. Beslissingen in code die veel afhankelijkheden hebben moet beter over gecommuniceerd worden. En als taak van de distributie is het de taak om alles zo mooi naadloos op elkaar aan te laten sluiten.
Daarom is Ubuntu ook zo populair geworden het wordt vanuit gebruikers oogpunt bekeken en daar horen dit soort dingen ook precies thuis zoals je al aan gegeeft. Mijn mening is dat de programmeurs denken teveel in enen en nullen. Maar denken niet na over de praktijk, er moeten gewoon afwegingen gemaakt worden soms als het probleem te overzien is moet gewoon de kernel aangepast worden. En als er dan grotere problemen voordoen moet er door de kernel om heen gewerkt worden. Kortom er moeten afwegingen gemaakt worden technisch goed en gebruiksvriendelijk goed, het kan nooit het een of het ander zijn zoals Linus aan gegeeft.

Wij zijn mensen geen computer !
Iedereen heeft wel es een slecht dagje. Spijtig voor Cox dat het publiek gebeurde en hij een figuur is waar mensen aandacht naar hebben.

Een schouderklopje had misschien wonderen gedaan :)
Ik ben het eens met Linus visie. Stabiliteit is momenteel belangrijker dan extra functionaliteit voor een stabiel OS.

Ik hoop wel dat er weer een experimentele kernel gebruikt gaat worden 2.7.* daar kunnen de veranderingen die Alan wil doorvoeren wel geïmplementeerd worden.

Tot kernel 2.6.* bestond er altijd een instable kernel die een oneven nummer had.

Jammer dat Alan stopt.
Nee ik vind van niet. Door continue vast te houden aan het verleden ga je de innovatie afremmen omdat je altijd die balast meeneemt. Als het idd waar is dat kdesu het enige grote programma is dat last heeft gehad van die patch dan moet men zich idd ook de vraag durven stellen ofdat kdesu wel goed geprogrammeerd is en niet bij elkaar is gehacked waardoor het op een incorrecte manier communiceert met tty.
Vraag is of innovatie nu het hoofddoel nog is van linux of dat linux als hoofddoel heeft een brede groep linux gebruikers te ondersteunen.
Je hoeft helemaal niet aan het verleden vast te houden. Je kunt ook zoals ik al zei de experimentele kernel in het leven roepen. Dat is ook ideaal voor de mensen die graag experimenteren en willen blijven innoveren.

Voorheen werd deze experimentele kernel uiteindelijk de stabiele kernel.
ofdat kdesu wel goed geprogrammeerd is en niet bij elkaar is gehacked waardoor het op een incorrecte manier communiceert met tty.
Het kan best zo zijn dat kdesu niet op de juiste manier geprogrammeerd is. Kdesu kan en zal snel aangepast zijn.

Maar stel dat een commercieel pakket dit probleem zou hebben en je zou halsstarig vasthouden aan je change dan zul je gegarandeerd klanten verliezen c.q. bedrijven die Linux gebruiken.

Een bedrijf heeft liever een stabiel systeem dan een systeem waarvan je niet weet of het na een update nog werkt.
Dit klinkt niet als een verhaal stabiliteit, maar meer 'backwards compatibiliteit'. Software eveolueert, en als besturingssoftware dat doet, kan het meer impact hebben.

We weten allemaal ondertussen wel hoe groot de 'ouwe printer' driver library is die bij Windows (en zelfs W7) wordt bijgeleverd, en wat voor impact alle ondersteuning kan hebben op software, op den duur moet je laag op laag op laag gaan bouwen totdat je een stuk bloatware hebt.

Je moet backwards compatibility soms laten varen, en als er dan een programma is wat niet meer werkt, dan kun je grijpen naar virtualisatie van een oude versie van het OS, of, je kunt het programma updaten. Anders laat je anno 2009 pas 16 bit support los, en laad je nog steeds een vage driver in bij je boot die DOS-boxes (die al ge-emuleerd worden) laat denken dat die USB printer werkelijk een LPT printer is.
Het feit is dat Microsoft erg conservatief en weinig innoverend is.

Ze hebben nog steeds de grootste klantenbase. Er zijn erg weinig klanten die het Microsoft aanrekenen dat ze nog steeds geen journeling file system hebben (WinFS) nog geen WinFS uitleveren dat ze als jaren beloven.

Het de vraag wat het beste is innovatie of behoudendheid het belangrijkste is. Als je naar Microsoft kijkt lijkt hun manier het meeste op te leveren.

Ik ben heel erg voor innovatie (geef mij maar een experimentele kernel) maar ook voor markt acceptatie van Linux.

[Reactie gewijzigd door worldcitizen op 31 juli 2009 13:09]

NTFS is al jaren Microsoft's journalling filesystem. WinFS zal een uitbereiding worden op NTFS wat het mogelijk maakt bestanden niet alleen in directories in te delen/doorzoekbaar te maken maar ook op metadata.
WinFS zal een uitbereiding worden
WinFS is allang niet meer aan de orde.
Het help concept wordt allang niet meer ontwikkeld en is vooledig geschrapt
Het was ook veel te riskant met een database over het filesystem heen.
Je creert extra points of failure met je data.
De kennis is overgeheveld naar het ADO.net team.
NTFS doet toch echt wel aan journaling hoor... dat zou ook wel heel erg zijn als ze dat nog niet hadden :)
Ik kan me eigenlijk wel in Alan Cox zijn visie vinden. Stel even, voor de discussie, dat Alan gelijk heeft en kdesu inderdaad op onjuiste wijze gebruik maakt van tty.

Misschien denk ik wat simplistisch hier, maar dit doet me denken aan Microsoft. Als je innovatie aan je kernel tegen gaat houden omdat clientsoftware daar mogelijk niet mee overweg kan kom je al gauw in de ellende die MS ook gehad heeft met zijn besturingssystemen. Het alsmaar groter wordende probleem om 'oude' software/drivers te blijven ondersteunen, dat uiteindelijk leidt tot een niet te onderhouden kernel/drivermodel wat niet vooruit komt.
MS heeft dat bij de introductie van Vista eindelijk eens laten varen zodat ze weer eens een stap konden maken en m.i. probeert Alan al deze ellende voor te zijn door gewoon niet rekening te houden met eventuele fouten in clientsoftware. Laat die programmeurs hun eigen boontjes maar doppen.

Dit is overigens géén uitnodiging tot yet another MS vs. Linux-discussie, maar gewoon een vergelijkbare situatie die mij in gedachten schoot. :)
Wanneer is het fixen van een 'bug' het tegenhouden van innovatie :?

De man maakt een patch in een essentiele stuk functionaliteit. Daarbij zou je zeker ervoor moeten zorgen dat de rest gewoon blijft werken! Maak die wijziging maar in een versie waarvan je altijd hebt aangegeven dat er drastische wijzigingen in komen te zitten.
Volgens mij begrijp je het artikel, de situatie, of mij niet of niet volledig.

Hij maakt inderdaad een patch voor een essentieel stuk functionaliteit. Daarbij heeft hij er waarschijnlijk voor gezorgd dat alles wat bij de kernel hoort, gewoon blijft werken (sterker nog, dat weet ik wel zeker). :)
Waar het mij om gaat is dat hij nu die patch niet kan/mag doen omdat een third party stuk software, waar Alan helemaal niets mee te maken heeft én dat onjuist gebruik maakt van tty, niet met die patch overweg kan.
aangezien het maar 1 programma is dat niet meer werkt kun je je natuurlijk afvragen of die wijziging wel zo drastische was, en waar de fout dat ligt.

en deze patch is ook niet in de stable kernel terecht gekomen.

[Reactie gewijzigd door Countess op 31 juli 2009 12:22]

Als je zo denkt, stel je dan voor dat ze deze software ondersteunen. Heel snel ga je een kettingreactie van bedrijven krijgen die willen dat hun software ondersteund wordt. Het is beter om zulke zaken te voorkomen dan te genezen :)
Ik kan me eigenlijk wel in Alan Cox zijn visie vinden. Stel even, voor de discussie, dat Alan gelijk heeft en kdesu inderdaad op onjuiste wijze gebruik maakt van tty.
Stel dat het SAP of Oracle is dat niet meer werkt. Commercieel is dit niet te verkroppen. Linux is ondertussen een commercieel OS geworden. Er zijn steeds meer bedrijven die hun boterham met Linux verdienen.
Tja, stel dat vliegtuigen uit de lucht vallen. We kunnen wel over allerlei situaties fantaseren, ik heb het echter over déze situatie.

En dan nog; hoe ver moet je gaan om backwards compatibility te blijven garanderen voor faulty software? Ik zou zeggen, gewoon de patch doen en laat de klanten hun software op hun beurt ook maar patchen als ze meewillen naar de nieuwe kernelversie. Ja, dat kost geld. Ja, dat is niet leuk. Maar m.i. is stilstand erger. En als je dat soort dingen van tevoren communiceert, is er niets aan de hand.

[Reactie gewijzigd door Cloud op 31 juli 2009 12:07]

Je update je Oracle of SAP doos ook niet zo snel denk ik. Uiteindelijk is het nogal een storm-in-een-glas-situatie omdat het patchen van kdesu ook prima mogelijk is. Het is gewoon een beetje uit de hand gelopen zoals wel vaker.
Het is moeilijk te beoordelen. Als kdesu (simpel gezegd het venster om je wachtwoord in te voeren als je in KDE administratorrechten nodig hebt) daadwerkelijk slecht geschreven is, dan moet dat in ieder geval worden opgelost. Uiteindelijk zou de tty-patch pas moeten worden gemerged als kdesu de boel gefixt heeft. Met KDE heb je wel zo'n 35-40% van de Linux desktopmarkt te pakken, dat zijn enorm veel gebruikers.
Er is natuurlijk ook gewoon de mogelijkheid om je kernel pas te upgraden zodra je een kdesu app heeft die hier bij aansluit. Zolang je patch niet gemerged is zullen de kdesu ontwikkelaars ook geen reden hebben om hun app aan te passen.
Gaat niet helemaal op omdat kdesu niet distro gebonden is en dus apart ontwikkelt wordt (net zoals bijna elke app) dus het team van kdesu zouden bij elke kernel release gewoon moeten testen of het nog werkt en zo nodig fixes aanbrengen, het is aan de distro maintainers om de distro's up to date te houden en de zeuj in de repo's te mikken.

En dan nog, ook al werkt het programma dan een poos niet, kom op zeg ... wat is er mis met 'su' en een terminal? We moeten niet te verwend worden of niet dan? :P

[Reactie gewijzigd door Ventieldopje op 31 juli 2009 11:31]

su gaat je bij KDE4 niet helpen, als je als andere user een KDE applicatie wilt opstarten.
en waarom niet? -- ok, Phas0r bedoelt waarschijnlijk sudo, but still.

[Reactie gewijzigd door psyBSD op 31 juli 2009 13:32]

Maakt niet uit of hij sudo of su bedoelt; wil je een kde4 programma opstarten als andere user, dien je kdesu te gebruiken. Andere smaken werken i.i.g. niet onder Fedora, geen idee waarom niet. Er wordt geen foutmelding gegeven dus kan best zijn dat het een foutje is omdat er bv. enkele omgevings variablen niet worden doorgegeven.

Weet wel dat kdesu o.a. bedacht is voor omgevingen waar geen su/sudo beschikbaar is (bv windows).
Wat kan je dan met een kdesu op een Windows 8)7
als linux een kans wil maken op een flink groter marketaandeel dan zal het mogelijk moeten gaan worden om nagenoeg alles via de GUI te regelen en in te stellen.
dus wat dat betreft denk ik zeker dat het belangrijk is om kdesu werkend te houden (via een kernel patch of een kdesu patch is even de vraag)
Een kernel patch dus.

Onderdeel van het conflict is dat er al een patch was! Dat AC zich hier niets van aantrok/ deed alsof hij van niets wist en een (fake) oplossing koos die in de ogen van Torvalds inferieur was.
Linus heeft helemaal gelijk vind ik.

Stabiliteit gaat voor alles. of het nu linux windows mac is dat maakt niets uit.
80% van de programma die vast lopen onder windows komt ook door fouten in de software. draai maar eens een systeem met alleen microsoft software en dan zal je zien dat deze maar heel zelden problemen geeft.
Voor linux is het niet anders, programmeurs moeten beter communicatie hebben met de developers en er moeten gewoon betere en makkelijkere richtlijnen komen, dan pas kan je goed werken aan een stabiel systeem.

Communicatie is vaak het probleem, .. het is er te vaak niet.

zo zie je nu nog steeds dat er zat mensen onder windows b.v c:\program files had in de code zet ipv %programdir% om maar een klein voorbeeldje te geven.

Alan heeft zich betreffende dit onderwerp gewoon wat kinderachtig opgesteld.
maar jij vind het dus de taak van kernel-developers om alle fouten van 3de party software op te lossen via een kernel patch? want dat is wel waar het op neer gaat komen.

en dat lijkt me nogal een heel tijdrovende klus, tijd die die ontwikkelaars in meer innovatie hadden kunnen steken.
en daarbij word de kernel er steeds groter en groter van.

dus om te zeggen dat alan zich hier kinderachtig opstelt is zeker veel en veel te kort door de bocht.
beide standpunten brengen grote voordelen, maar even zo belangrijk grote nadelen met zich mee.
en ik zie geen standpunt dat duidelijk beter of slechter is als het andere.
Voor zover ik het begreep zat de fout in de kernel ! En werd er niet goed gecommuniceerd tussen kdesu en de kernel. Kdesu ging uit van iets en dat werkte toevallig maar was niet goed volgens de richtlijnen en op hardware niveau leidde dit gewoon tot problemen *zie usb naar serieel chip pl2103 *.

Op dit item kan niet meer gereageerd worden.



Populair: Tablets Websites en communities Smartphones Beheer en beveiliging Google Laptops Apple Sony Games Politiek en recht

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013