arch első benyomások

Kezembe került egy netbook (Compaq Mini CQ10-500), és úgy döntöttem, annyi idő után épp itt az ideje, hogy kipróbáljam az Arch Linuxot.
A választás azért esett rá, mert errefelé ódákat zengenek róla, valamint úgy fest, hogy pici és gyors lévén netbookra jobb (de nehezebb) választásnak tűnt. Időm volt, belevágtam.

Szó se róla, tényleg többet kellett olvasni a telepítéshez, mint az Ubuntunál, de egyáltalán nem különösebben bonyolult. Ami egy picit trükkösebb volt, az a lemez particionálása, amit valami miatt nem lehetett a telepítőből elvégezni. Szerencsére, mint minden valamire való rendszer, ez is live CD, csak grafikus felülete nincs. Így hát rövid parted-bűvészkedés és mkfs után lehetett folytatni a telepítést.

A rendszerben nem csalódtam, tényleg eléggé kicsi, és tényleg elég gyors, kb. 20 másodperc alatt el is indul. A beállítások fapadosak, netkapcsolat nélkül nyilván nem vág bele az ember.

Ami problémát meg kellett oldani, az a wireless adapter, ugyanis nem ismerte fel magától, hogy néhány modult blacklistelni kell hozzá.

Ami jelenleg probléma, az a memóriakártya-olvasó, mivel az nem megy, és ez alapján a launchpad bejegyzés alapján nem is nagyon sanszos…
Valakinek működik a fenti gépen?
Az lshw-gtk ilyeneket ír róla: 

Unassigned class
…
product: Realtek Semiconductor Co., Ltd. [10EC:5288]
vendor: Realtek Semiconductor Co., Ltd. [10EC]
…
resources:
	memory: 53000000-5300ffff
this device hasn't been claimed

szerk.: a probléma megoldódott. A Realtek honlapjáról letöltött driverforrást le kell pörgetni, fel kell rakni, és örülni, hogy működik.

szerk. 2: Ez az AUR nagyon jó dolog, főleg yaourttal. Eleinte nem értettem, miért lehet szerkeszteni telepítés előtt a PKGBUILD-et, aztán megpróbáltam gimp-nightly-t telepíteni, és sajnos megértettem.
Az Arch-gurukat kérdem, mi a teendő akkor, ha a PKGBUILD rossz URL-t mutat?

Az, hogy letöltöm a forrásfájlokat, felrakom a localhoston lévő webszerverre, és a valós dolognak megfelelően szerkesztem át a PKGBUILD-et, nos, finoman szólva is hackszagú, és arra emlékeztet picit, mint amikor a SuSE Linuxomat barmoltam szét kezdőként.

Más: a GIMP nem működik jól Python3-mal – van rá valami kulturált mód, hogy a Python2-t felrakva azt használja? A Python3 legyakása számomra nem tűnik kulturáltnak, gondolom van erre valami szép megoldás.

szerk. 3:
Megint más: ezen a gépen nincs home, end, page up, page down. Windows alá elvileg összeraktak egy programot „nem próbáltam, megy-e wine alatt” ;)
Mivel ezt én használom, kerestem a billentyűzeten pár gombot, amire rámappelhetem. Eredetileg à la EeePC a kurzorgombokra szerettem volna, csak Fn helyett AltGr-rel, ami amúgy is kényelmesebb, azonban ez nem működött:
xmodmap -e "keysym Left = Left NoSymbol Left NoSymbol Home"
Sejtem, hogy valahogy engedélyezni kéne az AltGr-t a kurzorbillentyűkre, de ennyire nem ástam bele magam.
Így egy Eee-hez hasonlóan kifacsart megoldást leltem: mivel az alábbi karaktereket (ä,Ä,đ,Ð) ritkán használom, illetve ä esetében jobban kézre áll a "¨+a" megoldás számomra, ezekre rendre ráraktam a Home, End, Page Up, Page Down billentyűket, ami már sikerült. Jelenleg így fest az Xmodmap fájlom: 


! No Caps Lock
clear lock
! Caps Lock as Win key
add mod4 = Caps_Lock
keycode 77 = Num_Lock
! jobb oldali control compose key, ezekhez: kulonfele kotojelek, harmaspont, (c), (r), TM
keysym Control_R = Multi_key
! altgr + o,p,z --> magyar illetve angol idezojelek
keysym o = o O o O doublelowquotemark Oslash
keysym p = p P p P rightdoublequotemark THORN
keysym z = z Z z Z leftdoublequotemark leftarrow 

! altgr-buveszkedes
keysym e = e E e E Prior
keysym d = d D d D Next
keysym a = a A a A Home
keysym s = s S s S End

Ami így nem megy, az például a sor elejéig való kijelölés Shift + AltGr + A-val.

szerk.: Az akksiról…
No, mint látjuk, a gép hardveresen nem minden tekintetben a legjobb, ez az akksiban is megmutatkozik:
27.54 Wh lenne elvileg a design capacity, ezzel szemben a last full capacity 26.028 Wh. Ennek nem örültem. Ma cserébe meglestem azt is, hogy mennyit bír a gép. Nos, körülbelül 2.5–3 órát, ami netbookok körében elég rossznak számít, cserébe egyébként sem kifejezetten jó. Jelenleg a gépen egy grafikus alkalmazás fut, a GDM, és futtatom rajta a powertop-ot, hogy meglessem, mennyit fogyaszt alapjáraton.
A fogyasztás 6.5 W és 9 W között váltakozik (átlag így ránézésre 8 W), ez alapján tehát az üresjárati akkuélettartam 2.9 és 3.4 óra közé tehető.
Összehasonlításképp:
Jelenleg használok még egy Acer TravelMate 5720-asat, ennek fogyasztását még nem láttam 15 W alá menni.
Korábbi gépem ThinkPad R50e volt, annál a legkisebb mért fogyasztás 8 W volt, de jegyzetelés közben felmehetett 10 W-ra.
Az a gyanúm, hogy az új gép a napi felhasználás során a 4.5 éves ThinkPadre jellemző fogyasztást fogja mutatni, ami nem túl lenyűgöző, tekintve hogy amaz ugyanezen értékeket másfélszer ekkora képátlójú kijelzővel tudta. Számítási teljesítményben nyilván elmarad a 4.5 éves Pentium M processzor egy mai Intel Atomtól, de a felhasználási terület (jegyzetelés, főként Vimben) szempontjából ez kevésbé lényeges.

( batyu v | 2011. 02. 17., cs – 06:03 )

Nem csak a gimpnek kell, csomó másnak is, de fel lehet tenni a python2-t (nálam mondjuk fenn volt, amikor a váltás jött) mellé, a legtöbb csomag fel van készítve rá, ha igényli a python2-t, akkor nem a default helyen keresi. Mondjuk AUR-ra nem vennék mérget, akadtam már olyanra, amihez ki kellett emiatt egészíteni a pkgbuildet, érdemes figyelni mikori az utolsó frissítés, ill. mit írnak a hsz-ekben alul.

( kmARC v | 2011. 02. 17., cs – 08:10 )

Jó az az Arch, én eddig ezzel állítottam össze a leggyosabb, legkevesebb memóriát evő, vagy legenergiatakarékosabb notebook rendszert. De kb. egy hónap után, a 10. frissítés környékén összeszarta magát. Először valami lib nem frissült, míg a ráépülő másik lib meg igen, aztán kernel pánik volt egy frissítés miatt, elég sokszor.

Sajnos nincs időm arra várni, hogy majd a következő frissítés hátha megoldja (amióta linuxozom, mindig erre várok valamivel:) ), így hagytam a fenébe. Hobbirendszernek nagyon jó, a legtestreszabhatóbb, de sajnos vannak hibái.

És az intel comiler által sem támogatott platform :)

+1 Plusz oda kell figyelni a frissítések mellé érkező figyelmeztetésekre (csak zárójelben jegyzem meg, hogy kpackagekit és packagekit-pacman megléte esetén mármár ubuntu szintű kényelemmel lehet csomagkezelni, és az értesítések is okosan figyelmeztetnek a systray-ről) és akkor sok problémát csírájában meg lehet oldani.

Érthető, mert nem ez a neve :-) A packagekit pacman interface az ami kell, az most ha jól látom már be van építve a packagekit-be. Korábban határozottan emlékszem hogy külön csomag volt aur-ban. Jelen pillanatban yaourt-tal szépen fel lehet húzni függőségestül, én meg nem figyletem, mit is húz még magával, polkit, pacman-glib, packagekit-qt kell neki az biztos.

+1 ugyanez masfel evvel, honorshark anno elinditotta itt azt a legendat, hogy a pacman -Syu nem biztonsagos update, aztan azota midnenki tenykent kezeli ezt.

Gyakrolati peldakent osszesen annyit lattam masfel ev alatt, hogy eygszer egy Xorg verzio lassult be picit (xorgek hibaja volt, 1 napra ra jott a patch) meg egyszer kihagytak a kdelibset az uj KDE verziobol (par oran belul fixaltak), meg a 2.2beta krusader szerintem nem illett stabil csomagok koze (ctrl+alt+esc-kel kellett kilepni gyakrolatilag belole, hogy ne maradjon bent processek kozt)

Bar hozzatennem, hogy nekem meggyozodesem, hogy Arch inkabb Desktopra valo mint szerverre.

meg azert nem art neha odafigyelni a pacman uzeneteire (utolag okosan pacman logjara) neha egy-ket dolgot at kellhet konfigolni, de olyankor szol a pacman, es ezt nem szoktak elszurni

De ha megis elkefelodne ugy, ahogy meg nem lattam elkefelodni, akkor is ott a cache, amiben benne van helyileg minden regebben hasznalt csomag torlesig (torolni akkor fogsz belole, ha epp minden megy). Aki meg nem kepes chrootbol downgrade-elni egy csomagot, az meg ne hasznaljon (Desktopon) Linuxot

> ugyanez masfel evvel, honorshark anno elinditotta itt azt a legendat, hogy a pacman -Syu nem biztonsagos update, aztan azota midnenki tenykent kezeli ezt.

Hmm.. nem tudtam erről a divathullámról, én azért kezelem tényként, mert három kernel pánik után meguntam, és más rendszert telepítettem.

package downgrade chrootbol? Esetleg elgondolkodas custom kernelen (es ahhoz megfelelo blacklistezes)? Fuggetlenul attol, hogy en meg nem futottam Arch-csal eddig tobb gepen se kernelpanicba, de ha ez meg is tortenne atneznem mi van. Mondjuk lehet en is masik distrora mentem volna, de sok olyat lattam mar, hogy bizonyos konfigok allergiasak voltak nehany distrora, volt amelyiknek a gentoo live cd se tetszett (nyilvan kernelt sokfelekeppen lhet binarissa tenni es patchelni)

Nem, pont az ilyen szopásokra nem volt időm.

Az Archról azt gondoltam, hogy ez ahhoz eléggé karban van tartva, hogy mindennapi használatra ne kelljen pöcsölni ilyesmikkel, ugyanakkor, ha van egy kis szabadidőd, szénné optimalizálhatod pl.: energiafelhasználás szempontjából. Emellett szeretem a tooljait is, a netcfg-menu pl.: nagy kedvencem lenne. A kernel panic viszont egy frissítés után jött, és én pont nem tudtam kivárni, amíg helyrepofozzák. antiemes HUP-os kolléga mondta, hogy tudtak a hibáról, és pár nap után javították.

Hát ez van, rossz benyomás volt, bárhol előfordulhat, de Ubuntunál még nem történt meg velem, Archnál meg igen. (BTW. Ubuntut sem szeretem :) )

egy package-et downgrade-elni live cdrol chrootbol kb 5 perc, cache-ben meg ha nem torlod, ott vannak a regi (elozo verzioju) csomagok, net se kell hozza :) Bar az mn3monic fele "ezzel kezdem a melot" dolgokat en se szivesen vallalnam be ilyen hirek utan, fugetlen attol, hogy en meg nem futottam bele semmilyen katasztrofaba

> ott vannak a regi (elozo verzioju) csomagok
Igen, ezzel tisztában vagyok, de ha pl.: Ubuntu-ban elromlana ilyesmi, akkor ott egyszerűen a bootkor az előző biztos kernellel bootolnék (és még ki is választhatom, összesen hány régi kernel maradjon meg. Legalábbis régen meg lehetett adni)

És mi akadályoz meg benne, hogy egy másik kernelt bootolj?

Ennek számtalan módja van, a legegyszerűbb az ha a kernel26-lts csomagot feltelepíted és azt hozzáadod a /boot/grub/menu.lst-hez.

Már talán több mint 4 éve vagyok Arch Linux felhasználó és látom az árnyoldalát annak, hogy egyre népszerűbb ez a disztribúció.

Még annak sem vagytok képesek utánnanézni, hogy hogyan lehetséges biztonságosan frissíteni úgy hogy utánna szükség esetén azonnal és kézenfekvő módon rollbackelni.

"és még ki is választhatom, összesen hány régi kernel maradjon meg."

Arch Linuxban is minden ilyen lehetőség adott, a legfőbb különbség, hogy ezt neked kell megvalósítani, mert ez nem Ubuntu, hanem egy disztribúció középhaladóknak. Ha ez nem tetszik, mégis miért használtok Arch Linuxot?

( ijanos | 2011. 02. 17., cs – 09:09 )

a yaourt nemtudom most milyen, régen nagyon bugos/lassú volt, manapsága puritánabb (értsd: nem színes) packer -t használom.

PKGBUILD szerkesztés:
megoldás 1) szerkeszted az URL-t helyesre
megoldás 2) letöltöd a pkgbuild fájlt beteszed egy könyvtárba, letöltöd a jó forrást, beteszed mellé, kiadod a makepkg parancsot, elkészül a csomag és telepítes pacman -U
nem kell semmit trükközni localhost szerverrel.

A GIMPet valszeg újra kéne fordítanod ha python2t szeretnél használni, de ha jól meg tudod indokolni a bugtrackerben hogy miért nem működik jól akkor rá lehet venni a deveket hogy még egy darabig python2vel forgassák.

( Zaneck | 2011. 02. 17., cs – 14:44 )

"Eleinte nem értettem, miért lehet szerkeszteni telepítés előtt a PKGBUILD-et"

Mert a csomagépítő rendszer (ABS) része, a csomagok felépítéséhez szükséges utasításokat tartalmazza.

https://wiki.archlinux.org/index.php/Pkgbuild
https://wiki.archlinux.org/index.php/Creating_Packages

"a valós dolognak megfelelően szerkesztem át a PKGBUILD-et, nos, finoman szólva is hackszagú"

Ez csak azért van, mert Ubuntuhoz stb. sohasem készítettél csomagokat. Az ABS használatához szükséges a PKGBUILD-ek elkészítése, módosítása.

"a GIMP nem működik jól Python3-mal – van rá valami kulturált mód, hogy a Python2-t felrakva azt használja"

A csomagtárolóban lévő GIMP azt használja, ha a nightly-t akarod buildelni akkor a PKGBUILD-ben specifikálnod kell, hogy melyik Python-t használja. 

sed -i 's|#!/usr/bin/env python|#!/usr/bin/env python2|' "${pkgdir}"/usr/lib/gimp/2.0/plug-ins/*.py

Értelmszerűen ezt a csomag felépítése és telepítése után is megteheted a /usr/lib/gimp/2.0/plug-ins alatti összes .py kiterjesztésű állomány #!/usr/bin/env python sorának #!/usr/bin/env python2-re cserélésével, többek között sed-el, awk-val vagy ami neked kézreáll.

https://wiki.archlinux.org/index.php/Python

Mert a csomagépítő rendszer (ABS) része, a csomagok felépítéséhez szükséges utasításokat tartalmazza.

Ja jó… Azt hittem, hogy nem a csomagépítő, hanem a csomagkezelő része, így már világos. Eddig az AUR-t olyasminek gondoltam, mint egy közösségileg karbantartott forrásrepót, amit megtámogattak némi buildscripttel.

Ami meg a GIMP-et illeti, egyelőre nem nagyon mélyedtem bele a PKGBUILD rejtelmeibe (megszoktam, hogy nem hackelek, hanem használom a gépet). A probléma az volt, hogy fordításidőben panaszkodott az egyik script, hogy a „sys” modult ő bizony nem találja. Biztos ami sicher rákerestem, de tudtommal ez elvileg része az alap pythontelepítésnek. Mindenesetre legyaktam a 3-asat, és felraktam a kettest. Minden működik, ahogy kell, könnyen lehet, hogy már nem tudom meg, hogy lehetett volna a hármassal megoldani a dolgot. 

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

"az AUR-t olyasminek gondoltam, mint egy közösségileg karbantartott forrásrepót"

Az is, és a PKBUILD-ek ennek a szerves részét alkotják, elvégre a csomagépítéshez kellenek.

"megszoktam, hogy nem hackelek, hanem használom a gépet"

Akkor minek van szükséged a gimp-nightly-ra? És hogyan oldottad volna meg a buildelését vagy a csomagépítést más disztribúciók alatt?

"Mindenesetre legyaktam a 3-asat, és felraktam a kettest. Minden működik, ahogy kell, könnyen lehet, hogy már nem tudom meg, hogy lehetett volna a hármassal megoldani a dolgot."

Lehet, hogy nem kellene Arch Linuxot használnod, mert már mindent leírtam arról amit tudnod kell.

A GIMP bővítmények Python 2-re lettek írva, ezért egyáltalán nem kompatibilisek a Python 3-al.

Akkor minek van szükséged a gimp-nightly-ra? És hogyan oldottad volna meg a buildelését vagy a csomagépítést más disztribúciók alatt?
Ubuntu alatt van nightly build repó, és a sima buildelést pedig nem nevezem hackelésnek. De newbieként a PKGBUILD átszerkesztését úgy értékeltem, mint a csomagkezelő lelkivilágába való belenyúlást, ami mint SuSE alatt megtanultam, általában nem jó.
@batyu: newbieként az AUR-t nem tartom hackelésebbnek, mint Gentoo alatt az emerge-öt.

Lehet, hogy nem kellene Arch Linuxot használnod, mert már mindent leírtam arról amit tudnod kell.
No igen, viszont mire leírtad, addigra már „megoldottam” a problémát a fenti módon. Legközelebb majd jobban beletúrok a PKGBUILD-be, de frisshusiként úgy gondoltam, hogy az egy veszélyes dolog, de ezek szerint mégsem az… ☺ 

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

"beletúrok a PKGBUILD-be, de frisshusiként úgy gondoltam, hogy az egy veszélyes dolog, de ezek szerint mégsem az"

Nem az, sőt lényeges és kihagyhatatlan része a csomagépítésnek, leszámítva, hogy az AUR tartalmaz sok mások által elkészített PKGBUILD-et.

A bináris csomagforrások PKGBUILD-jei is elérhetőek többek között webes felületről az archlinux.org-on (Package Actions -> SVN Entries)

"A bináris csomagforrások PKGBUILD-jei is elérhetőek többek között webes felületről az archlinux.org-on (Package Actions -> SVN Entries)"
Tegnap használtam is, ha nem is onnan (egy "pacman -G fontforge"-ot nyomtam, mert eredetileg nyilván nem volt belefordítva, hogy használja az AUR-ból elérhető libspirót.)

int getRandomNumber() { // ←ez itt már az aláírásom
 return 4;//szabályos kockadobással választva.
}  //garantáltan véletlenszerű. xkcd

( Boobek | 2011. 02. 17., cs – 18:04 )

sub, Én is váltani akarok, de vagy a cd íróm szart be, amit nem hiszek, vagy a x64-es telepítőcd-vel van valami probléma.. 2x kiírtam, ugyanott readerror-ral elszáll.

Próbáltam unetbootin-al kiírni, pendrájvról telepíteni, leírás szerint. Hiába szerkesztettem át a sysconfig-ot sosem találta meg a pendrájvot, mint telepítőmédia..

Arch wikiben írták, hogy járható út az is, és mivel először azzal kezdtem, hogy unetbootinnal elkészítettem a médiát, így azt az utat jártam..
Másrészről meg rájöttem a hibára...
Gpartedben állítottam be a label-t, ami utána valahogy mindig más lett.. mtools-al átírtam, máris megtalálta a telepítő..