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 , , 60 reacties
Bron: Washington Post

Microsoft wordt al geruime tijd bekritiseerd vanwege de vermeende traagheid waarmee het reageert op bugs. De Washington Post Security Fix bestudeerde alle kritieke patches van de afgelopen drie jaar om de verwijten te onderzoeken. Kritieke patches zijn volgens Microsoft patches waarmee een beveiligingsgat wordt opgelost dat een aanvaller kan gebruiken om in te inbreken op een Windows-computer en de controle hiervan kan overnemen. Voor elke kritieke patch werd gekeken naar de datum dat Microsoft op de hoogte werd gesteld en hoe lang het vervolgens duurde om een patch uit te brengen. De datums waarop Microsoft op de hoogte werd gesteld, zijn verkregen van Common Vulnerabilities and Exposures (CVE), direct van onderzoekers en, in ongeveer een dozijn gevallen, van Microsoft zelf.

Microsoft blauw logoDe resultaten van het onderzoek laten zien dat het in 2004 en 2005 langer duurde voordat Microsoft patches uitbracht dan in 2003. In 2003 werd een patch gemiddeld drie maanden na het rapporteren van het probleem uitgebracht. In 2004 duurde dat op 134,5 dagen en in 2005 bleef dat vrijwel onveranderd. Gedurende deze periode ging echter wel het aantal dagen tussen het publiceren van de bug en het vrijgeven van de patch omlaag. In 2003 duurde dit gemiddeld 71 dagen, in 2004 55 dagen en in 2005 daalde dit naar 46 dagen.

Microsofts reactietijd op kritieke bugs
Microsofts reactietijd op kritieke bugs (groot)

Uit de gegevens blijkt dat Microsoft sneller patches vrijgeeft wanneer bugs publiekelijk bekend worden gemaakt in plaats van alleen aan Microsoft. Voorstanders van deze 'full disclosure'-aanpak zijn van mening dat bedrijven sneller hun fouten zullen herstellen wanneer iedereen ervan op de hoogte is. Andere factoren spelen hier echter ook een rol bij. Vaak wordt bij deze aanpak ook de broncode van de exploit gepubliceerd. Hierdoor is het voor Microsoft eenvoudiger om de oorzaak van de bug te achterhalen en sneller een patch uit te geven. Microsoft lijkt echter succesvol te zijn in het overtuigen van onderzoekers dat ze hun resultaten niet publiekelijk bekend moeten maken. In 2003 ging het om acht gevallen en in 2004 en 2005 ging het beide keren om vier gevallen van publiekelijke bekendmaking.

Stephen Toulouse van Microsoft geeft aan dat Microsoft tegenwoordig meer tijd besteedt aan de kwaliteitscontrole van de patches. Gecontroleerd wordt of elke patch het betreffende probleem totaal verhelpt in het gehele besturingssysteem. Daarnaast wordt beter gekeken of een patch geen nieuwe bugs introduceert. Volgens Toulouse is het maken van een patch voor de gerapporteerde bug het eenvoudigste gedeelte van het gehele proces. Na het schrijven moet de nieuwe patch getest worden en als er dan nieuwe bugs worden gevonden begint het proces opnieuw. Daarnaast geeft Microsoft tegenwoordig de ontdekkers van de bugs meer gelegenheid om de patches te testen.

Internetworm Toulouse geeft als voorbeeld van een problematische patch de ASN.1-bug, die gezien wordt als de grootste bug in de geschiedenis van Windows. Er moest tweemaal opnieuw met het testen van de patch worden begonnen als gevolg van nieuwe bugs die tot dan toe onopgemerkt waren gebleven. Microsoft heeft ook lessen geleerd uit bijvoorbeeld de afhandeling van de bug die leidde tot de Blaster-worm. Microsoft gaf de eerste patch al na 38 dagen vrij, maar twee dagen na het vrijgeven bleek de bug op te duiken op nog drie andere plaatsen in het besturingssysteem. Ongeveer twee weken later infecteerde Blaster miljoenen computers. Sommige experts menen dat de worm ontwikkeld is met behulp van Microsofts originele patch.

Blaster heeft geleid tot twee veranderingen bij Microsoft aldus Toulouse. Ten eerste worden patches beter gecontroleerd en ten tweede heeft het Microsofts Secure Windows Initiative Team de opdracht gekregen om alle bugs te onderzoeken en aan te vallen zoals hackers dat ook zouden doen. Niet iedereen is echter onder de indruk van Microsofts inspanningen. De kwaliteit van de patches is de laatste tijd weliswaar omhoog gegaan, toch duurt het nog steeds erg lang voordat de patches daadwerkelijk worden vrijgegeven. Onder hackersgroepen worden de bugs verhandeld en gebruikt tegen specifieke doelen, aldus een beveiligingsexpert van eEye Digital Security. Omdat Microsoft zo lang wacht met het vrijgeven van patches, blijven de systemen van de klanten van Microsoft langer kwetsbaar.

Windows patch Vorige week gaf Microsoft nog een patch voor het WMF-lek vrij. Deze bug werd reeds tien dagen na de eerste melding vrijgegeven. De korte reactietijd werd mede mogelijk gemaakt doordat er al een onofficiŽle patch voor bestond. Ook nu verschenen er echter weer meldingen dat er minstens nog twee andere fouten waren ontdekt in dezelfde WMF-code die Microsoft eerder patchte. Toulouse geeft aan dat Microsoft al van deze bugs op de hoogte was, maar dat de bugs nog niet waren opgelost omdat ze niet zo serieus van aard zouden zijn. Dit laat wel de vraag open of de veranderingen binnen Microsoft echt effect sorteren.

Moderatie-faq Wijzig weergave

Reacties (60)

Tja, het mag duidelijk zijn dat MS nog steeds te veel steunt op het "security by obscurity"-principe, en te weinig aandacht besteed aan het snel vrijgeven van patches.

Ze botsen ook steeds vaker op het probleem dat windows te veel in elkaar gestrengelde code bevat. Een patch lost dan een bug op, maar creŽert er soms ook nieuwe. Ze zullen in de toekomst echt wel sneller moeten gaan reageren en hun besturingssysteem modulair gaan opbouwen, willen ze in de toekomst op niet nog meer problemen stoten.
Als je tweakers.net een beetje bijhoudt heb je kunnen lezen dat men met het ontwikkelen van Vista modulair is gaan werken. Het was een grote cultuuromslag en een van de redenen waarom het ontwikkelen van Vista zoveel tijd heeft gekost.

Als Linux fanaat hoop ik dat het zootje een keer instort maar als dagelijks Windows gebruikende werknemer lijkt mij dit een heel goed plan van MS. :)

@mdvmine
kijk hier eens:
nieuws: Jim Allchin: 'Ontwikkeling Vista in 2004 compleet herzien'
Ik heb al meerdere malen in de comments gelezen dat er bericht zou zijn dat Vista modulairder opgezet zou worden maar ik heb dit niet in artikels zelf kunnen teruglezen.

Het enige wat ik mij herinneren kan is dat ze op een gegeven moment "opnieuw" begonnen zijn met een "kale" windows 2003 server release. Dit is natuurlijk de al 15 jaar oude NT code met verbeteringen erin. Vanuit backward-compatibility oogpunt hebben ze zichzelf in een hoek gedrukt, ze kunnen geen structurele verbeteringen maken qua modulariteit: het risico is te groot.

Wel een verbetering is dat Internet Explorer (e.a. misschien) met minder rechten kunnen gaan draaien.
het is een kale Longhorn-server die ze genomen hebben, geen Windows 2003-server
Right, Longhorn it is, maar die komt toch pas na de client versie uit ? En waar is die server versie dan op gebaseerd, die groeit toch ook niet aan 1 of andere boom daar? ;)

Ik vind het nog steeds een vreemd verhaal.
Ik heb al meerdere malen in de comments gelezen dat er bericht zou zijn dat Vista modulairder opgezet zou worden maar ik heb dit niet in artikels zelf kunnen teruglezen.
dit komt van het boven genoemde artikel ;)
Via deze grafische presentatie werd al snel duidelijk dat er teveel afhankelijkheden waren binnen Windows en dat er meer op een modulaire manier gewerkt zou moeten gaan worden. Valentine en Srivastava stelden dit vervolgens voor aan Allchin en deze ging ermee naar Gates in het midden van 2004. Ondanks het feit dat hij niet direct te spreken was over Allchins plannen, omdat onder meer WinFS (een van de baanbrekende zaken die Gates graag in Longhorn gehad had willen hebben) ervoor moest wijken, stemde hij wel toe. Naast het besluit om Longhorn op te delen in minder van elkaar afhankelijke modules, werd ook besloten om met een schone codelei te beginnen. Een kale release van de serverversie van Windows Longhorn werd uit de kast gehaald en deze is de basis gaan vormen voor het werk dat uiteindelijk tot Windows Vista geleid heeft.
men met het ontwikkelen van Vista modulair is gaan werken
Misschien modules met minder koppeling tussen deze modules, ik bedoel: ben er zeker van dat WinXP is ook modulair opgebouwt hoor (en 98, en 95, en NT, en 3.1). Elk programma van 100 regels code is normaal gezien ook altijd modulair opgebouwd, ga je mij niet zeggen dat de bestaande versies van windows allemaal uit 1 gigantische monstermodule bestaan waarin alle code zit.
Ze botsen ook steeds vaker op het probleem dat windows te veel in elkaar gestrengelde code bevat.
[...knip...]
besturingssysteem modulair gaan opbouwen
dan is dit interview vast interresant voor je, ze zijn zich ervan bewust en zijn er mee bezig. echter in een release de hele boel uit elkaar trekken zou teveel compatibility issues creeren
http://channel9.msdn.com/Showpost.aspx?postid=148820
Ik heb een stuk van dat interview gezien. Interessant, en af en toe behoorlijk schokkend. Tot nu toe was MS blijkbaar niet goed in staat om te bepalen wat de impact van een wijziging was, simpelweg omdat niet duidelijk was welke modules relaties met elkaar hadden. Dit werd nog erger doordat de afhankelijkheden 'gelaagd' waren, dus als A afhankelijk is van B die afhankelijk is van C en C werd gewijzigd dan kon het zijn dat ook A niet meer functioneerde.

De Windows kernel blijkt uit 5500 verschillende binaries te bestaan die uiteraard allemaal een relatie hebben met 1 of meerdere andere componenten die natuurlijk ook weer relaties met elkaar hebben.

In dit oerwoud is het natuurlijk moeilijk navigeren, vandaar dat ze zelfs bezig zijn met grafische tooltjes om afhankelijkheden te kunnen plotten en op de manier te voorkomen dat developer A developer B in de weg zit.

Zoals gezegd vond ik het nogal schokkend: een van de grootste softwarebedrijen ter wereld is niet in staat om haar iegen kernprodukt goed te documenteren en te onderhouden, maar is teruggevallen op, plat gezegd, uitproberen of het werkt. Met goed ontwerp heeft dat niet s meer te maken.

Met dit verhaal in het achterhoofd is ook goed te begrijpen waarom de tijd om een bug te fixen zo lang is: er kan gewoon veel te veel mis gaam zeker als de fixes ook nog eens bij een ontwikkeltak ingedraaid moeten worden. Schaarse resources zorgen natuurlijk ook voor probelemen en voordat je het weet zijn er twee maanden voorbij.

Overigens vind ik het tekenend dat het nog steeds zo is dat een lek dat publiek bekend is sneller wordt gedicht dan iets dat alleen bij de ontdekker en MS bekend is. In de tussentijd ben je als gebruiker aan de goede wil van de ontdekker overgeleverd en mag je hopen dat een kwaadwillend persoon ditzelfde lek niet gebruikt voor kwade doeleinden.

Kortom, MS heeft nog flink wat werk te verzetten, en niet als enige, want ook bedrijven als Oracle hebben soms belachelijk veel tijd nodig voor fixes.
Als men zo bang is dat na bekendmaking exploits zullen verschijnen, hou het dan bij: bugvolgnummer, schadelijkheid, welke (Windows) versies de bug betrekking op heeft, melddatum en datum gefixed. Dan krijg je pas een reeel beeld hoe lang het duurt na een melding totdat een fix beschikbaar is. MS zal dan ook meer geneigd zijn de echt kritieke bugs sneller te fixen, aangezien iedereen kan zien hoeveel kritieke bugs er nog open staan.
Al hun aandacht ligt nu bij Vista. Het zou contra-productief zijn om alle lekken in WIndows XP nu zo snel mogelijk op te lossen. Binnen drie jaar ligt het in de prullenbak.
Wanneer ik de stats zo zie, ligt hun aandacht al heel lang bij Vista.

Je kunt het natuurlijk niet goed praten met 'ze richten zich op de toekomst'. Vooral voor enterprise oplossingen is dit geen geldig argument. In de praktijk blijkt dat bedrijven pas enkele jaren later overstappen naar een nieuw OS. Veiligheid, stabiliteit en betrouwbaarheid van huidige producten heeft de hoogste prio.
Windows XP zag het daglicht in 2001. De grafiek begint pas vanaf 2003... Dus ja je kan ervan op aan dat men vanaf 2001 al volop aan Vista bezig was.

Feit is dat onderhoud van software veel meer kost dan aan een nieuwe versie te werken. En dan is het verbergen van fouten veel efficiŽnter dan ze op te lossen. Ikzelf kan me mateloos ergeren als iemand een bug in mijn software rapporteert terwijl ik aan een nieuwe versie bezig ben waarbij die bug compleet uitgesloten is.
Dus? Feit is ook dat nieuwe versies veel langer duren om te ontwikkelen, feit is ook dat nieuwe versies vrijwel nooit meteen ingezet worden door de klanten. Feit is ook dat ze de producten waar de problemen in zitten, nog altijd gewoon verkopen. Nog een feit, bugs kunnen veel sneller opgelost worden (zonder negatieve effecten), zolang ze de resources er maar voor vrij maken.
Ikzelf kan me mateloos ergeren als iemand een bug in mijn software rapporteert terwijl ik aan een nieuwe versie bezig ben waarbij die bug compleet uitgesloten is.
Lekkere instelling...
Resources voor vrijmaken, daar draait het allemaal om. Er is een tekort aan programmeurs met de juiste skills die voor weinig geld aan frustrerende debugging willen werken. Het is beter om die getalenteerde mensen aan je volgende product te laten werken.
Vreemd dat de OSS totaal geen capaciteits problemen heeft voor patches...

Beter voor wie? De klant of de sales afdeling?
Maar jij werkt alleen aan die software zo te lezen. Je gaat mij niet wijs maken dat het bij MS hetzelfde team ontwikkelaars is dat aan XP en aan Vista werkt hoor. Volgens mij werkt meer dan de helft van het personeel dat aan XP gewerkt heeft niet mee aan Vista en dient dat personeel voor het onderhoud van de XP-versies.

Ik vind het schandalig dat het gemiddeld 134 dagen duurt tegen een high priority issue gefixed is. Het gaat hier over heel wat internet-criminaliteit: pc's die overgenomen worden om spam en virussen te verspreiden, DOS-attacks, ...

Als er bij ons op het werk een bug uit komt die enige impact heeft, dan wordt er verwacht dat die binnen 24 tot 48 uur gefixt is EN in productie staat. Dit vraagt van iedereen een zeer grote inspanning, maar het resultaat is er wel. Het ontwikkelteam fixt de bug, maakt een nieuwe release (patch), installeert deze op de testomgevingen, waar deze dan door zowel developers als door diegene die de bug gerapporteerd hebben als de eindgebruikers wordt doorgetest alvorens deze in productie gezet mag worden.

en dan gaat het niet om bugs die met security of iets dergelijks te maken hebben...
Je werkt dan ook niet aan een besturingssysteem mag ik aannemen?

Een patch voor een O.S. in 48 uur afleveren leidt gegarandeerd tot grotere problemen dan het lek op zich. Grafische drivers, waar ik het meest ervaring mee heb, moeten wekenlang gestest worden om het WHQL certificaat te verdienen. Enige afwijking zou catastrofale gevolgen kunnen hebben (niet-WHQL drivers geven wel eens een blue-screen).

Ik heb onlangs een senior mamanger gesproken van een bedrijf dat SAP implementeert. Daar moeten patches en uitbreidingen door maar liefst vier stages om uiteindelijk definitief te worden. En dat is applicatiesoftware (wel gigantisch complexe).

Het is dus voor Microsoft een absolute must om al die tijd hun lekken verborgen te houden. En dan kan je ook beter het risico inschatten dat een lek daadwerkelijk misbruikt gaat worden. Met de vijf jaar dat XP al meegaat is het knap dat elk lek uiteindelijk toch binnen het jaar gepatcht wordt. Dat betekent dat ook de lekken die misschien nooit een reŽle bedreiging vormden ook gedicht worden.
Een patch voor een O.S. in 48 uur afleveren leidt gegarandeerd tot grotere problemen dan het lek op zich.
Ik wil niet veel zeggen, maar menige OSS patch wordt binnen 48 uur gereleased? Zijn daar zoveel problemen mee dan?

Ik weet het dus niet..ik werk niet zoveel met linux..
Een patch voor een O.S. in 48 uur afleveren leidt gegarandeerd tot grotere problemen dan het lek op zich.
Licht eraan hoeveel er gemoeid is met de patch. Als het een simpele controle is die vergeten is, kan deze snel toegevoegd worden. Het probleem van Windows is, dat er veel applicaties weer afhankelijk zijn van de bugs. Windows emuleerd oude bugs voor bepaalde programma's zodat deze blijven werken.

Dit soort situaties vergrooten de complexiteit van een patch, en de tijd die nodig is om te testen. Zoals hierboven al vermeld werd, heeft Microsoft ook geen overzicht van de afhankelijkheden van een stuk code. Lekkere boel dus :P
Hmm.. een dergelijke argumentatie zou wel eens tot problemen kunnen leiden. :Z

Het zou helemaal mooi zijn als MS geen patches meer uitbrengt want ach, Vista komt binnenkort toch uit. |:(

MS is verplicht om lekken te dichten en problemen op te lossen in de huidige versies van zijn besturingsystemen.

Sterker nog, zelfs na de introductie van een nieuw OS moet MS het oude nog ondersteunen en moet het actief patches uitbrengen. Je kunt niet zomaar iemand dwingen over te stappen als ie net de oude versie heeft aangeschaft. En dat zou je dan effectief wel doen. "Geen nieuwe versie? Dan ook geen updates en security patches meer. Jammer...."

Ik denk dat mensen heeeeel snel over zullen stappen naar een andere leverancier/os maker. Als bedrijf zit je echt niet te wachten op een dergelijke reactie.
Voor kritieke lekken blijft Microsoft patches uitbrengen.
Trieste uitkomst voor Microsoft. Misschien is het verstandig wanneer ze dit als speerpunt opnemen dit jaar/na de release van Vista.
Is het niet beter om meteen Vista zodanig te ontwerpen dat er minder kans is op lekken? :+ Geloof mij, daar zijn ze al langer dan vandaag mee bezig. Er bestaan ook vrij effectieve tools om lekken in broncode op te sporen. En door de modulaire/gelaagde architectuur van Vista zal ťťn lek niet zomaar toegang verlenen tot de hele computer.
Het gaat niet om de vraag of er bugs in de software zit, die zitten er altijd (ook in Vista straks). Dat maakt op zich ook niet zoveel uit. Natuurlijk is het voor MS zelf belangrijk dat ze hun software zo ontwikkelen dat er zo min mogelijk bugs onstaan (kleinere support afdeling, beter rendement), maar voor de klant is het belangrijk dat openstaande problemen asap gefixed worden.
Als die problemen zich daadwerkelijk ook uiten, ja. Als ze een jaar nodig gehad hebben om een lek te dichten waar absoluut niemand last van heeft gehad, wat is dan het probleem? Bugs en lekken zitten er altijd in, dan kan je je best enkel focussen op de meest zichtbare.
Het gaat hier om bugs en security holes die door Microsoft als kritiek gezien worden, geen minor issues dus.

Verder kun je altijd voorkomen dat je netwerk compromised wordt door andere beveiligings technieken, maar daar gaat het niet om want dat kun je net zo goed beweren dat MS helemaal geen patches hoeft te ontwikkelen...
Een bug kan kritiek zijn op vlak van beveiliging en toch een lage prioriteit hebben omdat in de praktijk niemand daar last van heeft.

Stel, een bepaalde DLL geeft totale toegang tot het systeem via een functie die niet geŽxporteerd wordt. Je moet dan al een knap hacker zijn om die te vinden. Dit is een kritiek lek, maar je mag er gerust een jaar over doen om de aanpassingen te maken om die functie overbodig te maken.

Lekken verborgen houden is dus wel degelijk een zeer effectieve manier om je software in de praktijk veilig te houden. Of ga jij inbrekers vertellen waar de sleutel van de achterdeur ligt?
Een tijd geleden werd een onderzoek bekend waarin de bestrijding van bugs werd vergeleken tussen Linux en Ms Windows. Toen kwam Linux ongunstig uit de bus, en het vermoeden bestond dat dat oa. zat in de officiele datum waarop de bug bekend werd. In de open source wereld is dat moment van ontdekking, en bij Microsoft was dat vaak later, bv. de dag dat ze de patch uitbrachten.

Ik ben nu benieuwd naar een vergelijking van de reactietijd van Linux en Microsoft op bovengenoemde bugs. Er blijft natuurlijk discussie over de ernst van de bug, maar dan kunnen we eindelijk eens min-of-meer objectief bekijken of een van beide aanpakken voordelen biedt.
Een reactietijd van een jaar? oei :o
Is dit inc. of exc. dev-tijd?
Het is wikken en wegen: Snelheid vs correctheid. Beide gaan bijna altijd wel ten nadele van elkaar.
MSFT zal nooit voor iedereen goed kunnen doen.
"Snelheid vs correctheid."

als't correct zou zijn zou't miss die bug niet hebben ;)
maar zouden mensne nog harder klagen omdat Vista/longhorn nog veel meer te laat is en dat er nog meer functionaliteit gesloopt is!
"Snelheid vs correctheid."
"Snelheid vs correctheid." van de patch!
Het is de tijd vanaf het moment van melding bij Microsoft tot het uitbrengen van de patch. Inclusief ontwikkeltijd dus :)
Die pieken vindt ik ook vrij hoog.
Ik zou niet verbaasd zijn als het gros van deze pieken oppgelost zijn door 'n service pack. Kijk bv. naar SP1 en SP2
ze kunnen misschien de releasecyclus zo aanpakken:
1) via de automatische windowsupdate enkel doorgeteste patches vrijgeven
2) de mogelijkheid laten aan de gebruiker om zelf manueel 'slechts-snel-geteste' patches te laten installeren, met melding dat dit geheel op risico van de gebruiker is

Het is lovenswaardig dat ze alles willen doortesten voor ze het in de windowsupdate smijten, maar een reuzegroot gat, zoals het wmf lek, zo lang openhouden is ook niet super.

Maw: de gebruiker zelf de keuze laten om de patch snel -doch ongetest- te laten installeren.
Met een heleboel disclaimers moeten ze hun wel kunnen indekken tegen eventuele juridische gevolgen van een slechte patch.
Debian heeft een stable en unstable tak, Gentoo heeft dat ook. Je kunt een keuze maken welk risico je wilt nemen.

Microsoft kan het zich natuurlijk nooit veroorloven om een unstable tak te hebben. Daarmee zouden ze publiekelijk toegeven dat ze onbetrouwbare software leveren. Marketing technisch niet erg slim lijkt mij. oftwel: ik denk niet dat zoiets er ooit komt.
Debian heeft niet alleen een stable en unstable maar ook een testing...

De testing is vergelijkbaar met beta software.

Unstable is (ondanks de naam) al erg stabiel en goed getest en geschikt voor systemen die niet mission-critical zijn, desktopsystemen dus.
Vergelijkbaar met de stabiliteit van windows xp.

Stable is ultrastabiel en door-en-door getest en bevat daardoor nogal verouderde software(geen bleeding edge dus). Microsoft heeft naar mijn weten geen os dat zo stabiel is(mischien 2K3 Server?).
De unstable tak van Debian zou je kunnen vergelijken met Beta software van Microsoft.

Ik zie echter niet hoe dit zou aangeven dat ze onbetrouwbare software uitgeven, dat doet Debian toch ook niet? Bij Debian worden overigens security fixes veel sneller in de unstable tak opgenomen dan in de stable tak, omdat ze eerst heel goed getest moeten worden.
Dat is bij Microsoft ook zo. De patch is vaak al heel snel beschikbaar in beta-vorm ('unstable'), maar wordt pas voor iedereen toegankelijk gemaakt via Windows Update ('stable') op het moment dat ie goed uitgetest is.

Het verschil is vooral dat niet iedereen zomaar toegang heeft tot die beta-patches. Daarvoor moet je als developer of OEM bij MS aangesloten zijn bij het beta-programma... of iets in die geest, ik ken ook de precieze details niet.

Maar het lijkt me wel logisch dat als MS de beta-patches ook gewoon via Windows Update oid zou aanbieden, dat er een HOOP fout gaat, omdat veel mensen het installeren zonder zich te beseffen wat de risico's zijn.
Bij Debian zijn dat soort risico's door een soort 'natuurlijke selectie' bijna uitgesloten. Alleen iemand die redelijk bekend is met de materie, zal uberhaupt van het bestaan van Debian afweten, en weten hoe hij een unstable distro downloadt, installeert, en onderhoudt.
Dit zijn wel hťle hoge reactietijden. Lijkt mij dat in het artikel wordt verwezen naar 'oplostijd'. Reactietijd is niets anders dan de tijd tussen aanmelden en het erkennen. Oplostijd daarentegen is de tijd tussen aanmelden en, hoe kan het ook anders, oplossen.

Desalniettemin duurt het oplossen van deze kritieke bug nog steeds te lang. Zijn dit soort tijden afgesproken bij de dienstverlening? Anders valt Microsoft niets te verwijten en is hier slechts sprake van gezeur.
Het lijkt me dat er voor een aantal van deze bugs niet verwezen kan worden naar bepaalde contractuele voorwaarden. Ik ben een juridische leek, maar volgens mij mag je er als consument er vanuit gaan dat een produkt datgene doet waar je het voor koopt. Voor een hedendaags OS zou je mogen verwachten dat dat ook inhoudt dat je je systeem veilig aan Internet kan hangen. Sterker nog, MS geeft dat zelf aan aangezien IE een onlosmakelijk onderdeel van het OS is ;)

Als blijkt dat het produkt niet aan de redelijke verwachtingen voldoet is de maker of leverancier verplicht om vebeteringen aan te brengen of het produkt terug te nemen. MS heeft natuurlijk een leuke constructie bedacht door bij OEM licenties te verwijzen naar de leverancier, maar dan zou er nog altijd sprake kunnen zijn van ketenverantwoordelijkheid.

Mijn punt: natuurlijk bevat software fouten. Je mag alleen wel van een leverancier verwachten dat deze fouten worden opgelost, ook als je niet een los supportcontract hebt om fouten op te lossen. Als dat wel het gebruikelijke mechanisme zou zijn, dan zou MS dat duidelijk moeten aangeven: dit OS bevat fouten, voor het oplossen hiervan moet u afzonderlijk betalen. Lijkt me commercieel niet zo'n aantrekkelijke propositie....
Reactietijd moet niet gezien worden als tijd die het duurt voordat Microsoft eraan gaat werken, maar tijd die het duurt voordat er een oplossing is; de reactie van Microsoft naar de buitenwereld. Voor gebruikers van Microsoft-software is het immers niet interessant dat Microsoft bezig is, maar ben je alleen geÔnteresseerd in de oplossing. Microsoft zou theoretisch een jaar bezig kunnen zijn, maar wel een reactietijd van 1 dag hebben in de suggestie die jij maakt. Volgens mij is het gekozen woord reactietijd daarom wel verdedigbaar :)
Krijgen we hier nou weer de wie-patch-sneller-microsoft-of-linux discussie?

Wat hťťl vťťl mensen vergeten is dat Linux veel vaker nieuwe versies uitbrengt waardoor je minder snel zit met oudere code.

Als windows ook om de 8 maanden oid een nieuwe versie uitbracht zou iedereen gek worden. Daardoor zitten ze dus langer met oude code opgescheept die niet overzichtelijk is.

Verder, mensen betrokken bij een Linux project blijven er lang aan werken. Bij een bedrijf als Micosoft heeft de "ontwerper" van een een bug het bedrijf al verlaten (mogelijk) en moet een andere ontwikkelaar als eerste de code gaan doorgronden en kijken hoe het zich allemaal verhoudt. Bij Linux gebeurt het ontwikkelen van een feature en het patchen ervan meestal door dezelfde persoon/personen, die hun productgebied beter kennen.

edit:
Volgens mij begrijpen de twee reageerders onder mij me verkeerd. Ik geef een andere verklaring waardoor OSS meestal sneller kan patchen, in dit geval actuelere code. Deze invalshoek ben ik nog nooit tegengekomen en het lijkt me daarom boeiend om een te bekijken wat de invloed hievan is.

Verder vind ik als fervente Windows gebruiker dat MS inderdaad te lang over patchen doet en dat open-source hier meestal (niet alls OS projecten patchen erg snel) erg veel punten voorheeft.
Krijgen we hier nou weer de wie-patch-sneller-microsoft-of-linux discussie?
Gezien het belang van dergelijke beveiligingspatches lijkt het mij best wel interessant om de reactie-/oplostijden van (alle) andere OS'en te kunnen vergelijken net die van Microsoft.
Als windows ook om de 8 maanden oid een nieuwe versie uitbracht zou iedereen gek worden. Daardoor zitten ze dus langer met oude code opgescheept die niet overzichtelijk is.
Niet overzichtelijk? Allereerst kan ik mij niet voorstellen dat Microsoft haar programma's niet of slecht documenteert. Daarnaast zou ik juist zeggen dat in een nieuw release juist meer patches nodig zouden zijn..
Ja, ik denk dat het interessant is om te weten hoe snel beide OS'en gepatched worden.

1. Omdat dat een belangrijk onderscheid betekent voor consumenten; als je auto kapot blijkt en je zou bij Ford een dag moeten wachten en bij Renault 3 maanden, dan vind je dat toch ook belangrijk? Nou geldt dat gewoon niet bij auto's, maar dus wel bij OS'en.

2. Omdat het mij enorm interesseert hoe een commercieel product presteert tov. een open source product. En hier hebben we dan iets wat enigszins objectief meetbaar en van belang is - veel andere criteria zijn veel lastiger vergelijkbaar.

Het is voor mij overigens helemaal niet zeker dat een van de twee 'wint'. Ik wil alleen graag weten hoe ze verhouden tot elkaar.
Het ergste is, dat Vista, het nieuwe OS dat voor de volgende 7 jaar voor de meeste mensen het OS wordt niks maar dan ook niks van verandering brengt.

inderdaad het hele principe is reeds 15 jaar verouderd, niet voorzien op hedendaags computergebruik.

Microsoft is hier niet consequent in geweest, en doordat ontwikkelaars geen duidelijk richtlijn hebben, is veel software onzorgvulidg geprogrameerd (in ms kan je met 20 verschillende registersleutels aan te passen 20 maal hetzelfde doen).
Hierdoor heb je nu een wildgroei van methodes om met het OS om te gaan.

Op zich niet zo erg moest het niet zijn dat ze daardoor zichzelf geblokeerd hebben op structurele wijzigingen te doen in windows.

Het ziet er dus niet naar uit dat je binnenkort verbetering mag verwachten. wel een mooie nieuwe layout en veel eye candy, coole effecten, mss ooit wel eens een nieuw filesysteem, maar voor de rest zal het patch it, solved blijven !

edit: [was een reactie op NeuroFobia ]
Heb je al eens het drivermodel voor Vista bekeken? Als ze dezelfde beveiligingen inbouwen voor alle andere componenten, wat ik toch wel minstens verwacht, zal Vista qua security echt wel veel verandering brengen.
Hij heeft het meer over de instelling die Microsoft heeft tov patches, niet dat Vista qua security beter/veiliger is. Mocht er een kritiek gat in Vista zitten, zullen ze nog altijd even veel tijd nodig hebben voordat ze het zaakje gedicht hebben.
Bij Windows XP wou men vooral zo snel mogelijk een opvolger van Windows 98, met een focus op functionaliteit en stabiliteit. Dat is bereikt maar security kreeg onvoldoende aandacht (omdat dit in 2000 nog niet zo kritiek was - veel minder internetgebruik). Een O.S. patchen dat niet van het begin met security in gedachte is geschreven, is een lastige zaak die z'n tijd vergt.

Vista daarentegen heeft security als een van de hoofdzaken. Ik vertrouw er dan ook op dat het veel beter te beheren is (vanuit het standpunt van de ontwikkelaars). De modulariteit maakt het eenvoudiger om te patchen en de geÔsoleerde module afzonderlijk te testen.

Ik geloof dan ook dat Microsoft heel wat efficienter zal zijn met patches voor Vista. Daar hebben ze nu de tijd voor gehad, terwijl het voor Windows XP roeien is met de riemen die ze hebben. En dat doen ze eerlijk nog niet zo slecht...
Define goed.

Het meest gebruikte OS wat is er, kan toch niet slecht zijn.

Zoals ik al vroeg: define goed.
Kijk maar naar LCD schermen of pentium 4's.
Leuke voorbeelden: LCD schermen, voor mij is het feit dat een LCD scherm minder ruimte in beslag neemt belangrijker dan de reactie tijd.
Je P4 voorbeeld, daarom zie je AMD ook steeds meer terrein winnen.

Windows heeft zoveel voordelen tov bv Linux, dat het door heel veel mensen als 'goed'/'beter dan' wordt gezien.
als ze nou eens een goed besturingssysteem zouden maken.
Altijd weer dit soort bullshit opmerkingen. Voor iedereen die Windows gebruikt en er niet mee kan leven: neem een ander OS of schrijf ZELF een besturingssysteem. Niemand houdt een pistool tegen je hoofd en zegt dat je perse MS producten moet gebuiken.
Ga naar school, koop een boek, lees nog eens de policy hier, volg cursussen en leer argumenteren. Of ga naar hypocrisie.com

Waarschijnlijk gebruik je zelf ook een Microsoft OS.
Hoe moeilijk bugfixes kunnen zijn zien we nu maar weer aan Apple die nu grote problemen heeft met de security update van QuickTime. Reactietijd was 2 maanden en gebruikers hebben nu toch grote problemen na installatie van de update (nou ja update, gewoon compleet nieuwe versie installeren), zowel op Mac als Windows. Apple adviseert nu dan maar om een oude versie te installeren.
@Bobco

Volgens mij zeggen ze dat alleen om van het gezeik af te zijn...... :*)

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