TU Wien:Betriebssysteme UE (Puschner)

Aus VoWi
Wechseln zu: Navigation, Suche

Im Rahmen der Studienplanänderung 2011 der Technischen Universität Wien wurde "Systemprogrammierung VL" in "Betriebssysteme UE" umbenannt. Die beiden LVAs sind daher äquivalent.

  • Studierende der TU, die im WS11 oder später mit ihrem Studium begonnen haben, können nur die LVA mit neuem Titel, sofern sie noch nach dem "Studienplan" ein Pflicht-/Wahlfach ist, für ihren Abschluss verwenden.
  • Studierende der TU, die bereits vor dem WS11 inskribiert waren, müssen genau eine dieser beiden LVAs absolvieren.

Für Details siehe auch FAQ Studienplan 2011.



Daten[Bearbeiten]

Ein gleichzeitiges Absolvieren mit Betriebssysteme VO (Puschner) ist sinnvoll, da sich die Theorie (Semaphoren, ...) teilweise überschneidet.

Inhalt[Bearbeiten]

Systemnahe Programmierung auf *NIX Systemen mit C.

Ziel ist das Verstehen von und Arbeiten mit Files, Commandline Parametern, Eltern-/Kindprozesse, named/unnamed Pipes, Shared Memory und Semaphoren. (Im WS15 wurden Message Queues und Sequencer nicht mehr behandelt)

Benötigte Vorkenntnisse[Bearbeiten]

Es sind keine Vorkenntnisse für die LVA angegeben. Dennoch ist die Kenntnis zumindest einer imperativen Programmiersprache wie z.B. Java sehr stark empfohlen. (z.B. aus Einführung in das Programmieren).

Auch sollte sich jeder Student ausführlich mit emacs und/oder vi(m) vor allem ohne Plugins vertraut sein. Persönliche Settings/configs sind beim Test verboten.

(WS17) Bei den Tests kann auf die vorinstallierte Software im TILab zurückgegriffen werden (also auch IntelliJ - kein mühsames lernen vom vim/emacs ist notwendig)

(SS18) Es war u.A. Atom, Emacs, IntelliJ und Visual Studio Code verfügbar. (VS Code leider ohne C-Extension, somit war keine IntelliSense und kein integriertes Debugging vorhanden; GDB-Kentnisse sind also weiterhin notwendig)

Hilfreiche Vorkenntnisse[Bearbeiten]

C-Kenntnisse sind am LVA-Beginn zwar nicht notwendig, aber hilfreich (Flags setzen, dynamischen Speicher allokieren, Pointers, usw.).

Andere Meinung: Ohne C-Kenntnisse ist diese LVA meiner Meinung nach nicht ohne erheblichen Mehraufwand schaffbar.

Es ist weiters von Vorteil, schon einmal auf einem *NIX System (Linux, (Free|Net|Open)BSD, ... ) gearbeitet zu haben. Das gilt vor allem für Erfahrung mit der Kommandozeile.

Vortrag[Bearbeiten]

Der Vorlesungsteil wird von verschiedenen Vortragenden abgehalten. Von interessanten und hilfreichen Vorträgen bis hin zum reinen Vorlesen der Folien ist alles dabei. Grundsätzlich ist es aber mit Buch und Folien kein Problem die LVA ohne Vorlesungsbesuch zu absolvieren.

Ablauf[Bearbeiten]

Die LVA besteht aus 3 Übungsbeispielen (zu je 20 Punkten) und 2 Übungstests (60 + 80 Punkte). Seit dem SS2010 werden die Übungstests am Computer gemacht. Der erste Test besteht aus dem Stoff des ersten Übungsbeispiels. Ehemals wurde angeboten 2 von 3 gestellten Beispielen zu implementieren (makefile oder Fehlersuche in einem vorgegebenen Programmcode und ein einfacher Client), diese Auswahl gab es 2013 nicht mehr. Beim zweiten Übungstest wird zunächst ein Theorie-MC-Test am Papier gemacht (elektronische Auswertung). Die Fragen dieses Tests werden aus einem Pool per Zufall ausgewählt und können einfache und schwere Fragen enthalten (Anmerkung: dies ist im WS 17/18 nicht mehr der Fall, da automatisch ausgewertet wird). Alles in allem ist der Theorieteil aber recht leicht.

Gute Vorbereitung (dabei helfen gelöste Programmierbeispiele), Beherrschen der man-Pages und Ruhe sind wichtig bei der Absolvierung der Tests. Die vorgegebene Zeit kann bei den kleinsten Problemen schon sehr knapp werden. Da die Bewertung vom Computer vorgenommen wird, können kleinste Fehler gravierend ins Gewicht fallen (z.B. Programm compiliert mit Warnings). Bei den Tests dürfen keine Unterlagen verwendet werden. Davon ausgenommen sind jedoch die man-Pages, die am Testrechner vorhanden sind (Anm.: allerdings ist unischer ob die Suche über apropos oder whatis verwendbar ist)

Für Leute, die zu Hause keinen Zugriff auf ein *NIX-System haben, werden Computer im TI-Lab zur Verfügung gestellt. Es besteht auch die Möglichkeit, sich direkt auf dem Server per SSH einzuloggen.

Es ist dringend zu empfehlen, alle Abgaben auf einem der Übungsrechner zu testen oder zu machen (egal ob lokal oder per SSH). Nichts ist ärgerlicher als Punkte zu verlieren, weil die etwas andere gcc-Version dort eine Warnung ausspuckt, die lokal nicht kommt. Worst Case wäre, dass das Programm dort gar nicht kompiliert. In diesem Fall würde dein Programm abgelehnt und du bekommst 0 Punkte. Das Testen der Abgabe ist vor allem für jene Personen relevant, die auf einer VM arbeiten, weil fork() u.a. in Windows ein anderes Verhalten aufweisen als auf Linux/*NIX.

Andere Meinung: Ich würde das nicht so streng sehen. Ich hab alle Aufgaben auf meinem Ubuntu 9.10 geschrieben und niemals im Lab ausprobiert. Bei der Abgabe hat es auch im Lab wunderbar funktioniert. 3.Meinung: bei mir gabs z.B. nach Programmierung auf einem 32-linux system unerwartet nicht ganz nochvollziehbare Warnings auf den 64bit laborrechnern die dann zu Punkteabzügen führten, also ich würde auch empfehlen, das Programm auf den Abgabesystemen zu testen.

Bemerkung: laut Vorbesprechung im WS11 sind auf den ersten Test 25 von 60 Punkte oder ein positiv absolviertes Quiz nötig. Insgesamt müssen für eine positive Note auf 1. plus 2. Test >= 60 Punkte erreicht werden und plus Beispiele ohne Bonus >= 100 Punkte. Insgesamt können 200 Punkte erreicht werden, ab 100 G4, ab 125 B3, ab 150 G2, ab 175 S1.

Im Diskussionsbereich finden sich weitere Kommentare zu den Tests, und bei den Materialien finden sich Ausarbeitungen zu den Tests im Informatik-Forum. Es gab 2013 einen Beispieltest der dann allerdings deutlich einfacher gehalten war als der dann tatsächliche stattfindende erste Test (Inhalt 1.Test waren 2Bsp.: Erstens Befehle und Argumente dazu die aus Void pointern Arrays ausgelesen und ausgeführt werden mussten und zweitens einen abgesehen vom command line parsing vollständig auszuprogrammierenden TCP Client der Nachrichten aus einer Datei ausliest und diese byteweise mittles pre-shared-key XOR ver-/entschlüsselt an den Server sendet und wieder byteweise vom Server empfängt und rückentschlüsselt.)

Tipps[Bearbeiten]

  • Im Buch steht fast alles in Musterbeispielen drinnen (es kann viel Code 1:1 aus dem Buch abgeschrieben werden) -> Buch lesen und verstehen, es ist einfach geschrieben.
  • Den ersten Übungstest nicht unterschätzen, der zweite wird schwerer.
  • Sobald man einmal den ersten Übungstest geschafft hat, ist der restliche Zeitaufwand zu vernachlässigen (je nach Beispiel) (pro Bsp 1-2 Tag(e), 2 Test Bsps ein bischen anschauen).
  • Es wird großer Wert auf "defensive Programmierung" (Überprüfung aller Rückgabewerte usw.) gelegt.
  • Tutoren können bei Problemen kompetent Rat geben.
  • Die Programmierrichtlinien unbedingt beachten!
  • Da die Themengebiete bei den Tests schon vorher bekannt sind hilft es sich schon vorher die hilfreichen Man-Pages rauszusuchen und als Vorbereitung ein Beispiel zu programmieren bei dem ausschließlich die Man-Pages verwendet werden (kein Google verwenden, das hat man beim Test auch nicht!)
  • Falls du noch nicht so gut mit C vertraut bist, fang rechtzeitig an, dich mit dem Stoff auseinanderzusetzen! Die Übungsaufgaben sind schon aufwändig genug - wenn du dir die Programmierkonzepte in C (Pointer etc.) erst bei deren Lösung näher ansiehst, wird das den Aufwand mit großer Wahrscheinlichkeit explodieren lassen.
  • Vorbereitung auf den ersten Test: Viele kleine Programme schreiben die getopt bzw. sockets beinhalten. Die Uebungsbeispiele alleine reichen als Testvorbereitung nicht, da man keine ausreichende Routine aufbauen kann. Client-Server Verbindung im Schlaf (oder durch geschicktes kopieren der man-pages) erstellen koennen erspart einem viel Zeit. Auch sollte man der Angabe nicht zu viel Beachtung schenken, im Code wird in sehr detaillierten Kommentaren darauf hingewiesen was zu implementieren ist.

Literatur[Bearbeiten]

  • Seit dem WS 2010 (vll auch schon länger) wird das Buch "C Programming Language (Second Edition)" von Brian W. Kernigham and Dennis M. Richie verwendet.
  • Früher gab es am Institut ein selbst verfasstes Buch um € 13,00, das den gesamten Stoff der VL abdeckt.
  • Darüber hinaus werden im Laufe des Semesters auf der Homepage der LVA die Folien zu den Vorträgen zum Download bereitgestellt.

Zeitaufwand[Bearbeiten]

Für alle, die schon C-Erfahrung mitbringen, wird sich der Zeitaufwand in Grenzen halten. Ich war leider C-Neuling, und da hab ich dann schon mal für ein Beispiel 3-5 Tage investieren müssen.

Zusätzliche Meinung: Ich konnte schon C programmieren und fand 2 der 3 Beispiele trotzdem ziemlich aufwändig (3-5 Tage). Ein Beispiel konnte man fast 1:1 aus dem angebotenen Tutorial kopieren.

Guter Tipp ist, wenn man mit der Angabe nicht zurecht kommt, einfach mal vom Tutor erklären lassen, so erspart man sich viel "coden ins leere" - und dann vor der Abgabe nochmal abnehmen lassen, dann ist ein hoher Punktezahl garantiert.

Was auch seltsam ist: der Aufwand der unterschiedlichen Angaben variiert sehr deutlich. Und soweit eruiert, gibt es auch keine constraints für Angaben (dh. wenn man bei Bsp1 Angabe A hat heißt das nicht, dass man bei Bsp2 auch Angabe A bekommt - den so könnte der Aufwand wenigsten halbwegs fair verteilt werden). Das heißt es ist abgesehen von den C-Skills dem Zufall überlassen wie hoch der Aufwand werden kann.

Erfahrungsbericht aus dem WS 17/18: Ich hatte schon vorher viele Geschichten aus dieser LVA von meinen Kolleginnen und Kollegen gehört. Grundtenor: Relativ aufwendig, schwere Tests, schon von der ersten Übung an ein solides Verständnis von C bzw. den vorgetragenen Inhalten notwendig. Weil ich vorher noch nie etwas mit C zu tun hatte, habe ich mir einen Monat vor Semesterbeginn "The C Programming Language" (Kernighan/Ritchie) aus der Bibliothek ausgeborgt und bis Semesterbeginn die ersten sieben Kapitel ausgearbeitet (hat meiner Meinung nach auch schon einen großen Teil der Basics abgedeckt, die in der LVA benötigt werden). Ich habe alle Vorlesungen bis auf jene zum Bonusbeispiel besucht. Die erste Übung (1A/B) war dennoch mit einigem Aufwand verbunden, weil einfach viel Code zu schreiben war, wenn das Error-Handling konsequent durchgezogen wurde. Meiner Meinung nach habe ich mir aber auch einiges an Kopfzerbrechen erspart, weil ich immer in den Laborstunden programmiert habe, und die Tutoren so ziemlich jede Frage beantworten konnten.

Als Vorbereitung den ersten Test habe ich ca. eine Woche lang ein Mal am Tag die notwendigen/relevanten Funktionen und Prozeduren (getopt, getaddrinfo/sockets, system I/O, buffered I/O, malloc...) auf Papier geschrieben, damit ich sie mir besser merke und auch die relevanten man-pages zusammengesucht (das socket Beispiel beim Test konnte von "man getaddrinfo" abgeschrieben werden). Zusätzlich habe ich den demo Test gemacht und eine Übung aus dem github repo.

Das hat sich beim Test selbst auch bezahlt gemacht, ich konnte relativ flüssig arbeiten, weil (bis auf das letzte Beispiel) einfach die Konzepte aus der Übung der Reihe nach implementiert werden mussten (also nicht sonderlich viel Code, sondern nur die notwendigen Funktionen aus der Übung). Ergebnis: 60 Punkte, also von den Tests her schon positiv.

Das zweite Beispiel war weniger Aufwand als 1A/B, aber ich hatte auch Glück beim Ziehen der Aufgabe (forksort). Das zweite Beispiel habe ich wieder komplett in den Laborstunden programmiert (2 * 2 Stunden). Beim ersten Abgabegespräch (Beispiel 1A/B und 2) hat auch das meiste gepasst.

Für das dritte Beispiel habe ich sehr lange gebraucht, weil ich noch nie mit Shared Memory/Semaphoren gearbeitet, und auch die Angabe (mrna) anfangs nicht ganz durchgeblickt habe. Bei diesem Beispiel waren die Laborstunden besonders hilfreich, vor allem im Hinblick auf den Synchronisationsablauf mit Server/Client sowie Error Handling. Überraschenderweise habe ich für dieses Beispiel alle Punkte bekommen, obwohl ich dachte (bzw. ganz sicher war), dass ich nicht zu 100% sauber gearbeitet habe (Ressourcenfreigabe u.ä.). An dieser Stelle möchte ich auch den Hinweis geben, dass ausgiebiges Kommentieren (nicht nur bei den Funktionensdeklarationen ein paar Sätze im doxygen Style hinfetzen, sondern auch in Schleifen, "tricky" Stellen etc. die eine oder andere Erklärung hinschreiben) in OSUE bei den Abgabegesprächen sehr geschätzt wird, weil es das Verstehen des Codes für alle Beteiligten sehr viel einfacher macht.

Die Vorbereitung für den zweiten Test war ähnlich wie beim ersten Test. Ich habe mir zusätzlich einmal die Folien durchgelesen bzw. die Zusammenfassung, das hat für zwei Drittel der Punkte aus dem Theorieteil gereicht. Der praktische Teil war deutlich schwerer als beim ersten Test, vor allem weil für etwa die selbe Menge an Code weniger Zeit zur Verfügung steht. Routine und Verständnis der Angabe ist hier noch wichtiger als beim ersten Test. Wer aber schon beim ersten Test gut abgeschnitten hat, konnte beim zweiten Test deutlich entspannter an die Sache rangehen.

Im Endeffekt habe ich die LVA im ersten Anlauf (knapp aber doch) mit einem S1 geschafft. Das war aber auch mit erheblichem Aufwand verbunden. Wer nicht einen Monat in die Vorbereitung investieren möchte, muss damit rechnen, mehr Zeit für die Vorbereitung zum ersten Test einzuplanen. Der Grund ist einfach: Die Tests sind für Neulinge zeitlich eng bemessen, und wer nicht schnell und effizient die Tasks abarbeitet, wird nicht fertig und hat beim zweiten, schwereren Test deutlich mehr Last auf den Schultern. Das eigenständige Lösen der Übungen reicht in OSUE leider nicht, um die notwendige Routine für die Tests aufzubauen. Die 4 ECTS sind meiner Meinung nach gerechtfertigt, das entspricht etwa 6,5 Stunden pro Woche im Semester, wobei in den Wochen zwischen dem ersten und zweiten Test eigentlich nur das dritte Beispiel ins Gewicht fällt.

TL;DR: In die Vorlesungen gehen. Alle Übungen im Labor machen (oder zumindest am Anfang vorbeischauen). Gut auf die Tests vorbereiten (vor allem den ersten). Eine gewissenhafte Vorbereitung ist meiner Ansicht nach in diesem Fach, mehr als in anderen ähnlichen Fächern (FPROG, OOP, VSUE) der Schlüssel zum Erfolg.

Dauer der Zeugnisausstellung[Bearbeiten]

Erfahrungen (nach dem letztem Test; Dauer: Anzahl der Erfahrungen):

  • 1 Monat: 1 (WS16)
  • 1,25 Monate: 1
  • 3 Monate: 1
  • 3,25 Monate: 1 (SS09: 26.06 - 23.09)

Nach Umstellung auf Computertests und Computerbewertung sind die Ergebnisse im SS2010 sehr rasch in myTI zur Verfügung gestanden (ca. 1 Woche nach dem Test). Zeugnis kam ca. 3 Wochen nach dem zweiten Test.

  • Im WS2010, SS2011, SS2015 wurden die Ergebnisse des 2. Tests noch am selben Tag im myTI eingetragen! Rekord :D
  • Im WS2017/18 waren die Ergebnisse des zweiten Tests am folgenden Tag eingetragen, gemeinsam mit den Punkten der letzten Übung

Links[Bearbeiten]

Verbesserungsvorschläge / Kritik[Bearbeiten]

noch offen