add essay questions across all blocks in 223015c

- A4: von-neumann komponenten (disabled)
- B7a: IP/MAC/Port vergleichen
- B13a: TCP vs UDP vergleichen
- C9a: status codes 2xx/4xx/5xx erklären
- C9b: HTTP-methoden vergleichen (disabled)
- D5: encapsulation erklären (disabled)
- E3: gesamtablauf DNS/TCP/HTTP
- H2a: einschränkungstypen erklären

AGENTS.md

@@ -0,0 +1,197 @@
+# AGENTS.md - Agent Guidelines for HdM Slides
+
+This file contains comprehensive guidelines for agentic coding agents working on the HdM Slides project.
+
+## Project Overview
+
+This project builds presentation decks for Marp, supporting multiple courses:
+- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
+- **223015c** - Internettechnologien (3 Kapitel)
+
+## Development Workflow
+
+### Build Commands
+```bash
+# Development
+make dev              # Start single dev server on port 3000
+npm run dev           # Alternative command for development server
+
+# Build
+make build            # Build all courses (HTML + PDF)
+make build-b          # Build 223015b only
+make build-c          # Build 223015c only
+make html             # HTML only builds
+make pdf              # PDF only builds
+
+# Klausur Folien
+make klausur          # Extract klausurfolien for all courses
+make klausur-b        # Extract klausurfolien for 223015b
+make klausur-c        # Extract klausurfolien for 223015c
+
+# Deployment
+make deploy            # Deploy all courses (requires explicit permission)
+make deploy-b         # Deploy 223015b only
+make deploy-c         # Deploy 223015c only
+
+# Utilities
+make qr URL=...       # Generate QR code
+make optimize-images COURSE=223015b  # Resize images
+make clean            # Remove generated files
+```
+
+### Testing
+No specific test framework is used. To validate changes:
+1. Start dev server: `make dev`
+2. Open http://localhost:3000/223015b/ or /223015c/
+3. Verify slides render correctly
+4. Run `make build` to ensure no build errors
+5. Check generated files in `build/` directory
+
+## Code Style Guidelines
+
+### File Structure
+- Slides in `slides/<course>/` following naming pattern `NN-topic.md`
+- Assets in `slides/<course>/assets/`
+- Always reference images as `./assets/filename.png`
+- Scripts in `scripts/`
+- Themes in `themes/`
+- Generated output in `build/` (gitignored)
+
+### Naming Conventions
+- Slide files: `NN-topic.md` (e.g., `01-grundlagen.md`, `02-bilder.md`)
+- Images: `snake_case.jpg` or `kebab-case.jpg`
+- Klausur files: `klausurfolien.md` (auto-generated)
+- Function names in scripts: `snake_case`
+- Variable names in scripts: `snake_case`
+
+### Markdown Style
+- Use ATX-style headers (`# ## ###`)
+- YAML frontmatter for slide metadata at top of each file
+- Never include a final `---` (creates empty slide)
+- Use `<!-- _class: klausur -->` for exam-relevant slides
+- Use relative paths for assets: `./assets/image.png`
+
+### Script Style
+- Use `#!/usr/bin/env bash` shebang
+- Use `set -e` for error handling
+- Use `2>/dev/null || true` for optional operations
+- Define variables in UPPER_CASE at script top
+- Use colors for terminal output: `\033[0;32m` etc.
+
+### Git Workflow
+- Commit messages: ALWAYS lowercase
+- NEVER add co-authoring lines or generated footers
+- Follow semantic naming: "add-...", "fix-...", "update-..."
+- Commit changes to scripts, Makefile, documentation separately from slide content
+
+## Agent Restrictions
+
+### Security
+- NEVER run commands outside `/home/mwc/Coding/hdm` folder
+- NEVER run build/deploy commands without explicit user request
+- NEVER run deploy commands (make deploy, scp, etc.) without explicit permission
+
+### File Protection
+Slide files in `slides/*/*.md` are main content files:
+- **ALLOWED**: Adding slides, adjusting content, fixing typos, enhancing sections
+- **FORBIDDEN** (without permission): Deleting slides, removing sections, bulk deletions
+- Before ANY deletion: ALWAYS ask user for confirmation
+
+### Klausur Handling
+- Klausur files (`klausurfolien.md`) are auto-generated
+- NEVER edit klausurfolien.md files directly
+- To update klausurfolien: edit source slides with `<!-- _class: klausur -->` markers
+- Run `make klausur` to regenerate
+
+## Development Patterns
+
+### Adding New Slides
+1. Create new file following `NN-topic.md` pattern
+2. Copy frontmatter from existing slides in the same course
+3. Update Makefile `_KAPITEL` variable if needed
+4. Test with `make dev`
+
+### Modifying Existing Slides
+1. Edit the appropriate markdown file in `slides/<course>/`
+2. Maintain consistent styling with course theme
+3. Preserve image paths as `./assets/...`
+4. Test changes with dev server
+
+### Working with Assets
+1. Place images in `slides/<course>/assets/`
+2. Use descriptive names: `diagram-network.jpg`, `example-code.png`
+3. Optimize with `make optimize-images COURSE=223015b`
+4. Reference as `./assets/filename.ext`
+
+### Course-Specific Configuration
+Each course has specific settings in Makefile:
+- Course name and title
+- Kapitel list (slide files)
+- Deploy path
+- Theme colors (in generate-index.sh)
+
+## Common Tasks
+
+### Debugging Build Issues
+1. Check Makefile syntax: `make -n build`
+2. Verify Marp CLI installation: `npx @marp-team/marp-cli --version`
+3. Check file permissions: `ls -la slides/`
+4. Validate markdown syntax with dev server
+
+### Updating Course Structure
+1. Update `_KAPITEL` variables in Makefile
+2. Ensure slide files follow naming convention
+3. Update course-specific themes if needed
+4. Test both dev and build processes
+
+### Working with Themes
+- Custom theme in `themes/custom-theme.css`
+- Course themes defined in individual slide frontmatter
+- Use consistent color schemes per course
+- Test theme changes across all slides
+
+## Deployment Process
+
+Deployment to production server requires explicit permission:
+1. Build process: `make build` (HTML + PDF)
+2. Index generation: automatically handled
+3. Deploy to remote server via SCP
+4. Root index deployment
+
+**IMPORTANT**: Never run deployment commands without explicit user permission.
+
+## Tools and Dependencies
+
+### Core Dependencies
+- Marp CLI for slide rendering
+- Bash scripts for automation
+- Make for build orchestration
+- Git for version control
+
+### Optional Tools
+- qrencode for QR generation (via nix)
+- ImageMagick for image optimization
+- Python 3 for simple HTTP server (legacy)
+
+## Testing Strategy
+
+Since there's no formal test suite:
+1. Manual testing with dev server
+2. Build process validation
+3. Slide rendering checks
+4. Asset path verification
+5. Cross-browser compatibility checks (important)
+
+## Troubleshooting
+
+### Common Issues
+- **Port conflicts**: Use `make dev-kill` to clean up processes
+- **Build failures**: Check file permissions and Marp CLI installation
+- **Asset loading**: Verify relative paths and file existence
+- **Deploy issues**: Check SSH keys and remote permissions
+
+### Getting Help
+1. Check this AGENTS.md file first
+2. Review Makefile targets and scripts
+3. Test changes incrementally
+4. Maintain backup of working configurations

Makefile

@@ -7,19 +7,13 @@
 COURSES = 223015b 223015c
 SLIDES_DIR = slides
 
-# Port configuration (index starts at BASE_PORT, courses increment from there)
-BASE_PORT = 1310
-INDEX_PORT = $(BASE_PORT)
-
 # Course-specific settings
 223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
-223015b_PORT = 1311
+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_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausur
 223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
 
 223015c_NAME = Internettechnologien
-223015c_PORT = 1312
+223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
-223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausur
 223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
 
 DEPLOY_HOST = tengo@tuttle.uberspace.de
@@ -33,9 +27,7 @@ help:
 	@echo "  223015c - Internettechnologien"
 	@echo ""
 	@echo "Development:"
-	@echo "  make dev         - Both servers + index (ports 1311, 1312, 1313)"
+	@echo "  make dev         - Start development server (port 3000)"
-	@echo "  make dev-b       - Dev server for 223015b (port 1312)"
-	@echo "  make dev-c       - Dev server for 223015c (port 1313)"
 	@echo ""
 	@echo "Build:"
 	@echo "  make build       - Build all courses"
@@ -43,7 +35,7 @@ help:
 	@echo "  make build-c     - Build 223015c only"
 	@echo "  make pdf         - Export all to PDF"
 	@echo "  make html        - Export all to HTML"
-	@echo "  make klausur     - Extract klausur slides"
+	@echo "  make klausur     - Extract klausurfolien slides"
 	@echo ""
 	@echo "Tools:"
 	@echo "  make qr URL=...  - Generate QR code for URL"
@@ -63,25 +55,14 @@ build/.exists:
 	@mkdir -p build/223015b build/223015c
 	@touch $@
 
-# Development servers
+# Development server
 dev:
 	@./scripts/dev-server.sh
 
 dev-kill:
-	@-pkill -f "python3 -m http.server" 2>/dev/null || true
 	@-pkill -f "marp-cli.*--server" 2>/dev/null || true
 	@sleep 0.5
 
-dev-b:
-	@echo "Starting 223015b dev server on port $(223015b_PORT)..."
-	@echo "Open: http://localhost:$(223015b_PORT)"
-	PORT=$(223015b_PORT) npx @marp-team/marp-cli --server $(SLIDES_DIR)/223015b/
-
-dev-c:
-	@echo "Starting 223015c dev server on port $(223015c_PORT)..."
-	@echo "Open: http://localhost:$(223015c_PORT)"
-	PORT=$(223015c_PORT) npx @marp-team/marp-cli --server $(SLIDES_DIR)/223015c/
-
 # Build functions
 define build_course
 	@echo "Building $(1)..."
@@ -158,7 +139,7 @@ klausur-c:
 	@./scripts/extract-klausur.sh 223015c
 
 klausur: klausur-b klausur-c
-	@echo "Klausur slides extracted for all courses!"
+	@echo "Klausurfolien slides extracted for all courses!"
 
 # QR Code generation (uses nix-shell)
 qr:
@@ -198,7 +179,8 @@ HDM_DEPLOY_PATH = /home/tengo/html/hdm
 
 build-index: build/.exists
 	@echo "Building root index..."
-	@echo '<!DOCTYPE html><html lang="de"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width,initial-scale=1"><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:.5rem}.subtitle{color:#86868b;font-size:1rem}.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.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:.25rem 0}.course-info{font-size:.85rem;color:#86868b}.section-title{font-size:1rem;font-weight:600;color:#86868b;margin-top:2.5rem;margin-bottom:.75rem}.references{display:flex;flex-direction:column;gap:.75rem}footer{margin-top:2.5rem;padding-top:1.5rem;border-top:1px solid #e5e5e7;color:#86868b;font-size:.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:.75rem;font-size:.85rem;color:#86868b}</style></head><body><h1>HdM Vorlesungen</h1><p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p><div class="courses"><a class="course course-b" href="223015b/"><span class="course-label">223015b</span><div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class="course-info">6 Kapitel · Modul "Technik 1"</span></a><a class="course course-c" href="223015c/"><span class="course-label">223015c</span><div class="course-title">Grundlagen IT- und Internettechnik</div><span class="course-info">3 Kapitel · Modul "Technik 1"</span></a></div><h2 class="section-title">Referenzen</h2><div class="references"><a class="course" href="https://codecrispi.es/"><span class="course-label">Plattform</span><div class="course-title">Code Crispies</div><span class="course-info">Selbstlernplattform</span></a></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>' > build/index.html
+	@mkdir -p build
+	@./scripts/generate-root-index.sh
 
 # Deploy
 define deploy_course

README.md

@@ -27,10 +27,12 @@ build/                # Generated output (gitignored)
 ## Development
 
 ```bash
-# Start dev servers (hot reload)
+# Start development server (hot reload)
-make dev              # All courses + index
+make dev              # Single server for all courses (port 3000)
-make dev-b            # 223015b only (port 1311)
+
-make dev-c            # 223015c only (port 1312)
+# Access individual courses:
+# 223015b: http://localhost:3000/223015b/
+# 223015c: http://localhost:3000/223015c/
 ```
 
 ## Build
@@ -43,7 +45,7 @@ make html             # HTML only
 make pdf              # PDF only
 ```
 
-## Klausur Slides
+## Klausur Folien
 
 Extract exam-relevant slides (marked with `<!-- _class: klausur -->`) into a single file:
 
@@ -53,7 +55,7 @@ make klausur-b        # 223015b only
 make klausur-c        # 223015c only
 ```
 
-Output: `slides/<course>/klausur.md`
+Output: `slides/<course>/klausurfolien.md`
 
 The generated file includes:
 - A title slide per kapitel for orientation

flake.nix

@@ -9,7 +9,8 @@
   outputs = { self, nixpkgs, flake-utils }:
     flake-utils.lib.eachDefaultSystem (system:
       let
-        pkgs = nixpkgs.legacyPackages.${system};
+        pkgs = import nixpkgs { inherit system; config.allowUnfree = true; };
+
 
         # QR code generator script
         qr-gen = pkgs.writeShellScriptBin "qr" ''
@@ -77,6 +78,7 @@
             qrencode
             imagemagick
             gnumake
+            claude-code
           ];
 
           shellHook = ''

package.json

@@ -3,13 +3,14 @@
   "version": "1.0.0",
   "description": "HdM Stuttgart - Lecture Slides (Marp)",
   "scripts": {
-    "dev:b": "PORT=1312 marp --server --allow-local-files courses/223015b/slides/",
+    "dev": "PORT=3000 marp --server --allow-local-files slides/",
-    "dev:c": "PORT=1313 marp --server --allow-local-files courses/223015c/slides/",
     "build": "make build",
     "build:b": "make build-b",
     "build:c": "make build-c",
     "pdf": "make pdf",
     "html": "make html",
+    "klausur": "make klausur",
+    "deploy": "make deploy",
     "test": "echo \"No tests specified\" && exit 0"
   },
   "keywords": ["marp", "slides", "hdm", "lectures"],

scripts/dev-server.sh

@@ -1,106 +1,53 @@
 #!/usr/bin/env bash
-# Development server script for HdM slides
+# Simplified development server for HdM slides
-# Starts index server + marp servers for each course
+# Starts single Marp server for all courses
 
 set -e
 
 # Configuration
-INDEX_PORT=1310
-COURSE_B_PORT=1311
-COURSE_C_PORT=1312
 SLIDES_DIR="slides"
-DEV_INDEX_DIR=".dev-index"
+DEV_PORT=3000
 
 # Colors
-RED='\033[0;31m'
 GREEN='\033[0;32m'
 BLUE='\033[0;34m'
+RED='\033[0;31m'
 NC='\033[0m' # No Color
 
 # Cleanup function
 cleanup() {
-    echo -e "\n${RED}Shutting down servers...${NC}"
+    echo -e "\n${RED}Shutting down dev server...${NC}"
-    kill $PID_INDEX $PID_B $PID_C 2>/dev/null || true
+    pkill -f "marp-cli.*--server" 2>/dev/null || true
     exit 0
 }
 
-# Kill existing processes on our ports
+# Kill existing processes on our port
 kill_existing() {
     echo -e "${BLUE}Cleaning up existing processes...${NC}"
-    # Kill marp processes first
     pkill -9 -f "marp-cli" 2>/dev/null || true
-    pkill -f "python3 -m http.server" 2>/dev/null || true
+    fuser -k $DEV_PORT/tcp 2>/dev/null || true
-    # Kill ports including marp's WebSocket ports (37717-37720 range)
+    sleep 1
-    fuser -k $INDEX_PORT/tcp $COURSE_B_PORT/tcp $COURSE_C_PORT/tcp 2>/dev/null || true
-    fuser -k 37717/tcp 37718/tcp 37719/tcp 37720/tcp 2>/dev/null || true
-    sleep 2
-}
-
-# Generate dev index
-generate_index() {
-    mkdir -p "$DEV_INDEX_DIR"
-    cat > "$DEV_INDEX_DIR/index.html" << 'EOF'
-<!DOCTYPE html>
-<html lang="de">
-<head>
-  <meta charset="UTF-8">
-  <meta name="viewport" content="width=device-width,initial-scale=1">
-  <title>HdM Slides - Dev</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:.5rem}
-    .subtitle{color:#86868b;font-size:1rem}
-    .courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}
-    a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}
-    a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}
-    .course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.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:.25rem 0}
-    .course-info{font-size:.85rem;color:#86868b}
-  </style>
-</head>
-<body>
-  <h1>HdM Slides</h1>
-  <p class="subtitle">Development Server</p>
-  <div class="courses">
-EOF
-    echo "    <a class=\"course course-b\" href=\"http://localhost:$COURSE_B_PORT\"><span class=\"course-label\">223015b</span><div class=\"course-title\">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class=\"course-info\">Port $COURSE_B_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
-    echo "    <a class=\"course course-c\" href=\"http://localhost:$COURSE_C_PORT\"><span class=\"course-label\">223015c</span><div class=\"course-title\">Grundlagen IT- und Internettechnik</div><span class=\"course-info\">Port $COURSE_C_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
-    cat >> "$DEV_INDEX_DIR/index.html" << 'EOF'
-  </div>
-</body>
-</html>
-EOF
 }
 
 # Main
 trap cleanup SIGINT SIGTERM
 
 kill_existing
-generate_index
 
-echo -e "${GREEN}Starting development servers...${NC}"
+echo -e "${GREEN}Starting development server...${NC}"
 echo ""
-echo -e "  Index:    ${BLUE}http://localhost:$INDEX_PORT${NC}"
+echo -e "  Server:   ${BLUE}http://localhost:$DEV_PORT${NC}"
-echo -e "  223015b:  ${BLUE}http://localhost:$COURSE_B_PORT${NC}"
+echo -e "  Slides:   ${BLUE}$SLIDES_DIR/${NC}"
-echo -e "  223015c:  ${BLUE}http://localhost:$COURSE_C_PORT${NC}"
 echo ""
-echo -e "Press ${RED}Ctrl+C${NC} to stop all servers"
+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"
 echo ""
 
-# Start servers
+# Start single Marp server for all slides
-python3 -m http.server $INDEX_PORT --directory "$DEV_INDEX_DIR" &
+PORT=$DEV_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/"
-PID_INDEX=$!
 
-PORT=$COURSE_B_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/223015b/" &
+# Wait for process to exit
-PID_B=$!
-
-sleep 3  # Stagger starts to avoid WebSocket port collision
-
-PORT=$COURSE_C_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/223015c/" &
-PID_C=$!
-
-# Wait for any process to exit
 wait

scripts/extract-klausur.sh

@@ -1,19 +1,19 @@
 #!/usr/bin/env bash
 # Extract klausur-relevant slides from all kapitel
 # Usage: ./extract-klausur.sh <course_id>
-# Output: slides/<course>/klausur.md
+# Output: slides/<course>/klausurfolien.md
 
 set -e
 
 COURSE="${1:-223015b}"
 SLIDES_DIR="slides/$COURSE"
-OUTPUT_FILE="$SLIDES_DIR/klausur.md"
+OUTPUT_FILE="$SLIDES_DIR/klausurfolien.md"
 
-# Find the first kapitel file (01-*.md) to copy styles from
+# Find the first kapitel file (00-intro.md or 01-*.md) to copy styles from
-FIRST_KAPITEL=$(ls "$SLIDES_DIR"/01-*.md 2>/dev/null | head -1)
+FIRST_KAPITEL=$(ls "$SLIDES_DIR"/00-intro.md "$SLIDES_DIR"/01-*.md 2>/dev/null | head -1)
 
 if [[ -z "$FIRST_KAPITEL" ]]; then
-  echo "Error: No 01-*.md file found in $SLIDES_DIR"
+  echo "Error: No 00-intro.md or 01-*.md file found in $SLIDES_DIR"
   exit 1
 fi
 
@@ -57,7 +57,7 @@ awk '
 ' "$FIRST_KAPITEL" >> "$OUTPUT_FILE"
 
 # Process each kapitel file in order - extract klausur slides only
-for md_file in $(ls "$SLIDES_DIR"/[0-9][0-9]-*.md 2>/dev/null | grep -v klausur | sort); do
+for md_file in $(ls "$SLIDES_DIR"/[0-9][0-9]-*.md 2>/dev/null | grep -v klausurfolien | sort); do
   filename=$(basename "$md_file")
   kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
 

scripts/generate-index.sh

@@ -42,6 +42,15 @@ TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
 TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
 TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
 
+# Configure which topics should appear disabled per course
+# Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)
+declare -A DISABLED_FULL
+declare -A DISABLED_BUTTONS
+# For course B: chapters 3,4,5 should be fully disabled
+DISABLED_FULL["223015b"]="speichermedien-schnittstellen distribution-apis-zukunft vertiefung-offene-fragen"
+# For course C: chapter 3 should keep link clickable but buttons disabled
+DISABLED_BUTTONS["223015c"]="interaktivitaet-javascript"
+
 cat > "$BUILD_DIR/index.html" << HEADER
 <!DOCTYPE html>
 <html lang="de">
@@ -61,6 +70,15 @@ cat > "$BUILD_DIR/index.html" << HEADER
       line-height: 1.5;
     }
     header { margin-bottom: 2rem; }
+    .breadcrumb {
+      margin-bottom: 1rem;
+      font-size: 0.85rem;
+    }
+    .breadcrumb a {
+      color: #86868b;
+      text-decoration: none;
+    }
+    .breadcrumb a:hover { text-decoration: underline; }
     h1 {
       font-size: 1.75rem;
       font-weight: 600;
@@ -68,6 +86,12 @@ cat > "$BUILD_DIR/index.html" << HEADER
       margin-bottom: 0.5rem;
       color: $ACCENT_COLOR;
     }
+    .course-heading {
+      font-size: 1.25rem;
+      font-weight: 500;
+      color: #1d1d1f;
+      margin-bottom: 0.25rem;
+    }
     .subtitle {
       color: #86868b;
       font-size: 0.95rem;
@@ -77,7 +101,8 @@ cat > "$BUILD_DIR/index.html" << HEADER
       font-size: 0.875rem;
       margin-top: 0.25rem;
     }
-    .kapitel {
+    /* Use the .termine wrapper and add a gap between cards */
+    .termine {
       margin-top: 1.5rem;
       display: flex;
       flex-direction: column;
@@ -93,6 +118,7 @@ cat > "$BUILD_DIR/index.html" << HEADER
       grid-template-columns: 1fr auto auto;
       align-items: center;
       gap: 1rem;
+      padding: 0; /* inner padding handled by kapitel-link */
     }
     .kapitel-card:hover {
       transform: translateY(-2px);
@@ -105,6 +131,8 @@ cat > "$BUILD_DIR/index.html" << HEADER
       color: inherit;
       grid-column: 1;
     }
+    /* Disabled look: dim the entire card and prevent pointer events */
+    .kapitel-card.disabled { opacity: 0.6; pointer-events: none; }
     .kapitel-label {
       font-size: 0.7rem;
       font-weight: 600;
@@ -135,11 +163,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
       white-space: nowrap;
       position: relative;
       z-index: 1;
+      margin-right: 0.5rem;
     }
     .btn-slides {
       background: $ACCENT_COLOR;
       color: #fff;
-      margin-right: 0.5rem;
     }
     .btn-slides:hover {
       filter: brightness(1.1);
@@ -147,9 +175,9 @@ cat > "$BUILD_DIR/index.html" << HEADER
     .btn-pdf {
       background: #f5f5f7;
       color: #1d1d1f;
-      margin-right: 1rem;
     }
     .btn-pdf:hover { background: #e8e8ed; }
+    .btn-disabled { opacity: 0.6; pointer-events: none; }
     /* Make entire card clickable via overlay */
     .kapitel-link::after {
       content: '';
@@ -198,7 +226,9 @@ cat > "$BUILD_DIR/index.html" << HEADER
 </head>
 <body>
   <header>
-    <h1>$TITLE</h1>
+    <p class="breadcrumb"><a href="../">← Kursübersicht</a></p>
+    <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>
   </header>
@@ -216,7 +246,7 @@ for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
   # Look up nice topic name or fallback
   topic="${TOPIC_MAP[$topic_raw]}"
   if [[ -z "$topic" ]]; then
-    topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\u&/')
+    topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\\u&/')
   fi
 
   # Handle kapitel number
@@ -228,42 +258,108 @@ for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
 
   pdf_filename="${filename%.html}.pdf"
 
-  # Check if PDF exists
+  # Determine whether this topic is configured as disabled for this course
+  disabled_full=false
+  disabled_buttons=false
+  for t in ${DISABLED_FULL["$COURSE"]}; do
+    if [[ "$topic_raw" == "$t" ]]; then
+      disabled_full=true
+      break
+    fi
+  done
+  if [[ "$disabled_full" == false ]]; then
+    for t in ${DISABLED_BUTTONS["$COURSE"]}; do
+      if [[ "$topic_raw" == "$t" ]]; then
+        disabled_buttons=true
+        break
+      fi
+    done
+  fi
+
+  # Decide card class
+  card_class="kapitel-card"
+  if [[ "$disabled_full" == true ]] || [[ "$disabled_buttons" == true ]]; then
+    card_class="$card_class disabled"
+  fi
+
+  # Build link/button HTML depending on disabled state
+  if [[ "$disabled_full" == true ]]; then
+    # non-interactive card (visually dimmed and not clickable)
+    link_html="<div class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></div>"
+    slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
+    pdf_html=""
+    if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
+      pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
+    fi
+  elif [[ "$disabled_buttons" == true ]]; then
+    # link stays clickable, but buttons are disabled; card appears dimmed
+    link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
+    slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
+    pdf_html=""
+    if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
+      pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
+    fi
+  else
+    # normal interactive card
     pdf_link=""
     if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
       pdf_link="<a href=\"$pdf_filename\" class=\"btn btn-pdf\">PDF</a>"
     fi
+    link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
+    slides_html="<a href=\"$filename\" class=\"btn btn-slides\">Folien</a>"
+    pdf_html="$pdf_link"
+  fi
 
   cat >> "$BUILD_DIR/index.html" << LINK
-    <div class="kapitel-card">
+    <div class="$card_class">
-      <a href="$filename" class="kapitel-link">
+      $link_html
-        <div class="kapitel-label">$kapitel_label</div>
+      $slides_html
-        <div class="kapitel-title">$topic</div>
+      $pdf_html
-      </a>
-      <a href="$filename" class="btn btn-slides">Folien</a>
-      $pdf_link
     </div>
 LINK
+
 done
 
-# Add klausur entry if it exists
+# Add klausurfolien entry if it exists
-if [[ -f "$BUILD_DIR/klausur.html" ]]; then
+if [[ -f "$BUILD_DIR/klausurfolien.html" ]]; then
   pdf_link=""
-  if [[ -f "$BUILD_DIR/klausur.pdf" ]]; then
+  if [[ -f "$BUILD_DIR/klausurfolien.pdf" ]]; then
-    pdf_link="<a href=\"klausur.pdf\" class=\"btn btn-pdf\">PDF</a>"
+    pdf_link="<a href=\"klausurfolien.pdf\" class=\"btn btn-pdf\">PDF</a>"
   fi
   cat >> "$BUILD_DIR/index.html" << KLAUSUR
     <div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
-      <a href="klausur.html" class="kapitel-link">
+      <a href="klausurfolien.html" class="kapitel-link">
         <div class="kapitel-label">Prüfung</div>
         <div class="kapitel-title">Klausurrelevante Folien</div>
       </a>
-      <a href="klausur.html" class="btn btn-slides">Folien</a>
+      <a href="klausurfolien.html" class="btn btn-slides">Folien</a>
       $pdf_link
     </div>
 KLAUSUR
 fi
 
+# Add klausurfragen entry if it exists (HTML and/or PDF)
+if [[ -f "$BUILD_DIR/klausurfragen.html" ]] || [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
+  pdf_link=""
+  if [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
+    pdf_link="<a href=\"klausurfragen.pdf\" class=\"btn btn-pdf\">PDF</a>"
+  fi
+  slides_link=""
+  if [[ -f "$BUILD_DIR/klausurfragen.html" ]]; then
+    slides_link="<a href=\"klausurfragen.html\" class=\"btn btn-slides\">Folien</a>"
+  fi
+  cat >> "$BUILD_DIR/index.html" << KLAUSURFRAGEN
+    <div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
+      <a href="klausurfragen.html" class="kapitel-link">
+        <div class="kapitel-label">Prüfung</div>
+        <div class="kapitel-title">Klausurfragen</div>
+      </a>
+      $slides_link
+      $pdf_link
+    </div>
+KLAUSURFRAGEN
+fi
+
 cat >> "$BUILD_DIR/index.html" << FOOTER
   </div>
   <div class="qr-section">
@@ -272,7 +368,7 @@ cat >> "$BUILD_DIR/index.html" << FOOTER
   </div>
   <footer>
     <a href="mailto:mail@librete.ch">Kontakt</a> ·
-    <a href="../">Alle Kurse</a>
+    <a href="../">Kursübersicht</a>
   </footer>
 </body>
 </html>

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

@@ -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 -->
@@ -270,6 +302,30 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Kompression – Vertiefung
+
+Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der Kompression. Ein Text mit gleichmäßiger Zeichenverteilung hat hohe Entropie (schwer komprimierbar); repetitive Texte haben niedrige Entropie.
+
+**Verlustfreie Kompression** erreicht diese Grenze durch:
+- **Statistische Kodierung:** Huffman, Arithmetic Coding
+- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG)
+- Originalzustand ist exakt rekonstruierbar
+
+**Verlustbehaftete Kompression** unterschreitet die Grenze, indem sie menschliche Wahrnehmungsgrenzen ausnutzt:
+
+| Sinneskanal | Psychophysisches Modell | Ausnutzung |
+|-------------|------------------------|------------|
+| 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.
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
@@ -837,6 +893,29 @@ Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Dateneinheiten – Vertiefung
+
+Zwei konkurrierende Standards existieren seit der IEC-Normierung 1998:
+
+| Präfix | SI (Dezimal) | IEC (Binär) | Differenz |
+|--------|--------------|-------------|-----------|
+| Kilo | 1.000 (10³) | 1.024 (2¹⁰) KiB | 2,4% |
+| Mega | 1.000.000 (10⁶) | 1.048.576 MiB | 4,9% |
+| Giga | 10⁹ | 2³⁰ GiB | 7,4% |
+| Tera | 10¹² | 2⁴⁰ TiB | 10% |
+
+**Warum der Unterschied wächst:** (2¹⁰)ⁿ ÷ (10³)ⁿ = 1,024ⁿ. Bei Terabyte sind es bereits 10% Abweichung.
+
+**Festplatten-Marketing:** Hersteller nutzen SI (dezimal), Betriebssysteme zeigen IEC (binär). Eine „1 TB"-Festplatte zeigt daher nur 931 GiB an – technisch korrekt, aber verwirrend.
+
+**Historischer Kontext:** RAM wurde immer binär gemessen (2ⁿ Adressen), Festplatten ursprünglich dezimal (physikalische Geometrie). Die IEC führte 1998 KiB/MiB/GiB ein – diese Notation setzt sich langsam durch.
+
+---
+
 # Datenwachstum der Menschheit
 
 | Jahr | Datenmenge | Kontext |
@@ -903,6 +982,32 @@ VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Digitaler Wendepunkt – Vertiefung
+
+Die Studie von Hilbert & López (Science, 2011) analysierte 60 Speichertechnologien von 1986–2007. Der Wendepunkt 2002 markiert den Moment, ab dem mehr Information digital als analog existierte.
+
+**Was 1986 „analog" bedeutete:**
+- Bücher, Zeitungen, Magazine: ~8 EB
+- Vinyl-Schallplatten, Musikkassetten: ~12 EB
+- VHS-Kassetten, Filmrollen: ~60 EB
+
+**Warum analog stagnierte:** Physische Medien haben Kapazitätsgrenzen. Eine VHS speichert 10 GB; eine Blu-ray (2006) bereits 50 GB auf kleinerer Fläche.
+
+**LTO-Magnetband überlebt** trotz „alter" Technologie:
+| Medium | Kosten/TB | Lebensdauer | Energiebedarf |
+|--------|-----------|-------------|---------------|
+| SSD | ~50 € | 5–10 Jahre | Dauerstrom |
+| HDD | ~15 € | 3–5 Jahre aktiv | Dauerstrom |
+| LTO-9 | ~5 € | 30+ Jahre | Nur beim Zugriff |
+
+AWS Glacier, Google Coldline und Film-Archive nutzen LTO – langsamer Zugriff, aber unschlagbar günstig und langlebig.
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
@@ -1004,6 +1109,29 @@ Visueller Kontrast: Analog vs. Digital
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Analoge Medien – Vertiefung
+
+Analoge Speicherung codiert Information als **kontinuierliche physikalische Größe**: Rillentiefe (Vinyl), Magnetfeldstärke (Tonband), Silberkorn-Dichte (Film). Es gibt keine diskreten Stufen – theoretisch unendliche Auflösung, praktisch begrenzt durch Rauschen.
+
+**Generationsverlust** entsteht, weil jede Kopie neues Rauschen addiert:
+- Schallplatte → Kassette: Frequenzgang leidet, Rauschen steigt
+- VHS → VHS: Farbsättigung sinkt, Schärfe nimmt ab
+- 3. Generation: oft unbrauchbar
+
+| Medium | Typische Auflösung | Dynamik |
+|--------|-------------------|---------|
+| Vinyl (audiophil) | ~20–20.000 Hz | ~70 dB |
+| Tonband (Studio) | ~30–15.000 Hz | ~55 dB |
+| 35mm Film | ~4K-äquivalent | ~13 Blendenstufen |
+
+**Paradox der Analogtechnik:** Das Original ist einzigartig und unersetzlich – aber genau deshalb anfällig. Jedes Abspielen einer Schallplatte trägt mikroskopisch Material ab; jeder Filmdurchlauf riskiert Kratzer.
+
+---
+
 # Analoge Medien: Vor- und Nachteile
 
 | Vorteile | Nachteile |
@@ -1071,6 +1199,30 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Digitale Medien – Vertiefung
+
+Digitale Speicherung quantisiert kontinuierliche Signale in diskrete Werte. Der **Quantisierungsfehler** (Differenz zum Original) ist der Preis der Digitalisierung – aber einmal digitalisiert, bleibt die Information exakt.
+
+**Bit-identische Kopien** revolutionierten die Medienindustrie:
+- Keine Qualitätskette mehr: 1000. Kopie = 1. Kopie = Original
+- Kosten pro Kopie: praktisch null (nur Speicherplatz)
+- Perfekte Archivierung: Bits altern nicht (nur der Datenträger)
+
+| Aspekt | Analog | Digital |
+|--------|--------|---------|
+| Kopiervorgang | Physikalischer Prozess | Bit-Kopie |
+| Qualität pro Generation | Verschlechtert | Identisch |
+| Fehlerkorrektur | Unmöglich | Möglich (ECC, RAID) |
+| 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.
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -1089,6 +1241,31 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Digitale Speichermedien – Vertiefung
+
+Jede Technologie hat physikalische Vor- und Nachteile:
+
+**Optisch (CD/DVD/Blu-ray):** Laser liest Pits (Vertiefungen) und Lands (Erhöhungen). Robust gegen Magnetfelder, aber empfindlich gegenüber Kratzern und UV-Licht. M-DISC verspricht 1000 Jahre – unter Laborbedingungen.
+
+**Magnetisch (HDD/LTO):** Magnetisierte Bereiche auf rotierenden Platten oder Band. HDDs haben bewegliche Teile (Verschleiß); LTO-Bänder sind passiv und extrem langlebig, aber sequentieller Zugriff.
+
+**Flash (SSD/USB/SD):** Elektronen in Floating Gates speichern Bits. Keine beweglichen Teile, aber begrenzte Schreibzyklen (TLC: ~3.000, SLC: ~100.000). Ohne Strom verlieren Zellen nach Jahren ihre Ladung.
+
+| Szenario | Empfehlung | Grund |
+|----------|------------|-------|
+| Betriebssystem | NVMe SSD | Geschwindigkeit |
+| Videoarchiv | HDD | Kapazität/Preis |
+| Langzeitarchiv | LTO + M-DISC | Lebensdauer |
+| Austausch | USB/SD | Portabilität |
+
+**Cloud** ist physisch HDD/SSD/LTO in Rechenzentren – kein eigenes Medium, sondern Zugriffsmethode.
+
+---
+
 # Das Speicherproblem der Digitalisierung
 
 

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

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

@@ -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 -->
@@ -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/klausurfolien.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 – WS 2025/26"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 <style>
@@ -92,6 +92,8 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
+**Wintersemester 2025/26**
+
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 
 ---
@@ -277,14 +279,12 @@ Breite × Höhe × Farbtiefe (in Bytes)
 | 32 | 16,7 Mio. + Alpha | Transparenz |
 
 <!--
-BERECHNUNG: Breite × Höhe × (Farbtiefe / 8)
+KLAUSURRELEVANT:
-BEISPIEL: 1920×1080 × 24 Bit = 1920×1080×3 = 6.220.800 Bytes ≈ 6,2 MB
+- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
-
+- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
-Farbtiefe erklärt:
+- Farbtiefe: 2^n Farben bei n Bit
-- 1 Bit: 2^1 = 2 Farben
+- 24 Bit = 8 Bit pro Kanal (R, G, B)
-- 8 Bit: 2^8 = 256 Farben
+- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
-- 24 Bit: 2^24 = 16.777.216 Farben (je 8 Bit für R, G, B)
-- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal
 -->
 
 
@@ -306,17 +306,15 @@ Farbtiefe erklärt:
 <circle cx="50" cy="50" r="40" fill="#ff0000"/>
 ```
 
-<small>SVG beschreibt nicht jeden einzelnen Pixel im Raster, sondern deklariert wie Farben und Formen gesetzt werden.</small>
+<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>
 
 <!--
-Vektorgrafiken beschreiben WAS gezeichnet werden soll.
+KLAUSURRELEVANT:
-Rastergrafiken beschreiben WIE jeder Pixel aussieht.
+- Vektor = Beschreibung (deklarativ)
-
+- Raster = Pixel für Pixel (imperativ)
-Rendering-Pipeline:
+- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
-Vektordaten → Rasterisierung → Framebuffer → Display
+- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
-
+- SVG = Scalable Vector Graphics (Web-Standard)
-Beim Skalieren werden einfach die Koordinaten multipliziert.
-Keine Information geht verloren.
 -->
 
 
@@ -334,18 +332,17 @@ Keine Information geht verloren.
 - Niedrige Frequenzen besser als hohe
 
 **JPEG nutzt das aus:**
-- Farbauflösung reduzieren (aber Helligkeit behalten)
+- Farbauflösung reduzieren (Helligkeit behalten)
 - Glatte Flächen effizient speichern
-- Hohe Frequenzen (Details) verwerfen
+- Hohe Frequenzen (feine Details) verwerfen
 
 <!--
-Das ist die visuelle Entsprechung zur Psychoakustik.
+KLAUSURRELEVANT:
-
+- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
-Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen)
+- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
-als für Farbe (Zapfen).
+- Niedrig = langsame Änderung = große gleichmäßige Fläche
-
+- Hoch = schnelle Änderung = feine Details, Kanten
-Hohe Frequenzen = schnelle Wechsel = feine Details
+- Analogie zur Psychoakustik bei MP3 (letztes Mal)
-Niedrige Frequenzen = langsame Wechsel = große Flächen
 -->
 
 
@@ -357,24 +354,25 @@ Niedrige Frequenzen = langsame Wechsel = große Flächen
 
 ![bg right:20%](./assets/Barn-yuv.png)
 
-# JPEG: Schritt 1 – Farbraumkonversion
+# JPEG Schritt 1: Farbraumkonversion
 
-**RGB → Y'CbCr** (seltener Y'UV)
+**RGB → Y'CbCr**
 
-- **Y** = Helligkeit (Luminanz) – Was das Auge am besten sieht
+- **Y** = Helligkeit (Luminanz)
 - **Cb** = Blau-Gelb-Anteil (Chrominanz)
 - **Cr** = Rot-Grün-Anteil (Chrominanz)
 
-**Warum diese Trennung?**
+**Warum?**
-Y (Helligkeit) behält volle Auflösung.
+Y (Helligkeit) behält volle Auflösung
-Cb/Cr (Farbe) kann reduziert werden – Auge merkt es kaum.
+Cb/Cr (Farbe) kann reduziert werden
 
 <!--
-YCbCr ist wie RGB ein Tripel aus 3 Werten pro Pixel.
+KLAUSURRELEVANT:
-Der Unterschied: Statt Rot-Grün-Blau speichern wir Helligkeit + 2 Farbdifferenzen.
+- YCbCr = auch 3 Werte pro Pixel, aber anders organisiert
-
+- Statt R-G-B: Helligkeit + 2 Farbdifferenzen
-Die Umrechnung ist reversibel (mathematische Transformation).
+- Umrechnung ist reversibel (mathematische Transformation)
-Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
+- Vorteil: Helligkeit und Farbe getrennt behandelbar
+- Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)
 -->
 
 
@@ -384,14 +382,14 @@ Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
 <!-- _footer: "" -->
 
 
-# JPEG: Schritt 6 – Huffman-Coding
+# JPEG Schritt 6: Huffman-Coding
 
 **Verlustfreie Kompression der Restwerte**
 
-**Idee:** Statt fester 8 Bit pro Wert → variable Bitlänge
+**Idee:** Variable Bitlänge statt fester 8 Bit
-Häufige Werte bekommen kurze Bit-Sequenzen.
+Häufige Werte → kurze Codes
 
-| Zeichen | Häufigkeit | Code (Bit-Sequenz) |
+| Zeichen | Häufigkeit | Code |
 |---------|------------|------|
 | e | 40% | `0` (1 Bit) |
 | a | 25% | `10` (2 Bit) |
@@ -400,9 +398,74 @@ Häufige Werte bekommen kurze Bit-Sequenzen.
 | u | 5% | `1111` (4 Bit) |
 
 <!--
-Huffman-Coding ist verlustfrei.
+KLAUSURRELEVANT:
-Der "Code" ist eine Bit-Sequenz, die das Zeichen eindeutig identifiziert.
+- Huffman = verlustfrei, optimal für bekannte Häufigkeiten
-Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
+- Präfix-frei: Kein Code ist Anfang eines anderen
+- Häufigstes Zeichen = kürzester Code
+- Auch in ZIP, PNG, MP3 verwendet
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+<!--
+# Huffman-Coding: Beispiel
+
+**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)
+
+**Häufigkeitsanalyse:**
+A=5, B=2, R=2, C=1, D=1
+
+**Huffman-Baum → Codes:**
+| Zeichen | Häufigkeit | Code |
+|---------|------------|------|
+| A | 5 | `0` |
+| B | 2 | `10` |
+| R | 2 | `110` |
+| C | 1 | `1110` |
+| D | 1 | `1111` |
+
+**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
+**Kompression:** 88 → 23 Bit = **74% gespart**
+
+
+- Beispiel Schritt für Schritt durchrechnen
+- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
+- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
+- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
+- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# WebP & AVIF: Moderne Alternativen
+
+**WebP (Google, 2010):**
+- Lossy und Lossless
+- Transparenz und Animationen
+- 25–35% kleiner als JPEG
+
+**AVIF (2019):**
+- Basiert auf AV1-Video-Codec
+- 50% kleiner als JPEG
+- HDR-Unterstützung, patent-frei
+
+**Browser-Support 2025:** WebP universell, AVIF wächst
+
+<!--
+KLAUSURRELEVANT:
+- WebP: VP8-Kompression (Google Video-Codec)
+- AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla)
+- Beide besser als JPEG, aber Kompatibilität bleibt Problem
+- JPEG bleibt dominant: alte Kameras, Software, Workflows
 -->
 
 
@@ -414,28 +477,22 @@ Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
 
 # Container und Codec
 
-**Container = Das Dateiformat (Beispiel: MP4)**
+**Container = Dateiformat (z.B. MP4)**
 Die "Box", die verschiedene Streams zusammenpackt:
 - Video-Stream
 - Audio-Stream(s)
 - Untertitel
 - Metadaten
 
-**Codec = Der Kompressionsalgorithmus (Beispiel: AV1)**
+**Codec = Kompressionsalgorithmus (z.B. H.264)**
-Entscheidet, WIE komprimiert wird.
+Bestimmt, WIE komprimiert wird
-
 
 <!--
-Container ≠ Codec
+KLAUSURRELEVANT:
-Das ist ein häufiges Missverständnis.
+- Container ≠ Codec (häufiges Missverständnis!)
-
+- MP4 kann H.264, H.265 oder AV1 enthalten
-MP4 ist ein Container, nicht ein Codec.
+- Gleiche Endung, unterschiedlicher Inhalt
-Ein MP4 kann H.264, H.265 oder AV1 enthalten.
+- Tool-Tipp: MediaInfo zeigt beides an
-
-Übrigens: JPEG ist ein Codec (für Bilder), kein Container.
-Bei Bildern fallen Container und Codec oft zusammen.
-
-Tools wie MediaInfo zeigen beide Informationen.
 -->
 
 
@@ -451,19 +508,19 @@ Tools wie MediaInfo zeigen beide Informationen.
 
 **Warum dominant?**
 - Exzellente Kompression (~100:1 möglich)
-- Hardware-Support in jedem Gerät seit ~2010
+- Hardware-Decoder in jedem Gerät seit ~2010
 - YouTube, Netflix, Blu-ray – alles H.264
 
 **Features:**
 - Variable Block-Größen (16×16 bis 4×4)
-- Deblocking-Filter (reduziert Block-Artefakte)
+- Deblocking-Filter (reduziert Artefakte)
 
 <!--
-H.264 revolutionierte Video-Streaming.
+KLAUSURRELEVANT:
-Ohne H.264 kein Netflix, kein YouTube in HD.
+- H.264 revolutionierte Video-Streaming
-
+- Ohne H.264 kein Netflix, kein YouTube HD
-Hardware-Decoder bedeutet: Kein CPU-Aufwand, kein Akku-Drain.
+- Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain
-Selbst billige Smartphones können H.264 abspielen.
+- Selbst billigste Smartphones können H.264 abspielen
 -->
 
 
@@ -486,17 +543,16 @@ Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
 - 8K, HDR, hohe Frame-Rates
 
 **Stand 2025:**
-YouTube und Netflix nutzen AV1 für 4K/8K
+YouTube, Netflix nutzen AV1 für 4K/8K
 Hardware-Encoder in aktuellen GPUs
 
 <!--
-AOM = Alliance for Open Media, gegründet 2015.
+KLAUSURRELEVANT:
-Historisch: Konkurrierende Tech-Giganten vereint.
+- AOM gegründet 2015 – historisch: Konkurrenten vereint
-
+- Ziel: Nie wieder Patent-Chaos wie bei H.265
-Das Ziel: Nie wieder Patent-Chaos wie bei H.265.
+- Problem: Encoding sehr langsam (10–100× vs. H.264)
-
+- Hardware-Encoder lösen das zunehmend
-Problem: Encoding ist sehr langsam (10-100× vs. H.264).
+- AV1 gewann 2024 einen Emmy für technische Innovation
-Hardware-Encoder lösen das zunehmend.
 -->
 
 

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

@@ -68,6 +68,38 @@ section.aufgabe {
 section.aufgabe footer {
   display: none;
 }
+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 -->
@@ -652,6 +684,28 @@ PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Von-Neumann-Architektur – Vertiefung
+
+John von Neumann beschrieb 1945 im „First Draft of a Report on the EDVAC" das Prinzip des **Stored Program Computer**: Programme und Daten teilen sich denselben Speicher und sind damit austauschbar, ohne Hardware-Änderungen.
+
+**Die 5 Komponenten im Detail:**
+
+| Komponente | Moderne Entsprechung | Funktion |
+|------------|---------------------|----------|
+| Rechenwerk (ALU) | CPU-Kern | Addition, Subtraktion, Logik (AND, OR, NOT) |
+| Steuerwerk | CPU-Kern | Fetch-Decode-Execute-Zyklus |
+| Speicherwerk | RAM + ROM | Einheitlicher Adressraum für Code + Daten |
+| Ein-/Ausgabe | I/O-Controller | USB, PCIe, Netzwerk |
+| Bus-System | Northbridge/Southbridge (heute: SoC) | Adress-, Daten-, Steuerbus |
+
+**Von-Neumann-Flaschenhals:** CPU und Speicher teilen einen Bus – die Bandbreite begrenzt die Geschwindigkeit. Moderne CPUs umgehen dies durch Caches (L1/L2/L3), die als Harvard-ähnliche Puffer dienen.
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -689,6 +743,33 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Stored Program Concept – Vertiefung
+
+Vor Von Neumann mussten Computer für jedes Problem neu verkabelt werden (ENIAC: tagelange Arbeit). Das **Stored Program Concept** machte Programme zu Daten – austauschbar wie Dokumente.
+
+**Konsequenzen für die Software-Industrie:**
+- **Betriebssysteme** möglich: Laden verschiedene Programme aus demselben Speicher
+- **Updates** ohne Hardware-Austausch: Nur Bits ändern, nicht Kabel
+- **Multitasking**: Mehrere Programme gleichzeitig im Speicher
+- **Self-Modifying Code**: Programme können sich selbst ändern (Compiler, JIT)
+
+**Harvard-Architektur (Alternative):**
+
+| Aspekt | Von Neumann | Harvard |
+|--------|-------------|---------|
+| Speicher | Gemeinsam für Code + Daten | Getrennt |
+| Busse | Ein Bus (Flaschenhals) | Paralleler Zugriff |
+| Flexibilität | Hoch (Code = Daten) | Geringer |
+| Einsatz | Desktop, Server, Smartphone | DSP, Mikrocontroller |
+
+**Modern:** „Modified Harvard" – L1-Cache trennt Code/Daten (Speed), RAM bleibt gemeinsam (Flexibilität).
+
+---
+
 <!-- _class: lead -->
 
 # Vom Militär zum Netz
@@ -1117,6 +1198,34 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HTML Metadaten – Vertiefung
+
+Der `<head>`-Bereich enthält Informationen *über* das Dokument, nicht den sichtbaren Inhalt. Diese Metadaten steuern Browser-Verhalten, Suchmaschinen-Indexierung und Social-Media-Vorschauen.
+
+**Kritische Meta-Tags:**
+
+| Tag | Funktion | Beispiel |
+|-----|----------|----------|
+| `<title>` | Browser-Tab, Suchergebnis-Titel | `<title>HdM Stuttgart</title>` |
+| `<meta charset>` | Zeichenkodierung (Umlaute!) | `<meta charset="UTF-8">` |
+| `<meta viewport>` | Mobile Darstellung | `width=device-width, initial-scale=1` |
+| `<meta description>` | Suchergebnis-Snippet (max 160 Zeichen) | SEO-kritisch |
+
+**Open Graph Protocol (Facebook, 2010):**
+```html
+<meta property="og:title" content="Artikel-Titel">
+<meta property="og:image" content="https://example.com/preview.jpg">
+```
+Steuert die Vorschau beim Teilen auf Facebook, LinkedIn, WhatsApp, Slack.
+
+**SEO-Relevanz:** Google nutzt `<title>` und `<meta description>` für Ranking und Snippet-Anzeige. Fehlende Metadaten = schlechtere Auffindbarkeit.
+
+---
+
 # HTML-Tags und Attribute
 
 ```html
@@ -1340,6 +1449,33 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Web-Zugänglichkeit – Vertiefung
+
+**a11y** = Accessibility (a + 11 Buchstaben + y). Die WHO schätzt, dass 15% der Weltbevölkerung eine Behinderung haben – das sind über 1 Milliarde potenzielle Nutzer.
+
+**Arten von Einschränkungen:**
+
+| Typ | Permanent | Temporär | Situativ |
+|-----|-----------|----------|----------|
+| Visuell | Blindheit | Nach Augen-OP | Grelle Sonne |
+| Motorisch | Amputation | Gebrochener Arm | Baby auf dem Arm |
+| Auditiv | Taubheit | Ohrenentzündung | Laute Umgebung |
+| Kognitiv | Legasthenie | Müdigkeit | Ablenkung |
+
+**Assistive Technologien:**
+- **Screenreader:** NVDA (Windows, kostenlos), VoiceOver (Apple, integriert), JAWS (kommerziell)
+- **Braillezeilen:** Taktile Ausgabe, ~40–80 Zeichen
+- **Switch-Geräte:** Ein-Knopf-Steuerung für motorische Einschränkungen
+- **Eye-Tracking:** Blicksteuerung für Bewegungsunfähige
+
+Screenreader lesen den DOM sequenziell – semantisches HTML (`<nav>`, `<main>`, `<button>`) ermöglicht Navigation per Tastenkürzel.
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -1379,6 +1515,35 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Rechtliche Anforderungen – Vertiefung
+
+Der **European Accessibility Act (EAA)** trat am 28. Juni 2025 in Kraft und betrifft erstmals auch private Unternehmen – nicht nur öffentliche Stellen.
+
+**Betroffene Sektoren:**
+- E-Commerce (Online-Shops)
+- Bankdienstleistungen
+- Telekommunikation
+- E-Books und E-Reader
+- Ticketing und Check-in-Terminals
+
+**WCAG 2.2 – Konformitätsstufen:**
+
+| Level | Anforderung | Beispiel |
+|-------|-------------|----------|
+| A | Minimum | Alt-Texte für Bilder |
+| AA | Gesetzlicher Standard | Kontrast 4,5:1, Tastaturnavigation |
+| AAA | Optimal | Gebärdensprache für Videos |
+
+**Curb-Cut-Effekt:** Barrierefreiheit hilft allen. Bordsteinabsenkungen für Rollstühle nutzen auch Kinderwagen, Rollkoffer, Fahrräder. Untertitel helfen Gehörlosen, aber auch in lauten Umgebungen oder beim Sprachlernen.
+
+**Sanktionen:** Bis zu 100.000 € Bußgeld bei Verstößen.
+
+---
+
 # WCAG: Der Standard
 
 **W**eb **C**ontent **A**ccessibility **G**uidelines
@@ -1532,6 +1697,38 @@ Echte NutzerInnen einbeziehen = Gold-Standard
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Barrierefreiheit testen – Vertiefung
+
+Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erfordert manuelles Testen und idealerweise echte Nutzer mit Behinderungen.
+
+**Tastatur-Test (5 Minuten, jeder kann's):**
+1. Maus weglegen, nur Tab + Enter + Pfeiltasten nutzen
+2. Fokus-Indikator immer sichtbar? (kein `outline: none;`!)
+3. Logische Reihenfolge? (nicht kreuz und quer)
+4. Alle interaktiven Elemente erreichbar?
+
+**Automatisierte Tools:**
+
+| Tool | Typ | Findet |
+|------|-----|--------|
+| axe DevTools | Browser-Extension | ~30% der WCAG-Verstöße |
+| WAVE | Browser-Extension | Struktur-Probleme, Kontrast |
+| Lighthouse | Chrome DevTools | Performance + Accessibility |
+| Pa11y | CLI | CI/CD-Integration |
+
+**Screenreader-Kurztest:**
+- macOS: `Cmd + F5` (VoiceOver)
+- Windows: NVDA installieren (kostenlos)
+- Augen schließen, nur zuhören: Ist die Seite verständlich?
+
+**Gold-Standard:** Usability-Tests mit Menschen, die Assistive Technologien täglich nutzen.
+
+---
+
 
 <!-- _class: lead -->
 

slides/223015c/02-netzwerke-protokolle-css.md

@@ -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 -->
@@ -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:**