Skip to content

LineageOS auf Galaxy S2 (i9100) installieren

^ v M ><
Mir ist ein altes Samsung Galaxy S2 in die Hände gekommen, das für einen potentiellen Empfänger tauglich gemacht werden sollte. Bislang war bereits ein etwas in die Jahre (oder doch nur Monate?) gekommenes Cyanogenmod installiert. Aber Cyanogenmod ist tot, darum soll auf jeden Fall aktuellste Software installiert werden. Da kommt fast nur LineageOS in Frage (v.a. auch da ich damit gute Erfahrungen auf S3 und S5 gemacht habe). Da der Empfänger noch empfindlicher auf seine Privatsphäre achtet als ich, habe ich die Google-Apps weggelassen. Diese zu installieren benötigt aber nur einen weiteren Befehl und zwei Klicks mehr in der Recovery.

Leider war die Installation nicht ganz einfach, da die /system-Partition erstens nur 500MB gross ist (das ist zu klein, LineageOS verlangt mindestens 600MB), zweitens einen Defekt hat und drittens alle im Internet gefundenen Anleitungen zur Installation und Repartitionierung falsch sind, insbesondere die offizielle Anleitung von LineageOS. Ausserdem sind die meisten Anleitungen von Windows-Schafen geschrieben und nutzen Odin, während mir unter Linux Heimdall zur Verfügung steht.

Als Voraussetzung für diese Anleitung setze ich voraus, dass der Leser mit TWRP bereits vertraut ist. Ausserdem gilt ganz klar: Anwendung auf eigene Gefahr!

Beim i9100 sind ein paar Spezialitäten zu beachten, so ist das Recovery-Image in das Kernel-Image integriert.

So hat's bei mir funktioniert:
Erst sichergehen, dass auf dem Computer die aktuellsten Versionen von heimdall und adb installiert sind.
Download von PIT-Dateien (eine Art Partitionstabelle für Samsung-Geräte) von hier
Download von TWRP (Custom Recovery) von hier
Download des aktuellsten LineageOS-Build von hier
Ggf Download des su-addons und/oder gapps, wenn benötigt.
Aus lineage-14.1-*-nightly-i9100-signed.zip muss die Datei boot.img extrahiert werden.
Aus Pit_files.rar muss die gewünschte PIT-Datei extrahiert werden, ich habe I91001GB_4GB.pit (1GB /system, 4GB /data) verwendet.

Boot des Telefons in den Download-Modus mittels VolDown-Home-Power (Bestätigen mit VolUp). Anschliessend das USB-Kabel anschliessen.
Upload des neuen PIT-Files und flashen der Recovery mittels:
heimdall flash --repartition --pit I91001GB_4GB.pit --RECOVERY twrp-3.1.0-0-i9100.img --KERNEL boot.img --no-reboot

Danach das Telefon ausschalten, das USB-Kabel ausziehen, kurz die Batterie entfernen (ansonsten liess es sich bei mir nicht wieder booten), Batterie wieder einfügen.
Start des Telefons in den Recovery-Modus mittels VolUp-Home-Power
TWRP sollte nun starten. In TWRP den Menüpunkt "Wipe" -> "Advanced Wipe" -> "System" -> "Repair or Change File System" -> "Resize File System". Bei Erfolg auf "back" klicken und in der Übersicht auf "Change File System" -> "ext4". In der Übersicht wird die Dateisystemgrösse falsch angezeigt, evtl sogar als 0 Byte. Dies ignorieren. Nach erfolgter Reformatierung auf "back" klicken. In der Übersicht sollte jetzt korrekt 1007MB als Dateisystemgrösse angezeigt werden. Dasselbe Spiel für "Data" und "Internal Storage" wiederholen. Es können dabei viele rote Fehler angezeigt werden, dass Partitionen nicht eingebunden werden können. Dies kann (hier) ignoriert werden.
Nun das Telefon wieder ausschalten, Batterie raus und wieder rein, und erneut in den Recovery-Modus booten.
in TWRP erneut auf "Wipe" -> "Advanced Wipe" und einen gleichzeitigen Wipe von Dalvik, Cache, System, Data und Internal Storage durchführen. Wenn keine roten Fehlermeldungen erscheinen, kann der Flash-Vorgang beginnen. Ansonsten muss so lange mit der Reformatierung herumgespielt werden, bis es klappt.

Nun das USB-Kabel wieder anschliessen und mittels adb die zu installierenden zip-Dateien hochladen:
adb push lineage-14.1-*-nightly-i9100-signed.zip /sdcard0/
Wichtig! Der interne Speicher heisst /sdcard0/, nicht /sdcard/, wie in vielen Anleitungen behauptet!

In TWRP nun auf Install gehen und die zip-Dateien gemäss handelsüblicher Anleitungen flashen. That's it. Uff. Ja, ist kompliziert und viel unnötiger Aufwand.

Update: Ein Leser weist mich auf diese hervorragende Anleitung hin... für Windows :-P

Update: Ein weiterer Leser gibt noch zwei Tipps mit:
1. Wenn es mit dem Download der PIT-Datei nicht funktioniert, anderes USB-Kabel, bzw. anderen USB Port benutzen. Den Tipp gab's an verschiedenen Stellen und hat mir geholfen.

2. Ich habe es dann ums verrecken nicht geschafft, per "adb" etwas auf's Handy zu schieben. Ich habe es dann letztendlich auf eine Micro-SD karte kopiert, die ins Handy gesteckt und von dort installiert.

CyanogenMod aufs Galaxy S5

^ v M ><
Gestern hat das Unfairphone zwar nochmals ein Software-Update erhalten, das zwar an der Oberfläche kratzt (z.B. Bildschirmflackern behebt oder den sinnlosen Privacy Indicator angeblich endlich deaktivierbar macht), aber die richtigen Probleme (fehlende Konfigurationsmöglichkeiten, fehlender Privacy Guard, fehlende Unterstützung für Dateisysteme) natürlich nicht behebt. Aber das ist dennoch zu spät, denn heute hat mir der Pöstler Ersatz geliefert. Diesmal ein von im Vergleich zum Unfairphone nicht ganz so glücklichen Chinesen zusammengeklebtes Galaxy S5. Warum so ein altes Gerät? Nun, im Prinzip ist es dasselbe wie das Unfairphone, nur in irreparabel, leicht und ohne zweiten SIM-Slot. Ansonsten ist die Hardware ziemlich identisch. Und: Es gibt eine recht solide Unterstützung durch CyanogenMod!

Gemäss Anleitung ist die Installation so kinderleicht wie beim S3. Doch der Teufel liegt wie immer im Detail. Erst startet man das Gerät mittels VolDown-Home-Power im Download-Modus und installiert ein Recovery-Image:
heimdall flash --RECOVERY twrp-3.0.2-1-klte.img --no-reboot
Heimdall v1.4.0
[..]
ERROR: Failed to download PIT file!

Muh! Wäre ja zu schön, wenn es auch nur ein einziges Mal einfach wäre!

Also muss als erstes Heimdall auf die letzte Version von github aktualisiert werden. Wie bei all meinen technischen Einträgen wird Debian als Basis verwendet. Bevor nun irgend ein Troll meint, na klar, mit der Uralt-Version aus Debian ist das auch kein Wunder: den Spruch kann man sich hier sparen, da auch die letzte offiziell veröffentlichte Version von Heimdall (1.4.1) nicht ausreicht. Es muss zwingend die Version aus dem git-Repository sein!
aptitude install build-essential cmake libusb-1.0-0-dev qt5-default libgl1-mesa-glx libgl1-mesa-dev
git clone https://github.com/Benjamin-Dobell/Heimdall.git
cd Heimdall
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make
cd bin

Nun kann erneut gemäss Anleitung versucht werden zu flashen:
./heimdall flash --RECOVERY /path/to/twrp-3.0.2-1-klte.img --no-reboot

D.h. man startet die Recovery mittels VolUp-Home-Power. Als kleinen Umweg habe ich mittels des gestarteten Recovery erst ein Backup erstellt und dieses mit ADB auf den Desktop-Computer kopiert:
adb pull /sdcard/TWRP TWRP

Danach kann man aber wirklich gemäss Anleitung weitermachen, ein möglichst minimales Google-Apps-Paket installieren und sich an einem relativ schlanken, funktionalen Telefon mit verstärktem Schutz der Privatsphäre erfreuen.

Und das Unfairphone? Wird wegen Nichtgebrauchs verkauft. Und das S3? Wird zur Bastelplattform umfunktioniert.

Fairphone 2

^ v M ><
Schon vor meiner Rückkehr habe ich mir das Fairphone 2 bestellt und liefern lassen, damit ich endlich mein vier Jahre altes S3 ablösen kann, das trotz CyanogenMod und vielen Tricksereien beständig langsamer wird. Während es sich beim Fairphone zwar um eine gute Idee handelt, ist die Software so schlecht, dass ich es wohl bald ersetzen muss, wenn nicht schnellstmöglich Unterstützung durch beispielsweise CyanogenMod kommt.

Das Fairphone 2 besticht vor allem durch "faire" Produktion. Das heisst zum einen dass den Arbeitern in den Fertigungswerken Löhne bezahlt werden, die das Überleben ermöglichen. Zum anderen werden möglichst nur konfliktfrei abgebaute Rohstoffe eingesetzt, d.h. nicht solche, die brutale Diktatoren oder blutrünstige Rebellentruppen finanzieren. Und auch der Kunde soll nicht zu kurz kommen, das Gerät ist modular aufgebaut, leicht zu reparieren und soll über mehrere Jahre mit Ersatzteilen und Softwareupdates versorgt werden.

Die Hardware ist ziemlich einwandfrei. Zwar bezahlt man den Preis der guten Reparierbarkeit durch ein relativ dickes, schweres Gerät. Doch dafür ist es griffig und liegt ausgesprochen gut in der Hand. Bei Verwendung fühlt es sich schnell an, das Display ist scharf, flimmert aber leicht. Neben zwei vollwertigen MicroSIM-Slots gibt es einen zusätzlichen Slot für eine MicroSD-Karte, man muss sich also nicht wie bei den meisten DualSIM-Geräten zwischen zweiter SIM und mehr Datenspeicher entscheiden. Der Akku ist natürlich wechselbar, somit kann man das Gerät bei einem kompletten Freeze auf die harte Tour Neustarten statt mehrere Stunden zu warten, bis der Akku leer ist. Auch softwareseitig ist der erste Eindruck gut. Halbwegs aktuelles Android und kaum vorinstallierter unnützer Bloat. Doch damit hat es sich leider schon...

Die rückseitige Abdeckung lässt sich nur mit viel Gefummel entfernen und wieder aufsetzen. Fraglich, wie lange die hält, bevor sie ersetzt werden muss. Ausserdem sammelt sich sehr viel Staub in der Kante zwischen Abdeckung und Display.

Für die Kamera gibt es einen Hardware-Knopf auf der Seite. Durch Druck wird die Kamera-App gestartet... Leider nicht immer auf den ersten Druck :-( Ist die Kamera-App gestartet, funktioniert der Knopf als Auslöser. Das ist cool, somit kann man das Gerät als sehr schnell einsatzbereite Kamera verwenden. Sind weitere Fotogelegenheiten absehbar, kann der Bildschirm einfach über den Power-Knopf aus- und wieder eingeschaltet werden, die Kamera ist sofort wieder verfügbar. Leider mangelt es der Kamera-App an Funktionalität, ein Panorama-Modus wäre schon noch was... Ausserdem ist die Bildqualität eher mässig. Das alte S3 macht die deutlich besseren Fotos.

GPS funktioniert leider nur im High-Precision-Mode richtig. Dieser braucht aber mehr Strom und überträgt Standortdaten an Google. Im Device-Only-Mode dauert es mehrere Stunden, bis endlich die Position bestimmt werden kann. Das ist unbrauchbar.

SD-Karten werden nur erkannt, wenn sie mit dem uralten und nur mässig stabilen FAT32 formatiert wurden. Weder das Monopolisten-Dateisystem ExFAT noch freie Systeme wie ext4 sind unterstützt.

Bluetooth Pairing ist fast unmöglich, da paarungsbereite Geräte in aller Regel nicht gefunden werden.

Irgendwie hatte ich im Hinterkopf, dass eines der Ziele von Fairphone (erste Version) auch war, dass der Benutzer damit machen können soll, was er will. Das heisst auch, dass er relativ leicht und auf offiziell abgesegnetem Weg den root-Modus aktivieren kann. Nun, beim Fairphone 2 ist davon nicht viel vorhanden. Man muss modifizierte Images aus dubiosen Quellen flashen und auch sonst ein gewaltiges Gebastel vornehmen (siehe hier). Das ist ein schlechter Witz.

Schlimm wird es bei den Einstellmöglichkeiten von Android. Wenn man CyanogenMod mit seinen erschlagenden Möglichkeiten der Grob- und Feinkonfiguration kennt, fühlt man sich beim Fairphone wie ein Apple- oder Gnome-Jünger mit bescheuerten Voreinstellungen, die nicht änderbar sind. Zumindest den Wifi-Tethering-Button hätte ich schon gerne in den Quick-Toggles...

Aber so richtig schmerzhaft ist das Fehlen des Privacy Guard - wohl das Killerfeature von CyanogenMod. Damit lassen sich die Berechtigungen von Apps einschränken, ohne dass die Funktionalität der App ernsthaft beeinträchtigt wird. Somit kann man notorischen Privatsphäre-Killern beispielsweise den Zugriff auf das Adressbuch verweigern. Update: Stattdessen liefert Fairphone eine "Privacy Impact" Anzeige mit. Beim ersten Start einer App wird angezeigt, welchen Einfluss die App auf die Privatsphäre haben kann. Das ist total nervig und überflüssig, denn diese Information erhalte ich schon im Play-Store, wenn ich eine App installiere. Ausserdem kann ich mir nur anzeigen lassen, dass meine Privatsphäre verletzt wird, aktiv dagegen vorgehen wie beim Privacy Guard ist nicht möglich. Das Feature ist im Prinzip zwar deaktivierbar, doch wenn man das tut, funktionieren die meisten Apps nicht mehr richtig. Völlig gaga!

Doch all diese Problemchen sind ja nicht so tragisch, da man immerhin ein Gerät bekommt, das im Prinzip macht, wofür man es eigentlich erworben hat, oder? Nein! Tut es nicht! Denn es stürzt sehr häufig ab und bootet spontan neu. Oder das Netzwerk hängt sich auf, Internetzugriff wird nur durch einen manuellen Neustart wieder ermöglicht.

Und dann kommt der Todesstoss: Viele Apps funktionieren einfach nicht richtig! Eingabeformulare werden nicht ausgewertet oder falsch angezeigt. In CSipSimple können keine neuen Konten hinzugefügt werden, da der "Add Account" Button nicht auf Eingabe reagiert. In der Mobility App kann kein Standort ausgewählt und somit auch keine Reservation getätigt werden... Ich kann mir nicht vorstellen, dass dies generell an Android liegt - vermutlich ist die von Fairphone verwendete Grafikbibliothek einfach ein Bruch. Update: Die Probleme konnte ich beheben, indem ich das obsolete "Privacy Impact" wieder aktiviert habe, siehe hier.

Was also soll ich noch weiter mit diesem Schrottdings? Die produktive Nutzung ist mir kaum möglich, wenn das Gerät so unzuverlässig ist. Dem vielen Geld und den hohen Erwartungen wird das Gerät auf Anwenderseite so einfach nicht gerecht.

Mobiles Internet in der Schweiz

^ v M ><
Dass mobiles Prepaid Internet eines der grössten First World Problems darstellt, hatte ich anhand der Beispiele Deutschlands und Schwedens bereits gezeigt. In der Schweiz ist das selbstverständlich auch kein Bisschen anders. Man muss hier schliesslich mit der EU-Norm in autonomem Nachvollzug Schritt halten.

Teil eins: Wechsel vom Abo zu Prepaid, inklusive Nummernportierung.
Irgendwann hatte ich die Schnauze voll von überteuerten Abos, deren Inklusivleistungen ich eh nie benutze. Und nachdem sich der "Support" und Verkaufsabteilung meines Providers schon mehrfach eher negativ ausgezeichnet hatten (wenn ein Telekommunikationskonzern etwas nicht beherrscht, dann ist es Kommunikation), war klar, dass beim nächsten Ablauf des Abos gewechselt wird, und zwar auf Prepaid. Ewige Bindung ist nämlich sowas von 19tes Jahrhundert.

Nach ein Bisschen Recherche und Analyse des Schweizer Mobilfunkmarktes bin ich zum Schluss gekommen, dass das Angebot der Migros meinen Anforderungen am besten entspricht. Also gute zwei Monate vor der nächsten Verlängerung des Abos (so lange war die Kündigungsfrist) habe ich die erste Migros-Filiale aufgesucht und nach SIM-Karten gefragt. Gibt's hier nicht im Sortiment, ich muss in die nächste Filiale. Na gut, wieder aufs Velo gestiegen und weitergeradelt. Am zweiten Ort bin ich dann erstmal fündig geworden. Die Dame vom Kundendienst war schon drauf und dran die Karte für mich zu registrieren, als ich mich doch noch ganz unschuldig erkundige, ob das denn auch eine Micro-SIM sei. Nein, das gäbe es in dieser Filiale nicht, hier gibt es nur normalgrosse SIMs ohne Möglichkeit, eine Micros-SIM auszubrechen. Der Grund dafür sei, dass kaum jemand mit Smartphone eine Prepaid-Karte brauche. Tolle Wurst von Begründung. Stattdessen müsste ich ins Glattzentrum radeln.
Der Migros-Kundendienst im Glattzentrum verwies mich dann direkt zum M-Electronic, wo mir ein Verkäufer auch gleich eine passende Micro-SIM-Karte in die Hand drückte. Wohlgemerkt, eine Micro-SIM im Normal-SIM-Adapter. Aha. Kann man sowas nicht einfach als Standard in allen Filialen anbieten? Egal. Ich durfte nun eine geschlagene halbe Stunde warten, bis sich endlich der zuständige Sachbearbeiter dazu bequemte, mich meines Anliegens anzunehmen und die Karte für mich zu registrieren. Dabei wurde auch ein Termin für die Nummernportierung festgelegt, nämlich auf das Datum, an welchem mein bestehender Vertrag auslaufen wird.

Ich erwähnte dabei explizit, dass die Karte nun bis zur Ablauf des alten Abos ungenutzt bleiben würde. Dennoch fragte der Verkäufer, ob er die Option "my country" für 3 Franken pro Monat und die Datenoption für 5 Franken pro Monat gleich aktivieren sollte. Ob das denn möglich sei, dass die Optionen erst in zwei Monaten aktiv werden? Nein, natürlich nicht. Ich würde also 16 Franken darauf ausgeben, ohne es zu brauchen. Guter Mann, haben Sie mir überhaupt zugehört? Folglich wurde das Angebot von mir direkt abgelehnt.

Nun bin ich nach getaner Aktion, die nur 2 Stunden verschwendet hat und mich ca 15km auf dem Velo absolvieren liess (statt eingeplanter 1km Fahrt und 15 Minuten Aufwand...) also mit Micro-SIM und geplanter Nummernportierung nach Hause gekommen und habe 2 Monate gewartet. Kurz vor dem Portierungstermin erhalte ich ein SMS, dass die Portierung doch erst 3 Tage später stattfinden würde. Auch OK, bin ich halt 3 Tage nicht unter gewohnter Nummer erreichbar, da der Vertrag pünktlich auslaufen wird. Folglich habe ich am Tag des Ablaufs des alten Vertrags die alte SIM aus dem Telefon entfernt und die neue eingelegt. Da ich mobiles Internet benötigte, wurde auch gleich die Mobildatenoption inklusive automatischer Erneuerung alle 30 Tage aktiviert. Soweit so gut. Drei Tage später fand dann auch wie angekündigt die Nummernportierung erfolgreich statt. Ich war positiv überrascht und glücklich.

Einige Wochen später, an einem Tag intensiver Datennnutzung (mein Kabelanschluss war ausgefallen), war plötzlich das ganze Prepaid-Guthaben schlagartig aufgebraucht. Ein Blick ins Kundenportal zeigte, dass zwar die Mobildatenoption aktiviert wurde, aber dennoch nicht eingeschaltet war. Empört den Kundendienst angerufen und der Dame das Problem erklärt. Das hat erstmal ein Bisschen gedauert, da die Dame aus irgend einem Grund die ganze Zeit verstanden hatte, dass mein Telefon übermässig viel Datenverkehr erzeugt hätte ("das ist ein Computer, den müssen sie regelmässig neu starten." "wie bitte, was hab Ihr für ein Abrechnungssystem, dass den Neustart des Clients erfordert???"). Irgendwann hat sie dann mein Problem doch verstanden, und anscheinend war die Ursache, dass die Mobildatenoption zwar aktiviert wurde, aber durch die Nummernportierung wieder verloren ging. Folglich wurde mir ohne weitere Umstände das abgebuchte Guthaben wieder gutgeschrieben. All das.

Teil 2: Wechsel des Prepaid-Providers.
Leider war ich bei der Migros nun mit dem Kundendienst und dem Abrechnungsmodell hochzufrieden, nicht aber mit der Netzabdeckung. Bekanntlich nutzt Migros das beste Netz wos je hets gits, nämlich Swisscom. Deren Abdeckung ist auch schweizweit top, ausser in meiner Wohnung. Ja toll. Daheim kann ich kaum telefonieren, da der Gegenüber nicht zu verstehen ist.
Mit dem Netz des früheren Providers war ich zwar unterwegs nur mässig zufrieden, dafür war's zuhause immer top. Folglich wurde nach fast einem halben Jahr der Versuch gestartet, wieder zurückzuwechseln, jedoch keinesfalls direkt zu diesem Provider sondern einem seiner vielen MVNOs, Aldi Mobile in diesem Fall. Also rasch das Antragsformular auf der Webseite ausgefüllt und an die nächstgelegene Filiale senden lassen. Dann wieder aufs Velo gestiegen und hingefahren, um mir was wohl anzuhören? Richtig, keine Karten vorhanden. Mhm. OK. Also da erwarte ich eigentlich schon ein minimales Lagerverwaltungssystem, das mir online beim Antrag ausfüllen eine Warnung ausgeben kann, wenn die Karten in der gewünschen Filiale ausgegangen sind. aber hey, ich bin halt nur Informatiker und habe Ideen, wie man Computersysteme konkret einsetzen könnte (dabei weiss doch jeder: Computer sind nur dazu da, um auf Facebook den "Like"-Button anzuklicken). Zur Strafe habe ich die Filialleiterin also in die umliegenden Filialen anrufen lassen, ob denn irgendwo noch eine Karte vorhanden wäre. Das hat auch auf Anhieb geklappt, also weiter zur nächsten Filiale. Dort wurde mir auch tatsächlich die Karte ausgehändigt. Und zwar nicht nur irgend eine Karte, sondern eine Multiformatkarte zum passend ausbrechen: Normal, Mini, Micro. SO sollte das doch überall sein.

Tatsächlich ist dann auch die Nummernportierung zum von Anfang an festgelegten Termin erfolgt. Und bis jetzt bin ich zufrieden, zuhause kann ich wieder telefonieren.

Fortinet Rant

^ v M ><
Letztes Wochenende hatte ich das Vergnügen, eine Fortinet-Installation zu konfigurieren. Das sind nicht ganz günstige Firewalls, die sich einen professionellen Anstrich geben. Dann ist ja alles easy, oder? Bislang hatte ich noch keine Erfahrung mit den Geräten und somit zum ersten mal welche von nahem gesehen.
  • Alle paar Minuten (in einem zufälligen, willkürlichen Interval) wird man aus dem Webinterface automatisch ausgeloggt. Nicht gespeicherte Einstellungen gehen dabei verloren. Besonders toll, wenn das mitten in einem etwas längeren Assistenten passiert und man mehrfach von vorne anfangen darf.
  • Die Geräte wären ja echt ausführlich dokumentiert. Leider verweist Google konsequent auf veraltete Dokumentation unter docs-legacy.fortinet.com und die Links sind nicht einfach zu docs.fortinet.com abänderbar... SEO, anyone?
  • Die Doku besteht oft aus schönen Schritt-für-Schritt Anleitungen. Z.B. klicke auf den Menüpunkt "Router"... wait... das Gerät hier hat keinen Menüpunkt Routing... - oder klicke auf System -> Network -> Routing, dort auf New Item und fülle Feld X, Y, Z folgendermassen aus... nur dass der Assistent unter New Item die Felder X, Y und Z nicht bietet. aaaargh!
  • Die Geräte müssen beim Hersteller registriert werden, um z.B. Firmware-Updates zu erhalten. Auch nach scheinbar erfolgreicher Registrierung motzt das Gerät, dass die Registrierung nicht vollständig sei.
  • Auf einem der Geräte hat das dann auch dazu geführt, dass OTA-Firmware-Updates nicht möglich sind. Mann muss das Image also mühsam von Hand auf der Website des Herstellers suchen, anhand der kryptischen Dateibezeichnung das richtige erraten und ins Gerät hochladen.
  • Somit haben wir zwei Geräte, beide mit der gleichen Firmware-Version und der gleichen Grundkonfiguration. Nun lassen wir auf beiden den gleichen Assistenten laufen und tragen die gleichen Werte ein (logischerweise sind die IP-Adressen jeweils abweichend, aber ansonsten...). Das Ergebnis: Man erhält völlig andere Resultatansichten.
  • Es gibt eine USB-Konsole, worüber man die Geräte auch mit einer bequemen App für Desktop-Windows, OSX, Android und iOS konfigurieren und überwachen kann. Und ähem, hüstel, räusper... wo ist der Linux-Support?
Das sind alles Dummheiten, die ich bei einem Gerät, das 500 Franken aufwärts in der blanken Ausführung ohne Extras ausgesprochen ärgerlich finde. Das grundsätzlich kostenlose pfSense macht sowas nicht. Aber hey, wie sagt der Manager so schön: was nix kostet...

Handkehrum: Wenn die Dinger mal eingerichtet sind, scheinen sie ihren Zweck zu erfüllen. Immerhin. In der Grundkonfiguration scheinen sie auch standardmässig auf hohe Sicherheit eingstellt zu sein (d.h. es funktioniert zwar erstmal nichts, dafür funktioniert aber auch nichts, wovon man nichts weiss). Und mit dem Upgrade des OS auf Version 5.2 hat sich enorm viel an der Benutzerfreundlichkeit getan. Sonst wäre obige Liste noch viel länger.

Galaxy S3 mit CyanogenMod

^ v M ><
Kitkat auf S3
Nachdem mein tragbarer Computer mit eingeschränkter Telefoniefähigkeit und Staatsüberwachung immer langsamer geworden ist, habe ich vor ein paar Monaten endlich einen kompletten Reset durchgeführt und die originale Bloatware durch das relativ schlanke CyanogenMod (inkl Google Apps Paket) ersetzt. Das hat sich absolut gelohnt, das Gerät flitzt regelrecht und konnte dadurch seine Lebens- bzw Gebrauchsspanne nochmals deutlich verlängern.

In Benutzung ist hier ein Samsung Galaxy S3 i9300. Die Installation verlief problemlos und strikte gemäss Anleitung von einer Debian 7 (amd64) Maschine aus.

Vorteile:
  • Sehr flotte Bedienoberfläche
  • Brandaktuelles Android 4.4 Kitkat, welches ja gemäss Samsung nicht auf dem Gerät laufen sollte.
  • Monatliche (Sicherheits)Updates
  • Viel weniger installierter, unnützer Bloatmüll. Lediglich von Google ist noch Bloat drauf. Google Maps ist leider derzeit noch eine ziemliche Killerapp, ansonsten wäre ein komplett freies System mit z.B. f-droid als Appstore sicher denkbar. Mal auf Nokias Here-Maps warten :-)
  • Reduzierter Speicherverbrauch (was wohl auch zur höheren Geschwindigkeit beiträgt)
  • Im Allgemeinen eine längere Akkulaufzeit - die Laufzeit scheint mir aber etwas stärker zu schwanken als mit der Originalfirmware. Das ist aber eine subjektive Empfindung ohne wissenschaftliche Prüfung
  • Tiefere Latenz und Jitter im WLAN
  • Unterstützung für Linux-Dateisysteme wie ext4. Sehr schön bei USB-Datenträgern und grossen SD-Karten
Eins muss man Samsung allerdings lassen, grad die Samsung eigenen Apps sowie viele Touchwhiz-Funktionen waren ausgesprochen durchdacht, hilfreich und ergonomisch, so dass der Ersatz doch etwas Zeit und den Test diverser Apps benötigt hat:
  • Bildbetrachter: QuickPic - das hatte ich schon mit der Originalfirmware im Einsatz
  • Kamera: Focal Beta - leider friert die Kamera gelegentlich ein oder die App tut zwar so, als ob sie Bilder machen würde, tut dies aber nicht. In jedem Fall hilft nur ein kompletter Neustart des Geräts. Ob das an Focal oder CyanogenMod liegt, habe ich bislang nicht herausgefunden. Die aktuelle Version der CM-Standard-Fotografie-App macht unterdessen einen deutlich besseren Eindruck als vor ein paar Monaten, so dass ich hier womöglich wechseln werde.
  • Bildschirm aktiv halten, wenn in Benutzung: Smart Stay + Die App erfüllt an sich den Zweck, wofür sie installiert wurde, verursacht aber einen gewaltigen und nicht dokumentierten Datenverkehr. Meine "Zweckselfies" möchte ich allerdings nicht in den Händen der NSA oder des Entwicklers wissen, weshalb die App mittels Firewall ruhiggestellt werden sollte.
  • Anrufe Ruhigstellen durch Umdrehen: Flip - Silent
  • Spezielle SMS-Klingeltöne für einzelne Kontakte: Ringo
  • Ersatz für das SPlanner Kalenderwidget: SolCalendar
Natürlich ist auch mit CyanogenMod nicht alles Milch und Honig, in Sachen Hardwareunterstützung funktioniert z.B. die Bildausgabe auf externe Monitore per HDMI-Adapter nicht mehr. Das ist allerdings ein Feature, das ich eh kaum je gebraucht habe, somit kann ich damit leben. Etwas unzufrieden bin ich auch mit der SMS-App, welche leider nicht anzeigt, wie viele Zeichen schon getippt wurden. Auch schön wäre es, wenn die SMS-App gleich die Funktionalität von Ringo integrieren würde. Ärgerlich: Der Empfang von MMS scheint nicht zu funktionieren.

Moderne Velobeleuchtung

^ v M ><
Hier mal wieder ein typisches Beispiel von "Murphy trifft auf geplante Obsoleszenz": Pünktlich zum Herbstbeginn hat die Beleuchtung meines teuren Velos von einem Tag auf den anderen den Geist aufgegeben. Zu machen war da nichts mehr, also kurz in die Werkstatt gebracht. Meinung des Mechanikers nach erfolgreicher Reparatur: "Tja, da ist bei der vorderen Lampe die Glühbirne durchgebrannt. Daraufhin hat das LED-Rücklicht zu viel Strom abgekriegt und ist ebenfalls durchgeschmort." Die Rücklichteinheit musste komplett ersetzt werden. Bei meinem billigen Bahnhofsvelo hat es gereicht, die Glühbirne zu wechseln...

a) Ist es ja nicht so, dass man das Rücklicht durch eine austauschbare Sicherung oder einen Widerstand hätte schützen können...
b) Das Rücklicht war nota bene als "wartungsfrei" angepriesen. Merke: Wartungsfrei = nicht reparierbar.

OpenSource und Sicherheit

^ v M ><
Neulich hatte ich eine Diskussion über Open Source, Closed Source und Sicherheit. Mein Standpunkt war, dass ich mir sicher nicht proprietäre Software wie Dropbox oder Wuala installieren möchte. Natürlich ist Sicherheit hier mit ein Argument. Allerdings nicht nur die Sicherheit davor, dass kein Schadcode in der Software enthalten ist. Grad bei grösseren OpenSource-Projekten kann auch das nicht zu 100% ausgeschlossen werden. Grad die gewaltigen Codemengen, welche einige Firmen in Form von Treibern beitragen, kann kaum sinnvoll extern reviewed werden, da für ein komplettes Verständnis auch die Hardware-Spezifikation bekannt sein muss.

Es geht mir eher um eine andere Form von Sicherheit: Die Sicherheit, dass ich die Software auch morgen noch einsetzen kann. Denn proprietäre Software hat hier schon immer zu Problemen geführt. Entweder ist der Hersteller überhaupt nicht (mehr) willig, gewisse Plattformen zu unterstützen, oder er ist bei der Unterstützung neuer Plattformen einfach viel zu langsam. Letztendlich kann ich 90% allen Ärgers, den ich unter Linux je hatte, auf das 1% proprietäre Software schieben, den ich im Einsatz habe oder hatte.

Hier nur mal ein paar Beispiele aus meiner Erfahrung:

  • VMWare Server (vor vielen Jahren): Nach dem Kernelupdate (Bugfix-Release) lassen sich die Module ums verrecken nicht mehr kompilieren.

  • Adobe Flash Player: Erinnert sich noch wer an die Zeiten, als 64bit unter x86 noch neumodischer Schnickschnack war? Da hatte man die Wahl, entweder einen 32bit-Browser ins System reinzuwürgen, den semiproprietären nspluginswrapper zu verwenden, um das 32bit-Flashplugin unter 64bit-Browsern zu nutzen, oder aber eine der nicht funktionierenden freien Flash-Alternativen zu installieren. Oder einfach alternativ jahrelang auf Flash verzichten. Oh, Adobe hat ja neulich auch beschlossen, dass Flash für amd64 in Zukunft gar nicht mehr weiterentwickelt wird.

  • Skype: Bis es endlich die offiziellen "64bit"-Pakete gab, konnte man die Software nur unter kompletter Verhunzung der Paketverwaltung ins System würgen. Und dann noch dieses neumodische Audiotreiberzeugs namens ALSA, lass mal noch ein paar Jahre beim obsoleten OSS bleiben... aber hey, das grauenhafte PulsAudio-Zeugs, das ist so schlecht, das unterstützen wir sofort und exklusiv.

  • PowerVR Grafiktreiber (für die gute, alte KyroII): nett, dieses Kernel 2.6 Zeugs. Aber einen (instabilen) Treiber gibt's nur für Kernel 2.4. Wer's neuer will, der kann ja den VESA-Treiber nehmen. Doku für die freie Treiberentwicklung? bwahahaha, der war gut!

  • nVidia-Grafiktreiber: Trotz Linus' Stinkefinger ja die Vorzeigefirma unter den proprietären Treiberentwicklern: Oh, alte Hardware wird nicht mehr unterstützt. Ausser mit alten Treiberversionen, die keine neuen Kernel unterstützen. Oh, und dieses neumodische KMS-Zeugs mit älterer Hardware... nun, hübsche Konsole, so mit extremer Verzerrung und nicht mehr leserbaren Bootmeldungen...

  • AMD-Grafiktreiber: Lass mal den neusten AMD-Treiber auf einem 6 Jahre alten Kernel kompilieren... oh geht nicht, Kernel ist zu neu... Dazu hab ich mich ja schon mehrfach ausgelassen. Ganz davon abgesehen, dass die letzte Treiberversion für meine Hardware der 12.04 ist. Da kann ich nur hoffen, dass bis ich den Umstieg auf Debian 8 ins Auge fasse, der freie radeon-Treiber was taugt. Grad im Bereich Multimonitor.

  • Druckertreiber für non-Postscript Drucker: Funktionieren nur mit sehr exotischen Distributionen, haben komische Abhängigkeiten, und natürlich nur für 32bit x86 Systeme.

  • Wine und Windows-Spiele: Guter Witz. Ich hab da kaum je was zum laufen gekriegt. Auch wenn Wine der Meinung war, das Spiel hätte Platin-Unterstützung (d.h. perfekt)


Aber auch Hardware ist mühsam, sobald sie nicht über ausreichend freie Dokumentation verfügt:

  • Noch einmal AMD und nVidia: Die freien Treiber waren jahrelang gar nicht brauchbar, unterdessen geht wenigstens so langsam mal das grundlegende.

  • Windows-Only GDI Drucker: aaaaaaaaaargh!

  • Nokia-Telefone: Viel Spass beim Zugriff mit Gnokii. Vielleicht geht es. Wahrscheinlich nicht.

  • Pogoplug: Die Pro-Platine (auch im spottbilligen Pogoplug Pink verwendet) verwendet ein proprietäres SoC, in dessen Dokumentation nur ein freier Entwickler unter NDA Einsicht hat. Die Konsequenz: Das Gerät läuft nur mit Arch Linux ARM und uralt-Kernel 2.6.31. Und die wichtigsten Treiber für viele USB-Geräte fehlen darin.



A propos Pogoplug: Der sowie z.B. der Raspberry Pi benutzen die ARM-Architektur. Über die Verwendung von Skype, Flash oder Dropbox nachzudenken, ist absolut müssig.

Gnokii und Phonet

^ v M ><
Die neueren Versionen von Gnokii (0.6.30 und neuer) bieten eine neue Verbindungsoption zu s40-Telefonen: Den Phonet-Treiber. Leider ist die Dokumentation im Gnokii-Wiki dazu sehr spärlich und auch sonst weiss das Internet nicht viel dazu. Jedoch ist er relativ gut im Source-Tarball des Gnokii-Projekts beschrieben. Die Source brauchte ich sowieso, um das aktuelle Gnokii für mein Debian Squeeze zu kompilieren.

Die Idee hinter diesem Treiber ist, dass die Nokia-Telefone sich als USB-Modem einbinden lassen und eine virtuelle Netzwerkschnittstelle erstellt wird. Um diese ansprechen zu können, müsste gnokii im Prinzip mit root-Rechten ausgeführt werden. Man kann das jedoch umgehen. Einerseits muss man der gnokii-Applikation etwas mehr Capabilities zugestehen, andererseits muss man dafür sorgen, dass die Schnittstelle automatisch gestartet wird, wenn man das Telefon an den PC anschliesst:

Gnokii Capabilities setzen (als root):
setcap cap_sys_admin,cap_net_raw=+ep $(which gnokii)
setcap cap_sys_admin,cap_net_raw=+ep $(which xgnokii)

Um die virtuelle usbpn-Schnittstelle automatisch zu starten, werden unter Debian/Ubuntu folgende drei Zeilen in der /etc/network/interfaces benötigt:
allow-hotplug usbpn0
iface usbpn0 inet manual
up ifconfig usbpn0 up

Nun muss noch die gnokii-Konfigurationsdatei unter ~/.config/gnokii/config erstellt werden:
[global]
port = usbpn0
connection = phonet
model = series40
[connect_script]
TELEPHONE = 12345678
[disconnect_script]
[logging]
[flags]


Leider hat mich das nicht ernsthaft weiter gebracht. Das Billigst-Telefon (Nokia C1) lässt weiterhin keinen Zugriff auf die SMS-Inbox zu. Telefonbuch auslesen und bearbeiten sowie zumindest SMS versenden klappt sowohl über den AT- wie auch den Phonet-Treiber problemlos.

Nachtrag vom 24.10.: mit Debian Wheezy lässt sich zumindest die Ordnerliste anzeigen, jedoch wird jeder Ordner als leer angezeigt. Das Speichern von SMS funktioniert. SMS lesen scheint aber nach wie vor nicht zu klappen.

Mal wieder Software-RAID retten

^ v M ><
Diesmal handelt es sich um eine Disk aus einem dubiosen NAS. Anscheinend pappt das /dev/sda1 und /dev/sda2 zu einem RAID-1 zusammen. Dies wird wohl so gemacht, um das System elegant aktualisieren zu können. Jedenfalls, musste da mal Hand an die Systemdaten angelegt werden.

Nun, Standardübung, nehmen wir mdadm:
mdadm --assemble /dev/md/0 /dev/sdb1 /dev/sdb2
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: /dev/sdb1 has no superblock - assembly aborted

Wie? Kein Superblock? jaaa aber... parted ist da anderer Meinung:
parted /dev/sdb print
Model: WDC WD10 EARX-00N0YB0 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
3 15.7MB 528MB 513MB primary
1 528MB 2576MB 2048MB ext3 primary raid
2 2576MB 4624MB 2048MB ext3 primary raid
4 4624MB 1000GB 996GB ext4 primary

Was nun? Es handelt sich hierbei um ein Legacy-RAID ohne Superblock. Das setzt man nicht mit assemble sondern mit build zusammen:
mdadm --build /dev/md/0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdb2
mdadm: array /dev/md/0 built and started.

Nach der Resynchronisation erfolgt der erste mount-Versuch:
mount /dev/md/0 temp/
mount: unknown filesystem type 'linux_raid_member'

Na gut, erzwingen wir das Dateisystem:
mount /dev/md/0 temp/ -t ext3

Perfekt, alle Daten da :-)

Ubuntu 11.10 auf Rechnern mit EFI installieren

^ v M ><
Vor etwa einem Jahr habe ich mir einen neuen Server zusammengebaut. Eigentlich wollte ich damals eine CPU, welche drei Anforderungen erfüllt: x86 64bit, virtualisierungsfähig und sehr stromsparend. Leider konnte jede vorhandene CPU höchstens zwei der Kriterien erfüllen, insbesondere bei Intels Atom sind auch heute noch Punkt eins und zwei gegenseitig ausgeschlossen. Und das stromsparendste von AMD war der Athlon X2 240e, welchen ich zuletzt ausgewählt hatte. Monate später wurden dann die Atom-Konkurrenten von AMD veröffentlicht. Zwei Geräte für Tests mit Cluster- und sonstigen Basteleien mit einer derartigen Zacate-CPU habe ich mir nun besorgt, und zwar zwei ZBOXen von Zotac. Diese sind extrem günstig, komplett ausgestattet und befreit von Microsoftsteuern. Zum einen habe ich mir einen Nano gekauft, da dieser mit Fernbedienung geliefert wird, so dass ich diesen später zu einem Multimediarechner umfunktionieren kann. Und zum anderen einen ADO2, da dieser im Gegensatz zum Nano Platz für zwei Speichermodule bietet, so dass er auf 8GB RAM ausgebaut werden kann.

Bei so schönen Geräten muss natürlich erst mal die Hardware etwas genauer getestet werden, statt sie nur im Konsolenmodus zu betreiben. Dazu wollte ich ein paar Betriebssysteme installieren. Ubuntu Desktop 11.10 lässt sich fast problemlos installieren. Die Installation von Ubuntu Server 11.10, Debian 6 und CentOS 6.2 scheitert jedoch an einem Punkt: Beim Laden des Installers geht plötzlich die Tastatur verloren. Natürlich kann jedes Huhn Debian installieren, wenn genügend Körner auf der Tastatur liegen. Aber die Tastatur muss halt funktionieren. Interessanter- und glücklicherweise tritt das Problem beim Ubuntu Desktop nicht auf, so, dass sich dieser mässig bequem installieren lässt.

Das Problem mit den USB-Tastaturen lässt sich auch mit keiner BIOS bzw EFI-Konfiguration beheben. Ich habe alle USB-Einstellungen in jeder Kombination getestet, in letzter Verzweiflung sogar USB-Legacy deaktiviert. Dazu steht im BIOS-Setup, dass dadurch USB-Geräte nur noch in EFI-Applikationen zur Verfügung gestellt würden. Tja, das BIOS-Setup ist blöderweise keine EFI-Applikation, so dass ich nun ganz ohne Tastatur dastand und dies somit nicht mehr einfach korrigieren konnte. Daher musste ich erst mal das CMOS resetten, was zum Glück recht simpel ist. Man muss die Bodenplatte des Geräts entfernen, d.h. erst die vier Daumenschrauben lösen, welche auch als Standfüsse dienen, und dann an der eingekerbten Ecke den Fingernagel einsetzen und die Bodenplatte herausreissen. Nun hat man Zugriff auf alle relevanten Innereien, d.h. Festplatte, WLAN-Karte und RAM-Sockel, so dass man an dieser Stelle auch einfach ein RAM-Upgrade durchführen kann. Für den Reset muss einfach der gummierte, unbeschriftete Knopf zwischen WLAN- und Speichermodul ein paar Sekunden gedrückt werden. Eine bebilderte Anleitung dafür findet sich leicht, jedoch ist in dieser der Reset-Knopf nicht ersichtlich.

Die Geräte verfügen über kein BIOS sondern das modernere EFI. So schöne Vorteile (wie z.B. richtig grosse Platten ohne Workarounds) das bietet, so wüste Nachteile bei der Bootloader-Installation zieht es mit sich. Zur Installation von Ubuntu bin ich folgendermassen vorgegangen:
  • Zuerst habe ich von meinem bevorzugten Mirror das CD-Image für Ubuntu Live 64bit heruntergeladen und dieses mittels unetbootin auf einen bootbaren USB-Stick geschrieben. Diesen habe ich dann in den Zotac eingsteckt und das Gerät eingeschaltet.
  • Wenn die Startpiepser ertönen (ähnlicher Klang wie die Telefone in 24), ein paar mal auf DEL hämmern, um ins BIOS-Setup zu gelangen. Unter "Boot" muss die Startreihenfolge angepasst werden, so dass zuerst ab USB-Stick gestartet wird.
  • Jetzt erscheint der Bootloader und kann man entweder Ubuntu Live starten und dort das Setup aufrufen oder grad den Installer starten.
  • Die Festplatte muss unbedingt manuell partitioniert werden, denn EFI verlangt eine EFI-Partition. Der gparted-Verschnitt des Ubuntu-Installers legt gleich eine GPT-Partitionstabelle an, so dass als erste Partition eine FAT32-Partition von mindestens 200MB angelegt werden kann. Die Schwierigkeit besteht darin, dieser noch das Flag bios_grub gesetzt werden muss. Unter Ubuntu Live ist das kein Problem, da partitioniert man einfach vorher rasch mit gparted. Wichtig ist, dass man die ganze Platte löscht und eine neue Partitionstabelle vom Typ GPT anlegt.
    Im reinen Installer-Modus wechselt man mittels ctrl-alt-F1 in die Konsole, startet mittels
    $ sudo parted
    eine parted-Shell und setzt das Flag rasch per Kommando
    set 1 bios_grub on
    (tatsächlich habe ich im Arch-Wiki gelesen, dass man das Flag boot setzen muss, aber dann meckern später EFI und grub-installer). Zurück zum Installer gelangt man durch alt-F7.
  • Nun installiert man Ubuntu ganz normal fertig. Bloss neu starten sollte man noch nicht! Zuerst muss grub noch richtig installiert werden. Dazu wechselt man wieder in die Kommandozeile (bzw öffnet eine Shell in Ubuntu Live) und gibt folgende Befehle ein:
    $ sudo mount /dev/sda2 /mnt (/dev/sda2 muss ggf durch die korrekte Angabe für die Root-Partition ersetzt werden) und
    $ sudo grub-install --root-directory=/mnt /dev/sda (auch hier muss /dev/sda ggf durch die korrekte Angabe für die Platte, worauf Ubuntu installiert wurde, ersetzt werden).
  • Jetzt kann man neu starten und Ubuntu sollte fehlerfrei booten. Die EFI-Warnmeldungen bezüglich Bildschirmauflösung und "file not found" kann man ignorieren.


Die Leistung der Geräte ist nicht schlecht. Sogar Nexuiz läuft passabel wenn der proprietäre AMD-Treiber fglrx installiert wird, bei 1024x768 ist es mit 40-70FPS absolut spielbar. Bei höheren Auflösungen kommt die Grafikeinheit aber an den Anschlag.

Pseudo-Hardware-RAID retten

^ v M ><
Mal wieder dicke Punkte für Linux als Rettungssystem. Kollege bringt mir seinen defekten PC mit einem Intel Matrix RAID. Natürlich RAID-Level 0, d.h. ohne Netz und doppelten Boden. Man müsste die Daten von den Disk versuchen zu retten, weil Backup ist nicht...

Na gut. Die Kiste fährt nicht hoch sondern piepst nur. Ergo Platten raus, in meinen alten Schrott-PC rein und die nächstbeste Live-CD (in diesem Falle CloneZilla) gestartet und mal geschaut, was da Sache ist. mdadm sollte ab Version 3.0 in der Lage sein, solche Non-Linux-SoftRAID Verbünde wieder zusammenzusetzen. Tatsächlich klappt das auch. Verwirrend ist jedoch, dass die physischen Festplatten als /dev/sda1 und /dev/sda2 (was ja eigentlich Partitionen wären) eingebunden sind und das logische Laufwerk, d.h. der Verbund, als /dev/sda (was eigentlich die erste physische Platte sein sollte) verfügbar ist. Tja, wo sind nun die Partitionen? Diese finden sich unter /dev/dm-[0-9] und können von dort ganz normal gemountet werden. CloneZilla hat NTFS-3G schon dabei, somit ist auch der Zugriff auf die Windows-Partitionen kein Problem.

Kurz die Daten auf eine externe USB-Disk gesichert, und gut ist.

Debian Backports selbst gemacht

^ v M ><
Ab und zu braucht oder möchte man mal unter Debian Stable ein neueres Programm installieren. Oft findet sich dies in Unstable oder gar Testing, aber leider gibt's dann oft keinen Backport. Das ist aber kein Problem. Meine Backports bau ich anhand dieser Anleitung, mit einigen Ergänzungen. Hier erläutere ich dies am Beispiel des Messengers Pidgin:

Als erstes werden mir root-Rechten die benötigten Abhängigkeiten für den Bau des Pakets installiert:
# aptitude build-dep pidgin


Bis auf weiteres können alle weiteren Schritte als normaler User ausgeführt werden. Als nächstes wird die Source und die Debian-Modifikation von packages.debian.org heruntergeladen und in ein eigens für den Build erstelltes Verzeichnis kopiert:
$ mkdir pidgin
$ cd pidgin
$ wget http://ftp.de.debian.org/debian/pool/main/p/pidgin/pidgin_2.9.0.orig.tar.bz2
$ wget http://ftp.de.debian.org/debian/pool/main/p/pidgin/pidgin_2.9.0-3.debian.tar.gz


Nun wird entpackt:
$ tar -jxf pidgin_2.9.0.orig.tar.bz2
$ cd pidgin-2.9.0
$ tar -zxf ../pidgin_2.9.0-3.debian.tar.gz


Der nächste Schritt ist etwas fummelig. Allenfalls müssen Abhängigkeiten angepasst werden, weil das Debian-Skript eine neuere Version einer Abhängigkeit fordert als nötig und/oder für Debian Stable verfügbar ist. Fehlerhafte Abhängigkeiten können einfach bestimmt werden, indem man den nächsten Schritt ausführt und den Kompiliervorgang versucht zu starten. Zur Bereinigung von Abhängigkeiten mit unnötig hoher Version muss die Datei debian/control bearbeitet werden.
Einige benötigte Abhängigkeiten mit höherer Version lassen sich aus den Backports installieren, dies klappt mittels aptitude -t squeeze-backports install myrequireddependency (vorausgesetzt, das backports-Repository ist konfiguriert). Für einige ganz fiese Abhängigkeiten kann es nötig sein, dass man davon selbst ein Update gemäss dieser Anleitung erstellen und installieren muss.

Sind alle Probleme behoben, kann man nun den Compiler anwerfen lassen:
$ dpkg-buildpackage -rfakeroot -uc -b


Wenn dies erfolgreich war, erhält man ein installationsbereites .deb-Paket. Für die Installation sind natürlich wieder root-Rechte erforderdlich:
$ cd ..
$ su
# dpkg -i *.deb

AMD vs Linux... na endlich!

^ v M ><
Kaum zu glauben: Aber mit Treiberversion 11.7 steht nun endlich ein AMD-Treiber zur Verfügung, welcher sich ohne rumgepatche und langen händischen Kompilierorgien out-of-the-box auf Kernel 2.6.38 aus den Debian Backports installieren lässt. Wird ja auch so langsam Zeit, jetzt wo schon bald Kernel 3.1 vor der Türe steht...

Atomkraftwerke im Stand-By-Modus?

^ v M ><
Und ich dachte eigentlich, dass man den Stand-By-Modus bei Stromverbrauchern* vermeiden und stattdessen ganz abschalten sollte. Tja, wieder was gelernt. Danke, Politiker!

*) was mit AKWs passiert, wenn man ihre Stromzufuhr abstellt, hat man ja in Japan mitbekommen...