Názor ke zprávičce Samba team dostal dokumentaci od Microsoftu od Miloslav Ponkrác - Toto je poslední reakce, opravdu nemám čas odpovídat...

Toto je poslední reakce, opravdu nemám čas odpovídat na pololži.

"Na které věci je C/C++ nenahraditelné?"

Na veškeré low level věci, na věci, kde záleží na max. rychlosti, efektivitě a přitom co nejmenší zátěži systému, spotřeby cpu a paměti. Zde je (pokud nechcete do asm/strojáku) naprosto dominantní úloha C/C++ (spolu s dalšími kompilovanými jazyky) a zatím se nejeví, že by je něco dokázalo nahradit.

"Které *konkrétní* věci chybí Singularity, aby mohl být zván OS?"

Jen tak mezi námi, víte o tom, že Singularity - Váš typický projekt ukazující jak lze napsat "operační systém" v managed jazyku má jádro psané v Céčku a asm? Tady jasně vidíte, že Vaše managed jazyky nejsou až tak všemocné a bez toho Céčka se prostě neobejdou. Bez Céčka/Asm to opravdu nejde a manged jazyky nejsou dostatečně mocné, aby v nich bez pomoci C/C++/Asm šel napsat operační systém. Hardwarová abstrakční vrstva v Singularity je zase napsána v C++. Takže kde tu vidíte Vámi proklamovanou lež, že "lze napsat operační systém v managed jazyku", když to ještě nikdo nikdy nedokázal. Myslím si, že i jako demonstrace nanahraditelnosti Céčkových jazyků je Singularity velmi silných argumentem a tím přidávám další odpověď na první otázku, na které věci je C/C++ nenahraditelné.

"Opravdu si myslíte, že rychlost souborových operací souvisí s tím, jestli je shell napsaný v .NETu, nebo ne?"

Lžete a uhýbáte jako chameleón, nikdo nemluvil o shellu, ale Vy, pane LO, jste tu utopicky maloval teze o operačních systémech a driver psaných v managed jazyku. Teď se snažíte nenápadně přehodit výhybku, a myslíte si, že si nevšimnu té změny a už mluvíte o shellu. Takže odpovídám na Vaše utopie z předchozích debat - ano, rychlost souborových operací velmi závisí na tom, zda OS a drivery jsou psány v C/C++, nebo v .NETu.

"Možná vás to překvapí (protože o Singularity nic nevíte), ale managed kernel může být srovnatelně rychlý s dnešními kernely."

Ne, nemůže - a nikdo takový kernel nenapsal, ani Singularity nemá kernel psaný kompletně v managed jazyku. Na rozdíl od Vás ani v Microsoftu nejsou tak vypatlaní, aby si neuvědomili, že kernel v managed jazyku jednak 1) nejde vůbec napsat (občas i daleko mocnější C/C++ je nutné doplnit asm), 2) i kdyby to šlo, tak ztráta výkonu oproti kernelům v kompilovaných jazycích bude obrovská.

"Vše běží v jednom adresním prostoru, neexistuje overhead způsobený kernel mode transition, context switch je *výrazně* levnější, tedy je vše rychlejší."

Ne, není - protože takto udělaná architektura není s to vykonávat základní věci - není schopná spustit program ve strojáku, není schopná ničeho jiného, než spouštět byte kód .NETu a to ještě za výrazných omezení. Něco takto osekaného je v praxi naprosto k ničemu. A tato architektura Singularity je navíc velmi nebezpečná, protože při chybě v jakékoli části systému (kernelu, virtuální .NET mašině, nebo jinde) - je prostě v prdeli, slušněji to říct neumím. Bezpečnost a spolehlivost dostává v Singularity pěkně na zadek. Zatímco v normálním OS, když selže něco v programu, OS běží bez potíží spolehlivě dál, v Singularity taková chyba dostane systém do stavu, kdy prostě je celý systém v nestabilním stavu. A že každý systém, sebelépe navržený chyby má, na to spolehněte, jen architektura Singularity umožňuje chybě způsobit mnohonásobně větší škodu, než v jakémkoli běžném OS.

"To vyvažuje fakt, že managed code je o něco pomalejší, než nativní."

Nevyvažuje nic - managed code je pomalejší více, než výrazně, a dobře napsaný C/C++/Asm kernel bude rychlejší - a na rozdíl od Singularity bude schopen spouštět běžné rpogramy.

"Zkuste nastudovat něco teorie; pak třeba nebudete tvrdit, že na managed kernelu bude třeba na spuštění Notepadu 64-CPU cluster (když jsme u toho, Windows umí 64 CPU i v SMP/NUMA, a na reálné možnosti využívání stovek CPU u běžných strojů se soustředí MS Research, i v souvislosti se Singularity)."

Raději byste měl nastudovat něco Vy - došly Vám argumenty a už nevíte, jak byste to zakamufloval, co? Já jsem argumentoval přímo, nikam jsem Vás neodkazoval.

"Kernel zjevně lze napsat v managed jazyku (důkazů již existuje několik, Singularity není jediný takový projekt)."

Kdyby důkazy existovaly, už dávno byste je napsal - Singularity nemá kernel v managed jazyku, ale v C/C++/Asm - zjevně ani Singularity není důkazem, že to jde.

"Win32 aplikace se budou virtualizovat (což přijde již v příští verzi Windows), a efektivně běžet nad kernelem psaným v managed jazyce. Vývoj Win32 API byl prakticky zastaven"

Zajímavé je, že Win API se stále vyvíjí a stále roste počet funkcí API. Ba dokonce, že stále Win API je mocnější (v tom, co s ním lze vše udělat), než .NET. Jste bláhový, pokud si myslíte, že Win API nebude hlavní větví - bude a pořád. A to, jestli to bude běžet v systému tak, nebo onak je implmenetační detai a nezajímá mě to. Nové features ve Win API stále jsou a zatím jsem nenašel jedinou oblast, kde by Win API nemělo "featuru" a musel jsem sáhnout do .NETu. A tak to bude pořád, stačí jen selsky myslet. Ale pokud je pan LO velký zastánce .NETu a snaží se sám sebe i lživě silou mocí jakkoli přesvědčit, že .NET bude důležitější, než pravidelná stolice, je to jeho problém.

P.S.: Znovu připomínám, přečtěte si co mělo být ve Vista, a pokud je tam toho 1% z toho co MS hlásal, tak je to moc. Tudíž to co píšete o příští verzi Windows můžeme na základě historických zkušeností z firmou MS prohlásit směle za blbost.

"Selský rozum opravdu napoví, že Win32 nezmizí zítra, ale také napoví, že tu nebude věčně. Nebo byste v roce 1990 tvrdil, že Win16 tu bude na věky věků?"

Drobný detail: Já mluvím o Win API a to nezmizí. Dokud bude Windows, bude tu Win API, ať už v podobě Win32 API, nebo Win64 API (které je až na drobné detaily interfacem stejné). Selský rozum mi napoví, že Win API tu bude až do konce časů Windows a bude hrát naprosto klíčovou roli. Win API zmizí přesně v době, kdy skončí WIndows jako operační systém.

"Prioritizace I/O ve Vistě funguje bez problémů. Pokud jde o zpomalení sítě při přehrávání multimédií, tam jde o Multimedia Class Scheduler Service, který v případě přehrávání multimédií nechá NDIS omezit propustnost na 10K packetů za sekundu (což při standardních 1500 byte na packet znamená 15MB/sec). Těch 10K je možná málo, ale horší je, že díky bugu jde při dvou síťových kartách o 8K packetů/s, a při třech kartách 6K p/sec, což je efektivně 9MB/sec. Vaše "když přehráváte MP3 ve Windows, tak s gigabitovou síťovkou ve Vista přenášíte data po síti rychlostí kolem několika MB/sekundu" je buď FUD, nebo neznalost."

Vaše snaha vysvětlit jak je v pořádku, že na gigové síťovce ve Vista nejsem s to protlačit víc, než zlomeček hw schopností sítě je až dojemná. Být Billem Gatesem, tak Vás adoptuji a snad se do Vás i zamiluju, fakt. Jste kouzelnej.

"Ještě podotknu, že kde má Vista prioritizaci I/O, nemá Linux nic. Kde má Vista Multimedia Class Scheduler Service s nepříjemným bugem (byť technicky je zřejmě bug kdesi v NDISu), nemá Linux také nic, dokonce ani prioritizaci IRQ."

Jo jo, já jako zarputilý Windowsák (linuxáci už mě znají) mohu říci přes to všechno jediné - tam kde má Vista DRM a kurvení kvality multimédií, stejně tak jako klopné bity a další ptákoviny - nemá Linux nic - díky Bohu. Tam, kde je v Linuxu gigová síťovka, tak tady pofičí síť adekvátní rychlostí, má-li na to hw. Je hezké, že má Vista prioritizaci I/O, ale běžné, mnohokrát opakované benchmarky dokazují, že i XP jsou na stejném (i velmi silně výkonném počítači) hw výrazně rychlejší v práci se souborovým systémem, než Vista, a rychlejší při práci se sítí, než Vista. Tohle jsou bohužel chyby architektury Vist - podle mě nejhorší verze Windows, co kdy MS stvořil, a to počítám i ME. Pak jsou Vistě hezká technologická slovíčka co tu plivete totálně Vistě na nic, protože Linux a XP i bez toho je rychlejší.

"Nicméně nechápu, proč řešit rychlost Visty na 800MHz CPU s 512 MB RAM (na Aero 1GHz a 1GB RAM), když nejlevnější počítače okolo 8000 Kč bývají s procesory AMD Sempron 64 LE-1100 (který je daleko rychlejší, než PIII 800MHz), a 1GB RAM je i v této kategorii považován za minimum."

Protože silný a výkonný počítač si lidé pořizují pro aplikace, nikoli pro to, aby jim celý výkon sežrala Vista. Jinak notebooky s výkonem vhodným pro Vistu jsou někde jinde, a já na jednom takovém pracuji. I ta paměť do notebooku je dražší. A hlavně, Vista pak zbytečně zvyšuje spotřebu notebooku, k čemuž po mnoha testech je změřeno, že stejný notebook s Vistou vybije baterku za o 30% kratší dobu.

"Visty určitě nejsou dokonalé :), vždyť je to jen SW. Korporace nepřecházejí na nové verze OS nijak rychle, a nepřecházely nijak rychle ani na XP. V obchodech jsem nikdy nikde neviděl cedule o kterých píšete."

Já ty cedule viděl i na propagačních letácích firmy a v zahraničí jsou mnohem častější.

"Visty jsem okolo Vánoc vyzkoušel, a nyní je úspěšně používám."

U Vás se tomu nedivím, Vy byste přešel i na extrementy, kdyby je prodával MS.

"Nyní jsou Visty ve fázi, kdy je začíná kupovat masový trh, a tržbám se daří velmi dobře (přes současnou dostupnost Windows XP). Je roztomilé, jak každou novou verzi Windows provázejí stesky, že vlastně nic nového nepřinesla, že obsahuje zase spoustu nového SW který "poškodí trh", že je moc odlišná od minulé verze, že je moc HW náročná apod."

Nikoli, já sám, když jsem přešel na Windows 2000 byl jsem nadšen jako všichni kolem mě, co na Windows 2000 přešli z nižších verzí. Když jsem později přešel na Windows XP, byl jsem znovu nadšen a na stejném počítači byl systém rychlejší, než Windows 2000. V okolí jsem také viděl spíše nadšení nad XP. Ale kdokoli z mého okolí včetně mě samotného po vyzkoušení Vistu honem rychle zrušil a všichni přemýšlí jak to udělat, aby na tu Vistu přestupovat nemuseli. Toto je skutečnost z mého okolí, a poněkud objektivnější, než to co tu prezentujete.