add diday and palantir slides to 223015c chapter 1

- add cd logo, cd player, dvd, artemis images
- add artemis ii slide with apollo comparison and bandwidth calculation
- regenerate hex-dec lookup table as 16x16 grid with ascii highlight
- move hex-dec table next to hexadezimal slides
- fix mp3 bitrate: 320 -> 128 kbps to match stated file size

CLAUDE.md

@@ -35,8 +35,9 @@ build/                  # Generated output (gitignored)
 ## Build Commands
 
 ```bash
-make dev-b          # Dev server 223015b (port 1311)
+make dev            # Marp live server all courses (port 1312, HMR)
-make dev-c          # Dev server 223015c (port 1312)
+make dev-b          # Marp live server 223015b (port 1313, HMR)
+make dev-c          # Marp live server 223015c (port 1314, HMR)
 make build          # Build all courses
 make build-b        # Build 223015b only
 make build-c        # Build 223015c only

Makefile

@@ -27,7 +27,9 @@ help:
 	@echo "  223015c - Internettechnologien"
 	@echo ""
 	@echo "Development:"
-	@echo "  make dev         - Start development server (port 3000)"
+	@echo "  make dev         - Marp live server all courses (port 1312, HMR)"
+	@echo "  make dev-b       - Marp live server 223015b (port 1313, HMR)"
+	@echo "  make dev-c       - Marp live server 223015c (port 1314, HMR)"
 	@echo ""
 	@echo "Build:"
 	@echo "  make build       - Build all courses"
@@ -55,13 +57,20 @@ build/.exists:
 	@mkdir -p build/223015b build/223015c
 	@touch $@
 
-# Development server
+# Development server (Marp live server with HMR)
 dev:
 	@./scripts/dev-server.sh
 
+dev-b:
+	@./scripts/dev-server.sh 223015b 1313
+
+dev-c:
+	@./scripts/dev-server.sh 223015c 1314
+
 dev-kill:
-	@-pkill -f "marp-cli.*--server" 2>/dev/null || true
+	@-fuser -k 1312/tcp 2>/dev/null || true
-	@sleep 0.5
+	@-fuser -k 1313/tcp 2>/dev/null || true
+	@-fuser -k 1314/tcp 2>/dev/null || true
 
 # Build functions
 define build_course

scripts/dev-server.sh

@@ -1,12 +1,16 @@
 #!/usr/bin/env bash
-# Simplified development server for HdM slides
+# Development server for HdM slides
-# Starts single Marp server for all courses
+# Usage:
+#   ./dev-server.sh              - Marp live server for all courses (port 1312)
+#   ./dev-server.sh 223015b 1313 - Marp live server for single course
+#   ./dev-server.sh 223015c 1314 - Marp live server for single course
 
 set -e
 
 # Configuration
 SLIDES_DIR="slides"
-DEV_PORT=3000
+COURSE="${1:-}"
+DEV_PORT="${2:-1312}"
 
 # Colors
 GREEN='\033[0;32m'
@@ -14,40 +18,27 @@ BLUE='\033[0;34m'
 RED='\033[0;31m'
 NC='\033[0m' # No Color
 
-# Cleanup function
+# Kill existing process on our port only
-cleanup() {
+kill_port() {
-    echo -e "\n${RED}Shutting down dev server...${NC}"
+    fuser -k "$DEV_PORT/tcp" 2>/dev/null || true
-    pkill -f "marp-cli.*--server" 2>/dev/null || true
+    sleep 0.5
-    exit 0
-}
-
-# Kill existing processes on our port
-kill_existing() {
-    echo -e "${BLUE}Cleaning up existing processes...${NC}"
-    pkill -9 -f "marp-cli" 2>/dev/null || true
-    fuser -k $DEV_PORT/tcp 2>/dev/null || true
-    sleep 1
 }
 
 # Main
-trap cleanup SIGINT SIGTERM
+trap 'echo -e "\n${RED}Shutting down...${NC}"; kill 0; exit 0' SIGINT SIGTERM
 
-kill_existing
+kill_port
 
-echo -e "${GREEN}Starting development server...${NC}"
+if [ -n "$COURSE" ]; then
-echo ""
+    SERVE_DIR="$SLIDES_DIR/$COURSE"
-echo -e "  Server:   ${BLUE}http://localhost:$DEV_PORT${NC}"
+    echo -e "${GREEN}Marp dev server${NC} · ${BLUE}$COURSE${NC}"
-echo -e "  Slides:   ${BLUE}$SLIDES_DIR/${NC}"
+else
-echo ""
+    SERVE_DIR="$SLIDES_DIR"
-echo -e "Available courses:"
+    echo -e "${GREEN}Marp dev server${NC} · ${BLUE}all courses${NC}"
-echo -e "  223015b: ${BLUE}http://localhost:$DEV_PORT/223015b/${NC}"
+fi
-echo -e "  223015c: ${BLUE}http://localhost:$DEV_PORT/223015c/${NC}"
+
-echo ""
+echo -e "  ${BLUE}http://localhost:$DEV_PORT${NC}"
-echo -e "Press ${RED}Ctrl+C${NC} to stop the server"
+echo -e "  ${BLUE}$SERVE_DIR/${NC}"
 echo ""
 
-# Start single Marp server for all slides
+PORT=$DEV_PORT exec npx @marp-team/marp-cli --server "$SERVE_DIR/"
-PORT=$DEV_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/"
-
-# Wait for process to exit
-wait

scripts/generate-root-index.sh

@@ -0,0 +1,158 @@
+#!/usr/bin/env bash
+# Generate root index.html for HdM slides overview
+# Usage: ./generate-root-index.sh
+
+BUILD_DIR="${1:-build}"
+
+cat > "$BUILD_DIR/index.html" << 'HEADER'
+<!DOCTYPE html>
+<html lang="de">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>HdM Vorlesungen</title>
+  <style>
+    * { box-sizing: border-box; margin: 0; padding: 0; }
+    body {
+      font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Segoe UI", Roboto, sans-serif;
+      max-width: 720px;
+      margin: 0 auto;
+      padding: 3rem 1.5rem;
+      background: #fafafa;
+      color: #1d1d1f;
+      line-height: 1.5;
+    }
+    h1 {
+      font-size: 2rem;
+      font-weight: 600;
+      letter-spacing: -0.02em;
+      margin-bottom: 0.5rem;
+    }
+    .subtitle { color: #86868b; font-size: 1rem; }
+    .courses {
+      margin-top: 2rem;
+      display: flex;
+      flex-direction: column;
+      gap: 0.75rem;
+    }
+    .course-card {
+      position: relative;
+      background: #fff;
+      border-radius: 12px;
+      box-shadow: 0 1px 3px rgba(0,0,0,0.08);
+      transition: all 0.2s ease;
+      display: grid;
+      grid-template-columns: 1fr auto auto;
+      align-items: center;
+      gap: 1rem;
+    }
+    .course-card:hover {
+      transform: translateY(-2px);
+      box-shadow: 0 4px 12px rgba(0,0,0,0.12);
+    }
+    .course-link {
+      display: block;
+      padding: 1.25rem 1.5rem;
+      text-decoration: none;
+      color: inherit;
+      grid-column: 1;
+    }
+    .course-link::after {
+      content: '';
+      position: absolute;
+      inset: 0;
+      border-radius: 12px;
+    }
+    .course-label {
+      font-size: 0.7rem;
+      font-weight: 600;
+      text-transform: uppercase;
+      letter-spacing: 0.05em;
+    }
+    .course-b .course-label { color: #1e5f8a; }
+    .course-c .course-label { color: #d63384; }
+    .course-title {
+      font-size: 1.15rem;
+      font-weight: 500;
+      color: #1d1d1f;
+      margin: 0.25rem 0;
+    }
+    .course-info { font-size: 0.85rem; color: #86868b; }
+    .section-title {
+      font-size: 1rem;
+      font-weight: 600;
+      color: #86868b;
+      margin-top: 2.5rem;
+      margin-bottom: 0.75rem;
+    }
+    .references {
+      display: flex;
+      flex-direction: column;
+      gap: 0.75rem;
+    }
+    footer {
+      margin-top: 2.5rem;
+      padding-top: 1.5rem;
+      border-top: 1px solid #e5e5e7;
+      color: #86868b;
+      font-size: 0.85rem;
+    }
+    footer a { color: #1d1d1f; text-decoration: none; }
+    footer a:hover { text-decoration: underline; }
+    .qr-section {
+      margin-top: 2.5rem;
+      padding: 1.5rem;
+      background: #fff;
+      border-radius: 12px;
+      box-shadow: 0 1px 3px rgba(0,0,0,0.08);
+      text-align: center;
+    }
+    .qr-code { width: 100%; height: auto; }
+    .qr-url { margin-top: 0.75rem; font-size: 0.85rem; color: #86868b; }
+    @media (max-width: 600px) {
+      .course-card { grid-template-columns: 1fr; }
+      .course-link { padding-bottom: 0.75rem; }
+    }
+  </style>
+</head>
+<body>
+  <h1>HdM Vorlesungen</h1>
+  <p class="subtitle">Sommersemester 2026 · Michael Czechowski</p>
+  <div class="courses">
+    <div class="course-card course-b">
+      <a href="223015b/" class="course-link">
+        <span class="course-label">223015b</span>
+        <div class="course-title">Dateiformate, Schnittstellen, Speichermedien &amp; Distributionswege</div>
+        <span class="course-info">6 Kapitel · Modul &quot;Technik 1&quot;</span>
+      </a>
+    </div>
+    <div class="course-card course-c">
+      <a href="223015c/" class="course-link">
+        <span class="course-label">223015c</span>
+        <div class="course-title">Grundlagen IT- und Internettechnik</div>
+        <span class="course-info">3 Kapitel · Modul &quot;Technik 1&quot;</span>
+      </a>
+    </div>
+  </div>
+  <h2 class="section-title">Referenzen</h2>
+  <div class="references">
+    <div class="course-card">
+      <a href="https://codecrispi.es/" class="course-link">
+        <span class="course-label">Plattform</span>
+        <div class="course-title">Code Crispies</div>
+        <span class="course-info">Selbstlernplattform</span>
+      </a>
+    </div>
+  </div>
+  <div class="qr-section">
+    <img src="qr-root.svg" alt="QR Code" class="qr-code">
+    <p class="qr-url">https://librete.ch/hdm/</p>
+  </div>
+  <footer>
+    <a href="mailto:mail@librete.ch">Kontakt</a>
+  </footer>
+</body>
+</html>
+HEADER
+
+echo "Generated $BUILD_DIR/index.html"

slides/223015b/00-intro.md

@@ -88,167 +88,103 @@ Hochschule der Medien Stuttgart
 
 ---
 
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
 ![bg fit](./assets/qrcode-0.svg)
 
 ---
 
 <!-- _class: lead -->
 
-# Willkommen!
+# Herzlich willkommen!
 ## Einführung
 
 ---
 
 # Über mich
 
-**Michael Czechowski**
+**Michael Werner Czechowski**
 
-- Irgendwas mit IT, Cloud und AI
+- Systems and Platform Engineer
 - Schwerpunkte:
   - Web-Technologien, Barriere-Armut, Systemarchitektur, Open Source
 - Hintergrund:
-  - Philosophie (Uni Stuttgart) -> NO degree
+  - Philosophie (Uni Stuttgart)
-  - Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
+  - Wirtschaftsinformatik (Leibniz-FH Hannover)
 - Kontakt: lb-czechowski@hdm-stuttgart.de
 
+---
+
+# Warum dieses Modul?
+
+**Digitale Medien sind überall.**
+
+* Warum enthalten Fotos oft Informationen über den Aufnahmeort?
+* Warum lassen sich gelöschte Dateien wiederherstellen?
+* Warum benötigt eine Minute 4K-Video unkomprimiert 45 GB Speicher?
+* Warum zeigt eine "1 TB"-Festplatte nur 931 GB an?
+* Warum ist USB-C nicht gleich USB-C?
+* Ziel: **→ Mitreden können!**
+
 <!--
-Kurze Vorstellung
+1. EXIF (Exchangeable Image File Format)-Metadaten speichern GPS-Koordinaten, Kameramodell und Zeitstempel automatisch. Die meisten wissen nicht, dass diese Daten beim Versenden mitgeschickt werden. → Kapitel 4: Metadaten
-Praxisbezug betonen
+
-Fragen jederzeit willkommen
+2. Beim Löschen wird nur der Verzeichniseintrag im Dateisystem entfernt, nicht die Daten selbst. Die Bits bleiben auf dem Datenträger, bis sie überschrieben werden. → Kapitel 3: Dateisysteme
+
+3. 3840 × 2160 Pixel × 3 Byte (RGB) × 30 Bilder/Sek × 60 Sek = ~45 GB. Codecs wie H.264/H.265 komprimieren um Faktor 100+. → Kapitel 1+2: Kompression
+
+4. Hersteller rechnen dezimal (1 TB = 10¹² Bytes), Betriebssysteme binär (1 TiB = 2⁴⁰ Bytes). Die Differenz beträgt bei Terabyte bereits ~10%. → Kapitel 1: Dateneinheiten
+
+5. USB-C ist nur die Steckerform. Dahinter können USB 2.0 (480 Mbit/s), USB 3.2 (20 Gbit/s) oder Thunderbolt 4 (40 Gbit/s) laufen — gleiches Kabel, völlig unterschiedliche Leistung. → Kapitel 3: Schnittstellen
 -->
 
 ---
 
-<!-- _footer: '' -->
-
-![bg fit](./assets/jung-naiv.png)
-
----
-
-# AMA (Ask my anything)
-
-*Nur ein Vorschlag ...*
-
-* Hast du alle Bände von AoT daheim?
-* Hast du eine Studierenden-Kneipe mal geleitet?
-* Hast du wirklich 17 Semester Philosophie ohne Abschluss studiert?
-
----
-
 # Kurze Umfrage
 
 **Bitte Hand heben:**
 
-1) Wer hat schon mal ein Video komprimiert/konvertiert?
+1) Wer kennt den Unterschied zwischen analog und digital?
-2) Wer kennte die 3-2-1 Regel?
+2) Wer hat schon mal eine Datei von einem Format in ein anderes konvertiert?
-3) Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
+3) Wer hat schon mal Metadaten aus einem Foto entfernt?
-4) Wer hat schon mal mit APIs gearbeitet?
+4) Wer kennt die 3-2-1 Backup-Regel?
-5) Wer weiß, was UTF-8 bedeutet?
+5) Wer hat schon mal eine API benutzt?
-6) Wer hat schon mal mit einem CLI gearbeitet?
-6) **Wer hat schon mal etwas mit HTML oder CSS gemacht?** (Hex-Farben wie `#FF0000`?)
 
 <!--
 Niveau der Gruppe einschätzen
 Keine falschen Antworten
 Zeigt, wo wir starten
-HTML/CSS-Frage: Viele kennen Hex-Codes aus Webdesign
 API = Application Programming Interface
 -->
 
 ---
 
-# Warum dieses Modul?
-
-**Digitale Medien sind überall** – aber was steckt dahinter?
-
-* Warum ist ein JPEG kleiner als ein PNG?
-* Warum klingt MP3 anders als FLAC?
-* Warum zeigt meine 1 TB Festplatte nur 931 GB?
-* Warum ist USB-C so verwirrend?
-* Wie funktioniert eigentlich Streaming?
-* **→ Die Technik dahinter verstehen!**
-
-<!--
-Praxisnahe Fragen aus dem Alltag
-Nicht nur "was", sondern "warum"
-Verständnis für technische Entscheidungen
--->
-
----
-
-# Das Ziel
-
-**Technische Grundlagen verstehen**, um fundierte Entscheidungen treffen zu können.
-
-Als Digital- und Medienwirtschaftler:innen werdet ihr täglich mit technischen Fragen konfrontiert:
-* Welches Format für welchen Zweck?
-* Welche Schnittstelle für welches Gerät?
-* Wie funktioniert die Distribution digitaler Inhalte?
-* **→ Mitreden können – nicht (zwingend) programmieren!**
-
-<!--
-Nicht: Ihr sollt Programmierer werden
-Sondern: Ihr sollt technische Entscheidungen verstehen
-Praxisbezug: Medienproduktion, Marketing, Projektmanagement
--->
-
----
-
-# Was ihr lernt
-
-**In dieser Veranstaltung erwerbt ihr folgende Kompetenzen:**
-
-* Fundiertes Grundwissen über Daten und Informationen
-* Dateiformate analysieren und verstehen
-* Grundlagen von Kompression (Audio, Bild, Video)
-* Speichermedien unterscheiden
-* Programmier-Schnittstellen kennenlernen
-* APIs und Distributionswege verstehen
-
-<!--
-Fokus auf Verständnis, nicht auf Programmierung
-Hands-On jede Woche: Selbst ausprobieren
-Ziel: Einblick in die Denkweise von Software-Entwicklern
--->
-
----
-
 # Kursübersicht
 
-**5 Termine:**
+**Kapitel:**
 
-| # | Datum | Thema |
+1. Grundlagen, Text & **Audio** (Bits, Bytes, Zeichenkodierung, MP3)
-|---|-------|-------|
+2. **Bild** & **Video**-Kompression (JPEG, PNG, H.264/H.265)
-| 1 | 19.12.2025 | Bits, Bytes, Zeichenkodierung & Audio |
+3. **Speichermedien** & **Schnittstellen** (HDD, SSD, USB, Thunderbolt)
-| 2 | 09.01.2026 | Bild- & Video-Kompression |
+4. **Distribution**, **APIs** & Zukunft (Streaming, REST, Cloud)
-| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
+5. Vertiefung & offene Fragen
-| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
-| 5 | TBA | Vertiefung & offene Fragen |
 
-**Format:** Theorie + Hands-On (30-40 Min pro Termin)
-
-<!--
-Nicht nur theoretische Inhalte
-Praktische Übungen jede Woche
-Medienwissenschaftler:innen, nicht Informatiker:innen
--->
 
 ---
 
-# Prüfungsleistung 18.02.
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
+
+# Prüfungsleistung
 
 **Nach aktuellem Kenntnisstand:**
 
-* 90 min (40% Grundlagen, 40% Dateiformate, 20% AV)
+* 90 min insg. (Technik 1)
-* Schriftliche Klausur
+* Schriftliche Klausur (digital)
 * Teils offene Fragen
-* Vermutlich digital
+* Kein Coding/Programmieren
-* Kein Coding!
+* **Prüfungsrelevante Folien:**
-* **Prüfungsrelevant:** Alles in den Folien/im Skript
+  - Gestreift oder Vollton (PDF) markiert
-
-<!--
-Details können sich noch ändern
-Keine Programmieraufgaben
-Verständnisfragen, keine Auswendiglernerei
--->
-

slides/223015b/01-grundlagen-text-audio.md

@@ -135,6 +135,15 @@ Hochschule der Medien Stuttgart
 
 ---
 
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/compact-disc-cd.jpg)
+
+---
+
+![bg right:40%](./assets/IMG_3617.jpg)
+
 # Ein konkretes Beispiel
 
 **Eine Minute Musik in CD-Qualität:**
@@ -154,6 +163,8 @@ Aber es skaliert schnell.
 
 ---
 
+![bg right:40%](./assets/IMG_3617.jpg)
+
 # Das Problem skaliert
 
 | Inhalt | Unkomprimiert |
@@ -174,6 +185,8 @@ Das Problem musste gelöst werden.
 
 ---
 
+![bg right:32% contain](./assets/dvd.jpg)
+
 # Video eskaliert
 
 **Eine Minute 4K-Video (unkomprimiert):**
@@ -195,11 +208,33 @@ Die physikalische Realität erzwingt Kompression.
 
 ---
 
+![bg right:40%](./assets/artemis.jpg)
+
+# Artemis II orbitiert
+
+| | Apollo (1969) | Artemis II (2026) |
+|---|---|---|
+| Bandbreite | ~50 kbit/s | 260 Mbit/s |
+| Video | SW, ~320 Zeilen | HD live, 4K gespeichert |
+| Codec | analog | H.265 (HEVC) |
+
+260.000.000 Bit/s
+÷ 8 (Bit pro Byte) = 32,5 MB/s
+× 60 Sekunden = **1,95 GB pro Minute**
+
+*Apollo: 50 kbit/s = 0,375 MB/min*
+
+<!--
+Übertragung per Infrarot-Laser (O2O = Orion Artemis II Optical Communications). MAScOT-Terminal entwickelt von MIT Lincoln Lab. 32 Kameras an Bord (Nikon D5/Z9, GoPros, Redwire 4K-Festkameras). ZCube-Encoder kodiert H.265 an Bord. Bandbreite geteilt mit Telemetrie und Voice — daher live "nur" HD, echtes 4K kommt auf CompactFlash-Karten nach Splashdown. Latenz Mond ↔ Erde: ~1,3 Sekunden (384.400 km). Apollo nutzte S-Band Radio, Artemis II Infrarot-Laser.
+-->
+
+---
+
 # Kompressionsraten in der Praxis
 
 | Medium | Unkomprimiert | Komprimiert | Faktor |
 |--------|-------------:|------------:|-------:|
-| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 320) | ~10× |
+| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 128) | ~10× |
 | 1 Foto (12 MP) | ~36 MB | ~3 MB (JPEG) | ~12× |
 | 1 Min 4K-Video | ~45 GB | ~375 MB (H.264) | ~120× |
 
@@ -282,12 +317,12 @@ Sondern gezielt das entfernen, was Menschen nicht wahrnehmen.
 | | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
 |---|---|---|
 | **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
-| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
+| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich verloren) |
 | **Reduktion** | 30-50% | 80-99% |
 | **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
 
 **Faustregel:**
-- Medien für Endnutzer → Lossy oft akzeptabel
+- Medien für EndnutzerInnen → Lossy oft akzeptabel
 - Quellmaterial, Code, Archive → Lossless nötig
 
 <!--
@@ -312,7 +347,7 @@ Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der
 
 **Verlustfreie Kompression** erreicht diese Grenze durch:
 - **Statistische Kodierung:** Huffman, Arithmetic Coding
-- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG)
+- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG, TAR)
 - Originalzustand ist exakt rekonstruierbar
 
 **Verlustbehaftete Kompression** unterschreitet die Grenze, indem sie menschliche Wahrnehmungsgrenzen ausnutzt:
@@ -322,7 +357,32 @@ Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der
 | Gehör | Maskierungseffekte, Hörschwelle | MP3: Töne unter Maskierungsschwelle weglassen |
 | Sehen | Farbauflösung, Kontrastempfindlichkeit | JPEG: Chroma-Subsampling, hohe Frequenzen verwerfen |
 
-**Shannon-Limit:** Verlustfreie Kompression kann nicht unter die Entropie; verlustbehaftete kann beliebig weit gehen – auf Kosten der Qualität.
+**Shannon-Limit:** Verlustfreie Kompression ist durch Entropie begrenzt; Verlustbehaftete Kompression kann beliebig weit gehen – auf Kosten der Qualität.
+
+<!--
+ABKÜRZUNGEN:
+- LZ = Lempel-Ziv (nach Abraham Lempel und Jacob Ziv)
+- LZ77 = Lempel-Ziv 1977 – Sliding-Window-Verfahren: sucht Wiederholungen in einem Fenster der letzten Bytes und ersetzt sie durch Rückverweise (Offset + Länge)
+- LZ78 = Lempel-Ziv 1978 – baut ein explizites Wörterbuch auf: neue Muster bekommen einen Index, Wiederholungen werden durch den Index ersetzt
+- DEFLATE = Kombination aus LZ77 + Huffman-Coding; verwendet in ZIP, PNG und gzip
+- TAR = Tape ARchive – kein Kompressionsformat, sondern ein Archivformat (bündelt Dateien zu einer). Kompression erst durch Kombination: .tar.gz (gzip = DEFLATE), .tar.bz2 (bzip2), .tar.xz (LZMA)
+- ZIP = Archivformat mit eingebauter DEFLATE-Kompression (Phil Katz, 1989)
+- PNG = Portable Network Graphics – nutzt DEFLATE für verlustfreie Bildkompression
+
+STATISTISCHE KODIERUNG:
+- Huffman-Coding: Häufige Zeichen bekommen kurze Bitfolgen, seltene Zeichen lange. Beispiel: 'e' (häufig) → 2 Bit, 'q' (selten) → 8 Bit
+- Arithmetic Coding: Kodiert die gesamte Nachricht als einzelne Zahl zwischen 0 und 1. Etwas effizienter als Huffman, aber rechenintensiver
+
+ENTROPIE (Shannon):
+- Maß für den Informationsgehalt: Wie "überraschend" ist jedes Zeichen?
+- Hohe Entropie = schwer komprimierbar (z.B. verschlüsselte Daten, Rauschen)
+- Niedrige Entropie = gut komprimierbar (z.B. "AAAAAAA" oder natürliche Sprache)
+- Theoretisches Minimum: kein Algorithmus kann unter die Entropie-Grenze kommen
+
+PRAXISBEISPIEL:
+- ZIP einer .txt-Datei: ~60-70% kleiner (Text hat niedrige Entropie)
+- ZIP einer .jpg-Datei: kaum kleiner (JPEG hat Entropie schon ausgereizt)
+-->
 
 ---
 
@@ -400,11 +460,15 @@ BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
 **1 Byte = 8 Bits**
 
 ```
-0 1 0 0 1 1 0 1
+0 0 1 0 1 0 1 0
 ```
 
 <!--
 
+
+binary 00101010 
+= decimal 42
+
 Rätsel: "Wenn sich das Wachstum einer Seerose auf einem Teich jeden Tag verdoppelt · und nach *zehn Tagen* der ganze Teich bedeckt ist, wann ist er zur Hälfte zugewachsen?"
 
 Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
@@ -418,7 +482,7 @@ Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
 **1 Byte = 8 Bits**
 
 ```
-0 1 0 0 1 1 0 1
+0 0 1 0 1 0 1 0
 ```
 
 2⁸ = **256 Möglichkeiten** (0-255)
@@ -500,8 +564,8 @@ Das menschliche Auge kann etwa 10 Millionen Farben unterscheiden
 <!--
 Welche Farben für ein volles Spektrum bieten sich nach unserer gelernten Sparsamkeit hier am besten an?
 
-1. CMYK bzw. in diesem Fall CMYW
+1. CMYK (Cyan, Magenta, Yellow, Key/Black) bzw. in diesem Fall CMYW (Cyan, Magenta, Yellow, White)
-2. RGB
+2. RGB (Red, Green, Blue)
 -->
 
 ---
@@ -539,23 +603,16 @@ Sog. RGB Tuple (geordnete endliche Liste)
 <!--
 "Weiß jemand oder möchte jemand raten, wofür das "s" bei "sRGB" steht?"
 
-sRGB = Standard RGB
+sRGB = Standard RGB (Red, Green, Blue)
-CMYK = Subtraktive Farbmischung (Druck)
+CMYK = Cyan, Magenta, Yellow, Key (Black) – Subtraktive Farbmischung (Druck)
 Hex-Notation: FF = 255 in Dezimal
-CSS-Farben nutzen Hex: #FF0000 = Rot
+CSS (Cascading Style Sheets)-Farben nutzen Hex: #FF0000 = Rot
-Wer HTML/CSS gemacht hat, kennt das schon!
+Wer HTML (HyperText Markup Language)/CSS gemacht hat, kennt das schon!
 background-color: #FF0000; = Rot
 -->
 
 ---
 
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg fit](./assets/hex-dec-lookup-table.png)
-
----
-
 # Das Problem: Sprachen
 
 **Die Welt hat mehr als 256 Zeichen!**
@@ -564,11 +621,9 @@ background-color: #FF0000; = Rot
 - + Ziffern: 10 (0-9)
 - + Sonderzeichen: ~30
 
-**≈ 90 Zeichen → passt in 1 Byte**
+**≈ 90 Zeichen passen problemlos in 1 Byte**
 
-**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
+**Jedoch ohne** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 🌸  
-
-→ **1 Byte reicht nicht!**
 
 <!--
 Problem der Zeichenkodierung
@@ -606,7 +661,7 @@ WICHTIG für Kontext zur ASCII-Folie:
 Byte-Längen:
 - ASCII-Zeichen (0-127): 1 Byte
 - Umlaute, diakritische Zeichen: 2 Bytes
-- Chinesisch, Japanisch, Koreanisch: 3 Bytes
+- CJK -> Chinesisch, Japanisch, Koreanisch: 3 Bytes
 - Emoji, seltene Zeichen: 4 Bytes
 -->
 
@@ -644,7 +699,7 @@ Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
 
 # Hexadezimal: Lesbarkeit
 
-**Binär ist unleserlich:**
+**Für den Menschen ungeeignet:**
 `01010000 01001110 01000111`
 
 **Hexadezimal (Base 16):**
@@ -653,12 +708,17 @@ Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
 **Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
 0-9, A-F (10=A, 11=B, ..., 15=F)
 
+`5 = 0101` `0 = 0000`
+`4 = 0100` `E = 1110`
+`4 = 0100` `7 = 0111`
+
 **ASCII Tabelle (0-127):**
 [https://www.asciitable.com](https://www.asciitable.com)
 
 <!--
 
-"Gerne vorab auf den Link gehen"
+Dezimalsystem passt nur umständlich 0->15 (1111) ins binäre System
+Hexadezimal (16) passt perfekt
 
 WICHTIG: ASCII geht nur von 0-127!
 - Werte 128-255 sind NICHT in der ASCII-Tabelle
@@ -684,7 +744,12 @@ Hex-Editor = Standard-Tool für Dateianalyse und Reverse Engineering
 
 ---
 
+<!-- _header: '' -->
+<!-- _footer: '' -->
 
+![bg fit](./assets/hex-dec-lookup-table.png)
+
+---
 
 <!-- _class: lead -->
 
@@ -702,12 +767,12 @@ KULTURHISTORISCHER KONTEXT:
 - "American Standard Code for Information Interchange" (1963)
 - Entwickelt für US-amerikanische Bedürfnisse
 - Keine Unterstützung für: Umlaute (ä, ö, ü), ß, diakritische Zeichen (é, ñ, ç)
-- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK) wurden nicht berücksichtigt
+- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK = Chinese, Japanese, Korean) wurden nicht berücksichtigt
 - Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)
 
 WARUM NOCH HEUTE RELEVANT?
-- Abwärtskompatibilität: UTF-8 ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
+- Abwärtskompatibilität: UTF-8 (Unicode Transformation Format, 8-bit) ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
-- Internetprotokolle basieren auf ASCII: HTTP-Header, SMTP, URLs
+- Internetprotokolle basieren auf ASCII: HTTP (HyperText Transfer Protocol)-Header, SMTP (Simple Mail Transfer Protocol), URLs (Uniform Resource Locator)
 - Programmiersprachen: Schlüsselwörter und Syntax sind ASCII
 - Ein 60 Jahre alter Standard, der durch Kompatibilitätszwänge fortbesteht
 
@@ -770,7 +835,7 @@ US-ASCII (1967) Code Chart
 | `0100 1110` | `4E` | 78 | **N** |
 | `0100 0111` | `47` | 71 | **G** |
 
-→ **PNG**-Signatur! (Das `89` markiert: "Ich bin binär, kein Text!")
+→ `89` übersteigt den ASCII-Raum und markiert eie Binärdatei
 
 <!--
 Hex = 2 Ziffern = 1 Byte = 8 Bit
@@ -853,7 +918,7 @@ WARUM nutzt PNG absichtlich 89 (= 137 dezimal)?
 Geschichte: "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
 Fun Fact: DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt!
 
-Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML
+Dateien OHNE Magic Number: TXT, HTML (HyperText Markup Language), CSS (Cascading Style Sheets), JSON (JavaScript Object Notation), XML (Extensible Markup Language)
 → Reiner Text, kein binäres Format
 
 Sicherheits-Aspekt:
@@ -882,8 +947,8 @@ Windows vertraut der Endung, aber "file" (Linux) liest Magic Number
 | **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
 
 <!--
-SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
+SI (Système International d'Unités)-Präfixe (Dezimal): 1 KB = 1.000 Bytes
-Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
+Binär (IEC = International Electrotechnical Commission): 1 KiB = 1.024 Bytes (Kibibyte)
 Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
 1 TB Festplatte = ~931 GiB nutzbar
 
@@ -974,9 +1039,9 @@ ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
 
 DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
 
-HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
+HEUTE: LTO-9 (LTO = Linear Tape-Open, 2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
 
-VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
+VERGLEICH: SSD (Solid State Drive) ~$50/TB, HDD (Hard Disk Drive) ~$15/TB, LTO ~$5/TB
 
 -->
 
@@ -1032,7 +1097,7 @@ AWS Glacier, Google Coldline und Film-Archive nutzen LTO – langsamer Zugriff,
 
 <!--
 Quellen: IDC Global DataSphere Forecast, Statista 2025
-IoT-Geräte allein: 73 ZB in 2025
+IoT (Internet of Things)-Geräte allein: 73 ZB in 2025
 Cloud-Speicher: 100 ZB (50% der Weltdaten)
 Prognose 2028: 394 ZB
 -->
@@ -1041,10 +1106,14 @@ Prognose 2028: 394 ZB
 
 
 <!-- _header: '' -->
-<!-- _footer: 'Floridi, L.: The forth Revolution' -->
+<!-- _footer: '' -->
 
 
-![bg fit](./assets/growth of big data.png)
+![bg fit](./assets/growth-of-big-data.png)
+
+<!--
+Quelle: Floridi, L.: The Fourth Revolution
+-->
 
 ---
 
@@ -1145,7 +1214,7 @@ Analoge Speicherung codiert Information als **kontinuierliche physikalische Grö
 <!--
 GENERATIONSVERLUST:
 Kassette → Kassette = jede Kopie schlechter
-VHS → VHS = Rauschen nimmt zu
+VHS (Video Home System) → VHS = Rauschen nimmt zu
 Schallplatte: Jedes Abspielen = minimaler Verschleiß
 
 ABER: Analoges Original bleibt "das Original"
@@ -1216,7 +1285,7 @@ Digitale Speicherung quantisiert kontinuierliche Signale in diskrete Werte. Der
 |--------|--------|---------|
 | Kopiervorgang | Physikalischer Prozess | Bit-Kopie |
 | Qualität pro Generation | Verschlechtert | Identisch |
-| Fehlerkorrektur | Unmöglich | Möglich (ECC, RAID) |
+| Fehlerkorrektur | Unmöglich | Möglich (ECC = Error Correcting Code, RAID = Redundant Array of Independent Disks) |
 | Formatmigration | Verlust | Verlustfrei möglich |
 
 **Die Kehrseite:** Digitale Obsoleszenz. Ein DOCX von 2025 ist in 50 Jahren womöglich unlesbar – während ein Buch von 1525 heute noch lesbar ist. Offene Formate (PDF/A, FLAC, PNG) mildern dieses Risiko.
@@ -1507,7 +1576,7 @@ Patent lief 2017 aus
 - Forschung ab 1982, Patent 1988
 
 <!--
-Fraunhofer IIS Erlangen
+Fraunhofer IIS (Institut für Integrierte Schaltungen) Erlangen
 Forschung dauerte über 10 Jahre
 Perfektionist: Jeder Hörtest musste bestehen
 -->
@@ -1574,7 +1643,7 @@ Ein Zusammenspiel aus vielen Faktoren:
 <!--
 MP3-Kompression in 4 Schritten (vereinfacht):
 
-1. FFT (Fast Fourier Transform)
+1. FFT (Fast Fourier Transform = Schnelle Fourier-Transformation)
    - Wandelt Schallwellen in Frequenzen um
    - Wie ein Prisma Licht in Farben zerlegt
 
@@ -1586,7 +1655,7 @@ MP3-Kompression in 4 Schritten (vereinfacht):
 3. Quantisierung (hier passiert der Datenverlust!)
    - Unwichtige Frequenzen werden "grob" gespeichert
    - Wichtige Frequenzen bleiben genau
-   - Wie JPEG: Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
+   - Wie JPEG (Joint Photographic Experts Group): Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
 
 4. Huffman-Coding (verlustfrei)
    - Häufige Muster = kurze Codes
@@ -1659,7 +1728,7 @@ KERNKONZEPT: Kompression = Modell der menschlichen Wahrnehmung
 **Prinzip:** Wiederholungen zählen statt wiederholen
 
 <!--
-RLE = Run-Length Encoding = Lauflängenkodierung
+RLE = Run-Length Encoding (Lauflängenkodierung)
 Einfachster Kompressionsalgorithmus
 Gut für: Fax, einfache Grafiken, Icons
 Schlecht für: Fotos, Audio (zu chaotisch)
@@ -1684,7 +1753,7 @@ Schlecht für: Fotos, Audio (zu chaotisch)
 Fraunhofer verklagte Winamp, andere Tools
 Millionen nutzten unlizenzierte Software
 Das Pferd war aus dem Stall
-2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
+2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC = Advanced Audio Coding, besser)
 -->
 
 ---
@@ -1727,7 +1796,7 @@ Aber: LimeWire, Kazaa, BitTorrent folgten
 → LimeWire, Kazaa, BitTorrent, später Spotify
 
 <!--
-RIAA (Recording Industry Association of America) verklagte Napster
+RIAA = Recording Industry Association of America – verklagte Napster
 Urteil: Napster muss schließen (2001)
 Aber: Technologie nicht mehr aufzuhalten
 iPod (2001): "1.000 songs in your pocket"
@@ -1795,7 +1864,7 @@ Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
 - Spektrogramme vergleichen Audacity (kostenloser Download nötig) [https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html)
 
 <!--
-Audacity: FOSS Audio-Editor (audacityteam.org)
+Audacity: FOSS (Free and Open-Source Software) Audio-Editor (audacityteam.org)
 Export: Datei → Exportieren → MP3 → Bitrate wählen
 Spektrogramm-Ansicht: Auf Track-Name klicken (Dropdown öffnet sich) → "Spektrogramm" wählen
 Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate

slides/223015b/klausurfolien.md

@@ -112,7 +112,7 @@ Hochschule der Medien Stuttgart
 | **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
 
 **Faustregel:**
-- Medien für Endnutzer → Lossy oft akzeptabel
+- Medien für EndnutzerInnen → Lossy oft akzeptabel
 - Quellmaterial, Code, Archive → Lossless nötig
 
 <!--

slides/223015c/00-intro.md

@@ -0,0 +1,228 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Grundlagen IT- und Internettechnik (223015c)"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
+title: Grundlagen IT- und Internettechnik
+---
+
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #d63384;
+  --color-dimmed: #4a4a6a;
+}
+section.invert {
+  --color-foreground: #fff;
+}
+section {
+  font-size: 1.7rem;
+}
+h1 {
+  color: #a02060;
+}
+section.invert h1 {
+  color: #fff;
+}
+h2 {
+  color: #1f2937;
+}
+pre {
+  background: #0f0f23;
+  color: #d63384;
+  border-radius: 8px;
+  border-left: 3px solid #d63384;
+}
+pre code {
+  background: transparent;
+  color: inherit;
+}
+code {
+  background: #1a1a2e;
+  color: #d63384;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+}
+a {
+  color: var(--color-highlight);
+}
+section.klausur {
+  background: repeating-linear-gradient(
+    135deg,
+    #fce4ec,
+    #fce4ec 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.klausur {
+    background: #fce4ec !important;
+  }
+}
+section.aufgabe {
+  background: #fce4ec !important;
+}
+section.aufgabe footer {
+  display: none;
+}
+</style>
+
+<!-- _class: invert -->
+<!-- _header: '' -->
+<!-- _backgroundColor: #000 -->
+
+![bg cover opacity:0.2](./assets/background-termin-1.png)
+
+# Grundlagen IT- und Internettechnik
+
+**223015c** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Sommersemester 2026**
+
+[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/qr/slides-223015c.png)
+
+---
+
+<!-- _class: lead -->
+
+# Herzlich willkommen!
+## Einführung
+
+---
+
+# Über mich
+
+**Michael Werner Czechowski**
+
+- Systems and Platform Engineer
+- Schwerpunkte:
+  - Web-Technologien, Barriere-Armut, Open Source
+- Hintergrund:
+  - Philosophie (Uni Stuttgart)
+  - Wirtschaftsinformatik (Leibniz-FH Hannover)
+- Kontakt: lb-czechowski@hdm-stuttgart.de
+
+---
+
+# Warum dieses Modul?
+
+**Das Internet ist überall** – aber was steckt dahinter?
+
+* Warum sehen Webseiten auf dem Handy anders aus?
+* Wie funktioniert eigentlich das Internet?
+* Wie erkennen Sie, ob eine Werbeagentur gute Arbeit leistet?
+* Was hat ein Unterseekabel mit meiner E-Mail zu tun?
+* **→ Die Technik dahinter verstehen und fundierte Entscheidungen treffen**
+
+---
+
+# Das Ziel
+
+**Technische Grundlagen verstehen**, um fundierte Entscheidungen treffen zu können.
+
+Als Digital- und MedienwirtschaftlerInnen werdet ihr täglich mit technischen Fragen konfrontiert:
+* Wie baue ich eine barrierearme Webseite?
+* Welches Protokoll für welchen Zweck?
+* Wie funktioniert das Web hinter den Kulissen?
+* **→ Mitreden können – und selbst Webseiten bauen!**
+
+---
+
+# Was Sie hier lernen werden
+
+**In dieser Veranstaltung erwerben Sie folgende Kompetenzen:**
+
+* Geschichte des Computers und Internets
+* HTML-Grundlagen und semantisches Markup
+* CSS für Layout und Gestaltung
+* Netzwerke und Protokolle (TCP/IP, DNS, HTTP(S))
+* "Barrierefreiheit" im Web
+* Grundlagen von JavaScript und Interaktivität
+
+---
+
+# Kurze Umfrage
+
+**Bitte Hand heben:**
+* Wer hat schon mal eine Webseite gebaut?
+* Wer weiß, was HTML ist?
+* Wer hat schon mal CSS geschrieben? 
+* Wer kennt den Unterschied zwischen Internet und WWW? 
+* Wer hat schon mal mit JavaScript gearbeitet?
+
+---
+
+# Kursübersicht
+
+**Kapitel:**
+
+1. Geschichte, Grundlagen & **HTML**
+2. Netzwerke, Protokolle, **semantisches HTML** & **CSS**
+3. Interaktivität, Animationen & **JavaScript**
+
+**Ziel:** "Gelernte Hilflosigkeit" ablegen
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #fce4ec -->
+
+# Prüfungsleistung
+
+**Nach aktuellem Kenntnisstand:**
+
+* 90 min insg. (Technik 1)
+* Schriftliche Klausur (digital)
+* Teils offene Fragen
+* So gut wie kein Coding/Programmieren
+* **Prüfungsrelevant:** Folien sind markiert mit anderem Hintergrund
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/klausur-01.png)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/klausur-02.png)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/klausur-03.png)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/splan.png)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/asta.png)
+

slides/223015c/01-geschichte-grundlagen-html.md

@@ -140,6 +140,38 @@ Hochschule der Medien Stuttgart
 
 ---
 
+# Ressourcen zum Selbstlernen
+
+* **CODE CRISPIES: https://codecrispi.es/**
+* Online Code-Editor: https://codepen.io/pen/
+* MDN (Mozilla Developer Network): https://developer.mozilla.org/de/
+* Flexbox-Spiel: https://flexboxfroggy.com/
+* Grid-Spiel: https://cssgridgarden.com/
+
+<!--
+SPEAKER NOTES:
+- Code Crispies = unser Material
+- Codepen = sofort CSS ausprobieren
+- MDN = DIE Referenz schlechthin
+- Spiele für Flexbox/Grid – später relevant
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg cover](./assets/diday.png)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/signal-2026-04-09-190024_002.jpeg)
+
+---
+
 <!-- _class: lead -->
 
 # Kapitel 1
@@ -596,6 +628,77 @@ COBOL läuft heute noch auf Bankensystemen
 
 ---
 
+# Assembler (1947)
+
+**Die erste Stufe über Maschinencode**
+
+- Erfunden von **Kathleen Booth** (Birkbeck College, London)
+- Mnemonische Befehle statt Binärzahlen (`MOV`, `ADD`, `JMP`)
+- Jeder Befehl entspricht direkt einer CPU-Instruktion
+- Hardwarenah, aber für Menschen lesbar
+
+**Fun Fact:** Chris Sawyer schrieb **RollerCoaster Tycoon** (1999) fast komplett in x86-Assembly
+
+<!--
+KATHLEEN BOOTH (1922–2022):
+Kathleen Hylda Valerie Booth (geb. Britten), BSc Mathematik (Royal Holloway, London), PhD Applied Mathematics (King's College London). Arbeitete ab 1946 mit Andrew Booth (später ihr Ehemann) am Birkbeck College – eines der kleinsten Computing-Teams Großbritanniens: nur Andrew, Kathleen und Xenia Sweeting.
+
+WAS SIE TAT:
+Kathleen baute die Hardware des ARC (Automatic Relay Calculator) mit auf und entwickelte dann die Programmierarchitektur. 1947 reiste sie mit Andrew nach Princeton, wo sie John von Neumann trafen und die Stored-Program-Architektur kennenlernten. Sie schrieb "Coding for A.R.C." – die erste veröffentlichte Beschreibung einer Assembly-Sprache. Statt roher Binärzahlen (z.B. 10011) konnten Programmierer nun mnemonische Kürzel verwenden (z.B. M -> cR). Ein konzeptioneller Sprung – die erste Abstraktionsschicht zwischen Mensch und Maschine.
+
+VOR ASSEMBLER:
+ENIAC (1943–46) wurde durch physisches Umstecken von Kabeln programmiert – Programmwechsel dauerten Tage. Danach kamen Stored-Program-Computer, aber Programme mussten als rohe Binärzahlen eingegeben werden. Jeder Tippfehler in einer 0/1-Folge konnte den Befehl komplett verfälschen.
+
+WEITERE LEISTUNGEN:
+- Mitentwicklung von Booth's Multiplication Algorithm (heute in Milliarden CPUs)
+- Pionierin der neuronalen Netze (1958/59 – nur ~4 Jahre nach den allerersten)
+- Erste öffentliche Demonstration maschineller Übersetzung (Französisch→Englisch, 1955)
+- Wurde 100 Jahre alt
+
+ROLLERCOASTER TYCOON:
+Chris Sawyer, schottischer Entwickler, schrieb RCT zu 99% in x86-Assembly (MASM), nur 1% C für Windows-Schnittstellen. Warum? Assembler war seine "Muttersprache" seit Kindheit, und Performance war kritisch: Tausende Besucher mit eigenem Verhalten, Fahrgeschäfte, Pathfinding – alles in Echtzeit. Das Spiel lief auf einem Pentium 90 MHz mit 16 MB RAM. Sawyer verdiente ca. 30 Mio. Dollar an Royalties und hat über 700 Achterbahnen weltweit selbst gefahren.
+-->
+
+---
+
+# Fortran (1957)
+
+**Die erste höhere Programmiersprache**
+
+- Entwickelt bei IBM unter **John Backus**
+- Im Team: **Lois Haibt** – verantwortlich für die Control-Flow-Analyse
+- Name: **For**mula **Tran**slator
+- Ziel: Mathematische Formeln direkt als Code schreiben
+- Revolutionär: ~**20 Assembler-Befehle → 1 Fortran-Zeile**
+- Noch heute genutzt in Wissenschaft und Hochleistungsrechnen
+
+<!--
+JOHN BACKUS (1924–2007):
+Unruhiger Werdegang – Chemiestudium abgebrochen, aus der Uni geflogen, Armee, Medizinstudium abgebrochen (Hirntumor, erfolgreich behandelt), dann Mathematik an der Columbia University. Bei IBM ab 1950. Seine Motivation war schlicht Faulheit: "Much of my work has come from being lazy. I didn't like writing programs." Er entwickelte erst Speedcoding (1953), dann leitete er das Fortran-Projekt. Später: Backus-Naur-Form (BNF), Turing Award 1977.
+
+LOIS HAIBT (*1934):
+Studierte Mathematik am Vassar College (Stipendium), jobbte in den Semesterferien bei Bell Labs. IBM bot ihr nach dem Abschluss 1955 $5.100/Jahr – fast doppelt so viel wie Bell Labs. Sie kam ohne jegliche Programmiererfahrung ins Team und war mit 21 Jahren die einzige Frau unter den 10 Kernentwicklern. Ihre Aufgabe (Section 4 des Compilers): Sie teilte Programme in "Basic Blocks" auf, erstellte einen Control-Flow-Graphen und simulierte per Monte-Carlo-Methode, welche Programmteile häufig durchlaufen werden ("Hot Paths"). Diese Info nutzte der Compiler für die Register-Optimierung. Ein für 1956 extrem fortschrittlicher Ansatz. Außerdem entwickelte sie den ersten syntaktischen Analysator für arithmetische Ausdrücke – ein Grundbaustein aller modernen Compiler. Ihre Tochter Carolyn studierte später in Princeton und promovierte am MIT in Mathematik.
+
+Haibt über die Teamkultur: "No one was worried about seeming stupid or possessive of his or her code. We were all just learning together."
+
+DAS TEAM:
+~10 Kernmitglieder, alle in ihren 20ern und 30ern, mit "varying academic degrees and unrelated areas of expertise". Harlan Herrick schrieb das erste jemals ausgeführte Fortran-Programm. Roy Nutt war von United Aircraft ausgeliehen. David Sayre war Kristallograph.
+
+ENTWICKLUNG:
+Sollte 6 Monate dauern, brauchte 3 Jahre (1954–1957). Das Team arbeitete nachts, weil sie nur dann Zugang zum IBM 704 hatten, und schlief tagsüber im Langdon Hotel an der 56th Street. Schneballschlachten lockerten die langen Winternächte auf.
+
+WARUM ES FUNKTIONIERTE:
+Das Killerkriterium war Performance: Frühere Compiler erzeugten Code, der 5–10× langsamer war als handgeschriebener Assembler. Fortran I war der erste Compiler, der annähernd gleich schnellen Code erzeugte. Dieser Rekord hielt 20 Jahre. Ken Thompson (Erfinder von Unix): "95% of the people who programmed in the early years would never have done it without Fortran."
+
+HEUTE:
+Fortran ist die "Muttersprache des Scientific Computing". Wettervorhersage (GFS, WRF), Klimamodelle (CESM für IPCC-Berichte), Kernphysik-Simulationen, LAPACK/BLAS (die linearen Algebra-Bibliotheken unter NumPy/SciPy) – alles Fortran. In numerischen Benchmarks 30–60× schneller als Python.
+
+PARALLELE ZU HEUTE:
+Assembly-Programmierer sahen Fortran als existenzielle Bedrohung ihrer Kunst – genau wie heute manche Programmierer KI fürchten. Das Ergebnis war dasselbe: Das Werkzeug erweiterte das Feld, statt es zu ersetzen.
+-->
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
@@ -739,11 +842,6 @@ ARPANET-Karte 1969
 
 ![bg](./assets/arpanet.jpg)
 
-<!--
-ARPANET-Karte 1969
-4 Knoten: UCLA, Stanford, UCSB, Utah
--->
-
 ---
 
 # Das WWW (1989)
@@ -766,6 +864,14 @@ WWW war NICHT kommerziell geplant!
 Kostenlos freigegeben → darum existiert es
 -->
 
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/mosaic.jpg)
+
+
 ---
 
 <!-- _header: '' -->
@@ -850,7 +956,7 @@ Shannon: Begründer der Informationstheorie
 **8 Bits = 1 Byte**
 
 ```
-0 1 0 0 1 0 0 1
+0 0 1 0 1 0 1 0
 ```
 
 **Wie viele Kombinationen?**
@@ -882,23 +988,50 @@ Farbbild: Rot + Grün + Blau
 
 ---
 
+# Zahlensysteme
+
+**Eine Ziffer — wie viele Werte?**
+
+| System | Basis | Ziffern | Beispiel |
+|--------|-------|---------|----------|
+| **Dezimal** | 10 | 0-9 | `42` = 4×10 + 2 |
+| **Binär** | 2 | 0-1 | `101010` = 42 |
+| **Hexadezimal** | 16 | 0-F | `2A` = 2×16 + 10 |
+
+→ Alle drei beschreiben dieselbe Zahl: **42**
+
+<!--
+Dezimal = was wir im Alltag nutzen (10 Finger → 10 Ziffern)
+Binär = was Computer nutzen (Strom an/aus → 2 Zustände)
+Hexadezimal = Kompromiss: kompakter als Binär, aber passt perfekt auf Bytes (2 Hex-Ziffern = 1 Byte = 8 Bit)
+Die Basis bestimmt, wie viele Symbole pro Stelle zur Verfügung stehen:
+- Dezimal: 10 (0–9)
+- Binär: 2 (0, 1)
+- Hex: 16 (0–9 + A–F, wobei A=10, B=11, ..., F=15)
+-->
+
+---
+
 # Hexadezimal: Lesbarkeit
 
-**Binär ist unleserlich:**
+**Für den Menschen ungeeignet:**
 `01001101 01010000 00110011`
 
 **Hexadezimal (Base 16):**
 `4D 50 33` (= "MP3" in ASCII)
 
-**Jede Hex-Ziffer = 4 Bits**
+**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
 0-9, A-F (A=10, B=11, ..., F=15)
 
-**Ihr kennt das:** `#FF0000` = Rot in CSS
+`4 = 0100` `D = 1101`
+`5 = 0101` `0 = 0000`
+`3 = 0011` `3 = 0011`
 
 <!--
 Hex = Shortcut für Menschen
 1 Byte = 2 Hex-Ziffern (00-FF)
-CSS-Farben nutzen Hex
+"Nibble" = 4 Bits = halbes Byte (Wortspiel: nibble = knabbern, byte = beißen)
+CSS (Cascading Style Sheets)-Farben nutzen Hex: #FF0000 = Rot
 -->
 
 ---
@@ -933,7 +1066,12 @@ CSS-Farben nutzen Hex
 Präfixe:
 - 0x = "das ist Hexadezimal" (C, JavaScript, Python)
 - U+ = Unicode-Codepoint (Standard für Zeichenkodierung)
-- # = CSS-Konvention für Farben
+- # = CSS (Cascading Style Sheets)-Konvention für Farben
+
+ABKÜRZUNGEN:
+- MAC = Media Access Control (eindeutige Hardware-Adresse einer Netzwerkkarte)
+- CSS = Cascading Style Sheets
+- Unicode = universeller Zeichensatz für alle Schriftsysteme
 
 Speicheradressen erklärt:
 - 64-Bit-System → Adresse hat 64 Bit = 16 Hex-Ziffern
@@ -1637,8 +1775,6 @@ Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erf
 
 # Fragen & Diskussion
 
-**Nächster Termin:** 10.01.2026 – CSS & Netzwerke
-
 **Kontakt:** lb-czechowski@hdm-stuttgart.de
 
 ---
@@ -1648,7 +1784,7 @@ Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erf
 Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
 
 Basiert auf Material von:
-- Markus Thamm / Wolfgang Gruel (HdM Stuttgart)
 - Michael Czechowski
+- Markus Thamm / Wolfgang Gruel (HdM Stuttgart)
 
 Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/