'Opensource bevat minder fouten dan propriëtaire code'

Opensourcecode bevat gemiddeld een gelijk aantal of zelfs minder fouten dan propriëtaire code. Dat stelt een onderzoeksorganisatie die miljoenen regels broncode van zowel opensourcesoftware als gesloten software testte op fouten.

Het onderzoek is uitgevoerd door de Coverity-organisatie en beschreven in het Scan Open Source Integrity Report. Tijdens het onderzoek werden 37 miljoen regels code van opensourcesoftware gecontroleerd op fouten, evenals 300 miljoen regels code van gesloten softwareproducten. Voor de opensourceselectie werden 45 projecten onderzocht, met elk gemiddeld 832.000 regels code. Daarnaast werd propriëtaire code nagelopen die was aangedragen door 41 anonieme leden van de Coverity-organisatie.

Uit de analyse bleek dat de opensourcebroncode gemiddeld 0,45 fouten per duizend regels bevatte, terwijl bij propriëtaire code 0,64 fouten per duizend regels werden aangetroffen. Daaruit zou blijken dat opensourceprojecten gemiddeld minder fouten bevatten, al scoren beide categorieën onder de 1.0, het gemiddelde aantal gemaakte fouten in software.

Verder stelt Coverity dat de broncode van drie opensourceprojecten een zeer hoge kwaliteit heeft: Linux 2.6, PHP 5.3 en PostgreSQL 9.1, met een respectievelijke foutdichtheid van 0,62, 0,2 en 0,21. Dergelijke cijfers worden door de organisatie omschreven als 'industry benchmarks'.

Reacties (150)

Interessant hier is hoe een "fout" word gedefinieerd. Dat staat niet in het artikel, maar als je de bron erbij pakt, dan zie je dat hier gebruikt is gemaakt van zgn. "static analysis". Dit betekent dat er is gekeken naar de code, en vervolgens naar fouten hierin: waar de code ongeldige dingen probeert te doen, welke voor problemen kan zorgen bij het uitvoeren. Hier worden vooral slordigheden van de programmeur gedetecteerd, het gebeurd zelden dat static analysis een echt, fundamenteel probleem onthult.

Een ander nadeel van static analysis is dat niet dat elke gedetecteerde fout ook daadwerkelijk problemen oplevert: programmeurs zijn nog altijd slimmer dan computers, en schrijven soms code welke voor de computer te ingewikkeld is om correct te kunnen analyzeren. Hierdoor zitten er vaak nog zgn. "false positivies" tussen de resultaten van een onderzoek als deze. Andersom is het trouwens ook zo dat de computer nog niet alle fouten van de programmeur kan detecteren.

Hoewel dit wel iets zegt over de kwaliteit van de code, zegt het praktisch gezien helemaal niks over de kwaliteit van de afgeleverde software. Het zegt hoogstens iets over hoe vaak bepaalde soort bugs (meestal crashes) voorkomen. Wat voor de eindgebruiker echter vooral van belang is, is tot in hoeverre het programma doet wat het moet doen. Als bijvorobeeld de Linux kernel nooit crasht, maar ook je harde schijf niet detecteert, is het alsnog een nutteloos stuk software.

Je kan op basis van dit onderzoek dus ook niet concluderen dat opensource software beter is dan proprietaire software, of andersom. Het zegt hoogstens iets over hoe goed de programmeurs zijn in het fixen van hun eigen slordigheden, en hoeveel prioriteit daaraan gegeven wordt.

Bovendien, wat niet in het artikel staat, heeft Coverity de open source projecten van te voren al toegang gegeven tot het scan platform, waarmee het onderzoek is uitgevoerd. Hierdoor hebben zij al de tijd gehad om het type problemen dat deze scanner detecteert al te fixen. De proprietaire code is hier niet voor aangepast, en het is dus geen goed vergelijkend onderzoek.

Wat ik ook een beetje mis is of de projecten vergelijkbaar zijn in professionaliteit. De closed source projecten worden door anonieme mensen aangeleverd, dus is hoe betrouwbaar is het dat de aangeleverde code ook in dezelfde staat van ontwikkeling is, en is het uberhaupt legaal dat het is gebruikt.

Plus het platform van Coverity is closed source als ik de site zo zie, dus die zou dus ook 0.64 fouten moeten bevatten per 1K regels code.

Het ziet er meer uit als een koop ons testplatform dan een daadwerkelijke studie die te verifieren is.

En een closed source project schaft natuurlijk sneller zo'n pakket aan dan een open source project.

Een kleine toevoeging:

Daarnaast is er van Open Source software 37 miljoen regels code gecontroleerd welke inderdaad bestonden uit een managed set van code (optimized voor de test) tegenover 300 miljoen regels closed source code (willekeurige code).

Statischisch gezien is het dus mogelijk dat er bij de closed source code een stuk code zat met zo een hoge dichtheid aan fouten volgens de meet methode, dat het gemiddelde van closed source beinvloed werd.

Uiteindelijk zegt deze test dan totaal niets en denk ik dat men in zowel closed source als open source afstand moet nemen van de resultaten omdat de resultaten te gekleurd zijn, de test manipuleerbaar is, de test set onvoldoende is.

Het is het zelfde als twee type's processoren testen of ze een bepaalde oc aankunnen, waarbij 1 fabrikant op voorhand mag cherrypicken terwijl de spullen van de andere fabrikant gewoon op de hoek gehaald wordt. Het resultaat staat vast in zo een geval, en dat geldt ook voor deze test.

Andersom is het trouwens ook zo dat de computer nog niet alle fouten van de programmeur kan detecteren.

Sterker nog: dat zal nooit kunnen.

Ik twijfel heel erg aan dit onderzoek, zeker aangezien PHP als een van de beste projecten uit de test komt. Als je ziet hoeveel bugreports, hotfixes en CVEs zij aan de lopende band produceren, dan acht ik niet geloofwaardig dat ze het beter doen dan andere projecten zoals de Linux kernel of PostgreSQL, welke veel minder vaak voor problemen zorgen.

Als ik de source code van PHP 5.3.10 erbij pak, dan zijn dat volgens cloc 1,29 miljoen regels code (blank + commentaar meegeteld). Als je dan nagaat dat er 0,2 fouten per 1.000 regels code in moeten zitten, zouden er in totaal 257 fouten in zitten. Als ik vervolgens in hun bug tracker kijk, dan zie ik dat er alleen al 556 bugs bevestigd zijn, en waarschijnlijk nog veel meer open staan zonder dat er uberhaupt iemand naar heeft gekeken.

Ik acht dit onderzoek dus niet heel geloofwaardig.

EDIT: Het onderzoek zelf spreekt zelfs van maar 537.871 regels code voor PHP. Dan zouden ze zelfs maar 107 fouten mogen hebben...

[Reactie gewijzigd door hostname op 24 februari 2012 17:52]

Als je ziet wat voor bugreports en CVE zij aan de lopende band produceren, dan acht ik het niet heel geloofwaardig dat ze het beter doen dan de andere projecten die getest zijn.

Ja en dat is dus juist de kracht van open source.. Mensen nemen nu uberhaupt de moeite om het te melden en dan kan er iets aan gedaan worden. De hoeveelheid bugreports is een heel slechte maatstaaf voor de kwaliteit van software. De ernst van bug reports en de afhandeling ervan is veeeel belangrijker.

Ik maak hier niet een vergelijk tussen open source en niet open source, maar tussen verschillende open source projecten. Voor PostgreSQL bijv. komen veel minder kritieke updates dan voor PHP. In mijn ervaring heeft de Linux kernel ongeveer evenveel kritieke updates als PHP, maar dat project is veel groter.

Los daarvan, de afhandeling is PHP ook niet goed. Zo moest PHP 5.3.9 een lek fixen waardoor dos-aanvallen erg makkelijk werden (deze volgens mij), maar tegelijkertijd introduceren ze een nog veel erger lek: remote code execution, wat pas een kleine maand later opgemerkt werd, en nog niet eens door een van de PHP developers zelf.

Misschien de kracht van Open Source, maar bij PHP niet erg geloofwaardig. Zoals hostname al aangeeft, zijn er veel CVE's voor PHP uitgebracht. Tel daarnaast de features op in de programmeertaal waar je af moet blijven, en het lijkt eerder op een drama dan een veilig project.

Even nadenken.. addslashes(), mysql_escape_string(), magic quotes, register globals, diverse $_SERVER[..] variabelen, null byte hacks (%00 op de querystring), urls in fopen() of include, geen default escaping (via prepared statements of template talen), weinig begeleiding om XSS/HTML injection te voorkomen en geen eenvoudige user privilege separation per site.

Het is het soort programmeertaal waarin je prima veilig kan werken, als je heen goed weet wat je doet. Zo'n taal durf ik alleen geen newbie aan te zetten, wat nu net de doelgroep van PHP is.

[Reactie gewijzigd door YaPP op 25 februari 2012 01:06]

Een bug is niet noodzakelijk een fout in de broncode. Een bug kan ook veroozaakt worden door foutieve implementaties van bepaalde dingen, bijkomend vind je in bugtrackers vaak ook feature requests terug alsook duplicaten en bugs gerelateerd aan elkaar.

Die 556 bugs in hun bugtracker zijn de zgn. "Assigned" bugs, waar al een developer naar heeft gekeken en heeft vastgesteld dat het een probleem is, en ook iemand voor is aangewezen die het gaat fixen. Dat zijn dus zeer waarschijnlijk wel degelijke echte bugs, en geen duplicaten.

Bovendien gebruikt PHP de bugtracker niet voor feature requests. Daar hebben zij een apart RFC proces voor.

is het niet zo dat die zaken juist aangeven dat ze erg druk bezig zijn met het controleren van kwaliteit en het fixen van fouten? Bij gesloten software heb je geen zich op dit soort zaken en weet je dus niet waar het om gaat.

Daarnaast zijn bugs een erg brede term

Ik vrees dat je twijfel veroorzaakt wordt door:

(a) je onbekendheid met het onderzoek en de gehanteerde maat voor kwaliteit
(b) je onbekendheid met de forma Coverity

Aan beide manco's is (met de enige inspanning) wel wat te doen.

De firma Coverity kan je op Googelen. Als eerste kijk je dan natuurlijk op Wikipedia, en dat leert je dat deze firma software tools maakt foor statische analyse van broncode. Zo'n beetje als PC-lint, maar dan beter.

Deze firme wordt betaald voor het leveren van dit soort software, en soms voor het draaien ervan. Bij wijze can reclame draaien zij alle bekende Open Source projecten door hun checker, en brengen de maintainers dan op de hoogte van alle dubieuze constructies en codeerfouten die zij hebben gevonden.

Dit leert je meteen welk perspectief deze firma hanteert voor "code-kwaliteit". Bot gesteld: als jij C++ code schrijft die geen enkele warning triggert bij compilatie en die netjes alle buffer overruns afvangt, dan is je code van "hoge kwaliteit". Ongeacht of je code wat zinnigs doet of hoe efficient/inefficient dan wel gebruiksvriendelijk je dat doet.

Daar ligt het antwoord op jouw opmerking over die bugs. Dat zijn blijkbaar fouten in de *werking* van PHP, die echter vervat zijn in C++ code van hoge kwaliteit (in termen van NULL pointers, ongeinitialiseerde variabelen etc. etc.).


Het rapport kan je hier vinden:

http://www.coverity.com/l...urce-integrity-report.pdf

Als je het rapport leest, dan zie je bijvoorbeeld deze zinsnede:

As open source adoption continues in commercial software development, a commonly asked question is, “How does open source software stack up against proprietary software?”
This year’s report marks the first time we are making a comparison between the quality of open source software in a sample of active projects in Scan and a representative sample of proprietary codebases from anonymous Coverity users across a variety of industries. What we found is that when comparing codebases of similar size, quality is on par across open source and proprietary software.

en verderop:

This year’s analysis led us to our final set of findings:
Proprietary codebases that leverage automated testing such as static analysis have quality above average
for the software industry.
Open source quality is on par with proprietary code quality, particularly in cases where codebases are of
similar size.

Simpelweg wordt gesteld dat:
(1) de code-kwaliteit (in termen van fouten die statische code-checkers detecteren) van firma's die statiscche code-checkers gebruiken duidelijk beter is dan het gemiddelde in de industrie (die dergelijke checkers niet gebruiken). Ligt voor de hand natuurlijk, maar ook dit soort fouten zijn fouten

(2) de code-kwaliteit van OS projecten ongeveer gelijk is aan die van goede (gedefinieerd als projecten die gespitst zijn op fouten die statische code-checkers opsporen) closed-source projecten. Ligt ook voor de hand, want deze OSS projecten doen moeite om de door Coverity scans gevonden fouten te verbeteren.


Al met al is er niets "twijfelachtigs" aan het onderzoek. Je moet het alleen wel goed interpreteren, en dat kan je alleen maar als je even leest wat er aan de hand is.

Uit de analyse bleek dat de opensourcebroncode gemiddeld 0,45 fouten per duizend regels bevatte, terwijl bij propriëtaire code 0,64 fouten per duizend regels werden aangetroffen. Daaruit zou blijken dat opensourceprojecten gemiddeld minder fouten bevatten, al scoren beide categorieën onder de 1.0, het gemiddelde aantal gemaakte fouten in software.

Ehm, dus opensource is minder 1.0 en propriëtaire code is minder dan 1.0. Hoe kan het gemiddelde dan 1.0 zijn, welke categorie is er nog over. Je hebt closed en non-closed. Zitten alle fouten in half-closed?

Ik denk dat ze bedoelen, je hebt direct toegang tot de broncode of je moet reverse engineeren.

Blijkbaar is de code die ze bekeken hebben niet representatief voor de gemiddelde code in software?

Voor de geinteresseerden: rapport

Overigens hebben de opstellers kennelijk hun eigen rapport verkeerd begrepen, dat zegt namelijk:

Open source quality is on par with proprietary code quality, particularly in cases where codebases are of similar size.

Da's toch heel wat anders, en zeker genuanceerder dan "Opensource bevat minder fouten".

Op security.nl stond het een stuk beter uitgelegd. Als je alleen keek naar open source projecten die ongeveer evenveel regels code hadden als de closed source projecten, dan kwam je op een error rate van 0.62 uit (zie Linux kernel). Dat is waarschijnlijk gelijk aan de 0.64 van closed source als je aanneemt dat de standaard deviatie (die niet genoemd wordt) niet onder de 0.01 ligt. Gemiddelde waardes kun je niet blindelings vergelijken.

PHP 5.3 heeft 0,2 fouten per 1000 regels code, maar als er dan eentje in zit is het wel meteen een huge lek. Neem als voorbeeld PHP 5.3.9 waar een denial of service probleem werd verholpen, maar waarmee een veel groter lek werd geintroduceerd. In hoeverre is het aantal fouten in software dan representatief voor de kwaliteit vraag je je dan af.

Sowieso gaat het nergens over. Misschien zitten er relatief weinig "security" holes in, maar er zitten in PHP zat dingen die gewoon verkeerd geïmplementeerd zijn (wegens het missen van een spec), waarna de bij-effecten vervolgens gedocumenteerd worden en that's that. Ja, zo kan ik ook foutvrije software schrijven

Dat mag misschien zo zijn (vind ik soms ook), en daardoor ga jij ASP gebruiken? Betalen voor MS 'technologie' wat ongeveer hetzelfde kan en dan moet je ook nog eens een windows servertje hebben etc. Je moet een gegeven paard niet in de bek kijken, kun jij het maken dan? Langs de lijn schreeuwen is altijd gemakkelijk.

[Reactie gewijzigd door codebeat op 27 februari 2012 02:32]

De software van Coverity zoekt op bepaalde types fouten (namelijk het soort dat je met static analysis en heuristics kunt vinden), en vind daardoor dus niet alle soorten fouten (conceptuele fouten of foute logica zijn bijvoorbeeld niet op deze wijze te detecteren).

Dit is op zichzelf wel een logische opmerking.....
Als iedereen zich kan bemoeien met je code is er veel meer aandacht aan besteed door verschillende mensen.

Dat is inderdaad een veelgehoord argument, maar in de praktijk zie je dat veel projecten of onderdelen daarvan lange tijd bij één persoon zitten. Ook hebben sommige bedrijven die proprietary code schrijven juist peer-reviews ingevoerd.

Het zou ook kunnen dat er minder fouten zit in code die zonder deadline wordt geschreven, en dat komt waarschijnlijk minder vaak voor bij open-source. Je wilt niet weten hoeveel drama-code ik heb gezien onder het excuus van een zo kort mogelijke time-to-market of een om een andere reden vastgestelde live-datum.

Kortom: zonder onderbouwing van de oorzaken met bewijs blijft het speculeren.

Dat is inderdaad zo, de code die onder "druk" word geschreven door programmeurs is meestal slecht en slordig. Open source heeft vaak geen/lange deadlines waardoor de code veel beter geschreven kan worden, wat weer bijdraagt aan de kleinere hoeveelheid fouten in de geschreven code.

Ja en daarom krijg je er ook wekelijks tig updates gratis bij. Een van de grootste ergernissen van mij wat betreft gratis software. Constante bugfixes en features waar je helemaal niet om vraagt. Patches en beveiligingsproblemen ok, maar dat de hele community schreeuwt om allerhande dingen die dan telkens weer eringezet worden + nieuwe bugs + weer nieuwe updates dat hoeft voor mij nou niet zo.

Hoe kortzichtig kan je zijn

Updates zijn belangrijk, die fixes zijn er niet voor niets. Hoe denk dat het gros van de hacks van afgelopen maanden tot stand zijn gekomen (buiten SQL Injection)? Juist door verouderde software.

Nu kan ik mij voorstellen dat je updates in Windows irritant vind, maar goed daar is het naar mijn mening ook slecht geïmplementeerd. Bijna altijd moeten restarten, een schermpje wat bijna constant blijft irriteren om je er aan te herinneren dat je computer opnieuw moet starten, en zo kan ik nog wel even doorgaan.

Linux heeft dit allemaal veel mooier en centraler geregeld, en hoeft voor slechts enkele updates ook opnieuw te worden gestart, en zal daarbij niet constant zeuren als je dat even niet wil.

Nu kan ik mij voorstellen dat je updates in Windows irritant vind, maar goed daar is het naar mijn mening ook slecht geïmplementeerd. Bijna altijd moeten restarten ...

Lang niet altijd, sinds Windows 7, en als er moet worden gereboot, dan kan dat ook niet anders.

... een schermpje wat bijna constant blijft irriteren om je er aan te herinneren dat je computer opnieuw moet starten ...

Dat kun je uit zetten, en dat is er om de gemiddelde computergebruiker te aan herinneren dat het belangrijk is om de computer te rebooten. Weinig slechts aan, imo.

Linux heeft dit allemaal veel mooier en centraler geregeld

Centraler? Centraler dan met Windows Update kan het volgens mij niet... Heeft 'Linux' een rollback-feature? Hangt af van je distro, en soms van hoe je je package manager configureert. Soms is het niet mogelijk, of moet je een oude update forceren. Lekker gebruikersvriendelijk. Bij Windows zijn rollbacks ook mogelijk voor gewone installaties en deïnstallaties.

Sorry maar ik moet concluderen dat jij precies niet zoveel van Linux afweet.

Op Windows krijg ik om de vijf botten van al mijn verschillende programma's die ik gebruik meldingen van updates: Adobe Acrobat, Sun Java, Flash, µTorrent, Firefox... en dan natuurlijk ook nog Windows zelf.

Ik zou nu persoonlijk het venster van waarschuwing tot reboot helemaal niet zó vreselijk vinden, als het nu ook eens de optie zou geven om niet te rebooten. Ik kan het namelijk maximaal 4 uur uitstellen, en als het venster verschijnt start er meteen gezellig een countdown van 10 minuten. Als je dan net even bezig bent in de keuken of even iemand anders thuis een handje geeft, of misschien aan het knutselen bent aan de hardware-kant van je nieuwe hobbyprojectje, dan heb je het vlaggen en is alles wat je open had staan weg.

Je kan effectief niet fatsoenlijk gaan slapen zo gauw je zo'n venster hebt gekregen zonder eerst alles wat je open hebt staan op te slagen. Als er iets is waar ik absoluut een hekel aan heb, dan is het een comfortabele sessie met al mijn benodigdheden open en afgesteld op elkaar af te moeten sluiten, ipv daar 's ochtends gewoon gezellig aan door te kunnen werken.

Bij Linux is het simpel: je hebt daar één package manager die alle updates van alle geïnstalleerde packages in het oog houdt; alle updates zitten mooi gecentraliseerd in één venster en één notificatie. Ik heb die van mij meestal ingesteld dat hij me er maar één keer per week mee lastig valt, en dan kan ik mooi wanneer ik er zin in heb al mijn packages updaten, allemaal tegelijk.

Een simpele rollback zoals in Windows is inderdaad niet beschikbaar, omdat er simpelweg niet evenveel vraag naar is. Het deïnstalleren van een package en dan het gewenste versienummer herinstalleren is beduidend makkelijker in Linux en de meeste mensen houden toch backups bij van hun home directory. Er zijn zelfs applicaties zoals Flyback die als perfecte Time Machine-klonen functioneren.

[Reactie gewijzigd door Gyzome op 24 februari 2012 22:05]

[...]
Lang niet altijd, sinds Windows 7, en als er moet worden gereboot, dan kan dat ook niet anders.

[...]
Dat kun je uit zetten, en dat is er om de gemiddelde computergebruiker te aan herinneren dat het belangrijk is om de computer te rebooten. Weinig slechts aan, imo.

[...]
Centraler? Centraler dan met Windows Update kan het volgens mij niet... Heeft 'Linux' een rollback-feature? Hangt af van je distro, en soms van hoe je je package manager configureert. Soms is het niet mogelijk, of moet je een oude update forceren. Lekker gebruikersvriendelijk. Bij Windows zijn rollbacks ook mogelijk voor gewone installaties en deïnstallaties.

yep die zit in de laatse opensuse vriend, op bestands systeem niveau
Jekan per update per uur instellen.. .. Ik draai zelf geen btrfs maar ik draai zelf backintime op mn home partity .. die bzipped elke dag mn home dir naar externe schijf

[Reactie gewijzigd door demilord op 24 februari 2012 20:58]

is dit juist wat we wel willen?
door die updates wordt je pc sneller en beter van.

In een zakelijke omgeving waar je een linux server draait zit je niet te wachten op wijzigingen, maar zit je te wachten op security patches e.d.

Het heeft mij de afgelopen paar weken enorm verbaasd hoeveel patches (soms wel 32 per dag) er op dagelijkse basis werden verspreid. En dan had ik alleen PHP, MYSQL en Apache draaien op die test server.

Je draaid nooit alleen maar php,mysql en apache op een linux server.
Het basis systeem bestaat vaak al uit ruim 200+ packages. En deze worden vanzelfsprekend ook geupdate.

Op je productie server, zal je vaak ook een Long Term Support willen hebben. Dus hier neem je Ubuntu LTS, RHEL of Centos voor. Zodat je niet lastig gevallen wordt met elke nieuw dingetje wat ze bedacht hebben.

De keuze is aan de mens zelf. iets wat vaak bij gesloten software niet zo is.

Het basis systeem bestaat vaak al uit ruim 200+ packages. En deze worden vanzelfsprekend ook geupdate.

Die 200 pakketten zijn over het algemeen niet het probleem, die zijn al zo volwassen dat er bijna geen fouten meer in gevonden worden die het echt noodzakelijk maken om te updaten. In Debian Stable (Squeeze) zijn er afgelopen jaar (tussen 6.0.0 en 6.0.4) maar ongeveer 5 updates geweest aan een pakket met prioriteit 'required' of 'important'

'Required' en 'important' pakketten zijn meestal wel geen server programma's die open staan voor het publiek, en updates voor deze (server) pakketten zijn net zo belangrijk.

En niet te vergeten: Debian stable...

In welke distro/channel zit je? Als je op ubuntu/debian zit krijg je vrijwel alleen security upgrades tenzij je een full distro upgrade doet.

Als je op Archlinux zit, ja dan heb je bleeding edge, en dat moet je ook niet voor een productie server gebruiken.

Als je op Archlinux zit, ja dan heb je bleeding edge, en dat moet je ook niet voor een productie server gebruiken.

Hangt er vanaf hoe goed de port maintainers hun werk doen, en hoe je eigen testing policy is. FreeBSD hanteert hetzelfde model als Arch en dat wordt ook volop in productie gebruikt.

Van grote OS serverpakketen als Apache, PostgreSQL of Samba worden de oudere versies ook in de ports gehouden. Ik vraag me af of zo'n server ook echt eerder onderuit gaat op FreeBSD CURRENT (10.0 #2) dan STABLE (9.0). Volgens mij kan dat alleen als je ook echt de nieuwste features gebruikt die in de laatste versies zitten of als je nieuwe hardware gebruikt die nog maar sinds kort wordt ondersteund.
Voor thuis merk ik i.i.g. geen verschil tussen die twee, behalve dat 10.0 de Atheros wifi van mijn laptop beter door heeft.

[Reactie gewijzigd door blorf op 25 februari 2012 11:39]

Vraag ik mij ook af. Mijn thuis-server (web, file, uPNP) draait op Arch en ik denk dat ik wekelijks een 30-tal packages moet updaten. Onze Debian stable-server krijgt maandelijks misschien een 10-tal security updates en een 5-tal gewone updates binnen...

Als je op je server natuurlijk X installeert en allerlei desktopprogramma's, dan zal het aantal updates snel toenemen...

Ik heb een dedicated server (isgenoeg.nl / OVH ) waar ArchLinux op staat. Op deze machine staan enkele websites en handelt de mail voor enkele domeinen af. (en nog wat andere taken) Wat dat betreft kan deze dus als productieserver worden gezien.

kreeg toch echt pas nog een update van firefox naar de laatste versie op ubuntu 10.10

daarin tegen het voordeel dat je bij linux-based servers de server niet opnieuw hoeft te op te starten wil je de updates actief maken. enkel mij een nieuwe kernel versie(van 2.6 naar 3.0 b.v.)

Zelfs bij een nieuwe kernel of je tegenwoordig niet meer te reboten Er zijn technieken (welke ik niet in productie wil gebruiken) om de huidige kernel te vangen zonder een reboot.

Je moet dan echter init ook opnieuw opstarten waardoor je in feite alsnog een reboot moet uitvoeren. Het enige voordeel is dan ook dat je niet opnieuw de BIOS POST moet doorlopen en wat RAID-controllers e.d. daar aan toevoegen.

Init wordt toch door de kernel gestart nadat die geladen is? Het systeem in dan al zover dat het Linux executables kan uitvoeren. Dan ben je al een stuk verder met booten dan de POST, da's puur de hardware init van je kast.

Maar ik vraag me af on hoeverre het mogelijk is de kernel "live" te vervangen met een andere. Ik heb er nog nooit van gehoord. Het klinkt interessant maar ik vertrouw het niet helemaal. Een andere kernel heeft mogelijk ook een ander process- en geheugenmanagement wat betekent dat alle data die voor de live kernel-update geladen was mogelijk niet meer strookt met het nieuwe systeem. Het blijft altijd gokken als je het mij vraagt. Het lijkt me ook niet mogelijk om bij een mislukte poging de vorige kernel direct weer te herstellen. Het hele systeem hangt eraan, zonder correcte kernel doe je niet veel meer.

probeer maar eens met ksplice gratis voor gebruik icm: ubuntu desktop kernels
maar betaald voor server gebruik

dat is kspkice

Je kunt toch gewoon een stable/LTS linux draaien, krijg je alleen security backports (vergelijkbaar met closed source versies) en geen nieuwe functionaliteit.

Verder kun je een systeem zo "bare" maken als je wilt waardoor je het aantal noodzakelijke updates tot een minimum kunt terugbrengen (itt closed source).

Ja, mooi voorbeeld: Firefox 10 (of is het 12 inmiddels) draait uiteraard sneller dan Firefox 2....

Nee, ik ben het best eens, te veel OSS projecten hebben extreem last van feature creep en het regelmatig overhoop gooien van de UI (Thunderbird).

En IE 2 draait ook sneller dan IE 9, dus wat is je punt?

Bovendien gooit gesloten software net zo vaak zijn UI overhoop (Office, SAP R2 vs R3, noem maar op).

free software moet je niet zien als gratis, meer als open waar je gebruik van kunt maken. die updates vind ik geweldig. en draai dan ook unstable voor nieuwste features en bugfixes. maar je hoeft niet perce te updaten! (los van eventueel security issue)

Precies. Free as in Free Speech not Free Beer

Free as in Free Speech *and* Free Beer.

Het is niet mogelijk betaling te vereisen voor Open Source software.

Je kunt vrijwillige donaties vragen, support contracten verkopen, maatwerk bouwen tegen uurtje factuurtje en het resultaat vrijgeven onder een Open Source licentie en nog veel meer constructies om Open Source heen, maar de Open Source software zelf kun je geen geld voor *eisen* (vragen staat natuurlijk vrij) en is dus zowel ' gratis' als 'vrij', zowel free as in free speech als free as in free beer.

Om mij het tegendeel te bewijzen hoef je slechts een Open Source project aan te wijzen waarvan ik de software niet legaal gratis kan bemachtigen en gebruiken, maar dit gaat niet lukken want niet een van de ' officiele' Open Source licenties maakt dit mogelijk.

Zie ook mijn blog over dit steeds terugkerende onderwerp:
Open Souce *is* Free Software

EDIT: Oh en Kramer65, men verwijst steeds naar die engelse zin omdat dat een beroemde (doch aantoonbaar onjuiste) quote is van de Free Software Foundation, details in mijn blog post.

[Reactie gewijzigd door OddesE op 24 februari 2012 19:23]

Het is niet mogelijk betaling te vereisen voor Open Source software.

Tuurlijk wel, en het gebeurt ook:

-MSFT vangt bijvoorbeeld geld voor de iedere open FAT-implemenatie van Linux die verkocht wordt door bijv. TomTom,
-het h.264 protocol en implementaties zijn open source, toch worden er voor de software geimplementeerd in de hardware geld gevraagd,
-Windows is open source voor veel overheden, toch wordt er geld voor gevraagd,
-_Alle_ NEN / ISO standaarden maar bijv ook GSM zijn ' open', maar bijna geen een is gratis (sommigen daarcvan bevatten brokjes software, die je dus niet gratis kan krijgen. Zo wel zie ik graag de volledige STEP-standaard tegemoet),
-bepaalde cryptografie omzeilende software is open source, maar niet (overal) legaal te bemachtigen,
-Het meeste uit RedHat is open source, maar RedHat is niet gratis te downloaden (wegens de RedHat trademarks, vandaar CentOS)
-De FTP-client (binary) uit Windows bevat OpenSource, maar de bron hiervan valt nergens gratis te downloaden
-Veel Chinese hardware heeft software erop geinstalleerd die "open source" zou moeten zijn, maar niet gratis te downloaden is (GPL overtreders dus)
-Java is vziw open source, doch Google is aangeklaagd voor het gebruik ervan; dus voor Google is het niet gratis.


Overigens, als de ISO het voor elkaar krijgt geld te vragen voor open standaarden zie ik niet in waarom iemand anders dat niet voor open source software kan doen. Zo moeilijk is het niet, NEN verdient er immers al decennia lang haar brood mee.

Zo jammer dat al deze malinformatie dan wordt gewaardeerd met +2 informatief.

In alle gevallen die jij noemt is of geen sprake van Open Source, of er wordt betaald voor licenties op patenten en niet op software:

- MSFT vangt bijvoorbeeld geld voor de iedere open FAT-implemenatie van Linux die verkocht wordt door bijv. TomTom, ==> Patenten

-het h.264 protocol en implementaties zijn open source, toch worden er voor de software geimplementeerd in de hardware geld gevraagd, ==> Patenten

-Windows is open source voor veel overheden, toch wordt er geld voor gevraagd,
==> Geen Open Source, maar Shared Source

-_Alle_ NEN / ISO standaarden maar bijv ook GSM zijn ' open', maar bijna geen een is gratis (sommigen daarcvan bevatten brokjes software, die je dus niet gratis kan krijgen. Zo wel zie ik graag de volledige STEP-standaard tegemoet),
==> Standaard != Software en Open != Open Source. Er is een definitie voor Open Source hoor!

-bepaalde cryptografie omzeilende software is open source, maar niet (overal) legaal te bemachtigen,
==> Irrelevant, het gaat hier over gratis, niet over legaal

-Het meeste uit RedHat is open source, maar RedHat is niet gratis te downloaden (wegens de RedHat trademarks, vandaar CentOS)
==> Again, de Software is gratis. RedHat vraagt geld voor branding, support e.d.

-De FTP-client (binary) uit Windows bevat OpenSource, maar de bron hiervan valt nergens gratis te downloaden
==> Beschikbaar stellen van de broncode is niet overal verplicht. Verder graag een bron naar de licentie, want jij noemt allerlei zaken Open Source die dat duidelijk niet zijn.

-Veel Chinese hardware heeft software erop geinstalleerd die "open source" zou moeten zijn, maar niet gratis te downloaden is (GPL overtreders dus)
==> Point being? Het is eigenlijk gratis maar ze houden zich er niet aan?

-Java is vziw open source, doch Google is aangeklaagd voor het gebruik ervan; dus voor Google is het niet gratis.
==> Java is niet Open Source, echter de OpenJDK is wel een Open Source implementatie van Java. Oracle klaagt Google aan voor overtreding van... patenten!

Windows open source voor veel overheden? Dacht het niet hoor!

Er kan geld gevraagd worden voor vrije software alleen mogen er geen limieten op de software zitten. Dus als er om de broncode gevraagd wordt moet die gegeven worden en de software mag vrijelijk verspreid worden.

Dat betekent niet dat je er geen geld voor kan vragen.

Vragen staat vrij natuurlijk.

Alleen de definitie van gratis is imho niet dat je niet *mag* betalen maar dat je niet *moet* betalen. Oftewel als je niet verplicht bent te betalen is het effectief gratis.

Maar goed ik heb deze discussie al zo vaak gevoerd en steeds dezelfde argumenten komen terug. Noem gewoon een Open Source project waar je voor gebruik van de software *moet* betalen... Is er niet. Waarom denk je dat MySQL e.d een 'dual licensing scheme' gebruiken? Waarom is die tweede, commerciele, licentie noodzakelijk? Simpel, omdat de software onder de Open Source licentie per definitie gratis is:

You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself.

Oftewel als je de commerciele licentie op MySQL aanschaft gebruik je juridisch gezien op dat moment geen Open Source software. Je gebruikt de software immers onder een commerciele licentie.

Free Software gaat niet over 'gratis' maar over 'vrijheid'. Vrije Software moet (volgens de Free Software Foundation) aan vier specifieke eisen voldoen. Niet alleen moet je het programma kunnen draaien (1) en de source bekijken (2), je moet ook het recht hebben om de source door te geven (3) en om je eigen aanpassingen door te geven (4) aan iedere gebruiker van de software.

Heel kort door de bocht mag je bij Open Source de broncode bekijken, en bij Free Software mag je de code ook gebruiken.

In praktijk heb je gelijk en is vrijwel alle Open Source software ook Free Software en is het verschil voornamelijk filosofisch. Dat neemt niet weg dat er wel degelijk een verschil is, al is het maar dat je aan iemands woorkeuze kan zien hoe hij over bepaalde zaken denkt.

Free Software gaat niet over 'gratis' maar over 'vrijheid'. Vrije Software moet (volgens de Free Software Foundation) aan vier specifieke eisen voldoen. Niet alleen moet je het programma kunnen draaien (1) en de source bekijken (2), je moet ook het recht hebben om de source door te geven (3) en om je eigen aanpassingen door te geven (4) aan iedere gebruiker van de software.

Even een nuance, je bent verplicht om de bron code mee te leveren en je aanpassingen door te geven.

Alleen de definitie van gratis is imho niet dat je niet *mag* betalen maar dat je niet *moet* betalen. Oftewel als je niet verplicht bent te betalen is het effectief gratis.

https://en.wikipedia.org/wiki/AdaCore is een bedrijf dat zo werkt.

In de praktijk betaal je vaak niet - in elk geval als consument. Maar je kunt zoveel geld vragen als je wilt - ik kan gerust 1000 euro vragen voor VLC en als jij VLC van mij wilt moet je dat betalen, geen discussie. De licentie verbied dat echt niet.

Uiteraard ga jij geen 1000 euro betalen want je kunt VLC gratis downloaden op andere plaatsen. Dat is hoe het werkt: ALS ik jouw VLC verkoop MOET ik de broncode erbij doen (als jij daarom vraagt, tenminste). En dan zou jij daarmee weer mogen doen wat je wilt - inclusief het gratis of tegen zeg 900 euro weer weggeven of verkopen. Kind kan bedenken dat ik dus maar 1 kopie ga verkopen...

Maar bedrijven betalen regelmatig ontwikkelaars om software te schrijven die deel wordt van een GPL project - ze betalen dus voor code die daarna gratis wordt weggegeven.

open source != vrij != gratis
alles hangt af van de licentie. Ik kan morgen mijn eigen openbron licentie uitbrengen die verbiedt om aan de software code te komen of ze te kopiëren zonder eerst een roze pinguin op de mond te kussen.

Dat kun je doen, echter zal dit niet aan de algemene definitie van Open Source voldoen. Jij bent dan dus de enige die het echt Open Source noemt.

De term Open Source is geen beschermd merk, maar er is dus wel een algemeen geaccepteerde definitie voor en de rest van de Open Source community zal jouw 'Open Source' licentie niet serieus nemen als die niet aan deze definitie voldoet.

Stel ik ontwikkel zelf een programmeertaal.
Stel ik schijf een programma in die programmeertaal,
Ik geef de broncode vrij, en verkoop een gecompileerde versie.

Tsja.... open source... maar aan de broncode heb je niks zonder compiler van mijn taal.

toch interessant dat jij het dan beter weet dan zowel de FSF als GNU en alle bedrijven die hun producten uitbrengen onder meerdere licenties

Om mij het tegendeel te bewijzen hoef je slechts een Open Source project aan te wijzen waarvan ik de software niet legaal gratis kan bemachtigen en gebruiken, maar dit gaat niet lukken want niet een van de ' officiele' Open Source licenties maakt dit mogelijk.

in deze heb je gelijk omdat jij een consument bent, MAAR... zodra jij deze software commercieel wilt gaan gebruiken dan ligt het anders. Neem bijvoorbeeld x264 en lees deze link: http://mailman.videolan.o...vel/2010-July/007508.html
(plus je moet betalen aan MPEG-LA, maar dat is een iets ander verhaal)

MPEG moet je (in sommige gevallen) inderdaad voor betalen, maar daar betaal je voor een licentie op een patent. Dit is ook waarom Firefox er niet aan wil. Heeft verder niets met Open Source te maken.

Wat betreft VLC. Aangezien deze licensed onder de GPL is, is deze *gratis*. Ook voor commercieel gebruik. De Open Source software, blijft altijd gratis, hoe je die ook gebruikt. Echter als je een extensie van VLC bouwt dan dien je onder de regels van de GPL de broncode van je extensie vrij te geven. Hier kun je onder de regels van de GPL niet onderuit, ook niet door te betalen. En daar komt die Dual Licensing om de hoek kijken. Je kiest dus een *andere*, commerciele license, die wel geld kost maar niet die eis van de GPL heeft om je broncode te openbaren. Echter betaal je op dat moment voor een commerciele licentie. Die licentie is ook niet Open Source. De enige reden dat Videolan dat kan doen is dat zij de auteur zijn van de software.

Interessant dat jij het dan beter weet dan zowel de FSF als GNU en alle bedrijven die hun producten uitbrengen onder meerdere licenties

Ik weet het helemaal niet beter dan de bedrijven die dual licensing hanteren; zij weten donders goed dat ze geen geld kunnen vragen voor de Open Source versie, vandaar dat ze daarnaast een tweede, commerciele versie uitbrengen.

Wat betreft het FSF en de GNU, dat is eigenlijk een partij (Richard Stalman) en die weet het echt wel beter maar dat is een soort van politicus die dus deze mythe in stand wil houden. Noem anders een Open Source GNU project dat je niet gratis kunt gebruiken?

Ik weet het helemaal niet beter dan de bedrijven die dual licensing hanteren; zij weten donders goed dat ze geen geld kunnen vragen voor de Open Source versie, vandaar dat ze daarnaast een tweede, commerciele versie uitbrengen.

ik denk dat daar het punt zit, er is geen "open source versie". Er is 1 versie waarvan de broncode gepubliceerd is (en ook verder gedistribueerd mag worden), dus noem je het open-source software. Het bestaan van een commerciele licentie maakt de software niet ineens closed-source of "niet open-source", maar je moet er dan wel voor betalen.
Vandaar betalen voor open-source software.

PS Ik ken het verschil tussen open-source in definitie van de OSI en de zin van 'de broncode is in te zien', maar in het geval van x264 (en vele anderen) denk ik dat er nog steeds sprake is van open-source in de definitie van OSI omdat het vrijgegeven is onder de GPL. Die commerciele licentie doet daar niets van af.

je kunt zelfs kopieën verkopen als je er de broncode maar bijleverd, dat mensen niet snel genijgd zijn bij jouw te kopen in plaats van gratis te downloaden, is geheel buiten de discussie...

zo zijn er bijv organisaties de gebruikertjes pesten door alleen maar lees toegang te geven tot GIT (een ontwikkel omgeving waarin je broncode kunt bijhouden)... en een binaire vorm (installatie bestand) alleen tegen forse betaling aan te bieden...

soms duurt het maanden / of jaren voor er iemand een alternatieve installer aanbied waardoor honderden mensen hebben moeten kopen omdat ze niet met het gratis om konden gaan...

dit is vaak heel vuil maar niet tegen de opensource licenties...

Precies. Free as in Free Speech not Free Beer

"Vrij" dus.

Als het in het Nederlands het verschil tussen gratis en vrij zo duidelijk is, waarom gebruikt iedereen daar dan Engels voor?

Ik gebruik liever de term open source (of opensource). Freeware kan op twee manieren geïnterpreteerd worden, in Engels èn in Nederlands, dus liever ondubbelzinnig doen.

@REDFISH:
Ik zou jouw automatische updates uitzetten. Lekker veilig. Waarom denk je dat Toyota zijn modellen terug roept? Omdat ze onveilig zijn? Ja, maar ook omdat ze het ethisch besef hebben daar eerlijk over te zijn.

gnu is dat toch niet met je eens

The official definition of “open source software,” as published by the Open Source Initiative, is very close to our definition of free software; however, it is a little looser in some respects, and they have accepted a few licenses that we consider unacceptably restrictive of the users. However, the obvious meaning for the expression “open source software” is “You can look at the source code.” This is a much weaker criterion than free software; it includes free software, but also some proprietary programs, including Xv, and Qt under its original license (before the QPL).

voor meer informatie (of nederlands artikel): https://www.gnu.org/philo...software-for-freedom.html

PS. GNU is wel erg radicaal wat sommige punten betreft

Ja, maar GNU == Stallman en die drijft sommige zaken erg ver door. Anderszijds moet je soms erg principieel zijn om de zaken niet te laten verklooien door een vrij verziekte industrie...

Als het in het Nederlands het verschil tussen gratis en vrij zo duidelijk is, waarom gebruikt iedereen daar dan Engels voor?

Omdat de meeste gebruikers van 'free software' alleen maar geïnteresseerd zijn in het 'gratis' deel. Dat het daarnaast ook nog 'vrij' is zal ze net zoveel schelen als dat hun kopie van MS-Office illegaal is.
Het enige 'vrije' dat voor hun van belang is, is dat het vrij van allerlei gehannes te installeren is.

Ik heb het hier dus duidelijk niet over idealisten die alleen open source software gebruiken, over ICT professionals die het beroepsmatig niet kunnen maken om software illegaal te gebruiken of anderen die dat uit fatsoensprincipes vinden, maar ik heb het over de gemiddelde computergebruiker.

Engelse woord is ook "gratis", echter gebruiken ze meestal toch free.

Dat is in theorie natuurlijk leuk, maar ik denk dat de meeste mensen voor open source kiezen vanwege het kostenaspect

Dat is in theorie natuurlijk leuk, maar ik denk dat de meeste mensen voor open source kiezen vanwege het kostenaspect.

Ik kies gewoon het beste product voor de taak. Als ik een webserver bouw verkies ik Apache boven IIS en als het even kan verkies ik MySQL boven MSSQL. Voor een terminal server gebruik ik wel weer Windows. Mij maakt het dus niet uit.

Het kostenaspect is denk ik ook niet zo belangrijk bij de aanschaf. De grootste kosten maak je toch met support contracten, onderhoud, personeel etc. daar valt de aanschaf bij in het niets.

Ik kies gewoon het beste product voor de taak. Als ik een webserver bouw verkies ik Apache boven IIS en als het even kan verkies ik MySQL boven MSSQL.

Of Apache beter is dan IIS is een moeilijk te winnen discussie, maar dat MySQL beter is dan MSSQL? Puh-lease. MySQL is alleen 'beter' omdat het gratis is, maar MSSQL wint op zo'n beetje alle andere fronten.

Wat dacht je van PostgreSQL?

[...]
Of Apache beter is dan IIS is een moeilijk te winnen discussie, maar dat MySQL beter is dan MSSQL? Puh-lease. MySQL is alleen 'beter' omdat het gratis is, maar MSSQL wint op zo'n beetje alle andere fronten.

Ook hoe goed het werkt op mn Linux-server?

Op welke fronten dan? Heb je er ook onderbouwing voor? Ik weet dat MySQL niet de allerbeste DB is die je kunt krijgen, maar MSSQL, kom op zeg...

En apache vs IIS is niet moeilijk te winnen. IIS komt bij geen enkele andere webserver in de buurt. Wat een draak van een applicatie. Het is traag, instabiel, moeilijk te configureren, mist teveel features, etc.

en toch zijn veel Open Source projecten om deze te implemeteren in een bedrijfsomgeving vaak duurder dan gesloten projecten..

Er zijn maar weinig bedrijven die op OS draaien. Gesloten systemen worden daarnaast ook meer vertrouwd al sluit het bovenstaande bericht dit natuurlijk af.
Ook systemen zoals een ERP e.d. wordt meer gesloten systemen gekozen omdat deze minder updates uitbrengen. Voor functionaliteit. Bug fixes en security natuurlijk uitgesloten.

Omdat fouten opgespoord en gevonden worden, hoe denk je dat men zulks een lage foutenlast haalt? Dat is niet door het te publiceren en daarna niet meer naar om te zien.

Niemand verplicht je trouwens om elke update te installeren, maak je gebruik van een productiemachine, neem dan een versie die zich bewezen heeft en blijf erbij tot de nood daar is om te upgraden.

Dat is hoe men in de oss wereld vaak werkt wanneer stabiliteit noodzakelijk is. Neem nu Debian, na de release van een nieuwe versie word er niets meer aan toegevoegd of verwijderd. Het enige wat ze doen zijn securite fixes backporten naar de huidige versie.

blijf daarbij tot het volgens jouw werkscheme tijd is te updaten.. bij kpn was er ook geen nood om te updaten totdat, je kent het verhaal..

Wanneer een product niet meer actief ondersteund word moet je het uiteraard wel vervangen. Maar zolang een product ondersteund word mag je er van uitgaan dat er de nodige security fixes blijven komen telkens er een bug ontdekt word, ook al zit de vondst upstream.

Wanneer een product niet meer actief ondersteund word moet je het uiteraard wel vervangen. Maar zolang een product ondersteund word mag je er van uitgaan dat er de nodige security fixes blijven komen telkens er een bug ontdekt word, ook al zit de vondst upstream.

maar de end user moet dan wel de updates toepassen anders is het nog ze lek als een mandje

Heb jij ooit windows update in de gaten gehouden? Het gaat tegenwoordig redelijk in de achtergrond maar er zijn zat updates die per week/maand worden uitgegeven.

eringezet worden + nieuwe bugs + weer nieuwe updates

Juist bugs zouden in opensource projecten minder zitten aangezien de code volgens die onderzoek van hogere kwalitieit is.


Ik snap je ergenissen omtrend software die veel updaten maar ik zie de relevantie met dit onderzoek niet

Ik snap je ergenissen omtrend software die veel updaten maar ik zie de relevantie met dit onderzoek niet

Ik niet... in linux is het namelijk binnen de kortste keren bijgewerkt, in tegenstelling tot windows bijv

Na de installatie van een linux distro is het updaten maximaal 10 minuutjes, terwijl je bij windows 7 al snel minimaal een half uur kwijt bent.
bovendien is het voordeel van veel updates, dat veel fouten, mocht je ze hebben, binnen de kortste keren zijn opgelost

[...]

Ik niet... in linux is het namelijk binnen de kortste keren bijgewerkt, in tegenstelling tot windows bijv

Na de installatie van een linux distro is het updaten maximaal 10 minuutjes, terwijl je bij windows 7 al snel minimaal een half uur kwijt bent.
bovendien is het voordeel van veel updates, dat veel fouten, mocht je ze hebben, binnen de kortste keren zijn opgelost

Een half uur? Maak daar maar enkele uren van, zeker als je install nog geen SP1 bevat. Je hebt al enkele update rondes nodig vooraleer je SP1 nog maar kan installeren. Bij linux werk je alles in 1 keer bij, in Windows zit alles zo vast dat het in meerdere keren moet gebeuren.

[Reactie gewijzigd door Blokker_1999 op 24 februari 2012 17:43]

Uhm, dat komt ook omdat je simpelweg met een OS werkt dat of niet ouder is dan 6 maanden of op een LTS versie zit waar alleen de hoogstnoodzakelijke issues opgelost worden.

Te veel updates, te weinig updates het is ook nooit goed

Ik ben blij dat ik zowat dagelijks updates krijg, sterker nog de security updates worden automatisch geïnstalleerd.

De overige update kan je negeren.

Anders gezegd, liever veel updates dan 1 maal in de maand.

ik krijg bij mijn Ubuntu 10 a 15 updates per week, waarvan er meestal 3 voor Firefox en 2 voor Apache/PHP/MySQL zijn de rest is systeem, dan heb ik toch liever "gratis" software dan Windows want daar heb ik er per week toch echt gemiddeld 20 a 25, inclusief basis programma's zoals Firefox en ms office. En ik vind het totaal niet erg om updates te krijgen ik heb liever dat er 40 updates zijn dan dat me systeem crasht omdat er ergens een bug zit die niet is opgelost.

ja, dat is echt een nadeel dat men fouten sneller update, schande dat ze zo'n goede service durven te leveren.

ja en windows heeft niet wekelijks tig updates voor windows office mediaplayers en ga zo maar door?

en dan heb je nog de grote bedrijven die software verkopen en vervolgens gewoon schijt aan je hebben ondanks dat er fouten in de software zitten

[Reactie gewijzigd door computerjunky op 24 februari 2012 20:40]

Niemand dwingt je de vrije software te installeren of om de updates te installeren.

Dat gebeurt in Windows ook hoor, om de dag zo'n beetje een nieuwe update van Java, Flash of Reader.... Of vallen die in jouw opinie ook onder die gratis software?

In Ubuntu kan je het tenminste helemaal automatisch laten gebeuren, in Windows kan dat niet want niet alle software wordt geupdate via Windows Update.

Verder kan je dit in Ubuntu precies zo aanpassen zoals je zelf wil; geen updates, alle updates, alleen security updates, en dan dagelijks, elke week, elke 2 weken etc.

Ik vind het juist fijn dat updates ASAP geinstalleerd worden (in kleinere brokjes) en niet na een jaar ofzo in een servicepack dat enkele honderden MB's groot is, wat enorm lang duurt om te installeren.

Je kan niet een hele beweging (OSS) in een hokje duwen omdat jij denkt dat het er zo aan toegaat... Vergroot je blikveld eens (try Debian stable).

Eigenlijk verbaast dit mij niet zoveel, bij open source projecten heb je gewoon meer onafhankelijke ogen die naar dezelfde code kijken dan bij een proprietair project. Hoe meer mensen er naar kijken, hoe meer fouten er in gevonden worden! Natuurlijk hangt dit bij een proprietair project ook gedeeltelijk af van het type software engineering dat is toegepast, zoals bijvoorbeeld pair programming, maar ik denk toch dat open source projecten in het algemeen gewoon beter 'doorgelicht' worden.

bij open source projecten heb je gewoon meer onafhankelijke ogen die naar dezelfde code kijken dan bij een proprietair project.

Dat wordt lekker makkelijker beweerd, maar in de praktijk is dat helemaal niet het geval. Het simpele feit dat de broncode open is, betekent niet dat je zomaar eventjes de code kan lezen. Iedere code die een significante omvang bereikt is te complex om eventjes door een derde ingekeken te worden. Daarom dat bij opensource het alsnog maar een zeer beperkte groep is die daadwerkelijk met de code bezig is. En of dat dan uiteindelijk een grotere groep is dan bij proprietair is maar zeer de vraag.

Is het niet zo of zou het niet zo kunnen zijn, dat een beperkte groep de gehele code bewerkt maar ook meerdere groepen kleine delen van de software bewerken, zonder verstand te hebben van andere delen?
En zo er toch weer meer mensen met de code bezig zijn?

Mja, hoe wordt dit getest? Ik bedoel, een knopje wat niet helemaal lekker werkt vs het hele programma werkt niet goed. Mijn ervaring met open source is dat het vaak vol zit met bugs in ieder geval.

Mijn ervaring met open source is dat het vaak vol zit met bugs in ieder geval.

mijn ervaring is eerder het tegenovergestelde, en ik ben toch al zeker 13 jaar bezig met OSS. Zelfs alpha versies die een keer per ongeluk (human error) op een productie systeem werden gezet waren dusdanig stabiel dat we ons serieus even hebben afgevraagd of we echt wel zouden downgraden.

ligt dit nu aan mij of is dit keihard nietszeggend?

ja, Linux, PHP en ProgresSQL worden keurig geschreven blijkbaar.

ik zie niets over wat een "fout" is.
is dat een fout in het schrijven (' ipv " of vergeten een statement af te sluiten) ?
of is dit een fout in het programma (een functie vergeten te implementeren) ?

wel erg vaag.
ook zijn er grote populaire projecten gepakt voor open source, maar er wordt totaal niet gemeld wat voor closed software er getest is. was dit een wijverspreid pakket of was dit iets wat henkie op zijn zolderkamer heeft geprogged en de broncode niet openbaar maakt?

lekker nietszeggend.

Er staat toch dat ze naar de code keken? Zal dus niet om functies gaan aangezien dat ook helemaal niet logisch zou zijn als we het over een kernel hebben.

Er staat ook niet bij dat welke open source projecten ze onderzoeken, er waren gewoon 3 open source projecten van zeer hoge kwaliteit

[Reactie gewijzigd door bantoo op 24 februari 2012 17:46]