Názory k článku
MS Windows Home Server poškozuje soubory

V grafu je severity.

hmm, hezké, nicméně graf jak z televize. Důležité, že graduje. Pokud se zeptáte každého studenta computer science, tak Vám řekne, že počet a význam chyb záleží převážně na komplexnosti daného kódu. Jako systémový inženýr Vám mohu potvrdit, že pokud systém dosáhne určité složitosti, pak náklady na jeho správu jsou vyšší než přínosy a systém je vhodné ukončit a začít znova. To, že v tomto stavu je možná Microsoft bych se ani nedivil. Z důvodu kompatibility si Microsoft nemůže dovolit pořádnou čistku a údržba několik tisíc knihoven může být neskutečně náročná. Před sedmi lety jsem tiše doufal, že ta čistka přijde v souvislosti s .NETem, ale zmýlil jsem se.

jde nám o zlepšení současného stavu, který je katastrofický

Tak hodnotíte windows. Pokud i Vy si tohle myslíte, tak asi Vysty nebudou žádný zázrak. Pokud za Vás sw dokáže, že v kódu není deadlock a že netrpí problémy s pamětí tak je to hezké, za předpokladu, že si kvůli tomu nebudu muset nový pořizovat comp, a že tento důkaz skončí o něco dřív než zkolabuje slunce. Jako problematické vidím ovšem to, že nic nedokáže zkontrolovat, zda-li sw dělá to, co skutečně dělat má. Microsoft se kdysi rozhodl preferovat thread model multiprocessingu. Díky tomu má každá exception podstatně horší důsledky než v process modelu. Proto řeší řadu věcí, které v jiných systémech řeší procesor. Ale to je problém Microsoftu a jeho strategie. Pokud by zvolil jiný model, patrně by vůbec nemusel řešit své problémy s kvalitou a v řadě věcí by se mohl spolehnout na hw. Co jsem nikdy nepochopil je fakt, že Microsoft opouští svůj COM model, který po deseti letech vyladil prakticky do dokonalosti .. viz spolehlivost a rychlost Microsoft Office, Microsoft Studia, a dalších aplikací. Rychlost COM a strukturovanost a bohatost .NET knihovny bych si nechal líbit. Uvidíme. Bohužel můj názor je ten, že v X desítkách redundantních knihoven, které tvoří to, čemu se říká Windows API lze jen obtížně udržet konzistenci a potřebnou strukturu. Bez tlusté čáry za minulostí je to problém a super u.i. v podstatě jen maskuje syndromy než aby řešila skutečný problém.

Thread model se používal na VMS, a používá se i na unixech (viz Oracle, Apache, a dnes v podstatě už cokoliv). Thready jsou totiž poněkud hubenější, než procesy, a výsledek tedy má daleko lepší scalability. Výjimka není problém - problém je případná memory corruption (které se ovšem nevyhnete ani v process modelu, protože nějak data mezi procesy sdílet musíte - typicky přes shared memory).

Záleží na kvalitě implementace procesů a Linux dokazuje, že procesy mohou být i rychlé. Problém není v odladěných aplikacích typu Apache, nebo SQL server, problémy jsou v podnikových (zákaznických) aplikacích, které píší žabaři, a tam je rozdíl ve výkonu minimální, neb stejně nevytěžují procesor a rozdíl ve spolehlivosti maximální neb pád threadu může sestřelit celý proces - celý server. Šance, že se Vám tak stane jsou v process modelu nižší, už jen proto, že přístup do shared memory je exkluzivní a používá se jen ve výjimečných případech, jinak se používá pipe a další bezpečné komunikační kanály. Navíc pokud už máte problém s corrupted shared memory, lze tento stav poměrně přesně identifikovat, a aplikaci slušně ukončit neb přesně víte, který segment paměti mohl být zasažen a který nikoliv. Důvod, proč se také používají thready je relativní pomalost vytváření nových procesů v NT, a pomalá shared memory. Tudíž aplikace, které chtějí nějak běžet na NT musí chca nechca tento model použít - není totiž na výběr. Nejsem proti managed jazykům, .NET jsem používal už před sedmi roky a vůči VBScriptu, Visual Basicu je to super vývojový nástroj a jestli jej budou umět programátoři použít, tak jen jedině dobře. Na druhou stranu znám natolik proces vývoje sw, že si dovolím pochybovat, že by se díky .NETu něco výrazněji změnilo, kromě hw. nároků. Zdroje chyb jsou v komplexnosti sw, v roztříštěnosti vývojových týmů, v architektuře, zejména v architektuře a pak ještě v lidech.

Kde je problém se server objekty? MS Word i Outlook je na serveru naprosto bez problémů. Stejně nakonec nepoužíváte front-end, ale jen pár jejich objektů. Nebo si představujete, že jde o monolitickou aplikaci? Když jsme u Outlooku, říká vám něco MAPI, CDO?

Samozřejmě, že mi to něco říká. Problémy jsou v zásadě dva: výkonnostní - nastartovat a incializovat objekty wordu, outlooku, excelu nějakou tu ms zabere a něco paměti a v případě většího zatížení šel server do kytek (nad 200 uživatelů, když se to sešlo), provozní - dost často se stávalo, že po security fixech takto postavené aplikace přestaly fungovat. Já se ani nedivím. Jde o to, že v pojetí Microsoftu je server zvláštní variantou desktopu, což je špatně, a dost lidí a firem na to naletělo a rozbilo si na tom nos. Relativně snadno se napsal server, s využitím objektů (jak jinak), nicméně velice bolestivě a nákladně se pak tento server ladil s tím, že se neustále objevovali nové a nové problémy. Což souviselo i s problémem COM platformy. Obtížná udržitelnost, v případě nabouraných registrů minimální šance na opravu, nepřehlednost, chybějící verzování, základní funkcionalita (přístup na síť, přístup k IO) byla v několika různých COM knihovnách přičemž některé se distribuovaly se systémem, některé z Office, některé z určitou jinou berličkou .. prostě neskutečný bordel .. celá devadesátá léta jednotlivé týmy Microsoftu živelně generovali stovky objektů (životnost knihovny byla ani ne 2 roky). Minimální - skoro nulová možnost skriptování (velice dobře znám vbscript). To je hlavní nevýhoda COMu. Java už byla navržena právě na základě zkušeností s COMem, kdy kromě jazyka (který není až tak podstatný) přišla s velice jednoduchým ale funkčním modelem uložení a distribuce objektů a hlavně dostatečně bohatou základní knihovnou. To, co přebral .NET

Java a .NET jsou částečně srovnatelné. Java byla především pěkný jazyk. Jde o managed prostředí, což také není špatné. Bohužel jako platforma je oproti .NETu velmi holá.

Těžko soudit. Tady neexistuje jasné kritérium. A použiji jiný příklad než Sun a Microsoft, abych neprovokoval. Typickým monstrem je CPAN, kde se najde prakticky všechno a v různé kvalitě (knihovna CPANu je bohatší než to, co je dostupné pro Javu a .NET dohromady). Což je pro programátora výhodné, ale tak trochu noční můrou pro admina a pro provozovatele vůbec. Je tam miliarda závislostí. Naopak bez závislostí (nebo s minimálními závislostmi) je kód postavený pouze na clib. Což třeba i pro mne je zpátečnictví. Nicméně musím přiznat, že je to kód, který bežel v roce 90, v roce 2000 a pravděpodobně poběží bezproblémově i za 20 let. Jde jen o to, co na co použít, tak aby vývoj byl efektivní a stabilní. Nedovolil bych si říci o Javě, že je velmi holá vůči .NETu, co vím, tak základ .NETu dost reflektuje Javu s přihlédnutím na specificky microsoft desktop věci, což v Javě ani být nemůže, jinak řada komerčních knihoven existuje jak pro javu, tak pro .NET, řada knihoven existuje pro Javu a neexistuje pro .NET a naopak. .NET má určitě větší drive, což je docela pochopitelné. Java má tuhle etapu už za sebou a už je stabilní, a používá se tam, kde se stabilita preferuje. Kdežto Microsoft .NET aktuálně extenzivně rozšiřuje a zkouší, co vše s .NETem lze.