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.127
    set VAX=25.0.0.127

    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.127H=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]

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 ;-)

14.12.2016

Flash-Update auf Version 24

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 24 (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=24.0.0.221

    set VAX=24.0.0.221

    set V=24
    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 24 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=24.0.0.221
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".

[20161213: Security-Bulletin von Adobe]
[20170110: Security-Bulletin von Adobe]
[20170214: Security-Bulletin von Adobe]