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.
Archiv der Kategorie: software
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.
Passwörter im Klartext gespeichert? m(
Jeder halbwegs vernünftige Netzbürger, speziell der, der für die Sicherheit von Systemen oder Webseiten oder Datenbanken verantwortlich ist, sollte eigentlich die Sony-Einbrüche kennen oder zumindest davon gehört haben. Stellt sich raus, dass Yahoo (Voices) mit der gerade veröffentlichten Liste von Passwörtern genau den gleichen Stumpfsinn gemacht hat und diese nicht als Hashes abgespeichert hat, sondern offensichtlich im Klartext. Da es bisher danach aussieht, dass die Passwörter schon 2009 erbeutet wurden, kann man dieses Wissen Yahoo nur begrenzt zum Vorwurf machen (obwohl solche Einbrüche natürlich schon vorher existierten).
Die Statistik (boingboing) zu den aktuell veröffentlichten Passwörtern gleicht größtenteils den bereits bekannten Fällen: der Großteil der Passwörter ist nicht sicher und kann, wenn er denn nicht im Klartext gespeichert worden wäre, ohne weitere Schutzmaßnahmen sehr schnell erraten werden.
In einem interessanten Vergleich hat hier mal jemand die offengelegten Passwörter von Sony und Yahoo gegenübergestellt. Fast 2/3 sind exakt die gleichen wie beim Sony-Einbruch, also auch mit dem gleichen Nutzernamen.
Randnotiz: ich hab vor einigen Tagen einen Dienst nach 1-monatiger Nutzung gekündigt, der mir bei der Anmeldung 2 Mails zur Bestätigung gesendet hatte, in der 2. standen meine login-Daten und mein Passwort im Klartext. Das war auch einer der Gründe, die ich bei der Kündigung anführte.
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)
Noch eine RAW-Software
Oh fein. Dank phoronix probier ich gerade eine weitere Software für die Bildbearbeitung (mit Schwerpunkt RAW) unter Linux aus. Ja, digikam ist brauchbar und ein sehr umfassendes Programm, aber langsam (auf meiner vermutlich etwas zu alten hardware) und bloat-ig. Wenn also was Neues auftaucht, schau ich von Neugier getrieben und auch etwas mit dem Wunsch nach mehr speed drauf.
darktable ist hier imo ein Wortspiel aus dark room und light table, beides Modi, in welchen das Programm zu nutzen ist, wobei darkroom für die Einzelbild-Anzeige und lighttable für ein Set von Bildern steht. Und es erscheint mir nach den ersten Minuten tatsächlich schneller bei grundlegenden Aktionen, auch wenn es sicherlich nicht hexen kann.
Die Oberfläche sieht auf den ersten Blick sehr aufgeräumt, gar spartanisch aus. Das Konzept macht auf jeden Fall einen interessanten Eindruck. Vor Tastaturbenutzung sollte man keine Angst haben, da diese für einen schnellen Arbeitsablauf essentiell ist und hier auch umgesetzt wurde. Die andernorts obligatorische Menüzeile sucht man hier vergebens. Die Begründung dafür findet sich in den GuiGuidelines im darktable-wiki.
Nach den ersten Minuten will ich mich noch nicht festlegen, ob das Programm ein Ersatz oder eine Ergänzung wird. Zwei Systeme rund um Bearbeitung und Verwaltung kann man sicherlich machen, bringen aber zusätzliche Probleme. darktable hat mit seiner Unabhängigkeit von einer Desktop-Umgebung und der Möglichkeit für tethered shooting, der Unterstützung des neusten Krams wie zB. Beschleunigung mittels OpenCL, einige starke Argumente.