TU Wien:Betriebssysteme UE (Puschner)

Aus VoWi
Zur Navigation springen Zur Suche springen
Ähnlich benannte LVAs (Materialien):

Daten[Bearbeiten | Quelltext bearbeiten]

Vortragende Andreas Brandstätter• Axel Brunnbauer• Jie He• David Lung• Peter Puschner
ECTS 4
Aufgezeichnet true
Alias Operating Systems (en)
Ersetzt Systemnahe Programmierung LU (Puschner)
Letzte Abhaltung 2022W
Sprache Deutsch
Abkürzung OSUE
Mattermost betriebssysteme • Register • Mattermost-Infos
Links tiss:182709, eLearning, Homepage
Zuordnungen
Bachelorstudium Wirtschaftsinformatik
Bachelorstudium Medizinische Informatik
Bachelorstudium Software & Information Engineering
Bachelorstudium Technische Informatik


Inhalt[Bearbeiten | Quelltext 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 | Quelltext 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) Update WS20/21: C-extension war diesmal dabei, d.h.: IntelliSense war da. GDB sollte man troztdem bedienen können bei der Prüfung

Ein gleichzeitiges Absolvieren mit Betriebssysteme VO (Puschner) ist sinnvoll, da sich die Theorie (Semaphoren, ...) teilweise überschneidet. Andere Meinung: Sehe ich überhaupt nicht so. Außer Semaphoren sind die beiden Lehrveranstaltungen komplett unabhängig voneinander, selbst das Semaphorenkapitel überschneidet sich geringfügigst. Die beiden LVAs können ohne jeglichen Mehraufwand komplett unabhängig voneinander absolviert werden.

Hilfreiche Vorkenntnisse[Bearbeiten | Quelltext 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 UNIX System (Linux, (Free|Net|Open)BSD, ... ) gearbeitet zu haben. Das gilt vor allem für Erfahrung mit der Kommandozeile.

Meinung WS18: Die UE ist meiner Meinung nach durchaus gut ohne große Vorkenntnisse in C schaffbar. Vorkenntnisse im Programmieren allgemein werden benötigt. Alles C relevante kommt in der Vorlesung zur UE vor. Es hilft allerdings wirklich, wenn man grundlegende Kenntnisse in Linux hat (Programme starten, Files löschen, etc.)

Vortrag[Bearbeiten | Quelltext 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 | Quelltext 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.)

WS20/21: um an der lva teilnehmen zu können war ein einfaches Eingangsquiz notwendig. Dieses wurde auf Tuwel bereitgestellt und war eigentlich nur dazu da die, die doch nicht an der LVA teilnehmen wollten auszusortieren. Der konnte so oft man will ausgeführt werden, und die Fragen waren immer dieselben, d.h.: einfach leer abgeben und die Antworten abschreiben. Dann waren 3 Aufgabenblätter zu bearbeiten. zwischen dem ersten Arbeitsblatt und dem zweiten Arbeitsblatt gab es einen Test (60Pkt) zu den Themen des ersten Arbeitsblatts. In unserem Fall waren das argument parsing,shared memory und semaphoren. danach waren die Arbeitsblätter 2 und 3 zu erledigen zu denen es dann anschließend den zweiten Test gab (50Pkt Implementierungen und 30Pkt Theorie). Der erste Test fand trotz Covid in Präsenz in den Tilabs statt und bestand eigentlich aus dem implementieren von Programmteilen bezogen auf Arbeitsblatt 1. der zweite Test war wie der erste, mit den themen des 2. und 3. Arbeitsblatts und zusätzlich einen Theorieteil. Zu dem ersten AB gab es ein Abgabegespräch und gebündelt zu dem 2. und 3. auch eins. da musste man nur ein bisschen die verwendeten funktionen und sein programm erklären und dieses sollte auch funktionieren.


WS:2021/22: 1. Test: Test war in 3 Teile geteilt: 1. Argument parsing (getopt), 2. shared memory, semaphoren und ein file öffnen, 3. Operationen auf files, shared memory und semaphoren. Test prinzipiell machbar mit vertretbarem Lernaufwand. Jedoch sollte man extrem aufpassen denn ein kleiner Fehler kann schon zu 0 Punkten bei einer der Teilaufgaben führen, die Bewertung wird automatisch durchgeführt und stoppt beim ersten Fehler für die Teilaufgabe. Das heißt hast du einen Fehler in der ersten Zeile einer Teilaufgabe bekommst du für diese 0 Punkte auch falls danach alles richtig ist. Die Schwierigkeit ist also nicht das Programmieren selbst sondern die elendige Fehlersuche im Code, welche jedoch viel Zeit kostet. Einzige Lösung: Code aus den man files kopieren und falls nicht möglich auswendig lernen.

Erstmals wurde ein automatisches Bewertungssystem eingeführt, das die Abgaben überprüft und angibt, wie viele Punkte mit der Arbeit prinzipiell erreichbar wären. Beim Abgabegespräch können aber noch Punkte abgezogen werden.

Tipps[Bearbeiten | Quelltext bearbeiten]

Programmieren/Übungen[Bearbeiten | Quelltext bearbeiten]

Nachschlagen[Bearbeiten | Quelltext bearbeiten]

  • In den Folien steht eigentlich alles fast 1:1 drin und das kann echt Zeit sparen
  • Einige man pages haben Codebeispiele, die sind auch beim Test sehr praktisch
  • 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. (Welches Buch?)

Programmieren[Bearbeiten | Quelltext bearbeiten]

  • Es wird großer Wert auf "defensive Programmierung" (überprüfung aller Rückgabewerte, Fehler handling, usw.) gelegt. Sauber zu programmieren erspart auch viel debugging Zeit.
  • Die Programmierrichtlinien unbedingt beachten!
  • Memory Leaks und Segmentation Faults werden mit harten Punkteabzüge bestraft. Am besten vorher mit Valgrind überprüfen ob man keine hat: valgrind --leak-check=full --show-leak-kinds=all -s ./myProgram
  • VSCode ist ein ganz brauchbarer Editor. Auf Windows kann man VSCode + WSL verwenden wenn man zuerst lokal entwickeln will, bevor man es auf deren Server hochlädt und dort zusätzlich testet.
  • 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.
  • Wenn man noch nie mit einem *NIX-System gearbeitet hat, kann das am Anfang etwas überwältigend sein. Deshalb zahlt es sich aus, basic commands und einen editor vielleicht vor dieser Lehrveranstaltung gut zu beherrschen. (Ich tat es nicht, hat mich beim 1. Beispiel viele Nerven gekostet)
  • Den anfänglichen Zeitaufwand nicht unterschätzen! Es macht sehr viel Sinn, sich mit den anfänglichen Foliensätzen so vertraut zu machen, dass man die Basics im Schlaf beherrscht (pointer (!), structs, typedef, Makefiles, header files mit include guard, ...). So erspart man sich viel Zeit und Frustration später.
  • Die Folien für die Übungen genauestens lesen. Die Konzepte sind nicht schwer, der Syntax und die genaue Verwendung der Funktionen aber manchmal tückisch. Das LVA-Team weiß sehr genau, welche Fehler oft vorkommen. So kann man sich viele unnötige Stunden Debugging ersparen.
  • Tutoren können beim Programmieren sehr hilfreich sein. Nicht zögern, in die Lab-Stunden zu gehen (habe ich wenig gemacht, das eine Mal, das ich dort war, war jedoch sehr hilfreich)
  • UNBEDINGT den Code zumindest via SSH am TILab Server testen. Sowohl mir als auch einem Kollegen ist passiert, dass wir Segfaults hatten obwohl die Programme am eigenen Rechner ohne Probleme funktioniert haben. Da können einem die Tutoren nicht mehr helfen, sind automatisch 0 Punkte für die Abgabe.
  • C ist weder eine leichte noch moderne Sprache. Vielmehr ist es ein altes, weit verbreitetes Beast und sollte auch dementsprechend behandelt werden. Nach dem BSUE Kurs ist es empfehlenswert, diese Sprache weitgehend zu vermeiden für neuen Code, siehe auch "70% aller Sicherheitslücken sind memory safety issues", "undefined behaviour", offizielle Guidelines die von C abraten, usw.

Tests[Bearbeiten | Quelltext bearbeiten]

  • für die tests einfach auf Automation üben. --> semaphoren initialisieren, shm aufsetzen, forken, programme executieren und sockets einfach versuchen zu hause auf Schnelligkeit und des öfteren coden. wenn das schnell geht dann hat man beim test mehr zeit für die fehlersuche.
  • 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). Andere Meinung: Sehe ich überhaupt nicht so. Hatte volle Punktzahl beim ersten Test und musste trotzdem relativ hohen Aufwand in Bsp 2 und 3 investieren.
  • 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!)
  • 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.
  • Demo-Tests mehrmals und auf Zeit lösen, bis man sie locker in weniger als der vorgegeben Zeit runtertippen kann. Dann hat man im Lab überhaupt keinen Stress und kann sich zum Beispiel auf gemeine Testcases konzentrieren. Dieses Rezept hat bei mir zwei mal perfekt funktioniert.
  • Der Theorieteil beim zweiten Test ist nicht schwer, er dreht sich aber hauptsächlich um die ersten Foliensätze, also unbedingt vorher zumindest durchlesen, damit man keine unnötigen Punkte verschenkt (zum Beispiel Deklaration vs Definition, wie werden lokale/globale Variablen initialisiert, ..:).
  • Da bei Segmentation Faults und Compiler Warnings wie in der Übung keine Punkte bzw. deutlich weniger Punkte vergeben werden, ist es mehr als sinnvoll, Backups der Testdateien zu erstellen, wenn man schon Punkte erreicht hat. So kann man im schlimmsten Fall am Ende der Zeit einen früheren Punktestand wiederherstellen, falls man einen Segmentation Fault o.Ä. hat und diesen im Stress nicht wegbekommt. Das gibt auch, wie ich finde, ein gewisses Gefühl der Sicherheit, quasi schon X punkte in der Tasche zu haben. Zwei Kollegen haben viele Punkte liegen lassen, weil sie das nicht gemacht haben.
  • Gut aber (wirklich) nicht notwendig: Vor dem Test alle Funktionen mit Parametern auswendig lernen (1. Test: getopt(), socket(), bind(), listen(), accept(), Stream-I/O. 2.Test: Semaphoren, Pipes, fork(), exec*(), dup2(), Shared Memory). So kann man sich immens viel Zeit beim Test ersparen, beide Tests sollten dann innerhalb von 30 Minuten lösbar sein.

Sonstiges[Bearbeiten | Quelltext bearbeiten]

  • Tutoren können bei Problemen kompetent Rat geben.

Literatur[Bearbeiten | Quelltext bearbeiten]

  • Seit dem WS 2010 (vll auch schon länger) wird das Buch Brian W. Kernigham, Dennis M. Richie. C Programming Language. Prentice Hall. 2. Auflage ISBN 0131103628 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 | Quelltext bearbeiten]

A Brief Info: Welcome to Operating Systems Practical Course. Do you think you are lucky person? Because let me tell you, getting an easy exercise depends on your luck. If you are C newbie, then pray for it, because the very first example can last for you a day or a week or weeks depending on your luck. Since years it seems the teachers are ignoring the difficulty balance of exercises, so there is nothing to do about that. Let me illustrate that with two exercise types( there are more than 2) from very first Homework.

In one exercise a program has to be implemented which gets two input files,compares them line by line and gives out the difference per line. Pretty straightforward right?

In another exercise from same homework a program has to be implemented which gets infinite number of input files or gets input from command line, and compresses each file by counting every consecutive occurrence of a character and writing it next to the character. But you are not finished yet. At the end, you need to report how many characters you read, how many you wrote and the compression ratio of course.

Now imagine you have good luck and you got the first exercise for the homework. You finished in a day or maybe two. Now spending your valuable time on other time demanding courses such as Database systems, OOP, etc. because this exercise was enough for you to understand the content which the course tries to explain you.

Oh what? RNG betrayed you and gave you the second exercise? Well prepare to curse this course for the rest of your life, forget spending extra time to DBS and OOP, because now it is either this exercise or another course, giving that you will be able to solve this exercise without any problems.

Oh and did I mention that both of the exercises are 5 points? So in summary, you can spend 1 Day to get 5 points or weeks to get 0 point or well maybe half because for an exercise like second one, there is always complications on test cases.

As a recommendation, if you realize you invested more than a week into very first Homework, then stop, it's not worth the 5 points and it might cost you performance decrease in other important courses. Make sure you understand the concepts which they try to tell you. Because unlike the exercise, exam is easy if you know the concepts. Focus on other Homeworks which are 15(Considered as second part of first Homework but doesn't have anything to do with first one), 20, 20 points.

Last but very important recommendation: Try to ACE the first exam by getting all the points. It's 60 points and if you understood the concepts good, then it should be a very easy exam for you. If you ace the first exam, you will need 40 more points to pass the Course and you will not need to reach any minimum note for second exam. (First exam note + second exam note >= 60 to be able to pass the course).

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.

Erfahrungsbericht aus dem WS 18/19: Die Aufgaben waren nicht unbedingt schwer zu programmieren, aber zum Teil enorm aufwändig. Wobei die letzten zwei Beispiele (semaphoren, shared memory) relaitv schnell erledigt waren. Selbst mit C Erfahrung kann man hier sicher mit mindestens 10h pro Beispiel rechnen. Oft kommen dann noch Ungenauigkeiten in der Angabe dazu, die dann am Tag vor der Abgabe auf TUWEL berichtigt werden, daher dort auch unbedingt mal reinschauen, damit man dann bei Abgabegespräch nicht mit weniger Punkten rausgeht. Das führt halt zu unnötigem Stress am Tag der Abgabe, insbesondere wenn man sich sicher war, dass alles passt.

Bei den Tests die gleiche Situation: An sich nicht schwer, aber besonders die zweite Angabe hatte Stellen drin, die falsch interpretiert werden konnten. Also zumindest war das bei mir der Fall. Daher kommt es dann zu fehlerhaften Testfällen und man weiß nicht warum. Wenn man Glück hat, kann man die Tutoren beim Test fragen. Wenn man Pech hat, kann keine Auskunft gegeben werden. Allerdings würde ich sagen, dass wenn die Aufgaben eigenständig gelöst wurden, dass dann der Test keine riesen Herausforderung darstellen sollte, insbesondere da die manual Pages beim Test verwendet werden dürfen. Sinnloses Auswendiglernen der Methoden ist daher eher kontraproduktiv.

Insgesamt finde ich die LVA mit 4 ECTS dennoch knapp bemessen, besonders wenn die VO Einheiten besucht werden.


Erfahrungsbericht aus dem WS 2021:

Das Fach ist ein Paradebeispiel für die suboptimale Studierbarkeit an der TU Wien. Grundsätzlich sind die Aufgaben lösbar, aber erfordern für Personen ohne Linux/C Vorkenntisse einen absurden Mehraufwand. Das geht so weit, dass die Übungen de fakto unlösbar sind, ohne Hilfe zu bekommen. Auch ist die Wahl der Programmiersprache zwar verständlich, aber Albtraumhaft. Von Anfang an muss man alle, und wirklich alle, Fehlercodes abfragen und abfangen. Das Programm sollte aus mehr Fehlerbehandlung als eigentlichem Code bestehen. Die Alternative ist, dass man Bugs im Programm hat, bei denen man Stundenlang suchen darf. Wobei man zuerst rausfinden muss wie man überhaupt einen Debugger korrekt zum laufen bekommt. Dieses wird leider in der LVA nicht erklärt.

tl;dr: Personen mit Vorerfahrung schaffen es. Personen die erst an der TU Wien das Programmieren gelernt haben werden weniger gut dabei sein und das Abmeldeformular mehrmals in Betracht ziehen.

Ergänzung zu WS2021: Ich war auf einer HTL davor und hatte dementsprechend schon Vorkentnisse, die LVA ohne Vorkentnisse zu machen ist quasi unmöglich, am besten sich 1-2 Monate bevor das Fach überhaupt beginnt, mit Linux und bisschen C außeinanderzusetzen.


Erfahrungsbericht aus dem WS 2022/23:

Bereits in den Sommerferien habe ich mich hier im VoWi über diese LVA tiefgründig informiert und hatte aufgrund der Erfahrungsberichte meiner Vorgänger Bedenken, ob ich diese LVA denn schaffen werde. Auch abseits des VoWis hörte man gerne, dass diese LVA mitunter einer der schwierigsten im gesamten Bachelor sei. Meine Bedenken haben sich aber im Laufe des Semesters als gegenstandslos erwiesen:

Ja, die Hausübungen sind eher langwierig, da man sich mit zuvor völlig unbekannten Konzepten befassen muss, also sollten pro HÜ 2-3 Tage Arbeitsaufwand und einige Tage Puffer zur Abgabefrist eingeplant werden. Abgesehen von den HÜs ist der restliche Aufwand aber tatsächlich zu vernachlässigen, zumal beim Test nur vorhersehbare Beispiele abgeprüft werden. Dies ist auch irgendwie verständlich, denn in 70 Minuten Arbeitszeit kann kein allzu umfangreiches Programm implementiert werden! Nicht einmal die genauen Schnittstellen der Systemcalls muss man sich merken, denn in jeder Unteraufgabe des Tests werden Verweise auf die für das Beispiel nützlichen man-Pages bereitgestellt. In diesen man-Pages sind häufig Codestücke enthalten, welche man ohne Weiteres kopieren kann (Zeitersparnis!).

Folglich kann ich manchen Vorsprechern überhaupt nicht zustimmen! Wer grundlegende Programmiererfahrung hat, also im Idealfall EP1 abgeschlossen hat, sollte gar keine gröberen Schwierigkeiten während des Semesters erleben.

"1-2 Monate im Vorhinein" muss man sich also NICHT mit den Inhalten befassen, es reicht, wenn man zu Beginn der LVA konsequent mitmacht. Der Vortrag ist gut gehalten, um einen Überblick über das aktuelle Thema zu verschaffen. Sollten die Inhalte nicht gleich klar sein (was bei den HÜs gerne der Fall sein kann), so findet man auf diversesten Plattformen (StackOverflow, YouTube, Programmierwebsites, ...) zusätzliche Ressourcen, welche die Vorlesung kompetent ergänzen. Sind auch diese Ressourcen nicht hilfreich, so können das LVA-Team und die Tutoren zielführend helfen, wobei die freundliche Kommunikation mit den Teilnehmern gelobt werden muss!

Kommentare wie "Paradebeispiel für die suboptimale Studierbarkeit an der TU Wien" oder dass man "Glück haben muss, eine einfache Hausübung zugeteilt zu bekommen", erachte ich im besten Fall für blind­lingse Res­sen­ti­ments gegenüber dieser LVA. Konstruktive Kritik für künftige Teilnehmer sollte anders aussehen!

Oft lassen wir Menschen uns kurzfristig von unseren Gefühlen prägen. Langfristig empfehle ich als Maßnahme jedoch, vor jedem Beitrag im VoWi - und in jedem anderen Kontext der verbalen Kommunikation - kurz innezuhalten und über das Gesagte detailliert nachzudenken: Gewisse Axiome können dem Empfänger ein fehlgeleitetes Bild vermitteln. Hier kann ich die Stoa, also die Lehre des Zenons von Kition, nicht genug empfehlen! Diese kann jemandes Leben merklich verbessern!

Anmerkung eines anderen Studenten: Dem stimme ich voll und ganz zu. Die Schwierigkeit wird maßlos überschätzt. Also für alle C-Anfänger der Tipp: Nur kein Stress! Es ist machbar :D

Zusätzlicher Erfahrungsbericht aus dem WS 22/23:

Zuerst möchte ich anmerken, dass ich genauso wie viele andere hier die ein oder andere Vorwarnung für Betriebssysteme erhalten. Mir wurde geraten mich zumindest ein wenig mit C auseinanderzusetzen, jedoch muss ich hierbei ehrlich zugeben, dass ich es einfach ignoriert habe. Meine Ferien wollte ich immerhin mit Spaßigerem verbringen. Dementsprechend bin ich ohne Vorwissen und als kompletter C-Anfänger in die LVA gegangen. Ich möchte hierbei vorneweg nehmen, dass der Anfang sehr viel schwieriger ist, als der Rest.

Der Anfang war sehr überwältigend, wenn nicht sogar zu viel für den kurzen Moment. Viel, womit ich noch nie zuvor konfrontiert wurde. Pointer, manuelle Speicherzuweisung, die extreme Gewichtung von defensiver Programmierung, verstehen wie Speicher überhaupt funktioniert. Besonders, wenn man von einer High-Level Porgrammiersprache wie Java kommt (was in Semestern 1&2 vermittelt wird) muss sich alles sehr fremd vorkommen. Gleichzeitig bin ich hierbei auch der Überzeugung, dass die LVA diesen großen Sprung nicht erleichtert. Es gibt Folien zum Selbststudium und die ein oder andere Vorlesung in der Übung, in welcher Basics wie Pointer etwas beleuchtet werden, aber bis sich ein brauchbares Verständnis dafür entwickelt braucht es sehr viel mehr Zeit, als erwartet wird.

Ein weiteres Problem besteht am Anfang mit der Tatsache, dass mit einem *NIX Gerät gearbeitet wird. (Sicht: Windows User) Sollte man nicht in das INFLAB gehen (dazu kommen wir noch) bleibt einem nichts anderes übrig, als sich mit ssh mit einem der Computer zu verbinden. Auch wie dies tatsächlich funktioniert war für einen Laien wie mich keine besonders lustige Auseinandersetzung. Zusätzlich hatte ich damals ebenso das Problem, dass ich nicht wusste, wie ich am Besten arbeiten sollte. Lokal den Code zu schreiben, ihn dann per scp auf den Inflab-rechner zu schiken, um ihn remote auf dem Testrechner zu testen, ist kein besonders effizienter Prozess, so viel darf ich verraten. Erst später habe ich dank meiner Kommilitonen herausgefunden, dass ich mich auch auf VS CODE remotely verbinden konnte, was diesen Zwischenprozess um ein Vielfaches vereinfacht hatte.

Weg von meiner eigenen Inkompetenz, folgen nun zwei besonders wichtige Punkte, die für viel Diskussion sorgen: Aufgabenblätter + Tests. Zuerst möchte ich mich den Arbeitsblättern widmen, da ein großer Trend bei ihnen ist, sich an alten Lösungen zu orientieren und sie an die Aufgabe anzupassen. Zu dieser Herangehensweise möchte ich schnell hinzufügen, dass an ihr nichts auszusetzen ist. Viele Aufgaben fand ich persönlich fast unmöglich zu begreifen, oft fehlte mir wirklich der Durchblick, sodass ich nie wusste, wie ich überhaupt anfangen sollte. Doch möchte ich nicht alle Blätter zusammenfassen.

1a: Dieser Teil der Aufgabe ist dazu gedacht, damit man sich langsam aber sicher in die Materie einarbeiten kann. Zumindest sollte das die Intention sein. In meiner Erfahrung kann sich dieses erste, eigentlich simple Programm schon zu einem syntaktischen Horror entwickeln. Speicher-Allokation, Kommandozeilen-Parsing und selbst der richtige Umgang mit File-Streams ist etwas, was wirklich brutal sein kann, wenn man noch nie damit zu tun hatte. Diese 5 Punkte sollte man unter keinen Umständen unterschätzen. Ich persönlich habe zu jenem Zeitpunkt Angst gehabt, ob ich die LVA überhaupt schaffe, wenn ich schon Probleme damit habe, diese "simple" Aufgabe zu lösen.

1b & 2 & 3: Die folgenden Aufgaben (1b gehört noch zur ersten Aufgabe) sind alle drei ziemlich ähnlich darin, dass sie sich mit einem Thema auseinandersetzen, welches im Vorlesungsteil der Übung besprochen wurde. Zwar sind diese Aufgaben vom Schwierigkeitsgrad her ein weiterer großer Sprung zur ersten Aufgabe. Allerdings fand ich jede fortlaufende Aufgabe einfacher als die davor. Wenn man einmal den Prozess und den Ablauf des Lösungsprogrammes verstanden hat (Hier helfen die alten Lösungen), ist es möglich mit den Vorlesungsfolien einen funktionierenden Code auf Papier zu bringen! Denn so wahnsinnig wie es ist: Die eigenen Fähigkeiten steigen bei dieser LVA exponentiell an. Wenn man einmal das Verständnis zu jedem Thema gefunden hat, dann sind all jene Übungsblätter komplett machbar (wohl aber mit einem großen Zeitaufwand). --> Eine Hilfe, die nicht so viele in diesem Kontext wahrnehmen nennt sich: Lab-Hours. Es ist wahrlich unglaublich, wie viel Zeit und Verständnis bei einem Gespräch mit dem Tutor gewonnen wird, im Vergleich dazu, wie lange man zu Hause vor dem Code gestarrt hätte. Man ist nicht alleine! Auch in der Fachschaft gibt es fast immer jemanden der einem bei dem Problem helfen kann bzw. einem helfen kann zu verstehen, was zu tun wäre.

Anmerkung: Dieser Bereich ist zeitintensiv, versteht mich nicht falsch. Die Menge an Code, Fehlerbehebung und Verständnis ist enorm, aber es ist nicht unmöglich, besonders wenn man Hilfe bekommen kann. Ich verstehe den Gedanken, dass man nicht ewig lange mit "Betriebssysteme" verbringen möchte, doch spart man sich erstens Zeit und Nerven in den Lab-Hours oder durch Kooperation mit anderen Studierenden (Verweis fsinf). Die LVA ist schwer, ja, aber nicht so schwer, wie es einige hier behaupten. --> schreibt bitte keinen Code von Altlösungen ab. Ihr werdet Probleme mit Plagiaten bekommen. (Altlösungen sollten Inspiration und Richtung zeigen und nicht die Basis des Codes bilden)

Prüfungen: Zu den zwei Tests will ich nicht allzu viel Zeit verlieren, da genug schon über sie erzählt worden ist. Ein Verständnis für die einzelnen Themen zu besitzen ist definitiv von Vorteil und wissen, welche manpages in was für einer Art nützlich sind ist extrem hilfreich. (Ich persönlich habe genug kopiert aus den Manpages). Es ist definitiv machbar mit der richtigen Vorbereitung. (Unterschätzt es einfach nicht)


TL;DR Es gibt definitiv Probleme mit der LVA, jedoch sind jene nicht so extrem, wie es teilweise behauptet wird. Mit genügend Geduld und mit Hilfenahme der gegebenen Hilfestellungen ist die LVA definitiv machbar, auch wenn es sicherlich einer der zeitintensiveren und schwierigeren LVAs ist. Lasst euch nicht davon unterkriegen! Ihr wollt nicht die Aufgaben halbherzig durchführen, nur um dann durch Plagiatspunktabzüge negativ zu werden. (Das habe ich tatsächlich im Studo-Chat beobachten können)


Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]

Zeugnisausstellung tatsächlich:

  • WS22 - ca. 2 Wochen nach dem letzten Test


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 | Quelltext bearbeiten]

Highlights / Lob[Bearbeiten | Quelltext bearbeiten]

noch offen

Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]

Angaben enthalten anscheinend relativ oft Ungenauigkeiten/Fehler. Das könnte also noch verbessert werden.

Diese Fehler vlt. Nicht mehr am Tag der Abgabe auf TUWEL berichtigen. Oder zumindest die Abgabe um 1-2 Tage verlängern. Wer den TUWEL Beitrag nicht rechtzeitig gesehen hat, und die Angabe falsch interpretiert hat, hat Pech gehabt.

Abgerufen von „https://vowi.fsinf.at/index.php?title=TU_Wien:Betriebssysteme_UE_(Puschner)&oldid=179212“