Kurzes Statement an alle Programmierer

Aus aktuellem Anlass 3 kurze Statements an alle Programmierer da draußen:

Wenn ihr glaubt man kann durch das Einsetzten toller Tools, Editoren oder Libraries bessere Programme schreiben, dann könnt ihr nicht programmieren!

Ich sehe es an Eclipse: IntelliSense, Projektverwaltung, Wizards alles schön und gut, ich arbeite trotzdem ungern damit! Eclipse hat tausend Einstellungsmöglichkeiten aber versucht mal die Einrückung auf zwei Leerzeichen einzustellen. Warum zum Teufel mach ich tausend Menüpunkte statt einer Configdatei? Warum muss ich eine halbe Minute warten bis ich Eclipse gestartet hab nur um zu schauen ob Änderungen im SVN sind? VIM ist für mich mit Abstand der beste Editor obwohl ich ihn bei weitem noch nicht so bedienen kann wie ich es gerne hätte. Dort ist einfach alles einstellbar, so wie es für jeden richtig ist. Für was brauche ich IntelliSense wenn ich eine Doku hab? Für was brauche ich ein SVN-Plugin wenn ich svn als Programm habe? Eclipse steht nur im Weg wenn man programmiert. Sicher Programmiert es sich so schneller weil man einfach nur seinen Methodennamen vervollständigen lassen muss aber genau in dem Moment gibt man das Denken an die IDE ab. Bevor ich in Eclipse ein Projekt erstellt habe bin ich mit VIM fertig.

Wenn ihr glaubt man kann aus einem UML-Diagramm, einem GUI-Designer oder Anderweitig auch nur Programmteile zusammenklicken, dann konntet ihr noch nie programmieren!

Programmieren hat zu einem kleinen Teil etwas mit einer planbaren Engineeringtätigkeit zu tun. Der Rest besteht aus Erfahrung und einem künstlerischem Prozess. Mit Kunst meine ich keine schöne GUI sondern viel mehr ist es eine Art von künstlerischem Ausdruck. Etwas, das durchaus mit dem spielen eines Instrumentes gleich kommt. KEIN Editor schafft es dies durch ein paar Code-Templates die man im Hintergrund platziert zu komprimieren. Sie gaukeln nur ein schnelles Ergebnis vor bis man ein gewissen Detailgrad erreicht hat und dann kommt der GAU weil der Editor nur noch im Weg steht und komplexe Dinge nicht mehr möglich sind.

Wenn ihr glaub, man muss nicht stetig weiterlernen, dann werdet ihr auch nie programmieren können!

Je nach dem was man als Programmiersprache definiert sollten zwei neue Sprachen im Jahr locker drinnen sein. Jeden Monat ein Buch zu einem neuen Thema sollte auch möglich sein. Bevor man sich mit einem neuen Thema beschäftigt => Buch lesen. Bevor man versucht etwas durch probieren zum laufen zu bekommen => Buch lesen. Ziel ist es zu wissen was man tut und nicht Beispiele aus einem Online Tutorial herauszukopieren und zu hoffen das es Funktioniert!

Schlechte Programme sind das Übel der Neuzeit. Früher gab es die Pest, heute reichen dazu ein paar Programmierer. Programmieren hat nichts mit Syntax zu tun. Programmieren ist einfach ein Gefühl welches sich durch Code ausdrückt!

Anmerkung: Das ganze ist natürlich (mal wieder) übertrieben und nicht ganz ernst gemeint. Deswegen ist es leider nicht weniger wahr.

ssh-agent Startscript

Nachdem ich zufällig auf einige interessante Möglichkeiten von SSH gestoßen bin entschloss ich mich vor meinen Semesterferien das Buch "SSH, The Secure Shell" auszuleihen. Ich muss sagen wenn dieses Buch ist schon fast die SSH Spezifikation. Dort steht wirklich alles drinnen. Zum Lesen völlig ungeeignet allerdings für Ideen und zum Nachblättern gar nicht mal so schlecht.

So bin ich auch auf Authentifikation über SSH-Keys gestoßen. Normalerweise gibt man sein Passwort ein, wenn man sich auf einem Server anmeldet. SSH-Keys funktionieren allerdings eher wie GPG Verschlüsselung. Man generiert einen Public Key, den man auf allen Servern, bei denen man sich anmelden möchte, hinterlegt. Außerdem noch einen Privat Key mit dem sich jeder, bei allen Server auf denen der Public Key hinterlegt ist, anmelden kann. Das funktioniert einfach, in dem der Server mit dem Public-Key eine Challenge verschlüsselt und diese dem Client zusendet. Dieser entschlüsselt die Nachricht wieder und sendet es zurück. Stimmen die Nachrichten beim Server überein wird der Nutzer rein gelassen. Allerdings kann dann wie schon gesagt jeder der den Private Key kennt auch auf den Server zugreifen. Um dies etwas zu erschweren kann man ein Passwort definieren das für den Privaten Key benötigt wird. Man sieht schon, im Grunde nichts anderes als GPG. In Wirklichkeit kann man sogar (mit den nötigen Einstellungen) seinen GPG Key dafür nutzen.

Nun hat man zwar SSH-Key, allerdings darf man nun wieder jedes mal sein Passwort eingeben. Man hat also nichts gewonnen. Dafür gibt es nun (ebenfalls aus der GPG-Welt bekannt) einen Agent, der die Key einmal lädt, dabei das Passwort abfragt und anschließend auf Anfragen reagiert. So muss man nicht jedes mal neu sein Passwort eingeben. Sehr praktische Geschichte! Leider ist die Syntax etwas umständlich und auch muss jeder Key einzeln geladen werden. Deshalb habe ich mir etwas den Kopf zerbrochen wie man dies automatisieren kann. Dabei ist das folgende Script entstanden. Es schaut bei jedem Aufruf (in der Regel sobald sich eine neue Shell öffnet) ob der SSH-Agent läuft. Außerdem lädt es die Keys Automatisch so das man nur noch die Passwörter eingeben muss. Außerdem ermöglicht es über die beiden Funktionen start-ssh-agent und load-ssh-indentities dies auch Manuell durchzuführen.

Um zu verstehen wie das Script funktioniert muss man sich erst einmal anschauen wie der ssh-agent bekannt gibt es es ihn gibt. Ruft man ihn einfach mit dem ssh-agent Kommando auf (was der falsche Weg ist), erscheinen einige Variablen. Diese Variablen sind wichtig damit der ssh-Client auf den Agent zugreifen kann. Der Agent selbst läuft vom Terminal losgelöst. Er wird also nicht beendet wenn die Session beendet wird sondern läuft im Hintergrund weiter. Einer der richtigen Wege (es gibt mehrere Möglichkeiten) wäre eval `ssh-agent`. Hier wird zuerst der ssh-agent aufgerufen und die Ausgaben ausgeführt. So werden die Variablen im aktuellen Terminal bekannt gegeben. Möchte man nun auch in einer anderen Session auf den Agent zugreifen muss man dort auch einfach nur die Variablen bekannt machen. Da der Agent wie gesagt unabhängig von der aktuellen Session läuft interessiert es nicht aus welcher Shell er gestartet wurde.

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-Yvpvk13029/agent.13029; export SSH_AUTH_SOCK;
SSH_AGENT_PID=13045; export SSH_AGENT_PID;
echo Agent pid 13045;

Mein kleines Script macht im Grunde nichts anderes als diese Variablen in einer Datei zu speichern und bei jedem anmelden diese einzulesen. Außerdem lädt es alle Identitäten die in in dem Verzeichnis ~/.ssh/keys/ liegen. Wichtig ist, dass dort nur Private-Keys liegen dürfen; keine Public-Keys!

# Lädt alle Indentitäten im Verzeichnis ~/.ssh/keys/
function load-ssh-indentities() {
  # Prüft erst ob ein tty verfügbar ist
  if tty -s ; then
    for FILE in ~/.ssh/keys/* ; do
      ssh-add $FILE
    done
  fi
}

# Startet den SSH-Agent mit einer Indentitäten-Lifetime von einer Stunde
# und schreibt die Variablen in die ~/.ssh_agent_vars Datei
function start-ssh-agent() {
  eval `ssh-agent -s -t 3600`
  echo -e "export SSH_AGENT_PID=$SSH_AGENT_PID\nexport SSH_AUTH_SOCK=$SSH_AUTH_SOCK" > ~/.ssh_agent_vars \
  && echo "SSH-Agent gestartet"
}

# Fragt erst nach ob Indentitäten geladern werden sollen.
function _ask_load_ssh_indentities() {
  echo "Indentitäten laden? (y/N)"
  read ANSWER
  ( [ "$ANSWER" = "y" ] || [ "$ANSWER" = "Y" ] ) && load-ssh-Indentitäten
}

# Die Variable SSH_AUTH_SOCK wird für den SSH-Agent benötigt und sollte gesetzt sein wenn er läuft.
if [ "$SSH_AUTH_SOCK" = "" ]; then
  # Es wird geprüft ob die Datei ~/.ssh_agent_vars vorhanden ist.
  if [ -f ~/.ssh_agent_vars ]; then
    # Wenn ja wird diese Includiert und geprüft ob die Variablen darin noch gültig sind.
    source ~/.ssh_agent_vars

    # Prüft ob es ein ssh-agent Prozess mit der PID gibt und das Socket existiert.
    if ( ps -p $SSH_AGENT_PID  | grep -q ssh-agent ) && [ -e $SSH_AUTH_SOCK ]; then
      # SSH-Agent ist gestartet Vorhandene Indentitäten werden angezeigt.
      echo "SSH-Agent ist bereits gestartet Geladene Indentitäten:"
      ssh-add -l
    else
      # Die Variablen sind nicht mehr gültig. Datei wird gelöscht und SSH-Agent wird neu gestartet.
      echo "~/.ssh_agent_vars Datei existiert aber es ist kein Agent gestartet. Starte Agent."
      rm ~/.ssh_agent_vars
      start-ssh-agent && _ask_load_ssh_indentities
    fi
  else
    # Datei ist nicht vorhanden. Es wird geprüft ob SSH-Agent läuft.
    if ps u -C ssh-agent | grep -q ssh-agent ; then 
      echo "SSH-Agent läuft aber es existiert keine ~/.ssh_agent_vars Datei!"
      echo "SSH-Agent muss gestoppt werden und mit 'start-ssh-agent' neu gestartet"
      # Weiteres Vorgehen dem User überlassen
    else
      # Wenn nicht wird er gestartet.
      start-ssh-agent && _ask_load_ssh_indentities
    fi
  fi
else
  # Variable ist schon gesetzt. Es wird geprüft ob SSH-Agent auch wirklich läuft
  if ps u -C ssh-agent | grep -q ssh-agent ; then 
    echo "SSH-Agent ist bereits gestartet. Geladen Indentitäten:"
    ssh-add -l
  else
    # Tritt nur bei Subshells auf, wenn die Variable in die Subshell
    # übergeben wurde obwohl der Agent schon beendet wurde.
    echo "SSH_AUTH_SOCK Variable ist gesetzt aber SSH-Agent läuft nicht!"
    # Weiteres Vorgehen dem User überlassen
  fi
fi

Das Script muss am besten in die Datei ~/.bashrc eingefügt werden. Dabei ist wichtig, dass dies nicht in einer Subshell ausgeführt werden darf. Deshalb direkt in die bashrc kopieren oder mittels source einbinden. Da es sonst Namespace-Probleme mit Variablen und Funktionen gibt darf es nicht über exec eingebunden werden (deshalb auch kein #!/bin/bash am Anfang).

Für Kritik und Verbesserungsvorschläge bin ich immer offen. Getestet habe ich das Script bis jetzt mit Bash 3.2.17 und zsh 4.3.4. Einziger Kritikpunkt den ich schon jetzt von meiner Seite habe: Das Script merkt natürlich nicht wenn der User nicht mehr angemeldet ist. Da der Agent unabhängig von der Session ist läuft er einfach weiter auch wenn der User schon längst über alle Berge ist. Das ist in so weit ein Problem da man theoretisch einen Speicherdump des ssh-agent Prozesses machen kann und dann alle Keys vorfindet. Um dies zu verhindern habe ich die 60 Minuten Sperre eingebaut. So scheißt der Agent nach 60 Minuten alle Keys raus und man muss sie neu laden. Leider ist das etwas unschön. Ich habe allerdings (noch) keine bessere Idee.

Fortgeschrittene Paketverwaltung mit Gentoo

Wer kennt das nicht. Man installiert ein Programm und irgend eine Kleinigkeit passt einem nicht. Sei es ein kleiner Bug oder ein fehlendes Feature. Oftmals kann man dies durch ein kurzes Patchen des Source Codes ausbügeln. Bisher unter Debian basierenden Distributionen war dies immer ein reißen Problem. Man musste manuell die Source herunterladen diese Patchen alle Abhängigkeiten herausfinden und installieren, Kompilieren und schließlich auch noch ein DEB-Paket erstellen und in die Paketverwaltung zurückführen. Wer das öfters machen muss wird wahnsinnig.

Bei der Installation von Gentoo bin ich auf ein richtig Cooles Feature gestoßen. Es gibt die Möglichkeit von Overlays. Das sind im Grunde weitere Repositories, die ebuilds, also die Gentoo-Pakete, enthalten. Richtig komfortabel wird dies da man über das Programm Layman einfach ein solches Repository bei sich einfügen kann, um dann daraus Software zu installieren. Im Prinzip wie bei Debian auch, nur das es viel anpassbarer ist. So besteht z.B. die Möglichkeiten das Repository über rsync, svn, git, bzr, etc. abzurufen und so zu aktualisieren. Im Gegensatz dazu sind auch Lokale Overlays möglich. Dabei legt man einfach ein Verzeichnis an und schmeißt die ebuilds die man installieren möchte einfach rein. Sehr komfortabel da man so kein Unterschied merkt ob diese Pakete nun Lokal in einem Overlay liegen oder aus dem offiziellen Portagetree kommen.

Hier ein kurzes Beispiel für ein Ebuild das aus einem lokalen Overlay installiert wird. Zuerst einmal das entsprechend Verzeichnis anlegen. Ich habe es unter /usr/portage/local/ gelegt, da dort auch Layman seine Dateien ablegt. Empfohlen wird normal /usr/local/portage/ allerdings sollte das relativ egal sein.

Ich zeige das ganze mal am Beispiel von Eqonomize. Dazu schmeißen wir einfach das heruntergeladen Ebuild in den Unterordner app-office/eqonomize. Anschließend noch kurz ein ebuild app-office/eqonomize/eqonomize-0.5.ebuild digest. Dies erstellt ein Manifest was einfach einige Checksummen zur Überprüfung enthält. Jetzt muss nur noch das Lokale Overlay in Portage bekannt gemacht werden. Das geschieht einfach über die Variable PORTDIR_OVERLAY="/usr/portage/local/local-overlay" die wir in der Datei /etc/make.conf hinzufügen müssen. Das einzige was noch fehlt ist das synchronisieren des Portage. Ich nutze dazu eix-sync da mir einfach die Ausgaben besser gefallen. Mit emerge geht's natürlich genauso.

Soweit meine Kurzeinführung in Lokale Overlays. Jetzt aber zu dem eigentlichen Feature. Ich bin es Leid bei ntfs3g jedes mal locale=de_DE.utf8 mitzugeben damit Umlaute richtig dargestellt werden. Deshalb möchte ich es gerne automatisch einfügen wenn ich mount.ntfs aufrufe. Das löse ich einfach über ein Patch im Lokalen Overlay. Ob dieses Beispiel jetzt sinnvoll bzw. der Aufwand gerechtfertigt ist sei mal dahin gestellt.

Dazu erst einmal ein Verzeichnis erstellen und die Aktuelle ntfs3g Version aus dem Portage kopieren. Der Unterordner files lege ich schon mal für den Patch später an.

mkdir -p /usr/portage/local/local-overlay/sys-fs/ntfs3g/files/

cp /usr/portage/sys-fs/ntfs3g/ntfs3g-1.1120.ebuild /usr/portage/local/local-overlay/sys-fs/ntfs3g/
cp /usr/portage/sys-fs/ntfs3g/metadata.xml /usr/portage/local/local-overlay/sys-fs/ntfs3g/

Anschließend die Datei /usr/portage/local/local-overlay/sys-fs/ntfs3g/ntfs3g-1.1120.ebuild Editieren und oben bei inherit multilib toolchain-funcs noch eutils hinzufügen. Außerdem weiter Unten noch folgenden Block, der das Auspacken und Patchen erledigt, einfügen:

src_unpack() {
      unpack ${A}
      cd "${S}"
      epatch "${FILESDIR}"/Makefile.am.patch
      epatch "${FILESDIR}"/Makefile.in.patch
}

Das war's so weit jetzt müssen wir noch die beiden gepatchen Makefiles erstellen. Dazu einfach das bestehende ebuild auspacken in /tmp/ verschieben und die beiden benötigten Dateien mit der Endung *.change kopieren

ebuild /usr/portage/local/local-overlay/sys-fs/ntfs3g/ntfs3g-1.1120.ebuild unpack

cp -r /var/tmp/portage/sys-fs/ntfs3g-1.1120/work/ntfs-3g-1.1120 /tmp/

cp /tmp/ntfs-3g-1.1120/src/Makefile.am /tmp/ntfs-3g-1.1120/src/Makefile.am.change
cp /tmp/ntfs-3g-1.1120/src/Makefile.in /tmp/ntfs-3g-1.1120/src/Makefile.in.change

Diese Dateien ändern wir nun. Als erstes Kommentieren wir die Zeile aus die den Link von ntfs-3g auf mount.ntfs-3g anlegt. Dann Fügen wir über echo Zwei Zeilen in die neue /sbin/mount.ntfs-3g Datei ein die ntfs-3g mit dem gewünschten Parameter aufrufen. Wer sich über die Maskierung wundert einfach mal ausführen und Anschauen. Ich hab ewig gebraucht bis ich das raus gefunden habe. Zu Letzt geben wir der Datei noch Ausführungsrechte und erstellen einen Link auf mount.ntfs. Das ganze muss in beiden Dateien (Makefile.in und Makefile.am) jeweils unter install-data-local: und install-exec-local: eingefügt werden. Die beiden Dateien sollen unter uninstall-local: auch wieder gelöscht werden.

-- vim -O /tmp/ntfs-3g-1.1120/src/Makefile.*.change
(install-data-local:|install-exec-local:)
#$(LN_S) -f $(bindir)/ntfs-3g $(DESTDIR)/sbin/mount.ntfs-3g
echo -e '#!/bin/bash\nntfs-3g "$$@" -o locale=de_DE.utf8' > $(DESTDIR)/sbin/mount.ntfs-3g
chmod +x $(DESTDIR)/sbin/mount.ntfs-3g
$(LN_S) -f $(DESTDIR)/sbin/mount.ntfs-3g $(DESTDIR)/sbin/mount.ntfs

uninstall-local:
$(RM) -f $(DESTDIR)/sbin/mount.ntfs
$(RM) -f $(DESTDIR)/sbin/mount.ntfs-3g
-- :wqa

Nun erstellen wir ein Patch zwischen der geänderten und der original Version. Das bash -c hilft mehrere Befehle auf einmal auszuführen. Das ist besonders hilfreich wenn man wie ich mit sudo arbeitet. Da man sonst evtl. keine Berechtigungen hat in die Datei zu schreiben. Die geänderten Dateien nun in unser lokales Overlay kopieren und wieder ein Manifest erstellen.

bash -c "cd /tmp/; diff -uN ntfs-3g-1.1120/src/Makefile.in ntfs-3g-1.1120/src/Makefile.in.change >  ntfs-3g-1.1120/src/Makefile.in.patch"
bash -c "cd /tmp/; diff -uN ntfs-3g-1.1120/src/Makefile.am ntfs-3g-1.1120/src/Makefile.am.change >  ntfs-3g-1.1120/src/Makefile.am.patch"

cp -v /tmp/ntfs-3g-1.1120/src/Makefile.*.patch /usr/portage/local/local-overlay/sys-fs/ntfs3g/files/

ebuild ntfs3g-1.1120.ebuild digest

Wer noch nicht die Variable für das lokale Overlay in die Datei /etc/make.conf eingefügt hat sollte das jetzt tun. Ansonsten wieder mit eix-sync synchronisieren. Hier sieht man dann das ein Update zwischen dem Originalen Portage und unserem Overlay statt gefunden hat. Installiert man nun wie gewohnt die Datei sieht man auch, dass das Portage gewechselt hat. Wenn man schnell genug ist, und ich die Ausgabe von emerge anschaut, sieht man sogar wie unsere beiden Patchs ausgeführt werden.

-- eix-sync
[ebuild   R   ] sys-fs/ntfs3g-1.1120  USE="-debug -suid" 0 kB [0=>1]
[0] /usr/portage
[1] /usr/portage/local/local-overlay
--

-- emerge -vat ntfs3g
[ebuild   R   ] sys-fs/ntfs3g-1.1120  USE="-debug -suid" 0 kB [1]

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/portage/local/local-overlay
--
--
>>> Unpacking ntfs-3g-1.1120.tgz to /var/tmp/portage/sys-fs/ntfs3g-1.1120/work
 * Applying Makefile.am.patch ...                                                                                                                                [ ok ]
 * Applying Makefile.in.patch ...                                                                                                                                [ ok ]
>>> Source unpacked.
--

So nun sollte alles Funktionieren. Man kann nochmal über eix nach unserem Paket suchen. So sieht dann dass die Version unseres Overlays installiert ist. Außerdem sollte man nochmal checken ob die Datei richtig erstellt worden ist und auch die Rechte und der Link so passen.

-- eix ntfs3g
[I] sys-fs/ntfs3g
     Available versions:  1.810 ~1.1030 ~1.1104 1.1120 1.1120[1] ~1.2129 ~1.2216 {debug suid}
     Installed versions:  1.1120(16:14:30 03/08/08)(-debug -suid)
     Homepage:            http://www.ntfs-3g.org
     Description:         Open source read-write NTFS driver that runs under FUSE

[1] /usr/portage/local/local-overlay
--

-- cat /sbin/mount.ntfs-3g
#!/bin/bash
ntfs-3g "$@" -o locale=de_DE.utf8
--

-- ls -l /sbin/mount.ntfs-3g
-rwxr-xr-x 1 root root 46  8. Mär 20:13 /sbin/mount.ntfs-3g
--

-- ls -l /sbin/mount.ntfs
lrwxrwxrwx 1 root root 19  8. Mär 20:13 /sbin/mount.ntfs -> /sbin/mount.ntfs-3g
--

Ich finde diese Möglichkeit absolut praktisch. Beachten sollte man allerdings, dass das lokale Overlay vor dem offiziellen Portage Vorrang hat, aber wenn jetzt z.B. die Version 1.2216 in unserem Portagetree stable wird dann hat diese vor dem lokalen Overlay Vorrang da sie aktueller ist. In diesem Sinne, fröhliches Merging!

Eine Woche Gentoo...

Nun ist es schon eine ganze Woche her seit dem ich kurz entschlossen angefangen habe Gentoo zu installieren. Alles in allem war die Installation bisher einfacher als erwartet. Allerdings dauerte es auch länger als ich dachte. Ich kann noch lange nicht sagen das alles fertig installiert und eingerichtet ist.

Mein altes Kubuntu 7.04 ist langsam doch in die Jahre gekommen. Außerdem ärgerte ich mich immer wieder über die Paketverwaltung da teilweise unschöne Abhängigkeiten, veraltete Pakete und wenig Anpassungsmöglichkeiten einem das Leben schwer machen. Allgemein bin ich warscheinlich aus der Zielgruppe von *buntu raus gewachsen, da zwar die Oberfläche schön und Sinnvoll eingerichtet ist (was mir jetzt nach dem Umstieg besonders auf fällt), allerdings dahinter absolutes Chaos herrscht. Wer wie ich gerne auf CLI-Basis arbeitet fällt dies sicher besonders auf. Bestes Beispiel ist der Networkmanager der nie tut was er soll. Jetzt habe ich einfach ein paar Konfigurationsdateien geschrieben und Netzwerk läuft ohne Probleme. Ebenso automatisches Einbinden von Wechseldatenträger etc. Ich glaub da kann man noch genug Beispiele finden. Und zu guter Letzt ärgerte es mich das Kubuntu, welches ich als KDE-Fan verwendet habe, von den *buntu Entwicklern eher vernachlässigt wurde.

So habe ich viel Hoffnung in Gentoo gesteckt und wurde auch im Großen und Ganzen nicht enttäuscht. Hier mal meine ersten Eindrücke von der Installation und einer Woche im Gebrauch. Außerdem vielleicht ein paar Tipps am Rande die dem ein oder anderen Umsteiger das Leben etwas einfacher machen sollte.

Installation

Wer auf einen Installer, wie man ihn in den meisten anderen Linux Distributionen kennt, hofft wird enttäuscht. Statt dessen startet man mit einer Live-CD und partitioniert so mit den gewohnten Programmen seine Festplatte und kopiert einige wichtige Programme. Anschließend wechselt man mit chroot auf die so erstellte Minimalumgebung und beginnt Programme wie den Bootmanager grub oder ein DHCP-Client zu installieren. Das erste mal wo ich wirklich geschockt wurde, war die Kernel Konfiguration. Man (darf|muss) jede Kerneleinstellung selbst setzten. Ich war damit erstmal völlig überfordert. Bisher habe ich allerdings bestimmt 30 Mal mein Kernel neu kompiliert und mittlerweile ist das Konfigurieren nichts mehr besonderes. Man sollte sich nur von Anfang an klar machen das man nicht alles gleich richtig einstellen kann. Einfach mal rum Probieren. Ganz wichtig für die komplette Installation ist das Handbuch. Ich rate jedem danach vor zu gehen.

Paketverwaltung

Man muss sich hier am meisten umgewöhnen. Binärpakete, wie unter den meisten anderen Distributionen, gibt es unter Gentoo nicht mehr. Statt dessen lädt man sich den Sourcecode herunter und kompiliert diesen selbst. Das hört sich schwerer an als es ist. Es gibt trotzdem eine Paketverwaltung. So das ein einfaches emerge PAKETNAME ausreicht um ein Paket mit allen Abhängigkeiten zu installieren. Es wird der Sourcecode heruntergeladen und wie man das auch von manuellen Kompilieren kennt configure und make aufgerufen. Wer öfters selbst kompiliert wird die Flags bei configure kennen. Man kann hier entscheiden ob einzelne Module kompiliert werden sollen oder eben nicht. Dies ist bei Gentoo sehr cool über so genannte USE-Flags gelöst die man zentral oder für einzelne Pakete angeben kann.

Man kann sich mit Use-Flags aber auch viel kaputt machen. Hier ein Tipp von mir: Am Anfang wenig USE-Flags nutzen und lieber später erneutes kompilieren mit veränderten Flags in kauf nehmen. Sonst passiert es euch wie mir, dass man eigentlich nur wpasupplicant für WPA Support installieren will aber gleichzeitig noch der Druckserver Cups, ein X-Server und die QT-Libraries als Abhängigkeiten mit kommen. Außerdem bei jedem Kompilieren bei emerge die Parameter für --verbose, --ask und --tree mitgeben um alle USE-Flags und Abhängigkeiten zu prüfen. Bestes Beispiel, bei dem man aufpassen muss, ist Eclipse. Will man dies in der Version 3.3 installieren und man passt mit den USE-Flags nicht auf so hat man danach Java 1.4, Java 1.5 und Java 6 installiert. Richtig freuen kann man sich aber auf der anderen Seite wenn man Psi mit dem USE-Flag "extra" kompiliert da Psi dann einige richtig coole neue Features hat. Oder wenn man Firefox mit "iceweasel" merged. Damit wird das Iceweasel Branding aktiviert. Leider ist nicht immer klar was ein USE-Flag jetzt genau bewirkt.

Einige sehr coole Features sind ccache und distcc. Distcc ist für verteiltes Kompilieren der Pakete was ich leider nicht ausprobieren konnte da es mir dazu an Computern fehlt. Ccache ist ein schneller Compiler Cache der Zwischenresultate speichert. So ist es möglich ein Programm viel schneller zu kompilieren wenn man es schon einmal übersetzt hat. Ich rate jedem ccache als eines der ersten Dinge auf dem System einzurichten. Mittlerweile schaffe ich es damit mein Kernel mit recht vielen Modulen in ca. sieben Minuten zu kompilieren. Ohne ccache dauert es bei mir fast 25 Minuten.

Insgesamt muss man beim installieren und vor allem beim deinstallieren sehr aufpassen da eventuelle Abhängigkeiten beim Deinstallieren nicht berücksichtigt werden. Außerdem kann es passieren das Programme nicht mehr laufen wenn man von Abhängigkeiten die USE-Flags ändert. Dafür hat man aber auch wahnsinnige Möglichkeiten (die ich evtl. die nächsten Tage näher beschreiben werde). Das einzige was ich wirklich vermisse ist mein geliebtes aptitude. Mit der Zeit kommt man aber auch ganz gut so zurecht. Nur weiter empfehlen kann ich eix auf das mich Klaus gebracht hat. Damit kann man sehr komfortabel sein Portage durchsuchen. Ansonsten helfen die drei Portage Seiten sehr weiter.

Man gewöhnt sich ans kompilieren allerdings freut man sich doch wenn zwischendurch mal ein Binärpaket wie z.B. den Grafikkartentreiber oder Flash erwischt da dann die Kompilierzeit auf 0 gedrückt wird.

GUI

Hier blickt man gerne auf *buntu zurück. Gentoo installiert zwar die Pakete, allerdings konfigurieren muss man das selbst. So ist es nicht so einfach unter KDE die Schriftgröße von Firefox anzupassen. Auch muss man zum Teil erst manuell definieren welche Dateien mit welchem Programm geöffnet werden sollen. Besonders beim Firefox ist das nervig. Aber da ich sowieso mit dem Gedanken spiele mich von dem kompletten KDE-Environment etwas weg zu bewegen und lieber mit anpassbaren und schnelleren Window-Managern zu arbeiten, komme ich so oder so nicht um die Konfiguration rum.

Was mir hier überhaupt nicht gefällt sind die "Metapakete". Metapakete sind Pakete die andere Pakete enthalten. So installiert man zum Beispiel nur kdepim und das gesamte KDE-PIM-Environment wird installiert. Leider aber nicht die einzelnen Komponenten als Abhängigkeit. So ist z.B. KMail in KDE-PIM enthalten und noch einmal als extra Paket. Will ich jetzt KMail deinstallieren geht das nicht weil das Paket KMail ist nicht installiert. Sondern nur kdepim was halt zufällig KMail enthält. Das ganze ist etwas unschön aufgebaut und ich bin noch nicht hinter den Grund gekommen. Ich hatte unter *buntu schon wenig für Metapakete übrig aber so ist das noch schlimmer.

Leider verfolgt mich auch das leidige nvidia-Treiber Thema welches ich im Zusammenhang mit Framebuffer und nvidia Treiber habe. Ich kann unter Konsole normal arbeiten aber sobald ich X mit nvidia Treiber starte komme ich nicht mehr zurück auf Konsole. Abhilfe schafft nur der langsamere xf86-video-nv Treiber der auch keine 3D Unterstützung anbietet. Allerdings habe ich jetzt schon andere Leute gefunden die das selbe Problem haben. Liegt also nicht an mir ;-)

Fazit

Der Umstieg hat sich auf jeden Fall gelohnt. Auch wenn ich noch ein bisschen Arbeit vor mir habe. Die Paketverwaltung ist echt cool und auch sonst glänzt es mit Anpassungsmöglichkeiten. Ich sag nur drei System-Logger und drei Cron-Daemons die allein im Handbuch beschrieben werden. Auf der anderen Seite muss ich mich über Details wie so manche Abhängigkeit oder eben der Metapackete wundern. Auch das Bash die Standard Shell ist hat mich als zsh Fan sehr überrascht. Ich bin allerdings froh das ich umgestiegen bin auch wenn ich noch einiges an Zeit reinstecken muss. Die sehr gute Community und die vielen Wikis und Foren helfen mir dabei sehr. In Sachen Dokumentation ist Gentoo auf jeden Fall vorne mit dabei!