Voraussehbar NIC Name

ich dachte mir schon, dass mir dieser Mumpitz irgendwann nochmal in die Quere kommt. Wer ist denn bitte auf die Ideee gekommen, dass predictable interface names auch auf Desktops eine tolle Sache sind? Herzlichen Dank an dieser Stelle an diejenige Person, die mir einen Nachmittag versaut hat, weil meine Kiste nach dem Starten kein Netz hatte und die Konsole vom Jammer-systemd blockiert wurde, nur weil ich mich erdreistet hatte ein BIOS-Update vorzunehmen. Für euch zu mitmeißeln: nein, das ist ein Desktop-Rechner mit nur einer einzigen Netzwerkkarte und die wird immer den gleiche Namen haben, ohne eure Mithilfe.

Gegen den Trend? *Pfff*

So. Nach recht wenig Bedenkzeit musste jetzt ein neuer mobiler Rechner her. Und zwar etwas mit realer Tastatur und der Möglichkeit, da ein anständiges Betriebssystem™ zu installieren. D.h. Tablets zB. fielen schon mal raus. Sonstige Anforderungen: Gewicht max. 1.5 kg, Akkulaufzeit bei moderater Nutzung wenigstens 3-5h, neben Wifi muss LAN dran sein und Rechenleistung deutlich über Atom-Niveau.

Da eigentlich in diesen Breiten der Nerd-Welt nur noch 3 dominierende Systeme (win[8], osx, chrome) auf Neugeräten zu finden sind, war die Option gutes gebrauchtes Demo- oder Vorführgerät nicht so abwegig. Doch es gibt immer noch einige, wenige Angebote mit den gewünschten Features. So zum Beispiel das kleine TravelMate B133-M, das von Haus aus mit einem vorinstallierten Linpus-Linux im Minimalumfang kommt. Also nicht mal ein grafische Oberfläche startet. Vielleicht wär das ja nachzuinstallieren, aber der Screenshot im Wikipedia-Artikel schreckt eigentlich schon ab.

schleppiAlso nicht länger gewartet, sondern bestellt. Es kam auch sehr fix und brachte wenige Überraschungen mit sich. Zum ominösen Ausdruck „Linux (boot only)“ im Angebot hatte sich der Support schon geäußert. Den ekelhaften Glanzlackrahmen um’s Display hatte ich leider nicht bemerkt, aber da werden sich im Lauf der Zeit schon genug passende Aufkleber finden. Die Tastatur verdient zwar den Namen, ist aber ergonomisch gesehen eine Enttäuschung. Auch überraschend: keine LED-Anzeigen für Wifi/Bluetooth oder CapsLock. Leider macht auch die Betriebsleuchte nicht viel mehr als vor-sich-hin-leuchten. Ein Doppelnutzung zum Beispiel als Anzeige für HD-Aktivität wäre wohl zu clever.

Ohne lange zu fackeln wurde ein mit Debian wheezy bestückter Stick eingestöpselt und mit der Installation begonnen. Nach ca. 3 Stunden lief das System und ein Großteil der verbauten Hardware lief ohne weitere Eingriffe sofort. Sogar die Fn-Tasten machten bis auf eine Funktion (Helligkeitssteuerung) das, was auf sie aufgedruckt ist. Hand auflegen war für die Steuerung der Displayhelligkeit (Kernel-Parameter ergänzen: acpi_backlight=vendor)und beim Touchpad nötig. Obwohl Letzteres an sich funktionierte, fehlte mir die rechte „Maustaste“ (Schalter unter dem Pad), was aber mehr am installierten Gnome 3 liegt. Einmal richtig konfiguriert, lassen sich auch Multitouch-Gesten nutzen und somit auch der Zwei-Finger-Tapp für’s Kontextmenü. Den SD-Karten-Leser hab ich allerdings bis jetzt noch nicht zur Mitarbeit überreden können.

Mittlerweile hab ich mit diesem gnome (vorerst) arrangiert und es soweit auf meine Bedürfnisse angepasst, dass es keine großen Schmerzen mehr verursacht. Interessanterweise gefällt mir sehr gut, dass die Farbverwaltung aus dem Stehgreif funktioniert und der Display auch sofort mit einem Colorimeter kalibriert werden konnte. Jetzt passen zwar die Farben (vorher: stark bläulich, daher sehr hell wirkend), aber dafür sieht die Ausleuchtung nicht sonderlich erfreulich aus.

Der kleine Rechenknecht übersetzt einen neuen Kernel (hier: 3.9.1) mit einer angepassten Konfiguration in ca. 12 min, das reicht aus. Am anderen Ende der Leistungsanforderung sagt powertop: reichlich 7 Watt bei Batteriebetrieb und 800 MHz, Laufzeitschätzung: 500 min.

Weitere Details oder Methoden (siehe SD-Leser) folgen.

Konsequenz der Bequemlichkeit

Oh oh, dachte ich heut Nachmittag, als ich versuchte, meinen Passwort-Safe zu öffnen. Den hatte ich seit einiger Zeit nicht mehr angefasst, genauer gesagt, seit der Umstellung des Systems von 32 auf 64 Bit. Eigentlich ist das – im theoretischen Idealfall – kein Problem, weil das System trotz breiterer Architektur bei Vorhandensein der 32Bit-Bibliotheken auch 32Bit-Programme ausführen kann. Die hatte ich vermutlich bis vor kurzem auch noch auf der Platte und es wäre mir wahrscheinlich gar nicht aufgefallen, vielleicht etwas Gejammer wegen fehlender Bibliotheken, aber es wäre noch möglich gewesen. Durch einen unsachgemäßen Eingriff hab ich aber den Paketmanager vor ein paar Wochen dazu gezwungen, aus dem eigentlich inkonsistenten Zustand (Unmengen an alten 32Bit-Paketen waren noch auf der Platte, aber das Paketsystem sah sie nicht mehr) wieder einen konsistenten Zustand zu machen. Das hatte das Entfernen von reichlich 1200 Paketen zur Folge, u.a. auch das für diesen Artikel ursächliche. Leider geht Nachinstallieren für x86_64 auch nicht mehr, da das Paket gar nicht mehr im Debian-Paketsystem geführt wird. Da ist guter Rat teuer.

Glücklicherweise finden sich im Netz noch die originalen Quellen (2010 das letzte Lebenszeichen) auf github. Und in meiner nicht-mehr-ganz-so-jugendlichen Naivität dachte ich natürlich, dass ein Übersetzen der Quellen mit dem aktuellen System kein Problem sein sollte und mich zum Öffnen des Safes befähigen müsste. (Der geneigte Leser mag sich die Fortsetzung dieses Gedankengangs kurz selbst ausmalen.) Es ging natürlich nicht. Obwohl das Binärformat des Safes in einer Definition festgeschrieben ist und eigentlich unabhängig von der verwendeten Architektur sein müsste, ließ sich die Datei nicht öffnen, schlimmer noch, das Programm verstarb geräuschvoll mit SEGFAULT bei jedem Versuch.

Jetzt bleiben noch ein paar Möglichkeiten, bevor ich mir den Kopf zerbrechen muss, was an wichtigen Daten da drin stand, die ich unter Umständen nicht wieder zurück bekomme. Ein Übersetzen mit debug-Informationen, um überhaupt erstmal die Ursache des Fehlers beim Öffnen zu finden. Das wird nicht leicht, da make mit gesetztem DEBUG eine metrische Tonne an Fehlermeldungen ausspuckt. Eine andere Möglichkeit wäre ein cross compile für 32 Bit, was vermutlich am Alter der beteiligten Bibliotheken scheitern wird. Und der letzte Akt ist das Aufsetzen einer 32Bit-VM und das Übersetzen des Programms da drin. Auch nicht unbedingt ein Garant für guten Schlaf. Die nächsten Tage werden es zeigen.

Der Stumpfsinn mit der Haftung

Man kann es eigentlich nicht oft genug und laut genug wiederholen: wann immer eine Diskussion zu den angeblichen Nachteilen von Open Source Software stattfindet, wird das Argument gebracht, dass die Haftungsfrage nicht oder nur schwer beantwortbar ist – das ist natürlich ziemlicher Blödsinn. Wenn es ein gemeinsames Detail gibt, welches proprietäre und offene Software verbindet – wenn sie hauptsächlich dem angelsächsischen Sprachraum entstammt – ist es die Ablehnung jeglicher Haftung. Sowohl in den Lizenzverträgen gängiger proprietärer Software als auch in den Nutzungsbestimmungen vieler FOSS-Projekte steht klar drin, dass der Hersteller oder die Community keine Haftung übernehmen.

Natürlich kann der Einspruch erhoben werden, dass eine Firma vor einem Gericht zu Verantwortung gezogen werden kann, was bei einer lose erscheinenden Gruppierung von Programmierern und Mitarbeitern eines FOSS-Projektes nicht so einfach erscheint. Allerdings ist das kein Argument für die ursprüngliche Diskussion und insofern ist die Haftungsfrage als Hinderungsgrund für den Einsatz quelloffener Software immer eine Nebelkerze.

Juristen sehen das vielleicht als zu stark vereinfachend an. Mag sein, ändert trotzdem nix am schlechten Charakter solcher Argumente.

 

 

 

 

Problems with BFS 0.422

The latest version of BFS has a strange effect on my box here. The first time i got aware of it was when i ran apt-get update (debian way of sync’ing package lists) which worked normal up to the point of reading local package lists from disk. It was horribly slow. Normally, it needs ~5 seconds to complete, this time it ran for several minutes but I/O-utilization was 100% (using top/iotop). And the sound of the disk was different too.

A more repeatable test: dd if=/dev/zero of=dd_disk_test bs=123K count=5000 needed 112 seconds which sums up to 5.6 MB/s – way to slow. The same test with a different disk, a 128 GB SSD had twice the rate, 9.7 MB/s, but way to slow too. No other sign of wrong-doing, everything else was fine. Changing the kernel did the trick. Same Version, linux-3.4.1, but without BFS runs fine: same test completed in 5 seconds (124 MB/s). At the moment i have no glue how to dig into the problem to find the root of it.

/edit: nope, it’s back. After a certain amount of uptime i saw the problem with a vanilla kernel too. (10.6.12)

Photobearbeitung und -verwaltung für Professionelle

Ich hatte vor einiger Zeit schon mal drüber nachgedacht, ob ich mir nicht eine Lizenz für Bibble Pro zulege, weil die Testversion einen recht guten Eindruck hinterlassen hatte. Speziell die Verarbeitungsgeschwindigkeit war klasse aufgrund des Multithreadings, für mich mit auf der höchsten Prioritätsstufe. Allerdings waren da hinter den Kulissen noch einige Fehler zu finden und letztlich war mir das zu viel Geld für das knausrige Interface.

Etwas Erstaunen hat dann die Nachricht  bei mir hervor gerufen, dass Corel die Firma Bibble gekauft hat und seitdem die Software unter dem neuen Namen AfterShot Pro vertickt. Corel gibt’s tatsächlich noch? … Na jedenfalls soll die mit digikam vergleichbare Software auch weiterhin für Linux angeboten werden und unterstützt zumindest auf dem Papier 32 und 64 Bit.