Ez a nap is elérkezett - a türelmem vége. Szerintem én elég türelmes ember vagyok, hiszen Bagojné már 3 hónapja  minden gép indításkor azzal piszkál, hogy "Vajon mi nem fog most működni a Linuxodon?". Pedig nem is Neki kellett elviselni az alábbi tortúrákat:

• Bármilyen csomag telepítése esetén gyomor összeszorulás, mert 95%-os biztonsággal egy teljes rendszer frissítést kell futtatnom, hiszen az a csomag, amit a rendszerem jelen állapotában leszedne, már nem létezik a csomagtárban.
• A rendszer frissítésekor az elmúlt fél évben ötször fordult elő feloldhatatlan körkörös csomagfüggés, amire egy kis force-szal kellett rásegíteni
• Programok vándorolnak csomagok között, lecserélődnek rendszeresen a dolgok: net-tools --> inetutils, kmod --> module-init-tools, consolekit --> logind, init --> systemd, udev --> systemd-tools stb.
• Frissítéskor rendszeres, hogy kézi beavatkozás szükséges: filesystem csomag, a /lib könyvtárból szimbolikus link lett (be kellett bootolni a telepítővel!), pacman csomaghitelesítés bekapcsolása, fontconfig frissítés

Talán legjobb, ha a fentieket egy igaz történetben foglalom össze: két héttel korábban frissített rendszernél szerettem volna felrakni a gnome-mplayer csomagot, mivel kis feleségem nem tudja az mplayert (ami már telepítve volt) paraméterezni, viszont DVD lemezt akart nézni. Természetesen már nem jött le a csomag, ment a pacman -Syu, ami kiírta, hogy a /lib-nél konfliktus van. Megyek a fórumra, oké rendben, az ott leírtak alapján járok el, sajnos errorokkal elszáll az egész. Szerencsére volt install cd-m, reboot, kézzel átraktam a /lib könyvtárat, tar-ral felraktam a glibc csomagot, reboot és glibc újratelepítés.

Eközben a nejem egy darabig állt mellettem az egy szál DVD-vel, látványosan ásítozott, aztán kiröhögött majd elment, hogy akkor majd holnap. A legfanatikusabb Arch rajongót is frusztrálna, ha élete párja folyamatosan a kedvenc terjesztését szapulja (és sajnos joggal!). :-(

Ezen felül már csak olyan "apróságok" vannak, hogy a múltkori downgrade óta is volt, hogy 20 percig nem kapott IP címet a gépem. Mióta Arch van fent, azóta a Gthumb nem tud fotókat importálni, parancssorból kellett gphoto2-vel (értem én, hogy egyszerű a dolog, de a családom nem ezt azonosítja a felhasználóbarátsággal).

A kaput végül az tette be, hogy egyik reggel melóhelyre akartam bevinni pár fájlt (=siettem), és egy pendrive-ot dugtam be, amin Arch telepítő volt éppen (amikor a downgrade-et telepítettem, visszabootoltam a 2012.07-es ISO-ra), mondom gyorsba meg kéne formázni. Hát, dosfstools nincs fent alapból, és mivel épp nem kaptam IP-t, le sem tudtam húzni (arról nem beszélve, hogy az megint egy system upgrade lett volna). Nem baj, megformázzuk ext3-ra, aztán majd csak elolvasom valamivel. Hát igen, de a partíció csak 400 megabyte, a többi szabad terület. Jó, akkor fdisk. Ha a pendrive bent volt, az fdisk panaszkodott, hogy felcsatolt eszközt nem célszerű partícionálni, és nem is látta a partíciót, ha eject-eltem, akkor meg nem látta az eszközt. Ezek után oda kellett kúsznom Bagojnéhez, hogy megformázhatnám-e a Windowson ezt a pendrive-ot?

Egy férfi önbecsülésének ezek a történetek nem tesznek jót, higgyétek el.

Körbenéztem a "piacon", szerintem nekem a Debian lesz a legjobb. Persze a Wheezy, ami jelenleg testing, de már eléggé kiforrott. Van hozzá 3.4-es Gnome, ami eddig a legjobb változat, sajnos a 3.6 nekem már nem tetszik annyira.

Kívánok mindenkinek sok szerencsét és még több megelégedettséget az Arch Linuxhoz! Én búcsúzom tőle, mivel az operációs rendszert nem önmaga buherálásáért használom, hanem egy stabil alaprendszert szeretnék, amin alkalmazásokat futtatok. Remélem, a Debian beváltja ilyen irányú reményeimet. Nemsokára jelentkezem a telepítés leírásával. :-)

Mindig tanul az ember valamit, és Linuxon ez hatványozottan így van. Ezért szeretjük, hiszen így nem kell minden nap zombiként, lógó nyállal ugyanazt az unalmas felületet bámulnunk, és megvan az életünk fűszerezése. :-)

A hét elején ismét frissült az Arch (azaz: én frissítettem). Megkaptam a 3.6.6-os kernelt és egyéb nyalánkságokat is. Sajna a reboot után azt vettem észre, hogy a wi-fi egyáltalán nem működik - az interfészt látom, fel is lehet húzni, sőt, rá is tud csatlakozni az Access Pointra, de IP címet már nem kap.Ez azért is elkeserítő, mert amióta 3.6.3-as volt, azóta rosszalkodott, többször neki kellett futni, mire IP-t kapott a wifiről. Mivel a wifi-s szkriptem ezt kezelte, mindössze várnom kellett egy kicsit, ami nem volt kellemes, és akartam is foglalkozni vele a lehető leghamarabb, miközben reménykedtem, hogy megjavul magától. :-) Most már muszáj volt lépnem.

Felhúztam tehát a szemöldököm, és előkaptam egy kábelt, hogy azzal kapcsolódjak a kis routerre. Ott kaptam IP címet, de kb. fél perc után leszakadt a netről, és csak a kártya lekapcsolása, majd felhúzása segített csak, de az is csak egy újabb fél percig. A dmesg ezt mondta:

NETDEV WATCHDOG: eth0 (sis190): transmit queue 0 timed out

Rákerestem az "arch kernel 3.6.6 network problem" kifejezésre, találtam is egy Arcsis fórumot, de segítséget nem igazán. Annak viszont a fele sem tréfa, hogy lényegében net nélkül maradtam. :-( Arra gondoltam, hogy valahogyan visszarakom a régi kernelt, hogy legyen stabil net, hiszen anélkül bugreportot se tudok adni, meg tovább keresgélni sem a megoldás után.

Hogyan lehet egy régi kernelt visszarakni?

Aszongya a downgrading packages oldal, hogy a /var/cache/pacman/pkg alatt ha még ott vannak a régi csomagok, akkor egyszerűen

pacman -U /var/cache/pacman/pkg/<csomagnév>

Nade mi van, ha nincsenek meg? Mint pl. nálam... :-D

Van egy nagyon egyszerű és hatásos, ráutaló nevű csomag, amit most ajánlok mindenkinek felrakásra. Ez a downgrade nevű, AUR-on keresztül elérhető programocska egy bash szkript. Telepítése úgy történt, hogy

1. Az oldaláról letöltöttem az AUR kátránylabdát ("download tarball" a jobb oldalon).
2. Kicsomagoltam a tar.gz-t és futtattam egy "makepkg -scr" parancsot. Ez felrak minden függőséget, ami a fordításhoz kell, majd el is távolítja azt, ezért szoktam mindig így használni, habár most az egyetlen függőséget, a wget-et fent hagytam. Az eredményképpen előálló downgrade-3.2-2-any.pkg.tar.xz nevű, immár Arch Linux csomagot természetesen
3. A pacman -U downgrade-3.2-2-any.pkg.tar.xz felrakta szép rendben (ez ismét lehúzta volna a wget-et, mint függőséget, ezért is hagytam fent)

Miután feltettem a downgrade programot, a régi csomagok telepítése gyermekien egyszerűvé vált. Példa:

downgrade linux


(Itt a linux ugye a linux kernel-t jelenti!) Ekkor lelistázza, hogy milyen régi csomagokat talált (keres gépen, illetve az ARM (Arch Rollback Machine) nevű weboldalon), és szépen listázza őket. Kiválasztjuk a nekünk tetszőt, letölti a /tmp könyvtárba és a pacman segítségével felrakja. (Nem kell root-ként futtatnunk, sudo-t használ és a megfelelő időben bekéri a jelszót.)

Még kis probléma lehet, hogy a letöltött régi csomag ütközik, vagy jelen pillanatban nem teljesíthető függőségei vannak. Ez nem gond, ilyenkor ne rakjuk fel a csomagot, hanem töltsük le hasonlóképpen a függőségeit is a /tmp alá, majd kézzel egy jól irányzott pacman -U segítségével felrakjuk őket egyszerre, így már nem lesz probléma a függőség.

Ez a downgrade szkript olyan jófej, hogy ezután azt is megkérdi, hogy betesszük-e a nem frissítendők közé a most downgrade-elt csomagot, nehogy a következő pacman -Syu felülvágja - ekkor ugyebár a /etc/pacman.conf fájlba írja bele az IgnorePkg szekcióba ezeknek a csomagoknak a nevét elméletileg - gyakorlatban nem vettem észre, hogy megcsinálná, majd figyelek a legközelebbi frissítéskor.

Felraktam hát a 3.6.2-1 kernelt, és az nvidia 304.51-4 verzióját, hiszen különben nem indult volna el az X a legközelebbi rebootkor. Ezután reboot, és voilá, nagyszerűen megy a wifi is.

Ennyit mára az Arch világából, remélem legközelebb nem olyannal jelentkezem, hogy egy frissítés elrontott valamit... :-)))

Utóirat: Ez az ARM egyébként félelmetes. Időbeli bontásban tartalmazza minden hivatalos Arch csomag visszamenőleges változatait, így akár össze lehetne hozni egy szkriptet mondjuk azzal, hogy én szeretnék visszaállni arra az állapotra, amiben pl. 2012 március 27-én volt a rendszerem. Ezzel a rolling distro nem csak előre, hanem hátra is görgethető. Nyilván nem fogom kipróbálni, hiszen elég kevés az esély, hogy ebből konzisztensen jöjjön ki a rendszer, de akinek sok ideje van, belefoghat, hiszen mint megtudtam, az Arch a buherálásról szól. ;-)

Ne gondolja senki, hogy az a célom, hogy ekézzem az Archot, mert távolról sem ez a helyzet, én csak használni szeretném napi szinten. Nyilván arról nem írok semmit, ha minden jól és megelégedésemre működik, hiszen ez eléggé unalmas lenne leírni, hogy "ma sem történt semmi". Bezzeg, ha valami probléma van, főleg ha fel is bosszant egy kicsit, akkor rögtön megjön az ihlet is! Lássuk hát, mi történt nemrégiben.

pacman -Syu


Ez a sor elég sok embernek ismerős, ez egy rendszer frissítés, amit az Arch Linuxot használók elég gyakran kiadnak. Én, óvatos duhaj lévén, csak vasárnaponként, és akkor sem minden héten. :-) Most telepítenem kellett egy új csomagot, ezért jobbnak láttam, ha a rendszerem naprakész. Eléggé meglepődtem, hogy 300+ megabájtot kell letölteni, ami kicsomagolva 1,6Gb+, és a fél rendszerem le lesz cserélve. Node miért is ne, hiszen kockázat nélkül nincs győzelem, ugyebár... :-)

Lejött a sok száz mega, figyelgettem fél szemmel, mi történik, a policykit könyvtárára panaszkodott, hogy 0750 és szerinte 0755 kéne, egye fene, megadtam neki. Ezen felül semmi extra, úgyhogy reboot, aztán hadd hasítson a legújabb nVidia meghajtó, ami a gyártó szerint akár kétszeres gyorsulást is hozhat a sebességben (nem mintha játszanék, hehe). Semmi különös nem történt, úgyhogy (az nVidia és az új kernel miatt) reboot.

Hoppá, hát a gdm az sajnos nem indult el, nade miért? A /etc/rc.d/ alól el is tűnt a gdm szkript, csak nem átdolgozták systemd-re? De igen. OK, próbáljuk meg kézzel elindítani... nem megy, azt írja ki, hogy hiba történt, próbáljam meg még egyszer. :-( Itt az egyszeri programozó végtelen ciklusba keveredett volna, de 2-3 próbálkozás után beláttam, hogy ennek fel se tréfa. :-)

Egy kézzel gyorsan megírt .xinitrc segítségével elindítottam egy fapados X felületet. Erre azért volt szükség, mert egyrészt nincs konzolos böngészőm, másrészt firefox-szal sokkal egyszerűbb volt az archwikiben keresgélni. Milyen szerencse, hogy a wifi hozzáférést saját szkripttel oldottam meg, így nem kellett küzdeni még holmi network-managerekkel is.

A neten ajánlott "systemctl enable gdm" parancsra a "No connection to service manager" hibaüzenetet adta. Kis nyomozás után némi fény gyúlt a sötétségben: Azért nem tud csatlakozni a systemd-hez, mert nálam még a régi System V-os init fut, viszont ahhoz, hogy a gdm elinduljon, már a systemd-nek kéne lennie az 1-es processznek.

Akkor /boot/grub/menu.cfg szerkeszt, és a kernel sorhoz hozzátold még egy kicsit:

linux   /boot/vmlinuz-linux root=UUID=84671fe3-0dd3-4df1-a624-8d77f2d315d5 ro init=/usr/lib/systemd/systemd

Remélhetőleg értelemszerű, hogy az init= és az utána lévő részeket tettem én hozzá, és egyébként kiszedtem a "quiet" kapcsolót, hogy jobban lássam, mit is csinál ez a ördöngös systemd. Nos, remekül bebootolt, és a gdm is elindult - sajnos igen ronda lett a bejelentkező képernyő! :-(

Annyit tudok még hozzátenni, hogy a systemd-sysvcompat csomag felrakása távolítja el végleg az init-et, és akkor már nem szükséges megadni a kernelnek, hogy systemd-vel bootoljon.

Ennyit a mai ijedségről. De azért elmondom, hogy szerintem mi lett volna a felhasználóbarát megoldás egy, a felhasználókkal minimálisan is szimpatizáló, helyzetükbe magukat beleérző fejlesztőktől. Tudván, hogy ezt a terjesztést azok használják, akiknek van minimális érzékük a dolgokhoz, elég lett volna egy hasonló üzenet az új gdm csomag telepítésekor:

"Hey, you fuzzer! Note that gdm is not going to work with System V init anymore, so if you are planning to use mixed systemd and initscript environments in the future, change the kernel line in grub.cfg by adding init=/usr/lib/systemd/systemd. If you have already fully migrated to systemd, please dismiss this message."

Ennyi. Ja, mégsem:

• Az nvidia-settings nem megy, mert panaszkodik, hogy neki a libpangox egy régebbi verziója kéne, hát ez van amikor a lib frissül, a program, ami használja, az pedig még nem.
• Megújult a Nautilus felülete, sokkal kisebb helyet foglal már a fejléc, jobb lett
• Átdolgozták kicsit a gnome-shell indító felületét, ez határozottan rosszabb lett. Az alkalmazások nevei már meg sem jelennek, csak ha külön kattintunk egy ikonra a Favorites bar-on. Persze ha rákeresünk a nevére, akkor bejön, de ez nemtom... olyan nekem nem tetsző dolog
• Lecserélődtek az ikonok
• A képernyő zárolás elég érdekes lett, nem elég kattintani, hanem az egérrel felfelé el kell húzni a hátteret, mintha egy függönyt húznék fel. Elég feleslegesnek tartom...

Bár nagyon megszerettem az Arch Linuxot pár dolog miatt, amikor a héten olvastam, hogy átállnak az init scriptekről systemd-re, kissé felment a pumpa. Nem emiatt az egy hír miatt, hanem mert ez már a harmadik vagy negyedik olyan változtatás, ami alapjaiban rengeti meg a rendszert, mióta használom ezt a terjesztést.

Azon is felháborodtam természetszerűleg, hogy miért kellett a /usr/lib alá bemozgatni a /lib tartalmát, és miért szimbolikus linkkel kell helyettesíteni. Illetve; a probléma inkább nyilván az volt, hogy miért a felhasználókkal kell elvégeztetni az ehhez szükséges, rengeteg buktatóval teli munkát, amihez még külön wiki bejegyzést is írtak.

Ez előtt volt, hogy kiszedték az installert, erről írtam is egy kis bejegyzést.

Én csak használni szeretném az operációs rendszeremet, nem heti szinten hegeszteni. Volt idő, amikor bejött ez a dolog, akkor Gentoo-t használtam, és végül ott is belefáradtam a gyakori fordítgatásokba, amiket ott sem lehet hagyni, mert közben ír ki alapvetően szükséges megteendő lépéseket. Lehet, hogy múltkor rossz terjesztést választottam?

Talán ennyire nem gáz a helyzet. Viszont a heti hír, miszerint a jól átlátható, működésében tetszőlegesen befolyásolható systemV initscriptek lecserélésre kerülnek, és helyette a Red Hat által fejlesztett systemd lesz nemsokára az alapértelmezett, kicsit rosszul esett. A fő dolog, ami miatt az Archot választottam, az az volt, hogy az Ubuntut már nem lehet átlátni, rengeteg egymáshoz integrált szoftver dolgozik együtt és nem hagyja, hogy én megmondjam, mit is szeretnék a rendszeremmel. Itt pedig azzal kellett szembesülnöm, hogy havi szinten más irányt vesznek a fejlesztések, és a felhasználók csak lobognak a fejlesztők által keltett szélben.

Mi az az init és miért kellene lecserélni?

UNIX-alapú operációs rendszereknél az init a legelső processz, ami elindul, és direkt vagy indirekt módon az összes többi processz szülője. Őt a kernel indítja el közvetlenül, név konvenció alapján (a Linux kernelben az init=xxx paraméterrel állítható).

Az init futási szinteket (runlevel) használ, amely bizonyos szinten megmondja, hogy a rendszer milyen állapotban van. Sok implementációja van, de úgy kell elképzelni, hogy pl. 1-es egyfelhasználós mód, 2-es többfelhasználós mód, 3-as hálózat, 5-ös grafikus felület, 6-os reboot, 0-ás leállítás. Az "init 1" paranccsal például át lehet váltani egyfelhasználós módba, ha ezt az adott UNIX változat támogatja. Indításkor az init belenéz a /etc/inittab fájlba, és annak megfelelően elindít egy nagy halom egyéb szkriptet és programot. A bootkor elindítandó funkciókat shell szkriptekkel oldották meg, ezek elég lazán vannak egymáshoz csatolva és nagyjából egymás után futnak le; viszont megadható, hogy melyik futási szinten melyik szkript fusson le. Általában minden szoftver komponens indítására és megállítására is van szkript ("komponens" alatt olyanok értendők, mint pl. az X-Window, szerverek esetén a különböző szolgáltatások stb); például az X indító szkriptje az 5-ös runlevelhez van hozzárendelve, a megállító a 0-ás és 6-oshoz minimum, de pl. ha meg akarjuk teremteni a lehetőségét a 3-as szintre visszavaló váltáshoz, akkor oda is be kell tenni a leállítási szkriptet (ha grafikus felületből valaki visszavált sima parancssoros multiuserre, akkor le kell állítani az X-et).

A fenti leírás alapján is látszik, hogy ez egy mondhatni ősi, robosztus, könnyen szerkeszthető és bővíthető rendszer; viszont az is, hogy amikor megtervezték, a mai igények nem léteztek. Az indítandó processzek párhuzamosítása, az indítások optimalizációja és az ehhez szükséges függőségi tábla (tehát hogy pl. az X elindításához kell networking, dbus és log gyűjtés) még egyáltalán nem volt napirenden, hiszen ha egy UNIX szerver nem 2 perc, hanem 2:30 alatt indul el, az senkit nem érdekel, hiszen 5 évente van újraindítva. Csakhogy, a Linux ma már jóval több, mint egy UNIX szerver változat.

Initng-launchd-systemd-upstart

"Mi lenne, ha meg tudnánk határozni, hogy a processzek hogyan függnek egymástól, és így optimalizáltabban lehetne elindítani őket? Mi lenne, ha kihasználnánk a több processzor és processzormag előnyeit a párhuzamos indításhoz? Mi lenne, ha nem korlátozott számú futási szinthez, hanem szinte tetszőleges eseményhez lehetne kötni a programok elindítását?"

Ilyen gondolatok bukkantak fel a fejlesztők fejében az utóbbi időben. Nem lenne pompázatos, ha mondjuk

• akkor indulna el a bluetoothd, ha csatlakozni szeretnénk egy másik Bluetooth-os eszközre? A CIFS akkor indulna el, ha odaváltok a Windows megosztás könyvtárára?
• a letöltő alkalmazás szólhatna a network szolgáltatásnak, hogy "kis barátom, ne állj le, még hátravan 300Mb"?
• nagy terhelés esetén a rendszer el tudná dönteni, hogy melyik processznek ad több kapacitást?

Valóban nem rossz gondolatok ezek. El is indult jó pár kezdeményezés az init leváltására, és bár ennek már több éve, az init még mindig elég jól tartja magát. Miért van ez?

Az init előnyei

• Az init egyszerű és egységes, míg a "trónkövetelők" még nem forrták ki magukat, többen is vannak tehát nehéz a választás
• a szoftverek indítására az init szkriptek már készen vannak, minek változtatni, ha valami működik?
• sokak szerint felesleges ez az "anyáskodás" a processzek felett, az init lazán csatolt működése bevált és jól kontrollálható
• Az init szkriptekbe bárki belenyúlhat, és bár igaz, hogy a bash interpreter mindig lassabb lesz, mint egy erre a célra írt szoftver, a flexibilitás kárpótol

Mindkét tábornak van sok követője; és lehet találni összehasonlításokat, amelyek persze általában a saját megoldás fényezésére vannak kihegyezve. A legegyszerűbb megnézni, hogy nekünk mire van szükségünk és az alapján választani.

Mi is a bajom?

Nem a systemd-vel van bajom egyáltalán, hanem az Arch-os hozzáállással, ahogyan átrendezik a rendszert hétről hétre, és emellett nem adnak a felhasználók számára sem választási lehetőséget, sem segítséget mondjuk egy automatikus migrációval; jó ha egy-egy wiki oldalt kapunk arra, hogy annak segítségével áthegeszthessük a rendszert, pedig nem is akartunk hozzányúlni. És ha ezt nem tesszük meg, akkor a rolling distro repo-k változása miatt két hét múlva már nem tudunk egy programot telepíteni, mivel annak már új verziója az aktuális, ami mellesleg magával vonzza a fél Gnome frissítését is. Öreg vagyok és csak használni szeretném a rendszeremet, nem folyamatosan foltozgatni!

Jó dolog a Gnome3, a Gnome-shell elég stabil és gyors, bár bevallom, elég sok memóriát eszik. Még jobbá tehető az ún. extension-ök segítségével, amelyek az alap funkcionalitást egészítik ki, vagy változtatják meg.

Elöljáróban javaslom a gnome-tweak-tool telepítését, ha még nincs fent; ugyanis nem csak a gnome-shell kiterjesztések, hanem egyéb gnome3-mal kapcsolatos beállítások is kényelmesen kezelhetők ezzel.

A telepítés a weboldalról nagyon egyszerű, igen hasonló a Firefox kiterjesztések felrakásakor megszokotthoz:  egyszerűen az ON-OFF gombra kattintunk, és egy megerősítést követően már fel is telepítődik a kis programocska. (Megjegyzés, hogy ehhez szükséges a "Gnome Shell Integration" plugin a Firefoxhoz, ami Arch alatt alapból felkerül.)

Megjegyzés: Ezek a kiterjesztések a gépünkön a saját home könyvtárunk alá a .local/share/gnome-shell/extensions könyvtárba kerülnek.

A Gnome3 előtti világban lévő működést állít vissza ez a hasznos kis kiterjesztés, ugyanis nekem kissé kényelmetlen, hogy az alt-tab-ra megjelenő alkalmazás-listában csoportosítja egy alkalmazás ablakait és azt elég nehézkesen lehet előhozni. Persze működik az egy alkalmazás ablakai közötti váltás az Alt+0 segítségével, de az meg nem vált az összes között, szóval kényelmetlen. A legjobb, amit találtam, az kicsit talán túl látványos, de nekem éppen megfelelő, a képernyőmentésen látható, hogy hogyan néz ki.

3. Apps Menu

Én elégedett vagyok a Gnome-shell overlay módjával, de van akinek hiányzik a Gnome2 start menüje; ezt a funkciót hozza vissza a kiterjesztés. Esetleg ehelyett az Axe menu is használható, ha valakinek jobban tetszik.

2. Window List

Olyan őskövületek számára készült, mint én vagyok - a task bar-ra visszarakja az alkalmazáslistát, ugyanis alapértelmezésben csak az overlay módban (Super billentyű leütése után vagy az egeret a bal felső sarokba húzva) látjuk a futó alkalmazásokat (igaz, ott legalább bélyegképként).