After one week of holiday already passed by I finally write a post again. I used the last days to go through a lot of texts I missed in the last weeks as I was preparing for the exams of the semester. Now that I read everything interesting/important I finally started to improve the arch_chroot_packaging.sh yesterday.

So for now I'm finished with that and will use the cool parts of the day to learn for the study, while the rest of each is used for the stuff that comes up. However I'll be at the Arch booth at this year's FrOSCon 2010 I hope some of you will come there and visit us.

Yesterday evening td123 and wonder were so nice to update the shell functions I wrote in order to make work with different packaging-chroots even more comfortable.

alias mktesting="upchr testing64 && mkchr testing64 && upchr testing32 && mkchr testing32"
alias mkstable="upchr stable64 && mkchr stable64 && upchr stable32 && mkchr stable32"

# Update the given chroot/all
function upchr() {
        if [ $1 = "all" ]; then
                echo -e 'e[1;32mUpdating the e[1;31mstable32e[1;32m chroot.e[0m'
                linux32 sudo mkarchroot -u /var/chroots/stable32/root/
                echo -e 'e[1;32mUpdating the e[1;31mtesting32e[1;32m chroot.e[0m'
                linux32 sudo mkarchroot -u /var/chroots/testing32/root/
                echo -e 'e[1;32mUpdating the e[1;31mstable64e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/stable64/root/
                echo -e 'e[1;32mUpdating the e[1;31mtesting64e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/testing64/root/ 
        elif [ ! $1 = "" ]; then
                echo -e 'e[1;32mUpdating the e[1;31m'$1'e[1;32m chroot.e[0m'
                if [ $1 = 'stable32' ]; then
                        linux32 sudo mkarchroot -u /var/chroots/$1/root/
                elif [ $1 = 'testing32' ]; then
                        linux32 sudo mkarchroot -u /var/chroots/$1/root/
                else
                        sudo mkarchroot -u /var/chroots/$1/root/
                fi
        fi
}

# Build the package with the given chroot
function mkchr() {
        if [ ! $1 = "" ]; then
                echo -e 'e[1;32mBuilding package using the e[1;31m'$1'e[1;32m chroot.e[0m'
                if [ $1 = 'stable32' ]; then
                        linux32 sudo makechrootpkg -c -r /var/chroots/$1/
                elif [ $1 = 'testing32' ]; then
                        linux32 sudo makechrootpkg -c -r /var/chroots/$1/
                else
                        sudo makechrootpkg -c -r /var/chroots/$1/
                fi
        fi
}

# Create a set of stable chroots for both architectures
function create_stable_chroots () {
                sudo mkdir -p /var/chroots/stable64 /var/chroots/stable32
                # 64 Bit Chroot
                sudo mkarchroot /var/chroots/stable64/root base base-devel sudo
                sudo $EDITOR /var/chroots/stable64/root/etc/pacman.d/mirrorlist
                # 32 Bit Chroot
                sed -e 's@/etc/pacman.d/mirrorlist@/tmp/mirrorlist@g' /var/chroots/stable64/root/etc/pacman.conf > /tmp/pacman.conf
                linux32 sudo mkarchroot /var/chroots/stable32/root base base-devel sudo
                echo "Created stable32 and stable64 under ."
}

# Create a set of testing chroots for both architectures
function create_testing_chroots () {
                sudo mkdir -p /var/chroots/testing64 /var/chroots/testing32
                # 64 Bit Chroot
                sudo mkarchroot /var/chroots/testing64/root base base-devel sudo
                sudo $EDITOR /var/chroots/testing64/root/etc/pacman.conf
                sudo $EDITOR /var/chroots/testing64/root/etc/pacman.d/mirrorlist
                # 32 Bit Chroot
                sed -e 's@/etc/pacman.d/mirrorlist@/tmp/mirrorlist@g' /var/chroots/testing64/root/etc/pacman.conf > /tmp/pacman.conf
                linux32 sudo mkarchroot /var/chroots/testing32/root base base-devel sudo
                sudo $EDITOR /var/chroots/testing32/root/etc/pacman.conf
                sudo $EDITOR /var/chroots/testing32/root/etc/pacman.d/mirrorlist
                echo "Created testing32 and testing64 under ."
}
 

Edit 20100706: Thanks to mac_mario for notification about a typo in the text.

Wie man sieht, ist es hier im Blog recht ruhig geworden, das liegt vor allem daran, dass ich mich hauptsächlich auf mein Studium konzentriere und meine digitale Kommunikation zum größten Teil mittels Mailing Listen und kurzen Unterhaltungen via IRC/XMPP erledige. Dennoch ist es an der Zeit, auch hier ein Lebenszeichen von mir zu geben und auf Tätigkeiten meinerseits zu verweisen, welche nicht bloß für mich von Interesse sind.

Da wäre zum einen mein Artikel über die absoluten Grundlagen im Umgang mit dem Portscanner NMap in der diesjährigen Mai Ausgabe von freiesMagazin, durch welchen ich dank Hilfe der Redaktion auch einige Kniffe hinsichtlich verständlicher Formulierungen erlernt habe.

Zum anderen wäre da noch der Vortrag über Arch Linux, welchen ich im Rahmen des Faches Proseminar vor einem Teil meines Semesters geben musste durfte. Der Vortrag richtet sich vom Schwierigkeitsgrad her an ein Publikum, welches keine oder nur sehr geringe Kenntnisse über Linux Distributionen besitzt, dementsprechend einfach sind Handout und Folien formuliert. Beides findet man - zusammen mit den LaTeX Quellen - in meinem talks Repository bei github.

sECuRE veröffentlichte gestern i3 v3.ε. Neuerungen sind unter anderem:

• Umstieg von Xinerama auf RandR, Nutzer des Nvidia Treibers sollten sich unbedingt diese beiden Artikel anschauen: Multi-Monitor und Multi Monitor im Userguide.
• Der neue Konfigurationsparser ist nun Standard, ggf. sind also kleine Änderungen an der Konfiguration nötig.
• Der Funktionsumfang mittels IPC wurde vergrößert.
• Die Workspace Leiste lässt sich abschalten und durch eine andere ersetzen.

Mit diesem Release habe ich gestern auch das i3 Paket aus dem AUR in das ArchLinux community Repository verschoben, bei 56 Votes wird das sicherlich den ein oder anderen Archer freuen.

Links:
Projektseite
git Repository
i3-git im AUR
i3lock im AUR
i3status im AUR

Dieser Eintrag ist eine Übersetzung von brain0s Early Userspace in Arch Linux für jene Arch Linux Nutzer, welche mit dem Englischen dann doch ihre Probleme haben, keine Gewähr auf Fehlerfreiheit. Dieser Eintrag unterliegt nicht der im Impressum angegebenen Lizenz, die Rechte liegen bei Thomas Bächler, die Übersetzung ist mit seinem Einverständnis erfolgt.



In letzter Zeit gab es einige große Änderungen bei Archs Programmen des fühen Userspace. Also dachte ich mir, dass ich mir die Zeit nehme und allen diese Änderungen erläutere.

Bootvorgang von Linuxsystemen: Wofür braucht man einen frühen Userspace?

Früher war das starten eines Linux Systems einfach: Der bootloader lud den Kernel, dieser wurde extrahiert und initialisierte die Hardware, danach initialisierte er den Festplatten-Controller, erkannte die Festplatte und das sich darauf befindliche Root-Dateisystem, band dieses ein uns startete /sbin/init.

Heutzutage gibt es eine gigantische Menge an unterschiedlichen Controllern und eine große Anzahl unterschiedlicher Dateisysteme, da wir eine ordentliche Distribution sind möchten wir alle unterstützen. Also bauen wir sie alle in unser monolithisches Kernelimage welches nun mehrere Megabyte groß ist alles bis zur Küchenspüle unterstützt, aber dann kommt jemand und hat zwei SATA-Controller, drei IDE-Controller, sieben Festplatten sowie drei externe USB-Laufwerke und wer weiß was. Der Kernel erkennt diese nun alle asynchron, aber wo ist nun bitte das Root-Dateisystem? Ist es auf der ersten Festplatte? Oder auf der dritten? Was ist "die erste Festplatte" überhaupt? Und wie binde ich mein Root-Dateisystem in der LVM Laufwerksgruppe im verschlüsselten Container auf dem Software RAID-Array ein? Wie man sieht wird das alles etwas hässlich und der Kernel stellt sich gerne dumm oder kümmert sich einfach nicht um diese nervtötenden Probleme, besonders nachdem er durch uns - die wir ihn mit jeden erdenklichen Treiber gefüttert haben - so fett wurde.

Was nun? Ganz einfach, wir übergeben die Kontrolle dem Userspace und regeln die Erkennung der Hardware dort, richten den ganzen komplizierten und von den Leuten gewünschten Kram ein, binden das Root-Dateisystem ein und starten /sbin/init selbst. Nun frägst du dich sicherlich "Wie führe ich Applikationen im Userspace aus, wenn das Root-Dateisystem nicht eingebunden ist?" die Antwort darauf lautet "Magie!".

Was ist initramfs?

Naja die Antwort ist nicht Magie. Die Antwort lautet eigentlich initramfs: Jedes Linux System hat ein ramfs Dateisystem, welches immer eingebunden ist und rootfs heißt. Wahrscheinlich wirst du dieses nie sehen, da deine wirklichen Dateisysteme es nach dem Einbinden überdecken. Allerdings führt der Kernel auch ein komprimiertes cpio Archiv mit sich, welches direkt nach dem Start in das rootfs extrahiert wird. Noch besser: Es ist sogar möglich aus dem Bootloader heraus ein solches Archiv an den Kernel anzuhängen, welches dann ebenfalls in das rootfs entpackt wird.

Bevor der Kernel den altmodischen init Code ausführt, prüft er, ob das rootfs eine Datei namens /init enthält, ist dies der Fall überspringt er den klassischen Einbindungs- und Initcode und führt stattdessen /init aus. Nun liegt die Verantwortung für diese Aufgabe, welche für den Kernel als zu kompliziert eingeschätzt wird, bei diesem Programm. Auf diese Weise können wir einen Kernel, welcher keinerlei eingebaute Unterstützung für einen Festplatten-Controller auch nur für irgendein Dateisystem bietet(das ist eigentlich, was wir mit dem Arch Linux Standardkernel machen) bauen und fügen die benötigten Module schlichtweg in das initramfs Image ein.

klibc - Das Fegefeuer für die Initramfs Maintainer

klibc wurde ursprünglich als kleine leichtgewichtige C Bibliothek für den frühen Userspace entwickelt. Sie bringt einige Programme mit, welche einem dabei helfen alles Einzurichten. Mit klcc führt sie sogar ein hässliches Perlskript mit, welches den gcc aufruft und Binärdateien gegen die klibc anstatt die übliche libc linkt. Als Aaron Griffin 2006 mkinitcpio als Ersatz für die alten, unflexiblen Skripte mkinitrd und mkinitramfs entwickelte, wurde entschieden es auf klibc basieren zu lassen. Von Anfang an hatte klibc Probleme:

• Das Set an mitgelieferten Programmen war begrenzt und den Programmen fehlten wichtige Optionen.
• Die meisten externen Programme liesen sich nicht gegen die klibc linken oder mussten dafür stark gepatcht werden.
• Es gab keinen dynamischen Linker, alle Binärdateien wurden statisch gegen eine spezifische Version der klibc gelinkt, diese Version änderte sich mit jeder Änderung an den klibc Quellen oder der Kernelheader, was dann wieder den Neubau aller - gegen die klibc gelinkten - Binärdateien nötig machte.
• Es war nicht möglich andere dynamische Bibliotheken, als die klibc selbst zu erstellen.

All das resultiere in großem Arbeitsaufwand für die Instandhaltung von udev und den module-init-tools, wir mussten auch ein kleines klibc-extra Paket verwalten, welches die fehlenden klibc Programme mit unseren eigenen ersetzte. Fortgeschrittenere Programme wie lvm oder cryptsetup mussten wir statisch gegen die glibc linken und so bereitstellen.

Irgendwann war klibc inkompatibel zu den Kernelheadern und wir mussten mehr und mehr Hacks einführen um es aktualisieren zu können. Seit Linux 2.6.30 war ich nicht in der Lage überhaupt eine funktionierende Version der klibc zu bauen, was uns mit einer alten Binärdatei zurückließ, bei welcher wir nicht einmal mehr Bugs fixen konnten. Mitte 2009 starb dann upstream vollkommen, keine commits ins git Repository und acuh auf der Mailingliste gab es nur eine Hand voll Mails pro Monat. Das brachte mich dazu, mir folgende Frage zu stellen: "Worin besteht der Sinn eine seperate C Bibliothek zusammen mit Programmen zu verwalten, welche nur für den Bruchteil einer Sekunde beim Start des Systems Verwendung finden?" Außer einem kleineren initramfs Image und dadurch verkürzte Bootzeit vermutlich nichts.

Es einfach halten

2009 entschied ich dann, dass um eine initramfs Umgebung mit geringem Verwaltungsaufwand, vielen Funktionen und großer Flexibilität, die folgenenden Änderungen nötig waren:

• Verwendung der C Bibliothek des Systems und keiner seperaten.
• Die Verwendung von busybox für grundlegende System- und Skriptingprogramme, um einen guten Kompromiss ziwschen hoher Funktionalität und kleiner Dateigröße zu finden.
• Die Verwendung von util-linux-ngs blkid, um Label von Dateisystemen, UUID und Typerkennung vollständig für alle neuen und alten Dateisysteme zu haben.
• Die Verwendung von modprobe, udev, lvm, cryptsetup, mdadm/mdassemble aus den normalen Arch Paketen für weitere fortgeschrittene Funktionen.

Auf diese Weise müsste ich neben mkinitcpio selbst nur noch eine ordentlich konfigurierte busybox Binärdatei verwalten. Ich setzte busybox seit geraumer Zeit auf meinen OpenWRT Routern und wusste daher wie beeindruckend es war. Es stellte sich außerdem heraus, dass die Implementierung von NFS Root-Unterstützung einfacher war, wenn wir die mit der klibc gelieferten Programme nfsmount und ipconfig nutzten.

Nun ist es Februar 2010 und in den letzten Wochen hatte ich endlich die Zeit, die ganze Arbeit zu erledigen. Erst vor wenigen Tagen veröffentlichte ich mkinitcpio 0.6, diese Version ist deutlich stabiler, flexibler und weniger fehleranfällig als jede klibc-basierte Version die wir je hatten. Das initramfs ist nun um Durchschnitt 600KB bis 1MB größer, ich glaube nicht, dass sich deswegen jemand beschwert, es ist immer noch kleiner als bei den meisten anderen Distributionen. Ich bin froh, dass ich hoffentlich nie wieder mit klibc zu tun haben werde.

As ArchLinux user one has to build his packages in chroots in order to make sure, that everything is fine with them and the package will build on other people's machines. ArchLinux provides several scripts which makes this easier with the devtools package. How they are used is described in the DeveloperWiki. So as you can see this is really simple but if you have a real build machine and want to build your packages with different chroots it helps a lot to have a function in your shell configuration, note that I use a x86_64 system, so the last two functions need small modifications to run on an i686 installation.

alias mktesting="mkchr testing64 && mkchr testing32"
alias mkstable="mkchr stable64 && mkchr stable32"

# Update the given chroot/all
function upchr() {
        if [ $1 = "all" ]; then
                print 'e[1;32mUpdating the e[1;31mstable32e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/stable32/root/
                print 'e[1;32mUpdating the e[1;31mtesting32e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/testing32/root/
                print 'e[1;32mUpdating the e[1;31mstable64e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/stable64/root/
                print 'e[1;32mUpdating the e[1;31mtesting64e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/testing64/root/ 
        elif [ ! $1 = "" ]; then
                print 'e[1;32mUpdating the e[1;31m'$1'e[1;32m chroot.e[0m'
                sudo mkarchroot -u /var/chroots/$1/root/
        fi
}

# Build the package with the given chroot
function mkchr() {
        if [ ! $1 = "" ]; then
                print 'e[1;32mBuilding package using the e[1;31m'$1'e[1;32m chroot.e[0m'
                sudo makechrootpkg -c -r /var/chroots/$1/
        fi
}

# Create a set of stable chroots for both architectures
function create_stable_chroots () {
                sudo mkdir -p $1/stable64 $1/stable32
                # 64 Bit Chroot
                sudo mkarchroot $1/stable64/root base base-devel sudo
                sudo $EDITOR $1/stable64/root/etc/pacman.d/mirrorlist
                # 32 Bit Chroot
                sudo sed -e 's/x86_64/i686/g' $1/stable64/root/etc/pacman.d/mirrorlist > /tmp/mirrorlist
                sed -e 's@/etc/pacman.d/mirrorlist@/tmp/mirrorlist@g' $1/stable64/root/etc/pacman.conf > /tmp/pacman.conf
                sudo mkarchroot $1/stable32/root base base-devel sudo
                echo "Created stable32 and stable64 under ."
}

# Create a set of testing chroots for both architectures
function create_testing_chroots () {
                sudo mkdir -p $1/testing64 $1/testing32
                # 64 Bit Chroot
                sudo mkarchroot $1/testing64/root base base-devel sudo
                sudo $EDITOR $1/testing64/root/etc/pacman.conf
                sudo $EDITOR $1/testing64/root/etc/pacman.d/mirrorlist
                # 32 Bit Chroot
                sudo sed -e 's/x86_64/i686/g' $1/testing64/root/etc/pacman.d/mirrorlist > /tmp/mirrorlist
                sed -e 's@/etc/pacman.d/mirrorlist@/tmp/mirrorlist@g' $1/testing64/root/etc/pacman.conf > /tmp/pacman.conf
                sudo mkarchroot $1/testing32/root base base-devel sudo
                sudo $EDITOR $1/testing32/root/etc/pacman.conf
                sudo $EDITOR $1/testing32/root/etc/pacman.d/mirrorlist
                echo "Created testing32 and testing64 under ."
}
 

If your shell is not bash compatible, the functions may need small modifications.

Heute Nacht wurde i3status von sECuRE in Version 2.0 freigegeben. Ich zitiere einfach mal den Kern der Announcement Email:

i3status version 2.0 has just been released. It is considered stable and every
user should upgrade. The list of changes since version 1.2 follows:

 * add support for disk info (free/used/ins)
 * add support for displaying the ESSID of the wireless interface
 * add support for getting the public IPv6 address of the system
 * all "modules" now support format strings
 * switch to libconfuse for parsing the config file
 * merge support for FreeBSD for many "modules"
 * drop support for wmii, add support for xmobar
 

Links:
i3status Projektseite
i3status im AUR
i3status-git im AUR

Nun, dieses Jahr sind meine Sommerferien ja deutlich länger als sonst, was neben der üblichen Entspannung auch einige Pläne mit sich bringt, Hochschuleinschreibung ist so gut wie abgehakt, Führerscheinausbildung im Gange und auch auf technischer Seite sind einige Dinge in Bearbeitung, unter anderem:

• Objective-C: Zwar eher für Apple Systeme zu gebrauchen, jedoch hat js mich nun doch dazu gebracht, mir das Ganze mal anzuschauen und eventuell mit seinem libobjfw zu verwenden.
• PL: Etwas das ich schon seit Jahren vor mir herschiebe, ein kleines Strategiespiel, angelehnt an die Schlachten der Suikoden Reihe, vorerst mit simpler ncurses Dialog Steuerung, soll später aber mal ein ordentliches ncurses Spieleframework werden(Also mit Szenarien, welche Story, Initialwerte beherbergen und einem entsprechenden Editor.), momentan schwanke ich noch zwischen C und ObjC für den Code. Ein öffentliches Repository wird es auch erst nach dem ersten Release geben.
• Ansonsten sind da auch einige Shellscripte am gedeihen, zum einen aur-repo, zum verwalten eines lokalen Repositories, welches Pakete aus dem AUR beiinhaltet, Stefan Husmanns autoaur hat dies nicht so wie von mir erwünscht erledigt, zum anderen gen_tarballs, welches mir beim aktuell halten meiner AUR Pakete hilft.

Ansonsten steht dann kommende Woche auch der Besuch der FrOSCon auf dem Programm, ich bin gespannt wen ich neben den Angekündigten noch treffen werde.

Xyne hat kürzlich eine recht nützliche Tray Applikation veröffentlicht, unibrow - ein kleiner Browser für Unicode Zeichen, so spart man sich das oft nervige durchstöbern einer entsprechenden Website und kann sich, wenn man mehrere Zeichen sucht, die Applikation fix in den Tray packen. Wer desöfteren mal Unicode Zeichen sucht, sollte mal schauen ob das für ihn von Vorteil ist.

Links:
Projektseite
PKGBUILD
Thread im offiziellen Archforum(archlinux.org)

Nun wer kennt das nicht, man ist mal eine Weile nicht zu Hause, ein Familienmitglied muss an einen Computer und schaltet das zu Hause gelassene Gerät an. Nun hat man unter Umständen das Problem, dass eben jenes Familienmitglied keinen Account am entsprechenden Gerät hat und sich dementsprechend nicht anmelden kann.
Dies war die Ausgangssituation für ein Gespräch mit einem Bekannten, welcher dieses Wochenende auf einem Festival verbringt und Angst hatte, dass jenes Familienmitglied dann in Panik einfach die Steckerleiste abschaltet, was einen Schaden im Dateisystem zur Folge haben könnte. Nachdem wir dann einige einfachere Hilfsmittel als, in seinem Falle, zu schwach erklärt hatten(Netzkabel mitnehmen, Netzteilschalter) kam uns dann die Idee, durch setzen des Runlevels auf 0(Halt) mittels anhängen einer 0 an die Kernelzeile des Booteintrages in der /boot/grub/menu.lst ein direktes sauberes Herunterfahren des Systems sicherzustellen.

Dank gebührt an dieser Stelle einem einige Stunden zuvor aufgetretenen Problemfall in #archlinux.de, welcher mittels der selben Technik(nur mit Runlevel 3 als Ziel) gelöst wurde, ansonsten wäre wohl Rechner aufschrauben und Stecker ziehen die gewählte Lösung geworden.

Da ich von mehreren Personen gefragt wurde, warum ich die letzten zweieinhalb Wochen hier nichts geschrieben habe, fasse ich die vergangenen Tage einfach kurz zusammen und gebe anschließend einen kurzen Ausblick auf die nächsten Wochen.

Nun, die meiste Zeit der vergangenen Wochen ging, wie immer für die Nachtruhe drauf, dicht gefolgt vom Lernen, sowohl in der Schule als auch zu Hause, zwar idle ich nach wie vor in IRC und MUCs, aber doch stiller als üblich. Grund hierfür ist, dass bis Anfang Mai die Noten der einzelnen Fächer feststehen müssen und Mitte Mai beginnen die schriftlichen Prüfungen, also werden in jedem Fach noch Klausuren fällig und am besten fängt man schonmal mit der Wiederholung des Stoffes des letzten Jahres an. Meine verbleibende Zeit verging dann mit einigen Kleinigkeiten, die hier keiner Erwähnung wert sind, abgesehen davon habe ich ein paar weitere PKGBUILDs ins AUR gestellt und bei github ein Repository für eben diese angelegt habe, hauptsächlich um Überblick über Änderungen zu behalten. Am Donnerstag habe ich mit mit dem NoName EV Heidelberg auch noch einen regionalen, dem CCC nahestehenden, Verein gefunden, wenn es mein Zeitplan erlaubt, werde ich nach den schriftlichen Prüfungen mal eines ihrer öffentlichen Treffen besuchen.

Da, wie gesagt, noch Klausuren und anschließend die Prüfungen auf dem Plan stehen, wird sich hier in den nächsten Wochen weiterhin recht wenig tun, es sei denn, jemand verrät mir einen Weg zur Allwissenheit (die (temporäre) Allmächtigkeit wäre auch sehr willkommen ).

Nachdem Tblue mir im Sommer die Mitteilung machte, dass unsere Notebooks zwar Schalter für Bluetooth Adapter besitzen, die Adapter jedoch nur in den teureren Modellen der Acer5220 Serie verbaut sind, hatte mit dem Thema eigentlich abgehakt.

In den vergangenen Wochen jedoch las ich das ein oder andere Paper zu diesem Thema und als ich Mitte vergangener Woche feststellen durfte, welche Möglichkeiten moderne Handys mit dieser Technologie bieten war mein Interesse dann vollends wieder da, nur einen Stick hatte ich bis dato nicht. Nun gut diese Woche sind hier in Baden-Württemberg Ferien, also hatte ich vor mich an einem Vormittag in der zweiten Hälfte der Woche auf den Weg zu einem der bequem erreichbaren Elektronikmärkte zu machen. Naja das kann ich mir sparen, denn als heute mein alter Herr von der Arbeit heim kam, war das erste was er mir in die Hand drückte ein Bluetooth-Stick(Kommentar: "Den hab ich bei mir im Schreibtisch gefunden, den hab ich vor nem Jahr gekauft weil ich dachte das sei ein normaler USB-Stick." in die Hand. Dafür gibt es dann erstmal ein Kreuz im Kalender, denn a) gibt er Fehlkäufe nicht zu und b) meint es das Glück/Schicksal/$Ähnliches gut mit mir, von meinen Plänen wusste der Herr nämlich nichts.

Also erstmal den Artikel im archlinux.org-Wiki durchgelesen und die entsprechenden Pakete installiert, das Dongle eingesteckt und erleichtert aufgeatmet, denn prinzipiell funktioniert alles, abgesehen von der Tatsache, dass der passkey-agent nicht im bluez Paket enthalten und auch ansonsten nicht aufzufinden ist. Da ohne diesen leider, weder die von mir gewünschte obexfs Methode, noch die grafischen Programme(blueman, gnome-bluetooth und bluez-gnome) mit meinem Handy Kontakt aufnehmen können, bin ich da momentan etwas aufgeschmissen.

$ lsusb
Bus 005 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

$ hciconfig -a hci0
hci0:   Type: USB
        BD Address: 00:15:83:B4:01:71 ACL MTU: 384:8 SCO MTU: 64:8
        UP RUNNING PSCAN 
        RX bytes:7264 acl:144 sco:0 events:252 errors:0
        TX bytes:2634 acl:90 sco:0 commands:111 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
        Link policy: RSWITCH HOLD SNIFF PARK 
        Link mode: SLAVE ACCEPT 
        Name: 'hellgate-0'
        Class: 0x0a010c
        Service Classes: Networking, Capturing
        Device Class: Computer, Laptop
        HCI Ver: 2.0 (0x3) HCI Rev: 0x7a6 LMP Ver: 2.0 (0x3) LMP Subver: 0x7a6
        Manufacturer: Cambridge Silicon Radio (10)

Nachtrag 20:03: Der Bugtracker bringt mit Ticket #12851 die Antwort, leider ist Damjans Repository momentan nicht zu erreichen, also werde ich wohl in Ruhe den PKGBUILD anpassen und das Paket neu bauen, ein Hoch auf das ABS.

Nachtrag 20:33: So, kernel.org ist leider quälend langsam gewesen(1.3KB/s im Schnitt), aber der Rest ging flott und ohne Probleme, mein Handy ist mountbar, auch wenn es nicht viel bietet.

Nächstes Wochenende ist AWAT, der Grund für meine bequem sitzenden vier Buchstaben, sich zu erheben, das archlinux.de Wiki zu durchstöbern und zu schauen wo mein - doch recht junges - Wissen denn von Nutzen wäre. Laut AWAT-Artikel fehlt momentan noch ein Artikel zu Fluxbox, wenn ich, bei den drei Klausuren im Verlauf der nächsten Woche, bis Donnerstag dazu komme einen halbwegs vernünftigen Artikel zu schreiben, werde ich mich wohl für diesen eintragen, allerdings muss ich mich auch erstmal mit der MediaWiki Syntax vertraut machen.

Seit Sonntag befindet sich X.Org 7.4 in archlinux' extra-Repository, nachdem ich Sonntag Nachmittag die ersten Erfahrungen anderer User im IRC und der deutschen Community abwartete und las, wagte ich dann am späten Montagnachmittag das Update am PC, was dank Rücksprache mit Bluewind relativ problemlos von Statten ging(da auch ein neuer Kernel installiert wurde, war auch ein Reboot nötig, welcher dann natürlich von fsck-Durchlauf über die 500GB Archiv-Festplatte verlängert werden musste... ). Da es trotz Sammelthread und Wiki-Artikel(Artikel im englischsprachigen Wiki) immer noch einige Unklarheiten bezüglich des Touchpad Treibers synaptics gab, nahm ich mir vor, noch einige Tage mit dem Update am Notebook zu warten.
Nun gut, seit Montag kamen einige neue Berichte hinzu und auch der Wiki-Artikel wurde um einen entsprechenden Eintrag erweitert, weshalb ich mich vorhin dazu entschloss, nun auch am Laptop das Update durchzuführen und ich muss zugeben, dass ich überrascht bin wie unproblematisch es von Statten ging, der Konfigurationszeitaufwand betrug etwa 20 Minuten, ich hatte ursprünglich mit ein bis anderthalb Stunden gerechnet. Soweit mir das Testen bisher möglich war, funktioniert jede Einstellung, einzig die Geschwindigkeit des Touchpads ist noch nicht optimal, das war sie aber zuvor auch nicht, weswegen ich dies nicht als "Durch-Update-verursachtes-Problem" bezeichnen kann.

Um das ganze direkt mal mit AVGPs Worten zu schmücken und auf den Punkt zu bringen

Nachdem ich in den vergangenen Tagen awesome in der Version 3 ausprobiert habe, war mir das Ganze dann doch etwas zu bunt. Zwar bietet es nun immensen Komfort, frisst aber so viel Leistung wie ein XFCE, was für einen PC zwar wirklich vollkommen in Ordnung ist, aber bei meiner Celeron Laptop-CPU, für meinen Geschmack, dann eben doch zu viel ist. Die Vorgänger Pakete und Konfiguration habe ich zwar noch, aber ich wollte nun doch mal etwas anderes ausprobieren, wenn das nichts für mich ist, kann ich immer noch zu awesome 2.3.4 zurückkehren.
Nun hatte ich diese Woche eine Unterhaltung mit eiffel56 bezüglich des Ressourcenverbrauchs des aktuellen KDE und der Nutzbarkeit auf einem Notebook, allerdings gibt es dann doch noch 2 Punkte, welche mich davon abhalten, zum einen benutze ich mit Absicht einen Tiling WM auf dem Laptop, zum anderen habe ich nicht wirklich Lust alle paar Tage dev Pakete zu aktualisieren, dazu fehlt mir schlichtweg die Zeit. bl1nk, warf wie üblich Openbox in den Raum, aber ich möchte eben doch einen Tiling-WM benutzen(auch wenn er es auf seinem 7" Display irgendwie schafft damit zurecht zu kommen, ich habe mit meinen 15,4" schon Probleme ').

Nun gut, blieben mir noch 3 Punkte auf meiner alten "Möglicher Laptop-WM"-Liste: xmonad und die beiden suckless.org Windowmanager wmii und dwm. xmonad fiel vorerst(bzw wie bisher) aufgrund der 400MB Haskell Deps weg. Blieb also die Wahl zwischen dwm und wmii, mit einem eigenen dwm Fork liebäugel ich zwar schon seit Monaten, andererseits fehlt mir wie gesagt die Zeit für derartiges, also war wmii der Kandidat der Stunde.

Ein pacman -S wmii und 20 Sekunden in Anspruch nehmendes Anpassen der .xinitrc später, folgte dann ein startx, normalerweise hätte ich mich an dieser Stelle geohrfeigt, weil ich mir die Dokumentation nicht angesehen hatte, aber wmii ersparte mir die (leichten) Schmerzen, denn ich wurde mit einer xmessage begrüßt welche mir schnell die Standardkeybindings erläuterte. Die Konfiguration erfolgt über Scripts, was sich als recht interressant erweist, ob sich wmii aber halten wird, weiß ich noch nicht, es ist zwar eine brilliante Entwicklungsumgebung, aber awesome 2 übt dann doch gewisse Reize aus. awesome 3 wäre bei stärkerer Hardware sowieso der WM der Wahl, vereint es nunmal enormen Komfort(integrierter Tray, gut dokumentierte Konfigurationssprache, etc.) mit mehreren übersichtlichen Tilinglayouts, nur muss ich hier Ressourcenbedarf und Komfort dann doch irgendwie auf einen Nenner bringen.

So, auch ich habe nun awesome3 auf dem Notebook am Laufen und bin fürs Erste doch sehr zufrieden. Zwar ist die alte Konfiguration nichtmehr zu gebrauchen(die Konfigurationsdatei ist nun ein LUA Script), aber ich hatte das meiste dann doch recht fix wieder so konfiguriert, wie es zuvor war. Sehr schön ist vor allem der, schon in der Standardkonfiguration, in die Statusbar integrierte Tray, was mir das benutzen von trayer erspart, da gab es in der Vergangenheit immer mal wieder Probleme mit der Statusbar. Gut, dass die Konfiguration nun auf LUA setzt wird sicherlich einige Einarbeitung benötigen, aber das drängt ja nicht.
Wenn dann mal fertig bin, gibt es auch einen Screenshot

Zur diesjährigen FrOSCon gibt es eine spezielle archlinux Live-CD, es handelt sich hierbei um die normale Installations-CD mit einigen kleinen Extras, so sind beispielsweise beide Architekturen(i686 und x86:64) auf dieser CD vertreten und neben der normalen Basispakete sind ein paar weitere enthalten, ich zitiere einfach mal aus Pierres Post:

This ISO has some special features:
* both architectures (i686 and x86_64) on one ISO image
* snapshot of [core] dated august 18th 2008
* use German keymap and timezone settings in grub and live environment by default
* Added some more packages to the live environment:
    base-devel (gcc, make, patch etc.)
    bash-completion
    htop
    irssi
    lm_sensors
    mc
    pacman-contrib
    rsync
    screen
    smartmontools
    sshfs
    testdisk
    vpnc
    zsh
* some workaround to avoid an out-of-memory bug when using pacman

Wie man sieht wurden mehrere extrem nützliche Applikationen aufgenommen, wer also vorhat arch auf einem System ohne Internetzugang zu betreiben(beispielsweise einen Heim Mediaserver) bekommt eine ganze Reihe nützlicher Shellapps ohne das System extra an internetfähige Struktur hängen zu müssen.

So, sowohl am Notebook, als auch am PC bin ich von meiner langjährigen Shell bash auf zsh umgestiegen. Warum ich meine Shell austausche? Naja zum einen Neugier zum anderen lässt sich zsh wesentlich umfangreicher konfigurieren, hier hoffe ich in den nächsten Wochen zu einer effizienteren Arbeitsumgebung zu kommen, dank bash Kompatibilität spar ich mir auch eine Menge Arbeit beim portieren von Skripten.

Wem bei pacman(der Archlinux Paketmanager) die Statusbars zu langweilig sind(die standardmässig mit Rauten gefüllten, wie man es von wget kennt), kann mit einem kleinen aber feinen ILoveCandy in der /etc/pacman.conf ein nettes Easter Egg freischalten: