Názor k článku
SCO: „Linux je kopie UNIXu“ od Lael Ophir - Neumím si představit takovou botu v plánování, že...

Neumím si představit takovou botu v plánování, že mezi major verzemi zjistíte zásadní problém v modelu driverů, který vás bude velmi trápit, a nepůjde vyřešit. A se změnou specifikace driverů mezi hlavními verzemi se (byť v omezeném rozsahu) počítá.

Proč by závazné API pro drivery mělo být nevýhodou? Máte závazné API (byť jen na úrovni zdrojáku) pro libc, tak proč ne pro drivery? Co je špatného na tom, když driver grafické karty není vázaný na jediný produkt (správný X11 server)?

Pokud jsem si všiml, LSB se chystá řešit multimédia. Uvidíme. Upozorňuji ale, že Video for Windows je 16 let stará záležitost. Je tedy co dohánet. A s kodeky na Windows je to jak jsem psal. Problémy dělají většinou soubory typu DIVX a XDIV. Bohužel pro ně existuje řada encoderů i dekoderů, a výsledky jsou někdy divné. Jistě vzpomínáte na DIVX3.11alpha a problémy s mrznutím obrazu. Já třeba vzpomínám na DIVX5, který při dekódování DIVX4 špatně demultiplexoval, takže nešel zvuk (u některých videí). Dnes se dekomprese DIVX a XVID provádí často pomocí open source kodeků, kde každá verze opraví jeden problém, a dva nové zanese. Proto používám formát WMV, a jsem šťastný.

Prioritizace na Linuxu? Povídejte. Já si všiml jen ionice. Jenže 1) prioritizace IRQ se pořád nekoná, a bez ní je cokoliv dalšího o ničem; 2) ionice funguje per process, a nikoliv per handle; 3) ionice nežeší rezervaci přenosového pásma. Takže jde o takovou velmi slabou záplatu.

Správně psaný SW je stavěný modulárně a hierarchicky. Chápu, že Linux je psaný od začátku pro x86, a když se portovalo na jinou platformu, tak se prostě použil ifdef. NT naproti tomu byly psány od začátku jako multiplatformní. Takže to (celkem typicky) dopadlo tak, že Linux má špagety s ifdefy, a NT mají HA.
Ohledně výkonu, tam bych se nebál. Ona existuje řada praktických postupů, jak optimalizovat. Třeba odlišný mechanismus syscallu (int 2e vs sysenter) na Windows nevyžaduje ani rekompilaci, ani odlišné binárky. Je to designu a o úsilí.

Povídejte, kde blábolím naprosté nesmysly ohledně reentrance Linux kernelu? Co vaše distro? Jede s "plnou" preempcí, s "dobrovolnou", nebo bez? Testy, ve kterých preemptivní kerel vycházel výkonově výrazně hůře, lze triviálně najít Googlem. Andrea Arcangeli (Linux kernel developer) prohlásil: "keep preempt turned off always, it's useless". A podle Andrewa Mortona je preemptivní kernel dobrý právě tak k vychytávání locking bugů.

Fork není oproti vytvoření threadu levná operace. Navíc je tam značná spotřeba paměti (forkovaný proces může překopat celý svůj adresní prostor, a vy tu paměť musíte mít rezervovanou - viz lhaní o paměti a oom killer). A samozřejmě režie switche mezi procesy je daleko vyšší, než switche mezi thready (protože thready sdílejí adresní prostor, stačí výměna registrů - značná úspora). Windows mají procesy výrazně dražší než thready, a o trochu dražší než procesy na unixech (třeba na Solarisu). Ovšem switch mezi thready i synchronizační primitiva jsou na NT rychlejší, než cokoliv kdekoliv jinde (výjimkou je Singularity se svými SIP). Nakonec si nelze nevšimnout, že po Solarisu se časem i Linux naučit thready. Pravda, měl je umět od začátku, a mohl si odpustit příšernost zvanou Linux threads.
Clone je zajímavý, ale bohužel Linux-specific.

Já na unixech zpravidla s GUI nevystačím, a musím většinu správy provádět na command line. GUI nemá nástroje, a kde je má, tam jsou mnohdy tak úděsné, že ještě rád uteču na command line.