Odpověď na názor

[98] Sdílené knihovny nejsou samopopisné. CORBA, KParts, Bonobo a UNO samozřejmě existují, ale jsou v podstatě novinkou, a distra Linuxu rozhodně nejsou poskládaná z komponent. Když například ve Windows kliknete na soubor pravou myší, tak se v Registry vyhledají handlery pro context menu daného typu souborů. Ty handlery jsou COM objekty, a kdykoliv můžete přidat další. Obdobně pokud zobrazíte vlastnosti nějakého souboru, máte v Registry ID komponenty, která se zavolá pro zobrazení property sheetu. Srovnejte to s tím, jak se píše SW na Linuxu. Sdílené knihovny vám komponenty opravdu nenahradí.

[102] Dodává se vaše distro s preemptivním kernelem? Nedávno jsem tu v diskuzi dával linky na vyjádření vývojářů jádra, kteří doporučovali používat preemptivní konfiguraci jen pro testování, a linky na problémy s výkonem preemptivního kernelu. Co jsem se naposledy díval, tak Ubuntu, Mandriva, Debian, Fedora a další distra jela "klasický" kernel s preempcí na pár vybraných místech.

Ano, článek je z roku 2003. A co se od té doby změnilo? Nenapsal jste totiž ani malý kousek informace, zřejmě prostě nevíte. Zato já vím, že makro local_irq_disable, které zakáže veškerá přerušení, je ve zdrojáku Linux kernelu 2.6.16-rc3 použito na 413 místech. Možná mi vysvětlíte, co se od roku 2003 změnilo - pokud to ovšem víte. Pokud nevíte, tak vám nezbývá, než si číst jadené noviny bez znalosti kontextu ;)
http://www.promethos.org/lxr/http/ident?i=local_irq_disable

[103] Co je CIM?

[104] Jak jsem psal výše, sdílené knihovny nejsou komponenty. A když se podíváte na modularitu Windows (kterou ovšem většina uživatelů unixů nikdy neuvidí, protože nevidí pod kapotu Windows), tak budete vědět, že komponentový model je dobrý nápad. Nakonec proto se ho snaží linuxové desktopy přebírat.

Jinými slovy Linux nemá mechanismy, které by umožnily zabránit podtečení bufferů při přehrávání multimédií. Jenže to není proto, že by byl optimalizovaný na server. Je to proto, že zvolená architektura obsluhy přerušení je velmi snadná k implementaci, ale přináší mizerné výsledky. To, že nelze napsat podporu multimédií odpovídajícím způsobem, je pak jen důsledek. Když jsme u toho, desktop bych nepovažoval za "speciální případ", minimálně ne u desktopového produktu, jakým mnohá distra Linuxu jsou.

Na pracovní stanici si těžko 100 uživatelů rezervuje přenosové pásmo, protože u ní typicky sedí v dané chvíli jeden uživatel. Technicky samozřejmě není problém, aby si 100 procesů rezervovalo přenosové pásmo (na stanici i na serveru). Nemám před sebou detaily implementace (jsou na webu MS), ale API umožňuje rezervaci pásma zamítnout. Dále IO scheduler přiděluje maximálně nějaké procento celkového přenosového pásma, aby se nakonec dostalo na všechny. Takže z těch 100 požadavků na rezervaci bude uspokojeno tolik, kolik lze uspokojit, a zbytek požadavků bude zamítnut.

O preemptivitě klidně mluvte. Pokud se vám stroj při práci seká, tak je to typicky způsobené tím, že čeká na disk. Pokud totiž stránka paměti není zavedena v RAM, dost těžko se provádí ;). Pak pomůže zvětšit RAM (2-8GB RAM dnes není problém), nebo zrychlit přístup k disku. Doporučuji třeba RAID z Raptorů, nebo 15k RPM SCSI disky. Nebo si prostě počkat - to je nejlevnější.

Ohledně toho testu se síťovkou vás asi nepotěším. Síťovka prostě dostane paket, tak vyvolá interrupt. Po dobu jeho zpracování jsou všechny interrupty zakázané (local_irq_di­sable). Navíc dojde k obsluze přerušení až tehdy, když je možné provést preempci kernelu (což je u Linuxu na dlouhé lokte díky absenci preemptivního kernelu). A čím horší latency, tím větší pravděpodobnost, že propásnete nějaký interupt (zvukovka zachrčí, síťovka ztratí pakket atp).
Srovnejte s Windows, kde je kernel preemptivní, takže k obsluze přerušení dojde dříve. Navíc při obsluze interruptu nižší priority je možné tuto obsluhu přerušit kvůli interruptu vyšší priority. To se ale týká jen ISR, kde se provádí minimum nutné ke zpracování přerušení (mimo jiné vám ISR dává možnost flow control). Potom se požadavek předá do fronty DPC, která umí priority, a při zpracování fronty se v pořadí priorit a času došlých požadavků volá příslušná DPC (popis celého mechanismus je nad rámec příspěvku, vyhledejte si něco o ISR a DPC). K tomu je zde konfigurovatelný mechanismus, který v případě přehrávání multimédií by default omezuje počet interruptů od síťové karty na 10k za sekundu. Ve srovnání s Linuxem jde o velmi pokročilou architekturu; její psaní ale asi nebylo tak triviální, jako v případě Linuxu.

O preemptivitě Linux kernelu můžete klidně mluvit vlastními slovy, pokud taková máte. Zatím jediným "argumentem" na tohle téma bylo, že mnou linkovaný článek je z roku 2003, následovaný linkem na seriál jaderných novin. Jistě uznáte, že to je argument k ničemu. Naopak viz třetí odstavec mého příspěvku. Vy máte znát vnitřnosti Linuxu, ne já :)

Pokud jsem si všiml, tak nový kernel pro své distro sice stáhnout můžete, ale typicky upgrade path někde končí, a vy musíte upgradovat distro úplně stejně, jako je třeba upgradovat v případě Windows. S tím rozdílem, že musíte upgradovat daleko častěji, protože release cycle je doslova zběsilý (což vede k mizernému otestování dister, za všechny viz tuším Mandriva 2007 kde z médií ani nebylo možná provést instalaci).
Pokud je systém "rozežraný a pomalejší", zkuste instalovat méně servisů (nebo je nespouštět všechny hned při startu), a instalovat méně doplňků, které se integrují se shellem. Ono když si nainstalujete 50 aplikací, které si zaregistrují handlery prováděné při každém zobrazení kontextového menu v Exloreru, tak systém moc nezrychlíte :). A samozřejmě defragmentace. Ale nejsme tu proto, abych vás učil zacházet s Windows, že.

V .NETu je psané například WPF. Pro vaši informaci, .NET není jen C# a managed environment. Je možné psát i v C++/CLI (Common Language Infrastructure), aka ECMA-372. Samozřejmě kernel je psaný v C/C++, a zřejmě tak ještě pár let zůstane. Ovšem takové VMS bylo psané v assembleru (VAX Macro), a API bylo určené pro Common Language Environment - opravdu nebylo třeba pro něj psát v assembleru. A nakonec pro Linux se píš například v Qt, což je high level C++, a kernel je psaný v C. To, že unixy mají jediné API (POSIX) definované v C, je věc unixů. Jinak souhlas, že C++ je nadále důležité i ve Windows; změny nejdou ze dne na den.
Volání mezi managed a unmanaged kódem není v případě .NETu nutné. Můžete totiž z .NETu používat unmanaged datové typy.

Linux se vyvíjí dynamicky, už asi 17 let. Kupodivu NT začali psát v roce 1989, a v roce 1993 je uvedli s řadou features, které unixy nemají po 30+ letech. Ja na unixech (aka na POSIXu) v kódu získám seznam běžících procesů (mluvíme o API, ne o command line utilitě)? Jak přidám lokálního uživatele, získám seznam služeb (aka daemonů), zastavím vybrané služby, změním kontext ve kterém služby nabíhají? Jak získám seznam síťových interfaců a zakážu nějaký interface? Nemluvě o věcech typu grafika, tisk a správa barev, multimédia, a další oblasti, které POSIX "pro jistotu" také neřeší, a které se řeší mnoha různými způsoby. Je hrozné, že UNIX byl jako platforma rozbit do mnoha větví, které sdílejí jen POSIX. POSIX je totiž nesmírně zaostalý za současným stavem technologií.