diff options
Diffstat (limited to 'linux-basics')
| -rw-r--r-- | linux-basics/boot-process/handout_boot-process_de.tex | 122 | ||||
| -rw-r--r-- | linux-basics/what-is-linux/handout_what-is-linux_de.tex | 142 |
2 files changed, 132 insertions, 132 deletions
diff --git a/linux-basics/boot-process/handout_boot-process_de.tex b/linux-basics/boot-process/handout_boot-process_de.tex index 0b36a61..40b62c8 100644 --- a/linux-basics/boot-process/handout_boot-process_de.tex +++ b/linux-basics/boot-process/handout_boot-process_de.tex @@ -4,99 +4,99 @@ \subsubsection{Aufgaben des Bootloaders} -Hauptaufgabe des Bootloaders ist die rudimentäre Initialisierung der +Hauptaufgabe des Bootloaders ist die rudiment"are Initialisierung der Hardware, so dass mindestens das RAM benutzt werden kann. Dazu ist auf den meisten Boards die Initialisierung eines (S)DRAM-Controllers erforderlich. -Soll das Board aus einem NAND-Flash booten können, so muss auch dessen +Soll das Board aus einem NAND-Flash booten k"onnen, so muss auch dessen Controller initialisiert werden. Viele Prozessoren beinhalten PLLs, die aus dem Prozessortakt andere Clocks -für verschiedene Peripherie-Einheiten generieren. Auch diese müssen +f"ur verschiedene Peripherie-Einheiten generieren. Auch diese m"ussen initialisiert werden. -Anschließend müssen die Peripherie-Einheiten initialisiert werden, die -der Bootloader benötigt, um den Kernel laden zu können. Für TFTP-Boot wäre +Anschlie\ss end m"ussen die Peripherie-Einheiten initialisiert werden, die +der Bootloader ben"otigt, um den Kernel laden zu k"onnen. F"ur TFTP-Boot w"are dies beispielsweise der Netzwerk-Chip. -Meist ist es auch erwünscht, dass der Bootloader eine serielle Schnittstelle -initialisiert. Dies ermöglicht nicht nur hilfreiche Meldungen aus dem -Bootloader, es ermöglicht auch dem Kernel bereits im frühen Stadium des +Meist ist es auch erw"unscht, dass der Bootloader eine serielle Schnittstelle +initialisiert. Dies erm"oglicht nicht nur hilfreiche Meldungen aus dem +Bootloader, es erm"oglicht auch dem Kernel bereits im fr"uhen Stadium des Bootvorgangs die Ausgabe von Meldungen (und nicht erst nach dem Laden seines UART-Treibers und der Konsole). Viele Bootloader bieten ausserdem eine Art Monitorprogramm, mit dem man mit Hilfe eines Terminalprogramms interaktiv -Einstellungen ändern oder Speicher lesen und schreiben kann. +Einstellungen "andern oder Speicher lesen und schreiben kann. -Nach erfolgreicher Initialisierung lädt der Bootloader von der gewählten +Nach erfolgreicher Initialisierung l"adt der Bootloader von der gew"ahlten Quelle das komprimierte Kernel-Image ins RAM. Am Anfang eines komprimierten -zImage steht (natürlich unkomprimiert) der Dekompressor-Code. Der Bootloader +zImage steht (nat"urlich unkomprimiert) der Dekompressor-Code. Der Bootloader springt diese Adresse an und hat damit seine Arbeit beendet. Alles weitere -läuft im Kernel ab. +l"auft im Kernel ab. -\subsubsection{Gängige Bootloader} +\subsubsection{G"angige Bootloader} Die Wahl des Bootloaders ist weitgehend eine Geschmacksfrage. Die verbreiteten Bootloader U-Boot und Redboot bieten im Wesentlichen die gleiche -Funktionalität. Die Bedienung unterscheidet sich zwar deutlich, aber der -ohnehin nötige Einarbeitungsaufwand dürfte bei beiden etwa gleich sein. +Funktionalit"at. Die Bedienung unterscheidet sich zwar deutlich, aber der +ohnehin n"otige Einarbeitungsaufwand d"urfte bei beiden etwa gleich sein. Auch beim Kompilieren dieser Bootloader sind die Unterschiede nicht gross. Beide zeichnen sich durch schwer durchschaubaren Sourcecode und ein eigenwilliges Buildsystem aus. -Es gibt aber auch die Möglichkeit, ganz auf einen derartigen Bootloader zu +Es gibt aber auch die M"oglichkeit, ganz auf einen derartigen Bootloader zu verzichten. Statt dessen verwendet man einen minimalen \emph{Initial Program -Loader (IPL)}, der lediglich die rudimentären Initialisierungsaufgaben -erfüllt und danach einen minimalen Bootkernel lädt und ausführt. Dieser -lädt wiederum den eigentlichen Produktiv-Kernel nach. +Loader (IPL)}, der lediglich die rudiment"aren Initialisierungsaufgaben +erf"ullt und danach einen minimalen Bootkernel l"adt und ausf"uhrt. Dieser +l"adt wiederum den eigentlichen Produktiv-Kernel nach. -Vorteile der letztgenannten Vorgehensweise sind hohe Flexibilität und die +Vorteile der letztgenannten Vorgehensweise sind hohe Flexibilit"at und die Tatsache, dass man im Bootkernel schon nach wenigen hundert Millisekunden -jeden gewünschten Treiber zur Verfügung hat. Dadurch können in elegante +jeden gew"unschten Treiber zur Verf"ugung hat. Dadurch k"onnen in elegante Weise Anforderungen wie das Anzeigen eines Bildes auf einem TFT (500 -Millisekunden nach dem Einschalten) gelöst werden. Wollte man dies mit -einem der oben erwähnten Bootloader erreichen, müsste man zunächst die -für das TFT benötigten Treiber vom Kernel in den Bootloader portieren und -dort zum Laufen bringen. Ähnliches gilt für andere gängige Forderungen, +Millisekunden nach dem Einschalten) gel"ost werden. Wollte man dies mit +einem der oben erw"ahnten Bootloader erreichen, m"usste man zun"achst die +f"ur das TFT ben"otigten Treiber vom Kernel in den Bootloader portieren und +dort zum Laufen bringen. "Ahnliches gilt f"ur andere g"angige Forderungen, wie das Booten von einem USB-Stick. -Es erscheint als überflüssige Mühe, einen im Kernel bereits -funktionierenden Treiber in den Bootloader portieren zu müssen. Mit IPL und -Bootkernel sind ausserdem komplexe Aufgaben während des Bootvorgangs, +Es erscheint als "uberfl"ussige M"uhe, einen im Kernel bereits +funktionierenden Treiber in den Bootloader portieren zu m"ussen. Mit IPL und +Bootkernel sind ausserdem komplexe Aufgaben w"ahrend des Bootvorgangs, beispielsweise automatisierte und sichere Firmware-Updates leicht realisierbar. \subsubsection{Bootprobleme: Im Bootloader} -Während der Entwicklungsphase sind Probleme im Bootloader besonders -unangenehm. Falls dieser bereits abstürzt, ehe er die serielle Schnittstelle +W"ahrend der Entwicklungsphase sind Probleme im Bootloader besonders +unangenehm. Falls dieser bereits abst"urzt, ehe er die serielle Schnittstelle initialisieren konnte, so sieht man schlichtweg gar nichts. Aber auch bei -späteren Fehlern ist der Entwicklungszyklus mühsam, da man den Bootloader -meist erst mit einem JTAG-Adapter oder ähnlichen Werkzeugen ins Flash des -Boards befördern muss, bevor man den nächsten Versuch machen kann. Bei -Änderungen am Bootloader-Code ist daher große Sorgfalt geboten. Wenn möglich, -sollte man zu zweit an solchem Code arbeiten und sich ständig gegenseitig +sp"ateren Fehlern ist der Entwicklungszyklus m"uhsam, da man den Bootloader +meist erst mit einem JTAG-Adapter oder "ahnlichen Werkzeugen ins Flash des +Boards bef"ordern muss, bevor man den n"achsten Versuch machen kann. Bei +"Anderungen am Bootloader-Code ist daher gro\ss e Sorgfalt geboten. Wenn m"oglich, +sollte man zu zweit an solchem Code arbeiten und sich st"andig gegenseitig kontrollieren. -Häufige Problemquellen im Bootloader sind beispielsweise: +H"aufige Problemquellen im Bootloader sind beispielsweise: \begin{itemize} \item Der Bootloader wurde nicht korrekt ins Flash geschrieben. In einem Fall passierte dies beispielsweise, wenn der Compiler ein Binary mit - ungerader Länge erzeugte. Aber auch falsche Konfiguration des JTAGer - kann zu solchen Problemen führen. -\item Im Bootloader wurden die Timings für Bus-Schnittstellen wie RAM oder + ungerader L"ange erzeugte. Aber auch falsche Konfiguration des JTAGer + kann zu solchen Problemen f"uhren. +\item Im Bootloader wurden die Timings f"ur Bus-Schnittstellen wie RAM oder Flash nicht korrekt eingestellt. Gerade wenn die Timings nicht ganz falsch, sondern nur grenzwertig sind, kann es zu schwer reproduzierbaren Bootproblemen kommen. -\item Die Ladeadresse für den Kernel ist nicht korrekt. Bei manchen +\item Die Ladeadresse f"ur den Kernel ist nicht korrekt. Bei manchen Bootloadern kann es leicht zu Verwechslungen zwischen physikalischen und virtuellen Adressen kommen. Weder U-Boot noch Redboot melden - einen Fehler, wenn man den Kernel an eine Adresse lädt, an der - sich überhaupt kein RAM befindet... -\item Beim Laden des Kernels per TFTP kann es zusätzlich weitere Probleme - geben, die mit dem Netzwerk zusammenhängen. Diese reichen von falsch - aufgesetzten TFTP-Servern über falsch konfigurierte DHCP-Server oder + einen Fehler, wenn man den Kernel an eine Adresse l"adt, an der + sich "uberhaupt kein RAM befindet... +\item Beim Laden des Kernels per TFTP kann es zus"atzlich weitere Probleme + geben, die mit dem Netzwerk zusammenh"angen. Diese reichen von falsch + aufgesetzten TFTP-Servern "uber falsch konfigurierte DHCP-Server oder falschen IP-Adressen bis hin zu Treiber- oder Hardware-Problemen. \end{itemize} @@ -104,46 +104,46 @@ Häufige Problemquellen im Bootloader sind beispielsweise: Bootprobleme im Kernel sind vergleichsweise einfach zu finden, sobald man eine Konsole auf der seriellen Schnittstelle hat. Der Kernel gibt meist recht -aussagekräftige Fehlermeldungen und bietet viele zusätzliche Debug-Funktionen, +aussagekr"aftige Fehlermeldungen und bietet viele zus"atzliche Debug-Funktionen, die man in der Kernel-Konfiguration aktivieren kann. Falls sich der Kernel -bereits früher aufhängt, so dass man nach der Meldung +bereits fr"uher aufh"angt, so dass man nach der Meldung \cmd{Uncompressing Linux.....} -überhaupt nichts mehr sieht, dann wird es schwieriger. Man sollte zunächst -überprüfen, ob die im Bootloader vorgegebene Commandline für den Kernel -korrekt ist, insbesondere die Einstellung der für die Konsole verwendeten +"uberhaupt nichts mehr sieht, dann wird es schwieriger. Man sollte zun"achst +"uberpr"ufen, ob die im Bootloader vorgegebene Commandline f"ur den Kernel +korrekt ist, insbesondere die Einstellung der f"ur die Konsole verwendeten seriellen Schnittstelle (\cmd{console=tty...}). -Ein weiteres gängiges Problem ist, dass der Kernel am Ende des Bootvorgangs +Ein weiteres g"angiges Problem ist, dass der Kernel am Ende des Bootvorgangs kein Root-Filesystem mounten kann. Dies kann daran liegen, dass man bei der -Kernelkonfiguration vergessen hat, dass \emph{alle} für das Rootfs nötigen -Hardware- und Dateisystem-Treiber in den Kernel einkompiliert sein müssen +Kernelkonfiguration vergessen hat, dass \emph{alle} f"ur das Rootfs n"otigen +Hardware- und Dateisystem-Treiber in den Kernel einkompiliert sein m"ussen und nicht etwa als Module gebaut wurden. Bei Medien, die erst detektiert -werden müssen (z.B. SD-Karten) kann es passieren, dass das Medium noch nicht +werden m"ussen (z.B. SD-Karten) kann es passieren, dass das Medium noch nicht bereit ist, wenn der Kernel es mounten will. In diesem Fall hilft der Parameter \cmd{rootwait}. Falls der Kernel zwar das Rootfs mounten kann, aber danach mit einer -Fehlermeldung hängen bleibt, anstatt \cmd{/sbin/init} zu starten, dann +Fehlermeldung h"angen bleibt, anstatt \cmd{/sbin/init} zu starten, dann liegt dies oft an fehlenden Device-Nodes im Verzeichnis \cmd{/dev}. -Überprüfen Sie dies. +"Uberpr"ufen Sie dies. \subsubsection{Bootprobleme: In den Startskripten} Wenn der Kernel erfolgreich das Rootfs mounten und \cmd{/sbin/init} starten konnte, wird letzteres versuchen, die in \cmd{/etc/inittab} angegebenen -Anweisungen auszuführen. Dies ist normalerweise zunächst der Aufruf eines +Anweisungen auszuf"uhren. Dies ist normalerweise zun"achst der Aufruf eines Startskripts, das in der Regel weitere Skripte und Programme aufruft. Je nach Art der aufgerufenen Programme kann es hier zu weiteren Problemen -kommen. Dazu gehören etwa fehlerhafte Konfigurationsdateien, fehlende -Device-Nodes oder Ähnliches. +kommen. Dazu geh"oren etwa fehlerhafte Konfigurationsdateien, fehlende +Device-Nodes oder "Ahnliches. Ausserdem kommt es bei Startskripten vor, dass diese nicht auf jede Situation sauber und fehlertolerant reagieren. Man sollte vermeiden, dass sich das -Skript zur Konfiguration des Netzwerks aufhängt, wenn kein DHCP-Server +Skript zur Konfiguration des Netzwerks aufh"angt, wenn kein DHCP-Server gefunden wurde oder kein Netzwerkkabel eingesteckt ist. Des weiteren sollte -das Skript selber erkennen, wenn über die Netzwerkschnittstelle das Rootfs +das Skript selber erkennen, wenn "uber die Netzwerkschnittstelle das Rootfs per NFS gemountet wurde, und dann eine Neukonfiguration tunlichst unterlassen. \input{tailhandout} diff --git a/linux-basics/what-is-linux/handout_what-is-linux_de.tex b/linux-basics/what-is-linux/handout_what-is-linux_de.tex index 2ae9b03..c793fe6 100644 --- a/linux-basics/what-is-linux/handout_what-is-linux_de.tex +++ b/linux-basics/what-is-linux/handout_what-is-linux_de.tex @@ -4,8 +4,8 @@ \subsubsection{Geschichtlicher Hintergrund} -Frühe elektronische Rechner, wie der in Abbildung \ref{img:eniac} gezeigte -ENIAC, waren nicht frei programmierbar. Sie wurden für einen bestimmten +Fr\"uhe elektronische Rechner, wie der in Abbildung \ref{img:eniac} gezeigte +ENIAC, waren nicht frei programmierbar. Sie wurden f\"ur einen bestimmten Zweck gebaut, der ENIAC beispielsweise zur Berechnung von ballistischen Flugbahnen. @@ -21,14 +21,14 @@ weiter, was vor allem durch die Erfindung des Transistors beschleunigt wurde. Mit der freien Programmierbarkeit kam gleichzeitig die Nachfrage nach einem Betriebssystem. Zum einen stellte man schnell fest, das bestimmte Operationen, etwa Ein- und Ausgabe-Funktionen, von nahezu jedem Programm immer wieder -benötigt wurden. Zum anderen hatte man bald den Wunsch nach größerer -Hardware-Unabhängigkeit, damit ein einmal geschriebenes Programm ohne große -Änderungen auf verschiedenen Rechnern laufen konnte. +ben\"otigt wurden. Zum anderen hatte man bald den Wunsch nach gr\"o \ss erer +Hardware-Unabh\"angigkeit, damit ein einmal geschriebenes Programm ohne gro\ss e +\"Anderungen auf verschiedenen Rechnern laufen konnte. -Die ersten Ansätze für ein universelles Betriebssystem blieben mehr oder +Die ersten Ans\"atze f\"ur ein universelles Betriebssystem blieben mehr oder weniger erfolglos. Die Entwickler verzettelten sich mit immer neuen Anforderungen und wenig durchdachten Konzepten. Die Systeme wurden -unüberschaubar und für viele der damaligen Rechner zu gross. +un\"uberschaubar und f\"ur viele der damaligen Rechner zu gross. Erst das ab 1969 von Ken Thompson und Dennis Ritchie (Abbildung \ref{img:ken_ritchie}) entwickelte \emph{Unix} konnte sich auf @@ -41,10 +41,10 @@ breiter Ebene durchsetzen und zu einem Standard entwickeln. \label{img:ken_ritchie} \end{figure} -In der zweiten Hälfte der 70-er Jahre veränderte sich der Computer-Markt -radikal. Die Erfindung der integrierten Schaltung ermöglichte es, kleine und -auch für Normalbürger erschwingliche Computer zu bauen. Dadurch entwickelte -sich der bisher auf Hochschulen, Behörden und Großbetriebe beschränkte Markt +In der zweiten H\"alfte der 70-er Jahre ver\"anderte sich der Computer-Markt +radikal. Die Erfindung der integrierten Schaltung erm\"oglichte es, kleine und +auch f\"ur Normalb\"urger erschwingliche Computer zu bauen. Dadurch entwickelte +sich der bisher auf Hochschulen, Beh\"orden und Gro\ss betriebe beschr\"ankte Markt zum Massenmarkt. \begin{figure}[h] @@ -55,114 +55,114 @@ zum Massenmarkt. \end{figure} Als etwas ausgereiftere Homecomputer wie der Apple 2 (Abbildung \ref{img:apple2}) -zunehmend auch in Betrieben als Ergänzung zu den vorhandenen Großrechnern, +zunehmend auch in Betrieben als Erg\"anzung zu den vorhandenen Gro\ss rechnern, beispielsweise als `intelligente' Terminals, eingesetzt wurden, beschloss -IBM, Marktführer bei Großrechnern, dem etwas entgegen zu setzen. Man +IBM, Marktf\"uhrer bei Gro\ss rechnern, dem etwas entgegen zu setzen. Man entwickelte den IBM-PC, der 1981 erschien. Durch die sehr knappen -Zeitvorgaben war es den Entwicklern nur möglich, bereits am Markt befindliche +Zeitvorgaben war es den Entwicklern nur m\"oglich, bereits am Markt befindliche Standard-Chips einzusetzen. Dadurch gelang es Firmen wie Compaq in kurzer Zeit, selbst ``IBM-kompatible'' Rechner auf den Markt zu werfen. Auch auf Unix hatte diese Entwicklung Einfluss. Bis dahin war Unix im -universitären Umfeld entwickelt worden. Die Rechte am Code besaß zwar AT+T, +universit\"aren Umfeld entwickelt worden. Die Rechte am Code besa\ss zwar AT+T, er wurde aber ohne weiteres kostenlos an Dritte weitergegeben, vor allem -zu Ausbildungszwecken. Es gab ja fast niemanden, der einen Unix-fähigen -Computer besaß. Mit dem beginnenden Massenmarkt sah AT+T die Chance, mit +zu Ausbildungszwecken. Es gab ja fast niemanden, der einen Unix-f\"ahigen +Computer besa\ss . Mit dem beginnenden Massenmarkt sah AT+T die Chance, mit Lizenzen Geld zu verdienen, und machte Unix zu Closed Source. Auch zu -Ausbildungszwecken war der Code nicht mehr verfügbar. +Ausbildungszwecken war der Code nicht mehr verf\"ugbar. -Durch diese Lizenzänderung war es vielen Unix-Programmierern nicht mehr +Durch diese Lizenz\"anderung war es vielen Unix-Programmierern nicht mehr gestattet, ihre eigenen Programme zu nutzen. Einer von ihnen, Richard -Stallman, gründete daraufhin 1984 die \emph{Free Software Foundation} und -begann, ein eigenes Unix namens \emph{GNU} völlig neu zu schreiben. Um -die eben gemachten Erfahrungen reicher, entwickelte er für den Code eine +Stallman, gr\"undete daraufhin 1984 die \emph{Free Software Foundation} und +begann, ein eigenes Unix namens \emph{GNU} v\"ollig neu zu schreiben. Um +die eben gemachten Erfahrungen reicher, entwickelte er f\"ur den Code eine eigene Lizenz, die \emph{GNU Public License (GPL)}. Sie stellt sicher, dass -bei Weitergabe eines Programms der Empfänger immer auch ein Recht auf den +bei Weitergabe eines Programms der Empf\"anger immer auch ein Recht auf den Sourcecode hat. Dem GNU-Projekt schlossen sich schnell weitere Programmierer an, und es gelang ihnen in relativ kurzer Zeit, die Grundlagen eines Unix-Systems zu -erstellen. Dazu gehörten neben den vielen kleinen Unix-Systemprogrammen vor +erstellen. Dazu geh\"orten neben den vielen kleinen Unix-Systemprogrammen vor allem auch der Compiler gcc und der Editor Emacs. Beim Kernel war man weniger -glücklich: Man entschied sich für ein zwar theoretisch interessantes, aber in +gl\"ucklich: Man entschied sich f\"ur ein zwar theoretisch interessantes, aber in der Praxis schlecht handhabbares Microkernel-Konzept. Dieser Kernel (\emph{GNU Hurd}) ist bis heute nicht produktiv einsetzbar... 1991 hatte der finnische Student Linus Torvalds einen Terminal-Emulator geschrieben, mit dem er von daheim per Modem auf den Unix-Rechner der -Universität zugreifen konnte. Als er immer mehr Funktionen hinzufügte, etwa +Universit\"at zugreifen konnte. Als er immer mehr Funktionen hinzuf\"ugte, etwa einen Treiber zum Direktzugriff auf seine Harddisk, bemerkte er, dass er eigentlich auch gleich einen Betriebssystem-Kernel schreiben konnte. Er beschaffte sich die POSIX-Spezifikation, in der die Schnittstellen eines Unix-Kernels beschrieben sind, und implementierte eine Funktion nach der anderen. -Nachdem dieser Kernel unter dem Namen \emph{Linux} veröffentlicht war, +Nachdem dieser Kernel unter dem Namen \emph{Linux} ver\"offentlicht war, schlossen sich ebenfalls schnell hunderte von Programmierern an und arbeiteten an der Weiterentwicklung mit. Durch Kombination des -GNU-Betriebssystems mit dem Linux-Kernel entstand so ein vollständig aus +GNU-Betriebssystems mit dem Linux-Kernel entstand so ein vollst\"andig aus freier Software bestehendes System. Der Begriff ``Linux'' bezeichnet also streng genommen nur den Kernel. -Allerdings hat es sich mittlerweile im Sprachgebrauch eingebürgert, das +Allerdings hat es sich mittlerweile im Sprachgebrauch eingeb\"urgert, das komplette System aus Programmen und Kernel als ``Linux'' zu bezeichnen. -\subsubsection{Ein Betriebssystem für Großrechner} +\subsubsection{Ein Betriebssystem f\"ur Gro\ss rechner} -Unix war von Anfang an ein Betriebssystem, das für den Betrieb auf -Großrechnern ausgelegt ist. Das verwundert nicht weiter, den zur Zeit +Unix war von Anfang an ein Betriebssystem, das f\"ur den Betrieb auf +Gro\ss rechnern ausgelegt ist. Das verwundert nicht weiter, den zur Zeit seiner Entstehung gab es noch keine Einzelplatzrechner im Sinne des heutigen PC. Die mit dieser Anwendung verbundenen Design-Entscheidungen -sind auch heute noch wirksam und bestimmen maßgeblich das Verhalten von +sind auch heute noch wirksam und bestimmen ma\ss geblich das Verhalten von Linux-Systemen. -Durch die freie Verfügbarkeit von Linux gab und gibt es ausserdem zahlreiche +Durch die freie Verf\"ugbarkeit von Linux gab und gibt es ausserdem zahlreiche Anwender mit ganz unterschiedlichen Anforderungen. Von Cluster-basierten Datenbankservern bis zu kleinen batteriebetriebenen PDAs ist alles vertreten. -Des weiteren werden sehr viele verschiedene Prozessor-Familien unterstützt. -Dadurch war der Kernel schon sehr früh 64-Bit- und Endian-fest. +Des weiteren werden sehr viele verschiedene Prozessor-Familien unterst\"utzt. +Dadurch war der Kernel schon sehr fr\"uh 64-Bit- und Endian-fest. Diesem historischen Hintergrund ist es zu verdanken, dass der Linux-Kernel heute sehr gut mit verschiedensten Hardware-Eigenschaften skaliert. Aus dem -selben Source-Code kann ein Kernel für einen Server mit 1024 CPU-Kernen -oder ein Kernel für ein kleines Embedded-System konfiguriert und erzeugt +selben Source-Code kann ein Kernel f\"ur einen Server mit 1024 CPU-Kernen +oder ein Kernel f\"ur ein kleines Embedded-System konfiguriert und erzeugt werden. \subsubsection{Multiuser-Betrieb} Eine weitere wichtige Eigenschaft von Linux, die sich aus der -Großrechner-Tradition ergibt, ist die Multitasking- und Multiuser-Fähigkeit. -Während Multitasking, also das quasi-gleichzeitige Ausführen mehrerer -Programme, heute jedem Computer-Anwender als Selbstverständlichkeit gilt, -verdient der Multiuser-Betrieb nähere Betrachtung. +Gro\ss rechner-Tradition ergibt, ist die Multitasking- und Multiuser-F\"ahigkeit. +W\"ahrend Multitasking, also das quasi-gleichzeitige Ausf\"uhren mehrerer +Programme, heute jedem Computer-Anwender als Selbstverst\"andlichkeit gilt, +verdient der Multiuser-Betrieb n\"ahere Betrachtung. Multiuser-Betrieb bedeutet, dass mehrere Anwender \emph{gleichzeitig} mit dem -System arbeiten können. Jeder Anwender hat dabei den Eindruck, dass ihm das -System allein gehört. Das Betriebssystem muss dazu Funktionalität -bereitstellen, um die Datensicherheit zu gewährleisten und die gerechte -Verteilung der Ressourcen unter den Benutzern sicherzustellen. Dazu gehört +System arbeiten k\"onnen. Jeder Anwender hat dabei den Eindruck, dass ihm das +System allein geh\"ort. Das Betriebssystem muss dazu Funktionalit\"at +bereitstellen, um die Datensicherheit zu gew\"ahrleisten und die gerechte +Verteilung der Ressourcen unter den Benutzern sicherzustellen. Dazu geh\"ort unter anderem, dass alle Dateien und Verzeichnisse mit Benutzerkennungen -versehen werden, die jedem Benutzer sinnvolles Arbeiten ermöglichen, aber -gleichzeitig seinen Zugriff auf fremde Daten einschränken. Diese -Einschränkungen müssen im Kernel realisiert werden, damit sie nicht auf -Anwenderebene umgangen werden können. +versehen werden, die jedem Benutzer sinnvolles Arbeiten erm\"oglichen, aber +gleichzeitig seinen Zugriff auf fremde Daten einschr\"anken. Diese +Einschr\"ankungen m\"ussen im Kernel realisiert werden, damit sie nicht auf +Anwenderebene umgangen werden k\"onnen. -In Unix war diese Funktionalität per Design schon immer vorhanden, während +In Unix war diese Funktionalit\"at per Design schon immer vorhanden, w\"ahrend aus der Tradition der Einzelplatz-Rechner entstandene Betriebssysteme wie DOS -oder Windows dies bis heute nicht leisten. Natürlich ist die freie Lizenz -von Linux hier ebenfalls von Vorteil. Proprietäre Betriebssysteme haben -schon aus Lizenzgründen ein Problem damit, wenn mehrere Anwender einen -Rechner nutzen können. +oder Windows dies bis heute nicht leisten. Nat\"urlich ist die freie Lizenz +von Linux hier ebenfalls von Vorteil. Propriet\"are Betriebssysteme haben +schon aus Lizenzgr\"unden ein Problem damit, wenn mehrere Anwender einen +Rechner nutzen k\"onnen. \subsubsection{Login} -Beim Hochfahren eines Linux-Systems werden üblicherweise alle für den +Beim Hochfahren eines Linux-Systems werden \"ublicherweise alle f\"ur den Systemstart vorgesehenen Programme automatisch gestartet, ohne dass dazu -ein Benutzereingriff nötig wäre. Durch Anpassung der dafür verantwortlichen +ein Benutzereingriff n\"otig w\"are. Durch Anpassung der daf\"ur verantwortlichen Startskripte kann man so auch seine eigenen Applikationen starten. An dieser Stelle hat man root-Rechte, also vollen Zugriff auf alle Ressourcen. -Möchte nach dem Hochfahren ein Benutzer mit dem System arbeiten, so muss +M\"ochte nach dem Hochfahren ein Benutzer mit dem System arbeiten, so muss er dem System mitteilen, wer er ist, und dies gegebenenfalls durch einen Authentifizierungsprozess glaubhaft machen. Diesen Vorgang nennt man ``Login''. @@ -170,34 +170,34 @@ Authentifizierungsprozess glaubhaft machen. Diesen Vorgang nennt man \begin{figure}[h] \centering \includegraphics[width=0.3\textwidth]{images/CPU_und_Terminals1-600px.png} -\caption{Schematische Darstellung eines Großrechners} +\caption{Schematische Darstellung eines Gro\ss rechners} \label{img:mainframe} \end{figure} Abbildung \ref{img:mainframe} zeigt die Situation in schematischer Weise. Am -Großrechner sind mehrere Terminals angeschlossen. Früher waren dies +Gro\ss rechner sind mehrere Terminals angeschlossen. Fr\"uher waren dies Fernschreiber, daher die Bezeichnung tty (von engl. teletype). Auf Abbildung \ref{img:ken_ritchie} kann man dies sehen -- da gab es noch keine Monitore. Unter Linux sind dies sogenannte \emph{virtuelle Terminals}. Selbst auf einem Laptop, der an nichts anderes angeschlossen ist, hat man mehrere solcher -virtueller Terminals zur Verfügung. Eines davon wird meist von der grafischen -Oberfläche benutzt. +virtueller Terminals zur Verf\"ugung. Eines davon wird meist von der grafischen +Oberfl\"ache benutzt. -Zusätzlich gibt es weitere physikalische Terminals, so haben beispielsweise +Zus\"atzlich gibt es weitere physikalische Terminals, so haben beispielsweise serielle Schnittstellen Bezeichnungen wie ttyS0, ttyS1 und so weiter. Jedes -dieser Terminals ist völlig autark, das heisst, man muss sich in jedem +dieser Terminals ist v\"ollig autark, das heisst, man muss sich in jedem Terminal erneut einloggen und authentifizieren. -Logins sind unter Linux auf mehreren Wegen möglich. Ausser dem von Desktops +Logins sind unter Linux auf mehreren Wegen m\"oglich. Ausser dem von Desktops her gewohnten Login am Bildschirm kann man sich auch mit Hilfe eines -Terminal-Programms über eine serielle Schnittstelle einloggen. Weit verbreitet -sind auch Logins über Netzwerkprotokolle wie ssh oder telnet. +Terminal-Programms \"uber eine serielle Schnittstelle einloggen. Weit verbreitet +sind auch Logins \"uber Netzwerkprotokolle wie ssh oder telnet. -Da diese Login-Möglichkeiten unter Windows nicht üblich sind, kommt es hier -häufig zu Verständnisschwierigkeiten. Als Übung sollten Sie sich per ssh +Da diese Login-M\"oglichkeiten unter Windows nicht \"ublich sind, kommt es hier +h\"aufig zu Verst\"andnisschwierigkeiten. Als \"Ubung sollten Sie sich per ssh auf einem entfernten Rechner einloggen und dann ein Programm starten. Machen -Sie sich klar, dass das Programm auf dem entfernten Rechner ausgeführt wird +Sie sich klar, dass das Programm auf dem entfernten Rechner ausgef\"uhrt wird und nicht etwa auf dem Rechner, an dem Sie gerade sitzen. \newpage @@ -207,7 +207,7 @@ und nicht etwa auf dem Rechner, an dem Sie gerade sitzen. \begin{enumerate} \item Wie alt ist das Unix-Konzept mittlerweile? \item Seit wann gibt es den Linux-Kernel? -\item Warum ist die Großrechner-Tradition von Linux auch für Embedded Systems +\item Warum ist die Gro\ss rechner-Tradition von Linux auch f\"ur Embedded Systems von Vorteil? \item Was passiert beim Login-Vorgang? \end{enumerate} |