21

Dieser Text ist länglich, und befasst sich nicht mit Spechten!

Menschliche Artefakte in diesem Forum

Wir haben hier schon lange eine etwas unlogische Situation: Während wir bei den Landschaften Bilder mit Gebäuden oder manchmal auch Booten oder Schiffen darauf oft ablehnen, akzeptieren wir Bilder, auf denen ein Greifvogel auf einem Pfahl sitzt, auch wenn der Pfahl oft eine größere Fläche einnimmt als das Gebäude es getan hätte.

Ich denke, wir verstehen alle, warum das so ist - nämlich dass sich der Vogel dahin gesetzt hat, und den Ansitz damit "geadelt" hat.
Wir akzeptieren da die Entscheidung des Vogels, der sich über die "Natürlichkeit" (16) seines Ansitzes keine großen Gedanken gemacht hat. Wir akzeptieren nicht die Entscheidung eines Fotografen, der sich möglicherweise viele Gedanken über den Bildausschnitt gemacht hat.

Richtig nett ist das nicht, und ich kann verstehen, dass manche Benutzer ziemlich sauer reagieren, wenn man ihre Bilder in die Rubrik für Unerwünschtes verschiebt.

Davon abgesehen ist es auch nicht richtig logisch, und man braucht eine gewisse Logik, wenn man Regeln formulieren will, zum Beispiel Regeln darüber, was wir hier akzeptieren.

Nun haben wir von administrativer Seite die Frage, welche Bilder wir hier akzeptieren, in letzter Zeit etwas lockerer gesehen. Wohin das führt, kann man gut in Mensch und Natur sehen, wo doch Einiges zusammengekommen ist, dass nicht so recht in die Rubrik passen will. Wie es mit der Rubrik weiter geht? Ich weiß es noch nicht, das wird noch diskutiert.

Ich könnte mir vorstellen (wertet das bitte nicht stärker), dass wir in M&N in Zukunft nur noch Bilder mit entweder klar erkenntlichem Bezug zum Spannungsfeld Mensch/Natur akzeptieren, oder solche, bei denen das aus der Beschreibung _klar_ hervorgeht.

So versteckt wie diese zwei Kaninchen sollte der Bezug zum Thema bei Bildern in Mensch und Natur nicht sein.
Ja, da sind zwei Kaninchen.

Aber was machen wir mit dem Rest? Für den haben wir bisher so eine Art Müllrubrik ("Administrativ unerwünscht"), deren Inhalte man kaum noch finden kann (schon gar nicht, wenn man kein Admin ist). Da finden sich Bilder mit als zuviel empfundenen menschlichen Artefakten neben Ziegen, die den Sonnenaufgang betrachten, oder Fohlen, die toben. Auch Hunde und Katzen… ach ja, und dann und wann richtigen Schrott. So manche Bilder darin sind übrigens richtig gut, nur thematisch unpassend.

AU, wie die Rubrik in Kurzform heißt, ist ein hartes Urteil: Ein Admin oder Moderator hat das Bild gesehen, und für unwürdig erachtet. Nun könnte der Autor dagegen andiskutieren, und das passiert auch manchmal. Aber nicht oft… was manchmal daran liegt, dass das Urteil einfach akzeptiert wird, aber sicher ebenso oft daran, dass man alleine gegen eine oder mehrere "Autoritäten" diskutieren müsste, was, ganz vorsichtig gesagt, nicht richtig attraktiv ist. AU unterbindet jede Möglichkeit, dass sich andere ein Bild über das Bild machen. Und das ist nicht gut (um nicht eine deutlich härtere Sprache a la "großer Mist" zu verwenden), immerhin ist das hier nicht ein Präsentations-, sondern ein Diskussionsforum, auch wenn wir das manchmal aus den Augen verlieren.

So bitte nicht.

Ein ins Wasser gefallener Baum, den ich aufgrund der Sichtverhältnisse niemals ganz hätte ablichten können. Ein paar Monate später wird die Ecke voller Jungfisch gewesen sein.
Dass das vorkommt, ist ganz natürlich. Aber an diesem Baggersee passiert es zu oft, die Ufer sind einfach instabil.

Meine Fotografie in 2017

Die Bilder, die ich hier zeige, stammen alle aus 2017. Aber das war fast meine ganze Ausbeute (von "Taunus im Nebel" gibt es noch viel mehr, aber mehr Nebelbilder verträgt dieser Text nicht).

Ja, das war wenig.

Gänse? Die habe ich am Anfang des Jahres in Ruhe gelassen, ich weiß nicht mehr warum. Kröten und Frühblüher? Fielen der verletzten Hand zum Opfer. Wie übrigens auch so einige freie Zeit, die ich zum Programmieren hätte nutzen können.

Tauchen/Schwimmen? Erst die verletzte Hand, dann so richtig miese Sicht, dann später wieder eine Verletzung, und dann war ich noch beruflich weit weg von hier, in einer Gegend ohne offensichtlich auch nur halb attraktive Gewässer. So kann das nichts werden.

Immerhin, ich hab' ein paar Karpfen gesehen. Und einen Mini-Schwamm. Die Bilder waren Speicherplatzverschwendung.

Eine paar Mal Schildkröten beim Sonnen auf dem Ast. Und einmal eine unter Wasser - in der trüben Brühe, in schneller Bewegung

Aber ein paar Landschaftsaufnahmen waren dabei. Und Katzen. Sogar ein Kaninchen.

Ich wollte jetzt im Dezember Gänse fotografieren. Wann immer so etwas wie eine Spur Blau am Himmel war, konnte ich gerade nicht. Wobei das Licht vermutlich sowieso schon wieder weg gewesen wäre, bis ich nur zur Haustüre herausgekommen wäre. Was für ein Mistwetter…

Das wird besser werden. Die Fotografie, und auch das Wetter. Letzteres natürlich erst in einer gefühlten Ewigkeit.

Gehäuse einer Köcherfliegenlarve. Sie hat es verlassen, um über Wasser für den Fortbestand der Art zu sorgen.

Ein paar Gedanken zur Forumssoftware

Ich arbeite seit nun seit 2006 an dieser Forumssoftware (die paar Jahre 4images vorher zählen dafür nicht).

Damit habe ich für mich ein paar Rekorde gebrochen:

• das Projekt ist größer als alle Anderen, an denen ich außerhalb des
  Berufes gearbeitet habe, und auch größer als die meisten, mit denen
  ich beruflich zu tun hatte (da dürfte nur Eines größer gewesen sein),
• ich habe noch nie ein Softwareprodukt so lange gewartet,
• und ich habe mich noch nie in einer Spätphase eines Projektes so sehr
  darüber geärgert. Das liegt auch am Produkt von Zeit und Projektgröße, denn
  Vieles würde ich heute so nicht mehr machen, entweder weil ich gelernt
  habe oder weil es heute bessere Wege gibt.
  
  Aber es liegt nicht nur an Zeit x Codezeilen. Ich komme darauf noch mal zurück.

Fundamentale Änderungen an Programmiersprachen

Zuerst mal sind die meisten Techniken, die in der Branche Jahr für Jahr begeistert gefeiert werden, weit weniger wert als die Werbung dafür glauben machen will.

Und das trifft in besonderem Maße auf Techniken zu, die bereits vorhandene, aber irgendwo mangelhafte, Programmiersprachen aufhübschen sollen, in dem Sprachfeatures nachgerüstet werden, den den Charakter einer Programmiersprache ändern (dies geht also nicht gegen Verbesserungen an sich).

Als die Gebrüder Wright auf den Gedanken kamen, einen Motorflieger zu bauen, haben sie doch nicht Flügel an ein Auto gehängt, nur weil Autos Motor, Räder und Sitze haben. Nein, die waren smarter.

Ich möchte dafür zwei Beispiele anführen.

Taunus, Panorama. Wirkt nicht? Ja, manche Bilder müssen groß sein.

Beispiel 1: Promises

So weit, so gut.

Nur ist realer existierender älterer Javascript-Code meistens, vielleicht bei größeren Projekten sogar immer, so angelegt, dass er den Nutzen von promises beschränkt oder ganz aufhebt.

So zuletzt gesehen in realem Code, der versucht hat, ein paar Daten aus dem Netz zu laden, und wenn das nicht geklappt hat, versucht hat, mit alten Daten weiterzumachen, wenn sie denn da waren (da wurde eine Karte aufgebaut, und im Notfall sollten dann weniger detaillierte Daten, die schon da waren, hoch interpoliert werden).

Das Ganze fiel auf die Nase, weil irgendwo in dem schönen neuen Code dann eine alte Funktion aufgerufen wurde, die eine Ausnahme warf, (so eine Art Fehlermeldung, die man unbedingt abfangen muss).

Leider hat wohl niemand auf dem Schirm gehabt, dass es alten Code gibt… und prompt fiel die Fehlerbehandlung übel auf die Nase und hinterließ eine halb gezeichnete Karte.

Die Fehler an der Stelle _richtig_ abzufangen war dann kompliziert und keineswegs mehr schön.

Zum Weglaufen... Vor dem Fotografen natürlich.

Beispiel 2: Exceptions in PHP

Am Beispiel von intdiv, einer relativ neuen Funktion zur Division zweier Ganzzahlen (3/2 liefert 1, nicht 1.5). Die Funktion ist also wirklich trivial, was die im Folgenden geschilderten Eigenwilligkeiten nur noch unverständlicher macht.

        Return Values
                The integer quotient of the division of dividend by divisor.
        Errors/Exceptions
                If divisor is 0, a DivisionByZeroError exception
                is thrown. If the dividend is PHP_INT_MIN and the
                divisor is -1, then an ArithmeticError exception
                is thrown.
  

Soll heißen, intdiv(N,0) ist ebenso verboten wie intdiv(PHP_INT_MIN,-1), und in beiden Fällen wird eine Ausnahme gemeldet. Für alle anderen Fälle wird der Quotient zurückgegeben.

Das heißt, der Aufruf soll ungefähr so aussehen:

        try {
                print intdiv($a,$b);
        } catch (Exception $e) {
                ... hier Fehlerbehandlung.
        }

Ich soll zum Punkt kommen? Na gut. Aber nicht zu schnell, erst einmal etwas "Spaß" am Rande:

 
        Eingabe:
                $a=PHP_INT_MIN-1;
                print "intdiv $a/7 is: ".var_export(intdiv($a,7),1)."\n";
        Ausgabe:
                intdiv -9.2233720368548E+18/7 is: -1317624576693539401

Ganzzahldivisionen von Fließkommazahlen sind also erlaubt. Kein Schönheitspreis für die PHP-Entwickler (dass INT_MIN-1 plötzlich zum Fließkommawert wird, bekommt auch keinen).

Und dass das Ergebnis vielleicht nicht ganz das ist, was man erwarten würde, wenn man INT_MIN durch 7 teilt, liegt einfach daran, dass PHP_INT_MIN tatsächlich INT64_MIN ist.

Modifizieren wir das ein bissel…

 
        Eingabe:
                $a=PHP_INT_MAX+1;
                print "intdiv $a/7 is: ".var_export(intdiv($a,7),1)."\n";
        Ausgabe:
                PHP Warning:  intdiv() expects parameter 1 to be integer, float given in - on line 1
                intdiv 9.2233720368548E+18/7 is: NULL

Mit einer schönen, großen, _positiven_ Fließkommazahl geht es aber nicht. Ah ja. Soviel zum Thema Konsistenz.

Aber Inkonsistenz ist nicht, worauf ich hinaus will. Nach 13 Jahren PHP wäre Konsistenz eine Überraschung.

Nein, ich will auf die NULL in der letzten Ausgabezeile hinweisen. Laut Dokumentation kann die gar nicht kommen.

Jetzt könnte man sagen, die Dokumentation ist schlecht, und ja, die PHP-Dokumentation ist oft genug schlecht. Auch hier. Aber nicht das ist hier das Problem, sondern dass die PHP-Interna derartig unübersichtlich sind, dass die Entwickler schon nicht mehr sehen können, was _triviale_ Funktionen so tun. Der Entwickler, der den Code geschrieben hat, wusste gar nicht, was in dem Drumherum um seine paar Zeilen Code passiert.

Was jetzt dazu führt, dass man, um die Funktion benutzen zu können, das tun muss:

        try {
                $tmp = intdiv($a,$b);
                if (NULL === $tmp) {
                        ... hier Fehlerbehandlung.
                }
        } catch (Exception $e) {
                ... hier noch eine Fehlerbehandlung.
        }

Herzlichen Glückwunsch - wir haben hier das "Beste", was man sich vorstellen kann, doppelte Fehlerbehandlung für eine triviale Funktion.

Kaninchen. Eine ganze Gruppe war an dem Tag wie im Paarungsrausch.

Die grundlegende Ursache des Problems ist, dass die PHP-Interna noch genug Stellen haben, und auch haben müssen, an denen sie keine Ausnahmen liefern, sondern andere Fehlersignale, und dass neuerer Code des PHP-Interpreters an allen Ecken und Enden darauf achten muss, wie der die Fehlersignale, die ältere Funktionen liefert, übersetzt.

Warum passiert das nicht?

• weil Fehlerbehandlung grundsätzlich unsexy ist. Das wird nebenher
  gemacht, weil es sein muss. Nicht mehr. Das ist ein grundlegendes
  Problem in der EDV. Und eines, das durch den Gebraucht von Exceptions eher schlimmer wird, weil die dazu verleiten, Fehlerbehandlung auf eine höhere Ebene abzuschieben, was in vielen Fällen gleichbedeutend mit dem Ignorieren der Fehler ist, wenn man auch ein reineres Gewissen hat.
• und weil man, im Fall von PHP, viel über die Interna wissen müsste,
  um solche Fehler zu vermeiden - und überhaupt auf die Idee zu kommen,
  dass sie auftreten könnten, und man die Funktion dagegen schützen muß.
  

Diese Sorte von Fehlern wird PHP noch über Jahre liefern, und das
wird ein großes Vergnügen für alle Betroffenen.

Das möchte man im Wasser nicht sehen, schon gar nicht noch näher kennen lernen, aber darauf nehmen zu viele keine Rücksicht.

PHP an sich

Wenn man mit circa einer Million kleiner und großer Inkonsistenzen leben kann, kann man mit PHP arbeiten - und einige Teile des PHP-Ökosystems, speziell einige der Standard-"Erweiterungen" (wenn es mitgeliefert wird - warum nennt man es dann 'Erweiterung'?), waren und sind richtig gut und zuverlässig, was so manches ausgeglichen hat.

Und ohne richtig guten Grund sollte man Code nicht neu schreiben - oder verschiedene Sprachen mischen. Überflüssigerweise Code anzufassen, der funktioniert, ist eine Garantie für neue Fehler, und verschiedene Sprachen zu mischen, na ja, stellt euch eine Zeitung vor, in der jeder Absatz in einer anderen Sprache geschrieben wurde.

Dann kam vor ziemlich genau Jahren PHP Version 7. Damit ist nun vieles besser geworden. Oder?

Sicher, einiges ist besser geworden. Die Performance wird gerne angeführt, und das war hier im Forum auch deutlich spürbar. Etliche Inkonsistenzen in der Syntax sind weg, und das ist ein Segen, nutzt aber älterem Code erst mal gar nichts. Und das Forum _ist_ älterer Code.

Aber das PHP-Ökosystem gammelt vor sich hin.

Kassiopeia, gammelt nicht.

PEAR gammelt vor sich hin

Auf _dem_ System, auf dem Erweiterungen gesammelt werden (Pear), ist nichts von dem, was ich brauche, oder was mich interessiert hat, für PHP 7 verfügbar.

Das ist gar nicht gut, insbesondere weil es auch Pakete betrifft, auf die von den PHP-Webseiten verwiesen wird, die also schon irgendwie offiziellen Charakter haben.

Ich habe mir das jetzt zwei Jahre angesehen, und ich sehe keine Besserung in irgendeiner Hinsicht. Und das stört mich gewaltig.

Wobei ich den beiden Entwicklern, die sich um Pear kümmern (ja, es sind nur zwei - wenn nicht gar, wie der eine behauptet, nur 1,5) keinen Vorwurf machen möchte. Versagen tun da Andere.

Twister, gammelt auch nicht.

Die Dokumentation rottet vor sich hin, Teil 1

        PHP 7.2.0 comes with numerous improvements and new features such as
        [...]
            New sodium extension

Offensichtlich ist der ganzen Menschheit klar, das Sodium nicht Salz ist, sondern eine Kryptografie-Bibliothek (sonst würde es da ja stehen). Die Annahme würde ich so nicht gemacht haben, aber sei's drum.

Gucken wir uns doch mal die Dokumentation zu dieser Bibliothek an, und zwar die zur Funktion crypto_auth_keygen (so heißt sie in libsodium, der Grundlage der PHP-Sodium-Erweiterung) oder sodium_crypto_auth_keygen (so heißt sie in PHP):
pre]
sodium_crypto_auth_keygen

(PHP 7 >= 7.2.0)

sodium_crypto_auth_keygen — Description

Description
ReturnType sodium_crypto_auth_keygen ( void )

Warning
This function is currently not documented; only its argument list is available.

Aha. Jetzt weiß immerhin mehr als vorher - nämlich dass das nicht zur Benutzung gedacht ist.

So sind übrigens alle Funktionen dieser Erweiterung "dokumentiert".

_Erfahrungsgemäß_ wird das binnen eines Jahres dokumentiert sein. So halbwegs jedenfalls. Also so, dass man sich den Rest aus der
libsodium-Dokumentation zusammenreimen kann.

Falls man denn bereit wäre, sich die Dokumentation für kryptografische Funktionen zusammenzureimen, meine ich. Wozu niemand bereit sein sollte.

Die Dokumentation rottet vor sich hin, Teil 2

So basieren crc32("abc") und hash("crc32b", "abc") auf dem AUTODIN II Polynom (Ethernet), während hash("crc32") das ZModem-Polynom verwendet.

Der Umgang mit gemeldeten Fehlern

Was den Umgang der PHP-Entwickler mit gemeldeten Fehlern betrifft, möchte ich eigentlich darüber lieber nichts sagen, weil es mir im Moment echt schwer fällt, auf sehr deutliche und nicht jugendfreie Ausdrücke zu verzichten.

Ich lasse mal das aktuellste Beispiel weg, weil ich mich darüber noch so gar nicht beruhigt habe, und nehme mal ein etwas Älteres, https://bugs.php.net/bug.php?id=70419 .

In Kurzform:

1. Ich melde am 3.9.2015: zwei Funktionen haben unbrauchbare
   Rückgabewerte, die verhindern, dass man im Fehlerfall erfahren kann,
   wie sich die aufgerufenen Programme beendet haben. (Ich halte das
   für sehr problematisch).
   Das war noch vor dem PHP7-Release, und hätte, wenn man denn gewollt
   hätte, darin geflickt werden können.
2. Das Ganze gammelte bis zum 25.8.2016 herum. Dann:
3. "Es ist jetzt zu spät für 7.0. Also müsste diskutiert werden ob
   das in 7.2 rein kann oder auf 8.0 warten muss. Ein 'PR' *könnte*
   helfen, die Diskussion zu starten."

   Hey, ich dachte, das, was ich die geschrieben hatte, wäre ein PR.
   Ach so, _könnte_. Ja, klar.

• https://bugs.php.net/bug.php?id=67383
• https://bugs.php.net/bug.php?id=63185
• https://bugs.php.net/bug.php?id=67087

Ich habe so eine Ahnung, woran das liegt: Für jede noch so kleine Änderung am Verhalten muß man eine Diskussion in php-internals durchhalten und meistens auch noch einen RFC dort verfassen - und nebenher den Code schreiben.

Für Bugfixes macht das keiner. Schon gar nicht, wenn man sich verarscht vor kommt.

Liebe Entwickler von Open Source Projekten, und das bezieht sich jetzt wirklich nicht nur auf die PHP-Leute: verarscht mich nicht. Wenn ich mir schon die Mühe gemacht habe, einen Fehler von euch zu finden und die Ursache zu bestimmen, und euch auch noch Bescheid sage, dann erwartete ich wenigstens Respekt für diese Arbeit. Aber nicht "wir haben es jetzt ein Jahr liegen lassen, schreib' noch mal".

Retrospektive, Teil 1

Der Zustand der verwendeten BBCode-Library ist jedenfalls nicht besser geworden. Da hat sich einfach nichts getan, und das Risiko ist ziemlich groß, dass sie nicht aktualisiert wird, wenn sich die PHP-Internas das nächste Mal ändern. Mit anderen Worten: Die kann mit jedem größeren Update unter den Tisch fallen, und da müsste eine Alternative her, die eben die vielen alten Texte verarbeiten kann.

Leider sind die üblichen, in PHP geschriebenen Interpreter allesamt in einem der kritischen Fälle extrem langsam - oder haben einen geradezu lächerlichen Speicherbedarf. Alle Getesteten sind ausnahmslos unbrauchbar.

Es sieht so aus, als brauchte ich diese Bibliothek noch eine ganze Weile, und eine Option wäre, sie selbst zu flicken, sobald es denn nötig ist, und es kein Anderer tut. Leider hieße das, sich in die PHP-Internas einzuarbeiten, und das _will_ ich nicht.

Ganz und gar und überhaupt nicht. So wie PHP nach draußen wirkt, also ohne jede logische Struktur, so wirken auch die Interna auf mich, auf den ersten und zweiten Blick jedenfalls. Damit ich mich damit weiter beschäftige, muss ich bezahlt werden.

An der Stelle haben sich meine Überlegungen eine ganze Weile im Kreis gedreht. Monate, um genau zu sein: 7 Monate von Mai bis Dezember.

PHP und das Forum

Mein Unmut über PHP ist über die Jahre gewachsen. Dennoch _kann_ man damit arbeiten. Man braucht, insgesamt, für viele Sachen mehr Zeit als mit anderen Sprachen, aber das rechtfertigt nicht, dass ganze Projekt neu zu schreiben (wir reden hier von gefühlten Ewigkeiten meiner Zeit, und einer
gefühlt unendlich großen Zahl von Möglichkeiten, neue und alte Fehler einzubauen).

Die Entscheidung, trotzdem alledem mit PHP weiter zu machen, habe ich zum ersten Mal bewusst in 2005 getroffen. Damals waren um die 20000 Zeilen Code und HTML im Repository, heute sind es locker 130000 (plus noch Einiges, was hoffentlich nirgendwo mehr im Einsatz ist, was ich aber aus Rücksicht auf andere Nutzer nicht einfach rauswerfen kann).

Das wäre natürlich ein Grund, mit PHP weiter zu machen.

Auf der anderen Seite ist das Projekt nun ziemlich alt, und schleppt einigen Ballast mit sich herum, den man neu schreiben _müsste_.

• 
  Da ist die Template-Engine. Ja, die ist immer noch verdammt schnell,
  aber man sieht ihr das Alter zu sehr an, und sie ist auch zu eigen,
  als dass Andere damit arbeiten könnten. Sie auszuwechseln ist möglich,
  aber dann schreibe ich nicht nur die Templates neu (das wäre ein gutes
  Werk), sondern auch viel vom aufrufenden Code (auch ein gutes Werk,
  wenn man dabei aufräumt).
• Dann wäre da die BBCode-Bibliothek, die man austauschen müsste.
• Dann müsste ich das Rechtesystem von ein paar Altlasten befreien (kann
  dem Code nicht schaden, und wäre auch ein gutes Werk).
• Dann müsste ich den Cache-Layer um die Objektverwaltung mal neu machen
  (da könnte man viel Zeit einsparen, wenn man ein paar hundert Kilobyte
  shared memory opfert), und eventuell auch den Cache für die größeren
  Sachen vereinheitlichen (also Seitenbestandteile, Datenbankabfragen,
  ...). Das wäre auch ein gutes Werk.
• Dann müsste ich mal den Startup-Code reduzieren. Wie auch immer, aber
  irgendwie muss ich von 6 Millisekunden, die der im Idealfall frisst,
  runter kommen. 6 Millisekunden klingt nach wenig? Für eine normale
  Seite fällt es auch nicht ins Gewicht. Für Ajax-Kram dagegen schon. Und
  ich nicht mehr, wie ich den Startup-Code reduzieren kann. Da läuft
  nichts mehr, was ich nicht brauche, und es wird bereits gecacht, was
  irgendwie gecacht werden kann.
• Dann müsste ich… da gibt es noch vieles. Viele Aufräumarbeiten, um
  Konsistenz in den Code zu kriegen (alter Code benutzt neue Möglichkeiten
  nicht… das ist zwar logisch, macht aber den Durchblick nicht leichter).
  

Wenn man an der Stelle steht, lohnt es sich doch, mal nachzudenken, ob man nicht etwas größer denken sollte.

Das habe ich die letzten paar Monate gemacht. Und experimentiert. Und festgestellt, dass mich die Javascript-basierten Frameworks anekeln, weil ich Javascript und seine Abarten verabscheue. Ich werde nicht um JS herum kommen, aber ich muss die Zeit, die ich damit verbringe, nicht auch noch maximieren.

Übrigens ist meine Meinung über die meisten Frameworks negativ. Die meisten wollen eine perfekte Lösung für ein Problem sein, aber keines von Ihnen ist es. Wenn mir ein Framework Hindernisse in den Weg legt, weil meine Idee, wie man die Dinge tut, nicht zum Framework passt… sagen wir, ich habe nicht umsonst Schraubendreher in verschiedenen Größen, mal Schlitz, mal Kreuz - und nebenbei noch Zangen und Hämmer und…

Rust? Ganz nett, ja, aber mit Sprachen mit komplexen Syntaxen bin ich noch nie lange glücklich gewesen. Ease of use, und so.

Dann stolperte ich über Go. So a la "Stimmt, das gab es ja auch noch. Hm.". Und hab' angefangen, die ersten Funktionen dahin
auszulagern. Ich schätze, als nächstes kommt der Datenbanklayer. Und dann der Objektcache. Und dann BBCode. Und dann das Rechtesystem.
Und dann…

Vielleicht schreibe ich zwischendurch noch irgendwann das Linux-ZModem darin neu. Nach 20 Jahren Stillstand sollte man das mal in Erwägung ziehen.

Retrospektive, Teil 2

Ich hatte mir für dieses Jahr etwas fest vorgenommen, nämlich das:

Ich hatte mir davon Einiges erhofft, und fast nichts davon ist eingetreten. Die minimale Performanceverbesserung - ja. Aber was nutzt es, wenn an einer unkritischen Stelle eine von zwei Millisekunden entfällt? Es wäre etwas Anderes, könnte ich diese Millisekunde im Startup-Code des Forums einsparen, aber im Browser?

Das Ajax-Geraffel ist jetzt besser lesbar. Das ist eine Verbesserung. Aber
weil die Fehlerbehandlung deutlich komplizierter wurde, als ich das
anfangs geahnt hatte, ist der Code immer noch nicht richtig gut.

Flexibler ist es auch geworden, aber da habe ich feststellen müssen, dass ich überschätzt habe, wie viel Flexibilität ich brauche. Der Fall, für den ich optimiert habe, tritt in der Praxis so gut wie gar nicht auf. Das hätte ich doch vorher wissen können… oder?

Leider hätte ich mir das tatsächlich denken sollen. Habe ich aber nicht, und so habe habe ich jetzt wieder ein Stückchen überkomplizierten Code geschrieben. Hm.

Auf der anderen Seite war es wirklich eine gute Idee… theoretisch. Die Praxis ist so feindselig gegenüber guten Ideen…

Auch die andere gute Idee, die ich an dieser Stelle hatte, scheiterte ähnlich:

Sie war, ein paar Netzwerkanfragen einzusparen, in dem man Anfragen an andere Anfragen dran hängt. Das ist insbesondere deshalb sinnvoll, weil die eigentliche Bearbeitung der Antworten nur ein paar Millisekunden kostet, aber die Netzwerklatenz so im Bereich von 100 Millisekunden liegt - und dafür dann ein oder mehrere Anfragen vorzuziehen, von denen ich sicher weiß, dass sie erfolgen werden.

Theoretisch ist das das eine gute Idee. Und der erhoffte Effekt ist auch _messbar_ eingetreten. Fühlbar ist das allerdings nicht (und das war das Ziel). Im Gegenteil, fühlbar hat sich die Sache verschlechtert. Vorher war es so, dass sich eine Information alle 15 (ein Beispiel) Sekunden aktualisiert hat. Nach der Änderung hat sie sich nach 15 oder auch 10 Sekunden aktualisiert, und das fühlte sich verstörend unregelmäßig an.

Im Nachhinein ist das sonnenklar. Das hätte es auch im Vorfeld sein können, wenn ich das Problem mal von der anderen Seite aus betrachtet hätte.

Unter Beobachtung

Eine kurze Betrachtung zu Fragen der Privatsphäre…

Datenschutz im Falle transnational verbreiteter Daten:

1. 
   Sobald Daten an ein anderes Land weitergegeben werden, ganz egal ob Peru oder die Vereinigten Arabischen Emirate, kann man nur noch _glauben_, dass die dort so behandelt werden, wie es die Datenschutzgesetzes des Ursprungslandes der Daten erlauben.
   
   Man kann es nicht _kontrollieren_.
   
2. Und für den Fall, dass die Daten plötzlich ihren Weg in Hände finden, in denen sie nichts zu suchen haben, kann man nicht einmal klagen, denn zum einen enthalten diese internationalen Abkommen meist Klauseln, die Klagen in Bagatellfällen ausschließen (und die Definition von 'Bagatelle' ist hier durchaus nicht kompatibel mit dem Schaden für einzelne Menschen), zum Anderen ist der Gerichtsstand nicht da, wo er hingehört (ein reguläres Gericht des Ursprungslandes, _nicht_ aber eines des Ziellandes - und schon gar kein internationales Schiedsgericht), und zum Dritten kann man Daten nur selten ansehen, wer sie verkauft hat.
3. Aus Daten gewinnt man Informationen, Informationen sind Macht, und Informationen sind Geld wert.
4. Die Möglichkeit der Kontrolle und die Möglichkeit der Klage sind _alles_, was zwischen den Daten und ihrer illegalen Ausnutzung steht.

Mit anderen Worten: Daten, die erst mal die Grenzen der eigenen Gesetze verlassen haben, sind derzeit Freiwild.

Taunus im Nebel

Die Browser:

Sie werden auch durch Programme gefährdet, die wir Tag für Tag laufen lassen. Sagen wir mal Firefox (https://drewdevault.com/2017/12/16/Firefox-is-on-a-slippery-slope.html). Mozilla hat das nach einen Shitstorm schnell wieder abgestellt, aber so etwas (Zwangsinstallation von fremdem Code unbekannter Herkunft) _macht_ man gar nicht erst.

Wie kommt man auf eine solche Idee? Waren da Dollar-Zeichen in den Augen, oder waren da Gehirne wegen spontaner Lobotomie nicht mehr zurechnungsfähig?

Und warum entsteht Nutzern dieses Programmes (und Anderer Programme) Schaden, ohne dass das irgendwelche Konsequenzen hat? Was läuft da falsch, dass leichtfertige Verantwortungslosigkeit ausgesessen werden kann? Ist es, weil der Schaden nicht quantifizierbar ist? Warum nimmt man dann Null an, nicht Unendlich? Ist es, weil nicht zweifelsfrei belegbar ist, wer schuldig ist? Warum in aller Welt lassen wir Microsoft, Ubuntu, Firefox, Google und Co damit durchkommen, dass man auf diesen Systemen überhaupt nicht nachvollziehen kann, was wann warum geschehen ist?

Und dann ist da noch… ja, genau, Google Chrome. Google, das größte Werbeunternehmen der Welt ist. Genug gesagt?

Vielleicht nicht. Ein Browser hat jede Menge Daten - über das Verhalten des Benutzers. Und Google liebt Daten. Alleine das wäre, in einer vernünftigen Welt, ein Grund, diesen Monsterkonzern zu zerschlagen (aber dies ist keine).

Ich will hier jetzt nicht übermäßig meckern, aber wieso trauen wir diesen Programmen?

Warum erschießen wir nicht mal ein paar Verantwortliche, damit die Nächsten ins Grübeln kommen? (für den Fall, dass das nicht klar sein
sollte: Das war eine Überspitzung. Und ich habe keine Schusswaffen. Weil die Jahreszeit für unpassende Geschenke ist: Ich will auch keine. Die Dinger gehören nicht in meine Hände. Und Deine. Und… verstanden?).

Taunus immer noch im Nebel

Die Webseiten:

Und ich will hier nur _eine_ Seuche ansprechen - die meiner Meinung nach Schlimmste, die Einbindung von Inhalten und Bibliotheken auf Servern Dritter.

Vielleicht sollte ich das umformulieren? "veranlassen die Browser, Bewegungsdaten der Benutzer an den weltgrößten Werbekonzern zu senden." Denn das ist es, was passiert.

Am Beispiel von Google Maps: Bei jeder Darstellung einer Karte sendet der Browser die Kennung der Seite an Google (die meldet sich auf diese Art über den Browser des Benutzers an). Zusammen mit der unvermeidlichen IP-Adresse und der Uhrzeit kann man daraus, insbesondere wenn man noch andere Dienste anbietet, ein wunderbares Bewegungsprofil machen. Ein sogenannter Fingerabdruck des Browsers (https://www.heise.de/newsticke [verkürzt] -auch-ohne-Cookie-3597078.html , https://amiunique.org/faq) ist auch hilfreich, klar.

Und wenn jemand glaubt, dass Google das nicht täte, dann irrt er (dito für die anderen Datenkraken).

Der Kartendienst ist längst nicht der einzige Datensammeldienst, den Google aus purer Gutherzigkeit (?) betreibt.

Da wären beispielsweise ajax.googleapis.com (darüber werden Javascript-Bibliotheken ausgeliefert) oder der Schriftartendienst fonts.google.com.

Das Ziel dieser so kostenlosen Dienste ist es, möglichst viele Bewegungsdaten zu bekommen. Und aus denen möglichst gute Profile zu gewinnen - um zielgerichtet Werbung zu liefern.

Taunus im Nebel 3

Profile:

Bald werden sie gut genug sein, für die Mehrzahl von euch zielgerichtete Werbung auf den Monitoren an der U-Bahn-Haltestelle einzublenden. Wie peinlich wird es sein, wenn für den Mann auf der einen Bank Werbung für ein Nobelrestaurant gezeigt wird, für Dich aber McDoof? Sie eine Galapagos-Reise mit allen Extras, Du Malle?

Ihr meint, das wird keiner wollen? Doch. Werbung funktioniert besonders gut, je genauer man das Ziel trifft. Das ist in der virtuellen Welt so, und es ist auch in der realen Welt so.

Und glaubt ja nicht, dass das nicht geht. Unsere Smartphones liefern physische Bewegungsdaten. Smartphones und größere Computer liefern virtuelle Bewegungsdaten. Das zusammen zu setzen ist keine Kleinigkeit, aber mit entsprechendem Aufwand machbar. Und der Aufwand _wird_ betrieben (jetzt, nicht erst in Zukunft).

Dass in diesen zusammengesetzten Daten noch euer Name und die Adresse fehlt, ist ein Feigenblatt, hinter dem sich die Branche gegen die Datenschutzgesetze versteckt. Aber mehr ist es auch nicht.

Facebook hat euren Namen. Google hat euren Namen. Hundert Andere haben euren Namen.

Und die Adresse? Da braucht man doch nur bei der Post fragen - die betreibt für ihre "Partner" eine Dienst zum Säubern von Adressen. Und diese Partner zeichnen sich dadurch aus, unverlangt Briefkästen vollzumüllen.

Wir stehen nun kurz davor, dass es diese perfekten Profile gibt.

Taunus im Nebel, 4

Datenschutz und Privatsphäre, Finale:

Dieses Wissen für die gewinnversprechendste Werbung zu nutzen ist eine Sache (wobei ich da schon gewisse Bedenken habe).

Aber im nächsten Schritt läßt sich damit noch viel mehr machen. Menschen mit ähnlichem Profil fahren richtig saumäßig Auto? Klar, die Versicherung wird höher. Menschen mit ähnlichem Profil werden öfter krank? Du bekommst den Job nicht. Menschen mit ähnlichem Profil wohnen normalerweise in günstigeren Gegenden? Die Versicherungsprämien Deiner Nachbarn steigen, Deine Kinder werden in anderen Stadtteilen eingeschult. Menschen mit ähnlichem Profil kaufen meist ein 600er-Tele? Der Verkäufer weiß das auch, und redet Dir das 500er aus.

Und auch das ist erst der Anfang.

Wenn wesentliche Bewertungen von Menschen durch automatische Verfahren getroffen werden, deren Funktionsweise nicht offen gelegt wird, und die durch Interessengruppen, die von der Gesellschaft nicht kontrolliert werden können, verändert werden können, dann _wird_ die Gesellschaft eines Tages eben diesen Interessengruppe angepasst werden - mit anderen Worten, von diesen kontrolliert werden.

Falls ihr denkt, das kann nicht funktionieren: https://de.wikipedia.org/wiki/Sozialkredit-System_(VR_China) (und das ist noch harmlos - sobald physische Bewegungsdaten hinzu kommen, wird das erst richtig übel).

Falls ihr denkt, es könnte hier nicht kommen: Es ist technisch machbar, es verspricht Gewinn, also wird es kommen, wenn sich niemand wehrt. Vielleicht kommt es auch, wenn sich jemand wehrt, aber dann hätte man es wenigstens versucht.

Es ist Zeit, dass diese Entwicklung gestoppt wird. Egal wie.

Grübel' doch mal eine Weile darüber nach, bitte.

Spiegelung

Zu guter Letzt möchte ich Danke sagen - danke an alle Helfer, Silke, und insbesondere auch an Toph.

Und euch wünsche ich frohe Weihnachten, viel Spaß hier, und möge 2018 euch Gutes bringen.

Die Meise ist nur neugierig. Der Specht war's. Ich hab's gesehen.