SCO: „Linux je kopie UNIXu“

Netykáme si.

Vyloučit přítomnost kódů jiného unixu v Linux kernelu, to by šlo opravdu špatně. Mimo jiné je předpokladem mít zdrojáky všech těch ostatních unixů. Realistickým závěrem studie nejvýše může být, že takový kód nenašla. Vyloučit a nenajít jsou dvě celkem odlišné věci.

Nejmenovaná korporace celkem dobře doložila, že Linux obsahuje cizí kód. Pokud máte k těm slidům výhrady, sem s nimi. Jak říkám, výhrady stylu "od tam je, ale na tom není nic špatného" nejsou relevantní, protože to se nesnažíme hodnotit. Jde o fakta.

Nevím jak Vista ale předchozí WinNT systémy obsahovaly něco jako Posix subsystém. Takže pak podle vaší argumentace jsou i tyto systémy opisem UNIXu. Nebo jen něco nechápu?

Windows mají subsystémy, takže mohou nabízet různé API. Do tuším NT 4.0 se Windows dodávaly s Win32, OS/2, VDM a POSIX subsystémem. Každý subsystém je postavený nad kernelem (resp. nad executive), a používá jeho funkce. POSIX subsystem slouží ve Windows jako ocmpatibility layer pro běh (či migraci) unixových aplikací. Architektura Windows je výrazně odlišná od architektury unixů.

IMHO VDM nebyl subsystém. Do WinNT4 si byly subsystémy víceméně rovnocenné, pak se Win32 subsystém stal dominantním a ostatní závislé na něm. Jak to je ve Vista netuším - pokud máte zajímavý odkaz, tak si jej s chutí přečtu.

No ono je to trochu jinak. Část Win32 je implementovaná v kernel mode, například GDI32. Z původní knihovny GDI32.dll zůstal stub, který provádí syscall (není to čistý stub - provádí nějaké cachování apod). Dnes GDI spousta práce odpadla, protože s WPF se zobrazování dost změnilo.

Když jsme u toho, NT subsystémy jsou moc pěkný design, ale obchodní význam mají malý (což se zpočátku samozřejmě netušilo). OS/2 subsystem byl důležitý možná první rok, a to ještě jen marketingově (aplikací pro OS/2 bylo pět a půl). POSIX subsystem zákazníci také moc nepoužívají. WoW byl pravda využíván hodně, stejně jako VDM, ale to je spíše o zpětné kompatibilitě (z hlediska uživatele).

Ano GDI32 se přestěhovalo do kernelu (protože rychlost) ale obecně to byla pěkná prasárna a konec toho, že se dal WinNT považovat za jakž takž mikrokernel.
Ale mluvím spíš o věcek jako správa session a tak dále kde se ostatní subsystémy pověsily na Win32.

Subsystémy: OS/2 je mrtvý, Posix natolik ořezaný že je z praktického hlediska nepoužizelný. WoW (alespoň 16bit na 32bit Windows) nebyl nikdy subsystém ale program pro Win32. IMHO totéž platí i pro VDM ale zde si nejsem stopro jistý.

Proč je přestěhování GDI do kernelu prasárna? Mělo to dost dobrý výsledek: snížil se počet syscalls, a GDI se tím stalo daleko rychlejším. Nevedlo to ani ke snížení stability (NT byly vždy rock stable, a verze 4.0 nebyl výjimkou).
Samozřejmě Win32 je jediný dlouhodobě přeživší subsystem, takže se dá pochopit, že jeho role je "privilegovaná".

OS/2 subsystém je mrtvý, protože umřela OS/2. Marketingově byla důležitá kompatibilita s OS/2, a ta existovala. Spíše překvapí, že OS/2 subsystem odstranil MS až v XP/Win2003. POSIX byl v prvních verzích dost očesaný (součástí instalace nebyly utility, pokud si vzpomínám; ty byly zvlášť), a v XP/Win20003 opět odstraněn. Dnešní SFU bych viděl jako vyhovující. Resp. jsem si vyzkoušel bash, pár utilit, a nainstaloval Gimp :)

Prasárna - prostě se mi stěhování hromady kódu do kernelu nelíbí. BTW dohledejte si, jak byl implementován Terminal Server - to je ultra mega humus.
Ten počet syscalls jsem nějak nepochopil - naopak přibyla další syscalls table. Tuším že na sysinternals to pěkně popisovali.

Aneb přesun GDI do kernelu a víceméně odepsání subsystémů je zprasení architektury která byla zpočátku velice elegantní.

Ten počet syscalls je ve skutečnosti četnost syscalls. Kernel mode transition je drahá věc, to oba víme. Pokud máte GDI v user mode, tak ho zavoláte jedním voláním (NakresliKřivku), a na druhé straně vypadne dlouhá řada syscallů. Když máte GDI v kernel mode (NT 4.0), tak provedete jedno volání typu NakresliKřivku, to vyústí v jeden syscall, a zbytek volání probíhá v kernel mode. V praxi je to trochu složitější, protože NT 3.51 i NT 4.0 používaly řadu optimalizací, ale rychlost vyšla silně ve prospěch GDI v kernel mode. Více zde:
http://www.microsoft.com/technet/archive/ntwrkstn/reskit/archi.mspx?mfr=true

Nevím, jak byl implementován Citrix, ale implementace RDP mi přijde celkem dobrá. Prostě máte vyjma grafické karty, tiskáren a plotterů další grafické zařízení, kterým je driver Remote Desktop Protocolu. Pěkné je třeba to, že při otevírání RDP session vám klient řekne, jaké má capabilities (barevné obdélníky, cache bitmap, rendrování fontů; neoficiální klient pro DOS umí jen rastrovat bitmapy), a GDI potom high level volání překládá do primitiv, která klient umí (podobně jako u grafických karet, tiskáren apod). Rozšíření Windows NT o session management bylo sice trochu drsnější, ale jednou to přijít muselo. Naopak vlastní RDP protokol je zvolený celkem šťastně. Netrpí na round-trip hell jako X11, umožňuje kompresi, odpojení a opětovné připojení k session, šifrování, a protože podporuje kanály, bylo lehké přidat podporu vzdáleného clipboardu (objektového, nikoliv textového - zkuste si), vzdálený zvuk, smart cards na přihlašování apod. Navíc je protokol rozšiřitelný na aplikační úrovni, což potěší vývojáře (i když - kdo tohle kdy použil).

Windows byly od začátku modifikovaným mikrokernelem. Na rozdíl od čistého mikrokernelového designu běžely servery vždy v kernel mode (NT executive). GDI jen drží tenhle trend. A důvod je pořád stejný: drahý kernel mode transition.

Syscals - ano zrychlilo to systém. Ale stejně se mi to nelíbí :-)

Terminal server - tady nemluvím o RDP ale o tom, že původně byla kernel memory namapována ve všech procesech stejně ale s příchodem TS se místo toho aby se přidal handle dané session a příslušně opravilo GDI tak se začala přehazovat mapování kernel mode paměti.

BTW hlavní problém není přepnutí do kernel mode ale přepnutí na jiný proces - to je MNOHEM dražší.

Ono nebylo účelem, aby se vám nové řešení líbilo, ale aby přineslo výhody :)

Máte k tomu RDP a změně mapování paměti nějaký link? Celkem bych se na to podíval.

Jak jsem jiz nekolikrat psal, jako demagog jste opravdu brilantni.
Ted uz nejde lhat o tom, ze Linux je jakysi ukradeny cizi operacni system, jak se s oblibou blabolilo pred par lety, tak aspon trochu zasmrdime tak, ze "to asi neni nelegalni, ale ze prece jenom...." :-))
Chapu. Vas zamestnavatel nalil tenkrat do SCO penize vicemene zbytecne a to opravdu na.ere.

Tak počkat. Jaké zasmradíme? Je Linux opisem starších unixů jedno volání po druhém, nebo ne? Asi se shodneme, že ano. Obsahuje (resp. obsahoval) od jiných unixů? Linkovaný materiál to prokazuje. Co chcete potom "zasmradit"? Fakta jsou fakta. Můžete fakta rozporovat, nebo se můžeme dohadovat o jejich interpretaci. Jak vidím, někteří lidé volí "třetí cestu", a před fakty jednoduše zavírají oči.

Nakonec jak jsem psal o pár příspěvků dříve:
V tomto světle je zábavné pozorovat lidi, kteří o problematice nevědí vůbec nic, ale na základě pár let administrace Linuxu je jim nad slunce jasnější, že Linux neobsahuje ani řádek z jiného unixu. O co méně je takové přesvědčení racionální, o to je silnější.
http://www.root.cz/zpravicky/sco-linux-je-kopie-unixu/201313/

Je Linux opisem starších unixů jedno volání po druhém, nebo ne? Asi se shodneme, že ano.

Neshodneme, protože není. Linux implementuje jednak POSIX, což není "starší Unix", ale norma, a jednak má některá vlastní API.

Obsahuje (resp. obsahoval) od jiných unixů? Linkovaný materiál to prokazuje.

Linkovaný materiál prokazuje, že Linux obsahoval malou část legálního kódu odjinud, který byl posléze minimálně zčásti, pokud ne zcela nahrazen, a to přinejmenším jednou z toho důvodu, že jeho kvalita byla shledána nevalnou.

POSIX je de facto souhrn společných API profi UNIXů. A když jsme u toho, Linux není POSIX compliant (na rozdíl třeba od Windows se SFU, nebo od MacOS).
No a dále Linus sám tvrdil, že Linux psal podle man pages SunOS. Prostě opisoval jednu funkci po druhé. Tedy ne že by činilo zvláštního rozdílu, jestli opisoval z man pages, nebo ze specifikace POSIX. O re-implementaci/opis/kopii/obšleh/plagiát (vyberte si citové zabarvení dle svých preferencí - já bych řekl opis) samozřejmě jde.
http://www.linuxjournal.com/article/3417

Ano, linkovaný materiál prokazuje, že Linux obsahuje (obsahoval) kód jiných unixů. Dále prokazuje, že autoři kódu měli přístup ke kódu komerčních unixů (to jsou některé ty komentáře). Jestli je to legální, to ať rozhodne soud. Podle mě tohle SCO nevyhraje, protože naprostá většina toho kódu byla uvolněna pod BSD licencí.

No a nakonec ten link tvrdí, že kód, kterým firma IBM přispívá do Linuxu, je odvozený od kódu BSD. Tam jsem na výsledek soudní pře sám zvědavý, protože by to zřejmě mělo vliv i na povinnost uvolňovat kód kernelových modulů pod GPL.

A když jsme u toho, Linux není POSIX compliant (na rozdíl třeba od Windows se SFU, nebo od MacOS).

To není podstatné, zda je nebo není POSIX compliant. I pokud tvůrci Linuxu nechtějí podstoupit certifikační proces, stále mají právo ho implementovat, aby ti, kteří štempl na bedně nevyžadují, nemuseli aplikace portovat.

O re-implementaci/opis/kopii/obšleh/plagiát (vyberte si citové zabarvení dle svých preferencí - já bych řekl opis) samozřejmě jde.

Ano, asi tak ve stejné míře, jako když si teď postavím šroubárnu a začnu k cizím šroubkům vyrábět matičky s metrickými závity. ;-) Také by to bylo vskutku opovrženíhodné. ;-)

Ano, linkovaný materiál prokazuje, že Linux obsahuje (obsahoval) kód jiných unixů. Dále prokazuje, že autoři kódu měli přístup ke kódu komerčních unixů (to jsou některé ty komentáře). Jestli je to legální, to ať rozhodne soud. Podle mě tohle SCO nevyhraje, protože naprostá většina toho kódu byla uvolněna pod BSD licencí.

Legální to určitě je v případě, že kód poskytli jeho autoři. SCO do toho v první řadě nemá co mluvit, pokud není držitelem autorských práv k poskytnutému kódu. Soud jednak rozhodl, že SCO tímto držitelem není dokonce ani v případě starého, původního kódu Systemu V, a druhak, i kdyby SCO mělo s dalšími dodavateli Systemu V dohodu, že jimi nově vyvinutý kód dříve dodávaný pouze v implementacích Systemu V (třeba JFS v AIXu) nebudou uvolňovat pod jinou licencí, tito dodavatelé tak přesto mohou učinit, aniž by to ohrozilo Linux. Jsou totiž držiteli autorských práv a mohou si s ním dělat, co chtějí, a pokud to poruší nějaké jejich obchodní dohody, Linux bude z hlediska autorských práv tímto nedotčen a bude to problém pouze těch firem. A to, zda kód poskytli jehou autoři nebo ne, to bych ponechal na soudu. Každopádně objem takového sporného kódu v Linuxu je tak mizivý, že jeho ztráta by se nikterak závažně neprojevila.

Linux a POSIX není jen o razítku. Musíte také projít certifikaci, a tou Linux neprojde.
http://www.opengroup.org/personal/ajosey/tr28-07-2003.txt
http://www.opengroup.org/personal/ajosey/tr28-07-2003.txt

Osobně bych viděl jistý rozdíl mezi výrobou metrických šroubů, a opsáním existujícího systému jedno volání po druhém. Z morálního hlediska bychy s tím neměl problém. Spíš je otázka, jestli má ztrácet čas implementací něčeho, co je už v té době zastaralé (klasické unixy), a co nemá příliš perspektiv. Problém vidím, když čtenáři root.cz tvrdí, že Linux není kopie UNIXu.

Pokud jde o kód odvozený od kódu SCO (třeba JFS), není to tak jednoduché. Na prvním místě spor vede SCO s IBM, protože to byla firma IBM, která ten kód uvolnila. Ale pokud se jmenujete Red Hat, a sporný kód dále prodáváte, můžete si také pěkně naběhnout, pokud ten kód není legální.

Já osobně spor SCO se zbytkem světa pozoruji jako nezúčastněný divák. Pokud by se SCO podařilo uhájit svoji pravdu, bylo by to zřejmě pár drobných z kapsy IBM, a trocha ztráty pro Linux. Pokud to SCO definitivně projede, má Linux dále hromadu starostí sám se sebou. Například uživatelský interface, administraci, vývojové nástroje, šíři platformy, dokumentaci, patenty atd. Navíc osobně věřím, že unixy jsou dávno přežité, a ani free unix pro x86 nepomůže. Protože to píšu na root.cz, je mi jasné, že s předcházející větou bude souhlasit dost malé procento čtenářů.

Nemám slov, tohle nadšení pro Microsoft člověk nemůže neobdivovat. :-) Kéž bychom i my měli takové vytrvalé fanatiky! ;-)

Na okraj, jak to celé souvisí s MS?

Jak? Asi nejpravděpodobnější Vaší odpovědí na otázku "Co tedy navrhujete místo Unixu?" Předpokládám, že to nebude BeOS, Hurd ani Minix 3. ;-)

Já měl za to, že diskuze nebyla o tom, čím bychom nahradili unixy. Ale když jste to otevřel, čím byste je nahradil vy?

Jejich evolučními potomky? Jako to udělal Apple?

Otazka, cim by Lael Ophir nahradil UNIXy, ma jednoduchou odpoved: UNIXy zatim neni cim nahradit.

A to v jaké konkrétní aplikaci, prosím? Podnikový trh, který kdysi patřil téměř výhradně profi unixům, patří dnes téměř výhradně Microsoftu a jeho partnerům. Kdo tak miloval vi a bash, že neopustil profi unixy ve prospěch Windows, přechází dnes na Linux. Profi unixů je čím dál méně, a jejich výrobci čelí vleklé krizi.

Na pracovních stanicích unixy dávno umřely (SGI o tom ví své), na běžných serverech také skoro vymřely, a na velkých serverech na ně Windows úspěšně útočí. Jsou tu reference na dostupnost 99.999+ od UNISYSu, multi-TB DB, a kritických aplikací dávno běží na Windows velké procento.

Což mi připomíná, proč se ve zprávičkách neobjeví, že Sun měl velmi mizerné finanční výsledky, a propouští tisíce lidí? Proč nikdo nanapíše, že podle řady analytiků jde o důsledek koupě MySQL za přemrštěnou cenu? Nehodí se to na root.cz?

Jo, povím. Ale já sem zprávičky nepíšu. Mám s tím začít? Otázka je míněna vážně.

Sun reported a net loss of $34m (£17m) compared with a profit of $67m in the same period of 2007. Sun announced plans to cut between 1,500 and 2,500 jobs. The job cuts represent up to 7.5% of Sun's total workforce of 33,500.
http://news.bbc.co.uk/2/hi/business/7379324.stm

Hmmm pri tej hypotekarnej krize co je(bola) v USA ma vecsina firiem problem... moze to byt sposobene aj tym...

To je samozřejmě otázka. Faktem ale je, že Sun prodělával, pak se zvedl těsně nad nulu, a teď prodělává zase.

Predstava high availability serveru, ktery se musi trikrat tydne rebootovat, me desi. Internet, fungujici diky Windows, mi pripada natolik nerealny, ze bych se odhlasil, protoze Internet 2 hodiny za tyden me nezajima. Krome toho, Windows, zejmena ve sve posledni, krasne verzi Vista, udela i z rychleho stroje pomalou hajtru, o jejimz nasazeni, jako vykoneho serveru, bych pochyboval. Navic, co kdyby mi zcernala obrazovka, protoze MS ma chybu ve WGA? No, snad bych to za tech 30 dnu nejak vytelefonoval. (Kdo mi zaplati cas a telefonni poplatky?)

To, ze Windows nekde nejak utoci, neznamena, ze UNIX neni nenahraditelny. Microsoft ma porad hodne co dohanet. Ostatne, co byste chtel? Neuspeli ani na poli hernich konzoli, kde ma Microsoft dlouhou tradici (Windows 9x/Me na PC).

Tady nejde o padani, Windows dnes uz padaji o dost mene, nez byvalo zvykem. Ale kvuli kdejakemu update se musi rebootovat cele Windows, a to dost casto. Tak mate moznost neupdatovat a nerebootovat, coz je znacne riskantni. Nebo updatovat a rebootovat. Dalsi rebooty si muze treba vyzadat antivirus pri updatu engine.... High availability je v kopru.

No pokud provozujete nejakou aplikaci ktera okna moc nevytezuje,tak to jeste jde,ale zkuste si provozovat win server, ktery je dlouhodobe vytizen treba na 98%,opravdy vytizeny proxy server nebo treba router na gigabitu.Stabilita serveru, ktere vytezuji na par % je rekl bych prakticky stejna.

WOW na prvom mieste je Win2003 naklikol som adresu a co nevidim jeden obrazok a jeden riadok textu... uff to je narocna aplikacia...

Ano, HA swerver, který je třeba 3x týdně rebootovat, je nepoužitelný. Nicméně já psal o referencích na 99.999+ dostupnost, a to bez clusteringu. Zjevně se tedy nerebootuje 3x týdně.

Internet fungující díky Windows je celkem běžná věc. Velké procento webů běží na Windows/IIS.

Vista na rychlém stroji běhá rychle, tedy alespoň na tom mém velmi rychle. Jen nechápu, proč byste jí chtěl nasazovat jako server. Je to desktopový OS, nikoliv serverový. Když vám zčerná obrozovka díky chybě WGA (nestává se to), jste ve stejné situaci, jako když se podělá cokoliv jiného (třeba FS, nebo konfigurace).

Vzhledem k tomu, že spousta firem jede bez jediného unixového serveru, nemyslím, že by unix byl nenahraditelný. V čem *konkrétně* byl měl být nenahraditelný?

S těmi konzolemi je to pochopitelně mimo. MS s XBoxem 360 uspěl velmi slušně, a má vynikající výsledky ohledně průměrného počtu zakoupených her ke konzoli. Windows 9x/ME neměly nic společného s konzolami.

To jsou zajímavé reference, obzvlášť ve světle nedávné analýzy Gartneru, která tvrdí, že W2k3 měly v minulém roce několikrát horší downtime než Linux (ten náš kolem jedné hodiny ročně, jestli se nepletu), a ten měl o něco horší downtime než AIX a o něco lepší než Solaris... Několik hodin downtimu ročně v průměru na jeden stroj s W2k3 by ve světle toho, že některé stroje mají dostupnost 99,999+, znamenalo buď to, že jiné stroje jsou na tom mnohem hůř, nebo možná jen to, že není dost schopných adminů Windows a ti unixoví jsou prostě lepší... ;-)

Internet diky windows neznamena cast webu na IIS. Internet je mnohem slozitejsi: routery, proxy, DNS... a Windows botnety. Recept na rychlou likvidaci Internetu: Nahradte top level DNS servery Windows clusterem. To je i odpovedi na to, proc je UNIX nenahraditelny. Ale ono by stacilo zacit routovat prez Windows, joj, to by byl hukot. To by to trvalo, nez by se skrzto vsechno to porno a spam propasirovalo.

Vista na rychlem stroji beha mozna rychle, ale kdyz se tam daji Windows XP, to je teprve ta spravna pila.

XSkatule je mensi uspech, nez se vam zda. V lepsim pripade na tom Microsoft neprodela, ale konkurenci to na paty moc neslape. Mozna se to jednou zmeni ci se to zlepsuje, ale zatim to tak je.

Windows 9x/Me premenily PC na padavou herni konzoli.

Samozřejmě routing, proxy i DNS lze provozovat za pomoci Windows. Ovšem routery bývají typicky "HW", a jedou třeba na Internetwork Operating System (Cisco). Proxy na Windows jede velká spousta firem, a DNS jede na Windows snad každá firma. V případě ISP jsou ale velmi důležité náklady (používá se nejlevnější HW, mnohdy desktopový, nezálohuje se, lidé jsou ti nejlevnější na trhu atd). Linux a FreeBSD jsou zdarma, což je pro ISP to nejdůležitější.

Mám na stroji dual boot 64-bit Visty a 32-bit XP. Ty XP končí někde na 3.5GB RAM, Vista používá celých 8GB. Vista má memory managament, který je lépe optimalizovaný pro velkou spoustu paměti (lépe jí využije). Navíc má řadu nových technologií. Že by byla Vista pomalejší, to jsem si nevšiml. Zato jsem si toho všiml, že beta verze Visty byly pomalejší, než finální verze.

Pokud MS neprodělá na XBoxu, bude na tom pořád lépe, než Sony. Nakonec být dvojkou na trhu (a jedničkou mezi next gen konzolemi) už s druhou verzí produktu, a to na trhu kde je pěkně narváno, to není špatný úspěch.

Windows 9x byly možná padavou herní konzolí pro vás. Pro zbytek světa to byl OS, na kterém jela naprostá většina pracovních desktopů (a to přesto, že se MS snažil od roku 1996 tlačit na desktop NT - trh má velkou setrvačnost). Pokud postavíte tyto dvě+ věci proti sobě, je zjevné, že jste s padavou herní konzolí (již tradičně) mimo.

Netykáme si. O tom, proč jsou unixy zastaralé, jsem tu psal mnohokrát. Asi bych našel lepší kousky, ale nemám teď čas hledat, takže jen namátkou:

Ve Windows máme drivery grafických karet, tiskáren, plotterů a grafických terminálů, které mají jeden model, dají se šířit binárně (tedy bez kompilace na uživatelově PC), a mají stabilní API. O převod vysokoúrovňových volání typu "nakresli křivku" nebo "napiš text" se stará GDI, které to překládá driverům do primitiv, kterým konkrétní driver rozumí. Dovede se u toho postarat barevné profily a správu barev. Co má Linux? Pomalou a zaostalou příšernost jménem X11, a device tiskárny. Proč? Protože je zaostalý. Jiný příklad? Komprese audia a videa. Windows mají komponentový systém, který můžete doplnit o libovolné kompresory a dekompresory. Ty pak využívají všechny aplikace, které pracují s multimédii (až na sociální výjimky). Linux takový systém nemá. Proč? Protože je zaostalý. Windows mají prioritizaci I/O operací, kterou navíc používá celý systém (přehrávač multimédií, swapování atd). Linux nemá. Proč? Hádejte. Windows mají modifikovaný mikrokernel, tedy modulární kernel, který má vrstvu Hardware Abstraction Layer. Linux má hromadu ifdefů. Proč? Hádejte. Windows mají preemptivní a reentrantní kernel, kdežto u Linuxu se preempce považuje za zběsilý experiment, nehodný produktivního nasazení. Proč? Hádejte.

Příšerností unixů je také systém terminálů. Kdo proboha vymyslel systém stovek nekompatibilních sad sekvencí? OK, mohlo se to stát, ale proč to dávno není zrušené a nahrazené něčím lepším (viz Win32 API pro konzoli)? Když chci napsat text ve žluté barvě, tak nejprve lokalizuji soubor s popisem terminálu, ten parsuji, najdu sekvenci, a vypíšu jí na stdout. Příšernost. Nakonec celý tenhle kolotoč řada aplikací ignoruje, a používá vlastní sady sekvencí (viz třeba Midnight Commander). To bylo z hlediska autora aplikace. Z hlediska uživatele: přiloguji se, konfiguruji environment a terminál, až mi začnou chodit šipky i backspace. Samozřejmě pro konkrétní stroj, na jakémkoliv dalším to absolvuji znovu. Pak ale spustím aplikaci typu Oracle sqlplus, nebo Midnight Commander, a šipky a backspace s vysokou pravděpodobností opět nepůjdou. No a nakonec si nechám vypsat nějaký soubor (cat moje.abc), po čemž mi zmizí i kurzor, nebo píšu nesmyslné znaky. Samozřejmě vím proč - ale nechápu, proč se toho unix dávno nezbavil.

:-) Jste veselý. Existence jednotného kreslícího API v desktopových prostředích ignorujete. Preempce v Linuxu Vás úspěšně minula, předpokládám, že jste byl asi v té době na kosmické výpravě financované M$, že se to k Vám nedoneslo. Prioritizace IO taktéž. A to konzolové API, to je ta věc, co se nedá použít v aplikacích s GUI, protože pak nechodí eventy? V čem je jako lepší? A bude mi v něm fungovat myš i přes síť, jako mi funguje v Linuxu?

Jenže ta "jednotná kreslící API" jsou i oproti starému GDI dost omezená, a slouží jako wrappery nad X11 a cups. Přičemž každý X11 server má svůj vlastní model driverů video karet. Srovnajte tento koncept se situací ve Windows, a uvidíte, že návrh i realizace je ve Windows daleko lepší (nehledě na širší funkcionalitu a vyšší výkon). Pomalost X11 proti RDP jsme už kdesi probírali, je to ostuda světa unixů.

Preempce v Linuxu mě opravdu minula. Linux byl od začátku psaný jako klasický unixový kernel, kde mezi vstupem do kernelu a ukončením obsluhy volání nedojde nikdy k preempci (v éře dřevních unixů pochopitelný přístup, v době psaní Linuxu naprosto nepochopitelný krok). Dnes distra běží v nejlepším případě s CONFIG_VOLUNTARY_PREEMPT, a CONFIG_PREEMPT nikdo produktivně nepoužívá (dokonce jsem četl kernelové vývojáře, jak od toho odrazovali). Kernel s CONFIG_PREEMPT rád padá (kdykoliv někdo zapomene provést lock, což je pohříchu často), a navíc má problémy s výkonem. Popisuji snad něco nesprávně? Je klidně možné, že se za poslední rok něco změnilo, a já o tom nevím...

Prioritizace I/O se mi také nějak nedonesla. Věiml jsem si, že Linux neumí prioritizovat IRQ, což je dost velké neštěstí, kterým veškeré další snahy padají. Pak je tu ionice, což je dost primitivní náplast, navíc aplikováno per-process, a nikoliv per-handle. Opět - vývoj jde kupředu, a možná mi ukážete, že dnes je (konečně) vše jinak.

Přiznávám, že jsem konzolové API nikdy nepoužíval z GUI aplikace. Proč bych to proboha dělal? No a v čem je lepší mít konzolové API, než systém terminálů se stovkami sekvencí (a desítkami sad sekvencí), to jsem snad popsal v původním příspěvku. Myš v konzoli běhá (pochopitelně i před RDP), jen nějak nevidím důvod jí používat na jinou věc, než copy/paste. TUI je přece jen minulost.

S kritikou terminalu souhlasim. Ale windows jsou na tom v jinych oblastech na terminalu hure - nepohodlny cut and paste, omezene doplnovani, silene resizovani. Znam par citrixovych adminu, kteri na to nadavaji dnem i noci.

Kromě toho, pro terminály přeci jen existují respektované standardy (VT100 jako minimum a jeho potomci) - dokonce respektované mezi různými OS, takže se mezi nimi dá v pohodě komunikovat, což s Win32 Console API podle mě přeci jen nepůjde.

Stává se to, to ano. Ale už opravdu nepamatuju, kdy se mi to stalo naposledy, možná někdy minulý tok. Pak dám jen reset a je to. Určitě se mi to stává méně často, než jak často nadávám na nedostatečné funkce konzole ve Windows, takže to nepovažuju za tak špatný tradeoff. ;-)

Problémem je použití escape sekvencí místo API. Co nakonec leze přes drát, to je irelevantní.

Respektované standardy jako vt52, vt100, xterm, vt220 a pár desítek dalších jistě existují. Jen je jich trochu moc. A neškodil by nějaký standard pro delete a backspace, nejlépe jeden :)

No problem..

Řekněme, že Linux je opisem unixů, který není plně kompatibilní. Ovšem ony ani komerční unixy nejsou plně kompatibilní (jakkoliv by měly být kompatibilní alespoň na POSIX úrovni), takže to není taková újma.

MacOS X není systém unixového typu (na rozdíl od HP-UX, AIXu, Linuxu a dalších). Stejně jako Windows se Services for UNIX projde POSIX testy, a navíc má právo používat ochrannou známku UNIX. Ale právě Core Graphics (včetně Quartz) je ne-unixová technologie.

GDI je letitá technologie, která odvedla veliký kus práce. Windows Vista používají jako primární API .NET, a posun v příštích verzích bude ještě dramatičtější. Vista má jako novinku Windows Presentation Foundation. To je stavěné trochu jinak, a umožňuje takové věci, jako nechat přehrávat objekt videa, a pod něj umístit obdélník s reflection efektem, který bude video odrážet (na úrovni WPF, tedy bez toho, abyste se tím dále zabýval ve svém kódu). Podobně lze ve WPF nechat přehrávat video na krychli, a jen pomocí timeru provádět rotaci krychle. Poskytuje také primitiva pro komplexní práci s textem apod. Masivně se používá 3D akcelerace, a to včetně akcelerace rendrování fontů, antialiasingu i ClearType. WPF má koordináty typu double, nikoliv integer, což například vede k lepšímu subpixel renderingu.
GDI nebylo nahrazeno pomocí DWM. DWM je jen obdoba Berylu, tedy Desktop Manager. GDI je dále na živu, i když je střednědobě nahrazováno pomocí WPF.

Ve Windows mám naopak cut-and-paste na konzoli celkem rád. Tedy pokud si nastavíte quickedit a quickinsert. Doplňování funguje na jména souborů a adresáře, nevidím na něm nic špatného. Resizovat můžete jen do šíře screen bufferu, kterou si ovšem můžete změnit (a nastavit jako výchozí, když na to přijde). Ale uvědomte si hlavně, že ve Windows je konzole jen takový doplněk ke GUI, a ne primární prostředí.

Uz se tesim, jak si nekde na serveru budu na rotujicim komolem kuzelu prehravat DVD. BTW, znamena to, ze budouci Windows budou jako primarni API pouzivat Power Point a WMP?

Cut-and-paste v Linuxu je lepsi, jak na konzoli, tak v GUI. Sorry, neda se nic delat. To same plati pro doplnovani.

Mluvím o možnostech technologie, odpusťte si švejkování.

Budoucí verze Windows (a nakonec i ty současné) mají jako primární API .NET Framework, jehož částí je (už nyní) WPF, o kterém byla řeč. Možná nerozeznáte rozdíl mezi API a aplikací?

Nebojte, staci, aby Microsoft integroval Silnou tecku do Windows tak, jak to ucinil s IE a rozdil se stane zcela nepodstatnym.

To už jsme se doatali na úroveň potlachu v hospodě čtvrté cenové skupiny?

Ono binární drivery a stabilní API je na jednu stranu hezká věc ale na druhou stranu znemožní (a nebo alespoň výrazně zproblematizuje) daný kód přepsat. Je to na první pohled docela riskantní strategie ale umožní MNOHEM rychlejší vývoj.

Ad společné API pro drivery - ale ono existuje, jen není tak centrálně nařízené. Ostatně s drivery pro Windows tiskárny zrovna bojuji - jedna tiskárna mi přestala respektovat počet kopií a občas sama od sebe tiskne jen černobíle. Prý je to nejspíš proto, že mám v síti další tiskárnu od stejného výrobce a ovladače se pohádaly. Bomba ...

Komprese audia a videa - i na Linuxu existují projekty obecných rešení aby byly kodeky sdílené. Ale zase - u Windows je to prima pokud vše funguje. Jakmile se kodeky zhádají, tak už jde jen nainstalovat VLC který na kodeky .censored. a proto funguje bez problémů.

Priority IO operací jsou pokud vím u Windows horká novinka. Nebo chcete tvrdit, že jej umí Windows XP?

HAL a ifdefy - oboje je víceméně totéž. HAL je více oddělený což plyne z nutnosti podporovat binární API. Linux těží z toho, že jsou vždy k dipozici zdrojáky a pak to co je v HALu může implementovat makrem nebo inline funkcí a být tak rychlejší. Ostatně porovnejte si, kde všude běhá Linux (od hodinek po nejrychlejší počítače na planetě) a pochopíte ten rozdíl. A WindowsCE a jeho následovníky neberte v úvahu, to je systém, který s WinXP, ... nemá nic společného, jen náhodou implementuje docela podobné API.

Preemptivní a reentrantní kernel - Linux má, perfektně funguje jen jaksi na serveru to nemá moc smysl - rychlejší reakce neoceníte, naopak oceníte vyšší výkon nepreeptivního kernelu. Prostě u Linuxu si můžete vybrat co je vhodnější, u Windows bylo vybráno za vás.

Systém terminálů je sice příšernost ale stejně to už málokdo používá tak proč to přepisovat? A ztratíte tím kompatibilitu s UNIXy. To je jako argumentovat proč ve Windows jde programy pro DOS psát tak blbě a proč MS nevylepší API pro DOS.

Binární drivery a stabilní API umožňují rychlejší vývoj? Já bych spíše řekl, že to vyžaduje daleko lepší plánování, abyste věci nepřepisoval po pár měsících. Obecný interface pro drivery sice zůstává, ale samozřejmě se mezi major verzemi systémů občas něco mění. Například Windows 2000 zavedly v NT řadě plug and play, a drivery se přepisovaly. Teď se zase přepisovaly drivery grafických karet pro Vistu. Jinými slovy: binární drivery a stabilní API neznamená, že nedochází ke změnám. Jen je třeba plánovat.

Jaké existuje společné API pro drivery na unixech (nebo klidně jen na Linuxu)? Existuje například model grafického driveru, který byl byl závazný, a který by používaly různé produkty (třeba různé X11 servery)? A má takový driver jakoukoliv podobnost s driverem tiskárny (třeba společné funkce typu NakresliElipsu, capabilities bity apod)? Obávám se, že ne.

Ano, na Linuxu vždy existují projekty :). Bohužel multimédia po 17 letech vývoje systému nemají centrální správu kodeků. To bych si na místě autorů nedával za rámeček. Ve Windows samozřejmě kodeky fungují. Pochopitelně pokud je kodek vadný (a to u je open source kodeků typu skoro pravidlo), má průšvih více aplikací.

Prioritizace I/O operací je k dispozici ve Vistě, která je tu rok a půl.

HAL a ifdefy nejsou zdaleka totéž. HAL je oddělený, což znamená možnost ho nahradit jako modul. Když něco modifikujete, modifikujete HAL, a neděláte špagety z kódu kernelu. To je samozřejmě důležité i pro support výsledného řešení. Rychlost není problém, pokud umíte dost rychle dynamicky linkovat (to se provede jednou při startu systému).
Linux v hodnikách nemá s Linuxem na vašem desktopu moc společného. Dokonce neimplementuje ani naprostou většinu API, které máte k dispozici na desktopu.

Ano, Linux má preemptivní a reentrantní kernel. Teoreticky dokonce funguje. V praxi ho kerneloví vývojáři doporučují na odchytávání bugů (holt občas někdo zapomene locknout), a tvrdí, že má značný overhead. Výsledkem je, že neexistuje prakticky nikdo, kdo by na produktivním stroji jel s plnou preempcí kernelu. V případě Linuxu si můžete vybrat mezi příšernou latency, nebo mizerným výkonem s problémy se stabilitou. Výhodné je samozřejmě mít nízkou latency, dobrý výkon i stabilitu (tedy Windows). Obdobně je dobré používat thready místo forku, protože mají nižší režii.
Ovšem Linux byl napsaný po vzoru "dřevních" unixů (což bylo důsledkem toho, že se na začátku moc neplánovalo). Dostat se od "velkého kernelového locku" k současné nestabilní a pomalé preempci (kterou stejně skoro nikdo nepoužívá) stálo určitě daleko více času, než by se na začátku strávilo nad slušným designem.

Systém terminálů je, pokud jsem si všiml, primárním pracovním prostředím naprosté většiny uživatelů unixů (včetně uživatelů Linuxu). Rozhodně bych terminály na unixech nepřirovnával k MS-DOS subsystému ve Windows (který ve 64-bit verzích Windows ani není).
Podpora terminálů se měla předělat v sedmdesátých letech. Jenže unixy v té době nějak zmrzly, jejich vývoj se zastavil, a rozmrazil ho trošku (opravdu jen trošku) až MS s uvedením NT.

Binární drivery a stabilní API NEumožňují rychlejší vývoj :-). Ano stabilní API vynucuje lepší plánování ale ono se stejně občas zjistí, že se to nenaplánovalo dobře a jste v ... . A zrovna zavádění PnP bych se nechlubil - IMHO to naroubování do systému není úplně z nejelegantnějších.

Kotas dotaz - jaké různé X servery? IMHO všichni používají jeden a tentýž - x.org verzi. Cokoliv jiného jsou jen totální speciality. A závazné API pro drivery není zrovna populární věc akorát vy to považujete za nevýhodu a já za výhodu.

Jednotné rozhraní pro MM - ano, zde má Linux co dohánět. Ale on se stal dobře použitelným pro normální smrtelníky poměrně nedávno takže se situace ještě neusadila. Dejme tomu čas. To že kodeky pod Win fungují - teoreticky ano, v praxi až příliš často narazím na problémy.

Prioritizace IO - je ve Vistě a nových Linuxech. Takže tak nějak nevidím moc rozdíl.

HAL a ifdefy - nemáte pravdu. Pokud můžu nějakou často volanou funkci inlinovat nebo dokonce nahradit makrem, tak můžu být výrazně rychlejší. Ostatně podívejte se, kolik z funkcí z HAL.dll nezačíná na HalXxx aneb původně v HAL vůbec neměly být :-). Kernel u Linuxu v hodinkách a v superpočítači je víceméně stejný (plus minus podpora něčeho). userland se ale bude výrazně odlišovat.

Preentibilní a reentrantní kernel - sorry ale zde blábolíte naprosté nesmysly. Thready proti procesům - on fork na Linuxu je velice levná operace (zkopírovat pár pagetables, nastavit CopyOnWrite, ...) ale na Windows je to hodně drahá operace a proto se zde vymyslel opruz zvaný thready. A největší sranda je, že nakonec ideální řešení je na Linuxu kde si můžete vybrat co všechno bude potomek sdílet s předkem - hledejte man page pro clone.

Terminál jako primární pracovní prostředí - no nevím, okolo mě každý (já, žena, rodiče) pracují v grafice a jen já občas použiji terminál pro správu vzdálených Linuxů.

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.

Problém v modelu driverů - ale to je přesně to co říkám. U Win musíte čekat na novou major verzi, u Linuxu se to opraví hned. Aneb rychlejší vývoj :-)

Jediné závazné API - koukněte se na nějaké sofistikované ovaladče např. pro tiskárny pro Win pro lepší tiskárny. Zjistíte, že si stejně pogramátor těch ovladačů většinu věcí obchází a složitě předefinovává. Aneb pro PCL tiskárny máte pravdu, ve složitějších případech je to naopak spíš na obtíž.
A opět zopakuji - xserver se reálně používá jen jeden.

MM - ano je co dohánět. BTW já se zase vyhýbám WMV protože mám doma počítače s Apple Mac OS X a Linuxy a tam je s jeho přehrátím problém.

ifdefy a výkon - nemluvím o volání služby systému ale o volání funkce z HAL. Ono když místo čtení z portu (jedna instrukce inb) musíte volat funkci tak je to docela pakárna. A IMHO na tom Linux v tomto směru není tak špatně - ostatně množství architektur na kterých běží mluví za vše.

reentrance Linux kernelu - byly by odkazy na ty výroky? Zajímalo by mě, kdy k nim došlo. IMHO to bylo za časů kernelu 2.4 ne li starších a situace dnes je úplně jiná.

fork JE oproti vytvoření procesu levná operace. Drahé ja až pak případné exec. Ale pokmkud chci další obsluhu pro stejný typ požadavků pak mi stačí fork a pak se zduplikuje kus pamšti s proměnnými lokálními pro daný proces. Thread oproti tomuto sdílí adresní prostor - je rychlejší přepnutí kontextu a o něco málo rychlejší vytvoření ale zas jeden thread může při případné chybě zlikvidovat i ostatní therady. Aneb o něco větší rychlost a o něco menší bezpečnost. Na linuxu si můžu vybrat, na Windows mi nic jiného než thready nezbyde.
Ale souhlasím v tom, že řešení synchronizačních primitiv na WinNT (WaitOnXxxObject může čekat na cokoliv a lze to kombinovat) je mnohem elegantnější.

GUI - ano pro správu často sáhnu po commandline. Ale většinu času jej nespravuji ale používám :-)

Ano, u Linuxu můžete změnit driver model ze dne na den. Bohužel tím drivery (namátkou nVidia, WiFi, RAID) odpadnou úplně stejně, jako ve Windows. Tímto způsobem můžete změnit cokoliv i ve Windows :)
No a když jsme u toho, možnosti mnohdy přinášejí nutnost. Když dáte k aplikaci zdroják, asi se bohužel vykašlete na psaní dokumentace (přitom zdroják není dokumentace). Když máte možnost měnit interface mezi verzemi, nebudete plánovat, a dopadne to jako s USB. Jde tedy o rozlišení technické nutnosti, a nějakých procedur.

Ve Windows můžete driver tiskárny implementovat více způsoby. Nejjednodušší je použít MS driver, kterému v nějaké DLL předhodíte parametry typu "bude to PCL5, existují dva podavače, umí to oboustranný tisk", a k tomu řada výrobců připatlá vlastní stránku do vlastností tiskárny (třeba nějaké nastavení kvalita/rychlost). Pochopitelně velká firma jako HP se k takové věci nebude snižovat, a udělá si driver obsahující dvacet utilit, který bude 3x za den padat (protože na vývoj a testování nebylo dost peněz), a celý balík "driveru" bude mít 100MB. Naštěstí i HP vydává "minimální" drivery, jen se hůře hledají.

WMV na MacOS přehrajete pomocí Flip4Mac. MS ukončil podporu WMP pro MacOS X (a MacOS 9- a Solaris). Na Linuxu předpokládám funguje mplayer, tedy po instalaci nelegálních kodeků (které stejně instaluje každý).

Reentrance - výroky byly vyřčeny v souvislosti s kernelem 2.6.4 (a jeho problémy s výkonem, pokud CONFIG_PREEMPT=y), zřejmě v roce 2004. Pokud se něco změnilo, rád se poučím. Nakonec jsem se vás i ptal: je vaše distro dodáváno s "plně" preemptivním kernelem, "dobrovolně" preemptivním, nebo ne-preemptivním? A jak jsou na tom ostatní distra? Když jsem se na to díval před pár měsíci, "plně" preemptivní kernel nemělo žádné distro.

Samozřejmě fork je levná operace ve srovnání s vytvořením procesu. Ale drahá v porovnání s vytvořením threadu.
Thready mají sdílet adresní prostor. Context switch je rychlejší, což je jedna výhoda. Druhou výhodou je rychlá komunikace mezi thready (protože máte sdílený adresní prostor), a samozřejmě synchronizace (protože lokální synchronizační primitiva jsou ve Windows rychlejší, než cokoliv ve světě unixů). Samozřejmě thread může způsobit poškození dat ostatních threadů; to ovšem forkovaný proces může také, protože typicky stejně musíte nějaká data sdílet (třeba přes shared memory). Když díky threadu sletí celý servis, tak se nestala žádná katastrofa - Service Manager může ten servis automaticky restartovat. Proti resource leaks se zase můžete bránit tak, že čas od času spustíte nový proces, nové požadavky necháváte zpracovat v něm, a po dokončení práce starého procesu do ukončíte (mikrorebooty). Ono skoro cokoliv je lepší, než klasický unixový process model.
Znovu opakuji, že i aplikace pro unixy (Oracle, Apache) dnes používají thready.

Ve světle výše psaného trochu překvapí, že si někteří lidé vážně myslí, že Linux má lepší architekturu, než Windows.

Změna driver modelu - záleží co měníte. Nedávno se překopalo firewire, na začátku se přepisovalo několikrát USB. Nic z toho neovlivní nVidia, RAID, WiFi. Ostatně použitelné RAID řadiče mají ovladače v kernelu (stydí se jen výrobci pseudoRAID kteří ovladačem maskují, že se jedná o softwarový RAID a pak už je lepší použít SW RAID přímo z Linuxu) a u WiFi se situace poslední dobou rapidně zlepšuje.

Ad drivery tiskáren - ano souhlas. Ale u GDI tiskáren se tomu výrobce nemůže vyhnout.

Flip4Mac - pokud vím, tak s ním taky byly nějaké problémy. mplayer přehraje kdeco. Ale proč riskovat a nepoužít rovnou něco l=pe podporovaného?

Reentrance - situace v roce 2004 a dnes je opravdu trovhu jiná. Na to jak to je u mě (Ubuntu) se kouknu až dorazím domů, teď sedím u stroje s WinNT4 :-)

fork nebude aý zas o tolik dražší než thread. Ano přepnutí je rychlejší ale ... . Paměť kterou potřebujete sdílet si namapujete do všech procesů. Zda sletí jeden proces (a ostatní forknuté fungují dál) nebo proces se všemi thready není jedno - ovlivníte komunikaci ostatních klientů.
Oracle netuším, apache může ale nemusí používat thready.

A Linux je v něčem lepší a v něčem horší než Windows. Ale použitelné jsou oba a vývoj u Linuxu je mnohem rychlejší.

Samozřejmě pokud překopete USB nebo FireWire, ovlivní to USB nebo FireWire. Provádět takovou změnu mezi minor verzemi mi přijde zločin. A muset něco záhy přepisovat mi přijde jako ukázka špatného plánování.

SW RAID přímo z Linuxu? To má dva problémy. Jedním problémem je jeho výkon v Linuxu (byť se to možná už zlepšilo). Tím druhým je boot z takového zařízení. Vyumíte nabotovat z čistě SW RAID5? Windows umí bootovat z čistě SW RAID1. Ale samozřejmě pouze pokud všechny disky fungují. Jakmile nějaký odejde, zřejmě nenabootujete ani ze SW RAID1. Proto je třeba mít ten pseudoRAID, který to za vás zařídí.

Výrobce GDI tiskáren má velmi jednoduchou roli. Tiskárna umí toliko tisknout bitmapy. Driver řekne GDI, že umí jen bitmapy, a dál to moc neřeší, protože GDI mu vše přeloží na bitmapy. Ad absurdum vám stačí ukázkový driver pseudo-tiskárny, který ukládá výtisk do TIFFu, a ten lehce upravíte.

Já nemám Mac, a tedy ani Flip4Mac. Něco lépe popdorovaného bych použil, kdyby to mělo alespoň srovnatelné výsledky.

Pořád říkáte, že dnes je to jinak. Je to klidně možné, ale mě se nepodařilo zjistit, že by se něco změnilo. No, uvidíme co zjistíte.

Paměť, kterou potřebujete, si můžete namapovat. Problém je v tom, že pokud se vám forkovaný proces zblázní, tak může poškodit data ve sdílené paměti. Takže vám vezme s sebou i všechny ostatní work processy (případně jim přepíše nějaký kus dat). Situace je tedy podobná, jako u threadů. Jen je výsledek pomalejší, a když vám sletí worker, tak nevíte, jestli nepoškodil data ostatních workerů.
Apache nemusí používat thready. To je proto, že Apache musí běžet i na unixech, které mají threading v naprosto tristním stavu. Ukázkou budiž Linux s kernelem 2.4 (LinuxThreads ostuda světa unixů), nebo AIXu (minimálně ve starších verzích). Na Linuxu s kernelem 2.6 používá Apache standardně thready. Oracle je používá standardně, a jinak ani neumí.

Nějak jsem si nevšiml, v čem je Linux lepší, než Windows. Napadá mě leda kompatibilita s unixy (i když Windows se SFU jsou na rozdíl od Linuxu POSIX compliant). Architektura Linuxu je zjevně o dost horší.

S tím, že se Linux rychle vyvíjí, je to rozporuplné. Co to znamená? Že nový build kernelu vychází často? Že distra mají novou verzi co pár měsíců? To všechno jsou ve skutečnosti problémy z hlediska supportu i obchodu. Zkuste zákazníkovi prodat desktopový systém, který se 3x do roka upgraduje (a než skončíte marketignovou kampaň na AAALinux verze X, už abyste začal znovu s verzí Y). Zkuste vývojáři tvrdit, že má aplikaci podporovat na X distrech, a každé z nich v Y verzích (X*Y kombinací, aby obsáhl 1% desktopů). A mimochodem potom vznikají netestované zmetky, jako distro, které napíše "vložte CD2", a to CD nepozná (zřejmě v rootu chyběl nějaký ID file), případně distro které hned po výběru jazyka začne všude psát zmršenou diakritiku, a nebo distro, kde když napíšete text v UTF-8, tak je na obrazovce OK, ale už v Print Preview jsou místo českých znaků otazníky (to jsou tři věci, které se mi opravdu staly).

Linux sice už léta "rychle" přidává features, ale nějak je na tom pořád hůře, než konkurenční systémy.

přepisování něčeho - ono je to i nedostatkem lidí a nedostatkem zkušeností.

SW RAID je na Linuxu rychlý více než dost. Bootovat z RAID1 umí bez problémů. A je postaven nad partitions takže zkombinovat ne jedněch discích malou boot partition s RAID1 pro boot a velkou RAID5 pro data není problém. Pokud správně nastavíte boot managera tak nabootuje z kteréhokolivk disku v RAID1.

WMV - používám MP4 a IMHO jsou výsledky více než porovnatelné. U MP3 není problém použít větší bitrate, disky jsou dneska velké (ostatně VMA byl výrazně lepší jen u malých bitrate které bych stejně na muziku nepoužil).

thready - přestaňte se ohánět linuxem 2.4 to je už minulost. Pokud se zblázněný thread urve ze řetězu, tak je mnohem větší šance, že poškodí něco důležitého pokud je sdílení celá paměť než když je sdíleno jen nezbytné minimum.

Nové buildy, ... ano daň za rychlejší vývoj je trocha zmatku.

Linux je na tom v něčem lépe (podpora kdejaké platformy od hodinek po superpočítače, ...), někde hůře. Ale tvrdit, že je na tom jednoznačně hůře je prostě nesmysl.

Samozřejmě špatný design je selháním lidí i procesů.

SW RAID na Linuxu měl řadu problémů s výkonem, včetně výkonu žurnálových FS, a se zátěží systému během rebuildu RAIDu. Jak to vypadá dnes, to opravdu netuším.
Z RAID1 zabootujete, pokud jsou disky v pořádku. BIOS bude bootovat z jednoho z disků RAIDu 1, a po načtení driverů OS se bude pokračovat v plném RAID1 módu. Pokud ale první disk RAIDu bude mrtvý, tak z něj nezabootujete. Některé BIOSy umí bootovat i z dalších disků, což vás může zachránit. Ovšem pokud budete mít například na "vhodném" místě bad block na disku, ze kterého BIOS bootuje, máte smůlu. BISO-supported RAID tohle samozřejmě řeší.
Boot partition s RAID1 jistě můžete mít. Problém je v tom, že pro RAID5 to chce 3 a více disků se stejnou geometrií, nejlépe využitých jen pro ten RAID. Neuděláte tomu moc dobře, pokud budete kombinovat 2-HDD RAID1 s 3-HDD RAID5 (zátěž disků bude nestejná), pokud když vám bude partition na třetím disku RAIDu5 začínat jinde, než na prvních dvou. Opět BIOS-supported RAID to řeší za vás.

MP4 je fajn, ale kodeků je dlouhá spousta, a občas si nesednou. Navíc se ve Windows typicky používají open source kodeky, které mají řadu chyb. Jedna verze kodeku u některých souborů špatně demultiplexuje po seeku, takže se čas od času po čtvrt vteřiny od seeku ozývají z audia hrozné zvuky. Další verze u jiných souborů po seeku občas vytuhne, obraz se zastaví, a pomůže jen restart přehrávače. Další verze má resource leaks, a například pokračuje v přehrávání některých souborů i po ukončení přehrávače. Taková je mimochodem moje zkušenost s většinou open source - má hromadu bugů. S WMA/WMV tohle nikdy neřeším, vše "prostě funguje".

Linux 2.4 je historický fakt, a jeho implementace threadingu ukázkou designové katastrofy. V případě "zblázněného threadu" je pád celé aplikace pravděpodobnější, než v případě zblázněného worker procesu pád všech procesů. V možnosti corruption sdílené paměti bych ten rozdíl ale tolik výrazný neviděl. Navíc ve Windows zpravidla nepíšeme v ANSI C, ale v C++, což samo o sobě o něco snižuje pravděpodobnost problémů. No a killer argument je ten, že threading je rychlejší (context switche, synchronizace), a má nižší spotřebu paměti.

Jak jsem psal, v případě Linuxu se dá mluvit leda o rychlejším release cycle, nikoliv o rychlejší implementaci features. Dnešní technologickou špičkou je .NET Framework 3.5, s WPF a XAML, transakční NTFS, prioritizace I/O operací, rezevace přenosového pásma, defragmentace přimontovaného FS na pozadí s nízkou prioritou I/O apod.

Samozřejmě hodinky s Windows CE jsou nepoužitelný gadget, stejně jako hodinky s Linuxem.
http://asia.cnet.com/crave/2008/04/17/first-watch-crams-in-windows-mobile-5/
No a Windows najdete na superpočítačích také. Viz Windows Compute Cluster. Popisoval jsem tu někde i důvody, proč se Windows běžně nepoužívají v superpočítačích (node je celkem tupé zařízení, zato je jich potřeba hromada, a Windows na node napřinášejí žádné výhody, jen vyšší cenu; změnu má přinést Windows Compute Cluster, kde MS prodává primárně řídící SW, a který má velmi rychlý deployment, plus integraci s Visual Studiem).

Špatnému designu se nevyhnete nikdy už třeba proto, že přijde něco, co v době návrhu neexistovalo. Aneb např. roubování PnP na WinNT kernel - ono to jde ale určitě by to šlo udělat mnohem elegantněji leč za cenu nekompatiblity. Linux se toto rozhodl přijmout jako životní fakt a nese mu to jisé výhody i nevýhody. Ale to už se opakuji a vy tento argument stejně ignorujete nebo nechápete :-).

SW RAID - používám na spoustě míst a peblémů jsem si něja nevšiml. Hlavní výhodu vidím v tom, že to není závislé na žádném HW. Vám pokud umře RAID řadič tak máte VELKÝ problém. U větších serverů to lze řešit zálohami, nahradním řadičem ve skříni, ... ale ... . Bootování z jiního disku - V MBR mám Smart Boot Mamager a v něm možnost nabootovat z kteréhokoli disku. Sice to znamená nutnost aby někdo v boot menu vybral jinou položku ale to zas takový problém není. Boot a RAID 5 - SW RAID v Linuxu běhá nad partitions takže malá boot partition v RAID1 a zbytek disků do RAID5 a nevidím problém.

MP4 - přehrávám všude pomocí VLC a jsem spokojen :-) WM? na spoustě systémů neběží. Toto je o jiných prioritách :-)

Threading má o něco rychlejší context switch (ale to IMHO v praxi zas tak velký rozdíl neudělá), spotřeba paměti je v obou případech plus minus stejná (dohledejte si Copy On Write). V Linuxu mám možnost použít threading a forky, ve Win jen threading.

Linux IMHO má jak rychlejší release cyklus tak i rychlejší implementaci featur jen jeho vývoj byl mnohem více směřován na servery což se snad dnes mění. BTW koukněte kdy se Linux naučil věci jako podpora 64bit, poaměti NUMA a další serverové záležitosti.

Windows Mobile sem netahejte, jejich jádro nemá naprosto nic společného s WinNT jádrem. Naopak Linux na hodinkách je překládán ze stejných zdrojáků jako ten na superpočítačích a to říká hodně o jeho portabilitě a schopnostech jeho tvůrců.

Zeptám se: dostal jste se domů, a ověřil, jak je to s preempcí kernelu u běžných dister?

U Ubuntu je CONFIG_PREEMPT_VOLUNTARY=y, jinde nevím

Takže jinými slovy se zřejmě moc nezměnilo. Určitě víte, že CONFIG_PREEMPT_VOLUNTARY provádí přeplánování na pár místech v kernelu, která byla vyhodnocena jako nejkritičtější, a do plné peempce to má velmi daleko. Mimochodem třeba u hudebního SW celkem záleží na latency (u přehrávání MP3 naopak daleko méně).

Otazka je, jestli tou certifikaci neprojde nebo jenom za ni nikdo nechce zaplatit. Pokud vim, existuji dve verze jadra, ktere tu certifikaci maji: jakysi Linux-FT a jeste jeden, jmeno jsem jiz stastne zapomnel.

UNIXy jsou mozna prezite, ale patri k tomu nejlepsimu, co bylo na poli OS vymysleno a tak i pres mouchy, ktere NIXy maji, tu s nami jsou jiz peknou radku let a nepochybne jeste radku let budou. Nechcete snad tvrdit, ze Windows jsou navrzeny inteligentneji, ze? Jiz zbezny pohled dava tusit, ze tomu tak neni. Zbezny pohled dava tusit, ze se nekde utrhlo prase a slo se do Microsoftu plest do vyvoje. Nevim proc, ale nejak mi ted samovolne vytanul na mysli Ballmer, ale urcite to nema zadny vztah k predchozi vete. Je-li UNIX prezity, o Windows to plati tuplem, prez jejich relativni mladi. Nekdo holt zije zhyrale a starne predcasne. Microsoft by udelal lepe, kdyby zacal znovu, na zelene louce. Mel by se podivat, jak to delaji jini, najmout lidi, kteri tomu opravdu rozumi, zavrit Ballmera do klece v recepci Microsoftu. Pak vzit to nejlepsi z Windows a jinych OS a konecne udelat neco, z cehu cloveku netecou nervy.

S dovolením POSIX compliance není jen o jádru.

Unixy beze sporu patří k tomu nejlepšímu v historii IT jako oboru. Ovšem dnes jsou stejně přežité, jako děrné štítky.

Ano, Windows jsou navrženy lépe, než unixy. Uváděl jsem řadu důvodů, proč si to myslím. Zkuste vy uvést nějaký *faktický* důvod, proč si myslíte opak. Jistě sám uznáte, že "nekde se utrhlo prase a slo se do Microsoftu plest do vyvoje" není faktický argument.

MS už začal znovu na zelené louce. Viz Singularity. Mám za to, že během 5 let uvidíme výsledek. Potom ovšem budou unixy o dvě generace pozadu. Jestli dnes přirovnávám unixy k děrným štítkům, tak v té době bude sedět přirovnání k drátovým propojkám Eniacu.

Singularity je research project. Samozřejmě se v této podobně neobjeví. Spíše bude výsledek výzkumu využit v příštích verzích Windows. A nebo MS uvede nový produkt postavený na této technologii. Ale když uvážíte, že poslední vývoj okolo Singularity se týkal i možnosti běhu "klasického" SW, tak to vypadá na první scénář.

Mluvme o Windows řady NT. Ty mají odjakživa uživatelské účty, přístupová práva, Access Control Listy na všem (které často unixy standardně nemají dodnes), jsou odjakživa síťové atd. Windows 3.x byly velmi omezené tehdejším HW, byly určeny čistě pro osobní počítače, a z důvodu overheadu neřešily věci typu bezpečnost.

Pravidelně vyšší HW nároky má většina produktů, včetně dister Linuxu.

Jasne, my vam zkratka verime, ze Intel vyrabi novejsi procesory pomalejsi nez ty stare. :)

No zrovna P4 Celeron je proti plnohodnotné PIII docela ve srabu. Já se kdysi radoval, když jsem místo PIII 1,13 GHz HP dostal 2 GHz P4-M Dell, ale jen do otestování výkonu. Jediné, co ten stroj měl po stránce procesoru navíc, byla technická životnost...a spotřeba, tepelné vyzařování a hluk. :-) Kdyby neměl větší operační paměť a pevný disk, asi bych ten "upgrade" vůbec nepostřehl. ;-)

BTW, i Intel umí dělat fakt seriózní boty. NetBurst ustál přeci jen docela dobře, ale projekt iAPX 432, který dokonce ještě pamatuju :-), skončil ještě úžasnějším fiaskem, jakkoli to byl galantní a odvážný návrhářský počin. :-) To i ty lispové počítače stály víc nohama na zemi.

Tím chcete říct, že P3 600MHz je výkonější, než Celer 2.8GHz? Že GF4Ti je podle NĚKTERÝCH testů výkonější než GF 5200, to nepopírám. (I když zase na druhou stranu, 5200 má podporu DX9). Paměť nemá cenu komentovat... Vista je na 512MB neprovozovatelná, což jistě sám moc dobře víte :)

Proboha, člověče, zjistěte si něco málo o historii IT. MS vyvíjel OS/2 pro IBM, za přispění IBM. Samozřejmě, že viděli pod pokličku, když šlo o jejich aktivitu. Společnost IBM například trvala na popdoře 80286 v OS/2, což se MS nelíbilo. NT byly napsány na úplně jiném základu, než OS/2 (modifikovaný mikrokernel, portabilní OS, HAL, více subsystémů včetně kompatibility s OS/2).

Compiz je jen kompozitní desktop. Proč si stěžujete na HW nároky u Visty? Vždyť je to směšné. FX5200 je 5 let stará karta z value segmentu, a je to zřejmě nejslabší kus, na kterém Vista poběží s rozhraním Aero. Zkuste to bez Aero, v tomto případě to možná pomůže. Zátěž CPU může souviset třeba s fulltextovým indexem, nebo defragmentací na pozadí - vezměte Resource Monitor, a podívejte se, kdo vám žere zdroje. 9GB velikost složky Windows je také o ničem, když disk menší než 80GB už nekoupíte, a i nejlevnější sestavy s cenou pod CZK 10000 mívají 160GB disk.

Já si na HW nároky stěžuji vždy když musím u podobného PC trpět se systémem, jehož odezvy jsou na úrovni rychlosti mentálně postiženého dítěte. To by možná bylo spokojené. Aero je samozřejmě vypnuté a všechny vizuální efekty jakbysmet. Hlavním zabijákem tu bude to CPU a pak pevný disk, ale přesto zlatá XP na odezvu než Vista sebevíc ořezaná. Ty tu jsou totiž nainstalované taky a je to nebe a dudy. Asi to bude nějaké prokleté či co. Těch zabraných 9GB bez programů je individuální, já radši egoisticky mám víc místa pro sebe než pro systém :)

A muzes mi ty picusi ukazat treba nejaky moderni popularni ASUS EEE s alespon 80 MB?

Ale, dyk se staci podivat na adresarovou strukturu a jak se v tom teprve po letech nekdo pokusil udelat trochu poradek, aby bylo jasne, ze je to bastl.

Mluvte konkrétně. Co je za problém s adresářovou strukturou?

Jednoduse je to chlivek. Puvodne snad cele Windows byly nasypany do jednoho adresare (presne se jiz nepamatuji) a z teto skvele myslenky vyplyva soucasny neuspokojivy stav. Dnes to sice trochu rozdelili na podadresare, ale furt nic moc. Takze v c:\windows mam nasypane .dll s .exe, .ini a logy..., v system32 mam nasypane .dll s .exe, .ini a logy.... Uzasne, kdyz treba potrebuji vyhledat nejaky log, tak tahleta "logicka" struktura, kdy jsou veci "prehledne" uskupovany do adresaru podle funkce, je prakticka, jak hrabe do postele. Uzasne tez musi byt, kdyz nejaka podelana .dll existuje v ruznych adresarich v ruzne verzi a ted je otazka, ktera se pouzije.

Jeste reknete, ze Windows maji adresarovou hierarchii navrzenou lepe, nez UNIX.

Vy máte v adresáři Windows dll, ini a logy? To celkem překvapí. Knihovny .dll jsou v podadresáři System32, a .ini se dávno nepoužívají (najdete tam tři kusy, které jsou tam pro kompatibilitu s Windows 3.x). Místo logů existuje centrální Event Log (byť pravda například instalace patchů zanechají log v tempu, nebo ojediněle i v adresáři Windows). Textové logy (třeba DHCP log, pokud je zapnutý) jsou v System32\logs. Pořadí ve kterém se prohledávají adresáře na knihovny je samozřejmě přesně dané, a popsané ve vývojářské dokumentaci (MSDN).

Když jste u těch logů, jak se v nich orientujete na unixech? Oracle třeba píše své logy do svých vlastních adresářů. Fuj.

Unixy mají adresářovou strukturu navrženou poměrně pěkně, ale bohužel na dnešní poměry nevhodně. Například uživatel má na unixech svůj home adresář, a pod ním bez lady a skladu nacpané všechno. Ve Windows existuje roaming, tedy možnost pracovat se stejným profilem na různých stanicích (změny v profilu se pak replikují na server). Proto máme oddělená uživatele, která migrují s uživatelem, a data, která na stanici zůstávají. Například cache browseru nemá smysl migrovat mezi stanicemi. Nakonec se zkuste podívat do svého home directory na strukturu podadresářů.

Windows desktopové edice mají jednu desktopovou session (o kterou se můžete poprat s kolegou), což je marketingové omezení. Serverové verze se to netýká.

Samozřejmě Windows lze upravovat k obrazu svému. Je to systém poskládaný z komponent, se který lze změnit k nepoznání. Jenom to nikdo nedělá, stejně jako lidi netrhají kapotu ze svého auta a nenahrazují jí svými výtvory (vyjma pár šílenců).

Pokud tohle považujete za problémy návrhu, je to dost slabé. Čekal jsem, že se budete bavit o kernelu, správě procesů a threadů, kernelu, konceptu UI, subsystémech apod. Místo toho probíráme ikonky.

Na server patří serverová edice, na desktop desktopová. Serverová umí, co má umět server, a desktopová zase to, co má umět desktop.

Bohužel X11 vám neumožní to, co můžete mít s RDP bez problému. Tedy například GUI session před dial-up, nebo GPRS. Zkuste si v tomhle srovnat X11 a RDP, a pak se o tom můžeme bavit dále.

To je samozřejmě nesmysl. Windows si můžete upravovat k obrazu svému, a to celkem dramatickým způsobem (a legálně). Všimněte si, že na Windows jede většina bankomatů, velké procento pokladních systémů, informačních panelů apod. To jsou Windows Embedded, které si můžete poskládat z komponent. U běžných verzí si naopaku musíte přitesávat instalaci. Výsledek může vypadat třeba takhle:
http://www.kerin444.net/images/windows/desktop_01-04-2004.jpg
Pokud vám ale není 16, používáte stroj na práci, případně se u něj bavíte, a nechcete si ho mršit tak příšerným způsobem. Nakonec svému autu také můžete servat blatníky, a předvést svou tvořivost (s tím rozdílem, že auto pak nebude smět na silnici). Jenže kdo by to dělal, a hlavně proč?

Počkat, počkat. Na jedné straně tu mluvíte o architektuře a designu systému, a na druhé straně mi tvrdíte, že se vlastně zajímáte jen o ikonky. Tak jak je to? Já tu uvedl pár celkem dobrých důvodů, proč považuji unixy za přežité. A to nikoliv z hlediska barvy ikonek, ale z hlediska konceptu.

Superpočítače se tu diskutovaly nedávno, a to dokonce spolu (nepamatujete si už?). Co jsem k nim psal:
Superpočítače jsou velmi úzký trh. Navíc node clustreru/gridu je dost tupé zařízení, které musí mít konektivitu, správu paměti a procesů, a tím to končí. To jsou věci, které dostanete daleko levněji, než za cenu desktopové licence Windows. Ovšem v posledních letech se MS snaží prosadit i na poli HPC. Jak roste počet HPC aplikací, MS cítí obchodní příležitost. Sází na jednoduchou správu a deployment. Banky a pojišťovny už občas používají Windows Compute Cluster Server 2003 a Windows HPC Server 2008.
http://www.root.cz/zpravicky/analyza-gartner-windows-se-pomalu-hrouti/197594/

Pokud si vzpomínám, tak jste se mě snažil přesvědčovat, že node typického superpočítače má stovky CPU, a desítky GB RAM. Jestli jste četl mohi odpověď (a linky v ní), tak už víte, že o věci nic nevíte.

Bohužel X11 vám neumožní to, co můžete mít s RDP bez problému. Tedy například GUI session před dial-up, nebo GPRS. Zkuste si v tomhle srovnat X11 a RDP, a pak se o tom můžeme bavit dále.

To je zajímavé, naše interní demo spočívající v tunelování plnohodnotného desktopu přes GPRS, WiFi a dvě VPNky se tedy vůbec neuskutečnilo? :o) Krucinál, co všechno ještě v naší enterprise distribuci nefunguje, a my o tom nevíme? Neměli bychom její vývoj pověsit radši na hřebík a přesídlit do Microsoftu? ;-)

Naše "interní demo" skončilo tak, že jsem se přes dial-up 22.8kbps připojil k AIXu, půl minuty čekal na login screen, pak napsal "root", a dalších 10 sekund čekal, než se to slovo "root" objeví. Práci s CDE jsem pro nedostatek trpělivosti nedemonstroval. Pak totéž se Solarisem, a nakonec sice ne příliš svižná, ale ještě přijatelná práce s Windows přes RDP.

Klidně přesídlete do MS. Ale jestli myslíte, že sabotáží něco dokážete, tak jste na omylu ;)

To jsou ale vaše problémy, ne naše. ;-) Nám NX servery i NX klienty bez problémů fungují. A když na to přijde, dokážeme přes NX urychlit i to RDP, aby nebylo tak náročné. ;-)

NX, to je trochu jiná káva. S tím urychlováním RDPO to máte vyzkoušené, nebo odkoukané z prezentace, které srovnávala NX s RDP z roku 2000?

OMG ty jsi ale trol

No našel jsem tam něco jako:

1) Neodkazují se na naší definici ale napsali si vlastní. Lumpové!!! Ale nikdo nezkoumá, zda náhodou ta definice není shodná :-)

2) Oni umí něco navíc proti naší definici. Lumpové!!!

3) Oni označili funkci gets za nedoporučenou a my ne. Lumpové!!! Pokud někdo zná jazyk C, tak ví, že kdokoliv, kdo má rozum, tak nepoužije gets ale její variantu která obsahuje i velikost bufferu a tím zančně sníží bezpečnostní riziko - buffer overflow.

Takže asi tak :-)

Linux neni POSIX compliant nebo Linux nema POSIX certifikaci?

Viz co jsem linkoval. Není POSIX compliant.

No, jak jsem tak koukal po Internetu, tak podle jinych linku to spis vypada, ze compliant v podstate je, jen nikdo nezaplatil za certifikaci.

V linkované prezentaci byl jeden kus. SCO tvrdí, že je to jeden z mnoha. Otázka je, jak moc se jim dá věřit :)

Nemotám dohromady dvě věci. Společnost IBM licencovala zdrojáky prapůvodních unixů, a licence se vztahovala i na odvozená díla. A problém je velmi podobný, jako v případě Linuxu a kernelových modulů. Pokud IBM napíše JFS, je to odvozené dílo od původního zdrojáku, i když z něj nic neobsahuje? Pokud napíšu kernel modul pro Linux, je to odvozené dílo, i když z Linux kernelu nic neobsahuje?

SCO je na pokraji záhuby. Pokud by měla něco v rukávu, tak to použije.

IBM licencovalo zdrojáky a na XFS pro UNIX se vztahuje licence pro UNIX. Ale odvozené dílo to IMHO není.

Kernel modul - zde záleží jaký modul a jak moc je integrovaný do kernelu. IMHO ale platí že i když to nebude odvozené dílo, tak se na něj nejspíš vztahuje GPL protože jinak je jeho zahrnutí do kernelu nelegální.

Ale toto případně budou muset rozštípnout právníci, my to nevyřešíme.

Jak jsem psal, hlavní problém SCO spočívá v tom, že velká většina kódu, který byl předmětem sporu, byla uvolněna pod BSD licencí.

Ad IBM: pokud vezmete zdroják, a něco k němu připíšete (třeba podporu SMP, nebo nový FS), je to odvozené dílo. Nevidím důvod, proč by to soud neměl uznat. V případě Linuxu a GPL je situace taková, že podle vývojářů kernelu je odvozeným dílem v podstatě cokoliv. Nutnost uvolňovat zdrojáky linkující proti GPL projektům je tu právě proto, že se jedná o odvozené dílo. Ale souhlasím, že tohle rozlousknou až právníci.