Schlüsseltechnologie

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.

oft erwähnt, aber nie systematisch eingeführt: der Begriff Graph

Wie durchschreitet man einen Graphen? -> Suchalgorithmen, im allgemeinsten Fall die zwei wichtigsten "uninformierten" Suchalgorithmen

Beobachtung: Breitensuche findet garantiert den kürzesten Pfad vom Startpunkt zu einem gewünschten Endpunkt

im Gespräch erwähnt: #WissPodWeihnacht 3: Das Haus vom Niko…hä?!? mit Geschichten aus der Mathematik

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…

Frage 1: Warum ist Software (bzw. Produkte im Allgemeinen) immer weniger langlebig?

Frage 2: Warum waren Computer in den 90ern schneller?

Komplexitätsquellen laut Wirth

Wie heraus aus der Teergrube? Wirth bespricht sein eigenes Oberon System

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.

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.

siehe STP081: gemäß des neuen Barrierefreiheitsstärkungsgesetzes müssen Webseiten und Webapplikationen die AA-Kriterien der WCAG 2.1 erfüllen

Grundprinzip 3: Verständlichkeit

Grundprinzip 4: Robustheit

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

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...

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".

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.

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

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

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.

siehe STP081: gemäß des neuen Barrierefreiheitsstärkungsgesetzes müssen Webseiten und Webapplikationen die AA-Kriterien der WCAG 2.1 erfüllen

Grundprinzip 2: Bedienbarkeit

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

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!

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.

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.

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."

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.

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.

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."

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.

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.

"Calling the Shot" hier im Baseball-Sinne: vorher ansagen, wo der Ball nach dem Schlag landet

Problem: Code schreiben alleine ist noch einigermaßen abschätzbar, macht aber nur einen kleinen Teil (vllt. ein Sechstel) des Gesamtaufwandes aus

Brooks fasst dann Erkenntnisse aus mehreren quantitativen Studien zusammen; Highlights:

wenn Code kein Wert an sich, sondern eine Verbindlichkeit ist, wie kann man Code reduzieren?

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."

"Repräsentation ist die Essenz des Programmierens": Brooks hält den Entwurf passender Datenstrukturen für sehr viel relevanter als die Auswahl passender Algorithmen

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."

wesentliche Funktionen von Dokumentation für den Manager:

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

damit im Zusammenhang: Wie geht man mit Veränderungen der Umstände um? Wieviel Veränderung der Umstände ist man bereit, zu akzeptieren?

Software-Maintenance laut Brooks besteht hauptsächlich aus "Änderungen, die Designfehler beheben"

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."

Programmierer sind eine der wenigen Berufsstände, die ihre eigenen Werkzeuge bauen

Brooks bespricht dann Strategien, die nicht auf den allgemeinen Fall übertragbar sind

Brooks stellt als offensichtlich wertvolles Werkzeug Hochsprachen auf eine Stufe mit interaktiver Programmierung

Wie verhindert man Probleme beim Zusammenfügen mehrerer Teilprogramme zu einem Gesamtsystem?

Missverständnisse bzw. Unklarheiten in der Spezifikation: siehe Kapitel 4-6 für Prozesse zum Erhalt der konzeptionellen Integrität des Gesamtsystems

Empfehlung: klare Markierungen, wenn zum Zwecke der Fehlerbehebung der dokumentierte Zustand des Systems manipuliert wird

weitere Empfehlungen:

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

Erkennen von Verspätungen erfordert einen festen Zeitplan mit spezifischen Meilensteinen

"Aber die anderen sind auch zu spät dran."

"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."

Brooks möchte, dass Dokumentation aus drei Teilen besteht

Brooks findet Strukturdiagramme super, und Flowcharts scheiße: man solle lieber äquivalenten (Pseudo-)Code hinschreiben

im Gespräch erwähnt: The Architecture of Open Source Applications; ein Buch darüber, guten Open-Source-Code zu lesen und zu durchdringen

"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."

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.

seit 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz als nationale Umsetzung der EU-Richtlinie 2019/882 über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen

Webseiten und Webapplikationen müssen die AA-Kriterien der WCAG 2.1 erfüllen

Grundprinzip 1: Wahrnehmbarkeit

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

Platz 9: CWE-862; fehlende Autorisierung

Platz 10: CWE-434; Unbeschränktes Hochladen von Dateien des falschen Typs

Platz 21: CWE-476; Zugriff auf Nullzeiger

Platz 22: CWE-798; Zugriff mit hartkodierten Anmeldedaten

Platz 23: CWE-190; Ganzzahlüberlauf ("Integer Overflow or Wraparound")

Platz 24: CWE-400; unkontrollierter Ressourcenverbrauch

außerdem noch Xyrills Favorit: CWE-655; unzureichende psychologische Akzeptabilität :)

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.

Rückbezug STP077: Liste von Listen

Rückbezug STP072: assoziative Datenfelder (wir sagen hier "Maps"; heißt je nach Programmiersprache auch "Objekt", "Dictionary", etc.)

Ansatz 1: "Sammlung von Wertepaaren" als Liste umsetzen

Ansatz 2: Vorsortierung anhand von Streuwertfunktionen (Hashes)

Vorwärtsbezug zu STP080: Komplexitätsattacke auf Hashmaps (eine Instanz von CWE-400)

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.

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.

Rückbezug STP049: CVE-Datenbank für bekannte Sicherheitslücken in bestimmten Programmen (z.B. Heartbleed ist CVE-2014-0160)

Platz 1: CWE-79; fehlerhafte Neutralisierung von Eingaben während der Erzeugung von Webseiten ("Cross-Site Scripting", XSS)

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

Platz 3: CWE-89; SQL-Injektion

Platz 4: CWE-352; Cross-Site Request Forgery (CSRF)

Platz 5: CWE-22; Pfaddurchquerung ("Path Traversal")

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.