Schlüsseltechnologie

STP088: Die Schlüsseltechnologie-Kochshow

Thu, 09 Apr 2026 21:15:00 GMT

Heute mal eine eher kurze Folge. Darin geht es ums Kochen und ähnliche Dinge und wie man sie verbinden könnte (oder auch nicht).

Shownotes

ttimeless kocht eines seiner geTeXten Rezepte:

Präambel in einer Masterdatei
Rezepte in einzelnen Dateien
- Hier das Hummusrezept wie von Andong auf seinem Youtube-Kanal vorgestellt: Can I Recreate the World's Smoothest Hummus?, dazu gibt es das passende Pita.
Gesamtergebnis als PDF

Xyrill kocht ein C++-Programm mit make(1):

Grundproblem: im Kompilierungsmodell von C/C++ entsteht ein Programm in mehreren Schritten
- jede einzelne Quellcode-Datei wird einzeln vom Compiler in eine Objektdatei übersetzt
- am Ende werden alle Objektdateien vom Linker zu einer ausführbaren Programmdatei verknüpft
- als Beispiel ein kleines, vollständiges C-Programm
Vorteile von Makefiles
- Universalsprache zum Dokumentieren von Prozessen
Nachteile/Beschränkungen
- tw. arkane Syntax
- (fast?) turingvollständig, vgl. Ninja
- (unter anderem dadurch) vergleichsweise ineffizient, vgl. Tup
- moderne Programmiersprachen verwenden andere Kompilierkonzepte, meist fokussiert um Module aus mehreren Quelldateien

STP087: Graphen von Null bis Dijkstra

Thu, 19 Mar 2026 18:40:00 GMT

Nachdem wir den Begriff schon ein paar Male gestreift haben, heute ein genauerer Blick auf Graphen. Darin: informierte und uninformierte Suche sowie eine Erkundung der Dresdner Umgebung.

Shownotes

oft erwähnt, aber nie systematisch eingeführt: der Begriff Graph
- Graph: eine Menge von Knoten mit Kanten dazwischen
- z.B. Nahverkehrsnetz: Knoten = Haltestellen, Kanten = Direktverbindung zwischen zwei Haltestellen
- z.B. soziale Medien: Knoten = Personen, Kanten = "ist befreundet/folgt"
- anders als bei Listen (STP077) oder Maps (STP079) große Variabilität darin, was ein Graph fundamental ist
  - z.B. gerichtete vs. ungerichtete Graphen: Haben die Kanten eine Richtung oder nicht? (siehe Beispiele oben)
- häufig verwendete Unterarten von Graphen:
  - Baum: ayzklischer ungerichteter zusammenhängender Graph (z.B. siehe STP077/STP079: zum effizienten Abspeichern von sortierten Listen bzw. Maps)
  - azyklischer gerichteter Graph (z.B. Versionsverwaltung, Familienstammbaum, Firmen-Organigramm)
  - planarer Graph: siehe "Untangle"
Wie durchschreitet man einen Graphen? -> Suchalgorithmen, im allgemeinsten Fall die zwei wichtigsten "uninformierten" Suchalgorithmen
- Breitensuche: von einem Startpunkt pro Runde alle Nachbarn von bereits besuchten Knoten besuchen
- Tiefensuche: vom Startpunkt aus immer erst einen Nachbarn besuchen und dann dort wieder einen Nachbarn; sobald keine weiteren unbesuchten Nachbarn möglich sind, Backtracking zum vorherigen Knoten, bis ein neuer unbesuchter Nachbar gefunden wird
- sowohl Breiten- als auch Tiefensuche erzeugen beim Durchschreiten des Graphen einen Suchbaum, der ein Spannbaum ist (vgl. Spanning Tree bei Ethernet in STP028)
- Abwägung: Tiefensuche ist einfacher zu implementieren und hat weniger Speicheraufwand (braucht nur eine "besucht-Markierung" und keine Kandidatenliste), kann aber in der Praxis problematisch sein :)
Beobachtung: Breitensuche findet garantiert den kürzesten Pfad vom Startpunkt zu einem gewünschten Endpunkt
- Abwandlung für Wegfindung: Dijkstra-Algorithmus
- Voraussetzung: Kanten haben auch noch ein Gewicht (analog zu einer Streckenlänge)
- Breitensuche merkt sich bei jedem Knoten den kürzesten Gesamtweg zu diesem Knoten
- beim Auswählen des nächsten Besuchskandidaten Wahl des Knotens mit dem kürzesten Gesamtweg
- Erweiterung zum A*-Algorithmus mittels Ergänzung um eine Heuristik, die beschreibt, wie nahe gefundene Knoten am Ziel sind (damit je nach Situation enorme Effizienzsteigerung möglich, siehe z.B. dieser Blogpost der Factorio-Entwickler)
im Gespräch erwähnt: #WissPodWeihnacht 3: Das Haus vom Niko…hä?!? mit Geschichten aus der Mathematik

STP086: Literatur: Ein Plädoyer für schlanke Software

Thu, 26 Feb 2026 19:15:00 GMT

Die Erfahrung, dass das Plastikgehirn gelegentlich länger für die Dinge braucht, die wir ihm aufgeben, kennen wir alle. War das früher nicht schon mal besser? Oder sollte es nicht zumindest der Vergangenheit angehören? Oder täuschen wir uns und verklären die Vergangenheit…

Shownotes

Anhand von "A Plea for Lean Software" (1995) von Niklaus Wirth besprechen wir zwei wesentliche Fragestellungen. Zuerst einige Vorbeobachtungen:

Frage 1: Warum ist Software (bzw. Produkte im Allgemeinen) immer weniger langlebig?
- COBOL-Software aus den 60ern ist immer noch im Einsatz, aber React-Apps von vor 5 Jahren sind hoffnungslos obsolet
  - siehe Vermutung, dass in der Frontend-Entwicklung Schnelllebigkeit von YouTube-Influencern getrieben wird
  - bei COBOL/Fortran-Systemen auch regulatorische Hürden (z.B. Steuerungsoftware für Atombomben in Fortran 77, weil ein Umstieg auf neuere Versionen Tests der Software erfordern würde, aber Atomwaffentests verboten sind)
- vgl. Erfahrung von ttimeless: Fensterbeschläge von vor 30 Jahren noch top, aber neuere von vor 5 Jahren tw. schon abgeranzt (Geplante Obsoleszenz? Survivorship-Bias?)
  - Wie schätzt man Qualität bei selten gekauften Produkten ab?
  - im Gespräch erwähnt: Backblaze Drive Stats
- sich gegenseitig beschleunigende Marktmechanismen (Qualitätsschwund durch Sparmaßnahmen in der Produktion, Mode)
  - passend dazu: "Ich sah neulich eine alte Episode von 'Der Preis ist heiß' aus den 80ern, die UK-Edition mit [Bruce Forsyth]. Die Preise waren Dinge wie Mikrowellen, Fernseher, Möbelstücke und so weiter. Die Preise waren weit, weit höher, als was ich je geraten hätte. Wir sind mit der Vorstellung aufgewachsen, dass eine Mikrowelle weniger als 100 Pfund kosten sollte, obwohl sie unter Berücksichtigung der Inflation mittlerweile 400 kosten sollten. Alles ist scheiße günstig geworden."
- These von ttimeless: mehr Leute machen mehr Zeug machen mehr Altlasten (Xyrill erhöht um eine Coding-KI-Industrie und möchte sehen)
Frage 2: Warum waren Computer in den 90ern schneller?
- welch Ironie, dass wir uns nach der Zeit zurücksehnen, in der der Autor unseres Textes sich über verschwenderische Programmierweisen aufregt
- vgl. Frage im MDR: Wann kriegen wir wieder Akkulaufzeiten von einer Woche wie bei den alten Nokia-Handys?
- offensichtlicher Einfluss: mehr Leistung, die sich nicht als konkrete Funktion äußert (z.B. höhere Auflösung erfordert mehr Videospeicher, moderne Konnektivität ist objektiv komplexer, als nur auf einen Anruf oder eine SMS zu warten)
- Gegenrede: "Ich war dabei bei den meisten dieser alten Maschinen und meiner Erinnerung nach waren sie immer langsam, weswegen es ein derart unerbittliches Rennen um das Upgrade auf eine schnellere Maschine gab, und warum für eine lange Zeit Leute jedes Jahr ihren alten Computer ersetzten. [...] Dieser Topos von 'wie konnten Dinge langsamer werden, damals war alles so schnell' ist eine fehlerhafte Erinnerung"
- andere Perspektive aus demselben Thread: "Weil wir erweiterbare anstatt zusammensetzbarer Software schreiben. Wir liefern nicht Funktionen aus, sondern Apps. Wieviele Instruktionen braucht man, um in Maschinensprache 1+1 auszurechnen? Wieviele Instruktionen braucht man, um die Suchleiste zu öffnen, den Taschenrechner zu finden und die Berechnung auszuführen?"
- vgl. Freak Show 273 im Kapitel mit dem Nachruf auf Niklaus Wirth: in den 60ern vorherrschende Vorstellung unmittelbar bevorstehender Ablösung von Programmierern durch Computer, aber mehr Rechenleistung erfordert noch mehr Programmierer (vgl. Softwarekrise, für den Verweis auf kombinatorische Explosion von Software-Komplexität siehe STP070)
Komplexitätsquellen laut Wirth
- "verbesserte Benutzerführung und Funktionalität" laut Wirth keine gute Begründung
  - aber Wirth begründet das mittels seines eigenen extremen Fokus auf Basisfunktionalität ("Diese grundlegenden Aufgaben haben sich [... angesichts u. a. der] Ersetzung von aussagekräftigen Befehlswörtern durch hübsche Bilder [nicht geändert].")
  - Desktop-Metapher und Skeuomorphismus waren essentiell darin, Computersoftware einem breiten Publikum näherzubringen
  - vgl. Brooks (essentielle vs. versehentliche Komplexität), aber unterschiedliche Grenzziehungen
  - Wirth bevorzugt ziemlich explizit "simple" statt "easy"
- jede Funktion, die der Kunde haben will, wird eingebaut, ob sie sich nun sinnfällig in das ursprüngliche Design einfügt oder nicht
  - Komplexität durch Komplikationen
- monolithischer Systementwurf ("Jeder Kunde zahlt für alle Funktionen, aber nutzt nur wenige von ihnen.")
  - vgl. oben "wir liefern nicht Funktionen aus, sondern Apps"
  - Xyrill baut Systeme auch eher monolitisch, weil sich für ihn der Wartungsaufwand verringert, wenn alles in einer Codebase liegt
- Komplexität wird an sich als Funktionalität missverstanden: "Immer mehr scheinen die Leute Komplexität als Raffinesse zu interpretieren, was rätselhaft ist — Unverständliches sollte Argwohn erregen, nicht Bewunderung."
  - *hust* *hust* ✨KI✨ *hust* *hust*
  - kapitalistischer Anreiz: damit Nutzer in der eigenen Teergrube binden und Support und Beratung verkaufen
- gutes Design erfordert systematische Iteration auf dem ersten, offensichtlichen, überkomplizierten Entwurf
  - vgl. Antoine de Saint-Exupéry ("Es scheint, dass Perfektion nicht dann erreicht ist, wenn nichts mehr hinzuzufügen ist, sondern wenn nichts mehr wegzunehmen ist.")
  - aber: Zeitdruck ("akribische Ingenieursroutine zahlt sich kurzfristig nicht aus")
  - Wirth drischt hier stark auf die Kunden ein, die ständig neuen Klimbim wollen, was etwas aus der Zeit gefallen wirkt (bzw. nur etwas deplatziert; heute sind "die Kunden" die Werbeabteilung, die noch mehr Datenspuren sammeln will)
- deswegen auch extrem langsame Einführung von Techniken für methodisches Arbeiten (z.B. stark typisierte Programmiersprachen): "Methodisch korrektes Design [...] ist offenbar unerwünscht, weil auf diese Weise entwickelte Produkte zu viel Zeit bis zur Markteinführung brauchen."
  - Wirth beschwert sich, dass in den 90ern die Programmiertheorie der 70er (z.B. abstrakte Datentypen) erst langsam in Produktivumgebungen Einzug fand
  - passend dazu kommt zurzeit die Programmiertheorie der 90er (z.B. algebraische Datentypen wie in STP072, affine Typsysteme) erst langsam in die heutigen Produktivumgebungen, aber C hält sich immer noch hartnäckig
Wie heraus aus der Teergrube? Wirth bespricht sein eigenes Oberon System
- ursprüngliches Ziel: ein Betriebssystem inklusive Userspace, das kompakt genug ist, um als Lehrmaterial verwendet und in Lehrbüchern besprochen werden zu können
- extreme Konzentration auf "Grundfunktionen" (z.B. keine grafische Oberfläche, nur Textinteraktion)
- Implementation in einer typsicheren Programmiersprache mit Objektorientierung, um starke Modularität auf Codeebene zu ermöglichen
  - Xyrill ist hier etwas skeptisch, dass Objektorientierte Programmierung hier einen großen Unterschied macht, aber für Wirth ist das extrem wichtig
- keine abgeschlossenen Programme, sondern nur Funktionsaufrufe
  - also vmtl. kein Speicherschutz in Hardware, sondern nur durch Typsicherheit
  - "Wenn ein Modul M eine Prozedur P anbietet, dann kann P aufgerufen werden, indem man einfach auf den Text 'M.P' zeigt, sobald er irgendwo auf dem Bildschirm erscheint, und eine Maustaste drückt"
  - statt einer Leiste mit Icons eine einfache Textbox mit Befehlsnamen
  - vgl. Plan 9, Smalltalk, Forth
- der Preis des schlanken Systems ist der Aufwand für den sauberen Entwurf

Am Ende neun Lektionen für das Design schlanker Software. Wir zitieren Nummer 7:

Die Reduktion von Komplexität und Größe muss in jedem Schritt das Ziel sein: im Lastenheft, im Design, und beim detaillierten Programmieren. Die Kompetenz eines Programmierers soll nach der Fähigkeit gemessen werden, einfache Lösungen zu finden, und ganz bestimmt nicht nach Produktivität, gemessen in "Anzahl Codezeilen, die pro Tag ausgeworfen werden". Produktive Programmierer tragen zum sicheren Desaster bei.

STP085: Barrierefreiheit im Web (Teil 3)

Thu, 05 Feb 2026 21:00:00 GMT

Nachdem wir das eingegangene Feedback besprochen haben, starten wir zur letzten Etappe dieses überraschend ergiebigen Themas. Weder fehlt es an Anekdoten noch an vorbei fahrenden Krankenwagen und zuletzt müssen auch noch ein paar Worte über Spiele verloren werden.

Shownotes

siehe STP081: gemäß des neuen Barrierefreiheitsstärkungsgesetzes müssen Webseiten und Webapplikationen die AA-Kriterien der WCAG 2.1 erfüllen
- WCAG = Web Content Accessibility Guidelines (Webinhalte-Barrierefreiheits-Richtlinien) der Web Accessibility Initiative des W3C
- Kriterien sind gruppiert in 4 Grundprinzipien und darin 13 Richtlinien
- Kriterien gehen jeweils von A (Pflicht) über AA (Kür) bis AAA (Sahnehäubchen)
- in STP081 und STP083: das Grundprinzip 1 (Wahrnehmbarkeit) und 2 (Bedienbarkeit) mit insgesamt neun Richtlinien, heute der Rest
- zum Mitlesen: WCAG 2.2 (aktuelle Version, nur Englisch) oder WCAG 2.0 (etwas ältere Version, in offizieller deutscher Übersetzung)
Grundprinzip 3: Verständlichkeit
- Richtlinie 10: Lesbarkeit
  - A: Sprache der Webseite muss programmatisch auslesbar sein
  - AA: Sprache jedes Teils der Webseite muss programmatisch auslesbar sein
  - AAA: für ungewöhnliche Ausdrücke, Fachwörter und Abkürzungen soll eine Definition zugänglich sein; für komplizierte Texte (alles über Hauptschulniveau) soll eine Alternativform in einfacher Sprache vorliegen; Aussprachehinweise sollen zugänglich sein, sofern die Bedeutung eines geschriebenen Wortes von der Aussprache abhängt (z.B. "umfahren" vs. "umfahren")
- Richtlinie 11: Vorhersehbarkeit
  - A: Bedienung von Steuerelementen soll nicht unvorhersehbar eine Seitennavigation oder dergleichen auslösen; Hilfemechanismen (inkl. Kontaktinformationen) müssen (sofern vorhanden) auf jeder Unterseite gleich funktionieren
  - AA: Navigationsmechanismen und wiederholte Steuerelemente müssen auf jeder Unterseite gleich erscheinen und funktionieren
  - AAA: Navigation nur aufgrund von expliziter Anforderung durch die Nutzer:in
- Richtlinie 12: Hilfestellung bei der Eingabe
  - A: fehlerhafte Eingaben müssen klar hervorgehoben werden; benötigte Eingaben müssen klar als solche gekennzeichnet sein; Daten sollen nicht mehrmals abgefragt werden (beim zweiten Mal entweder automatisches Ausfüllen oder eine Option zur Datenübernahme), außer wenn Sicherheit es erfordert oder die vorliegenden Daten veraltet sind
  - AA: bei fehlerhaften Eingaben sollen Korrekturvorschläge gegeben werden (soweit möglich; z.B. nicht, wenn Geheimniswahrung gefährdet wäre); rechtlich verbindliche Vorgänge sollen entweder umkehrbar sein oder einen separaten Bestätigungsschritt anbieten; Authentifizierung soll keine Tests für geistige Leistungsfähigkeit erfordern (z.B. für Captcha muss eine alternative Methode existieren, außer wenn der kognitive Test nur Bilderkennung oder Wiedererkennung vergangener Eingaben umfasst; Passwort-Manager-Blocker sind verboten)
  - AAA: kontextsensitive Hilfe bei jeder Eingabe; jegliche formularbasierte Eingabe soll entweder umkehrbar sein oder einen separaten Bestätigungsschritt anbieten; Komplettverbot von Captchas ohne Alternativmethode, die keinen Test für geistige Leistungsfähigkeit umfasst
Grundprinzip 4: Robustheit
- Richtlinie 13: Kompatibilität
  - A: für alle Steuerelemente sind der Name und die Rolle programmatisch auslesbar (z.B. mittels ARIA (Accessible Rich Internet Applications, barrierefreie reichhaltige Internet-Anwendungen))
  - AA: für alle Steuerelemente sind der aktuelle Status bzw. eventuelle Statusnachrichten programmatisch auslesbar (z.B. durch Screenreader)

Feedback zu STP003

Dominic schreibt Themenvorschläge, und außerdem:

Vor kurzem ist mir ein Video untergekommen, das die unterschiedlichen Gatter sehr anschaulich zeigt und das ich hiermit empfehlen möchte. (Allerdings empfehle ich das Englische original denn die deutsche Synchronisation ist eine ✨KI✨-Stimme)

macht weiter so und vielen Dank

Feedback zu STP084

Daniel schreibt:

Hallo Xyrill, hallo stell es dir in einer unbekannten Fremdsprache vor ttimeless,

TL,DR: macht 'ne Folge über alternative Betriebssysteme für Smartphones

Ich habe euren Call for Action aus der Episode 84 des STP gehört. Bei mir liegt aktuell das Thema Betriebssystem fürs Smartphone auf dem Tisch (dazu später mehr) und da habe ich mich gefragt, ob ihr dazu nicht eine Folge oder einen Teil einer Folge machen könnt.

Xyrill sagte ja mal, er wechselt alle paar Jahre zwischen Android und iOS. ttimeless hat sich hierzu, glaube ich, noch nicht geäußert (Was mit Holz? Zwinkersmiley).

Es gibt ja inzwischen einige Custom ROMs auf dem Markt und einige Projekte sind auch schon wieder eingestampft (dazu später mehr).

Ich glaube, GrapheneOS wurde bei euch schon mal angesprochen, mindestens im Pentaradio. Das ist ja bekannt für seine Security Features und Einstellmöglichkeiten, hat aber den klitzekleinen Nachteil, das es nur auf einer Hardware läuft (Google Pixel).

Ubuntu Touch macht anscheinend auch Fortschritte. Außerdem schon lange verfügbar sind LineageOS und /e/os. Weitere: DivestOS, CalyxOS (dazu später mehr), Pixel Experience, usw, usf.

Ich finde, auch im Zuge der Di.day Initiative lohnt sich ein Blick auf dieses Thema. Auch, wenn es hier ein gewisses Skill Level, die Fähigkeit zum Verzicht und Bock auf Bugs bzw Bastelfreude braucht, um mit einem alternativen Betriebssystem auf dem Smartphone unterwegs zu sein.

Jetzt kommt das "später": Ich habe mir im letzten Jahr ein Fairphone 4 angeschafft und mir CalyxOS draufgeholfen. Nur um kurz nach der Installation und Einrichtung die Nachricht von den Leutis vom Projekt zu erhalten, dass erstmal keine Updates mehr over-the-air ausgeliefert werden. Wie es mit dem Projekt weitergeht, kann ich ihrer Kommunikation leider nicht entnehmen. ¯\_(^^)_/¯

Ich brauche also bald mal ein neues Betriebssystem und ich dachte, ihr habt bestimmt was Spannendes dazu beizutragen. Sei es aus eigener Erfahrung und/oder aus eurem technikbegeisterten und technikversierten Umfeld.

Der Endgegner in diesem Game ist übrigens die einzige App, die ich nicht durch FOSS ersetzen kann: die Banking-App... Es liegt in der Natur der Sache, dass ich diese App nicht wie einen Messanger oder Musikstreamingdienst wechseln kann.

Ich weiß, dass euer Wissensdampfer langsam den Eisberg umschifft (Lob der Sorgfalt) und ihr Zeit für die Produktion neuer Folgen braucht. Selbst wenn dieses Thema erst in einigen Monaten rankommen sollte, freue ich mich zu hören, was ihr dazu zu sagen habt.

Ansonsten noch vielen Dank für viele unterhaltsame und lehrreiche Stunden und einen Podcast, bei dem ich schon einige Folgen mehrfach gehört habe. Ganz stark.

Der im Gespräch erwähnte Datenspuren-Vortrag ist "Na endlich: Linux auf dem Smartphone".

Feedback zu STP081/083

Toni schreibt:

Lieber Xyrill, lieber ttimeless,

ich wurde heute von einem Kollegen auf euren Podcast aufmerksam gemacht. Ausschlaggebend war eure kleine Episodenreihe zum Thema Barrierefreiheit im Web. Ich bin selbst geburtsblind und schon immer mit den Hürden im Netz konfrontiert, schlussendlich hat mich das dazu geführt, dass ich im Rahmen meiner Promotion derzeit zum Thema Zugänglichmachung von interaktiven visuellen Kollaborationswerkzeugen forsche. Studiert habe ich ursprünglich Spieleentwicklung.

Ihr hattet in eurem Podcast zu Wortmeldungen von Betroffenen aufgefordert. Nun ist das ja schon eine Weile her - ihr meintet im Podcast, ihr nehmt die Folge Ende August auf, das sind ja immerhin schon 4 Monate. Ich finde es super, dass ihr in eurem Podcast über die Barrierefreiheit im Web aufklärt und würde mich noch viel mehr darüber freuen, wenn sie tatsächlich auch die Mehrheit umsetzen oder zumindest die Notwendigkeit dafür einsehen würde - in der Praxis wird man bei Nachfragen tatsächlich immer eher mit Skepsis und Unwillen konfrontiert, selbst aus der eher liberalen und auch der Open-Source-Community. Zudem ist das BFSG auch leider eher ein zahnloser Wolf - es gibt zwar Richtlinien, an die sich technisch jeder halten muss, insbesondere öffentliche Dienste und Dienstleister mit einer gewissen Mindestgröße, aber wo kein Kläger, da kein Richter. Menschen, die von Barrierefreiheit betroffen sind, befinden sich statistisch eher am unteren Ende der Existenzgrenze und machen sich mehr Sorgen um ihr täglich Brot als darüber, Geld in Klageverfahren zu stecken. Und selbst wenn damit Erfolg zu verzeichnen wäre, wäre gerade für große Firmen der Verlust immer noch sehr viel geringer, als das Investment, ihre Webpräsenzen von vornherein umzurüsten.

Mein Ansatz hier ist daher, Barrierefreiheit direkt schon in der Lehre mitzudenken. Darum bin ich unter Anderem an der Hochschule Anhalt tätig und versuche, meine Studierenden von vornherein darauf einzuschwören.

Ich könnte vermutlich einen halben Roman dazu verfassen, und auch auf den einen oder anderen Punkt aus eurem Episoden eingehen, aber wie zielführend das ist kann ich nicht sagen. Wenn euch so etwas interessiert, könnte man dazu aber ja gern mal quatschen, oder ihr fragt nochmal nach konkreten Kommentaren, dann setze ich mich hin und mache euch eine Liste fertig ;).

Bis dahin habt ihr vermutlich einen neuen Hörer dazugewonnen, je nachdem, ob ich noch einen Podcast mehr in meinen täglichen Informationswust reinquätschen kann ;). Macht weiter so, haltet die Ohren steif, und viel Erfolg und Glück im Jahr 2026.

STP084: Cursed Computer Iceberg Meme, Runde 3

Thu, 15 Jan 2026 00:00:00 GMT

Mal wieder stehen uns angesichts der Merkwürdigkeit der Computertechnik die Haare zu Eisberge.

Shownotes

Wir setzen unsere Betrachtung des Cursed Computer Iceberg Meme aus STP042 und STP064 fort. Dieses Mal hat Xyrill sich vorgenommen, einen Pick aus jeder Ebene des Eisbergs zu besprechen.

"Above the Iceberg" - Oberhalb des Eisbergs: Spectre/Meltdown
- Beispiel eines Seitenkanalangriffs (vgl. Besprechung von nicht-zeitkonstanten Operationen in STP041)
- war damals (2018) auch im Pentaradio besprochen worden
- und im Chaosradio
- Grundlage: moderne Prozessoren erzielen ihre Geschwindigkeit zu guten Teilen durch spekulative Ausführung zukünftiger Instruktionen (siehe STP011)
- Idee: Angreifer kann nicht auf geschützten Speicher zugreifen, aber die spekulative Ausführung weiß das nicht
- spekulativ ausgeführter (und dann verworfener) Befehl ist so gebaut, dass je nach dem Wert eines geschützten Bytes eine unterschiedliche Speicherseite angefasst wird
- dann Auslesen des Wert des Bytes durch Timing-Seitenkanal: zuletzt angefasste Speicherseite ist im Cache und schneller lesbar
"On the Iceberg" - Auf dem Eisberg: Schriftarten können Schadcode enthalten
- Kombo mit "Middle of the Iceberg" weiter unten
"Below the Water" - Unter der Wasserlinie: Magic the Gathering is Turing Complete
- vgl. unsere Besprechung von "aus Versehen turingvollständig" in STP042 sowie von Turingmaschinen in STP063
- Kyle Hill hat dazu auch noch ein neueres Video auf seinem eigenen Kanal
"Middle of the Iceberg" - Mitte des Eisbergs: Font-Hinting ist turingvollständig
- noch ein Fall von "aus Versehen turingvollständig" (siehe STP042)
- Hinting: Anpassung der Form einer Glyphe an die tatsächliche Schriftgröße in Pixeln etc., um ungewollte Rasterisierungs-Artefakte zu reduzieren (grafisches Beispiel)
- in TrueType: Hinting in einer VM, die durch Code in der Schriftartendatei gesteuert wird; damit Einschleusung von Schadcode möglich, wenn diese VM Schwachstellen hat
- Problem: heute Schriftarten nicht nur im Betriebssystem vorinstalliert, sondern auch dynamisch geladen als Webfont
"Bottom of the Iceberg" - Unterseite des Eisbergs: Es gibt keine elegante Lösung für FizzBuzz
"Below the Iceberg" - Unterhalb des Eisbergs: SAT-Solver werden immer schneller
- SAT (von engl. "satisfiability"): Erfüllbarkeitsproblem der Aussagenlogik
- relevant deswegen, weil man viele Probleme als SAT-Problem umformulieren kann (z.B. Sudoku, Raumplanung, Paketmanager)
"Deep Water" - Im tiefen Wasser: FJCVTZS
- FJCTVZS = "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" (Konvertierung eines float64 in einen int32 mit Rundung zur Null hin und Modulo 2^32 bei Überlauf)
- ARM ist zwar RISC (siehe STP075), aber eine spezielle Instruktion für Zahlenumwandlungen in JavaScript-Engines ist offenbar doch wertvoll
"The Abyss" - Der Abgrund: Die große Adressdatei der japanischen Post
- eine Lektion darin, wie wichtig saubere Daten sind, und dass man auf bei der Erstellung von Dateien auf ihre Verwendung achten muss (Parallele zu Dokumentation)

Es gibt weiterhin mehr zu entdecken. Wir sehen uns wieder in STP105.

STP083: Barrierefreiheit im Web (Teil 2)

Thu, 25 Dec 2025 15:50:00 GMT

Der versprochene zweite Teil ist da. Auch heute soll es darum gehen, wie eine angenehme Erfahrung im Internet und allgemein an Computern aussehen könnte. Zum Thema, ob wir alles geschafft haben, siehe Shownotes unten. Frohe Weihnachten allerseits.

Shownotes

siehe STP081: gemäß des neuen Barrierefreiheitsstärkungsgesetzes müssen Webseiten und Webapplikationen die AA-Kriterien der WCAG 2.1 erfüllen
- WCAG = Web Content Accessibility Guidelines (Webinhalte-Barrierefreiheits-Richtlinien) der Web Accessibility Initiative des W3C
- Kriterien sind gruppiert in 4 Grundprinzipien und darin 13 Richtlinien
- Kriterien gehen jeweils von A (Pflicht) über AA (Kür) bis AAA (Sahnehäubchen)
- in STP081: das Grundprinzip 1 (Wahrnehmbarkeit) mit insgesamt vier Richtlinien, heute der Rest
- zum Mitlesen: WCAG 2.2 (aktuelle Version, nur Englisch) oder WCAG 2.0 (etwas ältere Version, in offizieller deutscher Übersetzung)
Grundprinzip 2: Bedienbarkeit
- Richtlinie 5: Zugänglichkeit per Tastatur
  - A: alle Aktionen per Tastatur ansteuerbar, die nicht eine genaue geometrische Ansteuerung erfordern (z.B. Zeichenfläche in einem Zeichenprogramm); kein Steuerelement kann den Tastaturfokus so fangen, dass man den Fokus nur mit einer anderweitigen Aktion (z.B. Mausklick) brechen kann; etc.
  - AAA: ausnahmslos alle Aktionen per Tastatur ansteuerbar
- Richtlinie 6: Ausreichend Zeit
  - A: wenn Interaktionen ein Zeitlimit haben, muss das Limit (wann immer möglich) in irgendeiner Form umgehbar oder zurücksetzbar sein (Aufgaben sollen abschließbar sein, ohne dass ein Zeitlimit plötzlich den Fortschritt zunichte macht); jegliches automatische Bewegen/Scrollen/Blinken/Aktualisieren muss abschaltbar sein
  - AAA: absolut keine Zeitlimits für Interaktionen; bei Relogin aufgrund abgelaufener Sitzung darf kein Fortschritt verloren gehen; Benutzer müssen jederzeit über laufende Zeitlimits informiert sein, die kürzer als 20 Stunden sind
- Richtlinie 7: Keine Anfälle
  - A: Inhalte, die mehr als 3x pro Sekunde blinken, müssen eine Intensität unter den Grenzwerten für Epilepsierisiko liegen
  - AAA: gar kein Blinken schneller als 3x pro Sekunde; Animationen infolge von Benutzerinteraktionen müssen abschaltbar sein
- Richtlinie 8: Navigierbarkeit
  - A: sinnvolle Titel auf jeder Seite; über mehrere Seiten wiederholte Informationen sind überspringbar; Steuerelemente haben eine sinnvolle Fokusreihenfolge; der Zweck von Links soll soweit wie möglich aus dem Linktext allein erkennbar sein (z.B. nicht "[Hier klicken], um den Kauf abzuschließen")
  - AA: statische Seiten sollen auf mehrere Wege auffindbar sein; Seiten sind mittels Teilüberschriften und Labels sinnvoll strukturiert; Tastaturfokus auf Steuerelementen soll klar erkennbar sein; Steuerelemente mit Fokus sollen nie komplett verdeckt sein (z.B. durch ein danebenliegendes Ausklappmenü); etc.
  - AAA: aktueller Ort des Nutzers innerhalb einer Webseitenstruktur soll klar erkennbar sein (z.B. "Sie sind hier: [Start] > [Blog] > [Archiv] > Name des aktuellen Artikels"); etc.
- Richtlinie 9: Alternative Eingabemethoden
  - A: Webseiten/-applikationen, die Mehrpunkt-Interaktion erlauben ("Touch-Gesten"), sollen auch eine Alternative für zeigerbasierte Einzelpunkt-Interaktion erlauben; Aktionen infolge fehlerhaften Runterdrückens der Maustaste sollen abwendbar oder umkehrbar sein; Interaktion durch Bewegungssteuerung soll auch durch Steuerelemente ersetzbar sein sowie gegen Fehlaktivierung resistent sein; etc.
  - AA: Klickflächen müssen mindestens 24x24 CSS-Pixel groß sein (vgl. Fitts' Gesetz)
  - AAA: Klickflächen müssen mindestens 44x44 CSS-Pixel groß sein; alternative Eingabemethoden sollen beliebig gleichzeitig nutzbar sein (ohne explizites Umschalten)
  - im Gespräch erwähnt: Zenons Paradoxon von Achilles und der Schildkröte, The Topological Problem with Voting (Video)

In Teil 3 dieser Serie folgen noch Grundprinzip 3 (Verständlichkeit) und 4 (Robustheit).

STP082: Literatur: Vom Mythos des Mann-Monats, Teil 3

Thu, 04 Dec 2025 21:00:00 GMT

Als letzten Streich in der Besprechung dieses Werkes hört ihr einen Mitschnitt von den Datenspuren von 2025-09-19; und da wir leider nicht den ganzen Rest des Buches in unsere Bühnenzeit bekommen haben, auch noch den Rest in der gewohnten Form. Applaus für den Presenter!

Shownotes

Fortsetzung aus STP068 und STP074. Wir lesen weiterhin die englische Erstausgabe von 1975, die im Internet Archive digitalisiert wurde. Erneut als Vorbemerkung: Aus Quellentreue sagen wir "Mann-Monat" statt "Person-Monat".

Kurzzusammenfassung der bisherigen Folgen

Für die Zuschauer im Saal, die die vergangenen Folgen nicht gehört haben. Das übergreifende Motiv in dieser ersten Hälfte des Buches ist, wie sich die Arbeit in großen Teams von kleinen Teams unterscheidet.

Die Teergrube

So wie man in der Teergrube erst gefangen ist, wenn alle Beine drinstecken, so resultiert die Trägheit von Software-Entwicklung aus einem Zusammenspiel mehrerer Faktoren. Ein Programm zu schreiben, ist einfach. Aber die Produktisierung erfordert viel mehr Aufwand: für Generalisierung, Testabdeckung, Dokumentation und fortlaufende Wartung. Außerdem muss sich das Programm in ein größeres System einfügen. Vom Programm zum Programmsystemprodukt erhöht sich der Aufwand um ungefähr eine ganze Größenordnung.
Vom Mythos des Mann-Monats

Konventionelle Planungsmethoden funktionieren nur, wenn Personen und Monate austauschbar sind. Das beachtet jedoch weder die unterschiedlichen Kompetenzniveaus verschiedener Teammitglieder noch den zusätzlichen Zeitaufwand durch Kommunikation innerhalb des Teams sowie zwischen Teams. Da Programmierer aber schlecht im Schätzen von Zeitaufwand sind, wird in der Praxis der Zeitplan oft an den Bedürfnissen der Kunden ausgerichtet, nicht an den technischen Randbedingungen. Wenn dann das Kind in den Brunnen gefallen ist, tritt das Brooks'sche Gesetz in Kraft: "Das Hinzufügen weiteren Personals zu einem verspäteten Softwareprojekt verspätet es weiter."
Das OP-Team

Um die Kommunikationskosten zu verringern, stellt Brooks ein Modell für kleinere Teams vor, die in Analogie zu einem OP-Team organisiert sind, in dem immer nur einer auf einmal die eigentliche Programmierarbeit leistet und alle anderen nur zuarbeiten. Die genaue Beschreibung ist sicherlich überholt: Heutzutage braucht man zum Beispiel keinen Schreiber mehr, der Lochkarten sortiert. Aber vielleicht haben wir auch etwas verloren, als wir Sekretärsrollen ersetzt haben dadurch, dass jetzt die rare Expertin Termine im Outlook schubsen und Präsentationsfolien zusammenklicken muss.
Aristokratie, Demokratie und System-Design

Die Kathedrale von Reims wurde von acht Generationen von Baumeistern errichtet, weist aber trotzdem eine beachtliche gestalterische Kohärenz auf, weil die nachfolgenden Generationen das ursprüngliche Design respektiert haben. Daraus muss aber nicht folgen, dass ein einzelner Architekt alle Entscheidungen trifft und die Erbauer nur stupide die Pläne umsetzen. Auch auf der Umsetzungsebene gibt es viele interessante Designentscheidungen zu treffen; und ein guter Architekt hört auch auf seine Erbauer, wenn es um Fragen von Praktikabilität geht.
Das Problem des zweiten Systems

In diesem Dialog zwischen Architekt und Erbauer stellen sich also oftmals Ideen des Architekten als unpraktikabel heraus und werden verworfen. Doch wenn das erste System erfolgreich war, gewinnt der Architekt an Prestige und Erfahrung, die dazu verleiten kann, beim nächsten Mal alle Sachzwänge zu ignorieren. Ein weiteres klassisches Diktum von Brooks ist deswegen: "Dieses zweite ist das gefährlichste System, dass man jemals entwirft."
Weitergabe von Informationen

Damit ein Entwurf von 10 Architekt:innen von 1000 Mitarbeiter:innen und nochmal deutlich mehr Nutzer:innen verstanden wird, braucht es gute Dokumentation: Handbücher für Benutzer, und Architekturpläne für Erbauer. Brooks schlägt hier einiges vor, was heute in der Industrie gelebte Praxis ist (oder zumindest sein sollte), zum Beispiel maschinenlesbare Spezifikation von Schnittstellen und automatisierte Tests zur Überprüfung der Kompatibilität. Sein Ruf nach sorgfältiger Pro/Kontra-Abwägung zwischen mehreren möglichen Design-Optionen verhallt im Zeitalter agiler Softwareentwicklung jedoch oftmals ungehört.
Warum ist der Turm zu Babel gefallen?

Offensichtlich ist ineffektive Kommunikation einer der wesentlichen Gründe dafür, dass Software-Großprojekte scheitern oder erst mit deutlicher Verspätung liefern. Somit stellt sich die Frage nach der optimalen Teamstruktur in einer Software-Entwicklungsabteilung. Brooks hält eine baumförmige Struktur für unausweichlich, damit Entscheidungskompetenzen klar geregelt sind. In jedem Entwicklungsteam sollte es sollte es neben einem Architekten (dem Chefentwickler des Teams) auch einen Produzenten geben, der sich um die Kommunikation mit anderen Teams kümmert. Da eine Personalunion zwischen beiden Rollen nicht skaliert, muss entweder der Architekt der Chef des Produzenten sein: Dies passt aber nicht zu den separaten Management-Karrieren in den großen Firmen. Oder der Produzent ist der Chef des Architekten: Dies kann aber nur funktionieren, wenn der Produzent die technische Autorität des Architekten akzeptiert.

Kapitel 8: "Calling the Shot"

"Calling the Shot" hier im Baseball-Sinne: vorher ansagen, wo der Ball nach dem Schlag landet
- Wie lange wird eine System-Programmierungsaufgabe dauern? Wieviel Aufwand ist nötig? Wie schätzt man das?
Problem: Code schreiben alleine ist noch einigermaßen abschätzbar, macht aber nur einen kleinen Teil (vllt. ein Sechstel) des Gesamtaufwandes aus
- Aufwand steigt exponentiell mit der Komplexität des Programmiersystems, weil Interaktionen zwischen verschiedenen Teilen des Systems beachtet werden müssen und Kompromisse im Design erfordern (vgl. Kapitel 1)
- und dann zusätzlicher Overhead, sobald Kommunikation zwischen mehreren Teammitgliedern erforderlich ist (vgl. Kapitel 2)
Brooks fasst dann Erkenntnisse aus mehreren quantitativen Studien zusammen; Highlights:
- Geschwindigkeitsschätzungen waren zu Beginn immer ziemlich akkurat, aber im Verlauf des Projektes wird mit zunehmender Komplexität alles immer träger
- Aufwand scheint am stärksten von der Gesamtmenge an Code abzuhängen (sprich: 1000 Zeilen Code sind ähnlicher Aufwand, unabhängig von der Sprache) -> Überleitung in das nächste Kapitel

Kapitel 9: Zehn Pfund in einem Fünf-Pfund-Sack

wenn Code kein Wert an sich, sondern eine Verbindlichkeit ist, wie kann man Code reduzieren?
- Hochsprachen -> vgl. "No Silver Bullet" und intrinsiche vs. versehentliche Komplexität ("essential vs. accidental complexity"; besprochen im Pentaradio vom Dezember 2022)
- Xyrill sieht einen Bezug zum Hype um Coding-KI und die damit verbundenen Werbeversprechen
Brooks zieht eine Parallele zu Hardware-Entwurf: "Weil die Größe ein wichtiger Teil der Benutzerkosten eines Programmiersystem-Produktes ist, muss der Erbauer Größenziele setzen, die Größe im Auge behalten, und Techniken zur Größenreduktion ersinnen; genau so, wie ein Hardware-Erbauer Komponentenzahlziele setzt, die Komponentenzahl im Auge behält, und Techniken zur Reduktion der Komponentenzahl ersinnt. Wie jede Art von Kosten ist Größe an sich nicht schlecht, aber überflüssige Größe ist es."
- vgl. Kapitel 1 (siehe STP068), wo bereits ein vordefiniertes Ressourcenbudget für jedes Teilprogramm gefordert wurde
- heute (leider?) nicht mehr en vogue; Speicher ist zu günstig geworden
"Repräsentation ist die Essenz des Programmierens": Brooks hält den Entwurf passender Datenstrukturen für sehr viel relevanter als die Auswahl passender Algorithmen
- Xyrill stimmt offensichtlicherweise zu, siehe STP071/072
- "Zeig mir deine Flussdiagramme ohne die [Datenbank-]Tabellen, und ich werde verwirrt bleiben. Zeig mir deine Tabellen, und ich werde die Flussdiagramme wahrscheinlich nicht brauchen; sie werden offensichtlich sein."
- Xyrill vermutet, dass hierher seine tiefe Abneigung gegen Prozess-Designer rührt

Kapitel 10: Die dokumentarische Hypothese

Die Hypothese: Verborgen in einem riesigen Papierhaufen verborgen, werden eine kleine Zahl von Dokumenten zu kritischen Angelpunkten, um die sich das Management eines jeden Projektes dreht. Dies sind die zentralen Werkzeuge eines Managers.

"Auf einen neuen Manager, der gerade aus dem Handwerk gewechselt ist, erscheint der meiste Papierkram als vollständiges Ärgernis, als unnütze Ablenkung, und eine weiße Flut, die droht, ihn zu umspülen. Und in der Tat sind die meisten dieser Dokumente genau das."
- doch einige Dokumente sind essentiell und das wesentliche Arbeitsergebnis des Managers
- Mindestsatz laut Brooks: Zielsetzungen/Spezifikationen, Zeitplan, Budget, Ressourcenzuteilung, Personalzuteilung (letzteres vgl. Conway's Gesetz: "Organisationen, die Systeme entwerfen, sind gezwungen, Systeme hervorzubringen, die die Kommunikationsstruktur dieser Organisation kopieren.")
wesentliche Funktionen von Dokumentation für den Manager:
- Festhalten von Entscheidungen: Aufschreiben legt Widersprüche, Denkfehler und -lücken offen
- Kommunizieren von Entscheidungen: Manager sind die meiste Zeit Kommunikatoren und nur relativ selten tatsächlich Entscheider
- Erinnern von Entscheidungen: klare Dokumentation einer Entscheidung mit Begründung ermöglicht spätere Rezension und Entscheidung, wann eine Richtungsänderung angebracht ist

Kapitel 11: Plane damit, eines wegzuwerfen ("Plan to Throw One Away")

Analogie zu Pilotanlagen in der Chemietechnik: beim Übergang von Laborprozessen zu Fabrikproduktion im großen Maßstab sind Skalierungsprobleme und methodische Fragen zu lösen, sodass man nicht sofort die Fabrikanlage in der finalen Größe bauen kann
- "Plane damit, eines wegzuwerfen. Du wirst es sowieso tun."
- Programmierer waren zu Brooks' Zeiten damit beschäftigt, die Lektion zu lernen, und sind es heute immer noch
damit im Zusammenhang: Wie geht man mit Veränderungen der Umstände um? Wieviel Veränderung der Umstände ist man bereit, zu akzeptieren?
- These: Unwillen zur Dokumentation ist Unwillen, sich auf eine Entscheidung festzulegen, von der man schon weiß, dass sie immer nur vorläufig sein kann
- bis hin zu Teamstruktur: "In einem großen Projekt muss der Manager zwei oder drei Topprogrammierer als technische Kavallerie vorhalten, die zu Rettung galoppieren können, wo immer der Kampf am schwierigsten ist." (Xyrill ist sich nicht sicher, ob er da mitgeht)
Software-Maintenance laut Brooks besteht hauptsächlich aus "Änderungen, die Designfehler beheben"
- Xyrill stimmt nur im Teil zu: der meiste Aufwand bei Maintenance heutzutage ist "Bit Rot" (Umgang mit der stetig fortschreitenden Fäulnis im Ökosystem), also nur indirekt Behebung von Designfehlern
- jede Behebung eines Fehlers kann aber auch neue Fehler erzeugen (sowohl auf handwerklicher Ebene als auch auf Design-Ebene)
- automatisierte Tests helfen, sofern sie eine hinreichend gute Abdeckung erzielen und nicht so aufwändig sind, dass sie den Arbeitsprozess behindern
- trotzdem: Programme werden im Verlauf ihres Lebenszyklus immer komplexer, wodurch die Rate von Folgefehlern steigt
der letzte Satz des Kapitels war bereits im Juni im Pentaradio zitiert: "Das Erbauen eines Programms ist ein entropieverringernder Prozess […] Die Wartung eines Programms ist ein entropieerhöhender Prozess, und selbst die gescheiteste Umsetzung kann das unausweichliche Absacken des Systems in unreparierbare Obsoleszenz höchstens verzögern."

Kapitel 12: Scharfe Werkzeuge

Programmierer sind eine der wenigen Berufsstände, die ihre eigenen Werkzeuge bauen
- da Effizienz aus der Qualität des Instrumentariums folgt, sollen Softwareentwicklungs-Manager Ressourcen abstellen für "Werkzeugmacher"
- aber: heute anderer Fokus als damals; weniger Bedarf nach z.B. Debugging-Werkzeugen (das bringt die Programmiersprache mit) und mehr Bedarf nach z.B. CI/CD oder Linting
Brooks bespricht dann Strategien, die nicht auf den allgemeinen Fall übertragbar sind
- Rationierung der Rechenzeit auf raren Mainframes: heute haben wir überproportionierte PCs für jeden Entwickler, sowie elastische Cloud-Infrastruktur für alles, was da nicht heraufpasst
- Umgang mit Prerelease-Hardware: betrifft die allermeisten großen Software-Projekte nicht (aber siehe dieser Vortrag von einem AMD-Chipdesigner)
Brooks stellt als offensichtlich wertvolles Werkzeug Hochsprachen auf eine Stufe mit interaktiver Programmierung
- "Ich bin überzeugt, dass nur Schwerfälligkeit und Faulheit die universelle Annahme dieser Werkzeuge aufhalten; die technischen Schwierigkeiten sind nicht länger valide Ausreden."
- Vorteile von Hochsprachen: erhöhte Produktivität (aufgrund weniger Code; siehe Kapitel 8/9), weniger Programmierfehler (nicht nur aufgrund weniger Code, sondern weil ganze Fehlerklassen eliminiert werden)
- bei interaktiver Programmierung Bezug zu MIT Multics (dem Vorgänger von AT&T Unix): Xyrill hatte hier zuerst an Systeme wie Smalltalk gedacht, aber offenbar ist "interaktiv" hier das Gegenwort zu "Batch Processing"

Kapitel 13: Das Ganze und die Teile

Wie verhindert man Probleme beim Zusammenfügen mehrerer Teilprogramme zu einem Gesamtsystem?
- Brooks enumeriert hier viele bereits erwähnte Sachen: strukturierte Programmierung in Hochsprachen, Debugging (entweder interaktiv auf der Zielmaschine, oder post-mortem mit einem Speicherabbild), Tests (sowohl für Einzelkomponenten als auch das Gesamtsystem)
Missverständnisse bzw. Unklarheiten in der Spezifikation: siehe Kapitel 4-6 für Prozesse zum Erhalt der konzeptionellen Integrität des Gesamtsystems
- Xyrill beobachtet, dass das Schreiben der Spezifikation oftmals mehr Konzentration erfordert als das Schreiben des Code (hohe Entscheidungsdichte, dichtes Konsequenzgeflecht)
- Brooks empfiehlt einen Ansatz nach Niklaus Wirth: "Programmentwicklung durch schrittweises Verfeinern" mit verschiedenen Stufen von je nach Stufe möglichst groben Designs, die dann jeweils durch die nächste Stufe verfeinert werden
- Probleme beim Verfeinern stellen dann evtl. die Designfehler auf der gröberen Ebene bloß -> damit der Versuchung entgehen, ein schlechtes Grunddesign mit immer mehr Epizyklen zuzukleistern
Empfehlung: klare Markierungen, wenn zum Zwecke der Fehlerbehebung der dokumentierte Zustand des Systems manipuliert wird
- Brooks beschreibt Verkabelung gemäß Plan mit gelben Kabeln und manuelle Änderungen mit lilanen Kabeln, damit diese ins Auge stechen und dann beim nächsten Update des Kabelplans berücksichtigt werden
- in Software nicht so sehr formalisiert, wie es sein sollte (am ehesten in Form von Systemen, die manuelle Änderungen am Produktivsystem unterbinden)
weitere Empfehlungen:
- immer eine Komponente nach der anderen hinzufügen, nicht mehrere auf einmal
- Aktualisierungen nicht ständig einspielen, sondern nur ab und zu, damit man zwischendurch den stabilen Zustand des Systems beobachten kann

Kapitel 14: Wie man eine Katastrophe ausbrütet ("Hatching a Catastrophe")

Zeitpläne scheitern meist nicht durch ein großes Hindernis (auf welches mit einer großen Anstrengung reagiert würde), sondern durch eine Anhäufung kleiner Hindernisse
- vgl. politische Reaktion auf Versagen: Einsturz einer einzelnen Brücke mobilisiert sofort Unterstützung, aber schleichender Verfall aller Brücken ist alternativlos
- Tod durch tausend Schnitte: heute ist der Chefentwickler krank, morgen ist eine Festplatte auf dem Datenbankserver kaputt, übermorgen verspätet sich der Hardwaretest aufgrund Problemen in der Lieferkette
Erkennen von Verspätungen erfordert einen festen Zeitplan mit spezifischen Meilensteinen
- Gegenbeispiel: "Implementation 90% fertig" stimmt so gut wie immer :)
- "Chronisches Überziehen des Zeitplans ist ein Teammoral-Killer."
"Aber die anderen sind auch zu spät dran."
- trotzdem ist es ratsam, sich selber ranzuhalten, damit man nicht auf dem kritischen Pfad landet und dann das ganze Großprojekt ins Stocken bringt
- Manager sollten den kritischen Pfad kennen, damit sie rechtzeitig wissen, wo ihre Aufmerksamkeit am wertvollsten ist

Kapitel 15: Das andere Gesicht

"Ein Computerprogramm ist eine Nachricht des Menschen an die Maschine. [...] Aber ein geschriebenes Programm hat ein anderes Gesicht, dasjenige, dass seine Geschichte dem menschlichen Benutzer erzählt."
- selbst für Programme für den eigenen Gebrauch, damit man sich in einem Jahr noch daran erinnert, was das Programm tut
Brooks möchte, dass Dokumentation aus drei Teilen besteht
- wie man ein Programm verwendet (klar)
- wie man dem Programm glaubt (Testfälle zum Ausprobieren)
- wie man das Programm verändert (Dokumentation über die interne Struktur, das Dateilayout, verwendete Algorithmen und Datenstrukturen)
Brooks findet Strukturdiagramme super, und Flowcharts scheiße: man solle lieber äquivalenten (Pseudo-)Code hinschreiben
- Xyrill stimmt zu: die meisten Flowcharts aus der Praxis sind abgrundtief hässlich und unlesbar chaotisch
- Ergebnis: der Code sollte einfach selbstdokumentierend sein bzw. seine Dokumentation inline enthalten (vgl. Donald Knuth und "Literate Programming")
- offensichtlich ist das alles aus der Zeit, bevor Software ein einzeln verkauftes Produkt war
im Gespräch erwähnt: The Architecture of Open Source Applications; ein Buch darüber, guten Open-Source-Code zu lesen und zu durchdringen

Epilog

"Die Teergrube der Software-Entwicklung wird noch eine ganze Weile klebrig bleiben. Man kann davon ausgehen, dass die Menschheit auch weiterhin Systeme in Angriff nehmen wird, die gerade so innerhalb oder gerade so außerhalb des Möglichen liegen; und Softwaresysteme sind vielleicht die vertracktesten und komplexesten aller menschlichen Schöpfungen. Das Verwalten dieses komplexen Handwerks wird von uns fordern: den bestmöglichen Einsatz neuer Sprachen und Systeme, die optimale Anwendung bewährter Methoden des Ingenieurmanagements, großzügige Mengen gesunden Menschenverstandes, und die gottgegebene Demut, die eigene Fehlbarkeit und Beschränkungen zu erkennen."

Podcast-Empfehlungen

Gilda con Arne – Der Politik-Podcast
Dlf Doku Serien
- einige Trailer für Dokus
- Tech Bro Topia
- Rechtsextreme vor Gericht
- Neuland
Die Geschichte geht weiter – Victor Klemperers Tagebücher 1918-1958

STP081: Barrierefreiheit im Web (Teil 1)

Thu, 13 Nov 2025 00:10:00 GMT

Es gibt Menschen, die körperliche oder mentale Einschränkungen haben. Für diese Menschen könnte unsere Welt angenehmer gestaltet werden. Welche Vorteile auch nicht behinderte Menschen aus entsprechenden Maßnahmen ziehen und was diese Maßnahmen sind, darum soll es heute gehen. Und an einem anderen Tag auch.

Shownotes

seit 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz als nationale Umsetzung der EU-Richtlinie 2019/882 über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen
- gilt insbesondere auch für alle digitalen Dienstleistungen (Webseiten, Apps, Ticketautomaten, etc.)
- Leitmotiv heute: Ist das nur was für Menschen mit Behinderungen?
Webseiten und Webapplikationen müssen die AA-Kriterien der WCAG 2.1 erfüllen
- WCAG = Web Content Accessibility Guidelines (Webinhalte-Barrierefreiheits-Richtlinien) der Web Accessibility Initiative des W3C
- WCAG 2.2 (aktuelle Version von 2024) enthält eine Reihe von Kriterien, gruppiert in 4 Grundprinzipien und darin 13 Richtlinien
- Kriterien gehen jeweils von A (Pflicht) über AA (Kür) bis AAA (Sahnehäubchen)
- zum Mitlesen: WCAG 2.2 (aktuelle Version, nur Englisch) oder WCAG 2.0 (etwas ältere Version, in offizieller deutscher Übersetzung)
Grundprinzip 1: Wahrnehmbarkeit
- Richtlinie 1: Textalternativen
  - A: Textalternativen für alle Nicht-Text-Inhalte
- Richtlinie 2: Alternativen für zeitbasierte Medien
  - A: Audiobeschreibung oder Alternativdarstellung für voraufgezeichnete Bewegtbilder, Untertitel für voraufgezeichnete Videos mit Ton
  - AA: Untertitel für Live-Videos etc.
  - AAA: Gebärdenübersetzung für Sprache in Audio/Video etc.
- Richtlinie 3: Anpassbarkeit
  - A: Struktur und Beziehungen in dargestellter Information sollen programmatisch auslesbar sein (z.B. in HTML Strukturierung anhand semantisch aufgeladener Tags wie <main>, <nav>, <aside>, <section>); Darstellung soll in korrekter Lesereihenfolge erfolgen; Struktur der Information soll nicht nur aus sensorischen Charakteristika wie Form, Farbe, visueller Anordnung oder Klängen hervorgehen
  - AA: Inhalte sollen sowohl in Hochformat als auch Querformat funktionieren; Eingabefelder sollen programmatisch als solche erkennbar sein
  - AAA: alle Steuer- und Inhaltselemente sollen programmatisch auslesbar sein
  - im Gespräch erwähnt: Rot-Grun-Sehschwäche
- Richtlinie 4: Unterscheidbarkeit
  - A: Farbe nicht als einziges Unterscheidungsmerkmal (z.B. zwischen guten und schlechten Optionen); Abspielen von Audioinhalten soll durch den Nutzer kontrollierbar sein
  - AA: Text- und Hintergrundfarben sollen ein Kontrastverhältnis von mindestens 4.5:1 aufweisen (außerdem 3:1 für aktive Steuerelemente); Text soll ohne Spezialwerkzeuge um bis zu 200% vergrößerbar sein; Inhalte sollen unabhängig vom Bildschirmformat ohne exzessives Scrolling erreichbar sein; etc.
  - AAA: Kontrastverhältnis für Text mindestens 7:1; Audio mit Sprache soll geringe Hintergrundgeräusche aufweisen; Text soll mit kurzen Zeilenlängen und mindestens anderthalbfachem Zeilenabstand dargestellt werden; reiner Text soll nicht als Bilddatei ausgespielt werden; etc.

STP080: Common Weakness Enumeration (Teil 2)

Thu, 23 Oct 2025 08:50:00 GMT

Im zweiten Teil zu üblichen Schwachstellen hören wir neben einigen Querverweisen auch Xyrills Meinung zu seiner favorisierten Verwundbarkeit.

Shownotes

Platz 9: CWE-862; fehlende Autorisierung
- siehe Besprechung von Authentifizierung und Autorisierung in STP039
- Lösung: Just do it! :)
- passend dazu Platz 14 und 18: CWE-287 und CWE-863; fehlerhafte Authentifizierung bzw. Autorisierung
- außerdem Platz 15: CWE-269; unzureichende Privilegienkontrolle
- als Sonderfall Platz 25: CWE-306; fehlende Authentifizierung an kritischer Stelle
- daraus folgend Platz 17: CWE-200; Preisgabe sensitiver Informationen an nicht Zugriffsberechtigte
Platz 10: CWE-434; Unbeschränktes Hochladen von Dateien des falschen Typs
- und dadurch z.B. Einschleusung von Schadcode (Xyrill fühlt sich an den "OpenOffice kann dienstags nicht drucken"-Bug erinnert)
- Lösung: nur bekannte Formate akzeptieren
- passend dazu Platz 16: CWE-502; Deserialisieren unvertrauenswürdiger Daten
- Lösung: unbekannte Daten mit sicheren Parsern validieren
Platz 21: CWE-476; Zugriff auf Nullzeiger
- besprochen in STP045
Platz 22: CWE-798; Zugriff mit hartkodierten Anmeldedaten
- In wieviele Plasterouter kommt man wohl immer noch mit Username admin und Passwort letmein rein? :)
- tatsächlich auch bei Enterprise-Hardware oftmals Standardpasswörter voreingestellt, die dann beim Einrichten (versehentlich?) nicht geändert werden
Platz 23: CWE-190; Ganzzahlüberlauf ("Integer Overflow or Wraparound")
- besprochen in STP003 (Überlauf in Logikgattern) und STP037 (berühmte Überlauffehler)
Platz 24: CWE-400; unkontrollierter Ressourcenverbrauch
- Rückbezug zu STP079 (Komplexitätsattacke in Hashmaps)
außerdem noch Xyrills Favorit: CWE-655; unzureichende psychologische Akzeptabilität :)

STP079: Feld von Feldern

Thu, 02 Oct 2025 21:25:00 GMT

Nach einem kurzen Feedback gehen wir diesmal zu Karten… nein, Abbildungen über. Das ist am Anfang kein Problem. Nur wenn die Eimer für Streuwertfunktionen kleiner werden, hat ttimeless etwas Schwierigkeiten.

Shownotes

Rückbezug STP077: Liste von Listen
- verschiedene Datenstrukturen implementieren dasselbe Datenformat mit unterschiedlichen Laufzeitcharakteristiken
- heute analog dazu Besprechung von assoziativen Datenfeldern
Rückbezug STP072: assoziative Datenfelder (wir sagen hier "Maps"; heißt je nach Programmiersprache auch "Objekt", "Dictionary", etc.)
- eine Sammlung von Wertepaaren mit jeweils einem eindeutigen Schlüssel ("Key") und einem zugeordneten Wert ("Value")
- z.B. Wörterbuch: Schlüssel ist das Lemma, Wert ist die Definition
- z.B. Verzeichnis im Dateisystem: Schlüssel ist der Dateiname, Wert ist die Datei (bzw. das Unterverzeichnis)
- praktisches Beispiel: Wörter zählen
- es geht hier nur um Wertepaare, die aktiv im Speicher vorliegen, nicht um berechnete Abbildungen (Gegenbeispiel: Suchmaschine bildet von Suchanfrage auf Ergebnisseite ab)
Ansatz 1: "Sammlung von Wertepaaren" als Liste umsetzen
- sofern unsortiert, ist die algorithmische Komplexität für die meisten Operationen sehr schlecht
  - z.B. Suchen nach einem bestimmten Schlüssel in linearer Zeit (O(n)), wenn man die Liste von vorne nach hinten durchgehen muss
  - z.B. Einfügen eines neuen Schlüssels auch nur in linearer Zeit, weil man einen evtl. existierenden Eintrag mit demselben Schlüssel finden und ersetzen
- praktikable Umsetzung unter Verwendung einer sortierten Liste, um bestimmte Schlüssel schnell aufzufinden
  - meistens mittels eines balancierten Baums, z.B. in Rust BTreeMap oder in C++ std::map
  - Problem: Schlüssel müssen sortierbar sein (Beispiel: Strings, Ganzzahlen; Gegenbeispiel: komplexe Zahlen, Fließkommazahlen, ungeordnete Mengen)
  - Problem: auch bei sortierbaren Schlüsseln können Vergleiche teuer sein
  - Wie können wir die Vergleiche günstiger machen?
Ansatz 2: Vorsortierung anhand von Streuwertfunktionen (Hashes)
- Idee: bei Suche nach einem bestimmten Schlüssel wird ein Hash des Schlüssels ermittelt (in Größenordnung einer kleinen Ganzzahl, z.B. 4 oder 8 Byte; nicht ein kryptografisch starker Hash wie SHA-2 mit 28-64 Bytes); damit schnelle Vergleiche möglich -> Hashtabelle
- Strategie 1: Gruppierung der Wertepaare in "Buckets" anhand der ersten K Bits des Hash-Wertes des Schlüssels
  - K richtet sich nach der Gesamtanzahl an Wertepaaren (z.B. für 50 Elemente könnte man K = 5 oder 6 und damit 2^K = 32 oder 64 Buckets wählen)
  - innerhalb der Buckets einfache Listen von Wertepaaren, die in diesen Bucket fallen; idealerweise nur ein Eintrag pro Bucket
  - durch dynamisches Anpassen der Bucket-Anzahl Abwägung zwischen Speicheraufwand für evtl. leere Buckets einerseits und Zeitaufwand für Durchsuchen übervoller Buckets andererseits
- Strategie 2: wie 1, aber jeder Bucket kann maximal ein Element aufnehmen
  - bei Kollisionen strategisches Ausweichen auf andere Buckets in einem systematischen Muster, bis ein freier Platz gefunden wird
  - große Variation von Implementationsstrategien für dieses "strategische Ausweichen"
Vorwärtsbezug zu STP080: Komplexitätsattacke auf Hashmaps (eine Instanz von CWE-400)
- Problem, wenn Hashmap mit nutzerdefinierten Daten gefüllt wird: Angreifer könnte Daten so wählen, dass sie alle im selben Bucket landen wollen
- damit extrem hohe Rechenlast durch ständige Kollisionen
- Lösung: Durchmischen des Hash mittels prozessinterner Geheimzahl (siehe STP044 zu Zufallszahlen)

Feedback zu STP065

Mole schreibt:

In STP065 vermutest du, dass der Ethernet-Port wegen Authentifizierung abgeschafft wurde. "Beim WLAN muss man sich authentifizieren, beim Ethernet kann man sich einfach anstecken und lossurfen." Das ist so natürlich nicht richtig. Im Enterprise-Umfeld gibt es für sowas 802.1x. Das wird übrigens auch beim WLAN zur Authentifizierung mit einem RADIUS-Server benutzt. Außerdem gibt es da SNMP-Traps. Da schaltet dann der Port ab und der Admin bekommt eine Nachricht, wenn die falsche MAC antwortet. Das gab es schon lange vor WLAN.

Nächstes Problem: Du erklärst, das die NUCs vom VOC für das Streaming zuständig sind. Das ist so auch nicht richtig. Die machen nur das Encoding in die Subformate, wenn der Talk schon geschnitten ist. Für das Streaming sind die Cubes, ordentliche PCs mit extrem teuren Spezial-SDI-Encoding-Karten. Die Kisten brauchen auch echt Leistung, weil die das live machen.

STP078: Common Weakness Enumeration (Teil 1)

Thu, 11 Sep 2025 21:59:00 GMT

Nachdem wir kurz über Alex' Feedback gesprochen haben, soll es heute mal wieder um Sicherheit gehen; diesmal speziell darum, was Personen die Software schreiben beachten sollten, um die bekantesten Fallstricke sicher zu umgehen.

Shownotes

Rückbezug STP049: CVE-Datenbank für bekannte Sicherheitslücken in bestimmten Programmen (z.B. Heartbleed ist CVE-2014-0160)
- betrieben von dem privaten Forschungsinstitut Mitre Corporation auf Basis von Fördermitteln der US-Regierung
- April 2025: kurzzeitige Verwirrung nach Aussetzen des Fördervertrages, dann einen Tag später Kommando zurück (Pentaradio berichtete)
- neben CVE pflegt Mitre Corp. eine weniger bekannte Datenbank: CWE (Common Weakness Enumeration), ein Klassifizierungssystem für Arten von Sicherheitslücken
- wir besprechen die jährliche Rangliste der CWE Top 25 mit Stand von 2024
- wertvoll, weil man so als interessierter Laie oder Programmierer-Generalist ein Gefühl für wichtige Angriffsvektoren bekommt
Platz 1: CWE-79; fehlerhafte Neutralisierung von Eingaben während der Erzeugung von Webseiten ("Cross-Site Scripting", XSS)
- siehe Beispielbild im Link
- Webseiten können JavaScript-Code enthalten, der auf dem Browser des Endanwenders ausgeführt wird
- wenn Webseiten aus Eingaben anderer Benutzer zusammengebaut werden, können diese Code einschleusen
- Lösung: Escaping (Entfernen oder Ersetzen von Zeichen mit syntaktischer Bedeutung), kann durch Template Engines teilweise automatisiert werden
- passend dazu Platz 7: CWE-78; fehlerhafte Neutralisierung von Eingaben während der Erzeugung von Befehlszeilen
- außerdem Platz 13: CWE-77; dasselbe für alle anderen Befehlssprachen, die nicht JavaScript oder die System-Shell sind
- allgemeiner als Platz 12: CWE-20; unzureichende Überprüfung von Eingaben
- Lösung: "assume all input is malicious"; nur Eingaben akzeptieren, die strikten Formatvorgaben folgen (z.B. unter Einsatz von regulären Ausdrücken, siehe STP021)
Platz 2, 6 und 20: CWE-787 und CWE-125; Schreiben bzw. Lesen außerhalb des allokierten Speicherbereichs ("Out-of-Bounds Write/Read") sowie als übergeordnete Kategorie CWE-119; allgemeiner Pufferüberlauf ("Buffer Overflow")
- und passend dazu Platz 8: CWE-416; Benutzung nach dem Freigeben ("Use after Free")
- alle bereits besprochen in STP047
- Lösung: speichersichere Programmiersprachen, Speicherprofiling-Tools wie Valgrind (siehe STP076)
Platz 3: CWE-89; SQL-Injektion
- SQL siehe STP012: Abfragesprache für relationale Datenbanksysteme
- Beispiel siehe XKCD 327
- Lösung: Datenwerte von der Abfrage trennen (z.B. SELECT * FROM users WHERE name = 'Alice' -> SELECT * FROM users WHERE name = $1 mit Datensatz ["Alice"])
- passend dazu Platz 11: CWE-94; Code-Injektion (dasselbe für Programmcode); Überlapp zu CWE-77
Platz 4: CWE-352; Cross-Site Request Forgery (CSRF)
- Angreifer möchte im Namen des Opfers eine Aktion ausführen (z.B. auf Rechnung des Opfers in einem Webshop bestellen)
- Angreifer schiebt dem Opfer ein manipuliertes HTML-Formular unter, dass beim Abschicken die gewünschte Aktion auslöst, aber mit den Cookies (und damit der Identität des Opfers)
- Lösung: CSRF-Tokens (echte HTML-Formulare erhalten ein einmalig nutzbares Token, dass nicht vom Angreifer gefälscht werden kann)
- passend dazu Platz 19: CWE-918; Server-Site Request Forgery (SSRF)
- dabei manipuliert der Angreifer nicht ein menschliches Opfer oder einen Webclient, sondern einen Webserver, mit seinem privilegierten Zugriff andere Webserver abzufragen
Platz 5: CWE-22; Pfaddurchquerung ("Path Traversal")
- z.B. bei Webservern mit statischen Inhalten: entsprechende Dateien liegen im Dateisystem in einem bestimmten Ordner
- Dateien außerhalb dieses Ordners sollen eigentlich nicht zugreifbar sein, aber manchmal geht http://example.com/../../../etc/passwd oder dergleichen
- Lösung: magische Pfadelemente wie .. (bei Pfaden) oder / (bei Dateinamen) ablehnen

Feedback zu STP063

Alex schreibt:

danke für den Podcast. Ich bin wie immer weit im Rückstand mit Hören, habe zu Folge 63 aber mal die Turing-Maschine für die Subtraktion neu gebastelt. [...] Den Input muss man mit folgender 0 eingeben, also 1110110 z.B. Gebaut habe ich das auf https://turingmachinesimulator.com/.

//----------------------------------------------------------------------
//Syntax:

//-------CONFIGURATION
name: sub
init: q0
accept: qe

//-------DELTA FUNCTION:
//[current_state],[read_symbol]
//[new_state],[write_symbol],[>|<|-]

// < = left
// > = right
// - = hold
// use underscore for blank cells

q0,1 // 1en 1.Op überspringen
q0,1,>

q0,0
q1,0,>

q1,0 // 0en überspringen
q1,0,>

q1,1
q2,1,>

q2,0 // mehr als eine 1 im 2. Op? Ja->q5, nein->q3
q3,0,<

q2,1
q5,1,>

q5,1 // 1en 2.Op überspringen, dann auf letzte 1 des 2.Op
q5,1,>

q5,0
q6,0,<

q6,1 // letzte 1 des 2. Op durch 0 ersetzen
q7,0,<

q7,1 // zurück, 1en 2. Op überspringen
q7,1,<

q7,0
q8,0,<

q8,0 // zurück, 0en überspringen
q8,0,<

q8,1 // letzte 1 des 1. Op auf 0 setzen, zurück zu q1
q1,0,>

q3,1 // letzte 1 des 2. Op auf 0 setzen
q4,0,<

q4,0 // zurück, 0en überspringen
q4,0,<

q4,1 // letzte 1 des 1.Op auf Null setzen, zum Ende
qe,0,>

STP077: Liste von Listen

Thu, 21 Aug 2025 19:40:00 GMT

Als der inoffizielle Wikipedia-Vorlesepodcast sehen wir es als unsere Pflicht, eine Eigenheit dieser anzusprechen: nämlich Listen von Listen, obwohl es uns eigentlich um Listen im Speicher geht.

Shownotes

Rückbezüge:
- fundamentale Datenstrukturen siehe STP071: Felder/Listen, ~~assoziative Datenfelder (Maps), Graphen~~
- Frage: Wie stellt man solche Datenstrukturen im Speicher dar? Gibt es darauf überhaupt die eine richtige Antwort?
- algorithmische Komplexität siehe STP029: Liste mit n Elementen ausdrucken in O(n), aber sortieren in O(n log(n)) bis O(n^2)
- Speicherallokation siehe STP047 und Speicherschutz siehe STP019: Bezug wird gleich klar werden
Listen kann man als verkettete Liste darstellen
- klassisches Studienobjekt in Erstsemester-Datenstrukturen-Vorlesungen
- intuitiv verständlich: Parallele zu segmentierten Halsketten
- wahlweise einfach oder doppelt verkettet
- effiziente Operationen: Einfügen am Ende, Entfernen am Ende
- ineffiziente Operationen: Einfügen in der Mitte, Wahlzugriff/Suche
- Vergleichstabelle mit Darstellung der Zeiteffizienz
- alles in allem durchwachsene Performance -> geht es besser?
alternative Strategie: interne Darstellung der Liste als balancierter Baum (oder evtl. "ausgeglichener Baum")
- außerdem Link auf die englische Wikipedia, die nicht nur unbalancierte, sondern auch balancierte Bäume zeigt
- kann nur sortierte Listen darstellen
- Idee: Wurzelknoten hat das Median-Element, dann der linke Ast alle kleineren und der rechte Ast alle größeren Elemente
- im Grunde alle gängigen Operationen mittelschnell: Wahlzugriff/Suche, Einfügen an beliebigen Stellen, Entfernen von beliebigen Stellen (Änderungen erfordern im Allgemeinen ein Austarieren des Baumes)
- große Variation von Implementationsstrategien für dieses Balancieren -> hier nicht
verkettete Listen und balancierte Bäume sehen auf dem Papier ziemlich effizient aus, haben aber in ihrer reinen Form pathologisch schlechtes Speicherverhalten
- hoher Platzverbrauch: z.B. bei einfach bzw. doppelt verketteten Listen muss zu jedem Element müssen noch eine bzw. zwei Speicheradressen abgelegt werden
- hohe Allokationslast: wenn nicht eine Arena oder ein vergleichbarer Small Object Allocator verwendet wird
- schlechte Lokalität: beim Durchlaufen nachfolgender Elemente werden im schlimmsten Fall ständig unterschiedliche Speicherseiten getroffen, was fortlaufend Seitenfehler verursachen kann
in der Praxis mit Abstand dominante Implementationsstrategie: dynamische Felder
- Beobachtung: Einfügen oder Löschen an beliebigen Stellen wird kaum gemacht; man hängt eher mehrmals ans Ende an und sortiert dann, falls nötig
- Idee: Optimieren auf Einfügen am Ende bei möglichst optimalen Speicherverhalten
- Umsetzung: einfaches Feld (ein fortlaufendes Stück Speicher, in dem mehrere Elemente hintereinander abgelegt werden) mit aktuellem Füllstand N und Kapazität K
- Einfügen ans Ende: normalerweise einfach N erhöhen; wenn N nicht in K passt, größeren Speicher reservieren, alles hinüberkopieren und die alten Speicherallokation verwerfen
- Löschen vom Ende: einfach N reduzieren, keine Deallokation erforderlich
- Einfügen am Anfang oder in die Mitte: alle Elemente dahinter nach hinten verschieben
nahezu optimales Speicherverhalten von dynamischen Feldern begründet ihre Dominanz
- Platzverbrauch: neben der Speichergröße der Elemente selber nur zwei Zahlen (N und K)
- Allokationslast: Vergrößern geht für gewöhnlich in exponentiellen Schritten und wird damit für wachsende Listen immer seltener nötig
- Lokalität: lineare Suche durch die Liste geht linear durch den Speicher hindurch -> folgende Speicherseiten können vom Prozessor oft schon auf Verdacht vorgeladen werden
- trotzdem: die anderen Datenstrukturen haben auch ihre Berechtigung (z.B. modifizierte balancierte Bäume als Basis für Datenbank-Indizes)
Xyrill will auch noch auf analoge Weise über Maps und Graphen reden -> weiter in STP079

STP076: Debugging

Thu, 31 Jul 2025 18:00:00 GMT

Die Zeiten, in denen wie von Grace Hopper "actual bugs" in Computern gefunden werden, sind wohl weitestgehend vorbei. Trotzdem ist Debugging bis heute eine Sache, um die man in der IT nicht herumkommt.

Shownotes

Wikipedia definiert den Begriff:

Als Debuggen (dt. Entwanzen) oder Fehlerbehebung bezeichnet man in der Informatik den Vorgang, in einem Computerprogramm Fehler oder unerwartetes Verhalten zu diagnostizieren und zu beheben. Die Suche von Programmfehlern (sogenannten Bugs) ist eine der wichtigsten und anspruchsvollsten Aufgaben der Softwareentwicklung und nimmt einen großen Teil der Entwicklungszeit in Anspruch. Ein guter Programmierer muss daher auch das Debuggen beherrschen und umgekehrt: Nicht jeder gute Programmierer ist auch ein guter Debugger.

Xyrill hat eine Anekdote: Firefox im Hotel-WLAN hängt beim Starten vier Minuten
- nicht dramatisch, könnte man auch hinnehmen (oder halt auf einen anderen Browser wechseln)
- Xyrill war aber in der Stimmung, zu debuggen
Kategorie 1: Werkzeuge zum Mitlauschen
- traceroute (bzw. tracert unter Windows): Nachverfolgung der Netzwerkroute zu einem bestimmten Ziel anhand von Ping-Paketen mit begrenzter TTL; stark variable Pings oder plötzliche Anstiege des Pings deuten auf ein Problem an dem entsprechenden Hop hin
- tcpdump und Wireshark: Mitschneiden aller Netzwerkpakete, die über ein Netzwerk-Interface versendet oder empfangen werden (evtl. mit Suchmuster, z.B. "nur auf Port 80" oder "nur für Ziel-/Quelladresse 192.168.0.1")
- mitmproxy et al: Fangnetz für HTTP-Anfragen und -Antworten, die von einem Prozess geschickt und empfangen werden (quasi wie tcpdump, aber einige Netzwerkschichten höher); super zum Reverse-Engineering von webbasierten APIs
- mal nicht Netzwerk: strace listet alle Syscalls (Systemrufe) auf, die ein Prozess während seiner Lebenszeit macht (siehe Beispiel unten)
- zurück zum Hotel-WLAN-Beispiel: strace zeigt Timeout bei DNS-Anfrage zum eigenen Hostnamen jeweils 2x nach 120s
- Grund für diese Anfragen bleibt unklar, aber die Lösung ist eindeutig: expliziter Eintrag für den eigenen Hostnamen in /etc/hosts, um die DNS-Abfrage zu umgehen
Kategorie 2: Werkzeuge zum Nachverfolgen
- printf-Debugging: im Programmcode vorrübergehend Befehle einbauen, die zu sinnfälligen Zeitpunkten Logmeldungen ausdrucken, insb. beinhaltend den aktuellen Zustand von bestimmten Variablen (sprich: transiente Form von Logging, siehe STP032)
- Debugger wie gdb: Ausführung eines Programms bis zum Moment des Crashs oder bis zu benutzerdefinierten Haltepunkten; dann schrittweise Ausführung bzw. Inspektion von Variablen (flexibler als printf-Debugging, aber erfordert direkten Zugriff auf den Prozess)
- Profiler wie valgrind: Ausführung eines Programms und währenddessen Erfassung von Statistiken zu Laufzeit- und Speichernutzung, um Speicherzugriffsfehler oder Ineffizienzen aufzudecken
Kategorie 3: Werkzeuge zum Zurückverfolgen
- Bisektion z.B. mit git bisect: Aufspüren derjenigen Änderung in einem Versionsverwaltungssystem, die eine bestimmte Verhaltensänderung (z.B. einen Bug oder einen Performance-Einbruch) ausgelöst hat

Beispiel einer strace-Ausgabe für den Befehl mv /tmp/foo /tmp/bar (stark verkürzt):

$ strace mv /tmp/foo /tmp/bar
execve("/usr/bin/mv", ["mv", "/tmp/foo", "/tmp/bar"], 0x7fff820357b0 /* 67 vars */) = 0
... (ca. 60 Zeilen an Setup-Phase der libc und anderer Shared Libraries ausgelassen) ...
ioctl(0, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
renameat2(AT_FDCWD, "/tmp/foo", AT_FDCWD, "/tmp/bar", RENAME_NOREPLACE) = -1 EEXIST (File exists)
openat(AT_FDCWD, "/tmp/bar", O_RDONLY|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
newfstatat(AT_FDCWD, "/tmp/foo", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/tmp/bar", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid()                               = 1001
faccessat2(AT_FDCWD, "/tmp/bar", W_OK, AT_EACCESS) = 0
renameat2(AT_FDCWD, "/tmp/foo", AT_FDCWD, "/tmp/bar", 0) = 0
lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

STP075: Prozessorarchitekturen im Vergleich

Thu, 10 Jul 2025 14:45:00 GMT

Nach einer sehr deutlichen Einordnung der Aufnahmezeit kommen wir im Wesentlichen zu den Unterschieden zwischen x86 und ARM. Natürlich wird auch geklärt, was das ist. Gegen Ende gibt es noch ein paar Meinungen und Weissagungen zum Thema KI.

Shownotes

Rückbezug STP011: grundsätzliche Beschreibung von Maschinensprache
- siehe Beispiel unter dem obenstehenden Link
- Maschinensprache ist spezifisch für die Prozessorarchitektur, genauer die Befehlssatzarchitektur (instruction set architecture, ISA)
heutzutage relevante ISA
- x86: PCs, Notebooks, Server, Supercomputer, Apple Macs bis 2020
- ARM: Smartphones, Tablets, Apple Macs seit 2020, Einplatinencomputer (SBC) wie Raspberry Pi
- Embedded: AVR, MIPS, etc.
- Hochleistungsrechnen: neben x86 noch Power und SPARC
- Neuentwicklungen: RISC-V, LoongArch
Warum ist die Wahl der ISA wichtig?
- ISA beschreibt nominal, wie ein CPU die Bits in einer ausführbaren Binärdatei (sprich: die kodierte Form der Maschinensprache) zu interpretieren hat
- daraus als Konsequenz Festlegung von Hardware-Parametern wie der Adressbreite oder der Anzahl und Größe der verfügbaren Register
- Designentscheidungen in der ISA wirken sich auf die maximal erreichbare Performance und auf die Energieeffizienz aus
- klassischerweise Gegenüberstellung zweier verschiedener Design-Philosophien: Complex Instruction Set Computing (CISC) und Reduced Instruction Set Computing (RISC) (die Grenzen verschwimmen aber in der Praxis)
- historischerweise war CISC die Domäne großer CPU-Hersteller, die sich ein kompliziertes Design leisten konnten, um dem Programmierer Arbeit abzunehmen (z.B. Intel); und RISC die Domäne kleiner CPU-Hersteller, die aus möglichst wenig Arbeitseinsatz möglichst viel erreichen wollten
Was steht in einem Maschinencode-Befehl drin?
- grundsätzlich eine Operation, die ausgeführt wird (z.B. "Addition zweier 64-Bit-Zahlen")
- als Quellen für Argumente und Ziel für das Ergebnis: entweder Register, Speicher oder Immediate-Argumente
  - Beispiel CISC: 20 verschiedene Ausführungen des ADD-Befehls in x86-64
  - Beispiel RISC: 2 verschiedene Ausführungen des ADD- bzw. ADDI-Befehls in RISC-V (RV32I)
- wenn RISC wie bei RISC-V eine Load/Store-Architektur verwendet, muss man also im Zweifelsfall Argumente erst aus dem Speicher in Register laden
  - dadurch tendenziell mehr Maschinencode, aber weniger Komplexität in der CPU
Abwägungen zwischen Energieeffizienz (ARM) und Performance (x86)
- aktueller ARM-Befehlssatz (A64) hat durchgängig 4 Byte große Befehle, was das Dekodieren vereinfacht; x86-Befehle haben eine variable Breite zwischen 1 und 15 Byte
- x86 hat eine lange Pipeline, um u.a. die komplexen Befehle in kleinere Teilschritte (Micro-Operations) zu zerlegen oder bestimmte häufige Befehlssequenzen in effizientere Gruppen (Macro-Operations) zu fusionieren und damit die Performance zu steigern; ARM-Prozessoren machen das nicht und sparen dadurch Energieaufwand
- x86 hat für bestimmte Rollen designierte Spezialregister, die je nach Befehl feste Bedeutungen haben; ARM (und RISC allgemein) verwendet für fast alles 31 General-Purpose-Register

STP074: Literatur: Vom Mythos des Mann-Monats, Teil 2

Thu, 19 Jun 2025 19:20:00 GMT

Beim letzten Mal war zuviel Buch für zu wenig Zeit übrig. Daher nun die Fortsetzung mit zwar gelegentlich etwas angestaubten, im Großen und Ganzen aber sinnvollen, Vorschlägen zur Organisation von Softwareentwicklung.

Shownotes

Fortsetzung aus STP068. Wir lesen weiterhin die englische Erstausgabe von 1975, die im Internet Archive digitalisiert wurde.

Kapitel 4: Aristokratie, Demokratie und System-Design

Brooks beschreibt als Leitmotiv die Kathedrale von Reims, die von acht Generationen von Baumeistern errichtet wurde, aber trotzdem eine beachtliche gestalterische Kohärenz aufweist, da die nachfolgenden Generationen das ursprüngliche Design ungewöhnlich stark respektieren: "Das Ergebnis verkündet nicht nur die Herrlichkeit Gottes, sondern auch seine Macht, gefallene Menschen von ihrem Stolz zu befreien."
- Kontrast nicht nur zu den meisten anderen Kirchenbauten, sondern auch zu Programmsystemen
- dort aber nicht wegen Mehrgenerationalität, sondern wegen Vielstimmigkeit
- These: konzeptionelle Integrität ist die wichtigste Eigenschaft im System-Design (vgl. STP006: Unix-Philosophie)
- Vorteil: bessere Verwendbarkeit und Erlernbarkeit
- Umsetzung: das Design sollte von einigen wenigen Architekten kontrolliert werden, die im Interesse des Benutzers handeln; doch hieraus drei Problemstellungen
Problem 1: Folgt hieraus nicht eine aristokratische Klassengesellschaft von wenigen Vordenkern und bauendem Fußvolk?
- nein, auch auf der Implementationsebene gibt es viele interessante Entscheidungen zu treffen
  - Brooks zitiert einen Aphorismus aus der Kunst: "Form befreit.", sprich: Kreativität erwächst aus dem Umgang mit Beschränkungen
- in der Architektur geht es darum, was man dem Nutzer präsentiert (das "Was")
- in der Bauphase geht es darum, wie man dieses Verhalten erreicht (das "Wie")
- es ist absolut gewollt, dass die Erbauer auch Designideen vorschlagen und auf Beschränkungen hinweisen; nur entscheiden sie nicht final über das Design
Problem 2: Wie verhindert man, dass die Architekten von den Zwängen der Realität abgekoppelt im Elfenbeinturm davonschweben?
- Xyrill bringt eines seiner Lieblings-Schimpfwörter ins Spiel: "Architektur-Astronaut"
- Lösung dieselbe wie für das dritte Problem
Problem 3: Wie stellt man sicher, dass die Erbauer mit allen wichtigen Details des Designs vertraut gemacht werden?
- Lösung: die Erbauer frühzeitig in den Design-Prozess involvieren, Ideen aufnehmen, Designvorschläge auf praktische Umsetzbarkeit abklopfen etc.
- Vergleich mit der Errichtung eines Gebäudes: man kann die Erbauer nicht erst einstellen, wenn der Plan fertig ist, weil in der Software-Entwicklung immer noch vieles explorativ und nicht nach Standard-Muster abläuft

Kapitel 5: Das Problem des zweiten Systems ("Second-System Effect")

in diesem Dialog zwischen Architekt und Erbauer stellen sich viele Ideen des Architekten als unpraktikabel heraus und werden verworfen... bis zum nächsten Mal
- Szenario: das erste System war erfolgreich, der Architekt hat Prestige und Erfahrung gewonnen
- "Dieses zweite ist das gefährlichste System, dass man jemals entwirft." -> Second-System Effect
- beim dritten und vierten System hat man dann mehr Erfahrung, was tatsächlich funktioniert und was nur auf dem Papier gut aussieht
- Xyrill legt Wert darauf, dass seine jüngeren Kollegen früh ihre eigenen Komponenten alleine entwerfen, damit sie dann auch in die Probleme ihrer eigenen Design-Entscheidungen reinlaufen und daraus lernen
der vorgeschlagene Lösungsansatz ist leider etwas antiquiert: "Eine Disziplin, die dem Architekten die Augen öffnen wird, ist es, jeder kleinen Funktion einen Wert zuzuweisen: Fähigkeit X ist nicht mehr wert als M Bytes Speicher und N Mikrosekunden pro Aufruf. Diese Werte dienen als Richtschnur für die ersten Entscheidungen und während der Implementierung als Leitfaden und Warnung an alle."
- nicht realisitisch in Zeiten, wo die meisten Programmierer offenkundigerweise noch nie einen Profiler verwendet haben oder auch nur ein Gefühl für ihre eigene Ressourcenvergeudung haben

Kapitel 6: Weitergabe von Informationen ("Passing the Word")

Wie stellt eine Gruppe von 10 Architekten sicher, dass ihre Entwürfe von 1000 Mitarbeitenden berücksichtigt und von allen Benutzern verstanden werden?
- gute Dokumentation ist erforderlich: Handbücher für die Benutzer, Architekturpläne für die Erbauer
Qualitäten guter Dokumentation
- vorzugsweise aus der Feder von nur ein oder zwei Personen -> Fokus auf konzeptionelle Integrität
- Beschreibung sowohl des definierten Verhaltens als auch der Grenzen der Definiertheit
- Definitionen in formaler Notation und/oder präziser Sprache, um Lücken und Widersprüche im Design möglichst früh aufzudecken
- Anti-Pattern: Definition eines Systems durch sein eigenes Verhalten
  - führt zu Bug-für-Bug-Kompatibilität (siehe STP050) bzw. Ossifikation (siehe STP056): inhaltliche Widersprüche zwischen der ursprünglichen Implementation, späteren Revisionen sowie später abgeleiteten Spezifikationen
- gutes Pattern: Spezifikation maschinenlesbar darstellen, damit die Erbauer die Konformität ihrer Implementation mit der Spezifikation automatisch prüfen können
  - aktuelles Beispiel: formale Spezifikation von Schnittstellen mittels OpenAPI
Wie erarbeitet man Designs? Vorschlag von Brooks:
- Meetings zwischen den Architekten und involvierten Erbauern, in denen das Problem vorgestellt und mehrere Designideen gesammelt werden
- dann Erarbeitung von detaillierten Designentwürfen mit Pro-/Kontra-Analyse
- daraus entweder sofortiger Konsens oder Entscheidung eines Chefarchitekten
- klingt offensichtlich, ist aber im agilen Zeitalter selten anzutreffen
noch eine kleine Anmerkung am Rande: auch Kurzabsprachen am Telefon sollten dokumentiert werden :)

Kapitel 7: Warum ist der Turm zu Babel gefallen?

Woran können Projekte scheitern?
- unklare Zielstellung
- nicht genug Personal
- nicht genug Material/Budget
- nicht genug Zeit
- unzureichende Technologien
- ineffektive Kommunikation
Wie sollen Teams kommunizieren? Neben direkten Gesprächen z.B. via Telefon und Gruppengesprächen z.B. in Meetings wird ein Arbeitsbuch vorgeschlagen.
- nicht ein konkretes Dokument, sondern eine Struktur für alle Dokumente im Projekt
- die Dokumentation am Ende geht aus den Memos am Anfang hervor, also gleich richtig machen
- Memos sollen durchnummeriert werden, damit man später darauf Bezug nehmen kann (wir fühlen uns an RFCs erinnert) -> Arbeitsbuch ergibt sich als Baumstruktur aller Memos (wir fühlen uns an Hypertext erinnert, und in der Tat wird Douglas C. Engelbart am Rande erwähnt)
- Brooks diskutiert dann praktische Unterschiede zwischen Papier und Microfiche, die heutzutage keine Relevanz mehr haben (aber ein Nachteil: die Verteilung aktualisierter physischer Seiten sorgte dafür, dass die Erbauer mitbekamen, wo sich wann was ändert)

D. L. Parnas von der Carnegie-Mellon-Universität hat eine noch radikalere Lösung vorgeschlagen. Seine These lautet, dass ein Programmierer am effektivsten ist, wenn er von den Details der Konstruktion von Systemteilen, die nicht seine eigenen sind, abgeschirmt wird, anstatt ihnen ausgesetzt zu sein. Dies setzt voraus, dass alle Schnittstellen vollständig und genau definiert sind. Dies ist zwar ein solider Entwurf, aber in der Abhängigkeit von seiner perfekten Ausführung ist eine Katastrophe vorprogrammiert. Ein gutes Informationssystem deckt Schnittstellenfehler auf und regt zu deren Korrektur an.

Xyrill stimmt voll und ganz zu: sorgfältiges Gegenlesen der Meeting-Minutes der benachbarten Teams ist zwar extrem zeitaufwändig, verhindert aber regelmäßig katastrophale Design-Entscheidungen
Organisationsstruktur: Brooks hält eine baumförmige Organisationsstruktur für unausweichlich (mehrere Vorgesetzte für einen Angestellten = Chaos) und schaut darauf, was jedes Team haben sollte
- Produzent ("Producer"): stellt das Team zusammen, verteilt Arbeit, definiert Ziele und Zeitpläne, kommuniziert außerhalb des Teams
- Architekt bzw. technischer Leiter ("Technical Director"): entwirft das Design und entwickelt es fortlaufend weiter, kommuniziert innerhalb des Teams
- drei Optionen, wie diese Rollen verteilt sein können
Option 1: Produzent und Architekt sind dieselbe Person
- nur für kleine Teams gangbar, bis etwa 3-6 Personen
- "Denker sind rar; Macher sind rarer; und Denker-Macher sind am rarsten."
Option 2: Produzent als Chef, Architekt als seine rechte Hand
- funktioniert nur, wenn der Produzent die technische Autorität des Architekten akzeptiert
- Xyrill hat lange in einem derartigen Zweierteam als Architekt gearbeitet und weiß, dass es funktionieren kann; kommt aber extrem auf die interpersonelle Dynamik des Duos an
Option 3: Architekt als Chef, Produzent als seine rechte Hand
- findet Brooks am besten; Xyrill ist geneigt, zuzustimmen

Noch mehr

Es gibt noch acht weitere Kapitel, die wir irgendwann™ mal besprechen werden.

STP073: Was aus Holz

Thu, 29 May 2025 20:00:00 GMT

Diesmal vieleicht doch eher aus Interesse denn aus Resignation. Wieder geht's um Holz. Allerdings noch nicht so weit, wie Xyrill sich das zuerst vorgestellt hatte.

Shownotes

Rückbezug STP072: Programmierung besteht aus Algorithmen und Datenstrukturen, Holzbau besteht aus Materialien (siehe STP053) und Fertigungstechniken (diesmal)
- Als Beispiel die Herstellung einer Leimholzplatte (z.B.: Tischplatte, Schrankseite, Wandverkleidung, …) aus Schnittholz. Wir gehen die Technologie durch und Besprechen dabei auch die Maschinen. Hierbei hauptsächlich stationäre Werkstattmaschinen im Gegensatz zu Handmaschinen: https://blog.schneidbrettguru.de/wann-ist-ein-holzschneidebrett-wirklich-gut-gemacht/
Schritt 1: Auftrennen
- heute praktisch immer mit der Kreissäge, besonders für große Querschnitte praktisch wegen Schiebeschlitten, beim Auftrennen Auftrennblatt
Schritt 2: Abrichten
- mithilfe einer sogenannten Abrichthobelmaschine
- plan machen und Winkelkante erstellen
Schritt 3: Aushobeln
- Herstellung von parallelen Flächen zu den bisher abgerichteten mittels Dickenhobelmaschine
Exkurs Fügen:
- Stumpfe Fuge: glatte Flächen
- Gefälzte Fuge: mit einfachem Falz
- Nut-Spund
- Nut-Feder
- Kronenfuge
- Die profilierten Verbindungen werden mit einer Tischfräsmaschine hergestellt, eventuell auch mit einer Oberfräse.
Schritt 4: Verleimen
- In userem Fall einfach mit Weißleim, weil Leime ca. 5 Einzelsendungen sind
- Pressen mit Zwingen oder mechanischen Pressen
Schritt 5: nochmal Aushobeln
- jetzt aber die ganze Platte mit einem Mal, eventuell auch vorher abrichten
Schritt 6: nochmal Winkelkante
- jetzt aber die ganze Platte mit einem Mal
Schritt 7: Formatzuschnitt
- wieder mit der Formatkreissäge, jetzt aber die ganze Platte und mit einem Feinschnittblatt

STP072: Der Datentypeneisberg

Thu, 08 May 2025 20:15:00 GMT

Auch heute geht es mit Rost und Kaffee weiter, allerdings mit grundsätzlicheren Datentypen. ttimeless wird von besonders winzigen Datentypen überrascht und Xyrill formuliert Gedanken darüber, warum Struktur das Handeln bestimmen sollte.

Shownotes

Rückbezug STP071: anhand von JSON haben wir die sichtbaren Datentypen besprochen
- heute tauchen wir unter die Wasseroberfläche ab und schauen auf Typen, die man eher im Speicher als in einer Datei sieht
Einwurf Kombinatorik: Wieviele mögliche Werte haben die vorgenannten Typen (sofern nicht unendlich)? (wir schreiben K(T) für die Kardinalität des Typs T)
- Boolean: K(bool) = 2 (true oder false)
- Zahlen: K(T_N) = 2^N Werte für Zahltypen mit N Bits (z.B. 256 für i8 oder 65536 für u16), weil jedes Bit zwei Werte hat, die unabhängig voneinander gewählt werden können
- Listen fester Länge: K([T; N]) = K(T)^N für K(T) mögliche Werte des Elementtyps T und Länge N
- Listen variabler Länge: K(Vec<T>) = ∞ bis auf praktische Platzbeschränkungen
Listen wirken sich auf die Kardinalität also wie eine Potenzierung aus
- Gibt es auch andere Rechenoperationen? -> algebraische Datentypen
Produkttypen: Gesamttyp P enthält je einen Wert von Typ T_1, T_2, ..., T_N, somit K(P) = K(T_1) * K(T_2) * ... * K(T_N)
- in Rust: entweder als Tupel (geordnete Folge von Werten, die mit Zahlenindizes bezeichnet sind), z.B. type Vector3D = (f64, f64, f64), oder als Strukturtypen (ungeordnete Menge von Werten, die mit Namen bezeichnet sind, z.B. struct Person { first_name: String, last_name: String })
- in JSON: Tupel als Listen, Strukturtypen als Objekte (beim Einlesen muss die Elementzahl bzw. die Namen der Elemente geprüft werden)
Summentypen: Gesamttyp S enthält entweder einen Wert vom Typ T_1 oder T_2 oder ... oder T_N, somit K(P) = K(T_1) + K(T_2) + ... + K(T_N)
- in Rust: Enumerationstyp, z.B. enum ParseResult { Ok(DataStructure), Err(ParseError) }
- in JSON: keine klare Konvention, Serialisierung in Rust erzeugt ein Objekt mit einem Eintrag, die nach der jeweiligen Variante benannt ist (z.B. {"Ok": ...})
sehr kleine Spezialfälle: Gibt es Datentypen, die kleiner als bool sind?
- Produkttyp mit null Feldern (in Rust struct Empty {}): nur ein möglicher Wert (1 ist das neutrale Element der Multiplikation)
  - in JSON kann man das als null serialisieren
  - in Rust kommt dies im Summentyp enum Option<T> { Some(T), None } vor; None ist hier im Prinzip eine Kurzschreibweise für None(Empty)
- Summentyp mit null Varianten (in Rust enum Impossible {}): keine möglichen Werte (0 ist das neutrale Element der Addition)
  - in JSON nicht darstellbar (keine Werte haben keine Serialisierung)
  - in Rust kommt so ein Typ in Funktionen vor, die kein Ergebnis liefern (z.B. quit())
  - nützlicher, als es zunächst erscheint, sobald Monomorphisierung ins Spiel kommt
Abendgedanken: Warum das ganze Gerede über Datentypen?
- angewandte Programmierung besteht aus zwei (verwandten) Teildisziplinen: Algorithmen (das Wie, der Rechenteil) und Datenstrukturen (das Was, der Speicherteil)
- Xyrill hält Datenstrukturen für das Fundament; die Wahl der Algorithmen muss an zweiter Stelle kommen
- vergleichbarer Ansatz in klassischen Software-Design-Lehrbüchern wie SICP und HtDP

STP071: Das Periodensystem der Datentypen

Thu, 17 Apr 2025 18:25:00 GMT

Offenbar gibt es unterschiedliche Ergebnisse, wenn verschiedene Datentypen für die gleichen Dinge verwendet werden. Wir fangen heute mal damit an, zu verstehen, welche Datentypen es denn überhaupt gibt. Außerdem geht es scheinbar um Kaffee und Rost.

Shownotes

JSON: ein populäres Format für die Serialisierung von Daten
- Serialisierung: "Abbildung von strukturierten Daten auf eine sequenzielle Darstellungsform", insb. auf Bytefolgen wie in einer Datei oder einer Datenübertragung im Netzwerk
- JSON ist bekannt dafür, nicht erfunden, sondern "entdeckt" worden zu sein
- außerdem relativ minimal: nur sechs verschiedene Grundstrukturen
- aber trotzdem relativ universell: damit unser Ausgangspunkt für die Kartografierung der Welt der Datentypen
- außerdem Gegenüberstellung mit dem Typvorrat von Rust (einer zeitgenössischen Programmiersprache mit einem detaillierten Typsystem)
atomare Datentypen: einzelne Werte (C++ nennt sie "Plain Old Data" (POD), Perl nennt sie "Skalare")
- Boolean: ein Bit (wahr oder falsch)
  - Typvorrat in Rust: bool
  - in JSON: true oder false
- Zahlen: in verschiedenen Bitgrößen, mit oder ohne Vorzeichen, Ganzzahl oder Fließkommazahl
  - Typvorrat in Rust: u8/i8, u16/i16, u32/i32, u64/i64, u128/i128, usize/isize, f32, f64
  - in JSON: wie gewohnt ausgeschrieben (z.B. 42, -23.5) oder in wissenschaftlicher Notation (z.B. 7.297e-3 oder -6.022E23)
- Zeichenfolgen: nicht wirklich unteilbar, aber wird für gewöhnlich als einzelner Wert verstanden
  - Typvorrat in Rust: String (UTF-8), OsString (Kodierung gemäß Zeichentabelle des Systems) und andere
  - in JSON: als Zeichenkette mit Anführungszeichen und mit Escape-Sequenzen für nicht druckbare Zeichen (z.B. "Mit freundlichen Grüßen\nErika Mustermann")
- fehlender Wert: in JSON null (heißt woanders vielleicht auch nil)
  - Typvorrat in Rust: siehe später
Listen: ein abgeleiteter Datentyp
- deswegen vorhin "atomar": der Typ einer Liste bestimmt sich aus dem Typ der Elemente (in statisch typisierten Programmiersprachen ist z.B. "Liste von 8-Bit-Zahlen" etwas anderes als "Liste von Strings" oder "Liste von Listen von Strings")
- Typvorrat in Rust:
  - mit variabler Länge: Vec<X>, wobei X für den Typ der Elemente steht (Beispiele zu oben: Vec<u8>, Vec<String>, Vec<Vec<String>>); der Name "Vec" deutet auf die Struktur im Arbeitsspeicher hin
  - mit fester Länge: [X; N], wobei N für die Anzahl von Elementen steht
- in JSON: kommagetrennte Liste der Elemente in eckigen Klammern (z.B. [42, 23])
- Unterschiede zu Rust:
  - JSON ist nicht statisch typisiert und hat nur einen Listentyp, der alle möglichen Elemente enthalten kann und beliebig lang sein kann (z.B. [42, "Hallo", []])
assoziative Datenfelder: ein anderer abgeleiteter Datentyp
- enthält nicht einzelne Elemente, sondern Paare von Schlüssel und Wert; ermöglicht schnellen Zugriff auf einen Wert anhand seines Schlüssels
- heißt je nach Programmiersprache bzw. Datenformat "Objekt", "Map", "Dictionary" etc.
- Typvorrat in Rust: unter anderem HashMap<K, V>, wobei K der Schlüsseltyp ("key") und V der Werttyp ("value") ist; der Name "HashMap" deutet auf die Struktur im Arbeitsspeicher hin
- in JSON: kommagetrennte Liste von Wertpaaren in geschweiften Klammern, die Wertpaare jeweils mit Doppelpunkt getrennt; der Schlüssel muss ein String sein (z.B. {"Karo": 9, "Herz": 10, "Pik": 11, "Kreuz": 12})
- wiederum Unterschied zu Rust: Werte verschiedener Typen dürfen gemischt werden
Damit ist alles beschrieben, was JSON kann, doch es gibt so viel mehr! Beispiele für abgeleitete Datentypen:
- Mengen ("Sets"): wie Listen, aber ohne definierte Ordnung
  - in Rust: HashSet<X>; der Name "HashSet" deutet auf die Struktur im Arbeitsspeicher hin
- Graphen: Netzwerke von Knoten mit Kanten dazwischen (z.B. Straßenkarte: Kreuzungen = Knoten, Straßen = Kanten)
  - in Rust: kein entsprechender Typ in der Standardbibliothek
  - ähnlich wie bei Listen und assoziativen Datenfeldern viele verschiedene Implementationsstrategien, aber bei Graphen gibt es keinen "Standardansatz"
- Außerdem ist JSON relativ restriktiv in der Auswahl an PODs. Andere Serialisierungsformate unterstützen zum Beispiel Datums- oder Zeitangaben, Referenzen auf externe Dateien etc.
im Gespräch erwähnt
- Hörtipp: Douglas Crockford bei CoRecursive zur Entstehung von JSON
- Lehrbuch: Structure and Interpretation of Computer Programs

STP070: Blitzgespräche

Thu, 27 Mar 2025 21:22:00 GMT

Manche Dinge geben keine ganze Folge her. Dies ist der Versuch, ein paar davon zusammenzufassen: Wie definiert sich ein Geek? Bringt es etwas, den Computer aus und wieder einzuschalten? Und rechnet es sich vielleicht in umgekehrtem Polnisch besser?

Shownotes

im Intro erwähnt:
- Eternal September
- Im Dunkeln ist alles viel aufregender

Talk Nr. 1: Geek Code

Primärquelle (Version 3.12, Stand vom 5. März 1996): https://web.archive.org/web/20090220181018/http://geekcode.com/geek.html
vordergründig: eine kompakte Notation zur Selbstbeschreibung von Geeks durch eine Menge von Attributen und Interessen
- Beispiel: das Attribut d beschreibt den eigenen Dresscode (d++ für den Anzugträger, d- für Jeans und T-Shirt, !d für nackt etc.)
- diverse Modifier, z.B. $ für "damit verdiene ich Geld" oder > für ein persönliches Entwicklungsziel
- Beispiel: C++ alleine ist "ich kenne mich gut mit Computern aus", C++>$ ist "...und möchte damit Geld verdienen"
- Xyrill fühlt sich an die Grammatik agglutinierender Sprachen erinnert
Parallele zum Jargon File (siehe STP050): Geek Code ist ein Produkt seiner Zeit und Subkultur mit veralteten Debatten (z.B. interessiert sich heute noch jemand für Babylon 5 oder Akte X?) tendenziösen Einschätzungen (z.B. vgl. h--- mit r+++)
Kann es sowas heute nochmal geben?
- Wahrscheinlich schwierig, man bräuchte zu viele Subkategorien.
- Passt wahrscheinlich nicht für die heutigen visuell dominierten Medien (YouTube, TikTok, Instagram etc.).
- Vielleicht für Dating?

Talk Nr. 2: Ist was dran an "try turning it off and on again"? Ja! Hierzu eine Kurzeinführung in Kombinatorik:

ein Speicher mit einem Bit kann zwei Zustände annehmen (klar)
ein Speicher mit zwei Bit kann 2 * 2 = 4 Zustände annehmen
- Beispiel/Analogie: UI mit zwei Checkboxen
aber nur, wenn die Bits voneinander unabhängig sind
- Beispiel: UI für Ticketkauf, Checkbox 1 = "ist Kind", Checkbox 2 = "ist Rentner"
- von vier Zuständen ist einer ungültig: Kinder können nicht Rentner sein
kombinatorische Explosion: bei mehr Bits exponentiell mehr mögliche Zustände, die meisten davon ungültig
- Programmfehler oder "kosmische Strahlung" können dazu führen, dass ungültige Zustände erreicht werden
- "Aus- und Wiederanschalten" ist die ultimative Form des Zurücksetzens in einen gültigen Zustand

Talk Nr. 3: Umgekehrte polnische Notation

Wie schreibt man mathematische Ausdrücke?
- Infix-Notation: die klassische Schreibweise für mathematische Ausdrücke, bei der Operatoren zwischen ihren Operanden stehen
- Problem: Operationsreihenfolge muss entweder per Konvention ("Punkt vor Strich") oder durch Klammern klargestellt werden (Bsp. 2 * 3 + 5 = (2 * 3) + 5 ≠ 2 * (3 + 5))
- Polnische Notation: Operatoren stehen vor ihren Operanden (Bsp. + * 2 3 5 bzw. * 2 + 3 5)
- hier technisch gesehen keine Klammern notwendig (außer um Menschen das Lesen zu erleichtern, Bsp. + (* 2 3) 5 bzw. * 2 (+ 3 5))
- Umgekehrte polnische Notation (RPN): Operatoren stehen hinter ihren Operanden (Bsp. 2 3 * 5 + bzw. 2 3 5 + *)
Warum würde man das machen wollen?
- RPN entspricht dem Betriebsmodus eines Kellerautomaten (siehe STP021)
- Kellerautomaten kann man extrem günstig in Hardware implementieren (d.h. mit sehr wenig Code, mit sehr wenig Prozessorregistern, mit wenig Speicher)
- Praxisbeispiel: Forth
- Praxisbeispiel: HP-12C

STP069: Anatomie einer GUI

Thu, 06 Mar 2025 18:45:00 GMT

Wer hat sich nicht schon einmal über schlechte Benutzeroberflächen geärgert? Aber wer wiederum hat sich Gedanken gemacht, warum diese Oberflächen so sind, wie sie sind, oder wie das Ganze überhaupt zustande kommt?

Shownotes

Rückbezug zu STP008 (2D-Grafik) und STP010 (3D-Grafik): dort besprochen die grundsätzliche Methodik zum Zeichnen mit Pixeln, aber wer zeichnet hier eigentlich?
- Infografik zum Rendering-Ablauf unter Linux, mit Display-Manager (bzw. heutzutage Wayland-Compositor) und Desktop-Shell
- unter Windows war früher alles in explorer.exe, heute gibt es den Desktop Window Manager dafür
Thema heute: Wie baut man als Anwendungsprogramm seine GUI zusammen?
- klassischer Ansatz: GUI-Toolkit; Programmbibliothek mit vorgefertigten Steuerelementen (Texteingabefeld, Knopf, Checkbox, Listenansicht), siehe Beispielbilder im verlinkten Artikel
- neumodischer Ansatz: Darstellung einer Programmoberfläche mit einer Webbrowser-Engine (z.B. Electron); somit Verwendung von Webtechnologien (HTML, CSS und JavaScript) an Stelle (im Wortsinne) eines GUI-Toolkits
  - bis dahin, dass selbst die Interface-Elemente von Computerspielen mittlerweile quasi mit einem Webbrowser gerendert werden (Beispielprodukt)
  - eine Variation von STP022: Webentwickler gibt es wie Sand am Meer
Wie baut man so ein GUI-Toolkit? Retained Mode vs. Immediate Mode
- Retained Mode: die Grafikbibliothek behandelt die Steuerelemente als langlebige Objekte, die vom Programm über die Zeit manipuliert werden
- Immediate Mode: beim Zeichnen jedes Einzelbildes muss das Programm die gewünschten Steuerelemente neu deklarieren; Grafikbibliothek speichert nur wenig Zustand (z.B. aktuelle Cursorposition oder noch nicht verarbeitete Eingabeereignisse)
- Unterschiede:
  - Retained Mode ist intuitiver (aus Entwicklersicht)
  - Retained Mode führt oft zu einer Duplikation von Zustandsverwaltung (z.B. speichert das Checkbox-Steuerelement ein Bit, ob es angehakt ist; und der Applikationscode selber speichert ein gleichlautendes Bit, ob die entsprechende Funktion aktiviert ist)
  - Immediate Mode ist flexibler (z.B. gibt eine direkte Möglichkeit, die Standard-Steuerelemente noch mit einzelnen Zeichenbefehlen zu erweitern)
  - Immediate Mode kann resourcenschonender sein (z.B. geringerer Speicherverbrauch, weil nicht sichtbare Steuerelemente weniger wahrscheinlich im Speicher gehalten werden)
  - Immediate Mode kann auch mehr Ressourcen verbrauchen (z.B. weil jedes Einzelbild neu gerendert werden muss, auch wenn sich meist in weiten Teilen gar nichts ändert)
- Mischform: React-artige GUI-Toolkits arbeiten im Retained Mode, aber alle Aktualisierungen führen zu einer kompletten Neudeklaration der betroffenen Steuerelemente; diese Deklaration wird dann mit den vorhandenen Steuerelementen abgeglichen
Layoutstrategien: Wie werden Steuerelemente gegeneinander angeordnet?
- Ziel: ein Arrangement von Steuerelementen soll z.B. auf Änderungen der Fenstergröße sinnfällig reagieren
- Beispielbild aus der Dokumentation zu QGridLayout -> bei Änderungen der Höhe des Fensters sollen die beiden oberen Zeilen gleichbleiben und nur die unterste Zeile wachsen
- explizite Deklaration durch den Programmentwickler mühselig: stattdessen berechnen Steuerelemente selbst bestimmte Eigenschaften wie "minimale Größe", "maximale Größe", "sinnvolle Größe" oder "wieviel profitiere ich von Wachstum"
Layoutstrategien bei Webseiten und Webapplikationen
- anhand des Textflusses, z.B. Eingabefelder und Links/Schaltflächen innerhalb von Mengentext (in anderen GUI-Toolkits unüblich; das Web ist durch seine Dokumentenorientierung hier besonders)
- für alles andere bis ca. 2013: tabellenbasierte Layouts mit manuell (z.B. per JavaScript) berechneten Größen; in der Praxis frustrierend und fehleranfällig
- seit 2013: Flexbox für Layout von Elementen mit dynamischer Größe nebeneinander bzw. in Form eines Textflusses
- seit 2017: Grid für Layout von Elementen, die sich in ein dynamisches Raster einfügen
- außerdem seit 2009/2010: CSS Media Queries zum Umschalten zwischen Layouts auf Basis von Eigenschaften des Endgerätes (Bildschirmgröße und -ausrichtung, Maus- oder Touch-Bedienung, Dark Mode oder Light Mode, etc.)
zum Weiterhören: Pentaradio vom März 2024: "UI: Hui oder pfui?"

STP068: Literatur: Vom Mythos des Mann-Monats

Thu, 13 Feb 2025 22:10:00 GMT

In dieser Episode wird ein lang gehegter Traum wahr. Xyrill hat ein Buch gelesen und spricht darüber. Obwohl es nicht sehr dick ist, ist es doch sehr gehaltvoll und so entscheiden wir uns kurz vor Ende der Sendung für eine spontane Planänderung.

Shownotes

Wir lesen die englische Erstausgabe von 1975, die im Internet Archive digitalisiert wurde.

zum Autor: Frederick P. Brooks, Jr. (US-amerikanischer Informatiker, 1931-2022)
- in den 60ern Entwicklungsleiter bei IBM für das Betriebssystem OS/360 (eines der ersten Systeme mit Unterstützung für persistente Massenspeicher mit Wahlzugriff, sprich: Festplatten)
- gilt als Erfinder des Bytes mit 8 Bit; Wikipedia zitiert Brooks aus einem Interview von 2010:

„Die wichtigste Entscheidung, die ich je getroffen habe, war, die IBM-360-Serie von einem 6-Bit-Byte auf ein 8-Bit-Byte umzustellen und damit die Verwendung von Kleinbuchstaben zu ermöglichen. Diese Veränderung verbreitete sich überall.“

zum Buch: "Vom Mythos des Mann-Monats" ("The Mythical Man-Month") dokumentiert Brooks' Erfahrungen als Projekt-Manager in einem der frühen großen Software-Projekte
- nicht als Lehrbuch angelegt, weil es dafür "noch zu früh" gewesen sei, sondern als Serie persönlicher Eindrücke und Lektionen
- fast jedes Kapitel ist ein alleinstehendes Essay
- wir wollen schauen, ob diese Lektionen auch heute noch Bestand haben
- in der ersten Hälfte des Buches (Kapitel 2-7) ist das übergreifende Motiv, wie sich die Arbeit in großen Teams von kleinen Teams unterscheidet
Hörempfehlung: Pentaradio vom Dezember 2022
- anlässlich Brooks' Tod hatten wir über seinen anderen wichtigen Text "No Silver Bullet" und das Thema Komplexität gesprochen

Kapitel 1: Die Teergrube

Teergruben-Analogie: steckt ein Tier mit einem Bein in der Teergrube, kann es das Bein meist aus eigener Kraft herausziehen; alle Beine in der Teergrube sind hingegen meist ein Todesurteil
- analog hierzu: Zähheit/Trägheit in der Software-Entwicklung nicht aus einem bestimmten Grund, sondern aufgrund mehrerer parallel wirkender Gründe
Programme können von Einzelpersonen oder Zweierteams erschaffen werden
- These: aber nicht "Programmsystemprodukte"
vom Programm zum Programmprodukt: Generalisierung (Nützlichkeit für eine ganze Klasse von Situationen), Testabdeckung (siehe STP038), Dokumentation, fortlaufende Wartung -> heute sagt man "Produktisierung" dazu
- Brooks schätzt hier dreimal mehr Aufwand als für das reine Programm
- Xyrill würde heute sogar einen größeren Faktor schätzen, vllt. 4 oder 5: im Bereich der Programmierproduktivität gab es mehr Innovationen beim initialen Schreiben als bei Maintenance (siehe Xyrills Kritik an Ruby als einzeilerorientiert; siehe auch LLMs, aber das verschiebt sich eventuell gerade)
- Parallele zu "warum setzt sich Open Source nicht durch", siehe Besprechnung von "Open Source on its own is no alternative to Big Tech" im Pentaradio vom Dezember 2024
vom Programm zum Programmsystem: Einbettung in ein Netzwerk anderer Programme mit konsistentem Stil und definierten Schnittstellen untereinander
- Brooks legt hier auch Wert auf ein vordefiniertes Ressourcenbudget (CPU-Zeit, Speicher, Datenverkehr) für jedes Teilprogramm -> heute überholt; Effizienz der Belegschaft geht über Effizienz des Produktes
- Brooks schätzt hier mindestens dreimal mehr Aufwand als für die reinen Programme
- Xyrill stimmt im Großen und Ganzen zu: heute zwar öfter von Anfang an wohlgeformte Schnittstellen (vgl. Unix-Philosophie in STP006, JSON in STP071), aber andererseits gestiegene Gesamtkomplexität
Programmsystemprodukt: ein produktisiertes Programmsystem
- somit laut Brooks' Schätzung 3 x 3 = 9 Mal mehr Aufwand als für die einzelnen Programme

Kapitel 2: Vom Mythos des Mann-Monats

Problem 1: Programmierer sind schlecht im Schätzen von Zeitaufwand
- inhärenter Optimismus: für jede Teilaufgabe schätzt man den Aufwand im Fall, dass alles gut geht
- These: das Programm entsteht erst im Kopf und dann in der Realität; letzteres dauert länger, aber ein Programm, dass im Kopf fertig ist, fühlt sich schon fertig an
- Programme sind kristallisierte Gedanken auf eine sehr viel direktere Art und Weise als z.B. Handwerksstücke, die kategorisch in ein physisches Artefakt umgesetzt werden müssen
- Testphasen sind von diesem Optimismus am stärksten betroffen
  - Xyrill stimmt im Prinzip zu; allerdings wird heute versucht, Tests bei der Entwicklung einzugliedern (siehe Besprechung von TDD in STP038)
Problem 2: konventielle Planungsmethoden funktionieren nur, wenn "Personen und Monate austauschbar sind"
- Basiseinheit: Mann-Monat (heute sagt man Personenmonat); die Menge Arbeit, die eine Person in einem Monat verrichten kann
- Messung von Aufwand in Personenmonaten impliziert, dass eine Aufgabe unter mehreren Personen aufgeteilt werden kann und keine Kommunikation zwischen diesen Personen erforderlich ist
  - kommt hin für z.B. Spargelstechen oder Zimmerreinigung im Hotel, aber: "Das Austragen eines Kindes dauert neun Monate, egal, wieviele Frauen der Aufgabe zugewiesen werden."
- zwei Komplikationen: Einarbeitungszeit (linear in der Größe des Personals) und fortwährender Kommunikationsaufwand (quadratisch in der Größe des Personals)
  - Xyrill kann das 100-%-ig bestätigen; in großen Teams verbringen die hochrangigen Techniker signifikant mehr Zeit mit Meetings/Mails/Chat als mit ihrer nominalen Tätigkeit
  - quadratisches Wachstum kann teilweise begrenzt werden durch Einführung von Unterteams mit strikten Rollenverteilungen; dann tritt das Gesetz von Conway in Kraft
Problem 3: der Zeitplan wird durch die Bedürfnisse des Kunden bestimmt, nicht durch die Bedürfnisse der Programmierer
- Restaurant-Analogie: wenn man das langsam gegarte Steak in nur 5 Minuten haben will, wird der Koch sich dem entgegenstellen... oder er dreht halt die Hitze hoch und man kriegt ein schlechteres Produkt
- Programmierprojekte richten sich aber oft dem vom Kunden und/oder Management vorgegebenen Liefertermin: "Es ist sehr schwierig, eine Schätzung energisch, plausibel und arbeitsplatzgefährdend zu verteidigen, die auf keiner quantitativen Methode beruht, durch wenig Daten gestützt und hauptsächlich durch das Bauchgefühl der Manager getragen wird."
- wenn dann beim Testen am Ende eine Verspätung eintritt, ist die Versuchung groß, halb fertige Produkte zu liefern (vgl. "Bananaware")
Problem 4: Was macht man, wenn dann das Kind in den Brunnen gefallen ist und man zu spät dran ist?
- Option 1: Lieferdatum nach hinten verschieben
- Option 2: Umfang reduzieren
  - passiert eventuell auch unter der Hand, zum Beispiel indem beim Design und beim Testen Arbeitstempo gegen Sorgfalt abgewogen wird
  - Xyrill schielt auf sein ständig wachsendes Backlog an "müsste man mal machen"-Aufgaben
- Option 3: weitere Leute hinzufügen
  - Brooks'sches Gesetz: "Das Hinzufügen weiteren Personals zu einem verspäteten Softwareprojekt verspätet es weiter."
  - siehe Problem 2: neue Mitarbeiter müssen von den bestehenden Teammitgliedern eingearbeitet werden und erhöhen dann permanent den Kommunikationsaufwand
- Vorschlag von Brooks: Planung basierend auf sequentiellen Teilschritten mit jeweils voneinander unabhängigen Teilaufgaben
  - Personalgröße ergibt sich aus der Anzahl jeweils unabhängiger Teilaufgaben
  - Zeitaufwand ergibt sich aus der längsten Kette von sequentiellen Teilschritten
  - Parallele zum Gantt-Diagramm, dass zu Brooks' Zeit bekannt gewesen sein sollte

Kapitel 3: Das OP-Team ("The Surgical Team")

Beobachtung: sehr weite Spannbreite im Produktivitätsspektrum der Software-Entwickler; die besten sind 10x so produktiv wie die schlechtesten
- Xyrill war überrascht, dass diese Beobachtung schon so alt ist; in den 2010ern gab es einen Hype darum und man hat die produktivsten Entwickler als "Rock Stars" gehandelt
- naive Schlussfolgerung: statt einem großen Team lieber ein kleines Team der absolut Besten
  - kleine Teams kommunizieren ja auch besser, also weniger Overhead
- Problem: skaliert irgendwann nicht mehr
  - 10 Leute können nicht z.B. ein modernes Betriebssystem bauen (vielleicht als Programm, aber definitiv nicht als fortlaufend gewartetes Programmsystemprodukt)
Alternativvorschlag: Teamstruktur analog zu Operations-Teams in der Chirurgie
- ein Spezialist in der Mitte, der die Schnitte macht
- viele Unterstützer drumherum, die die Werkzeuge anreichen und Instrumente überwachen
genaue Rollenverteilung in diesem Vorschlag
- Chirurg/Chefprogrammierer: erarbeitet die Design-Spezifikation und schreibt Programm, Dokumentation und Tests
- Copilot: berät den Chirurgen in allen Design- und Implementations-Entscheidungen; fungiert als Stellvertreter des Chirurgen
- Administrator: kümmert sich für den Chirugen um alle administrativen Aufgaben (Geldmittel, Personal, Räumlichkeiten, Inventar); bei kleineren Teams teilen sich evtl. mehrere Teams einen Administrator
- Editor: bringt die vom Chirurgen ins Unreine geschriebene oder diktierte Dokumentation in Reinform
- außerdem werden Sekretariatsrollen beschrieben; z.B. ein Schreiber, der Code auf Lochkarten bringt und Programmausgaben sammelt und archiviert
- weitere Randrollen, die von mehreren Teams geteilt werden können: Werkzeugmacher, Tester, Language Lawyer (jemand, der die jeweilige Programmiersprache in- und auswendig kennt und hochspezialisierte Optimierungen oder besonders leichtgängige Strukturen finden kann)
großer Fokus auf den unterstützenden Sekretärs- und Schreiberrollen, um den Chirurgen und Copilot von Schreibarbeiten zu entlasten
- Xyrill stellt sich das heute schwierig vor; Digitalisierung hat zwar viele Schreibarbeiten vereinfacht, aber auf eine Art und Weise, die das Delegieren schwierig macht
- hier könnte der Kern liegen, warum verschiedene Leute so unterschiedlich starken Nutzen aus LLMs ziehen
Skalierungsfrage ist hierdurch vereinfacht: ein Projekt mit 2000 Mitarbeitern kann damit in 200 Zehnerteams geteilt werden, sodass nur die 200 Chirurgen miteinander reden müssen
- aber nicht gelöst: 200 Chirurgen können immer noch ganz schön viel Kakophonie erzeugen

STP067: Linux auf dem Desktop

Thu, 23 Jan 2025 19:35:00 GMT

Endlich ist die Hardware geliefert und montiert; Zeit, der Elektronik Leben einzuhauchen. Was könnte da besser passen als die Linux-Distribution der Wahl.

Shownotes

Wir haben Feedback bekommen, siehe unten. Zuerst die Shownotes zum eigentlichen Thema:

Rückbezüge: STP065/066, Gamespodcast
Unterschiede zu Windows und macOS
- Pro: keine Werbung, kein Tracking, keine nervtötenden Virenscanner oder Abzockereien (achtung Ubuntu)
  - im Gespräch erwähnt: OOBE\BYPASSNRO, Debloating-Tool für Windows
- Pro: nicht der Enshittification durch Microsoft und Apple ausgesetzt (siehe: warum Steam Linux unterstützt)
- Pro: Langlebigkeit (siehe Xyrills Schiff des Theseus)
- Pro: unendliche Variabilität -> Distributionen (vgl. distrowatch.com, /r/UnixPorn)
- Contra: unendliche Variablität :) -> neben verschiedenen Distributionen zum Beispiel auch verschiedene Desktop-Umgebungen usw.
Wie wählt man eine Distribution?
- Empfehlung für den ersten Kontakt: z.B. Linux Mint
- evtl. je nach speziellen Anforderungen: z.B. für Gaming RegataOS
- als Live-System ausprobieren (unter Windows braucht man dafür einen leeren USB-Stick und Rufus oder Ventoy)
- als VM unter Windows ausprobieren (VirtualBox)
- für weiteren Überblick: auf YouTube nach Distro-Vorstellungen suchen

Feedback I

Auf dem Kongress gab es eine Postkarte.

Feedback II zu STP066

für deutschsprachige Kaufberatung zu PC-Hardware wurde https://forum.worldofplayers.de/forum/forums/504-Kaufberatung empfohlen
Xyrill hat 80 PLUS falsch erklärt: es geht dort um einen Wirkungsgrad über 80% bei Lasten von 20/50/100%

STP066: Desktop-PC basteln, Teil 2

Thu, 02 Jan 2025 13:35:00 GMT

Nachdem es sich als eine gute Entscheidung erwiesen hat, die ursprünglich geplante Episode zu teilen, geht es heute nun konkreter um die Auswahl der Komponenten und deren Montage in den Selbstbau-PC.

Shownotes

fortgesetzt aus STP065: Wie wählt man Komponenten so, dass alles zusammenpasst?
- CPU wählen (Intel oder AMD; übertaktbar oder nicht; Boxed-Lüfter oder Aftermarket-Kühlung, etc.)
- Mainboard wählen (passend zum CPU-Sockel und dem benötigten Chipsatz; im gewünschten Formfaktor, z.B. ATX vs. Mini-ITX; mit gewünschten Funktionen, z.B. WLAN oder Toslink-Audio oder viele USB-Steckplätze)
- RAM wählen (passend zum RAM-Sockel auf dem Mainboard und den unterstützten RAM-Frequenzen)
- GPU wählen (relativ unabhängig von den vorherigen Schritten)
- SSD/HDD wählen (unabhängig von den vorherigen Schritten außer: Mainboard muss genügend Steckplätze für NVMe bzw. SATA haben)
- Gehäuse wählen (GPU und Mainboard muss passen, bei großen CPUs mit extravaganten Lüftern muss auch die Lüfterhöhe passen)
- Netzteil wählen (TDP von allen bisher genannten Sachen aufsummieren -> Netzteil so wählen, dass bei Volllast 80% verwendet werden)
- je nach Prioritätensetzung kann auch eine andere Planungsreihenfolge sinnvoll sein (z.B. wenn man ein ganz bestimmtes Gehäuse füllen will)
Webempfehlungen:
- https://www.logicalincrements.com
- https://reddit.com/r/BuildAPC
- https://www.geizhals.de
- Mitternachtstarif bei Mindfactory :)
- gerade neu: Systembuilding-Guide von Ars Technica für 2024
Wie baut man es zusammen?
- Werkzeug: PH1/PH2-Schraubendreher, evtl. Wärmeleitpaste (beim Boxed-Kühler schon voraufgetragen), evtl. Kabelbinder
- allgemeine Arbeitsplatzregeln: Zeit nehmen, genügend Platz, gute Beleuchtung
- für die Zusammenbaureihenfolge dem Handbuch zum Gehäuse folgen (allgemein: Gehäuse -> Netzteil -> Mainboard -> CPU -> RAM -> Lüfter -> SSD/HDD -> GPU)
- Platinen nur an den Kanten anfassen, nicht auf die Leiterbahnen patschen
- Steckverbindungen sollten immer ohne Gewalt funktionieren
weitere Empfehlungen
- Spiralschlauch zum Organisieren der Kabel sowohl innerhalb als auch außerhalb des Gehäuses
- zum Reinigen: Staubsauger und Pinsel, Druckluftdose (bitte ohne Treibmittel)

STP065: Desktop-PC basteln

Wed, 11 Dec 2024 23:00:00 GMT

Da wir hier ja alle stilechte Nerds sind, gehört auch der Bau des eigenen PC zu den Standardaufgaben. Wie wir das anfangen, darum soll es diesmal gehen.

Shownotes

Warum sollte man das tun wollen?
- Gründe für den PC im Allgemeinen
  - mehr Leistung als ein Notebook
  - vielseitiger als eine Spielekonsole
  - ortsfester als ein Smartphone (kann man z.B. im Arbeitszimmer zurücklassen, um von der Arbeit Abstand zu gewinnen)
- Gründe für den Selbstbau-PC im Speziellen
  - spezifische Anforderungen (z.B. besonders leistungsstark, besonders leise, besonders kompakt)
  - Nachhaltigkeit (Austauschen einzelner Komponenten möglich -> Schiff des Theseus)
  - konsistente Qualität (bei Fertig-PCs oft ein, zwei tolle Komponenten und der Rest Billigschrott)
Wie stellt man die Einkaufsliste zusammen?
- Schritt 1: Welche Komponenten brauche ich grundsätzlich?
  - auf jeden Fall: CPU, Mainboard, RAM, SSD, Gehäuse, Netzteil
  - nach Bedarf: dedizierte GPU (sonst CPU mit integrierter GPU), HDD, zusätzliche Lüfter und/oder Wasserkühlung (Bilder)
  - wenn noch nicht vorhanden: Tastatur, Maus, Monitor(e), Lautsprecher bzw. Kopfhörer, Webcam
- Schritt 2: Passt alles zusammen?
  - das und noch mehr beim nächsten Mal

STP064: Cursed Computer Iceberg Meme, Runde 2

Thu, 21 Nov 2024 21:15:00 GMT

Heute geht es ein weiteres Mal um Eisberge und Memes. Entweder ttimeless ist gut aufgelegt oder diese Dinge sind nur mit Humor zu ertragen… oder beides.

Shownotes

Wir setzen unsere Betrachtung des Cursed Computer Iceberg Meme aus STP042 fort. Das letzte Mal waren wir bis "Below the Water" gekommen. Xyrill hat aber noch ein paar Sachen in den oberen Ebenen gesehen, die besprechenswert sind.

"Above the Iceberg" - Oberhalb des Eisberges
- Little Bobby Tables: das Mem-Beispiel einer SQL-Injektion; dieses wiederum eine klassische Art von Sicherheitslücken (siehe STP049)
"On the Iceberg" - Auf dem Eisberg
- Quine: ein Programm, dass seinen eigenen Programmcode ausdruckt (Beispiele siehe Link)
  - siehe auch: quine-relay
- Intel Management Engine
"Below the Water" - Unterhalb der Wasserlinie
- rm -rf "$STEAM_ROOT"/*: wie eine einzige uninitialisierte Variable unzählige Computer außer Gefecht setzt (heutzutage würde man sagen, diese Computer wurden ge-crowdstriket)
- "lp0 on fire": heute eher ein Mem als alles andere, aber wie im Artikel beschrieben gab es früher Drucker mit Heizelementen, die bei Papierstau in Flammen aufgingen (und trotzdem weiter Papier nachschoben); Xyrill fühlt sich an die Szene aus "Fantasia" mit den belebten Besen erinnert
- Illegale Zahlen: eine konkrete Art, wie Redefreiheit in der Praxis durch Urheberrecht etc. eingeschränkt werden kann
  - siehe auch "Welche Farbe haben deine Bits?"
  - Economics of everyday things - Happy birthday to you
- Kaltstartattacke: ein sehr handfester Seitenkanalangriff
  - Es gibt auch die Möglichkeit, RAM einzufrieren, damit darin enthaltene Schlüssel forensisch ausgelesen werden können.
  - Manchmal sieht man auch Hausdurchsuchungen, bei denen die Polizei eine USV und Werkzeug zum Kabelspleißen mitbringt.
"Middle of the Iceberg" - Mitte des Eisbergs
- 42.zip: gepackt nur 42 KiB; "beim Entpacken wächst das Datenvolumen allerdings um das Hundertmilliardenfache auf [4 PiB]"
  - Rückbezug zu Quines: Zip Files All The Way Down
- "OpenOffice kann dienstags nicht drucken": ein legendärer Fehlerbericht, fast so gut wie die 500-Meilen-Mail aus STP042
"Bottom of the Iceberg" - Unterseite des Eisbergs
- "You fool. You absolute, unmitigated, unadulterated, complete and utter, fool.": Manöverkritik zum Keypair-Spam-Angriff auf das GPG-Keyserver-Netzwerk (GPG hatten wir bereits am Rande in STP048 erwähnt)

Es gibt noch jede Menge im tiefen Wasser. Wir sehen uns wieder in STP084.

STP063: Fleißige Biber

Thu, 31 Oct 2024 11:55:00 GMT

Wie auch schon in der Vergangenheit nehmen wir es mit der Aktualität unserer "Berichterstattung" nicht ganz so genau. Und so liegt das entsprechende Ereignis etwa 2¹/₂ Monate in der Vergangenheit. Der fünfte fleißige Biber wurde gefunden.

Shownotes

Wir haben Feedback bekommen, siehe unten. Zuerst die Shownotes zum eigentlichen Thema:

aktueller Anlass: Der fünfte fleißige Biber wurde gefunden
- Rückbezug zu STP000: theoretische Informatik ist ein Teilgebiet der Mathematik, dass Xyrill lieber "Berechnungstheorie" nennen würde
- hierin insbesondere "Berechenbarkeitstheorie": Welche Probleme lassen sich mit Rechenmaschinen lösen?
- Church-Turing-These: Berechenbarkeit ist eine intrinsische Eigenschaft eines Problems und nicht abhängig davon, welchen Computer ich zur Lösung einsetze
  - "Die Klasse der Turing-berechenbaren Funktionen stimmt mit der Klasse der intuitiv berechenbaren Funktionen überein."
- Analyse der Berechenbarkeit eines Problems anhand von einfachen Modellmaschinen, z.B. der Turing-Maschine (daher "Turing-berechenbar")
- Turing-Vollständigkeit: die Eigenschaft einer Rechenmaschine, alle Probleme lösen zu können, die auch eine Turing-Maschine lösen kann (mal abgesehen von weltlichen Einschränkungen wie Speicherplatz und Rechenzeit)
- Rückbezug zu STP021 (Reguläre Ausdrücke): dort hatten wir stärker limitierte Maschinenmodelle erwähnt (endliche Zustandsautomaten, Kellerautomaten)
Aufbau einer Turing-Maschine (Beispielbild aus Wikipedia)
- unendlich langes Speicherband mit Feldern, auf denen entweder 0 oder 1 stehen kann
- Lese-/Schreibkopf, der das aktuelle Feld lesen und schreiben kann sowie sich in Einzelschritten entlang des Bandes bewegen kann
- Programm: endliche Menge von Zuständen, und eine Zustandsübergangsfunktion, die auf Basis der gelesenen Zeichen entscheidet und Zeichen überschreibt sowie den Lesekopf bewegt
- Xyrill hat ein Beispiel mitgebracht: ein Programm, dass zwei positive Ganzzahlen subtrahiert; die Zahlen sind als Folgen von 1 gegeben, getrennt von einer 0; zum Beispiel "3-2" wird eingegeben als "111011" und der Lesekopf startet am Anfang der ersten Zahl
- Warnung: Wir haben während der Aufzeichnung bemerkt, dass diese Maschine inkorrekt ist. Damit keine Verwirrung entsteht, haben wir die Notizen nicht angepasst.
Zustandsvorrat (durchbuchstabiert in der Reihenfolge der Benutzung, Startzustand ist A):
- A: suche nach rechts in der ersten Zahl
- B: suche nach rechts in der zweiten Zahl
- C: auf dem Ende der zweiten Zahl
- D: suche nach links in der zweiten Zahl
- E: suche nach links nach der ersten Zahl
Übergangstabelle:
- Zustand A, lese 0 -> schreibe 0, gehe nach rechts, neuer Zustand B
- Zustand A, lese 1 -> schreibe 1, gehe nach rechts, neuer Zustand A
- Zustand B, lese 0 -> schreibe 0, gehe nach links, neuer Zustand C
- Zustand B, lese 1 -> schreibe 1, gehe nach rechts, neuer Zustand B
- Zustand C, lese 0 -> schreibe 0, gehe nach links, neuer Zustand HALT
- Zustand C, lese 1 -> schreibe 0, gehe nach links, neuer Zustand D
- Zustand D, lese 0 -> schreibe 0, gehe nach links, neuer Zustand E
- Zustand D, lese 1 -> schreibe 1, gehe nach links, neuer Zustand D
- Zustand E, lese 0 -> schreibe 0, gehe nach links, neuer Zustand E
- Zustand E, lese 1 -> schreibe 0, gehe nach rechts, neuer Zustand A

Beispielausführung für die Aufgabe "3-2"

... 0 [1] 1  1  0  1  1  0 ... Zustand A
... 0  1 [1] 1  0  1  1  0 ... Zustand A
... 0  1  1 [1] 0  1  1  0 ... Zustand A
... 0  1  1  1 [0] 1  1  0 ... Zustand A
... 0  1  1  1  0 [1] 1  0 ... Zustand B
... 0  1  1  1  0  1 [1] 0 ... Zustand B
... 0  1  1  1  0  1  1 [0]... Zustand B
... 0  1  1  1  0  1 [1] 0 ... Zustand C
... 0  1  1  1  0 [1] 0  0 ... Zustand D
... 0  1  1  1 [0] 1  0  0 ... Zustand D
... 0  1  1 [1] 0  1  0  0 ... Zustand E
... 0  1  1  0 [0] 1  0  0 ... Zustand A
... 0  1  1  0  0 [1] 0  0 ... Zustand B
... 0  1  1  0  0  1 [0] 0 ... Zustand B
... 0  1  1  0  0 [1] 0  0 ... Zustand C
... 0  1  1  0 [0] 0  0  0 ... Zustand D
... 0  1  1 [0] 0  0  0  0 ... Zustand E
... 0  1 [1] 0  0  0  0  0 ... Zustand E
... 0  1  0 [0] 0  0  0  0 ... Zustand A
... 0  1  0  0 [0] 0  0  0 ... Zustand B
... 0  1  0 [0] 0  0  0  0 ... Zustand C
... 0  1 [0] 0  0  0  0  0 ... Zustand HALT

Anmerkungen hierzu
- man kann Turing-Maschinen auch auf viele andere Weisen modellieren, etwa mit größeren Zeichensatz (z.B. alle Dezimalziffern sowie mathematische Symbole, um eine Eingabe wie 127*(3+6/2) zu ermöglichen) oder mehreren Bändern; an der Berechenbarkeit ändert das nichts
- Xyrill belässt es bei obigem Beispiel, dass noch einigermaßen kompakt ist
- Übungsaufgabe: Füge weitere Zustände ein, mit denen der Lesekopf am Ende in die Startposition zurückbewegt wird.
- Aber was ist jetzt mit den Bibern?
N-ter fleißiger Biber: diejenige Turingmaschine mit N Zuständen, die auf ein initial leeres Band (alles voller Nullen) die meistmöglichen Einsen schreiben kann, bevor sie anhält
- Die Haltebedingung ist wichtig! Sonst können wir mit nur einem Zustand unendlich viele Einsen schreiben ("Zustand A, lese irgendwas -> schreibe 1, gehe nach rechts, neuer Zustand A")
- Problem: Man kann einer Turingmaschine nicht ohne weiteres ansehen, ob sie terminiert oder nicht. -> Das Halteproblem ist eines der klassischen unberechenbaren Probleme.
- Jetzt gefunden wurde BB(5,2) = 47176870; sprich: Der längstmögliche endliche Lauf einer Turingmaschine mit 5 Zuständen und 2 Zeichen auf initial leerem Band ist 47176870 Schritte. (Das ist die gleiche Maschinengröße wie unser Beispiel oben.)
- Bei der Gelegenheit erwähnen wir auch mal die OEIS. Die fleißigen Biber sind zum Beispiel A060843.

Feedback zu STP038

laalsaas schreibt:

In Minute 32 spricht xyrill von 1,6 Terabit und sagt, dass wären 1,6 Millionen Bit. Ich nehme an, dass es sich hierbei um einen Versprecher im Eifer des Gefechts handelt, sind doch 1 Terabit eine Billion Bit.

Anmerkung: Im Englischen sogar "a trillion bit". :)

Etwas früher ging es um USB und darum, dass man den Stecker nie beim ersten Versuch richtig herum reinbekommt. Dazu möchte ich hier einen „Lifehack“ teilen. Ich hoffe, es gelingt mir, ihn in Textform verständlich zu beschreiben. Ein USB-Stecker ist meist folgendermaßen aufgebaut: Wenn man von vorne daraufguckt, ist der äußere Rand ein rechteckig gebogenes Metallblech. Innen ist eine Hälfte des Rechtecks eine Plastik-„Zunge“, auf der die Kontakte sitzen, in der anderen Hälfte ist Luft. Eine USB-Buchse wiederum besteht aus einem Rechteck, in dem die Hälfte ebenfalls aus einer „Zunge” besteht, die andere aus Luft. Damit nun ein Stecker in die Buchse passt, müssen sich die „Zungen“ gegenüberliegen, damit sie die Luft in der jeweils anderen Komponente ausfüllen. Nun ist es so, dass bei über 90% der horizontal fest verbauten USB-buchsen in Laptops, PCs, usw die „Zunge“ oben ist. Das heißt, man muss einfach die „Zunge“ des USB-steckers nach unten orientieren. Wer immer noch zu faul ist, jedes mal frontal auf seinen USB-Stecker draufzugucken, der sei darauf hingewiesen, dass man auch einfach herausfinden kann, auf welcher Seite die Zunge ist, indem man durch die seitlichen Löcher im Blech des USB-Steckers schaut und darauf achtet, ob da direkt Plastik ist (Zungenseite, die muss nach unten) oder erst etwas Luft und dann Kontakte, wenn man das sieht, hält man den Stecker richtig herum. Seitdem ich diesen Trick kenne, habe ich wesentlich weniger Probleme damit, USB-Stecker richtigherum reinzustecken. Das funktioniert natürlich nicht bei freifliegenden Hubs und auch bei seitlich oder „nach unten“ montierten Buchsen habe ich noch keine Konvention erkennen können, das kann aber auch daran liegen, dass ich zu selten mit denen zu tun habe. Ich hoffe trotzdem, dass ich manchem mit diesem Trick das Leben einfacher machen konnte :)

Zu guter Letzt möchte ich noch anmerken, dass die in Minute 39 von timeless gewählte Formulierung „Der LaTeX-Bruder“ eine (vermutlich ungewollte) Doppelbödigkeit hat. Erfahrene STP-Hörer wissen natürlich, dass es sich hier um Xyrills Bruder handelt, der seine Abschlussarbeit in LaTeX geschrieben hat, aber ich finde, es klingt auch so, wie ein Mitglied des LaTeX-Klosters oder der LaTeX-Sekte, was mich sehr zum Schmunzeln gebracht hat.

Noch mehr Feedback

Weiterhin schreibt Matthias:

Statt Postkarte: Liebe Hörergrüße aus dem Urlaub in Allgäu sendet Matthias.

Anbei ein Bild eines Gedenksteins für Konrad Zuse.

STP062: Selfhosting

Thu, 10 Oct 2024 17:35:00 GMT

Nachdem unser aller Heimnetzwerk voll funktionsfähig ist, wollen wir nun von daheim aus die ganze Welt mit unseren Online-Diensten beglücken... oder zumindest bestimmte Dinge selbst an den Start rollen.

Shownotes

Rückbezug STP061: wir haben unser Heimnetzwerk von Schicht 1 bis 3 aufgebaut
- Schicht 3 hatte uns einen Zustellweg durchs Internet gegeben
- Schicht 4 ergänzt Sitzungsverwaltung (z.B. Flusskontrolle und Fehlerkorrektur; hierfür siehe STP005) und Ports
- Warum braucht man Ports? Gedankenexperiment:
  - Annahme: Datenpakete werden nur anhand von Quelladresse und Zieladresse zugestellt
  - Situation: zwei Prozesse auf demselben PC wollen mit wikipedia.de reden
  - Abschicken der Anfragen klappt eventuell noch, da gleiches Ziel
  - Problem: Antwortpaket kommt -> Welcher Prozess kriegt das Paket?
  - Technisch formuliert: Wie kann man über diese Netzwerkleitung mehrere unabhängige Verbindungen multiplexen?
Ports: Identifikationsnummer für offene Netzwerkverbindungen; 16 Bit groß (0-65535)
- vgl. Briefkästen/Wohnungsnummern in Mehrparteienhäusern
- Datenpakete auf Schicht 4 werden anhand der Gesamtheit aus Quelladresse, Quellport, Zieladresse, Zielport einer Verbindung zugeordnet
- damit eindeutige Endzustellung an einen Prozess möglich
- auf Server-Seite im Allgemeinen "wohlbekannte" Ports (z.B. 25 für SMTP, 80 für HTTP, 443 für HTTPS), damit Clients ein definiertes Ziel für neue Verbindungen haben
- auf Client-Seite für gewöhnlich automatisch vergebene Ports (meist zwischen 32768-65535)
- Praxisbeispiel: im Browser eine Webseite aufmachen, dann in der Konsole aktive Verbindungen auflisten mit ss -utpn -o state connected
Wie kann ich zuhause einen Server-Prozess betreiben?
- Außenwelt muss meine IP-Adresse finden können und den entsprechenden Port erreichen können
- Problem 1: IP-Adresse wird durch den Internetanbieter bestimmt und ändert sich -> Dynamisches DNS (nicht zu verwechseln mit der Firma "DynDNS", die nur ein möglicher Anbieter ist)
- Problem 2: Router hat für gewöhnlich einen Paketfilter (Firewall), der nur ausgehende sowie bekannte Verbindungen durchlässt -> Ausnahmeregel ("Port Opening") muss konfiguriert werden; je nach Betriebssystem auch dasselbe auf dem Server selbst erforderlich
- Problem 3: IPv4 mit NAT, lokaler Rechner mit Server-Prozess hat nur eine lokale IP-Adresse -> Portweiterleitung muss konfiguriert werden (damit dann meist auch eine Ausnahmeregel in der Firewall verbunden)
Was kann ich zuhause betreiben?
- E-Mail definitiv nicht, MTAs aus Endkunden-IP-Bereichen werden von den großen Betreibern als Spam-Schleudern interpretiert und blockiert
- Videotelefonie auch eher nicht, weil da NAT-Durchdringung noch problematischer ist
- Faustregel: fast alles mit HTTP sollte gehen, sofern man nicht durch den oft dünnen Upstream von Endkunden-Internetanschlüssen begrenzt ist
- Xyrill betreibt (teils zuhause, teils auf gemieteten Servern im Rechenzentrum): Gitea, Jitsi Meet, Matrix, NextCloud, nginx (siehe STP022), Prometheus (siehe STP032)
- andere Vorschläge: Bitwarden, Kodi, Mastodon oder andere ActivityPub-Server (siehe STP057), Paperless-NGX, Pi-Hole
im Gespräch erwähnt
- Pentaradio zu Quellcode-Verwaltung mit Git: https://c3d2.de/news/pentaradio24-20210727.html
- Audio-Streaming-Software: https://www.navidrome.org/

STP061: Heimnetzwerk

Thu, 19 Sep 2024 19:10:00 GMT

In dieser Episode soll es etwas detaillierter um die unteren Schichten im Netzwerkstapel gehen. Außerdem: ttimeless fordert biologische Lösungen für Verknöcherungsprobleme und Xyrill räumt mit falschen Werbeversprechen auf.

Shownotes

Rückbezug: STP005 (Netzwerk-Schichtenmodell)
- seither haben wir über die unteren Schichten des Netzwerks nicht allzu viel gesprochen, sondern eher über Anwendungen darauf (siehe STP018 zu DNS, STP022 zu dem Web, STP052/STP054 zu TLS, STP057 zu ActivityPub/Mastodon)
- heute mal wieder mehr die Infrastruktursicht (Layer 1 bis 4), vor allem aus praktischer Endanwendersicht
Layer 1/2 kabelgebunden: über achtadrige Twisted-Pair-Kabel mit üblicherweise vorkonfektionierten RJ45-Steckern (8P8C) nach IEEE 802.3 "Ethernet"
- Twisted Pair: Kabel mit verdrillten Doppeladern und einer (je nach Kategorie) zunehmenden Menge an Abschirmungen, damit das Kabel nicht z.B. unbeabsichtigt zur Antenne wird :) – Wikipedia hat eine schöne Visualisierung, wie besser geschirmte Kabel für mehr Bandbreite sorgen
- vorkonfektionierte Stecker: man kann auch selber konfektionieren (sprich: Kabel auf die richtige Länge zuschneiden und Modularstecker anbringen)
- im Rechenzentrum findet man auch Ethernet, aber oberhalb der 10 Gbit/s dann nur noch auf Basis von Glasfasern und SFP-Modulen
- Kabel alleine reichen nicht, man braucht mindestens noch einen Switch, um tatsächlich ein Kabelnetzwerk zu erhalten
- der Switch ist oft auch ein Router, der das lokale Kabelnetzwerk mit dem Internet verbindet
- Wir empfehlen: Beim Hausbau oder -umbau am besten gleich Cat7 verlegen (oder zumindest Leerrohre), damit man sich nicht mit WLAN-Signalstärken rumärgern muss.
  - im Gespräch erwähnt: Keystone-Modul
Layer 1/2 kabellos: über Radiowellen im 2,4-GHz-Band oder im 5-GHz-Band nach IEEE 802.11 "WLAN bzw. Wi-Fi"
- was bei Ethernet der Switch, ist bei WLAN der Access Point (AP)
- übliches Setup zuhause: der zentrale Router macht sowohl LAN (Ethernet) als auch WLAN
- Xyrills Setup: ein Server agiert als Router, aber macht nur LAN; am LAN hängt ein WLAN-AP (kein WLAN-Router, somit nur ein lokales Netz für alle Endgeräte)
Layer 3 mit IPv4 (1981)
- auf dem Router läuft mindestens ein DHCP-Server, um die lokalen Adressen zu vergeben; oft auch ein DNS-Resolver (siehe STP018)
- an und für sich sind Netzwerke ineinander verschachtelt, z.B. kann ein Netzwerk 10.11.0.0/16 ein Teilnetzwerk 10.11.12.0/24 enthalten (Analogie: Telefonanlage in einem Firmengebäude mit Verbindung ins weite Telefonnetz); damit fast beliebig feine Unterteilungen des Netzwerks möglich
- Problem: insgesamt etwa 4,3 Mrd. unterschiedliche IP-Adressen, aber davon nur etwa 3,7 Mrd. "weltweit gültige" Adressen
- in der Praxis sehr viel NAT: ein Heimnetzwerk kriegt nur eine IP-Adresse für den Router; innerhalb des lokalen Netzwerkes private Adressen (z.B. 192.168.x.y), die nicht direkt aus dem Internet erreichbar sind
Layer 3 mit IPv6 (1998)
- IPv6-Adressen haben sehr viel mehr Ziffern und sind damit extrem viel zahlreicher, aber auch unhandlicher
- noch sehr viele andere Unterschiede zu IPv4, die mit dazu führten, dass sich IPv6 nur sehr langsam verbreitet hat bzw. immer noch verbreitet
- Endanwender kriegen bei IPv6 nicht nur einzelne Adressen, sondern wie ursprünglich vorgesehen ganze Netze, die ihr Router frei verwalten kann
- statt DHCP meist nur SLAAC (Stateless Address Auto-Configuration; zustandslose Adressen-Autokonfiguration): Router teilt den Netzwerkbereich mit und Endgeräte würfeln selbsttätig gültige Adressen
- Umfangreichere Infos im RFC-Podcast zu IPv6
- Problem: Wenn jedes Gerät vom Computer bis zur smarten Glühbirne eine global eindeutige IPv6-Adresse hat, ist das nicht ein Traum für jeden Überwachungskapitalisten?
Layer 3 mit VPN (Virtual Private Network)
- Idee: Netzwerkverkehr ist zumindest auf Layer 2 und darüber auch nur Bits und Bytes; die kann man als Nutzdaten behandeln und in eine andere Netzwerkverbindung zu einem VPN-Server einpacken (meist auch mit Verschlüsselung drumherum, z.B. TLS)
- Xyrills Setup: ein Server im Rechenzentrum fungiert als VPN-Server, mit dem Xyrills Endgeräte alle verbunden sind; aus Sicht der Endgeräte sind alle im selben lokalen Netzwerk; damit auch z.B. vom Notebook von unterwegs "direkter" Zugriff auf den Heimserver möglich (trotz NAT im Plaste-Router)
- das häufigere Setup beim Endanwender: aller Datenverkehr nach außen geht durch einen VPN-Tunnel und erst ab dem Server des VPN-Anbieters weiter ins weite Internet
- tatsächlicher Nutzen: es sieht so aus, als ob man in einer anderen geografischen Region sitzt, was z.B. für Streaming-Dienste relevant sein kann (aber Vorsicht: das verstößt oft gegen die Geschäftsbedingungen des Streamers; das hier ist keine Rechtsberatung)
- fragwürdiger Nutzen: man muss nicht mehr dem Internetanbieter vertrauen, dass der nicht den eigenen Datenverkehr mitliest (Problem 1: in Zeiten von allgegenwärtigem TLS sieht der ISP sowieso nur die Domain-Namen und IP-Adressen, nicht die Inhalte; Problem 2: man verschiebt die Vertrauensfrage nur vom Internetanbieter zum VPN-Anbieter)
Layer 4 bis 7 dann beim nächsten Mal

STP060: Praxisbeispiel: Datenauswertung auf der Kommandozeile

Thu, 29 Aug 2024 17:34:06 GMT

Nachdem die beiden sich gegenseitig ihr Leid geklagt haben, geht es dann doch noch um Technik. Oder eher um deren Anwendung. Diesmal wieder mit einer Hands-on-Folge, denn es ist wichtig, vor Kunden und bei Präsentationen einen professionellen Eindruck zu machen.

Shownotes

Rückblick: STP006 "Kommandozeilen und Unixphilosophie"
- ttimeless hat gerade eine Gelegenheit, Daten zu analysieren, an der man das praktische Vorgehen mit Kommandozeilen-Werkzeugen gut demonstrieren kann
- Ausgangssituation: Klimasensor-Datenlogger in verschiedenen Räumen messen einmal pro Minute Temperatur und Luftfeuchtigkeit
- mitgelieferte Software bietet eine rudimentäre Visualisierung sowie einen Datenexport als CSV
- die hier besprochenen CSV-Dateien können zum Nachvollziehen heruntergeladen werden
- Ziel: eigene Datenvisualisierung mit gnuplot
erste Sichtprüfung: <Balkon.csv head
- acht Kopfzeilen mit Metadaten und Auswertungen (Berichtszeitraum, Maximum/Minimum/Durchschnitt)
- diesen Header brauchen wir nicht, wir wollen die Rohdaten
- Option 1: sofern immer acht Zeilen, z.B. tail -n +9 oder sed 1,8d
- Option 2: Suchmuster auf den Zeileninhalt der letzten Kopfzeile, z.B. sed 1,/^Aufnahmezeit/d
- Option 3: nur Zeilen auswählen, die nach Daten aussehen, z.B. grep '^"[0-9]'
Kopfzeilen entfernt: <Balkon.csv sed 1,8d
- nächstes Problem: die Anführungszeichen um die einzelnen Werte werden gnuplot verwirren -> würden wir mit tr -d \" wegbekommen
- Problem: dann wären die Dezimalkommas nicht von den wertetrennenden Kommas zu unterscheiden
- unsere Lösung: während wir Anführungszeichen entfernen, werden dazwischenliegende Kommas gleichzeitig durch ein anderes Trennzeichen (hier einen Tabulator) ersetzt -> sed 's/^"//; s/","/\t/g; s/"\s*$//'
- hierin ist Trickserei erforderlich, weil die erzeugten Dateien Windows-Zeilenenden haben (CR+LF), nicht Unix-Zeilenenden (nur LF) -> könnte man auch vorher mit dos2unix beheben, dann ist statt s/"\s*$// nur s/"$// erforderlich
- Alternative (erfordert csvkit): csvformat -d , -q \" -U 3 -D $'\t'
Anführungszeichen entfernt: <Balkon.csv sed 1,8d | sed 's/^"//; s/","/\t/g; s/"\s*$//' >Balkon.dat
- zu Xyrills Überraschung ist das schon ausreichend, den Rest können wir in gnuplot machen

Anzeige in gnuplot: das untenstehende Programm als Balkon.gp abspeichern, gnuplot aufrufen und load 'Balkon.gp' eingeben)

set xdata time
set timefmt '%d-%m-%Y %H:%M:%S'
set format x '%d.%m.%Y %H:%M:%S'
set decimalsign ','
set datafile separator "\t"
set ylabel "Temperatur °C"
set y2label "Luftfeuchte %"
set y2tics
plot 'Balkon.dat' using 1:2 title 'Temperatur' with lines axes x1y1, 'Balkon.dat' using 1:3 title 'Luftfeuchtigkeit' with lines axes x1y2

Für die Ausgabe in eine Datei können noch diese beiden Zeilen vorangestellt werden:
```
set terminal svg background "white" dashed size 1920,1080
set output "Balkon.svg"
```
Was, wenn gnuplot nicht so clever wäre?
- Dezimaltrennzeichen von Komma in Punkt ändern: <Balkon.dat tr , .
- Datumsformat in ISO ändern: <Balkon.dat awk -F'\t' '{ split($1, DATE, /[^0-9]*/); $1 = DATE[3] "-" DATE[2] "-" DATE[1] "T" DATE[4] ":" DATE[5] ":" DATE[6] "Z"; print }'
- Xyrill hatte auch geschaut, wie man die Zeitangaben in date -d bekommen könnte, um sie damit umzuwandeln, und wurde von einem wunderschönen Zitat begrüßt (nachfolgende deutsche Übersetzung mittels DeepL):
  
  Unsere zeitlichen Maßeinheiten, von Sekunden bis hin zu Monaten, sind so kompliziert, asymmetrisch und disjunkt, dass ein kohärentes mentales Rechnen in der Zeit nahezu unmöglich ist. In der Tat, hätte sich ein tyrannischer Gott ausgedacht, unseren Geist an die Zeit zu versklaven, um es uns nahezu unmöglich zu machen, der Unterwerfung unter durchweichte Routinen und unangenehme Überraschungen zu entkommen, hätte er kaum etwas Besseres tun können, als uns unser gegenwärtiges System zu überliefern. Es ist wie ein Satz trapezförmiger Bauklötze, ohne vertikale oder horizontale Flächen, wie eine Sprache, in der der einfachste Gedanke verschnörkelte Konstruktionen, nutzlose Partikel und langatmige Umschreibungen erfordert. Im Gegensatz zu den erfolgreicheren Mustern der Sprache und der Wissenschaft, die es uns ermöglichen, Eindrücken kühn oder zumindest nüchtern zu begegnen, fördert unser System der zeitlichen Berechnung stillschweigend und beharrlich unseren Terror vor der Zeit.
  
  ... Es ist, als ob Architekten die Länge in Fuß, die Breite in Metern und die Höhe in Ellen messen müssten; als ob grundlegende Bedienungsanleitungen die Kenntnis von fünf verschiedenen Sprachen erfordern würden. Kein Wunder also, dass wir in unsere eigene unmittelbare Vergangenheit oder Zukunft, auf den letzten Dienstag oder den Sonntag in einer Woche, oft mit einem Gefühl hilfloser Verwirrung blicken. ...
im Gespräch erwähnt: ASCII-Folge von Request for Comments

STP059: Nebenläufigkeit

Thu, 08 Aug 2024 20:30:00 GMT

Nachdem es in STP015 (Multitasking) bereits um die nacheinanderfolgende Verteilung von Resourcen an verschiedene Prozesse ging, kommt heute echtes "gleichzeitig Arbeiten" dran.

Shownotes

Rückbezug und Abgrenzung zu STP015 (Multitasking in Betriebssystemen)
- Definition von Nebenläufigkeit: "in der Informatik die Eigenschaft eines Systems, mehrere Aufgaben, Berechnungen, Anweisungen oder Befehle gleichzeitig ausführen zu können"
- Definition von Multitasking: "die Fähigkeit eines Betriebssystems, mehrere Aufgaben [...] (quasi-)nebenläufig auszuführen"
- eins definiert das andere \o/ -> wir schauen auf den Begriffsgebrauch in der Praxis
- Multitasking: die funktionale Umsetzung einer Multiprozess-Architektur in Hardware und Software (auf Betriebssystem-Ebene)
- Nebenläufigkeit: die Ertüchtigung von Userspace-Programmen zur Ausnutzung dieser Möglichkeiten unter Wahrung des korrekten Verhaltens
Grundproblem: Wie vermeidet man Konflikte und Verwirrung beim Umgang mit geteilten Ressourcen?
- "Ressource" bedeutet vor allem: Speicherstellen, Dateisystem-Einträge (Dateien und Verzeichnisse), Geräte, (Aufmerksamkeit der Benutzerin)
- explizit nicht Zeit; darum kümmert sich bereits die Multitasking-Unterstützung des Betriebssystems
Race: eine Situation, bei der das Ergebnis (und insbesondere die Korrektheit) mehrerer nebenläufiger Prozesse davon abhängt, in welcher Reihenfolge die einzelnen Rechenschritte verschiedener Prozesse zufälligerweise ausgeführt werden
- allgemein bekannt als Race Condition (Wettlaufsituation) oder beim Speicherzugriff insbesondere Data Race
- Beispielsituation: im Arbeitsspeicher liegt ein Zähler mit aktuellem Wert 40; zwei Prozesse A und B wollen diesen Zähler gleichzeitig um 1 erhöhen -> erwarteter Endwert 42
- Problem: "Zahl im Arbeitsspeicher verändern" ist nicht, wie Speicherzugriff in CPUs funktioniert (siehe STP007); tatsächlich sind jeweils drei Schritte erforderlich (Einlesen in CPU-Register, Erhöhen um 1, Zurückschreiben in den RAM)
- möglicher Ausgang: beide Prozesse laufen auf verschiedenen CPUs, lesen gleichzeitig den Wert 40 in ihre CPU-Register, erhöhen gleichzeitig auf 41, schreiben dies zurück -> Ergebnis 41 statt 42
- "auf verschiedenen CPUs" ist hier nicht erforderlich: z.B. A liest ein und erhöht, wird unterbrochen, B liest ein und erhöht, B schreibt zurück, wird unterbrochen, A schreibt zurück
- "zwei Prozesse" ist auch nicht erforderlich: Prozesse können auch in Threads (parallele Ausführungsstränge) unterteilt sein, die nebenläufig Code ausführen, aber ansonsten fast alle Ressourcen (Speicherseiten, offene Dateien, etc.) teilen
wir brauchen ein Mutex: einen Mechanismus zum wechselseitigen Ausschluss ("Mutual Exclusion")
- Problem: Wie implementiert man sowas?
Idee: bevor wir den Zähler anfassen, fragen wir bei einem zentralen Prozess nach einer Sperre für diesen Zähler an; dieser Prozess vermerkt Sperr- und Entsperrvorgänge in seinem internen Speicher
- dieser Kontrollprozess könnte auch einfach ein Teil des Betriebssystems sein und der Sperr-/Entsperrvorgang ein Syscall (siehe STP019)
- Vorteil: innerhalb dieses Kontrollprozesses keine Nebenläufigkeit und damit keine Gefahr eines Data Race
- Nachteil: Interprozess-Kommunikation ist vergleichsweise grauenhaft langsam (Millisekunden vs. Mikrosekunden)
Idee: in der kritischen Region (von Auslesen des Zählers bis Zurückschreiben) verbieten wir dem Betriebssystem, unseren Prozess zu unterbrechen
- Problem 1: hilft nur bei nebenläufigen Prozessen auf demselben CPU-Kern
- Problem 2: immer noch ein teurer Syscall
- Problem 3: böswillige Prozesse könnten einfach ihre gesamte Laufzeit als kritische Region markieren und die Rechenzeit blockieren
praktische Umsetzung von Mutexen mittels Atomics: spezielle CPU-Instruktionen, die nicht unterbrochen werden können
- Beispiel für Mutex: "Fetch and Add" liest einen Wert aus dem Speicher aus, erhöht ihn um das Argument, und schreibt den erhöhten Wert zurück
- schneller als ein Kontextwechsel zu einem Kontrollprozess oder ein Syscall
- langsamer als ein normaler Speicherzugriff, da eventuell Caches ignoriert oder aktiv geleert werden müssen
- in der Praxis evtl. Kombination mit Syscalls, um bei blockiertem Mutex den Prozess zu unterbrechen (z.B. unter Linux das "Fast Userspace Mutex" bzw. Futex)
andere Perspektive, hier zitiert aus der Programmiersprache Go: "Do not communicate by sharing memory; instead, share memory by communicating."
- statt Zugriffssicherungen für geteilten Speicher dort eher Nutzung von "Kanälen" (Channels) zur Nachrichtenübermittlung zwischen Threads
- Beispiel "Worker Pool": mehrere gleichartige und voneinander unabhängige Teilaufgaben sind abzuarbeiten (z.B. 100 Bilder in ein anderes Dateiformat umwandeln)
- Idee: ein Worker (Arbeits-Prozess oder Arbeits-Thread) pro CPU-Kern; außerdem ein zentraler Prozess, der die Aufgaben verteilt; Zentrale stellt alle Dateinamen in einen Kanal, Arbeiter greifen nacheinander aus dem Kanal die Dateinamen heraus
- unter der Haube nutzt der Kanal Atomics, um sich vor Data Races zu schützen
- Rückbezug zu STP027: sobald man mehrere Threads untereinander koordinieren muss, hat man das ganze Problemfeld "Verteilte Systeme", was nach Xyrills Erfahrung nochmal wesentlich nerviger ist als Data Races
Abendgedanken: Amdahl'sches Gesetz
- mehr CPU-Kerne machen nur Dinge schneller, die wahrhaft nebenläufig sind

STP058: Identifier

Thu, 18 Jul 2024 21:40:00 GMT

Da die Zeiten von Karteikarten in Büros und auf Ämtern ~~zum Glück~~ leider vorbei sind, braucht es nun andere Wege, um Personen zu identifizieren. Doch nicht nur störende Kundschaft will wiedererkannt werden...

Shownotes

Wir haben einiges an Feedback bekommen, siehe Ende der Shownotes. Zuerst zum eigentlichen Thema:

Identifier (ID): eindeutiges Kennzeichen zur Unterscheidung gleichartiger Objekte oder Individuen
- während des Softwaredesign (z.B. beim Entwurf des Datenbankschemas): Entscheidung darüber, welche Identifier für welche Kategorien von Objekten verwendet werden
Identifier für Menschen: Falsehoods Programmers Believe About Names
- bei deutschen Behörden üblich: das Tupel aus Name und Geburtsdatum und evtl. Geburtsort -> immer noch nicht ganz eindeutig
- bei Benutzerkonten im wesentlichen drei Optionen:
  - fortlaufende Nummern (Vorteile: im Speicher kompakt darstellbar, robustes Pseudonym; Nachteile: leakt das Alter des Kontos, rare kurze Nummern vermitteln Status), siehe z.B. ICQ-Kontonummern (frühe 2000er)
  - frei wählbare Benutzernamen (Vorteile: eingängig, Pseudonymität möglich; Nachteile: belohnt frühe Registrierung, fördert Name-Squatting)
  - E-Mail-Adressen (Vorteile: enthält implizit eine Kontaktmöglichkeit, wird seltener vergessen als eine Nummer oder ein frei wählbarer Name; Nachteile: muss vertraulich behandelt werden, beim Wechsel der Mail-Adresse evtl. Neuanmeldung erforderlich)
auch bei Objekten oder Datenstrukturen eine gute Option: fortlaufende Nummern
- im deutschen Handelsrecht bei Rechnungen sogar in gewissem Rahmen rechtlich vorgeschrieben
- Vorteil: Hochzählen ist trivial umzusetzen
- Vorteil: kompakte Darstellung im Speicher (z.B. nur 4 Byte bei einer Gesamtzahl unter 4 Mrd. Objekte) -> insb. wichtig bei Kreuzreferenzen
- Nachteil: ab und zu hat man doch mehr Objekte als erwartet und muss mühselig auf größere Zahlen umstellen (z.B. bei über 4 Mrd. Objekten von 32-Bit-Zahlen auf 64-Bit-Zahlen) -> Beispiel bei der Schachwebseite chess.com
- Nachteil: in verteilten Systemen (siehe STP027) braucht man eine zentrale ID-Vergabestelle oder einen aufwändigen Konsensalgorithmus -> Geht das besser?
Universally Unique Identifier (UUID) gemäß RFC 4122
- Idee: mit dem Schritt von 64 Bit auf 128 Bit so viele mögliche Werte, dass man z.B. bei zufälliger Wahl eine absurd geringe Kollisionswahrscheinlichkeit hat
- Darstellung in Text meistens als Hexadezimalzahl in Gruppen von 8, 4, 4, 4 und 12 Stellen; Beispiel: 8b4b72a2-55dd-4ab7-b239-bb9caad9107a
- mehrere verschiedene Formate: heutzutage am häufigsten UUIDv4 (mit rein zufälligen Zahlen, außer dass die 13. Hexadezimalstelle die Formatzahl "4" enthält)
- Vorteil: in verteilten Systemen keine Koordination bei der Vergabe erforderlich
- Nachteil: etwas weniger kompakt, insb. wenn die UUID wie oft üblich als Text abgespeichert wird
- Nachteil insb. bei UUIDv4: keine sinnvolle Sortierung -> Alternativvorschläge wie UUIDv7 oder ULID stellen eine sortierbar kodierte Form des Erstellungszeitstempels voran
Content-Addressed Storage (CAS): Bezeichnung eines Datenstroms durch seine kryptografische Prüfsumme (siehe STP004)
- z.B. Identifikation dieses Bildes nicht durch einen Dateinamen/Pfad/URL wie https://dl.xyrillian.de/noises/stp-038-intro.png, sondern durch die Prüfsumme sha256:e68ae45acddfab6198c01ba552ca9f1b76e78bc12c4a4ca0476da27d688d8238
- Bildung von Datenstrukturen (z.B. Ordner oder Lesezeichenlisten) durch Benutzung dieser Prüfsummen-IDs analog zu Inode-Nummern (siehe STP031)
- möglicherweise noch menschenlesbare Identifier, die auf CAS-Identifier abbilden (z.B. in Git: Tags als menschenlesbare Namen für Commits)
- Vorteil: bei sorgfältigem Design selbsttätige Deduplikation und Integritätsprüfung möglich
- Nachteil: Prüfsummen sind nochmal deutlich sperriger als UUIDs
zur Bezeichnung von Software-Versionen: Versionsnummern
- konventionelles Format: Zahlen mit Punkten getrennt (z.B. 1.7.10), sortiert leider nicht lexikografisch (z.B. "1.7.10" > "1.10.7")
- kein fester Formatstandard, aber es gibt Ansätze: z.B. Semantic Versioning
- Alternativschema: jahreszahlbasiert (z.B. Ubuntu 24.06 ist die im Juni 2024 veröffentlichte Version) -> Bemerkung von ttimeless: kann man auch mit Dateien machen (z.B. 2024-03-01-ticket-bahn.pdf)
- Alternativschema: das Marketing bestimmt (z.B. XBox -> XBox 360 -> XBox One -> XBox Series X/S)
- Alternativschema: Konvergenz (die Versionsnummer von TeX nähert sich der Zahl π an) -> bräuchten wir vielleicht mehr davon :)

Feedback zu STP049

Till schreibt:

Hallo Xyrill,

dies bezieht sich auf Schlüsseltechnologie #49 bzw auf die darin erwähnten Farb-Begriffe.

Rot vs blau kommt ursprünglich vom Militär, ich selbst kenn es von den Pfadfindern, damals bei Sommerlagern und/oder Geländespielen. Um ein bisschen Spannung in das Lagerleben zu kriegen (wovon es unter 200 pubertierenden Jünglingen offenbar nicht genug gab), wurden wir in zwei Unterlager aufgeteilt, die in Wettbewerb gingen. Am letzten Abend wurden die Sieger nach Punkten verkündet, hurra. Bei Geländespielen wurde oft eine Burg definiert, gehalten von Blau und attackiert von Rot. Hier die Ursprünge: $LINK

Xyrill ersetzt hiermit den bereitgestellten Link auf einen Personalagentur-Blog durch den ausführlicheren Wikipedia-Artikel.

Die schwarzen und weißen Hüte kommen aus der Urform des Westernfilms, in der die guten Jungs immer weiße Hüte trugen und die Schurken schwarze. Zuletzt sehr pointiert in der ersten Staffel von "Westworld", die ich außerordentlich stark empfehlen möchte. (Steht bei euch popkulturell ignoranten Cyberspezls immer im Schatten von "Black Mirror".) https://en.wikipedia.org/wiki/Black_and_white_hat_symbolism_in_film

re: Wurm - Wiki sagt, die Bezeichnung gehe zurück auf einen SF-Roman

Schlapphüte (Farbe des Huts zweitrangig) sind geheimdienstlich aktive Personen. Vorkommen: ausschließlich in journalistisch schlampigen Kontexten. Das ist eine dieser Dummphrasen für alle Schreiber, die in Deutsch gelernt haben, dass man sich schöne Synonyme ausdenken soll, damit der Text eleganter wird. Wird er nicht, im Gegenteil fettet er zu, aber das ist wie nem Ochs ins Horn gepetzt. https://de.wikipedia.org/wiki/Schlapphut#Sonstiges

Wo wir grade dabei sind, off-topic mein Lieblings-Hassobjekt: "soziale Medien". Nichts an diesen Plattformen ist sozial, Medien sind sie auch nicht, sondern deren Inhalt. Wie meistens bei Übersetzungen im Cyberbereich war die erstübersetzende Person des Englischen nicht mächtig und hat uns für immer mit einem False Friend gestraft. Das originale "social media" hat zwar ein ebenfalls dubioses Medium, aber der Begriff "social" bedeutet in diesem Fall "gesellig": Let's go socialising! (dt. "Gehn wir einen saufen"). Entsprechend sind die sozialen Medien in Wirklichkeit Geselligkeitsplattformen. Nörgel nörgel.

Warum die doofen Trojaner sich ein Hottepferdchen voll waffenstarrender Griechen in die Stadt holten, schildert Stephen Fry in seiner sehr lesenswerten Ilias-Nacherzählung "Troy": Erstens war das Pferd ein exquisites Stück Handwerkskunst, zweitens war es überzogen mit Gold und Silber und Edelsteinen, drittens stand es unter dem Schutz einer mächtigen Göttin, Stichwort Laokoon, vor allem aber ergänzten diese verschlagenen Griechen das Pferd mit einem False-Flag-Helfershelfer, der alle Zweifel (und Cassandras Verzweiflungsschreie) beiseite wischte. Die Operation wäre einer Leningrader Trollfabrik würdig.

Stuxnet: https://darknetdiaries.com/episode/29/

Wenn wir schon Podcasts zu Stuxnet verlinken, erhöht Xyrill um ein Alternativlos und möchte sehen.

Feedback zu STP057

Klaus schlägt per Mail einen anderen Namen für Matrix/Mastodon-Server vor:

Hallo Xyrill!

Wie wär's mit 'Meldestelle' oder 'Anmeldedienst' oder etwas in der Art.

Wenn man irgendwo neu hinzieht, muss man sich doch auch registrieren.

Das ist hier nicht anders, schließlich ist man neu auf den entsprechenden Diensten.

Gibt ja jede Menge Meldestellen in Deutschland, so auch im Fediverse, nur dass im Fediverse nicht vorgeschrieben wird, welche man zu nehmen hat.

In der Regel interagiert man ja auch nicht notwendigerweise mit den Leuten, die sich bei der gleichen Meldestelle angemeldet habe.

Grüße aus Belgien!

Mehr Feedback zu STP057

Jan schreibt:

Hallo Xyrill und ttimeless,

da ihr in der letzten Folge zu ActivityPub wiederholt nach Feedback gefragt habt, gebe ich doch auch gerne meinen Senf dazu!

Ich denke das Wort, das Xyrill bei 00:14:53 sucht ist Galionsfigur. Wikipedia nennt im Deutschen Artikel von Figurehead auch "Frühstücksdirektor".

Das war eigentlich schon alles was ich schreiben wollte. Ich danke euch vielmals für diesen tollen Podcast und freue mich alle drei Wochen(!) über eine neue Folge.

Xyrill merkt hierzu an, dass er nicht mehr wirklich GPG verwendet und das Entschlüsseln dieser Mail ein Abenteuer war.

Cold Call

Xyrill hat eine Mail bekommen:

Hallo Herr Majewsky,

Das sieht schon nicht gut aus.

ich möchte Ihnen gerne einen spannenden Gast für Ihren Podcast vorschlagen

Haben wir ja grundsätzlich nichts dagegen. Ladet Euch bitte ein, wenn Ihr ein Thema mitbringen möchtet, zu dem Ihr was sagen könnt.

Mit freundlichen Grüßen, $NAME

Communications Executive $PR_AGENTUR

Aber wenn Ihr Eure PR-Agentur vorschickt, dann gehe ich davon aus, dass es sich hier um Native Advertising handelt. Nicht nur mag ich das nicht, sondern vielleicht denkt dann das Finanzamt noch, dass hier Gewinnabsicht bestünde.

STP057: ActivityPub

Thu, 27 Jun 2024 17:25:00 GMT

Wieder einmal ein von langer Hand vorbereitetes Thema. Hier kulminiert der Inhalt der beiden vorangegangenen Folgen zu einem Blick in den Maschinenraum von z.B. Mastodon. Außerdem sprechen wir ein weiteres Mal über unseren persönlichen Blick und Umgang mit diesem Thema.

Shownotes

Klaus schreibt per Mail:

Hallo timeless und Xyrill,

bin Anfang des Jahres irgendwo auf euren Podcast gestoßen und dort eingestiegen, wo ihr damals gerade wart, Folge 49 Schadcode und dann die weiteren.

Diese haben mir so gut gefallen, dass ich alle Folgen mit Antennapod abgeholt habe und dabei bin euren Podcast von hinten aufzurollen.

Großes Kompliment an Euch! Phantastische Serie! Freue mich auf jede neue und für mich neue-alte Folge.

Bin zwar vom Fach, aber lerne immer was Neues oder andere Blickwinkel kennen. HERRLICH!

Eine kleine Bemerkung von mir zu den Folgen 13 und 14, Textkodierung und Textdarstellung.

Ich bevorzuge so wie Xyrill auch die Verwendung von kombinierenden diakritischen Zeichen.

Die meisten der für mich nützlichen davon (u.a. für DE, FR, NL, CN-Pinyin) beginnen an der Hex-Adresse U+0300 ff.

Leicht zu merken und praktisch, wenn man ständig mit anderen Tastaturbelegungen zu tun hat.

Worauf ich aber hinaus möchte, ist folgendes:

Diese diakritischen Zeichen werden sowohl am Schirm als auch im Druck gleich dargestellt, obwohl ihnen andere Byte-Folgen zugrunde liegen. Hat Xyrill alles beschrieben. Hab ja zugehört. Für Textprogramme, etc. ist das kein Problem, in Datenbanken aber schon.

Es macht dann leider doch einen gravierenden Unterschied, ob diakritische Zeichen wie en "ä" aus U+00E4 oder aus der Kombination von U+0061 + U+0308 entstehen.

Tastaturen, die diese Zeichen direkt kodieren, verwenden nur die Version mit 1 Codepunkt.

Bei Längenbestimmungen von Zeichenketten ergeben sich Unterschiede. Die Zeichenketten sehen gleich aus, sind aber nicht gleich lang, obwohl sie auch gleich lang aussehen!

Eingabeformulare fangen das nicht immer gut ab. Gleich aussehender Begriff, aber doch nicht derselbe.

Idem bei Suchanfragen.

etc.

Ich empfehle daher immer in Datenbanken Strings so zu standardisieren, dass nur die Version mit 1 Codepunkt verwendet wird, so wie eben Muttersprachler diesen Text auf ihrer sprachspezifischen Tastatur eingeben würden.

Viele Grüße aus Belgien!

Klaus

Nun zum eigentlichen Thema:

Ausgangssituation
- Soziale Medien: "digitale Medien bzw. Plattformen, die es Nutzern ermöglichen, sich im Internet zu vernetzen, [...] untereinander auszutauschen und mediale Inhalte einzeln, in einer definierten Gemeinschaft oder offen in der Gesellschaft zu erstellen, zu diskutieren und weiterzugeben"
- aber: alles zentralisiert (siehe STP056) und nicht interoperabel (siehe STP055)
- ActivityPub: der zurzeit wahrscheinlich aussichtsreichste Versuch, soziale Medien dezentral zu modellieren
- erste Anfänge in den frühen 2010ern mit Activity Streams 1.0, dann in 2016-2018 Entwicklung von Activity Streams 2.0 und darauf aufbauend ActivityPub
- Xyrill sieht zwei wesentliche Design-Einflüsse im ActivityPub-Protokoll
Einfluss: REST (Representational State Transfer)
- HTTP kennt man allgemein als Protokoll zum Abruf von Webseiten (siehe STP002)
- neben GET gibt es in HTTP-Anfragen aber noch viele andere Verben
- POST: Ursprung in HTML für Abschicken ausgefüllter Formulare
- PUT, PATCH, DELETE etc.: für Hochladen und Verwalten von Dateien
- REST: Modellierung von APIs unter Einsatz dieser HTTP-Verben und unter Modellierung der Datensätze entlang von URLs (z.B. in einem Webshop PATCH /products/23, um Produkt Nr. 23 zu bearbeiten; oder in einem Blog GET /articles/hello-world/comments, um die Kommentare zu dem Post namens "Hello World" aufzurufen)
Einfluss: E-Mail
- entworfen in einer Zeit, als die meisten Verknüpfungen im Internet nicht durchgehend verfügbar waren
- Mails werden nicht sofort an den Empfänger zugestellt, sondern landen erstmal auf dem Mail-Server des Absenders in einer Outbox (analog dem Postbriefkasten)
- Zustellung an den jeweils nächsten Server in der Kette bei Verfügbarkeit der Leitung (heutzutage unverzüglich und immer direkt an den Zielserver), dann Ablage in der Inbox des Empfängers (analog dem Hausbriefkasten)
- Problem bei ActivityPub: E-Mail ist Unicast (Nachrichten gehen immer an eine bestimmte Adresse bzw. eine bestimmte Liste von Adressen), aber soziale Medien können auch Broadcast sein (z.B. Tweets oder Blogposts sind global sichtbar)
ActivityPub: Inbox und Outbox wie bei E-Mail, aber bidirektional
- Direktnachricht von Alice an Bob: Alice postet in ihre eigene Outbox, Server leitet weiter in Bobs Inbox, Bob ruft aus seiner Inbox ab
- öffentliche Nachricht von Alice: Alice postet in ihre eigene Outbox, Bob ruft aus Alices Outbox ab; bei Followern sendet Alices Server in deren Inbox
- Nachrichten verbleiben bis zu ihrer eventuellen Löschung in der Outbox und bilden einen Feed aller Nachrichten dieser Person
- REST-Einfluss: Inbox erlaubt GET durch den Inhaber und POST durch andere Server, Outbox erlaubt POST durch den Inhaber und GET durch alle
- vgl. Bilder in Kapitel 1 der ActivityPub-Spezifikation
- wesentliche Implementationen von ActivityPub: Kurznachrichtendienst Mastodon, Linkaggregator Lemmy, Bildplattform Pixelfed, Videoplattform PeerTube
- Anekdote: Xyrill hatte überlegt, die Podcast-Seite mit ActivityPub auszustatten, und ist davon wieder abgekommen
Beobachtung bzw. Rückbezug zu STP056: föderierte Netzwerke haben einen starken Drang zur (Re-)Zentralisierung
- Anschauungsbeispiel: Verteilung der Nutzerzahlen zwischen verschiedenen ActivityPub-Implementationen -> Mastodon macht 99% der Nutzerbasis aus
- innerhalb von Mastodon initial starke Konzentration bei mastodon.social; seit einiger Zeit ist beim Anlegen eines Nutzerkontos kein Server mehr voreingestellt
- vgl. auch Matrix: schätzungsweise etwa 50% der Nutzer bei matrix.org
- absolut subjektiver Eindruck: Mastodon-Entwickler dominieren die Weiterentwicklung von ActivityPub als ganzes
Vergleich mit dem AT-Protokoll von BlueSky
- Motivation: Trennung des Zustellpfades von "dem Algorithmus" (Inhaltsvorschläge und Moderation), um letztere austauschbar zu gestalten
- modulare/dezentrale Moderation (mit den daraus folgenden Konsequenzen, z.B. öffentlich einsehbare Blocklisten, also kein Shadowbanning möglich)
  - vgl. ActivityPub: Faustregel: 1 Moderator:in pro 1000 User
- Konten bei AT sind nicht an bestimmte Server gebunden, sondern können unter Erhalt der gesamten Kommunikationshistorie umgezogen werden (ActivityPub-Adressen sind mehr wie Kontonummern oder E-Mail-Adressen; AT-Identifier sind mehr wie portierbare Telefonnummern)
  - vgl. Debatte über die Begrifflichkeit "Server" vs. "Instanz" vs. "Community" bei Mastodon
  - Update: ActivityPub arbeitet an "nomadischer Identität" analog zu den Decentralized Identifiers in AT
im Gespräch erwähnt: Entwurf einer Änderung der Gemeinsamen Geschäftsordnung der Bundesministerien (GGO) zur Umsetzung der Vorhaben "Exekutiver Fußabdruck" und "Synopse"

STP056: Zentralisierung

Thu, 06 Jun 2024 19:20:00 GMT

In dieser Episode werden die Kerntatsachen zum Sachverhalt der Zentralisierung in geradezu essayistischer Form herausgearbeitet und dargestellt, um der Hörerin eine Urteilsbildung zu ermöglichen. Hierbei wird ein eigener Standpunkt zur Fragestellung gefunden und argumentativ abgeleitet.

Shownotes

RFC (Request for Comments): eine Publikationsreihe für zumeist technische Spezifikationen, aber auch Essays betreffend die Fortentwicklung der Internet-Infrastruktur
- bereits besprochen in STP035 anhand der Tradition der Aprilscherz-RFCs
- im Übrigen auch eines der anschaulichsten Beispiele für die ursprüngliche Intention von Hypertext: RFCs sind blanke Textdateien, die für die Darstellung als Webdokument automatisiert aufbereitet werden
- heute etwas ernster, aber hoffentlich ähnlich zugänglich anhand RFC 9518: "Centralization, Decentralization, and Internet Standards"
- wir folgen in unserer Besprechung des Themas der Struktur der Textgrundlage; deutschsprachige Zitate sind jeweils aus dem Englischen übersetzt
Kernbegriff: "Zentralisierung [im Sinne dieses Dokumentes] ist eine Sachlage, bei der eine einzelne Entität oder eine kleine Gruppe eine Funktion des Internets überwachen, abfangen, kontrollieren oder aus ihrem Betrieb oder ihrer Benutzung Pacht ziehen kann."
- Die ersten drei Varianten (Überwachung, Abfangen, Kontrolle) sind die intuitiv klaren Formen von Zentralisierung (z.B. das Telefon-Festnetz ist zentralisiert, da es von einem einzigen Anbieter, der Telekom, betrieben und kontrolliert wird).
- Der Teil mit "Pacht" ist im Original "rent extraction", was im Englischen ein durchaus geläufiger Begriff ist, während im Deutschen der "Rentier" wahrscheinlich eher für einen Rentner gehalten wird.
  - en.wiktionary.org zu "rent" im Sinne "rent extraction": "A profit from possession of a valuable right, as a restricted license to engage in a trade or business." – "Profit aus dem Besitz eines wertvollen Rechtes, als limitierte Lizenz zum Betrieb eines Handwerks oder Geschäftes"
  - klassische Beispiele außerhalb der IT: Taximedaillon, Notarstellen, natürliche Monopole wie Netzbetreiber von Strom-/Wasser-/Gasleitungen
  - Beispiel im Internet: App-Store-Betreiber (wer Software für iPhones vertreiben will, muss 30% Pacht an Apple abführen), IANA (Internet Assigned Numbers Authority) als Betreiber der DNS-Rootserver (zu DNS siehe STP018)
  - im Gespräch erwähnt: 5 Gründe, warum der Markt in der Praxis nicht so funktioniert wie in der Theorie
mögliche negative Konsequenzen von Zentralisierung
- Machtkonzentration (der RFC zitiert hier die Federalist Papers von 1788: "So wie [John Madison in denselben] Good Governance [(verantwortungsbewusste Regierungsführung)] der US-Staaten beschreibt, so erfordert Good Governance des Internets, dass Kontrolle über seine einzelnen Funktionen nicht ohne angemessene Gewaltenteilung an einer zentralen Stelle konsolidiert wird.")
- Begrenzung von Innovation: neue Entwicklungen brauchen Freiraum
  - im Gespräch erwähnt: Freak Show #274 zum App-Store-Monopol von Apple
- Begrenzung von Wettbewerb: Wettbewerb mehrerer kompatibler Anbieter oder mehrerer Protokolle schafft die vorgenannte Gewaltenteilung
- Verringerte Verfügbarkeit: Wenn alles durch einen zentralen Anbieter geht, führt ein Ausfall dort zu Folgeausfällen woanders.
  - Greifbares Beispiel: Was passiert, wenn ein Stadtviertel über eine zentrale Glasfaserleitung angebunden ist und diese Glasfaser versehentlich aufgebaggert wird?
  - Der RFC zitiert einige Beispiele.
  - Xyrill hat eine Anekdote zu AWS und Minecraft.
- Monokultur
- Selbstverstärkung
mögliche positive Konsequenzen von Zentralisierung
- Verständlichkeit, Zweckdienlichkeit
  - zentrale Steuerung von DNS verleiht Domain-Namen eine hilfreiche Universalität
  - z.B. bei IP-Adressen oder Telefonnummern ist derartig kontrollierte Universalität technisch notwendig
- Effizienz durch Skaleneffekte: siehe Besprechung von CDNs in STP024 (Cloud-Computing)
- Konzentration von Kontrolle kann Governance einfacher machen (was positiv sein kann, sofern man Governance an sich als grundsätzlich wünschenswert ansieht)
  - Beispiel: Bankenregulierung
- Xyrill fügt noch hinzu: Zentralisierung kann die Weiterentwicklung von Protokollen vereinfachen, sofern Ossifikation entgegengewirkt werden muss
  - Ossifikation: im Wortsinne "Verknöcherung", im übertragenen Sinne die faktische Unänderbarkeit von Protokollen, wenn eine Vielzahl von verschiedenen unabhängigen Akteuren die Änderung gleichzeitig vollziehen muss
Ansätze zur aktiven Dezentralisierung
- Föderation: verschiedene Anbieter betreiben voneinander unabhängige Instanzen, die miteinander in Kontakt treten, um einen insgesamten Dienst zu bilden (klassisches Beispiel: E-Mail)
  - alleine unzureichend, da nicht-technische Faktoren Zentralisierungsdruck erzeugen
  - Beispiel E-Mail: wer einen E-Mail-Server betreiben will, muss faktisch nach der Pfeife von Microsoft/Google/United Internet/etc. tanzen, da Outlook und G-Mail den Markt dominieren
  - Beispiel XMPP: nachdem einige wenige Betreiber in der Föderation groß geworden sind, haben sie sich vom föderierten Netz getrennt und ihre Nutzer effektiv eingesperrt (z.B. WhatsApp war früher XMPP-kompatibel)
- verteilter Konsens: Zusammenschluss aus vielen Teilnehmenden, bei denen die Ausübung von Macht innerhalb des Netzes zufällig und temporär zugewiesen wird (siehe Besprechung von Blockchain in STP048)
  - "Während diese Maßnahmen darin wirkungsvoll sein können, den Betrieb eines Dienstes zu dezentralisieren, können andere Aspekte seiner Vorhaltung weiterhin zentralisiert sein: zum Beispiel die Kontrolle über das Design, die gemeinsam genutzte Implementation, sowie die Dokumentation von Netzwerkprotokollen."
- aktives Regierungshandeln ("Operational Governance"): Ausübung der operativen Kontrolle durch eine neutrale Treuhänderstelle, die die Interessen der verschiedenen Diensteanbietern und Nutzenden gegeneinander abwägt
  - Einrichtung mitunter auch im Nachhinein möglich, sofern das technische, ökonomische oder politische Umfeld die Diensteanbieter zur Kooperation zwingt
  - klassische Beispiele: ICANN für IP-Adressen, IANA für DNS, CA/Browser-Forum für Wurzel-Zertifikatsautoritäten (siehe STP048)
Was können Autorinnen von Internet-Standards tun, um Zentralisierung vorzubeugen und Dezentralisierung zu fördern?
- Legitimität erzeugen
  - durch Öffentlichkeitsarbeit gegenüber der Bevölkerung oder gesellschaftlichen und staatlichen Institutionen Vertrauen schaffen, um dann die öffentliche Diskussion in die gewünschte Richtung zu beeinflussen
  - Problem: mehr Geld kauft mehr PR
- Diskussion fokussieren
  - nicht Zentralisierung als solches verteufeln (hat wie gesehen ja auch Vorteile), sondern explizit auf die Nachteile konzentrieren
  - konkreter Vorschlag: RFCs sollten neben den Standardabschnitten "Sicherheitsrelevante Überlegungen" und "IANA-relevante Überlegungen" immer auch "Zentralisierungsrelevante Überlegungen" explizieren
- Abzielen auf proprietäre Dienste
  - zentralisierte Angebote und Protokolle sollten aktiv mit offenen Standards konfrontiert werden
- Wechselkosten verringern
  - z.B. neue offene Standards so gestalten, dass sie mit bestehenden proprietären Diensten interoperabel sein können
  - selbst Open Source ist nicht immer die Lösung, wenn die Weiterentwicklung der Open-Source-Software die Expertise eines bestimmten Anbieters erfordert
- Delegation von Kontrolle bändigen
  - Wenn ein Protokoll der Nutzerin ermöglicht, Aufgaben an einen Dritten zu delegieren, kann das eine Sollbruchstelle zur Machtkonzentration sein.
  - Beispiel (im RFC erwähnt): HTTP-Proxies (ähnliches war auch bei HTTP auf der Internetanbieter-Ebene zu beobachten)
- starke Isolation durchsetzen
  - Beispiel: viele Protokolle hängen von der Verfügbarkeit und Zuverlässigkeit eines darunterliegenden Netzwerkes ab -> Verschlüsselung schützt gegen Machtkonzentration beim Betreiber dieser Basisschicht (schützt in diesem Beispiel nur vor Zentralisierung im Sinne von Überwachung, weniger im Sinne von Kontrolle)
- sorgfältige Abwägung von Erweiterbarkeit
  - hilfreich, um Wettbewerb und Innovation zwischen verschiedenen Anbietern zu fördern
  - aber auch Risiko des "Vendor Lock-In" (Erweiterung durch anbieterspezifische Funktionen, die Nutzerinnen an den Anbieter binden)
- wiederverwenden, was funktioniert
  - z.B. hat DNS trotz aller Probleme alles in allem ein relativ dezentrales Design und eine relativ gute Governance – tendenziell lieber darauf aufbauen, als eine eigene dezentrale Datenbank zu frickeln (oder s/DNS/Ethereum/, wenn man lieber Blockchain nehmen möchte)
Xyrills Abendgedanken: (De-)Zentralisierung ist, so wie fast alle Fragen aus dem Feld der Netzpolitik, nicht eine rein technische Frage und erfordert neben technischen auch soziale und gesetzliche Lösungen

STP055: Interoperabilität

Thu, 16 May 2024 15:00:00 GMT

"Together we stand, divided we fall." Deshalb geht es heute darum, wie Prozesse zur Zusmmenarbeit gebracht werden, oder auch, wie das gelegentlich schief geht. Zum Schluss haben wir wieder eine leicht schwermütige Unterhaltung darüber, warum die Dinge sind, wie sie sind. In diesem Sinne: "Let's work together..."

Shownotes

historischer Einstieg: initial nur einzelne monolithische Programme
- Computer startet, sobald das Programm eingegeben ist, zusammen mit dem Programm
- mehrere Programme möglich, aber diese alle komplett voneinander unabhängig; bzw. jeweils nur abhängig von der Maschine selbst
- dann wurden Programme so komplex, dass sie nicht mehr von einer Person verfasst werden konnten
- 1975: akademische Unterscheidung zwischen "Programming in the large" und "Programming in the small"
- Unterteilung der Software eines Computers in kleinere Einheiten erfordert definierte Schnittstellen
- Analogie: Unternehmen mit mehreren Mitarbeiterinnen erfordern meist definierte Abläufe
Schnittstellen auf der großen Ebene (zwischen Prozessen): Kommunikationsprotokolle und Datenformate
- Kommunikationsprotokolle: regeln Sende-/Empfangsreihenfolge, Inhalte der einzelnen Datenpakete und das durch sie ausgelöste Verhalten, Fehlerbehandlung etc.
- Datenformate: definieren die Struktur eines Datenpaketes; kann in einer Datei gespeichert sein; kann Teil eines Kommunikationsprotokolls sein; kann Baustein in einem größeren Datenformat sein (z.B. Videodatei besteht aus einem Audiodatenformat, einem Bildstromdatenformat und einem umschließenden Containerformat)
Schnittstellen auf der kleinen Ebene (innerhalb eines Prozesses): API (Application Programming Interface) und ABI (Application Binary Interface)
- z.B. eine Komponente, die einen Sortieralgorithmus bereitstellt, hat eine Schnittstelle, die eine Liste von Zahlen entgegennimmt und eine sortierte Liste von Zahlen zurückgibt
- dies ungefähr die geringste Ebene von Komplexität, Skala nach oben offen
- API: auf der Ebene von Programmcode
- ABI: auf der Ebene von Maschinencode
- Beispiel API: OpenGL vs. DirectX vs. Vulkan
- XKCD 927
Interoperabilität mit der Brechstange: Reverse Engineering
- siehe auch STP040 (§69e UrhG: Dekompilierung und Reverse Engineering sind unter bestimmten Umständen auch ohne Zustimmung des Urheberrechteinhabers erlaubt)
Interoperabilität mit etwas sanfterem Hebel: Emulation
- siehe auch STP023
siehe auch: Berufsbezeichnung Systemintegrator
- Unterdisziplin des Ausbildungsberufes "Fachinformatiker", in Abgrenzung zum Anwendungsentwickler
- Tätigkeitsschwerpunkt: Anpassung bestehender Systeme zum Zwecke der Interoperabilität
- vor allem im Umfeld von Firmensoftware verbreitet (Warenwirtschaftssystem des Herstellers A muss mit dem Buchhaltungssystem des Herstellers B verbunden werden)

STP054: TLS als Ganzes

Thu, 25 Apr 2024 19:00:00 GMT

Nach unserem kleinen Ausflug in fremdes Fach kehren wir heute zurück zu TLS. Dabei soll es diesmal mehr um einen Blick aufs Ganze gehen – und um die Identität der Entität.

Shownotes

Feedback per Mail:

Bei ca. 8 Minuten sagst du, das ein 64-Bit-Prozessor eine Adressbreite von 64 Bit hat, 32 Bit etc. analog. Das stimmt so nicht. Die Zahl gibt die Datenbreite an, nicht die Adressbreite (und damit auch die Registerbreite). Ein aktueller 64 Bit amd64 Prozessor kann max. 48 Bit adressieren (siehe /proc/cpuinfo, bzw. die Länge deiner Adressen in der maps Ausgabe). Der 286er konnte 20 bit Adressbreite, obwohl es ein 16-Bit-Prozessor war – Ich weiss nicht, ob du die Rumfummelei mit den Segmentregistern noch machen musstest. ;) Bei den 32-Bit-Prozessoren hat es übereingestimmt.

Ca 14 Minuten: Das Programm muss nicht komplett im Speicher liegen, sondern nur Teil, der abgearbeitet wird. Heute eventuell unüblich, aber früher war es durchaus so, das Programmteile während der Ausführung nachgeladen wurden und dann andere, gerade nicht benutzte Programmteile ersetzt haben.

Bei den 8-Bit-Spielekonsolen teilweise mit per Software umschaltbaren Speicherseiten des Game-ROMs, als z.B. das von einem 64k-ROM immer nur 16k-Blöcke für den Prozessor sichtbar waren (und die gleichen Adressen benutzt haben) und per IO-Befehl die Speicherseiten vom Programm gewechselt werden konnten, da ansonsten der Adressraum nicht ausgereicht hätte.

Stack: Soweit ich weiss, ist der Stack nicht wirklich hart beschränkt, sondern nur über das eingestellte ulimit. Bis zu diesem (änderbarem) Limit wird der dynamisch zur Laufzeit verwaltet und ggf. vergrößert.

Xyrill nimmt die Ausführungen wohlwollend zur Kenntnis, sieht sich jedoch nicht gezwungen, seine Position zu revidieren. Nun zum eigentlichen Thema:

Wo kriegt man Zertifikate her?
- Rückblick auf STP048: Zertifikate sind signiert von übergeordneten Zertifikaten (Zertifikatsautoritäten, CA), wodurch sich eine Kette bis hoch zu einem Wurzelzertifikat (Root-CA) aufbaut
- Clientzertifikate werden durch eine Stelle ausgegeben, der der Server vertraut (z.B. in Unternehmensnetzwerken eine CA unter der Obhut der Unternehmens-IT)
- für Serverzertifikate enthält der Browser bzw. das Betriebssystem eine Liste von vertrauenswürdigen Root-CAs -> Wie kann man eine Root-CA werden?
CA/Browser Forum
- Verein von Browser-Herstellern und Root-CA-Betreibern zur Selbstregulierung der Anforderungen an Browser und Root-CAs
- Root-CAs, die gegen die entsprechenden Sicherheits- und Transparenzregeln verstoßen, wird von den Browsern das Vertrauen entzogen, was deren Geschäftsgrundlage entzieht (siehe z.B. diese tolle lange Liste von Vorfällen mit Symantec-CAs, die Mozilla dokumentiert hat)
eine sehr bekannte Root-CA: ISRG (Internet Security Research Group) unter dem Markennamen Let's Encrypt
- Situation vor 2013: TLS-Zertifikate kosten Geld und werden im Prinzip nur von Firmenwebseiten gekauft (Teufelskreis: teuer -> kleine Kundschaft -> keine Skaleneffekte -> teuer)
- 2013: Snowden-Enthüllungen (Pentaradio berichtete neulich über das 10-jährige Jubiläum) -> Erkenntnis: wir brauchen mehr Verschlüsselung im Internet
- 2015: ISRG bietet mit Let's Encrypt automatisierbare und kostenlose TLS-Zertifikate für Jedermann
Was tun nach einem IT-Angriff, wenn ein Server-Zertifikat kompromittiert wurde?
- Zertifikate können der CA als gestohlen gemeldet werden
- Online Certificate Status Protocol (OCSP): Protokoll für die Abfrage von Rückzugsanzeigen (dem digitalen Äquivalent von Diebstahlsmeldungen)
- Probleme: wenn das die Clients machen, überlastet es die kleinen CAs und die großen CAs könnten damit wunderbar #Datenspuren sammeln
- OCSP-Stapling ("OCSP-Tackern"): der Server lässt sich alle paar Minuten per OCSP bescheinigen, dass das eigene Zertifikat noch nicht zurückgezogen wurde, und tackert das an alle TLS-Handshakes ran
Angriffe auf TLS
- grundsätzlich alle Angriffe auf einzelne Primitiven sowie die Interaktion bestimmter Primitiven miteinander im Rahmen von TLS -> das geht uns zu sehr ins Detail, ist aber einer der Hauptgründe für die fortwährende Weiterentwicklung des Protokolls
- Implementierungsfehler (z.B. Heartbleed, siehe STP037)
- Downgrade-Angriffe: Kryptoagilität ausnutzen, um die anderen Teilnehmer zu einer weniger starken Verschlüsselung zu überreden; z.B. auch durch Machine-in-the-Middle (MITM), weswegen die Verschlüsselung schon der allerersten Handshake-Schritte so wichtig ist
- Export-Downgrade: Spezialform des Downgrade-Angriffs, der die anderen Teilnehmer auf eine extrem schwache Exportverschlüsselung herunterzieht (bewusst schwache Verschlüsselungen aus der Zeit vor dem Wassenaar-Abkommen, als starke Verschlüsselung noch als exportlimitierte Militärtechnik eingestuft war)

STP053: Lieber was mit Holz

Thu, 04 Apr 2024 20:05:00 GMT

Diesmal hat Xyrill kein Bock mehr auf den Computermist und ttimeless erzählt stattdessen etwas über die ehrliche Arbeit des Handwerkers. Oder zumindest einiger Handwerker.

Shownotes

Gewerksabgrenzung
- Drechsler: Holzgewerk, Kunsthandwerk: Stellt Drehteile aus Holz, Kunststoffen, Bein, Elfenbein, Horn, … her
- Holzbildhauer: stellt Skulpturen aus Holz sowie Verzierungen an hölzernen Bauelementen oder Einrichtungsgegenständen her
- Zimmerer: Holzgewerk, Bauberuf (Bauhauptgewerbe); stellt Bauwerksteile her, z.B. Dachkonstruktionen, Rohbauten (Fachwerk, Holzrahmenbau, Blockbauweise, …), Balkone, Innenausbau (Böden, Treppen, Holzdecken, Wandverkleidungen), …
- Stellmacher/Wagner: Holzgewerk; stellt Räder, Wagen, landwirtschaftliche Geräte, … her
- Tischler/Schreiner: "… Handwerk, welches sich auf die schneidende, fügende oder veredelnde Verarbeitung von Holz und Holzwerkstoffen spezialisiert hat." Stellt Bauelemente (Fenster, Türen, …), Möbel, Innenausbauten (Böden, Treppen, Holzdecken, Wandverkleidungen wie Lambris, …), … her.
- Die Abspaltung der Tischler vom Zimmererberuf wurde ab dem 14. Jahrhundert durch Bildung von Zünften vorangetrieben.
- Siehe hierzu auch Liste der Handwerksberufe: Holzhandwerke
Materialien
- Verschiedene einheimische und importierte Hölzer als:
  - Massivholz (hauptsächlich in Form von Brettern oder Bohlen)
  - Furnier
- Holzwerkstoffe (haupsächlich Plattenwerkstoffe) z.B.
  - Platten auf Massivholzbasis
    - Brettsperrholz (z.B. Dreischichtplatte)
    - Brettschichtholz
    - Stabsperrholz (Tischlerplatte)
    - …
  - Furnierholzwerkstoffe
  - Spanplatten
    - Flachpressplatten
    - Strangpressplatten
    - OSB (Oriented Strand Board)
    - …
  - Holzfaserplatten
- Kunststoffe
  - Plexiglas (oder allgemeiner durchsichtige oder trübe Kunststoffplatten)
  - Corian
  - Epoxidharz
  - …
- Metall, z.B. in Form von Beschlägen
- Mineralische Werkstoffe
Fachrichtungen
- Möbeltischler: Herstellung und Montage von mobilen und Einbaumöbeln
- Bautischler: Herstellung und Montage von Bauelementen
- Treppenbau: Herstellung und Belag von Treppen sowie Geländern und Brüstungen
- Innenausbau: Erstellung von bewohnbaren Raumoberflächen auf Basis des Rohbaus
- Ladenbau: Erstellung und Einrichtung von Verkaufspräsentationsflächen inkl. z.B. Kassenbereich
- Montagebetriebe: Montage vorwiegend von Bauelementen auf Baustellen ohne umfangreiche Fertigungsstätten
- Bodenleger: Verlegen und Aufarbeiten von Parkett-, Dielen-, Laminat- und anderen Böden
- (Messebau)
- Billardbau
- Zaunbau
- …
Rausschmeißer: In eigener Sache
- Postkarten eingetroffen aus Berlin, Rheinland-Pfalz, dem Kanton Zürich und vom Kongress – Bitte weiter so. :)
- Wir nehmen auch gute Bewertungen bei Apple Podcasts etc.

STP052: TLS im Detail

Thu, 14 Mar 2024 20:15:00 GMT

Wir steigern den Schwierigkeitsgrad. In dieser Episode wird der Stoff der vorherigen Folgen abgefragt. Dafür können wir dann aber auch die Folge in einer Stunde abfeiern – oder zumindest den ersten Teil.

Shownotes

Rückbezug zu STP048: Transportverschlüsselung vs. Ende-zu-Ende-Verschlüsselung
- Ende-zu-Ende-Verschlüsselung: zwischen den Endpunkten einer Kommunikation (z.B. im Messenger zwischen Alice und Bob)
- Transport-Verschlüsselung: entlang eines einzelnen Schrittes des Kommunikationsweges (z.B. im Messenger einmal zwischen Alice und dem Server, und dann einmal zwischen dem Server und Bob)
- heute reden wir über Transport-Verschlüsselung
Transport Layer Security (Sicherheit auf der Transportschicht): "ein Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet"
- nicht selbst ein vollständiges Protokoll, sondern ein Fundament, dass andere Protokolle als Nutzlast trägt (vgl. STP005: Netzwerkschichten-Modell)
- Geschichte von TLS: 1994 erste stabile Version als Teil des Netscape-Browsers (unter dem Namen SSL); in den 90ern in schneller Abfolge neue Versionen, seitdem nach Bedarf in unregelmäßigen Abständen; aktuell TLS 1.3 (und 1.2 ist auch hinreichend okay)
- wir beschreiben jetzt die Struktur des TLS-Protokolls; hierfür sind als notwendiges Vorwissen STP043 (Kryptografische Primitiven) und STP048 (Vertrauen) erforderlich
TLS Record: zweite und einfachere Phase der Verbindung
- einfach eine symmetrische Verschlüsselung, um die Nutzdaten einzupacken
- offensichtliches Problem: Wo kommt der symmetrische Schlüssel her?
- das klingt nach einem Job für asymmetrische Verschlüsselung
TLS Handshake: initiale Aushandlungsphase zu Beginn der Verbindung
- erste Aufgabe: Aushandlung eines symmetrischen Schlüssels -> Diffie-Hellman-Schlüsselaustausch (siehe STP Live)
- zweite Aufgabe: Überprüfung der Identität der Gegenstelle -> digitale Zertifikate (siehe STP048)
- beide Aufgaben müssen miteinander verbunden werden -> drei (teils überlappende) Phasen
- Phase 1: Berechnung eines initialen symmetrischen Schlüssels mit Diffie-Hellman, damit Verschlüsselung von Phase 2 und 3
- Phase 2: Validierung des Server-Zertifikates durch den Client und ggf. des Client-Zertifikates durch den Server
- Phase 3: Client würfelt den finalen symmetrischen Schlüssel und überträgt diesen verschlüsselt mit dem öffentlichen Schlüssel des Server-Zertifikates
Warum zwei Schlüssel?
- die Art und Weise der Übertragung des finalen Schlüssels stellt sicher, dass der Server den privaten Schlüssel kontrolliert
- der Handshake-Schlüssel aus Phase 1 stellt sicher, dass auch bei nachträglicher Kompromittierung des privaten Schlüssels des Servers eine mitgeschnittene Verbindung nicht geknackt werden kann (Perfect Forward Secrecy/Perfekte Vorwärts-Geheimhaltung)
eine wesentliche Eigenschaft von TLS: Kryptoagilität
- TLS ist erstmal nur eine Grundstruktur
- konkrete kryptografische Primitiven sind bis zu einem gewissen Grad gegeneinander austauschbar
- im Laufe der Zeit Hinzufügung neuentwickelter Primitiven und Abschaffung alter Primitiven
- Handshake enthält eine Verhandlung, in der Client und Server sich über die zu verwendenen Primitiven handelseinig werden
Im Gespräch erwähnt:
- ARP(Address Resolution Protocol) erklärt im RFC-Podcast

STP051: Ablauf eines IT-Angriffs

Thu, 22 Feb 2024 00:10:00 GMT

Im zweiten Teil der ursprünglichen Episode #49 spricht Xyrill nun über den tatsächlichen Ablauf einer Attacke. Außerdem geht es um Motivationen und Gegenmaßnahmen.

Shownotes

[Unser Arbeitsfeld] heißt "Computer-Sicherheit", nicht "Computer-Optimismus". Wir machen uns der schlimmstmöglichen Resultate bewusst, denn auch wenn wir es nicht tun, unsere Gegner werden es auf jeden Fall tun.

– Matthew Green über IT-Sicherheit (übersetzt aus dem Englischen)

Topologie eines IT-Angriffs auf ein verteiltes System (z.B. das interne Netz eines Unternehmens oder einer Organisation)
- Erstangriff entweder durch reinen Exploit eines von außen erreichbaren Systemes (z.B. der Firmenwebseite) oder durch Einschleusung eines Exploits mittels Social Engineering (Manipulation von Menschen mit Zugriff auf das System mit dem Ziel, einen Exploit einzuschleusen oder Informationen wie Passwörter auszuschleusen; z.B. Phishing)
- basierend auf erstem Zugriff in das System dann Privilege Escalation (Verwendung weiterer Exploits, um schrittweise immer weitergehenden Zugriff zu erlangen) und Lateral Movement (Ausnutzung des Zugriffs auf ein Teilsystem, um andere verwundbare Systeme im Netzwerk aufzuspüren und anzugreifen)
Welche Ziele kann ein IT-Angriff letztendlich verfolgen?
- Datendiebstahl: z.B. Spionage, Wirtschaftsspionage, Erpressung mittels Kompromat, Doxing
- Propaganda: z.B. Verbreitung von Desinformation und Fake-News durch gekaperte Accounts von Personen des öffentlichen Lebens
- Datendiebstahl: z.B. Datenbanken von Nutzerdaten (Passwörter, Mail-Adressen, Kontodaten etc.) können für weitere Angriffe und Betrugsversuche vermarktet werden
- Finanzdiebstahl: z.B. Ausnutzung illegitimen Zugriffs auf Bankkonten, Kreditkarten oder auch Konten in virtuellen Währungen
- Sabotage: z.B. Ransomware (Infektion durch Virus oder Trojaner, dann evtl. Lateral Movement, dann Verschlüsselung aller erreichbaren Festplatten und Backups, dann Erpressung von Lösegeld)
- Sabotage: z.B. Stuxnet
Was kann man auf der Verteidigerseite machen?
- keine Sicherheitslücken haben :)
- Verwendung von sichereren Programmiermethodiken (z.B. moderne Programmiersprachen, die Speicherverwaltungsfehler systematisch verhindern)
- Einsatz von Sandboxing (siehe STP023) und anderen Techniken, um die Privilege Escalation zu erschweren ("Principle of Least Privilege": jeder Prozess sollte mit den geringsten möglichen Rechten laufen, und jedes Benutzerkonto sollte nur genau die Berechtigungen haben, die für die Erfüllung der jeweiligen legitimen Aufgaben notwendig sind)
- aktive Verteidigungsmaßnahmen wie Virenscanner oder Intrusion-Detection-Software sind umstritten
- allgemeiner: Threat Modeling; das systematische Auflisten von möglichen Angriffen und Schwachstellen, um dann entsprechende Gegenmaßnahmen zu koordinieren
- nach dem Angriff: Attribuierung (die Zuschreibung eines Angriffs zu einem Angreifer) ist zwar oft gewünscht (man hat halt gerne einen Schuldigen, gerade in der politischen Arena), ist aber meist extrem schwer (es ist deutlich einfacher, als Angreifer falsche Fährten zu legen, als sie als Forensiker als solche zu erkennen)
weiterführende Quellen
- zu Social Engineering: Hirne hacken
- zu digitalen Waffen und Hackback: Wie Hackback mit der Gesellschaft spielt

STP050: Jargon File

Thu, 01 Feb 2024 22:10:00 GMT

In dieser Nichtjubiläumsfolge kümmern wir uns wieder einmal darum, unseren Hörer:innen Nerdkultur näher zu bringen. Dazu ist selbstverständlich nichts besser geeignet als der Ursprung vieler lieb gewonnener Worte und Redewendungen.

Shownotes

Jargon File
- "a comprehensive compendium of hacker slang illuminating many aspects of hackish tradition, folklore, and humor" ("ein umfassendes Kompendium des Hackerslangs, das viele Aspekte der Hackertradition, der Folklore und des Humors beleuchtet")
- zuletzt aktualisiert 2003, repräsentiert sprachliche Eigenheiten der 70er bis 90er, als die Hacker noch relativ isoliert vom Mainstream-Zeitgeist waren
- wir haben durch das Glossar geschaut und präsentieren unsere Picks von A bis M
- Vorsicht: das Jargon File ist absolut ein Produkt seiner Zeit und einer männlich-weiß dominierten Subkultur mit entsprechend teils unsensiblen Begriffsbildungen und Nutzungsbeispielen (zum Beispiel hier in Unterdefinition 2)
Namensgebend: hack und hacker
Design und Methodik: buzzword-compliant, cargo cult programming, connector conspiracy, crufty, cruftsmanship, deep magic, elegant, KISS principle
Fehler: airplane rule, bug-for-bug compatible, bug-of-the-month club, Finagle's Law vs. Murphy's Law, glitch, magic smoke, smoke test
Vergänglichkeit: bit rot und link rot, cosmic rays
Netzwerk: Chernobyl packet, honey pot, LAN party, massage
Hardware: bitty box, gorilla arm, Moore's law und passend dazu Andy's and Bill's law
Grafische Oberflächen: marching ants, menuitis
Kryptografie: Alice and Bob
Dokumentation: Green's theorem, language lawyer, left as an exercise
Kommunikation: fnord, Hanlon's Razor, highly, Jeopardy-style quoting, meta und metasyntactic variable, meatspace
als Rausschmeißer ein Koan: "Tom Knight and the Lisp Machine"

STP049: Schadcode

Thu, 11 Jan 2024 20:05:00 GMT

In dieser ersten Folge zum Thema Cyber-Cyber halten wir uns so lange mit der Einführung von Grundbegriffen auf, dass am Ende die Entscheidung fällt, den Rest auf Episode 51 zu verschieben. Betrachtet euch hiermit als angeteasert!

Shownotes

Die drei wichtigsten Dinge, die Experten über Software-Sicherheit wissen:

Software ist unglaublich unzuverlässig und unsicher.

Nein, wirklich, ihr könnt es euch nicht vorstellen.

Es ist sogar noch schlimmer als das.

Matt Blaze auf Twitter (Achtung: zweiter Link geht zu einer Domain von Elon Musk)

Vorbemerkung: für offensive und defensive Computernutzung wird regelmäßig der Wortteil "Cyber-" verwendet (z.B. "Cyberangriff", "Cybersicherheit")
- in IT-Kreisen, insb. im CCC-Umfeld, gilt "Cyber-" als Schibboleth für Leute, die von IT keine tiefgehende Ahnung haben (siehe z.B. "Unsere Cyber-Cyber-Regierung")
- wir bleiben deswegen sicherheitshalber bei "IT-Angriff" :)
Grundlage: Sicherheitslücken ("Fehler in einer Software oder einer Hardware, durch [die] ein Programm mit Schadwirkung oder ein Angreifer in ein Computersystem eindringen kann")
- siehe STP037: heutige berühmte Softwarefehler sind meist Sicherheitslücken (z.B. Heartbleed, wie in STP037 besprochen)
- siehe STP039: handwerkliche Fehler in der Authentifizierung oder Autorisierung ergeben meist besonders gut ausnutzbare Sicherheitslücken (siehe gerade neulich Azure AD)
- siehe STP045/STP047: Grundlage vieler Sicherheitslücken sind Speicherverwaltungsfehler (z.B. Pufferüberlauf, wie in STP047 besprochen)
- Sicherheitslücken werden aktiv gesucht, entweder von "Whitehats" (Sicherheitsforschern oder den Red-Teams der Softwarehersteller selbst) oder von "Blackhats" (die die Lücken für tatsächliche Angriffe ausnutzen wollen oder an Angreifer verkaufen wollen)
- bekannte Sicherheitslücken werden in der CVE-Datenbank ("Common Vulnerabilities and Exposures", dt. "Bekannte Schwachstellen und Anfälligkeiten") geführt (z.B. Heartbleed ist CVE-2014-0160)
zweiter Schritt: Exploit (eine systematische Methode, um eine Sicherheitslücke auszunutzen)
- auch für Whitehats sind Exploits wichtig, um die Kritikalität einer Sicherheitslücke zu demonstrieren
- für Blackhats sind Exploits die handelbare Form von Sicherheitslücken
- Preise für Exploits orientieren sich an Angebot und Nachfrage, z.B. für RCE-Exploits in iOS oder Android bis zu 20 Mio. $ (RCE = Remote Code Execution)
- Angriffe auf der Grundlage von Exploits haben meist eines von zwei Zielen: Ausführung von Schadcode oder Ausschleusung von Informationen (z.B. Passwörter)
Schadcode: der große Nachteil von Computern ist auch ihr Vorteil; sie tun genau all das, was man ihnen sagt :)
- Computervirus: ein sich selbst verbreitendes Programm, dass sich in einen Computer einnistet (biologisches Analog: Pilze, die die Gehirne von Insekten infizieren)
- Computerwurm: wie ein Virus, aber nistet sich nicht ein, sondern verbreitet sich nur weiter (z.B. über E-Mails oder USB-Sticks)
- Trojaner: ein Virus, der sich nicht mittels Exploit einer Sicherheitslücke verbreitet, sondern sich als nützliches Programm tarnt
  - in der netzpolitischen Debatte vor allem relevant in Form von Staatstrojanern
Vorschau: zweiter Teil in STP051 (Ablauf eines IT-Angriffs)
im Gespräch erwähnt: Vortrag von HonkHase zu Hackback und Digitalen Waffen

STP048: Vertrauen

Thu, 21 Dec 2023 19:30:00 GMT

Nach Xyrills gewaltigem humorischen Auftakt kommen wir zu wirklich wichtigen Dingen: Wem kann vertraut werden und warum? Hat Vertrauen ein Haltbarkeitsdatum? Wem vertraue ich, ohne explizit davon zu wissen? Zum Schluss gibt es noch Aufklärung über die Herkunft des Wortes Spam für unerwünschte Werbung.

Shownotes

Rückbezug zu STP039: Authentifizierung ("Wer ist diese Person?" bzw "Was darf diese Person?")
- Problem: Woher weiß man, ob ein Identitätsnachweis verlässlich ist? -> Vertrauen
- Vorstellung verschiedener Arten von Vertrauensvermittlung -> Ziel: Vokabular aufbauen, Methoden gegeneinander abwägen
- Beispiele im realen Leben: gemeinsame Vorgeschichte und Inside-Jokes, Geheimlosungen, Personalausweise
Vererbung von Vertrauen: Digitale Zertifikate nach dem X.509-Standard
- basierend auf asymmetrischer Verschlüsselung (siehe STP043)
  - Zertifikat = öffentlicher Schlüssel + Identitätsinformationen + Signatur durch ein übergeordnetes Zertifikat
  - durch die Signaturkette geht Vertrauen vom Anfang der Kette (Zertifikatsautorität, CA) auf die abgeleiteten Zertifikate über
- authentifizierende Systeme müssen nur das allererste Zertifikat in der Kette kennen (das Wurzel-Zertifikat bzw. Root-CA)
  - Beispiel: Wurzelzertifikat signiert Zertifikat einer unterliegenden CA, und dieses signiert ein Zertifikat für einen Nutzer
- Einsatzfälle
  - Transportverschlüsselung im Web (HTTPS, Zertifikat enthält Domain-Namen)
  - Impfzertifikate in der Corona-Warn-App
  - Benutzerseitige Zertifikate im Firmen-Intranet oder bei Elster
  - Äquivalente in der realen Welt: Personalausweis oder Reisepass (ausgestellt durch eine Regierungsstelle), Zugangskarte in der Firma (ausgestellt durch die Liegenschaftsverwaltung der Firma), Mitarbeiteruniform (eine Person in DB-Uniform auf einem Bahnhof wird wahrscheinlich ein DB-Mitarbeiter sein)
- Vorteile: skaliert sehr gut auf viele Akteure, nur relativ wenig Speicher notwendig (für die Root-CAs)
- Nachteil: erfordert Vertrauen in eine zentrale Stelle
Vertrauen durch Beständigkeit: Trust on first use (TOFU)
- beim ersten Kontakt mit einer Person wird deren öffentlichen Schlüssel blind vertraut
- bei weiteren Kontakten wird demselben Schlüssel weiterhin vertraut, aber die Präsentation eines neuen Schlüssels wird als Angriffsversuch bzw. Betrugsversuch gewertet
- Einsatzfälle
  - die meisten Messenger mit Ende-zu-Ende-Verschlüsselung (z.B. Signal, WhatsApp, verschlüsselte Chats in Telegram)
  - Fernzugriff auf Server mittels SSH (für den Teil, wo die Identität des Servers überprüft wird)
  - Äquivalente in der realen Welt: Bekanntschaften unter Nachbarn oder Vereinsmitgliedern (alles, was auf der Basis von "den kenn ich" läuft)
- Vorteil: braucht keinen zentralen Vertrauensanker
- Nachteil: anfällig gegen Attacken beim initialen Verbindungsaufbau
Vertrauen durch Vitamin B: Web of Trust (WoT)
- Zertifikate ähnlich wie bei X.509: öffentlicher Schlüssel + Identitätsinformatione + Liste von Signaturen
- Signaturen nicht vertikal (in einer Hierarchie), sondern horizontal (zwischen gleichrangigen Zertifikaten verschiedener Nutzer)
- Vertrauen vererbt sich zwischen Nutzern:
  - unendliches Vertrauen in das eigene Zertifikat
  - hohes Vertrauen in Zertifikate, die man selbst signiert hat
  - mittelhohes Vertrauen in Zertifikate, die von diesen Zertifikaten signiert wurden
  - und so weiter
- Einsatzfälle
  - E-Mail-Verschlüsselung mit PGP/GPG, siehe auch Keysigning-Parties
  - Verifikation eines Chat-Kontakts über einen Seitenkanal
  - Äquivalent in der realen Welt: Bekanntschaften über Bande ("der Freund der Freundin des Schwippschwagers")
- Vorteil: braucht keinen zentralen Vertrauensanker
- Nachteil: Schlüssel mit vielen Signaturen sind eigentlich wertvoll, aber auch unhandlich; Angriff möglich durch bösartige Müll-Signaturen
Seitenleiste: Wie könnte man solchen Signatur-Spam verhindern?
- Problem: Spam (sowohl bei E-Mails als auch GPG-Signaturen) ist für den Versender sehr günstig und für den Empfänger extrem lästig -> Kann man den Spieß umdrehen?
- Idee (1990er): wir nutzen Einwegfunktionen (Streuwertfunktionen siehe STP004, STP043), aber drehen die Sache um
  - Sender muss einen Datensatz bilden, für den eine Streuwertfunktion ein Ergebnis mit X führenden Nullen hat (X kann variiert werden je nach Leistungsfähigkeit aktueller Prozessoren) -> erfordert sehr viel Durchprobieren von Eingabewerten
  - Empfänger muss nur schauen, dass die Lösung stimmt -> erfordert nur eine Berechnung mit dem präsentierten Eingabewert
- Implementation (2002): Hashcash als eines der ersten Proof-of-Work-Verfahren
Vertrauen durch Proof of Work: Blockchain
- Kombination von Proof of Work mit Merkle-Bäumen
- Merkle-Baum = Baumstruktur aus Datenpaketen, die jeweils die Hash-Werte ihrer untergeordneten Knoten enthalten -> Hash-Wert des Wurzelknotens ist die einzige benötigte Information, um die Integrität des gesamten Baumes zu überprüfen
- Blockchain: System zur kontinuierlichen Erweiterung eines Merkle-Baums (genauer: einer Merkle-Kette) um neue Blöcke, aber die Hashes jedes Blocks müssen eine Proof-of-Work-Bedingung erfüllen
- kein Vertrauen in einzelne Akteure notwendig, nur in die Sicherheit des Algorithmus
Abendgedanken: Vertrauen lässt sich nicht eliminieren, nur verschieben
- Vertraue ich einem Menschen? Einer Maschine? Einer Organisation? Einem Algorithmus?
- Niemandem vertrauen ist auch keine Lösung.
im Gespräch erwähnt
- Versionsverwaltungssystem "git", wie von uns besprochen im Pentaradio vom Juli 2021

STP047: Speicherallokation

Thu, 30 Nov 2023 01:10:00 GMT

Ein weiteres Mal beschäftigen wir uns mit Speicher. Diesmal spezifisch mit Haufen davon. Wie man die wieder wegräumt oder gar nicht erst zu groß werden lässt, ist auch ein Thema. Außerdem gibt es ein Novum direkt am Beginn der Folge.

Shownotes

Rückbezug auf STP045: Heap (Haufenspeicher)
- keine Strukturvorgaben durch das Betriebssystem oder die Prozessorarchitektur
- notwendig für Daten, deren Lebenszeit nicht der Struktur von Unterprogrammen folgt, oder deren Größe die 132 KiB des Stacks übersteigt
- neue Frage: Wie kann man diesen unstrukturierten Haufen sinnvoll verwalten?
- Analogie: Ein Team verwendet als Speicher ein großes Whiteboard, auf dem verschiedene Mitglieder des Teams rumschreiben wollen, ohne sich gegenseitig in die Quere zu kommen.
man braucht einen Allokator
- meist in Form einer Programmbibliothek, die auf die jeweilige Programmiersprache und/oder Laufzeitumgebung abgestimmt ist
- klassischerweise zwei Funktionen: "malloc" ("memory allocate"; ich brauche ein Stück Speicher der Größe X) und "free" (das gegebene Stück Speicher brauche ich nicht mehr)
- Allokationen mittels malloc sind meist sehr viel kleiner als die Speicherseiten, die das Betriebssystem rausgibt (min. 4 KB) -> Allokator holt sich ganze Speicherseiten und zerteilt die in mundgerechte Stücke
- damit "free" funktioniert, muss der Allokator irgendwo über diese Zerstückelung Buch führen -> gewisser Mehraufwand an Speicher für die Buchführung
- verschiedene Anwendungen machen ihre Speicherallokationen in unterschiedlichen Mustern (häufig z.B. ein gewisser Bodensatz an großen Allokationen, die für die ganze Lebensdauer des Programms erhalten bleiben, und dazu sehr viele kleine und kurzlebige Allokationen für bestimmte Einzeloperationen) -> interessantes Arbeits- und Forschungsfeld für Leute, die sich gern in Algorithmen eingraben
Speicherverwaltung im Heap ist sicherheitskritisch -> mögliche Fehlerquellen
- Speicherleck: Speicher wird allokiert, aber dann nicht wieder freigegeben; da der Allokator nicht wissen kann, ob der Speicher noch verwendet wird, muss er brachliegen
- Pufferüberlauf: Allokation war für X Bytes, aber dann wird über das Ende (Basisadresse + X) hinausgeschrieben; dies zerstört dann Daten in anderen Allokationen oder Buchführungsdaten des Allokators
- Use after free: Allokation wird mit "free" zurückgegeben, aber danach noch vom Programm verwendet, obwohl der Allokator dieses Stück Speicher vielleicht schon wieder anderweitig allokiert hat
- Das klingt alles anstrengend. Kann man das nicht den Computer machen lassen? -> automatische Speicherverwaltung
einfachste praktikable Idee: Referenzen zählen
- Ansatz: bei allokiertem Speicher nicht die lose Speicheradresse herumreichen, sondern noch einen Zähler mitführen
  - Zähler beginnt bei 1, da man am Anfang eine Referenz hat
  - bei jedem Kopieren der Referenz wird der Zähler um 1 erhöht, bei jedem Löschen einer Referenz um 1 verringert
  - die Allokation wird freigegeben, wenn der Zähler auf 0 fällt
- Vorteil: sehr schnell, sehr zuverlässig, eliminiert bei konsequenter Anwendung das Risiko von "Use after free"
- Nachteil: garantierte Speicherlecks bei zyklischen Referenzen (z.B. A verweist auf B verweist auf C verweist auf A, aber nichts anderes verweist auf A/B/C)
- komplexere Formen von automatische Speicherverwaltung mit Zykluserkennung heißen meist Garbage Collector (GC, "Müllsammler"); strenggenommen sind Referenzzähler "konservative GC"
Beispiel für einen GC-Algorithmus: Mark and Sweep
- aktives Aufräumen zu bestimmten Gelegenheiten, z.B. wenn bei malloc kein Speicher mehr frei ist und weiterer Speicher vom Betriebssystem angefordert werden müsste
- Algorithmus:
  - Allokationen, deren Adressen im Stack liegen, werden als "erreichbar" markiert
  - alle anderen Allokationen werden initial als "nicht erreichbar" markiert
  - ausgehend von den erreichbaren Allokationen wird sukzessive nach Verweisen auf andere Allokationen gesucht und diese ebenfalls als "erreichbar" markiert
  - nachdem alles durchsucht wurde, werden alle Allokationen freigegeben, die immer noch als "nicht erreichbar" markiert sind
- GC braucht meist eine enge Integration mit dem Allokator und mit der Programmiersprache oder der Laufzeitumgebung (z.B. insb. um die Frage "welche Allokationen sind im Stack referenziert" zu beantworten)
- Nachteil: fast jeder GC muss zumindest für einen Teil der Aufräumphase "die Welt anhalten", was für den Nutzer wie Motorstottern aussieht
Optimierung der Heap-Nutzung: Anzahl der Allokationen verringern (es gilt die Faustregel "der einzige Weg, zu optimieren, ist, weniger zu tun")
- zusammenhängende Datenstrukturen möglichst in eine einzelne Allokation ablegen anstatt in mehrere Teilstücke ("Arena-Allokation", "Small Object Allocation")
- kleine Daten bevorzugt im Stack halten und nicht auf den Heap legen (Xyrill hat eine Anekdote zu Minecraft)
- noch eine Idee: GC zu opportunen Momenten explizit anstarten (z.B. bei Spielen während des VSync, d.h. wenn ein Einzelbild gerade fertig ist und es auf den Bildschirm kopiert wird)
zum Schluss ein Blick auf ein Teilgebiet der Heap-Algorithmen: Zwischenspeicher (Cache)
- Grundproblem: bestimmte Operationen sind teuer (z.B. Netzwerkabfragen, Einlesen von Dateien von der Festplatte, komplexe Berechnungen), aber reproduzierbar; wir würden die Ergebnisse gerne wiederverwenden, aber können nicht alle im Speicher halten
- Speicherstück mit einer festen Größe wird als Cache designiert
- idealerweise würde man genau die Ergebnisse dort ablegen, die in der Zukunft am häufigsten wieder nachgefragt werden
- Problem: "Vorhersagen sind schwierig, insbesondere, wenn sie die Zukunft betreffen" -> Cache-Replacement-Algorithmen sind ein Forschungsfeld
- Beispiel LRU ("Least Recently Used"): wenn ein neues Element abgelegt wird, wird dasjenige existierende Element überschrieben, das am längsten ungenutzt ist
Lesestoff: www.memorymanagement.org (englisch)

STP046: Bram Moolenaar und vim

Thu, 09 Nov 2023 13:05:00 GMT

Obwohl dies ein Technikpodcast ist, kommen wir um politische Themen oft nicht ganz herum. In dieser Folge jedoch stellen wir uns nun direkt ins Feuer. Und all das nur, weil Xyrill unbedingt seinen Lieblingseditor unters Volk bringen will.

Shownotes

Aus aktuellem Anlass: Anfang August 2023 ist Bram Moolenaar gestorben.

Bram Moolenaar
- Jahrgang 1961, bis 1985 Studium der Elektrotechnik in Delft mit Abschlussarbeit zu Multiprozessor-Unix-Architektur
- seit 1988 Entwicklung eines Klons des Texteditors vi mit dem Namen vim (erst "vi imitation", später "vi improved"; "vim" kann aber auch "Elan" bedeuten)
- bis kurz vor seinem Tod (d.h. 35 Jahre) Leitung des vim-Projektes in seiner Freizeit (neben der Arbeit u.a. bei Google)
- außerdem Engagement für die NGO ICCF Holland, die Waisenkinder in Uganda unterstützt
in diesem Zusammenhang: Was ist eigentlich vim? Und warum verbringt Xyrill sein halbes Leben darin? (Spoiler: man kann alle intellektuelle Arbeit als Texteditieren darstellen; siehe auch STP006)
- frühe 1970er-Jahre: ed – der erste Unix-Texteditor; damals hatten Unix-Computer noch keinen Bildschirm, sondern nur Tastatur und Drucker
- 1976: ex – eine von vielen Weiterentwicklungen von ed mit zusätzlichen Funktionen
- darin enthalten: ein neuartiger "visual mode", der 1979 der Standard wurde – vi ist geboren
- 1989 dann vim als Weiterentwicklung von Brams Portierung von vi auf Atari-Computer
- sprich: im Großen und Ganzen eine 50 Jahre lang ungebrochene Evolutionslinie von Texteditoren, analog und parallel zu Unix
Kernidee von vi-artigen Texteditoren: modales Editieren
- in herkömmlichen Texteditoren: jeder Tastendruck hat immer die gleiche Bedeutung (z.B. "u" fügt ein kleines U ein; z.B. "Strg+Z" macht die letzte Operation rückgängig)
- Nachteil: komplexe Operationen sind begrenzt darin, wieviele Tastenkombinationen man sich merken kann
- in vi-artigen Editoren: Bedeutung eines Tastendrucks hängt vom aktuellen Modus ab (z.B. "u" im Eingabemodus fügt ein kleines U ein, jedoch "u" im Befehlsmodus macht die letzte Operation rückgängig)
- erster Vorteil: mehr Befehle sind durch einfache Tastendrücke erreichbar, die sich einfacher tippen lassen als Akkorde wie "Strg+Umschalt+R"
zweite Besonderheit: Aktionsgrammatik
- in herkömmlichen Texteditoren: viele Aktionen, die alle ziemlich ähnlich sind (z.B. ein Zeichen nach links löschen, ein Wort nach links löschen, ein Zeichen nach links auswählen, ein Wort nach links auswählen, etc.)
- Befehlsmodus in vi: Befehle werden wie mit einer Grammatik zusammengesetzt
  - Substantive = Bewegungen (z.B. "w" = ein Wort nach rechts, "b" = ein Wort nach links, "j" = eine Zeile nach unten)
  - Zahlen = Vervielfältigungen (z.b. "3w" = drei Worte nach rechts, "5j" = fünf Zeilen nach unten)
  - Verben = Aktionen (z.B. "d" = löschen, "c" = ändern)
  - ganzer Befehl: nur eine Bewegung (bewegt den Cursor, z.B. "3w") oder eine Aktion und eine Bewegung (z.B. "d5j")
- damit zweiter Vorteil: eine große Menge an komplexen Aktionen ist mit sehr kompakten Befehlen auszudrücken (z.B. "Ich möchte den Inhalt des Klammerpaars löschen, in dem mein Cursor steht" = "di(", "ich möchte diesen Absatz und die nächsten drei Absätze automatisch formattieren" = "ga4p")
weitere coole Funktionen in vim
- Makrofunktion: Folgen von Tastendrücken können aufgezeichnet und dann automatisiert abgespielt werden (gibt's auch in anderen Editoren, aber paart sich mit vi's Befehlssprache besser als mit denen der meisten anderen Texteditoren)
- man kann damit Hacker Jeopardy gewinnen :3
Kann man das lernen?
- Ja, auf jeden Fall. Was man da an Zeit aufwendet, zahlt sich dann über Jahrzehnte aus.
- Xyrill empfiehlt: Erstmal nur mit den Basics anfangen (Dateien öffnen und schließen, zwischen Modi wechseln). Dann schrittweise Befehle lernen, wann immer man das Gefühl hat, dass man was von Hand macht, was auch einfacher gehen sollte.
- vim hat ein eingebautes Tutorial: vimtutor auf der Kommandozeile ausführen
- vim-Cheatsheet auf dem Schreibtisch bereitlegen (Beispiel (deutsch), Beispiel (englisch))
im Gespräch erwähnt
- Perl-Programm mit Spracherkennung schreiben
- Pentaradio zu Git (Versionsverwaltungssystem)

STP045: Speicherstruktur aus Programmsicht

Thu, 19 Oct 2023 19:45:00 GMT

In dieser Ausgabe greifen wir ein altes Thema erneut auf, bei dem ttimeless trotzdem stellenweise nur schwer folgen kann. Denn durch Wiederholung lernt man. Denn durch Wiederholung lernt man.

Shownotes

Rückblick: wir hatten schon einige Folgen zu Speicherverwaltung
- STP007: Speicherhierarchie (Festplatte und SSD, Arbeitsspeicher/RAM, Prozessor-Cache, Registerbank)
- STP019: Speicherschutz (virtueller Speicher, Auslagerungsspeicher/Swap, Direct Memory Access)
- Nachtrag/Linktipp: https://www.linuxatemyram.com
- das war alles aus Sicht des Betriebssystems; diesmal Abläufe innerhalb des Prozesses
Was stellt uns das Betriebssystem bereit? -> Virtueller Speicher
- nominale Größe: entsprechend der Adressbreite des Prozessors (für 32 Bit sind das 2^32 Bytes = 4 GiB, für 64 Bit sind es 2^64 Bytes = 16 EiB = 16.777.216 TiB)
- nutzbar aber nur dort, wo das Betriebssystem für uns eine tatsächlich existierende Speicherseite einblendet
- initiale Belegung (siehe Beispiel unten): hauptsächlich Programmdatei und benötigte Programmbibliotheken mit ihren entsprechenden Segmenten
- Belegung (und Rückgabe) weiterer Speichersegmente mittels Syscalls (siehe STP019)
- klassische Struktur des virtuellen Speichers: oben der Stapel, unten ein Haufen
vorher einige Bemerkungen zu klassischen Schutzmaßnahmen, die man im untenstehenden Beispiel sehen kann
- die untersten paar KiB des Adressbereiches werden nie vergeben
  - dies verhindert versehentlichen Zugriff auf Nullzeiger mit hoher Wahrscheinlichkeit
- Address Space Layout Randomization (ASLR): Programmdateien und Programmbibliotheken werden an zufällig gewählten Speicheradressen eingeblendet, um es Angreifern zu erschweren, das Programm so zu manipulieren, dass es ungeplant in deren Code hineinspringt
  - klingt nach einer einfach umsetzbaren Schutzmaßnahme
  - war aber lange nicht weit verbreitet, weil der benötigte Position Independent Code (PIC) mit einem kleinen Geschwindigkeitsverlust (1-3%) einhergeht
oberer Teil (d.h. bei hohen Adressen): Stack (Stapelspeicher)
- Programme sind meist als ineinander verschachtelte Unterprogramme (Subroutinen) aufgebaut (siehe STP011)
- Daten, die nur für die Dauer des jeweiligen Unterprogramms gebraucht werden, können im Stack aufgestapelt werden
- Idee: Hauptroutine kriegt den ganzen Stack und knapst sich oben soviel ab, wie es selber braucht
- nächste Unterroutine kriegt den Rest des Stacks und verfährt in derselben Weise
- wenn die Unterroutine zurückkehrt, kann der von ihr benutzte Stack an die nächste Unterroutine weitergereicht werden -> keine aufwändige Speicherverwaltung nötig
- bei Prozessen mit mehreren Threads (parallel lauffähigen Teilprozessen) teilen sich alle Threads grundsätzlich denselben virtuellen Speicher, aber kriegen jeweils eigene Stacks
- Stack ist vom Betriebssystem in einer festen Größe angelegt (im Beispiel unten 132 KiB) – bei zu vielen verschachtelten Subroutinen-Aufrufen kommt es zum berüchtigten Stack Overflow
unterer Teil (d.h. bei tiefen Adressen): Heap (Haufenspeicher)
- keine Strukturvorgaben durch das Betriebssystem oder die Prozessorarchitektur
- notwendig für Daten, deren Lebenszeit nicht der Struktur von Unterprogrammen folgt, oder deren Größe die 132 KiB des Stacks übersteigt
- neue Frage: Wie kann man diesen unstrukturierten Haufen sinnvoll verwalten? -> Teil 2 folgt in STP047
Randnotiz zu unserem Beispiel unten: Was sind vvar, vdso und vsyscall?
- Syscalls sind zeitaufwändig (in der Größenordnung von dutzenden Mikrosekunden), da man vom Prozess in den Kernel umschalten muss und wieder zurück
- Idee: manche Syscalls kann der Kernel mit geschickter Planung im Prozess selbst beantworten, ohne Kontextwechsel
- Beispiel: gettimeofday (Abfrage der aktuellen Uhrzeit) kann man aus einem vorhergehenden Datenpunkt des Kernels anhand des Taktzählers des Prozessors fortschreiben (z.B. TSC auf x86)
- vsyscall: erste derartige Implementation, mit zwei großen Problemen (Platzbegrenzung, kein PIC = kein ASLR); nur aus Kompatibilitätsgründen angeboten
- vDSO ("virtual dynamic shared object"): die aktuelle Implementation, verhält sich wie eine dynamisch nachgeladene Programmbibliothek
- vvar: Datensegment für das vDSO

$ sleep 30 &
[1] 4970
$ cat /proc/$(pidof sleep)/maps
# address                perms offset   dev   inode       pathname
556ac29f4000-556ac29f6000 r--p 00000000 fe:00 10234368    /usr/bin/sleep
556ac29f6000-556ac29f9000 r-xp 00002000 fe:00 10234368    /usr/bin/sleep
556ac29f9000-556ac29fa000 r--p 00005000 fe:00 10234368    /usr/bin/sleep
556ac29fa000-556ac29fb000 r--p 00006000 fe:00 10234368    /usr/bin/sleep
556ac29fb000-556ac29fc000 rw-p 00007000 fe:00 10234368    /usr/bin/sleep
556ac2f81000-556ac2fa2000 rw-p 00000000 00:00 0           [heap]
7fe4dea00000-7fe4ded42000 r--p 00000000 fe:00 10321904    /usr/lib/locale/locale-archive
7fe4deefc000-7fe4deeff000 rw-p 00000000 00:00 0
7fe4deeff000-7fe4def21000 r--p 00000000 fe:00 10226583    /usr/lib/libc.so.6
7fe4def21000-7fe4df07e000 r-xp 00022000 fe:00 10226583    /usr/lib/libc.so.6
7fe4df07e000-7fe4df0d6000 r--p 0017f000 fe:00 10226583    /usr/lib/libc.so.6
7fe4df0d6000-7fe4df0da000 r--p 001d6000 fe:00 10226583    /usr/lib/libc.so.6
7fe4df0da000-7fe4df0dc000 rw-p 001da000 fe:00 10226583    /usr/lib/libc.so.6
7fe4df0dc000-7fe4df0eb000 rw-p 00000000 00:00 0
7fe4df11e000-7fe4df11f000 r--p 00000000 fe:00 10226556    /usr/lib/ld-linux-x86-64.so.2
7fe4df11f000-7fe4df145000 r-xp 00001000 fe:00 10226556    /usr/lib/ld-linux-x86-64.so.2
7fe4df145000-7fe4df14f000 r--p 00027000 fe:00 10226556    /usr/lib/ld-linux-x86-64.so.2
7fe4df14f000-7fe4df151000 r--p 00031000 fe:00 10226556    /usr/lib/ld-linux-x86-64.so.2
7fe4df151000-7fe4df153000 rw-p 00033000 fe:00 10226556    /usr/lib/ld-linux-x86-64.so.2
7ffe3da15000-7ffe3da36000 rw-p 00000000 00:00 0           [stack]
7ffe3da73000-7ffe3da77000 r--p 00000000 00:00 0           [vvar]
7ffe3da77000-7ffe3da79000 r-xp 00000000 00:00 0           [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0   [vsyscall]

Randbemerkungen: Sofern ich die Ausgabe von strace sleep 30 richtig lese, wurde [heap] hier mit brk verwaltet. Die beiden anonymen Segmente gehen höchstwahrscheinlich auf das Konto des Laufzeit-Linkers (hier ld-linux-x86-64.so.2), der die Programmbibliotheken (hier nur libc.so.6) in den Prozess lädt.

Um das zu bestätigen, habe ich dann ~~mal schnell~~ ein minimales Programm gebaut, dass ausschließlich sleep gefolgt von exit macht, und definitiv gar nichts anderes. Ich war in der Tat erfolgreich:

$ strace ./target/release/minimal-memory-maps
execve("./target/release/minimal-memory-maps", ["./target/release/minimal-memory-"...], 0x7ffd0c104b00 /* 67 vars */) = 0
nanosleep({tv_sec=10, tv_nsec=0}, 0x7ffdaa084800) = 0
exit(0)                                 = ?
+++ exited with 0 +++

Und dieses Programm hat nicht mal einen Heap, sondern nur den Stack und die Kernel-Schnittstellen:

$ cat /proc/$(pidof minimal-memory-maps)/maps
# address                perms offset   dev   inode       pathname
00400000-00401000         rwxp 00000000 fe:00 9309336     .../target/release/minimal-memory-maps
7ffdaa066000-7ffdaa087000 rw-p 00000000 00:00 0           [stack]
7ffdaa0ea000-7ffdaa0ee000 r--p 00000000 00:00 0           [vvar]
7ffdaa0ee000-7ffdaa0f0000 r-xp 00000000 00:00 0           [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0   [vsyscall]

Hier sieht man übrigens schön, dass ich mein Programm nicht mit PIC kompiliert habe, sodass für die Programmdatei selber keine ASLR vorgenommen werden konnte.

Der Vollständigkeit halber dokumentiere ich hier noch den Code, um mein Testprogramm zu reproduzieren. Der Code funktioniert nur auf Linux und x86-64. Und selbst da habe ich irgendwas nicht ganz richtig gemacht: Das Programm funktioniert nur, wenn man dem Compiler Optimierungen verbietet (?!?). Trotzdem ein Shoutout an diesen Blogartikel und diesen anderen Blogartikel, mit deren Hilfe ich das Kompilieren ohne libc und main zumindest hinreichend weit ans Laufen bekommen habe.

$ cat Makefile
build:
    RUSTFLAGS="-Copt-level=0 -Ctarget-cpu=native -Clink-args=-nostartfiles -Clink-args=-Wl,-n,-N,--no-dynamic-linker" cargo build --release

$ cat Cargo.toml
[package]
name = "minimal-memory-maps"
version = "0.1.0"
edition = "2021"
[profile.dev]
panic = "abort"
[profile.release]
panic = "abort"

$ cat src/main.rs
#![no_std]
#![no_main]
use core::arch::asm;

#[repr(C)]
struct Timespec {
    pub tv_sec: i64,
    pub tv_nsec: i64,
}

const NR_NANOSLEEP: usize = 35;
const NR_EXIT: usize = 60;

#[no_mangle]
pub extern "C" fn _start() -> ! {
    let req = Timespec { tv_sec: 10, tv_nsec: 0 };
    let mut resp = Timespec { tv_sec: 0, tv_nsec: 0 };
    unsafe {
        // nanosleep(&req, &mut resp)
        let req_ptr = (&req as *const Timespec) as usize;
        let resp_ptr = (&mut resp as *mut Timespec) as usize;
        let ret: usize;
        asm!(
            "syscall",
            inout("rax") NR_NANOSLEEP => ret,
            in("rdi") req_ptr,
            in("rsi") resp_ptr,
            out("rcx") _,
            out("r11") _,
        );
        let exit_code = if ret == 0 { 0 } else { 1 };
        // exit(0)
        asm!(
            "syscall",
            in("rax") NR_EXIT,
            in("rdi") exit_code,
            options(noreturn)
        )
    }
}

#[panic_handler]
fn my_panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

STP044: Zufall

Thu, 28 Sep 2023 20:30:00 GMT

Wir befassen uns unter anderem mit der Erstellung, Bewertung und dem Verbrauch von Zufall. Außerdem in dieser Folge: Quantenmechanik, wildes Tastendrücken und Schiffe versenken.

Shownotes

Wir haben ein Errata zu STP019. Alex schreibt:

DMA kenne ich anders, nicht das der Prozess direkt über die MMU auf ein Peripheriegerät durchgreift, sondern dass ein Peripheriegerät ohne Beteiligung der CPU Daten vom/zum Hauptspeicher übertragen kann. Man muss dem Kernel allerdings beim Reservieren von Speicher für DMA sagen, dass das ein DMA Buffer sein soll, weil DMA selbst nicht über die MMU läuft sondern vom Peripheriegerät direkt von/zur physikalischen Adresse. Den eigentlichen Transfer zwischen Buffer und Peripherie muss man dann aber per Software entsprechend aktivieren.

Xyrill antwortet: Ja, stimmt. Nun zur eigentlichen Folge:

Intro-Intro: in Referenz auf den klassischen Dilbert-Cartoon, den man zum Beispiel hier sieht
Warum sind hochwertige Zufallszahlen wichtig?
- siehe STP043: Erzeugung eines RSA-Schlüsselpaars benötigt zwei große und geheime Primzahlen
- geheim = niemand anders kann es raten = zufällig
- oder zumindest von Zufall nicht zu unterscheiden (Pseudozufall)
Was ist "guter" Zufall?
- erstaunlich schwer zu definieren
- vielleicht Periodenlänge (Dauer, bis sich die Zahlenfolge wiederholt)
- vielleicht Gleichverteilung der Auftrittshäufigkeit von Teilfolgen (jede einstellige/zweistellige/dreistellige/etc. Zahl sollte gleich oft in der Folge vorkommen)
- Problem: die Folge "2236067977499789805051478..." ist nach all diesen Maßstäben guter Zufall – bis man bemerkt, dass das die Dezimalstellen der Quadratwurzel von 5 sind
- guter (aber unpraktikabler) Test: hohe Kolmogorow-Komplexität (siehe STP025)
- Errata: Beim Nachhören ist mir aufgefallen, dass die Kolmogorow-Komplexität eines Pseudozufallszahlengenerators nie besonders groß sein kann, da der Zufallszahlengenerator ja gerade ein Programm ist, was die entsprechende Zahlenfolge erzeugen kann. Das ist kein praktisches Problem, da das Programm im Kolmogorow-Sinne auch die Startwerte des Zufallszahlengenerators umfassen müsste, die aber gerade geheim sind.
"echter" Zufall kommt aus physikalischen Zufallszahlengeneratoren (Hardware-RNG)
- z.B. thermisches Rauschen eines elektrischen Widerstandes
- z.B. radioaktive Zerfallsvorgänge
- z.B. atmosphärisches Rauschen (Empfang auf einem Frequenzband, auf dem keiner sendet)
- z.B. Abfilmen eines Aquariums :)
- siehe auch: Würfeln, Lottozahlen
- Probleme: nicht in jedem Computer verfügbar, pro Zeiteinheit begrenzte Menge von Zufall
- Idee: Erzeugung beliebiger Mengen von Pseudozufall aus einem festen Algorithmus
Beispiel: Linearer Kongruenzgenerator
- Parameter: geheime Ganzzahlen a, b, m; Startwert y
- Erzeugung einer Folge von Pseudozufallszahlen durch die Formel y' = (a * y + b) mod m
- Problem: bereits aus wenigen aufeinander folgenden y-Werten kann man auf die geheimen Zahlen zurückschließen (Ansatz vergleichbar mit Kryptoanalyse)
- in besseren Pseudozufallszahlengeneratoren wird nach jedem Schritt nur ein kleiner Teil des Zustands herausgegeben, um Analyse zu erschweren
- Anwendungsbereich für einfache Pseudozufallszahlengeneratoren: nicht sicherheitsrelevanter Pseudozufall, z.B. Ereignisse in Computerspielen oder Randomisierung von automatisierten Tests (hier kann Reproduzierbarkeit aus einem Startwert für spätere Nachvollziehung hilfreich sein)
für sicherheitsrelevante Anwendungen: Kryptografisch sichere Zufallszahlengeneratoren
- Beispielidee: mit einem Hardware-RNG ein paar Bytes als Startwerte erzeugen, wiederholt mit AES-CTR (siehe STP043) verschlüsseln und die verschlüsselten Bits (oder Teile davon) als Ausgabe nehmen
- wenn man keinen Hardware-RNG hat, kann man Zufallsbits auch aus Beobachtung des normalen Betriebs extrahieren (z.B. Mikrosekundenbruchteile der Zeitstempel von Ereignissen wie Tastaturdrücken oder dem Empfang von Datenpaketen übers Netzwerk)
- unter Unix: /dev/random vs. /dev/urandom ; ist aber unter Linux mittlerweile so gut wie synonym (siehe auch); Probleme nur beim Systemstart, wenn noch nicht genug Entropie vorliegt (siehe auch: haveged, VirtIO RNG, systemd-random-seed.service)
im Gespräch erwähnt:
- Video: "How we solved the worst minigame in Zelda's history" (Errata: Xyrill hatte im Gespräch behauptet, dass das Video von Lowest Percent sei. Es ist aber von Linkus7.)

STP043: Kryptografische Primitiven

Thu, 07 Sep 2023 18:50:00 GMT

Im zweiten Teil unserer Reihe über Kryptografie besehen wir uns einzelne Klassen von Bausteinen, welche dann zu Verschlüsselungsprotokollen zusammengesetzt werden können.

Shownotes

Rückblick zu STP041
- Kryptografische Systeme dienen dem Erreichen der vier Schutzziele (Vertraulichkeit, Integrität, Authentizität, Verbindlichkeit)
- Implementierung vollständiger Kryptosysteme braucht Primitiven (Grundbausteine)
- heute: Vorstellung grundlegender Klassen von Primitiven
Symmetrische Verschlüsselung
- Schritt 1: Klartext (Plaintext) + Schlüssel (Key) -> Geheimtext (Ciphertext)
- Schritt 2: Geheimtext + selber Schlüssel -> Klartext
- üblicherweise als Blockchiffre mit Beschränkung des Klartexts auf eine Blockgröße von z.B. 128 oder 256 Bits, übliche Schlüsselgrößen ähnlich groß
- zwei Probleme:
  1. Wie verschlüsselt man mehr als einen Block?
  2. Wie einigt man sich auf einen gemeinsamen Schlüssel, ohne dass Beobachter den Schlüssel abgreifen können?
zu Problem 1: Erweiterung der Blockchiffre zu einem Stromchiffre mittels eines geeigneten Betriebsmodus
- Datenstrom wird in einzelne Blöcke der gewünschten Größe zerteilt; Betriebsmodus beschreibt dann die Anwendung des Blockchiffre auf die Folge von Blöcken
- einfachster Betriebsmodus ist ECB (Electronic Codebook): der Blockchiffre wird auf jeden Block komplett separat angewendet -> offensichtliche Probleme (siehe Bild im verlinkten Abschnitt)
- bei den meisten modernen Betriebsmodi werden meist Daten aus dem aktuellen Blockchiffre in den nächsten Block übertragen, um die Analyse des Geheimtextes zu erschweren -> Problem: schwer parallelisierbar, Lesezugriff nur sequentiell
- CTR-Betriebsmodus (Counter): jeder Block wird beim Verschlüsseln mit einem Zähler kombiniert, damit sich keine wiederkehrenden Muster wie bei ECB ergeben -> Vorteil: wahlfreier Schreib- und Lesezugriff möglich (interessant für Festplattenverschlüsselung)
- siehe unten: Beispiel für die Geschwindigkeit moderner Stromchiffern insb. mit Hardwareunterstützung

$ cryptsetup benchmark
...
#     Algorithm |       Key |      Encryption |      Decryption
...
        aes-xts        512b      3547,4 MiB/s      3540,4 MiB/s
    serpent-xts        512b       742,7 MiB/s       729,4 MiB/s
    twofish-xts        512b       398,9 MiB/s       404,8 MiB/s

zu Problem 2 (Einigung auf einen gemeinsamen Schlüssel) zwei Ansätze:
1. Schlüsselaustausch-Protokolle wie Diffie-Hellman
2. asymmetrische Verschlüsselung
Asymmetrische Verschlüsselung
- statt einem einzelnen Schlüssel ein Schlüsselpaar
  - wir haben keine gute Bildmetapher dazu; Xyrills Vorschlag: zwei Ratschen; eine dreht nur nach rechts und eine nur nach links
- Schritt 1: Klartext + öffentlicher Schlüssel -> Geheimtext
- Schritt 2: Geheimtext + privater Schlüssel -> Klartext
- Beispiel RSA:
  - Grundgeheimnis sind zwei sehr große Primzahlen (p und q, jeweils z.B. 500 Dezimalstellen)
  - aus dem Produkt dieser Primzahlen (N = p * q) werden zwei weitere Zahlen (d und e) mittels günstiger Rechenoperationen abgeleitet
  - dann ist der öffentliche Schlüssel das Zahlenpaar d,N und der private Schlüssel das Zahlenpaar e,N
  - Ableitung des privaten aus dem öffentlichen Schlüssel erfordert Primzahlfaktorisierung von N, was extrem teuer ist (siehe Beispiel unten)
- Problem 1 teilweise gelöst: Empfänger muss nur seinen öffentlichen Schlüssel offenbaren, der kein Geheimnis enthält
- Problem 2 ungelöst: auch asymmetrische Verschlüsselung arbeitet nur pro Block

$ time factor 1350918345091284620469824069824602946802496824562049682046982406982406980
1350918345091284620469824069824602946802496824562049682046982406982406980: 2 2 3 5 7 193 941 5077 3488395463852632669275489205712092360621005476304268749586169
factor   1,92s user 0,00s system 99% cpu 1,926 total
$ time factor 1350918345091284620469824069824602946802496824562049682046982406982406981
1350918345091284620469824069824602946802496824562049682046982406982406981: 11 3931 5242879872157046321 5958863859256362497309559371496021100634736129421
factor   462,19s user 0,01s system 99% cpu 7:43,24 total

neues Problem: asymmetrische Verfahren sind sehr viel rechenaufwändiger als symmetrische Verfahren -> hybrides Kryptosystem
- asymmetrische Verschlüsselung wird nur zum Austausch eines symmetrischen Schlüssels verwendet
- Beispiel "verschlüsselte E-Mail": Alice hat den öffentlichen Schlüssel O, Bob hat den privaten Schlüssel P dazu
  - Alice erstellt die Nachricht N im Klartext
  - Alice erzeugt einen zufälligen symmetrischen Schlüssel S
  - Alice verschlüsselt N mit S und einem Stromchiffre zu N'
  - Alice verschlüsselt S mit O zu S'
  - Alice schickt N' und S' an Bob
  - Bob entschlüsselt S' mit P zu S
  - Bob entschlüsselt N' mit S zu N
zweite Anwendung von asymmetrischer Kryptografie: Signaturen
- Verschlüsselung: vorwärts mit dem öffentlichen Schlüssel, rückwärts mit dem privaten Schlüssel
- bei Signierung umgekehrt: vorwärts mit dem privaten Schlüssel (Erzeugung), rückwärts mit dem öffentlichen Schlüssel (Überprüfung)
- im Detail: erst Komprimierung der zu signierenden Daten auf eine feste Größe mittels einer Hashfunktion (siehe STP004), dann Verschlüsselung dieses Hash-Wertes mit dem privaten Schlüssel
- Überprüfung: Berechnung des Hashes auf dieselbe Weise, Vergleich mit entschlüsselter Signatur
noch eine Primitive zum Schluss: Geheimnisteilung
- Problem: Ein Geheimnis soll in N Teile so aufgeteilt werden, dass M beliebige Teile zum Entschlüsseln genutzt werden können.
- Beispiel: Backup des Passwortspeichers in 5 Fragmente aufteilen und bei 5 Freunden so einlagern, dass man später nur 3 beliebige Fragmente zum Wiederherstellen braucht
- Illustrationen: Visuelle Kryptografie, Blakley-Schema
im Gespräch erwähnt
- Anerzählt Podcast zu AES
- Whitfield Diffie und Moxie Marlinspike und eine Flasche Whiskey auf der Bühne

STP042: Cursed Computer Iceberg Meme

Thu, 17 Aug 2023 21:45:00 GMT

In der Episode mit dieser Nummer werden wir aus Günden vom normalen Programm abweichen. Während diese Gründe für den durchschnittlichen {Nerd|Geek} gut verständlich sein dürften, werden diese für alle Anderen ausführlich erklärt. Xyrill greift zu diesem Anlass völlig wahllos einige lustige und/oder deprimirende Aspekte aus dem Eisberg der Computerei heraus.

Shownotes

Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen.

– Douglas Adams, Das Restaurant am Ende des Universums. Ullstein, 1994. ISBN 3-548-22492-X. Deutsche Übersetzung von Benjamin Schwarz. Seite 11.

Vorbemerkung: Die Zahl 42
- Per Anhalter durch die Galaxis von Douglas Adams
- in der Nerdkultur einflussreich durch eine Kombination aus klassisch britischem schwarzem Humor und einprägsam idiosynkratischen Vignetten
- 42 = die Antwort auf die endgültige Frage nach dem Leben, dem Universum und dem ganzen Rest
- mehr zu Douglas Adams in der Freak Show, Folge 266 (siehe Kapitelmarke "Douglas Adams")
Was könnte dieser Referenz passen? Vielleicht das Cursed Computer Iceberg Meme
- Eisberg-Meme: möglicherweise inspiriert von Freuds Vorstellung des Bewusstseins als ein Eisberg, von dem der größte Teil (das Unterbewusstsein) unter Wasser liegt und nicht sichtbar ist
- Xyrill findet die Kategorieneinteilung etwas merkwürdig; wir werden auf fast allen Ebenen Sachen finden, die schon in vergangenen Folgen besprochen wurden
- aus Zeitgründen nur eine kleine Auswahl, analog zu STP035
"Above the Iceberg" - Oberhalb des Eisberges
- bereits besprochen:
  - Y2K, Jahr-2038-Bug: siehe STP016 bzw. STP037
  - Brainfuck: siehe STP033
  - TCP/IP über Brieftaube: siehe STP035
  - Heisenbugs: siehe STP038
- Bogosort: der beste Sortieralgorithmus (siehe auch STP029)
- Sleepsort: der parallelste Sortieralgorithmus
- DOOM auf einem Toaster: eine wichtige Erinnerung, dass diese ganzen "smarten" Geräte vollwertige Computer sind
  - siehe auch: Wahlcomputer-Debatte (dazu passend Pentacast 55 und CRE039 der NEDAP-Hack)
- "All web browsers pretend to be each other"
  - Beispiel: aktueller Edge meldet sich als User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 Edg/113.0.1774.50
"On the Iceberg" - Auf dem Eisberg
- bereits besprochen:
  - Gene wurden umbenannt wegen Excel: siehe STP012
  - Fast Inverse Square Root: siehe STP037
- aus Versehen turingvollständig
  - Turing-Vollständigkeit heißt, dass ein System alle berechenbaren Funktionen berechnen kann (gegeben genug Zeit und Speicherplatz)
  - überraschend wenig Voraussetzungen (siehe Brainfuck), im wesentlichen reicht musterbasierte Textersetzung und echte Rekursion
  - Implikationen für den Erfolg von Sicherheitsmaßnahmen wie Sandboxing (siehe STP023)
- Self-Hosting Languages
  - nicht das gleiche Bootstrapping wie in STP020
  - siehe auch "Trusting Trust" weiter unten
- "Wir können keine E-Mail weiter als 500 Meilen schicken"
  - Techniker macht ein Serverupdate, bei dem aus Versehen der Mailserver durch eine ältere Version ersetzt wird
  - alter Mailserver versteht Teile der Konfigurationsdatei nicht, nimmt für alle unbekannten Sachen Null an
  - Null erlaubte Wartezeit beim Verbindungsaufbau ergibt ein reales Zeitfenster von etwa 3ms; in Lichtgeschwindigkeit etwas über 500 Meilen
"Below the Water" - Unter der Wasserlinie
- bereits besprochen:
  - FDIV-Bug: siehe STP037
  - CAP-Theorem: siehe STP027
- Reflections on Trusting Trust
- Malbolge: die frustrierendste Programmiersprache der Welt
- Null Island: ein Insider-Witz unter Geografen
  - Die 0,0-Boje bei OpenStreetMap
Wir haben's trotz stark beschränkter Auswahl nicht mal bis zur Hälfte des Eisbergs geschafft... wir brauchen wohl mal einen zweiten Teil hiervon. :) Aber Xyrill sah noch etwas Bekanntes an der unteren Spitze des Eisbergs:

if you ever code something that "feels like a hack but it works," just remember that a CPU is literally a rock that we tricked into thinking

not to oversimplify: first you have to flatten the rock and put lightning inside it

– @daisyowl auf Twitter

STP041: Grundlagen der Kryptografie

Thu, 27 Jul 2023 16:30:00 GMT

Diesmal gibt es den Einstieg in ein Thema, vor dem wir uns schon eine Weile gedrückt haben. Dieses heutzutage essenzielle und gleichzeitug subtile Gebiet werden wir auch aufgrund seiner Tiefe über mehrere Episoden aufteilen.

Shownotes

Definition laut Wiktionary:

"Kryptografie", aus griechisch κρυπτός (kryptos) „verborgen“ und -γραφία (graphia), zum Verb γράφειν (graphein) „schreiben“ gebildet

Informatik, Mathematik: Wissenschaft der Verschlüsselung von Informationen

Psychologie: absichtslos entstandene Kritzelzeichnung eines Erwachsenen

Warum Verschlüsselung? Vier Schutzziele
- Vertraulichkeit: Eine Nachricht soll nur von berechtigten Personen oder Maschinen gelesen werden dürfen.
- Integrität: Nachrichten sollen nachweislich vollständig und unverändert sein.
- Authentizität: Die Nachricht soll ihrem tatsächlichen Absender zugeordnet werden können.
- Verbindlichkeit: Der Absender einer Nachricht soll seine Urheberschaft nicht abstreiten können.
- Beispiele aus der analogen Welt: Verträge, Geheimnisträger:innen (Anwält:innen, Geistliche, Mediziner:innen, etc.)
- "Ich hab doch nichts zu verbergen" -> Unterschied zwischen "privat" und "geheim"
Verschlüsselung im engeren Sinne: Übertragung eines Klartext (Plaintext) in einen Geheimtext (Ciphertext) und später wieder zurück
- Beispiel für (historisch signifikanten) Ciphertext: Zimmermann-Depesche
- die Relation zwischen Klartext und Ciphertext wird vermittelt durch einen Schlüssel, also eine Folge von Bits fester Länge (je nach Verfahren zwischen 128 Bits bis zu 4096 Bits)
Grundbausteine eines Kryptosystems: Primitiven
- Beispiel für eine Klasse von Primitiven: symmetrische Verschlüsselung (Funktionsprinzip: Klartext + Schlüssel -> Geheimtext, Geheimtext + selber Schlüssel -> Klartext)
- Qualitätsmaßstab: Angreifer mit Zugriff auf den Geheimtext soll nicht auf den Klartext schließen können
- immer möglich: Angriff nach Brute-Force-Methode, also Durchprobieren aller möglichen Schlüssel (Beispiel: Zahlenschloss mit vierstelliger PIN)
- praktischer Maßstab: Brechen einer Verschlüsselung soll nicht weniger als 2^100 Rechenoperationen erfordern (2^100 = 1.267... * 10^30)
- Rechenbeispiel: Xyrills Grafikkarte kann im Idealfall etwa 64 TFLOPS liefern, also 64 Trillionen Rechenoperationen pro Sekunde; bei dieser Geschwindigkeit benötigen 2^100 Rechenoperationen etwa 627 Millionen Jahre
- Seitenleiste: Quantencomputer sind nicht automatisch Game Over, aber es gibt aktive Forschung an Post-Quanten-Kryptografie
Primitiven alleine machen noch kein vollständiges Kryptosystem
- die tollste Festplattenverschlüsselung hilft nicht, wenn ich das Passwort am Monitor kleben habe :)
- besonders spannend: Seitenkanal-Angriffe
- Beispiel: je nach Bitfolge im Schlüssel dauert das Entschlüsseln unterschiedlich lang oder braucht unterschiedlich viel Energie oder erzeugt unterschiedlich viel Strahlung
- Beispiel: Login mit Benutzername und Passwort sollte sich bei falschem Passwort genauso verhalten wie bei nicht vorhandenem Benutzerkonto
Vorschau
- nächstes Mal (STP042) was ganz anderes... aber dann!
- STP043: Überblick über Klassen von Primitiven (Fokus auf das allgemeine Verhalten anstatt auf konkrete mathematische Konstruktion)
- STP044: Starke Kryptografie ist kein Zufall... oder doch?
im Gespräch erwähnt

STP040: Urheberrecht bei Programmen

Thu, 06 Jul 2023 20:40:00 GMT

In dieser Episode soll es darum gehen, wer, wann, wie ein Urheberrecht erhält und es nutzen kann. Im Zweifel sogar postmortal. Oder eben nicht. Auch geht es darum, wie lange ein Urheberrecht aus wissenschaftlicher Sicht sinnvoll ist. Und sogar Hitler hat es in die Sendung geschafft.

Shownotes

Programmcode ist ein immaterielles Wirtschaftsgut -> jeder Programmierer sollte ein Grundverständnis für Immaterialgüterrecht haben (neben Urheberrecht auch Patentrecht, Markenrecht, etc.)
obligatorische Vorbemerkungen
- Wir sind keine Rechtsanwälte. Das hier ist keine Rechtsberatung.
- Fokus auf das deutsche Recht (insbesondere nicht auf das Copyright der englischen Rechtstradition)
- insbesondere Fokus auf das UrhG, daneben noch zum Beispiel das KunstUrhG (Recht am eigenen Bild) oder das ArbnErfG (Arbeitnehmererfindungen)
erste Facette: Urheberpersönlichkeitsrecht
- § 12 UrhG: "Der Urheber hat das Recht zu bestimmen, ob und wie sein Werk zu veröffentlichen ist."
- § 13 UrhG: "Der Urheber hat das Recht auf Anerkennung seiner Urheberschaft am Werk." (aber keine Pflicht)
- § 14 UrhG: "Der Urheber hat das Recht, eine Entstellung oder eine andere Beeinträchtigung seines Werkes zu verbieten, die geeignet ist, seine berechtigten geistigen oder persönlichen Interessen am Werk zu gefährden."
- im Allgemeinen nicht übertragbar, aber insb. für Computerprogramme § 69b UrhG: "Wird ein Computerprogramm von einem Arbeitnehmer in Wahrnehmung seiner Aufgaben oder nach den Anweisungen seines Arbeitgebers geschaffen, so ist ausschließlich der Arbeitgeber zur Ausübung aller vermögensrechtlichen Befugnisse an dem Computerprogramm berechtigt, sofern nichts anderes vereinbart ist."
zweite Facette: Verwertungsrecht in §§ 15 ff. UrhG
- Recht auf Vervielfältigung, Verbreitung, Ausstellung, Vortrag/Aufführung/Vorführung, Sendung, Bearbeitung/Umgestaltung, Verfilmung, etc.
- meistens Übertragung dieser Rechte, zum Beispiel bei Büchern auf Verlage oder bei Filmen auf Verleiher
Schranken des Urheberrechts: §§ 44a ff. UrhG
- Rechtspflege, Barrierefreiheit, Gebrauch bei religiösen Feierlichkeiten, Schulfunksendungen, Verbreitung öffentlicher Reden, Berichterstattung über Tagesereignisse, Zitate, Karikaturen/Parodien, Privatkopien
- insb. für Programme § 69e UrhG: "Die Zustimmung des Rechtsinhabers ist nicht erforderlich, wenn die Vervielfältigung des Codes oder die Übersetzung der Codeform [...] unerläßlich [sic] ist, um die erforderlichen Informationen zur Herstellung der Interoperabilität eines unabhängig geschaffenen Computerprogramms mit anderen Programmen zu erhalten, sofern folgende Bedingungen erfüllt sind: [...]"
Freie Software, Open-Source-Bewegung
- Urkonzept im englischsprachigen Copyright: Public Domain (willentliche Abtretung der Urheberrechte, im deutschen Urheberrecht nicht möglich)
- ab Beginn der Informatik: in der Forschung Behandlung von Programmcode wie wissenschaftliche Erkenntnisse, ohne Anwendung des Urheberrechts
- ab 1980er Jahre: Freie-Software-Bewegung -> subversive Nutzung des Copyright nicht zur Beschränkung, sondern zur Maximierung von Nutzbarkeit
- "Vier Grundfreiheiten": Use, Study, Share, Modify -> Copyleft-Modell (Urheber zwingt alle Nutzer, auch bei Folgenutzungen die vier Grundfreiheiten zu berücksichtigen)
- Gegenbewegung: "Open Source" -> schwächere Definition, quelloffene Software ohne Copyleft kann auch in unfreier Software verwendet werden
- Randbemerkung: diese Open-Source-Gemeinde hat bis auf den Namen nichts mit der OSINT-Community zu tun
praktischer Hinweis für Programmierer: Schaut auf eure SBOM!
- BOM = Bill of Material (zu deutsch: Stückliste/Materialliste)
- SBOM = Stückliste für Software (Welche Programme oder Programmbibliotheken werden als Teil meines Programms mit ausgeliefert?), Symbolbild
- Teil der SBOM sind die Lizenzinformationen der verwendeten Programme und Bibliotheken
- SBOM ist auch sonst eine gute Idee; kann man auch zum automatisierten Suchen nach Sicherheitslücken verwenden
netzpolitische Aspekte
- § 95a UrhG: der Kopierschutzparagraf, "Wirksame technische Maßnahmen zum Schutz eines [...] Werkes [...] dürfen ohne Zustimmung des Rechtsinhabers nicht umgangen werden, soweit [...] die Umgehung erfolgt, um den Zugang zu einem solchen Werk [oder dessen] Nutzung zu ermöglichen."
- § 64 UrhG: "Das Urheberrecht erlischt [im Allgemeinen] siebzig Jahre nach dem Tode des Urhebers."
  - Studie: Optimale Dauer des Urheberrechtsschutzes wäre 14 Jahre; Link zur Originalstudie
- § 44b UrhG: der Data-Mining-Paragraf, "Zulässig sind Vervielfältigungen von rechtmäßig zugänglichen Werken für das Text und Data Mining. Die Vervielfältigungen sind zu löschen, wenn sie für das Text und Data Mining nicht mehr erforderlich sind. [...] Ein Nutzungsvorbehalt bei online zugänglichen Werken ist nur dann wirksam, wenn er in maschinenlesbarer Form erfolgt."; siehe dazu auch Pentaradio vom August 2022
im Gespräch erwähnt
- GNU-Projekt
- Postmortales Persönlichkeitsrecht

STP039: Authentifizierung und Autorisierung

Thu, 15 Jun 2023 19:55:00 GMT

Die Frage, wer wir sind, beschäftigt nicht nur uns selbst, sondern auch alle Anbieter von Diensten aller Art, wenn sie mit Computern zu tun haben. Heute sprechen wir über die Mechanismen, die zur Feststellung einer Person oder ihrer Berechtigungen besonders im Netz verwendet werden.

Shownotes

grundsätzliche Begriffsklärung
- Authentifizierung: Nachweis einer behaupteten Eigenschaft einer Entität; hier: der Nachweis der Identität einer Person, eines Gerätes oder eines Prozesses ("Wer ist dieser Benutzer?")
- Autorisierung: die Einräumung von Rechten gegenüber einem interessierten Subjekt; hier: das initiale Zuweisen und das wiederholt einleitende Überprüfen von Zugriffsrechten ("Darf dieser Benutzer auf dieses Dokument zugreifen?")
- im englischen Sprachgebrauch "authentication" (AuthN) und "authorization" (AuthZ)
AuthN durch einen oder mehrere von drei wesentlichen Arten von Identitätsmerkmalen
- Wissen: etwas, dass ich weiß (Passwörter, PINs, etc.)
- Besitz: etwas, dass ich habe (Chipkarte, Lichtbildausweis, Mobiltelefon, PC, etc.)
- Inhärenz: etwas, dass ich bin (Fingerabdruck, Iris-Abbild, etc.) -> Achtung: Problematisch, weil nicht änderbar!
- Multifaktor-Authentifizierung: Wer eines der drei Merkmale gut angreifen kann, kann selten eins der anderen Merkmale gut angreifen.
schlechte Arten von Merkmalen
- Magnetstreifenkarte (Besitz-Merkmal): trivial kopierbar -> deswegen heute meist Chipkarten
  - Chipkarten sind kleine Computer, die sich per Challenge-Response authentisieren können
  - siehe zum Beispiel ChipTAN
- Code per SMS (Besitzfaktor): auf Telefonebene angreifbar durch Malware mit erschlichener SMS-Berechtigung, auf Netzwerkebene angreifbar durch Umleitung der SMS
  - als Besitzfaktor buchstäblich "besser als nichts"
  - besser ist eine Authentisierungs-App mit TOTP
- zu kreativen Angriffen auf Besitzmerkmale und Biometrie siehe die Vorträge von Starbug
Autorisierungs-Schemata
- früher meist Access Control Lists (ACL): jedes Datenobjekt hat eine Liste mit zugriffsberechtigten Benutzerkonten und Gruppen
- Beispiel ACL in Unix: Dateisystemeinträge haben rwx-Bits (Lesezugriff, Schreibzugriff, Ausführzugriff) jeweils für das besitzende Benutzerkonto, die besitzende Gruppe und alle Benutzerkonten
- heute meist Role-Based Access Control (RBAC) auf der Ebene von semantischen Operationen
- Beispiel RBAC in OpenStack: Benutzerkonten oder Benutzergruppen können Rollenzuweisungen erhalten; die Menge der zugewiesenen Rollen bestimmt, welche Aktionen ein Benutzer ausführen kann
Authentisierung im Webkontext: Single Sign-On (SSO) via SAML, OIDC
- Idee: Authentisierung bei einem zentralen Identitätsanbieter, dann Verwendung dieser festgestellten Identität in einem Zielsystem
- SSO könnte man auch mit LDAP haben, aber SAML/OIDC erlaubt eine Einschränkung, welche Identitätsdaten der autorisierende Dienst vom authentifizierenden Dienst erhält

STP038: Software-Tests

Thu, 25 May 2023 21:59:59 GMT

Nach der Episode über die Fehler, spechen wir heute darüber, wie man sie vermeidet. Wie nicht anders zu erwarten, ist auch dies ein Thema, bei dem reichhaltige Meinungsdiskurse geführt werden.

Shownotes

Warum testen? -> siehe STP037
Anforderungen an Tests
- reproduzierbar: nicht abhängig von unerwarteten äußeren Einflüssen oder menschlicher Intervention
- fokussiert: im Fehlerfall soll möglichst klar sein, wo das Problem liegt
- schnell: damit man beim Ändern des Systems schnelles Feedback bekommt (siehe auch XKCD 303)
- realitätsnah: überprüft eine Funktion, die der Benutzer so tatsächlich benötigt
manuelle Tests
- kostenintensiv: Online-Shooter braucht(e) 200 Tester (das Spiel erlaubt Matches mit bis zu 60 Teilnehmern)
- erfüllt von den obigen Anforderungen nur die Realitätsnähe
- wenn's geht, lieber automatisieren
- gängige Strategie: manuelle Tests zur Fehlersuche, im Zweifelsfall durch die Kunden ;) – dann Nachstellung des gefundenen Problems
automatisierte Tests am Beispiel der Testpyramide
- Unit Tests: Überprüfung einer einzelnen Komponente in Isolation
  - besonders wertvoll, wenn die Komponenten auf besonders reproduzierbare Weise arbeiten (zum Beispiel pure Berechnungen; Vorgänge, die nicht Netzwerkzugriff/Festplattenzugriff/etc. erfolgen)
  - Problem: es reicht nicht, wenn jede Komponente für sich genommen funktioniert, aber sie nicht zusammen passen
  - Bewertung: reproduzierbar, fokussiert, schnell, aber nicht realitätsnah
- Integration Tests: Überprüfung des Zusammenspiels mehrerer Komponenten eines Gesamtsystems
  - nach Möglichkeit Eingrenzung äußerer Faktoren, z.B. statt Kommunikation mehrerer Komponenten über ein reales Netzwerk Simulation einer Netzwerkstruktur im Programm oder mittels Containern/VMs (siehe STP023)
  - Bewertung: tendenziell weniger reproduzierbar, etwas langsamer, weniger fokussiert, aber realitätsnäher
- End-to-End-Tests (E2E): Überprüfung des Verhaltens eines Gesamtsystems
  - analog zu den manuellen Tests, aber nach festem Algorithmus
  - höchster Aufwand in der Umsetzung, siehe insbesondere UI-Tests mittels Headless Browser etc.
  - Bewertung: am wenigsten reproduzierbar (aufgrund der Vielzahl an Variablen), am unfokussiertesten, am langsamsten, aber am nächsten an der Realität
- allgemeine Empfehlung: ganz viele kleine Unit Tests und einige mittelgroße Integrationstests für die schnelle Feedbackschleife, dazu einige wenige große E2E-Tests für den Abgleich mit der Realität
alternative Teilung: Blackbox-Tests vs. Whitebox-Tests
- Blackbox: Umsetzung eines Tests ohne innere Kenntnis der Struktur des Systems, z.B. anhand einer Spezifikation
- Vorteil: ein Blackbox-Test durch ein anderes Team kann Missverständnisse des ursprünglichen Teams aufdecken
- Nachteil: kann nur E2E sein
die reine Lehre: Test Driven Development (Testgetriebene Entwicklung)
- neue Funktionalität darf man nur bauen, wenn es Testabdeckung dafür gibt
- erst fehlschlagenden Test schreiben; dann Funktionalität einbauen, sodass der Test erfolgreich durchläuft; dann aufräumen
- Xyrill macht lieber "Data Driven Development" und hat Bedenken
Kann man die Qualität eines Tests bewerten? -> Idee: Code Coverage
- Welcher Anteil des Programmcodes wird von meinem Test tatsächlich abgedeckt?
- Was heißt eigentlich "Anteil"?
  - Beispiel: if (a or b or c) { return "Kredit abgelehnt" } (einfach bei Zeilenabdeckung, schwierig bei Bedingungsabdeckung)
  - Beispiel: "Kommt ein Software-Tester in eine Bar."
- Problem: Goodharts Gesetz, "Sobald eine Metrik zu einem Ziel wird, hört sie auf, eine gute Metrik zu sein."
- Problem: für manche Zeilen sind Tests wichtiger als andere (wichtig für vertrackte Logik, weniger wichtig für Sofortabbruch bei unerwarteten Fehlern)
Tests muss man trotzdem noch schreiben. Kann man das wegautomatisieren?
- Statische Analyse: automatische Suche nach bedenklichen Mustern (z.B. Datei wurde zum Schreiben geöffnet, wird aber am Ende nicht geschlossen -> Risiko des Datenverlusts; z.B. Verwendung veralteter kryptografischer Primitiven)
- Fuzzing: anstatt eines Tests mit festen Werten ("bei Eingabe X wird Ausgabe Y erwartet") nur Vorgabe einer Struktur ("wenn hier ein Text reingesteckt wird, kommt da eine Zahl raus"), dann automatische Suche nach Absturzbedingungen
Machen Tests die Sache immer besser?
- Heisenbug: "ein Softwarefehler, der zu verschwinden oder sein Verhalten zu verändern scheint, wenn man versucht, ihn zu untersuchen"
im Gespräch erwähnt:
- ISO9001
- FG034 zu Werner Heisenberg

STP037: Berühmte Softwarefehler

Thu, 04 May 2023 15:45:00 GMT

Wir alle machen Fehler. So gut, so trivial. Wenn allerdings Elektronenrechner im Spiel sind, kann das durchaus kritisch werden. In manchen Fällen sogar tödlich.

Shownotes

Errata zu STP034 von Thomas aus Berlin:

Am Ende der Folge wundert sich ttimeless darüber, warum sin(pi) auf dem Taschenrechner immer ein Ergebnis von 0,0548... produziert. Du versuchst, das dann mit möglichen Ungenauigkeiten der Abbildung von pi zu erklären.

Ich glaube, die Antwort ist viel einfacher: In der normalen Einstellung DEG erwartet der Taschenrechner die Eingabe in Grad und sin(pi°) = 0,0548... ist damit auch korrekt. Stellt man den Taschenrechner auf RAD (Radiant), dann rechnet der Taschenrechner auch korrekt sin(pi) = 0.

"Off by One" ("um eins daneben")
- Diese Folge ist Nr. 37 und somit die 38. Folge dieses Podcasts!
- häufige Konvention in der IT: Nummerierung fängt bei Null an
  - In einer Liste mit 10 Elementen das vorderste den Index 0 und das hinterste den Index 9.
  - formal plausibel, da Null die erste natürliche Zahl ist (ansonsten ist ℕ unter Addition keine Gruppe; siehe EWD831)
  - technisch plausibel, da die Speicheradresse einer Liste für gewöhnlich die Speicheradresse des vordersten Elementes ist; dieses hat also einen Abstand von 0 zum Beginn der Liste
- siehe auch Zaunpfahlfehler
- Thema heute: Wie katastrophal können die Auswirkungen solcher kleinen Fehler sein?
mechanische Fehler: "First actual case of bug being found."
Überlauf: Ariane-Flug V88 (1996)
- erster Flug der Ariane 5
- Steuerungssoftware war von der Ariane 4 übernommen und nicht auf derart große Horizontalgeschwindigkeiten ausgelegt
- Überlauf bei Konvertierung von float64 in int16; aber bei dieser konkreten Variable keine Überlaufprüfung wegen Ressourcenknappheit
- größeres Motiv laut Untersuchungsbericht: in der Gefahrenabschätzung wurde nicht hinreichend berücksichtigt, dass die Software (und nicht nur die Hardware) fehlerhaft sein könnte
- Folge: erster großflächiger Einsatz von Fehlersuche mittels statischer Code-Analyse
Überlauf: Y2K Bug -> siehe STP016
Überlauf: Heartbleed (2014)
Drift: Dhahran Missile Incident (1991), siehe auch
- Hintergrund: 28 Amerikaner getötet durch Raketenbeschuss auf eine US-Basis in Saudi Arabien während des 1. Golfkriegs
- Fehler im Raketenabwehrsystem: aufgrund Rundungsfehler driftet die interne Uhr um einen Faktor von 0,00000095
- nach 100 Stunden Dauerbetrieb ist die Drift bei 0,34 Sekunden; entspricht bei Raketen mit Mach 4 einer Distanz von etwa 500 Metern
Spezifikation falsch gelesen (oder Kommunikationsproblem): Mars Climate Orbiter (1999)
- NASA hatte metrische Einheiten verwendet (Impuls in Newtonsekunden), die Navigationssoftware von Lockheed Martin hingegen imperiale Einheiten (Impuls in Pound-Force-Sekunden)
Clusterfuck: Therac-25 (1985-1987), unter anderem:
- ~~verteiltes~~ verstreutes System: fehlerhafte Synchronisation zwischen einem Messprozess und einem parallel arbeitenden Steuerprozess
- Benutzerführung: in bestimmten Situationen wurde nach der Eingabe neuer Daten der alte Datensatz weiterverwendet, obwohl die Benutzeroberfläche den neuen Datensatz anzeigte
- Überlauf: 8-Bit-Flag für die Anzeige der Notwendigkeit einer Sicherheitsprüfung konnte von 255 auf 0 überlaufen und dadurch die Prüfung überspringen
überfordert von Komplexität: Corrupted Blood (2005)
- vor COVID-19 eines der wichtigsten Studienobjekte für das Verbreitungsmuster einer Pandemie, inklusive Tiervektoren und asymptomatisch infektiösen Patienten
- ein bestimmter Bosskampf in "World of Warcraft" versieht Spielercharaktere mit einem negativen Statuseffekt, der sie langsam tötet und der auf naheliegende Charaktere ansteckend wirkt
- Spieler sollten mit diesem Statuseffekt den Bosskampf nicht verlassen können, aber die Reittiere der Spieler konnten es!
analog zu Copy-Paste-Fehler: Mariner 1 (1962)
- Programmcode wurde auf Papier geschrieben, dort wurde fehlerhafterweise mit "R" statt mit dem korrekten "R̅" (R mit Überstrich) gerechnet
Copy-Paste-Fehler: Pentium-FDIV-Bug
- Division von Fließkommazahlen (siehe STP009) beim Pentium verwendet einen Algorithmus, der zur Beschleunigung eine Tabelle von vorberechneten Werten verwendet
- fünf Einträge in dieser Tabelle wurden nicht richtig in das finale Chip-Design übernommen
- Ergebnis: bestimmte Divisionen liegen um einen Bruchteil eines ‰ daneben
- Rückrufaktion im Wert von über 400 Millionen $
- "Wie viele Intel-Mitarbeiter braucht man, um eine Glühbirne zu wechseln? 1,9999983256"
- im Gespräch erwähnt: Fast Inverse Square Root

STP036: LaTeX

Thu, 13 Apr 2023 16:35:00 GMT

Diesmal ist für ttimeless ein echtes Herzensthema an der Reihe. Dafür tritt man auch mal zum zweiten Aufnahmeversuch an. All das, um euch ein Textsatzpogramm nahezubringen, das im Kern 37 Jahre alt ist.

Shownotes

Zu dieser Sendung liegt ein Begleitdokument mit zugehörigen Quelldateien vor.

Ein Mann, der nicht den Regeln folgt: Donald Knuth
- The Art of Computer Programming – szenische Lesung des ersten Unterabschnittes
- Knuth vs. Email
  - "Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things."
Textsatz: "in einer Druckerei, einem Verlag o. Ä. der Arbeitsschritt, der durch ein technisches Verfahren aus einer Vorlage (einem Text, Grafiken, Bildern usw.) eine drucktaugliche Form herstellt"
- unter anderem unser Interesse: Formelsatz
- Blütezeit Anfang der 1900er Jahre parallel zur Formalisierung der Mathematik
- Tiefpunkt ab 1925 wegen rein auf Schreibmaschinen gesetzter Arbeiten
- "Dieser Entwicklung hat Donald Knuth ab 1977 mit der Entwicklung von TeX Einhalt geboten. Ab etwa 1994 gilt es als schlechter Stil, mathematische Texte nicht mit TeX zu setzen."
TeX und LaTeX
- Beispieldokument
- Kein WYSIWYG (What You See Is What You Get), stattdessen Beschreibung des Dokumentes durch Quelltext, dadurch sehr kompakt und leicht versionierbar
- Logische Auszeichnung ("Kapitelüberschrift" statt "Arial, fett, 24 Punkt"), dadurch Maschinenlesbarkeit (z.B. automatische Erstellung von Inhaltsverzeichnissen)
- Rechnerunabhängigkeit (heute gang und gäbe, damals revolutionär) sowohl der Software als auch der resultierenden Dokumente (ursprünglich DVI, heutzutage PDF)
- Rückwärtskompatibilität
- Open Source
- Anpassbarkeit, Programmierbarkeit (z.B. AMSLaTeX, MusicTeX, TikZ, Beamer)
- professionelles Aussehen entsprechend den Grundsätzen der Typografie (KOMA-Script!)
im Gespräch erwähnt:

STP035: Aprilscherz-RFCs

Sat, 01 Apr 2023 00:00:00 GMT

April, April! Ha, erwischt. Hier eine Sonderfolge mit vergnüglichen RFCs, die einen niederschwelligen Einblick in technische Spezifikationen bieten. Viel Spass beim Hören und passt auf, ihr werdet alle gehirngewaschen.

Shownotes

vollständige Liste siehe Wikipedia
- wir präsentieren hier nur eine kleine Auswahl
RFC 1097 (von 1989): TELNET-Option "Unterschwellige Botschaft"
- zu TELNET siehe STP022
- "Die Nutzung von Hinweisbannern und Newslettern ist oft nicht ausreichend, um widerspenstige Nutzer zum Upgrade auf die neueste Telnet-Version zu bewegen. Manche Nutzer werden die selben veralteten Versionen noch Jahre weiterverwenden. [...] Diese Nutzer müssen auf sanfte Weise 'überredet' werden."
- Kontext: Wikipedia zu unterschwelligen Botschaften im Fernsehen
RFC 1149 (von 1990): IP-Übertragungen via Brieftaube
- gute Illustration des Netzwerk-Schichtenmodells (siehe STP005)
- 2001: Praxisversuch durch die Linux User Group im norwegischen Bergen
RFC 2100 (von 1997): "The naming of hosts"
- ein Gedicht zur Frage, was gute Namen für Computer sind
- siehe auch RFC 1178: "Choosing a name for your computer"
RFC 2324 (von 1998): Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
- ein früher Beitrag zur Heimautomatisierung aber für "Kaffee-mit-Milch-Trinker" eventuell mit Problemen behaftet
RFC 3514 (von 2003): "The Security Flag in the IPv4 Header" -böswillige Teilnehmer des Internets werden aufgefordert ein ensprechendes Bit im Header zu setzen
RFC 5514 (von 2009): "IPv6 over Social Networks"
- schon wieder das Netzwerk-Schichtenmodell: wenn etwas Bytes übertragen kann, kann es IP-Pakete übertragen
RFC 6919 (von 2013): Neue definierte Schlüsselwörter für Standard-Texte
- nimmt satirischen Bezug auf die Begriffsdefinitionen in RFC 2119
RFC 7168 (von 2014): Update für RFC2324 zur Zubereitung von Tee
- geht in besonderem Maße auch auf verschiedene Teesorten und feste Zuschlagstoffe ein
RFC 7511 (von 2015): Malerische Routen für IP-Pakete
- nimmt satirischen Bezug auf Routenplanungsoptionen in Navigationssystemen ("schnelle" vs. "spritsparende" vs. "malerische" Route)
- "In Zeiten von Green IT wird großer Aufwand getrieben, um den Energieverbrauch von Netzwerkgeräten und Computern zu reduzieren und damit die Umwelt zu schützen. Dieses Dokument beleuchtet Green IT aus einem anderen Winkel"
RFC 8140 (von 2017): Eine Galerie mit ASCII Art
- "Johannes Gutenberg entdeckte und patentierte ASCII und die dazu passende Schriftart 'Courier New' mit ihrer nunmehr berühmten "Zehn-Punkt"-Größe. Seither haben sich Kunsthandwerker darum bemüht, ihre Sicht der Welt in gedruckter Form abzubilden."
RFC 9225 (von 2022): "Software Defects Considered Harmful"
- "Handlungsempfehlungen: 1. Software-Autoren DÜRFEN KEINE Fehler einbauen. 2. Wenn Fehler eingebaut werden, MÜSSEN sie klar dokumentiert werden. [...] 5. Nehmen Sie an, dass externe Eingaben das Ergebnis von Fehlern sind. [...] 6. Genau genommen sollten sie auch annehmen, dass interne Eingaben das Ergebnis von Fehlern sind."
- Kontext: "Goto Considered Harmful" von 1968
- "Considered Harmful" ist ein Snowclone
Im Gespäch erwähnt:
- RFC-Podcast Episode 011

STP034: Compilerbau

Thu, 23 Mar 2023 22:59:00 GMT

In dieser Episode soll es detaillierter um Compiler gehen. Jene Programmme, die dafür zuständig sind, andere Programme zu erzeugen. Um es mit C3PO zu sagen: "... Wie pervers." :)

Shownotes

Compiler: wandelt eine Programmiersprache (siehe STP033) in eine andere Programmiersprache oder Maschinensprache (siehe STP011)
- insb. Erkennung und Abweisung fehlerhafter Konstrukte (z.B. 42 + 5 ist okay, aber 42 + "Test" nicht)
Unterbegriffe zu "Compiler"
- Interpreter: anstatt Erzeugung eines Zielcodes direkte Ausführung
- REPL: Interpreter für die interaktive Verwendung ("Read Evaluate Print Loop")
- JIT-Compiler: direkte Ausführung wie ein Interpreter, aber es wird echter Maschinencode erzeugt ("Just In Time")
- z.B. portable Programme: Compiler erzeugt Maschinencode für ein virtuelles Maschinenmodell, Laufzeitumgebung ist ein Interpreter oder JIT-Compiler für diesen Maschinencode -> analog dazu Frontend/Backend-Aufteilung innerhalb eines Compilers
Frontend: Umformen der Texteingabe in eine Datenstruktur, Prüfung dieser Struktur auf inhaltliche Korrektheit (maschinenunabhängig, aber sprachabhängig)
- lexikalische Analyse: Zerteilen des Eingabetextes in eine Folge von Tokens mittels regulärer Ausdrücke (siehe STP021; diese Vorstufe ist eine Optimierung, weil reguläre Ausdrücke schneller ausgewertet werden können)
- syntaktische Analyse: Umformen der Tokenliste in einen Syntaxbaum mittels eines kontextfreien Parsers (siehe Beispiel bei Wikipedia)
- semantische Analyse: Prüfen des Syntaxbaums auf inhaltliche Korrektheit, meist mittels Markierungen an jedem Knoten des Baums (z.B. Welchen Typ hat der hier berechnete Wert? Passen die Werte des Elternknotens bzw. des Kindknotens dazu? etc.)
- IR-Erzeugung: Umformung des Syntaxbaums in eine Intermediate Representation (IR), die sich für maschinenunabhängige Optimierung eignet
Fortsetzung des Beispiels aus Wikipedia (aber mit einer Eingabevariable y und Ausgabevariable x): mögliche IR für den Ausdruck x = y + (2 + 2) - sin(pi)

$1 = 2
$2 = $1 + $1
$3 = load %y
$4 = $3 + $2
$5 = pi
$6 = call sin($5)
$7 = $4 - $6
store %x, $7

Middleend: Optimierungsläufe auf IR (Auswahl)
- Statische Formelauswertung: z.B. oben statt $2 = $1 + $1 direkt $2 = 4
- Löschung von unerreichbarem Code: sehr einfach bei IR mit Static Single Assignment (SSA) wie im Beispiel
- Invariantenextraktion aus Schleifen: wenn z.B. für verschiedene Werte von x der Ausdruck sin(x) + cos(y) berechnet wird, so kann man cos(y) vor der Schleife ein einziges Mal berechnen und das Zwischenergebnis wiederverwenden
- Inlining: ist eine Funktion sehr kurz, kann es effizienter sein, einen Funktionsaufruf durch eine Kopie der Funktion zu ersetzen (insb. wenn dann weitere Optimierungen möglich werden)
Beispiel: optimierte Variante der IR von oben

$3 = load %y
$7 = $3 + 4
store %x, $7

Backend: Umwandlung der maschinenunabhängigen IR in tatsächlichen Maschinencode
- Codeauswahl: für die einzelnen Operationen Auswahl der besten Maschinenbefehle
  - je nach Optimierungsziel: Geschwindigkeit, Speicherverbrauch, Energieverbrauch, etc. (z.B. x * 3 kann je nach Maschinenarchitektur gewinnbringend durch x + x + x ersetzt werden)
  - schwieriger als gedacht wegen komplexen Befehlen (z.B. SIMD: Single Instruction Multiple Data)
- Registerzuweisung: nummerierte Register aus der IR ersetzen durch die tatsächlich in der Maschine verfügbaren Register
  - reduzierbar auf ein Graphenfärbungsproblem: Knoten = IR-Register, Kanten = gemeinsame Verwendung in Berechnungen, Farben = echte Register
- Scheduling: optimale Sortierung der einzelnen Maschinenbefehle (soweit umordenbar)
  - z.B. parallele Ausnutzung verschiedener Recheneinheiten in der CPU (für Ganzzahl- und Fließkommazahl-Operationen)
- maschinenabhängige Optimierungen (aus Zeitgründen hier nicht)

STP033: Programmiersprachen

Thu, 02 Mar 2023 18:05:00 GMT

In dieser Episode wird die Antwort auf die Frage geliefert, warum wir Dinge wie Programmiersprachen brauchen, und vor allem, warum so viele. Es werden mal wieder starke Meinungen geäußert und es gibt einen zweiten Prolog in der Mitte der Episode. :) Außerdem dabei: Linguisten, automatisierte Textilbearbeitung und unsichtbarer Programmcode.

Shownotes

Einordnung in das Sprachenuniversum
- Programmiersprachen sind formale Sprachen (d.h. ein Algorithmus kann in endlicher Zeit eindeutig entscheiden, ob ein gegebener Text Teil der Sprache ist) -> Rückbezug zu STP021
- Programmiersprachen sind kein Maschinencode (d.h. Programme in Bytefolgen, den ein Prozessor direkt ausführen kann) -> Rückbezug zu STP011
- Abwägung zwischen Lesbarkeit für den Menschen und Lesbarkeit für den Computer
- einfachste Form von Programmiersprachen: Maschinensprachen (stellen Maschinencode direkt lesbar dar)
Beispiel anhand einer frühen Anwendung von Programmierbarkeit: Weben/Stricken/Häkeln
- Maschinensprache: so etwas wie "zwei links, zwei rechts, zwei fallen lassen"
- Maschinencode = Lochkarten-Kette für einen Jacquard-Webstuhl
darstellendes Beispiel für moderne Maschinensprachen und Programmiersprachen: Fibonacci-Funktion
- interaktiv bei Godbolt
- reine Textform nachfolgend

unsigned int fibonacci(unsigned int x) {
    if (x == 0 || x == 1) {
        return x;
    }
    return fibonacci(x - 1) + fibonacci(x - 2);
}

fibonacci(unsigned int):
    push    rbp
    mov     rbp, rsp
    push    rbx
    sub     rsp, 24
    mov     DWORD PTR [rbp-20], edi
    cmp     DWORD PTR [rbp-20], 0
    je      .L2
    cmp     DWORD PTR [rbp-20], 1
    jne     .L3
.L2:
    mov     eax, DWORD PTR [rbp-20]
    jmp     .L4
.L3:
    mov     eax, DWORD PTR [rbp-20]
    sub     eax, 1
    mov     edi, eax
    call    fibonacci(unsigned int)
    mov     ebx, eax
    mov     eax, DWORD PTR [rbp-20]
    sub     eax, 2
    mov     edi, eax
    call    fibonacci(unsigned int)
    add     eax, ebx
.L4:
    mov     rbx, QWORD PTR [rbp-8]
    leave
    ret

Was unterscheidet hier die Programmiersprache von der Maschinensprache?
- Verwendung von benannten Variablen, um Werte zu halten
  - Maschinensprache: nur Speicheradressen und CPU-Register
- Variablen können feste Datentypen haben
  - Maschinensprache: alles nur Nullen und Einsen :)
- Kontrollfluss-Strukturen (Subprozeduren, Abzweigungen, Schleifen)
  - Maschinensprache: nur lineare Ausführung und Sprungbefehle
- allgemein:
  - bessere Lesbarkeit (immerhin kann Maschinensprache heutzutage auch Freitext-Kommentare)
  - Portabilität (Unabhängigkeit von Details einer bestimmten Maschinen-Architektur)
  - formale Strukturen, die Fehler vermeiden (z.B. Typprüfungen, Kollisionsvermeidung bei nebenläufigen Programmen)
Arten von Programmiersprachen ("Paradigma")
- imperative Programmierung: Programme als Folgen von Befehlen
- strukturierte Programmierung: Programme als ineinander verschachtelte Blöcke von Befehlsfolgen
- modulare Programmierung: Programme als Verbund logischer Einheiten aus Prozeduren und Datenstrukturen
- objektorientierte Programmierung: Programme als Verbund von datenhaltenden Objekten, die miteinander interagieren
- logische Programmierung: Programme als Verbund von logischen Aussagen und Ableitungsregeln (Beispiele in der Sprache Prolog; Xyrill hat eine Anekdote zu Prolog)
- funktionale Programmierung: Programme als Verbund von mathematischen Funktionen (insbesondere von Funktionen, die andere Funktionen als Werte nehmen)
  - Beispiel unten: Berechnung sämtlicher Primzahlen in der Sprache Haskell
- reaktive Programmierung: Programme als voneinander abhängige Berechnungen (Beispiel: Tabellenkalkulation, Webanwendungen mit React)

module Primes where

isPrime :: Int -> Bool
isPrime x = all (\y -> mod x y /= 0) $ takeWhile (\y -> y * y <= x) primes

primes :: [Int]
primes = 2 : filter isPrime [3..]

Exkurs: esoterische Programmiersprachen
- Brainfuck: eine der minimalsten turing-vollständigen Programmiersprache; nur 8 verschiedene Befehle
- Befunge: anschauliches Beispiel für das Konzept einer "virtuellen Maschine" im Kontext von Programmiersprachen
- Chef: viele esoterische Programmiersprachen sind vor allem clevere Textersetzung
Im Gespräch erwähnt
- Pentaradio 2022-12 zu Komplexität

STP032: Hochverfügbarer Softwarebetrieb

Thu, 09 Feb 2023 13:05:00 GMT

Die heutige Episode beschäftigt sich neben dem offensichtlichen Hauptthema auch mit Prozenten, deren Bedeutung bedacht sein sollte, und dem Verhalten guter Manager. Deshalb sei hiermit eine Politik-Triggerwarnung ausgesprochen... aber nur eine kleine.

Shownotes

Schlagwort: Site Reliability Engineering (SRE)
- Hauptziel: "Schaffung skalierbarer und hochzuverlässiger Softwaresysteme"
Grundkonzept: Service Level
- SLO (Service Level Objective): selbstgewählter Indikator soll bis zu einem bestimmten Grad an 100% herangeführt werden (z.B. Zeiten, zu denen der Dienst erreichbar ist; Anteil der Anfragen, die in weniger als 1 Sekunde beantwortet werden; Anteil der Anfragen, die erfolgreich beantwortet werden)
- SLA (Service Level Agreement): SLO, der mit dem Kunden vertraglich vereinbart ist
- Beispiel: 99% Verfügbarkeit = bis zu 3,65 Tage Ausfall; 99,9% = bis zu 8,77 Stunden; 99,99% = bis zu 52 Minuten; 99,999% = bis zu 5,2 Minuten
Problem: die Unbekannten in der Gleichung
- Known Unknowns (bekanntes Unwissen): ich weiß, dass ich etwas nicht weiß (z.B. wann meine Festplatte ausfallen wird)
- Unknown Unknowns (unbekanntes Unwissen): ich weiß nicht mal, dass da etwas ist, was ich nicht weiß (z.B. dass meine angebliche 30-TB-Festplatte in Wahrheit nur eine 32-GB-Speicherkarte in einem großen Gehäuse ist)
- siehe auch: zur Wortherkunft der Begriffsgruppe "(un)known (un)knowns"
strukturierter Einblick in Applikationen mittels Instrumentierung
- Logging: Ereignisse innerhalb der Applikation werden als textförmiger Bericht (Log) aus der Applikation ausgeleitet und in einem Log-System durchsuchbar gemacht
- Monitoring: Zustand der Applikation wird in Form von Messdaten quantifiziert, in einer Zeitseriendatenbank abgelegt und in Dashboards aufbereitet (Beispielbild); Messdaten entweder direkt aus der Applikation selbst oder durch ein Extraprogramm von außen erhoben
- Alarmierung: Menschen werden benachrichtigt, wenn ein bestimmter Messwert eine bestimmte Schwelle überschreitet (oder eine Überschreitung projiziert ist, z.B. "die Festplatte läuft gerade voll und in einer Stunde ist sie komplett voll")
strukturierte Herangehensweisen beim Durchführen von Änderungen
- Configuration as Code: Änderungen werden möglichst nie manuell vorgenommen, sondern es wird ein Programm geschrieben (bzw. die Konfiguration für jenes Program angepasst), das die Änderungen vornimmt; bei Problemen ist ein Zurückrollen auf den letzten funktionierenden Zustand möglich
- Continuous Integration (CI): Änderungen an Code und Konfiguration fließen in ein System, das automatisch standardisierte Tests ausführt, um die Änderung auf Fehler zu prüfen; bei Erfolg automatische Übernahme der vorgeschlagenen Änderung in den veröffentlichten Code-Stand
- Continuous Delivery (CD): automatisches oder stark automatisiertes Ausrollen von Änderungen an Code und Konfiguration von Testsystemen in Verifikationssysteme in Produktivsysteme
- Rolling Upgrade: bei Systemen mit mehreren gleichartigen Komponenten werden die Komponenten nacheinander durch die neue Version ersetzt, damit das Ausrollen für den Kunden unsichtbar ist und bei Fehlern frühzeitig gestopppt werden kann
- Canary Deployment: Ausrollen einer Änderung zunächst nur in einem kleinen Teil des Systems; bei Problemen ist nur der kleine Teil betroffen (siehe auch Ankündigungen der Form "diese Funktion ist zurzeit nur für ausgewählte Kunden verfügbar")
strukturierter Umgang mit Alarmen/Fehlern
- standardisierte Abläufe ("Playbooks") für Alarme
- Postmortem-Analyse mindestens nach signifikanten Fehlern (Was ist passiert? Was war der tatsächliche Grund? Was ist bei der Bekämpfung des Problems gut/schlecht gelaufen? Was können wir besser machen?)
- Fehlerkultur: Das Hauptziel soll nicht sein, einen Schuldigen zu finden, sondern das Problem möglichst schnell zu beheben und dann dafür zu sorgen, dass das Problem nie wieder auftritt.
- Parallelen zum Toyota-Produktionssystem
im Gespräch erwähnt (im Kontext des Gesetzesvorhabens zur Chatkontrolle):

STP031: Festplatten und Dateisysteme

Thu, 19 Jan 2023 20:00:00 GMT

Mit dieser Episode kehrt STP zum Ursprung zurück, denn das initiale Ereignis hatte ebenfalls mit Dateisystemen zu tun. Hier sprechen wir aber über deutlich mehr und auch andere Sachen. Darunter: Dinge, von denen Xyrill wenig bis keine Ahnung hat (physikalische Anschlüsse) und Dinge, von denen Xyrill deutlich mehr Ahnung hat (die Software dahinter und deren Verwendung). ttimeless raschelt derweil mit einer dicken Winterjacke.

Shownotes

blockbasierter Speicher ("Block Storage")
- Festplatten handeln immer nur in festen Einheiten (Blöcken)
- traditionellerweise 512 Byte, heutzutage 4 KiB
kurzer Überblick zur physikalischen Anbindungen blockbasierter Speicher
- USB (Universal Serial Bus): für externe Festplatten, CD-Laufwerke, *räusper* Mini-Raketenwerfer *räusper*, etc.
- SATA (Serial AT Attachment): für interne Festplatten, kabelgebundene Punkt-zu-Punkt-Verbindungen
- SAS (Serial Attached SCSI): für interne Festplatten, kabelgebundene Verbindungen auch mit Switching (mehrere Festplatten an einem Verteiler)
- NVMe (Non-Volatile Memory Express): für interne Festplatten, direkte Steckverbindung via PCI Express
- Warum alles immer seriell? Höhere Geschwindigkeiten = Synchronisierung immer schwieriger. Parallele Leitungen = Übersprechen/Interferenz = komplexe Kompensation notwendig bzw. bei flexiblen Systemen wie Kabeln nicht möglich.
Rückbezug zu STP012: "Dateisysteme sind eine besondere Form von Key-Value-Datenbank"; keine Datenbank im engeren Sinne:
- keine widerspruchsfreie Speicherung, da keine Beziehungen zwischen verschiedenen Dateien möglich
- keine Unterstützung für bedarfsgerechte Darstellungsformen; jede Datei hat genau ein Format
alternative Perspektive als Vergleich zum blockbasierten Speicher
- jede Datei ist ihr eigener "kleiner Massenspeicher"
- zusätzlich noch Metadaten (Dateiname, Erstelldatum, Zugriffsrechte, etc.)
- Dateisystem kümmert sich um die Zuteilung des tatsächlichen blockbasierten Speichers an die einzelnen Dateien
- Praxisbeispiel zur Zuteilung von Speicherplatz: Unix-Befehl du -h ("disk usage")
Dateisystem-Struktur unter unixoiden Betriebssystemen: mittels Inodes
- ein Inode enthält alle Metadaten zu einem bestimmten Dateisystemeintrag (einer Datei, einem Verzeichnis, einer Verknüpfung, etc.) sowie (bei normalen Dateien) einen Verweis auf den Speicherort der tatsächlichen Daten
- Größe eines Inodes: immer ein Vielfaches der Blockgröße (4 KiB, 8 KiB, etc.)
- bei sehr kleinen Dateien mitunter direktes Ablegen des Dateiinhaltes im Inode
- bei großen Dateien meist fragmentierter Inhalt: Ablage in mehreren separaten Stücken (wegen späterer Umschreibung oder wegen Platzmangel)
- Verzeichnisse: Inode mit einer Liste von Einträgen (Name + Inode-Verweis)
- Dateisystem = Inode-Liste + Dateiinhalte + Übersicht über noch freie Festplattenbereiche
"aktuelle" Entwicklungen in Dateisystemen
- Journaling (in NTFS seit 1993, in ext3 seit 2001): Transaktionen werden in einem separaten Festplattenbereich vorgemerkt, bevor sie tatsächlich ausgeführt werden; ermöglicht Abgeschlossenheit und Dauerhaftigkeit analog zum Write-Ahead-Log bei Datenbanken (siehe STP012), außerdem schnelleren Start nach Systemausfall (keine Komplettprüfung des Dateisystems nötig)
- Online-Defragmentierung bzw. optimierte Speicherzuteilung zur Vermeidung von Fragmentierung (aber: aktives Defragmentieren = mehr Schreibzyklen = mehr Abnutzung)
antiintuitive Schlussfolgerungen aus dieser Struktur
- "sicheres Löschen": einfaches Löschen einer Datei löscht nur den Inode, aber überschreibt nicht den Inhalt (selbst Überschreiben der Datei hilft nicht unbedingt, weil die neuen Daten vielleicht an einer anderen Stelle landen, oder weil die alten Daten trotzdem noch im Journal liegen)
- Löschen von im Verbrauch befindlichen Dateien: kein Problem, eine "geöffnete Datei" ist nur ein Verweis auf einen Inode; "Löschen der Datei" löscht nur den Verzeichnis-Eintrag; der Inode bleibt noch so lang bestehen, wie ein Prozess einen Verweis auf den Inode hält
- anders bei Windows: Verweis auf eine offene Datei blockiert das Löschen -> Konsequenzen für System-Updates
Exkurs 1: virtuelles Dateisystem
- bis hier: physikalische Perspektive (Welche Bits stehen tatsächlich auf der Platte?)
- jetzt: logische Perspektive (Was zeigt das Betriebssystem den Programmen?)
- Unix: ein einziger Verzeichnisbaum, in das die verschiedenen Dateisysteme eingehängt werden können; anders als das System mit Laufwerksbuchstaben unter Windows
- "Datei" und "Verzeichnis" als abstrakte Konzepte, die u.a. durch echte Dateisysteme abgebildet werden können, oder auch durch was anderes (vgl. "Everything is a file.")
- Beispiel: procfs
- Beispiel: sshfs
- Beispiel: transparente Behandlung von Zip-Archiven im Windows Explorer
- Beispiel: /dev/random etc.
Exkurs 2: Festplattenverschlüsselung
- Option 1: auf der Ebene des Dateisystems (einzelne Dateien oder Verzeichnisse werden verschlüsselt)
- Option 2: auf der Ebene des blockbasierten Speichers -> Dateisystem sieht als Speichermedium einen virtuellen blockbasierten Speicher, der die Verschlüsselung vornimmt und erst dann auf den tatsächlichen blockbasierten Speicher schreibt -> schöne Arbeitsteilung
- andere Anwendungsfälle für virtuelle blockbasierte Speicher: Netzwerklaufwerke, Dateisysteme innerhalb von Dateien

STP030: Arbeitsalltag in der IT

Thu, 29 Dec 2022 12:45:00 GMT

In dieser etwas länger geratenen Episode sricht Xyrill über seinen Alltag und den seiner Kollegen, Unterstellten und Vorgesetzten. Derweil darf ttimeless darf derweil munter drauflosraten, womit diese Leute denn so ihren Alltag verbringen (zumindest den professionellen).

Shownotes

Ausgangsfrage: "Ist Programmieren eigentlich ein Handwerk, eine Kunst oder eine Wissenschaft?"
- vgl. Artes mechanicae und Artes liberales
- im Gespräch erwähnt: xkcd 1205
- Vergleich: Industrie (effiziente Massenfertigung) vs. Handwerk (Nutzer der Industrieprodukte, Lieferant der Industrieanlagen) -> These: Programmieren als Manufakturbetrieb
- Berufskrankheit: Hochstapler-Syndrom
  - These: Internet verschafft den fähigsten Leuten sehr viel Sichtbarkeit und schafft Gelegenheit, sich relativ dazu inadäquat zu fühlen
  - These: Grund ist die Abwesenheit festgelegter Berufsbilder und Ausbildungsgänge (vgl. Lehre und Meisterschule im Handwerk, Studium im Ingenieurwesen, Staatsexamen in Jura/Medizin)
grundsätzliche Gewerke in der IT
- technische Disziplinen
  - Software-Entwickler*in
  - Software-Architekt*in
  - Tester*in
    - im Gespräch erwähnt: Pentaradio zu Resilienz
  - Systemadministrator*in: siehe auch DevOps
  - Kundendienst: Level 1/2/3
    - im Gespräch erwähnt: xkcd 806
  - Übersetzer*in (siehe STP017)
- Designdisziplinen
  - bei fast allen Applikationen: UI-Designer*in
  - in der Spieleentwicklung: Spieldesign, Leveldesign, Assetdesign
- Management-Disziplinen
  - Projekt-Manager*in
  - Release-Manager*in
  - Scrum Master*in
"Gesetze" der Softwareentwicklung
- Conway's Law: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."
- Brooks's Law: "Adding manpower to a late software project makes it later."
- Zawinski's Law: "Every program attempts to expand until it can send mail. Those programs which cannot so expand are replaced by ones which can." (heute wahrscheinlich eher "until it contains a web server")
- Parkinson's Law: "Work expands so as to fill the time available for its completion."
- Pareto's Fallacy: "When you're 80% done, you think you only have 20% left."
- Eagleson's Law: "Any code of your own that you haven't looked at for six or more months might as well have been written by someone else."
- Iceberg Fallacy: "The cost of development of a new software product is the only ~25% of the total cost of ownership management sees and budgets for."
- The LGTM Dilemma: "If you want to quickly ship a 10 line code change, hide it in a 1500 line pull request."
Lesetipp: "Everything Easy is Hard Again"
- Money Quote: "I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times."
- Xyrills Beobachtung: Die Branche (selbst die Universitäten!) rennt viel zu sehr Trends hinterher bzw. steckt zu sehr im selbst propagierten Novelty Bias fest. Wir haben noch nicht hinreichend die unveränderlichen Prinzipien destilliert (bzw. als solche erkannt).

STP029: Algorithmische Komplexität

Thu, 08 Dec 2022 12:15:00 GMT

In dieser Episode möchte Xyrill gern eine Vorlesung halten über ein Thema, das in der Informatik zu den Grundlagen für das erste Semester gehört. Zwischendurch ist ttimeless etwas schwer von Begriff. Zu hoffen ist, dass ihr trotzdem durchhaltet. Und haltet ein paar Skatkarten bereit!

Shownotes

Komplexität: Ressourcenbedarf eines Algorithmus (Zeitkomplexität, Platzkomplexität; vielleicht auch Kostenkomplexität etc.)
- Forschungsgegenstand der Komplexitätstheorie
- hier hauptsächlich Zeitkomplexität
einfaches Beispielproblem: "Gegeben ist eine sortierte Liste von Wörtern (Schlagwörter im Wörterbuch). Finde ein bestimmtes Wort."
- naive Idee: jedes Wort nacheinander anschauen -> lineare Laufzeit (Verdopplung der Wörtermenge verdoppelt die zu erwartende Suchzeit)
- kluge Idee: Bisektion -> logarithmische Laufzeit (Verdopplung der Wörtermenge erfordert nur einen zusätzlichen Schritt)
Beschreibung von Komplexität: Landau-Symbole
- wichtigste Form: f = O(g) heißt, dass f "nicht wesentlich schneller als g wächst (sprich: f(n)/g(n) bleibt beschränkt, wenn n -> ∞)
- Beispiel: naive Suche über eine Liste von n Elementen hat eine Laufzeit in O(n), Bisektion hat eine Laufzeit in O(log n)
etwas komplexeres Beispiel: Sortieralgorithmen ("Gegeben ist eine Liste von Zahlen/Wörtern/etc. Sortiere diese Liste.")
- Live-Beispiel: Skatkarten mischen und dann sortieren -> Auf welche Art und Weise sortieren wir intuitiv?
- Sortieralgorithmen auf Computern: zwei Grundbausteine
  - Vergleich von zwei Elementen
  - Tauschen von zwei Elementen
- anhand von Skatkarten diskutierbar:
  - Insertionsort: O(n^2)
  - Quicksort: O(n log n)
  - Mergesort: O(n log n)
- wünschenswerte Eigenschaften:
  - Lokalität (Timsort!, siehe STP007)
  - Stabilität (Mergesort!)
  - Codegröße (Quicksort!)
Schauempfehlung (mit Epilepsie-Warnung): Visualisierung verschiedener Sortieralgorithmen
im Gespräch erwähnt:

STP028: Autokonfiguration

Thu, 17 Nov 2022 16:05:00 GMT

Wenn Sie diese Nachricht lesen, hat sich diese Folge automatisch in ihren Podcast-Player konfiguriert. Heute geht es darum, warum es heute nicht mehr so kompliziert ist, einen Computer oder ein Netzwerk einzurichten.

Shownotes

Automatisierung: nach DIN V 19233 definiert als "das Ausrüsten einer Einrichtung, sodass sie ganz oder teilweise ohne Mitwirkung des Menschen bestimmungsgemäß arbeitet" (Quelle: Wikipedia)
- Was heißt "bestimmungsgemäß"? (siehe 33C3-Motto "Works for me"; siehe ebenfalls "Overly-Clever-Syndrom")
- heute feiern wir Autokonfiguration, die tatsächlich funktioniert
- Autokonfiguration: automatisierte Führung eines neu entstehenden Systems in einen arbeitsfähigen Zustand
Rückbezug zu STP020 (Bootstrap): Hardware-Erkennung während (und nach) dem Bootvorgang
- früher: Betriebssysteme spezifisch für einzelne Computer-Modellreihen mit gleichartiger Hardware
- heute: Betriebssysteme für ganze Kategorien von Computern, die oftmals vom Anwender selbst aus Komponenten zusammengestellt werden können
- während des Bootvorgangs Abfrage der vorliegenden Hardware-Komponenten durch das Betriebssystem (siehe Xyrills Hardware-Upgrade)
- nach dem Bootvorgang teilweise auch Neuerkennung möglich (Hotswap, USB, etc.)
Ethernet
- ausführliche Beschreibung siehe später; Grundprinzip: Netzwerk aus Switches, an denen die Endgeräte hängen
- Autokonfiguration 1: früher separate Kabel für Verbindungen zu Switches (Patch-Kabel) und Direktverbindungen (Cross-Kabel), heute automatische Erkennung mittels Auto MDI-X
  - ähnlich dazu automatische Orientierungs-Erkennung in USB-C-Steckverbindungen
- Autokonfiguration 2: früher Switches nicht in Schleifen verschaltbar (Broadcast-Stürme z.B. wegen ARP und DHCP)
- heute automatische Bildung eines Spannbaumes für eindeutiges Routing von Frames
apropos Ethernet: ARP (Address Resolution Protocol)
- Identifikation im Internet (Layer 3-7) durch IP-Adressen, aber in lokalen Netzen (Layer 1-2) durch adapterspezifische MAC-Adressen
- IP-Adressen können Computer sich im Prinzip auch einfach selber geben, grundsätzlich keine zentrale Vergabe
- ARP: Welche MAC-Adresse gehört zur gewünschten IP-Adresse?
- MAC-Adressen und ARP gibt's auch im WiFi...
apropos Ethernet und WiFi: DHCP (Dynamic Host Configuration Protocol)
- grundsätzlich Selbstwahl der IP möglich, aber man muss im richtigen Netzbereich sein und es darf keine Kollisionen geben
- meist bessere Lösung: automatische IP-Vergabe durch eine zentrale Stelle (Clients können IP-Adressen für eine gewisse Zeit pachten)
apropos DHCP: TFTP (Trivial File Transfer Protocol) -> per DHCP automatisches Ankündigen von verfügbaren Betriebssystem-Images, Abholen der Images über TFTP für Booten mit leerer Festplatte
- siehe auch: Installieren von macOS auf Apple Macs mit leerer Festplatte via Internet Recovery
IPv6 (Router Advertisement etc.) siehe RFC-Podcast
Autokonfiguration im Cloud-Computing-Umfeld
- virtuelle Maschinen in der Cloud werden aus Abbildern (Images) erzeugt und müssen sich dann an die Laufzeitumgebung (IP-Adressen, verfügbare Netzwerk-Festplatten, etc.) anpassen
- von Cloud-Seite: Metadata-Service meist auf der magischen IP-Adresse 169.254.169.254 (siehe z.B. Dokumentation bei OpenStack)
- von VM-Seite: Initialisierung mittels dieser Metadaten mit z.B. cloud-init

STP027: Verteilte Systeme

Thu, 27 Oct 2022 00:05:00 GMT

In dieser Episode bringt Xyrill uns versprengte Systeme näher. Dabei erfahren wir auch, dass Dinge, die wir als Grundvoraussetzung ansehen würden, bei genauerer Betrachtung gar nicht so selbstverständlich sind.

Shownotes

Laut Wikipedia eine überraschend breite Definition:

Ein verteiltes System ist [...] ein Zusammenschluss unabhängiger Computer, die sich für den Benutzer als ein einziges System präsentieren.

Motivationen für verteilte Systeme
- Kommunikation zwischen Computern mit verschiedenen Eigentümern (z.B. Chatnetzwerk, Banküberweisung)
- Teilen von Ressourcen (z.B. Druckerfreigabe)
- Hochverfügbarkeit
- Lastverteilung
Grundlage des Problems: CAP-Theorem
- Es gibt drei extrem wünschenswerte Eigenschaften. Wähle zwei.
- Konsistenz (Consistency): Lesevorgänge liefern immer die Daten, die zuletzt geschrieben wurden.
- Verfügbarkeit (Availability): Alle Anfragen an das System werden stets beantwortet.
- Partitionstoleranz: Das System kann bei Störungen des Netzwerkes oder einzelner Computer weiterarbeiten.
Beispiele bekannter Systeme gemäß CAP-Klassifikation
- CP: Banküberweisung, Geldautomat
- CA: Datenbanksysteme (siehe Folge 12)
- AP: DNS (siehe Folge 18)
Komplexbeispiel: Verteilte Datenbank mit Raft-Konsensalgorithmus
- Computernetzwerk aus N gleichartigen Teilnehmern (N meist ungerade, um Pattsituationen zu vermeiden)
- pro Wahlperiode ein Anführer, alle anderen folgen dem Anführer
- Schreibvorgänge gehen an den Anführer, werden von ihm an die Folger verteilt, und erst quittiert, wenn eine Mehrzahl der Folger Vollzug meldet
- Anführer sagt regelmäßig (Größenordnung 150-300 ms) allen Folgern Bescheid, dass er noch anführt
- bei Ausbleiben der Meldung vom Anführer startet jeder Folger eine neue Wahlperiode und stimmt für sich selbst als neuen Anführer
- pro Wahlperiode:
  - wer jemand anderen abstimmen sieht, bevor er selbst abstimmt, folgt sofort der gesehenen Stimme
  - wer die Mehrheit der Stimmen auf sich vereinigt, ist der neue Anführer
- bei Pattsituationen beginnt nach einer Wartefrist die nächste Wahlperiode (Wartefrist ist pro Teilnehmer randomisiert, um Kettenpatt zu vermeiden)
- CAP-Bewertung: CA (nicht partitionstolerant, weil eine Mehrheit der Teilnehmer erforderlich ist)
hier nicht betrachtet: Byzantinische Fehler
- Paper: The Saddest Moment
- Analogie zu Wahlcomputern
zum Nachlesen: Irrtümer der verteilten Datenverarbeitung
Sidebar: Volunteer Computing (BOINC, SETI@Home, Folding@Home, etc.)
- siehe Pentacast 56
Nachtrag: geführte Visualisierung des Raft-Algorithmus (englisch): https://thesecretlivesofdata.com/raft/

STP026: Energieeffizienz

Thu, 06 Oct 2022 18:50:00 GMT

Seit der Zeit von Konrad Zuse, der seine Rechenmaschinen mit Relais baute, hat sich viel getan. Nicht nur, was die Geschwindigkeit, sondern auch, was die Effizienz betrifft. Wir beleuchten heute einige jüngere Ereignisse dieser Entwicklung.

Shownotes

Wortklärung
- "effektiv": die Fähigkeit besitzend, eine Aufgabe erfolgreich zu erledigen
- "effizient": fähig, viel Leistung in Relation zum Aufwand zu erbringen
- Leitsatz: "Der einzige Weg, ein Programm effizienter zu machen, ist, weniger zu tun." (Quelle unklar)
- Welche Wege gibt es, weniger zu tun?
- hängt vom Optimierungsziel ab: Speicherverbrauch vs. Zeitverbrauch vs. Energieverbrauch vs. Kosten bei Zugriff auf externe Systeme -> Analogie zum Navigationssystem im Auto
Caching: Ergebnisse wiederverwenden
- Abruf aus dem Arbeitsspeicher ist effizienter (in Zeit und Energie) als Abruf aus dem Netzwerk
Miniaturisierung: weniger Elektronen durch die Gegend schaufeln
- "viele Zahlen für wenig Wärme"
- Transistoren sind ähnlich wie Relais-Schalter, die durch Auffüllen und Leeren einer Elektronenfalle umschalten
- kleinere Transistoren = weniger Elektronen schaufeln = weniger Stromverbrauch (und weniger Abwärme)
- zeitlicher Verlauf der Strukturgrößen anhand von x86-Prozessoren (mit bildlichem Vergleich zu mechanischen Schaltern im Maßstab 1.000.000:1)
  - 1971 (Intel 4004): 10µm (vgl. 10m = nur im Cartoon, etwa 3-4 Etagen hoch)
  - 1993 (Intel Pentium): 800nm (vgl. 80cm = Weichenhebel in manuellem Stellwerk, kleiner Scherenstromabnehmer)
  - 2007 (ohne Produktbezeichnung): 65nm (vgl. 65mm = Lichtschalter)
  - 2019 (AMD Ryzen): 7nm (vgl. 7mm = Kippschalter an der Schreibtischlampe)
heterogene CPU-Architektur, z.B. "big.LITTLE" bei ARM
- kleine CPU-Kerne (mit geringem Stromverbrauch) für Routinearbeit und Hintergrundprozesse
- große CPU-Kerne (die meistens schlafen) für energieintensive Anwendungen (3D-Grafik bei Spielen, Enkodierung/Dekodierung bei Videoanrufen, etc.)
- außerdem Betrieb der kleinen Kerne sehr stoßartig: lieber kurz mit hoher Taktfrequenz und dann gleich wieder schlafen als permanent langsam laufen lassen (Randbemerkung: anders als z.B. bei Verbrennungsmotoren, aber Parallelen zu Elektromotoren)
im Zusammenhang damit: "Aufwachverschmelzung" (z.B. systemd.timer)
- Idee: für geplante Hintergrundaktivitäten die Takte so verschieben, dass möglichst viele Aktivitäten gleichzeitig ausgeführt werden und die CPU-Kerne möglichst selten aufwachen müssen
ebenfalls im Zusammenhang damit: Push Gateways auf iOS/Android
- Netzwerkverbindungen = Energieverbrauch (für das Funken und das Verarbeiten in der CPU)
- Netzwerkverbindung aufhalten = Energieverbrauch (für Keepalive-Pakete)
- Idee: statt einer Netzwerkverbindung pro Messenger-App eine zentrale Netzwerkverbindung zu einem zentralen Relay-Server vom Betriebssystem-Anbieter
- aber: aus Datenschutzsicht problematisch
Xyrills Abendgedanken: Wie kann es sein, dass alles soviel effizienter ist, aber wir machen nicht mehr damit? (siehe klassische Floskel: "modernes Smartphone ist mächtiger als die Computer in der Apollo-Kapsel")
- wir erwarten gleichzeitig immer mehr von den Geräten (z.B. Grafikqualität: gleich komplizierte App, aber früher auf 80x25-Terminal und heute auf Full-HD-Bildschirm)
- vgl. Jevons-Paradoxon: mehr Effizienz ermöglicht mehr Anwendungen, sodass letztlich der Energieverbrauch gleich bleibt oder sogar steigt
- waghalsige Prognose: viel mehr E-Ink-Displays, wenn Energieeffizienz wichtiger wird

STP025: Datenkompression

Thu, 15 Sep 2022 19:00:00 GMT

Trotz des Themas haben wir es nicht geschafft, uns kurz zu fassen. Xyrill musste den Preis dafür zahlen. In dieser Sendung: Ein Einstieg mit flachen Witzen, gezinkte Münzen, naive Betrachtungsweisen und schwierige Abwägungen.

Shownotes

Einführungsbeispiel: simulierte schlechte Leitung ("xxxxxx heute xxxxxx Podcast xxxxxx Thema xxxxxx Kompression xxxxxx" -> "In unserer heutigen Folge unseres Podcasts ist das Thema die Datenkompression.")
- naiver Impuls eines Erstsemester-Linguistikstudenten: "Warum sagt man nicht gleich 'heute Podcast Thema Kompression'?"
- Sprache ist so gestaltet, dass auch teilweise fehlerhafte Informationen noch korrekt ankommen
- beim Hören intuitiver Einsatz eines Vorhersagemodells, um kommende Silben/Wörter/Phrasen vorherzusagen
theoretische Grundlagen
- Bit: Basiseinheit für Informationsgehalt (enstprechend der Auswahl aus zwei gleich wahrscheinlichen Möglichkeiten), allerdings nicht im SI-System verankert
- Beispiel Münzwurf:
  - ideale Münze (50% Kopf + 50% Zahl) liefert 1 Bit pro Wurf
  - reelle Münze liefert mehr als 1 Bit pro Wurf (z.B. 49,5% Kopf + 49,5% Zahl + 1% Kante -> 1,07 Bit pro Wurf)
  - gezinkte Münze liefert weniger als 1 Bit pro Wurf (z.B. 10% Kopf + 90% Zahl -> 0,469 Bit pro Wurf)
- gute Komprimierbarkeit = niedriger Informationsgehalt -> häufiger, als man denkt (Bsp. nebeneinanderliegende Pixel eines Bildes sind ähnlich)
- Zusammenhang mit physikalischer Entropie: Systeme mit geringer Entropie (z.B. Eisblock) sind einfach vorherzusagen, Beobachtungen haben geringen Informationsgehalt; Systeme mit hoher Entropie (z.B. Wasserdampf) sind schwer vorherzusagen, Beobachtungen haben hohen Informationsgehalt
"naive" Kompressionsmethoden (die man auch als Mensch überblicken kann)
- Nutzung von Allgemeinwissen
  - Beispiel aus der Vorbereitung: "Schachbrett" im Kontext von Exponentialfunktionen ruft die Assoziation einer ganzen Geschichte auf
- Wörterbuchmethode für Text
  - Beispiel aus Wikipedia: "wenn Fliegen hinter Fliegen fliegen, fliegen Fliegen Fliegen nach" -> "wenn Fliegen hinter \2 fliegen, \5 \2 \2 nach"
- RLE (Run-Length Encoding) z.B. in Bildern wie dem Coverart dieses Podcasts
- Huffman-Kodierung wie im Morse-Code (Verbindung zur Linguistik!)
- Minifizierung von Skripten
  - Beispiel: jQuery 3.6 ohne Minifizierung und mit Minifizierung
zwei fundamentale Abwägungen
- Geschwindigkeit vs. Stärke (z.B. Debian-Pakete mit zwei getrennten Bereichen, die verschiedene Kompressionsverfahren nutzen)
- verlustfrei vs. verlustbehaftet (Bsp. Pentaradio vom Mai 2022: Radiofassung als FLAC 271,7 MiB; Endprodukt als Opus 52,0 MiB)
Kompressionsmethoden im Audio-Video-Bereich beispielhaft anhand ihres Verlustverhaltens
- Blockartefakte bei JPEG
- Psychoakustik bei MP3
- Datamoshing bei Videos (Beispiel) illustriert Bedeutung von Intra-Frames
  - siehe auch dasselbe Video, 1000-mal komprimiert und dekomprimiert
- Einfluss fester Bitrate auf Audio/Videos
theoretische Grenze: Kolmogorow-Komplexität
Fußnoten:
- ttimeless fühlt sich verpflichtet, auf den RFC-Podcast zu verlinken
- David Kriesel: "Traue keinem Scan, den du nicht selbst gefälscht hast"

STP024: Cloud Computing

Thu, 25 Aug 2022 16:20:00 GMT

Diese Episode beschäftigt sich mit anderer Leute Computer: warum man die überhaupt benutzen kann, und unter welchen Voraussetzungen das sinnvoll ist.

Shownotes

Cloud Computing erklärt anhand von Pizza
- On-Premise: kein Cloud Computing, Nutzer betreibt seine eigene Hardware und Software
- IaaS (Infrastructure as a Service): Cloud-Anbieter betreibt die Hardware, Nutzer bringt Betriebssystem und Software
- PaaS (Platform as a Service): Cloud-Anbieter betreibt die Hardware und das Betriebssystem, Nutzer bringt die Anwendung
- SaaS (Software as a Service): Cloud-Anbieter betreibt alles, Nutzer bedient die Anwendung nur noch

Fünf Grundanforderungen gemäß Definition durch NIST (NIST ist dem Aufgabenspektrum nach mit der PTB und dem BSI vergleichbar):

On-Demand Self-Service: Nutzer kann selber Ressourcen klicken, ohne Mitarbeiter beim Dienstanbieter zu involvieren
- Bsp. SaaS-Anwendungen wie Dropbox, GitHub, Netflix, etc.
- Bsp. mal kurz ein dutzend VMs klicken, um eine komplizierte Server-Anwendung wie Kubernetes auszuprobieren
Broad Network Access: Ressourcen sind über das Netz mittels "Standardmethoden" erreichbar, ohne durch eine anbieterspezifische Zugriffstechnologie gehen zu müssen
- Was soll diese Anforderung ausschließen? Xyrills Vermutung: z.B. das Telefonnetz, ttimeless' Vermutung: Mainframes und Universitäts-Rechenzentren (die nur aus dem entsprechenden Intranet zu erreichen sind)
- zur Konfiguration und Administration jedoch meist anbieterspezifische Schnittstellen und Werkzeuge (entsprechend dem Funktionsumfang des jeweiligen Angebots) -> Vendor Lock-In
Resource Pooling: Ressourcen werden unter mehreren/allen Kunden nach Bedarf aufgeteilt
- sowohl zwischen mehreren Kunden ("Public Cloud") als auch innerhalb einer Firma oder innerhalb eines Teams ("Private Cloud")
- Bsp. CDN (Content Delivery Network): mehrere Kunden teilen sich ein weltweites Rechenzentrumsnetz, das jeder alleine so nicht bezahlen könnte
Rapid Elasticity: Ressourcen können kurzfristig zugeteilt und zurückgegeben werden
- Bsp. Internet-Shop am Black Friday, Buchhaltungssystem am Quartalsende
- Bsp. Cloud-Gaming (Gegenbeispiel: Error 37)
Measured Service: Messung und Abrechnung der genutzten Ressourcen mindestens zeitnah oder sogar in Echtzeit
- "wie bei der Telefonrechnung früher"
- Bsp. sehr kurze Nutzung (z.B. einige Stunden) von leistungsstarker Hardware, z.B. um ein neuronales Netz zu trainieren
Probleme mit Cloud Computing
- Zentralisierung: wenn ein Amazon-Rechenzentrum Probleme hat, ist gefühlt das halbe Internet weg
- Preistransparenz: siehe z.B. "I got pwned by my cloud costs"

STP023: Virtualisierung, Container, Sandboxing, Simulation/Emulation

Thu, 04 Aug 2022 18:15:00 GMT

Die Sendung mit der Quersumme 5 beschäftigt sich damit, wie Computer so tun können, als wären sie andere Computer. Außerdem beginnt Xyrill damit, sein Mediensyndikat aufzubauen.

Shownotes

Laut Wikipedia:

Virtualisierung bezeichnet in der Informatik die Nachbildung eines Hardware- oder Software-Objektes durch ein ähnliches Objekt vom selben Typ mithilfe einer Abstraktionsschicht.

verschiedene Arten von Virtualisierung je nachdem, wo die Abstraktionsschicht liegt
- Virtuelle Maschinen (VM): Hardware gleich, Betriebssysteme (OS) und Prozesse getrennt
- Container: OS gleich, Prozesse getrennt
- Sandboxing: getrennte Teile innerhalb eines Prozesses
Anwendungsfälle für VM (OS als Anwendung innerhalb eines anderen OS)
- gleichzeitiger Betrieb von mehreren OS auf einem Computer (z.B. Linux als Hauptsystem, Windows-VM für bestimmte Anwendungen)
- saubere Abgrenzung von verschiedenen Programmen durch das Einsperren in VMs mit festen Ressourcen-Zuteilungen und Zugriffsschranken
- daraus folgend: Aufteilen einer einzelnen Server-Maschine in mehrere VMs für verschiedene Kunden
- Ermöglichung der Verschiebung von Programmen zwischen Maschinen im laufenden Betrieb ("Live-Migration", z.B. bei Hardwarefehlern)
Ansätze für VMs (Wie kann der Gast-Kernel seinen administrativen Aufgaben nachgehen, ohne selber vollen Zugriff auf das System zu erhalten?) anhand von Meilensteinen auf x86-CPUs
- User Mode Linux (ab ca. 2000), Xen (ab 2003): "Paravirtualisierung", Gast-Kernel ist von Anfang an so aufgebaut, dass er auch als Prozess unter einem anderen Kernel laufen kann (Hardware-Zugriff mittels Emulation, siehe unten)
- VMware Workstation (ab 1999), VirtualBox (ab 2007), etc.: "Software-Virtualisierung", Gast-Kernel läuft in einem teilprivilegierten Modus (z.B. Ring 1 bei x86), sodass Hardware-Zugriff einen Fehler auslöst; der Host-Kernel erhält die Kontrolle zurück und macht den Hardwarezugriff im Namen des Gast-Kernels (Problem: Performance-Verlust gegenüber Direktzugriff auf die Hardware) (detaillierte Erklärung in der VirtualBox-Dokumentation)1
- Intel VT-x (ab 2005), AMD-V (ab 2006): "Hardware-Virtualisierung", Host-Kernel richtet durch spezialisierte CPU-Instruktionen einen abgetrennten Bereich für den Gast-Kernel ein (beschränkter Speicherbereich, beschränkte CPU-Zeit, beschränkter Gerätezugriff), innerhalb dessen das System für den Gast-Kernel wie unvirtualisiert erscheint (somit so gut wie kein Performance-Unterschied zwischen nativem und virtualisiertem Kernel mehr)
Container: isolierte Umgebungen innerhalb eines OS, aus denen Programme im Allgemeinen nicht ohne weiteres ausbrechen können
- Vorteil gegenüber VM: ressourcenschonender (nur ein Kernel für alle), Container starten schneller als VM (kein Boot eines Gast-Kernels notwendig)
- Urform des Containers: chroot in Unix-Systemen (ab 1979) modifiziert für einen Prozess das sichtbare Dateisystem so, dass nur Dateien unterhalb eines bestimmten Verzeichnisses erreicht werden können (Intention war die Bereitstellung von angepassten Dateisystemstrukturen für bestimmte Programme; chroot ist kein wirklicher Container, da die allermeisten Ressourcen nicht eingeschränkt werden und ein privilegierter Prozess das chroot jederzeit durch Neukonfiguration umgehen kann)
- echte Container ab ca. 2000: z.B. FreeBSD Jails ab 1999, Virtuozzo/OpenVZ ab 2000, Solaris Zones ab 2005, LXC (Linux Containers) ab 2008, Docker ab 2013
ausführliche Besprechung von Containern unter Linux (Docker/Kubernetes) siehe Pentaradio von 2022-05-24
Sandboxing: Container innerhalb einer Applikation
- z.B. Webbrowser führen JavaScript-Code aus dem Internet in separaten Prozessen mit geringen Privilegien aus, um Malware das Leben schwer zu machen
- Begriffstrennung nicht ganz sauber; mitunter werden auch Container als eine Art von Sandboxing eingeordnet
Simulation und Emulation
- Simulation: Nachbildung eines realen Systems oder Szenarios mittels andersgearteter Technik (z.B. Fahrsimulation ohne echtes Auto, Militärsimulation ohne echtes Schlachtfeld, Simulation von quantenmechanischen Wellen mittels Ultraschallwellen... oder gleich mit Zahlen im Computer)
- Emulation: Nachbildung eines Systems durch ein ähnliches, aber anderes System (z.B. Nachbildung des Verhaltens eines CPU-Typs als Programm auf einem anderen CPU-Typ)
- Einsatz von Emulation hauptsächlich zum Nachbilden alter Systeme (siehe Emulation von Videospielen, wie besprochen im Pentaradio vom Januar 2022) und zum Testen von Software auf besser zugänglichen Systemen (z.B. Testumgebungen für Smartphone-Apps auf PC-Betriebssystemen)

STP022: Das Web ist nicht das Internet

Thu, 14 Jul 2022 00:00:00 GMT

Heute geht es um das allseits bekannte und beliebte Interweb. Oder nicht, denn Web und Internet sind beileibe nicht dasselbe. Oder doch, oder nicht, denn sie werden erst dazu. Egal, Xyrill kann das besser erklären!

Shownotes

Geschichte des Internets
- 1989-1991 initiale Entwicklung des World Wide Web
- Internet aber bereits seit 1969 als Darpanet, ab 1981 bis 1983 Umstellung auf TCP/IP
- über 20 Jahre Internet ohne Web -> das Web ist nur eine von vielen Anwendungen für das Internet
- Internet vs. Web: Netzwerk von Computern vs. Netzwerk von Dokumenten
DNS: seit 1984, ausführlich siehe STP018
E-Mail: seit 1971
- Ablage von Mails in Mailboxen mittels SMTP (Simple Mail Transfer Protocol)
- Abruf von Mails aus Mailboxen zuerst durch direkten Login auf dem Zielsystem, ab 1984 mittels POP3 (Post Office Protocol), ab 1994 mittels IMAP (Internet Message Access Protocol)
- nicht dasselbe wie das Web: asynchrone Zustellung (siehe Wikipedia zur ersten E-Mail nach Deutschland)
NTP (Network Time Protocol): seit 1985
- Synchronisation der Computeruhr mit der Uhr eines Servers und damit indirekt mit einer Atomuhr
- Zeitdifferenzen werden (bei Nachgehen) durch Vorstellen oder (bei Vorgehen) durch Verlangsamen der lokalen Uhr korrigiert
- nicht dasselbe wie das Web: nicht dokumentenbasiert
Telnet, RSH (Remote Shell) und SSH (Secure Shell): seit 1974/1977/1995
- Telnet: Klartextaustausch mit einem entfernten Rechner
- RSH/SSH: Abwicklung einer Kommandozeilen-Sitzung auf dem entfernten Rechner
- nicht dasselbe wie das Web: bidirektionaler Datenstrom
IRC (Internet Relay Chat), XMPP (Extensible Messaging and Presence Protocol): seit 1988/1998
- IRC: textbasiertes Chatprotokoll zwischen vielen nutzerseitigen Clients und einigen untereinander vernetzten Servern
- XMPP: ähnlich, statt Plain Text mittels Strömen von XML-Nachrichten
- nicht dasselbe wie das Web: ebenfalls ein kontinuierlicher bidirektionaler Datenstrom
SIP (Session Initiation Protocol): seit 1999
- und darauf folgend ein ganzer Zoo von Telefonie-Protokollen... ITU-Standards sind unser blinder Fleck :)
- nicht dasselbe wie das Web: ebenfalls ein kontinuierlicher bidirektionaler Datenstrom
FTP (File Transfer Protocol), NFS (Network File System), SMB (Server Message Block): seit 1985/1984/1996
- Zugriff (FTP) bzw. Einbindung (NFS/SMB) eines entfernten Dateisystem auf dem lokalen Rechner
- Protokollbefehle wie "Dateien in Ordner auflisten" oder "Dateiinhalt lesen" oder "Datei löschen"
- nicht dasselbe wie das Web: keine Dokumente mit Verweise untereinander, "nur" eine Struktur aus Dateien ohne bestimmte Anforderungen an den Dateiinhalt
LDAP (Lightweight Directory Access Protocol): seit 1993
- Wenn DNS das Telefonbuch des Internets ist, dann sollte LDAP das Benutzerverzeichnis des Internets sein.
- nicht dasselbe wie das Web: nicht dokumentenbasiert, sondern datensatzbasiert
und dann natürlich HTTP (Hypertext Transfer Protocol): seit 1991
- zunächst fokussiert auf Abruf von Hypertext-Dokumenten in HTML sowie der darin enthaltenen Ressourcen (zunächst vor allem Bilder)
- dann erweitert um Hochladen von Daten zum Ausfüllen von Formularen
- dann erweitert um Verwaltung von Sitzungsdaten mittels Cookies
- dann erweitert um Methoden zum Durchlaufen von Dateisystemen (WebDAV, CalDAV, CardDAV, GroupDAV)
- dann erweitert durch eine komplette Client-Server-Programmierumgebung (JavaScript, XHR)
- dann erweitert durch serverseitige Benachrichtigungen (WebSockets, Server Sent Events)
- dann erweitert... und erweitert... und erweitert
Plot-Twist: Web ist nur ein Teil des Internets, aber alle anderen Teile des Internets werden immer webbiger
- jedes einzelne Protokoll profitiert tendenziell davon, wenn es auf HTTP aufsetzt:
  - Webbrowser können direkt HTTP verstehen
  - die meisten Entwickler kennen HTTP gut (auf jeden Fall besser als die ganzen anderen Protokolle)
  - in HTTP sind häufige Probleme wie Verschlüsselung/Caching/etc. schon gelöst (und die Lösungen sind milliardenfach getestet)
  - HTTP kommt am besten durch Firewalls durch
- quasi ein Netzwerkeffekt ("es ist populär, weil es alle benutzen, und alle benutzen es, weil es populär ist")
Wie sieht es mit den vorgenannten Protokollen aus?
- DNS -> DoH (DNS over HTTPS), um Verschlüsselung hinzuzufügen
- IRC, XMPP -> meist HTTP-basierte app-spezifische Chatprotokolle (z.B. Matrix)
- LDAP -> SAML (Authentifizierung mittels Umleitungskette im Webbrowser)
- SMTP, SSH, SIP, NFS, SMB: gibt's so noch, aber als Webapplikation ist die letzte Meile über HTTPS oder das eigentliche Protokoll ist in HTTPS-Websockets eingewickelt

STP021: Reguläre Ausdrücke

Thu, 23 Jun 2022 17:45:00 GMT

ttimeless hat sich ein Thema gewünscht und mit Beginn von Xyrills Recherchen angefangen, es zu bereuen. Es stellt sich heraus, dass das Thema zwar abstrakt, aber dennoch spannend ist. Außerdem gibt es im zweiten Teil der Sendung noch praktische Dinge zu lernen.

Shownotes

Motivation: reguläre Ausdrücke verstehen
- etwas Theorie ist notwendig, um die Eigenschaften und Grenzen von regulären Ausdrücken zu verstehen
- quasi eine Erstsemestervorlesung -> Anekdote Xyrill: Büchlein "Einblick ins Studium"

Siehe Wikipedia:

Grammatik bezeichnet in der Linguistik jede Form einer systematischen Sprachbeschreibung. Dabei steht der Begriff der Grammatik einmal für das Regelwerk selbst, auf der anderen Seite aber auch für die Theorie über eine bestimmte Sprache oder Sprachfamilie.

im Kontext der Informatik: formale Grammatiken für formale Sprachen
- formale Sprache: Menge von Symbolketten ("Wörter"), die aus Symbolen ("Alphabet") zusammengesetzt werden
- formale Grammatik: endlich große Beschreibung einer (im Allgemeinen unendlich großen) formalen Sprache
- Beispiele: Programmiersprachen, Tastenkombos in Videospielen, Münzeinwurf in Verkaufsautomat
- Abwägung: komplexere Grammatiken sind flexibler, aber auch aufwändiger (z.B. Tastatureingaben vs. Sprachsteuerung)
Chomsky-Hierarchie: Klassifikation von formalen Grammatiken in aufsteigender Striktheit und absteigender Flexibilität
- Beschreibung der entsprechenden formalen Grammatiken: hier nicht, zu technisch
- zu jeder Ebene der Chomsky-Hierarchie gehört ein Maschinenmodell, dass entsprechende Grammatiken akzeptieren kann
- Typ 3: reguläre Grammatiken mittels endlichem Zustandsautomat (Beispiel: Münzeinwurf in Verkaufsautomat)
- Typ 2: kontextfreie Grammatiken mittels Kellerautomat (Beispiel: balancierte Klammerpaare)
- Typ 1 und 0 mittels Turingmaschinen (erst mit beschränktem, dann mit unbeschränktem Speicher)
Beispiel für grafische Repräsentation von Grammatiken: siehe SQLite-Dokumentation
reguläre Grammatiken im Alltag: reguläre Ausdrücke; formale Definition mit vier Grundbausteinen

Grundbaustein	Beispielausdruck	Findet z.B.
Zeichen(folge)	`Ausdruck`	`Ausdruck`
Alternative	`Ausdruck\|Ausdrücke`	`Ausdruck` und `Ausdrücke`
Gruppierung	`Ausdr(uck\|ücke)`	`Ausdruck` und `Ausdrücke`
Sternquantor	`to*ll`	`tll`, `toll`, `tooll`, `toooll`, etc.

in der Praxis weitere Bausteine, um häufige Anwendungen zu vereinfachen

Zusatzbaustein	Definition	Beispielausdruck	Findet z.B.
Zeichenklasse	`[ABC...] = A\|B\|C\|...`	positive Ganzzahl: `0\|[1-9][0-9]*`	`0`, `42`, `900`, aber nicht `0815`
feste Zeichenklasse	`\s` für Whitespace, `\d = [0-9]` für Ziffern, etc.
beliebiges Zeichen	`.`	Klammerausdruck: `(.*)`	`(2 + 4)`, `(siehe oben)`, aber auch `(siehe oben (oder nicht)`
Fragezeichenquantor	`A? = (\|A)`	Ganzzahl mit Vorzeichen: `[+-]?(0\|[1-9][0-9]*)`	`+0`, `-42`, `23`
Fixquantor	z.B. `A{3} = AAA`, `A{2,4} = AAA?A?`	Postleitzahl: `[0-9]{5}`	`01127`, `50616`
Plusquantor	`A+ = AA*`	Domainname: `([a-zA-Z0-9-]+\.)*[a-zA-Z0-9-]+`	`www.example.com`
Anker	`^` für Zeilenanfang, `$` für Zeilenende, `\b` für Wortgrenze	`Schulz\b`	`Schulz`, aber nicht `Schulze`

Problem in der Praxis: Escaping
- z.B. Klammern sind Teil der Syntax; um eine Klammer im Eingabetext darzustellen, schreibt man "\("
Regexen lernen
- Online
  - LearnRegex ist ein interaktives Tutorial zum Erlernen von regulären Ausdrücken, in englischer Sprache.
  - Mit Regex Crossword kann man spielerisch besonders das Lesen regulärer Ausdrücke üben.
- Apps
  - Regex-Kreuzworträtsel auf dem Mobiltelefon
  - Mehrere Ausdrücke mit regulären Ausdrücken erfassen bzw. ausschließen

STP020: Bootstrap

Thu, 02 Jun 2022 17:10:00 GMT

Strom an und Ohren auf! In dieser Episode nähern wir uns Computern im Dornröschenschlaf. Genauer sehen wir uns an, was beim Erwachen geschieht.

Shownotes

Zustand bei frühen Rechenmaschinen und Computern
- kein Bootstrap: Strom an -> Programm starten, Programm beenden -> Strom aus (siehe Konrad-Zuse-Clip)
- Programme waren spezifisch für die Hardware, auf der sie laufen
- siehe auch: damals (TM) Podcast
- und ChaosRadioExpress193 Old School Computing
Zustand bei heutigen Computern
- Programme benötigen Funktionen des Betriebssystems, Betriebssystem muss sich mit der Hardware vertraut machen -> separate Startphase notwendig
- Bootstrap (oder kurz Boot): sich selbst an den Schnürsenkeln aus dem Sumpf ziehen; aus einem einfachen System heraus ein komplexeres System aktivieren
- Konzept taucht mehrmals in verschiedenen Kontexten auf ("Wie stellt man einen Hobel her, wenn man keinen Hobel hat?"), siehe z.B. Bootstrapping von Programmiersprachen
- Hardware-Bootvorgang meist in mehreren aufeinanderfolgenden Phasen
Phase 1: Firmware
- minimales Startprogramm
- in einen separaten Flash-Speicher im Chip fest verbaut
- Aufgabe: Hardware in einen definierten Zustand bringen (z.B. interne Speicher initialisieren), nächste Stufe finden und laden
- heute mitunter alles andere als minimal: siehe UEFI und Intel ME/AMD PSP
- bei x86 früher BIOS; heute ersetzt durch UEFI, dessen definierter Endzustand modernen Konventionen folgt
Phase 2: Bootloader
- immer noch ziemlich minimal
- liegt auf einem Massenspeicher (Festplatte, USB-Stick)
- Aufgabe: Massenspeicher nach Betriebssystemen durchsuchen, Auswahldialog anbieten, gewähltes Betriebssystem starten
- unter Linux meistens GRUB oder systemd-boot
Alternativen zum klassischen Bootloader
- UEFI-Firmware kann direkt das Betriebssystem starten, sofern keine interaktive Auswahl erforderlich ist
- Netzwerk-Boot (entweder durch die Firmware oder als Option in Bootloadern wie GRUB)
Phase 3: Betriebssystem
- Erinnerung (siehe STP019): Kernel = Betriebssystemteile in höchster Privilegenstufe, Userspace = alle Programme in niedrigerer Privilegienstufe
- Bootloader lädt und startet den Basisteil des Kernels
- Kernel erkennt die verfügbare Hardware, lädt von der Festplatte die benötigten Kernel-Module nach und startet den System-Manager
Phase 4: System-Manager
- unter Unix meist als "PID 1" benannt, weil dieser erste Prozess mit der Prozess-ID (PID) 1 läuft
- klassischerweise sysvinit, heute unter Linux meist systemd
- startet alle Userspace-Programme, die als Teil des Betriebssystems aufgefasst werden können (im Unix-Sprech "Daemons": Disk And Execution MONitors)
- auf Systemebene z.B. Druckwarteschlange, Bluetooth-Dienst, Netzwerk-Konfigurationsdienst, Zeitsynchronisation
- auf der Ebene einer grafischen Sitzung z.B. Dienste zum Auswählen von Tastaturlayout/Netzwerk, Einstellen der Lautstärke, Screen-Reader
- ChaosRadioExpress209 Das Linux System
Phase 5: Display-Manager
- bietet auf grafischen Systemen den Anmeldedialog
- im Prinzip selbst eine komplette grafische Sitzung (Anekdote: GDM vs. LightDM)
- startet nach erfolgreicher Anmeldung die entsprechende grafische Sitzung
Phase 6: grafische Sitzung
- Strukturierung je nach Desktopoberfläche
- immer mit dabei: ein Window-Manager, der die einzelnen Fenster in ein Gesamtbild zusammensetzt (heutzutage auf der GPU, dann heißt der Window-Manager "Compositor")
- unter Windows ist der Window-Manager aus historischen Gründen Teil von explorer.exe
- wie besprochen: unter Linux Bootvorgang visualisieren mit systemd-analyze plot > output.svg

STP019: Speicherschutz

Thu, 12 May 2022 16:50:00 GMT

Nach einem glorreichen Intro mit perfekter Vorbereitung befassen Xyrill und ttimeless sich mit Speicherschutz. Wie und warum und welchen Speicher überhaupt? Hört selbst.

Shownotes

"Welchen Speicher müssen wir eigentlich schützen?"
- hier nur Arbeitsspeicher und Gerätespeicher
- andere Speicherarten (z.B. Festplatten) geschützt durch die Betriebssystem-Abstraktionen, siehe zukünftige Folge zu Privilegienkontrolle
Aufgaben des Betriebssystems: Prozessisolation und Vermittlung des Hardwarezugriffs
- Problem: das Betriebssystem ist auch nur "ein Programm"
- Frage 1: Wie wird sichergestellt, dass das Betriebssystem die finale Kontrolle über Hardwarezugriffe hat?
- Frage 2: Wie wird verhindert, dass ein Speicherbereich, den Prozess A verwendet, von Prozess B überschrieben (oder unberechtigterweise ausgelesen) wird?
Antwort auf Frage 1: Prozessor-Ringe
- Standardfunktion auf allen CPUs, die auf Mehrprozess-Betrieb ausgelegt sind (nicht immer im Embedded-Bereich)
- zu jedem Zeitpunkt läuft der Prozess in einem von mehreren Ringen
- sensible Operationen (v.a. Hardwarezugriff) sind nur in den höheren Ringen erlaubt und damit den Betriebssystemprozessen vorbehalten
- Wechsel in einen niedrigeren Ring jederzeit möglich (z.B. Aktivierung eines Userspace-Prozesses durch das Betriebssystem)
Wie kommen wir von einem niedrigeren Ring wieder in einen höheren Ring?
- Interrupts (siehe STP015): Eintreten eines Hardware-Ereignisses (z.B. ankommendes Netzwerk-Paket oder abgelaufener Hardware-Timer), das durch das Betriebssystem behandelt werden muss
- Syscalls: niedrigprivilegierter Prozess fragt eine definierte Schnittstelle des Betriebssystems an, um eine höherprivilegierte Operation auszuführen
- z.B. Dateisystem-Zugriff, Hardware-Zugriff, Ändern der Betriebssystem-Konfiguration, Starten von neuen Prozessen, Nachrichtenübermittlung an andere Prozesse
- dadurch Realisierung der Prozessisolation, weil das Betriebssystem die Kontrolle über alle privilegierten Operationen hat
Antwort auf Frage 2: Virtuelle Speicherverwaltung
- wenn Prozesse auf Speicher zugreifen, verwenden sie nur "virtuelle" Speicheradressen: z.B. Adresse 0x42 für Prozess A ist nicht unbedingt derselbe Speicher wie Adresse 0x42 für Prozess B
- Abbildung auf physische Speicheradressen innerhalb der CPU durch eine Memory Management Unit (MMU)
- Konfiguration der MMU durch das Betriebssystem immer kurz vor der Übergabe der CPU an einen anderen Prozess
- Aufteilung des physischen/virtuellen Speichers in Seiten (Pages), z.B. bei x86-64 wahlweise 4 KiB oder 2 MiB oder 1 GiB
- pro Page verschiedene Zugriffsberechtigungen möglich, z.B. zur Verhinderung des Schreibens in ausführbare Programmteile, oder für Shared Memory als Kommunikationsweg zwischen Prozessen
Paging der MMU ermöglicht Swapping
- Pages müssen nicht unbedingt im tatsächlichen Arbeitsspeicher gehalten werden, sondern können bei Nichtverwendung in eine Swap-Datei auf der Festplatte ausgelagert werden
- dadurch über alle Programme summiert meist deutlich mehr virtueller Speicher zugewiesen, als tatsächlich physischer Speicher vorhanden ist
- wenn ein Programm auf eine im Arbeitsspeicher fehlende Seite zugreift, erzeugt die MMU einen Interrupt (Page Fault), sodass das Betriebssystem die fehlende Seite transparent nachladen kann
- analog dazu: Memory-Mapping von Dateiinhalten direkt in den Arbeitsspeicher
wenn wir schon mal über Speicheradressen reden: Direct Memory Access
- Abbildung eines Arbeitsspeicher-Addressbereiches auf einen Speicher eines angeschlossenen Gerätes, zum Beispiel den Arbeitsspeicher der Grafikkarte oder eines Netzwerkadapters
- dadurch direkter Transfer von Daten zwischen niedrigprivilegierten Prozessen und Hardware möglich, z.B. schnelles Hochladen von Texturen in die Grafikkarte durch ein 3D-Spiel
- DMA braucht nicht unbedingt eine MMU (siehe VGA-Buffer bei 0xB8000 in DOS-Ära-Betriebssystemen)

STP018: DNS im Detail

Thu, 21 Apr 2022 16:15:00 GMT

Nachdem wir das Thema in STP002 schon einmal gestreift haben, wollen wir in dieser Episode genauer darauf eingehen. Woher weiß unser Computer eigentlich, welche IP-Adresse er aufrufen muss, um uns all die schönen Katzenvideos zu zeigen?

Shownotes

Nicht die Desoxyribonukleinsäure, sondern das Domain Name System.

Rückbezüge
- zu STP002 (Aufruf einer Webseite): Webserver haben Domain-Namen, die aufgelöst werden müssen
- zu STP012 (Datenbanken): DNS ist eine globale, verteilte (aber nicht dezentrale!), hierarchische Datenbank
Grundaufgabe: Namensauflösung
- menschenlesbare und stabile Server-Namen anstatt unlesbarer und möglicherweise wechselnder IP-Adressen
- aber auch andere Abfragen möglich, siehe unten
- historischer Vorgänger: /etc/hosts
Aufteilung des Internet in Domains (Domänen) und verschachtelte Subdomains (Unterdomänen)
- Beispiel: Wurzeldomain "." enthält Domain "org" enthält Domain "wikipedia.org" enthält Domain "de.wikipedia.org" -> deswegen hierarchische Datenbank
- wenn die Subdomain einer anderen Person oder Organisation gehört als die Domain darüber, hat man eine neue Zone
- jeder Inhaber einer Zone hält auf einem (oder mehreren) Webserver(n) die Inhalte seiner Zone (also Domain-Daten und Zonenreferenzen) in einem Nameserver -> deswegen verteilte Datenbank
Wurzelzone ist unter der Kontrolle der ICANN -> deswegen nicht dezentrale Datenbank
- Verteilung der Wurzelzone durch die Root-Nameserver
- finanzieller Anreiz zum Erlauben von immer mehr Top-Level-Domains (TLD)
Einträge in einer DNS-Zone heißen Records (Datensätze), mehrere Record Types möglich:
- A, AAAA: IP-Adresse zu einer Domain (A = IPv4, AAAA = IPv6)
- CNAME: Domain-Alias (anstatt direkt eine IP zu erhalten, erhält man eine andere Domain, die man stattdessen nach der finalen IP fragen muss)
- PTR: Rückwärtsabfrage, Domain zu einer IP-Adresse
- MX: Mail-Server zu einer Domain
- SRV: ähnlich wie MX, aber für beliebige Dienste (z.B. XMPP)
- TXT: beliebige Textinformationen (wird zum Beispiel für Mail-Empfangsregeln verwendet)
- NS: Zonendelegation, die entsprechende Domain ist der Ausgangspunkt einer Unterzone und der Record enthält den autoritativen Nameserver für diese Zone
Abfrage einer bestimmten Domain
- Grundidee: zuerst Root-Nameserver fragen, der delegiert an den Nameserver der TLD, der delegiert an den Nameserver der Second-Level-Domain, etc.
- Problem: absurd hohe Last auf die Root-Nameserver
- Lösung 1: jeder Eintrag in einer Nameserver-Datenbank hat eine TTL ("Time to Live")
- Lösung 2: Endnutzer reden nicht direkt mit den autoritativen Nameservern, sondern mit Vermittlern (Resolver), die sie sich mit anderen Endnutzern teilen
Komplexbeispiel: Abfrage von de.wikipedia.org über die Root-Nameserver mit dem Unix-Tool dig (Ausgaben stark gekürzt)

$ dig A de.wikipedia.org @m.root-servers.net

;; QUESTION SECTION:
;de.wikipedia.org.              IN      A
;; AUTHORITY SECTION:
org.                    172800  IN      NS      a0.org.afilias-nst.info.
...
;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 172800 IN      A       199.19.56.1
...

$ dig A de.wikipedia.org @199.19.56.1

;; QUESTION SECTION:
;de.wikipedia.org.              IN      A
;; AUTHORITY SECTION:
wikipedia.org.          86400   IN      NS      ns0.wikimedia.org.
...
;; ADDITIONAL SECTION:
ns0.wikimedia.org.      86400   IN      A       208.80.154.238
...

$ dig A de.wikipedia.org @208.80.154.238

;; QUESTION SECTION:
;de.wikipedia.org.              IN      A
;; ANSWER SECTION:
de.wikipedia.org.       86400   IN      CNAME   dyna.wikimedia.org.

$ dig A dyna.wikimedia.org @199.19.56.1

;; QUESTION SECTION:
;dyna.wikimedia.org.            IN      A
;; AUTHORITY SECTION:
wikimedia.org.          86400   IN      NS      ns0.wikimedia.org.
...
;; ADDITIONAL SECTION:
ns0.wikimedia.org.      86400   IN      A       208.80.154.238
...

$ dig A dyna.wikimedia.org @208.80.154.238

;; QUESTION SECTION:
;dyna.wikimedia.org.            IN      A
;; ANSWER SECTION:
dyna.wikimedia.org.     600     IN      A       91.198.174.192

zum Vergleich: Abfrage von de.wikipedia.org über einen öffentlichen Resolver (beachte die unterschiedlichen TTL-Werte)

$ dig A de.wikipedia.org @9.9.9.9

;; QUESTION SECTION:
;de.wikipedia.org.              IN      A
;; ANSWER SECTION:
de.wikipedia.org.       32533   IN      CNAME   dyna.wikimedia.org.
dyna.wikimedia.org.     227     IN      A       91.198.174.192

Beispiel: Rückwärtsabfrage der so erhaltenen IP mittels PTR-Record unter der Pseudo-Domain in-addr.arpa

dig PTR 192.174.198.91.in-addr.arpa
;; QUESTION SECTION:
;192.174.198.91.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
192.174.198.91.in-addr.arpa. 1104 IN    PTR     text-lb.esams.wikimedia.org.

Woher kommt der Resolver?
- normalerweise über DHCP (auf demselben Wege, über den das eigene Gerät eine IP-Adresse vom Router bekommt; oder über den der Router eine IP-Adresse vom ISP bekommt), unter Unix siehe /etc/resolv.conf
- somit meist ein Resolver unter Kontrolle des ISP
- alternative Resolver: z.B. 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.{9,10,11} (Quad9), 5.9.164.112 (Digitalcourage)
- Resolverwahl: Implikationen für Privatsphäre und für Vertrauenswürdigkeit
DNS selbst ist unverschlüsselt -> neuere Entwicklung: DNS-over-TLS und DNS-over-HTTP
- eigentlich würde DNS-over-TLS reichen, aber kann dann vom ISP geblockt werden; HTTP hingegen ist aus praktischen Gründen quasi unblockbar
- Unterstützung in Betriebssystemen noch lückenhaft, aber Browser können DoT und DoH am Betriebssystem vorbei machen (Browsereinstellungen prüfen!)
alternative DNS-Roots: meist in privaten Netzen (z.B. Firmen-Intranet mit .corp-Domains), aber es gibt auch alternative Roots mit globalem Anspruch (z.B. Namecoin)

STP017: Lokalisierung

Thu, 31 Mar 2022 16:30:00 GMT

Mit den Eigenheiten verschiedener Kultur- und Sprachräume hat wohl jeder schon so seine Erfahrungen gesammelt. In der aktuellen Episode soll es um die ortsbezogenen Einstellungen von Computersystemen gehen. Und natürlich gibt uns das ein weiteres Mal die Möglichkeit, abschätzig über imperiale Einheiten zu sprechen.

Shownotes

Letztes Mal hatten wir Komplikationen wegen der Zeit, diesmal wegen des Raumes. :)

vergleiche: Lokalisierung bei Filmen
- Übersetzung als Untertitel, Voice-Over oder Synchronisation
- viele Schwierigkeiten der Medienlokalisierung spiegeln sich im Softwarefall
  - Beispiel: Formulierung der Übersetzung muss sich an die verfügbare Zeit im Film anpassen
  - in Software müssen übersetzte Beschriftungen in das ursprüngliche Layout reinpassen
Softwarelokalisierung: zwei getrennte Schritte
- Internationalisierung (i18n): Gestaltung des Programms derart, dass es einfach an verschiedene Sprachen und Kulturen angepasst werden kann -> Aufgabe für den Entwickler
- Lokalisierung (l10n): der Akt der Anpassung an eine Zielsprache -> Aufgabe für den Übersetzer
Aspekte von Internationalisierung anhand der Locale-Einstellungen in Unix-Systemen (siehe man 7 locale)
- LC_MESSAGES: Sprache für übersetzte Texte
- LC_TIME, LC_DATE: Darstellung von Datums- und Zeitangaben (siehe XKCD 2562 und XKCD 1179)
- LC_COLLATE: alphabetische Sortierreihenfolge (siehe Wikipedia, z.B. Deutsch sortiert "ä" wie "a", aber Dänisch sortiert "ä" hinter "z")
- LC_NUMERIC, LC_MONETARY: Darstellung von Zahlen und Währungsangaben (z.B. Dezimalpunkt vs. Komma, Tausendertrennzeichen, Währungszeichen vor oder hinter dem Wert)
- LC_NAME: Anreden (z.B. "Herr" und "Frau" im Deutschen)
- LC_MEASUREMENT: Größenangaben in imperialen oder metrischen Einheiten
- LC_PAPER: Standard-Papierformat für Dokumente (z.B. DIN A4 in Deutschland, aber Letter in USA)
- LC_CTYPE (character type): Standard-Zeichensatz für Dateien
- usw.
mögliche Werte für eine Locale-Wahl in Unix
- klassisch: de_DE, de_AT, de_CH, en_US, en_GB usw.
- mit UTF-8-Präferenz: de_DE.UTF-8, en_US.UTF-8 usw.
- Spezialfall: LC_MESSAGES=C zeigt Texte, wie sie im originalen Quelltext stehen
- gemischte Konfiguration möglich, z.B. Xyrill hat fast überall de_DE.UTF-8, aber LC_MESSAGES=C
Aufgaben des Softwareentwicklers bei i18n
- Verwendung von internationalisierbaren Betriebssystemfunktionen oder Programmbibliotheken, wann immer Ein- und Ausgaben lokalitätsabhängig sind
- Testen von grafischen Oberflächen im Right-to-Left-Modus (in Sprachen mit RTL-Schrift läuft auch das GUI-Layout von rechts nach links, siehe z.B. arabische Wikipedia)
- Formulierung von übersetzbaren Texten derart, dass die Übersetzer möglichst gut arbeiten können
  - Angabe von Kontext (z.B. Beschriftungstext "Match" -> Ist das das Verb "Abgleichen" oder das Substantiv "Treffer"? Oder gar "Streichholz"?)
  - bei Textbaustein mit Zahlenparameter Berücksichtigung sprachabhängiger Pluralformen (im meist englischen Original wird ein Singulartext und ein Pluraltext bereitgestellt, z.B. 1 match und %d matches; die Übersetzer können je nach Notwendigkeit beliebig viele Formen angeben)
Arbeitsablauf für Übersetzung am Beispiel GNU gettext
- Programmierer fügt Textmeldungen ("Nachrichten") im englischen Original in den Quelltext ein
- Maintainer erstellt mittels Hilfsprogramm aus dem Quelltext einen Nachrichtenkatalog für jede gewünschte Zielsprache (meist automatisiert, z.B. täglich oder wöchentlich)
- Übersetzer erhält den Nachrichtenkatalog und füllt die Übersetzungen ein
- zukünftige Änderungen der Originalnachrichten werden mit den bestehenden Nachrichtenkatalogen zusammengeführt
- Anekdote: x-test
Fundstück: Amtssprachen der Europäischen Union

STP016: Zeitdarstellung

Thu, 10 Mar 2022 18:00:00 GMT

Heute brechen wir das fünfte Bit an. Das tun wir mit einem Thema, das scheinbar einfach ist, sich allerdings bei genauerer Betrachtung als tückisch herausstellt. Es geht um Zeit und ihre Darstellung. Und darum, dass es nicht immer sinnvoll ist, sich seinen eigenen Kalender auzudenken. Außerdem überzeugt ttimeless duch überragende Excel-Kentnisse.

Shownotes

Zeiteinteilung ist ganz schön unhandlich
- Kalender orientieren sich an astronomischen Fakten, die leider keine schönen ganzzahligen Einteilungen erlauben (1 Sonnenjahr = 365,242... Tage, 1 Mondmonat = 29.530... Tage, etc.)
- präzise Definition von kleinen Zeiteinheiten wie Sekunden zeigt, dass die astronomischen Fakten schwanken -> Schaltsekunden; später mehr
- Zielkonflikt: möglichst gleichmäßige Zeitentwicklung oder möglichst intuitive Handhabung
- Internationale Atomzeit (TAI): exakt gleichmäßig (im Rahmen der Genauigkeit der Atomuhr), berücksichtigt nicht Schwankungen in der Tageslänge durch Änderungen der Erdrotationsgeschwindigkeit
- Koordinierte Weltzeit (UTC): TAI zuzüglich Schaltsekunden (zurzeit TAI = UTC + 37s), sodass der Tagesbeginn am nullten Breitengrad immer bei 00:00:00 Uhr UTC bleibt

Wie können Computer Zeit darstellen?

Option 1: separate Zahlen für Jahr, Monat, Tag, Stunde, Minute, Sekunde
- Verwendung vor allem an Stellen, wo der Nutzer es sehen kann (Zeitanzeigen, Zeitstempel in Dateinamen etc.)
- Vorteil: sofort menschenlesbar
- Nachteil: muss für Eindeutigkeit immer mit Zeitzoneninformation verknüpft sein; Gültigkeit von zukünftigen Zeitangaben evtl. durch nicht vorhergesehene Zeitzonenänderungen beeinträchtigt
- Nachteil: textuelle Darstellung je nach Kulturkreis uneindeutig (z.B. "4/7/2021" kann entweder für den 4. Juli oder den 7. April stehen)
Option 2: eine einzelne Zahl, die die vergangene Zeit in einer bestimmten Einheit (z.B. Sekunden oder Tage) seit einem Startzeitpunkt (der Epoche) angibt
- z.B. Unix: Sekunden seit 1. Januar 1970 00:00:00 Uhr UTC (bzw. 01:00:00 Uhr deutscher Zeit)
- z.B. julianisches Datum: Tage seit 1. Januar 4713 v.u.Z.
- z.B. Excel, LibreOffice Calc, etc.: Tage seit 1. Januar 1900, mit Nachkommastellen für Zeitpunkte innerhalb eines Tages
Probleme durch Überlauf in Datumsfeldern
- Y2K-Problem: Überlauf in der Jahreszahl, die damals zweistellig angegeben war (z.B. "76" für 1976)
- Y2038-Problem: Überlauf in einem 32-Bit-Unix-Zeitstempel (am Dienstag, dem 19. Januar 2038 um 04:14:07 Uhr deutscher Zeit)
- GPS-Wochen-Rollover: Überlauf in der Wochenzahl des Zeitstempel-Formats von GPS; erstmals 1999, zuletzt 2019, nächstes Mal 2038
Probleme durch astronomische/politische Fakten
- Berechnungen wie "10 Tage dazuaddieren" mühselig aufgrund Kalenderregeln (Monatswechsel, Schalttage etc.)
  - Beispiel: in einer Terminserie wie "täglich um 15 Uhr" hat wegen Sommerzeitwechsel nicht jeder Termin genau 24 Stunden Abstand zueinander
  - Beispiel: Sommerzeitumstellung bei der Eisenbahn (diesen Abschnitt können wir im Prinzip direkt vorlesen)
- Schaltsekunden lassen UTC springen und erzeugen unerwartete Zeitzustände wie "23:59:60"
- Zeitzonendefinitionen folgen politischen Entscheidungen
  - z.B. Deutschland besteht in tzdata aus zwei Zeitzonen
  - z.B. 2015 Chaos in der Türkei durch eine Änderung der Sommerzeitregel mit zu wenig Vorlauf
Probleme durch technische Einflüsse
- Hardware-Uhren sind nicht hinreichend genau und driften mit der Zeit: in verteilten Systemen mögliche Verwirrung über die Reihenfolge von Aktionen
- Zeitsynchronisation mittels NTP (Network Time Protocol): im Moment der Richtigstellung der Uhr mögliche Verwirrung durch einen kleinen Sprung rückwärts in der Zeit
- Suspend/Standby: im Moment des Wiederanschaltens mögliche Verwirrung durch einen drastischen Sprung vorwärts in der Zeit
- monotonische Uhren: zählen die Zeit, die der Computer seit Systemstart gelaufen sind (z.B. mittels TSC; damit zuverlässige Messung von Laufzeitspannen etc.
positiver Ausblick: Es könnte noch viel schlimmer sein!
- gregorianischer Kalender hat sich weltweit für den Geschäftsverkehr durchgesetzt
- Beispiel für einen alternativen Kalender: Japanische Zeitrechnung
kryptografisch abgesicherte Zeitstempel: RFC Podcast #15 Crypto for the Masses

STP015: Multitasking in Betriebssystemen

Thu, 17 Feb 2022 17:40:00 GMT

Um viele Dinge gefühlt gleichzeitig tun zu können, ist die Computertechnik einen weiten Weg gegangen. In der heutigen Folge halten wir viele lose Fäden in der Hand und ständig merkt Xyrill, dass dies und jenes ja auch noch notwendig ist, um zum Ziel zu kommen: Zu Multitasking.

Shownotes

Vorbemerkung: Begriffsklärung Programm vs. Prozess
- Programm: ein bestimmtes Stück Maschinencode, das zumeist auf der Festplatte vorgehalten wird
- Prozess: eine bestimmte Laufzeitinstanz eines Programms
- Prozess = Programm + zugehörige Daten im Speicher + zugehörige Berechtigungen etc.
Multitasking: Ausführung mehrerer Aufgaben zur selben Zeit oder abwechselnd in kurzen Zeitabschnitten
- konkurrente Ausführung: abwechselnd in kurzen Zeitabschnitten
- parallelle Ausführung: zur selben Zeit (z.B. Parallelbearbeitung mehrerer Daten in der GPU, Parallelität in mehreren CPU-Kernen); heute nicht so sehr im Fokus
Analogie: Multitasking beim Menschen
- Idee 1: tatsächlich parallele Ausführung, z.B. gehen und gleichzeitig sprechen
- Idee 2: Teilaufgaben an einer jeweils sinnvollen Stelle unterbrechen und während der Wartezeiten etwas anderes machen, z.B. Kochen/Backen (entspricht dem kooperativen Multitasking)
- Idee 3: Teilaufgaben nach einer bestimmten Zeit oder bei äußeren Ereignissen unterbrechen, z.B. Büroarbeit (entspricht dem präemptiven Multitasking)
kooperatives Multitasking: Prozesse unterbrechen sich selbst, wenn sich abzeichnet, dass sie warten müssen
- z.B. auf das Lesen von Daten von der Festplatte oder eine Antwort aus dem Netzwerk
- Problem 1: jedes Programm muss Unterbrechungspunkte enthalten
- Problem 2: unkooperative Programme (z.B. fehlerhafte oder Schadsoftware) können das gesamte System blockieren
- weit verbreitet in der Ära der frühen Heimcomputer (C64, DOS-PCs, Macs bis Mac OS 9)
- heute nicht mehr im Einsatz, da moderne Prozessoren interruptfähig sind und somit präemptives Multitasking möglich ist
präemptives Multitasking: Prozesse werden nach dem Ablauf ihrer zugeteilten Zeitscheibe unterbrochen, damit jemand anderes drankommen kann
- bevor der Prozess drankommt, stellt das Betriebssystem einen Hardware-Timer in der CPU
- nach Ablauf des Timers löst die CPU einen Interrupt (eine Unterbrechung) aus
- CPU unterbricht die Arbeit am Prozess und führt eine vom Betriebssystem definierte ISR (Interrupt Service Routine) aus
- ISR speichert den Zustand des Prozesses (insb. die Inhalte aller Prozessor-Register) und gibt die Ausführung zurück an den Scheduler
- um Prozess später wiederherzustellen, werden im Prinzip einfach alle Prozessor-Register auf die gesicherten Werte zurückgesetzt
Scheduler (Zeitplaner): Komponente des Betriebssystems, die den jeweils nächsten Prozess wählt, der laufen darf
- interne Buchführung des Schedulers unterscheidet zwischen lauffähigen und nicht lauffähigen Prozessen
- ist ein laufender Prozess nicht mehr lauffähig (weil auf I/O gewartet werden muss), kann er auch selbst einen Interrupt auslösen und wird dann im Scheduler als nicht lauffähig markiert
- nächster Prozess wird immer aus der Liste der lauffähigen Prozesse gewählt, nach Kriterien wie Priorität (z.B. Audio-Prozesse)
- gibt es keinen lauffähigen Prozess, kann die CPU bis zum nächsten Interrupt angehalten werden
Wie werden Prozesse wieder lauffähig?
- Eingabe von der Hardwareseite (z.B. Netzwerk, Festplatte) erzeugt ebenfalls Interrupts, auf die das Betriebssystem reagiert
- Eingabe von anderen Prozessen (z.B. via Pipes) landet direkt beim Betriebssystem
- Betriebssystem stellt die Daten dem entsprechenden Prozess bereit und markiert diesen wieder als lauffähig
- analog bei vollgelaufenen Ausgabepuffern

STP014: Textdarstellung

Thu, 27 Jan 2022 02:00:00 GMT

In dieser Folge unterhalten wir uns über allerlei Detailwissen zu verschiedenen Schriftarten, werfen mit schlecht vorbereiteten Beispielen um uns und haben starke Meinungen zu verschiedenen Dingen. Um Textdarstellung geht es dabei nebenbei auch.

Shownotes

Nachbemerkungen zum letzten Mal: bidirektionaler Text
- Mischung aus LTR-Schrift (left to right) und RTL-Schrift (right to left), z.B. hebräische oder arabische Zitate in lateinischer Schrift
- in der Zeichenkette entsprechend der logischen Reihenfolge
- in der Darstellung: Zeichen können (aber müssen nicht) eine präferierte Schreibrichtung haben, explizite Umschaltung der Schreibrichtung mit Steuerzeichen möglich
Grundbegriffe
- "Zeichen": wird im Bereich von Unicode kaum verwendet, da nicht klar definiert
- Graphem: die kleinste bedeutungsunterscheidende (aber nicht bedeutungstragende) Einheit eines Schriftsystems (z.B. lateinische Schrift: Buchstaben, Ziffern, Sonderzeichen, Leerzeichen); in Unicode ungefähr gleichsetzbar mit einem Codepunkt (abgesehen von Steuerzeichen)
- Glyphe: die grafische Darstellung eines Graphems
- Schriftart/Font: ein vollständiger Satz von Glyphen
Unterschiede zwischen Schriftarten
- Serifenschriften vs. serifenlose, insb. Groteskschriften
- Proportionalschriften vs. Monospace-Schriften
- Spezialanwendungen: OCR-A, FE-Schrift, Schriften zur Unterstützung von Analphabeten (unter den bekannten Schriften insbesondere Comic Sans)
- Beispiel aus Asien: Ming vs. Gothic vs. Kalligrafie
Phase 1: Textlayout
- Segmentierung in Wörter, Zeilen, Absätze, evtl. Seiten
- abhängig von den Regeln der verwendeten Schriftsysteme, siehe z.B. UAX 14: Unicode Line Breaking Algorithm
- abhängig von der Schreibrichtung, interessant insbesondere bei bidirektionalem Text
  - Unicode beschreibt fast ausschließlich zeilenweises Layout mit LTR oder RTL
  - im Japanischen ist auch spaltenweises Layout mit TTB (top to bottom) gängig, siehe UTR 50: Unicode Vertical Text Layout
- Ruby: Ausspracheannotationen an CJK-Schriftzeichen, außerhalb der eigentlichen Textzeile (in LTR darüber, in TTB rechts daneben)
Phase 2: Schriftwahl
- kaum ein Font deckt alle Grapheme ab -> im Allgemeinen Auswahl verschiedener Fonts je nach Schriftsystem notwendig (Font Stack)
- in europäischen Texten früher kaum relevant, heute wichtig wegen separater Emoji-Fonts
- Schriftgröße früher wichtig, da manche Fonts nur als Bitmaps in festen Größen vorlagen; heute durch Vektorschriftarten kein Problem mehr
- Schriftwahl beeinflusst Phase 1: verschiedene Schriften laufen unterschiedlich weit und ergeben somit andere Zeilenumbruchspunkte
Phase 3: Glyphenwahl
- einfacher Fall: eine Glyphe für ein Graphem
- allgemeiner Fall: Bildung von Graphem-Clustern
  - z.B. Ligaturen: "f" + "l" = "ﬂ"
  - z.B. kombinierende diakritische Zeichen: "a" + "◌́" = "á"
  - z.B. Emoji-Hautfarben: "👨" + Fitzpatrick Modifier 1-2 = "👨🏻"
  - z.B. Emoji-Flaggen: "🇩" + "🇪" = "🇩🇪"
  - z.B. Fonts mit kreativer Verwendung von Ligaturen: Sans Bullshit Sans, Fira Code
- anspruchsvollster Fall: Complex text layout, sprich: Anpassung von Glyphen an ihre Nachbarglyphen
  - v.a. im Arabischen und in indischen Schriften, aber auch z.B. in handschriftartigen Fonts
- auch Glyphenwahl beeinflusst Phase 1, aus demselben Grund wie oben
Phase 4: Darstellung
- Glyphen aus Vektorschriftarten werden in den gewünschten Schriftgrößen gerendert und vorgehalten
- dann "einfach" Zusammensetzen der Glyphen zu einem Gesamtbild unter Anwendung der gewünschten Textfarbe
- Ausnahme: Emoji-Glyphen folgen meist nicht der Schriftfarbe
Quelle: Spezifikationen und Reports des Unicode Consortium
Hörempfehlung: CRE080 Geschichte der Typografie

STP013: Textkodierung

Thu, 06 Jan 2022 00:00:00 GMT

Dies ist ein Text. Für den Computer besteht er nur aus Zahlen. Xyrill erklärt diesmal, wie es kommt, dass wir ihn trotzdem lesen können. Und jedes andere geschriebene Wort, das je existiert hat… natürlich nur idealtypisch.

Shownotes

Laut Wiktionary:

[Text ist eine] mündliche oder schriftliche Folge von Sätzen, die miteinander syntaktisch und semantisch verbunden sind (Kohärenz, Kohäsion), eine abgeschlossene Einheit bilden (Kompletion) und eine bestimmte kommunikative Funktion (Textfunktion) erfüllen.

[Von] lateinisch textus für "Inhalt" oder "Gewebe der Rede", "Text".

zur Definition
- Wiktionary geht vom linguistischen Blickwinkel aus
- in der Informatik: Zeichenketten (oder synonym "Zeichenfolgen"), in Programmiersprachen meist als String bezeichnet
Problem: Computer können nur Zahlen! Wie bilden wir Zeichenketten als Zahlenfolgen ab?
- Idee 1: jedes Zeichen als eine Zahl einer bestimmten Größe, z.B. 1 Byte oder 2 Byte (fixed-length code)
  - primitives Beispiel: alle Buchstaben des Alphabets durch ihre Position darstellen, z.B. "hallo" -> "08 01 12 12 15"
- Idee 2: häufige Zeichen mit kurzen Bytefolgen darstellen, seltene Zeichen mit längeren Bytefolgen (variable-length code, siehe Entropiekodierung)
Beispiel: Morse-Code
- variable Länge: z.B. "e" ist am häufigsten und deswegen nur 1 Ton kurz, "q" ist sehr selten und deswegen 4 Töne lang
- Kodiertabelle enthält nicht nur Buchstaben und Ziffern, sondern auch Sonderzeichen (Punkt, Komma, etc.) und Spezialzeichen wie "Spruchende" oder "Fehler, Wiederholung ab letztem vollständigem Wort"
in der frühen Informatik (bis in die 1990er Jahre): Codepages (Zeichentabellen)
- Codes mit fester Länge von meist 1 Byte (7 oder 8 Bit) pro Zeichen
- Beispiel mit 7 Bit: ASCII, unter Linux siehe man ascii (RFC 20)
- Beispiel mit 8 Bit: Codepage 437
- Standardisierung als ISO/IEC 8859
- Problem: 8 Bit (256 Zeichen) sind zu wenig für alle in europäischen Sprachen verwendeten Zeichen, insb. wegen diakritischer Zeichen -> verschiedene Codepages für verschiedene Sprachen -> Mojibake
- spätestens mit zunehmend globaler Kommunikation im Internetzeitalter musste eine bessere Lösung her
Unicode
- keine Textkodierung im engeren Sinne, sondern erstmal nur eine durchnummerierte Liste aller möglichen Zeichen (die Nummer zu einem Zeichen heißt Codepunkt)
- Anspruch: wenn ein Zeichen in tatsächlichen Textdokumenten verwendet wird oder wurde, gehört es in Unicode (von Buchstaben über Redigierungssymbole mittelalterlicher Typografen bis zu Hieroglyphen und Keilschrift)
- Größe: 17 Ebenen (Planes) zu je 65536 Codepunkten = 1.114.112 Codepunkte; davon sind 2048 Codepunkte aus technischen Gründen (für die Kodierung von Surrogatpaaren) unbelegbar, somit maximal möglich 1.112.064 Codepunkte
Ebenen in Unicode
- Ebene 0: Basic Multilingual Plane mit allen zeitgenössischen und weitverbreiteten Schriftsystemen (Übersichtskarte)
- Ebene 1: Supplementary Multilingual Plane mit historischen Schriftsystemen und Obskuritäten wie Domino/Mahjongg-Steinen und 😍 Emoji 😍
- Ebene 2: Supplementary Ideographic Plane mit selten benutzten CJK-Schriftzeichen
- Ebene 3-13: noch frei
- Ebene 14: Supplementary Special-purpose Plane mit Steuerzeichen zur Selektion alternativer Schriftzeichenformen
- Ebene 15/16: für private Verwendung reserviert
Kodierungen für Unicode mit fixer Länge
- UCS-2: eine 16-Bit-Zahl pro Zeichen -> kann nur die BMP kodieren (UCS-2 stammt aus der Zeit, bevor Unicode mehrere Planes hatte)
- UCS-4/UTF-32: eine 32-Bit-Zahl pro Zeichen -> extrem verschwenderisch
Kodierungen für Unicode mit variabler Länge
- UTF-16: BMP-Zeichen als eine 16-Bit-Zahl, andere Zeichen als zwei 16-Bit-Zahlen -> Probleme mit Endianness
- UTF-8: jedes ASCII-Zeichen als ein Byte, alle anderen Zeichen als eine Folge von 2-5 Bytes (unter Linux siehe man utf-8)
- UTF-8 ist spektakulär: sehr kompakt, selbstsynchronisierend, einfach zu implementieren (auch in Hardware), sortierungserhaltend, ASCII-abwärtskompatibel, Nicht-ASCII-Zeichen enthalten niemals ASCII-Bytes; und wurde buchstäblich in einem Abend von Ken Thompson und Rob Pike auf einer Serviette entworfen
Probleme von Unicode
- Anspruch: jeder bestehende Kodierungsstandard soll Zeichen für Zeichen in Unicode abbildbar sein -> dadurch unnötig viele Codepunkte insb. für diakritische Zeichen und Probleme mit Normalisierung
- allgemeiner: Was ist eigentlich ein Zeichen im Sinne von "ein Codepunkt"? (mehr dazu in der nächsten Folge) -> Unicode übernimmt hier oftmals teils kontroverse Klassifikationen aus nationalen Standards z.B. für indische und thailändische Schriften
- am signifikantesten hier: Han-Vereinheitlichung (Beispiel)

Für die historische Herleitung von Schriftkodierung empfehlen wir wieder den großartigen Podcast Request for Comments. Diesmal die Folge über RFC 20 ASCII.

Das nächste Mal geht es dann um T̪͙̪̻̹̩̠͔͑͋ͥ͘ę̥͔̝̘ͦͬx̨̜̩̜͙̦̻̗̳̒̊͆t̯̳̓ͥ͐ͣ́d͔̱̗̯̪̭́͛͜ͅa̵͕̯͕̻̜ͮ͒ͭȓ̜͚͚̯͎͓̋̎̈́͘s̥̯̠̬̆̿͡t̫̱̺͉̱̓͒͑͐͢e̸͖̮̙̺̠̗̬̅ͅl̝͉͚ͪ͋ͤ͜l̵̦̪͔͈̉͑u̴̝̲̠̳̖̘͚̔n͙̹̍̆͊̈͢g̨͍̣̝̣͇̯̮̠̏.

STP012: Datenbanken

Thu, 16 Dec 2021 16:50:00 GMT

Wenn Sie diese Folge sehen, dann, weil sie in der Datenbank Ihrer Podcast-App gelandet ist. Datenbanken sind überall, denn ohne sichere und effiziente Datenhaltung kommt kein technisches System zurecht. Deswegen erklärt Xyrill uns heute, warum Biologen sich über Excel aufregen und was gute Datenspeicher mit Säure zu tun haben.

Shownotes

Laut Wikipedia:

Eine Datenbank, auch Datenbanksystem genannt, ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe einer Datenbank ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern und benötigte Teilmengen in unterschiedlichen, bedarfsgerechten Darstellungsformen für Benutzer und Anwendungsprogramme bereitzustellen.

Beispiele für Datenbanken im weitesten Sinne: Passen diese mit der Definition oben zusammen?
- Spreadsheets (Excel etc.)
  - was funktioniert: unterschiedliche, bedarfsgerechte Darstellungsformen
  - keine widerspruchsfreie Speicherung: Beispiel Gen-Namen-Fehlformatierung
  - keine großen Datenmengen: Beispiel verlorene Covid-Patienten aufgrund Beschränkung auf 1 Mio. Zeilen
- Dateisystem
  - was funktioniert: große Datenmengen effizient und dauerhaft speichern
  - keine widerspruchsfreie Speicherung, da keine Beziehungen zwischen Dateiinhalten möglich
  - keine Unterstützung für bedarfsgerechte Darstellungsformen: jede Datei hat genau ein Format
Dateisysteme sind eine besondere Form von Key-Value-Datenbank
- Datenbasis = ein großer Haufen von Values (Werte, im allgemeinen Fall beliebige Dateien), die alle einen Namen (Key) haben
- keine Datenbank im engeren Sinne (keine Sicherstellung von Widerspruchsfreiheit, keine Unterstützung für bedarfsgerechte Darstellungsformen)
- aber in der Praxis eine sinnvolle Ergänzung zu stark strukturierten Datenbanken, da die einfache Datenstruktur es ermöglicht, sehr groß zu skalieren (bis Milliarden/Billionen von individuellen Objekten)
- Praxisbeispiel: Cache für vorgerenderte Wikipedia-Seiten
Datenbanken im engeren Sinne: relationale Datenbanken
- Daten liegen in einer bestimmten Struktur vor: gleichartige Objekte sind jeweils als Zeilen in Tabellen abgelegt, deren Spalten im Voraus definiert sind (diese Grundstruktur nennt man Schema)
- "relational": Kreuzreferenzen zwischen Tabellenspalten (Beispiel: wenn die Tabelle "Mitarbeiter" eine Spalte "Abteilungsnummer" hat, muss es für jeden Wert in dieser Spalte eine entsprechende Zeile in der Tabelle "Abteilungen" geben), unter anderem dadurch Sicherstellung der Widerspruchsfreiheit
- strukturierte Datenhaltung ermöglicht komplexe Abfragen (z.B. "Wieviele Mitarbeiter in der Abteilung 172 haben ein Monatsgehalt über 3000€?"), typischerweise mittels SQL (Structured Query Language)
Grundkriterien für das Verhalten von relationalen Datenbanken: ACID am Beispiel "Überweisung zwischen zwei Bankkonten"
- Atomarität (Abgeschlossenheit)
  - Änderungen werden entweder ganz oder gar nicht vorgenommen
  - am Beispiel: Überweisung muss immer beide Bankkonten anfassen (oder komplett fehlschlagen)
- Konsistenzerhaltung
  - wie oben besprochen: Prüfung von Kreuzreferenzen oder Randbedingungen
  - am Beispiel: Überweisung darf nur durchgehen, wenn das Quellkonto genug Füllstand hat
- Isolation (Abgrenzung)
  - parallel laufende Änderungen dürfen nicht dieselbe Zeile anfassen
  - im Zweifelsfall muss eine Änderung warten, bis die andere fertig ist
  - am Beispiel: Deckungsprüfung im Quellkonto muss alle vorherigen Überweisungen einbeziehen
- Dauerhaftigkeit
  - wird eine Änderung als abgeschlossen gemeldet, darf auch ein Systemfehler (z.B. Systemabsturz oder Stromausfall) nicht zum Verlust der Änderung führen
  - Garantierung der Dauerhaftigkeit ist nichttrivial aufgrund der vielen Schichten der Speicherhierarchie (siehe STP007)
  - Sicherstellung meist in der Datenbanksoftware selbst mittels Write-Ahead Log und drumherum mittels Betriebsprozeduren (Backups, Replikation)
klassisches Problem mit relationalen Datenbanken: Wie klassifiziert man die Welt? Welche Attribute kann man bei Objekten voraussetzen?
- Welche Spalten kann man voraussetzen? z.B. Tabelle "Personen" mit Spalten "Name", "Adresse", "Geburtsdatum", "Geburtsort" -> für alle diese Attribute gibt es Menschen, bei denen dieses Attribut nicht existiert oder unbekannt ist
- Welche Datentypen haben Spalten? z.B. wird die Postleitzahl oft als Nummer abgelegt, sodass dann "01069 Dresden" als "1069 Dresden" fehlverarbeitet wird
- allgemein: Entwurf des Datenbankschemas ist einer dieser Punkte, wo man sich manchmal als Programmierer bewusst wird, wie wenig man das Problemfeld eigentlich verstanden hat
abseits von relationalen Datenbanken und SQL: NoSQL
- großer Hype in den 2010ern vor allem aufgrund der Hoffnung, die lästige Schemaentwurf-Phase los zu werden
- aber: Speichern von unstruktierten oder wenig strukturierten Daten verlagert das Problem nur in die Zukunft
Arten von NoSQL-Datenbanken, die tatsächlich nützlich sind:
- Key-Value-Datenbanken (siehe oben)
- Dokumentendatenbanken für Volltextsuche (z.B. Suchmaschinen)
- Graphdatenbanken (z.B. soziale Graphen)
- Datenströme (Darstellung der Welt als ein zeitlich geordneter Strom von Ereignissen)

STP011: Programmsteuerung im Prozessor

Thu, 25 Nov 2021 00:00:00 GMT

Die CPU ist als der zentrale Baustein praktisch aller Computer bekannt. Nachdem wir schon einen kleinen Blick in ihren Speicher geworfen haben, soll es heute darum gehen, wie dieser Baustein dazu gebracht wird, das Richtige zur rechten Zeit zu tun.

Shownotes

Rückblick: Logikgatter (STP003)
- aus Gattern lassen sich Schaltkreise bilden, die konkrete Einzelberechnungen anstellen
  - hauptsächlich einfache Rechenoperationen wie "zwei 16-Bit-Zahlen addieren"
  - aber auch teils sehr komplexe Einzeloperationen, z.B. Teilschritte einer bestimmten Hashfunktion (siehe STP004) oder eines bestimmten Audio/Video-Codecs (heißt in Produktbeschreibungen meist Hardware-Beschleunigung)
- Frage 1: Wie kann man mehrere Operationen nacheinander ausführen?
- Frage 2: Wie kann man in einem einzelnen Taktschritt aus verschiedenen möglichen Operationen wählen?
- Frage 3: Wie entsteht daraus ein ganzes Programm, also eine bestimmte Folge von verschiedenen Operationen?
Antwort auf Frage 1: Taktgenerator
- analog zum Taktgeber in einer Uhr (Unruh bei mechanischen Uhren, Quartzoszillator bei elektronischen Uhren), aber als mikroeletronische Schaltung realisiert
- Geschwindigkeitsvergleich: bei Quartzuhren hat der Oszillator meist 32768 Hz
- heutzutage ist die Taktfrequenz meistens regelbar
  - 1990er: Turbo-Schalter am Gehäuse zum Verdoppeln (bzw. in der anderen Richtung Halbieren) der Taktfrequenz
  - seit den 2000ern: ACPI und Co., Energiesparen durch bedarfsgerechtes Heruntertakten der CPU-Kerne
  - Heruntertakten als Schutz vor Überhitzung (nach Überlastung oder beim Versagen der Kühlung)
- unter Linux: aktuelle Taktfrequenz auslesen mittels grep '^cpu MHz' /proc/cpuinfo
Antwort auf Frage 2: Arithmetisch-logische Einheit (ALU)
- Idee: neben 2N Eingängen für zwei N-Bit-Eingabezahlen noch weitere Eingänge, die einen Opcode darstellen, also eine fortlaufende Nummer für die gewünschte Rechenoperation
- Opcode bestimmt, von welchem Teilschaltkreis das Ergebnis nach außen durchgereicht wird
- hierzu zusätzliche Logikschaltung am Ende: Ausgabe = ((Opcode = 1) AND Ausgabe1) OR ((Opcode = 2) AND Ausgabe2) OR ...
- analog zur ALU gibt es meist noch eine FPU für Fließkommazahl-Operationen
Antwort auf Frage 3: Steuerwerk in der CPU (oder GPU)
- Programmdatei besteht aus einer Folge von Befehlen, die im Arbeitsspeicher vorliegen
- Steuerwerk hat einen Befehlszeiger (Instruction Pointer), der auf den jeweils nächsten Befehl zeigt
Befehle sind in Maschinensprache kodiert
- meist 16/32/64 Bit groß (je nach Prozessorarchitektur)
- für Rechenbefehle wie "Addition" oder "Multiplikation"
  - den Opcode (welche Berechnung auszuführen ist)
  - aus welchen Prozessorregister die Eingabe kommt (evtl. ist ein Eingabewert eine Konstante wie "0" oder "1" und steckt direkt im Befehl drin)
  - in welches Prozessorregister die Ausgabe geht
- andere Befehlsarten:
  - Load: aus dem Hauptspeicher einen Wert in ein Prozessorregister holen (Parameter: Quelladresse und Zielregister)
  - Store: genau andersherum (Parameter: Quellregister und Zieladresse)
  - Compare: schickt zwei Zahlen aus Registern an die ALU, aber statt einer Ergebniszahl gibt es einen Satz von Flags wie "A ist gleich B" oder "A ist kleiner als B" zurück
  - Jump: aktualisiert den Befehlszeiger, evtl. nur wenn ein bestimmtes Flag gesetzt ist (zum Beispiel Gleichheits-Flag aus einem vorherigen Compare oder Überlauf-Flag aus einer vorherigen Addition)
  - Call/Return: Call macht einen Sprung, aber speichert vorher die aktuelle Position in einen designierten Teil des Arbeitsspeichers; Return springt an den Ursprung des letzten Call zurück (damit verschachtelbare Unterprogramme realisierbar)
Ausführung eines Befehls ist unterteilt in mehrere Schritte
- grobe Skizze der Abarbeitung eines einzelnen Befehls (Schritt 2-5 jeweils nur, sofern für den entsprechenden Befehl zutreffend)
  - Schritt 1: Auslesen und Dekodieren des Befehls
  - Schritt 2: Laden der Eingabewerte aus den entsprechenden Registern
  - Schritt 3: Ausführen des Befehls (z.B. bei Rechenbefehlen mittels der ALU oder FPU)
  - Schritt 4: Speichern des Ausgabewertes im entsprechenden Zielregister
  - Schritt 5: Verschieben des Befehlszeigers auf den Folgebefehl
- in der Praxis meist noch viel mehr Teilschritte (z.B. moderne x86-CPUs: über 40 Pipeline-Schritte)
- Pipelining: wenn ein Befehl einen bestimmten Schritt durchlaufen hat, kann hier meist schon mit dem nächsten Befehl begonnen werden, auch wenn der vorherige Befehl noch nicht komplett abgearbeitet war
- spekulative Ausführung (Speculative Execution): nachfolgende Befehle rechnen mit den Daten, von denen die CPU glaubt, dass sie wahrscheinlich aktuell sein werden, sobald derjenige Befehl tatsächlich an der Reihe ist
- Sprungvorhersage (Branch Prediction): bei einem Sprungbefehl mit Vorbedingung muss die CPU möglichst gut abschätzen, ob die Vorbedingung eintritt und der Sprung vollzogen wird, um die nächsten Befehle vorhersagen zu können
- Verbesserungen in spekulativer Ausführung und Sprungvorhersage sind einer der Hauptgründe, warum Desktop-CPUs auch ohne höhere Taktfrequenzen immer schneller geworden sind
Überlegungen für schnelle Programme
- Sprungbefehle sind für schnelle Programme ein Problem: wenn die CPU einen Sprung falsch vorhersagt, muss nach dem Ausführen des Sprungs die gesamte Pipeline verworfen und neu gefüllt werden
- verschiedene Befehle dauern unterschiedlich lange in der Berechnung (z.B. Multiplikation ist langsamer als Addition ist langsamer als Bit-Shift); entsprechende Austauschungen finden in Compilern meist automatisch statt, z.B. 2 * x -> x + x oder 8 * x -> x << 3

STP010: 3D-Grafik

Thu, 04 Nov 2021 00:00:00 GMT

Heute geht es viel um Spiele. Denn anscheinend sind diese fast das Einzige, das Xyrill und ttimeless einfällt, wenn es um 3D-Grafik geht. Allgemeiner dreht sich diese Folge darum, was es alles braucht, um Körper in virtuellen Welten darzustellen. Der Abschluss der vierteiligen Reihe über Grafik, und was dazu notwendig ist.

Shownotes

Vergleich zu 2D-Desktop-Grafik (STP008)
- Zeichenreihenfolge ist nicht so offensichtlich (Was ist vorne? Was ist hinten?)
- höherer Anspruch an Realismus: dynamische Beleuchtung, Texturierung, etc.
- Randbemerkung: auch 2D-Spiele werden heute meist in einer 3D-Szene aufgebaut
- Grundeinheit für 3D-Modelle: nicht der Pixel, sondern das Polygon (deswegen kommen wir um Fließkommazahlen nicht herum)
Vorbemerkungen zu den folgenden Schritten:
- all dies passiert für jedes Einzelbild von vorne (also bei 60Hz 60-mal pro Sekunde)
- zur Illustration verlinken wir auf Beispielbilder aus den Übungsunterlagen für einen Kurs in 3D-Rendering-Grundlagen
Schritt 1: 3D-Modell mit Polygonen
- Polygon heißt wörtlich "Vieleck", aber 3D-Modelle bestehen meist nur aus Dreiecken
- Polygone mit vier und mehr Ecken können mittels Triangulation in Dreiecke zerlegt werden
- Darstellung eines 3D-Modells als Gitternetz
Schritt 2: Kamera
- grundsätzlich ein Paar aus Blickpunkt und Blickrichtung, aber mit einigen weiteren Parametern
- mathematische Grundlage: Quaternionen
- Sichtfeld (Field of View): beim Menschen 130°; bei Videospielen meist weniger, je nachdem, wieviel Platz der Bildschirm im Sichtfeld einnimmt (z.B. 90° am PC, 60° an Konsolen)
Schritt 3: Ausmalen der Polygone (Rasterisierung)
- Backface Culling (Rückseiten-Auslese): wir werfen alle Polygone weg, die von uns wegzeigen
- Beispiel mit ausgemalten Polygonen nach Backface Culling
- Z-Buffer: wenn wir Polygone ausmalen, dann malen wir nur die Pixel aus, bei denen wir nicht schon Polygone gemalt haben, die näher an der Kamera dran sind
- Beispiel mit ausgemalten Polygonen unter Verwendung des Z-Buffers
Schritt 4: Texturen
- bis jetzt war jedes Polygon einfarbig, jetzt kleben wir Bilder auf (analog zu Modellbausätzen)
- in der Praxis ein großes Bild für das ganze Modell
- jede Ecke jedes Polygons wird zu einem Punkt in der Textur zugeordnet
- Beispiel mit Polygonen, die mit ihrer Textur ausgemalt sind
Einwurf: Was unterscheidet einen Grafikprozessor (GPU) von einem Hauptprozessor (CPU)?
- CPU-Kerne führen einzelne Befehle auf einzelnen Daten aus
- GPU führt einzelne Befehle auf vielen Daten gleichzeitig aus, z.B. Rasterisierung von 10000 Polygonen gleichzeitig oder Z-Buffer-Prüfung für 10000 Pixel gleichzeitig
- dadurch auch für andere massiv parallelisierbare Operationen interessant ("GPGPU", General Purpose GPU), z.B. wissenschaftliche Simulationen, maschinelles Lernen, Passwortknacken
Schritt 5: Shader
- bis jetzt haben wir die Fixed Function Pipeline beschrieben, eine im GPU-Treiber fest vorgegebene Kette von Rendering-Schritten
- neuere GPU (seit den frühen 2000ern) erlauben das Einbetten von eigenen Programmen (Shadern) in die Pipeline
- Vertex Shader: wird einmal pro Vertex (Ecke eines Polygons) aufgerufen, um die 2D-Position auf dem Bildschirm zu berechnen (ansonsten normale Berechnung anhand der konfigurierten Kameraposition)
- Fragment Shader: wird einmal pro Pixel aufgerufen, um gegebenenfalls die Farbe des Pixels zu modifizieren
- Beispiel eines Fragment-Shaders, der eine Farbtextur auf 6 feste Farbstufen reduziert
Schritt 6: Beleuchtung
- bei traditionallen 2D-Spielen mit Sprites war Beleuchtung meist global (z.B. jedes Objekt hat 2 Sprites, einmal für dunkle und einmal für helle Szenen)
- dynamische Beleuchtung: heute meist als Teil des Fragment Shaders
- Beispiel: Phong's Approximation einer natürlichen Beleuchtung
  - 1. Anteil: ambiente Beleuchtung (überall gleich stark, Grundausleuchtung wie in einem Fernsehstudio)
  - 1. Anteil: diffuse Beleuchtung (abhängig davon, wie sehr die beleuchtete Fläche zur Lichtquelle hingewendet ist)
  - 1. Anteil: spekulare Beleuchtung (Glänzen; stark überbetont auf Flächen, die fast exakt zur Lichtquelle hingewendet sind)
es gibt noch so viel mehr: Kantenglättung (Antialiasing), lineares und anisotropisches Filtern, Normal Mapping, Raytracing

STP009: Fließkommazahlen

Thu, 14 Oct 2021 16:40:00 GMT

„Wir nehmen diese Ausrede Grafik, um in diesen Grundlagenfolgen Dinge zu erklären, die überhaupt nichts mit Grafik zu tun zu haben scheinen, aber dann machen wir den Bogen doch wieder zurück.“ Damit schafft Xyrill die passende Einleitung dieser dritten Folge unserer vierteiligen Reihe.

Shownotes

Rückbezug zu STP001: Ganzzahlen
- z.B. 8-Bit-Zahlen: ohne Vorzeichen 0 bis 255 oder mit Vorzeichen -128 bis 127
- Problem 1: Wie stellt man Zahlen mit Nachkommastellen dar?
- Problem 2: Wie stellt man sehr große Zahlen effizient dar?
- zwei Optionen: Festkommazahlen und Fließkommazahlen
Festkommazahlen
- im Prinzip dasselbe wie Ganzzahlen, aber zählt in Schritten von 0,1 oder 0,01 etc.
- Beispiel: Währungsrechnungen oft mit 4 Nachkommastellen (also auf 0,01 Eurocent genau)
- gegenüber Fließkommazahlen: schneller und genauer, aber nicht so flexibel (löst nur Problem 1, nicht Problem 2)
Fließkommazahlen
- grundsätzliche Idee: analog zur wissenschaftlichen Zahlennotation
  - z.B. "1,2 Milliarden": nicht als 1.200.000.000, sondern 1,2 x 10^9
  - z.B. "2 Hunderttausendstel": nicht als 0,000002, sondern 2 x 10^-6
- Vorteil: unabhängig von der Größenordnung kann immer die gleiche Zahl an Ziffern dargestellt werden
- in Computern natürlich nicht zur Basis 10, sondern zur Basis 2
Bestandteile einer Fließkommazahl
- Exponent (E): die Anzahl der Zweierpotenzen
- Mantisse (M): der Teil der Zahl, der nicht in der Potenz steht
- insgesamt also M * 2^E für positive oder -M * 2^E für negative Zahlen
Rechenoperationen ungefähr analog zum Rechenschieber
- z.B. Addition: erst die Exponenten angleichen, dann die Mantissen addieren, dann eventuell nochmal den Exponenten anpassen, damit die finale Darstellung wieder schön kompakt ist
- hier kommt das Überlaufbit aus STP003 wieder ins Spiel
Kodierung: fast immer gemäß IEEE-754-Standard * IEEE
- Problem: wir wollen uns nicht merken müssen, wo in der Mantisse das Komma steht
- Trick: wir schieben das Komma so hin, dass die Mantisse mit 1, anfängt, und speichern dann nur den Teil dahinter (normalisierte Zahlen)
- Ausnahme: beim kleinsten Wert des Exponenten fängt die Mantisse mit 0, an, damit wir auch die Zahl 0 und sehr kleine Zahlen nahe 0 darstellen können (subnormale Zahlen)
- z.B. für 32 Bit: einfache Genauigkeit ("Single Precision")
  - 1 Bit Vorzeichen
  - 8 Bit Exponent (Ganzzahl zwischen -127 und 128)
  - 23 Bit Signifikand (Mantisse ohne das führende 1, oder 0,)
- Werte je nach Exponent:
  - Exponent = -127 -> subnormale Zahlen
  - Exponent = 128 -> spezielle Werte
  - ansonsten -> normalisierte Zahlen
- im Exponent 128 werden einige spezielle Werte kodiert, die man braucht, damit jede Rechenoperation immer eine gültige Fließkommazahl erzeugt:
  - plus Unendlich: z.B. 1 / 0 = +∞ oder ∞ + ∞ = ∞
  - minus Unendlich: z.B. -1 / 0 = -∞ oder log2(0) = -∞
  - keine Zahl (not a number, NaN): z.B. ∞ - ∞ = NaN oder 0 / 0 = NaN oder log2(-1) = NaN
Implementation von Fließkommarechnungen
- initial in Software auf Basis von Ganzzahlen
- seit den 1980ern zunehmend in Hardware (seit den 1990ern auch in PCs)
Fallstricke bei Fließkommarechnungen
- nicht alle kompakten Dezimalzahlen sind kompakte Binärzahlen: z.B. 0.3/0.2 = 1.4999999999999998
- bei komplexen Berechnungen können sich kleine Rundungsfehler zu großen Fehlern aufschaukeln, siehe zum Beispiel Kahan-Summenalgorithmus (leider in Wikipedia nur auf englisch)
Anwendungsbereiche üblicher Fließkommaformate
- doppelte Genauigkeit (64 Bit): für wissenschaftliche Berechnungen
- einfache Genauigkeit (32 Bit): für 3D-Grafik (siehe nächste Folge)
- halbe Genauigkeit (16 Bit), Viertelgenauigkeit (8 Bit): für Training von neuronalen Netzwerken

STP008: 2D-Grafik

Thu, 23 Sep 2021 16:45:00 GMT

Hier nun der zweite Teil unserer Reihe über die Herkunft und Darstellung von Grafik. Genießen sie heute Funfacts und Kaufberatung auf mittelmäßigem Niveau.

Shownotes

computergenerierte Bilder sind rasterisiert (in Bildpunkte unterteilt)
- jeder Bildpunkt hat genau eine Farbe
- generell sind verschiedene Rasterisierungen möglich (z.B. bei Facettenaugen von Insekten meist hexagonale Rasterung)
- bei Computern meist quadratische Pixelraster: vereinfacht Speicherabbildung und bestimmte Berechnungen, die Nachbarpixel einbeziehen
Farbe ist nicht eine einzige Zahl, sondern ein Punkt in einem mehrdimensionalen Farbraum
- verschiedene Farbräume/Farbmodelle je nach Anwendung
  - RGB (Rot-Grün-Blau): für selbstleuchtende Monitore mit drei verschiedenen Grundfarben (Beispiel aus einem CRT-Monitor)
  - YUV (Y-Luminanz, UV-Chrominanz) etc.: für Fernsehbildschirme (abwärtskompatibel zu Schwarzweißfernsehern, die UV ignorieren und nur Y anzeigen)
  - HSV und CIELAB: modellieren die natürliche Farbwahrnehmung des Menschen
  - CMYK (Cyan-Magenta-Yellow-Black): für Druckprozesse mit vier Standardtinten
- Farbräume sind meistens dreidimensional, weil wir drei Arten von Farbrezeptoren im Auge haben (zum Vergleich: Fangschreckenkrebse haben bis zu 12 Rezeptorarten und bräuchten also einen zwölfdimensionalen Farbraum)
Beispielrechnung: Wie groß ist der Datenstrom zu einem normalen Computermonitor?
- angenommen 4K-Auflösung: 3840x2160 Pixel
- angenommen 8 Bit Farbtiefe: 8 Bit pro Pixel und Farbe, also 3 Byte pro Pixel (es gibt auch schon Monitore mit 10 Bit oder 12 Bit Farbtiefe)
- angenommen 60 Hz, also 60 Bilder pro Sekunde
- Ergebnis (ohne Datenkompression): 3840 * 2160 Pixel / Bild * 3 Byte / Pixel * 60 Bilder / Sekunde = 1.39 GiB/s bzw. 11.1 Gib/s
- zum Vergleich: komprimiertes 4K-Video typischerweise 2 MiB/s (16 Mib/s), Kompressionsfaktor ~700
Bildaufbau in traditionellen Systemen mit 2D-Grafik (z.B. Spielkonsolen der 80er und frühen 90er) erfolgt meist mittels Sprites
- Sprites: einzelne vorgefertigte Bilder (z.B. Glyphen einer Terminal-Schriftart oder einzelne Objekte in einem Videospiel)
  - Pixel-Art
- Grafikprozessor erhält eine Liste von Sprites mit den entsprechenden Positionen, an denen diese eingefügt werden sollen
- Bild entsteht als Überlagerung aller Sprites in ein Gesamtbild
- Gesamtbild liegt somit im Videospeicher vor (einem separaten Speicher des Grafikprozessors) und kann dann zum Monitor geschickt werden (siehe auch Double Buffering und V-Sync)
in Abgrenzung dazu: Vektorgrafik
- Beschreibung eines Bildes mittels grafischer Primitiven (Rechtecke, Kreise, Linien, Kurven)
- Bildaufbau durch Rasterisierung dieser Primitiven, z.B. mittels des Bresenham-Algorithmus
- bis Ende der 90er oft mittels separater Koprozessoren (z.B. Super FX), da die normalen Prozessoren nicht schnell genug waren
Bildaufbau in traditionellen Desktopsystemen (z.B. Windows 95 bis XP) ist eine Mischung aus beiden
- Fensterrahmen, Knöpfe etc. als Vektorgrafik (teilweise in Sprites vorgerendert)
- Textsatz ebenfalls auf Basis vorgerenderter Sprites für die einzelnen Zeichen, die wiederum als Vektorgrafik definiert sind
seit den 2000er-Jahren werden auch 2D-Bilder zunehmend auf der Grafikkarte berechnet, denn:
- Grafikkarten bzw. Grafikprozessoren (GPUs) sind seit diesem Punkt hinreichend allgegenwärtig
- GPUs sind für diese Aufgabe deutlich effizienter (sowohl in Geschwindigkeit als auch Energieverbrauch)
- GPUs können auch fortgeschrittene Effekte wie Schattierungen oder Animationen effizient berechnen

STP007: Speicherhierarchie

Thu, 02 Sep 2021 00:00:00 GMT

Für große Teile der Anwender liegt sie im Verborgenen. Versteckt unter Plastik- und Metallgehäusen ist die Welt der Speicher ein ebenso fremder wie faszinierender Ort. Doch auch hier herscht eine strenge Rangordnung, bestimmt allein von Geschwindigkeit und Ausdauer. Hört selbst, welch beschwerlicher Weg sich auftut, wenn Bits sich auf die Reise machen, um verarbeitet zu werden.

Shownotes

Rückbezug zu STP003: Logikgatter
- damit Rechnen möglich
- für Eingabewerte und Ausgabewerte ist ein Speicher erforderlich
Kurzabriss zum Thema Harvard-Architektur vs. Von-Neumann-Architektur
grundsätzliche Arten von Speichern
- flüchtiger Speicher: braucht Strom zum Halten von Daten
- nichtflüchtiger Speicher: behält Daten auch im ausgeschalteten Zustand
- Der ideale Speicher wäre groß, schnell, nichtflüchtig, und beliebig oft wiederbeschreibbar.
- da wir keinen idealen Speicher haben: Speicherhierarchie

In der folgenden Liste der verschiedenen Hierarchiestufen sind alle konkreten Zahlenwerte nur illustrative Beispielwerte für Hardware der aktuellen Generation.

Stufe 1: Festplatte
- nichtflüchtig, groß und günstig (ab etwa 25 Euro pro TiB)
- Zugriffsgeschwindigkeit: 2.5 bis 10 ms (bei 3 GHz: 7,5 bis 30 Millionen Takte) plus Übertragungszeit
- Zugriff immer mindestens in Blöcken zu 4 KiB, besonders effizient beim Zugriff auf Sequenzen aufeinanderfolgender Blöcke
Stufe 2: SSD
- etwas teurer als Festplatten (ab etwa 90 Euro pro TiB)
- aber Zugriffsgeschwindigkeit: 0.05 ms (bei 3 GHz: 150.000 Takte)
- anders als bei Festplatten schneller Wahlzugriff
Stufe 3: Arbeitsspeicher (RAM)
- ab hier flüchtig (Vorteil: öfter wiederbeschreibbar ohne Qualitätsverlust)
- deutlich teurer (ab etwa 4 Euro pro GiB, entspr. ~4000 Euro pro TiB)
- gerade deswegen meist kleiner als die nichtflüchtigen Speicher
  - übliche Größen: von 2-4 GiB bei Smartphones oder kleinen Notebooks bis mehrere TiB bei Servern
- Zugriffsgeschwindigkeit: 15 ns Latenz plus Übertragungszeit, insgesamt z.B. 65 ns (bei 3 GHz: 200 Takte)
Stufe 4: Cache (Zwischenspeicher) des Prozessors
- ab hier fest in den Prozessor eingebaut
- Abbilder von einzelnen Zeilen (je 64 Byte) aus dem Arbeitsspeicher
- Größe: 4-16 MiB
- Zugriffsgeschwindigkeit: 1-5 ns (bei 3 GHz: 3-15 Takte)
Stufe 5: Registerbank des Prozessors
- Größe: 64 bis einige 100 Byte
- Zugriffsgeschwindigkeit: meist 1 Takt
- nur dieser Speicher kann vom CPU direkt für Berechnungen verwendet werden
andere mögliche Hierarchiestufen
- Stufe 0: Speicher auf anderen Computern im Netzwerk
- Stufe 2,5: nichtflüchtiger RAM (noch nicht weitverbreitet)
Speicher aus Sicht des Programmierers
- Abstraktion: lineare Kette von bytegroßen Speicherzellen, die fortlaufend nummeriert sind (Speicheradressen)
- Probleme mit dieser Abstraktion:
  - kleinste sinnvolle Schreibmengen (4/8 Bytes bei Registern, 64 Bytes bei RAM, 4 KiB bei Festplatte/SSD)
  - Caching-Verhalten
- Einfluss auf effizientes Rechnen: viel wichtiger als schnelles Rechnen ist lokales Rechnen
- Beispiel: Repräsentation von 2D-Feldern (z.B. Grafiken) und effizientes Bearbeiten derselben
Quelle: "What every programmer should know about memory"

STP006: Kommandozeilen und Unix-Philosophie

Thu, 12 Aug 2021 09:30:00 GMT

Computer haben heute unglaublich leistungsfähige Grafik. Warum verwenden so viele Computer-Experten dann immer noch textbasierte Terminals?

Shownotes

Begriffsklärung
- Kommandozeile: allgemein jede textbasierte Steueroberfläche
- Terminal ("Endpunkt"): ursprünglich ein einfacher Computerarbeitsplatz, der an einen Großrechner angeschlossen ist und eine Kommandozeile zur Steuerung desselben bereitstellt; heutzutage synonym mit Terminal-Emulator (ein Programm, das denselben Zweck erfüllt)
- Shell (auch "Befehlszeile" genannt): ein Programm, das die Grundstruktur der Befehlsinteraktion im Terminal bereitstellt und das Ausführen und Kombinieren konkreter Befehle ermöglicht
- Befehl: ein Programm, das in der Shell ausgeführt wird und eine konkrete Aktion bewirkt
Warum werden Terminals oft gegenüber grafischen Oberflächen (GUI) bevorzugt?
- ~~Weil es viel cooler ist.~~
- bessere Handhabbarkeit eines großen Funktionsumfangs, nach entsprechender Einarbeitung (vgl. GUI mit 1000 Knöpfen vs. Kommandozeile mit 1000 Befehlen)
- Programmierbarkeit: Textmakros sind einfacher und robuster als GUI-Makros
- Kombinierbarkeit: Textbausteine sind auf offensichtliche Art und Weise kombinierbar, grafische Bearbeitungsschritte nur begrenzt
- Fernwartung: Übertragung von Text braucht weniger Bandbreite als Übertragung einer GUI
- Zugriff bei Problemen oder bei Neuinstallation: wenn GUI nicht mehr oder noch nicht geht, geht oft noch das Terminal
Nachteile von Terminals
- schlechtere Auffindbarkeit von Funktionen ("Discoverability")
- steile Lernkurve
Befehlszeilen gibt es überall, aber besonders prägend ist die von Unix
- Unix: Familie von Betriebssystemen
- ursprünglich Anfang der 1970er bei Bell Laboratories entwickelt von
  - Dennis Ritchie
  - Douglas McIlroy
  - Ken Thompson
  - Brian W. Kernighan wurde im Gespräch auch erwähnt. Er schrieb viele Programme für Unix und half, awk zu entwickeln.
- wichtige aktuelle Vertreter: Linux (und damit Android), macOS, BSD-Familie
- Gründe für den fortwährenden Einfluss des originalen Unix:
  - Quellcode war für universitäre Nutzung frei zugänglich
  - vergleichsweise einfacher und modularer Aufbau
  - dadurch einfach auf neue Systeme übertragbar
Unix-Philosophie
- Formulierung von Douglas McIlroy: "Mache nur eine Sache und mache sie gut."
- Formulierung von Richard P. Gabriel: "Schlechter ist besser." (Einfachheit ist wichtiger als alle anderen Eigenschaften eines Programmes wie Fehlerfreiheit, Konsistenz oder Vollständigkeit, da die Weiterentwicklung vereinfacht wird.)
- weitere Formulierungen siehe verlinkter Wikipedia-Artikel
Unix-Philosophie im Kontext des Terminals
- meist nicht ein Befehl, der die ganze Aufgabe erledigt; sondern viele kleine Befehle, die kombiniert werden können
- gemeinsames Datenmodell: Ströme von Textdaten, die außerdem zumeist zeilenweise verarbeitet werden
- Kombinieren der einzelnen Befehle erfolgt interaktiv (direkt in der Shell) und dadurch iterativ (schrittweise durch wiederholtes Probieren und Anpassen der Befehlszeile)
Beispiel: Wir wollen aus einem gegebenen Text die häufigsten Wörter bestimmen.
- Eingabedatei: BGB als Markdown-Datei aus der inoffiziellen Quelle https://github.com/bundestag/gesetze
- Schritt 1: Einlesen der Datei
  - cat index.md
- Schritt 2: jedes Wort auf eine eigene Zeile
  - cat index.md | tr ' ' '\n'
  - passt nicht ganz, aber ist für unsere Zwecke gut genug ("Schlechter ist besser")
- Schritt 3: Wörter sortieren, dann identische Wörter zusammengruppieren und zählen
  - cat index.md | tr ' ' '\n' | sort | uniq -c
- Schritt 4: Wörter nach ihrer Häufigkeit sortieren
  - cat index.md | tr ' ' '\n' | sort | uniq -c | sort -k1 -n
- Schritt 5: nur die letzten 20 Zeilen, die die häufigsten Wörter enthalten
  - cat index.md | tr ' ' '\n' | sort | uniq -c | sort -k1 -n | tail -n 20
- siehe unten: Auszüge aus den Ausgaben jedes einzelnen Schrittes
Abendgedanken: Eine Lernkurve ist nicht unbedingt ein Nachteil. Es ist durchaus wertvoll, wenn ein Programm seinem Nutzer richtig kommuniziert, wie viel Einarbeitung und Wissen erforderlich ist. Siehe LaTeX vs. Word.
Im Gespräch erwähnt wurden auch:
Errata: Der Begriff "Mem" wurde nicht von Douglas Hofstadter eingeführt, sondern von Richard Dawkins (in seinem Buch "Das egoistische Gen").

Auszüge aus den einzelnen Schritten des Beispiels

Jeweils mit | head, um nur die ersten 10 Zeilen zu zeigen.

Schritt 1

$ cat index.md | head
---
Title: Bürgerliches Gesetzbuch
jurabk: BGB
layout: default
origslug: bgb
slug: bgb

---

# Bürgerliches Gesetzbuch (BGB)

Schritt 2

$ cat index.md | tr ' ' '\n' | head
---
Title:
Bürgerliches
Gesetzbuch
jurabk:
BGB
layout:
default
origslug:
bgb

Schritt 3

Hier sieht man keine Wörter im engeren Sinne, sondern Folgen von Sonderzeichen, deren Zeichen aus technischen Gründen vor den eigentlichen Buchstaben einsortiert werden. In der ganz ersten Zeile taucht die Anzahl von Zeilen auf, die nach Schritt 2 komplett leer waren (zum Beispiel Leerzeilen, die im Ursprungsdokument Absätze voneinander trennen).

$ cat index.md | tr ' ' '\n' | sort | uniq -c | head
  18490
      1 #
      5 ##
     35 ###
    376 ####
   1216 #####
   1015 ######
     24 (§
      6 (§§
      1 *

Schritt 4

Aufgrund der Sortierreihenfolge sehen wir hier besonders seltene Ergebnisse mit je einem Treffer.

$ cat index.md | tr ' ' '\n' | sort | uniq -c | sort -k1 -n | head
      1 #
      1 *
      1 ,
      1 0,75
      1 1).
      1 1\.
      1 1005
      1 1006
      1 1007
      1 1008

Schritt 5

Das Endergebnis.

$ cat index.md | tr ' ' '\n' | sort | uniq -c | sort -k1 -n | tail -n 20
   1374 auf
   1383 nach
   1391 für
   1448 ist
   1523 von
   1568 so
   1574 das
   1630 wenn
   1692 in
   1850 zu
   1953 nicht
   2127 und
   2628 den
   2737 dem
   2909 oder
   3584 §
   4718 des
   5980 die
   8602 der
  18490

STP005: Netzwerk-Schichtenmodell

Thu, 22 Jul 2021 16:00:00 GMT

Wie in Folge 0 bereits erwähnt, tun wir viele Dinge mit Computern. Genauer tun wir sie in oder mit dem Internet. Damit das funktionert ist es nötig vielerlei Protokolle übereinander zu stapeln. Wir präsentieren -- den Network Stack.

Shownotes

Vorbemerkung: Daten im Computer bzw. im Computernetzwerk sind immer nur Zahlen
- Wenn wir Texte haben, haben wir tatsächlich Zahlenfolgen, von denen jede Zahl für einen Buchstaben steht.
- Wenn wir Bilder haben, haben wir tatsächlich Zahlenfolgen, von denen jede Zahl für den Farbwert eines Bildpunktes steht.
- etc.
Rückerinnerung zu STP002: Protokolle
- Wikipedia: "Ein Kommunikationsprotokoll ist eine Vereinbarung, nach der die Datenübertragung zwischen zwei oder mehreren Parteien abläuft. In seiner einfachsten Form kann ein Protokoll definiert werden als eine Menge von Regeln, die Syntax, Semantik und Synchronisation der Kommunikation bestimmen."
- Beispiel aus dem normalen Leben: Interaktion zwischen Kunde und Verkäufer
Computer-Netzwerke brauchen einen ganzen Stapel von Protokollen, die aufeinander aufbauen
- Problemlösung auf verschiedenen Ebenen: physikalische Signalübertragung, Suche von Verbindungspfaden, Fehlerkorrektur, finale Anwendung
- Nachrichten einer höheren Schicht werden in Nachrichten der nächsttieferen Schicht eingewickelt
  - metaphorisches Beispiel: verpacktes Geschenk in Postpaket in Postwertsack in Cargo-Flugzeug
- Austauschbarkeit einzelner Teile des Stapels: z.B. höhere Protokollebenen hängen (fast) nicht davon ab, ob die Übertragung mittels Ethernet oder DSL oder WLAN oder LTE etc. läuft
  - innerhalb der Metapher: Paket kann sowohl über Luftpost als auch per Schiff zugestellt werden
- Lehrmodell: OSI-Modell (Open Systems Interconnection) mit 7 Schichten; entspricht aber nicht ganz der Realität
Schicht 1: Bitübertragungsschicht ("Physical Layer")
- bei kabelgebundenen Wegen Spezifikation der Kabel (Aderanzahl, Materialien, Schirmung, etc.) und Stecker
- bei kabellosen Wegen Spezifikation des Frequenzspektrums etc.
- auf dieser Ebene im Allgemeinen nur Folgen von Bits (Nullen und Einsen)
- Problem: echte Welt ist fehlerbehaftet (Störsignale)
Schicht 2: Sicherungsschicht ("Data Layer")
- Realisierung einer fehlerfreien Übertragung zwischen direkt miteinander verbundenen Geräten
- Bitfolgen werden zu Frames zusammengefasst und mit Prüfsummen versehen
  - zu Prüfsummen siehe STP004
- MTU: Maximum Transfer Unit (maximale Nutzlast in einem Frame)
- manchmal enthalten: Protokolle zum Neustarten fehlgeschlagener Übertragungen (z.B. WLAN), ansonsten nur Verwerfen kaputter Frames (z.B. Ethernet)
- hier meist hohe Komplexität aufgrund strenger Anforderungen an Verarbeitungsgeschwindigkeit
Schicht 3: Vermittlungsschicht ("Network Layer")
- Schicht 1 und 2 war nur für Geräte, die direkt miteinander verbunden sind (bzw. maximal durch Switches und Repeater verbunden)
- Schicht 3 verschaltet mehrere solche lokale Netzwerke miteinander
- Router: Computer, der mit mehreren Netzwerken verbunden ist und dazwischen vermittelt
- Internet ist paketbasiert (wie die Post), nicht verbindungsbasiert (wie das Telefonnetz)
- auf Schicht 3 große Einigkeit in den Protokollen, um Interoperabilität zu ermöglichen
- IP (Internet Protocol)
  - Zuweisung global gültiger Adressen ("IP-Adressen"), z.B. 91.198.174.192 für IP-Version 4 oder 2620:0:862:ed1a::1 für IP-Version 6
  - IP-Pakete können über Netzwerkgrenzen hinweg an den Adressaten zugestellt werden; enthalten Rückadresse für Antwortpakete
- IP-Adressen nicht immer eindeutig auf einen Computer zugewiesen
  - eine global erreichbare Adresse für mehrere Computer, z.B. Anycast (vgl. Großkundenadressen bei der Post)
  - private Adressen für die Verwendung in lokalen Netzwerken (analog zu internen Adressen in der Hauspost einer einzelnen Firma)
- ICMP (Internet Control Message Protocol)
  - z.B. Ping, Pfad-MTU-Aushandlung, Anzeige von nicht verfügbaren Empfängern
- NAT (Network Address Translation)
  - Anwendungsfeld: ein ganzes lokales Netzwerk hat nur eine öffentliche IP-Adresse
  - Router übersetzt IP-Adressen beim Übergang aus dem lokalen Netzwerk oder ins lokale Netzwerk
- weitere Protokolle insb. für die dynamische Verschaltung von Netzwerken, z.B. BGP (Border Gateway Protocol)
Schicht 4: Transportschicht ("Transport Layer")
- Erweiterung von Schicht 3 um Sitzungsverwaltung und Fehlerkorrektur (analog zum Verhältnis von Schicht 2 zu Schicht 1)
- Problem: IP-Adressen identifizieren nur Computer, nicht die Programme auf dem Computer
- getrennte Sitzungen mittels Ports
  - Verbindung eindeutig identifizierbar durch die Verbindung aus Quelladresse, Quellport, Zieladresse und Zielport
- TCP (Transmission Control Protocol)
  - garantierte fehlerfreie Zustellung der Datenpakete jeder Verbindung in der jeweils richtigen Reihenfolge
  - z.B. für große Downloads und Uploads (HTTP)
- Fehlerkorrektur in TCP
  - verpflichtendes Bestätigen erfolgreicher Übertragungen
  - Sender hält Daten in einem Sendefenster vor, bis der Empfang von der Gegenseite bestätigt wurde; analog Empfangsfenster beim Empfänger
  - Überfüllungskontrolle: Sendefenstergröße wird angepasst, wenn die Fehlerrate zunimmt (weil jemand auf dem Weg Pakete verwerfen muss)
  - für den Benutzer sichtbar als "TCP Slow Start" (Downloads fangen meist erst mit geringer Geschwindigkeit an und werden dann schneller, sobald die optimale Sendefenstergröße gefunden wurde)
- UDP (User Datagram Protocol)
  - keine Fehlerkorrektur; im Prinzip nur IP + Ports
  - z.B. für Echtzeit-Anwendungen (Voice over IP), wo geringe Verzögerung wichtiger ist und der Verlust einzelner Pakete hingenommen werden kann
Schicht 5-7: Anwendungsschicht ("Application Layer")
- feinere Aufteilung nicht wirklich hilfreich, da die verschiedenen Aspekte zunehmend schwer voneinander zu trennen sind
- Protokolle auf dieser Ebene: z.B. HTTP/HTTPS (Webseiten), SMTP/IMAP (E-Mail), DNS (Namensauflösung)
Grenzen des Schichtenmodells
- tiefere Schichten können durch höhere Schichten abgebildet werden; Beispiel: VPN-Protokolle (Virtual Private Network; Protokolle der Schicht 7, das einen Datenkanal der Schicht 3 darstellt)
- Schicht 8? Schicht 9?
Zum Weiterhören
- der großartige Podcast Request for Comments (dessen Produzentin natürlich Baecker und nicht Bauer heißt; ttimeless nimmt alle Schuld auf sich)
- hier der erwähnte RFC-Podcast über TCP
- außerdem die angesprochene Episode vom Chaosradio Express: CRE197 IPv6
Lesestoff ;)
- ADSL over wet string
- Twelve Networking Truths

STP004: Passwörter

Thu, 01 Jul 2021 15:45:00 GMT

Es geht um die Gretchenfrage der IT-Sicherheit. Wie müssen Passwörter aussehen? Wie sollen sie gespeichert werden? Wieviel Salz muss an ein Passwort? Kann man sie ersetzen? Und vor allem, wie würde Xyrill das alles machen, würde ihm doch endlich die Weltherrschaft übertragen?

Shownotes

Through twenty years of effort, we've successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess.

Wir haben zwanzig [mittlerweile dreißig – d. Red.] Jahre lang allen eingeredet, Passwörter zu verwenden, die schwer zu merken sind, aber leicht von Computern geraten werden können.

Quelle: Zitat aus XKCD Comic #936.

Motivation: Authentifizierung (Identitätsbeweis)
- mögliche Auth.faktoren:
  - etwas, das ich weiß (z.B. Passwort, PIN, ~~Sicherheitsfrage~~)
  - etwas, das ich habe (z.B. Chipkarte, Hardware-Token, TOTP/HOTP)
  - etwas, das ich bin (z.B. Fingerabdruck, Iris-Abbild)
- Ein-Faktor-Auth. vs. Zwei-Faktor-Auth.
Theorie: Hash-Funktionen
- Hash-Funktion:
  - Wikipedia sagt als Begriff "Streuwertfunktion", das erklärt es ganz gut
  - Anwendungsfelder: Hashtabellen, Prüfsummen
- kryptografische Hash-Funktion:
  - kollisionsresistent und dadurch zur "Ein-Weg-Verschlüsselung" geeignet
  - typische Hash-Länge: 256 Bit = 32 Byte = 64 Hexadezimalziffern
  - Größenvergleich: 2^256 Nanosekunden = 3 Mio. Trio. Trio. Trio. Jahre
- Ziel: Passwort nicht direkt auf dem Webserver speichern
  - Server speichert nur Hash vom Passwort
  - zur Überprüfung präsentiertes Passwort hashen und mit gespeichertem Hash vergleichen
  - Salting: zu jedem Hash noch ein Extra-Zufallstext, damit dasselbe Passwort nicht immer denselben Hash ergibt
Was können Nutzer machen, um sich zu schützen?
- schwer ratbare Passwörter verwenden
  - keine persönlichen Informationen hineinkodieren (Namen von Angehörigen oder nahestehenden Personen, Geburtsdaten, etc.)
  - NICHT "passwort" oder "123456" oder "123qwe"
  - z.B. XKCD-Schema: Wörterbuch aufschlagen, vier zufällige Wörter wählen
  - NICHT bekannte Phrasen (z.B. Bibelverse)
- Passwörter nicht wiederverwenden
  - Wenn überall das gleiche Passwort verwendet wird, sind alle Konten gleichzeitig offen.
  - Mit dem Zugang zum E-Mail Konto kann die "Passwort zurücksetzen"-Funktion ausgenutzt werden.
  - Wenn du nur ein starkes Passwort benutzt, dann das für das E-Mail-Konto.
- Passwort-Manager verwenden
  - auf dem lokalen PC: KeePassXC
  - oder cloud-basiert: Bitwarden (Server kann man auch selbst betreiben)
  - oder für Nerds: pass
- Passwörter nicht mit anderen teilen, auch nicht "nur mal schnell"
  - siehe IT-Support-Scam
  - bei Mehrbenutzersystemen auch mehrere Benutzerkonten verwenden
- Passwort nur auf vertrauenswürdigen Seiten eingeben
  - nicht Links in irgendwelchen Mails folgen (siehe Phishing-Scam), sondern direkt zur bekannten Webseite navigieren
- Passwort für Webseiten ändern, bei denen die Datenbanken gestohlen wurden
  - in vielen Passwort-Managern als automatische Prüfung integriert
Rant: Sicherheitsmaßnahmen, die nicht wirklich bessere Sicherheit bringen
- Sicherheitsfragen
- Passwortbeschränkungen: maximal N Zeichen, mindestens ein Sonderzeichen etc.
- Zwangswechsel nach N Monaten
Was können Webseitenbetreiber machen, um Auth. sicher zu machen?
- Passwörter nur mit starken Hashes ablegen (Argon2, SCrypt, BCrypt, notfalls auch PBKDF2)
- 2FA unterstützen
- HIBP-API verwenden, um Passwort-Wiederverwendung zu erschweren
Gibt es eine Alternative zu Passwörtern?
- anderer Faktor (z.B. Hardware-Token oder Biometrie): nicht unbedingt besser, nur anders (Abwägungsfrage)
- Zwei-Faktor-Auth.
- Anmeldungslink per E-Mail

STP003: Logikgatter

Thu, 10 Jun 2021 08:30:00 GMT

Heute erklärt Xyrill Logikgatter. Und das, obwohl er selbst nicht so genau weiß, was da drin ist. Das ist aber auch nicht zwingend nötig – sagt er –, denn es kommt ja darauf an, was sie tun. Obwohl die meisten Logikgatter scheinbar sehr langweilig sind, schaffen wir es nur, damit zu addieren. Allerdings ist das für ttimeless auch genug für den Anfang.

Shownotes

Rückblick STP001: Binärzahlen sind dargestellt als Folge von Bits
- z.B. 16-Bit-Zahl entspricht 16 Stromleitungen, an denen die Spannung an oder aus ist
Ziel: Berechnungen auf solchen Zahlen
- z.B. Addition zweiter 16-Bit-Zahlen: 2x16 = 32 Bit gehen rein, 16 neue Bit kommen raus
- Wie kombiniert man Bits sinnfällig?
- Logikgatter: Bausteine für solche Schaltkreise
  - allgemein ein oder zwei Eingänge und ein Ausgang
  - ansonsten Logikschaltung bzw. Logikbaustein, der aus mehreren Gattern zusammengesetzt ist
Logikgatter mit einem Eingang und einem Ausgang
- Gatter unterscheiden sich in der Ausgabe bei Eingabe 0 (2 Optionen) und in der Ausgabe bei Eingabe 1 (2 Optionen)
- insgesamt 2x2 = 4 mögliche Gatter
  - 0 -> 0, 1 -> 0 – Ausgang ist konstant Null (langweilig)
  - 0 -> 0, 1 -> 1 – Ausgang ist gleich Eingang (langweilig)
  - 0 -> 1, 1 -> 0 – Ausgang ist Negation des Eingangs (NOT-Gatter)
  - 0 -> 1, 1 -> 1 – Ausgang ist konstant Eins (langweilig)
Logikgatter mit zwei Eingängen und einem Ausgang
- vier mögliche Eingaben (00, 01, 10, 11) und je zwei mögliche Ausgaben (0, 1) -> 2^4=16 mögliche Gatter
- darunter sechs langweilige Gatter
  - Ausgang ist konstant Null
  - Ausgang ist konstant Eins
  - Ausgang ist gleich Eingang 1
  - Ausgang ist gleich Eingang 2
  - Ausgang ist Negation von Eingang 1
  - Ausgang ist Negation von Eingang 2
- sechs nützliche Gatter Logikgatter
  - AND: Sind beide Eingänge 1?
  - OR: Ist wenigstens ein Eingang 1?
  - XOR: Ist genau ein Eingang 1? bzw. Sind beide Eingänge unterschiedlich?
  - NAND: Ist wenigstens ein Eingang 0?
  - NOR: Sind beide Eingänge 0?
  - NXOR, XNOR: Sind beide Eingänge gleich?
- vier verbleibende Gatter sind nicht so intuitiv, können aber bei Bedarf aus den obigen Gattern zusammengesetzt werden
Beispiel für eine Logikschaltung: Addiernetz
- Idee analog zum Addieren auf Papier wie in der Grundschule mit Übertrag
  - Beispiel hier: 35 + 47 = 82
- Halbaddierer: zwei Eingänge, zwei Ausgänge
  - Zwei Ein-Bit-Zahlen werden zu einer Zwei-Bit-Zahl addiert.
  - Ausgang 1 = XOR (erste Stelle der addierten Zahl)
  - Ausgang 2 = AND (zweite Stelle der addierten Zahl)
  - z.B. bei dezimal: 5 + 7 = 2 + Übertrag 1
  - in binär: Ausgang 1 = XOR, Ausgang 2 = AND
- Volladdierer: drei Eingänge, zwei Ausgänge
  - Wie der Halbaddierer, aber nimmt auch den Übertrag der vorherigen Stelle mit.
  - z.B. bei dezimal: 3 + 4 + Übertrag 1 = 8 + Übertrag 0
- Addiernetz für N-Bit-Zahlen: 2N Eingänge, N Ausgänge
  - ein Halbaddierer für die erste Stelle
  - je ein Volladdierer für jede weitere Stelle
  - Überlauf: Was ist, wenn der finale Übertrag nicht 0 ist?
    - Option 1: als Zustand im Prozessor speichern, der später abgefragt werden kann
    - Option 2: als Fehler behandeln, Prozess oder Prozessor anhalten
Warum sind Logikgatter interessant?
- starke Abstraktionsebene: fast das gesamte Verhalten des Computers als Rechenmaschine ist aus Logikgattern zusammengesetzt
- konkrete Hardware (z.B. konkrete Art von Transistoren) ist oberhalb der Ebene der Logikgatter fast unerheblich
- aber natürlich: keine Abstraktion ist perfekt...
- Beispiel: Schaltverzögerung -> Takt

STP002: Aufruf einer Webseite

Thu, 20 May 2021 20:30:00 GMT

Die meisten tun es. Viele täglich. Teils hundertfach oder öfter. Aber was passiert eigentlich, wenn wir es tun? Die Rede ist natürlich von Webseiten. Wir sprechen darüber, wer alles am Aufrufen und Anzeigen von all den Informatinen beteiligt ist, die wir uns täglich beschaffen. Und über Kekse!!!

Shownotes

Schritt 1: Webseitenadresse, z.B. https://de.wikipedia.org/wiki/Computer
- https: Protokoll (wie wir mit der anderen Seite reden)
- de.wikipedia.org: Domain-Name (wo die andere Seite zu finden ist)
- /wiki/Computer: Pfad (welches Dokument wir von der anderen Seite haben wollen)
Schritt 2: Namensauflösung
- Datenverbindungen im Internet gehen nur mit einer IP-Adresse (sieht aus wie 192.168.12.169 oder fe80::42e2:30ff:fe12:17b)
- Webseitenadressen enthalten Domain-Namen, weil:
  - menschenlesbar
  - kann auf mehrere verschiedene Server verweisen (Lastverteilung, Redundanz, Geo-Routing)
- Frage: Welche IP-Adresse gehört zu dem Domain-Namen? -> Namensauflösung mittels Domain Name System (DNS)
- Computer der Benutzerin kennt einen DNS-Server (meist vom Internetanbieter)
- DNS-Server kann zu jedem Domain-Namen die richtige IP-Adresse bestimmen
- Privatsphäre-Relevanz: dein DNS-Server kennt alle Domains, die du besuchst
Schritt 3: Verbindung zum Webserver
- Broadcast vs. Unicast
  - Fernsehen/Radio/etc. ist Broadcast (eine sendet einmal, viele empfangen)
  - Internet ist im Allgemeinen Unicast (eine sendet, eine empfängt) wie das Telefonnetz
- grobe Analogie: IP-Adressen zu Telefonnummern (Ländervorwahl, Ortsvorwahl, Durchwahl, etc.)
- Datenleitung steht, jetzt können wir unser Protokoll (HTTPS) darüber sprechen
  - Wikipedia: "Ein Kommunikationsprotokoll ist eine Vereinbarung, nach der die Datenübertragung zwischen zwei oder mehreren Parteien abläuft. In seiner einfachsten Form kann ein Protokoll definiert werden als eine Menge von Regeln, die Syntax, Semantik und Synchronisation der Kommunikation bestimmen."
- HTTPS verwendet Verschlüsselung, da sonst jeder entlang des Weges mitlesen könnte
  - TLS: Aushandlung einer Transportverschlüsselung, dann Überprüfung der Identität des Servers
  - Server muss dazu ein Zertifikat für seinen Domain-Namen haben
- Datenleitung mit Verschlüsselung steht, jetzt kann HTTP gesprochen werden (HTTPS = HTTP mit TLS)
  - HTTP: allgemein Protokoll zum Herunterladen und Hochladen von Dateien (Hochladen z.B. auch beim Abschicken von Webseiten-Formularen)
Schritt 4: Webseite
- Computer der Benutzerin fragt über die bestehende HTTPS-Verbindung nach dem Dokument unter dem Pfad in der Webseitenadresse
- Server liefert eine Datei, üblicherweise im HTML-Format
- Hausaufgabe: im Browser Webseite öffnen und im Rechtsklick-Menü "Element untersuchen" wählen
- HTML: Dokumentenformat
  - dieselbe Grundkategorie wie PDF oder DOC
  - aber mehr für die Bildschirmanzeige als für den Druck optimiert
  - seit 2000 zunehmend auch für dynamische Inhalte ("Webanwendungen")
Schritt 5: Ressourcen
- HTML alleine enthält nur die Dokumentenstruktur und den Text
- weitere Teile der Webseite liegen in anderen Dateien, auf die das HTML verweist und die der Browser separat herunterlädt
  - CSS: Darstellungsanweisungen (z.B. "alle Absätze mit 1,5 Zeilen Zeilenhöhe")
  - Bilder, Audios, Videos
  - Skripte für dynamische Inhalte
- siehe auch: Webseite wird schon angezeigt, aber Bilder erscheinen erst nach und nach
- Verweise auch auf Dokumente auf anderen Domains möglich
  - Privatsphäre-Relevanz: Tracking-Pixel und Tracking-Skripte
Schritt 6: Cookies
- HTTP an sich ist zustandslos: Anfrage nach einem Dokument ist nicht abhängig davon, was ich vorher angefragt hatte
- Problem: Wie ordnet man die Anfrage nach einem Dokument zu einer Benutzerin zu? (z.B. um Anmeldestatus oder Warenkorb zu verfolgen)
- Cookie: kleine Datei, die der Server bei einem Dokument mitschickt und die vom Browser aufbewahrt wird
- beim nächsten Request werden alle Cookies von diesem Server wieder mitgeschickt
- Privatsphäre-Relevanz: Tracking durch Facebook-Cookie etc.
Exkurs: "Was passiert, wenn ich einen Podcast abrufe?"
- prinzipiell genauso, aber statt HTML anderes Dokumentenformat
- RSS: "Really Simple Syndication" ("wirklich einfache Verbreitung")
- RSS-Dokument ist ein Feed
  - Feed = Liste von Nachrichten
  - vergleichbar mit dem Feed auf Twitter oder Facebook
- RSS ursprünglich für Blogs und Nachrichtenwebseiten entwickelt (Titel, Kurzbeschreibung, Link zur Webseite)
- für Podcasts statt Link zur Webseite Links zu den Audio-Dateien

STP001: Zahlensysteme

Wed, 28 Apr 2021 22:00:00 GMT

Wir versuchen uns daran, verschiedene Zählsysteme zu erklären. Xyrill will zum Wohl aller die Weltherrschaft an sich reißen, und wir hauen auf den Amerikanern rum. Außerdem in dieser Folge: Liverechnen von Xyrill und spannende Dinge mit Fingern von ttimeless.

Shownotes

Rekapitulation: Wie funktionieren die alltäglichen Zahlensysteme?
- römische Zahlen: Additionssystem mit Fünferteilung
- Maya-Zahlensystem: Vigesimalsystem zur Basis 20
- arabische Zahlen: Stellenwertsystem zur Basis 10
- Basis ist prinzipiell frei wählbar
  - Basis 10 wegen Fingerzählen
  - Basis 20, wenn man auch die Zehen dazu nimmt (Spuren in vielen europäischen Sprachen)
  - Basis 12 ("Dutzend", Stundenteilung) erlaubt viele gerade Teilungen
  - ähnlich für Basis 60 (Babylon)
- Hybridsystem aus Stellenwert- und Additionssystem: z.B. Aussprache arabischer Zahlen im Deutschen, z.B. chinesische/japanische Zahlen
Dualsystem/Binärsystem: Stellenwertsystem zur Basis 2
- praktisches Beispiel: ttimeless' Binär-Armbandur
- zuschauen wie Binärzahlen wachsen: Onlinebinäruhr
- zuerst von Gottfried Wilhelm Leibniz für Logikberechnungen genutzt
- vielseitig darstellbar in technischen Anwendungen
  - Mechanik: Klappe auf/zu
  - Elektronik: Strom an/aus
  - Pneumatik: Druck/kein Druck (Beispiel: pneumatische Roboter)
  - Programmierung: true/false
  - etc.
- z.B. in Elektronik: mehr als zwei Spannungswerte möglich, aber dann anfälliger für:
  - Störsignale im Kabel
  - Spannungsschwankungen (z.B. durch Entladen der Batterie)
  - etc.
- Abgrenzung "binär" vs. "digital" (Wortherkunft "digital": lat. "digitus" = Finger)
Hexadezimalsystem: Basis 16
- für die kompakte Notation von Binärzahlen
- im Prinzip nur für Menschen bedeutsam
- Ziffern 0-9, A-F
- Notation in der Mathematik: Subskript mit der Basis (z.B. 42_10 = 24_16)
- Notation in der Informatik: blanke Zahl ist dezimal (z.B. 42), Präfix "0x" ist hexadezimal (z.B. 0x24)
  - manchmal auch "0b100100" für binär und "0o52" für oktal
Größenordnungen oberhalb von 0/1
- Oktett: 8 Bit (256 Zustände)
- Byte: kleinste einzeln addressierte Speichermenge (heutzutage so gut wie immer 8 Bit)
- Kilobyte, Megabyte, Gigabyte, etc.: Multiplikator 1000 (KB,MB,GB)
- Binärpräfixe Kibibyte, Mebibyte, Gibibyte, etc.: Multiplikator 1024 (KiB,MiB,GiB)
- Einheitensymbole: kleines "b" für Bit, großes "B" für Byte (wichtig für Netzwerktechnik, da Geschwindigkeiten oft in Megabit/Sekunde etc. angegeben sind)

STP000: Was ist Informatik?

Thu, 08 Apr 2021 10:30:00 GMT

In der ersten... nein, nullten Folge sprechen wir über die grundlegenden Muster von Informatik und Mathematik. Dazu gehört, dass Informatik sowieso das einzig neue seit fließend Wasser, und Mathematik keine Naturwissenschaft ist. Außerdem in dieser Folge: Was Trommeln im Stadion mit dem Wetter und Turing mit λ zu tun haben.

Shownotes

Einleitung: Erklärung des Podcastkonzepts durch ttimeless
Informatik ist das vllt. einzige wirklich neue eigenständige Studienfach des 20. Jh.
- Crossover aus Mathematik (Strukturwissenschaft) und Elektrotechnik (Ingenieurwissenschaft)
- mittlerweile eigenständig aufgrund Größe und unterschiedlicher Lernstruktur
  - ähnlich der Abgrenzung zwischen Medizin und Biologie
- vielleicht vergleichbar mit der Bildung einer neuen Spezies: unterschiedlich genug zu allen anderen Disziplinen
- Fokus in dieser Folge eher auf Mathematik als auf Elektrotechnik (Xyrill ist hier eher Theoretiker)
Mathematik: keine Naturwissenschaft, sondern Strukturwissenschaft
- Untersuchung von "ausgedachten" Systemen
- meist Bezug zu realen Dingen (z.B. Arithmetik, Rechnen mit Zahlen im Kopf und auf dem Zettel, ein grundsätzliches Element der Mathematik)
- aber auch viel Grundlagenforschung (z.B. Primzahlen)
- Teilbereiche der Mathematik sind erfolgreich, wenn sie reale Probleme lösen
  - Handel -> Arithmetik
  - Architektur -> Geometrie
  - Wechselstromtechnik -> Komplexe Zahlen
  - Rechenmaschinen -> theoretische Informatik (Xyrill nennt es "Berechnungstheorie")
Warum "Berechnungstheorie"?
- Mathematik begnügt sich mit Aussagen wie "X ist lösbar", "X existiert"
- Informatik muss immer auch erklären, wie etwas lösbar ist
  - "Ein Algorithmus ist eine eindeutige Handlungsvorschrift zur Lösung eines Problems oder einer Klasse von Problemen. Algorithmen bestehen aus endlich vielen, wohldefinierten Einzelschritten."
  - "Algorithmus": benannt nach einem iranischen Universalgelehrten aus dem 8. Jhd. (al-Chwarizmi)
- Algorithmen gab's also auch schon, bevor es "Informatik" hieß
  - Arithmetik: Primzahlen finden (Sieb des Erastothenes)
  - Geometrie: Umkreis eines Dreiecks finden
  - Knotenkunde
- maschinelles Abarbeiten von Algorithmen erfordert besonders präzise Formulierung
  - Menschen kommen mit ungenauen Erläuterungen oder reinen Zielbeschreibungen klar
  - Beispiel: Wörter alphabetisch sortieren
  - Beispiel: Gegeben zwei Zahlen, welche ist kleiner und welche ist größer?
- "Berechenbarkeit" ist ein universales Konzept
  - nicht an bestimmte Arten von Rechnenmaschinen gebunden
  - Algorithmen können auch von Hand ausgeführt werden
- Church-Turing-These: alle universellen Rechenmaschinen sind äquivalent (Turingmaschinen, Lambda-Kalkül, Primitiv-rekursive Funktionen)
  - nicht rigoros bewiesen, aber stimmt für alle bisher gefundenen universellen Rechenmaschinen
Durch das Aufschreiben von Algorithmen zeigen wir, dass wir ein Problem so gut verstanden haben, dass eine Maschine es für uns lösen kann.
Deswegen ist Informatik die Schlüsseltechnologie der modernen Welt.