Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
64f4729f45 | ||
|
|
c35541961e | ||
|
|
d8f68183f3 | ||
|
|
705c5e3457 | ||
|
|
9b0b6bc9d6 | ||
|
|
62cd97c51a | ||
|
|
9f2c78d536 | ||
|
|
fb0db03db9 | ||
|
|
f9185d25e0 | ||
|
|
4f3b680951 | ||
|
|
a2b1c0484a | ||
|
|
1480d31a54 | ||
|
|
514896db33 | ||
|
|
b21e2394d5 | ||
|
|
7da018d92c | ||
|
|
9e12447528 | ||
|
|
7e4d4a8a4b | ||
|
|
3fa1e1b1dc | ||
|
|
a8343c9937 | ||
|
|
b951341376 | ||
|
|
0fab5005df | ||
|
|
2755d4dee0 | ||
|
|
a3131851f0 | ||
|
|
7e878c27ef | ||
|
|
93e8ced463 | ||
|
|
58e0457165 | ||
|
|
d77b0f20c7 | ||
|
|
f7f4872c11 | ||
|
|
5f6369ad85 | ||
|
|
31790930de | ||
|
|
4fa64a6abd | ||
|
|
5c970053ee | ||
|
|
d19aa98f79 | ||
|
|
ccceac83e4 | ||
|
|
8f9934413a | ||
|
|
32c14ac412 | ||
|
|
2179f6caed | ||
|
|
b45a528faf | ||
|
|
64e67b7034 | ||
|
|
fc3f3a73f5 | ||
|
|
ee4d5435ed | ||
|
|
111d13420a | ||
|
|
3db80be669 | ||
|
|
8690e69e47 | ||
|
|
3f4be26dcb |
No files matched your search
@@ -32,3 +32,4 @@ hdm-internettechnik-slides/
|
|||||||
# Temporary files
|
# Temporary files
|
||||||
*.tmp
|
*.tmp
|
||||||
*.bak
|
*.bak
|
||||||
|
.idea
|
||||||
@@ -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
|
||||||
@@ -4,8 +4,8 @@ This project builds presentation decks for Marp, supporting multiple courses.
|
|||||||
|
|
||||||
## Courses
|
## Courses
|
||||||
|
|
||||||
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Termine)
|
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
|
||||||
- **223015c** - Internettechnologien (3 Termine)
|
- **223015c** - Internettechnologien (3 Kapitel)
|
||||||
|
|
||||||
## Agent Restrictions
|
## Agent Restrictions
|
||||||
|
|
||||||
@@ -15,7 +15,7 @@ This project builds presentation decks for Marp, supporting multiple courses.
|
|||||||
|
|
||||||
## Critical File Protection
|
## 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
|
- ALLOWED: Adding slides, adjusting content, fixing typos, enhancing sections
|
||||||
- FORBIDDEN (without permission): Deleting slides, removing sections, bulk deletions
|
- FORBIDDEN (without permission): Deleting slides, removing sections, bulk deletions
|
||||||
- Before ANY deletion: ALWAYS ask user for confirmation
|
- Before ANY deletion: ALWAYS ask user for confirmation
|
||||||
@@ -23,9 +23,9 @@ Slide files in `courses/*/slides/*.md` are main content files:
|
|||||||
## Project Structure
|
## Project Structure
|
||||||
|
|
||||||
```
|
```
|
||||||
courses/
|
slides/
|
||||||
├── 223015b/slides/ # Dateiformate course
|
├── 223015b/ # Dateiformate course
|
||||||
└── 223015c/slides/ # Internettechnik course
|
└── 223015c/ # Internettechnik course
|
||||||
scripts/ # Shared scripts
|
scripts/ # Shared scripts
|
||||||
themes/ # Custom Marp themes
|
themes/ # Custom Marp themes
|
||||||
build/ # Generated output (gitignored)
|
build/ # Generated output (gitignored)
|
||||||
@@ -34,13 +34,14 @@ build/ # Generated output (gitignored)
|
|||||||
## Build Commands
|
## Build Commands
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
make dev-b # Dev server 223015b (port 1312)
|
make dev-b # Dev server 223015b (port 1311)
|
||||||
make dev-c # Dev server 223015c (port 1313)
|
make dev-c # Dev server 223015c (port 1312)
|
||||||
make build # Build all courses
|
make build # Build all courses
|
||||||
make build-b # Build 223015b only
|
make build-b # Build 223015b only
|
||||||
make build-c # Build 223015c only
|
make build-c # Build 223015c only
|
||||||
make html # HTML only
|
make html # HTML only
|
||||||
make pdf # PDF only
|
make pdf # PDF only
|
||||||
|
make klausur # Extract klausur slides → slides/*/klausur.md
|
||||||
make deploy # Deploy all (ASK FIRST!)
|
make deploy # Deploy all (ASK FIRST!)
|
||||||
```
|
```
|
||||||
|
|
||||||
@@ -56,12 +57,12 @@ nix run .#optimize-img -- <path> # Optimize images
|
|||||||
## Code Style Guidelines
|
## Code Style Guidelines
|
||||||
|
|
||||||
### File Structure
|
### File Structure
|
||||||
- Slides in `courses/<course>/slides/`
|
- Slides in `slides/<course>/`
|
||||||
- Assets in `courses/<course>/slides/assets/`
|
- Assets in `slides/<course>/assets/`
|
||||||
- Always reference images as `./assets/filename.png`
|
- Always reference images as `./assets/filename.png`
|
||||||
|
|
||||||
### Naming Conventions
|
### 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`
|
- Images: `snake_case.jpg` or `kebab-case.jpg`
|
||||||
|
|
||||||
### Markdown Style
|
### Markdown Style
|
||||||
|
|||||||
@@ -1,25 +1,19 @@
|
|||||||
# HdM Slides - Unified Makefile
|
# HdM Slides - Unified Makefile
|
||||||
# Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
|
# 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
|
# Course configuration
|
||||||
COURSES = 223015b 223015c
|
COURSES = 223015b 223015c
|
||||||
COURSE_DIR = courses
|
SLIDES_DIR = slides
|
||||||
|
|
||||||
# Port configuration (index starts at BASE_PORT, courses increment from there)
|
|
||||||
BASE_PORT = 1310
|
|
||||||
INDEX_PORT = $(BASE_PORT)
|
|
||||||
|
|
||||||
# Course-specific settings
|
# Course-specific settings
|
||||||
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
|
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
|
||||||
223015b_PORT = 1311
|
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_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_DEPLOY_PATH = /home/tengo/html/hdm/223015b
|
223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
|
||||||
|
|
||||||
223015c_NAME = Internettechnologien
|
223015c_NAME = Internettechnologien
|
||||||
223015c_PORT = 1312
|
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
|
||||||
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_DEPLOY_PATH = /home/tengo/html/hdm/223015c
|
223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
|
||||||
|
|
||||||
DEPLOY_HOST = tengo@tuttle.uberspace.de
|
DEPLOY_HOST = tengo@tuttle.uberspace.de
|
||||||
@@ -33,9 +27,7 @@ help:
|
|||||||
@echo " 223015c - Internettechnologien"
|
@echo " 223015c - Internettechnologien"
|
||||||
@echo ""
|
@echo ""
|
||||||
@echo "Development:"
|
@echo "Development:"
|
||||||
@echo " make dev - Both servers + index (ports 1311, 1312, 1313)"
|
@echo " make dev - Start development server (port 3000)"
|
||||||
@echo " make dev-b - Dev server for 223015b (port 1312)"
|
|
||||||
@echo " make dev-c - Dev server for 223015c (port 1313)"
|
|
||||||
@echo ""
|
@echo ""
|
||||||
@echo "Build:"
|
@echo "Build:"
|
||||||
@echo " make build - Build all courses"
|
@echo " make build - Build all courses"
|
||||||
@@ -43,6 +35,7 @@ help:
|
|||||||
@echo " make build-c - Build 223015c only"
|
@echo " make build-c - Build 223015c only"
|
||||||
@echo " make pdf - Export all to PDF"
|
@echo " make pdf - Export all to PDF"
|
||||||
@echo " make html - Export all to HTML"
|
@echo " make html - Export all to HTML"
|
||||||
|
@echo " make klausur - Extract klausurfolien slides"
|
||||||
@echo ""
|
@echo ""
|
||||||
@echo "Tools:"
|
@echo "Tools:"
|
||||||
@echo " make qr URL=... - Generate QR code for URL"
|
@echo " make qr URL=... - Generate QR code for URL"
|
||||||
@@ -62,36 +55,25 @@ build/.exists:
|
|||||||
@mkdir -p build/223015b build/223015c
|
@mkdir -p build/223015b build/223015c
|
||||||
@touch $@
|
@touch $@
|
||||||
|
|
||||||
# Development servers
|
# Development server
|
||||||
dev:
|
dev:
|
||||||
@./scripts/dev-server.sh
|
@./scripts/dev-server.sh
|
||||||
|
|
||||||
dev-kill:
|
dev-kill:
|
||||||
@-pkill -f "python3 -m http.server" 2>/dev/null || true
|
|
||||||
@-pkill -f "marp-cli.*--server" 2>/dev/null || true
|
@-pkill -f "marp-cli.*--server" 2>/dev/null || true
|
||||||
@sleep 0.5
|
@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
|
# Build functions
|
||||||
define build_course
|
define build_course
|
||||||
@echo "Building $(1)..."
|
@echo "Building $(1)..."
|
||||||
@mkdir -p build/$(1)
|
@mkdir -p build/$(1)
|
||||||
@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
|
@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
|
||||||
@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
|
@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
|
||||||
@for f in $($(1)_TERMINS); do \
|
@for f in $($(1)_KAPITEL); do \
|
||||||
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
|
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
|
||||||
echo " Building $$f..."; \
|
echo " Building $$f..."; \
|
||||||
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; \
|
||||||
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 \
|
fi \
|
||||||
done
|
done
|
||||||
@./scripts/generate-index.sh $(1) build/$(1)
|
@./scripts/generate-index.sh $(1) build/$(1)
|
||||||
@@ -110,12 +92,12 @@ build: build-b build-c
|
|||||||
define html_course
|
define html_course
|
||||||
@echo "Building HTML for $(1)..."
|
@echo "Building HTML for $(1)..."
|
||||||
@mkdir -p build/$(1)
|
@mkdir -p build/$(1)
|
||||||
@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
|
@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
|
||||||
@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
|
@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
|
||||||
@for f in $($(1)_TERMINS); do \
|
@for f in $($(1)_KAPITEL); do \
|
||||||
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
|
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
|
||||||
echo " $$f.html"; \
|
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 \
|
fi \
|
||||||
done
|
done
|
||||||
@./scripts/generate-index.sh $(1) build/$(1)
|
@./scripts/generate-index.sh $(1) build/$(1)
|
||||||
@@ -133,10 +115,10 @@ html: html-b html-c
|
|||||||
define pdf_course
|
define pdf_course
|
||||||
@echo "Building PDFs for $(1)..."
|
@echo "Building PDFs for $(1)..."
|
||||||
@mkdir -p build/$(1)
|
@mkdir -p build/$(1)
|
||||||
@for f in $($(1)_TERMINS); do \
|
@for f in $($(1)_KAPITEL); do \
|
||||||
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
|
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
|
||||||
echo " $$f.pdf"; \
|
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 \
|
fi \
|
||||||
done
|
done
|
||||||
endef
|
endef
|
||||||
@@ -149,6 +131,16 @@ pdf-c: build/.exists
|
|||||||
|
|
||||||
pdf: pdf-b pdf-c
|
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 Code generation (uses nix-shell)
|
||||||
qr:
|
qr:
|
||||||
ifndef URL
|
ifndef URL
|
||||||
@@ -174,9 +166,9 @@ ifndef COURSE
|
|||||||
@echo "Usage: make optimize-images COURSE=223015b"
|
@echo "Usage: make optimize-images COURSE=223015b"
|
||||||
else
|
else
|
||||||
@echo "Optimizing images for $(COURSE)..."
|
@echo "Optimizing images for $(COURSE)..."
|
||||||
@mkdir -p $(COURSE_DIR)/$(COURSE)/slides/assets-original
|
@mkdir -p $(SLIDES_DIR)/$(COURSE)/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 \
|
@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" $(COURSE_DIR)/$(COURSE)/slides/assets-original/ && \
|
[ -f "$$img" ] && cp "$$img" $(SLIDES_DIR)/$(COURSE)/assets-original/ && \
|
||||||
magick "$$img" -resize "1920x>" -quality 85 "$$img" && echo " Optimized: $$(basename $$img)"; \
|
magick "$$img" -resize "1920x>" -quality 85 "$$img" && echo " Optimized: $$(basename $$img)"; \
|
||||||
done || true'
|
done || true'
|
||||||
@echo "Done! Originals in assets-original/"
|
@echo "Done! Originals in assets-original/"
|
||||||
@@ -187,7 +179,8 @@ HDM_DEPLOY_PATH = /home/tengo/html/hdm
|
|||||||
|
|
||||||
build-index: build/.exists
|
build-index: build/.exists
|
||||||
@echo "Building root index..."
|
@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
|
# Deploy
|
||||||
define deploy_course
|
define deploy_course
|
||||||
|
|||||||
@@ -1,182 +1,97 @@
|
|||||||
# HdM Slides
|
# HdM Slides
|
||||||
|
|
||||||
**Modul "Technik 1"** - 1. Semester - Digital- und Medienwirtschaft
|
Presentation slides for HdM Stuttgart courses, built with [Marp](https://marp.app/).
|
||||||
Hochschule der Medien Stuttgart - Wintersemester 2025/26
|
|
||||||
|
|
||||||
---
|
## 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
|
|
||||||
```
|
```
|
||||||
|
slides/
|
||||||
### Ohne Nix
|
├── 223015b/ # Dateiformate course
|
||||||
|
│ ├── 00-intro.md
|
||||||
```bash
|
│ ├── 01-grundlagen-text-audio.md
|
||||||
npm install
|
│ └── ...
|
||||||
make dev-b # 223015b auf Port 1312
|
└── 223015c/ # Internettechnik course
|
||||||
make dev-c # 223015c auf Port 1313
|
├── 01-geschichte-grundlagen-html.md
|
||||||
|
└── ...
|
||||||
|
scripts/ # Build scripts
|
||||||
|
build/ # Generated output (gitignored)
|
||||||
```
|
```
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Development
|
## Development
|
||||||
|
|
||||||
### Dev Server starten
|
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
make dev-b # 223015b (Dateiformate) - http://localhost:1312
|
# Start development server (hot reload)
|
||||||
make dev-c # 223015c (Internettechnik) - http://localhost:1313
|
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
|
```bash
|
||||||
make build # Alle Kurse (HTML + PDF)
|
make build # Build all (HTML + PDF)
|
||||||
make build-b # Nur 223015b
|
make build-b # Build 223015b only
|
||||||
make build-c # Nur 223015c
|
make build-c # Build 223015c only
|
||||||
make html # Nur HTML
|
make html # HTML only
|
||||||
make pdf # Nur PDF
|
make pdf # PDF only
|
||||||
```
|
```
|
||||||
|
|
||||||
### Deploy
|
## Klausur Folien
|
||||||
|
|
||||||
|
Extract exam-relevant slides (marked with `<!-- _class: klausur -->`) into a single file:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
make deploy # Alle Kurse
|
make klausur # Extract all courses
|
||||||
make deploy-b # Nur 223015b
|
make klausur-b # 223015b only
|
||||||
make deploy-c # Nur 223015c
|
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
|
## 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
|
```bash
|
||||||
# Mit Nix
|
make deploy # Deploy all courses
|
||||||
nix run .#qr -- "https://librete.ch/hdm/223015b/"
|
make deploy-b # Deploy 223015b only
|
||||||
nix run .#qr -- "https://example.com" output.png
|
make deploy-c # Deploy 223015c only
|
||||||
|
|
||||||
# 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
|
|
||||||
```
|
```
|
||||||
|
|
||||||
### Bilder optimieren
|
## Marking Slides as Klausur-Relevant
|
||||||
|
|
||||||
```bash
|
Add this comment block after the slide separator:
|
||||||
# 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
|
|
||||||
|
|
||||||
```markdown
|
```markdown
|
||||||
# Slide 1
|
|
||||||
|
|
||||||
Content
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Slide 2
|
<!-- _class: klausur -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
<!-- _backgroundColor: #e3f2fd -->
|
||||||
|
|
||||||
More content
|
# Your Slide Title
|
||||||
|
|
||||||
|
Content here...
|
||||||
```
|
```
|
||||||
|
|
||||||
### Bilder
|
The `klausur` class adds a visual indicator (diagonal stripes) during presentation.
|
||||||
|
|
||||||
```markdown
|
|
||||||

|
|
||||||
```
|
|
||||||
|
|
||||||
### Themes
|
|
||||||
|
|
||||||
Built-in: `default`, `gaia`, `uncover`
|
|
||||||
Custom: in `themes/` Verzeichnis
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## License
|
|
||||||
|
|
||||||
[CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/)
|
|
||||||
@@ -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: <head> vs. <body></text></n>
|
||||||
|
<questiontext type="html">
|
||||||
|
<text><![CDATA[
|
||||||
|
<p>Ein Student erstellt eine Webseite und platziert <em>alles</em>
|
||||||
|
im <code><body></code> – auch den <code><title></code>
|
||||||
|
und die <code><meta name="description"></code>.</p>
|
||||||
|
<p><strong>Welche zwei konkreten Konsequenzen hat das?</p>
|
||||||
|
]]></text>
|
||||||
|
</questiontext>
|
||||||
|
<generalfeedback type="html"><text>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.</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 – <head> und <body> 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><head></code> und <code><body></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><meta charset></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><p class="highlight" id="main">Text</p></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 < 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 < 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><p></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>
|
||||||
@@ -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 -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
# 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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
<!-- _class: lead -->
|
|
||||||
|
|
||||||
# Termin 2 – 09.01.2026
|
|
||||||
## Bild-, Audio- & Videoformate
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
<!-- _header: '' -->
|
|
||||||
<!-- _footer: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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)
|
|
||||||
-->
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
# 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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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: '' -->
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
<!--
|
|
||||||
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/
|
|
||||||
|
|
||||||
@@ -9,7 +9,8 @@
|
|||||||
outputs = { self, nixpkgs, flake-utils }:
|
outputs = { self, nixpkgs, flake-utils }:
|
||||||
flake-utils.lib.eachDefaultSystem (system:
|
flake-utils.lib.eachDefaultSystem (system:
|
||||||
let
|
let
|
||||||
pkgs = nixpkgs.legacyPackages.${system};
|
pkgs = import nixpkgs { inherit system; config.allowUnfree = true; };
|
||||||
|
|
||||||
|
|
||||||
# QR code generator script
|
# QR code generator script
|
||||||
qr-gen = pkgs.writeShellScriptBin "qr" ''
|
qr-gen = pkgs.writeShellScriptBin "qr" ''
|
||||||
@@ -77,6 +78,7 @@
|
|||||||
qrencode
|
qrencode
|
||||||
imagemagick
|
imagemagick
|
||||||
gnumake
|
gnumake
|
||||||
|
claude-code
|
||||||
];
|
];
|
||||||
|
|
||||||
shellHook = ''
|
shellHook = ''
|
||||||
|
|||||||
@@ -3,13 +3,14 @@
|
|||||||
"version": "1.0.0",
|
"version": "1.0.0",
|
||||||
"description": "HdM Stuttgart - Lecture Slides (Marp)",
|
"description": "HdM Stuttgart - Lecture Slides (Marp)",
|
||||||
"scripts": {
|
"scripts": {
|
||||||
"dev:b": "PORT=1312 marp --server --allow-local-files courses/223015b/slides/",
|
"dev": "PORT=3000 marp --server --allow-local-files slides/",
|
||||||
"dev:c": "PORT=1313 marp --server --allow-local-files courses/223015c/slides/",
|
|
||||||
"build": "make build",
|
"build": "make build",
|
||||||
"build:b": "make build-b",
|
"build:b": "make build-b",
|
||||||
"build:c": "make build-c",
|
"build:c": "make build-c",
|
||||||
"pdf": "make pdf",
|
"pdf": "make pdf",
|
||||||
"html": "make html",
|
"html": "make html",
|
||||||
|
"klausur": "make klausur",
|
||||||
|
"deploy": "make deploy",
|
||||||
"test": "echo \"No tests specified\" && exit 0"
|
"test": "echo \"No tests specified\" && exit 0"
|
||||||
},
|
},
|
||||||
"keywords": ["marp", "slides", "hdm", "lectures"],
|
"keywords": ["marp", "slides", "hdm", "lectures"],
|
||||||
|
|||||||
@@ -1,106 +1,53 @@
|
|||||||
#!/usr/bin/env bash
|
#!/usr/bin/env bash
|
||||||
# Development server script for HdM slides
|
# Simplified development server for HdM slides
|
||||||
# Starts index server + marp servers for each course
|
# Starts single Marp server for all courses
|
||||||
|
|
||||||
set -e
|
set -e
|
||||||
|
|
||||||
# Configuration
|
# Configuration
|
||||||
INDEX_PORT=1310
|
SLIDES_DIR="slides"
|
||||||
COURSE_B_PORT=1311
|
DEV_PORT=3000
|
||||||
COURSE_C_PORT=1312
|
|
||||||
COURSE_DIR="courses"
|
|
||||||
DEV_INDEX_DIR=".dev-index"
|
|
||||||
|
|
||||||
# Colors
|
# Colors
|
||||||
RED='\033[0;31m'
|
|
||||||
GREEN='\033[0;32m'
|
GREEN='\033[0;32m'
|
||||||
BLUE='\033[0;34m'
|
BLUE='\033[0;34m'
|
||||||
|
RED='\033[0;31m'
|
||||||
NC='\033[0m' # No Color
|
NC='\033[0m' # No Color
|
||||||
|
|
||||||
# Cleanup function
|
# Cleanup function
|
||||||
cleanup() {
|
cleanup() {
|
||||||
echo -e "\n${RED}Shutting down servers...${NC}"
|
echo -e "\n${RED}Shutting down dev server...${NC}"
|
||||||
kill $PID_INDEX $PID_B $PID_C 2>/dev/null || true
|
pkill -f "marp-cli.*--server" 2>/dev/null || true
|
||||||
exit 0
|
exit 0
|
||||||
}
|
}
|
||||||
|
|
||||||
# Kill existing processes on our ports
|
# Kill existing processes on our port
|
||||||
kill_existing() {
|
kill_existing() {
|
||||||
echo -e "${BLUE}Cleaning up existing processes...${NC}"
|
echo -e "${BLUE}Cleaning up existing processes...${NC}"
|
||||||
# Kill marp processes first
|
|
||||||
pkill -9 -f "marp-cli" 2>/dev/null || true
|
pkill -9 -f "marp-cli" 2>/dev/null || true
|
||||||
pkill -f "python3 -m http.server" 2>/dev/null || true
|
fuser -k $DEV_PORT/tcp 2>/dev/null || true
|
||||||
# Kill ports including marp's WebSocket ports (37717-37720 range)
|
sleep 1
|
||||||
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
|
|
||||||
}
|
}
|
||||||
|
|
||||||
# Main
|
# Main
|
||||||
trap cleanup SIGINT SIGTERM
|
trap cleanup SIGINT SIGTERM
|
||||||
|
|
||||||
kill_existing
|
kill_existing
|
||||||
generate_index
|
|
||||||
|
|
||||||
echo -e "${GREEN}Starting development servers...${NC}"
|
echo -e "${GREEN}Starting development server...${NC}"
|
||||||
echo ""
|
echo ""
|
||||||
echo -e " Index: ${BLUE}http://localhost:$INDEX_PORT${NC}"
|
echo -e " Server: ${BLUE}http://localhost:$DEV_PORT${NC}"
|
||||||
echo -e " 223015b: ${BLUE}http://localhost:$COURSE_B_PORT${NC}"
|
echo -e " Slides: ${BLUE}$SLIDES_DIR/${NC}"
|
||||||
echo -e " 223015c: ${BLUE}http://localhost:$COURSE_C_PORT${NC}"
|
|
||||||
echo ""
|
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 ""
|
echo ""
|
||||||
|
|
||||||
# Start servers
|
# Start single Marp server for all slides
|
||||||
python3 -m http.server $INDEX_PORT --directory "$DEV_INDEX_DIR" &
|
PORT=$DEV_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/"
|
||||||
PID_INDEX=$!
|
|
||||||
|
|
||||||
PORT=$COURSE_B_PORT npx @marp-team/marp-cli --server "$COURSE_DIR/223015b/slides/" &
|
# Wait for process to exit
|
||||||
PID_B=$!
|
wait
|
||||||
|
|
||||||
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
|
|
||||||
@@ -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"
|
||||||
@@ -41,6 +41,16 @@ TOPIC_MAP["vertiefung-offene-fragen"]="Vertiefung & Offene Fragen"
|
|||||||
TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
|
TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
|
||||||
TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
|
TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
|
||||||
TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
|
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
|
cat > "$BUILD_DIR/index.html" << HEADER
|
||||||
<!DOCTYPE html>
|
<!DOCTYPE html>
|
||||||
@@ -61,6 +71,15 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
|||||||
line-height: 1.5;
|
line-height: 1.5;
|
||||||
}
|
}
|
||||||
header { margin-bottom: 2rem; }
|
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 {
|
h1 {
|
||||||
font-size: 1.75rem;
|
font-size: 1.75rem;
|
||||||
font-weight: 600;
|
font-weight: 600;
|
||||||
@@ -68,6 +87,12 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
|||||||
margin-bottom: 0.5rem;
|
margin-bottom: 0.5rem;
|
||||||
color: $ACCENT_COLOR;
|
color: $ACCENT_COLOR;
|
||||||
}
|
}
|
||||||
|
.course-heading {
|
||||||
|
font-size: 1.25rem;
|
||||||
|
font-weight: 500;
|
||||||
|
color: #1d1d1f;
|
||||||
|
margin-bottom: 0.25rem;
|
||||||
|
}
|
||||||
.subtitle {
|
.subtitle {
|
||||||
color: #86868b;
|
color: #86868b;
|
||||||
font-size: 0.95rem;
|
font-size: 0.95rem;
|
||||||
@@ -77,13 +102,14 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
|||||||
font-size: 0.875rem;
|
font-size: 0.875rem;
|
||||||
margin-top: 0.25rem;
|
margin-top: 0.25rem;
|
||||||
}
|
}
|
||||||
|
/* Use the .termine wrapper and add a gap between cards */
|
||||||
.termine {
|
.termine {
|
||||||
margin-top: 1.5rem;
|
margin-top: 1.5rem;
|
||||||
display: flex;
|
display: flex;
|
||||||
flex-direction: column;
|
flex-direction: column;
|
||||||
gap: 0.75rem;
|
gap: 0.75rem;
|
||||||
}
|
}
|
||||||
.termin-card {
|
.kapitel-card {
|
||||||
position: relative;
|
position: relative;
|
||||||
background: #fff;
|
background: #fff;
|
||||||
border-radius: 12px;
|
border-radius: 12px;
|
||||||
@@ -93,32 +119,35 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
|||||||
grid-template-columns: 1fr auto auto;
|
grid-template-columns: 1fr auto auto;
|
||||||
align-items: center;
|
align-items: center;
|
||||||
gap: 1rem;
|
gap: 1rem;
|
||||||
|
padding: 0; /* inner padding handled by kapitel-link */
|
||||||
}
|
}
|
||||||
.termin-card:hover {
|
.kapitel-card:hover {
|
||||||
transform: translateY(-2px);
|
transform: translateY(-2px);
|
||||||
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
|
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
|
||||||
}
|
}
|
||||||
.termin-link {
|
.kapitel-link {
|
||||||
display: block;
|
display: block;
|
||||||
padding: 1.25rem 1.5rem;
|
padding: 1.25rem 1.5rem;
|
||||||
text-decoration: none;
|
text-decoration: none;
|
||||||
color: inherit;
|
color: inherit;
|
||||||
grid-column: 1;
|
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-size: 0.7rem;
|
||||||
font-weight: 600;
|
font-weight: 600;
|
||||||
color: $ACCENT_COLOR;
|
color: $ACCENT_COLOR;
|
||||||
text-transform: uppercase;
|
text-transform: uppercase;
|
||||||
letter-spacing: 0.05em;
|
letter-spacing: 0.05em;
|
||||||
}
|
}
|
||||||
.termin-title {
|
.kapitel-title {
|
||||||
font-size: 1.05rem;
|
font-size: 1.05rem;
|
||||||
font-weight: 500;
|
font-weight: 500;
|
||||||
color: #1d1d1f;
|
color: #1d1d1f;
|
||||||
margin: 0.15rem 0;
|
margin: 0.15rem 0;
|
||||||
}
|
}
|
||||||
.termin-date {
|
.kapitel-date {
|
||||||
font-size: 0.8rem;
|
font-size: 0.8rem;
|
||||||
color: #86868b;
|
color: #86868b;
|
||||||
}
|
}
|
||||||
@@ -135,11 +164,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
|||||||
white-space: nowrap;
|
white-space: nowrap;
|
||||||
position: relative;
|
position: relative;
|
||||||
z-index: 1;
|
z-index: 1;
|
||||||
|
margin-right: 0.5rem;
|
||||||
}
|
}
|
||||||
.btn-slides {
|
.btn-slides {
|
||||||
background: $ACCENT_COLOR;
|
background: $ACCENT_COLOR;
|
||||||
color: #fff;
|
color: #fff;
|
||||||
margin-right: 0.5rem;
|
|
||||||
}
|
}
|
||||||
.btn-slides:hover {
|
.btn-slides:hover {
|
||||||
filter: brightness(1.1);
|
filter: brightness(1.1);
|
||||||
@@ -147,11 +176,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
|||||||
.btn-pdf {
|
.btn-pdf {
|
||||||
background: #f5f5f7;
|
background: #f5f5f7;
|
||||||
color: #1d1d1f;
|
color: #1d1d1f;
|
||||||
margin-right: 1rem;
|
|
||||||
}
|
}
|
||||||
.btn-pdf:hover { background: #e8e8ed; }
|
.btn-pdf:hover { background: #e8e8ed; }
|
||||||
|
.btn-disabled { opacity: 0.6; pointer-events: none; }
|
||||||
/* Make entire card clickable via overlay */
|
/* Make entire card clickable via overlay */
|
||||||
.termin-link::after {
|
.kapitel-link::after {
|
||||||
content: '';
|
content: '';
|
||||||
position: absolute;
|
position: absolute;
|
||||||
inset: 0;
|
inset: 0;
|
||||||
@@ -184,10 +213,10 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
|||||||
color: #86868b;
|
color: #86868b;
|
||||||
}
|
}
|
||||||
@media (max-width: 600px) {
|
@media (max-width: 600px) {
|
||||||
.termin-card {
|
.kapitel-card {
|
||||||
grid-template-columns: 1fr;
|
grid-template-columns: 1fr;
|
||||||
}
|
}
|
||||||
.termin-link {
|
.kapitel-link {
|
||||||
padding-bottom: 0.75rem;
|
padding-bottom: 0.75rem;
|
||||||
}
|
}
|
||||||
.btn-slides, .btn-pdf {
|
.btn-slides, .btn-pdf {
|
||||||
@@ -198,63 +227,140 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
|||||||
</head>
|
</head>
|
||||||
<body>
|
<body>
|
||||||
<header>
|
<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="subtitle">$SUBTITLE</p>
|
||||||
<p class="meta">HdM Stuttgart · Wintersemester 2025/26 · Michael Czechowski</p>
|
<p class="meta">HdM Stuttgart · Wintersemester 2025/26 · Michael Czechowski</p>
|
||||||
</header>
|
</header>
|
||||||
<div class="termine">
|
<div class="termine">
|
||||||
HEADER
|
HEADER
|
||||||
|
|
||||||
# Generate links for each termin (sorted)
|
# Generate links for each kapitel (sorted)
|
||||||
for html in $(ls "$BUILD_DIR"/2*.html 2>/dev/null | sort); do
|
for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
|
||||||
filename=$(basename "$html")
|
filename=$(basename "$html")
|
||||||
|
|
||||||
# Extract components from filename
|
# Extract components from filename (format: NN-topic.html)
|
||||||
date=$(echo "$filename" | grep -oE '^[0-9]{4}-[0-9x]{2}-[0-9x]{2}')
|
kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
|
||||||
termin_num=$(echo "$filename" | grep -oE 'termin-[0-9]+' | grep -oE '[0-9]+')
|
topic_raw=$(echo "$filename" | sed -E 's/^[0-9]+-//' | sed 's/\.html$//')
|
||||||
topic_raw=$(echo "$filename" | sed -E 's/^[0-9]{4}-[0-9x]{2}-[0-9x]{2}-termin-[0-9]+-//' | sed 's/\.html$//')
|
|
||||||
|
|
||||||
# Look up nice topic name or fallback
|
# Look up nice topic name or fallback
|
||||||
topic="${TOPIC_MAP[$topic_raw]}"
|
topic="${TOPIC_MAP[$topic_raw]}"
|
||||||
if [[ -z "$topic" ]]; then
|
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
|
fi
|
||||||
|
|
||||||
# Format date
|
# Handle kapitel number
|
||||||
if [[ "$date" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]] && [[ ! "$date" =~ xx ]]; then
|
if [[ "$kapitel_num" == "0" ]] || [[ -z "$kapitel_num" ]]; then
|
||||||
formatted_date=$(date -d "$date" "+%d. %B %Y" 2>/dev/null || echo "$date")
|
kapitel_label="Einführung"
|
||||||
else
|
else
|
||||||
formatted_date="Termin folgt"
|
kapitel_label="Kapitel $kapitel_num"
|
||||||
fi
|
|
||||||
|
|
||||||
# Handle termin number
|
|
||||||
if [[ "$termin_num" == "0" ]]; then
|
|
||||||
termin_label="Einführung"
|
|
||||||
else
|
|
||||||
termin_label="Termin $termin_num"
|
|
||||||
fi
|
fi
|
||||||
|
|
||||||
pdf_filename="${filename%.html}.pdf"
|
pdf_filename="${filename%.html}.pdf"
|
||||||
|
|
||||||
# Check if PDF exists
|
# Determine whether this topic is configured as disabled for this course
|
||||||
pdf_link=""
|
disabled_full=false
|
||||||
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
|
disabled_buttons=false
|
||||||
pdf_link="<a href=\"$pdf_filename\" class=\"btn btn-pdf\">PDF</a>"
|
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
|
fi
|
||||||
|
|
||||||
cat >> "$BUILD_DIR/index.html" << LINK
|
cat >> "$BUILD_DIR/index.html" << LINK
|
||||||
<div class="termin-card">
|
<div class="$card_class">
|
||||||
<a href="$filename" class="termin-link">
|
$link_html
|
||||||
<div class="termin-label">$termin_label</div>
|
$slides_html
|
||||||
<div class="termin-title">$topic</div>
|
$pdf_html
|
||||||
<div class="termin-date">$formatted_date</div>
|
|
||||||
</a>
|
|
||||||
<a href="$filename" class="btn btn-slides">Folien</a>
|
|
||||||
$pdf_link
|
|
||||||
</div>
|
</div>
|
||||||
LINK
|
LINK
|
||||||
|
|
||||||
done
|
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
|
cat >> "$BUILD_DIR/index.html" << FOOTER
|
||||||
</div>
|
</div>
|
||||||
<div class="qr-section">
|
<div class="qr-section">
|
||||||
@@ -263,7 +369,7 @@ cat >> "$BUILD_DIR/index.html" << FOOTER
|
|||||||
</div>
|
</div>
|
||||||
<footer>
|
<footer>
|
||||||
<a href="mailto:mail@librete.ch">Kontakt</a> ·
|
<a href="mailto:mail@librete.ch">Kontakt</a> ·
|
||||||
<a href="../">Alle Kurse</a>
|
<a href="../">Kursübersicht</a>
|
||||||
</footer>
|
</footer>
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
|
|||||||
@@ -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">Wintersemester 2025/26 · 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 & 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,7 +3,7 @@ marp: true
|
|||||||
theme: gaia
|
theme: gaia
|
||||||
paginate: true
|
paginate: true
|
||||||
backgroundColor: #fff
|
backgroundColor: #fff
|
||||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
|
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||||
---
|
---
|
||||||
@@ -49,9 +49,23 @@ a {
|
|||||||
color: var(--color-highlight);
|
color: var(--color-highlight);
|
||||||
}
|
}
|
||||||
section.klausur {
|
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;
|
background: #e3f2fd !important;
|
||||||
}
|
}
|
||||||
section.klausur footer {
|
section.aufgabe footer {
|
||||||
display: none;
|
display: none;
|
||||||
}
|
}
|
||||||
</style>
|
</style>
|
||||||
@@ -95,7 +109,7 @@ Hochschule der Medien Stuttgart
|
|||||||
- Hintergrund:
|
- Hintergrund:
|
||||||
- Philosophie (Uni Stuttgart) -> NO degree
|
- Philosophie (Uni Stuttgart) -> NO degree
|
||||||
- Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
|
- Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
|
||||||
- Kontakt: mail@librete.ch
|
- Kontakt: lb-czechowski@hdm-stuttgart.de
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
Kurze Vorstellung
|
Kurze Vorstellung
|
||||||
@@ -0,0 +1,781 @@
|
|||||||
|
---
|
||||||
|
marp: true
|
||||||
|
theme: gaia
|
||||||
|
paginate: true
|
||||||
|
backgroundColor: #fff
|
||||||
|
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||||
|
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: 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>
|
||||||
|
|
||||||
|
<!-- _class: invert -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _backgroundColor: #000 -->
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
# 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: '' -->
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
# Kapitel 3 – 23.01.2026
|
||||||
|
## Speichermedien & Schnittstellen
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
<!--
|
||||||
|
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: 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: '' -->
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
<!--
|
||||||
|
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
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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,7 +3,7 @@ marp: true
|
|||||||
theme: gaia
|
theme: gaia
|
||||||
paginate: true
|
paginate: true
|
||||||
backgroundColor: #fff
|
backgroundColor: #fff
|
||||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
|
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||||
---
|
---
|
||||||
@@ -49,9 +49,23 @@ a {
|
|||||||
color: var(--color-highlight);
|
color: var(--color-highlight);
|
||||||
}
|
}
|
||||||
section.klausur {
|
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;
|
background: #e3f2fd !important;
|
||||||
}
|
}
|
||||||
section.klausur footer {
|
section.aufgabe footer {
|
||||||
display: none;
|
display: none;
|
||||||
}
|
}
|
||||||
</style>
|
</style>
|
||||||
@@ -84,7 +98,7 @@ Hochschule der Medien Stuttgart
|
|||||||
|
|
||||||
<!-- _class: lead -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Termin 4 – 30.01.2026
|
# Kapitel 4 – 30.01.2026
|
||||||
## Distribution, APIs & Zukunft
|
## Distribution, APIs & Zukunft
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -1252,7 +1266,7 @@ Dangerzone: FOSS-Tool (Freedom of Press Foundation)
|
|||||||
**Offene Formate:**
|
**Offene Formate:**
|
||||||
✓ Spezifikation öffentlich
|
✓ Spezifikation öffentlich
|
||||||
✓ Keine Lizenzgebühren
|
✓ Keine Lizenzgebühren
|
||||||
✓ Viele Programme unterstützen
|
✓ Viele Programme unterstützen1
|
||||||
**Beispiele:** PNG, OGG, MKV, Markdown, SVG
|
**Beispiele:** PNG, OGG, MKV, Markdown, SVG
|
||||||
|
|
||||||
**Proprietäre Formate:**
|
**Proprietäre Formate:**
|
||||||
@@ -1267,7 +1281,7 @@ Lock-in: "Gefangene Daten" (nur in Software X öffenbar)
|
|||||||
Firma geht pleite → Format stirbt (WordPerfect-Beispiel)
|
Firma geht pleite → Format stirbt (WordPerfect-Beispiel)
|
||||||
Offene Standards: Überlebensfähiger (Community kann implementieren)
|
Offene Standards: Überlebensfähiger (Community kann implementieren)
|
||||||
-->
|
-->
|
||||||
|
111
|
||||||
---
|
---
|
||||||
|
|
||||||
# Vendor Lock-in: Beispiele
|
# Vendor Lock-in: Beispiele
|
||||||
@@ -1839,7 +1853,7 @@ Evaluation: Feedback ernst nehmen, Kurs verbessern
|
|||||||
|
|
||||||
# Fragen & Diskussion
|
# Fragen & Diskussion
|
||||||
|
|
||||||
**Kontakt:** mail@librete.ch
|
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||||||
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -3,7 +3,7 @@ marp: true
|
|||||||
theme: gaia
|
theme: gaia
|
||||||
paginate: true
|
paginate: true
|
||||||
backgroundColor: #fff
|
backgroundColor: #fff
|
||||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
|
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||||
---
|
---
|
||||||
@@ -49,9 +49,23 @@ a {
|
|||||||
color: var(--color-highlight);
|
color: var(--color-highlight);
|
||||||
}
|
}
|
||||||
section.klausur {
|
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;
|
background: #e3f2fd !important;
|
||||||
}
|
}
|
||||||
section.klausur footer {
|
section.aufgabe footer {
|
||||||
display: none;
|
display: none;
|
||||||
}
|
}
|
||||||
</style>
|
</style>
|
||||||
@@ -84,7 +98,7 @@ Hochschule der Medien Stuttgart
|
|||||||
|
|
||||||
<!-- _class: lead -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Termin 5 – TBA
|
# Kapitel 5 – TBA
|
||||||
## Vertiefung & Offene Fragen
|
## Vertiefung & Offene Fragen
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -110,7 +124,7 @@ Themen nach Interesse der Studierenden
|
|||||||
|
|
||||||
# Fragen & Diskussion
|
# Fragen & Diskussion
|
||||||
|
|
||||||
**Kontakt:** mail@librete.ch
|
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||||||
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
||||||
|
|
||||||
---
|
---
|
||||||
|
After Width: | Height: | Size: 220 KiB |
|
After Width: | Height: | Size: 9.2 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 425 KiB |
|
After Width: | Height: | Size: 64 KiB |
|
After Width: | Height: | Size: 28 KiB |
|
After Width: | Height: | Size: 241 KiB |
|
After Width: | Height: | Size: 484 KiB |
|
After Width: | Height: | Size: 249 KiB |
|
After Width: | Height: | Size: 388 KiB |
|
After Width: | Height: | Size: 27 KiB |
|
After Width: | Height: | Size: 161 KiB |
|
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 |
|
After Width: | Height: | Size: 97 KiB |
|
After Width: | Height: | Size: 38 KiB |
|
After Width: | Height: | Size: 465 KiB |
|
After Width: | Height: | Size: 29 KiB |
@@ -0,0 +1,458 @@
|
|||||||
|
---
|
||||||
|
marp: true
|
||||||
|
theme: gaia
|
||||||
|
paginate: true
|
||||||
|
backgroundColor: #fff
|
||||||
|
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||||
|
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: 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 -->
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
# 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: "" -->
|
||||||
|
|
||||||
|
|
||||||
|
# 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: "" -->
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
# 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
|
||||||
|
-->
|
||||||
@@ -0,0 +1,924 @@
|
|||||||
|
---
|
||||||
|
marp: true
|
||||||
|
theme: gaia
|
||||||
|
paginate: true
|
||||||
|
backgroundColor: #fff
|
||||||
|
header: "Klausurfragen – 223015b"
|
||||||
|
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||||
|
title: "Klausurfragen – Dateiformate, Schnittstellen, Speichermedien"
|
||||||
|
---
|
||||||
|
<style>
|
||||||
|
:root {
|
||||||
|
--color-foreground: #1a1a2e;
|
||||||
|
--color-highlight: #1e5f8a;
|
||||||
|
--color-dimmed: #4a4a6a;
|
||||||
|
}
|
||||||
|
section.invert { --color-foreground: #fff; }
|
||||||
|
section { font-size: 1.325rem; }
|
||||||
|
h1 { color: #1e5f8a; }
|
||||||
|
section.invert h1 { color: #fff; }
|
||||||
|
h2 { color: #1f2937; }
|
||||||
|
pre { background: #0f0f23; border-radius: 8px; }
|
||||||
|
pre code { background: transparent; color: inherit; }
|
||||||
|
a { color: var(--color-highlight); }
|
||||||
|
section.disable { opacity: 0.3; }
|
||||||
|
</style>
|
||||||
|
|
||||||
|
# Klausurfragen – 223015b
|
||||||
|
**Dateiformate, Schnittstellen, Speichermedien · HdM Stuttgart · M. Czechowski**
|
||||||
|
|
||||||
|
<small>Stand: 02.02.2026</small>
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
> **Legende – Moodle XML-Typen:**
|
||||||
|
> `[MC]` = `multichoice` (einzelne Auswahl)
|
||||||
|
> `[MM]` = `multichoice` + `<single>false</single>` (Mehrfachauswahl)
|
||||||
|
> `[MATCH]` = `matching` (Zuordnung)
|
||||||
|
> `[ORDER]` = `ordering` (Reihenfolge)
|
||||||
|
> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
|
||||||
|
> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
|
||||||
|
> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
|
||||||
|
> `[CLOZE]` = `cloze` (Lückentext, gemischt)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
## BLOCK J – Dateiformate: Grundbegriffe
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J1 – Was bedeutet „komprimieren"?
|
||||||
|
**Thema:** Grundbegriffe – Kompression
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was bedeutet es, eine Datei zu komprimieren?
|
||||||
|
|
||||||
|
- [ ] Die Datei wird auf einem anderen Speichermedium gesichert.
|
||||||
|
- [x] **Die Dateigröße wird durch Entfernung oder Vereinfachung von Daten reduziert.** ✅
|
||||||
|
- [ ] Die Datei wird verschlüsselt, damit sie kleiner aussieht.
|
||||||
|
- [ ] Die Datei wird in ein anderen Format umgewandelt, ohne dass sich die Größe ändert.
|
||||||
|
|
||||||
|
> **Feedback:** Kompression = Dateigröße reduzieren. Zwei Familien: verlustfrei (alle Daten bleiben erhalten, z. B. ZIP, PNG) und verlustbehaftet (Daten werden dauerhaft weggeworfen, z. B. JPEG, MP3).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J2 – Verlustfrei vs. verlustbehaftet
|
||||||
|
**Thema:** Grundbegriffe – Kompressionsprimitiven
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jedem Format zu, ob es verlustfrei oder verlustbehaftet komprimiert.
|
||||||
|
|
||||||
|
| Format | Kompressions-Typ |
|
||||||
|
|---|---|
|
||||||
|
| JPEG | Verlustbehaftet |
|
||||||
|
| PNG | Verlustfrei |
|
||||||
|
| MP3 | Verlustbehaftet |
|
||||||
|
| ZIP | Verlustfrei |
|
||||||
|
| FLAC | Verlustfrei |
|
||||||
|
| WebP (lossy) | Verlustbehaftet |
|
||||||
|
|
||||||
|
> **Feedback:** Verlustfrei = Originaldaten perfekt rekonstruierbar (ZIP, PNG, FLAC). Verlustbehaftet = Daten dauerhaft weggeworfen, nicht mehr zurückholbar (JPEG, MP3).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J3 – Verlustfrei vs. verlustbehaftet: Erkläre
|
||||||
|
**Thema:** Grundbegriffe – Konzept
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ESSAY]`
|
||||||
|
|
||||||
|
Erkläre den Unterschied zwischen verlustfreier und verlustbehafteter Kompression. Nenne je ein konkretes Beispiel und erkläre, warum man in unterschiedlichen Situationen unterschiedliche Kompressionstypen wählt.
|
||||||
|
|
||||||
|
> **Musterlösung:** Verlustfrei: Alle Originaldaten bleiben erhalten – die Datei kann perfekt rekonstruiert werden (z. B. ZIP, PNG). Verlustbehaftet: Daten werden dauerhaft weggeworfen – die Datei kann nicht mehr perfekt hergestellt werden (z. B. JPEG, MP3). Wahl: Fotos fürs Web → JPEG (verlustbehaftet), weil der Unterschied kaum sichtbar ist und die Datei deutlich kleiner wird. Archivierung oder Grafiken → PNG (verlustfrei), weil Qualitätsverlust inakzeptabel wäre.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J4 – Was bedeutet „skalieren"?
|
||||||
|
**Thema:** Grundbegriffe – Skalierung
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was passiert, wenn ein Rasterbild vergrößert wird?
|
||||||
|
|
||||||
|
- [ ] Neue Pixel werden aus dem Dateiformat automatisch geladen.
|
||||||
|
- [x] **Fehlende Pixel müssen durch Interpolation „erfunden" werden – es entsteht keine neue Information.** ✅
|
||||||
|
- [ ] Das Bild wird verlustfrei größer, weil Pixel automatisch duplifiziert werden.
|
||||||
|
- [ ] Die Dateigröße bleibt gleich, nur der Zoom im Betrachter ändert sich.
|
||||||
|
|
||||||
|
> **Feedback:** Ein Rasterbild hat eine native Auflösung. Alles darüber hinaus = Schätzung (Interpolation). Deshalb werden vergrößerte Rasterbilder unscharf – es gibt einfach keine Daten für die fehlenden Pixel.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J5 – Was bedeutet „konvertieren"?
|
||||||
|
**Thema:** Grundbegriffe – Konvertierung
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was bedeutet es, eine Datei zu konvertieren?
|
||||||
|
|
||||||
|
- [ ] Die Datei wird komprimiert und umbenannt.
|
||||||
|
- [x] **Die Daten werden von einem Format in ein anderes umgewandelt (z. B. JPEG → PNG, MP4 → WebM).** ✅
|
||||||
|
- [ ] Die Datei wird verschlüsselt und in ein neues Format gepackt.
|
||||||
|
- [ ] Die Dateiendung wird umbenannt, ohne dass sich der Inhalt ändert.
|
||||||
|
|
||||||
|
> **Feedback:** Konvertierung = Format-Umwandlung. Der Inhalt bleibt inhaltlich gleich, aber die Art der Speicherung (Kompression, Struktur) ändert sich. Wichtig: Eine Dateiendung umzubenennen ist KEINE Konvertierung.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J6 – Was bedeutet „codieren" und „decodieren"?
|
||||||
|
**Thema:** Grundbegriffe – Codec-Konzept
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ESSAY]`
|
||||||
|
|
||||||
|
Erkläre, was „codieren" und „decodieren" bedeuten. Erkläre anschließend, warum der Begriff „Codec" aus beiden Wörtern zusammengesetzt ist, und nenne ein konkretes Beispiel.
|
||||||
|
|
||||||
|
> **Musterlösung:** Codieren = Daten in ein bestimmtes Format umwandeln (z. B. Rohvideodaten → H.264-komprimiertes Video). Decodieren = das Gegenteil: komprimierte Daten wieder in abspielbare Form zurückwandeln (z. B. H.264 → Pixeldaten für den Bildschirm). Codec = Co(der) + Dec(oder) – ein Algorithmus, der beides kann. Beispiel: H.264 ist ein Video-Codec: Der Encoder erzeugt die komprimierte Datei, der Decoder im Player spielt sie wieder ab.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J7 – Codec vs. Container
|
||||||
|
**Thema:** Grundbegriffe – Codec/Container-Unterschied
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was ist der Unterschied zwischen einem Container und einem Codec bei Videodateien?
|
||||||
|
|
||||||
|
- [ ] Container und Codec sind synonyme Begriffe für das gleiche Konzept.
|
||||||
|
- [x] **Der Container (z. B. MP4) ist die „Verpackung", die verschiedene Streams zusammenpackt. Der Codec (z. B. H.264) bestimmt, wie der Video-Stream komprimiert wird.** ✅
|
||||||
|
- [ ] Der Codec ist die Dateiendung, der Container der Kompressionsalgorithmus.
|
||||||
|
- [ ] Ein Container enthält immer genau einen Codec – es kann keine Kombination geben.
|
||||||
|
|
||||||
|
> **Feedback:** Container ≠ Codec. Ein MP4-Container kann H.264, H.265 oder AV1 enthalten. Gleiche Endung `.mp4`, unterschiedlicher Inhalt. Der Container packt zusammen (Video, Audio, Untertitel, Metadaten), der Codec komprimiert.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J8 – Codec vs. Container: Zuordnung
|
||||||
|
**Thema:** Grundbegriffe – Codec/Container-Zuordnung
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne zu: Container oder Codec?
|
||||||
|
|
||||||
|
| Name | Typ |
|
||||||
|
|---|---|
|
||||||
|
| MP4 | Container |
|
||||||
|
| H.264 | Codec |
|
||||||
|
| WebM | Container |
|
||||||
|
| AV1 | Codec |
|
||||||
|
> **Feedback:** Container = Dateiformat, das Streams zusammenpackt (MP4, MKV, WebM). Codec = Kompressionsalgorithmus für einen bestimmten Stream (H.264, AV1, AAC).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J9 – Redundanz vs. Irrelevanz
|
||||||
|
**Thema:** Grundbegriffe – Kompressionsprinzipien
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Verlustfreie und verlustbehaftete Kompression arbeiten nach unterschiedlichen Prinzipien. Ordne zu.
|
||||||
|
|
||||||
|
| Prinzip | Kompressionstyp |
|
||||||
|
|---|---|
|
||||||
|
| Redundanz entfernen (wiederholende Muster kompakter darstellen) | Verlustfrei |
|
||||||
|
| Irrelevanz entfernen (für Menschen nicht wahrnehmbar) | Verlustbehaftet |
|
||||||
|
|
||||||
|
> **Feedback:** Der Kernunterschied: Verlustfrei arbeitet mit Redundanz – Wiederholungen werden kompakter gespeichert, aber nichts geht verloren. Verlustbehaftet arbeitet mit Irrelevanz – Daten werden weggeworfen, die Menschen sowieso nicht wahrnehmen können (Psychovisuell bei Bildern, Psychoakustisch bei Audio).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J10 – Dateneinheiten: Größenordnungen
|
||||||
|
**Thema:** Grundbegriffe – Speichereinheiten
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ORDER]`
|
||||||
|
|
||||||
|
Sortiere die Dateneinheiten von kleinster zu größter:
|
||||||
|
|
||||||
|
1. Byte
|
||||||
|
2. Kilobyte (KB)
|
||||||
|
3. Megabyte (MB)
|
||||||
|
4. Gigabyte (GB)
|
||||||
|
5. Terabyte (TB)
|
||||||
|
6. Petabyte (PB)
|
||||||
|
|
||||||
|
> **Feedback:** Jede Stufe = Faktor 1.000 (SI-Präfixe). Merkhilfe: „Komm Mit Großem Tee, Peter". Ein einzelnes Foto (12 MP, unkomprimiert) ≈ 36 MB. Ein FullHD-Kinofilm ≈ 1 GB. Ein 4K-Film pro Minute unkomprimiert ≈ 44 GB.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J11 – Bit und Byte: Umrechnung
|
||||||
|
**Thema:** Grundbegriffe – Bit/Byte-Verhältnis
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[NUMERIC]`
|
||||||
|
|
||||||
|
Ein Bit ist die kleinste Informationseinheit. Ein Byte besteht aus wie vielen Bit?
|
||||||
|
|
||||||
|
**Lösung:** **8** (±0)
|
||||||
|
|
||||||
|
> **Feedback:** 1 Byte = 8 Bit. Ein Byte kann einen Wert von 0 bis 255 darstellen (2⁸ − 1). Die Unterscheidung Bit/Byte ist fundamental – Bit wird mit kleinem „b" abgekürzt (b), Byte mit großem „B" (B). Deshalb: 1 Mbit/s ≠ 1 MB/s.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J12 – 7-Bit ASCII: Wie viele Zeichen?
|
||||||
|
**Thema:** Grundbegriffe – ASCII-Zeichenkodierung
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[NUMERIC]`
|
||||||
|
|
||||||
|
Der ASCII-Standard verwendet 7 Bit pro Zeichen. Wie viele verschiedene Zeichen können damit dargestellt werden?
|
||||||
|
|
||||||
|
**Lösung:** **128** (±0)
|
||||||
|
|
||||||
|
> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 7 Bit → 2⁷ = 128 Zeichen. Diese umfassen: Ziffern (0–9), Buchstaben (A–Z, a–z), Sonderzeichen und Steuerzeichen. Achtung: Umlaute (ä, ö, ü) sind nicht im ASCII-Sortiment – dafür braucht man z. B. UTF-8.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J13 – Hexadezimalzahlen: Zwei 4-Bit-Werte
|
||||||
|
**Thema:** Grundbegriffe – Hexadezimal
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[NUMERIC]`
|
||||||
|
|
||||||
|
Zwei Hexadezimalzahlen werden jeweils durch 4 Bit dargestellt. Wie viele verschiedene Werte kann eine einzelne Hexadezimalziffer annehmen?
|
||||||
|
|
||||||
|
**Lösung:** **16** (±0)
|
||||||
|
|
||||||
|
> **Feedback:** 4 Bit → 2⁴ = 16 Werte (0–15). Diese werden in Hexadezimal als 0–9 und A–F dargestellt. Zwei Hex-Ziffern zusammen = 8 Bit = 1 Byte → ein Byte lässt sich immer als genau zwei Hex-Ziffern schreiben (z. B. Byte 255 = FF, Byte 10 = 0A).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### J14 – Ein Pixel, drei Kanäle, 8 Bit
|
||||||
|
**Thema:** Grundbegriffe – Speicherbedarf eines Pixels
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[NUMERIC]`
|
||||||
|
|
||||||
|
Ein einzelner Pixel wird durch drei Farbkanäle (R, G, B) mit jeweils 8 Bit Farbtiefe gespeichert. Wie viele Byte Informationen enthalten ein solcher Pixel?
|
||||||
|
|
||||||
|
**Lösung:** **3** (±0)
|
||||||
|
|
||||||
|
> **Feedback:** 3 Kanäle × 8 Bit = 24 Bit = 3 Byte pro Pixel. Das entspricht einer 24-Bit-Farbtiefe (True Color). Diese 3 Byte pro Pixel bilden die Basis für jede Speicherberechnung von Rasterbildern: Breite × Höhe × 3 Bytes = Gesamtgröße unkomprimiert.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
## BLOCK K – Bildformate & Raster vs. Vektor
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### K1 – Was ist ein Pixel?
|
||||||
|
**Thema:** Digitale Bilder – Grundbegriffe
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was ist ein Pixel in einem digitalen Bild?
|
||||||
|
|
||||||
|
- [ ] Ein winziges physisches Kameraobjektiv.
|
||||||
|
- [x] **Ein einzelner Farbpunkt in einem Rasterbild – der kleinste Baustein.** ✅
|
||||||
|
- [ ] Eine Einheit zur Messung der Dateigröße.
|
||||||
|
- [ ] Ein Synonym für eine Farbe im RGB-Farbraum.
|
||||||
|
|
||||||
|
> **Feedback:** Pixel = Picture Element. Ein digitales Rasterbild ist ein 2D-Array aus Pixeln, jeder mit einem Farbwert (z. B. RGB).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### K2 – Speicherbedarf berechnen
|
||||||
|
**Thema:** Rastergrafiken – Berechnung
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[NUMERIC]`
|
||||||
|
|
||||||
|
Ein Bild ist 1920 × 1080 Pixel groß und nutzt 24-Bit-Farbtiefe (True Color). Wie groß ist das Bild unkomprimiert in Megabyte? (Runde auf eine Dezimalstelle)
|
||||||
|
|
||||||
|
**Formel:** Breite × Höhe × (Farbtiefe / 8) = Bytes
|
||||||
|
|
||||||
|
**Lösung:** 1920 × 1080 × 3 = 6.220.800 Bytes ≈ **6,2 MB** (±0,1)
|
||||||
|
|
||||||
|
> **Feedback:** 24 Bit = 3 Bytes pro Pixel (8 Bit pro Kanal: R, G, B). 1920 × 1080 = 2.073.600 Pixel × 3 Bytes = 6.220.800 Bytes. Durch 1.000.000 ≈ 6,2 MB.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### K3 – Farbtiefe: Bedeutung
|
||||||
|
**Thema:** Rastergrafiken – Farbtiefe
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jeder Farbtiefe ihre Bedeutung zu.
|
||||||
|
|
||||||
|
| Farbtiefe | Bedeutung |
|
||||||
|
|---|---|
|
||||||
|
| 1 Bit | 2 Farben (Schwarz/Weiß) |
|
||||||
|
| 8 Bit | 256 Farben (Graustufen, GIF) |
|
||||||
|
| 24 Bit | 16,7 Millionen Farben (True Color, Standard) |
|
||||||
|
| 32 Bit | 16,7 Millionen Farben + Alpha (Transparenz) |
|
||||||
|
|
||||||
|
> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 24 Bit = 8 Bit pro Kanal (R, G, B). 32 Bit = 24 Bit Farbe + 8 Bit Alpha-Kanal für Transparenz.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### K4 – Was ist Alpha-Transparenz?
|
||||||
|
**Thema:** Rastergrafiken – Transparenz
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was bedeutet ein 32-Bit-Bild gegenüber einem 24-Bit-Bild?
|
||||||
|
|
||||||
|
- [ ] Es hat doppelt so viele Pixel.
|
||||||
|
- [x] **Es hat einen zusätzlichen Alpha-Kanal (8 Bit), der die Transparenz jedes Pixels speichert.** ✅
|
||||||
|
- [ ] Es nutzt eine höhere Auflösung.
|
||||||
|
- [ ] Es kann mehr Dateiformate speichern.
|
||||||
|
|
||||||
|
> **Feedback:** 32 Bit = 24 Bit (RGB) + 8 Bit Alpha. Der Alpha-Kanal bestimmt, wie durchsichtig jeder Pixel ist (0 = vollständig transparent, 255 = vollständig undurchsichtig). Wichtig für PNGs mit Hintergrund-Transparenz.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### K5 – Raster vs. Vektor: Kern-Unterschied
|
||||||
|
**Thema:** Raster vs. Vektor – Konzept
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was ist der fundamentale Unterschied zwischen Raster- und Vektorgrafiken?
|
||||||
|
|
||||||
|
- [ ] Vektorgrafiken sind immer farbiger als Rastergrafiken.
|
||||||
|
- [x] **Rastergrafiken speichern einzelne Pixel; Vektorgrafiken speichern geometrische Beschreibungen (Pfade, Formen), die beliebig skaliert werden können.** ✅
|
||||||
|
- [ ] Rastergrafiken können keine Farben darstellen, Vektorgrafiken schon.
|
||||||
|
- [ ] Der Unterschied liegt nur in der Dateiendung, nicht im Inhalt.
|
||||||
|
|
||||||
|
> **Feedback:** Raster = „Malen nach Zahlen" (jeder Pixel einzeln). Vektor = „Bauanleitung" (Formen beschreiben). Diese Unterschied bestimmt alles: Skalierung, Dateigröße, Einsatzbereich.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### K6 – Raster vs. Vektor: Vergleich
|
||||||
|
**Thema:** Raster vs. Vektor – Eigenschaften zuordnen
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jeder Eigenschaft zu: Raster oder Vektor?
|
||||||
|
|
||||||
|
| Eigenschaft | Typ |
|
||||||
|
|---|---|
|
||||||
|
| Skalierung ohne Qualitätsverlust | Vektor |
|
||||||
|
| Ideal für Fotos | Raster |
|
||||||
|
| Dateigröße abhängig von der Auflösung | Raster |
|
||||||
|
| Ideal für Logos und Icons | Vektor |
|
||||||
|
| Speicherung als 2D-Array von Pixeln | Raster |
|
||||||
|
| Dateigröße abhängig von der Komplexität | Vektor |
|
||||||
|
|
||||||
|
> **Feedback:** Raster = Pixel-basiert, auflösungsabhängig, ideal für Fotos. Vektor = Beschreibungs-basiert, beliebig skalierbar, ideal für Grafiken/Logos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### K7 – Skalierung: Warum werden Rasterbilder unscharf?
|
||||||
|
**Thema:** Rastergrafiken – Skalierung Transfer
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ESSAY]`
|
||||||
|
|
||||||
|
Erkläre, warum ein Rasterbild beim Vergrößern unscharf wird, während ein Vektorbild bei beliebiger Größe scharf bleibt. Nenne einen konkreten Anwendungsfall, in dem diese Eigenschaft ausschlaggebend ist.
|
||||||
|
|
||||||
|
> **Musterlösung:** Ein Rasterbild hat eine feste Auflösung (eine bestimmte Anzahl von Pixeln). Beim Vergrößern müssen neue Pixel „erfunden" werden (Interpolation) – es gibt keine echten Daten für die fehlenden Stellen → Unschärfe. Ein Vektorbild speichert nur Beschreibungen (Pfade, Formen). Beim Vergrößern werden einfach die Koordinaten skaliert – keine Information geht verloren → immer scharf. Anwendungsfall: Ein Logo auf einer Visitenkarte UND auf einem Plakat → SVG nutzen, damit es bei beliebiger Größe scharf bleibt.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### K8 – Vektor → Raster: Wie heißt das?
|
||||||
|
**Thema:** Raster vs. Vektor – Konvertierung
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Wie heißt der Prozess, bei dem eine Vektorgrafik in eine Rastergrafik umgewandelt wird?
|
||||||
|
|
||||||
|
- [ ] Vektorisierung
|
||||||
|
- [x] **Rasterisierung** ✅
|
||||||
|
- [ ] Pixelierung
|
||||||
|
- [ ] Komprimierung
|
||||||
|
|
||||||
|
> **Feedback:** Rasterisierung = Vektor → Raster (trivial, immer möglich). Der umgekehrte Prozess (Raster → Vektor) heißt „Tracing" und funktioniert oft nur unbefriedigend.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### K9 – Interpolation: Welches Verfahren wofür?
|
||||||
|
**Thema:** Rastergrafiken – Interpolationsverfahren
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jedem Interpolationsverfahren seine Eigenschaft zu.
|
||||||
|
|
||||||
|
| Verfahren | Eigenschaft |
|
||||||
|
|---|---|
|
||||||
|
| Nearest Neighbor | Schnell, pixelig – gut für Pixel-Art |
|
||||||
|
| Bilinear | Glättet, Standard-Verfahren |
|
||||||
|
| Bicubic | Hohe Qualität, rechenintensiver |
|
||||||
|
| Lanczos | Beste Qualität, mathematisch komplex |
|
||||||
|
|
||||||
|
> **Feedback:** Bei der Wahl: Pixel-Art → Nearest Neighbor (soll pixelig bleiben). Normale Bilder → Bilinear oder Bicubic. Maximale Qualität bei Fotos → Lanczos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
## BLOCK L – JPEG: Innenleben
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### L1 – JPEG: Verlustfrei oder verlustbehaftet?
|
||||||
|
**Thema:** JPEG – Grundeigenschaft
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
JPEG ist ein …
|
||||||
|
|
||||||
|
- [x] **…verlustbehaftetes Bildformat. Beim Speichern werden Daten dauerhaft weggeworfen.** ✅
|
||||||
|
- [ ] …verlustfreies Bildformat wie PNG.
|
||||||
|
- [ ] …Videoformat für Streaming.
|
||||||
|
- [ ] …Vektorgrafik-Format.
|
||||||
|
|
||||||
|
> **Feedback:** JPEG = Joint Photographic Experts Group. Verlustbehaftet: Beim Speichern werden Daten dauerhaft weggeworfen – eine gespeicherte JPEG kann nicht perfekt zum Original zurückgeführt werden. Quality 100 ≠ verlustfrei, nur „wenig wegwerfen".
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### L2 – Psychovisuelle Kompression: Das Auge austricksen
|
||||||
|
**Thema:** JPEG – Wahrnehmungsprinzip
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Wie nutzt JPEG die Schwächen des menschlichen Auges aus?
|
||||||
|
|
||||||
|
- [ ] Das Auge kann keine Farben wahrnehmen – daher werden Farben komplett entfernt.
|
||||||
|
- [x] **Das Auge sieht Helligkeit besser als Farbe. JPEG behält die Helligkeit (Y) nahezu vollständig, reduziert aber die Farbauflösung (Cb, Cr) – der Verlust wird kaum wahrgenommen.** ✅
|
||||||
|
- [ ] Das Auge kann keine Details sehen – daher werden alle Details entfernt.
|
||||||
|
- [ ] JPEG nutzt keine Wahrnehmungsforschung, komprimiert rein mathematisch.
|
||||||
|
|
||||||
|
> **Feedback:** Psychovisuelle Kompression = Schwächen des Auges ausnutzen. Kern: Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge → Helligkeit sichern, Farbe reduzieren. Der Verlust ist für Menschen kaum sichtbar.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### L3 – Farbraumkonversion: RGB → YCbCr
|
||||||
|
**Thema:** JPEG Schritt 1 – Farbraum
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Warum wird bei JPEG von RGB in YCbCr konvertiert?
|
||||||
|
|
||||||
|
- [ ] YCbCr nutzt weniger Speicher pro Pixel als RGB.
|
||||||
|
- [x] **In YCbCr sind Helligkeit (Y) und Farbe (Cb, Cr) getrennt – die Farbauflösung kann unabhängig von der Helligkeit reduziert werden.** ✅
|
||||||
|
- [ ] RGB kann keine Transparenz darstellen, YCbCr schon.
|
||||||
|
- [ ] Die Konvertierung ist ein verlustfreier Schritt, der die Dateigröße halbiert.
|
||||||
|
|
||||||
|
> **Feedback:** Y = Helligkeit (Luminanz), Cb/Cr = Farbdifferenzen (Chrominanz). Diese Trennung ermöglicht Chroma Subsampling: Helligkeit voll behalten, Farbe reduzieren – ohne sichtbaren Verlust.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### L4 – Chroma Subsampling: Was ist 4:2:0?
|
||||||
|
**Thema:** JPEG Schritt 2 – Subsampling
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was bedeutet das Subsampling-Schema 4:2:0?
|
||||||
|
|
||||||
|
- [ ] 4 Pixel teilen sich eine Helligkeit, aber jeder hat eigene Farbe.
|
||||||
|
- [x] **4 Pixel teilen sich einen Farbwert (Chrominanz), aber jeder hat eine eigene Helligkeit (Luminanz). Die Farbauflösung wird auf 25% reduziert.** ✅
|
||||||
|
- [ ] 4:2:0 bedeutet, dass keine Farbe gespeichert wird – nur Graustufen.
|
||||||
|
- [ ] Die Notation beschreibt die Blockgröße, nicht die Farbauflösung.
|
||||||
|
|
||||||
|
> **Feedback:** 4:2:0 = JPEG-Standard. Von 4 Pixeln wird nur 1 Farbwert gespeichert (2×2-Block teilt Farbe), aber jeder Pixel behält seine eigene Helligkeit. Ergebnis: 50% Datenreduktion, kaum sichtbar.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### L5 – JPEG-Schritte: Richtige Reihenfolge
|
||||||
|
**Thema:** JPEG – Kompressionsablauf
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ORDER]`
|
||||||
|
|
||||||
|
Sortiere die Schritte der JPEG-Kompression in der richtigen Reihenfolge:
|
||||||
|
|
||||||
|
1. Farbraumkonversion (RGB → YCbCr)
|
||||||
|
2. Chroma Subsampling
|
||||||
|
3. Block-Aufteilung (8×8)
|
||||||
|
4. DCT (Frequenzanalyse)
|
||||||
|
5. Quantisierung (hier passiert der Verlust!)
|
||||||
|
6. Huffman-Coding (verlustfrei)
|
||||||
|
|
||||||
|
> **Feedback:** Der einzige verlustbehaftete Schritt ist die Quantisierung (Schritt 5). Alles davor bereitet die Daten vor, alles danach komprimiert die Ergebnisse verlustfrei weiter.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### L6 – Welcher Schritt ist verlustbehaftet?
|
||||||
|
**Thema:** JPEG – Verlust lokalisieren
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Bei welchem Schritt der JPEG-Kompression werden Daten dauerhaft weggeworfen?
|
||||||
|
|
||||||
|
- [ ] Farbraumkonversion (RGB → YCbCr)
|
||||||
|
- [ ] DCT (Discrete Cosine Transform)
|
||||||
|
- [x] **Quantisierung – hier werden unwichtige Frequenzkoeffizienten auf Null gesetzt oder vergröbert.** ✅
|
||||||
|
- [ ] Huffman-Coding
|
||||||
|
|
||||||
|
> **Feedback:** DCT selbst ist verlustfrei und reversibel – es sortiert nur die Daten nach Wichtigkeit. Die Quantisierung ist der einzige verlustbehaftete Schritt: Sie wirft hohe Frequenzen (feine Details) weg. Huffman-Coding danach ist wieder verlustfrei.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### L7 – DCT: Was macht sie?
|
||||||
|
**Thema:** JPEG – DCT-Prinzip
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was leitet die DCT (Discrete Cosine Transform) bei JPEG?
|
||||||
|
|
||||||
|
- [ ] Sie komprimiert die Daten verlustbehaftet.
|
||||||
|
- [x] **Sie wandelt 64 Pixelwerte eines 8×8-Blocks in 64 Frequenzkoeffizienten um – sortiert die Information nach Wichtigkeit (niedrige Frequenz = wichtig, hohe Frequenz = Details).** ✅
|
||||||
|
- [ ] Sie verschlüsselt die Daten für sichere Übertragung.
|
||||||
|
- [ ] Sie reduziert die Farbauflösung des Bildes.
|
||||||
|
|
||||||
|
> **Feedback:** DCT = Herzstück von JPEG, aber selbst verlustfrei. Sie sortiert: Der DC-Koeffizient (0,0) = Durchschnittshelligkeit eines Blocks. Die AC-Koeffizienten = Helligkeitsänderungen. 90% der Information steckt in den ersten 10–15 Koeffizienten.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### L8 – Huffman-Coding: Prinzip
|
||||||
|
**Thema:** JPEG – Huffman
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Wie funktioniert Huffman-Coding?
|
||||||
|
|
||||||
|
- [ ] Alle Zeichen bekommen gleich lange Codes – einfach und effizient.
|
||||||
|
- [x] **Häufige Werte bekommen kurze Codes, selten vorkommende lange Codes – variable Bitlänge statt fester 8 Bit.** ✅
|
||||||
|
- [ ] Huffman-Coding verschlüsselt die Daten zusätzlich.
|
||||||
|
- [ ] Es funktioniert nur für Texte, nicht für Bilddaten.
|
||||||
|
|
||||||
|
> **Feedback:** Huffman = verlustfrei, optimal für bekannte Häufigkeiten. Präfix-frei: Kein Code ist Anfang eines anderen → eindeutig decodierbar. Auch in ZIP, PNG, MP3 verwendet.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### L9 – JPEG-Artefakte: Benennen
|
||||||
|
**Thema:** JPEG – Artefakte identifizieren
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jedem JPEG-Artefakt seine Beschreibung zu.
|
||||||
|
|
||||||
|
| Artefakt | Beschreibung |
|
||||||
|
|---|---|
|
||||||
|
| Blocking | 8×8-Blöcke werden sichtbar als Rechteckmuster |
|
||||||
|
| Ringing | „Geister" oder Halos an scharfen Kanten |
|
||||||
|
| Posterization | Farbverläufe werden stufig statt fließend |
|
||||||
|
|
||||||
|
> **Feedback:** Alle drei sind Folgen der Quantisierung. Blocking: Weil jeder 8×8-Block unabhängig komprimiert wird. Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen). Posterization: Zu wenige Bits für feine Farbabstufungen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
## BLOCK M – Bildformate: PNG, GIF, WebP, SVG
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### M1 – PNG: Verlustfrei oder verlustbehaftet?
|
||||||
|
**Thema:** PNG – Grundeigenschaft
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Wie komprimiert PNG?
|
||||||
|
|
||||||
|
- [ ] Verlustbehaftet – wie JPEG, aber mit besserer Qualität.
|
||||||
|
- [x] **Verlustfrei – die Originaldaten können perfekt rekonstruiert werden.** ✅
|
||||||
|
- [ ] Gar nicht – PNG speichert Daten unkomprimiert.
|
||||||
|
- [ ] PNG nutzt eine Kombination aus verlustfrei und verlustbehaftet.
|
||||||
|
|
||||||
|
> **Feedback:** PNG nutzt DEFLATE-Kompression (wie ZIP) – verlustfrei. Deshalb ist PNG ideal für Grafiken, Screenshots und Bilder mit Transparenz, aber größer als JPEG für Fotos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### M2 – PNG vs. JPEG: Wann was?
|
||||||
|
**Thema:** Bildformate – Formatwahl
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ESSAY]`
|
||||||
|
|
||||||
|
Erklären Sie, wann Sie PNG und wann JPEG wählen würden. Nenne je zwei konkrete Anwendungsfälle und begründen Sie Ihre Wahl.
|
||||||
|
|
||||||
|
> **Musterlösung:** PNG: (1) Screenshots – Texte und Linien bleiben scharf, keine Artefakte. (2) Logos mit Transparenz – PNG unterstützt Alpha-Transparenz, JPEG nicht. JPEG: (1) Fotos fürs Web – deutlich kleiner bei kaum sichtbarem Qualitätsverlust. (2) Social Media – Plattformen re-komprimieren sowieso, PNG würde nur unnötig groß sein.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### M3 – GIF: Wie viele Farben?
|
||||||
|
**Thema:** GIF – Eigenschaften
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Wie viele Farben kann ein GIF-Bild gleichzeitig anzeigen?
|
||||||
|
|
||||||
|
- [ ] 16 Farben
|
||||||
|
- [ ] 16,7 Millionen Farben
|
||||||
|
- [x] **256 Farben (8-Bit-Palette)** ✅
|
||||||
|
- [ ] Unbegrenzt – GIF unterstützt alle Farben.
|
||||||
|
|
||||||
|
> **Feedback:** GIF = 8-Bit-Palette = 256 Farben maximal. Deshalb sehen GIF-Bilder bei Fotos oft banding/posterisiert aus. GIF überlebt heute wegen Animationen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### M4 – WebP vs. JPEG: Vorteil?
|
||||||
|
**Thema:** Bildformate – WebP
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was ist der hauptsächliche Vorteil von WebP gegenüber JPEG?
|
||||||
|
|
||||||
|
- [ ] WebP unterstützt Videos, JPEG nicht.
|
||||||
|
- [x] **WebP erzeugt bei gleicher Qualität 25–35% kleinere Dateien als JPEG.** ✅
|
||||||
|
- [ ] WebP ist verlustfrei, JPEG nicht.
|
||||||
|
- [ ] WebP kann keine Fotos speichern, nur Grafiken.
|
||||||
|
|
||||||
|
> **Feedback:** WebP (Google, 2010) kann sowohl lossy als auch lossless komprimieren, unterstützt Transparenz und Animationen. Bei gleicher visueller Qualität sind WebP-Dateien deutlich kleiner als JPEG.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### M5 – SVG: Was ist es?
|
||||||
|
**Thema:** SVG – Grundbegriff
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was ist SVG?
|
||||||
|
|
||||||
|
- [ ] Ein verlustbehaftetes Rasterbild-Format wie JPEG.
|
||||||
|
- [x] **Ein Vektorgrafik-Format, das Bilder als geometrische Beschreibungen (XML) speichert – beliebig skalierbar ohne Qualitätsverlust.** ✅
|
||||||
|
- [ ] Ein Video-Container wie MP4.
|
||||||
|
- [ ] Ein komprimiertes Archivformat wie ZIP.
|
||||||
|
|
||||||
|
> **Feedback:** SVG = Scalable Vector Graphics. Web-Standard für Vektorgrafiken. Beschreibt WAS gezeichnet werden soll (`<circle>`, `<rect>`, `<path>`), nicht wie jeder Pixel aussieht. Ideal für Logos, Icons, Illustrationen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### M6 – Formatwahl: Szenario zuordnen
|
||||||
|
**Thema:** Bildformate – Formatwahl Transfer
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jedem Szenario das optimale Bildformat zu.
|
||||||
|
|
||||||
|
| Szenario | Format |
|
||||||
|
|---|---|
|
||||||
|
| Ein Foto für eine Webseite (klein, OK-Qualität) | JPEG |
|
||||||
|
| Ein Screenshot einer Benutzeroberfläche | PNG |
|
||||||
|
| Ein Logo, das auf allen Bildschirmgrößen scharf sein muss | SVG |
|
||||||
|
| Ein animiertes Reaktionsbild für einen Chat | GIF |
|
||||||
|
|
||||||
|
> **Feedback:** JPEG = Fotos (klein, lossy OK). PNG = Screenshots, Grafiken mit Transparenz (verlustfrei). SVG = Logos, Icons (skalierbar). GIF = Animationen (256 Farben, aber Animations-Support).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
## BLOCK N – Video-Kompression
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### N1 – Spatial vs. Temporal Compression
|
||||||
|
**Thema:** Video – Kompressionsprinzipien
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jedem Prinzip seine Beschreibung zu.
|
||||||
|
|
||||||
|
| Prinzip | Beschreibung |
|
||||||
|
|---|---|
|
||||||
|
| Spatial Compression (Intra-Frame) | Komprimiert jedes einzelne Bild für sich (wie JPEG) |
|
||||||
|
| Temporal Compression (Inter-Frame) | Speichert nur die Änderungen zwischen aufeinanderfolgenden Bildern |
|
||||||
|
| Motion Compensation | Beschreibt Bewegung durch Vektoren statt Pixel zu kopieren |
|
||||||
|
|
||||||
|
> **Feedback:** Spatial = räumlich (innerhalb eines Frames). Temporal = zeitlich (zwischen Frames). Motion Compensation = Bewegungsvektoren. 90% eines Frames ist oft identisch mit dem vorherigen – deshalb ist Temporal-Kompression so wirksam.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### N2 – I-Frame, P-Frame, B-Frame: Was ist was?
|
||||||
|
**Thema:** Video – Frame-Typen
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jedem Frame-Typ seine Beschreibung zu.
|
||||||
|
|
||||||
|
| Frame-Typ | Beschreibung |
|
||||||
|
|---|---|
|
||||||
|
| I-Frame (Keyframe) | Vollständiges Bild, unabhängig dekodierbar – keine Referenz auf andere Frames |
|
||||||
|
| P-Frame | Nur Änderungen gegenüber vorherigen Frames speichern (~30% der Größe eines I-Frames) |
|
||||||
|
| B-Frame | Änderungen gegenüber vorherigen UND zukünftigen Frames (~15% der Größe eines I-Frames) |
|
||||||
|
|
||||||
|
> **Feedback:** I = Intra (innerhalb). P = Predicted (aus Vergangenheit). B = Bi-directional (Vergangenheit + Zukunft). B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung zum Decodieren.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### N3 – Was passiert, wenn ein I-Frame beschädigt ist?
|
||||||
|
**Thema:** Video – I-Frame Bedeutung Transfer
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ESSAY]`
|
||||||
|
|
||||||
|
Erkläre, warum ein I-Frame bei der Videokompression so wichtig ist. Was passiert, wenn ein einzelner I-Frame in einem Videostream beschädigt wird?
|
||||||
|
|
||||||
|
> **Musterlösung:** Ein I-Frame ist ein vollständiges, unabhängig dekodierbare Bild. Alle nachfolgenden P- und B-Frames referenzieren auf vorherige Frames – letztlich auf das letzte I-Frame. Wenn ein I-Frame beschädigt wird, können alle abhängigen P- und B-Frames bis zum nächsten intakten I-Frame nicht mehr korrekt rekonstruiert werden → Videofehler sichtbar bis zum nächsten Keyframe. Deshalb werden typischerweise alle 1–2 Sekunden neue I-Frames eingefügt.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### N4 – Motion Compensation: Prinzip
|
||||||
|
**Thema:** Video – Motion Compensation
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was beschreibt ein Motion Vector bei der Videokompression?
|
||||||
|
|
||||||
|
- [ ] Die Helligkeit eines einzelnen Pixels.
|
||||||
|
- [x] **Die Verschiebung eines Bildblocks zwischen zwei Frames (z. B. „verschiebe um +20 Pixel nach rechts").** ✅
|
||||||
|
- [ ] Die Kompressionsrate des gesamten Videos.
|
||||||
|
- [ ] Die Anzahl der Farben in einem Frame.
|
||||||
|
|
||||||
|
> **Feedback:** Motion Compensation speichert Bewegung als Vektoren statt Pixel zu kopieren. Wenn sich ein 16×16-Block von (100,200) auf (120,200) bewegt, wird nur „+20, 0" gespeichert – deutlich kleiner als den Block zweimal zu speichern.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### N5 – Video-Codecs: Zeitstrahl
|
||||||
|
**Thema:** Video – Codecs-Übersicht
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ORDER]`
|
||||||
|
|
||||||
|
Sortiere die Video-Codecs nach Veröffentlichungsjahr (alt → neu):
|
||||||
|
|
||||||
|
1. H.264 / AVC (2003)
|
||||||
|
2. H.265 / HEVC (2013)
|
||||||
|
3. VP9 (2013)
|
||||||
|
4. AV1 (2018)
|
||||||
|
|
||||||
|
> **Feedback:** H.264 revolutionierte Streaming. H.265 und VP9 kamen gleichzeitig – H.265 technisch besser, aber Patent-Chaos. AV1 vereint die Industrie: patent-frei, 30% besser als H.265.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### N6 – AV1: Warum die Zukunft?
|
||||||
|
**Thema:** Video – AV1 Transfer
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ESSAY]`
|
||||||
|
|
||||||
|
Erkläre, warum AV1 als „die Zukunft" der Videokompression gilt. Nenne mindestens zwei konkrete Eigenschaften und erkläre, warum H.265 trotz besserer technischer Kompression nicht die gleiche Dominanz erreicht hat.
|
||||||
|
|
||||||
|
> **Musterlösung:** AV1 (2018) ist royalty-free und open source – die Alliance for Open Media vereint Google, Netflix, Amazon, Apple, Mozilla. Es liefert 30% bessere Kompression als H.265 und unterstützt 8K, HDR, hohe Frame-Rates. H.265 scheitert vor allem am Patent-Chaos: Drei konkurrierende Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) erzeugen rechtliche Unsicherheit und unklare Kosten → viele Unternehmen bleiben bei H.264 oder wechseln direkt zu AV1.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
## BLOCK O – Speichermedien & Schnittstellen
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### O1 – KB vs. KiB: Was ist der Unterschied?
|
||||||
|
**Thema:** Speicher – Einheiten
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Eine Festplatte wird als „1 TB" vermarktet, aber Windows zeigt nur ~931 GB an. Warum?
|
||||||
|
|
||||||
|
- [ ] Windows zeigt falsche Werte an – das ist ein Bug.
|
||||||
|
- [x] **Hersteller nutzen dezimale Einheiten (1 TB = 1.000 GB), Windows nutzt binäre Einheiten (1 TiB = 1.024 GiB). Bei TB-Größen entsteht eine ~7% Diskrepanz.** ✅
|
||||||
|
- [ ] Die Festplatte verliert beim Formatieren fast 10% ihrer Kapazität.
|
||||||
|
- [ ] Windows reserviert automatisch 10% als Sicherheitspuffer.
|
||||||
|
|
||||||
|
> **Feedback:** SI (Dezimal): 1 KB = 1.000 Bytes, 1 MB = 1.000 KB. IEC (Binär): 1 KiB = 1.024 Bytes, 1 MiB = 1.024 KiB. Bei 1 TB: 1.000⁴ vs. 1.024⁴ Bytes → ~7% Unterschied. Windows zeigt binäre Werte an, aber mit SI-Bezeichnung (GB statt GiB) → Verwirrung.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### O2 – HDD vs. SSD: Kern-Unterschied
|
||||||
|
**Thema:** Speichermedien – HDD vs. SSD
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Was ist der fundamentale technische Unterschied zwischen HDD und SSD?
|
||||||
|
|
||||||
|
- [ ] HDDs sind elektronisch, SSDs mechanisch.
|
||||||
|
- [x] **HDDs speichern Daten magnetisch auf sich drehenden Plattern (mechanisch). SSDs nutzen Flash-Speicher (elektronisch, keine beweglichen Teile).** ✅
|
||||||
|
- [ ] Beide Technologien funktionieren identisch, der Unterschied liegt nur im Gehäuse.
|
||||||
|
- [ ] HDDs nutzen Flash-Speicher, SSDs magnetische Platten.
|
||||||
|
|
||||||
|
> **Feedback:** HDD = Hard Disk Drive = mechanisch (Platter, Spindel, Schreib-Lese-Kopf). SSD = Solid State Drive = elektronisch (Flash-Speicher). Diese Unterschied bestimmt alles: Geschwindigkeit, Latenz, Geräusche, Haltbarkeit.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### O3 – HDD vs. SSD: Eigenschaften zuordnen
|
||||||
|
**Thema:** Speichermedien – Vergleich
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jeder Eigenschaft zu: HDD oder SSD?
|
||||||
|
|
||||||
|
| Eigenschaft | Typ |
|
||||||
|
|---|---|
|
||||||
|
| Sequentielle Lesgeschwindigkeit ~150 MB/s | HDD |
|
||||||
|
| Sequentielle Lesgeschwindigkeit ~3.500 MB/s | SSD (NVMe) |
|
||||||
|
| Latenz ~10 ms | HDD |
|
||||||
|
| Latenz ~0,02 ms | SSD |
|
||||||
|
| Günstig pro TB (~15€/TB) | HDD |
|
||||||
|
| Ideal für Betriebssystem | SSD |
|
||||||
|
|
||||||
|
> **Feedback:** Der dramatische Unterschied liegt bei Random Access: SSD ~500× schneller. Deshalb: Betriebssystem auf SSD, Archiv auf HDD. Viele nutzen beides: Kleine SSD für System + große HDD für Daten.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### O4 – USB-C: Stecker oder Protokoll?
|
||||||
|
**Thema:** Schnittstellen – USB-C
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Ein USB-C-Kabel kann langsam sein, obwohl es wie ein „modernes" Kabel aussieht. Warum?
|
||||||
|
|
||||||
|
- [ ] USB-C-Kabel sind immer gleich schnell – die Geschwindigkeit liegt am Gerät.
|
||||||
|
- [x] **USB-C ist nur ein Steckertyp, kein Protokoll. Ein USB-C-Kabel kann USB 2.0 (480 Mbit/s) bis USB4 (40 Gbit/s) sein – am Stecker nicht erkennbar.** ✅
|
||||||
|
- [ ] USB-C-Kabel werden nach einem Jahr automatisch langsamer.
|
||||||
|
- [ ] Die Geschwindigkeit hängt nur vom Betriebssystem ab.
|
||||||
|
|
||||||
|
> **Feedback:** USB-C = Steckerform. Das Protokoll dahinter kann USB 2.0, 3.2 oder USB4 sein. Ein billiges USB-C-Kabel ist oft nur USB 2.0 mit neuem Stecker. Kabel-Spezifikation prüfen!
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### O5 – Dateisysteme: Zuordnung
|
||||||
|
**Thema:** Dateisysteme – Überblick
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jedem Dateisystem seine ideale Anwendung zu.
|
||||||
|
|
||||||
|
| Dateisystem | Ideal für |
|
||||||
|
|---|---|
|
||||||
|
| FAT32 | USB-Sticks, SD-Karten (maximale Kompatibilität) |
|
||||||
|
| NTFS | Windows-Systeme (Journaling, Rechte) |
|
||||||
|
| APFS | macOS, iOS (Snapshots, CoW) |
|
||||||
|
| ext4 | Linux-Systeme (Journaling, stabil) |
|
||||||
|
| exFAT | Große Dateien auf portablen Medien |
|
||||||
|
|
||||||
|
> **Feedback:** FAT32 = kleinster gemeinsamer Nenner, aber max. 4 GB pro Datei. exFAT = FAT32 ohne Größenlimits. NTFS/APFS/ext4 = moderne Systeme mit Journaling. Journaling = bei Absturz werden Änderungen nicht verloren.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### O6 – FAT32: Warum nicht für große Dateien?
|
||||||
|
**Thema:** Dateisysteme – FAT32 Limitation
|
||||||
|
**Punkte:** 1
|
||||||
|
**Typ:** `[MC]`
|
||||||
|
|
||||||
|
Sie versuchen, eine 5-GB-Videodatei auf einen FAT32-formatierten USB-Stick zu kopieren. Was passiert?
|
||||||
|
|
||||||
|
- [ ] Die Datei wird automatisch aufgeteilt in kleinere Teile.
|
||||||
|
- [x] **Der Vorgang fehlschlägt – FAT32 unterstützt keine einzelnen Dateien größer als 4 GB.** ✅
|
||||||
|
- [ ] Die Datei wird automatisch komprimiert, bis sie unter 4 GB ist.
|
||||||
|
- [ ] FAT32 hat keine Dateigrößenbeschränkung.
|
||||||
|
|
||||||
|
> **Feedback:** FAT32-Limit: max. 4 GB pro Datei. Ein 4K-Video oder ISO-Image passt oft nicht. Lösung: USB-Stick mit exFAT oder NTFS formatieren.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### O7 – Die 3-2-1-Regel
|
||||||
|
**Thema:** Backup – Prinzip
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[ESSAY]`
|
||||||
|
|
||||||
|
Erkläre die 3-2-1-Regel für Backups. Begründe, warum jede der drei Ziffern wichtig ist.
|
||||||
|
|
||||||
|
> **Musterlösung:** 3 Kopien: Original + 2 Backups. Warum? Das Original kann kaputt gehen, das erste Backup auch – das zweite ist der Sicherheitspuffer. 2 verschiedene Medientypen (z. B. SSD + HDD, oder lokal + Cloud). Warum? Gleiche Medien haben gleiche Schwachstellen (z. B. Batch-Fehler bei HDDs derselben Charge). 1 Kopie an einem anderen Ort (Cloud, anderes Gebäude). Warum? Brand oder Wasserschaden zerstört alles vor Ort; Ransomware verschlüsselt alle angeschlossenen Laufwerke gleichzeitig.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: disable -->
|
||||||
|
|
||||||
|
### O8 – Backup-Arten: Unterschiede
|
||||||
|
**Thema:** Backup – Typen
|
||||||
|
**Punkte:** 2
|
||||||
|
**Typ:** `[MATCH]`
|
||||||
|
|
||||||
|
Ordne jedem Backup-Typ seine Beschreibung zu.
|
||||||
|
|
||||||
|
| Backup-Typ | Beschreibung |
|
||||||
|
|---|---|
|
||||||
|
| Full (Vollständig) | Kompletter Datenbestand jedes Mal – einfach, aber langsam und platzhungrig |
|
||||||
|
| Inkrementell | Nur Änderungen seit dem letzten Backup (egal welcher Art) – schnell, aber Wiederherstellung komplex |
|
||||||
|
| Differenziell | Änderungen seit dem letzten Voll-Backup – Mittelweg zwischen beiden |
|
||||||
|
|
||||||
|
> **Feedback:** Typisches Schema: Sonntag Full, Mo–Sa Inkrementell oder Differenziell. Inkrementell = schnellstes Backup, langsamste Wiederherstellung (Kette aufbauen). Full = langsamstes Backup, schnellste Wiederherstellung.
|
||||||
@@ -3,9 +3,9 @@ marp: true
|
|||||||
theme: gaia
|
theme: gaia
|
||||||
paginate: true
|
paginate: true
|
||||||
backgroundColor: #fff
|
backgroundColor: #fff
|
||||||
header: "Grundlagen IT- und Internettechnik"
|
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||||
title: "Termin 1: Geschichte, Grundlagen & HTML"
|
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
|
||||||
---
|
---
|
||||||
|
|
||||||
<style>
|
<style>
|
||||||
@@ -49,11 +49,52 @@ a {
|
|||||||
color: var(--color-highlight);
|
color: var(--color-highlight);
|
||||||
}
|
}
|
||||||
section.klausur {
|
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;
|
background: #fce4ec !important;
|
||||||
}
|
}
|
||||||
section.klausur footer {
|
section.aufgabe footer {
|
||||||
display: none;
|
display: none;
|
||||||
}
|
}
|
||||||
|
section.erklaerung {
|
||||||
|
font-size: 1.1rem;
|
||||||
|
background: linear-gradient(180deg, #fff8fa 0%, #fef0f4 100%) !important;
|
||||||
|
border-left: 6px solid #a02060;
|
||||||
|
}
|
||||||
|
section.erklaerung h1 {
|
||||||
|
font-size: 1.6rem;
|
||||||
|
color: #a02060;
|
||||||
|
margin-bottom: 0.5rem;
|
||||||
|
}
|
||||||
|
section.erklaerung h2 {
|
||||||
|
font-size: 1.3rem;
|
||||||
|
color: #1f2937;
|
||||||
|
margin-top: 0;
|
||||||
|
}
|
||||||
|
section.erklaerung ul,
|
||||||
|
section.erklaerung ol {
|
||||||
|
font-size: 1.0rem;
|
||||||
|
line-height: 1.4;
|
||||||
|
}
|
||||||
|
section.erklaerung p {
|
||||||
|
font-size: 1.05rem;
|
||||||
|
line-height: 1.5;
|
||||||
|
}
|
||||||
|
section.erklaerung table {
|
||||||
|
font-size: 0.95rem;
|
||||||
|
}
|
||||||
</style>
|
</style>
|
||||||
|
|
||||||
<!-- _class: invert -->
|
<!-- _class: invert -->
|
||||||
@@ -84,7 +125,7 @@ Hochschule der Medien Stuttgart
|
|||||||
|
|
||||||
<!-- _class: lead -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Termin 1 – 20.12.2025
|
# Kapitel 1
|
||||||
## Geschichte, Grundlagen & HTML
|
## Geschichte, Grundlagen & HTML
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -606,6 +647,9 @@ Euer Laptop, euer Handy, der Server dieser Präsentation
|
|||||||
---
|
---
|
||||||
|
|
||||||
<!-- _class: klausur -->
|
<!-- _class: klausur -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
<!-- _backgroundColor: #fce4ec -->
|
||||||
|
|
||||||
# Die 5 Komponenten
|
# Die 5 Komponenten
|
||||||
|
|
||||||
@@ -635,7 +679,30 @@ PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
<!-- _class: erklaerung -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
|
||||||
|
# Die 5 Komponenten: Erklaerung
|
||||||
|
|
||||||
|
**Definition:** Die Von-Neumann-Architektur beschreibt den grundlegenden Aufbau moderner Computer in fuenf Funktionseinheiten.
|
||||||
|
|
||||||
|
| Komponente | Aufgabe | Beispiel |
|
||||||
|
|------------|---------|----------|
|
||||||
|
| **Rechenwerk (ALU)** | Arithmetische & logische Operationen | +, -, ×, ÷, Vergleiche |
|
||||||
|
| **Steuerwerk** | Holt, dekodiert und steuert Befehle | Fetch-Decode-Execute-Zyklus |
|
||||||
|
| **Speicherwerk** | Speichert Programme UND Daten | RAM, ROM |
|
||||||
|
| **Ein-/Ausgabe** | Kommunikation mit Aussenwelt | Tastatur, Monitor, USB |
|
||||||
|
| **Bus-System** | Verbindet alle Komponenten | Adress-, Daten-, Steuerbus |
|
||||||
|
|
||||||
|
**Merkhilfe:** "**R**echnen, **S**teuern, **S**peichern, **E**in/**A**us, **B**us" (RSSEAB)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
<!-- _class: klausur -->
|
<!-- _class: klausur -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
<!-- _backgroundColor: #fce4ec -->
|
||||||
|
|
||||||
# Von-Neumann-Architektur: Bedeutung
|
# Von-Neumann-Architektur: Bedeutung
|
||||||
|
|
||||||
@@ -669,6 +736,27 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
<!-- _class: erklaerung -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
|
||||||
|
# Von-Neumann-Architektur: Erklaerung
|
||||||
|
|
||||||
|
**Definition:** Das revolutionaere Prinzip, dass Programme und Daten im selben Speicher liegen und Programme somit wie Daten behandelt werden koennen.
|
||||||
|
|
||||||
|
**Kernpunkte:**
|
||||||
|
- **Stored Program Concept:** Programme sind austauschbare Daten
|
||||||
|
- **Universalrechner:** Gleiche Hardware fuer beliebige Aufgaben
|
||||||
|
- **Software-Flexibilitaet:** Programme koennen geladen, geaendert und geloescht werden
|
||||||
|
|
||||||
|
**Vorher (ENIAC):** Programmierung durch Umstecken von Kabeln → Tage fuer jedes neue Programm
|
||||||
|
|
||||||
|
**Nachher:** Software als austauschbare Datei → Betriebssysteme, Apps, Updates moeglich
|
||||||
|
|
||||||
|
**Harvard-Architektur (Alternative):** Getrennter Speicher fuer Code und Daten → schneller, aber weniger flexibel (Arduino, DSPs)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
<!-- _class: lead -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Vom Militär zum Netz
|
# Vom Militär zum Netz
|
||||||
@@ -1056,6 +1144,9 @@ Formattierungssprache
|
|||||||
---
|
---
|
||||||
|
|
||||||
<!-- _class: klausur -->
|
<!-- _class: klausur -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
<!-- _backgroundColor: #fce4ec -->
|
||||||
|
|
||||||
# HTML Metadaten
|
# HTML Metadaten
|
||||||
|
|
||||||
@@ -1094,6 +1185,30 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
<!-- _class: erklaerung -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
|
||||||
|
# HTML Metadaten: Erklaerung
|
||||||
|
|
||||||
|
**Definition:** Der `<head>`-Bereich enthaelt Informationen ueber das Dokument, die nicht direkt im Browser angezeigt werden.
|
||||||
|
|
||||||
|
| Meta-Tag | Zweck | Beispiel |
|
||||||
|
|----------|-------|----------|
|
||||||
|
| `<title>` | Browser-Tab, Lesezeichen, SEO | "Meine Website" |
|
||||||
|
| `<meta charset>` | Zeichenkodierung | UTF-8 fuer Umlaute |
|
||||||
|
| `<meta description>` | Suchmaschinen-Snippet | Max. 160 Zeichen |
|
||||||
|
| `<meta viewport>` | Mobile Darstellung | width=device-width |
|
||||||
|
| `<meta og:image>` | Social Media Vorschau | Bild beim Teilen |
|
||||||
|
|
||||||
|
**Wichtige Unterscheidung:**
|
||||||
|
- `<head>`: Metadaten (fuer Browser, Suchmaschinen, Social Media)
|
||||||
|
- `<body>`: Sichtbarer Inhalt (fuer Menschen)
|
||||||
|
|
||||||
|
**Merkhilfe:** "Head = Gehirn (unsichtbar), Body = Koerper (sichtbar)"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
# HTML-Tags und Attribute
|
# HTML-Tags und Attribute
|
||||||
|
|
||||||
```html
|
```html
|
||||||
@@ -1264,15 +1379,330 @@ https://developer.mozilla.org/de/docs/Web/HTML/Reference/Elements/input
|
|||||||
|
|
||||||
https://developer.mozilla.org/de/docs/Web/HTML/Reference/Elements/dialog
|
https://developer.mozilla.org/de/docs/Web/HTML/Reference/Elements/dialog
|
||||||
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
# "Barrierefreiheit"
|
||||||
|
## a11y – Accessibility
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: lead -->
|
||||||
|
|
||||||
|
# Web Disability Simulator
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: klausur -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
<!-- _backgroundColor: #fce4ec -->
|
||||||
|
|
||||||
|
# Wie nutzen Menschen das Web?
|
||||||
|
|
||||||
|
| Eingabe | Nutzungsweise |
|
||||||
|
|---------|---------------|
|
||||||
|
| **Maus** | Klicken, Scrollen |
|
||||||
|
| **Tastatur** | Tab-Navigation, Enter, Pfeiltasten |
|
||||||
|
| **Screenreader** | Vorlesen von Inhalten (NVDA, VoiceOver, JAWS) |
|
||||||
|
| **Sprachsteuerung** | "Klicke auf Anmelden" |
|
||||||
|
| **Augensteuerung** | Eye-Tracking |
|
||||||
|
| **Switch-Geräte** | Ein-/Aus-Schalter |
|
||||||
|
|
||||||
|
→ **Nicht alle nutzen Maus + Bildschirm!**
|
||||||
|
|
||||||
|
<!--
|
||||||
|
ACCESSIBILITY (a11y): a + 11 Buchstaben + y
|
||||||
|
STATISTIK: ~15% der Weltbevölkerung haben eine Behinderung (WHO)
|
||||||
|
ARTEN VON EINSCHRÄNKUNGEN:
|
||||||
|
- Permanent: Blindheit, Taubheit, motorische Einschränkungen
|
||||||
|
- Temporär: Gebrochener Arm, Augen-OP, Ohrenentzündung
|
||||||
|
- Situativ: Helle Sonne (Kontrast), laute Umgebung (kein Audio), Baby auf Arm (eine Hand)
|
||||||
|
ASSISTIVE TECHNOLOGIEN:
|
||||||
|
- Screenreader: NVDA (Windows, kostenlos), VoiceOver (Apple), JAWS (kommerziell)
|
||||||
|
- Braillezeilen: Taktile Ausgabe für Blinde
|
||||||
|
- Switch-Geräte: Für motorische Einschränkungen
|
||||||
|
- Spracheingabe: Dragon NaturallySpeaking, Siri, Google Assistant
|
||||||
|
WCAG: Web Content Accessibility Guidelines (A, AA, AAA)
|
||||||
|
EUROPEAN ACCESSIBILITY ACT: Seit Juni 2025 verpflichtend!
|
||||||
|
PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: erklaerung -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
|
||||||
|
# Web-Nutzung: Erklaerung
|
||||||
|
|
||||||
|
**Definition:** Menschen nutzen das Web auf sehr unterschiedliche Weisen - nicht nur mit Maus und Bildschirm.
|
||||||
|
|
||||||
|
**Eingabemethoden:**
|
||||||
|
- **Maus/Trackpad:** Klicken, Scrollen, Hover
|
||||||
|
- **Tastatur:** Tab-Navigation, Shortcuts, Pfeiltasten
|
||||||
|
- **Screenreader:** Vorlesen von Inhalten (NVDA, VoiceOver, JAWS)
|
||||||
|
- **Sprache/Augen:** Sprachbefehle, Eye-Tracking, Switch-Geraete
|
||||||
|
|
||||||
|
**Arten von Einschraenkungen:**
|
||||||
|
- **Permanent:** Blindheit, Taubheit, motorische Einschraenkungen
|
||||||
|
- **Temporaer:** Gebrochener Arm, Augen-OP
|
||||||
|
- **Situativ:** Sonnenlicht, laute Umgebung, Baby auf Arm
|
||||||
|
|
||||||
|
**Merkhilfe:** "a11y" = a + 11 Buchstaben + y = "accessibility"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: klausur -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
<!-- _backgroundColor: #fce4ec -->
|
||||||
|
|
||||||
|
# Warum "Barrierefreiheit"?
|
||||||
|
|
||||||
|
**Rechtlich:**
|
||||||
|
- EU: European Accessibility Act (seit Juni 2025 in Kraft!)
|
||||||
|
- DE: BITV 2.0 (Behörden), Privatwirtschaft betroffen
|
||||||
|
|
||||||
|
**Ethisch:**
|
||||||
|
- Teilhabe für alle Menschen
|
||||||
|
- Digitale Inklusion
|
||||||
|
|
||||||
|
**Praktisch:**
|
||||||
|
- Bessere UX für **alle** (SEO, Mobile, ältere Menschen)
|
||||||
|
- Größerer Markt (~15% der Bevölkerung)
|
||||||
|
|
||||||
|
<!--
|
||||||
|
RECHTLICHER RAHMEN:
|
||||||
|
- European Accessibility Act (EAA): EU-Richtlinie, seit 28. Juni 2025 in Kraft
|
||||||
|
- Betrifft: E-Commerce, Banking, Telekommunikation, Transport, E-Books
|
||||||
|
- BITV 2.0: Barrierefreie Informationstechnik-Verordnung (DE, öffentliche Stellen)
|
||||||
|
- BFSG: Barrierefreiheitsstärkungsgesetz (DE-Umsetzung des EAA)
|
||||||
|
- Strafen: Bis zu 100.000€ Bußgeld möglich
|
||||||
|
CURB-CUT-EFFEKT:
|
||||||
|
- Bordsteinabsenkung für Rollstuhlfahrer → hilft auch Kinderwagen, Rollkoffern, Fahrrädern
|
||||||
|
- Untertitel für Gehörlose → helfen in lauter Umgebung, beim Sprachlernen
|
||||||
|
- Kontrastreiche Farben → besser bei Sonnenlicht, für ältere Menschen
|
||||||
|
BUSINESS CASE:
|
||||||
|
- 15% Zielgruppe (Menschen mit Behinderung)
|
||||||
|
- +20% ältere Menschen (Sehschwäche, motorische Einschränkungen)
|
||||||
|
- SEO-Vorteile: Alt-Texte, semantisches HTML = besser für Google
|
||||||
|
PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: erklaerung -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
|
||||||
|
# Barrierefreiheit: Erklaerung
|
||||||
|
|
||||||
|
**Definition:** Barrierefreiheit (Accessibility) bedeutet, dass digitale Inhalte fuer alle Menschen zugaenglich sind - unabhaengig von koerperlichen oder technischen Einschraenkungen.
|
||||||
|
|
||||||
|
**Rechtlicher Rahmen:**
|
||||||
|
- **European Accessibility Act (EAA):** Seit Juni 2025 EU-weit verpflichtend
|
||||||
|
- **BITV 2.0:** Deutsche Verordnung fuer oeffentliche Stellen
|
||||||
|
- **Strafen:** Bis zu 100.000 EUR Bussgeld moeglich
|
||||||
|
|
||||||
|
**Curb-Cut-Effekt:** Massnahmen fuer Menschen mit Behinderung helfen allen:
|
||||||
|
- Untertitel → laute Umgebung, Sprachlernen
|
||||||
|
- Kontrast → Sonnenlicht, aeltere Menschen
|
||||||
|
- Tastatur-Navigation → Power-User, RSI-Betroffene
|
||||||
|
|
||||||
|
**Business Case:** ~15% Menschen mit Behinderung + ~20% Aeltere = 35% potenzielle Zielgruppe
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# WCAG: Der Standard
|
||||||
|
|
||||||
|
**W**eb **C**ontent **A**ccessibility **G**uidelines
|
||||||
|
|
||||||
|
**4 Prinzipien (POUR):**
|
||||||
|
|
||||||
|
| Prinzip | Bedeutung |
|
||||||
|
|---------|-----------|
|
||||||
|
| **Perceivable** | Wahrnehmbar – Inhalte müssen erkennbar sein |
|
||||||
|
| **Operable** | Bedienbar – Funktionen müssen nutzbar sein |
|
||||||
|
| **Understandable** | Verständlich – Inhalte müssen klar sein |
|
||||||
|
| **Robust** | Robust – Funktioniert mit verschiedenen Technologien |
|
||||||
|
|
||||||
|
<!--
|
||||||
|
WCAG vom W3C (World Wide Web Consortium)
|
||||||
|
Aktuelle Version: WCAG 2.2 (2023)
|
||||||
|
Level: A (minimal), AA (Standard), AAA (optimal)
|
||||||
|
Gesetzlich meist Level AA gefordert
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Perceivable: Wahrnehmbar
|
||||||
|
|
||||||
|
**Textalternativen für Nicht-Text:**
|
||||||
|
```html
|
||||||
|
<img src="team.jpg" alt="Unser Team bei der Weihnachtsfeier 2024">
|
||||||
|
```
|
||||||
|
|
||||||
|
**Kontrast:** Mindestens 4.5:1 für Text
|
||||||
|
|
||||||
|
**Untertitel:** Videos brauchen Captions
|
||||||
|
|
||||||
|
**Responsive:** Inhalte bei 200% Zoom nutzbar
|
||||||
|
|
||||||
|
<!--
|
||||||
|
Leeres alt="" für dekorative Bilder
|
||||||
|
Contrast-Checker: WebAIM Contrast Checker
|
||||||
|
Captions ≠ Untertitel (Captions = auch Geräusche beschrieben)
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Operable: Bedienbar
|
||||||
|
|
||||||
|
**Tastaturzugänglich:**
|
||||||
|
```css
|
||||||
|
/* Fokus-Indikator NIE entfernen! */
|
||||||
|
:focus {
|
||||||
|
outline: 2px solid blue;
|
||||||
|
outline-offset: 2px;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* Wenn custom styling: */
|
||||||
|
button:focus-visible {
|
||||||
|
box-shadow: 0 0 0 3px rgba(0, 100, 255, 0.5);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Genug Zeit:** Keine automatischen Timeouts ohne Warnung
|
||||||
|
|
||||||
|
**Keine Blitze:** Nichts blinkt mehr als 3x pro Sekunde
|
||||||
|
|
||||||
|
<!--
|
||||||
|
Tab-Reihenfolge = DOM-Reihenfolge
|
||||||
|
Skip-Links: "Zum Hauptinhalt springen"
|
||||||
|
:focus-visible = nur bei Tastatur-Navigation
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Understandable: Verständlich
|
||||||
|
|
||||||
|
**Sprache angeben:**
|
||||||
|
```html
|
||||||
|
<html lang="de">
|
||||||
|
```
|
||||||
|
|
||||||
|
**Konsistente Navigation:** Gleiche Elemente an gleicher Stelle
|
||||||
|
|
||||||
|
**Fehler erklären:**
|
||||||
|
```html
|
||||||
|
<input type="email" aria-describedby="email-error">
|
||||||
|
<p id="email-error" role="alert">
|
||||||
|
Bitte geben Sie eine gültige E-Mail-Adresse ein.
|
||||||
|
</p>
|
||||||
|
```
|
||||||
|
|
||||||
|
<!--
|
||||||
|
Screenreader nutzen lang für korrekte Aussprache
|
||||||
|
Konsistenz reduziert kognitive Last
|
||||||
|
Fehlermeldungen: konkret, hilfreich, am Feld
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Robust: Technisch solide
|
||||||
|
|
||||||
|
**Semantisches HTML:**
|
||||||
|
```html
|
||||||
|
<!-- Schlecht -->
|
||||||
|
<div class="button" onclick="...">Klick mich</div>
|
||||||
|
|
||||||
|
<!-- Gut -->
|
||||||
|
<button type="button">Klick mich</button>
|
||||||
|
```
|
||||||
|
|
||||||
|
**ARIA nur wenn nötig:**
|
||||||
|
```html
|
||||||
|
<!-- Nötig: Custom-Komponente -->
|
||||||
|
<div role="tablist" aria-label="Produktkategorien">
|
||||||
|
<button role="tab" aria-selected="true">Schuhe</button>
|
||||||
|
<button role="tab" aria-selected="false">Jacken</button>
|
||||||
|
</div>
|
||||||
|
```
|
||||||
|
|
||||||
|
<!--
|
||||||
|
ARIA = Accessible Rich Internet Applications
|
||||||
|
Erste Regel von ARIA: Wenn möglich, natives HTML nutzen!
|
||||||
|
button hat eingebaute Tastatur-Unterstützung
|
||||||
|
div-Button braucht JavaScript für Enter/Space
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: klausur -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
<!-- _backgroundColor: #fce4ec -->
|
||||||
|
|
||||||
|
# Barrieren im Netz vermeiden (a11y)
|
||||||
|
|
||||||
|
**Tastatur-Test:**
|
||||||
|
- Alle Funktionen nur mit Tab + Enter nutzbar?
|
||||||
|
- Fokus immer sichtbar?
|
||||||
|
- Logische Tab-Reihenfolge?
|
||||||
|
|
||||||
|
**Screenreader-Test:**
|
||||||
|
- VoiceOver (Mac): `Cmd + F5`
|
||||||
|
- NVDA (Windows): Gratis-Download
|
||||||
|
|
||||||
|
**Tools:**
|
||||||
|
- axe DevTools, WAVE (Browser-Extensions)
|
||||||
|
- Lighthouse (in Chrome DevTools)
|
||||||
|
|
||||||
|
<!--
|
||||||
|
Automatische Tests finden ~30% der Probleme
|
||||||
|
Manuelles Testen unverzichtbar
|
||||||
|
Echte NutzerInnen einbeziehen = Gold-Standard
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- _class: erklaerung -->
|
||||||
|
<!-- _header: '' -->
|
||||||
|
<!-- _footer: '' -->
|
||||||
|
|
||||||
|
# Barrieren vermeiden: Erklaerung
|
||||||
|
|
||||||
|
**Definition:** Praktische Massnahmen zur Pruefung und Sicherstellung der Barrierefreiheit von Webseiten.
|
||||||
|
|
||||||
|
**Tastatur-Test (selbst durchfuehren):**
|
||||||
|
1. Tab druecken → Springt der Fokus logisch durch die Seite?
|
||||||
|
2. Ist der fokussierte Bereich immer sichtbar markiert?
|
||||||
|
3. Kann man alle Funktionen ohne Maus bedienen?
|
||||||
|
|
||||||
|
**Screenreader-Test:**
|
||||||
|
- **Mac:** VoiceOver aktivieren mit `Cmd + F5`
|
||||||
|
- **Windows:** NVDA installieren (kostenlos)
|
||||||
|
- **Frage:** Ergibt die vorgelesene Seite Sinn?
|
||||||
|
|
||||||
|
**Automatische Tools (finden ~30% der Probleme):**
|
||||||
|
- axe DevTools, WAVE (Browser-Extensions)
|
||||||
|
- Lighthouse (in Chrome DevTools unter F12)
|
||||||
|
|
||||||
|
**Merkhilfe WCAG-Prinzipien:** "**P**erceivable, **O**perable, **U**nderstandable, **R**obust" (POUR)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
<!-- _class: lead -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Fragen & Diskussion
|
# Fragen & Diskussion
|
||||||
|
|
||||||
**Nächster Termin:** 10.01.2026 – CSS & Netzwerke
|
**Nächster Termin:** 10.01.2026 – CSS & Netzwerke
|
||||||
|
|
||||||
**Kontakt:** mail@librete.ch
|
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -3,9 +3,9 @@ marp: true
|
|||||||
theme: gaia
|
theme: gaia
|
||||||
paginate: true
|
paginate: true
|
||||||
backgroundColor: #fff
|
backgroundColor: #fff
|
||||||
header: "Grundlagen IT- und Internettechnik"
|
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||||
title: "Termin 3: Interaktivität & JavaScript"
|
title: "Kapitel 3: Interaktivität & JavaScript"
|
||||||
---
|
---
|
||||||
|
|
||||||
<style>
|
<style>
|
||||||
@@ -48,6 +48,26 @@ code {
|
|||||||
a {
|
a {
|
||||||
color: var(--color-highlight);
|
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>
|
</style>
|
||||||
|
|
||||||
<!-- _class: invert -->
|
<!-- _class: invert -->
|
||||||
@@ -78,7 +98,7 @@ Hochschule der Medien Stuttgart
|
|||||||
|
|
||||||
<!-- _class: lead -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Termin 3 – 24.01.2026
|
# Kapitel 3 – 24.01.2026
|
||||||
## Interaktivität & JavaScript
|
## Interaktivität & JavaScript
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -984,7 +1004,7 @@ Euer ehrliches Feedback hilft mir, den Kurs zu verbessern.
|
|||||||
- Was könnte besser sein?
|
- Was könnte besser sein?
|
||||||
- Welche Themen interessieren euch noch?
|
- 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!
|
# Danke!
|
||||||
|
|
||||||
**Kontakt:** mail@librete.ch
|
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||||||
|
|
||||||
**Ressourcen:**
|
**Ressourcen:**
|
||||||
- https://nextlevelshit.github.io/html-over-js/
|
- https://nextlevelshit.github.io/html-over-js/
|
||||||