17.04.2018

Leserbrief zur Diskussion über Impfpflicht

Tja nun, die WZ dachte sich wohl "wir brauchen mehr Klicks" und hat auf Facebook eine Diskussion angefangen über das Impfen und die Impfpflicht.
Wen wundert's - die Impfgegner gießen die üblichen Verschwörungstheorien und wilden Behauptungen in die Kommentare unter den Facebook-Beitrag.

Ein paar Tage danach folgt dann ein scheinheiliger Artikel in der gedruckten Ausgabe, der die Facebook-Kommentare zusammenzufassen versucht.
Garniert wird der Artikel von einem "Pro"- und einem "Kontra"-Kommentar von zwei Redakteuren der WZ.

Es ist absolut in Ordnung, dass jeder eine Meinung hat und sie auch äußern kann - aber wenn man zu einem Thema inkompetent ist, sollte man vielleicht einfach mal das Motto von Dieter Nuhr beherzigen ("wenn man keine Ahnung hat ..."). Insbesondere regt es mich unglaublich auf, wenn Impfgegner mit harten wissenschaftlichen Fakten konfrontiert werden und das mit einem Achselzucken abtun. Schade ist nur, dass die meisten Impfgegner eine starke Meinung haben und keinerlei Hemmungen, dies auch öffentlich kund zu tun, aber sie erkennen leider nicht, dass diese Meinung falsch ist - ein schönes Beispiel für den Dunning-Kruger-Effekt ;-)

Das gute an Wissenschaft ist: sie funktioniert auch, wenn man nicht daran glaubt. Das Schlimme an Impfgegnern: wenn sie nicht daran glauben und das Impfen verweigern, gefährden sie nicht nur sich selbst (das wäre mir ja noch egal), sondern auch jeden anderen, den sie anstecken könnten.

[Der Leserbrief wurde am 14. April 2018 veröffentlich.]


Leserbrief zur Diskussion über Impfen und Impfpflicht (Facebook und gedruckt)
Liebe WZ-Redaktion,

was hat Sie denn geritten, dieses Fass aufzumachen? Geht es um Klicks und Onlinewerbung?

Beim Impfen kann es eigentlich gar keine Diskussion mehr geben. Das Thema ist medizinisch hervorragend erforscht.
Statistisch gesehen gibt es überhaupt keinen einzigen Grund, gegen das Impfen zu sein.
Durch Schutzimpfungen sind viele Krankheiten nahezu ausgerottet.

Stattdessen eröffnen Sie die Diskussion auf Ihrer Facebookseite erneut und bieten dadurch Impfgegnern eine willkommene Plattform, um größtenteils unwidersprochen Behauptungen in die Welt zu setzen und zu wiederholen, dass das Impfen "nutzlos" sei und mehr Schaden verursache als es Gutes tue.

In Venezuela sind seit Jahresbeginn mindestens 54 ungeimpfte Kinder an Masern gestorben. 2016 galt das Land noch als masernfrei.

In Serbien gab es eine Masernepidemie mit 4000 Ansteckungen und fast 20 Toten.

Die Diskutanten, die lautstark in den Facebook-Kommentaren Verschwörungstheorien über die Geldgier der Pharmakonzerne äußern, sind dieselbe Sorte Mensch, durch deren Schuld in Berlin vor kurzem Masern mit über 700 Ansteckungen und einem toten Säugling ausgebrochen sind.

Als Krönung des Ganzen darf Frau Kaufmann in ihrem "Kontra"-Kommentar in der Druckausgabe noch zeigen, dass sie in der Schule nicht aufgepasst hat, als das Grundgesetz besprochen wurde. Sie fabuliert munter drauflos, dass das Recht auf körperliche Unversehrtheit im Grundgesetz verankert ist und nicht durch eine Impfpflicht gebrochen werden kann. Dabei vergisst sie leider die Tatsache, dass alle Grundrechte nicht absolut gelten, sondern immer gegeneinander abgewogen werden müssen. Jedes Grundrecht findet seine Grenzen dort, wo die Grundrechte anderer verletzt werden, und das ist beim Impfen ganz klar der Fall. In Deutschland gab es jahrelang eine Impfpflicht gegen die Pocken. Das Bundesverwaltungsgericht entschied schon 1959, dass die verpflichtende Pockenschutzimpfung mit dem Grundgesetz vereinbar sei.

Es kann nicht sein, dass ein dogmatischer Impfgegner sich oder seine Kinder nicht impfen lässt und sie damit zu Trägern der Erreger macht. Dabei verletzt er nämlich offensichtlich das Recht auf körperliche Unversehrtheit aller Personen in seinem Umfeld. Wenn es hier Neugeborene oder Menschen mit Immunschwäche gibt, die aus medizinischen Gründen nicht geimpft werden können, provoziert er damit vorsätzlich deren Ansteckung und Gefährdung.
Manche Impfungen kann man erst ab einem Mindestalter impfen. Wenn nun die Mama das große Kind im Kindergarten abliefert und hat ihren 2 Monate alten Säugling dabei, dann ist so ein Schild an der Eingangstür "wir haben einen Fall von Masern" für mich schon vorsätzliche Körperverletzung, begangen von den Eltern, die ihr Kind nicht impfen lassen und trotzdem in den Kindergarten geben.
Es heißt nicht "Kinderkrankheit", weil es so ungefährlich ist, sondern weil hauptsächlich ungeschützte Kinder daran erkranken und womöglich sterben.

In Deutschland wurden in 10 Jahren ca. 180 Fälle von Impfschäden gemeldet, die meisten davon Bagatellen wie Fieber oder Hautausschlag. Statistisch ist ohne Impfung in derselben Zeit allein mit 800 Maserntoten zu rechnen, die sonstigen Folge- und Dauerschäden noch gar nicht eingerechnet. Natürlich ist jeder Impfschaden eine schlimme Sache für die Betroffenen, aber die Chance auf ein sorgenfreies, langes Leben ist mit Impfung wesentlich höher.

Eine Langzeitstudie an der Charité in Berlin hat übrigens festgestellt, dass der plötzliche Kindstod (SIDS) statistisch wesentlich seltener bei Säuglingen auftritt, die gegen Keuchhusten, Diphtherie und Polio geimpft sind.

Ich sehe das so ähnlich wie beim Führerschein oder beim Gesundheitspass für Beschäftigte in der Lebensmittelverarbeitung: ohne Schein kein Rein. Ganz einfach. Ohne Impfung kein Zugang zu öffentlichen KiTas, Schulen usw. Eine Impfpflicht muss es nicht geben - es steht jedem frei, das Risiko für sich einzugehen. Aber niemand darf für sein Umfeld entscheiden.

22.03.2018

Nerviges beim Autofahren - 2

Schön, dass Sie trotz Teil 1 wieder eingeschaltet haben zum nächsten Teil meines Gemeckers über Autofahren und Autofahrer und alles rundherum!

Ich hatte im letzten Teil schon angefangen, mich über Baustellen und das Verhalten von Fahrern in Baustellen auszulassen.

Einen Nachtrag zum Thema "Mittelspurfahrer" möchte ich noch nachliefern: der Postillon hat vor einiger Zeit über eine Sensation auf deutschen Autobahnen berichtet.

Auch sehr nett sind die Autofahrer, die in Baustellen links fahren, aber dann kein Gefühl dafür haben, wie breit ihr Auto tatsächlich ist, und sich dann nicht trauen, an breiten LKWs vorbeifahren. Dann bleiben sie schräg links hinter dem LKW, aber sie kommen auch nicht auf die Idee, dass sie wieder auf die rechte Spur wechseln, und blockieren dann erst mal alles.

Autofahrer, die nicht blinken können oder wollen, sind auch so eine Sache. Meistens geht das auch einher damit, nicht einschätzen zu können, wie schnell jemand von hinten angefahren kommt.

Nicht zu Unrecht lernt man in der Fahrschule, mindestens zweimal in den Spiegel zu schauen, um zu sehen, wie schnell jemand näher kommt, wie groß also der Geschwindigkeitsunterschied ist. Es gibt aber Fahrer, die das nicht nötig haben und dann einfach darauf vertrauen, dass der Hintermann gute Bremsen hat. Leider verursachen genau diese heftigen Bremsmanöver i.a. auch noch Folgebremsungen der weiteren Fahrzeuge dahinter, und das pflanzt sich dann vielleicht noch Kilometer nach hinten fort. Im schlimmsten Fall geschieht durch den unüberlegten und rücksichtslosen Spurwechsel sogar noch ein Unfall.

Wie gut, dass der Postillon erst kürzlich vermelden konnte, dass ab 2018 auch ein Blinker für das Geradeausfahren Pflicht wird!

Vielleicht wollen die Fahrer, die nicht blinken, den anderen Verkehrsteilnehmern aber auch einfach nicht die Überraschung verderben?

Marode Brücken sind auch so eine Sache für sich: durch die Vibrationen gehen Brücken schneller kaputt, als bei der Konstruktion vorausgesehen, weil insbesondere der LKW-Verkehr unglaublich zugenommen hat. An vielen Brücken gibt es Tempolimits wegen "Brückenschäden", üblicherweise 60 für LKWs und 80 für PKW. Ich denke mir dann, dass jeder, der das Tempolimit ignoriert, dazu beiträgt, dass die Brücke schneller kaputtgeht und saniert werden muss. Und natürlich passiert das von den Steuergeldern - meinen und seinen. Leider ist der Zusammenhang zwischen Steueraufwand und Tempolimit den meisten Autofahrern nicht allzu naheliegend.

Achja, nochmal Baustellen: die meisten dicken Automodelle, insbesondere die Disco- und Kindergartenpanzer, neudeutsch "SUV" genannt, sind mittlerweile inklusive Außenspiegeln deutlich breiter als zwei Meter, und das bedeutet in den üblichen Baustellen, dass sie rechts bleiben müssen. Im Fahrzeugschein steht die Breite ohne Spiegel, aber wenn auf einem Verbotsschild ein Limit von zwei Meter angezeigt wird, gilt das für die reale Breite inklusive beider Außenspiegel. Öffnen Sie einfach mal spaßeshalber die Scheiben in den vorderen Türen und messen Sie, wie breit Ihr Auto ist! Sie werden überrascht sein.

Tempolimits innerorts sind mir auch besonders wichtig und ich halte mich auch daran. In unserer Gemeinde ist vor einiger Zeit überall Tempo 30 eingeführt worden, außer auf der Bundesstraße und höchstens noch einer Durchgangsstraße durch jeden Ortsteil. Damit verbunden ist generell "rechts vor links". Leider hält sich kaum jemand daran - weder an das Eine noch an das Andere. Dabei ist es gerade innerorts wichtig, auf kleine und große Fußgänger Rücksicht zu nehmen. Besonders toll, wenn einem der Schulbus die Vorfahrt nimmt.

Ebenfalls gar nicht leiden kann ich es, wenn jemand mir zu dicht auffährt. Wenn ich mit der Familienkutsche unterwegs bin und habe jemanden hinter mir, dessen Front ich schon gar mehr nicht richtig im Spiegel sehen kann, weil er so nah ist, wünsche ich mir eine automatisch ausfahrbare Rampe statt der Heckklappe, um das Auto hinter mir als Beiboot an Bord zu nehmen (wie bei James Bond ;) ). Dieses Verhalten ist extrem dumm - wenn ich rechts fahren könnte, würde ich das tun. Meistens überhole ich aber gerade selbst, oder es ist eine ganze Schlange vor mir. In jedem Fall führt Drängeln aber zu erhöhtem Streß beim Gedrängelten und in letzter Konsequenz erhöht es das Risiko von Fahrfehlern und Unfällen (wie vor ein paar Jahren bei dem Unfall mit einem Mercedes-Testfahrer und einem Kleinwagen mit Mutter und Kind).

Eine besonders krasse Form von "dicht Auffahren" passiert anscheinend auch nur mir: ich bin vermutlich der einzige Idiot, der regelkonform am STOP-Schild wirklich anhält. Bei meinem vorherigen Astra ist mir an derselben Autobahnausfahrt zweimal (!) dieselbe Art von Unfall passiert: ich fahre bis zur Linie und halte an. Und dann bummst es. Weil der Autofahrer hinter mir (bzw. Kleinlaster, ist aber eigentlich egal) nicht erwartet hatte, dass ich tatsächlich anhalte. Das sind die Oberschlauen, die als zweiter in der Schlange sehen, dass von Links keiner kommt und dann einfach durchfahren wollen.

Dieselbe Art von Unfall ist mir dann mit dem kleinen Spaßauto nochmals passiert, allerdings an einem STOP-Schild an einer Einmündung zur Landstraße. Der Autofahrer hinter mir schaut nach links und bildet sich ein, er kann fahren, achtet aber nicht darauf, ob vor ihm das Auto noch da ist. Dieser Autofahrer war dann besonders penetrant: er beschimpfte mich auch noch, warum ich angehalten hätte. Der Gipfel der Selbstgerechtigkeit war, dass er von meinem kaputten Auto ausgiebig Fotos machen wollte, damit ich auf keinen Fall auf seine Kosten von der Versicherung Reparaturen bezahlen lasse, für die er nicht verantwortlich sei. Dabei hatte es gar keine sonstigen Schäden. Ich liebe das kleine Spaßauto, das ist technisch immer in Ordnung, nur manchmal ein bißchen staubig.

15.03.2018

Ich bau mir ein Linux wie es mir gefällt - 1

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)

14.03.2018

Flash-Update auf Version 29

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 29 (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=29.0.0.140
set VAX=29.0.0.140
set V=29
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 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:-
29.0.0.140}
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".

[20180314: Security Bulletin von Adobe]
[20180410: Security Bulletin von Adobe]

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.