---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
<style>
:root {
  --color-foreground: #1a1a2e;
  --color-highlight: #1e5f8a;
  --color-dimmed: #4a4a6a;
}
section.invert {
  --color-foreground: #fff;
}
section {
  font-size: 1.7rem;
}
h1 {
  color: #1e5f8a;
}
section.invert h1 {
  color: #fff;
}
h2 {
  color: #1f2937;
}
pre {
  background: #0f0f23;
  color: #5fb3e4;
  border-radius: 8px;
  border-left: 3px solid #1e5f8a;
}
pre code {
  background: transparent;
  color: inherit;
}
code {
  background: #0f0f23;
  padding: 0.15em 0.4em;
  border-radius: 4px;
  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
}
section code:not(.hljs) { color: #5fb3e4 !important; }
section code.hljs { color: #f8f8f8 !important; }
a {
  color: var(--color-highlight);
}
section.klausur {
  background: repeating-linear-gradient(
    135deg,
    #e3f2fd,
    #e3f2fd 40px,
    #fff 40px,
    #fff 80px
  ) !important;
}
@media print {
  section.klausur {
    background: #e3f2fd !important;
  }
}
section.aufgabe {
  background: #e3f2fd !important;
}
section.aufgabe footer {
  display: none;
}
</style>

<!--
  ╔═══════════════════════════════════════════════════════════════════╗
  ║  AUTO-GENERATED FILE - DO NOT EDIT MANUALLY                       ║
  ║                                                                   ║
  ║  This file is generated by: make klausur                          ║
  ║  Source: scripts/extract-klausur.sh                               ║
  ║                                                                   ║
  ║  To update, edit the source slides and re-run make klausur        ║
  ╚═══════════════════════════════════════════════════════════════════╝
-->

<!-- _class: invert -->
<!-- _header: '' -->
<!-- _backgroundColor: #000 -->

![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)

# Dateiformate, Schnittstellen, Speichermedien & Distributionswege

**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
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 `.` 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-Theorem — warum 2× reicht

![bg right:50% contain](./assets/demos/nyquist-diagram.png)

**Sample-Rate muss mindestens das *Doppelte* der höchsten Signal-Frequenz sein:**

```
f_sample ≥ 2 · f_max
```

Drei Fälle:
- **zu wenig** → Aliasing (falsche tiefere Welle)
- **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: "" -->


# Container ≠ Codec

![bg right:40% contain](./assets/container-codec-diagram.png)

**Container** = die *Verpackung*: hält Video-Spur, Audio-Spur, Untertitel, Metadaten zusammen.
*Beispiele:* MP4, MKV, WebM, AVI

**Codec** = der *Komprimierer*: wie wird Bild/Audio gespeichert?
*Beispiele:* H.264, H.265, AV1, VP9 (Video) · AAC, MP3, Opus (Audio)

**Eine `.mp4`-Datei kann verschiedene Codecs enthalten.**

<!--
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.
-->