Odpověď na názor

[116] U podnikových řešení je zásadní věcí podpora, na tom se shodneme.

Co je vám po tom, že distro vychází co půl roku? Je to problém proto, že pro každou novou verzi distra musíte znovu otestovat vydané aplikace, musíte mít testovací systémy a poskytovat podporu. Když vezmete v úvahu počet distribucí a jejich verzí, je to pořádná spousta práce, a to kvůli minimu zákazníků. To je i důvod, proč společnosti typu Oracle a vmware podporují jen pár dister v pár verzích.

Myslíte, že CAD nebo informační systém nemůže být špatně napsaný? Omyl. Jak jsem opakovaně psal, rozšířeným zvykem je třeba vykrádání ikon a animací z knihoven shellu. Jenže knihovna řekněme shell32.dll v nové verzi Windows neobsahuje stejné ikony a animace, nebo vůbec neexistuje (ve Vistě shodou okolností existuje), a aplikace pak spadne. Podobných prasáren předvádějí autoři aplikací překvapivé množství. Viz články linkované zde: http://www.root.cz/zpravicky/porovnani-herni-kompatibility-os/184114/

S certifikací driverů jste mimo mísu vy. Obecně pokud driver není certifikovaný, s vaším OS může a nemusí fungovat. Jediný, kdo tvrdí, že to funguje, je výrobce HW, který driver psal. Jak ho napsal, to je velká otázka - znáte výrobce HW. Já například koupil zvukovou kartu s Dolby Digital Live, která byla v řadě článků vychválená, ale neměla certifikované drivery. Výsledek? Blue screeny v driveru driveru té karty. Totéž u necertifikovaných driverů grafické karty. Podívejte se na detaily WHQL testování. MS vydává stovky stran specifikací, co daný HW/driver musí umět, co by měl umět, a co nesmí, a testy jsou velmi důkladné. Certifikace driverů byla zavedena proto, že nekvalitní drivery jsou odpovědné za 80-90% blue screen chyb, ke kterým ve Windows dojde. Skoro celý doplněk do 100% jsou chyby HW, a naprosté minimum jsou chyby Windows.

Ohledně vašich problémů s WHQL drivery mohu říci dvě věci. 1) problém nemusel být způsobený certifikovaným driverem (a samozřejmě mohl, ale lidé typicky neprovedou analýzu hlubší než "jé ono to spadlo na BSOD"), 2) nic není dokonalé. K paralele s automobily si dovolím opravit to. "Franta měl havárku ve svém Volvu s airbagy, a zabil se. Jenda havaroval ve Škoda 120 bez airbagů, a žije. Z toho plyne, že airbagy jsou na nic."

Databáze na abclinuxu je naprosto k ničemu; má podobnou vypovídací hodnotu, jako to fórum na (l)živě.

Do vyběru file manageru nebo browseru vám mluvit nehodlám. Do závislostí vám hodlají mluvit ty aplikace, kterých se závislosti týkají.

[117] Gnome má Bonobo, což je částečný opis OLE (Miguel de Icaza se s tím alespoň nikdy netajil). KDE má KParts a DCOP, který byl v KDE 4.0 nahrazen D-BUSem. OpenOffice má UNO. Objektů každého modelu existuje pět a půl, OLE ani objektový clipboard mezi Gnome a KDE nefungují. Kupodivu ve Windows je z komponent poskládané skoro všechno, OLE a "inteligentní" clipboard jsou dlouhou řadu let samozřejmostí. Kdo od koho opisoval, to by byla neplodná diskuze :)

Ke Kparts a Konqueroru se vraťme. Popíšete prosím, jak a z čeho je Konqueror poskládaný, jak se registrují rozšíření, a jestli u rozšíření existují callbacky.

U Qt hlavně zamrzí, že to není primární (nejlépe jediný) framework pro Linux, že pracuje nad příšerným X11, že při každém volání překládá své interní UTF-16 stringy do UTF-8 a při návratu z volání zase zpět atd.

Jestli se v Qt vyznáte, ještě by mě zajímalo jedno. Co se stane, když mám na disku názvev souboru v 8859-2? Qt pracuje s UTF-16 stringy, a názvy souborů na disku vždy považuje za UTF-8. Návez v 8859-2 je ovšem neplatnou UTF-8 sekvencí. Co se pak stane? Znamená to, že Qt aplikace neumí otevírat soubory, které mají názvy v 8859-* (a obsahují znaky s kódem 128 a výše)?

[118] Skvěle, 4 rozšíření pro Nautilus. Není to sice hodně, ale počítá se to. Popíšete prosím trochu podrobněji, co je pod pokličkou?