Dirks Logbuch

Für den Fall, dass das noch jemand anderes benötigt.

Um andere Certificate Authorities (CAs) zu Linux hinzuzufügen, sind nur kleine Schritte nötig. Hier einmal am Beispiel CAcert.

Debian:


CentOS:


ACHTUNG: In jedem Fall sollte vor dem Ausführen von update-ca-certificates bzw. update-ca-trust extract die Fingerprints der Zertifikate überprüft werden.

In den kommenden Tagen werde ich ein paar Artikel zu Perl und insbesondere auch zu Perl 6 veröffentlichen. Um aufkommenden Diskussionen vorzubeugen, muss ich hier einmal betonen, dass Perl aufgrund von schlechtem Marketing und einer viel zu frühen Ankündigung von Perl 6 sehr viel an Boden verloren hat und meiner Meinung nach diesen auch nicht mehr aufholen wird.

Die Rolle der Programmiersprache bzw. Skriptsprache, die überall installiert ist, hat zum Einen die immer stärker werdende Bash und zum Anderen Python übernommen. Tatsächlich finde ich auch, dass Python eine sehr "schöne" Programmiersprache ist (an dieser Stelle sei erwähnt, dass ich eher Skripter als Programmierer bin).

Ja, Ruby spielt auch noch eine Rolle, aber meiner Meinung nach eher oder stärker bei Webanwendungen als in der Systemadministration (meinem Arbeitsfeld). Ausnahmen wie Puppet bestätigen die Regel.

Bei grösseren Anwendungen könnte Perl 6 tatsächlich auch wieder eine Rolle spielen. Warum ich das vermute, werde ich vielleicht in den folgenden Artikeln darlegen können.

Ein grosses und nicht zu unterschätzendes Plus von Perl ist allerdings die internationale Perl-Community, die einfach nur grossartig ist und die uns Events wie den Swiss Perl Workshop 2015 mit Perl 6 Hackathon durchführen lässt und Gäste aus der ganzen Welt anzieht. Die Community bewegt mich auch dazu, mich weiter für Perl einzusetzen und eine Rolle im Perl-Verein Schweiz zu übernehmen.

Durch die grossartigen Sponsoren, die auch zu einer gut funktionierenden Community gehören, konnten wir die Reisekosten der Perl 6 Core Entwickler übernehmen und hatten so unter anderem auch Larry Wall zu Gast. Zum diesjährigen Swiss Perl Workshop wird es auch einen Artikel geben.

Ich muss gestehen, dass mir andere Communities neben denen von Fedora, Ubuntu und Perl gar nicht auffallen, was aber auch an meinem begrenzten Blickfeld liegt. Wenn Ihr das anders sehr, bin ich für Kommentare hier sehr dankbar.

Larry Wall hat sich den Fragen der Community zu Perl6 gestellt, Roman hat das alles zusammengebaut (Danke!).

Ich möchte an dieser Stelle auch noch einmal auf unsere Sponsoren hinweisen, ohne die der Swiss Perl Workshop 2015 und Perl 6 Hackathon nicht möglich gewesen werde (sie werden im Abspann erwähnt).

At FrOSCon 2015 we had a spontaneous mini Taskwarrior meetup. Once again it was quite interesting to speak with people you only know virtually.

From left to right: Lynoure Braakman, Sujeevan Vijayakumaran, Wilhelm Schürmann and myself, by "accident" sorted by height.

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.

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.



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

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.

• Monthly Commits
• Monthly Contributors
• Monthly Lines of Code changed
• Monthly Projects

Mal schnell wegbloggen, ich habe vor 1,5 Wochen mein Hauptarbeitsgerät mittels fedup von Fedora 21 auf Fedora 22 aktualisiert. Dabei war ich ziemlich überrascht, wie reibunglos alles funktioniert hat. Das Update von KDE 4.x auf Plasma 5 hat sehr gut funktioniert!

Interessanterweise wurden auch die eingebundenen Fremdrepositories angefasst.

"Normalerweise" installiere ich neue Releases direkt mit der ISO-Datei neu, das war nur ein Test, ob es funktioniert und ich muss sagen: Prima!

So soll es sein:

Das Video ist echt grossartig gemacht:

Weil ich gestern darüber gestolpert bin und sehr lange gebraucht habe, bis ich die entsprechenden Einstellungen gefunden habe.

Webcams, genauso wie USB 2.0, laufen unter VirtualBox nur, wenn man das Extension Pack (von der Download-Seite) passend zur benutzten Version installiert hat.

Das Extension Pack ist der Teil von VirtualBox, der nicht Open Source ist, gemäss dieser Seite fügt es folgende Features zu VirtualBox hinzu:
• The virtual USB 2.0 (EHCI) device
• VirtualBox Remote Desktop Protocol (VRDP) support
• Host webcam passthrough
• Intel PXE boot ROM
• Experimental support for PCI passthrough on Linux hosts

Installiert wird es mit:

Achtung: Das muss vermutlich bei jedem Update von VirtualBox wiederholt werden.

Nach der Installation kann man USB 2.0 Support einschalten und in einer laufenden VM erscheint unter "Geräte" der Punkt Webcams, mit dem man die verbundene Webcam an die virtuelle Maschine durchreichen kann.

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.


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

Weil ich es neulich gebraucht habe.

Aufgabe ist es, Zeiten eines normalen Datums in einen Unixtimestamp und wieder zurück umzurechnen. Nebenbedingung, es dürfen nur Bordmittel verwendet werden und laufen sollte es bitte unter Linux und Solaris. (Unter Solaris ist im Standard kein GNU date aus den GNU coreutils installiert, sonst wäre es einfach).

Meine Lösung war, Perl zu benutzen.

Einzig das Datumsformat ist unschön, vom Monat muss eins abgezogen werden und vom Jahr 1900.



Und der Rückweg:



Wenn Ihr bessere Ideen habt, dann nur her damit.

Am gestrigen Sonntag wurde Debian 8.0, Codename "Jessie" veröffentlicht.

Neben der üblichen Versionspflege ist die vermutlich grösste Änderung die umstrittene Umstellung von System-V-Init auf Systemd (ich persönlich begrüsse das sehr).

Die weiteren Änderungen sind zu zahlreich, um sie in einem kurzen Blogartikel zu beleuchten, das haben andere bereits erledigt. Es lohnt sich in jedem Fall ein Blick in die (auch in deutscher Sprache erhältlichen) Releasenotes oder dem Artikel bei Pro-Linux.

Wer die Informationen gerne in Form von Slides haben möchte, wird bei Michael Prokop fündig (PDF) oder kann sich die "Folien" (HTML) von Axel anschauen.

Ich freue mich sehr darüber, dass sich das LTS-Modell durchsetzt. LTS steht für Long Term Support und in Debian dafür, dass die Version fünf Jahre lang mit Sicherheitsupdates versorgt wird. Die Seite LTS im Debian-Wiki klärt über das "wie" auf.

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.