Tak jsem tu knihu prolistoval a jenom kroutim hlavou. Nevim teda, jak je ta kniha stara, ale mam dojem, ze snad autor si chtel vybit zlost, ze mu neco nejde.
Jinak ja sem za to rad, ze muj system ocekava, ze vim, jak funguje hardware, jadro, jak se zavadi program atd... a nesnazi se mi to zamaskovat za neco, co by mel pochopit kdokoliv. To by akorat vedlo ke zmatku a nejasnostem.
Bohužel většina uživatelů Linuxu zná jen konkrétní utility a konfiguráky. To je totiž jen kapota, interface pro uživatele sedmdesátých let. Principy jsou tam uvnitř, na úrovni API, threadů, kernelu, modulů, plánovače, správy paměti, IPC, obsluhy přerušení atd. Průměrný uživatel Linuxu zná syntaxi stovky utilit, umí ovládat vi, ale o vnitřnostech Linuxu toho ví stejně málo, jako uživatel Windows o vnitřnostech Windows.
Tak namátkou, věděl byste bez dotazu Googlem, co je major a minor number, a k čemu slouží? Věděl byste, jak je realizovaná obsluha přerušení, nebo jak volání API propadne z kódu aplikace do kernelu? Vy možná ano, ale s utilitami a konfiguráky to nemá nic společného, a řada uživatelů Linuxu prostě nebude vědět.
Samozrejme to vim, obcas profesionalne programuji v kernel space. Dost veci jsem vedel i nez jsem s programovanim zacal, v te dobe to ale vedel skoro kazdy uzivatel linuxu. Podle meho nazoru bezny uzivatel nema system spravovat, jen pouzivat. Na spravu si ma zaplatit profesionala. Kdyz se mi rozbije auto, tak si ho take neopravuji sam.
Jinak major a minor cisla a jak se volaji syscally by mel znat i kazdy spravce.
Se stovkou utilit to je prehnane, odhadl bych to spise na desitky. Vetsinou stejne v jednom okne koukam na manualove stranky.
Na jednu stranu souhlasím. Na druhou stranu si myslím, že uživatel klidně může nainstalovat SW, který chce používat, přidat uživatelský account, nebo nainstalovat tiskárnu. Jen musí existovat dostatečně jednoduchý interface, který mu to umožní. Ono totiž nemá smysl za každou maličkost platit profesionála. Umíte si představit, kolik by bylo třeba těch profesionálů na tak podrobnou správu všech firemních a domácích počítačů? Takhle existují power useři, kteří umí "zkušeně klikat", a o velké procento věcí se postarají. Nakonec se svým autem jedete do servisu také jen když se porouchá (plus na plánovanou maintenance).
Tak instalace tiskarny, USB Mass storage a pod. je treba v KDE na dobre urovni (pokud to distributor nezprzni), tiskarny instaluji relativne casto na notebooku a opravdu se to vpodstate cele udela samo, staci parkrat kliknout mysi.
Pro bezne uzivatele uz je treba horsi instalace grafiky, ale to uz povazuji za vetsi zasah do pocitace, ktery by mel delat ten, kdo tomu opravdu rozumi.
Jedine, co ted brani vetsimu nasazeni linuxu na firemni kancelarske pocitace, je, ze neni mozne (oficialne) provozovat MS Office. Prechod na OO.org je riskantni, protoze neni zajistena 100% kompatibilita.
Zpravicka je zavadejici. Nejde jen o zahozeni xaa, kterou nahrazuje pomalu exa, ale o vytvoreni nove akceleracni architektury uxa. Vse je motivovano vyvojari Intel driveru. Dalsi zajimavosti je, ze TTM memory management bude nahrazen GEM memory managementem, coz je hlavni duvod toho, ze poradny akacelerace pro intel grafiky se dockame az v xorg 1.5.
gem v xorg 1.5 spis nebude. resp. to nezavisi na verzi xserveru, ktery v budouci verzi 1.5 nebude mit nektere veci urychlujici exa architekturu, uxa bude az kdo vi kdy. navic gem dost zavisi na dostupnosti dri modulu v jadre, ktery umi gem, jenze ve 2.6.27 urcite nebude (od rc1 do final to byvaji tak 2 mesice, takze pristi 2 mesice urcite ne, mozna ve 2.6.28, kdo vi).
gem intel driveru je mergnuty do master, takze pristi verze intel driveru bude gem uz umet (2.5). nicmene ma zatim nekolik problemu - pomalost, nefunguje fbc. to predpokladam spravi. nicmene ten driver je dost zavisly na dri z drm-gem vetve a ta je silne dobrodruzna zatim.
Diky za upresneni. Ja jsem to pochopil tak, ze ta pomalost je nejen kvuli gem ale i diky diky exa, proto ta snaha o vytvoreni uxa. Nicmene ta zpravicka uzce souvisi s aktivitami ohledne dri-gem branche a bude to asi jeste nejakou dobu trvat, nez se to dostane do mainstreamu.
-- cut ---
started UXA by just copying the existing EXA code and running an edit script to change all of the names. Then, I went through the code and removed everything dealing with pixmap migration, damage computation or explicit global hardware synchronization. The only synchronization primitive left is the prepare_access/finish_access pair which signals the start and end of software drawing. The hardware driver is expected to deal with all other synchronization issues itself.
------