onli blogging

Europaweit sind Demos gegen die Urheberrechtsreform und die einhergehenden Uploadfilter angekündigt. Die Termine finden such auf savetheinternet.info/demos, auf der Seite gibt es auch eine Petition (mit 4 Millionen Unterschriften!). Die mir nächste ist Köln, dort werde ich hingehen. Vielleicht sieht man sich?

Die Vorgeschichte: Es ist die Fortführung des Leistungsschutzrechts. Leistungsschutzrecht ist Beschönigungssprech für den Wunsch der Verleger, Geld verlangen zu können wenn jemand einen Link auf ihre Seite setzt und dabei selbst einzelne Worte zitiert. Das gabs schonmal auf nationaler Ebene – denn die Verleger haben die Politiker hier natürlich in der Tasche – aber Google weigerte sich einfach zu bezahlen. Die Verlage gaben Google dann einen Blankoscheck für die Verwendung ihrer Inhalte, das deutsche Gesetz lief ins Leere. Blogger zu verklagen war dann doch nicht lukrativ genug.

Jetzt versuchen sie es nochmal auf EU-Ebene. Weil Google wieder nicht für Links zahlen wird ist das Gesetz diesmal ausdrücklich so formuliert, dass es alle anderen betrifft und nicht nur große Internetkonzerne. Vor allem soll zwar Youtube geschlachtet werden: Mit der Auflage, Inhalte vor Upload zu prüfen und sonst Strafzahlungen leisten zu müssen. Das geht bei der Masse an Videos gar nicht, außer mit automatisierten Uploadfiltern, die aber saudumm sind. Ergebnis: Sie würden alles blocken, auch zulässige Zitate und Remixe. Das ist Artikel 13 und das Hauptproblem.
Artikel 13 betrifft aber nicht nur Youtube, was schlimm genug wäre. Es betrifft alle Seiten mit Inhalten, die kommerziell sein könnten und von Nutzern hochgeladen werden. Das ist eine massive Gefahr für diese gesamte Internetbranche, aber auch für den Rest des Internets.

Denn es ist nicht klar, ob durch die schwierigen nationalen Regeln nicht auch simple Seiten wie unsere Serendipity-Forum betroffen wären. In Deutschland ist ja fast alles als kommerziell interpretierbar und die Seite existiert länger als 3 Jahre, die Ausnahmeregelungen würden dann nicht greifen. Wir sind mit dem Geiste des Artikel 13 eine kleine Interpretation vom vollständigen Ende des Internets abseits von Facebook entfernt.

Es gibt dazu noch Artikel 1112, der Verleger explizit Einnahmen zuspricht, die den Urhebern zustehen. Das ist genau die VGWORT-Praxis, die vor kurzem als illegal erkannt und gekippt wurde. Etwas weniger schlimm als Artikel 13, trotzdem eine asoziale Schlechterstellung der angeblich mit der Reform zu schützenden Urheber.

Die Reform kam erst nicht durch, dann haben Deutschland und Frankreich sich zusammengesetzt und a la Merkelsteuer einen Kompromiss gefunden, die Regelungen also verschärft. Seitdem wollen SPD und CDU und auch viele Grüne für dieses Verleger-Lobbyvorhaben stimmen – trotz eines Koalitionsvertrags, der Uploadfilter verbietet. Die CDU hat gerade angekündigt, dann mit nationalen Regelungen Uploadfilter zu verhindern. Eine glatte Lüge, das ginge gar nicht, und warum stimmten sie dann im EU-Parlament dafür?

Deshalb ist es so wichtig zur Demo zu gehen: Die Politiker verarschen uns gerade mal wieder. Die CDU setzt sich sowieso wann immer möglich gegen Freiheitsrechte ein, die SPD verrät uns wie immer (diesmal personifiziert von Katarina Barley), die Grünen sind eben teils konservative Möchtegern-CDUler und rennen denen auch in Zensurvorhaben hinterher. Nur mit viel Druck auf der Straße gibt es eine Chance, diese Einschränkung unserer Rechte doch noch zu verhindern.

«Wer sich als US-Diplomat wie ein Hochkommissar einer Besatzungsmacht aufführt, der muss lernen, dass unsere Toleranz auch Grenzen kennt», sagte Kubicki

Manchmal kommen auch aus Spaßparteien vernünftige Vorschläge.

Kubicki hat natürlich Recht und das unterwürfige Gehabe der deutschen Politiker der USA gegenüber gehört endlich adressiert. Das ist sonst wie bei Merkels Handy: Pure Unterwürfigkeit. Kubickis klare Ansage ist wohltuend und berechtigt.

Mitch hat es in seinem Artikel gut erklärt: Serendipity aß Trackbacks. Das war bekannt, aber die Ursache war bis jetzt unklar. Mitch stolperte aber darüber, als Thomas seine Webhook-Artikelreihe verlinkte und da eben immer nur ein Trackback ankam, ließ nicht locker und fand die Ursache.

Schuldig war eine Spamblockoption. "Keine doppelten Kommentare erlauben" wurde nicht nur auf Kommentare angewandt, sondern auch auf Trackbacks (nicht aber auf Pingbacks!). Wenn dann ein Artikel mehrere Artikel eines anderen Blogs verlinkte schlug diese Einstellung zu, denn es passt ja genau – der Inhalt des Trackbacks ist eben jeweils der gleiche.

Besonders mies war dieser Teil der Abfrage:

$_SERVER['REMOTE_ADDR'] != $_SERVER['SERVER_ADDR']

Die Einstellung griff also nicht im eigenen Blog. Also, nicht in meinem Entwicklungsblog. In diesem Blog hier schon, weil durch Cloudflare die REMOTE_ADDR eben doch von der SERVER_ADDR abweicht. Sonst wäre vielleicht das Schema schon vorher klar geworden.

Ich habe nun das Spamblock-Plugin im Master aktualisiert:

1. Die Option greift jetzt nur noch bei Kommentaren.
2. Außerdem ist sie standardmäßig aus, weil sie selbst bei normalen Kommentaren zu viele valide verbieten wird.

Vielleicht sollten wir sie wie im Artikel argumentiert grundsätzlich intelligenter machen. Andererseits haben wir mit dem Bayes-Plugin und der Spamblock-Bee bereits bessere Alternativen zur Hand.

Vielen Dank an Mitch fürs Debuggen! Genau solche investierte Zeit und Arbeit kann Serendipity derzeit sehr gut gebrauchen.

Der erste Beitrag in diesem Blog ging im Januar 2008 online. Nicht alles, was ich in diesem langen Zeitraum geschrieben habe gefällt mir heute noch. Man lernt dann halt doch dazu was man vertreten will, was wie verstanden werden wird. Andere Blogeinträge finde ich heute unschön geschrieben. Und einige sind einfach veraltet: Ich veröffentlichte gerade am Anfang oft kurze Hinweise auf Videos und Artikel, von denen der Großteil heute natürlich nicht mehr online ist. Das wäre vielleicht nicht schlimm wenn diese Beiträge länger als ein Tweet wären, so aber sind sie heute uninteressant.

Ich kam da übrigens drauf, als ich Formatierungsfehler in einem Artikel bemerkte. Zumeist invalides HTML, das damals wohl durchging. Die alten Artikel sah ich auch nur, weil Googles Chart-API abgeschaltet wird und mir ein paar Artikel einfielen, in denen diese API genutzt wurde. Diese Fehler reparierte ich gestern und die Charts sind nun lokal gespeichert.

Wie haltet ihr das? Löscht ihr alte Artikel, formuliert ihr sie um? Oder ignoriert ihr sie, immerhin wird sie ja kaum jemand je aufrufen?

Ich habe den iRobot Roomba 615 schon vor ein paar Monaten für 185€ als Amazon-Warehouse-Deal gekauft. Inzwischen liegt selbst sein Neupreis nur noch bei 200€ und gebraucht kostet er ~120€, auch bei Lidl wurde er neu für den Preis meines Gebrauchtmodells verscherbelt.

Es wundert nicht, denn der Saugroboter ist massenmarktreif. Ich muss wohl dazusagen: Meine Wohnung ist perfekt für ihn. Ich habe keine Treppe und keinen Teppich. Dafür aber zwei Katzen und vor allem die mit längerem Fell haart sehr viel, daher auf jeden Fall Bedarf. Vor allem mag ich Staubsaugen nicht und müsste das ohne den Roboter jeden zweiten Tag trotzdem tun. So sah übrigens die erste Begegnung Tier-Roboter aus:

Das ging also harmlos aus.

In einer Wohnung wie meiner ist der Roomba 615 absolut ausreichend. Klar, er kann nicht in jede Ecke und manchmal bleibt er irgendwo stehen. Trotzdem macht er seinen Job gut, die Wohnung ist seit seiner Anschaffung durchschnittlich sauberer, zumindest als wenn ich den Boden sauberhalten müsste. Die Mitbewohnerin war schon nochmal gründlicher.

Meine Bedenken waren:

1. Ist er nicht zu laut?
2. Was, wenn die Katzen vorher irgendwo hinkacken und er das schön verteilt?
3. Macht er überhaupt sauber?

Den letzten Punkt adressierte ich ja eben schon. Tatsächlich ist er trotz des kleinen integrierten Behälters ausreichend für die zwei Katzen, nach einem Durchgang ist er dann aber auch voll und muss geleert werden. Erfreulicherweise geht das sehr einfach.

Das zweite Bedenken beruhte mehr auf einer falschen Vorstellung. Ja, er wäre zu doof um diese Situation zu vermeiden. Aber dieses einfache Modell fährt nicht von alleine los. Es gibt keine Programmiermöglichkeit, keinen Zeitplan, keine App. Stattdessen drücke ich zweimal auf den Startbutton (beim ersten Mal leuchtet die Batterieanzeige auf), erst danach fährt er autonom durch die Wohnung. Vorher muss die Wohnung sowieso aufgeräumt werden: An kleinen losen Kabeln verfängt er sich sonst (Ethernetkabel sind kein Problem), kleine Gegenstände würde er durch die Wohnung schieben. In der Praxis ist das kein Problem und immer noch tausendmal angenehmer als selbst einen Staubsauger zu schleppen. Und er passt sogar unters Sofa!

Laut aber ist er. Immerhin nicht so laut wie ein normaler Staubsauger, und dass er nicht von alleine loslegt macht es erträglicher. So stört er wenigstens nicht im falschen Moment.

Die Wegfindung erscheint mir nicht sonderlich intelligent, aber sie funktioniert. Man hat nicht das Gefühl, dass er groß plant. Stattdessen folgt e wohl einfachen Regeln – bei Kollision setze zurück, umfahre Hindernisse eng um auch an Wänden und Tischbeinen zu saugen, solches Zeug. Der Ansatz ist ausreichend, er fährt fast immer die gesamte Wohnung ab. Nur manchmal reicht dann wohl die Akkulaufzeit nicht, ganz selten findet er sogar nicht mehr zu seine Ladestation und bleibt dann irgendwo stehen. Vor Kollisionen bremst er, zudem ist er vorne gepolstert, ich habe nicht den Eindruck dass Wände oder Möbel leiden.

Den Roboter würde ich nicht mehr missen wollen. Ich würde nicht tausend Euro für ausgeben, aber ein günstiges Modell ist wohl in fast jedem Haushalt eine gute Idee. Selbst wenn er eine größere Wohnung oder eine mit Teppichen nicht völlig sauberkriegen würde, er wäre trotzdem immer eine Hilfe.

Das zweite für mich interessante Spiel aus dem Caffeine-Humblebundle war mit Shadow Tactics ein Commandos in Japan. Vielleicht ist es näher an Desperados, doch die beiden Klassiker ähnelten sich ja sehr.

Mit wenigen vom Spieler kontrollierten Einheiten müssen auf Karten Missionen erfüllt werden, möglichst ohne sich dabei von der Gegnerübermacht erwischen zu lassen. Blades of the Shogun bedient sich voll beim Japan-Setting und gibt dem Spieler einen Ninja, ein Ninja-Mädchen, einen Samurai, einen alten Mann mit Gewehr sowie eine Frau, die sich als Geisha tarnen kann. Auch die Geschichte um einen Shogun und eine Verschwörung ist sehr üblich.

Alle Charaktere haben unterschiedliche Spezialfähigkeiten. Ich fand nur zwei der Figuren etwas schlecht ausbalanciert: Das Ninja-Mädchen Yuki hat fast keine Nachteile gegenüber dem Ninja Hayato. Der hat Shuriken und einen Stein zum Lärm machen, wobei Gegner nicht zum Stein hinlaufen und vom Shuriken getroffen lange nicht umfallen, dabei sehr sichtbar sind. Sie dagegen hat eine Falle und eine Flöte, sie kann so wunderbar einzelne Gegner mit der Flöte außer Sichtweite ihrer Gefährten und dort in Fallen locken.
Dass dagegen der alte Mann Takuma durch seine fehlende Nahkampfwaffe und begrenzte Munition mehr als Joker für schwierige Situationen da ist fand ich okay, aber Yuki und Hayato füllen beide die gleiche Rolle. Die Geisha kann Sichtbalken verringern und wird verkleidet nur von Samurais enttarnt, das macht sie an vielen Stellen sehr mächtig. Der Samurai Mugen schließlich lockt Gegner mit einer Sake-Flasche weg, kann mehrere auf einmal attackieren und sogar gegnerische Samurais erledigen, ohne dass sie wie bei den anderen vorher mit einem Schuss geschwächt werden müssen. Abgesehen von der merkwürdigen Dopplung der beiden Ninjas stimmt also die Vielfalt.

Die Missionen sind sehr gut gemacht. Jede Karte ist praktisch eine Sammlung von vielen kleinen Puzzles: Mit welcher Kombination welcher Fähigkeiten komme ich an den Wachen vorbei? Dazu haben die Level immer wieder Besonderheiten, zum Beispiel einen Gegner umgehenden Holzwagen oder Schnee, der verräterische Fußspuren sichtbar macht – und wir wissen ja, dass Ninjas im Schnee super-effektiv sind. Immer gibt es viele Büsche und Gebäude zum Verstecken und alle außer Samurai und altem Mann können mit Ranken und Enterhaken obere Ebenen erreichen, die von Gegnern kaum eingesehen werden. Nach einer kurzen Weile kommen Pistolen ins Spiel, die zum Ausschalten gegnerischer Samurais gebraucht werden und ansonsten als Notlösung für zu nervige Stellen dienen.

Sehr schön ist wieder die Planungsfunktion, hier Schattenmodus genannt. Mit Shift aktiviert wird jeweils eine Aktion pro Charakter vorgemerkt. Enter löst sie dann alle auf einmal aus. Die Funktion wird vor allem gebraucht um Gegnergruppen ohne den Samurai-Rundumschlag Mugens auszuschalten, oder wenn zwei Wachen sich gegenseitig decken und zeitgleich das Zeitliche segnen sollen. Auch für gegnerische Samurais ist die Funktion wichtig, sie müssen erst angeschossen und dann von der anderen Seite mit dem Schwert erledigt werden, sonst stehen sie nach wenigen Sekunden wieder auf.

Die Sprachausgabe ist entweder Englisch oder Japanisch, in beiden Fällen sehr gut. Das Spiel sieht auch hübsch aus. Auf den Screenshots kommen die eingebauten Bewegungen nicht rüber, beispielsweise im Wind flatternde Zeltplanen. Die Grafik der ja wirklich nicht schlecht aussehenden Vorgänger war da statischer, andererseits ist selbst Shadow Tactics in Sachen Grafik und besonders bei den Animationen nicht auf der Höhe der Zeit.

Laut Steam hat mich das Spiel 21 Stunden beschäftigt, die echte Spielzeit war zwar etwas geringer, aber das war trotzdem ordentlich.

Shadow Tactics: Blades of the Shogun hat mir wirklich gut gefallen. Alle Missionen sind durch ihr Leveldesign und der öfter mal unterschiedlichen Truppzusammenstellung unterschiedlich genug, sodass die 20 Stunden lang keine Langeweile aufkommt und das Spiel nicht repetitiv wird. Es ist einfach richtig gut gelungen.

Die Benchmarks von letzter Woche waren ja um den i5-5675C zu bewerten, für den ich ein mATX-Mainboard gekauft hatte. Beim Zusammenbau hatte ich aber ein Problem: Ich hatte keinen passenden Kühler zur Hand. Beide meiner Kühler sollten zwar kompatibel sein, aber bei beiden finde ich das Intel-Montagezubehör nicht mehr. Stattdessen wollte ich den Corsair H90 nutzen, der die inzwischen zur Seite gelegte Radeon HD 7950 gekühlt hatte. Stellt sich raus, dass der mit dem Mainboard nicht in mein Gehäuse passt, weil das MSI Z97-G43M oben einen fetten VRM-Kühler hat, der dann mit dem Radiator des H90 kollidiert.

Jetzt hätte ich einen neuen Kühler oder ein neues Gehäuse kaufen können. Es wurde ein Gehäuse: So konnte ich etwas passendes zum mATX-Mainboard holen, die mATX-Gehäuse sind ja etwas kleiner. Der H90 verstaubt nicht und die übrige Hardware kann im alten Gehäuse als Dritt-PC bleiben, so vielleicht besser einem neuen Nutzen zugeführt werden.
Das neue Gehäuse wurde dann das Antec P5 Mini, für das ich jetzt auch drüben im Blog von pc-kombo ein Review geschrieben habe. Spoiler: Ich bin zufrieden.

Allerdings ist dieser Formfaktor sicher diskutierwürdig. Als mATX-Gehäuse ist es eben nur ein bisschen kleiner als ein normaler mid-Tower. Andererseits fehlt dafür auch nicht gerade viel, vielleicht wäre eine Lüfterinstallationsmöglichkeit oben nett gewesen, das aber ginge mit anderen Modellen in der Größe durchaus. Es lohnt also nicht wirklich, aber es schadet wahrscheinlich auch nicht solch ein etwas kleineres Gehäuse zu wählen.

Ich wollte das zum einen einfach erwähnt haben, aber vor allem die Chance nutzen, hier eine Photo-Gallery einzubauen, was als Funktion ja jetzt in Serendipity integriert ist. Hier ist sie:

Beim Zubehör war übrigens ein Beeper dabei, mich hats gefreut. Immer wenn ein PC mal nicht startete in den letzten Monaten nach irgendwelchen Umbauten habe ich den vermisst.

Ich bin günstig über den Intel Core i5-5675C und ein Z97-Motherboard gestolpert. Eigentlich wollte ich gar keinen neuen Prozessor für mich, sondern dem Spiele-PC der Mitspielerin ein Upgrade verpassen. Der i5 ging dann aber doch an mich, dafür überließ ich ihr meinen AMD FX-8320E.

Doch die Frage war: Wieviel bringt uns das überhaupt? Und wie gut ist der i5-5675C?

Der Broadwell-Prozessor ist fast schon ein Kuriosum, auch deshalb reizte mich der Kauf. Intel hat ihn damals wenige Monate vor der neuen Prozessorgeneration Skylake veröffentlicht und kaum beworben. Seine integrierte Grafik ist stärker selbst als Intels aktuelle integrierte Grafiklösung und durch den ungewöhnlichen 128MB großen L4-Cache erreichte er in vielen Spielen eine besonders gute Leistung. Als AMD dann Ryzen veröffentlichte war der 5675C immer noch schneller als der neue Ryzen 5 1600, obwohl der 2 Kerne und 8 Threads mehr hat und anders als bei den alten FX-Prozessoren diese Kerne auch gar nicht schwach sind. Und er war auch schneller als sein eigener Nachfolger.
Windows allerdings konnte mit dem Prozessor zumindest anfangs nicht besonders gut umgehen, einige Spiele und Anwendungen starteten mit ihm einfach nicht.

Auf der anderen Seite hatte die Mitspielerin bereits einen Phenom II X6 1090T. Diese Phenom-Prozessoren waren bei der Single-Core-Performance kaum schlechter als die Jahre später veröffentlichten FX-Prozessoren in ihrer letzten und besten Iteration. Ich habe mir den FX damals nur geholt, weil ich für Funtoo soviel Zeug kompilierte, da ist er dann eben doch schneller. Aber ich habe nie gemessen wie groß der Unterschied in Spielen ist. Und müssten nicht modernere Spiele mittlerweile den FX-Prozessor mit seinen zwei Kernen mehr doch besser unterstützen?

Also habe ich mich hingesetzt und meine kleine Sammlung AM3(+)-Prozessoren durch ein paar Spielebenchmarks geschickt, bevor ich zum Intel Core i5-5675C wechselte und dort die Benchmarks wiederholte. Grafikkarte war meine Radeon RX 580, die Einstellungen standen in allen Spielen auf Low, es lief die in void Linux zum Testzeitpunkt aktuelle Version des Mesa-Treibers 18.3.3 und das System hatte 20GB Ram. Hier ist das Ergebnis:

Es ist ein erschreckend großer Sieg für den i5-5675C.

Kleine Einschränkung: Shadow of Mordor war bei den AMD-Prozessoren auf 60 FPS beschränkt, der Vergleich mit dem Intel-Prozessor ist invalid (ich hatte vergessen, vblank_mode=0 als Startparameter zu setzen und das erst beim letzten Prozessor angesichts seiner höheren Leistung bemerkt). Aber der Vergleich zwischen dem Phenom II X6 und dem FX-8320E ist interessant, denn der FX ist langsamer. Da der Phenom II X4 965 fast das gleiche Ergebnis erreicht wird hier deutlich, dass dieses Spiel vor allem einen hohen Takt einzelner Kerne braucht.

Ähnlich ist das bei Skylines. Dort erreichten alle AMD-Prozessoren in meiner mittelgroßen Teststadt mit sechzigtausend Einwohnern richtig schlechte FPS, der i5-5675C schlägt sich hier viel besser. Immerhin ist Skylines auch mit einer geringen Bildwiederholrate gut spielbar und der FX schlägt sich besser als seine Vorgänger, auch bei den hier nicht gezeigten minimalen FPS. Der kleine Athlon aber ist offensichtlich bei dieser Stadtgröße und genutzten Mods schon an seiner Grenze.

Im per Photon (3.16-7-beta) laufendem Witcher 3 ist der Athlon II X3 450 dann endgültig überfordert. Ich fand den kleinen Prozessor immer überraschend stark, selbst jetzt noch schlägt er sich wacker, der war damals sogar neu super günstig. Aber Witcher 3 ist wirklich zu anspruchsvoll für ihn. Der FX-8320E dagegen ist hier ziemlich klasse, der Unterschied zu den Phenoms ist relevant, der i5 nicht viel schneller. Ich vermute aber, dass die RX 580 selbst auf diesen niedrigen Grafikeinstellungen mindestens den Intel-Prozessor ausbremst. Klar, das kann sich durch Grafiktreiberverbesserungen ganz schnell ändern.

Ich hätte gerne noch wirklich moderne Spiele getestet, aber ich besitze keine. Die modernsten wie Deus Ex: Mankind Divided und Tomb Raider starten momentan nicht auf meinem System, schuld sind die auf nicht-Ubuntu-Distributionen üblichen openssl-Abhängigkeitsprobleme der Feral-Ports. Und zumindest Deus Ex würde auf den Phenom-Prozessoren sowieso nicht starten, da die benötigte SSE-Erweiterung fehlt.

Mein Fazit soweit ist, dass der Intel Core i5-5675C kein schlechter Kauf war. Bei älteren Spielen ist er den FX-Prozessoren haushoch überlegen. Im Benchmark auf pc-kombo ist er bei Windowsspielen auf dem Niveau des Ryzen 5 1600, daher wird er für moderne Spiele wahrscheinlich so lange ausreichen, bis diese mehr als 4 Kerne/Threads voraussetzen. Die Kompatibilitätsprobleme von Windows erwarte ich unter Linux nicht.

Bei den älteren AMD-Prozessoren fand ich es interessant, ihre schlechte Leistung in Spielen einmal selbst zu messen. Es ist genau wie unter Windows: Wenn Spiele auf wenige Threads setzen sind Phenom- und FX-Prozessoren den kontemporären Intel-Prozessoren komplett unterlegen. Der FX-8320E ist ja die letzte Iteration dieser Serie gewesen, mit allen Verbesserungen seit dem Start mit der Bulldozer-Architektur, wodurch die Single-Thread-Performance mit dem Phenom mithalten kann. Trotzdem sollte der 8320E wohl etwas übertaktet werden um den Vorgänger in jeder Situation zu schlagen. In modernen Spielen ist er dann etwas deutlicher besser, aber ein richtig großer Sprung ist er im Vergleich zum viel älteren Phenom II X6 nicht. Linux als Betriebssystem ändert daran wohl nichts.

Hinter meinem Computerbildschirm kleben die LEDs eines Lightpacks und seit einer Weile sorgt hyperion mit boblight-X11 dafür, dass sich die Farben der LEDs dem Bildschirminhalt anpassen.

Als ich damals hyperion installierte fand ich einen Hinweis auf hyperion-x11, aber keinerlei Infos dazu wie das zu benutzen ist oder wo sich das versteckt. Jetzt suchte ich nach einer Möglichkeit, die schwarzen Balken eines Videos zu ignorieren und stolperte wieder darüber. Mit boblight-X11 bleiben die LEDs beim Balken ja schwarz, aber es wäre vielleicht schöner wenn sie sich nach dem Videobild darunter richten würden. Ich las, dass hyperion das lösen würde, und es gibt eine Konfigurationseinstellung dazu:

    "blackborderdetector" : 
    {
        "enable" : true,
        "threshold" : 0.01
    },

Das gehört in die ~/.hyperion.config.json. Aber mit boblight-X11 als Bildschirmgrabber bewirkt das nichts. Aber diesmal fand ich hyperion-x11: Es wurde bei der letzten Kompilierung von hyperion miterstellt und lag in hyperion/bin/ des Kompilierungsordners. Und tatsächlich: Ohne Kommandozeilenargument statt boblight-X11 gestartet belieferte das sofort die LEDs mit Daten, nach ein paar Sekunden wurden die schwarzen Balken des Videos erkannt und daraufhin ignoriert.

Alles in allem lief der Blog nach dem Upgrade auf die Alpha gut, aber es gab doch noch ein paar Probleme.

Nicht alle hier genutzten Plugins waren kompatibel mit PHP 7.2. Zuerst bemerkte ich das Sitemaps-Plugin, damit installiert konnte ich keine Artikel abspeichern. Ich patchte das, aber es ist ein notdürftiger Patch und das Plugin braucht einen Maintainer, der es mal durchtestet und aufräumt. Dafür steht jetzt auch ein Issue auf Github.

Das zweite problematische Plugin war mein Bayes-Plugin, das beim Lernen eines Kommentars als Spam oder valid einen Fehler wegen einer Konstante warf, die ein String sein müsste. Der Patch ist hier und damit schon in Spartacus.

Problematischer waren ein paar Installationsspezifische Besonderheiten. Mein Blog benutzt je ein eigenes Theme, einen modernisierten Fork von codeschmiede. Nach dem Upgrade war die Kommentardarstellung falsch, das Datum fehlte und die Seitenleiste sah ebenfalls kaputt aus. Aber nicht direkt, erst nachdem ich wegen eines anderen Fehlers templates_c/ leerte. Tatsächlich war da mein Theme etwas kaputt, was ich dann auch im Testblog nachvollziehen konnte, aber vorher im Blog wohl wegen gecacheter Smarty-Dateien nicht bemerkte.

Drei Commits adressierten weitere Fehler im Kern. Erstmal mussten die Funktionen des internen Caches neu strukturiert werden, weil ich vorher die Cachedauer nicht gesetzt hatte. Jetzt sitzen die Funktionen auch an einer besseren Stelle im Kern und sind so leichter anderswo nutzbar. Dann fand ich einen weiteren Konstanten-Fehler. Und schließlich bemerkte Matthias, dass Seiten die eine 404-Fehlerseite anzeigen sollten stattdessen einen internen Fehler produzierten, was angesichts des Ausbleibens des Fehlers mit 2k11 scheinbar auch mit meinem Theme zusammenhängt. Der simple Patch war leider schwer gefunden.

Es bleibt noch ein Fehler: Gerade kann ich keine Preview dieses Artikel erstellen. Die Fehlermeldung besagt

Ihr Browser hat keinen gültigen HTTP-Referrer übermittelt. Dies kann entweder daher kommen, dass Ihr Browser/Proxy nicht korrekt konfiguriert ist, oder dass Sie Opfer einer "Cross Site Request Forgery (XSRF)" waren, mit der man Sie zu ungewollten Änderungen zwingen wollte. Die angeforderte Aktion konnte daher nicht durchgeführt werden.

Sowas sah ich auch vorher schonmal, aber dann half immer ein erneuten Klicken auf den Vorschau-Button, diesmal nicht. Das könnte an PHP 7.2 hängen oder auch an meiner Überarbeitung des Autologin-Tokens, wobei seltsam ist dass es in meinem Testblog nicht einmal auftrat. Da muss ich nochmal ran.

Die Installation war der letzte Schritt. Ich hatte ja gestern schon angekündigt, damit die Woche abschließen zu wollen. Was nicht völlige Inaktivität bedeuten soll, aber andere Projekte (Pipes!) kriegen erstmal wieder Priorität.

Das Upgrade auf die aktuelle Version funktionierte, was aber auch kein Wunder ist wenn der Upgrader fast keine Aufgabe durchführen muss. Allerdings begrüßte mich der Blog danach mit einer Fehlermeldung: Er konnte voku/simple-cache nicht laden. Ich hatte vergessen die aktualisierten composer-Dateien hochzuladen, dass das nötig ist war mir gar nicht klar. Schnell nachgeholt scheint erstmal alles zu laufen, wenn nicht wird sich das jetzt zeigen. Aber ich bin zuversichtlich, dass der Code jetzt mindestens reif für eine Beta ist.

Mir hat die Woche Spaß gemacht. Serendipity ist eben ein altes PHP-Projekt, mit allen Vor- und Nachteilen. Zu den Nachteilen gehören die vielen Workarounds für teils jahrealte PHP-Absonderlichkeiten und die Codestruktur und Qualität mancher Ecken im Kern, die dann eben den Standards von PHP-Projekten vor 15 Jahren entsprechen.
Aber die Vorteile zählen eben auch: Es ist ein stabiles und simpel gehaltenes Framework, das extrem aufs Bloggen ausgelegt ist, in dem sich manche Features erstaunlich komfortabel umsetzen lassen. Mit jeder neuen PHP-Version seit PHP 7 bekommen wir eine ganze Menge Verbesserungen der Sprache und in ihrem Ökosystem umsonst, die einzubauen und generell den Code zu verbessern ist lohnenswerte Arbeit. Auch haben sich meiner Meinung nach in den letzten Jahren viele Verbesserungen im Kern angesammelt, welche die Weiterentwicklung desselben, aber auch die Pluginentwicklung besser machen. Zusammengenommen ist die Arbeit an Serendipity derzeit besonders erfreulich. Ich kann jeden nur einladen, sich mal an einer neuen Funktionalität, einem Bugfix oder einem Plugin zu probieren.

Heute reichte es nur für eine kleine gestern überlegte Verbesserung der Mediendatenbank und ich muss mich beim Aufschreiben beeilen, um nicht in den letzten Tag der Entwicklungswoche zu rutschen.

IDs für Nicht-Bilder

Mindestens der aktuelle Code der Mediendatenbank könnte auch Links in Einträgen zu per Mediendatenbank eingefügten Dateien umbiegen, wenn diese umbenannt oder verschoben werden. Dateien meint hier Dateien im Gegensatz zu Bildern, denn bei Bildern geht das ja schon lange. Doch bisher wurden die Dateien ignoriert weil sie beim Einfügen keine ID mit in den Eintrag geschrieben bekommen haben. Das habe ich nun geändert und getestet, dass das Umbenennen tatsächlich den Link umschreibt.

IDs für das Podcast-Plugin

Die IDs für Audiodateien im Eintrag zu haben ist eine Voraussetzung für das Podcast-Plugin, das jetzt die ID auslesen und damit auf die Datei auf dem Server zugreifen kann. Ich habe den Code dafür nur angelegt und damit schonmal den Wrapper für den Player angepasst, das war vorher auf Übersichtsseiten wie der Hauptseite des Blogs noch kaputt. Der nächste Schritt wäre mittels der ID die Originaldatei auszulesen und so Informationen wie die Länge der Aufzeichnung ins Markup des Players aufnehmen zu können.

Unschön an dem ganzen ist, dass ich nach der Entwicklungswoche dann immer noch ein konkret anstehendes Serendipity-Projekt haben werde. Andererseits ist das Podcast-Plugin ganz spannend und ich glaube, dass es mit vertretbarem Aufwand in einen guten Zustand kommen kann. Morgen werde ich mich aber statt dem Plugin meinem Blog widmen, diese Installation auf die Alpha aktualisieren und schauen, ob es dort noch Probleme gibt.

Wie gestern habe ich an diesem Tag der Entwicklungswoche mit den bundled-libs angefangen, ungleich gestern habe ich mit einem Entwurf für ein neues Plugin aufgehört.

XML_RPC und PHP 7.2 war doch noch kaputt

Warum auch immer ich vorher keine Fehlermeldung bekam, das XML_RPC-Modul hatte noch andere Inkompatibilitäten als nur den veralteten Konstruktor von vorgestern. An drei Stellen wurde noch das genauso veraltete each benutzt. Leider ist die letzte Version upstream von 2011 und die Library mit einer anderen auszuwechseln wäre wesentlich mehr Arbeit als es das beim Cache war. Also habe ich einen Patch gebaut. Eine besser gepflegte Version wie phpxmlrpc einzubauen wäre schöner und ich hoffe, jemand anders macht das irgendwann. Mir reicht erstmal die Zeit dafür nicht.

Podcasts

Warum "nochmal Podcasts" wenn ich über Podcasts noch gar nicht sprach? Es ist ein lange geäußerter Wunsch von Dirk und anderen, der schon mehrmals an der Komplexität des Themas scheiterte. Wobei das Fehlen von podcastenden Entwicklern sicher auch nicht hilft, ich zum Beispiel habe nur wenig Ahnung was genau gebraucht wird.

Im Geiste der Woche habe ich diesmal trotzdem angefangen, so gut es eben geht. Herausgekommen ist das hier:

Man kann sich das auch anhören, ich habe vor dem Schreiben des Plugins einen Mini-Podcast über meine Ideen für dieses Plugin aufgenommen.

Was man im Screenshot nicht sieht ist das enclosure im RSS-Feed, aber das ist da. Ebenfalls nicht zu sehen ist etwas weniger erfreulicheres: Das Plugin hat ein konzeptionelles Problem. Weil die Mediendatenbank Audio-Dateien ohne ID in Artikel einfügt fehlt diese ID dem Plugin. Deswegen kann es bisher nur mit der URL arbeiten, es kann noch nicht die Audiodatei auf dem Server direkt anschauen. Aber wir können ja jetzt besprechen ob das wirklich nötig ist, dann würde ich morgen versuchen das im Kern umzubauen.

Wer das Plugin testen will kann sich den Quellcode auf Github anschauen und herunterladen. Es ist definitiv noch nicht fertig, aber wenn es fertig werden soll braucht es Feedback von Podcastern.

Heute war mein Einsatz ähnlich kurz wie gestern, aber gefühlt was es bisher einer der produktivsten Tage der Entwicklungswoche. Ich kam nämlich zum letzten Punkt meiner Agenda und konnte dort völlig überraschenderweise ein tolles neues Feature einbauen.

Smarty Pflichtupgrade

Aber erstmal zu Smarty. Im Forum hatte chris_goe eine seltsame Datei gemeldet, eine Verknüpfung, die upstream in das damalige Smarty-Release gerutscht war. Seitdem gab es sowieso neue und sogar Sicherheitsupdates beinhaltende neue Versionen. Also löschte ich das gesamte Smart-Verzeichnis und ersetzt es mit einem neuen Release, diesmal auch darauf achtend den Demo-Ordner zu entfernen. Der Commit ist leider unlesbar riesig, weil an irgendeiner Stelle automatisiert die Codeformatierung verändert wurde (ob bei uns im Code oder auf Seite von Smarty werde ich zwecks Ärgervermeidung nicht recherchieren). Immerhin funktioniert s9y mit der neuen Version weiterhin und scheinbar problemlos.

Ein besserer Cache

Smarty zu aktualisieren war Pflicht, nochmal den Cache anzugehen war eine Freude. Eigentlich wollte ich nur Cache/Lite ebenfalls aktualisieren, stolperte dabei aber über voku/simple-cache. Das ist ein mehrere Systeme unterstützender Cache-Layer: Tolle Optionen sind memcached und Redis. Und als Fallback dient OpCache, bei dem ähnlich wie mit Cache/Lite eine Datei erstellt wird. Gut, dazu gibt es nochmal ein Fallback, ein für uns unnützes nicht-persistentes Speichern im Array, aber OpCache sollte überall an sein.

Erst dachte ich "cool, aber wir haben ja schon Cache/Lite und das Projekt sieht etwas zu klein aus". Dann sah ich das:

Wir brauchen sowieso möglichst bald eine neue Cache-Lösung. Warum nicht jetzt? Also durfte voku/simple-cache per composer in die bundled-libs und ich stellte direkt den Code des internen Cache um (der übrigens bei den wenigen Plugins der Standardinstallation auf uberspace mit MySQL wenig bringt, dort ist die Datenbank schnell genug).

Eine aktiv gepflegte Cache-Library zur Hand zu haben ist nicht der einzige Nutzen. Sondern wir kriegen kostenlos die Funktion, Sachen in Memcached und Redis und damit im Arbeitsspeicher zu cachen. Das ist viel schneller als Speichern auf der Platte, egal ob in einer Datei oder Datenbank. Und besonderes interessant für mich: Es ist besonders attraktiv auf Scaleway-Servern und ähnlich langsamen Systemen mit viel verfügbarem Arbeitsspeicher.

Wieviel das bringt muss ich noch testen.

Damit habe ich alle im Vorhinein geplanten Themen der Woche durch. Robert hat sich einen Blick auf die XMLRPC-Schnittstelle für die Editoren gewünscht, davon habe ich aber keine Ahnung und würde vielleicht etwas anderes vorziehen.
Gibt es denn sonst noch Wünsche für die letzten drei Tage?

Heute wird es etwas kürzer als gestern, jedoch konnte ich die Entwicklungswoche fortführen.

XMLRPC und PHP 7.2

Bernd hatte schon eine Weile den deprecated Konstruktor von XMLRPC gemeldet.

Ich bin mir nicht 100% sicher warum ich die Fehlermeldung nicht gesehen habe. Meine Vermutung: Die Library wird nur eingebunden, wenn ein Pingback gesendet oder empfangen wird, also sieht man die Meldung nur als Fehlermeldung wenn man einen Pingback verschickt. Und das passiert nur wenn der Trackback scheiterte, was nur selten vorkommt.

Wie auch immer, ich habe den Konstruktor jetzt einfach wie von modernen PHP-Versionen gefordert auf __construct umgestellt.

Cache

Danke für die Kommentare zum Artikel gestern. Der Cache des Entryproperties-Plugins ist nun standardmäßig aus und folgt damit der üblichen, von euch definierten Praxis. Dafür wird der interne Cache bei der Installation nun aktiviert.

Das VGWORT-Plugin ist auf meinem Server nun in der aktuellen Version, und trotzdem wird anders als im Testblog die Zeichenanzahl in der Eintragsliste nicht angezeigt. Stellt sich raus, dass ich dafür einen neuen Event backend_view_entry eingeführt hatte der schlicht noch nicht in der hier laufenden Serendipity-Version 2.1.4 drin ist. Am Ende der Woche werde ich diesen Blog aktualisieren.