Kleines Downloadskript für Mainline-Kernel

Da ich wegen meines Notebooks immer eine aktuelle stabile Vanilla-Version von Linux einsetze, habe ich mir in der Vergangenheit angewöhnt regelmäßig bei „www.kernel.org“ nachzuschauen, welches gerade die aktuellste stabile Linux-Version ist. Danach führte der Weg immer zum Mainline-PPA um dort dann die die Debian-Pakete des Kernels herunterzuladen. Diese sind in der Regel kurz nach der Freigabe einer neuen Version verfügbar. Da ich ein bequemer Mensch bin und mir vor allem das händische Herunterladen irgendwann auf den Geist ging, habe ich ein kleines Skript geschrieben, welches diese Schritte automatisiert:

Das Skript schaut auf der Kernel-Webseite nach, welches die aktuellste stabile Version ist und lädt dann aus dem Mainline-PPA die passenden Dateien herunter für den eingesetzten CPU-Typ herunter. Das Skript hat noch drei Parameter, welche für alle selbsterklärend sind, die schon einmal einen Kernel aus dem Mainline-PPA heruntergeladen haben. Das Skript prüft selbstständig ob die CPU und der Kerneltyp zusammenpassen (z.B. macht es keinen Sinn zu versuchen einen „i386“-Kernel vom Typ „snapdragon“ herunterzuladen. Letzteren gibt es nur für den CPU-Typ „arm64“) und lässt nur den Download einer verfügbaren Kombination zu.

Das Skript ist in Python3 geschrieben und benötigt ein Python-Module, welches aber in allen noch unterstützten Ubuntu und Debian-Versionen vorhanden ist:

sudo apt install python3-lxml

Das Skript habe ich auf Github gehostet: https://github.com/glasen/download_kernel

Direkter Download des Skripts: download_kernel.py

Eine kleine Einführung in die Bioinformatik und warum Linux dort so weit verbreitet ist

Wie ich in meinem Blog irgendwann mal erwähnt habe, studiere ich im Moment Bioinformatik an der THM und JLU in Gießen. Da ich nebenbei auch  noch einen Job in einer der Arbeitsgruppen habe, bekomme ich einen Recht guten Eindruck davon, was aktuell Forschungsgebiet in der Bioinformatik ist und vor allem welche Software und Hardware dort eingesetzt wird. Einen Überblick über beispielsweise die Hardware des Bioinformatikfachbereichs an der THM liefert der z.B. folgende Link:

mni.thm.de: Bioinformatik erweitert Infrastruktur

Ubuntu ist im Bioinformatik-Umfeld sehr weit verbreitet. Ich würde sogar sagen, dass knapp 80% aller Bioinformatiker Ubuntu (Mit verschiedenen Desktops) einsetzen. Der Rest verteilt sich auf Debian und Arch-Linux. Es gibt auch Windows-Nutzer, aber diese sind deutlich in der Unterzahl. Ein sehr nettes Feature seitens Ubuntu und Debian ist die Tatsache, dass nahezu alle wichtigen Bioinformatik-Tools direkt in den Paketquellen vorhanden sind. Das ist auch einer der Hauptgründe für die weite Verbreitung.

Die Bioinformatik ist grundsätzlich sehr Unix-affin. Nahezu alle Server, die irgendwas mit Bioinformatik und verwandten Gebieten zu tun haben, laufen unter einem Unix-System (Heutzutage hauptsächlich eine Linux-Distribution). Und wer tagtäglich auf einem Unix-System unterwegs ist, arbeitet auch privat eher mit so einem System.

„Eine kleine Einführung in die Bioinformatik und warum Linux dort so weit verbreitet ist“ weiterlesen

Upgrade von Ubuntu 16.04 auf Debian 9

Heute habe ich mal ein kleines (größeres?) Experiment gewagt und meinen Root-Server von Ubuntu 16.04 auf Debian 9 aktualisiert. Und siehe da:

Experiment geglückt, das Upgrade lief nach ein wenig Handarbeit vollkommen problemlos:

  1. Ich musste vor dem Upgrade meine Installation von MySQL auf MariaDB umstellen, da Debian 9 nur noch MariaDB anbietet. Das war ein wenig Konsolenarbeit mit Hilfe von „mysqldump“ und der MySQL-Konsole angesagt. Da ich eh schon seit Ewigkeiten auf MariaDB wechseln wollte, war das grundsätzlich keine zusätzliche Arbeit.
  2. Ich musste händisch das Paket „debian-archive-keyring“ von Debian 9 installieren, damit das Paketmanagement mich überhaupt Debian-Pakete installieren lies.
  3. Während des Upgrade-Vorgangs gab es einen Fehler wegen eines Konflikts zwischen zwei verschiedenen Paketen (Unter Ubuntu liegt eine Datei in einem anderen Paket als unter Debian). Ein „apt install -f“ hat das aber sofort behoben. Ansonsten gab es keine Unterbrechungen außer dem üblichen Nachfragen wegen geänderter Konfigurationsdateien.
  4. Dovecot hat keine Unterstützung für SSLv2 mehr. Ich musste also die Konfigurationsdatei von Dovecot entsprechend anpassen.
  5. Es gab etwa ein Dutzend Pakete (z.B. „libfontconfig1“ ), welche eine höhere Versionsnummer unter Ubuntu 16.04 haben als unter Debian 9. Diese musste ich händisch downgraden.
  6. Ich musste ein paar Dateien bezüglich „motd“ und „issue“ entfernen, damit sich mein System auch als Debian 9 zu erkennen gibt (Im Grunde nur Kosmetik)

Wie schon geschrieben, das Experiment ist geglückt und auf meinem Root-Server läuft jetzt Debian 9.

Warum das ganze? Ich wollte es einfach mal ausprobieren ob sowas überhaupt möglich ist. Wenn es schief gegangen wäre, hätte ich einfach ein Backup eingespielt und ich hätte nur etwas Freizeit vergeudet.

Firefox unter Ubuntu vernünftige Schriften beibringen

Mit der Freigabe von Freetype 2.7, kam bei mir wieder das Thema Schriftdarstellung unter Linux in den Focus. Ich hatte vor Jahren auf meinem alten, stillgelegten Blog das Thema schon einmal behandelt. Dieser Artikel ist eine Überarbeitung des alten Artikels von 2010:

Vor ein paar Jahren (2009) fragte ein Webdesigner im Forum von ubuntuusers.de nach Screenshots seiner Website (Der Link benötigt einen Account bei Ubuntuusers.de, da der Thread in der „Lounge“ liegt) welche mit Linux-Browsern aufgerufen wurde. In einem anderen Thread wurde vom gleichen Webdesigner nachgefragt welche Schriftarten standardmäßig unter den diversen Linux-Distributionen installiert sind bzw. mit welchen man in Normalfall immer rechnen kann. Daraus entwickelte sich eine Diskussion über gutes Webdesign bzw. die Abhängigkeit eines Webdesigners von den vorhandenen Schriftarten.

Das Problem ist seit der Einführung von Webfonts grundsätzlich nicht mehr so stark ausgeprägt, da ein Webdesigner heutzutage einfach per CSS und/oder Javascript fehlende Schriftarten nachladen lassen kann. Aber nicht jede Webseite bindet Webfonts ein, da viele Webdesigner immer noch davon ausgehen, dass Besucher der Seite entweder Windows oder OSX benutzen (Was oft heißt entweder „Helvetica (Neue)“ oder „Arial“ vorzugeben).

Ich hatte im Forum eine kurze Erklärung verfasst, warum manche Webseiten unter Linux sehr oft recht bescheiden ausschauen (Komische Schrift, zerrissenes Layout usw.) und wie man dieses Problem recht einfach beseitigen kann (Aus Nutzer -und aus Webdesignersicht).

Wie wählt mein Browser die Schriftarten aus?

Zuerst möchte ich die Grundlagen, wie ein Browser unter Linux seine Schriftarten auswählt, erläutern:

Jeder moderne Browser bietet in seinen Konfigurationsdialogen eine Möglichkeit an die Schriften, welche zum Darstellen der Webseiten benutzt werden sollen, auszuwählen. In den meisten Fällen beschränkt sich die Auswahl auf drei Möglichkeiten :

  • Serif
  • Sans Serif
  • Monospace

Ersteres sind Serifenschriften (z.B. Times New Roman, Liberation Serif, Courier, usw.)  des weiteren Schriften ohne („sans“) Serifen (z.B. Arial, Liberation Sans, Helvetica, usw.) und und am Ende Schriften mit fester Buchstabenbreite (z.B. Courier New, Liberation Mono, usw.). Zusätzlich lässt sich noch die Größe der Schriften und die Minimalgröße der Schriften festlegen.

Warum zeigt mir der Browser dann trotz allem einige Seiten mit einer anderen Schrift an?

Hier kommt nun ein Element von HTML bzw. CSS ins Spiel :

Wird im HTML-Code explizit eine bestimmte Schriftart vorgegeben (z.B. „Liberation Sans“ auf ubuntuusers.de), übergeht der Browser die vorgegebenen Schriftarten und benutzt die im HTML-Code angegebenen. Hier ein Beispiel wie ein „font-family“-Eintrag oft ausschaut:

font-family: "Helvetica","Arial",sans-serif;

Zuerst versucht der Browser die Seite mit der Schriftart “Helvetica” anzuzeigen. Falls diese nicht vorhanden ist, soll “Arial” benutzt werden. Falls diese wiederum nicht vorhanden ist soll die im Browser unter “sans-serif” vorgegebene Schriftart benutzt werden.

Warum sieht dann stellenweise die Schrift in meinen Browser immer noch so bescheiden aus?

Jetzt könnte man als Benutzer meinen das alles in Butter ist. In der Regel hat man ja auch unter Linux  bzw. Ubuntu die Windows-Schriftarten und damit “Arial” installiert (z.B. durch das Paket “msttcorefonts” bzw. “ttf-mscorefonts-installer”). Leider ist das nicht immer der Fall. So ist z.B. in der Grundinstallation der meisten Distributionen aus Lizenz-technischen Gründen dieses Paket nicht enthalten. Normalerweise wäre auch das kein Problem, da der Browser im Zweifelsfall einfach die unter “sans-serif” angegebene Schriftart benutzt. In der Auswahl der Schriften im Browser taucht ja kein „Helvetica“ auf, also ist diese auch nicht auf dem System vorhanden.

Jedoch besitzen alle Linux-Distributionen ein Schrift-Konfigurationssystem namens “Fontconfig”, welches dafür sorgt das das System auch bei  nicht vorhandenen Schriftarten eine (mehr oder weniger) fehlerfreie Ausgabe auf dem Bildschirm liefert. Dieses lässt sich sehr flexibel anpassen, hat in der Grundkonfiguration aber eine, gelinde gesagt, hirnrissige Einstellung, welche für die schlechte Darstellung der Schriften sorgt:

Fontconfig substituiert die fehlende Schriftart „Helvetica“ standardmäßig mit der Postscript-Schriftart „Nimbus Sans L„. Da CUPS als Abhängigkeit Ghostscript definiert und letztere diese Schriftart als Abhängigkeit mitbringt, ist die Schrift so gut wie immer installiert (Außer man verzichtet auf CUPS). Da die Schriftart “Helvetica” somit vorhanden ist, gibt es auch kein Ausweichen auf „Arial“ oder “sans-serif”.

Unter Fontconfig ist zusätzlich noch eine Substituierung von „Arial“ eingestellt. Standardmäßig wird beim Nichtvorhandensein diese gegen „DejaVu Sans“ ersetzt. Diese entspricht von der Schrifthöhe -und Breite nicht Arial, wodurch Webseiten die Standardmäßig „Arial“ einsetzen eine größere Darstellung des Inhaltes haben.

Und „Nimbus Sans“ ist nicht gerade für ihr gutes Aussehen auf Bildschirmen bekannt („Nimbus Sans“ ist als Druckerschriftart entwickelt worden). Die meisten Benutzer greifen dann einfach zur Radikalmethode und verbieten dem Browser per Konfigurationsoption das Benutzen aller anderen Schriftarten. Doch es geht auch eleganter:

Fontconfig die “Nimbus Sans”-Schriftart abgewöhnen

Um Fontconfig, Firefox und allen anderen Anwendungen das Ersetzen der Schriftart “Helvetica” gegen “Nimbus Sans” abzugewöhnen, ohne die Schriften löschen oder den Browser umkonfigurieren zu müssen, gibt es eine relativ einfache Methode:

Man ersetzt einfach alle Vorkommen von “Nimbus” in den Dateien unter “/etc/fonts/conf.avail” gegen eine andere Schriftart (z.B. „Liberation Sans“). Unter Ubuntu kommt dieser Name nur in drei Dateien vor (Bei anderen Distributionen sollten die Dateinamen und Vorkommen identisch sein):

  • 30-metric-aliases.conf
  • 45-latin.conf
  • 60-latin.conf

Um die Sache etwas zu vereinfachen, biete ich die geänderten Dateien zum Download an :

fontconfig.tar.bz2

Im TAR-Archiv sind die drei oben genannten Dateien enthalten (Eben nur mit den Liberation Fonts als Fallback) sowie ein kleines Skript, welches mit Root-Rechten ausgeführt werden muss. Dieses legt mit Hilfe von „dpkg-divert“ eine Umleitung der Original-Dateien und und kopiert die neuen Dateien dann nach „/etc/fonts/conf.avail“. Die Umleitung ist deshalb notwendig, da bei jedem möglichen Update des Fontconfig-Pakets ansonsten die Änderungen verloren gehen würden. So schreibt der Paketmanager die Änderungen in die umgeleiteten Original-Dateien und lässt die veränderten Dateien in Ruhe.

Startet man jetzt den Browser neu bzw. loggt sich neu ein, wird die Schriftart “Nimbus Sans” nicht mehr als Ersatz für den Schrifttyp “Helvetica” verwendet, sondern “Liberation Sans”. Die Schrift ist quasi eine Kopie von „Arial“, welches selbst eine (dreiste) Kopie von „Helvetica“ ist und entspricht fast 100% dem Schriftbild (Breite und Höhe) dem Vorbild.

Somit benutzen Firefox und andere Browser endlich vernünftige Bildschirmschriften und man muss sich als Benutzer nicht mehr mit einem schlechten Schriftbild herumärgern.

„bootctl“ als Alternative zu GRUB2

Seit Jahren ist der „Grand Unified Bootloader“ kurz „GRUB“ bzw. dessen Nachfolger GRUB2 bei den allermeisten Distributionen der Standard-Bootloader. Beide funktionieren sehr gut, wirken aber in Zeitalter von UEFI und auf normalen PCs, die nur von Festplatte booten, irgendwie aus der Zeit gefallen. Während GRUB Version 1 noch relativ übersichtlich und einfach zu konfigurieren war, benötigt man bei GRUB2 schon fast ein Hochschulstudium um durchzublicken.

PCs mit UEFI-Firmware benötigen keinen komplexen Bootloader mehr. Man kann die Firmware direkt den Kernel booten lassen. Ein dezidierter Bootloader ist in den meisten Fällen überflüssig und nur noch in Spezialfällen notwendig. Leider ist das Verfahren nicht ganz einfach umzusetzen, da man der Firmware die benötigten Kerneloptionen von Hand übergeben muss. Dazu können noch weitere Probleme kommen (Siehe z.B. ArchWiki – EFISTUB). Dazu kommt, dass bei einem Reset der Firmware alle Einträge verloren gehen und man mit einem nicht-bootfähigen System dasteht.

Es geht aber auch sehr viel einfacher:

Man benutzt einfach den, von systemd mitgelieferten, Bootloader „bootctl“. Der Loader ist kein neues Projekt, sondern hieß vor der Integrierung in systemd „gummiboot“ (Welcher wiederum nur als Referenzimplementierung gedacht war).

Installation von „bootctl“

Bitte die Anleitung einmal komplett durchlesen, bevor man sich darauf stürzt „bootctl“ einzusetzen!

Die Installation des Bootloaders ist sehr einfach (Ubuntu 16.04 und höher):

sudo apt-get purge grub* (Deinstalliert GRUB2 komplett)
sudo rm -r /boot/grub (GRUB2-Dateien aus dem boot-Verzeichnis/Partition löschen)
sudo efibootmgr -b 0000 -B (Entfernt den "ubuntu"-Eintrag aus der Firmare)
sudo bootctl install ("bootctl" in der Firmware hinterlegen)

Bitte setzt den Befehl „efibootmgr“ nur ein, wenn ihr 100% sicher seid, dass ihr dadurch nicht die Firmware-Einträge zerstört. Normalerweise ist der Ubuntu-Eintrag die Nummer 0000. Man sollte aber vor dem Löschen zur Sicherheit die Nummer überprüfen. Im Zweifelsfall lässt man den Eintrag in der Firmware und ändert im „BIOS-Setup“ die Reihenfolge von Hand und setzt den neuen Eintrag „Linux Boot Manager“ ganz nach vorne.

Leider gibt es einen kleinen Makel:

Im Gegensatz zum Vorgänger „gummiboot“ bzw. dessen Paket in Ubuntu, installiert bzw. aktualisiert der Loader nicht automatisch die Kerneleinträge. Diese müssen leider von Hand angelegt werden. Aus diesem Grund habe ich die Dateien aus dem Paket „gummiboot“ extrahiert, welche diese Funktionalität unter „gummiboot“ bereitgestellt haben. Im Prinzip ist es nur eine kleine Konfigurationsdatei und ein kleines Shell-Skript, welche dafür sorgen, dass nach jedem Kernel bzw. Initrd-Update der Bootloader entsprechend konfiguriert wird. Hier mal der Link zur DEB-Datei:

bootctl_0-1-ubuntu1_amd64

Liste der Dateien im Paket:

/etc/default/bootctl (Konfigurationsdatei für den Bootloader. Hier werden die Kerneloptionen eingefügt)
/etc/initramfs/post-update.d/zz-update-bootctl (Wird aufgerufen, wenn eine Initial-Ramdisk installiert bzw. aktualisiert wird).
/etc/kernel/postinst.d/zz-update-bootctl (Wird bei einer Kernel-Installation aufgerufen)
/etc/kernel/postrm.d/zz-update-bootctl (Wird bei einer Kernel-Deinstallation aufgerufen)
/usr/sbin/update-bootctl (Das eigentliche Update-Skript. Kopiert den Kernel und die Initial-Ramdisk auf die EFI-Partition und legt im Loader die Einträge an).

Bei den meisten Systemen sollte es ausreichen das Paket zu installieren um den Bootloader fertig zu konfigurieren. Falls die EFI-Partition nicht unter „/boot/efi“ gemountet ist, muss man noch den Parameter „–path=PATH“ zum bootctl-Kommando hinzufügen und in der Datei „/etc/default/bootctl“ die Variable „BOOTCTL_EFI“ nach der Installation des Pakets entsprechend anpassen.

Warum das Ganze?

Wie schon am Anfang angesprochen, ist „bootctl“ deutlich einfacher aufgebaut als GRUB2. Es gibt im Grunde nur zwei Dateien die man bearbeiten muss, um den Loader zu konfigurieren. Dazu kommt, dass der Loader keine Probleme mit verschiedenen root-Dateisystemen hat. Auf meinem Desktop-PC liegt „root“ auf einem XFS-Dateisystem und ich musste meine „boot“-Partition explizit auf ein „ext4“-Dateisystem legen damit GRUB2 das System überhaupt booten konnte (Getestet unter Ubuntu 16.04, 16.10, Debian Testing). Eigentlich sollte GRUB2 mit XFS umgehen können, aber egal was ich versucht habe, es hat nicht funktioniert.

„bootctl“ sind die Dateisysteme vollkommen egal, da der Loader und die Kerneldateien immer auf der EFI-Partition liegen und ersterer nur dafür sorgt, dass der Kernel direkt von der Firmware geladen wird. Das heißt man kann grundsätzlich jedes Dateisystem als „root“-Partition einsetzen, solange der Kernel und die Initial-Ramdisk damit umgehen können. Bei Grub muss man sich daran orientieren, was dieses selbst an Dateisystemen unterstützt.

25 Jahre Linux: Slackware 1.1.2 – Meine erste Linux-Distribution

Da sich der Geburtstag von Linux zum 25 mal jährte, dachte ich mir, es wird mal Zeit eine uralte Linux-Distribution auszugraben und auszuprobieren.

Ich hatte den gleichen Artikel schon einmal vor ein paar Jahren auf meinen Blog veröffentlicht, dieser ging aber nach der Stilllegung dieses aber verloren. Dank der Wayback-Machine habe ich ihn wieder herstellen können (Wenn auch ohne Bilder). Zusätzlich habe ich ihn noch ein wenig überarbeitet.

Einleitung

Slackware 1.1.2 erschien am 15.Februar 1994. Ausgestattet war diese Distribution mit Linux 0.99.15, GCC 2.5.8, und XFree86 2.0. Als Windowmanager wurden “fvwm” in der Version 1.2, sowie SUNs Desktopversuch OpenWindows mitgeliefert. Man kann die mitgelieferte Softwareausstattung also ohne Übertreibung als „prähistorisch“ bezeichnen.

Für mich war diese Version die erste Bekanntschaft mit Linux und Unix überhaupt. Ich spare mir an dieser Stelle die Geschichte, wie ich damals an die Installations-CD mit Slackware kam. Jedenfalls nimmt die Slackware-CD immer noch einen Ehrenplatz in meiner CD-Sammlung ein. Witzigerweise war die Installation unter QEMU auch das erste Mal, dass ich diese Slackware-Version überhaupt sauber zum Laufen bekommen habe. Als ich mir nämlich die CD damals kaufte, hatte ich gerade einmal einen Rechner mit einer 386SX25-CPU, 3MB RAM und einer 40MB Festplatte. Da ich im Leben noch nie etwas von Swap-Partitionen gehört hatte, ging mir beim Rumspielen mit dem System immer der Speicher aus, weshalb es damals auch bei einigen wenigen Versuchen blieb. Die ersten richtigen Schritte mit Linux machte ich erst ein paar Monate später mit einem 386DX40MHz, 4MB RAM, einer 120MB Festplatte und DLD (Deutsche Linux Distribution).

Die Installation

Die Installation dieser alten Slackware-Version stellte mich vor einige besondere Herausforderungen:

Linux lernte erst mit Version 1.2 mit IDE-CDROM-Laufwerken umzugehen. Davor konnte es nur mit einigen proprietären Laufwerkscontrollern und den passenden Laufwerken (Das bekannteste Laufwerk war damals ein Single-Speed-Laufwerk von Mitsumi) umgehen. Ein direkter Zugriff auf das CD-Image während der Installation war also nicht möglich.

Mir blieben also nur zwei Wege, die Installation durchzuführen:

  1. Installation über Disketten-Images
  2. Installation über ein gemountetes Installationsverzeichnis

Den ersten Weg konnte ich mir gleich sparen, da außer der „root“- und „boot“-Diskette (Ältere Linux-Benutzer dürften sich noch erinnern), keine weiteren Disk-Images vorlagen. Ich hätte also alle Dateien der einzelnen Verzeichnisse auf dutzende Disketten verteilen müssen und dazu hatte ich einfach keine Lust.

Als zweite Möglichkeit bot sich die Installation per gemounteten Installationsverzeichnis an. Der Installer von Slackware bietet seit Alters her die Möglichkeit an, die Installationsdateien aus einem beliebigen Verzeichnis zu holen. Ich musste also nur einen Weg finden die Dateien auf eine, von Slackware lesbare, Partition zu packen.

Um dieses zu ermöglichen, musste ich folgendermaßen vorgehen:

  1. Erstellen eines zusätzlichen QEMU-Festplatten-Images mit ca. 100MB.
  2. Einbinden dieses Images (neben dem Image des später installierten System) in QEMU.
  3. Partitionieren und formatieren der neuen Partition unter dem virtualisierten Slackware mit dem ext2-Dateisystem.
  4. Mounten des QEMU-Images bzw. der ext2-Partition innerhalb meines Host-Systems, mit Hilfe von des Kernelmoduls „nbd“ und „qemu-nbd“.
  5. Kopieren aller Installationsdateien von Slackware auf die Partition.
  6. Einbinden der Partition in das virtualisierte Slackware.
  7. Auswählen des Verzeichnisses im Installer.

Dieser Weg funktionierte deshalb, weil sich das ext2-Dateisystem in all den Jahren kaum verändert hat bzw. moderne Versionen des Dateisystems einen Kompatibilitätsmodus für ältere Versionen besitzen und man ein älteres Dateisystemformat relativ problemlos auch heute noch mounten kann.

Jedenfalls konnte ich am Ende innerhalb der virtuellen Maschine, problemlos auf die Installationsdateien von Slackware zugreifen.

Alte Dateisysteme von Linux:

  • Minix – Dieses war das ursprüngliche Dateisystem bei der Entwicklung von Linux. Es wurde 1:1 von Minix übernommen, wurde aber recht schnell, wegen zu großer Beschränkungen, gegen weiterentwickelte Dateisysteme ersetzt. Das Minix-Dateisystem wurde aber noch einige Jahre auf den Installationsdisketten diverser Linux-Distributionen benutzt (z.B. SuSE).
  • extfs – Der Vorgänger des bekannten ext2fs. Das Dateisystem war im Grund nur eine leicht verbesserte Version des Minix-Dateisystems.
  • Xiafs – War eine verbesserte Variante des minix-Dateisystems und war bis zu einem bestimmten Zeitpunkt stabiler, schneller und platzsparender als das bekannte ext2-Dateisystem. Größtes Manko im Vergleich zu ext2, war das Fehlen eines “Dirty”-Bits um ein nicht korrekt ausgehängtes Dateisystem zu markieren. So musste ein Dateisystemcheck immer von Hand ausgeführt werden. Zudem entwickelte sich ext2 damals rasant weiter, sodass Xiafs ab einem bestimmten Zeitpunkt nicht mehr konkurrenzfähig war.

Die Konfiguration

Nach der Installation fing die eigentliche Arbeit an:

So gab es damals nicht ohne Weiteres eine deutsche Tastaturbelegung. Diese musste von Hand nachgeladen bzw. in die Datei „rc.local“ eingebunden werden.

Auch die Inbetriebnahme der Netzwerkkarte gestaltete sich etwas schwieriger, da Plug’n Play und PCI damals noch nicht existierten. Zum Glück erlaubt QEMU auch das Emulieren einer ISA-Netzwerkkarte. Da die Version 0.99.15 einen kleinen Bug im Zusammenhang mit der NE2000-Karte hat (Es wird grundsätzlich IRQ4 benutzt, egal was in der Config-Datei des Kernels eingestellt ist), habe ich den Kernel gleich auf Version 1.0 aktualisiert (Linux 0.99.15 wurde im Dezember 1993 freigegeben. Die Version 1.0 erschien im März 1994).

Als größtes Problem sollte sich die Einrichtung des X-Servers erweisen. Da sich die Syntax der X-Konfigurationsdatei in den letzten 20 Jahren sehr stark verändert hat, musste ich erst einmal mein Wissen über diese alte X11-Version auffrischen. So musste man sich damals noch mit den Modeline-Einträgen zur Programmierung der passenden Auflösung und Bildwiederholfrequenzen herumärgern. Durch die freie Programmierung des Monitors musste man damals sehr vorsichtig sein, um seinen Monitor nicht über den Jordan zu schicken. Nicht wenige Benutzer sahen nach einer Fehlkonfiguration (Weil sie z.B. den Monitor außerhalb seiner Spezifikation betrieben) schwarzen Rauch aus den Lüftungsschlitzen aufsteigen. Unter QEMU kann so etwas natürlich nicht passieren, da der Monitor bzw. die Grafikkarte nur emuliert wird. Hier kann man im Prinzip Fantasiewerte in einem Modeline-Eintrag angeben. Hauptsache die Felder mit den der Auflösung sind richtig eingetragen.

Auch musste ich explizit einen bestimmten (eigentlich falschen) „Cirrus Logic“-Chip angeben (QEMU benutzt den Cirrus Logic 5446, benutzt habe ich den Cirrus Logic 5424, kurz clgd5424), um den X-Server überhaupt zum Laufen zu bekommen. Der X-Server kannte nämlich die ID des emulierten Grafikchips noch nicht (Der “verbaute” Grafikchip kam erst ein paar Jahre später auf dem Markt).

Danach lief der Xserver vollkommen problemlos, auch wenn nach dem Umschalten auf die Textkonsole die Schrift nicht mehr angezeigt wird. Zumindest reagiert das Terminal noch auf Eingaben, wodurch ein „reboot“ abgesetzt werden kann.

Betrieb

Tja, was ist mit so einem alten System überhaupt noch möglich? Man kann sich daran ergötzen ein Linux-System zu haben, dass innerhalb weniger Sekunden betriebsbereit ist. Richtiges Arbeiten nach den heutigen Maßstäben ist mit dieser alten Slackware-Version nicht mehr möglich. Dazu fehlen einfach die Programme bzw. die vorhandenen Programme sind einfach schon zu alt. Ich habe z.B. versucht eine alte Version des Mosaic Browsers zum Laufen zu bekommen, was aber aus verschiedenen Gründen fehlschlug (Fehlende Motif-Bibliotheken, andere fehlende Bibliotheken, generelle Bugs beim Starten). An modernere Programme die Gtk oder Qt benötigen braucht man gar erst nicht zu denken.

Im Grunde sind als Produktivprogramme nur Emacs, TeX (ohne LaTeX), GCC, diverse andere Editoren und einige kleinere grafische Tools vorhanden. Also nichts, womit sich ein moderner Computerbenutzer überhaupt anfreunden würde.

Fazit

Im Vergleich zu heutigen Linux-Distributionen wirkt die alte Slackware-Installation sehr unfertig und kantig. Es gibt so gut wie keine Automatismen oder Komfortfunktionen. Das man z.B.nach der Installation nur eine englische Tastaturbelegung hat, ist noch eines der kleineren Übel. Die größte Hürde wird für die meisten die Einrichtung eines funktionierenden Xservers sein gewesen.

Linux war damals noch ein System für Menschen, die sich schon mit Unix auskannten und daheim auch ein “echtes” Unix haben und/oder gerne an ihrem Computer experimentierten und etwas Neues kennenlernen wollten. Es war definitiv nicht für Leute gedacht, die ihren Computer nur einfach benutzen wollten. Ohne eine gedruckte Dokumentation lief fast gar nichts, schon alleine aus dem Grund, da es damals keine bezahlbaren Zugänge zum Internet für den Heimanwender gab.

Das war auch der Grund warum z.B. SuSE Linux in Deutschland recht schnell zum Marktführer bei den Linux-Distributionen wurde. Man bekam sehr gute gedruckte Handbücher und die Vorkonfiguration des gesamten Systems war auch deutlich besser als beim reinen Slackware (Auf dem SuSE Linux in den ersten Versionen basierte).

Ich habe mir mal den Spaß erlaubt und ein TAR-Archiv mit den QEMU-Image-Dateien des installierten Systems bei Dropbox hochgeladen. Um das System in Betrieb zu nehmen, muss man nur QEMU installieren, das Archiv entpacken und über Befehl „start-slackware.sh“ ausführen.

Die Installation startet direkt zum einem grafischen Login durch. Der Benutzer „gonzo“ startet den Fenstermanager “fvwm2”. Es sind noch die Benutzer „satan“ (Verzeichnis „/home/hell“) und „snake“ (Verzeichnis „/home/pit“) vorhanden, die aber komplett unkonfiguriert sind und den Fenstermanager “twm” starten. Alle Benutzer (inkl. „root“) haben kein gesetztes Passwort.

Um den Rechner sauber herunterzufahren, muss man in einem geöffneten grafischen Terminal den Befehl su -c „/sbin/shutdown -h now“ bzw. su -c „/sbin/reboot“ ausführen. Beim Herunterfahren, Neustarten oder Ausloggen aus X11 (Wenn man den Textmodus benutzt und X11 erst später startet) gibt es leider einen Bug, welcher dazu führt, dass man die Text-Meldungen nicht mehr sehen kann. Man sollte deshalb ungefähr eine Minute warten, bis man das QEMU-Fenster schließt.

Um wieder dauerhaft den Textmodus einzustellen, muss man in der Datei „/etc/inittab“ das Standard-Runlevel von 6 auf 5 ändern (Zeile „id:6:initdefault“). Im Text-Modus-Runlevel gibt es den oben beschriebenen Bug übrigens nicht. Dort funktioniert alles wie gewohnt.

Wer gerne mit Linux experimentiert, wird mit dem alten System seine wahre Freude haben. Vor allem kann man sehr deutlich sehen, wie sich Linux in den letzten 21 Jahren weiterentwickelt hat. Witzigerweise hat sich der Installer von Slackware seit dieser Zeit kaum verändert.

Am Ende möchte ich noch einen Link zu einer Webseite anbieten, welcher einige sehr alte Linux-Distributionen zum Download anbietet:

http://www.oldlinux.org/Linux.old/

Auf dieser Seite kann z.B. eine Version von DLD, welche damals die beste deutsche Übersetzung aller Distributionen anbot, finden. Auch findet man dort ein VMWare-Image einer Linux-Installation (Distribution ist in diesem Fall zu hoch gegriffen), die auf der Kernelversion 0.11 basiert. Diese Version erschien am 6. Dezember 1991 und stellte die erste Linux-Version dar, die unter sich selbst kompiliert werden konnte (Bis zu dieser Version musste Linux unter Minix kompiliert werden). Linux war zu diesem Zeitpunkt nicht einmal drei Monate alt!

Firefox 46 unter Linux standardmäßig als Gtk3-Build

Nach Jahren des Wartens wird seit Firefox 46 endlich standardmäßig Gtk3 als Toolkit benutzt. Dadurch passt sich Firefox besser an moderne Oberflächen an und benutzt z.B. die integrierten Scrollbars von Gtk3. Zusätzlich scheint Firefox ein wenig performanter in der Grafikdarstellung geworden zu sein, wobei das ein rein subjektiver Eindruck meinerseits ist.

Neben dem offiziellen Paket von der Mozilla-Seite wird in allen noch unterstützten Ubuntu-Versionen (14.04, 15.10 & 16.04) Firefox 46 ebenfalls als Gtk3-Build ausgeliefert.

Leider hat es die Multiprozess-Architektur noch nicht in Firefox 46 geschafft. Diese soll ab Version 48 dann für alle Benutzer aktiviert werden.

Erfahrungen beim Installieren von Ubuntu auf Dutzenden von Notebooks

Heute musste ich mit meinem Kommilitonen im Rahmen unseres HiWi-Jobs auf Dutzenden von Notebooks Linux installieren. Dabei waren die Notebooks von den unterschiedlichsten Marken und Modellen (Eben die privaten Notebooks der Studenten). In unserem Studiengang „Bioinformatik“ ist Linux sozusagen Pflicht und unsere Aufgabe ist es die neuen Studenten bei der Installation und beim weiteren Benutzen zu unterstützen. „Erfahrungen beim Installieren von Ubuntu auf Dutzenden von Notebooks“ weiterlesen

Warum LibreOffice eine bessere Qualitätskontrolle benötigt!

Ich musste die vorletzte Woche ein sogenanntes „Book of Abstracts“ für eine Summer School an der JLU erstellen. Das Book besteht im Grunde nur aus einer Ansammlung von einzelnen kleinen Artikeln und umfasste am Ende nicht mehr als etwa ein Dutzend Bilder und knapp 50 Seiten. Also nichts, was ein modernes Office-Paket überfordern sollte. „Warum LibreOffice eine bessere Qualitätskontrolle benötigt!“ weiterlesen