Dirks Logbuch

Da kann man mal sehen, wie viel Zeit es braucht bis ein Artikel fertig wird ...

Wer einen Distributionstest sucht, sollte meiner Ansicht nach lieber bei Pro-Linux oder Michael Kofler nachlesen.

Meine Anmerkung ist eher "philosophischer Natur"

Zum Einen finde ich es klasse, dass sich bei OpenSUSE endlich wieder etwas getan hat. Tot gesagte leben bekanntlicherweise länger. SUSE war "meine Einstiegsdroge" in die Linuxwelt und ich hätte es sehr schade gefunden, wenn diese Distribution einfach sang- und klanglos verschwunden wäre.

Zum Anderen gefällt mir das Konzept sehr (keine Angst, ich denke derzeit nicht darüber nach, zu wechseln). Es bietet eine sehr gute Alternative zu bestehenden Distributionen, die sich (bis jetzt) bezogen auf Softwareversionen ganz grob in drei Lager einteilen liessen:

1. Abgehangen (ich möchte nicht veraltet sagen, weil es nicht passt), stabile Software, die lange unterstützt wird. Vertreter dieser Gattung finden sich besonders bei den Server-Systemen, seltener auf dem Desktop.
• CentOS
• Debian
• Ubuntu LTS
2. Schnell drehend, relativ viele Updates, aktuelle Software, kurze Support-Zeiträume. Typische Verwendung als Desktopsystem für (ambitionierte) Endbenutzer.
• Fedora
• Ubuntu (ohne LTS)
3. Ständig aktualisierend ("rolling release"), meist topaktuelle Software häufig zu Lasten der Stabilität. Wer nicht regelmässig mitspielt ("aktualisiert") manövriert sich in Schwierigkeiten.
• ArchLinux
• Sabayon
• Gentoo
• OpenSUSE Tumbleweed

Klar, dass noch wesentlich mehr Distributionen gibt, die obigen seien nur als Beispiele genannt.

Es gibt natürlich Zwitter, so lassen sich die abgehangenen Systeme durch zusätzliche (nicht vom Hauptrojekt unterstützte) Paketquellen mit aktuellerer Software bestücken.

Und diesen "Zwitter-Weg" geht jetzt auch OpenSUSE Leap. Sie bauen auf der stabilen Basis von SUSE Enterprise Linux auf und portieren aktuelle Applikationen aus Tumbleweed zurück in die Distribution und unterstützen sie auch offiziell.

In der Summe ist das eine Mischung aus der ersten und der dritten gerade genannten Kategorie. Für mich ist dieser Weg das Beste aus allen Welten für Endanwender und ich hoffe, dass einige weitere Distributionen dem Beispiel folgen werden. Allerdings, das darf man nicht vergessen, kann der hohe Takt auch zu Problemen führen.

Termux ist eine Linux-Umgebung (und Terminal-Emulator) für Android, damit wäre schon fast alles gesagt, wenn es nicht so toll und zu dem noch Open-Source-Software wäre

In der App lassen sich nämlich Pakete via apt nachinstallieren und das ohne, dass man für das Gerät root-Rechte benötigt. Neben den üblichen Verdächtigen, wie beispielweise openssh oder vim gibt es auch ein Paket für Taskwarrior, das direkt funktioniert. Zusammen mit dem Taskserver lässt sich so auch bequem synchronisieren.

Der Entwickler ist sehr aktiv und steht Paketwünschen sehr wohlwollend gegenüber. Am einfachsten kann man vermutlich einfach einen Request im entsprechenden GitHub-Projekt einstellen.

Den Tipp zu Termux hat mir Wim (hast Du eigentlich eine Webseite?) auf der OpenRheinRuhr gegeben.

Nachdem ich die beteiligten Komponenten zur Entstehung des Linkdumps einmal aufgeschrieben hatte, kam mir das alles mehr als merkwürdig und viel zu kompliziert vor.

"Drüben", bei Google+, wurde mir nochmals Wallabag als Lösung zum Selberhosten ans Herz gelegt. Als ich das zuletzt "vor 100 Jahren" getestet habe, hat es mir nicht gefallen.

Mittlerweile hat sich da aber eine Menge getan und ich bin schwer begeistert, wie toll Wallabag mittlerweile geworden ist. Very well done!.

Wallabag ist eine Webapplikation, mit der sich einfach Webseiten lesen lassen. Dabei sorgt sie dafür, dass das ganze Brimborium um den Haupttext abgeschnitten wird und so ein sehr gut lesbarer Text entsteht, der ablenkungsfrei gelesen werden kann. Die so entkernten Webseiten lassen sich auch als E-Book (epub in Version 3, Mobipocket oder PDF) herunterladen und mit einem entsprechenden Readern lesen.

Von dem Export mache ich aber keinen Gebrauch, weil es auch eine sehr gute Android-App gibt (an eine App für iOS und eine App für Windows Phone wurde ebenfalls gedacht).

Prima finde ich auch, dass sich Wallabag mir der Share-Funktion von Firefox nutzen lässt oder mit einem Bookmarklet oder mit dieser Extension.

Solltet Ihr die Dokumentation benötigen, rate ich stark, die englischsprachige zu nehmen, die Doku in deutscher Sprache ist veraltet und zum Teil falsch.

Der Workflow bei mir hat sich jetzt so verändert, dass ich gute Artikel in der Wallabag App favorisiere und auf gelesen setze. Das folgende kleine Skript erstellt mir dann das Gerüst für den Linkdump.

Ach ja, wer bei mir einen Account möchte, kann sich gerne melden.

Mittlerweile bin ich wieder mehrfach darauf angesprochen worden, wie mein Linkdump entsteht, den ich jeden Freitag veröffentliche. Ihr habt es nicht anders gewollt ...

Die folgenden Softwarekomponenten und Dienste sind daran beteiligt:

Auf meinem Server läuft die RSS Bridge, die mir die öffentlichen Postings einiger ausgewählter Google+ und Twitter Accounts als Feed zur Verfügung stellt.

RSS-Feeds bilden die Hauptquelle meiner Informationen, alle Feeds laufen im selbst gehosteten Tiny Tiny RSS auf (wer einen Account möchte, kann sich gerne melden). Dort lese ich die Feeds meistens über das Web. Ich nutze das tt-rss-feedly-theme, weil mir das mitgelieferte nicht gefällt.

Auf dem Tablet nutze ich manchmal News+ Premium mit der Tiny Tiny RSS Extension. Damit die Synchronisation der gelesenen Nachrichten mit Tiny Tiny RSS funktioniert, muss dort noch das TT-RSS News+ plugin installiert werden.

In Tiny Tiny RSS kann man Artikel mittels "Shift-s" veröffentlichen, das mache ich für Artikel, die länger sind und, die ich später lesen möchte (Basis für den Linkdump). In der News+ App kann man Artikel nur markieren, das entspricht "s" in Tiny Tiny RSS, die so markierten Artikel bearbeite ich in der Webansicht mit "s" und dann "Shift-s" nach, damit sie veröffentlicht werden.

Veröffentlichte Artikel landen in Tiny Tiny RSS in einem Feed, die URL findet man unter "Aktionen/ Einstellungen/ Feeds/ Veröffentlichte und geteilte Artikel / erzeugte Feeds", dann auf "Zeige URL an".

Diesen Feed stecke ich (noch) in If this then that und lasse die Einträge an Pinboard weiterleiten und mit dem Tag "2do" versehen. Das "noch" bezieht sich darauf, dass ich die Funktionalität gerne durch ein selbst geschriebenes Python-Skript ablösen möchte (ein externer Dienst weniger).

Favorisierte Tweets aus Twitter landen ebenfalls in Pinboard, allerdings ohne weiteres externes Tool.

Die Links in Pinboard schaue ich durch und bei dem, was auf die Leseliste soll, suche ich nach Druckversionen der Onlineartikel, nutze den entsprechenden Link zur Druckseite - der Orginallink wandert in das description-Feld - und gebe den Tag "crofflr". Für Pinboard gibt es neben vielen anderen auch Pindroid für Android und eine Erweiterung für Firefox.

Crofflr ist ein Dienst, der (konfigurierbar) einmal wöchentlich - bei mir Freitagmorgen um 5:00 Uhr - alle ungelesenen Pinboard-Links mit dem Tag "crofflr" liest und aus den beteiligten Seiten ein epub baut und in der Dropbox ablegt (ein guter Grund Dropbox für nicht sicherheitsrelevante Daten weiter zu nutzen). Crofflr kann übrigens auch andere Dienste, wie beispielsweise Pocket, Longform.org, Longreads oder The Feature anzapfen. Als ich noch den Kindle benutzt habe, habe ich mir statt der epubs die entsprechenden Mobipocket-Dateien für den Kindle erzeugen und per E-Mail zusenden lassen.

Crofflr sorgt auch dafür, dass die für das epub bzw. mobi benutzten Links auf gelesen gesetzt werden. Die Links, die nicht verabreitet werden konnten, bleiben auf ungelesen stehen. Nach dem Crofflr-Lauf vergebe ich für alle "crofflr" etikettierten Links das Tag "linkdump" und lösche den Tag "crofflr".

Auf dem Tablet benutze ich Moon+ Reader Pro als Anwendung zum Lesen.

Spätestens am Donnerstag oder nach Lektüre des epubs schaue ich mir alle "linkdump"-Links in Pinboard an und lösche die, die ich nicht veröffentlichen möchte, passe die Beschreibung und/oder die URL bei Links an, die veröffentlicht werden sollen. Artikel, die ich nicht geschafft habe, bekommen wieder den Link "crofflr" und werden auf ungelesen gesetzt, so dass sie am Freitag nochmals auf dem Tablet landen.

Ein kleines Bashskript liest alle mit "linkdump" bezeichneten Links und die Ausgabe dient als Basis für den Linkdump, der am Freitag erscheint.



Die mit "linkdump" bezeichneten Artikel lösche ich, wenn der Artikel in Serendipity gespeichert wurde.

Das liest sich aufgrund der Länge vermutlich viel komplizierter als es ist.

Was mir nicht gefällt, ist, dass so viele verschiedene Dienste beteiligt sind, das nervt.

Zum Thema "Kostenloskultur bei Android Nutzern": News+ Premium und Moon+ Reader Pro kosten Geld, Pinboard und Crofflr ebenfalls.

Weil ich danach gefragt wurde.

Wenn man den zu Taskwarrior passenden Taskserver übersetzen und benutzen möchte, sind folgende Schritte nötig:

Die sollten auch unter CentOS 7 funktionieren.



Gerade die letzte Bibliothek wird benötigt, wenn man einen älteren C++-Compiler - wie in CentOS 6 - einsetzt.

Gebaut wird dann mit


ACHTUNG: Das letzte Zeichen der Zeile, die cmake ausführt ist ein Punkt ".".

Der CMAKE_INSTALL_PREFIX kann wegfallen, wenn man den Taskerver unterhalb von /usr installieren möchte (dann muss man im letzten Schritt auch sudo make install ausführen.

Jetzt noch die Pfade konfigurieren und dann kann es losgehen:


Testen mit


Viel Spass!

Man, was ist das nervig.

Aufgrund eines Irrtums, der sich durch Hören dieser Folge (ab 01:29:32) des empfehlenswerten Podcasts Rechtsbelehrung aufklärte, werde ich mit meinem root-Server wieder nach Deutschland umziehen. Ich hatte das hier schon mal angemerkt.

Mit Bekannten teile ich mir einen Backupserver bei Hetzner und da liegt es natürlich nahe mit dem Server auch zu Hetzner zu gehen. Das Preis-/Leistungsverhältnis für den EX40 ist einfach ungeschlagen. Der Server, wie auch der andere Server der Bekannten, läuft mit CentOS und sehr schnell, also so wie er soll.

Mein neuer Server stand in Rechenzentrum 20 und "fühlte" sich immer sehr langsam an, vor allem das Installieren dauerte ewig. Nun, EPEL-Repositories sind aktiviert und ich bekam den Server kurz vor dem Release von Fedora 23, daher dachte ich, es lag daran. - So war es aber nicht.

Ich habe einen nmap auf Port 22 eines Servers in einem anderen Rechenzentrum bei Hetzner gemacht und der dauerte 16.5 Sekunden, von einem anderen Server bei Hetzner (ebenfalls nicht im gleichen Rechenzentrum) dauerte es 0.07 Sekunden und von zu Hause 0.2 Sekunden.

Das spricht sehr stark dafür, dass etwas im Routing nicht sauber funktioniert und die Pakete den "falschen (langsamen) Weg nehmen". Der Hetzner-Support versuchte das Problem mit dem Rettungssystem (Debian) nach zustellen, aber da funktionierte alles zufriedenstellend. Sie verweigerten Support für das installierte System, was ich verstehe, bei einem root-Server ist man auf sich alleine gestellt.

Also habe ich den Server mit dem offiziellen CentOS-Image neu installiert und danach nichts anderes gemacht als nmap zu installieren. Das Problem war wieder da.

Jetzt ist für mich klar, dass da irgendetwas im Zusammenspiel von CentOS mit dem Routing Probleme bereitet.

Aber auch jetzt fand der Support kein Problem, ich gehe davon aus, dass es nie unter CentOS nachgestellt haben und sie boten mir an, einen Austauschserver zu bekommen. Aufgrund der Prozesse sollte ich den alten Server kündigen und den neuen bestellen, sie würden dann an der gleichen Stelle einen neuen Server bereitstellen. Das hätte das Problem meiner Ansicht nach nicht gelöst.

Glücklicherweise kann man einen Server innerhalb von zwei Wochen stornieren, das habe ich gemacht. Dann habe ich einen neuen Server bestellt und darum gebeten ihn nicht im gleichen Rechenzentrum 20 bereitzustellen. Das dauert knapp 24 Stunden und, was soll ich sagen, im Rechenzentrum 21 gibt es das gleiche Problem.

Man, das nervt.

Also wieder storniert und neu bestellt und jetzt darauf geachtet, dass der Server in ein Rechenzentrum kommt, wo ich weiss, dass es funktioniert.

Das ist halt der Nachteil, wenn man zu einem Grosshoster geht und dort wirklich Probleme hat. Die grosse Anzahl an Systemen können nur durch einen standardisierten Prozess verwaltet werden. Lösungen, die ausserhalb dieser Prozesse liegen, funktionieren halt nicht. Nicht falsch verstehen, das ist kein Vorwurf, es geht nicht anders. Aber es nervt.

Die Kommentare des Artikels Rechnen mit Python kann man vermutlich nur mit einer gehörigen Ladung Popcorn ertragen, vor allem der Teil, dass der Computer bestimmt, was mathematisch korrekt ist, hat Unterhaltungswert.

Damals habe ich schon angemerkt, dass Computer auch mit geschickteren Algorithmen rechnen könnten, um möglichst genau zu sein. Die Variante, die Perl 6 umsetzt, ist allerdings so einfach wie brillant. Werte mit Nachkommastellen werden einfach intern als Brüche (rationale Zahlen) gespeichert und so ist 90% des Rechnens einfache Bruchrechnung und damit genauer (und sogar korrekt) als das Rechnen mit Fliesskommazahlen. Allerdings ist das natürlich langsamer, daher kann man auch explizit festlegen, dass man Fliesskommaarithmetik möchte.

Das Beispiel aus dem verlinkten Artikel:

> 1100-1036.04
63.96

Gucken wir uns einmal die Datentypen an:

> say 1100.WHAT
(Int)
> say 1036.04.WHAT
(Rat)
> say (1100-1036.04).WHAT
(Rat)

Brüche haben einen Zähler und einen Nenner (Perl 6 kürzt automatisch):

> say 63.96.numerator
1599
> say 63.96.denominator
25
> say 63.96.nude
(1599 25)

Das ist alles nicht so wahnsinnig spannend. Wer allerdings programmiert, weiss, dass so etwas normalerweise als ungleich ausgegeben wird.

> my $a=1/6
0.166667
> my $b=1/3
0.333333
> if (4 * $a + $b == 1) {say "Ist gleich"} else {say "Ist ungleich"}
Ist gleich

Fliesskomma geht auch, aber hier wird für die Darstellung gerundet.

> say 1100e0-1036.04e0
63.96
> say (1100e0-1036.04e0).WHAT
(Num)

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.

Da es noch kein Release von Perl 6 gibt, ist eine Installation via GitHub mit den Skripten von Tadeusz Sośnierz die schnellste Variante.

Tadeusz schlägt vor die Installation ins Verzeichnis ~/.rakudobrew zu packen, das gefällt mir nicht so gut.



Das export PATH=... würde ich auch gleich in die ~/.bashrc packen.

Mit dem folgenden Kommando wird ein Perl 6 gebaut, das dauert ein paar Minuten funktioniert aber zuverlässig.



Der neue Paketmanager von Perl 6 heisst Panda, diesen würde ich im nächsten Schritt gleich mitinstallieren.



Da Perl 6 einen interaktiven Interpreter enthält, der aber noch nicht in der Historie "blättern" kann, kommt noch linenoise dazu. Ich möchte Euch bitten vor dem Schritt einmal perl6 aufzurufen, um zu sehen, wie schnell der Interpreter startet.

Nach der Installation von linenoise braucht der Interpreter deutlich länger, da muss sich noch etwas tun.



Und jetzt: Viel Spass mit Perl 6.

Zeit für eine kleine Zusammenfassung des Swiss Perl Workshops dieses Jahr.

Der Workshop ist jetzt schon über vier Wochen vorbei und er wirkt für mich immer noch nach. Ich habe viele nette Leute neu kennengelernt und alte Bekannte wieder getroffen. Interessant war es, einmal die Berühmtheiten aus der Perl-Szene zu sehen und mit Ihnen reden zu können.

Allen voran ist natürlich die "Legende" Larry Wall zu nennen - ja, es gibt ihn wirklich, aber auch die Core-Developer von Perl 6 wie Jonathan Worthington (DER Core-Entwickler und Macher von hervorragenden Tutorials), Will "Coke" Coleda (hat Larry Eure Fragen gestellt), Paul Cochrane (promovierter Physiker, Erfinder des Warp-Drives), Stefan Seifert, Vende Thiel, Sue Spence, Carl Mäsak, Elizabeth Mattijsen, Tadeusz SoÅ›nierz (Installskript für Perl 6 aus den Quellen), Tobias Leich, Timo Paulssen, Wendy van Dijk und viele andere mehr, die man über die Suche finden kann (Suchfelder leer lassen, um alle zu finden).

Dank der vielen Sponsoren konnten wir die Reise- und Hotelkosten einiger Core-Entwickler übernehmen. DANKE!

Matthias (der leider nächstes Jahr nicht mehr dabei ist), Roman und ich haben den Workshop organisiert, wobei Matthias den Löwenanteil an IRC-Kommunikation getragen hat, da er tagsüber die Möglichkeit hatte, mitzulesen und zu schreiben.

Das Programm war sehr vielfältig und interessant, allerdings habe ich leider nur zwei Teile wirklich komplett wahrnehmen können, zum Einen das Interview von Larry Wall mit Will Coleda und zum Anderen den ersten Teil des Perl 6 Workshops von Jonathan Worthington.

Dass die ganze Veranstaltung ein so grosser Erfolg war, liegt ganz besonders auch daran, dass wir mit Daniela, Anja mit Ronja und Christoph ein hervorragend gutes und motiviertes Küchenteam hatten, die für uns gekocht (und gespült) haben. Danke!

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.