Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
8d5c57d561 | ||
|
|
3a2e1a8d15 | ||
|
|
ac89d69365 | ||
|
|
552949811e | ||
|
|
030bb322a2 | ||
|
|
9631a1c45b | ||
|
|
4245ea2567 | ||
|
|
51146d3dfc | ||
|
|
fda4aca4c7 | ||
|
|
aff352fa91 | ||
|
|
ea7e905c61 | ||
|
|
512fbd9d3d | ||
|
|
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 |
No files matched your search
@@ -32,3 +32,4 @@ hdm-internettechnik-slides/
|
||||
# Temporary files
|
||||
*.tmp
|
||||
*.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,18 +4,19 @@ This project builds presentation decks for Marp, supporting multiple courses.
|
||||
|
||||
## Courses
|
||||
|
||||
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Termine)
|
||||
- **223015c** - Internettechnologien (3 Termine)
|
||||
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
|
||||
- **223015c** - Internettechnologien (3 Kapitel)
|
||||
|
||||
## Agent Restrictions
|
||||
|
||||
- Agent NEVER runs commands outside this folder
|
||||
- Agent NEVER runs build/deploy commands without explicit user request
|
||||
- Agent NEVER runs deploy commands (make deploy, scp, etc.) without explicit user permission
|
||||
- Agent NEVER runs `git checkout --` or `git restore` on files with uncommitted work. To undo specific changes, use targeted Edit operations instead.
|
||||
|
||||
## Critical File Protection
|
||||
|
||||
Slide files in `courses/*/slides/*.md` are main content files:
|
||||
Slide files in `slides/*/*.md` are main content files:
|
||||
- ALLOWED: Adding slides, adjusting content, fixing typos, enhancing sections
|
||||
- FORBIDDEN (without permission): Deleting slides, removing sections, bulk deletions
|
||||
- Before ANY deletion: ALWAYS ask user for confirmation
|
||||
@@ -23,9 +24,9 @@ Slide files in `courses/*/slides/*.md` are main content files:
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
courses/
|
||||
├── 223015b/slides/ # Dateiformate course
|
||||
└── 223015c/slides/ # Internettechnik course
|
||||
slides/
|
||||
├── 223015b/ # Dateiformate course
|
||||
└── 223015c/ # Internettechnik course
|
||||
scripts/ # Shared scripts
|
||||
themes/ # Custom Marp themes
|
||||
build/ # Generated output (gitignored)
|
||||
@@ -34,34 +35,32 @@ build/ # Generated output (gitignored)
|
||||
## Build Commands
|
||||
|
||||
```bash
|
||||
make dev-b # Dev server 223015b (port 1312)
|
||||
make dev-c # Dev server 223015c (port 1313)
|
||||
make dev-b # Dev server 223015b (port 1311)
|
||||
make dev-c # Dev server 223015c (port 1312)
|
||||
make build # Build all courses
|
||||
make build-b # Build 223015b only
|
||||
make build-c # Build 223015c only
|
||||
make html # HTML only
|
||||
make pdf # PDF only
|
||||
make klausur # Extract klausur slides → slides/*/klausur.md
|
||||
make deploy # Deploy all (ASK FIRST!)
|
||||
```
|
||||
|
||||
## Nix Flake Commands
|
||||
|
||||
```bash
|
||||
nix develop # Dev shell with all tools
|
||||
nix run .#qr -- "https://example.com" # Generate QR code
|
||||
nix run .#qr-slides -- 223015b # QR for course
|
||||
nix run .#optimize-img -- <path> # Optimize images
|
||||
nix develop # Dev shell with all tools (node 22, npm, make)
|
||||
```
|
||||
|
||||
## Code Style Guidelines
|
||||
|
||||
### File Structure
|
||||
- Slides in `courses/<course>/slides/`
|
||||
- Assets in `courses/<course>/slides/assets/`
|
||||
- Slides in `slides/<course>/`
|
||||
- Assets in `slides/<course>/assets/`
|
||||
- Always reference images as `./assets/filename.png`
|
||||
|
||||
### Naming Conventions
|
||||
- Slide files: `YYYY-MM-DD-termin-N-topic.md`
|
||||
- Slide files: `NN-topic.md` (e.g., `01-grundlagen.md`)
|
||||
- Images: `snake_case.jpg` or `kebab-case.jpg`
|
||||
|
||||
### Markdown Style
|
||||
|
||||
@@ -1,25 +1,19 @@
|
||||
# HdM Slides - Unified Makefile
|
||||
# Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
|
||||
|
||||
.PHONY: help dev dev-b dev-c build build-b build-c pdf html clean install deploy qr optimize-images
|
||||
.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images
|
||||
|
||||
# Course configuration
|
||||
COURSES = 223015b 223015c
|
||||
COURSE_DIR = courses
|
||||
|
||||
# Port configuration (index starts at BASE_PORT, courses increment from there)
|
||||
BASE_PORT = 1310
|
||||
INDEX_PORT = $(BASE_PORT)
|
||||
SLIDES_DIR = slides
|
||||
|
||||
# Course-specific settings
|
||||
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
|
||||
223015b_PORT = 1311
|
||||
223015b_TERMINS = 2025-12-19-termin-0-intro 2025-12-19-termin-1-grundlagen-text-audio 2026-01-09-termin-2-bild-audio-video 2026-01-23-termin-3-speichermedien-schnittstellen 2026-01-30-termin-4-distribution-apis-zukunft 2026-xx-xx-termin-5-vertiefung-offene-fragen
|
||||
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien klausurfragen
|
||||
223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
|
||||
|
||||
223015c_NAME = Internettechnologien
|
||||
223015c_PORT = 1312
|
||||
223015c_TERMINS = 2025-12-20-termin-1-geschichte-grundlagen-html 2026-01-10-termin-2-netzwerke-protokolle-css 2026-01-24-termin-3-interaktivitaet-javascript
|
||||
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
|
||||
223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
|
||||
|
||||
DEPLOY_HOST = tengo@tuttle.uberspace.de
|
||||
@@ -33,9 +27,7 @@ help:
|
||||
@echo " 223015c - Internettechnologien"
|
||||
@echo ""
|
||||
@echo "Development:"
|
||||
@echo " make dev - Both servers + index (ports 1311, 1312, 1313)"
|
||||
@echo " make dev-b - Dev server for 223015b (port 1312)"
|
||||
@echo " make dev-c - Dev server for 223015c (port 1313)"
|
||||
@echo " make dev - Start development server (port 3000)"
|
||||
@echo ""
|
||||
@echo "Build:"
|
||||
@echo " make build - Build all courses"
|
||||
@@ -43,6 +35,7 @@ help:
|
||||
@echo " make build-c - Build 223015c only"
|
||||
@echo " make pdf - Export all to PDF"
|
||||
@echo " make html - Export all to HTML"
|
||||
@echo " make klausur - Extract klausurfolien slides"
|
||||
@echo ""
|
||||
@echo "Tools:"
|
||||
@echo " make qr URL=... - Generate QR code for URL"
|
||||
@@ -62,36 +55,25 @@ build/.exists:
|
||||
@mkdir -p build/223015b build/223015c
|
||||
@touch $@
|
||||
|
||||
# Development servers
|
||||
# Development server
|
||||
dev:
|
||||
@./scripts/dev-server.sh
|
||||
|
||||
dev-kill:
|
||||
@-pkill -f "python3 -m http.server" 2>/dev/null || true
|
||||
@-pkill -f "marp-cli.*--server" 2>/dev/null || true
|
||||
@sleep 0.5
|
||||
|
||||
dev-b:
|
||||
@echo "Starting 223015b dev server on port $(223015b_PORT)..."
|
||||
@echo "Open: http://localhost:$(223015b_PORT)"
|
||||
PORT=$(223015b_PORT) npx @marp-team/marp-cli --server $(COURSE_DIR)/223015b/slides/
|
||||
|
||||
dev-c:
|
||||
@echo "Starting 223015c dev server on port $(223015c_PORT)..."
|
||||
@echo "Open: http://localhost:$(223015c_PORT)"
|
||||
PORT=$(223015c_PORT) npx @marp-team/marp-cli --server $(COURSE_DIR)/223015c/slides/
|
||||
|
||||
# Build functions
|
||||
define build_course
|
||||
@echo "Building $(1)..."
|
||||
@mkdir -p build/$(1)
|
||||
@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
|
||||
@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
|
||||
@for f in $($(1)_TERMINS); do \
|
||||
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
|
||||
@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
|
||||
@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
|
||||
@for f in $($(1)_KAPITEL); do \
|
||||
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
|
||||
echo " Building $$f..."; \
|
||||
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md -o build/$(1)/$$f.html; \
|
||||
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
|
||||
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md -o build/$(1)/$$f.html; \
|
||||
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
|
||||
fi \
|
||||
done
|
||||
@./scripts/generate-index.sh $(1) build/$(1)
|
||||
@@ -110,12 +92,12 @@ build: build-b build-c
|
||||
define html_course
|
||||
@echo "Building HTML for $(1)..."
|
||||
@mkdir -p build/$(1)
|
||||
@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
|
||||
@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
|
||||
@for f in $($(1)_TERMINS); do \
|
||||
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
|
||||
@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
|
||||
@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
|
||||
@for f in $($(1)_KAPITEL); do \
|
||||
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
|
||||
echo " $$f.html"; \
|
||||
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md -o build/$(1)/$$f.html; \
|
||||
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md -o build/$(1)/$$f.html; \
|
||||
fi \
|
||||
done
|
||||
@./scripts/generate-index.sh $(1) build/$(1)
|
||||
@@ -133,10 +115,10 @@ html: html-b html-c
|
||||
define pdf_course
|
||||
@echo "Building PDFs for $(1)..."
|
||||
@mkdir -p build/$(1)
|
||||
@for f in $($(1)_TERMINS); do \
|
||||
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
|
||||
@for f in $($(1)_KAPITEL); do \
|
||||
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
|
||||
echo " $$f.pdf"; \
|
||||
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
|
||||
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
|
||||
fi \
|
||||
done
|
||||
endef
|
||||
@@ -149,6 +131,16 @@ pdf-c: build/.exists
|
||||
|
||||
pdf: pdf-b pdf-c
|
||||
|
||||
# Klausur slide extraction
|
||||
klausur-b:
|
||||
@./scripts/extract-klausur.sh 223015b
|
||||
|
||||
klausur-c:
|
||||
@./scripts/extract-klausur.sh 223015c
|
||||
|
||||
klausur: klausur-b klausur-c
|
||||
@echo "Klausurfolien slides extracted for all courses!"
|
||||
|
||||
# QR Code generation (uses nix-shell)
|
||||
qr:
|
||||
ifndef URL
|
||||
@@ -174,9 +166,9 @@ ifndef COURSE
|
||||
@echo "Usage: make optimize-images COURSE=223015b"
|
||||
else
|
||||
@echo "Optimizing images for $(COURSE)..."
|
||||
@mkdir -p $(COURSE_DIR)/$(COURSE)/slides/assets-original
|
||||
@nix-shell -p imagemagick --run 'for img in $(COURSE_DIR)/$(COURSE)/slides/assets/*.png $(COURSE_DIR)/$(COURSE)/slides/assets/*.jpg 2>/dev/null; do \
|
||||
[ -f "$$img" ] && cp "$$img" $(COURSE_DIR)/$(COURSE)/slides/assets-original/ && \
|
||||
@mkdir -p $(SLIDES_DIR)/$(COURSE)/assets-original
|
||||
@nix-shell -p imagemagick --run 'for img in $(SLIDES_DIR)/$(COURSE)/assets/*.png $(SLIDES_DIR)/$(COURSE)/assets/*.jpg 2>/dev/null; do \
|
||||
[ -f "$$img" ] && cp "$$img" $(SLIDES_DIR)/$(COURSE)/assets-original/ && \
|
||||
magick "$$img" -resize "1920x>" -quality 85 "$$img" && echo " Optimized: $$(basename $$img)"; \
|
||||
done || true'
|
||||
@echo "Done! Originals in assets-original/"
|
||||
@@ -187,7 +179,8 @@ HDM_DEPLOY_PATH = /home/tengo/html/hdm
|
||||
|
||||
build-index: build/.exists
|
||||
@echo "Building root index..."
|
||||
@echo '<!DOCTYPE html><html lang="de"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>HdM Vorlesungen</title><style>*{box-sizing:border-box;margin:0;padding:0}body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}.subtitle{color:#86868b;font-size:1rem}.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}.course-b .course-label{color:#1e5f8a}.course-c .course-label{color:#d63384}.course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}.course-info{font-size:.85rem;color:#86868b}.section-title{font-size:1rem;font-weight:600;color:#86868b;margin-top:2.5rem;margin-bottom:.75rem}.references{display:flex;flex-direction:column;gap:.75rem}footer{margin-top:2.5rem;padding-top:1.5rem;border-top:1px solid #e5e5e7;color:#86868b;font-size:.85rem}footer a{color:#1d1d1f;text-decoration:none}footer a:hover{text-decoration:underline}.qr-section{margin-top:2.5rem;padding:1.5rem;background:#fff;border-radius:12px;box-shadow:0 1px 3px rgba(0,0,0,0.08);text-align:center}.qr-code{width:100%;height:auto}.qr-url{margin-top:.75rem;font-size:.85rem;color:#86868b}</style></head><body><h1>HdM Vorlesungen</h1><p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p><div class="courses"><a class="course course-b" href="223015b/"><span class="course-label">223015b</span><div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class="course-info">6 Termine · Modul "Technik 1"</span></a><a class="course course-c" href="223015c/"><span class="course-label">223015c</span><div class="course-title">Grundlagen IT- und Internettechnik</div><span class="course-info">3 Termine · Modul "Technik 1"</span></a></div><h2 class="section-title">Referenzen</h2><div class="references"><a class="course" href="https://codecrispi.es/"><span class="course-label">Plattform</span><div class="course-title">Code Crispies</div><span class="course-info">Selbstlernplattform</span></a></div><div class="qr-section"><img src="qr-root.svg" alt="QR Code" class="qr-code"><p class="qr-url">https://librete.ch/hdm/</p></div><footer><a href="mailto:mail@librete.ch">Kontakt</a></footer></body></html>' > build/index.html
|
||||
@mkdir -p build
|
||||
@./scripts/generate-root-index.sh
|
||||
|
||||
# Deploy
|
||||
define deploy_course
|
||||
|
||||
@@ -1,182 +1,97 @@
|
||||
# HdM Slides
|
||||
|
||||
**Modul "Technik 1"** - 1. Semester - Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart - Wintersemester 2025/26
|
||||
Presentation slides for HdM Stuttgart courses, built with [Marp](https://marp.app/).
|
||||
|
||||
---
|
||||
## Courses
|
||||
|
||||
## Kurse
|
||||
| Code | Title | Kapitel |
|
||||
|------|-------|---------|
|
||||
| 223015b | Dateiformate, Schnittstellen, Speichermedien | 6 |
|
||||
| 223015c | Internettechnologien | 3 |
|
||||
|
||||
### 223015b - Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
## Project Structure
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 0 | 19.12.2025 | Intro |
|
||||
| 1 | 19.12.2025 | Grundlagen, Text & Audio |
|
||||
| 2 | 09.01.2026 | Bild- & Videoformate |
|
||||
| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
|
||||
| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
|
||||
| 5 | TBA | Vertiefung & offene Fragen |
|
||||
|
||||
### 223015c - Internettechnologien
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 1 | 20.12.2025 | Geschichte, Grundlagen & HTML |
|
||||
| 2 | 10.01.2026 | Netzwerke, Protokolle & CSS |
|
||||
| 3 | 24.01.2026 | Interaktivitat & JavaScript |
|
||||
|
||||
**Dozent:** Michael Czechowski - mail@librete.ch
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
### Mit Nix (empfohlen)
|
||||
|
||||
```bash
|
||||
# Development shell mit allen Tools
|
||||
nix develop
|
||||
|
||||
# Oder direkt QR-Code generieren
|
||||
nix run .#qr -- "https://example.com"
|
||||
nix run .#qr-slides -- 223015b
|
||||
```
|
||||
|
||||
### Ohne Nix
|
||||
|
||||
```bash
|
||||
npm install
|
||||
make dev-b # 223015b auf Port 1312
|
||||
make dev-c # 223015c auf Port 1313
|
||||
slides/
|
||||
├── 223015b/ # Dateiformate course
|
||||
│ ├── 00-intro.md
|
||||
│ ├── 01-grundlagen-text-audio.md
|
||||
│ └── ...
|
||||
└── 223015c/ # Internettechnik course
|
||||
├── 01-geschichte-grundlagen-html.md
|
||||
└── ...
|
||||
scripts/ # Build scripts
|
||||
build/ # Generated output (gitignored)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Development
|
||||
|
||||
### Dev Server starten
|
||||
|
||||
```bash
|
||||
make dev-b # 223015b (Dateiformate) - http://localhost:1312
|
||||
make dev-c # 223015c (Internettechnik) - http://localhost:1313
|
||||
# Start development server (hot reload)
|
||||
make dev # Single server for all courses (port 3000)
|
||||
|
||||
# Access individual courses:
|
||||
# 223015b: http://localhost:3000/223015b/
|
||||
# 223015c: http://localhost:3000/223015c/
|
||||
```
|
||||
|
||||
### Build
|
||||
## Build
|
||||
|
||||
```bash
|
||||
make build # Alle Kurse (HTML + PDF)
|
||||
make build-b # Nur 223015b
|
||||
make build-c # Nur 223015c
|
||||
make html # Nur HTML
|
||||
make pdf # Nur PDF
|
||||
make build # Build all (HTML + PDF)
|
||||
make build-b # Build 223015b only
|
||||
make build-c # Build 223015c only
|
||||
make html # HTML only
|
||||
make pdf # PDF only
|
||||
```
|
||||
|
||||
### Deploy
|
||||
## Klausur Folien
|
||||
|
||||
Extract exam-relevant slides (marked with `<!-- _class: klausur -->`) into a single file:
|
||||
|
||||
```bash
|
||||
make deploy # Alle Kurse
|
||||
make deploy-b # Nur 223015b
|
||||
make deploy-c # Nur 223015c
|
||||
make klausur # Extract all courses
|
||||
make klausur-b # 223015b only
|
||||
make klausur-c # 223015c only
|
||||
```
|
||||
|
||||
---
|
||||
Output: `slides/<course>/klausurfolien.md`
|
||||
|
||||
The generated file includes:
|
||||
- A title slide per kapitel for orientation
|
||||
- All slides marked with `<!-- _class: klausur -->`
|
||||
|
||||
## Tools
|
||||
|
||||
### QR-Code Generator
|
||||
```bash
|
||||
make qr URL=https://example.com # Generate QR code
|
||||
make qr-slides COURSE=223015b # QR for course URL
|
||||
make optimize-images COURSE=223015b # Resize images
|
||||
```
|
||||
|
||||
## Deploy
|
||||
|
||||
```bash
|
||||
# Mit Nix
|
||||
nix run .#qr -- "https://librete.ch/hdm/223015b/"
|
||||
nix run .#qr -- "https://example.com" output.png
|
||||
|
||||
# Mit Make
|
||||
make qr URL=https://example.com
|
||||
make qr URL=https://example.com OUTPUT=my-qr.png
|
||||
|
||||
# Fur Kurse
|
||||
make qr-slides COURSE=223015b
|
||||
make deploy # Deploy all courses
|
||||
make deploy-b # Deploy 223015b only
|
||||
make deploy-c # Deploy 223015c only
|
||||
```
|
||||
|
||||
### Bilder optimieren
|
||||
## Marking Slides as Klausur-Relevant
|
||||
|
||||
```bash
|
||||
# Mit Nix
|
||||
nix run .#optimize-img -- courses/223015b/slides/assets/
|
||||
|
||||
# Mit Make
|
||||
make optimize-images COURSE=223015b
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Projektstruktur
|
||||
|
||||
```
|
||||
hdm/
|
||||
├── courses/
|
||||
│ ├── 223015b/
|
||||
│ │ └── slides/
|
||||
│ │ ├── 2025-12-19-termin-1-grundlagen-text-audio.md
|
||||
│ │ ├── assets/
|
||||
│ │ └── materials/
|
||||
│ └── 223015c/
|
||||
│ └── slides/
|
||||
│ ├── 2025-12-20-termin-1-geschichte-grundlagen-html.md
|
||||
│ └── assets/
|
||||
├── scripts/
|
||||
│ └── generate-index.sh
|
||||
├── themes/
|
||||
│ └── custom-theme.css
|
||||
├── build/ # Generated output
|
||||
├── flake.nix # Nix flake with tools
|
||||
├── Makefile
|
||||
└── package.json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Slides erstellen
|
||||
|
||||
### Frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
marp: true
|
||||
theme: uncover
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
---
|
||||
```
|
||||
|
||||
### Slide-Trennung
|
||||
Add this comment block after the slide separator:
|
||||
|
||||
```markdown
|
||||
# Slide 1
|
||||
|
||||
Content
|
||||
|
||||
---
|
||||
|
||||
# Slide 2
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #e3f2fd -->
|
||||
|
||||
More content
|
||||
# Your Slide Title
|
||||
|
||||
Content here...
|
||||
```
|
||||
|
||||
### Bilder
|
||||
|
||||
```markdown
|
||||

|
||||
```
|
||||
|
||||
### Themes
|
||||
|
||||
Built-in: `default`, `gaia`, `uncover`
|
||||
Custom: in `themes/` Verzeichnis
|
||||
|
||||
---
|
||||
|
||||
## License
|
||||
|
||||
[CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/)
|
||||
The `klausur` class adds a visual indicator (diagonal stripes) during presentation.
|
||||
@@ -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,968 +0,0 @@
|
||||
---
|
||||
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: url('./assets/klausur-pattern.svg') !important;
|
||||
background-size: cover !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
section.aufgabe 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 -->
|
||||
|
||||
# Teil 1: Dateiformate
|
||||
## 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 -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _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 -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _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 -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _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 Qualität
|
||||
|
||||
| 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)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: aufgabe -->
|
||||
|
||||

|
||||
|
||||
# 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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# H.264 / AVC Codec (2003)
|
||||
### Der bisherige Platzhirsch
|
||||
|
||||
**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 Codec (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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 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
|
||||
✓ Erster Codec, der einen Grammy gewonnen hat (2025)
|
||||
|
||||
**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)
|
||||
|
||||
Source: https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: aufgabe -->
|
||||
|
||||
# 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/
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
<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="#fce4ec"/>
|
||||
<rect x="40" width="40" height="80" fill="#ffffff"/>
|
||||
</pattern>
|
||||
</defs>
|
||||
<rect width="100%" height="100%" fill="url(#diagonalStripes)"/>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 401 B |
@@ -1,5 +1,5 @@
|
||||
{
|
||||
description = "HdM Slides - Marp presentation builder with tools";
|
||||
description = "HdM Slides - Marp presentation builder";
|
||||
|
||||
inputs = {
|
||||
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
|
||||
@@ -9,114 +9,19 @@
|
||||
outputs = { self, nixpkgs, flake-utils }:
|
||||
flake-utils.lib.eachDefaultSystem (system:
|
||||
let
|
||||
pkgs = nixpkgs.legacyPackages.${system};
|
||||
|
||||
# QR code generator script
|
||||
qr-gen = pkgs.writeShellScriptBin "qr" ''
|
||||
if [ -z "$1" ]; then
|
||||
echo "Usage: qr <url> [output.png]"
|
||||
echo ""
|
||||
echo "Examples:"
|
||||
echo " qr https://example.com"
|
||||
echo " qr https://example.com my-qr.png"
|
||||
echo " qr 'https://librete.ch/hdm/223015b/' slides-qr.png"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
URL="$1"
|
||||
OUTPUT="''${2:-qr-code.png}"
|
||||
|
||||
${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "$URL"
|
||||
echo "Generated: $OUTPUT"
|
||||
'';
|
||||
|
||||
# QR code for course slides
|
||||
qr-slides = pkgs.writeShellScriptBin "qr-slides" ''
|
||||
COURSE="''${1:-223015b}"
|
||||
OUTPUT="''${2:-build/$COURSE/qr-$COURSE.png}"
|
||||
|
||||
mkdir -p "$(dirname "$OUTPUT")"
|
||||
${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "https://librete.ch/hdm/$COURSE/"
|
||||
echo "Generated QR for $COURSE: $OUTPUT"
|
||||
'';
|
||||
|
||||
# Image optimizer script
|
||||
optimize-img = pkgs.writeShellScriptBin "optimize-img" ''
|
||||
if [ -z "$1" ]; then
|
||||
echo "Usage: optimize-img <image-or-directory> [max-width]"
|
||||
echo ""
|
||||
echo "Resizes images to max width (default: 1920px)"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
TARGET="$1"
|
||||
MAX_WIDTH="''${2:-1920}"
|
||||
|
||||
if [ -d "$TARGET" ]; then
|
||||
for img in "$TARGET"/*.{png,jpg,jpeg,webp} 2>/dev/null; do
|
||||
[ -f "$img" ] || continue
|
||||
echo "Optimizing: $(basename "$img")"
|
||||
${pkgs.imagemagick}/bin/magick "$img" -resize "''${MAX_WIDTH}x>" -quality 85 "$img"
|
||||
done
|
||||
elif [ -f "$TARGET" ]; then
|
||||
echo "Optimizing: $TARGET"
|
||||
${pkgs.imagemagick}/bin/magick "$TARGET" -resize "''${MAX_WIDTH}x>" -quality 85 "$TARGET"
|
||||
else
|
||||
echo "Error: $TARGET not found"
|
||||
exit 1
|
||||
fi
|
||||
echo "Done!"
|
||||
'';
|
||||
|
||||
pkgs = import nixpkgs { inherit system; };
|
||||
in {
|
||||
# Development shell with all tools
|
||||
devShells.default = pkgs.mkShell {
|
||||
buildInputs = with pkgs; [
|
||||
nodejs_20
|
||||
nodejs_22
|
||||
nodePackages.npm
|
||||
qrencode
|
||||
imagemagick
|
||||
gnumake
|
||||
];
|
||||
|
||||
shellHook = ''
|
||||
echo "HdM Slides Development Environment"
|
||||
echo ""
|
||||
echo "Available commands:"
|
||||
echo " make dev-b - Start 223015b dev server (port 1312)"
|
||||
echo " make dev-c - Start 223015c dev server (port 1313)"
|
||||
echo " make build - Build all courses"
|
||||
echo " qr <url> - Generate QR code"
|
||||
echo " qr-slides 223015b - Generate QR for course"
|
||||
echo " optimize-img <dir> - Optimize images"
|
||||
echo ""
|
||||
echo "HdM Slides - run 'make' for available commands"
|
||||
'';
|
||||
};
|
||||
|
||||
# Standalone apps
|
||||
packages = {
|
||||
qr = qr-gen;
|
||||
qr-slides = qr-slides;
|
||||
optimize-img = optimize-img;
|
||||
default = qr-gen;
|
||||
};
|
||||
|
||||
# Direct runnable apps
|
||||
apps = {
|
||||
qr = {
|
||||
type = "app";
|
||||
program = "${qr-gen}/bin/qr";
|
||||
};
|
||||
qr-slides = {
|
||||
type = "app";
|
||||
program = "${qr-slides}/bin/qr-slides";
|
||||
};
|
||||
optimize-img = {
|
||||
type = "app";
|
||||
program = "${optimize-img}/bin/optimize-img";
|
||||
};
|
||||
default = self.apps.${system}.qr;
|
||||
};
|
||||
}
|
||||
);
|
||||
}
|
||||
@@ -3,13 +3,14 @@
|
||||
"version": "1.0.0",
|
||||
"description": "HdM Stuttgart - Lecture Slides (Marp)",
|
||||
"scripts": {
|
||||
"dev:b": "PORT=1312 marp --server --allow-local-files courses/223015b/slides/",
|
||||
"dev:c": "PORT=1313 marp --server --allow-local-files courses/223015c/slides/",
|
||||
"dev": "PORT=3000 marp --server --allow-local-files slides/",
|
||||
"build": "make build",
|
||||
"build:b": "make build-b",
|
||||
"build:c": "make build-c",
|
||||
"pdf": "make pdf",
|
||||
"html": "make html",
|
||||
"klausur": "make klausur",
|
||||
"deploy": "make deploy",
|
||||
"test": "echo \"No tests specified\" && exit 0"
|
||||
},
|
||||
"keywords": ["marp", "slides", "hdm", "lectures"],
|
||||
|
||||
@@ -1,106 +1,53 @@
|
||||
#!/usr/bin/env bash
|
||||
# Development server script for HdM slides
|
||||
# Starts index server + marp servers for each course
|
||||
# Simplified development server for HdM slides
|
||||
# Starts single Marp server for all courses
|
||||
|
||||
set -e
|
||||
|
||||
# Configuration
|
||||
INDEX_PORT=1310
|
||||
COURSE_B_PORT=1311
|
||||
COURSE_C_PORT=1312
|
||||
COURSE_DIR="courses"
|
||||
DEV_INDEX_DIR=".dev-index"
|
||||
SLIDES_DIR="slides"
|
||||
DEV_PORT=3000
|
||||
|
||||
# Colors
|
||||
RED='\033[0;31m'
|
||||
GREEN='\033[0;32m'
|
||||
BLUE='\033[0;34m'
|
||||
RED='\033[0;31m'
|
||||
NC='\033[0m' # No Color
|
||||
|
||||
# Cleanup function
|
||||
cleanup() {
|
||||
echo -e "\n${RED}Shutting down servers...${NC}"
|
||||
kill $PID_INDEX $PID_B $PID_C 2>/dev/null || true
|
||||
echo -e "\n${RED}Shutting down dev server...${NC}"
|
||||
pkill -f "marp-cli.*--server" 2>/dev/null || true
|
||||
exit 0
|
||||
}
|
||||
|
||||
# Kill existing processes on our ports
|
||||
# Kill existing processes on our port
|
||||
kill_existing() {
|
||||
echo -e "${BLUE}Cleaning up existing processes...${NC}"
|
||||
# Kill marp processes first
|
||||
pkill -9 -f "marp-cli" 2>/dev/null || true
|
||||
pkill -f "python3 -m http.server" 2>/dev/null || true
|
||||
# Kill ports including marp's WebSocket ports (37717-37720 range)
|
||||
fuser -k $INDEX_PORT/tcp $COURSE_B_PORT/tcp $COURSE_C_PORT/tcp 2>/dev/null || true
|
||||
fuser -k 37717/tcp 37718/tcp 37719/tcp 37720/tcp 2>/dev/null || true
|
||||
sleep 2
|
||||
}
|
||||
|
||||
# Generate dev index
|
||||
generate_index() {
|
||||
mkdir -p "$DEV_INDEX_DIR"
|
||||
cat > "$DEV_INDEX_DIR/index.html" << 'EOF'
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width,initial-scale=1">
|
||||
<title>HdM Slides - Dev</title>
|
||||
<style>
|
||||
*{box-sizing:border-box;margin:0;padding:0}
|
||||
body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}
|
||||
h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}
|
||||
.subtitle{color:#86868b;font-size:1rem}
|
||||
.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}
|
||||
a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}
|
||||
a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}
|
||||
.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}
|
||||
.course-b .course-label{color:#1e5f8a}
|
||||
.course-c .course-label{color:#d63384}
|
||||
.course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}
|
||||
.course-info{font-size:.85rem;color:#86868b}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>HdM Slides</h1>
|
||||
<p class="subtitle">Development Server</p>
|
||||
<div class="courses">
|
||||
EOF
|
||||
echo " <a class=\"course course-b\" href=\"http://localhost:$COURSE_B_PORT\"><span class=\"course-label\">223015b</span><div class=\"course-title\">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class=\"course-info\">Port $COURSE_B_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
|
||||
echo " <a class=\"course course-c\" href=\"http://localhost:$COURSE_C_PORT\"><span class=\"course-label\">223015c</span><div class=\"course-title\">Grundlagen IT- und Internettechnik</div><span class=\"course-info\">Port $COURSE_C_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
|
||||
cat >> "$DEV_INDEX_DIR/index.html" << 'EOF'
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
EOF
|
||||
fuser -k $DEV_PORT/tcp 2>/dev/null || true
|
||||
sleep 1
|
||||
}
|
||||
|
||||
# Main
|
||||
trap cleanup SIGINT SIGTERM
|
||||
|
||||
kill_existing
|
||||
generate_index
|
||||
|
||||
echo -e "${GREEN}Starting development servers...${NC}"
|
||||
echo -e "${GREEN}Starting development server...${NC}"
|
||||
echo ""
|
||||
echo -e " Index: ${BLUE}http://localhost:$INDEX_PORT${NC}"
|
||||
echo -e " 223015b: ${BLUE}http://localhost:$COURSE_B_PORT${NC}"
|
||||
echo -e " 223015c: ${BLUE}http://localhost:$COURSE_C_PORT${NC}"
|
||||
echo -e " Server: ${BLUE}http://localhost:$DEV_PORT${NC}"
|
||||
echo -e " Slides: ${BLUE}$SLIDES_DIR/${NC}"
|
||||
echo ""
|
||||
echo -e "Press ${RED}Ctrl+C${NC} to stop all servers"
|
||||
echo -e "Available courses:"
|
||||
echo -e " 223015b: ${BLUE}http://localhost:$DEV_PORT/223015b/${NC}"
|
||||
echo -e " 223015c: ${BLUE}http://localhost:$DEV_PORT/223015c/${NC}"
|
||||
echo ""
|
||||
echo -e "Press ${RED}Ctrl+C${NC} to stop the server"
|
||||
echo ""
|
||||
|
||||
# Start servers
|
||||
python3 -m http.server $INDEX_PORT --directory "$DEV_INDEX_DIR" &
|
||||
PID_INDEX=$!
|
||||
# Start single Marp server for all slides
|
||||
PORT=$DEV_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/"
|
||||
|
||||
PORT=$COURSE_B_PORT npx @marp-team/marp-cli --server "$COURSE_DIR/223015b/slides/" &
|
||||
PID_B=$!
|
||||
|
||||
sleep 3 # Stagger starts to avoid WebSocket port collision
|
||||
|
||||
PORT=$COURSE_C_PORT npx @marp-team/marp-cli --server "$COURSE_DIR/223015c/slides/" &
|
||||
PID_C=$!
|
||||
|
||||
# Wait for any process to exit
|
||||
# Wait for 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["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
|
||||
TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
|
||||
TOPIC_MAP["klausurfragen"]="Klausurfragen"
|
||||
|
||||
# Configure which topics should appear disabled per course
|
||||
# Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)
|
||||
declare -A DISABLED_FULL
|
||||
declare -A DISABLED_BUTTONS
|
||||
# For course B: chapters 3,4,5 should be fully disabled
|
||||
DISABLED_FULL["223015b"]="speichermedien-schnittstellen distribution-apis-zukunft vertiefung-offene-fragen"
|
||||
# For course C: chapter 3 should keep link clickable but buttons disabled
|
||||
DISABLED_BUTTONS["223015c"]="interaktivitaet-javascript"
|
||||
|
||||
cat > "$BUILD_DIR/index.html" << HEADER
|
||||
<!DOCTYPE html>
|
||||
@@ -61,6 +71,15 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
line-height: 1.5;
|
||||
}
|
||||
header { margin-bottom: 2rem; }
|
||||
.breadcrumb {
|
||||
margin-bottom: 1rem;
|
||||
font-size: 0.85rem;
|
||||
}
|
||||
.breadcrumb a {
|
||||
color: #86868b;
|
||||
text-decoration: none;
|
||||
}
|
||||
.breadcrumb a:hover { text-decoration: underline; }
|
||||
h1 {
|
||||
font-size: 1.75rem;
|
||||
font-weight: 600;
|
||||
@@ -68,6 +87,12 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
margin-bottom: 0.5rem;
|
||||
color: $ACCENT_COLOR;
|
||||
}
|
||||
.course-heading {
|
||||
font-size: 1.25rem;
|
||||
font-weight: 500;
|
||||
color: #1d1d1f;
|
||||
margin-bottom: 0.25rem;
|
||||
}
|
||||
.subtitle {
|
||||
color: #86868b;
|
||||
font-size: 0.95rem;
|
||||
@@ -77,13 +102,14 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
font-size: 0.875rem;
|
||||
margin-top: 0.25rem;
|
||||
}
|
||||
/* Use the .termine wrapper and add a gap between cards */
|
||||
.termine {
|
||||
margin-top: 1.5rem;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
.termin-card {
|
||||
.kapitel-card {
|
||||
position: relative;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
@@ -93,32 +119,35 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
grid-template-columns: 1fr auto auto;
|
||||
align-items: center;
|
||||
gap: 1rem;
|
||||
padding: 0; /* inner padding handled by kapitel-link */
|
||||
}
|
||||
.termin-card:hover {
|
||||
.kapitel-card:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
|
||||
}
|
||||
.termin-link {
|
||||
.kapitel-link {
|
||||
display: block;
|
||||
padding: 1.25rem 1.5rem;
|
||||
text-decoration: none;
|
||||
color: inherit;
|
||||
grid-column: 1;
|
||||
}
|
||||
.termin-label {
|
||||
/* Disabled look: dim the entire card and prevent pointer events */
|
||||
.kapitel-card.disabled { opacity: 0.6; pointer-events: none; }
|
||||
.kapitel-label {
|
||||
font-size: 0.7rem;
|
||||
font-weight: 600;
|
||||
color: $ACCENT_COLOR;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
}
|
||||
.termin-title {
|
||||
.kapitel-title {
|
||||
font-size: 1.05rem;
|
||||
font-weight: 500;
|
||||
color: #1d1d1f;
|
||||
margin: 0.15rem 0;
|
||||
}
|
||||
.termin-date {
|
||||
.kapitel-date {
|
||||
font-size: 0.8rem;
|
||||
color: #86868b;
|
||||
}
|
||||
@@ -135,11 +164,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
white-space: nowrap;
|
||||
position: relative;
|
||||
z-index: 1;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.btn-slides {
|
||||
background: $ACCENT_COLOR;
|
||||
color: #fff;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.btn-slides:hover {
|
||||
filter: brightness(1.1);
|
||||
@@ -147,11 +176,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
.btn-pdf {
|
||||
background: #f5f5f7;
|
||||
color: #1d1d1f;
|
||||
margin-right: 1rem;
|
||||
}
|
||||
.btn-pdf:hover { background: #e8e8ed; }
|
||||
.btn-disabled { opacity: 0.6; pointer-events: none; }
|
||||
/* Make entire card clickable via overlay */
|
||||
.termin-link::after {
|
||||
.kapitel-link::after {
|
||||
content: '';
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
@@ -184,10 +213,10 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
color: #86868b;
|
||||
}
|
||||
@media (max-width: 600px) {
|
||||
.termin-card {
|
||||
.kapitel-card {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
.termin-link {
|
||||
.kapitel-link {
|
||||
padding-bottom: 0.75rem;
|
||||
}
|
||||
.btn-slides, .btn-pdf {
|
||||
@@ -198,63 +227,140 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<h1>$TITLE</h1>
|
||||
<p class="breadcrumb"><a href="../">← Kursübersicht</a></p>
|
||||
<h1>HdM Vorlesungen</h1>
|
||||
<h2 class="course-heading">$TITLE</h2>
|
||||
<p class="subtitle">$SUBTITLE</p>
|
||||
<p class="meta">HdM Stuttgart · Wintersemester 2025/26 · Michael Czechowski</p>
|
||||
<p class="meta">HdM Stuttgart · Sommersemester 2026 · Michael Czechowski</p>
|
||||
</header>
|
||||
<div class="termine">
|
||||
HEADER
|
||||
|
||||
# Generate links for each termin (sorted)
|
||||
for html in $(ls "$BUILD_DIR"/2*.html 2>/dev/null | sort); do
|
||||
# Generate links for each kapitel (sorted)
|
||||
for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
|
||||
filename=$(basename "$html")
|
||||
|
||||
# Extract components from filename
|
||||
date=$(echo "$filename" | grep -oE '^[0-9]{4}-[0-9x]{2}-[0-9x]{2}')
|
||||
termin_num=$(echo "$filename" | grep -oE 'termin-[0-9]+' | grep -oE '[0-9]+')
|
||||
topic_raw=$(echo "$filename" | sed -E 's/^[0-9]{4}-[0-9x]{2}-[0-9x]{2}-termin-[0-9]+-//' | sed 's/\.html$//')
|
||||
# Extract components from filename (format: NN-topic.html)
|
||||
kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
|
||||
topic_raw=$(echo "$filename" | sed -E 's/^[0-9]+-//' | sed 's/\.html$//')
|
||||
|
||||
# Look up nice topic name or fallback
|
||||
topic="${TOPIC_MAP[$topic_raw]}"
|
||||
if [[ -z "$topic" ]]; then
|
||||
topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\u&/')
|
||||
topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\\u&/')
|
||||
fi
|
||||
|
||||
# Format date
|
||||
if [[ "$date" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]] && [[ ! "$date" =~ xx ]]; then
|
||||
formatted_date=$(date -d "$date" "+%d. %B %Y" 2>/dev/null || echo "$date")
|
||||
# Handle kapitel number
|
||||
if [[ "$kapitel_num" == "0" ]] || [[ -z "$kapitel_num" ]]; then
|
||||
kapitel_label="Einführung"
|
||||
else
|
||||
formatted_date="Termin folgt"
|
||||
fi
|
||||
|
||||
# Handle termin number
|
||||
if [[ "$termin_num" == "0" ]]; then
|
||||
termin_label="Einführung"
|
||||
else
|
||||
termin_label="Termin $termin_num"
|
||||
kapitel_label="Kapitel $kapitel_num"
|
||||
fi
|
||||
|
||||
pdf_filename="${filename%.html}.pdf"
|
||||
|
||||
# Check if PDF exists
|
||||
# Determine whether this topic is configured as disabled for this course
|
||||
disabled_full=false
|
||||
disabled_buttons=false
|
||||
for t in ${DISABLED_FULL["$COURSE"]}; do
|
||||
if [[ "$topic_raw" == "$t" ]]; then
|
||||
disabled_full=true
|
||||
break
|
||||
fi
|
||||
done
|
||||
if [[ "$disabled_full" == false ]]; then
|
||||
for t in ${DISABLED_BUTTONS["$COURSE"]}; do
|
||||
if [[ "$topic_raw" == "$t" ]]; then
|
||||
disabled_buttons=true
|
||||
break
|
||||
fi
|
||||
done
|
||||
fi
|
||||
|
||||
# Decide card class
|
||||
card_class="kapitel-card"
|
||||
if [[ "$disabled_full" == true ]] || [[ "$disabled_buttons" == true ]]; then
|
||||
card_class="$card_class disabled"
|
||||
fi
|
||||
|
||||
# Build link/button HTML depending on disabled state
|
||||
if [[ "$disabled_full" == true ]]; then
|
||||
# non-interactive card (visually dimmed and not clickable)
|
||||
link_html="<div class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></div>"
|
||||
slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
|
||||
pdf_html=""
|
||||
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
|
||||
pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
|
||||
fi
|
||||
elif [[ "$disabled_buttons" == true ]]; then
|
||||
# link stays clickable, but buttons are disabled; card appears dimmed
|
||||
link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
|
||||
slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
|
||||
pdf_html=""
|
||||
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
|
||||
pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
|
||||
fi
|
||||
else
|
||||
# normal interactive card
|
||||
pdf_link=""
|
||||
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
|
||||
pdf_link="<a href=\"$pdf_filename\" class=\"btn btn-pdf\">PDF</a>"
|
||||
fi
|
||||
link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
|
||||
slides_html="<a href=\"$filename\" class=\"btn btn-slides\">Folien</a>"
|
||||
pdf_html="$pdf_link"
|
||||
fi
|
||||
|
||||
cat >> "$BUILD_DIR/index.html" << LINK
|
||||
<div class="termin-card">
|
||||
<a href="$filename" class="termin-link">
|
||||
<div class="termin-label">$termin_label</div>
|
||||
<div class="termin-title">$topic</div>
|
||||
<div class="termin-date">$formatted_date</div>
|
||||
</a>
|
||||
<a href="$filename" class="btn btn-slides">Folien</a>
|
||||
$pdf_link
|
||||
<div class="$card_class">
|
||||
$link_html
|
||||
$slides_html
|
||||
$pdf_html
|
||||
</div>
|
||||
LINK
|
||||
|
||||
done
|
||||
|
||||
# Add klausurfolien entry if it exists
|
||||
if [[ -f "$BUILD_DIR/klausurfolien.html" ]]; then
|
||||
pdf_link=""
|
||||
if [[ -f "$BUILD_DIR/klausurfolien.pdf" ]]; then
|
||||
pdf_link="<a href=\"klausurfolien.pdf\" class=\"btn btn-pdf\">PDF</a>"
|
||||
fi
|
||||
cat >> "$BUILD_DIR/index.html" << KLAUSUR
|
||||
<div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
|
||||
<a href="klausurfolien.html" class="kapitel-link">
|
||||
<div class="kapitel-label">Prüfung</div>
|
||||
<div class="kapitel-title">Klausurrelevante Folien</div>
|
||||
</a>
|
||||
<a href="klausurfolien.html" class="btn btn-slides">Folien</a>
|
||||
$pdf_link
|
||||
</div>
|
||||
KLAUSUR
|
||||
fi
|
||||
|
||||
# Add klausurfragen entry if it exists (HTML and/or PDF)
|
||||
if [[ -f "$BUILD_DIR/klausurfragen.html" ]] || [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
|
||||
pdf_link=""
|
||||
if [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
|
||||
pdf_link="<a href=\"klausurfragen.pdf\" class=\"btn btn-pdf\">PDF</a>"
|
||||
fi
|
||||
slides_link=""
|
||||
if [[ -f "$BUILD_DIR/klausurfragen.html" ]]; then
|
||||
slides_link="<a href=\"klausurfragen.html\" class=\"btn btn-slides\">Folien</a>"
|
||||
fi
|
||||
cat >> "$BUILD_DIR/index.html" << KLAUSURFRAGEN
|
||||
<div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
|
||||
<a href="klausurfragen.html" class="kapitel-link">
|
||||
<div class="kapitel-label">Prüfung</div>
|
||||
<div class="kapitel-title">Klausurfragen</div>
|
||||
</a>
|
||||
$slides_link
|
||||
$pdf_link
|
||||
</div>
|
||||
KLAUSURFRAGEN
|
||||
fi
|
||||
|
||||
cat >> "$BUILD_DIR/index.html" << FOOTER
|
||||
</div>
|
||||
<div class="qr-section">
|
||||
@@ -263,7 +369,7 @@ cat >> "$BUILD_DIR/index.html" << FOOTER
|
||||
</div>
|
||||
<footer>
|
||||
<a href="mailto:mail@librete.ch">Kontakt</a> ·
|
||||
<a href="../">Alle Kurse</a>
|
||||
<a href="../">Kursübersicht</a>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@@ -0,0 +1,187 @@
|
||||
#!/usr/bin/env bash
|
||||
# Generate root index.html for /hdm/
|
||||
# Lists all courses (klausurfragen are now per-course)
|
||||
|
||||
BUILD_DIR="build"
|
||||
|
||||
cat > "$BUILD_DIR/index.html" << 'HEADER'
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>HdM Vorlesungen</title>
|
||||
<style>
|
||||
* { box-sizing: border-box; margin: 0; padding: 0; }
|
||||
body {
|
||||
font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Segoe UI", Roboto, sans-serif;
|
||||
max-width: 720px;
|
||||
margin: 0 auto;
|
||||
padding: 3rem 1.5rem;
|
||||
background: #fafafa;
|
||||
color: #1d1d1f;
|
||||
line-height: 1.5;
|
||||
}
|
||||
h1 {
|
||||
font-size: 2rem;
|
||||
font-weight: 600;
|
||||
letter-spacing: -0.02em;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
.subtitle { color: #86868b; font-size: 1rem; }
|
||||
.courses {
|
||||
margin-top: 2rem;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
.course-card {
|
||||
position: relative;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
|
||||
transition: all 0.2s ease;
|
||||
display: grid;
|
||||
grid-template-columns: 1fr auto auto;
|
||||
align-items: center;
|
||||
gap: 1rem;
|
||||
}
|
||||
.course-card:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
|
||||
}
|
||||
.course-link {
|
||||
display: block;
|
||||
padding: 1.25rem 1.5rem;
|
||||
text-decoration: none;
|
||||
color: inherit;
|
||||
grid-column: 1;
|
||||
}
|
||||
.course-link::after {
|
||||
content: '';
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
border-radius: 12px;
|
||||
}
|
||||
.course-label {
|
||||
font-size: 0.7rem;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
}
|
||||
.course-b .course-label { color: #1e5f8a; }
|
||||
.course-c .course-label { color: #d63384; }
|
||||
.course-title {
|
||||
font-size: 1.15rem;
|
||||
font-weight: 500;
|
||||
color: #1d1d1f;
|
||||
margin: 0.25rem 0;
|
||||
}
|
||||
.course-info { font-size: 0.85rem; color: #86868b; }
|
||||
.btn {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
padding: 0.5rem 1rem;
|
||||
border-radius: 8px;
|
||||
text-decoration: none;
|
||||
font-size: 0.8rem;
|
||||
font-weight: 500;
|
||||
transition: all 0.2s;
|
||||
white-space: nowrap;
|
||||
position: relative;
|
||||
z-index: 1;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.btn-slides {
|
||||
background: #6c757d;
|
||||
color: #fff;
|
||||
}
|
||||
.btn-slides:hover { filter: brightness(1.1); }
|
||||
.btn-pdf {
|
||||
background: #f5f5f7;
|
||||
color: #1d1d1f;
|
||||
}
|
||||
.btn-pdf:hover { background: #e8e8ed; }
|
||||
.section-title {
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: #86868b;
|
||||
margin-top: 2.5rem;
|
||||
margin-bottom: 0.75rem;
|
||||
}
|
||||
.references {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
footer {
|
||||
margin-top: 2.5rem;
|
||||
padding-top: 1.5rem;
|
||||
border-top: 1px solid #e5e5e7;
|
||||
color: #86868b;
|
||||
font-size: 0.85rem;
|
||||
}
|
||||
footer a { color: #1d1d1f; text-decoration: none; }
|
||||
footer a:hover { text-decoration: underline; }
|
||||
.qr-section {
|
||||
margin-top: 2.5rem;
|
||||
padding: 1.5rem;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
|
||||
text-align: center;
|
||||
}
|
||||
.qr-code { width: 100%; height: auto; }
|
||||
.qr-url { margin-top: 0.75rem; font-size: 0.85rem; color: #86868b; }
|
||||
@media (max-width: 600px) {
|
||||
.course-card { grid-template-columns: 1fr; }
|
||||
.course-link { padding-bottom: 0.75rem; }
|
||||
.btn { margin: 0 1rem 1rem 1.5rem; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>HdM Vorlesungen</h1>
|
||||
<p class="subtitle">Sommersemester 2026 · Michael Czechowski</p>
|
||||
<div class="courses">
|
||||
<div class="course-card course-b">
|
||||
<a href="223015b/" class="course-link">
|
||||
<span class="course-label">223015b</span>
|
||||
<div class="course-title">Dateiformate, Schnittstellen, Speichermedien & 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"
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -59,8 +59,7 @@ section.klausur {
|
||||
}
|
||||
@media print {
|
||||
section.klausur {
|
||||
background: url('./assets/klausur-pattern.svg') !important;
|
||||
background-size: cover !important;
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
@@ -83,7 +82,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
@@ -110,7 +109,7 @@ Hochschule der Medien Stuttgart
|
||||
- Hintergrund:
|
||||
- Philosophie (Uni Stuttgart) -> NO degree
|
||||
- Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
|
||||
- Kontakt: mail@librete.ch
|
||||
- Kontakt: lb-czechowski@hdm-stuttgart.de
|
||||
|
||||
<!--
|
||||
Kurze Vorstellung
|
||||
@@ -0,0 +1,860 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
<style>
|
||||
:root {
|
||||
--color-foreground: #1a1a2e;
|
||||
--color-highlight: #1e5f8a;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert {
|
||||
--color-foreground: #fff;
|
||||
}
|
||||
section {
|
||||
font-size: 1.7rem;
|
||||
}
|
||||
h1 {
|
||||
color: #1e5f8a;
|
||||
}
|
||||
section.invert h1 {
|
||||
color: #fff;
|
||||
}
|
||||
h2 {
|
||||
color: #1f2937;
|
||||
}
|
||||
pre {
|
||||
background: #0f0f23;
|
||||
color: #5fb3e4;
|
||||
border-radius: 8px;
|
||||
border-left: 3px solid #1e5f8a;
|
||||
}
|
||||
pre code {
|
||||
background: transparent;
|
||||
color: inherit;
|
||||
}
|
||||
code {
|
||||
background: #1a1a2e;
|
||||
color: #5fb3e4;
|
||||
padding: 0.15em 0.4em;
|
||||
border-radius: 4px;
|
||||
}
|
||||
a {
|
||||
color: var(--color-highlight);
|
||||
}
|
||||
section.klausur {
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#e3f2fd,
|
||||
#e3f2fd 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.klausur {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#e3f2fd,
|
||||
#e3f2fd 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #1e5f8a;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||

|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015b** · Modul "Technik 1" · 1. Semester
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
---
|
||||
|
||||
<!-- _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: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HDD vs. SSD – Vertiefung
|
||||
|
||||
**HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor).
|
||||
|
||||
**SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles).
|
||||
|
||||
| Aspekt | HDD | SATA SSD | NVMe SSD |
|
||||
|--------|-----|----------|----------|
|
||||
| Latenz | 5–10 ms | 0,1 ms | 0,02 ms |
|
||||
| Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s |
|
||||
| IOPS (4K random) | 100 | 90.000 | 1.000.000 |
|
||||
| TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW |
|
||||
|
||||
**Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke.
|
||||
|
||||
**Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Dateisysteme
|
||||
## Die Organisation der Daten
|
||||
|
||||
---
|
||||
|
||||
# Was macht ein Dateisystem?
|
||||
|
||||
**Aufgaben:**
|
||||
- Dateien in Blöcke aufteilen
|
||||
- Speicherort verwalten (Allokation)
|
||||
- Verzeichnisstruktur pflegen
|
||||
- Metadaten speichern (Name, Datum, Rechte)
|
||||
- Integrität sichern (Journaling)
|
||||
|
||||
**Ohne Dateisystem:**
|
||||
Nur eine Folge von Bytes ohne Struktur.
|
||||
|
||||
<!--
|
||||
Das Dateisystem ist die Abstraktionsschicht
|
||||
zwischen Anwendungen und rohem Speicher.
|
||||
|
||||
Es entscheidet:
|
||||
- Wie Dateien gefunden werden
|
||||
- Wie freier Speicher verwaltet wird
|
||||
- Was bei Abstürzen passiert
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# FAT32: Der Kompatibilitätskönig
|
||||
|
||||
**File Allocation Table, 32-bit (1996)**
|
||||
|
||||
**Vorteile:**
|
||||
- Überall lesbar (Windows, Mac, Linux, Kameras, Fernseher...)
|
||||
- Einfach, robust
|
||||
|
||||
**Nachteile:**
|
||||
- Max. 4 GB pro Datei
|
||||
- Max. 2 TB pro Volume
|
||||
- Keine Berechtigungen
|
||||
- Kein Journaling
|
||||
|
||||
**Ideal für:** USB-Sticks, SD-Karten (Kompatibilität)
|
||||
|
||||
<!--
|
||||
4 GB Limit ist das Hauptproblem.
|
||||
Ein 4K-Video oder ISO-Image passt oft nicht drauf.
|
||||
|
||||
Trotzdem: FAT32 ist der kleinste gemeinsame Nenner.
|
||||
Wenn Kompatibilität wichtiger ist als Features → FAT32.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# exFAT: FAT32 ohne Limits
|
||||
|
||||
**Extended FAT (2006, Microsoft)**
|
||||
|
||||
**Vorteile:**
|
||||
- Keine praktischen Dateigrößen-Limits
|
||||
- Breite Unterstützung (seit 2019 auch Linux-Kernel)
|
||||
- Für Flash-Speicher optimiert
|
||||
|
||||
**Nachteile:**
|
||||
- Kein Journaling
|
||||
- Weniger robust als NTFS/APFS/ext4
|
||||
|
||||
**Ideal für:** Große Dateien auf portablen Medien
|
||||
|
||||
<!--
|
||||
exFAT ist der Nachfolger von FAT32 für portable Medien.
|
||||
SD-Karten über 32 GB sind standardmäßig exFAT.
|
||||
|
||||
Microsoft hat 2019 die Patente freigegeben.
|
||||
Seitdem native Linux-Unterstützung.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# NTFS: Windows-Standard
|
||||
|
||||
**New Technology File System (1993)**
|
||||
|
||||
**Features:**
|
||||
- Journaling (Crash-Sicherheit)
|
||||
- Dateirechte (ACLs)
|
||||
- Kompression, Verschlüsselung
|
||||
- Große Dateien und Volumes
|
||||
|
||||
**Nachteile:**
|
||||
- Nur Windows schreibt nativ
|
||||
- macOS: Nur lesen
|
||||
- Linux: Über ntfs-3g (langsamer)
|
||||
|
||||
<!--
|
||||
NTFS ist seit Windows NT der Standard.
|
||||
Alle modernen Windows-Versionen nutzen es.
|
||||
|
||||
Für Windows-only-Systeme die beste Wahl.
|
||||
Für portable Medien: Kompatibilitätsprobleme.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# APFS: Apple-Modern
|
||||
|
||||
**Apple File System (2017)**
|
||||
|
||||
**Features:**
|
||||
- Snapshots (Zeitpunkt-Kopien)
|
||||
- Copy-on-Write (CoW)
|
||||
- Native Verschlüsselung
|
||||
- Optimiert für SSDs
|
||||
|
||||
**Nachteile:**
|
||||
- Nur Apple-Geräte
|
||||
- Nicht abwärtskompatibel mit HFS+
|
||||
|
||||
<!--
|
||||
APFS ersetzte HFS+ auf allen Apple-Geräten.
|
||||
Snapshots ermöglichen Time Machine und APFS-Klone.
|
||||
|
||||
Copy-on-Write: Daten werden nicht überschrieben,
|
||||
sondern neue Versionen werden geschrieben.
|
||||
Gut für Integrität und Snapshots.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# ext4: Linux-Standard
|
||||
|
||||
**Fourth Extended File System (2008)**
|
||||
|
||||
**Features:**
|
||||
- Journaling
|
||||
- Extents (effiziente große Dateien)
|
||||
- Online-Defragmentierung
|
||||
- Bewährt und stabil
|
||||
|
||||
**Nachteile:**
|
||||
- Windows/macOS können nicht nativ lesen
|
||||
- Weniger Features als btrfs/ZFS
|
||||
|
||||
<!--
|
||||
ext4 ist der Standard für Linux-Systeme.
|
||||
Evolution: ext (1992) → ext2 → ext3 → ext4
|
||||
|
||||
Alternativen: btrfs (Snapshots, CoW), XFS, ZFS
|
||||
Für Server oft XFS oder ZFS.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Dateisysteme: Übersicht
|
||||
|
||||
| FS | Max. Datei | Journaling | Ideal für |
|
||||
|----|----------:|:----------:|-----------|
|
||||
| FAT32 | 4 GB | ❌ | Kompatibilität |
|
||||
| exFAT | 16 EB | ❌ | Große portable Dateien |
|
||||
| NTFS | 16 EB | ✓ | Windows |
|
||||
| APFS | 8 EB | ✓ | macOS, iOS |
|
||||
| ext4 | 16 TB | ✓ | Linux |
|
||||
|
||||
<!--
|
||||
Die Wahl hängt vom Kontext ab.
|
||||
|
||||
Portable Medien: FAT32 oder exFAT
|
||||
Interne Laufwerke: NTFS, APFS, ext4 je nach OS
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Backup & Archivierung
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
Symbolbild: Kaputte Festplatte oder Ransomware
|
||||
Das Worst-Case-Szenario
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Warum Backup?
|
||||
|
||||
**Realitäten:**
|
||||
- HDDs haben 1-2% jährliche Ausfallrate
|
||||
- SSDs können ohne Vorwarnung sterben
|
||||
- Ransomware verschlüsselt Daten
|
||||
- Versehentliches Löschen passiert
|
||||
- Diebstahl, Brand, Wasserschaden
|
||||
|
||||
**Die Frage ist nicht ob, sondern wann.**
|
||||
|
||||
<!--
|
||||
Backblaze veröffentlicht jährliche HDD-Statistiken.
|
||||
1-2% Ausfallrate klingt wenig, aber bei 100 Platten...
|
||||
|
||||
Pixar verlor fast "Toy Story 2" (1998).
|
||||
Rettung: Eine Mitarbeiterin hatte ein Home-Backup.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #e3f2fd -->
|
||||
|
||||
# Die 3-2-1-Regel
|
||||
|
||||
**3** Kopien eurer Daten
|
||||
(Original + 2 Backups)
|
||||
|
||||
**2** verschiedene Medientypen
|
||||
(z.B. SSD + HDD, oder lokal + Cloud)
|
||||
|
||||
**1** Kopie an anderem Ort
|
||||
(Offsite: Cloud, anderes Gebäude)
|
||||
|
||||
<!--
|
||||
Herkunft: Peter Krogh, "The DAM Book" (2005)
|
||||
|
||||
Warum 3 Kopien?
|
||||
- Original kann kaputt gehen
|
||||
- Backup 1 auch
|
||||
- Backup 2 = Sicherheitspuffer
|
||||
|
||||
Warum 2 Medientypen?
|
||||
- Gleiche Medien haben gleiche Schwachstellen
|
||||
- Batch-Fehler bei HDDs derselben Charge
|
||||
|
||||
Warum 1 Offsite?
|
||||
- Brand/Wasserschaden zerstört alles vor Ort
|
||||
- Ransomware verschlüsselt angeschlossene Laufwerke
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 3-2-1-Backup-Regel – Vertiefung
|
||||
|
||||
Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien:
|
||||
|
||||
| Bedrohung | Schutz durch | Beispiel |
|
||||
|-----------|--------------|----------|
|
||||
| Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden |
|
||||
| Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System |
|
||||
| Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher |
|
||||
|
||||
**Moderne Erweiterung 3-2-1-1-0:**
|
||||
- **+1** Air-Gapped (offline, nicht verbunden)
|
||||
- **+0** Verifizierte Backups (regelmäßig Restore testen)
|
||||
|
||||
**Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind.
|
||||
|
||||
**Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots.
|
||||
|
||||
---
|
||||
|
||||
# Backup-Arten
|
||||
|
||||
**Vollständig (Full):**
|
||||
Kompletter Datenbestand jedes Mal.
|
||||
Einfach, aber langsam und platzhungrig.
|
||||
|
||||
**Inkrementell:**
|
||||
Nur Änderungen seit dem letzten Backup.
|
||||
Schnell, aber Wiederherstellung komplex (Kette).
|
||||
|
||||
**Differenziell:**
|
||||
Änderungen seit dem letzten Voll-Backup.
|
||||
Mittelweg zwischen beiden.
|
||||
|
||||
<!--
|
||||
Typisches Schema:
|
||||
- Sonntag: Voll-Backup
|
||||
- Mo-Sa: Inkrementell oder Differenziell
|
||||
|
||||
Inkrementell: Schnellstes Backup, langsamste Wiederherstellung
|
||||
Differenziell: Kompromiss
|
||||
Voll: Langsamstes Backup, schnellste Wiederherstellung
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Backup in der Praxis
|
||||
|
||||
**macOS:** Time Machine
|
||||
**Windows:** Veeam Agent (kostenlos), Windows Backup
|
||||
**Linux:** rsync, Borg, Restic
|
||||
**Cloud:** Backblaze, iCloud, Google Drive
|
||||
|
||||
**Wichtig:**
|
||||
- Automatisieren (manuell wird vergessen)
|
||||
- Regelmäßig testen (Backup nützt nichts, wenn Restore nicht funktioniert)
|
||||
|
||||
<!--
|
||||
Time Machine: Stündliche Snapshots, APFS-Integration
|
||||
Veeam: Enterprise-Level, kostenlose Endnutzer-Version
|
||||
rsync: Unix-Klassiker, extrem effizient
|
||||
Borg: Deduplizierung + Verschlüsselung
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Langzeitarchivierung
|
||||
|
||||
**Probleme:**
|
||||
- Bit Rot (Daten degradieren)
|
||||
- Format-Obsoleszenz (wer öffnet .wpd?)
|
||||
- Hardware-Obsoleszenz (Diskettenlaufwerk?)
|
||||
|
||||
**Lösungen:**
|
||||
- Migration alle 5-10 Jahre auf neue Medien
|
||||
- Offene Standards (PDF/A, TIFF, Plain Text)
|
||||
- Redundante Kopien
|
||||
|
||||
<!--
|
||||
WordPerfect dominierte die 1980er/90er.
|
||||
Heute kann kaum jemand .wpd-Dateien öffnen.
|
||||
|
||||
Flash-Dateien (.swf) sind seit 2020 praktisch tot.
|
||||
Millionen von Websites und Spielen verloren.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Archivmedien
|
||||
|
||||
**LTO-Tapes:**
|
||||
- 18 TB pro Band (LTO-9)
|
||||
- ~5€/TB
|
||||
- 30 Jahre Haltbarkeit
|
||||
- Für Cold Storage ideal
|
||||
|
||||
**M-DISC:**
|
||||
- Spezielle DVD/Blu-ray
|
||||
- 1.000+ Jahre Haltbarkeit (Herstellerangabe)
|
||||
- Für kleine, wichtige Daten
|
||||
|
||||
**Cloud:**
|
||||
- Glacier, Backblaze B2
|
||||
- Günstig für Langzeit
|
||||
|
||||
<!--
|
||||
LTO = Linear Tape-Open
|
||||
AWS, Google, Netflix nutzen Tape für Archive.
|
||||
|
||||
M-DISC nutzt anorganische Schicht statt Dye.
|
||||
Theoretisch sehr langlebig, praktisch ungetestet.
|
||||
|
||||
Cloud-Archive haben laufende Kosten.
|
||||
Aber: Keine Hardware-Wartung.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Schnittstellen
|
||||
|
||||
---
|
||||
|
||||
# USB: Die Universal-Schnittstelle
|
||||
|
||||
| Version | Jahr | Geschwindigkeit |
|
||||
|---------|------|----------------:|
|
||||
| USB 1.1 | 1998 | 12 Mbit/s |
|
||||
| USB 2.0 | 2000 | 480 Mbit/s (~60 MB/s) |
|
||||
| USB 3.0 | 2008 | 5 Gbit/s (~625 MB/s) |
|
||||
| USB 3.1 Gen 2 | 2013 | 10 Gbit/s |
|
||||
| USB 3.2 Gen 2×2 | 2017 | 20 Gbit/s |
|
||||
| USB4 | 2019 | 40 Gbit/s |
|
||||
|
||||
<!--
|
||||
USB = Universal Serial Bus
|
||||
|
||||
Die Namensgebung ist ein Chaos.
|
||||
USB 3.0 wurde nachträglich zu "USB 3.1 Gen 1" umbenannt.
|
||||
Dann zu "USB 3.2 Gen 1".
|
||||
|
||||
Die Industrie verwirrt absichtlich.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# USB-C: Der Stecker, nicht die Geschwindigkeit
|
||||
|
||||
**USB-C ist ein Steckertyp, kein Protokoll!**
|
||||
|
||||
Ein USB-C-Kabel kann sein:
|
||||
- USB 2.0 (480 Mbit/s)
|
||||
- USB 3.2 (bis 20 Gbit/s)
|
||||
- USB4 (40 Gbit/s)
|
||||
- Thunderbolt 3/4 (40 Gbit/s)
|
||||
|
||||
**Am Stecker nicht erkennbar.**
|
||||
→ Kabel-Spezifikation prüfen!
|
||||
|
||||
<!--
|
||||
Das ist eine häufige Quelle für Frustration.
|
||||
|
||||
"Ich habe ein USB-C-Kabel, warum ist es so langsam?"
|
||||
Weil es ein USB 2.0-Kabel mit USB-C-Stecker ist.
|
||||
|
||||
Gute Kabel sind teurer, aber es lohnt sich.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Thunderbolt
|
||||
|
||||
**Thunderbolt 3/4 (2015/2020):**
|
||||
- 40 Gbit/s
|
||||
- PCIe über Kabel (externe GPUs möglich)
|
||||
- DisplayPort integriert
|
||||
- USB-C-Stecker
|
||||
|
||||
**Vorteile:**
|
||||
- Sehr schnell
|
||||
- Vielseitig (Daten, Video, Strom)
|
||||
|
||||
**Nachteile:**
|
||||
- Teure Kabel
|
||||
- Nicht alle USB-C-Ports sind Thunderbolt
|
||||
|
||||
<!--
|
||||
Intel und Apple entwickelten Thunderbolt gemeinsam.
|
||||
Lizenzfrei seit 2019.
|
||||
|
||||
Thunderbolt-Kabel haben oft ein Blitz-Symbol.
|
||||
Aber nicht immer.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Video-Schnittstellen
|
||||
|
||||
| Schnittstelle | Max. Auflösung | Features |
|
||||
|---------------|---------------:|----------|
|
||||
| HDMI 2.0 | 4K/60Hz | ARC, CEC |
|
||||
| HDMI 2.1 | 8K/60Hz, 4K/120Hz | VRR, eARC |
|
||||
| DisplayPort 1.4 | 8K/60Hz | Daisy-Chain |
|
||||
| DisplayPort 2.0 | 16K/60Hz | Mehr Bandbreite |
|
||||
|
||||
**HDMI:** Consumer-Geräte (TV, Konsolen)
|
||||
**DisplayPort:** Computer, Monitore
|
||||
|
||||
<!--
|
||||
HDMI hat Lizenzgebühren, DisplayPort nicht.
|
||||
Deshalb ist DP bei Monitoren beliebter.
|
||||
|
||||
DisplayPort kann Daisy-Chaining:
|
||||
Laptop → Monitor 1 → Monitor 2 über ein Kabel.
|
||||
|
||||
HDMI hat ARC (Audio Return Channel):
|
||||
TV schickt Audio an Soundbar über HDMI.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Netzwerk
|
||||
|
||||
**Ethernet:**
|
||||
| Standard | Geschwindigkeit |
|
||||
|----------|----------------:|
|
||||
| Fast Ethernet | 100 Mbit/s |
|
||||
| Gigabit | 1 Gbit/s |
|
||||
| 2.5 Gigabit | 2,5 Gbit/s |
|
||||
| 10 Gigabit | 10 Gbit/s |
|
||||
|
||||
**WiFi:**
|
||||
| Generation | Standard | Geschwindigkeit |
|
||||
|------------|----------|----------------:|
|
||||
| WiFi 5 | 802.11ac | ~1,3 Gbit/s |
|
||||
| WiFi 6 | 802.11ax | ~9,6 Gbit/s |
|
||||
| WiFi 7 | 802.11be | ~46 Gbit/s |
|
||||
|
||||
<!--
|
||||
Gigabit-Ethernet ist heute Standard.
|
||||
2,5G und 10G verbreiten sich für NAS und Poweruser.
|
||||
|
||||
WiFi-Geschwindigkeiten sind theoretische Maxima.
|
||||
Real: Bruchteil davon, abhängig von Entfernung und Störungen.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Welche Schnittstelle für was?
|
||||
|
||||
| Anwendung | Empfehlung |
|
||||
|-----------|------------|
|
||||
| Externe SSD | USB 3.2 Gen 2 oder Thunderbolt |
|
||||
| USB-Stick | USB 3.0 reicht |
|
||||
| Monitor | DisplayPort oder HDMI 2.0+ |
|
||||
| NAS im Heimnetz | Gigabit Ethernet |
|
||||
| Backup-Platte | USB 3.0 |
|
||||
| Video-Editing extern | Thunderbolt |
|
||||
|
||||
<!--
|
||||
Die Schnittstelle muss zum Gerät passen.
|
||||
|
||||
Externe HDD über Thunderbolt?
|
||||
Bringt nichts, die HDD ist der Flaschenhals.
|
||||
|
||||
NVMe-SSD über USB 2.0?
|
||||
Verschwendung, USB ist der Flaschenhals.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: aufgabe -->
|
||||
|
||||
# Hands-On: Eigene Speicher analysieren
|
||||
|
||||
**Aufgabe (30 Min):**
|
||||
|
||||
1. Welche Laufwerke habt ihr? (SSD, HDD, extern)
|
||||
2. Welches Dateisystem nutzt ihr?
|
||||
3. Wie ist eure Backup-Situation?
|
||||
4. Welche Schnittstellen nutzt ihr?
|
||||
|
||||
**Tools:**
|
||||
- Windows: Datenträgerverwaltung
|
||||
- macOS: Festplattendienstprogramm
|
||||
- Linux: `lsblk`, `df -h`
|
||||
|
||||
<!--
|
||||
Ziel: Bewusstsein für eigene Infrastruktur.
|
||||
|
||||
Die meisten wissen nicht, welches Dateisystem
|
||||
auf ihrem USB-Stick ist.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||||
**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/)
|
||||
|
||||
---
|
||||
|
||||
# Lizenz & Attribution
|
||||
|
||||
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
|
||||
|
||||
- Erlaubt Teilen & Anpassen mit Namensnennung
|
||||
- Adaptionen müssen unter gleicher Lizenz geteilt werden
|
||||
|
||||
Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -59,8 +59,7 @@ section.klausur {
|
||||
}
|
||||
@media print {
|
||||
section.klausur {
|
||||
background: url('./assets/klausur-pattern.svg') !important;
|
||||
background-size: cover !important;
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
@@ -84,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
@@ -99,7 +98,7 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 4 – 30.01.2026
|
||||
# Kapitel 4 – 30.01.2026
|
||||
## Distribution, APIs & Zukunft
|
||||
|
||||
---
|
||||
@@ -1267,7 +1266,7 @@ Dangerzone: FOSS-Tool (Freedom of Press Foundation)
|
||||
**Offene Formate:**
|
||||
✓ Spezifikation öffentlich
|
||||
✓ Keine Lizenzgebühren
|
||||
✓ Viele Programme unterstützen
|
||||
✓ Viele Programme unterstützen1
|
||||
**Beispiele:** PNG, OGG, MKV, Markdown, SVG
|
||||
|
||||
**Proprietäre Formate:**
|
||||
@@ -1282,7 +1281,7 @@ Lock-in: "Gefangene Daten" (nur in Software X öffenbar)
|
||||
Firma geht pleite → Format stirbt (WordPerfect-Beispiel)
|
||||
Offene Standards: Überlebensfähiger (Community kann implementieren)
|
||||
-->
|
||||
|
||||
111
|
||||
---
|
||||
|
||||
# Vendor Lock-in: Beispiele
|
||||
@@ -1854,7 +1853,7 @@ Evaluation: Feedback ernst nehmen, Kurs verbessern
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||||
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
||||
|
||||
---
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -59,8 +59,7 @@ section.klausur {
|
||||
}
|
||||
@media print {
|
||||
section.klausur {
|
||||
background: url('./assets/klausur-pattern.svg') !important;
|
||||
background-size: cover !important;
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
@@ -84,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
@@ -99,7 +98,7 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 5 – TBA
|
||||
# Kapitel 5 – TBA
|
||||
## Vertiefung & Offene Fragen
|
||||
|
||||
---
|
||||
@@ -125,7 +124,7 @@ Themen nach Interesse der Studierenden
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||||
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
||||
|
||||
---
|
||||
|
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: 161 KiB |
|
After Width: | Height: | Size: 112 KiB |
|
After Width: | Height: | Size: 97 KiB |
|
After Width: | Height: | Size: 465 KiB |
|
After Width: | Height: | Size: 29 KiB |
@@ -0,0 +1,619 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
<style>
|
||||
:root {
|
||||
--color-foreground: #1a1a2e;
|
||||
--color-highlight: #1e5f8a;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert {
|
||||
--color-foreground: #fff;
|
||||
}
|
||||
section {
|
||||
font-size: 1.7rem;
|
||||
}
|
||||
h1 {
|
||||
color: #1e5f8a;
|
||||
}
|
||||
section.invert h1 {
|
||||
color: #fff;
|
||||
}
|
||||
h2 {
|
||||
color: #1f2937;
|
||||
}
|
||||
pre {
|
||||
background: #0f0f23;
|
||||
color: #5fb3e4;
|
||||
border-radius: 8px;
|
||||
border-left: 3px solid #1e5f8a;
|
||||
}
|
||||
pre code {
|
||||
background: transparent;
|
||||
color: inherit;
|
||||
}
|
||||
code {
|
||||
background: #1a1a2e;
|
||||
color: #5fb3e4;
|
||||
padding: 0.15em 0.4em;
|
||||
border-radius: 4px;
|
||||
}
|
||||
a {
|
||||
color: var(--color-highlight);
|
||||
}
|
||||
section.klausur {
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#e3f2fd,
|
||||
#e3f2fd 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.klausur {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!--
|
||||
╔═══════════════════════════════════════════════════════════════════╗
|
||||
║ AUTO-GENERATED FILE - DO NOT EDIT MANUALLY ║
|
||||
║ ║
|
||||
║ This file is generated by: make klausur ║
|
||||
║ Source: scripts/extract-klausur.sh ║
|
||||
║ ║
|
||||
║ To update, edit the source slides and re-run make klausur ║
|
||||
╚═══════════════════════════════════════════════════════════════════╝
|
||||
-->
|
||||
|
||||
<!-- _class: invert -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||

|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015b** · Modul "Technik 1" · 1. Semester
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Verlustfrei vs. Verlustbehaftet
|
||||
|
||||
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||||
|---|---|---|
|
||||
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
|
||||
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
|
||||
| **Reduktion** | 30-50% | 80-99% |
|
||||
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
|
||||
|
||||
**Faustregel:**
|
||||
- Medien für Endnutzer → Lossy oft akzeptabel
|
||||
- Quellmaterial, Code, Archive → Lossless nötig
|
||||
|
||||
<!--
|
||||
REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
|
||||
IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
|
||||
|
||||
KLAUSURRELEVANT:
|
||||
- Verlustfrei = Original 1:1 wiederherstellbar
|
||||
- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
|
||||
- Redundanz vs. Irrelevanz ist der Kernunterschied!
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Dateneinheiten
|
||||
|
||||
| Einheit | Bytes | Potenz | Beispiel |
|
||||
|---------|------:|:------:|----------|
|
||||
| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
|
||||
| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
|
||||
| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
|
||||
| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
|
||||
| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
|
||||
| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
|
||||
| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
|
||||
| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
|
||||
|
||||
<!--
|
||||
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
|
||||
Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
|
||||
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
|
||||
1 TB Festplatte = ~931 GiB nutzbar
|
||||
|
||||
Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
|
||||
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Der digitale Wendepunkt
|
||||
|
||||
| Jahr | Analog | Digital | Digital-Anteil |
|
||||
|------|--------|---------|----------------|
|
||||
| **1986** | 2,6 EB | 0,02 EB | **1%** |
|
||||
| **2002** | — | — | **50%** (Wendepunkt) |
|
||||
| **2007** | 18 EB | 277 EB | **94%** |
|
||||
|
||||
**Perspektive:**
|
||||
- 1986: "Petabyte" war ein theoretisches Konzept
|
||||
- 2025: ~181 Zettabyte jährlich produziert
|
||||
|
||||
**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
|
||||
(AWS Glacier, Film-Archive, Rechenzentren)
|
||||
|
||||
<!--
|
||||
PRÜFUNGSRELEVANT:
|
||||
- Wendepunkt 2002
|
||||
- Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
|
||||
- Magnetband als Archivmedium
|
||||
|
||||
QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
|
||||
|
||||
METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
|
||||
|
||||
WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
|
||||
|
||||
ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
|
||||
|
||||
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
|
||||
|
||||
HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
|
||||
|
||||
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
|
||||
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Analoge Medien
|
||||
### Distribution: physisch (Kauf, Verleih, Kopie)
|
||||
|
||||
- **Text**
|
||||
- Bücher, Zeitungen, Zeitschriften, Lochkarten
|
||||
- **Bild**
|
||||
- Fotografie (Negativ, Dia, Polaroid), Mikrofilm
|
||||
- **Audio:**
|
||||
- Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
|
||||
- **Video:**
|
||||
- Film (35mm, Super 8), VHS, Betamax
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Digitale Medien
|
||||
### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
|
||||
|
||||
- **Text**
|
||||
- E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
|
||||
- **Bild**
|
||||
- Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
|
||||
- **Audio**
|
||||
- Audiodatei (MP3, FLAC, WAV, AAC, OGG)
|
||||
- **Video**
|
||||
- Videodatei (MP4, MKV, AVI, WebM)
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Digitale Speichermedien
|
||||
|
||||
- **Optische Speicher**
|
||||
- CD, DVD, Blu-ray
|
||||
- **Magnetische Speicher**
|
||||
- Festplatte (HDD), Magnetband (LTO)
|
||||
- **Flash-Speicher**
|
||||
- SSD, USB-Stick, SD-Karte
|
||||
- **Cloud-Speicher**
|
||||
- Dropbox, Google Drive, iCloud, AWS S3
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Rastergrafiken
|
||||
|
||||
**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
|
||||
|
||||
**Speicherbedarf (unkomprimiert):**
|
||||
Breite × Höhe × Farbtiefe (in Bytes)
|
||||
|
||||
**Beispiele:** JPEG, PNG, WebP
|
||||
|
||||
| Bits (Farbtiefe) | Farben | Anwendung |
|
||||
|-----:|-------:|-----------|
|
||||
| 1 | 2 | Schwarz/Weiß (Fax) |
|
||||
| 8 | 256 | Graustufen, GIF |
|
||||
| 24 | 16,7 Mio. | True Color (Standard) |
|
||||
| 32 | 16,7 Mio. + Alpha | Transparenz |
|
||||
|
||||
<!--
|
||||
KLAUSURRELEVANT:
|
||||
- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
|
||||
- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
|
||||
- Farbtiefe: 2^n Farben bei n Bit
|
||||
- 24 Bit = 8 Bit pro Kanal (R, G, B)
|
||||
- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Vektorgrafiken
|
||||
|
||||
**Speicherung als geometrische Primitive:**
|
||||
- Pfade (Bézierkurven mit Kontrollpunkten)
|
||||
- Grundformen (Rechteck, Ellipse, Polygon)
|
||||
- Text (Glyphen als Outlines)
|
||||
|
||||
**SVG-Beispiel:**
|
||||
```xml
|
||||
<circle cx="50" cy="50" r="40" fill="#ff0000"/>
|
||||
```
|
||||
|
||||
<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>
|
||||
|
||||
<!--
|
||||
KLAUSURRELEVANT:
|
||||
- Vektor = Beschreibung (deklarativ)
|
||||
- Raster = Pixel für Pixel (imperativ)
|
||||
- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
|
||||
- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
|
||||
- SVG = Scalable Vector Graphics (Web-Standard)
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Die Schwächen des Auges
|
||||
|
||||
**Menschen sehen:**
|
||||
- Helligkeit besser als Farbe
|
||||
- Große Flächen besser als feine Details
|
||||
- Niedrige Frequenzen besser als hohe
|
||||
|
||||
**JPEG nutzt das aus:**
|
||||
- Farbauflösung reduzieren (Helligkeit behalten)
|
||||
- Glatte Flächen effizient speichern
|
||||
- Hohe Frequenzen (feine Details) verwerfen
|
||||
|
||||
<!--
|
||||
KLAUSURRELEVANT:
|
||||
- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
|
||||
- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
|
||||
- Niedrig = langsame Änderung = große gleichmäßige Fläche
|
||||
- Hoch = schnelle Änderung = feine Details, Kanten
|
||||
- Analogie zur Psychoakustik bei MP3 (letztes Mal)
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||

|
||||
|
||||
# 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
|
||||
-->
|
||||
@@ -4,8 +4,8 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
title: "Termin 1: Geschichte, Grundlagen & HTML"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
|
||||
---
|
||||
|
||||
<style>
|
||||
@@ -59,8 +59,7 @@ section.klausur {
|
||||
}
|
||||
@media print {
|
||||
section.klausur {
|
||||
background: url('./assets/klausur-pattern.svg') !important;
|
||||
background-size: cover !important;
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
@@ -69,6 +68,38 @@ section.aufgabe {
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#fce4ec,
|
||||
#fce4ec 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #a02060;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -84,7 +115,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
@@ -97,24 +128,13 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 1 – 20.12.2025
|
||||
## Geschichte, Grundlagen & HTML
|
||||
|
||||
---
|
||||
|
||||
# Kursübersicht
|
||||
|
||||
**3 Termine (10:00 – 16:30 Uhr):**
|
||||
**Kapitel:**
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 1 | 20.12.2025 | Geschichte, Grundlagen & **HTML** |
|
||||
| 2 | 10.01.2026 | Netzwerke, Protokolle, **semantisches HTML** & **CSS** |
|
||||
| 3 | 24.01.2026 | Interaktivität, Animationen & **JavaScript** |
|
||||
|
||||
**Format:** Theorie + viele Hands-On-Übungen
|
||||
1. Geschichte, Grundlagen & **HTML**
|
||||
2. Netzwerke, Protokolle, **semantisches HTML** & **CSS**
|
||||
3. Interaktivität, Animationen & **JavaScript**
|
||||
|
||||
**Ziel:** "Gelernte Hilflosigkeit" ablegen
|
||||
|
||||
@@ -122,8 +142,15 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 1: Die Geschichte
|
||||
## Von der Geburtsstunde des erten Computer-Algorithmus bis zur Vernetzung des gesamten Globus
|
||||
# Kapitel 1
|
||||
## Geschichte, Grundlagen & HTML
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Die Geschichte des Computers
|
||||
## Vom ersten Algorithmus bis zum globalen Netzwerk
|
||||
|
||||
---
|
||||
|
||||
@@ -145,14 +172,13 @@ Antoine Claudet
|
||||
|
||||
**Die erste Programmiererin der Welt**
|
||||
|
||||
- Arbeitete mit **Charles Babbage** an der "Analytical Engine"
|
||||
- Ihre »Notes« zu Babbages Maschine: **umfangreicher als sein Text**
|
||||
- 1843 publiziert – unter Initialen »A.A.L.« Ada Augusta Lovelace
|
||||
- Erst **1953** wiederentdeckt und gewürdigt
|
||||
- Schrieb **1843** den ersten Algorithmus für eine Maschine, die nie fertiggestellt wurde
|
||||
- Erste Programmiererin – 100 Jahre vor dem ersten Computer
|
||||
- Zusammenarbeit mit Charles Babbage an der *Analytical Engine*
|
||||
- Ihre Notizen: umfangreicher als sein Originaltext
|
||||
- Erst 1953 wiederentdeckt und gewürdigt
|
||||
|
||||
<!--
|
||||
Babbage: Mathematiker, besessen von Rechenmaschinen. Erst die Difference Engine, dann die Analytical Engine – nie fertig gebaut, aber revolutionär im Konzept.
|
||||
Babbage: Mathematiker, besessen von Rechenmaschinen. Erste Maschine: Difference Engine (reine Rechenmaschine). Zweite Maschine: Analytical Engine – programmierbar, mit Lochkarten gesteuert. Nie fertig gebaut, aber revolutionär im Konzept.
|
||||
|
||||
Ada: Tochter von Lord Byron, dem Dichter. Die Mutter – selbst Mathematikerin – hatte Angst, Ada könnte den "Wahnsinn" des Vaters erben. Also: strikte naturwissenschaftliche Erziehung. Weg von der Poesie, hin zur Logik.
|
||||
|
||||
@@ -182,19 +208,25 @@ Herman Hollerith, ca. 1890
|
||||
|
||||
# Herman Hollerith (1860–1929)
|
||||
|
||||
**Das Problem:** US-Volkszählung 1880 dauerte **7 Jahre** zur Auswertung
|
||||
**Erfinder der Lochkarten-Datenverarbeitung**
|
||||
|
||||
**Die Lösung:** Lochkarten + elektromechanische Tabelliermaschine
|
||||
|
||||
**1890 Census:** 62 Millionen Menschen in **2,5 Jahren** gezählt
|
||||
|
||||
**Ersparnis:** 5 Millionen Dollar (damals!)
|
||||
- **Problem:** Volkszählung 1880 brauchte 7 Jahre zur Auswertung
|
||||
- **Lösung:** Lochkarten + elektromechanische Tabelliermaschine
|
||||
- **Ergebnis:** 1890 Census in 2,5 Jahren – 5 Mio. Dollar gespart
|
||||
- Gründete Firma, die später zu IBM wurde
|
||||
|
||||
<!--
|
||||
Hollerith: Deutsch-amerikanischer Ingenieur
|
||||
Inspiration: Jacquard-Webstuhl (Lochkarten für Muster)
|
||||
Lochkarte = erstes standardisiertes Datenformat
|
||||
Eine Karte = ein Datensatz (eine Person)
|
||||
Hollerith: Deutsch-amerikanischer Ingenieur, Statistiker am US Census Bureau.
|
||||
|
||||
Das Problem: Die USA wuchsen so schnell, dass die Volkszählung von 1880 erst 1887 fertig ausgewertet war – die nächste Zählung stand schon bevor.
|
||||
|
||||
Inspiration: Jacquard-Webstuhl. Dieser französische Webstuhl nutzte seit 1804 Lochkarten zur Steuerung komplexer Muster. Hollerith übertrug das Prinzip auf Daten.
|
||||
|
||||
Seine Innovation: Eine Lochkarte = ein Datensatz (eine Person). Die Position der Löcher codierte Informationen (Alter, Geschlecht, Beruf etc.). Elektromechanische Maschine las die Karten und zählte automatisch.
|
||||
|
||||
1896 gründete er die Tabulating Machine Company. Nach mehreren Fusionen entstand daraus 1924 IBM – International Business Machines.
|
||||
|
||||
Die Lochkarte blieb bis in die 1970er das Standardformat für Dateneingabe.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -214,6 +246,17 @@ US Census Bureau
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

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

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

|
||||

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

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

|
||||
|
||||
<!--
|
||||
Unterseekabel-Karte: Über 400 Kabel verbinden die Kontinente.
|
||||
Quelle: TeleGeography Submarine Cable Map
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 1,3 Millionen Kilometer Unterseekabel
|
||||
|
||||
**Heute:**
|
||||
@@ -786,19 +809,28 @@ Kostenlos freigegeben → darum existiert es
|
||||
- **>400** Unterseekabel weltweit
|
||||
- Daten reisen mit **Lichtgeschwindigkeit** (Glasfaser)
|
||||
|
||||
**Das Internet ist physisch!** Keine "Cloud" ohne Kabel.
|
||||
Keine "Cloud" ohne Kabel – das Internet ist physische Infrastruktur.
|
||||
|
||||
**Five Eyes** (USA, UK, Kanada, Australien, Neuseeland):
|
||||
→ Zapfen Unterseekabel an – globale Massenüberwachung
|
||||
|
||||
<!--
|
||||
Google, Meta, Microsoft besitzen eigene Kabel
|
||||
Sabotage-Risiko (Russland, Anker)
|
||||
Latenz: Frankfurt → New York = ~80ms
|
||||
|
||||
Five Eyes: Geheimdienstallianz aus dem Zweiten Weltkrieg (UKUSA-Abkommen, 1946). Die fünf Länder teilen systematisch Überwachungsdaten. 2013 durch Edward Snowden enthüllt: NSA und GCHQ zapfen Unterseekabel direkt an (Programm "Tempora" des GCHQ, "Upstream" der NSA). Über diese Kabel läuft fast der gesamte internationale Internetverkehr – wer sie anzapft, kann potenziell alles mitlesen.
|
||||
|
||||
Erweiterte Allianzen: Nine Eyes (+Dänemark, Frankreich, Niederlande, Norwegen), Fourteen Eyes (+Deutschland, Belgien, Italien, Spanien, Schweden).
|
||||
|
||||
Deutschland ist also kein Five-Eyes-Mitglied, aber Teil der Fourteen Eyes. Der BND kooperiert eng mit der NSA (Operation Eikonal: BND leitete Daten vom Frankfurter Internetknoten DE-CIX an die NSA weiter).
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 2: Bits & Bytes
|
||||
# Bits & Bytes
|
||||
## Die Sprache der Computer
|
||||
|
||||
---
|
||||
@@ -944,9 +976,9 @@ Fehlercodes: Windows zeigt diese bei Bluescreens
|
||||
|
||||
| Einheit (Bit) | Einheit (Byte) |
|
||||
|---------------|----------------|
|
||||
| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte |
|
||||
| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte |
|
||||
| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte |
|
||||
| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte = 8.000 Bit |
|
||||
| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte = 8 Mbit |
|
||||
| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte = 8 Gbit |
|
||||
|
||||
**Praxis:** 100 Mbit/s Internet = **12,5 MB/s** Download
|
||||
|
||||
@@ -961,35 +993,9 @@ Warum? Marketing - 100 klingt besser als 12,5
|
||||
|
||||
---
|
||||
|
||||
# Warum zeigt meine 1TB-Festplatte nur 931GB?
|
||||
|
||||
**Zwei Zählweisen:**
|
||||
|
||||
| Dezimal (Hersteller) | Binär (Computer) |
|
||||
|---------------------|------------------|
|
||||
| Kilo = 1.000 | Kibi = 1.024 (2¹⁰) |
|
||||
| Mega = 1.000.000 | Mebi = 1.048.576 (2²⁰) |
|
||||
| Giga = 1.000.000.000 | Gibi = 1.073.741.824 (2³⁰) |
|
||||
| Tera = 1.000.000.000.000 | Tebi = 1.099.511.627.776 (2⁴⁰) |
|
||||
|
||||
**Das Problem:**
|
||||
- Hersteller verkauft: 1 TB = 1.000.000.000.000 Bytes
|
||||
- Computer rechnet: 1 TiB = 1.099.511.627.776 Bytes
|
||||
- Differenz: **9,1%** → zeigt nur **931 GB**
|
||||
|
||||
<!--
|
||||
Dezimal: SI-System (Système International) - Basis 10
|
||||
Binär: IEC-Standard (International Electrotechnical Commission) - Basis 2
|
||||
Kibi/Mebi/Gibi = Kunstwörter für binäre Einheiten
|
||||
Hersteller nutzen Dezimal = klingt größer = Marketing
|
||||
Windows zeigt binär, schreibt aber "GB" statt "GiB"
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 3: Eure erste Webseite
|
||||
# Unsere erste Webseite
|
||||
## HTML-Grundlagen
|
||||
|
||||
---
|
||||
@@ -1077,6 +1083,7 @@ Formattierungssprache
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# HTML Metadaten
|
||||
|
||||
@@ -1115,6 +1122,34 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTML Metadaten – Vertiefung
|
||||
|
||||
Der `<head>`-Bereich enthält Informationen *über* das Dokument, nicht den sichtbaren Inhalt. Diese Metadaten steuern Browser-Verhalten, Suchmaschinen-Indexierung und Social-Media-Vorschauen.
|
||||
|
||||
**Kritische Meta-Tags:**
|
||||
|
||||
| Tag | Funktion | Beispiel |
|
||||
|-----|----------|----------|
|
||||
| `<title>` | Browser-Tab, Suchergebnis-Titel | `<title>HdM Stuttgart</title>` |
|
||||
| `<meta charset>` | Zeichenkodierung (Umlaute!) | `<meta charset="UTF-8">` |
|
||||
| `<meta viewport>` | Mobile Darstellung | `width=device-width, initial-scale=1` |
|
||||
| `<meta description>` | Suchergebnis-Snippet (max 160 Zeichen) | SEO-kritisch |
|
||||
|
||||
**Open Graph Protocol (Facebook, 2010):**
|
||||
```html
|
||||
<meta property="og:title" content="Artikel-Titel">
|
||||
<meta property="og:image" content="https://example.com/preview.jpg">
|
||||
```
|
||||
Steuert die Vorschau beim Teilen auf Facebook, LinkedIn, WhatsApp, Slack.
|
||||
|
||||
**SEO-Relevanz:** Google nutzt `<title>` und `<meta description>` für Ranking und Snippet-Anzeige. Fehlende Metadaten = schlechtere Auffindbarkeit.
|
||||
|
||||
---
|
||||
|
||||
# HTML-Tags und Attribute
|
||||
|
||||
```html
|
||||
@@ -1304,6 +1339,7 @@ https://developer.mozilla.org/de/docs/Web/HTML/Reference/Elements/dialog
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Wie nutzen Menschen das Web?
|
||||
|
||||
@@ -1337,9 +1373,37 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Web-Zugänglichkeit – Vertiefung
|
||||
|
||||
**a11y** = Accessibility (a + 11 Buchstaben + y). Die WHO schätzt, dass 15% der Weltbevölkerung eine Behinderung haben – das sind über 1 Milliarde potenzielle Nutzer.
|
||||
|
||||
**Arten von Einschränkungen:**
|
||||
|
||||
| Typ | Permanent | Temporär | Situativ |
|
||||
|-----|-----------|----------|----------|
|
||||
| Visuell | Blindheit | Nach Augen-OP | Grelle Sonne |
|
||||
| Motorisch | Amputation | Gebrochener Arm | Baby auf dem Arm |
|
||||
| Auditiv | Taubheit | Ohrenentzündung | Laute Umgebung |
|
||||
| Kognitiv | Legasthenie | Müdigkeit | Ablenkung |
|
||||
|
||||
**Assistive Technologien:**
|
||||
- **Screenreader:** NVDA (Windows, kostenlos), VoiceOver (Apple, integriert), JAWS (kommerziell)
|
||||
- **Braillezeilen:** Taktile Ausgabe, ~40–80 Zeichen
|
||||
- **Switch-Geräte:** Ein-Knopf-Steuerung für motorische Einschränkungen
|
||||
- **Eye-Tracking:** Blicksteuerung für Bewegungsunfähige
|
||||
|
||||
Screenreader lesen den DOM sequenziell – semantisches HTML (`<nav>`, `<main>`, `<button>`) ermöglicht Navigation per Tastenkürzel.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Warum "Barrierefreiheit"?
|
||||
|
||||
@@ -1375,6 +1439,35 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Rechtliche Anforderungen – Vertiefung
|
||||
|
||||
Der **European Accessibility Act (EAA)** trat am 28. Juni 2025 in Kraft und betrifft erstmals auch private Unternehmen – nicht nur öffentliche Stellen.
|
||||
|
||||
**Betroffene Sektoren:**
|
||||
- E-Commerce (Online-Shops)
|
||||
- Bankdienstleistungen
|
||||
- Telekommunikation
|
||||
- E-Books und E-Reader
|
||||
- Ticketing und Check-in-Terminals
|
||||
|
||||
**WCAG 2.2 – Konformitätsstufen:**
|
||||
|
||||
| Level | Anforderung | Beispiel |
|
||||
|-------|-------------|----------|
|
||||
| A | Minimum | Alt-Texte für Bilder |
|
||||
| AA | Gesetzlicher Standard | Kontrast 4,5:1, Tastaturnavigation |
|
||||
| AAA | Optimal | Gebärdensprache für Videos |
|
||||
|
||||
**Curb-Cut-Effekt:** Barrierefreiheit hilft allen. Bordsteinabsenkungen für Rollstühle nutzen auch Kinderwagen, Rollkoffer, Fahrräder. Untertitel helfen Gehörlosen, aber auch in lauten Umgebungen oder beim Sprachlernen.
|
||||
|
||||
**Sanktionen:** Bis zu 100.000 € Bußgeld bei Verstößen.
|
||||
|
||||
---
|
||||
|
||||
# WCAG: Der Standard
|
||||
|
||||
**W**eb **C**ontent **A**ccessibility **G**uidelines
|
||||
@@ -1503,6 +1596,7 @@ div-Button braucht JavaScript für Enter/Space
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Barrieren im Netz vermeiden (a11y)
|
||||
|
||||
@@ -1527,6 +1621,38 @@ Echte NutzerInnen einbeziehen = Gold-Standard
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Barrierefreiheit testen – Vertiefung
|
||||
|
||||
Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erfordert manuelles Testen und idealerweise echte Nutzer mit Behinderungen.
|
||||
|
||||
**Tastatur-Test (5 Minuten, jeder kann's):**
|
||||
1. Maus weglegen, nur Tab + Enter + Pfeiltasten nutzen
|
||||
2. Fokus-Indikator immer sichtbar? (kein `outline: none;`!)
|
||||
3. Logische Reihenfolge? (nicht kreuz und quer)
|
||||
4. Alle interaktiven Elemente erreichbar?
|
||||
|
||||
**Automatisierte Tools:**
|
||||
|
||||
| Tool | Typ | Findet |
|
||||
|------|-----|--------|
|
||||
| axe DevTools | Browser-Extension | ~30% der WCAG-Verstöße |
|
||||
| WAVE | Browser-Extension | Struktur-Probleme, Kontrast |
|
||||
| Lighthouse | Chrome DevTools | Performance + Accessibility |
|
||||
| Pa11y | CLI | CI/CD-Integration |
|
||||
|
||||
**Screenreader-Kurztest:**
|
||||
- macOS: `Cmd + F5` (VoiceOver)
|
||||
- Windows: NVDA installieren (kostenlos)
|
||||
- Augen schließen, nur zuhören: Ist die Seite verständlich?
|
||||
|
||||
**Gold-Standard:** Usability-Tests mit Menschen, die Assistive Technologien täglich nutzen.
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
@@ -1534,7 +1660,7 @@ Echte NutzerInnen einbeziehen = Gold-Standard
|
||||
|
||||
**Nächster Termin:** 10.01.2026 – CSS & Netzwerke
|
||||
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||||
|
||||
---
|
||||
|
||||
@@ -4,8 +4,8 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
title: "Termin 3: Interaktivität & JavaScript"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 3: Interaktivität & JavaScript"
|
||||
---
|
||||
|
||||
<style>
|
||||
@@ -59,8 +59,7 @@ section.klausur {
|
||||
}
|
||||
@media print {
|
||||
section.klausur {
|
||||
background: url('./assets/klausur-pattern.svg') !important;
|
||||
background-size: cover !important;
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
@@ -84,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
@@ -99,7 +98,7 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 3 – 24.01.2026
|
||||
# Kapitel 3 – 24.01.2026
|
||||
## Interaktivität & JavaScript
|
||||
|
||||
---
|
||||
@@ -1005,7 +1004,7 @@ Euer ehrliches Feedback hilft mir, den Kurs zu verbessern.
|
||||
- Was könnte besser sein?
|
||||
- Welche Themen interessieren euch noch?
|
||||
|
||||
*Feedback gerne auch anonym per E-Mail an mail@librete.ch*
|
||||
*Feedback gerne auch anonym per E-Mail an lb-czechowski@hdm-stuttgart.de*
|
||||
|
||||
---
|
||||
|
||||
@@ -1013,7 +1012,7 @@ Euer ehrliches Feedback hilft mir, den Kurs zu verbessern.
|
||||
|
||||
# Danke!
|
||||
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||||
|
||||
**Ressourcen:**
|
||||
- https://nextlevelshit.github.io/html-over-js/
|
||||