Case-Modding-Projekt: Wie packe ich einen modernen PC in ein SGI Indigo2-Gehäuse?

Vor ein paar Jahren war ich im Besitz zweier SGI Indigo2:

  • Einer „Teal“-Indigo2, welche ich von einer XZ-Grafik auf eine Impact-Grafik umgebaut hatte. Diese hatte eine MIPS 4400-250MHz CPU und 256MB RAM.
  • Eine „Purple“-Indigo2 mit einer MIPS R10000-175MHz CPU, 384MB RAM und einer High-Impact-Grafikkarte.

Aus Mangel an Zeit und Platz lagen die beiden Indigos gut verpackt im elterlichen Keller. Leider wurde dieser ein Opfer der Aufräumwut meiner Mutter und beide Indigos landeten ohne Rückfragen auf der Wertstoffdeponie.

Vor ein paar Monaten bin ich dann bei eBay-Kleinanzeigen auf eine „Purple“-Indigo2 gestoßen. Diese war laut Verkäufer seit 20 Jahren nicht mehr im Einsatz und er konnte keine Funktionsgarantie geben, aber 100€ war mir der Spaß und das Risiko wert.

Leider gab die Indigo2 beim Funktionstest keinen Laut von sich. Die Lüfter drehten sich nicht und die LEDs bleiben auch tot. Wahrscheinlich waren einige Elektrolytkondensatoren im Netzteil über die Jahre ausgetrocknet. Ich habe mich natürlich sofort auf die Suche nach einem Ersatznetzteil gemacht, aber alle Quellen schienen ausgetrocknet zu sein bzw. es wurden Preise für ein Ersatznetzteil verlangt, die jenseits von Gut und Böse sind (200€ aufwärts). Auch der Umbau eines modernen ATX-Netzteils war keine Option, da sich dieses massiv von dem Originalnetzteil unterscheidet und ich mir den Umbau ohne externe Hilfe nicht zugetraut habe. Da ich aber nicht sicher sein konnte, ob nur das Netzteil betroffen ist, habe ich mich gegen eine Instandsetzung des Rechners entschieden und für den Umbau des Gehäuses entschieden, so dass ein normales mATX-Mainboard und ein modernes Netzteil hineinpassen, (SGI-Fans mögen mir das Sakrileg entschuldigen).

„Case-Modding-Projekt: Wie packe ich einen modernen PC in ein SGI Indigo2-Gehäuse?“ weiterlesen

AusweisApp2 unter Debian 10

Heute hatte mich ein Benutzer angeschrieben und mich nach einer Fehlermeldung des Snap-Pakets von AusweisApp2 unter Debian 10 gefragt. Dabei poppt eine Dialogbox auf und sagt, dass Port scbon 24727 belegt sei.

Diese Meldung erscheint aus folgendem Grund:

Das Paket „snapd“ aus Debian 10 ist zu alt. Es ist noch auf dem Versionsstand 2.37 während unter Ubuntu die Version 2.44 aktuell ist. Leider gibt es keinen Backport von „snapd“ für Debian 10, aber man kann sich aber auf anderem Weg helfen:

Man installiert einfach die das Snap-Paket „snapd“:

snap install snapd

Falls es eine Fehlermeldung geben sollte, muss noch das Paket „core“ installiert werden:

snap install core

Danach loggt man seinen Benutzer kurz aus und wieder ein und die Fehlermeldung ist verschwunden.

AusweisApp2 als Snap #3

Ich habe eine neue Version des Snap-Pakets veröffentlicht. Dieses beinhaltet das Treiberpaket von „Reiner SCT“ für den PC/SC-lite Daemon.

Dadurch unterstützt der Daemon z.B. den „Reiner SCT cyberJack RFID standard. Dessen Treiber wurde im CCID-Treiber 1.4.30 auf Bitte von „Reiner SCT“ deaktiviert.

Das Update wird von „snap“ automatisch durchgeführt. Man kann es auch per „snap refresh ausweisapp2-ce“ anstoßen.

AusweisApp2 als Snap #2 (Update 06.04.19)

Nach Wochen der Bastelei habe ich es endlich geschafft ein Snap-Paket für die AusweisApp2 zu bauen, welches auch mit dem Confinement funktioniert. Die einzige Einschränkung, die aktuell noch existiert, ist das man nach der Installation einmalig die benötigten Interfaces des Snap-Pakets „connecten“ muss. Danach funktioniert die Anwendung ohne weitere Einschränkungen:

sudo snap install ausweisapp2-ce
sudo snap connect ausweisapp2-ce:raw-usb :raw-usb
sudo snap connect ausweisapp2-ce:hardware-observe :hardware-observe
sudo snap connect ausweisapp2-ce:network-manager :network-manager
sudo snap connect ausweisapp2-ce:network-observe :network-observe
sudo systemctl restart snap.ausweisapp2-ce.pcscd.service

Letzterer Befehl ist notwendig, damit der Card-Daemon noch vor dem ersten Start der Anwendung die passenden Rechte besitzt.

Ich habe im Snap-Store einen Request zum Auto-Connecten gestellt. Falls dieser genehmigt wird, kann man die Anwendung auch ohne explizites „connecten“ installieren.

Update

Ich habe gestern (05.04.19) die Freigabe des Stores für das automatische „connecten“ der benötigten Interfaces erhalten. Es reicht jetzt also aus das Snap zu installieren. Es sind keine weiteren Schritte notwendig.

AusweisApp2 als Snap (Update 25.01.19)

Da ich im Moment Urlaub und viel Zeit habe, habe ich mich mal daran gemacht ein Projekt zu vollenden, welches ich schon seit ein paar Monaten in die Augen gefasst habe:

Das Paketieren der AusweisApp2.

Falls jemand nicht weiß, wozu dieses Programm dient, hier mal der Link zum passenden Wikipedia-Artikel:

https://de.wikipedia.org/wiki/AusweisApp2

Offiziell unterstützen die Entwickler Linux nicht, dadurch dass der Quellcode aber unter Github und unter einer freien Lizenz verfügbar ist, kann man wenigstens den Versuch wagen das Programm unter Linux zum Laufen zu bekommen.

„AusweisApp2 als Snap (Update 25.01.19)“ weiterlesen

Eine Lanze für moderne Computer brechen

Retrocomputing ist in. Wer, wie ich, seine ersten Erfahrungen mit Computern in den 80er Jahren gemacht hat, ist für dieses Thema besonders empfänglich. Dabei ist der Blick zurück häufig ziemlich verklärt und die alte Zeit wird als die bessere angesehen. Dabei wird übersehen, dass früher nicht alles eitel Sonnenschein war.
Der folgende Artikel bezieht sich allein auf meine Erfahrungen, welche sehr stark von Heimcomputern und PCs mit MS-DOS geprägt wurden und weniger von Konsolen. Ich habe exemplarisch das Jahr 1992 als Grundlage des Artikels genommen, wobei ich auch spätere Jahre (bis ca. 1997) anspreche um bestimmte Sachverhalte zu verdeutlichen.


Kurze Biographie meinerseits:
Jahrgang 1977. Der erste C64 irgendwann im Jahr 1988. Im Oktober 1990 folgte ein Atari ST mit 1 MB RAM, im Mai 1992 dann ein PC (AMD 386SX25 CPU, 1 MB RAM und 40 MB HDD).

Warum ausgerechnet 1992? Weil ich in diesem Jahr meinen ersten PC gekauft habe und zusätzlich weil zu diesem Zeitpunkt der Computermarkt noch sehr viel heterogener war als heute. Neben den PCs waren noch sehr häufig Heimcomputer (Amiga, Atari ST oder C64) im Einsatz und viele Spiele und Programme wurden noch für mehrere Plattformen entwickelt. Zudem war der Leistungsunterschied zwischen den PCs und den Heimcomputern noch nicht so groß, obwohl Letztere mit der breiten Verfügbarkeit von 386er CPUs und VGA-Grafikkarten ins Hintertreffen gerieten.

Hier mal einige Punkte, welche meine Sicht auf die damalige Hardware und Software aufzeigen soll:

„Eine Lanze für moderne Computer brechen“ weiterlesen

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 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 zusätzliches Python-Modul, 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.