diff --git a/slides/223015b/04-distribution-apis-zukunft.md b/slides/223015b/04-distribution-apis-zukunft.md
index 35617e9..e96cc34 100644
--- a/slides/223015b/04-distribution-apis-zukunft.md
+++ b/slides/223015b/04-distribution-apis-zukunft.md
@@ -5,7 +5,7 @@ paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
-title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+title: Speicher und Schnittstellen
---
-
-
-
-
+
-
+# Kapitel 4
+## Speicher und Schnittstellen
-# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
---
-
-
----
-
-
-
-# Kapitel 4 – 30.01.2026
-## Distribution, APIs & Zukunft
-
----
-
-
-
-
-
----
-
-# Das Problem: Daten müssen reisen
-
-**Szenario:** 100 TB von Berlin nach München
-
-**Option 1: Internet-Upload**
-- 1 Gbps Uplink = 125 MB/s
-- Zeit: **9,3 Tage** (non-stop!)
-
-**Option 2: Festplatte per Post**
-- 10× 10TB HDDs (~2.000€)
-- Kopieren: ~10 Stunden
-- Versand: 1-2 Tage
-- Gesamt: **~3 Tage**
-
-*"Never underestimate the bandwidth of a station wagon full of tapes."* — Andrew Tanenbaum (1981)
-
-
-
----
-
-
-
-
-
----
-
-# AWS Snowball
-
-**AWS Snowball (seit 2015):**
-
-**Problem:** Petabytes on-premise → AWS-Cloud
-
-**Geräte:**
-- Snowball Edge: 100 TB
-- **Snowmobile:** 100 PB (Container auf LKW!)
-
-**Prozess:**
-1. AWS schickt verschlüsseltes Gerät
-2. KundIn kopiert Daten lokal (schnell!)
-3. Gerät zurück an AWS
-4. AWS lädt in S3 hoch
-
-**Kosten:** Günstiger als Internet-Transfer bei >10 TB
-
-
-
----
-
-
-
-
-
----
-
-# Physische Distribution
-
-**CD (1982):** 700 MB
-**DVD (1995):** 4,7 GB / 8,5 GB
-**Blu-ray (2006):** 25 GB / 50 GB / 100 GB
-
-**Problem heute:**
-- Games: 50-150 GB (Call of Duty: 200+ GB!)
-- Filme: Streaming überholt Blu-ray
-- Disc = "License Key", Rest wird geladen
-
-
-
----
-
-
-
-
-
----
-
-# Zentralisierte Distribution
-
-**Klassisches Modell:** Ein Server, viele Clients
-
-**Problem:**
-1 Million Nutzende wollen 1 GB-Datei
-→ Server braucht **1 PB Bandbreite!**
-→ Server überlastet → **"Hug of Death"**
-
-**Lösung:** Content Delivery Networks (CDNs)
-
-
-
----
-
-
-
-
-
----
-
-# CDNs: Content Delivery Networks
-
-**CDN = Verteiltes Netzwerk weltweit**
-
-**Funktionsweise:**
-1. **Origin Server** (Hauptquelle)
-2. **Edge Servers** (geografisch verteilt)
-3. Nutzende → nächster Edge Server
-4. Erste Anfrage: Edge holt von Origin, cached
-5. Weitere Anfragen: Direkt vom Edge (schnell!)
-
-**Vorteile:**
-✓ Reduzierte Latenz (geografische Nähe)
-✓ Last-Verteilung
-✓ Bandbreitenersparnis
-
-
-
----
-
-# CDN-Strategien
-
-**Static Content:**
-- Bilder, CSS, JS, Videos
-- Lange Cache-Zeit (TTL: Tage/Wochen)
-
-**Dynamic Content:**
-- Nutzungs-spezifisch (Profil)
-- Kurze TTL oder nicht cachebar
-
-**Cache Invalidation:**
-- Versioning (`style.css` → `style.v2.css`)
-- Cache-Purge (manuell leeren)
-
-*"There are only two hard things in Computer Science: cache invalidation and naming things."* — Phil Karlton
-
-
-
----
-
-
-
-
-
----
-
-# Netflix: Fallstudie CDN
-
-**Netflix Open Connect (eigenes CDN):**
-
-**Strategie:**
-- Server IN ISP-Rechenzentren (Telekom, Vodafone...)
-- Popular Content vorgeladen (Predictive Caching)
-- **95%+ Traffic vom lokalen ISP-Server**
-
-**Zahlen (2024):**
-- 200M+ Subscriber
-- ~15% des globalen Internet-Traffics!
-- Ohne CDN: Unmöglich
-
-
-
----
-
-
-
-
-
----
-
-# P2P: Peer-to-Peer
-
-**P2P = Jeder ist Client UND Server**
-
-**Philosophie:** Dezentralisierung
-
-**Anwendungen:**
-- BitTorrent (File-Sharing)
-- IPFS (InterPlanetary File System)
-- Blockchain (Bitcoin, Ethereum)
-
-**Vorteil:** Skalierbar (mehr Nutzende = mehr Bandbreite!)
-
-**Nachteil:** Langsam bei wenigen Peers, oft für Piraterie missbraucht
-
-
-
----
-
-
-
-
-
----
-
-# BitTorrent: Wie funktioniert's?
-
-**BitTorrent (Bram Cohen, 2001):**
-
-**Komponenten:**
-1. **.torrent-Datei:** Metadaten (Hashes, Tracker-URL)
-2. **Tracker:** Vermittelt Peers
-3. **Seeders:** Haben komplette Datei
-4. **Leechers:** Laden noch
-5. **Swarm:** Alle Peers zusammen
-
-**Mechanismus:**
-- Datei in Chunks (z.B. 256 KB)
-- Jeder Peer lädt von verschiedenen Peers
-- "Tit-for-tat": Wer uploaded, lädt schneller
-
-
-
----
-
-
-
-
-
----
-
-# BitTorrent & Piraterie
-
-**2000er:** Musik-/Film-Piraterie-Revolution
-
-**Napster (1999-2001):** Zentralisiert → Verklagt, Shutdown
-
-**BitTorrent (2001+):** Dezentral → Schwerer zu verklagen
-
-**The Pirate Bay (2003):** BitTorrent-Index
-- Blockiert, zieht um, neue Domains
-- **Whack-a-Mole-Spiel**
-
-**Rechtliche Grauzone:**
-- Protokoll selbst: Legal
-- Inhalte: Oft illegal (Urheberrecht)
-- Legitime Uses: Linux-ISOs, Open-Source, Public Domain
-
-
-
----
-
-
-
-
-
----
-
-# IPFS: Dezentrales Web?
-
-**IPFS = InterPlanetary File System (2015)**
-
-**Vision:** Web ohne Server
-
-**Funktionsweise:**
-- **Content-Addressable:** Dateien durch Hash identifiziert
-- **CID:** Content Identifier (`QmXyZ123...`)
-- Datei auf vielen Knoten (wie BitTorrent, aber persistent)
-- Abruf: "Gib mir Datei mit Hash X" (egal wo)
-
-**Vorteile:** Zensur-resistent, kein Single Point of Failure
-
-**Nachteile:** Langsam (noch), keine Verfügbarkeitsgarantie
-
-**Anwendung:** NFT-Speicher
-
-
-
----
-
-
-
-
-
----
-
-# Streaming: Real-Time-Distribution
-
-**Streaming = Daten während Empfang konsumiert**
-
-**Protokolle:**
-- **HLS** (Apple): HTTP-basiert, Segmente
-- **MPEG-DASH:** Standard, ähnlich HLS
-- **WebRTC:** Browser-zu-Browser, niedrige Latenz
-
-**Adaptive Bitrate:**
-- Stream in mehreren Qualitäten (240p-4K)
-- Player wechselt dynamisch
-- Segmente: 2-10 Sekunden
-
-**Latenz:**
-- Traditional (HLS): 10-30 Sekunden
-- Low-Latency HLS: 2-5 Sekunden
-- WebRTC: <1 Sekunde (Videocalls)
-
-
-
----
-
-# Hands-On: Torrent & CDN
-
-**Aufgabe (40 Min):**
-
-**Teil 1: BitTorrent (20 Min)**
-1. Lade legalen Torrent (Linux-ISO: ubuntu.com)
-2. Tool: qBittorrent oder Transmission
-3. Beobachte: Peers, Seeders, Download-Speed, Upload-Speed
-
-**Teil 2: CDN-Analyse (20 Min)**
-1. Öffne populäre Website (z.B. nytimes.com)
-2. Browser DevTools → Network-Tab
-3. Schaue auf Requests: Welche CDN-Domains?
-4. Response-Headers: `X-Cache`, `CF-Ray`, etc.
-
-**Tools:** cdn77.com/cdn-check
-
-
+
---
-# Dateitransfer-Protokolle
+
-**FTP (File Transfer Protocol, 1971):**
-- Ältestes Internet-Protokoll für Dateitransfer
-- ⚠️ Unverschlüsselt! (Passwort im Klartext)
-- **SFTP/FTPS:** Sichere Varianten
-
-**WebDAV (Web-based Distributed Authoring):**
-- HTTP-basiert → Firewall-freundlich
-- Wird von vielen Cloud-Diensten genutzt
-- Mountbar als Netzlaufwerk
-
-**Moderne Alternativen:** rsync, rclone, Cloud-APIs
+# Sub-Sektion A: Speicher — wo wohnen die Bytes?
---
-
+# HDD — Magnetscheibe mit beweglichen Köpfen
-# Teil 2: APIs
-## Software-Schnittstellen & Protokolle
+**Hard Disk Drive.** Erfunden 1956 (IBM RAMAC). Bis 2010 das Standard-Speichermedium.
----
-
-
-
-
-
----
-
-# Was ist eine API?
-
-**API = Application Programming Interface**
-
-**Analogie: Restaurant**
-- Du (Client) → Speisekarte (API-Dokumentation)
-- Bestellst (Request)
-- Küche bereitet zu (Backend)
-- Kellner bringt Essen (Response)
-- Du weißt nicht, WIE gekocht wird – nur WAS du kriegst
-
-**Typen:** Hardware-APIs, OS-APIs, Web-APIs, Library-APIs
-
-
-
----
-
-
-
-
-
----
-
-# HTTP: Das Fundament
-
-**HTTP = HyperText Transfer Protocol (1991)**
-
-**Request-Struktur:**
-- **Method:** GET, POST, PUT, DELETE
-- **URL:** Resource-Identifier
-- **Headers:** Metadaten (Content-Type, Authorization...)
-- **Body:** Optional (bei POST/PUT)
-
-**Response-Struktur:**
-- **Status Code:** 200 OK, 404 Not Found, 500 Error
-- **Headers:** Metadaten
-- **Body:** HTML, JSON, XML, Binary...
-
-
-
----
-
-# HTTP-Methods: CRUD
-
-**CRUD = Create, Read, Update, Delete**
-
-| Method | CRUD | Beispiel |
-|--------|------|----------|
-| **GET** | Read | `/posts` → Alle Posts |
-| **POST** | Create | `/posts` → Neuer Post |
-| **PUT** | Update | `/posts/42` → Post ersetzen |
-| **PATCH** | Update | `/posts/42` → Teilupdate |
-| **DELETE** | Delete | `/posts/42` → Post löschen |
-
-**GET = Idempotent** (mehrfach ausführen = gleiches Ergebnis)
-
-
-
----
-
-
-
-
-
----
-
-# REST: Representational State Transfer
-
-**REST (Roy Fielding, 2000):**
-
-**Prinzipien:**
-1. **Stateless:** Jede Anfrage eigenständig
-2. **Resource-Based:** URLs = Ressourcen (`/users/123`)
-3. **HTTP-Methods:** CRUD-Operationen
-4. **Hypermedia:** Links zu verwandten Ressourcen
-
-**Beispiel: Twitter-API**
-```
-GET /tweets/123 → Tweet mit ID 123
-POST /tweets → Neuen Tweet erstellen
-DELETE /tweets/123 → Tweet löschen
-GET /users/alice/tweets → Tweets von Alice
-```
-
-
-
----
-
-# REST-Probleme
-
-**Problem 1: Over-Fetching**
-```
-GET /users/123
-→ Gibt zurück: Name, Email, Bio, Avatar,
- Follower-Count, Posts, Friends...
-```
-Du willst nur Name → Kriegst 90% zu viel
-
-**Problem 2: Under-Fetching**
-```
-GET /users/123 → User-Daten
-GET /users/123/posts → Alle Posts
-```
-2 Requests statt einem
-
-**Lösung:** GraphQL
-
-
-
----
-
-
-
-
-
----
-
-# GraphQL: Die REST-Alternative
-
-**GraphQL (Facebook, 2015):**
-
-**Idee:** Client fragt EXAKT, was er braucht
-
-**Query-Beispiel:**
-```graphql
-{
- user(id: 123) {
- name
- email
- posts(limit: 5) {
- title
- createdAt
- }
- }
-}
-```
-
-**Vorteile:**
-✓ Kein Over-/Under-Fetching
-✓ Ein Endpoint (`/graphql`)
-✓ Strongly Typed (Schema!)
-
-
-
----
-
-# GraphQL Schema
-```graphql
-type User {
- id: ID!
- name: String!
- email: String
- posts: [Post!]!
-}
-
-type Post {
- id: ID!
- title: String!
- content: String!
- author: User!
-}
-
-type Query {
- user(id: ID!): User
- posts: [Post!]!
-}
-
-type Mutation {
- createPost(title: String!, content: String!): Post!
-}
-```
-
-**`!` = Required (non-nullable)**
-
-
-
----
-
-
-
-
-
----
-
-# WebSockets: Real-Time
-
-**Problem mit HTTP:**
-- Request-Response-Zyklus
-- Server kann nicht "pushen"
-- Polling ineffizient
-
-**WebSocket (2011):**
-- **Bidirektionale Verbindung**
-- Bleibt offen (Persistent)
-- Server kann jederzeit senden
-
-**Anwendungen:**
-Chat (Discord), Live-Updates (Aktienkurse), Multiplayer-Games
-
-
-
----
-
-# WebSocket: Chat-Beispiel
-
-**Flow:**
-1. Alice öffnet Chat → WebSocket-Connection
-2. Bob öffnet Chat → Eigene Connection
-3. Alice tippt: "Hi Bob!"
-4. Client sendet: `{"type": "message", "text": "Hi Bob!", "to": "bob"}`
-5. Server leitet an Bobs Connection weiter
-6. Bob empfängt, zeigt an
-
-**Kein Polling! Instant!**
-
-
-
----
-
-
-
-
-
----
-
-# gRPC: Google's Approach
-
-**gRPC = Google Remote Procedure Call (2015)**
-
-**Idee:** Funktion auf Remote-Server aufrufen, als wäre es lokal
-
-**Eigenschaften:**
-- **Protocol Buffers (Protobuf):** Binär, kompakt (statt JSON)
-- **HTTP/2:** Multiplexing, Bidirektional
-- **Strongly Typed**
-- **Code-Generierung** (Client/Server aus `.proto`-Datei)
-
-**Vorteile:** Performance, Streaming
-**Nachteile:** Nicht Browser-kompatibel, Debugging schwieriger
-
-
-
----
-
-# gRPC Beispiel
-
-**`.proto`-Datei:**
-```protobuf
-service UserService {
- rpc GetUser (UserRequest) returns (UserResponse);
- rpc ListPosts (Empty) returns (stream Post);
-}
-
-message UserRequest {
- int32 id = 1;
-}
-
-message UserResponse {
- string name = 1;
- string email = 2;
-}
-```
-
-**Code-Generierung:** Client/Server-Code automatisch generiert
-
-
-
----
-
-# JSON: Das Standard-Format
-
-**JSON = JavaScript Object Notation**
-
-**Eigenschaften:**
-- Textbasiert, menschenlesbar
-- Schlüssel-Wert-Paare
-- Unterstützt: Objekte, Arrays, Strings, Numbers, Booleans, null
-
-**Beispiel:**
-```json
-{
- "name": "Alice",
- "age": 28,
- "posts": [
- {"title": "Hello", "views": 42},
- {"title": "World", "views": 123}
- ]
-}
-```
-
-
-
----
-
-# Hands-On: API abfragen
-
-**Aufgabe (40 Min):**
-
-**Teil 1: REST-API (20 Min)**
-1. Öffentliche API: `jsonplaceholder.typicode.com`
-2. Tool: curl (Terminal) oder Postman (GUI)
-3. Beispiele:
-```bash
-curl https://jsonplaceholder.typicode.com/posts/1
-curl -X POST https://jsonplaceholder.typicode.com/posts \
- -H "Content-Type: application/json" \
- -d '{"title":"Test","body":"Hello","userId":1}'
-```
-4. Analysiere: Status-Code, Headers, Body
-
-**Teil 2: WebSocket (20 Min)**
-1. Öffne: `websocket.org/echo.html`
-2. Verbinde, sende Nachrichten
-3. Beobachte: Instant Response
-
-
-
----
-
-
-
-# Teil 3: Metadaten
-## Daten über Daten & Interoperabilität
-
----
-
-
-
-
-
----
-
-# Was sind Metadaten?
-
-**Metadaten = Daten über Daten**
-
-**Beispiele:**
-- **Foto:** Kamera, Datum, GPS, Belichtung
-- **MP3:** KünstlerInnen, Album, Jahr, Genre, Cover
-- **PDF:** AutorIn, Datum, Software
-- **E-Mail:** Absender, Empfänger, Zeitstempel
-
-**Warum wichtig?**
-✓ Organisation, Suche
-✓ Kontext (Wann/Wo/Wie?)
-
-**Aber auch:**
-❌ Privacy-Risiko, Forensische Spuren
-
-
-
----
-
-# EXIF: Exchangeable Image File Format
-
-**EXIF (1995, Kamera-Hersteller):**
-
-**Typische Daten:**
-- Kamera-Modell (z.B. "iPhone 15 Pro")
-- Datum & Uhrzeit
-- Belichtung (Blende, Verschlusszeit, ISO)
-- **GPS-Koordinaten** (Latitude, Longitude, Altitude)
-- Software (z.B. "Photoshop 2024")
-
-**Speicherort:** JPEG-Header (Binärformat)
-
-**Tools:** exiftool, ExifPurge, metapicz.com
-
-
-
----
-
-
-
-
-
----
-
-# EXIF: Privacy-Albtraum
-
-**Szenario 1: Stalking**
-- Foto auf Twitter: "Zuhause entspannen 🏡"
-- EXIF: GPS 52.5200° N, 13.4050° E
-- → Stalker weiß, wo du wohnst
-
-**Szenario 2: Whistleblowing**
-- Anonyme Quelle schickt PDF
-- Metadaten: "Erstellt von: John Doe, Firma XY"
-- → Quelle identifiziert
-
-**Berühmter Fall:**
-John McAfee (2012): Vice-Magazine vergaß EXIF zu entfernen
-→ GPS verriet Aufenthaltsort in Guatemala
-
-
-
----
-
-# Social Media & EXIF-Stripping
-
-**Welche Plattformen entfernen EXIF?**
-
-✓ **Twitter/X:** Ja (seit 2015)
-✓ **Facebook/Instagram:** Ja (GPS entfernt)
-✓ **Reddit:** Ja
-❌ **WhatsApp:** Nein (privat, aber Metadaten bleiben)
-❌ **E-Mail-Anhänge:** Nein
-❌ **Cloud (Dropbox, Google Drive):** Nein
-
-**Best Practice:** EXIF manuell entfernen vor Upload
-```bash
-exiftool -all= foto.jpg # Entfernt ALLE Metadaten
-```
-
-
-
----
-
-
-
-
-
----
-
-# ID3-Tags: Musik-Metadaten
-
-**ID3 = Identification 3 (1996)**
-
-**Versionen:**
-- **ID3v1:** 128 Bytes am Ende (limitiert!)
- - Titel (30 Zeichen), Artist, Album, Jahr
-- **ID3v2:** Am Anfang, variable Länge
- - Unbegrenzte Textfelder, Cover-Art, Lyrics, BPM
-
-**Tools:**
-- Kid3 (GUI, Multi-Platform)
-- MusicBrainz Picard (Auto-Tagging!)
-- mp3tag (Windows)
-
-
-
----
-
-
-
-
-
----
-
-# MusicBrainz: Offene Musik-Datenbank
-
-**MusicBrainz (2000):**
-
-**Idee:** Wikipedia für Musik-Metadaten
-
-**Community-gepflegt:**
-- KünstlerInnen, Alben, Tracks
-- Relationships (Band-Mitglieder, Label...)
-- Releases (verschiedene Editionen, Länder)
-
-**MusicBrainz Picard:**
-- Audio-Fingerprinting (AcoustID)
-- Analysiert Waveform, matched mit Datenbank
-- Auto-Tagging (auch bei falsch benannten Dateien!)
-
-**Philosophie:** Open Data (gegen proprietäre Gracenote/CDDB)
-
-
-
----
-
-# Dublin Core: Universelle Metadaten
-
-**Dublin Core (1995, Dublin, Ohio):**
-
-**15 Kern-Elemente:**
-1. Title, 2. Creator, 3. Subject, 4. Description
-5. Publisher, 6. Contributor, 7. Date, 8. Type
-9. Format, 10. Identifier (ISBN, DOI)
-11. Source, 12. Language, 13. Relation
-14. Coverage, 15. Rights
-
-**Anwendung:** Bibliotheken, Archive, Webseiten (HTML ``)
-
-
-
----
-
-
-
-
-
----
-
-# PDF-Metadaten: Hidden Dangers
-
-**PDF-Metadaten (XMP):**
-
-**Gespeichert:**
-- Titel, AutorIn, Betreff, Keywords
-- Erstellungsdatum, Änderungsdatum
-- Software, **Company** (aus Office-Lizenz!)
-
-**Versteckte Daten:**
-- Änderungshistorie (Track Changes)
-- Kommentare (vermeintlich gelöscht)
-- Ebenen (InDesign, Illustrator)
-
-**Berühmter Fall:**
-Tony Blair Dossier (2003, Irak-Krieg)
-→ PDF-Metadaten zeigten Manipulation
-
-
-
----
-
-# Interoperabilität: Offene vs. Proprietäre
-
-**Offene Formate:**
-✓ Spezifikation öffentlich
-✓ Keine Lizenzgebühren
-✓ Viele Programme unterstützen1
-**Beispiele:** PNG, OGG, MKV, Markdown, SVG
-
-**Proprietäre Formate:**
-❌ Spezifikation geheim
-❌ Oft nur in einer Software voll nutzbar
-❌ **Lock-in-Effekt**
-**Beispiele:** PSD (Photoshop), INDD (InDesign), DWG (AutoCAD), .pages
-
-
-111
----
-
-# Vendor Lock-in: Beispiele
-
-**Fall 1: Microsoft Office (.docx)**
-- Historisch: .doc undokumentiert
-- LibreOffice konnte nicht perfekt konvertieren
-- "Formatierung kaputt" → Zurück zu MS Office
-
-**Fall 2: Adobe Creative Suite**
-- PSD: Layer, Blend-Modes → Nur in Photoshop voll editierbar
-- GIMP kann öffnen, aber Features fehlen
-
-**Fall 3: Apple Ecosystem**
-- .pages, .numbers, .key → Nur auf Apple native Bearbeitung
-
-
-
----
-
-# Datenmigration & Langzeitarchivierung
-
-**Beispiele toter Formate:**
-- WordPerfect (.wpd) – 1980-90er dominant, heute kaum lesbar
-- Lotus 1-2-3 (.wks) – Spreadsheet, verschwunden
-- Flash (.swf) – Millionen Websites/Games, seit 2020 tot
-
-**Archivierungs-Strategien:**
-1. **Migration:** Regelmäßig in aktuelle Formate konvertieren
-2. **Emulation:** Alte Software in VM
-3. **Offene Standards:** PDF/A, TIFF, Plain Text
-
-
-
----
-
-# Metadaten für Accessibility
-
-**Alt-Text (Alternative Text):**
-```html
-
-```
-
-**Warum?**
-✓ Screen-Reader (Blinde/Sehbehinderte)
-✓ SEO (Suchmaschinen)
-✓ Fallback (Bild lädt nicht)
-
-**PDF-Tags:** Strukturierte PDFs (Überschriften, Listen)
-→ Screen-Reader kann navigieren
-
-**Video:** Closed Captions (CC), Audio Descriptions
-
-
-
----
-
-# Hands-On: Metadaten analysieren & entfernen
-
-**Aufgabe (40 Min):**
-
-**Teil 1: EXIF (20 Min)**
-1. Nimm Foto (oder nutze altes)
-2. Analysiere: `exiftool foto.jpg` oder metapicz.com
-3. Notiere: GPS? Kamera-Modell? Software?
-4. Entferne: `exiftool -all= foto.jpg`
-5. Vergleiche Dateigrößen
-
-**Teil 2: ID3 (20 Min)**
-1. Nimm MP3-Datei
-2. Analysiere: Kid3, mp3tag, oder exiftool
-3. Ändere Tags (z.B. falscher Artist)
-4. Optional: MusicBrainz Picard (Auto-Tagging)
-
-
-
----
-
-
-
-# Teil 4: Zukunft
-## Trends & Ausblick
-
----
-
-
-
-
-
----
-
-# AI-basierte Kompression
-
-**Problem:** JPEG/H.264 basieren auf 90er-Jahre-Modellen
-
-**Neue Ansätze:**
-
-1. **Neuronale Bild-Kompression:**
- - Deep Learning lernt Kompression/Dekompression
- - Google's "Learned Image Compression" (2018)
- - Outperforms JPEG bei gleicher Größe
-
-2. **Generative Kompression:**
- - Encoder extrahiert semantische Features
- - Decoder generiert Bild neu (wie DALL-E)
- - **99%+ Kompression**, aber nicht bit-genau!
-
-**Problem:** Hoher Rechenaufwand, keine Standardisierung
-
-
-
----
-
-
-
-
-
----
-
-# JPEG XL: Der moderne JPEG
-
-**JPEG XL (2021, ISO-Standard):**
-
-**Ziele:**
-✓ 60% besser als JPEG
-✓ Besser als WebP/AVIF (manchmal)
-✓ Lossless UND Lossy
-✓ Progressive Decoding (wie klassisches JPEG)
-✓ Rückwärtskompatibel (JPEG → JPEG XL "Wrapper")
-
-**Features:** HDR, Animation (wie GIF, aber besser)
-
-**Status 2025:** Browser-Support langsam (Safari ja, Chrome on-off)
-
-**Problem:** Google favorisiert WebP/AVIF → politischer Kampf
-
-
-
----
-
-# AV1 & VVC: Codec-Krieg
-
-**AV1 (Alliance for Open Media):**
-✓ Etabliert sich (YouTube 4K, Netflix)
-✓ Hardware-Decoder in neuen GPUs/Smartphones
-
-**VVC (H.266, 2020):**
-- 50% besser als H.265
-- **Aber:** Patent-Problem (mehrere Pools, unklare Kosten)
-- Adoption gering
-
-**LCEVC:** Add-on für existierende Codecs
-
-**Zukunft:**
-- AV2 (Nachfolger AV1) in Entwicklung
-- ML integriert?
-
-
-
----
-
-
-
-
-
----
-
-# DNA-Storage
-
-**Konzept:** Daten in DNA-Sequenzen
-
-**Eigenschaften:**
-- Speicherdichte: **215 Petabyte/Gramm**
-- Haltbarkeit: Tausende Jahre
-- Kosten: Aktuell $3.500/MB (sinkend)
-
-**Beispiele:**
-- Microsoft + Twist Bioscience
-- Netflix "Biohackers"-Episode (2021)
-- Harvard: Wikipedia (11 GB) in DNA (2017)
-
-**Problem:** Synthese & Sequenzierung extrem langsam/teuer
-
-**Anwendung:** Langzeitarchivierung (nicht Live-Daten)
-
-
-
----
-
-# Holografischer Speicher
-
-**Holographic Data Storage:**
-
-**Prinzip:**
-- Laser schreibt in 3D-Kristall (statt 2D-Oberfläche)
-- Interferenzmuster speichert Bits
-- Paralleler Zugriff (schnell!)
-
-**Vorteile:**
-✓ Hohe Dichte (Terabytes pro Disc)
-✓ Schnelle Lesegeschwindigkeit
-✓ Langlebig (50+ Jahre)
-
-**Stand 2025:** Prototypen (Sony, InPhase †), Kommerzialisierung gescheitert
-
-**Problem:** Teuer, Konkurrenz durch SSDs
-
-
-
----
-
-# Quantum Storage?
-
-**Quantenspeicher:**
-
-**Konzept:**
-- Qubits statt klassische Bits
-- Superposition: 0 UND 1 gleichzeitig
-- Verschränkung: Qubits korreliert über Distanz
-
-**Anwendung:**
-- Nicht für klassische Daten (Qubits instabil)
-- Quantum Key Distribution (QKD) für Kommunikation
-- Zukunft: Quanten-RAM für Quantencomputer
-
-**Stand 2025:** Experimentell, Speicherzeit Millisekunden
-
-
-
----
-
-# Web3 & Dezentraler Speicher
-
-**IPFS, Filecoin, Arweave, Storj:**
-
-**Idee:** Speicher ohne zentrale Server
-
-**Filecoin (2017):**
-- Blockchain-basiert
-- Nutzende vermieten Festplatten-Platz
-- Bezahlung in FIL (Kryptowährung)
-
-**Arweave (2018):**
-- "Permanent Storage"
-- Einmalige Zahlung → Daten für immer (theoretisch)
-
-**Kritik:**
-❌ Langsam vs. AWS S3
-❌ Teurer (oft)
-❌ Keine Garantie (Nodes offline)
-
-
-
----
-
-# Streaming-Zukunft
-
-**Trends:**
-
-**8K-Streaming:**
-- 7680×4320 = 33 Megapixel/Frame
-- Braucht 100+ Mbps (selbst mit AV1)
-- Problem: Kaum Content, kaum TVs
-
-**VR/AR-Streaming:**
-- 2× 4K (pro Auge), 90-120 fps
-- Latenz <20ms kritisch
-- 5G + Edge Computing nötig
-
-**Cloud Gaming:**
-- Spiel im Rechenzentrum, Stream zu Nutzenden
-- Input-Lag = Todfeind (<50ms)
-
-**Problem:** Physik (Lichtgeschwindigkeit!)
-
-
-
----
-
-# Nachhaltigkeit
-
-**Digitalisierung ≠ Umweltfreundlich**
-
-**Rechenzentren:**
-- 2024: 1-2% globaler Stromverbrauch (steigend!)
-- Kühlung, Server, Netzwerk
-
-**Streaming:**
-- 1h Netflix (HD): ~3 GB, ~0,1 kWh
-- × Milliarden Stunden = massiver CO₂
-
-**E-Waste:**
-- Smartphones: 2-3 Jahre Lebensdauer
-- SSDs, HDDs: Nicht ewig
-
-**Lösungen:**
-- Effizientere Codecs (weniger Bandbreite)
-- Renewable Energy für Rechenzentren
-- Längere Hardware-Lebensdauer (Right to Repair!)
-
-
-
----
-
-# Regulierung & Standardisierung
-
-**Wer entscheidet?**
-
-**Standards-Organisationen:**
-- ISO/IEC (International)
-- IETF (Internet-Protokolle)
-- W3C (Web-Standards)
-- IEEE (Hardware)
-
-**Problem:** Industrie-Dominanz
-- MPEG-LA (Patent-Pools)
-- USB-IF (Intel-dominiert)
-- HDMI Forum (Consumer-Electronics)
-
-**EU-Regulierung:**
-- USB-C-Pflicht (ab 2024)
-- DMA (Digital Markets Act): Interoperabilität
-- GDPR: Datenschutz (betrifft Metadaten!)
-
-**Zukunft:** Mehr Open Standards? Oder Fragmentierung?
-
-
-
----
-
-# Fallstudie: Gruppenarbeit
-
-**Aufgabe (90 Min, ca. 5 Personen):**
-
-**Szenario:** Mittelständisches Medienunternehmen produziert Videos
-
-**Erarbeitet Konzept für:**
-1. Speichermedien (intern/extern, kurz-/langfristig)
-2. Dateiformate (Produktion, Distribution, Archivierung)
-3. Dateisysteme (welche für was?)
-4. Schnittstellen (SATA, USB, PCIe, Netzwerk)
-5. Distributionswege (NAS, Cloud, FTP)
-6. Backup-Strategie (3-2-1-Regel!)
-
-**Ergebnis:** Konzeptpapier (Mindmap, Tabelle, Poster)
-**Präsentation:** 5 Min pro Gruppe
-
-
-
----
-
-# Alternative Szenarien (Auswahl)
-
-1. **Mittelständisches Medienunternehmen** (Videos, Streaming)
-2. **Kommunales Stadtarchiv** (Digitalisierung historischer Bestände)
-3. **Agentur für digitale Kommunikation** (internationale Kampagne)
-4. **Digitale Hochschul-Mediathek** (Lehrvideos, Podcasts)
-5. **Freiberufliche Fotografin** (Tausende RAW-Fotos/Jahr)
-6. **Internationales Reporterteam** (investigative Recherche, sensibel)
-
-**Jede Gruppe wählt ein Szenario**
-
-
-
----
-
-# Was wir insgesamt gelernt haben
-
-✓ **Bits → Formate:** Encoding, Kompression (MP3, JPEG, H.264)
-✓ **Speicher:** HDD, SSD, Dateisysteme, Backup, Archivierung
-✓ **Schnittstellen:** USB-C, HDMI, DisplayPort, Ethernet
-✓ **Distribution:** CDN, P2P, Streaming, APIs
-✓ **Metadaten:** EXIF, ID3, Privacy, Interoperabilität
-✓ **Zukunft:** AI-Kompression, DNA-Storage, Nachhaltigkeit
-
-**Kernbotschaft:**
-Digitale Medien sind das Ergebnis von Standards, Politik, Kompromissen & Innovation.
-
-Ihr habt jetzt die Werkzeuge, um die digitale Welt kritisch zu verstehen.
+- **Magnetisierte** Bereiche auf rotierender Platter (5.400–15.000 U/min)
+- Schreib-/Lese-**Kopf** schwebt auf Luftpolster (~5 nm Abstand)
+- **Spuren** (konzentrische Kreise) + **Sektoren** (Tortenstück-Abschnitte)
+- **Bewegliche Teile** → Verschleiß, Geräusch, Stoß-empfindlich
---
-# Weiterführende Ressourcen
+# SSD — Speicher ohne Mechanik
-**Bücher:**
-- "Code" – Charles Petzold (Basics)
-- "Understanding Digital Signal Processing" – Richard Lyons
+**Solid State Drive.** Massentauglich seit ~2010. Heute Standard für OS-Disks.
-**Websites:**
-- IETF RFCs (ietf.org)
-- FFmpeg Documentation (ffmpeg.org)
-- Protocol Labs (IPFS, Filecoin)
-
-**YouTube:**
-- Computerphile (Kompression, Encoding)
-- Branch Education (Hardware-Visualisierungen)
-
-**Podcasts:**
-- Command Line Heroes (Red Hat)
-
-**Tools:** MediaInfo, exiftool, FFmpeg, Wireshark
-
-
-
----
-
-# Abschluss & Dank
-
-**Ihr habt gelernt:**
-- Dateien zu lesen (Hex, Metadaten)
-- Formate zu vergleichen (JPEG vs. PNG, H.264 vs. AV1)
-- Infrastruktur zu verstehen (CDN, P2P, APIs)
-- Kritisch zu denken (Open Standards, Lock-in, Nachhaltigkeit)
-
-**Nächste Schritte:**
-- Fallstudie (falls Prüfungsleistung)
-- Feedback willkommen (E-Mail)
-- Weiterlernen mit Ressourcen
-
-**Vielen Dank für eure Aufmerksamkeit!**
+- **Flash-Speicher** (NAND): Elektronen in Floating Gates speichern Bits
+- **Keine beweglichen Teile** → kein Geräusch, kein Stoß-Risiko
+- **NVMe-Protokoll** (PCIe-direkt) → 5–14 GB/s im Vergleich zu HDD-200 MB/s
+- **Schreibzyklen begrenzt** (TLC: ~3 000 P/E-Zyklen pro Zelle)
+
+---
+
+
+
+# HDD vs. SSD
+
+
+
+| | 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 |
+
+
+
+---
+
+
+
+# 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 |
+
+
---
-# Fragen & Diskussion
+# Filesystems — die Sprache des Speichers
-**Kontakt:** lb-czechowski@hdm-stuttgart.de
-**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
+
---
-# Lizenz & Attribution
+# Was macht ein Filesystem?
-Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+**Vier zentrale Aufgaben:**
-- Erlaubt Teilen & Anpassen mit Namensnennung
-- Adaptionen müssen unter gleicher Lizenz geteilt werden
+1. **Datei-Tabelle:** welche Datei wohnt wo? (Block-Adressen)
+2. **Frei-Liste:** welche Blöcke sind ungenutzt?
+3. **Verzeichnisbaum:** Ordner-Hierarchie
+4. **Metadaten:** Berechtigung, Erstell-Zeit, Letzt-Änderung, Eigentümer
-Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+Ein Speichermedium **ohne Filesystem** ist nur ein langer Strom von Bytes — niemand weiß, was wo ist.
+
+
+---
+
+
+
+# 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.
+
+
+
+---
+
+
+
+# Backup — die unangenehme Pflicht
+
+
+
+---
+
+
+
+# Pixar verlor Toy Story 2 fast
+
+**1998.** Ein Mitarbeiter führte ein Maintenance-Skript aus, das per `rm -rf /` ausversehen die Hauptdatenbank löschte.
+
+90 % des Films weg. Backup-Tapes? Defekt seit Monaten — niemand merkte es.
+
+**Glück:** Galyn Susman, im Mutterschutz, hatte privat ein Backup auf dem Heim-PC. *Daraus wurde der Film rekonstruiert.*
+
+
+
+---
+
+
+
+# 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)
+```
+
+
+
+---
+
+# Backup-Typen
+
+| Typ | Was wird gesichert | Restore-Aufwand | Speicher |
+|-----|---------------------|-----------------|----------|
+| **Full** | Alles, jedes Mal | klein (eine Datei) | viel (jedes Mal alles) |
+| **Incremental** | Nur Änderungen seit *letztem Backup* | groß (Kette aufrollen) | klein |
+| **Differential** | Alle Änderungen seit *letztem Full* | mittel | mittel |
+| **Snapshot** (APFS, ZFS) | Filesystem-Stand zu einem Zeitpunkt | sofort | Copy-on-Write |
+
+**In der Praxis:** Mix aus 1× Full pro Woche + Incremental täglich.
+
+
+
+---
+
+
+
+# Sub-Sektion B: Schnittstellen — wie reisen die Bytes?
+
+
+
+---
+
+
+
+# USB-C — und seine drei Achsen
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# HDMI — Video + Audio + Kopierschutz
+
+**High-Definition Multimedia Interface.** 2002. Standard für Heim-Elektronik.
+
+| Version | Bandbreite | Max. Video |
+|---------|-----------|-----------|
+| HDMI 1.4 | 10 Gbit/s | 4K @ 30 Hz |
+| HDMI 2.0 | 18 Gbit/s | 4K @ 60 Hz |
+| HDMI 2.1 | 48 Gbit/s | 8K @ 60 Hz oder 4K @ 120 Hz |
+
+**HDCP:** Kopierschutz, der „illegale" Aufnahmen verhindern soll. Manchmal die Ursache für „Bildschirm bleibt schwarz, wenn Netflix läuft."
+
+
+
+---
+
+# DisplayPort — HDMIs offenes Pendant
+
+**Open-Source-Industrie-Standard.** Hauptsächlich PC-Welt (Monitore).
+
+- Versionen 1.4 (32 Gbit/s) bis 2.1 (80 Gbit/s)
+- **MST (Multi-Stream Transport):** ein Kabel → mehrere Monitore
+- **Adaptive Sync:** flüssige Bildraten bei Gaming (FreeSync, G-Sync)
+
+In USB-C steckt fast immer ein **DisplayPort Alt Mode**, sodass dasselbe Kabel beides kann.
+
+
+
+---
+
+# Thunderbolt — der Tunnel für alles
+
+**Intel + Apple 2011, seit Version 3 (2015) auf USB-C-Stecker.**
+
+Spezifikation:
+- **Thunderbolt 3 / 4:** 40 Gbit/s. PCIe + DisplayPort + USB *gleichzeitig*.
+- **Thunderbolt 5** (2024): 80–120 Gbit/s.
+
+Anwendung: **externe GPU** (eGPU), 8K-Monitor, RAID-Array, ein Dock für alles.
+
+
+
+---
+
+# Ethernet vs. WiFi — Bandbreite + Latenz
+
+| | Ethernet (Kabel) | WiFi (Funk) |
+|--|------------------|-------------|
+| Bandbreite | 1–10 Gbit/s | 0,6–9,6 Gbit/s (WiFi 6E) |
+| Latenz | < 1 ms | 5–20 ms (variabel) |
+| Stabilität | konstant | abhängig von Umgebung |
+| Setup | Kabel ziehen | App, kein Kabel |
+| Sicherheit | physisch geschützt | Passwort, abhörbar |
+
+**Für Streaming:** WiFi reicht.
+**Für Gaming, Video-Call, Online-Code:** Ethernet besser (Latenz!).
+
+
+
+---
+
+
+
+# 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 |
+
+
+
+---
+
+
+
+# Selbstlernen — zwei Übungen
+
+**1. Backup-Konzept aufschreiben**
+Inventarisiert eure Geräte: Wo wohnen welche Daten? Schreibt euer 3-2-1-Backup für eure eigene Foto-Library auf. Welches Off-site? Welche zweite Kopie?
+
+**2. USB-C-Kabel-Check**
+Holt eure USB-C-Kabel raus. Was steht drauf? Was kann jedes Kabel laut Verpackung? Habt ihr ein „Charge-only"-Kabel, ohne es zu wissen?
+
+
+
+---
+
+# Zusammenfassung
+
+**Speicher = wo wohnen die Bytes:** HDD-Mechanik vs SSD-Flash. Tradeoff Geschwindigkeit ↔ Preis/TB. Filesystem als Buchhaltung. Backup als 3-2-1.
+
+**Schnittstellen = wie reisen sie:** USB-C-Stecker täuscht — drei Achsen (Stecker · Kabel · Protokoll). HDMI/DP/TB für Video. Ethernet für Latenz, WiFi für Bequemlichkeit.
+
+**Der gemeinsame Hebel:** Engpass identifizieren, *bevor* man Hardware kauft.
+
+→ **In Kap 5** schauen wir uns an, was eine Datei *unterwegs* mitführt — und was sie *verrät*.
+
+