Compare commits
13
Commits
test-merge
...
7d8e9f596c
| Author | SHA1 | Date | |
|---|---|---|---|
 libretech
|
7d8e9f596c | ||
|
libretech
|
ef0a55db77 | ||
|
libretech
|
ceb5f89320 | ||
|
libretech
|
a18afde2db | ||
|
libretech
|
38563e2142 | ||
|
libretech
|
aeb0adada9 | ||
|
libretech
|
e58dacd98c | ||
|
libretech
|
edc9225ccf | ||
|
libretech
|
5b94593d94 | ||
|
libretech
|
3bd6d7b459 | ||
|
libretech
|
c57db78c52 | ||
|
libretech
|
c1277cc737 | ||
|
libretech
|
fd8b107643 |
No files matched your search
@@ -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
|
||||
|
||||
@@ -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
@@ -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/"
|
||||
Executable
+158
@@ -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 & 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>
|
||||
</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
@@ -88,167 +88,103 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _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 enthalten Fotos oft 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?
|
||||
* Ziel: **→ 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: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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üfungsrelevante Folien:**
|
||||
- Gestreift oder Vollton (PDF) markiert
|
||||
@@ -135,6 +135,15 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
# Ein konkretes Beispiel
|
||||
|
||||
**Eine Minute Musik in CD-Qualität:**
|
||||
@@ -154,6 +163,8 @@ Aber es skaliert schnell.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
# Das Problem skaliert
|
||||
|
||||
| Inhalt | Unkomprimiert |
|
||||
@@ -174,6 +185,8 @@ Das Problem musste gelöst werden.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
# Video eskaliert
|
||||
|
||||
**Eine Minute 4K-Video (unkomprimiert):**
|
||||
@@ -195,11 +208,33 @@ Die physikalische Realität erzwingt Kompression.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
# 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: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 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 problemlos in 1 Byte**
|
||||
|
||||
**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
|
||||
|
||||
→ **1 Byte reicht nicht!**
|
||||
**Jedoch ohne** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 🌸
|
||||
|
||||
<!--
|
||||
Problem der Zeichenkodierung
|
||||
@@ -606,7 +661,7 @@ WICHTIG für Kontext zur ASCII-Folie:
|
||||
Byte-Längen:
|
||||
- ASCII-Zeichen (0-127): 1 Byte
|
||||
- Umlaute, diakritische Zeichen: 2 Bytes
|
||||
- Chinesisch, Japanisch, Koreanisch: 3 Bytes
|
||||
- CJK -> Chinesisch, Japanisch, Koreanisch: 3 Bytes
|
||||
- Emoji, seltene Zeichen: 4 Bytes
|
||||
-->
|
||||
|
||||
@@ -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: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _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,14 @@ Prognose 2028: 394 ZB
|
||||
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: 'Floridi, L.: The forth Revolution' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Quelle: Floridi, L.: The Fourth Revolution
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
@@ -1145,7 +1214,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 +1285,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 +1576,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 +1643,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 +1655,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 +1728,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 +1753,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 +1796,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 +1864,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 |
File renamed without changes.
Binary file not shown.
|
Before Width: | Height: | Size: 2.0 MiB After Width: | Height: | Size: 84 KiB |
@@ -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
|
||||
|
||||
<!--
|
||||
|
||||
@@ -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 -->
|
||||
|
||||
|
||||
|
||||
# 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: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _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: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
@@ -140,6 +140,38 @@ 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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Kapitel 1
|
||||
@@ -596,6 +628,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 +842,6 @@ ARPANET-Karte 1969
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
ARPANET-Karte 1969
|
||||
4 Knoten: UCLA, Stanford, UCSB, Utah
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das WWW (1989)
|
||||
@@ -766,6 +864,14 @@ WWW war NICHT kommerziell geplant!
|
||||
Kostenlos freigegeben → darum existiert es
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
@@ -850,7 +956,7 @@ Shannon: Begründer der Informationstheorie
|
||||
**8 Bits = 1 Byte**
|
||||
|
||||
```
|
||||
0 1 0 0 1 0 0 1
|
||||
0 0 1 0 1 0 1 0
|
||||
```
|
||||
|
||||
**Wie viele Kombinationen?**
|
||||
@@ -882,23 +988,50 @@ Farbbild: Rot + Grün + Blau
|
||||
|
||||
---
|
||||
|
||||
# Zahlensysteme
|
||||
|
||||
**Eine Ziffer — wie viele Werte?**
|
||||
|
||||
| System | Basis | Ziffern | Beispiel |
|
||||
|--------|-------|---------|----------|
|
||||
| **Dezimal** | 10 | 0-9 | `42` = 4×10 + 2 |
|
||||
| **Binär** | 2 | 0-1 | `101010` = 42 |
|
||||
| **Hexadezimal** | 16 | 0-F | `2A` = 2×16 + 10 |
|
||||
|
||||
→ Alle drei beschreiben dieselbe Zahl: **42**
|
||||
|
||||
<!--
|
||||
Dezimal = was wir im Alltag nutzen (10 Finger → 10 Ziffern)
|
||||
Binär = was Computer nutzen (Strom an/aus → 2 Zustände)
|
||||
Hexadezimal = Kompromiss: kompakter als Binär, aber passt perfekt auf Bytes (2 Hex-Ziffern = 1 Byte = 8 Bit)
|
||||
Die Basis bestimmt, wie viele Symbole pro Stelle zur Verfügung stehen:
|
||||
- Dezimal: 10 (0–9)
|
||||
- Binär: 2 (0, 1)
|
||||
- Hex: 16 (0–9 + A–F, wobei A=10, B=11, ..., F=15)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Hexadezimal: Lesbarkeit
|
||||
|
||||
**Binär ist unleserlich:**
|
||||
**Für den Menschen ungeeignet:**
|
||||
`01001101 01010000 00110011`
|
||||
|
||||
**Hexadezimal (Base 16):**
|
||||
`4D 50 33` (= "MP3" in ASCII)
|
||||
|
||||
**Jede Hex-Ziffer = 4 Bits**
|
||||
**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
|
||||
0-9, A-F (A=10, B=11, ..., F=15)
|
||||
|
||||
**Ihr kennt das:** `#FF0000` = Rot in CSS
|
||||
`4 = 0100` `D = 1101`
|
||||
`5 = 0101` `0 = 0000`
|
||||
`3 = 0011` `3 = 0011`
|
||||
|
||||
<!--
|
||||
Hex = Shortcut für Menschen
|
||||
1 Byte = 2 Hex-Ziffern (00-FF)
|
||||
CSS-Farben nutzen Hex
|
||||
"Nibble" = 4 Bits = halbes Byte (Wortspiel: nibble = knabbern, byte = beißen)
|
||||
CSS (Cascading Style Sheets)-Farben nutzen Hex: #FF0000 = Rot
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -933,7 +1066,12 @@ CSS-Farben nutzen Hex
|
||||
Präfixe:
|
||||
- 0x = "das ist Hexadezimal" (C, JavaScript, Python)
|
||||
- U+ = Unicode-Codepoint (Standard für Zeichenkodierung)
|
||||
- # = CSS-Konvention für Farben
|
||||
- # = CSS (Cascading Style Sheets)-Konvention für Farben
|
||||
|
||||
ABKÜRZUNGEN:
|
||||
- MAC = Media Access Control (eindeutige Hardware-Adresse einer Netzwerkkarte)
|
||||
- CSS = Cascading Style Sheets
|
||||
- Unicode = universeller Zeichensatz für alle Schriftsysteme
|
||||
|
||||
Speicheradressen erklärt:
|
||||
- 64-Bit-System → Adresse hat 64 Bit = 16 Hex-Ziffern
|
||||
@@ -1637,8 +1775,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 +1784,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: 698 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.0 MiB After Width: | Height: | Size: 84 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: 213 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 450 KiB |
Reference in new issue
Block a user