Kalandozások Linuxföldén

Első felvonás: Linuxos nomádok kalandozásai Windowsföldén

ERP rendszerünk vasárnap valamiért újraindult, Windows update 94%-nál megállt és valószínűleg pár órája úgy is van. Álmoskönyv szerint ilyenkor nem jó megzavarni a lelkivilágát (személy szerint ezzel csak és kizárólag rossz tapasztalataim van), de az üzemeltetés szerint sok jót ne várjunk a géptől: reset. Hál istennek akkor még felállt a rendszer. Délután, mikor beláttuk, hogy 12G rammal nem mehet tovább a gép, raktunk még 12G-t bele. Hiába, megnőtt picit az adatbázis. Na itt kezdődött az igazi szopás: újraindulás után minden BIOS beállítás elfelejtve, oprendszer nem található. Hopsz. Rövid vizsgálódás után kiderült, hogy a RAID vezérlő nem igazán akar élni. Másik LSI-s kártya ugyan lett volna raktáron, csupán egyetlen egy dolog nem: hozzávaló kábel. Az alaplap valami ASUS alaplap, valami PIKE nevű porton figyelt a RAID kártya és az alaplapon volt kivezetve SATA csatlakozókhoz. A RAID kártya viszont egy mini-SAS csatlakozóval rendelkezett, nekünk meg mindenünk volt, kivéve olyan kábelünk, ami azt normál (tápcsatis) SAS csatlakozókra alakítja át. Továbbá egy ismerősnek sem volt és ahhoz is késő volt, hogy elmenjünk érte valahova.

(Maga a gép egyébként kb. 4 éves, ironikus módon pont hétfő reggel döntöttünk arról, hogy cseréljük. Igen, egy tákolt szar. )

Mondom jó, átmásoljuk sima SATA diskekre, amúgy is kezdett már köhögni az egyik SAS disk. Van egy tesztszerverünk (az már legalább végre szerver - Fuji TX200 S5), átraktam diskeket oda, USB-re egy SATA-s, Ubuntu Live bebootol, másolnám át. Aham, leszámítva, hogy nem látja a RAID vezérlőt. Jó, akkor Centos minimal. Na az végre látja. Első körben amúgy a Sysrescuecd lett volna a tippem, leszámítva, hogy a sourceforge.net-ről nem lehetett letölteni, dd-vel átmásoltam, utána ment szépen. RAID-nak meg sima Windowsos softverres RAID lett beállítva, teljesítményben nem észlelni hátrányt eddig (igaz a 2x annyi RAM is rengeteget segít az MSSQL-nek.)

Apropó, dd. Hasznos egy tool, kétségtelenül. De olyan rohadt nehéz lenne implementálni bele egy szájbavert kapcsolót, hogy ugyan mondja már meg, hogy sacc/kb. mennyi idő múlva végez a másolással? Találtam ilyen csodaszép megoldásokat: http://www.cyberciti.biz/faq/linux-unix-dd-command-show-progress-while-… Persze, Centos Live-ban semmi nem volt meg abból, ami kellett volna. (Workaround: először átmásoltam kis mennyiséget, abból meg lett saccolva, hogy mennyi a teljes.)

Intermezzó: PHP. Facebook nem kedveli ezt.

Node ugorjunk. Adott ez a csodás hupu myth, hogy "de hát a Facebook is PHP-t használ!!!". A helyes megfejtés, leginkább az, hogy igen, valami olyasmit, ami egykoron talán az volt. No de ne szaladjunk ennyire előre. Ugye a kiinduló sztori az volt, hogy a Cukrosbácsi végigszivatta az FB-t PHP-vel, amiről ugyan egyszer megpróbáltak Pythnora áttérni, de hamar belátták, hogy 8M kódsort a büdös életben nem fog senki sem portolni. (És egyébként is, Joel Spolsky már rég megmondta, hogy miért fasság egy terméket újraírni.) Így jött az ötlet, hogy fordítsanak mindent C++-ra. Egy ideig jó volt, ameddig rá nem jöttek, hogy annyira azért mégsem. Egyik fő problémájuk - a hiányzó dinamikus nyelvi dolgokat leszámítva - a lassú fejlesztés volt, a nehéz optimalizálás, valamint az, hogy volt 3 féle verziójuk is belőle (HPHPc - fordításhoz, HPHPd - debuggoláshoz, HPHPi - interaktív dolgokhoz).

Aztán teltek, múltak az évek és megszületett a HHVM. Mi is ez? Gyakorlatilag egy JIT-teres PHP5.5, ami egy VM felett fut, hasonlóan a JVM-hez vagy a .NET-es CLR-hez. (Már látom a kialakuló flamet a C/Java, C# hívők között). Plusz megtoldották static typing lehetőségével (persze, meghagyva a dinamic typing lehetőségét), mindehhez statikus analizálást végző toolokkal (és akkor a Hupon lehurrognak mindig, mikor kijelentem, hogy a gyengén típusosság megnehezíti a fejlesztést), Hack langgal, mindenféle földi jósággal, pl. normális típusos collectionok, Generics, Nullable types*, normálisabb Lambda, async, stb. Egyébként annyira látszik, hogy a C#-ból lett egy csomó minden átvéve, amivel semmi probléma nincs, C# egy nagyon jól használható nyelv.

Ami kifejezetten tetszik az a nullable types kezelése: alapból semmi nem lehet null, kivéve, ha jelölve van, hogy az lehet null. (Ugyanúgy kérdőjellel, mint C#-ban, csak a típus előtt, nem utána). Ez igaz a referencia típusokra is. Ezen már egyszer elmélkedtem korábban is, hogy C#-ban a sok metódus elei

if (arg == null) throw new ArgumentNullException("arg");

helyett sokkal-sokkal szebb lett volna az, ha a referencia típusoknál kötelezővé teszik azt, hogy nem lehet null, kivéve, ha engedélyezve van. Na de lassan itt a Roslyn, ismerős szerint azzal elvileg valóra vállhat ez az álmom.

Második felvonás: Kell egy Linuxos disztro

Szóval jött az ötlet, hogy nézzük már meg a gyakorlatban is a HHVM-et. Először CentOS volt a kiszemelt áldozat, majd miután rá kellett jönnöm, hogy *minden* kőkorszak benne a feladat végrehajtásához, így letettem róla, és fogtam egy Ubuntut, amit láthatóan jobban támogatnak. (Igen, tudom EPEL, mondták időközben, de most a HHVM volt a cél, nem az, hogy random csomagokat vadásszak. Haladjunk.)

Ubuntuból 13.10 volt a kiszemelt áldozat, abból is a server verzió. Az egész egy Citrix XenServer-en belül települt, ott kiderült első körben, hogy a drága jó Citrix nem vett át egy kb. egy éves patchet, ami miatt az újabb Ubuntuk csesznek felmenni. De a diverzitás jó, megmondták a hupon! Utána a telepítőn fogtam a fejem több soron.

CentOS-nál valami egész használható, egyszerű grafikus telepítő van, amely van annyira okos, hogy ha úgy látja, hogy a VGA kártya (jelen esetben a Xen) nem képes eme roppant nagy feladat végrehajtására, akkor felajánlja a, hogy VNC-n keresztül futtasd a telepítőt. Ez azért tök jó, mert pl. az LVM-ről kap az ember egy szép grafikus áttekintést. Na, az ubuntu-server még mindig az ezer éves Debianos - szerintem unintuitív szart - hozza. Plusz, valami irreálisan sokat kérdez szerintem, mindezt nem ám egy szép csokorba szedve, hogy a végén csak a telepítés legvégét kelljen megvárni, hanem a telepítés legkülönfélébb pontján. Ezek közül a személyes kedvencem az, hogy megkérdezi kétszer is, hogy az óra hogy van beállítva, de arra már nem képes, hogy megkérdezze, hogy hogyan akarom a hálózatot használni. Kapott DHCP-n IP-t, szerinte ez így jól van, kuss. Majd utólag átállítja a parasztja, ha nem tetszett. Csak akkor tundám, minek kérdezi meg kétszer azt, hogy UTC-e az idő meg mégy egy csomó egyéb lényegtelen kérdést.

Harmadik felvonás: csak nem úszom meg az X-et

Amúgy alapvetően - a szokásos apróságokat leszámítva - innen már egészen eseménytelen volt (Linuxos mércével) az élet. Egészen addig, ameddig le nem vontam azt a következtetést, hogy kicsit C++-ozni kellene Linuxon.

HHVM-hez ugyanis van PostgreSQL csatoló, viszont nagy hibája, hogy nem a Facebook fejleszti, hanem pár arc, mert nekik is kellett és ők úgy gondolták, hogy a perzisztens kapcsolat nem annyira lényeges. Ami miatt viszont elkezdtem vizsgálódni HHVM ügyben, amiatt meg kifejezetten kell nekem egy connection pool. És mivel a fejlesztője nem tervezi a közeljövőben belefejleszteni, kénytelen vagyok magamnak megcsinálni. Ezért gondoltam, felrakok egy QtCreatort.

Negyedik felvonás: LVM

Első probléma ott adódott, hogy az alap 8G-s disk image (-swap) kicsinek bizonyult. Az külön vicces, hogy a tasksel valami totál irreleváns fals semmitmondó hibaüzenetet ad arról, hogy azért nem megy fel a csomag, mert kevés a hely. Itt jött az, hogy de jó, hogy LVM-re telepítettem.

Windowsban azt szeretem, hogy ha van rá mód és az ember tudja, hogy mit akar és nagyjából tudja, hogy hol keresse az adott dolgot, akkor _általában_ viszonylag intuitív (értsd: rájössz magadtól, triviáls dolgok miatt nem kell manualok olvasgatásával kezdeni) módon meg lehet csinálni dolgokat. (Ugyanez igaz OSX-re is, bár ott meg van toldva azzal, hogy néha roppant intuitív módon elrejtenek egy-egy funkciót, hogy ne is tudd, hogy létezik). Erre nagyon jó példa az, amikor kellett egy DNS-t beállítanom. Alapvető fogalmakkal tisztában voltam, a DNS beállító felületet meg kb. bárki elkezeli, aki tisztában van az egyes controlok működésével. Na egy Bind zóna fájlt nem írnék meg fejből magamtól. Ugyanez igaz például a Windowsos Volume Management-re is: jobb click a köteten, átméretez, megadom az új méretet, picit molyol, TADA.WAV.

Ezzel szemben az LVM-hez - bár léteznek grafikus toolok - alapból egy unintuitív CLI-s utilkupac van. Igen, tudom tanuljam meg, meg tök jó mert lehet automatizálni (FYI: ott a PowerShell, meg szerintem volt korábban is CLI-s mód Windowson), meg jajdemenő, hogy nem kattintgatni kell meg a többi. Bullshit. Az nem tudás, hogy tudom fejből, hogy most szóközzel vagy egyenlőségjellel, vagy csak egy betű után írva simán kell írni a paramétereket. Valami random Linux hívő ego-blogján futottam bele egyszer ilyenbe, ahol valaki azzal jött, hogy mennyivel okosabbak a Linuxosok, mert ezeket mind hogy tudják. Aha jó, az, hogy valaki autista és arra áll fel neki, hogy tudja, hogy minek kell szóközzel, minek kell kötőjellel elválasztani a paraméter nevét és értékét, ahelyett, hogy a tényleges feladatot egyszerűen meg lehetne oldani, az szerintem kezelendő. Meg ha pl. lett volna egy egyértelmű UI (és nem definiáltam, hogy console vagy GUI!), akkor valószínűleg nem lettem volna megvezetve, hogy pv-t is át lehet méretezni, nem kell újat létrehozni és arra extendelni a vg-t. Egyébként az is tök jó, hogy egy lépés helyett itt hat volt volt: cfdisk, partprobe (mert a cfdisk annyira intuitív, hogy képtelen szólni a Linuxnak, hogy változott a partíciós tálba, gondolom teljesen értelmetlen a feltételezés, hogy kellene) pvcreate, vgextend, lvextend, fs2resize.

Sluszpoén: ha a köteten nincs hely, az lvextend sem működik. Röhej.

Intuitív eszköz, mondhatni.

Az igazán ironikus meg az, amikor egy törzsgyökeres Linux user jön azzal, hogy "mert szart hasznalsz, yast install disk, aztan mar reg tul lennel rajta kattintgatva". Okay. :)

Ötödik felvonás: X forwarding, VNC, mert Linuxot továbbra is csak bottal vagyok hajlandó piszkálni

Első gondolatom az X11 forwarding volt. Itt meglepődve tapasztaltam, hogy Ubuntuban alapból be volt kapcsolva az X11Forwarding az sshd.conf-ban. A dolog egyébként egészen jól működött (bár teljesen vicces volt W7-es ablakkeretben a Gnome-terminal), egészen addig, ameddig nem akartam indítani egy QtCreator-t. Az ugyanis valami használhatatlanul lassan működött, pedig pl. egy Firefox is teljesen jó sebességgel ment. (100M lan van a két gép között).

Mondom jó, marad a VNC, akármennyire is utálom. Egy kis intuitív tutorial olvasgatás, intuitív konfig fájl heggesztés és intuitív xstartup birizgálás után életre is kelt a VNC szerver. (Hogy hány kőkorszakkal van lemaradva az RDP-hez képest, azt most nem részletezném). Qt Creator is használható sebességgel fut és majdnem jó volt minden, ameddig meg nem nyomtam egy d betűt. Meg a fel/le nyilat. Vagy a tabot. Gyügyüke úgy vette valamiért, mintha mindig megnyomnán a super/meta/cmd/windows keyt is. Neten utánanézve más is belefutott, keyboard configban állítsam át. Oké, nem indult. X11 forwardon elindult, opciót nem találtam. Mondom jó, gconf-editor talán segít. Az adott kulcs nem volt benne, amit írtak fórumon. Meguntam, akkor már dolgozni is akartam, felment az xfce4. Ott csak a tab nem volt jó, de a megfelelő XML-ben legalább meg lehetett találni a megfelelő sort. Hogy Linux + távoli használat még mindig szopás, az hihetetlen. (Legutóbb az rdesktop-al szoptam egy Debianon, hogy legalább a Windowson jó karaktereket kapjon a program. Igaz, ott a helyzetet - nagyban - súlyosbította egy vonalkód olvasó is.)

Konklúzió: 2014-ben (sem) nyűgözött le a "Linux destkop" és a Linuxos toolok kőkorszakisága, unintuitivitása.