Compare commits
14
Commits
4245ea2567
...
test-merge
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
8d5c57d561 | ||
|
|
3a2e1a8d15 | ||
|
|
ac89d69365 | ||
|
|
552949811e | ||
|
|
030bb322a2 | ||
|
|
9631a1c45b | ||
|
|
64f4729f45 | ||
|
|
c35541961e | ||
|
|
d8f68183f3 | ||
|
|
705c5e3457 | ||
|
|
9b0b6bc9d6 | ||
|
|
62cd97c51a | ||
|
|
9f2c78d536 | ||
|
|
fb0db03db9 |
No files matched your search
@@ -12,6 +12,7 @@ This project builds presentation decks for Marp, supporting multiple courses.
|
||||
- Agent NEVER runs commands outside this folder
|
||||
- Agent NEVER runs build/deploy commands without explicit user request
|
||||
- Agent NEVER runs deploy commands (make deploy, scp, etc.) without explicit user permission
|
||||
- Agent NEVER runs `git checkout --` or `git restore` on files with uncommitted work. To undo specific changes, use targeted Edit operations instead.
|
||||
|
||||
## Critical File Protection
|
||||
|
||||
@@ -48,10 +49,7 @@ make deploy # Deploy all (ASK FIRST!)
|
||||
## Nix Flake Commands
|
||||
|
||||
```bash
|
||||
nix develop # Dev shell with all tools
|
||||
nix run .#qr -- "https://example.com" # Generate QR code
|
||||
nix run .#qr-slides -- 223015b # QR for course
|
||||
nix run .#optimize-img -- <path> # Optimize images
|
||||
nix develop # Dev shell with all tools (node 22, npm, make)
|
||||
```
|
||||
|
||||
## Code Style Guidelines
|
||||
|
||||
@@ -0,0 +1,469 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<quiz>
|
||||
|
||||
<!-- ============================================================
|
||||
223015c – Grundlagen IT- und Internettechnik
|
||||
40 Punkte / 40 Minuten
|
||||
Michael Czechowski – HdM Stuttgart – WS 2025/26
|
||||
============================================================ -->
|
||||
|
||||
<!-- ─── 3 pt – Von-Neumann: 5 Komponenten ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q1 – Von-Neumann: Komponenten zuordnen</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ordne jeder Komponente der Von-Neumann-Architektur ihre
|
||||
Funktion zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>Rechenwerk (ALU)</text><match>Führt arithmetische und logische Operationen durch.</match></answer>
|
||||
<answer fraction="100"><text>Steuerwerk</text><match>Holt, dekodiert und steuert die Ausführung von Befehlen.</match></answer>
|
||||
<answer fraction="100"><text>Speicherwerk</text><match>Enthält sowohl Programme als auch Daten (Stored Program Concept).</match></answer>
|
||||
<answer fraction="100"><text>Ein-/Ausgabe</text><match>Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.</match></answer>
|
||||
<answer fraction="100"><text>Bus-System</text><match>Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Von-Neumann vs Harvard: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q2 – Von-Neumann vs. Harvard</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Arduino-Mikrocontroller nutzt die <strong>Harvard-Architektur</strong>.
|
||||
Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.</p>
|
||||
<p><strong>Warum ist die Harvard-Architektur für Echtzeit-Anwendungen
|
||||
auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn
|
||||
das Smartphone diese Architektur verwenden würde?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Speed vs. Flexibilität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was getrennte Speicher für Code und Daten bedeuten.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Harvard nutzt <strong>separate Speicher</strong> für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Stored Program Concept Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q3 – Stored Program Concept</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem
|
||||
ENIAC Programme durch <strong>Umstecken von Kabeln</strong> eingegeben
|
||||
werden.</p>
|
||||
<p><strong>Was konkret ermöglicht das Stored Program Concept, was
|
||||
vorher nicht möglich war? Nenne zwei Beispiele.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Programme als Daten im Speicher = Flexibilität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – der Kern liegt darin, dass Programme im Speicher als Daten residieren.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Programme werden als <strong>Daten im Speicher</strong> abgelegt → z. B. Apps können installiert/gelöscht werden und <strong>Multitasking</strong> (mehrere Programme gleichzeitig) wird möglich.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTML Metadaten: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q4 – HTML: <head> vs. <body></text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Student erstellt eine Webseite und platziert <em>alles</em>
|
||||
im <code><body></code> – auch den <code><title></code>
|
||||
und die <code><meta name="description"></code>.</p>
|
||||
<p><strong>Welche zwei konkreten Konsequenzen hat das?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>title und meta description gehören in <head>. Im <body>: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Metadaten im Body werden nicht als solche interpretiert.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – <head> und <body> haben spezifische Funktionen.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[(1) Der Browser-Tab zeigt <strong>keinen Titel</strong> an. (2) Suchmaschinen haben <strong>keine Beschreibung</strong> für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Kein Problem – Browser ignorieren die Unterscheidung zwischen <code><head></code> und <code><body></code>.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Nur das Fehlen von <code><meta charset></code> ist ein Problem – title und description funktionieren überall.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – Accessibility Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q5 – Barrierefreiheit: Curb-Cut-Effekt</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der <strong>Curb-Cut-Effekt</strong> beschreibt, wie eine
|
||||
barrierefreie Lösung – ursprünglich für Menschen mit Behinderung –
|
||||
letztendlich <em>allen</em> zugute kommt.</p>
|
||||
<p><strong>Nenne ein konkretes Web-Beispiel, das diesen Effekt
|
||||
demonstriert, und erkläre, wer davon profitiert.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Barrierefreiheit hilft allen.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche barrierefreien Maßnahmen auch Menschen ohne Behinderung nutzen.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Untertitel:</strong> Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Dark Mode:</strong> Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – EAA / WCAG ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q6 – European Accessibility Act</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der <strong>European Accessibility Act (EAA)</strong> ist seit
|
||||
Juni 2025 in Kraft.</p>
|
||||
<p><strong>Was bedeutet das konkret für ein deutsches
|
||||
E-Commerce-Unternehmen, das eine Webseite betreibt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – rechtliche Pflicht zur Barrierefreiheit.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – der EAA erstellt eine rechtliche Verpflichtung für bestimmte Sektoren.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Die Webseite <strong>muss barrierefreiheitstechnisch</strong> WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – TCP/IP Schichten: Protokoll → Schicht ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q7 – TCP/IP: Protokoll → Schicht</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>HTTP</text><match>Anwendung</match></answer>
|
||||
<answer fraction="100"><text>TCP</text><match>Transport</match></answer>
|
||||
<answer fraction="100"><text>IP</text><match>Internet</match></answer>
|
||||
<answer fraction="100"><text>Ethernet</text><match>Netzzugang</match></answer>
|
||||
<answer fraction="100"><text>DNS</text><match>Anwendung</match></answer>
|
||||
<answer fraction="100"><text>UDP</text><match>Transport</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – Encapsulation: D-S-P-F ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q8 – Encapsulation: Dateneinheit → Schicht</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Bei der Übertragung wird eine Nachricht von Schicht zu Schicht
|
||||
verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige
|
||||
Schicht zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>Daten</text><match>Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).</match></answer>
|
||||
<answer fraction="100"><text>Segment</text><match>Transportschicht – Daten + Ports und Sequenznummern.</match></answer>
|
||||
<answer fraction="100"><text>Paket</text><match>Internetschicht – Segment + IP-Adressen (Quelle und Ziel).</match></answer>
|
||||
<answer fraction="100"><text>Frame</text><match>Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – IP vs MAC vs Port Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q9 – IP vs. MAC vs. Port: Transfer-Szenario</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in
|
||||
einem anderen Land. Das Paket durchläuft mehrere Router.</p>
|
||||
<p><strong>Welche der folgenden Aussagen über die Adressen auf dem
|
||||
Weg ist korrekt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – nur MAC ändert sich unterwegs.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche Adresse bei jedem Hop neu gesetzt wird.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Die <strong>IP-Adresse</strong> des Servers bleibt konstant, der <strong>Port</strong> (443) ändert sich nicht – die <strong>MAC-Adresse</strong> wird an jedem Router neu gesetzt (lokal, ein Hop).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – 3-Way Handshake: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q10 – TCP 3-Way-Handshake: Was passiert wäre?</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der Client sendet ein <strong>SYN</strong> zum Server.
|
||||
Das SYN-Paket geht verloren – es erreicht den Server nie.</p>
|
||||
<p><strong>Was passiert als nächstes, und warum wird keine
|
||||
Verbindung aufgebaut?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – ohne SYN beim Server: kein SYN-ACK, kein Handshake.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was der Server ohne SYN tun kann.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Der Server kennt die Anfrage nicht → sendet <strong>kein SYN-ACK</strong> → der Client erhält keine Antwort → <strong>keine Verbindung</strong>. Der Client wird das SYN nach einem Timeout erneut senden.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – TCP vs UDP Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q11 – TCP vs. UDP: Videostreaming</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Videostreaming-Dienst sendet Daten an deinen Browser.
|
||||
Ein einzelnes Paket geht verloren.</p>
|
||||
<p><strong>Warum wählt der Dienst <strong>UDP</strong> statt TCP,
|
||||
obwohl ein Paket verloren geht?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – bei Echtzeit ist Verzögerung ärger als Verlust.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was TCP bei einem verlorenen Paket tun würde.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Bei <strong>Echtzeit</strong> ist Verzögerung schlimmer als Verlust. TCP würde das Paket <strong>erneut anfordern</strong> → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTTP Methoden: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q12 – HTTP-Methoden: Szenario</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Nutzer aktualisiert sein Profilbild auf einer Webseite.
|
||||
Das Foto wird zum Server gesendet und das <strong>alte Bild
|
||||
ersetzt</strong>.</p>
|
||||
<p><strong>Welche HTTP-Methode wird für diese Operation verwendet,
|
||||
und warum nicht GET?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – PUT für das Ersetzen einer Ressource.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was „ersetzen" in HTTP bedeutet.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>PUT</strong> – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet <em>keine</em> Daten zum Server.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>GET</strong> – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>POST</strong> – POST ist immer für das Ersetzen von Daten zuständig.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>DELETE</strong> – DELETE sendet das neue Foto und löscht gleichzeitig das alte.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTTP Status-Codes Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q13 – HTTP Status-Codes: Fehlerdiagnose</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du rufst eine Webseite auf und der Browser zeigt folgende
|
||||
Fehlermeldung an:</p>
|
||||
<pre>HTTP/1.1 503 Service Unavailable</pre>
|
||||
<p><strong>Was bedeutet dieser Code, und wer ist für die Behebung
|
||||
zuständig – du oder der Betreiber der Webseite?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – 5xx = Server-Problem, nicht dein Fehler.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was die Ziffer „5" im Code bedeutet.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Server-Fehler:</strong> Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim <strong>Betreiber</strong> – du kannst nur später erneut versuchen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – DNS Ablauf Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q14 – DNS: Rolle im Ablauf</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du gibst <code>https://hdm-stuttgart.de</code> in die
|
||||
Adresszeile ein.</p>
|
||||
<p><strong>Was passiert <em>vor</em> dem TCP-Handshake, und warum
|
||||
ist dieser Schritt zwingend nötig?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – DNS vor TCP, Name → IP.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was TCP als Zieladresse braucht.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>DNS-Auflösung:</strong> Der Name <code>hdm-stuttgart.de</code> wird in eine <strong>IP-Adresse</strong> umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – CSS Spezifität Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q15 – CSS Spezifität: Welche Regel gewinnt?</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Gegeben folgender CSS-Code:</p>
|
||||
<pre>
|
||||
p { color: blue; } /* (A) */
|
||||
.highlight { color: green; } /* (B) */
|
||||
#main { color: red; } /* (C) */
|
||||
</pre>
|
||||
<p>Ein Element <code><p class="highlight" id="main">Text</p></code>
|
||||
wird angezeigt.<br>
|
||||
<strong>Welche Farbe zeigt der Text an, und warum?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – ID gewinnt durch höchste Spezifität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege die Spezifitätswerte: ID > Klasse > Element.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – die ID-Regel <code>#main</code> hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die Element-Regel steht zuerst im Code und hat daher Vorrang.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – Klassen-Selektoren haben immer Vorrang vor IDs.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Rot</strong> – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Responsive Design Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q16 – Responsive Design: Mobile First</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Developer schreibt folgendes CSS:</p>
|
||||
<pre>
|
||||
.container { background: white; }
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.container { background: blue; }
|
||||
}
|
||||
|
||||
@media (min-width: 1024px) {
|
||||
.container { background: green; }
|
||||
}
|
||||
</pre>
|
||||
<p><strong>Welche Farbe hat <code>.container</code> bei einem
|
||||
Bildschirm von 900 px Breite, und warum?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – 768px greift, 1024px nicht.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche min-width-Bedingungen bei 900px erfüllt sind.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Blau</strong> – bei 900 px greift <code>min-width: 768px</code> (900 ≥ 768), aber <code>min-width: 1024px</code> greift nicht (900 < 1024).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – die letzte Media-Query überschreibt immer alle vorherigen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 1 pt – Zusammen: Der Ablauf eines Klicks ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du gibst eine URL ein. <strong>Welche Reihenfolge der Schritte
|
||||
ist korrekt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).</text></generalfeedback>
|
||||
<defaultgrade>1</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – DNS → TCP → HTTP Request → HTTP Response.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – an erster Stelle steht immer die DNS-Auflösung.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 1 pt – Bonusfrage: Spezifität Edge Case ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q18 – CSS: 100 Element-Selektoren vs. 1 Klasse</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Es gibt zwei CSS-Regeln für ein <code><p></code>-Element:</p>
|
||||
<pre>
|
||||
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
|
||||
.highlight { color: red; } /* 1× Klasse */
|
||||
</pre>
|
||||
<p>Das Element hat die Klasse <code>highlight</code>.
|
||||
<strong>Welche Farbe gewinnt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.</text></generalfeedback>
|
||||
<defaultgrade>1</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – eine Klasse gewinnt immer gegen beliebig viele Elemente.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – Spezifität funktioniert nicht durch Addition innerhalb einer Stelle.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Unentschieden – die Regeln haben exakt gleiche Spezifität.]]></text></answer>
|
||||
</question>
|
||||
|
||||
</quiz>
|
||||
File diff suppressed because it is too large.
Load diff
@@ -0,0 +1,439 @@
|
||||
Here is the quiz converted into a clean, readable Markdown format. I have preserved the structure, code snippets, and feedback for each question.
|
||||
|
||||
---
|
||||
|
||||
# 223015c – Grundlagen IT- und Internettechnik
|
||||
|
||||
**WS 2025/26 – Michael Czechowski – HdM Stuttgart**
|
||||
**40 Punkte / 40 Minuten**
|
||||
|
||||
---
|
||||
|
||||
### Q1 – Von-Neumann: Komponenten zuordnen (3 pt)
|
||||
|
||||
**Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.**
|
||||
|
||||
* **Rechenwerk (ALU):** Führt arithmetische und logische Operationen durch.
|
||||
* **Steuerwerk:** Holt, dekodiert und steuert die Ausführung von Befehlen.
|
||||
* **Speicherwerk:** Enthält sowohl Programme als auch Daten (Stored Program Concept).
|
||||
* **Ein-/Ausgabe:** Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.
|
||||
* **Bus-System:** Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.
|
||||
|
||||
> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
|
||||
|
||||
---
|
||||
|
||||
### Q2 – Von-Neumann vs. Harvard (2 pt)
|
||||
|
||||
**Ein Arduino-Mikrocontroller nutzt die Harvard-Architektur. Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.**
|
||||
|
||||
**Warum ist die Harvard-Architektur für Echtzeit-Anwendungen auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn das Smartphone diese Architektur verwenden würde?**
|
||||
|
||||
* [ ] Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.
|
||||
* [x] **Harvard nutzt separate Speicher für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.** ✅
|
||||
* [ ] Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.
|
||||
* [ ] Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.
|
||||
|
||||
> **Feedback:** Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.
|
||||
|
||||
---
|
||||
|
||||
### Q3 – Stored Program Concept (2 pt)
|
||||
|
||||
**Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem ENIAC Programme durch Umstecken von Kabeln eingegeben werden.**
|
||||
|
||||
**Was konkret ermöglicht das Stored Program Concept, was vorher nicht möglich war? Nenne zwei Beispiele.**
|
||||
|
||||
* [ ] Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.
|
||||
* [ ] Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.
|
||||
* [x] **Programme werden als Daten im Speicher abgelegt → z. B. Apps können installiert/gelöscht werden und Multitasking (mehrere Programme gleichzeitig) wird möglich.** ✅
|
||||
* [ ] Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.
|
||||
|
||||
> **Feedback:** Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.
|
||||
|
||||
---
|
||||
|
||||
### Q4 – HTML: `<head>` vs. `<body>` (2 pt)
|
||||
|
||||
**Ein Student erstellt eine Webseite und platziert *alles* im `<body>` – auch den `<title>` und die `<meta name="description">`.**
|
||||
|
||||
**Welche zwei konkreten Konsequenzen hat das?**
|
||||
|
||||
* [ ] Kein Problem – Browser ignorieren die Unterscheidung zwischen `<head>` und `<body>`.
|
||||
* [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.** ✅
|
||||
* [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
|
||||
* [ ] Nur das Fehlen von `<meta charset>` ist ein Problem – title und description funktionieren überall.
|
||||
|
||||
> **Feedback:** title und meta description gehören in `<head>`. Im `<body>`: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.
|
||||
|
||||
---
|
||||
|
||||
### Q5 – Barrierefreiheit: Curb-Cut-Effekt (3 pt)
|
||||
|
||||
**Der Curb-Cut-Effekt beschreibt, wie eine barrierefreie Lösung – ursprünglich für Menschen mit Behinderung – letztendlich *allen* zugute kommt.**
|
||||
|
||||
**Nenne ein konkretes Web-Beispiel, das diesen Effekt demonstriert, und erkläre, wer davon profitiert.**
|
||||
|
||||
* [ ] Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.
|
||||
* [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
|
||||
* [x] **Untertitel: Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.** ✅
|
||||
* [ ] **Dark Mode:** Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.
|
||||
|
||||
> **Feedback:** Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.
|
||||
|
||||
---
|
||||
|
||||
### Q6 – European Accessibility Act (2 pt)
|
||||
|
||||
**Der European Accessibility Act (EAA) ist seit Juni 2025 in Kraft.**
|
||||
|
||||
**Was bedeutet das konkret für ein deutsches E-Commerce-Unternehmen, das eine Webseite betreibt?**
|
||||
|
||||
* [ ] Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.
|
||||
* [ ] Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.
|
||||
* [x] **Die Webseite muss barrierefreiheitstechnisch WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.** ✅
|
||||
* [ ] Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.
|
||||
|
||||
> **Feedback:** EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.
|
||||
|
||||
---
|
||||
|
||||
### Q7 – TCP/IP: Protokoll → Schicht (3 pt)
|
||||
|
||||
**Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.**
|
||||
|
||||
* **HTTP:** Anwendung
|
||||
* **DNS:** Anwendung
|
||||
* **TCP:** Transport
|
||||
* **UDP:** Transport
|
||||
* **IP:** Internet
|
||||
* **Ethernet:** Netzzugang
|
||||
|
||||
> **Feedback:** Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
|
||||
|
||||
---
|
||||
|
||||
### Q8 – Encapsulation: Dateneinheit → Schicht (3 pt)
|
||||
|
||||
**Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige Schicht zu.**
|
||||
|
||||
* **Daten:** Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).
|
||||
* **Segment:** Transportschicht – Daten + Ports und Sequenznummern.
|
||||
* **Paket:** Internetschicht – Segment + IP-Adressen (Quelle und Ziel).
|
||||
* **Frame:** Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.
|
||||
|
||||
> **Feedback:** Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.
|
||||
|
||||
---
|
||||
|
||||
### Q9 – IP vs. MAC vs. Port: Transfer-Szenario (3 pt)
|
||||
|
||||
**Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in einem anderen Land. Das Paket durchläuft mehrere Router.**
|
||||
|
||||
**Welche der folgenden Aussagen über die Adressen auf dem Weg ist korrekt?**
|
||||
|
||||
* [ ] Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.
|
||||
* [x] **Die IP-Adresse des Servers bleibt konstant, der Port (443) ändert sich nicht – die MAC-Adresse wird an jedem Router neu gesetzt (lokal, ein Hop).** ✅
|
||||
* [ ] Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.
|
||||
* [ ] IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.
|
||||
|
||||
> **Feedback:** IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.
|
||||
|
||||
---
|
||||
|
||||
### Q10 – TCP 3-Way-Handshake: Was passiert wäre? (3 pt)
|
||||
|
||||
**Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie.**
|
||||
|
||||
**Was passiert als nächstes, und warum wird keine Verbindung aufgebaut?**
|
||||
|
||||
* [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.
|
||||
* [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client wird das SYN nach einem Timeout erneut senden.** ✅
|
||||
* [ ] Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.
|
||||
* [ ] Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.
|
||||
|
||||
> **Feedback:** Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).
|
||||
|
||||
---
|
||||
|
||||
### Q11 – TCP vs. UDP: Videostreaming (2 pt)
|
||||
|
||||
**Ein Videostreaming-Dienst sendet Daten an deinen Browser. Ein einzelnes Paket geht verloren.**
|
||||
|
||||
**Warum wählt der Dienst UDP statt TCP, obwohl ein Paket verloren geht?**
|
||||
|
||||
* [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
|
||||
* [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
|
||||
* [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
|
||||
* [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
|
||||
|
||||
> **Feedback:** Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.
|
||||
|
||||
---
|
||||
|
||||
### Q12 – HTTP-Methoden: Szenario (2 pt)
|
||||
|
||||
**Ein Nutzer aktualisiert sein Profilbild auf einer Webseite. Das Foto wird zum Server gesendet und das *alte Bild ersetzt*.**
|
||||
|
||||
**Welche HTTP-Methode wird für diese Operation verwendet, und warum nicht GET?**
|
||||
|
||||
* [ ] **GET** – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.
|
||||
* [x] **PUT – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet *keine* Daten zum Server.** ✅
|
||||
* [ ] **POST** – POST ist immer für das Ersetzen von Daten zuständig.
|
||||
* [ ] **DELETE** – DELETE sendet das neue Foto und löscht gleichzeitig das alte.
|
||||
|
||||
> **Feedback:** PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.
|
||||
|
||||
---
|
||||
|
||||
### Q13 – HTTP Status-Codes: Fehlerdiagnose (2 pt)
|
||||
|
||||
**Du rufst eine Webseite auf und der Browser zeigt folgende Fehlermeldung an:**
|
||||
`HTTP/1.1 503 Service Unavailable`
|
||||
|
||||
**Was bedeutet dieser Code, und wer ist für die Behebung zuständig – du oder der Betreiber der Webseite?**
|
||||
|
||||
* [ ] Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.
|
||||
* [ ] Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.
|
||||
* [x] **Server-Fehler: Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Betreiber – du kannst nur später erneut versuchen.** ✅
|
||||
* [ ] Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.
|
||||
|
||||
> **Feedback:** 503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.
|
||||
|
||||
---
|
||||
|
||||
### Q14 – DNS: Rolle im Ablauf (2 pt)
|
||||
|
||||
**Du gibst `https://hdm-stuttgart.de` in die Adresszeile ein.**
|
||||
|
||||
**Was passiert *vor* dem TCP-Handshake, und warum ist dieser Schritt zwingend nötig?**
|
||||
|
||||
* [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.
|
||||
* [x] **DNS-Auflösung: Der Name `hdm-stuttgart.de` wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.** ✅
|
||||
* [ ] DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.
|
||||
* [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
|
||||
|
||||
> **Feedback:** DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.
|
||||
|
||||
---
|
||||
|
||||
### Q15 – CSS Spezifität: Welche Regel gewinnt? (2 pt)
|
||||
|
||||
**Gegeben folgender CSS-Code:**
|
||||
|
||||
```css
|
||||
p { color: blue; } /* (A) */
|
||||
.highlight { color: green; } /* (B) */
|
||||
#main { color: red; } /* (C) */
|
||||
|
||||
```
|
||||
|
||||
**Ein Element `<p class="highlight" id="main">Text</p>` wird angezeigt.**
|
||||
**Welche Farbe zeigt der Text an, und warum?**
|
||||
|
||||
* [ ] **Blau** – die Element-Regel steht zuerst im Code und hat daher Vorrang.
|
||||
* [ ] **Grün** – Klassen-Selektoren haben immer Vorrang vor IDs.
|
||||
* [x] **Rot – die ID-Regel `#main` hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).** ✅
|
||||
* [ ] **Rot** – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.
|
||||
|
||||
> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.
|
||||
|
||||
---
|
||||
|
||||
### Q16 – Responsive Design: Mobile First (2 pt)
|
||||
|
||||
**Ein Developer schreibt folgendes CSS:**
|
||||
|
||||
```css
|
||||
.container { background: white; }
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.container { background: blue; }
|
||||
}
|
||||
|
||||
@media (min-width: 1024px) {
|
||||
.container { background: green; }
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
**Welche Farbe hat `.container` bei einem Bildschirm von 900 px Breite, und warum?**
|
||||
|
||||
* [ ] **Weiß** – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.
|
||||
* [ ] **Grün** – die letzte Media-Query überschreibt immer alle vorherigen.
|
||||
* [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` greift nicht (900 < 1024).** ✅
|
||||
* [ ] **Weiß** – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.
|
||||
|
||||
> **Feedback:** Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.
|
||||
|
||||
---
|
||||
|
||||
### Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs (1 pt)
|
||||
|
||||
**Du gibst eine URL ein. Welche Reihenfolge der Schritte ist korrekt?**
|
||||
|
||||
* [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
|
||||
* [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
|
||||
* [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
* [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
|
||||
> **Feedback:** Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).
|
||||
|
||||
---
|
||||
|
||||
### Q18 – Bonusfrage: Spezifität Edge Case (1 pt)
|
||||
|
||||
**Es gibt zwei CSS-Regeln für ein `<p>`-Element:**
|
||||
|
||||
```css
|
||||
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
|
||||
.highlight { color: red; } /* 1× Klasse */
|
||||
|
||||
```
|
||||
|
||||
**Das Element hat die Klasse `highlight`. Welche Farbe gewinnt?**
|
||||
|
||||
* [ ] **Blau** – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.
|
||||
* [x] **Rot – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.** ✅
|
||||
* [ ] **Blau** – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.
|
||||
* [ ] Unentschieden – die Regeln haben exakt gleiche Spezifität.
|
||||
|
||||
> **Feedback:** Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.
|
||||
|
||||
---
|
||||
|
||||
### Q19 – Von-Neumann: Der Flaschenhals (Engpass)
|
||||
|
||||
**Die Von-Neumann-Architektur hat einen bekannten Nachteil, den sogenannten „Von-Neumann-Flaschenhals“. Was ist damit gemeint?**
|
||||
|
||||
* [ ] Das Steuerwerk kann Befehle schneller verarbeiten, als das Rechenwerk sie berechnen kann.
|
||||
* [x] **Die CPU ist schneller als der Datentransfer über den gemeinsamen Bus. Da Daten und Befehle denselben Bus nutzen, müssen sie nacheinander geladen werden.** ✅
|
||||
* [ ] Der Speicher verliert seine Daten, wenn der Strom abgeschaltet wird, was den Startvorgang verlangsamt.
|
||||
* [ ] Die Ein-/Ausgabegeräte blockieren den Prozessor dauerhaft, da sie keinen eigenen Speicher haben.
|
||||
|
||||
> **Feedback:** Der Flaschenhals entsteht, weil Befehle und Daten sich den gleichen Weg (Bus) teilen müssen und der Speicherzugriff langsamer ist als die CPU-Geschwindigkeit.
|
||||
|
||||
---
|
||||
|
||||
### Q20 – HTML: Encoding (Charset)
|
||||
|
||||
**In Q4 ging es um Metadaten. Ein weiteres wichtiges Tag im `<head>` ist `<meta charset="UTF-8">`. Was ist die konkrete Konsequenz, wenn dieses Tag fehlt oder falsch ist?**
|
||||
|
||||
* [ ] Die Webseite lädt gar nicht, da der Browser den Binärcode nicht interpretieren kann.
|
||||
* [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole („Hieroglyphen“) dargestellt, da der Browser die falsche Zeichenkodierung rät.** ✅
|
||||
* [ ] Die Seite wird langsamer, da der Browser erst alle Sprachen der Welt durchprobieren muss.
|
||||
* [ ] Das CSS wird nicht geladen, da CSS zwingend UTF-8 voraussetzt.
|
||||
|
||||
> **Feedback:** Ohne definierte `charset` (Zeichensatz) nutzt der Browser oft einen Standard (z. B. Latin-1), was bei UTF-8-gespeicherten Dateien zu Darstellungsfehlern bei ä, ö, ü oder Emojis führt.
|
||||
|
||||
---
|
||||
|
||||
### Q21 – Barrierefreiheit: POUR-Prinzip
|
||||
|
||||
**Die WCAG basieren auf vier Prinzipien (POUR). Eines davon ist „Bedienbarkeit“ (Operable). Welches Szenario beschreibt eine Verletzung dieses Prinzips?**
|
||||
|
||||
* [ ] Der Textkontrast ist zu gering (grau auf hellgrau), sodass man ihn kaum lesen kann.
|
||||
* [x] **Eine Navigation funktioniert nur per Maus (Hover), ist aber per Tastatur (Tab-Taste) nicht erreichbar.** ✅
|
||||
* [ ] Der Inhalt ist in sehr komplizierter Fachsprache geschrieben, die ein Laie nicht versteht.
|
||||
* [ ] Die Webseite stürzt in alten Browsern ab.
|
||||
|
||||
> **Feedback:** „Bedienbar“ bedeutet, dass die Schnittstelle (Buttons, Links) von jedem genutzt werden kann – also auch ohne Maus (nur Tastatur). Kontrast gehört zu „Wahrnehmbar“ (Perceivable).
|
||||
|
||||
---
|
||||
|
||||
### Q22 – Encapsulation: Die Empfänger-Seite (Decapsulation)
|
||||
|
||||
**In Q8 haben wir Daten verpackt. Wenn der Server das Signal empfängt, passiert das Gegenteil (Decapsulation). In welcher Reihenfolge werden die Header *entfernt*?**
|
||||
|
||||
* [ ] Anwendung (HTTP) → Transport (TCP) → Internet (IP) → Netzzugang (Ethernet)
|
||||
* [ ] Es werden alle Header gleichzeitig entfernt, sobald die Daten im RAM liegen.
|
||||
* [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
|
||||
* [ ] Internet (IP) → Netzzugang (Ethernet) → Transport (TCP) → Anwendung (HTTP)
|
||||
|
||||
> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken (Zwiebel-Prinzip). Erst wird der Umschlag (Ethernet) geöffnet, dann das Paket (IP), dann das Segment (TCP).
|
||||
|
||||
---
|
||||
|
||||
### Q23 – Ports: Wozu genau?
|
||||
|
||||
**Wir wissen aus Q9, dass IP-Adressen Computer identifizieren. Wozu genau dient dann die Port-Nummer (z. B. 80 oder 443) auf dem Zielrechner?**
|
||||
|
||||
* [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
|
||||
* [ ] Sie dient zur Verschlüsselung der Daten.
|
||||
* [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver vs. Mailserver).** ✅
|
||||
* [ ] Sie zeigt an, ob der Computer per WLAN oder Kabel verbunden ist.
|
||||
|
||||
> **Feedback:** Die IP ist wie die Hausnummer (welches Gebäude?), der Port ist wie die Türnummer oder der Name an der Klingel (wer im Haus soll das Paket bekommen? Webserver? Mailserver?).
|
||||
|
||||
---
|
||||
|
||||
### Q24 – TCP: Sequenznummern
|
||||
|
||||
**TCP ist zuverlässig. Ein Mechanismus dafür sind „Sequenznummern“ im Header. Welches Problem lösen diese konkret?**
|
||||
|
||||
* [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
|
||||
* [x] **Pakete können im Internet unterschiedliche Routen nehmen und in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
|
||||
* [ ] Sie zählen, wie viele Benutzer gerade gleichzeitig auf dem Server sind.
|
||||
* [ ] Sie bestimmen die maximale Größe einer Datei.
|
||||
|
||||
> **Feedback:** Da IP-Pakete überholen können, kommen Teil 2 und Teil 3 vielleicht vor Teil 1 an. TCP sortiert sie anhand der Nummern wieder richtig. UDP macht das nicht.
|
||||
|
||||
---
|
||||
|
||||
### Q25 – HTTP Methoden: Sicherheit
|
||||
|
||||
**Warum sollte man niemals die GET-Methode verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?**
|
||||
|
||||
* [ ] GET ist langsamer als POST und Passwörter müssen schnell übertragen werden.
|
||||
* [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST stehen sie im Body.** ✅
|
||||
* [ ] GET erlaubt nur Zahlen, keine Buchstaben.
|
||||
* [ ] GET-Anfragen werden vom Server nicht verschlüsselt, POST-Anfragen immer.
|
||||
|
||||
> **Feedback:** Parameter bei GET hängen an der URL (`?pw=123`). Das ist in der History und in Logs sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL ist an zu vielen Stellen sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### Q26 – HTTP Status: 404 Not Found
|
||||
|
||||
**Du erhältst einen 404-Fehler. In Q13 (503) lag der Fehler beim Server. Wer hat beim 404-Fehler „Schuld“ bzw. wo liegt die Ursache meistens?**
|
||||
|
||||
* [ ] Der Server ist abgestürzt.
|
||||
* [ ] Das Internet ist ausgefallen.
|
||||
* [x] **Der Client (Nutzer). Es wurde eine URL angefordert, die es nicht gibt (Tippfehler oder veralteter Link).** ✅
|
||||
* [ ] Der DNS-Server konnte den Namen nicht auflösen.
|
||||
|
||||
> **Feedback:** 4xx-Codes sind Client-Errors. Der Server funktioniert super, er sagt dir nur: „Das, was du (Client) suchst, habe ich nicht.“
|
||||
|
||||
---
|
||||
|
||||
### Q27 – CSS: `!important` vs. ID
|
||||
|
||||
**In Q15 hat die ID gewonnen. Nun ändern wir den Code:**
|
||||
|
||||
```css
|
||||
#main { color: red; }
|
||||
p { color: blue !important; }
|
||||
|
||||
```
|
||||
|
||||
**Welche Farbe hat das `<p id="main">` Element nun?**
|
||||
|
||||
* [ ] **Rot** – ID ist immer noch spezifischer als ein Element-Selektor.
|
||||
* [ ] **Lila** – Die Farben mischen sich.
|
||||
* [x] **Blau** – `!important` durchbricht die normale Spezifitäts-Kaskade und gewinnt sogar gegen IDs (außer die ID hat auch !important). ✅
|
||||
* [ ] **Rot** – `!important` wird von modernen Browsern ignoriert.
|
||||
|
||||
> **Feedback:** `!important` ist die „Atombombe“ im CSS. Es überschreibt normale Spezifitätsregeln (ID, Klasse, Element). Es sollte daher sehr sparsam eingesetzt werden.
|
||||
|
||||
---
|
||||
|
||||
### Q28 – Responsive Design: Desktop First
|
||||
|
||||
**In Q16 nutzten wir `min-width` (Mobile First). Wie würde die Media Query aussehen, wenn wir „Desktop First“ arbeiten würden (also Standard ist Desktop, Anpassung für kleine Screens)?**
|
||||
|
||||
* [ ] `@media (device-width: small) { ... }`
|
||||
* [ ] `@media (min-width: ...)` – das bleibt gleich, nur die Reihenfolge ändert sich.
|
||||
* [x] **`@media (max-width: ...)` – Wir definieren Stile für Bildschirme, die *kleiner* als eine bestimmte Breite sind.** ✅
|
||||
* [ ] `@media (mobile: true) { ... }`
|
||||
|
||||
> **Feedback:** Desktop First bedeutet: Das Basis-CSS ist für große Schirme. Mit `max-width` (maximale Breite) definieren wir Ausnahmen für Geräte, die schmaler sind (Tablets, Handys).
|
||||
@@ -1,5 +1,5 @@
|
||||
{
|
||||
description = "HdM Slides - Marp presentation builder with tools";
|
||||
description = "HdM Slides - Marp presentation builder";
|
||||
|
||||
inputs = {
|
||||
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
|
||||
@@ -9,116 +9,19 @@
|
||||
outputs = { self, nixpkgs, flake-utils }:
|
||||
flake-utils.lib.eachDefaultSystem (system:
|
||||
let
|
||||
pkgs = import nixpkgs { inherit system; config.allowUnfree = true; };
|
||||
|
||||
|
||||
# QR code generator script
|
||||
qr-gen = pkgs.writeShellScriptBin "qr" ''
|
||||
if [ -z "$1" ]; then
|
||||
echo "Usage: qr <url> [output.png]"
|
||||
echo ""
|
||||
echo "Examples:"
|
||||
echo " qr https://example.com"
|
||||
echo " qr https://example.com my-qr.png"
|
||||
echo " qr 'https://librete.ch/hdm/223015b/' slides-qr.png"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
URL="$1"
|
||||
OUTPUT="''${2:-qr-code.png}"
|
||||
|
||||
${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "$URL"
|
||||
echo "Generated: $OUTPUT"
|
||||
'';
|
||||
|
||||
# QR code for course slides
|
||||
qr-slides = pkgs.writeShellScriptBin "qr-slides" ''
|
||||
COURSE="''${1:-223015b}"
|
||||
OUTPUT="''${2:-build/$COURSE/qr-$COURSE.png}"
|
||||
|
||||
mkdir -p "$(dirname "$OUTPUT")"
|
||||
${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "https://librete.ch/hdm/$COURSE/"
|
||||
echo "Generated QR for $COURSE: $OUTPUT"
|
||||
'';
|
||||
|
||||
# Image optimizer script
|
||||
optimize-img = pkgs.writeShellScriptBin "optimize-img" ''
|
||||
if [ -z "$1" ]; then
|
||||
echo "Usage: optimize-img <image-or-directory> [max-width]"
|
||||
echo ""
|
||||
echo "Resizes images to max width (default: 1920px)"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
TARGET="$1"
|
||||
MAX_WIDTH="''${2:-1920}"
|
||||
|
||||
if [ -d "$TARGET" ]; then
|
||||
for img in "$TARGET"/*.{png,jpg,jpeg,webp} 2>/dev/null; do
|
||||
[ -f "$img" ] || continue
|
||||
echo "Optimizing: $(basename "$img")"
|
||||
${pkgs.imagemagick}/bin/magick "$img" -resize "''${MAX_WIDTH}x>" -quality 85 "$img"
|
||||
done
|
||||
elif [ -f "$TARGET" ]; then
|
||||
echo "Optimizing: $TARGET"
|
||||
${pkgs.imagemagick}/bin/magick "$TARGET" -resize "''${MAX_WIDTH}x>" -quality 85 "$TARGET"
|
||||
else
|
||||
echo "Error: $TARGET not found"
|
||||
exit 1
|
||||
fi
|
||||
echo "Done!"
|
||||
'';
|
||||
|
||||
pkgs = import nixpkgs { inherit system; };
|
||||
in {
|
||||
# Development shell with all tools
|
||||
devShells.default = pkgs.mkShell {
|
||||
buildInputs = with pkgs; [
|
||||
nodejs_20
|
||||
nodejs_22
|
||||
nodePackages.npm
|
||||
qrencode
|
||||
imagemagick
|
||||
gnumake
|
||||
claude-code
|
||||
];
|
||||
|
||||
shellHook = ''
|
||||
echo "HdM Slides Development Environment"
|
||||
echo ""
|
||||
echo "Available commands:"
|
||||
echo " make dev-b - Start 223015b dev server (port 1312)"
|
||||
echo " make dev-c - Start 223015c dev server (port 1313)"
|
||||
echo " make build - Build all courses"
|
||||
echo " qr <url> - Generate QR code"
|
||||
echo " qr-slides 223015b - Generate QR for course"
|
||||
echo " optimize-img <dir> - Optimize images"
|
||||
echo ""
|
||||
echo "HdM Slides - run 'make' for available commands"
|
||||
'';
|
||||
};
|
||||
|
||||
# Standalone apps
|
||||
packages = {
|
||||
qr = qr-gen;
|
||||
qr-slides = qr-slides;
|
||||
optimize-img = optimize-img;
|
||||
default = qr-gen;
|
||||
};
|
||||
|
||||
# Direct runnable apps
|
||||
apps = {
|
||||
qr = {
|
||||
type = "app";
|
||||
program = "${qr-gen}/bin/qr";
|
||||
};
|
||||
qr-slides = {
|
||||
type = "app";
|
||||
program = "${qr-slides}/bin/qr-slides";
|
||||
};
|
||||
optimize-img = {
|
||||
type = "app";
|
||||
program = "${optimize-img}/bin/optimize-img";
|
||||
};
|
||||
default = self.apps.${system}.qr;
|
||||
};
|
||||
}
|
||||
);
|
||||
}
|
||||
@@ -41,6 +41,7 @@ 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)
|
||||
@@ -230,7 +231,7 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
<h1>HdM Vorlesungen</h1>
|
||||
<h2 class="course-heading">$TITLE</h2>
|
||||
<p class="subtitle">$SUBTITLE</p>
|
||||
<p class="meta">HdM Stuttgart · Wintersemester 2025/26 · Michael Czechowski</p>
|
||||
<p class="meta">HdM Stuttgart · Sommersemester 2026 · Michael Czechowski</p>
|
||||
</header>
|
||||
<div class="termine">
|
||||
HEADER
|
||||
|
||||
Executable
+187
@@ -0,0 +1,187 @@
|
||||
#!/usr/bin/env bash
|
||||
# Generate root index.html for /hdm/
|
||||
# Lists all courses (klausurfragen are now per-course)
|
||||
|
||||
BUILD_DIR="build"
|
||||
|
||||
cat > "$BUILD_DIR/index.html" << 'HEADER'
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>HdM Vorlesungen</title>
|
||||
<style>
|
||||
* { box-sizing: border-box; margin: 0; padding: 0; }
|
||||
body {
|
||||
font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Segoe UI", Roboto, sans-serif;
|
||||
max-width: 720px;
|
||||
margin: 0 auto;
|
||||
padding: 3rem 1.5rem;
|
||||
background: #fafafa;
|
||||
color: #1d1d1f;
|
||||
line-height: 1.5;
|
||||
}
|
||||
h1 {
|
||||
font-size: 2rem;
|
||||
font-weight: 600;
|
||||
letter-spacing: -0.02em;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
.subtitle { color: #86868b; font-size: 1rem; }
|
||||
.courses {
|
||||
margin-top: 2rem;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
.course-card {
|
||||
position: relative;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
|
||||
transition: all 0.2s ease;
|
||||
display: grid;
|
||||
grid-template-columns: 1fr auto auto;
|
||||
align-items: center;
|
||||
gap: 1rem;
|
||||
}
|
||||
.course-card:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
|
||||
}
|
||||
.course-link {
|
||||
display: block;
|
||||
padding: 1.25rem 1.5rem;
|
||||
text-decoration: none;
|
||||
color: inherit;
|
||||
grid-column: 1;
|
||||
}
|
||||
.course-link::after {
|
||||
content: '';
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
border-radius: 12px;
|
||||
}
|
||||
.course-label {
|
||||
font-size: 0.7rem;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
}
|
||||
.course-b .course-label { color: #1e5f8a; }
|
||||
.course-c .course-label { color: #d63384; }
|
||||
.course-title {
|
||||
font-size: 1.15rem;
|
||||
font-weight: 500;
|
||||
color: #1d1d1f;
|
||||
margin: 0.25rem 0;
|
||||
}
|
||||
.course-info { font-size: 0.85rem; color: #86868b; }
|
||||
.btn {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
padding: 0.5rem 1rem;
|
||||
border-radius: 8px;
|
||||
text-decoration: none;
|
||||
font-size: 0.8rem;
|
||||
font-weight: 500;
|
||||
transition: all 0.2s;
|
||||
white-space: nowrap;
|
||||
position: relative;
|
||||
z-index: 1;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.btn-slides {
|
||||
background: #6c757d;
|
||||
color: #fff;
|
||||
}
|
||||
.btn-slides:hover { filter: brightness(1.1); }
|
||||
.btn-pdf {
|
||||
background: #f5f5f7;
|
||||
color: #1d1d1f;
|
||||
}
|
||||
.btn-pdf:hover { background: #e8e8ed; }
|
||||
.section-title {
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: #86868b;
|
||||
margin-top: 2.5rem;
|
||||
margin-bottom: 0.75rem;
|
||||
}
|
||||
.references {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
footer {
|
||||
margin-top: 2.5rem;
|
||||
padding-top: 1.5rem;
|
||||
border-top: 1px solid #e5e5e7;
|
||||
color: #86868b;
|
||||
font-size: 0.85rem;
|
||||
}
|
||||
footer a { color: #1d1d1f; text-decoration: none; }
|
||||
footer a:hover { text-decoration: underline; }
|
||||
.qr-section {
|
||||
margin-top: 2.5rem;
|
||||
padding: 1.5rem;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
|
||||
text-align: center;
|
||||
}
|
||||
.qr-code { width: 100%; height: auto; }
|
||||
.qr-url { margin-top: 0.75rem; font-size: 0.85rem; color: #86868b; }
|
||||
@media (max-width: 600px) {
|
||||
.course-card { grid-template-columns: 1fr; }
|
||||
.course-link { padding-bottom: 0.75rem; }
|
||||
.btn { margin: 0 1rem 1rem 1.5rem; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>HdM Vorlesungen</h1>
|
||||
<p class="subtitle">Sommersemester 2026 · Michael Czechowski</p>
|
||||
<div class="courses">
|
||||
<div class="course-card course-b">
|
||||
<a href="223015b/" class="course-link">
|
||||
<span class="course-label">223015b</span>
|
||||
<div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div>
|
||||
<span class="course-info">6 Kapitel · Modul "Technik 1"</span>
|
||||
</a>
|
||||
</div>
|
||||
<div class="course-card course-c">
|
||||
<a href="223015c/" class="course-link">
|
||||
<span class="course-label">223015c</span>
|
||||
<div class="course-title">Grundlagen IT- und Internettechnik</div>
|
||||
<span class="course-info">3 Kapitel · Modul "Technik 1"</span>
|
||||
</a>
|
||||
</div>
|
||||
HEADER
|
||||
|
||||
cat >> "$BUILD_DIR/index.html" << 'FOOTER'
|
||||
</div>
|
||||
<h2 class="section-title">Referenzen</h2>
|
||||
<div class="references">
|
||||
<div class="course-card">
|
||||
<a href="https://codecrispi.es/" class="course-link">
|
||||
<span class="course-label">Plattform</span>
|
||||
<div class="course-title">Code Crispies</div>
|
||||
<span class="course-info">Selbstlernplattform</span>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
<div class="qr-section">
|
||||
<img src="qr-root.svg" alt="QR Code" class="qr-code">
|
||||
<p class="qr-url">https://librete.ch/hdm/</p>
|
||||
</div>
|
||||
<footer>
|
||||
<a href="mailto:mail@librete.ch">Kontakt</a>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
FOOTER
|
||||
|
||||
echo "Generated $BUILD_DIR/index.html"
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -82,7 +82,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -114,7 +114,7 @@ section.erklaerung table {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
<style>
|
||||
@@ -92,7 +92,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -48,7 +48,7 @@ section.disable {
|
||||
# Klausurfragen – 223015b
|
||||
**Dateiformate, Schnittstellen, Speichermedien · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 01.02.2026</small>
|
||||
<small>Stand: 02.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,6 +922,8 @@ Wie viele Farben kann ein GIF-Bild gleichzeitig anzeigen?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M4 – WebP vs. JPEG: Vorteil?
|
||||
**Thema:** Bildformate – WebP
|
||||
**Punkte:** 1
|
||||
@@ -1165,6 +1167,8 @@ 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
|
||||
@@ -1181,6 +1185,8 @@ Was ist der fundamentale technische Unterschied zwischen HDD und SSD?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O3 – HDD vs. SSD: Eigenschaften zuordnen
|
||||
**Thema:** Speichermedien – Vergleich
|
||||
**Punkte:** 2
|
||||
@@ -1395,4 +1401,4 @@ Beschreiben Sie die drei Speichertechnologien **optisch** (CD/DVD/Blu-ray), **ma
|
||||
|
||||
Erklären Sie die drei Backup-Typen **Full**, **Inkrementell** und **Differenziell**. Beschreiben Sie für jeden: (1) welche Daten gesichert werden, (2) Vor- und Nachteile, und (3) wann dieser Typ sinnvoll eingesetzt wird.
|
||||
|
||||
> **Musterlösung:** **Full:** Kompletter Datenbestand wird jedes Mal gesichert. Vorteil: Einfache Wiederherstellung (nur ein Backup nötig). Nachteil: Langsam, braucht viel Speicherplatz. Einsatz: Wöchentlich als Basis. **Inkrementell:** Nur Änderungen seit dem letzten Backup (egal welcher Art). Vorteil: Schnell, wenig Speicher. Nachteil: Wiederherstellung komplex (Kette aller Backups nötig). Einsatz: Täglich. **Differenziell:** Änderungen seit dem letzten Full-Backup. Vorteil: Schneller als Full, einfachere Wiederherstellung als Inkrementell. Nachteil: Wächst täglich. Einsatz: Mittelweg bei moderatem Datenvolumen.
|
||||
> **Musterlösung:** **Full:** Kompletter Datenbestand wird jedes Mal gesichert. Vorteil: Einfache Wiederherstellung (nur ein Backup nötig). Nachteil: Langsam, braucht viel Speicherplatz. Einsatz: Wöchentlich als Basis. **Inkrementell:** Nur Änderungen seit dem letzten Backup (egal welcher Art). Vorteil: Schnell, wenig Speicher. Nachteil: Wiederherstellung komplex (Kette aller Backups nötig). Einsatz: Täglich. **Differenziell:** Änderungen seit dem letzten Full-Backup. Vorteil: Schneller als Full, einfachere Wiederherstellung als Inkrementell. Nachteil: Wächst täglich. Einsatz: Mittelweg bei moderatem Datenvolumen.
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
|
||||
---
|
||||
|
||||
@@ -115,7 +115,7 @@ section.erklaerung table {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
@@ -128,24 +128,13 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Kapitel 1
|
||||
## Geschichte, Grundlagen & HTML
|
||||
|
||||
---
|
||||
|
||||
# Kursübersicht
|
||||
|
||||
**3 Termine (10:00 – 16:30 Uhr):**
|
||||
**Kapitel:**
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 1 | 20.12.2025 | Geschichte, Grundlagen & **HTML** |
|
||||
| 2 | 10.01.2026 | Netzwerke, Protokolle, **semantisches HTML** & **CSS** |
|
||||
| 3 | 24.01.2026 | Interaktivität, Animationen & **JavaScript** |
|
||||
|
||||
**Format:** Theorie + viele Hands-On-Übungen
|
||||
1. Geschichte, Grundlagen & **HTML**
|
||||
2. Netzwerke, Protokolle, **semantisches HTML** & **CSS**
|
||||
3. Interaktivität, Animationen & **JavaScript**
|
||||
|
||||
**Ziel:** "Gelernte Hilflosigkeit" ablegen
|
||||
|
||||
@@ -153,8 +142,15 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 1: Die Geschichte
|
||||
## Von der Geburtsstunde des erten Computer-Algorithmus bis zur Vernetzung des gesamten Globus
|
||||
# Kapitel 1
|
||||
## Geschichte, Grundlagen & HTML
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Die Geschichte des Computers
|
||||
## Vom ersten Algorithmus bis zum globalen Netzwerk
|
||||
|
||||
---
|
||||
|
||||
@@ -176,14 +172,13 @@ Antoine Claudet
|
||||
|
||||
**Die erste Programmiererin der Welt**
|
||||
|
||||
- Arbeitete mit **Charles Babbage** an der "Analytical Engine"
|
||||
- Ihre »Notes« zu Babbages Maschine: **umfangreicher als sein Text**
|
||||
- 1843 publiziert – unter Initialen »A.A.L.« Ada Augusta Lovelace
|
||||
- Erst **1953** wiederentdeckt und gewürdigt
|
||||
- Schrieb **1843** den ersten Algorithmus für eine Maschine, die nie fertiggestellt wurde
|
||||
- Erste Programmiererin – 100 Jahre vor dem ersten Computer
|
||||
- Zusammenarbeit mit Charles Babbage an der *Analytical Engine*
|
||||
- Ihre Notizen: umfangreicher als sein Originaltext
|
||||
- Erst 1953 wiederentdeckt und gewürdigt
|
||||
|
||||
<!--
|
||||
Babbage: Mathematiker, besessen von Rechenmaschinen. Erst die Difference Engine, dann die Analytical Engine – nie fertig gebaut, aber revolutionär im Konzept.
|
||||
Babbage: Mathematiker, besessen von Rechenmaschinen. Erste Maschine: Difference Engine (reine Rechenmaschine). Zweite Maschine: Analytical Engine – programmierbar, mit Lochkarten gesteuert. Nie fertig gebaut, aber revolutionär im Konzept.
|
||||
|
||||
Ada: Tochter von Lord Byron, dem Dichter. Die Mutter – selbst Mathematikerin – hatte Angst, Ada könnte den "Wahnsinn" des Vaters erben. Also: strikte naturwissenschaftliche Erziehung. Weg von der Poesie, hin zur Logik.
|
||||
|
||||
@@ -213,19 +208,25 @@ Herman Hollerith, ca. 1890
|
||||
|
||||
# Herman Hollerith (1860–1929)
|
||||
|
||||
**Das Problem:** US-Volkszählung 1880 dauerte **7 Jahre** zur Auswertung
|
||||
**Erfinder der Lochkarten-Datenverarbeitung**
|
||||
|
||||
**Die Lösung:** Lochkarten + elektromechanische Tabelliermaschine
|
||||
|
||||
**1890 Census:** 62 Millionen Menschen in **2,5 Jahren** gezählt
|
||||
|
||||
**Ersparnis:** 5 Millionen Dollar (damals!)
|
||||
- **Problem:** Volkszählung 1880 brauchte 7 Jahre zur Auswertung
|
||||
- **Lösung:** Lochkarten + elektromechanische Tabelliermaschine
|
||||
- **Ergebnis:** 1890 Census in 2,5 Jahren – 5 Mio. Dollar gespart
|
||||
- Gründete Firma, die später zu IBM wurde
|
||||
|
||||
<!--
|
||||
Hollerith: Deutsch-amerikanischer Ingenieur
|
||||
Inspiration: Jacquard-Webstuhl (Lochkarten für Muster)
|
||||
Lochkarte = erstes standardisiertes Datenformat
|
||||
Eine Karte = ein Datensatz (eine Person)
|
||||
Hollerith: Deutsch-amerikanischer Ingenieur, Statistiker am US Census Bureau.
|
||||
|
||||
Das Problem: Die USA wuchsen so schnell, dass die Volkszählung von 1880 erst 1887 fertig ausgewertet war – die nächste Zählung stand schon bevor.
|
||||
|
||||
Inspiration: Jacquard-Webstuhl. Dieser französische Webstuhl nutzte seit 1804 Lochkarten zur Steuerung komplexer Muster. Hollerith übertrug das Prinzip auf Daten.
|
||||
|
||||
Seine Innovation: Eine Lochkarte = ein Datensatz (eine Person). Die Position der Löcher codierte Informationen (Alter, Geschlecht, Beruf etc.). Elektromechanische Maschine las die Karten und zählte automatisch.
|
||||
|
||||
1896 gründete er die Tabulating Machine Company. Nach mehreren Fusionen entstand daraus 1924 IBM – International Business Machines.
|
||||
|
||||
Die Lochkarte blieb bis in die 1970er das Standardformat für Dateneingabe.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -245,6 +246,17 @@ US Census Bureau
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

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

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

|
||||

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

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

|
||||
|
||||
<!--
|
||||
Unterseekabel-Karte: Über 400 Kabel verbinden die Kontinente.
|
||||
Quelle: TeleGeography Submarine Cable Map
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 1,3 Millionen Kilometer Unterseekabel
|
||||
|
||||
**Heute:**
|
||||
@@ -868,19 +809,28 @@ Kostenlos freigegeben → darum existiert es
|
||||
- **>400** Unterseekabel weltweit
|
||||
- Daten reisen mit **Lichtgeschwindigkeit** (Glasfaser)
|
||||
|
||||
**Das Internet ist physisch!** Keine "Cloud" ohne Kabel.
|
||||
Keine "Cloud" ohne Kabel – das Internet ist physische Infrastruktur.
|
||||
|
||||
**Five Eyes** (USA, UK, Kanada, Australien, Neuseeland):
|
||||
→ Zapfen Unterseekabel an – globale Massenüberwachung
|
||||
|
||||
<!--
|
||||
Google, Meta, Microsoft besitzen eigene Kabel
|
||||
Sabotage-Risiko (Russland, Anker)
|
||||
Latenz: Frankfurt → New York = ~80ms
|
||||
|
||||
Five Eyes: Geheimdienstallianz aus dem Zweiten Weltkrieg (UKUSA-Abkommen, 1946). Die fünf Länder teilen systematisch Überwachungsdaten. 2013 durch Edward Snowden enthüllt: NSA und GCHQ zapfen Unterseekabel direkt an (Programm "Tempora" des GCHQ, "Upstream" der NSA). Über diese Kabel läuft fast der gesamte internationale Internetverkehr – wer sie anzapft, kann potenziell alles mitlesen.
|
||||
|
||||
Erweiterte Allianzen: Nine Eyes (+Dänemark, Frankreich, Niederlande, Norwegen), Fourteen Eyes (+Deutschland, Belgien, Italien, Spanien, Schweden).
|
||||
|
||||
Deutschland ist also kein Five-Eyes-Mitglied, aber Teil der Fourteen Eyes. Der BND kooperiert eng mit der NSA (Operation Eikonal: BND leitete Daten vom Frankfurter Internetknoten DE-CIX an die NSA weiter).
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 2: Bits & Bytes
|
||||
# Bits & Bytes
|
||||
## Die Sprache der Computer
|
||||
|
||||
---
|
||||
@@ -1026,9 +976,9 @@ Fehlercodes: Windows zeigt diese bei Bluescreens
|
||||
|
||||
| Einheit (Bit) | Einheit (Byte) |
|
||||
|---------------|----------------|
|
||||
| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte |
|
||||
| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte |
|
||||
| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte |
|
||||
| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte = 8.000 Bit |
|
||||
| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte = 8 Mbit |
|
||||
| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte = 8 Gbit |
|
||||
|
||||
**Praxis:** 100 Mbit/s Internet = **12,5 MB/s** Download
|
||||
|
||||
@@ -1043,35 +993,9 @@ Warum? Marketing - 100 klingt besser als 12,5
|
||||
|
||||
---
|
||||
|
||||
# Warum zeigt meine 1TB-Festplatte nur 931GB?
|
||||
|
||||
**Zwei Zählweisen:**
|
||||
|
||||
| Dezimal (Hersteller) | Binär (Computer) |
|
||||
|---------------------|------------------|
|
||||
| Kilo = 1.000 | Kibi = 1.024 (2¹⁰) |
|
||||
| Mega = 1.000.000 | Mebi = 1.048.576 (2²⁰) |
|
||||
| Giga = 1.000.000.000 | Gibi = 1.073.741.824 (2³⁰) |
|
||||
| Tera = 1.000.000.000.000 | Tebi = 1.099.511.627.776 (2⁴⁰) |
|
||||
|
||||
**Das Problem:**
|
||||
- Hersteller verkauft: 1 TB = 1.000.000.000.000 Bytes
|
||||
- Computer rechnet: 1 TiB = 1.099.511.627.776 Bytes
|
||||
- Differenz: **9,1%** → zeigt nur **931 GB**
|
||||
|
||||
<!--
|
||||
Dezimal: SI-System (Système International) - Basis 10
|
||||
Binär: IEC-Standard (International Electrotechnical Commission) - Basis 2
|
||||
Kibi/Mebi/Gibi = Kunstwörter für binäre Einheiten
|
||||
Hersteller nutzen Dezimal = klingt größer = Marketing
|
||||
Windows zeigt binär, schreibt aber "GB" statt "GiB"
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 3: Eure erste Webseite
|
||||
# Unsere erste Webseite
|
||||
## HTML-Grundlagen
|
||||
|
||||
---
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 2: Netzwerke, Protokolle & CSS"
|
||||
---
|
||||
|
||||
@@ -118,7 +118,7 @@ section.erklaerung table {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 3: Interaktivität & JavaScript"
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.4 MiB |
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
|
||||
---
|
||||
<style>
|
||||
@@ -93,7 +93,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
|
||||
@@ -48,7 +48,7 @@ section.disable {
|
||||
# Klausurfragen – 223015c
|
||||
**IT-Grundlagen · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 01.02.2026</small>
|
||||
<small>Stand: 02.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,6 +138,7 @@ Erklären Sie die fünf Komponenten der Von-Neumann-Architektur: **Rechenwerk (A
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK B – Netzwerk-Grundlagen (TCP/IP)
|
||||
@@ -696,7 +697,7 @@ Was ist die Hauptfunktion eines DNS-Servers?
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### D2 – DNS: Zeitlicher Ablauf
|
||||
### D2-alt – DNS: Zeitlicher Ablauf
|
||||
**Thema:** DNS – Rolle im Gesamtablauf
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
@@ -994,6 +995,7 @@ 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