Verwandte Artikel

• Keine verwandten Artikel

Verwandte Artikel

• Norwegen – Tag 21 (2)
• Norwegen – Tag 20 (1)
• Norwegen – Tag 18 (1)
• Norwegen – Tag 17 (2)
• Norwegen – Tag 16 (1)

Um Git Repositories vernünftig hosten zu können gibt es das Tool gitosis, welches bereits als Debian-Paket verfügbar und somit leicht zu installieren ist:

Im Anschluss muss man gitosis mit einem SSH public key initialisieren, damit man sich ohne Passwort mit dem gitosis Repository (welches zur Konfiguration verwendet wird) verbinden kann. Eine entsprechenden Schlüssel kann man mit ssh-keygen erzeugen:

Diesen Schlüssel muss man jetzt für gitosis aktivieren:

gitosis verfügt über ein eigenes Konfigurations-Repository über das es konfiguriert werden kann. Dieses lässt sich wie folgt auschecken:

Dieser Befehl checkt das Repository aus und speichert es im aktuellen Pfad im Verzeichnis gitosis-admin. In diesem befindet sich einerseits eine Konfigurationsdatei gitosis.conf, sowie zusätzlich ein Verzeichnis keydir, in dem die SSH public keys der Benutzer gespeichert werden.

In der Konfigurationsdatei gitosis.conf gibt es Blöcke für Benutzergruppen und Repositories. Ich lege daher einfach einmal eine Gruppe für Entwickler an (wo allerdings momentan nur ich Mitglied bin). Außerdem sage ich, dass diese Gruppe mit dem Repository diplomarbeit (vielleicht sollte ich mehr Leute in diese Gruppe schreiben, vielleicht findet sich ja ein Depp der mir die Arbeit abnimmt) arbeiten darf.

Die geänderte Konfiguration kann mittels der folgenden Befehle aktiviert werden:

Der erste Befehl speichert dabei die Änderungen in der lokalen Kopie des Repositorys, während mit git push die Änderungen auf das Remote-Repository übertragen werden.

Die Diplomarbeit lässt sich jetzt in das Repository einchecken (dazu muss zuerst in das entsprechende Verzeichnis gewechselt werden):

Mit git init wird dabei ein lokales git Repository angelegt (d.h. das Verzeichnis .git wird erstellt), mit git remote add wird ein neues Ziel origin angelegt, welches der angegebenen URL entspricht). Anschließend können die lokalen Dateien für die Versionskontrolle aktiviert werden (git add teilt git mit, das diese Dateien ab sofort unter Versionskontrolle sein sollen):

Die Änderungen (d.h. das Hinzufügen der Dateien) muss nun noch bestätigt werden, wobei hier zusätzlich ein entsprechender Kommentar angegeben werden sollte, der die Änderungen beschreibt:

Das Repository muss nun auch auf den Server gepusht werden. Hierbei werden die Änderungen an das Ziel origin (welches zuvor mit git remote add konfiguriert wurde) übertragen. Diese werden dabei in die lokale Branch master als remote Branch heads/master gespeichert werden soll:

Die Repositories werden auf dem Server dabei im Verzeichnis /srv/gitosis/repositories/ gespeichert, welches natürlich entsprechend in die Backups aufgenommen werden sollte.

Verwandte Artikel

• UML Sequence Diagram Online (0)
• Tips zum Schreiben von Dokumentationen (1)
• Stanford CS193P: iPhone Application Programming (0)
• Puzzle Websites to Sharpen Your Programming Skills (0)
• How a programmer reads your resume (0)

Verwandte Artikel

• Schneeschuhwanderung auf der Rax (0)
• Norwegen – Tag 21 (2)
• Norwegen – Tag 20 (1)
• Norwegen – Tag 18 (1)
• Norwegen – Tag 17 (2)

Hier noch ein Video, welches die Augmented Reality Fähigkeiten demonstriert:

Da kann man eigentlich eh nur eines dazu sagen: MUSS ICH HABEN!

Verwandte Artikel

• Laser-Navigation am MIT UAV (0)

Gefunden habe ich das wieder einmal über /Film: GandALF T-Shirt, zu bestellen ist es bei TeeFury.

Verwandte Artikel

• Trailer zu Black Lightning (0)
• The Tournament (0)
• The Good, The Bad, The Weird (0)
• Solomon Kane (0)
• Prince of Persia: The Sands of Time (0)

Wie auch andere hat Solomon Kane das Ziel das Böse zu vernichten. Als Figur ähnelt er dabei sehr Van Helsing, was auch in dem Trailer recht deutlich erkennbar sein sollte. Der Film sollte dieses Jahr in die Kinos kommen, ich bin jedenfalls schon sehr gespannt darauf.

Verwandte Artikel

• Trailer zu Black Lightning (0)
• Prince of Persia: The Sands of Time (0)
• King of Fighters (0)
• Give ‘em Hell, Malone (0)
• The Tournament (0)

Der Lieferumfang des Development-Boards ist jedenfalls sehr ausführlich: 3 serielle Kabel, 2 externe Stabantennen, eine externe Stehantenne, eine Netzgerät mit echtem und mit amerikanischem Anschlusskabel sowie einer Software-CD.

Nach erfolgreichem Zusammenbau und erstem Schock, weil die orange Power-On-LED nur kurz nach dem Anstecken aufblinkt und dann ausgeht habe ich mein serielles Kabel am Mac angesteckt und eine Screen-Session darüber gestartet:

Und schon sieht man den Boot-Prozess des Gerätes.

Nach kurzen nachschauen im Manual habe ich dann auch gleich das Passwort (admin / access) gefunden – und den hinweis überlesen, das bei älteren Firmware-Versionen root als Benutzer zu verwenden ist. Naja, 3 Versuche später hab ich es dann erfolgreich erraten.

Erster Schritt am eingeloggten System: welche Version hamma denn?

Dann mal die Überprüfung, wie viel Speicherplatz wir denn eigentlich verwenden (dabei habe ich auch gleich festgestellt, das jffs2 als root-Filesystem verwendet wird):

Hm, nicht viel, sollte aber für’s erste Mal ausreichen. Sodann überprüfe ich einmal, welche Module denn verwendet werden – in der Vermutung, das das sicher teilweise recht spezifische sein werden:

Eigentlich sollte ich ja eine aktuelle Version der Firmware installieren, aber das funktioniert irgendwie nicht so wie geplant – es ist zwar möglich, diese via TFTP oder auch über das eigene UpdateIP Programm auf das SX-560 zu transferieren, dort passiert aber genau nichts damit. Ich vermute das ist ein Problem der frühen Version (1.00A scheint das bei mir zu sein, offenbar sind da irgendwelche alten Lagerhallten bei der Bestellung geräumt worden).

Der nächste Schritt ist es, die Tool Chain für das Ding zu laden und zu installieren. Dabei gibt es im wesentlichen 2 verschiedene Dinge und Ergebnisse:

Erzeugen eines neuen Root-Filesystems

Damit habe ich mich noch nicht wirklich sonderlich auseinander gesetzt, weil ich annehme, dass die ohnehin vorhandenen Firmware-Images ganz brauchbar sind. Und auf 8MB Flash lässt sich ja auch nicht sonderlich viel unterbringen. Die dazu benötigten Files findet man jedenfalls hier auf der Silex Homepage, wobei zu beachten ist, das man bei einer aktuellen Version von Buildroot ein paar Anpassungen durchführen muss, die im folgenden Abschnitt erklärt werden. Wenn man sich jedenfalls an die Anleitung in der dortigen Readme hält, bekommt man als Endresultat ein ext2-Image (eventuell sollte man hier also noch etwas umkonfigurieren, um ein JFFS2 Image zu erhalten).

Erzeugen einer Tool-Chain um eigene Programme zu erstellen

Für diese Aufgabe ist auf der Silex Homepage ebenfalls eine Anleitung zu finden, an die man sich weitgehend halten kann. Es waren lediglich zwei Dinge umzukonfigurieren: die Version des empfohlenen Kernels ist nicht mehr in der Auswahlliste vorhanden, da der schon zu verstaubt ist. Ich habe es noch nicht probiert, ob das ganze auch mit einem aktuellen Kernel noch funktioniert (bzw. sich mit dem installierten 2.6.16er verträgt) – insbesondere da ja auch in der Anleitung nicht die aktuelle sondern die vorige Version verwendet wird. Dazu muss man nach dem make menuconfig in der .config die Optione BR2_KERNEL_HEADERS_2_6_22=y einfügen, und den Default-Kernel ändern:

Im Anschluss kann man das ganze Ding kompilieren, wobei er sich da zumindest zweimal dastoßen wird: beim Kernel und bei der Libc. In beiden Fällen betrifft es eine Inkompatibilität der unifdef.c mit der stdio.h, sodass die Datei unifdef.c bei der er da jeweils meckert entsprechend adaptiert werden muss (siehe auch dieser Kernel-Patch):

Wenn das alles erfolgreich funktioniert hat, findet man im Verzeichnis build_arm/staging_dir/usr/bin/ den Cross-Compiler arm-linux-gcc sowie weitere Tools. Damit kann dann das erste Programm erstellt, kompiliert und mittels TFTP auf den SX-560 kopiert werden.

Verwandte Artikel

• Keine verwandten Artikel

Für Xen-Systeme ist es recht gängig, die einzelnen Partitionen als LVM Volumes einzurichten, da diese leicht auf mehrere physikalische Geräte verteilt und einfach vergrößert werden können. Ein zusätzliches wichtiges Feature für Server-Systeme ist es, dass mit LVM auch sehr einfach Snapshots eines (laufenden) Volumes erstellt werden können.

Um ein LVM Logical Volume zu kopieren (ohne dabei Einfluss auf die laufenden Systeme zu nehmen), sollte zuerst ein Snapshot von dem entsprechenden Volume gemacht werden. Um einen Snapshot zu erstellen, wird der Befehl lvcreate verwendet, wobei der Parameter -s einen Snapshot erstellt. Mit dem Parameter -n wird der Name des Snapshot-Volumes angegeben (im Beispiel lv01-snapshot), und als letzter Parameter das Volume, von dem der Snapshot erstellt werden soll (in diesem Fall /dev/vg0/lv01). Zusätzlich muss noch die Größe des Volumes angegeben werden, da diese – aus für mich unerfindlichen Gründen – nicht automatisch übernommen wird. Diese Größe kann man mit lvdisplay /dev/vg0/lv01 herausfinden (es ist das Attribut LV Size) und mit dem Parameter -L an lvcreate übergeben:

Dieses Snapshot Volume kann nun über beliebige Methoden auf den Zielserver übertragen werden. Dazu muss zuerst ein DiskDump davon erstellt werden, der dann beispielsweise über HTTP oder SCP oder ähnliche Methoden auf das Zielsystem kopiert werden kann (eine elegante Methode wäre natürlich auch die Übertragung mittels netcat). Um einen DiskDump zu erstellen kann der folgende Befehl verwendet werden:

Auf dem Zielsystem muss nun ein entsprechendes Logical Volume der passenden Größe erstellt werden. Auch dazu wird der Befehl lvcreate verwendet:

Nachdem der Diskdump vom Quellsystem auf das Zielsystem übertragen wurde, kann dieser entsprechend auf das Logical Volume geschrieben werden:

Es ist natürlich genauso möglich, den Zwischenschritt über den DiskDump als Datei zu überspringen und das ganze direkt zu übertragen, beispielsweise über SCP (ideal wäre hier natürlich die Verwendung von netcat):

Bei einem hinreichend schnellen Netzwerk kann die Komprimierung mit gzip genausogut entfallen. Wobei hier vermutlich die Komprimierung weniger rechenintensiv ist, als die Verschlüsselung durch ssh.

Nachdem das Volume erfolgreich übertragen wurde, kann der Snapshot wieder gelöscht werden. Dies geschieht mit dem folgenden Befehl:

Wenn alle Volumes eines Xen-Gastsystems übertragen wurden, sollte sich dieses am Zielsystem genauso starten lassen, wie am Quellsystem. Es ist dabei jedoch eventuell darauf zu achten vorher die IP-Adressen zu aktualisieren.

Verwandte Artikel

• Keine verwandten Artikel

Das Gesetz kurz zusammengefasst lautet:

All work expands so as to fill all the time available for its completion.

Das Gesetz führt dies vor allem auf die “Beamtenexplosion” zurück, die durch 2 Faktoren induziert wird:

1. Jeder Beamte möchte lieber Untergebene als gleichrangige Mitarbeiter haben.

   Wenn ein Beamter überarbeitet ist (sei es durch echte Arbeit oder nur als Illusion), dann hat er 3 Optionen zur Verfügung: er kann kündigen (das wird allerdings kaum einer freiwillig tun), er kann versuchen einen gleichrangigen Mitarbeiter zu bekommen mit dem er die Arbeit teilen kann (das wir er allerdings auch nicht tun, da dies seine Chance auf Beförderung verringert) oder er kann versuchen Untergebene zu erhalten.

   Nun ist es jedoch so, dass er mindestens 2 Untergebene braucht, weil wenn er nur einen Untergebenen hätte, dann wäre das im Prinzip mit einem gleichrangigen Kollegen gleichzusetzen.Früher oder später wird das Überarbeitungsproblem auch einen der Untergebenen treffen, sodass hier weitere 2 Untergebene angestellt werden. Der ursprünglich überarbeitete Beamte hat damit eine ganze Hierarchie unter sich aufgebaut, wodurch wiederum seine Chancen auf Beförderung gestiegen sind.

2. Arbeit tendiert dazu, sich zu vervielfältigen.

   Da nun mehrere Beamten das gleiche tun, was zuvor ein einziger getan hat, ist mehr Aufwand notwendig, um diese zu koordinieren. Wenn zum Beispiel der Chef irgendein Dokument bekommt, so wird er es einem seiner Untergebenen weiterleiten. Dieser kann nun behaupten, dass einer seiner Kollegen besser dazu geeignet ist, und das Dokument geht mit entsprechend immer mehr Memos im Kreis herum. Das führt dazu, dass weitaus mehr Leute weitaus länger brauchen, als wenn es gleich nur einer bearbeiten würde.

Das Gesetz wird durch statistische Daten aus der britischen Regierung bestätigt. Es wird statistisch gezeigt, das die Anzahl der Beamten pro Jahr um etwa 5% steigt. Das ganze wird auch durch entsprechende Formeln unterlegt.

Der Ursprungsartikel The Law for Late Projects zeigt uns quasi die erste Ableitung des Gesetzes:

Wenn ein Manager ein Projekt betreut, und dieses ohne Probleme in der vorgegebenen Zeit umgesetzt werden kann, so bedeutet dies, dass der Manager das Team nicht genügend getreten hat, da das Projekt auch weitaus früher hätte fertig sein können (der Manager hat daher versagt, weil er Geld der Firma vergeudet hat). Wenn nun ein wissender diesem Manager vor Projektbeginn mitteilt, das das Projekt auch ein Monat schneller umgesetzt werden kann, so wird der Manager diesen kürzeren Termin wahrhaben. Falls das Projekt trotzdem noch in der Zeit durchgeführt werden kann, hat der Manager natürlich noch immer versagt, weil das Projekt eventuell noch schneller hätte fertig werden können.

Es liegt daher im Interesse der Manager die Deadlines für das Projekt unrealistisch kurz zu setzen, sodass diese nicht eingehalten werden, weil der Manager so garantiert nicht versagen kann (weil das Team ja offenbar gemanaget werden muss, da es sonst die Termine erst gar nicht einhalten kann).

Die Ableitung von Parkinsons Gesetz ist daher wie folgt definiert:

Management will always try to make a project late.

Verwandte Artikel

• Keine verwandten Artikel