KDE printer-applet, olcsó a ram

Ha már szóba került az előző topicban, hogy miért eszik közel 40 mega ramot egy printer applet, gondoltam csak megnézem, mi is ez. Mert ugye biztos a lehető legoptimálisabban, és bloatware mentesebben van megírva, és biztos nincs felesleges layerek össze-vissza hivogatva. No de ne szaladjunk ennyire előre.

Nosza, menjunk fel az oldalára, sasoljuk már meg mi is ez.

"Printer Applet is the first application in the mainline KDE modules to be written with PyKDE."

No, nézzük, mi is ez a PyKDE? Alapvetően a PyQt-hez ad pár KDE specifikus dolgot. Jó, ez még valóban hasznos dolog lehet, ha már a KDE többi részétől eltérően húzunk egy pythont és egy wrappert is a C/C++ fölé/mellé, hátha így még intuitívabb, könnyen használhatóbb és tanulhatóbb meg olvashatóbb, karbantarthatóbb, mint a Qt/C++ kód.

Node nézzük tovább a README fájlt. Aszerint kell neki PyKDE4, PyQt4 (ez tiszta sor volt már eddig is), pycups (mert nyílván kell valami köztesréteg, hogy pythonból is elérjük az eredetileg C-ben írt dolgokat...) és hal-cups-utils (OFF: Fontosnak tartom megjegzezni, hogy eddig az első oldal, ami HTTPS-l érhető el!).

No, akkor nézzünk, miből főzünk eddig. Van egy halom köztesrétegünk, ami adódik abból, hogy nem a KDE-ben széles körűen alkalmazott Qt féle C++-t használjuk, hanem Pythont, mindezt egy egyszerű ablak egy ikon és egy lista kirajzolásához. (Maradjunk annyiban, hogy időben viszonylag nehezen minimalizálható feladatról van szó, lévén, C++-ban sem sokkal több, arról nem is beszélve, hogy van összekattintgatós cucc is Qt-hez, amivel pikk-pakk össze lehet hozni 0 hozzáértéssel). Adott továbbá egy köztesréteg, ami arra szolgál, hogy Pythonból elérjük a CUPS-t és egy utilunk, amivel a HAL-ból kérdezgetünk a nyomtatók iránt. Ez utóbbinak megléte még egész indokolható, mert valahogy mégis csak nem ártana információt kapnunk a nyomtatókról.

De a teljesség kedvéért tegyünk egy kis kitérőt, hogy mi is ez a HAL. A HAL - mint ahogy a neve is sugalja - egy absztrakciós réteg a hardverekhez, alapvetően arra van, amire az összes többi absztrakciós réteg: elrejti a különbségeket és egy egységes felületet nyújt az alkalmazások felé. Mi ezzel a probléma? Alapvetően semmi. Ugyanezt csinálja a kernel is. Ha valakinél elkezd villogni a redundancia checker és felteszi a kérdést, hogy jó, de akkor minek HAL és miért nem system callokkal használ minden?

A kérdés teljesen jogos: alapvetően a tradicionális modell szerint egy számítógépben nem nagyon pakolászták ki-be menet közben az alkatrészeket. Ez ugye a különféle hot plug megoldásokkal eléggé megváltozott és a tradicionális rendszerhívásokkal vagy vagy IPC-vel nem volt annyira jó megoldani, ezért kellett egy új megoldás, így jött az új réteg a régi modernizálása helyett (igaz, utólag csak meglépték azt is). Bár még ezzel sem lenne annyi gond, leszámítva, hogy manapság HAL az deprecated, mondván "become a large monolithic unmaintainable mess", szóval legalább itt visszatértünk a devfs udev-hez.

Node mindegy, vissza a csuda pythonos programunkhoz. hal-cups-utils-hoz van még egy kis megjegyzés:

"hal-cups-utils needs the common parts of system-config-printer (cupshelpers/*, ppds.py, probe_printer.py):
http://cyberelk.net/tim/software/system-config-printer/

Note to packagers: system-config-printer is a Gnome app, please split
out the parts needed by printer-applet "

Parancsolsz? Emeljünk át egy GTK-s programból részeket? Na mindegy, szerencsére csak részek, biztos nem kell hozzá GTK. Mondom, ugye, nem kell még GTK-t is betölteni nekünk? Hát persze, hogy kell!

Továbbá azt sem értem, hogy a KDE-hez írt programban mit keresnek GTK-s dolgok, ha már egyszer PyKDE-ben lett elkezdve az egész.

Gondolom még csak véletlenül sem annak a következménye, hogy trehány módon "mindegy honnan van összeollózva" és "dehátapythonegyolyanaranyosnyelv" elvek szerint lett ez a remek szoftver megírva, mondván, hogy úgy is occsó a ram. És azt se mondja már senki, hogy ez a több tonnányi köztesréteg is a semmiből születik.

Valahogy nem érződik az egészből a KISS elv...

Hozzászólások

Az udev pedig nem csinál mást, mint a devtmpfs-en elvégez pár módosítást. Gyakorlatilag a hal után egyből mehetne a kukába az udev is, ha a kernelbeli devtmpfs-t lehetne egy picit finomhangolni sysctl-lal.

--
Don't be an Ubuntard!

Remek összefoglaló. Az ilyen mentalitás miatt váltottam OS X-re, ott legalább többnyire értelmes, és konzisztensen működő dolgok vesznek el disznó sok RAM-ot, nem pedig a fogyatékosok agyatlan szarjai.

(eme IT-t pusztító rák egy másik előfordulási esete)

Kösz az összefoglalót, jól esett ez így reggel. Azt csak közbevetőleg kérdem meg, hogy ezek szerint ez a csodálatos, új (?), innovatív KDE-applet rögtön meszületése (vagy hadrendbe állítása) pillanatában máris egy elavult/meg-fog-szűnni réteggel (az a jó kis HAL) gazdagítja azon szerencsések rendszerét, akik használják? Ez azért biztató, mert ha sok ilyen lesz még, akkor rövid úton visszakerül a HAL támogatása az XFCE-be, és ismét lehet "automountolni" FreeBSD-n is :-)

jo kis autoloader Qt/KDE-hez, Pythonhoz, sot meg GTK-hoz is. Ezutan mindenfele app pillanatok alatt elindul...

Ambivalens érzéseim vannak:
Egyrészt kellemetlen, hogy ilyen összehányt dolgok végeznek alapvető feladatokat.

Másrészt viszont baromira bírom, hogy ha nekem kell összedobni valamit hirtelen, akkor rendelkezésemre áll ez a lehetőség:

nincs rám erőltetve egy programnyelv, script nyelv, library -> mert már korábban a hasonló mentalitást követő emberek szinte páronként minden között írtak egy-egy kompatibilitási réteget... ;)

Sajnos rengeteg ilyen van meg (es nem csak open source). Igazan ritka a jol megirt szoftver :(

tragikus. gondolom, nem ez az egyetlen ilyen app a KDE worldben.

Remek

Kellene egy programozó hadsereget ráirányítani ezekre az apróságokra, mindjárt szebb lenne a világ, ha az ilyenek ki lennének gyomlálva :)