Avaleht Arvamus Miks ma vihkan Microsofti? 2.osa

Miks ma vihkan Microsofti? 2.osa

2. Mitte nii hea, halb ja kole

“… on lihtne olla pimestatud nende olulise kasutu suhtes saavutustunde järgi, mida saate nende üldse tööle saamisest. Aastal teised sõnad … nende põhilised disainivead on täielikult peidetud nende pealiskaudsed disainivead.”

— Hitchhikeri teejuht galaktikasse, Sirius Cybernetics Corporationi tooted.

Olgem ausad: sellist asja nagu veavaba tarkvara pole olemas. Esialgne programmide versioonid võivad aeg-ajalt kokku joosta, mälu jaotamata jätta või kokku puutuda testimata tingimustega. Arendajad võivad unustada turvaaugud, kasutajad võib teha asju, millele keegi ei mõelnud ja mitte kõik süsteemid ei ole identsed. Tarkvara Arendajad on ainult inimesed ja nad teevad vigu nüüd ja siis. See juhtub. Kuid kõigist suurematest tarkvaramüüjatest on Microsoftil nende toodete kvaliteedi osas üldiselt halvim rekord.

Lahinguvälja visandamine

Microsoftil on üsna lai tootevalik, kuid tegelikult on olemas vähem siin kui silma paistab. Microsoft on igavesti müünud sisuliselt sama tarkvara ikka ja jälle, mitmesugustes värvilistes uutes ümbrised.

Microsofti tooteid saab jagada kolme kategooriasse: rakendused, operatsioonisüsteemid ja täiendavad serveritooted. Rakendused hõlmavad järgmist: Microsoft Office’i komplekt, aga ka Internet Explorer, Media Player, Visio, Esileht jne. Operatsioonisüsteemid hõlmavad töölaua- ja serveriversioone Windows. Töölaual leiame Windows 9x / ME, NT Workstation, Windows 2000, XP ja Vista ning serveri lõpus on meil Windows NT Server, Windows 2003 Server ja sellised sordid nagu Datacenter. Täiendavad serveritooted, nt Internet Information Server (IIS) ja SQL Server, run on üks Windowsi serveritoodetest. Nad lisavad teenuseid (nt veebiserver või andmebaasiserveri funktsioonid) põhifailile, printimisele ja autentimisele teenused, mida Windows serveri platvorm pakub.

Kaks erinevat Windowsi perekonda

Töölaual on Windowsil kaks maitset: Windows 9x/ME tootesari ja Windows NT/2000/XP/Vista tootesari. Erinevad versioonid Üks tootesari on tehtud nii, et see näeks välja natuke erinev, kuid erinevus on selles, et ainult üksikasjad; need on sisuliselt samad. Windows ’95, ’98 ja ME põlvneb DOS-ist ja Windows 3.x-st ning sisaldab märkimisväärses osas vanu 16-bitine pärandkoodi. Need Windowsi versioonid on sisuliselt DOS-põhised, koos 32-bitised laiendused. Protsesside ja ressursside haldamine, mälu kaitse ja turvalisus lisati järelmõttena ja on parimal juhul algeline. See Windowsi tootesari on täiesti sobimatu rakenduste jaoks, kus turvalisus ja usaldusväärsus on probleem. See on täiesti ebakindel, nt võib ta küsida parooli, kuid see ei pahanda, kui te seda ei esita. Ei ole võimalik takistada kasutaja või rakenduste juurdepääsu ja võimalikku rikkumist kogu süsteemi (sealhulgas failisüsteemi) ja iga kasutaja saab muuta süsteemi konfiguratsioon, kas kogemata või tahtlikult. Windows 9x/ME liin on suunatud peamiselt tarbijatele (kuigi Windows ’95 turundus oli suunatud ka ärikasutajate juures). Kuigi kogu see tootesari jäi pensionile Windows XP vabastamisel arvutid, kus töötab Windows ’98 või (a vähemal määral) Windows ME on endiselt levinud.

Teine Windowsi tootesari sisaldab Windows NT, 2000, XP ja Vista ja serveritooted. See Windowsi perekond on parem kui 9x/ME liin ja vähemalt käivitab uue (st post-DOS) 32-bitise koodi. Mälu kaitse, ressursside haldamine ja turvalisus on natuke tõsisemad kui Windowsis 9x/ME ja neil on isegi mõningane toetus juurdepääsupiirangutele ja turvalisele failisüsteem. See ei tähenda, et see Windowsi perekond oleks sama usaldusväärne ja turvaline, nagu Redmondi turundajad väidavad, kuid võrreldes Windows 9x / ME-ga on Lisafunktsioonidel on vähemalt see eelis, et nad on olemas kõik. Kuid isegi see Windowsi rida sisaldab teatud kogust 16-bitist pärandit kood ja kogu 16-bitine allsüsteem on Microsofti otsene pärand OS/2 päeva IBM-iga. Lühidalt öeldes jagavad kõik 16-bitised rakendused ühte 16-bitist allsüsteem (nagu ka OS/2 puhul). Sisemälu kaitset pole, seega üks 16-bitine rakendus võib krahhida kõik teised ja kogu 16-bitine ka allsüsteem. See võib tekitada kokkujooksnud 16-bitisest püsivaid lukke kodeerige 32-bitisi ressursse ja lõpuks peatage Windows. Õnneks pole enam suur probleem nüüd, kui 16-bitistel rakendustel on kõik olemas, aga suri välja.

Kuigi Windows on aastate jooksul palju arenenud, suhteliselt vähe on tõesti paranenud. Windowsi uute versioonide uued funktsioonid kõik näitavad sama poolküpsetatud, lünklikku lähenemist. Iga lahendatud probleemi puhul Tutvustatakse vähemalt ühte uut probleemi (ja sageli rohkem kui ühte). Windows XP-l on rohkem rakendusi ja funktsioone kui kunagi varem. Kuigi see võib esmapilgul tunduda mugav, on kaasas funktsioonid pole nii head kui välise tarkvara pakutavad funktsioonid. Sest näiteks XP nõuab DSL-i (“wideband Internet”) toetamist võrgundus, skannerid ja muud välisseadmed sisseehitatud Microsofti abil kood selle asemel, et nõuda kolmanda osapoole koodi. Nii et sa jõuad asjadeni nagu DSL-võrk, mis kasutab valesid seadeid (ja pole mugav viis selle muutmiseks), skanneri tugi, mis ei lase teil oma skanneri valguskoopia funktsioon või digitaalkaamera liides, mis võimaldab teil kaamerast pilte alla laadida, kuid te ei saa selle veebikaamerat kasutada funktsioonina. Traadita (WiFi) võrgukaardid on veelgi suurem probleem: kus tootjad võiksid kaasata oma juhid ja kliendihalduri tarkvara Windowsi varasemates versioonides, kasutajad on nüüd uuesti kasutanud XP natiivse WiFi tugi. Kahjuks on XP WiFi tugi täis probleemid, mis põhjustavad traadita arvutite ühenduse kaotamise traadita ühendusega masendava regulaarsusega pääsupunkt. Samuti XP loomulik WiFi-tugi puuduvad lisafunktsioonid (nt täiustatud mitme profiiliga haldus) mida tootjad varem oma klienditarkvarasse lisasid.

See mõjutab isegi põhiteenuseid. Windows 2000 ja uuematel versioonidel on sisseehitatud DNS (domeeninimede süsteem) vahemällu salvestamine. DNS on mehhanism, mis lahendab Interneti host ja domeeninimed (nt www.microsoft.com) numbritesse Arvutites kasutatavad IP-aadressid (nt 194.134.0.67). Windowsi DNS-i vahemällu salvestamine põhimõtteliselt mäletab lahendatud hostinimesid kiiremaks juurdepääsuks ja DNS-i vähendamiseks Otsingud. See oleks tore omadus, kui poleks viga, mis ebaõnnestunud DNS-i otsingud salvestatakse vaikimisi ka vahemällu. Kui DNS-i otsing nurjub (ajutiste DNS-i probleemide tõttu) Windows salvestab ebaõnnestunud DNS-päringu vahemällu ja ei suuda jätkuvalt hostiga ühendust luua, hoolimata asjaolust, et DNS-server võib mõni sekund hiljem korralikult reageerida ning kursuserakendused (nt Internet Explorer ja Outlook) on olnud integreeritud operatsioonisüsteemi tihedamalt kui kunagi varem ja rohkem (varem eraldi) tooteid on operatsiooniga komplekteeritud süsteem.

Kõigi Windowsi versioonide ühised kujundusvead

Kõigil Windowsi versioonidel on mitmeid struktuurikujunduse vigu. Rakenduse installimise protseduurid, kasutaja vead ja põgenenud rakendused võivad kergesti rikkuda operatsioonisüsteemi pärast parandamist. Võrgustike tugi on halva Rakendamisega. Ebatõhus kood toob kaasa ebakvaliteetse jõudluse ja mõlemad mastaapsus ja juhitavus jätavad palju soovida. (Vt ka A liidet.) Tegelikult NT ja selle järeltulijad (või mis tahes Windowsi versioon) pole lihtsalt võrreldavad funktsionaalsuse, töökindluse või jõudlusega, mida UNIX-i kogukond on kasutanud kuni aastakümneid. Need võivad hästi töötada või mitte. Ühes süsteemis Windows kestab nädalaid, teisel võib see üsna sageli kokku kukkuda. Käisin Microsofti volitatud hariduskeskuses koolitustel ja mulle öeldi: “Nüüd installime Windowsi serveritesse. Paigaldamine tõenäoliselt ebaõnnestub ühes või kahes süsteemis [Neil oli kümme identset süsteemi klassiruumis], kuid seda juhtub alati – me ei tea, miks ja kumbagi teeb Microsoft.” Ma kordan, seda Microsofti volitatud partnerilt.

Olgu kuidas on… Isegi ilma paigaldusprobleemide või tõsisteta krahhid (sellised, mis nõuavad taastamistoiminguid või uuesti installimist) Windows ei tee seda tööd eriti hästi. Paljud kasutajad arvavad, et see on nii, kuid nad pole üldiselt alternatiive kogenud. Tegelikult Windows” ebausaldusväärsus on muutunud igapäevaseks ja isegi vanasõnaks; kardetud sinine Ekraan on ilmunud multifilmidesekraanisäästjates ja t-särkides lennujaamades ja hoonetes ning seal on isegi olnud Star Treki episood, kus pidi olema rikkis kosmoselaev välja lülitatud ja uuesti sisse lülitatud, et see käima saada.

Isegi kui Windows jääb üles, jätab see palju soovida. On vana, kuid siiski hea lauaarvuti (nt 450 MHz PII protsessor 256 MB RAM-iga, midagi, millest võisime vaid unistada viisteist aastat tagasi) neli või viis korraga ülesannetest piisab, et maksustada Windowsi multitegumtöötlusvõimalused nende piirideni, isegi kui saadaval on palju põhimälu. Ülesannete lülitid hakkavad võtma igavesti lakkavad rakendused reageerimast lihtsalt seetõttu, et nad ootavad süsteemiressursse, mida vabastavad muud rakendused (mis võivad olla peatunud ilma neid ressursse vabastamata) või kerneli ja raamatukogu rutiinid lukustuvad mingi tundmatu ootetingimusega. Varsti lukustub kogu süsteem täielikult või muutub kõike muud kui kasutuskõlbmatuks. Lühidalt öeldes on Windowsi protsessijuhtimine nagu ebaimpressiivne, nagu selle mälukaitse ja ressursside haldamine on ja operatsioonisüsteem, mis võib rakenduse tõrke korral täielikult krahhi minna. Esinemisi ei tohiks müüa tõsise mitme ülesande täitmise keskkonnana. Rahuldatud, see käivitab mitu protsessi korraga – kuid mitte eriti hästi. Hiljutine Windowsi versioonid (st XP ja Vista) on selles osas paremad ja rohkem stabiilne kui nende eelkäijad, kuid mitte suurejooneliselt. Kuigi neil on lapitud, et vähendada mõnede kõige tõsisemate probleemide mõju, OS-i arhitektuuri põhilised puudused jäävad alles; krahhi põhjustav rakendus (nt videopleier või sidepakett) võib süsteemi siiski lukustada või Visake see äkilisse ja spontaansesse taaskäivitusse.

Koodide eraldamine, kaitse ja vigade jagamine

Windows on üsna habras ja operatsioonisüsteem võib üsna rikkuda kergesti. See juhtub kõige sagedamini värskenduste, teenuse installimise ajal paketid, draiverid või rakendustarkvara ja probleem on olemas kõigis versioonides akendest siiani. Probleemi tuum seisneb selles, et Windows ei saa (või pigem ei ole mõeldud) eraldi rakendust ja töötamist süsteemi koodi ja seadetega. Kood läheb rakenduste installimisel segamini osad endast operatsioonisüsteemi kuuluvate failide vahel, aeg-ajalt asendades neid protsessis. Seaded kirjutatakse a-le keskregister, mis salvestab ka olulisi OS-i seadeid. Registri andmebaas on põhimõtteliselt ebaturvaline ja seaded, mis on OS-i või muu jaoks üliolulised rakendused on kergesti rikutud.

Veelgi rohkem probleeme põhjustavad Windowsi DLL-alamsüsteemi piirangud. Hea mitme ülesande ja / või mitme kasutajaga operatsioonisüsteem kasutab põhimõtet, mida nimetatakse koodi jagamiseks. Koodi jagamine tähendab, et kui rakendus töötab n korda korraga, siis koodisegment, mis sisaldab programmi koodi (mida nimetatakse staatiliseks segmendiks) laaditakse mällu ainult üks kord, kasutamiseks n erinevates protsessides, mis on seega sama rakendus. Ilmselt oli Microsoft kuulnud millestki nimega koodijagamine, kuid ilmselgelt ei saanud mõistest ja kasu või nad ei viitsinud kogu ideega vaeva näha. Mis iganes põhjusel, nad läksid ja kasutasid selle asemel DLL-e. DLL-failid sisaldavad dünaamiliste linkide teeke ja on mõeldud ainult raamatukogu funktsioonide jaoks. Windows ei anna ühiskasutust staatiline (kood) segmendil – kui käivitate 10 Wordi eksemplari, siis suurem osa Koodist laaditakse mällu 10 korda. Ainult murdosa kood, nt teegi funktsioonid, on teisaldatud DLL-idesse ja seda võib jagada.

DLL-i toe peamine probleem on see, et OS jälgib DLL-e nime järgi ainus. Erinevate DLL-ide jälgimiseks puudub piisav allkirjasüsteem Versioonid. Teisisõnu, Windows ei näe erinevust ühe vahel WHATSIT.DLL ja teine sama nimega DLL, kuigi need võivad sisaldada täiesti erinevat koodi. Kui DLL Windowsi kataloogis on olnud teise poolt üle kirjutatud, tagasiteed pole. Samuti järjekord, milles rakendused käivitatakse (ja DLL-id laaditakse) määrab, milline DLL muutuvad aktiivseks ja kuidas süsteem lõpuks kokku jookseb. Ei ole olemas sama DLL-i erinevate versioonide või DLL-ide eristamine mis on kaasas Windowsiga ja nendega, mis on kaasas rakendustarkvaraga. Rakendus võib panna oma DLL-id Windowsi DLL-idega samasse kataloogi installimise ajal ja võib DLL-id sama nimega üle kirjutada, kui need on olemas.

Millel see taandub, on see, et rakendus võib lisada osi endast operatsioonisüsteem. (See on üks põhjusi, miks Windows peab olema taaskäivitatakse pärast rakenduse installimist või muutmist.) See tähendab, et installiprotseduur tutvustab kolmanda osapoole koodi (loe: sertifitseerimata kood) operatsioonisüsteemi ja teistesse rakendustesse, mis laadivad mõjutatud DLL-id. Pealegi, kuna puudub tegelik vahetegemine süsteemitaseme kood ja kasutajataseme kood, DLL-ide tarkvara, mis on olnud mida pakuvad rakenduse programmeerijad või kasutaja võib nüüd töötada süsteemi tasemel. See rikub operatsioonisüsteemi ja muude rakenduste terviklikkust. Üsna tõhusa demonstratsiooni pakkus Bill Gates ise, kes, Windows 98 USB-plug-and-play funktsioonide Comdexi esitluse ajal, ühendas skanneri arvutiga ja põhjustas selle krahhi sinisele ekraanile. “Liigume otse mööda,” ütles Gates, “ma arvan, et see on põhjus, miks me ei saada seda veel.” Tore proovida, hr Gates, kuid muidugi Windows ’98 ja ME väljalaskeversioonid olid sama ebastabiilsed ja Windowsis 2000 ja selle sucessors uued probleemid on sisse toodud. Need versioonid Windows kasutab seadmete tuvastamiseks püsivara versiooni numbrit, nii et värskendatakse välisseadme püsivara võib põhjustada selle seadme “kadumise” PnP-le.

Teine, vähem kahjulik, kuid kõige tüütum koodi segaduse kõrvalmõju on et tarkvara erinevad keeleversioonid võivad segi minna. Välismaa rakenduse keeleversioon võib Windowsi täiendada või osaliselt üle kirjutada” dialoogisõnumite loend. See võib põhjustada dialoogiaknas küsimise “Kas sa oled kindel?” inglise keeles, millele järgneb kaks nuppu, mis on tähistatud, näiteks, “Da” ja “Nyet”.

Perifeersed draiverid kasutavad ka üsna nõrka allkirjasüsteemi ja kannatavad sarnased probleemid nagu DLL-id, ehkki vähemal määral. Näiteks on see üsna võimalik asendada printeridraiver teise sarnase draiveriga Windowsi keeleversioon ja selle tulemusena lehe vormingu sassi ajamine. Printeri Windowsi eri keeleversioonide draiverid sisaldavad mõnikord täielikult erinev kood, mis genereerib erineva printeriväljundi, kuid Windows pole sellest teadlik erinevusest. Seda probleemi on väljaandega mõnevõrra lahendatud Windows 2000, kuid see pole veel kaugeltki täiuslik.

OS-i ja rakenduse koodi segamine

OS-i kujundamine süsteemi ja rakenduse koodi tahtlikuks segamiseks sobib Microsofti toodete komplekteerimise ja integreerimise strateegia. Tulemused on järgmised: Ilmselge: iga failitoiming, mis hõlmab käivitatavat koodi, paneb sisuliselt kogu operatsioonisüsteemi ja selle rakendused ohtu ning rakendusvead tähendavad sageli OS-i vead (ja krahhid) samuti. See toob kaasa naeruväärsed “probleemid” näiteks Outlook Express põhjustab Windowsi krahhi, kui see on “kõrge krüptimine” versioon, mille lokaadiks on seatud Prantsusmaa. Meilisõnumile vastamine võib krahhi minna kogu süsteem, probleem, mis on jälgitav ühest DLL-ist, mis kaasas Outlook. (Kas sa oled ikka veel minuga?)

Hästi kujundatud ja jõuliselt kodeeritud operatsioonisüsteemis ei saa midagi sellist kunagi juhtuma. Mis tahes operatsioonisüsteemi esimene disainikriteerium on see, et süsteem, rakendused ja (mitme kasutajaga keskkonnas) kõik kasutajad eraldatakse ja üksteise eest kaitstud. Lisaks sellele, et ükski Windowsi versioon ei tee seda vaikimisi takistab see aktiivselt asjade seadistamist sel viisil. The DLL Fiasko on vaid jäämäe tipp. Te ei saa säilitada ega piisavalt taastada operatsioonisüsteemi terviklikkust, te ei saa säilitada versioonikontrolli ja te ei saa seda teha takistada rakendusi ja kasutajaid üksteist segamast ning süsteemi, kas kogemata või tahtlikult.

Pärast remonti

Siis puudub Windowsil piisav remont või hooldus režiim. Kui midagi läheb valesti ja väike viga või korruptsioon esineb ühes (sõna otseses mõttes) tuhandetest failidest, mis moodustavad Windowsi, sageli on ainus reaalne lahendus suuremahuline taastamisoperatsioon või isegi operatsioonisüsteemi uuesti installimiseks. Jah, sa lugesid õigesti. Kui teie operatsioonisüsteem äkki või järk-järgult lakkab korralikult töötamast ja komponendid, millel te remondivajadus on teadmata või on Windowsi poolt lukustatud, standard lähenemine probleemile (nagu soovitab Microsoft) on teha täielik Taasinstalli. Pole olemas sellist asja nagu ühe kasutaja režiim või hooldus režiim remondi tegemiseks, samuti pole head võimalust teada saada, millisel komponendil on on kõigepealt rikutud, rääkimata kahjustuste heastamisest. (2018. aasta Niinimetatud “turvarežiim” lihtsalt vahetab konfiguratsioone ega paku piisav kontroll süsteemi tõsiseks parandamiseks.)

Windowsi on sageli kritiseeritud paljude probleemide pärast, mis tekivad installides selle juhuslikule arvutile, mis võib olla A-bränd või kloon süsteem mis tahes võimalikus konfiguratsioonis. See kriitika ei ole täielikult Põhjendatud; lõppude lõpuks pole praktiliselt teostatav kõiki ette näha võimalikud riistvarakonfiguratsioonid, mis võivad kasutajal esineda. Kuid see pole mõte. Asi on selles, et need probleemid on sageli võimatu parandada või isegi korralikult diagnoosida, sest enamik Windowsi operatsioonisüsteeme on väljaspool kasutajate või administraatorite oma kontrolli. See kehtib muidugi vähem Windows 9x/ME kohta. Sest need on sisuliselt DOS-i tooted, saate süsteemi taaskäivitada, kasutades DOS-i ja teha teatud määral käsitsi remonti. Windows NT ja selle järeltulijatega See on üldiselt võimatu. Windows 2000, XP ja Vista tulevad välise remondikonsooli utiliidiga CD-l, mis võimaldab teil mõnda juurdepääs kahjustatud Windowsi installi failisüsteemile. Aga see selleks.

Suutmatust remonti teha on teatud määral käsitletud Windows XP. Sellega on kaasas funktsioon “Süsteemitaaste”, mis jälgib muudatusi operatsioonisüsteemis, et administraatorid saaksid süsteemi eelmisesse olekusse tagasi pöörata enne probleemi tekkimist. Samuti üritab funktsioon “System File Check” Veenduge, et umbes 1000 süsteemifaili on need, mis algselt olid Installitud. Kui “major” süsteemifail asendatakse teise versiooniga (näiteks kui Windows XP DLL-faili kirjutab üle Windows ’95 DLL koos sama nimi) algne versioon taastatakse. (Muidugi ka see takistab eemaldamast selliseid asju nagu Outlook Express või Progman.exe, kuna olulise süsteemifaili spetsifikatsioon on üsna lohakas.) Windows Vista viib need funktsioonid veelgi kaugemale, lisades tehingupõhised põhimõtted. See suurendab edukuse võimalusi tagasipööramine muudatustest, mida ei ole veel püsivalt tehtud.

Enamik neist lahendustest on suures osas kasutaja kontrolli alt väljas. Kuigi mõnel neist võib olla kahjulik mõju (nt failisüsteemi kontroll võib tagasi võtta vajalikud muudatused) nende tõhusus on oma olemuselt piiratud. Seal kas on palju rikketingimusi, mis takistavad automatiseeritud remondifunktsioone kõigepealt korrektsest töötamisest. Kui Windows katkeb, kuvatakse Automatiseeritud funktsioonid sellest veast taastumiseks purunevad tavaliselt samuti. Samuti vigade arv, millega automatiseeritud remondivõimalused saavad hakkama on piiratud. Mingil hetkel on käsitsi sekkumine ainus võimalus, kuid mis nõuab piisavat hooldusrežiimi, mida Windowsil pole. Kaubandusliku operatsioonisüsteemi võimetus võimaldada oma hooldust on selle ebaküpsuse hea demonstreerimine.

Sellegipoolest on XP ja Vista süsteemitaaste lisavalikud paranemas võrreldes eelmise olukorraga, kuna vähemalt teatud määral taastumine on nüüd võimalik. Teisest küljest illustreerib see Microsofti Kludgy lähenemine väga tõsisele probleemile: selle asemel, et rakendada muudatusi arhitektuur OS-i korruptsiooni vältimiseks, nad põlistavad põhidisaini viga ja proovige pärast selle kahjuga toime tulla. Nad ei paranda auku teie katusel nad müüvad teile ämbri, et selle asemel selle alla panna. Kui ämber ülevoolud (st süsteemi taastamise funktsioonid ei ole piisavad probleem) sul on ikka.

Raisatud ressursid, raisatud investeeringud

Windowsi libisev disain ei kajastu ainult selle vigases arhitektuur. Selle koodi üldine kvaliteet jätab palju soovida samuti. See ei tähenda mitte ainult ebaproportsionaalselt suurt hulka vigu, aga ka palju ebaefektiivsust. Microsoft vajab vähemalt kolme või neli korda rohkem riistvara, et pakkuda sama jõudlust kui teised operatsioonisüsteemid (nt Unix) annavad palju vähem. Samamoodi sarnastel riistvaradel konkureerivad tooted toimivad palju paremini või töötavad isegi hästi riistvara kohta, mis ei vasta Microsofti minimaalsetele süsteeminõuetele.

Ebaefektiivne kood ei ole ainus probleem. Teine probleem on see, et enamik kellasid ja vilesid Microsofti toodetes on kallid täiendavad riistvaranõuded ja hooldus, kuid ei suurene tootlikkus üldse. Arvestades asjaolu, et IKT investeeringud peaksid tasuge end ära suurema tootlikkuse, väiksemate kulude või mõlema korral, see tähendab, et enamik Microsofti toodete “täiustusi” viimastel aastakümnetel on investeeringutasuvuse seisukohast olnud ajaraiskamine. Tüüpiline kontoriülesanded (nt raamatupidamine, andmetöötlus, kirjavahetus) on ei ole sisuliselt muutunud ja võtab ikkagi nii palju aega ja tööjõudu kui nad tegid seda MS-DOS-i ajastul. Kuid vajalik riistvara, tarkvara ja IKT-töötajad on mitmekordistunud. Väga vähesed neist investeeringutest oli kasumi proportsionaalne kasv.

Apollo kapslite arvutites piisas vaid 32 kilobaidist RAM-ist panna mehed Kuule ja viia nad turvaliselt tagasi Maale. The Voyager süvakosmose sondid, mis saatsid meile hulgaliselt pilte ja teaduslikke andmeid päikesesüsteemi väliskülgedest (ja teeb seda ka edaspidi tähtedevahelisest ruumist) on pardaarvutid, mis põhinevad 4-bitisel protsessoril. An 80C85 protsessor 176 kilobaidi ROM-i ja 576 kilobaidi RAM-iga oli kõik see juhtis Sojourneri robotit, mis sõitis üle Marsi pinna ja edastas geoloogiliste andmete andmeid ja kõrgresolutsiooniga pilte täisvärvides Stereo. Aga kui mul on 800MHz Pentium III koos 256 megabaidi RAM-iga ja 40 gigabaiti kettaruumi ning proovin vanaemale kirja kirjutada kasutades Windows XP-d ja Office XP-d, võtab töö mind igavesti, sest minu arvuti on alatoidetud!

Serveri- või võrgupõhine andmetöötlus ei ole samuti lahendus, peamiselt seetõttu, et Windowsil pole reaalse koodi jagamise võimalust. Kui peaksite vahetama kümne tööjaama töökoormus rakendusserverisse (kasutades Windowsi) Terminal Server, Citrix Server või mõni muu ASP-laadne lahendus) vajavad teoreetilist kümnekordset süsteemi ressurssi igas tööjaamas see asendati sama jõudluse säilitamiseks, arvestamata vältimatut üldkulu, mis võivad kergesti ulatuda veel 10 või 20 protsendini.

Siis on uskumatult palju ebaefektiivset või isegi täiesti mittevajalik kood Windowsi failikomplektis. Võtke 3D Pinballi mäng Windowsis Näiteks 2000 Professional ja XP Professional. See mäng (leiate selle all \Program Files\Windows NT\Pinball) on installitud koos Windowsiga ja võtab paar megabaiti kettaruumi. Kuid enamik kasutajaid ei saa kunagi teada, et see istub seal, raiskab ladustamist ja ei tee üldse midagi produktiivset. Seda ei kuvata programmi menüüs ega juhtpaneelil ega otseteed sellele. Kasutajalt ei küsita installimise ajal selle kohta küsimusi. Aastal asjaolu, et selle ainus mõeldav eesmärk oleks illustreerida Microsofti mõiste “professionaalne” määratlus. Pole ime, et Windows on vajanud üha rohkem ja rohkem ressursse aastate jooksul. Mõni megabait ei tundu võib-olla palju, kuid seda ainult seetõttu, et oleme harjunud Windowsi tohutute jalajälgedega ja Windowsi rakendustega. Pealegi, kui Microsoft installib terve pinballi mängu, mida enamik kasutajaid ei vaja ega taha, nad ilmselgelt ei hooli ressursside säilitamisest (mille eest maksab kasutajaskond). Mida teeb mis räägivad teile ülejäänud koodi ressursitõhususest? Las mina andke teile vihje: 2002. aasta aprillis PC Magazine’is avaldatud tulemused näitavad, et uusim Samba tarkvara ületab Windows 2000 jõudlust umbes 100 protsenti võrdlustestide korral. Mastaapsuse osas näitavad tulemused, et Unix ja Samba saavad hakkama neli korda rohkemate kliendisüsteemidega kui Windows 2000, enne kui etendus hakkab langema.

Teine näide on see, mis juhtus, kui üks mu enda klientidest vahetas Unix Windowsile (selle käigu põhjuseks on vajadus käivitada mõned veebipõhised raamatupidamispaketid koos BackOffice’i ühenduvusega serveris). Nende esimene server jooksis Unix, Apache, PHP ja MySQL ning tegi kõik, mis tal oli teha mootoriga, mis vaevalt tühikäigul töötab. Samas süsteemis, mille nad seejärel installisid Windows Server 2003, IIS, PHP ja MySQL, pärast mida isegi kõige lihtsam PHP-skriptid (nt tavaline 100-realine vormigeneraator) katkeksid, kui 30 teise täitmise ajalõpp ületati.

Paradoksaalsel kombel on aga tõsiasi, et Microsofti tooted vajavad humongous vaiasid riistvara, et korralikult toimida, on aidanud kaasa nende kaubanduslikule tegevusele edu. Paljud integraatorid ja edasimüüjad suruvad Microsofti tarkvara, sest see võimaldab neil välja kirjutada uusimaid ja raskemaid riistvaraplatvorme turg. Unix ja Netware suudavad pakkuda sama või paremat jõudlust paljudel juhtudel vähem. Windows 2000 ja XP vajavad aga suuremaid ja kiiremaid süsteeme ning on sageli ei ühildu vanemate riistvara- ja püsivara versioonidega (eriti BIOS). See ja asjaolu, et riistvaratootjad lõpetavad toe vanem riistvara ja BIOS-id, sunnib kasutajat ostma kallist riistvara koos investeeringutasuvus oluliselt ei suurene. See suurendab riistvara müüki, “kalli, hinnatud kliendi” arvelt. Edasimüüjad teenivad rohkem raha, kui nad suruvad Microsofti tooteid. Nii lihtne see ongi.

Paljud väikesed vead teevad suure

Lisaks ülaltoodud (ja muudele) suurtele vigadele on ka vapustav väikeste vigade hulk. Tegelikult on nii palju väiksemaid vigu, et nende õhuke arvu võib liigitada suureks veaks. Lühidalt, üldine kvaliteet Microsofti kogu programmikoodide komplekt on ebastandardne. Kontrollimata puhvrid, kontrollimata sisend-/väljundtoimingud, võistlustingimused, valesti rakendatud protokollid, ressursside jaotamise ebaõnnestumine, keskkonnaparameetrite kontrollimata jätmine, t et cetera ad nauseam… Sa nimetad seda, see on seal. Microsofti tooted sisaldavad mõned äärmiselt lohakaid koode ja halvad kodeerimistavad, mis annaksid bakalaureuseõpe mõned hästi teenitud halvad märgid. Nende puudumise tõttu kvaliteedikontroll, Microsofti tooted ja eriti Windows on täis sõna otseses mõttes tuhandeid ja tuhandeid vigu ja tõrkeid. Isegi paljud veateated on valed!

Mõnda neist vigadest võib liigitada pigem kohmakaks disainiks kui kui lihtsalt lohakus. Hea näide on Windowsi pika failinime tugi. Aastal katse lubada pikki failinimesid Windows ‘9x/ME, Microsoft tahtlikult murdis FAT-failisüsteemi. Nad salvestasid laienduse teave tahtlikult ristseotud kataloogikirjeteks, mis on ilmselt üks nende räpasemaid kludgesid üldse. Ja kui sellest ei piisanud, nad muutsid seaduslikuks, et failinimed sisaldavad tühikut. Sest see ei ühildu Windowsi enda käsurea sõelumisega (Windows ootab endiselt vana FAT-märge) oli vaja veel ühte kludge ja tühik pidi olema jutumärkides. See segas (ja murdis) paljusid programme, sealhulgas paljud Microsofti enda omad, mis olid Windowsiga kaasas.

Teine hea näide on Windowsi näiline tõstutundlikkus. Tundub, et Windows teeb käsitsemisel vahet suur- ja väiketähtedel failinimedel, kuid aluseks olevad tarkvarakihid on endiselt tõstutundlikud. Nii Windows muudab ainult failide ja kataloogide täheregistrit sellisena, nagu need esitatakse kasutajale. Tegelike failide ja kataloogide nimed võivad olla salvestatud suurtähtedega, väiketähtedega või segatähtedega, kui need on veel esitatud suurtähtedega väiketähtedega failinimedena. Loomulikult ei põhjusta see lahknevus probleeme ainult Windowsi keskkonnas. Kuna aluseks olev kood on sisuliselt tõstutundlik, juhtum ei ole Windowsi toimimise jaoks kriitiline. Kuid niipea, kui soovite lisada Unixi-põhiseid teenuseid (nt a Unixi-põhine veebiserver IIS-i asemel) avastate, et Windows on sassi läinud failinimede ja kataloogide puhul.

Kuid enamik Windowsi vigu ja tõrkeid on lihtsalt lohaka töö tulemus. Loomulikult ei ole sellist asja nagu veavaba tarkvara, kuid vigade hulk Windowsis leiduv on pehmelt öeldes ebaproportsionaalne. Näiteks teenus Windows NT 4.0 pakk 4 üritas parandada umbes 1200 viga (jah, tuhat kakssada). Kuid seal oli juba kolm eelmist hoolduspaketti Aeg! Microsoft tunnistas seda häbitult ja isegi kiitles, et tal on “täiustatud” NT 1200 punktil. Siis pidid nad vabastama mitu järgnevatel kuudel rohkem järgnevaid hoolduspakette, et parandada järelejäänud küsimused ja muidugi lisaprobleemid, mille oli tekitanud hoolduspaketid ise.

Microsofti arendajate sisemine memo mainis 63 000 (jah: kuuskümmend kolm tuhat) teadaolevat defekti algses Windows 2000 väljalaskes. Keith White, Windowsi turundusdirektor, ei eitanud dokumendi olemasolu, kuid väitis, et selles sisalduvad avaldused tehti selleks, et “motiveerida Windowsi arendusmeeskonda”. Ta jätkas, öeldes: “Windows 2000 on seni kõige usaldusväärsem Windows.” Jah, seda ta ütles. Toode, millel on 63 000 teadaolevat defekti (pange tähele, see on ainult teadaolevad defektid) ja ta tunnistab, et see on parim, mida nad teha saavad.

Ja lugu jätkub: Windows XP hoolduspakett Service Pack 2 reklaamiti aadressiks suur hulk turvaprobleeme ja muudab andmetöötluse turvalisemaks. Selle asemel puruneb palju asju (enamasti Microsofti konkurentide valmistatud tooted, kuid muidugi see on lihtsalt kokkusattumus), kuid ei paranda tegelikult tegelikke turvavigu. XP-SP2 esimest suuremat turvaauku kirjeldasid turvaeksperdid kui “mitte auk, vaid pigem kraater” ja lubas allalaaditavat koodi tulemüüriteabe võltsimiseks. Vaid päevad pärast XP-SP2 vabastamist esimene Avastati SP2-ajastu Internet Exploreri haavatavus. Peale selle SP2 jätab paljud mittevajalikud võrgukomponendid sisse, punnitab õigused, jätab IE ja OE pahatahtlikele skriptidele avatuks ja installib paketti filtri, millel puudub väljumise filtreerimise võime. See muudab selle ka rohkem kolmandate osapoolte toodetele (eriti multimeedia pistikprogrammidele) on raske juurde pääseda ActiveX-juhtnupud, mis omakorda takistab üsna natuke Microsofti konkurentide tehtud multimeediumitarkvara. XP-SP2 kõige rohkem märgatav efekt (välja arvatud katkine rakenduse ühilduvus) on sagedased hüpikaknad, mis annavad kasutajale turvatunde. Peale selle platseebo efekt kauaoodatud ja paljukiidetud XP-SP2 ei paranda tegelikult väga palju.

2005. aasta suvel Jim Allchin, tollane grupi asepresident, kes vastutas Windowsi eest. Lõpuks läksin ja tunnistasin seda kõike. Harvaesinevas korporatiivses väljapanekus aususes, ta ütles Wall Street Journalile, et esimene versioon Longhorn (siis Windows Vista koodnimi) pidi olema täielikult lammutatud, sest ka programmikoodi kvaliteet oli halvenenud Palju. Probleemi juur, ütles Allchin, oli Microsofti ajalooline Lähenemine tarkvara arendamisele (nn “spagetikood” kultuur”), kus ettevõtte tuhanded programmeerijad igaüks töötavad välja oma kooditüki ja see oleks siis kõik kokku õmmeldud lõpus. Allchin ütles ka, et on seisnud silmitsi vastuseisuga tema üleskutsele täiesti uus lähenemine arengule, esiteks Gatesilt endalt ja siis ettevõtte insenerid.

MS arendajad: “Me oleme mornid”

Allchini paljastused ei tulnud suure üllatusena. Osa allikast kood Windows 2000-le oli varem Internetti lekkinud ja ilus see ei olnud nii. Microsofti lipulaev osutus suureks laialivalguvaks spagetid assamblees, C ja C++, kõik koos kleeplindi ja paberiga Klippe. Lähtekoodifailid sisaldasid palju nüüdseks kurikuulsaid kommentaare, sealhulgas “Me oleme mornid” ja “Kui muudate vahekaarte tühikuteks, siis teid tapetakse! Seda tehes f***s ehitamise protsess”.

Seal oli palju viiteid idiootidele ja mornidele, mõned välised, kuid enamasti Microsoftis. Näiteks:

  • Failis private\ntos\rtl\heap.c, mis pärineb aastast 1989:
    // Konkreetne on sel juhul Office95, kellele meeldib
    // vabastada juhuslik kursor, kui käivitate Word95 töölaualt
    // otsetee.
  • Failis privaatne\ntos\w32\ntuser\kernel\swp.c alates 11-juuli-1991:
    // idiootidele nagu MS-Access 2.0, kes SetWindowPos( SWP_BOZO )
    // ja puhuvad end kestale ära, siis laseb
    // lihtsalt ignoreerida nende palvet salvest eemaldada.
  • Moroneid leidub ka failis private\genx\shell\inc\prsht.w:
    // Me oleme sellised mornid. Wiz97 läbis IE4 ja IE5
  • Ja privaatselt\shell\shdoc401\unicpp\desktop.cpp:
    // Me oleme mornid. Muutsime IDeskTray liidest IE4
  • In private\shell\browseui\itbar.cpp:
    // tuleks rakendustes endis fikseerida. Morons!
  • Nagu ka privaatselt\shell\ext\ftp\ftpdrop.cpp:
    Peame seda tegema ainult seetõttu, et Exchange on morn.

Microsofti programmeerijad võtavad ka oma kohustuse hoiatada oma kaasarendajaid tõsiselt ebasobivate tavade vastu, mis on ilmselt toime pandud Regulaarselt. Seal on üle 4,000 viite “häkkimisele”. Nende hulka kuuluvad:

  • Failis privaatne\inet\mshtml\src\core\cdbase\baseprop.cxx:
    // HACK! HACK! HACK! (Mohanb) Selleks, et parandada #64710
    // sellel väga hilisel kuupäeval
  • In private\inet\mshtml\src\core\cdutil\genutil.cxx:
    // HACK HACK HACK. EEMALDAGE SEE, KUI MARLETT ON LÄHEDUSES
  • Privaatselt\inet\mshtml\src\site\layout\flowlyt.cxx:
    // Jumal, ma vihkan seda häkkimist …
  • In private\inet\wininet\urlcache\cachecfg.cxx:
    // Loll häkkimine tagasi ühilduvuse jaoks. *Ohkama*
  • Privaatselt\ispu\pkitrust\trustui\acuictl.cpp:
    // ACHTUNG! HACK ON PEALE HACK ALERT: // Uskuge või mitte,
    pole võimalust praegust kõrgust saada
  • In private\ntos\udfs\devctrl.c:
    // Lisage hack-o-rama vormingute parandamiseks.
  • Privaatselt\shell\shdoc401\unicpp\sendto.cpp:
    // Mondo hackitude-o-rama.
  • Privaatses\ntos\w32\ntcon\server\link.c:
    // TOHUTU, TOHUTU hack-o-rama, et NTSD-d sellega alustada protsess!
  • Privaatselt\ntos\w32\ntuser\client\dlgmgr.c:
    // SURMA HÄKKIMINE!!
  • In private\shell\lib\util.cpp:
    // KOHUTAV JUBE NO GOOD VERY BAD HACK
  • Privaatselt\ntos\w32\ntuser\client\nt6\user.h:
    // Selle häkkimise suurus on võrreldav riigivõla // omaga
    .

Kõige murettekitavam aspekt ei ole siin ainult see, kuidas need halvad tavad püsivad ja leiavad isegi tee vabanemishoonetesse suures osas Numbrites. Lõppude lõpuks on vähesed asjad nii püsivad kui “ajutine” lahus. Samuti pole üllatav, kui palju iidset koodi veel eksisteerib Windowsi uusimad versioonid (kuigi see on mõnevõrra häiriv et näha, kuidas aastakümnete vanused vead on jätkuvalt probleemiks). Ei, kõige hirmutavam on see, et Microsofti arendajad ilmselt teavad nad teevad kohutavaid asju, mis tõsiselt kahjustavad kvaliteeti lõpptootest, kuid ilmselt ei suuda nad teadaolevat halba parandada oma koodi kvaliteeti.

Nagu te võib-olla mäletate, oli Windows XP juba selleks ajaks, kui ülaltoodud lähtekood lekkis. Tegelikult oli Microsoft juba 2004. aastal rääkinud Longhorni (Windows Vista) kohta kolm aastat. Vaid mõni kuu pärast lähtekood lekkis välja, teatati, et WinFS, mida reklaamitakse kui Microsofti oma lipulaev Relational File System Of The Future, ei saadaks Vistaga Pealegi. Põhjust pole raske ära arvata: Windowsi programmikoodist on saanud aastate jooksul üha enam kättesaamatuks ja pöördumatuks.

Pikkade aastate jooksul pärast XP turuletoomist on Apple välja tulnud viitega suuremad uuendused OSX-ile, täiendused, mida (julgen öelda?) installida umbes nii palju vaeva, kui kulub hammaste pesemiseks hommikul. Ei mingit õudusunenägu kõned tehnilisele toele, ei mingeid äkilisi riistvara kokkusobimatusi ega probleeme. Veel Microsoft ei ole suutnud sammu pidada ja ülaltoodud näide nende olekust Programmi koodis näitab selgelt, miks.

Ebausaldusväärsed serverid

Kõik need vead mõjutavad muidugi Windowsi töökindlust ja kättesaadavust. Sõltuvalt rakendusest ja süsteemi koormusest on enamik Windowsi süsteemid vajavad tavaliselt sagedast taaskäivitamist, kas probleemide lahendamiseks või regulaarselt, et vältida jõudluse halvenemist Windowsi tõttu värisev ressursside haldamine.

Töölaual on see piisavalt halb, kuid Windowsis on samad vead serveri toodetel. Servereid kasutatakse palju tõenäolisemalt missioonikriitilise rakendusena kui tööjaamad on, seega Windowsi piiratud kättesaadavus ja selle mõju ettevõtlusele muutub suureks probleemiks. Tüüpilise Windowsi-põhise tööaeg serverid tõsistes rakendustes (st rohkem kui lihtsalt faili- ja printimisteenused; mõne tööjaama puhul) kipuvad piirduma maksimaalselt mõne nädalaga. Üks või kaks serveri krahhi (loe: äritegevuse katkestused ja andmete kadumine) iga kord Paar kuud ei ole haruldased. Serveri operatsioonisüsteemina puudub Windowsil selgelt Usaldusväärsus.

Windowsi serveritooted pole isegi tegelikult serveri operatsioonisüsteemid. Nende arhitektuur ei erine tööjaama versioonidest. Server ja tööjaam NT tuumad on identsed ja kahe registrivõtme muutmisest piisab, et veenda tööjaama, et see on server. Võrguvõimalused on endiselt olemas põhineb suures osas võrdõigusvõrgu meetodil, mis oli osa Windowsist Töörühmad 3.11 ja et Microsoft kopeeris pärast seda, kui see oli edukalt läbi viidud teerajajaks Apple ja teised kaheksakümnendate keskel. Muidugi mõni kood serveritooteid on jõudluse tagamiseks laiendatud või optimeeritud ja Lisatud on domeenipõhine autentimine, kuid see ei muuda seda tõeseks serveri platvormi. Seda ei tee ka asjaolu, et NT Server maksab peaaegu kolm korda sama palju kui NT Workstation. Tegelikult räägime me veidi enamast kui Windowsist steroidide töörühmadele.

1999. aasta novembris viis Sm@rt edasimüüja Steven J. Vaughan-Nichols läbi testi võrrelda Windows NT Serveri stabiilsust (arvatavasti töötab Microsoft Internet Information Server) avatud lähtekoodiga Linuxi omaga, mis töötab süsteem (töötab Samba ja Apache). Ta kirjutas:

Tavapärane tarkus ütleb, et Linux on uskumatult stabiilne. Alati skeptiline, Otsustasime selle väite 10 kuu jooksul proovile panna. Meie test, käivitasime Caldera Systems OpenLinux, Red Hat Linux ja Windows NT Server 4.0 koos hoolduspaketiga Service Pack 3 dubleeritud 100MHz Pentiumi süsteemides koos 64 MB mälu. Alates sellest, kui me jaanuaris oma testimissüsteemid esimest korda käivitasime, Võrgupäringud on saadetud igale serverile paralleelselt standardi jaoks Interneti-, faili- ja printimisteenused. Tulemused olid üsna paljastavad. Meie NT server kukkus kokku keskmiselt kord kuue nädala jooksul. Iga ebaõnnestumine võttis umbes 30 minutit parandamiseks. See pole nii halb, kuni arvate, et kumbki Linuxi server pole kunagi alla läinud.

Huvitav: krahh, mille parandamiseks kulub 30 minutit, tähendab, et midagi kriitilist on kahjustatud ja vajab parandamist või taastamist. Vähemalt nii võtab rohkem kui lihtsalt taaskäivitamisega. See juhtub kord kuue nädala jooksul serveris ja seda peetakse “mitte nii halvaks”… Mõtle see. Pange tähele ka seda, et enamik teisi Unixi maitseid, nagu Solaris, BSD või AIX, on sama usaldusväärne kui Linux.

Kuid Windowsi ja tegelike tööaja näitajate vahel on isegi suurem kui Vaughan-Nichols kirjeldab eespool. Võrrelge seda pooletunnist seisakut kuue nädalani Netware’i omani, järgmises Techwebi artiklis 9. aprillil 2001:

Server 54, kus sa oled?
Põhja-Carolina ülikool on lõpuks leidnud võrguserveri, mis kuigi neli aastat kadunud, pole kogu selle aja jooksul ühtegi paketti vahele jätnud. Proovige nii, nagu nad võiksid, ülikooli administraatorid ei leidnud serverit. Töötades Novell Inc.-iga (laos: NOVL), jälgisid IT-töötajad seda jälgides hoolikalt kaablit, kuni nad sõna otseses mõttes seina jooksid. See Server oli hooldustöötajate poolt ekslikult kipsplaadi taha pitseeritud.

Kuigi selle loo tegelikus tões on kahtlusi, on see  teadaolev fakt, et Netware’i serverid on võimelised aastaid katkematu teenus. Vahetult enne selle kirjutamist tõin meie juurde Netware’i serveri peakontori. See oli Netware 5.0 server, mis käivitas ka tarkvara, et toimida ettevõtte SMTP/POP3 serveri, faksiserveri ja peamise viirusetõrje võrgu, lisaks regulaarsete faili- ja printimisteenuste pakkumisele kogu tervikule ettevõte. See oli töötanud ilma ühegi tõrketa rohkem kui aastal ja ainus põhjus, miks me selle sulgesime, oli see, et see pidi füüsiliselt kolima teise hoonesse. Kui kolimine poleks olnud vajalik, oleks see võinud joosta sisse lülitatud seni, kuni vooluvõrk vastu pidas. Lihtsalt pole põhjust, miks selle jõudlust tuleks mõjutada seni, kuni keegi pistikut ei tõmba ega tormakalt laadi testimata tarkvara. Meie Linuxi ja Solarise serverite tööaeg (missioonikriitilised veebiserverid, andmebaasiserverid ja meiliserverid või lihtsalt põhilised faili- ja prindiserverid) mõõdetakse ka kuudes. Uptimes üle aasta ei ole Netware’i ja Unixi platvormide puhul haruldased ja üle kahe aasta pikkused tööajad pole samuti ennekuulmatud. Enamik operatsioonisüsteemi värskendusi tuuma asendamise puudumisel ei nõuta Unixi serveri taaskäivitamist, erinevalt Windowsist, mis ootab serveri täielikku taaskäivitamist iga kord, kui DLL mõnes allsüsteemis uuendatakse. Kuid vaadake ise: kontrollige Netcraft Uptime’i statistikat ja võrrelge Windowsi serverite tööaega Unixi serverite omadega. Arvud räägivad enda eest.

Microsoft lubab 99.999% saadavust Windows 2000-ga. See on vähe üle 5 minuti seisakuid aastas. Ausalt öeldes ei suuda ma uskuda, et see on realistlik sihtmärk Windowsile. Microsofti tooted pole kunagi isegi lähenenud sellised uptime arvud. Kuigi enamik suurenenud kättesaadavusest Windows 2000 tuleb pakkuda kolmanda osapoole klasterdamise ja liiasuse kaudu lahendused (midagi, mida läikivad reklaamid jätavad mainimata) see on väga ebatõenäoline, et vähem kui viis minutit seisakuid aastas kogu Windowsi klaster on praktiliselt teostatav.

Võib-olla veelgi tõsisem on asjaolu, et klastrite moodustamise puudumisel ei ole Piisav lahendus paljudele tarkvaratõrgetele, mis ohustavad tüüpilise Windowsi serveri kättesaadavust. Tüüpiline NT või 2000 server saab spontaanselt tekkivaid arvukad mööduvad probleeme. Need võivad võrgust erineda protsessid, mis tunduvad tervislikud, kuid ignoreerivad kõiki võrgutaotlusi, põgenevad serverirakendused, mis lukustavad kogu operatsioonisüsteemi. Tavaliselt ainus Sellistel juhtudel on lahenduseks toitetsükkel ja süsteemi taaskäivitamine. Mäletan peab seda tegema kolm korda nädalas tootmisserveris. Uskuge mind, see ei ole lõbus. Võib-olla on arusaadav, et mõned võrguadministraatorid tunnevad et parim viis Windowsi süsteemi kiirendamiseks on 9.81 meetrit sekundis Ruuduline.

Järgneb…

 

Exit mobile version