| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung |
| edv:betriebsysteme:start [29 36 2026 19 : 36] – André Reichert-Creutz | edv:betriebsysteme:start [29 41 2026 19 : 41] (aktuell) – André Reichert-Creutz |
|---|
| ====== DON'T PANIC: Per Anhalter durch das Betriebssystem ====== | ====== DON'T PANIC: Per Anhalter durch das Betriebssystem ====== |
| |
| Willkommen, Anhalter! Dieser zweiwöchige Kurs ist euer Handtuch für die Reise durch die Galaxis der Betriebssysteme. Ein Betriebssystem (OS) ist weit mehr als nur bunter Code auf einem Bildschirm – es ist der ultimative Vermittler zwischen Benutzer, Anwendungen und der fehleranfälligen Hardware[cite: 1]. | Willkommen, Anhalter! Dieser zweiwöchige Kurs ist euer Handtuch für die Reise durch die Galaxis der Betriebssysteme. Ein Betriebssystem (OS) ist weit mehr als nur Code auf einem Bildschirm – es ist der ultimative Vermittler zwischen Benutzer, Anwendungen und der Hardware. |
| |
| Ohne ein Betriebssystem müsstet ihr jede Spannungsänderung im Silizium selbst steuern – eine Aufgabe, die selbst die Geduld eines Vogonen überstrapazieren würde. In den nächsten zwei Wochen werden wir die fundamentalen Konzepte entschlüsseln, primär am Beispiel des offenen Pinguins (**Linux**), aber wir werfen auch einen Blick über den Tellerrand zu Windows und macOS[cite: 1]. | Ohne ein Betriebssystem müsstet ihr jede Spannungsänderung im Silizium selbst steuern – eine Aufgabe, die selbst die Geduld eines Vogonen überstrapazieren würde. In den nächsten zwei Wochen werden wir die fundamentalen Konzepte entschlüsseln. Die Antwort auf alle Fragen lautet vielleicht 42, aber bis wir dort ankommen, müssen wir verstehen, wie die Frage überhaupt im Speicher abgelegt wird. |
| | |
| Die Antwort auf alle Fragen lautet vielleicht 42, aber bis wir dort ankommen, müssen wir verstehen, wie die Frage überhaupt im Speicher abgelegt wird. | |
| |
| --- | --- |
| |
| ==== Modul 1: Historie und Architektur (Tag 1) ==== | ==== Modul 1: Historie und Architektur (Tag 1) ==== |
| Wie strukturieren wir das Chaos aus Nullen und Einsen? Alles begann mechanisch mit dem Abakus und später der Zuse Z1, dem ersten vollautomatischen, programmgesteuerten Rechner der Welt[cite: 1]. Über Röhrenrechner (Z22) und Lochkarten kamen wir zu den ersten Time-Sharing-Systemen wie CTSS und Multics, den direkten Vorfahren von Unix[cite: 1]. | Wie strukturieren wir das Chaos aus Nullen und Einsen? Alles begann mechanisch. |
| | * Konrad Zuse konstruierte mit der Z1 das erste Rechenwerk, das voll auf der Grundlage des Dualsystems arbeitete. |
| | * Die Z22 war später der erste Röhrenrechner der Zuse KG, in dem Programme direkt in der Maschine gespeichert werden konnten. |
| | * Die erste Computergeneration (1945-1955) besaß gar kein Betriebssystem, programmiert wurde direkt mit Steckbrett oder Lochkarte. |
| | * Danach kam die Stapelverarbeitung (Batch-Betrieb) der zweiten Generation, bevor die dritte Generation den Dialogbetrieb und Multiprogramming einführte. |
| |
| Heute unterscheiden wir beim Kern des Systems (Kernel) drei Architekturen[cite: 1]: | **Architektur des Kernels:** |
| * **Die Monolithische Architektur:** Alle Komponenten (Treiber, Dateisysteme, Speicherverwaltung) sind starr zu einem homogenen Gebilde zusammengefügt[cite: 1]. Dies bringt eine enorm hohe Effizienz[cite: 1]. **Linux** ist ein solcher Monolith. Wenn ihr später Enterprise-Umgebungen wie Red Hat Enterprise Linux (RHEL 9.2) oder Debian 12 "Bookworm" administriert, nutzt ihr genau diese Kraft, die durch ladbare Kernel-Module extrem flexibel bleibt. | * **Die Monolithische Architektur:** Alle Komponenten sind starr zu einem homogenen Gebilde zusammengefügt. Das bringt extrem hohe Effizienz, auf Kosten der Flexibilität. Linux nutzt diese monolithische Architektur. |
| * **Die Mikrokern Architektur:** Der Kernel reduziert sich auf das Nötigste (Prozess- und Speicherverwaltung)[cite: 1]. Alles andere läuft im User-Space. Das ist sicherer (ein abstürzender Treiber reißt nicht das System mit), aber durch den ständigen Nachrichtenversand langsamer. | * **Die Mikrokern Architektur:** Der Kernel verfügt über deutlich weniger Funktionen (meist nur Speicher- und Prozessverwaltung) als ein Monolith. Er wird vor allem bei Echtzeitbetriebssystemen eingesetzt. |
| * **Mehrschichtige Architektur:** Eine funktionelle Trennung in Schichten mit unterschiedlichen Privilegien[cite: 1]. | * **Mehrschichtige Architektur:** Das System wird in funktionelle, hierarchische Schichten oder Schalen getrennt, die mit unterschiedlichen Privilegien ausgestattet sind. |
| |
| {{http://www.kreissl.info/pics/images/bs_08.gif|Organisation eines Betriebssystem}} | {{http://www.kreissl.info/pics/images/bs_08.gif|Organisation eines Betriebssystem}} |
| |
| ==== Modul 2: Prozesse, Threads und die galaktische Bürokratie (Tag 2) ==== | ==== Modul 2: Prozesse, Threads und die galaktische Bürokratie (Tag 2) ==== |
| Ein Prozess ist die Ausführung eines Programms, bestehend aus Befehlen (Codebereich) und Programmdaten[cite: 1]. Ein Thread hingegen ist ein "leichtes Programm", das sich mit anderen Threads die Betriebsmittel und den Prozesskontext teilt, aber einen eigenen Stapelspeicher (Stack) besitzt[cite: 1]. | Ein Prozess ist in der Informatik ein Programm, das sich in Befehle (Codebereich) und Programmdaten gliedert. Ein Thread ist eine Erweiterung dieses Modells – ein "leichtes Programm", das sich mit anderen Threads die Betriebsmittel teilt, aber einen eigenen Stapelspeicher (Stack) besitzt. |
| |
| Damit wir nicht Äonen auf Berechnungen warten müssen, gibt es das **Prozessmodell** mit seinen Zuständen[cite: 1]: | Damit wir nicht Äonen warten müssen, nutzt das OS ein **Prozessmodell** mit diesen Zuständen: |
| * **WARTEND:** Der Prozess wartet auf die Zuteilung eines Prozessors[cite: 1]. | * **WARTEND (rechenbereit):** Der Prozess wartet auf die Zuteilung eines Prozessors. |
| * **LAUFEND:** Der Prozess ist aktuell einem Prozessor zugeordnet und rechnet[cite: 1]. | * **LAUFEND (rechnend):** Der Prozess ist aktuell einem Prozessor zugeordnet und läuft ab. |
| * **UNTERBROCHEN:** Der Prozess wurde durch einen anderen Prozess unterbrochen[cite: 1]. | * **UNTERBROCHEN:** Der Prozess wurde durch einen anderen Prozess unterbrochen. |
| * **BLOCKIERT:** Der Prozess wartet auf ein Ereignis (z.B. I/O)[cite: 1]. | * **BLOCKIERT:** Der Prozess wartet auf ein Ereignis (z. B. I/O). |
| |
| {{http://www.kreissl.info/pics/images/bs_09.gif|Prozessübergänge}} | {{http://www.kreissl.info/pics/images/bs_09.gif|Prozessübergänge}} |
| |
| Ein **Scheduler** regelt, wer wann rechnen darf[cite: 1]. Beim **Round Robin** (Zeitscheibenverfahren) erhält jeder Prozess eine feste Zeitspanne, bevor er verdrängt wird, während beim **Prioritäts-Scheduling** wichtigere Prozesse bevorzugt werden[cite: 1]. | Ein **Scheduler** bestimmt, wer rechnen darf. Beim **Round Robin** (Zeitscheibenverfahren) erhält jeder Prozess eine feste Zeitspanne, bevor er verdrängt wird. Beim **Prioritäts-Scheduling** wird einem Prozess eine Priorität zugeordnet, wodurch Prozesse niedrigerer Priorität warten müssen. Bei "First come, first served" wird schlicht derjenige bedient, der zuerst da ist. |
| |
| ==== Modul 3: Prozesskommunikation & Hierarchien (Tag 3) ==== | ==== Modul 3: Prozesskommunikation, Hierarchien und Deadlocks (Tag 3) ==== |
| Ein Prozess kann einen neuen Prozess starten (z.B. über den Systemaufruf ''fork'')[cite: 1]. Dieser "Kindprozess" hat genau einen "Elternprozess"[cite: 1]. Wenn der Elternprozess stirbt, sterben normalerweise auch seine Kinder[cite: 1]. | Ein Prozess kann einen neuen Prozess starten, wodurch ein "Elternprozess" und ein "Kindprozess" entstehen. Wird der Elternprozess beendet, beenden sich normalerweise auch alle seine Kindprozesse. |
| |
| Damit Prozesse nicht im luftleeren Raum agieren, müssen sie kommunizieren (IPC)[cite: 1]: | Prozesse müssen kommunizieren (Inter-Process Communication). Dafür gibt es mehrere Wege: |
| * **Pipes:** Direkte Datenkanäle zwischen zwei Prozessen (einer schreibt, einer liest)[cite: 1]. | * **Gemeinsamer Speicher:** Prozesse teilen sich Datenbereiche und Variablen. |
| * **Gemeinsamer Speicher:** Prozesse teilen sich Datenbereiche im RAM[cite: 1]. | * **Pipes:** Direkte Datenkanäle zwischen zwei Prozessen – einer schreibt, der andere liest. |
| * **Signale:** Software-Interrupts, die Prozesse über Ereignisse informieren[cite: 1]. | * **Signale:** Ereignisse, die einen Software-Interrupt erzeugen. |
| | * **Prozedurfernaufrufe (RPC):** Ein Prozess ruft eine Prozedur auf, die in einem anderen Prozess liegt. |
| |
| Jeder Prozess hat Rechte. Wichtig ist die Trennung zwischen der //realen Benutzer-ID// (wer hat den Prozess gestartet) und der //effektiven Benutzer-ID// (welche Rechte hat der Prozess aktuell)[cite: 1]. Durch das **setuid-Bit** kann ein Prozess die Rechte des Programmeigentümers annehmen[cite: 1] – ein kritisches Sicherheitskonzept in Unix/Linux. | Wenn Prozesse um Ressourcen kämpfen, droht der **Deadlock** (Stillstand). Dafür müssen vier Bedingungen erfüllt sein: |
| | 1. Mutual Exclusion (wechselseitiger Ausschluss). |
| | 2. Belegungs- und Wartebedingung (Prozess kann weitere Betriebsmittel anfordern). |
| | 3. Unterbrechbarkeitsbedingung (Betriebsmittel können nicht entzogen werden). |
| | 4. Zyklische Wartebedingung (Zyklus im Betriebsmittelgraph). |
| |
| ==== Modul 4: Speicherverwaltung & Der Unwahrscheinlichkeitsdrive (Tag 4) ==== | ==== Modul 4: Speicherverwaltung & Der Unwahrscheinlichkeitsdrive (Tag 4) ==== |
| Es ist eine universelle Konstante: Der RAM ist immer zu klein[cite: 1]. Statt in Panik zu verfallen, nutzen moderne OS den **virtuellen Speicher**[cite: 1]. | Der Arbeitsspeicher ist chronisch zu klein. Früher nutzte man **Overlay-Verwaltung**, bei der der Programmierer sein Programm selbst in Teile (Overlays) spalten musste, die das OS nacheinander lud. |
| * Der logische Adressraum (auf den das Programm zugreift) ist getrennt vom physischen Adressraum (dem echten RAM)[cite: 1]. | |
| * Beim **Paging** wird der Adressraum in gleich große Seiten (Pages) und Seitenrahmen (Page Frames) unterteilt[cite: 1]. | Heute rettet uns der **virtuelle Speicher**: Der Speicheradressraum des Prozessors wird vom realen Adressraum des Arbeitsspeichers getrennt. |
| * Eine Memory Management Unit (MMU) rechnet die virtuellen Adressen in physikalische um[cite: 1]. Ein Translation Look-aside Buffer (TLB) dient dabei als ultraschneller Cache für die Adressumrechnung[cite: 1]. | * Beim **Paging** wird der virtuelle Adressraum in "Seiten" (Pages) unterteilt. Die korrespondierenden Einheiten im physikalischen Speicher heißen Seitenrahmen. |
| * Werden Seiten benötigt, die gerade nicht im RAM liegen, kommt es zum Page Fault, und das OS lädt sie von der Festplatte nach[cite: 1]. | * Die Umrechnung erledigt die **Memory Management Unit (MMU)**. |
| | * Ein **Translation Look-aside Buffer (TLB)** speichert die zuletzt verwendeten Umrechnungen zwischen – ein enormer Geschwindigkeitsvorteil. |
| | * Alternativ (oder ergänzend) gibt es das **Segmentieren**, bei dem der logische Adressraum in Abschnitte variabler Größe (z. B. für Unterprogramme) geteilt wird. Die logische Adresse besteht dann aus Segment-Nummer und Offset. |
| |
| ==== Modul 5: Eingabe, Ausgabe und Geräte (Tag 5) ==== | ==== Modul 5: Eingabe, Ausgabe und Geräte (Tag 5) ==== |
| I/O-Geräte werden meist in das Dateisystem eingebunden und wie Dateien behandelt[cite: 1]. Wir unterscheiden grob: | Peripheriegeräte werden in das Dateisystem eingebunden und aus Benutzersicht meist wie Dateien behandelt. Wir unterscheiden: |
| * **Block Devices:** Blockorientierte Geräte wie Festplatten, die Daten in festen Blöcken verarbeiten und wahlfreien Zugriff erlauben[cite: 1]. | * **Block Devices:** Blockorientierte Geräte wie Festplatten, die Daten nur in Form von Datenblöcken fester Länge verarbeiten. |
| * **Character Devices:** Zeichenorientierte Geräte wie Terminals oder serielle Schnittstellen, die einen kontinuierlichen Datenstrom (Byte für Byte) verarbeiten[cite: 1]. | * **Character Devices:** Zeichenorientierte Geräte wie Terminals, die einen Datenstrom aus einzelnen Bytes verarbeiten. |
| |
| Damit die CPU nicht ständig warten muss ("Polling"), arbeiten wir mit **interruptgesteuerter E/A** oder dem **DMA-Betrieb** (Direct Memory Access), bei dem der Datentransfer zwischen RAM und Peripherie völlig autark von der CPU abläuft[cite: 1]. | Die Gerätesteuerung kann programmgesteuert, unterbrechungsgesteuert (Interrupts) oder via **DMA (Direct Memory Access)** erfolgen. Beim DMA-Betrieb übernimmt eine DMA-Steuerung die Datenübertragung zwischen Hauptspeicher und Peripheriegerät völlig selbstständig, um den Prozessor zu entlasten. |
| |
| --- | --- |
| |
| ===== Woche 2: Die Galaxis in der Praxis ===== | ===== Woche 2: Dateisysteme, Cluster und die Zukunft ===== |
| |
| ==== Modul 6: Dateisysteme - Everything is a File (Tag 6) ==== | ==== Modul 6: Dateisysteme - Everything is a File (Tag 6) ==== |
| Ein Dateisystem übersetzt zwischen den rohen Hardware-Blöcken der Festplatte und den logischen Dateien des Benutzers[cite: 1]. | Ein Dateisystem muss die physischen Blöcke einer Festplatte in die logische Form einer Datei übersetzen. |
| |
| **Die Linux-Welt (Unix/ext2/ext3/ext4):** | **Linux/Unix:** |
| Nutzt **INodes (Index Nodes)**[cite: 1]. Ein Inode enthält Attribute (Eigentümer, Rechte, Zeiten) und Zeiger auf die Datenblöcke[cite: 1]. Kleine Dateien werden direkt adressiert. Für größere Dateien gibt es "einfach indirekte", "doppelt indirekte" und "dreifach indirekte" Blöcke, die eine baumartige Adressierung von riesigen Datenmengen erlauben[cite: 1]. | Unix nutzt zur Adressierung **INodes (Index Nodes)**. |
| | * Ein INode enthält Informationen über Eigentümer, Zugriffsberechtigungen und Attribute. |
| | * Er hat 13 Einträge zur Adressierung. Die ersten 10 zeigen direkt auf Datenblöcke. |
| | * Der 11. Eintrag zeigt auf einen INode, der weitere Blöcke adressiert (einfach indirekt). Eintrag 12 ist doppelt indirekt, der letzte dreifach indirekt. |
| |
| {{http://www.kreissl.info/pics/images/bs_03.gif|I-Nodes}} | {{http://www.kreissl.info/pics/images/bs_03.gif|I-Nodes}} |
| |
| **Die Windows-Welt (NTFS):** | **Windows (NTFS):** |
| Nutzt eine **Master File Table (MFT)**[cite: 1]. Zusammenhängende Bereiche werden als B-Baum organisiert[cite: 1]. Kleine Dateien werden sogar direkt in den MFT-Eintrag (1-4 KB) geschrieben[cite: 1]. Ein Logfile (Journal) sorgt für Sicherheit nach Systemabstürzen[cite: 1]. | NTFS nutzt eine **Master File Table (MFT)**. |
| | * Jede Datei besitzt hier einen Eintrag. |
| | * Bei kleinen Dateien werden alle Attribute (inklusive der Daten) direkt innerhalb des MFT-Eintrags abgelegt. |
| | * Bei großen Dateien enthält der Eintrag den Wurzelknoten eines B-Baums, dessen Blätter auf die Dateibereiche (Extents) verweisen. |
| |
| Zudem erlauben Systeme **Links**: Ein Softlink verweist auf den Pfad, ein Hardlink zeigt direkt auf den Inode der Zieldatei[cite: 1]. | Um Dateien von mehreren Orten zugänglich zu machen, nutzt man **Links**. Das "symbolic linking" legt eine spezielle Datei an, die den absoluten Pfadnamen der gelinkten Datei enthält. |
| |
| ==== Modul 7: Linux, GNU und die Philosophie des freien Quellcodes (Tag 7) ==== | ==== Modul 7: Linux, GNU und die Open-Source-Galaxis (Tag 7) ==== |
| Linux begann 1991 als Hobby-Projekt des finnischen Studenten Linus Torvalds[cite: 1]. Doch "Linux" ist streng genommen nur der Kernel. Zusammen mit den Werkzeugen des **GNU-Projekts** (Compiler wie gcc, Shells wie bash, Tools wie grep oder find) wird daraus ein vollwertiges Betriebssystem[cite: 1]. | Historisch stammt Unix aus den 1960er Jahren, hervorgegangen aus dem System Multics. Ken Thompson und Dennis Ritchie entwickelten die erste Unix-Version und schufen dafür die Sprache C. |
| | |
| **Was ist Open Source?** | |
| "Frei" (wie in Freiheit, nicht zwingend wie in Freibier) bedeutet: Der Quellcode (meist C und Assembler) ist offen. Jeder kann ihn lesen, verstehen, verändern und weitergeben. Diese Transparenz macht das System extrem sicher und anpassbar[cite: 1]. | |
| | |
| **Kann man da mitmachen?** | |
| Absolut! Wer einen Bug findet, kann den Code per Git (z.B. über GitLab-Management) klonen, patchen und auf der Linux Kernel Mailing List (LKML) einreichen. Wenn der Code gut ist, wird er Teil der Geschichte. | |
| |
| | 1991 initiierte Linus Torvalds den Kernel für Linux. Ein Großteil der grundlegenden Software in Linux (wie C-Compiler oder Shells) stammt aus dem GNU-Projekt. |
| **Systemvergleich:** | **Systemvergleich:** |
| * **Linux:** Hochgradig anpassbar, exzellente Speicherverwaltung, extrem stabil, Fokus auf Sicherheit[cite: 1]. Ein Traum für Administratoren und Server. | * **Linux:** Extrem ressourcenschonend (eine GUI ist optional), sehr sicheres Multiusersystem, extrem konfigurierbar. Alle Sourcen sind frei verfügbar. |
| * **macOS X:** Basiert auf einem Unix-Kern (Darwin/Mach), bietet eine geschlossene, hochoptimierte Hardware-Software-Symbiose[cite: 1]. | * **macOS X:** Basiert auf einem Unix-Derivat (Darwin/Mach), glänzt durch Hardwarebindung und Multimedia-Integration. |
| * **Windows:** Gigantisches Software-Ökosystem, hervorragende Hardwareunterstützung im Consumer-Bereich, benötigt jedoch meistens Virenscanner[cite: 1]. | * **Windows:** Gigantische Verbreitung und riesige Software-Auswahl. Es ist stark von Microsoft getrieben, anfälliger für Viren und oft schwieriger in tiefen Kernelsystemen zu debuggen. |
| |
| ==== Modul 8: Verteilte Systeme & Netzwerke (Tag 8) ==== | ==== Modul 8: Verteilte Systeme & Cluster (Tag 8) ==== |
| Ein verteiltes System ist ein Zusammenschluss unabhängiger Computer, der sich dem Benutzer als ein einzelnes System präsentiert[cite: 1]. | Ein verteiltes System ist laut Andrew Tanenbaum ein Zusammenschluss unabhängiger Computer, der sich für den Benutzer als ein einzelnes System präsentiert. |
| * **Client-Server:** Der Client fordert Betriebsmittel oder Dienste an, der Server liefert[cite: 1]. | Die bekannteste Architektur ist das **Client-Server-Modell**, bei dem der Client eine Aufgabe (z. B. Datenbankabfrage) anfordert und der Server diese bereitstellt. |
| * **HA-Cluster (High Availability):** Zwei oder mehr Knoten. Einer ist aktiv, der andere passiv[cite: 1]. Sie tauschen ständig "Heartbeat"-Signale aus[cite: 1]. Fällt der primäre Node aus (oder wird eine Perimeter-Firewall rebootet), übernimmt der sekundäre. Um "Split-Brain"-Szenarien zu verhindern, nutzt man STONITH ("Shoot The Other Node In The Head")[cite: 1]. Solche Zustände können hervorragend mit Agenten wie checkmk überwacht werden. | |
| * **HPC-Cluster:** High Performance Computing, bei dem Jobs via Message Passing Interface (MPI) parallel auf Dutzenden Knoten abgearbeitet werden[cite: 1]. | Noch spannender sind **Cluster**, die vernetzte Computer zu einem mächtigen Gebilde vereinen. Es gibt primär diese Typen: |
| * **Load Balancing:** Clientanfragen werden an den Knoten mit der aktuell besten Performance verteilt[cite: 1]. | * **HA Cluster (High Availability):** Ein Knoten ist aktiv, der andere passiv. Sie tauschen "Heartbeat"-Signale aus. Fällt der aktive Knoten aus, übernimmt der passive. Um den gefährlichen "Split-Brain"-Zustand zu verhindern, schießt der passive Knoten den defekten Partner vor der Übernahme über STONITH (Shoot The Other Node In The Head) hardwareseitig ab. |
| | * **HPC Cluster (High Performance Computing):** Hier werden Jobs durch ein Decomposition-Programm in kleine Teile zerlegt und parallel auf mehreren Rechenknoten ausgeführt. Die Kommunikation erfolgt meist via MPI (Message Passing Interface). |
| | * **Load Balancing Cluster:** Clientanfragen werden durch einen Loadbalancer an den Serverknoten mit der voraussichtlich besten Performance verteilt. |
| |
| ==== Modul 9: Grid & Cloud Computing (Tag 9) ==== | ==== Modul 9: Grid & Cloud Computing (Tag 9) ==== |
| Das Internet wächst zu einem globalen Parallelrechner zusammen[cite: 1]. | Wenn der lokale Rechner nicht reicht, wandern wir ins Netz. |
| * **Grid Computing:** Ressourcen (Computer, Speicher, Datenbanken) werden über das Internet transparent verteilt (z.B. Data Grids oder Application Grids)[cite: 1]. | **Grid Computing** vernetzt Tausende einzelner Computer zu einem komplexen System mit enormer Rechenleistung. Es gibt z. B. Computer Grids für Rechenkapazität, Data Grids für große verteilte Datenmengen und Application Grids zur Bereitstellung von Software über virtuelle Organisationen. |
| * **Cloud Computing:** Bietet hochskalierbare Infrastruktur On-Demand[cite: 1]. | |
| * **IaaS (Infrastructure as a Service):** Bereitstellung von roher Hardware (Rechner, Speicher, Netze) durch Virtualisierung[cite: 1]. | **Cloud Computing** treibt dies auf die Spitze. Dienste werden On-Demand abgerechnet ("pay per use"). Wir unterscheiden: |
| * **PaaS (Platform as a Service):** Bereitstellung einer transparenten Entwicklungsumgebung (Webserver, Laufzeitumgebung), auf der Apps getestet und gehostet werden[cite: 1]. | * **IaaS (Infrastructure as a Service):** Der Anbieter stellt Speicherplatz, Server und Rechenkapazität bereit. |
| * **SaaS (Software as a Service):** Komplette Anwendungen laufen beim Drittanbieter (z.B. Web-Mail oder ERP-Systeme), der Nutzer braucht nur noch einen Browser[cite: 1]. | * **PaaS (Platform as a Service):** Bereitstellung einer transparenten Entwicklungsumgebung (z.B. Webserver) zum Testen und Hosten von Apps. |
| | * **SaaS (Software as a Service):** Der Anbieter hostet eine vollständige Software-Applikation; der Anwender benötigt nur noch einen Web-Browser. |
| | |
| | Die Bereitstellung erfolgt über **Private Clouds** (nur für interne Unternehmenszwecke), **Public Clouds** (öffentlich verfügbar) oder als **Hybrid Cloud**. |
| |
| ==== Modul 10: Embedded Systems & Organic Computing (Tag 10) ==== | ==== Modul 10: Embedded Systems & Organic Computing (Tag 10) ==== |
| Die Zukunft liegt nicht nur in der Cloud, sondern in winzigen Geräten. | Betriebssysteme der Zukunft steuern nicht nur Desktop-PCs. |
| * **Embedded Systems:** Vom Apollo Guidance Computer der Mondlandung[cite: 1] bis zum modernen Android-Telefon oder der Kfz-Steuerung[cite: 1]. Hier kommen stark spezialisierte Echtzeit-OS wie QNX, VxWorks oder Embedded Linux zum Einsatz[cite: 1]. | **Embedded Systems** verrichten unsichtbar ihren Dienst in Waschmaschinen, Autos oder DVD-Playern. Eines der ersten war der Apollo Guidance Computer für die Mondlandung. Die Elektronik besteht meist aus Mikroprozessoren (wie ARM oder PowerPC) und hochspezialisierten Betriebssystemen wie QNX, VxWorks oder Embedded Linux. |
| * **Organic Computing:** Künftige Systeme werden so komplex, dass sie sich wie biologische Organismen verhalten müssen: selbst-konfigurierend, selbst-heilend, selbst-optimierend und selbst-schützend (die sogenannten "self-x Eigenschaften")[cite: 1]. | |
| | Die absolute Spitze der Evolution bildet das **Organic Computing**. Systeme werden künftig so komplex, dass sie lebensähnlich ("organisch") reagieren müssen. Sie benötigen "self-x" Eigenschaften: |
| | * **selbst-konfigurierend** |
| | * **selbst-optimierend** |
| | * **selbst-heilend** |
| | * **selbst-schützend** |
| | |
| | Ein "Smart Network" wird sich spontan vernetzen, Ausfälle erkennen und Aufgaben bei Überlastung autonom neu verteilen. |
| |
| ---- | ---- |
| //**Quellen**//\\ | //**Quellen & Materialien**//\\ |
| //Script Betriebssysteme zur Erlangung des Grades Bachelor (German-Baltic Management School)//[cite: 1]\\ | //Alle Inhalte dieses Kurses basieren auf dem Skript "Betriebssysteme" der German-Baltic Management School. Zusätzliche Anreicherungen und Strukturierung durch den Kursleiter.// |
| //Zusätzliche Anreicherungen und Strukturierung durch den Kursleiter.// | |