Compare commits
13
Commits
| 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
|
||||
|
||||
@@ -1,469 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<quiz>
|
||||
|
||||
<!-- ============================================================
|
||||
223015c – Grundlagen IT- und Internettechnik
|
||||
40 Punkte / 40 Minuten
|
||||
Michael Czechowski – HdM Stuttgart – WS 2025/26
|
||||
============================================================ -->
|
||||
|
||||
<!-- ─── 3 pt – Von-Neumann: 5 Komponenten ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q1 – Von-Neumann: Komponenten zuordnen</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ordne jeder Komponente der Von-Neumann-Architektur ihre
|
||||
Funktion zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>Rechenwerk (ALU)</text><match>Führt arithmetische und logische Operationen durch.</match></answer>
|
||||
<answer fraction="100"><text>Steuerwerk</text><match>Holt, dekodiert und steuert die Ausführung von Befehlen.</match></answer>
|
||||
<answer fraction="100"><text>Speicherwerk</text><match>Enthält sowohl Programme als auch Daten (Stored Program Concept).</match></answer>
|
||||
<answer fraction="100"><text>Ein-/Ausgabe</text><match>Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.</match></answer>
|
||||
<answer fraction="100"><text>Bus-System</text><match>Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Von-Neumann vs Harvard: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q2 – Von-Neumann vs. Harvard</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Arduino-Mikrocontroller nutzt die <strong>Harvard-Architektur</strong>.
|
||||
Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.</p>
|
||||
<p><strong>Warum ist die Harvard-Architektur für Echtzeit-Anwendungen
|
||||
auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn
|
||||
das Smartphone diese Architektur verwenden würde?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Speed vs. Flexibilität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was getrennte Speicher für Code und Daten bedeuten.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Harvard nutzt <strong>separate Speicher</strong> für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Stored Program Concept Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q3 – Stored Program Concept</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem
|
||||
ENIAC Programme durch <strong>Umstecken von Kabeln</strong> eingegeben
|
||||
werden.</p>
|
||||
<p><strong>Was konkret ermöglicht das Stored Program Concept, was
|
||||
vorher nicht möglich war? Nenne zwei Beispiele.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Programme als Daten im Speicher = Flexibilität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – der Kern liegt darin, dass Programme im Speicher als Daten residieren.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Programme werden als <strong>Daten im Speicher</strong> abgelegt → z. B. Apps können installiert/gelöscht werden und <strong>Multitasking</strong> (mehrere Programme gleichzeitig) wird möglich.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTML Metadaten: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q4 – HTML: <head> vs. <body></text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Student erstellt eine Webseite und platziert <em>alles</em>
|
||||
im <code><body></code> – auch den <code><title></code>
|
||||
und die <code><meta name="description"></code>.</p>
|
||||
<p><strong>Welche zwei konkreten Konsequenzen hat das?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>title und meta description gehören in <head>. Im <body>: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Metadaten im Body werden nicht als solche interpretiert.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – <head> und <body> haben spezifische Funktionen.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[(1) Der Browser-Tab zeigt <strong>keinen Titel</strong> an. (2) Suchmaschinen haben <strong>keine Beschreibung</strong> für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Kein Problem – Browser ignorieren die Unterscheidung zwischen <code><head></code> und <code><body></code>.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Nur das Fehlen von <code><meta charset></code> ist ein Problem – title und description funktionieren überall.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – Accessibility Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q5 – Barrierefreiheit: Curb-Cut-Effekt</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der <strong>Curb-Cut-Effekt</strong> beschreibt, wie eine
|
||||
barrierefreie Lösung – ursprünglich für Menschen mit Behinderung –
|
||||
letztendlich <em>allen</em> zugute kommt.</p>
|
||||
<p><strong>Nenne ein konkretes Web-Beispiel, das diesen Effekt
|
||||
demonstriert, und erkläre, wer davon profitiert.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Barrierefreiheit hilft allen.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche barrierefreien Maßnahmen auch Menschen ohne Behinderung nutzen.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Untertitel:</strong> Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Dark Mode:</strong> Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – EAA / WCAG ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q6 – European Accessibility Act</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der <strong>European Accessibility Act (EAA)</strong> ist seit
|
||||
Juni 2025 in Kraft.</p>
|
||||
<p><strong>Was bedeutet das konkret für ein deutsches
|
||||
E-Commerce-Unternehmen, das eine Webseite betreibt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – rechtliche Pflicht zur Barrierefreiheit.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – der EAA erstellt eine rechtliche Verpflichtung für bestimmte Sektoren.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Die Webseite <strong>muss barrierefreiheitstechnisch</strong> WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – TCP/IP Schichten: Protokoll → Schicht ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q7 – TCP/IP: Protokoll → Schicht</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>HTTP</text><match>Anwendung</match></answer>
|
||||
<answer fraction="100"><text>TCP</text><match>Transport</match></answer>
|
||||
<answer fraction="100"><text>IP</text><match>Internet</match></answer>
|
||||
<answer fraction="100"><text>Ethernet</text><match>Netzzugang</match></answer>
|
||||
<answer fraction="100"><text>DNS</text><match>Anwendung</match></answer>
|
||||
<answer fraction="100"><text>UDP</text><match>Transport</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – Encapsulation: D-S-P-F ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q8 – Encapsulation: Dateneinheit → Schicht</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Bei der Übertragung wird eine Nachricht von Schicht zu Schicht
|
||||
verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige
|
||||
Schicht zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>Daten</text><match>Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).</match></answer>
|
||||
<answer fraction="100"><text>Segment</text><match>Transportschicht – Daten + Ports und Sequenznummern.</match></answer>
|
||||
<answer fraction="100"><text>Paket</text><match>Internetschicht – Segment + IP-Adressen (Quelle und Ziel).</match></answer>
|
||||
<answer fraction="100"><text>Frame</text><match>Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – IP vs MAC vs Port Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q9 – IP vs. MAC vs. Port: Transfer-Szenario</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in
|
||||
einem anderen Land. Das Paket durchläuft mehrere Router.</p>
|
||||
<p><strong>Welche der folgenden Aussagen über die Adressen auf dem
|
||||
Weg ist korrekt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – nur MAC ändert sich unterwegs.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche Adresse bei jedem Hop neu gesetzt wird.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Die <strong>IP-Adresse</strong> des Servers bleibt konstant, der <strong>Port</strong> (443) ändert sich nicht – die <strong>MAC-Adresse</strong> wird an jedem Router neu gesetzt (lokal, ein Hop).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – 3-Way Handshake: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q10 – TCP 3-Way-Handshake: Was passiert wäre?</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der Client sendet ein <strong>SYN</strong> zum Server.
|
||||
Das SYN-Paket geht verloren – es erreicht den Server nie.</p>
|
||||
<p><strong>Was passiert als nächstes, und warum wird keine
|
||||
Verbindung aufgebaut?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – ohne SYN beim Server: kein SYN-ACK, kein Handshake.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was der Server ohne SYN tun kann.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Der Server kennt die Anfrage nicht → sendet <strong>kein SYN-ACK</strong> → der Client erhält keine Antwort → <strong>keine Verbindung</strong>. Der Client wird das SYN nach einem Timeout erneut senden.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – TCP vs UDP Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q11 – TCP vs. UDP: Videostreaming</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Videostreaming-Dienst sendet Daten an deinen Browser.
|
||||
Ein einzelnes Paket geht verloren.</p>
|
||||
<p><strong>Warum wählt der Dienst <strong>UDP</strong> statt TCP,
|
||||
obwohl ein Paket verloren geht?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – bei Echtzeit ist Verzögerung ärger als Verlust.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was TCP bei einem verlorenen Paket tun würde.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Bei <strong>Echtzeit</strong> ist Verzögerung schlimmer als Verlust. TCP würde das Paket <strong>erneut anfordern</strong> → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTTP Methoden: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q12 – HTTP-Methoden: Szenario</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Nutzer aktualisiert sein Profilbild auf einer Webseite.
|
||||
Das Foto wird zum Server gesendet und das <strong>alte Bild
|
||||
ersetzt</strong>.</p>
|
||||
<p><strong>Welche HTTP-Methode wird für diese Operation verwendet,
|
||||
und warum nicht GET?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – PUT für das Ersetzen einer Ressource.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was „ersetzen" in HTTP bedeutet.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>PUT</strong> – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet <em>keine</em> Daten zum Server.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>GET</strong> – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>POST</strong> – POST ist immer für das Ersetzen von Daten zuständig.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>DELETE</strong> – DELETE sendet das neue Foto und löscht gleichzeitig das alte.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTTP Status-Codes Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q13 – HTTP Status-Codes: Fehlerdiagnose</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du rufst eine Webseite auf und der Browser zeigt folgende
|
||||
Fehlermeldung an:</p>
|
||||
<pre>HTTP/1.1 503 Service Unavailable</pre>
|
||||
<p><strong>Was bedeutet dieser Code, und wer ist für die Behebung
|
||||
zuständig – du oder der Betreiber der Webseite?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – 5xx = Server-Problem, nicht dein Fehler.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was die Ziffer „5" im Code bedeutet.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Server-Fehler:</strong> Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim <strong>Betreiber</strong> – du kannst nur später erneut versuchen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – DNS Ablauf Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q14 – DNS: Rolle im Ablauf</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du gibst <code>https://hdm-stuttgart.de</code> in die
|
||||
Adresszeile ein.</p>
|
||||
<p><strong>Was passiert <em>vor</em> dem TCP-Handshake, und warum
|
||||
ist dieser Schritt zwingend nötig?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – DNS vor TCP, Name → IP.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was TCP als Zieladresse braucht.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>DNS-Auflösung:</strong> Der Name <code>hdm-stuttgart.de</code> wird in eine <strong>IP-Adresse</strong> umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – CSS Spezifität Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q15 – CSS Spezifität: Welche Regel gewinnt?</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Gegeben folgender CSS-Code:</p>
|
||||
<pre>
|
||||
p { color: blue; } /* (A) */
|
||||
.highlight { color: green; } /* (B) */
|
||||
#main { color: red; } /* (C) */
|
||||
</pre>
|
||||
<p>Ein Element <code><p class="highlight" id="main">Text</p></code>
|
||||
wird angezeigt.<br>
|
||||
<strong>Welche Farbe zeigt der Text an, und warum?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – ID gewinnt durch höchste Spezifität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege die Spezifitätswerte: ID > Klasse > Element.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – die ID-Regel <code>#main</code> hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die Element-Regel steht zuerst im Code und hat daher Vorrang.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – Klassen-Selektoren haben immer Vorrang vor IDs.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Rot</strong> – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Responsive Design Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q16 – Responsive Design: Mobile First</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Developer schreibt folgendes CSS:</p>
|
||||
<pre>
|
||||
.container { background: white; }
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.container { background: blue; }
|
||||
}
|
||||
|
||||
@media (min-width: 1024px) {
|
||||
.container { background: green; }
|
||||
}
|
||||
</pre>
|
||||
<p><strong>Welche Farbe hat <code>.container</code> bei einem
|
||||
Bildschirm von 900 px Breite, und warum?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – 768px greift, 1024px nicht.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche min-width-Bedingungen bei 900px erfüllt sind.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Blau</strong> – bei 900 px greift <code>min-width: 768px</code> (900 ≥ 768), aber <code>min-width: 1024px</code> greift nicht (900 < 1024).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – die letzte Media-Query überschreibt immer alle vorherigen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 1 pt – Zusammen: Der Ablauf eines Klicks ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du gibst eine URL ein. <strong>Welche Reihenfolge der Schritte
|
||||
ist korrekt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).</text></generalfeedback>
|
||||
<defaultgrade>1</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – DNS → TCP → HTTP Request → HTTP Response.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – an erster Stelle steht immer die DNS-Auflösung.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 1 pt – Bonusfrage: Spezifität Edge Case ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q18 – CSS: 100 Element-Selektoren vs. 1 Klasse</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Es gibt zwei CSS-Regeln für ein <code><p></code>-Element:</p>
|
||||
<pre>
|
||||
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
|
||||
.highlight { color: red; } /* 1× Klasse */
|
||||
</pre>
|
||||
<p>Das Element hat die Klasse <code>highlight</code>.
|
||||
<strong>Welche Farbe gewinnt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.</text></generalfeedback>
|
||||
<defaultgrade>1</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – eine Klasse gewinnt immer gegen beliebig viele Elemente.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – Spezifität funktioniert nicht durch Addition innerhalb einer Stelle.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Unentschieden – die Regeln haben exakt gleiche Spezifität.]]></text></answer>
|
||||
</question>
|
||||
|
||||
</quiz>
|
||||
File diff suppressed because it is too large.
Load diff
@@ -1,439 +0,0 @@
|
||||
Here is the quiz converted into a clean, readable Markdown format. I have preserved the structure, code snippets, and feedback for each question.
|
||||
|
||||
---
|
||||
|
||||
# 223015c – Grundlagen IT- und Internettechnik
|
||||
|
||||
**WS 2025/26 – Michael Czechowski – HdM Stuttgart**
|
||||
**40 Punkte / 40 Minuten**
|
||||
|
||||
---
|
||||
|
||||
### Q1 – Von-Neumann: Komponenten zuordnen (3 pt)
|
||||
|
||||
**Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.**
|
||||
|
||||
* **Rechenwerk (ALU):** Führt arithmetische und logische Operationen durch.
|
||||
* **Steuerwerk:** Holt, dekodiert und steuert die Ausführung von Befehlen.
|
||||
* **Speicherwerk:** Enthält sowohl Programme als auch Daten (Stored Program Concept).
|
||||
* **Ein-/Ausgabe:** Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.
|
||||
* **Bus-System:** Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.
|
||||
|
||||
> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
|
||||
|
||||
---
|
||||
|
||||
### Q2 – Von-Neumann vs. Harvard (2 pt)
|
||||
|
||||
**Ein Arduino-Mikrocontroller nutzt die Harvard-Architektur. Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.**
|
||||
|
||||
**Warum ist die Harvard-Architektur für Echtzeit-Anwendungen auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn das Smartphone diese Architektur verwenden würde?**
|
||||
|
||||
* [ ] Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.
|
||||
* [x] **Harvard nutzt separate Speicher für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.** ✅
|
||||
* [ ] Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.
|
||||
* [ ] Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.
|
||||
|
||||
> **Feedback:** Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.
|
||||
|
||||
---
|
||||
|
||||
### Q3 – Stored Program Concept (2 pt)
|
||||
|
||||
**Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem ENIAC Programme durch Umstecken von Kabeln eingegeben werden.**
|
||||
|
||||
**Was konkret ermöglicht das Stored Program Concept, was vorher nicht möglich war? Nenne zwei Beispiele.**
|
||||
|
||||
* [ ] Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.
|
||||
* [ ] Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.
|
||||
* [x] **Programme werden als Daten im Speicher abgelegt → z. B. Apps können installiert/gelöscht werden und Multitasking (mehrere Programme gleichzeitig) wird möglich.** ✅
|
||||
* [ ] Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.
|
||||
|
||||
> **Feedback:** Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.
|
||||
|
||||
---
|
||||
|
||||
### Q4 – HTML: `<head>` vs. `<body>` (2 pt)
|
||||
|
||||
**Ein Student erstellt eine Webseite und platziert *alles* im `<body>` – auch den `<title>` und die `<meta name="description">`.**
|
||||
|
||||
**Welche zwei konkreten Konsequenzen hat das?**
|
||||
|
||||
* [ ] Kein Problem – Browser ignorieren die Unterscheidung zwischen `<head>` und `<body>`.
|
||||
* [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.** ✅
|
||||
* [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
|
||||
* [ ] Nur das Fehlen von `<meta charset>` ist ein Problem – title und description funktionieren überall.
|
||||
|
||||
> **Feedback:** title und meta description gehören in `<head>`. Im `<body>`: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.
|
||||
|
||||
---
|
||||
|
||||
### Q5 – Barrierefreiheit: Curb-Cut-Effekt (3 pt)
|
||||
|
||||
**Der Curb-Cut-Effekt beschreibt, wie eine barrierefreie Lösung – ursprünglich für Menschen mit Behinderung – letztendlich *allen* zugute kommt.**
|
||||
|
||||
**Nenne ein konkretes Web-Beispiel, das diesen Effekt demonstriert, und erkläre, wer davon profitiert.**
|
||||
|
||||
* [ ] Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.
|
||||
* [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
|
||||
* [x] **Untertitel: Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.** ✅
|
||||
* [ ] **Dark Mode:** Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.
|
||||
|
||||
> **Feedback:** Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.
|
||||
|
||||
---
|
||||
|
||||
### Q6 – European Accessibility Act (2 pt)
|
||||
|
||||
**Der European Accessibility Act (EAA) ist seit Juni 2025 in Kraft.**
|
||||
|
||||
**Was bedeutet das konkret für ein deutsches E-Commerce-Unternehmen, das eine Webseite betreibt?**
|
||||
|
||||
* [ ] Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.
|
||||
* [ ] Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.
|
||||
* [x] **Die Webseite muss barrierefreiheitstechnisch WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.** ✅
|
||||
* [ ] Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.
|
||||
|
||||
> **Feedback:** EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.
|
||||
|
||||
---
|
||||
|
||||
### Q7 – TCP/IP: Protokoll → Schicht (3 pt)
|
||||
|
||||
**Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.**
|
||||
|
||||
* **HTTP:** Anwendung
|
||||
* **DNS:** Anwendung
|
||||
* **TCP:** Transport
|
||||
* **UDP:** Transport
|
||||
* **IP:** Internet
|
||||
* **Ethernet:** Netzzugang
|
||||
|
||||
> **Feedback:** Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
|
||||
|
||||
---
|
||||
|
||||
### Q8 – Encapsulation: Dateneinheit → Schicht (3 pt)
|
||||
|
||||
**Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige Schicht zu.**
|
||||
|
||||
* **Daten:** Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).
|
||||
* **Segment:** Transportschicht – Daten + Ports und Sequenznummern.
|
||||
* **Paket:** Internetschicht – Segment + IP-Adressen (Quelle und Ziel).
|
||||
* **Frame:** Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.
|
||||
|
||||
> **Feedback:** Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.
|
||||
|
||||
---
|
||||
|
||||
### Q9 – IP vs. MAC vs. Port: Transfer-Szenario (3 pt)
|
||||
|
||||
**Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in einem anderen Land. Das Paket durchläuft mehrere Router.**
|
||||
|
||||
**Welche der folgenden Aussagen über die Adressen auf dem Weg ist korrekt?**
|
||||
|
||||
* [ ] Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.
|
||||
* [x] **Die IP-Adresse des Servers bleibt konstant, der Port (443) ändert sich nicht – die MAC-Adresse wird an jedem Router neu gesetzt (lokal, ein Hop).** ✅
|
||||
* [ ] Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.
|
||||
* [ ] IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.
|
||||
|
||||
> **Feedback:** IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.
|
||||
|
||||
---
|
||||
|
||||
### Q10 – TCP 3-Way-Handshake: Was passiert wäre? (3 pt)
|
||||
|
||||
**Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie.**
|
||||
|
||||
**Was passiert als nächstes, und warum wird keine Verbindung aufgebaut?**
|
||||
|
||||
* [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.
|
||||
* [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client wird das SYN nach einem Timeout erneut senden.** ✅
|
||||
* [ ] Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.
|
||||
* [ ] Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.
|
||||
|
||||
> **Feedback:** Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).
|
||||
|
||||
---
|
||||
|
||||
### Q11 – TCP vs. UDP: Videostreaming (2 pt)
|
||||
|
||||
**Ein Videostreaming-Dienst sendet Daten an deinen Browser. Ein einzelnes Paket geht verloren.**
|
||||
|
||||
**Warum wählt der Dienst UDP statt TCP, obwohl ein Paket verloren geht?**
|
||||
|
||||
* [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
|
||||
* [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
|
||||
* [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
|
||||
* [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
|
||||
|
||||
> **Feedback:** Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.
|
||||
|
||||
---
|
||||
|
||||
### Q12 – HTTP-Methoden: Szenario (2 pt)
|
||||
|
||||
**Ein Nutzer aktualisiert sein Profilbild auf einer Webseite. Das Foto wird zum Server gesendet und das *alte Bild ersetzt*.**
|
||||
|
||||
**Welche HTTP-Methode wird für diese Operation verwendet, und warum nicht GET?**
|
||||
|
||||
* [ ] **GET** – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.
|
||||
* [x] **PUT – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet *keine* Daten zum Server.** ✅
|
||||
* [ ] **POST** – POST ist immer für das Ersetzen von Daten zuständig.
|
||||
* [ ] **DELETE** – DELETE sendet das neue Foto und löscht gleichzeitig das alte.
|
||||
|
||||
> **Feedback:** PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.
|
||||
|
||||
---
|
||||
|
||||
### Q13 – HTTP Status-Codes: Fehlerdiagnose (2 pt)
|
||||
|
||||
**Du rufst eine Webseite auf und der Browser zeigt folgende Fehlermeldung an:**
|
||||
`HTTP/1.1 503 Service Unavailable`
|
||||
|
||||
**Was bedeutet dieser Code, und wer ist für die Behebung zuständig – du oder der Betreiber der Webseite?**
|
||||
|
||||
* [ ] Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.
|
||||
* [ ] Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.
|
||||
* [x] **Server-Fehler: Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Betreiber – du kannst nur später erneut versuchen.** ✅
|
||||
* [ ] Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.
|
||||
|
||||
> **Feedback:** 503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.
|
||||
|
||||
---
|
||||
|
||||
### Q14 – DNS: Rolle im Ablauf (2 pt)
|
||||
|
||||
**Du gibst `https://hdm-stuttgart.de` in die Adresszeile ein.**
|
||||
|
||||
**Was passiert *vor* dem TCP-Handshake, und warum ist dieser Schritt zwingend nötig?**
|
||||
|
||||
* [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.
|
||||
* [x] **DNS-Auflösung: Der Name `hdm-stuttgart.de` wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.** ✅
|
||||
* [ ] DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.
|
||||
* [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
|
||||
|
||||
> **Feedback:** DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.
|
||||
|
||||
---
|
||||
|
||||
### Q15 – CSS Spezifität: Welche Regel gewinnt? (2 pt)
|
||||
|
||||
**Gegeben folgender CSS-Code:**
|
||||
|
||||
```css
|
||||
p { color: blue; } /* (A) */
|
||||
.highlight { color: green; } /* (B) */
|
||||
#main { color: red; } /* (C) */
|
||||
|
||||
```
|
||||
|
||||
**Ein Element `<p class="highlight" id="main">Text</p>` wird angezeigt.**
|
||||
**Welche Farbe zeigt der Text an, und warum?**
|
||||
|
||||
* [ ] **Blau** – die Element-Regel steht zuerst im Code und hat daher Vorrang.
|
||||
* [ ] **Grün** – Klassen-Selektoren haben immer Vorrang vor IDs.
|
||||
* [x] **Rot – die ID-Regel `#main` hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).** ✅
|
||||
* [ ] **Rot** – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.
|
||||
|
||||
> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.
|
||||
|
||||
---
|
||||
|
||||
### Q16 – Responsive Design: Mobile First (2 pt)
|
||||
|
||||
**Ein Developer schreibt folgendes CSS:**
|
||||
|
||||
```css
|
||||
.container { background: white; }
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.container { background: blue; }
|
||||
}
|
||||
|
||||
@media (min-width: 1024px) {
|
||||
.container { background: green; }
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
**Welche Farbe hat `.container` bei einem Bildschirm von 900 px Breite, und warum?**
|
||||
|
||||
* [ ] **Weiß** – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.
|
||||
* [ ] **Grün** – die letzte Media-Query überschreibt immer alle vorherigen.
|
||||
* [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` greift nicht (900 < 1024).** ✅
|
||||
* [ ] **Weiß** – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.
|
||||
|
||||
> **Feedback:** Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.
|
||||
|
||||
---
|
||||
|
||||
### Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs (1 pt)
|
||||
|
||||
**Du gibst eine URL ein. Welche Reihenfolge der Schritte ist korrekt?**
|
||||
|
||||
* [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
|
||||
* [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
|
||||
* [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
* [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
|
||||
> **Feedback:** Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).
|
||||
|
||||
---
|
||||
|
||||
### Q18 – Bonusfrage: Spezifität Edge Case (1 pt)
|
||||
|
||||
**Es gibt zwei CSS-Regeln für ein `<p>`-Element:**
|
||||
|
||||
```css
|
||||
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
|
||||
.highlight { color: red; } /* 1× Klasse */
|
||||
|
||||
```
|
||||
|
||||
**Das Element hat die Klasse `highlight`. Welche Farbe gewinnt?**
|
||||
|
||||
* [ ] **Blau** – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.
|
||||
* [x] **Rot – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.** ✅
|
||||
* [ ] **Blau** – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.
|
||||
* [ ] Unentschieden – die Regeln haben exakt gleiche Spezifität.
|
||||
|
||||
> **Feedback:** Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.
|
||||
|
||||
---
|
||||
|
||||
### Q19 – Von-Neumann: Der Flaschenhals (Engpass)
|
||||
|
||||
**Die Von-Neumann-Architektur hat einen bekannten Nachteil, den sogenannten „Von-Neumann-Flaschenhals“. Was ist damit gemeint?**
|
||||
|
||||
* [ ] Das Steuerwerk kann Befehle schneller verarbeiten, als das Rechenwerk sie berechnen kann.
|
||||
* [x] **Die CPU ist schneller als der Datentransfer über den gemeinsamen Bus. Da Daten und Befehle denselben Bus nutzen, müssen sie nacheinander geladen werden.** ✅
|
||||
* [ ] Der Speicher verliert seine Daten, wenn der Strom abgeschaltet wird, was den Startvorgang verlangsamt.
|
||||
* [ ] Die Ein-/Ausgabegeräte blockieren den Prozessor dauerhaft, da sie keinen eigenen Speicher haben.
|
||||
|
||||
> **Feedback:** Der Flaschenhals entsteht, weil Befehle und Daten sich den gleichen Weg (Bus) teilen müssen und der Speicherzugriff langsamer ist als die CPU-Geschwindigkeit.
|
||||
|
||||
---
|
||||
|
||||
### Q20 – HTML: Encoding (Charset)
|
||||
|
||||
**In Q4 ging es um Metadaten. Ein weiteres wichtiges Tag im `<head>` ist `<meta charset="UTF-8">`. Was ist die konkrete Konsequenz, wenn dieses Tag fehlt oder falsch ist?**
|
||||
|
||||
* [ ] Die Webseite lädt gar nicht, da der Browser den Binärcode nicht interpretieren kann.
|
||||
* [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole („Hieroglyphen“) dargestellt, da der Browser die falsche Zeichenkodierung rät.** ✅
|
||||
* [ ] Die Seite wird langsamer, da der Browser erst alle Sprachen der Welt durchprobieren muss.
|
||||
* [ ] Das CSS wird nicht geladen, da CSS zwingend UTF-8 voraussetzt.
|
||||
|
||||
> **Feedback:** Ohne definierte `charset` (Zeichensatz) nutzt der Browser oft einen Standard (z. B. Latin-1), was bei UTF-8-gespeicherten Dateien zu Darstellungsfehlern bei ä, ö, ü oder Emojis führt.
|
||||
|
||||
---
|
||||
|
||||
### Q21 – Barrierefreiheit: POUR-Prinzip
|
||||
|
||||
**Die WCAG basieren auf vier Prinzipien (POUR). Eines davon ist „Bedienbarkeit“ (Operable). Welches Szenario beschreibt eine Verletzung dieses Prinzips?**
|
||||
|
||||
* [ ] Der Textkontrast ist zu gering (grau auf hellgrau), sodass man ihn kaum lesen kann.
|
||||
* [x] **Eine Navigation funktioniert nur per Maus (Hover), ist aber per Tastatur (Tab-Taste) nicht erreichbar.** ✅
|
||||
* [ ] Der Inhalt ist in sehr komplizierter Fachsprache geschrieben, die ein Laie nicht versteht.
|
||||
* [ ] Die Webseite stürzt in alten Browsern ab.
|
||||
|
||||
> **Feedback:** „Bedienbar“ bedeutet, dass die Schnittstelle (Buttons, Links) von jedem genutzt werden kann – also auch ohne Maus (nur Tastatur). Kontrast gehört zu „Wahrnehmbar“ (Perceivable).
|
||||
|
||||
---
|
||||
|
||||
### Q22 – Encapsulation: Die Empfänger-Seite (Decapsulation)
|
||||
|
||||
**In Q8 haben wir Daten verpackt. Wenn der Server das Signal empfängt, passiert das Gegenteil (Decapsulation). In welcher Reihenfolge werden die Header *entfernt*?**
|
||||
|
||||
* [ ] Anwendung (HTTP) → Transport (TCP) → Internet (IP) → Netzzugang (Ethernet)
|
||||
* [ ] Es werden alle Header gleichzeitig entfernt, sobald die Daten im RAM liegen.
|
||||
* [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
|
||||
* [ ] Internet (IP) → Netzzugang (Ethernet) → Transport (TCP) → Anwendung (HTTP)
|
||||
|
||||
> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken (Zwiebel-Prinzip). Erst wird der Umschlag (Ethernet) geöffnet, dann das Paket (IP), dann das Segment (TCP).
|
||||
|
||||
---
|
||||
|
||||
### Q23 – Ports: Wozu genau?
|
||||
|
||||
**Wir wissen aus Q9, dass IP-Adressen Computer identifizieren. Wozu genau dient dann die Port-Nummer (z. B. 80 oder 443) auf dem Zielrechner?**
|
||||
|
||||
* [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
|
||||
* [ ] Sie dient zur Verschlüsselung der Daten.
|
||||
* [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver vs. Mailserver).** ✅
|
||||
* [ ] Sie zeigt an, ob der Computer per WLAN oder Kabel verbunden ist.
|
||||
|
||||
> **Feedback:** Die IP ist wie die Hausnummer (welches Gebäude?), der Port ist wie die Türnummer oder der Name an der Klingel (wer im Haus soll das Paket bekommen? Webserver? Mailserver?).
|
||||
|
||||
---
|
||||
|
||||
### Q24 – TCP: Sequenznummern
|
||||
|
||||
**TCP ist zuverlässig. Ein Mechanismus dafür sind „Sequenznummern“ im Header. Welches Problem lösen diese konkret?**
|
||||
|
||||
* [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
|
||||
* [x] **Pakete können im Internet unterschiedliche Routen nehmen und in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
|
||||
* [ ] Sie zählen, wie viele Benutzer gerade gleichzeitig auf dem Server sind.
|
||||
* [ ] Sie bestimmen die maximale Größe einer Datei.
|
||||
|
||||
> **Feedback:** Da IP-Pakete überholen können, kommen Teil 2 und Teil 3 vielleicht vor Teil 1 an. TCP sortiert sie anhand der Nummern wieder richtig. UDP macht das nicht.
|
||||
|
||||
---
|
||||
|
||||
### Q25 – HTTP Methoden: Sicherheit
|
||||
|
||||
**Warum sollte man niemals die GET-Methode verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?**
|
||||
|
||||
* [ ] GET ist langsamer als POST und Passwörter müssen schnell übertragen werden.
|
||||
* [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST stehen sie im Body.** ✅
|
||||
* [ ] GET erlaubt nur Zahlen, keine Buchstaben.
|
||||
* [ ] GET-Anfragen werden vom Server nicht verschlüsselt, POST-Anfragen immer.
|
||||
|
||||
> **Feedback:** Parameter bei GET hängen an der URL (`?pw=123`). Das ist in der History und in Logs sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL ist an zu vielen Stellen sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### Q26 – HTTP Status: 404 Not Found
|
||||
|
||||
**Du erhältst einen 404-Fehler. In Q13 (503) lag der Fehler beim Server. Wer hat beim 404-Fehler „Schuld“ bzw. wo liegt die Ursache meistens?**
|
||||
|
||||
* [ ] Der Server ist abgestürzt.
|
||||
* [ ] Das Internet ist ausgefallen.
|
||||
* [x] **Der Client (Nutzer). Es wurde eine URL angefordert, die es nicht gibt (Tippfehler oder veralteter Link).** ✅
|
||||
* [ ] Der DNS-Server konnte den Namen nicht auflösen.
|
||||
|
||||
> **Feedback:** 4xx-Codes sind Client-Errors. Der Server funktioniert super, er sagt dir nur: „Das, was du (Client) suchst, habe ich nicht.“
|
||||
|
||||
---
|
||||
|
||||
### Q27 – CSS: `!important` vs. ID
|
||||
|
||||
**In Q15 hat die ID gewonnen. Nun ändern wir den Code:**
|
||||
|
||||
```css
|
||||
#main { color: red; }
|
||||
p { color: blue !important; }
|
||||
|
||||
```
|
||||
|
||||
**Welche Farbe hat das `<p id="main">` Element nun?**
|
||||
|
||||
* [ ] **Rot** – ID ist immer noch spezifischer als ein Element-Selektor.
|
||||
* [ ] **Lila** – Die Farben mischen sich.
|
||||
* [x] **Blau** – `!important` durchbricht die normale Spezifitäts-Kaskade und gewinnt sogar gegen IDs (außer die ID hat auch !important). ✅
|
||||
* [ ] **Rot** – `!important` wird von modernen Browsern ignoriert.
|
||||
|
||||
> **Feedback:** `!important` ist die „Atombombe“ im CSS. Es überschreibt normale Spezifitätsregeln (ID, Klasse, Element). Es sollte daher sehr sparsam eingesetzt werden.
|
||||
|
||||
---
|
||||
|
||||
### Q28 – Responsive Design: Desktop First
|
||||
|
||||
**In Q16 nutzten wir `min-width` (Mobile First). Wie würde die Media Query aussehen, wenn wir „Desktop First“ arbeiten würden (also Standard ist Desktop, Anpassung für kleine Screens)?**
|
||||
|
||||
* [ ] `@media (device-width: small) { ... }`
|
||||
* [ ] `@media (min-width: ...)` – das bleibt gleich, nur die Reihenfolge ändert sich.
|
||||
* [x] **`@media (max-width: ...)` – Wir definieren Stile für Bildschirme, die *kleiner* als eine bestimmte Breite sind.** ✅
|
||||
* [ ] `@media (mobile: true) { ... }`
|
||||
|
||||
> **Feedback:** Desktop First bedeutet: Das Basis-CSS ist für große Schirme. Mit `max-width` (maximale Breite) definieren wir Ausnahmen für Geräte, die schmaler sind (Tablets, Handys).
|
||||
+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/"
|
||||
@@ -41,7 +41,6 @@ TOPIC_MAP["vertiefung-offene-fragen"]="Vertiefung & Offene Fragen"
|
||||
TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
|
||||
TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
|
||||
TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
|
||||
TOPIC_MAP["klausurfragen"]="Klausurfragen"
|
||||
|
||||
# Configure which topics should appear disabled per course
|
||||
# Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
#!/usr/bin/env bash
|
||||
# Generate root index.html for /hdm/
|
||||
# Lists all courses (klausurfragen are now per-course)
|
||||
# Generate root index.html for HdM slides overview
|
||||
# Usage: ./generate-root-index.sh
|
||||
|
||||
BUILD_DIR="build"
|
||||
BUILD_DIR="${1:-build}"
|
||||
|
||||
cat > "$BUILD_DIR/index.html" << 'HEADER'
|
||||
<!DOCTYPE html>
|
||||
@@ -78,31 +78,6 @@ cat > "$BUILD_DIR/index.html" << 'HEADER'
|
||||
margin: 0.25rem 0;
|
||||
}
|
||||
.course-info { font-size: 0.85rem; color: #86868b; }
|
||||
.btn {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
padding: 0.5rem 1rem;
|
||||
border-radius: 8px;
|
||||
text-decoration: none;
|
||||
font-size: 0.8rem;
|
||||
font-weight: 500;
|
||||
transition: all 0.2s;
|
||||
white-space: nowrap;
|
||||
position: relative;
|
||||
z-index: 1;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.btn-slides {
|
||||
background: #6c757d;
|
||||
color: #fff;
|
||||
}
|
||||
.btn-slides:hover { filter: brightness(1.1); }
|
||||
.btn-pdf {
|
||||
background: #f5f5f7;
|
||||
color: #1d1d1f;
|
||||
}
|
||||
.btn-pdf:hover { background: #e8e8ed; }
|
||||
.section-title {
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
@@ -137,7 +112,6 @@ cat > "$BUILD_DIR/index.html" << 'HEADER'
|
||||
@media (max-width: 600px) {
|
||||
.course-card { grid-template-columns: 1fr; }
|
||||
.course-link { padding-bottom: 0.75rem; }
|
||||
.btn { margin: 0 1rem 1rem 1.5rem; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
@@ -149,19 +123,16 @@ cat > "$BUILD_DIR/index.html" << 'HEADER'
|
||||
<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>
|
||||
<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>
|
||||
<span class="course-info">3 Kapitel · Modul "Technik 1"</span>
|
||||
</a>
|
||||
</div>
|
||||
HEADER
|
||||
|
||||
cat >> "$BUILD_DIR/index.html" << 'FOOTER'
|
||||
</div>
|
||||
<h2 class="section-title">Referenzen</h2>
|
||||
<div class="references">
|
||||
@@ -182,6 +153,6 @@ cat >> "$BUILD_DIR/index.html" << 'FOOTER'
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
FOOTER
|
||||
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
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
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
|
||||
|
||||
<!--
|
||||
|
||||
@@ -48,7 +48,7 @@ section.disable {
|
||||
# Klausurfragen – 223015b
|
||||
**Dateiformate, Schnittstellen, Speichermedien · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 02.02.2026</small>
|
||||
<small>Stand: 01.02.2026</small>
|
||||
|
||||
---
|
||||
|
||||
@@ -60,7 +60,7 @@ section.disable {
|
||||
> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
|
||||
> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
|
||||
> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
|
||||
> `[CLOZE]` = `cloze` (Lückentext, gemischt)
|
||||
> `[CLOZE]` = `cloze` (Lückentext, gemischt)`
|
||||
|
||||
---
|
||||
|
||||
@@ -922,8 +922,6 @@ Wie viele Farben kann ein GIF-Bild gleichzeitig anzeigen?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M4 – WebP vs. JPEG: Vorteil?
|
||||
**Thema:** Bildformate – WebP
|
||||
**Punkte:** 1
|
||||
@@ -1167,8 +1165,6 @@ Eine Festplatte wird als „1 TB" vermarktet, aber Windows zeigt nur ~931 GB an.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O2 – HDD vs. SSD: Kern-Unterschied
|
||||
**Thema:** Speichermedien – HDD vs. SSD
|
||||
**Punkte:** 1
|
||||
@@ -1185,8 +1181,6 @@ Was ist der fundamentale technische Unterschied zwischen HDD und SSD?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O3 – HDD vs. SSD: Eigenschaften zuordnen
|
||||
**Thema:** Speichermedien – Vergleich
|
||||
**Punkte:** 2
|
||||
|
||||
@@ -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: '' -->
|
||||
|
||||
@@ -668,27 +771,6 @@ Die Frage: Wer entscheidet, was mit Technologie gemacht wird? Die Entwickler? Di
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Von-Neumann-Architektur: Erklaerung
|
||||
|
||||
**Definition:** Das revolutionaere Prinzip, dass Programme und Daten im selben Speicher liegen und Programme somit wie Daten behandelt werden koennen.
|
||||
|
||||
**Kernpunkte:**
|
||||
- **Stored Program Concept:** Programme sind austauschbare Daten
|
||||
- **Universalrechner:** Gleiche Hardware fuer beliebige Aufgaben
|
||||
- **Software-Flexibilitaet:** Programme koennen geladen, geaendert und geloescht werden
|
||||
|
||||
**Vorher (ENIAC):** Programmierung durch Umstecken von Kabeln → Tage fuer jedes neue Programm
|
||||
|
||||
**Nachher:** Software als austauschbare Datei → Betriebssysteme, Apps, Updates moeglich
|
||||
|
||||
**Harvard-Architektur (Alternative):** Getrennter Speicher fuer Code und Daten → schneller, aber weniger flexibel (Arduino, DSPs)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Vom Militär zum Netz
|
||||
@@ -760,11 +842,6 @@ ARPANET-Karte 1969
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
ARPANET-Karte 1969
|
||||
4 Knoten: UCLA, Stanford, UCSB, Utah
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das WWW (1989)
|
||||
@@ -787,6 +864,14 @@ WWW war NICHT kommerziell geplant!
|
||||
Kostenlos freigegeben → darum existiert es
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
@@ -871,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?**
|
||||
@@ -903,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
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -954,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
|
||||
@@ -1658,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
|
||||
|
||||
---
|
||||
@@ -1669,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 |
@@ -48,7 +48,7 @@ section.disable {
|
||||
# Klausurfragen – 223015c
|
||||
**IT-Grundlagen · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 02.02.2026</small>
|
||||
<small>Stand: 01.02.2026</small>
|
||||
|
||||
---
|
||||
|
||||
@@ -60,7 +60,7 @@ section.disable {
|
||||
> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
|
||||
> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
|
||||
> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
|
||||
> `[CLOZE]` = `cloze` (Lückentext, gemischt)
|
||||
> `[CLOZE]` = `cloze` (Lückentext, gemischt)`
|
||||
|
||||
---
|
||||
|
||||
@@ -138,7 +138,6 @@ Erklären Sie die fünf Komponenten der Von-Neumann-Architektur: **Rechenwerk (A
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK B – Netzwerk-Grundlagen (TCP/IP)
|
||||
@@ -697,7 +696,7 @@ Was ist die Hauptfunktion eines DNS-Servers?
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D2-alt – DNS: Zeitlicher Ablauf
|
||||
### D2 – DNS: Zeitlicher Ablauf
|
||||
**Thema:** DNS – Rolle im Gesamtablauf
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
@@ -995,7 +994,6 @@ Erklären Sie die drei Typen von Einschränkungen: **permanent**, **temporär**
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### H3 – Curb-Cut-Effekt: Beispiel identifizieren
|
||||
|
||||
Reference in new issue
Block a user