Door Anoniem: Door meidoorn: Door Anoniem: Linux-lek? Wat krijgen we nou? Open-source is toch een onneembare vesting?
Vriendelijk verzoek met een bijdrage te komen waar iedereen wat aan heeft.
Het was ook niet bedoeld als een bijdrage van mijn kant, ik probeer slechts kennis op te doen door de bijdragen van de experts op dit forum.
Het kwam op mij (niet degene die het geciteerde vriendelijke verzoek deed) eerder over als een opmerking van iemand die volstrekt geen kennis op wil doen maar die een beetje wil trollen. Je had namelijk makkelijk kunnen hebben opgemerkt dat mensen die dit soort dingen beweren vrijwel altijd worden gecorrigeerd, en ook dat ook in Linux wel degelijk regelmatig beveiligingslekken worden gerepareerd — die er dus zijn. Het zou je evenmin zijn ontgaan dat het bij alle soorten softwarelicenties af en toe voorkomt dat er een lek in de betreffende software wordt gevonden dat er al erg lang in zit. Er zijn namelijk zat bugs die nooit tot (herkenbare) problemen leiden, en zie die maar op te merken.
Door Anoniem: In combinatie met "Het probleem is sinds versie 4.11 van de Linux-kernel aanwezig, die zo'n negen jaar geleden verscheen."
En wordt nu pas gevonden, ondanks Open-Source en iedereen de broncode kon inzien...
Dit wordt altijd als voordeel gezien, maar zo zie je maar dat ondanks beter inzicht niet alles gevonden wordt.
Dat iets een voordeel is betekent niet dat het meteen zo zwart/wit ligt dat meteen alles gegarandeerd gevonden wordt. Dat niet alles gevonden wordt en het soms lang kan duren is echt geen nieuws.
In het ontstaan van dat beeld van magische perfectie lijkt de bekende uitspraak "given enough eyeballs, all bugs are shallow", uit "The Cathedral and the Bazaar" (1999) van Eric Raymond, een grote rol te hebben gespeeld.
Kennelijk laten indrukwekkend veel mensen na om als ze zoiets tegenkomen eens uit te zoeken waar het nou eigenlijk vandaan komt, om daar goed te lezen wat er nou echt staat, en om hun gezonde verstand te gebruiken. Dat is iets om wel te doen. Op de kleuterschool leer je al dat als je een verhaaltje aan elkaar doorfluistert in een kring het onderweg vervormd raakt. Om dergelijke vervormingen te herkennen en ondervangen moet je dus al die stappen van doorvertellen proberen kort te sluiten zodat je weet wat er oorspronkelijk werd gezegd. Dat volwassenen beter zijn in dingen goed doorvertellen dan kleuters betekent niet dat het effect helemaal niet meer optreedt, het blijft de moeite waard om de bron van iets op te zoeken en te kijken wat daar staat.
Het relevante stukje uit "The Cathedral and the Bazaar" (het gaat over hoe de Linux-kernel ontwikkeld wordt; vet door mij toegevoegd):
Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this:
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.
My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.'' That correction is important; we'll see how in the next section, when we examine the practice of debugging in more detail. But the key point is that both parts of the process (finding and fixing) tend to happen rapidly.
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html (ouderwets http)
Linus Torvalds zelf heeft destijds al direct aangegeven dat een bug vinden een grotere uitdaging is dan hem oplossen. Zijn commentaar maakt duidelijk dat het voordeel van "many eyeballs" primair is dat degene die een probleem snapt vaak iemand anders is dan degene die het vindt, en dat het daarom dus helpt dat veel mensen het onder ogen krijgen. Ondanks die correctie, die aangeeft dat het voordeel vooral in het oplossen en minder in het vinden van bugs zit, blijft Eric Raymond het voordeel in het geciteerde stukje aan zowel "finding and fixing" toeschrijven op een manier die je makkelijk kan lezen alsof er geen verschil is in hoe sterk dat voordeel is. Maar merk ook op dat hij in de laatste zin de woorden "tend to" gebruikt, hij zegt niet dat het een absoluut gegeven is maar dat de tendens bestaat. Het is dus niet zo zwart/wit als in de populair geworden kreet die hij ervoor bedacht heeft. Ook bij open source moet je dat soort gevleugelde kreten niet als absolute waarheden opvatten maar even verder kijken.
Dankzij die AI mogelijkheden gaat het pas een meerwaarde mogelijk hebben.
AI voegt inderdaad iets toe. Het kan fouten vinden die mensen normaal niet makkelijk onderkennen, het kan iets dat mensen zelfstandig niet kunnen (en ook een heleboel niet dat mensen juist wel kunnen). Het gaat hier om een bug die bij normaal gebruik van XFS helemaal niet tot fouten leidt, het gaat niet spontaan mis, of zo extreem zeldzaam en slecht herkenbaar dat het nooit tot reproduceerbare bugmeldingen, een herkenbaar patroon in bugmeldingen of wie weet zelfs maar tot bugmeldingen heeft geleid.
Maar dat effect is geen meerwaarde van open source, het is een meerwaarde van AI als tool om bugs mee op te sporen die je anders niet herkent. Closed source-leveranciers passen die tools ook toe, zie de stortvloed aan patches die gaande is in hun patchrondes.
Het beeld dat dit bij open source allemaal vanzelf zal gaan als die broncode maar ingezien kan worden door genoeg mensen was van begin af aan al onjuist. Dat broncode ingezien kan worden bij open source betekent niet op magische wijze dat er bij alle projecten ook daadwerkelijk veel mensen naar kijken, er zijn zat voorbeelden van waar dat vies tegenvalt, zelfs af en toe bij razend belangrijke projecten die maar door een handjevol mensen getrokken worden. Die "many eyeballs" zijn er niet volautomatisch als iets maar publiek beschikbaar is, dus. En zelfs in code die voortdurend intensief gebruikt wordt komt het soms voor dat een combinatie van waarden in de invoer die een fout triggert zo zeldzaam is dat er vele jaren overheen kunnen gaan voor het een keer daadwerkelijk fout gaat. Of de invoer die de fout triggert moet zelfs doelbewust voor die fout zijn gemaakt.
Open source, en met name vrije software, heeft wel degelijk voordelen, maar dat is geen magie, een labeltje als "open source" is geen toverspreuk die wonderlijke dingen teweegbrengt, de effecten zijn concreet verklaarbaar. Ook is concreet verklaarbaar dat het niet immuun is voor fouten en problemen, het is namelijk gewoon mensenwerk, en mensen zijn daar niet immuun voor. Met nu AI-tools die helpen om een van de zwaktes van mensenwerk te compenseren.
