Szokásos, havi tesztünkben a Slitaz nevű minilinux terjesztést vizsgáltam meg közelebbről. Előre nem lövök le semmilyen poént, de sok helyen dicsérték a Slitazt, főleg hogy a döbbenetesen kicsi, 25 Mb-os méretű ISO fájlhoz képest még egy PHP-s Lighty webszerver és egy SQLite is belefért. Ez már önmagában nem semmi teljesítmény, hiszen képzeljük csak el, akárcsak egy 512Mb-os USB penre kiírva simán tud egy teljes website-ot szolgáltatni (amennyiben nem MySQL adatbázist használ, hanem az SQLite-ot, ami valljuk be, elég sok esetben bőven elég), csak RAMot kell adni neki.

Ugorjunk a gyakorlati részre! Miután a CD-ről elkezdett bootolni, kicsit felcsúszott a szemöldököm, mert először is ékes francia nyelven indul a dolog, majd szöveges képernyőkkel néztem farkasszemet: A hangkártya és a nyelv kiválasztásával. Persze 25 megától mit is várok? A boot végülis sikerült, a slim bejelentkező után a jwm ablakkezelő és az lxpanel indul el. Az általános összkép elképesztően siralmas: A jwm hagyja, hogy az ablakokat a panelre nyissam, a használt fájlkezelő (emelfm2) nem is kényelmes, de ráadásul a szokásos kétpaneles fájlkezelők billentyűkombinációit még távolról sem alkalmazza; az F5 például a törlés (!). Sokkal jobb lett volna, ha az Mc-t teszik be helyette. Gondolom, ilyen pici méretben nem igazán fér el a dbus és a hal, tehát automatikus média felismerést, csatolást nem is vártam, de a TinyME-vel ellentétben itt írtak a fejlesztők egy saját (szerintem gtkdialog-os) mount programot, aminek segítségével fel tudjuk csatolni grafikus felületen a dolgokat. Köszönet érte!

	Balra látható, hogy milyen körülmények között kell nyelvet választanunk.
	Majd a hangkártya választás...

Hasonló módon a hálózati kártya beállítására is van egy picike grafikus tool, ami sajnos a vezetéknélküli hálókártyákat hírből sem ismeri (igazából nem is ennek a toolnak kéne ismernie, hanem a kernelnek, illetve legalább a boot scripteknek illene felismernie).

További alkalmazások: Firefox 2.0.0.12 (!!!), elég régi de meglepően gyorsan elindul. A levelezőprogramot (gitmail) az elindítás után gyomorgörcs kíséretében azonnal bezártam. Ez szörnyű... sokkal jobb lenne egy Pine.

A beállításokat az említetteken felül szövegfájlokban, vagy szöveges dialógusablakok segítségével, terminálban kell megtennünk. Ha valaki keni-vágja az .Xresources vagy a .gtkrc formátumát, akkor persze ez nem gond...

A (karakteres) telepítő szintén francia nyelvű. Bár nagyjából lehet követni, hogy mit akar, hiszen az informatikai kifejezések eléggé nemzetköziek, de én mégsem mertem megpróbálni a telepítést, ezért a telepített rendszerrel kapcsolatos pontszámokat nulláztam.

A csomagkezelést saját csomagtípussal, és -kezelővel oldották meg, tazpkg a neve. Természetesen teljesen ismeretlen volt számomra, de kis idő után belejöttem; frissítettem a csomaglistát majd megpróbáltam a thunderbirdöt telepíteni, sajnos ez nem sikerült, mert nem találtam semmi ilyesféle csomagot. Talán nincs benne a repójukban?

 (Kattints a képre a teljes méretért)

Irodai alkalmazásokból csak az ePDF olvasó jutott; általában a laptopos dolgokból semmi nem működött. Jellemző, hogy az lxpanelhez be lehet állítani az akksi állapotjelzőjét, de ez nem működött, mert kernel szinten is kellett volna hozzá támogatás.

A magyar nyelvi dolgokkal kapcsolatban: nem sok. Leginkább semmi. A betűkészlet hosszú ő és ű betűje láthatóan valami default készletből származik (lásd a képet), de legalább megjelenik, nem úgy mint a Siduxnál.

Összefoglalás

Más már nem maradt, csak hogy összefoglaljam a dolgot. Ami tetszett, az az, hogy valaki egy ennyire kicsike linuxot tud karbantartani még manapság is. Értelemszerűen ebből adódik az, ami nem tetszik: ekkora méretben képtelenség valami szépet, látványosat alkotni. Desktop felhasználásra semmiféleképpen nem ajánlom, de webszervernek jól jöhet. Az alkalmazások összeállítása szerintem nem túl ideális: Firefox helyett egy sokkal kisebb Opera lenne jó, cserébe a megüresedett helyre a GitMail helyett fel lehetne tenni egy Claws levelezővel. Az emelfm2-t simán dobnám az mc kedvéért, hiszen az még ftp-t is tud. Ezen felül lehetne erősíteni a szerver dolgokra; pl. egy grafiksu tűzfal és egy cron beállítóval, cserébe el lehet hagyni az Osmo naptárkezelőt és az mtPaint nevű, elég basic képszerkesztőt.

Azt már tudjuk, hogy a rendszerre fordított kernellel fel lehet gyorsítani a boot idejét. Milyen egyéb furfangokat tudunk bevetni?

Első ötlet természetesen az, hogy ami nem kell, kapcsoljuk ki. A probléma ezzel csak az, hogy ezzel kapcsolatban képtelenség általános tanácsokat adni, hiszen mindenkinek másra van szüksége. Akik ilyen tanácsokat írnak, azzal kezdik, hogy "ne egy az egyben vedd át, hanem csak azt tiltsd le ami neked nem kell", de a "delikvens" éppen azt nem tudja, mi nem kell neki.

Én azt mondom, először legyünk tisztában azzal, hogy mi eszi rommá a processzort, illetve a diszkeket, és ennek tudatában majd döntünk arról, hogy szükséges-e nekünk az adott szolgáltatás. Emellett jó, ha fel tudjuk ismerni, hogy mikor malmozik a gép, mikor vár valamilyen folyamat lezárására üresjáratban. Az csak természetes, hogy Linuxon fogunk erre céleszközt találni...

Első lépésben tehát a boot folyamat gyorsításában (még a kernel csere előtt!) tudjuk könnyedén hasznosítani a bootchart nevű kis programocskát. Ez egy teljesítmény-analizáláshoz használatos, évek óta meglévő program, de talán pár embernek még újdonság. Ami nagy előnye, hogy grafikusan, ráadásul nem valami elvont, absztrakt formákkal, hanem jó lérthetően ábrázolja a boot folyamatot. Hátránya, hogy kicsit sok erőforrást eszik ahhoz képest, miközben adminisztrálja a dolgokat.

Mit is csinál a program pontosan? A lelke egy egyszerű script, amely két tized másodpercenként elteszi a /proc/uptime fájlból azt, hogy mióta bootolunk, illetve a /proc/stat, /proc/diskstats fájl tartalmát; illetve minden futó processzről begyűjti a statisztikai információkat (ez mindig a /proc/ <PID>/stat fájlban található). Ezeket a stat fájlokat a linux kernel folyamatosan frissíti, és ezekben minden fontos teljesítmény-adat megtalálható a processzekről. A boot folyamat végén pedig egy Java programmal a begyűjtött adatokból grafikont készít, mégpedig EPS, SVG vagy PNG kimenettel.

Mivel értelemszerűen a programot a boot folyamat legelején kell elindítani, ehhez vagy a boot scripteket, vagy ha van initrd, akkor azt kell módosítani. Az Ubuntu használ initrd-t, a program telepítésekor le is generálódik automatikusan a nekünk kellő változat (ezért használjuk a kernel csere előtt a bootchartot). Így aztán a telepítés igen egyszerű:

root@pujka:~# apt-get install bootchart

Ezek után nincs is más dolgunk, mint újraindítani a gépet, majd a boot végeztével bekukkantani a /var/log/bootchart/ könyvtárba, a legfrissebb dátumú fájlt keresve.

Mivel ez méretes képfájl, csak az elejét rakom ide, hogy mutogathassak (így is rájuk kell kattintani a nagyításhoz!):

Az egésznek a tetején van a legfontosabb rész, ahol a CPU és az I/O wait értékeket olvashatjuk le, itt látható hogy hol dolgozik a gépünk teljes erőbedobással, és hol pihenget a boot során. A vízszintes az időtengely, ez világos. A kék a CPU, a piros az IO. Magyarul ha mindkettő alacsony, akkor gépünk vár valaminek az eredményére, és egyáltalán nincs kihasználva a teljesítmény. Ha a CPU magas, akkor ott keményen dolgozik, ha az IO a magas, akkor pedig azt jelenti, hogy túl sok mindent akar egyszerre írni a lemezre/olvasni a lemezről, ezért ezek az írások egymásra várnak.

• A magas CPU használaton nem tudunk segíteni értelemszerűen, hiszen a boot során vannak számításigényes dolgok; sőt éppen az a jó, ha a processzorhasználat magas, mivel akkor van jól kihasználva.
• A magas IOwait nem annyira jó (főleg ha a CPU alacsony, ez általában együtt jár), ez azt jelenti hogy hiába dolgozna a processzor, meg kell várnia amíg a diszkre kiírásra, vagy a diszkről beolvasásra kerülnek az adatok. Megoldás: gyorsabb diszk, vagy a boot sorrend megváltoztatása, hogy kicsit "kiegyenlítődjenek" ezek a dolgok. Na ez utóbbival sokat foglalkoznak az egyes linux terjesztések készítői, és jelentem, egyelőre nem tudunk üdvözítő megoldásról (hiszen ki tudja, a drága felhasználó éppen milyen szolgáltatásokat szeretne használni. Optimalizálni legfeljebb a leggyakoribbakra tudnak).
• Ha alacsony a CPU és az IO is, az a legrosszabb, hiszen várunk, várakozunk valaminek az eredményére, legtöbbször akkor van ha valamilyen egyéb hardver csak komótosan válaszolgat az inicializálásra, illetve hardver felismerés esetén.

Ha lejjebb tekintünk, akkor látjuk a processzeinket, amelyek a megfelelő időben indulnak el. A legfelső grafikon és a processz lista alapján össze tudjuk nézni, hogy melyik processz milyen erőforrásokat eszik. Példánkban:

1. Egy másodpercig minden oké, elindul az initrd-ben az init, elindítja a busyboxot, ami meg az usplasht (ez teszi ki a gyönyörű Ubuntus boot logót). Amúgy az usplash soron látjuk, hogy a boot logó kirakása kér egy kis processzor-időt (kék csíkocska), de utána már nem nagyon kér enni.
2. Ezek után négy másodpercig a gépem csont semmit nem csinál, a második init (ez már nem az initrd-s) által indított modprobe eredményére vár, azaz húzza befelé a kernel modulokat szépen. (Itt rögtön van is lehetőségünk gyorsítani, ha pár dolgot kernelbe fordítunk.)
3. Igazán a hetedik másodpercben indulnak be a dolgok (végre!). De egyből ott egy nagy IOwait... nézzük csak, ott van hogy rc -> S01readahead -> readahead-list, na annál látszik a hosszú piros csík. Mit csinál ez? A /etc/rcS.d/S01readahead tartalma elég semmitmondó, de az apt-cache show readahead már ad infókat. Ezek szerint ez éppen arra szolgálna, hogy előre a memóriába töltsünk bizonyos fájlokat, ezzel meggyorsítva bizonyos programok elindulását. Kisvártatva kiderül, hogy a /etc/readahead/boot fájlban felsorolt függvénykönyvtárakat és binárisokat cache-eli a memóriába, a későbbi gyors futás érdekében. Hát ezért ez a nagy IO! Mindenesetre ebből a fájlból akár bőven szemezgethetnék is, egy nagy rakás dolog nekem nem kell belőle, de menjünk tovább.
4. Az látszik, hogy a 15-20 másodperc közötti időszak egyértelműen az udevd "felségterülete". Ez azt hiszem, mindenkinek világos, hogy nem kikapcsolható, hiszen ez a kernel eseményeket a felhasználói területtel összekötő daemon és szkriptek gyűjteménye; ráadásul jól kihasználja a processzort, szóval probléma nincs. Ami érdekes, az az udevadm alatt lévő sleep-ek: ez a kis parancssoros program nem csinál mást, csak scriptekben mesterségesen várakoztat. Van nekünk erre szükségünk? Annyi szent, hogy a /etc/init.d/rc indítgatja... nézzük, mi van benne!

Hmm, ugyan a sleep értelmét nem találtam meg, de van itt egy érdekes opció az /etc/init.d/rc-ben:

# Specify method used to enable concurrent init.d scripts.
# Valid options are 'none' and 'shell'.
CONCURRENCY=noneNosza, állítsuk át "Shell"-re! Utána jöhet egy reboot, majd döbbenten láttam, hogy egyből találtam 3 másodpercet. Íme a két bootchart egymás fölé téve, csak a legfelső grafikon:

 (kattints a képre a teljes mérethez)

A lejjebb lévő részletezésből, ami most nem vágtam ide, az látszik, hogy valóban az rc párhuzamosan indul; és az ebből adódó csúnya dolgokat (pl. hogy valami előbb indul, minthogy a hozzá szükséges dolgok előtte elinduljanak) pedig szintén sleep-ekkel hidalták át.

Végülis nekem a lényeg az, hogy a bootchart segítségével 3 másodperccel gyorsabban bootol a gépem, ezzel kevesebb energiát fogyaszt, tehát védem a környezetet és a globális felmelegedés ellen dolgozom. :-)

Elhatároztam, hogy az eddigi random, "ami-épp-eszembe-jut" módszerek helyett összerakok egy kis egyszerű módszertant, hogy a továbbiakban hogyan szeretném kirpóbálni a különféle disztribúciókat (az eddigi Sidux, TinyME, PUDLinux és gOS tesztek eléggé össze-visszára sikeredtek). Ez a kis sorvezető nekem is jól jön majd a jövőben, illetve számonkérhetitek, ha valami hiányzik... ;-)

A számok, amiket zárójelben írok, számomra az adott dolog fontossága: (1) = jó, ha van/működik, (2) = fontos a megléte, (5) = nagyon fontos

1. LiveCD Boot, telepítés
1.1. Sikerült-e alap beállításokkal eljutni a GUI-ig? Ha nem, mennyire egyszerű a javítás? (5)
1.2. Indítás sebessége (2)
1.3. Felismert/nem támogatott hardverek (5)
1.4. Általános kép
1.4.1. Rápillantva mennyire kívánatos? (1)
1.4.2. Mennyire stabil, van-e alkalmazás ami kifagy? (2)
1.5. Széleskörű grafikus beállítások
1.5.1. CPU frekvencia állítás (2)
1.5.2. Wi-fi (2)
1.5.3. Akku töltöttség jelző (2)
1.6. Készenléti állapot/hibernálás gyorsasága, stabil működése (2)
1.7. A telepítés időszükséglete
1.7.2. Mennyire bonyolult a beállítás (mennyi ideig tart bekonfigolni a telepítőt?)
1.7.3. Magának a telepítésnek az időszükséglete

2. Feltelepített rendszer
2.1. Sikerül-e alap telepítéssel eljutni a boot képernyőig? (5)
2.2. Indítás sebessége (5)
2.3. Alapértelmezett alkalmazások stabilitása (2)
2.4. Magyar nyelvi támogatás
2.4.1. Betűkészlet megfelelő? (5)
2.4.2. Megszólalnak-e az alkalmazások magyarul/félmagyarul, vagy csak angolul? (1)
2.5. Egyszerű, napi feladatok támogatása (mennyire egyszerű? Ezt is idővel mérném)
2.5.1. Csomagkezelés (a csomagkezelés kitapasztalása, felrakás és eltávolítás) (5)
2.5.2. Samba megosztás / felcsatolás (2)
2.5.3. Pen drive, CD/DVD lemez automatikus felcsatolása (5)
2.5.4. Email fiókok bekonfigurálása és levelek ellenőrzése (5)
2.5.5. Flash és Java telepítése a böngészőbe (5)
2.5.6. Word, Excel, Adobe Acrobat, OpenDocument doksi megnyitása (5)
2.5.7. PHP, C, Perl fájlok megnyitása, szerkesztése (2)
2.5.8. CD/DVD írás fájlokból (2)
2.5.9. CD/DVD írás ISO és BIN/CUE állományból (1)
2.5.10. MP3, WAV, AVI (MPEG4/MP3), QT9, VMW, FLV, RM megnyitása (2)
2.5.11. SSH szerver/kliens (1)
2.6. Grafikus beállítások lehetősége
2.7. Készenléti állapot/hibernálás gyorsasága, stabil működése (2)

A mérések, illetve szubjektív vélemény alapján 0-3 között fogom értékelni a pontokat, a kapott értéket megszorzom a súlyával és a végeredményt összeadom.

Ha valami ötletetek van, nyomjátok és hozzátódítom. :-)

Sem sci-firől, sem zenekarról nem lesz szó. :-) Történt egyszer, hogy a Bell Labs 1985 - 2002 között elkészített Plan9 néven egy operációs rendszert, amelyet a UNIX utódjául szánt, és házi berkekben be is vezetett.

Az OS érdekessége, hogy hálózaton elosztott fájlrendszert használ, valamint a különféle rendszerkomponensek elérése fájlokon keresztül történik (mondhatnánk, hogy "ahogyan a UNIXoknál és klónjaiknál, és a Linuxnál is", de egy sokkal általánosabb felületet kell elképzelni, ahol mondjuk a diszkek, vagy bármely hardver és a képernyő kezelése ugyanúgy egy hierarchikus fájlrendszerben zajlik, nincs specializált (programozói) felület pl. ioctl), és egy saját fejlesztésű protokoll segítségével elérték a munkaállomás-független munkavégzést (azaz a felhasználónak nem kell tudnia, hogy egy erőforrást a helyi gép, vagy valamelyik távoli szerver bocsát a rendelkezésére). Ezen kívül rengeteg fejlesztést beleöltek, többek között az UTF-8 karakterkezelést is itt valósították meg, de igazából ez a post nem a Plan9-ról szól.

A Plan9 rengeteg ötletet, új elgondolást tartalmazott, és sokan kaptak ebből inspirációt. Például az összes mai "minimalista" window manager Linuxra a 9wm ablakkezelőből fejlődött ki, vagy legalábbis a szerzőjük onnan kapott ihletet. A 9wm pedig a Plan9 window managerének klónja volt. De a fájlrendszer design is sokakat foglalkoztatott, így született meg például a glastree backup projekt is.

Elérkeztünk végre a mai programponthoz... :-)

GlasTree

Ahogyan a weboldalon is írják, a "szegényember napi snapshot gyártója". Nagyon egyszerűen működik: első alkalommal teljes mentést készít, majd pedig csak inkrementális mentéseket a változott fájlokról, azonban minden mentést (snapshotot) külön könyvtárba tárol el, és a nem változott fájlokat hardlinkeli. Azaz egy fájl változás után egyszer ment, majd ha a következő snapshotig nincs változás, akkor csak belinkeli az utolsó változatot. Ezzel helyet spórol, és mégis "teljes" live mentések készülnek minden esetben. Zseniális... Emellett természetesen biztosítani tudja, hogy egy bizonyos megőrzési idő elteltével törölje a régebbi snapshotokat, azaz egy "vándorló ablak"-ot kapunk a legutóbbi X nap mentéseivel. Használata rendkívül nehéz:

root@bicigli:~# mkdir mentesek
root@bicigli:~# glastree <mentendő könyvtár> mentesek

..és a mentesek alá elkezdi elkészíteni a 01, 02 stb. könyvtárakat. A man-jából egy példa arra, hogy hogyan mentsük automatizáltan, cronból a levelezésünket, a legutolsó 35 napnyit megtartva (ezt ugye a crontab -e futtatása tán kell beírni):

0 4 * * *  glastree Mail /backups/bagoj/Mail ; \
               glastreeprune --days=35 /backups/bagoj/Mail | xargs -- rm -fr

Ez a kis apróság sem teljes partíciók, sem élő rendszer mentésére nem alkalmas, de igen sokszor tud életmentő lenni. Ha valakinek nem tetszik a Perl, van egy Ruby megvalósítás is, pdumpfs néven.

A Vakulj Paraszt, Inc. :-) legújabb tanálmánya a PicLens nevű, amúgy fantasztikusan jól kezelhető Firefox plugin, ami egyelőre sajnos csak Windows-os FF alól érhető el. Képzeljük el, hogy a megfelelően előpreparált weboldal képeit 3D-s, forgatható, egy szem egérrel könnyen kezelhető felületen nézhetjük.

Mint a bevezetőből is kiderült, ezúttal nem egészen Linuxos dologba kezdtem bele, de mivel a megvalósítás történhet linuxon is, valamint érdekesnek tartom a témát, belevágtam. Nemrégiben mutatta meg az ismerősöm ugyanis ezt a PicLenst - sajnos Wine alatt futó FF esetén sem megy, mindenképp Windows kell hozzá. De ha élvezni nem is tudjuk az effekteket, mások számára lehetővé tehetjük, ezzel vonzóbb lesz a weboldalunk.

 A PicLens ugyanis RSS-folyamainkban kotor nagy erőkkel mindenféle képek után. Feladatunk mindössze annyi, hogy egy olyan RSS-folyamot állítsunk elő, amely kompatíbilis a PicLens-sel (ehhez a Yahoo által 2004-ben publikált RSS kiegészítéseket kell használnunk. Ezzel nem sértjük meg a szabványt, mindössze ellátjuk speciális címkékkel az egyes elemeket).

1. feladat: RSS folyamunk előállítása

1. Az RSS ugyebár nem más, mint egy puszta XML fájl, jól meghatározott nevű tagokkal (azaz egy kötött DTD van hozzá, hiányos emlékeim szerint). Ebben mindenképpen meg kell adnunk a következőket:
2. Milyen speciális XML névtereket akarunk használni (nyugi, ezekre mindjárt nyomom a példát)
3. Mi most épp egy RSS fájlt írunk (<rss> tag)
4. Amelyben egy csatornát hozunk létre (<channel> tag, ez lesz egy kép album)
5. A csatornába pedig belesoroljuk az itemeket (azaz az egyes képeket)

Itt a példa:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<rss version="2.0" xmlns:media="http://search.yahoo.com/mrss" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Erdélyi vakáció</title>
        <copyright>Creative Commons Non-commercial (nc), Mister Owl</copyright>
        <item>
            <link>erdely2008/01.jpg</link>
            <title>Az elindulás</title>
            <media:thumbnail url="erdely2008/thumb_01.jpg" />
            <media:content url="erdely2008/01.jpg">
        </item>
        <item>
            <link>erdely2008/02.jpg</link>
            <title>Az autópályán megálltunk iddogálni...</title>
            <media:thumbnail url="erdely2008/thumb_02.jpg" />
            <media:content url="erdely2008/02.jpg">
        </item>
    </channel>
</rss>Nekem elég egyszerűnek tűnik... :-) Mivel ismétlődő elemekről van szó, ezt akár egy egyszerű szkripttel is elő tudjuk állítani - az egyetlen nehézség, hogy a képekhez tartozó leírást, illetve az egész albumnak a nevét honnan szedjük. Egy barátom erre egyből jelentőségteljesen rávágná, hogy: "hát, fájlból! :-)". Ezt is fogjuk csinálni, de előbb kikerekítem a történetet, hiszen az még nem derült ki, hogy az elmentett (mondjuk pictures.rss nevű) fájllal mi a teendő.

2. feladat: Az rss beillesztése a html oldal szerkezetébe

Hát ez a legegyszerűbb dolog, óvoda alsó tagozatban ezt karcolják a gyermekek a homokba. A html <head> szekcióján belül kell csak elhelyeznünk a hivatkozást az rss-ünkre:

<link rel="alternate" href="pictures.rss" type="application/rss+xml" title="Erdélyi vakáció" id="erdely2008">Ezt az egy sort bezúzzuk oszt reszelő. Ha mindent jól csináltunk, a képeink sarkaiban már dübörögnek is a kis play gombok, amikre rákattintva máris elindul a Piclens.

3. ez nem feladat: Fontos dolgok

Félreértés elkerülése végett:

• Csak annak a képnek fog megjelenni Play gomb, amelyik az RSS-ben is szerepel.
• Ilyen RSS-t albumonként érdemes generálni, és annak a weboldalnak a fejlécébe kell belerakni a hivatkozást, amely egyébként is tartalmazza a képeket - a "hagyományos", web galéria módszerrel, amely általában kattintható kis képeket tartalmaz. Tehát albumonként egy galéria, minden galériához egy RSS a beletartozó képekkel.

4. feladat: Automatikus generálás

Körülkajbászoltam a gépemen, de nem találtam olyan képnézegetőt, amelynél be lehet írni egy-egy képhez annak címét, és az el is tárolja. Lehet, hogy a digikam, vagy a picasa tudja, de én azt nem használom. Ha valaki esetleg megírná, hogy melyik támogat ilyet, boldog lennék hogy nem nekem kell felrakosgatni megint ezeket a programokat. Ha lesz példa képaláírás-fájl, amin perlezhetek, akkor megírom az RSS előállítót, ami legalább olyan gyorsan oldja majd gondjainkat, mint a Calgonit a vízkövet...