| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung |
| edv:betriebsysteme:start [29 33 2026 19 : 33] – André Reichert-Creutz | edv:betriebsysteme:start [29 41 2026 19 : 41] (aktuell) – André Reichert-Creutz |
|---|
| {{:edv:betriebsysteme:logo-betriebsysteme.png?600|}}\\ | |
| {{ :edv:betriebsysteme:bsscript.pdf |Script Betriebssysteme zur Erlangung des Grades Bachelor im Studiengang Informatik / Computer Science / B.Sc.}} | |
| {{:edv:betriebsysteme:logo-betriebsysteme.png?600|}}\\ | {{:edv:betriebsysteme:logo-betriebsysteme.png?600|}}\\ |
| {{ :edv:betriebsysteme:bsscript.pdf |Script Betriebssysteme zur Erlangung des Grades Bachelor im Studiengang Informatik / Computer Science / B.Sc.}} | {{ :edv:betriebsysteme:bsscript.pdf |Script Betriebssysteme zur Erlangung des Grades Bachelor im Studiengang Informatik / Computer Science / B.Sc.}} |
| ====== 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. Um es holistisch zu betrachten: Ein Betriebssystem ist nicht einfach nur Code. Es ist das Fundament der informationstechnischen Existenz, das System, das als Vermittler zwischen Benutzer, Anwendungen und Hardware fungiert[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. Wir werden uns primär ansehen, wie das Open-Source-Flaggschiff **Linux** funktioniert, wie es programmiert wird und wo die Unterschiede zu Systemen wie Windows oder macOS liegen. | 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. |
| |
| {{http://www.kreissl.info/pics/images/bs_08.gif|Organisation eines Betriebssystem}} | --- |
| |
| ===== Kapitel 1: Die Anatomie des Pinguins (Architektur) ===== | ===== Woche 1: Das Fundament der informationstechnischen Existenz ===== |
| |
| Wie strukturiert man das Chaos aus Nullen und Einsen? Das Skript definiert drei grundlegende Herangehensweisen[cite: 1]: | ==== Modul 1: Historie und Architektur (Tag 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. |
| |
| * **Die Monolithische Architektur:** Alle Komponenten sind starr zu einem homogenen Gebilde zusammengefügt[cite: 1]. **Linux** ist ein klassischer Monolith. Das bedeutet, Treiber, Dateisysteme und Speicherverwaltung laufen alle im privilegierten Kernel-Space. Das ist rasend schnell, bedeutet aber auch: Baut ihr einen fehlerhaften Treiber, stürzt das gesamte System ab (Kernel Panic). Wenn ihr heute hochstabile Enterprise-Umgebungen wie Red Hat Enterprise Linux (RHEL 7.9 bis 9.2) oder ein solides Debian 12 "Bookworm" administriert, nutzt ihr genau diese monolithische, aber durch ladbare Module dynamisch erweiterbare Kraft. | **Architektur des Kernels:** |
| * **Die Mikrokern Architektur:** Hier verfügt der Kernel über weniger Funktionen als ein monolithischer Kernel – in der Regel lediglich Speicher- und Prozessverwaltung[cite: 1]. Treiber laufen im isolierten User-Space. Das ist sicherer, aber durch den ständigen Nachrichtenversand zwischen den Schichten (Inter-Process Communication) oft langsamer. | * **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. |
| * **Der Systemvergleich:** Apple nutzt in macOS X den Darwin-Kernel, welcher auf einem Mach-Mikrokernel basiert[cite: 1]. Unser Handout-Skript klassifiziert auch Windows NT als MACH Mikrokernel[cite: 1], in der modernen Realität spricht man bei Microsoft Windows jedoch eher von einem "Hybridkernel", der Konzepte aus beiden Welten mischt, um Performance und Modularität auszubalancieren. | * **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:** Das System wird in funktionelle, hierarchische Schichten oder Schalen getrennt, die mit unterschiedlichen Privilegien ausgestattet sind. |
| |
| {{http://www.kreissl.info/pics/images/bs_09.gif|System-Call am Beispiel Windows NT}} | {{http://www.kreissl.info/pics/images/bs_08.gif|Organisation eines Betriebssystem}} |
| |
| ===== Kapitel 2: Prozesse, Threads und Bürokratie ===== | ==== Modul 2: Prozesse, Threads und die galaktische Bürokratie (Tag 2) ==== |
| | 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. |
| |
| Ein Prozess ist schlichtweg ein Programm in Ausführung[cite: 1] – sozusagen der bürokratische Akt des Rechnens. Ein Thread hingegen ist ein "leichtes Programm", das sich mit anderen Threads die Betriebsmittel teilt[cite: 1]. | Damit wir nicht Äonen warten müssen, nutzt das OS ein **Prozessmodell** mit diesen Zuständen: |
| | * **WARTEND (rechenbereit):** Der Prozess wartet auf die Zuteilung eines Prozessors. |
| | * **LAUFEND (rechnend):** Der Prozess ist aktuell einem Prozessor zugeordnet und läuft ab. |
| | * **UNTERBROCHEN:** Der Prozess wurde durch einen anderen Prozess unterbrochen. |
| | * **BLOCKIERT:** Der Prozess wartet auf ein Ereignis (z. B. I/O). |
| |
| {{http://www.kreissl.info/pics/images/bs_01.gif|Prozess}} | {{http://www.kreissl.info/pics/images/bs_09.gif|Prozessübergänge}} |
| |
| Damit wir nicht Äonen auf Berechnungen warten müssen, gibt es das Prozessmodell. Es beschreibt wesentliche Zustände[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. |
| * **WARTEND:** Der Prozess wartet auf die Zuteilung eines Prozessors[cite: 1]. | |
| * **LAUFEND:** Der Prozess ist aktuell einem Prozessor zugeordnet und läuft ab[cite: 1]. | |
| * **UNTERBROCHEN:** Der Prozess wurde durch einen anderen Prozess unterbrochen[cite: 1]. | |
| * **SUSPENDIERT:** Prozesse aus dem Speicher entfernen und auslagern[cite: 1]. | |
| |
| {{http://www.kreissl.info/pics/images/bs_02.gif|Prozess Warteschlange}} | ==== Modul 3: Prozesskommunikation, Hierarchien und Deadlocks (Tag 3) ==== |
| {{http://www.kreissl.info/pics/images/bs_06.gif|Single-Server Warteschlange}} | 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. |
| {{http://www.kreissl.info/pics/images/bs_07.gif|Prioritätsscheduling}} | |
| |
| Damit das Multitasking flüssig wirkt, teilt ein sogenannter Scheduler die Prozessorzeit ein. Eine der bekanntesten Strategien ist "Round Robin" (Zeitscheibenverfahren), bei der jeder Prozess eine feste Zeitspanne zugeordnet bekommt, bevor er verdrängt wird[cite: 1]. Das verhindert, dass lange Prozesse die CPU monopolisieren. | Prozesse müssen kommunizieren (Inter-Process Communication). Dafür gibt es mehrere Wege: |
| | * **Gemeinsamer Speicher:** Prozesse teilen sich Datenbereiche und Variablen. |
| | * **Pipes:** Direkte Datenkanäle zwischen zwei Prozessen – einer schreibt, der andere liest. |
| | * **Signale:** Ereignisse, die einen Software-Interrupt erzeugen. |
| | * **Prozedurfernaufrufe (RPC):** Ein Prozess ruft eine Prozedur auf, die in einem anderen Prozess liegt. |
| |
| ===== Kapitel 3: Speicherverwaltung & Der Unwahrscheinlichkeitsdrive ===== | 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). |
| |
| Es ist eine universelle Konstante: Der RAM ist immer zu klein[cite: 1]. Statt in Panik zu verfallen, hat die Menschheit den **virtuellen Speicher** erfunden. | ==== Modul 4: Speicherverwaltung & Der Unwahrscheinlichkeitsdrive (Tag 4) ==== |
| | 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. |
| |
| {{http://www.kreissl.info/pics/images/bs_11.gif|Adressumsetzung}} | Heute rettet uns der **virtuelle Speicher**: Der Speicheradressraum des Prozessors wird vom realen Adressraum des Arbeitsspeichers getrennt. |
| | * Beim **Paging** wird der virtuelle Adressraum in "Seiten" (Pages) unterteilt. Die korrespondierenden Einheiten im physikalischen Speicher heißen Seitenrahmen. |
| | * 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. |
| |
| Hierbei ist der Adressraum des Prozessors strikt vom realen Adressraum des Arbeitsspeichers getrennt[cite: 1]. Eine Memory Management Unit (MMU) rechnet die virtuellen Adressen eurer Programme beim Paging in physikalische Adressen um[cite: 1]. Benötigt ein Programm Speicher, der gerade nicht in den RAM passt, lagert das Betriebssystem diesen auf die Festplatte (Swap) aus. | ==== Modul 5: Eingabe, Ausgabe und Geräte (Tag 5) ==== |
| | 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 nur in Form von Datenblöcken fester Länge verarbeiten. |
| | * **Character Devices:** Zeichenorientierte Geräte wie Terminals, die einen Datenstrom aus einzelnen Bytes verarbeiten. |
| |
| ===== Kapitel 4: Dateisysteme (Everything is a file!) ===== | 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. |
| |
| In der Linux/Unix-Welt gilt ein eisernes Gesetz: **"Everything is a file"** (Alles ist eine Datei). Egal ob es sich um ein Textdokument, eine Netzwerkverbindung oder eine Festplatte handelt – das OS abstrahiert alles als Datei, was die Programmierung extrem elegant macht[cite: 1]. | --- |
| | |
| | ===== Woche 2: Dateisysteme, Cluster und die Zukunft ===== |
| | |
| | ==== Modul 6: Dateisysteme - Everything is a File (Tag 6) ==== |
| | Ein Dateisystem muss die physischen Blöcke einer Festplatte in die logische Form einer Datei übersetzen. |
| | |
| | **Linux/Unix:** |
| | 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_05.gif|Unix Dateisystem Struktur}} | |
| {{http://www.kreissl.info/pics/images/bs_03.gif|I-Nodes}} | {{http://www.kreissl.info/pics/images/bs_03.gif|I-Nodes}} |
| {{http://www.kreissl.info/pics/images/bs_04.gif|Dateideskriptoren}} | |
| |
| * **Linux (ext2/ext3/ext4):** Nutzt zur Adressierung sogenannte **Inodes** (Index Nodes)[cite: 1]. Ein Inode enthält Informationen über den Eigentümer, Zugriffsberechtigungen und Zeiger auf die eigentlichen Datenblöcke der Datei auf der Platte[cite: 1]. | **Windows (NTFS):** |
| * **Windows (NTFS):** Nutzt eine **Master File Table (MFT)**, in der jede Datei einen Eintrag besitzt und zusammenhängende Bereiche als B-Baum organisiert werden[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. |
| | |
| | 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 Open-Source-Galaxis (Tag 7) ==== |
| | 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. |
| | |
| | 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:** |
| | * **Linux:** Extrem ressourcenschonend (eine GUI ist optional), sehr sicheres Multiusersystem, extrem konfigurierbar. Alle Sourcen sind frei verfügbar. |
| | * **macOS X:** Basiert auf einem Unix-Derivat (Darwin/Mach), glänzt durch Hardwarebindung und Multimedia-Integration. |
| | * **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. |
| |
| Spezialdateien wie //Pipes// verbinden Prozesse miteinander, wie ein pangalaktischer Strohhalm, durch den Datenströme fließen. | ==== Modul 8: Verteilte Systeme & Cluster (Tag 8) ==== |
| {{http://www.kreissl.info/pics/images/bs_12.gif|Pipe Schema}} | Ein verteiltes System ist laut Andrew Tanenbaum ein Zusammenschluss unabhängiger Computer, der sich für den Benutzer als ein einzelnes System präsentiert. |
| | Die bekannteste Architektur ist das **Client-Server-Modell**, bei dem der Client eine Aufgabe (z. B. Datenbankabfrage) anfordert und der Server diese bereitstellt. |
| |
| ===== Kapitel 5: Wie baut man ein OS und was ist dieses Open Source? ===== | Noch spannender sind **Cluster**, die vernetzte Computer zu einem mächtigen Gebilde vereinen. Es gibt primär diese Typen: |
| | * **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. |
| |
| Wie werden Betriebssysteme eigentlich programmiert? Die Sprache der Wahl ist **C**. Der Linux-Kernel besteht fast vollständig aus C. Hardwarenahe Bereiche (wie das Booten oder die direkte CPU-Register-Kontrolle) werden in **Assembler** geschrieben. | ==== Modul 9: Grid & Cloud Computing (Tag 9) ==== |
| | Wenn der lokale Rechner nicht reicht, wandern wir ins Netz. |
| | **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. |
| |
| **GNU und die Open-Source-Philosophie** | **Cloud Computing** treibt dies auf die Spitze. Dienste werden On-Demand abgerechnet ("pay per use"). Wir unterscheiden: |
| Wenn wir "Linux" sagen, meinen wir oft eigentlich **GNU/Linux**. Linux ist nur der Kernel (gestartet 1991 von Linus Torvalds[cite: 1]). Die ganzen Werkzeuge drumherum – Compiler, Shells, Basisprogramme – stammen vom GNU-Projekt ("GNU's Not Unix"), das freie Software fördert. | * **IaaS (Infrastructure as a Service):** Der Anbieter stellt Speicherplatz, Server und Rechenkapazität bereit. |
| "Frei" (Open Source) bedeutet nicht zwingend kostenlos (obwohl es das meistens ist[cite: 1]), sondern frei wie in "Freiheit". Ihr habt das Recht, den Quellcode zu lesen, zu modifizieren und zu verbreiten. | * **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. |
| |
| **Kann man da mitmachen? Ja!** | Die Bereitstellung erfolgt über **Private Clouds** (nur für interne Unternehmenszwecke), **Public Clouds** (öffentlich verfügbar) oder als **Hybrid Cloud**. |
| Jeder Student in diesem Kurs kann Code zum Linux-Kernel beitragen. Wenn ihr einen Bug in Debian fixen oder einen Treiber verbessern wollt, könnt ihr eure Änderungen (Patches) auf der Linux Kernel Mailing List (LKML) einreichen. Wenn der Code gut ist, wird er integriert. Linux ist das größte gemeinschaftliche Softwareprojekt der Menschheit. | |
| |
| ===== Kapitel 6: Verteilte Systeme & Die Zukunft der Galaxis ===== | ==== Modul 10: Embedded Systems & Organic Computing (Tag 10) ==== |
| | Betriebssysteme der Zukunft steuern nicht nur Desktop-PCs. |
| | **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. |
| |
| Was passiert, wenn ein Computer nicht reicht? Man baut ein Cluster. Das Skript beschreibt hier primär zwei Ausprägungen[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: |
| * **HA-Cluster (High Availability):** Bestehen aus mindestens zwei Knoten, wobei einer passiv ist und sofort übernimmt, sobald der aktive (überwacht durch "Heartbeat"-Signale) ausfällt[cite: 1]. | * **selbst-konfigurierend** |
| * **HPC-Cluster (High Performance Computing):** Hier werden Rechenaufgaben in kleine Teile zerlegt und parallel auf mehreren Rechnern ausgeführt[cite: 1]. | * **selbst-optimierend** |
| | * **selbst-heilend** |
| | * **selbst-schützend** |
| |
| Die Zukunft, liebe Anhalter, liegt im **Grid- und Cloud Computing**. Hierbei werden Ressourcen (IaaS), Plattformen (PaaS) oder komplette Software (SaaS) dynamisch und transparent wie Strom aus der Steckdose bezogen[cite: 1]. | 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 durch den Kursleiter.// | |