klausur-marker reset: 42 _class:klausur entfernt (alle die ich beim rewrite hinzugefügt habe). nur folien mit titel-exact-match zur main-version bleiben klausur — aktuell 2 (Prüfungsleistung-intros). klausurfolien.md auf 2 slides regeneriert pro kurs. dozent kann live in vorlesung entscheiden welche klausur-relevant sind, marker-set ist explizite untermenge der main-version

2026-05-14 21:09:23 +02:00
parent 722a4a9fe8
commit 6209f9f3a0
9 changed files with 0 additions and 1403 deletions
@@ -310,8 +310,6 @@ Klausurrelevant: wenn jemand sagt "lila ist B399FF", können wir die drei Byte s

 ---

-<!-- _class: klausur -->
-
 # Hex begegnet euch überall

 | Kontext | Beispiel |
@@ -447,8 +445,6 @@ Pädagogisch wichtig: variable Länge heißt, dass „Zeichen zählen" und „By

 ---

-<!-- _class: klausur -->
-
 # Beispiel: Byte zählen

 **Text:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"`
@@ -490,8 +486,6 @@ Auflösung kommt mit Magic-Numbers-Folie.

 ---

-<!-- _class: klausur -->
-
 # Magic Numbers — die Visitenkarte der Datei

 **Datei-Typ erkennt man an den ersten Byte:**
@@ -584,8 +578,6 @@ Gruppenarbeit: 3–4 Personen. ~15 Min.

 ---

-<!-- _class: klausur -->
-
 # KB vs KiB — warum „1 TB" als 931 GB angezeigt wird

 ![bg right:48% contain](./assets/demos/kb-vs-kib.png)
@@ -607,8 +599,6 @@ Klausurfähig: warum zeigt eine 1-TB-SSD im Finder „931 GB"? Begründung mit R

 ---

-<!-- _class: klausur -->
-
 # Dateneinheiten — Größenordnungen

 | Einheit | Bytes (dezimal) | Beispiel |
@@ -749,8 +739,6 @@ Das ist dasselbe Phänomen wie Audio-Quantisierungsrauschen, nur in der visuelle

 ---

-<!-- _class: klausur -->
-
 # Datenrate = Sample Rate × Bittiefe × Kanäle

 **Formel:**
@@ -779,8 +767,6 @@ Brücke zu Kap2 (Kompression): da reduzieren wir nicht die Parameter, sondern *w

 ---

-<!-- _class: klausur -->
-
 # CD-Audio: die Rechnung

 **Audio-CD (Philips/Sony 1982):**
@@ -807,8 +793,6 @@ Spektrogramm-Folie als Anschluss: 44,1 kHz → wir können bis ~22 kHz erfassen.

 ---

-<!-- _class: klausur -->
-
 # Nyquist — warum 2× reicht

 ![bg right:50% contain](./assets/demos/nyquist-diagram.png)
@@ -370,8 +370,6 @@ Sobald du bearbeiten, mastern, archivieren willst → Lossless.

 ---

-<!-- _class: klausur -->
-
 # Vergleich: Lossless vs. Lossy

 | Eigenschaft | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
@@ -149,8 +149,6 @@ Anwendung: Logo → Vektor. Foto → Raster. Icon → Vektor.

 ---

-<!-- _class: klausur -->
-
 # Raster vs. Vektor

 | | Raster | Vektor |
@@ -332,8 +330,6 @@ Konsequenz: nach Schritt 6 ist die Pipeline fertig. Die JPEG-Datei kann gespeich

 ---

-<!-- _class: klausur -->
-
 # Memo: Die 6 JPEG-Schritte

 | # | Schritt | Lossless / Lossy |
@@ -415,8 +411,6 @@ Quality-Bewusstsein: SVG ist nicht „Konkurrenz" zu Raster-Formaten — sie lö

 ---

-<!-- _class: klausur -->
-
 # Wann welches Bildformat?

 | Anwendung | Format | Warum |
@@ -572,8 +566,6 @@ Wichtig:

 ---

-<!-- _class: klausur -->
-
 # Audio-Format-Wahl

 | Anwendung | Format | Warum |
@@ -668,7 +660,6 @@ Die Kompression ist hier nicht „nice to have" — sie ist die Voraussetzung, d

 ---

-<!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->

@@ -751,8 +742,6 @@ B-Frames sind effizienter als P-Frames (haben zwei Vorlagen), aber teurer zu enk

 ---

-<!-- _class: klausur -->
-
 # I, P, B — Frame-Typen

 | Typ | Vollname | Was drin | Größe |
@@ -896,8 +885,6 @@ Pointe: politisch gewinnt der „offene" Codec, wenn die Industrie es will. Bei

 ---

-<!-- _class: klausur -->
-
 # Patent vs. Open — warum AV1?

 | Codec | Effizienz | Patent | Adoption (2026) |
@@ -157,8 +157,6 @@ NVMe vs SATA:

 ---

-<!-- _class: klausur -->
-
 # HDD vs. SSD

 ![bg right:40% contain](./assets/hdd-ssd-comparison.png)
@@ -188,8 +186,6 @@ Klausurfähig: gegeben ein Anwendungsfall, HDD oder SSD?

 ---

-<!-- _class: klausur -->
-
 # Wann nehme ich was?

 | Anwendung | Empfehlung | Begründung |
@@ -248,8 +244,6 @@ Wenn du einen USB-Stick „formatierst", wird das Filesystem neu angelegt — di

 ---

-<!-- _class: klausur -->
-
 # Filesystem-Landschaft

 | Filesystem | Wo verbreitet | Max. Dateigröße | Besonderheit |
@@ -310,8 +304,6 @@ Daraus folgt die 3-2-1-Regel.

 ---

-<!-- _class: klausur -->
-
 # Die 3-2-1-Backup-Regel

 **3** Kopien deiner Daten
@@ -523,8 +515,6 @@ WiFi 6 / 6E (ax) bringt deutliche Verbesserung gegenüber WiFi 5 (ac), insbesond

 ---

-<!-- _class: klausur -->
-
 # Schnittstellen-Wahl-Matrix

 | Aufgabe | Beste Schnittstelle | Warum |
@@ -213,8 +213,6 @@ Konsistente Methoden + URLs → REST = "Representational State Transfer".

 ---

-<!-- _class: klausur -->
-
 # REST: GET · POST · PUT · DELETE

 | Methode | Was tut sie | URL-Beispiel |
@@ -354,8 +352,6 @@ Demo im Hörsaal: ein Foto vom Smartphone exportieren, exiftool drauf, GPS-Koord

 ---

-<!-- _class: klausur -->
-
 # Der John-McAfee-GPS-Fall

 **Dezember 2012.** John McAfee (Antivirus-Erfinder) flieht aus Belize, wo er als Mordverdächtiger gesucht wird.
@@ -440,8 +436,6 @@ Verwendet von: iTunes, Spotify, jeder Audio-Player.

 ---

-<!-- _class: klausur -->
-
 # Der Tony-Blair-Fall (PDF-Metadaten)

 **Februar 2003.** Britische Regierung veröffentlicht PDF-Dokument zur Begründung des Irakkriegs.
@@ -524,8 +518,6 @@ Gegenstrategien:

 ---

-<!-- _class: klausur -->
-
 # Vendor-Lockin als Risiko

 **Szenario:** Du arbeitest 5 Jahre lang mit Adobe InDesign. Dann steigt der Abo-Preis um 200 % oder Adobe ändert das Format.
@@ -97,729 +97,3 @@ Hochschule der Medien Stuttgart
 **Sommersemester 2026**

 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Hex begegnet euch überall
-
-| Kontext | Beispiel |
-|---------|----------|
-| CSS-Farben | `#FF5733` |
-| MAC-Adressen | `00:1A:2B:3C:4D:5E` |
-| Speicheradressen | `0xA04F20` |
-| Windows-Fehlercodes | `0x80070005` |
-| Unicode-Codepoints | `U+00E4` (ä) |
-| Datei-Signaturen | `89 50 4E 47` (PNG) |
-
-<!--
-Präfixe:
- `0x` = "das ist Hex" (in C, JS, Python)
- `U+` = Unicode-Codepoint
- `#` = CSS-Konvention
-
-Lebensweltanker: jede:r Studi hat mindestens drei dieser Kontexte schon real gesehen. Hex ist nicht eine akademische Übung, sondern die Lesart, in der Computer mit Menschen über Byte reden.
-
-MAC-Adresse: 6 Byte = 6 Paare Hex-Ziffern. Eindeutige Hardware-Kennung der Netzwerkkarte.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Beispiel: Byte zählen
-
-**Text:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"`
-
-| Zeichen | Byte |
-|---------|-------|
-| `Hello·` | 6 × 1 = **6 Byte** (ASCII) |
-| `🌸` | **4 Byte** (Emoji) |
-| `·` | **1 Byte** |
-| `こんにちは` | 5 × 3 = **15 Byte** (Hiragana) |
-| `·(Kon-ni-chi-wa)` | **16 Byte** (ASCII) |
-
-**Gesamt: 42 Byte für 29 sichtbare Zeichen.**
-
-<!--
-Klausurfähig: gegeben ein Text mit ASCII, Umlauten, CJK und Emoji — wie viel Byte ist das?
-
- ASCII (Hello, Klammern) = 1 Byte pro Zeichen
- Emoji 🌸 (Cherry Blossom U+1F338) = 4 Byte
- Hiragana こんにちは = 3 Byte pro Zeichen (U+3040–309F)
- は wird hier „wa" ausgesprochen (Partikel), nicht „ha"
-
-Pointe: 29 sichtbare Zeichen, 42 Byte. Zeichen ≠ Byte sobald Unicode > 127.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Magic Numbers — die Visitenkarte der Datei
-
-**Datei-Typ erkennt man an den ersten Byte:**
-
-| Format | Magic Number (Hex) | Lesbar? |
-|--------|-------------------|---------|
-| PNG | `89 50 4E 47` | (89 außerhalb ASCII) P N G |
-| JPEG | `FF D8 FF` | — |
-| PDF | `25 50 44 46` | % P D F |
-| ZIP | `50 4B 03 04` | P K — — |
-
-**Achtung:** Werte > 127 sind nicht ASCII-druckbar. *Hex-Editoren zeigen einen Punkt oder ein anderes Ersatzzeichen als Platzhalter.*
-
-<!--
- PNG nutzt absichtlich `89` (= 137 dezimal): markiert Datei eindeutig als Binär. Erkennt kaputte Übertragungen (alte Systeme schnitten Bit 7 ab).
- "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
- DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt
- Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML — reiner Text, kein binäres Format
- Sicherheitsrelevant: virus.exe → bild.jpg umbenennen täuscht nur Menschen; `file` (Linux) liest Magic Number und erkennt die echte Identität.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# KB vs KiB — warum „1 TB" als 931 GB angezeigt wird
-
-![bg right:48% contain](./assets/demos/kb-vs-kib.png)
-
-**Auf der Verpackung:** 1 TB = 10¹² Byte (dezimal).
-**Im Finder:** 931 GB = eigentlich 931 GiB (binär, 1024³).
-
-Es fehlt nichts — beide Seiten zählen nur in **verschiedenen Sprachen.**
-
-<!--
- Marketing nutzt SI-Präfixe (1000³, 1000⁴) → größere Zahlen auf der Packung.
- Betriebssysteme rechnen in Zweier-Potenzen (1024³) → kleinere angezeigte Zahl, weil Bits binär organisiert sind.
- Korrekt wären `GiB` (Gibi-, binär) und `GB` (Giga-, dezimal). Realität: beide nennen es `GB`.
-
-Rechnung: 10¹² ÷ 2³⁰ ≈ 931,3 GiB. Der Finder zeigt „931 GB".
-
-Klausurfähig: warum zeigt eine 1-TB-SSD im Finder „931 GB"? Begründung mit Rechnung.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Dateneinheiten — Größenordnungen
-
-| Einheit | Bytes (dezimal) | Beispiel |
-|---------|------:|----------|
-| **Byte** | 1 | Farbwert eines Pixels |
-| **Kilobyte (KB)** | 1.000 | kleiner Programmcode |
-| **Megabyte (MB)** | 1 Million | Textdokument |
-| **Gigabyte (GB)** | 1 Milliarde | Kinofilm in FullHD |
-| **Terabyte (TB)** | 1 Billion | ~12h Video in 4K |
-| **Petabyte (PB)** | 1 Billiarde | Netflix-Gesamtarchiv |
-| **Exabyte (EB)** | 1 Trillion | Alle E-Mails weltweit/Tag |
-| **Zettabyte (ZB)** | 1 Trilliarde | globale Datenmenge ~heute |
-
-<!--
-SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes. Auf Packungen, in Marketing.
-IEC-Präfixe (Binär): 1 KiB = 1.024 Bytes (Kibibyte). In Betriebssystemen (oft ohne i geschrieben — Verwechselung!).
-
-Eselsbrücke für die Reihenfolge:
-„**K**omm **M**it **G**roßem **T**ee, **P**eter **E**xte **Z**ettelt **Y**achten."
-→ Kilo, Mega, Giga, Tera, Peta, Exa, Zetta, Yotta.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Datenrate = Sample Rate × Bittiefe × Kanäle
-
-**Formel:**
-
-```
-Datenrate (bit/s) = Sample Rate (Hz) × Bittiefe (bit) × Kanäle
-```
-
-**Was bestimmt jeder Faktor?**
-
- **Sample Rate:** Bandbreite (Höhe der erfassbaren Töne)
- **Bittiefe:** Dynamik (Stufenfeinheit)
- **Kanäle:** Stereo, Mono, Surround
-
-Daraus ergibt sich, wie groß eine Audiodatei pro Sekunde wird — *unkomprimiert*.
-
-<!--
-Wichtige Klausur-Formel.
-
-Anwendungsbeispiel kommt nächste Folie (CD-Audio).
-
-Konsequenz: wenn ich Speicher sparen will, kann ich an einem dieser drei Parametern drehen. ABER: jede Reduktion ist hörbar.
-
-Brücke zu Kap2 (Kompression): da reduzieren wir nicht die Parameter, sondern *werfen unhörbare Information weg* — das ist Psychoakustik, nicht Container-Schrumpfung.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# CD-Audio: die Rechnung
-
-**Audio-CD (Philips/Sony 1982):**
-
-```
-44.100 Hz × 16 bit × 2 Kanäle = 1.411.200 bit/s = 1,4 Mbit/s
-```
-
-Pro Sekunde: ~172 KB. Pro Minute: ~10,3 MB. Pro Album (60 Min): ~635 MB.
-
-*Eine ganze 90er-Festplatte für ein Album.*
-
-<!--
-Diese Rechnung muss in der Klausur reproduziert werden können — Formel + Anwendung.
-
-Historischer Kontext:
- 1982: erste CD (Billy Joel – 52nd Street, Japan)
- Festplatten der 90er: 40–500 MB → ein Album füllte die ganze Platte
- 56k-Modem: 7 KB/s → 42 MB Song ≈ 100 Minuten Download
- Daraus entstand der Druck zur Audio-Kompression — die wir in Kap 2 sehen werden
-
-Spektrogramm-Folie als Anschluss: 44,1 kHz → wir können bis ~22 kHz erfassen. Mehr nicht. Warum genau 22 kHz? Weil Menschen bis ~20 kHz hören. Antwort kommt mit Nyquist.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Nyquist — warum 2× reicht
-
-![bg right:50% contain](./assets/demos/nyquist-diagram.png)
-
-**Sample-Rate ≥ *2× höchste Signal-Frequenz.***
-
-```
-f_sample ≥ 2 · f_max
-```
-
-Drei Fälle:
-
- **zu wenig** → Aliasing
- **genau** → mathematisches Minimum
- **mehr** → sichere Rekonstruktion
-
-<!--
-Harry Nyquist (1928) + Claude Shannon (1949): Sampling-Theorem.
-
-Beweis nicht klausurrelevant. Die Aussage und das visuelle Verständnis sind klausurrelevant.
-
-Konsequenz:
- 44,1 kHz Sample Rate → max. 22,05 kHz erfassbare Frequenz
- Über 22 kHz wird *physisch nicht aufgenommen* (vor dem ADC sitzt ein Tiefpassfilter, der alles über 22 kHz abschneidet — anti-aliasing filter)
- Studis hören diese hohen Frequenzen sowieso nicht (~20 kHz oben)
-
-Anschluss zur nächsten Folie: warum hat die CD genau 44,1 kHz gewählt?
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Vergleich: Lossless vs. Lossy
-
-| Eigenschaft | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
-|-------------|------------------------|--------------------------|
-| Was passiert? | Redundanz raus | Irrelevanz raus |
-| Umkehrbar? | Ja, bit-genau | Nein, nie wieder |
-| Trick | Wiederholungen kürzer kodieren | Wahrnehmung modellieren |
-| Typischer Faktor | 2× – 5× | 10× – 100× |
-| Anwendung | Archiv, Werkzeug, Code | Stream, Anzeige, Konsum |
-| Beispiele | ZIP · PNG · FLAC · RAW | MP3 · JPEG · H.264 · WebP |
-
-<!--
-Klausurfähig: gegeben ein Anwendungsfall — soll Lossless oder Lossy verwendet werden? Mit Begründung.
-
-Beispiele für Klausurfragen:
- 4K-Stream auf Netflix → Lossy (H.265 oder AV1)
- RAW-Datei aus der DSLR archivieren → Lossless (RAW selbst, ggf. ZIP)
- Lecture-Capture-Aufzeichnung für Wiederverwendung → Lossless besser, aber Datenrate hoch
- Logo-Datei für Print + Web → SVG (vektorgraphisch) oder PNG (lossless raster)
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Raster vs. Vektor
-
-| | Raster | Vektor |
-|--|--------|--------|
-| Was | Gitter aus Pixel-Werten | Mathematische Anweisungen |
-| Speicher | wächst mit Auflösung | wächst mit Komplexität |
-| Skalierung | pixelig beim Zoom | scharf bei jeder Größe |
-| Geeignet für | Fotos, Screenshots | Logos, Icons, Schrift |
-| Formate | PNG · JPEG · GIF · WebP | SVG · PDF · Schriftarten |
-
-<!--
-Klausurfähig. Geben Sie:
- ein Format zu jeder Spalte
- ein Anwendungsbeispiel zu jeder Spalte
- begründen warum Vektor bei Logos und Raster bei Fotos
-
-Trick-Frage: kann man ein Foto in SVG speichern? Theoretisch ja (mit Millionen winziger Rechtecke), praktisch nein — wird dann viel größer als JPEG.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Memo: Die 6 JPEG-Schritte
-
-| # | Schritt | Lossless / Lossy |
-|---|---------|------------------|
-| 1 | RGB → Y'CbCr (Farbraum) | Lossless |
-| 2 | Chroma-Subsampling 4:2:0 | **Lossy** |
-| 3 | 8×8 Blöcke | Lossless |
-| 4 | DCT (Frequenz-Zerlegung) | Lossless |
-| 5 | Quantisierung | **Lossy** (Haupt-Reduktion) |
-| 6 | Huffman + Zigzag + RLE | Lossless |
-
-Nur **2** der 6 Schritte verlieren Information.
-
-<!--
-Klausurfähig. Sechs Schritte. Reihenfolge wichtig. Lossy/Lossless-Status pro Schritt wichtig.
-
-Eselsbrücke: „Farb-Sub-Block-DCT-Quant-Huff" → F-S-B-D-Q-H.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Wann welches Bildformat?
-
-| Anwendung | Format | Warum |
-|-----------|--------|-------|
-| Foto im Web (Insta, News) | **JPEG** oder **WebP** | klein, Foto-optimiert |
-| Foto-Archiv (RAW) | **RAW**, **TIFF**, **DNG** | nichts verlieren |
-| Logo, Icon (skalierbar) | **SVG** | wird neu berechnet |
-| Logo als Raster | **PNG** | Transparenz + scharfe Kanten |
-| Screenshot mit Text | **PNG** | scharfe Buchstaben |
-| Animiertes Sticker | **GIF** oder **WebP** | beide animierbar |
-| Foto in höchster Modern-Qualität | **AVIF** oder **WebP** | bessere Kompression als JPEG |
-
-<!--
-Klausurfähig: gegeben ein Anwendungsfall, welches Format und warum?
-
-Sub-Frage: was schief geht, wenn ich JPEG für ein Logo nehme? → unscharfe Ränder + sichtbare Artefakte.
-
-Sub-Frage: warum nicht immer AVIF? → Browser-Support (manche ältere Browser können AVIF noch nicht), Tool-Kompatibilität, Workflow-Etablierung.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Audio-Format-Wahl
-
-| Anwendung | Format | Warum |
-|-----------|--------|-------|
-| Spotify-Stream | **AAC** oder **MP3 192+** | Kompression, breite Unterstützung |
-| Studio-Master | **WAV** oder **FLAC** | Bit-genau erhalten |
-| Sprachnachricht | **Opus** oder **AAC-LD** | für Sprache optimiert, niedrige Bitrate |
-| Podcast-Distribution | **MP3 128 kbit/s** | universelle Unterstützung |
-| HiFi-Audiophile | **FLAC** | lossless, kleiner als WAV |
-| Archiv eigener Aufnahmen | **FLAC** oder **WAV** | nichts verlieren |
-
-<!--
-Klausurfähig: gegeben ein Anwendungsfall, welches Format?
-
-Trick-Frage: warum nicht MP3 320 für Studio? → Lossless ist immer noch verlustfrei besser. Wer mastern will, braucht das.
-
-Trick-Frage 2: warum nicht WAV für Spotify? → Daten-Volumen zu hoch fürs Streaming.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-![bg fit](./assets/demos/container-vs-codec.png)
-
-<!--
-Das ist DER zentrale Missverständnis-Punkt bei Video. Studis denken oft, „MP4" oder „MKV" sei das Format des Videos. Stimmt nicht. Es ist nur die Hülle.
-
-Konkretes Beispiel: zwei `.mp4`-Dateien:
- A: H.264-Video + AAC-Audio
- B: H.265-Video + Opus-Audio
-
-Beide haben die Endung .mp4. Aber A spielt überall, B braucht moderne Player.
-
-Tool: `mediainfo <datei>` zeigt Container UND Codec.
-
-Klausurfähig.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# I, P, B — Frame-Typen
-
-| Typ | Vollname | Was drin | Größe |
-|-----|----------|----------|-------|
-| **I** | Intra-coded | Komplettes Bild (wie JPEG) | groß |
-| **P** | Predicted | „Was hat sich seit voriges I/P geändert" | mittel |
-| **B** | Bidirectional | „Was zwischen vorigem und nächstem I/P" | klein |
-
-Typische GOP: `I B B P B B P B B P B B I ...` (alle 1–3 Sekunden ein I-Frame).
-
-<!--
-Klausurfähig: was sind I/P/B-Frames? Welche ist die größte? Warum brauchen wir I-Frames trotzdem (Seeking, Stream-Start, Fehlerresistenz)?
-
-GOP = Group of Pictures.
-
-I-Frame als Seeking-Anker:
- Wenn man im Video an einer Stelle springt, kann der Player nur an I-Frames anfangen
- Zwischen I-Frames muss Player VOM letzten I-Frame ab dekodieren bis zur Spring-Stelle
-
-Daher: I-Frames sollten nicht zu selten sein (sonst langsames Seeking), aber auch nicht zu häufig (sonst weniger Kompression).
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Patent vs. Open — warum AV1?
-
-| Codec | Effizienz | Patent | Adoption (2026) |
-|-------|-----------|--------|-----------------|
-| H.264 | Baseline | Lizenz (MPEG-LA) | ~80 % aller Videos |
-| H.265 | +50 % | 3 Patent-Pools, chaotisch | nur Apple |
-| VP9 | ~H.265 | lizenzfrei (Google) | YouTube 4K |
-| **AV1** | **+30 % über H.265** | **lizenzfrei (Allianz)** | **YouTube, Netflix, Twitch** |
-
-**Die Lektion:** technisch beste Lösung gewinnt nicht. *Lizenz-klare* beste Lösung gewinnt.
-
-<!--
-Klausurfähig: warum hat AV1 H.265 abgelöst, wenn beide ähnlich effizient sind?
-
-Antwort: Patent-Politik. H.265 hat drei Patent-Pools, AV1 ist lizenzfrei. Industrie-Konsortium hat AV1 finanziert, weil sie nie wieder einem MPEG-LA-Pool ausgeliefert sein wollten.
-
-Sub-Frage: warum nicht VP9? → AV1 ist effizienter (~30 %), und alle wichtigen Player stehen dahinter (statt nur Google).
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# HDD vs. SSD
-
-![bg right:40% contain](./assets/hdd-ssd-comparison.png)
-
-| | HDD | SSD |
-|--|-----|-----|
-| Technik | Mechanik | Flash |
-| Geschwindigkeit | 50–250 MB/s | 500–14.000 MB/s |
-| Latenz | ~10 ms | ~0,1 ms |
-| Preis/TB (2026) | ~20 € | ~70 € |
-| Lebensdauer | ~5–10 Jahre | ~5–10 Jahre |
-| Geräusch | hörbar | lautlos |
-| Stoß-empfindlich | ja | nein |
-
-<!--
-HDD-Vorteile: viel Kapazität für wenig Geld. Lange archivierbar im Schrank.
-SSD-Vorteile: schnell, leise, robust. Aber teurer pro TB.
-
-Klausurfähig: gegeben ein Anwendungsfall, HDD oder SSD?
-
- Betriebssystem: SSD (schnell)
- Backup-Archiv: HDD (billig)
- Server für Foto-Speicher: HDD (Kapazität)
- Laptop (mobil): SSD (Stoß)
- Video-Bearbeitung: SSD (Throughput)
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Wann nehme ich was?
-
-| Anwendung | Empfehlung | Begründung |
-|-----------|------------|------------|
-| Betriebssystem auf dem Laptop | **NVMe-SSD** | Geschwindigkeit, Boot |
-| Eigene Foto-Library (10 TB+) | **HDD** | Kapazität, Preis |
-| Server für Logfiles | **HDD oder SSD** | je nach Schreib-Last |
-| Externes Backup-Archiv | **HDD** | billig, ok wenn langsam |
-| Mobile Workstation (Reise) | **SSD** | Stoß, Geräusch |
-| Edit-Drive für 4K-Schnitt | **NVMe-SSD** | Throughput für Video |
-| Langzeitarchiv 10+ Jahre | **LTO-Band + M-DISC** | Langlebigkeit |
-
-<!--
-Klausurfähig. Trick-Frage: warum nicht alles SSD? → Preis pro TB. Faktor 3-5× teurer.
-
-Cloud-Speicher (iCloud, Google Drive, Dropbox) ist physisch HDD/SSD/LTO in Rechenzentren — kein eigenes Medium, sondern Zugriffsmethode.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Filesystem-Landschaft
-
-| Filesystem | Wo verbreitet | Max. Dateigröße | Besonderheit |
-|-----------|---------------|----------------:|--------------|
-| **FAT32** | USB-Sticks, SD-Karten alt | **4 GB** | universell, alt |
-| **exFAT** | USB-Sticks modern | 16 EB | wie FAT, ohne 4-GB-Limit |
-| **NTFS** | Windows | 16 EB | Standard seit Win 2000 |
-| **APFS** | macOS seit 2017 | 8 EB | snapshots, schnell |
-| **ext4** | Linux | 16 TB | klassisch, robust |
-| **ZFS** | Server, FreeBSD | 16 EB | checksum, snapshots |
-
-**FAT32 4-GB-Grenze** ist der häufigste Alltags-Knack: USB-Stick noch nie umformatiert → kein 4K-Video drauf.
-
-<!--
-Klausurfähig: warum kann ich 5 GB Video nicht auf den USB-Stick ziehen? Antwort: FAT32 hat 4-GB-Dateigrößen-Limit. Lösung: USB-Stick auf exFAT umformatieren (Mac und Windows lesen/schreiben beide).
-
-Asymmetrien:
- Mac kann NTFS nur lesen, nicht schreiben (ohne Drittpartei-Treiber)
- Windows kann APFS gar nicht
- Linux kann mit Plugins fast alles
-
-Konsequenz für Studis: für Datentransfer zwischen Mac und Windows → exFAT. Für reinen Mac → APFS. Für Backup auf USB-Disk, die nur am eigenen Gerät benutzt wird → natives FS.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Die 3-2-1-Backup-Regel
-
-**3** Kopien deiner Daten
-
-**2** verschiedene **Medien** (z.B. SSD + HDD)
-
-**1** Kopie **off-site** (außerhalb deines Wohnorts)
-
-Beispiel:
-
-```
-Original  →  Foto-Library auf der MacBook-SSD
-Kopie 1   →  Time Machine auf externer HDD (zuhause)
-Kopie 2   →  Backblaze in der Cloud (off-site)
-```
-
-<!--
-Diese Regel löst drei Risiken:
- Hardware-Crash: 3 Kopien, 2 davon auf anderen Geräten
- Diebstahl/Brand: 1 Kopie off-site (Cloud oder bei Familie)
- Ransomware: off-site-Kopie schreibgeschützt oder versioniert
-
-Klausurfähig: was ist die 3-2-1-Regel? Beispiele für jede Ebene.
-
-Cloud-Backup-Anbieter (off-site Option):
- Backblaze: ~7 USD/Monat unlimited (Mac/Windows)
- iCloud / Google One / OneDrive: integriert, aber begrenzt
- Self-hosted: Synology / QNAP bei einer Person im Vertrauen
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Schnittstellen-Wahl-Matrix
-
-| Aufgabe | Beste Schnittstelle | Warum |
-|---------|---------------------|-------|
-| 4K-Monitor anschließen | **HDMI 2.0+** oder **DP 1.4+** | Bandbreite |
-| Online-Gaming | **Ethernet** | niedrige Latenz |
-| eGPU am Laptop | **Thunderbolt 3/4** | PCIe-Tunnel |
-| SD-Karte einlesen | **USB-A 3.0** oder **USB-C** | Kompatibilität |
-| Smartphone laden | **USB-C-PD** | Standard |
-| Heim-Streaming | **WiFi** oder **Ethernet** | reicht beides |
-| 4K-Stream mehrere Geräte | **Ethernet** | Stabilität |
-
-<!--
-Klausurfähig: gegeben Anwendungsfall, welche Schnittstelle und warum?
-
-Trick: warum nicht immer Thunderbolt? → Teurer Kabel, teurere Hardware. Nicht jedes Endgerät unterstützt es.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# REST: GET · POST · PUT · DELETE
-
-| Methode | Was tut sie | URL-Beispiel |
-|---------|-------------|--------------|
-| **GET** | lesen | `GET /users/42` (User mit ID 42 abfragen) |
-| **POST** | neu erstellen | `POST /users` mit Daten als Body |
-| **PUT** | überschreiben | `PUT /users/42` mit kompletten neuen Daten |
-| **PATCH** | teilweise ändern | `PATCH /users/42` mit Änderungen |
-| **DELETE** | löschen | `DELETE /users/42` |
-
-CRUD = **C**reate · **R**ead · **U**pdate · **D**elete.
-
-<!--
-Klausurfähig: welche HTTP-Methode für welche Operation?
-
-Trick-Frage: was ist der Unterschied zwischen PUT und PATCH?
- PUT: ersetzt komplett. User wird kompletter neu gesetzt.
- PATCH: ändert nur die mitgegebenen Felder. Rest bleibt.
-
-In der Praxis nehmen viele APIs PUT auch für partielle Updates — kein RFC-konforme Strenge.
-
-Werkzeuge zum Testen: curl, Postman, Hoppscotch (browser-basiert), VS-Code REST-Client-Plugin.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Der John-McAfee-GPS-Fall
-
-**Dezember 2012.** John McAfee (Antivirus-Erfinder) flieht aus Belize, wo er als Mordverdächtiger gesucht wird.
-
-**Vice Magazine** veröffentlicht ein Interview mit einem Foto: McAfee im T-Shirt, scheinbar in einer geheimen Location.
-
-**EXIF-Koordinaten im Foto:** `15.6541° N, 88.9939° W` → **Hotel Nana Lodge, Guatemala.** Bekannt.
-
-McAfee wird 36 Stunden später festgenommen.
-
-<!--
-Diese Story zeigt:
-1. Smartphones speichern GPS-Daten standardmäßig
-2. Online-Plattformen STRIPPEN diese Metadaten oft NICHT (Vice damals nicht)
-3. Wer ein Bild mit GPS hochlädt, kann seinen Aufenthaltsort verraten
-
-McAfee hat sich danach öffentlich darüber lustig gemacht ("yes that was the actual location"), aber der Fall wurde zum Lehrbuch-Beispiel für EXIF-Privacy.
-
-2026: die meisten großen Plattformen strippen EXIF (Twitter/X, Instagram, WhatsApp), aber:
- WhatsApp-Originaldatei via "Dokument" senden: behält EXIF
- E-Mail-Anhang: behält EXIF
- Direkt-Upload zu Drittpartei-Webseiten: oft mit EXIF
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Der Tony-Blair-Fall (PDF-Metadaten)
-
-**Februar 2003.** Britische Regierung veröffentlicht PDF-Dokument zur Begründung des Irakkriegs.
-
-Ein britischer Akademiker findet im **PDF-Revisionsverlauf**: das Dokument wurde aus einer studentischen Doktorarbeit von 1991 kopiert.
-
-**Plagiats-Skandal.** Plus Hinweise auf welche Mitarbeiter:innen welche Sätze überarbeitet hatten.
-
-→ **PDF-Metadaten** verraten oft mehr als der Inhalt.
-
-<!--
-PDF-Metadaten:
- Autor, Erstell-Zeit, letzte Änderung
- Software (Microsoft Word, LibreOffice, Adobe Acrobat)
- Manchmal Revision History
- Manchmal versteckter Text (z.B. weiße Schrift auf weißem Hintergrund)
-
-Sicherheitsrelevant:
- Schwärzungen werden manchmal nur als schwarzer Layer DRÜBER gelegt — Text bleibt extrahierbar
- NSA-Dokumente, FBI-Reports, US-Gerichtsdokumente: viele berühmte Beispiele für gescheiterte Schwärzungen
- Auch bei Microsoft Word: "Schwärze" via schwarzes Highlight → Text bleibt im Stream lesbar
-
-Klausurfähig: ein Beispiel für PDF-Metadaten-Privacy-Verstoß nennen + Begründung.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Vendor-Lockin als Risiko
-
-**Szenario:** Du arbeitest 5 Jahre lang mit Adobe InDesign. Dann steigt der Abo-Preis um 200 % oder Adobe ändert das Format.
-
-**Konsequenz:**
- Bestehende INDD-Dateien öffnen sich noch — aber nur in Adobe-Produkten
- Migration zu Affinity Publisher / Scribus: Daten müssen konvertiert werden, manche Details gehen verloren
- Bei einigen Formaten gibt es keine Konverter — Vendor entscheidet komplett
-
-**Schutz:** Wichtige Daten in **offenen Formaten** parallel speichern.
-
-<!--
-Klausurfähig: was ist Vendor-Lockin? Beispiel + warum problematisch?
-
-Diskussion: Open-Source-Tools sind oft "fast so gut" — manchmal sogar besser. Aber Industrie-Standards halten den Status quo.
-
-Heimlich-Lockin: auch "Bug-für-Bug-Kompatibilität". Microsoft Office hat sich in den 90ern als Standard durchgesetzt, weil Konkurrenz-Office-Suites die exakten Bugs/Quirks nicht reproduzieren konnten.
-->
@@ -205,8 +205,6 @@ Auch beteiligt: Manhattan-Projekt (Implosions-Linsen für die Atombombe). Zwiesp

 ---

-<!-- _class: klausur -->
-
 # Von-Neumann-Architektur · 5 Komponenten

 | # | Komponente | Aufgabe |
@@ -299,8 +297,6 @@ ARPANET (1969) ist die erste praktische Umsetzung. 4 Knoten anfangs: UCLA, Stanf

 ---

-<!-- _class: klausur -->
-
 # Internet-Timeline · 4 Milestones

 | Jahr | Was | Was hat es verändert |
@@ -443,8 +439,6 @@ Nichts Magisches dran. Plain-Text mit Tags drum. Studis könnten das in Notepad

 ---

-<!-- _class: klausur -->
-
 # HTML-Anatomie

 ```html
@@ -534,8 +528,6 @@ Wichtig: vergesst nicht den `alt`-Text für `<img>` — A11y.

 ---

-<!-- _class: klausur -->
-
 # Document-Struktur: das Grundgerüst

 ```html
@@ -585,8 +577,6 @@ Faustregel: alles, was den Inhalt der Seite betrifft → body. Alles, was die Se

 ---

-<!-- _class: klausur -->
-
 # Semantische HTML-Tags

 | Tag | Bedeutung | Beispiel |
@@ -90,8 +90,6 @@ Jede Folie bedient mindestens eines der Klausur-Lernziele C/D/E/F.

 ---

-<!-- _class: klausur -->
-
 # Drei Adressen — IP · MAC · Port

 | Adresse | Identifiziert | Beispiel |
@@ -199,8 +197,6 @@ Pro Antwort weiter unten ist der Fehler eingegrenzt.

 ---

-<!-- _class: klausur -->
-
 # TCP/IP · 4 Schichten

 | # | Schicht | Aufgabe | Beispiel-Protokolle | Dateneinheit |
@@ -246,8 +242,6 @@ Sehr wichtig: jede Schicht sieht nur ihren eigenen Header — sie kann den Inhal

 ---

-<!-- _class: klausur -->
-
 # Encapsulation — Datenüberbringung

 ```
@@ -381,8 +375,6 @@ Jetzt: was geht ÜBER die Verbindung? Bei einer Webseite: HTTP-Requests.

 ---

-<!-- _class: klausur -->
-
 # HTTP-Request — was geschickt wird

 ```http
@@ -421,8 +413,6 @@ Wichtige Header:

 ---

-<!-- _class: klausur -->
-
 # HTTP-Response — was zurückkommt

 ```http
@@ -456,8 +446,6 @@ Status-Code ist die wichtigste Zeile. Drei Stellen, erste Stelle gibt grobe Kate

 ---

-<!-- _class: klausur -->
-
 # Statuscodes — die wichtigsten

 | Code | Name | Bedeutung |
@@ -629,8 +617,6 @@ Standard: External in style.css.

 ---

-<!-- _class: klausur -->
-
 # CSS-Selektoren

 | Selektor | Was |
@@ -683,8 +669,6 @@ Faustregel: nur so spezifisch wie nötig. „nav > a" ist klar (Links in Hauptna

 ---

-<!-- _class: klausur -->
-
 # Spezifizität — wer gewinnt?

 Wenn mehrere CSS-Regeln auf das gleiche Element zutreffen: **die spezifischste gewinnt.**
@@ -750,8 +734,6 @@ Heute Best-Practice: `* { box-sizing: border-box; }` global setzen.

 ---

-<!-- _class: klausur -->
-
 # Box-Model

 ```
@@ -808,8 +790,6 @@ Klausur (H.4): Flexbox vs Grid unterscheiden — wann was?

 ---

-<!-- _class: klausur -->
-
 # Flexbox vs Grid

 | | Flexbox | Grid |
@@ -886,8 +866,6 @@ Für Studis besonders relevant:

 ---

-<!-- _class: klausur -->
-
 # BFSG + EAA — was kommt am 28.06.2025?

 **Barrierefreiheitsstärkungsgesetz (BFSG)** — DE-Gesetz, setzt **European Accessibility Act (EAA)** um.
@@ -916,8 +894,6 @@ EU hat das mit EAA 2019 beschlossen. DE setzt es mit BFSG 2021 in nationales Rec

 ---

-<!-- _class: klausur -->
-
 # WCAG · 4 Prinzipien (POUR)

 | Prinzip | Bedeutung | Beispiel |
@@ -95,597 +95,3 @@ Hochschule der Medien Stuttgart
 **Sommersemester 2026**

 [https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Von-Neumann-Architektur · 5 Komponenten
-
-| # | Komponente | Aufgabe |
-|---|------------|---------|
-| 1 | **Steuerwerk** (Control Unit) | holt Befehl, entscheidet was zu tun ist |
-| 2 | **Rechenwerk** (ALU) | führt Rechnung / Vergleich aus |
-| 3 | **Speicher** (Memory) | hält Daten *und* Programm |
-| 4 | **Eingabe / Ausgabe** (I/O) | Tastatur, Bildschirm, Netzwerk |
-| 5 | **Bus** (Verbindung) | transportiert Daten zwischen allen |
-
-**Schlüssel:** Speicher hält *beides* — Daten + Programm. (Stored Program.)
-
-<!--
-Klausurfähig: die 5 Komponenten und ihre Aufgaben benennen.
-
-Wo seht ihr das in eurem eigenen Gerät?
- Steuerwerk + Rechenwerk = CPU
- Speicher = RAM (flüchtig) + SSD (persistent)
- I/O = USB-Ports, Display, Audio
- Bus = im Chip (Intern), zwischen Chips (PCIe, USB)
-
-Die Architektur ist seit 1945 stabil. Quantencomputer brechen sie auf (kein klassisches stored program). Aber jeder PC, Mac, Smartphone, jeder Server, jede Spielkonsole folgt ihr noch immer.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Internet-Timeline · 4 Milestones
-
-| Jahr | Was | Was hat es verändert |
-|------|-----|----------------------|
-| **1969** | ARPANET | Erstes paket-vermitteltes Netzwerk, 4 Knoten |
-| **1971** | Email (Ray Tomlinson) | Erste Nutzung des `@`-Zeichens |
-| **1983** | TCP/IP | Wurde Standard-Protokoll des ARPANET |
-| **1989** | **WWW** (Berners-Lee, CERN) | HTML, HTTP, URL — das Web wie wir es kennen |
-
-1993: Mosaic-Browser → Internet wird *populär*.
-
-<!--
-Klausurfähig: die 4 Meilensteine und ihre Bedeutung.
-
-Anmerkungen:
- 1969 ARPANET: noch militärisch + Forschung. Wenige Knoten.
- 1971 Email: Ray Tomlinson schickt die erste E-Mail mit @-Zeichen, das er gewählt hat um „User AT Maschine" zu trennen. Heute auf jedem Tastatur als Standard.
- 1983 TCP/IP: Vint Cerf + Bob Kahn. ARPANET wechselt am 1. Jan 1983 von NCP zu TCP/IP. Das ist die „Geburt des modernen Internets" im technischen Sinne.
- 1989 WWW: Tim Berners-Lee am CERN. Er erfindet HTTP (Protokoll), HTML (Markup) und URL (Adress-System) — drei Standards, eine Person.
- 1993 Mosaic: erste GUI-Browser, der Bilder im Text-Fluss anzeigen konnte. Damit explodierte die Web-Nutzung.
-
-Internet ist nicht Web — Internet ist das Netzwerk, Web ist eine Anwendung darauf. Aber im Volksmund verwechselt.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# HTML-Anatomie
-
-```html
-<a href="https://librete.ch">Mein Link</a>
-```
-
-| Bestandteil | Was |
-|-------------|-----|
-| `<a` | **Opening-Tag** mit Tag-Namen |
-| `href="https://..."` | **Attribut** (Name + Wert) |
-| `>` | Ende des Opening-Tags |
-| `Mein Link` | **Inhalt** des Elements |
-| `</a>` | **Closing-Tag** |
-
-Alles zusammen = ein **Element.**
-
-<!--
-Klausurfähig. Studis sollen die Bestandteile eines HTML-Elements unterscheiden können:
- Opening-Tag
- Closing-Tag
- Attribute (Name=Wert)
- Inhalt
- Element = alles zusammen
-
-Achtung: einige Tags sind „self-closing" und haben keinen Closing-Tag:
- `<img src="..." alt="...">`
- `<br>`
- `<input>`
- `<meta>`
-
-Diese werden auf der nächsten Folie behandelt.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Document-Struktur: das Grundgerüst
-
-```html
-<!DOCTYPE html>
-<html lang="de">
-<head>
-  <meta charset="UTF-8">
-  <meta name="viewport" content="width=device-width, initial-scale=1">
-  <title>Meine Seite</title>
-  <link rel="stylesheet" href="style.css">
-</head>
-<body>
-  <h1>Hallo Welt</h1>
-  <!-- alle sichtbaren Inhalte -->
-</body>
-</html>
-```
-
-<!--
-Klausurfähig: die DOCTYPE + head + body-Struktur reproduzieren können.
-
-Was passiert wo?
- DOCTYPE: sagt dem Browser „das ist HTML5". Ohne DOCTYPE: Quirks-Mode (alte Browser-Verhaltensweisen).
- html-Element + lang: Wurzel-Element + Sprache
- head: alles, was *nicht* sichtbar ist (Meta, Title, CSS-Links, Scripts)
- meta charset: sagt Browser, wie die Byte zu interpretieren sind (UTF-8 = international, alle Sprachen)
- meta viewport: für Mobile-Rendering, ohne zoomt iPhone alles auf 980px
- title: Browser-Tab-Titel + Lesezeichen-Name
- link stylesheet: CSS einbinden
- body: alle sichtbaren Inhalte
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Semantische HTML-Tags
-
-| Tag | Bedeutung | Beispiel |
-|-----|-----------|----------|
-| `<header>` | Kopfbereich (Logo, Nav) | oben auf der Seite |
-| `<nav>` | Navigations-Menü | Hauptmenü |
-| `<main>` | Hauptinhalt | das eigentliche Thema |
-| `<section>` | Thematischer Abschnitt | Kapitel der Seite |
-| `<article>` | eigenständiger Inhalt | Blog-Post, News-Beitrag |
-| `<aside>` | Seiten-Inhalt | Sidebar, Werbung |
-| `<footer>` | Fußbereich | Impressum, Copyright |
-
-**Vorteil:** Screen-Reader, Suchmaschinen + andere Entwickler verstehen die Struktur.
-
-<!--
-Klausurfähig: die 7 semantischen Tags und ihre Bedeutung.
-
-Vor HTML5 (2008) gab es nur `<div>`. Man hat alles in div verpackt und mit Klassen markiert: `<div class="header">`. Funktioniert visuell — aber Maschinen (Screen-Reader, Suchmaschinen) verstehen nichts.
-
-Mit semantischen Tags:
- Screen-Reader kann „Hauptnavigation überspringen" anbieten
- Google versteht, was Haupt-Inhalt der Seite ist (SEO-Boost)
- Andere Entwickler lesen den Code schneller
-
-Faustregel: wenn ein Tag den *Zweck* eines Bereichs ausdrückt — semantisch. Wenn nur Styling — div.
-
-Drei A11y-relevante Anti-Patterns:
- `<div onclick="...">` statt `<button>` (Tastatur nicht erreichbar)
- `<a href="javascript:void(0)">` statt `<button>` (semantisch falsch)
- alles in `<div>` (keine Hierarchie für Screen-Reader)
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Drei Adressen — IP · MAC · Port
-
-| Adresse | Identifiziert | Beispiel |
-|---------|---------------|----------|
-| **IP** | das **Endgerät** (welt-eindeutig) | `192.168.1.42` (v4) · `2001:db8::1` (v6) |
-| **MAC** | die **Netzwerk-Karte** (lokal eindeutig) | `00:1A:2B:3C:4D:5E` (6 Byte hex) |
-| **Port** | das **Programm** auf dem Gerät | `80` (HTTP) · `443` (HTTPS) · `22` (SSH) |
-
-**Drei Schichten, drei Fragen.** „Welcher Computer?" → IP. „Welches Kabel/WLAN?" → MAC. „Welches Programm?" → Port.
-
-<!--
-Klausurfähig (Block D).
-
-Konkretes Beispiel:
- `localhost:8080` = IP 127.0.0.1 (eigene Maschine) + Port 8080 (typisch für lokale Dev-Server)
- `git.librete.ch:41240` = IP von librete.ch + Port 41240 (SSH-Custom-Port)
- `8.8.8.8:53` = Google's DNS-Server + Port 53 (DNS)
-
-MAC ist die niedrigste Adress-Ebene — wird nur im lokalen Netz benutzt. Sobald ein Paket den Router verlässt, wird die MAC ausgetauscht (nächster Hop).
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# TCP/IP · 4 Schichten
-
-| # | Schicht | Aufgabe | Beispiel-Protokolle | Dateneinheit |
-|---|---------|---------|---------------------|--------------|
-| 1 | **Network Access** | Bits auf Kabel/WLAN | Ethernet · WiFi | Frame |
-| 2 | **Internet** | Routing über mehrere Hops | **IP** · ICMP | Packet |
-| 3 | **Transport** | Verbindung + Zuverlässigkeit | **TCP** · UDP | Segment |
-| 4 | **Application** | Anwendungs-Logik | **HTTP** · DNS · SMTP | Data |
-
-Schichten von unten nach oben. Jede höhere Schicht **nutzt** die darunter.
-
-<!--
-Klausurfähig (Block C). Studis sollen die 4 Schichten benennen + ein Protokoll pro Schicht zuordnen + die Dateneinheit pro Schicht.
-
-Wichtige Protokolle:
- Schicht 1: Ethernet (Kabel), WiFi 802.11 (Funk), Bluetooth
- Schicht 2: IP v4/v6, ICMP (Ping), ARP (IP→MAC-Auflösung)
- Schicht 3: TCP (zuverlässig, mit Handshake), UDP (schnell, ohne Garantien)
- Schicht 4: HTTP/HTTPS, DNS, SMTP/IMAP/POP3, SSH, FTP, MQTT
-
-Faustregel: jeder Buchstabe in einem URL-Schema sagt was über Schicht 4 (HTTP, FTP, MQTT, …).
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Encapsulation — Datenüberbringung
-
-```
-[Application Data]
-        ↓ + TCP-Header
-[Segment]
-        ↓ + IP-Header
-[Packet]
-        ↓ + Ethernet-Header + Trailer
-[Frame]
-        ↓ als Bits auf das Kabel/WLAN
-```
-
-Beim Empfänger: **umgekehrte Reihenfolge.**
-
-<!--
-Klausurfähig (Block C.2, C.3).
-
-Diese Verschachtelung ist nicht zufällig — sie ist die direkte Folge der Schichten-Architektur. Jede Schicht braucht eigene Adressierung + eigene Kontrolldaten → eigener Header.
-
-Konsequenz: ein HTTP-Request hat in der Realität wesentlich mehr „Overhead" als nur die HTTP-Daten:
- Ethernet-Header: 14 Byte
- IP-Header: 20 Byte (v4) oder 40 Byte (v6)
- TCP-Header: 20 Byte (oft mit Optionen mehr)
- + HTTP-Header: typisch 200-1000 Byte
- Bei kleinem HTTP-Body: Overhead > Payload
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# HTTP-Request — was geschickt wird
-
-```http
-GET /index.html HTTP/1.1
-Host: librete.ch
-User-Agent: Mozilla/5.0 (Macintosh; …)
-Accept: text/html,application/xhtml+xml
-Accept-Language: de-DE,en-US;q=0.9
-Connection: keep-alive
-```
-
-| Bestandteil | Was |
-|-------------|-----|
-| `GET` | **Method** — was tun wir |
-| `/index.html` | **Path** — was wollen wir |
-| `HTTP/1.1` | **Version** |
-| `Host: …` | **Header** (mehrere möglich) |
-
-<!--
-Klausurfähig (Block E.2). Studis sollen einen HTTP-Request lesen können.
-
-Wichtige Methods:
- GET: lesen (idempotent — gleiche Anfrage gibt gleiche Antwort)
- POST: erstellen / Daten senden
- PUT: ersetzen
- DELETE: löschen
- HEAD: nur Header holen (z.B. um Datei-Größe zu prüfen ohne Download)
-
-Wichtige Header:
- Host: welche Website auf dem Server (mehrere Sites pro Server möglich)
- User-Agent: Browser-Identifikation
- Accept: welche Content-Types die App verarbeiten kann
- Cookie: Session-Identifikation
- Authorization: Login-Token
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# HTTP-Response — was zurückkommt
-
-```http
-HTTP/1.1 200 OK
-Content-Type: text/html; charset=utf-8
-Content-Length: 1234
-Cache-Control: max-age=3600
-Server: nginx/1.24
-
-<!DOCTYPE html>
-<html>...
-```
-
-| Bestandteil | Was |
-|-------------|-----|
-| `200 OK` | **Statuscode + Message** |
-| `Content-Type: …` | **Header** mit Meta-Information |
-| (leere Zeile) | trennt Header von Body |
-| `<!DOCTYPE …` | **Body** (eigentlicher Inhalt) |
-
-<!--
-Klausurfähig (Block E.2).
-
-Status-Code ist die wichtigste Zeile. Drei Stellen, erste Stelle gibt grobe Kategorie:
- 1xx: Informational (Hinweise)
- 2xx: Success (alles ok)
- 3xx: Redirect (woanders gucken)
- 4xx: Client Error (du hast Mist gebaut)
- 5xx: Server Error (Server hat Mist gebaut)
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Statuscodes — die wichtigsten
-
-| Code | Name | Bedeutung |
-|------|------|-----------|
-| **200** | OK | alles gut, hier dein Inhalt |
-| **301** | Moved Permanently | Seite ist umgezogen, hier neue URL |
-| **302** | Found | temporäre Weiterleitung |
-| **400** | Bad Request | deine Anfrage war kaputt |
-| **401** | Unauthorized | du musst dich einloggen |
-| **403** | Forbidden | eingeloggt aber nicht berechtigt |
-| **404** | Not Found | gibt's nicht |
-| **500** | Internal Server Error | Server hat Bug |
-| **503** | Service Unavailable | Server überlastet / down |
-
-<!--
-Klausurfähig (Block E.3): mindestens 200, 301, 404, 500 mit Bedeutung.
-
-Memo:
- 200 = "OK" — alltäglich erfolgreich
- 301 = permanenter Umzug (Cache-fähig, SEO-Geschichte)
- 404 = klassisch — Endbenutzer kennt sie
- 500 = Server crasht
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# CSS-Selektoren
-
-| Selektor | Was |
-|----------|-----|
-| `p` | alle `<p>`-Elemente |
-| `.btn` | alle Elemente mit `class="btn"` |
-| `#header` | das Element mit `id="header"` (nur EINS pro Seite) |
-| `*` | alle Elemente |
-| `button:hover` | Button beim Hover |
-| `button:focus` | Button mit Tastatur-Fokus |
-| `input:disabled` | deaktivierte Inputs |
-| `nav > a` | alle `<a>` direkt unter `<nav>` |
-| `h1 + p` | erstes `<p>` direkt nach einem `<h1>` |
-
-<!--
-Klausurfähig (Block H.2).
-
-Grundtypen:
- Element-Selektor: `p`
- Klassen-Selektor: `.btn` (kann mehrfach vorkommen)
- ID-Selektor: `#header` (einmalig pro Seite!)
- Universal-Selektor: `*`
-
-Pseudo-Klassen (Element in einem bestimmten Zustand):
- :hover, :focus, :active
- :first-child, :last-child, :nth-child(2n)
- :disabled, :checked, :required
-
-Kombinatoren:
- a > b: b ist direktes Kind von a
- a b: b ist irgendwo unter a (Descendant)
- a + b: b ist direkter Geschwister-NACHFOLGER von a
- a ~ b: b ist Geschwister von a (irgendwo nach)
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Spezifizität — wer gewinnt?
-
-Wenn mehrere CSS-Regeln auf das gleiche Element zutreffen: **die spezifischste gewinnt.**
-
-| Selektor-Typ | Spezifizität |
-|--------------|-------------:|
-| Inline `style="..."` | 1000 |
-| ID `#header` | 100 |
-| Klasse `.btn`, Attribut `[type=text]`, Pseudo `:hover` | 10 |
-| Element `p`, Pseudo-Element `::before` | 1 |
-| `*` | 0 |
-
-Bei Gleichstand: **letzte Regel** im CSS gewinnt.
-
-<!--
-Klausurfähig (Block H.3).
-
-Konkretes Beispiel:
-```css
-p { color: blue; }           /* Spezifizität: 1 */
-.notice { color: red; }      /* Spezifizität: 10 */
-#warn { color: green; }      /* Spezifizität: 100 */
-```
-
-Wenn ein `<p id="warn" class="notice">Hi</p>` definiert ist:
- Welche Farbe? Grün, weil #warn (100) > .notice (10) > p (1).
-
-`!important` umgeht die Regel — sollte vermieden werden (macht Refactoring schwer).
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Box-Model
-
-```
-+------------------------+
-|        margin          |
-|  +------------------+  |
-|  |     border       |  |
-|  | +--------------+ |  |
-|  | |   padding    | |  |
-|  | | +----------+ | |  |
-|  | | | content  | | |  |
-|  | | +----------+ | |  |
-|  | +--------------+ |  |
-|  +------------------+  |
-+------------------------+
-```
-
-`box-sizing: border-box;` ist Best Practice — `width` inkludiert dann Padding + Border.
-
-<!--
-Klausurfähig (Block H.1).
-
-Studis sollen das Box-Model malen können + erklären, was content/padding/border/margin ist + Bedeutung von `box-sizing: border-box`.
-
-Tip: in DevTools, beim Inspector wird die Box-Model-Visualisierung neben dem Element angezeigt — beste Lern-Methode.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Flexbox vs Grid
-
-| | Flexbox | Grid |
-|--|---------|------|
-| Dimensions | **1D** (Reihe ODER Spalte) | **2D** (Reihe UND Spalte) |
-| Geeignet für | Navigation, Karten-Liste, Button-Gruppe | Seiten-Layout, komplexe Raster |
-| Container-CSS | `display: flex` | `display: grid` |
-| Reihen-Richtung | `flex-direction` | `grid-template-rows` |
-| Spalten-Richtung | (durch flex-direction) | `grid-template-columns` |
-
-**Faustregel:** Brauchst du nur eine Richtung? Flex. Beide? Grid.
-
-<!--
-Klausurfähig (Block H.4 konzeptionell, nicht Code).
-
-Konkrete Beispiele:
- Header-Navigation mit Logo links + Links rechts → Flexbox (1D Horizontal)
- Foto-Galerie mit gleichmäßigen Karten → Grid (2D, fixe Spalten)
- Sidebar + Hauptinhalt + Footer-Layout → Grid (ganze Seite)
- Button mit Icon links + Text rechts → Flexbox
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# BFSG + EAA — was kommt am 28.06.2025?
-
-**Barrierefreiheitsstärkungsgesetz (BFSG)** — DE-Gesetz, setzt **European Accessibility Act (EAA)** um.
-
-**Pflicht für:**
- Online-Shops, Buchungssysteme
- Banken, Versicherungen
- E-Books, E-Reader
- Smartphone-Apps mit kommerziellem Bezug
-
-**Ausnahmen:** Unternehmen < 10 Mitarbeiter + < 2 Mio € Umsatz.
-
-Verstöße: bis **100 000 €** Bußgeld + Klagerecht durch Behindertenverbände.
-
-<!--
-Klausurfähig (Block I.1). Studis sollen kennen:
- BFSG / EAA als Gesetz/Richtlinie
- Datum 28.06.2025
- Wer betroffen ist
- Strafrahmen
-
-Hintergrund: ~10% der Bevölkerung haben relevante Behinderungen (Sehen, Hören, Motorik, kognitiv). Die meisten Websites sind nicht barrierefrei → diese Menschen werden ausgeschlossen.
-
-EU hat das mit EAA 2019 beschlossen. DE setzt es mit BFSG 2021 in nationales Recht. Übergangsfrist endet 28.06.2025.
-->
-
-
---
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# WCAG · 4 Prinzipien (POUR)
-
-| Prinzip | Bedeutung | Beispiel |
-|---------|-----------|----------|
-| **P**erceivable | wahrnehmbar | Alt-Text für Bilder, Untertitel für Video |
-| **O**perable | bedienbar | Keyboard-Navigation, Skip-Links |
-| **U**nderstandable | verständlich | Lese-Niveau, klare Fehlermeldungen |
-| **R**obust | robust gegenüber Tech | semantisches HTML, Standards-konform |
-
-**WCAG 2.1 Level AA** ist meist Mindest-Anforderung.
-
-<!--
-Klausurfähig (Block I.2). Die 4 POUR-Prinzipien benennen können.
-
-WCAG = Web Content Accessibility Guidelines, vom W3C.
- WCAG 1.0 (1999), 2.0 (2008), 2.1 (2018), 2.2 (2023)
- Drei Stufen: A (Minimum), AA (Standard), AAA (höchste)
- BFSG verlangt Level AA
-
-Konkrete WCAG-Kriterien (Beispiele):
- 1.1.1 Non-text Content: Alt-Text für alle Bilder
- 1.4.3 Contrast (Minimum): Kontrast 4.5:1 für Text
- 2.1.1 Keyboard: alle Funktionen mit Tastatur erreichbar
- 2.4.7 Focus Visible: Fokus-Indikator sichtbar
- 3.3.1 Error Identification: Fehler klar markieren
- 4.1.2 Name, Role, Value: ARIA korrekt einsetzen
-->