---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
---
---
# Termin 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. Kunde 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 User 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. User → 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:**
- User-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 User = 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
---
# Teil 2: APIs
## Software-Schnittstellen & Protokolle
---
---
# 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ünstler, Album, Jahr, Genre, Cover
- **PDF:** Autor, 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ünstler, 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, Autor, 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ützen
**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
---
# 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
- User 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 User
- 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.
---
# Weiterführende Ressourcen
**Bücher:**
- "Code" – Charles Petzold (Basics)
- "Understanding Digital Signal Processing" – Richard Lyons
**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!**
---
# Fragen & Diskussion
**Kontakt:** mail@librete.ch
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
---
# Lizenz & Attribution
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
- Erlaubt Teilen & Anpassen mit Namensnennung
- Adaptionen müssen unter gleicher Lizenz geteilt werden
Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/