Cookies op Tweakers

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

Meer informatie

Door , , 100 reacties

Een Nederlandse ontwikkelaar heeft een bug in Openbsd ontdekt die al in een Unix-versie van 1975 aanwezig was. De vondst volgt op de ontdekking van een 25 jaar oude bug, die in mei werd gevonden.

Openbsd Journal logoOpenbsd-ontwikkelaar Otto Moerbeek vond de bug tijdens het testen van een nieuwe implementatie van malloc, een routine waarmee geheugen gereserveerd kan worden. Een gebruiker wees hem erop dat het compileren van grote C++-projecten soms spaak liep bij gebruik van malloc in combinatie met Sparc-hardware. De bug zou betrekking hebben op de parsergenerator yacc, die al sinds de jaren zeventig onderdeel van Unix uitmaakt.

"Het grappige is dat ik dit heb kunnen traceren naar Sixth Edition Unix, dat in 1975 is geïntroduceerd", schrijft Moerbeek op Openbsd Journal. Volgens Moerbeek doet het probleem zich exclusief voor op Sparc64-systemen. Inmiddels heeft de programmeur de code gepubliceerd die de antieke bug verhelpt. De nieuwe malloc moet ook beter in staat zijn om buffer overflows op te pikken. In mei van dit jaar trof de Zwitserse ontwikkelaar Marc Balmer al een 25 jaar oude bug aan die in alle BSD-varianten aanwezig bleek.

Moderatie-faq Wijzig weergave

Reacties (100)

ik heb zelf niet zoveel verstand van programmeren, maar je zou je ook kunnen afvragen of het wenselijk is om de bug gefixt te hebben. Misschien zijn er in die 33 jaar vele workarounds gemaakt om het probleem te omzeilen, die nu niet meer goed zullen werken (apps. met die workarounds kunnen nu misschien ander, onwenselijk gedrag gaan vertonen). Idd wordt er door de bugfix een fout opgelost, maar misschien worden er vele andere geÔntroduceerd doordat iedereen altijd heeft voortgeborduurd op de foute code.
Just my 2 cents
Omdat het zo lang geduurd heeft voordat de fout gevonden en verbeterd werd, denk ik dat er niet zo veel workarounds zijn gemaakt. Ik denk dit ook omdat de fout zo miniem voorkwam:
Volgens Moerbeek doet het probleem zich exclusief voor op Sparc64-systemen
De code om de bug te fixen is slechts gepubliceerd. Als systeembeheerder ben je vrij om deze bug te fixen adhv de gepuliceerde code. Dus als je vermoed dat je een applicatie hebt draaien met een workaround en je wil in geen geval dat deze zou stoppen met werken, dan laat je de bug voor wat ze is.
Wat je zegt klopt niet echt, voor alle software bestaat er een API, die aangeeft hoe er gebruik gemaakt moet worden van de functionaliteiten die de programmatuur biedt. Pas op het moment dat door een bug of andere security reden er een 'API bump' optreedt, zal code van anderen bewerkt moeten worden.

Vergelijk het maar even met auto's, als jou motor het begeeft, dan hoef je toch ook niet opnieuw te leren gasgeven? Dit is puur en alleen iets dat 'under the hood' gefixt wordt, en gezien de aard van de bug denk ik dat dat zal gebeuren met een workaround voor sparc64.
Je hebt wel een punt; dit geldt min of meer voor iedere bug die gevonden wordt.

Maar je kunt alleen workarounds maken voor bugs die bekend zijn. Aangezien dit een "nieuw" ontdekte bug is, is het onwaarschijnlijk dat iemand hier een workaround voor gemaakt heeft, tenzij volkomen onbewust.

Je kunt je natuurlijk wel afvragen hoe belangrijk het is een bug op te lossen waar niemand de afgelopen 25 jaar last van gehad heeft.
of hij is nu sneller omdat die extra code niet nodig is..
Je kunt je natuurlijk wel afvragen hoe belangrijk het is een bug op te lossen waar niemand de afgelopen 25 jaar last van gehad heeft.
Blijkbaar had iemand er last van anders was de bug niet alsnog gevonden.
Bizar dat in een 25 jaar oud OS een fout zit die in een in x64 systeem boven komt. Toch?

Edit: ah, een kleine spraakverwarring van mijn kant :D

[Reactie gewijzigd door sQuarecoW op 11 juli 2008 11:00]

Was ook mijn eerste gedachte. Overigens is dit natuurlijk geen x64 architectuur, maar sparc64. Je bedoelt natuurlijk gewoon te zeggen dat het 64-bit is, maar eigenlijk is x64 32-bit met 64-bit extenties en sparc64 gewoon volledig 64-bit.
maar eigenlijk is x64 32-bit met 64-bit extenties
Onzin. x86-64 heeft een "legacy mode" waarin hij zich voordoet als een oude 32-bits proc (zodat hij backwards compatible is met oude 16 en 32-bits OSen), en in "long mode" kan hij ook nog 16 en 32 bits code draaien (zodat je oude 16- en 32-bits protected mode apps kan draaien onder een 64 bits OS), maar dat wil niet zeggen dat de CPU maar een 32 bits CPU is met wat 64 bits extensies. De hele architectuur is verder 64 bits - registers, geheugenadressering.

Natuurlijk, de 64 bits instructieset is een superset van de 32 bits ISA en daarom zou je het een 64 bits extensie kunnen noemen. Maar dat betekent niet dat een x64 chip eigenlijk 32 bits is - verre van dat.
Even voor de goede orde: Sparc64 is geen x64, het is een andere architectuur.
De SPARCS kennen al iets langer de 64-bit architectuur. Daarnaast ging het niet om x64, maar dus om Sparc64.
Beetje sensatie zoeken zoals dit artikeltje geschreven is. De bug op zich heeft niet zo veel te maken met Unix, maar wel met Yacc wat een parser generator is. Het is wel door een OpenBSD ontwikkelaar ontdekt door de implementatie van een nieuwere malloc, en eigenlijk kan je dit meer als een feature van die nieuwe (en op security gerichte) malloc zien dat die deze bug ontdekt!.

Bovendien komt de bug voor op alle platformen waar desbetreffende Yacc op gebruikt wordt maar resulteert die enkel in een crash op dat sparc64 platform wegens een specifieke combinatie van omgevingsparameters (vooral de page size van dat platform en een specifiek stukje code).

Desalniettemin heel mooi dat dit probleem ontdekt werd en opgelost wordt.
mac OSX heeft deze bug dus ook zitten?
"exclusief voor op Sparc64-systemen."
OS X draait niet op Sparc64 systemen.
Als je jouw Mac OSX op een Sparc64 hebt draaien ;)
Yacc is onderdeel van UNIX. Bij mij staat ie in /usr/bin (FreeBSD) wat betekent dat het een deel van de base installatie is, wat na de kernel het meest onmisbaar is. Volgens die kerel al 33 jaar dus.

Nou, wie gaat er een virtuele sparc maken om de bug te showen? 8-)

[Reactie gewijzigd door blorf op 11 juli 2008 13:01]

Nou, wie gaat er een virtuele sparc maken om de bug te showen?
virtueel? dude, ik heb gewoon 2 sparcs thuis op m'n bureau staan hoor. :)
Als dit bericht klopt is het ook een bug van de programmeurs: in C++ moet je geen malloc() maar new gebruiken om geheugen op de heap te alloceren. malloc() is voor plain C. Beide door elkaar gebruiken is zowiezo vragen om problemen, met of zonder bug in de implementatie.
Zeer grote kans dat jou c++ compiler je "new" aanroep gewoon vertaald naar malloc!
Dan nog zal de compiler in geval van new weten wat voor type er gemaakt moet worden, bij malloc() is dat wel handmatig te deduceren als je netjes cast maar dat doet ook lang niet iedereen (en zeker niet in 30 jaar oude code van voor de introductie van het void type).
Hoezo moeten? Niks moet... Vrijwel alle geldige C code is ook gewoon geldige C++ code, dus het is nogal merkwaardig dat jij van een bug spreekt terwijl het in feite gewoon gaat over een verschil in programmeerstijl.

Verder snap ik ook niet echt wat je bedoelt met "door elkaar gebruiken". Je moet geheugen dat je met malloc gealloceerd hebben inderdaad niet proberen vrij te geven met delete, en geheugen dat je hebt gealloceerd met new niet met free... Maar voor afzonderlijke stukken geheugen mag je de twee wel gewoon door elkaar gebruiken. Gelukkig wel, zou ik willen zeggen, anders zou je wanneer je linkt met een library die malloc gebruikt dat verplicht overal zelf ook moeten doen, en vice versa...
Er vanuit gaande dat er heel wat werd code werd geklopt in assembly voor de 'prehistorische' software verbaast het me eerlijk gezegd weinig dat je anno 2008 nog tegen dit soort problemen aanloopt

Doordat C++ en C talen zijn die niet direct met machinetaal werken, en de moderne talen hier zelfs nog verder vanaf staan krijg je steeds meer dat er al jarenlang om bugs in het fundamentele systeem wordt gewerkt. Als vervolgens dieper ingegaan wordt op instructies op Assembly of machinetaal niveau dan is er een groot risico dat je wel eens tegen fundamentele problemen aanloopt zoals deze nu al 33 jaar staat.

De programmeurs die met C++ gewerkt hebben kunnen hoogstwaarschijnlijk wel bevestigen dat memory management een van de meest kritieke punten is voor je gebouwde applicatie.
Toch nog iemand die zich hiermee bezig houdt.

Vandaag de dag zijn er toch nog steeds mensen en misschien wel bedrijven die dit gebruiken, dus het is altijd wel handig als iemand dan nog een fout repareert.
Beter laat dan nooit.
Sterker nog, Unix word nog zeer veel gebruikt. Meestal voor robots, ik lees hier niet of dit probleem in alles Unix varianten zit (FreeBSD/Darwin).

Als ik mij goed herinner gebruiken de kranen in Rotterdam(haven) Unix en de transport hal(flat) van Volkswagen ook Unix. Foto
meestal voor robots? zonder Unix was er geen internet :)

Wat denk je dat er bij al die ISP's draait? Windows? Nope. Heel veel Unix en Linux. (heck, heel xs4all draait op FreeBSD)
Ik denk dat er veel Linux word gebruikt bij ISP's, en geen Unix. En zoals wij weten is Linux geen Unix, maar een poging tot.
Ik denk dat er veel Linux word gebruikt bij ISP's, en geen Unix. En zoals wij weten is Linux geen Unix, maar een poging tot.
BSD is redelijk populair bij ISP's (ik kijk verder dan alleen nederland). en BSD mag zich welliswaar geen echte Unix noemen, omdat niemand er de moeite (en kosten) voor neemt om 't te laten certificeren. de OpenGroup (die eigenaar van het Unix trademark) doet er echter niet moeilijk over dat men naar de BSD's refereert als Unix. Het zijn de laatste OS'en die nog direct afstammen van de oorspronkelijke AT&T Unix.

Van Casema weet ik sowieso dat ze eigelijk alles op Sun hadden draaien, dat is echt een Unix. bij Telco's zie je veel AIX, ook weer een echte Unix. Xs4all draait volledig op FreeBSD, Wirehub! deed dat ook. Cistron was weer heel erg Linux (debian om precies te zijn), BiT draait volgens mij weer heel erg op FreeBSD. Pine is erg FreeBSD centric (was ISP, nu meer security focus). Heel Yahoo draait op FreeBSD.

Ik kan nog wel even doorgaan hoor. :)

Mij is ook wel eens opgevallen dat die 'zolderkamer' (meestal zitten ze gewoon in een rack bij een club hoor) hosting clubjes van studenten op een bepaald moment serieuzer gaan worden (na het afstuderen doorgaans) en dan zie je er ook veel een overstap maken van Linux naar FreeBSD.
Solaris is ook duidelijk op BSD gebaseerd (ten minste lang geleden).
Nee, SunOS (1-4) was BSD, Solaris (SunOS 5) is SVR4. Wat niet betekent dat er geen BSD in Solaris zit (want SVR4 heeft zelfs zaken van BSD overgenomen), maar de switch van SunOS naar Solaris was duidelijk voelbaar in systeemopzicht.
tis helemaal geen poging tot. Linux streeft ernaar om een posix compiant, unix-like operating systeem (eigenlijk kernel) te zijn.
Nog sterker, tax on web in BelgiŽ draait exclusief op unix servers.
Vele banken hebben het geimplementeerd om hun systemen te draaien.
Unix is in de grotere servers zeer zeker een belangrijke speler.
25 van de snelste 500 servers in de wereld draaien op unix. (valt mij persoonlijk nog tegen)

[Reactie gewijzigd door s463042 op 11 juli 2008 10:51]

Als je je bedenkt dat Linux, BSD en Mac OS takken zijn van Unix wordt het aandeel ineens een heel stuk meer ;)
kortom alles behalve windows.
kortom alles behalve windows
Neuh, er zijn genoeg OS'en buiten Windows om die niet op Unix zijn gebaseerd. Bijvoorbeeld OS/2, (Open)VMS, Nextstep/Openstep en BeOS.

[Reactie gewijzigd door Dingen op 11 juli 2008 14:25]

NextStep en OpenStep zijn wel degelijk op UNIX gebaseerd. Mach kernel, BSD 4.3 en een postscript based GUI om precies te zijn. Sterker nog, MacOS X is er op gebaseerd.
laten we het herdefinieren: alles wat serieus nog gebruikt wordt buiten windows om :+

tuurlijk is er genoeg, maar hoeveel dingetjes die nog echt gebruikt worden?
Daar valt over te twisten. Windows bevat BSD code, en de NT tak die de laatste jaren dominant is, is bovendien ontworpen door de ontwerpers van VMS.
Daar valt over te twisten. Windows bevat BSD code, en de NT tak die de laatste jaren dominant is, is bovendien ontworpen door de ontwerpers van VMS.
VMS is geen Unix.
Indertijd heeft een rechter uitgesproken dat BSD geen Unix is en er dus geen licentiegelden voor nodig zijn. Op dit moment probeert een bedrijf aan te tonen dat Linux wel een unix variant is. Dat lijkt niet echt te lukken ;)

Dus BSD is geen unix. Linux is hoogstwaarschijnlijk geen Unix en Mac OS is gebaseerd op BSD en dus geen Unix.

Simpel toch....
Linux is Unix based, alleen zonder de eisen die aan een echte Unix worden gesteld.

Voor zo ver ik weet ik de enigste andere Unix dan gewoon Unix, Tru64 Unix/Digital Unix van Digital Equipement Corperation, deze behaalde alle criteria om een echte Unix te zijn. En ja ook deze is allang dood gegaan het was dan ook voor de Alpha 64bits proc. gemaakt, en waar zie je die tegenwoordig nog?
De xBSD varianten zitten een stuk 'dichter bij' Unix dan linux....
Gebaseerd op, geen kloon van, BSD's zijn vrije klonen, maar nog steeds geen echte Unix'n.
Het is meer andersom. BSD is van origine een verzameling tools die het originele Bell Labs UNIX bruikbaar maakten. Denk aan editor, shell, TCP/IP-stack etc. Wat op dit moment UNIX genoemd wordt is eigenlijk meer de filosofie en toolkit van BSD dan de kernel van Bell labs/AT&T. Officieel is UNIX een specificatie waarvoor je gecertificeert kunt worden als je een heeele grote zak geld op tafel legt.
Apple's OS X is bijvoorbeeld UNIX-gecertificeerd.
OSX voldoet tegenwoordig ook aan de Unix specs.. (iPhone versie ook geloof ik).
Linux is niet UNIX based, het is UNIX like, net zoals minix.
BSD stamt wel af van de oorspronkelijke UNIX code.

Dit wikipedia artikel legt het wel goed uit: http://en.wikipedia.org/wiki/Unix-like
Oh geloof me, Tru64 wordt nog heel omvangrijk ingezet hoor. Banken, pensioen verstrekkers en heel veel overheid. (veiligheidsdiensten, belastingdienst, uitkeringsinstanties etc.etc.etc.)
wat dacht je van solaris.. ook een unix...

En ja Ik heb nog een alpha64 :D
Voor zo ver ik weet ik de enigste andere Unix dan gewoon Unix, Tru64 Unix/Digital Unix van Digital Equipement Corperation, deze behaalde alle criteria om een echte Unix te zijn. En ja ook deze is allang dood gegaan het was dan ook voor de Alpha 64bits proc. gemaakt, en waar zie je die tegenwoordig nog?
*steekt zijn hand op*

De nieuwste Debian/Linux draait op een AlphaServer nog steeds retestabiel. Maar DEC UNIX is een beetje overbodig. Ja, het is leuk. Nee, het is niet nuttig. Onder Debian kan je tenminste nog hedendaagse (open-source) software draaien.

[Reactie gewijzigd door The Zep Man op 11 juli 2008 14:34]

ahum, ik zou nu niet bepaald tax-on-web als voorbeeld geven wanneer iemand me vraagt om eens een stabiele unixserver te noemen :D
Niet dat dat aan Unix ligt :p

[Reactie gewijzigd door RaZzz op 11 juli 2008 16:10]

De software van de fregatten van de Nederlandse marine draait (iig 1.5 jaar terug) op Solaris 10 .. Dus inderdaad geen windows
Vorig jaar is bekend gemaakt dat voor die software een overstap naar Windows is gemaakt.
Hebben we binnenkort ook wel eens een NL fregat dat een half uur stuurloos kan liggen ronddobberen tot ze al hun windows based systemen gereboot hebben ? ;)
Ooit de docu gezien op Discovery over de Falklands oorlog (1982 Pre-Windows) . Hierbij werden twee Engelse schepen aangevallen door Argentijnse exocet raketten. Tijdens dit gevecht moest op een schip de vuurleiding computers worden gereset. Dat is niet lachen op zo een moment.
Dat was geen Windows.
Je moest een hele rij knopjes afwerken die in een bepaalde volgorde geschakeld moesten worden om het systeem te rebooten. Dat duurde altijd enkele minuten.

Helaas voor hun was op het moment dat de reboot klaar was het andere schip in de vuurlinie gaan varen, waardoor ze niet konden schieten. Dus die aanval is succesvol verlopen voor de argetijnen.

wat je allemaal niet leert/ziet bij discovery
Dat is bij een Amerikaans fregat inderdaad een keer gebeurd. Niet leuk.
De Aegis kruisers van de US Navy op Windows 2000.....
draait meer op windows dan je denkt in het bankwezen ;)
Maar het gross van de banken draait op IBM mainframes, AIX of SUN (ik werk voor de grootste financieel software bouwer van de wereld, fortune 500 bedrijf)
Ik heb gewerkt voor een fortune 100 bedrijf in het bankwezen, en daar werd Windows enkel gebruikt voor de meest simpele non-critical applicaties.
De rest ging op mainframe, AIX, SUN of HP-UX.
draait meer op windows dan je denkt in het bankwezen
Idd, zoals hieronder gezegd pinautomaten vaak (helaas). Bankmedewerkers schijnen dat prettiger te vinden omdat ze het kennen (jammer dat dat belangrijker is dan veiligheid van die dingen).

[Reactie gewijzigd door kidde op 11 juli 2008 19:10]

OK, niet bedrijfs kritisch, maar veel geld automaten draaien op Windows NT
Om daar nog eens over te praten. Ik zag laatst in Groningen een pinautomaat met een BSOD.
Ik heb ook wel eens een automaat zo over de zeik gekregen dat 'ie opeens een dr. watson log ging maken.
Bij deze is het bewezen: met testen kun je aanduiden dat er fouten in je code zit, maar je kunt NOOIT aanduiden dat er geen fouten inzitten :)
Ja en nee. In theorie is het mogelijk om de correctheid van programma's te bewijzen, hetgeen je ook leert in een bachelor Informatica bijvoorbeeld. Dit schijnen ze ook bij NASA en andere hele belangrijke projecten te gebruiken. In praktijk is dit waanzinnig duur en tijdrovend, en er blijft altijd de vraag hoe je ooit 100% zeker weet dat er tijdens het opstellen van het bewijs geen fouten zijn gemaakt ;)
En dan nog... Dan heb je bewezen dat er geen fout in je softwareontwerp zit, maar wie garandeert dat:
  • Je compiler geen fouten maakt
  • Je hardware geen fouten maakt
Dat soort fouten kan je met testen detecteren, maar niet bewijzen dat ze niet aanwezig zijn.

Statische verificatie is slechts 1 stap in het hele process om volledig veilige software te maken.
Als je dan van je compiler ook bewijst dat er geen softwarefouten zitten heb je al weer een factor geelimineerd. Alleen de hardware dan nog, maar daar kom je zo goed als niet onderuit.
Helaas moet je dan ook nog bewijzen dat er in de compiler waarmee je compiler is gecompileerd OOK geen fouten zaten... en die code is ooit ook weer met een andere compiler gecompileerd dus zou je daarvan ook weer de correctheid moeten bewijzen.

Of je moet de boel disassemblen, en de correctheid van de assemblycode bewijzen, maar daar wordt je echt niet vrolijk van :9
dat er in de compiler waarmee je compiler is gecompileerd OOK geen fouten zaten... en die code is ooit ook weer met een andere compiler gecompileerd
Nee, zo werkt het dus niet helemaal, want de eerste compiler ter wereld was natuurlijk niet gecompileerd; er was immers nog geen compiler. Lees maar over Yacc, een compiler die compilers compileert. Het begint vaak met definities in BNF-achtige vorm, een soort mathematische grammatica; 'taalregels / definities'. Aan de hand daarvan prutsen Yacc-achtige programma's een compiler in elkaar.
Zo werkt het wel. Fortran is niet met Yacc gemaakt. Fortran (een van de, zo niet de eerste programmeertaal) stamt uit de pre-Backus-Naur-Form-tijd.

Bovendien gebeurt het omzetten van de AST's (de boomstructuren die op basis van de programmacode wordt gemaakt) naar programma code nog steeds met een normale programmeertaal.
en er blijft altijd de vraag hoe je ooit 100% zeker weet dat er tijdens het opstellen van het bewijs geen fouten zijn gemaakt
Als je het zo stelt, spreek je jezelf tegen en kan je dus niet de correctheid bewijzen. Of begrijp ik je verkeerd?
Theoretisch kun je het bewijzen, echter moet het bewijs wel door mensen geleverd worden. Laten die wezen nu net nog wel eens fouten maken, dus wie zegt dat er geen fout in het bewijs zit en dus mogelijk ook in de code?
Recent nog een vakje daarover gehad en inderdaad: het bewijzen is lijkt vaak moeilijker dan de code zelf :)
Ja en nee. In theorie is het mogelijk om de correctheid van programma's te bewijzen, hetgeen je ook leert in een bachelor Informatica bijvoorbeeld. Dit schijnen ze ook bij NASA en andere hele belangrijke projecten te gebruiken. In praktijk is dit waanzinnig duur en tijdrovend, en er blijft altijd de vraag hoe je ooit 100% zeker weet dat er tijdens het opstellen van het bewijs geen fouten zijn gemaakt ;)
Algoritmes kan je formeel bewijzen. Denk/logica fouten niet. Denk maar bijvoorbeeld aan de Y2K bug, niks mis met de algoritmes of functionaliteit van de software. Het werkte 30 jaar lang goed. Zelfs bij NASA zijn er redelijk wat incidenten die voor een deel te verwijten zijn aan software fouten.
Ik dacht dat de eerste versie van de ariane 5 raket een klein bugje bevatte. Goed was ESA, maar op dat niveau worden dus toch nog grote blunders begaan.
bollocks. Zie je dat een MSC nog ergens goed voor is. Je kunt bewijzen dat dat een bepaald gedrag niet voorkomt. Moet je wel voor alle ongewenste gedragingen doen. Ergo, hoeveel mogelijk fouten kunnen er voorkomen en hoeveel test je er af. Het is feitelijk ondoenlijk om aan te tonen dat er geen bugs in je applicatie zitten. Wel kun je aantonen dat 1 specifieke fout niet op zal treden.
neej, want je hebt nietbewezen dat er geen fouten in de php interpreter zitten.. ;)
Alleen als er in de procedure echo geen fouten zitten ;)
Als je niet weet wat de intentie van de code is kan het fout zijn he. Misschien was de specificatie wel, "Toon de tekst Deze codA bevat geen fauten!" en dan zit er wel een bug in je code...
Haha, dan is Microsoft toch wat sneller met windows updates ;)

ps. Oe, wat zegt ie nou!? ;)
niemand heeft de fout ontdekt in die 33 jaar ;)

Windows bevat ook bugs (er was er vorig jaar nog een gefixed als ik 't me goed herinner) die er al sinds 3.11 inzitten tot XP en Vista aan toe. Backwards compatible blijven kan soms een ramp zijn :)

Feit is, de bug is pas een bug als ie ontdekt wordt. Nu pas, liep er iemand tegen een issue aan waarop een deverloper is gaan onderzoeken. Redelijk bizar eigelijk, OpenBSD wordt wel vaker op sparc64 systemen gezet.
Hihi, ik weet het ;)

Ik moet altijd erg lachen om de reacties op een bugfix van Microsoft, waarna ze volledig (soms terecht) door het slijk worden gehaald.

Het is mooi om het verschil te zien met de reacties op iets dergelijks onder Unix, en dat wilde ik op een niet onaardige manier even aan de kaak stellen :)

Gelukt volgens mij, gezien de snelheid waarmee de reactie op -1 stond ;)
Feit is, de bug is pas een bug als ie ontdekt wordt.
Dat is een persoonlijke mening. Voor mij maakt een vallende boom geluid, ook wanneer niemand er is om het te horen. Anderen willen het dan liever filosofisch bekijken en zullen zeggen dat de boom geen geluid maakt.

Dus het is niet omdat de bug onbekend is dat je mag zeggen dat ze niet bestaat.
En dan? Als ik jou als bugfixer aanneem en jou 250 miljoen betaling in het vooruitzicht stel als jij alle bugs fixt dan hoef ik jou nooit te betalen, ik kan altijd volhouden dat er nog een niet ontdekte bug inzit?

Na release is iets pas een bug als hij ontdekt wordt. Daarvoor is en blijft het een bug...
Wat zeg je nou ? Microsoft lost meestal beveiligingslekken op en grote bugs. De andere laten ze gewoon zitten.

vb: "Bezig met bouwen van domein lijst" -> even ctrl+alt+del
Zit er nog altijd in hoor, al sinds windows 2000

of de toetsenbord instelling tijdens setup, waar je zogezegd moet herstarten om engels weg te krijgen, bovenaan gewoon even default op je gewenste indeling zetten, en engels kan plots wel weg ...

2 kleine bugs die gewoon te omzeilen zijn, maar ze zitten er al 8 jaar in !

Op dit item kan niet meer gereageerd worden.



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

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