Dirks Logbuch (Artikel mit Tag computer)

Backup-Konzept

nospam@example.com (Dirk Deimeke) — Tue, 29 Mar 2022 05:19:00 +0200

Vor ein paar Wochen habe ich beschrieben, wie man sein Backup mit Borgbackup durchführen kann.

Heute soll es einmal darum gehen, sich ein generelles Konzept zu überlegen. Wenn man sich erst die Gedanken macht, wenn Datenverlust droht oder bereits Daten verloren gegangen sind, dann ist es zu spät.

Im Artikel geht es mir vor allem um private Daten.

Um die Klassifizierung der Daten kommt man leider nicht herum. Damit lässt sich feststellen, welche Daten am wichtigsten sind, welche Daten sich wie häufig ändern und wie viel Datenverlust man verkraften kann. Natürlich sollte man sich auch über Restorezeiten Gedanken machen - die gewünschte Restorezeit beeinflusst auch die Art des Backups (Vollbackup, differentielles oder inkrementelles Backup) und selbstverständlich auch die Wahl des Backuptools.

Natürlich kann man sagen, dass man jede Minute ein Backup aller Daten anfertigt, um in jedem Fall auf einen alten Stand zurückzukommen. Dazu darf das Backup nicht länger als eine Minute dauern und man muss ausreichend Speicherplatz vorsehen (und bezahlen).

Die folgenden Daten würde ich bei einer Klassifizierung privater Daten berücksichtigen:
(Ergänzungen sind herzlich willkommen)

Das Betriebssystem
Die installierten Programme
Konfigurationen
Dokumente (Textverarbeitung, Tabellenkalkulation, ...)
Quelltexte
Notizen
Skizzen
E-Mails
Chat-Nachrichten
Eingescannte Dokumente
Fotos

Für jede der Kategorien sollte man sich überlegen, ob man mit einem Verlust der Daten leben könnte, wie lange die Wiederherstellung der Daten dauern darf, welcher Aufwand getrieben werden muss, um die Daten wiederzubekommen und wie aktuell die Backups sein müssen.

Ein Beispiel: Fotos lassen sich ohne Backup nicht wiederherstellen, eingescannte Dokumente schon (wenn man das Original noch besitzt), allerdings kostet das vermutlich mehr Zeit als ein Restore der Daten. Dafür belegen Fotos und Scans viel Platz auf dem Backupmedium.

Ein weiteres Beispiel: Wenn ich bei einem erstellten Dokument nur auf ein tägliches Backup zugreifen kann, verliere ich einen Tag, den ich an dem Dokument gearbeitet habe. Je nach Komplexität und Genialität der Dokumente kann das schon sehr viel sein.

Was bedeuten eigentlich Vollbackup, differentielles Backup und inkrementelles Backup?

Ein Vollbackup beinhaltet alle Daten, die gesichert werden sollen und dauert je nach Volumen relativ lange.

Ein differentielles Backup sichert immer die Differenz zum letzten Vollbackup, man braucht also für die Rücksicherung das letzte Vollbackup und das aktuellste differentielle Backup. Je weiter (zeitlich) man sich vom letzten Vollbackup entfernt, desto grösser werden die differentiellen Backups.

Ein inkrementelles Backup sichert immer die Unterschiede zum letzten Backup, das entweder ein Vollbackup oder ein inkrementelles Backup sein kann. Für eine Rücksicherung benötigt man das letzte Vollbackup und alle seitdem angefallenen inkrementellen Backups. Inkrementelle Backups sind in der Regel relativ klein - je nach Häufigkeit der Inkremente - benötigen aber vergleichsweise lange für den Restore.

Die 3-2-1-Regel für Backups:

Wenigstens drei Kopien (Backups) der Daten verwenden.
Wenigstens zwei verschiedene Speichermedien einsetzen.
Wenigstens eine Kopie ausser Haus aufbewahren.

Den letzten Punkt möchte ich besonders herausstreichen. Das Backup sollte in jedem Fall auch nach einem Feuer bei Euch zu Hause und zugreifbar sein. Mit Backups schützen wir uns vor Katastrophen. Feuer ist nur eine davon.

Automatisierung:

Bitte vertraut nicht darauf, dass Ihr immer daran denkt, Euer Backup zu machen. Backups müssen automatisiert ablaufen, damit der "Faktor Mensch" ausgeschaltet werden kann.

Rücksicherung testen:

Es gibt kaum Dinge, die weniger wert sind als ein Backup, auf das man vertraut und auf das nicht mehr zugreifen kann, daher sind Restoretests elementar wichtig.

Bei mir:

Wie bereits an anderer Stelle geschrieben, mache ich meine Backups mit Borgbackup. Borgbackup macht eine inkrementelle Sicherung ("incremental forever") linkt aber bereits gesicherte Daten in das inkrementelle Backup ein, sodass ich mit jedem Backup einen Zugriff auf alle Daten (Fullbackup) habe.

Das Backup wird bei jedem Runterfahren meines Rechners ("poweroff") ausgeführt.

Die Backups landen auf einer internen zweiten Festplatte, auf dem NAS-Share und via SSH auch auf einer Storagebox bei Hetzner.

Der Schwachpunkt, den ich habe, ist, dass alles mit dem gleichen Tool gesichert wird. Eine der drei Sicherungen werde ich in der nächsten Zeit auf Restic umziehen. Da verliere ich dann zwar die Historie, hätte aber dennoch ein besseres Gefühl.

Logseq

nospam@example.com (Dirk Deimeke) — Tue, 01 Mar 2022 05:12:00 +0100

Im Zuge dessen, dass mein altes Dokumentationssystem mittels Wikis schon stark in die Jahre gekommen ist und ehrlicherweise nie so richtig gut funktioniert hat, habe ich mich von der TILpod-Community bei Matrix einmal inspirieren lassen.

Dort wurde Obsidian empfohlen, was mir aufgrund der Tatsache, dass es Closed-Source-Software ist, nicht so wirklich gefallen hat. In diesem Artikel bei GNULinux.ch wurde ich dann auf Logseq aufmerksam, was ich mir näher angeschaut habe.

Für eine sprachliche Auseinandersetzung mit dem Thema im Rahmen eines Podcasts empfehle ich Euch die März-Episode des TILpod.

Dokumentationsmedien, dazu zähle ich auch Wikis, haben meist ein Problem. Sie erlauben es selten, Informationen einfach so zu erfassen, ohne sich grosse Gedanken über die Struktur und die Findbarkeit machen zu müssen.

Notizen bestehen, zumindest bei mir, aus Stichpunkten, die nicht weiter ausformuliert sind. Ich mache sie am liebsten handschriftlich, weil mir das alle Freiheiten bietet und auch erlaubt, etwas "ins Unreine" zu skizzieren. Tools schränken zumeist die Möglichkeiten für Notizen ein, da sie an Programmvorgaben und Formen gebunden sind. Mobil auf dem Handy benutze ich Nextcloud Notes für Notizen, dafür gibt es eine sehr gute Android-App. Ich spiele mit dem Gedanken, eine Diktierfunktion oder sogar ein Diktiergerät zu verwenden.

Der Nachteil dieses Verfahrens ist, dass ich die Notizen noch einmal durchgehen muss, um sie in eine lesbare und verstehbare Form zu bringen.

Der Vorteil ist, dass ich die Notizen noch einmal durchgehe und die Inhalte besser behalten kann und dass mir durch die erneute Beschäftigung vielleicht noch weitere Inhalte und Themen einfallen.

Logseq versucht jetzt genau diese Lücke zwischen Notizen und Dokumentation zu schliessen. Vorab ein Disclaimer: Ich nutze das Tool erst seit rund einem Monat, bin noch ziemlicher Anfänger und nutze nur einen Bruchteil der Möglichkeiten.

Logseq ist noch im Beta-Modus und es gibt Anwendungen für Linux, Mac OS, Windows und Android. Es gibt auch noch eine Webanwendung, die die Daten in einem GitHub-Repository speichert, die soll aber eingestellt werden, sobald die Android-Anwendung fertig ist. Ach ja, mit einer weiteren Webanwendung aka "Live Demo", mit der kann man ohne weitere Installationen auch mit den lokalen Daten arbeiten. Obsidian und Logseq können auf derselben Verzeichnis-Hierarchie parallel zusammenarbeiten.

Ich habe Logseq via Flatpak auf zwei Linux-Maschinen installiert und zusätzlich auf einem Windows-System. Die Daten von Logseq können via Nextcloud synchronisiert werden, was in meinem Fall ohne weitere Zwischenfälle geklappt hat.

Basis von Logseq ist das Journal, in Form von "was ich heute getan habe". Man kann auch anders damit umgehen, aber das ist der einfachste Weg.

Innerhalb des Journals gibt es für jeden Tag eine Seite (gespeichert im Markdown-Format, Emacs Org-Mode wäre auch möglich), auf der man in Form einer Aufzählung alles notiert, was von Interesse ist. Dabei kann man Tags verwenden. Jeder Aufzählungspunkt und eventuelle weitere Unterpunkte gelten als Blöcke.

Klickt man auf einen Tag, bekommt man alle Blöcke angezeigt, die diesen Tag enthalten. Wenn man auf der "Tag-Seite" weitere Informationen erfasst, so wird auch diese im Markdown-Format abgelegt, ansonsten existiert die Seite nur virtuell.

Beispiel:

Ich beginne einen Block mit dem Namen eines meiner Rechner in doppelten eckigen Klammern (ich könnte auch das Hash-Zeichen "#" verwenden, das führt zum gleichen Resultat). Innerhalb des Blocks schreibe ich auf, was ich auf dem Rechner getan habe, beispielsweise "Logseq installiert". Logseq bekommt auch einen Tag.

Wenn ich auf den Rechnernamen klicke, bekomme ich alles gezeigt, was ich auf dem Rechner gemacht habe. Wenn ich auf Logseq klicke, bekomme ich alle Informationen und alle Installationen mit Bezug auf Logseq angezeigt.

Auf der Seite des Rechners erfasse ich beispielsweise die Hardwareausstattung.

Auf diese Art entsteht über die Zeit eine stark vernetzte Dokumentation. Man kann Bilder einfügen, Videos einbetten und sogar PDFs kommentieren. Mit der Speicherung der Daten kommt man nicht in Berührung, man muss nur beim ersten Start einen Speicherort in Form eines Verzeichnisses angeben.

Ich gewöhne mich gerade daran und bin ziemlich begeistert, dass die Software so gar nicht im Weg steht.

Wenn Ihr sie auch testen wollte, empfehle ich Euch den Logseq Intro Course mit acht kurzen Videos.

Ein Wermutstropfen ist für mich, dass sich die Entwickler "Privacy First" auf die Fahne geschrieben haben, aber per Default Telemetriedaten versenden. Das könnte man auch beim ersten Start abfragen.

Die Software ist FLOSS und soll es auch bleiben. Es ist eine Pro-Version geplant, die eine Synchronisationslösung eingebaut hat, ab dann lohnt sich vielleicht auch die Android-Anwendung.

Ich benutze Logseq für

Engineering Journal
Sammlung von Links, Bildern und Videos - könnte meine Bookmarks mit Shaarli ablösen.
Installationen und Konfigurationen auf meinen Clients und Servern
Planung von Vorträgen und Workshops
Wissensspeicher

Was ich noch ganz spannend finde, ist die eingebaute Aufgabenverwaltung, die ich mir auch noch näher anschauen möchte. Spannend wäre es, ob ich damit Todoist ablösen könnte und ich alle Daten unter eigener Kontrolle hätte.

Bessere Shell-Skripte

nospam@example.com (Dirk Deimeke) — Tue, 30 Nov 2021 05:27:00 +0100

Shell-Skripte sind gegenüber anderen Programmiersprachen natürlich nicht das "Non-plus-ultra", aber sie sind für Ablaufsteuerungen - dafür sind sie gemacht - eine gute Wahl. Für alles, was grösser ist, empfehle ich eine "richtige Programmiersprache". Ich bin als Systemadministrator ein grosser Fan von Python und - schon länger nicht mehr genutzt - Perl, aber auch Sprachen wie Raku, Ruby oder irgendetwas mit Compiler sind natürlich gute Alternativen.

Ich beziehe mich im Folgenden auf die Bash, weil das die Shell ist, die ich täglich auf verschiedenen Systemen und Architekturen benutze.

Tipp 1:

Schreibt in den Shebang #! zu Beginn des Skriptes genau die Skriptsprache mit der Ihr auch getestet habt und nicht - weil alle das machen - /bin/sh. Auf Debian basierten Systemen ist /bin/sh ein Link auf dash, bei Alpine ist es ein Link auf Busybox, auf Red Hat basierten Systemen ein Link auf bash.

An dieser Stelle möchte ich gerne noch auf diesen alten Artikel hinweisen.

Tipp 2:

Skripte laufen auch im Falle eines Fehlers weiter. Ich halte das für ein blödes Verhalten, was sehr häufig zu Fehlern führt. Glücklicherweise kann man das Verhalten abstellen.

Entweder man ruft die Shell mit -e auf, setzt den Shebang entsprechend oder schreibt set -e an den Anfang des Skriptes oder vor die Zeilen für die das Setting gelten soll. Mit set +e kann man wieder das alte Verhalten herstellen.

Meine Empfehlung ist, die Langform set -o errexit zu verwenden, das ist deutlich lesbarer. (Altes Verhalten kann man mit set +o errexit wieder herstellen).

Shellzeilen gelten als fehlerhaft, wenn der exit-Code des letzten Kommandos der Zeile ungleich 0 (null) ist. Das bedeutet unter anderem, dass man den Exitcode einer einzelnen Zeile durch Hinzufügen von || true auf "nicht fehlerhaft" ändern kann.

Tipp 3:

Wie im letzten Tipp beschrieben, ist das letzte ausgeführte Kommando einer Zeile ausschlaggebend dafür, ob eine Zeile mit oder ohne Fehlercode beendet wird.

Der Eintrag set -o pipefail sorgt dafür, dass eine Zeile als fehlerhaft "gesehen" wird, wenn auch nur ein Kommando der über Pipes vernetzten Kommandos einer Zeile fehlschlägt.

Tipp 4:

Nicht gesetzte oder "leere" Variablen sind häufig ein Problem.

Um eine nicht gesetzte Variable mit einem Fehler zu quittieren, kann man das Kommando set -o nounset oder set -u verwenden.

Tipp 5:

Es ist generell eine gute Idee, alle Variablen mit doppelten Anführungszeichen zu umgeben, ganz besonders dann, wenn es um Dateien geht. Auch, wenn man selber keine Dateien mit Leerzeichen (oder anderen "Internal Field Separators" (IFS)) erstellt, heisst es nicht, dass man nicht auf solche treffen kann.

Nachtrag:

Christoph hat in diesem Kommentar zur recht darauf hingewiesen, dass es besser ist /usr/bin/env bash zu verwenden, das benutzt die erste Bash, die der Benutzer im Pfad hat und funktioniert auch auf Systemen, auf denen die Bash in einem anderem Pfad liegt als /bin/bash.

Zusammenfassung:

Meine Erfahrung ist, dass man mit den fünf Tipps rund 80% aller Probleme mit Shellskripten umschifft bzw. Skripte mit Fehlern rechtzeitig abbricht.

#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail

# Und Variablen immer mit doppelten Anführungszeichen verwenden.

echo "${Variable}"

Es gibt noch viele weitere Tipps, aber das sind meiner Ansicht nach die wichtigsten.

Threema App wird quelloffen

nospam@example.com (Dirk Deimeke) — Mon, 21 Dec 2020 13:43:00 +0100

Kaum kommt die Meldung, dass der Quelltext des Threema-Clients offen liegt, kommen die Bedenkenträger, dass das kein Grund zur Freude wäre, so lange der Quelltext des Servers noch nicht offen ist.

Zwei Anmerkungen dazu und auch gleichzeitig eine Einladung zur Diskussion.

Haben wir verlernt, uns über Teilerfolge zu freuen? Muss es immer 100% sein? Kein Wunder, dass wir es uns immer schlechter gehen lassen, wir tragen selber die Schuld daran.
Auch, wenn der Quelltext der Serverkomponente offen liegt, gibt es keine Garantie dafür, dass der Quelltext die Basis für den Server ist, der auf Seiten des Betreibers läuft. Ich setze als Blogengine Serendipity ein. Ihr müsst mir glauben, dass das so ist und keine von mir abgewandelte Variante der Software.

Wenn man etwas nicht selber macht, muss man darauf vertrauen, dass es sich so verhält wie behauptet.

Nebenbei: Auch die App müsste man selber bauen, um sicher zu sein, dass die App auf dem Handy aus dem offen gelegten Quelltext gebaut wurde.

Neue Hardware

nospam@example.com (Dirk Deimeke) — Sun, 01 Nov 2020 15:01:00 +0100

Das Thema Homeoffice wird mich vermutlich länger nicht loslassen.

Mein einziges Arbeitsgerät ist derzeit ein mittlerweile 4,5 Jahre altes Notebook in einer Dockingstation. Dass ich es mobil verwendet habe, ist vermutlich länger als ein Jahr her. Aufgrund von Corona werde ich es höchstwahrscheinlich auch in nächster Zeit nicht mobil einsetzen. Ein neues Notebook wäre somit eher sinnlos.

Den Platz auf dem Schreibtisch könnte ich aber gut gebrauchen. Mein Notebook wird auch noch länger gut mobil oder bei Präsentationen funktionieren, so dass ich zum ersten Mal seit längerer Zeit wieder über ein immobiles Standsystem nachdenke. Einmal mehr merke ich, dass ich von Hardware wirklich keine Ahnung habe. Die Faustregel "nimm etwas mit Intel-Prozessor und -Grafikkarte, dann funktioniert es auch unter Linux" gilt weiterhin.

Also, liebe Mitleser, was würdet Ihr kaufen?

Anforderungen:

Ich mache viel mit virtuellen Maschinen und mit Containern, daher sollten es schon 64 GB RAM sein.
Einen aktuellen Prozessor sollte das Teil auch haben, da der Trümmer hoffentlich lange Jahre Dienst tun wird.
Eine schnelle SSD / NVMe mit 1 TB ist Pflicht, wenn noch Platz für eine 4 TB SATA-Platte vorhanden ist, dann ist das umso besser.
Netzwerk (kabelgebunden) plus WLAN als Fallback sind nötig.
Betrieben wird das Gerät an einem Monitor mit 2560x1440 Pixeln Auflösung, daher ist ein Display Port Anschluss vermutlich eine gute Idee.
Wichtig wäre noch, dass der Trümmer möglichst leise ist.
Aufgrund der Notwendigkeit, Citrix Workplace zu verwenden, kommt Ubuntu zum Einsatz - Fedora hätte ich lieber.

In meiner engeren Auswahl sind die folgenden beiden Konfigurationen auf Basis von Tuxedo Core One v10 oder Tuxedo Cube v8 ich bin aber offen für weitere Vorschläge.

SSD tauschen ...

nospam@example.com (Dirk Deimeke) — Tue, 18 Jul 2017 15:06:59 +0200

Ich habe nicht bereut, mich bei meinem aktuellen Notebook im Februar letzten Jahres für ein Dell Latitude E7450 entschieden zu haben. Am Sonntag habe ich innerhalb von ein paar Minuten die neue SSD eingebaut und Fedora installiert. Arbeitsbereit war ich in deutlich unter zwei Stunden ... (selbst Windows 10 wäre da noch dabei gewesen, die Updates zu installieren und Anwendungen wären auch noch nicht drauf).

Wannacry?

nospam@example.com (Dirk Deimeke) — Wed, 17 May 2017 05:20:00 +0200

Leider muss ich jetzt doch etwas längeres dazu schreiben, weil mich die polemisierenden Nachrichten nerven.

Kurz zusammengefasst:

Ich habe kein Mitleid mit Firmen, die von Wannacry betroffen sind. Mein Mitleid geht an die Menschen, die nichts damit zu tun hattem wie beispielsweise Patienten von Krankenhäusern.

Wannacry hat mit Admins zu tun, die ihre Hausaufgaben nicht gemacht haben; mit Entscheidern, die kein Geld für ein Update bewilligen und mit Anwendern, die auf alles klicken, was klickbar ist und Warnhinweise ignorieren. Es hat nichts mit Windows vs. Linux zu tun. Ein ungepatchtes und nicht supportetes Linuxsystem ist auch ein Sicherheitsproblem.

Längere Version:

Soweit ich verstehe und aus diesem Link mitnehme, läuft die initiale Verbreitung folgendermassen:

Ein Benutzer bekommt per Mail eine Passwort geschützte ZIP-Datei in der ein Dokument ist. Wenn das Dokument geöffnet wird, wird eine unsignierte ausführbare Datei nachgeladen und diese ausführbare Datei enthält alles, was der Wurm braucht, Code zur Infizierung, Vervielfältigung und Verseuchung der Zielsysteme, wobei eine Schwachstelle in SMB ausgenutzt wird. Durch den User erreichbare Dateien (insbesondere Netzwerkshares) werden verschlüsselt.

Der Benutzer muss mehrfach bestätigen, dass er Dinge "wirklich" tun will (Ungeschützte Datei öffnen, Makros ausführen, Datei aus unsicherer Quelle ausführen).

Erste Möglichkeit, es gar nicht erst zu solchem einem Eklat kommen zu lassen, wäre beispielsweise die Schulung der Nutzer.

Für noch im Support befindliche Betriebssysteme, also nicht Windows XP, hat Microsoft bereits Mitte März dieses Jahres einen Patch veröffentlicht.

Zweite Möglichkeit, kritische Patches kurz nach Erscheinen einspielen.

Das hilft nicht, wenn man nur Windows XP hat und die Entscheider kein Geld für neue Lizenzen ausgeben wollen. Hier ist die dreckige Wahrheit: Der Unterhalt einer IT-Infrastruktur kostet Geld für Hardware, Softwarelizenzen und Support-Personal. Es liegen vier aktuell supportete Versionen zwischen XP und heute (Windows Vista, Windows 7, Windows 8 und Windows 10). Selbst, wenn man sich entscheiden würde, nur jede zweite oder dritte Inkarnation von Windows einzusetzen, hätte es mit dem rechtzeitig veröffentlichten Patch keine Probleme gegeben.

Es geht nicht um "XP ist Mist", es geht in diesem Fall um abgelaufenen Herstellersupport.

Von einem Oldtimer würde man auch nicht erwarten, dass er einen Airbag hat ...

Um in der Analogie zu bleiben: Windows XP hat 2001 das Licht der Welt erblickt, das ist vor 16 Jahren. Wie viele Geschäftsführer fahren 16 Jahre alte Autos? Ich kenne keinen. Geld für ein neues Auto wäre also da, aber nicht für Softwarelizenzen. Das passt nicht.

Dazu gibt es noch mehrere Möglichkeiten, technisch dem Problem beizukommen, gekapseltes E-Mail-System, Paketfilter, ... aber die sind meiner Meinung nach nicht mit vertretbarem Aufwand handhabbar.

Fazit:

Es führt nichts, gar nichts daran vorbei Anwender zu schulen. Selbst, wenn das zu Grunde liegende System von Windows auf irgendetwas anderes wechselt, hilft die Schulung, dass die gleichen Fehler nicht auf den neuen Systemen gemacht werden.

Ebenfalls ist es nötig, zeitnah kritische Patches einzuspielen. Selbst Unternehmen mit sehr konservativen Patchzyklen (ein Mal pro Jahr) kennen "Emergency-Patching".

Egal, welches System eingesetzt wird, es muss durch den Hersteller oder die Community unterstützt sein (ich kenne reichlich Menschen, die ein lange nicht mehr gewartetes Debian einsetzen).

Wem die Supportzyklen zu kurz sind, muss auf etwas mit längeren Supportzyklen wechseln.
Wer lizenzpflichtige Betriebssysteme (oder auch andere Software) einsetzt, muss diesen Kostenpunkt dringend in seinem Budget einplanen.

GNU time ...

nospam@example.com (Dirk Deimeke) — Tue, 02 May 2017 16:44:00 +0200

In den "Core Utilities" der meisten Linuxdistributionen findet sich das Tool GNU time (ja, die Homepage ist ein bisschen, nun, ..., nichtssagend).

Das time-Kommando als eingebautes Kommando der Bash (oder anderer Shells) kennen viele, auch die charakteristische Ausgabe:

$ time bash
$ exit

real 0m2.608s
user 0m0.137s
sys 0m0.326s

Ein wenig gesprächiger ist GNU time:

$ /usr/bin/time bash
$ exit
0.18user 0.37system 0:04.17elapsed 13%CPU (0avgtext+0avgdata 3736maxresident)k
0inputs+80outputs (0major+96587minor)pagefaults 0swaps

Im "verbose-Modus" kann man dann aber schon richtig ordentlich Informationen abgreifen:

$ /usr/bin/time -v bash
$ exit
Command being timed: "bash"
User time (seconds): 0.11
System time (seconds): 0.30
Percent of CPU this job got: 12%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.36
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 3732
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 96806
Voluntary context switches: 713
Involuntary context switches: 155
Swaps: 0
File system inputs: 0
File system outputs: 80
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

Die manpage gibt noch weitere Optionen an.

Pipe Viewer ...

nospam@example.com (Dirk Deimeke) — Mon, 01 May 2017 17:21:00 +0200

In den letzten Jahren haben sich reichlich viele tar.bz2-Archive mit zum Teil über 100 Gigabytes bei mir angesammelt. Die mussten einmal dringend aufgeräumt werden.

Beim Aufräumen war mir Pipe Viewer eine grosse Hilfe. Na, ja, Hilfe ist vielleicht übertrieben, aber "subjektive Zeitverkürzung" hat auch ihren Wert.

Pipe Viewer macht genau das, was der Name vermuten lässt, es zeigt - unter anderem - den Fortschritt von Pipes an.

$ pv --progress --eta downloads.tar.bz2 | tar xjf -
[> ] 2% ETA 0:04:02

Der umgekehrte Weg ist komplexer, weil die Grösse der Daten an das Kommando übergeben werden muss.

$ tar cf - Downloads \
| pv --progress --eta --size $(du -bs Downloads | awk '{print $1}') \
| bzip2 -9 > downloads.tar.bz2
[==============> ] 31% ETA 0:08:42

Weitere sehr gute Beispiele finden sich auf der verlinkten Homepage.

FLOSS-Perlen ...

nospam@example.com (Dirk Deimeke) — Tue, 16 Feb 2016 05:53:00 +0100

Ich bin immer auf der Suche nach FLOSS-Perlen.

Wenn Ihr also FLOSS-Perlen findet, wäre ich sehr froh, wenn Ihr Eure Fundstücke in den Kommentaren oder besser noch in eigenen Blog-Artikeln beschreibt und hier verlinkt.

Wichtig! Ich suche nicht nach dem x-ten Artikel, der eine Software beschreibt, die eh schon jeder kennt, es sei denn sie bietet etwas so besonderes, dass sich die Erwähnung lohnt.

Dabei schreibe ich ganz bewusst FLOSS, weil ich die Streitigkeiten zwischen der Free-Software-Definition und der Open-Source-Definition nicht mitmachen möchte.

Grundlegend wollen beide Gruppierungen das gleiche und ich fühle mich eher zur "Open Source" als zur dogmatischeren "Free Software" hingezogen. Ich bin der Meinung, dass der Streit "unserer Bewegung" eher schadet als nützt.

Definition von "Freie Software" nach Wikipedia:

Die Freiheit, das Programm auszuführen, wie man möchte, für jeden Zweck.
Die Freiheit, die Funktionsweise des Programms zu untersuchen und eigenen Bedürfnissen der Datenverarbeitung anzupassen.
Die Freiheit, das Programm weiterzuverbreiten und damit seinen Mitmenschen zu helfen.
Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gemeinschaft davon profitiert.

Definition von "Open Source" nach Wikipedia:

Die Software (das heisst der Quelltext) liegt in einer für den Menschen lesbaren und verständlichen Form vor.
Die Software darf beliebig kopiert, verbreitet und genutzt werden.
Die Software darf verändert und in der veränderten Form weitergegeben werden.

E-Mail, Kontakte und Kalender ...

nospam@example.com (Dirk Deimeke) — Mon, 05 Oct 2015 05:41:00 +0200

Lange Jahre war ich mit Claws-Mail als Mailclient mehr als zufrieden und bin es heute noch. Die Filter- und anderen Konfigurationsmöglichkeiten sind unerreicht. Leider ist er nicht mehr auf der Höhe der Zeit.

Es gibt immer mehr HTML-Mails (die ich auch als HTML sehen möchte) und die meine Anforderungen über Mail hinaus sind gestiegen.

Ich bin auf der Suche nach einem "Personal Information Manager", der die folgenden Aufgaben in einer integrierten Oberfläche bereitstellt und soll unter KDE auf Linux laufen:

Pflicht: E-Mail (klar, oder?)
Pflicht: Anzeige von HTML-Nachrichten ohne Verrenkungen, gerne mit einmaliger (!) Nachfrage pro Kontakt ob Content nachgeladen werden darf.
Pflicht: Sollte nicht in die Knie gehen bei meinem Mailaufkommen (derzeit drei "echte Mailaccounts" via IMAP und zahlreiche Weiterleitungen) mit einigen hunderttausend gespeicherten Nachrichten.
Pflicht: Nutzung verschiedener Identitäten pro Mailaccount.
Pflicht: Filterung von eingehenden Mails, gerne auch mit Frontend für Sieve.
Pflicht: Verwaltung und Einbindung von Kontakten aus den externen Quellen ownCloud und Google Contacts.
Pflicht: Gleiches - ownCloud und Google Calendar - gilt für Kalender, hier kommen aber noch öffentliche ICS-Dateien dazu.
Kür: Speicherung von Antworten im gleichen Ordner wie die Mail, die auf die geantwortet wird.
Kür: Vergabe von Verarbeitungsregeln für Ordner wie beispielsweise "Verschiebe alle Nachrichten, die älter sind als 365 Tage in den Archivordner (der in einem anderen Mailaccount zu finden ist)" oder "Lösche alle Nachrichten aus dem Gesendet-Ordner, die an Mailinglisten gingen".
Kür: Usenet-Client

Die "Kür-Anforderungen" resultieren aus Funktionen, die ich Claws-Mail genutzt habe.

Getestet habe ich die integrierten KDE-Anwendungen KMail, KOrganizer, KAddressbook und KNode, aber die waren für die Anzahl der verwalteten Mails zu langsam und mit intensivem Filtern unbenutzbar. Der Featureset hat ansonsten dem entsprochen, was ich mir vorstelle.

Momentan teste ich Mozilla Thunderbird.

daterem.py vs. daterem.pl ...

nospam@example.com (Dirk Deimeke) — Mon, 17 Aug 2015 05:53:00 +0200

Ich muss bzw. darf mich mit der Programmiersprache Python auseinandersetzen. Was liegt da näher, ein selbstgeschriebenes Perl-Skript nach Python zu migrieren? Nichts. Also habe ich es getan.

Die Ergebnisse lassen sich auf GitHub sehen.

Kritik ist ausdrücklich erwünscht, ich kann davon nur lernen.

Diesen Artikel wollte ich nicht Python vs. Perl nennen, weil beide Programmiersprachen ihre Berechtigung haben und es gibt ja nicht wirklich einen Streit zwischen beiden, nur unterschiedliche Philosophien. Einer von vielen Gründen ist, dass Perl von einem Linguisten - Larry Wall - entwickelt wurde und Python von einem Mathematiker - Guido van Rossum.

So, hier kommen die Dinge, die mir beim Umschreiben aufgefallen sind. Achtung! Ich bin kein Programmierer, sondern eher ein Skripter ...

Die folgenden Punkte kann meiner Ansicht nach Python besser:

Datumshandling mit mitgelieferten Bibliotheken: das Modul time ist doch deutlich komfortabler als das Perl-Pendant Time::local (zum Wert für Monat muss 1 und zum Wert von Jahr muss 1900 addiert werden).
Struktur: Da Bei Python die Einrückungen eine Rolle spielen, kann auf geschweifte Klammern für Codeblöcke verzichtet werden, das gefällt mir richtig gut.
Listen: Der Umgang mit Listen gefällt mir auch besser als bei Perl, aber ich gebe zu, dass das Geschmackssache sein könnte.

Aber auch Perl hat seine Stärken:

Reguläre Ausdrücke, nun, was soll ich schreiben, reguläre Ausrücke gehen direkt und wesentlich unkomplizierter als bei Python, wo sie per Modul nachgerüstet werden müssen. Es hat einen Grund, dass es einen Namen gibt "PRE - Perl Regular Expressions".
Variablenhandling: Ich habe mich daran gewöhnt, dass ich eine Variable sowohl als String wie auch als Zahl verwenden kann, ohne umwandeln zu müssen. Gut, Python ist schwach typisiert, aber wenn der Typ feststeht, muss man konvertieren.
Assoziative Arrays gefallen mir deutlich besser als Dictionaries, das ist wieder einmal Geschmackssache.
Nachgestelles "if" print $a if ($a == $b) ist wirklich hübscher als ein Mehrzeiler.

Es gibt gute Gründe, die zu den Entscheidungen in den Programmiersprachen geführt haben. Ich möchte auch nicht in "besser" oder "schlechter" einteilen, das ist doof. Alles, was man mit der einen Programmiersprache erledigen kann, kann man auch mit der anderen tun.

Hashes in der Bash ...

nospam@example.com (Dirk Deimeke) — Wed, 22 Jul 2015 11:11:41 +0200

Weil ich es gerade für einen Kollegen gebraucht habe.

Ein eher selten genutztes Feature in der Bash sind assoziative Arrays (Hashes). Ab Bash Version 4 geht das ganz ohne Hilfskonstrukte.

#!/bin/bash

declare -A dns=(
[mond]=192.168.0.1
[erde]=192.168.2.3
[saturn]=192.168.7.8
)

echo "Alle Keys: ${!dns[@]}"
echo "Alle Values: ${dns[@]}"
echo

for host in ${!dns[@]}; do
ip=${dns[${host}]}
echo "${host} hat die IP-Adresse ${ip}"
done

Schlüssel und Werte dürfen "natürlich" auch Leerzeichen enthalten. Dann müssen diese allerdings - wie bekannt - in Anführungszeichen stehen.

Ergebnis des Skriptes:

Alle Keys:   erde saturn mond
Alle Values: 192.168.2.3 192.168.7.8 192.168.0.1

erde hat die IP-Adresse 192.168.2.3
saturn hat die IP-Adresse 192.168.7.8
mond hat die IP-Adresse 192.168.0.1

Programmiersprachen Ranglisten ...

nospam@example.com (Dirk Deimeke) — Mon, 06 Jul 2015 05:10:00 +0200

Letzte Woche gingen die aktuelle RedMonk Programmiersprachen Rangliste durch die Blogs. Ich kannte die Rangliste tatsächlich noch nicht und habe vorher immer den Tiobe Index zu Rate gezogen. Im Zuge der Recherche zu diesem Artikel habe ich auch noch den Popularity of Programming Language Index gefunden.

Die Ergebnisse sind sehr interessant, weil sie drei verschiedene Messmethoden anwenden, um die gefragtesten Programmiersprachen zu finden.

Der RedMonk Index erscheint alle zwei Jahre und benutzt GitHub und Stack Overflow, um die Rangliste zu erstellen. Damit wird erhofft, die Benutzung (gemessen in Codezeilen) und die Diskussion (Anzahl der Beiträge) in einen Gesamtwert einfliessen zu lassen. Mir persönlich fehlt die Einschränkung auf einen Zeitraum (GitHub: Alle neuen oder alle aktiven Projekte der letzten zwei Jahre beispielsweise). Die für mich interessanten Sprachen finden sich auf folgenden Plätzen:
3 PHP
4 Python
5 Ruby
11 Perl
13 R

Die Berechnung des Tiobe Index ist ein wenig undurchsichtiger, dafür erscheint er aber auch jeden Monat. Die Macher sprechen von einem Popularitätsindex. Die Rangliste wird auf Basis der Ergebnisse in den Suchmaschinen Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube und Baidu ausgerechnet und soll die Anzahl der erfahrenen Ingenieure, Kurse und Drittanbieter berücksichtigen. Wenn man vor der Wahl einer neuen Programmiersprache steht, kann man sich anschauen, was momentan der Trend ist.
6 Python
8 PHP
12 Perl
13 R
16 Ruby

Der letzte im Bunde PYPLI nutzt einzig Google Trends und berücksichtigt nur die Suchen nach Tutorials der Programmiersprachen.
2 PHP
3 Python
10 R
12 Ruby
15 Perl

Interessant ist, dass die Ergebnisse zwar die gleichen Sprachen enthalten, aber in deutlich unterschiedlichen Reihenfolgen.

RedMonk spiegelt die aktive Entwicklung von Open-Source-Projekten wieder, Tiobe zeigt das, was momentan im Markt aktuell ist und PYPLI was gerade gelernt wird. Spannend.

Auch spannend ist, es, sich die Anzahl der registrierten Projekte auf Ohloh anzeigen und nach Sprache auswerten zu lassen.

Globales gitignore ...

nospam@example.com (Dirk Deimeke) — Mon, 18 May 2015 05:33:00 +0200

Wenn man Dateien aus der Versionskontrolle mit git ausschliessen möchte, kann man im Repository eine Datei .gitignore anlegen. Das ist sinnvoll, wenn es Dateien gibt, die in nur einem Repository ausgeschlossen werden sollen.

Anders ist es, wenn man Backupdateien des Editors ausschliessen möchte. Da in der Regel mehrere Menschen an einem Projekt arbeiten und vielleicht sogar jeder einen anderen Editor benutzt, ist es sinnvoller, dass jeder die Dateien ausschliesst, die seinem Editor entsprechen.

Dazu kann mit dem folgenden Kommando die globale Variable core.excludesfile gesetzt werden, die einen Dateinamen beinhaltet, in der die globalen Ausschlusskriterien zu finden sind.

git config --global core.excludesfile ~/.gitignore_global

Bei mir enthält sie derzeit nur:
*~
Das sind die Backupdateien von vim.

Performanceuntersuchungen ...

nospam@example.com (Dirk Deimeke) — Thu, 23 Apr 2015 05:41:00 +0200

Aus aktuellem Anlass muss ich noch einmal auf Bandbreite und Latenz herumreiten und vielleicht noch hinzufügen, dass auch die Anzahl der Anfragen durchaus eine Rolle bei Performance-Betrachtungen spielt.

Wir hatten hier auf einem System massive Performance-Probleme und ich habe relativ schnell herausgefunden, dass ein bestimmter User und von diesem ein bestimmter Prozess für einen grossen Teil der Festplattenlast verantwortlich ist.

Der Applikationsbetreuer war der Meinung, dass das nicht sein könne, da der Teil der Applikation kaum bzw. nur sehr wenig schreibt. Das stimmt, er hat wirklich nicht viel geschrieben, aber dafür wenige Bytes und diese sehr häufig. Das hat die IO-Queue gefüllt und weitere Zugriffe blockiert.

Einige Zeit später hat der Betreuer einfach mal den Prozess beendet und siehe da, die Performance der übrigen Komponenten war sehr hoch.

Lehre, die man daraus ziehen sollte: Glaubt keinem Applikationsbetreuer!

Nein, im Ernst: Es ist wichtig, dass man genau weiss, was eine Applikation tut und noch wichtiger ist es, Performance nicht alleine am Durchsatz fest zu machen. Latenz und Anzahl der Requests spielen ebenfalls eine Rolle.

Cloudprovider ...

nospam@example.com (Dirk Deimeke) — Tue, 21 Apr 2015 05:26:00 +0200

Nach meinen wirklich sehr guten Erfahrungen mit DigitalOcean, interessiert mich, welche bezahlbaren Cloudprovider Ihr kennt und womit Ihr Erfahrung habt. Mich interessiert vor allem IaaS (Infrastructure as a service).

Für die einzelnen Begrifflichkeiten verweise ich auf diesen Artikel hier oder den Cloud-Computing-Artikel in der Wikipedia.

• Amazon EC2
• DigitalOcean
• Google Compute
• JiffyBox (in Deutschland)
• Linode
• Microsoft Azure
• Rackspace
• teutoStack (in Deutschland)

Tiny Tiny RSS update daemon und systemd ...

nospam@example.com (Dirk Deimeke) — Thu, 09 Apr 2015 05:10:00 +0200

Um den update daemon von Tiny Tiny RSS unter systemd (CentOS 7) auch bei einem Serverneustart direkt verfügbar zu haben, habe ich das unten stehende Unitfile geschrieben, vielleicht hilft es auch Euch.

Man kann von systemd halten, was man möchte, ich finde es aber deutlich eleganter als System V Initskripte.

[Unit]

Description=Tiny Tiny RSS update daemon

After=network.target mariadb.service

Requires=mariadb.service



[Service]

User=apache

Group=apache

WorkingDirectory=/â var/â www/â html/â ttr

Type=simple

StandardOutput=null

StandardError=syslog

ExecStart=/â usr/â bin/â php ./â update_daemon2.php

PrivateTmp=true

InaccessibleDirectories=/â home /â root /â boot /â opt /â mnt /â media

ReadOnlyDirectories=/â etc /â usr



[Install]

WantedBy=multi-â user.target

Einfach nach /lib/systemd/system/ttrss-update.service kopieren und mittels systemctl daemon-reload einlesen (den Befehl muss man auch ausführen, wenn man das Skript manuell ändert).

Testen mit

systemctl start ttrss-update
systemctl status ttrss-update

und, wenn alles erfolgreich war mit dem folgenden Befehl aktivieren:

systemctl enable ttrss-update

Git swapped beim Packen ...

nospam@example.com (Dirk Deimeke) — Wed, 01 Apr 2015 05:56:00 +0200

Von Zeit zu Zeit lohnt es sich Git-Repositories neu zu packen oder den Müll weg zu bringen (mittels "garbage collection, der Befehl ist git gc).

Auch beim Auschecken oder Klonen von grossen Repositories packt Git neu.

Da ich mit den Standard-Einstellungen regelmässig ware Swap-Orgien erlebt habe, lohnt es sich, die Ressourcen für Git zu begrenzen.

In der Standard-Einstellung benutzt Git pro Core und Hyper-Threading je einen Thread. Da Hyperthreading keinen "echten Prozessor" zur Basis hat, steht aufgrund vieler Kontextwechsel das System nahezu still. Ein System mit zwei Kernen und Hyperthreading wird von Git mit vier Threads konfiguriert und jedem Thread steht im Standard der komplette Arbeitsspeicher zur Verfügung.

Das ist ein bisschen viel. Und die folgenden Konfigurationsoptionen begrenzen das ein wenig.

git config --global pack.threads 2
git config --global pack.windowMemory 1073741824

git config --global pack.depth 250
git config --global pack.window 250

Die genaue Beschreibung der einzelnen Optionen lassen sich auf der git-config-Manpage nachlesen.

Das Repack-Skript auf der oben verlinkten Webseite hat sich damit natürlich auch verändert.

#!/bin/bash

case $(uname) in
"Linux")
renice -n 19 -p $$
ionice -c 2 -n 7 -p $$
;;
"SunOS")
renice -n 19 -p $$
;;
esac

start_directory=$PWD
for i in $(find ${start_directory} -name '.git' -type d); do
du -hs ${i}/..
cd ${i}/..

git gc
git repack -a -d

du -hs ${i}/..
echo
done

Dieses Skript ist Teil meines littlehelpers-Repositories auf GitHub.

Feedly Theme für Tiny Tiny RSS ...

nospam@example.com (Dirk Deimeke) — Thu, 26 Mar 2015 05:10:00 +0100

Einer der grössten Kritikpunkte an Tiny Tiny RSS - neben der Tatsache, dass der Hauptentwickler ein Arctrl-wctrl-ww sozial schwierig ist - ist das Aussehen.

Christian Grube hat mich bei Google+ schon vor Monaten auf dieses wirklich hervorragende Theme für Tiny Tiny RSS hingewiesen, ich kann es nur empfehlen:

Das Feedly-Theme für Tiny Tiny RSS.

Der Screenshot ist aus diesem Forenthread.

Benchmarking ...

nospam@example.com (Dirk Deimeke) — Mon, 19 Jan 2015 05:49:00 +0100

Man kann viel über Tools lernen, wenn man nachvollziehbare Messungen macht.

Für mich hat sich als sinnvoll erwiesen, fünf Mal zu messen. Die beste und die schlechteste Messung wird gelöscht ("Ausreisser") und aus den verbleibenden drei Messungen nehme ich den Mittelwert.

Die Messungen für den Artikel dd vs. fallocate vs. truncate ... habe ich mit diesem Skript gemacht:

#!/bin/bash
set -o errexit

# echo 'sync ; time (dd if=/dev/zero of=10gig.dd count=20971520 ; sync)'
# echo 'sync ; time (dd if=/dev/zero of=10gig.dd bs=1024 count=10485760 ; sync)'
# echo 'sync ; time (dd if=/dev/zero of=10gig.dd bs=10240 count=1048576 ; sync)'
# echo 'sync ; time (dd if=/dev/zero of=10gig.dd bs=20480 count=524288 ; sync)'
# echo 'sync ; time (fallocate -l 10G 10gig.fallocate ; sync)'
echo 'sync ; time (truncate -s 10G 10gig.truncate ; sync)'
for i in $(seq 1 5); do
sync ; time (truncate -s 10G 10gig.truncate ; sync)
rm 10gig.truncate
done

Dabei habe ich das Kommando eingesetzt, was ich gerade getestet habe.

Interessant ist, wie sich die Blocksizes bei dd auf die wirkliche Schreibperformance auswirken ... nämlich minimal. Hier kommen nur die mittleren der fünf Werte, die komplette Liste der Messwerte lässt sich hier sehen.

sync ; time (dd if=/dev/zero of=10gig.dd count=20971520 ; sync)
20971520+0 records in
20971520+0 records out
10737418240 bytes (11 GB) copied, 36.6231 s, 293 MB/s

real 2m2.442s
user 0m2.772s
sys 0m33.771s

#####

sync ; time (dd if=/dev/zero of=10gig.dd bs=1024 count=10485760 ; sync)
10485760+0 records in
10485760+0 records out
10737418240 bytes (11 GB) copied, 20.5773 s, 522 MB/s

real 1m55.923s
user 0m0.974s
sys 0m19.529s

#####

sync ; time (dd if=/dev/zero of=10gig.dd bs=10240 count=1048576 ; sync)
1048576+0 records in
1048576+0 records out
10737418240 bytes (11 GB) copied, 7.79126 s, 1.4 GB/s

real 1m53.523s
user 0m0.123s
sys 0m7.667s

#####

sync ; time (dd if=/dev/zero of=10gig.dd bs=20480 count=524288 ; sync)
524288+0 records in
524288+0 records out
10737418240 bytes (11 GB) copied, 6.87154 s, 1.6 GB/s

real 2m8.122s
user 0m0.068s
sys 0m6.808s

Die Cloud ...

nospam@example.com (Dirk Deimeke) — Wed, 14 Jan 2015 05:33:00 +0100

Hier ist endlich einmal eine gelungene Übersichtsgrafik, was mit den ganzen Abkürzungen im Cloud-Umfeld "eigentlich" gemeint ist. Die Bausteine bedingen einander.

Software as a Service (SaaS) setzt auf Platform as a Service (PaaS) auf, die als Basis Infrastructure as a Service (IaaS) hat bis schliesslich die Hardware als Fundament erreicht ist.
(Die verlinkten Wikipedia-Artikel sind auch lesenswert).

Nils Magnus/inovex GmbH

Die Grafik ist dem lesenswerten Artikel Cloud Computing - The Name of the Game entnommen und die Veröffentlichung erfolgt mit freundlicher Genehmigung von Nils Magnus und Marius Moise (beide inovex GmbH). Vielen Dank!

PHP Fortgeschrittene ...

nospam@example.com (Dirk Deimeke) — Wed, 03 Dec 2014 06:16:00 +0100

In der letzten Woche durfte ich die Schulung PHP Fortgeschrittene im Linuxhotel besuchen. Gehalten wurde die Schulung von Martin "Joey" Schulze.

Das war mein vierter Aufenthalt im Linuxhotel, aber das erste Mal, dass ich dort eine Schulung besucht habe. Und, ich muss sagen, dass die Schulung grossartig war. Danke Joey! (Lasst Euch von seiner Webseite nicht blenden, er hat wirklich etwas drauf).

Erschreckenderweise - als alter Perl-Liebhaber - muss ich gestehen, dass ich auch von den Möglichkeiten von PHP sehr angetan bin. Da kann man mit relativ wenig Aufwand sehr gute objektorientierte Programme schreiben.

Ich habe viel gelernt!

BTW: PHP muss ich lernen, weil ich in der Firma ein in objektorientiertem PHP geschriebenes System übernehme und erweitern soll. Meine Einarbeitung in PHP - also das Basiswissen - habe ich mir mit diesem Buch angeeignet.

Vielleicht ergibt sich darüber auch die Möglichkeit, "die beste Blogsoftware der Welt" in der Programmierung zu unterstützen.

Der Aufenthalt im Linuxhotel war nett und ich habe es sehr genossen, abends meine Eltern besuchen zu können, so häufig kommt das ja leider nicht mehr vor.

Bloonix wird Open-Source-Software ...

nospam@example.com (Dirk Deimeke) — Mon, 13 Oct 2014 08:19:29 +0200

Der Monitoring-Dienst Bloonix von Jonny Schulz wird Open-Source-Software. Über den Dienst habe ich hier im Blog schon einmal berichtet.

Ich freue mich sehr darüber, da ich das für eine ausgereifte Lösung halte, die von Jonny mit viel Liebe gepflegt wird. Ausserdem ist es an der Zeit, dass es eine weitere Alternative zu den derzeitigen Platzhirschen gibt.

Well done!

In dem Zusammenhang: Mein privater Server wird von Bloonix überwacht.

Schöne Schriften ...

nospam@example.com (Dirk Deimeke) — Tue, 15 Jul 2014 05:16:00 +0200

Ein Kollege von mir hat die "Source"-Schriftserien von Adobe ausgegraben und mir gefallen sie so gut, dass ich meinen Desktop angepasst habe, um sie zu benutzen.

Die drei Schriftarten, um die es geht heissen:

Source Code Pro - eine Schriftart, die sich sehr gut als Schriftart für Monospaced-Geschichten eignet, beispielsweise als Default-Schrift in Editoren oder Terminalfenstern.
Source Sans Pro - ist perfekt für Menüs und Übersichten auf dem Desktop (ersetzt bei mir Deja Vu Sans).
Source Serif Pro - passt sehr gut bei Drucksachen.

Dass Adobe selber auch im Rahmen von Open@Adobe Teile ihrer Entwicklung als Open-Source-Software veröffentlichen war mir neu. Eine Übersicht findet sich auf der Projekt-Seite.