gendering: fehlende person-substantive in beiden kursen
- Nutzer/User -> Nutzende - Endnutzer -> Endnutzende - Teilnehmer -> Teilnehmende - Programmierer/Entwickler -> Programmierende/Entwickelnde - Web-Entwickler -> Web-Entwickelnde - Tastatur-Nutzer -> Tastatur-Nutzende - Benutzer -> Nutzende - Konsumenten -> KonsumentInnen - Künstler -> KünstlerInnen - Autor -> AutorIn - Fotografen -> FotografInnen - Kunde -> KundIn ausgenommen: code-identifiers (User, type User, /users/), Sender/Empfänger (network protocol), Sawyer (konkrete person), Hersteller/Betreiber (organisations-rolle).
This commit is contained in:
@@ -348,7 +348,7 @@ dann **150 Mbit/s ÷ 8** = **18,75 MB/s**
|
|||||||
**50 MB Upload bei 10 Mbit/s = ~40 Sekunden**
|
**50 MB Upload bei 10 Mbit/s = ~40 Sekunden**
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
- ADSL (Asymmetric Digital Subscriber Line, ITU = International Telecommunication Union, Norm G.992.1, 1999): Upload bewusst begrenzt — Annahme war, Nutzer konsumieren mehr als sie produzieren
|
- ADSL (Asymmetric Digital Subscriber Line, ITU = International Telecommunication Union, Norm G.992.1, 1999): Upload bewusst begrenzt — Annahme war, Nutzende konsumieren mehr als sie produzieren
|
||||||
- FTTH = Fiber To The Home (Glasfaser bis in die Wohnung)
|
- FTTH = Fiber To The Home (Glasfaser bis in die Wohnung)
|
||||||
- Glasfaser (FTTH) symmetrisch: Upload = Download
|
- Glasfaser (FTTH) symmetrisch: Upload = Download
|
||||||
- FTTH-Verfügbarkeit Deutschland Ende 2024: ~40% der Haushalte (Bundesnetzagentur, Breitbandatlas)
|
- FTTH-Verfügbarkeit Deutschland Ende 2024: ~40% der Haushalte (Bundesnetzagentur, Breitbandatlas)
|
||||||
@@ -434,7 +434,7 @@ Jede Messung = ein Zahlenwert
|
|||||||
<!--
|
<!--
|
||||||
- Dynamikumfang Formel: ~6 dB pro Bit
|
- Dynamikumfang Formel: ~6 dB pro Bit
|
||||||
- 16 Bit reicht für menschliches Hören unter realen Bedingungen (~80–90 dB)
|
- 16 Bit reicht für menschliches Hören unter realen Bedingungen (~80–90 dB)
|
||||||
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzer (Meyer & Moran, JAES 2007)
|
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzende (Meyer & Moran, JAES 2007)
|
||||||
- dB = Dezibel: logarithmische Einheit für Lautstärke
|
- dB = Dezibel: logarithmische Einheit für Lautstärke
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@@ -556,7 +556,7 @@ RECHNUNG:
|
|||||||
|
|
||||||
- CD (1982, Sony/Philips): erstes massenmarktfähiges digitales Distributionsmedium für unkomprimiertes PCM-Audio
|
- CD (1982, Sony/Philips): erstes massenmarktfähiges digitales Distributionsmedium für unkomprimiertes PCM-Audio
|
||||||
- PCM (Pulse-Code Modulation) existierte bereits vorher: NHK (Nippon Hōsō Kyōkai = japanische öffentlich-rechtliche Rundfunkanstalt)-Forschung ab 1960er, digitale Studiogeräte ab 1970er
|
- PCM (Pulse-Code Modulation) existierte bereits vorher: NHK (Nippon Hōsō Kyōkai = japanische öffentlich-rechtliche Rundfunkanstalt)-Forschung ab 1960er, digitale Studiogeräte ab 1970er
|
||||||
- Die CD war nicht das erste digitale Audio — aber das erste das in Konsumentenhänden landete
|
- Die CD war nicht das erste digitale Audio — aber das erste das in KonsumentInnen-Hand landete
|
||||||
-->
|
-->
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -600,7 +600,7 @@ _class: erklaerung
|
|||||||
|
|
||||||
# CD-Audio – Vertiefung
|
# CD-Audio – Vertiefung
|
||||||
|
|
||||||
Die CD (1982) war nicht das erste digitale Audiomedium — PCM-Aufnahmen existierten seit den späten 1960ern in Tonstudios (u.a. NHK, Nippon Columbia). Die CD war das erste **massenmarktfähige** digitale Distributionsmedium für unkomprimiertes Audio in Konsumentenhänden.
|
Die CD (1982) war nicht das erste digitale Audiomedium — PCM-Aufnahmen existierten seit den späten 1960ern in Tonstudios (u.a. NHK, Nippon Columbia). Die CD war das erste **massenmarktfähige** digitale Distributionsmedium für unkomprimiertes Audio in KonsumentInnen-Hand.
|
||||||
|
|
||||||
**Warum 44.100 Hz?**
|
**Warum 44.100 Hz?**
|
||||||
Kombination aus Nyquist-Limit (2× 20 kHz = 40 kHz Minimum) und Kompatibilität mit Videobandgeräten, die in frühen digitalen Tonstudios als Speichermedium genutzt wurden. NTSC: 3 Samples × 245 Zeilen × 60 Felder = 44.100. PAL: 3 Samples × 294 Zeilen × 50 Felder = 44.100.
|
Kombination aus Nyquist-Limit (2× 20 kHz = 40 kHz Minimum) und Kompatibilität mit Videobandgeräten, die in frühen digitalen Tonstudios als Speichermedium genutzt wurden. NTSC: 3 Samples × 245 Zeilen × 60 Felder = 44.100. PAL: 3 Samples × 294 Zeilen × 50 Felder = 44.100.
|
||||||
@@ -1810,7 +1810,7 @@ Fangfrage: "Wie hoch ist die Sample Rate von Vinyls?" -> Vinyl has no sample rat
|
|||||||
<!--
|
<!--
|
||||||
- Dynamikumfang Formel: ~6 dB pro Bit
|
- Dynamikumfang Formel: ~6 dB pro Bit
|
||||||
- 16 Bit reicht für menschliches Hören unter realen Bedingungen
|
- 16 Bit reicht für menschliches Hören unter realen Bedingungen
|
||||||
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzer (Meyer & Moran, JAES 2007)
|
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzende (Meyer & Moran, JAES 2007)
|
||||||
-->
|
-->
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -2015,7 +2015,7 @@ Ein Zusammenspiel aus vielen Faktoren:
|
|||||||
**P2P-Filesharing für MP3s**
|
**P2P-Filesharing für MP3s**
|
||||||
|
|
||||||
- Shawn Fanning, 19 Jahre alt
|
- Shawn Fanning, 19 Jahre alt
|
||||||
- 80 Millionen User in 2 Jahren
|
- 80 Millionen Nutzende in 2 Jahren
|
||||||
- Musikindustrie verklagt (2001)
|
- Musikindustrie verklagt (2001)
|
||||||
- Pandora's Box: Nicht mehr aufzuhalten
|
- Pandora's Box: Nicht mehr aufzuhalten
|
||||||
|
|
||||||
@@ -2032,7 +2032,7 @@ Ein Zusammenspiel aus vielen Faktoren:
|
|||||||
# Napster & Musikindustrie
|
# Napster & Musikindustrie
|
||||||
|
|
||||||
**1999:** Napster startet
|
**1999:** Napster startet
|
||||||
**2001:** 80 Millionen User
|
**2001:** 80 Millionen Nutzende
|
||||||
|
|
||||||
**Musikindustrie:**
|
**Musikindustrie:**
|
||||||
- CDs kosten $15–20
|
- CDs kosten $15–20
|
||||||
|
|||||||
@@ -948,7 +948,7 @@ KLAUSURRELEVANT:
|
|||||||
<!--
|
<!--
|
||||||
- Kompatibilität schlägt oft Effizienz
|
- Kompatibilität schlägt oft Effizienz
|
||||||
- TIFF für Archivierung: Unkomprimiert oder verlustfrei
|
- TIFF für Archivierung: Unkomprimiert oder verlustfrei
|
||||||
- RAW für Fotografen: Maximale Bearbeitungsfreiheit
|
- RAW für FotografInnen: Maximale Bearbeitungsfreiheit
|
||||||
- Frage: "Was passiert, wenn ihr ein PNG auf Instagram hochladet?"
|
- Frage: "Was passiert, wenn ihr ein PNG auf Instagram hochladet?"
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@@ -984,8 +984,8 @@ KLAUSURRELEVANT:
|
|||||||
- Instagram ist keine Kunstgalerie, sondern Massenplattform
|
- Instagram ist keine Kunstgalerie, sondern Massenplattform
|
||||||
- Optimiert für Geschwindigkeit, nicht Qualität
|
- Optimiert für Geschwindigkeit, nicht Qualität
|
||||||
- Facebook, Twitter, TikTok – alle machen das
|
- Facebook, Twitter, TikTok – alle machen das
|
||||||
- Tipp für Fotografen: Portfolio auf eigener Website
|
- Tipp für FotografInnen: Portfolio auf eigener Website
|
||||||
- Diskussion: Ist das fair? Trade-off Nutzer vs. Plattform
|
- Diskussion: Ist das fair? Trade-off Nutzende vs. Plattform
|
||||||
-->
|
-->
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -1062,7 +1062,7 @@ KLAUSURRELEVANT:
|
|||||||
|
|
||||||
**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.
|
**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.
|
||||||
|
|
||||||
| Container | Entwickler | Typische Codecs | Besonderheit |
|
| Container | Entwicklung | Typische Codecs | Besonderheit |
|
||||||
|-----------|------------|-----------------|--------------|
|
|-----------|------------|-----------------|--------------|
|
||||||
| MP4 | ISO/MPEG | H.264, H.265, AAC | Web-Standard, DRM-fähig |
|
| MP4 | ISO/MPEG | H.264, H.265, AAC | Web-Standard, DRM-fähig |
|
||||||
| MKV | Matroska | Alle | Beliebig viele Streams, Kapitel |
|
| MKV | Matroska | Alle | Beliebig viele Streams, Kapitel |
|
||||||
@@ -1326,7 +1326,7 @@ H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-
|
|||||||
|
|
||||||
**Hardware-Ubiquität:** Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie.
|
**Hardware-Ubiquität:** Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie.
|
||||||
|
|
||||||
**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzer-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.
|
**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzungs-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -1347,7 +1347,7 @@ H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-
|
|||||||
<!--
|
<!--
|
||||||
- MPEG-LA = Licensing Authority
|
- MPEG-LA = Licensing Authority
|
||||||
- Firefox weigerte sich lange, H.264 zu unterstützen
|
- Firefox weigerte sich lange, H.264 zu unterstützen
|
||||||
- "Free to View" gilt nur für Endnutzer-Streaming
|
- "Free to View" gilt nur für Endnutzungs-Streaming
|
||||||
- Diskussion: Sollten Standards patent-frei sein?
|
- Diskussion: Sollten Standards patent-frei sein?
|
||||||
-->
|
-->
|
||||||
|
|
||||||
|
|||||||
@@ -154,7 +154,7 @@ Hersteller: Dezimal (SI-Präfix) - klingt mehr!
|
|||||||
Betriebssysteme: Binär - aber zeigen "GB" statt "GiB"
|
Betriebssysteme: Binär - aber zeigen "GB" statt "GiB"
|
||||||
Diskrepanz bei 1 TB: 1.000.000.000.000 vs. 1.099.511.627.776 Bytes
|
Diskrepanz bei 1 TB: 1.000.000.000.000 vs. 1.099.511.627.776 Bytes
|
||||||
→ 10% Unterschied bei TB-Größen
|
→ 10% Unterschied bei TB-Größen
|
||||||
Verwirrung für Konsumenten seit Jahrzehnten
|
Verwirrung für KonsumentInnen seit Jahrzehnten
|
||||||
ISO/IEC 80000-13: Definiert KiB, MiB, GiB, TiB (2008)
|
ISO/IEC 80000-13: Definiert KiB, MiB, GiB, TiB (2008)
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@@ -592,7 +592,7 @@ Voll: Langsamstes Backup, schnellste Wiederherstellung
|
|||||||
|
|
||||||
<!--
|
<!--
|
||||||
Time Machine: Stündliche Snapshots, APFS-Integration
|
Time Machine: Stündliche Snapshots, APFS-Integration
|
||||||
Veeam: Enterprise-Level, kostenlose Endnutzer-Version
|
Veeam: Enterprise-Level, kostenlose Privatversion
|
||||||
rsync: Unix-Klassiker, extrem effizient
|
rsync: Unix-Klassiker, extrem effizient
|
||||||
Borg: Deduplizierung + Verschlüsselung
|
Borg: Deduplizierung + Verschlüsselung
|
||||||
-->
|
-->
|
||||||
|
|||||||
@@ -160,7 +160,7 @@ AWS Snowmobile: 45-Fuß-Container auf LKW
|
|||||||
|
|
||||||
**Prozess:**
|
**Prozess:**
|
||||||
1. AWS schickt verschlüsseltes Gerät
|
1. AWS schickt verschlüsseltes Gerät
|
||||||
2. Kunde kopiert Daten lokal (schnell!)
|
2. KundIn kopiert Daten lokal (schnell!)
|
||||||
3. Gerät zurück an AWS
|
3. Gerät zurück an AWS
|
||||||
4. AWS lädt in S3 hoch
|
4. AWS lädt in S3 hoch
|
||||||
|
|
||||||
@@ -220,7 +220,7 @@ Server unter Last (symbolisch)
|
|||||||
**Klassisches Modell:** Ein Server, viele Clients
|
**Klassisches Modell:** Ein Server, viele Clients
|
||||||
|
|
||||||
**Problem:**
|
**Problem:**
|
||||||
1 Million User wollen 1 GB-Datei
|
1 Million Nutzende wollen 1 GB-Datei
|
||||||
→ Server braucht **1 PB Bandbreite!**
|
→ Server braucht **1 PB Bandbreite!**
|
||||||
→ Server überlastet → **"Hug of Death"**
|
→ Server überlastet → **"Hug of Death"**
|
||||||
|
|
||||||
@@ -252,7 +252,7 @@ Globale Verteilung
|
|||||||
**Funktionsweise:**
|
**Funktionsweise:**
|
||||||
1. **Origin Server** (Hauptquelle)
|
1. **Origin Server** (Hauptquelle)
|
||||||
2. **Edge Servers** (geografisch verteilt)
|
2. **Edge Servers** (geografisch verteilt)
|
||||||
3. User → nächster Edge Server
|
3. Nutzende → nächster Edge Server
|
||||||
4. Erste Anfrage: Edge holt von Origin, cached
|
4. Erste Anfrage: Edge holt von Origin, cached
|
||||||
5. Weitere Anfragen: Direkt vom Edge (schnell!)
|
5. Weitere Anfragen: Direkt vom Edge (schnell!)
|
||||||
|
|
||||||
@@ -277,7 +277,7 @@ Große CDN-Anbieter: Cloudflare, Akamai, Amazon CloudFront, Fastly
|
|||||||
- Lange Cache-Zeit (TTL: Tage/Wochen)
|
- Lange Cache-Zeit (TTL: Tage/Wochen)
|
||||||
|
|
||||||
**Dynamic Content:**
|
**Dynamic Content:**
|
||||||
- User-spezifisch (Profil)
|
- Nutzungs-spezifisch (Profil)
|
||||||
- Kurze TTL oder nicht cachebar
|
- Kurze TTL oder nicht cachebar
|
||||||
|
|
||||||
**Cache Invalidation:**
|
**Cache Invalidation:**
|
||||||
@@ -349,14 +349,14 @@ Dezentral, jeder ist Client & Server
|
|||||||
- IPFS (InterPlanetary File System)
|
- IPFS (InterPlanetary File System)
|
||||||
- Blockchain (Bitcoin, Ethereum)
|
- Blockchain (Bitcoin, Ethereum)
|
||||||
|
|
||||||
**Vorteil:** Skalierbar (mehr User = mehr Bandbreite!)
|
**Vorteil:** Skalierbar (mehr Nutzende = mehr Bandbreite!)
|
||||||
|
|
||||||
**Nachteil:** Langsam bei wenigen Peers, oft für Piraterie missbraucht
|
**Nachteil:** Langsam bei wenigen Peers, oft für Piraterie missbraucht
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
P2P vs. Client-Server: Kein zentraler Server
|
P2P vs. Client-Server: Kein zentraler Server
|
||||||
Last verteilt sich auf alle Teilnehmer
|
Last verteilt sich auf alle Teilnehmenden
|
||||||
Je mehr User, desto schneller (umgekehrt zu Client-Server!)
|
Je mehr Nutzende, desto schneller (umgekehrt zu Client-Server!)
|
||||||
Zensur-resistent: Kein Single Point of Failure
|
Zensur-resistent: Kein Single Point of Failure
|
||||||
Rechtliche Grauzone: Technologie neutral, aber oft illegal genutzt
|
Rechtliche Grauzone: Technologie neutral, aber oft illegal genutzt
|
||||||
-->
|
-->
|
||||||
@@ -1023,8 +1023,8 @@ Privacy-Albtraum
|
|||||||
|
|
||||||
**Beispiele:**
|
**Beispiele:**
|
||||||
- **Foto:** Kamera, Datum, GPS, Belichtung
|
- **Foto:** Kamera, Datum, GPS, Belichtung
|
||||||
- **MP3:** Künstler, Album, Jahr, Genre, Cover
|
- **MP3:** KünstlerInnen, Album, Jahr, Genre, Cover
|
||||||
- **PDF:** Autor, Datum, Software
|
- **PDF:** AutorIn, Datum, Software
|
||||||
- **E-Mail:** Absender, Empfänger, Zeitstempel
|
- **E-Mail:** Absender, Empfänger, Zeitstempel
|
||||||
|
|
||||||
**Warum wichtig?**
|
**Warum wichtig?**
|
||||||
@@ -1180,7 +1180,7 @@ Wikipedia für Musik-Metadaten
|
|||||||
**Idee:** Wikipedia für Musik-Metadaten
|
**Idee:** Wikipedia für Musik-Metadaten
|
||||||
|
|
||||||
**Community-gepflegt:**
|
**Community-gepflegt:**
|
||||||
- Künstler, Alben, Tracks
|
- KünstlerInnen, Alben, Tracks
|
||||||
- Relationships (Band-Mitglieder, Label...)
|
- Relationships (Band-Mitglieder, Label...)
|
||||||
- Releases (verschiedene Editionen, Länder)
|
- Releases (verschiedene Editionen, Länder)
|
||||||
|
|
||||||
@@ -1239,7 +1239,7 @@ Versteckte Informationen sichtbar
|
|||||||
**PDF-Metadaten (XMP):**
|
**PDF-Metadaten (XMP):**
|
||||||
|
|
||||||
**Gespeichert:**
|
**Gespeichert:**
|
||||||
- Titel, Autor, Betreff, Keywords
|
- Titel, AutorIn, Betreff, Keywords
|
||||||
- Erstellungsdatum, Änderungsdatum
|
- Erstellungsdatum, Änderungsdatum
|
||||||
- Software, **Company** (aus Office-Lizenz!)
|
- Software, **Company** (aus Office-Lizenz!)
|
||||||
|
|
||||||
@@ -1600,7 +1600,7 @@ QKD: Abhör-sichere Kommunikation (Quantenmechanik garantiert)
|
|||||||
|
|
||||||
**Filecoin (2017):**
|
**Filecoin (2017):**
|
||||||
- Blockchain-basiert
|
- Blockchain-basiert
|
||||||
- User vermieten Festplatten-Platz
|
- Nutzende vermieten Festplatten-Platz
|
||||||
- Bezahlung in FIL (Kryptowährung)
|
- Bezahlung in FIL (Kryptowährung)
|
||||||
|
|
||||||
**Arweave (2018):**
|
**Arweave (2018):**
|
||||||
@@ -1638,7 +1638,7 @@ Legitime Use-Cases: NFT-Storage, Zensur-resistente Archivierung
|
|||||||
- 5G + Edge Computing nötig
|
- 5G + Edge Computing nötig
|
||||||
|
|
||||||
**Cloud Gaming:**
|
**Cloud Gaming:**
|
||||||
- Spiel im Rechenzentrum, Stream zu User
|
- Spiel im Rechenzentrum, Stream zu Nutzenden
|
||||||
- Input-Lag = Todfeind (<50ms)
|
- Input-Lag = Todfeind (<50ms)
|
||||||
|
|
||||||
**Problem:** Physik (Lichtgeschwindigkeit!)
|
**Problem:** Physik (Lichtgeschwindigkeit!)
|
||||||
@@ -1647,7 +1647,7 @@ Legitime Use-Cases: NFT-Storage, Zensur-resistente Archivierung
|
|||||||
8K: YouTube unterstützt, aber wer hat 8K-Monitor?
|
8K: YouTube unterstützt, aber wer hat 8K-Monitor?
|
||||||
VR: Meta Quest, Apple Vision Pro
|
VR: Meta Quest, Apple Vision Pro
|
||||||
Latenz: Lichtgeschwindigkeit ~300.000 km/s, aber Routing + Processing addiert sich
|
Latenz: Lichtgeschwindigkeit ~300.000 km/s, aber Routing + Processing addiert sich
|
||||||
Edge Computing: Server näher an User (5G-Masten)
|
Edge Computing: Server näher an Nutzende (5G-Masten)
|
||||||
Cloud Gaming: Stadia gescheitert (2023 †), GeForce Now, Xbox Cloud
|
Cloud Gaming: Stadia gescheitert (2023 †), GeForce Now, Xbox Cloud
|
||||||
Input-Lag: Fiber ~5ms/1000km, aber Server-Processing + Encoding + Decoding
|
Input-Lag: Fiber ~5ms/1000km, aber Server-Processing + Encoding + Decoding
|
||||||
-->
|
-->
|
||||||
|
|||||||
@@ -451,9 +451,9 @@ Ordne jede Eigenschaft zu: Vorteil von Analog oder Vorteil von Digital?
|
|||||||
**Punkte:** 3
|
**Punkte:** 3
|
||||||
**Typ:** `[ESSAY]`
|
**Typ:** `[ESSAY]`
|
||||||
|
|
||||||
Erklären Sie die drei digitalen Distributionswege **Download**, **Streaming** und **Peer-to-Peer (P2P)**. Beschreiben Sie für jeden Weg: (1) wie die Daten zum Nutzer gelangen, (2) ob der Nutzer eine dauerhafte Kopie erhält, und (3) nennen Sie je ein Beispiel.
|
Erklären Sie die drei digitalen Distributionswege **Download**, **Streaming** und **Peer-to-Peer (P2P)**. Beschreiben Sie für jeden Weg: (1) wie die Daten zu Nutzenden gelangen, (2) ob Nutzende eine dauerhafte Kopie erhalten, und (3) nennen Sie je ein Beispiel.
|
||||||
|
|
||||||
> **Musterlösung:** **Download:** Datei wird vollständig vom Server heruntergeladen und lokal gespeichert. Nutzer erhält dauerhafte Kopie. Beispiel: iTunes Store, Steam. **Streaming:** Daten werden während des Abspielens übertragen, keine dauerhafte lokale Kopie. Beispiel: Netflix, Spotify. **P2P:** Nutzer laden Teile der Datei gleichzeitig von vielen anderen Nutzern herunter (dezentral). Dauerhafte Kopie möglich. Beispiel: BitTorrent.
|
> **Musterlösung:** **Download:** Datei wird vollständig vom Server heruntergeladen und lokal gespeichert. Nutzende erhalten dauerhafte Kopie. Beispiel: iTunes Store, Steam. **Streaming:** Daten werden während des Abspielens übertragen, keine dauerhafte lokale Kopie. Beispiel: Netflix, Spotify. **P2P:** Nutzende laden Teile der Datei gleichzeitig von vielen anderen herunter (dezentral). Dauerhafte Kopie möglich. Beispiel: BitTorrent.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
@@ -630,7 +630,7 @@ KATHLEEN BOOTH (1922–2022):
|
|||||||
Kathleen Hylda Valerie Booth (geb. Britten), BSc Mathematik (Royal Holloway, London), PhD Applied Mathematics (King's College London). Arbeitete ab 1946 mit Andrew Booth (später ihr Ehemann) am Birkbeck College – eines der kleinsten Computing-Teams Großbritanniens: nur Andrew, Kathleen und Xenia Sweeting.
|
Kathleen Hylda Valerie Booth (geb. Britten), BSc Mathematik (Royal Holloway, London), PhD Applied Mathematics (King's College London). Arbeitete ab 1946 mit Andrew Booth (später ihr Ehemann) am Birkbeck College – eines der kleinsten Computing-Teams Großbritanniens: nur Andrew, Kathleen und Xenia Sweeting.
|
||||||
|
|
||||||
WAS SIE TAT:
|
WAS SIE TAT:
|
||||||
Kathleen baute die Hardware des ARC (Automatic Relay Calculator) mit auf und entwickelte dann die Programmierarchitektur. 1947 reiste sie mit Andrew nach Princeton, wo sie John von Neumann trafen und die Stored-Program-Architektur kennenlernten. Sie schrieb "Coding for A.R.C." – die erste veröffentlichte Beschreibung einer Assembly-Sprache. Statt roher Binärzahlen (z.B. 10011) konnten Programmierer nun mnemonische Kürzel verwenden (z.B. M -> cR). Ein konzeptioneller Sprung – die erste Abstraktionsschicht zwischen Mensch und Maschine.
|
Kathleen baute die Hardware des ARC (Automatic Relay Calculator) mit auf und entwickelte dann die Programmierarchitektur. 1947 reiste sie mit Andrew nach Princeton, wo sie John von Neumann trafen und die Stored-Program-Architektur kennenlernten. Sie schrieb "Coding for A.R.C." – die erste veröffentlichte Beschreibung einer Assembly-Sprache. Statt roher Binärzahlen (z.B. 10011) konnten Programmierende nun mnemonische Kürzel verwenden (z.B. M -> cR). Ein konzeptioneller Sprung – die erste Abstraktionsschicht zwischen Mensch und Maschine.
|
||||||
|
|
||||||
VOR ASSEMBLER:
|
VOR ASSEMBLER:
|
||||||
ENIAC (1943–46) wurde durch physisches Umstecken von Kabeln programmiert – Programmwechsel dauerten Tage. Danach kamen Stored-Program-Computer, aber Programme mussten als rohe Binärzahlen eingegeben werden. Jeder Tippfehler in einer 0/1-Folge konnte den Befehl komplett verfälschen.
|
ENIAC (1943–46) wurde durch physisches Umstecken von Kabeln programmiert – Programmwechsel dauerten Tage. Danach kamen Stored-Program-Computer, aber Programme mussten als rohe Binärzahlen eingegeben werden. Jeder Tippfehler in einer 0/1-Folge konnte den Befehl komplett verfälschen.
|
||||||
@@ -714,7 +714,7 @@ Cambridge Analytica (2018): Facebook-Daten von 87 Mio. Nutzern wurden für polit
|
|||||||
|
|
||||||
China Social Credit System: Punktesystem für "gutes Verhalten". Wer zu oft bei Rot geht, bekommt keinen Kredit mehr.
|
China Social Credit System: Punktesystem für "gutes Verhalten". Wer zu oft bei Rot geht, bekommt keinen Kredit mehr.
|
||||||
|
|
||||||
Die Frage: Wer entscheidet, was mit Technologie gemacht wird? Die Entwickler? Die Firmen? Die Politik? Wir alle?
|
Die Frage: Wer entscheidet, was mit Technologie gemacht wird? Die Entwickelnden? Die Firmen? Die Politik? Wir alle?
|
||||||
-->
|
-->
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -1748,7 +1748,7 @@ button:focus-visible {
|
|||||||
border-radius: 4px;
|
border-radius: 4px;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Anti-Pattern: Tastatur-Nutzer sind "blind" */
|
/* Anti-Pattern: Tastatur-Nutzende sind "blind" */
|
||||||
button:focus { outline: none; }
|
button:focus { outline: none; }
|
||||||
```
|
```
|
||||||
|
|
||||||
@@ -1888,7 +1888,7 @@ Fokus-Indikator immer sichtbar? Logische Reihenfolge? Alle Elemente erreichbar?
|
|||||||
|
|
||||||
<!--
|
<!--
|
||||||
WAVE Tab-Reihenfolge: visualisiert DOM-Reihenfolge als Tab-Pfad.
|
WAVE Tab-Reihenfolge: visualisiert DOM-Reihenfolge als Tab-Pfad.
|
||||||
Wenn Pfad kreuz und quer → schlechte Struktur für Tastatur-/Screenreader-Nutzer.
|
Wenn Pfad kreuz und quer → schlechte Struktur für Tastatur-/Screenreader-Nutzende.
|
||||||
-->
|
-->
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|||||||
@@ -1608,7 +1608,7 @@ Wie Encapsulation funktioniert.
|
|||||||
**1. DNS-Auflösung:**
|
**1. DNS-Auflösung:**
|
||||||
- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
|
- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
|
||||||
- Rekursive Abfrage: Root → TLD → Authoritative
|
- Rekursive Abfrage: Root → TLD → Authoritative
|
||||||
- Caching auf jeder Ebene (TTL = Time To Live)
|
- Caching auf jeder Ebene (TTL = Time To Live)
|
||||||
|
|
||||||
**2. TCP-Verbindungsaufbau:**
|
**2. TCP-Verbindungsaufbau:**
|
||||||
- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
|
- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
|
||||||
|
|||||||
@@ -619,7 +619,7 @@ Ordne jedem Szenario den passenden HTTP-Status-Code zu.
|
|||||||
|
|
||||||
Erklären Sie die drei HTTP-Status-Code-Kategorien **2xx**, **4xx** und **5xx**. Beschreiben Sie für jede: (1) was sie bedeutet, (2) wer „schuld" ist (Client oder Server), (3) ein konkretes Beispiel mit Szenario.
|
Erklären Sie die drei HTTP-Status-Code-Kategorien **2xx**, **4xx** und **5xx**. Beschreiben Sie für jede: (1) was sie bedeutet, (2) wer „schuld" ist (Client oder Server), (3) ein konkretes Beispiel mit Szenario.
|
||||||
|
|
||||||
> **Musterlösung:** **2xx (Erfolg):** Die Anfrage wurde erfolgreich verarbeitet. Niemand ist „schuld" – alles funktioniert. Beispiel: 200 OK – die Webseite wurde korrekt geladen. **4xx (Client-Fehler):** Die Anfrage war fehlerhaft. Der Client ist verantwortlich. Beispiel: 404 Not Found – der Benutzer hat eine URL eingetippt, die nicht existiert. **5xx (Server-Fehler):** Der Server hat ein Problem. Der Betreiber ist verantwortlich. Beispiel: 503 Service Unavailable – der Server ist überlastet oder in Wartung.
|
> **Musterlösung:** **2xx (Erfolg):** Die Anfrage wurde erfolgreich verarbeitet. Niemand ist „schuld" – alles funktioniert. Beispiel: 200 OK – die Webseite wurde korrekt geladen. **4xx (Client-Fehler):** Die Anfrage war fehlerhaft. Der Client ist verantwortlich. Beispiel: 404 Not Found – Nutzende haben eine URL eingetippt, die nicht existiert. **5xx (Server-Fehler):** Der Server hat ein Problem. Der Betreiber ist verantwortlich. Beispiel: 503 Service Unavailable – der Server ist überlastet oder in Wartung.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user