Vor ein paar Tagen habe ich einen Schatz angebrochen, der noch vom letztjährigen Kalender übriggeblieben ist: eine kleine Tafel Schokolade. Sie wiegt nur 30 Gramm, ist in schwarzes Papier gekleidet und hört auf den vielversprechenden Namen Noir Infini.

Das alles machte einen so edlen Eindruck, daß ich es nicht für einen gewöhnlichen Feierabend verschwenden wollte. Jetzt hat sich aber das eine oder andere ruhige Stündchen ergeben, und ich muß sagen: das Warten hat sich gelohnt. Ich versuche gar nicht erst, das näher zu beschreiben, aber sie schmeckt wirklich sehr dunkel und sehr edel.

Übrigens fällt mir gerade auf, daß ich dunkle Schokolade (unabhängig von der Qualität) sehr genau dosieren kann, während ich Milchschokolade kaum zu essen aufhören kann.

Kein Kommentar

von kirjoittaessani


Tags:

Das Versionskontrollsystem git habe ich ja schon gelegentlich erwähnt. Heute ist mir aufgefallen, daß git bei aller Komplexität und Mächtigkeit dadurch, daß sich Repositories so einfach einrichten lassen, auch wunderbar leichtfüßig[1] ist. Früher[2] habe ich echte Versionskontrolle[3] nur für größere Softwareprojekte verwendet, kleinere Projekte habe ich allenfalls mit RCS verwaltet.

Derzeit stecke ich mehr und mehr auch Kleinkram in git: Konfigurationsdateien -- früher mehr schlecht als recht in RCS[4] -- lassen sich so wunderbar handhaben. Ganz nebenbei bietet git auch noch eine Art Deployment: ich kann auf meiner Maschine entwickeln und dann einfach auf den Server, den ich eigentlich konfigurieren will, klonen. So bleiben alle Projekte und Projektchen schön übersichtlich beisammen; und dank Gitzilla ist auch für eine sinnvolle Dokumentation gesorgt.
Das einzige, was ich jetzt noch vermisse, ist eine gute und universelle Testumgebung: irgendetwas, das für ein neues Projekt keiner aufwendigen Neukonfiguration bedarf, das aber das Testen von neuen Konfigurationen ermöglicht, bevor sie auf den Produktionsserver geschoben[5] werden.

  1. lightweight
  2. TM
  3. z.B. CVS
  4. oder gar nicht verwaltet
  5. deployt? deployed?
Kein Kommentar

von kirjoittaessani


Erkenntnis des Tages: Gitflow macht Spaß!

Außerdem fange ich an, ein zweites kürzlich entdecktes Werkzeug regelmäßig zu nutzen: Gitzilla. Das ist -- man ahnt es fast -- eine Git--Bugzilla-Integration. Nach der Installation läuft Gitzilla unsichtbar im Hintergrund. Wenn man nun in einem Git-Commit-Text eine Bugnummer aus dem angeschlossenen Bugzilla erwähnt, dann erscheinen automatisch Informationen zu diesem Commit als Kommentar in dem Bug.
Das ist sehr praktisch, um eine Gesamtdokumentation zu erstellen (statt Bugzilla und Git-Historie nebeneinander her laufen zu lassen)

Wer mag, kann die Bugnummer sogar erzwingen, aber für mich als Einzelkämpfer ist das übertrieben.

Zum Schluß noch ein kleiner Tipp für alle, die es selbst ausprobieren möchten: Gitzilla wird beim Push in ein (zentrales) Repository aktiv, nicht schon beim lokalen Commit. Das steht zwar in der Dokumentation, ich habe mich zunächst aber trotzdem gewundert, als nichts passiert ist. Diese Repositories habe ich mit mit --shared --bare in /home/git auf meiner Maschine angelegt, so sind sie zwar mir zugeordnet, aber trotzdem von meinen eigenen Daten getrennt.

2 Kommentare

von kirjoittaessani


Sam näki ensi kerran ihmisten taistelevan ihmisiä vastaan eikä hän erityisemmin pitänyt näkemästään. Hän oli iloinen ettei hän ollut nähnyt kuolleen kasvoja. Hän mietti, mikähän miehen nimi oli ja mistä hän oli kotoisin.

Aus dem Herrn der Ringe. Dazu geht mir so viel durch den Kopf, daß ich das einfach mal unkommentiert stehen lasse.

Kein Kommentar

von kirjoittaessani


Neulich vor dem Frühstück: der Bär steht in der Küche und pfeffert seinen Schnuller quer durch den Raum. Dann fixiert er ihn mit seinem Blick, wirft seine Hand in einer gebieterischen Geste nach vorn und wiederholt nachdrücklich: 'nulli 'aben! 'nulli 'aben!

Kein Kommentar

von kirjoittaessani


Eigentlich bin ich kein großer Fan von Biographien, aber heute will ich eine Ausnahme machen und ein paar Worte zu Heisenbergs Der Teil und das Ganze sagen.

Mich hat vor allem interessiert, einen Einblick in die Anfangszeit der Quantenmechanik zu bekommen -- eine Zeit, in der die Tür zu einem weiten Feld gerade aufgestoßen war, in der es (jedenfalls aus heutiger Sicht) viel zu entdecken und zu erforschen gab und in der Geschichte passierte. In dieser Beziehung bin ich natürlich auf meine Kosten gekommen, aber es gibt auch noch andere interessante Episoden in dem Buch. Bevor ich auf diese näher eingehe, will ich noch kurz erwähnen, daß der an den physikalischen Laien gerichtete Text zu wissenschaftlichen Problemen meist nur Andeutungen macht, die gerade ausreichen, die Neugier zu wecken, nicht jedoch, sie zu stillen. Da werde ich mich wohl noch anderweitig informieren müssen.
So war mir zum Beispiel neu, daß die Heisenbergsche Quantenmechanik ursprünglich keine Wellenmechanik war. Die hat Schrödinger erst später eingeführt, und ich wüßte doch zu gerne, wie diese ursprüngliche Formulierung aussah.

Neben der Physik kommen aber, wie gesagt, auch noch andere Themen vor.
Die Beschreibung der Anfangszeit in Göttingen und der Spaziergänge, die Heisenberg dort mit Bohr unternimmt, haben ein bißchen das Gefühl von Heimat geweckt.
Besonders eindrücklich habe ich aber die Zeit des dritten Reiches empfunden -- man redet dabei so oft von der Verfolgung der Juden und anderer Minderheiten, daß der Blick auf den Durchschnittsbürger oft ein bißchen in Vergessenheit gerät: die bedrückende Stimmung in einem totalitären Staat, die Katastrophe, die vielen schon früh als unausweichlich erschien, und die Frage, wie man sich selbst verhalten soll.

Zum Schluß möchte ich noch kurz auf die Art der Darstellung eingehen: Der Autor bestreitet große Teile des Buches durch Gespräche mit Zeitgenossen. Das zieht den Leser in die Geschehnisse mit hinein und sorgt gleichzeitig für einen sehr persönlichen Blick auf die Dinge.

Mir fehlt, wie zu Anfang schon angedeutet, die Erfahrung, diese Form der Darstellung in den Kontext anderer Biographien einzuordnen. Mir hat sie jedoch gut gefallen.

Kein Kommentar

von kirjoittaessani


Am Anfang seiner Karriere war Professor Mortimer in Kairo: hier hat er das Geheimnis der großen Pyramide[1] gelüftet. Die Geschichte ist ursprünglich in zwei Bänden erschienen, die in der deutschen Ausgabe die Nummern eins und zwei tragen. Der eigentliche Beginn der Reihe, das dreibändige Kriegsepos Der Kampf um die Welt, ist erst etliche Jahre später auf deutsch veröffentlicht worden.

Weil dies schon meine dritte Rezension zu Blake und Mortimer ist, will ich mich kurz fassen: Jacobs' Stil begeistert mich nach wie vor, aber den Futurismus der späteren Bände vermisse ich doch. Stattdessen bekommen wir eine kleine Dosis Magie, die meines Erachtens nicht so recht zu den Hauptfiguren paßt. Deshalb mag ich diesmal auch nur vier von fünf Sternen vergeben.

Meine Ausgabe ist in einem Band bei Dargaud erschienen, und sie kann sich durchaus sehen lassen: unter den 128 Seiten finden sich auch zwölf mit Abdrucken der ursprünglichen Veröffentlichung in Form einer Fortsetzungsgeschichte im Tintin; ein Festeinband versteht sich von selbst.

  1. Cheops-Pyramide
Kein Kommentar

von kirjoittaessani


Tags:

Jeder weiß, daß man Dokumente, in denen viel Hirnschmalz in wenig Text verpackt ist[1], in einem Revision Control System hält. Ich habe früher CVS für größere Projekte und RCS für Kleinkram[2] verwendet.

For ein paar Jahren bin ich dann auf git umgestiegen: Neben dem einfachen Einrichten des Repository[3] macht vor allem das leichte und schnelle Branchen Spaß. Zugegeben, git hat auch seine Schwächen, und die Bedienung ist nicht immer einfach[4].

Trotzdem überwiegen in meinen Augen zumindest gegenüber SVN und CVS (und natürlich RCS) die Vorteile. Vor ein paar Tagen bin ich zufällig über einen Blog-Eintrag von Vincent Driessen gestolpert, der dem Werkzeug git sozusagen als Überbau noch einen Prozeß oder einen Satz Richtlinien hinzufügt -- Anweisungen, wann man welche Branches erzeugen soll, und wohin sie gemerget werden. Das Modell gefällt mir auf Anhieb recht gut, und weil es dazu auch ein Tool gibt, das das Einhalten des Prozesses stark vereinfacht, werde ich meine Repositories demnächst wohl nach und nach umstellen.

Vincents Modell hat natürlich auch Kritiker, und wer tiefer einsteigen will, sollte sich die Diskussion zu Jeffs Blog-Eintrag durchlesen. Wahrscheinlich am meisten nachgedacht hat Adam Dymitruk. Die Feinheiten seines Modells sind für mich zu dieser späten Stunde definitiv zuviel, aber mir gefällt die Idee, Feature Branches unabhängig zu halten, so daß man jedes Feature jederzeit wieder ausbauen kann.[5]

Edit: HTML an falscher Stelle
Edit 2: Typo

  1. z.B. Source Code und Konfigurationsdateien
  2. z.B. Dateien aus /etc
  3. ja, ich benutze normalerweise auch lieber deutsche Begriffe, aber heute lasse ich das aus gutem Grunde mal sein: wenn man gut eingeführte termini technici übersetzt, versteht am Ende niemand etwas
  4. manche Kommandos muß ich heute noch immer wieder nachschlagen, checkout -b vergesse ich regelmäßig, wenn ich es nicht oft genug benutze
  5. jedenfalls bis zum nächsten Release
2 Kommentare

von kirjoittaessani


Dieser Artikel ist für mich eine Premiere -- ich nehme nämlich zum ersten Mal an einer Blogparade teil. Diejenigen, die nicht wissen, was das ist (bis gerade eben gehörte ich auch dazu) können sich das Ganze als große Schwester der Stöckchen vorstellen. Man schreibt zu einem vorgegebenen Thema, allerdings ohne daß sich das ganze endlos durch Raum und Zeit zieht; stattdessen gibt es einen Einsendeschluß (Deadline heißt das heutzutage wohl), und die Verbindung zum Erfinder der Blogparade soll -- anders als beim Stöckchen -- auch nicht abreißen.

Berufen

Also gut: diese Blogparade stammt von Wibke Ladwig, und ich habe sie bei Tanja entdeckt. Die Frage lautet schlicht: Was machen Sie beruflich? Dabei soll es insbesondere um neue Berufsbilder gehen. Was mache ich also beruflich? Ich habe gerade noch einmal nachgeschlagen: In meinem Arbeitsvertrag steht das gar nicht -- trotzdem sind mein Chef und ich uns einig, daß ich Systemadministrator bin. Das hört sich -- verglichen mit einigem, was einem bei dieser Blogparade so begegnet -- noch recht verdaulich an: es ist auf jeden Fall was mit Computern, und wahrscheinlich verrate ich den meisten von Euch nichts Neues, wenn ich mein Tagewerk zusammenfasse: ich halte die Computer am Laufen.

Fachfremd

Was heißt das konkret? Zunächst möchte ich anmerken, daß ich (wie wahrscheinlich die meisten Admins) sozusagen als interner Dienstleister fungiere: um uns herum sitzen lauter kernkompetente Menschen, die tolle Produkte herstellen, und wir sorgen dafür, daß sie dazu alles haben, was sie brauchen. Vielleicht ist der Beruf auch deshalb so vielseitig: es gibt einfach nicht genug Kollegen, um eine starke Spezialisierung zu ermöglichen.
Was tut ein Admin also für seine Kollegen (oder, wenn man so will, Kunden)? Grob kann man das in drei Bereiche einteilen: er beschafft neue Dinge (seien es nun Rechner oder Programme), er sorgt dafür, daß die vorhandene Hard- und Software funktionsfähig bleibt, und er unterstützt die Anwender im Umgang mit der EDV.

Beschaffen

Als erstes fällt einem hier wohl der Kauf neuer Rechner ein. Das hört sich vielleicht trivial an, ist es aber oft nicht: schon ein gewöhnlicher Arbeitsplatzrechner bedarf einiger Überlegung, wenn er nicht nur eine größere Zahl Festplatten beherbergen soll, sondern auch noch fünf Jahre quasi ununterbrochen Dienst tun soll (unsere Rechner laufen auch nachts und am Wochenende).
Wenn es dann darum geht, ein echtes Arbeitspferd zu kaufen, dessen Preis oft über dem eigenen Jahresgehalt liegt, wollen alle Möglichkeiten sorgfältig ausgelotet werden: wieviel Speicher, wie viele und welche Prozessoren von welchem Hersteller, brauchen wir ein Hochgeschwindigkeitsnetzwerk, und so weiter. Am grünen Tisch lassen sich diese Fragen nicht beantworten, hier sind dann Benchmarks mit unserer Software gefragt.
A propos Software: in vielen Fällen greift man auch hier einfach zum Beschaffungsauftrag. Wenn es das benötigte am Markt gibt, ist das in der Regel billiger als eine Eigenentwicklung. Aber es kommt natürlich oft vor, daß es keine fertige Lösung gibt, und dann schreibt der Admin eben selber ein Programm. Das fängt an bei einem kleinen Skript zur Automatisierung häufiger Arbeitsschritte und kann bis zu ausgewachsener Software gehen -- mein ganzer Stolz ist derzeit ein grafisches Front-End (genauer: ein CGI), für unser Batch-System.

Erhalten

Auch das einfachste Werkzeug braucht Pflege. Computer sind nun alles andere als einfach, und entsprechend aufwendig ist ihre Wartung. Fehlersuche ist an der Tagesordnung: Fehler in Hardware, Fehler in gekauften Programmen, Fehler in selbstgeschriebenen Programmen, und Fehler in Programmen der Kunden[1] wollen gefunden und ggf[2] behoben werden. Obwohl meine Lieblingsbeschäftigung das Programmieren ist, hat die Fehlersuche ihren eigenen, ganz besonderen Reiz: mit Intuition und den unterschiedlichsten Werkzeugen[3] pirscht man sich -- manchmal über Tage -- immer näher an die Ursache heran, und das Gefühl, ein besonders heimtückisches Problem erfolgreich analysiert zu haben, ist schon etwas ganz Besonderes.

Auch wenn kein Fehler auftritt, gibt es immer etwas zu verbessern: Computer sind ja nur deshalb so vielseitig einsetzbar, weil auf einfachste Operationen (die vier Grundrechenarten und ein bißchen Logik) Abstraktionsebene über Abstraktionsebene gebaut wird, bis Begriffe entstehen, die ein gegebenes Problem lösbar werden lassen. Und selbst dann, wenn man mit dem Computer nur Probleme lösen will, die man ohne Computer nicht hätte[4], kann man sich die Arbeit mit jeder zusätzlichen Abstraktionsebene weiter erleichtern. So hilft eine Verwaltungssoftware dabei, auf einem Haufen Computer gleiche Programme zu installieren oder Einstellungen vorzunehmen, ohne jeden einzelnen anfassen zu müssen; wenn man Programme in Pakete packt, lassen sie sich leichter auf verschiedenen Rechnern mit verschiedenen Betriebssystemen installieren; Überwachungssoftware hilft, aus dem Zoo von Rechnern diejenigen mit defekten Festplatte oder fehlerhaften Programmen herauszufischen, bevor die Benutzer Probleme bekommen; ... diese Liste ließe sich noch lange fortführen.

Unterstützen

Mit einem funktionierenden Rechner- und Softwarepark ist es natürlich noch nicht getan. Ziel des ganzen ist ja, daß die Benutzer die Rechner für ihre Zwecke einsetzen können. Deshalb helfen wir bei allen möglichen Problemen, ob nun ein Programm installiert werden muß, das wir bislang nicht kannten, ob jemand Probleme bei der Bedienung eines Programms hat, oder ob Hilfe bei der Fehlersuche angesagt ist. Die Computerkenntnisse unsere Benutzer sind recht unterschiedlich, aber fast alle können[5] programmieren, und sie tun das auch bei ihrer täglichen Arbeit. Je nach Fertigkeiten werden dann schon einmal Fehler in die Programme eingebaut, die ohne fremde Hilfe nicht wieder zu entfernen sind. Ja, und dann gibt es auch noch Leute, die Hilfe benötigen, ohne es zu wissen; wenn jemand vier Rechner für ein parallel arbeitendes Programm anfordert, dann aber nur einen benutzt[6], dann zahlt sich die Systemüberwachung aus.

Dokumentieren

Zu guter Letzt möchte ich noch einen Punkt erwähnen, der zwar nicht direkt zur Arbeit eines Systemadministrators gehört, der aber trotzdem ungeheuer wichtig ist[7]: was immer man tut, muß dokumentiert werden. Nichts ist ärgerlicher, als Stunden oder gar Tage mit der Fehlersuche zu verbringen, nur um ein paar Wochen oder Monate später an anderer Stelle vor dem gleichen Problem zu stehen -- und genauso lang an der Lösung zu arbeiten. Davon, daß möglicherweise auch andere Leute mit einem komplexen System umgehen müssen, will ich gar nicht anfangen.

Diese Aufgabe habe ich zusammen mit einigen anderen durch das Werkzeug Bugzilla in Angriff genommen. Neben der Dokumentation dient Bugzilla nämlich noch als To-Do-Liste, hilft bei der Kommunikation mit den anderen Admins und den Benutzern und kann die nach einem vollen Arbeitstag manchmal etwas beunruhigende Frage Was habe ich heute eigentlich getan? beantworten.

  1. siehe nächster Abschnitt
  2. bei Rechnern und gekaufter Software macht das dann normalerweise der Lieferant
  3. und wenn gar nichts hilft, gibt es immer noch strace
  4. will sagen: wenn man nur die Computer und ihre Programme verwalten will
  5. mehr oder weniger
  6. und zu 400% belastet
  7. wie ich auf die harte Tour gelernt habe
4 Kommentare

von kirjoittaessani


Wer gelegentlich auf der Kommandozeile arbeitet, kennt sicher den einen oder anderen redirector, um Ein- oder Ausgaben von Befehlen in Dateien umzuleiten:

ls > /tmp/liste
grep blub < /tmp/list
grep -r hallo . 2> /tmp/fehler
ls /tmp >> /tmp/liste

Heute hatte ich das Vergnügen, einen neuen zu benutzen. Grund war ein Programm, das zunächst prüft, ob der File-Descriptor 3 geöffnet ist. In einer normalen Shell ist das nicht der Fall, wenn das besagte Programm als Plugin läuft, aber schon. Zur Fehlersuche wollte ich es unter der Shell starten, aber den Plugin-Modus simulieren. Die Lösung:

exec 3<> /tmp/t

legt die Datei /tmp/t an und öffnet sie mit dem gewünschten Descriptor. Danach starte ich einfach das zu untersuchende Programm.

[via The Linux Documentation Project]

Kein Kommentar

von kirjoittaessani