Microsoft: „hledáme open source evangelistu”

Pánové, koukám že nkdy na konci roku 2006 tu byla doszti tupá argumentace co je lepší, jestli Microsoft nebo Apple. Rád bych tu slyšel opravdu úádné argumenty a né tlachání. Pokud někdo neví co MAC X versus Windows, nikdy němel možnost porovnat HW a SW těchto výrobců na akademické a vyšší úrovni, tak ať si nechá hloupé názory pro neznalé lidy kteří pracují a pracovali pouze na MS Windows. Nic proti MS Windows nemám ale uvědomte si všichni že Apple je na tom s HW stokrát léme než nějaká stupidní architektura na PC. Vždit je to stále stejná písnička na x86 a teď s k tomu přidala architektura s 64 bitovým CPU. Srovnáváte BMW a Volvo. Tak mi řekněte co je lepší z těchto dvou výrobců vozů. Každej si najde to co více vyhoví jeho požedavkům. Tečka za vším, servus.

Ad vývoj - přesuny naštěstí nejsou technicky velký problém. Viz přesunutí GDI do kernel mode v NT 4.0 - aplikace nepoznaly nic, jenom se zlepšil výkon. Dále není pravda, že se ve Windows nepředělává "od základu". Například Windows NT 4.0 měly výrazně odlišnou strukturu driverů. Windows 2000 zavedly drivery sběrnic, které rozhodují, jaké drivery pro zařízení běžící na dané sběrnici se mají zavést. To byla opravdu velká změna. Stejně tak Vista znamená řadu změn. Obecně je třeba plánovat architekturu s trochou rozhledu, a pokud vyvstaly nové požadavky nebo se něco nepovedlo, tak to mezi verzemi změnit. Rozhraní směrem k aplikacím by se měnit nemělo (proto jsou v API ty funkce *Ex, třeba CreateFileEx).

Udržování zpětné kompatibility samozřejmě stojí úsilí, ovšem ve výsledku jsme schopni na Windows Vista běžet aplikace psané pro Windows 2.0, a to bez jakýchkoliv změn v těch aplikacích. U Linuxu je vše psané pro aktuální verze, a s ničím novějším ani starším to často neběhá. V důsledku se většina SW šíří jako součást daného distra :/. To vede k tomu, že pro Linux je minimum SW mimo součástí distribuce (ve srovnání s Windows). Obecně úspěšně používat SW šířený v binárkách a nekompilovaný pro dané distro (v dané verzi) je dost problém.

Ad portabilita - nejvýkonnější počítače jsou typicky clustery, a často na Intelu. Wi-Fi routery jsou ale hezký příklad. Windows by v nich šly použít (jde typicky o MIPS, a má dost paměti pro NT kernel), jenže k tomu není žádný důvod. Výrobce potřebuje velmi nízkou cenu, TCP stack, a tím to končí. Takže na Wi-Fi routerech končí Linux, vxWorks apod.

Ad thready - znám fork. Windows mají obdobu pouze pod Services for Unix. Fork problémy s výkonem neřeší, mimo jiné protože worker processy alokují paměť pro data často na stejné adresy ve svém address space (prostě memory map je jiná u každého cílového procesu). Proč je v Apache podpora threadů nevím, ale používá se na Linuxu i většině dalších unixů. Údajně to bylo nutné pro ošetření serverů s vysokou zátěží.

Ad X11 - jinými slovy X11 je technologicky oproti GDI velmi zaostalé, dokonce o generace. Ad tisk - samozřejmě je žádoucí, aby bylo možné jedním kódem kreslit po obrazovce i tiskárně :). Je také dobré, když je možné volání použitá pro kreslení na obrazovce schovat do souboru, a ten soubor pak rastrovat jinde (třeba na té tiskárně); viz WMF, EMF. To s X11 půjde velmi těžko. V případě použití knihoven nad X11 je celá vrstva X11 nadbytečná (viz Qt a embedded zařízení). A právě vy jste říkal, že "v Linuxu by se to přepsalo znova a přehledně". Nepřepsalo, protože to chce plánování a rozhled do budoucna. X11 visí v unixech coby historická příšernost, a nikdo nic nepřepisuje. Nejvýše se něco píše nad stávajícími X11 (s výjimkou těch embedded zařízení, kde je X11 mnohdy naprosto neúnosným overheadem).

GUI na serveru není k tisku potřeba; stačí modul GDI32, a žádné GUI tam být nemusí. Ovšem otázka je, proč na serveru nemít GUI.

Async IO je dobré pro specifické účely. Pokud píšu DB engine, je to dost zásadní věc. Pokud píšu jednoduché účto nebo Office, je to celkem jedno.

Ad terminálové sekvence - tato vrstva měla být dávno zrušena, a mělo zbýt jen API. Ano, blbne to - zvláště proto, že všechny aplikace zřejmě nemají stejný způsob určování typu terminálu. A také proto, že aplikace nepoužívají jediný zdroj sekvencí pro daný typ terminálu. Proč stavět další vrstvu nad zastaralé terminály? Proč ani tuhle skoro 40 let starou příšernost nikdo dodnes nepřepsal od základu? Ještě chcete tvrdit, že "v Linuxu by se to přepsalo znova a přehledně"?

Ad subsystémy - ostatní subsystémy pořád formálně existují. Samozřejmě se časem ukázalo, že Win32 je prostě nejužívanější. POSIX layer (mimochodem ten *není* wrapperem nad Win32) byl z instalace vydělen do Services for Unix ve Win2K, protože ho skoro nikdo nepoužíval. OS/2 subsystem byl odstraněn také ve Win2K, protože OS/2 v mezičase umřela. Architektura zůstala.

Těší mě, že uznáte, že Windows jsou před unixy v mnoha věcech výrazně napřed. Mnoho čtenářů root.cz totiž tohle neví, nebo nechce vidět.

Dovoluji si vám připomenout, že velká část Win32 volání se ve skutečnosti provádí na úrovni kernelu (příslušná knihovna typu GDI32.dll provede syscall). .NET může s klidem používat právě tyto kernelové funkce. Win32 tak jak ho známe je jen jeden z modulů. MS samozřejmě bude držet kompatibilitu, ale otázka je, kolik nových věcí půjde napsat jen v .NETu. Win32 bude existovat primárně z důvodu zpětné kompatibility, a za mnoho let dopadne stejně, jako VDM (Virtual DOS Machine) v 64-bit Windows. Je to samozřejmě spekulace; tak daleko dopředu nevidí ani autoři Windows. Faktem je, že MS interně diskutoval oddělení (možná některého) unmnaged kódu do sandboxu, s tím že koupě VirtualPC měla přinést potřebné technologie. Rozhodně to ale není věc, která by měla nastat zítra ;)