Schlüsseltechnologie

By Xyrillian Noises

Die IT hat unser Leben in den letzten Jahrzehnten von Grund auf verändert. Aber wie funktioniert sie wirklich? Das möchte ttimeless mal erklärt bekommen. Zum Glück hat Xyrill Antworten.... more

· Technology

Download on the App Store

Download on the App Store

Get it on Google Play

FAQs about Schlüsseltechnologie:

How many episodes does Schlüsseltechnologie have?

The podcast currently has 82 episodes available.

Schlüsseltechnologie episodes:

July 27, 2023STP041: Grundlagen der Kryptografie
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.
ShownotesDefinition 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
Schlüsseltechnologie Live: Das Diffie-Hellman-Protokoll
Kerckhoffs' Prinzip
XKCD 538: Security
crypto/subtle
...more
1h 8min
July 06, 2023STP040: Urheberrecht bei Programmen
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
...more
1h 21min
June 15, 2023STP039: Authentifizierung und Autorisierung
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
...more
1h 5min
May 25, 2023STP038: Software-Tests
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
...more
1h 23min
May 04, 2023STP037: Berühmte Softwarefehler
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.
ShownotesErrata 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
...more
1h 6min
April 13, 2023STP036: LaTeX
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.
ShownotesZu 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:
dinbrief.cls
Museum für Druckkunst Leipzig
CRE zu TeX/LaTeX
CRE zu Typografie
Videobeweis von Xyrills Formelsatz-Lesefähigkeiten (ab 01:31:00)
Xyrills Physik-Diplomarbeit und Informatik-Bachelorarbeit
...more
1h 1min
April 01, 2023STP035: Aprilscherz-RFCs
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
...more
1h 4min
March 23, 2023STP034: Compilerbau
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)
...more
1h 10min
March 02, 2023STP033: Programmiersprachen
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
...more
1h 38min
February 09, 2023STP032: Hochverfügbarer Softwarebetrieb
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):
Pentaradio vom Mai 2022 und ganz aktuell vom Januar 2023
LNP429: Endlich sind wir am Anfang angekommen
LNP430: Die größte Koalition aller Zeiten
...more
1h 16min

FAQs about Schlüsseltechnologie:

How many episodes does Schlüsseltechnologie have?

The podcast currently has 82 episodes available.

More shows like Schlüsseltechnologie

Freak Show by Metaebene Personal Media - Tim Pritlove

Freak Show

11 Listeners

Methodisch inkorrekt! by Methodisch inkorrekt!

Methodisch inkorrekt!

16 Listeners

Lage der Nation - der Politik-Podcast aus Berlin by Philip Banse & Ulf Buermeyer

Lage der Nation - der Politik-Podcast aus Berlin

227 Listeners

c’t uplink - der IT-Podcast aus Nerdistan by c’t Magazin

c’t uplink - der IT-Podcast aus Nerdistan

9 Listeners

Chaosradio by Chaos Computer Club Berlin

Chaosradio

7 Listeners

heiseshow by heise online

heiseshow

3 Listeners

Logbuch:Netzpolitik by Metaebene Personal Media - Tim Pritlove

Logbuch:Netzpolitik

6 Listeners

Jung & Naiv by Tilo Jung

Jung & Naiv

43 Listeners

Holger ruft an by Übermedien

Holger ruft an

2 Listeners

Die Wochendämmerung - Der stabile Wochenrückblick by Katrin Rönicke und Holger Klein (hauseins)

Die Wochendämmerung - Der stabile Wochenrückblick

14 Listeners

Sicherheitshalber by Der Podcast zur sicherheitspolitischen Lage in Deutschland, Europa und der Welt.

Sicherheitshalber

46 Listeners

Bit-Rauschen: Der Prozessor-Podcast von c’t by c't Magazin

Bit-Rauschen: Der Prozessor-Podcast von c’t

0 Listeners

Legion by rbb | NDR | Undone

Legion

7 Listeners

Haken dran – das Social-Media-Update der c't by Gavin Karlmeier

Haken dran – das Social-Media-Update der c't

2 Listeners

Passwort - der Podcast von heise security by Dr. Christopher Kunz, Sylvester Tremmel

Passwort - der Podcast von heise security

3 Listeners