02.02.2018

Ich bau mir ein Linux wie es mir gefällt

Seit langen Jahren bin ich begeisterter Nutzer einer ganz speziellen Linux-Variante namens "Linux from scratch".

Wie der Name sagt, wird dabei ein Linux-System von Grund auf ("from scratch") komplett neu gebaut. Dazu werden die Quelltexte verwendet, um selbst alle Pakete zu übersetzen und einen PC (oder ein anderes Rechnersystem) mit einem von Festplatte startfähigen Linux auszustatten.

Dabei hat man natürlich ein Henne-Ei-Problem: man braucht ein Linux, um das neue Linux zusammen zu bauen. Für dieses Problem gibt es mehrere Lösungsmöglichkeiten: zum Einen kann man das LFS in einer virtuellen Maschine zusammenbauen. Alternativ kann man auf dem Zielrechner zunächst eine kleine Partition mit einem anderen Linux einrichten, von dort starten und dann das LFS auf den freien Platz der Festplatte werfen. Das Linux zum Bauen kann man dann hinterher als Notfallsystem behalten, oder aus der Partition dann die Swappartition machen oder sie anderweitig verwenden. Für das allererste ("bootstrap") Linux reicht eine Minipartition von 8-16 GB, und dort kann man dann z.B. ein Linux Mint oder Fedora installieren.

"Linux from Scratch" ist nicht nur eine Anleitung für ein Linux zum Selbstbasteln, sondern ist hauptsächlich dazu gedacht, Erfahrung beim Bauen von Linuxprogrammen aus den Quelltexten zu sammeln.

Man lernt dabei eine ganze Menge, nämlich vor allem Zusammenhänge zwischen den verschiedenen Programmen, Konfigurationsdateien, aber auch viel über Netzwerke, und vor allem natürlich über die technischen Voraussetzungen, darunter die Verwendung von Makefiles, und man lernt, Logfiles zu lesen, um die Probleme zu beseitigen.

Bei "LFS" gibt es verschiedene Steigerungsmöglichkeiten, wie man sich selbst das Leben schwer und spannend machen kann. Man kann das Basissystem bauen, dann hat man "nur" eine Linux-Kommandozeile.

Darauf aufbauend ist es mit dem Fortsetzungsbuch "Beyond Linux from scratch" (BLFS) möglich, einen Server zu bauen, mit dem man z.B. eine Firewall, ein NAS, einen Webserver, oder noch viel mehr zusammen bauen kann. Oder man baut sich ein Desktopsystem mit einer grafischen Oberfläche, und am Ende steht dann der selbst kompilierte Firefox. Hört sich das nicht cool an?

Eine Schwierigkeitsstufe darüber steht die Automation des Bau-Vorgangs - und hauptsächlich darüber will ich hier schreiben. Die Anleitung von "LFS" für ein Basissystem und für das "BLFS" sind ziemlich gut. Wenn man sich daran hält, hat man gute Chancen, manuell Schritt für Schritt ein lauffähiges System zu erstellen. Man geht am Browser durch alle Kapitel der Reihe nach durch und führt gemäß Anleitung die einzelnen Schritte durch. Das ist beim ersten Mal ehrlich gesagt mühsam - ich spreche aus Erfahrung ;-). Andererseits ist es spannend zu erleben, wie das Linuxsystem mit jedem Schritt wächst und tatsächlich immer mehr dem ähnelt, was man als Linuxbenutzer kennt.

Die Automation "Automated Linux from scratch" (ALFS) hingegen ist in einer README-Datei nur spärlich beschrieben. Dafür hat man, wenn man das System einmal verinnerlicht hat, eine wunderbare und sehr esoterische Möglichkeit, Updates zu installieren oder das gesamte System auf Knopfdruck noch einmal komplett neu zu erzeugen.

Auf diese Weise habe ich über Nacht ein Linux gebaut - besser gesagt: bauen lassen, das mit dem neuesten Kernel 4.15 und C-Compiler gcc 7.3 gegen Spectre und Meltdown gefeit wäre. - Wenn, ja wenn mein Bastelsystem ein 64-bit-System gewesen wäre (x86_64) und nicht 32 Bit (i686). Und wenn ich das Gefühl hätte, dass ich wirklich von diesen Sicherheitslücken bedroht bin. Aber zum Thema Risikoanalyse muss ich noch mal einen eigenen Artikel schreiben, denke ich.

Und noch eine Stufe darüber verwendet man nicht die "stable" Variante der Bücher, sondern die LFS- und BLFS-Bücher, die gerade in der Entwicklung sind. Die Autoren der Kapitel sind permanent damit beschäftigt, neue Versionen der Pakete zu integrieren und die Artikel anzupassen. Wenn sich z.B. bei einem Paket das Verfahren ändert, wie man das Paket lauffähig kompiliert, wird das enorm schnell in die "development"-Variante von LFS bzw. BLFS übernommen. Genau das ist mir während des Schreibens dieses Artikels passiert: ich habe das Makefile angestoßen, und mittendrin wurde im Buch auf ncurses 6.1 umgestellt. Kaum war ich fertig, veröffentlichen die Entwickler die neue glibc-Version 2.27. So kann's gehen ...

Um noch mal auf "Meltdown" und "Spectre" zurück zu kommen: das LFS-Buch enthält seit kurzem brandneue Kernel- und gcc-Versionen, die diese Sicherheitslücken beheben sollen. Das ist natürlich immer "work in progress". Der aktuelle Stand ist, dass Spectre V2 und Meltdown repariert sind, und für Spectre V1 ist noch einiges an Entwicklerarbeit zu leisten. Die alten 32-bit-Prozessoren hinken hier leider hinterher, für 64 bit (also alles, was grob jünger als 10 Jahre ist) sollten alle Fixes auf jeden Fall in Arbeit sein.

So, jetzt aber wie versprochen eine genauere Beschreibung der Automation für LFS (ALFS). Dazu lädt man sich zunächst das aktuelle Paket herunter. Der Paketname lautet aus historischen Gründen "jhalfs" und ehrt damit den ersten Entwickler des Verfahrens mit seinen Initialen "jh".

Damit jhalfs funktioniert, benötigt es ein paar zusätzliche Linux-Pakete auf dem Gastsystem, die man nachinstallieren muss, weil sie normalerweise nicht für Endbenutzer erforderlich sind. Dazu gehören natürlich der C-Compiler gcc und einige Hilfsprogramme und Bibliotheken wie bison, awk, ncurses etc. Das Schöne ist: wenn man jhalfs startet, kontrolliert es, was noch fehlt und beschwert sich. Für die Verwendung der "development"-Fassung muss man außerdem noch Subversion installieren, um die tagesaktuellen Dateien aus dem Versionskontrollsystem herunter zu laden.

Die Automation setzt tatsächlich schon bei den allerersten Schritten ein, die man gemäß LFS-Buch durchführen würde: dem Erzeugen eines neuen Unixbenutzers "lfs" für das Kompilieren der Pakete, dem Anlegen von Verzeichnissen usw. Der einzige Schritt, den man selbst durchführen muss, ist das Erzeugen einer Festplattenpartition und sie dann so zu mounten, dass die Skripte sie finden können. Traditionell ist das /mnt/lfs, man kann es aber nach Belieben ändern, wenn man weiß, was man tut.

Vorab ein paar Worte zum Design von jhalfs: die Autoren erstellen LFS und die weiteren Bücher in einem speziellen XML-Format namens "DocBook"; daraus werden mit trickreichen XSLT-Transformationen dann lesbare Bücher in HTML, PDF oder sogar TeX. jhalfs verwendet ebenfalls XSLT-Transformationen, um aus dem Buch die Kommandozeilenanweisungen herauszufiltern, und erstellt daraus ein Makefile und Installationsskripte für jedes Kapitel, d.h. jedes zu installierende Paket. Die Automation mit ALFS ist also ein zweistufiger Prozess: zuerst werden aus dem Buch die Befehle zum Bauen herausgefiltert und in ein Makefile mit Hilfsskripten umgewandelt, und in einem zweiten Schritt wird diese Befehlsliste ausgeführt.

Die Autoren liefern außerdem eine komplette Liste der Softwarepakete mit Versionsnummern, die man entweder selbst herunterladen kann oder die automatisch nach Bedarf geholt werden, wenn man eine einigermaßen schnelle Internetverbindung hat. Grob geschätzt muss man für LFS ca. 400 MB an Paketen herunterladen und für BLFS, je nach Umfang, bis zu 2 GB.

Die Pakete sollte man in einem Verzeichnis /mnt/lfs/sources unterhalb der zukünftigen LFS-Partition ablegen, damit während des Ablaufs alle Pakete gefunden werden können. Hierzu wird eine Unix-Technik namens "chroot" (change root) verwendet, um einem laufenden Programm eine andere Festplattenstruktur vorzutäuschen - effektiv wird das verwendet, um so zu tun, als würde es schon in der "richtigen" LFS-Umgebung ausgeführt werden.

Das Makefile für LFS wird in einem neuen Unterverzeichnis erzeugt, in das man nach der Festlegung von ein paar Grundannahmen wechseln muss. Genau wie /sources sollte dieses Verzeichnis auf der zukünftigen LFS-Partition liegen, damit alle Skripte auch in der "chroot"-Umgebung erreichbar sind. Wenn man nun dort "make" startet, sollte nach einigen Stunden (je nach Geschwindigkeit des Rechners*) ein fast schon startfähiges Linux auf der neuen Partition vorliegen. Schritte, die man automatisieren kann, aber nicht muss, sind das Kompilieren eines Kernels und das Festlegen der Partitionen, die beim Starten gemountet werden sollen.

*) Als grobe Richtschnur zwei Vergleichszahlen, die ich mit der aktuellen LFS-Version gemessen habe. Das Paket, das mit großem Abstand am längsten dauert, ist der finale Schritt, den C-Compiler zu kompilieren. Auf einem alten Pentium 4 dauert das 540 Minuten, auf einem etwas aktuelleren i5-3350 immer noch knapp 230 Minuten. Eine SSD statt einer Festplatte ist hierbei eine große Hilfe, Zeit zu sparen.

Der erste Schritt nach dem Auspacken des jhalfs-Pakets ist, in das Verzeichnis zu wechseln und dort "make" einzugeben. Wer schon mal einen Kernel selbst kompiliert hat, wird gleich einen Aha-Effekt erleben: die Konfiguration verwendet dieselbe Textoberfläche für die Menüauswahl wie der Kernel beim "make menuconfig". Hier kann man LFS/BLFS wählen, "stable" oder "development", ob der Kernel auch automatisiert kompiliert werden soll und einiges mehr. Die Grundeinstellungen sind gar nicht so schlecht, und man sollte nur ändern, was man auch versteht ;-)

Nach dem "exit" aus diesem ALFS-Menü kommt die Frage, ob man zufrieden ist mit der Konfiguration. Bei "yes" werden die schon erwähnten Prüfungen durchgeführt, ob alle Developerpakete auf dem Gastlinux vorhanden sind und bestimmte Mindestvoraussetzungen erfüllen, wie z.B. gcc mindestens in Version 4.6 (weil frühere Versionen Fehler enthalten, so dass das LFS nicht funktionieren würde oder Pakete nicht kompiliert werden können usw.). Wenn das alles erfolgreich geprüft wurde, wechselt man (als Benutzer, nicht als root) in das neue Verzeichnis und startet dort erneut "make".

Coole Socken schauen sich im Unterverzeichnis lfs-commands die Dateien unterhalb von chapter040506 und 07 erst mit dem Editor an, bevor sie make starten. Man könnte insbesondere bei den Dateien für Kapitel 7 direkt auf die Idee kommen, dort die Stellen noch zu bearbeiten, die mit **EDITME** markiert sind ;-)

Parallel dazu empfiehlt es sich, dieselbe Version des Buchs in einem Browser zu öffnen und die Kapitel zu lesen, die der Automatismus auch gerade zu bauen versucht. Bei Problemen kann man dann im jeweiligen Kapitel nachlesen, was gerade passiert.

Wahrscheinlich wird es beim ersten Mal nicht gleich komplett erfolgreich funktionieren; das ist aber nicht schlimm: wenn ein Fehler gemeldet wird, kann man sich die Logdatei dieses Schritts aus dem Unterverzeichnis logs anschauen, den Fehler beheben und dann einfach wieder "make" eingeben. Das make-Programm ist so schlau, dass es an derselben Stelle weitermacht. Manche Pakete werden mehrfach gebaut, z.B. der C-Compiler und einige Hilfsprogramme. Dies hat den Zweck, dass man nicht aus Versehen Abhängigkeiten zum Gastsystem einbaut. Wenn ein wichtiges Programm mit der C-Bibliothek des Gastsystems gelinkt wäre, würde das nach dem Booten ja nicht mehr funktionieren. Also wird ein "Zwischensystem" in einem anderen Pfad (/tools) gebaut, das dann das endgültige LFS kompilieren kann.

Ein paar generelle Tipps, wenn das Kompilieren eines Pakets fehlschlägt: gcc 7.3 ist "bleeding edge", also so brandneu, dass man sich bei Verwendung auch mal in die Finger schneiden kann ;-). Ich will damit sagen, dass hier soviele Änderungen drin sind, z.B. Anpassungen an die aktuellen C- und C++-Standards, die in den meisten Paketen und in den Gehirnen der Entwickler noch nicht angekommen sind. Aber: man will gcc 7.3 und aktuelle binutils einsetzen, weil hier die Reparaturarbeiten für Meltdown und Spectre stattfinden. Trotzdem nochmal die Empfehlung: erst mal ein "stable" LFS bauen und danach als Steigerung auf "development" umsteigen.

Typisches Problem beim Kompilieren:
  • ein C-Programm verwendet Datentypen, die jetzt in einer neu eingeführten include-Datei <stdint.h> deklariert werden und nicht mehr in <stdlib.h>. Vorläufig muss man also irgendwo den zusätzlichen include-Befehl unterbringen, bevor das Programm erfolgreich kompiliert werden kann. Freundlicherweise sagt make sehr genau, wo ein Problem aufgetreten ist.
  • beim Korrigieren eines Problems hat man Dateien oder Verzeichnisse als root editiert oder bearbeitet. Das führt zu einem Folgefehler, weil LFS alles mit dem Benutzer "lfs" durchführen will und dann ein Abbruch wegen Berechtigungsproblemen passieren kann (bringe ich laufend fertig).
    chown lfs:lfs is your friend.
Was mir noch untergekommen ist:
  • das gcc-interne Makro __sigemptyset gibt es nicht mehr. Man kann stattdessen sigemptyset (ohne die Unterstriche) verwenden.
  • die Makros major und minor für Devices sind jetzt in <sys/sysmacros.h> zu finden.
  • grub lässt sich mit binutils 2.30 auf 32-bit-Systemen nicht übersetzen, man muss zusätzlich zu den configure-Switches im LFS-Buch noch den Switch "--enable-64-bit-bfd" angeben. Alternativ binutils 2.29.1 statt 2.30 verwenden.
Zwei Schritte sind im LFS-Buch etwas vage beschrieben, weil sie sehr stark vom eigenen PC abhängen: die Konfiguration des Kernels und die bootfähige Festplatte. Wenn man ein Linux-Gastsystem mit "kernelconfig"-Unterstützung hat, kann man sich selbst einen maßgeschneiderten Kernel bauen mit "make oldconfig", das verwendet dann nämlich genau die Einstellungen, die im Moment aktuell sind.

Der einzige wichtige Punkt ist, dass das Filesystemformat des Bootlaufwerks in den Kernel fest kompiliert sein soll. Es nutzt nichts, wenn das Root-Filesystem mit ext4 formatiert ist und der Kernel die ext4-Fähigkeit erst mit einem Modul lernen soll, das auf der ext4-Festplatte liegt - hier beißt sich die Katze in den Schwanz. Ach ja: nach dem Kompilieren von Kernel und Modulen unbedingt in der chroot-Shell "make modules_install" durchführen und in /lib/modules kontrollieren!

Für spätere Bildungs- und Forschungszwecke kann man natürlich auch eine "initiale Ramdisk" (initrd) vorsehen und dort benötigte Module und sonstige Files ablegen, aber wenn man sich einen maßgeschneiderten Kernel für diesen speziellen PC erzeugt, ist das erst mal nicht nötig. Man kann es später machen, um Microcode-Updates per "early load" zu aktivieren, aber lebensnotwendig ist es erst mal nicht. Für intel-Prozessoren gibt es hier die Microcode-Dateien.

Vor dem Reboot sollte man dann im neuen /etc-Verzeichnis (das derzeit noch /mnt/lfs/etc heißt) nach Dateien schauen, die ein "**EDITME**" enthalten. Dort kann man dann Hostname, IP-Adresse, Nameserver etc. einbauen, die zur eigenen Umgebung passen (wenn man keinen eigenen DNS-Server betreibt, die IP-Adresse des DSL-Routers, der als DNS-Forwarder die Anfragen an den Provider weiterreicht). Die Dateien findet man mit einem beherzten "grep -l EDITME /mnt/lfs/etc/*", und wenn man gleich auf einen Schwung alle bearbeiten will, wirft man die Liste der Ergebnisse einfach einem Editor vor: "vi $(grep -l EDITME /mnt/lfs/etc/*)".

Die wichtigste Datei ist hier die /etc/fstab, die beschreibt, welche Partition der Festplatte welchen Zweck hat und wohin im Filesystem gehört. Eine Swappartition sollte man auf jeden Fall vorsehen, selbst wenn der PC gefühlt genug RAM eingebaut hat. Eine Begründung dafür findet sich hier (der Autor des Artikels arbeitet bei Facebook in einem Rechenzentrum). Früher gab es mal eine Regel "doppelt soviel Swap wie RAM", aber ich würde prinzipiell für normale Desktopsysteme zwischen 2 und 8 GB Swap vorsehen.

Was man auf keinen Fall vergessen darf: dem root-User des neuen LFS-Systems vor dem Reboot ein Passwort zu geben. Sonst kann man zwar wunderbar booten, aber sich nicht anmelden ;-)

Ganz ehrlich: das Gefühl ist unbeschreiblich, wenn das selbstkompilierte Linux dann tatsächlich zum ersten Mal bootet und man den Loginprompt sieht ;-)

Wenn das neue System nicht booten will, muss man Ursachenforschung betreiben. Ein "kernel panic" tritt auf, wenn das Root-Filesystem nicht gefunden wurde. Vermutlich fehlt dann das Kernelmodul für das betreffende Filesystem. Oder die Angabe in der /boot/grub/grub.cfg passt nicht, welche Partition das ist. Die Schreibweise von grub und Linux unterscheiden sich hier leider etwas. "sda" für Linux ist "hd0" in grub.

Ein Fehler, den ich mal gemacht habe: alle USB-Treiber als Module deklariert und dann nicht in /etc/modules definiert. In dieser Situation wird es für eine USB-Tastatur schwierig, ihre Eingaben abzuliefern :-).

In solchen Situationen bootet man dann erneut das Gastsystem, mountet die LFS-Partition wieder unter /mnt/lfs und fängt an zu reparieren.

Wenn es bootet und man sich anmelden kann, ist das Reparieren leichter: die Fehlermeldungen z.B. der init-Skripte stehen ja noch auf dem Bildschirm, und man kann Schritt für Schritt alles Nötige korrigieren und das neue, selbstgebaute Linuxsystem einrichten. Das LFS hat schon alles an Bord, um eigenständig Pakete zu übersetzen und zu installieren.

Nach dem erfolgreichen LFS geht es dann mit dem BLFS weiter.
Ein paar Vorschläge, wie man sich das LFS etwas bequemer bedienbar gestaltet:
  • gpm (copy+paste mit Maus in der Textoberfläche)
  • cpio (zum Bauen von initrd)
  • openssl (ssl-Bibliothek)
  • openssh (ssh server und client)
  • dhcpcd (IP-Adresse über DHCP setzen lassen)
  • nfs-utils (wenn man ein NAS hat, z.B. eine Fritzbox, oder selbst bauen will)
  • samba (wenn man selbst ein NAS aufbauen will oder einen Windows-Domaincontroller)
  • lm_sensors (Hardwareüberwachung von CPU und Lüfter)
  • lsusb (list USB devices)
  • lspci (list PCI devices)
  • ghostscript (für PDF)
  • cups (zum Drucken)
  • Firefox (für Katzenvideos im Internet)

13.12.2017

Flash-Update auf Version 28

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 28 (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 https_proxy=http://192.168.100.100:3128/
set VNP=28.0.0.161
set VAX=28.0.0.161
set V=28
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

# https_proxy=http://192.168.100.100:3128/

VL=${1:-
28.0.0.161}
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".

[20171213: Security Bulletin von Adobe]
[20180110: Security Bulletin von Adobe]

10.10.2017

Nerviges beim Autofahren - 5

Ein spezielles Erlebnis hatte ich neulich, als ich Kind 2 von der Ferienfreizeit abholen wollte. Das passte jetzt nicht mehr thematisch zum Thema im vorigen Gemecker, deshalb habe ich direkt einen neuen Beitrag angefangen. Kurz erwähnt hatte ich das Verhalten mit dem zu großen Ego schon früher, aber diesmal ist es mir so krass aufgefallen, dass ich nochmal drüber schreiben wollte. Die früheren Texte gibt es als Teil 1 und Teil 2 und Teil 3 und Teil 4 hier im Blog.

Es begab sich also zu der Zeit, dass das Kind nach dem Ende der Freizeit mit dem Bus in Limburg ankommen sollte und der Vater sich rechtzeitig vorher auf den Weg machen musste, wie es die Kaiserin angeordnet hatte.

Die Ferienfreizeit nach England hatte nur 2 Möglichkeiten zum Zusteigen bzw. Abholen - Limburg und Frankfurt. Aus Gründen hatten wir uns entschieden, nach Limburg zu fahren.

Für die Fahrt nach Limburg benutze ich die A45 bis Wetzlar und dann die Bundesstraße, die eigentlich recht gut ausgebaut ist. Abgesehen von gelegentlichen Baustellen und noch nicht fertig gestellten Abzweigungen etc.

Nach dem Auffahren hatte ich die Autobahn ganz für mich allein - das war nett ;-). Nach ein paar Kilometern hatte ich einen PKW mit Anhänger vor mir, der gerade am Überholen war. Kein Problem, das war lang vorher abzusehen und ich fuhr ganz normal hinter ihm her, um abzuwarten, bis er fertig war.

In der Zwischenzeit tauchte hinter mir ein dicker Geländewagen auf (neudeutsch "SUV"), der sehr dicht auffuhr. Das war aber kein Grund für mich, meinen Sicherheitsabstand zu verringern. Das war dem Fahrer (oder der Fahrerin ...) wohl auch klar und der SUV fing an, nach rechts zu pendeln und wieder zurück nach links. Es war offensichtlich, dass ich ein Hindernis für ihn darstellte war und der Fahrer die Erwartung hatte, dass ich nach rechts wechseln sollte. Einmal hatte ich sogar den Verdacht, er würde mich rechts überholen wollen.

In der Zwischenzeit hatte aber der PKW mit dem Anhänger den LKW überholt und ich gab einfach Gas. Das kleine Spaßauto (mit 2-Liter-Turbomotor) wird gern mal unterschätzt, und ich gebe zu, dass ich vom Verhalten des Fahrers hinter mir ziemlich genervt war.

Nachdem ich die beiden Fahrzeuge überholt hatte, fuhr ich nach rechts und dann weiter. Der Audi Q7 blieb auf der linken Spur und hatte offensichtlich den Plan, mich zu überholen. Dummerweise hatte er offensichtlich zuwenig Leistung oder zuviel Luftwiderstand, und er blieb recht deutlich hinter mir zurück, und auch nach der nächsten Kurve dauerte es ziemlich lang, bis er dann hinter mir "um die Ecke" wieder zu sehen war. Ganz offensichtlich war es also kein V8-Modell, dem ich davonfahren konnte (der TFSI-Benziner ist als V8 mit 244 km/h angegeben, als 4.2 TDI Diesel mit 243 km/h), sondern ein Q7 mit einem kleineren Motor. Tja, selbst schuld. Beim nächsten Autokauf in Bottrop also mal lieber den größeren Motor bestellen, wenn es Audi und die Dieselmodelle dann noch geben sollte.

Dieses Spiel wiederholte sich noch mehrfach bis hinter Gießen - ich blieb mit Sicherheitsabstand hinter einem überholenden Fahrzeug vor mir, der SUV konnte aufholen, fuhr jedesmal sehr dicht auf und erwartete trotz bisheriger schlechter Erfahrungen, dass ich ihm Platz machen müsste. Jedes Mal, wenn die Autobahn wieder frei war, gab ich Gas und er schaffte es nicht, mich zu überholen - und zwar deutlich, der SUV war regelmäßig weit hinter mir. Es gab kein "Elefantenrennen" wie bei LKWs, bei dem wir fast gleich schnell nebeneinander fuhren.

Ich will mich hier natürlich auch nicht von Schuld freisprechen, das gebe ich zu. Ich hätte ja auch nachgeben und ihn überholen lassen können. Andererseits - warum sollte ich ein Auto vorbeilassen, nur weil es in einer Schlange drängelt? Ich konnte und wollte schnell(er) fahren als er, und ich bin mir sicher, dass er mich auch auf freier Strecke nicht wieder hätte überholen lassen. Er wollte unbedingt an mir vorbei, und nach dem bisherigen Verhalten zu schließen wollte er dann diesen "Triumph" nicht wieder aufgeben. Das ist ungefähr dieselbe Sorte Ego-Problem wie die Autofahrer, die beim Reißverschlussverfahren die andere Spur nicht einfädeln lassen.

Endlich (für den SUV ...) kamen wir zu den zwei Baustellenstücken kurz vor Wetzlar. Ich fuhr nach wie vor rechts, der SUV hinter mir musste mich unbedingt überholen und rauschte mit geschätztem Tempo 130 auf der linken Spur in die Baustelle (die Schilder zeigten die üblichen 100 und dann 80 an ...). Nach der Baustelle musste er es mir richtig zeigen und fuhr links mit "nur" 120 weiter, obwohl die rechte Spur frei war. Aber der Fahrer wollte mir wohl unbedingt zeigen, wie grausam es ist, wenn man überholen will und nicht kann. Er sollte aber lieber sein schwächliches Auto dafür verantwortlich machen, dass er mich nicht überholen konnte - ich fahre konsequent rechts, sobald es möglich ist. Aber der SUV konnte nicht aufholen, geschweige denn überholen ...

Hier sieht man leider deutlich, dass die meisten Autofahrer viel zu emotional fahren - der SUV drängelt mehrfach, missachtet den Sicherheitsabstand, ignoriert das Tempolimit in der Baustelle und überholt mit viel zu hoher Geschwindigkeit, und danach begeht er eine Nötigung und verstößt gegen das Rechtsfahrgebot. Außerdem ist ihm nicht klar, dass sein Auto breiter als 2 m ist und er in der Baustelle gar nicht links fahren darf (Audi Q7 Breite ohne Spiegel 1.98m, mit Spiegel 2.18m). Abgesehen davon, dass ihm gar nicht bewusst zu sein scheint, dass ich die ganze Zeit schneller fuhr als er. Er wollte unbedingt überholen, auch mit dem Risiko von Verkehrsverstößen und dem massiv erhöhten Risiko von Unfällen durch sein Verhalten.

Leider wird viel zu wenig kontrolliert. Über den Verlauf von knapp 30 km war das nicht nur ein Regelverstoß, den die Rennleitung in grün (oder mittlerweile blau) eigentlich gern hätte notieren können. Ich finde Sicherheitsabstand außerordentlich wichtig - wenn das Fahrzeug vor mir bremst, habe ich gern genug Platz und Zeit zum Reagieren. Mein kleines Spaßauto hat einen sportlichen Motor und dazu passende sportliche Bremsen. Dummerweise ist es trotzdem mein Auto, das kaputtgeht, wenn der Idiot hinter mir so dicht aufgefahren war, dass er nicht rechtzeitig bremsen konnte und mir rein knallt.

25.09.2017

LineageOS ist eine tolle Sache

Ich habe ja schon einige Beiträge dazu geschrieben, wie toll ich es finde, dass alte Smartphone-Modelle immer noch Software-Updates bekommen, wenn man vom Original-ROM des Herstellers auf ein sogenanntes "Custom ROM" wechselt.

Diese Beiträge (für Modelle von Samsung, Motorola, LG und Google) waren bislang eher technisch. Ich möchte aber auch gern mal eher prinzipiell über die Vorteile eines aktuellen Custom ROMs schreiben.

Ich gebe zu, dass ich eher ein paranoider Mensch bin, der die Nachrichtenmeldungen über Datenverluste, Trojanerangriffe, Virusausbreitung usw. beunruhigt zur Kenntnis nimmt. Deswegen bin ich auch immer sehr bemüht, meine Software aktuell zu halten und alle Updates einzuspielen. Mit aktueller Software kann man das Risiko, Opfer eines Angriffs zu werden, enorm verringern. Diese Tatsache kann man gar nicht oft genug aussprechen!

Das Besondere an diesen Custom ROMs ist: sie sind fast immer fast genauso aktuell wie Google die neuen Android-Versionen und die Sicherheitsupdates veröffentlicht. Nach einer neuen Android-Version dauert es vielleicht ein paar Wochen und auch nicht für alle Modelle gleichzeitig, aber mit ein bißchen Geduld hat man dann wieder das allerneueste Android auf seinem Smartphone. Die einzige derzeitige Ausnahme ist das Samsung Galaxy Nexus. Für dieses Modell gibt es nicht LineageOS 14.1 "Nougat" (Android 7), sondern "nur" 13.0 "Marshmallow" (Android 6). Aber selbst das ist bemerkenswert, wenn ich überlege, dass es von Google nur bis Jellybean (4.3) offiziell mit Software versorgt wurde. Man muss nicht immer das allerneueste Betriebssystem haben - aber die Sicherheitsupdates sind enorm wichtig, und die liefert LineageOS auch bei diesem Modell.

[20171023] Aktueller Nachtrag: LineageOS hat die Patches für KRACK am 16. Oktober integriert.

Die meisten Smartphones gehören mittlerweile ins Billig- und Discounter-Segment. Ich will damit nicht die Qualität des Geräts schlechtreden, aber der Hersteller spart dann bei der Softwarequalität und vor allem in der Pflege des Geräts nach dem Kauf. Bei einem Handy für 99€ kann man nach dem Kauf keinerlei Software-Updates mehr erwarten. Generell sollte man lieber etwas mehr investieren und darauf achten, dass der Hersteller die Dauer der Updates nach dem Kauf ausdrücklich erwähnt. Nokia ist hier mit den neueren Geräten (Nokia 3, 5, 6 und 8 mit Android) eine rühmliche Ausnahme, genau wie Google selbst mit den (früheren) Nexus- und jetzigen Pixel-Geräten. Hier weiß man, dass es Updates geben wird. Bei anderen Herstellern hängt der Preis unmittelbar mit der Updatelieferung zusammen: die Top-Geräte bekommen vermutlich noch das eine oder andere Update (z.B. Galaxy S7, S8), die billigeren oder älteren Geräte dann schon wieder nicht mehr.

Eine weitere Möglichkeit, die nebenbei auch noch gut für die Umwelt ist, könnte sein, dass man auf ein Neugerät verzichtet und bei einem Händler ein gebrauchtes Gerät sucht, für das es ein Custom ROM gibt. So mache ich es seit langem: erst überlege ich, welche Eigenschaften mein zukünftiges Smartphone haben soll (Speicher, Displaygröße, Displayauflösung in Pixel, Kamera), und dann informiere ich mich bei download.lineageos.org, für welche Geräte es dort ein ROM gibt. Danach suche ich bei Händlern wie rebuy.de oder bei ebay.de ein solches gut erhaltenes Gerät.

Kauf bei einem (deutschen) Händler hat den Vorteil, dass man auf das gebrauchte Gerät immerhin noch 12 Monate Gewährleistung bekommt, die der Händler auch nicht wegdiskutieren kann. Auf diese Weise habe ich kürzlich ein Google Nexus 5 für mich und die Schwiegermutter gekauft, ein Nexus 6 für Kind 2, und ein LG G4 für die beste Ehefrau von allen. Ein gern verwendetes Argument gegen gebrauchte Handys kann ich empirisch von meinen eigenen gekauften Geräten nicht bestätigen: die Akkus sind alle akzeptabel gewesen. Für das G4 mit wechselbarem Akku habe ich einen Ersatzakku gekauft, aber mehr aus Bequemlichkeit.

Nur Kind 1 fällt vollkommen aus dem Rahmen: sie will Geräte von Apple. Technisch finde ich das ok, weil sowohl die Geräte konstruktiv gut sind, als auch Updates für lange Zeit gesichert sind. Auf dem Retina-MacBook läuft das aktuellste OS X, und das iPhone erhält immer noch die iOS-Updates. Über die Geschäftspolitik von Apple und die Steuervermeidungsstrategien kann ich nur den Kopf schütteln, aber technisch habe ich wenig auszusetzen. Die Reparaturmöglichkeiten bei Apple sind laut iFixit.com durchwachsen: manche Geräte lassen sich sehr gut reparieren, andere sind verklebt und gelötet, so dass Aufrüsten oder Instandsetzen nur schwer möglich sind.

Zurück zu Android: an diesem Punkt angelangt und ein Modell ausgesucht und gekauft. Nun hat man also ein Gerät, für das es ein Custom ROM gibt, und dann kann man loslegen, das Hersteller-ROM durch ein Custom ROM zu ersetzen. Darauf will ich jetzt an dieser Stelle nicht mehr eingehen, es gibt ein paar ältere Beiträge, in denen ich das Entsperren und Flashen eines Custom ROMs beschrieben habe (Samsung Galaxy S, Galaxy S+, Galaxy S2, Galaxy Nexus, LG G4). Ich finde es einfach großartig, dass es Software-Entwickler gibt, die in ihrer Freizeit die von Google freigegebene Android-Software auf andere Smartphone-Modelle anpassen und weiter pflegen.

Insbesondere bekommt man auf diese Weise die Android-Security-Updates, die Google seit den schwerwiegenden Fehlern in den Medienbibliotheken monatlich entwickelt und im "Android Open Source Project" (AOSP) veröffentlicht. Erwähnenswert ist auch noch, dass die reinen Android-Updates auch für alte Versionen bis zurück zu 4.4 dort abgelegt werden. Was leider nicht gemacht wird: Google erstellt selbst keine installierbaren Pakete mehr; deshalb gibt es für das Nexus 5 z.B. auch keinerlei Updates mehr (das sogenannte "end of life" bei Google-Geräten bedeutet, dass man zwei Jahre lang alle Updates bekommt, auch neue Androidversionen, und danach noch ein weiteres Jahr Security-Updates).

Und was auch nicht gemacht wird: für jedes Smartphone-Modell müsste man neben dem eigentlichen Android noch höchst spezifische Linux-Kernelupdates pflegen, und das macht Google leider nicht für alte Geräte. Außerdem kann es passieren, dass ein CPU-Hersteller den Support für einen CPU-Chip einstellt. Dann kann sich Google auf den Kopf stellen, aber es ist nicht mehr möglich, Updates für den Kernel zu erstellen.

So ist das leider beim Galaxy Nexus geschehen: es hat eine CPU von Texas Instruments (OMAP), und TI hat sich aus dem Geschäft mit Smartphone-CPUs komplett zurückgezogen. Dummerweise sind die Unterlagen nicht öffentlich, so dass auch niemand sonst die Arbeit übernehmen kann. Das ist schlecht, weil üblicherweise in diesen CPU-Chips auch WLAN, Bluetooth, LTE oder andere Funktionen integriert sind, die eigene Software enthalten, die sogenannte Firmware. Genau wie jede andere Software können auch hier Programmierfehler und Sicherheitslücken enthalten sein!

Um Mißverständnissen vorzubeugen: die öffentlichen Updates für den Linuxkernel kann man natürlich bekommen oder selbst einpflegen. Falls aber ein Fehler in der Firmware bekannt würde, könnte man den nicht beheben. Diese Firmware wird in Form von Binärpaketen beim Starten vom Kernel in den Spezialchip geladen (für WLAN, Bluetooth, LTE, Kamera, was auch immer), und neue Binärpakete gibt es vom Chiphersteller leider nicht. Nebenbei gibt es eine nicht ganz vollständige Liste als Überblick, welche Android-Version mit welcher Kernelversion ausgeliefert wird. Google macht hierzu seit einiger Zeit sogar bestimmte Vorgaben, welche Kernelversion es mindestens sein muss.

Wenn aus Gründen gar kein Software-Update (mehr) möglich ist, ist die letzte Konsequenz dann eben, dem Gerät den Internetzugang zu sperren. Letzteres passierte bei uns 2014, nachdem Microsoft die Updates für Windows XP einstellte - die PCs, auf denen eine spezielle Software für die Tierarztpraxis läuft, dürfen jetzt einfach nicht mehr ins Internet und damit gibt es auch keine Infektionsgefahr mehr. Die Software läuft gut, sie würde auf einem neueren Windows nicht mehr laufen, und die PCs wären auch nicht wirklich gut gerüstet für eine neuere Windowsversion - warum also sollte ich Windows updaten? Für den Internet-Zugang gibt es seitdem einen PC mit Linux, für den es - natürlich - Updates gibt.

Ältere Smartphones ohne Updatemöglichkeit kann man dann immer noch als lokale Medienspieler oder für andere Zwecke einsetzen oder selbst gebraucht verkaufen. Internetzugang für ein Smartphone sperren ist in meiner kleinen Welt ganz einfach: ich entferne die private WLAN-IP-Adresse des Geräts aus meinem Firewall, und wenn keine SIM-Karte drinsteckt, war's das mit dem Internetzugang. Bei weniger paranoiden Menschen müsste man umgekehrt die Nummer des Geräts aktiv in der Fritzbox (o.ä. Router ...) sperren. Vor der finalen Sperre sollte man natürlich alle Apps installieren, die man auf dem Gerät weiterverwenden will.

Ich habe eigentlich gar nicht die Befürchtung, dass ich persönlich von bösen Menschen von irgendwoher angegriffen werde - die Gefahr ist einfach, dass ein breit gestreuter Angriff mich auch erwischt. Die bösen Buben haben es darauf abgesehen, entweder Drohnen einzufangen, mit denen dann Denial-of-Service-Angriffe (Lahmlegen des angegriffenen Ziels) getätigt werden, oder die Opfer zu erpressen, indem ihr Gerät verschlüsselt wird und für die vermeintliche Entschlüsselung Geld verlangt wird. Die Wahrscheinlichkeit, dass mich persönlich irgend jemand angreift, ist verschwindend gering - dazu bin ich nicht wichtig genug.

Angriffe geschehen häufig über Schwachstellen im Browser, durch die eine Schadsoftware "ausbrechen" und mit Hilfe einer weiteren Sicherheitslücke im Betriebssystem böse Dinge tun kann - entweder unmittelbar oder indem sie sich dauerhaft einnistet. Deshalb ist es besonders wichtig, das Betriebssystem, den Browser und eventuelle Hilfspakete im Browser ("Addons", "Extensions", "Plugins"), z.B. Flash, immer aktuell zu halten. Dazu sollte man das "automatische Update" einschalten, sofern vorhanden, oder zumindest regelmäßig nach Updates suchen. Dabei ist es wichtig, das Update nur direkt vom Hersteller herunterzuladen und nicht von irgendwelchen Downloadseiten. Dort kann man weder sicher sein, dass es wirklich die aktuellste Version ist, noch, dass nicht jemand das Update manipuliert hat und man sich gerade mit dem Update eine Schadsoftware einhandelt.

Solche Schadsoftware wird auch gern mal als Werbung im Browser-Fenster ausgespielt. Mittlerweile halte ich einen Adblocker (Werbeblocker) im Browser für unverzichtbar (ich verwende "uBlock origin"). Die Website-Betreiber haben die Kontrolle über die ausgespielte Werbung vollkommen abgegeben - es gibt Dienstleister, die dann wiederum an Subunternehmer Aufträge vergeben oder die Werbefläche sogar in automatisierten Auktionen "live" versteigern.

Noch relativ selten nehmen auch die Angriffe über Office-Dokumente wieder zu. Das war vor 10-15 Jahren ein großes Problem, weil in den üblichen Office-Programmen auch eine Programmiersprache enthalten ist, die nicht nur Dokumente automatisieren kann, sondern auch das Betriebssystem ansprechen kann (Visual Basic und Office-Makros mit Autostart-Funktion). Mittlerweile muss man diese Makros ausdrücklich einschalten, wenn man sie benötigt. Manche Angriffe bitten den Anwender deshalb genau darum - "Bitte erlauben Sie Makros, damit ich als Virus meine Arbeit erledigen kann. Vielen Dank!".

Eine weitere Angriffsmöglichkeit sind echt aussehende gefälschte Emails, in denen man auf einen Link klicken soll. Gern genommen werden hier Emails mit einem Drohpotenzial, z.B. indem mit der Sperrung des Bankkontos oder Nutzerkontos gedroht wird und Zeitdruck erzeugt wird. Entweder wird dann die Eingabe von persönlichen Daten auf einer Webseite verlangt, oder allein durch das Anklicken des Links in der Email hat man sich schon infiziert. In diesen Mails wird häufig behauptet, dass man nur sehr wenig Zeit habe zu reagieren, bevor das Konto ganz gesperrt wird, oder ähnlich vermeintlich empfindliche Konsequenzen. Damit soll verhindert werden, dass man sich die Mail genauer anschaut oder recherchiert, z.B. dort anruft und direkt nachfragt.

Gefälschte Emails stammen dann angeblich vom Emailprovider wie GMX, 1&1, web.de, oder von einem Internetversandhändler, z.B. Amazon, oder von einer Bank, in letzter Zeit hatte ich z.B. häufig solche "Phishing"-Mails von der Deutschen Bank, aber auch von diversen Sparkassen und Volksbanken. Diese Mails sind natürlich durchschaubar, wenn man dort gar nicht Kunde ist. "Phishing" ist übrigens ein englisches Kunstwort, das aus den Worten "Password" und "fishing" zusammengesetzt ist, d.h. jemand versucht dort mit Tricks, ein Passwort zu ergaunern.

Man kann solche Mails i.a. erkennen, indem man mit dem Mauszeiger über den Link fährt (aber natürlich nicht anklickt!) und üblicherweise erscheint dann in der Fußzeile des Emailprogramms der volle Name des Links, zu dem man gehen soll. Wenn dort nicht der richtige Name der Firma erscheint, sondern irgend etwas ähnliches (manchmal auch nicht mal das) oder ein Abkürzungsdienst wie bit.ly, goo.gl etc., dann ist es zu 120% eine Phishing-Mail, auf die man nicht reagieren sollte.

Manche Firmen haben mittlerweile eine eigene Schädlingsbekämpfungsabteilung eingerichtet, an die man solche Mails weiterleiten kann. Wenn gefälschte Emails angeblich von amazon kommen, kann man diese Email an spoof@amazon.com weiterleiten. Andere Firmen haben eine Emailadresse der Form abuse@firma.com ("abuse" = "Mißbrauch") eingerichtet. Leider ist das nicht einheitlich, und es funktioniert auch nicht bei allen Firmen. Aber es kann einen Versuch wert sein, hier aktiv zu werden und wenigstens im Kleinen etwas zu unternehmen.

Mittlerweile schlagen auch Spam- und Phishing-Nachrichten in Messenger-Apps auf dem Smartphone auf. WhatsApp ist mittlerweile sehr beliebt bei bösen Buben. WhatsApp weist zwar darauf hin, dass der Absender nicht im Adressbuch ist, aber der Link in der Nachricht ist trotzdem anwählbar, wenn man die Nachricht anschaut. Leider gibt es Schadsoftware, die extrem ausgefeilt ist und sich dann dauerhaft im Smartphone einnistet. Dabei werden dieselben Tricks verwendet, die man auch zum "Rooten" oder "Jailbreak" des Handys verwendet - die Schadsoftware hat dann volle Administratorrechte, was manchmal mehr ist als der Besitzer selbst ...

Nach diesem etwas ausführlicheren Exkurs in die Welt der Schädlinge nochmals mein Fazit: auch mit einem Smartphone-Modell vom Vorjahr kann man gut leben. Die Geräte sind mittlerweile genau wie PCs so leistungsfähig, dass man nicht mehr das Topmodell haben muss, um vernünftig damit zu arbeiten. Software-Updates sind enorm wichtig, gerade weil diese Sorte Geräte dafür konzipiert sind, immer online und aktiv zu sein. Mit UMTS oder LTE sind sie recht breitbandig angebunden, d.h. ihr Internetzugang ist ziemlich schnell, und das alles in Summe ist ein sehr attraktives Ziel für Bösewichte, aus diesem "Internet in der Hosentasche" eine ferngesteuerte Drohne mit schädlicher Nutzlast zu machen. Ein Custom-ROM wie LineageOS kann hier Wunder wirken und das Gerät noch über Jahre hinweg aktuell halten.

13.09.2017

Flash-Update auf Version 27

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 27 (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 https_proxy=http://192.168.100.100:3128/
set VNP=27.0.0.187
set VAX=27.0.0.187
set V=27
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

# https_proxy=http://192.168.100.100:3128/

VL=${1:-
27.0.0.187}
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".

[20170913: Security Bulletin von Adobe]
[20171023: Security Bulletin von Adobe]
[20171115: Security Bulletin von Adobe]

12.08.2017

Nerviges beim Autofahren - 4

Willkommen zum nächsten Teil meines Gemeckers über andere Autofahrer ;). Die früheren Texte gibt es als Teil 1 und Teil 2 und Teil 3 hier im Blog.

Ich schrieb ja schon früher, dass ich die meisten Verkehrsregeln und -schilder befolge, weil ich davon ausgehe, dass sie üblicherweise an dieser Stelle einen Sinn haben. Klar gibt es auch Schilder, von denen ich denke, dass sie sinnlos oder übertrieben vorsichtig sind - da mir aber mein Führerschein lieb und teuer ist, befolge ich auch die. Aber auch hier gilt mittlerweile das "cover your ass"-Prinzip: die Strassenverkehrsbehörden (bei uns in der Region z.B. Hessen Mobil) wollen sicherstellen, dass ihnen niemand eine Mitschuld gibt, weil irgendwo ein Schild fehlt (hier nähern wir uns ein bißchen den Amerikanern mit ihren verrückten Gesetzen zum Schadenersatz).

Generell halte ich es für selbstverständlich, auch aus Rücksicht gegenüber den anderen Verkehrsteilnehmern, sich an die Regeln zu halten, und ich erwarte genau dasselbe von allen anderen. Dadurch wird der Ablauf nämlich erwartbar und somit verringert sich das Unfallrisiko. Das heißt nicht, dass ich durch die Gegend schleiche - ich gebe zu, dass ich gern schnell fahre - allerdings nur, wenn die Situation es zulässt (Autobahn frei ...).

Kürzlich bekam ich Anmerkungen zum ersten Teil dieser Reihe. Der Kommentator schlug mir als Thema vor, nochmals auf das Thema "Blinken" einzugehen. Ich hatte zwar schon mal kurz darüber geschrieben, aber den Fokus nur auf das gefährliche Spurwechseln ohne Blinken auf der Autobahn gelegt.

Aber natürlich ist es immer wichtig, zu blinken. Das Blinken ist ja nicht für sich selbst wichtig, sondern hauptsächlich dazu gedacht, die anderen Verkehrsteilnehmer frühzeitig darauf hinzuweisen, dass gleich irgend etwas beabsichtigt ist. Und wenn ich weiß, dass sich gleich die Situation ändert, kann ich mich darauf einstellen und z.B. etwas mehr Abstand halten oder bremsen.

Die Betonung liegt hier ausdrücklich auf "frühzeitig"! Viele Autofahrer fangen nämlich auch erst an zu blinken, wenn sie schon mitten im Spurwechsel oder beim Abbiegen sind. Ich glaube ja, dass bei den meisten Fahrern die Finger fest am Lenkrad bleiben und beim Drehen des Lenkrads einfach der Finger ausgestreckt wird, um genau dann den Blinker einzuschalten.

Ein Verwandter meiner Schwiegermutter hat diese Angewohnheit: er wechselt auf eine Abbiegespur, und ganz vorn an der weißen Markierung, Sekundenbruchteile vor dem Abbiegen, schaltet er erst den Blinker an. Das ist natürlich vollkommen sinnlos, weil die anderen Autofahrer schon längst wissen, was er vorhat und der eigentliche Sinn des Blinkens total verloren geht.

Nebenbei ist so ein Verhalten katastrophal, wenn man mit mehreren Autos Kolonne fährt und der Vordermann nicht rechtzeitig anzeigt, wohin es geht, oder nicht darauf achtet, ob der Nachfolgende auch wirklich folgen kann. In dieser Situation wäre es vollkommen schwachsinnig, an einer gelben Ampel noch durchzurutschen oder sogar extra Gas geben und damit den Hintermann abzuhängen.

Mich juckt es jedesmal in den Fingern, jemanden darauf hinzuweisen, dass seine Blinker vermutlich defekt sein müssen, wenn ich hinter einem Auto herfahre, das so gar nicht blinkt, weder links noch rechts.

Ganz doof ist es auch bei denen, die die "abknickende Vorfahrt" nicht verstehen und nicht oder falsch blinken. Wer hier falsch blinkt, kann sogar eine Teilschuld bei einem eventuellen Unfall bekommen!

Zum Thema "defekte Birnen" habe ich auch noch eine Anekdote, die schon ziemlich lang her ist, aber mir aufgrund der Unverfrorenheit - ich würde sogar "Dummheit" dazu sagen - der Fahrerin immer noch gut im Gedächtnis geblieben ist.

Ich fuhr hinter einem anderen Auto von Friedberg nach Hause und wunderte mich, dass das Auto vor mir scheinbar nie bremsen musste. Nicht mal am Ortsschild von Dorheim, oder an der Einmündung zur B455 haben die Bremsleuchten aufgeleuchtet (damals war die Straße von Fauerbach nach Dorheim noch nicht die Vorfahrtsstraße wie jetzt nach dem Bau der Umgehungsstraße). Zufällig mussten wir dann alle an der Bahnschranke warten und ich dachte, dass ich den Autofahrer vor mir warnen sollte. Ich stieg aus und wies die Fahrerin vor mir darauf hin, dass ich vermutete, ihre Bremsleuchten seien beide kaputt. Ihre Antwort verschlug mir die Sprache: "Ach, die zweite jetzt auch? Neulich hat mir schon mal jemand gesagt, dass eine Bremsleuchte kaputt ist". Ich konnte nichts mehr sagen und stieg einfach wieder in mein Auto ein.

10.08.2017

Alles nicht so schlimm - Leserbrief

Die Wetterauer Zeitung und die Schwesterausgabe Gießener Allgemeine haben ein Interview mit Prof. Breuer von der THM veröffentlich. Der Tenor dieses Interviews ist "war doch alles nicht so schlimm" und die "die Industrie nutzt nur die vorhandenen Regeln aus". Das Interview ist online lesbar.
Diese Beurteilung der Situation halte ich für völlig daneben und habe einen Leserbrief dazu geschrieben.
Änderungen der WZ in blau bzw. Auslassungen in rot.

Merkwürdigerweise interpretiert die WZ den Leserbrief in der Bildunterschrift hauptsächlich so, als ob ich über die Auswirkungen auf Arbeitsplätze schreibe. Das war aber nur der i-Punkt meines Leserbriefs. Die Autoindustrie will jetzt erreichen, dass möglichst wenig Reaktionen vom Staat geschehen, z.B. keine Pflicht auf Umbauten u.ä., mit der Begründung, dass unglaublich viele Arbeitsplätze gefährdet sein könnten. Der Staat darf sich aber nicht mit dem Abbau von Arbeitsplätzen erpressen lassen. Sicherlich ist die Gefahr für die Autoindustrie groß - sie zerstört ja gerade systematisch weltweit das gute Image der deutschen Autoindustrie. Aber das darf nicht dazu führen, dass die Politik jetzt die Autoindustrie mit Samthandschuhen anfasst.
Herr Breuer, Sie stimmen im Interview ein in das Loblied der "ist ja alles nicht so schlimm"-Fraktion. Leider ist das nicht wirklich begründet.
Sie behaupten "die Autoindustrie hat die Regeln maximal interpretiert".
Ich würde es anders formulieren: die Autoindustrie hat über Lobbyismus die Regeln maximal aufgeweicht, um sie danach nochmals maximal zu ihren Gunsten zu interpretieren.
Wenn man Regeln nur "maximal interpretiert", würde das nicht Milliarden an Bußgeldern kosten und Manager ins Gefängnis bringen. Man sieht also deutlich, dass die Autoindustrie nicht nur interpretiert, sondern auch gegen Regeln konkret verstößt.
Ein Auto, dessen Katalysator nur von 20 bis 30 Grad Celsius eingeschaltet wird, ist bestimmt nicht im Sinne der Umwelt. Ein Konzern, der als Begründung liefert, dass die Regeln überhaupt nur für die Dauer des Prüfzyklus gelten, ist unglaublich arrogant. Ich dachte bislang, ein Gerät wird für die durchschnittliche Umgebung konstruiert, so dass es den größten Teil der Zeit funktionieren kann. Insbesondere müssen dem Käufer die Einschränkungen bewusst sein, damit er eine qualifizierte Entscheidung für oder gegen den Kauf treffen kann.
Stattdessen ist die Konstruktion darauf ausgelegt, möglichst oft gerade nicht eingeschaltet zu sein, damit nicht nachgetankt werden muss. Ich nenne das bewusste Täuschung des Verbrauchers durch Vorenthalten von Wissen über wesentliche Nachteile.
Wo wäre denn der Schmerz gewesen, dass man z.B. nach jedem 5. Tanken auch Adblue nachtanken muss? Stattdessen werden Kartelle gebildet, um in geheimen Absprachen ein maximales Volumen für den Adblue-Tank abzusprechen. Der gewonnene Platz wird auf Druck der Marketingabteilung für Schnickschnack verwendet, den man teurer verkaufen kann. Hätten diese Absprachen mal lieber dazu geführt, einen genormten Tankstutzen für Adblue einzuführen.
Mit ein bißchen chemischen Grundkenntnissen (Stöchiometrie) kann selbst ein Oberstufenschüler ausrechnen, wieviel Ammoniak benötigt wird, um die Abgase auf einen vorgegebenen Reinheitsgrad zu bringen. Darüberhinaus ist dem KBA sicherlich bekannt gewesen sein, dass bei LKW der Verbrauch von Harnstofflösung (Adblue) bei ca. 5 % des Spritverbrauchs liegt. Ich würde also sagen, die Zulassungsbehörden wollten betrogen werden.
Und Anfang der 2000er jammerte die Autoindustrie über Jahre hinweg, dass Russfilter und andere Reinigungsverfahren für Diesel in der Praxis nicht funktionieren können, und die Politik ist der willfährige Bremser in Brüssel.
Peugeot und Citroen haben Jahre vor den deutschen Herstellern gezeigt, dass es eben doch technisch möglich ist. Erst nach langem Zaudern haben die deutschen Hersteller nachgezogen und Reinigungsverfahren mit SCR und Adblue eingebaut, und dabei massiv getrickst.
Was in Zukunft vielleicht auch noch passieren wird: die Anlagefonds, die in Auto-Aktien investieren, könnten Schadenersatzklagen planen, wenn jetzt die Aktienkurse bei VW, BMW und Daimler fallen und fallen. Was mich als Deutschen noch besonders ärgert: durch Dummheit und Gier zahlt VW 20 Mrd. Dollar Strafzahlungen in die USA, die in Deutschland fehlen. Wo bleiben die Strafzahlungen in Deutschland? Was könnte man mit 20 Mrd. Forschungsgeldern erreichen?
Und bevor jetzt wieder die Schutzreflexe für die "vielen" Arbeitsplätze einsetzen, die angeblich an der Autoindustrie hängen: diese Mär hat der Spiegel schon 2009 entlarvt. Die Aussage "jeder 7. Arbeitsplatz" ist ein wohlfeiles Märchen des VDA, das natürlich für die Politik eine bequeme Ausrede ist. Effektiv ist es nicht mal jeder 20. Arbeitsplatz, der direkt oder indirekt von der Autoindustrie abhängig ist (Quelle: VCD). Der VDA rechnet z.B. sogar Taxi- und Busfahrer mit ein. Diese Jobs würden vermutlich auch existieren, wenn es überhaupt keine deutsche Autoindustrie gäbe. Da rund die Hälfte der deutschen Produktion sowieso ins Ausland geht, kann man diesen Anteil ebenfalls nicht zur Begründung von Subventionen und Bevorteilungen heranziehen.