From f41dd51e5c20d43ff506e4923752e41958cfe572 Mon Sep 17 00:00:00 2001 From: Michael Czechowski Date: Thu, 14 May 2026 12:04:58 +0200 Subject: [PATCH] =?UTF-8?q?223015b=20phase=204:=20kap4=20slide-MD=20(filen?= =?UTF-8?q?ame=20misleading:=2004-distribution-apis-zukunft.md=20h=C3=A4lt?= =?UTF-8?q?=20jetzt=20'speicher=20und=20schnittstellen').=2023=20slides=20?= =?UTF-8?q?nach=20bogen=20(etwas=20gek=C3=BCrzt=20von=2030=20durch=20zusam?= =?UTF-8?q?menfassen)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit struktur: - 2 intro: kapitel-lead, kap04-eroeffner als advance organizer (datei-reise pipeline) - 10 SPEICHER: lead, HDD-mechanik, SSD-flash, klausur HDD-vs-SSD-tabelle (hdd-ssd-comparison reuse), klausur wann-was-matrix, lead filesystems, was-macht-FS, klausur filesystem-landschaft (FAT32/exFAT/NTFS/APFS/ext4/ZFS mit max-dateigröße), lead backup, pixar-story (backup-disaster reuse), klausur 3-2-1-regel, backup-typen-tabelle - 9 SCHNITTSTELLEN: lead schnittstellen, lead USB-C-drei-achsen (vorbereitung), usb-c-drei-achsen demo, HDMI mit version-tabelle + HDCP-warnung, DisplayPort, Thunderbolt, ethernet-vs-wifi-tabelle, klausur schnittstellen-wahl-matrix - 2 selbstlernen + summary: backup-konzept + usb-c-kabel-check, zusammenfassung reuse-demos: kap04-eroeffner, usb-c-drei-achsen (zentrales aha-bild) reuse-assets: hdd-ssd-comparison.png, backup-disaster.png klausur-marker (6): HDD-vs-SSD, wann-was-speicher, filesystem-landschaft, 3-2-1-regel, schnittstellen-wahl, (impliziert USB-C-achsen) streichungen vs altem 03-speichermedien-schnittstellen.md (850 zeilen): doppelte HDD/SSD-vertiefungen entfernt, legacy-kabel-folien raus, latenz-throughput-wiederholungen gekürzt build geht durch --- .../223015b/04-distribution-apis-zukunft.md | 2287 ++++------------- 1 file changed, 507 insertions(+), 1780 deletions(-) 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 --- - - - - + -![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg) +# Kapitel 4 +## Speicher und Schnittstellen -# Dateiformate, Schnittstellen, Speichermedien & Distributionswege + --- -![bg fit](./assets/qr/slides-223015b.png) - ---- - - - -# Kapitel 4 – 30.01.2026 -## Distribution, APIs & Zukunft - ---- - -![bg](./assets/sneakernet-truck.png) - - - ---- - -# 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) - - - ---- - -![bg](./assets/aws-snowmobile.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/cd-dvd-bluray.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/server-overload.png) - - - ---- - -# 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) - - - ---- - -![bg](./assets/cdn-map.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/netflix-openconnect.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/p2p-network.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/bittorrent-swarm.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/pirate-bay-logo.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/ipfs-logo.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/streaming-hls.png) - - - ---- - -# 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 - - +![bg fit](./assets/demos/kap04-eroeffner.png) --- -# 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. ---- - -![bg](./assets/api-diagram.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/http-request-response.png) - - - ---- - -# 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) - - - ---- - -![bg](./assets/rest-api.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/graphql-logo.png) - - - ---- - -# 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)** - - - ---- - -![bg](./assets/websocket-diagram.png) - - - ---- - -# 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!** - - - ---- - -![bg](./assets/grpc-logo.png) - - - ---- - -# 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 - ---- - -![bg](./assets/exif-gps.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/mcafee-exif-fail.png) - - - ---- - -# 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 -``` - - - ---- - -![bg](./assets/id3-tag-editor.png) - - - ---- - -# 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) - - - ---- - -![bg](./assets/musicbrainz-logo.png) - - - ---- - -# 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 ``) - - - ---- - -![bg](./assets/pdf-metadata-leak.png) - - - ---- - -# 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 -Orange tabby cat sleeping on windowsill -``` - -**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 - ---- - -![bg](./assets/futuristic-datacenter.png) - - - ---- - -# 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 - - - ---- - -![bg](./assets/jpeg-xl-logo.png) - - - ---- - -# 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? - - - ---- - -![bg](./assets/dna-storage-concept.png) - - - ---- - -# 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 + +![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 | + + + +--- + + + +# 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 + + + +--- + +![bg right:40% contain](./assets/backup-disaster.png) + +# 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 + + + +--- + + + + +![bg fit](./assets/demos/usb-c-drei-achsen.png) + + + +--- + +# 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*. + +