Használható GNU+Linux grafikus környezet 25 megában?...avagy lehet-e legújabb disztribúciót rakni _régi_ gépre így 2015-ben, és egyáltalán érdemes-e?Pár hete botlottam bele egy 10 éve nem használt laptopomba, amin még a Debian Woody boot-olt be. Hozzátenném, hogy már a maga korában sem volt szélvész. Egy 1998-as gyármányú Fujtsu Lifebook b110.P233mmx, 64M ram, 4G hdd, ES1879 hangkártya, NeoMagic videokártya 800x600-zal és natív 100x37-es (!) textmode-dal, plusz egy korabeli Cisco pcmcia wifi; wep-et legalább már tud. Első körben upgrade-eltem Jessie-re, mert már mindjárt úgyis az a stable. Amikor már minden a csomag a legfrissebb volt, akkor kezdtem bele az optimalizálásba. --- Alapok --- Ha nem egy létező rendszert akarunk lecsupaszítani, akkor már a partícionálásnál megjelennek a kérdések. Milyen fs (filesystem) legyen a root? Alapvetően mindenképpen egy journaling fs-t javaslok, több szempontból is. Ext2 ilyen szempontból felejtős. Én megmaradtam az ext3-nál, de ugyanígy lehet ext4-et vagy btrfs-t is felrakni. Ha ma raknám fel, ext4-et választottam volna root-nak, és btrfs-t home-nak. A rootfs-hez még érdemes a noatime,nodiratime,data=writeback opciókkal mount-olni, így nem fog számunkra feleslegesen írkálni a lassú vinyóra, és az írási műveleteket is cache-eli lehetőség szerint. Emiatt kell a journal, hogy ebből fakadó adatvesztés ne léphessen fel. Ha a /home btrfs, akkor érdemes neki a noatime,nodiratime,norelatime,compress=lzo,nodatasum,autodefrag paramétereket megadni. Ezeket install után ráér beállítgatni a /etc/fstab-ban. Ha minden megabyte memória számít, akkor még érdemes az elején egy custom kernelt is forgatni, ami sallangmentesen a mi hardware-ünkre van belőve.

Használható GNU+Linux grafikus környezet 25 megában?

...avagy lehet-e legújabb disztribúciót rakni _régi_ gépre így 2015-ben, és egyáltalán érdemes-e?

Pár hete botlottam bele egy 10 éve nem használt laptopomba, amin még a Debian Woody boot-olt be. Hozzátenném, hogy már a maga korában sem volt szélvész. Egy 1998-as gyártmányú Fujtsu Lifebook b110. P233mmx, 64M ram, 4G hdd, ES1879 hangkártya, NeoMagic videokártya 800x600-zal és natív 100x37-es (!) textmode-dal, plusz egy korabeli Cisco pcmcia wifi; wep-et legalább már tud. Első körben upgrade-eltem Jessie-re, mert már mindjárt úgyis az a stable. Amikor már minden csomag a legfrissebb volt, akkor kezdtem bele az optimalizálásba. Tisztában kell lennünk vele, hogy miből kell gazdálkodni. A legszűkebb keresztmetszett a hdd sebessége, így minimalizálni kell az írást-olvasást. A második kritikus rész a memória, amiben el kéne férni, különben jön az eszetlen swap-elés, amit máris el akarunk kerülni. A harmadik a cpu lomhasága - ezen nagyon nem tudunk változtatni. A hdd mérete jelen esetben a maga 4 gigájával még mindig ideális, hiszen 2 gigába is simán elfér egy rendszer. A cél egy használható rendszer, ahol a minimális kényelmi funkciók még működnek, és teljesen kompatibilis marad csomagszinten a disztribúcióval, így bármi telepíthető rá később bármiféle kompromisszum nélkül.

--- Alapok (partíció, kernel) ---

Ha nem egy létező rendszert akarunk lecsupaszítani, akkor már a partícionálásnál megjelennek a kérdések. Milyen fs (filesystem) legyen a root? Alapvetően mindenképpen egy journaling fs-t javaslok, több szempontból is. Ext2 ilyen szempontból felejtős. Én megmaradtam az ext3-nál, de ugyanígy lehet ext4-et vagy btrfs-t is felrakni. Ha ma raknám fel, ext4-et választottam volna root-nak, és btrfs-t home-nak. A rootfs-hez még érdemes a noatime,nodiratime,data=writeback opciókkal mount-olni, így nem fog számunkra feleslegesen írkálni a lassú vinyóra, és az írási műveleteket is cache-eli lehetőség szerint. Emiatt kell a journal, hogy ebből fakadó adatvesztés ne léphessen fel. Ha a /home btrfs, akkor érdemes neki a noatime,nodiratime,norelatime,compress=lzo,nodatasum,autodefrag paramétereket megadni. Ezeket install után ráér beállítgatni a /etc/fstab-ban.

Ha minden megabyte memória számít, akkor még érdemes az elején egy custom kernelt is forgatni, ami sallangmentesen a mi hardware-ünkre van belőve. Nekem 3 megát sikerült lefaragnom a ramhasználatból. Aki még nem forgatott kernelt, annak itt egy működő howto: https://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage . Aki nem debian-t használ, talál a neten magának; az is ugyanezt meséli el, csak a legelső meg utolsó lépések térnek el. Az alapszabály a make menuconfig után annyi, hogy amire biztosan nincs szükségünk, és [Y]-ként szerepel, azt szedjük ki szépen. Ami [M], az nem baj, mert csak module-ként forog le, és csak szükség esetén töltődik be. Hozzátenném, hogy a Debian default kernele elég lightweight alapjáraton is, így ne csodálkozzunk, ha alig tudunk valamit kiszedni belőle. Főleg a framebuffer környékén vannak a statikusan linkelendő driver-ek, amire nekünk semmi szükségünk nem lesz, mert a console az textmode-ban gazdaságos. Mindenképpen válasszuk ki a megfelelő cpu-t, amire optimalizáljon a gcc, ez nálam a pentium-mmx lett. Emellett az Optimize for size-t mindenképpen kapcsoljuk be! A selinux-os audit feature-ökre sem lesz szükségünk, azokat is lehet lekapcsolgatni. Meg a nem használt tömörítő algokat. Érdemes rászánni egy fél órát, és bejárni minden szegletét a menünek. Természetesen a kernelforgatást ne a kiszemelt lassú gépen végezzük, hanem bármely izmosabb tesóján! Bár aki türelmes, az várhat egy fél napot a kernelre... Ami nagyon csábító, azok a különböző swap/cache tömörítő algok - gondolok itt a zcache(compcache)-re, zswap-ra és zram-ra. Ezekre nem lesz szükségünk, hiszen alapvetően a ramból van kevés, utána a cpu-ból, így ezek csak lassítanak. Ha sikeresen lefutott egy reboot az új fstab-bal és új kernellel, akkor a `free` paranccsal össze is hasonlíthatjuk, hogy mennyi memóriát sikerült nyernünk, és már léphetünk is a következő lépcsőre. De ha nem, akkor is. Ezek párhuzamos optimalizálások, nem épülnek egymásra, úgyhogy a howto további részében is order does not matter.

--- Csupaszítás (felesleges daemon-ok) ---

Most jön az a rész, hogy szépen minden programot leállítunk ami fut, és nincs rá szükségünk. Ezeket én csomagszinten is leszedtem, hogy véletlen se induljanak el, és a helyet se foglalják. Egy alap rendszerhez nem kell semmi más a textmode console-hoz, csak:

- udev (systemd-udev)

- syslog (sysklogd, syslog-ng, rsyslog)

- getty (mgetty, mingetty, agetty)

- shell (bash, csh, zsh)

[ - dhcp kliens (dhclient, dhcp-client)]

Érdemes letölteni a ps_mem.py scriptet ( https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py ) és berakni /usr/local/sbin -be, meg feltenni az smem csomagot, és gyakran futtatni. A ps_mem a ténylegesen a userspace ramban állomásozó binárisok helyfoglalását mutatja, míg az smem -kt a swap-et is beleszámolja, de a shared ramokat nem annyira. Kicsit más eredményt fog mutatni a kettő -már csak azért is, mert a psmem nem számolja bele önmagát a listába-, ámde mindkettőnek megvan a maga értelme. Még fontos parancs a pmap -x `pgrep <program neve>`, amivel egy adott programról kaphatunk részletes ramhasználati statisztikát.

A felsorolt programokon kívül nekem semmi másra nincs szükségem - ha valakinek meg igen, úgyse szedi le, mert tudja, mi az. Ami nem kell, az például a policykit, nscd, chronyd, ntp, smtp (exim, postfix), pulseaudio. Egy rootlogin után lehetőleg a psmem ne mutasson más futó processzt, mint amiket felsoroltam. Ha systemd-s rendszerünk van, akkor érdemes sysvinitre váltani, mert az sokkal kisebb. (debianon: sysvinit-core) Ez el fog tartani egy darabig, már csak az apt sebessége miatt is, amit a lassú hdd okoz. A hálózati beállításokhoz használjuk az adott disztró standard megoldásait a különböző networkmanager-ek helyett. Ez debiannál a /etc/network/interfaces file. Tartalma kommentek nélkül:

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet dhcp

auto wlan0

iface wlan0 inet dhcp

wireless-essid linksys

# wireless-key s:wpa2password

wireless-key ABCDEF0123

A device-ok nevei persze nem feltétlenül ezek, ezek csak a default-ok. A wlan0 most wepet használ, de a kikommentelt sorral wpa2-es jelszót lehetne megadni neki. Aki ennél komplexebb megoldásokra vágyik, man interfaces.

--- X (grafikus felület) ---

Ugorjunk is bele az X-be, ha már semmi sallang nem fut a gépen! Az xorg-ot mindenképpen fel kell rakni, ezt nem lehet megkerülni, és a hozzá tartozó videokártya és input driver-eket sem. A legtöbb lightweight linux leírás gyakorlatilag csak erről szól, hogy milyen desktop environmentet, ablakkezelőt válasszunk. Erre én nem fogok sok időt szánni, hanem elmondom, hogy a méltánytalanul elfelejtett icewm a legkisebb, és pont. Az lxde-session szóba sem jöhet ilyen gyengusz gépen, mivel közel sem annyira lightweight, mint azt a neve sugallná. Egyszerűen magával rántja a gvfs-t, ssh agentet, és minden hóbelebancot, amire nincs szükség, csak a ramot foglalja. Egy csupasz openbox+lxpanel kombó még játékban lehetne...ha...ha nem foglalna az openbox 3.9, az lxpanel pedig 5.1megát. Összesen közel 10M, ami a 64M ramnak már vagy 15%a, ami itt soknak mondható. Az icewm ehhez képest csak szerény 2megát foglal, és egymaga az ablakkezelő és a panel is. Lehet még kisebb userunfriendly ablakkezelőket találni (pl. suckless dwm), de én meghúztam egy kényelmi minimumot. Az icewm képes kezelni virtualdesktopot, hotkey-eket lehet állítani (pl. screenshot, multimedia gombok), theme-ezhető (itt van cirka száz, ha valaki válogatni szeretne: http://box-look.org/index.php?xcontentmode=7311 - mai napig készülnek hozzá), ablakok réteg szerint csoportosíthatók (always on top), menü, óra, system monitor a panelen. Még systray-t is kezel, ha erre van igény (icewm-tray, +800KB), vagy hátterünk is lehet (icewm-bg, +800K).

A képből látható, hogy a userspace ramból 29 megánál meg is áll, ami ennyi sem lenne, ha egy másik gépről nem ssh-ztam volna be (sshd), nem nézném folyamatosan a statisztikát a gép működéséről (dstat), nem futna vpn (openvpn), és screen-ben (screen) sem su-ztam (su) volna. Ha neked itt még csomó gnome-os/kde-s hülyeség is szerepelne a listában -ami igen valószínű-, akkor arra az a megoldás, hogy nem kell őket elindítani. Naigen, hogy indítjuk el az x-et? Hát a lehető legegyszerűbben. Terminálban belépünk a user-rel, és beírjuk, hogy xinit. Ez a ~/.xinitrc -ből veszi, hogy mit indítunk el. Ennak tartalma legyen:

xrdb -merge ~/.Xresources

setxkbmap us,hu ,101_qwerty_dot_dead -option grp:alt_shift_toggle

xset r rate 300 50

Ha valaki nem értené, mi történik: saját beállításaink betöltése az xresources file-ból - ennek később lesz jelentősége. Keyboard-on amcsi-magyar kiosztás beállítása, váltás bal alt-shift-tel. Utána a billentyűismétlés és az egér sebessége, aztán maga az icewm. Ha valamire még szükséged van, akkor ide írogasd be őket az autostarthoz. Ha valami nem fut le véges idő alatt, és/vagy nem a háttérben indul daemon-ként, akkor a végére tegyünk egy & jelet, és az icewm elé írjuk be; pl: icewmtray &, xterm &. Ekkor már elmondhatjuk, hogy van egy lightweight linuxunk, bár még tippünk sincs, mit fogunk futtatni, amit el is bír a gépünk.

-- Grafikus programkörnyezet --

Nem is tudom, mivel kezdjem...bár: de. x-terminal, azaz debianon /etc/alternatives/x-terminal-emulator. Remélhetőleg, ez default az xterm, ami napjainkban már felfogható lightweight terminálnak, de sajna messze van tőle az rxvt-hez képest. Évek óta xterm-ezem, úgyhogy ennek a feature-jeit nem szeretném kidobni, így kerestem egy abszolút győztest: rxvt-unicode-lite. Ez jelenleg 2.6megát foglal, szemben az xterm-mel, ami 4 alatt nem áll meg. Külön előnye, hogy futtatható daemon mode-ban is, azaz csak 1 process indul, és a többi terminál erre kapcsolódik rá. Ez nem forkol, azaz single thread marad, így 10 rxvt egymás mellett nem igényel sokkal több ramot, mint 1. Xterm ilyenkor -shared ram ide vagy oda-, megkajál 40 mega ramot is simán. Külön jó, hogy az alkotók mindenre gondoltak, így van egy minishellscript is urxvtcd néven, ami rákapcsolódik az rxvt daemon-ra, de ha nem fut, akkor indít egyet, és aztán kapcsolódik rá. Ezt pl. érdemes betenni .xinitrc-be is, hogy icewm előtt induljon már el. Sőt: ha ezt hívjuk meg ablakkezelő helyett, akár ebből indítható és leállítható tetszőleges desktop az x újraindítása nélkül (xfce, openbox, lxpanel, icewm, dwm).

Mivel én mindig is xterm-et használtam, így a default rxvt hasogatta a szememet, ezért csináltam egy xterm klón beállítást, ahol tényleg minden ugyanúgy néz ki és működik. Se az xterm-nek, se az rxvt-nek nincs configfile-ja, hanem az x-ből veszi a környezeti beállításokat. Ez található a ~/.Xresources-ban:

UXTerm*background: black

UXTerm*foreground: gray90

UXTerm*VT100.geometry: 80x25

UXTerm*rightScrollBar: false

UXTerm*saveLines: 512

UXTerm*scrollKey: true

XTerm*background: black

XTerm*foreground: gray90

XTerm*VT100.geometry: 80x25

XTerm*rightScrollBar: false

XTerm*saveLines: 512

XTerm*scrollKey: true

URxvt*perl-ext:

URxvt*perl-ext-common:

URxvt*color0: black

URxvt*color1: red3

URxvt*color2: green3

URxvt*color3: yellow3

URxvt*color4: blue2

URxvt*color5: magenta3

URxvt*color6: cyan3

URxvt*color7: gray90

URxvt*color8: gray50

URxvt*color9: red

URxvt*color10: green

URxvt*color11: yellow

URxvt*color12: rgb:5c/5c/ff

URxvt*color13: magenta

URxvt*color14: cyan

URxvt*color15: white

URxvt*geometry: 80x25

URxvt*cursorBlink: true

URxvt*cursorUnderline: true

URxvt*background: black

URxvt*foreground: gray90

URxvt*jumpScroll: true

URxvt*skipScroll: true

URxvt*font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

URxvt*scrollstyle: plain

URxvt*scrollBar: false

URxvt*termName: rxvt

URxvt*scrollTtyOutput: false

URxvt*scrollWithBuffer: true

URxvt*scrollTtyKeypress: true

URxvt.secondaryScreen: 1

URxvt.secondaryScroll: 0

URxvt.secondaryWheel: 1

* Icewm hangolás - Bár ugyan a http://www.icewm.org/manual/-on mindenki kiokosíthatja magát, azért ideírom, hogy én miket használok konkrétan. A ~/.icewm/keys file-ba írjuk bele, hogy key "Print" scrot 'scrot-%Y-%m-%d-%H-%M-%S_$wx$h.png' -e 'mv $f ~/Pictures/screenshot/ . Így printscreen-re kapunk egy screenshot-ot. A ~/.icewm/preferences:

ShowHelp=0

TaskBarShowMailboxStatus = 0

TaskBarShowClock=1

TimeFormat=%T

DateFormat="%F %A - %T"

WorkspaceNames=" 1 ", " 2 ", " 3 ", " 4 "

~/.icewm/toolbar:

prog XTerm xterm x-terminal-emulator

prog "WWW" dillo x-www-browser

prog "IRC" hexchat hexchat

prog "xmms" xmms xmms

prog "gkrellm" gkrellm gkrellm

Miután modósítunk egy file-t, könnyedén újraolvastathatjuk a config-ot az icewm-mel egy paranccsal: killall -HUP icewm. A theme-eket pedig a menüből érjük el, miután kicsomagultunk egy csomó letöltött zip-et a ~/.icewm/themes/ -be.

- Multimedia - Kezdjük az audio részével: a pulseaudio-tól nagyon gyorsan szabaduljunk meg: ram és cpu gyilkos egy személyben, nincs itt semmi keresnivalója. A jó öreg oss vagy alsa tesója pont megfelelőek, és a kernelmodule-okon kívül nem foglalnak semmit. Zenehallgatásra sok lehetőség adódik; az én ajánlatom már évek óta az xmms. Az 1.2.11-es verzió a mai napig használható. (debian-on sources.list-be: deb http://archive.debian.org/debian/ etch main contrib non-free, és már telepíthető is). Kezeli a régi winampos skineket, szóval tényleg bárhogy kinézhet a keretein belül. Tud mp3-mat, streamet, cd-t, mod-ot (s3m, xm, stb...), sid-et (c64), ogg-ot, flac-t, midit, wavot. Ennyi elég is egyelőre. Vannak hozzá vizuál plugin-ek (fullscreen-esek is), infrás távirányítóra szoktatható. Mi kell még? :-> Közepes playlist-tel 5.3M ramot eszik mp3 lejátszása közben, és a p233-mas prociból 20%-ot kér. (cpu bogomips : 459.26).

Érdemes az xmms-t negatív nice-szal futtatni, hogy ne akadjon be a zene, ha valami történik még a gépen. Természetesen a screenshoton csak a látvány miatt kapcsoltam be egy vizuál plugin-t - a valóságban megeszi a maradék cpu-t, ezen a gépen nincs értelme. Mixerből nagyon nem tudunk válogatni, de ami van, az pont elég: aumix és alsamixer.

Videora sincs sok kérdés: mplayer. Kész. Az egyetlen player, ahol codec-enként lehet megmondani forgatásnál, hogy mi kerüljön bele. Mivel default 18M a bináris, és 214 lib-en dependel, így nem a barátunk. Töltsünk le egy forrást, és szépen fordítsuk le magunknak kihagyva mindazon hardware-eket, feature-öket, codec-eket, amiket nem kívánunk használni. Ezt most nem fogom részletezni, mert mindenkinél egyedi, hogy mit forgat bele. Én speciel csináltam egy youtube-os mplayer verziót, ami 1.7M, és csak pentium-mmx optimalizálás, flv codec, mp3 codec, feliratkezelés, x11-xv output van benne. Természetesen borzasztóan macera egy működőképes kisebb mplayer-t összehozni, így ezt a lépést ki is hagyhatjuk, csak később emlékezzünk rá, hogy az mplayer alapból baromi nagy! Nekem 64mega rammal ez a 18 elfogadhatatlanul hatalmas, úgyhogy nem volt más választásom. Ja, és hogyan nézek youtube-ot? (*)

Van egy kis script, ami betolja mplayer-nek youtube-ról az flv-s verziót. Ha valakit érdekel a ~/bin/yy :

#!/bin/sh

URL="$1"

if [ "$URL" = "" ]

then URL=$(xclip -o)

echo "URL: $URL"

URL=$(echo "$URL"|cut -d"&" -f1)

pipe=`mktemp -u`

mkfifo -m 600 "$pipe" && youtube-dl -f 5 -qo "$pipe" "$URL" & mplayer.youtube "$pipe"

rm -f "$pipe"

Ez vagy a paraméterben megadott videot játsza le, vagy a clipboard-ról veszi az url-t. Így elég csak kijelölnünk brózerben, nyomnunk egy alt+y -t, aztán némi krákogás után beköszön az mplayer egy ablakban. Persze miután beleírtuk a ~/.icewm/keys-be a key "Alt+y" yy sort. 80% CPU-t eszik és 8+15mega ramot (mplayer+youtube-dl). Így már egész baráti, de az is nyilvánvaló, hogy nem ez lesz az elsődleges youtube-ozó gépünk. Ezt tekintsük kényszermegoldásnak, ha mégis szükség lenne rá. Aki csillagászati számokkal leírható 256M rammal is rendelkezik, az az smplayer-t is megpróbálhatja. Azért smplayer, mert az már az általunk forgatott binárist fogja hívogatni. Sőt: a youtube-ot is natívan kezeli hack megoldások nélkül. Azt remélem, nem kell említenem, hogy a video output xv, és semmiképpen sem x11, mert az ugye borzalom lassú! Egyéb videokártyákon egyéb kimenet is elérhető - ezt te tudod, hogy mid van. De x11 nem pálya semikor sem, akkor túrjál netet vmi normális driver-ért! (* a screenshot -vo x11-gyel készült, hogy látszódjon is valami.)

* Web browser - Nahát igen. Ez a nagy kérdés. Mindig ez a kérdés. Egy ilyen gyenge gépen alapvetően 3 megoldás jöhet szóba: dillo, netsurf, *vnc. A dillo tényleg lightweight. A legkisebb grafikus brózer, amit valaha láttam. ( http://www.dillo.org/ )

500Kbyte-on elfér a vinyón, és 11 megát eszik 4 nyitott tab-bal. Nyilván javascriptet nem tud, ez van. Tud keresni, vannak tabjai, van bookmark, van css, vannak képek, és még ssl-re is képes. Ezt stabilan tudja, és még ezen a gépen is szinte repül, annyira gyors. Howto-k olvasására, képek megtekintésére, mobilkompatibilis oldalak borzolására melegen ajánlott. Mást nem lehet róla elmondani, musthave! Ajánlott kis tweak a ~/.dillo/dillorc-be:

panel_size=tiny

search_url="Google http://google.com/search?q=%s"

search_url="Duckduckgo http://duckduckgo.com/lite/?kp=-1&q=%s"

cookies.rc-be:

DEFAULT ACCEPT_SESSION

.akamaihd.net ACCEPT

.facebook.com ACCEPT

Viszont akadnak olyan helyzetek, amikor a dillo már nem elég. Például egy linksys router webes felületén pont annyira minimális javascript van, hogy a dilloval lehetetlen legyen beállítani. Ekkor jön jól, ha fel van telepítve egy netsurf is. ( http://www.netsurf-browser.org/ )

Ez már 3 megabyte-ban állomásozik a vinyón, alapjáraton eszik 13 megát, és 4 tab-bal már 32M ramot kér enni. Az nagyon sok, érezhetően lomhábban fut, nekem sajna már erősen swap-el is. Firefox-hoz szokott szemnek nagyon könnyű hozzá alkalmazkodnia, teljesen hasonló az elv és a kinézet. Van korrekt guis beállítása, nem a dillorc-be kell pötyögni a konfigot kézzel. Nagy előnye, hogy kezeli a javascriptet. Természetesen ebben nincs webkit, így nem teljesértékű a js motor, de egyszerűbb site-okra elmegy. A mobil facebook működik vele, nem csúszik szét, klafa. Ha van legalább 100M ramod, ez már elég használható.

A harmadik lesz az igazi megoldás. Abba bele kell törődnünk, hogy ilyen gyatra gépen a mai javascript-heavy webes világot nem érhetjük el. Nem is csak a ram, már a cpu is bőven alatta van a lécnek, csodák pedig nincsenek. Egyetlen lehetőség maradt: másik gépen futtatjuk a browsert.

Szerencsésebbek többmagos szerveren, szerencsések többmagos otthoni gépen, többiek pedig ahol tudják. Érdemes kitolni fullscreen-be, a sávot még összébbhúzni, a zoompage addont felrakni, hogy 1 klikkre kizoom-oljon a teljes oldalra. Ez 800x600-ban különösen fontos, ahol a mai oldalak már mind kilógnak alapból. Itt ugye már semmi megkötés nincsen, azzal terheljük a másik gépet, amivel csak akarjuk. Lehet erre azt mondani, hogy nem "igazi" browser. Lehet, viszont működik. Ilyen gépen nincs más lehetőségünk a normális webre. Az pedig mindegy, hogy milyen vnc klienst használunk ehhez a kapcsolathoz. Én a tightvnc-t, vagy a tigervnc-t ajánlom. Tightvnc ugyan kevesebb rammal beéri, de kevésbé tud hatékonyan tömöríteni, így nekem már csak emiatt megéri tigervnc-t használni. 9 megával elvan, míg a tightvnc-nek kb. 6 is elég, ám érezhetően lassabb - belefér ez a +3M. ( http://tigervnc.org/ )

A következő lépcsőfok a lightweight-nek csúfolt qupzilla lehetne, de az már 200 mega ramot hörpint be ugyanarra a 4 tab-ra. Egyszerűen nem opció. A lassú proci miatt meg hiába lenne elég ram, akkor is csak méltóságteljesen (=lassan) futna. Mivel qupzilla a webkitre épül (amire a chrome is), így ennek előnye a mindent vivő motor, és a minden ramot megevő motor egyszerre. Amelyik gépen a qupzilla szépen fut, ott már chrome-mal is lehet próbálkozni. A 'futottak még' kategória helyezés nélküli indulói: uzbl, luakit, midori, dwb. Ezeknél ilyen vagy olyan szempontok alapján a dillo és a netsurf mindig jobb választás.

* Instant Messenger - ...avagy chat-elni jó! Jogos lehet a kérdés, hogy mi szükség van ezt külön taglalni, amikor a vnc-s megoldással elérünk bármit. Ez igaz, és tényleg nem szükséges ezek után külön chat klienst telepíteni, de azért mégiscsak gyorsabb és kényelmesebb egy local input box-ba gépelni. Ha valaki a pidgin-re vagy empathy-ra gondol, akkor téved. Pidgin csak induláskor 32 megát szippant be, és még nem is csatlakoztam semmire. Egy közepes komplett brózernek kell ugye ennyi, ennyit nem ér meg. Ekkor siet segítségünkre a bitlbee és a hexchat. ( https://hexchat.github.io/ )

Azt rögtön látjuk, hogy a hexchat-nek (egyébként ez az xchat utódja) elég 5.8 mega ram. Aki a bitlbee-t nem ismeri, annak annyit illik tudnia, hogy ez egy irc gateway a különböző protokollok fele. Ahogy a pidgin is csinálja, csak itt a végeredmény egy szabványos irc server, amire bármilyen klienssel csatlakozhatunk. Ha már fut egy brózerunk vnc-ben, akkor ugyanide a bitlbee szervert is felhúzhatjuk skype-ostul. Igen, az igazi hipszterek kedvéért megy terminálból is irssi-vel, ami már 2.7 megán is elél. Csak érdekességképpen tettem ide, a gyakorlatban xchat-et, bocs: hexchat-et használok. Facebook chat megy vele, csak a képeket kapja meg linkként - azokat én a dillo-val nyitom meg. Tudja mutatni, hogy ki online/away/online. Ezt még gtalk-on, icq-n, skype-on és még whatsapp-on is tudja. Nyilván utóbbin nincs away. Elég egyszerűen lehet bekonfigolni a hálózatokat hexchat alól, bővebb leírás itt: https://wiki.bitlbee.org/. Ja, természetesen irc hálózatra is jó, hiszen ez pont egy irckliens. :->

* Képnézegetőnek a gpicview-ot ajánlom az lxde gondozásában. XFImage is lehet alternatíva az xfce-től.

Az (s)xiv nagyon fapad, a dillo végülis erre is jó, a feh is fapad, a geeqie pedig túl sok ramot eszik. A gpicview és az xfimage fej-fej mellett hozzák a 10M ramhasználatot egy 800x600-as képnél.

Ennyi elég az X-ről, innen már mindenki kedvére telepítgetheti, ami neki szem-száj ingere, és még a ramba is befér. Felesleges hülyeségekbe (pl. hangszerkesztő, videovágó, szövegszerkesztő) nem megyek bele, mert egy ilyen hw alapvetően nem erre van, senki se akarja a 21. században ilyenekkel terhelni a gépet, avagy magát. Ha már amúgy is egy firefox-ot meg skype-ot csapatunk egy remote gépen, akkor már a libreoffice is elfér ott. Demonstratív hipsztercélokra lehet még abiword-del és társaival küzdeni, de ezt én meghagyom másnak, a pdf-eket vnc-ben nyitom meg. Summa-summárum: a vnc-ben úgyis bármit tudunk futtatni, ami nem igényel low latency-t. Ami meg igen, az pont az audio és a video, amit fentebb kiveséztem már.

Gyakorlatban még felmerülhet az a probléma, hogy jó-jó, a youtube megy, vimeo megy, indavideos/facebook-os linket is tudunk mplayer-nek tolni, de a vnc-s firefox-ban hiába megyeget a silverlight video, hangja nincs. Erre a stock megoldás a pulseadio és tcp-n átdobni a hangot, de mint említettem volt: nekünk a pulseaudio nem pálya. Ezért felrakunk egy shoutcast-et vagy icecast-et, aztán ebbe pumpoljuk bele a firefox hangját. Így kb. 1 másodperc latency-vel xmms-sel hallgatjuk a silverlight hangját. Nekem eddig erre egyszer volt szükségem, de hátha valakinek detto...

-- További tuningok --

...avagy még mindig nincs elég szabad ram, hogy a kernel kedvére cache-elhessen. Aki a fentebbi lépéseket követte a saját gépén, az már egy igencsak lightweight linux-szal büszkélkedhet, nagyon kevés ram-on is megél. Ámde ez még messze az ígért 25M fölött van - próbáljátok ki, de úgyis látjátok. (smem, psmem) Most jön az a rész, hogy amit nem tudunk nélkülözni, abból beszerezzük a legkisebb verziót. Ez még annyira nem kézzelfogható, hisz a partíción elfoglalt hely még nem minden. A lényeg, hogy mennyit eszik a ramból. Ezt a legjobban a dietlibc-vel tudjuk kimaxolni, így olyan alternatívákat keresünk, amik ezt támogatják. ( http://www.fefe.de/dietlibc/, debianon dietlibc-dev)

* Syslog/klog. Bár az is egy lehetőség, hogy a logolásról teljes mértékben lemondunk, ez azért egy linux rendszernél nem a legjobb választás - pláne, ha valami hiba adódik, vagy amúgy is. A default syslog megoldások biztosan nagyobbak, mint ami nekünk ideális lenne. Például egy syslog-ng 2M ramon terpeszkedik. 2M nagyon sok csak arra, hogy sorokat másoljon egy file-ba - anno feleennyibe komplett játékok belefértek. Szóval ezen változtatni kell. Ismerkedjünk meg a busybox-szal, avagy akinek van busybox-static csomagja, az azzal. ( http://www.busybox.net/ ) A busybox egy olyan statikusan is fordítható svájcibicska, ami alapvető tool-ok nagyon fapad verzióját mind tartalmazza magában. Ennek tudatában már nem tűnik furcsának, hogy syslogként is tud viselkedni. Debian-on nagyon egyszerű, mert van egy busybox-syslogd csomag, ami pont erre képes. Beállítjuk, hogy inkább file-ba logoljon, és nyugodtan hátradőlhetünk, mert 3-400kbyte körül fog kérni magának, később még összébb is húzhatja magát. Ha még ezt is sokalljuk, akkor jöjjön a dietlibc-vel fordított socklog, ami a saját svlogd parser-ével elvan 190kbyte-on. ( http://smarden.org/socklog/ ) Debian-on apt-get source socklog, aztán CC=gcc helyett CC=diet gcc. Fordításnál érdemes már a saját procinkra optimalizálni a kódot, és a méretét is lecsökkenteni, amennyire lehet. Ezt 3 változó export-olásával érhetjük el:

CFLAGS='-mtune=pentium-mmx -march=pentium-mmx -Os'

CPPFLAGS='-mtune=pentium-mmx -march=pentium-mmx -Os'

CXXFLAGS='-mtune=pentium-mmx -march=pentium-mmx -Os'

Ideális esetben, amikor dpkg-buildpackage-vel vagy fakeroot debian/rules binary-val gyártunk csomagot, akkor ezeket a flag-eket felhaszálja fordításkor. Ha nem, akkor kézzel írjuk bele a rules-be, configure-be, vagy akár a kész Makefile-okba. Egységes recept nincsen, minden program más-más programozótól, más-más developertől származik, így ezt minden csomagnál nekünk kell megkeresni, hogy a lehetséges helyek közül hol kell belenyúlni a scriptekbe. Ha sikerült, és felraktuk a csomagot is, akkor valami ilyesmit kell látnunk psmem-mel:

Most hátradőlhetünk - megtaláltuk a legkisebb loggert. Kicsit ugyan más a logfile-ok elrendezése és elnevezése, mint a default syslognál, de ilyen baráti ramhasználatnál ez simán megbocsátható. Symlinkekkel és ügyes konfiggal syslog szerűre is fejleszthető.

* Cron. Naigen, akár ezt is lespórolhatnánk, de akkor bukjuk az automatikus logrotate-et, a locatedb frissülését, egyebeket. Ebből is van busybox-os megoldás, ami teljesen kompatibilis a default vixie cron-nal. A busybox-syslogd mintájára én is gyártottam magamnak busybox-crond csomagot, de aztán ehelyett is találtam egy még gazdaságosabb dietlibc-s megoldást: dcron. ( http://www.jimpryor.net/linux/dcron.html )

Ennél lightweight-ebb nem is lehetne. Nagy sajnálatunkra nem a Debian része, ámde az Arch-osok könnyen rálelnek. Érdemes mindenből csomagot gyártani, hogy ne legyen összeszemetelve a rendszer!

* Getty. Ez az, amit nem tudunk megkerülni. Valahogy console-on be kell tudni lépni, és erre kell egy getty. A default getty sem hatalmas, a mingetty is egész jó, az ngetty-hez még több process sem kell, ámde az fgetty-nek van egy behozhatatlan előnye: képes direktben autentikálni a pam és a login megkerülésével. Desktop rendszerünkön ez a legkevesebb, úgyse nagyon lesz 2-nél több user, a /etc/shadow-ból bőven elég autentikálni. Ezt is újraforgatjuk dietlibc-vel, beírjuk a /etc/inittab-ba a (min)getty helyére:

1:2345:respawn:/sbin/fgetty tty1

2:23:respawn:/sbin/fgetty tty2

3:23:respawn:/sbin/fgetty tty3

4:23:respawn:/sbin/fgetty tty4

Aztán init q, és már az fgetty fog fogadni minket igen meggyőző takarékos üzemmódban. ( http://www.fefe.de/fgetty/ ) Mivel az fgetty még csak md5-tel hash-elt password-öket kezel, ezért a default sha512-est wrong password-nek fogja hinni, ezért a /etc/pam.d/common-password-ben ezt írjuk át, utána cseréljünk jelszót!

* Init. Avagy könnyes búcsú a sysvinit-től. Alapjaiban nincs baj az init méretével, hisz összehúzza magát 200k-ra is, ha kell, de hát ő is csak libc-vel szeret fordulni, így jöhet az egyetlen dietlibc-s init megoldás (a busybox-ot nem számolva): runit. Igen, igen kényes téma az initet birizgálni, több lépésben kell leváltani, de annyira nem is rocketscience, csak egy howto kell hozzá: http://smarden.org/runit/replaceinit.html . Szerintem a /sbin/init -et felesleges átsymlinkelni, bőven elég ha a grub-ban az init=/sbin/runit-init paramétert a kernel mögé biggyesztjük. Mivel az fgetty és a socklog is runit haverja, így ezekre kész example-ket találunk, hogy hogyan indítsuk el őket.

Én két helyen nyúltam bele a default configfile-jaiba. Az egyik a /etc/runit/1, ahol a /etc/init.d/rc 2 helyett inkább:

for runprog in /etc/rc2.d/S*; do

$runprog start

done

A /etc/runit/3-ban pedig:

for runprog in `ls -1r /etc/rc2.d/S*`*; do

$runprog stop

done

Így nem kell aggódnunk az iniscriptjeink miatt, hiszen lefutnak ugyanazok a bootkor, mint sysvinit-tel. Kicsit fapad megoldás, de a pálya szabad mindenkinek szebbet építeni. A force-stop-nál a timeout-ot még levettem 7-re. A reboot-ra gyárthatunk alias-t: alias reboot='runit-init 6' . Igen, runit-ban ez a reboot.

* Dhcp kliens. Ez már nem egy annyira kritikus pont, hiszen bármikor lekillelhetjük ezt a processt, ha már megkaptuk az ip-t, de azért érdemes ebből is egy dietlibc-set használni. Én csak erre használom már csak a busybox-ot, mert egyszerűen nem találtam használható dietlibc-vel forduló dhcp klienst - ha valaki tud, szólhat is ezügyben! Ez debianon az udhcpc csomag, és indítás után képes elég minimálisra összehúzni magát. ( Próbálkoztam még csak az udhcp feature-rel újraforgatni a busybox-ot, de úgy is 700k lett. )

* Inetd/sshd. Azért egy linux nem linux, ha nem lehet rá bessh-zni. A folyton ramban állomásozó sshd nem pálya, inetd-ből illik ilyenkor igény szerint indítani. A default inetd sem túl nagy, de természetesen ebből is létezik egy mini verzió, aminek pont micro-inetd a neve. Ez a csomag neve debianon, ha neked nincs ilyen, akkor innen húzhatod: http://www.acme.com/software/micro_inetd/. Hiperfapad, cserébe hiperpici. A /etc/sv/inetd-ssh/run-ba elég beírni, hogy:

exec micro-inetd 22 /usr/sbin/sshd -i . Természetesen ezt is dietlibc-vel tálaljuk!

* Shell. A bash nagyon meghízott az utóbbi években. Bejött neki a jólét, és nem is hajlandó már kisebb lenni, dietlibc-nek már messziről sem köszön, egyszóval nem barát. Alsóhangon becuppant 4 megát, rémálmainkban se! De akkor mit? Van a debian default init sh-ja, a (d)ash, de ennek nagy hiányossága, hogy nem tud tab completiont. A zsh meg csh csak szimplán nagyok. Mi lehet az ideális? Hát a '83-mas Korn Shell, ami már mksh néven fut! ( http://mirbsd.de/mksh ) Puszta jófejségből kapunk a /bin/mksh mellé egy /bin/mksh-static -ot is. Érdemes ezt is újraforgatni, hogy a lehető legkisebb helyen elférjen, és a tabolást meg a history-t se felejtsük ki belőle! (HAVE_PERSISTENT_HISTORY) Nyugodtan cseréljük le a root, vagy bárki shell-jét erre: chsh root, /bin/mksh-static. Sőt: annyira kompatibilis a bash-sel, hogy az initscriptek is elmennek vele. Ezért nyugodt szívvel symlinkelhetjük sh-ként: ln -sf /bin/mksh-static /bin/sh. Eddig nekem nem volt gondom egyik initscript-tel sem boot folyamán, de számítsunk rá, ha valami emiatt dob majd failt. Nem csak dietás a libc-je, de még önmagában is sokkal kisebb, mint a libc6-os társa. Én már teljesen átálltam bash-ről erre más gépeken is, annyira megszerettem. Kezdésnek mutizom a ~/.mkshrc-met:

HISTFILE=~/.mksh_history

HOST=$(hostname)

PS1="$(print \\001)$(print \\r)$(print \\001)$(print \\033)"']0;${USER}@${HOST}: ${PWD##${HOME}/}'"$(print \\001)$(print \\007)"'[${USER:=$(id -un)}'"@${HOSTNAME:=$(hostname)} \$PWD]$(

if (( USER_ID )); then print \$; else print \#; fi) "

Csak hogy legyen promptunk is, vagy valami.

Még illik hozzátenni, hogy a busybox beépített ash-ja is alkalmas lehet a célra, csak nekem az initscript-ek failt dobtak rá bootnál, mivel a function-t nem ismeri, ezért kukáztam.

* udev. Nnna, ez az egyetlen, amivel nem tudunk mit kezdeni. Libc6-on dependel, ráadásul a systemd része...de az újabb kernelek annyira ráépülnek, hogy nehezen lehet megkerülni, és már a különböző programok/daemon-ok is igénylik, úgyhogy ezt el kell viselnünk a ramban. Van még egy eudev nevű gentoo-s forkja, ami nem dependel systemd-n, de az újabb fejlesztéseket későn vagy egyáltalán nem rakják bele, így egy friss rendszeren használhatatlan.

Ha mindent a fenti leírás alapján csináltál, akkor egy boot után getty-n belépve valami hasonlót kell tapasztalnod ps_mem-mel:

A képen ez a 3.4M még több is, mint amennyit te fogsz kapni. Hiszen itt van egy openvpn+sshd is - így screenshotoltam. Ennél jelentősen fogyókúrásabb boot utáni állapotot már nem lehet elérni. Ezután már az X is fürgébb lesz, ha ritkábban kell swap-elnie.

-- Ez itt a vége? --

Nem. Még van lehetőségünk további tuningokra. Minden gyakran használt programot (openssh, openvpn, vncviewer, dillo, netsurf, xmms, akármi) érdemes -Os -sel újrafordítani, kiszedegetni belőle a sosemhasznált libeket, végén meg stripet a binárisnak. Ez fakultatív, és tetszőleges időtartamig végezhető. Én a lassú hdd-n még alkalmaztam azt a trükköt, hogy az 1M-nál nagyobb binárisokat upx-szel becsomagoltam. ( ls -lrS ) Ennek elsősorban nem a helyfoglalás miatt van értelme, hanem egyrészt kevesebbet kell a hdd-nek dolgoznia, ha elindul, másrészt a filecache-be az upx-elt bináris kerül bele, így ott is kevesebbet eszik. A kicsomagolás ideje elhanyagolható még ezen a gépen is, az upx-ucl-t használva pedig még többletramot sem eszik ilyenkor. Mivel közel 30-40%-ra képes a binárisokat összezsugorítani, így sokat nyerhetünk vele a gyakran futtatott programoknál - especially mplayer, perl, python. ( http://upx.sf.net/ )

Debian-on az apt eléggé lassúcska. Kicsit azért lehet rajta segíteni. (csoda nincs!) /etc/apt/apt.conf:

DPkg::NoTriggers "true";

PackageManager::Configure "smart";

DPkg::ConfigurePending "true";

DPkg::TriggersPending "true";

APT::Install-Recommends "false";

APT::Install-Suggests "false";

Acquire::Languages "none";

Acquire::Pdiffs=false;

Packages::Compress "gzip";

Acquire::GzipIndexes "true";

Acquire::CompressionTypes::Order:: { "gz"; };

A /var/lib/dpkg dir-t érdemes btrfs-re symlink-elni a tömörítés és az autodefrag miatt. Ugyanígy a /var/cache és a /usr/share/doc is jobban érzi magát btrfs-en.

Ha valakit a sources.list érdekel, semmi extra nincs benne:

deb http://ftp.hu.debian.org/debian/ jessie main contrib non-free

deb http://ftp.hu.debian.org/debian/ jessie-backports main contrib non-free

deb http://ftp.hu.debian.org/debian/ jessie-updates main contrib non-free

deb http://security.debian.org/ jessie/updates main contrib non-free

deb http://www.deb-multimedia.org jessie main non-free

deb http://www.deb-multimedia.org jessie-backports main

A localepurge csomag lehetőséget ad arra, hogy a nem használt nyelvi file-okat és man page-eket egy mozdulattal törölhessük le. Ezzel száz megákat is nyerhetünk egy alap rendszer helyfoglalásán.

Ne felejtsük el sosem, hogy a swap a barátunk! Amit eddig smem-mel nézgettünk, hogy mennyi ramot eszik swap-ben és a ramban, az a hosszútávú használatnál már nem mérvadó. A swap arra való, hogy a nem használt programrészek a hdd-n pihizzenek, ne a ramban. Szóval ha az openssh kiswap-elte a krb5 supportot, akkor jól van az ott. A kezdőképen kicsi "csalás" van, mivel csak a ramban levő cuccokat számoltam össze, miközben a swap-ben még lézengett jópár. Csak mivel ezeket már nem használta egyik program sem futás közben (csak az indulásnál), ezért a 25 mega ram, az nem csalás, hanem tényleg annyi. Swap meg teszi a dolgát. Itt egy fullos screenshot, hogy még a dillo és tigervnc együtt fut:

És végülis a 15mega swap sem olyan veszélyes méret.

-- Élet X nélkül --

Meg kell még említeni, hogy a teljesértékű élethez nem feltétlen szükséges a grafikus felület. Mplayer-nek lehet vesa vagy svga outputja (hipsztereknek -vo aa), így videot nézhetünk, youtube-ozni ott az mps-youtube, zenét hallgathatunk mp3blaster-rel is, régi vnc kliensekből is találhatunk svga-sat, irssi ugye jó chat-re, mc filekezelőként x alatt is bevált, így konzolban sincs para vele. Egerezni jó a gpm, copypaste van benne, oszt ennyi. El lehet így éldegélni, de inkább csak demonstratív célokra jó.

Akinek az ls/cut/sed és társai is túl nagynak bizonyulnak, az ezeket mind besymlinkelheti a busybox-ra, ami a fapadért cserébe gyorsabb futással és kevesebb memóriahasználattal jutalmaz. Én ezt már felesleges szőrözésnek érzem p233-on, talán 66mhz alatt lenne valami hatása.

Még a btrfs-en lehetne spórolni, hiszen 1 megát kér a ramból, viszont cserébe az on-the-fly compression-ért nekem ez megéri. Ha minden bit számít, akkor csak ext3 mindenhova.

Ha sok kis file-t akarunk tárolni, akkor érdemes squashfs-be rakni őket. Ezek után a file-okat már vígan lehet mountolni -o loop-pal. Egy példa a c64 zenegyűjteményre: összesen 46176 file és 274M. Ebből 76M lesz squashfs-ben, és még a defrag-gal sem kell törődni. (mksquashfs C64Music C64Music.squash; mount -o loop C64Music.squash C64Music)

Praktikus még a cron-ba rootként bebiggyeszteni egy * * * * * timeout 10 rdate -s wwv.nist.gov sort, hogy az óra is helyesen ketyegjen. (Szegény ember chrony-ja.)

Ha 'sok' ramod van, és egy-két binárist és lib-jeit mindenképpen benne szeretnél tudni (pl. mksh, xmms, sshd), akkor némi memóriáért cserébe ezek sosem swap-elődnek ki a memlockd csomagot használva.

-- Vége --

Hát így ennyi. Ennyit a userspace ramhasználat kimaxolásához; kernelspace ram-ról meg talán legközelebb - vagy nem. Lehetne még faragni a biteket, ám ez nekem már elégséges állapot. Ha meg esetleg tudsz egy klafa kicsi dhcp klienst, meg is írhatod: DC-1@scene.hu