Compare commits

9 Commits
Author SHA1 Message Date
libretech 38563e2142 fix growth-of-big-data image: rename to remove spaces, hide footer 2026-04-10 01:29:16 +02:00
libretech aeb0adada9 update 223015b chapter 1: add images, artemis slide, fix hex table
- add cd logo, cd player, dvd, artemis images
- add artemis ii slide with apollo comparison and bandwidth calculation
- regenerate hex-dec lookup table as 16x16 grid with ascii highlight
- move hex-dec table next to hexadezimal slides
- fix mp3 bitrate: 320 -> 128 kbps to match stated file size
2026-04-10 01:10:26 +02:00
libretech e58dacd98c rework 223015b intro: cleaner structure, new umfrage, consolidate slides
- update über mich (full name, proper title)
- remove ama/jung-naiv slides
- new course-specific umfrage questions with speaker notes
- consolidate warum/ziel/kompetenzen into two slides
- chapter-based kursübersicht, klausur-styled prüfungsleistung
2026-04-10 01:10:17 +02:00
libretech edc9225ccf add assembler and fortran slides to 223015c chapter 1
- assembler (1947): kathleen booth, mnemonics, rollercoaster tycoon
- fortran (1957): john backus, lois haibt, formula translator
- detailed speaker notes with biographical and technical context
2026-04-09 22:11:11 +02:00
libretech 5b94593d94 update 223015b klausurfolien: endnutzer -> endnutzerInnen 2026-04-09 22:11:04 +02:00
libretech 3bd6d7b459 update 223015b chapter 1: content fixes, expand speaker notes with abbreviations
- endnutzer -> endnutzerInnen, fix lossy reversibility wording
- add tar to deflate examples, reword shannon-limit
- expand kompression-vertiefung speaker notes: lz77/lz78/deflate/tar explained
- resolve all abbreviations in speaker notes (cmyk, rgb, css, html, http,
  smtp, url, cjk, utf-8, si, iec, iot, lto, ssd, hdd, ecc, raid, vhs,
  fft, jpeg, aac, riaa, foss, iis, rle)
- minor slide fixes: hex examples, byte value, wording improvements
2026-04-09 22:10:59 +02:00
libretech c57db78c52 rework dev server: hmr for all courses, per-course targets, root index
- make dev serves all courses on port 1312 with marp live reload
- make dev-b/dev-c for single course on 1313/1314
- dev-kill only kills specific ports instead of all marp processes
- add generate-root-index.sh for prod build overview page
- cleanup function uses exec + trap instead of pid files
2026-04-09 22:10:48 +02:00
libretech c1277cc737 update 223015c chapter 1: add mosaic browser image, remove duplicate speaker notes 2026-03-27 09:46:56 +01:00
libretech fd8b107643 add 00-intro for 223015c, update chapter 1 speaker notes and five eyes
- new intro deck for 223015c with adapted content, colors, and assets
- chapter 1: expanded sputnik/kalter krieg speaker notes, five eyes on unterseekabel slide
- bits/bytes table: added factor 8 conversion, removed 1tb slide
2026-03-27 09:41:29 +01:00
22 changed files with 689 additions and 213 deletions

No files matched your search

+3 -2
View File
@@ -35,8 +35,9 @@ build/ # Generated output (gitignored)
## Build Commands
```bash
make dev-b # Dev server 223015b (port 1311)
make dev-c # Dev server 223015c (port 1312)
make dev # Marp live server all courses (port 1312, HMR)
make dev-b # Marp live server 223015b (port 1313, HMR)
make dev-c # Marp live server 223015c (port 1314, HMR)
make build # Build all courses
make build-b # Build 223015b only
make build-c # Build 223015c only
+13 -4
View File
@@ -27,7 +27,9 @@ help:
@echo " 223015c - Internettechnologien"
@echo ""
@echo "Development:"
@echo " make dev - Start development server (port 3000)"
@echo " make dev - Marp live server all courses (port 1312, HMR)"
@echo " make dev-b - Marp live server 223015b (port 1313, HMR)"
@echo " make dev-c - Marp live server 223015c (port 1314, HMR)"
@echo ""
@echo "Build:"
@echo " make build - Build all courses"
@@ -55,13 +57,20 @@ build/.exists:
@mkdir -p build/223015b build/223015c
@touch $@
# Development server
# Development server (Marp live server with HMR)
dev:
@./scripts/dev-server.sh
dev-b:
@./scripts/dev-server.sh 223015b 1313
dev-c:
@./scripts/dev-server.sh 223015c 1314
dev-kill:
@-pkill -f "marp-cli.*--server" 2>/dev/null || true
@sleep 0.5
@-fuser -k 1312/tcp 2>/dev/null || true
@-fuser -k 1313/tcp 2>/dev/null || true
@-fuser -k 1314/tcp 2>/dev/null || true
# Build functions
define build_course
+24 -33
View File
@@ -1,12 +1,16 @@
#!/usr/bin/env bash
# Simplified development server for HdM slides
# Starts single Marp server for all courses
# Development server for HdM slides
# Usage:
# ./dev-server.sh - Marp live server for all courses (port 1312)
# ./dev-server.sh 223015b 1313 - Marp live server for single course
# ./dev-server.sh 223015c 1314 - Marp live server for single course
set -e
# Configuration
SLIDES_DIR="slides"
DEV_PORT=3000
COURSE="${1:-}"
DEV_PORT="${2:-1312}"
# Colors
GREEN='\033[0;32m'
@@ -14,40 +18,27 @@ BLUE='\033[0;34m'
RED='\033[0;31m'
NC='\033[0m' # No Color
# Cleanup function
cleanup() {
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 port
kill_existing() {
echo -e "${BLUE}Cleaning up existing processes...${NC}"
pkill -9 -f "marp-cli" 2>/dev/null || true
fuser -k $DEV_PORT/tcp 2>/dev/null || true
sleep 1
# Kill existing process on our port only
kill_port() {
fuser -k "$DEV_PORT/tcp" 2>/dev/null || true
sleep 0.5
}
# Main
trap cleanup SIGINT SIGTERM
trap 'echo -e "\n${RED}Shutting down...${NC}"; kill 0; exit 0' SIGINT SIGTERM
kill_existing
kill_port
echo -e "${GREEN}Starting development server...${NC}"
echo ""
echo -e " Server: ${BLUE}http://localhost:$DEV_PORT${NC}"
echo -e " Slides: ${BLUE}$SLIDES_DIR/${NC}"
echo ""
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"
if [ -n "$COURSE" ]; then
SERVE_DIR="$SLIDES_DIR/$COURSE"
echo -e "${GREEN}Marp dev server${NC} · ${BLUE}$COURSE${NC}"
else
SERVE_DIR="$SLIDES_DIR"
echo -e "${GREEN}Marp dev server${NC} · ${BLUE}all courses${NC}"
fi
echo -e " ${BLUE}http://localhost:$DEV_PORT${NC}"
echo -e " ${BLUE}$SERVE_DIR/${NC}"
echo ""
# Start single Marp server for all slides
PORT=$DEV_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/"
# Wait for process to exit
wait
PORT=$DEV_PORT exec npx @marp-team/marp-cli --server "$SERVE_DIR/"
+158
View File
@@ -0,0 +1,158 @@
#!/usr/bin/env bash
# Generate root index.html for HdM slides overview
# Usage: ./generate-root-index.sh
BUILD_DIR="${1:-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; }
.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; }
}
</style>
</head>
<body>
<h1>HdM Vorlesungen</h1>
<p class="subtitle">Sommersemester 2026 · Michael Czechowski</p>
<div class="courses">
<div class="course-card course-b">
<a href="223015b/" class="course-link">
<span class="course-label">223015b</span>
<div class="course-title">Dateiformate, Schnittstellen, Speichermedien &amp; Distributionswege</div>
<span class="course-info">6 Kapitel · Modul &quot;Technik 1&quot;</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 &quot;Technik 1&quot;</span>
</a>
</div>
</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>
HEADER
echo "Generated $BUILD_DIR/index.html"
+52 -116
View File
@@ -88,167 +88,103 @@ Hochschule der Medien Stuttgart
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/qrcode-0.svg)
---
<!-- _class: lead -->
# Willkommen!
# Herzlich willkommen!
## Einführung
---
# Über mich
**Michael Czechowski**
**Michael Werner Czechowski**
- Irgendwas mit IT, Cloud und AI
- Systems and Platform Engineer
- Schwerpunkte:
- Web-Technologien, Barriere-Armut, Systemarchitektur, Open Source
- Hintergrund:
- Philosophie (Uni Stuttgart) -> NO degree
- Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
- Philosophie (Uni Stuttgart)
- Wirtschaftsinformatik (Leibniz-FH Hannover)
- Kontakt: lb-czechowski@hdm-stuttgart.de
---
# Warum dieses Modul?
**Digitale Medien sind überall.**
* Warum enthält ein Foto Informationen über den Aufnahmeort?
* Warum lassen sich gelöschte Dateien wiederherstellen?
* Warum benötigt eine Minute 4K-Video unkomprimiert 45 GB Speicher?
* Warum zeigt eine "1 TB"-Festplatte nur 931 GB an?
* Warum ist USB-C nicht gleich USB-C?
* **→ Mitreden können!**
<!--
Kurze Vorstellung
Praxisbezug betonen
Fragen jederzeit willkommen
1. EXIF (Exchangeable Image File Format)-Metadaten speichern GPS-Koordinaten, Kameramodell und Zeitstempel automatisch. Die meisten wissen nicht, dass diese Daten beim Versenden mitgeschickt werden. → Kapitel 4: Metadaten
2. Beim Löschen wird nur der Verzeichniseintrag im Dateisystem entfernt, nicht die Daten selbst. Die Bits bleiben auf dem Datenträger, bis sie überschrieben werden. → Kapitel 3: Dateisysteme
3. 3840 × 2160 Pixel × 3 Byte (RGB) × 30 Bilder/Sek × 60 Sek = ~45 GB. Codecs wie H.264/H.265 komprimieren um Faktor 100+. → Kapitel 1+2: Kompression
4. Hersteller rechnen dezimal (1 TB = 10¹² Bytes), Betriebssysteme binär (1 TiB = 2⁴⁰ Bytes). Die Differenz beträgt bei Terabyte bereits ~10%. → Kapitel 1: Dateneinheiten
5. USB-C ist nur die Steckerform. Dahinter können USB 2.0 (480 Mbit/s), USB 3.2 (20 Gbit/s) oder Thunderbolt 4 (40 Gbit/s) laufen — gleiches Kabel, völlig unterschiedliche Leistung. → Kapitel 3: Schnittstellen
-->
---
<!-- _footer: '' -->
![bg fit](./assets/jung-naiv.png)
---
# AMA (Ask my anything)
*Nur ein Vorschlag ...*
* Hast du alle Bände von AoT daheim?
* Hast du eine Studierenden-Kneipe mal geleitet?
* Hast du wirklich 17 Semester Philosophie ohne Abschluss studiert?
---
# Kurze Umfrage
**Bitte Hand heben:**
1) Wer hat schon mal ein Video komprimiert/konvertiert?
2) Wer kennte die 3-2-1 Regel?
3) Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
4) Wer hat schon mal mit APIs gearbeitet?
5) Wer weiß, was UTF-8 bedeutet?
6) Wer hat schon mal mit einem CLI gearbeitet?
6) **Wer hat schon mal etwas mit HTML oder CSS gemacht?** (Hex-Farben wie `#FF0000`?)
1) Wer kennt den Unterschied zwischen analog und digital?
2) Wer hat schon mal eine Datei von einem Format in ein anderes konvertiert?
3) Wer hat schon mal Metadaten aus einem Foto entfernt?
4) Wer kennt die 3-2-1 Backup-Regel?
5) Wer hat schon mal eine API benutzt?
<!--
Niveau der Gruppe einschätzen
Keine falschen Antworten
Zeigt, wo wir starten
HTML/CSS-Frage: Viele kennen Hex-Codes aus Webdesign
API = Application Programming Interface
-->
---
# Warum dieses Modul?
**Digitale Medien sind überall** – aber was steckt dahinter?
* Warum ist ein JPEG kleiner als ein PNG?
* Warum klingt MP3 anders als FLAC?
* Warum zeigt meine 1 TB Festplatte nur 931 GB?
* Warum ist USB-C so verwirrend?
* Wie funktioniert eigentlich Streaming?
* **→ Die Technik dahinter verstehen!**
<!--
Praxisnahe Fragen aus dem Alltag
Nicht nur "was", sondern "warum"
Verständnis für technische Entscheidungen
-->
---
# Das Ziel
**Technische Grundlagen verstehen**, um fundierte Entscheidungen treffen zu können.
Als Digital- und Medienwirtschaftler:innen werdet ihr täglich mit technischen Fragen konfrontiert:
* Welches Format für welchen Zweck?
* Welche Schnittstelle für welches Gerät?
* Wie funktioniert die Distribution digitaler Inhalte?
* **→ Mitreden können – nicht (zwingend) programmieren!**
<!--
Nicht: Ihr sollt Programmierer werden
Sondern: Ihr sollt technische Entscheidungen verstehen
Praxisbezug: Medienproduktion, Marketing, Projektmanagement
-->
---
# Was ihr lernt
**In dieser Veranstaltung erwerbt ihr folgende Kompetenzen:**
* Fundiertes Grundwissen über Daten und Informationen
* Dateiformate analysieren und verstehen
* Grundlagen von Kompression (Audio, Bild, Video)
* Speichermedien unterscheiden
* Programmier-Schnittstellen kennenlernen
* APIs und Distributionswege verstehen
<!--
Fokus auf Verständnis, nicht auf Programmierung
Hands-On jede Woche: Selbst ausprobieren
Ziel: Einblick in die Denkweise von Software-Entwicklern
-->
---
# Kursübersicht
**5 Termine:**
**Kapitel:**
| # | Datum | Thema |
|---|-------|-------|
| 1 | 19.12.2025 | Bits, Bytes, Zeichenkodierung & Audio |
| 2 | 09.01.2026 | Bild- & Video-Kompression |
| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
| 5 | TBA | Vertiefung & offene Fragen |
1. Grundlagen, Text & **Audio** (Bits, Bytes, Zeichenkodierung, MP3)
2. **Bild** & **Video**-Kompression (JPEG, PNG, H.264/H.265)
3. **Speichermedien** & **Schnittstellen** (HDD, SSD, USB, Thunderbolt)
4. **Distribution**, **APIs** & Zukunft (Streaming, REST, Cloud)
5. Vertiefung & offene Fragen
**Format:** Theorie + Hands-On (30-40 Min pro Termin)
<!--
Nicht nur theoretische Inhalte
Praktische Übungen jede Woche
Medienwissenschaftler:innen, nicht Informatiker:innen
-->
**Ziel:** Mitreden können
---
# Prüfungsleistung 18.02.
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->
# Prüfungsleistung
**Nach aktuellem Kenntnisstand:**
* 90 min (40% Grundlagen, 40% Dateiformate, 20% AV)
* Schriftliche Klausur
* 90 min insg. (Technik 1)
* Schriftliche Klausur (digital)
* Teils offene Fragen
* Vermutlich digital
* Kein Coding!
* **Prüfungsrelevant:** Alles in den Folien/im Skript
<!--
Details können sich noch ändern
Keine Programmieraufgaben
Verständnisfragen, keine Auswendiglernerei
-->
* Kein Coding/Programmieren
* **Prüfungsrelevant:** Folien sind markiert mit anderem Hintergrund
+112 -47
View File
@@ -135,6 +135,15 @@ Hochschule der Medien Stuttgart
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/compact-disc-cd.jpg)
---
![bg right:40%](./assets/IMG_3617.jpg)
# Ein konkretes Beispiel
**Eine Minute Musik in CD-Qualität:**
@@ -154,6 +163,8 @@ Aber es skaliert schnell.
---
![bg right:40%](./assets/IMG_3617.jpg)
# Das Problem skaliert
| Inhalt | Unkomprimiert |
@@ -174,6 +185,8 @@ Das Problem musste gelöst werden.
---
![bg right:32% contain](./assets/dvd.jpg)
# Video eskaliert
**Eine Minute 4K-Video (unkomprimiert):**
@@ -195,11 +208,33 @@ Die physikalische Realität erzwingt Kompression.
---
![bg right:40%](./assets/artemis.jpg)
# Artemis II orbitiert
| | Apollo (1969) | Artemis II (2026) |
|---|---|---|
| Bandbreite | ~50 kbit/s | 260 Mbit/s |
| Video | SW, ~320 Zeilen | HD live, 4K gespeichert |
| Codec | analog | H.265 (HEVC) |
260.000.000 Bit/s
÷ 8 (Bit pro Byte) = 32,5 MB/s
× 60 Sekunden = **1,95 GB pro Minute**
*Apollo: 50 kbit/s = 0,375 MB/min*
<!--
Übertragung per Infrarot-Laser (O2O = Orion Artemis II Optical Communications). MAScOT-Terminal entwickelt von MIT Lincoln Lab. 32 Kameras an Bord (Nikon D5/Z9, GoPros, Redwire 4K-Festkameras). ZCube-Encoder kodiert H.265 an Bord. Bandbreite geteilt mit Telemetrie und Voice — daher live "nur" HD, echtes 4K kommt auf CompactFlash-Karten nach Splashdown. Latenz Mond ↔ Erde: ~1,3 Sekunden (384.400 km). Apollo nutzte S-Band Radio, Artemis II Infrarot-Laser.
-->
---
# Kompressionsraten in der Praxis
| Medium | Unkomprimiert | Komprimiert | Faktor |
|--------|-------------:|------------:|-------:|
| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 320) | ~10× |
| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 128) | ~10× |
| 1 Foto (12 MP) | ~36 MB | ~3 MB (JPEG) | ~12× |
| 1 Min 4K-Video | ~45 GB | ~375 MB (H.264) | ~120× |
@@ -282,12 +317,12 @@ Sondern gezielt das entfernen, was Menschen nicht wahrnehmen.
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|---|---|---|
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich verloren) |
| **Reduktion** | 30-50% | 80-99% |
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
**Faustregel:**
- Medien für Endnutzer → Lossy oft akzeptabel
- Medien für EndnutzerInnen → Lossy oft akzeptabel
- Quellmaterial, Code, Archive → Lossless nötig
<!--
@@ -312,7 +347,7 @@ Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der
**Verlustfreie Kompression** erreicht diese Grenze durch:
- **Statistische Kodierung:** Huffman, Arithmetic Coding
- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG)
- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG, TAR)
- Originalzustand ist exakt rekonstruierbar
**Verlustbehaftete Kompression** unterschreitet die Grenze, indem sie menschliche Wahrnehmungsgrenzen ausnutzt:
@@ -322,7 +357,32 @@ Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der
| Gehör | Maskierungseffekte, Hörschwelle | MP3: Töne unter Maskierungsschwelle weglassen |
| Sehen | Farbauflösung, Kontrastempfindlichkeit | JPEG: Chroma-Subsampling, hohe Frequenzen verwerfen |
**Shannon-Limit:** Verlustfreie Kompression kann nicht unter die Entropie; verlustbehaftete kann beliebig weit gehen – auf Kosten der Qualität.
**Shannon-Limit:** Verlustfreie Kompression ist durch Entropie begrenzt; Verlustbehaftete Kompression kann beliebig weit gehen – auf Kosten der Qualität.
<!--
ABKÜRZUNGEN:
- LZ = Lempel-Ziv (nach Abraham Lempel und Jacob Ziv)
- LZ77 = Lempel-Ziv 1977 – Sliding-Window-Verfahren: sucht Wiederholungen in einem Fenster der letzten Bytes und ersetzt sie durch Rückverweise (Offset + Länge)
- LZ78 = Lempel-Ziv 1978 – baut ein explizites Wörterbuch auf: neue Muster bekommen einen Index, Wiederholungen werden durch den Index ersetzt
- DEFLATE = Kombination aus LZ77 + Huffman-Coding; verwendet in ZIP, PNG und gzip
- TAR = Tape ARchive – kein Kompressionsformat, sondern ein Archivformat (bündelt Dateien zu einer). Kompression erst durch Kombination: .tar.gz (gzip = DEFLATE), .tar.bz2 (bzip2), .tar.xz (LZMA)
- ZIP = Archivformat mit eingebauter DEFLATE-Kompression (Phil Katz, 1989)
- PNG = Portable Network Graphics – nutzt DEFLATE für verlustfreie Bildkompression
STATISTISCHE KODIERUNG:
- Huffman-Coding: Häufige Zeichen bekommen kurze Bitfolgen, seltene Zeichen lange. Beispiel: 'e' (häufig) → 2 Bit, 'q' (selten) → 8 Bit
- Arithmetic Coding: Kodiert die gesamte Nachricht als einzelne Zahl zwischen 0 und 1. Etwas effizienter als Huffman, aber rechenintensiver
ENTROPIE (Shannon):
- Maß für den Informationsgehalt: Wie "überraschend" ist jedes Zeichen?
- Hohe Entropie = schwer komprimierbar (z.B. verschlüsselte Daten, Rauschen)
- Niedrige Entropie = gut komprimierbar (z.B. "AAAAAAA" oder natürliche Sprache)
- Theoretisches Minimum: kein Algorithmus kann unter die Entropie-Grenze kommen
PRAXISBEISPIEL:
- ZIP einer .txt-Datei: ~60-70% kleiner (Text hat niedrige Entropie)
- ZIP einer .jpg-Datei: kaum kleiner (JPEG hat Entropie schon ausgereizt)
-->
---
@@ -400,11 +460,15 @@ BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
**1 Byte = 8 Bits**
```
0 1 0 0 1 1 0 1
0 0 1 0 1 0 1 0
```
<!--
binary 00101010
= decimal 42
Rätsel: "Wenn sich das Wachstum einer Seerose auf einem Teich jeden Tag verdoppelt · und nach *zehn Tagen* der ganze Teich bedeckt ist, wann ist er zur Hälfte zugewachsen?"
Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
@@ -418,7 +482,7 @@ Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
**1 Byte = 8 Bits**
```
0 1 0 0 1 1 0 1
0 0 1 0 1 0 1 0
```
2⁸ = **256 Möglichkeiten** (0-255)
@@ -500,8 +564,8 @@ Das menschliche Auge kann etwa 10 Millionen Farben unterscheiden
<!--
Welche Farben für ein volles Spektrum bieten sich nach unserer gelernten Sparsamkeit hier am besten an?
1. CMYK bzw. in diesem Fall CMYW
2. RGB
1. CMYK (Cyan, Magenta, Yellow, Key/Black) bzw. in diesem Fall CMYW (Cyan, Magenta, Yellow, White)
2. RGB (Red, Green, Blue)
-->
---
@@ -539,23 +603,16 @@ Sog. RGB Tuple (geordnete endliche Liste)
<!--
"Weiß jemand oder möchte jemand raten, wofür das "s" bei "sRGB" steht?"
sRGB = Standard RGB
CMYK = Subtraktive Farbmischung (Druck)
sRGB = Standard RGB (Red, Green, Blue)
CMYK = Cyan, Magenta, Yellow, Key (Black) – Subtraktive Farbmischung (Druck)
Hex-Notation: FF = 255 in Dezimal
CSS-Farben nutzen Hex: #FF0000 = Rot
Wer HTML/CSS gemacht hat, kennt das schon!
CSS (Cascading Style Sheets)-Farben nutzen Hex: #FF0000 = Rot
Wer HTML (HyperText Markup Language)/CSS gemacht hat, kennt das schon!
background-color: #FF0000; = Rot
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/hex-dec-lookup-table.png)
---
# Das Problem: Sprachen
**Die Welt hat mehr als 256 Zeichen!**
@@ -564,11 +621,9 @@ background-color: #FF0000; = Rot
- + Ziffern: 10 (0-9)
- + Sonderzeichen: ~30
**≈ 90 Zeichen → passt in 1 Byte**
**≈ 90 Zeichen passen problem in 1 Byte**
**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
→ **1 Byte reicht nicht!**
**Jedoch ohne** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
<!--
Problem der Zeichenkodierung
@@ -644,7 +699,7 @@ Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
# Hexadezimal: Lesbarkeit
**Binär ist unleserlich:**
**Für den Menschen ungeeignet:**
`01010000 01001110 01000111`
**Hexadezimal (Base 16):**
@@ -653,12 +708,17 @@ Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
0-9, A-F (10=A, 11=B, ..., 15=F)
`5 = 0101` `0 = 0000`
`4 = 0100` `E = 1110`
`4 = 0100` `7 = 0111`
**ASCII Tabelle (0-127):**
[https://www.asciitable.com](https://www.asciitable.com)
<!--
"Gerne vorab auf den Link gehen"
Dezimalsystem passt nur umständlich 0->15 (1111) ins binäre System
Hexadezimal (16) passt perfekt
WICHTIG: ASCII geht nur von 0-127!
- Werte 128-255 sind NICHT in der ASCII-Tabelle
@@ -684,7 +744,12 @@ Hex-Editor = Standard-Tool für Dateianalyse und Reverse Engineering
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/hex-dec-lookup-table.png)
---
<!-- _class: lead -->
@@ -702,12 +767,12 @@ KULTURHISTORISCHER KONTEXT:
- "American Standard Code for Information Interchange" (1963)
- Entwickelt für US-amerikanische Bedürfnisse
- Keine Unterstützung für: Umlaute (ä, ö, ü), ß, diakritische Zeichen (é, ñ, ç)
- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK) wurden nicht berücksichtigt
- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK = Chinese, Japanese, Korean) wurden nicht berücksichtigt
- Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)
WARUM NOCH HEUTE RELEVANT?
- Abwärtskompatibilität: UTF-8 ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
- Internetprotokolle basieren auf ASCII: HTTP-Header, SMTP, URLs
- Abwärtskompatibilität: UTF-8 (Unicode Transformation Format, 8-bit) ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
- Internetprotokolle basieren auf ASCII: HTTP (HyperText Transfer Protocol)-Header, SMTP (Simple Mail Transfer Protocol), URLs (Uniform Resource Locator)
- Programmiersprachen: Schlüsselwörter und Syntax sind ASCII
- Ein 60 Jahre alter Standard, der durch Kompatibilitätszwänge fortbesteht
@@ -770,7 +835,7 @@ US-ASCII (1967) Code Chart
| `0100 1110` | `4E` | 78 | **N** |
| `0100 0111` | `47` | 71 | **G** |
→ **PNG**-Signatur! (Das `89` markiert: "Ich bin binär, kein Text!")
→ `89` übersteigt den ASCII-Raum und markiert eie Binärdatei
<!--
Hex = 2 Ziffern = 1 Byte = 8 Bit
@@ -853,7 +918,7 @@ WARUM nutzt PNG absichtlich 89 (= 137 dezimal)?
Geschichte: "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
Fun Fact: DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt!
Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML
Dateien OHNE Magic Number: TXT, HTML (HyperText Markup Language), CSS (Cascading Style Sheets), JSON (JavaScript Object Notation), XML (Extensible Markup Language)
→ Reiner Text, kein binäres Format
Sicherheits-Aspekt:
@@ -882,8 +947,8 @@ Windows vertraut der Endung, aber "file" (Linux) liest Magic Number
| **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)
SI (Système International d'Unités)-Präfixe (Dezimal): 1 KB = 1.000 Bytes
Binär (IEC = International Electrotechnical Commission): 1 KiB = 1.024 Bytes (Kibibyte)
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
1 TB Festplatte = ~931 GiB nutzbar
@@ -974,9 +1039,9 @@ 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
HEUTE: LTO-9 (LTO = Linear Tape-Open, 2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
VERGLEICH: SSD (Solid State Drive) ~$50/TB, HDD (Hard Disk Drive) ~$15/TB, LTO ~$5/TB
-->
@@ -1032,7 +1097,7 @@ AWS Glacier, Google Coldline und Film-Archive nutzen LTO – langsamer Zugriff,
<!--
Quellen: IDC Global DataSphere Forecast, Statista 2025
IoT-Geräte allein: 73 ZB in 2025
IoT (Internet of Things)-Geräte allein: 73 ZB in 2025
Cloud-Speicher: 100 ZB (50% der Weltdaten)
Prognose 2028: 394 ZB
-->
@@ -1041,10 +1106,10 @@ Prognose 2028: 394 ZB
<!-- _header: '' -->
<!-- _footer: 'Floridi, L.: The forth Revolution' -->
<!-- _footer: '' -->
![bg fit](./assets/growth of big data.png)
![bg fit](./assets/growth-of-big-data.png)
---
@@ -1145,7 +1210,7 @@ Analoge Speicherung codiert Information als **kontinuierliche physikalische Grö
<!--
GENERATIONSVERLUST:
Kassette → Kassette = jede Kopie schlechter
VHS → VHS = Rauschen nimmt zu
VHS (Video Home System) → VHS = Rauschen nimmt zu
Schallplatte: Jedes Abspielen = minimaler Verschleiß
ABER: Analoges Original bleibt "das Original"
@@ -1216,7 +1281,7 @@ Digitale Speicherung quantisiert kontinuierliche Signale in diskrete Werte. Der
|--------|--------|---------|
| Kopiervorgang | Physikalischer Prozess | Bit-Kopie |
| Qualität pro Generation | Verschlechtert | Identisch |
| Fehlerkorrektur | Unmöglich | Möglich (ECC, RAID) |
| Fehlerkorrektur | Unmöglich | Möglich (ECC = Error Correcting Code, RAID = Redundant Array of Independent Disks) |
| Formatmigration | Verlust | Verlustfrei möglich |
**Die Kehrseite:** Digitale Obsoleszenz. Ein DOCX von 2025 ist in 50 Jahren womöglich unlesbar – während ein Buch von 1525 heute noch lesbar ist. Offene Formate (PDF/A, FLAC, PNG) mildern dieses Risiko.
@@ -1507,7 +1572,7 @@ Patent lief 2017 aus
- Forschung ab 1982, Patent 1988
<!--
Fraunhofer IIS Erlangen
Fraunhofer IIS (Institut für Integrierte Schaltungen) Erlangen
Forschung dauerte über 10 Jahre
Perfektionist: Jeder Hörtest musste bestehen
-->
@@ -1574,7 +1639,7 @@ Ein Zusammenspiel aus vielen Faktoren:
<!--
MP3-Kompression in 4 Schritten (vereinfacht):
1. FFT (Fast Fourier Transform)
1. FFT (Fast Fourier Transform = Schnelle Fourier-Transformation)
- Wandelt Schallwellen in Frequenzen um
- Wie ein Prisma Licht in Farben zerlegt
@@ -1586,7 +1651,7 @@ MP3-Kompression in 4 Schritten (vereinfacht):
3. Quantisierung (hier passiert der Datenverlust!)
- Unwichtige Frequenzen werden "grob" gespeichert
- Wichtige Frequenzen bleiben genau
- Wie JPEG: Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
- Wie JPEG (Joint Photographic Experts Group): Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
4. Huffman-Coding (verlustfrei)
- Häufige Muster = kurze Codes
@@ -1659,7 +1724,7 @@ KERNKONZEPT: Kompression = Modell der menschlichen Wahrnehmung
**Prinzip:** Wiederholungen zählen statt wiederholen
<!--
RLE = Run-Length Encoding = Lauflängenkodierung
RLE = Run-Length Encoding (Lauflängenkodierung)
Einfachster Kompressionsalgorithmus
Gut für: Fax, einfache Grafiken, Icons
Schlecht für: Fotos, Audio (zu chaotisch)
@@ -1684,7 +1749,7 @@ Schlecht für: Fotos, Audio (zu chaotisch)
Fraunhofer verklagte Winamp, andere Tools
Millionen nutzten unlizenzierte Software
Das Pferd war aus dem Stall
2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC = Advanced Audio Coding, besser)
-->
---
@@ -1727,7 +1792,7 @@ Aber: LimeWire, Kazaa, BitTorrent folgten
→ LimeWire, Kazaa, BitTorrent, später Spotify
<!--
RIAA (Recording Industry Association of America) verklagte Napster
RIAA = Recording Industry Association of America – verklagte Napster
Urteil: Napster muss schließen (2001)
Aber: Technologie nicht mehr aufzuhalten
iPod (2001): "1.000 songs in your pocket"
@@ -1795,7 +1860,7 @@ Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
- Spektrogramme vergleichen Audacity (kostenloser Download nötig) [https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html)
<!--
Audacity: FOSS Audio-Editor (audacityteam.org)
Audacity: FOSS (Free and Open-Source Software) Audio-Editor (audacityteam.org)
Export: Datei → Exportieren → MP3 → Bitrate wählen
Spektrogramm-Ansicht: Auf Track-Name klicken (Dropdown öffnet sich) → "Spektrogramm" wählen
Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate
Binary file not shown.

After

Width:  |  Height:  |  Size: 148 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 66 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 318 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 2.0 MiB

After

Width:  |  Height:  |  Size: 84 KiB

+1 -1
View File
@@ -112,7 +112,7 @@ Hochschule der Medien Stuttgart
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
**Faustregel:**
- Medien für Endnutzer → Lossy oft akzeptabel
- Medien für EndnutzerInnen → Lossy oft akzeptabel
- Quellmaterial, Code, Archive → Lossless nötig
<!--
+228
View File
@@ -0,0 +1,228 @@
---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Grundlagen IT- und Internettechnik (223015c)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Grundlagen IT- und Internettechnik
---
<style>
:root {
--color-foreground: #1a1a2e;
--color-highlight: #d63384;
--color-dimmed: #4a4a6a;
}
section.invert {
--color-foreground: #fff;
}
section {
font-size: 1.7rem;
}
h1 {
color: #a02060;
}
section.invert h1 {
color: #fff;
}
h2 {
color: #1f2937;
}
pre {
background: #0f0f23;
color: #d63384;
border-radius: 8px;
border-left: 3px solid #d63384;
}
pre code {
background: transparent;
color: inherit;
}
code {
background: #1a1a2e;
color: #d63384;
padding: 0.15em 0.4em;
border-radius: 4px;
}
a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#fce4ec,
#fce4ec 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #fce4ec !important;
}
}
section.aufgabe {
background: #fce4ec !important;
}
section.aufgabe footer {
display: none;
}
</style>
<!-- _class: invert -->
<!-- _header: '' -->
<!-- _backgroundColor: #000 -->
![bg cover opacity:0.2](./assets/background-termin-1.png)
# Grundlagen IT- und Internettechnik
**223015c** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Sommersemester 2026**
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/qr/slides-223015c.png)
---
<!-- _class: lead -->
# Herzlich willkommen!
## Einführung
---
# Über mich
**Michael Werner Czechowski**
- Systems and Platform Engineer
- Schwerpunkte:
- Web-Technologien, Barriere-Armut, Open Source
- Hintergrund:
- Philosophie (Uni Stuttgart)
- Wirtschaftsinformatik (Leibniz-FH Hannover)
- Kontakt: lb-czechowski@hdm-stuttgart.de
---
# Warum dieses Modul?
**Das Internet ist überall** – aber was steckt dahinter?
* Warum sehen Webseiten auf dem Handy anders aus?
* Wie funktioniert eigentlich das Internet?
* Wie erkennen Sie, ob eine Werbeagentur gute Arbeit leistet?
* Was hat ein Unterseekabel mit meiner E-Mail zu tun?
* **→ Die Technik dahinter verstehen und fundierte Entscheidungen treffen**
---
# Das Ziel
**Technische Grundlagen verstehen**, um fundierte Entscheidungen treffen zu können.
Als Digital- und MedienwirtschaftlerInnen werdet ihr täglich mit technischen Fragen konfrontiert:
* Wie baue ich eine barrierearme Webseite?
* Welches Protokoll für welchen Zweck?
* Wie funktioniert das Web hinter den Kulissen?
* **→ Mitreden können – und selbst Webseiten bauen!**
---
# Was Sie hier lernen werden
**In dieser Veranstaltung erwerben Sie folgende Kompetenzen:**
* Geschichte des Computers und Internets
* HTML-Grundlagen und semantisches Markup
* CSS für Layout und Gestaltung
* Netzwerke und Protokolle (TCP/IP, DNS, HTTP(S))
* "Barrierefreiheit" im Web
* Grundlagen von JavaScript und Interaktivität
---
# Kurze Umfrage
**Bitte Hand heben:**
* Wer hat schon mal eine Webseite gebaut?
* Wer weiß, was HTML ist?
* Wer hat schon mal CSS geschrieben?
* Wer kennt den Unterschied zwischen Internet und WWW?
* Wer hat schon mal mit JavaScript gearbeitet?
---
# Kursübersicht
**Kapitel:**
1. Geschichte, Grundlagen & **HTML**
2. Netzwerke, Protokolle, **semantisches HTML** & **CSS**
3. Interaktivität, Animationen & **JavaScript**
**Ziel:** "Gelernte Hilflosigkeit" ablegen
---
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #fce4ec -->
# Prüfungsleistung
**Nach aktuellem Kenntnisstand:**
* 90 min insg. (Technik 1)
* Schriftliche Klausur (digital)
* Teils offene Fragen
* So gut wie kein Coding/Programmieren
* **Prüfungsrelevant:** Folien sind markiert mit anderem Hintergrund
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/klausur-01.png)
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/klausur-02.png)
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/klausur-03.png)
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/splan.png)
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/asta.png)
+98 -10
View File
@@ -140,6 +140,24 @@ Hochschule der Medien Stuttgart
---
# Ressourcen zum Selbstlernen
* **CODE CRISPIES: https://codecrispi.es/**
* Online Code-Editor: https://codepen.io/pen/
* MDN (Mozilla Developer Network): https://developer.mozilla.org/de/
* Flexbox-Spiel: https://flexboxfroggy.com/
* Grid-Spiel: https://cssgridgarden.com/
<!--
SPEAKER NOTES:
- Code Crispies = unser Material
- Codepen = sofort CSS ausprobieren
- MDN = DIE Referenz schlechthin
- Spiele für Flexbox/Grid – später relevant
-->
---
<!-- _class: lead -->
# Kapitel 1
@@ -596,6 +614,77 @@ COBOL läuft heute noch auf Bankensystemen
---
# Assembler (1947)
**Die erste Stufe über Maschinencode**
- Erfunden von **Kathleen Booth** (Birkbeck College, London)
- Mnemonische Befehle statt Binärzahlen (`MOV`, `ADD`, `JMP`)
- Jeder Befehl entspricht direkt einer CPU-Instruktion
- Hardwarenah, aber für Menschen lesbar
**Fun Fact:** Chris Sawyer schrieb **RollerCoaster Tycoon** (1999) fast komplett in x86-Assembly
<!--
KATHLEEN BOOTH (1922–2022):
Kathleen Hylda Valerie Booth (geb. Britten), BSc Mathematik (Royal Holloway, London), PhD Applied Mathematics (King's College London). Arbeitete ab 1946 mit Andrew Booth (später ihr Ehemann) am Birkbeck College – eines der kleinsten Computing-Teams Großbritanniens: nur Andrew, Kathleen und Xenia Sweeting.
WAS SIE TAT:
Kathleen baute die Hardware des ARC (Automatic Relay Calculator) mit auf und entwickelte dann die Programmierarchitektur. 1947 reiste sie mit Andrew nach Princeton, wo sie John von Neumann trafen und die Stored-Program-Architektur kennenlernten. Sie schrieb "Coding for A.R.C." – die erste veröffentlichte Beschreibung einer Assembly-Sprache. Statt roher Binärzahlen (z.B. 10011) konnten Programmierer nun mnemonische Kürzel verwenden (z.B. M -> cR). Ein konzeptioneller Sprung – die erste Abstraktionsschicht zwischen Mensch und Maschine.
VOR ASSEMBLER:
ENIAC (1943–46) wurde durch physisches Umstecken von Kabeln programmiert – Programmwechsel dauerten Tage. Danach kamen Stored-Program-Computer, aber Programme mussten als rohe Binärzahlen eingegeben werden. Jeder Tippfehler in einer 0/1-Folge konnte den Befehl komplett verfälschen.
WEITERE LEISTUNGEN:
- Mitentwicklung von Booth's Multiplication Algorithm (heute in Milliarden CPUs)
- Pionierin der neuronalen Netze (1958/59 – nur ~4 Jahre nach den allerersten)
- Erste öffentliche Demonstration maschineller Übersetzung (Französisch→Englisch, 1955)
- Wurde 100 Jahre alt
ROLLERCOASTER TYCOON:
Chris Sawyer, schottischer Entwickler, schrieb RCT zu 99% in x86-Assembly (MASM), nur 1% C für Windows-Schnittstellen. Warum? Assembler war seine "Muttersprache" seit Kindheit, und Performance war kritisch: Tausende Besucher mit eigenem Verhalten, Fahrgeschäfte, Pathfinding – alles in Echtzeit. Das Spiel lief auf einem Pentium 90 MHz mit 16 MB RAM. Sawyer verdiente ca. 30 Mio. Dollar an Royalties und hat über 700 Achterbahnen weltweit selbst gefahren.
-->
---
# Fortran (1957)
**Die erste höhere Programmiersprache**
- Entwickelt bei IBM unter **John Backus**
- Im Team: **Lois Haibt** – verantwortlich für die Control-Flow-Analyse
- Name: **For**mula **Tran**slator
- Ziel: Mathematische Formeln direkt als Code schreiben
- Revolutionär: ~**20 Assembler-Befehle → 1 Fortran-Zeile**
- Noch heute genutzt in Wissenschaft und Hochleistungsrechnen
<!--
JOHN BACKUS (1924–2007):
Unruhiger Werdegang – Chemiestudium abgebrochen, aus der Uni geflogen, Armee, Medizinstudium abgebrochen (Hirntumor, erfolgreich behandelt), dann Mathematik an der Columbia University. Bei IBM ab 1950. Seine Motivation war schlicht Faulheit: "Much of my work has come from being lazy. I didn't like writing programs." Er entwickelte erst Speedcoding (1953), dann leitete er das Fortran-Projekt. Später: Backus-Naur-Form (BNF), Turing Award 1977.
LOIS HAIBT (*1934):
Studierte Mathematik am Vassar College (Stipendium), jobbte in den Semesterferien bei Bell Labs. IBM bot ihr nach dem Abschluss 1955 $5.100/Jahr – fast doppelt so viel wie Bell Labs. Sie kam ohne jegliche Programmiererfahrung ins Team und war mit 21 Jahren die einzige Frau unter den 10 Kernentwicklern. Ihre Aufgabe (Section 4 des Compilers): Sie teilte Programme in "Basic Blocks" auf, erstellte einen Control-Flow-Graphen und simulierte per Monte-Carlo-Methode, welche Programmteile häufig durchlaufen werden ("Hot Paths"). Diese Info nutzte der Compiler für die Register-Optimierung. Ein für 1956 extrem fortschrittlicher Ansatz. Außerdem entwickelte sie den ersten syntaktischen Analysator für arithmetische Ausdrücke – ein Grundbaustein aller modernen Compiler. Ihre Tochter Carolyn studierte später in Princeton und promovierte am MIT in Mathematik.
Haibt über die Teamkultur: "No one was worried about seeming stupid or possessive of his or her code. We were all just learning together."
DAS TEAM:
~10 Kernmitglieder, alle in ihren 20ern und 30ern, mit "varying academic degrees and unrelated areas of expertise". Harlan Herrick schrieb das erste jemals ausgeführte Fortran-Programm. Roy Nutt war von United Aircraft ausgeliehen. David Sayre war Kristallograph.
ENTWICKLUNG:
Sollte 6 Monate dauern, brauchte 3 Jahre (1954–1957). Das Team arbeitete nachts, weil sie nur dann Zugang zum IBM 704 hatten, und schlief tagsüber im Langdon Hotel an der 56th Street. Schneballschlachten lockerten die langen Winternächte auf.
WARUM ES FUNKTIONIERTE:
Das Killerkriterium war Performance: Frühere Compiler erzeugten Code, der 5–10× langsamer war als handgeschriebener Assembler. Fortran I war der erste Compiler, der annähernd gleich schnellen Code erzeugte. Dieser Rekord hielt 20 Jahre. Ken Thompson (Erfinder von Unix): "95% of the people who programmed in the early years would never have done it without Fortran."
HEUTE:
Fortran ist die "Muttersprache des Scientific Computing". Wettervorhersage (GFS, WRF), Klimamodelle (CESM für IPCC-Berichte), Kernphysik-Simulationen, LAPACK/BLAS (die linearen Algebra-Bibliotheken unter NumPy/SciPy) – alles Fortran. In numerischen Benchmarks 30–60× schneller als Python.
PARALLELE ZU HEUTE:
Assembly-Programmierer sahen Fortran als existenzielle Bedrohung ihrer Kunst – genau wie heute manche Programmierer KI fürchten. Das Ergebnis war dasselbe: Das Werkzeug erweiterte das Feld, statt es zu ersetzen.
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
@@ -739,11 +828,6 @@ ARPANET-Karte 1969
![bg](./assets/arpanet.jpg)
<!--
ARPANET-Karte 1969
4 Knoten: UCLA, Stanford, UCSB, Utah
-->
---
# Das WWW (1989)
@@ -766,6 +850,14 @@ WWW war NICHT kommerziell geplant!
Kostenlos freigegeben → darum existiert es
-->
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/mosaic.jpg)
---
<!-- _header: '' -->
@@ -893,8 +985,6 @@ Farbbild: Rot + Grün + Blau
**Jede Hex-Ziffer = 4 Bits**
0-9, A-F (A=10, B=11, ..., F=15)
**Ihr kennt das:** `#FF0000` = Rot in CSS
<!--
Hex = Shortcut für Menschen
1 Byte = 2 Hex-Ziffern (00-FF)
@@ -1637,8 +1727,6 @@ Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erf
# Fragen & Diskussion
**Nächster Termin:** 10.01.2026 – CSS & Netzwerke
**Kontakt:** lb-czechowski@hdm-stuttgart.de
---
@@ -1648,7 +1736,7 @@ Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erf
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
Basiert auf Material von:
- Markus Thamm / Wolfgang Gruel (HdM Stuttgart)
- Michael Czechowski
- Markus Thamm / Wolfgang Gruel (HdM Stuttgart)
Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
Binary file not shown.

After

Width:  |  Height:  |  Size: 315 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 525 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 232 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 255 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 448 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 450 KiB