Compare commits

57 Commits
Author SHA1 Message Date
libretech 8d5c57d561 merge klausur-erklaerungen into test-merge
resolves all conflicts: main's content preferred for slide edits,
klausur-erklaerungen's structural additions (erklaerung slides,
klausurfragen, archive, scripts) preserved.
fixes generate-root-index.sh semester to sommersemester 2026.
2026-03-26 22:31:04 +01:00
libretech 3a2e1a8d15 rework 223015c chapter 1: reorder history, improve slides, fix terminology
- kursübersicht: themen -> kapitel, format-zeile entfernt, vor kapitel 1 verschoben
- teil 1/2/3 prefixes entfernt, section titles vereinfacht
- von-neumann-architektur: konzeptfolie überarbeitet, klausur-titel ergänzt, redundante zeile entfernt
- folien-reihenfolge: von-neumann direkt nach eniac, lektionen für heute ans ende
- slide 34 (kalter krieg): inhalt erweitert, sputnik-schock speaker notes ergänzt
- bits/bytes-tabelle: faktor 8 zwischen bit und byte ergänzt
- 1tb-festplatte folie entfernt
- unterseekabel: bild hinzugefügt, five eyes ergänzt, text verbessert
2026-03-26 19:02:31 +01:00
libretech ac89d69365 update claude.md: add git checkout restriction, simplify nix section 2026-03-26 18:17:23 +01:00
libretech 552949811e rework 223015c chapter 1: improve formatting, speaker notes, remove redundant slides 2026-03-26 18:17:16 +01:00
libretech 030bb322a2 update semester to sommersemester 2026 across all courses 2026-03-26 18:17:09 +01:00
libretech 9631a1c45b simplify flake.nix: remove redundant scripts and claude-code, bump to node 22 2026-03-26 18:17:01 +01:00
libretech 4245ea2567 add essay questions across all blocks in 223015c
- A4: von-neumann komponenten (disabled)
- B7a: IP/MAC/Port vergleichen
- B13a: TCP vs UDP vergleichen
- C9a: status codes 2xx/4xx/5xx erklären
- C9b: HTTP-methoden vergleichen (disabled)
- D5: encapsulation erklären (disabled)
- E3: gesamtablauf DNS/TCP/HTTP
- H2a: einschränkungstypen erklären
2026-02-02 21:12:48 +01:00
libretech 51146d3dfc add more essay questions to 223015b (all disabled)
- J25: redundanz vs irrelevanz
- K12: rasterisierung vs vektorisierung
- L12: warum 8x8 blöcke bei JPEG
- N9: container vs codec transfer
2026-02-02 21:10:47 +01:00
libretech fda4aca4c7 add essay questions across all blocks in 223015b
- J23-J24: distribution comparison, analog vs digital
- K10-K11: image types, color depth (disabled)
- L10-L11: JPEG pipeline, artifacts (L11 disabled)
- M7-M8: image format comparison, GIF alternatives (M8 disabled)
- N7-N8: frame types, video codec comparison (N8 disabled)
- O14-O15: storage tech comparison, backup strategies (O15 disabled)
2026-02-02 20:51:46 +01:00
libretech aff352fa91 add questions for analog/digital media and storage types in 223015b
- J15-J22: analog/digital media, distribution methods, generationsverlust
- O9-O13: storage media categories, cloud, LTO
- some questions disabled for later use
2026-02-02 20:38:48 +01:00
libretech ea7e905c61 split klausurfragen into per-course files and add erklaerung slides to 223015c
- split slides/klausurfragen.md into course-specific files:
  - slides/223015b/klausurfragen.md (blocks J-O: dateiformate)
  - slides/223015c/klausurfragen.md (blocks A-I: it-grundlagen)
- add erklaerung slides to 223015c (16 new vertiefung slides)
- update erklaerung slides in 223015b with deeper content
- update makefile to build klausurfragen per-course
- remove global klausurfragen from root index
2026-02-02 19:06:37 +01:00
libretech 512fbd9d3d add erklaerung slides to 223015b course files
- add erklaerung css class and 6 explanation slides to 01-grundlagen-text-audio.md
- add erklaerung css class and 9 explanation slides to 02-bild-audio-video.md
- add erklaerung css class and 2 explanation slides to 03-speichermedien-schnittstellen.md
- regenerate klausurfolien.md with updated content
2026-02-02 14:25:04 +01:00
libretech 64f4729f45 add erklaerung slides after klausur slides in 223015c
- add section.erklaerung CSS class with pink theme styling
- add 6 explanation slides to 01-geschichte-grundlagen-html.md
- add 10 explanation slides to 02-netzwerke-protokolle-css.md
- each slide includes definition, key points, and mnemonics
2026-02-02 14:03:54 +01:00
libretechandClaude Opus 4.5 c35541961e add archive directory with old klausurfragen files
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:42:12 +01:00
libretechandClaude Opus 4.5 d8f68183f3 update 02-bild-audio-video.md structure and content
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:42:11 +01:00
libretechandClaude Opus 4.5 705c5e3457 add klausurfragen to topic map in generate-index.sh
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:42:02 +01:00
libretechandClaude Opus 4.5 9b0b6bc9d6 remove global klausurfragen from root index
klausurfragen are now per-course, no longer shown on root index

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:41:58 +01:00
libretechandClaude Opus 4.5 62cd97c51a update makefile for per-course klausurfragen
- add klausurfragen to KAPITEL lists for both courses
- remove standalone build-klausurfragen target
- remove deploy-klausurfragen target
- klausurfragen now built and deployed as part of each course

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:41:52 +01:00
libretechandClaude Opus 4.5 9f2c78d536 add course-specific klausurfragen files
split klausurfragen by course with appropriate CI:
- 223015b: blocks J-O (dateiformate) with blue CI
- 223015c: blocks A-I (IT-grundlagen) with pink CI

preserves existing disable markers for non-klausur questions

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:41:48 +01:00
libretechandClaude Opus 4.5 fb0db03db9 restore 01-grundlagen.md for 223015b
accidentally removed in a8343c9, restored from d77b0f2

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-02 13:41:42 +01:00
libretech f9185d25e0 add functionality to disable topics in course index and improve layout 2026-02-02 02:28:06 +01:00
libretech 4f3b680951 add build and deploy targets for klausurfragen 2026-02-02 01:20:33 +01:00
libretech a2b1c0484a update klausurfragen.md to improve visibility and clarify title 2026-02-02 01:13:31 +01:00
libretech 1480d31a54 refactor klausurfragen.md to use gender-neutral language and improve clarity 2026-02-01 22:38:14 +01:00
libretech 514896db33 update flake.nix to allow unfree packages and add claude-code dependency 2026-02-01 22:38:02 +01:00
libretech b21e2394d5 fix layout and add disabled state for slides 2026-02-01 22:27:26 +01:00
libretech 7da018d92c add klausurfragen for 223015c 2026-02-01 18:21:01 +01:00
libretech 9e12447528 rebuild dev and build system with single marp server
- simplify development: single marp server on port 3000 instead of 3 processes
- rename klausur to klausurfolien for better naming
- update extract script to use 00-intro.md as template when no 01-*.md exists
- update makefile and package.json for new workflow
- add comprehensive AGENTS.md guidelines
2026-02-01 18:17:51 +01:00
libretech 7e4d4a8a4b ignore idea and update slides 2026-01-30 17:55:53 +01:00
libretech 3fa1e1b1dc add klausur to build and overview 2026-01-25 21:47:22 +01:00
libretech a8343c9937 restructure: rename termin to kapitel, flatten folder structure
- rename slide files: YYYY-MM-DD-termin-N-topic.md → NN-topic.md
- flatten folders: courses/X/slides/ → slides/X/
- replace "Termin" with "Kapitel" in all content
- add klausur extraction script (make klausur)
- update Makefile, generate-index.sh, dev-server.sh
- add README.md with full documentation
2026-01-25 11:26:15 +01:00
libretech b951341376 rename to kapitel 2026-01-24 00:02:48 +01:00
libretech 0fab5005df rework termin-2 223015c beginning network 2026-01-24 00:00:43 +01:00
libretech 2755d4dee0 refine netzwerke section in termin-2 223015c 2026-01-23 21:09:14 +01:00
libretech a3131851f0 update contact email to lb-czechowski@hdm-stuttgart.de 2026-01-23 12:57:31 +01:00
libretech 7e878c27ef add quantization visual to termin-2, restructure jpeg section 2026-01-23 11:32:34 +01:00
libretech 93e8ced463 fix klausur slide pdf rendering with @media print fallback 2026-01-22 20:15:42 +01:00
libretech 58e0457165 restructure ascii position in termin-1, refine jpeg section in termin-2 2026-01-22 18:24:34 +01:00
libretech d77b0f20c7 add standalone slide decks 01-grundlagen and 02-bild-audio-video for 223015b 2026-01-22 17:02:38 +01:00
libretech f7f4872c11 termin-2: restructure jpeg section with menschliche sinne lead 2026-01-22 17:02:34 +01:00
libretech 5f6369ad85 add yuv/ycbcr assets for jpeg section in 223015b 2026-01-22 17:02:29 +01:00
libretech 31790930de termin-2: restructure video compression into 3 numbered slides
- add "was ist ein digitales bild?" intro slide with context
- split compression into: spatial, temporal, motion compensation
- add i/p/b frame abbreviation explanations in speaker notes
- add terminology notes (intra/inter vs spatial/temporal)
- update motion compensation with 16x16 pixel block example
2026-01-16 03:42:18 +01:00
libretech 4fa64a6abd add missing slide assets for 223015b
- ascii-table-colored.png
- av1 grammy images
- chroma subsampling diagram
- hilbert data growth chart
- hollerith machine
- moores law chart
2026-01-16 00:30:11 +01:00
libretech 5c970053ee 223015c termin-2: minor style fix from merge 2026-01-16 00:19:05 +01:00
libretech d19aa98f79 fix klausur gradient for pdf printing in termin 0,3,4,5
- add !important to repeating-linear-gradient for proper pdf export
2026-01-16 00:18:56 +01:00
libretech ccceac83e4 update termin-2: huffman example with vowels, add gradient !important
- change huffman coding example from numbers to vowels (a,e,i,o,u)
- add !important to klausur gradient for pdf printing
2026-01-16 00:18:47 +01:00
libretech 8f9934413a update termin-1: merge dateneinheiten slides, improve examples
- combine two dateneinheiten slides into one table (byte to zettabyte)
- replace poop emoji with cherry blossom in bytes example
- add japanese konnichiwa with pronunciation
- change hex example from MP3 to PNG (matches following slides)
- add !important to klausur gradient for pdf printing
2026-01-16 00:18:35 +01:00
libretech 32c14ac412 restructure termin 2 with narrative approach
- reframe content as "die reise eines klicks" story
- explain why layers/ip/mac/ports exist before showing how
- add encapsulation/decapsulation visualizations
- remove redundant css comments
- fix klausur background with !important
2026-01-14 20:56:53 +01:00
libretech 2179f6caed fix klausur pdf backgrounds with _backgroundColor directive
- remove !important from klausur css gradient (allows directive override)
- add _backgroundColor directive to all klausur slides for pdf
- web: shows css gradient stripes
- pdf: shows solid color background
2026-01-13 20:26:28 +01:00
libretech b45a528faf fix klausur slides for pdf: add svg pattern and marp directives
- add svg diagonal stripe patterns for pdf background
- use @media print to apply svg only in pdf export
- keep css gradient for web/screen display
- add _header: '' and _footer: '' to all klausur slides
2026-01-12 12:28:30 +01:00
libretech 64e67b7034 restructure 223015c slides: move a11y to termin-1, reorganize termin-2
termin-1:
- add accessibility (a11y) section with wcag principles

termin-2:
- move dns section earlier (before osi/tcp-ip theory)
- reorganize network fundamentals flow
- remove a11y section (moved to termin-1)
- update osi merksatz to "dualen"
2026-01-09 21:04:11 +01:00
libretech fc3f3a73f5 update slides: add course numbers to headers, widen stripe pattern
- add course number (223015b/c) to all slide headers
- widen klausur diagonal stripes from 20/40px to 40/80px
- expand termin-1 with analog vs digital media content
- rename wtf files exercise to hex files
2026-01-09 11:09:13 +01:00
libretech ee4d5435ed fix termin 2 header/footer colors to match termin 1
- change --color-dimmed from light gray to dark
- update code styling to dark bg with pink text
2026-01-05 17:22:28 +01:00
libretech 111d13420a add diagonal stripe pattern to klausur and aufgabe class in c course
- update klausur class with 135deg diagonal stripes (pink #fce4ec)
- add aufgabe class with solid background
- apply to all termin slides (1-3)
2026-01-05 17:19:09 +01:00
libretech 3db80be669 add diagonal stripe pattern to klausur and aufgabe class across b course
- update klausur class with 135deg diagonal stripes
- add aufgabe class with solid background
- apply to all termin slides (0-5)
2026-01-05 17:18:27 +01:00
libretech 8690e69e47 add diagonal stripes to klausur slides and update content
- add diagonal stripe pattern to klausur class
- add aufgabe class for exercise slides
- update napster section with new images
- revise hands-on audio exercise with online tools
- various content improvements
2026-01-05 17:13:26 +01:00
libretech 3f4be26dcb improve termin 1 slides content and formatting
- clean up speaker notes, remove redundant comments
- fix typo in bit etymology note
- update data units tables with german number names and examples
- add klausur class to exam-relevant slides
- improve hands-on exercise formatting with direct download links
2026-01-05 16:31:15 +01:00
143 changed files with 17199 additions and 6228 deletions

No files matched your search

+1
View File
@@ -32,3 +32,4 @@ hdm-internettechnik-slides/
# Temporary files
*.tmp
*.bak
.idea
+197
View File
@@ -0,0 +1,197 @@
# AGENTS.md - Agent Guidelines for HdM Slides
This file contains comprehensive guidelines for agentic coding agents working on the HdM Slides project.
## Project Overview
This project builds presentation decks for Marp, supporting multiple courses:
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
- **223015c** - Internettechnologien (3 Kapitel)
## Development Workflow
### Build Commands
```bash
# Development
make dev # Start single dev server on port 3000
npm run dev # Alternative command for development server
# Build
make build # Build all courses (HTML + PDF)
make build-b # Build 223015b only
make build-c # Build 223015c only
make html # HTML only builds
make pdf # PDF only builds
# Klausur Folien
make klausur # Extract klausurfolien for all courses
make klausur-b # Extract klausurfolien for 223015b
make klausur-c # Extract klausurfolien for 223015c
# Deployment
make deploy # Deploy all courses (requires explicit permission)
make deploy-b # Deploy 223015b only
make deploy-c # Deploy 223015c only
# Utilities
make qr URL=... # Generate QR code
make optimize-images COURSE=223015b # Resize images
make clean # Remove generated files
```
### Testing
No specific test framework is used. To validate changes:
1. Start dev server: `make dev`
2. Open http://localhost:3000/223015b/ or /223015c/
3. Verify slides render correctly
4. Run `make build` to ensure no build errors
5. Check generated files in `build/` directory
## Code Style Guidelines
### File Structure
- Slides in `slides/<course>/` following naming pattern `NN-topic.md`
- Assets in `slides/<course>/assets/`
- Always reference images as `./assets/filename.png`
- Scripts in `scripts/`
- Themes in `themes/`
- Generated output in `build/` (gitignored)
### Naming Conventions
- Slide files: `NN-topic.md` (e.g., `01-grundlagen.md`, `02-bilder.md`)
- Images: `snake_case.jpg` or `kebab-case.jpg`
- Klausur files: `klausurfolien.md` (auto-generated)
- Function names in scripts: `snake_case`
- Variable names in scripts: `snake_case`
### Markdown Style
- Use ATX-style headers (`# ## ###`)
- YAML frontmatter for slide metadata at top of each file
- Never include a final `---` (creates empty slide)
- Use `<!-- _class: klausur -->` for exam-relevant slides
- Use relative paths for assets: `./assets/image.png`
### Script Style
- Use `#!/usr/bin/env bash` shebang
- Use `set -e` for error handling
- Use `2>/dev/null || true` for optional operations
- Define variables in UPPER_CASE at script top
- Use colors for terminal output: `\033[0;32m` etc.
### Git Workflow
- Commit messages: ALWAYS lowercase
- NEVER add co-authoring lines or generated footers
- Follow semantic naming: "add-...", "fix-...", "update-..."
- Commit changes to scripts, Makefile, documentation separately from slide content
## Agent Restrictions
### Security
- NEVER run commands outside `/home/mwc/Coding/hdm` folder
- NEVER run build/deploy commands without explicit user request
- NEVER run deploy commands (make deploy, scp, etc.) without explicit permission
### File Protection
Slide files in `slides/*/*.md` are main content files:
- **ALLOWED**: Adding slides, adjusting content, fixing typos, enhancing sections
- **FORBIDDEN** (without permission): Deleting slides, removing sections, bulk deletions
- Before ANY deletion: ALWAYS ask user for confirmation
### Klausur Handling
- Klausur files (`klausurfolien.md`) are auto-generated
- NEVER edit klausurfolien.md files directly
- To update klausurfolien: edit source slides with `<!-- _class: klausur -->` markers
- Run `make klausur` to regenerate
## Development Patterns
### Adding New Slides
1. Create new file following `NN-topic.md` pattern
2. Copy frontmatter from existing slides in the same course
3. Update Makefile `_KAPITEL` variable if needed
4. Test with `make dev`
### Modifying Existing Slides
1. Edit the appropriate markdown file in `slides/<course>/`
2. Maintain consistent styling with course theme
3. Preserve image paths as `./assets/...`
4. Test changes with dev server
### Working with Assets
1. Place images in `slides/<course>/assets/`
2. Use descriptive names: `diagram-network.jpg`, `example-code.png`
3. Optimize with `make optimize-images COURSE=223015b`
4. Reference as `./assets/filename.ext`
### Course-Specific Configuration
Each course has specific settings in Makefile:
- Course name and title
- Kapitel list (slide files)
- Deploy path
- Theme colors (in generate-index.sh)
## Common Tasks
### Debugging Build Issues
1. Check Makefile syntax: `make -n build`
2. Verify Marp CLI installation: `npx @marp-team/marp-cli --version`
3. Check file permissions: `ls -la slides/`
4. Validate markdown syntax with dev server
### Updating Course Structure
1. Update `_KAPITEL` variables in Makefile
2. Ensure slide files follow naming convention
3. Update course-specific themes if needed
4. Test both dev and build processes
### Working with Themes
- Custom theme in `themes/custom-theme.css`
- Course themes defined in individual slide frontmatter
- Use consistent color schemes per course
- Test theme changes across all slides
## Deployment Process
Deployment to production server requires explicit permission:
1. Build process: `make build` (HTML + PDF)
2. Index generation: automatically handled
3. Deploy to remote server via SCP
4. Root index deployment
**IMPORTANT**: Never run deployment commands without explicit user permission.
## Tools and Dependencies
### Core Dependencies
- Marp CLI for slide rendering
- Bash scripts for automation
- Make for build orchestration
- Git for version control
### Optional Tools
- qrencode for QR generation (via nix)
- ImageMagick for image optimization
- Python 3 for simple HTTP server (legacy)
## Testing Strategy
Since there's no formal test suite:
1. Manual testing with dev server
2. Build process validation
3. Slide rendering checks
4. Asset path verification
5. Cross-browser compatibility checks (important)
## Troubleshooting
### Common Issues
- **Port conflicts**: Use `make dev-kill` to clean up processes
- **Build failures**: Check file permissions and Marp CLI installation
- **Asset loading**: Verify relative paths and file existence
- **Deploy issues**: Check SSH keys and remote permissions
### Getting Help
1. Check this AGENTS.md file first
2. Review Makefile targets and scripts
3. Test changes incrementally
4. Maintain backup of working configurations
+14 -15
View File
@@ -4,18 +4,19 @@ This project builds presentation decks for Marp, supporting multiple courses.
## Courses
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Termine)
- **223015c** - Internettechnologien (3 Termine)
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
- **223015c** - Internettechnologien (3 Kapitel)
## Agent Restrictions
- 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
Slide files in `courses/*/slides/*.md` are main content files:
Slide files in `slides/*/*.md` are main content files:
- ALLOWED: Adding slides, adjusting content, fixing typos, enhancing sections
- FORBIDDEN (without permission): Deleting slides, removing sections, bulk deletions
- Before ANY deletion: ALWAYS ask user for confirmation
@@ -23,9 +24,9 @@ Slide files in `courses/*/slides/*.md` are main content files:
## Project Structure
```
courses/
├── 223015b/slides/ # Dateiformate course
└── 223015c/slides/ # Internettechnik course
slides/
├── 223015b/ # Dateiformate course
└── 223015c/ # Internettechnik course
scripts/ # Shared scripts
themes/ # Custom Marp themes
build/ # Generated output (gitignored)
@@ -34,34 +35,32 @@ build/ # Generated output (gitignored)
## Build Commands
```bash
make dev-b # Dev server 223015b (port 1312)
make dev-c # Dev server 223015c (port 1313)
make dev-b # Dev server 223015b (port 1311)
make dev-c # Dev server 223015c (port 1312)
make build # Build all courses
make build-b # Build 223015b only
make build-c # Build 223015c only
make html # HTML only
make pdf # PDF only
make klausur # Extract klausur slides → slides/*/klausur.md
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
### File Structure
- Slides in `courses/<course>/slides/`
- Assets in `courses/<course>/slides/assets/`
- Slides in `slides/<course>/`
- Assets in `slides/<course>/assets/`
- Always reference images as `./assets/filename.png`
### Naming Conventions
- Slide files: `YYYY-MM-DD-termin-N-topic.md`
- Slide files: `NN-topic.md` (e.g., `01-grundlagen.md`)
- Images: `snake_case.jpg` or `kebab-case.jpg`
### Markdown Style
+36 -43
View File
@@ -1,25 +1,19 @@
# HdM Slides - Unified Makefile
# Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
.PHONY: help dev dev-b dev-c build build-b build-c pdf html clean install deploy qr optimize-images
.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images
# Course configuration
COURSES = 223015b 223015c
COURSE_DIR = courses
# Port configuration (index starts at BASE_PORT, courses increment from there)
BASE_PORT = 1310
INDEX_PORT = $(BASE_PORT)
SLIDES_DIR = slides
# Course-specific settings
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
223015b_PORT = 1311
223015b_TERMINS = 2025-12-19-termin-0-intro 2025-12-19-termin-1-grundlagen-text-audio 2026-01-09-termin-2-bild-audio-video 2026-01-23-termin-3-speichermedien-schnittstellen 2026-01-30-termin-4-distribution-apis-zukunft 2026-xx-xx-termin-5-vertiefung-offene-fragen
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien klausurfragen
223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
223015c_NAME = Internettechnologien
223015c_PORT = 1312
223015c_TERMINS = 2025-12-20-termin-1-geschichte-grundlagen-html 2026-01-10-termin-2-netzwerke-protokolle-css 2026-01-24-termin-3-interaktivitaet-javascript
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
DEPLOY_HOST = tengo@tuttle.uberspace.de
@@ -33,9 +27,7 @@ help:
@echo " 223015c - Internettechnologien"
@echo ""
@echo "Development:"
@echo " make dev - Both servers + index (ports 1311, 1312, 1313)"
@echo " make dev-b - Dev server for 223015b (port 1312)"
@echo " make dev-c - Dev server for 223015c (port 1313)"
@echo " make dev - Start development server (port 3000)"
@echo ""
@echo "Build:"
@echo " make build - Build all courses"
@@ -43,6 +35,7 @@ help:
@echo " make build-c - Build 223015c only"
@echo " make pdf - Export all to PDF"
@echo " make html - Export all to HTML"
@echo " make klausur - Extract klausurfolien slides"
@echo ""
@echo "Tools:"
@echo " make qr URL=... - Generate QR code for URL"
@@ -62,36 +55,25 @@ build/.exists:
@mkdir -p build/223015b build/223015c
@touch $@
# Development servers
# Development server
dev:
@./scripts/dev-server.sh
dev-kill:
@-pkill -f "python3 -m http.server" 2>/dev/null || true
@-pkill -f "marp-cli.*--server" 2>/dev/null || true
@sleep 0.5
dev-b:
@echo "Starting 223015b dev server on port $(223015b_PORT)..."
@echo "Open: http://localhost:$(223015b_PORT)"
PORT=$(223015b_PORT) npx @marp-team/marp-cli --server $(COURSE_DIR)/223015b/slides/
dev-c:
@echo "Starting 223015c dev server on port $(223015c_PORT)..."
@echo "Open: http://localhost:$(223015c_PORT)"
PORT=$(223015c_PORT) npx @marp-team/marp-cli --server $(COURSE_DIR)/223015c/slides/
# Build functions
define build_course
@echo "Building $(1)..."
@mkdir -p build/$(1)
@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
@for f in $($(1)_TERMINS); do \
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
@for f in $($(1)_KAPITEL); do \
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
echo " Building $$f..."; \
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md -o build/$(1)/$$f.html; \
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md -o build/$(1)/$$f.html; \
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
fi \
done
@./scripts/generate-index.sh $(1) build/$(1)
@@ -110,12 +92,12 @@ build: build-b build-c
define html_course
@echo "Building HTML for $(1)..."
@mkdir -p build/$(1)
@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
@for f in $($(1)_TERMINS); do \
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
@for f in $($(1)_KAPITEL); do \
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
echo " $$f.html"; \
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md -o build/$(1)/$$f.html; \
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md -o build/$(1)/$$f.html; \
fi \
done
@./scripts/generate-index.sh $(1) build/$(1)
@@ -133,10 +115,10 @@ html: html-b html-c
define pdf_course
@echo "Building PDFs for $(1)..."
@mkdir -p build/$(1)
@for f in $($(1)_TERMINS); do \
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
@for f in $($(1)_KAPITEL); do \
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
echo " $$f.pdf"; \
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
fi \
done
endef
@@ -149,6 +131,16 @@ pdf-c: build/.exists
pdf: pdf-b pdf-c
# Klausur slide extraction
klausur-b:
@./scripts/extract-klausur.sh 223015b
klausur-c:
@./scripts/extract-klausur.sh 223015c
klausur: klausur-b klausur-c
@echo "Klausurfolien slides extracted for all courses!"
# QR Code generation (uses nix-shell)
qr:
ifndef URL
@@ -174,9 +166,9 @@ ifndef COURSE
@echo "Usage: make optimize-images COURSE=223015b"
else
@echo "Optimizing images for $(COURSE)..."
@mkdir -p $(COURSE_DIR)/$(COURSE)/slides/assets-original
@nix-shell -p imagemagick --run 'for img in $(COURSE_DIR)/$(COURSE)/slides/assets/*.png $(COURSE_DIR)/$(COURSE)/slides/assets/*.jpg 2>/dev/null; do \
[ -f "$$img" ] && cp "$$img" $(COURSE_DIR)/$(COURSE)/slides/assets-original/ && \
@mkdir -p $(SLIDES_DIR)/$(COURSE)/assets-original
@nix-shell -p imagemagick --run 'for img in $(SLIDES_DIR)/$(COURSE)/assets/*.png $(SLIDES_DIR)/$(COURSE)/assets/*.jpg 2>/dev/null; do \
[ -f "$$img" ] && cp "$$img" $(SLIDES_DIR)/$(COURSE)/assets-original/ && \
magick "$$img" -resize "1920x>" -quality 85 "$$img" && echo " Optimized: $$(basename $$img)"; \
done || true'
@echo "Done! Originals in assets-original/"
@@ -187,7 +179,8 @@ HDM_DEPLOY_PATH = /home/tengo/html/hdm
build-index: build/.exists
@echo "Building root index..."
@echo '<!DOCTYPE html><html lang="de"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>HdM Vorlesungen</title><style>*{box-sizing:border-box;margin:0;padding:0}body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}.subtitle{color:#86868b;font-size:1rem}.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}.course-b .course-label{color:#1e5f8a}.course-c .course-label{color:#d63384}.course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}.course-info{font-size:.85rem;color:#86868b}.section-title{font-size:1rem;font-weight:600;color:#86868b;margin-top:2.5rem;margin-bottom:.75rem}.references{display:flex;flex-direction:column;gap:.75rem}footer{margin-top:2.5rem;padding-top:1.5rem;border-top:1px solid #e5e5e7;color:#86868b;font-size:.85rem}footer a{color:#1d1d1f;text-decoration:none}footer a:hover{text-decoration:underline}.qr-section{margin-top:2.5rem;padding:1.5rem;background:#fff;border-radius:12px;box-shadow:0 1px 3px rgba(0,0,0,0.08);text-align:center}.qr-code{width:100%;height:auto}.qr-url{margin-top:.75rem;font-size:.85rem;color:#86868b}</style></head><body><h1>HdM Vorlesungen</h1><p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p><div class="courses"><a class="course course-b" href="223015b/"><span class="course-label">223015b</span><div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class="course-info">6 Termine · Modul "Technik 1"</span></a><a class="course course-c" href="223015c/"><span class="course-label">223015c</span><div class="course-title">Grundlagen IT- und Internettechnik</div><span class="course-info">3 Termine · Modul "Technik 1"</span></a></div><h2 class="section-title">Referenzen</h2><div class="references"><a class="course" href="https://codecrispi.es/"><span class="course-label">Plattform</span><div class="course-title">Code Crispies</div><span class="course-info">Selbstlernplattform</span></a></div><div class="qr-section"><img src="qr-root.svg" alt="QR Code" class="qr-code"><p class="qr-url">https://librete.ch/hdm/</p></div><footer><a href="mailto:mail@librete.ch">Kontakt</a></footer></body></html>' > build/index.html
@mkdir -p build
@./scripts/generate-root-index.sh
# Deploy
define deploy_course
+60 -145
View File
@@ -1,182 +1,97 @@
# HdM Slides
**Modul "Technik 1"** - 1. Semester - Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart - Wintersemester 2025/26
Presentation slides for HdM Stuttgart courses, built with [Marp](https://marp.app/).
---
## Courses
## Kurse
| Code | Title | Kapitel |
|------|-------|---------|
| 223015b | Dateiformate, Schnittstellen, Speichermedien | 6 |
| 223015c | Internettechnologien | 3 |
### 223015b - Dateiformate, Schnittstellen, Speichermedien & Distributionswege
## Project Structure
| # | Datum | Thema |
|---|-------|-------|
| 0 | 19.12.2025 | Intro |
| 1 | 19.12.2025 | Grundlagen, Text & Audio |
| 2 | 09.01.2026 | Bild- & Videoformate |
| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
| 5 | TBA | Vertiefung & offene Fragen |
### 223015c - Internettechnologien
| # | Datum | Thema |
|---|-------|-------|
| 1 | 20.12.2025 | Geschichte, Grundlagen & HTML |
| 2 | 10.01.2026 | Netzwerke, Protokolle & CSS |
| 3 | 24.01.2026 | Interaktivitat & JavaScript |
**Dozent:** Michael Czechowski - mail@librete.ch
---
## Quick Start
### Mit Nix (empfohlen)
```bash
# Development shell mit allen Tools
nix develop
# Oder direkt QR-Code generieren
nix run .#qr -- "https://example.com"
nix run .#qr-slides -- 223015b
```
### Ohne Nix
```bash
npm install
make dev-b # 223015b auf Port 1312
make dev-c # 223015c auf Port 1313
slides/
├── 223015b/ # Dateiformate course
│ ├── 00-intro.md
│ ├── 01-grundlagen-text-audio.md
│ └── ...
└── 223015c/ # Internettechnik course
├── 01-geschichte-grundlagen-html.md
└── ...
scripts/ # Build scripts
build/ # Generated output (gitignored)
```
---
## Development
### Dev Server starten
```bash
make dev-b # 223015b (Dateiformate) - http://localhost:1312
make dev-c # 223015c (Internettechnik) - http://localhost:1313
# Start development server (hot reload)
make dev # Single server for all courses (port 3000)
# Access individual courses:
# 223015b: http://localhost:3000/223015b/
# 223015c: http://localhost:3000/223015c/
```
### Build
## Build
```bash
make build # Alle Kurse (HTML + PDF)
make build-b # Nur 223015b
make build-c # Nur 223015c
make html # Nur HTML
make pdf # Nur PDF
make build # Build all (HTML + PDF)
make build-b # Build 223015b only
make build-c # Build 223015c only
make html # HTML only
make pdf # PDF only
```
### Deploy
## Klausur Folien
Extract exam-relevant slides (marked with `<!-- _class: klausur -->`) into a single file:
```bash
make deploy # Alle Kurse
make deploy-b # Nur 223015b
make deploy-c # Nur 223015c
make klausur # Extract all courses
make klausur-b # 223015b only
make klausur-c # 223015c only
```
---
Output: `slides/<course>/klausurfolien.md`
The generated file includes:
- A title slide per kapitel for orientation
- All slides marked with `<!-- _class: klausur -->`
## Tools
### QR-Code Generator
```bash
make qr URL=https://example.com # Generate QR code
make qr-slides COURSE=223015b # QR for course URL
make optimize-images COURSE=223015b # Resize images
```
## Deploy
```bash
# Mit Nix
nix run .#qr -- "https://librete.ch/hdm/223015b/"
nix run .#qr -- "https://example.com" output.png
# Mit Make
make qr URL=https://example.com
make qr URL=https://example.com OUTPUT=my-qr.png
# Fur Kurse
make qr-slides COURSE=223015b
make deploy # Deploy all courses
make deploy-b # Deploy 223015b only
make deploy-c # Deploy 223015c only
```
### Bilder optimieren
## Marking Slides as Klausur-Relevant
```bash
# Mit Nix
nix run .#optimize-img -- courses/223015b/slides/assets/
# Mit Make
make optimize-images COURSE=223015b
```
---
## Projektstruktur
```
hdm/
├── courses/
│ ├── 223015b/
│ │ └── slides/
│ │ ├── 2025-12-19-termin-1-grundlagen-text-audio.md
│ │ ├── assets/
│ │ └── materials/
│ └── 223015c/
│ └── slides/
│ ├── 2025-12-20-termin-1-geschichte-grundlagen-html.md
│ └── assets/
├── scripts/
│ └── generate-index.sh
├── themes/
│ └── custom-theme.css
├── build/ # Generated output
├── flake.nix # Nix flake with tools
├── Makefile
└── package.json
```
---
## Slides erstellen
### Frontmatter
```yaml
---
marp: true
theme: uncover
paginate: true
backgroundColor: #fff
---
```
### Slide-Trennung
Add this comment block after the slide separator:
```markdown
# Slide 1
Content
---
# Slide 2
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->
More content
# Your Slide Title
Content here...
```
### Bilder
```markdown
![Alt text](./assets/image.jpg)
```
### Themes
Built-in: `default`, `gaia`, `uncover`
Custom: in `themes/` Verzeichnis
---
## License
[CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/)
The `klausur` class adds a visual indicator (diagonal stripes) during presentation.
+469
View File
@@ -0,0 +1,469 @@
<?xml version="1.0" encoding="UTF-8"?>
<quiz>
<!-- ============================================================
223015c – Grundlagen IT- und Internettechnik
40 Punkte / 40 Minuten
Michael Czechowski – HdM Stuttgart – WS 2025/26
============================================================ -->
<!-- ─── 3 pt – Von-Neumann: 5 Komponenten ─── -->
<question type="matching">
<n><text>Q1 – Von-Neumann: Komponenten zuordnen</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Ordne jeder Komponente der Von-Neumann-Architektur ihre
Funktion zu.</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).</text></generalfeedback>
<defaultgrade>3</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<shuffleanswers>true</shuffleanswers>
<answer fraction="100"><text>Rechenwerk (ALU)</text><match>Führt arithmetische und logische Operationen durch.</match></answer>
<answer fraction="100"><text>Steuerwerk</text><match>Holt, dekodiert und steuert die Ausführung von Befehlen.</match></answer>
<answer fraction="100"><text>Speicherwerk</text><match>Enthält sowohl Programme als auch Daten (Stored Program Concept).</match></answer>
<answer fraction="100"><text>Ein-/Ausgabe</text><match>Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.</match></answer>
<answer fraction="100"><text>Bus-System</text><match>Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.</match></answer>
</question>
<!-- ─── 2 pt – Von-Neumann vs Harvard: Transfer ─── -->
<question type="multichoice">
<n><text>Q2 – Von-Neumann vs. Harvard</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Ein Arduino-Mikrocontroller nutzt die <strong>Harvard-Architektur</strong>.
Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.</p>
<p><strong>Warum ist die Harvard-Architektur für Echtzeit-Anwendungen
auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn
das Smartphone diese Architektur verwenden würde?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – Speed vs. Flexibilität.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege, was getrennte Speicher für Code und Daten bedeuten.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[Harvard nutzt <strong>separate Speicher</strong> für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.]]></text></answer>
<answer fraction="0"><text><![CDATA[Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.]]></text></answer>
<answer fraction="0"><text><![CDATA[Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.]]></text></answer>
<answer fraction="0"><text><![CDATA[Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.]]></text></answer>
</question>
<!-- ─── 2 pt – Stored Program Concept Transfer ─── -->
<question type="multichoice">
<n><text>Q3 – Stored Program Concept</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem
ENIAC Programme durch <strong>Umstecken von Kabeln</strong> eingegeben
werden.</p>
<p><strong>Was konkret ermöglicht das Stored Program Concept, was
vorher nicht möglich war? Nenne zwei Beispiele.</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – Programme als Daten im Speicher = Flexibilität.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – der Kern liegt darin, dass Programme im Speicher als Daten residieren.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[Programme werden als <strong>Daten im Speicher</strong> abgelegt → z. B. Apps können installiert/gelöscht werden und <strong>Multitasking</strong> (mehrere Programme gleichzeitig) wird möglich.]]></text></answer>
<answer fraction="0"><text><![CDATA[Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.]]></text></answer>
<answer fraction="0"><text><![CDATA[Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.]]></text></answer>
<answer fraction="0"><text><![CDATA[Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.]]></text></answer>
</question>
<!-- ─── 2 pt – HTML Metadaten: Transfer ─── -->
<question type="multichoice">
<n><text>Q4 – HTML: &lt;head&gt; vs. &lt;body&gt;</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Ein Student erstellt eine Webseite und platziert <em>alles</em>
im <code>&lt;body&gt;</code> – auch den <code>&lt;title&gt;</code>
und die <code>&lt;meta name="description"&gt;</code>.</p>
<p><strong>Welche zwei konkreten Konsequenzen hat das?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>title und meta description gehören in &lt;head&gt;. Im &lt;body&gt;: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – Metadaten im Body werden nicht als solche interpretiert.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – &lt;head&gt; und &lt;body&gt; haben spezifische Funktionen.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[(1) Der Browser-Tab zeigt <strong>keinen Titel</strong> an. (2) Suchmaschinen haben <strong>keine Beschreibung</strong> für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.]]></text></answer>
<answer fraction="0"><text><![CDATA[Kein Problem – Browser ignorieren die Unterscheidung zwischen <code>&lt;head&gt;</code> und <code>&lt;body&gt;</code>.]]></text></answer>
<answer fraction="0"><text><![CDATA[(1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.]]></text></answer>
<answer fraction="0"><text><![CDATA[Nur das Fehlen von <code>&lt;meta charset&gt;</code> ist ein Problem – title und description funktionieren überall.]]></text></answer>
</question>
<!-- ─── 3 pt – Accessibility Transfer ─── -->
<question type="multichoice">
<n><text>Q5 – Barrierefreiheit: Curb-Cut-Effekt</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Der <strong>Curb-Cut-Effekt</strong> beschreibt, wie eine
barrierefreie Lösung – ursprünglich für Menschen mit Behinderung –
letztendlich <em>allen</em> zugute kommt.</p>
<p><strong>Nenne ein konkretes Web-Beispiel, das diesen Effekt
demonstriert, und erkläre, wer davon profitiert.</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.</text></generalfeedback>
<defaultgrade>3</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – Barrierefreiheit hilft allen.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege, welche barrierefreien Maßnahmen auch Menschen ohne Behinderung nutzen.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[<strong>Untertitel:</strong> Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.]]></text></answer>
<answer fraction="0"><text><![CDATA[Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.]]></text></answer>
<answer fraction="0"><text><![CDATA[Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>Dark Mode:</strong> Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.]]></text></answer>
</question>
<!-- ─── 2 pt – EAA / WCAG ─── -->
<question type="multichoice">
<n><text>Q6 – European Accessibility Act</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Der <strong>European Accessibility Act (EAA)</strong> ist seit
Juni 2025 in Kraft.</p>
<p><strong>Was bedeutet das konkret für ein deutsches
E-Commerce-Unternehmen, das eine Webseite betreibt?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – rechtliche Pflicht zur Barrierefreiheit.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – der EAA erstellt eine rechtliche Verpflichtung für bestimmte Sektoren.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[Die Webseite <strong>muss barrierefreiheitstechnisch</strong> WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.]]></text></answer>
<answer fraction="0"><text><![CDATA[Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.]]></text></answer>
<answer fraction="0"><text><![CDATA[Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.]]></text></answer>
<answer fraction="0"><text><![CDATA[Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.]]></text></answer>
</question>
<!-- ─── 3 pt – TCP/IP Schichten: Protokoll → Schicht ─── -->
<question type="matching">
<n><text>Q7 – TCP/IP: Protokoll → Schicht</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.</text></generalfeedback>
<defaultgrade>3</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<shuffleanswers>true</shuffleanswers>
<answer fraction="100"><text>HTTP</text><match>Anwendung</match></answer>
<answer fraction="100"><text>TCP</text><match>Transport</match></answer>
<answer fraction="100"><text>IP</text><match>Internet</match></answer>
<answer fraction="100"><text>Ethernet</text><match>Netzzugang</match></answer>
<answer fraction="100"><text>DNS</text><match>Anwendung</match></answer>
<answer fraction="100"><text>UDP</text><match>Transport</match></answer>
</question>
<!-- ─── 3 pt – Encapsulation: D-S-P-F ─── -->
<question type="matching">
<n><text>Q8 – Encapsulation: Dateneinheit → Schicht</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Bei der Übertragung wird eine Nachricht von Schicht zu Schicht
verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige
Schicht zu.</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.</text></generalfeedback>
<defaultgrade>3</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<shuffleanswers>true</shuffleanswers>
<answer fraction="100"><text>Daten</text><match>Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).</match></answer>
<answer fraction="100"><text>Segment</text><match>Transportschicht – Daten + Ports und Sequenznummern.</match></answer>
<answer fraction="100"><text>Paket</text><match>Internetschicht – Segment + IP-Adressen (Quelle und Ziel).</match></answer>
<answer fraction="100"><text>Frame</text><match>Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.</match></answer>
</question>
<!-- ─── 3 pt – IP vs MAC vs Port Transfer ─── -->
<question type="multichoice">
<n><text>Q9 – IP vs. MAC vs. Port: Transfer-Szenario</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in
einem anderen Land. Das Paket durchläuft mehrere Router.</p>
<p><strong>Welche der folgenden Aussagen über die Adressen auf dem
Weg ist korrekt?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.</text></generalfeedback>
<defaultgrade>3</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – nur MAC ändert sich unterwegs.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege, welche Adresse bei jedem Hop neu gesetzt wird.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[Die <strong>IP-Adresse</strong> des Servers bleibt konstant, der <strong>Port</strong> (443) ändert sich nicht – die <strong>MAC-Adresse</strong> wird an jedem Router neu gesetzt (lokal, ein Hop).]]></text></answer>
<answer fraction="0"><text><![CDATA[Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.]]></text></answer>
<answer fraction="0"><text><![CDATA[Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.]]></text></answer>
<answer fraction="0"><text><![CDATA[IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.]]></text></answer>
</question>
<!-- ─── 3 pt – 3-Way Handshake: Transfer ─── -->
<question type="multichoice">
<n><text>Q10 – TCP 3-Way-Handshake: Was passiert wäre?</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Der Client sendet ein <strong>SYN</strong> zum Server.
Das SYN-Paket geht verloren – es erreicht den Server nie.</p>
<p><strong>Was passiert als nächstes, und warum wird keine
Verbindung aufgebaut?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).</text></generalfeedback>
<defaultgrade>3</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – ohne SYN beim Server: kein SYN-ACK, kein Handshake.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege, was der Server ohne SYN tun kann.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[Der Server kennt die Anfrage nicht → sendet <strong>kein SYN-ACK</strong> → der Client erhält keine Antwort → <strong>keine Verbindung</strong>. Der Client wird das SYN nach einem Timeout erneut senden.]]></text></answer>
<answer fraction="0"><text><![CDATA[Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.]]></text></answer>
<answer fraction="0"><text><![CDATA[Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.]]></text></answer>
<answer fraction="0"><text><![CDATA[Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.]]></text></answer>
</question>
<!-- ─── 2 pt – TCP vs UDP Transfer ─── -->
<question type="multichoice">
<n><text>Q11 – TCP vs. UDP: Videostreaming</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Ein Videostreaming-Dienst sendet Daten an deinen Browser.
Ein einzelnes Paket geht verloren.</p>
<p><strong>Warum wählt der Dienst <strong>UDP</strong> statt TCP,
obwohl ein Paket verloren geht?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – bei Echtzeit ist Verzögerung ärger als Verlust.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege, was TCP bei einem verlorenen Paket tun würde.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[Bei <strong>Echtzeit</strong> ist Verzögerung schlimmer als Verlust. TCP würde das Paket <strong>erneut anfordern</strong> → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.]]></text></answer>
<answer fraction="0"><text><![CDATA[UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.]]></text></answer>
<answer fraction="0"><text><![CDATA[TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.]]></text></answer>
<answer fraction="0"><text><![CDATA[UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.]]></text></answer>
</question>
<!-- ─── 2 pt – HTTP Methoden: Transfer ─── -->
<question type="multichoice">
<n><text>Q12 – HTTP-Methoden: Szenario</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Ein Nutzer aktualisiert sein Profilbild auf einer Webseite.
Das Foto wird zum Server gesendet und das <strong>alte Bild
ersetzt</strong>.</p>
<p><strong>Welche HTTP-Methode wird für diese Operation verwendet,
und warum nicht GET?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – PUT für das Ersetzen einer Ressource.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege, was „ersetzen" in HTTP bedeutet.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[<strong>PUT</strong> – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet <em>keine</em> Daten zum Server.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>GET</strong> – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>POST</strong> – POST ist immer für das Ersetzen von Daten zuständig.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>DELETE</strong> – DELETE sendet das neue Foto und löscht gleichzeitig das alte.]]></text></answer>
</question>
<!-- ─── 2 pt – HTTP Status-Codes Transfer ─── -->
<question type="multichoice">
<n><text>Q13 – HTTP Status-Codes: Fehlerdiagnose</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Du rufst eine Webseite auf und der Browser zeigt folgende
Fehlermeldung an:</p>
<pre>HTTP/1.1 503 Service Unavailable</pre>
<p><strong>Was bedeutet dieser Code, und wer ist für die Behebung
zuständig – du oder der Betreiber der Webseite?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – 5xx = Server-Problem, nicht dein Fehler.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege, was die Ziffer „5" im Code bedeutet.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[<strong>Server-Fehler:</strong> Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim <strong>Betreiber</strong> – du kannst nur später erneut versuchen.]]></text></answer>
<answer fraction="0"><text><![CDATA[Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.]]></text></answer>
<answer fraction="0"><text><![CDATA[Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.]]></text></answer>
<answer fraction="0"><text><![CDATA[Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.]]></text></answer>
</question>
<!-- ─── 2 pt – DNS Ablauf Transfer ─── -->
<question type="multichoice">
<n><text>Q14 – DNS: Rolle im Ablauf</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Du gibst <code>https://hdm-stuttgart.de</code> in die
Adresszeile ein.</p>
<p><strong>Was passiert <em>vor</em> dem TCP-Handshake, und warum
ist dieser Schritt zwingend nötig?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – DNS vor TCP, Name → IP.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege, was TCP als Zieladresse braucht.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[<strong>DNS-Auflösung:</strong> Der Name <code>hdm-stuttgart.de</code> wird in eine <strong>IP-Adresse</strong> umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.]]></text></answer>
<answer fraction="0"><text><![CDATA[Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.]]></text></answer>
<answer fraction="0"><text><![CDATA[DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.]]></text></answer>
<answer fraction="0"><text><![CDATA[DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.]]></text></answer>
</question>
<!-- ─── 2 pt – CSS Spezifität Transfer ─── -->
<question type="multichoice">
<n><text>Q15 – CSS Spezifität: Welche Regel gewinnt?</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Gegeben folgender CSS-Code:</p>
<pre>
p { color: blue; } /* (A) */
.highlight { color: green; } /* (B) */
#main { color: red; } /* (C) */
</pre>
<p>Ein Element <code>&lt;p class="highlight" id="main"&gt;Text&lt;/p&gt;</code>
wird angezeigt.<br>
<strong>Welche Farbe zeigt der Text an, und warum?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – ID gewinnt durch höchste Spezifität.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege die Spezifitätswerte: ID > Klasse > Element.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – die ID-Regel <code>#main</code> hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die Element-Regel steht zuerst im Code und hat daher Vorrang.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – Klassen-Selektoren haben immer Vorrang vor IDs.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>Rot</strong> – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.]]></text></answer>
</question>
<!-- ─── 2 pt – Responsive Design Transfer ─── -->
<question type="multichoice">
<n><text>Q16 – Responsive Design: Mobile First</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Ein Developer schreibt folgendes CSS:</p>
<pre>
.container { background: white; }
@media (min-width: 768px) {
.container { background: blue; }
}
@media (min-width: 1024px) {
.container { background: green; }
}
</pre>
<p><strong>Welche Farbe hat <code>.container</code> bei einem
Bildschirm von 900 px Breite, und warum?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 &lt; 1024). Ergebnis: blau.</text></generalfeedback>
<defaultgrade>2</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – 768px greift, 1024px nicht.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – überlege, welche min-width-Bedingungen bei 900px erfüllt sind.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[<strong>Blau</strong> – bei 900 px greift <code>min-width: 768px</code> (900 ≥ 768), aber <code>min-width: 1024px</code> greift nicht (900 &lt; 1024).]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – die letzte Media-Query überschreibt immer alle vorherigen.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.]]></text></answer>
</question>
<!-- ─── 1 pt – Zusammen: Der Ablauf eines Klicks ─── -->
<question type="multichoice">
<n><text>Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Du gibst eine URL ein. <strong>Welche Reihenfolge der Schritte
ist korrekt?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).</text></generalfeedback>
<defaultgrade>1</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – DNS → TCP → HTTP Request → HTTP Response.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – an erster Stelle steht immer die DNS-Auflösung.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
<answer fraction="0"><text><![CDATA[(1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
<answer fraction="0"><text><![CDATA[(1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
<answer fraction="0"><text><![CDATA[(1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
</question>
<!-- ─── 1 pt – Bonusfrage: Spezifität Edge Case ─── -->
<question type="multichoice">
<n><text>Q18 – CSS: 100 Element-Selektoren vs. 1 Klasse</text></n>
<questiontext type="html">
<text><![CDATA[
<p>Es gibt zwei CSS-Regeln für ein <code>&lt;p&gt;</code>-Element:</p>
<pre>
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
.highlight { color: red; } /* 1× Klasse */
</pre>
<p>Das Element hat die Klasse <code>highlight</code>.
<strong>Welche Farbe gewinnt?</p>
]]></text>
</questiontext>
<generalfeedback type="html"><text>Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.</text></generalfeedback>
<defaultgrade>1</defaultgrade>
<penalty>0.25</penalty>
<hidden>0</hidden>
<single>true</single>
<shuffleanswers>true</shuffleanswers>
<correctfeedback type="html"><text>Genau – eine Klasse gewinnt immer gegen beliebig viele Elemente.</text></correctfeedback>
<incorrectfeedback type="html"><text>Nein – Spezifität funktioniert nicht durch Addition innerhalb einer Stelle.</text></incorrectfeedback>
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.]]></text></answer>
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.]]></text></answer>
<answer fraction="0"><text><![CDATA[Unentschieden – die Regeln haben exakt gleiche Spezifität.]]></text></answer>
</question>
</quiz>
File diff suppressed because it is too large. Load diff
+439
View File
@@ -0,0 +1,439 @@
Here is the quiz converted into a clean, readable Markdown format. I have preserved the structure, code snippets, and feedback for each question.
---
# 223015c – Grundlagen IT- und Internettechnik
**WS 2025/26 – Michael Czechowski – HdM Stuttgart**
**40 Punkte / 40 Minuten**
---
### Q1 – Von-Neumann: Komponenten zuordnen (3 pt)
**Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.**
* **Rechenwerk (ALU):** Führt arithmetische und logische Operationen durch.
* **Steuerwerk:** Holt, dekodiert und steuert die Ausführung von Befehlen.
* **Speicherwerk:** Enthält sowohl Programme als auch Daten (Stored Program Concept).
* **Ein-/Ausgabe:** Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.
* **Bus-System:** Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.
> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
---
### Q2 – Von-Neumann vs. Harvard (2 pt)
**Ein Arduino-Mikrocontroller nutzt die Harvard-Architektur. Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.**
**Warum ist die Harvard-Architektur für Echtzeit-Anwendungen auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn das Smartphone diese Architektur verwenden würde?**
* [ ] Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.
* [x] **Harvard nutzt separate Speicher für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.** ✅
* [ ] Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.
* [ ] Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.
> **Feedback:** Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.
---
### Q3 – Stored Program Concept (2 pt)
**Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem ENIAC Programme durch Umstecken von Kabeln eingegeben werden.**
**Was konkret ermöglicht das Stored Program Concept, was vorher nicht möglich war? Nenne zwei Beispiele.**
* [ ] Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.
* [ ] Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.
* [x] **Programme werden als Daten im Speicher abgelegt → z. B. Apps können installiert/gelöscht werden und Multitasking (mehrere Programme gleichzeitig) wird möglich.** ✅
* [ ] Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.
> **Feedback:** Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.
---
### Q4 – HTML: `<head>` vs. `<body>` (2 pt)
**Ein Student erstellt eine Webseite und platziert *alles* im `<body>` – auch den `<title>` und die `<meta name="description">`.**
**Welche zwei konkreten Konsequenzen hat das?**
* [ ] Kein Problem – Browser ignorieren die Unterscheidung zwischen `<head>` und `<body>`.
* [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.** ✅
* [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
* [ ] Nur das Fehlen von `<meta charset>` ist ein Problem – title und description funktionieren überall.
> **Feedback:** title und meta description gehören in `<head>`. Im `<body>`: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.
---
### Q5 – Barrierefreiheit: Curb-Cut-Effekt (3 pt)
**Der Curb-Cut-Effekt beschreibt, wie eine barrierefreie Lösung – ursprünglich für Menschen mit Behinderung – letztendlich *allen* zugute kommt.**
**Nenne ein konkretes Web-Beispiel, das diesen Effekt demonstriert, und erkläre, wer davon profitiert.**
* [ ] Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.
* [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
* [x] **Untertitel: Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.** ✅
* [ ] **Dark Mode:** Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.
> **Feedback:** Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.
---
### Q6 – European Accessibility Act (2 pt)
**Der European Accessibility Act (EAA) ist seit Juni 2025 in Kraft.**
**Was bedeutet das konkret für ein deutsches E-Commerce-Unternehmen, das eine Webseite betreibt?**
* [ ] Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.
* [ ] Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.
* [x] **Die Webseite muss barrierefreiheitstechnisch WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.** ✅
* [ ] Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.
> **Feedback:** EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.
---
### Q7 – TCP/IP: Protokoll → Schicht (3 pt)
**Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.**
* **HTTP:** Anwendung
* **DNS:** Anwendung
* **TCP:** Transport
* **UDP:** Transport
* **IP:** Internet
* **Ethernet:** Netzzugang
> **Feedback:** Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
---
### Q8 – Encapsulation: Dateneinheit → Schicht (3 pt)
**Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige Schicht zu.**
* **Daten:** Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).
* **Segment:** Transportschicht – Daten + Ports und Sequenznummern.
* **Paket:** Internetschicht – Segment + IP-Adressen (Quelle und Ziel).
* **Frame:** Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.
> **Feedback:** Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.
---
### Q9 – IP vs. MAC vs. Port: Transfer-Szenario (3 pt)
**Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in einem anderen Land. Das Paket durchläuft mehrere Router.**
**Welche der folgenden Aussagen über die Adressen auf dem Weg ist korrekt?**
* [ ] Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.
* [x] **Die IP-Adresse des Servers bleibt konstant, der Port (443) ändert sich nicht – die MAC-Adresse wird an jedem Router neu gesetzt (lokal, ein Hop).** ✅
* [ ] Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.
* [ ] IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.
> **Feedback:** IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.
---
### Q10 – TCP 3-Way-Handshake: Was passiert wäre? (3 pt)
**Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie.**
**Was passiert als nächstes, und warum wird keine Verbindung aufgebaut?**
* [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.
* [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client wird das SYN nach einem Timeout erneut senden.** ✅
* [ ] Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.
* [ ] Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.
> **Feedback:** Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).
---
### Q11 – TCP vs. UDP: Videostreaming (2 pt)
**Ein Videostreaming-Dienst sendet Daten an deinen Browser. Ein einzelnes Paket geht verloren.**
**Warum wählt der Dienst UDP statt TCP, obwohl ein Paket verloren geht?**
* [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
* [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
* [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
* [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
> **Feedback:** Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.
---
### Q12 – HTTP-Methoden: Szenario (2 pt)
**Ein Nutzer aktualisiert sein Profilbild auf einer Webseite. Das Foto wird zum Server gesendet und das *alte Bild ersetzt*.**
**Welche HTTP-Methode wird für diese Operation verwendet, und warum nicht GET?**
* [ ] **GET** – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.
* [x] **PUT – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet *keine* Daten zum Server.** ✅
* [ ] **POST** – POST ist immer für das Ersetzen von Daten zuständig.
* [ ] **DELETE** – DELETE sendet das neue Foto und löscht gleichzeitig das alte.
> **Feedback:** PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.
---
### Q13 – HTTP Status-Codes: Fehlerdiagnose (2 pt)
**Du rufst eine Webseite auf und der Browser zeigt folgende Fehlermeldung an:**
`HTTP/1.1 503 Service Unavailable`
**Was bedeutet dieser Code, und wer ist für die Behebung zuständig – du oder der Betreiber der Webseite?**
* [ ] Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.
* [ ] Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.
* [x] **Server-Fehler: Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Betreiber – du kannst nur später erneut versuchen.** ✅
* [ ] Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.
> **Feedback:** 503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.
---
### Q14 – DNS: Rolle im Ablauf (2 pt)
**Du gibst `https://hdm-stuttgart.de` in die Adresszeile ein.**
**Was passiert *vor* dem TCP-Handshake, und warum ist dieser Schritt zwingend nötig?**
* [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.
* [x] **DNS-Auflösung: Der Name `hdm-stuttgart.de` wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.** ✅
* [ ] DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.
* [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
> **Feedback:** DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.
---
### Q15 – CSS Spezifität: Welche Regel gewinnt? (2 pt)
**Gegeben folgender CSS-Code:**
```css
p { color: blue; } /* (A) */
.highlight { color: green; } /* (B) */
#main { color: red; } /* (C) */
```
**Ein Element `<p class="highlight" id="main">Text</p>` wird angezeigt.**
**Welche Farbe zeigt der Text an, und warum?**
* [ ] **Blau** – die Element-Regel steht zuerst im Code und hat daher Vorrang.
* [ ] **Grün** – Klassen-Selektoren haben immer Vorrang vor IDs.
* [x] **Rot – die ID-Regel `#main` hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).** ✅
* [ ] **Rot** – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.
> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.
---
### Q16 – Responsive Design: Mobile First (2 pt)
**Ein Developer schreibt folgendes CSS:**
```css
.container { background: white; }
@media (min-width: 768px) {
.container { background: blue; }
}
@media (min-width: 1024px) {
.container { background: green; }
}
```
**Welche Farbe hat `.container` bei einem Bildschirm von 900 px Breite, und warum?**
* [ ] **Weiß** – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.
* [ ] **Grün** – die letzte Media-Query überschreibt immer alle vorherigen.
* [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` greift nicht (900 < 1024).** ✅
* [ ] **Weiß** – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.
> **Feedback:** Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.
---
### Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs (1 pt)
**Du gibst eine URL ein. Welche Reihenfolge der Schritte ist korrekt?**
* [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
* [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
* [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
* [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
> **Feedback:** Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).
---
### Q18 – Bonusfrage: Spezifität Edge Case (1 pt)
**Es gibt zwei CSS-Regeln für ein `<p>`-Element:**
```css
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
.highlight { color: red; } /* 1× Klasse */
```
**Das Element hat die Klasse `highlight`. Welche Farbe gewinnt?**
* [ ] **Blau** – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.
* [x] **Rot – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.** ✅
* [ ] **Blau** – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.
* [ ] Unentschieden – die Regeln haben exakt gleiche Spezifität.
> **Feedback:** Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.
---
### Q19 – Von-Neumann: Der Flaschenhals (Engpass)
**Die Von-Neumann-Architektur hat einen bekannten Nachteil, den sogenannten „Von-Neumann-Flaschenhals“. Was ist damit gemeint?**
* [ ] Das Steuerwerk kann Befehle schneller verarbeiten, als das Rechenwerk sie berechnen kann.
* [x] **Die CPU ist schneller als der Datentransfer über den gemeinsamen Bus. Da Daten und Befehle denselben Bus nutzen, müssen sie nacheinander geladen werden.** ✅
* [ ] Der Speicher verliert seine Daten, wenn der Strom abgeschaltet wird, was den Startvorgang verlangsamt.
* [ ] Die Ein-/Ausgabegeräte blockieren den Prozessor dauerhaft, da sie keinen eigenen Speicher haben.
> **Feedback:** Der Flaschenhals entsteht, weil Befehle und Daten sich den gleichen Weg (Bus) teilen müssen und der Speicherzugriff langsamer ist als die CPU-Geschwindigkeit.
---
### Q20 – HTML: Encoding (Charset)
**In Q4 ging es um Metadaten. Ein weiteres wichtiges Tag im `<head>` ist `<meta charset="UTF-8">`. Was ist die konkrete Konsequenz, wenn dieses Tag fehlt oder falsch ist?**
* [ ] Die Webseite lädt gar nicht, da der Browser den Binärcode nicht interpretieren kann.
* [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole („Hieroglyphen“) dargestellt, da der Browser die falsche Zeichenkodierung rät.** ✅
* [ ] Die Seite wird langsamer, da der Browser erst alle Sprachen der Welt durchprobieren muss.
* [ ] Das CSS wird nicht geladen, da CSS zwingend UTF-8 voraussetzt.
> **Feedback:** Ohne definierte `charset` (Zeichensatz) nutzt der Browser oft einen Standard (z. B. Latin-1), was bei UTF-8-gespeicherten Dateien zu Darstellungsfehlern bei ä, ö, ü oder Emojis führt.
---
### Q21 – Barrierefreiheit: POUR-Prinzip
**Die WCAG basieren auf vier Prinzipien (POUR). Eines davon ist „Bedienbarkeit“ (Operable). Welches Szenario beschreibt eine Verletzung dieses Prinzips?**
* [ ] Der Textkontrast ist zu gering (grau auf hellgrau), sodass man ihn kaum lesen kann.
* [x] **Eine Navigation funktioniert nur per Maus (Hover), ist aber per Tastatur (Tab-Taste) nicht erreichbar.** ✅
* [ ] Der Inhalt ist in sehr komplizierter Fachsprache geschrieben, die ein Laie nicht versteht.
* [ ] Die Webseite stürzt in alten Browsern ab.
> **Feedback:** „Bedienbar“ bedeutet, dass die Schnittstelle (Buttons, Links) von jedem genutzt werden kann – also auch ohne Maus (nur Tastatur). Kontrast gehört zu „Wahrnehmbar“ (Perceivable).
---
### Q22 – Encapsulation: Die Empfänger-Seite (Decapsulation)
**In Q8 haben wir Daten verpackt. Wenn der Server das Signal empfängt, passiert das Gegenteil (Decapsulation). In welcher Reihenfolge werden die Header *entfernt*?**
* [ ] Anwendung (HTTP) → Transport (TCP) → Internet (IP) → Netzzugang (Ethernet)
* [ ] Es werden alle Header gleichzeitig entfernt, sobald die Daten im RAM liegen.
* [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
* [ ] Internet (IP) → Netzzugang (Ethernet) → Transport (TCP) → Anwendung (HTTP)
> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken (Zwiebel-Prinzip). Erst wird der Umschlag (Ethernet) geöffnet, dann das Paket (IP), dann das Segment (TCP).
---
### Q23 – Ports: Wozu genau?
**Wir wissen aus Q9, dass IP-Adressen Computer identifizieren. Wozu genau dient dann die Port-Nummer (z. B. 80 oder 443) auf dem Zielrechner?**
* [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
* [ ] Sie dient zur Verschlüsselung der Daten.
* [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver vs. Mailserver).** ✅
* [ ] Sie zeigt an, ob der Computer per WLAN oder Kabel verbunden ist.
> **Feedback:** Die IP ist wie die Hausnummer (welches Gebäude?), der Port ist wie die Türnummer oder der Name an der Klingel (wer im Haus soll das Paket bekommen? Webserver? Mailserver?).
---
### Q24 – TCP: Sequenznummern
**TCP ist zuverlässig. Ein Mechanismus dafür sind „Sequenznummern“ im Header. Welches Problem lösen diese konkret?**
* [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
* [x] **Pakete können im Internet unterschiedliche Routen nehmen und in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
* [ ] Sie zählen, wie viele Benutzer gerade gleichzeitig auf dem Server sind.
* [ ] Sie bestimmen die maximale Größe einer Datei.
> **Feedback:** Da IP-Pakete überholen können, kommen Teil 2 und Teil 3 vielleicht vor Teil 1 an. TCP sortiert sie anhand der Nummern wieder richtig. UDP macht das nicht.
---
### Q25 – HTTP Methoden: Sicherheit
**Warum sollte man niemals die GET-Methode verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?**
* [ ] GET ist langsamer als POST und Passwörter müssen schnell übertragen werden.
* [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST stehen sie im Body.** ✅
* [ ] GET erlaubt nur Zahlen, keine Buchstaben.
* [ ] GET-Anfragen werden vom Server nicht verschlüsselt, POST-Anfragen immer.
> **Feedback:** Parameter bei GET hängen an der URL (`?pw=123`). Das ist in der History und in Logs sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL ist an zu vielen Stellen sichtbar.
---
### Q26 – HTTP Status: 404 Not Found
**Du erhältst einen 404-Fehler. In Q13 (503) lag der Fehler beim Server. Wer hat beim 404-Fehler „Schuld“ bzw. wo liegt die Ursache meistens?**
* [ ] Der Server ist abgestürzt.
* [ ] Das Internet ist ausgefallen.
* [x] **Der Client (Nutzer). Es wurde eine URL angefordert, die es nicht gibt (Tippfehler oder veralteter Link).** ✅
* [ ] Der DNS-Server konnte den Namen nicht auflösen.
> **Feedback:** 4xx-Codes sind Client-Errors. Der Server funktioniert super, er sagt dir nur: „Das, was du (Client) suchst, habe ich nicht.“
---
### Q27 – CSS: `!important` vs. ID
**In Q15 hat die ID gewonnen. Nun ändern wir den Code:**
```css
#main { color: red; }
p { color: blue !important; }
```
**Welche Farbe hat das `<p id="main">` Element nun?**
* [ ] **Rot** – ID ist immer noch spezifischer als ein Element-Selektor.
* [ ] **Lila** – Die Farben mischen sich.
* [x] **Blau** – `!important` durchbricht die normale Spezifitäts-Kaskade und gewinnt sogar gegen IDs (außer die ID hat auch !important). ✅
* [ ] **Rot** – `!important` wird von modernen Browsern ignoriert.
> **Feedback:** `!important` ist die „Atombombe“ im CSS. Es überschreibt normale Spezifitätsregeln (ID, Klasse, Element). Es sollte daher sehr sparsam eingesetzt werden.
---
### Q28 – Responsive Design: Desktop First
**In Q16 nutzten wir `min-width` (Mobile First). Wie würde die Media Query aussehen, wenn wir „Desktop First“ arbeiten würden (also Standard ist Desktop, Anpassung für kleine Screens)?**
* [ ] `@media (device-width: small) { ... }`
* [ ] `@media (min-width: ...)` – das bleibt gleich, nur die Reihenfolge ändert sich.
* [x] **`@media (max-width: ...)` – Wir definieren Stile für Bildschirme, die *kleiner* als eine bestimmte Breite sind.** ✅
* [ ] `@media (mobile: true) { ... }`
> **Feedback:** Desktop First bedeutet: Das Basis-CSS ist für große Schirme. Mit `max-width` (maximale Breite) definieren wir Ausnahmen für Geräte, die schmaler sind (Tablets, Handys).
@@ -1,937 +0,0 @@
---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
<style>
:root {
--color-foreground: #1a1a2e;
--color-highlight: #1e5f8a;
--color-dimmed: #4a4a6a;
}
section.invert {
--color-foreground: #fff;
}
section {
font-size: 1.7rem;
}
h1 {
color: #1e5f8a;
}
section.invert h1 {
color: #fff;
}
h2 {
color: #1f2937;
}
pre {
background: #0f0f23;
color: #5fb3e4;
border-radius: 8px;
border-left: 3px solid #1e5f8a;
}
pre code {
background: transparent;
color: inherit;
}
code {
background: #1a1a2e;
color: #5fb3e4;
padding: 0.15em 0.4em;
border-radius: 4px;
}
a {
color: var(--color-highlight);
}
section.klausur {
background: #e3f2fd !important;
}
section.klausur footer {
display: none;
}
</style>
<!-- _class: invert -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #000 -->
![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/qr/slides-223015b.png)
---
<!-- _class: lead -->
# Termin 2 – 09.01.2026
## Bild-, Audio- & Videoformate
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/photo-comparison.png)
<!--
Links: Hochauflösend
Rechts: Stark komprimiert (JPEG-Artefakte sichtbar)
Instagram-Effekt
-->
---
# Was ist ein Bild?
**Digital = Pixelraster**
**Beispiel: 1920×1080 (Full HD)**
= 2.073.600 Pixel
**Jedes Pixel = 3 Bytes (RGB)**
2.073.600 × 3 = **6,2 MB**
**Für EIN Foto!**
<!--
Zoom auf Pixel-Ebene zeigen
Jedes Pixel = RGB-Tripel (3 Bytes)
6 MB × 10.000 Fotos = 62 GB
Smartphone-Speicher wäre schnell voll ohne Kompression
-->
---
<!-- _class: klausur -->
<!-- _footer: '' -->
# Rastergrafiken (Bitmaps)
**Aufbau:** 2D-Array von Pixeln mit Farbwerten
**Speicherbedarf (unkomprimiert):**
Breite × Höhe × Farbtiefe (in Bytes)
→ 1920×1080 × 3 Byte (RGB) = **6,2 MB**
**Farbtiefe:**
- 1 Bit = 2 Farben (S/W)
- 8 Bit = 256 Farben (Graustufen/Palette)
- 24 Bit = 16,7 Mio. Farben (True Color)
- 32 Bit = True Color + Alpha (Transparenz)
**Skalierung:** Interpolation (Nearest Neighbor, Bilinear, Bicubic)
<!--
DEFINITION: Bitmap = Bit-mapped graphics, 2D-Matrix aus Pixeln
BERECHNUNG SPEICHERBEDARF: Breite × Höhe × (Farbtiefe / 8)
BEISPIEL: 1920×1080 × 24 Bit = 1920×1080×3 = 6.220.800 Bytes ≈ 6,2 MB
FARBTIEFE erklärt:
- 1 Bit: 2^1 = 2 Farben (Schwarz/Weiß, Fax)
- 8 Bit: 2^8 = 256 Farben (GIF, Graustufen)
- 24 Bit: 2^24 = 16.777.216 Farben (True Color, RGB je 8 Bit)
- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal (Transparenz)
INTERPOLATION bei Skalierung:
- Nearest Neighbor: Schnell, pixelig (Pixel-Art)
- Bilinear: Mittelwert aus 4 Nachbarn (Standard)
- Bicubic: 16 Nachbarn, glatter (Photoshop-Standard)
- Lanczos: Beste Qualität, rechenintensiv
PRÜFUNGSRELEVANT: Speicherberechnung, Farbtiefe-Tabelle, warum Vergrößern problematisch
-->
---
<!-- _class: klausur -->
<!-- _footer: '' -->
# Vektorgrafiken
**Speicherung als geometrische Primitive:**
- Pfade (Bézierkurven mit Kontrollpunkten)
- Grundformen (Rechteck, Ellipse, Polygon)
- Text (Glyphen als Outlines)
**SVG-Beispiel:**
`<circle cx="50" cy="50" r="40" fill="#ff0000"/>`
→ 3 Parameter statt 5.027 Pixel (r=40)
**Rendering-Pipeline:**
Vektordaten → Rasterisierung → Framebuffer → Display
**Auflösungsunabhängig:** Gleiche Datei für Icon (32px) und Plakat (3m)
<!--
PRIMITIVE: Grundbausteine der Vektorgrafik
- Pfade: Sequenz von Punkten, verbunden durch Linien/Kurven
- Bézierkurven: Quadratisch (3 Kontrollpunkte), Kubisch (4 Kontrollpunkte)
- Formen: Rechteck, Ellipse, Polygon (intern als Pfade)
SVG-SYNTAX Beispiele:
- <rect x="0" y="0" width="100" height="50"/>
- <circle cx="50" cy="50" r="25"/>
- <path d="M 0 0 L 100 100"/> (MoveTo, LineTo)
BERECHNUNG: Kreis mit r=40 → Fläche = π×40² ≈ 5.027 Pixel vs. 3 Parameter
RENDERING-PIPELINE: Vector → Tessellation → Rasterization → Framebuffer
FORMATE:
- SVG: XML-basiert, Web-Standard, editierbar
- PDF: Seiten-Beschreibungssprache, Vektoren + Raster gemischt
- AI/EPS: Adobe-proprietär, Druckvorstufe
PRÜFUNGSRELEVANT: Warum Vektoren skalierbar, SVG-Grundsyntax, Rendering-Pipeline
-->
---
<!-- _class: klausur -->
<!-- _footer: '' -->
# Raster vs. Vektor: Entscheidungskriterien
| Kriterium | Raster | Vektor |
|---|---|---|
| **Speicherung** | Pixelmatrix | Geometrie + Attribute |
| **Skalierung** | Qualitätsverlust | Verlustfrei |
| **Komplexität** | O(Breite × Höhe) | O(Anzahl Objekte) |
| **Bearbeitung** | Pixelbasiert | Objektbasiert |
**Wann Raster?** Fotos, Texturen, komplexe Farbverläufe
**Wann Vektor?** Logos, Icons, Typografie, technische Zeichnungen
**Konvertierung:**
- Raster → Vektor: Tracing (verlustbehaftet, approximiert)
- Vektor → Raster: Rasterisierung (exakt, aber auflösungsgebunden)
<!--
KOMPLEXITÄT erklärt:
- Raster O(w×h): Speicher wächst mit Pixelanzahl
- Vektor O(n): Speicher wächst mit Objektanzahl
BEISPIEL: Foto einer Wiese
- Raster: 1920×1080 = 2 Mio. Pixel, komprimiert ~500 KB
- Vektor: Jeder Grashalm ein Pfad → Millionen Objekte, unkomprimierbar
KONVERTIERUNG:
- Raster→Vektor (Tracing): Kantenerkennung, verlustbehaftet
- Tools: Potrace (Open Source), Adobe Live Trace, Inkscape
- Funktioniert gut: Logos, Zeichnungen, Text
- Funktioniert schlecht: Fotos, Farbverläufe
- Vektor→Raster (Rasterisierung): Exakt, aber Auflösung fixiert
- Jeder Bildschirm macht das (GPU)
- Export: "Auflösung" wählen = Ziel-Pixelgröße
ENTSCHEIDUNGSBAUM:
- Foto/Screenshot? → Raster
- Logo/Icon/Diagramm? → Vektor
- Druckvorlage? → Vektor (Auflösungsunabhängig)
- Web-Animation? → SVG (Vektor) oder Video (Raster)
PRÜFUNGSRELEVANT: Wann welches Format, Konvertierungsrichtungen und deren Eigenschaften
-->
---
# Lossless: PNG
**PNG = Portable Network Graphics (1996)**
**Funktionsweise:**
- Vorhersage (Pixel ähneln Nachbarn)
- Differenz-Encoding
- DEFLATE-Algorithmus (wie ZIP)
**Kompression:** 20-50% Ersparnis
**Gut für:** Screenshots, Logos, Text
**Schlecht für:** Fotos
<!--
PNG wurde entwickelt als GIF-Alternative (Patent-Probleme)
Lossless: Originaldaten bleiben erhalten
Transparenz: Alpha-Kanal (sanfte Übergänge)
DEFLATE: Gleicher Algorithmus wie ZIP
-->
---
# Lossy: JPEG
**JPEG = Joint Photographic Experts Group (1992)**
**Eigenschaften:**
- Lossy Kompression
- 90%+ Platzersparnis möglich
- Artefakte bei hoher Kompression
**6 MB → 500 KB** (typisch)
<!--
JPEG-Norm beschreibt nur Kompression, nicht Speicherformat
JFIF = JPEG File Interchange Format (das eigentliche Dateiformat)
Dateierweiterungen: .jpg, .jpeg, .jfif (alle gleich)
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/jpeg-artifacts.png)
<!--
Beispiel: Stark komprimiertes JPEG
Blocking (8×8-Blöcke sichtbar)
Ringing (Geister um Kanten)
Color Banding (Verläufe "treppig")
-->
---
# Wie funktioniert JPEG? (1/2)
**Schritt 1: RGB → YCbCr**
- Y = Helligkeit (Luminanz)
- Cb/Cr = Farbe (Chrominanz)
**Warum?** Menschen sehen Helligkeit besser als Farbe
**Schritt 2: Chroma Subsampling**
Farbauflösung reduzieren (4:2:0)
→ 50% Datenmenge weg, kaum sichtbar
<!--
YCbCr = Farbraum-Konversion
Y = Brightness, Cb = Blue-Yellow, Cr = Red-Green
4:2:0 Subsampling: Farbe nur jedes 2. Pixel horizontal & vertikal
Auge merkt's kaum, weil Helligkeitssehen dominiert
-->
---
# Wie funktioniert JPEG? (2/2)
**Schritt 3: DCT (Discrete Cosine Transform)**
Bild in 8×8-Blöcke → Frequenzspektrum
**Schritt 4: Quantisierung**
Hohe Frequenzen (Details) stark reduzieren
→ **Hier passiert Datenverlust!**
**Schritt 5: Huffman-Coding**
Lossless-Kompression der Restdaten
<!--
DCT: Ähnlich wie FFT bei Audio
8×8 Blöcke: Warum JPEG "blocky" wird bei hoher Kompression
Quantisierung: Quality-Schieberegler steuert genau das
Huffman: Finale Effizienz (wie bei MP3)
-->
---
# JPEG Quality
| Quality | Dateigröße | Artefakte |
|---------|------------|-----------|
| **100** | ≈2-3 MB | Kaum |
| **85-90** | ≈200-400 KB | Minimal |
| **50** | ≈100 KB | Sichtbar |
**Sweet Spot: 85-90**
10x Kompression, für Menschen kaum unterscheidbar
<!--
Quality 100 = Minimum Compression (nicht lossless!)
Quality 85-90 = Standard für Web
Quality 50 = Sichtbare Artefakte (Blocking, Ringing)
Photoshop "Save for Web": Standard ist 60
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/gif-animation.png)
<!--
GIF-Animation (z.B. Meme)
256 Farben, aber Animationen möglich
-->
---
# Die GIF-Geschichte
**GIF = Graphics Interchange Format (1987)**
CompuServe (US-Online-Dienst)
**Features:**
- 256 Farben max (8-bit Palette)
- Lossless (für Palette)
- Animationen!
**1994 Twist:** Unisys hält Patent auf LZW-Kompression
→ Fordert Lizenzgebühren
→ **"Burn All GIFs!" Kampagne**
<!--
CompuServe: Früher Online-Dienst (1969-2009)
LZW = Lempel-Ziv-Welch Compression
Unisys Patent-Trolling: Erst Jahre nach GIF-Einführung
Community-Reaktion: Boykott, Suche nach Alternative
Ergebnis: PNG wurde entwickelt (1996)
-->
---
# PNG vs. GIF
**GIF:**
✓ Animationen
✓ Breite Unterstützung
❌ Nur 256 Farben
❌ Patent-Probleme (bis 2003)
**PNG:**
✓ Millionen Farben
✓ Alpha-Transparenz
✓ Patent-frei
❌ Keine Animationen (bis APNG, 2004)
**Ergebnis:** PNG für Grafiken, GIF für Memes!
<!--
APNG = Animated PNG (Firefox, Safari support)
WebP (Google, 2010): Animationen + bessere Kompression
GIF überlebte kulturell (Meme-Format)
"GIF" Aussprache: "Jif" vs. "Gif" – ewiger Streit
-->
---
# WebP & AVIF
**WebP (Google, 2010):**
- Lossy UND Lossless
- Animationen
- 25-35% kleiner als JPEG
**AVIF (2019):**
- Basiert auf AV1-Video-Codec
- 50% kleiner als JPEG
- HDR-Unterstützung
- Patent-frei
<!--
WebP: Von Google entwickelt, deshalb Skepsis
AVIF: Alliance for Open Media (Google, Netflix, Amazon, Mozilla...)
Browser-Support 2024: WebP fast überall, AVIF wachsend
JPEG bleibt dominant (Kompatibilität!)
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/instagram-quality-loss.png)
<!--
Vorher/Nachher: Hochauflösend vs. Instagram-Upload
Sichtbare Qualitätsverluste
-->
---
# Warum Instagram eure Fotos "ruiniert"
**Upload-Pipeline:**
1. Dein Foto: 12 MP, 8 MB
2. Instagram skaliert: max. 1080px
3. Re-Kompression: JPEG Quality ~75
4. Endgröße: 200-400 KB
**Warum?**
- Speicherkosten (Milliarden Fotos!)
- Ladezeiten (Mobile)
- Bandbreite (günstiger)
<!--
Instagram ist keine Kunstgalerie
Optimiert für Geschwindigkeit, nicht Qualität
Facebook macht dasselbe
Lösung: Portfolio-Websites (eigene Kontrolle)
-->
---
![bg contain right:25%](./assets/qr/squoosh.png)
# Hands-On: Kompression vergleichen
**Aufgabe (40 Min):**
1. Hochauflösendes Foto (eigenes oder CC)
2. Exportiere:
- PNG
- JPEG Q100, Q85, Q50
- WebP (optional)
3. Tool: **[Squoosh.app](https://squoosh.app)** (Google-Tool)
4. Vergleiche: Dateigrößen, sichtbare Unterschiede
5. Wo werden Artefakte sichtbar?
<!--
Squoosh.app: Browser-basiert, keine Installation
Side-by-Side-Vergleich mit Zoom
Verschiedene Codecs testen
Studis sollen selbst "Sweet Spot" finden
-->
---
<!-- _class: lead -->
# Teil 2: Video
## Kompression & Codecs
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/netflix-4k.png)
<!--
Netflix 4K-Streaming
Unmöglich ohne moderne Codecs
-->
---
# Das Problem: Videos sind RIIIIIIIESIG
**1 Minute 4K-Video (3840×2160):**
- 30 fps (Bilder/Sekunde)
- Jedes Bild: 24,8 MB (unkomprimiert)
**Rechnung:**
30 × 24,8 MB = **744 MB/Sekunde**
× 60 Sekunden = **44,6 GB/Minute**
**2-Stunden-Film: 5,3 TB!**
<!--
4K = 3840×2160 Pixel = 8,3 Megapixel pro Frame
30 fps = Standard, Kino = 24 fps, Gaming = 60+ fps
Ohne Kompression: Unmöglich zu streamen oder speichern
-->
---
# Container: Das Dateiformat
**Was ist ein Container?**
Das Dateiformat – eine "Box", die verschiedene Streams zusammenpackt:
- Video-Stream, Audio-Stream(s), Untertitel, Metadaten
**Gängige Container:**
- **MP4** (.mp4) – Web, Streaming
- **MKV** (.mkv) – Archiv, viele Streams
- **AVI** (.avi) – Legacy (veraltet)
- **MOV** (.mov) – Apple-Ökosystem
<!--
Container = Verpackung, nicht der Inhalt
Ein MP4 sagt nichts über die Qualität aus
MKV kann beliebig viele Audio/Untertitel-Spuren haben
-->
---
# Codec: Der Kompressionsalgorithmus
**Was ist ein Codec?** (Coder/Decoder)
Entscheidet, WIE Video/Audio komprimiert wird
**Video-Codecs:**
| Codec | Jahr | Verbreitung |
|-------|------|-------------|
| H.264/AVC | 2003 | Universell, überall |
| H.265/HEVC | 2013 | 4K, effizient, Lizenzen |
| VP9 | 2013 | YouTube, Google |
| AV1 | 2018 | Zukunft, lizenzfrei |
**Audio-Codecs:** AAC, MP3, Opus, FLAC
<!--
H.264 = De-facto-Standard seit 20 Jahren
H.265 = 50% kleinere Dateien, aber teure Lizenzen
AV1 = Open Source, Netflix/YouTube pushen es
-->
---
# Container + Codec = Video
**Das Zusammenspiel:**
```
┌─────────────────────────────┐
│ Container (z.B. MP4) │
│ ┌────────────────────────┐ │
│ │ Video-Stream (H.264) │ │
│ ├────────────────────────┤ │
│ │ Audio-Stream (AAC) │ │
│ ├────────────────────────┤ │
│ │ Untertitel (SRT) │ │
│ └────────────────────────┘ │
└─────────────────────────────┘
```
**Häufiger Irrtum:** "Das ist eine MP4-Datei"
→ Sagt nichts über den Codec aus!
<!--
Container ≠ Codec (häufiges Missverständnis!)
MP4 ist KEIN Codec, sondern Container
Ein MP4 kann H.264, H.265 oder AV1 enthalten
Prüfen mit: MediaInfo, ffprobe
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/container-codec-diagram.png)
<!--
Diagramm: Container mit verschiedenen Streams
Video-Track (H.264)
Audio-Track (AAC)
Untertitel-Track (SRT)
Metadaten (Titel, Künstler, etc.)
-->
---
# Video-Kompression: Drei Prinzipien
**1. Spatial Compression (Intra-Frame)**
Jedes Bild einzeln (wie JPEG)
→ I-Frames
**2. Temporal Compression (Inter-Frame)**
Nur Änderungen zwischen Bildern
→ P-Frames, B-Frames
**3. Motion Compensation**
"Ball bewegt sich von A nach B"
<!--
Spatial: Innerhalb eines Bildes (JPEG-ähnlich)
Temporal: Zwischen Bildern (zeitliche Redundanz)
Motion Compensation: Intelligente Vorhersage
→ 90%+ Effizienz durch temporale Kompression
-->
---
# I-Frames, P-Frames, B-Frames
**I-Frame (Intra):**
Vollständiges Bild (wie JPEG)
Groß, aber unabhängig
**P-Frame (Predicted):**
Referenziert vorherige Frames
Viel kleiner
**B-Frame (Bi-directional):**
Referenziert vorherige UND zukünftige Frames
Am effizientesten
**GOP:** I - B - B - P - B - B - P - B - B - I
<!--
GOP = Group of Pictures (typisch 12-15 Frames)
I-Frame: Alle 1-2 Sekunden nötig (für Seeking)
P-Frame: "Pixel X bewegt sich 5px rechts"
B-Frame: Komplex, aber beste Kompression
Wenn du vorspulst: Sucht nach nächstem I-Frame
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/ipb-compression-canon.jpg)
<!--
Visualisierung: I/P/B-Frame-Abhängigkeiten
I-Frame = Vollbild (Keyframe), P/B-Frames speichern nur Unterschiede
Quelle: https://www.canon.com.hk/cpx/en/technical/va_EOS_Movie_Compression_Options_All_I_and_IPB.html
-->
---
# H.264: Der König
**H.264 / AVC (2003)**
**Warum dominant?**
✓ Exzellente Kompression (100:1 möglich)
✓ Hardware-Support (jedes Gerät seit ~2010)
✓ YouTube, Netflix, Blu-ray – alles H.264
**Features:**
- Variable Block-Größen (16×16 bis 4×4)
- Deblocking-Filter
- CABAC-Coding
<!--
AVC = Advanced Video Coding
MPEG-4 Part 10 = H.264 (gleicher Standard)
Revolutionierte Video-Streaming
Hardware-Decoder in CPUs/GPUs → Batterie-schonend
CABAC = Context-Adaptive Binary Arithmetic Coding
-->
---
# Das Patent-Problem
**H.264 ist NICHT frei!**
**MPEG-LA (Patent Pool):**
- 2.000+ Patente von ~30 Unternehmen
- Apple, Microsoft, Sony, Panasonic...
**Lizenzgebühren:**
- Hardware-Decoder: $0,20/Einheit
- Content-Distribution: Kostenlos für "Internet Broadcast"
**Problem:** Open-Source-Projekte in Grauzone
<!--
MPEG-LA = Licensing Authority
Firefox weigerte sich lange, H.264 zu supporten (Patent-Gründe)
Chromium musste extern linken
Patent-Pool: Firmen teilen Patente, gemeinsame Lizenzierung
"Free to View" Klausel: YouTube etc. kostenlos
-->
---
# H.265 / HEVC
**H.265 (2013):**
50% bessere Kompression als H.264
**ABER:** Patent-Desaster
**Drei (!) konkurrierende Patent-Pools:**
- MPEG-LA
- HEVC Advance
- Velos Media
→ Viele bleiben bei H.264 oder suchen Alternativen
<!--
HEVC = High Efficiency Video Coding
Technisch überlegen, aber juristisch Albtraum
Apple nutzt HEVC (iPhone-Videos)
Netflix zögert wegen Lizenzkosten
Fragmentierung verzögert Adoption
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/youtube-vp9.png)
<!--
YouTube VP9-Logo
Google's Patent-freie Alternative
-->
---
# VP9: Googles Antwort
**VP9 (2013):**
Entwickelt von Google (On2-Akquisition)
**Eigenschaften:**
✓ Ähnlich H.265-Kompression
✓ KOSTENLOS, patent-frei (laut Google)
✓ YouTube nutzt VP9 für 4K
**Nachteile:**
❌ Hardware-Support langsam
❌ Höherer CPU-Aufwand
❌ Nicht universell wie H.264
<!--
On2 Technologies: Gekauft 2010 für $133M
VP8 → VP9 → AV1 (Evolution)
YouTube forciert VP9: 4K-Videos nur VP9/AV1
Hardware-Decoder erst ab ~2016 (langsame Adoption)
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/av1-logo.png)
<!--
AV1-Logo
Alliance for Open Media
-->
---
# AV1: Die Open-Source-Revolution
**AV1 (2018):**
Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
**Ziel:** Patent-freier, moderner Codec
**Features:**
✓ 30% besser als H.265
✓ Royalty-free, Open Source
✓ 8K, HDR, hohe Frame-Rates
**Stand 2025:**
YouTube, Netflix nutzen AV1 für 4K/8K
<!--
AOM = Alliance for Open Media (2015 gegründet)
Alle Big-Tech-Player vereint (historisch!)
"Fuck you" an Patent-Mafia
Problem: Encoding SEHR langsam (10-100x vs. H.264)
Hardware-Encoder kommen (ab 2020er-GPUs)
-->
---
# Adaptive Bitrate Streaming
**Problem:** Internet-Geschwindigkeit variiert
**Lösung:** Mehrere Qualitäten parallel
**MPEG-DASH / HLS:**
- 4K (20 Mbps)
- 1080p (5 Mbps)
- 720p (2,5 Mbps)
- 480p (1 Mbps)
- 240p (0,5 Mbps)
Segmente: 2-10 Sekunden (Player wählt dynamisch)
<!--
DASH = Dynamic Adaptive Streaming over HTTP
HLS = HTTP Live Streaming (Apple)
Beide ähnlich, aber inkompatibel
Manifest-Datei: Liste aller Qualitäten
Player misst Bandbreite, wechselt live
→ Warum Netflix plötzlich pixelig wird
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/streaming-quality-switch.png)
<!--
Visualisierung: Qualitätswechsel während Playback
Bandbreite schwankt → Player reagiert
-->
---
# Container im Detail
**MP4:** Standard für Web/Mobile, DRM-fähig (H.264, H.265, AV1)
**MKV:** Open Source, beliebig viele Spuren (fast jeder Codec)
**WebM:** Google/Web-optimiert (nur VP9/AV1 + Opus/Vorbis)
<!--
MP4 = MPEG-4 Part 14 (ISO-Standard)
Matroska = Russisch: Matrjoschka (Puppen ineinander)
WebM = Subset von Matroska (HTML5-Video)
MKV vs. MP4: Offenheit vs. Kompatibilität
-->
---
# Hands-On: Video analysieren
**Aufgabe (40 Min):**
**Tools:**
- Desktop: FFmpeg, HandBrake, [MediaInfo](https://mediaarea.net/MediaInfoOnline)
- Browser: [Squoosh.app](https://squoosh.app) (Bilder), [MediaInfo Online](https://mediaarea.net/MediaInfoOnline)
- iOS/Android: MediaInfo App, VLC
1. Download: CC-Video (Big Buck Bunny, ~1 Min)
2. Analysiere: Container, Codec, Bitrate, Auflösung
3. Konvertiere: H.264 vs. H.265 (gleiche Qualität)
4. Vergleiche: Größen, Encoding-Zeit
<!--
Big Buck Bunny: Open-Source-Film (Blender Foundation)
FFmpeg: Swiss Army Knife für Video
HandBrake: GUI für FFmpeg (einfacher)
MediaInfo: Detaillierte Datei-Analyse
Encoding-Zeit: H.265 deutlich langsamer als H.264
-->
---
<!-- _class: lead -->
# Fragen & Diskussion
**Kontakt:** mail@librete.ch
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
---
# Lizenz & Attribution
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
- Erlaubt Teilen & Anpassen mit Namensnennung
- Adaptionen müssen unter gleicher Lizenz geteilt werden
Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
File diff suppressed because it is too large. Load diff
File diff suppressed because it is too large. Load diff
File diff suppressed because it is too large. Load diff
+4 -99
View File
@@ -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,114 +9,19 @@
outputs = { self, nixpkgs, flake-utils }:
flake-utils.lib.eachDefaultSystem (system:
let
pkgs = nixpkgs.legacyPackages.${system};
# 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
];
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;
};
}
);
}
+3 -2
View File
@@ -3,13 +3,14 @@
"version": "1.0.0",
"description": "HdM Stuttgart - Lecture Slides (Marp)",
"scripts": {
"dev:b": "PORT=1312 marp --server --allow-local-files courses/223015b/slides/",
"dev:c": "PORT=1313 marp --server --allow-local-files courses/223015c/slides/",
"dev": "PORT=3000 marp --server --allow-local-files slides/",
"build": "make build",
"build:b": "make build-b",
"build:c": "make build-c",
"pdf": "make pdf",
"html": "make html",
"klausur": "make klausur",
"deploy": "make deploy",
"test": "echo \"No tests specified\" && exit 0"
},
"keywords": ["marp", "slides", "hdm", "lectures"],
+22 -75
View File
@@ -1,106 +1,53 @@
#!/usr/bin/env bash
# Development server script for HdM slides
# Starts index server + marp servers for each course
# Simplified development server for HdM slides
# Starts single Marp server for all courses
set -e
# Configuration
INDEX_PORT=1310
COURSE_B_PORT=1311
COURSE_C_PORT=1312
COURSE_DIR="courses"
DEV_INDEX_DIR=".dev-index"
SLIDES_DIR="slides"
DEV_PORT=3000
# Colors
RED='\033[0;31m'
GREEN='\033[0;32m'
BLUE='\033[0;34m'
RED='\033[0;31m'
NC='\033[0m' # No Color
# Cleanup function
cleanup() {
echo -e "\n${RED}Shutting down servers...${NC}"
kill $PID_INDEX $PID_B $PID_C 2>/dev/null || true
echo -e "\n${RED}Shutting down dev server...${NC}"
pkill -f "marp-cli.*--server" 2>/dev/null || true
exit 0
}
# Kill existing processes on our ports
# Kill existing processes on our port
kill_existing() {
echo -e "${BLUE}Cleaning up existing processes...${NC}"
# Kill marp processes first
pkill -9 -f "marp-cli" 2>/dev/null || true
pkill -f "python3 -m http.server" 2>/dev/null || true
# Kill ports including marp's WebSocket ports (37717-37720 range)
fuser -k $INDEX_PORT/tcp $COURSE_B_PORT/tcp $COURSE_C_PORT/tcp 2>/dev/null || true
fuser -k 37717/tcp 37718/tcp 37719/tcp 37720/tcp 2>/dev/null || true
sleep 2
}
# Generate dev index
generate_index() {
mkdir -p "$DEV_INDEX_DIR"
cat > "$DEV_INDEX_DIR/index.html" << 'EOF'
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>HdM Slides - Dev</title>
<style>
*{box-sizing:border-box;margin:0;padding:0}
body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}
h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}
.subtitle{color:#86868b;font-size:1rem}
.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}
a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}
a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}
.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}
.course-b .course-label{color:#1e5f8a}
.course-c .course-label{color:#d63384}
.course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}
.course-info{font-size:.85rem;color:#86868b}
</style>
</head>
<body>
<h1>HdM Slides</h1>
<p class="subtitle">Development Server</p>
<div class="courses">
EOF
echo " <a class=\"course course-b\" href=\"http://localhost:$COURSE_B_PORT\"><span class=\"course-label\">223015b</span><div class=\"course-title\">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class=\"course-info\">Port $COURSE_B_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
echo " <a class=\"course course-c\" href=\"http://localhost:$COURSE_C_PORT\"><span class=\"course-label\">223015c</span><div class=\"course-title\">Grundlagen IT- und Internettechnik</div><span class=\"course-info\">Port $COURSE_C_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
cat >> "$DEV_INDEX_DIR/index.html" << 'EOF'
</div>
</body>
</html>
EOF
fuser -k $DEV_PORT/tcp 2>/dev/null || true
sleep 1
}
# Main
trap cleanup SIGINT SIGTERM
kill_existing
generate_index
echo -e "${GREEN}Starting development servers...${NC}"
echo -e "${GREEN}Starting development server...${NC}"
echo ""
echo -e " Index: ${BLUE}http://localhost:$INDEX_PORT${NC}"
echo -e " 223015b: ${BLUE}http://localhost:$COURSE_B_PORT${NC}"
echo -e " 223015c: ${BLUE}http://localhost:$COURSE_C_PORT${NC}"
echo -e " Server: ${BLUE}http://localhost:$DEV_PORT${NC}"
echo -e " Slides: ${BLUE}$SLIDES_DIR/${NC}"
echo ""
echo -e "Press ${RED}Ctrl+C${NC} to stop all servers"
echo -e "Available courses:"
echo -e " 223015b: ${BLUE}http://localhost:$DEV_PORT/223015b/${NC}"
echo -e " 223015c: ${BLUE}http://localhost:$DEV_PORT/223015c/${NC}"
echo ""
echo -e "Press ${RED}Ctrl+C${NC} to stop the server"
echo ""
# Start servers
python3 -m http.server $INDEX_PORT --directory "$DEV_INDEX_DIR" &
PID_INDEX=$!
# Start single Marp server for all slides
PORT=$DEV_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/"
PORT=$COURSE_B_PORT npx @marp-team/marp-cli --server "$COURSE_DIR/223015b/slides/" &
PID_B=$!
sleep 3 # Stagger starts to avoid WebSocket port collision
PORT=$COURSE_C_PORT npx @marp-team/marp-cli --server "$COURSE_DIR/223015c/slides/" &
PID_C=$!
# Wait for any process to exit
wait
# Wait for process to exit
wait
+112
View File
@@ -0,0 +1,112 @@
#!/usr/bin/env bash
# Extract klausur-relevant slides from all kapitel
# Usage: ./extract-klausur.sh <course_id>
# Output: slides/<course>/klausurfolien.md
set -e
COURSE="${1:-223015b}"
SLIDES_DIR="slides/$COURSE"
OUTPUT_FILE="$SLIDES_DIR/klausurfolien.md"
# Find the first kapitel file (00-intro.md or 01-*.md) to copy styles from
FIRST_KAPITEL=$(ls "$SLIDES_DIR"/00-intro.md "$SLIDES_DIR"/01-*.md 2>/dev/null | head -1)
if [[ -z "$FIRST_KAPITEL" ]]; then
echo "Error: No 00-intro.md or 01-*.md file found in $SLIDES_DIR"
exit 1
fi
echo "Extracting klausur slides for $COURSE..."
# Extract frontmatter and styles (everything up to first <!-- _class: line after style block)
# This gets the YAML frontmatter + <style> block
awk '
BEGIN { in_frontmatter = 0; in_style = 0; done = 0 }
/^---$/ && !in_frontmatter { in_frontmatter = 1; print; next }
/^---$/ && in_frontmatter && !in_style { in_frontmatter = 0; print; next }
in_frontmatter { print; next }
/<style>/ { in_style = 1; print; next }
/<\/style>/ { in_style = 0; print; print ""; done = 1; next }
in_style { print; next }
done { exit }
' "$FIRST_KAPITEL" > "$OUTPUT_FILE"
# Add warning comment
cat >> "$OUTPUT_FILE" << 'EOF'
<!--
╔═══════════════════════════════════════════════════════════════════╗
║ AUTO-GENERATED FILE - DO NOT EDIT MANUALLY ║
║ ║
║ This file is generated by: make klausur ║
║ Source: scripts/extract-klausur.sh ║
║ ║
║ To update, edit the source slides and re-run make klausur ║
╚═══════════════════════════════════════════════════════════════════╝
-->
EOF
# Extract and copy the cover slide (first slide after frontmatter/styles, up to first ---)
awk '
BEGIN { past_style = 0; in_cover = 0; printed = 0 }
/<\/style>/ { past_style = 1; next }
past_style && !in_cover && /^[^[:space:]]/ { in_cover = 1 }
in_cover && /^---$/ { print "---\n"; exit }
in_cover { print }
' "$FIRST_KAPITEL" >> "$OUTPUT_FILE"
# Process each kapitel file in order - extract klausur slides only
for md_file in $(ls "$SLIDES_DIR"/[0-9][0-9]-*.md 2>/dev/null | grep -v klausurfolien | sort); do
filename=$(basename "$md_file")
kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
# Skip intro (kapitel 0)
if [[ "$kapitel_num" == "0" ]] || [[ -z "$kapitel_num" ]]; then
continue
fi
# Check if file has any klausur slides
if ! grep -q '<!-- _class: klausur -->' "$md_file"; then
continue
fi
echo " Processing Kapitel $kapitel_num..."
# Extract klausur slides, hide header/footer, convert * to - bullets
awk '
/<!-- _class: klausur -->/ {
in_klausur = 1
# Add header/footer hiding
print "<!-- _header: \"\" -->"
print "<!-- _footer: \"\" -->"
print ""
next
}
in_klausur && /^---$/ {
print "\n---\n"
in_klausur = 0
next
}
in_klausur {
# Skip marp directives (we add our own)
if (/<!-- _header:/ || /<!-- _footer:/ || /<!-- _backgroundColor:/) next
# Convert * bullets to - bullets (avoid fragments)
gsub(/^\* /, "- ")
gsub(/^ \* /, " - ")
gsub(/^ \* /, " - ")
print
}
' "$md_file" >> "$OUTPUT_FILE"
done
# Remove trailing --- and empty lines
perl -i -0777 -pe 's/\n*---\n*$/\n/' "$OUTPUT_FILE"
# Count slides
slide_count=$(grep -c '^---$' "$OUTPUT_FILE" 2>/dev/null || echo "0")
echo ""
echo "Generated: $OUTPUT_FILE"
echo "Total slides: $slide_count"
+150 -44
View File
@@ -41,6 +41,16 @@ TOPIC_MAP["vertiefung-offene-fragen"]="Vertiefung & Offene Fragen"
TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
TOPIC_MAP["klausurfragen"]="Klausurfragen"
# Configure which topics should appear disabled per course
# Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)
declare -A DISABLED_FULL
declare -A DISABLED_BUTTONS
# For course B: chapters 3,4,5 should be fully disabled
DISABLED_FULL["223015b"]="speichermedien-schnittstellen distribution-apis-zukunft vertiefung-offene-fragen"
# For course C: chapter 3 should keep link clickable but buttons disabled
DISABLED_BUTTONS["223015c"]="interaktivitaet-javascript"
cat > "$BUILD_DIR/index.html" << HEADER
<!DOCTYPE html>
@@ -61,6 +71,15 @@ cat > "$BUILD_DIR/index.html" << HEADER
line-height: 1.5;
}
header { margin-bottom: 2rem; }
.breadcrumb {
margin-bottom: 1rem;
font-size: 0.85rem;
}
.breadcrumb a {
color: #86868b;
text-decoration: none;
}
.breadcrumb a:hover { text-decoration: underline; }
h1 {
font-size: 1.75rem;
font-weight: 600;
@@ -68,6 +87,12 @@ cat > "$BUILD_DIR/index.html" << HEADER
margin-bottom: 0.5rem;
color: $ACCENT_COLOR;
}
.course-heading {
font-size: 1.25rem;
font-weight: 500;
color: #1d1d1f;
margin-bottom: 0.25rem;
}
.subtitle {
color: #86868b;
font-size: 0.95rem;
@@ -77,13 +102,14 @@ cat > "$BUILD_DIR/index.html" << HEADER
font-size: 0.875rem;
margin-top: 0.25rem;
}
/* Use the .termine wrapper and add a gap between cards */
.termine {
margin-top: 1.5rem;
display: flex;
flex-direction: column;
gap: 0.75rem;
}
.termin-card {
.kapitel-card {
position: relative;
background: #fff;
border-radius: 12px;
@@ -93,32 +119,35 @@ cat > "$BUILD_DIR/index.html" << HEADER
grid-template-columns: 1fr auto auto;
align-items: center;
gap: 1rem;
padding: 0; /* inner padding handled by kapitel-link */
}
.termin-card:hover {
.kapitel-card:hover {
transform: translateY(-2px);
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
}
.termin-link {
.kapitel-link {
display: block;
padding: 1.25rem 1.5rem;
text-decoration: none;
color: inherit;
grid-column: 1;
}
.termin-label {
/* Disabled look: dim the entire card and prevent pointer events */
.kapitel-card.disabled { opacity: 0.6; pointer-events: none; }
.kapitel-label {
font-size: 0.7rem;
font-weight: 600;
color: $ACCENT_COLOR;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.termin-title {
.kapitel-title {
font-size: 1.05rem;
font-weight: 500;
color: #1d1d1f;
margin: 0.15rem 0;
}
.termin-date {
.kapitel-date {
font-size: 0.8rem;
color: #86868b;
}
@@ -135,11 +164,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
white-space: nowrap;
position: relative;
z-index: 1;
margin-right: 0.5rem;
}
.btn-slides {
background: $ACCENT_COLOR;
color: #fff;
margin-right: 0.5rem;
}
.btn-slides:hover {
filter: brightness(1.1);
@@ -147,11 +176,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
.btn-pdf {
background: #f5f5f7;
color: #1d1d1f;
margin-right: 1rem;
}
.btn-pdf:hover { background: #e8e8ed; }
.btn-disabled { opacity: 0.6; pointer-events: none; }
/* Make entire card clickable via overlay */
.termin-link::after {
.kapitel-link::after {
content: '';
position: absolute;
inset: 0;
@@ -184,10 +213,10 @@ cat > "$BUILD_DIR/index.html" << HEADER
color: #86868b;
}
@media (max-width: 600px) {
.termin-card {
.kapitel-card {
grid-template-columns: 1fr;
}
.termin-link {
.kapitel-link {
padding-bottom: 0.75rem;
}
.btn-slides, .btn-pdf {
@@ -198,63 +227,140 @@ cat > "$BUILD_DIR/index.html" << HEADER
</head>
<body>
<header>
<h1>$TITLE</h1>
<p class="breadcrumb"><a href="../">← Kursübersicht</a></p>
<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
# Generate links for each termin (sorted)
for html in $(ls "$BUILD_DIR"/2*.html 2>/dev/null | sort); do
# Generate links for each kapitel (sorted)
for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
filename=$(basename "$html")
# Extract components from filename
date=$(echo "$filename" | grep -oE '^[0-9]{4}-[0-9x]{2}-[0-9x]{2}')
termin_num=$(echo "$filename" | grep -oE 'termin-[0-9]+' | grep -oE '[0-9]+')
topic_raw=$(echo "$filename" | sed -E 's/^[0-9]{4}-[0-9x]{2}-[0-9x]{2}-termin-[0-9]+-//' | sed 's/\.html$//')
# Extract components from filename (format: NN-topic.html)
kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
topic_raw=$(echo "$filename" | sed -E 's/^[0-9]+-//' | sed 's/\.html$//')
# Look up nice topic name or fallback
topic="${TOPIC_MAP[$topic_raw]}"
if [[ -z "$topic" ]]; then
topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\u&/')
topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\\u&/')
fi
# Format date
if [[ "$date" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]] && [[ ! "$date" =~ xx ]]; then
formatted_date=$(date -d "$date" "+%d. %B %Y" 2>/dev/null || echo "$date")
# Handle kapitel number
if [[ "$kapitel_num" == "0" ]] || [[ -z "$kapitel_num" ]]; then
kapitel_label="Einführung"
else
formatted_date="Termin folgt"
fi
# Handle termin number
if [[ "$termin_num" == "0" ]]; then
termin_label="Einführung"
else
termin_label="Termin $termin_num"
kapitel_label="Kapitel $kapitel_num"
fi
pdf_filename="${filename%.html}.pdf"
# Check if PDF exists
pdf_link=""
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
pdf_link="<a href=\"$pdf_filename\" class=\"btn btn-pdf\">PDF</a>"
# Determine whether this topic is configured as disabled for this course
disabled_full=false
disabled_buttons=false
for t in ${DISABLED_FULL["$COURSE"]}; do
if [[ "$topic_raw" == "$t" ]]; then
disabled_full=true
break
fi
done
if [[ "$disabled_full" == false ]]; then
for t in ${DISABLED_BUTTONS["$COURSE"]}; do
if [[ "$topic_raw" == "$t" ]]; then
disabled_buttons=true
break
fi
done
fi
# Decide card class
card_class="kapitel-card"
if [[ "$disabled_full" == true ]] || [[ "$disabled_buttons" == true ]]; then
card_class="$card_class disabled"
fi
# Build link/button HTML depending on disabled state
if [[ "$disabled_full" == true ]]; then
# non-interactive card (visually dimmed and not clickable)
link_html="<div class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></div>"
slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
pdf_html=""
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
fi
elif [[ "$disabled_buttons" == true ]]; then
# link stays clickable, but buttons are disabled; card appears dimmed
link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
pdf_html=""
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
fi
else
# normal interactive card
pdf_link=""
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
pdf_link="<a href=\"$pdf_filename\" class=\"btn btn-pdf\">PDF</a>"
fi
link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
slides_html="<a href=\"$filename\" class=\"btn btn-slides\">Folien</a>"
pdf_html="$pdf_link"
fi
cat >> "$BUILD_DIR/index.html" << LINK
<div class="termin-card">
<a href="$filename" class="termin-link">
<div class="termin-label">$termin_label</div>
<div class="termin-title">$topic</div>
<div class="termin-date">$formatted_date</div>
</a>
<a href="$filename" class="btn btn-slides">Folien</a>
$pdf_link
<div class="$card_class">
$link_html
$slides_html
$pdf_html
</div>
LINK
done
# Add klausurfolien entry if it exists
if [[ -f "$BUILD_DIR/klausurfolien.html" ]]; then
pdf_link=""
if [[ -f "$BUILD_DIR/klausurfolien.pdf" ]]; then
pdf_link="<a href=\"klausurfolien.pdf\" class=\"btn btn-pdf\">PDF</a>"
fi
cat >> "$BUILD_DIR/index.html" << KLAUSUR
<div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
<a href="klausurfolien.html" class="kapitel-link">
<div class="kapitel-label">Prüfung</div>
<div class="kapitel-title">Klausurrelevante Folien</div>
</a>
<a href="klausurfolien.html" class="btn btn-slides">Folien</a>
$pdf_link
</div>
KLAUSUR
fi
# Add klausurfragen entry if it exists (HTML and/or PDF)
if [[ -f "$BUILD_DIR/klausurfragen.html" ]] || [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
pdf_link=""
if [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
pdf_link="<a href=\"klausurfragen.pdf\" class=\"btn btn-pdf\">PDF</a>"
fi
slides_link=""
if [[ -f "$BUILD_DIR/klausurfragen.html" ]]; then
slides_link="<a href=\"klausurfragen.html\" class=\"btn btn-slides\">Folien</a>"
fi
cat >> "$BUILD_DIR/index.html" << KLAUSURFRAGEN
<div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
<a href="klausurfragen.html" class="kapitel-link">
<div class="kapitel-label">Prüfung</div>
<div class="kapitel-title">Klausurfragen</div>
</a>
$slides_link
$pdf_link
</div>
KLAUSURFRAGEN
fi
cat >> "$BUILD_DIR/index.html" << FOOTER
</div>
<div class="qr-section">
@@ -263,7 +369,7 @@ cat >> "$BUILD_DIR/index.html" << FOOTER
</div>
<footer>
<a href="mailto:mail@librete.ch">Kontakt</a> ·
<a href="../">Alle Kurse</a>
<a href="../">Kursübersicht</a>
</footer>
</body>
</html>
+187
View File
@@ -0,0 +1,187 @@
#!/usr/bin/env bash
# Generate root index.html for /hdm/
# Lists all courses (klausurfragen are now per-course)
BUILD_DIR="build"
cat > "$BUILD_DIR/index.html" << 'HEADER'
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>HdM Vorlesungen</title>
<style>
* { box-sizing: border-box; margin: 0; padding: 0; }
body {
font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Segoe UI", Roboto, sans-serif;
max-width: 720px;
margin: 0 auto;
padding: 3rem 1.5rem;
background: #fafafa;
color: #1d1d1f;
line-height: 1.5;
}
h1 {
font-size: 2rem;
font-weight: 600;
letter-spacing: -0.02em;
margin-bottom: 0.5rem;
}
.subtitle { color: #86868b; font-size: 1rem; }
.courses {
margin-top: 2rem;
display: flex;
flex-direction: column;
gap: 0.75rem;
}
.course-card {
position: relative;
background: #fff;
border-radius: 12px;
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
transition: all 0.2s ease;
display: grid;
grid-template-columns: 1fr auto auto;
align-items: center;
gap: 1rem;
}
.course-card:hover {
transform: translateY(-2px);
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
}
.course-link {
display: block;
padding: 1.25rem 1.5rem;
text-decoration: none;
color: inherit;
grid-column: 1;
}
.course-link::after {
content: '';
position: absolute;
inset: 0;
border-radius: 12px;
}
.course-label {
font-size: 0.7rem;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.course-b .course-label { color: #1e5f8a; }
.course-c .course-label { color: #d63384; }
.course-title {
font-size: 1.15rem;
font-weight: 500;
color: #1d1d1f;
margin: 0.25rem 0;
}
.course-info { font-size: 0.85rem; color: #86868b; }
.btn {
display: inline-flex;
align-items: center;
justify-content: center;
padding: 0.5rem 1rem;
border-radius: 8px;
text-decoration: none;
font-size: 0.8rem;
font-weight: 500;
transition: all 0.2s;
white-space: nowrap;
position: relative;
z-index: 1;
margin-right: 0.5rem;
}
.btn-slides {
background: #6c757d;
color: #fff;
}
.btn-slides:hover { filter: brightness(1.1); }
.btn-pdf {
background: #f5f5f7;
color: #1d1d1f;
}
.btn-pdf:hover { background: #e8e8ed; }
.section-title {
font-size: 1rem;
font-weight: 600;
color: #86868b;
margin-top: 2.5rem;
margin-bottom: 0.75rem;
}
.references {
display: flex;
flex-direction: column;
gap: 0.75rem;
}
footer {
margin-top: 2.5rem;
padding-top: 1.5rem;
border-top: 1px solid #e5e5e7;
color: #86868b;
font-size: 0.85rem;
}
footer a { color: #1d1d1f; text-decoration: none; }
footer a:hover { text-decoration: underline; }
.qr-section {
margin-top: 2.5rem;
padding: 1.5rem;
background: #fff;
border-radius: 12px;
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
text-align: center;
}
.qr-code { width: 100%; height: auto; }
.qr-url { margin-top: 0.75rem; font-size: 0.85rem; color: #86868b; }
@media (max-width: 600px) {
.course-card { grid-template-columns: 1fr; }
.course-link { padding-bottom: 0.75rem; }
.btn { margin: 0 1rem 1rem 1.5rem; }
}
</style>
</head>
<body>
<h1>HdM Vorlesungen</h1>
<p class="subtitle">Sommersemester 2026 · Michael Czechowski</p>
<div class="courses">
<div class="course-card course-b">
<a href="223015b/" class="course-link">
<span class="course-label">223015b</span>
<div class="course-title">Dateiformate, Schnittstellen, Speichermedien &amp; Distributionswege</div>
<span class="course-info">6 Kapitel · Modul "Technik 1"</span>
</a>
</div>
<div class="course-card course-c">
<a href="223015c/" class="course-link">
<span class="course-label">223015c</span>
<div class="course-title">Grundlagen IT- und Internettechnik</div>
<span class="course-info">3 Kapitel · Modul "Technik 1"</span>
</a>
</div>
HEADER
cat >> "$BUILD_DIR/index.html" << 'FOOTER'
</div>
<h2 class="section-title">Referenzen</h2>
<div class="references">
<div class="course-card">
<a href="https://codecrispi.es/" class="course-link">
<span class="course-label">Plattform</span>
<div class="course-title">Code Crispies</div>
<span class="course-info">Selbstlernplattform</span>
</a>
</div>
</div>
<div class="qr-section">
<img src="qr-root.svg" alt="QR Code" class="qr-code">
<p class="qr-url">https://librete.ch/hdm/</p>
</div>
<footer>
<a href="mailto:mail@librete.ch">Kontakt</a>
</footer>
</body>
</html>
FOOTER
echo "Generated $BUILD_DIR/index.html"
@@ -3,8 +3,8 @@ marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
@@ -49,9 +49,23 @@ a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #e3f2fd !important;
}
}
section.aufgabe {
background: #e3f2fd !important;
}
section.klausur footer {
section.aufgabe footer {
display: none;
}
</style>
@@ -68,7 +82,7 @@ section.klausur footer {
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
**Sommersemester 2026**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
@@ -95,7 +109,7 @@ Hochschule der Medien Stuttgart
- Hintergrund:
- Philosophie (Uni Stuttgart) -> NO degree
- Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
- Kontakt: mail@librete.ch
- Kontakt: lb-czechowski@hdm-stuttgart.de
<!--
Kurze Vorstellung
File diff suppressed because it is too large. Load diff
File diff suppressed because it is too large. Load diff
@@ -0,0 +1,860 @@
---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
<style>
:root {
--color-foreground: #1a1a2e;
--color-highlight: #1e5f8a;
--color-dimmed: #4a4a6a;
}
section.invert {
--color-foreground: #fff;
}
section {
font-size: 1.7rem;
}
h1 {
color: #1e5f8a;
}
section.invert h1 {
color: #fff;
}
h2 {
color: #1f2937;
}
pre {
background: #0f0f23;
color: #5fb3e4;
border-radius: 8px;
border-left: 3px solid #1e5f8a;
}
pre code {
background: transparent;
color: inherit;
}
code {
background: #1a1a2e;
color: #5fb3e4;
padding: 0.15em 0.4em;
border-radius: 4px;
}
a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #e3f2fd !important;
}
}
section.aufgabe {
background: #e3f2fd !important;
}
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 -->
<!-- _header: '' -->
<!-- _backgroundColor: #000 -->
![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Sommersemester 2026**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/qr/slides-223015b.png)
---
<!-- _class: lead -->
# Kapitel 3 – 23.01.2026
## Speichermedien & Schnittstellen
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/hdd-ssd-comparison.png)
<!--
HDD aufgeschraubt neben SSD-Platine
Mechanisch vs. Elektronisch
-->
---
# Speicherkapazität: KB vs. KiB
**Das Problem:** Hersteller vs. Betriebssysteme
| Dezimal (SI) | Binär (IEC) |
|--------------|-------------|
| 1 KB = 1.000 Bytes | 1 KiB = 1.024 Bytes |
| 1 MB = 1.000 KB | 1 MiB = 1.024 KiB |
| 1 GB = 1.000 MB | 1 GiB = 1.024 MiB |
| 1 TB = 1.000 GB | 1 TiB = 1.024 GiB |
**1 TB Festplatte → Windows zeigt ~931 GB!**
<!--
Hersteller: Dezimal (SI-Präfix) - klingt mehr!
Betriebssysteme: Binär - aber zeigen "GB" statt "GiB"
Diskrepanz bei 1 TB: 1.000.000.000.000 vs. 1.099.511.627.776 Bytes
→ 10% Unterschied bei TB-Größen
Verwirrung für Konsumenten seit Jahrzehnten
ISO/IEC 80000-13: Definiert KiB, MiB, GiB, TiB (2008)
-->
---
# HDD: Aufbau & Struktur
**Komponenten:**
- **Platter:** Magnetisch beschichtete Scheiben
- **Spindel:** Dreht mit 5.400-7.200 RPM
- **Schreib-Lese-Kopf:** Schwebt nm-dünn über Platter
- **Aktuator:** Bewegt Kopf zur richtigen Spur
**Logische Struktur:**
- **Spuren:** Konzentrische Kreise auf Platter
- **Sektoren:** Unterteilung der Spuren (512 Bytes)
- **Zylinder:** Gleiche Spuren aller Platter
<!--
Aufbau seit 1956 (IBM) grundsätzlich gleich
Platter: Aluminium oder Glas mit Magnetschicht
Spindelgeschwindigkeit: Desktop 7.200, Laptop 5.400, Server 15.000 RPM
Head Crash: Schreib-Lese-Kopf berührt Platter → Kratzer → Datenverlust
Sektor: Kleinste adressierbare Einheit
LBA (Logical Block Addressing): Abstraktion der physischen Struktur
-->
---
# NVMe: Die SSD-Revolution
**NVMe = Non-Volatile Memory Express (2011)**
**Unterschied zu SATA-SSD:**
- SATA: Max. ~550 MB/s (AHCI-Protokoll)
- NVMe: Bis zu 7.000+ MB/s (PCIe direkt)
**Form-Faktoren:**
2,5" (SATA), M.2 (SATA oder NVMe), PCIe-Karte
<!--
NVMe = Non-Volatile Memory Express
Protokoll speziell für Flash-Speicher entwickelt.
SATA wurde für HDDs entwickelt.
Für SSDs ein Flaschenhals.
M.2 ist ein Formfaktor, kein Protokoll!
M.2 kann SATA oder NVMe sein – prüfen!
-->
---
# HDD vs. SSD: Vergleich
| Aspekt | HDD | SSD (NVMe) |
|--------|----:|----------:|
| Sequentiell | ~150 MB/s | ~3.500 MB/s |
| Random Read | ~1 MB/s | ~500 MB/s |
| Latenz | ~10 ms | ~0,02 ms |
| Preis/TB | ~15€ | ~60€ |
| Max. Kapazität | 24 TB | 8 TB (Consumer) |
| Haltbarkeit | 3-5 Jahre | 5-10 Jahre |
<!--
Der Random-Access-Unterschied ist dramatisch.
500× schneller bei zufälligen Zugriffen.
Das ist der Grund, warum SSDs Betriebssysteme
so viel schneller starten lassen.
-->
---
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->
# Wann HDD, wann SSD?
| Anwendung | Empfehlung |
|-----------|------------|
| Betriebssystem | SSD (NVMe) |
| Anwendungen, Spiele | SSD |
| Video-Editing (Projekte) | SSD |
| Foto-Archiv | HDD oder SSD |
| Backup | HDD |
| NAS / Server | HDD (oder Mix) |
| Cold Storage | HDD oder Band |
<!--
Die Faustregel:
- Oft genutzt, schnell gebraucht → SSD
- Selten genutzt, viel Kapazität → HDD
Viele setzen auf beides:
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
## Die Organisation der Daten
---
# Was macht ein Dateisystem?
**Aufgaben:**
- Dateien in Blöcke aufteilen
- Speicherort verwalten (Allokation)
- Verzeichnisstruktur pflegen
- Metadaten speichern (Name, Datum, Rechte)
- Integrität sichern (Journaling)
**Ohne Dateisystem:**
Nur eine Folge von Bytes ohne Struktur.
<!--
Das Dateisystem ist die Abstraktionsschicht
zwischen Anwendungen und rohem Speicher.
Es entscheidet:
- Wie Dateien gefunden werden
- Wie freier Speicher verwaltet wird
- Was bei Abstürzen passiert
-->
---
# FAT32: Der Kompatibilitätskönig
**File Allocation Table, 32-bit (1996)**
**Vorteile:**
- Überall lesbar (Windows, Mac, Linux, Kameras, Fernseher...)
- Einfach, robust
**Nachteile:**
- Max. 4 GB pro Datei
- Max. 2 TB pro Volume
- Keine Berechtigungen
- Kein Journaling
**Ideal für:** USB-Sticks, SD-Karten (Kompatibilität)
<!--
4 GB Limit ist das Hauptproblem.
Ein 4K-Video oder ISO-Image passt oft nicht drauf.
Trotzdem: FAT32 ist der kleinste gemeinsame Nenner.
Wenn Kompatibilität wichtiger ist als Features → FAT32.
-->
---
# exFAT: FAT32 ohne Limits
**Extended FAT (2006, Microsoft)**
**Vorteile:**
- Keine praktischen Dateigrößen-Limits
- Breite Unterstützung (seit 2019 auch Linux-Kernel)
- Für Flash-Speicher optimiert
**Nachteile:**
- Kein Journaling
- Weniger robust als NTFS/APFS/ext4
**Ideal für:** Große Dateien auf portablen Medien
<!--
exFAT ist der Nachfolger von FAT32 für portable Medien.
SD-Karten über 32 GB sind standardmäßig exFAT.
Microsoft hat 2019 die Patente freigegeben.
Seitdem native Linux-Unterstützung.
-->
---
# NTFS: Windows-Standard
**New Technology File System (1993)**
**Features:**
- Journaling (Crash-Sicherheit)
- Dateirechte (ACLs)
- Kompression, Verschlüsselung
- Große Dateien und Volumes
**Nachteile:**
- Nur Windows schreibt nativ
- macOS: Nur lesen
- Linux: Über ntfs-3g (langsamer)
<!--
NTFS ist seit Windows NT der Standard.
Alle modernen Windows-Versionen nutzen es.
Für Windows-only-Systeme die beste Wahl.
Für portable Medien: Kompatibilitätsprobleme.
-->
---
# APFS: Apple-Modern
**Apple File System (2017)**
**Features:**
- Snapshots (Zeitpunkt-Kopien)
- Copy-on-Write (CoW)
- Native Verschlüsselung
- Optimiert für SSDs
**Nachteile:**
- Nur Apple-Geräte
- Nicht abwärtskompatibel mit HFS+
<!--
APFS ersetzte HFS+ auf allen Apple-Geräten.
Snapshots ermöglichen Time Machine und APFS-Klone.
Copy-on-Write: Daten werden nicht überschrieben,
sondern neue Versionen werden geschrieben.
Gut für Integrität und Snapshots.
-->
---
# ext4: Linux-Standard
**Fourth Extended File System (2008)**
**Features:**
- Journaling
- Extents (effiziente große Dateien)
- Online-Defragmentierung
- Bewährt und stabil
**Nachteile:**
- Windows/macOS können nicht nativ lesen
- Weniger Features als btrfs/ZFS
<!--
ext4 ist der Standard für Linux-Systeme.
Evolution: ext (1992) → ext2 → ext3 → ext4
Alternativen: btrfs (Snapshots, CoW), XFS, ZFS
Für Server oft XFS oder ZFS.
-->
---
# Dateisysteme: Übersicht
| FS | Max. Datei | Journaling | Ideal für |
|----|----------:|:----------:|-----------|
| FAT32 | 4 GB | ❌ | Kompatibilität |
| exFAT | 16 EB | ❌ | Große portable Dateien |
| NTFS | 16 EB | ✓ | Windows |
| APFS | 8 EB | ✓ | macOS, iOS |
| ext4 | 16 TB | ✓ | Linux |
<!--
Die Wahl hängt vom Kontext ab.
Portable Medien: FAT32 oder exFAT
Interne Laufwerke: NTFS, APFS, ext4 je nach OS
-->
---
<!-- _class: lead -->
# Backup & Archivierung
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/backup-disaster.png)
<!--
Symbolbild: Kaputte Festplatte oder Ransomware
Das Worst-Case-Szenario
-->
---
# Warum Backup?
**Realitäten:**
- HDDs haben 1-2% jährliche Ausfallrate
- SSDs können ohne Vorwarnung sterben
- Ransomware verschlüsselt Daten
- Versehentliches Löschen passiert
- Diebstahl, Brand, Wasserschaden
**Die Frage ist nicht ob, sondern wann.**
<!--
Backblaze veröffentlicht jährliche HDD-Statistiken.
1-2% Ausfallrate klingt wenig, aber bei 100 Platten...
Pixar verlor fast "Toy Story 2" (1998).
Rettung: Eine Mitarbeiterin hatte ein Home-Backup.
-->
---
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->
# Die 3-2-1-Regel
**3** Kopien eurer Daten
(Original + 2 Backups)
**2** verschiedene Medientypen
(z.B. SSD + HDD, oder lokal + Cloud)
**1** Kopie an anderem Ort
(Offsite: Cloud, anderes Gebäude)
<!--
Herkunft: Peter Krogh, "The DAM Book" (2005)
Warum 3 Kopien?
- Original kann kaputt gehen
- Backup 1 auch
- Backup 2 = Sicherheitspuffer
Warum 2 Medientypen?
- Gleiche Medien haben gleiche Schwachstellen
- Batch-Fehler bei HDDs derselben Charge
Warum 1 Offsite?
- Brand/Wasserschaden zerstört alles vor Ort
- Ransomware verschlüsselt angeschlossene Laufwerke
-->
---
<!-- _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):**
Kompletter Datenbestand jedes Mal.
Einfach, aber langsam und platzhungrig.
**Inkrementell:**
Nur Änderungen seit dem letzten Backup.
Schnell, aber Wiederherstellung komplex (Kette).
**Differenziell:**
Änderungen seit dem letzten Voll-Backup.
Mittelweg zwischen beiden.
<!--
Typisches Schema:
- Sonntag: Voll-Backup
- Mo-Sa: Inkrementell oder Differenziell
Inkrementell: Schnellstes Backup, langsamste Wiederherstellung
Differenziell: Kompromiss
Voll: Langsamstes Backup, schnellste Wiederherstellung
-->
---
# Backup in der Praxis
**macOS:** Time Machine
**Windows:** Veeam Agent (kostenlos), Windows Backup
**Linux:** rsync, Borg, Restic
**Cloud:** Backblaze, iCloud, Google Drive
**Wichtig:**
- Automatisieren (manuell wird vergessen)
- Regelmäßig testen (Backup nützt nichts, wenn Restore nicht funktioniert)
<!--
Time Machine: Stündliche Snapshots, APFS-Integration
Veeam: Enterprise-Level, kostenlose Endnutzer-Version
rsync: Unix-Klassiker, extrem effizient
Borg: Deduplizierung + Verschlüsselung
-->
---
# Langzeitarchivierung
**Probleme:**
- Bit Rot (Daten degradieren)
- Format-Obsoleszenz (wer öffnet .wpd?)
- Hardware-Obsoleszenz (Diskettenlaufwerk?)
**Lösungen:**
- Migration alle 5-10 Jahre auf neue Medien
- Offene Standards (PDF/A, TIFF, Plain Text)
- Redundante Kopien
<!--
WordPerfect dominierte die 1980er/90er.
Heute kann kaum jemand .wpd-Dateien öffnen.
Flash-Dateien (.swf) sind seit 2020 praktisch tot.
Millionen von Websites und Spielen verloren.
-->
---
# Archivmedien
**LTO-Tapes:**
- 18 TB pro Band (LTO-9)
- ~5€/TB
- 30 Jahre Haltbarkeit
- Für Cold Storage ideal
**M-DISC:**
- Spezielle DVD/Blu-ray
- 1.000+ Jahre Haltbarkeit (Herstellerangabe)
- Für kleine, wichtige Daten
**Cloud:**
- Glacier, Backblaze B2
- Günstig für Langzeit
<!--
LTO = Linear Tape-Open
AWS, Google, Netflix nutzen Tape für Archive.
M-DISC nutzt anorganische Schicht statt Dye.
Theoretisch sehr langlebig, praktisch ungetestet.
Cloud-Archive haben laufende Kosten.
Aber: Keine Hardware-Wartung.
-->
---
<!-- _class: lead -->
# Schnittstellen
---
# USB: Die Universal-Schnittstelle
| Version | Jahr | Geschwindigkeit |
|---------|------|----------------:|
| USB 1.1 | 1998 | 12 Mbit/s |
| USB 2.0 | 2000 | 480 Mbit/s (~60 MB/s) |
| USB 3.0 | 2008 | 5 Gbit/s (~625 MB/s) |
| USB 3.1 Gen 2 | 2013 | 10 Gbit/s |
| USB 3.2 Gen 2×2 | 2017 | 20 Gbit/s |
| USB4 | 2019 | 40 Gbit/s |
<!--
USB = Universal Serial Bus
Die Namensgebung ist ein Chaos.
USB 3.0 wurde nachträglich zu "USB 3.1 Gen 1" umbenannt.
Dann zu "USB 3.2 Gen 1".
Die Industrie verwirrt absichtlich.
-->
---
# USB-C: Der Stecker, nicht die Geschwindigkeit
**USB-C ist ein Steckertyp, kein Protokoll!**
Ein USB-C-Kabel kann sein:
- USB 2.0 (480 Mbit/s)
- USB 3.2 (bis 20 Gbit/s)
- USB4 (40 Gbit/s)
- Thunderbolt 3/4 (40 Gbit/s)
**Am Stecker nicht erkennbar.**
→ Kabel-Spezifikation prüfen!
<!--
Das ist eine häufige Quelle für Frustration.
"Ich habe ein USB-C-Kabel, warum ist es so langsam?"
Weil es ein USB 2.0-Kabel mit USB-C-Stecker ist.
Gute Kabel sind teurer, aber es lohnt sich.
-->
---
# Thunderbolt
**Thunderbolt 3/4 (2015/2020):**
- 40 Gbit/s
- PCIe über Kabel (externe GPUs möglich)
- DisplayPort integriert
- USB-C-Stecker
**Vorteile:**
- Sehr schnell
- Vielseitig (Daten, Video, Strom)
**Nachteile:**
- Teure Kabel
- Nicht alle USB-C-Ports sind Thunderbolt
<!--
Intel und Apple entwickelten Thunderbolt gemeinsam.
Lizenzfrei seit 2019.
Thunderbolt-Kabel haben oft ein Blitz-Symbol.
Aber nicht immer.
-->
---
# Video-Schnittstellen
| Schnittstelle | Max. Auflösung | Features |
|---------------|---------------:|----------|
| HDMI 2.0 | 4K/60Hz | ARC, CEC |
| HDMI 2.1 | 8K/60Hz, 4K/120Hz | VRR, eARC |
| DisplayPort 1.4 | 8K/60Hz | Daisy-Chain |
| DisplayPort 2.0 | 16K/60Hz | Mehr Bandbreite |
**HDMI:** Consumer-Geräte (TV, Konsolen)
**DisplayPort:** Computer, Monitore
<!--
HDMI hat Lizenzgebühren, DisplayPort nicht.
Deshalb ist DP bei Monitoren beliebter.
DisplayPort kann Daisy-Chaining:
Laptop → Monitor 1 → Monitor 2 über ein Kabel.
HDMI hat ARC (Audio Return Channel):
TV schickt Audio an Soundbar über HDMI.
-->
---
# Netzwerk
**Ethernet:**
| Standard | Geschwindigkeit |
|----------|----------------:|
| Fast Ethernet | 100 Mbit/s |
| Gigabit | 1 Gbit/s |
| 2.5 Gigabit | 2,5 Gbit/s |
| 10 Gigabit | 10 Gbit/s |
**WiFi:**
| Generation | Standard | Geschwindigkeit |
|------------|----------|----------------:|
| WiFi 5 | 802.11ac | ~1,3 Gbit/s |
| WiFi 6 | 802.11ax | ~9,6 Gbit/s |
| WiFi 7 | 802.11be | ~46 Gbit/s |
<!--
Gigabit-Ethernet ist heute Standard.
2,5G und 10G verbreiten sich für NAS und Poweruser.
WiFi-Geschwindigkeiten sind theoretische Maxima.
Real: Bruchteil davon, abhängig von Entfernung und Störungen.
-->
---
# Welche Schnittstelle für was?
| Anwendung | Empfehlung |
|-----------|------------|
| Externe SSD | USB 3.2 Gen 2 oder Thunderbolt |
| USB-Stick | USB 3.0 reicht |
| Monitor | DisplayPort oder HDMI 2.0+ |
| NAS im Heimnetz | Gigabit Ethernet |
| Backup-Platte | USB 3.0 |
| Video-Editing extern | Thunderbolt |
<!--
Die Schnittstelle muss zum Gerät passen.
Externe HDD über Thunderbolt?
Bringt nichts, die HDD ist der Flaschenhals.
NVMe-SSD über USB 2.0?
Verschwendung, USB ist der Flaschenhals.
-->
---
<!-- _class: aufgabe -->
# Hands-On: Eigene Speicher analysieren
**Aufgabe (30 Min):**
1. Welche Laufwerke habt ihr? (SSD, HDD, extern)
2. Welches Dateisystem nutzt ihr?
3. Wie ist eure Backup-Situation?
4. Welche Schnittstellen nutzt ihr?
**Tools:**
- Windows: Datenträgerverwaltung
- macOS: Festplattendienstprogramm
- Linux: `lsblk`, `df -h`
<!--
Ziel: Bewusstsein für eigene Infrastruktur.
Die meisten wissen nicht, welches Dateisystem
auf ihrem USB-Stick ist.
-->
---
<!-- _class: lead -->
# Fragen & Diskussion
**Kontakt:** lb-czechowski@hdm-stuttgart.de
**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/)
---
# Lizenz & Attribution
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
- Erlaubt Teilen & Anpassen mit Namensnennung
- Adaptionen müssen unter gleicher Lizenz geteilt werden
Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
@@ -3,8 +3,8 @@ marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
@@ -49,9 +49,23 @@ a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #e3f2fd !important;
}
}
section.aufgabe {
background: #e3f2fd !important;
}
section.klausur footer {
section.aufgabe footer {
display: none;
}
</style>
@@ -69,7 +83,7 @@ section.klausur footer {
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
**Sommersemester 2026**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
@@ -84,7 +98,7 @@ Hochschule der Medien Stuttgart
<!-- _class: lead -->
# Termin 4 – 30.01.2026
# Kapitel 4 – 30.01.2026
## Distribution, APIs & Zukunft
---
@@ -1252,7 +1266,7 @@ Dangerzone: FOSS-Tool (Freedom of Press Foundation)
**Offene Formate:**
✓ Spezifikation öffentlich
✓ Keine Lizenzgebühren
✓ Viele Programme unterstützen
✓ Viele Programme unterstützen1
**Beispiele:** PNG, OGG, MKV, Markdown, SVG
**Proprietäre Formate:**
@@ -1267,7 +1281,7 @@ Lock-in: "Gefangene Daten" (nur in Software X öffenbar)
Firma geht pleite → Format stirbt (WordPerfect-Beispiel)
Offene Standards: Überlebensfähiger (Community kann implementieren)
-->
111
---
# Vendor Lock-in: Beispiele
@@ -1839,7 +1853,7 @@ Evaluation: Feedback ernst nehmen, Kurs verbessern
# Fragen & Diskussion
**Kontakt:** mail@librete.ch
**Kontakt:** lb-czechowski@hdm-stuttgart.de
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
---
@@ -3,8 +3,8 @@ marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
@@ -49,9 +49,23 @@ a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #e3f2fd !important;
}
}
section.aufgabe {
background: #e3f2fd !important;
}
section.klausur footer {
section.aufgabe footer {
display: none;
}
</style>
@@ -69,7 +83,7 @@ section.klausur footer {
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
**Sommersemester 2026**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
@@ -84,7 +98,7 @@ Hochschule der Medien Stuttgart
<!-- _class: lead -->
# Termin 5 – TBA
# Kapitel 5 – TBA
## Vertiefung & Offene Fragen
---
@@ -110,7 +124,7 @@ Themen nach Interesse der Studierenden
# Fragen & Diskussion
**Kontakt:** mail@librete.ch
**Kontakt:** lb-czechowski@hdm-stuttgart.de
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
---
Binary file not shown.

After

Width:  |  Height:  |  Size: 220 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.2 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 425 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 64 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 241 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 484 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 249 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 388 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 161 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 112 KiB

@@ -0,0 +1,9 @@
<svg xmlns="http://www.w3.org/2000/svg" width="80" height="80">
<defs>
<pattern id="diagonalStripes" patternUnits="userSpaceOnUse" width="80" height="80" patternTransform="rotate(135)">
<rect width="40" height="80" fill="#e3f2fd"/>
<rect x="40" width="40" height="80" fill="#ffffff"/>
</pattern>
</defs>
<rect width="100%" height="100%" fill="url(#diagonalStripes)"/>
</svg>

After

Width:  |  Height:  |  Size: 401 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 97 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 465 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 29 KiB

+619
View File
@@ -0,0 +1,619 @@
---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
<style>
:root {
--color-foreground: #1a1a2e;
--color-highlight: #1e5f8a;
--color-dimmed: #4a4a6a;
}
section.invert {
--color-foreground: #fff;
}
section {
font-size: 1.7rem;
}
h1 {
color: #1e5f8a;
}
section.invert h1 {
color: #fff;
}
h2 {
color: #1f2937;
}
pre {
background: #0f0f23;
color: #5fb3e4;
border-radius: 8px;
border-left: 3px solid #1e5f8a;
}
pre code {
background: transparent;
color: inherit;
}
code {
background: #1a1a2e;
color: #5fb3e4;
padding: 0.15em 0.4em;
border-radius: 4px;
}
a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #e3f2fd !important;
}
}
section.aufgabe {
background: #e3f2fd !important;
}
section.aufgabe footer {
display: none;
}
</style>
<!--
╔═══════════════════════════════════════════════════════════════════╗
║ AUTO-GENERATED FILE - DO NOT EDIT MANUALLY ║
║ ║
║ This file is generated by: make klausur ║
║ Source: scripts/extract-klausur.sh ║
║ ║
║ To update, edit the source slides and re-run make klausur ║
╚═══════════════════════════════════════════════════════════════════╝
-->
<!-- _class: invert -->
<!-- _header: '' -->
<!-- _backgroundColor: #000 -->
![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Sommersemester 2026**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
---
<!-- _header: "" -->
<!-- _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)
**Speicherbedarf (unkomprimiert):**
Breite × Höhe × Farbtiefe (in Bytes)
**Beispiele:** JPEG, PNG, WebP
| Bits (Farbtiefe) | Farben | Anwendung |
|-----:|-------:|-----------|
| 1 | 2 | Schwarz/Weiß (Fax) |
| 8 | 256 | Graustufen, GIF |
| 24 | 16,7 Mio. | True Color (Standard) |
| 32 | 16,7 Mio. + Alpha | Transparenz |
<!--
KLAUSURRELEVANT:
- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
- Farbtiefe: 2^n Farben bei n Bit
- 24 Bit = 8 Bit pro Kanal (R, G, B)
- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Vektorgrafiken
**Speicherung als geometrische Primitive:**
- Pfade (Bézierkurven mit Kontrollpunkten)
- Grundformen (Rechteck, Ellipse, Polygon)
- Text (Glyphen als Outlines)
**SVG-Beispiel:**
```xml
<circle cx="50" cy="50" r="40" fill="#ff0000"/>
```
<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>
<!--
KLAUSURRELEVANT:
- Vektor = Beschreibung (deklarativ)
- Raster = Pixel für Pixel (imperativ)
- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
- SVG = Scalable Vector Graphics (Web-Standard)
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Die Schwächen des Auges
**Menschen sehen:**
- Helligkeit besser als Farbe
- Große Flächen besser als feine Details
- Niedrige Frequenzen besser als hohe
**JPEG nutzt das aus:**
- Farbauflösung reduzieren (Helligkeit behalten)
- Glatte Flächen effizient speichern
- Hohe Frequenzen (feine Details) verwerfen
<!--
KLAUSURRELEVANT:
- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
- Niedrig = langsame Änderung = große gleichmäßige Fläche
- Hoch = schnelle Änderung = feine Details, Kanten
- Analogie zur Psychoakustik bei MP3 (letztes Mal)
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
![bg right:20%](./assets/Barn-yuv.png)
# JPEG Schritt 1: Farbraumkonversion
**RGB → Y'CbCr**
- **Y** = Helligkeit (Luminanz)
- **Cb** = Blau-Gelb-Anteil (Chrominanz)
- **Cr** = Rot-Grün-Anteil (Chrominanz)
**Warum?**
Y (Helligkeit) behält volle Auflösung
Cb/Cr (Farbe) kann reduziert werden
<!--
KLAUSURRELEVANT:
- YCbCr = auch 3 Werte pro Pixel, aber anders organisiert
- Statt R-G-B: Helligkeit + 2 Farbdifferenzen
- Umrechnung ist reversibel (mathematische Transformation)
- Vorteil: Helligkeit und Farbe getrennt behandelbar
- Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# JPEG Schritt 6: Huffman-Coding
**Verlustfreie Kompression der Restwerte**
**Idee:** Variable Bitlänge statt fester 8 Bit
Häufige Werte → kurze Codes
| Zeichen | Häufigkeit | Code |
|---------|------------|------|
| e | 40% | `0` (1 Bit) |
| a | 25% | `10` (2 Bit) |
| i | 20% | `110` (3 Bit) |
| o | 10% | `1110` (4 Bit) |
| u | 5% | `1111` (4 Bit) |
<!--
KLAUSURRELEVANT:
- Huffman = verlustfrei, optimal für bekannte Häufigkeiten
- Präfix-frei: Kein Code ist Anfang eines anderen
- Häufigstes Zeichen = kürzester Code
- Auch in ZIP, PNG, MP3 verwendet
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
<!--
# Huffman-Coding: Beispiel
**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)
**Häufigkeitsanalyse:**
A=5, B=2, R=2, C=1, D=1
**Huffman-Baum → Codes:**
| Zeichen | Häufigkeit | Code |
|---------|------------|------|
| A | 5 | `0` |
| B | 2 | `10` |
| R | 2 | `110` |
| C | 1 | `1110` |
| D | 1 | `1111` |
**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
**Kompression:** 88 → 23 Bit = **74% gespart**
- Beispiel Schritt für Schritt durchrechnen
- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# WebP & AVIF: Moderne Alternativen
**WebP (Google, 2010):**
- Lossy und Lossless
- Transparenz und Animationen
- 25–35% kleiner als JPEG
**AVIF (2019):**
- Basiert auf AV1-Video-Codec
- 50% kleiner als JPEG
- HDR-Unterstützung, patent-frei
**Browser-Support 2025:** WebP universell, AVIF wächst
<!--
KLAUSURRELEVANT:
- WebP: VP8-Kompression (Google Video-Codec)
- AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla)
- Beide besser als JPEG, aber Kompatibilität bleibt Problem
- JPEG bleibt dominant: alte Kameras, Software, Workflows
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Container und Codec
**Container = Dateiformat (z.B. MP4)**
Die "Box", die verschiedene Streams zusammenpackt:
- Video-Stream
- Audio-Stream(s)
- Untertitel
- Metadaten
**Codec = Kompressionsalgorithmus (z.B. H.264)**
Bestimmt, WIE komprimiert wird
<!--
KLAUSURRELEVANT:
- Container ≠ Codec (häufiges Missverständnis!)
- MP4 kann H.264, H.265 oder AV1 enthalten
- Gleiche Endung, unterschiedlicher Inhalt
- Tool-Tipp: MediaInfo zeigt beides an
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# H.264 / AVC
**Advanced Video Coding (2003)**
**Warum dominant?**
- Exzellente Kompression (~100:1 möglich)
- Hardware-Decoder in jedem Gerät seit ~2010
- YouTube, Netflix, Blu-ray – alles H.264
**Features:**
- Variable Block-Größen (16×16 bis 4×4)
- Deblocking-Filter (reduziert Artefakte)
<!--
KLAUSURRELEVANT:
- H.264 revolutionierte Video-Streaming
- Ohne H.264 kein Netflix, kein YouTube HD
- Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain
- Selbst billigste Smartphones können H.264 abspielen
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# AV1: Die offene Zukunft
**AV1 (2018)**
**Alliance for Open Media:**
Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
**Eigenschaften:**
- 30% besser als H.265
- Royalty-free, Open Source
- 8K, HDR, hohe Frame-Rates
**Stand 2025:**
YouTube, Netflix nutzen AV1 für 4K/8K
Hardware-Encoder in aktuellen GPUs
<!--
KLAUSURRELEVANT:
- AOM gegründet 2015 – historisch: Konkurrenten vereint
- Ziel: Nie wieder Patent-Chaos wie bei H.265
- Problem: Encoding sehr langsam (10–100× vs. H.264)
- Hardware-Encoder lösen das zunehmend
- AV1 gewann 2024 einen Emmy für technische Innovation
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Wann HDD, wann SSD?
| Anwendung | Empfehlung |
|-----------|------------|
| Betriebssystem | SSD (NVMe) |
| Anwendungen, Spiele | SSD |
| Video-Editing (Projekte) | SSD |
| Foto-Archiv | HDD oder SSD |
| Backup | HDD |
| NAS / Server | HDD (oder Mix) |
| Cold Storage | HDD oder Band |
<!--
Die Faustregel:
- Oft genutzt, schnell gebraucht → SSD
- Selten genutzt, viel Kapazität → HDD
Viele setzen auf beides:
Kleine SSD für System + große HDD für Archiv.
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Die 3-2-1-Regel
**3** Kopien eurer Daten
(Original + 2 Backups)
**2** verschiedene Medientypen
(z.B. SSD + HDD, oder lokal + Cloud)
**1** Kopie an anderem Ort
(Offsite: Cloud, anderes Gebäude)
<!--
Herkunft: Peter Krogh, "The DAM Book" (2005)
Warum 3 Kopien?
- Original kann kaputt gehen
- Backup 1 auch
- Backup 2 = Sicherheitspuffer
Warum 2 Medientypen?
- Gleiche Medien haben gleiche Schwachstellen
- Batch-Fehler bei HDDs derselben Charge
Warum 1 Offsite?
- Brand/Wasserschaden zerstört alles vor Ort
- Ransomware verschlüsselt angeschlossene Laufwerke
-->
File diff suppressed because it is too large. Load diff
File renamed without changes.
File renamed without changes.
File renamed without changes.
File diff suppressed because it is too large. Load diff
File diff suppressed because it is too large. Load diff
@@ -3,9 +3,9 @@ marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Grundlagen IT- und Internettechnik"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
title: "Termin 3: Interaktivität & JavaScript"
header: "Grundlagen IT- und Internettechnik (223015c)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: "Kapitel 3: Interaktivität & JavaScript"
---
<style>
@@ -48,6 +48,26 @@ code {
a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#fce4ec,
#fce4ec 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #fce4ec !important;
}
}
section.aufgabe {
background: #fce4ec !important;
}
section.aufgabe footer {
display: none;
}
</style>
<!-- _class: invert -->
@@ -63,7 +83,7 @@ a {
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
**Sommersemester 2026**
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
@@ -78,7 +98,7 @@ Hochschule der Medien Stuttgart
<!-- _class: lead -->
# Termin 3 – 24.01.2026
# Kapitel 3 – 24.01.2026
## Interaktivität & JavaScript
---
@@ -984,7 +1004,7 @@ Euer ehrliches Feedback hilft mir, den Kurs zu verbessern.
- Was könnte besser sein?
- Welche Themen interessieren euch noch?
*Feedback gerne auch anonym per E-Mail an mail@librete.ch*
*Feedback gerne auch anonym per E-Mail an lb-czechowski@hdm-stuttgart.de*
---
@@ -992,7 +1012,7 @@ Euer ehrliches Feedback hilft mir, den Kurs zu verbessern.
# Danke!
**Kontakt:** mail@librete.ch
**Kontakt:** lb-czechowski@hdm-stuttgart.de
**Ressourcen:**
- https://nextlevelshit.github.io/html-over-js/
Loaded 100 of 143 files, more files were not shown because too many files have changed in this diff. Show more