Cookies op Tweakers

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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 110 reacties

Het gebruik van vrije software is essentieel om surveillance tegen te gaan. Dat stelt Richard Stallman, de oprichter van de Free Software Foundation en GNU, in een interview met Tweakers. "Vrije software zorgt ervoor dat je apparaat je gedrag niet meer verraadt."

Richard Stallman"Als je niet-vrije software gebruikt ben je kwetsbaar voor spionage via je eigen computer.", aldus Stallman tegenover Tweakers op de CCC-beveiligingsconferentie in Hamburg. "Iedereen kan een aangepaste versie van vrije software maken en zelf bepalen wat daar inzit. Inderdaad, veel mensen kunnen geen broncode lezen en voeren dus geen wijzigingen door in software. Maar het zorgt wel voor een soort collectieve controle. Er hoeft maar één iemand malafide functionaliteit aan te treffen en een nieuwe versie te publiceren."

Stallman is de oprichter van de Free Software Foundation en GNU, en is groot voorstander van vrije software, waarvan de broncode beschikbaar is en die vrijelijk kan worden aangepast. "Propriëtaire software onderwerpt de gebruiker", stelt Stallman, verwijzend naar software waarvan de broncode niet vrij is, zoals Windows. "Omdat de ontwikkelaars gebruikers in hun macht hebben, worden ze verleid tot het inbouwen van backdoors." Daarbij wijst hij onder meer naar de kill switch die Apple en Google hebben ingebouwd in hun mobiele besturingssystemen en die de bedrijven op afstand apps laat wissen van telefoons, evenals vergelijkbare functionaliteit die in Windows zou zitten.

De voorvechter van vrije software erkent dat ook software waarvan de broncode vrijelijk kan worden bekeken en bewerkt beveiligingsproblemen bevat. "Maar ontwikkelaars van vrije software voelen geen drang om malafide functionaliteit toe te voegen. Ontwikkelaars van propriëtaire software doen dat continu! Ze weten dat gebruikers het toch niet kunnen verwijderen. Het maakt ze niet uit. Gebruikers van propriëtaire software zijn sitting ducks." Er bestaat wel kwalitatief hoogwaardige propriëtaire software, erkent Stallman. "Maar het is onethisch en kwaadaardig. Het is een bedreiging voor vrijheid."

Tegelijkertijd is het gebruik van vrije software niet genoeg. "Ook andere vormen van surveillance moeten worden ingeperkt, zoals de bewaarplicht", vindt Stallman. "Vrije software biedt geen waterdichte beveiliging, maar het is tenminste beveiliging." Volgens Stallman is er politiek nog te weinig veranderd na de Snowden-onthullingen, die anderhalf jaar geleden begonnen. "Het is niet genoeg om beperkingen te stellen aan wat de overheid mag doen met verzamelde gegevens", zegt Stallman. "We moeten het onmogelijk maken om vast te leggen waar iedereen heen gaat en met wie iedereen praat."

Dat is niet alleen belangrijk voor mensen die het niet fijn vinden dat ze worden gevolgd, maar vooral ook om te voorkomen dat klokkenluiders kunnen worden opgepakt, stelt Stallman. "We moeten het onmogelijk maken om klokkenluiders te identificeren als we daadwerkelijk een democratie willen hebben. Een democratie kan niet zonder klokkenluiders."

Stallman benadrukt het verschil tussen vrije en opensource-software. Beide stempels worden vaak op dezelfde software gedrukt, maar waar 'open source' enkel betekent dat de broncode van software wordt gepubliceerd, betekent het stempel 'vrije software' dat de software ook vrijelijk kan en mag worden aangepast en opnieuw gedistribueerd.

Stallman gebruikt geen telefoon. "Het is in theorie mogelijk om een vrije telefoon te maken, maar in de praktijk niet", stelt Stallman. "Het modem van telefoons kan geen vrije software draaien, omdat de specificaties niet bekend zijn en een certificaat van de fabrikant nodig is om te software te kunnen flashen." Daardoor kan alleen de application processor van de telefoon vrije software draaien. "Maar backdoors in het modem zorgen ervoor dat weer niet-vrije software naar de applicatieprocessor kan worden geflasht", beweert Stallman.

Android is volgens Stallman sowieso niet vrij. De mobiele versie van Ubuntu en Replicant, een vrije kloon van Android, zijn volgens Stallman geen oplossing. "Die draaien alleen op de applicatieprocessor en zijn dus niet volledig vrij." Ubuntu Phone heeft bovendien niet-vrije drivers aan boord, tekent Stallman aan.

De programmeur, die in 1975 de originele versie van Emacs schreef, ziet wel een mogelijkheid voor een privacybewuste telefoon, in de vorm van een pager die enkel communicatie kan ontvangen en niets terugzendt naar het netwerk. "Mensen zouden je een bericht kunnen sturen op die pager, waarna je zelf kunt bepalen of je verbinding wil maken met het telecomnetwerk", aldus Stallman.

Moderatie-faq Wijzig weergave

Reacties (110)

Tsja, het is en blijft een heel aparte man eigenlijk. Hij gaat van lezing naar lezing, van universiteit naar universiteit, en "logeert" eigenlijk alleen maar. Een beetje een zwerver-type en daar gaat hij ook heel ver in door. Het is niet een tak van open-source die ik persoonlijk heel erg goed vind, GPL3 is bijvoorbeeld een érg beperkende licentie want het gaat zelfs door op de content... en als developer/consultant/techneut heb ik toch elke maand een hypotheek te betalen, als ik ze had, kan nog, zou ik willen dat m'n kinderen alle kansen krijgen die ik heb gehad (al willen ze zoiets als doctor worden!), en hoewel ik mijn kennis deel, moet ik toch mijn geld verdienen! En tsja... dat kan niet op alléén support. Altruisme is goed maar het kan doorslaan. Ik vind LGPL/BSD dan bijvoorbeeld een stuk beter want: closed source drivers zijn vaak juist een goed ding. Dat je een apparaat kan opsplitsen en in "stukjes" er mee praat is ook een goed ding. Uiteindelijk geld dat ook voor closed source PC software: het is afhankelijk van zelfs het OSI-model wat wil zeggen dat je desnoods wat je NIET wilt tegen kan houden ook al is het closed source. Software is misschien niet open, maar communicatie is dat vaak juist wél. Tenzij ze op een of andere manier entangled elektronen in quantum-staat in software (!) weten in te bouwen waardoor er altijd een onvindbare dial-home modum is die "sneller dan licht" kan communiceren.

Lithografie is duur. Het ontwikkelen van een PCB is al duur maar laat staan het ontwikkelen van een combinatie PCB met SOC en VRM... denk je dat die transistoren voor een 1900+ shader tellende nVidia kaart vanzelf op de juiste plek zijn gaan zitten? Daar zitten mensen achter die het geheel ontwerpen (en de BIOS/firmware is ook software van die krengen...), de drivers maken, de chips ontwerpen, de VRM's ontwerpen, de condensatoren hebben ontworpen, de materialen hebben gemijnd. De raffinaderij, de chemische fabriek, silicium verwerkers, ga zo maar door. Totdat je dat ook "vrij" kan maken en tegelijkertijd de jaren mensenwerk op een of andere manier "gratis" kan maken zodat het niet erg is dat iemand het nadoet in een deel van de wereld met goedkopere maar slechtere scholen en ladingen goedkope "volg de instructies op en denk niet na" arbeidskrachten kán helemaal open gewoon niet.

Leuke visie, maar de man zelf is een extremist en gaat te ver door. Los val al het goeds wat hij heeft gedaan. Maar waren er alleen mannen als hij geweest dan was de computer (ik zeg niet: PC) een niche-apparaat gebleven.
Er staat nergens dat je niet betaald kunt worden om vrije software (free is vrij, niet gratis !) te schrijven.

De groep mensen die dat doet en kan doen omdat daar werk voor is groeiende en blijft maar groeien.

Neem de ontwikkelaars aan de Linux kernel of OpenStack. Deze worden betaald voor Intel, HP, Samsung, Google, etc.

Jammer voor jou maar deze 'extremist' heeft wel heel vaak uit eindelijk gelijk gehad.

Ik ga daar nu niet een heel stuk over schrijven, maar hier een voorbeeld van een andere Nederlander die dat ook heeft ontdekt en er wel een stuk over geschreven heeft:
http://www.osnews.com/sto...llman_Was_Right_All_Along

Ik zou de man niet afschrijven, hij denkt vooruit en daarvan moeten we meer mensen hebben.

De politiek bijvoorbeeld doet precies het tegenovergestelde dit moment.

Bedrijven, vooral beursgenoteerde, hebben een nog kortere visie.

Als we de klimaat wetenschappers mogen geloven dan is het hoog nodig dat we zelfs ophouden in korte termijn denken.
Volledig akkoord. RS is een visionair van het type waar we er te weinig van hebben en waar we te weinig naar luisteren. Hij is altijd al een stap verder geweest dan de rest, altijd vergeleken met een extremist en gek, maar heeft achteraf ook zeer veel gelijk gekregen.

Daarenboven begrijpen veel mensen RS en zijn 'wereldvisie' niet. Die gaat vziw verder dan enkel vrije software. Er is trouwens nog een onderscheid die je moet maken:
Free (as in speech) software, open-source software, Free (as in beer) software.

Vrije software is daarom niet automatisch gratis software. Dat in de OS wereld dit in vele gevallen wel zo is is mooi, maar het hoeft niet. Je kan gerust je software GPL maken en toch verkopen, of een dual-licensed model, of ...
Volledig akkoord. RS is een visionair van het type waar we er te weinig van hebben en waar we te weinig naar luisteren. Hij is altijd al een stap verder geweest dan de rest, altijd vergeleken met een extremist en gek, maar heeft achteraf ook zeer veel gelijk gekregen.

Daarenboven begrijpen veel mensen RS en zijn 'wereldvisie' niet. Die gaat vziw verder dan enkel vrije software. Er is trouwens nog een onderscheid die je moet maken:
Free (as in speech) software, open-source software, Free (as in beer) software.

Vrije software is daarom niet automatisch gratis software. Dat in de OS wereld dit in vele gevallen wel zo is is mooi, maar het hoeft niet. Je kan gerust je software GPL maken en toch verkopen, of een dual-licensed model, of ...
IMO moeten veel mensen een keer naar een presentatie van Richard Stallman gaan. Dan zie ze ook een keer hoeveel kennis hij heeft van de copyright ed en dat hij erg veel inzicht in de hele materie heeft.
Ik ben een paar jaar geleden bij de presentatie in de TU Delft geweest. Het was heel erg interessant, ik heb heel veel bijgeleerd.

Om Richard Stallman met een extremist te vergelijken is IMO in deze wereld te gek voor woorden. Een huidige extremist is iemand die met geweld zijn doel probeert te bereiken.
Ik denk dat Richard Stallman beter als purist gezien kan worden, hij probeert de Software wereld op een geweldloze manier te veranderen.
Dat je in dat geval pleit voor het ideaal (GPL) lijkt me logisch.
Volledig akkoord. RS is een visionair van het type waar we er te weinig van hebben en waar we te weinig naar luisteren. Hij is altijd al een stap verder geweest dan de rest, altijd vergeleken met een extremist en gek, maar heeft achteraf ook zeer veel gelijk gekregen.
RMS is inderdaad niet gek. Hij is een idealist. Het is heel goed af en toe naar idealisten te luisteren omdat ze je aan het denken zetten. Maar in de praktijk is een idealistische houding meestal gewoon niet houdbaar. Zo is het ook met vrije software. Je kan heel fundementalistisch alleen maar vrije software willen hebben, maar in de praktijk moeten mensen ook gewoon hun brood verdienen. En dat gaat met niet-vrije software in sommige gevallen gewoon beter.
Vrije software is daarom niet automatisch gratis software. Dat in de OS wereld dit in vele gevallen wel zo is is mooi, maar het hoeft niet. Je kan gerust je software GPL maken en toch verkopen, of een dual-licensed model, of ...
De GPL vereist inderdaad niet dat software gratis is, maar het is wel een beetje een wassen neus. De GPL staat het jouw klanten namelijk toe om de software verder te verspreiden, zolang ze dat maar onder de GPL doen. Er hoeft dus maar een klant te zijn die het gratis op internet zet, en floep! -- weg klandizie, want iedereen gaat voor de legale gratis versie. Het is dan ook niet voor niks dat alle grote vrije softwareprojecten ofwel zelf gratis zijn, ofwel een gratis communityvariant hebben. De bedrijven achter die projecten verdienen geld met ondersteuning, niet met de software zelf.
Er hoeft dus maar een klant te zijn die het gratis op internet zet, en floep! -- weg klandizie, want iedereen gaat voor de legale gratis versie.
Niet alle software heeft dit risico.
Stel dat je een GPL CRM/HRM systeem maakt en waar dus hele bedrijfsprocessen op draaien. Klanten zullen dit niet zomaar te grabbel gooien, en mocht het toch gebeuren denk ik niet je je eigen klanten kwijt bent.
Jij kent namelijk de code, je ontwikkelt hun wensen en geeft support.

Natuurlijk valt veel code niet onder zo'n idee, maar ik denk dat een serieus bedrijf/serieuze klant wel 2 maal denkt vooraleer ze je aan de deur zet.
Support, training, updates, integratie

Deze argumenten zijn maar het topje van de ijsberg om (zeker zakelijk) niet het gratis alternatief te gebruiken.

Edit: documentatie, veiligheid, maatwerk etc.

Als een bedrijf software koopt dan zijn dit de dingen die daadwerkelijk geld kosten. En als leverancier zijn dit de dingen die daadwerkelijk geld opleveren.

[Reactie gewijzigd door Thystan op 30 december 2014 11:30]

Laten we een ander populair stuk software als voorbeeld nemen.

Wordpress is GPLv2.

Je wilt niet weten hoeveel bedrijven en ZZPs websites bouwen op basis van Wordpress voor hun klanten.

Hun klant kan die Wordpress site meenemen naar een ander bedrijf.

Ja, GPLv2 geeft de gebruiker mee rechten, dat is wat de GPL doet.

Hoe is dat erg ?

Als er een conflict is tussen bedrijf en klant, dan is het toch juist mooi voor de klant dat hij naar een ander kan ?

Dat is wat vrije software doet. Het geeft de klant iets meer rechten.

Zo lang je goed werk aflevert is er ook geen probleem, de klant kwam niet zomaar bij jou(w bedrijf) terecht.

Het aanpassen van algemene software of implementaties doen op basis van die software gaat veel meer geld in om dan het maken van de basis software.

EDIT: het woord waarschijnlijk heb ik weggehaald.

[Reactie gewijzigd door Lennie op 31 december 2014 01:39]

Het is niet een tak van open-source die ik persoonlijk heel erg goed vind, GPL3 is bijvoorbeeld een érg beperkende licentie want het gaat zelfs door op de content... en als developer/consultant/techneut heb ik toch elke maand een hypotheek te betalen, als ik ze had, kan nog, zou ik willen dat m'n kinderen alle kansen krijgen die ik heb gehad (al willen ze zoiets als doctor worden!), en hoewel ik mijn kennis deel, moet ik toch mijn geld verdienen! En tsja... dat kan niet op alléén support. Altruisme is goed maar het kan doorslaan. Ik vind LGPL/BSD dan bijvoorbeeld een stuk beter want: closed source drivers zijn vaak juist een goed ding.
Kortom je bekijkt het vanuit bedrijven / personen die Open Souce Software gebruiken en eigenlijk niet terug willen geven (IMO Free loaders) Daar is het inderdaad inderdaad een slechte licentie voor. En terecht IMO dan moeten ze maar zelf alles van de grond af zelf ontwikkelen.
Maar voor de originele ontwikkelaars die willen dat het product zo goed mogelijk wordt en open blijft zijn het de beste licenties.
Dan vraag ik jou toch: waar zitten de meeste developers, en wordt veel open source in de baas z'n tijd ontwikkeld, óf zijn die mensen ná werktijd NOG aan het ontwikkelen? Veel FOSS wordt juist vanuit het bedrijfsleven ontwikkeld en ja: hoewel er een hoop open is, betekend dat dat er vaak ook externe, NIET open libraries worden aangeroepen. Zo hebben wij een stuk GIS wat BlueMarble GeoCalc aanroept en ik verzeker je: hoewel QGIS zo openbaar is als de pest, en een hoop data ook (niet alles), zal je moeten dokken én geen broncode kunnen zien van bluemarble geocalc. Kun je zelf wel bezig gaan met geodetische transformaties, maar 1: wil je dat, en 2: wat als je het fout hebt en het kadaster trekt jouw schutting met de overgang van rijksdriekhoekstelsel naar ETRS of zelfs voor web views: WGS84 een meter OP je terrein waardoor de buurman z'n hangmat boven je zwembad hangt? Jij ook niet blij!
Dan vraag ik jou toch: waar zitten de meeste developers, en wordt veel open source in de baas z'n tijd ontwikkeld, óf zijn die mensen ná werktijd NOG aan het ontwikkelen? Veel FOSS wordt juist vanuit het bedrijfsleven ontwikkeld en ja: hoewel er een hoop open is, betekend dat dat er vaak ook externe, NIET open libraries worden aangeroepen. Zo hebben wij een stuk GIS wat BlueMarble GeoCalc aanroept en ik verzeker je: hoewel QGIS zo openbaar is als de pest, en een hoop data ook (niet alles), zal je moeten dokken én geen broncode kunnen zien van bluemarble geocalc. Kun je zelf wel bezig gaan met geodetische transformaties, maar 1: wil je dat, en 2: wat als je het fout hebt en het kadaster trekt jouw schutting met de overgang van rijksdriekhoekstelsel naar ETRS of zelfs voor web views: WGS84 een meter OP je terrein waardoor de buurman z'n hangmat boven je zwembad hangt? Jij ook niet blij!
Ten eerste maakt het helemaal niet uit waar de software ontwikkeld wordt. Uiteindelijk is de eigenaar de gene die beslist welke licentie er op geplakt wordt. Vaak beslissen bedrijven ook om een GPL licentie te gebruiken om zeker te zijn dat alle verbeteringen terug komen.
Volgens mij zijn er meer open source software projecten die door privé personen ontwikkeld worden dan bedrijven. Het is wel zo dat bedrijven meestal aan de bekendere software projecten werken.

IMO is jouw GIS BlueMarble GeoCalc verhaal heel erg off topic. Het gaat er veel meer over of het altijd zin heeft om in bepaalde gevallen open source software te ontwikkelen. Ik ken de software niet precies ik weet ook niet waar je werkt etc.
Maar voor bedrijven als het kadaster zou het waarschijnlijk zinvol zin om samen het hun EU tegenhangers een Open Source variant van deze software te ontwikkelen.
Dan heb je direct het probleem niet meer dat als het bedrijf failliet is de software niet meer op een nieuw OS zal werken en je bent niet aan een specifieke ontwikkelaar gebonden. Voor klanten is een GPL licentie in veel gevallen ook ideaal.

Alleen niet voor bedrijven die Open Source software willen gebruiken zonder ooit iets terug te geven.
Maar voor de originele ontwikkelaars die willen dat het product zo goed mogelijk wordt en open blijft zijn het de beste licenties.
Ik heb zelf een aantal open source projecten - waarvan ik weet dat een aantal actief worden gebruikt - en toch ben ik geen RMS aanhanger of fiets ik zelf rond GPLv3. En als ik bij server gerelateerde dingen toch die loophole wil sluiten, dan verkies ik AGPL niet die doorgedraaide v3 van GPL.

Dat heeft niets te maken met een freeloaden instelling maar gewoon van een andere opinie. RMS is in mijn ogen zelf een onverbeterlijke extremist waar ik bij sommige uitspraken toch even van in de haren krab.
Dan vraag ik jou toch: waar zitten de meeste developers, en wordt veel open source in de baas z'n tijd ontwikkeld, óf zijn die mensen ná werktijd NOG aan het ontwikkelen? Veel FOSS wordt juist vanuit het bedrijfsleven ontwikkeld
Veel FOSS wordt net vanuit intrinsieke motivatie ontwikkeld en dus in mensen hun vrije tijd, is volgens mij ook de reden waarom gesloten software er soms niet aan kan tippen. Dat laatste is trouwens iets wat ik ook wetenschappelijk kan onderbouwen want er bestaan al decennia aan onderzoek die aantonen dat geld als motivator, een negatieve impact hebben op creatieve taken zoals het programmeren. Je moet maar eens het boek Drive lezen van Daniel pink of zijn TED talk bekijken.

Daarentegen heb je idd ook FOSS die vanuit bedrijven worden ontwikkeld vaak uit marketingoverwegingen of de weinig die de 20% tijd regel hanteren. Je hebt er zelf die het doen - vaak diegene waar je bij elke pull request een papier mag tekenen om afstand te doen van je rechten - die er gratis arbeid inzien. Maar dat FOSS enkel maar levensvatbaar is door tijd te "spenderen in de baas hun tijd" is een flagrante leugen.

Ik spendeer heel wat van mijn vrije tijd aan FOSS en dat omdat ik het leuk vind en net omdat ik tijdens mijn werkuren vaak de ruimte niet heb om op die problemen te werken. Niet elke ontwikkelaar is een ontwikkelaar geworden omwille van het vele geld, sommigen van ons hebben echt een passie die ons drijft en waar geld maar een ondergeschikte rol in speelt.

[Reactie gewijzigd door simplicidad op 29 december 2014 10:57]

...Je moet maar eens het boek Drive lezen van Daniel pink of zijn TED talk bekijken.
Fantastisch verhaal: http://www.ted.com/talks/dan_pink_on_motivation?language=nl
Men kan soms ook doordraaien met een licentie. Direct ook de reden waarom de linux kernel bijvoorbeeld nog altijd op GPLv2 zit en niet op v3 . De v3 licentie eist te veel openheid en maakt bepaalde dingen totaal onmogelijk die leuk zijn in een idealistische wereld, maar onpraktisch in de echte wereld.

LGPL en BSD hebben hun nut, zeker wanneer er een verbinding moet komen met gesloten software. Neem je GPLv3 code op in een closed source project zou je direct heel dat project ook onder de GPLv3 moeten uitbrengen en dat is onrealistisch.
LGPL en BSD hebben hun nut, zeker wanneer er een verbinding moet komen met gesloten software. Neem je GPLv3 code op in een closed source project zou je direct heel dat project ook onder de GPLv3 moeten uitbrengen en dat is onrealistisch.
Dat klopt niet, het is wel een grijs gebied. Je mag GPL code dynamisch linken (denk aan de videodriver modules). Maar code statisch linken of in je eigen code zonder de code een GPL licentie te geven mag niet.
In veel gevallen kan GPL code veel tijd en geld besparen dat ruim opweegt tegen de verplichtingen maar dat willen sommige bedrijven niet zien. Ze willen eigenlijk van twee walletjes eten. Lekker code gebruiken waar andere hun tijd en/of geld gestopt hebben zonder er zelf maar iets aan terug te geven.

Dat gezeur over GPL snap ik helemaal niet, er is niemand die je verplicht om GPL code te gebruiken. Je kunt en mag de code ook helemaal zelf ontwikkelen.
Als je GPL code wel gebruikt dien je aan de verplichtingen te voldoen.

Typo.

[Reactie gewijzigd door worldcitizen op 29 december 2014 12:47]

Je mag GPL code statisch linken (denk aan de videodriver modules). Maar code statisch linken of in je eigen code zonder de code een GPL licentie te geven mag niet.
Dit is pertinent onwaar. Ik hoop voor je dat je dit niet doet.
GPL en LGPL code mag je niet statisch linken, enkel LGPL code mag je wel dynamisch linken.

Secite 2.b:
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Als je statisch linkt voldoe je op z'n minst aan de "any part thereof" en moet je de volledige source "as a whole ... under the terms of this License" vrijgeven.
[...]


Dit is pertinent onwaar. Ik hoop voor je dat je dit niet doet.
GPL en LGPL code mag je niet statisch linken, enkel LGPL code mag je wel dynamisch linken.

Secite 2.b:

[...]


Als je statisch linkt voldoe je op z'n minst aan de "any part thereof" en moet je de volledige source "as a whole ... under the terms of this License" vrijgeven.
De eerste statisch, in mijn vorige reactie, moest dynamisch zijn (heb ik gecorrigeerd).
Dynamisch linken aan GPL code is grijs gebied. Dat doen zowel NVidia als AMD met hun closed source video drivers.
Veiligheidshalve zou ik het ook niet doen.
De reden waarom nVidia en AMD dit doen is omdat:
- ze dezelfde code gebruiken op alle platformen. Je kan dus moeilijk claimen dat hun driver een afgeleid werk is.
- het gaat om een H/W driver. De code is waardeloos en onbruikbaar zonder dit specifiek H/W component. Er zijn wel meer fabrikanten die om deze reden toch de grijze zone betreden - hoewel het dan eerder om erg specialistische H/W gaat die niet zomaar verkrijgbaar is...

De eerste is wat mij betreft doorslaggevend hier.
Je zal in sommige gevallen zelfs alle documenten die je er mee maakt haast openbaar mee moeten maken als je er toevallig een macrootje in hebt... de lijn is té vaag bij GPLv3.
Que? Je zal met een voorbeeld moeten komen want zoals het hier staat is het onjuist/onvolledig.

GPLv3 gaat nooit over de data die door een GPLv3 tool bewerkt wordt. Het simpelste voorbeeld is de compiler: een GPLv3 compiler zorgt er niet plots voor dat alle code die je maakt GPLv3 wordt (en de GCC jongens hebben voor libgcc zelfs een speciale GPLv3+exception licentie gemaakt).

Een GPLv3 tekstverwerker zal niet automatisch ervoor zorgen dat alle code GPLv3 wordt. Als die tekstverwerker een macro in een document stopt, dan is het gewoon de vraag of die macro ook onder die licentie valt of niet. Een beetje slim developer zorgt ervoor dat macro's onder een aparte licentie vallen (bij voorkeur zelfs public domain).
De Linux kernel zit vanwege de eisen in GPLv3 nog op GPLv2, maar doordat ze gekozen hebben om de "upgrade clause" van GPLv2 niet te hanteren kunnen ze niet naar een nieuwere versie van de GPL zonder toestemming van iedereen waarvan code in Linux zit.
Dat Stallman regelmatig fundamentalistischer is dan practisch, ben ik volkomen met je eens. Als theoreticus heeft hij echter toch in veel gevallen wel gelijk, en zulke mensen moeten er ook zijn om je wakker te houden.

Ik snap in jouw betoog niet waarom drivers niet open zouden mogen zijn. Door de specificaties van de hardware gewoon vrij te geven, is er juist op het gebied van drivers schrijven ontzettend veel winst te behalen. Denk alleen maar eens aan drivers die hooguit 1 of 2 OS-versies lang updates krijgen, waardoor nog prima werkende hardware na een paar jaar afgeschreven moet worden of functionaliteit verliest. Denk ook gewoon aan het recht van de gebruiker om zelf te bepalen hoe hij zijn gekochte en duur betaalde hardware wil gebruiken. Denk ook aan optimsalisatie. Drivers die fors sneller of efficienter kunnen voor precies dat wat jij er nou toevallig mee wilt doen.

Daar hoef je de modulaire opbow helemaal niet voor op te geven.
Op zich heeft hij gelijk dat vrije software transparantie afdwingt het het moeilijker maakt om buiten het zicht van de gebruiker zaken uit te halen.
Maar als ik zo'n 'OSS kopstuk' was zou ik persoonlijk het woord wapen nog niet in de mond nemen. Dan moet je ook openlijk zeggen wie de tegenpartij is en welke richting we op willen met onze "vrije software". Gaan we het nu tegen het systeem gebruiken? Ik denk niet dat alle gebruikers en aanhangers het daarmee eens zijn.
In de Linux wereld is op het moment een hoop te doen tegenover "conservatief" (waar ik deze man onder zal scharen) en "progressief". De laatste tak zoekt nogal de samenwerking op met de takken zoals Canonical en hardware vendors om het product breder te brengen. Je ziet zo ook hoe nu 60% van de telefoons op Linux draaien; zei het een fork die "Android" genoemd is met slechts een gedeeltelijke GNU implementatie en compleet géén X.org.

Ik denk dat het systemd VS. init debat een erg goede is: persoonlijk hang ik het kamp systemd aan, het is een goede verbetering, paralellisatie, modulair, en een goed services framework wat het concept monolitische kernel eindelijk wat meer richting de "hybride" kant brengt. Er is echter ook een tak van mensen die "mens leesbare config files" aanhangt. Hetzelfde type wat er
10 IF X = 42 GOTO 40
20 X = X + 1
30 GOTO 10
40 PRINT "X is finally 42!"

Ideeën op nahoud om eeuwig compatible te blijven. Leuk, maar ook niet leuk. Niet alleen open VS closed, maar ook conservatief VS progressief. Stallman is in deze concepten eigenlijk een coservatief, open source type... en ook in de open source wereld is er dus een hoop ruzie. En een hoop vooringenomen concepten/achterdocht/kinderachtige fetes. Voorbeeldje: nieuws: Microsoft brengt .Net naar Linux en OS X en maakt .Net Server Core opensource -- een hoop achterdocht. Bijdrages aan de Linux Kernel: ook achterdocht...
Wat is er mis met mens leesbare config files? Zelfdocumentererend en eenvoudig en snel aanpasbaar. Er mist helaas wel wat stadaardisatie op dat vlak. Maar het zorgt oa voor dat systeemtools prima configtaken kunnen uitvoeren. In is het ieder geval stukken beter dan het windows registry systeem. Een kluit onleesbare data in 1 bestand...
Er mist niet alleen een hoop standaardisatie, een hoop HOEFT ook niet mens-leesbaar te zijn. Er zijn mensen die voor alles JSON pakken, al is het nóg zo'n complex 3D model van 100MB+ wat je niet open krijgt in wat voor text editor dan ook, laat staan dat je het wilt veranderen. Een config database is ook geen slecht idee. Het concept register is ook niet helemaal verkeerd te noemen.
Een config database is ook geen slecht idee. Het concept register is ook niet helemaal verkeerd te noemen.
Je moet het ook in de juiste context plaatsen:
1) Registry is met Windows NT geintroduceerd begin jaren 90. De voordelen van de registry zijn dat het snel en compact is. In een tijd dat CPU-tijd en opslag nog schaars waren, is dat idee zeker niet gek.
Voordeel hiervan is ook dat de toegang gestandaardiseerd is. Bij config-files heeft iedere applicatie z'n eigen parser aan boord, en daarin dan vaak een in-memory hashing-systeem, wat bij de registry allemaal al gestandaardiseerd en gedeeld is.
2) Windows NT wordt toch grotendeels via GUIs/commandline tools geconfigureerd, die op hun beurt weer de registry-waarden aanpassen. Dat de registry zelf niet human-readable is, is dus niet zo interessant.
3) De registry ondersteunt .reg bestanden waarmee je (delen van) de registry kunt importeren/exporteren. Deze zijn wel human-readable.
Ik vind persoonlijk het verschil tussen een human-readable config-file, en een human-readable .reg file die je kunt editen en importeren, niet heel groot. Er wordt nogal overdreven over gedaan, naar mijn mening.
Je weet ook dat het Windows-register in zijn oorspronkelijke vorm niets te maken had met het opslaan van configuratiegegevens van programma's, maar vooral was bedoeld om programma- en driverassociaties te leggen? Zie bijvoorbeeld het gebruik van het register in Windows 3.1.

Het opslaan van andere gegevens is mijnsinziens een kunstgreep geweest om van een wildgroei aan ini-files af te komen, die opzich zeker niet slecht heeft uitgepakt maar ook niet helemaal zo goed is als hij had kunnen zijn.
Je weet ook dat het Windows-register in zijn oorspronkelijke vorm niets te maken had met het opslaan van configuratiegegevens van programma's, maar vooral was bedoeld om programma- en driverassociaties te leggen?
Uhhh, dat ZIJN configuratiegegevens.
Maar inderdaad... Windows 3.x werkte nog met .ini files.
Oorspronkelijk is de registry in Windows 3.1 geintroduceerd om COM mogelijk te maken.
Maar Windows NT was toen al lang in ontwikkeling, en de registry zal we gebackport zijn naar Windows 3.1. Windows NT kwam alleen een paar maanden later op de markt dan Windows 3.1, dus dat vertekent de chronologie wat.
Het opslaan van andere gegevens is mijnsinziens een kunstgreep geweest om van een wildgroei aan ini-files af te komen, die opzich zeker niet slecht heeft uitgepakt maar ook niet helemaal zo goed is als hij had kunnen zijn.
Waarom zou dat een 'kunstgreep' zijn?
In Windows NT heeft men het vanaf dag 1 zo gedaan.
Het is eerder een kunstgreep geweest om een registry aan Windows 3.x toe te voegen. Daar moet je dus ook niet je hele visie van de registry op baseren.
In Windows 9x, de directe opvolger van 3.x, heeft men net als bij NT wel de .ini files compleet gedag gezegd, en ging men volledig over op de registry (op legacy support van Win16 apps na natuurlijk).
Ik bedoelde: "een heel beperkt en specialistisch onderdeel van de Windows configuratiegegevens" versus "alle configuratiegegevens van alle software". Excuus als ik dat onduidelijk had opgeschreven.

De naam registry wijst ook wel in die richting: dingen die je moet registreren. Dat wijst eerder op associaties dan op configuratiegegevens van alle software.

Mogelijk verder wel goede punten die je noemt m.b.t de NT-ontwikkeling. Dit vraagt wat diepgravender onderzoek naar de registry in de traditionele Windowsversies vóór 3.1. Die kennis heb ik zo niet paraat. Ik doelde met associaties inderdaad o.a. op COM.

Aanvulling: Dat hij in NT keurig gestructureerd is opgezet en waarschijnlijk al meteen voor alles werd gebruikt, lijkt me aannemelijk. In de praktijk werkt het ook best aardig, en zijn defecten meestal ook afdoende op te lossen door middel van systeemherstel.

[Reactie gewijzigd door mae-t.net op 29 december 2014 15:59]

De naam registry wijst ook wel in die richting: dingen die je moet registreren. Dat wijst eerder op associaties dan op configuratiegegevens van alle software.
Een 'registry' is een 'register' in het Nederlands. Dat is dus een plek waar gegevens worden bewaard: http://www.vandale.nl/opz...gister&lang=nn#.VKFdDAADM
Een boek/index dus.
Dat heeft niet noodzakelijkerwijs met 'registreren' te maken in de zin die jij denkt (in de vorm van een abbonnement of iets).
Gewoon het vastleggen van gegevens... configuratiegegevens.
Dit vraagt wat diepgravender onderzoek naar de registry in de tijd vóór 3.1.
Zoals ik zeg: die was er niet.
Windows 1.x, 2.x en 3.0 werkten nog met ini-files, en COM bestond nog niet.

[Reactie gewijzigd door Scalibq op 29 december 2014 14:57]

Samengevat: Register (NL) en Registry (EN) betekenen hetzelfde en zijn ook volgens van Dale eerder een soort index waarin dingen geregistreerd worden dan een algemeen boek. What's in a name?

Tijdlijn: Windows 3.1 kwam uit voordat Windows NT3.1 uitkwam. In eerdere versies zat inderdaad geen registry. Dat maakt het opzichzelf al aannemelijk dat ergens tussentijds pas is besloten om de registry in NT3.1 breder te gaan gebruiken dan de eerste implementatie in 3.1, of op zijn minst dat er nog druk aan een breder gebruik gewerkt werd toen de ontwikkeling van 3.1 afgesloten werd. Er is kennelijk geen sprake van een beperkte backport uit NT3.1 naar 3.1 zoals je suggereerde, al overlappen de tijdlijnen elkaar wel gedeeltelijk.

Bovendien bevestigt Wikipedia mijn stelling:
When first introduced with Windows 3.1, Windows Registry's primary purpose was to store configuration information for COM-based components. With the introduction of Windows 95 and Windows NT, its use was extended to tidy up the profusion of per-program INI files that had previously been used to store configuration settings for Windows programs.

[Reactie gewijzigd door mae-t.net op 30 december 2014 05:46]

Tijdlijn: Windows 3.1 kwam uit voordat Windows NT3.1 uitkwam.
Wat nogal logisch was, omdat Windows 3.1 een kleine update was aan 3.0, waar NT3.1 de eerste versie was van de NT-reeks, een compleet nieuw OS, en de eerste 32-bit versie van Windows.
Dat maakt het opzichzelf al aannemelijk dat ergens tussentijds pas is besloten om de registry in NT3.1 breder te gaan gebruiken dan de eerste implementatie in 3.1
Vind je?
Dan zou men op vrij korte termijn het hele OS overhoop hebben moeten gooien om de configuratie van .ini files om te zetten naar registry. Dat is niet iets dat je binnen een jaar voor release van een dergelijk groot OS gaat doen.
Het lijkt mij veel aannemelijker dat men sowieso de registry al had ontworpen in NT, en dat men bij het ontwikkelen van COM dacht van "Okee, in NT kunnen we dat mooi in de registry doen. We kunnen een soort lightweight-registry backporten naar de 3.x-reeks zodat we COM daar op dezelfde manier kunnen doen".

Sowieso zie ik je logica niet echt:
"Windows 3.1 is de eerste met een registry, maar gebruikt het ALLEEN voor COM, *dus* gaat men in NT de registry voor alles gebruiken."
Dat is toch geen logisch gevolg?
Sowieso, heb je wel een goed beeld van hoe breed de registry in NT3.1 is toegepast?
http://en.wikipedia.org/wiki/Windows_NT_3.1
The Windows registry, introduced with Windows NT 3.1, is a central, hierarchical configuration database[85] designed to allow configuration of computers over the network[102] and to replace the commonly-used text-based configuration files, like INI files, AUTOEXEC.BAT and CONFIG.SYS.[103] Using the undocumented registry editor, the Windows registry can be viewed and edited by the user.[85]
Dat is niet iets dat je 'even' besluit, omdat Windows 3.1 'toevallig' een registry voor COM heeft.
Configuratie over een netwerk met alleen .ini bestandjes? Ik wens je veel succes!
Er is kennelijk geen sprake van een beperkte backport uit NT3.1 naar 3.1
Waarom niet?
Je stelt wel dat het 'kennelijk' zo is, maar ik zie nergens een argument waaruit dat zou moeten blijken?
Want dat de implementatie in 3.1 eerder op de markt is, impliceert nog niet dat dat ook de eerste implementatie van de registry was. De implementatie in NT kon alleen niet eerder op de markt komen dan de eerste complete versie van NT. Dus die registry moest wachten totdat de implementatie van alle andere NT-onderdelen ook klaar was.
Bovendien bevestigt Wikipedia mijn stelling:
[...]
Welke stelling precies? En hoe wordt dat bevestigd?
Het bevestigt eerder mijn stelling:
In 3.1 wordt het ALLEEN voor COM gebruikt (als een soort backport dus).
In NT zijn er nooit INI files geweest, en heeft men vanaf dag 1 alleen de registry gebruikt.
Dit systeem is ook later ook overgenomen door Windows 95 (wat logisch is, het was immers een lightweight implementatie van de Win32API van NT).
Misschien vergis je je in het feit dat NT uit 1993 is, dus vlak na Windows 3.1 uit 1992, en lang voor Windows 95?
Windows 95 is in het verhaal totaal niet relevant eigenlijk.

[Reactie gewijzigd door Scalibq op 30 december 2014 11:24]

1992 en 1993 zijn mij bekend. Natuurlijk liep de ontwikkeling al langer en hebben ze niet in minder dan een jaar even een groot deel van de registry bedacht, maar het ligt voor de hand dat er in die tussentijd nog wel aan geschaafd is (ook al weet je nooit zeker welke factoren meespeelden bij het niet volledig in 3.1 maar wel volledig in '95 implementeren). Feitelijk moet je ook nog gaan kijken hoe OS/2 de zaken aanpakte, wat daar op de agenda stond, of er in Windows 3.0 al wat op de agenda stond wat niet in de release terecht is gekomen, enz. en dan interne projecttijdlijnen van MS erbij gaan zoeken of reconstrueren. Bronnenonderzoek n.a.v. de door mij aangehaalde Wiki liep met snel doorklikken in eerste instantie op niets uit. Ik heb wel ervaring met zulk onderzoek op andere terreinen, al schrijf ik de redenaties hier kennelijk niet zodanig op dat ze voor iedereen goed te volgen zijn. Heb ook geen zin om ze punt voor punt nog een keer door te lopen, hier schrijven blijft toch iets dat ik er voor het plezier bij doe na lange dagen.

Verder zoeken is mij te veel moeite voor een "minor issue", conclusie: geloof wat je wil geloven. Helemaal onjuist zal het niet zijn; statistisch is de kans dat we er allebei in meer of mindere mate naastkleunen op basis van de beperkte informatie die voorhanden is, erg groot. Mocht je zin hebben om er verder in te duiken, hoor ik het graag maar ik doe het zelf niet.

[Reactie gewijzigd door mae-t.net op 30 december 2014 22:45]

(ook al weet je nooit zeker welke factoren meespeelden bij het niet volledig in 3.1 maar wel volledig in '95 implementeren).
Had ik al gezegd: legacy. Volgens mij heb je dat argument niet begrepen.
Windows 3.1 was een 16-bit Windows, en 16-bit Windows werkt nu eenmaal met .ini files, dat was al zo sinds 1985. Dat kun je niet meer omgooien naar een registry, dan gaat alle bestaande software kapot.
Je kunt er wel een registry NAAST zetten, voor nieuwe features als COM, waar nog geen legacy is.
Voor 32-bit is MS met een schone lei begonnen. NT werkt dus met registry (er zijn voor Win16 wel nog een aantal .ini bestanden).

Win95 implementeert 'Win32-lite', en dus moet ie ook een registry hebben. Doet in feite hetzelfde als wat NT doet (dus ook legacy .ini bestanden voor Win16 support nog aanwezig).
Daarom zei ik al: Win95 is niet relevant voor dit verhaal. Het probeert slechts compatible te zijn met NT.

[Reactie gewijzigd door Scalibq op 30 december 2014 23:57]

Grappig dat juist die .reg bestanden nog enige vorm van leesbaar en bewerkbaar zijn hebben... zelfs uitleg kan erbij. I.t.t het register zelf. Die is lastig te navigeren, bewerken en zoeken.

Soms lijkt het ook alsof MS het bewust zo moeilijk mogelijk maakt... al eens gekeken hoe een Outlook profiel verstopt zit in het register?

[Reactie gewijzigd door Rinzwind op 29 december 2014 14:57]

Problemen met het register zijn o.a. dat het alleen te bewerken is in een werkend systeem, zodat een systeem dat niet werkt door een registerfout niet aan de praat te krijgen is. Verder wordt het register bij iedere wijziging groter, doordat nieuwe informatie achteraan komt en verwijderde informatie ongebruikte ruimte overlaat, en er ook geen ondersteunde methode is om te zaak te comprimeren. Die nadelen heb je niet bij tekstgeoriënteerde bestanden.
Problemen met het register zijn o.a. dat het alleen te bewerken is in een werkend systeem, zodat een systeem dat niet werkt door een registerfout niet aan de praat te krijgen is.
Helemaal niet.
De registry is opgeslagen in een aantal bestanden, genaamd 'hives'.
Je kunt deze bestanden 'mounten' via regedit op een ander systeem (of bv met een andere installatie op hetzelfde systeem, of een WinPE bootdisk oid).
Op die manier kun je dus fouten in de registry aanpassen en een systeem weer bootend krijgen.
Zie ook: http://technet.microsoft.com/en-us/library/cc732157.aspx
En: http://msdn.microsoft.com...s724877%28v=vs.85%29.aspx

Gebrek aan kennis van jouw kant dus.
Verder wordt het register bij iedere wijziging groter, doordat nieuwe informatie achteraan komt en verwijderde informatie ongebruikte ruimte overlaat, en er ook geen ondersteunde methode is om te zaak te comprimeren.
Er bestaan zeker wel registry defragmenters, maar over het algemeen is dat niet noodzakelijk. De grootte van de registry heeft namelijk geen invloed op de snelheid (het is immers een geindexeerde database).
En zo heel groot wordt de registry nou ook weer niet (op mijn ontwikkeldoos hier op het werk is SOFTWARE 138 MB en SYSTEM 19 MB. De rest is helemaal verwaarloosbaar klein... Niet echt iets om van wakker te liggen).

[Reactie gewijzigd door Scalibq op 30 december 2014 14:38]

al is het nóg zo'n complex 3D model van 100MB+ wat je niet open krijgt in wat voor text editor dan ook
mag ik je voorstellen aan Vim
Ik lees al jaren over die systemd vs init discussie. Als FreeBSD-gebruiker heb ik dat nooit helemaal gevat. Na het booten geeft de kernel de controle over aan een ander proces wat in volgens mij in alle BSD's init is. Die voert normaalgesproken de rc-scripts (die gooi ik er altijd uit), start getty op voor de hardware consoles en voert login uit om vervolgens in stilte actief te blijven als parent van alle verdere user-processen. Op het moment dat die stopt of breekt vallen we terug in single-user mode, wat dezelfde toestand is als voordat init gestart werd.
Wat ik me afvraag is wat initd in linux nou anders doet dat dat zo discussiewaardig is. Behalve voor gestandaardiseerde de bootsequence en processen-hierarchie zit er (bij *BSD) volgens mij niet zoveel functionaliteit in. Het is enkel het systeem in een bruikbare toestand brengen. Alle andere dingen die gestart of geladen moeten worden kunnen elders geregeld worden.
Er zijn meerdere redenen waarom men overstapt naar Systemd. Allereerst is een script in /etc/init.d gruwelijk inefficiënt om uit te voeren: Je start vaak wel 10 processen op om uiteindelijk 1 daemon te starten. Ook is het erg lastig om daemons parallel te starten, beetje zonde van moderne processoren met heel veel kernen. Met systemd start een systeem gewoon een stuk sneller op. Zo'n script is ook distributiespecifiek: SuSE gebruikt geheel andere scripts dan Debian. Daarom bemoeilijkt het init-systeem het installeren van software van derde komaf. Het gebrek aan standaardisatie zorgt er ook weer voor dat software die op het systeem draait, bijvoorbeeld KDE, geen goede betrouwbare methode heeft om er mee te communiceren en zo de gebruiksvriendelijkheid van het systeem te vergroten. Tot slot gaan de init scripts nog immer uit van een server die gestart wordt en weer afgesloten worden. Met systemd worden zaken mogelijk dat je bijvoorbeeld daemons pas gaat starten als je je laptop in het netwerk prikt.

[Reactie gewijzigd door dmantione op 29 december 2014 13:09]

Volgens mij, als het goed is, hangt de installatieprocedure van een stuk software van derden niet aan init of systemd gerelateerde instellingen omdat dat een per machine gespecificeerde en optionele configuratie is.
Ik denk dat daar het probleem zit en de discussie wel of geen systemd c.q. gestandaardiseerde processenmanager voorkomt uit het geen raad weten met een kaal platform oftewel gewend zijn aan een bepaalde voorgekauwde configuratie. Of je nou alles wat je nodig hebt opstart vanuit een shell-script die automatisch meestart of dat laat regelen door een daemon die standaard draait maakt in de praktijk weinig verschil. Bijv. een mail daemon die start op het moment dat je online gaat is bij beide manieren goed haalbaar.
Bij het eerste moet je het alleen zelf eenmalig regelen.
Zelf heb ik het liefst zo weinig mogelijk processen draaien op een standaard schoon systeem en knoop ik daemons e.d. met een specifiek doel het liefst aan de startprocedure van de desbetreffende software om het met afsluiten ook weer te laten verdwijnen. Daar heb ik tot nu toe geen constant draaiende processen voor nodig gehad. Juist een van de redenen om FreeBSD te doen ipv Windows is al die meuk die standaard (en voor niks) aan staat + het feit dat alleen grof en vanuit user-perspectief te zien is wat er eigenlijk allemaal draait.
Jij doet dat dan ook zelf, iets wat eigenlijk alleen zinvol is als het nodig is (vrijwel nooit, jij doet het omdat het kan en je het leuk vind...).

systemd doet feitelijk wat jij beschrijft!
Ja maar als een script 1 voor 1 opstart kan het niet in conflict raken. Je hebt gelijk maar punt hierin is Linux is van oorsprong server based. En nu wordt het consumenten pc. In eerste geval hoevaak reboot je een server? Wil je dan stabiliteit of snelheid. In 2 de geval idem maar tegenovergesteld ;)
Reken voor de servermarkt er maar op dat de Oracles en VMWare's heel blij zijn met de standaardisering die Systemd oplevert en afdoende goede contacten met Red Hat en SuSE hebben om te zorgen dat SySVinit weldra uit de servermarkt verdwenen is.
Bij linux doet initd niks anders dan bij *bsd.
Stallman heeft zelf weinig met Linux te maken en is ook lang niet altijd een graag geziene gast onder Linux-gebruikers/developers enz.
Hij is oprichter van GNU en van de Free Software Foundation. Op zich is het streven naar open en vrije software een goed streven, maar Stallman staat erom bekend hier dusdanig fundamentalistisch in te zijn dat hij liever helemaal geen software ziet, dan software die gedeeltelijk open is. En daarmee is zijn houding niet altijd even constructief.
Ik begrijp niet goed wat je bedoeld. Waarom haal je de kernel erbij? Het al dan niet monolithisch zijn van de kernel heeft toch niks met de systemd discussie te maken! Daarnaast snap ik niet waarom iedereen modulariteit van systemd altijd zo lopen op te kloppen. Bij init heb je die modulariteit automatisch. Je kunt gewoon kiezen welke rc scriptjes worden gerund en welke niet. Ik heb vaak het idee dat de meeste mensen die zich in de discussie mengen eigenlijk niet weten wat init doet.
Ik wil overigens niet de suggestie wekken dat jij bij die groep hoort.
De tegenpartijen zijn de groepen als NSA, AIVD en MIVD die de surveillance uitvoeren.
Google, KPN, Ziggo (digitale televisie), Rijkswaterstaat, belastingdienst, Albert Heijn, en de lijst is lang niet af.

Opsporingsdiensten, daarvan is het bekend, de andere partijen hebben net zoveel, zoniet meer gegevens, waar eventueel een opsporingsdienst ook even een bezoekje kan brengen.

* Iblies denkt aan de kikker en heet water
Je hebt groot gelijk, op dat va die kikker na. Dat is een fabeltje.
Eerlijk: tegen de (inter)nationale veiligheidsdiensten hoef je je meestal niet te beschermen.

Je wilt je wel beschermen tegen de verzamelwoede van alle commerciële partijen.
"Maar ontwikkelaars van vrije software voelen geen drang om malafide functionaliteit toe te voegen."

Ahum! NSA heeft o.a. meegewerkt aan de encryptie binnen openssh. Ik geloof dat ze een zeer grote drang voelen om malafide functionaliteit toe te voegen!

Verder had Richard wel gelijk.
Een wapen kan je ook gebruiken voor verdediging. Bij verdediging is je vijand nog niet bekend.
Het is een misvatting dat je een wapen pas nodig hebt zodra je tegenstanders hebt.

Het is beter om wapens te hebben voordat je tegenstanders hebt, dat geeft een voorsprong, zie bijvoorbeeld de handelswijze van de NSA.

In dit betoog hier is het wapen meer een 'verzekering' tegen surveillance. Surveillance op zichzelf is ook niet per definitie slecht, maar moet wel controleerbaar en proportioneel zijn. Eigenlijk net als geweld...

Maar daar staat weer tegenover dat ook het praktisch nut in verhouding moet zijn tot de mogelijke surveillance, en daarin schiet meneer Stallman vaak nogal door, hij ziet liever dat het praktisch nut in alle gevallen moet inboeten ten faveure van 'heimelijkheid'. Want dat is het natuurlijk wel. Ik denk niet dat veel mensen het daarin met hem eens zijn, de technologie is er nog altijd om meer mogelijkheden te bieden dan voorheen, niet minder.

De harde werkelijkheid is dus eigenlijk precies wat Stallman zegt: je kan niet beide (volledig/maximaal praktisch nut en 100% surveillance-vrij/privacy) hebben.

[Reactie gewijzigd door Vayra op 29 december 2014 20:18]

"Mensen zouden je een bericht kunnen sturen op die pager, waarna je zelf kunt bepalen of je verbinding wil maken met het telecomnetwerk", aldus Stallman.
Aardig idee. Nadeel is natuurlijk dat het bericht op zijn minst in heel Nederland moet worden uitgezonden, want je weet niet waar de persoon zich bevindt. Ik vraag me ook af hoe je zo'n bericht versleuteld. Op een PGP achtige manier waarbij je eerst de publieke sleutel van iemand moet weten? Het is misschien wel veilig, maar het qua gebruiksgemak lijkt het me toch een stapje terug.

Ik zou meer zien in een Ubuntu telefoon met open-source drivers. Dat moet toch kunnen als de specificaties van de hardware fabrikant bekend zijn.
Dat laatste ligt heel gevoelig. Dat betekent behalve dat de boel niet meer controleerbaar is ook dat het zeer lucratieve ecosysteem dat tussen de hardware en de gebruiker in getrapt is overbodig wordt. Een maker van een volledig open Ubuntu-telefoon moet zelf de (linux) systeemsoftware engineeren tot een bruikbaar geheel en daarbij er niet van uit gaan dat er nog iets valt te verdienen aan nevenactiviteiten op software-level.
Maar persoonlijk zou ik voor zo'n toestel een aanzienlijk bedrag over hebben. Ik zit niet te wachten op een Google of Apple verplicht in mijn platform. Die vormen alleen maar een risico en hebben we verder nergens voor nodig.

[Reactie gewijzigd door blorf op 29 december 2014 10:09]

Maar persoonlijk zou ik voor zo'n toestel een aanzienlijk bedrag over hebben.
Je kan een OpenPhoenux-device overwegen, of een Neo900. De GTA04-upgrade-boards voor Openmoko-telefoons zijn al productiemodellen, voor een volgende productierun worden bestellingen vergaard.
De Neo900 is in prototype-fase.

Beide series worden ontwikkeld met het maximum aan haalbare openheid voor de hardware. De componenten die een gesloten firmware-deel nodig hebben (modem, wifi) zijn via interne USB aangesloten.
Op de modem-aansluiting van de Neo900 zit een verklikker-circuit. Als de modem uitgeschakeld is, maar (stiekum) toch activiteiten ontplooit, dan wordt dat door het verklikker-circuit gesignaleerd.
Nee, de modem die de communicatie verzorgt met het GSM netwerk bevatten altijd gesloten, digitaal ondertekende firmware. Daar kom je niet rond. Net met als doel de veiligheid op het GSM netwerk te verhogen.
Dat zou dus een randapparaat moeten zijn met een integere methode voor aansturing, net als bij een PC met modem. Met als verschil dat ie in dezelfde behuizing zit. Wat aan de andere kant van het modem gebeurt is grotendeels non-TCP/IP en verschilt per provider/netwerk. Maar dat is niet van belang. Een dergelijk apparaat is gewoon bruikbaar met een volledig open besturingssysteem. "Probleem" in die opstelling is alleen dat het systeem niet eventueel kan verbergen wat er in- en uit gaat.
En dat lees je dit soort dingen: nieuws: 'Locatie mobiele telefoons eenvoudig te achterhalen via ss7'

Veiligheid, jaja... Commerciële belangen, dat is alles. Ook voor het niet verbeteren van de veiligheid van SS7.
Interessant stuk, voor mij een van de redenen om een opensource besturingssysteem te gebruiken.

Sinds Valve SteamOS en Linux gaming actief promote gebruik ik bijna alleen nog een opensource besturingssyteem, alleen mijn eerder aangeschafte games draai ik nog wel eens op mijn Windows partitie.
Terwijl Valve juist één van die bedrijven is waar deze man het compleet niet mee kan vinden. Zoveel closed source er binnenin, wát open source is, is GPLv2 of Apache/BSD/LGPL, en teveel closed hardware support. Wat deze man betreft JUIST kwaadaardiger dan Windows!
Terwijl Valve juist één van die bedrijven is waar deze man het compleet niet mee kan vinden. Zoveel closed source er binnenin, wát open source is, is GPLv2 of Apache/BSD/LGPL, en teveel closed hardware support. Wat deze man betreft JUIST kwaadaardiger dan Windows!
Een linkje met recent bewijs zou op zijn plaats zijn.


Tevens kan de situatie veranderen denk aan Linus en NVidia.
Linus Torvalds Gives Nvidia the Finger. Literally
Nvidia seeks peace with Linux, pledges help on open source driver (Updated)
Torvalds gives Nvidia software thumbs up, not middle finger

Ik ben momenteel ook een grote fan van NVidia de Tegra K1 SOC de enige ARM SOC met Open Source Video drivers. De andere hebben niet eens vrin toegankelijke closed source drivers.

Ik heb zelf het volgende gevonden.
SteamOS.
Richard Stallman, head of the Free Software Foundation, is cautiously supportive.[31]
Dat duid IMO helemaal niet op wat jij vermeld.

[Reactie gewijzigd door worldcitizen op 29 december 2014 11:09]

Grappig terwijl zowel Richard Stallman zelf als Linux Torvalds JUIST expliciet aangeven dat VALVE en SteamOS goed zijn voor de ontwikkeling van Linux.

p.s. Zie dat Workcitizen al een linkje had opgenomen, thanks scheelt mij weer zoeken.

p.s. 2 In de Steam forums is Richard Stallman ook actief... vermakelijk leesvoer en onderbouwd nog eens dat hij geen tegenstander is van SteamOS en Valve.
Die man is doorgeslagen in zijn ideeën. In onze huidige (westerse) wereld kun je enkel iets doen als er brood op de plank komt. En met enkel vrije software komt er akelig weinig brood op de plank.
Je moet dan als een veredelde zwerver/freeloader door het leven willen gaan als je steeds gratis je maanden/jaren werk beschikbaar wil maken.

Iets waar volgens mij heel weinig mensen toe bereid zijn. Want waarom niet zoals vele anderen (grof) geld verdienen met je stuk software waar je jaren aan gewerkt hebt.

Zijn ideeën lijken haast wel communistisch en simpelweg niet haalbaar....
Met software op zich valt inderdaad je brood niet te verdienen. Wel met de ondersteuning op die software. Red Hat is een tamelijk winstgevend bedrijf met een aardig aantal werknemers. Het geld zit in de toekomst dan ook in die dienstverlening. Daarom ook dat bijv MS meer en meer gratis begint te doen.

Maar dan moet je afzetmarkt voldoende groot zijn om die ondersteuning aan verkocht te krijgen. Voor een veel gebruikt OS gaat dat nog, maar kijk je bijv. naar een AutoCAD, dan zie ik dat nog niet zo snel gebeuren.
Ook zal je zien dat er een flinke synergie is tussen het ontwikkelen van gratis software en het gebruik van deze software binnen een bedrijf. Dat gebruik hoeft niet eens support te zijn, maar gewoon productiviteit. Bovendien kan je dit dan ook aan collega-bedrijven verkopen als je extra inkomsten zoekt. Het open zijn van de software is daar geen belemmering voor, omdat niet jan en alleman zin heeft om er zich in te verdiepen.
Zeg maar gerust, en ik weet dat dit controversieel kan klinken: stalinistisch. Open source "projecten" zijn weliswaar vrij te forken/porten/backporten wat je maar wilt, maar uiteindelijk is er altijd binnen een project een "mainstream" waar een paar mensen de dienst uitmaken. Van de diepste kernel tot de kleinste niet-kritieke module tot de meest onbekende "oh hadden we dat ook nog nodig" module. GMP is iets waar een hoop mensen niet helemaal tevreden over zijn, en wat nu al een paar keer geforked is (de bekendste is MPIR die gek genoeg nog steeds GNU-compatibiliteit wil behouden). Helaas is er niet tengenop te knokken en zo zie je dat de commits minder snel gaan totdat een project doodvalt, en dan is er weer één project wat de status quo is. Er is vaak gewoon géén keuze, op de versie die er in een distro zit na dan. Het mag een wonder heten dat er drie (eigenlijk twee, DEB en RPM zijn toch de grootste...) package management sytemen zijn ontstaan!

En hoewel er een hoop idealistische, echt vrije, community pakketten bestaan, zijn er ook een hoop (de hele GNU omgeving eigenlijk is daar deel van...) waar alles en ook alle ideeën langs één iemand moeten en die éne iemand is knap lastig te vervangen want forks sterven een snelle dood omdat er maar geen momentum komt. En ja, daar kom ik dan bij m'n opmerking: stalinistisch, want zoals ik eerder zei: de mededeling conservatief/progressief en hoe "tolerant" of niet de omgevingen zijn... het zijn net universiteiten soms, ouwe mannetjes met héle lange tenen.

De enige manier die er lijkt te zijn om een fork succesvol te maken is om je "support-bijverdiensten-en-develop-club" bedrijfje over te zien worden genomen door Oracle. Dan weet men niet hoe snel ze de zut moeten forken!
Zeg maar gerust, en ik weet dat dit controversieel kan klinken: stalinistisch. Open source "projecten" zijn weliswaar vrij te forken/porten/backporten wat je maar wilt, maar uiteindelijk is er altijd binnen een project een "mainstream" waar een paar mensen de dienst uitmaken. Van de diepste kernel tot de kleinste niet-kritieke module tot de meest onbekende "oh hadden we dat ook nog nodig" module. GMP is iets waar een hoop mensen niet helemaal tevreden over zijn, en wat nu al een paar keer geforked is (de bekendste is MPIR die gek genoeg nog steeds GNU-compatibiliteit wil behouden). Helaas is er niet tengenop te knokken en zo zie je dat de commits minder snel gaan totdat een project doodvalt, en dan is er weer één project wat de status quo is.
Je noemt bewust een project waar de fork niet gewerkt heeft.

Libreoffice en xorg zijn twee projecten die met succes geforkt zijn. En MariaDB is een andere die steeds succesvoller is.
Er is vaak gewoon géén keuze, op de versie die er in een distro zit na dan. Het mag een wonder heten dat er drie (eigenlijk twee, DEB en RPM zijn toch de grootste...) package management sytemen zijn ontstaan!
Het blijkt dat je helemaal niets van Linux af weet.
Er zijn veel meer package manager systemen binnen Linux (RPM, DEB, Gentoo ports, pacman etc). Dit is puur op vrije keuze gebaseerd.

[Reactie gewijzigd door worldcitizen op 29 december 2014 12:05]

En met enkel vrije software komt er akelig weinig brood op de plank.
2005 belde of ze hun vooroordeel terug konden hebben.
Die stelling gaat al lang niet meer op, vooral tegenwoordig niet. Er zijn legio bedrijven die kunnen leven van support op OSS software die zij zelf geschreven hebben. En er is ook zat OSS die open source is maar voor zakelijk gebruik je vrijwillig een licentie kan aanschaffen. (Ja kan, ja)

Overigens waarom lees je vaak dat verschillende overheden van landen broncode in willen zien van gesloten software? Omdat ze de software na willen kijken omdat ze het niet vertrouwen. Maar Jan Modaal krijgt het allemaal niet te zien en moet het alleen maar kopen en gebruiken.
Bij OSS hoef je daar dus niet om te vragen, zelfs als eenvoudige tweakert kan je er zelf in kijken.

Stallman is een visionair en al veel verder dan de meeste mensen hier.
Hopelijk dat dit keer de mensen wat sneller in gaan zien dat de beste man ook deze keer weer een heel belangrijk punt heeft. Overheden zijn niet te vertrouwen.
Vrij =/= gratis.
"Maar ontwikkelaars van vrije software voelen geen drang om malafide functionaliteit toe te voegen."

Omdat hij het zegt zeker?
Ik vind dit een enorm naief statement eerlijk gezegd. Natuurlijk zitten er ook rotte appels tussen de FOSS-ontwikkelaars! Sterker nog, een hoop FOSS wordt zelfs door commerciele bedrijven ontwikkeld!
Dus de argumenten dat er druk zou zijn om malafide functionaliteit toe te voegen, gaan ook op voor FOSS.

Het enige dat je zou kunnen beargumenteren is dat het lastiger is om malafide code voor langere tijd onontdekt te houden in FOSS. Maar er zijn genoeg voorbeelden te noemen van bugs/exploits die tientallen jaren in FOSS hebben gezeten. Wie zegt dat dat geen bewuste backdoors waren?
Daarnaast, als je eenmaal de compiler weet te infecteren, dan kan het wel eens HEEL lang gaan duren totdat dat ooit ontdekt wordt: http://c2.com/cgi/wiki?TheKenThompsonHack
Echt vrije software/hardware gaat veel verder dan alleen wat source-code van applicaties.
Echt vrije software/hardware gaat veel verder dan alleen wat source-code van applicaties.
Inderdaad, het gaat over transparantie.
- transparantie van de code (open-source)
- transparantie van het ontwikkelproces: wie, wat, waar, wanneer, waarom, hoe.

Zie het als het bouwen van een woning. De muren zijn closed source, de vensters zijn open source. Als de aannemer bakstenen van slechte kwaliteit gebruikt dan kun je dit bij oplevering niet zien. Als de aannemer glas met onzuiverheden gebruikt dan kun je dit wel zien.
De realiteit is en blijft natuurlijk wel dat het gros van de mensen naar hun TV kijkt ipv de muur of het glas... Maar zoals RMS zegt :er moet maar 1 iemand de ramen inspecteren bij oplevering en aan de alarmbel te trekken. Voor closed source moeten er enkele huizen zijn ingestort.
Inderdaad, het gaat over transparantie.
- transparantie van de code (open-source)
- transparantie van het ontwikkelproces: wie, wat, waar, wanneer, waarom, hoe.
Het gaat nog wel verder dan dat.
Ook de hardware waarop je het draait, moet transparant zijn (firmware, microcode, en ook de logica in de devices zelf). En dat is geen haalbare kaart in deze tijd (wat Stallman dan blijkbaar wel weer door heeft, gezien zijn opmerkingen over telefoons).
Voor closed source moeten er enkele huizen zijn ingestort.
Pertinent onwaar.
Ten eerste: ook opensource huizen storten vaak genoeg in. Zo vaak zelfs dat het uberhaupt de vraag is of opensource enige meerwaarde heeft in de praktijk qua veiligheid, betrouwbaarheid etc.
Ten tweede, ook bij closed source worden er audits gedaan, zowel op de source code zelf (zowel intern als door externe partijen), als via onafhankelijke white hat hackers, die de code reverse-engineeren en bestuderen.
Er worden vaak genoeg bugs in closed source gevonden door dergelijk onderzoek ipv dat men bugs ontdekt door malware die er al misbruik van maakt.

[Reactie gewijzigd door Scalibq op 29 december 2014 13:04]

Het gaat nog wel verder dan dat.
<snip>
Ik denk dat er een miscommunicatie in het spel is, want ik spreek je niet tegen. BIOS/UEFI, firmware, ... is allemaal code. Ook H/W valt er wmb allemaal onder.
Pertinent onwaar.
Ten eerste: ook opensource huizen storten vaak genoeg in. Zo vaak zelfs dat het uberhaupt de vraag is of opensource enige meerwaarde heeft in de praktijk qua veiligheid, betrouwbaarheid etc.
Ontken ik niet. Ik zeg enkel dat eender wie kàn auditen bij open-source.
Dat kun je bij closed source helemaal niet.
Je zou kunnen zeggen dat de kwaliteit van open-source software stijgt naarmate het aantal developers stijgt. OpenSSL, bash, ntpd en andere code die recent het nieuws gehaald hebben zijn daar getuigen van. Aan de andere kant van het spectrum blinkt de Linux Kernel met een estimated defect/LOC ratio die een stuk onder dat van andere software ligt.

De gebruikers van open-source (en in het bijzonder de bedrijven) die die software voor belangrijke zaken gebruiken zullen eens goed moeten nadenken of ze niet beter zelf mee investeren... Zie ook het recent opgestartte Core Infrastructure Initiative.
Ten tweede, ook bij closed source worden er audits gedaan, zowel op de source code zelf (zowel intern als door externe partijen), als via onafhankelijke white hat hackers, die de code reverse-engineeren en bestuderen.
De audit van closed source is maar zo goed als de selecte groep auditors en het gebruikte proces. Een code walkthrough is bovendien geen goede audit en toch teveel gebruikt bij interne audits.

Sowieso, closed of open, enkele grote projecten hebben kans om voldoende aandacht te krijgen. Bij closed-source meestal omdat er een groot bedrijf achter staat die het zich kan permitteren, bij open-source meestal omdat de code in constante flux is en de vele auteurs mekaar onrechtstreeks continue auditen.

Dat je spreekt van reverse-engineeren is eigenlijk al een voldoende pleidooi voor open-source: waarom zou een white-hat nog moeten reverse-engineeren. Had ie de code gehad dan was ie vele malen efficienter.
Ook H/W valt er wmb allemaal onder.
Hardware is ECHT geen code hoor. Dat is een verzameling logische circuits.
Dat kun je bij closed source helemaal niet.
Jawel, en mijn voorbeeld van white hat reverse-engineering geeft dat al aan.
Je zou kunnen zeggen dat de kwaliteit van open-source software stijgt naarmate het aantal developers stijgt.
Niet bekend met de mythical man-month? http://en.wikipedia.org/wiki/The_Mythical_Man-Month
TL;DR: meer mensen toevoegen aan een software-project werkt vaak averechts.
De audit van closed source is maar zo goed als de selecte groep auditors en het gebruikte proces.
Ditzelfde geldt exact zo voor open source.
Daarbij schuilt er in open source het gevaar dat teveel mensen denken "Oh, daar heeft een ander wel naar gekeken", waardoor er in de prakijk naar sommige code in geen jaren is omgekeken.
Bij closed source is het JUIST transparant wie er naar de code kijkt, omdat die mensen expliciet toegang krijgen.
Dat je spreekt van reverse-engineeren is eigenlijk al een voldoende pleidooi voor open-source: waarom zou een white-hat nog moeten reverse-engineeren. Had ie de code gehad dan was ie vele malen efficienter.
Dan ga je ervanuit dat de compiler volledig betrouwbaar is. Het kan geen kwaad om af en toe de code ook op assembly-niveau te inspecteren. Compilers doen niet altijd precies wat je verwacht. Hetzelfde geldt ook voor libraries overigens.
Een mooi voorbeeld is memcpy(): https://bugzilla.redhat.com/show_bug.cgi?id=696096
memcpy() doet niet wat het volgens de specificaties zou moeten doen. Als jij een stuk code inspecteert die memcpy() aanroept, en je inspecteert daarbij memcpy() zelf niet (want dat is een ander project, en daar kijken anderen naar), dan ga je dus nat.
In de praktijk blijkt het gros van de open source code memcpy() structureel verkeerd te gebruiken (ze vertrouwen er dus op dat de implementatie niet volgens spec is), en dus heeft men besloten om alle bugs maar te laten zitten, want dan werkt het tenminste.
[...]


Ditzelfde geldt exact zo voor open source.
Daarbij schuilt er in open source het gevaar dat teveel mensen denken "Oh, daar heeft een ander wel naar gekeken", waardoor er in de prakijk naar sommige code in geen jaren is omgekeken.
Bij closed source is het JUIST transparant wie er naar de code kijkt, omdat die mensen expliciet toegang krijgen.
Heb je voor de aardigheid een keer gekeken hoe het bij closed en open source werkt?

- Bij opensource wordt bij grote georganiseerde projecten iedere commit reviewed. Bij closed source wordt de code pas aan het einde geaudit.
- Bij closed source wordt meestal niet meer geaudit omdat dit al gedurende review gedaan is. Waardoor de code nauwkeuriger ingezien wordt. Reviewen van grote lappen code werkt niet daar wordt je letterblind van.
- Tevens wordt commerciële software alleen maar intern reviewed, dan zullen bewuste backdoors echt niet gemeld worden.
- Bij open source software kan bij een vreemde gedraging door iedere gebruiker de code ingezien worden terwijl dit bij closed source software niet mogelijk is waardoor defecten veel moeilijker gevonden kunnen worden.
- Bij commerciële software is tijd geld daar zal niet ongelimiteerd tijd zijn om code te reviewen.
[...]


Dan ga je ervanuit dat de compiler volledig betrouwbaar is. Het kan geen kwaad om af en toe de code ook op assembly-niveau te inspecteren. Compilers doen niet altijd precies wat je verwacht. Hetzelfde geldt ook voor libraries overigens.
Een mooi voorbeeld is memcpy(): https://bugzilla.redhat.com/show_bug.cgi?id=696096
memcpy() doet niet wat het volgens de specificaties zou moeten doen. Als jij een stuk code inspecteert die memcpy() aanroept, en je inspecteert daarbij memcpy() zelf niet (want dat is een ander project, en daar kijken anderen naar), dan ga je dus nat.
In de praktijk blijkt het gros van de open source code memcpy() structureel verkeerd te gebruiken (ze vertrouwen er dus op dat de implementatie niet volgens spec is), en dus heeft men besloten om alle bugs maar te laten zitten, want dan werkt het tenminste.
Ik zie het probleem niet t.a.v. memcpy, dit is een bewuste keuze t.o.v. een "hidden feature". Zoiets kan ook binnen gesloten software gebeuren. En bij gesloten software heb je vaak helemaal geen inzicht in de code van een library omdat een andere partij die aanlevert zoals de bouwer van de compiler.

Binnen open source kun en mag de source code van de compiler inzien. Je hoeft echt niet te verwachten dat je als software bureautje de code van de Microsoft compiler in mag zien.
Ik zie het probleem niet t.a.v. memcpy, dit is een bewuste keuze t.o.v. een "hidden feature".
Het WAS een onbewuste keuze. Door wat optimalisaties kwam men erachter dat de oorspronkelijke versie eigenlijk een memmove() was, en dat de meeste software ook gewoon memcpy() aanriep in gevallen waar ze memmove() moesten aanroepen.
Nu hebben ze bewust gekozen om dus niet volgens de C-standaard te werken, maar hun eigen suboptimale memcpy() met hidden features te handhaven.
Zoiets kan ook binnen gesloten software gebeuren.
Daar ging het niet om. Het punt was dat je er bij een code-review niet vanuit kunt gaan dat library-calls volgens de spec werken, wat goed reviewen op source-code niveau dus een stuk omslachtiger maakt dan men op het eerste gezicht denkt.
En bij gesloten software heb je vaak helemaal geen inzicht in de code van een library omdat een andere partij die aanlevert zoals de bouwer van de compiler.
Ik heb volgens mij bij alle compilers die ik ooit gebruikt heb, de source code van de C-library erbij gekregen. Microsoft levert die sowieso mee.
Binnen open source kun en mag de source code van de compiler inzien. Je hoeft echt niet te verwachten dat je als software bureautje de code van de Microsoft compiler in mag zien.
Het is dan ook compleet ondoenlijk om een compiler te gaan uitpluizen terwijl je eigenlijk code zou moeten schrijven. Daarom wordt er in de praktijk ook zo weinig aan auditen van open source gedaan.
Daarom wordt er in de praktijk ook zo weinig aan auditen van open source gedaan.
Auditen is IMO niet nodig binnen opensource. Bij grote projecten wordt alle code voordat deze toegestaan wordt gereviewed. Reviewen van lappen van code is IMO helaal niet zinvol.
De meeste problemen van software komen aan het licht bij het gebruik van de code.
Bij Open Source code kan het probleem door iedereen debugged worden.
Terwijl dit bij closed source code niet mogelijk is.
Dan kun je bij de software fabrikant een bug reportje inschieten als je geluk hebt, als je een support contract hebt.

[Reactie gewijzigd door worldcitizen op 29 december 2014 14:54]

[...]
Hardware is ECHT geen code hoor. Dat is een verzameling logische circuits.
Hardware wordt ook gewoon gedesigned. Tijdens die fase wordt er code gebruikt zoals Verilog of VHDL. Code dus.
[...]
Jawel, en mijn voorbeeld van white hat reverse-engineering geeft dat al aan.
En open-source maakt reverse-engineering overbodig, dus is het voor een veel grotere groep mogelijk om dit te doen.
[...]
Niet bekend met de mythical man-month? http://en.wikipedia.org/wiki/The_Mythical_Man-Month
TL;DR: meer mensen toevoegen aan een software-project werkt vaak averechts.
Helemaal bekend mee, maar daar gaat het ook helemaal niet over.
Mythical man month is iets wat over planning gaat. Hier gaat het over reviews en audits. Je lijkt te willen argumenteren om te kunnen argumenteren.
[...]
Ditzelfde geldt exact zo voor open source.
Helaas is dit niet waar.
Bij een closed-source audit, huur je een bedrijf in (of stel je een intern team samen). Je audit is zo goed als die kleine groep.
In open-source kan eender wie auditen. Misschien heeft iemand net een crash gehad en neust die even rond in de code of is ie nieuwsgierig. Ik doe dit ook wel eens (bvb rsyslogd code is een giant mess waarvan wsch enkel de auteur zelf nog iets kan maken).
Daarbij schuilt er in open source het gevaar dat teveel mensen denken "Oh, daar heeft een ander wel naar gekeken", waardoor er in de prakijk naar sommige code in geen jaren is omgekeken.
Daar schuilt inderdaad een gevaar. Dat iemand het kàn wil nog niet zeggen dat het ook zo is. Daarom ook dat ik zeg dat grotere projecten typisch hogere kwaliteit krijgen doordat veel mensen de codebase onderhouden, elk vanuit hun eigen standpunt/expertise.
Zoals ik ook al zei: dit is idem voor closed-source, hoewel tijdsdruk daar een beperkende factor kan spelen (don't fix what ain't broken, especially if you need to get the job done fast)
Bij closed source is het JUIST transparant wie er naar de code kijkt, omdat die mensen expliciet toegang krijgen.
Transparant? Weet jij of pakweg Microsoft's Windows, Adobe's Flash of Oracle's Java al ooit een audit gehad hebben? Niks transparant dus.
[...]
Dan ga je ervanuit dat de compiler volledig betrouwbaar is. Het kan geen kwaad om af en toe de code ook op assembly-niveau te inspecteren. Compilers doen niet altijd precies wat je verwacht. Hetzelfde geldt ook voor libraries overigens.
Dat is toch helemaal niet ter zake? Dat zijn aparte structuren met eigen processen, etc.
Maar om op het punt in te gaan: review jij de code van elk closed-source project wat je gebruikt? Oh, right - je kan niet, het is closed.
Een mooi voorbeeld is memcpy(): https://bugzilla.redhat.com/show_bug.cgi?id=696096
memcpy() doet niet wat het volgens de specificaties zou moeten doen. Als jij een stuk code inspecteert die memcpy() aanroept, en je inspecteert daarbij memcpy() zelf niet (want dat is een ander project, en daar kijken anderen naar), dan ga je dus nat.
In de praktijk blijkt het gros van de open source code memcpy() structureel verkeerd te gebruiken (ze vertrouwen er dus op dat de implementatie niet volgens spec is), en dus heeft men besloten om alle bugs maar te laten zitten, want dan werkt het tenminste.
En hier geef je al meteen aan waarom bvb ook de Windows API zo written in stone is. Tal van bugs, maar ze blijven zitten want veel code zou breken.

Closed source is hier niet anders in.

Ik begrijp trouwens niet waarom je met me begint te discusseren, mijn oorspronkelijke reactie was als aanvulling bedoeld.
Hardware wordt ook gewoon gedesigned. Tijdens die fase wordt er code gebruikt zoals Verilog of VHDL. Code dus.
Uhhhh.... niet per se.
Vooral oudere hardware werd vaak 'met de hand' ontworpen (er was immers niets anders).
Dit is het zelfde als zeggen: "Alle software wordt in een hogere programmeertaal geschreven".
Zeker niet.
En open-source maakt reverse-engineering overbodig, dus is het voor een veel grotere groep mogelijk om dit te doen.
Overbodig zeker niet.
Helemaal bekend mee, maar daar gaat het ook helemaal niet over.
Mythical man month is iets wat over planning gaat. Hier gaat het over reviews en audits.
Het principe blijft hetzelfde: of het nu om het ontwikkelen van software gaat of het reviewen/auditen ervan. Meer mensen erop zetten levert niet noodzakelijk ook betere resultaten. Je moet het coordineren, en daar gaat overhead in zitten (als iedereen hetzelfde stukje zit te auditen, schiet het ook niet op natuurlijk).

quote]In open-source kan eender wie auditen.[/quote]

Wat dus ook best een kleinere groep kan zijn dan bij een closed-source audit.
Ook heb je geen idee wat de kwaliteit van dergelijke audits is, waar je bij een third-party mensen inhuurt met de juiste diploma's en ervaring.
Oa Red-Hat doet dit trouwens ook: zij huren ook third-party mensen in voor audits. Zullen ze niet voor niets doen.
Transparant? Weet jij of pakweg Microsoft's Windows, Adobe's Flash of Oracle's Java al ooit een audit gehad hebben? Niks transparant dus.
Ten eerste bedoelde ik transparantie binnen het bedrijf. Men weet precies welke code wanneer door wie bekeken is, en dus ook welke code nog NIET bekeken is, en waar dus een audit handig is.
Ten tweede, ja, Microsoft's code is zeker geaudit.
Destijds is de source-code van MS gelekt, en toen heeft MS een grootschalige audit gedaan, en structurele veranderingen doorgevoerd in hoe men code ontwikkelt: http://www.computerworld....o-audit-windows-code.html
Dit begon vorm te krijgen in XP SP2.

Ook is Windows NT gecertificeerd tot C2-niveau door de DoD: http://msdn.microsoft.com/en-us/library/cc767092.aspx
At the C2 level, the vendor must provide detailed documentation to show that the features are properly implemented. This includes design documentation, information on lifecycle management, testing procedures, and other information. In addition to providing this information, Microsoft chose to also provide full source code as part of the evaluation.
Dus ja.
Dat is toch helemaal niet ter zake? Dat zijn aparte structuren met eigen processen, etc.
Tuurlijk wel. Als jij code bouwt, dan moet je ook je compiler kunnen vertrouwen. Anders weet je nog niet zeker of de daadwerkelijke applicatie wel doet wat in het deel van de code staat dat je bekeken hebt.
Maar om op het punt in te gaan: review jij de code van elk closed-source project wat je gebruikt? Oh, right - je kan niet, het is closed.
En dus? Ik reverse-engineer wel eens closed-source code ja... Open source code kijk ik ook zelden in. Dus voor mij maakt het weinig verschil.
En hier geef je al meteen aan waarom bvb ook de Windows API zo written in stone is. Tal van bugs, maar ze blijven zitten want veel code zou breken.
Ik weet dat je graag Windows wil bashen, maar dat was het argument niet.
Het argument was: je moet OOK je libraries auditen, want je kunt er niet vanuit gaan dat die doen wat de specs zeggen. Dus je kunt er niet vanuit gaan dat de code doet wat je denkt dat het doet, als je alleen naar de applicatie-code kijkt, en niet naar de libraries die aangeroepen worden.
Ik begrijp trouwens niet waarom je met me begint te discusseren, mijn oorspronkelijke reactie was als aanvulling bedoeld.
Ik vond het geen goede aanvulling, dus reageerde ik daarop. Vervolgens maak jij er een flauw welles/nietes-spelletje van.
[...]
Uhhhh.... niet per se.
Vooral oudere hardware werd vaak 'met de hand' ontworpen (er was immers niets anders).
Dit is het zelfde als zeggen: "Alle software wordt in een hogere programmeertaal geschreven".
Zeker niet.
Stop met je 'gelijk' te willen halen. Compleet irrelevant hoe ze dingen 30 jaar geleden deden. Vandaag hebben we ook compilers die ze toen niet hadden
[...]
Overbodig zeker niet.
Geef dan een argument. Als ik de source heb, waarom zou ik dan nog reverse-engineeren?
[...]
Het principe blijft hetzelfde: of het nu om het ontwikkelen van software gaat of het reviewen/auditen ervan. Meer mensen erop zetten levert niet noodzakelijk ook betere resultaten. Je moet het coordineren, en daar gaat overhead in zitten (als iedereen hetzelfde stukje zit te auditen, schiet het ook niet op natuurlijk).
Helaas is de mythical man month hier niet toepasbaar. Die gaat over inwerken en vertrouwd raken met een project.
Wat jij wil is de economische wet van diminishing returns.
Wat dus ook best een kleinere groep kan zijn dan bij een closed-source audit.
'Free' gaat over de gebruiker van de code, niet over de ontwikkelaar. Daarmee vergeleek ik het dus ook.
Ik als eindgebruiker moet reverse-engineeren als ik closed-source wil auditen. Ik kan echter vrijelijk de source code van eender welk open-source project bekijken.
De groep die de nodige kwaliteit bezit is vele malen groter in het tweede geval.
Ook heb je geen idee wat de kwaliteit van dergelijke audits is, waar je bij een third-party mensen inhuurt met de juiste diploma's en ervaring.
Oa Red-Hat doet dit trouwens ook: zij huren ook third-party mensen in voor audits. Zullen ze niet voor niets doen.
Ik bepaal wel waar ik wel en niet een idee van heb. Ad hominem attacks worden niet geapprecieerd aan deze kant van het internet.
De reden van externe audits is vaak omdat internet audits gedaan worden door mensen die het project kennen en die dus al vast zitten in de denkwijzen die ook tijdens het designen gevolgd werden. Een frisse blik is dan veel kostbaarder, maar dat wist je zelf zeker ook wel.
[...]
Ten eerste bedoelde ik transparantie binnen het bedrijf. Men weet precies welke code wanneer door wie bekeken is, en dus ook welke code nog NIET bekeken is, en waar dus een audit handig is.
Nogmaals: Free gaat over de gebruiker, niet over de developer.
Ten tweede, ja, Microsoft's code is zeker geaudit.
Destijds is de source-code van MS gelekt, en toen heeft MS een grootschalige audit gedaan, en structurele veranderingen doorgevoerd in hoe men code ontwikkelt: http://www.computerworld....o-audit-windows-code.html
Dit begon vorm te krijgen in XP SP2.

Ook is Windows NT gecertificeerd tot C2-niveau door de DoD: http://msdn.microsoft.com/en-us/library/cc767092.aspx
[...]
Dus ja.
Dat Microsoft's code geaudit was, dat is inderdaad gekend. Het is ook gekend dat overheden en andere inzage kunnen krijgen om zich er van te verzekeren dat er geen backdoors etc in zitten. (hoewel het waarschijnlijk eerder gebruikt wordt om exploits te zoeken)
Maar bij Flash en Java heb ik grote twijfels.
[...]
Tuurlijk wel. Als jij code bouwt, dan moet je ook je compiler kunnen vertrouwen. Anders weet je nog niet zeker of de daadwerkelijke applicatie wel doet wat in het deel van de code staat dat je bekeken hebt.
In open-source kringen is hier veel rond aan het gebeuren. Niet alleen compiler verificatie, maar ik verificatie dat hetgeen je download in binary form ook overeenstemt met de code die je erbij kan krijgen.
Ik weet dat je graag Windows wil bashen, maar dat was het argument niet.
Sorry, maar waar was ik Windows aan het bashen? Ik zie het echt niet. Ik gaf enkel 1 van de meeste gekende API's aan die met exact datzelfde probleem zitten: bug-for-bug compatibility over versies heen. Microsoft's sterkste punt is meteen ook hun grootste zwakte.
Zie maar hoe bvb Wine dit ook ondervindt. Bugs moeten implementeren omdat bepaalde software anders niet werkt.
Ik vond het geen goede aanvulling, dus reageerde ik daarop. Vervolgens maak jij er een flauw welles/nietes-spelletje van.
Dit is nu al de thread op T.net dat je elk argument al dan niet moedwillig verdraaid. Zo kunnen we blijven heen en weer gaan. Het zou alvast helpen mocht je on-topic reageren, niet andermans woorden verdraaien en niet in elk argument een persoonlijke aanval zien die je compleet naast de kwestie móet beantwoorden.

Exit discussie, ik hou alvast de eer aan mezelf. Jammer dat er geen 'ignore' knop op T.net is, van mij verdien je ze.
Stop met je 'gelijk' te willen halen. Compleet irrelevant hoe ze dingen 30 jaar geleden deden. Vandaag hebben we ook compilers die ze toen niet hadden
Tsja, je argument is gewoon niet goed.
We hebben het hier over transparantie van software en hardware. Dan moet je er dus OOK rekening mee houden dat het mogelijk is om software te schrijven zonder gebruik te maken van een compiler, of hardware te ontwerpen zonder gebruik te maken van een HDL of iets. En als we heb hebben over het verbergen van backdoors etc, dan kun je verwachten dat men dat op een dergelijke manier zal doen.
Dus in deze context is dat ZEKER relevant.
Geef dan een argument. Als ik de source heb, waarom zou ik dan nog reverse-engineeren?
Zie hierboven. Naast de source moet je ook kijken wat de compiler ervan bakt, en wat de hardware ermee doet, als je echt compleet inzicht wil hebben, en zeker wil weten dat er geen backdoors zijn.
Ik bepaal wel waar ik wel en niet een idee van heb. Ad hominem attacks worden niet geapprecieerd aan deze kant van het internet.
Ik bedoelde 'je' in het algemeen (in de zin van: je weet niet wie er op welk moment naar welke code kijkt, en in hoeverre hun oordeel daarover waarde heeft), maar leuk dat je je alles zo persoonlijk aantrekt.
Helaas is de mythical man month hier niet toepasbaar. Die gaat over inwerken en vertrouwd raken met een project.
En waarom zou dat bij een code review/audit anders zijn? Je moet nog steeds jezelf inwerken en vertrouwd maken met het project.
Sorry, maar waar was ik Windows aan het bashen? Ik zie het echt niet.
Je haalt de Windows-API erbij, terwijl dat nergens voor nodig is. Wat ik zei was al algemeen geldend, dus ook voor de Windows-API. Het feit dat je die API specifiek noemt, komt dus over als Windows-bashing.
"Maar ontwikkelaars van vrije software voelen geen drang om malafide functionaliteit toe te voegen."

Omdat hij het zegt zeker?
Ik vind dit een enorm naief statement eerlijk gezegd. Natuurlijk zitten er ook rotte appels tussen de FOSS-ontwikkelaars! Sterker nog, een hoop FOSS wordt zelfs door commerciele bedrijven ontwikkeld!
Dus de argumenten dat er druk zou zijn om malafide functionaliteit toe te voegen, gaan ook op voor FOSS.
Iemand die vrije software ontwikkelaar wil blijven zal geen malafide functionaliteit toevoegen.
Omdat hij/zij in dat geval in geen enkele vrij software project meer toegelaten zal worden of je merge requests niet meer geaccepteerd worden.
Het enige dat je zou kunnen beargumenteren is dat het lastiger is om malafide code voor langere tijd onontdekt te houden in FOSS. Maar er zijn genoeg voorbeelden te noemen van bugs/exploits die tientallen jaren in FOSS hebben gezeten. Wie zegt dat dat geen bewuste backdoors waren?
Daarnaast, als je eenmaal de compiler weet te infecteren, dan kan het wel eens HEEL lang gaan duren totdat dat ooit ontdekt wordt: http://c2.com/cgi/wiki?TheKenThompsonHack
Echt vrije software/hardware gaat veel verder dan alleen wat source-code van applicaties.
Heb je "The Ken Thompson Hack" gelezen.
Deze is van voor het publieke internet tijdperk.
En in de praktijk alleen in commerciële software gezien.
In August 2009 a virus utilizing the Ken Thompson hack was seen in the wild. It infected Delphi 4 through 7 and applications genereated with it. http://www.h-online.com/s...environment--/news/114031
Iemand die vrije software ontwikkelaar wil blijven zal geen malafide functionaliteit toevoegen.
Omdat hij/zij in dat geval in geen enkele vrij software project meer toegelaten zal worden of je merge requests niet meer geaccepteerd worden.
NAIEF!
Vrijwel alles gaat alleen via internet, met emails en Git-commits etc.
Wie controleert of iemand echt is wie hij zegt?
Het is kinderlijk eenvoudig om onder een valse naam merge requests te doen. Komen ze erachter, en blokkeren ze je... dan ga je gewoon onder de volgende valse identiteit verder.
Deze is van voor het publieke internet tijdperk.
En wat heeft dat ermee te maken? Gebruiken we tegenwoordig geen compilers meer?
Het is al een aantal keren voorgekomen dat de FTP van een grote linux distro gehackt is, en dat er besmette packages verspreid werden.
Wie zegt dat we niet al jaren met een geinfecteerde gcc werken, naar binnen gesmokkeld door een hack die NIET ontdekt is?
[...]


NAIEF!
Vrijwel alles gaat alleen via internet, met emails en Git-commits etc.
Wie controleert of iemand echt is wie hij zegt?
Het is kinderlijk eenvoudig om onder een valse naam merge requests te doen. Komen ze erachter, en blokkeren ze je... dan ga je gewoon onder de volgende valse identiteit verder.
Merge requests, zeker van nieuwe/onbekende personen worden niet zomaar geaccepteerd.
De code wordt ten eerste gecontroleerd, daarna de persoon bij de code.
Volgens mij denk je dat de ontwikkelaars die de code reviewen geen kennis van zaken hebben.
[...]


En wat heeft dat ermee te maken? Gebruiken we tegenwoordig geen compilers meer?
Het is al een aantal keren voorgekomen dat de FTP van een grote linux distro gehackt is, en dat er besmette packages verspreid werden.
Wie zegt dat we niet al jaren met een geinfecteerde gcc werken, naar binnen gesmokkeld door een hack die NIET ontdekt is?
Alles ten eerste was het een proof of concept. In de tijd voor het publieke internet waren er veel minder ogen die de software zagen.

Niemand kan met 100% zekerheid zeggen dat we niet met een geïnfecteerde gcc werken maar de kans is erg klein.
De kans dat er in commerciële software backdoors zitten is veel groter dat heeft Edward Snowden wel duidelijk gemaakt.

Dat vrije software als veiligere software gezien mag worden lijkt me logisch.
Volgens mij denk je dat de ontwikkelaars die de code reviewen geen kennis van zaken hebben.
Wat heeft dit met kennis van zaken te maken?
Het screenen van een persoon gaat wel iets verder dan wat een gemiddelde software-ontwikkelaar kan doen. Dat is meer iets voor de overheid oid.
Zoals ik dus al zei: het is niet zo heel moeilijk om jezelf een valse identiteit aan te meten (evt inclusief een 'online presence' met opensource projecten hier en daar, forum posts en noem maar op), en zo de ontwikkelaars om de tuin te leiden.
Niemand kan met 100% zekerheid zeggen dat we niet met een geïnfecteerde gcc werken maar de kans is erg klein.
Hoe weet je dat de kans erg klein is?
Ik heb namelijk geen idee hoe groot die kans zou zijn.
Dat vrije software als veiligere software gezien mag worden lijkt me logisch.
Mij niet... 'Potentieel veiliger', dat is nog wel verdedigbaar, maar per definitie veiliger, zeker niet. Dat is nu juist de valkuil van open source. Het wordt overal naar binnen gereden onder het mom van 'het is veiliger'... en dan komen er toch grote exploits naar boven.
[...]


Wat heeft dit met kennis van zaken te maken?
Het screenen van een persoon gaat wel iets verder dan wat een gemiddelde software-ontwikkelaar kan doen. Dat is meer iets voor de overheid oid.
Zoals ik dus al zei: het is niet zo heel moeilijk om jezelf een valse identiteit aan te meten (evt inclusief een 'online presence' met opensource projecten hier en daar, forum posts en noem maar op), en zo de ontwikkelaars om de tuin te leiden.
Het gaat minder om de persoon maar vooral om de code.
Je leid via Forums geen ontwikkelaars om de tuin ze zullen de code nog steeds in zien voor ze deze toestaan.
[...]


Hoe weet je dat de kans erg klein is?
Ik heb namelijk geen idee hoe groot die kans zou zijn.
Heel klein omdat er veel mensen de code inzien. Tevens wordt de code reviewed voordat deze geaccepteerd wordt (zeker in projecten zoals gcc en de Linux Kernel). Tevens zijn er mensen die hun code debuggen en bij problemen de hele keten onderzoeken. Waardoor gcc zaken al lang opgevallen waren.
[...]


Mij niet... 'Potentieel veiliger', dat is nog wel verdedigbaar, maar per definitie veiliger, zeker niet. Dat is nu juist de valkuil van open source. Het wordt overal naar binnen gereden onder het mom van 'het is veiliger'... en dan komen er toch grote exploits naar boven.
Er bestaat geen volledig veilige software. Er er ontstaan steeds nieuwe inzichten. Denk bijvoorbeeld in het verleden aan buffer overflows.
Feit is dat jij als gebruiker geen closed source in kunt zien. Dan moet je maar op de fabrikant vertrouwen.

Zie bijvoorbeeld: nieuws: 'NSA betaalde beveiligingsbedrijf RSA voor inbouwen backdoor'
t.a.v. mijn opmerking t.a.v. Edward Snowden.

Zoiets zou veel sneller opgemerkt zijn in Open Source software.
Het gaat minder om de persoon maar vooral om de code.
Je leid via Forums geen ontwikkelaars om de tuin ze zullen de code nog steeds in zien voor ze deze toestaan.
Het is prima mogelijk om subtiele bugs te introduceren hoor. Code waar op het eerste gezicht niets vreemds aan te zien is... Maar als je een bepaalde functie aanroept met een speciale parameter, waarbij je een net wat te groot buffertje meegeeft of iets... dan gebeuren er leuke dingen.
Dingen die je niet aan de code zelf kunt zien, maar pas als je de gecompileerde vorm bestudeert.
Heel klein omdat er veel mensen de code inzien.
Hoe weet je dat?
Heb je ergens cijfers? Statistieken?
Daarnaast... een miljoen apen die naar de code kijken, halen er ook geen bugs uit. 1 slim iemand die op de juiste plek kijkt, doet dat wel.
Je kunt er gewoon niets over zeggen.
Zoiets zou veel sneller opgemerkt zijn in Open Source software.
Wederom, daar kun je niets over zeggen.
[...]


Hoe weet je dat?
Heb je ergens cijfers? Statistieken?
Daarnaast... een miljoen apen die naar de code kijken, halen er ook geen bugs uit. 1 slim iemand die op de juiste plek kijkt, doet dat wel.
Je kunt er gewoon niets over zeggen.
A.u.b de hele tekst quoten waar ik het over had.
Het gaat niet alleen over code inzien. Het gaat ook over vreemde gedragingen die dan direct kunt debuggen omdat je de code hebt. Dit gaat bij gesloten software niet. Daar zit meestal zelfs geen debug code in.
[...]


Wederom, daar kun je niets over zeggen.
Natuurlijk wel, want voorbedachte backdoor code hoef je niet te verbergen, of via compliceerde code. RSA kan een routine schrijven met commentaar.
"Malicious NSA code"
En dan recht toe rechtaan de gevraagde code.
Zoiets is onmogelijk binnen opensource code. Die zal nooit geaccepteerd worden.

[Reactie gewijzigd door worldcitizen op 29 december 2014 14:36]

Natuurlijk wel, want voorbedachte backdoor code hoef je niet te verbergen, of via compliceerde code. RSA kan een routine schrijven met commentaar.
"Malicious NSA code"
En dan recht toe rechtaan de gevraagde code.
Zoiets is onmogelijk binnen opensource code. Die zal nooit geaccepteerd worden.
En je denkt dat dat met closed source wel kan?
Lijkt me niet.
Als je het zo overduidelijk maakt, kan dus IEDERE medewerker van het bedrijf met toegang tot de code (en bij een bedrijf als Microsoft zijn dat er nog wel wat) zien dat er een NSA backdoor in zit. Denk je echt dat dat jarenlang goed gaat? Dat er niet ergens een Snowden opstaat die zegt: "Hee, wacht eens even! Ik ga deze code publiek maken, want wat hier gebeurt, dat kan niet!".

Het lijkt mij dat, ALS een bedrijf ergens een backdoor opneemt, dat ze dit goed vermommen, want ook bij closed source weet je maar nooit wie er meekijkt in de code.
[...]


En je denkt dat dat met closed source wel kan?
Lijkt me niet.
Als je het zo overduidelijk maakt, kan dus IEDERE medewerker van het bedrijf met toegang tot de code (en bij een bedrijf als Microsoft zijn dat er nog wel wat) zien dat er een NSA backdoor in zit. Denk je echt dat dat jarenlang goed gaat? Dat er niet ergens een Snowden opstaat die zegt: "Hee, wacht eens even! Ik ga deze code publiek maken, want wat hier gebeurt, dat kan niet!".

Het lijkt mij dat, ALS een bedrijf ergens een backdoor opneemt, dat ze dit goed vermommen, want ook bij closed source weet je maar nooit wie er meekijkt in de code.
Daar zegt je het precies, tot iemand als Snowden opstaat, die zijn er helaas niet veel. De meeste mensen kijken ook wel uit om zoiets te doen. Als klokkenluider heb je meestal geen leven meer, zeker als het om een veiligheidsdienst gaat.

Ik zou het ook niet melden en zo snel mogelijk bij zo'n bedrijf vertrekken. Ik heb uiteindelijk ook een en mijn verantwoordelijkheid naar hun toe gezin.
Gelukkig werk ik in een open source bedrijf, daarom is de kans dat ik in zo'n situatie kom gelukkig heel erg klein.

Daarom heb ik veel respect voor mensen zoals Snowden is dit wel durven.

[Reactie gewijzigd door worldcitizen op 29 december 2014 15:02]

Daar zegt je het precies, tot iemand als Snowden opstaat, die zijn er helaas niet veel.
Bij de NSA niet nee, dat lijkt me logisch, daar wordt specifiek op geselecteerd.
Maar de gemiddelde programmeur bij een Microsoft oid is natuurlijk een heel ander verhaal.
[...]


Bij de NSA niet nee, dat lijkt me logisch, daar wordt specifiek op geselecteerd.
Maar de gemiddelde programmeur bij een Microsoft oid is natuurlijk een heel ander verhaal.
Ik denk zelfs een gemiddelde Microsoft programmeur.
Je zult om je opmerking te onderbouwen een deel van de code moeten publiceren. Daar zit bijvoorbeeld copyright op, waar Microsoft zich op kan beroepen.
Een rechtzaak van Microsoft ga je als klein burgertje echt niet winnen.
Daarom zal het overgrote deel van de Microsoft/Oracle/Cisco etc. programmeurs dit ook echt niet gaan melden.
Ze zullen waarschijnlijk op zoek gaan naar ander werk als ze zich hier niet mee kunnen verenigen.
Je zult om je opmerking te onderbouwen een deel van de code moeten publiceren. Daar zit bijvoorbeeld copyright op, waar Microsoft zich op kan beroepen.
Sorry, maar dit is echt een non-argument.
Snowden heeft niet alleen met copyright te maken gehad, maar ook met informatie die als 'classified' te boek staat. Die heeft dus met heel wat meer problemen te maken dan wat een Microsoft-programmeur ooit tegen zou gaan komen.
Zo kan Snowden vervolgd worden voor landverraad. Dat risico zul je bij MS niet lopen.
Een rechtzaak van Microsoft ga je als klein burgertje echt niet winnen.
Hoeft ook niet. Er zijn namelijk ook wetten die klokkenluiders beschermen. Als jij een goede reden hebt om het copyright van MS te schenden (zoals bv illegale praktijken van de staat), dan heeft MS geen poot om op te staan.
Sowieso kan het altijd nog anoniem gedaan worden. In het verleden is vaak genoeg een pakket informatie anoniem naar bv een redactie van een krant oid gestuurd.
uhh.. vrije software zorgt helemaal niet voor dat je gedrag niet wordt 'verraden'. Het ZOU kunnen ja.. Maar niemand controleert echt alle 'vrije software' en genoeg mensen downloaden ook deze 'vrije software' van andere bronnen waardoor deze al niet meer te vetrouwen is.
Ja 'vrije software' KAN veiliger zijn, maar dat is verre van een garantie.. Maar IMHO is hier natuurlijk wel weer het standaard 'wij van wc-eend' van toepassing...
+1 terechte opmerking, in de praktijk blijkt inderdaad ook niet iedere regel in vrije software gecontroleerd te worden.

Stallman is echter hierover in bovenstaand artikel nog wel enigzins genuanceerd met zijn uitspraak: "Maar het zorgt wel voor een soort collectieve controle. Er hoeft maar één iemand malafide functionaliteit aan te treffen en een nieuwe versie te publiceren.". Hij stelt dus niet dat het perfect is, alleen beter dan gesloten software en daar kan ik mij wel in vinden.

Ik vermoed trouwens dat Stallman prima beseft dat het openstellen van software nog geen volledige oplossing is en dat er meer nodig is om veilig software op te leveren.
Free as in freedom!

Waarlijk de koning van /g/

On-topic:
RMS bedoelt het altijd wel goed, maar zijn manier van overbrengen en zijn obsessief gedrag rond 'vrije' software maken het niet bepaald aantrekkelijk.
Ook geeft hij niets om design, een klassiek voorbeeldje is zijn website:
https://stallman.org/

Op zijn site zie je topics als "Don't do business with Apple & Amazon".
Als we even serieus zijn, welke investeerder zou hiermee in zee willen gaan? Ik zie bepaalde risk ventures dit wel nog doen maar ik betwijfel het dat RMS dit ziet zitten.

[Reactie gewijzigd door Synthax op 29 december 2014 11:09]

Ik geloof niet dat RMS erg veel interesse heeft om zaken te doen met "risk ventures".

Verder is het natuurlijk een wereldvreemde weirdo, maar als het puntje bij paaltje komt heeft hij wel altijd gelijk.

Behalve natuurlijk met betrekking tot EMACS want _O_ vim _O_.

[Reactie gewijzigd door zovty op 29 december 2014 12:30]

Ik heb dat emacs vs vim gedoe nooit begrepen, heb ze beide geprobeerd maar ik vond dat command line geklungel in een text editor nogal vreemd...
Schiet me nu niet dood aub
Ik denk dat wanneer software dat (nog) niet veel gebruikt wordt, minder wordt gemonitord, maar zodra de interesse, van de samenleving, in het gebruik gaat toenemen, Er wel zal worden overgegaan om die software ook de surveilleren. Dat had je indertijd ook met Linux, die werd nog niet zo afgetapt, maar nu het gebruik van Linux toeneemt, zal dat wel de interesse van veiligheidsdiensten opwekken.
Wat een nieuws zeg. Dit is toch al lang bekend? Als morgen een belangrijke wetenschapper op een conferentie verteld dat water nat is, komt er dan ook een artikel over op tweakers?
+3, het eerste wat ik dacht, maar aan de andere kant gezien de recente ontwikkelingen ook niet verkeerd om eens te belichten op een bekende site als Tweakers. Persoonlijk zou ik graag zien dat onze overheid ook wat actiever wordt tegen cyber spionage. Ander overheden willen inzicht in de broncode van Windows of nemen gewoon een Linux distro, willen de data van hun burgers opgeslagen hebben in hun eigenland, etc. NL loopt een beetje achteraan in dit rijtje.

p.s. NL heeft trouwens jaren terug al wel aangegeven Opensource meer te gaan gebruiken bij de overheid instanties, maar in de praktijk komt daar nog bijna niets van terecht.
Ja, maar met een titel zoals
DARPA onderzoekers waarschuwen: Diwaterstofmonoxide gevaar voor Network Address Translation.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True