Zwei Wochen Arch Linux
Während auf meinem Notebook schon seit vielen Jahren ein Linux läuft (ein vielfach modifiziertes Kubuntu), nutzte ich auf meinem Desktop ausschließlich Windows. Jedenfalls bis vor zwei Wochen, als ich schließlich genug von der langsamen, drei Jahre alten Installation hatte.
Und damit ich es mir gar nicht mehr anders überlegen kann, habe ich nur schnell meine wichtigsten Daten von der Systempartition gesichert (andere Partitionen wurden halbautomatisch gespiegelt), Arch von CD gebootet (mein Mainboard ist sehr wählerisch, was das Dateisystem und die Partitionstabelle bei USB-Sticks angeht) und erstmal die Partitionstabelle gelöscht.
Die Wahl
Aber warum eigentlich Arch Linux? Wie schon erwähnt, nutze ich auf meinem Notebook ein LTS-Kubuntu. Statt KWin nutze ich aber awesome, statt KDM ein LightDM mit eigenem Style und die meisten KDE-Dienste sind abgeschaltet (zumindest soweit es geht). Das läuft soweit ganz gut, nur sind mir einige Programme in den Paketquellen zu alt. Und auch, wenn es eine LTS-Version ist, werde ich in absehbarer Zeit viel Arbeit in ein Update (bzw. Neuinstallation) zur nächsten LTS-Version investieren müssen. Die Lösung, die mir am sinnvollsten erschien: eine Rolling-Release-Distribution. Wenn dann noch Software dazu kommt, die es nicht in den Paketquellen gibt, wird es in Ubuntu kompliziert: manuelle Installation (mit einem zugemüllten /usr oder /opt wie unter Windows) oder ein PPA (was manchmal schlecht gepflegt oder nicht vorhanden ist oder allerlei Kram mitbringt, den man gar nicht haben möchte, und bei dem man auf das komplizierte und langsame Build-System von Ubuntu angewiesen ist).
Letztendlich blieb eine Distribution über, die ich zudem schon lange ausprobieren möchte: Arch Linux. Rolling-Release, sehr schnell die aktuellsten Versionen in den Paketquellen, KISS und Dank dem AUR ein geniales System für inoffizielle Pakete. Und ein super Wiki gibt es auch noch.
Die Installation
Die ersten Schritte sind noch nichts besonderes und im Beginners' Guide ausführlich beschrieben. Bei einem Desktop kann man zudem den umfangreichen Netzwerkteil weitestgehend überspringen, sofern man kein WLAN nutzt.
Nach dem ersten Reboot bin ich dann auf das erste Problem gestoßen: Die Schrift stellt keine Umlaute dar, obwohl ich dem Wiki gefolgt bin und Lat2-Terminus16 gewählt hatte. Nach einigem Suchen im Internet (d.h. man braucht für die ersten Schritte i.d.R. einen zweiten Computer) fand ich heraus, dass lediglich early KMS aktiviert werden muss. Nun konnte es ans Einrichten gehen.
X-System
Zwar kann man vieles auf der Konsole machen (und ich mache dort auch sehr viel), aber eben nicht alles. WWW im Textbrowser macht keinen Spaß und ist oftmals unmöglich. Auch Bildbearbeitung, Office usw. erfordern eine grafische Oberfläche.
Nach der Installation des X-Servers inklusive Abhängigkeiten, awesome als Window Manager und urxvt als Terminalemulator ging es an die Konfiguration. Zuerst wurden mit einigen Konfigurationsdateien das Tastaturlayout und die zwei Bildschirme eingerichtet:
/etc/X11/xorg.conf.d/00-keyboard.conf
------------------------------------------------------------
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "de"
Option "XkbModel" "pc105"
Option "XkbVariant" "nodeadkeys"
EndSection
/etc/X11/xorg.conf.d/10-monitor.conf
------------------------------------------------------------
Section "Monitor"
Identifier "DVI-0"
Option "Primary" "true"
EndSection
Section "Monitor"
Identifier "DVI-1"
Option "RightOf" "DVI-0"
EndSection
Section "ServerLayout"
Identifier "ServerLayout0"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
EndSection
Anschließend habe ich mir eine grundlegende ~/.xinitrc und zudem einen kleinen Autostarter (d.h. ich verzichte auf einen Display Manager) geschrieben:
~/.xinitrc
------------------------------------------------------------
#!/bin/sh
xrdb -merge ~/.Xresources
numlockx &
exec awesome
~/.bash_profile
------------------------------------------------------------
[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && exec startx &> ~/.xsession-errors
Anschließend kann man die grafische Oberfläche mit startx starten. Ein kleiner Schönheitsfehler: Programme in ~/.xinitrc werden nach ihrem Beenden weiter als Zombies geführt. Das ist erstmal nicht schlimm, aber trotzdem etwas, was man vermeiden könnte (wie?).
Zwar habe ich bislang awesome 3.4 genutzt, die Konfiguration und die Widgets ließen sich aber relativ leicht für die aktuelle Version 3.5 anpassen. Dabei ist mir aufgefallen, dass scrot (ein sehr simples Programm für Screenshots) einige Optionen nicht kennt. Die neuste Version ist von 2000 und in Ubuntu hatte ich z.B. -u und -z. Der Grund: Debian patcht fast alles. Die Lösung: Die Version mit Patches aus dem AUR installieren.
GTK+, QT & KDE
Es gibt GTK+ 1, GTK+ 2, GTK+ 3 (die alle nicht miteinander kompatibel sind) sowie Qt (hauptsächlich 4 und 5). Das alles sind Bibliotheken, welche grafische Elemente (genannt Widgets) wie z.B. Schaltflächen oder Auswahlboxen zur Verfügung stellen. Sie sollen die Entwicklung von grafischen Oberflächen nicht nur vereinfachen, sondern auch vereinheitlichen. Kurz: Sie legen das Design des Systems fest. Aufgrund der vielen Versionen funktioniert das leider nicht so wirklich.
Um nun ein möglichst einheitliches Aussehen zu bekommen, habe ich mir für Oxygen entschieden, welches ich schon von meinem Kubuntu gewohnt war. Dazu habe ich neben oxygen-gtk2, welches den GTK-Style liefert, auch kdeartwork-styles installiert, welches mir ein halbes KDE in Form von Abhängigkeiten installiert hat. Für GTK habe ich den Style mit lxappearance festgelegt (man hätte es auch manuell in ~/.gtkrc-2.0 und ~/.config/gtk-3.0/settings.ini machen können). Für Qt habe ich es mit den systemsettings von KDE gemacht.
Erst lief es auch, nach einem Neustart war aber wieder alles beim Alten. Warum? Beim Start einer KDE-Anwendung werden kdeinit und andere Hilfsprogramme von KDE gestartet. Eigentlich geschieht dies zusammen mit vielen anderen Umgebungsvariablen und Hilfsprogrammen beim Start mittels startkde. Allerdings nutze ich keine KDE-Session. Die Lösung ist also das manuelle Setzen der Umgebungsvariable, damit die Bibliothek für Oxygen gefunden wird. Alternativ kann man auch einen Symlink erstellen:
# ln -s /usr/lib/kde4/plugins/styles /usr/lib/qt4/plugins/
Die Feineinstellungen von Oxygen kann man dann mit den systemsettings (oder per Hand – wie bei KDE üblich – in vielen Konfigurationsdateien) machen. Diese werden durch oxygen-gtk2 auch größtenteils für die GTK-Darstellung genutzt.
Die Schrift
Von WIndows bin ich ClearType gewohnt und auch unter Ubuntu sieht die Schrift halbwegs akzeptabel aus. Nicht so unter Arch. Konkret geht es um Antialiasing, Subpixel-Rendering (und damit LCD-Filter) und vor allem Hinting.
Zuerst habe ich mein Glück mit ~/.config/fontconfig/fonts.conf und Symlinks aus /etc/fonts/conf.avail probiert. Subpixel-Rendering auf rgb
, lcddefault
, Hinting mittels BCI, hintfull
und Autohinter aus. Toll sah es nicht aus. Erst recht nicht mit Windows-Schriftarten, die zu weit, zu dick oder einfach hässlich erschienen. Der Autohinter macht es etwas besser, dadurch werden die Schriften aber unschärfer.
Aus Verzweiflung habe ich schließlich infinality und fontconfig-infinality installiert. Dabei habe ich die Einstellungen DEFAULT
in /etc/profile.d/infinality-settings.sh und # infctl setstyle LINUX
verwendet. Die Schriften sehen auch in der Tat etwas besser aus, aber noch lange nicht perfekt. Manchmal wirken sie immer noch etwas gestaucht, gestreckt oder zu dick. Außerdem habe ich Probleme mit der Zuordnung (vgl. fc-match
): Schriften haben falsche Namen, Namen werden zu der falschen Schrift aufgelöst und im Firefox habe ich manchmal das Problem, dass die Standardschrift genutzt wird (serif), obwohl es eigentlich monospace sein sollte. Eine mögliche Lösung habe ich gefunden, aber noch nicht ausprobiert.
Ein weiteres Problem ist die allgemeine Schriftgröße. Manche Texte in der Oberfläche sind zu groß, manche zu klein. Die Verhältnisse stimmen irgendwie nicht. Die entsprechenden Einstellungen in systemsettings helfen leider auch nur bedingt weiter.
Der große Nachteil an infinality ist jedoch ein Bug, der regelmäßig urxvt abstürzen lässt. Das ist natürlich ärgerlich, wenn man viele Shells offen hat und (so wie ich) urxvt im Daemon-Modus nutzt. Dann werden nämlich alle Instanzen zusammen geschlossen.
[ 3098.337323] urxvtd[681]: segfault at 7f22f3226860 ip 00007f22f220c7c5 sp 00007fff2655f820 error 4 in libc-2.18.so[7f22f2194000+1a2000]
Weiterhin verschwinden bei mir in Firefox manchmal Teile eines Textes, wenn ich weiter schreibe oder den verschwundenen Text auswähle, erscheint er wieder (irgendein Problem mit einem fehlerhaften draw()
).
Standardanwendungen
Zwar gibt es mit XDG viele Richtlinien und Tools, um den Desktop zu vereinheitlichen. Desktop Environments machen dann aber dennoch ihr eigenes Ding. Läuft z.B. KDE, dann nutzt xdg-open das KDE-Äquivalent kde-open mit dessen Zuordnungen. Einstellungen in systemsettings bringen also nichts, da bei mir kein KDE läuft. Also habe ich es mit dem XDG-Standard in ~/.local/share/applications/mimeapps.list mittels xdg-mime probiert. Ist aber etwas mühsam, die passenden *.desktop-Dateien zu finden. Einige (z.B. von Okular) sind auch fehlerhaft, sodass ich sie zuerst duplizieren und anpassen musste:
--- /usr/share/applications/kde4/okular.desktop 2013-08-28 19:07:55.000000000 +0200
+++ /home/sammyshp/.local/share/applications/okular.desktop 2013-10-08 19:32:34.302148013 +0200
@@ -123,7 +123,7 @@
GenericName[x-test]=xxDocument Viewerxx
GenericName[zh_CN]=文档查看器
GenericName[zh_TW]=文件檢視器
-Exec=okular %U %i -caption %c
+Exec=okular %U
Icon=okular
Type=Application
X-DocPath=okular/index.html
Dann gibt es noch die grafische Auflistung, wenn man aus einer GUI etwas öffnen möchte. Apropos: Qt/KDE und GTK haben natürlich unterschiedliche Datei-Dialoge, was auch nicht besonders schön ist.
Tearing
Tearing entsteht, wenn die Bildgenerierung nicht mit der Ausgabe synchronisiert ist (siehe vsync). Dies fällt besonders in Firefox beim Scrollen auf. Es lässt sich nur beheben, indem man einen Compositor einsetzt. Die meisten Dektop Environments haben bereits einen standardmäßig aktiviert, bei KDE ist er in KWin integriert. Wichtig ist, dass der Compositor OpenGL unterstützt, was bei den stand-alone Implementierungen (ohne Window Manager) fast nur in Compton der Fall ist. Mit dieser Konfiguration ist das Tearing weg und das Bild ruckelt nicht merklich (meistens zumindest).
~/.config/compton.conf
------------------------------------------------------------
backend = "glx";
paint-on-overlay = true;
glx-no-stencil = true;
glx-no-rebind-pixmap = true;
Compton wird automatisch über die ~/.xinitrc beim Starten von X ausgeführt.
Java
Dies ist eher ein Problem mit awesome, als mit Arch. Das erste Problem ist, dass sich Menüs beim Loslassen der Maustaste automatisch schließen. Das zweite, dass der Mauszeiger in Menüs einen Offset aufweist. Das erste Problem lässt sich mit $ wmname LG3D
lösen, das zweite mit dem expliziten Setzen der Umgebungsvariable _JAVA_AWT_WM_NONREPARENTING
. Das habe ich zusammen mit einigen Schriftverbesserungen in /etc/profile.d gepackt:
/etc/profile.d/jre.sh
------------------------------------------------------------
export _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on -Dswing.aatext=true -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel'
export _JAVA_AWT_WM_NONREPARENTING=0
Ein drittes Problem ist, dass manche Popups nicht dargestellt werden (es wird nur der Hintergrund angezeigt). Dafür habe ich leider noch keine Lösung gefunden, da in awesome 3.5 die Methode redraw()
entfernt wurde.
LaTeX
Wenn doch alles so einfach wäre. Da ich viele exotische Pakete nutze, müsste ich ein volles TexLive installieren. Das wären aber einige GB. Alternativ könnte ich texlive-core installieren und texlive-localmanager verwenden, um Pakete nachzuinstallieren. Leider habe ich dieses Tool nicht zum Laufen bekommen.
Dabei ist die Lösung so einfach: Nach dieser Anleitung habe ich TexLive und anschließend die gewünschten Pakete mit tlmgr installiert. Mein $PATH
habe ich über
/etc/profile.d/texbin.sh
------------------------------------------------------------
export PATH=$PATH:/usr/local/texlive/2013/bin/x86_64-linux
angepasst. Anschließend noch latex-dummy aus dem AUR installieren, damit die Paketverwaltung denkt, TexLive sei installiert(Abhängigkeiten).
Mounting
Irgendwas hat udisks2 als Abhängigkeit installiert, dadurch kann ich als Benutzer schonmal "leicht" externe Datenträger mounten. Eine udev-Regel sorgt dafür, dass dies in /media geschieht.
/etc/udev/rules.d/99-udisks2.rules
------------------------------------------------------------
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="1"
ENV{ID_CDROM}=="1", ENV{UDISKS_FILESYSTEM_SHARED}="1"
Allerdings gibt es auch Pakete, die udisks (Version 1) als Abhängigkeit haben, dann wird es schon komplizierter, da man nun mehrere Systeme parallel nutzt. Für vieles andere (u.a. Mounten aus grafischen Dateimanagern) gibt es gvfs. Das habe ich leider nicht zum Laufen bekommen. Vielleicht, weil ich noch keinen polkit-Agent verwende. Daher bini ch auch am Mounten eines sftp-"Laufwerks" gescheitert, mein Android mit MTP habe ich noch gar nicht probiert.
VirtualBox & Photoshop
Gimp ist für manche Dinge ja ganz nett, aber irgendwann ist man dann doch auf Photoshop angewiesen. Dafür habe ich mir VirtualBox installiert und dann eine virtuelle Maschine mit meinem alten Windows 7 erstellt. Das anschließende Windows-Update hat fast drei Stunden gedauert, anschließend war die virtuelle Festplatte schon 15 GB groß. Durch irgendwelche Windows-Dienste gibt es auch ständig Festplattenaktivität. Es ist also doch nicht so verkehrt gewesen, nun auch hier zu Linux zu wechseln.
Die Photoshop-Installation (CS5) verlief ohne Probleme. Leider funktioniert die Grafikbeschleunigung nicht. Außerdem verschwindet der Pinsel-Cursor, wenn er größer als ca. 30 px wird. Das Farbmanagement ist natürlich auch nicht perfekt.
(Nachtrag: Deaktiviert man die Mauszeigerintegration, wird die Maus also von der VM gefangen, dann werden die Pinsel korrekt angezeigt. Allerdings gibt es den Fehler in VirtualBox, dass gelegentlich "unsichtbare Wände" auftauchen und man den Mausfang kurzzeitig deaktivieren muss.)
Gut funktioniert hingegen der Zugriff auf die Daten mittels der Freigabe in VirtualBox. Insgesamt ist diese Photoshop-Lösung aber noch nicht sehr schön.
Flash
Flash macht hauptsächlich drei Probleme: Es braucht viel CPU (keine Lösung), beim Vollbild wird die Bildschirmgröße falsch erkannt (teilweise Lösung) und beim Fokussieren einer anderen Anwendung wird der Vollbildmodus beendet (unschöne Lösung). Aber Flash war unter Linux schon immer mist und Videos schaut man sich besser mit mplayer in Verbindung mit youtube-dl an.
Drucker & Scanner
Ich nutze den S/W-Laserdrucker OKI B430d. Für diesen gibt es einen PostScript-Treiber (PPD) vom Hersteller. Der Linux-Download liefert eine ältere Version, die ich bislang auf meinem Notebook genutzt hatte. Damit lässt sich zwar drucken, aber ich finde das Ergebnis nicht so schön wie unter Windows. Vielleicht liegt das auch an CUPS. Ich habe mir schon die PPD-Datei aus dem Windows-Treiber extrahiert, die ein wenig neuer ist. Werde ich demnächst ausprobieren. Firefox schickt leider ein gerastertes Bild an den Drucker, wodurch das Ergebnis logischerweise nur für das Altpapier reicht.
(Nachtrag: Es gibt im AUR die Pakete oki-400-ps und oki-400-pcl, mit denen das Drucken gut funktioniert.)
Ein richtig großer Vorteil von Linux ist, dass mein Scanner – ein alter Mustek BearPaw 1200CU Plus – endlich wieder läuft. Für Windows 7 (und vor allem 64 bit) gab es keinen Treiber, unter Linux läuft er mit SANE und dem GT68xx Backend.
Positives?
Eindeutig ja. Ich mag das Prinzip des AUR, welches meiner Meinung nach besser ist, als die PPA unter Ubuntu. Die PKGBUILD-Dateien sind übersichtlich und leicht zu verstehen und da man die Programme selbst kompiliert, muss man nicht lange wie beim PPA auf die Binaries warten. Zusammen mit einem AUR-Helper (ich verwende yaourt) integriert sich das AUR auch sehr schön in die Paketverwaltung inklusive Updates und Abhängigkeiten.
Weiterhin mag ich die Aktualität der Software, allerdings kommt es so vielleicht auch schneller zu Konflikten.
Schließlich bleibt noch das KISS-Prinzip, welches ich mit dem Verzicht auf Display Manager und Desktop Environment auch wunderbar fortsetze.
Fazit
Zwei Wochen sitze ich nun schon vor dieser Kiste und sie läuft immer noch nicht so, wie ich es möchte. Die zuvor genannte Liste von Problemen ist noch lange nicht komplett. Viele Probleme ließen sich vielleicht mit der Nutzung eines Desktop Environments beheben. Aber dies würde auch neue Probleme bringen und vieles verkomplizieren. Probieren werde ich es vielleicht dennoch irgendwann.
Insgesamt fühle ich mich unter Linux wohler als unter Windows, aber einige Sachen laufen unter Windows einfach problemloser. Wenn Linux, dann aber Arch. Ein komplettes Ubuntu läuft vielleicht problemloser, aber das erkauft man sich mit alter Software und einem System, das nicht mehr KISS ist.
Und da ich jetzt so genervt von der Sache bin, habe ich die Kiste einfach ausgeschaltet und diesen Blog-Artikel per Hand geschrieben. Fünf Seiten beidseitig beschriebenes Papier. Oldschool, aber es geht wirklich! Abschreiben muss ich es dennoch…
Nachtrag 19.10.2013
Zumindest das Problem mit den falschen Schriften in Firefox konnte ich teilweise beheben.
--- infinality.conf.old 2013-10-17 18:13:26.124382257 +0200
+++ infinality.conf 2013-10-18 15:10:14.234828736 +0200
@@ -73,7 +73,7 @@
<!-- NOTE: Corrective substitutions will still be done -->
<match target="pattern" >
<edit name="do_substitutions" mode="assign">
- <bool>true</bool>
+ <bool>false</bool>
</edit>
</match>
Auch die Probleme mit Flash habe ich zu einem Großteil gelöst, allerdings bislang nur in der Theorie. Details stehen in einem Issue auf GitHub.
Nachtrag 21.04.2014
Viel Zeit ist inzwischen vergangen und viel hat sich an meiner Arch-Installation geändert. Von größter Bedeutung ist sicherlich, dass ich vor einiger Zeit von den Infinality-Patches auf das Infinality-Bundle von Bohoomil umgestiegen bin. Es gibt auch eine gute Anleitung, wie man das installiert. Dadurch wurden alle Probleme mit der Schrift gelöst.
Insgesamt bin ich nun mit fast allem am System zufrieden. Flash ist nicht so performant und manchmal klemmt es hier und da, aber im Groben und Ganzen läuft das Arch sehr gut. Insbesondere in die Paketverwaltung und das Build-System habe ich mich verliebt.
Nachtrag 07.06.2014
Das Problem mit den angeblich defekten *.desktop Dateien ist ein Problem xdg-open
aus den xdg-utils. Dessen Parser versteht die Parameter nämlich nicht und übergibt sie daher unverändert an das Programm. In der nächsten Version müsste der Fehler behoben sein.