[59] Budu to muset trochu krátit. Na rootu občas přispěju do diskuze tehdy, když vidím ve článku či diskuzi zjevný nesmysl, nebo když mám z jiného důvodu potřebu se k něčemu vyjádřit. Nejsem uživatelem Linuxu, takže nemám zapotřebí říkat, že věci, které jsou špatně řešené, nebo rozbité, jsou ve skutečnosti v pořádku. Stejně tak nemám zapotřebí před kritikou nějaké věci psát "Linux je super, ale...", zvláště pokud si to nemyslím. Rovněž na rozdíl od některých jiných lidí nedělám na rootu PR, takže se nemusím bát říci i nepříjemnou pravdu. Nepřipadá mi, že by tím diskuze nějak trpěla.
K amatérům jsem se již vyjadřoval. Znovu opakuji, že se nejedná o urážku, natož o urážku vaší osoby.
Open source a kvalitní aplikace? Ano, i takové případy existují. Bohužel to není pravidlem. Argument s číslem verze je velmi relevantní. Pokud projekt trvá ředu let, a nemá jediný výsledek, ale juen samé meziprodukty, je asi něco velmi špatně. Možná chybí vedení projektu, a zainteresovanost autorů na výsledku.
Ke špatným návrhům. Návrh unixu měl na začátku mouchy (například byl single user), ale v osmdesátých letech to byla nejlepší alternativa na trhu. Bohužel dnešním požadavkům příliš neodpovídá. To, že monolitický nepreemptivní kernel je přežitý design, musel Linus vědět už ze školy. Jenže on ve skutečnosti žádný design Linuxu neprovedl - prostě převzal design původních prastarých unixů, a postupně ho přepisoval pro x86 (v čemž také nebyl první). Nakonec jak skvěle prováděl plánování můžete vidět zde: http://groups.google.com/group/comp.os.minix/msg/b813d52cbc5a044b?dmode=source
Mikrokernelový design má samozřejmě své problémy, a to především v oblasti výkonu. Nicméně zajimavým side effectem je fakt, že takový systém je pěkně modulární. Jak jistě víte, Windows řeší problém výkonu mikrokernelu přesunem serverů do kernel mode, a zachovávají modularitu. Monolitický kernel, navíc bez stabilního API, je neštěstím Linuxu.
X11 je příšernost ohledně psaní aplikací, dokumentace, a stejně tak ohledně výkonu. Kupodivu X11 protokol je nevhodný i pro vzdálený přístup k systému (zkuste si přístup X11 session přes dial-up nebo GPRS, a srovnejte s RDP - rozdíl je velmi dramatický). Navíc X11 servery nejsou multithreadové (při značně pomalém rendrování stránky s čínskými znaky máte smůlu, dokud nedoběhne), nelze se znovu připojit k odpojené session atd. Některá embedded zařízení opravdu kreslí do framebufferu. Daleko lepší by ovšem bylo, kdyby taková zařízení měla drivery grafické karty se standardním rozhraním, a mohla tedy vyjma framebufferu používat akceleraci. Pak by rozdíl asi byl vyšší, než těch 30%. Qt a GTK nejsou na X11 závislé, ale protože pro Linux neexistuje jednotný interface grafických driverů, těžko mohou bez X11 rozumně používat grafickou kartu. Ve Windows je pochopitelně interface, který umí každé zobrazovací zařízení, a driver řekne, které věci zařízení umí. Některá zařízení umí jen zobrazovat bitmapy, jiná zařízení umí barevné obdélníky, offscreen buffery, čáry, křivky, nebo rendrovat text. GDI potom překládá volání aplikace na taková grafická primitiva driveru, která dané zařízení umí. Oproti X11 neskutečně pokrokové (a to ještě popisuji GDI, které dnes už prakticky končí).
Ale vidím, že konkrétní příklady špatného návrhu jste vzal celkem rychle. znamená to, že v pohledu na preempci kernelu, management I/O, stabilní kernelové API, memory overcomitting, (ne)podporu Unicode, adresaci zařízení, systém device nodes a systém terminálových sekvencí se shodneme? Rovnou můžu přihodit multithreading, který byl v návrhu Linuxu jaksi opomenut, a celou věc se podřilo napravit až v kernelu 2.6 (LinuxThreads v kernelu 2.4 byla katastrofa a hanba).
Když říkáte, jak mohou admini problémy OSS systémů opravdu řešit, tak mě dost překvapuje, že OSS systémy mají pořád těch problémů daleko více, než plaforma Windows. Navíc mi nepřipadá, že by troubleshooting na platformě Windows byl nějak zásadně složitý. Jen ho většina lidí neumí, bohužel často včetně adminů; zřejmě proto, že jej není tak často potřeba provádět.
¨
Do ovládání Gimpu se navážím proto, že jde o ukázku toho, jak GUI nemá vypadat. Mám tu drzost tvrdit, že spálená svíčková servírovaná s pečenou podrážkou je špatné jídlo. A ti dva lidé, kterým taková věc chutná, na tom moc nezmění. Neptejte se těch dvou, jestli máte uvařit lepší jídlo. Ptejte se těch, co říkají "proboha, to snad nemyslíte vážně, tohle jíst". To byla první pointa, a teď ještě jedna. Kdo rozhoduje o tom, jestli je interface kvalitní? V případě komerčního produktu zjevně zákazníci, kteří si produkt kupují. Když produkt zákazníkovi nevyhovuje, firma nemá tržby, nevydělá, nezaplatí lidi, produkt skončí (často spolu s firmou). V případě Gimpu (a řady dalších) má produkt kvality té spálené svíčkové s podrážkou, grafici Gimp štítivě obcházejí a platí raději desítky tisíc za Photoshop, ale podle vás je vše v pořádku, a já jsem drzý, že si dovolím říci, že je král nahý. Víte, co Gimpu chybí? zpětná vazba penězi. Až autoři v důsledku špatné kvality produktu nebudou mít dovolenou, nebudou mít na benzín, nezaplatí nájem, a firma bude před krachem, tak možná začnou pracovat na takovém produktu, který bude zákazník opravdu chtít. A to, že dělají svoji práci dobře, uvidí na tržbách; zákazník zaplatil, protože jsme udělali dobrý SW. Bohužel svět open source tohle neumí. To byla druhá pointa.
Mít zdrojáky je zákazníkům obecně na nic. Chápejte, že mi fakt *nevadí*, když dostanu k produktu navíc DVD se zdrojáky, ale zároveň mi k ničemu není. Nemám čas se hrabat ve zdrojácích OS, office, DB engine, a dalších věcí, protože musím pracovat (stejně tak admin musí pracovat, a ne si hrát se zdrojáky). Navíc open source přináší problém v tom, že vás produkt může kdokoliv opsat, když má k dispozici zdroják. Konkrétně v případěGPL stačí, abyste prodal/dal SW jedinému zákazníkovi, a ten ho pak už může libovolně šířit dále, z čehož vy už nebudete mít ani korunu. To není moc kompatibilní s businessem, že?
V případě integrace je hlavně dobré mít technickou dokumentaci. Pokud jí máte, na co potřebujete zdroják? Řešit chyby v cizím SW má autor toho SW, protože zná své zdrojáky (mimochodem nastudovat nějak zdrojáky všech produktů, které používáte ve firmě, asi fakt nechcete - nemáte dost lidí ani času), a je schopen ke změnám poskytovat support.
Když pošlete mail vývojáři OSS komponenty, jak máte smluvně zajištěno, že vám vůbec odpoví, nebo že bude problém nějak řešit? Když to totiž nemáte zajištěno, tak jde o sázku do loterie. A že vám náhodou někdo odpověděl? To je super, ale asi je to jen proto, že jeho produkt používá tak málo lidí, že si náhodou může dovolit se vámi zabývat.
