diff --git a/.gitignore b/.gitignore index 10d7422..c7f867f 100644 --- a/.gitignore +++ b/.gitignore @@ -61,3 +61,4 @@ Desktop.ini *.html !build/*.html *.pdf +index.md.bak diff --git a/index.md b/index.md deleted file mode 100644 index 0cecd2c..0000000 --- a/index.md +++ /dev/null @@ -1,4209 +0,0 @@ ---- -marp: true -theme: gaia -paginate: true -backgroundColor: #fff -header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege" -footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26" -title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege ---- - - - -![bg fit](./assets/digital-landscape.jpg) - - - ---- - -# Dateiformate, Schnittstellen, Speichermedien & Distributionswege - -Modul "Technik 1" – 1. Semester -Digital- und Medienwirtschaft -Hochschule der Medien Stuttgart - -**Wintersemester 2025/26** - ---- - -# Über mich - -**Michael Czechowski** - -- Softwareentwickler & IT-Berater -- Schwerpunkte: Web-Technologien, Systemarchitektur, Open Source -- Hintergrund: Philosophie & Informatik -- Kontakt: czechowski@hdm-stuttgart.de - - - ---- - -# Termine - -| Datum | Zeit | Thema | -|-------|------|-------| -| 19.12.2025 | 14:15 – 17:30 | Grundlagen, Text & Audio | -| 09.01.2026 | 14:15 – 17:30 | Bild- & Videoformate | -| 23.01.2026 | 14:15 – 17:30 | Speichermedien & Schnittstellen | -| 30.01.2026 | 14:15 – 17:30 | Distribution, APIs & Zukunft | -| TBA | 14:15 – 17:30 | Vertiefung (wird bekannt gegeben) | - -**Ort:** HdM Stuttgart, Nobelstraße 10 - ---- - -# Kurze Umfrage - -**Bitte Hand heben:** - -1. Wer hat schon mal eine Datei mit einem Hex-Editor geöffnet? -2. Wer weiß, was der Unterschied zwischen JPEG und PNG ist? -3. Wer hat schon mal mit APIs gearbeitet? -4. Wer weiß, was UTF-8 bedeutet? -5. Wer hat schon mal ein Video komprimiert/konvertiert? - - - ---- - -# Kursübersicht - -**Ziel:** Verstehen, wie digitale Medien technisch funktionieren – von Bits bis zu globalen Distributionsnetzwerken - -**5 Termine:** -- **19.12.** Bits, Bytes, Zeichenkodierung & Audio-Kompression -- **09.01.** Bild- & Video-Kompression -- **23.01.** Speichermedien & Hardware-Schnittstellen -- **30.01.** Distribution, APIs, Metadaten & Zukunft -- **TBA** Vertiefung & offene Fragen - - - ---- - - - -# Termin 1 – 19.12.2025 -## Grundlagen, Text & Audio - ---- - -![bg right:40%](./assets/matrix-code.jpg) - -# Mysterium - -``` -89 50 4E 47 0D 0A 1A 0A -00 00 00 0D 49 48 44 52 -00 00 01 90 00 00 01 2C -``` - -**Was ist das?** - - - ---- - -# Das Bit - -**Kleinste Informationseinheit** - -- **0 oder 1** -- AN oder AUS -- Strom fließt oder nicht - -![bg right:50%](./assets/lightbulb-onoff.jpg) - - - ---- - -# Das Byte - -**8 Bits = 1 Byte** - -``` -0 1 0 0 1 1 0 1 -``` - -**Wie viele Kombinationen?** -2⁸ = **256 Möglichkeiten** (0-255) - - - ---- - -# Was kann man mit 256 Zuständen machen? - -- **256 Zeichen** (Buchstaben, Zahlen, Symbole) -- **256 Graustufen** (0 = Schwarz, 255 = Weiß) -- **256 Lautstärkestufen** -- **Zahlen 0-255** (oder -128 bis +127) - -![bg left:40%](./assets/grayscale-gradient.jpg) - - - ---- - -# Farben: RGB-Modell - -**1 Pixel = 3 Bytes** - -- **Rot:** 0-255 -- **Grün:** 0-255 -- **Blau:** 0-255 - -**Beispiel:** -`FF 00 00` = Rot -`00 FF 00` = Grün -`FF FF FF` = Weiß - -![bg right:40%](./assets/rgb-color-model.jpg) - - - ---- - -# Das Problem: Sprachen - -**Die Welt hat mehr als 256 Zeichen!** - -- Englisches Alphabet: 52 (A-Z, a-z) -- + Ziffern: 10 (0-9) -- + Sonderzeichen: ~30 - -**≈ 90 Zeichen → passt in 1 Byte** - -**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀 - -→ **1 Byte reicht nicht!** - - - ---- - -![bg](./assets/ascii-table.png) - - - ---- - -# Unicode: Ein Standard für alle - -**Unicode (1991):** -Jedes Schriftsystem der Welt - -**>150.000 Zeichen:** -- Latein, Kyrillisch, Arabisch, Chinesisch, Japanisch... -- Mathematische Symbole, Emoji, historische Schriften - -**UTF-8:** Variable Länge (1-4 Bytes pro Zeichen) - - - ---- - -# Beispiel: Bytes zählen - -**Text:** `"Why the fuck braucht 💩 4 Bytes?!"` - -``` -W h y → je 1 Byte (4 Bytes) -t h e → je 1 Byte (4 Bytes) -f u c k → je 1 Byte (4 Bytes) - → 1 Byte (Leerzeichen) -b r a u c h t → je 1 Byte (7 Bytes) - → 1 Byte -💩 → 4 Bytes! (0xF0 9F 92 A9) - → 1 Byte -4 B y t e s ? ! → je 1 Byte (9 Bytes) -``` - -**Gesamt: 37 Bytes** - - - ---- - -# Hexadezimal: Lesbarkeit - -**Binär ist unleserlich:** -`01001101 01010000 00110011` - -**Hexadezimal (Base 16):** -`4D 50 33` (= "MP3" in ASCII) - -**Jede Hex-Ziffer = 4 Bits** -0-9, A-F (10=A, 11=B, ..., 15=F) - -![bg right:40%](./assets/hex-binary-table.jpg) - - - ---- - -# Magic Numbers - -**Dateityp-Identifikation durch erste Bytes** - -| Format | Magic Number (Hex) | ASCII | -|--------|-------------------|-------| -| PNG | `89 50 4E 47 0D 0A 1A 0A` | `.PNG` | -| JPEG | `FF D8 FF` | `ÿØÿ` | -| PDF | `25 50 44 46` | `%PDF` | -| ZIP | `50 4B 03 04` | `PK` | - - - ---- - -![bg](./assets/hexeditor-screenshot.png) - - - ---- - -# Hands-On: Mystery Files - -**Aufgabe (30 Min):** - -1. Drei Dateien ohne Extension: `mystery1`, `mystery2`, `mystery3` -2. Öffne im Hex-Editor -3. Lies erste 16 Bytes -4. Identifiziere Format (Magic Number) -5. Benenne um und öffne - -**Tools:** hexed.it (online), HxD, Hex Fiend, Bless - - - ---- - -# Aufgabe bis nächste Woche - -**Finde eine Datei auf deinem Computer** - -1. Öffne im Hex-Editor -2. Screenshot der ersten 16 Bytes -3. Identifiziere Magic Number -4. Poste im Forum: Format + kurze Beschreibung - -**Bonus:** Finde Datei ohne Magic Number in Standard-Listen - - - ---- - - - -# Teil 2: Die MP3-Revolution -## Psychoakustik & Audio-Kompression - ---- - -![bg](./assets/cassette-ipod.jpg) - - - ---- - -# Das Problem (1990) - -**1 Minute CD-Audio:** - -- Sample Rate: 44.100 Hz -- Bit Depth: 16 Bit -- Stereo: 2 Kanäle - -**Rechnung:** -44.100 × 16 × 2 = 1.411.200 Bits/Sekunde -≈ **10,6 MB/Minute** -≈ **635 MB für 60-Min-Album** - -**1990:** Festplatten hatten 100-500 MB! - - - ---- - -# Zwei Philosophien - -![bg right:50%](./assets/compression-types.jpg) - -**Lossless (Verlustfrei):** -- Original exakt wiederherstellbar -- ZIP, PNG, FLAC -- 30-50% Ersparnis - -**Lossy (Verlustbehaftet):** -- Daten irreversibel verändert -- JPEG, MP3, H.264 -- 90%+ Ersparnis - - - ---- - -# Lossless: Run-Length Encoding - -**Original:** -``` -AAAAABBBCCCCCCCC -``` - -**Komprimiert:** -``` -5A 3B 8C -``` - -**Ersparnis:** 16 → 6 Zeichen (62% Reduktion) - - - ---- - -# Lossy: Der Trick - -**Kernidee:** Wirf weg, was der Mensch eh nicht wahrnimmt - -**JPEG:** Schwächen des Auges -- Helligkeit besser als Farbe wahrgenommen -- Große Flächen besser als feine Details - -**MP3:** Schwächen des Ohrs -- Mittlere Frequenzen besser als hohe/tiefe -- Laute Töne "maskieren" leise Töne - -→ **Psychoakustik / Psychovisuell** - - - ---- - -![bg](./assets/karlheinz-brandenburg.jpg) - - - ---- - -# Die Geburt der MP3 - -**1982:** Universität Erlangen-Nürnberg -Karlheinz Brandenburg, Diplom-Ingenieur - -**1987:** Fraunhofer IIS entwickelt MPEG-1 Audio Layer III - -**1988:** Patentanmeldung - -**1992:** Erste Software-Implementierung - -**1995:** .mp3 Dateiendung offiziell - - - ---- - -![bg](./assets/suzanne-vega.jpg) - - - ---- - -# "Tom's Diner" - -**Warum dieser Song?** - -- A cappella (keine Instrumente) -- Suzanne Vegas Stimme ist "schwierig" -- Klare, hohe Frequenzen → Stresstest - -*"If I could code Suzanne Vega's voice well, I could code anything."* -— Karlheinz Brandenburg - - - ---- - -# Wie funktioniert MP3? - -**1. Frequenz-Analyse (FFT)** -Audio → Frequenzspektrum - -**2. Psychoakustisches Modell** -Welche Töne hört Mensch nicht? - -**3. Quantisierung** -Unwichtige Frequenzen reduzieren - -**4. Huffman-Coding** -Lossless-Kompression der Restdaten - - - ---- - -# Bitrate: Der Qualitäts-Knopf - -| Bitrate | Qualität | Kompression | -|---------|----------|-------------| -| **128 kbps** | Hörbar schlechter | ~11x | -| **192 kbps** | Akzeptabel | ~7x | -| **256 kbps** | Gut | ~5,5x | -| **320 kbps** | "CD-Qualität" | ~4,4x | - -**Original CD:** 1.411 kbps (unkomprimiert) - - - ---- - -![bg](./assets/audio-spectrogram.jpg) - - - ---- - -# Der Patentkrieg - -**1990er:** Fraunhofer + Thomson halten MP3-Patente - -**Lizenzgebühren:** -- $0,75 pro Decoder -- $2,50 pro Encoder - -**Problem:** Napster (1999) → unkontrollierte Verbreitung - -**2017:** Patente laufen aus → MP3 ist frei - - - ---- - -![bg](./assets/napster-interface.jpg) - - - ---- - -# Napster & Musikindustrie - -**1999:** Napster startet -**2001:** 80 Millionen User - -**Musikindustrie:** -- CDs kosten $15-20 -- MP3s gratis (illegal, aber egal) -- Einzelne Songs statt Alben - -**2001:** Napster verklagt, geschlossen - -**Aber:** Pandora's Box offen -→ LimeWire, Kazaa, BitTorrent, später Spotify - - - ---- - -# Kulturelle Revolution - -**MP3 veränderte:** - -✓ Musik wurde portabel (Walkman → iPod) -✓ Alben wurden irrelevant (Playlists) -✓ Musikkonsum explodierte (kostenlos/billig) -✓ Künstler verloren Kontrolle - -**Aber auch:** -❌ Künstler verdienen weniger pro Stream -❌ Audio-Qualität sank (Loudness War) -❌ Physische Medien starben - - - ---- - -# Hands-On: MP3 sezieren - -**Aufgabe (30 Min):** - -1. Lade Lied runter (eigenes oder CC) -2. Konvertiere in verschiedene Bitraten: - - 320 kbps, 128 kbps, 64 kbps -3. Tool: Audacity (kostenlos) -4. Höre Unterschiede (Kopfhörer!) -5. Vergleiche Dateigrößen - -**Optional:** Spektrogramm-Ansicht - - - ---- - -# Aufgabe bis nächste Woche - -**Nimm ein Lied (eigenes oder CC)** - -1. Exportiere: WAV, MP3 320 kbps, MP3 128 kbps -2. Notiere: Dateigrößen, Höreindrücke -3. Poste im Forum: Screenshot + Reflexion - -**Bonus:** Niedrigste Bitrate finden, bei der du keinen Unterschied hörst - - - ---- - - - -# Termin 2 – 09.01.2026 -## Bild-, Audio- & Videoformate - ---- - -![bg](./assets/photo-comparison.jpg) - - - ---- - -# Was ist ein Bild? - -**Digital = Pixelraster** - -**Beispiel: 1920×1080 (Full HD)** -= 2.073.600 Pixel - -**Jedes Pixel = 3 Bytes (RGB)** -2.073.600 × 3 = **6,2 MB** - -**Für EIN Foto!** - - - ---- - -# Lossless: PNG - -**PNG = Portable Network Graphics (1996)** - -**Funktionsweise:** -- Vorhersage (Pixel ähneln Nachbarn) -- Differenz-Encoding -- DEFLATE-Algorithmus (wie ZIP) - -**Kompression:** 20-50% Ersparnis - -**Gut für:** Screenshots, Logos, Text -**Schlecht für:** Fotos - - - ---- - -# Lossy: JPEG - -**JPEG = Joint Photographic Experts Group (1992)** - -**Eigenschaften:** -- Lossy Kompression -- 90%+ Platzersparnis möglich -- Artefakte bei hoher Kompression - -**6 MB → 500 KB** (typisch) - - - ---- - -![bg](./assets/jpeg-artifacts.jpg) - - - ---- - -# Wie funktioniert JPEG? (1/2) - -**Schritt 1: RGB → YCbCr** -- Y = Helligkeit (Luminanz) -- Cb/Cr = Farbe (Chrominanz) - -**Warum?** Menschen sehen Helligkeit besser als Farbe - -**Schritt 2: Chroma Subsampling** -Farbauflösung reduzieren (4:2:0) -→ 50% Datenmenge weg, kaum sichtbar - - - ---- - -# Wie funktioniert JPEG? (2/2) - -**Schritt 3: DCT (Discrete Cosine Transform)** -Bild in 8×8-Blöcke → Frequenzspektrum - -**Schritt 4: Quantisierung** -Hohe Frequenzen (Details) stark reduzieren -→ **Hier passiert Datenverlust!** - -**Schritt 5: Huffman-Coding** -Lossless-Kompression der Restdaten - - - ---- - -# JPEG Quality - -| Quality | Dateigröße | Artefakte | -|---------|------------|-----------| -| **100** | ≈2-3 MB | Kaum | -| **85-90** | ≈200-400 KB | Minimal | -| **50** | ≈100 KB | Sichtbar | - -**Sweet Spot: 85-90** -10x Kompression, für Menschen kaum unterscheidbar - - - ---- - -![bg](./assets/gif-animation.gif) - - - ---- - -# Die GIF-Geschichte - -**GIF = Graphics Interchange Format (1987)** -CompuServe (US-Online-Dienst) - -**Features:** -- 256 Farben max (8-bit Palette) -- Lossless (für Palette) -- Animationen! - -**1994 Twist:** Unisys hält Patent auf LZW-Kompression -→ Fordert Lizenzgebühren - -→ **"Burn All GIFs!" Kampagne** - - - ---- - -# PNG vs. GIF - -**GIF:** -✓ Animationen -✓ Breite Unterstützung -❌ Nur 256 Farben -❌ Patent-Probleme (bis 2003) - -**PNG:** -✓ Millionen Farben -✓ Alpha-Transparenz -✓ Patent-frei -❌ Keine Animationen (bis APNG, 2004) - -**Ergebnis:** PNG für Grafiken, GIF für Memes! - - - ---- - -# WebP & AVIF - -**WebP (Google, 2010):** -- Lossy UND Lossless -- Animationen -- 25-35% kleiner als JPEG - -**AVIF (2019):** -- Basiert auf AV1-Video-Codec -- 50% kleiner als JPEG -- HDR-Unterstützung -- Patent-frei - -**Problem:** Browser-Support dauert Jahre - - - ---- - -![bg](./assets/instagram-quality-loss.jpg) - - - ---- - -# Warum Instagram eure Fotos "ruiniert" - -**Upload-Pipeline:** -1. Dein Foto: 12 MP, 8 MB -2. Instagram skaliert: max. 1080px -3. Re-Kompression: JPEG Quality ~75 -4. Endgröße: 200-400 KB - -**Warum?** -- Speicherkosten (Milliarden Fotos!) -- Ladezeiten (Mobile) -- Bandbreite (günstiger) - - - ---- - -# Hands-On: Kompression vergleichen - -**Aufgabe (40 Min):** - -1. Hochauflösendes Foto (eigenes oder CC) -2. Exportiere: - - PNG - - JPEG Q100, Q85, Q50 - - WebP (optional) -3. Tool: **Squoosh.app** (Google-Tool) -4. Vergleiche: Dateigrößen, sichtbare Unterschiede -5. Wo werden Artefakte sichtbar? - - - ---- - -# Aufgabe bis nächste Woche - -**Nimm ein Foto (eigenes oder CC)** - -1. Exportiere: PNG, JPEG Q90, JPEG Q50 -2. Vergleiche Größen & Qualität -3. Poste im Forum: Screenshot + Reflexion - -**Fragen:** -- Welche Quality ist für dich "akzeptabel"? -- Wo siehst du zuerst Artefakte? - -**Bonus:** Teste WebP oder AVIF - - - ---- - - - -# Teil 2: Video -## Kompression & Codecs - ---- - -![bg](./assets/netflix-4k.jpg) - - - ---- - -# Das Problem: Video ist RIESIG - -**1 Minute 4K-Video (3840×2160):** - -- 30 fps (Bilder/Sekunde) -- Jedes Bild: 24,8 MB (unkomprimiert) - -**Rechnung:** -30 × 24,8 MB = **744 MB/Sekunde** -× 60 Sekunden = **44,6 GB/Minute** - -**2-Stunden-Film: 5,3 TB!** - - - ---- - -# Container vs. Codec - -**Container = Die Box** -Verpackt Video, Audio, Untertitel, Metadaten - -**Beispiele:** MP4, MKV, AVI, MOV - -**Codec = Kompressionsalgorithmus** -Entscheidet, WIE Daten komprimiert werden - -**Video-Codecs:** H.264, H.265, VP9, AV1 -**Audio-Codecs:** AAC, MP3, Opus - - - ---- - -![bg](./assets/container-codec-diagram.jpg) - - - ---- - -# Video-Kompression: Drei Prinzipien - -**1. Spatial Compression (Intra-Frame)** -Jedes Bild einzeln (wie JPEG) -→ I-Frames - -**2. Temporal Compression (Inter-Frame)** -Nur Änderungen zwischen Bildern -→ P-Frames, B-Frames - -**3. Motion Compensation** -"Ball bewegt sich von A nach B" - - - ---- - -# I-Frames, P-Frames, B-Frames - -**I-Frame (Intra):** -Vollständiges Bild (wie JPEG) -Groß, aber unabhängig - -**P-Frame (Predicted):** -Referenziert vorherige Frames -Viel kleiner - -**B-Frame (Bi-directional):** -Referenziert vorherige UND zukünftige Frames -Am effizientesten - -**GOP:** I - B - B - P - B - B - P - B - B - I - - - ---- - -![bg](./assets/iframe-pframe-diagram.jpg) - - - ---- - -# H.264: Der König - -**H.264 / AVC (2003)** - -**Warum dominant?** -✓ Exzellente Kompression (100:1 möglich) -✓ Hardware-Support (jedes Gerät seit ~2010) -✓ YouTube, Netflix, Blu-ray – alles H.264 - -**Features:** -- Variable Block-Größen (16×16 bis 4×4) -- Deblocking-Filter -- CABAC-Coding - - - ---- - -# Das Patent-Problem - -**H.264 ist NICHT frei!** - -**MPEG-LA (Patent Pool):** -- 2.000+ Patente von ~30 Unternehmen -- Apple, Microsoft, Sony, Panasonic... - -**Lizenzgebühren:** -- Hardware-Decoder: $0,20/Einheit -- Content-Distribution: Kostenlos für "Internet Broadcast" - -**Problem:** Open-Source-Projekte in Grauzone - - - ---- - -# H.265 / HEVC - -**H.265 (2013):** -50% bessere Kompression als H.264 - -**ABER:** Patent-Desaster - -**Drei (!) konkurrierende Patent-Pools:** -- MPEG-LA -- HEVC Advance -- Velos Media - -→ Viele bleiben bei H.264 oder suchen Alternativen - - - ---- - -![bg](./assets/youtube-vp9.jpg) - - - ---- - -# VP9: Googles Antwort - -**VP9 (2013):** -Entwickelt von Google (On2-Akquisition) - -**Eigenschaften:** -✓ Ähnlich H.265-Kompression -✓ KOSTENLOS, patent-frei (laut Google) -✓ YouTube nutzt VP9 für 4K - -**Nachteile:** -❌ Hardware-Support langsam -❌ Höherer CPU-Aufwand -❌ Nicht universell wie H.264 - - - ---- - -![bg](./assets/av1-logo.jpg) - - - ---- - -# AV1: Die Open-Source-Revolution - -**AV1 (2018):** -Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla... - -**Ziel:** Patent-freier, moderner Codec - -**Features:** -✓ 30% besser als H.265 -✓ Royalty-free, Open Source -✓ 8K, HDR, hohe Frame-Rates - -**Stand 2025:** -YouTube, Netflix nutzen AV1 für 4K/8K - - - ---- - -# Adaptive Bitrate Streaming - -**Problem:** Internet-Geschwindigkeit variiert - -**Lösung:** Mehrere Qualitäten parallel - -**MPEG-DASH / HLS:** -- 4K (20 Mbps) -- 1080p (5 Mbps) -- 720p (2,5 Mbps) -- 480p (1 Mbps) -- 240p (0,5 Mbps) - -Segmente: 2-10 Sekunden -Player wählt dynamisch - - - ---- - -![bg](./assets/streaming-quality-switch.jpg) - - - ---- - -# Container im Detail - -**MP4:** -- Standard für Web, Mobile -- H.264, H.265, AV1 -- DRM-fähig - -**MKV (Matroska):** -- Open Source, extrem flexibel -- Beliebig viele Audio-/Untertitel-Spuren -- Fast jeden Codec - -**WebM:** -- Google, Web-optimiert -- Nur VP9/AV1 + Opus/Vorbis - - - ---- - -# Hands-On: Video analysieren - -**Aufgabe (40 Min):** - -**Tool:** FFmpeg (CLI) oder HandBrake (GUI) - -1. Download: CC-Video (Big Buck Bunny, ~1 Min) -2. Analysiere: `ffmpeg -i video.mp4` oder MediaInfo -3. Notiere: Container, Codec, Bitrate, Auflösung -4. Konvertiere: - - H.264, 1080p, 5 Mbps - - H.265, 1080p, 2,5 Mbps -5. Vergleiche: Größen, Encoding-Zeit, Qualität - - - ---- - -# Aufgabe bis nächste Woche - -**Nimm kurzes Video (eigenes oder CC, max. 1 Min)** - -1. Analysiere: Container, Codecs, Bitrate -2. Konvertiere: H.264 + H.265 (gleiche Qualität) -3. Poste im Forum: - - Dateigrößen - - Encoding-Zeiten - - Visueller Unterschied? - -**Bonus:** AV1-Encoding (Warnung: SEHR langsam!) - - - ---- - - - -# Termin 3 – 23.01.2026 -## Speichermedien & Schnittstellen - ---- - -![bg](./assets/hdd-ssd-comparison.jpg) - - - ---- - -# Rückblick: HDD vs. SSD - -**HDD:** -- Mechanisch, magnetisch -- Langsam (~150 MB/s) -- Günstig (~20€/TB) -- Empfindlich (Stöße!) - -**SSD:** -- Elektronisch, Flash -- Schnell (~500-7.000 MB/s) -- Teuer (~80-150€/TB) -- Write-Zyklen begrenzt - - - ---- - -# Was fehlt? Dateisysteme! - -**Dateisystem = Bibliothekskatalog für Festplatte** - -**Aufgaben:** -- Dateien speichern & finden -- Metadaten verwalten -- Speicherplatz effizient nutzen -- Fehler erkennen & beheben - - - ---- - -![bg](./assets/directory-tree.jpg) - - - ---- - -# Partitionen & Volumes - -**Partition:** -Zusammenhängender Bereich auf Festplatte - -**Volume:** -Logische Einheit mit Dateisystem - -**Beispiel:** -1 TB HDD → 2 Partitionen -- 500 GB Windows (NTFS) -- 500 GB Daten (exFAT) - - - ---- - -# Formatierung - -**Schnellformatierung:** -- Löscht nur Metadaten -- Daten physisch noch da -- → Datenrettung möglich! - -**Vollständige Formatierung:** -- Überschreibt mit Nullen -- Dauert länger, aber sicherer - - - ---- - -# FAT (File Allocation Table) - -**Geschichte:** 1977, Microsoft - -**Versionen:** -- FAT16: Max. 2 GB -- FAT32: Max. 4 GB Dateien, 2 TB Partitionen -- exFAT: Keine 4 GB-Grenze - -**Vorteil:** Universelle Kompatibilität - -**Nachteil:** Keine Rechte, kein Journaling - - - ---- - -# NTFS - -**NTFS = New Technology File System (1993)** - -**Features:** -✓ Dateien >4 GB (bis 16 EB) -✓ Zugriffsrechte (ACLs) -✓ Journaling (Crash-Schutz) -✓ Kompression & Verschlüsselung -✓ Shadow Copies - -**Nachteil:** Proprietär (nur Windows nativ) - - - ---- - -# APFS - -**Apple File System (2017)** - -**Features:** -✓ Copy-on-Write (Speicherersparnis!) -✓ Snapshots (Time Machine) -✓ Native Verschlüsselung -✓ SSD-optimiert - -**Nachteil:** Nur Apple-Geräte - - - ---- - -# ext4 - -**Fourth Extended File System (2008)** -Linux-Standard - -**Features:** -✓ Journaling -✓ Extents (schneller) -✓ Max. 16 TB Dateien, 1 EB Partitionen -✓ Online-Defragmentierung - -**Nachteil:** Windows/macOS können nicht nativ lesen - - - ---- - -# Dateisysteme: Vergleich - -| FS | OS | Max. Datei | Features | -|----|----|-----------:|----------| -| FAT32 | Alle | 4 GB | Kompatibilität | -| exFAT | Alle | 16 EB | Flash-optimiert | -| NTFS | Win | 16 EB | Journaling, ACLs | -| APFS | macOS | 8 EB | Snapshots, CoW | -| ext4 | Linux | 16 TB | Journaling | - - - ---- - -![bg](./assets/backup-disaster.jpg) - - - ---- - -# Backup: Warum? - -**Realität:** -- Festplatten sterben ohne Vorwarnung -- Ransomware verschlüsselt Daten -- Versehentliches Löschen -- Diebstahl, Brand, Wasserschaden - -**Faustregel: 3-2-1** -Mindestens 3 Kopien, auf mindestens 2 unterschiedlichen Speichermedien und mindestens 1 an einem anderen Ort - - - ---- - -# Backup-Arten - -**Vollständig (Full):** -Kompletter Datenbestand -Langsam, aber einfach - -**Inkrementell:** -Nur Änderungen seit letztem Backup -Schnell, aber Wiederherstellung komplex - -**Differenziell:** -Änderungen seit letztem Voll-Backup -Mittelweg - - - ---- - -# 3-2-1-Regel - -**3** Kopien (Original + 2 Backups) - -**2** verschiedene Medientypen (SSD + HDD) - -**1** Offsite-Backup (Cloud, externes Lager) - -**Beispiel:** -Laptop + externe Festplatte + Cloud - - - ---- - -# Backup-Software - -**macOS:** Time Machine -**Windows:** Veeam Agent (kostenlos) -**Linux:** rsync, Borg, Restic -**Plattformübergreifend:** Duplicati, Syncthing -**Cloud:** Backblaze, Nextcloud - - - ---- - -![bg](./assets/bit-rot.jpg) - - - ---- - -# Langzeitarchivierung: Das Problem - -**Digitale Daten altern:** -- Bit Rot (Degradation) -- Format-Obsoleszenz (WordPerfect .wpd) -- Hardware-Obsoleszenz (Diskettenlaufwerke) - -**Lösung:** -Migration + offene Standards - - - ---- - -![bg](./assets/lto-tape.jpg) - - - ---- - -# Magnetbänder (LTO) - -**Linear Tape-Open:** - -- LTO-9 (2021): 18 TB nativ, 45 TB komprimiert -- Haltbarkeit: 30 Jahre -- Kosten: ~5€/TB (Laufwerk ~5.000€) -- Nutzung: Rechenzentren, Archive - -**Air-Gap-Sicherheit:** -Offline-Band kann nicht von Ransomware verschlüsselt werden - - - ---- - -![bg](./assets/m-disc.jpg) - - - ---- - -# M-DISC (Millennial Disc) - -**Eigenschaften:** -- DVD/Blu-ray-kompatibel -- Anorganische Metallschicht -- Haltbarkeit: 1.000 Jahre (Tests) -- Einsatz: Familienfotos, Archive - - - ---- - -![bg](./assets/dna-helix.jpg) - - - ---- - -# DNA-Storage (Zukunft) - -**Konzept:** Daten in DNA-Sequenzen - -**Eigenschaften:** -- Speicherdichte: 215 Petabyte/Gramm (!!) -- Haltbarkeit: Tausende Jahre -- Kosten: Aktuell $3.500/MB - -**Beispiele:** -Microsoft + Twist Bioscience -Netflix "Biohackers"-Episode (2021) - - - ---- - -# Hands-On: S.M.A.R.T. & Backup - -**Aufgabe 1 (20 Min):** -S.M.A.R.T.-Daten auslesen -- Windows: CrystalDiskInfo -- macOS/Linux: `smartctl -a /dev/sda` -- Notiere: Health, Power-On Hours, Temp - -**Aufgabe 2 (20 Min):** -Test-Backup erstellen -- rsync (Linux/macOS) oder Robocopy (Windows) -- Simuliere Datenverlust → Wiederherstellung - - - ---- - -# Aufgabe bis nächste Woche - -**Analysiere dein System:** - -1. Welches Dateisystem nutzt deine Hauptpartition? -2. Hast du ein Backup? Welche Art? Wo? -3. Poste im Forum: S.M.A.R.T.-Screenshot + Backup-Strategie - -**Bonus:** Richte automatisches Backup ein - - - ---- - - - -# Teil 2: Schnittstellen -## USB-C, HDMI & das Kabel-Chaos - ---- - -![bg](./assets/cable-mess.jpg) - - - ---- - -# Was ist eine Schnittstelle? - -**Schnittstelle = Verbindung zwischen Systemen** - -**Hardware-Schnittstellen:** -Physischer Anschluss (USB, HDMI, Ethernet) - -**Software-Schnittstellen:** -API (nächste Woche!) - -**Heute:** Hardware-Fokus - - - ---- - -![bg](./assets/pc-back-1990s.jpg) - - - ---- - -# USB: Die Idee - -**Universal Serial Bus (1996)** - -**Ziel:** Ein Kabel für alles - -**Vorher:** -- PS/2 (Maus, Tastatur) -- Seriell (Modem) -- Parallel (Drucker) -- SCSI (Festplatten) - -**USB-Versprechen:** -✓ Ein Stecker, Hot-Pluggable, Stromversorgung - - - ---- - -# USB-Versionen: Chaos - -| Version | Jahr | Geschwindigkeit | Marketing-Name | -|---------|------|----------------:|----------------| -| USB 1.0 | 1996 | 12 Mbps | – | -| USB 2.0 | 2000 | 480 Mbps | Hi-Speed | -| USB 3.0 | 2008 | 5 Gbps | USB 3.2 Gen 1 | -| USB 3.1 | 2013 | 10 Gbps | USB 3.2 Gen 2 | -| USB 3.2 | 2017 | 20 Gbps | USB 3.2 Gen 2×2 | -| USB 4 | 2019 | 40 Gbps | USB4 | - -**NIEMAND versteht das mehr!** - - - ---- - -![bg](./assets/usb-c-cables.jpg) - - - ---- - -# USB-C: Stecker ≠ Geschwindigkeit - -**USB-C = Physischer Stecker (2014)** - -**Eigenschaften:** -✓ Reversibel (beide Seiten gleich) -✓ 24 Pins (vs. 4 bei USB-A) -✓ Unterstützt: Daten, Strom, Video, Audio - -**ABER:** USB-C sagt NICHTS über Geschwindigkeit! - -Ein USB-C-Kabel kann sein: -- USB 2.0 (480 Mbps) 😱 -- USB 3.2 Gen 2 (10 Gbps) -- USB 4 (40 Gbps) -- Thunderbolt 3/4 (40 Gbps) -- Oder nur Power Delivery (Laden, keine Daten!) - - - ---- - -# USB Power Delivery - -**USB PD (über USB-C):** - -- Profile: 5V bis 20V -- Max. 5A -- Bis zu **240W** (USB PD 3.1, 2021) - -**Anwendungen:** -- Laptop-Ladung (60-100W) -- Monitor mit Stromversorgung -- Docking-Stations - -**Problem:** Nicht jedes Kabel unterstützt volles PD! - - - ---- - -# USB-C: Das Wirrwarr - -**Was ein USB-C-Kabel KÖNNEN KANN:** - -**Daten:** USB 2.0 bis USB4 (40 Gbps) - -**Strom:** 5W bis 240W - -**Video:** DisplayPort Alt Mode, HDMI Alt Mode - -**Audio:** USB Audio Class - -**Problem:** Am Kabel steht's oft NICHT drauf! - - - ---- - -![bg](./assets/thunderbolt-logo.jpg) - - - ---- - -# Thunderbolt: Premium-Schnittstelle - -**Thunderbolt (Intel + Apple):** - -- Thunderbolt 3/4 (2015/2020): USB-C, 40 Gbps -- **PCIe über Kabel** → externe GPUs! -- Daisychaining (bis 6 Geräte) -- 100W Power Delivery garantiert - -**Nachteile:** -❌ Teuer (Kabel: 30-80€) -❌ Lizenzgebühren (Intel) -❌ Nur High-End-Geräte - - - ---- - -![bg](./assets/hdmi-cable.jpg) - - - ---- - -# HDMI: Der Heimkino-Standard - -**HDMI (2002):** -Entwickelt von Sony, Panasonic, Toshiba... - -**Versionen:** -- HDMI 1.4 (2009): 4K @ 30 Hz, ARC -- HDMI 2.0 (2013): 4K @ 60 Hz, HDR -- HDMI 2.1 (2017): 8K @ 60 Hz, 4K @ 120 Hz, VRR - -**Features:** -✓ Audio + Video in einem Kabel -✓ HDCP (Copy Protection) -✓ CEC (Gerätesteuerung) - -**Nachteile:** -❌ Proprietär, Lizenzgebühren -❌ Keine Daisychaining - - - ---- - -![bg](./assets/displayport-cable.jpg) - - - ---- - -# DisplayPort: Die PC-Alternative - -**DisplayPort (2006):** -VESA (Video Electronics Standards Association) - -**Versionen:** -- DP 1.4 (2016): 8K @ 60 Hz, HDR -- DP 2.0 (2019): 16K @ 60 Hz, 8K @ 120 Hz - -**Vorteile:** -✓ Lizenzfrei (keine Gebühren!) -✓ Daisychaining (Multi-Monitor) -✓ Adaptive Sync (FreeSync, G-Sync) -✓ USB-C Alt Mode - -**Nachteil:** Weniger verbreitet in TVs - - - ---- - -# HDMI vs. DisplayPort - -| Feature | HDMI 2.1 | DisplayPort 2.0 | -|---------|----------|-----------------| -| **Max. Auflösung** | 8K @ 60 Hz | 16K @ 60 Hz | -| **Lizenz** | Ja (~$10k/Jahr) | Nein | -| **Daisychaining** | Nein | Ja | -| **Adaptive Sync** | VRR (neu) | Ja (nativ) | -| **USB-C** | Alt Mode (selten) | Alt Mode (häufig) | -| **Verbreitung** | TVs dominant | PCs/Monitore | - - - ---- - -![bg](./assets/hdcp-warning.jpg) - - - ---- - -# HDCP: Copy Protection - -**HDCP = High-bandwidth Digital Content Protection** - -**Was ist das?** -- DRM für Video-Signale -- Verschlüsselt zwischen Quelle und Display -- Verhindert "Man-in-the-Middle"-Aufnahme - -**Problem:** -- Alte Monitore: Kein HDCP 2.2 → 4K-Netflix funktioniert nicht! -- Capture-Cards oft blockiert -- "HDCP-Handshake-Fehler" → Schwarzer Bildschirm - -**Kritik:** Schikaniert ehrliche Nutzer, Piraten umgehen es leicht - - - ---- - -![bg](./assets/ethernet-cable.jpg) - - - ---- - -# Ethernet: Das Netzwerkkabel - -**Ethernet (1980er):** - -**Versionen:** -- 100BASE-TX (1995): 100 Mbps -- 1000BASE-T (1999): 1 Gbps (Gigabit) -- 10GBASE-T (2006): 10 Gbps - -**Kabel-Kategorien:** -- Cat5e: bis 1 Gbps (veraltet) -- Cat6: bis 10 Gbps (55m) -- Cat6a: bis 10 Gbps (100m) - -**Stecker:** RJ45 (8P8C) - - - ---- - -![bg](./assets/vintage-ports.jpg) - - - ---- - -# Veraltete Schnittstellen - -**Seriell (RS-232):** 1960er, 115,2 kbps, Modems -**Parallel (LPT):** Drucker, 8 Bits gleichzeitig -**PS/2:** Maus + Tastatur (1987-2010er) -**VGA:** Analoges Video (1987-2010er) - -**Heute:** Manchmal noch auf Mainboards (Legacy-Support) - - - ---- - -# Hands-On: Schnittstellen identifizieren - -**Aufgabe (30 Min):** - -1. Untersuche deinen Laptop/Desktop -2. Welche Anschlüsse vorhanden? -3. Für USB-C: Welche Features? (Daten, Video, Laden?) -4. Teste: Schließe Gerät an verschiedenen Ports an -5. Dokumentiere: Foto + Beschriftung - -**Tools:** Systeminfo (Win), System Report (Mac), lsusb (Linux) - - - ---- - -# Aufgabe bis nächste Woche - -**Analysiere deine Kabel:** - -1. Liste alle Kabel (USB, HDMI, etc.) -2. Identifiziere: Standard, Geschwindigkeit, Features -3. Ist es beschriftet? Verständlich? -4. Poste im Forum: Foto + das verwirrendste Kabel - -**Bonus:** Finde USB-C-Kabel, das nur USB 2.0 kann - - - ---- - - - -# Termin 4 – 30.01.2026 -## Distribution, APIs & Zukunft - ---- - -![bg](./assets/sneakernet-truck.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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 - - - ---- - -![bg](./assets/cd-dvd-bluray.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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) - - - ---- - -![bg](./assets/cdn-map.jpg) - - - ---- - -# 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 - - - ---- - -![bg](./assets/netflix-openconnect.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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 - - - ---- - -![bg](./assets/bittorrent-swarm.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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 - - - ---- - -# Aufgabe bis nächste Woche - -**Analysiere Streaming-Dienst oder Website:** - -1. Wähle: Netflix, YouTube, Spotify, News-Seite -2. DevTools (Network-Tab): - - Welcher CDN? - - Wie viele Requests an CDN vs. Origin? - - Cache-Headers? -3. Poste im Forum: Screenshot + Erkenntnisse - -**Bonus:** Linux-ISO via Torrent, poste Peer-Stats - - - ---- - - - -# Teil 2: APIs -## Software-Schnittstellen & Protokolle - ---- - -![bg](./assets/api-diagram.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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 - - - ---- - -# Aufgabe bis nächste Woche - -**Experimentiere mit öffentlicher API:** - -1. Wähle: - - GitHub API (`api.github.com`) - - OpenWeather (`openweathermap.org/api`) - - PokéAPI (`pokeapi.co`) -2. Mache 3-5 Requests (curl, Postman, oder Code) -3. Poste im Forum: - - Welche API? - - Interessante Daten? - - Rate-Limiting erlebt? (429 Too Many Requests) - -**Bonus:** Baue kleinen Client (Python, JavaScript, etc.) - - - ---- - - - -# Teil 3: Metadaten -## Daten über Daten & Interoperabilität - ---- - -![bg](./assets/exif-gps.jpg) - - - ---- - -# 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 - - - ---- - -![bg](./assets/mcafee-exif-fail.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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 ``) - - - ---- - -![bg](./assets/pdf-metadata-leak.jpg) - - - ---- - -# 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 -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) - - - ---- - -# Aufgabe bis nächste Woche - -**Metadaten-Audit:** - -1. Wähle 3 Dateitypen: - - Ein Foto (EXIF) - - Eine MP3 (ID3) - - Ein PDF (XMP) -2. Analysiere: Welche Metadaten? -3. Poste im Forum: - - Screenshots (OHNE sensible Infos!) - - Überraschungen? - - Wie viel KB gespart nach Entfernung? - -**Bonus:** Finde alte Datei (>5 Jahre) – was verraten Metadaten über damaliges Setup? - - - ---- - - - -# Teil 4: Zukunft -## Trends & Ausblick - ---- - -![bg](./assets/futuristic-datacenter.jpg) - - - ---- - -# Rückblick: 9 Wochen - -**Woche 1:** Bits → Bytes → Bedeutung (Encoding) -**Woche 2:** MP3 & Psychoakustik -**Woche 3:** JPEG & GIF-Kriege -**Woche 4:** H.264 vs. AV1 -**Woche 5:** HDD vs. SSD, Dateisysteme, Backup -**Woche 6:** USB-C-Chaos, HDMI vs. DisplayPort -**Woche 7:** CDN, P2P, Streaming -**Woche 8:** REST, GraphQL, WebSockets -**Woche 9:** EXIF, Vendor Lock-in - -**Heute:** Wohin geht die Reise? - - - ---- - -# 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.jpg) - - - ---- - -# 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.jpg) - - - ---- - -# 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 (Forum, E-Mail) -- Weiterlernen mit Ressourcen - -**Vielen Dank für eure Aufmerksamkeit!** - - - ---- - - - -# Termin 5 – TBA -## Vertiefung & Offene Fragen - ---- - -# Ersatztermin - -**Dieser Termin wird noch bekannt gegeben.** - -Mögliche Inhalte: -- Vertiefung von Themen nach Wunsch -- Praxisübungen & Hands-On -- Offene Fragen & Diskussion -- Prüfungsvorbereitung - - - ---- - - - -# Fragen & Diskussion - -**Kontakt:** czechowski@hdm-stuttgart.de -**Folien:** Online verfügbar unter https://hdm.librete.ch - ---- - -# 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/ - - - diff --git a/slides/2025-12-19-termin-1-grundlagen-text-audio.md b/slides/2025-12-19-termin-1-grundlagen-text-audio.md new file mode 100644 index 0000000..68bde7c --- /dev/null +++ b/slides/2025-12-19-termin-1-grundlagen-text-audio.md @@ -0,0 +1,634 @@ +--- + + + +# Termin 1 – 19.12.2025 +## Grundlagen, Text & Audio + +--- + +![bg right:40%](./assets/matrix-code.jpg) + +# Mysterium + +``` +89 50 4E 47 0D 0A 1A 0A +00 00 00 0D 49 48 44 52 +00 00 01 90 00 00 01 2C +``` + +**Was ist das?** + + + +--- + +# Das Bit + +**Kleinste Informationseinheit** + +- **0 oder 1** +- AN oder AUS +- Strom fließt oder nicht + +![bg right:50%](./assets/lightbulb-onoff.jpg) + + + +--- + +# Das Byte + +**8 Bits = 1 Byte** + +``` +0 1 0 0 1 1 0 1 +``` + +**Wie viele Kombinationen?** +2⁸ = **256 Möglichkeiten** (0-255) + + + +--- + +# Was kann man mit 256 Zuständen machen? + +- **256 Zeichen** (Buchstaben, Zahlen, Symbole) +- **256 Graustufen** (0 = Schwarz, 255 = Weiß) +- **256 Lautstärkestufen** +- **Zahlen 0-255** (oder -128 bis +127) + +![bg left:40%](./assets/grayscale-gradient.jpg) + + + +--- + +# Farben: RGB-Modell + +**1 Pixel = 3 Bytes** + +- **Rot:** 0-255 +- **Grün:** 0-255 +- **Blau:** 0-255 + +**Beispiel:** +`FF 00 00` = Rot +`00 FF 00` = Grün +`FF FF FF` = Weiß + +![bg right:40%](./assets/rgb-color-model.jpg) + + + +--- + +# Das Problem: Sprachen + +**Die Welt hat mehr als 256 Zeichen!** + +- Englisches Alphabet: 52 (A-Z, a-z) +- + Ziffern: 10 (0-9) +- + Sonderzeichen: ~30 + +**≈ 90 Zeichen → passt in 1 Byte** + +**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀 + +→ **1 Byte reicht nicht!** + + + +--- + +![bg](./assets/ascii-table.png) + + + +--- + +# Unicode: Ein Standard für alle + +**Unicode (1991):** +Jedes Schriftsystem der Welt + +**>150.000 Zeichen:** +- Latein, Kyrillisch, Arabisch, Chinesisch, Japanisch... +- Mathematische Symbole, Emoji, historische Schriften + +**UTF-8:** Variable Länge (1-4 Bytes pro Zeichen) + + + +--- + +# Beispiel: Bytes zählen + +**Text:** `"Why the fuck braucht 💩 4 Bytes?!"` + +``` +W h y → je 1 Byte (4 Bytes) +t h e → je 1 Byte (4 Bytes) +f u c k → je 1 Byte (4 Bytes) + → 1 Byte (Leerzeichen) +b r a u c h t → je 1 Byte (7 Bytes) + → 1 Byte +💩 → 4 Bytes! (0xF0 9F 92 A9) + → 1 Byte +4 B y t e s ? ! → je 1 Byte (9 Bytes) +``` + +**Gesamt: 37 Bytes** + + + +--- + +# Hexadezimal: Lesbarkeit + +**Binär ist unleserlich:** +`01001101 01010000 00110011` + +**Hexadezimal (Base 16):** +`4D 50 33` (= "MP3" in ASCII) + +**Jede Hex-Ziffer = 4 Bits** +0-9, A-F (10=A, 11=B, ..., 15=F) + +![bg right:40%](./assets/hex-binary-table.jpg) + + + +--- + +# Magic Numbers + +**Dateityp-Identifikation durch erste Bytes** + +| Format | Magic Number (Hex) | ASCII | +|--------|-------------------|-------| +| PNG | `89 50 4E 47 0D 0A 1A 0A` | `.PNG` | +| JPEG | `FF D8 FF` | `ÿØÿ` | +| PDF | `25 50 44 46` | `%PDF` | +| ZIP | `50 4B 03 04` | `PK` | + + + +--- + +![bg](./assets/hexeditor-screenshot.png) + + + +--- + +# Hands-On: Mystery Files + +**Aufgabe (30 Min):** + +1. Drei Dateien ohne Extension: `mystery1`, `mystery2`, `mystery3` +2. Öffne im Hex-Editor +3. Lies erste 16 Bytes +4. Identifiziere Format (Magic Number) +5. Benenne um und öffne + +**Tools:** hexed.it (online), HxD, Hex Fiend, Bless + + + +--- + +# Aufgabe bis nächste Woche + +**Finde eine Datei auf deinem Computer** + +1. Öffne im Hex-Editor +2. Screenshot der ersten 16 Bytes +3. Identifiziere Magic Number +4. Poste im Forum: Format + kurze Beschreibung + +**Bonus:** Finde Datei ohne Magic Number in Standard-Listen + + + +--- + + + +# Teil 2: Die MP3-Revolution +## Psychoakustik & Audio-Kompression + +--- + +![bg](./assets/cassette-ipod.jpg) + + + +--- + +# Das Problem (1990) + +**1 Minute CD-Audio:** + +- Sample Rate: 44.100 Hz +- Bit Depth: 16 Bit +- Stereo: 2 Kanäle + +**Rechnung:** +44.100 × 16 × 2 = 1.411.200 Bits/Sekunde +≈ **10,6 MB/Minute** +≈ **635 MB für 60-Min-Album** + +**1990:** Festplatten hatten 100-500 MB! + + + +--- + +# Zwei Philosophien + +![bg right:50%](./assets/compression-types.jpg) + +**Lossless (Verlustfrei):** +- Original exakt wiederherstellbar +- ZIP, PNG, FLAC +- 30-50% Ersparnis + +**Lossy (Verlustbehaftet):** +- Daten irreversibel verändert +- JPEG, MP3, H.264 +- 90%+ Ersparnis + + + +--- + +# Lossless: Run-Length Encoding + +**Original:** +``` +AAAAABBBCCCCCCCC +``` + +**Komprimiert:** +``` +5A 3B 8C +``` + +**Ersparnis:** 16 → 6 Zeichen (62% Reduktion) + + + +--- + +# Lossy: Der Trick + +**Kernidee:** Wirf weg, was der Mensch eh nicht wahrnimmt + +**JPEG:** Schwächen des Auges +- Helligkeit besser als Farbe wahrgenommen +- Große Flächen besser als feine Details + +**MP3:** Schwächen des Ohrs +- Mittlere Frequenzen besser als hohe/tiefe +- Laute Töne "maskieren" leise Töne + +→ **Psychoakustik / Psychovisuell** + + + +--- + +![bg](./assets/karlheinz-brandenburg.jpg) + + + +--- + +# Die Geburt der MP3 + +**1982:** Universität Erlangen-Nürnberg +Karlheinz Brandenburg, Diplom-Ingenieur + +**1987:** Fraunhofer IIS entwickelt MPEG-1 Audio Layer III + +**1988:** Patentanmeldung + +**1992:** Erste Software-Implementierung + +**1995:** .mp3 Dateiendung offiziell + + + +--- + +![bg](./assets/suzanne-vega.jpg) + + + +--- + +# "Tom's Diner" + +**Warum dieser Song?** + +- A cappella (keine Instrumente) +- Suzanne Vegas Stimme ist "schwierig" +- Klare, hohe Frequenzen → Stresstest + +*"If I could code Suzanne Vega's voice well, I could code anything."* +— Karlheinz Brandenburg + + + +--- + +# Wie funktioniert MP3? + +**1. Frequenz-Analyse (FFT)** +Audio → Frequenzspektrum + +**2. Psychoakustisches Modell** +Welche Töne hört Mensch nicht? + +**3. Quantisierung** +Unwichtige Frequenzen reduzieren + +**4. Huffman-Coding** +Lossless-Kompression der Restdaten + + + +--- + +# Bitrate: Der Qualitäts-Knopf + +| Bitrate | Qualität | Kompression | +|---------|----------|-------------| +| **128 kbps** | Hörbar schlechter | ~11x | +| **192 kbps** | Akzeptabel | ~7x | +| **256 kbps** | Gut | ~5,5x | +| **320 kbps** | "CD-Qualität" | ~4,4x | + +**Original CD:** 1.411 kbps (unkomprimiert) + + + +--- + +![bg](./assets/audio-spectrogram.jpg) + + + +--- + +# Der Patentkrieg + +**1990er:** Fraunhofer + Thomson halten MP3-Patente + +**Lizenzgebühren:** +- $0,75 pro Decoder +- $2,50 pro Encoder + +**Problem:** Napster (1999) → unkontrollierte Verbreitung + +**2017:** Patente laufen aus → MP3 ist frei + + + +--- + +![bg](./assets/napster-interface.jpg) + + + +--- + +# Napster & Musikindustrie + +**1999:** Napster startet +**2001:** 80 Millionen User + +**Musikindustrie:** +- CDs kosten $15-20 +- MP3s gratis (illegal, aber egal) +- Einzelne Songs statt Alben + +**2001:** Napster verklagt, geschlossen + +**Aber:** Pandora's Box offen +→ LimeWire, Kazaa, BitTorrent, später Spotify + + + +--- + +# Kulturelle Revolution + +**MP3 veränderte:** + +✓ Musik wurde portabel (Walkman → iPod) +✓ Alben wurden irrelevant (Playlists) +✓ Musikkonsum explodierte (kostenlos/billig) +✓ Künstler verloren Kontrolle + +**Aber auch:** +❌ Künstler verdienen weniger pro Stream +❌ Audio-Qualität sank (Loudness War) +❌ Physische Medien starben + + + +--- + +# Hands-On: MP3 sezieren + +**Aufgabe (30 Min):** + +1. Lade Lied runter (eigenes oder CC) +2. Konvertiere in verschiedene Bitraten: + - 320 kbps, 128 kbps, 64 kbps +3. Tool: Audacity (kostenlos) +4. Höre Unterschiede (Kopfhörer!) +5. Vergleiche Dateigrößen + +**Optional:** Spektrogramm-Ansicht + + + +--- + +# Aufgabe bis nächste Woche + +**Nimm ein Lied (eigenes oder CC)** + +1. Exportiere: WAV, MP3 320 kbps, MP3 128 kbps +2. Notiere: Dateigrößen, Höreindrücke +3. Poste im Forum: Screenshot + Reflexion + +**Bonus:** Niedrigste Bitrate finden, bei der du keinen Unterschied hörst + + + diff --git a/slides/2026-01-09-termin-2-bild-audio-video.md b/slides/2026-01-09-termin-2-bild-audio-video.md new file mode 100644 index 0000000..f7e17c4 --- /dev/null +++ b/slides/2026-01-09-termin-2-bild-audio-video.md @@ -0,0 +1,686 @@ +--- + + + +# Termin 2 – 09.01.2026 +## Bild-, Audio- & Videoformate + +--- + +![bg](./assets/photo-comparison.jpg) + + + +--- + +# Was ist ein Bild? + +**Digital = Pixelraster** + +**Beispiel: 1920×1080 (Full HD)** += 2.073.600 Pixel + +**Jedes Pixel = 3 Bytes (RGB)** +2.073.600 × 3 = **6,2 MB** + +**Für EIN Foto!** + + + +--- + +# Lossless: PNG + +**PNG = Portable Network Graphics (1996)** + +**Funktionsweise:** +- Vorhersage (Pixel ähneln Nachbarn) +- Differenz-Encoding +- DEFLATE-Algorithmus (wie ZIP) + +**Kompression:** 20-50% Ersparnis + +**Gut für:** Screenshots, Logos, Text +**Schlecht für:** Fotos + + + +--- + +# Lossy: JPEG + +**JPEG = Joint Photographic Experts Group (1992)** + +**Eigenschaften:** +- Lossy Kompression +- 90%+ Platzersparnis möglich +- Artefakte bei hoher Kompression + +**6 MB → 500 KB** (typisch) + + + +--- + +![bg](./assets/jpeg-artifacts.jpg) + + + +--- + +# Wie funktioniert JPEG? (1/2) + +**Schritt 1: RGB → YCbCr** +- Y = Helligkeit (Luminanz) +- Cb/Cr = Farbe (Chrominanz) + +**Warum?** Menschen sehen Helligkeit besser als Farbe + +**Schritt 2: Chroma Subsampling** +Farbauflösung reduzieren (4:2:0) +→ 50% Datenmenge weg, kaum sichtbar + + + +--- + +# Wie funktioniert JPEG? (2/2) + +**Schritt 3: DCT (Discrete Cosine Transform)** +Bild in 8×8-Blöcke → Frequenzspektrum + +**Schritt 4: Quantisierung** +Hohe Frequenzen (Details) stark reduzieren +→ **Hier passiert Datenverlust!** + +**Schritt 5: Huffman-Coding** +Lossless-Kompression der Restdaten + + + +--- + +# JPEG Quality + +| Quality | Dateigröße | Artefakte | +|---------|------------|-----------| +| **100** | ≈2-3 MB | Kaum | +| **85-90** | ≈200-400 KB | Minimal | +| **50** | ≈100 KB | Sichtbar | + +**Sweet Spot: 85-90** +10x Kompression, für Menschen kaum unterscheidbar + + + +--- + +![bg](./assets/gif-animation.gif) + + + +--- + +# Die GIF-Geschichte + +**GIF = Graphics Interchange Format (1987)** +CompuServe (US-Online-Dienst) + +**Features:** +- 256 Farben max (8-bit Palette) +- Lossless (für Palette) +- Animationen! + +**1994 Twist:** Unisys hält Patent auf LZW-Kompression +→ Fordert Lizenzgebühren + +→ **"Burn All GIFs!" Kampagne** + + + +--- + +# PNG vs. GIF + +**GIF:** +✓ Animationen +✓ Breite Unterstützung +❌ Nur 256 Farben +❌ Patent-Probleme (bis 2003) + +**PNG:** +✓ Millionen Farben +✓ Alpha-Transparenz +✓ Patent-frei +❌ Keine Animationen (bis APNG, 2004) + +**Ergebnis:** PNG für Grafiken, GIF für Memes! + + + +--- + +# WebP & AVIF + +**WebP (Google, 2010):** +- Lossy UND Lossless +- Animationen +- 25-35% kleiner als JPEG + +**AVIF (2019):** +- Basiert auf AV1-Video-Codec +- 50% kleiner als JPEG +- HDR-Unterstützung +- Patent-frei + +**Problem:** Browser-Support dauert Jahre + + + +--- + +![bg](./assets/instagram-quality-loss.jpg) + + + +--- + +# Warum Instagram eure Fotos "ruiniert" + +**Upload-Pipeline:** +1. Dein Foto: 12 MP, 8 MB +2. Instagram skaliert: max. 1080px +3. Re-Kompression: JPEG Quality ~75 +4. Endgröße: 200-400 KB + +**Warum?** +- Speicherkosten (Milliarden Fotos!) +- Ladezeiten (Mobile) +- Bandbreite (günstiger) + + + +--- + +# Hands-On: Kompression vergleichen + +**Aufgabe (40 Min):** + +1. Hochauflösendes Foto (eigenes oder CC) +2. Exportiere: + - PNG + - JPEG Q100, Q85, Q50 + - WebP (optional) +3. Tool: **Squoosh.app** (Google-Tool) +4. Vergleiche: Dateigrößen, sichtbare Unterschiede +5. Wo werden Artefakte sichtbar? + + + +--- + +# Aufgabe bis nächste Woche + +**Nimm ein Foto (eigenes oder CC)** + +1. Exportiere: PNG, JPEG Q90, JPEG Q50 +2. Vergleiche Größen & Qualität +3. Poste im Forum: Screenshot + Reflexion + +**Fragen:** +- Welche Quality ist für dich "akzeptabel"? +- Wo siehst du zuerst Artefakte? + +**Bonus:** Teste WebP oder AVIF + + + +--- + + + +# Teil 2: Video +## Kompression & Codecs + +--- + +![bg](./assets/netflix-4k.jpg) + + + +--- + +# Das Problem: Video ist RIESIG + +**1 Minute 4K-Video (3840×2160):** + +- 30 fps (Bilder/Sekunde) +- Jedes Bild: 24,8 MB (unkomprimiert) + +**Rechnung:** +30 × 24,8 MB = **744 MB/Sekunde** +× 60 Sekunden = **44,6 GB/Minute** + +**2-Stunden-Film: 5,3 TB!** + + + +--- + +# Container vs. Codec + +**Container = Die Box** +Verpackt Video, Audio, Untertitel, Metadaten + +**Beispiele:** MP4, MKV, AVI, MOV + +**Codec = Kompressionsalgorithmus** +Entscheidet, WIE Daten komprimiert werden + +**Video-Codecs:** H.264, H.265, VP9, AV1 +**Audio-Codecs:** AAC, MP3, Opus + + + +--- + +![bg](./assets/container-codec-diagram.jpg) + + + +--- + +# Video-Kompression: Drei Prinzipien + +**1. Spatial Compression (Intra-Frame)** +Jedes Bild einzeln (wie JPEG) +→ I-Frames + +**2. Temporal Compression (Inter-Frame)** +Nur Änderungen zwischen Bildern +→ P-Frames, B-Frames + +**3. Motion Compensation** +"Ball bewegt sich von A nach B" + + + +--- + +# I-Frames, P-Frames, B-Frames + +**I-Frame (Intra):** +Vollständiges Bild (wie JPEG) +Groß, aber unabhängig + +**P-Frame (Predicted):** +Referenziert vorherige Frames +Viel kleiner + +**B-Frame (Bi-directional):** +Referenziert vorherige UND zukünftige Frames +Am effizientesten + +**GOP:** I - B - B - P - B - B - P - B - B - I + + + +--- + +![bg](./assets/iframe-pframe-diagram.jpg) + + + +--- + +# H.264: Der König + +**H.264 / AVC (2003)** + +**Warum dominant?** +✓ Exzellente Kompression (100:1 möglich) +✓ Hardware-Support (jedes Gerät seit ~2010) +✓ YouTube, Netflix, Blu-ray – alles H.264 + +**Features:** +- Variable Block-Größen (16×16 bis 4×4) +- Deblocking-Filter +- CABAC-Coding + + + +--- + +# Das Patent-Problem + +**H.264 ist NICHT frei!** + +**MPEG-LA (Patent Pool):** +- 2.000+ Patente von ~30 Unternehmen +- Apple, Microsoft, Sony, Panasonic... + +**Lizenzgebühren:** +- Hardware-Decoder: $0,20/Einheit +- Content-Distribution: Kostenlos für "Internet Broadcast" + +**Problem:** Open-Source-Projekte in Grauzone + + + +--- + +# H.265 / HEVC + +**H.265 (2013):** +50% bessere Kompression als H.264 + +**ABER:** Patent-Desaster + +**Drei (!) konkurrierende Patent-Pools:** +- MPEG-LA +- HEVC Advance +- Velos Media + +→ Viele bleiben bei H.264 oder suchen Alternativen + + + +--- + +![bg](./assets/youtube-vp9.jpg) + + + +--- + +# VP9: Googles Antwort + +**VP9 (2013):** +Entwickelt von Google (On2-Akquisition) + +**Eigenschaften:** +✓ Ähnlich H.265-Kompression +✓ KOSTENLOS, patent-frei (laut Google) +✓ YouTube nutzt VP9 für 4K + +**Nachteile:** +❌ Hardware-Support langsam +❌ Höherer CPU-Aufwand +❌ Nicht universell wie H.264 + + + +--- + +![bg](./assets/av1-logo.jpg) + + + +--- + +# AV1: Die Open-Source-Revolution + +**AV1 (2018):** +Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla... + +**Ziel:** Patent-freier, moderner Codec + +**Features:** +✓ 30% besser als H.265 +✓ Royalty-free, Open Source +✓ 8K, HDR, hohe Frame-Rates + +**Stand 2025:** +YouTube, Netflix nutzen AV1 für 4K/8K + + + +--- + +# Adaptive Bitrate Streaming + +**Problem:** Internet-Geschwindigkeit variiert + +**Lösung:** Mehrere Qualitäten parallel + +**MPEG-DASH / HLS:** +- 4K (20 Mbps) +- 1080p (5 Mbps) +- 720p (2,5 Mbps) +- 480p (1 Mbps) +- 240p (0,5 Mbps) + +Segmente: 2-10 Sekunden +Player wählt dynamisch + + + +--- + +![bg](./assets/streaming-quality-switch.jpg) + + + +--- + +# Container im Detail + +**MP4:** +- Standard für Web, Mobile +- H.264, H.265, AV1 +- DRM-fähig + +**MKV (Matroska):** +- Open Source, extrem flexibel +- Beliebig viele Audio-/Untertitel-Spuren +- Fast jeden Codec + +**WebM:** +- Google, Web-optimiert +- Nur VP9/AV1 + Opus/Vorbis + + + +--- + +# Hands-On: Video analysieren + +**Aufgabe (40 Min):** + +**Tool:** FFmpeg (CLI) oder HandBrake (GUI) + +1. Download: CC-Video (Big Buck Bunny, ~1 Min) +2. Analysiere: `ffmpeg -i video.mp4` oder MediaInfo +3. Notiere: Container, Codec, Bitrate, Auflösung +4. Konvertiere: + - H.264, 1080p, 5 Mbps + - H.265, 1080p, 2,5 Mbps +5. Vergleiche: Größen, Encoding-Zeit, Qualität + + + +--- + +# Aufgabe bis nächste Woche + +**Nimm kurzes Video (eigenes oder CC, max. 1 Min)** + +1. Analysiere: Container, Codecs, Bitrate +2. Konvertiere: H.264 + H.265 (gleiche Qualität) +3. Poste im Forum: + - Dateigrößen + - Encoding-Zeiten + - Visueller Unterschied? + +**Bonus:** AV1-Encoding (Warnung: SEHR langsam!) + + + diff --git a/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md new file mode 100644 index 0000000..3c04021 --- /dev/null +++ b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md @@ -0,0 +1,918 @@ +--- + + + +# Termin 3 – 23.01.2026 +## Speichermedien & Schnittstellen + +--- + +![bg](./assets/hdd-ssd-comparison.jpg) + + + +--- + +# Rückblick: HDD vs. SSD + +**HDD:** +- Mechanisch, magnetisch +- Langsam (~150 MB/s) +- Günstig (~20€/TB) +- Empfindlich (Stöße!) + +**SSD:** +- Elektronisch, Flash +- Schnell (~500-7.000 MB/s) +- Teuer (~80-150€/TB) +- Write-Zyklen begrenzt + + + +--- + +# Was fehlt? Dateisysteme! + +**Dateisystem = Bibliothekskatalog für Festplatte** + +**Aufgaben:** +- Dateien speichern & finden +- Metadaten verwalten +- Speicherplatz effizient nutzen +- Fehler erkennen & beheben + + + +--- + +![bg](./assets/directory-tree.jpg) + + + +--- + +# Partitionen & Volumes + +**Partition:** +Zusammenhängender Bereich auf Festplatte + +**Volume:** +Logische Einheit mit Dateisystem + +**Beispiel:** +1 TB HDD → 2 Partitionen +- 500 GB Windows (NTFS) +- 500 GB Daten (exFAT) + + + +--- + +# Formatierung + +**Schnellformatierung:** +- Löscht nur Metadaten +- Daten physisch noch da +- → Datenrettung möglich! + +**Vollständige Formatierung:** +- Überschreibt mit Nullen +- Dauert länger, aber sicherer + + + +--- + +# FAT (File Allocation Table) + +**Geschichte:** 1977, Microsoft + +**Versionen:** +- FAT16: Max. 2 GB +- FAT32: Max. 4 GB Dateien, 2 TB Partitionen +- exFAT: Keine 4 GB-Grenze + +**Vorteil:** Universelle Kompatibilität + +**Nachteil:** Keine Rechte, kein Journaling + + + +--- + +# NTFS + +**NTFS = New Technology File System (1993)** + +**Features:** +✓ Dateien >4 GB (bis 16 EB) +✓ Zugriffsrechte (ACLs) +✓ Journaling (Crash-Schutz) +✓ Kompression & Verschlüsselung +✓ Shadow Copies + +**Nachteil:** Proprietär (nur Windows nativ) + + + +--- + +# APFS + +**Apple File System (2017)** + +**Features:** +✓ Copy-on-Write (Speicherersparnis!) +✓ Snapshots (Time Machine) +✓ Native Verschlüsselung +✓ SSD-optimiert + +**Nachteil:** Nur Apple-Geräte + + + +--- + +# ext4 + +**Fourth Extended File System (2008)** +Linux-Standard + +**Features:** +✓ Journaling +✓ Extents (schneller) +✓ Max. 16 TB Dateien, 1 EB Partitionen +✓ Online-Defragmentierung + +**Nachteil:** Windows/macOS können nicht nativ lesen + + + +--- + +# Dateisysteme: Vergleich + +| FS | OS | Max. Datei | Features | +|----|----|-----------:|----------| +| FAT32 | Alle | 4 GB | Kompatibilität | +| exFAT | Alle | 16 EB | Flash-optimiert | +| NTFS | Win | 16 EB | Journaling, ACLs | +| APFS | macOS | 8 EB | Snapshots, CoW | +| ext4 | Linux | 16 TB | Journaling | + + + +--- + +![bg](./assets/backup-disaster.jpg) + + + +--- + +# Backup: Warum? + +**Realität:** +- Festplatten sterben ohne Vorwarnung +- Ransomware verschlüsselt Daten +- Versehentliches Löschen +- Diebstahl, Brand, Wasserschaden + +**Faustregel: 3-2-1** +Mindestens 3 Kopien, auf mindestens 2 unterschiedlichen Speichermedien und mindestens 1 an einem anderen Ort + + + +--- + +# Backup-Arten + +**Vollständig (Full):** +Kompletter Datenbestand +Langsam, aber einfach + +**Inkrementell:** +Nur Änderungen seit letztem Backup +Schnell, aber Wiederherstellung komplex + +**Differenziell:** +Änderungen seit letztem Voll-Backup +Mittelweg + + + +--- + +# 3-2-1-Regel + +**3** Kopien (Original + 2 Backups) + +**2** verschiedene Medientypen (SSD + HDD) + +**1** Offsite-Backup (Cloud, externes Lager) + +**Beispiel:** +Laptop + externe Festplatte + Cloud + + + +--- + +# Backup-Software + +**macOS:** Time Machine +**Windows:** Veeam Agent (kostenlos) +**Linux:** rsync, Borg, Restic +**Plattformübergreifend:** Duplicati, Syncthing +**Cloud:** Backblaze, Nextcloud + + + +--- + +![bg](./assets/bit-rot.jpg) + + + +--- + +# Langzeitarchivierung: Das Problem + +**Digitale Daten altern:** +- Bit Rot (Degradation) +- Format-Obsoleszenz (WordPerfect .wpd) +- Hardware-Obsoleszenz (Diskettenlaufwerke) + +**Lösung:** +Migration + offene Standards + + + +--- + +![bg](./assets/lto-tape.jpg) + + + +--- + +# Magnetbänder (LTO) + +**Linear Tape-Open:** + +- LTO-9 (2021): 18 TB nativ, 45 TB komprimiert +- Haltbarkeit: 30 Jahre +- Kosten: ~5€/TB (Laufwerk ~5.000€) +- Nutzung: Rechenzentren, Archive + +**Air-Gap-Sicherheit:** +Offline-Band kann nicht von Ransomware verschlüsselt werden + + + +--- + +![bg](./assets/m-disc.jpg) + + + +--- + +# M-DISC (Millennial Disc) + +**Eigenschaften:** +- DVD/Blu-ray-kompatibel +- Anorganische Metallschicht +- Haltbarkeit: 1.000 Jahre (Tests) +- Einsatz: Familienfotos, Archive + + + +--- + +![bg](./assets/dna-helix.jpg) + + + +--- + +# DNA-Storage (Zukunft) + +**Konzept:** Daten in DNA-Sequenzen + +**Eigenschaften:** +- Speicherdichte: 215 Petabyte/Gramm (!!) +- Haltbarkeit: Tausende Jahre +- Kosten: Aktuell $3.500/MB + +**Beispiele:** +Microsoft + Twist Bioscience +Netflix "Biohackers"-Episode (2021) + + + +--- + +# Hands-On: S.M.A.R.T. & Backup + +**Aufgabe 1 (20 Min):** +S.M.A.R.T.-Daten auslesen +- Windows: CrystalDiskInfo +- macOS/Linux: `smartctl -a /dev/sda` +- Notiere: Health, Power-On Hours, Temp + +**Aufgabe 2 (20 Min):** +Test-Backup erstellen +- rsync (Linux/macOS) oder Robocopy (Windows) +- Simuliere Datenverlust → Wiederherstellung + + + +--- + +# Aufgabe bis nächste Woche + +**Analysiere dein System:** + +1. Welches Dateisystem nutzt deine Hauptpartition? +2. Hast du ein Backup? Welche Art? Wo? +3. Poste im Forum: S.M.A.R.T.-Screenshot + Backup-Strategie + +**Bonus:** Richte automatisches Backup ein + + + +--- + + + +# Teil 2: Schnittstellen +## USB-C, HDMI & das Kabel-Chaos + +--- + +![bg](./assets/cable-mess.jpg) + + + +--- + +# Was ist eine Schnittstelle? + +**Schnittstelle = Verbindung zwischen Systemen** + +**Hardware-Schnittstellen:** +Physischer Anschluss (USB, HDMI, Ethernet) + +**Software-Schnittstellen:** +API (nächste Woche!) + +**Heute:** Hardware-Fokus + + + +--- + +![bg](./assets/pc-back-1990s.jpg) + + + +--- + +# USB: Die Idee + +**Universal Serial Bus (1996)** + +**Ziel:** Ein Kabel für alles + +**Vorher:** +- PS/2 (Maus, Tastatur) +- Seriell (Modem) +- Parallel (Drucker) +- SCSI (Festplatten) + +**USB-Versprechen:** +✓ Ein Stecker, Hot-Pluggable, Stromversorgung + + + +--- + +# USB-Versionen: Chaos + +| Version | Jahr | Geschwindigkeit | Marketing-Name | +|---------|------|----------------:|----------------| +| USB 1.0 | 1996 | 12 Mbps | – | +| USB 2.0 | 2000 | 480 Mbps | Hi-Speed | +| USB 3.0 | 2008 | 5 Gbps | USB 3.2 Gen 1 | +| USB 3.1 | 2013 | 10 Gbps | USB 3.2 Gen 2 | +| USB 3.2 | 2017 | 20 Gbps | USB 3.2 Gen 2×2 | +| USB 4 | 2019 | 40 Gbps | USB4 | + +**NIEMAND versteht das mehr!** + + + +--- + +![bg](./assets/usb-c-cables.jpg) + + + +--- + +# USB-C: Stecker ≠ Geschwindigkeit + +**USB-C = Physischer Stecker (2014)** + +**Eigenschaften:** +✓ Reversibel (beide Seiten gleich) +✓ 24 Pins (vs. 4 bei USB-A) +✓ Unterstützt: Daten, Strom, Video, Audio + +**ABER:** USB-C sagt NICHTS über Geschwindigkeit! + +Ein USB-C-Kabel kann sein: +- USB 2.0 (480 Mbps) 😱 +- USB 3.2 Gen 2 (10 Gbps) +- USB 4 (40 Gbps) +- Thunderbolt 3/4 (40 Gbps) +- Oder nur Power Delivery (Laden, keine Daten!) + + + +--- + +# USB Power Delivery + +**USB PD (über USB-C):** + +- Profile: 5V bis 20V +- Max. 5A +- Bis zu **240W** (USB PD 3.1, 2021) + +**Anwendungen:** +- Laptop-Ladung (60-100W) +- Monitor mit Stromversorgung +- Docking-Stations + +**Problem:** Nicht jedes Kabel unterstützt volles PD! + + + +--- + +# USB-C: Das Wirrwarr + +**Was ein USB-C-Kabel KÖNNEN KANN:** + +**Daten:** USB 2.0 bis USB4 (40 Gbps) + +**Strom:** 5W bis 240W + +**Video:** DisplayPort Alt Mode, HDMI Alt Mode + +**Audio:** USB Audio Class + +**Problem:** Am Kabel steht's oft NICHT drauf! + + + +--- + +![bg](./assets/thunderbolt-logo.jpg) + + + +--- + +# Thunderbolt: Premium-Schnittstelle + +**Thunderbolt (Intel + Apple):** + +- Thunderbolt 3/4 (2015/2020): USB-C, 40 Gbps +- **PCIe über Kabel** → externe GPUs! +- Daisychaining (bis 6 Geräte) +- 100W Power Delivery garantiert + +**Nachteile:** +❌ Teuer (Kabel: 30-80€) +❌ Lizenzgebühren (Intel) +❌ Nur High-End-Geräte + + + +--- + +![bg](./assets/hdmi-cable.jpg) + + + +--- + +# HDMI: Der Heimkino-Standard + +**HDMI (2002):** +Entwickelt von Sony, Panasonic, Toshiba... + +**Versionen:** +- HDMI 1.4 (2009): 4K @ 30 Hz, ARC +- HDMI 2.0 (2013): 4K @ 60 Hz, HDR +- HDMI 2.1 (2017): 8K @ 60 Hz, 4K @ 120 Hz, VRR + +**Features:** +✓ Audio + Video in einem Kabel +✓ HDCP (Copy Protection) +✓ CEC (Gerätesteuerung) + +**Nachteile:** +❌ Proprietär, Lizenzgebühren +❌ Keine Daisychaining + + + +--- + +![bg](./assets/displayport-cable.jpg) + + + +--- + +# DisplayPort: Die PC-Alternative + +**DisplayPort (2006):** +VESA (Video Electronics Standards Association) + +**Versionen:** +- DP 1.4 (2016): 8K @ 60 Hz, HDR +- DP 2.0 (2019): 16K @ 60 Hz, 8K @ 120 Hz + +**Vorteile:** +✓ Lizenzfrei (keine Gebühren!) +✓ Daisychaining (Multi-Monitor) +✓ Adaptive Sync (FreeSync, G-Sync) +✓ USB-C Alt Mode + +**Nachteil:** Weniger verbreitet in TVs + + + +--- + +# HDMI vs. DisplayPort + +| Feature | HDMI 2.1 | DisplayPort 2.0 | +|---------|----------|-----------------| +| **Max. Auflösung** | 8K @ 60 Hz | 16K @ 60 Hz | +| **Lizenz** | Ja (~$10k/Jahr) | Nein | +| **Daisychaining** | Nein | Ja | +| **Adaptive Sync** | VRR (neu) | Ja (nativ) | +| **USB-C** | Alt Mode (selten) | Alt Mode (häufig) | +| **Verbreitung** | TVs dominant | PCs/Monitore | + + + +--- + +![bg](./assets/hdcp-warning.jpg) + + + +--- + +# HDCP: Copy Protection + +**HDCP = High-bandwidth Digital Content Protection** + +**Was ist das?** +- DRM für Video-Signale +- Verschlüsselt zwischen Quelle und Display +- Verhindert "Man-in-the-Middle"-Aufnahme + +**Problem:** +- Alte Monitore: Kein HDCP 2.2 → 4K-Netflix funktioniert nicht! +- Capture-Cards oft blockiert +- "HDCP-Handshake-Fehler" → Schwarzer Bildschirm + +**Kritik:** Schikaniert ehrliche Nutzer, Piraten umgehen es leicht + + + +--- + +![bg](./assets/ethernet-cable.jpg) + + + +--- + +# Ethernet: Das Netzwerkkabel + +**Ethernet (1980er):** + +**Versionen:** +- 100BASE-TX (1995): 100 Mbps +- 1000BASE-T (1999): 1 Gbps (Gigabit) +- 10GBASE-T (2006): 10 Gbps + +**Kabel-Kategorien:** +- Cat5e: bis 1 Gbps (veraltet) +- Cat6: bis 10 Gbps (55m) +- Cat6a: bis 10 Gbps (100m) + +**Stecker:** RJ45 (8P8C) + + + +--- + +![bg](./assets/vintage-ports.jpg) + + + +--- + +# Veraltete Schnittstellen + +**Seriell (RS-232):** 1960er, 115,2 kbps, Modems +**Parallel (LPT):** Drucker, 8 Bits gleichzeitig +**PS/2:** Maus + Tastatur (1987-2010er) +**VGA:** Analoges Video (1987-2010er) + +**Heute:** Manchmal noch auf Mainboards (Legacy-Support) + + + +--- + +# Hands-On: Schnittstellen identifizieren + +**Aufgabe (30 Min):** + +1. Untersuche deinen Laptop/Desktop +2. Welche Anschlüsse vorhanden? +3. Für USB-C: Welche Features? (Daten, Video, Laden?) +4. Teste: Schließe Gerät an verschiedenen Ports an +5. Dokumentiere: Foto + Beschriftung + +**Tools:** Systeminfo (Win), System Report (Mac), lsusb (Linux) + + + +--- + +# Aufgabe bis nächste Woche + +**Analysiere deine Kabel:** + +1. Liste alle Kabel (USB, HDMI, etc.) +2. Identifiziere: Standard, Geschwindigkeit, Features +3. Ist es beschriftet? Verständlich? +4. Poste im Forum: Foto + das verwirrendste Kabel + +**Bonus:** Finde USB-C-Kabel, das nur USB 2.0 kann + + + diff --git a/slides/2026-01-30-termin-4-distribution-apis-zukunft.md b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md new file mode 100644 index 0000000..fa13072 --- /dev/null +++ b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md @@ -0,0 +1,1818 @@ +--- + + + +# Termin 4 – 30.01.2026 +## Distribution, APIs & Zukunft + +--- + +![bg](./assets/sneakernet-truck.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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 + + + +--- + +![bg](./assets/cd-dvd-bluray.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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) + + + +--- + +![bg](./assets/cdn-map.jpg) + + + +--- + +# 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 + + + +--- + +![bg](./assets/netflix-openconnect.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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 + + + +--- + +![bg](./assets/bittorrent-swarm.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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 + + + +--- + +# Aufgabe bis nächste Woche + +**Analysiere Streaming-Dienst oder Website:** + +1. Wähle: Netflix, YouTube, Spotify, News-Seite +2. DevTools (Network-Tab): + - Welcher CDN? + - Wie viele Requests an CDN vs. Origin? + - Cache-Headers? +3. Poste im Forum: Screenshot + Erkenntnisse + +**Bonus:** Linux-ISO via Torrent, poste Peer-Stats + + + +--- + + + +# Teil 2: APIs +## Software-Schnittstellen & Protokolle + +--- + +![bg](./assets/api-diagram.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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 + + + +--- + +# Aufgabe bis nächste Woche + +**Experimentiere mit öffentlicher API:** + +1. Wähle: + - GitHub API (`api.github.com`) + - OpenWeather (`openweathermap.org/api`) + - PokéAPI (`pokeapi.co`) +2. Mache 3-5 Requests (curl, Postman, oder Code) +3. Poste im Forum: + - Welche API? + - Interessante Daten? + - Rate-Limiting erlebt? (429 Too Many Requests) + +**Bonus:** Baue kleinen Client (Python, JavaScript, etc.) + + + +--- + + + +# Teil 3: Metadaten +## Daten über Daten & Interoperabilität + +--- + +![bg](./assets/exif-gps.jpg) + + + +--- + +# 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 + + + +--- + +![bg](./assets/mcafee-exif-fail.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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 ``) + + + +--- + +![bg](./assets/pdf-metadata-leak.jpg) + + + +--- + +# 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 +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) + + + +--- + +# Aufgabe bis nächste Woche + +**Metadaten-Audit:** + +1. Wähle 3 Dateitypen: + - Ein Foto (EXIF) + - Eine MP3 (ID3) + - Ein PDF (XMP) +2. Analysiere: Welche Metadaten? +3. Poste im Forum: + - Screenshots (OHNE sensible Infos!) + - Überraschungen? + - Wie viel KB gespart nach Entfernung? + +**Bonus:** Finde alte Datei (>5 Jahre) – was verraten Metadaten über damaliges Setup? + + + +--- + + + +# Teil 4: Zukunft +## Trends & Ausblick + +--- + +![bg](./assets/futuristic-datacenter.jpg) + + + +--- + +# Rückblick: 9 Wochen + +**Woche 1:** Bits → Bytes → Bedeutung (Encoding) +**Woche 2:** MP3 & Psychoakustik +**Woche 3:** JPEG & GIF-Kriege +**Woche 4:** H.264 vs. AV1 +**Woche 5:** HDD vs. SSD, Dateisysteme, Backup +**Woche 6:** USB-C-Chaos, HDMI vs. DisplayPort +**Woche 7:** CDN, P2P, Streaming +**Woche 8:** REST, GraphQL, WebSockets +**Woche 9:** EXIF, Vendor Lock-in + +**Heute:** Wohin geht die Reise? + + + +--- + +# 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.jpg) + + + +--- + +# 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.jpg) + + + +--- + +# 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 (Forum, E-Mail) +- Weiterlernen mit Ressourcen + +**Vielen Dank für eure Aufmerksamkeit!** + + + diff --git a/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md new file mode 100644 index 0000000..93de6d6 --- /dev/null +++ b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md @@ -0,0 +1,24 @@ +--- + + + +# Termin 5 – TBA +## Vertiefung & Offene Fragen + +--- + +# Ersatztermin + +**Dieser Termin wird noch bekannt gegeben.** + +Mögliche Inhalte: +- Vertiefung von Themen nach Wunsch +- Praxisübungen & Hands-On +- Offene Fragen & Diskussion +- Prüfungsvorbereitung + + + diff --git a/slides/_frontmatter.md b/slides/_frontmatter.md new file mode 100644 index 0000000..f2ed955 --- /dev/null +++ b/slides/_frontmatter.md @@ -0,0 +1,19 @@ +--- +marp: true +theme: gaia +paginate: true +backgroundColor: #fff +header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege" +footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26" +title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege +--- + + + diff --git a/slides/_intro.md b/slides/_intro.md new file mode 100644 index 0000000..193cefe --- /dev/null +++ b/slides/_intro.md @@ -0,0 +1,83 @@ +![bg fit](./assets/digital-landscape.jpg) + + + +--- + +# Dateiformate, Schnittstellen, Speichermedien & Distributionswege + +Modul "Technik 1" – 1. Semester +Digital- und Medienwirtschaft +Hochschule der Medien Stuttgart + +**Wintersemester 2025/26** + +--- + +# Über mich + +**Michael Czechowski** + +- Softwareentwickler & IT-Berater +- Schwerpunkte: Web-Technologien, Systemarchitektur, Open Source +- Hintergrund: Philosophie & Informatik +- Kontakt: czechowski@hdm-stuttgart.de + + + +--- + +# Termine + +| Datum | Zeit | Thema | +|-------|------|-------| +| 19.12.2025 | 14:15 – 17:30 | Grundlagen, Text & Audio | +| 09.01.2026 | 14:15 – 17:30 | Bild- & Videoformate | +| 23.01.2026 | 14:15 – 17:30 | Speichermedien & Schnittstellen | +| 30.01.2026 | 14:15 – 17:30 | Distribution, APIs & Zukunft | +| TBA | 14:15 – 17:30 | Vertiefung (wird bekannt gegeben) | + +**Ort:** HdM Stuttgart, Nobelstraße 10 + +--- + +# Kurze Umfrage + +**Bitte Hand heben:** + +1. Wer hat schon mal eine Datei mit einem Hex-Editor geöffnet? +2. Wer weiß, was der Unterschied zwischen JPEG und PNG ist? +3. Wer hat schon mal mit APIs gearbeitet? +4. Wer weiß, was UTF-8 bedeutet? +5. Wer hat schon mal ein Video komprimiert/konvertiert? + + + +--- + +# Kursübersicht + +**Ziel:** Verstehen, wie digitale Medien technisch funktionieren – von Bits bis zu globalen Distributionsnetzwerken + +**5 Termine:** +- **19.12.** Bits, Bytes, Zeichenkodierung & Audio-Kompression +- **09.01.** Bild- & Video-Kompression +- **23.01.** Speichermedien & Hardware-Schnittstellen +- **30.01.** Distribution, APIs, Metadaten & Zukunft +- **TBA** Vertiefung & offene Fragen + + + diff --git a/slides/_outro.md b/slides/_outro.md new file mode 100644 index 0000000..d232a21 --- /dev/null +++ b/slides/_outro.md @@ -0,0 +1,27 @@ +--- + + + +# Fragen & Diskussion + +**Kontakt:** czechowski@hdm-stuttgart.de +**Folien:** Online verfügbar unter https://hdm.librete.ch + +--- + +# 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/ + + +