KDE printer-applet, olcsó a ram

 ( saxus | 2011. március 31., csütörtök - 2:29 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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!

+1

--------------------------------------------------------------------------
színes

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)

+1
ez tetszett

+2
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos

+1
a GTK belekeverese durva facepalm...
ez a printer applet amugy resze a hivatalos KDE csomagnak? mert akkor valakit a KDE-nel nagyon tokon kell rugni
-
Slackware current / OSX Snow Leopard

+1
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

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 :-)

hal xfce-ben? 4.8-ban már nincs? jééé...

"foss kvaliti"

~1

cserébe open source, ha nem tetszik készíts jobbat ;)

igen, csak a gond ott kezdodik, amikor ezt komolyan is veszik es csinalnak egy masikat az elozo melle, majd felbehagyjak mert megunjak, igy nyilvanvaloan az se fog valakinek tetszeni, es az majd csinaljon jobbat (goto "komolyan veszik")

Nice...

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... ;)

Cserébe az ember sosem fogja megtudni, hogy milyen gyors is (tudna lenni) igazából a gépe.


Ne kattints ide!

Nem is az, hanem hogy az absztrakciós rétegek fele azért készült, mert az alatta levő rétegbe nem voltak képesek leimplementálni azokat a funkciókat amikre szükség van.

--
Don't be an Ubuntard!

Amik egyébként egy alattuk lévő absztrakciós réteget fednek el egy wrapper felett...

----------------
Lvl86 Troll

Jo lehetoseg, hogy osszedobj magadnak valamit, de nem arra, hogy (mondjuk) hivatalos KDE-be keruljon.

+1
-
Slackware current / OSX Snow Leopard

gondolom a poszt írása több idő volt mint ennek az összerakása :)

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

pötty

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

s/KDE/open source/

----------------
Lvl86 Troll

nem, en most csak a kde-rol beszelek. multkor par napig hasznaltam, de neha majd megorultem, a top miket adott ki.

a GTK vilaga se semmi neha azert :)

Aucs.

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 :)