Stromverbraucher im Haushalt

Ein paar grobe Messungen der Verbraucher im Haushalt (gemessen mit KD 302 von Reichelt):

Verbraucher Zustand Leistungsaufnahme [W]
(ggf. Schwankung)
Wasserkocher an 2140
Server: HP DL360 an 158,5 (+/- 21,5)
standby 21,5
Mixer: RG28s Stufe 1 bis 3 82,5 (+/- 7,5)
Kühlschrank kühlend 75
CRT-Monitor (19”, älteres Modell) an (weißer Text auf Schwarz) 73
standby 2,3
aus 0,1
Samsung P30 Netzteil laden 53
mit P30 an ohne Akku 24 (+/- 9)
mit P30 aus ohne Akku 1,6
ohne P30 0,7
VIA EPIA M1000 + 3,5” Platte an 37
MacBook 13″ an 28 (+/- 10)
standby 2,7
TFT: Samsung SyncMaster 901B an 23 (+/- 7)
standby 0,7
aus 0,6
Router WRT54G + Voip-Adapter Zyxel an 22
Drucker: HP LaserJet 4000N bereit 17
standby 17
RFT Amplifier SV 3900 an 10
USB-SATA/IDE-Adapter Netzteil mit Platte 6,6
ohne Platte 2
RFT Equalizer SM 3000 an 5,8
La Fonera an (ohne WiFi) 4,2
Netzteil alleine 1
Siemens M50 Ladegerät laden 3,3
aus 0,2
RFT Tuner ST 3900 an 2,3
aus 0,2
Nokia N900 Ladegerät laden 2 (+/- 0,1)

(nicht aufgeführte „aus“-Zustände: < 0,1 W)

Die Werte für die lade-Zustände vom Laptop und den Handies unterliegen vermutlich größeren Schwankungen während des gesamten Ladevorgangs.

Die rote Lampe einer Schaltsteckerleiste scheint < 0,1 W zu ziehen. :)

Der Energiesparmodus des LaserJets schien nur dem Marketing zu dienen.

Die Leistungsaufnahme von Netzteilen, wenn an ihnen keine Verbraucher angeschlossen sind, lässt sich tatsächlich grob an ihrer Wärmeentwicklung einschätzen: Beim Netzteil vom P30 (0,7 W ohne angeschlossenem P30) ist deutlich Wärme zu spüren, während das N900-Netzteil vollkommen kalt ist und < 0,1 W nimmt.

Genaue Aufschlüsselung des Verbrauchs des CRT-Monitors (Modell: Formac ProNitron 19/600 CPD-4403) in neuem Post.

Das vierte Semester Informatik an der TUB

Wie angekündigt der Rückblick auf das 4. Semester:

MPGI5 – Datenbanksysteme: Es fängt damit an, aus Anforderungsbeschreibungen (E)ER-Diagramme zu erstellen. An dieser Stelle schon meine erste Kritik: Der Dozent und der für den Übungsbetrieb zuständige Dr. verwenden unnötigerweise unterschiedliche Notationen… Weitere Themen sind: Relationaler Entwurf (überlegen, wie die Tabellen auszusehen haben), Funktionale Abhängigkeiten, Normalformen (1.-3. und BCNF), Relationale Algebra, SQL, Abfrageoptimierung und Transaktionen/Serialisierbarkeit. Wie üblich wieder alles auf einer sehr theoretischen Schiene. Wenigstens bei SQL hätte es sich doch schön angeboten, wenn der Dozent einfach mal am Projektor auf seinem Rechner live ein paar Abfragen vorgeführt hätte – oder besser noch – den Teilnehmern einen Zugang zu einem SQL-Server geben, wo sie die für die Hausaufgaben nötigen Statements ausprobieren können. Aber nein, das gehört sich für eine Universität ja nicht.

Datenbankpraktikum (Wahlpflicht-Praktikum zu MPGI3): Das Datenbankpraktikum füllt die fehlende Praxisnähe von MPGI5, aber eben nur für die, die auch daran teilnehmen, denn es ist im Gegensatz zu MPGI5 keine Pflichtveranstaltung. Es werden Themen behandelt, mit denen ich so als Durchschnitts-Webentwickler teils noch nicht viel zu tun hatte, wie Views, UDRs (Stored Procedures), Trigger oder die Anbindung per JDBC. Alles wird auch direkt ausprobiert und am Ende in einem kleinen Projekt umgesetzt. Sehr empfehlenswerter Kurs. Auch wenn es als MPGI3-Praktikum angeboten wird hat es nicht sehr viel mit MPGI3 zu tun. Mit der Projektgruppe (6 Leute) muss man etwas Glück haben – andere hatten offenbar nicht so zuverlässige Gruppenpartner bekommen und dadurch etwas Stress.

TechGI4 – Verteilte Systeme: Die Grundlagen Verteilter Systeme werden angerissen – Probleme und deren Lösungsansätze (DHTs, Peer-To-Peer, Zeitsynchronisation, Replikation, TCP-/IP-Grundlagen). Der Dozent erzählt hauptsächlich Beispiele aus dem menschlichen Miteinander (Kommunikation), die dann ein bestimmtes Problem oder eine Technik in Rechnernetzwerken erklären sollen. In den Übungen werden (wie bei TechGI3) im Prinzip nur die Hausaufgaben vorgeführt/besprochen, wodurch Anwesenheitszwang besteht. Es gibt wieder eine Unterteilung in Theorie und Praxisaufgaben. Im Praxisteil werden Client/Server Beispiele programmiert (C und Java), die Theorie-Hausaufgaben entsprechen meistens der Recherche in den wirren Folien oder im Netz.

TheGI4: Das eine große Thema sind Petrinetze – das ist recht verständlich und lässt sich sehr schön mit Graphen veranschaulichen. Mein Eindruck ist, dass Petrinetze keine neuen Grundlagenerkenntnisse liefern, sondern eher eine zusätzliche Modellierungsmöglichkeit sind, mit der sich Prozesse ganz gut darstellen lassen (wie das Erkennen von Deadlocks – z. B. bei den Dining Philosophers). Das ganze Thema ist wie ein etwas komplexeres Brettspiel. :)
Der andere Scherpunkt sind Algebraische Spezifikationen. Die Grundlagen, die in TheGI1 rankamen (Signaturen und Algebren) werden weiter ausgebaut: Eine Spezifikation ist im Prinzip eine Signatur mit einer Menge von Gleichungen, die beschreiben, welche Eigenschaften die Operationen erfüllen sollen. Dann kann man sagen, ob eine Algebra (zu der passenden Signatur) ein Modell für diese Spezifikation ist (das heißt alle in der Spezifikation enthaltenen Gleichungen erfüllt) oder „initial korrekt“ ist (das ist so eine Art minimalst-mögliche Algebra, die Modell für die Spezifikation ist). Ich glaube an sich steckt da nicht so besonders viel dahinter, aber dadurch, dass für die Beweisführungen noch so etwas wie massig Meta-Algebren eingeführt werden (Grundtermalgebra), wird es irgendwie extrem kompliziert und für mich kaum noch nachvollziehbar. Der größte Anteil der Klausur stellte glücklicherweise Petrinetz-Aufgaben dar.

Stochastik für Informatiker: Es geht um Grundlagen der Wahrscheinlichkeitstheorie. Einige Handwerkszeuge werden gelehrt (kombinatorische Überlegungen, Bedingte Wahrscheinlichkeit, Zufallsvariablen und Verteilungen) und Markov-Ketten sind noch ganz witzig (ich mag Graphen). Aber was recht kompliziert wird sind Abschätzungs-Berechnungen mit Chebyshev-Ungleichung oder dem Starken/Schwachen Gesetz der Großen Zahlen – was die Gesetze anschaulich sagen ist eigentlich ziemlich intuitiv, aber das dann in konkreten Aufgaben anzuwenden wieder ne andere Sache.

Damit ist jetzt das sogenannte Grundstudium für mich vorbei und für das 5. und 6. Semester habe ich ziemliche Wahlfreiheit, was die Module angeht. Trotzdem muss ich mich einerseits auf eine Richtung für das Fachstudium festlegen (Softwaretechnik oder Kommunikationstechnik – in den jeweiligen Richtungen stehen unterschiedliche Module zur Auswahl) und ein Anwendungsfach auswählen.
So ein paar Themen, die ich interessant fände, wären NoSQL-Datenbanken (Map-Reduce etc.), Sicherheit, Betriebssysteme und Netzwerke/“NGN“.

Informatikstudium an der TUB: Literatur-Review

Während des Studiums stößt man auf etliche Fachliteratur unterschiedlichster Qualität. Manche Bücher sind den Weg dafür in die Bibliothek nicht Wert, wohingegen ich für andere eine deutliche Kaufempfehlung (wenn nicht sogar -pflicht) aussprechen würde.

Zur letzeren Gruppe gehört eindeutig das „Taschenbuch der Mathematik“ – besser bekannt als „Der Bronstein“ (Bronstein/Semendjajew/Musiol/Mühlig). Es ist im Prinzip eine fette Formel- und Tabellensammlung (> 1000 Seiten), die vermutlich alle mathematischen Grundlagen eines Ingenieurstudiums und darüber hinaus abdeckt. Viele Formeln/Zusammenhänge werden exzellent durch kleine Beispiele und Grafiken veranschaulicht. Es ist kein Lehrbuch, was man von vorne bis hinten durchlesen würde, sondern ein Nachschlagewerk. Ich selbst habe es leider erst zum Ende des dritten Semesters entdeckt – es hätte mir in den ersten drei Semestern für Lineare Algebra und Analysis 1 und 2 sehr geholfen. Insbesondere ergänzend zu Vorlesungsskripten oder anderen Mathebüchern, wo erst lange rumgeschwafelt und nie auf den Punkt gekommen wird (bzw. diese Punkte dann sehr versteckt sind), füllt der Bronstein eine Lücke.

Ein weiteres nettes Buch ist „Grundlagen der Technischen Informatik“ (Dirk W. Hoffmann). Es beginnt mit Boolescher Algebra und erklärt darauf aufbauend ziemlich leicht verständlich die Funktionsweise von Speicher, CPUs und der Von-Neumann-Architektur (auf der ja fast alle heutigen Systeme basieren). Auch auf neueste Entwicklungen – z. B. die Unterschiede der momentan auf dem Markt befindlichen Prozessoren – wird eingegangen (Ausgabe 2007 – es gibt mittlerweile noch eine aktuellere).
Als ich das Buch (noch vor Beginn des Studiums) gelesen hatte brachte es mir einen ziemlichen Erkenntnisgewinn, fast schon eine Art Erleuchtungsgefühl :). Alle Puzzleteile, die man von hier und da schon kannte setzen sich zu einem Gesamtbild zusammen – also insbesondere die Verbindung zwischen Software (Maschinensprache/Assembler) und Elektronik. Nach dem Lesen hatte ich das Gefühl, dass ich mit ausreichend Zeit und vielen Relais bzw. Transistoren einen Prozssor „from scratch“ aufbauen könnte.
Ich glaub die Uni-Veranstaltungen (TechGI1 und TechGI2) hätten das nicht so gut hinbekommen. In ihnen werden zwar alle Grundlagen einzeln betrachtet, aber es wird fast immer versäumt einen Gesamtzusammenhang herzustellen und mal auf die Praxis zu schauen (siehe auch meine Kritik an TechGI3 im dritten Semester).

Die dritte Empfehlung geht an „Computernetzwerke – Der Top-Down-Ansatz“ (Kurose/Ross). Der Ansatz von denen ist, sehr praxisnah das OSI-Schichtenmodell von oben nach unten durchzugehen – also von dort ausgehend, was man schon am besten kennt (die Anwendungsebene). Es ist wohl DAS Buch um zu verstehen, wie „das Internet“ funktioniert. Leider deckt es viele Themen von TechGI4 (Verteilte Systeme) nicht ab – Zeitsynchronisation, Webservices und Replikation kommen z. B. nicht vor (dafür sind dann ergänzend Tanenbaum/Steen bzw. Coulouris/Dollimore/Kindberg sinnvoll – siehe unten).

Was man noch in Erwägung ziehen sollte käuflich zu erwerben ist „Mathematisch-Strukturelle Grundlagen der Informatik“ (Ehrig/Mahr/Cornelius/Große-Rhode/Zeitz). Für TheGI1, TheGI3 und TheGI4 stellt dieses Buch im Prinzip das Skript dar. Inhaltlich finde ich es (wie TheGI insgesamt) jedoch eher uninteressant. Die TheGI2-Inhalte (Automaten und Formale Sprachen) werden in diesem Buch nicht behandelt.

Es folgen weitere Bücher, die teils in den Veranstaltungen empfohlen werden oder zu ihnen passen. Ich würde empfehlen sie zunächst in der Bibliothek anzugucken/zu leihen und dann zu entscheiden, ob es sinnvoll ist eins zu kaufen.

MPGI1:

  • Funktionale Programmierung: in OPAL, ML, HASKELL und GOFER (Pepper) – die OPAL-Bibel ist (nur) fürs erste Semester ganz sinnvoll

TechGI1:

  • VHDL-Synthese (Reichardt/Schwarz) – Unnötig – höchstens vielleicht für TIler interessant; Was man an VHDL-Kenntnissen für TechGI1 braucht gibts ausreichend im Netz bzw. im Skript.

MPGI2, MPGI4:

  • Java ist auch eine Insel (Ullenboom) – existiert auch als kostenloses Online-Buch; ist für Java-Neulinge vermutlich ganz gut und taugt auch um ab und zu etwas nachzuschlagen

TheGI2:

Hier kann ich nicht sagen, welches der folgenden ich am besten finde. Für die einfach zu verstehenden Themen in TheGI2 (Formale Sprachen, Automaten, Turing Maschinen) reicht das Skript/Formelsammlung und bei den komplizierten (Berechenbarkeit/Entscheidbarkeit, Komplexität) haben mir diese Bücher auch nicht sonderlich weitergeholfen.

  • Theoretische Informatik – kurz gefasst (Schöning)
  • Grundkurs Theoretische Informatik (Hollas)
  • Theoretische Grundlagen der Informatik (Socher)

MPGI3:

  • Object-oriented Analysis and Design with Applications (Booch/…) – scheint wohl ein Klassiker zu sein; einige UML-Geschichten sind hier anhand von Beispielen ganz gut erklärt; Notation teils etwas abweichend von der in der Veranstaltung

TechGI3:

  • Operating Systems: Design and Implementation (Tanenbaum) – auch MINIX-Buch genannt; Interessant für Leute, die mal sehen wollen, wie die Konzepte aus der Vorlesung in einem realen Betriebssystem implementiert sind. Es ist geschrieben um parallel zum Buch den MINIX-Quelltext durchzulesen (der witzigerweise zu großen Teilen im Buch abgedruckt ist).

MPGI5:

  • Database systems (Garcia-Molina/Ullman/Widom) – Viele Beispiele aus der Vorlesung sind genau diesem Buch entnommen. Es taugt jedoch nicht als Nachschlagewerk, da die wichtigen Definitionen in der LaTeX-Fließtext-Bleiwüste untergehen. Insgesamt scheint es mir auch viel Zeug zu enthalten, was man eigentlich in anderen Büchern suchen würde (z. B. wie in bestimmten Programmiersprachen eine Verbindung zur Datenbank hergestellt wird). Ich hab es gekauft, aber fast nicht verwendet.

TechGI4:

  • Verteilte Systeme: Prinzipien und Paradigmen (Tanenbaum/Steen) – Die Vorlesung ist sehr an diesem Buch orientiert; insgesamt eher auf einer theoretisch-abstrakten Ebene (im Gegensatz zu dem am Anfang genannten Top-Down-Approach-Buch).
  • Verteilte Systeme: Konzepte und Design (Coulouris/Dollimore/Kindberg) – Deckt ungefähr die gleichen Themen ab.

P.S.: Demnächst gibt es wieder eine Kurzzusammenfassung des 4. Semesters.

Kennzeichnung von Polizisten

Anlässlich der letzten Ausschreitung eines Polizisten am Ersten Mai beim Spreewaldplatz stellte mir sich wieder einmal die Frage, wie weit es denn nun um die von Körting für dieses Jahr versprochene Kennzeichnung von Polizisten steht.
Nach dem Übergriff bei der Freiheit statt Angst Demo im September 2009 kam das Thema auf und Körting kündigte an, dass ab 2010 eine Kennzeichnung stattfinden würde. Gemeint war offensichtlich, dass ab 2010 langsam angefangen wird alle mal ganz lieb zu fragen und die letzten Berichte dazu vom Januar sprechen nur noch von „bis zur Sommerpause“. Weil die GDP die Pläne natürlich abgelehnt hat, sollte sich dann die Einigungsstelle für Personalvertretungssachen damit beschäftigen – es wär mal interessant, wie diesbezüglich der aktuelle Stand ist.

Das dritte Semester Informatik an der TUB

Wieder kurz was zu allen Kursen des dritten Semesters.

MPGI3 – Softwaretechnik: Anforderungsbeschreibungen interpretieren und verschiedenste (UML-)Diagramm-Arten malen bzw. formale Definition in Object-Z aufschreiben. Exakte Übertragung der Klassen/Objektstrukturen aus den Modellen mittels Java. Etwas anstrengend an dem Kurs ist, dass bei der Modellierung nie eindeutig ist, wie etwas gelöst werden muss, weil es eben immer tausende korrekte Wege gibt. Man kann mit den Leuten in der Hausaufgabengruppe stundenlang darüber diskutieren, wie irgendetwas modelliert werden soll. Die Object-Z Aufgaben sind dann jedoch wieder klarer. Eine Arbeitsteilung in den Hausaufgaben ist fast unmöglich, da die Modelle in sich konsistent sein müssen – also ein Diagramm zu allen anderen passen muss. Die Arten der Aufgabenstellungen in den Klausuren (die Klausur war zweigeteilt, wobei beide Teile am gleichen Tag mit einigen Stunden Abstand stattfanden) waren glücklicherweise ziemlich an den Hausaufgaben orientiert.

MPGI4 – Praxis der Programmentwicklung: Im Prinzip werden alle größeren Themen von Java und dessen API durchgegangen: GUIs, Eingabe/Ausgabe, Exception Handling, Netzwerkverbindungen/Sockets, Applets, Threads, Remote Method Invocation, Servlets. Ich würd sagen für Programmierer noch einfacher als MPGI2, da es noch praxisnäher ist.

TechGI3 – Systemprogrammierung: Hausaufgaben werden in C programmiert. Für C gibt es keine Einführung, man sollte sich also unbedingt vorher schon damit beschäftigt haben – insbesondere mit den Aspekten, die C von Java unterscheidet wie Pointer, mit denen viele Leute anscheinend immer wieder Probleme haben. Die wesentlichen Bestandteile eines Multitaskingbetriebssystems werden theoretisch besprochen und teilweise nachgebaut: Scheduler, „Betriebsmittel“verwaltung (also z. B. Speicher), Prozesskommunikation. Nebenläufige Programmierung (teilweise mittels pthreads). Es gab auch einen (leider nur sehr kurzen) Einschub zu Assemblerprogrammierung auf dem ARM. In den Tutorien gab es eine Quasi-Anwesenheitspflicht, da man dort die Theorie- und Praxishausaufgaben vorstellen musste – sehr verschult. Bei den Themen fällt auf, dass von den Prinzipien her sehr ähnliche Themen mehrfach unter unterschiedlichen Namen auftauchen, was dann etwas langweilt (first in first out bzw. first come first served wurde gefühlte fünf Mal erklärt). Ich hätte mir gewünscht, dass bei manchen Themen nicht so sehr ins Detail gegangen wird (z. B. nicht alle 10 Schedulingverfahren genau durchgehen) sondern stattdessen mal an echten Beispielen (wie MINIX oder Linux) gezeigt wird, wie manche Sachen umgesetzt werden. Aber insgesamt ist TechGI3 schon recht interessant.

TheGI3 – Logiken und Kalküle: Aussagenlogik und Prädikatenlogik wird nochmal genau auseinander genommen und trainiert. Die Beweisführungen haben teils etwas meditatives, sofern man nicht versucht sie zu verstehen. Dazu mal ein Zitat von S. 236 des Mahr-Buchs zum Koinzidenzlemma: „Ist B eins Stern von Phi gleich T, so ist B eins Stern von Psi gleich F oder B eins Stern von Chi gleich T. Mit (13.3) folgt B zwei Stern von Psi gleich F oder B zwei Stern von Chi gleich T. Folglich ist dann B zwei Stern von Phi gleich T. Ist B eins Stern von Phi gleich F, so ist B eins Stern von Psi gleich T und B eins Stern von Chi gleich F. Mit (13.3) folgt B zwei Stern von Psi gleich T und B zwei Stern von Chi gleich F. Folglich ist dann B zwei Stern von Phi gleich F. Also ist in beiden Fällen B eins Stern von Phi gleich B zwei Stern von Phi“. Dies ist nur ein kleiner Teil der Begründung, dabei sagt das Koinzidenzlemma grob gesagt nur aus, dass wenn eine Variable, die in einer Formel nicht enthalten ist, anders belegt wird, sich der „Wert“ der Formel nicht verändert.

ANA2: Differential- und Integralrechnung im Mehrdimensionalen. Vergleichbar nervig wie ANA1.

Das zweite Semester Informatik an der TUB

Nun, fast am Ende des dritten Semesters Informatik eine Kurzzusammenfassung der Kurse aus dem zweiten Semester.

MPGI2: Imperative Programmierung mit Java (Java-Einführung, Algorithmen, Datenstrukturen); im Gegensatz zu MPGI1 recht praxisnah – sollte Leuten, die hobbymäßig programmieren nicht schwer fallen. Einige Themen (Sortieren, Bäume), die bereits in MPGI1 vorkamen, werden nun erneut mit imperativen Implementierungen wiederholt.

TechGI2: Rechnen mit Dualzahlen; Einführung in die Assemblerprogrammierung mittels „VIP“ („Virtueller Informatik Prozessor“); Vermutlich wurde der Komplexität wegen leider kein realer Prozessor (wie der Z80 ;) genommen… Dadurch blieb das ganze eine ziemliche Trockenübung. In TechGI3 kommt dann jedoch noch ein Einschub mit realer ARM-Hardware.

TheGI2: nochmal Formale Sprachen; Automaten und Turing Maschinen; Berechenbarkeit; Komplexität; Die Automaten oder Turingmaschinen zusammenzubauen sind teilweise nette Knobelaufgaben. Das Thema Berechenbarkeit ist jedoch ziemlich verzwickt.

ANA1: Im Wesentlichen sowas wie Kurvendiskussion in der Schule (Differenzieren, Integrieren), nur deutlich anspruchsvoller – auch gegenüber LinA. Die Klausur hatten ziemlich genau zwei Drittel der Teilnehmer nicht bestanden. Zum Üben sollte man möglichst viele Altklausuren (zu finden z.B. bei der Freitagsrunde) durchrechnen, sich selbst streng bewerten und gucken, ob die Punktzahl ausreicht und aus den Fehlern lernen. Ich hab die ANA1-Klausur erst im zweiten Versuch (also nach den Semesterferien) bestanden, nachdem ich dieses Übungsverfahren eingesetzt hatte.

Das erste Semester Informatik an der TUB

Dieser Nachtrag noch zum ersten Semester:

MPGI1 – Funktionale Programmierung: Wer sich mit Funktionaler Programmierung noch nicht auseinandergesetzt hat: Sehr vereinfacht kann man vielleicht sagen, dass es wie herkömmliche Imperative Programmierung ist, nur dass pro Funktion immer nur eine Anweisung ausgeführt wird. Es existiert also eigentlich kein richtiger Programmablauf, sondern die Ausführungsreihenfolge der Operationen ist allein durch die Verschachtelung der Funktionsaufrufe festgelegt. Es gibt auch keine Schleifenkonstrukte – stattdessen muss sowas über rekursive Aufrufe umgesetzt werden. Diese funktionale Denkweise etwas zu trainieren ist schon ganz nett, es führt vielleicht dazu manches auch in Imperativen Sprachen sauberer zu programmieren. An der TU Berlin wird als funktionale Sprache „OPAL“ benutzt, die von Prof. Pepper entwickelt wurde. OPAL und der zugehörige Compiler haben einige Tücken – an dieser Stelle sei auf die FAQ der Freitagsrunde zum Thema OPAL verwiesen.

TechGI1 – Digitale Systeme: Boolesche Algebra, Umformungen (z. B. mittels KV-Diagrammen), Normalformen, bestimmte Digitalschaltungen (Zaehler, Addierer, ROMs/PLAs), VHDL-Grundlagen. Auf die elektrotechnischen Grundlagen wird nicht weiter eingegangen. Der Dozent hatte fast nur seine fehlerhaften Folien durchgeklickt, dazu fehlerhafte Anmerkungen gemacht oder Aufgaben an der Tafel falsch vorgerechnet. Er ist soweit ich weiß mittlerweile im Ruhestand. Sonst gibts eigentlich nicht viel zu sagen – gehört neben MPGI1 zu den entspanntesten/einfachen Modulen im ersten Semester.

TheGI1 – Grundlagen und algebraische Strukturen: Es beginnt mit Mengenlehre, Relationen und Abbildungen dann kommen Signaturen, Algebren und Homomorphismen und schließlich der Einstieg in Formale Sprachen/Chomsky-Hierarchie. Für die meisten das schwierigste Fach im ersten Semester und vermutlich mit-Auslöser für Studiengang-Wechsel/Abbrech-Entscheidungen. Im Unterschied zu Theoretische Informatik-Veranstaltungen an manchen anderen Unis kommen Automaten und Turing Maschinen hier noch nicht, sondern erst in TheGI2 ran.

LinA – Lineare Algebra (für Ingenieure): Vektorrechnung, Matrizen, Abbildungen, Lineare Gleichungssysteme. Bemerkenswert ist vielleicht „die Mumie“ – eine Webapplikation in der ein Teil der Hausaufgaben gemacht werden muss. Es ist die einfachste der Mathe-Pflichtveranstaltungen.

Informatisches Propädeutikum: Dieses Modul ist nach wie vor eine große Baustelle. Es soll wissenschaftliches Arbeiten vermitteln. In der Vorlesung wurden hauptsächlich irgendwelche sehr philosophischen Fragestellungen zu Informatik/Informationen/Sprache erörtert. Tutorien gibt es nicht. Als Hausaufgaben gibt es Recherecheaufgaben, für die man sich zu zwei Themen kurz einlesen musste und dann einen Text (je halbe A4-Seite; in LaTeX) schreiben sollte – inklusive korrekter Angabe der zitierten Fachliteratur. Als ich teilnahm wurde von den Studis durchgesetzt, dass die Hausaufgaben (die wirklich sehr zeitaufwändig waren) keine Bedingung für die Klausurzulassung waren. Dies haben sie aber, wenn ich es richtig gehört habe, in dem darauffolgenden Jahr wieder geändert. Fürs erste Semester ist das Modul echt ziemlich unpassend, da auch einige Themen rankamen (wie P/NP-Problem), die zu späteren Zeitpunkten z. B. in TheGI1 und TheGI2 behandelt werden.

Übergreifend würde ich noch sagen, dass die Auswahl von MPGI1, TheGI1 und LinA im ersten Semester ganz gut zueinander passt, da es in allen dieser Modulen (unter anderem) um Abbildungen geht (deren Notation ja jetzt ein bisschen anders – bzw genauer – als in der Schule ist).

[Das Datum dieses Postings wurde nachträglich angepasst um es mit den anderen in eine chronologisch sinnvolle Reihenfolge zu bringen.]

Informatikstudium (Formales/Organisatorisches)

Im Oktober 2008 habe ich angefangen an der TU Berlin Informatik (Bachelor) zu studieren. Das erste Semester ist nun (längst) vorbei und ich möchte Außenstehenden die Möglichkeit geben einen Eindruck zu bekommen, wie das mit dem Studium (und der Anmeldung dazu) so abläuft, da ich es mir, bevor ich angefangen hatte, selber nur schlecht vorstellen konnte. Die Informationen basieren auf dem, was ich mir zusammengesucht oder zusammengereimt habe. Für verbindliche Informationen sollten natürlich die jeweiligen Ordnungen etc. konsultiert werden. Darüber, wie das mit dem Bafög oder Stipendien abläuft, kann ich nichts sagen, da es mich nicht betrifft.

Vor dem Studium:
Es ist empfehlenswert, sich ausführlich mit dem gewünschten Studiengang zu beschäftigen, um einen Eindruck zu haben, was einen erwartet und ob dieser wirklich in Frage kommt. Hilfreich ist dazu z. B. der Studienführer und Literatur, die für die einzelnen Module empfohlen wird, sowie die Modulbeschreibungen selbst.
Außerdem ist darauf zu achten, wann welcher Studiengang beginnt, da viele aus Kapazitätenmangel seitens der Uni nur im Wintersemester angeboten werden. Man sollte herausfinden, welche Fristen einzuhalten sind – das ist zunächst insbesondere die Bewerbungsfrist.
Für die (erstmalige) Bewerbung um einen Studienplatz sind eine beglaubigte Kopie des Abiturs sowie Reisepass oder Personalausweis nötig. Die Bewerbung läuft online über ein Formular, woraus ein Ausdruck generiert wird, der dann mit den anderen Unterlagen im „Campus-Center“ abzugeben ist.
Einige Wochen vor dem Semesterbeginn findet ein Matheeinführungskurs statt, in dem im wesentlichen der komplette Abi-Stoff innerhalb weniger Wochen wiederholt wird. Daran Teil zu nehmen ist besonders sinnvoll, wenn man in Mathe nicht gerade der Beste war oder es schon einige Jahre her ist. Außerdem nimmt in den meisten Studiengängen an der TU Mathe (Lineare Algebra und Analysis) einen großen Raum ein. Ein anderes Angebot vor Semesterbeginn ist der „Early Bird“-Mathekurs, in dem man bereits die Module „Lineare Algebra“ und „Analysis I“ machen kann, und dadurch während der ersten Semester etwas Freizeit gewinnt.
Ca. zwei Monate nach der Bewerbung kommt der Zulassungsbescheid, dort steht die Frist zur Einreichung des Immatrikulationsantrags drin (ein paar Wochen später). Da Studenten krankenversicherungspflichtig sind muss zum Immatrikulationsantrag ein Krankenversicherungsnachweis einer gesetzlichen Krankenkasse vorgelegt werden oder – wenn man privat versichert ist und bleiben möchte – eine Befreiungsbescheinigung von der gesetzlichen Krankenversicherungspflicht. Für letzteren Fall muss man mit einer Versicherungsbescheinigung der privaten Krankenkasse zu einer gesetzlichen Krankenkasse (z. B. zur Barmer) gehen und die stellen dann eine entsprechende Befreiungsbescheinigung aus (das sollte man sich gut überlegen, denn während des Studiums ist in dem Fall kein Wechsel mehr möglich). Desweiteren muss der Semesterbeitrag (im Wesentlichen für das Semesterticket) überwiesen werden und der Kontoauszug als Nachweis dem Immatrikulationsantrag beigelegt werden.
Nachdem die Immatrikulationsbescheinigung angekommen ist, kann man mit den Passbildautomaten ein Foto machen und sich direkt darauf den Studierendenausweis (der auch als Semesterticket und Bibliotheksausweis dient) und die tubIT-Zugangsdaten (für WLAN, Rechnerpools, E-Mailaccount und Web-Dienste) abholen.
In der ersten Vorlesungswoche finden Einführungsveranstaltungen statt: teils weniger hilfreiche Begrüßungsreden von hohen Tieren der Uni oder Fakultät, aber auch von Studierendeninitiativen (wie der Freitagsrunde) organisierte Kleingruppentreffen oder Campus-Führungen. Während dieser Zeit muss man sich zu den Tutorien anmelden und einen Mentor wählen (mit dem hat man eigentlich nicht sehr viel zu tun – ich hatte ihn einfach anhand der besten Bewertung bei meinprof.de rausgesucht). Während des ersten Semesters sind weitere wichtige Termine der „Antrag auf Zulassung zur Bachelorprüfung“, die Prüfungsan- und Abmeldezeiten der einzelnen Module und natürlich die Prüfungen (Klausuren) an sich. Zum Ende des Semesters muss die Rückmeldung (einschließlich Überweisung der Gebühr) zum nächsten Semester erfolgen.

Das Bachelor-Studium ist in sogenannten Modulen organisiert. Es gibt eine Liste von konkreten Pflichtmodulen, die auf jeden Fall absolviert werden müssen, um den Bachelor-Abschluss zu bekommen, und es gibt so etwas wie „Wahlpflicht“-Module. Wann welches Modul belegt wird ist theoretisch egal. Es ist jedoch (zumindest in den ersten Semestern) sehr sinnvoll es so zu belegen, wie im Studienverlaufsplan vorgeschlagen, da die Module zum Einen manchmal innerhalb eines Semsters untereinander Bezug nehmen (bzw. zumindest gut zueinander passen) und zum Anderen die nacheinanderfolgenden Module aufeinander aufbauen. Bei Informatik sind es im ersten Semester die fünf Module „Methodisch-Praktische Grundlagen der Informatik – MPGI1″, „Technische Grundlagen der Informatik – TechGI1″, „Theoretische Grundlagen der Informatik – TheGI1″, „Informatisches Propädeutikum“ und „Lineare Algebra für Ingenieure – LinA“. Bei den meisten Modulen gibt es ein oder zwei Vorlesungen pro Woche und ein Tutorium (Vorlesung und Tutorium dauern jeweils 90 min). Tutorien sind vergleichbar mit Schulunterricht – also Gruppenveranstaltungen von 8 bis 40 Leuten, in denen Übungen vorgeführt und zusammen gelöst werden. In den Tutorien bilden sich Studierendengruppen (oft aus 3 Leuten), die zusammen die Hausaufgaben machen und abgeben. Die jeweiligen Tutoren (üblicherweise Studenten höheren Semesters oder wissenschaftliche Mitarbeiter) sind erster Ansprechpartner wenn es um Fragen bezüglich des Moduls geht. Zudem werden von den Tutoren noch Sprechstundentermine angeboten. Wenn es in einem Modul ein Problem gibt, wo der Tutor nicht helfen kann, kann man sich an den organisierenden wissenschaftlichen Mitarbeiter wenden. Außerdem gibt es normalerweise für jedes Modul eine Seite in der Onlinelearning-Platform ISIS, wo Vorlesungsskripte, Hausaufgaben, Termine und Ansprechpartner draufstehen. Zusätzlich können noch die (manchmal ziemlich veralteten) Internetseiten des zugehörigen Fachbereichs sinnvoll sein.

Die Prüfungsmodalitäten, also welche Anforderungen erfüllt sein müssen, dass in diesem Modul eine Prüfung (Semesterendklausur) abgelegt werden kann, und wie sich die Modulnote zusammensetzt, sind je nach Modul vollkommen unterschiedlich. Der notwendige Anteil korrekt bearbeiteter Hausaufgaben unterscheidet sich überall. In manchen Modulen gibt es zusätzlich (angekündigte, schriftliche) Tests während der Tutorien, wo ein gewisser Anteil bestanden werden muss. Manchmal gibt es „Prüfungsäquivalente Studienleistungen“, so dass ein Teil der Bewertung der Hausaufgaben in die Modulnote einfließt bzw. woanders wiederum gibt es nach der Hälfte des Semesters eine Zwischenklausur, die zur Hälfte in die Modulnote eingeht. Gemeinsam ist eigentlich nur, dass am Ende des Semesters eine Klausur geschrieben wird (wenn die Prüfungsvorraussetzungen erfüllt wurden). Während des gesamten Studiums Informatik Bachelor gibt es anscheinend planmäßig nur Klausuren – also keine mündlichen Prüfungen.

Bevor die ersten Leistungen erbracht werden (entweder die erste „prüfungsäquivalente Studienleistung“ oder die erste Klausur) muss einmal der „Antrag auf Zulassung zur Bachelor-Prüfung“ eingereicht werden. Das ist ein Formular, was beim Campus-Center abgegeben werden kann, wo es keine schriftliche Bestätigung für gibt.

Die Anmeldung zu den (Semesterend-)Klausuren läuft je nach Modul über verschiedene Systeme übers Internet (Qispos und Moses). Es gibt immer einen Anmeldezeitraum und einen Abmeldezeitraum für die Klausuren. Wenn man den Eindruck hat, eine Klausur nicht schaffen zu können sollte man sich rechtzeitig von ihr abmelden (oder garnicht erst anmelden), denn man hat nur zwei schriftliche und einen mündlichen Versuch. Fällt man durch alle Verusche durch und handelt es sich um ein wichtiges Modul, wird man für alle Unis für alle Studiengänge, die dieses Modul erfordern, gesperrt.
Wenn man eine Klausur nicht mitschreibt, weil man sie später schreiben möchte, sollte beachtet werden, dass das oft erst nach einem Jahr (2 Semestern) möglich ist, sofern das Modul nur im Winter- oder Sommersemester stattfindet. Bei manchen Modulen darf man jedoch direkt den „Nachschreibetermin“ bzw. „2. Termin“ (eigentlich für Leute die krank waren oder am ersten Termin nicht bestanden haben) auswählen. Der findet dann am Ende der Semesterferien statt. Beim Nichtbestehen eines Moduls muss die Klausur innerhalb von einem Jahr wiederholt werden.

Der Zeitumfang der Hausaufgaben sollte nicht unterschätzt werden – bei mir waren es teilweise bis zu 5 Stunden pro Woche pro Modul. Generell empfinde ich das Studieren anstrengender, aber auch interessanter, als ne 40-Stunden Arbeitswoche als Programmierer, da es ununterbrochen etwas neues zu Lernen gibt.

Der wesentliche Unterschied zwischen Bachelor und den Diplomstudiengängen ist wohl, dass beim Bachelor versucht wird die Leute zu zwingen in einer bestimmten Zeit bestimmte Dinge zu lernen (Lernfortschrittskontrolle). Zum einen ist es so, dass das Bachelor-Studium maximal doppelt so lange dauern darf, wie die Regelstudienzeit (Regelstudienzeit bei Informatik Bachelor sind 6 Semester, das Maximum wäre also 12 Semester). Desweiteren muss innerhalb eines Jahres eine bestimmte Anzahl an Leistungspunkten (LP) gesammelt werden. Für jedes bestandene Modul gibt es eine bestimmte Anzahl an LP. Die empfohlenen Studienverlaufspläne sind so ausgelegt, dass die Anzahl der LPs deutlich über dem Jahres-Mindestwert liegt und dieser daher immernoch einhaltbar ist, wenn ein paar Module nicht bestanden werden. Wird die Lernfortschrittskontrolle nicht eingehalten, wird man zu seinem Mentor geordert und führt ein Gespräch, wie das passieren konnte. Bei nachvollziehbaren Gründen wird dann ggf. ein Auge zugedrückt.

Bei den Modulen, die ich in den ersten zwei Semstern hatte, gab es keine Anwesenheitspflicht/Kontrolle für Vorlesungen und Tutorien. Es ist natürlich trotzdem anzuraten überall hin zu gehen. Es kann auch mal vorkommen, dass dann in der Klasur etwas kommt wie „Lösen Sie die Aufgabe nach dem in der Vorlesung vorgestellten Verfahren“, ohne dass das in den Tutorien oder Hausaufgaben behandelt wurde (war bei mir ausgerechnet bei der langweiligsten Vorlesung so). Außerdem werden manchmal in den Vorlesungen natürlich wissenswerte organisatorische Dinge angesagt.

Vielleicht werde ich später in einem weiteren Posting noch näher auf die Inhalte der einzelnen Module eingehen.

Dual-Head: Desktoperweiterung mit xrandr

xrandr (von „Resize and Rotate Extension“) dient zum Konfigurieren der angeschlossenen Bildschirme. Mit xrandr lässt sich X auch so konfigurieren, wie was bisher mit Xinerama erreicht wurde (Desktoperweiterung durch mehrere nebeneinandergestellte Monitore).

Ein Aufruf ohne Argumente liefert die Outputs und wählbare Modi. Auf meinem MacBook mit angeschlossenem TFT sieht das etwa so aus:

$ xrandr
Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 2560 x 1024
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+224 (normal left inverted right x axis y axis) 286mm x 179mm
   1280x800       59.9*+   60.0
   1280x768       60.0
[...]
TMDS-1 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x800       60.0 +
   1280x1024      60.0*+   75.0     59.9     60.0*
TV disconnected (normal left inverted right x axis y axis)

TMDS-1 ist das externe Display, LVDS das integrierte (auch zu erkennen an den Auflösungen).

Die Konfiguration läuft nun z.B. so ab:
xrandr --output LVDS --mode 1280x800 --output TMDS-1 --off
…was das interne Display einschaltet und das externe deaktiviert, bzw. umgekehrt:
xrandr --output TMDS-1 --mode 1280x1024 --output LVDS --off

Mit --output wird also gewählt, was konfiguriert werden soll. Sollen mehrere Displays gleichzeitig konfiguriert werden, kann --output mehrmals angegeben werden, gefolgt von den entsprechenden Einstellungen (Rest siehe Manpage).

Soll der Desktop über beide Displays gehen, müssen beide Outputs aktiviert und ein entsprechender Versatz definiert werden:
xrandr --output LVDS --mode 1280x800 --pos 0x224 --output TMDS-1 --mode 1280x1024 --pos 1280x0
…hier ist es so, dass das Notebook links neben dem externen TFT steht und an dessen Unterkante ausgerichtet ist.

Damit das funktioniert, muss in der /etc/X11/xorg.conf in der entsprechenden Display-SubSection die virtuelle Auflösung definiert werden:

Section "Screen"
[...]
  SubSection "Display"
    [...]
    Virtual 2560 1024
  EndSubSection
EndSection

Damit diese Änderung wirksam wird, muss X neugestartet werden (also z.B. Abmelden und dann Ctrl+Alt+Backspace). Die ganzen Auflösungen müssen natürlich entsprechend der Displays angepasst werden.

Etwas bekloppt bei so Displays mit verschiedenen Vertikal-Auflösungen (bzw. unterschiedlichen Seitenverhältnissen) ist, dass es bei mir z.B. links oben einen Streifen von 1280×224 Pixeln gibt, der nicht benutzbar ist.

Bei manchen Anwendungen (irgendwelche Spiele), die im Vollbildmodus laufen und/oder versuchen von sich aus die Auflösungen zu verstellen kann es zu Problemen kommen. Da ist es meistens am sinnvollsten z.B. nur auf den externen Monitor umzuschalten.

Gewaltbereitschaft eines Teils der Atomkraftgegner

Zu beachten ist die tolle Bildunterschrift: http://www.mv-online.de/_em_cms/_globals/zoom.php?em_src=319039