Linux-bug veroorzaakt gegevensverlies

Er is een bug in de Linux kernel gevonden die in speciale gevallen tot gegevensverlies kan leiden. De fout zit in versie 2.4.20 van het hart van het besturingssysteem. Deze kernel is 28 november gereleased maar is nog niet verwerkt in de meeste distributies. Afgelopen vrijdag is de bug opgelost, twee weken na de definitieve release van de kernel. In juli werd al een fout gevonden die hier mee te maken had, zegt Andrew Morton, schrijver van de patch. Om in de toekomst dit soort fouten te voorkomen zijn de programmeurs voor de opsporing van bugs betere programma's gaan gebruiken. Het risico van deze softwarefout is echter niet zo groot omdat het dataverlies alleen optreed in speciale omstandigheden. Het ext3 file system zou op een speciale, trage en weinig voorkomende manier gebruikt moeten worden. Als daarna het file system voor de dataopslag losgekoppeld wordt zal de data van de voorgaande dertig seconden verloren kunnen gaan:

However, the risks of the recent Linux data-loss bug are reduced because it only appears in a particular circumstance: First, an administrator has to select an unusual mode for Linux's ext3 file system software, which controls how data is stored on hard drives; then the administrator must disconnect the file system where the data is saved. In that case, all data that should have been saved on the hard drive in the previous 30 seconds could be lost.

The data-loss problem is "not very severe," said programmer Andrew Morton in an e-mail interview. It was Morton who pointed out Sunday that the bug hadn't been fixed and who posted a patch Friday.

Morton added that the bug is contingent on using ext3 in "a specialized mode, which in practice is rather slow. It doesn't offer any realistic advantages over the default...mode, and nobody uses it much. This is why the bug lay dormant for three months."

Reacties (100)

[Rukapul]

Uit dit soort meldingen leid ik af dat Linux nog zeker niet volwassen is. Ik bedoel dan niet de kernel op zich, maar meer hoe er met Linux wordt omgegaan zoals de grote distributies nu doen. Het argument daarvoor is dat de kernel nauwelijks getest wordt voor deze vrijgegeven wordt. Natuurlijk zijn er de development en release versies, maar feature adding lijkt de hoofdzaak terwijl de periode om eens fatsoenlijk release versies te testen er bij in schiet. Zeker van de grote distributies zou ik toch verwachten dat ze 3 maanden tot een half jaar de tijd nemen om een kernel te testen na een code freeze voordat ze hem in een distributie meenemen. Nu zie je regelmatig dat eindgebruikers als testkonijn dienen voor stabiele versies van de kernel. Het wordt vervolgens wel snel gefixed, maar zeker de grote distributies hebben toch ergens de plicht om hun afnemers met name een veilig product te bieden ook al loopt deze iets achter met de features (zie FreeBSD stable).

[TumbleCow]

Niet volwassen zeg je?

Windows lijkt me een vrij volwassen operating system. Toch had juist windows er een tijdje geleden last van dat het data niet goed wegschreef bij het afsluiten, en dat niet alleen met een specialistische mode, maar praktisch ALTIJD als het systeem sneller was dan 800 (?) Mhz.

Of linux wel of niet volwassen is laat ik in het midden. Wel zeg ik dat je op grond van een dergelijke minor bug moeilijk kan concluderen dat een operating system nog niet volwassen is. Onze vrienden uit redmond hebben net zo goed last van dergelijke slordige foutjes.

[rootlinux]

Een soortgelijke bug zat ook in windows 98SE.

Als je veel disk cache op de disk had en je de PC uitzetten via startmenu shutdown (power off) dan was je partitie ook met groote kans omzeep. Ik heb hier flink mee gestoeid voordat ik doorhad dat windows de PC net iets tes nel het down bracht en de disk geen tijd had om de disk cache te legen. Een patch die een korte wait inbouwde loste het probleem op.

[SED]

tjonge windows 98 vergelijken met Linux is wel een erg sterke zet

[Verwijderd]

Het argument daarvoor is dat de kernel nauwelijks getest wordt voor deze vrijgegeven wordt.

Het vrijgeven is het testen.. zo werkt de open-source wereld.
Ook is dit een minimaal voorkomende bug, welke ook voorkomen in echt veel geteste producten als Windows

Zeker van de grote distributies zou ik toch verwachten dat ze 3 maanden tot een half jaar de tijd nemen om een kernel te testen na een code freeze voordat ze hem in een distributie meenemen.

"Deze kernel is 28 november gereleased maar is nog niet verwerkt in de meeste distributies."

[Verwijderd]

Eh, beter lezen, er staat zelfs expliciet bij:

Deze kernel is 28 november gereleased maar is nog niet verwerkt in de meeste distributies.

Bv RedHat levert nog 2.4.18 met een serie eigen patches. Inderdaad, omdat het beter is een stabiele kernel te hebben en daarin een paar bugs te patchen dan om de allernieuwste te gebruiken waar misschien nog nieuwe onbekende bugs inzitten.
Ze doen dus precies wat jij van een "volwassen" operating system verwacht!

[deadinspace]

Zeker van de grote distributies zou ik toch verwachten dat ze 3 maanden tot een half jaar de tijd nemen om een kernel te testen na een code freeze voordat ze hem in een distributie meenemen. [...] Het wordt vervolgens wel snel gefixed, maar zeker de grote distributies hebben toch ergens de plicht om hun afnemers met name een veilig product te bieden ook al loopt deze iets achter met de features

Ooit naar Debian Stable gekeken? De quality assurance daarvan is namelijk wel goed.
Debian 3.0 (vier maanden oud) heeft namelijk als default kernel 2.2.20, omdat 2.4 nog niet stabiel geacht werd voor alle architecturen (uiteraard kun je wel een 2.4 kernel gebruiken als je dat wilt). Dat komt omdat het dus grondig getest wordt.

Als je kritiek het testen (of gebrek daaraan) is kun je niet zeggen dat GNU/Linux al dan niet volwassen is, dat kun je hoogstens over specifieke distributies zeggen.

[wzzrd]

Niet volwassen? Omdat er een bug inzit? Als dat een criterium is voor 'niet volwassen', bestaan er geen volwassen besturginssystemen. De manier waarop je over het implementeren van een nieuwe kernel door distro-makers praat, laat overduidelijk zien dat je niet weet waar je het over hebt. Hoe kan een distro-maker nou een code-freeze inlassen? (Daar 'gaan' ze niet over nl.) Wat heeft feature adding in vredesnaam met deze bug te maken? (Het gaat om kernel 2.4.20, daar worden nauwelijks features meer aan toegevoegd, daarvoor moet je bij 2.5.x zijn).
Daarnaast: op productie-systemen wordt deze kernel door de eindgebruikers écht niet geinstalleerd hoor. Ook FreeBSD-stable heeft overings bugs genoeg.

[arjankoole]

Ook FreeBSD-stable heeft overings bugs genoeg

da's nogal logisch, -STABLE is nog altijd een development tree, alleen iets minder bleeding-edge dan -CURRENT dat is. Okay, dat de meeste ISP's STABLE d'r bij pakken en draaien is meestal puur en alleen omdat het de laatste bugfixes e.d. heeft. Maar in principe raden ze het bij FreeBSD niet aan.

[MikeN]

Het wordt vervolgens wel snel gefixed, maar zeker de grote distributies hebben toch ergens de plicht om hun afnemers met name een veilig product te bieden ook al loopt deze iets achter met de features (zie FreeBSD stable).

Goh, lijkt wel een beetje op Debian Stable

[Verwijderd]

Wel eens een windows NT4 zonder servicepack gedraaid. Op een snelle server en met veel dataverkeer treed hierbij al na enkele uren datacorruptie op. Dit is ook de reden dat windows NT4 standaard al servicepack 1 heeft bij een nieuwe installatie.

[Verwijderd]

ik ben het niet helemaal met je eens:
de grote distributies testen wel degelijk, ik ben bijvoorbeeld aangesloten bij redhat network, een soort windows update, en de updates die ik krijg zijn niet altijd het nieuwste van het nieuwste maar wel de stabielere en geteste

[RG]

Uit dit soort meldingen leid ik af dat Linux nog zeker niet volwassen is. Ik bedoel dan niet de kernel op zich, maar meer hoe er met Linux wordt omgegaan zoals de grote distributies nu doen. Het argument daarvoor is dat de kernel nauwelijks getest wordt voor deze vrijgegeven wordt.

De kernel wordt wel degelijk goed getest voordat ie wordt gereleased. Maar je kunt nooit garanderen dat er nergens in de Linuxkernel een fout zit. En als er dan zo'n fout aan het licht komt die vrijwel niemand treft door een of andere feature waar niemand van gehoord had, dan is Linus ineens niet volwassen.

Natuurlijk zijn er de development en release versies, maar feature adding lijkt de hoofdzaak terwijl de periode om eens fatsoenlijk release versies te testen er bij in schiet.

Onzin, er zijn vrijwel geen features meer bijgekomen de laatste maanden in de 2.4 kernel. En anders is er altijd nog de 2.2 serie.

Zeker van de grote distributies zou ik toch verwachten dat ze 3 maanden tot een half jaar de tijd nemen om een kernel te testen na een code freeze voordat ze hem in een distributie meenemen. Nu zie je regelmatig dat eindgebruikers als testkonijn dienen voor stabiele versies van de kernel. Het wordt vervolgens wel snel gefixed, maar zeker de grote distributies hebben toch ergens de plicht om hun afnemers met name een veilig product te bieden ook al loopt deze iets achter met de features (zie FreeBSD stable).

De FreeBSD kernel kan nog niet half zoveel als de Linux kernel. Je kunt moeilijk verwachten dat er dan net zoveel of minder fouten in zitten. Overigens zijn er genoeg distributies die afwachtend zijn wat betreft kernels, zoals Debian stable.

[arjankoole]

De FreeBSD kernel kan nog niet half zoveel als de Linux kernel. Je kunt moeilijk verwachten dat er dan net zoveel of minder fouten in zitten. Overigens zijn er genoeg distributies die afwachtend zijn wat betreft kernels, zoals Debian stable.

pardon?? hoe kom je in godsnaam tot die conclusie? Okay, het ondersteund lang niet alle 'speeltjes' die consumenten gebruiken, maar FreeBSD word dan ook meestal als server gebruikt. D'r zijn genoeg mensen die het als workstation gebruiken, maar die draaien weinig poespas d'r op, en hebben dat ook niet nodig.

enne, als de BSD kernel zo weinig kan, hoe komt 't dan dat 't ding Linux binairies sneller draait dan Linux zelf?

[lintux]

Uit dit soort meldingen leid ik af dat Linux nog zeker niet volwassen is.

Sure... Jij maakt vast ook wel eens foutjes, dus dan ben jij ook nog niet volwassen?

IOW: Welk systeem/programma is dan wel volwassen... "Hello World"?

[Verwijderd]

Het is te zeggen... De distro's, zoals Redhat, geven nooit een kernel weg zonder dat ie volkomen getest is. Dat dergelijke probleempjes komen is dan niet bizarre, nog tekenend voor het systeem, immers hoeveel problemen hebben "andere" OS'en niet bij release? Wat dan weer heel goed is bij RedHat is bijvoorbeeld het gratis abonement op RHN waardoor je meteen bericht krijgt van dergelijke issues alsmede de remedie patch, dit process kan je tegen geringe betaling voor verscheidenen configuraties automatische laten uitvoeren. Voor de prive gebruiker blijft het gratis, en het werkt zeer goed.

Neen, ik denk dat linux weldegelijk volwassen is en dat het aan de distro bakkers om de zaken goed te implementeren.

[BadRespawn]

"Uit dit soort meldingen leid ik af dat Linux nog zeker niet volwassen is."

Dan is Windows nog minder volwassen want daar zijn meer van dit soort meldingen over.

[Verwijderd]

*Zucht*...
En is Windows wel volwassen dan? Er zijn een hoop meer bugs in Windows dan in Linux, en bij Windows zijn ze echt gevaarlijk, terwijl dat bij Linux nauwelijks voorkomt.
Ook moet je om bugs in Windows op te lossen vaak lang wachten op een service-pack, terwijl je het bij Linux met een simpele patch op kan lossen.

[voodooless]

Wat is dat nu voor een onzin: in freeBSD of windows kan net zo makkelijk een bug insuipen als in elk ander OS/kernel. Dit zegt niets over de "volwassenheid" van de kernel. Je moet ook kijken naar het toepassingsgebied van de linux kernel t.o.v. FreeBSD. Dit wordt in het geval van FreBSD in gevallen gebruikt waar extreme veiligheid en betrouwebaarheid nodig is. Met linux mag dat dan iets minder zijn, maar het is nog altijd geen slecht systeem met een degelijke ondergrond. Distriburies testen overigens wel degelijk hun kernels op bugs en stabiliteit voordat ze een nieuwe versie uitbrengen! Vandaar dat de meeste distributie kernels ook flink gepatched zijn.

[Verwijderd]

zo'n bug niet in windows?

hahahah grapjurk
ik weet niet of jij ooit 60gb schijven onder een windows 2000 bak hebt gehad? ikke wel dus.

en een orginele out of the box splinternieuwe win2k + maxor 60gb hdd gingen dus wel mooi raar lopen doen

je raad het nooit, data loss all over te place.
eerst wat kleine stukjes, daarna wat files, daarna stukjes FAT32 .

dat is een veel grotere fout dacht ik zo, en alles ging stuk, niet alleen af en toe of met hele vreemde eigenschappen oid.

de combinatie van een 600hmz of meer cpu + een grote hdd met in verhouding minder cache en win2k zonder service packs was de boosdoener,

de cpu was te snel voor de hdd, waardoor deze stukken uit z'n cache liet vallen en zo dus data corrupted.

dit was een fout in win2k advanced server.
en ik moest zelf op zoek naar een oplossing totdat SP2 uitkwam, (gelukkig kon ik een beta vinden zodat dit niet al te lang duurde maar toch)...

dus denk eerst eens na voordat je zoiets zegt, zodra testen niet commercieel haalbaar of handig is doet een commercieel bedrijf het niet,
de open-source wereld daarintegen zal altijd testen en waarschijnlijk een stuk beter en netter omdat bij hen geen commerciele belangen meespelen als hoe kunnen we de uitgaven verminderen?...

[voodooless]

Er heeft ook nooit iemand beweert dat linux bugvrij is! (die dat wel deden kunnen beter weer naar windows overstappen)

Kijk eens hierboven en een stuk lager, daar staat tal van M$ bugs die met dataloss te maken hebben. Het is idd nogal logisch dat zo'n bug niet in windows kan voorkomen, windows heeft immers geen ext3, maar het nep journaling filesysteem NTFS.

[Verwijderd]

Ik zeg niet dat dit probleem niet bestaan heeft maar volgens mij is de situatie die jij schetst even zeldzaam als het probleem dat zich nu met linux voordoet.

No offense, maar wie installeert er nu een W2K advanced server op een fat32 partitie, laat staan 60 gig in fat32

edit: sorry deze reactie moet onder de post van Scratch staan

[Verwijderd]

ter illustratie heb ik de advnaced server gekozen aangezien deze het duurst is en aangezien deze bij mij als eerste geinstalleerd was (had even niets anders liggen, en ja wel legaal)
de zelfde fout zat in professional en server.
wie partitioneert er nou 60gb met fat32?
ik denk dat je daar best 60% van de eigenaren van zon disk hier op tweakers onder kun rekenen, en dan nog, als t niet een logische installatie is, hoeft het dan gelijk niet te werken? ik vind het een zeer slechte zaak dat een complete range aan producten van de grootste software producent ter wereld hier zo slect mee om gaat, pas in SP2 was er een patch en dan nog als MS 85 winst maakt op deze os'en dan vind ik dat ze toch verd*mme echt wel eens wat meer mogen gaan testen, vind je ook niet?

ps je edit heeft weinig nut, de t.net frontpage kan niet dieper threaden

[Jordi]

Leuk hoe C|net een geweldige lap tekst weet te maken, maar op geen enkele manier meldt dat het alleen gebeurt in geval van "data=journaled", terwijl de default "data=ordered" is, en zich beperkt tot "unusual mode" voor EXT3. Fijn, die diepgang.

Anyway, dat moet je dus met opzet actief met eigen verstand zo hebben ingesteld. Meestal doet men dat niet dus de kans dat je last hebt van deze bug is vrij klein.
Grappig om te zien wel dat Windows ME (wellicht ook andere versies), met een heeeel andere technische oorzaak, ongeveer dezelfde bug had.

Rukapul: je hebt een punt, maar ik ken geen distro die shipt met 2.4.20. En als men een beetje bij verstande is, komt die er ook niet

Owja, mocht je last hebben van deze bug en toch veilig willen shutdownen/rebooten: gebruik 'sync' voor de unmount.

[zomertje]

Dat vond ik als nieuwsposter ook jammer, het schrijven van een stukje is een stuk leuker met goede informatie. Waar heb je deze info vandaan trouwens?

[Jordi]

http://kerneltrap.org/node.php?id=515

[iKiddo]

Valt behoorlijk mee hoeveel (weinig?) gebruikers journallig gebruiken, het is namelijk het grote pluspunt van ext3 tegenover ext2 !!

(Redelijk veel ext3 gebruikers gebruiken -j, vooral in meer 'geavanceerde' distro's zoals gentoo, lfs etc. )

[Verwijderd]

Voor alle duidelijkheid: "data=ordered" wil niet zeggen dat je geen ext3/journaling gebruikt. Sterker nog: dit is de default instelling als je ext3 mount. Alleen als je je ext3 partitie expliciet mount met de optie "data=journaled" treed deze bug op en dus heeft er bijna niemand last van.

Wat je zegt gaat dus niet op: gentoo/slackware/debian, enz. voegen namelijk de optie "data=journaled" nooit zelf toe aan je fstab.

[wiho]

Ja, maar... de standaard ext3 journaling mode is metadata-journaling (alleen veranderingen aan de filesystemstructuur worden in 't journal bijgehouden). De bug heeft alleen betrekking of data-journaling (wanneer ook veranderingen aan de *inhoud* van bestanden in 't journal worden bijgehouden), en die mode is een stuk minder gangbaar.

Vandaar de terechte conclusie dat weinig mensen last zullen hebben van deze bug.

(DaZaffiro was me net ff voor... )

[Verwijderd]

For the record:
Eerste melding van het bestaan van de bug was om 9:11, 1 dec 2002.

Eerste fix (hielp helaas niet) na 40 minuten.
Tweede fix (bracht een ander probleem terug): na 23 uur en 6 minuten.
Derde, uiteindelijke fix: al na 31 uur en 26 minuten.

fix:
--- linux-2.4-ext3merge/fs/ext3/super.c.=K0027=.orig 2002-12-02 15:35:13.000000000 +0000
+++ linux-2.4-ext3merge/fs/ext3/super.c 2002-12-02 15:35:14.000000000 +0000
@@ -1640,7 +1640,12 @@
sb->s_dirt = 0;
target = log_start_commit(EXT3_SB(sb)->s_journal, NULL);

- if (do_sync_supers) {
+ /*
+ * Tricky --- if we are unmounting, the write really does need
+ * to be synchronous. We can detect that by looking for NULL in
+ * sb->s_root.
+ */
+ if (do_sync_supers || !sb->s_root) {
unlock_super(sb);
log_wait_commit(EXT3_SB(sb)->s_journal, target);
lock_super(sb);

[EfBe]

Lekker belangrijk na hoeveel minuten een 'fix' voorhanden was. Het gaat erom na hoeveel DAGEN een door en door geteste fix klaar is om op productiesystemen te worden geimplementeerd. MS heeft soms na 1 dag ook een hotfix klaar, maar dan weet je ook dat het nog niet door en door getest is (Dat duurt nl. enkele dagen) en indien je dus die fix op een productiesysteem implementeert loop je grote risico's. (gezien je eigen lijstje zou je bv na de 1e fix een systeem hebben gereboot zonder dat dat nodig was geweest. Wellicht kost een reboot veel geld, niet zo nuttig dus).

[Verwijderd]

Trouwens d'r was al meteen een workaround beschikbaar, gelijk met de vondst van de bug, alleen noem ik dat geen "fix":

A workaround is to run `sync' before unmounting.

Grappig dat je het noemt trouwens: dit probleem treed alleen om als je unmount en in productie-omgevingen doe je dat alleen als opnieuw opstart, dus ik denk ook niet dat de meeste admins, mochten ze uberhaupt al "data=journaled" gebruiken, zoiets hadden van "we gaan eens lekker opnieuw opstarten om deze bug te verhelpen". Ik denk dat ze snel een "sync" commando in hebben gevoegd in hun shutdown-scripts...

[voodooless]

En waar staat dat dit niet door een door getest is??

De luitjes die met de patches komen we weten waar ze het over hebben, en weten vaak al uit hun hoofd of iets goed gaat of niet, zonder dat er ook maar iets fysiek getest is. Als ze hun fix dan klaar hebben, kunnen ze heel snel met een paar doelmatige testen gemakkelijk zien of de fix goed werkt of niet

[EfBe]

En waar staat dat dit niet door een door getest is??

Omdat je niet een intense test uit kan voeren op verschillende configuraties met verschillende applicaties binnen zo'n korte tijd. Wellicht breekt deze fix weer iets anders, weet jij dat? Nee. Dat weet je alleen na intensief testen. Ik snap de nadruk op de haast echt niet. Mensen met mission critical systemen willen dat die bakken up blijven. die gaan echt niet na elke patch die handel rebooten (bij een kernelupdate), die wachten een maand of wat, totdat wellicht andere mensen additionele info hebben gegeven dat de patch goed is. Haastige spoed is NOOIT goed bij productiesystemen, tenzij je niet anders kan, bv een security flaw die je ala minuut moet fixen anders ben je het haasje.

De luitjes die met de patches komen we weten waar ze het over hebben, en weten vaak al uit hun hoofd of iets goed gaat of niet, zonder dat er ook maar iets fysiek getest is. Als ze hun fix dan klaar hebben, kunnen ze heel snel met een paar doelmatige testen gemakkelijk zien of de fix goed werkt of niet

Nee dat kun je niet. In zn algemeenheid kun je NOOIT zeggen of een fix goed is, tenzij je daarvoor een bewijs levert in bv pre/post conditielogica. Nu gaat het hier om een detail in een FS, zometeen gaat het om een detail in een library, waar bv pakket XYZ omheen werkt met eigen code. Fix je die library dan werkt XYZ niet meer. Dat weet je alleen door tests. Ja, dat is prutswerk van de firma die XYZ heeft gemaakt (of oss softwaredevelopers) maar mensen die het programma gebruiken zijn wel afhankelijk daarvan. Ergo: na tests pas implementeren, tenzij je het niet zoveel kan schelen of de patch wel/niet werkt. Ieder OS hangt tegenwoordig van vele onderdelen aanelkaar. Dat impliceert automatisch aannames dat een ander onderdeel goed werkt en wel op die en die manier. Indien dat niet het geval is en je kunt niet wachten op een fix van dat onderdeel gebruiken sommigen workarounds. Die kunnen je opbreken.

Verder is het wellicht zo dat de ontwikkelaar van een bepaald stukje code snel weet waar een bug zit (heb ik zelf ook) alleen de gevolgen van een fix kunnen vaak ruimer zijn dan initieel gedacht. Alleen met tests kom je daar achter (of met bewijzen, maar die nemen veelal ook veel tijd in beslag).

[voodooless]

Verder is het wellicht zo dat de ontwikkelaar van een bepaald stukje code snel weet waar een bug zit (heb ik zelf ook) alleen de gevolgen van een fix kunnen vaak ruimer zijn dan initieel gedacht. Alleen met tests kom je daar achter (of met bewijzen, maar die nemen veelal ook veel tijd in beslag).

vandaar dat er ook 3 fixes waren: een werkte niet, de tweede bracht een oud probleem naar boven, en de laatste was wel goed. Hieruit kun je dus al afleiden dat er wel degelijk getest is. En boevendien is het zo (zoals hierboven al een aantal keren is aangespitst) dat het testen in feite duur de gebruiker wordt gedaan, volgens de OSS filosofy. Dat houd natuurlijk niet in dat het van te voren totaal niet getest is. Dat is zeker gebeurt. Een release wordt daarom ook pas vrijgegeven als men vrij wel zeker is dat een onderdeel werkt. M$ brengt ook alpha's, beta's een releace candidates uit van hun software. Het verschil is dat dat deze alleen voor uitgezochte personen beschikbaar is. Bij OSS is alles voor iedereen beschikbaar. Wat je er dan ver mee doet is je eigen zaak. En als er dan eens een bugje in een release zit, so what, mensen maken nu eenmaal fouten, of het nu linux, M$, BSD of andere mensen zijn....

En dan krijg je natuurlijk het gezellige moddergegooi over wekl OS nu beter/sneller/veiliger is. Altijd leuk om daaraan mee te doen

[Verwijderd]

Als je perse de nieuwste kernel moet hebben en het kost je geld als je vervolgens een keer extra moet booten, dan moet je toch eens nadenken of je niet erg "on the edge" leeft.

Ik zou mijn geld niet in zo'n bedrijf steken

[Verwijderd]

Dat is inderdaad één van de voordelen van open-source software: met z'n allen kun je sneller werken aan de oplossing van het probleem.
Microsoft zou met zo'n probleem eerst een paar dagen de oorzaak en mogelijke oplossingen gaan zitten opsommen, vervolgens kijken of het waardevol is het op te lossen door een patch uit te brengen, en zo niet, de bug op de lijst van de volgende Service Pack zetten. Om te toch?

[gumkop]

Grappig dat er nu al 50 reacties zijn op een bug die in de praktijk in 0,00003 van de gevallen zal voorkomen, zo uniek is hij. Ik zou het een verademing vinden als er bij Linux / Microsoft topics op een dag geen flames meer gepost zouden worden.

Edit, 4real, moddergooien is idd op zijn tijd leuk, maar om elke dag 50x in de topics exact weer hetzelfde te lezen gaat iedereen vervelen.

[voodooless]

Hoezo: een beetje moddergooien moet kunnen, of word dit nu ook al als DDOS attack gezien

[XTerm]

Deze bug is niet de ramp die hij lijkt.
Eerst en vooral komt hij enkel voor op Ext3 filesystems die data opslaan in hun journal. Dat is een speciale optie die de filesysteemsnelheid ernstig terugschroeft maar, ironisch genoeg, het quasi onmogelijk moet maken dat je door crashed en reboots data verliest.
Gelukkig is dit niet de default mode waardoor slechts een heel kleine minderheid wordt getroffen. De dag dat IK wist dat de bug er was was e al een patch beschikbaar op kernel.org in de vorm van een ac1 patch.
Afleiden dat 'linux'' daardoor niet 'volwassen'' is is pure onzin, maar ik vind het jammer dat zo'n ernstige bug wordt gevonden in de stabiele kernelreeks, niet lang na de ptrace bug (waardoor alle 2.4 kernels konden crashen door een systemcall vanuit userland).

[Verwijderd]

Dames en heren:

wat is testen eigenlijk? voor velen onder U is testen het opsporen van bugs en die dan verhelpen. Maar een ECHTE softwaretester weet dat het niet gaan om het verhelpen van bugs, maar om RISICOBEPALING. Je test een stuk software en met je bevindingen stel je jezelf de vraag "welke risico's loop ik als dit stuk software toch uitgeleverd wordt, en is dat acceptabel?". Geen enkel stuk software is gegarandeerd 100% bugvrij, dus je moet de risico's afzetten tegen de baten. Je kunt dan besluiten om een software, ondanks bugs, uit te leveren, bijvoorbeeld omdat de kans dat het probleem werkelijk optreedt ongelofelijk klein is (zoals bij bovengenoemd probleem). In de open source wereld worden dergelijke problemen snel en kordaat opgelost, waar juist de commerciële bedrijven er voor zouden kiezen om het probleem niet te fixen! Ik bedoel: zelfs in Windows XP zit nog steeds de bug dat als je in een common dialog een paar bestanden kiest, die niet in de aangegeven of alfabetische volgorde worden ingeladen. Lekker makkelijk Zo zijn er nog wel meer dingen die Microsoft niet oplost. Nog sterker zelfs: om het aantal getelde "Windows Bugs" onder controle te houden, wordt niet ieder probleem ook werkelijk in de Knowledge Base opgenomen.

Drie hoeraatjes voor Open Source!

[Verwijderd]

Mogen alle Windows gebruikers nu eindelijk eens een keer gaan schelden op Linux?

Ik vind het altijd zo mooi dat zodra er een bug in een Windows-versie bekend wordt gemaakt, alle Non-Windows gebruikers direct beginnen met opmerkingen als: 'zie je wel' en 'Windows is troep', blablabla..

Mensen, nobody's perfect!!

[beany]

Mogen alle Windows gebruikers nu eindelijk eens een keer gaan schelden op Linux?

Doen jullie toch al...

De grap van het verhaal is dat wanneer wij linux users lachen/mopperen om/op windows, de bug er nog is, en nog een week of wat zal blijven. In dit geval gaat het om een bug die al is gefixed. Dit is een duidelijk voorbeeld van hoe de linux community werkt: ARRGGHH, A BUG!!! Now, lets call my girlfriend and tell her i'll be busy this weekend. Lets fix it!

[Verwijderd]

ARRGGHH, A BUG!!! Now, lets call my girlfriend and tell her i'll be busy this weekend. Lets fix it!

Beter kan je inderdaad het stereotype Linux-gebruiker niet omschrijven...

De Windows gebruiker heeft echter wel een sociaal leven, en zal denken, maandag 9:00 zijn ze de eerste, tot die tijd doen we het maar even met die bug....



No offence!

edit:

Zet je 'No offence!' en en smiley neer, krijg je nog -1 Troll... Hebben jullie nou echt geen gevoel meer voor een beetje humor, of hebben we hier te maken met allemaal single linux gebruikers die een spiegel voorgehouden worden....

[EfBe]

(reactie op bobco)
Ooit een kernel gedebugged? Weet je hoe dat moet? En deze bug had jij meteen kunnen fixen omdat je een systeem klaar had staan met die configuratie of optuigbaar in die configuratie?

OSS is erg leuk, maar overdrijf de openheid van sourcecode aub niet zo. Maar een handjevol kan effectief iets wijzigen aan een kernel's code, het compileren, testen en in productie nemen. Verreweg de meeste linuxgebruikers piepen wel lekker mee met de zealots maar veel meer dan 'hot-air' is het niet.

En no offence, maar wat heb je liever: een patch die getest is door een batterij testers op testbakken (bv bij Redhat) wat enige dagen kan kosten, of een patch gemaakt door L33tC0d3r uit Zweden, die, omdat het compileerde, de patch als 'good' kwalificeerde? Voor productiesystemen: absoluut het 1e. Wat is dan het verschil met closed source development? 0.0.

[progster]

Eigenlijk wanneer je een patch schrijft en je geloofd dat hij werkt stuur je deze naar de developper van het originele product met de nodige bewijzen en de source code. Deze zal die dan nog eens testen en als de patch "good" is zal hij die signeren en is het een officiële patch. Dat is hoe open source werkt ;-)

[SirBlade]

Nee, de linuxgebruiker doet het dat weekend met de bug, de windowsgebruiker doet het dat weekend met de vriendin van de linuxgebruiker.

[Bobco]

Kun je dan als Windows-gebruiker even opnieuw compileren? Een van de pluspunten van open-source is dat je, in principe, alles zelf zou kunnen fixen. Uiteraard ben je in de praktijk nog heel vaak van anderen afhankelijk, maar de theoretische mogelijkheid bestaat.

[jiriw]

<Reactie op Otis>

Ok hier dan een reactie van een enorme computer enthousiast, maar eentje die niet van het nivau "Bring it on, daddy" als het om kernel hacking gaat.

Ik kan REDELIJK C programmeren (* beknopte CV onderaan de post), ik ben hartstikke enthousiast van Linux, en NEE, VEEL KERNEL CODE IS NIET MOEILIJK OM TE BEGRIJPEN. Het enige wat nodig is om de meeste code te begrijpen is ong. MBO Informatica programmeerkennis en RTFMs!!!!. Er zijn stukken kernelcode waar ik de ballen verstand van heb, maar daar zijn slimmere jongens voor. Met de kernel spelen is hardstikke leuk, en veel drivers voor "randapparatuur" zoals de gedeelten van de NIC's en de OSS sound modules zijn helemaal niet moeilijk om te begrijpen. Ja ik blijf ver weg van het memory management systeem of file system handling; dat gaat me over het algemeen boven de pet. Maar het schrijven van een driver voor een simpel stukje ISA hardware zal voor mij geen enkel probleem zijn (zoals van een zelf gemaakte multi i/o kaart o.i.d.) Nogmaals IK BEN ECHT GEEN WIZZKID in C programmeren, maar iedereen die er een beetje tijd in wil steken kan best een eind komen.

Oh, ja. Een "kernel update" (of vaak enig andere update) betekent bij het niet nader genoemde closed source OS een reboot. Bij het niet nader genoemde open source OS is het vaak: rmmod - insmod - vrolijk door werken. 0 downtime Ook toepasbaar bij het aanpassen van je configuratie. Het heeft wel HEEL lang geduurt voordat je bij dat ene OS eindelijk je IP adres kon veranderen zonder te rebooten. En het is nog steeds zo dat iedere onbenullige randapp. hardware error een BSOD geeft, terwijl je bij OSS vaak ff een moduletje swapt of een configje aanpast en het is okee. En als er dan echt stront aan de knikker is krijg je tenminste een FATSOENLIJKE foutmelding in je log i.p.v. error 0EX1B2D4F !@*($@%.

*beknopte CV:
Ooit Natuurwetenschappen geprobeerd te studeren; 11 studiepunten daar in; HIO voor 2 jaar studiepunten, niet afgemaakt, want m'n studietijd zat er op/geld was op/ging te veel "vrije" tijd inzitten; daarna gaan werken voor een klein software bedrijfje (jah proprietary software maar de software is van ondergeschikt belang: 95% van de kosten gaat op aan vertalers. Maakt vertaalsoftware ned-du-en-fr-sp-it) waar ik nu werk aan een PALM OS versie voor een 6 talig vertaalsysteem, zodat de "woordenboeken" gemaakt door de vertalers ook op je Palm beschikbaar zijn.

[Verwijderd]

Dus eigenlijk wil je zeggen dat Windows gebruikers nog een prive leven hebben (en een vriendin) en Linux gebruikers niet (en binnenkort ook geen vriendin meer).

[k7of9]

Doen jullie toch al...

Hoe bedoel je generaliseren en vooroordelen? Er bestaat geen jullie of wij.

Wij Linux users, wij Windows users...er zijn ook mensen die beiden naar tevredenheid gebruiken hoor. ik ben er een van.

En je voorstelling van de bug-afhandeling door MS is zwaar overdreven.

Het is gewoon de waarheid dat blijkbaar Linux fanaten wel mogen zeiken om bugs in Windows, maar als er iets over een bug in Linux wordt vermeld dan is het weer een ander verhaal. Met als resultaat dat deze post waarschijnlijk als overbodig, flamebait, troll of overgewaardeerd gemodereerd zal worden.
Een bug is een bug, hoe ernstig dan ook. Blijkbaar belangrijk genoeg om als nieuws te vermelden iig.

Ik begrijp gewoon echt niet waarom mensen niet gewoon kunnen gebruiken wat ze willen zonder perse het andere te moeten afkraken. Waarom is dat toch? Ik zou echt graag eens willen horen waarom zoveel mensen op die manier redeneren. Waarom moet het altijd Windows vs. Linux zijn, en AMD vs. Intel, en Ajax vs. Feyenoord....etc, etc, etc.

[RobT]

Hier komen we op alweer een ander groot voordeel van OS/linux: niet iedereen heeft dezelfde versie/installatie etc.
Een windows bug betreft doorgaans iedereen die die versie van windows draait. Anders komt 'ie waarschijnlijk niet eens door naar de buitenwereld, en wordt in de MSKB of advisories gewoon gezegd: het gebruik van die en die modus wordt sterk afgeraden (etcetc blablabla).

Bij linux is het vaak zeer waarschijnlijk dat:
- bij een fout slechts een klein deel van de gebruikers betroffen is
- de fout snel wordt opgelost
- er duidelijkheid is over wat er nou eigenlijk fout was,
zodat je weet of je wel of niet betroffen was.

Zo zou je eigenlijk kunnen stellen dat als je naar het aantal bugmeldingen kijkt, er bij linux een veel groter aantal bugs moet zijn (er vanuitgaande dat de verhouding tussen onbelangrijke en belangrijke/gevaarlijke (voor userdata/stabiliteit) bugs hetzelfde is bij linux als bij windows) voor de userbase van linux procentueel net zo zwaar getroffen wordt als de windows gebruikers.
Tel daarbij op dat de meeste windows bugs niet eens bekend worden, maar in stilte gepatched (als ze al gevonden worden), en je ziet dat het aantal bugmeldingen niet met een directe ratio vergeleken moet worden.

Daarnaast: deze bug treft alleen mensen die heel expliciet een modus gebruiken die afwijkt van de normaal aan te raden modus, en is zeer waarschijnlijk niet op gewone werk of thuispc's in gebruik.

Het raakt dus de gewone linuxgebruiker niet.

En dat is het grote verschil met windows bugs van welke versie dan ook, vanaf win98 tm winxp, die allemaal nog volop in gebruik zijn, daarvan zou iedere gebruiken getroffen zijn.

Dus: de windows gebruikers mogen van mij best doen, maar dan alleen naar die linuxgebruikers die deze specifieke manier van Ext3 gebruik toepassen.

Als die te vinden zijn.

Net als winnt/2k/xp gebruikers zich niet aangesproken voelen als je het hebt over bugs / instabiliteit in win95/98/me.

[PenguinPower]

Mogen alle Windows gebruikers nu eindelijk eens een keer gaan schelden op Linux?

Nee

Windows heeft nog niet eens journaling system. (waar de fout in zit) dus hoezo grappig doen als windows gebruiker over linux terwijl windows die functionaliteit niet eens heeft.

Als een gebruiker voor ext2 (zonder journaling) had gekozen, had ie net zoveel data verlies.

* PenguinPower wil dadelijk wel lachen met WinFS

[EfBe]

Windows heeft nog niet eens journaling system. (waar de fout in zit) dus hoezo grappig doen als windows gebruiker over linux terwijl windows die functionaliteit niet eens heeft.

Niet? Goh, wat raar, XP fixed automatisch het FS na een crash, mbv NTFS' journalling functionaliteit.

Plus: wtf heeft deze bug met windows te maken? Het is een codingerror die bij tests eruit had moeten komen, is niet gebeurd, fixen, testen, klaar.

[Aetje]

En fschk draait niet automagisch na een unclean dismount wil je zeggen? Oh ja, vast nooit gezien, Ux crasht niet zo vaak als Windhoos

[BlackBurn]

Windows heeft nog niet eens journaling system. (waar de fout in zit) dus hoezo grappig doen als windows gebruiker over linux terwijl windows die functionaliteit niet eens heeft

en windows heeft weer zoveel tools etc die linux niet heeft, so what? Als er iets geleverd word, moet het in principe goed zijn en dan maakt het niet uit voor welk OS.

Als je wilt zeiken, kun je voor elk OS wel iets bedenken om over te zeiken, MS is nu het grootst dus het makkelijkst voor de meeste en nee ik ben geen MS-fan of Linux-fan. Word alleen een beetje moe van het geflame telkens, gebruik het OS wat je het liefste gebruikt en STFU.

Dan is iedereen tenminste tevreden

/offtopic
NOFI Nico

[Verwijderd]

dergelijke bugjes ben ik nog in geen enkel windows os tegengekomen

[blouweKip]

Ach, het is een probleem dat een kleine kans heeft om op te treden en waar al een fix voor is..

Ik wil liever op de hoogte blijven van bugs die enigzins ernstig zijn en nog niet gefixt (iets wat je bij windows niet kunt weten)

[burne]

http://support.microsoft.com/support/kb/articles/Q185/7/73.ASP
http://search.microsoft.com/gomsuri.asp?n=7&c=rp_Results&siteid=us&tar get=http://support.microsoft.com/support/kb/articles/150/0/09.ASP
http://search.microsoft.com/gomsuri.asp?n=7&c=rp_Results&siteid=us&tar get=http://support.microsoft.com/support/kb/articles/150/3/02.ASP
http://search.microsoft.com/gomsuri.asp?n=4&c=rp_Results&siteid=us&tar get=http://support.microsoft.com/support/kb/articles/179/4/33.ASP
http://search.microsoft.com/gomsuri.asp?n=8&c=rp_Results&siteid=us&tar get=http://support.microsoft.com/support/kb/articles/197/3/66.ASP
http://search.microsoft.com/gomsuri.asp?n=1&c=rp_Results&siteid=us&tar get=http://support.microsoft.com/support/kb/articles/229/6/07.ASP
http://search.microsoft.com/gomsuri.asp?n=10&c=rp_Results&siteid=us&ta rget=http://support.microsoft.com/support/kb/articles/269/6/80.ASP
http://search.microsoft.com/gomsuri.asp?n=1&c=rp_Results&siteid=us&tar get=http://support.microsoft.com/support/kb/articles/283/3/40.ASP
http://search.microsoft.com/gomsuri.asp?n=3&c=rp_Results&siteid=us&tar get=http://support.microsoft.com/support/kb/articles/98/1/42.ASP
http://search.microsoft.com/gomsuri.asp?n=3&c=rp_Results&siteid=us&tar get=http://support.microsoft.com/support/kb/articles/135/3/08.ASP

enzovoort. Need I say more?

[Badger]

..of ze zitten er wel in maar M$ zegt niets...

[mullah]

C:\FILE026.CHK

[Verwijderd]

k vind het altijd zo mooi dat zodra er een bug in een Windows-versie bekend wordt gemaakt, alle Non-Windows gebruikers direct beginnen met opmerkingen als: 'zie je wel' en 'Windows is troep', blablabla..

Dat soort opmerkingen worden ook niet zonder reden naar beneden gemod.
Overbodig dus

Edit:
Waarom wordt ik nou weer flamebait gemod? Ik geef alleen maar aan dat ik 't ermee eens ben dat opmerkingen als "Windows is troep" naar beneden gemod worden.. dus hierover zeuren is overbodig.. lees toch es beter

[memphis]

Is het een bug of gewoon een samenspel van nieuw hardware en software ?
Onder Win98 bestaat er namelijk een soortgelijk timingprobleem dat bij de huidige systemen met snelle harde schijven de cache te snel geleegd wordt en dus wat data verloren kan gaan.
Ook hier is gelukkig een patch voor.

[deadinspace]

Normaalgesproken gebeurt een unmount synchronous. Synchronous houdt in dat acties die op de HD worden verricht niet worden gebufferd, maar meteen worden weggeschreven.
Als een filesystem geunmount wordt, dan wordt alle data die nog weggeschreven moest worden weggeschreven. Omdat dat synchronous gebeurt, staat dus alle noodzakelijke data echt op de harddisk op het moment dat de unmount klaar is.

Bij het rebooten of halten is de laatste stap voor de feitelijke reboot/poweroff het unmounten van de local filesystems. Dus unmount -> wegschrijven data -> unmount klaar -> *pieuw*.

In 2.4.20 echter was echter de check of het unmounten wel synchronous gebeurde afwezig (alleen op ext3 filesystems met data=journal, wat niet standaard is). Het kan dan dus gebeuren dat het filesystem geunmount wordt, maar dat nog niet alles is weggeschreven. Dus unmount -> unmount klaar -> *pieuw* -> wegschrijven data (alleen gaat dat dan niet meer).

Het is dus hetzelfde probleem als Windows 98 had, maar met een andere oorzaak.
Windows had er geen beveiliging voor, en het kwam pas aan het licht bij computers boven een bepaalde snelheid.
Linux had er wel een beveiliging voor, maar in de laatste kernelversie werkte deze beveiliging niet.

[johu]

Ik vind het jammer dat met dit soort 'bugs' Linux direct door leken weer wordt bestempeld als "slecht" besturings systeem.
Eigenlijk zouden ze d'r een andere naam aan moeten geven.

[Verwijderd]

Waarom? Een bug is toch een bug, als dit bij microsoft was gebeurd had iedereen waarschijnlijk geroepen dat ms producten slecht zijn.

Waarom moet er steeds met twee maten en gewichten gewogen worden?

EDIT: het gaat er mij niet om over hoe erg deze bug wel was, of hoe snel ze is opgelost. Ik reageer gewoon op johu omdat hij vindt dat ze dit in het geval van linux geen bug zouden mogen noemen.

[blouweKip]

Ik denk dat dat wel meevalt, deze bug is niet zo ernstig en is al gefixt, de meeste bugs die naar buiten komen (als dat al gebeurt) voor windows waar mensen over zeiken zijn vaak 1.ernstiger en 2.niet of slecht gefixt

[Verwijderd]

* Het is ontdekken, niet ontdenken
* Het is "wie niet waagt wie niet wint" en "wat niet weet wat niet deert"
* Het is "uberhaupt" en "bekend" met een d

Ik denk uberhaupt niet dat deze bug zou voorkomen bij Microsoft, aangezien het hier om een speciale modus van het filesystem gaat en voor zover ik weet kunnen de Microsoft filesystems maar in 1 modus draaien: die van de eindgebruiker. Als er toch een vergelijkbare bug zou voorkomen in een Microsoft filesystem zouden er veel meer mensen last van hebben dan van deze bug.

[Verwijderd]

Wie is er prikkelig?

1. Waar baseer je dit op.
2. Waar baseer je dit op.
3. Waar baseer je dit op

Het feit dat ik bijna dagelijks updates krijg van Microsoft betekend dat de problemen wel degelijk onderkend worden en dus ook verholpen.

[TheLevel]

[offtopic]Hmm... het is inderdaad zo dat ik niet ALTIJD foutloos schrijf, maar ik ga der toch wel prat op dat mijn nederlands nagenoeg altijd foutloos en goed leesbaar is. Het is trouwens ook zo dat ik, als ik een fout maak, dat wèl erg vind en der wat aan wil doen. Het is niet omdat we hier met een stel techneuten bij elkaar zitten dat we opeens geen nederlands meer moeten kunnen. Zou wel helemaal achterlijk zijn, lijkt me... Een goede taal getuigt van respect voor de medemens én van zorg. Goede taalbeheersing kan er trouwens ook voor zorgen dat de kennis die een persoon heeft, beter overgebracht kan worden. Taal is nog steeds het belangrijkste communicatiemiddel van de mens, dus draag er even zorg voor aub.
Moest me toch even van't hart... hier worden erg veel (gruwelijke) taalfouten gemaakt die gemakkelijk vermeden zouden kunnen worden door wat meer aandacht...
[offtopic]

[Atmosphere]

Tja, ik ben het er mee eens dat een dergelijke bug vrij "slecht" is, echter 1 bug maakt nog niet het gehele systeem slecht (wat natuurlijk ook geld voor windows.)

Je kan zeggen wat je wil, maar de definitie van "goed" en "slecht" bepaal jij altijd zelf nog. Dus als jij vind dat de linux-kernel 2.4.20 slecht is .. heb je daar groot gelijk in. Alleen als je dan eerlijk bent is windows ook "slecht". Een compleet foutloos OS is moeilijk te vinden, en een OS met fouten is uiteindelijk best mee te leven (zolang je er niet te veel last van hebt, a la BSOD in win95 )

Mijn persoolijke meening is dat Windows een pracht van een concept heeft, en gezegend is met de meest fantastische interface te krijgen, maar dat de uitwerking nogal rammelt. Linux daarintegen is een veel robuster OS maar heeft voor al zijn functionaliteiten een spartaanse interface, en ook in linux worden regelmatig fouten gevonden en gemeld. Dit in tegenstelling tot windows waar de fouten vaak verborgen gehouden worden totdat er een fix is, met alle mogelijke gevolgen*.

(* ik denk hierbij aan de grotere veiligheid die ontstaat door het stilhouden (wat een hacker niet weet kan ik ook niet zo maar exploiten), maar ook het risico van een langer gebruik van een bepaalde exploit. Immers omdat het niet bekend is kunnen ook geen alternatieve maatregelen worden genomen, mocht er een exploit plaats vinden.)

[Captain Pervert]

"It's not a bug, it's a feature"

[pietje63]

wel goed dat ze er nu mee komen voordat er een regen aan klachten is is de bug al opgelost

als je dat vergelijkt met problemen bij ms, dan krijg e eerst veel klachten dan een melding 'we zijn er mee bezig' en een paar weken later hebben ze een halve oplossing

[gumkop]

en een paar weken later hebben ze een halve oplossing

Ik word echt moe van dit domme geflame op MS. Goed ze hebben een Monopolie, leer er mee leven man !! Ik ben het niet eens met de manier waarop MS de top heeft bereikt, echter als iemand commentaar heeft op Microsoft moet diegene zelf maar even een OS gaan schrijven welke 10.000 hardware devices ondersteund en dat binnen 3 jaar graag; en niet mee gaan liften op het gratis Linux en doen alsof je god bent

Edits naar aanlijding van deadinspace en mikemike:
Edit 1: ik ben het NIET eens met hun monopolie, leer lezen mensen !!

Edit 2: ik zie nog geen OS op tafel, alleen maar weer dom gezwets in de ruimte en een opsomming van wat al 1000x verteld is in elke topic over MS. Dus hup aan de slag en programmeren en niet lullen !!

[deadinspace]

Goed ze hebben een Monopolie, leer er mee leven man !!

Waarom dat? Ik heb er last van, dus ik moet er maar mee leren leven?
Nee, ik heb er last van, dus ik probeer er iets aan te doen.

...echter als iemand commentaar heeft op Microsoft moet diegene zelf maar even een OS gaan schrijven welke 10.000 hardware devices ondersteund en dat binnen 3 jaar graag

1. Microsoft heeft geen OS gemaakt dat 10.000 devices ondersteunt; het zijn de hardware fabrikanten die de drivers voor Windows maken.
2. Microsoft heeft over Windows iets meer dan 3 jaar gedaan.

en niet mee gaan liften op het gratis Linux en doen alsof je god bent

Waarom niet? Ik vind het een zeer goed OS, waar ik op prettige manier mee kan doen wat ik wil. Bovendien ben ik een voorstander van Free (vrij, niet gratis) Software.

[Verwijderd]

Nee, ik heb er last van, dus ik probeer er iets aan te doen.

Leg eens uit waarom je er last van zou hebben?

De één gebruikt Windows omdat het bijvoorbeeld lekker simpel te installeren is en voor de meeste hardware onderdelen ondersteuning biedt, de tweede gebruikt Linux omdat het bijvoorbeeld lekker goedkoop is en de derde gebruikt weer iets anders omdat het bijvoorbeeld........ vul zelf maar in.

Ik zie het probleem niet. Waarom zou iemand last hebben zolang iedereen zelf kan beslissen aan welk OS hij de voorkeur geeft?

[deadinspace]

Edits naar aanlijding van deadinspace en mikemike:
Edit 1: ik ben het NIET eens met hun monopolie, leer lezen mensen !!

Ik moet leren lezen? Ik heb nergens beweerd dat jij het wel met hun monopolie eens was.
Maar jij stelde "leer er mee leven", en daar ben ik het niet mee eens.

Leg eens uit waarom je er last van zou hebben?

Probeer eens een computer (en dan vooral een laptop!) te vinden zonder Windows pre-installed?
Als ik een computer koop, dan wil ik daar geen Windows bij, maar het wordt me wel door de strot geduwd (tegen extra kosten uiteraard).

Ik krijg .doc files en wordt verwacht bepaalde dingen in .doc op te sturen, terwijl het hele project juist in TeX is gedocumenteerd (wat veel handiger, praktischer en mooier is).

Dat zijn - om er maar twee te noemen - dingen waar MS mee weg komt omdat ze een monopolie hebben. In een markt met meerdere spelers en fatsoenlijke concurrentie waren ze allang overhoop geschoffeld hiervoor.

de tweede gebruikt Linux omdat het bijvoorbeeld lekker goedkoop is

Prijs is wel de laatste reden dat ik GNU/Linux gebruik.
Ik heb voor al mijn computer gewoon Windows licenses (die werden me door de strot geduwd - zie boven), welke in de kast stof liggen te vangen. Honderden euro's aan MS software die ik niet gebruik dus.

Ik zie het probleem niet. Waarom zou iemand last hebben zolang iedereen zelf kan beslissen aan welk OS hij de voorkeur geeft?

Omdat dat zelf beslissen je lastig wordt gemaakt. Windows wordt je op verschillende manieren opgedrongen, daar heb ik last van.

[Atmosphere]

Ik ben het met je eens dat het geflame op MS geen zin heeft .. dan moet je gewoon maar wat anders gaan draaien dan hun nog verder in hun monopolipositie te 'dragen'.

Wat ik wel vind is dat M$ toch meer dan 3 jaar heeft gehad ... (vanaf win95 hebben ze de win32 codebase al, en zelfs in 3.11 waren ze bezig), bovendien zijn het altijd maar 'halve' drivers. Elke vorm van specifieke uitbreidingen wordt niet gedaan, en soms moet ook functionaliteit inboeten als men de standaard druivers voor een device gebruiken.

[Verwijderd]

Goed ze hebben een Monopolie, leer er mee leven man !!

Dus al die anti-monopolie en anti-trust wetten vind jij ook onzin?

Ik ben het niet eens met de manier waarop MS de top heeft bereikt, echter als iemand commentaar heeft op Microsoft moet diegene zelf maar even een OS gaan schrijven welke 10.000 hardware devices ondersteund en dat binnen 3 jaar graag;

3 jaar? Laten we zeggen 15 jaar. En NIEMAND op deze aardbol heeft op dit moment de macht/middelen in huis een concurerend OS te schrijven, omdat als ik iets zou hebben dat op PC's lekker zou draaien, ik al 100 keer uitgekocht of weggemarket zou worden door MS en dat geld neem ik dan echt wel aan hoor. Dat is precies de reden dat er alleen iets opensource als Linux nog enige concurentie kan bieden: MS heeft daar geen greep op, ze kunnen het niet opkopen.