Administrace komentářů

Pokud ve Windows něco jde pomalu, Microsoft zrubá architekturu nějakým bastlem, přidá nějaké cachování a drobné podvůdky a najednou to funguje rychle. U Linuxu toto neexistuje. Není žádná možnost, jak by vývojář OpenOffice přesvědřil vývojáře kernelu, že mu to pomalu startuje a že se musí krásná architektura trochu přiohnout, nacpat sem tam pár výjimek, něco nacpat přímo do kernelu, aby se start zrychlil. Do Windows se klidně dobastlí přepínač, jestli je stanice desktop nebo server a tomu se přizpůsobil memory management a třeba cachování. V Linuxu nic takového není, stejné jádro musí stačit pro jakékoliv použití a komu se to nelíbí, ten má smůlu.

To není pravda (hint: sysctl, sysfs, -ck patchset a jeho /proc/sys/kernel/{interactive|compute}).

Proto třeba ten neskutečně pomalý start aplikací v X Window.

To jako vážně?

1. Já bych nechtěl mít v jádru nějaký ugly hack, který umožní startování grafických aplikací rychle, ale třeba na multiprocesoru nebo preemtible kernelu se tím vytvoří deadlock, který se někdy může projevit (něco takového je třeba devfs, ikdyž ten řeší zrovna celkem praktickou věc).

2. Jak si vlastně představujete takový hack, který zrychlí start xových aplikací? Není to tím, že prostě ty aplikace jsou špatně napsaný a nějaký hack v jádře by jim nepomohl?

Třeba WIN32 API. Bastl nad bastl, ale je to rychlé. Proti různým elegantně navrženým GTK a QT neskutečný rozdíl. Pohodlnost programátorů zvítězila nad uživatelem. Skoro se na něj zapomnělo.

Pokud nebude mít programátor pohodlí, bude trořit pomaleji a s chybami.

A to je důvod, proč Windows 95 s Office 97 fungují na Pentiu 400 s 64MB paměti stejně dýchavičně, jako Open Office s KDE a Linuxem na Pentiu 4 2.5GHz a 1GB paměti. Microsoft má jako hlavní modlu spokojeného uživatele desktopu, Linux technickou dokonalost.

Openoffice jako vzor technické dokonalosti? Huh.