13.04.2017

Die Cyberwehr - Leserbrief

In letzter Zeit wird die Vorsilbe "cyber" immer wieder ge- und mißbraucht. Niemand weiß so richtig, was damit ausgedrückt werden soll. Erfunden hat diesen Begriff William Gibson für seine Bücher über virtuelle Realitäten und hat damit Kinofilme wie "Matrix" inspiriert. Echte Programmierer(tm) machen sich seit langem über diesen Begriff lustig und verwenden ihn mittlerweile massiv satirisch überzeichnet selbst für reale Ereignisse ("hacker terror cyber cyber") oder als Hinweis auf überschießende politische oder mediale Berichterstattung.

In letzter Zeit wird dieser Begriff immer mehr verwendet, wenn der Autor keine Ahnung von Computern hat, aber trotzdem modern wirken will. Leider schließt sich die Wetterauer Zeitung diesem Trend an und veröffentlicht Glossen über die geplante Bundeswehrtruppe zur digitalen Kampfführung und Abwehr, die etwas spöttisch als "Cyberwehr" bezeichnet wird. Ich habe meine Zweifel, dass daraus irgend etwas werden wird.
Leserbrief zu Glossen Hr. Junginger, 06.04.17, und Fr. Spiller, 12.04.17

Fr. Spiller macht sich lustig und packt alle Vorurteile über Computerspezialisten aus, die ihr einfallen. Leider ist kein einziges davon witzig oder auch nur ansatzweise in der Lage, das Thema zu streifen. Im Gegenteil sorgt Fr. Spiller mit ihren hämischen Bemerkungen dafür, dass sich die Vorurteile über "Nerds" weiter verfestigen. Hr. Junginger zitiert ominöse "Experten", die angeblich seit Jahren vor den Gefahren des Internets warnen. Leider liefert er keinerlei Belege, welche Experten welche Gefahren befürchten.

"Hacker dringen in Atomkraftwerk ein", befürchtet Hr. Junginger. Und dagegen soll uns die neue Cybertruppe der Bundeswehr schützen? Wie wäre es, wenn man ganz einfach die kritische Infrastruktur nicht ans öffentliche Internet anschließt? Oder wenn man es doch tut – warum auch immer – dann wenigstens richtig Geld für Fachleute in die Hand nimmt, um eine solche Verbindung abzusichern? Dazu braucht es keine Bundeswehr - das BSI hat eigentlich schon genug Empfehlungen auf Lager. Man sollte nur anfangen, sie fachkundig umzusetzen.

Die "Gefahren" im Internet entstehen nach meiner Meinung gerade und hauptsächlich durch die "nation-grade attackers", also die staatlich gut finanzierten Hacker der Geheimdienste und Behörden, die den Markt für unveröffentlichte Sicherheitslücken befeuern, indem sie Umsummen zahlen, die Hersteller aber nicht informieren. Dadurch wird die Zivilgesellschaft als Ganzes unsicherer. Das FBI zog kürzlich sogar eine Anklage gegen einen mutmaßlichen Pädophilen zurück, um nicht vor Gericht das Abhörwerkzeug offenlegen zu müssen. An diesem Beispiel sieht man besonders krass, dass es definitiv nicht um den Schutz der Gesellschaft vor Verbrechern und Hackern geht, sondern um Macht und darum, sie nicht aufzugeben.

Aber hauptsächlich das Geld ist das Problem. Die Industrie zahlt vernünftige Gehälter für gute Leute. Die "Cyberwehr" bezahlt vermutlich stur nach Bundesbesoldungsordnung, für einen Leutnant also A9 mit ca. 2.800 € brutto pro Monat. Das ist vergleichbar mit einem Lehrer. Das Anfangsgehalt in der Industrie für einen Informatiker direkt nach Ende des Studiums liegt bei ca. 4.000 € mit extrem guten Entwicklungsmöglichkeiten.

Seit kurzem wird es auch immer moderner, Alltagsgegenstände mit Internetanschluss zu versehen, vom Kühlschrank über Stromzähler bis hin zu Fernsehern, Autos und Vibratoren (kein Scherz!). Diese Geräte werden unter massivem Kostendruck produziert und der Hersteller kümmert sich nach der Markteinführung nicht mehr um Software-Updates. Hier ist die Gesetzgebung gefragt, den Firmen eine Pflicht zu Updates oder ein einprogrammiertes Verfallsdatum aufzugeben, um unsichere Produkte zu verhindern. Die Selbstregulierung funktioniert nicht. Die meisten Konsumenten wollen das billigste Gerät kaufen und verstehen die Notwendigkeit von Software-Updates nicht. Die Hersteller in China kümmern sich nicht um Sicherheitslücken, weil sie keinerlei Nachteile zu befürchten haben oder diese Lücken sogar gewollt oder geduldet werden. Wenn hier der Gesetzgeber nicht eingreift, wird das Desaster noch eine Größenordnung schlimmer als bei den billigen Android-Smartphones ohne Updatemöglichkeit.

Ursprünglich wurde das Internet dezentral entworfen, um einen Atomkrieg zu überstehen. Aber jedes Netz hat Kapazitätsgrenzen, und wenn jetzt mit Macht Milliarden Geräte der Kategorie "Internet of Things" auf den Markt kommen, wird das Internet demnächst von intelligenten Toastern zerstört, die jemand gehackt hat. Aber bei alldem hilft uns keine unterbezahlte Cyberwehr, die freitags um 14.00 Uhr nach Hause geht. Hier hilft nur ein Paradigmenwechsel in der gesamten Software-Industrie hin zum "Security by Design" mit rigorosen Tests und Zulassungsvorschriften inklusive Zwang zur Update-Garantie. Und da muss die Gesetzgebung schneller werden. Eine unterbezahlte Cyberwehr ist nicht die Lösung, sondern nur zielloses Herumdoktern an den Symptomen.

07.04.2017

Selbstmodifizierender Code

Heute zeige ich mal ein kleines Stück Skriptcode, das eine eigentlich verpönte Programmiertechnik zeigt, nämlich "selbstmodifizierenden Code". Das bedeutet, dass zur Laufzeit erst Programmcode erzeugt und dann direkt ausgeführt wird.

Am besten funktioniert das natürlich in Skriptsprachen, und es muss auch eine Möglichkeit geben, das ausführende Organ, also den Skript-Interpreter, darauf hinzuweisen, dass es neuen Code gibt.

Das Beispiel, das ich vorstellen möchte, ist eher harmlos. Generell sollte man aber bedenken, dass es gefährlich sein kann, wenn man einem Programm die Möglichkeit gibt, sich selbst zu verändern. Diese Technik darf man also insbesondere nicht verwenden, wenn man keine oder wenig Kontrolle über die "Zulieferung" hat, also z.B. bloß nicht in Software für's Web wie CGI-Skripte oder so was.

Mein Artikel beschreibt die Abfrage des Tintenstands eines Druckers. Auf dem Display bzw. im Webinterface zeigt der Drucker sehr schön an, zu wieviel Prozent die Patronen gefüllt sind. Es gibt noch eine weitere Technik: nämlich die Abfrage mit SNMP ("simple network management protocol"). SNMP an sich ist erst mal ziemlich dämlich: es beschreibt nur, wie Geräte Informationen liefern. Welcher Art die gelieferten Informationen sind, kann aber total unterschiedlich sein. SNMP wird von Routern, Switches, Servern, PCs, Druckern, Firewalls, NAS, SAN, Monitoring und vielen anderen Geräten gesprochen, und jedes davon hat ein anderes Spektrum an Parametern.

Deshalb gibt es zu Geräten der diversen Kategorien Beschreibungsdateien, in denen niedergelegt ist, welche Daten ein Gerät liefern kann. Diese Beschreibungen werden gesammelt in MIBs ("Management Information Base"). Es gibt standardisierte MIBs, und manchmal liefern Hersteller, wenn sie nett sind, auch eigene MIBs mit den spezifischen Erweiterungen, z.B. für ein bestimmtes Druckermodell. MIBs werden in einer syntaktisch festgelegten Grammatik geschrieben, in ASN.1.

Zur Abfrage eines Geräts benötigt man ein Hilfsprogramm, das SNMP spricht und eine Netzwerkverbindung zum Ziel aufbauen kann. Für Linux installiert man dazu "net-snmp", das es als fertiges Paket (sourceforge binaries download) oder zum Selbstbauen gibt.

Für die Abfrage muss man ein paar merkwürdige, sehr lange Zahlen wissen. Manchmal kann es trickreich sein, genau herauszufinden, was man braucht. Man kann die MIB-Datei lesen (braucht etwas Übung) oder man versucht es mit einer Suchmaschine (so wie ich, wenn ich faul bin).

Weiter unten stelle ich das komplette Skript vor, aber ich zerlege einzelne Zeilen in ihre Einzelteile und zeige, wie sie funktionieren.

Das Skript zum Abfragen der Tintenstände verwendet sogar zwei verschiedene Techniken aus der Kategorie "selbstmodifizierender Code". Zum Einen verwende ich den "eval"-Befehl der Linux-Shell (die /bin/sh ist bei mir bash), und zum anderen baue ich ein winziges Perl-Skript mit Inhalten zusammen, die ich mir gerade vorher erst im Shellskript aus einem snmp-Befehl zusammengesammelt habe.

Die eigentliche Abfrage des Tintenstands funktioniert so wie im folgenden Schnipsel gezeigt. Zuerst der Befehl, dann die Ergebnisse mit meinem speziellen Drucker. Der Befehl "snmpwalk" liefert mir mehrere Ergebnisse mit einer Abfrage; dazu "wandert" der Befehl durch alle Unter-Ergebnisse der angegebenen Nummer 1.3.6.1.2.1.43.11.1.1.6.0, also .6.0.1, .6.0.2 usw.
Diese spezielle Abfrage liefert mir die Zuordnung, welche Nummer zu welcher Farbpatrone gehört.

# snmpwalk -v1 -c public 192.168.100.173 1.3.6.1.2.1.43.11.1.1.6.0
SNMPv2-SMI::mib-2.43.11.1.1.6.0.1 = STRING: "black ink"
SNMPv2-SMI::mib-2.43.11.1.1.6.0.2 = STRING: "yellow ink"
SNMPv2-SMI::mib-2.43.11.1.1.6.0.3 = STRING: "cyan ink"
SNMPv2-SMI::mib-2.43.11.1.1.6.0.4 = STRING: "magenta ink"

Als nächstes beschaffe ich mir die Tintenstände und den Maximalwert, damit ich prozentual berechnen kann, wie voll jede Patrone noch ist.

# snmpwalk -v1 -c public 192.168.100.173 1.3.6.1.2.1.43.11.1.1.9.0
SNMPv2-SMI::mib-2.43.11.1.1.9.0.1 = INTEGER: 231
SNMPv2-SMI::mib-2.43.11.1.1.9.0.2 = INTEGER: 94
SNMPv2-SMI::mib-2.43.11.1.1.9.0.3 = INTEGER: 210
SNMPv2-SMI::mib-2.43.11.1.1.9.0.4 = INTEGER: 174

# snmpwalk -v1 -c praxis 192.168.100.173 1.3.6.1.2.1.43.11.1.1.8.0
SNMPv2-SMI::mib-2.43.11.1.1.8.0.1 = INTEGER: 674
SNMPv2-SMI::mib-2.43.11.1.1.8.0.2 = INTEGER: 240
SNMPv2-SMI::mib-2.43.11.1.1.8.0.3 = INTEGER: 226
SNMPv2-SMI::mib-2.43.11.1.1.8.0.4 = INTEGER: 241
"black" ist also noch zu 231/674 voll, umgerechnet ca. 34 %.

So, damit haben wir das Werkzeug, um Dinge zu tun. Wäre schön, wenn das noch mit etwas mehr Bequemlichkeit verbunden wäre. Also packen wir all das in ein Skript.

Dieses Skript muss also mehrere SNMP-Abfragen durchführen, sich die Werte merken, Prozente ausrechnen und den ganzen Spaß dann wieder ausgeben.

Die Technik der folgenden Zeile verwendet den bash-Befehl "eval", um Shell-Befehle in diesem Moment auszuführen.
eval $(snmpwalk -v1 -c praxis 192.168.100.173 \
  1.3.6.1.2.1.43.11.1.1.6.0 | perl -ne 'print "c[$1]=$2\n" \
if(m!SNMPv2-SMI::mib-2.43.11.1.1.6.0.(\d) = STRING:\s+"(\w+) ink"!i);')

Der Shell-Befehl, den das perl-Skript zusammenbaut, nimmt die Zahlenwerte aus der SNMP-Abfrage und erzeugt daraus die Zuweisung der Abfragewerte zu Shellvariablen in einem Array. Dazu nimmt der perl-Interpreter die Ausgabe des snmpwalk-Befehls zeilenweise und untersucht jede dieser Zeilen, ob sie einem vorgegebenen Textmuster entsprechen (regular expression). perl baut also ungefähr so etwas

c[1]=black
c[2]=yellow
c[3]=cyan
c[4]=magenta
Der "eval" in der Shell sorgt nun dafür, dass diese Zuweisung im bash-Skript zu diesem Zeitpunkt ausgeführt wird, als hätte ich es vorher in den Code geschrieben. Hier greift also der Begriff "selbstmodifizierend", weil im Skript etwas passiert, was das Skript selbst vorher zusammengebaut hat (mit Hilfe von perl).

Auf dieselbe Weise werden die Maximalwerte jeder Patrone vom Drucker geholt; durch den "eval"-Befehl erhält die Shell dann noch das Array "max" mit folgendem Inhalt:

max[1]=674
max[2]=240
max[3]=226
max[4]=241
Und im nächsten Schritt wird es noch trickreicher: mit den eben gerade gelernten Arrays wird ein perl-Skript dynamisch zusammengebaut, in dem diese Zahlenwerte von einem bash-Array in ein perl-Array umgebaut werden, und ich lasse dann die Prozentwerte in perl ausrechnen. Da die Arrays in perl bei 0 anfangen zu zählen, ist in jedem Array das nullte Element ein leerer Text, also "". Das perl-Skript erhält die Tintennamen und die Maximalwerte als fest einprogrammierte Werte, und die aktuellen Zahlenwerte liest es direkt aus der Standardausgabe von snmpwalk.

Wie funktioniert dieser Trick nun genau?

Üblicherweise ruft man den Skriptinterpreter (perl, awk, sed oder irgendwas anderes) so auf: perl -e 'bla mein programm usw.'. Die Apostrophe teilen der Shell mit, dass alles dazwischen unverändert an perl weitergegeben werden soll. Man kann allerdings diese '...' unterbrechen, und an dieser Unterbrechung setzt die Shell ihre Arbeit fort. Wenn ich also perl -e '...bla(' ${variable} ')...' schreibe, besteht das Programm für perl also an dieser Stelle aus dem aktuellen Inhalt der Shell-Variablen ${variable} (z.B. 5) und das ganze wird effektiv zu perl -e '...bla(5)...'! Das ganze muss natürlich syntaktisch korrekter perl-Code werden, also muss man auf Anführungszeichen für Strings usw. achten.
#!/bin/sh

PATH=/opt/bin${PATH:+:$PATH}

# get current ink levels
eval $(snmpwalk -v1 -c praxis 192.168.100.173 \
  1.3.6.1.2.1.43.11.1.1.6.0 |
perl -ne 'print "c[$1]=$2\n" \
  if(m!SNMPv2-SMI::mib-2.43.11.1.1.6.0.(\d) = STRING:\s+"(\w+) ink"!i);')

# get max ink level per cartridge
eval $(snmpwalk -v1 -c praxis 192.168.100.173 \
  1.3.6.1.2.1.43.11.1.1.8.0 |
perl -ne 'print "max[$1]=$2\n" \
  if(m!SNMPv2-SMI::mib-2.43.11.1.1.8.0.(\d) = INTEGER:\s+(\d+)!i);')

snmpwalk -v1 -c praxis 192.168.100.173 1.3.6.1.2.1.43.11.1.1.9.0 |
perl -ne '
    my @c=("","'${c[1]}'","'${c[2]}'","'${c[3]}'","'${c[4]}'");
    my @max=("","'${max[1]}'","'${max[2]}'","'${max[3]}'","'${max[4]}'");
    printf"# $c[$1]=$2 (%.0f)\n",$2/$max[$1]*100
        if(m!SNMPv2-SMI::mib-2.43.11.1.1.9.0.(\d) = INTEGER:\s+(\d+)!i);'
 Das Ergebnis sieht dann ungefähr so aus:
$ sh ./ink.sh
# black=247 (38)
# yellow=218 (95)
# cyan=127 (59)
# magenta=195 (85)

06.04.2017

Logan

Tja, das war's also mit Hugh Jackman als Wolverine. Wie angekündigt und im Film auch ziemlich deutlich dargestellt, wird er den Charakter nicht mehr spielen.

Der Film lässt mich ein wenig ratlos zurück. Ich halte es mit Doctor Who - ich mag eigentlich keine finalen Enden mit toten Hauptcharakteren. Genauso wie in Star Wars Rogue. Der Schluss dort war absolut logisch und nachvollziehbar, aber für mich halt doch ziemlich traurig.

Kurze Übersicht: der Film spielt 2029; die Zukunft unterscheidet sich nicht wesentlich von unserer heutigen Zeit. Es gibt Autos und Straßen und den üblichen amerikanischen Way of Life. Logan lebt mit Charles X. Xavier und einem Albino namens Caliban in Mexiko auf einer entlegenen Farm; Charles hat seine Kräfte nicht mehr unter Kontrolle und nimmt Medikamente, die immer schlechter funktionieren. Logan arbeitet als Chauffeur mit eigener Stretchlimousine, quasi Uber. Auch Logan altert beträchtlich, seine Selbstheilungskräfte sind fast erloschen, und im Widerspruch zu "Der Weg des Kriegers" hat er wieder Krallen aus Adamantium.

Seit 25 Jahren wurden keine Mutanten mehr geboren, im Verlauf des Films wird angedeutet, warum das so ist - Zucker aus genmanipuliertem Mais in nahezu allen Nahrungsmitteln. Stattdessen gibt es eine Firma Alkali Transigen, die Mutanten züchtet und zu tödlichen Soldaten dressieren will. Als das neueste Forschungsprojekt ("24") erfolgreich ist, sollen alle anderen gezüchteten Kinder getötet werden. Pfleger können mit einigen der Kinder flüchten, eine Pflegerin bittet Logan um Hilfe, das Mädchen Laura in Sicherheit zu bringen in ein angebliches Paradies, das sich als Fiktion aus einem X-Men-Comic herausstellt ("Eden"). Die Helferin hat mit ihrem Handy Videoaufnahmen im Forschungslabor machen können - nicht sehr glaubwürdig. Die Kinder sind genetisch alle von Logans Erbmaterial gezeugt worden - am Ende von "Days of future past" sieht man, wie jemand Logans Blutproben in einen Koffer packt.

Der Rest ist eine Art Roadmovie und berichtet von der Flucht der drei Mutanten vor den Alkali-Söldnern. Logan und Laura bringen sehr blutig und explizit viele der Söldner bei verschiedenen Gelegenheiten um. Dabei gibt es auch viele Kollateralschäden. Beim großen Showdown überleben nur die Kinder, und Laura sagt erstmals "Daddy" zum sterbenden Logan. Dann fliehen die Kinder über die Grenze nach Kanada, wobei nicht klar wird, warum sie dort sicherer sein sollen.

Der Film war technisch gut gemacht, viel Action, gute Tricks. Die Martial Arts-Darbietung von Laura war beeindruckend; Jackman hat den gealterten Logan auch sehr glaubwürdig gespielt - ich finde den Schauspieler toll. Die FSK-16-Einstufung war mehr als gerechtfertigt, ich als Zuschauer hätte vielleicht sogar 18 vergeben.

Trotzdem bin ich irgendwie unzufrieden. Ich kann's nicht genau auf den Punkt bringen. Vielleicht liegt es wirklich nur daran, dass ich Hauptpersonen nicht sterben sehen will. Keiner von den "alten" Mutanten überlebt. Der Widerspruch zu den vorherigen Wolverine-Filmen erklären sich eingefleischte Fans vermutlich am ehesten mit der Zeitreise und der geänderten Vergangenheit in "Days of future past". Andere Mutanten wie Storm, Magneto, Jean Grey, Cyclops etc. werden gar nicht erwähnt. Was mir auf jeden Fall aufgestoßen ist: die Firma hat anscheinend beliebig viel Adamantium-Rohmaterial, und mir ist außerdem nicht klar, warum man ein Kind, das noch im Wachstum ist, schon mit einem Adamantium-Skelett ausstattet. Das würde doch nicht mehr mitwachsen?

Fazit: eingefleischte Marvel- und Comic-Fans werden sich den Film anschauen, es lohnt sich, wenn man mit drastischen Einschnitten ins Comic-Universum leben kann.

Achja: es gibt nach dem Abspann nix mehr zu sehen - ziemliche Enttäuschung für professionelle Marvel-Kinogänger.

15.03.2017

Reform des Sexualkundeunterrichts in Hessen - Leserbrief

Vor ein paar Wochen hatte die WZ ein schönes Interview mit der ehemaligen Vorsitzenden des Kreiselternbeirats, Karen Anschütz.
Im Interview berichtete sie, dass sowohl der KrEB als auch der LEB (Landeselternbeirat) wegen Meinungsverschiedenheiten im Vorstand nicht in der Lage waren, einen konsolidierten Standpunkt zur Reform des Sexualkundeunterrichts zu verabschieden.

Knapp zwei Wochen später kam ein böser, gallespuckender Leserbrief von Cornelia Marel, in dem alles verteufelt wurde, was nicht dem traditionellen Familienbild entspricht - Vater, Mutter, Kinder, alle hetero, und in dem gefordert wurde, dass im Sexualkundeunterricht keinerlei "moderne" Partnerschaftsformen und sexuelle Ausprägungen behandelt werden.
Man muss dazusagen: Fr. Marel ist die Gattin von Karel Marel, und diese beiden Namen tauchen in verschiedensten Berichten der WZ auf, und immer in Verbindung mit der AfD in Führungspositionen. Aus diesem Grund nenne ich auch hier den vollen Namen - es sind Personen, die im öffentlichen, politischen Leben mitmischen wollen.

Auf diesen schrecklichen Leserbrief hin habe ich eine Antwort geschrieben. Ich finde es wichtig, dass Kinder einen pädagogisch fundierten Unterricht bekommen, in dem alle Varianten von Sexualität und Partnerschaft neutral besprochen werden.


Leserbrief zum Leserbrief von Fr. Marel, 06.03.17

Jetzt lässt die AfD also auch in der Wetterau die Maske fallen und zeigt, dass dieser Partei die Grundrechte völlig egal sind.
Minderheitenschutz? Freie Entfaltung der Persönlichkeit? Menschenwürde? Brauchen wir nicht, sind ja nur 0,5 Promille der Bevölkerung, die „anders“ sind. Darüber müssen wir nicht sprechen.
Wir als Großeltern legen fest, welches Weltbild unsere Kinder in der Schule lernen.
Besser als in diesem Leserbrief kann man nicht nachlesen, warum die AfD nicht wählbar ist.

Haben Sie übrigens mal nachgerechnet? Woher kommt die Zahl 0,5 Promille? Das wären 5 von 10.000 Einwohnern. Sind Sie sicher, dass die restlichen 99,95 Prozent „normal“ sind? So normal, wie Sie das gern hätten? Und selbst wenn – diese Zahl ist vollkommen unerheblich. Wie Frau Anschütz sehr klar und deutlich geschrieben hat: jeder Mensch hat das Recht, sich frei zu entfalten, und insbesondere ungestört und unbeeinflusst von der Weltsicht anderer Menschen.

Es ist wichtig, dass unsere Kinder lernen, dass jede Form von Sexualität in Ordnung ist (ich erspare mir aus Platzgründen die üblichen Einschränkungen zu Konsens und Alter). Sie gehört zur Persönlichkeit, und niemand kann sich anmaßen, über andere zu richten und ihnen vorzuschreiben, wie sie zu leben haben. Zu dieser Einsicht gehört auch eine moderne Form von Sexualerziehung in der Schule. Homosexualität ist nicht ansteckend – niemand wird davon „befallen“, wenn er erfährt, dass es unterschiedliche Formen des Zusammenlebens gibt.

Ich würde sogar noch einen Schritt weitergehen: das Zusammenleben von Menschen ist keine Frage der Sexualität. Patchworkfamilien, gleichgeschlechtliche Partnerschaften und alle anderen Formen können auch genausogut bei den Gesellschaftswissenschaften unterrichtet werden. Partnerschaft bedeutet ganz einfach ein Zusammenleben in gegenseitiger Liebe, Achtung und Respekt. Wenn unsere Kinder das in der Schule lernen, kann unsere Gesellschaft daran nur wachsen und insbesondere über solche Ansichten hinauswachsen, wie sie Frau Marel in ihrem Leserbrief dargelegt hat.

Zweite Erfahrungen mit LineageOS 14.1

Nach dem ersten Bericht folgt hier noch ein kurzes Update zum Thema Update.

Nachdem Google das Security-Bulletin für März veröffentlicht hat, wollte ich natürlich auch gern mit den Custom ROMs aktuell sein und die eingebaute Update-Funktion testen.

Beim AOSP-Build für das Nexus 5 war ich bislang eher unglücklich mit den Updates, allerdings könnte dies auch mein eigener Fehler gewesen sein: nach Forenempfehlungen sollte man in einem Rutsch nach dem Flashen des neuen ROMs auch die Google-Apps unmittelbar hinterher flashen, ohne vorher neu zu starten. Damit würden dann alle Berechtigungen passend gesetzt. Die Update-Funktion im AOSP-ROM hat bis dahin nie Updates gefunden, deshalb der manuelle Weg.

Nun ja, wenn ein weit verbreitetes Custom ROM wie LineageOS eine Update-Funktion anbietet, dann sollte die auch funktionieren. Kurze Zusammenfassung: so halb und halb.

Beim Nexus 5 absolut problemlos. Zuerst im Update-Bildschirm auf "Download" und dann auf "Installieren" drücken, wenn der Download beendet ist. Zack, fertig! Build NOF27B, also der Stand März 2017. Der kleine Fehler, dass man kein Profilbild beim Nutzerkonto abspeichern kann, ist immer noch vorhanden.

Beim Moto G nicht ganz so problemlos. Download hat funktioniert, aber nach dem Druck auf "Installieren" startet zwar das TWRP-Recovery, führt aber kein Update aus. Ich habe dann manuell in den Ordner (/data/data/org.lineageos.updater/app_updates) navigieren müssen, in dem LineageOS das Update ablegt, habe die Zip-Datei und vorsichtshalber (s.o.) auch noch mal die OpenGApps-pico-7.1 ausgewählt und geflasht. Nach dem Booten war alles ok, auch hier Build NOF27B vom 05.03.2017.

Mal schauen, ob das nächste Update mit der neuesten Version von TWRP (3.1) besser funktioniert.

Alles gut ;)

14.03.2017

Flash-Update auf Version 25

Mir fehlen langsam die Worte, wie die Versionsnummern inflationär in Höhen klettern. Google hat es mit Chrome vorgemacht, aus irgendwelchen Gründen macht es Mozilla mit Firefox und Thunderbird nach, und jetzt beschleunigt Adobe die Nummerierung des Flashplayers genauso.

Und weil mir die neuen Worte fehlen, nehme ich immer den alten Blogartikel, nur die Versionsnummern und die Links ändern sich ;)

Einen Hinweis muss ich aber nun doch noch einbauen: ab Ende Januar 2016 gibt  es keine freien Downloads der Installationsdateien mehr. Genaue Modalitäten sind noch nicht bekannt, Adobe hat nur bekannt gegeben, dass die Downloadlinks über die "distribution3.html"-Seite nicht mehr zur Verfügung stehen werden und man eine Adobe-ID und eine Business-Lizenz benötige.

Wir sind jetzt schon bei Flash-Version 25 (mittlerweile zählt wohl auch ein Major release nicht mehr zu den besonders erwähnenswerten Ereignissen bei Adobe?). Wer sich selbst auf dem Laufenden halten will, kann das Blog des Security-Teams bei Adobe lesen oder als RSS abonnieren.

Wie üblich in ihrem freundlichen Service-Blog die passende Automation zum Herunterladen und Installieren. Falls ein Proxy verwendet wird, das "rem" bzw. "#" entfernen und eigene Proxy-Adresse eintragen.

Das Tool wget wird bei Windows noch benötigt wie hier beschrieben. Bei Linux sollte es schon vorhanden sein, da es von vielen anderen Programmen intern verwendet wird.

Für Windows wie üblich beide Varianten, ActiveX und Netscape Plugin (Achtung übrigens, Firefox wird demnächst das NPAPI komplett abschaffen - mal sehen, was Adobe und Flash dann machen).

Die Download-URL hat sich übrigens im Vergleich zu Version 23 leicht geändert, sowohl bei Windows als auch bei Linux.

    @echo off

    rem set http_proxy=http://192.168.100.100:3128/
    set VNP=
25.0.0.148
    set VAX=25.0.0.148

    set V=25
    set H=fpdownload.adobe.com
    set P=/get/flashplayer/pdc
    set AX=install_flash_player_ax.exe
    set NP=install_flash_player.exe

    wget https://%H%%P%/%VAX%/%AX% -O flash-%VAX%_ax.exe
    .\flash-%VAX%_ax -install
    wget https://%H%%P%/%VNP%/%NP% -O flash-%VNP%_np.exe
    .\flash-%VNP%_np -install


Für Linux 64 bit rpm (als root ausführen oder "sudo rpm" schreiben) gibt es jetzt auch wieder offiziell dieselbe Version 25 wie für Windows. Eine Zeitlang war Flash für Linux bei Version 11.2 "eingefroren", Adobe hat es sich nun anders überlegt und liefert wieder, obwohl die Zeichen generell auf Untergang stehen - in Google Chrome ist Flash gar nicht mehr enthalten, und die anderen Browser-Hersteller wechseln auf Multimedia in HTML5 statt Flash. Es gäbe auch die Version "PPAPI" zum Herunterladen, das ist die Pluginvariante "Pepper" für das Google-API, ich gebe hier "NPAPI" für das Firefox-API im Skript an.
#!/bin/sh

# http_proxy=http://192.168.100.100:3128/

VL=
25.0.0.148
H=fpdownload.adobe.com

PL=/get/flashplayer/pdc/${VL}

DL() { wget -N "$1/$2" -O "$3"; }

echo Linux 64 bit rpm ...
DL https://${H}${PL} \
   flash-player-npapi-${VL}-release.x86_64.rpm \
   flash-${VL}.x86_64.rpm
rpm -F --force flash-${VL}.x86_64.rpm
Der Filename für die 32bit-Variante ist "flash-player-npapi-${VL}-release.i386.rpm".

[20170314: Security-Bulletin von Adobe]
[20170412: Security Bulletin von Adobe]

09.03.2017

Excel-Datei mit perl erzeugen

Hach, ich liebe perl! Hab ich das schon mal erwähnt? Bestimmt nicht.

Eine ganze Zeit lang habe ich ein etwas älteres perl-Modul für Excel-Spreadsheets verwendet. Beim Lesen der Anleitung fand ich kürzlich den Hinweis, dass es einen Nachfolger gibt, mit dem das neuere XML-Dokumentenformat erzeugt werden kann. Dieses Modul kann nahezu den kompletten Umfang von Excel-Spreadsheets ausreizen, inklusive Formatierung, Charts und Formeln.

Hier ist ein kurzes Beispiel für die Verwendung. Es liest die /etc/passwd eines Unix-Systems und erzeugt daraus eine kleine Exceltabelle. Als Schmankerl setzt es die Spaltenbreite und Autofilter für alle Spalten, so dass man z.B. alle Benutzer mit "nologin" filtern kann.

Vor der ersten Benutzung muss man das perl-Modul noch mit dem Befehl

# cpan install Excel::Writer::XLSX

(als root) installieren. In blau habe ich ein paar zusätzliche Kommentare an interessanten Stellen eingefügt.

#!/usr/bin/perl -w

use strict 'refs';
use strict 'vars';

use Excel::Writer::XLSX;

my %userlist;

# Spaltentitel
my @t_passwd =qw( USER PASSWD UID GID GECOS HOME SHELL );
# Spaltenbreiten, <0 heißt Spalte verbergen
my @f_passwd =qw(   20     -3  10  10    30   20    20 );

sub setfilter {
    my ($worksheet,$row,@colwidth)=@_;
    my $numcol=scalar(@colwidth);


# Autofilter für alle Spalten
    $worksheet->autofilter(0,0,$row,$numcol-1);
    for (my $i=0; $i<$numcol; ++$i) {
        my $w=$colwidth[$i];

        if ($w>0) {
            $worksheet->set_column( $i,$i, $w );
        }
        else {

# Breite setzen, kein Format, aber verstecken
            $worksheet->set_column( $i,$i, -$w, undef, 1);
        }
    }
}

sub collect_linux_passwd {
    my ($file)=@_;

    if (open(F,"<",$file)) {
        while (my $u=<F>) {
            chomp($u);
            my @user=split(/:/,$u);
            my $uname=$user[0];

# split löscht leere Felder am Ende

            $user[6]||="";
            $userlist{$uname}=[ @user ];
        }
        close(F);
    }
}

sub exceloutpasswd {
    my ($worksheet,$title,$list)=@_;
    my $row=0;


# eine ganze Zeile schreiben ($title ist ein Arrayref)
    $worksheet->write(0,0, $title);
    foreach my $i (sort(keys(%{$list}))) {
        ++$row;

# $list->{$i} ist ein Arrayref
        $worksheet->write($row, 0, $list->{$i});
    }
    setfilter($worksheet,$row,@f_passwd);
}

collect_linux_passwd("/etc/passwd");
my $workbook = Excel::Writer::XLSX->new('passwd.xlsx');
exceloutpasswd( $workbook->add_worksheet('unix users'), \@t_passwd, \%userlist );

$workbook->close();

06.03.2017

Erste Erfahrungen mit Lineage OS 14.1

Ich gebe zu, ich bin spät dran ;)

Nach längerer Zeit hab ich nun also auch nicht nur ein, sondern gleich zwei Geräte mit LineageOS, dem Nachfolger von CyanogenMod, geflasht, um es mir mal genauer anzuschauen.

Die Opfer waren ein älteres Nexus 5 ("hammerhead") mit 16 GB, das hier noch herumlag, weil meine Frau ein Gerät mit mehr Speicher wollte, und ein noch älteres Motorola Moto G (1. Gen, "falcon"). Ansonsten ist ein Nexus natürlich optimal, weil es bei den allermeisten Custom ROMs ganz vorne mit dabei ist - eben weil alle nötigen Files von Google veröffentlicht werden und man es ohne Klimmzüge entsperren und flashen kann. Ähnlich entspannt funktioniert das Custom-ROM-Flashen bei Motorola. Die einzige kleine Hürde ist, dass man zum Entsperren einmalig eine Webseite von Motorola aufsuchen muss, dort einen Code vom Handy eingeben muss und dann einen Freischaltcode zurückbekommt.

Der erste Versuch auf dem Nexus 5 nach dem Download war wenig erfolgreich - das Flashen verlief ohne Fehlermeldung und ich bekam zwar die Bootanimation von LineageOS zu sehen, aber nach etwa einer Stunde dachte ich mir, dass da irgendein Problem sein muss, und habe abgebrochen. Das Nexus 5 ist immer noch ein ziemlich aktuelles und vor allem schnelles Gerät, nicht wie damals das Motorola Milestone 2, bei dem der erste Bootvorgang 30 Minuten gedauert hat.

Beim nächsten Versuch, ins Recovery zu booten, stellte ich fest, dass irgendwie auch das Recovery kaputt gegangen ist. Also im Fastboot-Modus erst mal ein neues Recovery geflasht (TWRP), und dann ging das schon mal wieder ;)

Im nächsten Schritt habe ich erneut im Recovery den Nightly Build vom 28.02. und die OpenGApps (pico) geflasht. Diesmal war ich aber noch etwas konservativer und habe die Frage von TWRP verneint, ob ich vor dem Reboot auch SuperSU installieren will. LineageOS liefert ein eigenes Addon für SU-Funktionalität mit, und ich wollte es erst mal ohne alle Veränderungen versuchen.

Bingo! Dieser Versuch klappte auf Anhieb, und wenig später erschien der Einrichtungsassistent von Android Nougat. Lineage ist auf dem aktuellen Stand 7.1.1, Build NOF26W, Sicherheitsstand 05.02.2017.

Beim Moto G war gleich der erste Versuch erfolgreich, und nach einigen Minuten hatte ich auch hier die übliche Ansicht.

Bei den OpenGApps kann man sich aussuchen, wie umfangreich das Google-Paket sein soll, das man als Basissystem installiert. "pico" ist das kleinste Paket und enthält eigentlich nur die App für den Play Store; somit kann man später gezielt aussuchen, welche weiteren Google-Apps man haben will. Die größeren Pakete enthalten dann immer mehr, was gleich als System-App installiert wird. Je nachdem, wie groß die Systempartition ist, kann man also gar nicht alles installieren, was zur Auswahl steht, sondern muss ein "kleines" Paket nehmen und nachinstallieren. Diese nachinstallierten Apps  werden dann in den "normalen" Speicher des Telefons installiert.

Viele Features der bisherigen CyanogenMod-Versionen hat Google ohnehin auf die eine oder andere Weise übernommen, so dringend ist es mit Nougat nicht mehr, eine "Bells and Whistle"-Version von Android zu installieren. Auffällig ist, dass die "Themes" von CM verschwunden sind, es ist also nicht mehr so leicht möglich, z.B. eine angepasste Bootanimation zu verwenden.

Der eine Punkt, der mir bei meiner vorherigen "Custom" ROM aufgefallen ist, war die unzuverlässige Update-Methode. Ich hatte bislang auf dem Nexus 5 einen AOSP-Build, d.h. ein Android, das aus den offiziellen Quelltexten von Google gebaut wird. Nach keinem der Flashvorgänge konnte ich problemlos weiterarbeiten, ich bekam immer Fehlermeldungen, dass Google Play Services abgebrochen wird. Erst ein Factory Reset, d.h. Rücksetzen und Neueinrichten des Telefons, konnte das beheben. Für ein täglich genutztes Werkzeug ist so ein Verhalten natürlich indiskutabel, deshalb hoffe ich, dass die Updates von LineageOS sich problemlos(er) einspielen lassen.

Ich hatte neulich im Nexus 5-Thread zu AOSP-Nougat auf xda-developers gefragt, und da kam doch gerade eben eine Antwort mit einem Vorschlag: man soll beim Update nicht nur das AOSP-ROM, sondern auch noch die OpenGApps in einem Rutsch mit flashen, damit die Berechtigungen der System-Apps korrekt gesetzt werden, das würde nämlich nur beim ersten Booten nach dem Flashen gemacht. Alles in allem trotzdem sehr unschön: ein inkrementelles Update wie beim Nexus-Android wäre natürlich die schönste Lösung, und insbesondere viel kleiner. Die Updates, die ich bislang beim Nexus 5 erlebt habe, waren mit 10-20 MB pro Monat erfreulich klein.

Bislang funktioniert LineageOS bei mir schmerzfrei. Aufgefallen ist mir ein kleiner Fehler sowohl beim Nexus als auch beim Moto G: ich kann zwar bei den Benutzerkonten ein Bild für den Benutzer aussuchen, aber das "Speichern" speichert nicht, ich habe nach wie vor nur das abstrakte Platzhalterbildchen. Das kann ich verkraften ;)

Beim Motorola gibt es noch einen merkwürdigen Effekt: nach der Grundinstallation hatte ich mir einige der Google Apps aus dem Play Store installiert, darunter die aktuellste Version von Kalender, Kontakte und Telefon. Die mitgelieferten Apps von LineageOS hatte ich bei den Apps-Einstellungen deaktiviert. Beim Telefonieren mit einem "Direktwahl"-Widget konnte ich zwar telefonieren, aber die App wollte mir den üblichen Telefonbildschirm nicht anzeigen; somit konnte ich die Zahlentastatur nicht benutzen, stumm schalten, Lautsprecher, etc. Deshalb habe ich die Telefon-App wieder deinstalliert und mit der Version, die mit LineageOS mitkommt, funktioniert alles so, wie es soll.

Was mir im Vergleich zum Vanilla-Android immer noch besser gefällt, ist die Möglichkeit, die Statusleiste, die Benachrichtigungen und die Schnelleinstellungen bequem(er) anzupassen und die Icons rauszuwerfen, die man persönlich nicht braucht. Ich benötige z.B. die Icons für "Hotspot" und "Übertragen" gar nicht. Aber selbst diese Anpassungen kann man mit den normalen Android erreichen. Wenn man nämlich lang auf das Einstellungen-Zahnrad drückt, kann man den "System UI Tuner" aktivieren, und mit dem kann man ebenfalls diese Icons bearbeiten.


Trebuchet App FolderHingegen gefällt mir der Standardlauncher von CM und LO seit den letzten zwei Versionen gar nicht mehr, die Icons in Ordners extrem verkleinert anzuzeigen statt sie mit 3D-Effekt hintereinander zu stapeln. Deswegen ist der erste Handgriff dann auch, auf den Google Now-Launcher umzustellen - der ja leider nun auch eingestellt wird. Der Launcher3 des AOSP-Projekts sieht ziemlich gut aus, alternativ gibt es mittlerweile auch den Pixel-Launcher im Play Store, und jede Menge weitere Alternativen für jeden Geschmack.

Auf jeden Fall ist ein Custom ROM, egal ob es AOSP, LineageOS oder ein anderes ist, immer noch eine gute Möglichkeit, sein Schätzchen auf dem neuesten Sicherheitsstand zu halten, selbst wenn Google die Auslieferung von Updates im Dezember 2016 für dieses Modell eingestellt hat. Eigentlich ist das schade - die Patches werden von Google bis zurück zu 4.4 ins AOSP-Repository eingepflegt (soweit das technisch möglich ist), und die Build-Maschinerie könnte weiterhin das Nexus 5 mit Marshmallow-Updates auf dem aktuellen Sicherheitsstand versorgen.

20.02.2017

Soziale Netzwerke vor 30 Jahren oder: Opa erzählt vom Krieg

Vor langer Zeit, als die "sozialen Netzwerke" noch "Mailboxnetze" hießen, war ich Mitglied in mehreren solcher Netze.

Die Technik damals war im Vergleich zu heute gar nicht so viel anders. Das heutige Internet ähnelt zwar dem Entwurf des DARPA-Netzes auch nicht mehr so, aber das Grundprinzip ist immer noch sichtbar: ein dezentrales Netzwerk mit store-and-forward-Prinzip an den Relaispunkten.

Die Mailboxnetze von damals gab es in mehreren Kategorien, wenn man die Software betrachtet. Auf der einen Seite gab es die Netze mit Fido-Technik, daneben gab es das Maus-Netz, und ein paar wackere Kämpen hatten damals schon Zugang zum Usenet mit Unixtechniken wie UUCP und kleinere Netze mit noch eigener Software wie Zerberus usw.

Wir reden hier vom Zeitraum von ungefähr 1988 bis 2000. Damals kostete das Telefonieren noch richtig viel Geld, und das Internet gab es nur für große Firmen und Unis als "Standleitung" für mehrere Hundert DM Gebühren pro Monat. Die Uni Gießen hatte damals eine 2-MBit/s-Anbindung, und es war ein unglaublicher Fortschritt, als ca. 1995 die 34 MBit/s.-Leitung geschaltet wurde; aber ich schweife ab. Privatleute verwendeten ein sogenanntes Telefonmodem, und die gab es damals mit und ohne Segen der Deutschen Bundespost und heftigen Strafandrohungen, falls man denn erwischt werden würde. Aus heutiger Sicht betrachtet vollkommen lächerlich, aber so selbstherrlich gebärdete sich damals die staatliche Bundespost.

Die Entscheidung für oder gegen die Teilnahme an einem Mailboxnetz wurde hauptsächlich durch die Erreichbarkeit der Partner und damit die Telefonkosten bestimmt. Die Verbindung zum "Uplink", also dem Lieferanten, wurde mit Hilfe von Telefonmodems gehalten, die üblicherweise Geschwindigkeiten von 2.400 bis 14.400 Bit/s. hatten (da sind wirklich keine Vorsilben vor der Maßeinheit!).

Bei den schnelleren Modems gab es zwei Standards, weil die Standardisierung nur bis 9.600 gekommen war, die Norm hieß damals V.32.

Bei der Weiterentwicklung auf 14.400 Bit/s gab es zwei Konkurrenten: US Robotics mit einem proprietären Standard, und die wurden später von ZyXEL ziemlich heftig vom Markt gefegt, soweit ich mich noch erinnere. ZyXEL und später andere Hersteller lieferten Modems mit V.32bis-Standard für 14.400 Bit/s., und obwohl ZyXEL eigentlich aus der Geschichte mit dem proprietären US-Robotics-Protokoll hätte lernen können, machten sie es dann genauso: für die "normalen" ZyXEL-Modems wurde mit einem ROM-Update eine mit keinem anderen Hersteller kompatible Geschwindigkeit von 16.800 Bit/s. geliefert (damals musste man die EPROMs noch mit einem Spezialgerät brennen, Typ 27512). Im FidoNet gab es dann unglaublich hitzige Diskussionen, ob man in der Nodeliste diese Angabe einpflegen soll und unter welcher Kennung. Wenn man sonst keine Probleme hat ...
ZyXEL hat dann das Plus-Modell mit mehr Speicher und etwas schnellerem Prozessor gebaut, das dann ebenfalls proprietäre 19.200 Bit/s. beherrschte. So ein Modell werkelt bei uns in der Praxis immer noch, aber wird nur noch als reine Faxmaschine mißbraucht. Außerdem habe ich bei ebay billig noch ein Ersatzgerät gekauft, falls das erste kaputt geht (Cold standby).

Nebenbei gab es noch eine proprietäre Technik, nämlich das Telebit Trailblazer, die damals schon 19.200 Bit/s. beherrschten, und davon gab es auch eine postzugelassene Variante in Deutschland zu kaufen oder von der Post zu mieten (!). Ich kann mich aber nicht mehr an Preise erinnern.

Diese Modems haben in der Größenordnung 500 bis 800 DM gekostet, eine ganz schöne Stange Geld (inflationsbereinigt würde ich sagen, das ist heute dasselbe in Euro). Der Höhepunkt der analogen Telefonmodems waren die Geräte mit standardisierten 28.800 und 56.000 Bit/s, die aber nicht mehr allzuviel Verbreitung fanden, weil viele Betreiber neben dem analogen auch einen digitalen ISDN-Zugang anboten (ich übrigens auch - meine TeX-Box hatte zwischendurch 2x analog und 2x ISDN für bis zu vier gleichzeitige Anrufer).

Nun ja, wie auch immer - ich hatte im Ortsbereich einen Lieferanten für Fido in Lich, das war für mich als Schüler bzw. angehender Student gerade noch bezahlbar. Die eigene Telefonleitung war schon Luxus, nur das Umstecken von Telefon zu Modem war ziemlich schnell ziemlich lästig. Kurze Zeit später hatte ich also eine separate Telefonleitung für das Modem, und von da zum Mailboxbetreiber statt nur -nutzer war es nur noch ein kleiner Schritt ;-), aber bis zur TeX-Box war es zeitlich noch ein ganz schöner Weg. Wer noch alte c't-Hefte aufgehoben hat: dort war ich ziemlich lang mit der "TeX-Box" in der Mailboxliste enthalten; eines der Netze, an denen ich teilnahm, war das GerNet mit der Zonennummer 21:, das vom Heise-Verlag betrieben wurde und kurz vor der Jahrtausendwende abgeschaltet wurde, weil deren Software nicht y2k-tauglich war (soweit ich mich noch erinnere).

Zunächst hatte ich also ein relativ preisgünstiges Modem als interne Steckkarte für den PC mit 2.400 Bit/s. Übrigens haben damals ziemlich viele Leute die Maßeinheiten Baud und Bit ziemlich konfus durcheinander verwendet, obwohl sie ganz unterschiedliche technische Sachverhalte beschreiben. "Baud" misst, wieviele "Symbole" pro Sekunde übertragen werden. Mit einem "Symbol" können aber je nach Kodierung mehrere Bits übertragen werden. Bis 2.400 war Baud und Bit noch dasselbe, aber mit zunehmender Geschwindigkeit konnten pro Baud immer mehr Bit übertragen werden, mit Kodierungen wie Trellis, QAM usw.

Die richtigen Profis hatten einen eigenen PC, der nur für die Verwaltung des bzw. der Modems zuständig war, und haben auf einem anderen PC die Mails gelesen. Soweit war ich noch lange nicht, bei mir lief alles auf einem PC, und dazu gab es damals (vor Windows-Zeiten) Programme, mit denen auf einem 286 oder 386 schon richtig gutes Multitasking möglich war. Die Software, die ich zunächst verwendete, damit die Mailbox funktionierte, hieß QEMM-386 und war im großen und ganzen der Vorläufer der heutigen Betriebssysteme, die mehrere Dinge (fast) gleichzeitig tun konnten.

Nach kurzer Zeit war ich damit aber eher unzufrieden, und weil ich schon länger in Fachzeitschriften wie mc und c't von "großen" Betriebssystemen gelesen hatte, wollte ich unbedingt OS/2 ausprobieren. Damals war die Version 2.0 im Entstehen, und für kleines Geld gab es die ersten Beta-Versionen zum Testen zu kaufen, geliefert auf ca. 50 Disketten (mit C-Compiler, Druckertreibern, Bildschirmtreibern und zahllosen anderen Dingen wie 3270, die ich damals überhaupt nicht verstand).

OS/2 war richtig klasse und ich bin mit fliegenden Fahnen von MS-Dos weg hin zu OS/2 gewechselt und bis zu einem doofen Festplattendefekt Mitte 2000 war ich ein begeisterter Anhänger. Als IBM 2005 dann den Tod von OS/2 bekanntgab, war ich ziemlich niedergeschmettert; obwohl ich privat schon lang kein OS/2 mehr verwendete, sondern beruflich bedingt Linux und Windows, finde ich bis heute, dass OS/2 ein trauriges und unrühmliches Ende nahm. Es wird bis heute als "eComStation" weiter von einer Drittfirma vermarktet und gepflegt, aber eigentlich ist das nur für Firmenkunden interessant; für Privatleute hingegen überhaupt nicht.

Leider gab es für OS/2 relativ wenig gute Software, insbesondere für die Fido-Technik, und die Dos-Emulation ließ am Anfang doch arg zu wünschen übrig. Also fing ich an, selbst Fido-Software zu programmieren. Dabei half mir Open Source ganz gewaltig: es gab nämlich den genialen gcc-Compiler in einer speziellen OS/2-Variante, die den größten Teil der richtig guten Features nutzen konnte, auch ohne von IBM das Software Development Kit zu kaufen. Das einzige, was ich nie hinbekommen habe, war, wie man in einem 32-Bit-C-Programm eine Callback-Funktion definiert, die von einer 16-Bit-DLL aufgerufen werden kann. Das hätte ich für die Benutzung der OS/2-ISDN-CAPI brauchen können, die gab es nämlich nur als 16-Bit-DLL.

Nach einiger Zeit hatte ich eine komplette Suite von Programmen und Hilfsprogrammen, um eine Mailbox mit allen Features zu betreiben. Nachdem das letzte Dos-Programm also einen Ersatz gefunden hatte, konnte ich feierlich in der config.sys von OS/2 die Umstellung auf "ProtectOnly=Yes" durchführen und nach dem nächsten Booten hatte ich 1 MB Speicher mehr, weil es keine Dos-Emulation mehr gab.

Einer meiner Bekannten berichtete dann bei einem Treffen davon, dass er jetzt auch Zugang zum Usenet hat, und rein zufällig war sein Lieferant auch für mich über Ortsnetz erreichbar, also halbwegs preisgünstig. Flugs den C-Compiler  geschwungen und mir selbst ein Gateway zwischen UUCP und Fidonetz gebastelt, für Mail (mit batch-smtp) und News.  Auch im Usenet war ich dann unter texbox erreichbar, zuerst unter der Domain cpr.sub.org, und als die dann eingestellt wurde, war ich noch eine Zeitlang Mitglied bei lahn.de. Der Verein hatte durch gewisse Kontakte die Möglichkeit erhalten, einen eigenen Rechner im Rechenzentrum der Uni Gießen aufzustellen, und bot damit über Modems die Möglichkeit, ebenfalls Mail und News zu beziehen. Mit der zunehmenden Verbreitung von Zugangsmöglichkeiten über die normalen Telefonanbieter wie Telekom ist das alles dann irgendwie entschlafen, und heute habe ich über TGnet eine 50-MBit/s-Anbindung. Wahnsinn ;)

Das Windows in OS/2 habe ich übrigens nie verwendet (in OS/2 2.0 war Windows 3.0 enthalten und in Warp 3 aus dem Jahr 1994 war es dann Windows 3.1). IBM konnte das mitliefern, weil Microsoft und IBM noch gute Partner waren, bevor sie sich beim Streit über Windows NT gegen OS/2 2.x entzweiten. OS/2 3.0 "Warp" gab es dann in zwei Varianten, eine "rote" Edition ohne Windows für deutlich weniger Geld, und ein "blaues" Warp 3, bei dem schon Windows 3.1 enthalten war. Und selbst beim "roten" OS/2 konnte man nachträglich mit den eigenen Windows-Disketten die Emulation installieren. Windows 95 als 32-Bit-Aufsatz auf einen Dos-Unterbau ließ sich unter OS/2 nicht zum Laufen bringen, das wäre mit dem Protected Mode kollidiert. Es gab aber die abgespeckte win32s-Variante, aber das weiß ich nur aus Zeitungsartikeln, ich lebte da schon länger "ProtectOnly". Das Spiel "FreeCell" gibt es heute noch in Windows. Damals war es ein erster Lackmus-Test, ob win32s korrekt installiert wurde und funktioniert; dieses Spiel war das erste, das die neue 32-Bit-API von Windows benutzte, und win32s war eine Erweiterung für die älteren Windows-Versionen, um wenigstens einen Teil der 32-Bit-API in die alte Welt zu bringen.

Zuerst hieß der Artikel noch "Jugendsünden" - ich wollte nämlich darüber schreiben, wie ich in einem meiner Fido-Programme einen ganz dämlichen Fehler eingebaut hatte und ihn monatelang nicht finden konnte. Eines der Blogs, das ich ganz gern lese, hat gelegentlich auch Artikel über Fehler beim Programmieren. Aber irgendwie hat sich der Artikel dann ganz anders entwickelt, als ich dachte. Trotzdem will ich diese Anekdote noch aufschreiben, nach diesen ganzen Abschweifungen und historischen Andeutungen.

Eines der Programme, an dem ich ziemlich lang und ziemlich intensiv gearbeitet hatte (es hatte am Ende knapp 150.000 Zeilen Code), war eines, mit dem man Dateien in einem Mailboxnetzwerk an Abonnenten verteilen konnte. Dieses Programm konnte auch Mails erzeugen, um die Interessenten zu benachrichtigen. Das Aussehen der Mails war mit Textschablonen ziemlich frei konfigurierbar. Und im Programmcode für das Erzeugen der Mails war ein ziemlich dummer Fehler drin.

Üblicherweise deklariert man in C-Funktionen die Variablen, die man benötigt. Als Anfänger habe ich zuerst alle meine Strings als statische char-Arrays definiert. Irgendwann in meiner Lernphase dachte ich dann, ich müsste den Speicher effizienter ausnutzen und statt char origin[66] besser char *origin=malloc(length(irgendwas)) schreiben. Heute lacht man natürlich darüber, ob es sich lohnt, den Code zum zweiten Mal anzufassen, um 60 Byte für einen String einzusparen. Naja.

Dummerweise hatte ich an einer ganz anderen Stelle im Code (das ist der erste blöde Fehler) ein Sicherheitsnetz einbauen wollen, damit die von mir erzeugten Mails einen bestimmten Fido-Standard nicht verletzen, und deshalb beim Abspeichern der Mail origin[65]='\0' verwendet, um eine maximale Länge nicht zu überschreiten. Das waren dann gleich zwei blöde Fehler: (1) ein hartkodierter Wert 65, der (2) weit entfernt von der Deklaration der Variablen origin verwendet wird.

Das ist so eine Programmiertechnik, die meistens funktioniert. Außer, wenn der Parameter, der beim weit entfernten malloc einfließt, kleiner als 65 wird. Der String ist dann natürlich kürzer als 65 Byte, und in diesem Fall schieße ich mir irgendwo in den Speicher in eine ganz andere Variable ein Nullbyte hinein, das da nicht hingehört.

Ich habe ungelogen Monate gebraucht, bis mir der Zusammenhang klar war und ich eines meiner ersten Kopf->Tisch-Erlebnisse hatte. Natürlich ist das nie bei mir passiert, weil ich ausgerechnet so eine Situation bei mir nie hatte, aber ich habe die von mir programmierte OS/2-Software auch an andere OS/2-Mailboxbetreiber weiter gegeben, und von denen kamen dann ab und zu Meldungen über unerklärliche Abstürze oder abgeschnittene Texte in Mails. Das wurde mir dann klar: ein Nullbyte an der falschen Stelle kann viel Schaden anrichten.

Gefunden habe ich den Fehler dann, indem ich nahezu einen gesamten Programmdurchlauf im Debugger im Single-Step-Modus ausgeführt habe, während ich ein paar der "verdächtigen" Variablen mit einem dauerhaften Watch-Ausdruck beobachtete. Ich wusste gar nicht mehr, dass ich an einer weit entfernten Stelle im Code dieses "Sicherheitsnetz" eingebaut hatte, das war schon Monate her. Aber in dem Moment, als der Debugger mir die Zeile Code anzeigte und wie oben schon erwähnt eine ganz andere Variable plötzlich auf die Hälfte gekürzt wurde, war ich total begeistert. Und einen Moment später kam dann auch das schon erwähnte Kopf->Tisch-Erlebnis ;-)