Compare commits
12
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
8d5c57d561 | ||
|
|
3a2e1a8d15 | ||
|
|
ac89d69365 | ||
|
|
552949811e | ||
|
|
030bb322a2 | ||
|
|
9631a1c45b | ||
|
|
4245ea2567 | ||
|
|
51146d3dfc | ||
|
|
fda4aca4c7 | ||
|
|
aff352fa91 | ||
|
|
ea7e905c61 | ||
|
|
512fbd9d3d |
@@ -12,6 +12,7 @@ This project builds presentation decks for Marp, supporting multiple courses.
|
||||
- Agent NEVER runs commands outside this folder
|
||||
- Agent NEVER runs build/deploy commands without explicit user request
|
||||
- Agent NEVER runs deploy commands (make deploy, scp, etc.) without explicit user permission
|
||||
- Agent NEVER runs `git checkout --` or `git restore` on files with uncommitted work. To undo specific changes, use targeted Edit operations instead.
|
||||
|
||||
## Critical File Protection
|
||||
|
||||
@@ -48,10 +49,7 @@ make deploy # Deploy all (ASK FIRST!)
|
||||
## Nix Flake Commands
|
||||
|
||||
```bash
|
||||
nix develop # Dev shell with all tools
|
||||
nix run .#qr -- "https://example.com" # Generate QR code
|
||||
nix run .#qr-slides -- 223015b # QR for course
|
||||
nix run .#optimize-img -- <path> # Optimize images
|
||||
nix develop # Dev shell with all tools (node 22, npm, make)
|
||||
```
|
||||
|
||||
## Code Style Guidelines
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
{
|
||||
description = "HdM Slides - Marp presentation builder with tools";
|
||||
description = "HdM Slides - Marp presentation builder";
|
||||
|
||||
inputs = {
|
||||
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
|
||||
@@ -9,116 +9,19 @@
|
||||
outputs = { self, nixpkgs, flake-utils }:
|
||||
flake-utils.lib.eachDefaultSystem (system:
|
||||
let
|
||||
pkgs = import nixpkgs { inherit system; config.allowUnfree = true; };
|
||||
|
||||
|
||||
# QR code generator script
|
||||
qr-gen = pkgs.writeShellScriptBin "qr" ''
|
||||
if [ -z "$1" ]; then
|
||||
echo "Usage: qr <url> [output.png]"
|
||||
echo ""
|
||||
echo "Examples:"
|
||||
echo " qr https://example.com"
|
||||
echo " qr https://example.com my-qr.png"
|
||||
echo " qr 'https://librete.ch/hdm/223015b/' slides-qr.png"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
URL="$1"
|
||||
OUTPUT="''${2:-qr-code.png}"
|
||||
|
||||
${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "$URL"
|
||||
echo "Generated: $OUTPUT"
|
||||
'';
|
||||
|
||||
# QR code for course slides
|
||||
qr-slides = pkgs.writeShellScriptBin "qr-slides" ''
|
||||
COURSE="''${1:-223015b}"
|
||||
OUTPUT="''${2:-build/$COURSE/qr-$COURSE.png}"
|
||||
|
||||
mkdir -p "$(dirname "$OUTPUT")"
|
||||
${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "https://librete.ch/hdm/$COURSE/"
|
||||
echo "Generated QR for $COURSE: $OUTPUT"
|
||||
'';
|
||||
|
||||
# Image optimizer script
|
||||
optimize-img = pkgs.writeShellScriptBin "optimize-img" ''
|
||||
if [ -z "$1" ]; then
|
||||
echo "Usage: optimize-img <image-or-directory> [max-width]"
|
||||
echo ""
|
||||
echo "Resizes images to max width (default: 1920px)"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
TARGET="$1"
|
||||
MAX_WIDTH="''${2:-1920}"
|
||||
|
||||
if [ -d "$TARGET" ]; then
|
||||
for img in "$TARGET"/*.{png,jpg,jpeg,webp} 2>/dev/null; do
|
||||
[ -f "$img" ] || continue
|
||||
echo "Optimizing: $(basename "$img")"
|
||||
${pkgs.imagemagick}/bin/magick "$img" -resize "''${MAX_WIDTH}x>" -quality 85 "$img"
|
||||
done
|
||||
elif [ -f "$TARGET" ]; then
|
||||
echo "Optimizing: $TARGET"
|
||||
${pkgs.imagemagick}/bin/magick "$TARGET" -resize "''${MAX_WIDTH}x>" -quality 85 "$TARGET"
|
||||
else
|
||||
echo "Error: $TARGET not found"
|
||||
exit 1
|
||||
fi
|
||||
echo "Done!"
|
||||
'';
|
||||
|
||||
pkgs = import nixpkgs { inherit system; };
|
||||
in {
|
||||
# Development shell with all tools
|
||||
devShells.default = pkgs.mkShell {
|
||||
buildInputs = with pkgs; [
|
||||
nodejs_20
|
||||
nodejs_22
|
||||
nodePackages.npm
|
||||
qrencode
|
||||
imagemagick
|
||||
gnumake
|
||||
claude-code
|
||||
];
|
||||
|
||||
shellHook = ''
|
||||
echo "HdM Slides Development Environment"
|
||||
echo ""
|
||||
echo "Available commands:"
|
||||
echo " make dev-b - Start 223015b dev server (port 1312)"
|
||||
echo " make dev-c - Start 223015c dev server (port 1313)"
|
||||
echo " make build - Build all courses"
|
||||
echo " qr <url> - Generate QR code"
|
||||
echo " qr-slides 223015b - Generate QR for course"
|
||||
echo " optimize-img <dir> - Optimize images"
|
||||
echo ""
|
||||
echo "HdM Slides - run 'make' for available commands"
|
||||
'';
|
||||
};
|
||||
|
||||
# Standalone apps
|
||||
packages = {
|
||||
qr = qr-gen;
|
||||
qr-slides = qr-slides;
|
||||
optimize-img = optimize-img;
|
||||
default = qr-gen;
|
||||
};
|
||||
|
||||
# Direct runnable apps
|
||||
apps = {
|
||||
qr = {
|
||||
type = "app";
|
||||
program = "${qr-gen}/bin/qr";
|
||||
};
|
||||
qr-slides = {
|
||||
type = "app";
|
||||
program = "${qr-slides}/bin/qr-slides";
|
||||
};
|
||||
optimize-img = {
|
||||
type = "app";
|
||||
program = "${optimize-img}/bin/optimize-img";
|
||||
};
|
||||
default = self.apps.${system}.qr;
|
||||
};
|
||||
}
|
||||
);
|
||||
}
|
||||
|
||||
@@ -231,7 +231,7 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
<h1>HdM Vorlesungen</h1>
|
||||
<h2 class="course-heading">$TITLE</h2>
|
||||
<p class="subtitle">$SUBTITLE</p>
|
||||
<p class="meta">HdM Stuttgart · Wintersemester 2025/26 · Michael Czechowski</p>
|
||||
<p class="meta">HdM Stuttgart · Sommersemester 2026 · Michael Czechowski</p>
|
||||
</header>
|
||||
<div class="termine">
|
||||
HEADER
|
||||
|
||||
@@ -143,7 +143,7 @@ cat > "$BUILD_DIR/index.html" << 'HEADER'
|
||||
</head>
|
||||
<body>
|
||||
<h1>HdM Vorlesungen</h1>
|
||||
<p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p>
|
||||
<p class="subtitle">Sommersemester 2026 · Michael Czechowski</p>
|
||||
<div class="courses">
|
||||
<div class="course-card course-b">
|
||||
<a href="223015b/" class="course-link">
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -82,7 +82,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
+1200
-1292
File diff suppressed because it is too large
Load Diff
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -68,6 +68,38 @@ section.aufgabe {
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#e3f2fd,
|
||||
#e3f2fd 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #1e5f8a;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -82,7 +114,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
@@ -235,6 +267,29 @@ Kleine SSD für System + große HDD für Archiv.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HDD vs. SSD – Vertiefung
|
||||
|
||||
**HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor).
|
||||
|
||||
**SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles).
|
||||
|
||||
| Aspekt | HDD | SATA SSD | NVMe SSD |
|
||||
|--------|-----|----------|----------|
|
||||
| Latenz | 5–10 ms | 0,1 ms | 0,02 ms |
|
||||
| Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s |
|
||||
| IOPS (4K random) | 100 | 90.000 | 1.000.000 |
|
||||
| TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW |
|
||||
|
||||
**Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke.
|
||||
|
||||
**Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Dateisysteme
|
||||
@@ -484,6 +539,30 @@ Warum 1 Offsite?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 3-2-1-Backup-Regel – Vertiefung
|
||||
|
||||
Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien:
|
||||
|
||||
| Bedrohung | Schutz durch | Beispiel |
|
||||
|-----------|--------------|----------|
|
||||
| Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden |
|
||||
| Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System |
|
||||
| Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher |
|
||||
|
||||
**Moderne Erweiterung 3-2-1-1-0:**
|
||||
- **+1** Air-Gapped (offline, nicht verbunden)
|
||||
- **+0** Verifizierte Backups (regelmäßig Restore testen)
|
||||
|
||||
**Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind.
|
||||
|
||||
**Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots.
|
||||
|
||||
---
|
||||
|
||||
# Backup-Arten
|
||||
|
||||
**Vollständig (Full):**
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
<style>
|
||||
@@ -92,7 +92,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
@@ -102,6 +102,166 @@ Hochschule der Medien Stuttgart
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Verlustfrei vs. Verlustbehaftet
|
||||
|
||||
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||||
|---|---|---|
|
||||
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
|
||||
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
|
||||
| **Reduktion** | 30-50% | 80-99% |
|
||||
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
|
||||
|
||||
**Faustregel:**
|
||||
- Medien für Endnutzer → Lossy oft akzeptabel
|
||||
- Quellmaterial, Code, Archive → Lossless nötig
|
||||
|
||||
<!--
|
||||
REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
|
||||
IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
|
||||
|
||||
KLAUSURRELEVANT:
|
||||
- Verlustfrei = Original 1:1 wiederherstellbar
|
||||
- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
|
||||
- Redundanz vs. Irrelevanz ist der Kernunterschied!
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Dateneinheiten
|
||||
|
||||
| Einheit | Bytes | Potenz | Beispiel |
|
||||
|---------|------:|:------:|----------|
|
||||
| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
|
||||
| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
|
||||
| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
|
||||
| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
|
||||
| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
|
||||
| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
|
||||
| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
|
||||
| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
|
||||
|
||||
<!--
|
||||
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
|
||||
Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
|
||||
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
|
||||
1 TB Festplatte = ~931 GiB nutzbar
|
||||
|
||||
Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
|
||||
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Der digitale Wendepunkt
|
||||
|
||||
| Jahr | Analog | Digital | Digital-Anteil |
|
||||
|------|--------|---------|----------------|
|
||||
| **1986** | 2,6 EB | 0,02 EB | **1%** |
|
||||
| **2002** | — | — | **50%** (Wendepunkt) |
|
||||
| **2007** | 18 EB | 277 EB | **94%** |
|
||||
|
||||
**Perspektive:**
|
||||
- 1986: "Petabyte" war ein theoretisches Konzept
|
||||
- 2025: ~181 Zettabyte jährlich produziert
|
||||
|
||||
**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
|
||||
(AWS Glacier, Film-Archive, Rechenzentren)
|
||||
|
||||
<!--
|
||||
PRÜFUNGSRELEVANT:
|
||||
- Wendepunkt 2002
|
||||
- Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
|
||||
- Magnetband als Archivmedium
|
||||
|
||||
QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
|
||||
|
||||
METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
|
||||
|
||||
WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
|
||||
|
||||
ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
|
||||
|
||||
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
|
||||
|
||||
HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
|
||||
|
||||
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
|
||||
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Analoge Medien
|
||||
### Distribution: physisch (Kauf, Verleih, Kopie)
|
||||
|
||||
- **Text**
|
||||
- Bücher, Zeitungen, Zeitschriften, Lochkarten
|
||||
- **Bild**
|
||||
- Fotografie (Negativ, Dia, Polaroid), Mikrofilm
|
||||
- **Audio:**
|
||||
- Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
|
||||
- **Video:**
|
||||
- Film (35mm, Super 8), VHS, Betamax
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Digitale Medien
|
||||
### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
|
||||
|
||||
- **Text**
|
||||
- E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
|
||||
- **Bild**
|
||||
- Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
|
||||
- **Audio**
|
||||
- Audiodatei (MP3, FLAC, WAV, AAC, OGG)
|
||||
- **Video**
|
||||
- Videodatei (MP4, MKV, AVI, WebM)
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Digitale Speichermedien
|
||||
|
||||
- **Optische Speicher**
|
||||
- CD, DVD, Blu-ray
|
||||
- **Magnetische Speicher**
|
||||
- Festplatte (HDD), Magnetband (LTO)
|
||||
- **Flash-Speicher**
|
||||
- SSD, USB-Stick, SD-Karte
|
||||
- **Cloud-Speicher**
|
||||
- Dropbox, Google Drive, iCloud, AWS S3
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Rastergrafiken
|
||||
|
||||
**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
|
||||
@@ -243,6 +403,7 @@ KLAUSURRELEVANT:
|
||||
- Präfix-frei: Kein Code ist Anfang eines anderen
|
||||
- Häufigstes Zeichen = kürzester Code
|
||||
- Auch in ZIP, PNG, MP3 verwendet
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
+492
-12
@@ -3,9 +3,9 @@ marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Klausurfragen – 223015b"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
title: "Klausurfragen – Dateiformate, Schnittstellen, Speichermedien"
|
||||
header: ""
|
||||
footer: ""
|
||||
title: "Fragenkatalog – Dateiformate (223015b)"
|
||||
---
|
||||
<style>
|
||||
:root {
|
||||
@@ -13,17 +13,38 @@ title: "Klausurfragen – Dateiformate, Schnittstellen, Speichermedien"
|
||||
--color-highlight: #1e5f8a;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert { --color-foreground: #fff; }
|
||||
section { font-size: 1.325rem; }
|
||||
h1 { color: #1e5f8a; }
|
||||
section.invert h1 { color: #fff; }
|
||||
h2 { color: #1f2937; }
|
||||
pre { background: #0f0f23; border-radius: 8px; }
|
||||
pre code { background: transparent; color: inherit; }
|
||||
a { color: var(--color-highlight); }
|
||||
section.disable { opacity: 0.3; }
|
||||
section.invert {
|
||||
--color-foreground: #fff;
|
||||
}
|
||||
section {
|
||||
font-size: 1.325rem;
|
||||
}
|
||||
h1 {
|
||||
color: #1e5f8a;
|
||||
}
|
||||
section.invert h1 {
|
||||
color: #fff;
|
||||
}
|
||||
h2 {
|
||||
color: #1f2937; /* dark gray, almost black */
|
||||
}
|
||||
pre {
|
||||
background: #0f0f23;
|
||||
border-radius: 8px;
|
||||
}
|
||||
pre code {
|
||||
background: transparent;
|
||||
color: inherit;
|
||||
}
|
||||
a {
|
||||
color: var(--color-highlight);
|
||||
}
|
||||
section.disable {
|
||||
opacity: 0.3;
|
||||
}
|
||||
</style>
|
||||
|
||||
|
||||
# Klausurfragen – 223015b
|
||||
**Dateiformate, Schnittstellen, Speichermedien · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
@@ -49,6 +70,8 @@ section.disable { opacity: 0.3; }
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J1 – Was bedeutet „komprimieren"?
|
||||
**Thema:** Grundbegriffe – Kompression
|
||||
**Punkte:** 1
|
||||
@@ -96,6 +119,8 @@ Erkläre den Unterschied zwischen verlustfreier und verlustbehafteter Kompressio
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J4 – Was bedeutet „skalieren"?
|
||||
**Thema:** Grundbegriffe – Skalierung
|
||||
**Punkte:** 1
|
||||
@@ -112,6 +137,8 @@ Was passiert, wenn ein Rasterbild vergrößert wird?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J5 – Was bedeutet „konvertieren"?
|
||||
**Thema:** Grundbegriffe – Konvertierung
|
||||
**Punkte:** 1
|
||||
@@ -128,6 +155,8 @@ Was bedeutet es, eine Datei zu konvertieren?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J6 – Was bedeutet „codieren" und „decodieren"?
|
||||
**Thema:** Grundbegriffe – Codec-Konzept
|
||||
**Punkte:** 2
|
||||
@@ -172,6 +201,8 @@ Ordne zu: Container oder Codec?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J9 – Redundanz vs. Irrelevanz
|
||||
**Thema:** Grundbegriffe – Kompressionsprinzipien
|
||||
**Punkte:** 2
|
||||
@@ -206,6 +237,8 @@ Sortiere die Dateneinheiten von kleinster zu größter:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J11 – Bit und Byte: Umrechnung
|
||||
**Thema:** Grundbegriffe – Bit/Byte-Verhältnis
|
||||
**Punkte:** 1
|
||||
@@ -219,6 +252,8 @@ Ein Bit ist die kleinste Informationseinheit. Ein Byte besteht aus wie vielen Bi
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J12 – 7-Bit ASCII: Wie viele Zeichen?
|
||||
**Thema:** Grundbegriffe – ASCII-Zeichenkodierung
|
||||
**Punkte:** 1
|
||||
@@ -232,6 +267,8 @@ Der ASCII-Standard verwendet 7 Bit pro Zeichen. Wie viele verschiedene Zeichen k
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J13 – Hexadezimalzahlen: Zwei 4-Bit-Werte
|
||||
**Thema:** Grundbegriffe – Hexadezimal
|
||||
**Punkte:** 2
|
||||
@@ -245,6 +282,8 @@ Zwei Hexadezimalzahlen werden jeweils durch 4 Bit dargestellt. Wie viele verschi
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J14 – Ein Pixel, drei Kanäle, 8 Bit
|
||||
**Thema:** Grundbegriffe – Speicherbedarf eines Pixels
|
||||
**Punkte:** 1
|
||||
@@ -258,6 +297,181 @@ Ein einzelner Pixel wird durch drei Farbkanäle (R, G, B) mit jeweils 8 Bit Farb
|
||||
|
||||
---
|
||||
|
||||
### J15 – Analoge Medien: Übersicht
|
||||
**Thema:** Medientypen – Analog
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Medientyp ein typisches analoges Format zu.
|
||||
|
||||
| Medientyp | Analoges Format |
|
||||
|---|---|
|
||||
| Text | Buch, Zeitung, Lochkarte |
|
||||
| Bild | Fotografie (Negativ, Dia), Mikrofilm |
|
||||
| Audio | Schallplatte (Vinyl), Tonband, Musikkassette |
|
||||
| Video | Film (35mm, Super 8), VHS, Betamax |
|
||||
|
||||
> **Feedback:** Analoge Medien speichern Information als kontinuierliche physikalische Größe – Rillentiefe, Magnetfeldstärke, Silberkorn-Dichte. Distribution erfolgt physisch: Kauf, Verleih, Kopie.
|
||||
|
||||
---
|
||||
|
||||
### J16 – Generationsverlust: Das Problem analoger Kopien
|
||||
**Thema:** Analog vs. Digital – Kopierqualität
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was passiert, wenn eine VHS-Kassette auf eine andere VHS-Kassette kopiert wird?
|
||||
|
||||
- [ ] Die Kopie ist bit-identisch mit dem Original – kein Unterschied erkennbar.
|
||||
- [x] **Jede Kopie verschlechtert die Qualität – Rauschen nimmt zu, Schärfe ab.** ✅
|
||||
- [ ] Die Kopie wird besser, weil das Kopiergerät Rauschen herausfiltert.
|
||||
- [ ] Die Qualität bleibt exakt gleich, nur das Medium wechselt.
|
||||
|
||||
> **Feedback:** Generationsverlust ist ein fundamentales Problem analoger Medien: Jede Kopie addiert neues Rauschen. Bei der 3. Generation ist das Material oft unbrauchbar. Digital: Kopie = Original (bit-identisch).
|
||||
|
||||
---
|
||||
|
||||
### J17 – Digitale Medien: Formate zuordnen
|
||||
**Thema:** Medientypen – Digital
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Medientyp typische digitale Formate zu.
|
||||
|
||||
| Medientyp | Digitale Formate |
|
||||
|---|---|
|
||||
| Text | PDF, EPUB, TXT, DOCX |
|
||||
| Bild | JPEG, PNG, RAW, WebP, GIF |
|
||||
| Audio | MP3, FLAC, WAV, AAC, OGG |
|
||||
| Video | MP4, MKV, AVI, WebM |
|
||||
|
||||
> **Feedback:** Digitale Medien werden über Datenträger (CD, USB), Download, Streaming oder P2P verteilt. Der entscheidende Vorteil: bit-identische Kopien ohne Qualitätsverlust.
|
||||
|
||||
---
|
||||
|
||||
### J18 – Analog vs. Digital: Der Hauptunterschied
|
||||
**Thema:** Analog vs. Digital – Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der fundamentale Unterschied zwischen analoger und digitaler Speicherung?
|
||||
|
||||
- [ ] Analog speichert in diskreten Stufen, digital als kontinuierliches Signal.
|
||||
- [ ] Analog nutzt Elektrizität, digital nutzt Magnetismus zur Speicherung.
|
||||
- [x] **Analog speichert kontinuierlich (z.B. Rillentiefe), digital in diskreten Bits.** ✅
|
||||
- [ ] Analog ist für Audio, digital ist ausschließlich für Text geeignet.
|
||||
|
||||
> **Feedback:** Analog = kontinuierlich (Rillentiefe, Magnetfeldstärke). Digital = diskret (0 und 1). Die Quantisierung ist der „Preis" der Digitalisierung, aber danach bleibt die Information exakt – perfekte Kopien möglich.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J19 – Analoge Distribution: Wie kam Musik zum Käufer?
|
||||
**Thema:** Distribution – Analog
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie wurden analoge Medien typischerweise verbreitet?
|
||||
|
||||
- [ ] Per Download aus dem Internet auf den heimischen Computer.
|
||||
- [ ] Über Streaming-Dienste wie Spotify oder Apple Music.
|
||||
- [x] **Physisch: Kauf im Laden, Verleih, Kopie auf Kassette.** ✅
|
||||
- [ ] Über dezentrale Peer-to-Peer-Netzwerke zwischen Nutzern.
|
||||
|
||||
> **Feedback:** Analoge Distribution war immer physisch gebunden: Man musste das Medium besitzen oder ausleihen. Kopieren war möglich (Kassette), aber mit Qualitätsverlust verbunden.
|
||||
|
||||
---
|
||||
|
||||
### J20 – Digitale Distribution: Die vier Wege
|
||||
**Thema:** Distribution – Digital
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Distributionsform ein Beispiel zu.
|
||||
|
||||
| Distributionsform | Beispiel |
|
||||
|---|---|
|
||||
| Datenträger | CD, DVD, USB-Stick |
|
||||
| Download | iTunes Store, Steam, Bandcamp |
|
||||
| Streaming | Netflix, Spotify, YouTube |
|
||||
| Peer-to-Peer (P2P) | BitTorrent, eDonkey |
|
||||
|
||||
> **Feedback:** Digital ermöglicht vier Distributionswege: physische Datenträger (wie analog, aber ohne Generationsverlust), Download (Besitz einer Kopie), Streaming (Zugriff ohne Besitz), P2P (dezentrale Verteilung zwischen Nutzern).
|
||||
|
||||
---
|
||||
|
||||
### J21 – Streaming vs. Download: Was ist der Unterschied?
|
||||
**Thema:** Distribution – Streaming
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was unterscheidet Streaming von einem Download?
|
||||
|
||||
- [ ] Streaming speichert die Datei dauerhaft, Download nur temporär.
|
||||
- [ ] Streaming ist immer kostenlos, Download immer kostenpflichtig.
|
||||
- [x] **Streaming überträgt während des Abspielens, ohne dauerhafte Kopie.** ✅
|
||||
- [ ] Streaming funktioniert offline, Download braucht ständig Internet.
|
||||
|
||||
> **Feedback:** Streaming = „Wasserhahn" (Daten fließen, solange man zuschaut/hört). Download = „Flasche füllen" (Datei bleibt). Streaming braucht ständige Internetverbindung; Downloads funktionieren offline.
|
||||
|
||||
---
|
||||
|
||||
### J22 – Analog vs. Digital: Vor- und Nachteile
|
||||
**Thema:** Analog vs. Digital – Vergleich
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jede Eigenschaft zu: Vorteil von Analog oder Vorteil von Digital?
|
||||
|
||||
| Eigenschaft | Vorteil von |
|
||||
|---|---|
|
||||
| Kein Abspielgerät nötig (Buch lesen) | Analog |
|
||||
| Bit-identische Kopien ohne Qualitätsverlust | Digital |
|
||||
| Unabhängig von Strom und Internet | Analog |
|
||||
| Einfache Durchsuchbarkeit (Strg+F) | Digital |
|
||||
| Haptisches Erlebnis | Analog |
|
||||
| Fehlerkorrektur möglich (ECC, RAID) | Digital |
|
||||
|
||||
> **Feedback:** Analog: physisch, unabhängig, haptisch – aber Verschleiß und Generationsverlust. Digital: perfekte Kopien, durchsuchbar, korrigierbar – aber abhängig von Technik und Formaten.
|
||||
|
||||
---
|
||||
|
||||
### J23 – Distribution vergleichen: Download, Streaming, P2P
|
||||
**Thema:** Distribution – Vergleich
|
||||
**Punkte:** 3
|
||||
**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.
|
||||
|
||||
> **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.
|
||||
|
||||
---
|
||||
|
||||
### J24 – Analog vs. Digital: Kopieren und Archivieren
|
||||
**Thema:** Analog vs. Digital – Transfer
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Vergleichen Sie **analoge** und **digitale** Medien hinsichtlich (1) Kopierqualität, (2) Langzeitarchivierung und (3) Abhängigkeit von Technik. Nennen Sie je einen konkreten Vor- und Nachteil.
|
||||
|
||||
> **Musterlösung:** **Kopierqualität:** Analog: Jede Kopie verschlechtert sich (Generationsverlust). Digital: Bit-identische Kopien ohne Qualitätsverlust. **Langzeitarchivierung:** Analog: Physischer Verschleiß, aber lesbar ohne spezielle Software (Buch). Digital: Bits altern nicht, aber Formate können obsolet werden (DOCX in 50 Jahren?). **Technikabhängigkeit:** Analog: Buch braucht keinen Strom. Digital: Abhängig von funktionierender Hard- und Software. Vorteil Analog: Unabhängigkeit. Nachteil Analog: Generationsverlust. Vorteil Digital: Perfekte Kopien. Nachteil Digital: Formatobsoleszenz.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### J25 – Redundanz vs. Irrelevanz erklären
|
||||
**Thema:** Kompression – Prinzipien
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Verlustfreie und verlustbehaftete Kompression nutzen unterschiedliche Prinzipien. Erklären Sie: (1) Was bedeutet **Redundanz entfernen**? (2) Was bedeutet **Irrelevanz entfernen**? (3) Welches Prinzip nutzt welcher Kompressionstyp?
|
||||
|
||||
> **Musterlösung:** **(1) Redundanz:** Wiederholende Muster kompakter darstellen – z.B. "AAAAAAA" → "7×A". Die originalen Daten können perfekt rekonstruiert werden. **(2) Irrelevanz:** Daten wegwerfen, die Menschen nicht wahrnehmen – z.B. unhörbare Frequenzen in Audio, unsichtbare Farbunterschiede in Bildern. Nicht umkehrbar. **(3) Zuordnung:** Verlustfrei = Redundanz (ZIP, PNG, FLAC). Verlustbehaftet = Irrelevanz (JPEG, MP3).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK K – Bildformate & Raster vs. Vektor
|
||||
@@ -376,6 +590,8 @@ Erkläre, warum ein Rasterbild beim Vergrößern unscharf wird, während ein Vek
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### K8 – Vektor → Raster: Wie heißt das?
|
||||
**Thema:** Raster vs. Vektor – Konvertierung
|
||||
**Punkte:** 1
|
||||
@@ -412,12 +628,51 @@ Ordne jedem Interpolationsverfahren seine Eigenschaft zu.
|
||||
|
||||
---
|
||||
|
||||
### K10 – Bildtypen vergleichen: Foto, Screenshot, Logo
|
||||
**Thema:** Bildformate – Anwendungsfälle
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Sie haben drei Bilder: ein **Foto**, einen **Screenshot** und ein **Logo**. Erklären Sie für jedes Bild, welches Format (JPEG, PNG oder SVG) Sie wählen würden und warum. Begründen Sie Ihre Wahl mit den technischen Eigenschaften des Formats.
|
||||
|
||||
> **Musterlösung:** **Foto → JPEG:** Verlustbehaftete Kompression ist akzeptabel, da kleine Artefakte bei natürlichen Bildern kaum auffallen. Dateigröße deutlich kleiner als PNG. **Screenshot → PNG:** Verlustfreie Kompression erhält scharfe Texte und Linien. JPEG würde sichtbare Artefakte an Kanten erzeugen. **Logo → SVG:** Vektorgrafik ist beliebig skalierbar ohne Qualitätsverlust – ein Logo muss auf Visitenkarte und Plakatwand gleich scharf sein. Dateigröße bei einfachen Formen minimal.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### K11 – Farbtiefe erklären: 1-Bit, 8-Bit, 24-Bit, 32-Bit
|
||||
**Thema:** Rastergrafiken – Farbtiefe
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die Farbtiefen **1-Bit**, **8-Bit**, **24-Bit** und **32-Bit**. Beschreiben Sie für jede: (1) wie viele Farben dargestellt werden können, (2) einen typischen Anwendungsfall.
|
||||
|
||||
> **Musterlösung:** **1-Bit:** 2¹ = 2 Farben (Schwarz/Weiß). Anwendung: Strichzeichnungen, Fax, QR-Codes. **8-Bit:** 2⁸ = 256 Farben. Anwendung: GIF-Bilder, Graustufen, Paletten-Bilder. **24-Bit:** 2²⁴ = 16,7 Millionen Farben (8 Bit pro Kanal: R, G, B). Anwendung: Standard für Fotos und Webgrafiken ("True Color"). **32-Bit:** 24 Bit Farbe + 8 Bit Alpha-Kanal (Transparenz). Anwendung: PNG mit Transparenz, Compositing in Grafikprogrammen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### K12 – Rasterisierung vs. Vektorisierung
|
||||
**Thema:** Raster vs. Vektor – Konvertierung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die beiden Konvertierungsprozesse **Rasterisierung** und **Vektorisierung** (Tracing). Beschreiben Sie: (1) die Richtung der Umwandlung, (2) ob Qualitätsverlust entsteht, (3) warum einer der Prozesse problematischer ist.
|
||||
|
||||
> **Musterlösung:** **Rasterisierung (Vektor → Raster):** Trivial und verlustfrei bei gewählter Auflösung. Aus mathematischen Beschreibungen werden Pixel berechnet. Funktioniert immer perfekt. **Vektorisierung (Raster → Vektor):** Problematisch. Software muss Kanten "erraten" und als Pfade nachzeichnen. Funktioniert gut bei einfachen Grafiken (Logos), schlecht bei Fotos. Immer mit Qualitätsverlust/Interpretation verbunden.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK L – JPEG: Innenleben
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L1 – JPEG: Verlustfrei oder verlustbehaftet?
|
||||
**Thema:** JPEG – Grundeigenschaft
|
||||
**Punkte:** 1
|
||||
@@ -466,6 +721,8 @@ Warum wird bei JPEG von RGB in YCbCr konvertiert?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L4 – Chroma Subsampling: Was ist 4:2:0?
|
||||
**Thema:** JPEG Schritt 2 – Subsampling
|
||||
**Punkte:** 2
|
||||
@@ -482,6 +739,8 @@ Was bedeutet das Subsampling-Schema 4:2:0?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L5 – JPEG-Schritte: Richtige Reihenfolge
|
||||
**Thema:** JPEG – Kompressionsablauf
|
||||
**Punkte:** 2
|
||||
@@ -500,6 +759,8 @@ Sortiere die Schritte der JPEG-Kompression in der richtigen Reihenfolge:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L6 – Welcher Schritt ist verlustbehaftet?
|
||||
**Thema:** JPEG – Verlust lokalisieren
|
||||
**Punkte:** 1
|
||||
@@ -569,12 +830,51 @@ Ordne jedem JPEG-Artefakt seine Beschreibung zu.
|
||||
|
||||
---
|
||||
|
||||
### L10 – JPEG-Kompression erklären: RGB, YCbCr, DCT
|
||||
**Thema:** JPEG – Pipeline verstehen
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
JPEG komprimiert in mehreren Schritten. Erklären Sie die Rolle von: (1) **RGB → YCbCr Konversion**, (2) **DCT (Discrete Cosine Transform)**, (3) **Quantisierung**. Welcher dieser Schritte ist verlustbehaftet und warum?
|
||||
|
||||
> **Musterlösung:** **(1) RGB → YCbCr:** Trennt Helligkeit (Y) von Farbe (Cb, Cr). Ermöglicht Chroma Subsampling – Farbauflösung wird reduziert, Helligkeit bleibt voll erhalten. Das Auge sieht Helligkeit besser als Farbe. **(2) DCT:** Wandelt 8×8 Pixelblöcke in Frequenzkoeffizienten um. Sortiert Information nach Wichtigkeit: niedrige Frequenzen = grobe Struktur (wichtig), hohe Frequenzen = feine Details (weniger wichtig). Die DCT selbst ist verlustfrei. **(3) Quantisierung:** Hier passiert der Verlust! Frequenzkoeffizienten werden gerundet/auf Null gesetzt – hohe Frequenzen (Details) werden stärker reduziert. Dieser Schritt ist nicht umkehrbar.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L11 – JPEG-Artefakte erklären: Blocking, Ringing, Posterization
|
||||
**Thema:** JPEG – Artefakte verstehen
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
JPEG-komprimierte Bilder zeigen bei niedriger Qualität typische Artefakte. Erklären Sie die drei Artefakte **Blocking**, **Ringing** und **Posterization**. Beschreiben Sie für jedes: (1) wie es aussieht und (2) warum es entsteht.
|
||||
|
||||
> **Musterlösung:** **Blocking:** Sichtbare 8×8-Pixel-Rechtecke. Entsteht, weil jeder Block unabhängig komprimiert wird – bei starker Kompression passen Nachbarblöcke nicht mehr zusammen. **Ringing:** „Geister" oder Halos an scharfen Kanten (z.B. schwarze Schrift auf weißem Hintergrund). Entsteht, weil die DCT mit harten Übergängen schlecht umgehen kann (Gibbs-Phänomen). **Posterization:** Farbverläufe werden stufig statt fließend. Entsteht, weil zu wenige Bits für feine Farbabstufungen übrig bleiben – ähnlich wie ein Poster mit wenigen Farben.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L12 – Warum 8×8-Blöcke bei JPEG?
|
||||
**Thema:** JPEG – Blockgröße
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
JPEG teilt Bilder in 8×8-Pixel-Blöcke auf. Erklären Sie: (1) warum überhaupt Blöcke verwendet werden, (2) warum genau 8×8 (nicht 4×4 oder 16×16), (3) welches Artefakt durch diese Blockaufteilung entstehen kann.
|
||||
|
||||
> **Musterlösung:** **(1) Warum Blöcke:** DCT arbeitet effizienter auf kleinen Bereichen. Globale Analyse wäre rechenintensiv und würde lokale Unterschiede verwischen. **(2) Warum 8×8:** Kompromiss – klein genug für lokale Anpassung, groß genug für effiziente DCT. 64 Koeffizienten sind mathematisch handlich (8² = 64). Historisch auch wegen begrenzter Rechenleistung gewählt. **(3) Artefakt:** Blocking – bei starker Kompression werden die 8×8-Grenzen sichtbar, weil Nachbarblöcke nicht mehr zusammenpassen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK M – Bildformate: PNG, GIF, WebP, SVG
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M1 – PNG: Verlustfrei oder verlustbehaftet?
|
||||
**Thema:** PNG – Grundeigenschaft
|
||||
**Punkte:** 1
|
||||
@@ -591,6 +891,8 @@ Wie komprimiert PNG?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M2 – PNG vs. JPEG: Wann was?
|
||||
**Thema:** Bildformate – Formatwahl
|
||||
**Punkte:** 2
|
||||
@@ -602,6 +904,8 @@ Erklären Sie, wann Sie PNG und wann JPEG wählen würden. Nenne je zwei konkret
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M3 – GIF: Wie viele Farben?
|
||||
**Thema:** GIF – Eigenschaften
|
||||
**Punkte:** 1
|
||||
@@ -636,6 +940,8 @@ Was ist der hauptsächliche Vorteil von WebP gegenüber JPEG?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M5 – SVG: Was ist es?
|
||||
**Thema:** SVG – Grundbegriff
|
||||
**Punkte:** 1
|
||||
@@ -652,6 +958,8 @@ Was ist SVG?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M6 – Formatwahl: Szenario zuordnen
|
||||
**Thema:** Bildformate – Formatwahl Transfer
|
||||
**Punkte:** 2
|
||||
@@ -670,6 +978,30 @@ Ordne jedem Szenario das optimale Bildformat zu.
|
||||
|
||||
---
|
||||
|
||||
### M7 – Bildformate vergleichen: JPEG, PNG, WebP
|
||||
**Thema:** Bildformate – Vergleich
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Vergleichen Sie die drei Bildformate **JPEG**, **PNG** und **WebP**. Beschreiben Sie für jedes: (1) ob es verlustfrei oder verlustbehaftet komprimiert, (2) ob es Transparenz unterstützt, (3) einen idealen Anwendungsfall.
|
||||
|
||||
> **Musterlösung:** **JPEG:** Verlustbehaftet. Keine Transparenz. Ideal für Fotos im Web – kleine Dateien, Qualitätsverlust bei natürlichen Bildern kaum sichtbar. **PNG:** Verlustfrei. Unterstützt Alpha-Transparenz (8 Bit). Ideal für Screenshots, Grafiken mit Text, Bilder mit Transparenz. **WebP:** Kann beides – lossy (wie JPEG) und lossless (wie PNG). Unterstützt Transparenz und Animation. Ideal als moderner Ersatz für beide – 25-35% kleiner als JPEG bei gleicher Qualität.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M8 – GIF vs. moderne Alternativen
|
||||
**Thema:** Bildformate – Animation
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
GIF ist ein altes Format (1987), wird aber noch für Animationen verwendet. Erklären Sie: (1) die Haupteinschränkung von GIF, (2) warum es trotzdem noch populär ist, (3) welche moderne Alternative es gibt.
|
||||
|
||||
> **Musterlösung:** **(1) Haupteinschränkung:** Nur 256 Farben (8-Bit-Palette). Farbverläufe werden stufig, Fotos sehen schlecht aus. **(2) Popularität:** Universelle Browser-Unterstützung, einfach zu teilen, "Meme-Kultur" hat das Format am Leben gehalten. **(3) Alternativen:** WebP (Animation + Millionen Farben + kleiner), APNG (animiertes PNG), oder kurze Videos (MP4/WebM mit `<video>`-Tag statt `<img>`).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK N – Video-Kompression
|
||||
@@ -774,6 +1106,43 @@ Erkläre, warum AV1 als „die Zukunft" der Videokompression gilt. Nenne mindest
|
||||
|
||||
---
|
||||
|
||||
### N7 – Frame-Typen erklären: I-Frame, P-Frame, B-Frame
|
||||
**Thema:** Video – Frame-Typen verstehen
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die drei Frame-Typen **I-Frame**, **P-Frame** und **B-Frame**. Beschreiben Sie für jeden: (1) welche Daten gespeichert werden, (2) die relative Größe im Vergleich, (3) was passiert, wenn ein I-Frame beschädigt wird.
|
||||
|
||||
> **Musterlösung:** **I-Frame (Keyframe):** Vollständiges Bild, unabhängig dekodierbar. Größte Dateigröße (100%). Kein Bezug auf andere Frames. **P-Frame (Predicted):** Speichert nur Änderungen gegenüber vorherigen Frames. Etwa 30% der I-Frame-Größe. Referenziert rückwärts. **B-Frame (Bi-directional):** Speichert Änderungen zu vorherigen UND zukünftigen Frames. Etwa 15% der I-Frame-Größe. Referenziert in beide Richtungen. **Bei beschädigtem I-Frame:** Alle abhängigen P- und B-Frames bis zum nächsten I-Frame können nicht korrekt rekonstruiert werden → sichtbare Fehler, bis ein neuer Keyframe kommt.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N8 – Video-Codecs vergleichen: H.264, H.265, AV1
|
||||
**Thema:** Video – Codec-Vergleich
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Vergleichen Sie die drei Video-Codecs **H.264**, **H.265** und **AV1**. Beschreiben Sie für jeden: (1) das Erscheinungsjahr, (2) die Kompressionseffizienz im Vergleich, (3) die Lizenzierung (kostenpflichtig vs. frei).
|
||||
|
||||
> **Musterlösung:** **H.264 (2003):** Der Standard-Codec für über ein Jahrzehnt. Baseline für Vergleiche. Patentgebühren, aber klar strukturiert. Universelle Unterstützung. **H.265 (2013):** 50% bessere Kompression als H.264. Aber: Patent-Chaos mit drei konkurrierenden Pools → unklare Kosten, zögerliche Adoption. **AV1 (2018):** 30% besser als H.265. Royalty-free und open source (Alliance for Open Media: Google, Netflix, Apple, Amazon). Die Zukunft – aber höherer Rechenaufwand beim Encoding.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N9 – Container vs. Codec: MP4 mit verschiedenen Inhalten
|
||||
**Thema:** Video – Container/Codec Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Eine Datei heißt `video.mp4`. Erklären Sie: (1) Was sagt die Endung `.mp4` über den verwendeten Video-Codec aus? (2) Welche verschiedenen Codecs könnte diese Datei enthalten? (3) Warum kann ein MP4 auf einem Gerät abspielen und auf einem anderen nicht?
|
||||
|
||||
> **Musterlösung:** **(1) Endung:** `.mp4` ist der Container (MPEG-4 Part 14) – sagt nichts über den Codec. **(2) Mögliche Codecs:** H.264, H.265/HEVC, AV1, und andere. Auch verschiedene Audio-Codecs (AAC, MP3, AC3). **(3) Kompatibilität:** Das Gerät muss den Codec unterstützen, nicht nur den Container. Ein alter Fernseher kann MP4-Container öffnen, aber AV1-Codec fehlt → "Format nicht unterstützt".
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK O – Speichermedien & Schnittstellen
|
||||
@@ -922,3 +1291,114 @@ Ordne jedem Backup-Typ seine Beschreibung zu.
|
||||
| Differenziell | Änderungen seit dem letzten Voll-Backup – Mittelweg zwischen beiden |
|
||||
|
||||
> **Feedback:** Typisches Schema: Sonntag Full, Mo–Sa Inkrementell oder Differenziell. Inkrementell = schnellstes Backup, langsamste Wiederherstellung (Kette aufbauen). Full = langsamstes Backup, schnellste Wiederherstellung.
|
||||
|
||||
---
|
||||
|
||||
### O9 – Digitale Speichermedien: Kategorien
|
||||
**Thema:** Speichermedien – Übersicht
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedes Speichermedium seiner technischen Kategorie zu.
|
||||
|
||||
| Medium | Kategorie |
|
||||
|---|---|
|
||||
| CD, DVD, Blu-ray | Optisch |
|
||||
| Festplatte (HDD), Magnetband (LTO) | Magnetisch |
|
||||
| SSD, USB-Stick, SD-Karte | Flash-Speicher |
|
||||
| Dropbox, AWS S3 | Cloud-Speicher |
|
||||
|
||||
> **Feedback:** Optisch: Laser liest Pits/Lands. Magnetisch: magnetisierte Bereiche. Flash: Elektronen in Floating Gates. Cloud: physisch HDD/SSD/LTO in Rechenzentren – keine eigene Technologie, sondern Zugriffsmethode.
|
||||
|
||||
---
|
||||
|
||||
### O10 – Speichermedien: Wann welches?
|
||||
**Thema:** Speichermedien – Anwendungsfall
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Szenario das empfohlene Speichermedium zu.
|
||||
|
||||
| Szenario | Empfohlenes Medium |
|
||||
|---|---|
|
||||
| Betriebssystem (schneller Zugriff) | NVMe SSD |
|
||||
| Videoarchiv (große Datenmengen, günstig) | HDD |
|
||||
| Langzeitarchiv (10+ Jahre) | LTO-Band, M-DISC |
|
||||
| Datenaustausch (portabel) | USB-Stick, SD-Karte |
|
||||
|
||||
> **Feedback:** Die Wahl hängt vom Anwendungsfall ab: SSD = Geschwindigkeit, HDD = Kapazität/Preis, LTO/M-DISC = Langlebigkeit, USB/SD = Portabilität.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O11 – Optische Speicher: CD, DVD, Blu-ray
|
||||
**Thema:** Speichermedien – Optisch
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die optischen Speichermedien nach Kapazität (kleinste zuerst):
|
||||
|
||||
1. CD (~700 MB)
|
||||
2. DVD (~4,7 GB)
|
||||
3. Blu-ray (~25 GB)
|
||||
|
||||
> **Feedback:** Alle drei nutzen Laser zum Lesen von Pits (Vertiefungen) und Lands (Erhöhungen). Die Kapazität steigt durch kürzere Wellenlängen: CD = Infrarot, DVD = Rot, Blu-ray = Blau (daher der Name).
|
||||
|
||||
---
|
||||
|
||||
### O12 – Cloud-Speicher: Was ist das eigentlich?
|
||||
**Thema:** Speichermedien – Cloud
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist „Cloud-Speicher" technisch gesehen?
|
||||
|
||||
- [ ] Eine neue Speichertechnologie, die Daten in Funkwellen speichert.
|
||||
- [ ] Virtuelle Speicher ohne jegliche physische Hardware-Komponenten.
|
||||
- [x] **HDDs/SSDs in Rechenzentren – „Cloud" beschreibt den Internet-Zugriff.** ✅
|
||||
- [ ] Lokale Festplatten, die automatisch mit dem Himmel synchronisieren.
|
||||
|
||||
> **Feedback:** „Cloud" ist Marketing für „fremder Computer". Dropbox, Google Drive, iCloud – alle speichern physisch auf Servern in Rechenzentren. Vorteil: Zugriff von überall. Nachteil: Abhängigkeit von Internet und Anbieter.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O13 – Magnetband (LTO): Warum noch heute?
|
||||
**Thema:** Speichermedien – Magnetband
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Warum verwenden große Unternehmen noch heute Magnetbänder (LTO)?
|
||||
|
||||
- [ ] Magnetbänder sind schneller als SSDs beim wahlfreien Zugriff.
|
||||
- [ ] Magnetbänder werden nur aus nostalgischen Gründen eingesetzt.
|
||||
- [ ] Magnetbänder sind die einzige Technologie für Videospeicherung.
|
||||
- [x] **Extrem günstig pro TB, langlebig, ideal für selten abgerufene Daten.** ✅
|
||||
|
||||
> **Feedback:** LTO = Linear Tape-Open. Aktuell LTO-9: 18 TB pro Band, ~2€/TB. Nachteil: sequentieller Zugriff (kein Random Access). Perfekt für Archivierung, wo Daten selten gelesen werden. Google, Facebook, Banken – alle nutzen LTO.
|
||||
|
||||
---
|
||||
|
||||
### O14 – Speichertechnologien vergleichen: Optisch, Magnetisch, Flash
|
||||
**Thema:** Speichermedien – Technologievergleich
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Beschreiben Sie die drei Speichertechnologien **optisch** (CD/DVD/Blu-ray), **magnetisch** (HDD/LTO) und **Flash** (SSD/USB). Erklären Sie für jede: (1) wie Daten physikalisch gespeichert werden, (2) einen typischen Anwendungsfall und (3) eine wichtige Einschränkung.
|
||||
|
||||
> **Musterlösung:** **Optisch:** Laser liest Pits (Vertiefungen) und Lands (Erhöhungen). Anwendung: Software-Distribution, Archivierung (M-DISC). Einschränkung: Empfindlich gegen Kratzer und UV-Licht. **Magnetisch:** Magnetisierte Bereiche auf Platten (HDD) oder Band (LTO). Anwendung: Massenspeicher, Langzeitarchiv. Einschränkung: HDD hat bewegliche Teile (Verschleiß), LTO nur sequentieller Zugriff. **Flash:** Elektronen in Floating Gates. Anwendung: Betriebssystem (SSD), portable Daten (USB). Einschränkung: Begrenzte Schreibzyklen, Ladungsverlust ohne Strom nach Jahren.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O15 – Backup-Strategien erklären: Full, Inkrementell, Differenziell
|
||||
**Thema:** Backup – Strategievergleich
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die drei Backup-Typen **Full**, **Inkrementell** und **Differenziell**. Beschreiben Sie für jeden: (1) welche Daten gesichert werden, (2) Vor- und Nachteile, und (3) wann dieser Typ sinnvoll eingesetzt wird.
|
||||
|
||||
> **Musterlösung:** **Full:** Kompletter Datenbestand wird jedes Mal gesichert. Vorteil: Einfache Wiederherstellung (nur ein Backup nötig). Nachteil: Langsam, braucht viel Speicherplatz. Einsatz: Wöchentlich als Basis. **Inkrementell:** Nur Änderungen seit dem letzten Backup (egal welcher Art). Vorteil: Schnell, wenig Speicher. Nachteil: Wiederherstellung komplex (Kette aller Backups nötig). Einsatz: Täglich. **Differenziell:** Änderungen seit dem letzten Full-Backup. Vorteil: Schneller als Full, einfachere Wiederherstellung als Inkrementell. Nachteil: Wächst täglich. Einsatz: Mittelweg bei moderatem Datenvolumen.
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
|
||||
---
|
||||
|
||||
@@ -70,18 +70,23 @@ section.aufgabe footer {
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: linear-gradient(180deg, #fff8fa 0%, #fef0f4 100%) !important;
|
||||
border-left: 6px solid #a02060;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#fce4ec,
|
||||
#fce4ec 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.6rem;
|
||||
font-size: 1.5rem;
|
||||
color: #a02060;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
section.erklaerung h2 {
|
||||
font-size: 1.3rem;
|
||||
color: #1f2937;
|
||||
margin-top: 0;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
@@ -89,11 +94,11 @@ section.erklaerung ol {
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.5;
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.95rem;
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
@@ -110,7 +115,7 @@ section.erklaerung table {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
@@ -123,24 +128,13 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Kapitel 1
|
||||
## Geschichte, Grundlagen & HTML
|
||||
|
||||
---
|
||||
|
||||
# Kursübersicht
|
||||
|
||||
**3 Termine (10:00 – 16:30 Uhr):**
|
||||
**Kapitel:**
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 1 | 20.12.2025 | Geschichte, Grundlagen & **HTML** |
|
||||
| 2 | 10.01.2026 | Netzwerke, Protokolle, **semantisches HTML** & **CSS** |
|
||||
| 3 | 24.01.2026 | Interaktivität, Animationen & **JavaScript** |
|
||||
|
||||
**Format:** Theorie + viele Hands-On-Übungen
|
||||
1. Geschichte, Grundlagen & **HTML**
|
||||
2. Netzwerke, Protokolle, **semantisches HTML** & **CSS**
|
||||
3. Interaktivität, Animationen & **JavaScript**
|
||||
|
||||
**Ziel:** "Gelernte Hilflosigkeit" ablegen
|
||||
|
||||
@@ -148,8 +142,15 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 1: Die Geschichte
|
||||
## Von der Geburtsstunde des erten Computer-Algorithmus bis zur Vernetzung des gesamten Globus
|
||||
# Kapitel 1
|
||||
## Geschichte, Grundlagen & HTML
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Die Geschichte des Computers
|
||||
## Vom ersten Algorithmus bis zum globalen Netzwerk
|
||||
|
||||
---
|
||||
|
||||
@@ -171,14 +172,13 @@ Antoine Claudet
|
||||
|
||||
**Die erste Programmiererin der Welt**
|
||||
|
||||
- Arbeitete mit **Charles Babbage** an der "Analytical Engine"
|
||||
- Ihre »Notes« zu Babbages Maschine: **umfangreicher als sein Text**
|
||||
- 1843 publiziert – unter Initialen »A.A.L.« Ada Augusta Lovelace
|
||||
- Erst **1953** wiederentdeckt und gewürdigt
|
||||
- Schrieb **1843** den ersten Algorithmus für eine Maschine, die nie fertiggestellt wurde
|
||||
- Erste Programmiererin – 100 Jahre vor dem ersten Computer
|
||||
- Zusammenarbeit mit Charles Babbage an der *Analytical Engine*
|
||||
- Ihre Notizen: umfangreicher als sein Originaltext
|
||||
- Erst 1953 wiederentdeckt und gewürdigt
|
||||
|
||||
<!--
|
||||
Babbage: Mathematiker, besessen von Rechenmaschinen. Erst die Difference Engine, dann die Analytical Engine – nie fertig gebaut, aber revolutionär im Konzept.
|
||||
Babbage: Mathematiker, besessen von Rechenmaschinen. Erste Maschine: Difference Engine (reine Rechenmaschine). Zweite Maschine: Analytical Engine – programmierbar, mit Lochkarten gesteuert. Nie fertig gebaut, aber revolutionär im Konzept.
|
||||
|
||||
Ada: Tochter von Lord Byron, dem Dichter. Die Mutter – selbst Mathematikerin – hatte Angst, Ada könnte den "Wahnsinn" des Vaters erben. Also: strikte naturwissenschaftliche Erziehung. Weg von der Poesie, hin zur Logik.
|
||||
|
||||
@@ -208,19 +208,25 @@ Herman Hollerith, ca. 1890
|
||||
|
||||
# Herman Hollerith (1860–1929)
|
||||
|
||||
**Das Problem:** US-Volkszählung 1880 dauerte **7 Jahre** zur Auswertung
|
||||
**Erfinder der Lochkarten-Datenverarbeitung**
|
||||
|
||||
**Die Lösung:** Lochkarten + elektromechanische Tabelliermaschine
|
||||
|
||||
**1890 Census:** 62 Millionen Menschen in **2,5 Jahren** gezählt
|
||||
|
||||
**Ersparnis:** 5 Millionen Dollar (damals!)
|
||||
- **Problem:** Volkszählung 1880 brauchte 7 Jahre zur Auswertung
|
||||
- **Lösung:** Lochkarten + elektromechanische Tabelliermaschine
|
||||
- **Ergebnis:** 1890 Census in 2,5 Jahren – 5 Mio. Dollar gespart
|
||||
- Gründete Firma, die später zu IBM wurde
|
||||
|
||||
<!--
|
||||
Hollerith: Deutsch-amerikanischer Ingenieur
|
||||
Inspiration: Jacquard-Webstuhl (Lochkarten für Muster)
|
||||
Lochkarte = erstes standardisiertes Datenformat
|
||||
Eine Karte = ein Datensatz (eine Person)
|
||||
Hollerith: Deutsch-amerikanischer Ingenieur, Statistiker am US Census Bureau.
|
||||
|
||||
Das Problem: Die USA wuchsen so schnell, dass die Volkszählung von 1880 erst 1887 fertig ausgewertet war – die nächste Zählung stand schon bevor.
|
||||
|
||||
Inspiration: Jacquard-Webstuhl. Dieser französische Webstuhl nutzte seit 1804 Lochkarten zur Steuerung komplexer Muster. Hollerith übertrug das Prinzip auf Daten.
|
||||
|
||||
Seine Innovation: Eine Lochkarte = ein Datensatz (eine Person). Die Position der Löcher codierte Informationen (Alter, Geschlecht, Beruf etc.). Elektromechanische Maschine las die Karten und zählte automatisch.
|
||||
|
||||
1896 gründete er die Tabulating Machine Company. Nach mehreren Fusionen entstand daraus 1924 IBM – International Business Machines.
|
||||
|
||||
Die Lochkarte blieb bis in die 1970er das Standardformat für Dateneingabe.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -240,6 +246,17 @@ US Census Bureau
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
Hollerith-Lochkartenmaschine
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
@@ -251,19 +268,23 @@ US Census Bureau
|
||||
|
||||
# Die Geburt von IBM
|
||||
|
||||
**1896:** Hollerith gründet "Tabulating Machine Company"
|
||||
**Vom Einmannbetrieb zum Technologieriesen**
|
||||
|
||||
**1911:** Fusion → "Computing-Tabulating-Recording Company" (CTR)
|
||||
|
||||
**1924:** Umbenennung in **International Business Machines (IBM)**
|
||||
|
||||
IBM dominiert die nächsten 50 Jahre die Computerwelt.
|
||||
- 1896: Hollerith gründet *Tabulating Machine Company*
|
||||
- 1911: Fusion zur *Computing-Tabulating-Recording Company* (CTR)
|
||||
- 1924: Umbenennung in **International Business Machines (IBM)**
|
||||
- Dominiert die nächsten 50 Jahre die Computerwelt
|
||||
|
||||
<!--
|
||||
Thomas J. Watson Sr. → "THINK"-Motto
|
||||
IBM = "Big Blue"
|
||||
Lochkarten = Standard bis in die 1970er
|
||||
Heute: IBM als Cloud- und AI-Unternehmen (Watson, Red Hat)
|
||||
Thomas J. Watson Sr. übernahm 1914 die Führung und prägte IBM entscheidend. Sein Motto: "THINK" – stand auf Schildern in jedem IBM-Büro.
|
||||
|
||||
Warum "Big Blue"? IBMs Firmenfarbe war dunkelblau, ihre Großrechner hatten blaue Gehäuse. Der Spitzname entstand in den 1960ern.
|
||||
|
||||
Geschäftsmodell: IBM verkaufte nicht nur Maschinen, sondern vermietete sie – inklusive Wartung. Kunden waren abhängig. Ein frühes "Software-as-a-Service"-Modell.
|
||||
|
||||
Lochkarten blieben Standard bis in die 1970er. Die 80-Spalten-Karte prägte sogar frühe Bildschirmbreiten (80 Zeichen).
|
||||
|
||||
Heute: IBM hat sich neu erfunden – Cloud-Computing, KI (Watson), und 2019 Übernahme von Red Hat für 34 Milliarden Dollar.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -284,39 +305,23 @@ Dehomag = Deutsche Hollerith-Maschinen GmbH (IBM-Tochter)
|
||||
|
||||
# IBM und NS-Deutschland
|
||||
|
||||
**Dehomag** = Deutsche Hollerith-Maschinen GmbH (IBM-Tochter)
|
||||
**Technologie im Dienst des Terrors**
|
||||
|
||||
**Einsatz:**
|
||||
- Volkszählung 1933 (Identifikation von Juden)
|
||||
- **Dehomag:** Deutsche Hollerith-Maschinen GmbH (IBM-Tochter)
|
||||
- Volkszählung 1933: Identifikation von Juden
|
||||
- Verwaltung der Konzentrationslager
|
||||
- Logistik der Deportationen
|
||||
|
||||
**Edwin Black:** *"IBM and the Holocaust"* (2001)
|
||||
→ Edwin Black: *"IBM and the Holocaust"* (2001)
|
||||
|
||||
<!--
|
||||
Kontroverse Geschichte
|
||||
IBM profitierte, lieferte Maschinen, wartete sie
|
||||
"Technologie ist neutral" – wirklich?
|
||||
Wichtige Lektion für MedienethikerInnen
|
||||
-->
|
||||
Die Volkszählung 1933 fragte erstmals systematisch nach "Rasse" und Religion. Lochkarten ermöglichten die schnelle Auswertung – wer war Jude, wer Halbjude, wer mit wem verheiratet?
|
||||
|
||||
---
|
||||
Dehomag war IBMs profitabelste Auslandstochter. IBM lieferte nicht nur Maschinen, sondern auch maßgeschneiderte Lochkarten und Wartung. Die Maschinen in den KZs trugen IBM-Seriennummern.
|
||||
|
||||
# Lektionen für heute
|
||||
Edwin Blacks Buch basiert auf tausenden Dokumenten. IBM bestritt die Vorwürfe, zahlte aber 2001 Entschädigungen an Holocaust-Überlebende.
|
||||
|
||||
* Technologie ist nie neutral
|
||||
|
||||
|
||||
<!--
|
||||
* **2025:**
|
||||
* Big Data
|
||||
* Generative KI
|
||||
* Social Media
|
||||
* Rasterfahndung ([https://netzpolitik.org/](https://netzpolitik.org/2025/stuttgart-buendnis-plant-demonstration-gegen-palantir-einsatz/))
|
||||
|
||||
Facebook, Cambridge Analytica, Oracle Blue Kai
|
||||
Gesichtserkennung, Überwachung, Social Credit System (China)
|
||||
Verantwortung von TechnikerInnen und MedienarbeiterInnen
|
||||
Die Frage für MedienarbeiterInnen: Hätte IBM "Nein" sagen können? Sollen? Müssen? Technologie ist nie neutral – sie wird von Menschen für Zwecke eingesetzt.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -342,17 +347,24 @@ Bletchley Park
|
||||
|
||||
# Alan Turing (1912–1954)
|
||||
|
||||
**Vater der theoretischen Informatik**
|
||||
**Begründer der theoretischen Informatik**
|
||||
|
||||
- 1936: **Turing-Maschine** – theoretisches Modell eines Computers
|
||||
- 1939–1945: **Bletchley Park** – Enigma-Entschlüsselung
|
||||
- 1950: "Computing Machinery and Intelligence" → **Turing-Test**
|
||||
- **2013:** Posthume königliche Begnadigung
|
||||
- 1936: Turing-Maschine – definiert, was Computer können (und was nicht)
|
||||
- 1940er: Enigma-Entschlüsselung mit elektromechanischen Maschinen
|
||||
- 1950: Turing-Test – erste formale Definition von "Künstlicher Intelligenz"
|
||||
|
||||
<!--
|
||||
Genialer Mathematiker und Logiker
|
||||
Rettete vermutlich Millionen Leben durch Enigma-Arbeit
|
||||
Erst 2009 offizielle Entschuldigung der brit. Regierung
|
||||
Alan Turing war seiner Zeit Jahrzehnte voraus. Mit 24 Jahren definierte er, was "Berechnung" mathematisch bedeutet – bevor es echte Computer gab.
|
||||
|
||||
Bletchley Park: Geheimes Entschlüsselungszentrum 80 km nördlich von London. 10.000 Menschen arbeiteten dort, darunter viele Frauen. Streng geheim bis in die 1970er.
|
||||
|
||||
Seine Arbeit verkürzte den Krieg um geschätzte 2-4 Jahre und rettete Millionen Leben. Aber er durfte nie darüber sprechen.
|
||||
|
||||
1952 wurde Turing wegen Homosexualität verurteilt – damals illegal in Großbritannien. Er wurde chemisch kastriert. 1954 starb er an Zyanidvergiftung, vermutlich Suizid. Er war 41.
|
||||
|
||||
2009: Offizielle Entschuldigung von Premierminister Gordon Brown.
|
||||
2013: Königliche Begnadigung durch Queen Elizabeth II.
|
||||
2021: 50-Pfund-Schein mit Turings Porträt.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -360,88 +372,36 @@ Erst 2009 offizielle Entschuldigung der brit. Regierung
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||

|
||||
|
||||
<!--
|
||||
Bletchley Park, England
|
||||
Geheimes Entschlüsselungszentrum im WWII
|
||||
Der Turing-Test (1950): Ein Interrogator kommuniziert per Text mit einem Menschen und einer Maschine. Kann er nicht zuverlässig unterscheiden, wer wer ist, besteht die Maschine den Test.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Enigma & Bletchley Park
|
||||
|
||||
**Das Problem:** Deutsche Enigma-Maschine erzeugte 158 Trillionen mögliche Einstellungen
|
||||
|
||||
**Turings Lösung:** "Bombe" Elektro-mechanischer Entschlüssler
|
||||
|
||||
**Ergebnis:**
|
||||
- Alliierten konnten deutschen Funkverkehr mitlesen
|
||||
|
||||
**Geheim bis 1970er!** Turing starb ohne Anerkennung.
|
||||
|
||||
<!--
|
||||
Enigma: Elektrische Rotor-Chiffriermaschine
|
||||
Täglich neue Einstellungen
|
||||
Bombe: Vorläufer moderner Computer
|
||||
Parallelisierte Berechnung
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Die Turing-Maschine (1936)
|
||||
|
||||
**Theoretisches Modell eines Computers:**
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ ... │ 0 │ 1 │ 1 │ 0 │ 1 │ 0 │ ... │ ← Unendliches Band
|
||||
└─────────────────────────────────────────┘
|
||||
↑
|
||||
┌─────────────┐
|
||||
│ Lese-/ │
|
||||
│ Schreibkopf │
|
||||
└─────────────┘
|
||||
↓
|
||||
┌─────────────┐
|
||||
│ Zustand │ ← Endliche Zustände
|
||||
└─────────────┘
|
||||
```
|
||||
|
||||
**Beweis:** Alles Berechenbare kann so berechnet werden!
|
||||
→ Grundlage für **alle** modernen Computer
|
||||
|
||||
<!--
|
||||
Abstraktes Gedankenmodell
|
||||
Kein echter Bau nötig
|
||||
Church-Turing-These
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
---
|
||||
|
||||
# Das Manhattan-Projekt (1942–1945)
|
||||
|
||||
**Ziel:** Bau der ersten Atombombe
|
||||
**Problem:** Millionen von Berechnungen nötig für:
|
||||
- Ballistik-Berechnungen
|
||||
- Implosions-Simulationen
|
||||
- Nuklearphysik-Gleichungen
|
||||
|
||||
**Problem:** Berechnung von Implosionswellen
|
||||
→ Millionen von Berechnungen nötig
|
||||
**Lösung 1943:** Menschliche "Computer"
|
||||
→ Mathematikerinnen mit Taschenrechnern & IBM-Lochkarten
|
||||
|
||||
**Team:**
|
||||
- J. Robert Oppenheimer (Leitung)
|
||||
- Richard Feynman (Rechenabteilung)
|
||||
- **John von Neumann** (Mathematik & Stoßwellen)
|
||||
**Zu langsam** → Bedarf an automatischer Berechnung
|
||||
|
||||
**Schlüsselfigur:** John von Neumann (Mathematik & Stoßwellen)
|
||||
|
||||
<!--
|
||||
Los Alamos, New Mexico
|
||||
Geheimes Labor, beste WissenschaftlerInnen der Welt
|
||||
Von Neumann kam 1943 als Berater
|
||||
Los Alamos, New Mexico – geheimes Labor, beste WissenschaftlerInnen der Welt.
|
||||
|
||||
"Computer" war ein Job-Titel! Meist Mathematikerinnen. Richard Feynman leitete eine Abteilung davon.
|
||||
|
||||
Von Neumann kam 1943 als Berater. Seine mathematischen Fähigkeiten waren legendär.
|
||||
|
||||
Das ENIAC-Projekt in Philadelphia sollte die Berechnungen beschleunigen.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -468,27 +428,6 @@ Arbeitete am Manhattan-Projekt mit
|
||||
|
||||
---
|
||||
|
||||
# Das Problem der Berechnung
|
||||
|
||||
**Manhattan-Projekt brauchte:**
|
||||
- Ballistik-Berechnungen
|
||||
- Implosions-Simulationen
|
||||
- Nuklearphysik-Gleichungen
|
||||
|
||||
**Lösung 1943:** Menschliche "Computer"
|
||||
→ Mit Taschenrechnern, Tabellen, IBM-Lochkarten
|
||||
|
||||
**Zu langsam** → Bedarf an automatischer Berechnung
|
||||
|
||||
<!--
|
||||
"Computer" war ein Job-Titel!
|
||||
Meist Mathematikerinnen
|
||||
Feynman leitete eine Abteilung davon
|
||||
ENIAC-Projekt in Philadelphia sollte helfen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
@@ -522,6 +461,96 @@ Programmiert durch 6 Frauen (ENIAC Girls)
|
||||
|
||||
---
|
||||
|
||||
# Von-Neumann-Architektur (1945)
|
||||
|
||||
**Die zentrale Idee: Programme und Daten im selben Speicher**
|
||||
|
||||
**Vorher (z.B. ENIAC):** Programme durch Umstecken von Kabeln
|
||||
→ Tagelange Arbeit für jedes neue Problem
|
||||
|
||||
**Nachher:** Programme als austauschbare Daten im Speicher
|
||||
→ Grundlage aller Computer: Laptop, Smartphone, Server
|
||||
|
||||
<!--
|
||||
John von Neumann beschrieb 1945 das Prinzip im "First Draft of a Report on the EDVAC".
|
||||
|
||||
Vorher (ENIAC): Programme durch Umstecken von Kabeln – tagelange Arbeit für jedes neue Problem. Nachher: Programme als Daten im Speicher – austauschbar in Sekunden.
|
||||
|
||||
Das Revolutionäre: Programme liegen im selben Speicher wie Daten. Das klingt selbstverständlich, war aber ein Paradigmenwechsel. Vorher war ein Computer eine Maschine für genau ein Problem.
|
||||
|
||||
Der "Von-Neumann-Flaschenhals": CPU und Speicher teilen sich einen Bus – die Bandbreite begrenzt die Geschwindigkeit. Moderne CPUs umgehen das mit Caches (L1/L2/L3).
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Von-Neumann: 5 Komponenten
|
||||
|
||||
| Komponente | Funktion |
|
||||
|------------|----------|
|
||||
| **Rechenwerk (ALU)** | Führt Berechnungen durch |
|
||||
| **Steuerwerk** | Interpretiert Befehle, steuert Ablauf |
|
||||
| **Speicherwerk** | Speichert Programme UND Daten |
|
||||
| **Ein-/Ausgabe** | Tastatur, Bildschirm, Netzwerk |
|
||||
| **Bus-System** | Verbindet alle Komponenten |
|
||||
|
||||
<!--
|
||||
VON-NEUMANN-ARCHITEKTUR (1945): Grundlage aller modernen Computer
|
||||
5 KOMPONENTEN:
|
||||
- ALU (Arithmetic Logic Unit): Rechnet (+, -, ×, ÷) und vergleicht (>, <, =)
|
||||
- Steuerwerk: Holt Befehle, dekodiert sie, steuert Ausführung (Fetch-Decode-Execute)
|
||||
- Speicherwerk: RAM (flüchtig) + ROM (permanent), enthält Code UND Daten
|
||||
- Ein-/Ausgabe (I/O): Tastatur, Maus, Bildschirm, Netzwerk, USB, Sensoren
|
||||
- Bus-System: Adressbus (wo), Datenbus (was), Steuerbus (wie)
|
||||
KERNPRINZIP: Stored Program Concept - Programme im selben Speicher wie Daten
|
||||
VORHER (z.B. ENIAC): Programme durch Umstecken von Kabeln, tagelange Arbeit
|
||||
NACHHER: Programme als austauschbare Daten → Flexibilität, Software-Industrie möglich
|
||||
PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program Concept
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Von-Neumann-Architektur: Bedeutung
|
||||
|
||||
**Ohne Von-Neumann-Architektur:**
|
||||
- Kein Betriebssystem
|
||||
- Keine Apps
|
||||
- Kein Multitasking
|
||||
- Keine Updates bzw. Veränderungen am Computer System
|
||||
|
||||
**Die meisten Computer** basieren auf diesem Prinzip:
|
||||
Laptop, Smartphone, Server, Spielkonsole...
|
||||
|
||||
**Ausnahme:** Mikrocontroller & DSPs nutzen oft die **Harvard-Architektur**
|
||||
(separate Speicher für Code und Daten → schneller für Echtzeitanwendungen)
|
||||
|
||||
<!--
|
||||
BEDEUTUNG VON-NEUMANN-ARCHITEKTUR:
|
||||
- Betriebssystem möglich: Lädt verschiedene Programme aus gleichem Speicher
|
||||
- Apps installierbar: Können gelöscht/installiert werden ohne Hardware-Änderung
|
||||
- Multitasking: Mehrere Programme gleichzeitig im Speicher
|
||||
- Updates: Software austauschbar, Hardware bleibt gleich
|
||||
- Universalrechner: Gleiche Hardware für Text, Spiele, Video, Wissenschaft
|
||||
HARVARD-ARCHITEKTUR (Alternative):
|
||||
- Separate Speicher für Code und Daten
|
||||
- Vorteil: Schneller (paralleler Zugriff), sicherer (Code nicht überschreibbar)
|
||||
- Nachteil: Weniger flexibel, aufwändiger
|
||||
- Anwendung: Mikrocontroller (Arduino, ESP32), DSPs, einige ARM-Chips
|
||||
MODERNE CPUs: Modified Harvard (L1-Cache getrennt für Speed, RAM gemeinsam für Flexibilität)
|
||||
PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beispiele
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -601,137 +630,40 @@ Die Software priorisierte kritische Aufgaben automatisch
|
||||
|
||||
---
|
||||
|
||||
# Von Neumanns Idee (1945)
|
||||
# Lektionen für heute
|
||||
|
||||
**"First Draft of a Report on the EDVAC"**
|
||||
**Technologie ist nie neutral**
|
||||
|
||||
**Kernidee:** Programm und Daten im **selben Speicher**
|
||||
- Big Data ermöglicht Massenüberwachung
|
||||
- KI-Systeme übernehmen Entscheidungen über Menschen
|
||||
- Social Media schädigt die psychische Gesundheit Minderjähriger
|
||||
- PimEyes: RAF-Terroristin in 30 Minuten gefunden – Polizei brauchte 30 Jahre
|
||||
|
||||
**Vorher:** Hardware = Programm (Umstecken)
|
||||
**Nachher:** Software = austauschbar (laden)
|
||||
|
||||
→ **Gespeichertes Programm** = Revolution
|
||||
→ Verantwortung liegt bei denen, die Technologie bauen und einsetzen
|
||||
|
||||
<!--
|
||||
EDVAC = Electronic Discrete Variable Automatic Computer
|
||||
Nachfolger von ENIAC
|
||||
Von Neumann schrieb den Bericht
|
||||
Daher: "Von-Neumann-Architektur"
|
||||
-->
|
||||
Aktuelle Beispiele (in Reihenfolge der Folie):
|
||||
|
||||
---
|
||||
1. Big Data / Palantir: US-Firma liefert Überwachungssoftware an Polizei und Geheimdienste. In Deutschland nutzen es bereits Hessen, NRW, Bayern und Baden-Württemberg. Kritiker warnen vor "Rasterfahndung auf Knopfdruck".
|
||||
Quellen: https://www.zdfheute.de/politik/deutschland/palantir-einsatz-polizei-deutschland-alternative-100.html
|
||||
https://www.heise.de/en/news/Baden-Wuerttemberg-decides-on-the-use-of-Palantir-11075477.html
|
||||
|
||||
# Von-Neumann-Architektur
|
||||
2. KI-Systeme: Algorithmen entscheiden über Kreditvergabe, Bewerbungen, Sozialleistungen. Oft intransparent, oft diskriminierend. Beispiel: Niederlande "Toeslagenaffaire" – Steuerbehörde nutzte Algorithmus, der Familien mit Migrationshintergrund systematisch als Betrüger einstufte. Regierung Rutte trat 2021 zurück.
|
||||
Quelle: https://netzpolitik.org/2021/kindergeldaffaere-niederlande-zahlen-millionenstrafe-wegen-datendiskriminierung/
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ CPU │
|
||||
│ ┌─────────────┐ ┌─────────────────┐ │
|
||||
│ │ Rechenwerk │ │ Steuerwerk │ │
|
||||
│ │ (ALU) │ │ (Control Unit) │ │
|
||||
│ └─────────────┘ └─────────────────┘ │
|
||||
└─────────────────────────────────────────┘
|
||||
↕ Bus-System ↕
|
||||
┌─────────────────┐ ┌──────────────────┐
|
||||
│ Speicherwerk │ │ Ein-/Ausgabewerk │
|
||||
│ (Memory) │ │ (I/O) │
|
||||
└─────────────────┘ └──────────────────┘
|
||||
```
|
||||
3. Social Media: 2026 verloren Meta und Google einen Prozess in Kalifornien – ihre Plattformen schädigen nachweislich die psychische Gesundheit Minderjähriger.
|
||||
Quelle: https://www.latimes.com/california/story/2026-03-25/social-media-lawsuit-trial-meta-google-verdict
|
||||
|
||||
<!--
|
||||
5 Grundkomponenten
|
||||
JEDER Computer folgt diesem Prinzip
|
||||
Euer Laptop, euer Handy, der Server dieser Präsentation
|
||||
-->
|
||||
4. PimEyes/Clearview: Gesichtserkennungsdienste mit Milliarden Fotos aus dem Internet. Februar 2024: Ein Journalist fand RAF-Terroristin Daniela Klette in 30 Minuten – die Polizei hatte 30 Jahre gesucht. Beide Dienste gelten in der EU als illegal.
|
||||
Quelle: https://netzpolitik.org/2024/nancy-faeser-was-das-innenministerium-zur-gesichtserkennung-plant/
|
||||
|
||||
---
|
||||
Weitere Beispiele:
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
Cambridge Analytica (2018): Facebook-Daten von 87 Mio. Nutzern wurden für politische Werbung genutzt. Ob das tatsächlich Wahlen beeinflusst hat, ist umstritten – die Firmen behaupten es gerne, Belege fehlen.
|
||||
|
||||
# Die 5 Komponenten
|
||||
China Social Credit System: Punktesystem für "gutes Verhalten". Wer zu oft bei Rot geht, bekommt keinen Kredit mehr.
|
||||
|
||||
| Komponente | Funktion |
|
||||
|------------|----------|
|
||||
| **Rechenwerk (ALU)** | Führt Berechnungen durch |
|
||||
| **Steuerwerk** | Interpretiert Befehle, steuert Ablauf |
|
||||
| **Speicherwerk** | Speichert Programme UND Daten |
|
||||
| **Ein-/Ausgabe** | Tastatur, Bildschirm, Netzwerk |
|
||||
| **Bus-System** | Verbindet alle Komponenten |
|
||||
|
||||
**Wichtig:** Programme und Daten **gemeinsam** im Speicher!
|
||||
|
||||
<!--
|
||||
VON-NEUMANN-ARCHITEKTUR (1945): Grundlage aller modernen Computer
|
||||
5 KOMPONENTEN:
|
||||
- ALU (Arithmetic Logic Unit): Rechnet (+, -, ×, ÷) und vergleicht (>, <, =)
|
||||
- Steuerwerk: Holt Befehle, dekodiert sie, steuert Ausführung (Fetch-Decode-Execute)
|
||||
- Speicherwerk: RAM (flüchtig) + ROM (permanent), enthält Code UND Daten
|
||||
- Ein-/Ausgabe (I/O): Tastatur, Maus, Bildschirm, Netzwerk, USB, Sensoren
|
||||
- Bus-System: Adressbus (wo), Datenbus (was), Steuerbus (wie)
|
||||
KERNPRINZIP: Stored Program Concept - Programme im selben Speicher wie Daten
|
||||
VORHER (z.B. ENIAC): Programme durch Umstecken von Kabeln, tagelange Arbeit
|
||||
NACHHER: Programme als austauschbare Daten → Flexibilität, Software-Industrie möglich
|
||||
PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program Concept
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Die 5 Komponenten: Erklaerung
|
||||
|
||||
**Definition:** Die Von-Neumann-Architektur beschreibt den grundlegenden Aufbau moderner Computer in fuenf Funktionseinheiten.
|
||||
|
||||
| Komponente | Aufgabe | Beispiel |
|
||||
|------------|---------|----------|
|
||||
| **Rechenwerk (ALU)** | Arithmetische & logische Operationen | +, -, ×, ÷, Vergleiche |
|
||||
| **Steuerwerk** | Holt, dekodiert und steuert Befehle | Fetch-Decode-Execute-Zyklus |
|
||||
| **Speicherwerk** | Speichert Programme UND Daten | RAM, ROM |
|
||||
| **Ein-/Ausgabe** | Kommunikation mit Aussenwelt | Tastatur, Monitor, USB |
|
||||
| **Bus-System** | Verbindet alle Komponenten | Adress-, Daten-, Steuerbus |
|
||||
|
||||
**Merkhilfe:** "**R**echnen, **S**teuern, **S**peichern, **E**in/**A**us, **B**us" (RSSEAB)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Von-Neumann-Architektur: Bedeutung
|
||||
|
||||
**Ohne Von-Neumann-Architektur:**
|
||||
- Kein Betriebssystem
|
||||
- Keine Apps
|
||||
- Kein Multitasking
|
||||
- Keine Updates bzw. Veränderungen am Computer System
|
||||
|
||||
**Die meisten Computer** basieren auf diesem Prinzip:
|
||||
Laptop, Smartphone, Server, Spielkonsole...
|
||||
|
||||
**Ausnahme:** Mikrocontroller & DSPs nutzen oft die **Harvard-Architektur**
|
||||
(separate Speicher für Code und Daten → schneller für Echtzeitanwendungen)
|
||||
|
||||
<!--
|
||||
BEDEUTUNG VON-NEUMANN-ARCHITEKTUR:
|
||||
- Betriebssystem möglich: Lädt verschiedene Programme aus gleichem Speicher
|
||||
- Apps installierbar: Können gelöscht/installiert werden ohne Hardware-Änderung
|
||||
- Multitasking: Mehrere Programme gleichzeitig im Speicher
|
||||
- Updates: Software austauschbar, Hardware bleibt gleich
|
||||
- Universalrechner: Gleiche Hardware für Text, Spiele, Video, Wissenschaft
|
||||
HARVARD-ARCHITEKTUR (Alternative):
|
||||
- Separate Speicher für Code und Daten
|
||||
- Vorteil: Schneller (paralleler Zugriff), sicherer (Code nicht überschreibbar)
|
||||
- Nachteil: Weniger flexibel, aufwändiger
|
||||
- Anwendung: Mikrocontroller (Arduino, ESP32), DSPs, einige ARM-Chips
|
||||
MODERNE CPUs: Modified Harvard (L1-Cache getrennt für Speed, RAM gemeinsam für Flexibilität)
|
||||
PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beispiele
|
||||
Die Frage: Wer entscheidet, was mit Technologie gemacht wird? Die Entwickler? Die Firmen? Die Politik? Wir alle?
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -764,19 +696,29 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
|
||||
|
||||
---
|
||||
|
||||
# Das Problem (1960er)
|
||||
# Kalter Krieg: Das Problem der Kommunikation
|
||||
|
||||
**Kalter Krieg:**
|
||||
- Was passiert bei einem Nuklearangriff?
|
||||
- Zentrale Kommunikation → ein Treffer = alles tot
|
||||
**1957:** Sputnik-Schock → USA investiert massiv in Forschung
|
||||
→ **ARPA** (Advanced Research Projects Agency) wird gegründet
|
||||
|
||||
**DARPA** (Defense Advanced Research Projects Agency):
|
||||
→ Dezentrales Netzwerk, das Angriffe überlebt
|
||||
**Das Problem:** Zentrale Netzwerke sind verwundbar
|
||||
→ Ein Treffer = gesamte Kommunikation tot
|
||||
|
||||
**Die Idee (Paul Baran, 1964):** Packet Switching
|
||||
→ Nachrichten in kleine Pakete aufteilen
|
||||
→ Jedes Paket findet seinen eigenen Weg
|
||||
→ Kein einzelner Punkt kann das Netz zerstören
|
||||
|
||||
<!--
|
||||
ARPA (später DARPA) = Pentagon-Forschung
|
||||
Sputnik-Schock 1957 → USA investiert in Forschung
|
||||
Paul Baran (RAND Corp): Packet Switching
|
||||
Sputnik-Schock (4. Oktober 1957): Die Sowjetunion schießt den ersten künstlichen Satelliten ins All – "Sputnik 1". Die USA sind schockiert: Wenn die Sowjets Satelliten in den Orbit bringen können, können sie auch Atomwaffen über Kontinente schießen. Die gefühlte technologische Überlegenheit der USA ist über Nacht zerstört.
|
||||
|
||||
Reaktion: Präsident Eisenhower gründet 1958 ARPA (Advanced Research Projects Agency) im Pentagon. Auftrag: Die USA sollen nie wieder technologisch überrascht werden. ARPA finanziert Grundlagenforschung an Universitäten – daraus entsteht später das Internet.
|
||||
|
||||
Paul Baran (RAND Corporation, 1964): Entwickelt das Konzept des "Packet Switching". Statt einer durchgehenden Verbindung (wie beim Telefon) werden Nachrichten in kleine Pakete zerlegt. Jedes Paket wird unabhängig durchs Netz geroutet. Fällt ein Knoten aus, finden die Pakete einen anderen Weg. Das macht das Netz resilient gegen Angriffe.
|
||||
|
||||
Parallel und unabhängig: Donald Davies am britischen National Physical Laboratory entwickelt dasselbe Konzept und prägt den Begriff "Packet Switching".
|
||||
|
||||
ARPA wird später zu DARPA (Defense Advanced Research Projects Agency) umbenannt.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -847,6 +789,18 @@ Kostenlos freigegeben → darum existiert es
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
Unterseekabel-Karte: Über 400 Kabel verbinden die Kontinente.
|
||||
Quelle: TeleGeography Submarine Cable Map
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 1,3 Millionen Kilometer Unterseekabel
|
||||
|
||||
**Heute:**
|
||||
@@ -855,19 +809,28 @@ Kostenlos freigegeben → darum existiert es
|
||||
- **>400** Unterseekabel weltweit
|
||||
- Daten reisen mit **Lichtgeschwindigkeit** (Glasfaser)
|
||||
|
||||
**Das Internet ist physisch!** Keine "Cloud" ohne Kabel.
|
||||
Keine "Cloud" ohne Kabel – das Internet ist physische Infrastruktur.
|
||||
|
||||
**Five Eyes** (USA, UK, Kanada, Australien, Neuseeland):
|
||||
→ Zapfen Unterseekabel an – globale Massenüberwachung
|
||||
|
||||
<!--
|
||||
Google, Meta, Microsoft besitzen eigene Kabel
|
||||
Sabotage-Risiko (Russland, Anker)
|
||||
Latenz: Frankfurt → New York = ~80ms
|
||||
|
||||
Five Eyes: Geheimdienstallianz aus dem Zweiten Weltkrieg (UKUSA-Abkommen, 1946). Die fünf Länder teilen systematisch Überwachungsdaten. 2013 durch Edward Snowden enthüllt: NSA und GCHQ zapfen Unterseekabel direkt an (Programm "Tempora" des GCHQ, "Upstream" der NSA). Über diese Kabel läuft fast der gesamte internationale Internetverkehr – wer sie anzapft, kann potenziell alles mitlesen.
|
||||
|
||||
Erweiterte Allianzen: Nine Eyes (+Dänemark, Frankreich, Niederlande, Norwegen), Fourteen Eyes (+Deutschland, Belgien, Italien, Spanien, Schweden).
|
||||
|
||||
Deutschland ist also kein Five-Eyes-Mitglied, aber Teil der Fourteen Eyes. Der BND kooperiert eng mit der NSA (Operation Eikonal: BND leitete Daten vom Frankfurter Internetknoten DE-CIX an die NSA weiter).
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 2: Bits & Bytes
|
||||
# Bits & Bytes
|
||||
## Die Sprache der Computer
|
||||
|
||||
---
|
||||
@@ -1013,9 +976,9 @@ Fehlercodes: Windows zeigt diese bei Bluescreens
|
||||
|
||||
| Einheit (Bit) | Einheit (Byte) |
|
||||
|---------------|----------------|
|
||||
| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte |
|
||||
| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte |
|
||||
| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte |
|
||||
| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte = 8.000 Bit |
|
||||
| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte = 8 Mbit |
|
||||
| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte = 8 Gbit |
|
||||
|
||||
**Praxis:** 100 Mbit/s Internet = **12,5 MB/s** Download
|
||||
|
||||
@@ -1030,35 +993,9 @@ Warum? Marketing - 100 klingt besser als 12,5
|
||||
|
||||
---
|
||||
|
||||
# Warum zeigt meine 1TB-Festplatte nur 931GB?
|
||||
|
||||
**Zwei Zählweisen:**
|
||||
|
||||
| Dezimal (Hersteller) | Binär (Computer) |
|
||||
|---------------------|------------------|
|
||||
| Kilo = 1.000 | Kibi = 1.024 (2¹⁰) |
|
||||
| Mega = 1.000.000 | Mebi = 1.048.576 (2²⁰) |
|
||||
| Giga = 1.000.000.000 | Gibi = 1.073.741.824 (2³⁰) |
|
||||
| Tera = 1.000.000.000.000 | Tebi = 1.099.511.627.776 (2⁴⁰) |
|
||||
|
||||
**Das Problem:**
|
||||
- Hersteller verkauft: 1 TB = 1.000.000.000.000 Bytes
|
||||
- Computer rechnet: 1 TiB = 1.099.511.627.776 Bytes
|
||||
- Differenz: **9,1%** → zeigt nur **931 GB**
|
||||
|
||||
<!--
|
||||
Dezimal: SI-System (Système International) - Basis 10
|
||||
Binär: IEC-Standard (International Electrotechnical Commission) - Basis 2
|
||||
Kibi/Mebi/Gibi = Kunstwörter für binäre Einheiten
|
||||
Hersteller nutzen Dezimal = klingt größer = Marketing
|
||||
Windows zeigt binär, schreibt aber "GB" statt "GiB"
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 3: Eure erste Webseite
|
||||
# Unsere erste Webseite
|
||||
## HTML-Grundlagen
|
||||
|
||||
---
|
||||
@@ -1189,23 +1126,27 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTML Metadaten: Erklaerung
|
||||
# HTML Metadaten – Vertiefung
|
||||
|
||||
**Definition:** Der `<head>`-Bereich enthaelt Informationen ueber das Dokument, die nicht direkt im Browser angezeigt werden.
|
||||
Der `<head>`-Bereich enthält Informationen *über* das Dokument, nicht den sichtbaren Inhalt. Diese Metadaten steuern Browser-Verhalten, Suchmaschinen-Indexierung und Social-Media-Vorschauen.
|
||||
|
||||
| Meta-Tag | Zweck | Beispiel |
|
||||
|----------|-------|----------|
|
||||
| `<title>` | Browser-Tab, Lesezeichen, SEO | "Meine Website" |
|
||||
| `<meta charset>` | Zeichenkodierung | UTF-8 fuer Umlaute |
|
||||
| `<meta description>` | Suchmaschinen-Snippet | Max. 160 Zeichen |
|
||||
| `<meta viewport>` | Mobile Darstellung | width=device-width |
|
||||
| `<meta og:image>` | Social Media Vorschau | Bild beim Teilen |
|
||||
**Kritische Meta-Tags:**
|
||||
|
||||
**Wichtige Unterscheidung:**
|
||||
- `<head>`: Metadaten (fuer Browser, Suchmaschinen, Social Media)
|
||||
- `<body>`: Sichtbarer Inhalt (fuer Menschen)
|
||||
| Tag | Funktion | Beispiel |
|
||||
|-----|----------|----------|
|
||||
| `<title>` | Browser-Tab, Suchergebnis-Titel | `<title>HdM Stuttgart</title>` |
|
||||
| `<meta charset>` | Zeichenkodierung (Umlaute!) | `<meta charset="UTF-8">` |
|
||||
| `<meta viewport>` | Mobile Darstellung | `width=device-width, initial-scale=1` |
|
||||
| `<meta description>` | Suchergebnis-Snippet (max 160 Zeichen) | SEO-kritisch |
|
||||
|
||||
**Merkhilfe:** "Head = Gehirn (unsichtbar), Body = Koerper (sichtbar)"
|
||||
**Open Graph Protocol (Facebook, 2010):**
|
||||
```html
|
||||
<meta property="og:title" content="Artikel-Titel">
|
||||
<meta property="og:image" content="https://example.com/preview.jpg">
|
||||
```
|
||||
Steuert die Vorschau beim Teilen auf Facebook, LinkedIn, WhatsApp, Slack.
|
||||
|
||||
**SEO-Relevanz:** Google nutzt `<title>` und `<meta description>` für Ranking und Snippet-Anzeige. Fehlende Metadaten = schlechtere Auffindbarkeit.
|
||||
|
||||
---
|
||||
|
||||
@@ -1436,22 +1377,26 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Web-Nutzung: Erklaerung
|
||||
# Web-Zugänglichkeit – Vertiefung
|
||||
|
||||
**Definition:** Menschen nutzen das Web auf sehr unterschiedliche Weisen - nicht nur mit Maus und Bildschirm.
|
||||
**a11y** = Accessibility (a + 11 Buchstaben + y). Die WHO schätzt, dass 15% der Weltbevölkerung eine Behinderung haben – das sind über 1 Milliarde potenzielle Nutzer.
|
||||
|
||||
**Eingabemethoden:**
|
||||
- **Maus/Trackpad:** Klicken, Scrollen, Hover
|
||||
- **Tastatur:** Tab-Navigation, Shortcuts, Pfeiltasten
|
||||
- **Screenreader:** Vorlesen von Inhalten (NVDA, VoiceOver, JAWS)
|
||||
- **Sprache/Augen:** Sprachbefehle, Eye-Tracking, Switch-Geraete
|
||||
**Arten von Einschränkungen:**
|
||||
|
||||
**Arten von Einschraenkungen:**
|
||||
- **Permanent:** Blindheit, Taubheit, motorische Einschraenkungen
|
||||
- **Temporaer:** Gebrochener Arm, Augen-OP
|
||||
- **Situativ:** Sonnenlicht, laute Umgebung, Baby auf Arm
|
||||
| Typ | Permanent | Temporär | Situativ |
|
||||
|-----|-----------|----------|----------|
|
||||
| Visuell | Blindheit | Nach Augen-OP | Grelle Sonne |
|
||||
| Motorisch | Amputation | Gebrochener Arm | Baby auf dem Arm |
|
||||
| Auditiv | Taubheit | Ohrenentzündung | Laute Umgebung |
|
||||
| Kognitiv | Legasthenie | Müdigkeit | Ablenkung |
|
||||
|
||||
**Merkhilfe:** "a11y" = a + 11 Buchstaben + y = "accessibility"
|
||||
**Assistive Technologien:**
|
||||
- **Screenreader:** NVDA (Windows, kostenlos), VoiceOver (Apple, integriert), JAWS (kommerziell)
|
||||
- **Braillezeilen:** Taktile Ausgabe, ~40–80 Zeichen
|
||||
- **Switch-Geräte:** Ein-Knopf-Steuerung für motorische Einschränkungen
|
||||
- **Eye-Tracking:** Blicksteuerung für Bewegungsunfähige
|
||||
|
||||
Screenreader lesen den DOM sequenziell – semantisches HTML (`<nav>`, `<main>`, `<button>`) ermöglicht Navigation per Tastenkürzel.
|
||||
|
||||
---
|
||||
|
||||
@@ -1498,21 +1443,28 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Barrierefreiheit: Erklaerung
|
||||
# Rechtliche Anforderungen – Vertiefung
|
||||
|
||||
**Definition:** Barrierefreiheit (Accessibility) bedeutet, dass digitale Inhalte fuer alle Menschen zugaenglich sind - unabhaengig von koerperlichen oder technischen Einschraenkungen.
|
||||
Der **European Accessibility Act (EAA)** trat am 28. Juni 2025 in Kraft und betrifft erstmals auch private Unternehmen – nicht nur öffentliche Stellen.
|
||||
|
||||
**Rechtlicher Rahmen:**
|
||||
- **European Accessibility Act (EAA):** Seit Juni 2025 EU-weit verpflichtend
|
||||
- **BITV 2.0:** Deutsche Verordnung fuer oeffentliche Stellen
|
||||
- **Strafen:** Bis zu 100.000 EUR Bussgeld moeglich
|
||||
**Betroffene Sektoren:**
|
||||
- E-Commerce (Online-Shops)
|
||||
- Bankdienstleistungen
|
||||
- Telekommunikation
|
||||
- E-Books und E-Reader
|
||||
- Ticketing und Check-in-Terminals
|
||||
|
||||
**Curb-Cut-Effekt:** Massnahmen fuer Menschen mit Behinderung helfen allen:
|
||||
- Untertitel → laute Umgebung, Sprachlernen
|
||||
- Kontrast → Sonnenlicht, aeltere Menschen
|
||||
- Tastatur-Navigation → Power-User, RSI-Betroffene
|
||||
**WCAG 2.2 – Konformitätsstufen:**
|
||||
|
||||
**Business Case:** ~15% Menschen mit Behinderung + ~20% Aeltere = 35% potenzielle Zielgruppe
|
||||
| Level | Anforderung | Beispiel |
|
||||
|-------|-------------|----------|
|
||||
| A | Minimum | Alt-Texte für Bilder |
|
||||
| AA | Gesetzlicher Standard | Kontrast 4,5:1, Tastaturnavigation |
|
||||
| AAA | Optimal | Gebärdensprache für Videos |
|
||||
|
||||
**Curb-Cut-Effekt:** Barrierefreiheit hilft allen. Bordsteinabsenkungen für Rollstühle nutzen auch Kinderwagen, Rollkoffer, Fahrräder. Untertitel helfen Gehörlosen, aber auch in lauten Umgebungen oder beim Sprachlernen.
|
||||
|
||||
**Sanktionen:** Bis zu 100.000 € Bußgeld bei Verstößen.
|
||||
|
||||
---
|
||||
|
||||
@@ -1673,25 +1625,31 @@ Echte NutzerInnen einbeziehen = Gold-Standard
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Barrieren vermeiden: Erklaerung
|
||||
# Barrierefreiheit testen – Vertiefung
|
||||
|
||||
**Definition:** Praktische Massnahmen zur Pruefung und Sicherstellung der Barrierefreiheit von Webseiten.
|
||||
Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erfordert manuelles Testen und idealerweise echte Nutzer mit Behinderungen.
|
||||
|
||||
**Tastatur-Test (selbst durchfuehren):**
|
||||
1. Tab druecken → Springt der Fokus logisch durch die Seite?
|
||||
2. Ist der fokussierte Bereich immer sichtbar markiert?
|
||||
3. Kann man alle Funktionen ohne Maus bedienen?
|
||||
**Tastatur-Test (5 Minuten, jeder kann's):**
|
||||
1. Maus weglegen, nur Tab + Enter + Pfeiltasten nutzen
|
||||
2. Fokus-Indikator immer sichtbar? (kein `outline: none;`!)
|
||||
3. Logische Reihenfolge? (nicht kreuz und quer)
|
||||
4. Alle interaktiven Elemente erreichbar?
|
||||
|
||||
**Screenreader-Test:**
|
||||
- **Mac:** VoiceOver aktivieren mit `Cmd + F5`
|
||||
- **Windows:** NVDA installieren (kostenlos)
|
||||
- **Frage:** Ergibt die vorgelesene Seite Sinn?
|
||||
**Automatisierte Tools:**
|
||||
|
||||
**Automatische Tools (finden ~30% der Probleme):**
|
||||
- axe DevTools, WAVE (Browser-Extensions)
|
||||
- Lighthouse (in Chrome DevTools unter F12)
|
||||
| Tool | Typ | Findet |
|
||||
|------|-----|--------|
|
||||
| axe DevTools | Browser-Extension | ~30% der WCAG-Verstöße |
|
||||
| WAVE | Browser-Extension | Struktur-Probleme, Kontrast |
|
||||
| Lighthouse | Chrome DevTools | Performance + Accessibility |
|
||||
| Pa11y | CLI | CI/CD-Integration |
|
||||
|
||||
**Merkhilfe WCAG-Prinzipien:** "**P**erceivable, **O**perable, **U**nderstandable, **R**obust" (POUR)
|
||||
**Screenreader-Kurztest:**
|
||||
- macOS: `Cmd + F5` (VoiceOver)
|
||||
- Windows: NVDA installieren (kostenlos)
|
||||
- Augen schließen, nur zuhören: Ist die Seite verständlich?
|
||||
|
||||
**Gold-Standard:** Usability-Tests mit Menschen, die Assistive Technologien täglich nutzen.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 2: Netzwerke, Protokolle & CSS"
|
||||
---
|
||||
|
||||
@@ -73,18 +73,23 @@ section.glossar {
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: linear-gradient(180deg, #fff8fa 0%, #fef0f4 100%) !important;
|
||||
border-left: 6px solid #a02060;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#fce4ec,
|
||||
#fce4ec 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.6rem;
|
||||
font-size: 1.5rem;
|
||||
color: #a02060;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
section.erklaerung h2 {
|
||||
font-size: 1.3rem;
|
||||
color: #1f2937;
|
||||
margin-top: 0;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
@@ -92,11 +97,11 @@ section.erklaerung ol {
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.5;
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.95rem;
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
@@ -113,7 +118,7 @@ section.erklaerung table {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
@@ -433,22 +438,24 @@ SPEAKER NOTES:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP/IP-Modell: Erklaerung
|
||||
# TCP/IP-Modell – Vertiefung
|
||||
|
||||
**Definition:** Das TCP/IP-Modell beschreibt die Kommunikation im Internet in vier hierarchischen Schichten.
|
||||
Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt.
|
||||
|
||||
| Schicht | Frage | Protokolle | Dateneinheit |
|
||||
|---------|-------|------------|--------------|
|
||||
| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP | Daten |
|
||||
| 3 Transport | Kommt es an? | TCP, UDP | Segment |
|
||||
| 2 Internet | Welcher Rechner? | IP | Paket |
|
||||
| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN | Frame |
|
||||
**Schicht-Aufgaben im Detail:**
|
||||
|
||||
**Kernprinzip:** Jede Schicht hat eine Aufgabe und kennt nur ihre Nachbarschichten.
|
||||
| Schicht | Frage | Protokolle | Geräte |
|
||||
|---------|-------|------------|--------|
|
||||
| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) |
|
||||
| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) |
|
||||
| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router |
|
||||
| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point |
|
||||
|
||||
**Encapsulation:** Jede Schicht verpackt die Daten der darueberliegenden Schicht mit eigenem Header.
|
||||
**OSI vs. TCP/IP:**
|
||||
- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4
|
||||
- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1
|
||||
|
||||
**Merkhilfe Schichten:** "**A**lle **T**rinken **I**mmer **N**och" (Anwendung-Transport-Internet-Netzzugang)
|
||||
**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht.
|
||||
|
||||
---
|
||||
|
||||
@@ -515,23 +522,26 @@ SPEAKER NOTES:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Dateneinheiten: Erklaerung
|
||||
# Dateneinheiten & Encapsulation – Vertiefung
|
||||
|
||||
**Definition:** Jede Schicht im TCP/IP-Modell hat eine eigene Bezeichnung fuer die Daten, die sie verarbeitet.
|
||||
**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
|
||||
|
||||
| Schicht | Dateneinheit | Was kommt hinzu? |
|
||||
|---------|--------------|------------------|
|
||||
| Anwendung | **Daten** (Message) | Anwendungsspezifische Infos |
|
||||
| Transport | **Segment** | Ports, Sequenznummern |
|
||||
| Internet | **Paket** | IP-Adressen (Quelle, Ziel) |
|
||||
| Netzzugang | **Frame** | MAC-Adressen, Pruefsumme |
|
||||
**Was jeder Header enthält:**
|
||||
|
||||
**Encapsulation-Prozess:**
|
||||
```
|
||||
Daten → [TCP-Header + Daten] → [IP-Header + Segment] → [Eth-Header + Paket + Eth-Trailer]
|
||||
```
|
||||
| Schicht | Einheit | Header-Inhalte |
|
||||
|---------|---------|----------------|
|
||||
| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
|
||||
| Transport | Segment | Quell-/Zielport, Sequenznummer, Flags (SYN, ACK) |
|
||||
| Internet | Paket | Quell-/Ziel-IP, TTL, Protokoll (TCP=6, UDP=17) |
|
||||
| Netzzugang | Frame | Quell-/Ziel-MAC, EtherType, CRC-Prüfsumme |
|
||||
|
||||
**Merkhilfe:** "**D**er **S**ache **P**raktischer **F**olgen" (Daten-Segment-Paket-Frame, von oben nach unten)
|
||||
**Overhead-Rechnung (1 Byte HTTP-Body):**
|
||||
- Ethernet: 14 + 4 Bytes (Header + Trailer)
|
||||
- IP: 20 Bytes (ohne Optionen)
|
||||
- TCP: 20 Bytes (ohne Optionen)
|
||||
- **Minimum: 58 Bytes für 1 Byte Nutzlast**
|
||||
|
||||
**Decapsulation:** Empfänger packt in umgekehrter Reihenfolge aus. Jede Schicht prüft ihren Header (z.B. CRC) und reicht Nutzdaten nach oben.
|
||||
|
||||
---
|
||||
|
||||
@@ -718,22 +728,27 @@ SPEAKER NOTES:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# IP vs. MAC vs. Port: Erklaerung
|
||||
# IP, MAC, Port – Vertiefung
|
||||
|
||||
**Definition:** Drei verschiedene Adresstypen fuer drei verschiedene Fragen im Netzwerk.
|
||||
Drei Adressebenen lösen drei verschiedene Probleme:
|
||||
|
||||
| Adresstyp | Frage | Reichweite | Aendert sich? |
|
||||
|-----------|-------|------------|---------------|
|
||||
| **IP-Adresse** | Welcher Rechner im Internet? | Global | Nein (Ziel bleibt) |
|
||||
| **MAC-Adresse** | Welches Geraet nebenan? | Lokal (1 Hop) | Ja, bei jedem Hop |
|
||||
| **Port** | Welches Programm? | Auf einem Rechner | Nein |
|
||||
**IP-Adresse (Schicht 2 – Internet):**
|
||||
- Hierarchisch aufgebaut: Netzwerk-Teil + Host-Teil
|
||||
- Router lesen nur den Netzwerk-Teil für Routing-Entscheidungen
|
||||
- IPv4: 32 Bit (z.B. 192.168.1.1), IPv6: 128 Bit
|
||||
|
||||
**Analogie Briefpost:**
|
||||
- **IP** = Empfaengeradresse auf dem Brief (bleibt gleich)
|
||||
- **MAC** = "Naechstes Postamt" (aendert sich bei jeder Station)
|
||||
- **Port** = Wohnungsnummer im Mehrfamilienhaus
|
||||
**MAC-Adresse (Schicht 1 – Netzzugang):**
|
||||
- 48 Bit, vom Hersteller fest vergeben (theoretisch)
|
||||
- Erste 24 Bit = OUI (Organizationally Unique Identifier) = Hersteller
|
||||
- Nur relevant für den **nächsten Hop** – wird bei jedem Router ersetzt
|
||||
- ARP (Address Resolution Protocol) übersetzt IP → MAC
|
||||
|
||||
**Merkhilfe:** "**I**P = **I**nternet-weit, **M**AC = **M**omentaner Nachbar, **P**ort = **P**rogramm"
|
||||
**Port (Schicht 3 – Transport):**
|
||||
- 16 Bit → 65.535 mögliche Ports
|
||||
- Well-Known Ports (0–1023): HTTP=80, HTTPS=443, SSH=22
|
||||
- Ephemeral Ports (49152–65535): Dynamisch für Client-Verbindungen
|
||||
|
||||
**Warum ändert sich nur MAC?** IP ist das Endziel (Brief-Adresse), MAC ist der aktuelle Bote (wer trägt den Brief gerade?).
|
||||
|
||||
---
|
||||
|
||||
@@ -1023,24 +1038,29 @@ SPEAKER NOTES:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 3-Way-Handshake: Erklaerung
|
||||
# 3-Way-Handshake – Vertiefung
|
||||
|
||||
**Definition:** Der TCP-Verbindungsaufbau in drei Schritten, bei dem Client und Server ihre Sequenznummern austauschen.
|
||||
Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit.
|
||||
|
||||
**Die drei Schritte:**
|
||||
1. **SYN** (Client → Server): "Ich will reden, starte bei Seq=1000"
|
||||
2. **SYN-ACK** (Server → Client): "OK, ich starte bei Seq=5000, erwarte 1001"
|
||||
3. **ACK** (Client → Server): "Verstanden, erwarte 5001 - los geht's!"
|
||||
**Warum zufällige Startwerte (ISN)?**
|
||||
- Sicherheit: Verhindert Session-Hijacking durch Raten
|
||||
- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen
|
||||
- ISN = Initial Sequence Number, vom OS zufällig gewählt
|
||||
|
||||
**Warum so kompliziert?**
|
||||
- Beide Seiten muessen **bereit** sein
|
||||
- Sequenznummern werden **synchronisiert** (daher SYN)
|
||||
- Verlorene Pakete koennen spaeter **erkannt und nachgefordert** werden
|
||||
**TCP-Flags im Handshake:**
|
||||
|
||||
**Analogie Telefonat:**
|
||||
- Klingeln → Abheben → "Hallo?" → Gespraech beginnt
|
||||
| Paket | Flags | Bedeutung |
|
||||
|-------|-------|-----------|
|
||||
| 1 | SYN | Client will Verbindung, sendet seine ISN |
|
||||
| 2 | SYN+ACK | Server akzeptiert, sendet seine ISN, bestätigt Client-ISN+1 |
|
||||
| 3 | ACK | Client bestätigt Server-ISN+1 |
|
||||
|
||||
**Merkhilfe:** "**S**ag mir → **S**icher, **A**ntworte → **A**lles klar" (SYN → SYN-ACK → ACK)
|
||||
**Was passiert bei Problemen?**
|
||||
- Kein SYN-ACK → Client wiederholt SYN (Timeout)
|
||||
- SYN-Flood-Attacke: Millionen SYNs ohne ACK → Server-Ressourcen erschöpft
|
||||
- Schutz: SYN-Cookies (Server speichert keinen State bis ACK kommt)
|
||||
|
||||
**Verbindungsabbau:** 4-Way-Handshake (FIN → ACK → FIN → ACK) oder RST für sofortigen Abbruch.
|
||||
|
||||
---
|
||||
|
||||
@@ -1555,24 +1575,31 @@ SPEAKER NOTES:
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP vs. UDP: Erklaerung
|
||||
# TCP vs. UDP – Vertiefung
|
||||
|
||||
**Definition:** Die zwei Transport-Protokolle mit unterschiedlichen Garantien und Anwendungsfaellen.
|
||||
Beide sind Transport-Protokolle (Schicht 3), aber mit fundamental unterschiedlichen Garantien.
|
||||
|
||||
| Eigenschaft | TCP | UDP |
|
||||
|-------------|-----|-----|
|
||||
| Verbindungsaufbau | Ja (3-Way-Handshake) | Nein |
|
||||
| Reihenfolge | Garantiert | Nicht garantiert |
|
||||
| Verlorene Pakete | Werden nachgefordert | Gehen verloren |
|
||||
| Geschwindigkeit | Langsamer (Overhead) | Schneller |
|
||||
**TCP (Transmission Control Protocol):**
|
||||
- Verbindungsorientiert (Handshake vor Daten)
|
||||
- Sequenznummern → Reihenfolge garantiert
|
||||
- ACKs + Retransmission → Kein Datenverlust
|
||||
- Flow Control (Sliding Window) → Empfänger nicht überlasten
|
||||
- Congestion Control → Netzwerk nicht überlasten
|
||||
|
||||
**Wann TCP?** Wenn **alles ankommen** muss:
|
||||
- Web (HTTP/HTTPS), E-Mail, Datei-Downloads
|
||||
**UDP (User Datagram Protocol):**
|
||||
- Verbindungslos (Fire-and-Forget)
|
||||
- Keine Sequenznummern, keine ACKs
|
||||
- Header nur 8 Bytes (TCP: 20+ Bytes)
|
||||
- Anwendung muss selbst für Zuverlässigkeit sorgen
|
||||
|
||||
**Wann UDP?** Wenn **Geschwindigkeit** wichtiger ist als Vollstaendigkeit:
|
||||
- Video-Calls, Gaming, DNS, Streaming
|
||||
| Anwendung | Protokoll | Grund |
|
||||
|-----------|-----------|-------|
|
||||
| HTTP/HTTPS | TCP | Vollständigkeit kritisch |
|
||||
| DNS | UDP | Kleine Pakete, schnelle Antwort |
|
||||
| Video-Streaming | UDP/QUIC | Latenz wichtiger als Perfektion |
|
||||
| Online-Gaming | UDP | Echtzeit, veraltete Daten nutzlos |
|
||||
|
||||
**Merkhilfe:** "**T**CP = **T**otal **C**omplete **P**ackages" vs. "**U**DP = **U**nsicher, **D**afuer **P**rompt"
|
||||
**QUIC:** Googles Protokoll kombiniert UDP-Geschwindigkeit mit TCP-ähnlicher Zuverlässigkeit (HTTP/3).
|
||||
|
||||
---
|
||||
|
||||
@@ -1659,23 +1686,30 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP-Methoden: Erklaerung
|
||||
# HTTP-Methoden – Vertiefung
|
||||
|
||||
**Definition:** HTTP-Methoden beschreiben die gewuenschte Aktion auf einer Ressource.
|
||||
HTTP-Methoden definieren die **Semantik** der Anfrage – was der Client vom Server erwartet.
|
||||
|
||||
| Methode | Bedeutung | Typischer Einsatz |
|
||||
|---------|-----------|-------------------|
|
||||
| **GET** | Daten abrufen | Webseite laden, Bild anzeigen |
|
||||
| **POST** | Daten senden | Formular absenden, Login |
|
||||
| **PUT** | Daten ersetzen | Profil komplett aktualisieren |
|
||||
| **PATCH** | Daten teilweise aendern | Einzelnes Feld aendern |
|
||||
| **DELETE** | Daten loeschen | Account loeschen |
|
||||
**CRUD-Mapping (Create, Read, Update, Delete):**
|
||||
|
||||
**Idempotenz:** GET, PUT, DELETE koennen mehrfach ausgefuehrt werden mit gleichem Ergebnis. POST nicht (mehrfach absenden = mehrere Bestellungen).
|
||||
| Methode | CRUD | Idempotent | Safe | Typischer Einsatz |
|
||||
|---------|------|------------|------|-------------------|
|
||||
| GET | Read | Ja | Ja | Ressource abrufen |
|
||||
| POST | Create | Nein | Nein | Formular, neue Ressource |
|
||||
| PUT | Update | Ja | Nein | Ressource vollständig ersetzen |
|
||||
| PATCH | Update | Nein | Nein | Ressource teilweise ändern |
|
||||
| DELETE | Delete | Ja | Nein | Ressource löschen |
|
||||
|
||||
**REST-APIs:** Nutzen diese Methoden systematisch fuer CRUD-Operationen (Create, Read, Update, Delete).
|
||||
**Idempotent:** Mehrfaches Ausführen hat denselben Effekt wie einmaliges (GET, PUT, DELETE).
|
||||
**Safe:** Ändert nichts am Server (nur GET, HEAD, OPTIONS).
|
||||
|
||||
**Merkhilfe:** "**G**ib mir, **P**oste das, **P**latziere neu, **D**elete" (GET, POST, PUT, DELETE)
|
||||
**REST-Prinzip:** URLs identifizieren Ressourcen, Methoden definieren Aktionen.
|
||||
```
|
||||
GET /users/42 → Benutzer 42 abrufen
|
||||
PUT /users/42 → Benutzer 42 vollständig ersetzen
|
||||
DELETE /users/42 → Benutzer 42 löschen
|
||||
POST /users → Neuen Benutzer erstellen
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -1718,24 +1752,24 @@ Status-Codes sagen euch, was passiert ist.
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP Status-Codes: Erklaerung
|
||||
# HTTP Status-Codes – Vertiefung
|
||||
|
||||
**Definition:** Dreistellige Codes, die der Server zurueckgibt, um das Ergebnis einer Anfrage zu beschreiben.
|
||||
Die erste Ziffer kategorisiert die Antwort:
|
||||
|
||||
| Bereich | Bedeutung | Wichtige Codes |
|
||||
|---------|-----------|----------------|
|
||||
| **2xx** | Erfolg | 200 OK, 201 Created, 204 No Content |
|
||||
| **3xx** | Umleitung | 301 Moved Permanently, 304 Not Modified |
|
||||
| **4xx** | Client-Fehler | 400 Bad Request, 403 Forbidden, 404 Not Found |
|
||||
| **5xx** | Server-Fehler | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
|
||||
| Bereich | Kategorie | Häufige Codes |
|
||||
|---------|-----------|---------------|
|
||||
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
|
||||
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
|
||||
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
|
||||
| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
|
||||
| 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
|
||||
|
||||
**Haeufigste Codes im Alltag:**
|
||||
- **200:** Alles OK, hier sind die Daten
|
||||
- **404:** Seite nicht gefunden (falsche URL)
|
||||
- **403:** Zugriff verweigert (keine Berechtigung)
|
||||
- **500:** Server hat einen Fehler (nicht eure Schuld)
|
||||
**Wichtige Unterscheidungen:**
|
||||
- **401 vs. 403:** 401 = nicht authentifiziert (wer bist du?), 403 = nicht autorisiert (du darfst nicht)
|
||||
- **301 vs. 302:** 301 = permanent umgezogen (Cache-fähig), 302 = temporär (nicht cachen)
|
||||
- **304 Not Modified:** Browser hat Cache, Server bestätigt: noch aktuell → spart Bandbreite
|
||||
|
||||
**Merkhilfe:** "**2**=alles **g**ut, **3**=woanders, **4**=du Fehler, **5**=Server Fehler"
|
||||
**API-Design:** Korrekte Status-Codes sind wichtig für Clients. `200` bei Fehler mit `{"error": "..."}` im Body ist schlechtes Design.
|
||||
|
||||
---
|
||||
|
||||
@@ -1779,27 +1813,33 @@ Wie Encapsulation funktioniert.
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Netzwerke Zusammenfassung: Erklaerung
|
||||
# Netzwerk-Grundlagen – Vertiefung
|
||||
|
||||
**Der Ablauf eines Webseitenaufrufs:**
|
||||
1. **DNS** (UDP:53): Domain → IP-Adresse aufloesen
|
||||
2. **TCP-Handshake:** SYN → SYN-ACK → ACK (Verbindung aufbauen)
|
||||
3. **HTTP-Request:** GET /index.html (Seite anfordern)
|
||||
4. **HTTP-Response:** 200 OK + HTML (Seite erhalten)
|
||||
Die vier Kernkonzepte für Web-Entwickler:
|
||||
|
||||
**Die 4 Schichten (TCP/IP):**
|
||||
**1. DNS-Auflösung:**
|
||||
- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
|
||||
- Rekursive Abfrage: Root → TLD → Authoritative
|
||||
- Caching auf jeder Ebene (TTL = Time To Live)
|
||||
|
||||
| Schicht | Protokolle | Dateneinheit |
|
||||
|---------|------------|--------------|
|
||||
| Anwendung | HTTP, DNS | Daten |
|
||||
| Transport | TCP, UDP | Segment |
|
||||
| Internet | IP | Paket |
|
||||
| Netzzugang | Ethernet | Frame |
|
||||
**2. TCP-Verbindungsaufbau:**
|
||||
- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
|
||||
- Keep-Alive: Verbindung bleibt offen für mehrere Requests
|
||||
- HTTP/2: Multiplexing – viele Requests über eine Verbindung
|
||||
|
||||
**Merkhilfen:**
|
||||
- Schichten: "**A**lle **T**rinken **I**mmer **N**och"
|
||||
- Dateneinheiten: "**D**er **S**ache **P**raktischer **F**olgen"
|
||||
- IP bleibt gleich, MAC aendert sich bei jedem Hop
|
||||
**3. HTTP Request/Response:**
|
||||
```
|
||||
Request: Methode + URL + Header + (Body)
|
||||
Response: Status + Header + Body
|
||||
```
|
||||
|
||||
**4. Schichten & Adressen:**
|
||||
| Was bleibt gleich? | Was ändert sich? |
|
||||
|-------------------|------------------|
|
||||
| Ziel-IP | MAC-Adressen (bei jedem Hop) |
|
||||
| Ports | – |
|
||||
|
||||
**Debugging:** Browser DevTools (F12 → Network) zeigt alle Requests, Timing, Header.
|
||||
|
||||
---
|
||||
|
||||
@@ -2098,26 +2138,26 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# CSS Spezifitaet: Erklaerung
|
||||
# CSS Spezifität – Vertiefung
|
||||
|
||||
**Definition:** Spezifitaet bestimmt, welche CSS-Regel gewinnt, wenn mehrere Regeln auf dasselbe Element zutreffen.
|
||||
Spezifität bestimmt, welche CSS-Regel gewinnt, wenn mehrere auf dasselbe Element zutreffen. Sie wird als 4-stellige Zahl berechnet: **(Inline, IDs, Klassen, Elemente)**.
|
||||
|
||||
**Spezifitaet als 4-stellige Zahl (a,b,c,d):**
|
||||
**Berechnung:**
|
||||
|
||||
| Kategorie | Gewicht | Beispiel |
|
||||
|-----------|---------|----------|
|
||||
| **a:** Inline-Style | 1,0,0,0 | `style="..."` |
|
||||
| **b:** ID | 0,1,0,0 | `#header` |
|
||||
| **c:** Klasse, Attribut, Pseudo-Klasse | 0,0,1,0 | `.wichtig`, `:hover` |
|
||||
| **d:** Element, Pseudo-Element | 0,0,0,1 | `p`, `::before` |
|
||||
| Selektor | Inline | IDs | Klassen | Elemente | Gesamt |
|
||||
|----------|--------|-----|---------|----------|--------|
|
||||
| `p` | 0 | 0 | 0 | 1 | 0,0,0,1 |
|
||||
| `.info` | 0 | 0 | 1 | 0 | 0,0,1,0 |
|
||||
| `p.info` | 0 | 0 | 1 | 1 | 0,0,1,1 |
|
||||
| `#header` | 0 | 1 | 0 | 0 | 0,1,0,0 |
|
||||
| `#header .nav a` | 0 | 1 | 1 | 1 | 0,1,1,1 |
|
||||
|
||||
**Vergleich:** Von links nach rechts, hoehere Zahl gewinnt.
|
||||
- 0,1,0,0 > 0,0,99,99 (eine ID schlaegt beliebig viele Klassen)
|
||||
**Wichtige Regeln:**
|
||||
- Eine Klasse (0,0,1,0) schlägt **jede Anzahl** von Elementen (0,0,0,99)
|
||||
- Eine ID schlägt jede Anzahl von Klassen
|
||||
- `!important` bricht alles → vermeiden, da schwer zu überschreiben
|
||||
|
||||
**Praktische Tipps:**
|
||||
- Vermeide IDs in CSS (zu spezifisch)
|
||||
- Vermeide `!important` (bricht das System)
|
||||
- Nutze Klassen fuer wiederverwendbare Styles
|
||||
**Best Practice:** Flache Spezifität anstreben. BEM-Methodik (`.block__element--modifier`) hält Spezifität gleichmäßig niedrig.
|
||||
|
||||
---
|
||||
|
||||
@@ -2372,32 +2412,30 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Responsive Design: Erklaerung
|
||||
# Responsive Design – Vertiefung
|
||||
|
||||
**Definition:** Webseiten passen sich automatisch an verschiedene Bildschirmgroessen an (Desktop, Tablet, Smartphone).
|
||||
**Mobile First** ist der Standard: Basis-CSS für kleine Screens, dann Erweiterungen für größere.
|
||||
|
||||
**Mobile First Ansatz:**
|
||||
1. Basis-CSS fuer kleine Bildschirme schreiben
|
||||
2. Mit `@media (min-width: ...)` fuer groessere Bildschirme erweitern
|
||||
**Breakpoints (gängige Werte):**
|
||||
|
||||
```css
|
||||
/* Basis (Mobile) */
|
||||
.container { padding: 1rem; }
|
||||
| Breakpoint | Gerät | Media Query |
|
||||
|------------|-------|-------------|
|
||||
| < 576px | Smartphone (Portrait) | Basis (kein Query) |
|
||||
| ≥ 576px | Smartphone (Landscape) | `@media (min-width: 576px)` |
|
||||
| ≥ 768px | Tablet | `@media (min-width: 768px)` |
|
||||
| ≥ 992px | Desktop | `@media (min-width: 992px)` |
|
||||
| ≥ 1200px | Large Desktop | `@media (min-width: 1200px)` |
|
||||
|
||||
/* Ab 768px (Tablet) */
|
||||
@media (min-width: 768px) { .container { padding: 2rem; } }
|
||||
|
||||
/* Ab 1024px (Desktop) */
|
||||
@media (min-width: 1024px) { .container { max-width: 1200px; } }
|
||||
**Viewport-Meta-Tag (kritisch!):**
|
||||
```html
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
```
|
||||
Ohne diesen Tag ignorieren mobile Browser eure Media Queries und rendern die Desktop-Version verkleinert.
|
||||
|
||||
**Typische Breakpoints:**
|
||||
- **576px:** Kleine Smartphones
|
||||
- **768px:** Tablets
|
||||
- **1024px:** Desktop
|
||||
- **1200px:** Grosse Bildschirme
|
||||
|
||||
**Merkhilfe:** "Mobile First" = Basis klein, dann groesser werden
|
||||
**Moderne Alternativen zu Media Queries:**
|
||||
- `clamp()`: `font-size: clamp(1rem, 2vw, 2rem);`
|
||||
- Container Queries: Reagieren auf Container-Größe statt Viewport
|
||||
- CSS Grid `auto-fit`/`auto-fill`: Automatisches Responsive Layout
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 3: Interaktivität & JavaScript"
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.4 MiB |
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
|
||||
---
|
||||
<style>
|
||||
@@ -93,7 +93,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
|
||||
+176
-13
@@ -3,9 +3,9 @@ marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Klausurfragen – 223015c"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
title: "Klausurfragen – Grundlagen IT- und Internettechnik"
|
||||
header: ""
|
||||
footer: ""
|
||||
title: "Fragenkatalog – IT-Grundlagen (223015c)"
|
||||
---
|
||||
<style>
|
||||
:root {
|
||||
@@ -13,19 +13,40 @@ title: "Klausurfragen – Grundlagen IT- und Internettechnik"
|
||||
--color-highlight: #d63384;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert { --color-foreground: #fff; }
|
||||
section { font-size: 1.325rem; }
|
||||
h1 { color: #a02060; }
|
||||
section.invert h1 { color: #fff; }
|
||||
h2 { color: #1f2937; }
|
||||
pre { background: #0f0f23; border-radius: 8px; }
|
||||
pre code { background: transparent; color: inherit; }
|
||||
a { color: var(--color-highlight); }
|
||||
section.disable { opacity: 0.3; }
|
||||
section.invert {
|
||||
--color-foreground: #fff;
|
||||
}
|
||||
section {
|
||||
font-size: 1.325rem;
|
||||
}
|
||||
h1 {
|
||||
color: #a02060; /* darker raspberry */
|
||||
}
|
||||
section.invert h1 {
|
||||
color: #fff;
|
||||
}
|
||||
h2 {
|
||||
color: #1f2937; /* dark gray, almost black */
|
||||
}
|
||||
pre {
|
||||
background: #0f0f23;
|
||||
border-radius: 8px;
|
||||
}
|
||||
pre code {
|
||||
background: transparent;
|
||||
color: inherit;
|
||||
}
|
||||
a {
|
||||
color: var(--color-highlight);
|
||||
}
|
||||
section.disable {
|
||||
opacity: 0.3;
|
||||
}
|
||||
</style>
|
||||
|
||||
|
||||
# Klausurfragen – 223015c
|
||||
**Grundlagen IT- und Internettechnik · HdM Stuttgart · M. Czechowski**
|
||||
**IT-Grundlagen · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 02.02.2026</small>
|
||||
|
||||
@@ -104,6 +125,20 @@ Welche der folgenden Aussagen werden durch die Von-Neumann-Architektur ermöglic
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### A4 – Von-Neumann: Komponenten erklären
|
||||
**Thema:** Von-Neumann – Transfer
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die fünf Komponenten der Von-Neumann-Architektur: **Rechenwerk (ALU)**, **Steuerwerk**, **Speicherwerk**, **Ein-/Ausgabe** und **Bus-System**. Beschreiben Sie für jede Komponente ihre Hauptfunktion in einem Satz.
|
||||
|
||||
> **Musterlösung:** **Rechenwerk (ALU):** Führt arithmetische (Addition, Subtraktion) und logische (AND, OR, NOT) Operationen durch. **Steuerwerk:** Holt Befehle aus dem Speicher, dekodiert sie und steuert ihre Ausführung (Fetch-Decode-Execute). **Speicherwerk:** Speichert sowohl Programme als auch Daten im selben Speicher – das Kernprinzip der Von-Neumann-Architektur. **Ein-/Ausgabe:** Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerkkarte. **Bus-System:** Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK B – Netzwerk-Grundlagen (TCP/IP)
|
||||
@@ -225,6 +260,17 @@ Ordne jeder Adresse ihre Beschreibung zu.
|
||||
|
||||
---
|
||||
|
||||
### B7a – IP, MAC, Port: Drei Ebenen erklären
|
||||
**Thema:** Adressierung – Transfer
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die drei Adressierungsebenen **IP-Adresse**, **MAC-Adresse** und **Port-Nummer**. Beschreiben Sie für jede: (1) was sie identifiziert, (2) auf welcher Ebene sie gilt (lokal/global), (3) eine Analogie aus dem Alltag.
|
||||
|
||||
> **Musterlösung:** **IP-Adresse:** Identifiziert ein Gerät im Internet. Global gültig, ermöglicht Routing über Netzwerkgrenzen. Analogie: „Postanschrift eines Hauses". **MAC-Adresse:** Identifiziert eine Netzwerkkarte. Nur lokal gültig (ein Hop). Analogie: „Seriennummer des Briefkastens". **Port-Nummer:** Identifiziert einen Dienst auf dem Gerät. Analogie: „Türnummer in einem Mehrfamilienhaus" – IP sagt welches Haus, Port sagt welche Wohnung.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### B8 – MAC ändert sich, IP nicht: Warum?
|
||||
@@ -315,6 +361,17 @@ Ein Videostreaming-Dienst sendet Daten an Ihren Browser. Ein einzelnes Paket geh
|
||||
|
||||
---
|
||||
|
||||
### B13a – TCP vs. UDP: Eigenschaften vergleichen
|
||||
**Thema:** TCP vs. UDP – Vergleich
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Vergleichen Sie **TCP** und **UDP**. Beschreiben Sie für jedes Protokoll: (1) ob es verbindungsorientiert ist, (2) ob es Zuverlässigkeit garantiert, (3) einen konkreten Anwendungsfall mit Begründung.
|
||||
|
||||
> **Musterlösung:** **TCP:** Verbindungsorientiert (3-Way-Handshake). Garantiert Zuverlässigkeit: Sequenznummern, Bestätigungen (ACK), erneutes Senden bei Verlust. Anwendung: Dateiübertragung, E-Mail – jedes Byte muss ankommen. **UDP:** Verbindungslos („fire and forget"). Keine Garantie für Lieferung oder Reihenfolge. Anwendung: Videostreaming, Online-Gaming – Latenz wichtiger als Vollständigkeit, ein verlorenes Paket wird ignoriert statt nachgefordert.
|
||||
|
||||
---
|
||||
|
||||
### B14 – TCP vs. UDP: Unterschiede beschreiben
|
||||
**Thema:** TCP vs. UDP – Konzept-Vergleich
|
||||
**Punkte:** 2
|
||||
@@ -371,6 +428,8 @@ Beschreibe die drei Schritte des TCP 3-Way-Handshakes. Erkläre, warum alle drei
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### B18 – TCP Sequenznummern: Wozu?
|
||||
**Thema:** TCP – Sequenznummern
|
||||
**Punkte:** 1
|
||||
@@ -545,6 +604,30 @@ Ordne jedem Szenario den passenden HTTP-Status-Code zu.
|
||||
|
||||
---
|
||||
|
||||
### C9a – Status-Codes: 2xx, 4xx, 5xx vergleichen
|
||||
**Thema:** HTTP Status-Codes – Kategorien erklären
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### C9b – HTTP-Methoden vergleichen: GET, POST, PUT, DELETE
|
||||
**Thema:** HTTP-Methoden – Vergleich
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die vier HTTP-Methoden **GET**, **POST**, **PUT** und **DELETE**. Beschreiben Sie für jede: (1) die Hauptfunktion, (2) ob Daten im Request-Body gesendet werden, (3) ein konkretes Beispiel.
|
||||
|
||||
> **Musterlösung:** **GET:** Ruft eine Ressource ab (nur lesen). Keine Daten im Body (Parameter in URL). Beispiel: Webseite aufrufen. **POST:** Erstellt eine neue Ressource. Daten im Body. Beispiel: Neuen Blog-Eintrag erstellen. **PUT:** Ersetzt eine existierende Ressource vollständig. Daten im Body. Beispiel: Profilbild durch ein neues ersetzen. **DELETE:** Löscht eine Ressource. Meist keine Daten im Body. Beispiel: Kommentar löschen.
|
||||
|
||||
---
|
||||
|
||||
### C10 – Status-Codes: Freitext
|
||||
**Thema:** HTTP Status-Codes – Konzept zusammenfassen
|
||||
**Punkte:** 2
|
||||
@@ -580,6 +663,42 @@ Was ist die Hauptfunktion eines DNS-Servers?
|
||||
|
||||
### D2 – DNS: Zeitlicher Ablauf
|
||||
**Thema:** DNS – Rolle im Gesamtablauf
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie geben `https://hdm-stuttgart.de` in die Adresszeile ein. Was passiert **vor** dem TCP-Handshake?
|
||||
|
||||
- [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach benötigt.
|
||||
- [x] **DNS-Auflösung: Der Name wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen.** ✅
|
||||
- [ ] DNS passiert nach dem TCP-Handshake.
|
||||
- [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
|
||||
|
||||
> **Feedback:** DNS vor TCP. Kein Name-to-IP? Kein Handshake möglich. TCP arbeitet auf IP-Adressen, nicht auf Domain-Namen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D1-alt – DNS: Was macht es?
|
||||
**Thema:** DNS – Grundfunktion
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist die Hauptfunktion eines DNS-Servers?
|
||||
|
||||
- [ ] Er verschlüsselt die Verbindung zwischen Client und Server.
|
||||
- [x] **Er übersetzt einen Domain-Namen (z. B. `hdm-stuttgart.de`) in eine IP-Adresse.** ✅
|
||||
- [ ] Er routet Pakete durch das Internet.
|
||||
- [ ] Er weist jedem Computer eine MAC-Adresse zu.
|
||||
|
||||
> **Feedback:** DNS = Domain Name System = „Telefonbuch des Internets". Name → IP. Ohne DNS müsste man überall IP-Adressen eintippen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D2-alt – DNS: Zeitlicher Ablauf
|
||||
**Thema:** DNS – Rolle im Gesamtablauf
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
@@ -594,6 +713,8 @@ Sie geben `https://hdm-stuttgart.de` in die Adresszeile ein. Was passiert vor de
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D3 – DNS: Warum zwingend nötig?
|
||||
**Thema:** DNS – Transfer/Begründung
|
||||
**Punkte:** 2
|
||||
@@ -605,6 +726,8 @@ Erkläre in 2–3 Sätzen, warum der DNS-Schritt zwingend vor dem TCP-Handshake
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D4 – DNS: Lückentext
|
||||
**Thema:** DNS – Terminologie
|
||||
**Punkte:** 1
|
||||
@@ -616,6 +739,19 @@ Der DNS-Server übersetzt einen [[1:Domain-Namen]] in eine [[2:IP-Adresse]]. Die
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D5 – Encapsulation: Daten → Segment → Paket → Frame
|
||||
**Thema:** Encapsulation – Transfer
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie den Encapsulation-Prozess beim Senden einer Nachricht. Beschreiben Sie die vier Dateneinheiten **Daten**, **Segment**, **Paket** und **Frame**. Was wird bei jedem Schritt hinzugefügt und von welcher Schicht?
|
||||
|
||||
> **Musterlösung:** **Daten:** Die eigentliche Nachricht (z.B. HTML) von der Anwendungsschicht. **Segment:** Transportschicht fügt TCP-Header hinzu (Ports, Sequenznummern). **Paket:** Internetschicht fügt IP-Header hinzu (Quell- und Ziel-IP-Adresse). **Frame:** Netzzugangsschicht fügt Ethernet-Header (MAC-Adressen) und Trailer (Prüfsumme) hinzu. Beim Empfänger wird in umgekehrter Reihenfolge ausgepackt (Decapsulation).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK E – Der Gesamtablauf (Zusammen)
|
||||
@@ -653,6 +789,17 @@ Sie geben eine URL ein. Welche Reihenfolge ist korrekt?
|
||||
|
||||
> **Feedback:** DNS immer zuerst. Dann TCP (Verbindung). Dann HTTP (Anfrage/Antwort).
|
||||
|
||||
---
|
||||
|
||||
### E3 – Gesamtablauf: DNS, TCP, HTTP erklären
|
||||
**Thema:** Gesamtablauf – Schritte erklären
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die drei Hauptphasen beim Aufruf einer Webseite: **DNS-Auflösung**, **TCP-Verbindungsaufbau** und **HTTP-Request/Response**. Beschreiben Sie für jede Phase: (1) was passiert, (2) warum sie vor der nächsten kommen muss.
|
||||
|
||||
> **Musterlösung:** **DNS-Auflösung:** Der Domain-Name wird in eine IP-Adresse übersetzt. Muss zuerst kommen, weil TCP nur mit IP-Adressen arbeiten kann. **TCP-Verbindungsaufbau:** Der 3-Way-Handshake (SYN → SYN-ACK → ACK) baut eine zuverlässige Verbindung auf. Muss vor HTTP kommen, weil HTTP auf TCP aufsetzt und eine bestehende Verbindung braucht. **HTTP-Request/Response:** Der Browser sendet GET, der Server antwortet mit 200 OK + HTML. Kann erst nach TCP-Verbindung stattfinden.
|
||||
|
||||
---
|
||||
<!-- _class: lead -->
|
||||
|
||||
@@ -696,6 +843,8 @@ Ordne jedem Element zu, ob es in `<head>` oder `<body>` gehört.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### F3 – Charset: Was passiert ohne `<meta charset>`?
|
||||
**Thema:** HTML – Zeichenkodierung
|
||||
**Punkte:** 1
|
||||
@@ -817,6 +966,8 @@ Ordne jedem Eingabegerät seine Nutzungsweise zu.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### H2 – Einschränkungen: Temporär vs. situativ
|
||||
**Thema:** Barrierefreiheit – Einschränkungstypen
|
||||
**Punkte:** 2
|
||||
@@ -833,6 +984,18 @@ Eine Person kann aktuell nur mit einer Hand ihr Handy bedienen, weil sie das Bab
|
||||
|
||||
---
|
||||
|
||||
### H2a – Einschränkungen: Permanent, Temporär, Situativ
|
||||
**Thema:** Barrierefreiheit – Einschränkungstypen erklären
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die drei Typen von Einschränkungen: **permanent**, **temporär** und **situativ**. Nennen Sie für jeden Typ: (1) eine Definition, (2) ein konkretes Beispiel, (3) wie barrierefreie Gestaltung in diesem Fall hilft.
|
||||
|
||||
> **Musterlösung:** **Permanent:** Dauerhafte körperliche/kognitive Behinderung. Beispiel: Blindheit. Hilfe: Screenreader kann Alt-Texte vorlesen. **Temporär:** Zeitlich begrenzte Einschränkung durch Verletzung/Krankheit. Beispiel: Gebrochener Arm. Hilfe: Tastaturnavigation ermöglicht Bedienung ohne Maus. **Situativ:** Einschränkung durch aktuelle Umgebung/Situation. Beispiel: Helle Sonne auf dem Bildschirm. Hilfe: Hoher Kontrast macht Text trotzdem lesbar.
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### H3 – Curb-Cut-Effekt: Beispiel identifizieren
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user