Skip to content

Bloonix wird Open-Source-Software ...

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 ...

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.

GFA Basic ...

Ich bin gerade per Zufall auf der Wikipediaseite von GFA Basic gelandet.

Das ist die Programmiersprache, mit der ich auf dem Atari ST gearbeitet habe und die ich aus einigen Gründen echt vermisse.

Der Basic-Dialekt war Pascal-ähnlich, also nichts mit Zeilennummern.

Die "IDE" bestand aus einem Editor, der Syntax-Vervollständigung und automatische Einrückung beherrscht hat und per Tastendruck die Basic-Programme auch ausgeführt hat. Später kam noch ein Compiler dazu.

Gerade diese Art von IDE hatte es in sich und es machte richtig Spass, damit zu programmieren.

Swiss Perl Workshop 2014 ...

Grossartige Einladung zum Swiss Perl Workshop 2014. Ich werde in jedem Fall am Samstag, dem 6. September dabei sein und wenn mein neuer Arbeitgeber es zulässt, dann gerne auch am Freitag, dem 5. September.

Ich war auf dem Workshop im letzten Jahr und kann ihn nur empfehlen.

Open Source ist unsicher ...

Irgendwie war ja klar, dass der erste grosse Fehler in einer Open-Source-Software die Closed-Source-Befürworter hervorholt, die marktschreierisch rufen, dass Open-Source-Software unsicher sei.

Das ist Quatsch!

Open-Source-Software ist nicht sicherer oder unsicherer als Close-Source-Software. Punkt. Open-Source-Software ermöglicht es aber, solche Fehler, wie den, der bei Heartbleed gemacht wurde, zu finden. Und nach Fehlern kann nicht nur von den Herstellern der Software, sondern auch auch von Fremden - auch von potentiellen Angreifern - gesucht werden. Genau das geht bei Closed-Source-Software eben nicht.

Dass eine Software Open Source ist, ist eine notwendige, aber keine hinreichende Bedingung dafür, dass man einer Software Vertrauen schenken darf. Für Freie Software gilt genau das gleiche.

Was nun passieren muss, ist, dass nicht alle darauf vertrauen, dass Open-Source-Software "schon irgendwie" von anderen geprüft wird, sondern es müssen aktive Audits stattfinden. Prinzipiell erwarte ich insbesondere von Firmen, die Open-Source-Software einsetzen, dass sie sich - mit Manpower oder finanziell - an solchen Audits beteiligen. Der gefundene Bug macht klar, dass wir nicht darauf vertrauen sollten, "dass es schon jemand anderes macht".

Mir würde es gut gefallen, wenn sich eine Organisation gründen würde, die Spenden entgegen nimmt und solche Audits durchführt. Eventuell liesse sich auch ein Crowdfunding durchführen.

Ach, ja, den Kritikern, die denken, dass Open-Source-Software nur von Amateuren programmiert wird, sei der Beitrag Kritiker zweifeln an der Zuverlässigkeit vom Deutschlandfunk empfohlen.

Heartbleed ...

Manchmal lohnt es sich, ein konservativer Administrator zu sein. Heartbleed ist die Sicherheitslücke in OpenSSL 1.0.1, die dazu führt, dass Angreifer zufällige Daten aus dem Speicher des Servers lesen können.

Ich habe natürlich brav im Rudelreflex ein neues Zertifikat erstellt und wollte auch den Hostnamen ändern bis ich mal - ausnahmsweise - so schlau war, mir die Versionsnummern genauer anzuschauen.

Der Server läuft mit Debian 6.0.9 oder Squeeze (Oldstable). Und in Squeeze ist die Version 0.9.8 von OpenSSL enthalten, die nicht vom der Sicherheitslücke betroffen ist.

Wer lesen kann ...

Solaris x86 ...

Neulich habe ich festgestellt, dass sich Solaris 10 und Solaris 11 mit einem freien Oracle Account herunterladen lassen. Da mich die beiden Betriebssysteme, insbesondere die x86-Vairante, interessieren (kann man unter Linux virtualisiert laufen lassen), habe ich mal jemanden gefragt, der sich auskennt, welche Literatur empfehlenswert ist.

Wolfgang hat daraufhin die folgende umfangreiche Liste zusammen gestellt.

Danke!

Bemerkung am Rande: Wie auch bei Red Hat oder SUSE üblich, muss man das Produkt kaufen und registrieren, um die Update-Channel eintragen zu können. Zum Ausprobieren reicht es aber.

Präsentationsformen ...

Von Zeit zu Zeit bekomme ich das Vergnügen, einen Vortrag zu halten und jedes Mal aufs Neue stellt sich die Frage nach der richtigen Präsentationsform.

Ich halte nichts von den Präsentationsprogrammen der Office-Programme, egal, ob es Powerpoint, Impress oder irgendetwas anderes "integriertes" ist. Ich mag nicht gebremst werden und ich mag es, ohne Mausbenutzung, nur mit der Tastatur zu schreiben.

Wenn das ganze dann noch Open Source ist und möglichst, in einer einzigen Datei daher kommt, bin ich froh. Zwischenzeitlich habe ich einfache Textdateien benutzt. Das Verfahren ist hier im Blog schon beschrieben worden (meine beiden Workshops zu praktischer Administration habe ich so gehalten: Teil 1 und Teil 2 inklusive Videos).

So konnte es nicht weitergehen, daher habe ich mir die folgenden Tools und Möglichkeiten angeschaut:

Alle Verfahren haben spezifische Vor- und Nachteile.

Derzeit arbeite ich PDF-Dateien, die LaTeX Beamer erzeugt, sie enthalten auch Links und sind in meinem Speakerdeck-Account zu finden.

Weitere Style Guides ...

Via Twitter habe ich das Mutterprojekt der Google Styleguides ("Style guides for Google-originated open-source projects") gefunden.

Da gibt es also nicht nur den Shell Style Guide, den ich hier erwähnt habe. Es hätte mich auch überrascht, wenn es anders wäre.

Shell Style Guide ...

Bei Google gibt es einen Shell Style Guide, den ich wirklich jedem nur ans Herz legen kann.

Die Regeln sind sinnvoll und helfen, dass Skripte auch eine Woche nachdem sie geschrieben wurden noch verstanden werden können. :-)

Einiges ist sicherlich diskussionswürdig und Geschmackssache, ich würde Perl statt Python für längere Skripte nehmen, aber in Summe ist das Dokument prima.

Einführung in Git ...

Bei Google+ wurde ich danach gefragt, ob ich die Kurzeinführung in Git, die ich auf der Arbeit gehalten habe, veröffentlichen könnte. Hier ist sie.

Die Beispiele lohnen sich nur, wenn man sie versucht, nachzuvollziehen.

Viel Spass.

Das PDF (rund 100 kB) kann man hier herunterladen: einfuehrung-git.pdf

Lizenz ist CC-BY, das liefere ich auch noch im PDF nach.

Kaputt ...

Das passiert ja "eigentlich" nur "den anderen". Kurz nach Ablauf der Garantie ist mein Hauptrechner zuhause ein halbes Jahr nach Ablauf der Garantie aus dem Tiefschlaf nicht wieder aufgewacht.

Daten habe ich glücklicherweise keine verloren. Trotzdem ärgerlich so etwas.

Ob ich mir noch einmal einen Rechner zusätzlich zum Notebook kaufen werde, weiss ich nicht. Momentan hängt das Notebook mit ordentlicher Tastatur am grossen Monitor und tut, was es soll. Mir fehlt nur eine Dockingstation zum Glück.

Wenn jemand von Euch weiss, wo man einen Portreplikator oder eine Dockingstation für ein Thinkpad X201i herbekommt, bin ich für jeden Tipp dankbar.

Das kann doch nicht so schwer sein ...

Nachdem ich jetzt fünf mal nacheinander den gleichen Fehler gemacht habe, muss ich das schnell weg dokumentieren.

16:06:27 [root@rico:/srv/www/myown-it.com] # git init .

Initialized empty Git repository in /srv/www/myown-it.com/.git/

16:06:59 [root@rico:/srv/www/myown-it.com] # git add .

16:07:08 [root@rico:/srv/www/myown-it.com] # git remote add origin gitosis@rico.yawnrz.net:www-myown-it.com.git

16:07:23 [root@rico:/srv/www/myown-it.com] # git commit -m "init"

[master (root-commit) 16540f0] init

3296 files changed, 340870 insertions(+)

...

16:07:38 [root@rico:/srv/www/myown-it.com] 1 # git push origin master

Counting objects: 3344, done.

Delta compression using up to 4 threads.

Compressing objects: 100% (3263/3263), done.

Writing objects: 100% (3344/3344), 5.47 MiB | 5.52 MiB/s, done.

Total 3344 (delta 794), reused 0 (delta 0)

To gitosis@rico.yawnrz.net:www-myown-it.com.git

* [new branch] master -> master

Ja, das ist Teil meines Backup-Konzeptes.

TeX Live 2013 ...

TeX Live 2013 ist in den vergangenen Tagen erschienen.

TeX Live ist eine der wenigen Softwaresammlungen, die ich manuell installiere und aktualisiere. Das liegt einfach daran, dass ich auf Rechnern mit verschiedenen Betriebssystemen "TeXe" und ich gerne das gleiche LaTeX auf allen Systemen einsetze, um Fehler auf allen Systemen gleich zu halten ;-)

Installation über das Internet für Linux (oder Unix) und Cygwin unter Windows geht über das gleiche Archiv (wieder einmal ein "hoch auf Perl"). Für "normales" Windows gibt es ein separates Paket und sogar eine deutschsprachige Installationsanleitung.

Aktuell hält man die Installation übrigens via:

tlmgr update --self
tlmgr update --all

Git-Repositories packen ...

So ein lebendes Git-Repository ist ziemlicher "Platzverschwender". Mein Hauptrepository, in dem alle meine Dokumente und Scans und Bewerbungen und Skripte und einfach alles liegen, wurde grösser und grösser. Zum Schluss war es bei 16 GB obwohl die "Nutzdaten" nur einen Bruchteil des Repositories ausmachten.

Zeit, einmal einen git repack anzustossen.

Wenn man das unbedarft auf ein grosses Repository loslässt, merkt man sehr schnell, wie langsam der Rechner werden kann, wenn er ins Swapping fällt. Um das einzugrenzen, sollte der Parameter --window-memory gesetzt werden. Meine Beobachtung ist, dass der pro Core gilt. Die Parameter --window und --depth geben die Tiefe und die Anzahl der Objekte für die Delta-Kompression an. -a sorgt dafür, dass alles in gross Packs gepackt wird und -d, dass obsolet gewordene Packs gelöscht werden.

Damit kann man eine Menge erreichen.

16G	ddeimeke.git
Counting objects: 19947, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7173/7173), done.
Writing objects: 100% (19947/19947), done.
Total 19947 (delta 14053), reused 17947 (delta 12645)
6.4G	ddeimeke.git

Allerdings bremst das den Rechner so aus, dass kaum noch arbeiten möglich ist, was man aber mit nice und ionice in den Griff bekommt. Ersteres sorgt dafür, dass die CPU-Benutzung limitiert wird und zweiteres tut gleiches für I/O.

In Summe resultiert das in folgendes kleine Skript.

#!/bin/bash

for i in *.git
do
        du -hsx "${i}"
        cd "${i}"
        nice -n 19 ionice -c 2 -n 7 git repack -a -d --depth=250 --window=250 --window-memory=1g
        cd ..
        du -hsx "${i}"
        echo
done