Nichts könnte falscher sein, als das. Wer ernsthaft die letzten 30 Jahre in der IT tätig war, der weiß und kann bestätigen, dass Requirements-Engineering, Testing und QA wichtige Arbeiten sind, die man nicht automatisieren kann. Am Ende müssen Menschen die Anforderungen definieren und absegnen und die Umsetzung und den Betrieb sicherstellen.

Vor 15 Jahren gab es Delulu-Gründer ohne Technik-Kompetenz, die einfach „sowas wie Facebook/eBay/Amazon/Uber/AirBnB/… für X“ bauen lassen wollten, aber natürlich nicht in der Lage waren, die Komplexität zu begreifen und Anforderungen genau zu definieren. Ich kann natürlich auch Claude Code sagen, dass er mir eine App bauen soll, dann wird analysiert, was typischerweise(!) mit dieser Anforderungen verbunden wird (so funktionieren LLM, alles eine Frage der Statistik) und dann wird generiert.

Ein Großteil des Software-Geschäftes fußt aber eigentlich darauf, dass man die Definitionshoheit, aber auch Verantwortung an andere abgibt. Also davon ausgehen kann, dass jemand für Geld ein „rundes Produkt“ bereitstellt. Heute und auch in der Zukunft. Und genau das kann kein LLM ersetze, kein agentic coding toolkit.

Eine triviale Zeiterfassung- oder Buchhaltung kriegt jedes dieser Systeme in wenigen Minute hin, aber es ist untauglich für den praktischen Einsatz, da Nutzende die Tiefe des Problems nicht selbst verstehen, sondern bisher jemand anderes damit beauftragt haben. Sie wissen also nicht, was sie nicht wissen und können keine passenden Prompts schreiben.

Da es keine physischen Grenzen gibt, außer Token/Geld und Zeit, entwickeln gerade viele Leute irgendeinen Schrott und sinken dabei immer tiefer in bisher nicht verstandene Probleme, die sie eigentlich auch nicht verstehen oder lösen wollen.

An den Börsen crashen gerade die Aktien von Software-Unternehmen und das halte ich für absoluten Blödsinn. Natürlich wird die Einstiegshürde geringer werden, existierende Unternehmen zu kopieren, sofern ebenfalls fähige Senior Developer und Projekt-Manager welche strategisch und schlau vorgehen, also wissen, was sie tun. Es ist also eine massive Arbeitserleichterung für uns.

Alle anderen werden verzweifeln.

Wie immer gilt: Keine Handlungsempfehlung, da die Märkte länger irrational sein können, als wir liquide. Auch sind Software-Buden natürlich abhängig von der wirtschaftlichen und geopolitischen Entwicklung, d.h. da gibt es durchaus auch fundierte Gründe für eine Korrektur. Wo dann der faire Wert erreicht ist, bleibt offen.

Natürlich gibt es Geschäftsmodelle, die nicht mehr funktionieren werden. Ich persönlich lache immer über diese „KI-Sales-Leute“, die mit N8N und anderen Toolkits vorgeben, komplexe Arbeitsabläufe für Unternehmen zu realisieren. Dabei geht es fast immer um Anrufbeantworter bzw. Telefoniesysteme oder generieren von Mails. Das ist alles hoffnungsloser Bullshit und ineffizient.

Wenn ich z.B. einen Termin/Tisch beim Arzt oder im Restaurant will, möchte ich keinen Roman schreiben, sondern einfach auf der Website nach 3-4 Auswahloptionen eine Liste von freien Terminen bekommen und buchen. Nur Rentner und technologisch komplett verlorene Menschengruppen rufen per Telefon an, selbst wenn die Spracherkennung halbwegs funktionieren sollte. Darin steckt kein Potenzial, sondern nur ein Kostenfaktor.

Diese Verkäufer haben selbst keine Ahnung und sich ein paar Arbeitsabläufe ausgedacht, die sie jetzt immer und immer wieder verkaufen wollen. So wie Handyverträge vor 25 Jahren. Die schnelle Mark machen und Provisionen kassieren.

Während in den USA relativ oft Gründer aus dem Journalismus stammen, flüchten viele erfolgreiche Journalisten in Deutschland irgendwann in Corporate oder Public-PR, also quasi Propaganda für Konzerne oder die öffentliche Hand zu machen. Das mag lukrativer oder sicherer sein, als bei irgendeinem Medienhaus oder Fernsehsender zu bleiben, aber letztlich wäre mehr drin gewesen.

Vor ein paar Monaten habe ich mir den Spaß gemacht, eine vollständig auf LLM basierte „Journalistin“ zu generieren, welche die Münchner Rathaus-Umschau kommentiert. Das ist so eine Art Amtsblatt, dient aber primär der politischen Kommunikation. Es wird über Stadtratsbeschlüsse, Termine, Ehrungen und Anfragen berichtet.

Städtische Unternehmen verbreiten darüber auch ihre PR, egal ob Besucher beim Zoo, Ausbau des Fernwärmenetzes oder Baustellen bei der Tram.

Werktäglich außer Samstag wird gegen Mittag die neueste Ausgabe als PDF und teilweise in HTML bereitgestellt.

Für mein Projekt lade ich mir automatisiert das PDF, führe dann eine Texterkennung durch, da Meldungen städtischer Betriebe oft auch als Bild eingefügt werden, nicht als Text.

Danach sende ich den kompletten Inhalt mit einem längeren Prompt an ein LLM (TNG DeepSeek Chimera), warte auf das Ergebnis und poste das dann auf einem Social Media Kanal.

Da es politische Meldungen sind, erkennt die LLM manchmal nicht die wahren Absichten hinter bestimmten Anfragen, die nur vorgeblich für den Rad- und Fußverkehr sind, aber eigentlich neue Straßen und mehr Autoverkehr fordern. Manchmal ist es auch ungenau, was ich aber geschickt umgehe, dass nur sehr wenig kommentiert werden muss. Es ist Social Media und die Zeichenzahl beschränkt, da fällt es auch nicht immer so auf.

Einzige technische Herausforderungen sind: Nicht fristgerechte Veröffentlichung des PDFs und Überlastung des LLM-Endpunktes (ich verwende ein Gratis-Modell bei OpenRouter, habe schließlich nichts zu verschenken).

Ich wundere mich ehrlich gesagt, dass Medienhäuser und aktivistische Vereine augenscheinlich noch nicht solche Systeme entwickelt haben. Die SZ hat z.B. neulich über eine Woche gebraucht ein Thema zu berichten, nachdem es in der RU stand.

Ich hatte den Code und für noch ein paar andere Tools als Open Source auf GitHub, bis mir die persönlichen aber anonyme Angriffe diverser Mastodon.social-Moderatoren auf den Sack gingen. Warum also Tools liefern für deren Plattform? Technisch gesehen läuft der Code lokal in meinem Proxmox-Cluster, den ich u.a. mit cinc.sh (früher Chef) manage. Seit Monaten habe ich nichts mehr geändert und es läuft einfach. Achja, den Code dafür habe ich mit OpenCode vibe-coded, aber das ist eine andere Geschichte.

Die Idee klingt gut und notwendig: Infizierte sind bereits einen Tag vor Symptombeginn ansteckend und zudem sind viele Infektionen asymptomatisch. Stellen sich dann Beschwerden ein und kommt es zu einem Test, sind weitere kostbare Tage vergangen und weitere Menschen infiziert. Die Gesundheitsämter können dann nur noch sehr beschränkt mögliche Kontakte nach einem Interview nachverfolgen und so zur Quarantäne zwingen.

Der nun kommunizierte Plan in der Öffentlichkeit ist es, dass eine App per Bluetooth laufend eine eindeutige ID aussendet, die dann von anderen Nutzern mit ihren Smartphones und kompatiblen Apps empfangen und gespeichert werden (mit zusätzlichen Attributen wie Dauer und Signalstärke) – und vice versa. So entsteht auf den Geräte ein Logbuch der „bekannten“ Kontakte.

Wird eine Person als positiv getestet, so würde diese dann ihre App-ID an das Gesundheitsamt melden, welches dann die ID an einen zentralen Dienst/Service weitergibt, wo sie dann abgerufen werden kann. Das bedeutet, dass die IDs aller positiven Nutzer zentral für alle User zugänglich sein würde ODER jede Nutzer bzw Aapp für jede einzelne „gesehene“ ID regelmäßig eine Abfrage an einen zentralen Server durchführen muss (was effektiv eine zentrale Speicherung aller Daten und Kontakte gleich käme).

All das sind datenschutzrechtliche und ethische Probleme („Smartphone-App-Zwang“). Aber nicht das eigentliche Problem.

Das eigentliche Problem ist, dass Bluetooth schlicht dafür nicht geeignet ist.

Bluetooth wurde vor über 20 Jahren dazu entwickelt, Mäuse, Tastaturen, Headsets per Funk anzubinden. Ohne Triangulationsmöglichkeit gibt es keine verlässliche Möglichkeit, den Abstand oder andere sinnvolle Kriterien zu ermitteln, die eine Infektionswahrscheinlichkeit ergeben würde.

Bluetooth bzw. die Signalstärke oder Laufzeit, die Dauer der Verbindung (Sichtbarkeit) ist absolut unzuverlässig. Innerhalb einer Straßenbahn, S-Bahn, Supermarktes, Möbelhauses gäbe es vergleichsweise viele Menschen und sicherlich auch Infizierte, die dann sofort alle anderen in Quarantäne zwingen würde. Egal ob sie 30cm oder 15m Abstand eingehalten haben. Oder ob es an der frischen Luft war, wo aerosole Übertragungen unwahrscheinlicher sind als in einem stickigen Aufzug, oder dazwischen eine Plexiglaswand stand (Kassierer).

Das System schreit nach einer maximalen Anzahl an false positives welches zu einer Art Quarantäne-Lotterie mit hoher „Gewinnwahrscheinlichkeit“ führen wird.

BM Spahn hat in einem n-tv Interview heute auch eingestanden, dass in Südkorea GPS verwendet würde und nicht Bluetooth. Es findet also keine Kommunikation zwischen Smartphones statt, sondern die aktuelle Position wird sekündlich erfasst und auf einen Server hochgeladen, quasi eine elektronische Fussfessel.

Doch auch hier stellt sich die Frage, wie genau GPS bei einem Smartphone wirklich ist. Ich gehe zB ab und zu eine Route im Olympiapark spazieren und logge die Strecke mit 3 Apps auf meinem iPhone 8. Mobilfunk ist aktiv somit auch AGPS für einen schnellen Fix (initiale Bestimmung). Trotzdessen gibt es auf der Strecke zeitweise massive Abweichungen, teilweise 20m, zu Google Maps oder OpenStreetMap.

Natürlich landet das Smartphone in der Jacken oder Hosentasche und hat somit nur einen sehr eingeschränkten GPS-Empfang, den das Betriebssytem durch Gyrosensoren und über AGPS laufend korrigieren muss. Aber 20m mitten in der Stadt sind viel zu große Messfehler für eine zielführende Risikoeinschätzung.

Zynisch kann man jetzt darauf hoffen, dass die als Technologieversager bekannte T-Systems zusammen mit SAP nicht in der Lage sein werden, solch eine Lösung zu entwickeln. Zumal sie vollständig abhängig vom Unterbau von Apple und Google sind, der gerade erst noch geschaffen wird. Die Plattformen sind vollständig in der Hand von Apple und Google, so kann zB keine iOS-App direkt mit dem GPS-Modul „sprechen“, auch die Bluetooth-Verbindung steht nur indirekt bereit.

Das beste Szenario ist, dass man in Deutschland auf sehr wenige Neuinfektionen kommt und die App dann massive regionale False-Positives erzeugt. Vergleichbar mit einer Unwetterwarnung des Wetterdienstes über Starkwinde und „umstürzende Bäume“ – zwar trifft es immer nur wenige, die Warnung geht aber an alle raus. Wer schlau ist, wird die Risiken abwägen und zuhause bleiben – zB in Quarantäne.

Dafür das „Geschiss“ einer Tracing-App etablieren zu müssen, erinnert fast schon an Homöopathie.

Es zeigt aber auch, wie wenig Grundlagenwissen vorhanden ist.

Keiner kann programmieren, keiner hat jemals eine App entwickelt. Alle sind wir abhängig von Dritten, müssen uns an „Ideen“ Dritter klammern oder fallen auf diese rein.

Siehe Auch:

https://www.schneier.com/blog/archives/2020/05/me_on_covad-19_.html

Niemand braucht hunderte Arten von z.B. Supermarkt-Schokolade und Convenience-Lebensmitteln, trotzdem sind die Läden voll damit, verdrängen oft „ehrliche“ Produkte ohne Zusätze. Ähnliches bei anderen Suchtmitteln, wie Alkohol oder (noch immer) Tabak. Diese Produkte sind überwiegend für Konsumenten schädlich, trotzdem werden sie prominent und in großen Variation produziert, beworben, verkauft und konsumiert.

Eine verkürzte Begründung würde lauten: „Der Markt/die Kunden verlangen dies!“.

Aber warum brauche ich es?

Ähnlich ist es in der IT: Seit ich mich damit beschäftige, werden laufend neue Frameworks und Abstraktionsebenen veröffentlicht, die – zumindest früher – komplexe und schwierige „low level“-Programmierung durch einfacher zu nutzende Methoden und Schnittstellen ermöglicht haben. Dazu kam das entsprechende Tooling (IDEs, visuelle Interface-Builder etc) – man konnte viel schneller Produkte fertigstellen und veröffentlichen und damit Geld verdienen.

Heute ist es aber nicht nur komplexer in der Entwicklung sondern auch ohne messbare Vorteile für viele Nutzer. Man muss man für verschiedene Plattformen und Bereiche inkompatible Technologien einsetzen oder sich mit „eher schlechten“ plattformübergreifenden Frameworks begnügen. Kunden sind auch in Silos gefangen (Android vs iOS vs Web vs Desktop-Native).

Der Ausdruck „Balkanisierung“, wenn auch politisch inkorrekt, trifft die Situation recht gut: Eine Explosion, die aus wenigen universellen Technologien, Sprachen, Frameworks, Bibliotheken einer unbeherrschbare Vielfalt gemacht hat, die niemand überblicken kann und für die niemand sagen kann, ob sie in 2-3 Jahren noch existieren und ein „sicheres“ Investment sind.

Immer erst später erkennt man, wie nah früher der Markt/das Ökosystem am produktiven Optimum waren und wie viel Schrott und qualitativ schlechte Zusatzstoffe mittlerweile hinzugekommen und nicht mehr wegzudenken sind – ausser durch bewussten Verzicht!

Kommt ein neues Projekt mit dem Anspruch „eine gemeinsame Grundlage“ zu legen, dann passiert jedenfalls genau das nicht. Der Markt wird gespalten und ein neues Silo voller Eigenheiten und Komplexitäten aufgebaut. Einerseits braucht es dann „weitere Spezialisten“, aber die Produktivität pro Entwickler sinkt dramatisch, denn der Markt ist endlich d.h. Entwicklungs- und Betriebskosten steigen im Verhältnis zum Umsatz und es entsteht eine immer größer werdenen Markteintrittsbarriere für neue Produkte.

Kakao-Innovation:

Schokolade, Schokolade mit Nuss.

Schokolade mit Daim.

Schokolade mit OREO-Keksen.

Schokoladeneis!

Schokoladeneis mit Daim.

Schokoladeneis mit OREO.

Eis-Torte mit OREO, Daim, Schokolade, Kuchenteig, Salz und den besten Arteriengiften aus Palmöl und Milchpulver!

Auch hier kann die passende Fabrik sicherlich unbeschränkt viele Produktvarianten produzieren, aber die Regalplätze in den Supermarktfiliale ist beschränkt, müssen oftmals sogar gekauft werden und dauerhaft einen Mindestumsatz bringen. Was nicht performt, wird ausgelistet.

Man steht also im Supermarkt vor den Regalen und sieht nur noch populäre Fertigprodukte – auch frisches Gemüse ist nicht frisch sondern Tage alt und nährstoffarm, dafür „schön beleuchtet“ um den Frische-Eindruck zu erwecken. Nur noch wenige Kunden können und wollen selbst kochen – ohne Maggi und Knorr.

95% der Produkte sind versetzt mit ungesunden teilweise auch süchtig machenden aber zumindest prägenden Zusatzstoffen: viel Zucker, schlechte Fette, Einheits-Aromen („Erdbeer-Geschmack“, definiertem „Orangensaftkonzentrat“). Dazu ein durch Werbung und Kultur etabliertes Branding (Wer kannte Oreo vor 10 Jahren in Deutschland?).

Während ein Schokoladenhersteller mit etwas Logistik und Automation problemlos 1000 verschiedene Sorten herstellen und am Markt „ausprobieren“ kann, so kann das ein Entwickler oder Administrator nicht. Jeder Hype stellt für ihn ein Risiko dar: Lohnt sich die zeitaufwändige oft unbezahlte Einarbeitung, weil der Markt den Skill nachfragen wird? Oder verschwendet man seine Zeit mit einem Nischen-Silo? Wann sollte man „abspringen“ von etablierten aber „uncool“ gewordenen Dingen? Wie schlau ist es, sein Unternehmen oder seine Karriere auf 758 fremde nodejs packages aufzubauen?

Manche konzentrieren sich – spät und nach mühsamer Entwöhnung/Entzug – bei Lidl auf Tiefkühl-Rosenkohl, Tiefkühl-Blumenkohl, Tiefkühl-Brokkoli und Tiefkühl-Gemüsemix („OHNE ZUSATZSTOFFE“, Fette, Butter, Gewürze) – für läppische 1,60€ das Kilo. Direkt ab Ernte schockgefrostet, zuhause dampfgegart oder ehrlich mit etwas Käse und Salz überbacken.

In der IT können manche noch oder wieder Probleme mit einfachen Mitteln lösen, mit Bash, Ruby, Python oder schlicht bedachter Arbeitsweise, die auf den Punkt ein Problem lösen und damit Geld verdient („YAGNI„). Durch Reverse-Engineering von bestehendem Code, Hinterfragen von Anforderungen und Auswertung von Nutzerfeedback.

Wenig erstaunlich gibt es selten Jobs mit diesem Anforderungsprofil oder es handelt sich um ausbrennende „Feuerlösch-Jobs“ ohne leistungsabhängige Vergütung: Menschen und Unternehmen verbrennen problemlos monatelang Ressourcen um dann mit sehr wenig Restbudget nach notwendigen „Rettungskräften“ zu suchen, die Bestandssysteme oder Migrationen noch „retten“ sollen.

Der Fokus auf die eigentlichen Herausforderungen ist vollständig verloren gegangen.

Letztlich sind wir Menschen – alle! – wunderbar in der Lage, uns selbst lange etwas vorzumachen. Jeder sich selbst gegenüber und gegenüber seinen Mitmenschen, Kollegen, Kunden. Wir ignorieren langfristige Nachteile, sehen bunte Produktverpackungen, fallen auf durch Konsum suggerierte Emotionen hinein („Glück“, „Erfolg“, „Anerkennung“, „Lust“, „Respekt“, „selber Stack wie Google!“) und sind nur selten bereit oder überhaupt fähig, uns davon wieder zu lösen.

Wir unterschätzen Risiken, wenn andere den gleichen Unfug machen, überschätzen Risiken, wenn wir selbst etwas selbst umsetzen. Wir wollen keine Verantwortung übernehmen. Wir schätzen funktionierende Bestandslösungen zu schlecht ein und überschätzen Werbeversprechen von Anbietern, die erstaunlicherweise mit der „Lösung“ überhaupt kein Geld verdienen wollen (was schlicht gelogen und eine Falle ist).

Wir sind extrem schlecht darin zu beurteilen, was ein „Fortschritt für uns“ sein kann und was ein Rückschritt sein wird (der dafür anderen Playern dauerhaft Mehreinnahmen durch ein neues Abhängigkeitsverhältnis beschert). Wir fallen immer wieder auf „einfache Lösungen“ herein – auch politisch.

In der Wissenschaft zählen Fakten: Definierte Aufbauten, Durchführungen und ihre gemessenen Auswirkungen gegenüber einer Kontrollgruppe – daraus werden dann Schlüsse gezogen. In der IT-Branche sieht man allenfalls A/B-Tests zur Konversationsoptimierung im Bereich SEM/E-Commerce, selbst wenn mittlerweile alle möglichen Metriken zentral erfasst werden und mit zB Grafana oder Datadog auch schön bunt aber oftmals nutzlos visualisiert werden. Konkurrierende Experimente werden selten definiert. Und was ist das Ziel? Und was ist nochmal die Ausgangslage? Wie misst man Komplexität? In welchem Verhältnis steht Komplexität zu Laufzeitkosten?

In der IT transplantieren wir deshalb laufend Bestandssysteme ohne konkrete Analyse der bestehenden Beschwerden oder der Lebensweise, die möglicherweise die Ursache der Probleme sind. Ob Wechsel zu Microservices, Migration „in die Cloud“/proprietäre AWS-Services, Containerization, Kubernetes – alles schön und toll, aber nicht wenn man die Ursache des möglicherweise suboptimalen Bestands-Zustandes nicht korrekt analysiert hat und die Probleme dann mit hoher Wahrscheinlichkeit wieder erleiden wird. Niemand will es, aber es passiert laufend.

Viele Menschen saufen, fressen und rauchen — nicht, weil sie Durst oder Hunger leiden, oder „etwas anzünden“ wollen, auch nicht weil sie die Gefahren und Folgen nicht kennen, sondern weil sie damit andere Bedürfnisse zu stillen versuchen und/oder abhängig geworden sind. Natürlich gelingt das nicht und sie ruinieren sich und manchmal auch Unternehmen.

Ein ähnliches Verhalten sehe ich seit Jahren in der IT.

In den 2010er Jahren haben wir den massiven Wechsel hin zu Mobile Devices und einer massiven Zunahme der digitalen Unmündigkeit gesehen. Während die Jahrzehnte zuvor ein Universalrechner in verschiedenen Formen und Leistungsklassen eine vielschichtige und auch „produktive“ Nutzung erlaubt und viele Menschen vermögend gemacht hat, so haben heute immer weniger Menschen einen Desktop-PC oder ein Notebook. Oder die leiseste Ahnung, wie man damit umgeht oder gar selbst „Werte schafft“.

Die Masse der Menschen verfügt über Smartphones, entweder mit Android oder iOS-Betriebssystem. Beide Plattformen sind für den Nutzer „locked“, einzig die meist kostenpflichtige Beschaffung von Apps und Medien, insbesondere in Abo-Modellen (Spotify, Netflix) eröffnet einen gewissen Konsum-Freiraum.

Die Entwicklung von Mobile-Anwendungen ist so gut wie nicht direkt auf Mobilgeräten möglich, erfordert also leistungsfähige „Universal-Rechner“ und entsprechende Kenntnisse (Entwicklung/Konsum-Asymmetrie). Dabei sind die Frameworks und auch die Vermarktungsregeln (Inhalte, Preisgestaltung, Gebühren) strikt von den Anbietern vorgegeben, entweder Apple’s App-Store oder Google Play. Andere Märkte spielen keine nennenswerte Rolle.

Mit einem Smartphone kann man allerdings als Nutzer so gut wie nicht Werte schaffen. Klar, als Dienstleister, Hausmeister, Klempner oder Uber- oder Lieferando-Fahrer ist man per Telefon oder App „erreichbar“ und kann sich darüber als Tagelöhner betätigen und kurzzeitig manche lukrative Markt-Anomalien ausnutzen („Surge-Pricing“ etc.). Die Masse wird aber nie aus diesem Status herausfinden und daher schlechter gestellt sein, als einfache angestellte Fabrikarbeiter von vor 20-30 Jahren.

Aber auch die „digitalen Eliten“ unseres Landes werden noch massiv darunter leiden. Denn der Markt von PCs und Hardware schrumpft, sodass es auch für uns immer schwieriger wird, „neutrale“ Hardwarekomponenten zu beschaffen um damit Geld zu verdienen.

Der Mega-Trend Cloud-Computing sorgt auch auf der „professionellen“ Ebene dafür, dass leistungsfähige Hardware (Prozessoren, NVMe, i/O-Interfaces wie Netzwerkkarten, Router) zuerst bei den großen Abnehmern landen wird, also den drei großen Cloud-Anbietern und ggf. noch Facebook, Apple. Dazu muss man auch sehen, dass die komplette x86 Architektur im Mobilbereich durch ARM abgelöst wurde und hier kein Ökosystem existiert, wo sich Nutzer bausteinartig bedienen können.

Es gibt hier keine gesockelten CPUs, Mainboards oder Erweiterungskarten, die man von unterschiedlichen Herstellern, Preis- und Leistungsklassen auswählen könnte. Man muss hier entweder auf bereits fertig angebotene Komplett-Systeme (System-on-a-Chip) ausweichen. Letztere sind aber insbesondere im low-end-Segment verfügbar, wo Hersteller mit in die Jahre gekommenen Designs noch eine Einnahmequelle erschliessen (siehe Broadcom/RPi, Texas Instruments).

Derweil haben Apple und Amazon eigene Chip-Entwicklungsunternehmen und auch Facebook und Google investieren hier sehr viel in proprietäre Hardware, die (noch) extern nach Maß exklusiv für sie gefertigt wird.

Schauen wir in den Software-Bereich: In der von mir nicht erlebten Anfangszeit des Personal Computings war es üblich, sich Software selbst zu schreiben oder den Quellcode auszutauschen. Mit der Kommerzialisierung durch IBM, Apple und Microsoft, erlebten wir 25 Jahre Closed Source. Nun sieht es so aus, als ob Linux oder Open Source als Gegenpol doch noch gewonnen hätte: Android basiert auf Linux, Microsoft hat ein Linux-Subsystem umgesetzt, das sehr komfortabel für Nutzer ist. Auch macOS basiert auf Unix und immerhin noch zu einem Teil offenen „Userland“. Linux läuft auf allem, was mehr als ein paar Kilobyte Speicher hat.

Aber ich denke wir haben gerade den Peak erlebt: OpenSource Software verrottet. Man merkt den Tools die 20-40 Jahre an, die sie auf dem Buckel haben. Sie sind zu einem großen Teil in C geschrieben und anfällig für alle möglichen Programmierfehler welche für Sicherheitslücken ausnutzbar sind. Evolution unter „laufendem Rad“ ist so gut wie nicht möglich, jeder Wechsel wie bspw von SysVinit auf systemd begleitet von massiven Shitstorms, Bremsern und Innovationsfeinden. Und auch der Linux-Kernel ist ein Monstrum geworden, das noch primär von Linus Torvalds im Zaum gehalten wird.

Von alleine findet keine Innovation, keine Modernisierung statt. Ein Großteil der quelloffenen Software und natürlich der Kernel-Treiber stammt von Unternehmen oder wird von diesen gewartet/gefixt, die entweder Hardware verkaufen oder selbst eine kommerzielle Linux-Distribution anbieten und sich dafür von Großkunden bezahlen lassen: Wie zum Beispiel RedHat. RedHat wurde letztes Jahr von IBM übernommen und ist nun Teil eines Konzerns, der primär mit Consulting und „Lock-In“ im Enterprise-Bereich Geld verdient. Das „Zurückgeben“ an die Community oder die Akquise von „kleineren Mittelstandskunden“ spielt also noch weniger eine Rolle, als bei RedHat zuvor. Auch hier ist ein Switch zu einem Plattformmodell sichtbar, d.h. den „besten“ Support gibt es nur noch für Plattform/Cloud-Kunden und nicht mehr für On-Premise-Installationen auf Kundenhardware am Standord des Kunden oder seines Rechenzentrums.

Fassen wir nun die Entwicklungen aller drei Bereiche zusammen, also Hardware, Software, Cloud-Computing, dann werden wir Ende des Jahrzehntes 2020 keine Enterprise-fähige Hardware mehr am Markt mehr kaufen können. Die einzige Option wird eine in der Cloud bereitgestellte Umgebung sein, mich hochspezialisierter, proprietärer Hardware. Sowohl für allgemeine Berechnungen wie auch bestimmte gehypte Anwendungsfälle wie Machine Learning. Diese Lösungen werden mindestens um den Faktor 3 besser performen, als alles, was man sich „neutral“ am Markt noch zusammenkaufen können wird.

Daran wird auch RISC-V nichts ändern, eine freie Prozessor-Architektur welche im Gegensatz zu ARM keinen kommerziellen Hintergrund hat sondern als Stiftung organisiert ist. Auch hier werden sich die bereits großen Silicon-Vendors austoben und eigene Produkte und Plattformen entwickeln können. Auch hier wird eine große Abnahmemenge nur erreicht, wenn Cloud-Anbieter mit einsteigen oder gleich selbst die Chipentwicklung übernehmen und daraus fertige Services anbieten.

Was bleiben wird, sind vergleichsweise abgespeckte PCs/Macs, die ausreichend dimensioniert sind um Anwendung für die Cloud zu entwicklen, am besten durch Container und Containerumgebungen vollständig von der darunterliegenden Hardware (und teilweise auch Software) entkoppelt. Sie werden nicht mehr zu Betrieb eigener Anwendungen geeignet sein, entweder wegen der schlechten Performanz oder der schlechten Energieeffizienz.

Spätestens in der zweiten Hälfte der 2020er werden wir dann die Aufgabe dieser „Kompatibilitätsschicht“ sehen (Container, Kubernetes) und einen Switch zur „nativen“ Entwicklung auf exakt einen Cloudanbieter, welche dann lokal wirklich nur noch in langsamen Emulatoren testbar sein wird, vergleichbar mit der heutigen Entwicklung für Smartphones.

Der Wechsel wird, nicht ganz unrichtig, als Fortschritt gefeiert werden, weil damit der „alte Zopf“ des x86ers und eines Monokernels wie Linux abgeschnitten werden kann. Wer braucht schon Treiber für Disketten, CD-Laufwerke, Scanner oder Grafikkarten. In der Cloud ist alles schneller und ohne einmalige Hardware-Ausgaben realisierbar…

Wirtschaftlich ist das die vollständige Übernahme und Kannibalisierung der bestehenden IT durch 3-4 in Frage kommende Konzerne. Sie alle haben ursprünglich ihr Geld woanders verdient und tun es auch heute noch: Google mit Werbung, Microsoft mit Software und Amazon mit E-Commerce. Sie alle haben erkannt, dass es eine weitaus lukrativere und – für sie – zukunftssichere Möglichkeit gibt, Geld zu verdienen. Der perfekte Vendor-Lock-In, wie es wohl vor 50 Jahren bei IBM und vielleicht bei Nixdorf war. Die Symbiose aus Hardware und Software als Service. In einem begrenzten Maßstab (ERP und Services darum) ist das bei SAP aktuell ganz gut zu sehen, aber ob die SAP im Kampf um die beste Hardware+Betriebssysteme mithalten wird können, halte ich für fragwürdig. Bisher kauft man zu und diese Zulieferer werden massiv unter Google, Microsoft und Amazon leiden.

Bestenfalls naiv ist auch eine von vielen meiner Kollegen vorgetragene Beschwichtigung, dass im Kampf der „Giganten der Gegenwart“ gegen die „Giganten der Vergangenheit“ (quasi alle DAX und S&P 500-Unternehmen) zuerst die großen Unternehmen angefixt und dann gemolken/geschlachtet werden. Über die Zeit wir auch hier eine Sättigung einsetzen und auch jedes kleine, aber erfolgreiche Startup (oder Mittelständler) wird sich früher oder später „ergeben“ müssen: Es gibt keine neutralen Ressourcen mehr, sodass eine Preiserhöhung des Cloud-Providers, eine strategische Leistungseinschränkung oder ein anderer „freundliche Wink mit dem Zaunpfahl“ keinen Verhandlungsspielraum für angemessene Exits mehr zulassen werden: Entweder der gewählte Cloud-Anbieter kann das Startup für einen sehr guten Kurs übernehmen, oder er wird es durch Kopie oder Preisgestaltung zerstören. So wie man es Microsoft in den 1990ern vorgeworfen hat, nur eben 1000x brutaler.

Optimistischere Menschen würde nun an die Eigenverantwortung appellieren, an „den Ruck“ der durch die Gesellschaft und Wirtschaft gehen müsse, sich nicht in dieser Zwickmühle fangen zu lassen.

Oder an eine Intervention der Politik oder Kartellämter.

Aber letztlich kann das den Wandel nicht aufhalten, nur verlangsamen. Alternativen müssten her, aber wer soll das tun? Und warum? Einerseits wären Unsummen an Risikokapital nötig und andererseits nochmal: Wer könnte es überhaupt? Deutsche Hochschulen und hier ansässige Unternehmen sind abgeschlagen, selbst bei dem Thema RISC-V ist meines Wissens nur die Hochschule München (FH) interessiert. Es fehlt die Kompetenz, das Personal, die wirtschaftliche Denkweise. Jede weitere Fördermillion wird und würde vollständig und ergebnisarm versenkt werden.

Und wer geht freiwillig selbst ein wirtschaftliches Risiko ein, wenn im Falle eines „Lottogewinns“ dann auch noch die erzielten Gewinne brutal zu versteuern wären? Lieber lässt man sich wie ein Frosch im Topf erwärmen und versucht sich über die Zeit zu retten (oder den bis dahin noch aufgebauten Wohlstand in ein anderes Segment oder Region zu verschieben).

Wir leben 2020 in einem Land, bei denen nicht nur die Enduser sondern auch die Administratoren und Entwickler zu einem Großteil längst überfordert (oder inkompetent) sind, wie man aus den „Emotet“-Infektionen, der unfassbar stümperhaften Wartung zB der IT in Berliner Gerichten (Kammergericht), dem Umgang mit dem Citrix-Gau („Shitrix“, CVE-2019-19781) oder der naiven Auslagerung von Diensten wie Mail oder eben „General Cloud-Computing“ an US-Konzerne sehen kann. So war es 2010 und so war es 2000. Es hat keine messbare Steigerung gegeben, kein Ruck, kein „Gas geben“.

Wir haben bisher mindestens 20 Jahre verloren und werden in diesem Jahrzehnt weitere 10 Jahre verlieren.

Update 2021-02-25:

Im Journal der ACM ist ein spannender Artikel erschienen.

Günstige Panels bekommt man aber auch einzeln in China nachgeschmissen. So zum Beispiel P10-Elemente (10mm Abstand zwischen den LEDs) im Format 32×16 Pixel für ca 13€ inklusive Versand und Steuern (als ob) bei AliExpress.

Dazu einfach die OpenSource-Software des Google-Mitarbeites Henner Zeller verwenden auf einem 10€ Raspberry Pi Zero verwenden und für die Stromversorgung ein ATX-Netzteil recyclen. Done.

Das Ergebnis war insofern frustrierend, weil ich doch einige offene und fehlkonfigurierte Systeme fand. Manche offenbarten keine vertraulichen Daten, aber dafür den kompletten, maschinenlesbaren Katalog ihrer Produkte. Andere erfassten auch sämtliche Kundenattribute wie Anschrift, Handynummern, Geburtsdaten in ElasticSearch – entweder weil ElasticSearch als Suchmaschine eingesetzt wird oder im Rahmen einer Log-Aggregierung (z.B. mit Logstash und dem Frontend Kibana).

Ich habe alle betroffenen Unternehmen informiert (darunter auch ein großes, altes, renomiertes Schweizer Informatik-Unternehmen, das für seine insbesondere bei Kulturbetrieben in Frankreich verbreitete Ticketing-Anwendung Kundendaten im Rahmen eines Logs der Bonitätsabfrage „veröffentlicht“ – immerhin Klarnamen und Geburtsdaten)

Nur wenige haben sich zurückgemeldet oder gar bedankt. Ich hoffe trotzdem, dass man sich überall Gedanken über die IT-Sicherheit macht und zu blauäugige Cloud-Deployments in Zukunft unterlässt. In mindestens zwei Fällen waren Altsysteme offen für die es „keine Mitarbeiter“ mehr gab. In einem Falle konnte innerhalb des Unternehmens aus den Niederlanden ein Mitarbeiter die Altsyteme offline nehmen, in einem anderen Falle eines deutschen Fachverlages half nicht einmal eine Meldung an den Abuse-Kontakt des Hosting-Providers (QSC) um betroffene (und augenscheinlich schon von Dritten kompromittierten Systeme) offline zu nehmen.

Ich bin dann dazu übergegangen, diese Systeme und offene Systeme ohne Daten oder offensichtlich seit Monaten laufende „Test“-Systeme in einer Liste zu erfassen und diese demm BSI bzw. CERT-Bund mit Bitte um Eskalation/Kommunikation zukommen lassen. Das BSI hatte schon vor fast 2 Jahren vor den Gefahren ungesicherter ElasticSearch-Instanzen gewarnt, aber diese Warnung wurde und wird leider ignoriert.

Weiterhin kann ich meine Recherchen nicht monetarisieren, d.h. offene Systeme zu finden unterhält mich zwar, aber den oft inkompetenten und undankbaren Admins hinterherzulaufen ist nicht sinnvoll. Falls jemand eine plausible und ethische Möglichkeit einfällt, zumindest einen Unkosten-Obulus darüber zu realisieren, bitte ich um Rückmeldung.

Weiterhin habe ich auch noch nach offenen, fehlerhaften Docker-Deployments gesucht, bei denen die REST-Schnittstelle ohne Zugangsprüfung im Netz erreichbar ist. Hierbei bin ich auf ein VMWare-Container-Host-Deployment der Uni Trondheim gestoßen, auf dem bereits Angreifer CPU-Mining-Software gestartet hatten. Die Nodes wurden binnen 24h nach Mail offline genommen, eine Antwort habe ich jedoch nicht erhalten. Auch einige deutsche Webagenturen und Privatpersonen haben ihre Konfiguration verbockt: docker –tls -H <ip>:2376 ps

Ein Trauerspiel ist jedoch die Tatsache, dass auch 2019 noch so viele offene Multifunktionsgeräte/Drucker im Netz ansprechbar sind (ports 515/lpd, 631/ipp, 9100/jetdirect). Zwar sind die meisten Geräte wenigstens mit einem „Administratorpasswort“ gesichert (oder es waren schlicht andere Leute schneller…) doch anonyme Druckaufträge werden anstandslos akzeptiert.

So finden sich beispielsweise noch immer im IP-Netz der Universität Freiburg ca 60-80 offene Drucker mit teils abenteuerlicher Konfiguration (vermutlich Gebrauchtgeräte deren Altkonfiguration nicht gelöscht wurde). Richtig traurig finde ich hier die Tatsache, dass die zuständige RZ-Mitarbeiter eine inhaltlich sehr starke Website zu dem Thema veröffentlicht haben, aber nicht befugt oder willens sind, durch IP-Filter oder „aktive Verfolgung“ der einzelnen Geräte den Sachverhalt in kurzer Zeit zu klären.

Es ist zudem keine Neuheit, dass Sicherheit auch bedeutet, dass man sich „von innen“ nicht ungeschützt aufstellen darf. Spätestens seit BYOD und insbesondere in Netzen mit vielen und wechselnden Nutzern (Uni, Konzernen, etc) muss man Segmentiere und aktiv die Netze managen. Also bei Malware-Wellen ggf. eine Weiterverbreitung durch infizierte Systeme verhindern, bestimmte Dienste und Ports sperren, ein IDS betreiben und Traffic-Anomalien auswerten. Selbst in großen, dezentralen Organisationen gibt es keine Ausreden: Man muss die Aufgabe eben delegieren.

Für so triviale Dinge wie offene Drucker kann man sich mit ein paar Zeilen Bash einen Cronjob schreiben, der täglich eine Übersicht der Übeltäter per Mail erstellt. Oder auf externe Services wie eben Shodan zurückgreifen und sich kostenpflichtig informieren lassen. Letztlich muss man dann aber auch die Durchführungsgewalt haben und durchgreifen können, sollten sich Unterbereiche oder Endnutzer (wiederholt) den Anweisungen widersetzen.

Zum Schluss noch ein Abschnitt zu Obskuritäten: Uralt-Cisco-Router und Debian-Nodes mit 15-20 Jahre alter Firmware/Release. Während man insbesondere in Afrik noch ein paar steinalte Cisco-Router finden kann, so sind auch bei uns in Deutschland einige Legacy-Webhosting-Systeme aus den frühen 0er-Jahren online, z.B. ein System mit in 2003 abgelaufenen TLS-Zertifikaten. Somit ist auch davon auszugehen, dass seitdem keine Wartung mehr stattgefunden hat, worauf auch uralte Software-Versionen bei SSH und „Confixx“ hindeuten.

TL;DR

Obwohl mittels Shodan.io offensichtliche Konfigurationsfehler und Verwundbarkeiten in kürzester Zeit entdeckt/monitort werden können, sind noch immer verwundbare Systeme auffindbar. Hierzu reicht ein Browser und minimale Kenntnisse zur Ermittlung und „Exploitation“ aus.

Muss es überhaupt Jenkins sein?

Jenkins war das erste Mainstream CI-Tool und ist bis heute mit großem Abstand das populärste Tool im In-House-Einsatz, also on-premise oder der selbst verwalteten Cloud. Es stammt aus der Hochzeit der JEE-Webanwendungen und ist dementsprechend komplex und voller Legacy-Code. Besonders erwähnenswerte No-Gos für den Einsatz in 2019 sind meiner Meinung nach:

• Jenkins lässt sich nicht über Konfigurationsdateien dynamisch konfigurieren, sondern lädt diese beim Start einmalig und hält sie dann in einer internen, proprietären Datenbank. Änderungen sind dann nur über eine funktional unvollständige und fehleranfällige API möglich, über das Web-Interface, oder durch Groovy-Scripting/Java-Plugins. Das hat auch zur Folge, dass man die Konfiguration nicht mit üblichen Tools versionieren oder per DevOps-Tooling der Wahl duplizieren/wiederherstellen kann, die eingebaute „Versionierung“ einzelner Optionen (Jobs, Nodes) ist unvollständig und verfügt über keine remote API oder Exportfunktion. Würde Jenkins eine von aussen ansprechbare (no-)SQL-Datenbank nutzen, wären viele Probleme gelöst und eine Replikation/Failover möglich.
• Das Jenkins Master/Slave-Modell ist antiquiert und extrem fehleranfällig. Agents werden zB auf den Slaves per SSH-Connection vom Master aus gestartet oder verbinden sich per JNLP mit dem Master. Bricht aber diese connection ab oder startet der Master neu, sind alle noch laufende Jobs und deren Ergebnisse verloren.
• Jenkins verliert bei einem Neustart regelmäßig die Jobliste der noch auszuführenden Jobs. Das kann man z.B. beobachten, wenn man Jenkins Master als Docker-Container betreibt und dann zeitnah auch Dockerd neustartet. Jenkins löscht die Job-Persistierung noch bevor das System hochgefahren ist und ist auch nicht in der Lage, das passende Signal seitens Docker zum Herunterfahren wieder zur Persistierung zu nutzen. (Wie verwenden hier das offizielle Jenkins LTS Image).
• Logging ist die Hölle. Granulare Loglevel sind nicht impementiert, eine Erhöhung des Loglevels auf „fine“ sorgt für eine unfassbare Flut an belanglosen Meldungen, aber auch nicht zur mehr Informationen über das Verhalten von Jobs oder Slaves.
• Jenkins, auch die kommerzielle Lösung mit Support, hat keine HA-Lösung am Start. Was als HA verkauft wird, ist eine lahme hot-standby-Spiegelung auf DRBD-Level oder Network-Storage (z.B. NFS oder irgend einer kubernetes Storage-Lösung). Bei jedem „Schwenk“ (Failover) zwischen den Instanzen gehen alle laufenden Jobs verloren (siehe oben). Der „offizielle Workaround“ ist der Einsatz eines Plugins, dass fehlgeschlagene Jobs einfach neu startet. Was bei hunderten Jobs natürlich idiotisch ist, bei denen es laufend betrieblich zu kaputten Builds kommt. Diese dann immer und immer wieder erneut auszuführen, erhöht nur die Systemlast und Latenz für „neue“ Jobs.
• Plugins. Plugins sind die reinste Hölle. Jeder, der ein Jenkins Plugin installiert, muss sich dessen bewusst sein und dies nur unter Erleidung körperlich größter Schmerzen vollziehen oder besser vermeiden. Viele Plugins sind seit Jahren unmaintained, fast immer voller bugs und suggerieren ein größeres, aktiveres Ökosystem, als vorhanden. Dokumentation ist oft nicht vorhanden, die enorme Abstraktion sorgt für enorme Aufwände beim Reverse-Engineering/Verstehen des Codes. Tests sind lausig, wenn vorhanden.
• Groovy und Pipeline-Plugin werden als Alternative des traditionellen Jobs angepriesen, sorgen aber nur für noch mehr Matsch, weil jetzt auch noch massiv eigener Code an die brüchige Basis angedockt wird.
• Selbst populäre Plugins, wie das Github oder Github-Pull-Request-Builder-Plugin sind broken by design, wenn man eine gewisse Anzahl an Jobs oder Pull-Requests überschreitet. Das passiert besonders gerne bei Mono-Repos, wo ein Commit zwar auch nur einen Github-Webhook auslöst, doch dann innerhalb von Jenkins unter Umstände 20 Jobs anstösst. Das Github-Plugin führt nun aber wiederum 20 API-Requests (viel davon identisch) und startet dann diese Jobs. Je nach Teamgröße und Setup überschreitet man spielend leicht die tägliche Quote der GitHub public API, was das ganze Setup zum Erliegen bringt. Caching der Requests ist nicht sinnvoll in Jenkins möglich bzw wurde erst vor einigen Monaten durch eine Änderung wieder sabotiert (kein HTTP proxy mehr nutzbar), trotzdem gibt es interessante Ansätze ausserhalb von Jenkins wie z.B. Leeroy von Docker. Hier erfolgt die Interaktion mit GitHub ausserhalb von Jenkins in einer überschaubaren Anwendung, die dann nur doch Tests anstösst und Ergebnisse auswertet.
• Da Jenkins, wie oben beschrieben, keine zuverlässig persistente Queue hat, werden auch eingehende Webhooks öfter mal nach Annahmebestätigung (also HTTP 2xx/3xx-Response) verloren, insbesondere in der Phase eines Restarts. Hier muss dann vom Developer manuell erneut zB gepusht werden oder manuell in der Jenkins WebUI die Tests angestossen werden.

Also, wenn ihr es könnt, vermeidet grundsätzlich den Einsatz von Jenkins. Bitte macht keine Deployment-Automatisierung oder scripting von Cloud-Ressourcen (Terraform etc) innerhalb von Jenkins.

Ihr macht nur Web-Kram oder baut einfach nur binaries für eine Plattform/OS? Sucht euch etwas anderes, nutzt Travis CI, Circle, GitLab, Drone, Go-CI – oder baut euch eine eigene kleine Test-Pipeline. Geniesst eure niedrigen Anforderungen, die Welt steht euch offen, lasst sie euch von Jenkins nicht verderben!

2. Operationelle GOs und NO-GOs

Monorepos

Das miserable Verhalten von Jenkins bei Monorepos muss ich hier nochmal ansprechen. Ja, Monorepos machen bei bestimmten Projekten durchaus Sinn, wenn man eine große Core-Library hat und diese dann auf diversen Plattformen mit Wrapper-Code veröffentlicht. Da muss man eben laufend die Gesamtheit des Systems testen und auf einem Stand halten. Dependency-Management und Versionierung über dutzende einzelne Repos hinweg ist ein PITA, deshalb ist ein Monorepo hier sinnvoll.

Andererseits verhindern Monorepos auch die Aufteilung auf mehrere Jenkins-Master und je nach Projektumfang- und Entwicklerzahl ist somit eine 24/7-Auslastung des Masters-Nodes vorhanden, die selbst kurze Systemupdates unmöglich macht. Dank der nicht vorhandenen HA-Lösung gibt es also immer eine Downtime. Entweder stoppt man einfach den Node und verliert alle laufenden Jobs, oder greift schon ggf. Stunden vor der geplanten Downtime ein und deaktiviert neue Job-Ausführungen auf den Agents. Auch hier trägt wieder o.g. Bug bezüglich Job-Queue-Persistierung zu viel Ärger bei.

VPN

Weiterhin ist es absolut nicht mehr zeitgemäß, eine Jenkins-Instanz offen „im Internet“ zu betreiben, selbst über HTTPS landet jeder Request doch am shitty web-framework von Jenkins inkl. laufend bekannt werdender Bugs mit Cookies, CSRF oder den diversen Auth-Möglichkeiten. Bitte nutzt WireGuard. Bitte nutzt WireGuard! Ein Reverseproxy davor (zB nginx) kann auch weiterhin whitelisted Requests durchlassen, z.B. webhooks oder bestimmte API calls. Alle anderen bleiben ohne VPN draussen. WireGuard ist jeder andere VPN-Lösung in allen Belangen überlegen, solange ihr nicht Layer 2 oder Meshing benötigt, was hier nicht der Fall ist.

Vergesst bloated OpenVPN oder IPSec, die Batterien leerfressen oder Ärger mit Zertifikaten oder kaputten nativen Clients verursachen. Für das Jenkins-Szenario braucht ihr auch keine default-route, ihr baut einfach einen Tunnel auf und könnt dann auf zB ein System mittels RFC1918-Adressen zugreifen (DNS „jenkins.internal.company.com“ kann z.B. auch darauf zeigen), ohne euer lokales Routing weiter zu beeinflussen. Das wars.

Ihr bestimmt das lokal, der Server kann euch keine default route pushen, wie es bei anderen VPN-Lösungen der Fall ist. Ihr könnt/müsst Traffic für jedes Subnetz lokal freischalten (`AllowedIPs` in der WireGuard Config). Auch die Agents hinter einem NAT (z.B. in eurem Büro) können darüber eine zuverlässige, bidirektionale VPN-Verbindung aufbauen und halten, so wie es auch mein 12€ Raspberry Pi Zero seit Wochen schafft – trotz DSL-Disconnects und belastetem 2.4 GHz-Wifi-Band.

Lockdown

Entwickler sollten grundsätzlich keine Rechte zur Bearbeitung von Jenkins Jobs besitzen und es sollte eine Konvention sein, dass Testläufe und Auswertungen/Deployment-Hooks innerhalb des zu testenden Repositories gespeichert und damit versioniert sind. Somit gibt es auch ein Merge-Conflict-Handling und die üblichen Wege, sich mit seinen Kollegen über Änderungen abzustimmen (Issues, PR, Slack).

Jenkins-Jobs sollten ausnahmslos nur ein script aufrufen, z.B. `bin/ci` – innerhalb dieses Scripts im jeweiligen Repo erfolgt dann alles weitere, also die Trennung in „setup“, „test“, „report“, „deploy“, „teardown“ (oder das Container-Scripting, je nach Workflow).

Dieses/s Script/s müssen auch ausserhalb von Jenkins laufen können (deshalb z.B. eine Container-Lösung in Betracht ziehen), lokal auf Entwicklermaschinen oder einem anderen CI, auf das man eventuell in der Zukunft wechseln kann. Konfigurationen und Credentials sind deshalb ausnahmslos über Environment-Variablen zu übergeben. Auch hier hält man sich in Zukunft alle Wege offen.

Own the Test-Stack

Komplexere Plugins wie z.B. Android-Emulator sind problematisch: Hier werden Dinge in eine Web-Gui abstrahiert, die unter Umständen den Entwicklern selbst nicht bekannt oder geläufig sind. Als Non-Android-Developer habe ich keine Ahnung, was da genau passiert und so manche Frage an Android-Entwickler brachte auch keine Klärung. Das darf aber nicht sein. Auch hier gilt: Emulator-Setup, -Run und -Teardown gehören in Shellscripts innerhalb des zu testenden Repositories. Gerne auch zur Ausführung innerhalb eines Docker-Containers.

Jenkins selbst räumt trotz Plugin und Konfiguration nicht zuverlässig z.B. die Emulator-Dienste nach Test-Beendingung auf. Hierbei können undefinierte Zustände entstehen und CI-Läufe beeinträchtigen. Entweder räumt man mit Cronjobs und einer Frickellösung alter Prozesse ab, oder startet die Agents alle paar Tage neu, beides verletzt folgende Regel:

Agents = Stateless

Jenkins Agents (Slaves) sind zustandslos und müssen auch zustandslos gehalten werden: Keine testrelevante Konfiguration, keine Installation von Drittsoftware darf über die Test-Scripts installiert oder modifziert werden, keine Prozesse dürfen nach Abschluss eines Jobs „übrig bleiben“. Es ergeben sich sonst nicht mehr nachvollziehbare Versions-Zustände und Race-Conditions, die mit DevOps nicht mehr beherrschbar oder geschweige denn im Notfall wiederherstellbar sind.

Obacht, das gilt auch für Container. „Wie ist denn das Builder-Image vor 4 Monaten auf den Agent gekommen“ wollt ihr euch nicht fragen. Hier bietet sich zB der Einsatz eines Chaos-Monkeys ein. Zwischen Geschwindigkeit und Konsistenz muss sorgfältig abgewogen werden: Einmal im Monat alte Docker-Images löschen ist zwar besser als nie, es besteht aber ausreichend Zeit für Entwickler und Admins, dazwischen versehentlich Mist zu bauen. Dann läuft der Clean-up-Task und es gibt „keinen Zusammenhang“ zu der vor Wochen versehentlich gebauten Dependency. Weiterhin sorgt Docker’s Base-Image-Inheritance dafür, dass man auch nicht nach jedem Job „seine eigenen“ Images aufräumen kann, weil diese auch von anderen Projekten verwendet werden. Wenn man den Aufwand nicht scheut, kann man eigene dockerd-Instanzen pro Runner oder Projekt betreiben und so eine gegenseitige Einflussnahme verhindern. Multiple Dockerd-Instanzen pro Host sind jedenfalls kein Hexenwerk.

Kapseln mit Containern

Nutzt trotzdem, wo immer es geht, Docker um die Systemumgebung für Tests zu schaffen. Also das besagte `test/ci` script sollte ein ebenso im Repository hinterlegtes Dockerfile (eines, oder mehrere, oder docker-compose oder was auch immer) bauen, dann die Tests in diesem Container ausführen. So sind auch alle Build-Abhängigkeiten versioniert, als Teil des Dockerfiles.

Keine 20 Ruby-, Node oder Java-Versionen mehr auf Agent-Nodes!

Uptime rules

Wenn ihr ein verteiltes Team aus Entwicklern habt, die wirklich in jeder Zeitzone sitzen, dann könnt ihr auch nicht nachts um 4 den Jenkins-Master neustarten, ohne vom Kollegen, der gerade in Thailand arbeitet, via Slack einen Rüffel zu bekommen. Das macht Updates zu einer großen Herausforderung. Wenn dazu ein Mono-Repo kommt, kann man auch nicht einfach mehrere Jenkins-Setup parallel betreiben um die Auswirkungen auf einen Teil zu beschränken. Bleibt also in Ermangelung einer HA-Lösung nur das Festlegen eines regelmäßigen Wartungsfensters. Das ist nur möglich, wenn man zumindest die kritischsten Probleme noch ein paar Tage aussitzen kann, also im Jenkins-Fall die Security-Updates – auch hier wieder: Nutzt WireGuard um das Risiko und den Update-Druck zu reduzieren.

Responsible Hardware Use

Flaky Tests, also sich nicht konsistent verhaltende Testergebnisse, sind immer ein nerviges Problem. Im Zuge der Nachforschung und Bekämpfung solcher Anomalien könnte man auf die Ideen kommen, neben den Event-gesteuerten Testläufen (vi GitHub Hook) auch zeitgesteuert eine Ausführung durchzuführen („viel hilft viel“). Das ist per se gut, wenn man es 1-2x am Tag macht um schleichende Änderungen (z.B. durch Upstream/3rd party dependencies) zu testen. Geht man jedoch hin und sorgt durch eine aggressive Job-Crontab dafür, dass z.B. zwischen 20 und 6 Uhr alle Agents wiederholt, non-stopp, mit immer den gleichen Tests ausgelastet werden, nervt man einerseits den Admin gewaltig, denn der sucht händeringend eine Phase, in der man 10 Minuten downtime zum Upgrade einplanen kann.

Andererseits verschleisst die Hardware:

Zwar sind SSD/NVMe-Server mittlerweile z.B .bei Hetzner spottbillig, sodass man durchaus 10… 20… 50 Stück mieten kann, allerdings gilt das nur für die Standardausführung mit 2x500GB SSD/NVMe pro System. Zusätzliche oder größere SSD/NVMe SSD kosten mitunter mehr, als der ganze Server in der Standardausführung. Fährt man nun ein RAID-1 (Mirroring) hat man noch ca 400GB nutzbaren Speicherplatz, der von großen Monorepos schnell gefressen wird. Also fängt man notgedrungen an, die Systeme mit RAID-0 (Striping) aufzusetzen, denn schliesslich haben die Nodes ja keinen State…

Solche nächtlichen Build-Exzesse zur Bekämpfung von flaky tests sorgen dann aber dafür, dass SSD Wear Out innerhalb von wenigen Monaten die SSD zerstören, zumindest aber laut SMART bald ein Datenverlust auftreten wird. Mangels Mirroring (um ca. 900GB usable disk space zu erhalten) muss man also hier auch sofort das ganze System (automatisiert) neu aufsetzen. Und die zweite SSD fällt dann einige Wochen später aus und das Spiel wiederholt sich von vorne.

Ein Richtwert für die Lebensdauer bei Flash-Speichern: Maximale Lebensdauer in Schreibvorgängen (TBW) = mindestens 100x die Größe des Speichers. Moderne und hochwertige Flash-Speicher (bspw. Samsung EVO plus) schaffen auch 600 full writes – oder zumindest deckt die Gewährleistung diese Nutzung ab.

Man sollte also auch die Hardware sinnvoll einsetzen: SSDs reduzieren die Testdauer, was inbesondere den Entwicklern hilft, ein schnelles Feedback zu erhalten. Allerdings sterben sie „relativ“ schnell. Festplatten sind langsam, halten aber deutlich länger bzw. sind günstiger (d.h. 2-6TB pro Platte sind ausreichend und man kann problemlos ein Mirroring fahren). Nutzt das passende Werkzeug und verletzt euch nicht absichtlich selbst.

Fazit

Viele angesprochenen Probleme äussern sich bei Monorepos, bei einem zeitlich-geographisch verteilten Entwicklerteam, bei der Hook/PullRequest-Nutzung von Github.com (kein private Enterprise GitHub, GitLab etc) und durch komplexeren Build/Test-Umgebungen (insbesondere native Apps für diverse Plattformen) – auch wenn es ausreichend Gründe gibt, die genau diese Nutzung so rechtfertigen.

Ohne diese Anforderungen gäbe es schon lange keinen Grund mehr, überhaupt noch Jenkins zu verwenden: GitLab CI, Circle CI, Drone.io und die CI/CD-Pipelines der Cloud-Anbieter verfügen durchweg über eine bessere, aktuelle Architektur oder sind managed und lassen es dann auch überhaupt nicht zu, sich selbst in den Fuß zu schiessen.

TL;DR

Lasst die Finger von Jenkins oder verwendet es wie eine scharfe Chemikalie: Nur mit Schutzausrüstung. Haltet die CI-Konfiguration zu dünn wie möglich, dafür ausführlich Code und Beschreibungen in den jeweiligen Repos halten. Kein offenes Feuer. Nur mit Schutzbrille.

Also Docker, dazu Swarm. Alternativ Rancher, eventuell CoreOS. Und Kubernetes.

Wie es bisher ausging, ist bekannt: CoreOS und rkt sind tot, ebenso wie Docker Swarm. Der Swarm-Mode dümpelt noch im Docker-EE-Segment herum, ansonsten setzt Gott und die Welt auf Kubernetes.

Doch eine Sache ist bis heute nicht signifikant vorangekommen, nämlich das Bauen von Container-Images. Docker’s Buildkit hat zwar jüngst mal wieder ein paar nette experimentelle Features geliefert, wie z.B. ssh-agent zur Build-Zeit. Doch die grundlegende Dockerfile-Syntax wurde beibehalten und so richtig gute Alternativen gibt es nicht.

Und dann gibt es noch ein viel wichtigeres Problem: Externe Abhängigkeiten und Base-Images. Ich würde mal darauf tippen, dass 90% aller populären Container auf Docker-Hub auf Debian, Ubuntu oder Alpine Linux basieren und dann um proprietäre Repositories erweitert werden. So gut wie keiner baut sich selbst ein root Filesystem, gerade beim Einsatz einer privaten Registry ausserhalb der kommerziellen Docker-Hub-Angebote wie z.B. ECR, Azure’s Container Registry oder eine selbst gehosteten, muss man selbst regelmäßig dafür sorgen, dass die Base-Images aktualisiert und die eigenen Images neu gebaut oder gepatcht werden.

Weiterhin zeigen alle „etablierten“ Linux-Distributionen massive Schwächen beim Container-Einsatz. Sie sind schlicht nicht darauf ausgelegt. Bei Debian-basierten Dockerfiles sieht man die immer gleichen Patterns:

apt-get update; apt-get upgrade, apt-key adv –keyserver mit.wechselnder-erreichbarkeit.org… , add-apt-repository …; apt-get update; apt-get install –yes –no-install-recommends … rm -rf /var/lib/apt/lists/*

Nerv. Vergisst man mal etwas, ist das Image gleich 50MB größer. Dann gibt es mal ein neues gpg in Debian Stable und schon bricht apt-key adv  — und überhaupt ist Debian uralt. Also am besten gleich ein Backports oder Unstable-Base-Image…Von Init-Systemen (systemd) oder Cron innerhalb von Containern möchte ich garnicht erst anfangen.

Regelmäßig hat man damit dann Probleme, kann Images nicht einfach (automatisiert) erfolgreich neu bauen, weil Pakete bereits wieder aus Backports oder 3rd-party-Repos verschwunden sind – besonders aggressiv ist das Chrome Repo von Google.

Alpine Linux ist zwar wunderbar einfach gehalten, die Paket-Definitionen sind Shellscripts mit einem definierten set an Variablen und Funktionen/Callbacks, hier ein Beispiel.

Doch auch hier macht man sich wieder vom Tooling und der Motivation weniger Dritter abhängig, dass bestimmte Versionen und Pakete auch brauchbar und ggf. zeitnah bereitgestellt werden. So gibt es z.B. bei Alpine kein Mono für die ARM-Architekturen, weshalb auch mein Multi-Arch-Docker-Image für OpenRA (Open-Source-Nachbau von Command & Conquer Red Alert) auf einem Debian Base image basiert (bzw. das offizielle Mono Image) und nicht zu Alpine gewechselt ist.

Hat man also wiederholt die selben Schmerzen erlebt und sich Alpine angeschaut und geht dann nochmal zu Chef’s Habitat, ist man erstaunt: Auch dort sind Paketdefinitionen („Pläne“) als Shellscript verfasst mit definierten Variablen und callbacks. Klar strukturiert, einfach. Eine Datei zzgl. ggf. Patches.

Die Ähnlichkeit zu Alpine ist unübersehbar, allerdings geht es bei Habitat nicht um das Zusammenstellen einer Distribution, sondern um das Zusammenstellen von Abhängigkeiten diverser OpenSource-Software um dann zusammen mit der eigenen Anwendungen ein immutable Artifact zu bilden..

Man macht sich also komplett unabhängig von Distributionen, erhält ein vollständig offenes Framework (das auf Rust setzt und daher auch nicht die organisatorische Google-Go-Dependency besitzt) um selbst die Dependencies zu bauen und zu pflegen – oder verlässt sich auf den bldr-Service von Chef, für den es natürlich kommerzielle Nutzungs- und Servicemodelle gibt.

Mit Habitat erstellte Pakete können für unterschiedliche Ziele exportiert oder paketiert werden, also auch Docker. Und sie enthalten einen Supervisor, der auch Healthchecks und Updates übernehmen kann.

Wer All-In auf managed Kubernetes-Lösungen von AWS, Google Cloud oder Azure geht und zudem primär Anwendungen in Go oder Java entwickelt, wird vermutlich das Problem nicht haben, nicht verstehen oder lange Zeit ignorieren können, weil es so gut wie keine low-level Abhängigkeiten ausserhalb des eigenen Runtimes gibt (dafür dann eben im Go/Java-Projekt oder man „einfach das Linux vom Cloud-Anbieter nutzt“.

Für alle anderen könnte es durchaus eine Möglichkeit sein, den erodierenden Universal-Distributionen zu entkommen und vergleichsweise ressourcenschonend wieder selbst die volle Kontrolle über alle Abhängigkeiten zu erlangen. Also vielleicht nochmal anschauen…

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Accept YouTube Content

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Accept YouTube Content

Update 10.02.2019

Ein Beispiel-Build war sehr ernüchternd und exportiert als Docker-Image über 220MB größer (~30%), als meine aktuelle Debian-Lösung. Habitat hat dafür, neben des eingebauten Supervisors inkl. Orchestrierung, auch gleich zwei OpenSSL installiert, dazu auch 2x kernel headers und zu allem auch Manpages, alle möglichen Timezones, Locales und Charmaps. Sicher kann man die von mir genutzten „core“-Abhängigkeiten aus Habitat auch alle forken und dann dementsprechend „kleiner“ machen, aber letztlich funktionieren die Debian/Alpine-Frickellösungen aktuell noch immer viel zu gut.

Docker ist omnipräsent, ebenso wie es extrem günstige linuxfähige System on a Chip (SoC)-Geräte sind. Nach Beagleboard, Pandaboard, diversen Raspberry Pi etc sind wir bei 15€ pro System inkl. WiFi angekommen. Unfassbar für ein vollwertiges System, dessen Fähigkeiten für so manchen Büroarbeitsplatz ausreichen würden.

Die logische Konsequenz: Wenn man auf jedem Stück Blech die neuesten Linux-Distributionen und Kernel-Versionen laufen lassen kann, warum dann auch nicht Docker?

Man möchte allerdings die bestmöglichste Hardware (bzw Cloud-Service) zum Bau von Images für alle Plattformen nutzen und verwendet daher Cross-Compilation (typischerweise unter amd64/x86_64).

Die technischen Details sind nichts neues, deshalb erspare ich sie euch bis auf eine kurze Umschreibung: QEMU als Emulator, binfmt_misc um architekturfremde Binaries durch QEMU ausführen zu lassen. Und um das ganze mit Docker zu verheiraten, schiebt man das statische QEMU binary in den Build-Context und zwar an die Location, die man dem Kernel vorher global konfiguriert hat. Mehr dazu steht beispielsweise hier.

Zwei Dingen fehlten mir jedoch bis dahin:

1. Ich lasse Docker Hub automatisch Images aus GitHub Repositories bauen und möchte, dass Docker Hub mir für alle von mir gewünschten Architekturen automatisch Images baut.
2. Ich möchte einen gemeinsamen tag für alle Plattformen haben, d.h. egal auf welchem system docker pull rmoriz/multiarch-test:latest soll das passende Image zurückliefern.

Die Integration Dockerhub lässt sich mit etwas Shell-Frickelei lösen, hat man dort doch relativ großzügige root-Rechte, kann den gesamten Build-Prozess mit Shellscripts anpassen oder überschreiben und natürlich Pakete installieren. Sogar das Setzen von binfmt war problemlos möglich. Erstaunlicherweise war das größte Problem die dort eingesetze steinalte Docker EE-Version auf Client-Seite. Auch hier kann man glücklicherweise stattdessen ein eigenes, neueres Binary ausführen.

Um mehrere Architekturen hinter einem tag zu verbergen, muss man Manifests anlegen. Alles noch experimental, erfordert das neueste docker-cli und schlecht dokumentiert.

Der grobe Ablauf:

1. Installiere QEMU Pakete, eigener docker client
2. registriere binfmt handler
3. baue alle images mit jeweils eigenen Tags für jede Architektur
4. exportiere alle images auf festplatte, patche im Image-Manifest die Architektur auf die Zielarchitektur (hier wird IMMER die aktuelle dockerd-Architektur übernommen)
5. importiere den Kram wieder
6. pushe die Images in die Registry
7. Erstelle ein Manifest
8. Annotate das Manifest, damit die Archtekturen stimmen (eventuell durch 4. überflüssig geworden)
9. pushe das Manifest in die Registry
10. done

Große Frickelei, für euch an zwei Abenden durch trial+error gebaut:

Source Code hier: https://github.com/rmoriz/multiarch-test

Beispiel Log des Builds: https://gist.github.com/rmoriz/4204f1f30eeda3892248e797024ed794

Waren proprietäre Sprachen und Frameworks schon immer in allen Bereichen der Branchen präsent und verbreitet, so war dies fast immer auf Teilbereiche beschränkt: .Net auf Windows, Java für Enterprise-Anwendungen, Objective C für Macintosh. Dominierende OpenSource-Projekte der 1990er und 00er Jahre wie Perl, PHP, Python und Ruby waren allesamt „wirkliche“ OpenSource-Projekte einzelner Menschen und Unternehmen, ohne dass dort zwangsläufig eine absolute Dominanz ersichtlich war. Das lag natürlich auch an der auf (zugegeben sehr große) Teilbereiche der Software-Entwicklung. Wer Entscheidungen von Zend, der „PHP Company“ nicht mittragen wollte, hatte ausreichend Alternativen ohne nennenswerte Nachteile.

Mit der zweiten JavaScript-Welle änderte sich allerdings alles: Google dominierte damit den Interpreter (V8), die aktive Sprachentwicklung und den Browser. Was viele Menschen nicht verstehen wollten: Es ist eigentlich irrelevant, ob ein Unternehmen proprietäre Features baut, oder diese mit eigenen Leuten öffentlich als Standard definiert. Am Ende des Tages wurde das als de-facto oder „de-jure“ Standard beschlossen, was im Sinn der Konzerne war, namentlich bei JavaScript und HTML5 das, was Google wollte.

So war rückblickend die „Befreiung“ vom Internet-Explorer auch ein Pyrrhussieg. denn einerseits hat sich Google direkt (über Chrome) und indirekt (über die Beeinflussung von Mozilla) als neuer Platzhirsch der Standards etabliert. Aktuell arbeitet das Chrome-Team z.B. daran, die unliebsamen Adblocker ABP und uBlock Origin unbrauchbar zu machen: Es sollen Schnittstellen abgekündigt werden, die zwingend für ein aktives Adblocking notwendig sein sollen.

Auf der anderen Seite starb das Web mit der JavaScript-Welle, weil rudimentäre Tools wie selbstgeschriebene Suchmaschinen oder Text-Browser ohne JavaScript-Support und Client-Side-Rendering (das Google mit AngularJS gepusht hat) unbrauchbar wurden. Man hat so die Eintrittsbarriere in das profitable Kerngeschäft, nämlich eine durch Werbung finanzierte Suchmaschine, massiv erhöht und weiter die Marktanteile eigener Produkte zementiert.

Als drittes kommt dann die „Plattformisierung“ des Webs oben drauf: Content-Silos wie Facebook, YouTube oder Twitter töteten die ursprünglich verteilt angelegte Architektur des World Wide Webs. Statt einer Vielzahl von konkurrierenden und selbstverwalteten Alternativen gibt es im Web einzelne Monopolisten (YouTube, Whatsapp, Instagram, Facebook, Twitter).

Plattform-Modelle in Form von Betriebssystemen sind zwar uralt, aber erst seit Apple’s iOS gibt es einen harten Walled Garden. Konnte jeder Hobbyautor in den 1990ern Windows-Shareware entwickeln und vertreiben, so begann mit dem Apple Appstore der Untergang dieser freien Zunft: Nicht nur wird der Zugang irrational nach Gutsherrenart gewährt, sondern es wird auch noch großzügig Provision abkassiert.

Als ob diese beiden Beispiele schon nicht ausreichend, so hat sich dieser Trend auch auf Sytemsoftware ausgeweitet: Go ist das ideale Bespiel der geplanten Google-Dominanz. Zero dependency auf andere, existierende unabhängige OpenSource-Projekte, fast alles mittelbar zu 100% in der Hand von Google.

Wahrscheinlich erhofften sich Startups, die Go sehr früh eingesetzt haben, wie z.B. Docker und Hashicorp eine Partnerschaft oder einen Verkauf an Google, aber warum sollte Google Quellcode kaufen, der zu großen Teilen auf den Bausteinen der eigenen Entwicklung basiert und Nutzer bisher nicht exklusiv/hart an Google bindet?

Kubernetes orientiert sich z.B. nicht umsonst am Google-Architektur-Modell, kommt nicht umsonst mit Beispielen und „1st-class“ support für Googles Cloud-Services. Es geht hier darum, auch die gesamte Infrastruktur zu dominieren, wenngleich es hier mit Microsoft, IBM/Redhat und Amazon ebenfalls starke Konkurrenten gibt, die aber hier alle an einem Strang ziehen: Onpremise ist tot, verhafte die Kunden und melke sie bis zu ihrem Tod. Sie machen die Regeln, schreiben die Onboarding-Tools („OpenSource auf GitHub“) und liefern manchmal schon schlüsselfertigen Lösungen für die überschaubare jedoch alternativlose monatliche Zahlung von X$.

Am Ende steht die vollkommene Aufgabe der technischen Autonomie. Keiner soll mehr Software schreiben, verkaufen und betreiben können, ohne dass hierfür die Regeln und Preise von Google, Apple, Amazon oder Microsoft definiert werden.

Proprietäre Hardware, die sich diese Konzerne schon für ihre eigene Inhouse-Infrastruktur entwerfen und bauen lassen, stehen uns jedenfalls nicht zum Kauf offen, ja erfahren darüber auch so gut wie nichts. Wir müssen das verwenden, was auf dem Mainstream-Markt von Intel, AMD und den Mainboardherstellern angeboten wird. Stellt Apple nun wie schon lange erwartet auch macOS bzw. seine Macintosh-Linie von Intel/AMD64 auf proprietäre ARM/arm64 Prozessoren um, dann wird sicher auch ein anderer Player hier massiv Geld in die Hand nehmen und dies z.B. in der Cloud tun.

ARMs Patente und Architekturmodelle sind zwar gegen Geld lizenzierbar, doch das Salz in der Suppe sind die proprietären Erweiterungen und Designs, die Leistungsparameter und Energieverbrauch ausmachen. Diese zu Entwickeln und Umzusetzen kostet sehr viel Geld und erfordert Spezialisten-Know-How. Früher konnte deshalb ein Unternehmen nur wirtschaftlich überleben, wenn es durch den Verkauf der entwickelten (und produzierten) Chips einen Profit erzielt, also das „alte“ Modell eines Halbleiterherstellers (Intel, AMD).

Die oben angesprochenen Konzerne sind allerdings so vermögend, dass sie hier nicht mehr gezwungen sind, ihre Chips auch Dritten zugänglich zu machen. Es reicht eine kuratierte Software-Schnittstelle/ein SDK anzubieten und die Hardware dann in Form von Cloud-Produkten/Abos zu vermieten. Ohne Probleme wird z.B. Google ein paar Milliarden $ in Entwicklung und Produktion für Microchips investieren z.B. optimiert auf das eigene Tensorflow ML/KI-System zum exklusive Einsatz in der eigenen Cloud.

Somit werden wir dann alle endgültig zu Leibeigenen.

Mit Glück dürfen wir ein paar Brotkrumen aufsammeln, die uns die Großkonzerne überlassen, wenn wir unser gesamtes Arbeitsleben in von ihnen aus einer Hand kontrollierte Sprachen, Frameworks, Plattformen und Hardware investieren.

Und als Konsumenten zahlen wir natürlich auch dafür, dass Siemens, VW, Deutsche Bahn und sich diese proprietäre Hard- und Software in der Cloud mieten dürfen. So wie wir es seit 40 Jahren indirekt schon für SAP tun. Nur eben jetzt viel, viel umfänglicher.

Neben des C&C-Gameplays und liebevoller 90er-Jahre Grafik ist auch der Teamchat genau auf dem Niveau der vergangenen Zeit: Politisch unkorrekt und teilweise auch aggressiv trollt und spielt man, wie in alten Zeiten. Erfahrene Spieler tarnen sich als Newbies, Newbies ruinieren Multiplayer-Matches… lautstarke Trump-Trolle trollen andere lautstarke Trump-Trolle. So wie das Leben eben spielt.

Ich spiele fast ausschliesslich Red Alert, das populärste Mod, und bin vermutlich ein ganz guter Spieler.

Nach einer Zeit fast immer erfolgreichen Angriffstaktik mittels „V2 rush“ (Soviets) spiele ich seit einigen Wochen nur noch Allies (primär Briten) und trainiere meine Skills im Einsatz von Spionen. Das Scoring belohnt Spionage-Einsätze aktuell sehr wohlwollend und zudem sind die Gegner extrem genervt, wenn man 20 Spione in deren Raffinerien schickt und sie ich dann auch 20 Mal hintereinander machtlos „CREDITS STOLEN!“ anhören dürfen.

Deshalb hier ein paar Ratschläge für eine erfolgreiche Spieler-Karriere:

Nur wenige Anfänger kapieren die ökonomischen Grundlagen des Gameplays: Harvester (Ernter) müssen Mineralien oder Erz sammeln und diese zu Raffinerien bringen. Ernte und Fahrt kosten Zeit und somit muss man hier auf sehr kurze, effiziente Wege achten, um den konstante Cash-Flow zu sichern und rasch durch zusätzliche Harvester und Refineries ausbauen zu können.

Weiterhin verstehen viele Spieler nicht, dass man – wie auf dem Fussballfeld – Räume besetzen muss, um dem Gegner Wege abzuschneiden. Um diese Räume besetzt zu halten, muss man weitere Basen bauen oder mehr oder weniger aggressiv seine Basis nach vorne verlegen (rush/pushing). Letzteres erfordert massive, koordinierte Team-Unterstützung (inkl. Chat) und ist je nach Map (Karte) sinnvoll oder Harakiri.

Der dritte Punkt, den viele Anfänger nicht verstehen: Man muss den Gegner beobachten, also auskundschaften (scouting). Hierzu sollte man möglichst einzelne, relativ günstige Einheiten produzieren und in ordentlichem Abstand zur eigenen Basis aufstellen. Natürlich sind diese Einheiten bei einem gegnerischen Angriff sofort vernichtet, dafür hat man einerseits aber eine Angriffs-Früherkennung und andererseits kann man im späteren Verlauf dadurch auch Ziele und gegnerische Verteidigungseinrichtungen ausmachen — bevor man seine ganze Armee verbrät. Im späteren Spielverlauf sollte man unbedingt einzelne Hubschrauber oder Flugzeuge an neuralgischen Plätzen aufstellen/kreisen lassen, da diese eine größere Sichtweite haben.

Eigentlich alles ziemlich logische und nach wenigen Matches begreifbare Konzepte. Leider gibt es aber viele Spieler, die das nach Wochen nicht kapiert haben und somit die Teamleistung reduzieren. Das ist ärgerlich.

Wenn ihr also OpenRA spielt, beachtet bitte meine Hinweise.

Parallel verlegt man aufwendig Lichtwellenleiter (Glasfaser) immer näher zum Kunden (VDSL, Vectoring, FTTC) oder gleich ins Haus/Wohnung (FTTB/FTTH). Trotzdem gibt es in jedem „Vorzeigeland“ Regionen, in denen das auf absehbare Zeit nicht passieren wird. Sogar in der Schweiz, in Frankreich und in den Niederlanden.

Schon vor Jahren kam man deshalb auf die Idee, die verfügbaren Zugangswege (also Festnetz und Mobilfunk) zu bündeln und dadurch Kunden in diesen Regionen gesteigerte Bandbreiten anzubieten. Leider ist das nicht so einfach, wenn zwei oder mehr Transportwege sich in vielen Parametern unterscheiden (Latenz, Bandbreite, Nutzungsspitzen, Zuverlässigkeit).

In Deutschland gibt das Unternehmen Viprinet, dass eine proprietäre, closed-source Lösung mit eigener Hardware verkauft und damit seit Jahren auf Unternehmenskunden zielt. Die Telekom hat seit ein paar Jahren eine technisch eher schwache Lösung (auf GRE-Basis) am Start, die – soweit ich mich erinnere – von Huawei entwickelt wurde.

Wohingegen an der katholischen Universität in Löwen (Louvain) in Belgien seit über 10 Jahren an einem offenen Standard und offenen Implementierung gearbeitet wird. Der führende Entwickler ist seit Jahren bei Apple tätig und hat dort das von ihm mitentwickelte MPTCP (multipath TCP) in iOS implementiert. Siri als Anwendung setzt beispielsweise seit iOS 7 darauf um dynamisch WiFi und 4G zu bündeln.

Andere Mitglieder des Teams haben 2014 daraus ein Software-Unternehmen gegründet und bieten kommerzielle Services für Telcos an, während sie parallel die freie Weiterentwicklung vorantreiben und dafür in Gremien wie der IETF aktiv sind.

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Accept YouTube Content

Unterstützt werden sie unter anderem von der Swisscom, von KPN und dem französischen Provider OVH, die bereits alle kommerzielle Rollouts durchgeführt haben und MPTCP für die Anbindung von Kunden einsetzen. Hier ein Werbevideo von KPN über den Einsatz in den Niederlanden:

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Accept YouTube Content

Auch die EU förderte das Projekt im Rahmen des Programmes Horizon 2020.

Da fragt man sich dann schon, warum sowas in Belgien erdacht und entwickelt und im europäischen Ausland, von Apple global und Samsung regional in Korea erfolgreich ausgerollt und betrieben wird, aber an keiner deutschen Hochschule, an keine Fraunhoferbude und auch nicht bei einem „Technologie-Unternehmen“ wie der Deutschen Telekom eine ebenbürtige Lösung entwickelt werden konnte, geschweige denn ein offener Standard inklusive einer freien, für jedermann nutzbaren Referenzimplementation. Nein, ohne Huawei geht nichts mehr.

Überhaupt spielen deutsche Hochschulen, Forschungseinrichtungen und Unternehmen (inkl. DAX/TecDAX/MDAX-Konzerne) quasi keine Rolle, was die technologischen Grundlagen des Internets und seine Weiterentwicklung angeht.

Bezieht man die Landesgröße, Einwohnerzahl, die Anzahl der Hochschulen, die Konzerngrößen und den ganzen Bohai um „Digitalisierung“ mit ein, ist das Resultat für Deutschland mehr als beschämend.

Den gesamten Satz der Internet-RFCs seit 1969 gibt es hier zur Analyse: https://www.rfc-editor.org/retrieve/bulk/

Wer hingegen jetzt trotzdem auf den Geschmack von Kanalbündelung gekommen ist und es selbst ausprobieren möchte: Das Projekt https://www.openmptcprouter.com/ stellt sowohl auf OpenWRT basierte Images für Router und Raspberry PIs bereit, als auch Images für den Betrieb der Gegenseite z.B. in der Cloud. Alles OpenSource. Grüßen und Dank nach Frankreich.

https://kirill888.github.io/notes/wireguard-via-websocket/

Senator Ron Wyden (D) aus Oregon ist bereits 69 Jahre alt und hat sich in der Vergangenheit auch schon kritisch über die Aktivitäten von ZTE/China und das Thema Wahlbeeinflussung durch Hacks geäussert.

Seine Bitte an das NIST, das National Institute of Standards and Technology, WireGuard als Option für den Regierungs- und Verwaltungseinsatz zu evaluieren, kann man sich hier ansehen. (PDF Original)

Bei uns haben neben oben genannten Bevölkerungsteilen auch quasi alle deutschen Unternehmen dieses Thema bereits längst outgesourced und sich teure Appliances angeschafft (Kombination aus Hard+Software mit Servicevertrag) oder auf cloud-basierte VPN umgestellt. Die liegen nicht nur ausserhalb der eigenen technologischen Verantwortung sondern sorgt „mit Sicherheit“ auch dafür, dass keinerlei lokales Know-How erhalten oder aufgebaut wird. Die Ausrede „es ist ja eh nur OpenSource“ trifft zwar zu, aber was, wenn man keine Leute mehr finden und bezahlen kann, die noch verstehen, was die Software im Detail macht?

So wird man also noch etwas abwarten müssen, bis die üblichen, dominierenden Software- und Cloud-Anbieter wie Amazon, Cisco, Juniper, Huawei ihre VPN-Produkte aktualisiert haben und dann auch WireGuard einsetzen, vermutlich aber absichtlich in einer inkompatiblen und kryptographisch geschwächten Version…

Achja, es gibt ja noch diese streng geheime SINA-Box mit proprietär-germanischen Hochleistungs-Krypto-Algorithmen. (Siehe auch: Libelle). Gottseidank ist Deutschland das einzige Land auf diesem Planeten, in dem Security-by-Obscurity funktioniert (oder auch nicht). Enigma lässt grüßen.

PS: WireGuard setzt auf ChaCha20, Poly1305, Blake2s und Curve25519 – bis auf Blake2s stammen alle genannten Verfahren aus „der Feder“ von djb (Daniel J. Bernstein). Immerhin besitzt djb auch die deutsche Staatsbürgerschaft.

Wie der WireGuard-Autor wiederholt bei Vorträgen zu WireGuard gesagt hat, war eines der Ziele ursprünglich das zuverlässige, sichere Exfiltrieren im Rahmen von offensive security-Projekten, nicht unbedingt ein general purpose VPN.

Deshalb ist WireGuard auch das Gegenteil von Geschwätzig und sendet by default keine Keepalives, weshalb man hier selbst Hand anlegen muss. Es gibt auch kein Schlüsselaustauschprotokoll, kein dynamisches Routing oder Mesh. Man solle die Tools verwenden, die man eh schon hat z.B. DevOps für Schlüsselverwaltung oder eben bgp für dynamisches Routing.

Auf der anderen Seite des Spektrums befindet sich ein anderes OpenSource-Projekt namens „ZeroTier„: Ein Software Defined Network mit zentralem Controller, der auch Verbindungen zwischen zwei ge-NAT-teten Clients ermöglicht und noch viel mehr. Ähnlich wie z.B. auch bei Syncthing gibt es Relay-Nodes die Traffic notfalls auch durchleiten, sollte zwischen Teilnehmern keine direkte Verbindung möglich sein.

Das alles klingt erstmal sehr gut, andererseits steht dahinter ein US-Unternehmen welches VC erhalten hat und damit auch ordentlich Geld verdienen muss: Der „Controller“ ist eine Cloud-Lösung und bisher nicht OpenSource bzw. nur eine veraltete Version davon ist frei verfügbar. Meines Wissens regelt der Controller auch, wer einzelnen SDN beitreten darf und könnte so auch für z.B. die NSA von Interesse sein…

Ob und wie man so eine SDN-Lösung ohne Abhängigkeiten (Discovery/Relay/Management) zu einem Unternehmen betreiben kann, bleibt offen. Für die nächste ZeroTier-Version ist eine Multipath-Unterstützung geplant, sodass man verschiedene Anbindungen bündeln kann (bonding).

Das geht mit WireGuard unter Linux (und nur dort) wahrscheinlich auch, wenn man auf beiden Seiten Kernel mit MPTCP-Unterstützung am Start hat. Aus dem OVH und Free-Umfeld in Frankreich stammen viele Projekte um MPTCP und Uplink-Bündelungen, bei denen bisher zB shadowsocks eingesetzt wird.

Unabhängig von WireGuard interessant, wenn man unter einer angespannten Breitbandversorgung, insbesondere beim upstream, leidet. Ich erhoffe von diesen Projekten auch eine Evaluierung von WireGuard für die Bonding-Zwecke und versuche immer mal wieder die Updates zu verfolgen:

Linkliste:

• https://www.ovhtelecom.fr/overthebox/ (In Frankreich kommerziell angebotene Lösung von OVH)
• https://github.com/ovh/overthebox (Repo dazu)
• http://zehome.github.io/MLVPN/
• https://github.com/Ysurac/openmptcprouter

Das Abrufen der gesamten Liste ist noch gratis…

… doch leider hat die IEEE die Adresse der Liste geändert (vermutlich schon in 2015), sodass sämtliche Bordmittel verbreiteter Linux-Systeme zur Aktualisierung nicht mehr funktionieren, beispielsweise das Aktualisierungs-Script des „ieee-data“ Packages in Debian, das zudem der motivierte Debian-Betreuer des „aircrack-ng“ Paketes auch statt der lange aktualisierten upstream-Version von „airodump-ng-oui-update“ einsetzt…

Vermutlich setzen auch dutzende andere Tools auf die ehemalige URL „http://standards.ieee.org/regauth/oui/oui.txt“ und laufen seit einigen Jahren ins Leere.

tcpdump hingegen kann dies nicht passieren. Es gibt schlicht keinen Code, die Liste in das binary einzubauen oder – sehr viel sauberer – extern anzubinden. So findet sich weiter der Hinweis „/* FIXME complete OUI list using a script */“ in der Datei oui.c.

2014 traute sich ein Anwender zu fragen, was das soll: „Make it better“ war die Antwort.

Schaut man sich allerdings die offizielle Datenquelle bei der IEEE an, wird einem Angst und Bange: „The world’s largest technical professional organization dedicated to advancing technology for the benefit of humanity.“ schafft es nicht einmal, ihre trivialsten Datensätze zu normalisieren.

Und so gibt es wieder andere Tools und Datenanbieter, welche die Daten aufbereiten. Beispielsweise https://linuxnet.ca/ieee/oui/

Spätestens jetzt sollte man eigentlich fragen, ob Informationstechnologie wirklich etwas gutes ist und warum so viel Versagen an kritischen Punkten zugelassen wird. Jeder von uns „Professionals“ wühlt täglich im Schlamm (oder den Exkrementen) unserer Branche, einige waschen sich bei Feierabend nicht mal die Hände…

Wäre ich Ermittler beim Brandenburger LKA, ich hätte mir 100 Raspberry PIs besorgt, darauf Kismet installiert, diese mit Powerbanks quer über das Land verteilt (oder fliegend in Polizeifahrzeuge verbaut) und würde mir sämtliche Daten in der Cloud sammeln und auswerten. Der Aufwand hierfür liegt im niedrigen fünfstelligen Bereich, mit 3G/4G Upstream etwas höher.

Darüber bekäme man nicht nur mit, wann und wo diese MAC-Adresse auftaucht, sonder auch in welche Netze sie sich einbucht (und welche anderen MAC-Adressen dies ebenfalls tun). Man kann dann vor dem Zugriff auch ermitteln, zu welcher Tageszeit welcher Client aktiv ist und so den Zugriff mit Spezialkräften planen. All das bläst jedes WiFi-Gerät in die Luft und ist auch ohne Überlistung der WPA2-Verschlüsselung auswertbar: In den Metadaten stecken alle notwendigen Informationen.

Vermutlich ist mit diesem Gang an die Öffentlichkeit diese Chance vertan, der Täter dürfte das Gerät vermutlich jetzt spätestens vernichtet haben.

Hier ein aktuelles Video zu Kismet, dem Tool für WiFi-Analyse der Wahl:

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Accept YouTube Content

So langsam kommt bei mir wieder Nostalgie auf: Damals, in 2002, wie ich mit einem Firmen-Notebook und privater 802.11b PCMCIA/PC-Card, Kismet und Netstumbler per Straßenbahn „WarDriving“ in München betrieben habe

(Deshalb besitze ich bis heute auch noch die Domain wardriving.de )

Robert Habeck wurde, wie einige andere Politiker und Social-Media-Leute, Opfer einer Cracker-Attacke. Vermutlich eine Person hat sich Zugang zu diversen Accounts beschafft, ob Social Media (Twitter/Facebook), Mail oder Cloud-Speicher. Soweit man weiss, haben die Betroffenen dort weder verfügbare 2-Faktor-Authentisierungen genutzt, noch sonstige Vorkehrungen getroffen, um solche Attacken durch Selbstschutz zu verhindern (sichere, lange, einfach genutzte Passwörter – zB mittels Passwortmanager).

Nun sind also persönliche Daten und teilweise auch Dinge aus dem familiären Umkreis veröffentlicht worden und die Betroffenen leiden, gut nachvollziehbar, unter einem Trauma (ähnlich Einbruchs- oder Überfallsopfer).

Es macht die Sache auch nicht besser, dass selbsternannte Netzpolitiker wie Konstantin von Notz (Grüne) zu den stark betroffen gehören, wo man doch vielleicht gerade von ihnen etwas mehr Sorgfalt im digitalen Alltag erwarten hätte können?

Wie auch immer: Selbst Habeck forder nun eine „harte Hand“: Der Staat solle „die Sicherheit im Internet“ überwachen, vorschreiben, sicherstellen, sich in die Passwortvergabe einmischen und Anbieter und Nutzer „zwingen“. Gleichzeitig werden Forderungen aus allen Lagern gegen das BSI und BMI Seehofer erhoben, man hätte doch schon Anfang Dezember die Tweets lesen müssen, in denen die Dokumente geleaked wurden.

Also eine Forderung nach Massenüberwachung von Tweets, Facebook und des Webs durch das BND-nahe BSI? Vorratsdatenspeicherung aller in Deutschland „produzierten“ Tweets? Oder gleich IP-Verbindungen?

Habecks heutige Äusserungen zeugen davon, dass er absolut keine Ahnung von IT-Sicherheit und Bürgerrechten hat, wenn er sich bei so einer „harmlosen“ und selbsverschuldeten Aktion sofort zu einem rechtskonservativen Hardliner wandelt, statt sich zuerst die eigenen Missstände einzugestehen und an die Verantwortung jedes IT-Nutzers zu appellieren.

Das BSI gibt seit Jahren diverse Leitfäden heraus (IT-Grundschutz, BSI für Bürger) mit durchaus sinnvollen Empfehlungen, die persönliche und auch unternehmerische IT-Sicherheit zu verbessern. Auch 2FA und andere Dinge sind dort erfasst, aber werden von der breiten Masse inkl. MdBs aus Faulheit und Inkompetenz nicht umgesetzt.

Die Ursachen hinter dieser digitalen Inkompetenz vieler Bürger und fast aller Bundespolitiker, egal welcher Partei, ist vielschichtig:

Einerseits rein monetär: Wer etwas in der IT kann, wird sich nicht auf eine schlecht bezahlte und von vielen externen Faktoren (Partei, Wähler) abhängige Karriere einlassen sondern schlicht eine IT/InfoSec-Karriere verfolgen und in Ruhe gelassen werden. Ähnliches gilt für eine Laufbahn im Öffentlichen Dienst.

Andererseits hat es Deutschland als Nation digital so richtig verkackt: Nicht einmal in der theoretischen Informatik gibt es in Deutschland international nennenswertes Know-How, von der praktischen Ausbildung ganz abgesehen.

Man hat in Deutschland in den letzten 40 Jahren nie nennenswert Hardware (bspw. Prozessoren) entwickelt, so wie z.B. in Großbritannien mit Acorn, aus dessen Umfeld später ARM und auch die großartigen Edu-Projekte BBC Micro (1980er), Microbit und natürlich Raspberry Pi entstanden und bis heute einen Prozessor-Technologiecluster um Cambridge „füttern“.

Alles, was von Siemens, Schneider, Nixdorf oder gar von Robotron in der DDR gebaut wurde, basiert auf (un-)lizenzierter Technologie aus den USA (oder heute eben auch von ARM aus UK). Die einzige Fabrik, welche immerhin Mainboards in Deutschland herstellte, wird bis 2020 geschossen.

Auch im Bereich Systemsoftware wurde in Deutschland die letzten 35 Jahre nichts geleistet: Linux, Windows, macOS als Betriebssysteme aber auch Programmiersprachen und Internet-Standards sind in Deutschland nicht nennenswert entwickelt worden oder als Bonsaiprojekte zur Erlangung eines Hochschulabschlusses (also nur für den Mülleimer, nicht für die Praxis).

Das Windows-Monopol bei den Endbenutzern in den 1990ern tat den Rest, man wurde hier zum schlichten Anwender dressiert und das ist bis heute so, erfasste sämtliche Bildungseinrichtungen und Ausbildungspfade: Selbst Fachinformatiker werden nur dazu ausgebildet, ein Windows-System zu administrieren oder in Java zu programmieren und sind diesen System auf Gedeih und Verderb ausgeliefert.

Auch in meiner beruflichen Laufbahn *in* der IT-Branche erlebte und erlebe ich in Deutschland selbst in IT-Abteilungen in strategischen „Online/E-Commerce“ vollkommenes Unwissen über die Grundlagen unserer Computer und Netze und das auch noch 2019. Wie etwas funktioniert, warum etwas funktioniert, nach welchen Standards und wie diese Standards zustande kamen und weiterentwickelt werden: Völlig unbekannt. Einrichtung von simplen Dingen wie Mail-Accounts? 95% der Nutzer sind überfordert, obwohl sie „im Internet Geld verdienen“ wollen.

Nicht umsonst rate ich daher dem motivierten Nachwuchs mit starkem privaten Engagement in unserem Sektor sich bei erstbester Gelegenheit nach dem Abitur oder den ersten Semestern ins Ausland zu verabschieden, insbesondere natürlich in die USA, meinetwegen aber auch in die Schweiz. Ansonsten wird man hier im Laufe seines Lebens einen hohen persönlichen Preis für das digitale Versagen der Gesellschaft, Wirtschaft und Politik bezahlen:

Wir entwickeln Software auf Systemen, die Unternehmen aus den USA für uns entwickelt haben auf Computern, die US- oder chin. Unternehmen in Asien für uns gebaut haben, in Programmiersprachen, die meist US-Unternehmen für uns entwickelt haben. Und das ganze läuft später dann in der Cloud von US-Unternehmen wie Amazon, Microsoft oder Google. Versteuert wird auf Bermuda.

Deutschland ist digital bankrott.

Selbst in Brexit-Großbritannien ist, entgegen der Darstellung in unseren Medien, die Digitalisierung viel weiter fortgeschritten als bei uns: Hinter https://www.gov.uk/ gibt es nicht nur ein breites Bürgerportal sondern eine große Digitalisierungs-Abteilung mit Entwicklern, Projektmanagern und Designern, die seit Jahren Services für Bürger und Behörden umsetzt. Und zwar nach modernsten Vorgehensweisen der IT mit einem öffentlichen Handbuch/Leitfaden, das vielen privatwirtschaftlichen IT-Unternehmen(!) in unserem Land überlegen ist.

Viele dorrt entwickelten Webanwendungen und Dokumentationen sind quelloffen auf GitHub und wären auch für uns verwendbar (wenn auch nur als Inspiration), würde es jemand begreifen und anwenden.

Kein Politiker begreift es bisher, weder von den Grünen noch der FDP. Von SPD und Union ganz zu schweigen. Meines Wissens kann kein einziger MdB programmieren, sämtliche angeblichen „IT-Unternehmer“ aus dem FDP-Lager hatten Media-Agenturen/Werbeagenturen und Webdesign-Klitschen um 2000, die allesamt insolvent gingen. Nennenswerte Software oder gar Hardware wurde nicht produziert.

Wenn man also jetzt selbst vom „liberalen“ Lager eine staatliche Intervention fordert, dann ist das nichts anderes, als endgültig eine Mauer bauen zu wollen: Staatliche Hürden gegen Innovation, die man selbst nicht liefern oder mitgestalten kann. Solche eine Abschottung ist zum Scheitern verurteilt, wie die DDR oder andere nationalistischen Systeme, die gegen „Globalisierung“ und Marktwirtschaft nichts anderes zustande bekommen, als sich selbst meterhoch im eigenen Dung einzugraben, auf bessere Zeiten zu hoffen und irgend einen ausländischen Sündenbock für das eigene Versagen verantwortlich zu machen.

Im übrigen: Wenn in Deutschland eine zweite Fremdsprache eine Voraussetzung für eine Hochschulreife ist, warum nicht auch eine Programmiersprache?

PS: Die Entscheidung Habecks, Twitter- und Facebook-Accounts stillzulegen ist eine gute Entscheidung, die ich auch umgesetzt habe. Diese Plattformen sind toxisch, man feindet sich laufend an und rotzt emotionale Meinungen in die Welt. Für sachliche Diskussionen oder gar Überzeugungsarbeit ist kein Platz und dementsprechend ist das ganze für alle Beteiligten unproduktiv. Lernt lieber z.B. Programmieren.

Nach ersten Versuchen mit einem „billigen“ (ca 15€) China-Restposten-DVB-T USB-Stick mit R820T Tuner habe ich etwas Geld in die Hand genommen und mir über Amazon.de den NooElec NESDR SMArTee XTR inkl. Zubehör besorgt.

Der dort verbaute E4000 Tuner kann noch ein etwas breiteres Spektrum inkl. ~1800 MHz empfangen, als die sonst üblichen R820T/T2 Tuner, allerdings mit einem „Loch“ im Bereich von ADS-B, ist dafür also nicht geeignet. Im Lieferumfang sind ein Magnetfuss und drei Antennen-Aufsätze enthalten.

Während ich mit dem bisherigen „Billo“ RTL2832U R820T im „alten“ 900MHz-GSM-Frequenzbereich gerade mal 2 Base Stations empfangen konnte, schaffe ich mit dem Nooelec (Link zum Hersteller) deutlich mehr:

Hier das Ergebnis eines kurzen Sniffs mit https://github.com/Oros42/IMSI-catcher auf 1854.0M. Die erste Spalte enthält einen Zähler neuer/eindeutiger Geräte, Spalte vier beinhaltet die IMSI, dahinter folgen Land und Provider/Heimatnetz.

In Anbetracht der vielen Bänder und der Datenmenge (innerhalb von ca 15 Sekunden) ist es allerdings nicht besonders realistisch, hier ein Tracking aufzubauen: Der Tuner kann nur eine Frequenz gleichzeitig empfangen und somit müsste ich einen ganzen Haufen Empfänger parallel betreiben. Mit der Migration zu VoLTE wird vermutlich auch bald diese Möglichkeit der Metadaten-Erfassung nicht mehr für 15-50€ pro Frequenz möglich sein.

Und passend zum Thema empfehle ich einen der inhaltlich stärksten Vorträge des vergangenen 35C3:

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Accept YouTube Content

Nun leben wir in Zeiten, wo sich alle Menschen unbewusst überwachen lassen und das sogar passiv. Schienen RFID-Attacken auf Personalausweise, Gesundheitskarten oder vom Hersteller in Textilien eingenähten Tags mit großen Antennen etwas weit hergeholt, geht es mit Funkverbindungen sehr viel einfacher:

Jeder von uns trägt ein Smartphone oder eine Smartwatch bei sich, manche sogar mehrere. Die Smartphones buchen sich in Mobilfunknetze ein und halten ständig Kontakt zum nächsten Sendemast, senden regelmäßig Datenpakete um den jeweils am besten zu erreichenden zu ermitteln.

Und genau das tun auch alle WiFi-Clients: Sie senden regelmäßig Anfragen um für sie bekannte WLAN-Netze zu ermitteln und dann ggf. automatisch zu verbinden.

Beides lässt sich passiv mitschneiden und auswerten.

Für GSM eignet sich z.B. ein alter DVB-T USB-Stick für 15€: Hierbei werden die IMSIs (Weltweit eindeutige Nummer zur Identifikation des Subscribers) der SIM-Karten und dadurch auch das jeweilige Ursprungsnetz übertragen.

Tools:

• https://github.com/Oros42/IMSI-catcher

Bei WiFi ist es die MAC-Adresse des Gerätes bzw. eine zufällig generierte und eine Liste der bekannten SSIDs, also Netzwerknamen. Zwar wird die MAC-Adresse, also die weltweit eindeutige Hardware-Adresse verschleiert, aber das spielt keine Rolle, wenn die gesuchten SSIDs eindeutig sind.

Tools:

• https://github.com/hkm/whoishere.py
• https://github.com/xdavidhu/probeSniffer

Beide Vorgehensweisen sind rein passiv, man sendet nichts, man knackt keine Verschlüsselung, man hört einfach nur mit, was im Klartext übertragen wird. Was man dann damit macht, ist das Entscheidende: Will man Personen erkennen, so muss man entweder einmalig eine eindeutige Zuordnung durchführen, also wissen, wann eine Person in der Umgebung war und welche Metadaten man davon aufgezeichnet hat.

Die sofortige Identifikation gelingt vermutlich nur bei wenigen Teilnehmern/Signalen oder falls man durch die Signalstärke eindeutig einen nahegelegenen Teilnehmer ausmachen kann.

Paketboten tragen aber üblicherweise mindestens ein Smartphone mit sich herum, schlagen regelmäßig hier auf und sind über den Zeitpunkt zuordenbar:

1. Man schreibt sämtliche Metadaten über eine Woche mit
2. Man erfasst jeweils den Zustellzeitpunkt
3. Man gleicht die Daten ab
4. Man entfernt alle Teilnehmer, die auch 6 Stunden früher oder 6 Stunden später erfasst wurden (Nachbarn)

Spätestens nach einigen Tagen sollte man daraus eine sehr kurze, vielleicht sogar eindeutige Liste generieren können, die man immer weiter eindampfen kann.

Bleibt natürlich das Problem, dass sich das Personal häufig abwechselt oder ausgewechselt wird. Hier müsste man nun schauen, ob über die WiFi-Liste nicht z.B. eine eindeutige Netzkennung ermittelbar ist, z.B. die WLAN-Netze innerhalb eines UPS/DPD/DHL/Hermes/GLS-Depots?

Letztlich sieht man, wie viele Metadaten von uns für jeden abgreifbar sind und mit etwas Datenerfassung, weit jenseits von dem, was man als „big data“ bezeichnet, personalisierbar sind. Stellt man sich nun ausreichend Energie vor, so könnte man auch noch viel genauere Bewegungsprofile erstellen, wenn man regionale verteilte Sammelstellen aufstellt, die erfassten Kennungen in Echtzeit in die Cloud schieben, wo sie dann zusammengefügt bzw. ausgewertet werden.

Die Kosten sind minimal: Rasperry PI 3, dazu ein RTL-SDR-fähiger DVB-T-Stick für die GSM-Signale und Kali-Linux oder 15 Minuten Gefrickel um den Monitor-Mode auf einem Raspbian zu aktivieren.

Und was fällt uns nach GSM und WiFi ein? Genau. Bluetooth.

Gerade im libertär-konservativen Bereich beginnt man zu erkennen, dass hier nicht nur alt-right-Nazis „ohne Prozess“ ausgeschlossen werden, sondern eben dieses Mal auch Leute aus dem „normalen“ Spektrum. Sexworker, welche üblicherweise eher links verortet sind, haben schon vor Jahren ihre Accounts bei PayPal verloren und waren vor einigen Monaten auch bei Patreon wieder auf der Abschussliste, wieder sollen die Kreditkarten-Betreiber auf Basis ihrer Risk-Management-Policy eingeschritten sein.

Auch bei uns erkennt man die Macht der Kreditkartenunternehmen: So fallen z.B. fürs Lotto-Spiel zusätzliche Gebühren an in saftigen Höhen: 5€ pro Vorgang! Nun wird man das wohl mit „gestiegenem regulatorischen Aufwand und Zahlungsausfallrisiken“ begründen, ist aber letztlich nichts anderes, als eine Diskriminierung. So wie Facebook und Instagram pauschal blanke Nippel bestrafen, weil manche Teile der USA oder restlichen Welt damit nicht umgehen können, so wird der Zahlungsverkehrs-Filter nun global ausgerollt.

Ausnahmsweise hat hier Europa mit dem SEPA-Zahlungssystem eine wirklich brauchbare Alternative mit ca. 524 Millionen Menschen. Von Island, Norwegen, Eurozone, Schweiz… alle sind dabei, die Konditionen sind relativ strikt reguliert und Zahlungsvorgänge müssen in einer sehr kurzen Frist ausgeführt werden. Weiterhin dürfen ausländische SEPA-Bankverbindungen nicht diskriminiert werden und somit besteht eine viel größere Chance, eine kontoführende Bank für sein Unternehmen, sein Unterfangen, sein Hobby oder einfach seiner Sache zu finden.

Ist das gut? Ich erinnere mich, wie wir uns damals gefreut oder beschwert haben, dass eine Sparkasse einem Naziverein das Konto gekündigt oder eben nicht gekündigt hat. Wir dachten, das würde unter gesellschaftlichem Engagement laufen und natürlich nur in begründeten Fälle ablaufen, aber letztlich sollte man sehr aufpassen damit. Womöglich eröffnen Banken sonst politischen Gruppen jeglicher Richtung auch nur noch sehr ungerne ein Konto um Stress zu vermeiden oder kündigen beim ersten Sockenpuppen-Shitstorm das Konto? Und überhaupt: Wenn Neonazis ein deutsches SEPA-Girokonto haben, meinetwegen bei der Sparkasse, dann zahlen sie Gebühren und das Konto ist sehr schnell gesperrt und gepfändet, wenn es vor Gericht so entschieden worden ist. Immerhin kann man hier vor Ort prozessieren bzw. Gesetze anwenden und dagegen klagen.

Es ist jedenfalls ein Trauerspiel, dass wir mit Apple Pay, Google Pay und co ausgerechnet noch mehr Volumen über unfreie, proprietäre Zahlungsabwickler ohne Einspruchsmöglichkeit befördern. Nicht nur werden unter Umständen Zahlungsvorgänge zu werblich-analytischen Zwecken ausgeweidet (Paypack- und Amazon-Kreditkarten) sondern wir werden zukünftig dann vermutlich kein legales Glücksspiel mehr betreiben dürfen oder keine Bürgerinitiative für oder gegen etwas.

Bald werden dann Zahlungen hinsichtlich Prostitution, Alkohol und Cannabis verboten oder mit einem Strafzuschlag von zufälligen 10…20.…50€ versehen, selbst wenn diese nach geltendem regionalen Recht legal sind oder sein werden.

Die Lösung für Patreon könnte sehr einfach sein: Ein SEPA-Konto, dass eine Belastungssperre hat. Diese Bankverbindung kann man dann seinen Unterstützern bei jeder Gelegenheit mitteilen, die dann kostenfrei einmalige Zahlungen oder Daueraufträge anlegen können. Gewohnt über ihre Bank. Ohne Mittelsmann, Sicherheitsprobleme oder zusätzlichem digitale schnick-schnack. Notfalls hat man gegenüber der Bank noch immer Rechtsmittel nach deutschen oder jeweiligen Landes-Gesetzen.

Patreon ist kein Netzwerk, wo Nutzer sich einloggen und dann neuen Content „entdecken“/finden, für den sie bezahlen. Auf Patreon gelangen Fans und Unterstützer jeweils durch Content-Produzenten und zwar direkt zur eigenen Unterstützerseite. Produzenten könnten also auch einfach die Adresse ihrer eigenen Mitglieds-Webapp verlinken und so einen US-Mittelsmann entfernen oder zumindest die Unterstützung von 524 Millionen Europäern an der Mastercard/VISA-Zensur vorbeiführen.

Raspbian Lite erlaubt zumindest die headless installation, d.h. man flashed die SD-Karte mit dem Image (z.B. mit dem Tool balenaEtcher), legt eine leere Datei namens „ssh“ in die fat32-Bootpartition, und startet den Raspberry Pie. Per Ethernet holt sich das Device dann IPv4/IPv6, announced via mDNS/Bonjour „raspberrypi.local“ und erlaubt die connection per ssh (l/p pi/raspberry). Dokumentation hierfür hier und hier. Danach kann man dann die Tools der Wahl nutzen um das auf Debian Stretch basierte System mit Docker, Kubernetes und co zu versorgen. Repos für armhf gibt es mittlerweile bei den jeweiligen Projekten.

Ich hätte gerne mal Alpine Linux verwendet, musste aber leider feststellen, dass es bisher kein einfaches headless setup für Raspberry PI gibt: Man muss also Tastatur und Bildschirm an den Pi anschliessen und dann manuell die Installation starten. Alpine wäre deshalb interessant, weil ich die rudimentäre busybox+musl libc-Kombination nicht nur als Docker-Base-Image sondern auch direkt auf Metall für die überlegene, weil kompaktere, weniger komplexe und daher sicherere Lösung halte.

Nicht als Universaldistribution, aber als Grundlage um darauf Container zu betreiben.

Die von ihm oft ausgemachten Gründe der „Verweichlichung“, „Diversifikation“ oder „Quoten“ teile ich jedoch meistens nicht, auch in dem besagten Blogpost.

„Linux stirbt“ nicht wegen Linus, wegen eines Spendenaufrufes für Diversifikation oder einer Anti-Harassment-Policy, sonder aus einem anderen Grund: Zwar sieht es so aus, als ob die „privileged white men“ die überwiegend die letzten 27 Jahre am Kernel und viele Userland-Projekten tätig waren, die Ursache des Erfolges sind und jeder Versuch einer Diversifikation hier Projektsabotage sei. Doch wird hier vergessen, dass Linux damals relativ alternativlos war, sehr viele Leute in der Branche sehr viel Geld in sehr kurzer Zeit verdient und auch wieder in solche Projekte reinvestiert haben oder dadurch „Zeit spenden konnten“.

Nachdem nach 2000 die Verkäufe von PCs stagnierten, später die von Notebooks und vermutlich jetzt auch die von Smartphones, wird es ökonomisch nicht mehr so einfach sein. Weiterhin sorgt dieser Druck auch dafür, dass wieder mehr proprietär entwickelt wird (proprietär nicht auf Lizenz verkürzen).

Die großen Tech-Konzerne sehen die Zukunft, wie Danisch es richtig beschreibt, in den Dumb Consumer Terminals (Smartphone, Tablets) und proprietärem Cloud-Computing: Schon jetzt erhalten sie CPUs vorab und exklusiv mit frisiertem Microcode für ihre Anwendungsfälle – andere Unternehmen oder Startups haben keinen Zugriff darauf. Trends wie Docker/Kubernetes als Containerplattform ist auch grandioser Köder um IT-Operation-Budgets von Unternehmen anzuzapfen und mit Komplexität diverse kleine Anbieter zu verdrängen.

Im Gegensatz zu den früher üblichen Lizenzierungen von zB Windows, Oracle und co wird aber alles monatlich abgerechnet, d.h. man saugt sich das Blut der Opfer kontinuierlich ab. OpenSource spielt keine Rolle, weil man die eigene Plattform definiert und diese – bei Amazon, Google, Microsoft, Oracle, Facebook und Apple – groß genug ist, um sie von 0 neu zu schreiben oder bspw 90% des Linux-Kernels zu verschrotten.

Google’s Fuchsia-Betriebssystem auf Zircon-Kernel-Basis ist ein Beispiel, das immerhin noch als OpenSource bereitgestellt wird, wenngleich die Entwicklung und Roadmap ausschliesslich innerhalb von Google geplant und umgesetzt werden. So ähnlich wie auch schon die Programmiersprache Go als Ziel hatte, keine externen Laufzeit-Abhängigkeiten ausser einer C-Standardbibliothek zu haben. Damit werden 100% aller OpenSource-Bibliotheken überflüssig, wenn man nur Go einsetzt. Kubernetes folgt diesen Prinzipien.

Letztlich hat Google die Nase voll, sich in Projekten einzubringen, wenn sie im Gegenzug große „Investments“ planen und Verändungsabsichten habe. So haben sie sich bereits aus Webkit verabschiedet und so werden sie sich auch aus Linux verabschieden. Mit etwas Glück wird man weiter an den Quellcode der neuen Projekte gelangen, aber es wird keine neutrale Community existieren sondern immer nur das zugelassen, was innerhalb von Google als opportun angesehen wird.

Durch die Konzentration in diesem Marktsegment auf wenige Mega-Teilnehmer sinken auch die Budgets und das Interesse anderer Unternehmen zur Förderung von Linux zB durch sponsorships oder source contribution. Damit ist der Untergang von Linux ein ökonomisches Problem.

Unser Staatsbahn DB verlegt ja bereits einen Großteil der Infrastruktur zum Amazon AWS und deren proprietären Cloud-Diensten. Somit fliesst unsere Kohle in immer größerem Umfang zu Amazon, das aber meines Wissens so gut wie keine OSS-Projekte supported, jedenfalls in Betracht der Unternehmensgröße. Und natürlich hat/hatte die Deutsche Bahn auch nie eigene Lösungen von Wert entwickelt, sondern auch bisher auf zugekaufte Tools und Distributionen gesetzt – wie fast alle Unternehmen in Deutschland.

PS: Vor 2 Tagen hat Google das automatische Mirroring von Zircon auf Github deaktiviert: „The Fuchsia zircon repository is no longer being mirrored to GitHub. See https://fuchsia.googlesource.com/zircon.“

Nun möchte YouTube aber nicht, dass man auf bestimmten Geräten den Stream im Hintergrund laufen lässt, oder sogar Videos generell: Vermutlich um den „Missbrauch“ als Gratis-Spotify zu verhindern und den Video-Werbenden auch „Video“-Werbung verkaufen zu können.

Mir sind die wirtschaftlichen Hintergründe und die YouTube AGB egal, weil YouTube als Teil von Alphabet auch ein Monopolist ist und Live-Streaming eines der wenigen Bereiche ist, bei dem sie nicht den Markt dominieren (Amazons Twitch ist hier dominierend).

Nun schaue ich gerne diverse regelmäßige Livestreams an, u.a. die Mainboad-Repair-Videos von Louis Rossmann aus New York oder die langen Streams von Bjørn Nyland aus Oslo, wenn er mit einem Elektroauto tausende Kilometer durch Norwegen zurücklegt. Diese Art von Streams sind unerhaltsam, aber einfach nicht ausfüllend genug, um sie 100% der Zeit „modal“ zu konsumieren und so laufen die Streams bei mir im Hintergrund – leider bisher nicht auf iOS oder Android-Geräten, weil YouTube dies unterbindet.

Und dann gibt es noch Streams, die von den Produzenten wieder gelöscht werden, weil etwas zu skurriles oder unprofessionelles passiert ist: Das frisierte E-Bike fackelt mitten in Manhattan ab,oder ein Idiot darf sich wegen unprofessioneller Fahrweise einen lauten Anschiss anhören. All das will man als Fan natürlich mitbekommen, auch wenn man gerade nicht in der passenden Zeitzone lebt oder anderweitig beschäftigt war.

Eine Archivierungs-Lösung muss her!

Problemstellung:

1. Automatisches Aufzeichnen von Streams
2. Abspielen von Streams ohne YouTube-App oder Modal-Zwang (wie z.B. in Safari, Chrome auf mobilen Plattformen).

Ich legte los und bastelte einen Prototypen auf Basis von etwas Ruby, MQTT, Streamlink, dazu VLC auf iOS, Pushover.com als Push-Service und in der späteren Version dann Syncthing zur Dateisynchronisation.

Positiv anzumerken ist, dass Google einen wenig beachteten Pubsubhubbub-Server betreibt (Vorgänger von WebSub) und YouTube darüber Push-Notifications per HTTP für YouTube-Kanäle anbietet. Allerdings nur sehr rudimentär, man kann nicht einmal zuverlässig darauf schliessen, ob ein neues Video hochgeladen, ein Stream begonnen oder einfach nur die Beschreibung eines Videos oder Streams verändert wurden. Man bekommt also sehr viele „doppelte“ Notifications.

Somit wäre der erste Teil eigentlich schnell beschrieben: Die Ruby-Applikation auf einem virtuellen Server bei einem Cloud-Provider abonniert beim Start die passenden Topics (Kanäle), erhält dann via HTTP requests Infos zu neuen Streams. Diese werden per MQTT an einen anderen Docker-Container weitergeleitet, bei dem dann die downloads gestartet werden.

Für den zweiten Teil wird es komplizierter: Erstens sind die von YouTube bereitgestellten `.m3u`-Files mittels kryptographischer Signatur auf die abrufende IP-Adresse beschränkt, zweitens sind diese zu lang, um sie in diversen generischen iOS-Push-Service-Diensten zu versenden. Um das Problem der IP-Beschränkung zu überwinden, muss also die Datei mit der selben IP-Adresse abgerufen werden. Bei mir zuhause sind diverse iOS/Android-Geräte im WiFi, teilen sich zusammen u.a. mit dem NAS per NAT die IPv4-Adresse des Providers. Bei der Anschaffung des QNAP NAS habe ich bereits darauf geachtet, dass es sich um x86-Hardware handelt, also in dem Falle konkret ein Intel Atom-System mit Docker-Unterstützung und der Möglichkeit den Arbeitsspeicher auf 16GB aufzurüsten.

So schrieb ich eine weitere kleine Ruby-Applikation, die als Container auf dem NAS läuft: Sie empfängt per MQTT die allgemeine YouTube-URL des Videos, ruft damit Streamlink auf um die URL der `.m3u`-Datei zu ermitteln. Diese wird dann per MQTT wieder an den „öffentlichen“ Container geschickt, der sie umschreibt und verkürzt (das Mapping wird dort im Arbeitsspeicher gehalten weil sie relativ kurzlebig sind, also meist ein paar Stunden nach dem Stream bei YouTube nicht mehr verfügbar sind). Die verkürzte URL geht dann per MQTT wieder an den Container auf dem NAS-Zurück, der dann eine externe API von Pushover.com aufruft. Der Anbieter pusht die gekürzte URL dann auf meine Geräte.

Nützlicherweise kann man in der Pushover-App das automatische öffnen von gepushten http-URLs einstellen und so öffnet sich Safari. Da ich aber in VLC den Stream anschauen möchte, weil nur VLC das Abspielen im Hintergrund zulässt, musste ich einen Trick anwenden: Mobile Safari öffnet also die gekürzte URL durch den Aufruf meines URL-Shorteners, der wiederum schickt einen HTTP redirect auf „vlc://…m3u URL…/“ was Safari nach Rückfrage dann an die VLC-App weitergibt. Zwar ziemlich Ghetto, aber es funktioniert.

Zuerst übernahm auch der Container auf dem NAS den Download von YouTube: Ein paar TB freier Speicherplatz sind günstiger, als in der Cloud laufend steigende Storage-Kosten in Kauf zu nehmen. Allerdings hat man zuhause ein anderes Problem: Die Stromkosten!

Die aktuelle Lösung schreibt den Stream zuerst auf ein Volume des Cloud-Servers. Daneben läuft Syncthing. Zuhause auf dem NAS läuft ein weiterer Container mit Syncthing und lädt synchronisiert nun die Videos. Abgeschlossene Dateien werden auf dem NAS aus dem Sync-Ordner entfernt und somit auch auf dem Cloudserver automatisch gelöscht.

Das ganze funktioniert auch wunderbar, wenn man den NAS-Server über Nacht in den Ruhezustand schickt: Die Videos sind in der Cloud „gepuffert“ und wandern dann eben am nächsten Morgen auf meine lokalen Festplatten. Im Gegensatz zu einer rsync-Lösung spare ich mir hier auch das Ausrollen von SSH-Zugängen für rsync etc.

Fürs Deployment setze ich einfach zwei docker-compose Konfigurationen ein. Davor source ich jeweils die passenden Variablen und leite mir per ssh den Docker-Unix-Socket der entfernten Maschinen auf das lokale System um.

Der Quellcode liegt auf https://github.com/rmoriz/youtube-watcher allerdings gibt es keine Tests und so gut wie keine Dokumentation.

PS: Bei einem Kunden setze ich seit einiger Zeit Syncthing zur Synchronisation großer Virtualbox-Vagrant-Images ein (60-100GB): Auf einem manuellen Build-Environment wird das Image erstellt, angepasst und dann in einen Syncthing-Ordner geschoben, wovon es dann auf ca 20 weitere Server übertragen bzw. per p2p geteilt und mittels Chef ausgerollt wird. Die Syncthing-Konfiguration wird hierbei auch von Chef erstellt und aktualisiert, sodass jederzeit neue Nodes hinzugefügt oder weggenommen werden können.

Etwas neues musste her, weil ich auch beruflich ein Linux-Device für die aktuellen Aufgaben benötige (InfoSec + Containerkram + DevOps) und so fiel die Wahl am Black Friday auf ein Lenovo Thinkpad L380 Yoga (13″ convertible mit FHD-Display), welches zufälligerweise unter der mittlerweile erhöhten Abschreibungsgrenze von 810€ netto direkt von Lenovo zu haben war.

Bisher bin ich mit dem Gerät sehr zufrieden, es erfüllt alle Erwartungen und ist ganz gut verarbeitet. Selbst ein Hardware-Maintenance-Manual ist frei zugänglich, um Komponenten auszutauschen oder zu erweitern: Es würden bis zu 32 GB Arbeitsspeicher reinpassen oder eben eine M.2 2280 PCIe-SSD nach Wahl. Und das bei einem Gerät für um die 900€ brutto inkl. Versand, Netzteil.

Insbesondere der Preis lässt mich geradezu über das Gerät frohlocken. Es hat Eigenschaften und Verarbeitungsqualitäten, die einem „günstigen“ Apple-Gerät in nicht mehr viel nachstehen oder gar weit übertreffen. Ähnlich wie die Beschaffung des günstige Xiaomi-Android-Smartphones zeigt mir auch dieser Kauf wieder, wie man es sich über die Jahre „zu bequem“ im Apple-Lager gemacht hat.

Nun hat auch das Thinkpad L380 Yoga seine Schwächen, es fehlen Dinge wie IR-Kamera (Gesichtserkennung), WWAN (LTE-Modem) aber auch einklappbare Tasten bei Nutzung des Tablet-Modus (Yoga) fehlen. Diese Dinge sind den teureren Modellen vorbehalten, die dann auch über eine leistungsfähigere GPU verfügen und deren Kühlung dann hoffentlich mehr als 15W TDP schafft: Auf diese Heizleistung wird nämlich die Intel i7 CPU beschränkt, so stehen meist nur 1,7-1,8 GHz von bis zu 4GHz zur Verfügung. Das ist unschön, aber für meine Nutzung kein Problem. Das Display hat zwar auch nur eine Auflösung von 1920×1080 bei 166 DPI, ist also auch kein „Retina“ (hohe Punktdichte) aber gefühlt deutlich schärfer als beim 11″ Macbook Air – zumindest unter Windows 10 und Linux (Gnome). Die Tastatur ist jedenfalls um Welten besser als das, was Apple die letzten Jahre geliefert hat! Das mitgelieferte USB-C-Netzteil fiept leider, ich bin aktuell noch dabei, eine Aussage des Herstellers und evtl. einen Austausch zu bekommen.

Beim Umstieg auf Linux bzw. Dual-Boot mit Windows 10 gab es dann die erste Schattenseite: Das Lenovo-Recovery-Tool erlaubt den Download eine Image-Datei zum Schreiben eines Recovery-USB-Sticks. Davon kann man allerdings nicht eine normale Windows 10 Installation starten, sondern nur das ganze System plattmachen und in den Werkszustand zurücksetzen, aber auch das ging leider nicht.

Glücklicherweise leben wir in 2018 und Microsoft stellt ISO-Dateien schon seit einigen Jahren zum Download bereit. Hiermit konnte ich ein blankes Windows 10 Pro installieren, die Aktivierung ging automatisch, vermutlich über ein im Bios verbautes Zertifikat/Serial. Dazu noch die Lenovo Vantage-Software runtergeladen, die dann Treiber, Bios und anderen Treiberkram installiert und aktuell hält. Läuft.

Aber selbst ein Ubuntu 18.04 ging erstaunlich einfach zu installieren, wenn man entweder die gesamte SSD exklusiv für Ubuntu nutzen und verschlüsseln möchte oder auf eine LUKS-basierte Verschlüsselung komplett verzichtet. Die Kombination mit Windows im Dual-Boot war sehr schmerzhaft und musste mit gparted vorbereitet werden, weil der Installer überfordert bzw. buggy ist. Hier hat mir dieser Stackoverflow-Beitrag sehr geholfen.

Das war eigentlich die einzige Hürde, das System läuft stabil, unterstützt Touchscreen, Trackpoint, Touchpad und Stylus, Wifi, Bluetooth, Audio… eigentlich alles, bis auf den Fingerprint-Reader: Hierfür gibt es keine Linux-Treiber. Manuelles Hibernate funktioniert auch (suspend to disk), wenn man den Crypto-Key aus dem Arbeitsspeicher kriegen möchte (hoffentlich). Ob und wie man das automatisch hinbekommen möchte, oder ob Suspend-to-RAM nicht in der Praxis ausreichend ist, wird sich zeigen.

Die Steuerung des Akkus erledigt nach manueller Installation TLP — allerdings erst nach Abstellen des Secure Boots im BIOS — zuverlässig auf der Konsole: Man definiert untere und obere Ladegrenzen. Fällt die verfügbare Kapazität im Netzbetrieb unter den tieferen Wert, wird das Laden gestartet und bis zur definierten Obergrenze fortgesetzt, so wie man es auch bei einem Tesla-Auto schlauerweise macht, um die Lebensdauer der Batterien zu schonen. Plant man mobil die maximale Kapazität abzurufen, stellt man den Maximalwert temporär auf 100%. Lädt man jedoch immer auf 100%, sorgt man für unnötige Alterungserscheinungen und thermische Belastungen. Apple bietet auf seinen Geräten keine Wahl an und sorgt so für einen unnötig hohen Verschleiss insbesondere bei nur selten mobil genutzten Geräten bzw. die Täglich für mehr als 8 Stunden „am Strom“ hängen, also typische BYOD-Geräte, die tagsüber 8-10 am Arbeitsplatz am Strom hängen.

Zwar gäbe es einen Ersatzakku schon für 100-150€ bei verschiedenen „generic parts“ Händlern zu kaufen, aber wer so ein Feature hat, spart sich eventuell diese Ausgabe, die viele Apple-Nutzer kennen und dort nach ein paar Jahren fast schon alternativlos sind.

Nun stellt sich die Frage, wie man ein Linux-Device in seine Produktivumgebung einbaut: Ich verwende zwar noch Dropbox für einige Daten, aber das sollte auf Linux kein Problem sein bzw. lasse ich auslaufen. Die Einbindung mittels Syncthing neben meinen anderen Rechnern war jedenfalls ein No-Brainer und funktionierte anstandslos. An Thunderbird als Mail-Client werde ich mich sicher wieder gewöhnen, vim/gvim, Google Chrome, Atom und VS Code sind mehr oder weniger mit den macOS-Versionen identisch, wenn man von GUI-Shortcuts absieht. Da bin ich noch nicht am Ziel angelangt.

Überraschenderweise gibt es genau eine eingesetze Software, die mir massive Bauchschmerzen bereitet: Sie ist nicht OpenSource, es gibt keine stand-alone Linux-Version und ist nur noch als Abo-Modell erhältlich: 1Password.

Es gibt ein 1Password-Chrome-Plugin für Linux, welches aber ausschliesslich mit dem Abo-Modell von 1Password funktioniert. Ich bin seit ewigen Zeiten 1Password-Kunde, möchte aber nur ungern meine ganzen Accounts in irgend eine fremde Cloud schieben respektive für etwas bezahlen, was auch syncthing oder ein einfacher RESTful-Service machen könnte. Zwar gibt es Password-Manager mittlerweile wie Sand am Meer, allerdings bieten nur weniger eine Multi-Plattform-Lösung an, die neben Linux, Mac und Windows auch iOS und Android abdeckt. Wer hier einen Tipp hat: Her damit.

PS: Es sind die kleinen Details, die einem leuchtende Augen bereiten: Um das Notebook stromlos zu setzen, kann man im BIOS eine Option auswählen, die den Akku vom Mainboard bis zum nächsten Anschluss eines Netzteiles trennt. Bei Macbooks muss man hier vorsorglich immer das Flachbandkabel des Akkus rausziehen, was eine ziemliche Friemelei sein kann, wenn man es nicht sehr häufig macht und keine passende Pinzette hat.

Der Schritt zu JavaScript im Frontend wurde hingegen mit nicht schlüssigen Begründungen gepusht: Alles asynchron, schnellere Ladezeiten, „eine Sprache für alles“, mehr Traffic mit weniger Hardware erreichbar – alles nicht wirklich messbar oder für die wenigstens Unternehmen relevant, ausser man hat die Größe von Google oder Facebook. Der mit dem Wechsel im Frontend einhergehende Wechsel im Nutzerverhalten in Richtung Mobiltelefone und Tablets inklusive diverse Appstores („Walled Gardens“) hat die wirtschaftliche Bedeutung des Webs als Plattform aber gleichzeitig sinken lassen:

Ende der 1990er war es schick, sich Homepages zu bauen und man wollte jedes kleine Unternehmen dazu bringen, sich im Web „zu präsentieren“, direkt Kunden zu akquirieren, Produkte und Dienstleistungen zu verkaufen – ohne Mittelsmänner zu bezahlen. Heute ist das alles Geschichte, man sieht zwar noch vereinzelt Websites kleiner Unternehmen und gerade Mittelständler haben auch weiterhin ihre „Präsenzen“, aber es sind reine Marketing-Ausgaben ohne Nutzwert, so wie ein Unternehmensbroschüre oder Sponsoring beim Volksfest. Wer Informationen oder Angebote will, „soll halt anrufen“. Die wirklichen E-Commerce-Umsätze werden über die Teilnahme an Bieterplattformen (z.B. AdWords, „MyHammer“, aber auch Amazon und eBay) gemacht, durch Kontingente großer Kunden oder durch mühsame direkte Akquise — wie früher eben auch. So gesehen sind die Unternehmen heute noch viel mehr abhängig von Mittelsmännern und den großen Spielern – früher waren das eben die „Gelben Seiten“ – da kam man mit Pauschalen davon, nicht mit Umsatzprozenten wie im Onlinebereich.

Statt jedem Bürger und jedem Unternehmen einen direkten Zugang zum Markt zu ermöglichen, hat sich nur eine andere, digitale Form des Mittelsmannes etabliert und kassiert ab:

So vergessen fast alle Frontend-Leute, dass am Ende hinter einem Tool-Einsatz auch ein entsprechender Mehrwert liegen muss, nicht nur einfach die „coolness“ irgend ein von Dritten entwickeltes Tool oder Plattform einzusetzen. Am Ende des Jahres muss ein Gewinn realisiert werden und ausufernde Ausgaben in Personal oder Technik stehen dem entgegen. Was Google, Apple, Facebook oder Amazon einsetzen oder durch ihre Millionen bauen und veröffentlichen ist noch lange nicht im Sinne der Allgemeinheit, eines Software-Unternehmens, eines Beraters oder eines einzelnen Entwicklers. Das investieren von bezahlter Arbeitszeit für OpenSource-Projekte in den Dimensionen von Google/Facebook ist schlicht eine aktive Einflussnahme auf die zukünftige Entwicklung des Marktes. Jede Zeile Code für Go, v8, Angular, React sind mit Werbegeldern bezahlt, denn nur damit finanzieren sich Google und Facebook!

Keiner dieser Branchengrößen möchte mit den veröffentlichten Technologien neue Konkurrenten schaffen, sondern eine Generation von Zuarbeitern, Nutzern, Abhängigen, die brav die Zukunft der eigenen Marktdominanz sichern. Das gilt natürlich auch für die App-Entwicklung für iOS oder Android, so wie für die ERP-Systemhäuser und Add-On-Entwicklungen für SAP. Anderer Bereich, selbes Geschäftsmodell.

Letztlich ist es das genaue Gegenteil der Entwicklung der 80er und 90er Jahre: OpenSource startete damals als Idee, eine freie Alternative gegen closed-source Monopole zu schaffen und einen möglichst bereiten Zugang zu Technologien zu ermöglichen. Heute sind die monopolistischen Unternehmen schlauer und veröffentlichen so viel OpenSource-Software und betreiben Projekte im eigenen Interesse, dass neutrale Projekte an Entwicklern, Nutzern und Relevanz verlieren. Ob Swift, Go, Angular, React, selbst JavaScript (v8, Chrome), Kubernetes: Man treibt den Markt vor sich her, natürlich alles quelloffen und „OpenSource“ aber mit Geldern der beteiligten Unternehmen finanziert – inklusive der „vorgelebten Vision der Zukunft“.

Man kann sogar noch einen Schritt weitergehen: Das Frontend liegt heutzutage im Quellcode vor (minified, uglified… trotzdem in einer Scriptsprache), das Backend wird auf AWS Lambda oder einem generischen API-Backend gehostet. Das Frontend ist damit nicht nur inhaltlich sondern auch funktional 100% durchsuchbar und mit AI auch logisch analysierbar (mit der ausreichenden Leistung, die Google hat, aber den Markteintritt für andere Suchmaschinen massiv erschwert), das Backend oftmals nur generisch und in Händen einiger weniger Cloudprovider betreibbar. Microsoft war das erste „Opfer“, dass nur noch davon lebt, weil es einen ausreichend großen Bestandskundenschatz („Burggraben“) haben der nicht einfach abhauen kann.

Diesen „Microsoft“-Luxus hat keiner von uns „kleinen“: Welchen Wert generieren die Frontend-Entwickler aber überhaupt noch? Es gibt keinen Bestandsschutz und keine Einflussnahme auf die Zukunft. Leben sie also nicht einfach nur davon, dass ihre Kunden noch nicht realisiert haben, dass sie keinen messbaren Wert schaffen, weil responsible websites mit client-side apps auch nicht mehr Umsatz bringen als traditionelle JEE-Webapps mit server-side Rendering? Das Shop-Designs für 99% der E-Commerce-Unternehmen irrelevant geworden sind, weil man ausserhalb der Plattformen von Amazon, eBay und co. eh keine Chance mehr hat? Dass dank der extremen Volatilität die Technologien allesamt nach 6-12 Monaten veraltet sind und portiert werden müssen?

Entwickler sollten mit dem Gedanken einen monetären Mehrwert zu schaffen morgens aufstehen und abends ins Bett gehen. Nur so wird man auf Dauer seinen Job und seine Kunden halten können. Wer das auf Dauer nicht garantieren kann (sprich: jeder), sollte jedes Tools und jeden Trend hinterfragen, aufs Geld achten, sich ggf. umorientieren und so viel Geld wie möglich in Aktien stecken: Entweder in die oben genannten Unternehmen und/oder in etablierte Dividendenzahler.

Unter diesen Gesichtspunkten finde ich es moralisch auch sehr zweifelhaft, eine große Zahl (Nachwuchs, Branchenfremder, Diversity/Integrationsmaßnahmen) für diesen Bereich zu begeistern und auszubilden. Meiner Meinung nach ist da so, als ob man in den 1990er Jahren noch tausende neue Fernsehtechniker ausgebildet hätte…