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

@@ -12,6 +12,7 @@ This project builds presentation decks for Marp, supporting multiple courses.
 - Agent NEVER runs commands outside this folder
 - Agent NEVER runs build/deploy commands without explicit user request
 - Agent NEVER runs deploy commands (make deploy, scp, etc.) without explicit user permission
+- Agent NEVER runs `git checkout --` or `git restore` on files with uncommitted work. To undo specific changes, use targeted Edit operations instead.
 
 ## Critical File Protection
 
@@ -34,8 +35,9 @@ build/                  # Generated output (gitignored)
 ## Build Commands
 
 ```bash
-make dev-b          # Dev server 223015b (port 1311)
-make dev-c          # Dev server 223015c (port 1312)
+make dev            # Marp live server all courses (port 1312, HMR)
+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
@@ -48,10 +50,7 @@ make deploy         # Deploy all (ASK FIRST!)
 ## Nix Flake Commands
 
 ```bash
-nix develop                           # Dev shell with all tools
-nix run .#qr -- "https://example.com" # Generate QR code
-nix run .#qr-slides -- 223015b        # QR for course
-nix run .#optimize-img -- <path>      # Optimize images
+nix develop                           # Dev shell with all tools (node 22, npm, make)
 ```
 
 ## Code Style Guidelines

Makefile

@@ -1,7 +1,7 @@
 # HdM Slides - Unified Makefile
 # Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
 
-.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images klausurfragen build-klausurfragen deploy-klausurfragen
+.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images
 
 # Course configuration
 COURSES = 223015b 223015c
@@ -9,11 +9,11 @@ SLIDES_DIR = slides
 
 # Course-specific settings
 223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
-223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien
+223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien klausurfragen
 223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
 
 223015c_NAME = Internettechnologien
-223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien
+223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
 223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
 
 DEPLOY_HOST = tengo@tuttle.uberspace.de
@@ -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
-	@sleep 0.5
+	@-fuser -k 1312/tcp 2>/dev/null || true
+	@-fuser -k 1313/tcp 2>/dev/null || true
+	@-fuser -k 1314/tcp 2>/dev/null || true
 
 # Build functions
 define build_course
@@ -85,18 +94,7 @@ build-b: build/.exists
 build-c: build/.exists
 	$(call build_course,223015c)
 
-build-klausurfragen: build/.exists
-	@echo "Building klausurfragen..."
-	@mkdir -p build
-	@if [ -f "$(SLIDES_DIR)/klausurfragen.md" ]; then \
-		echo "  Building klausurfragen.md..."; \
-		npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" -o build/klausurfragen.html; \
-		npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" --pdf --allow-local-files -o build/klausurfragen.pdf; \
-	else \
-		echo "  Skipping: $(SLIDES_DIR)/klausurfragen.md not found"; \
-	fi
-
-build: build-b build-c build-klausurfragen
+build: build-b build-c
 	@echo "All courses built!"
 
 # HTML only builds
@@ -210,20 +208,13 @@ deploy-b: build-b
 deploy-c: build-c
 	$(call deploy_course,223015c)
 
-# Deploy klausurfragen (root-level page)
-deploy-klausurfragen: build-klausurfragen
-	@echo "Deploying klausurfragen..."
-	@scp build/klausurfragen.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
-	@scp build/klausurfragen.pdf $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
-	@echo "klausurfragen deployed!"
-
 deploy-index: build-index
 	@echo "Deploying root index..."
 	scp build/index.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/
 	scp build/qr-root.svg $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
 	@echo "Root index deployed!"
 
-deploy: build-index deploy-b deploy-c deploy-klausurfragen deploy-index
+deploy: build-index deploy-b deploy-c deploy-index
 	@echo "All courses deployed!"
 
 # Clean

flake.nix

@@ -1,5 +1,5 @@
 {
-  description = "HdM Slides - Marp presentation builder with tools";
+  description = "HdM Slides - Marp presentation builder";
 
   inputs = {
     nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
@@ -9,116 +9,19 @@
   outputs = { self, nixpkgs, flake-utils }:
     flake-utils.lib.eachDefaultSystem (system:
       let
-        pkgs = import nixpkgs { inherit system; config.allowUnfree = true; };
-
-
-        # QR code generator script
-        qr-gen = pkgs.writeShellScriptBin "qr" ''
-          if [ -z "$1" ]; then
-            echo "Usage: qr <url> [output.png]"
-            echo ""
-            echo "Examples:"
-            echo "  qr https://example.com"
-            echo "  qr https://example.com my-qr.png"
-            echo "  qr 'https://librete.ch/hdm/223015b/' slides-qr.png"
-            exit 1
-          fi
-
-          URL="$1"
-          OUTPUT="''${2:-qr-code.png}"
-
-          ${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "$URL"
-          echo "Generated: $OUTPUT"
-        '';
-
-        # QR code for course slides
-        qr-slides = pkgs.writeShellScriptBin "qr-slides" ''
-          COURSE="''${1:-223015b}"
-          OUTPUT="''${2:-build/$COURSE/qr-$COURSE.png}"
-
-          mkdir -p "$(dirname "$OUTPUT")"
-          ${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "https://librete.ch/hdm/$COURSE/"
-          echo "Generated QR for $COURSE: $OUTPUT"
-        '';
-
-        # Image optimizer script
-        optimize-img = pkgs.writeShellScriptBin "optimize-img" ''
-          if [ -z "$1" ]; then
-            echo "Usage: optimize-img <image-or-directory> [max-width]"
-            echo ""
-            echo "Resizes images to max width (default: 1920px)"
-            exit 1
-          fi
-
-          TARGET="$1"
-          MAX_WIDTH="''${2:-1920}"
-
-          if [ -d "$TARGET" ]; then
-            for img in "$TARGET"/*.{png,jpg,jpeg,webp} 2>/dev/null; do
-              [ -f "$img" ] || continue
-              echo "Optimizing: $(basename "$img")"
-              ${pkgs.imagemagick}/bin/magick "$img" -resize "''${MAX_WIDTH}x>" -quality 85 "$img"
-            done
-          elif [ -f "$TARGET" ]; then
-            echo "Optimizing: $TARGET"
-            ${pkgs.imagemagick}/bin/magick "$TARGET" -resize "''${MAX_WIDTH}x>" -quality 85 "$TARGET"
-          else
-            echo "Error: $TARGET not found"
-            exit 1
-          fi
-          echo "Done!"
-        '';
-
+        pkgs = import nixpkgs { inherit system; };
       in {
-        # Development shell with all tools
         devShells.default = pkgs.mkShell {
           buildInputs = with pkgs; [
-            nodejs_20
+            nodejs_22
             nodePackages.npm
-            qrencode
-            imagemagick
             gnumake
-            claude-code
           ];
 
           shellHook = ''
-            echo "HdM Slides Development Environment"
-            echo ""
-            echo "Available commands:"
-            echo "  make dev-b     - Start 223015b dev server (port 1312)"
-            echo "  make dev-c     - Start 223015c dev server (port 1313)"
-            echo "  make build     - Build all courses"
-            echo "  qr <url>       - Generate QR code"
-            echo "  qr-slides 223015b - Generate QR for course"
-            echo "  optimize-img <dir> - Optimize images"
-            echo ""
+            echo "HdM Slides - run 'make' for available commands"
           '';
         };
-
-        # Standalone apps
-        packages = {
-          qr = qr-gen;
-          qr-slides = qr-slides;
-          optimize-img = optimize-img;
-          default = qr-gen;
-        };
-
-        # Direct runnable apps
-        apps = {
-          qr = {
-            type = "app";
-            program = "${qr-gen}/bin/qr";
-          };
-          qr-slides = {
-            type = "app";
-            program = "${qr-slides}/bin/qr-slides";
-          };
-          optimize-img = {
-            type = "app";
-            program = "${optimize-img}/bin/optimize-img";
-          };
-          default = self.apps.${system}.qr;
-        };
       }
     );
 }

scripts/dev-server.sh

@@ -1,12 +1,16 @@
 #!/usr/bin/env bash
-# Simplified development server for HdM slides
-# Starts single Marp server for all courses
+# Development server for HdM slides
+# 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
-cleanup() {
-    echo -e "\n${RED}Shutting down dev server...${NC}"
-    pkill -f "marp-cli.*--server" 2>/dev/null || true
-    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
+# Kill existing process on our port only
+kill_port() {
+    fuser -k "$DEV_PORT/tcp" 2>/dev/null || true
+    sleep 0.5
 }
 
 # 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}"
-echo ""
-echo -e "  Server:   ${BLUE}http://localhost:$DEV_PORT${NC}"
-echo -e "  Slides:   ${BLUE}$SLIDES_DIR/${NC}"
-echo ""
-echo -e "Available courses:"
-echo -e "  223015b: ${BLUE}http://localhost:$DEV_PORT/223015b/${NC}"
-echo -e "  223015c: ${BLUE}http://localhost:$DEV_PORT/223015c/${NC}"
-echo ""
-echo -e "Press ${RED}Ctrl+C${NC} to stop the server"
+if [ -n "$COURSE" ]; then
+    SERVE_DIR="$SLIDES_DIR/$COURSE"
+    echo -e "${GREEN}Marp dev server${NC} · ${BLUE}$COURSE${NC}"
+else
+    SERVE_DIR="$SLIDES_DIR"
+    echo -e "${GREEN}Marp dev server${NC} · ${BLUE}all courses${NC}"
+fi
+
+echo -e "  ${BLUE}http://localhost:$DEV_PORT${NC}"
+echo -e "  ${BLUE}$SERVE_DIR/${NC}"
 echo ""
 
-# Start single Marp server for all slides
-PORT=$DEV_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/"
-
-# Wait for process to exit
-wait
+PORT=$DEV_PORT exec npx @marp-team/marp-cli --server "$SERVE_DIR/"

scripts/generate-index.sh

@@ -230,7 +230,7 @@ cat > "$BUILD_DIR/index.html" << HEADER
     <h1>HdM Vorlesungen</h1>
     <h2 class="course-heading">$TITLE</h2>
     <p class="subtitle">$SUBTITLE</p>
-    <p class="meta">HdM Stuttgart · Wintersemester 2025/26 · Michael Czechowski</p>
+    <p class="meta">HdM Stuttgart · Sommersemester 2026 · Michael Czechowski</p>
   </header>
   <div class="termine">
 HEADER

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

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -82,173 +82,109 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 
 ---
 
+<!-- _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
-  - Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
+  - Philosophie (Uni Stuttgart)
+  - 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
-Praxisbezug betonen
-Fragen jederzeit willkommen
+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
+
+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?
-2) Wer kennte die 3-2-1 Regel?
-3) Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
-4) Wer hat schon mal mit APIs gearbeitet?
-5) Wer weiß, was UTF-8 bedeutet?
-6) Wer hat schon mal mit einem CLI gearbeitet?
-6) **Wer hat schon mal etwas mit HTML oder CSS gemacht?** (Hex-Farben wie `#FF0000`?)
+1) Wer kennt den Unterschied zwischen analog und digital?
+2) Wer hat schon mal eine Datei von einem Format in ein anderes konvertiert?
+3) Wer hat schon mal Metadaten aus einem Foto entfernt?
+4) Wer kennt die 3-2-1 Backup-Regel?
+5) Wer hat schon mal eine API benutzt?
 
 <!--
 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 | 19.12.2025 | Bits, Bytes, Zeichenkodierung & Audio |
-| 2 | 09.01.2026 | Bild- & Video-Kompression |
-| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
-| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
-| 5 | TBA | Vertiefung & offene Fragen |
+1. Grundlagen, Text & **Audio** (Bits, Bytes, Zeichenkodierung, MP3)
+2. **Bild** & **Video**-Kompression (JPEG, PNG, H.264/H.265)
+3. **Speichermedien** & **Schnittstellen** (HDD, SSD, USB, Thunderbolt)
+4. **Distribution**, **APIs** & Zukunft (Streaming, REST, Cloud)
+5. 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)
-* Schriftliche Klausur
+* 90 min insg. (Technik 1)
+* Schriftliche Klausur (digital)
 * Teils offene Fragen
-* Vermutlich digital
-* Kein Coding!
-* **Prüfungsrelevant:** Alles in den Folien/im Skript
-
-<!--
-Details können sich noch ändern
-Keine Programmieraufgaben
-Verständnisfragen, keine Auswendiglernerei
--->
-
+* Kein Coding/Programmieren
+* **Prüfungsrelevante Folien:**
+  - Gestreift oder Vollton (PDF) markiert

slides/223015b/02-bild-audio-video.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -68,6 +68,38 @@ section.aufgabe {
 section.aufgabe footer {
   display: none;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.erklaerung {
+    background: #e3f2fd !important;
+  }
+}
+section.erklaerung h1 {
+  font-size: 1.5rem;
+  color: #1e5f8a;
+  margin-bottom: 0.3rem;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung table {
+  font-size: 0.9rem;
+}
 </style>
 
 <!-- _class: invert -->
@@ -220,6 +252,26 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Rastergrafik – Vertiefung
+
+Ein Pixel ist die kleinste adressierbare Einheit. Bei 24-Bit-Farbtiefe speichert jeder Pixel drei 8-Bit-Werte (0–255) für Rot, Grün und Blau. Diese additive Farbmischung erzeugt 256³ = 16,7 Millionen mögliche Farbtöne.
+
+**Speicherberechnung:** `Breite × Höhe × Bytes pro Pixel`
+
+| Auflösung | Farbtiefe | Berechnung | Größe |
+|-----------|-----------|------------|-------|
+| 1920×1080 | 24 Bit (3 B) | 2.073.600 × 3 | 6,2 MB |
+| 4K (3840×2160) | 24 Bit | 8.294.400 × 3 | 24,9 MB |
+| 4K | 32 Bit (4 B) | 8.294.400 × 4 | 33,2 MB |
+
+Der Alpha-Kanal (32 Bit) speichert Transparenz als Wert von 0 (unsichtbar) bis 255 (vollständig sichtbar). PNG nutzt dies für weiche Kanten; JPEG unterstützt keinen Alpha-Kanal.
+
+---
+
 # Das Problem der Skalierung
 
 **Vergrößern:**
@@ -274,6 +326,30 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Vektorgrafik – Vertiefung
+
+Vektorgrafiken speichern keine Pixel, sondern mathematische Beschreibungen: Koordinaten, Kurvenparameter (Bézier-Kontrollpunkte), Füllfarben, Strichstärken. Der Renderer berechnet die Pixel erst bei der Ausgabe – daher beliebig skalierbar.
+
+**Bézier-Kurven** (Pierre Bézier, 1962, für Renault-Karosserien entwickelt):
+- Definiert durch Ankerpunkte und Kontrollpunkte
+- Kubische Bézier: 2 Anker + 2 Kontrollpunkte
+- Mathematisch exakt reproduzierbar
+
+| Aspekt | Raster | Vektor |
+|--------|--------|--------|
+| Skalierung 10× | Pixel sichtbar | Perfekt scharf |
+| Foto-Realismus | Gut geeignet | Unpraktikabel |
+| Dateigröße Logo | Wächst mit Auflösung | Konstant (~5 KB) |
+| Editierbarkeit | Destruktiv | Nicht-destruktiv |
+
+**Rasterisierung:** GPU wandelt Vektordaten in Pixel um. Geschieht bei jeder Darstellung neu – deshalb ist ein 4K-Monitor schärfer als ein 1080p-Monitor bei gleichem SVG.
+
+---
+
 # Raster- und Vektorgrafiken
 
 | | Raster | Vektor |
@@ -338,6 +414,28 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Psychovisuelle Wahrnehmung – Vertiefung
+
+Die Netzhaut enthält ~120 Mio. Stäbchen (Helligkeitswahrnehmung) aber nur ~6 Mio. Zapfen (Farbwahrnehmung). Dieses 20:1-Verhältnis erklärt, warum JPEG Farbinformationen stärker reduzieren kann als Helligkeitsinformationen.
+
+**Räumliche Frequenz** beschreibt, wie schnell sich die Helligkeit über eine Bildfläche ändert:
+- **Niedrig:** Himmel, Wand – große einheitliche Flächen
+- **Hoch:** Haare, Texturen, Schrift – schnelle Wechsel
+
+Das Auge ist ein Tiefpassfilter: Hohe Frequenzen (feine Details) werden schwächer wahrgenommen. JPEG verwirft daher zuerst die hohen Frequenzen – der Qualitätsverlust bleibt meist unsichtbar.
+
+| Biologisches Limit | Ausnutzung in JPEG |
+|-------------------|-------------------|
+| Farbauflösung ~20× geringer | Chroma Subsampling (4:2:0) |
+| Hohe Frequenzen unscharf | DCT + Quantisierung |
+| Kontrast-Maskierung | Artefakte in Texturen versteckt |
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
@@ -442,6 +540,34 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Farbraumkonversion – Vertiefung
+
+RGB→YCbCr nutzt die Biologie des menschlichen Auges: 120 Mio. Stäbchen (Helligkeit) vs. nur 6 Mio. Zapfen (Farbe) – ein 20:1-Verhältnis. Die Transformation erfolgt über eine lineare Matrix:
+
+```
+Y  =  0.299·R + 0.587·G + 0.114·B
+Cb = −0.169·R − 0.331·G + 0.500·B + 128
+Cr =  0.500·R − 0.419·G − 0.081·B + 128
+```
+
+Die Gewichtung (G dominiert mit 59%) entspricht der spektralen Empfindlichkeit des Auges bei Tageslicht. Y enthält alle Schärfeinformation; Cb/Cr können reduziert werden.
+
+**Chroma Subsampling – Notation J:a:b** (bezogen auf 4×2 Pixel):
+
+| Schema | Farbdaten | Einsatz |
+|--------|-----------|---------|
+| 4:4:4 | 100% | Postproduktion, Grafik |
+| 4:2:2 | 50% | Broadcast, Pro-Video |
+| 4:2:0 | 25% | JPEG, H.264, Streaming |
+
+Bei 4:2:0 teilen sich 4 Pixel einen Farbwert, behalten aber individuelle Helligkeit → 50% Dateneinsparung bei kaum sichtbarem Unterschied.
+
+---
+
 # JPEG Schritt 2: Chroma Subsampling
 
 **Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block):
@@ -623,12 +749,36 @@ KLAUSURRELEVANT:
 - Präfix-frei: Kein Code ist Anfang eines anderen
 - Häufigstes Zeichen = kürzester Code
 - Auch in ZIP, PNG, MP3 verwendet
+-->
 
 ---
 
--->
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
 
+# Huffman-Coding – Vertiefung
 
+David Huffman entwickelte 1952 als Student am MIT einen optimalen Algorithmus für präfixfreie Codes – ursprünglich als Hausaufgabe, die zur Veröffentlichung führte.
+
+**Algorithmus (Bottom-Up-Baumkonstruktion):**
+1. Alle Symbole nach Häufigkeit sortieren
+2. Die zwei seltensten Symbole zu einem Knoten kombinieren
+3. Wiederholen bis nur noch die Wurzel übrig ist
+4. Codes ablesen: links = 0, rechts = 1
+
+**Präfixfreiheit:** Kein Code ist Anfang eines anderen → sofort dekodierbar ohne Trennzeichen.
+
+| Eigenschaft | Huffman | Arithmetisch |
+|-------------|---------|--------------|
+| Einheit | Ganze Bits | Fraktionale Bits |
+| Optimalität | Optimal für ganze Bits | Näher an Entropie |
+| Geschwindigkeit | Schneller | Langsamer |
+| JPEG-Einsatz | Standard (Baseline) | Optional (selten) |
+
+JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittswerte), eine für AC-Koeffizienten (Frequenzen). Die Tabellen sind im JPEG-Header gespeichert.
+
+---
 
 <!-- _class: klausur -->
 <!-- _header: '' -->
@@ -772,6 +922,28 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# WebP & AVIF – Vertiefung
+
+**WebP** entstand 2010 aus Googles VP8-Videocodec (On2 Technologies, für $133M gekauft). Statt I-Frames für Video werden sie als Einzelbilder verwendet. WebP nutzt Intra-Frame-Prediction, die benachbarte Blöcke zur Vorhersage verwendet – effizienter als JPEGs blockweise DCT.
+
+**AVIF** basiert auf dem AV1-Videocodec, entwickelt 2015–2018 von der Alliance for Open Media (Google, Apple, Netflix, Amazon, Microsoft, Mozilla). Nach dem Patent-Chaos von H.265/HEVC vereinten sich die Konkurrenten für einen lizenzfreien Standard.
+
+| Aspekt | WebP | AVIF |
+|--------|------|------|
+| Basis-Codec | VP8/VP9 | AV1 |
+| Kompression vs. JPEG | 25–35% besser | 50% besser |
+| HDR/Wide Gamut | Nein | Ja (10/12 Bit) |
+| Encoding-Geschwindigkeit | Schnell | Sehr langsam |
+| Browser-Support 2025 | 97%+ | 93%+ |
+
+**Warum JPEG dominiert:** Kameras, Bildbearbeitungssoftware und Content-Management-Systeme sind auf JPEG optimiert. Der Wechsel erfordert Infrastruktur-Updates über die gesamte Pipeline.
+
+---
+
 # Formatwahl in der Praxis
 
 | Anwendung | Format |
@@ -890,6 +1062,33 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Container vs. Codec – Vertiefung
+
+**Container** (Multiplexer-Format) organisiert mehrere Datenströme mit Timing-Informationen. Er enthält keine Kompressionslogik, sondern synchronisiert Video, Audio, Untertitel und Metadaten.
+
+**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.
+
+| Container | Entwickler | Typische Codecs | Besonderheit |
+|-----------|------------|-----------------|--------------|
+| MP4 | ISO/MPEG | H.264, H.265, AAC | Web-Standard, DRM-fähig |
+| MKV | Matroska | Alle | Beliebig viele Streams, Kapitel |
+| WebM | Google | VP9, AV1, Opus | HTML5-optimiert, lizenzfrei |
+| MOV | Apple | ProRes, H.264 | Professionelle Produktion |
+
+**Metadaten im Container:**
+- Timecodes für Frame-genaue Synchronisation
+- Kapitelmarken, Thumbnails
+- Sprach-Tags für Audio/Untertitel
+- HDR-Metadaten (MaxCLL, MaxFALL)
+
+**Praktisches Problem:** Eine `.mp4`-Datei mit AV1-Codec spielt auf älteren Geräten nicht ab, obwohl sie MP4 „unterstützen" – der Hardware-Decoder fehlt für AV1.
+
+---
+
 # Gängige Container
 
 | Container | Verwendung |
@@ -1115,6 +1314,32 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# H.264/AVC – Vertiefung
+
+H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-ray. Vor H.264 war MPEG-2 Standard – H.264 erreichte bei gleicher Qualität die halbe Bitrate.
+
+**Technische Innovationen:**
+- **Variable Blockgrößen:** 16×16 bis 4×4 Macroblocks (MPEG-2: nur 16×16)
+- **Intra-Prediction:** Blöcke werden aus Nachbarn vorhergesagt
+- **In-Loop Deblocking:** Filter reduziert Blockartefakte vor der Referenzierung
+- **CABAC:** Arithmetic Coding ersetzt Huffman (10–15% effizienter)
+
+| Profile | Anwendung | Max. Auflösung |
+|---------|-----------|----------------|
+| Baseline | Videotelefonie, ältere Geräte | 480p |
+| Main | Broadcast, Streaming | 1080p |
+| High | Blu-ray, professionell | 4K |
+
+**Hardware-Ubiquität:** Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie.
+
+**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzer-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.
+
+---
+
 # Das Patent-Problem
 
 **H.264 ist nicht frei**
@@ -1221,6 +1446,29 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# AV1 – Vertiefung
+
+Die **Alliance for Open Media** (2015) vereinte Konkurrenten nach dem Patent-Chaos von H.265/HEVC. Drei separate Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) machten H.265-Lizenzierung unberechenbar – die Industrie wollte einen garantiert lizenzfreien Standard.
+
+**Gründungsmitglieder:** Google, Mozilla, Cisco, Netflix, Amazon, Microsoft. Apple trat 2018 bei – historisch, da Apple sonst eigene Standards bevorzugt.
+
+| Technische Innovation | Beschreibung |
+|----------------------|--------------|
+| Superblocks | Bis 128×128 Pixel (H.264: max 16×16) |
+| Prediction Modes | 56 Intra-Modi (H.264: 9) |
+| Transform | 10 verschiedene Transformtypen |
+| Film Grain Synthesis | Filmkorn wird als Parameter übertragen |
+
+**Encoding-Performance:** Software-Encoding ist 50–200× langsamer als H.264. Erst Hardware-Encoder (Intel ab Gen 12, NVIDIA RTX 40, Apple M3) machen Echtzeit-Encoding praktikabel.
+
+**Adoption 2025:** YouTube und Netflix nutzen AV1 für 4K/8K-Streams. 2024 gewann AV1 einen Emmy für technische Innovation – offene Standards können Industriestandard werden.
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->
 

slides/223015b/03-speichermedien-schnittstellen.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -68,6 +68,38 @@ section.aufgabe {
 section.aufgabe footer {
   display: none;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.erklaerung {
+    background: #e3f2fd !important;
+  }
+}
+section.erklaerung h1 {
+  font-size: 1.5rem;
+  color: #1e5f8a;
+  margin-bottom: 0.3rem;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung table {
+  font-size: 0.9rem;
+}
 </style>
 
 <!-- _class: invert -->
@@ -82,7 +114,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 
@@ -235,6 +267,29 @@ Kleine SSD für System + große HDD für Archiv.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HDD vs. SSD – Vertiefung
+
+**HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor).
+
+**SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles).
+
+| Aspekt | HDD | SATA SSD | NVMe SSD |
+|--------|-----|----------|----------|
+| Latenz | 5–10 ms | 0,1 ms | 0,02 ms |
+| Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s |
+| IOPS (4K random) | 100 | 90.000 | 1.000.000 |
+| TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW |
+
+**Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke.
+
+**Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden.
+
+---
+
 <!-- _class: lead -->
 
 # Dateisysteme
@@ -484,6 +539,30 @@ Warum 1 Offsite?
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# 3-2-1-Backup-Regel – Vertiefung
+
+Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien:
+
+| Bedrohung | Schutz durch | Beispiel |
+|-----------|--------------|----------|
+| Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden |
+| Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System |
+| Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher |
+
+**Moderne Erweiterung 3-2-1-1-0:**
+- **+1** Air-Gapped (offline, nicht verbunden)
+- **+0** Verifizierte Backups (regelmäßig Restore testen)
+
+**Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind.
+
+**Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots.
+
+---
+
 # Backup-Arten
 
 **Vollständig (Full):**

slides/223015b/04-distribution-apis-zukunft.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -83,7 +83,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 

slides/223015b/05-vertiefung-offene-fragen.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -83,7 +83,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 

slides/223015b/klausurfolien.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 <style>
@@ -92,7 +92,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 
@@ -102,6 +102,166 @@ Hochschule der Medien Stuttgart
 <!-- _footer: "" -->
 
 
+# Verlustfrei vs. Verlustbehaftet
+
+| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
+|---|---|---|
+| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
+| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
+| **Reduktion** | 30-50% | 80-99% |
+| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
+
+**Faustregel:**
+- Medien für EndnutzerInnen → Lossy oft akzeptabel
+- Quellmaterial, Code, Archive → Lossless nötig
+
+<!--
+REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
+IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
+
+KLAUSURRELEVANT:
+- Verlustfrei = Original 1:1 wiederherstellbar
+- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
+- Redundanz vs. Irrelevanz ist der Kernunterschied!
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Dateneinheiten
+
+| Einheit | Bytes | Potenz | Beispiel |
+|---------|------:|:------:|----------|
+| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
+| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
+| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
+| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
+| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
+| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
+| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
+| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
+
+<!--
+SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
+Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
+Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
+1 TB Festplatte = ~931 GiB nutzbar
+
+Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
+→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Der digitale Wendepunkt
+
+| Jahr | Analog | Digital | Digital-Anteil |
+|------|--------|---------|----------------|
+| **1986** | 2,6 EB | 0,02 EB | **1%** |
+| **2002** | — | — | **50%** (Wendepunkt) |
+| **2007** | 18 EB | 277 EB | **94%** |
+
+**Perspektive:**
+- 1986: "Petabyte" war ein theoretisches Konzept
+- 2025: ~181 Zettabyte jährlich produziert
+
+**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
+(AWS Glacier, Film-Archive, Rechenzentren)
+
+<!--
+PRÜFUNGSRELEVANT:
+ - Wendepunkt 2002
+ - Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
+ - Magnetband als Archivmedium
+
+QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
+
+METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
+
+WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
+
+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
+
+VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
+
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Analoge Medien
+### Distribution: physisch (Kauf, Verleih, Kopie)
+
+- **Text**
+    - Bücher, Zeitungen, Zeitschriften, Lochkarten
+- **Bild**
+    - Fotografie (Negativ, Dia, Polaroid), Mikrofilm
+- **Audio:**
+    - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
+- **Video:**
+    - Film (35mm, Super 8), VHS, Betamax
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Digitale Medien
+### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
+
+- **Text**
+    - E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
+- **Bild**
+    - Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
+- **Audio**
+    - Audiodatei (MP3, FLAC, WAV, AAC, OGG)
+- **Video**
+    - Videodatei (MP4, MKV, AVI, WebM)
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Digitale Speichermedien
+
+- **Optische Speicher**
+    - CD, DVD, Blu-ray
+- **Magnetische Speicher**
+    - Festplatte (HDD), Magnetband (LTO)
+- **Flash-Speicher**
+    - SSD, USB-Stick, SD-Karte
+- **Cloud-Speicher**
+    - Dropbox, Google Drive, iCloud, AWS S3
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
 # Rastergrafiken
 
 **Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
@@ -243,6 +403,7 @@ KLAUSURRELEVANT:
 - Präfix-frei: Kein Code ist Anfang eines anderen
 - Häufigstes Zeichen = kürzester Code
 - Auch in ZIP, PNG, MP3 verwendet
+-->
 
 
 ---

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/02-netzwerke-protokolle-css.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Grundlagen IT- und Internettechnik (223015c)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: "Kapitel 2: Netzwerke, Protokolle & CSS"
 ---
 
@@ -71,6 +71,38 @@ section.aufgabe footer {
 section.glossar {
   font-size: 1.4rem;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: repeating-linear-gradient(
+    135deg,
+    #fce4ec,
+    #fce4ec 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.erklaerung {
+    background: #fce4ec !important;
+  }
+}
+section.erklaerung h1 {
+  font-size: 1.5rem;
+  color: #a02060;
+  margin-bottom: 0.3rem;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung table {
+  font-size: 0.9rem;
+}
 </style>
 
 <!-- _class: invert -->
@@ -86,7 +118,7 @@ section.glossar {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
 
@@ -402,6 +434,31 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# TCP/IP-Modell – Vertiefung
+
+Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt.
+
+**Schicht-Aufgaben im Detail:**
+
+| Schicht | Frage | Protokolle | Geräte |
+|---------|-------|------------|--------|
+| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) |
+| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) |
+| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router |
+| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point |
+
+**OSI vs. TCP/IP:**
+- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4
+- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1
+
+**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht.
+
+---
+
 # Schichten verpacken Daten
 
 ```
@@ -461,6 +518,33 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Dateneinheiten & Encapsulation – Vertiefung
+
+**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
+
+**Was jeder Header enthält:**
+
+| Schicht | Einheit | Header-Inhalte |
+|---------|---------|----------------|
+| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
+| Transport | Segment | Quell-/Zielport, Sequenznummer, Flags (SYN, ACK) |
+| Internet | Paket | Quell-/Ziel-IP, TTL, Protokoll (TCP=6, UDP=17) |
+| Netzzugang | Frame | Quell-/Ziel-MAC, EtherType, CRC-Prüfsumme |
+
+**Overhead-Rechnung (1 Byte HTTP-Body):**
+- Ethernet: 14 + 4 Bytes (Header + Trailer)
+- IP: 20 Bytes (ohne Optionen)
+- TCP: 20 Bytes (ohne Optionen)
+- **Minimum: 58 Bytes für 1 Byte Nutzlast**
+
+**Decapsulation:** Empfänger packt in umgekehrter Reihenfolge aus. Jede Schicht prüft ihren Header (z.B. CRC) und reicht Nutzdaten nach oben.
+
+---
+
 # Warum ist das clever?
 
 **Ohne Schichten:**
@@ -640,6 +724,34 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# IP, MAC, Port – Vertiefung
+
+Drei Adressebenen lösen drei verschiedene Probleme:
+
+**IP-Adresse (Schicht 2 – Internet):**
+- Hierarchisch aufgebaut: Netzwerk-Teil + Host-Teil
+- Router lesen nur den Netzwerk-Teil für Routing-Entscheidungen
+- IPv4: 32 Bit (z.B. 192.168.1.1), IPv6: 128 Bit
+
+**MAC-Adresse (Schicht 1 – Netzzugang):**
+- 48 Bit, vom Hersteller fest vergeben (theoretisch)
+- Erste 24 Bit = OUI (Organizationally Unique Identifier) = Hersteller
+- Nur relevant für den **nächsten Hop** – wird bei jedem Router ersetzt
+- ARP (Address Resolution Protocol) übersetzt IP → MAC
+
+**Port (Schicht 3 – Transport):**
+- 16 Bit → 65.535 mögliche Ports
+- Well-Known Ports (0–1023): HTTP=80, HTTPS=443, SSH=22
+- Ephemeral Ports (49152–65535): Dynamisch für Client-Verbindungen
+
+**Warum ändert sich nur MAC?** IP ist das Endziel (Brief-Adresse), MAC ist der aktuelle Bote (wer trägt den Brief gerade?).
+
+---
+
 <!-- _class: lead -->
 
 # Die Reise eines Klicks
@@ -922,6 +1034,36 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# 3-Way-Handshake – Vertiefung
+
+Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit.
+
+**Warum zufällige Startwerte (ISN)?**
+- Sicherheit: Verhindert Session-Hijacking durch Raten
+- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen
+- ISN = Initial Sequence Number, vom OS zufällig gewählt
+
+**TCP-Flags im Handshake:**
+
+| Paket | Flags | Bedeutung |
+|-------|-------|-----------|
+| 1 | SYN | Client will Verbindung, sendet seine ISN |
+| 2 | SYN+ACK | Server akzeptiert, sendet seine ISN, bestätigt Client-ISN+1 |
+| 3 | ACK | Client bestätigt Server-ISN+1 |
+
+**Was passiert bei Problemen?**
+- Kein SYN-ACK → Client wiederholt SYN (Timeout)
+- SYN-Flood-Attacke: Millionen SYNs ohne ACK → Server-Ressourcen erschöpft
+- Schutz: SYN-Cookies (Server speichert keinen State bis ACK kommt)
+
+**Verbindungsabbau:** 4-Way-Handshake (FIN → ACK → FIN → ACK) oder RST für sofortigen Abbruch.
+
+---
+
 # Nach dem Handshake
 
 **Status:** Die TCP-Verbindung steht.
@@ -1429,6 +1571,38 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# TCP vs. UDP – Vertiefung
+
+Beide sind Transport-Protokolle (Schicht 3), aber mit fundamental unterschiedlichen Garantien.
+
+**TCP (Transmission Control Protocol):**
+- Verbindungsorientiert (Handshake vor Daten)
+- Sequenznummern → Reihenfolge garantiert
+- ACKs + Retransmission → Kein Datenverlust
+- Flow Control (Sliding Window) → Empfänger nicht überlasten
+- Congestion Control → Netzwerk nicht überlasten
+
+**UDP (User Datagram Protocol):**
+- Verbindungslos (Fire-and-Forget)
+- Keine Sequenznummern, keine ACKs
+- Header nur 8 Bytes (TCP: 20+ Bytes)
+- Anwendung muss selbst für Zuverlässigkeit sorgen
+
+| Anwendung | Protokoll | Grund |
+|-----------|-----------|-------|
+| HTTP/HTTPS | TCP | Vollständigkeit kritisch |
+| DNS | UDP | Kleine Pakete, schnelle Antwort |
+| Video-Streaming | UDP/QUIC | Latenz wichtiger als Perfektion |
+| Online-Gaming | UDP | Echtzeit, veraltete Daten nutzlos |
+
+**QUIC:** Googles Protokoll kombiniert UDP-Geschwindigkeit mit TCP-ähnlicher Zuverlässigkeit (HTTP/3).
+
+---
+
 # Warum UDP bei Video-Calls?
 
 **Szenario:** Ein Paket geht verloren.
@@ -1508,6 +1682,37 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HTTP-Methoden – Vertiefung
+
+HTTP-Methoden definieren die **Semantik** der Anfrage – was der Client vom Server erwartet.
+
+**CRUD-Mapping (Create, Read, Update, Delete):**
+
+| Methode | CRUD | Idempotent | Safe | Typischer Einsatz |
+|---------|------|------------|------|-------------------|
+| GET | Read | Ja | Ja | Ressource abrufen |
+| POST | Create | Nein | Nein | Formular, neue Ressource |
+| PUT | Update | Ja | Nein | Ressource vollständig ersetzen |
+| PATCH | Update | Nein | Nein | Ressource teilweise ändern |
+| DELETE | Delete | Ja | Nein | Ressource löschen |
+
+**Idempotent:** Mehrfaches Ausführen hat denselben Effekt wie einmaliges (GET, PUT, DELETE).
+**Safe:** Ändert nichts am Server (nur GET, HEAD, OPTIONS).
+
+**REST-Prinzip:** URLs identifizieren Ressourcen, Methoden definieren Aktionen.
+```
+GET /users/42        → Benutzer 42 abrufen
+PUT /users/42        → Benutzer 42 vollständig ersetzen
+DELETE /users/42     → Benutzer 42 löschen
+POST /users          → Neuen Benutzer erstellen
+```
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -1543,6 +1748,31 @@ Status-Codes sagen euch, was passiert ist.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HTTP Status-Codes – Vertiefung
+
+Die erste Ziffer kategorisiert die Antwort:
+
+| Bereich | Kategorie | Häufige Codes |
+|---------|-----------|---------------|
+| 1xx | Informational | 100 Continue, 101 Switching Protocols |
+| 2xx | Success | 200 OK, 201 Created, 204 No Content |
+| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
+| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
+| 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
+
+**Wichtige Unterscheidungen:**
+- **401 vs. 403:** 401 = nicht authentifiziert (wer bist du?), 403 = nicht autorisiert (du darfst nicht)
+- **301 vs. 302:** 301 = permanent umgezogen (Cache-fähig), 302 = temporär (nicht cachen)
+- **304 Not Modified:** Browser hat Cache, Server bestätigt: noch aktuell → spart Bandbreite
+
+**API-Design:** Korrekte Status-Codes sind wichtig für Clients. `200` bei Fehler mit `{"error": "..."}` im Body ist schlechtes Design.
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -1579,6 +1809,40 @@ Wie Encapsulation funktioniert.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Netzwerk-Grundlagen – Vertiefung
+
+Die vier Kernkonzepte für Web-Entwickler:
+
+**1. DNS-Auflösung:**
+- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
+- Rekursive Abfrage: Root → TLD → Authoritative
+- Caching auf jeder Ebene (TTL = Time To Live)
+
+**2. TCP-Verbindungsaufbau:**
+- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
+- Keep-Alive: Verbindung bleibt offen für mehrere Requests
+- HTTP/2: Multiplexing – viele Requests über eine Verbindung
+
+**3. HTTP Request/Response:**
+```
+Request:  Methode + URL + Header + (Body)
+Response: Status + Header + Body
+```
+
+**4. Schichten & Adressen:**
+| Was bleibt gleich? | Was ändert sich? |
+|-------------------|------------------|
+| Ziel-IP | MAC-Adressen (bei jedem Hop) |
+| Ports | – |
+
+**Debugging:** Browser DevTools (F12 → Network) zeigt alle Requests, Timing, Header.
+
+---
+
 # Werkzeuge zum Selbst-Erkunden
 
 **Im Browser (F12 → Network-Tab):**
@@ -1870,6 +2134,33 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# CSS Spezifität – Vertiefung
+
+Spezifität bestimmt, welche CSS-Regel gewinnt, wenn mehrere auf dasselbe Element zutreffen. Sie wird als 4-stellige Zahl berechnet: **(Inline, IDs, Klassen, Elemente)**.
+
+**Berechnung:**
+
+| Selektor | Inline | IDs | Klassen | Elemente | Gesamt |
+|----------|--------|-----|---------|----------|--------|
+| `p` | 0 | 0 | 0 | 1 | 0,0,0,1 |
+| `.info` | 0 | 0 | 1 | 0 | 0,0,1,0 |
+| `p.info` | 0 | 0 | 1 | 1 | 0,0,1,1 |
+| `#header` | 0 | 1 | 0 | 0 | 0,1,0,0 |
+| `#header .nav a` | 0 | 1 | 1 | 1 | 0,1,1,1 |
+
+**Wichtige Regeln:**
+- Eine Klasse (0,0,1,0) schlägt **jede Anzahl** von Elementen (0,0,0,99)
+- Eine ID schlägt jede Anzahl von Klassen
+- `!important` bricht alles → vermeiden, da schwer zu überschreiben
+
+**Best Practice:** Flache Spezifität anstreben. BEM-Methodik (`.block__element--modifier`) hält Spezifität gleichmäßig niedrig.
+
+---
+
 # Box-Modell
 
 ```
@@ -2117,6 +2408,37 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Responsive Design – Vertiefung
+
+**Mobile First** ist der Standard: Basis-CSS für kleine Screens, dann Erweiterungen für größere.
+
+**Breakpoints (gängige Werte):**
+
+| Breakpoint | Gerät | Media Query |
+|------------|-------|-------------|
+| < 576px | Smartphone (Portrait) | Basis (kein Query) |
+| ≥ 576px | Smartphone (Landscape) | `@media (min-width: 576px)` |
+| ≥ 768px | Tablet | `@media (min-width: 768px)` |
+| ≥ 992px | Desktop | `@media (min-width: 992px)` |
+| ≥ 1200px | Large Desktop | `@media (min-width: 1200px)` |
+
+**Viewport-Meta-Tag (kritisch!):**
+```html
+<meta name="viewport" content="width=device-width, initial-scale=1">
+```
+Ohne diesen Tag ignorieren mobile Browser eure Media Queries und rendern die Desktop-Version verkleinert.
+
+**Moderne Alternativen zu Media Queries:**
+- `clamp()`: `font-size: clamp(1rem, 2vw, 2rem);`
+- Container Queries: Reagieren auf Container-Größe statt Viewport
+- CSS Grid `auto-fit`/`auto-fill`: Automatisches Responsive Layout
+
+---
+
 # Zusammenfassung CSS
 
 **Selektoren:**

slides/223015c/03-interaktivitaet-javascript.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Grundlagen IT- und Internettechnik (223015c)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: "Kapitel 3: Interaktivität & JavaScript"
 ---
 
@@ -83,7 +83,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
 

slides/223015c/klausurfolien.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Grundlagen IT- und Internettechnik (223015c)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: "Kapitel 1: Geschichte, Grundlagen & HTML"
 ---
 <style>
@@ -93,7 +93,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)