MS Windows Home Server poškozuje soubory

ehm, muze mi nekdo rict, jak to souvisi s open source, linuxem a vubec zamerenim tohoto serveru?
nebo to ma jenom ukazat "jak je ten majkrosoft zly, kdyz vam poskozuje souboru" a "tohle by se vam na unixu/linuxu v zivote stat nemohlo"?

Nemluve o tom ze ani po nekolikanasobnem precteni vubec nechapu o co vlastne jde.

"jak je ten majkrosoft zly, kdyz vam poskozuje souboru" a "tohle by se vam na unixu/linuxu v zivote stat nemohlo"?

I kdyby ano tak co je na tom špatného?

napr. bych cekal, ze se spis dozvim, co umi linux dobreho, nez co umi windows spatneho...

To je ale docela smutné, že systém, který měl mimojiné zálohami apod. zajišťovat větší bezpečnost v domácí síti, data může takovým způsobem poškozovat. Takováto chyba se vůbec neměla dostat přes fázi testování.

Software bez chýb existuje, ale je ho veľmi málo, pretože jeho vývoj je šialene drahý. Napr. existuje soft s TCSEC A1 alebo EAL7 assurance level. To už vyžaduje formálnu verifikáciu. Formálna verifikácia ešte nemusí síce nutne znamenať, že SW je bez chýb, ale že vyhodnocované kritériá sú formálne dokázané (čo už má k bezchybnosti dosť blízko, závisí na kritériách).

Teoreticky by sa za SW bez chýb dal považovať kernel MINIXu 3, ale ten je navrhnutý ako minimalistický mikrokernel (kód má niečo cez 8500 riadkov). "Teoreticky" preto, že asi nikto formálne nedokazoval jeho správnosť, takže je možné, že nejaká chybička by sa tam našla.

AFAIK ani EAL7 nic nemusí zaručit - jde spíš o úpřímnou snahu (resp. použití metodologie, nikoli prokázání, že sama metodologie byla použita správně nade vší pochybnost) než o zaručený neprůstřelný výsledek. :-) A kromě toho, pokud vím, jediný EAL7 produkt je kombinace specializovaného HW a SW. Který (čistý) SW je certifikovaný na EAL7, že o něm nevím?

Samozrejme ze vec ktera bezi na PC ti nemuze zarucit vubec nic. PC je prilis slozite a chybove. A zadny SW ti nepobezi bezchybne na stroji, kteremu se cas od casu stane ze zapomene nejaky ten bit v pameti ...

No jasne, zavisi na zvolenych kriteriach, ale ak to chapem spravne, tak urcite vlastnosti kodu/platformy su formalne dokazane (co nezarucuje uplnu nepriestrelnost). Obecne ide o to, ze dokazat bezpecnost niecoho je takmer nemozne hlavne kvoli tomu, ze nie je obecne mozne popisat vsetky vlastnosti, ktore by to malo splnovat tak, aby ziadna vlastnost neostala nepopisana (v danej logike nerozhodnutelne problemy).

Napr. existuju protokoly, ktore su dokazatelne bezpecne via BAN/GNY logiku, lenze je ich mozne napadnut sposobmi, ake tie logiky (modely) nepripustaju (nepoznaju). Napr. side channels.

Faktem je, že dokázat neexistenci buffer overflow, neexistenci deadlocku apod. v C/C++ kódu je téměř vyloučeno. Na této úrovni jsou managed jazyky velikým přínosem, a řešením dnešních problémů. Pochopitelně problém side channels to automaticky neřeší, stejně jako řadu dalších věcí. Ale jedná se o postup na další level, který potřebujeme, pokud chceme mít bezpečné a spolehlivé IT. Dnes není schopen garantovat nikdo nic - mimo garance faktu, že každý kodér dělá pravidelně chyby.

Jak souvisi dokazovani neexistence deadlocku s tim, zda je jazyk managed nebo nemanaged? Chapu, ze managed pomaha proti buffer overflow, memory leakum a dalsim problemum podobneho typu, ale IMHO co se tyce dokazovani neexistence deadlocku tam me nenapada nic, cim by me to pomohlo a dovedu si dost dobre predstavit dokazovani neexistence deadlocku (ktera vicemene souvisi se struktrurou volani funkci, coz je pomerne high-level zalezitost) v kodu v C.

no to je jednoduche, detekci deadloku lze delat bud statickou analyzou, runtime analyzou (Sun studio) nebo na urovni VM (typicke pro managed jazyky)

1) nemluvilo se o detekci deadloku, ale o dokazovani nemoznosti deadlocku

2) runtime detekci lze delat i pro nemanaged jazyky, to je spis veci implementace zamykacich primitiv.

Co TeX?

Ale existuje:

public class Hello {
public static void main(String[] args) {
System.out.println("Hello World");
}
}


Vidis tam chybu? Ja ne ;). Preji vsem ctenarum rootu hezkeho silvestra...

Chyba tam samozrejme je:-) Jak tvrdi klasik "tento program trpi tou nejvetsi chybou - je na nic". Viz "Programatorske poklesky"

Ááá, ta mi tu někde leží... :-) To byly časy, a to byl SW ještě celkem jednoduchý. ;-)

musim uznat tu vec, ze ta zprava je fakt na houby, asi bych byl aspon konkretni at nam je ta zprava aspon k necemu, ale na druhou stranu jsi me pobavil ze chvalis MS ze varuje pred svoji chybou. Mas slusne naformatovanej mozek od MS. Pred chybou se nema varovat ale poslat na ni vyvojare a rychle ji opravit, aspon pokud jsem z tehle mizerne zpravy spravne pochopil ze jde o zasadni chybu.

Možná se vám to nezdá, ale od nahlášení chyby do jejího opravení, a otestování opravy, uplyne dost času. V mezičase je dobré, aby zákazníci věděli, že taková chyba existuje (zvláště pokud není exploitovatelná, a pokud může vést ke ztrátě dat).

Jestli se problém na home serveru vyskytuje při vysoké zátěži, nemusí to být kritický problém.

Vy si vážně myslíte, že když je Root o linuxu, že by tu měly být JEN zprávy o linuxu? Já beru Root jako server se zaměřením na linux a zrovna tato zpráva je pro mě důležitá. Až se mě někdo ze známých zeptá, jestli si domů pořídit jako domácí server linux (který nejspíš neznají) nebo windows (které znají), tak považuju za výhodu, že jim jsem schopný říct o obou systémech a upozornit je i na nevýhody systémů. Rozhodně pak budou mít o mě lepší mínění, než když jim řeknu na téma windows "Sorry, tak o windows nic nevím.". Teda alespoň já radši vypadám jako celkově informovaný, než jako zaslepený vyznavač jednoho systému, který neví o čem jsou ostatní systémy... :-)
Johny99

velmi spravne

:-D
Že bych se svým názorem někoho dotkl? ;-)
1. Souhlasím s tebou, oprava možná bude na světě. Ale o tom nebyla moje reakce. Ta byla o tom, že dávám Rootu k plusu, že je tu i tato zpráva. Radši toho vím víc, než míň.
2. Nikdy jsem nenapsal, že jsem odborník. IT je pouze můj koníček a zatím neplánuju, že by to bylo jinak. Mimochodem - domácí server jsem už se známýma párkrát diskutoval. Záleží mezi jakýma lidma se pohybuješ. Věř mi, že v mém okolí to není tak zvláštní věc. Když dostavíš barák, máš pracovní notebook, žena má svůj notebook, pak počítač pro dítě, případně multimediální centrum do obýváku, tak už i ten domácí server je celkem aktuální...

Johny99

Každý to bereme jinak, ale rozumím ti. Pokud někdo poradit chce, tak mu poradím, klidně i nainstaluju a nastavím, občas stáhnu aktualizace, případně něco dokonfiguruju. Je to můj koníček. Pokud se v tom ale chce vrtat, tak mu řeknu svůj názor a ať si tam dá co chce a spravuje si to sám...

mám jeden server pro BFU s linuxem v provozu. Je super, že krom výměn hardwaru na něj člověk nemusí šáhnout. Ale to jentak naokraj. Já osobně neznalost některých systémů považuji za výhodu, nikterak se s tím netajím. Mě totiž postupně přestalo bavit neustále něco opravovat. Samo, že za to většinou nemůže systém, ale uživatel, ale já prostě chci mít klid. Najde se jinej ochotnej trouba.

chlapci, dievcatka i anonymovia... uz ste offtopic. a je dost trapne, ze sa daktori neviete podpisat ani prezyvkou

autor to berie nejako vazne, ani na linux neni hned na vsetko zaplata ale to uz samozrejme neberie tak vazne ...

chce to klud :))

Nicmene chyby tohoto druhu bych na Linuxu cekal na nejake beta verzi, ne na necem, co se prodava lidem a chce se za to penize.

Ovsem. Prekvapuje mne ale, ze Microsoft nebyl schopen pri testovani schopen vytvorit dostatecne huste podminky, ktere by takovou chybu chytly. Co ti uzivatele doma asi delaji, ze to presahuje vsechno, co si profesionalni software house dokaze predstavit a pri testovani nasimulovat? Nerikam, kdyby se jednalo o nejaky super server, ktery musi zvladat netusene veci a situace. Ale home server pro rodinna PC? Jestli chyba nahodou nevznikla tim, jak Microsoft mrzacil Windows 2003, aby je preskolil na Home Server.

Vy neznate heslo Mrkvo$oftu: Uz se to zkompilovalo, muzeme zacit prodavat! ;)

Pokud jsem si všiml, tak MS musdel zátěžový test upravit, aby se problém projevil. Bohužel takovéhle věci se stávají, a budou stávat do té doby, než začneme psát OS v něčem jiném, než v C/C++. Na tom MS pracuje, ale bude to trvat.

Ještě jsem neslyšel o jazyku, který by opravoval bugy za programátory. To skutečně ještě chvíli potrvá.

Ale mohl jste slyšet o jazycích, kde řadu chyb není možné udělat. Například chyby v pointerové aritmerice, chyby přístupu za hranice pole, chyby přetečení bufferů, chyby přiřazení vs srovnání (if (a=4)) atd. A mohl jste slyšet i pojem model checking. Obojí je za dveřmi. Ale věřím, že z perspektivy vimu a command line to není vidět.

Ale ovšem, o těchto chybách jsem slyšel. K tomu ovšem nepotřebujete nějaké geniální nástroje. Stačí používat kontrolovat warnings v překladači, valgrind, lint a další. Rozdíl je v tom, že zatím co zmíněné nástroje jsou aktivované pouze v debug módu, tak v managed jazycích jsou aktivní nonstop (o něco efektivněji implementované, takže ztráta výkonu není 30% ale nižší. Jde o to, kde tyto nástroje použijete. V zákaznických aplikacích určitě nejsou na škodu. Ovšem se stejnými výsledky použijete jakékoliv skriptovací prostředí. Takže, co mi unika?

Takže podle vašeho názoru vlastně nemáme problém. No a já bych řekl, že problém máme. Podívejte se na graf počtu zjištěných zranitelnosté SW. http://blogs.technet.com/blogfiles/security/WindowsLiveWriter/MicrosoftSecurityIntelligenceReportH1200_70A9/sir3f6.png

Většina těchto problémů by nevznikla, kdyby byl SW psaný v lepším jazyce, než C/C++.

Warnings v překladači řeší minimum. Valgrind, lint a podobné nástroje mohou vyřešit jisté procento problémů, ale zdaleka neodhalí všechny problémy. Například Valgrind člověku řekne v run time "teď jsi zapsal do paměti někam úplně mimo". Bohužel ale úspěšný běh aplikace ve Valgrind nezaručuje, že kód nezapíše do paměti někam mimo po změně vstupních parametrů. Nehledě na to, že běžet cokoliv ve Valgrind je ohledně rychlosti i spotřeby paměti utrpení. A z hlediska model checkingu je C/C++ velmi nešťastné.

Jelikož v tom grafu nejsou druhy bugu, vlastně nic, tak nevím, co mi tím chcete říct. Proč jsou chyby, jak se jich vyvarovat a jak psát bezpečné aplikace se ví a řeší cca 20 let (možná třicet). V zázračnou zbraň věřil už Hitler, v zázrak věřil i Sun, když uváděl Javu. Možná v další zázrak věří i Microsoft. Nevím, nebudu předjímat. Zatím není důvod si nemyslet, že kód v managed jazycích bude bezchybný. Pouze budou jiné chyby. Jazyk a prostředí sice určuje chyby, nicméně jejich počet a závažnost je ovlivněna složitostí aplikace a vývojovým procesem. A je to pouze moje doměnka, Microsoft neumí řešit věci jednoduše. O to lépe je dokáže vychvalovat. Několik úžasných technologií od Microsoftu už jsem zažil.

V grafu je severity.

Samozřejmě chyby lze dělat i v managed jazycích. Ale jednak se díky jim lze hromadě chyb vyhnout(jde nám o zlepšení současného stavu, který je katastrofický), a potom lze provádět design checking, který dovede formálně zaručit parametry kódu. Ukažte mi, jak dnes vezmete 100k řádek kódu v C/C++, a formálně prokážete, že v nich nemůže nikdy nastat deadlock, případně že tento kód zaručeně netrpí nějakou formou memory corruption.

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.

MS si v současné době vede ohledně ohledně zranitelností poměrně dobře. Graf se týká všech (tedy nejen MS) produktů, data jsou z nvd.nist.gov. Nehodnotím Windows, ale stav průmyslu. Podívejse se třeba na secunia.org. Ubuntu Linux 6.10, tento rok 135 advisories. Sun Solaris 9, 57 advisories. Windows Vista, 17 advisories. Microsoft Office 2007, 5 advisories. OpenOffice.org 2.x, 5 advisories. Samozřerjmě jde pouze o bezpečnostní problémy - bugů bude daleko více.

Jaký je podle vás stav průmyslu? Všichni máme děravé operační systémy, děravé aplikace, prohlížeče. Na všech platformách. A SW je čím dál, tím víc. Aplikace vznikají každý den, a většina se jich do statistik nedostane jen proto, že nikdo nemá čas v nich hledat chyby. Pro vás je to možná problém Windows a MS Office, ale zjevně to tak není.

Nevím, jestli je dobrý nápad dnes říci "OK, tlustá čára, zítra všechen SW v celém IT průmyslu smažeme, a začneme znovu". Praxe učí, že je třeba něco typu business continuity. Jinými slovy vymyslet něco, co řeší současnou neutěšenou situaci průmyslu, to provozovat paralelně, a postupně na to přecházet. Ale možná to u vás děláte jinak ;)

Pokud dokážete, že v kódu není deadlock a že netrpí problémy s pamětí, tak to není hezké, ale naprosto skvělé. Tedy pokud mluvíme o kernelech operačních systémů, a podobných kategoriích. Tím samozřejmě práce nekončí, ale posouvá se na úplně jinou úroveň.

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).

COM má celkem špatný výkon při instancování objektů. .NET je v tomhle o dost lepší. Ale COM s námi bude ještě pár let.

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.

To jsem ještě chtěl říci: když vám chyba v SW sestřelí proces, přijdete o aktuální requesty procesem zpracovávané. Není to ale důvod, proč by měla být odstavena celá služba - nové requesty mohou být dále obsluhovány (proces se restartuje, případně je jiný již nastartovaný v záloze).

problém je jediný, v korektním ukončení serveru, resp. výkonného threadu. Např. tak aby nedošlo k poškození datových souborů.

A jakou že výhodu dostanu, když mi spadne proces, ve kterém jede jeden request, namísto procesu, kde jich jede více? Máte za to, že proces obsluhující jeden request nemůže zbořit datový soubor, nad kterým pracuje? Mám za to, že situace je velmi podobná.

Záleží na architektuře. V každém případě je proces, který řeší pouze jeden proces znatelně jednodušší, a snáze se kóduje obsluha chyb. Za chvíli mne budete přesvědčovat, že psaní multithread aplikací je jednodušší než multiprocess aplikací.

Psát výkonnější aplikace je vždy obtížnější. Ale jak jsem psal někde výše, objektové programování v tom pomáhá. Obsluhu chyb usnadňují výjimky.

Psát komplikovanější aplikace je obtížnější :). Obyčejně, co je jednoduché je i rychlé. Pokud se zvolí jednoduchá a praktická architektura, tak to není problém a že je to možné dokazují platformy jako Oberon, BeOS které jsou čistě navržené, a lze pro ně psát jednoduché a rychlé aplikace.

A vracíme se kruhem zpět: proces má vysokou režii, thread nižší režii, proto je multithreadová aplikace proti work processům výkonnější. Apache, Oracle a další aplikace pro unixy jsou také psané multithreadě.

Tvrdit, že co je jednoduché napsat, je i rychlé, je nesmysl. Nebo máte za to, že skript v bashi je rychlejší, než program v C?

Procesy jsou s dovolením vždy dražší, než thready. Samozřejmě, že lze mít o něco levnější procesy (ovšem ne o moc), a lze mít mizerně implementované thready (LinuxThreads byla opravdu příšernost). Shared memory je opět v principu vždy pomalejší, než přístup k paměti procesu z různých threadů. Odpověď na drahé procesy je na VMS, NT, Linuxu, Solarisu, i ve většině dalších systémů stejná - thready. Rozdíl je v tom, že NT implementovaly thready odjakživa, kdežto Linux implementoval LinuxThreads ;)

Implementace shared memory je sice v principu o něco pomalejší, nicméně v NT je soudobě o dost pomalejší než např. v Linuxu. Implementace vláken v Linuxu nebyla žádný nic s čím by se dalo chlubit. Také vlákna jsou v Unixu duplicitní vůči procesům s určitými výhodami a ještě většími nevýhodami a také původní implementace byla dávno zahozena. Napsat multithread aplikaci a hlavně ji odladit je totiž o dost komplikovanější záležitost než napsat multiprocess aplikaci, což uznávám, že do jisté míry řeší .NET nicméně ještě jsem neviděl žádný z MS serverů přepsaný do .NETu, takže zatím to není nijak žhavá záležitost.

Shared memory jsem ve Windows nikdy nepoužíval, jedná se v kontextu Windows o značně neobvyklý konstrukt.

Multithreaded aplikace se ve Windows psaly (před .NETem) v C++. Díky takovým těm věcem typu objekty, instance, encapsulation, exceptions apod je to praktičtější, než ANSI C.

Ehm, proč by přístup ke sdílené paměti měl být "z principu pomalejší"?

Když thread A a thread B přistupují ke společným datům, činí tak v rámci jednoho procesu (tedy levně). Pokud jde o dva procesy, probíhá mezi nimi kontext swqitch, včetně převálcování memory map při každém kontext switchi. To je, pochopitelně, drahé.

To co ušetříte na přepnutí kontextu tak v reálných aplikacích ztratíte na podstatně komplexnější synchronizaci vláken. Vyjma výpočetně náročných úloh - rendrování apod to nehraje roli, kdy navíc hrdlem je z 99% I/O a nikoliv procesor (podotýkám u rozumně napsaných aplikacích). Viděl jsem aplikace, které vytěžují procesor na 100%, ale tam se jednalo o amaterismus. Pro určování celkových nákladů nelze posuzovat thready nebo procesy bez ohledu na systém. UNIX je optimalizován na větší počet krátkodobě bežících procesů komunikujících skrz pipu, NT zas pro menší počet dlouhodobě běžících procesů a více vláken komunikujících skrz message. Jestli si pamatuji důvody: na unixech podstatně jednoduší bezpečnostní model a široké použití skriptů, na NT komplexnější bezpečnostní model a podpora třívrstvé architektury. Přes rozdílné architektury si myslím, že výkon optimalizovaných aplikací je podobný. Hrdlo aplikací je někde jinde a tím je I/O. Tyto důvody platily zhruba před 8-10 lety platí stále i když došlo k určité konvergenci. Linux dokáže rychle vytvářet nová vlákna a NT umí rychle vytvářet nové procesy. Chtěl jsem říci, že model business object, který Microsoft propagoval v 90 letech se nikdy neuplatnil, ale to by nebyla pravda. Java kontejnery jsou totéž v bledě modrém.

Já měl vždy za to, že synchronizační primitiva používaná pro synchronizaci procesů jsou daleko dražší, než v případě synchronizace mezi thready.

Krátce žijící proces je mimořádně nákladná sranda. Nakonec proto i unixy šly touto cestou: proces-per-request (short living), worker processes (long-living), multithreading. Windows jsou pochopitelně architektonicky výrazně novější, takže první ani druhý model je v nich spíše exotickou záležitostí.

Optimalizované aplikace dnes počítají na straně unixu s multithreadingem. Viz Oracle, Apache, a v podstatě cokoliv dalšího.

Nevím, jak business object, ale objektový model MS celkem funguje. Windows a všechny MS aplikace jsou dnes poskládané z objektů, což dává produktům neuvěřitelnou flexibilitu. V tom mají unixy samozřejmě také co dohánět.

Souhlasím, že často bývá limitem I/O, a nikoliv CPU. Často se to řeší zvětšením paměti (větši procento dat dostupné bez přístupu na disk), a efektivně tedy 64-bit architekturou. Dalším limitem je rychlost operační paměti, která se k dnešním CPU má asi jako šnek k formuli.

S moderním objektovým modelem MS mám docela dost zkušeností a nejsem sám. Fakt je ten, že paradigma které bylo v 90 letech módní byly tzv. remote objects, CORBA potažmo COM, které Microsoft implementoval a které se ve VB6 daly relativně snadno implementovat. Díky této technologii kdekdo dokázal napsat klient/server aplikaci aniž by cokoliv věděl o komunikaci, navázání komunikace, atd atd a ono to kupodivu i fungovalo, a dodnes funguje. Má to jen několik nevýhod: a) výkon .. jedná se o podstatně komplikovanější řešení, které je ovšem před programátorem transparentní, nicméně má to neuvěřitelné nároky na hw, b) robustnost .. klasické Unix servery služeb jsou v podstatě primitivní aplikace, kde se nemá co rozbít. V aplikacích s MS modelem se každý SP očekává s hrůzou v očích a i drobné security fixy mohou mít dost dalekosáhlý negativní dopad na funkčnost aplikace. Což je taky důvod, proč se postupně tato technologie opouští (aniž by se nemusela opouštět MS platforma) ve prospěch jiných ještě modernějších architektur. Nad COM se psali zvrhlosti. Díky uzavřenému DOC formátu server musel spouštět MS Word a generovat tak DOC, což bylo a je možné, ale má to zdrcující dopad na výkon. Microsoft totiž pozapomněl dodávat server objekty - takže se na server musel instalovat Office, maily se odesílaly prostřednictvím Outlooku a atd, prostě absolutní bastl.

Že by v UNIX byl měl co dohánět nebo aplikace pro něj psané? Zase se vznášíte na křídlech své fantazie. Implementaci objektů z 90 let by Microsoft co nejrychleji opustil neb má několik závažných problémů, které řeší .NET leč nemůže. Pokud jde o business object, pak existuje o něco robustnější a stabilnější řešení založené na Javě, které je naopak modernější než COM a bere v potaz existenci tenkých klientů, heterogenní prostředí, atd. .NET je s Javou EE srovnatelné. Není nijak výrazně inovativní - výhodou je Visual Studio, nevýhodou jméno Microsoft, které dost firem odrazuje už z principu. Pokud jde o ostatní OOP, tak pro GUI existuje DBUS, případně DCOM.

Neřekl bych, že COM má problémy s výkonem. Celkem drahé je vytváření instance objektu, což řeší .NET lépe. Robustnost bych také neviděl jako problém. Naprostá většina všeho, co dnes používáte pod Windows, je sestavená z hromady objektů, a funguje to velmi dobře. Problémy se vyskytují sporadicky, a vyskytovaly by se i při použití jiných technologií (protože IT je v principu problémů plné).

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?

Někteří lidé tu tvrdili, že nechápou, proč MS opouští něco tak geniálního, jako je COM. Jiní (jako by) tvrdí, že je to hnus, který by měl být opuštěn nejlépe včera. Bohužel jste neuvedl, jaké problémy COM údajně má. Těžko zmiňovat HW náročnost, a jedním dechem mluvit o Javě (která je synonymem pro požírač zdrojů).

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á.

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.

Když hovoříte o serveru, proč byste měl vytvářet nové instance Wordu, Excelu, Outlooku, a kdo ví čeho ještě? Prostě si vytvoříte jednu instanci, a tu necháte běžet. V ní provedete, co potřebujete, a necháte jí pak zase ležet do dalšího požadavku. Jestli jste si vytvářel instance objektů pro každý request, tak se nedivím vašim dost nepříjemným pocitům :). Není to zdaleka tak hrozné, jako startovat OpenOffice pro každý request, ale pro ilustraci nesmyslnosti daného postupu takové srovnání postačí.

"Nabourané registry" nejsou problémem. FS nebo DB se mohou "nabourat" úplně stejně. Na rozdíl od Registry ovšem nemáte automaticky zálohu, pořízenou při minulém startu systému. Navíc existuje zálohování (a je důrazně doporučeno jej provádět), a Registry lze obnovit ze zálohy (když na to přijde, klidně spolu se zbytkem systému).

COM byl určen k IPC a dynamickému vytváření objektů. Nebylo účelem mít například COM objekty pro operace nad stringy, práci se sockety a threading. Pro tento účel byly určeny klasické knihovny. Těžko tedy COM vytýkat "chudou základní knihovnu objektů" - nebylo to účelem.

Samozřejmě, že MS generoval obrovskou spoustu objektů. Velká většina věcí od MS totiž COM nějak využívá. Podíl MS na trhu celkem jasně říká, že to bylo moudré rozhodnutí.

Skriptování mi přijde v COM světě celkem slušné (vbscript). Mám tu skripty, které pracují s DB, managují cluster, povídají si s Wordem a Excelem, provádějí dotazy do Active Directory, zapisují do storage i schema MS Exchange. V MS Script Repository najdete tisíce příkladů: http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mfr=true

Skoro nulové možnosti skriptování si představuji výrazně odlišně. Samozřejmě by to mohlo být i lepší. Unixy ovšem jako alternativu dodnes nabízejí pouze "spusť aplikaci, parsuj textový výstup". MS má dnes PowerShell, což je zřejmě první pokrok v oblasti skriptování za mnoho let.

Kód postavený na libc je pěkná myšlenka. Bohužel produktivita je pak nulová, a kód je plný bugů (už proto, že jde o C). Dnes stavíme výrazně komplexnější celky, než v šedesátých letech, a stavíme jich každý den veliké spousty. Potřebujeme proto frameworky, které umí daleko více, daleko lépe se používají, a jsou daleko méně náchylné na chyby.

Ano, Sun také zkoušel, co vše může s Javou dělat. Bohužel díky jisté strategické idiocii se toho moc nepovedlo. Embedded zařízení na Javě nikdy neběžela (jakkoliv to bylo první zamýšlené použití Javy). Nebo jste někdy viděl zařízení s formwarem psaným v Javě? Já ani jedno. JavaStations leží v muzeu neúspěchů Sunu, applety se z inetu téměř ztratily, a ani desktopové aplikace v Javě nikdy nebyly zvláště úspěšné. Dnes je Java chudou (ale jedinou realistickou) alternativou .NETu pro unixy. .NET je dnes primárním API Windows, přináší odpovědi na dnešní problémy stability a bezpečnosti (resp. bugy spolené s užíváním jazyka C/C++), a do budoucna v .NETu bude zřejmě i kernel.

Paradoxem je, že Sun mohl být ve velmi dobré pozici, kdyby netrval na Čisté Javě (ve chvíli, kdy neměl ani editor dialogů, Java neuměla tisknout, a přizpůsobení bylo nutně potřeba). Sun hrál poker s vysokými sázkami, a nedal to.

Citovat z příruček umíte. Zajímalo by mne, jestli jste sám někdy něco napsal, administroval a používal. Podle posledního příspěvku a posledního na který budu ve spojitosti s Vaší identitou reagovat si to nemyslím a opět mne to usvědčuje v názoru, že jste pouhý blb, který umí pouze papouškovat a o sw inženýrství, a o samotném vývoji ví pouze tolik, kolik se mu naservíruje v propagačním letácích určitých firem.

VBScript byl a bude pomalý a očesaný jazyk s velice špatnou chybovou diagnostikou. Tak jej Microsoft navrhl, aby náhodou nekonkuroval plnému Visual Basicu. Kromě jiného např. neumí používat klasické knihovny, ale pouze COM knihovny a to ještě specificky rozšířené pro VBScript. Těchto COM knihoven po čase vzniklo několik desítek (mluvím o těch významných), bohužel bez jakékoliv koncepce. Tudíž např. odeslání mailu bylo možné udělat v knihovnách A, B, C. V knihovnách A a B bylo možné uložit přílohu, v knihovně C naopak správně nastavit diakritiku odesílaného mailu atd. Tyto problémy se ve světě Unixu paradoxně vůbec nevyskytovaly, neb při vzniku se mu do vínku dostalo jak silného jádra, tak několik dalších pozoruhodných konceptů (silný shell, možnost skriptování aplikací), které Microsoft v devadesátých letech zavrhl jako přežitek, aby se k nim po patnácti letech vývoje vrátil. Ano Jádro NT je relativně moderní a kvalitní a koncepční. Což se ovšem nedá říci o zbytku systému (Zrovna shell byl nejkřiklavějším příkladem. Porovnejte bash a bat skripty). Ten vznikal nekoncepčně až do vzniku .NETu. Sláva Bohu, že konečně je k dispozici slušné skriptovací prostředí jako je PowerShell. Jak dlouho to trvalo a proč to trvalo tak dlouho firmě, která netrpí nedostatkem zdrojů a ani lidí? Jelikož je shell NT, aplikace, způsob konfigurace a správy navržen tak jak navržen je, tak skriptovací prostředí musí být neskutečně silné, protože nikdo nepředpokládal, že by kdy někdo skriptoval NT systém. NT se měly administrovat pouze v GUI, nevzpomínáte si? Dokonce se ani nepočítalo se vzdálenou správou. I tu si Microsoft musel koupit a licencovat. Nebyli schopni vlastní implementace. Taková blbost by nikoho v Unixu nenapadla. Částečně i proto, že o dvě dekády dříve, když Unixy vznikaly skutečně nebylo zdrojů nazbyt a muselo se šetřit. Díky tomu lze skriptovat podstatně jednodušeji a efektivněji než v NT a pouhé parsování bohatě stačí (přestože se jedná o koncept tak prastarý).

Blbem mě bude nazývat člověk, který si pouští velkou část Wordu pro každý request, aby ho po zpracování requestu zase ukončil (což svědčí o zásadním nepochopení principů)? A proč si asi představujete, že vám budu něco psát, když předesíláte, že neodpovíte? Mám za to, že vás něco podráždilo, i když mi není jasné, co to bylo.

VBScript je pomalý, a je očesaný - by design. Možnost skriptování aplikací mě dost rozesmála; říká vám něco VBA? To je ta věc, kterou používá třeba MS Office a AutoCad (v obojím lze naskriptovat v podstatě cokoliv).

Bat skripty jsou věcí MS-DOSu, nikoliv Windows (to ale asi víte). Interpreter cmd.exe a jeho .cmd soubory nejsou tak bohaté, jako bash, ale jsou daleko bohatší, než si většina adminů unixů myslí. Zkuste se podívat na if /? a for /?. Pokud nevíte, co dělá řekněme
for /D %i in (*) do @echo %~fi
tak toho o Windows shellu moc nevíte.

Windows se administrovaly a administrují primárně z GUI. Pochopitelně lze většinu věcí udělat pomocí command line utilit, nebo pomocí VBS, jenom to není primární interface.

Vzdálená správa NT se prováděla lokálním spuštěním utilit (server manager, user manager, event viewer atd). Utility uměly pracovat se vzdáleným strojem. Mimo toho tu byly náplasti typu PC Anywhere. Souhlasím, že to nebyla velká sláva. Mimochodem nástroje typu smit (děsivý GUI wrapper pro command line utilities) se, pokud si pamatuji, ke vzdálenému stroji připojit neumí.

MS implementace RDP je odlišná od toho, co nabízí Citrix (mimo jiné odlišný protokol). MS by nejspíš implementaci zvládl (když zvládnete napsat jeden z nejlepších kernelů na trhu, proč ne remote GUI), ale proč to dělat, když můžete know how levněji koupit? Abyste mohl říci "bylo to dražší, trvalo to déle, ale napsali jsme to od podlahy doma"? Výsledkem každopádně je RDP, které je oproti X11 výrazně použitelnější. Celkem malý klient, rychlé a na zdroje nenáročné připojení. Zkuste si X11 a RDP přes GPRS nebo dial-up. Přes RDP se bude dát pracovat (byť to není úplně skvělé), X11 bude naprosto nepoužitelné, s odezvou na klávesy ve vteřinách i déle. Jak X11 šetří zdroji, to je mi opravdu záhadou, protože něco tak rozežraného a technologicky příšerného jinde nevidět.

To, že se unixy skriptují jednoduše, je pouze dojem. Zdá se vám to tak proto, že znáte syntaxi hromady příkazů a stovek utilit, umíte regexpy atd. U některých lidí to jde tak daleko, že ovládání vi označují za "intuitivní". Pouhé parsování znamená problémy s lokalizací, problémy s rozšiřitelností, problémy s mezerami v názvech souborů, a nemožnost pracovat s čímkoliv mimo textu.

Za perličku bych označil fakt, že unixy pro spoustu věcí pro změnu vůbec nemají API. Chcete výpis běžících procesů? Spusťte si ps; nic jiného, co by běželo na více unixech, zřejmě nenajdete. Chcete založit lokálního uživatele? Spusťte si shell script, nebo máte smůlu. Pro ilustraci ve Windows máte mimo jiné API pro Performance Counters, kde si můžete nastavit, které hodnoty chcete sledovat, a například si navázat callback na přehročení mezní hodnoty. Holt Windows nejsou libc.

Nevim, kde jste vycetl, ze jsem ja pouzival word, tak jak o tom pisete. Pak bych asi nenapsal, ze spusteni trva milisekundy, ale pouzil bych jine jednotky. Tak jako tak to na serveru nemelo, co delat neb to pri vyssi zatezi nebylo stabilni.

Kdyby bylo VBA rozumne k dispozici, tak bych tu neplakal nad VBScriptem a v zivote bych VBScript nepouzil. Mimochodem s VBA pracuji od petkove verze Excelu, a nevim kolik lidi v republice pouziva VBA tak dlouho jako ja. Jenomze, VBA bylo trochu jinak licencovano nez ostatni Microsoft produkty, a to tak, ze bylo neskutecne drahe a v podstate pro firmu podnikajici v CR nedostupne, resp. pouzitelne pouze pro produkty typu AutoCad a spol s licenci nad 100K. A to jsem pracoval ve firme, ktera mela a ma s Microsoftem nadstandardni vztahy. VBA bylo neco jako rodinne stribro, a take tak si jej Microsoft cenil. Toliko k VBA. Rec byla ovsem o VBScriptu. Jak to souvisi s VBA? To jako, ze Microsoft dokaze delat kvalitni sw. Ja netvrdim, ze nedokaze. Tvrdim, ze zamerne dodava crypled verze, ktere bohuzel neoznacuje podle reality, ale za prevratnou technologii, novinu, ktera zmeni svet, a full verze doda teprve tehdy, kdyz s podobnym krokem prijde konkurence. O tom, jestli je administrace unixu slozita nebo nikoliv se nema cenu bavit s nekym, kdo to v zivote evidentne nezkousel, a kdo opakuje marketingove zvasty aniz by dokazal trochu premyslet.

Různé aplikace jsou holt různé stabilní. WordPerfect for Windows pravidleně padal po pár otevřeních a uzavřeních souboru.

Na MSDN je pár příkladů, jak do aplikace integrovat skriptování. Obecně vzato můžete použít jakýkoliv jazyk - klidně PERL, jestli ho máte rád. VBScript je k dispozici zdarma, to je jeho výhoda. Samozřejmě i k VBS existuje IDE, debugger atd.

Administraci unixů jsem měl v popisu práce dost dlouho na to, abych věděl, o čem je ;)

MS dokáže dělat kvalitní SW, a velká většina MS SW je kvalitní (tradičně cca od třetí verze). Mnohdy nejde o nejlepší produkty v relevantním oboru, ale typicky jsou z těch lepších. Síla je v jejich integraci, v synergickém efektu. Ve spolupráci produktů, podobném ovládání a administraci. Samozřejmě i MS má na účtu řadu neúspěchů. Za všechny rozhraní Bob (ze kterého zbyla sponka v MSO a Search Assistant, a to zřejmě proto že na projektu dělala Gatesova žena).

LO, je celkom vtipné, koľko terminologických argumentov máš vždy poruke k obrane M$.

Má to len jedinú chybu: realita je iná. Napriek všetkým teoretickým dôvodom, Vista je pomalšia než ktorýkoľvek iný systém. Napriek Tvojim dôvodom, Oracle beží rýchlejšie na Linuxe.

Vista je hlavně pokročilejší, než jakýkoliv jiný systém (což těžko nějak popírat). Jestli běží Oracle rychleji na Linuxu, to nevím. Zato vím, že MS SQL Server běží rychleji na Windows, a že je to engine s nejrychleji rostoucím tržním podílem.

Pristup do sdilene pameti mezi thready je stejne levny jako pristup do sdilene pameti mezi procesy. Kontext switch mezi procesy bude samozrejme drazsi nez mezi thready, ale to nijak nesouvisi s pristupem ke sdilene pameti - tam mohou oba pristupovat aniz by to obvykle vynucovalo nejaky kontext switch.

Ano, souhlas. Myslel jsem to dobře, napsal nevhodně (vysvětleno níže).

Já jsem hovořil o přístupu ke sdílené paměti, ne o nějakých kontext switchích. Sdílená paměť není nic jiného, než že nějaké stránky adresového prostoru procesu jsou mapované na tytéž stránky fyzické paměti jako odpovídající stránky v jiném procesu. Jediná režie je doba zápisu do RAM, stejně jako v případě jiného vlákna téže aplikace. Ergo je tento přístup stejně levný.

Z toho, co jsme si psali s ostatními, je zřejmé, že hovoříme každý o něčem jiném. Samozřejmě vlastní zápis či čtení sdílené paměti jsou stejně rychlé, jako v případě threadů. Jenže zde máme content switche, a synchronizaci, které jsou náročnější.

Pokud je mi známo, na rychlou meziprocesovou synchronizaci se pořád ještě dají na Linuxu použít futexy. Není to posixová věc, ale Windows taky nejsou zrovna Posix. ;-)

Poněkud nešťastné je, že futexy jsou věcí Linuxu, a pouze Linuxu (a ještě pouze v jádru 2.6). Je tedy krajně nepravděpodobné, že by je použil vývojář aplikace, která bude použita i na dalších unixech. Navíc drahé context switche zůstávají (dokud zůstanou work processy).

Je zjevné, že už i autoři unixových aplikací vědí, kam směřuje vývoj, když šli do multithreadingu.

"Poněkud nešťastné je, že futexy jsou věcí Linuxu, a pouze Linuxu (a ještě pouze v jádru 2.6)."

Pokud se Vám to nelíbí, můžete ještě použít FreeBSD. ;-)

Navíc drahé context switche zůstávají (dokud zůstanou work processy). Je zjevné, že už i autoři unixových aplikací vědí, kam směřuje vývoj, když šli do multithreadingu.

...přece k mikrojádrům a odděleným procesům, to ví každý. :-D

Ale žádné za dveřmi, tyhle věci fungují už třicet let. :-)

To by mě fakt zajímalo. Máme za těch 30 let za sebou model checking alespoň jednoho kernelu? A je to Linux, BSD, HP-UX, Solaris, AIX, nebo Windows NT? :)

Mluvil jsem o "Například chyby v pointerové aritmerice, chyby přístupu za hranice pole, chyby přetečení bufferů, chyby přiřazení vs srovnání (if (a=4)) atd.", v tomhle byly napsány v průmyslu používané operační systémy. :-) Bohužel byly i na svou dobu trošku dražší a zabily je unixové stanice a PCčko s MS DOSem, hanba Billovi! :-D

Viz napr. "Model Checking An Entire Linux Distribution for Security Violations", http://portal.acm.org/citation.cfm?id=1106807&dl=ACM&coll=ACM

BTW ako "najpriatelskejsi" k model checkingu bude asi MINIX 3.

In Linux we never ever assume a driver is working simply because the hardware vendor tested it. A decade of real world experience PROVES precisely the opposite -- getting code out into the world early and often repeatedly turned up problems not seen in hardware vendor's testing.
-- Jeff Garzik, vývojář Linuxového jádra

Kdyby použili celý kod Win200x server a nesnažili se jej zkryplit, chyba by tam nebyla.

Nojo,
jenže to by nebyl MS,kdyby nechtěl svůj produkt maximálně osekat a zkryplit ;-)

Myslim, ze posledni radek "Zdroj: Slashdot" mluvi za vse:) To je skoro jak cist blesk...co jsem se docetl, tak se ta chyba muze stat v extremnim pripade, takze asi tolik ....

Neřekl bych že extrémní případ...
ale máte pravdu že měl autor uvést spíše odkaz na microsoftí vyjádření:
http://support.microsoft.com/kb/946676/en-us?spid=12624

A tam se píše:
may become corrupted

což mi připomělo starou dobrou věc z Windows 98...
After 49.7 days ... computer MAY stop responding..
http://support.microsoft.com/kb/216641/en-us

pro nepamětníky, sory za nepřesnost výkladu.. díky implementaci čítače uptimu u windows 98 po nějakém čase došlo k přetečení čítače a tím k modré obrazovce takže to may mělo význam "může se stát s pravděpodobností téměř 100%" :D

Nebo to mělo význam druhý... a to, že to may znamená, že ještě předtím má 49 dnů aby zamrzl z jiného důvodu :D

Když už ten článek MS KB linkujete, tak si tam přečtěte následující:
These issues occur in the following scenario:
- A home server is under an extreme load. For example, lots of files are being copied to the home server.
- At the same time, a user is editing files that are already saved in a shared folder on the home server.
- The program that the user is using to edit these files is one of the programs that are listed in this article.

Děkuji za pobídku, jsem rád že upozorňujete na fakt že microsoft je schopen tímto scénářem reprodukovat chybu... tím pádem bude schopen vydat bugfix a bude po problému.

Jestli to myslíte jako námitku k tomu, že jsem se vyjádřil: "Neřekl bych že extrémní případ..." pak pořád si myslím, že bych neřekl, že je to extrémní případ. Ale simulaci situace vedoucí k té chybě a následně ověřovat jestli se jedná o extrémní případ nebudu, takže omluvte že jsem si dovolil napsat svůj osobní nepodložený názor.

Cili reseni je proste - bud muzete kopirovat soubory na server, nebo muzete editovat jine soubory, nebo muzete pouzivet nektere MS programy, nikoli vsak vsechno naraz ....

Mami, muzu si zkopirovat tady ty soubory?
Nikoli zlaticko, tatinek zrovna pouziva Vistu ...

moderni viceuzivatelsky server v cele sve krase ...

S Vistou to nemá nic společného, ale jinak v podstatě souhlas. Ovšem podobné problémy nejsou výjimečné. Například RFS měl problémy toho typu, že jeden thread úspěšně založil soubor, druhý thread k němu přistoupil, a dostal chybu, s tím že soubor neexistuje. Pochopitelně mailový server z takového bugu má velikou radost ;)

MS Windows Home Server poškozuje soubory

:-)…Tak jak to teda je? Ničí soubory Linux nebo Windows?

Windows jsou opět pozadu, Linux ničí rovnou celé disky. :-)

Linux disky neničí, pouze špatné nastavení některých hodnot => disk si ničí uživatel, který nastavuje to, co nemá (v defaultní konfiguraci ubuntu se vám toto nestane). Stejně tak si může nastavit časté parkování hlaviček u windows. Chyba je spíš u výrobců těch disků, že disk dovolí, aby se s ním takto zacházelo. Že Linux ničí notebookové disky je obyčejné Hulánovské FUD.

http://disposed.cz/wordpress/linux/radek-hulan-linux-fyzicky-nici-notebookove-disky/

Místní blázen českého internetu Hulán by nám to vysvětlil. :-))