Erinnere Dich an die Movember Wohltätigkeitsveranstaltungen im November. |
MediaWiki[wp] ist männerfeindlich, siehe T323956. |
PHP
PHP (rekursives Akronym und Backronym für "PHP: Hypertext Preprocessor", ursprünglich "Personal Home Page Tools") ist eine Skriptsprache mit einer an C[wp] und Perl[wp] angelehnten Syntax, die hauptsächlich zur Erstellung dynamischer Webseiten[wp] oder Webanwendungen[wp] verwendet wird.[1] PHP wird als freie Software[wp] unter der PHP-Lizenz verbreitet. PHP zeichnet sich durch breite Datenbank-Unterstützung[2] und Internet-Protokoll[wp]-Einbindung sowie die Verfügbarkeit zahlreicher Funktionsbibliotheken[3] aus.
Ein tiefenbeleidigter PHP-Entwickler hat mir geschrieben.
Ich hatte doch gerade über diese ausgefallene PHP-Konferenz[ext] geschrieben und dabei eine geringschätzige Bemerkung über die Sprache PHP fallen gelassen. Einige schrieben mir, dass das nicht nur dort so sei, sondern dass dieser Krampf sich inzwischen quer durch die technischen Konferenzen zieht. Da gab's wohl angeblich eine andere Konferenz aus dem Linux-Umfeld, zu der wieder nur weiße Männer Beiträge eingereicht haben. Also habe man in der Not einfach eine zweite Phantasiekonferenz zur selben Zeit am selben Ort abgehalten, bei der "Diversity" und "Empowerment" im Namen vorkommt, auf der dann "Unterdrückte" in 14 Sessions erzählen durften, wie sie die Open-Source-Welt umwälzen wollen ohne dabei jemals mit Technik in Berührung zu kommen. Man merke inzwischen richtig, wie durch diesen Gender-Druck die Konferenzen kaputtgehen und es immer weniger Leute dahinzieht - die einen, weil sie den Quatsch nicht mehr hören können - die anderen, weil sie durch diese Ideologie die Erwartung quotenmäßiger Durchmischung haben, die einfach nicht erfüllt werden kann und dann wegbleiben, weil die haluzinierte Frauen- oder Herkunftsquote nicht erfüllt wird. Egal, ob nun aus dem einen oder anderen, dem kritischen oder dem gläubigen Grund, das Ergebnis ist: Konferenz kaputt. So, wie durch diese Gender-Politik empirisch betrachtet alles kaputt geht. Ich schaue mir das ja an und bekomme unzählige Zuschriften, und mir ist bis heute kein Fall bekannt, in dem durch diesen Gender- und Diversitätsdruck irgendetwas besser wurde (obwohl das ja das große Versprechen und der angegebene Grund war), und mir fällt spontan auch kein Fall ein, in dem etwas wenigstens gleich gut belieben ist, weil allein schon der politische Druck und die verschobenen Anforderungen und Maßstäbe immer zu Konflikten, Konfrontionen, Streit führt. Viele Open-Source-Projekte wurden dadurch kaputtgefahren, und ich habe als Informatiker den Eindruck, dass Linux und das zugehörige Open-Source-Umfeld deutlich schlechter, leistungsärmer, innovationsärmer, qualitätsärmer ist als vor 10-15 Jahren, weil der Streit einfach zuviel Energie kostet und man zuviele hochproduktive aktive Developer in die Flucht geschlagen und durch Leute ersetzt hat, deren "Stärken" es sind, Kommentare und Variablennamen politisch korrekt umzuformulieren. Kommen dann noch solche Code-of-Conduct[wp]-Erklärungen dazu, die die Leute sogar außerhalb dieser Projekte in politische Diktate zwingen, wird das vielen Leuten zu dumm und sie gehen einfach. Übrig bleiben solche Leute, die bei den technischen Konferenzen nichts einreichen und dann zu "Diversity" und "Empowerment" sprechen. Ich kann mich nicht erinnern, jemals eine technische Leistung von "empowerten" Leuten gesehen zu haben.
Das einzige, was an dieser Zuschrift stimmt, ist, dass ich "studierter Informatiker" bin (der Zuschreiberling anscheinend nicht). Und ich bin durchaus in der Lage (und das gehört übrigens auch zu meinem Beruf), Programmiersprachen objektiv und leidenschaftslos anhand ihrer Eigenschaften zu beurteilen. Übrigens halte ich es für völlig dämlich, die Frage nach der Qualität von PHP mit der Frage "was ist die bessere Alternative" zu verbinden. Noch nie wurde etwas dadurch besser, dass es keine "Alternative" dazu gegeben hätte. Ich habe im Laufe meines Lebens bestimmt 30, 40 Programmiersprachen mehr oder weniger intensiv mal erlernt, benutzt und viele auch wieder nach jahrelanger Nichtbenutzung wieder vergessen, darunter diverse Assembler, Ursprachen wie Fortran, Cobol, Algol, BASIC, Lernsprachen wie Pascal und Modula-2, Kuriositäten wie APL und Occam, auch Forth, Unpraktisches wie Objective-C, Schräges wie Lisp und Prolog, Praktisches wie C und C++, Skriptiges wie Perl, Ruby, etwas Python, etwas Lua, PHP, Javascript, moderneres wie Rust, enttäuschendes wie Java, komisches wie Scala und noch jede Menge anderes Zeug, was mir gerade spontan nicht einfällt. Ich denke, ich habe schon etwas Überblick. Wobei mir übrigens ganz massiv auf den Wecker geht (und vielen Leuten meines Alters ebenfalls), dass es so überflüssig viele Sprachen gibt, die sich darin unterscheiden, dass sie ein und dieselbe Sache mit der soundsovielten Syntax machen und alle Begriffe und Schlüsselworte einfach mal wieder neu erfinden oder permutieren, ohne irgendwas neu oder besser zu machen. Irgendwann tut man sich echt schwer damit, ob jetzt ein Strichpunkt dahintergehört oder nicht, weil andauert irgendwer irgendwo meint, jetzt gerade mal wieder irgendeine neue Sprache erfinden zu müssen ohne Neues zu erfinden. SpielzeugsprachePHP war ursprünglich nur ein Experiment, ein proof of idea, die nochmal besser gemacht werden sollte, sich dann aber schon festgefressen hatte, und das nicht mehr zu ändern wäre, ohne inkompatibel zu werden. PHP ist quasi ein Betriebsunfall. Schon damals fiel auf, dass PHP groteske Fehler hatte. In der Anfangszeit hat PHP einfach alle URL-Parameter als Variablen gesetzt, was dazu führte, dass ein Angreifer durch Konstruktion des URL beliebige Variablen setzen konnte. Es hat nach meiner Erinnerung Jahre gedauert, bis man eingesehen hat, dass das eine dumme Idee ist und es zunächst optional (wegen der Rückwärtskompatiblität) und dann dauerhaft geändert hat. Sowas prägt sich bei mir ein. Mischung von Seiteninhalt und SprachelementenPHP murkst Programmteile und Webseiteninhalte beliebig durcheinander. Sowas wie klare Templates oder eine Struktur (z. B. MCV - Model View Controller[wp]) gibt's nicht, man rotzt und murkst es halt einfach so hin. Das ist enorm gefährlich. Denn dadurch sind statische Daten udn Programme kaum getrennt. Ein kleiner Konfigurationsfehler im Webserver, und der PHP-Code wird nicht interpretiert, sondern einfach als Text ausgegeben. Häufig enthalten PHP-Skripte aber Passworte und ähnliche vertrauliche Daten, etwa für die Datenbank. Die so eben gar zu leicht vom Angreifer gelesen werden können. Dem kann man zwar begegnen, indem man in den WWW-Baum nur Skripte mit Include-Anweisungen legt und die vertraulichen Daten dann außerhalb des Dateibaums, auf den der Webserver selbst zugreifen kann. Aber es macht kaum einer. Man muss es immer von Hand nachträglich fummeln. Und selbst wenn man es machte, dann müsste man zwei Dateibäume pflegen, zwei zip-Archive[wp] verwalten: Den im Web-Baum und den außerhalb. Konstruktionsfehler RoutingDer Grund, warum ich PHP für broken by design halte, ist, dass es zwischen dem URL-Raum und den PHP-Skripten keine Routing-Instanz, sondern eine 1:1-Beziehung gibt. Der Angreifer kann durch Bau des URLs bestimmen, welches der PHP-Skripte im Zugriffsraum des Servers gestartet wird. Und das ist Murks. Ich will mal am Beispiel erklären, warum. Vor Jahren hat mir mal einer das Blog aufgebohrt und Backdoors und Porno-Proxies implantiert. Viel ist nicht passiert, ich habe es durch Hinweise gemerkt, entfernt, untersucht. Was war passiert? Ich war damals auf der Suche nach einem passenden Theme, hatte verschiedene ausprobiert, und letztlich selbst eines geschrieben. Eines der fremden Themes, die ich probiert habe, hatte eine Sicherheitslücke. Obwohl ich das Theme längst wieder deaktiviert und aus der Konfiguration gestrichen hatte, lag das noch im Dateibaum herum und konnte deshalb vom Angreifer, der wusste, dass dieses Theme eine Macke hat, direkt aufgerufen werden, obwohl es in der Konfiguration deaktiviert war. Einfach, weil es im Pfad da war. Und dann kam dazu, dass WordPress Bilder, die man einbinden will, einfach in den normalen Web-Baum reinlädt, ein Verzeichnis muss dafür für den Webserver schreibbar sein, und die Dateinamen-Endung wird nicht prüft. Der Angreifer konnte also in das Verzeichnis, das für Bilder gedacht ist, einfach "Bilder" mit der Endung .php ablegen, die dann - obwohl eigentlich nur Daten da sein sollten - ausgeführt wurden. Ich sag's mal frei heraus: Sowas ist einfach absolute Scheiße und darf nicht passieren. Eine Konstruktion, in der ein Angreifer "Daten" hochladen kann, die per Konstruktion nicht von Programmen zu unterscheiden sind, und sie dann einfach ausführen kann, indem er einfach ihren Pfad als URL aufruft, ist ultimativer Mist. Die Trennung von Programmen und Daten ist elementar, und unter gar keinen Umständen darf ein Angreifer irgendwelche von ihm vorgegebenen Daten als Programm ausführen lassen. Interpreter statt CompilerJa, Interpretersprachen sind bequem. Ich mag sehr gerne Ruby. Aber sie haben ein gewaltiges Problem: Viele Fehler werden erst zur Laufzeit entdeckt. Beispielsweise ob Funktion und Funktionsaufruf mit Typ, Parametern und so weiter zusammenpassen oder überhaupt denselben Namen haben. Und das ist für Produktiv- und Feindkontakt-Einsätze übel. Ein Compiler mag zwar für Entwickler mitunter lästig sein, aber er hat den großen Vorteil (neben schnellerem Code), dass er eine Menge Prüfungen vorweg nimmt, etwa ob jeder Funktionsaufruf auch die Funktion findet und die Parameter und Typen passen. Laien-CommunityDas ist jetzt etwas überspitzt bezeichnet, aber mir fiel gerade keine bessere Formulierung ein. So der Typ, der mir da schreibt, ist symptomatisch. HTML+PHP ist verhältnismäßig einfach und ohne sonstige Kenntnis einzusetzen, weshalb sich da eine Biotop für Webentwickler gebildet hat, die das und sonst nichts können, so quasi das BASIC des Internet-Zeitalters. Und das Ergebnis ist halt viel Murks. Miserable WartbarkeitWir haben einen Vereinswebserver mit etwa 100 virtuellen Domains. Es ist jetzt aber nicht so, dass es da von den PHP-Programmen eine Version gebe, die wir mit dem normalen Update/Upgrade für alle pflegen, wenn wir etwa eine neue Version eines Apache-Webservers installieren. Die gilt dann für alle. PHP-Programme sind aber in der Regel nicht "mandantenfähig" und in der Regel auch nicht installationsfähig, zumindest nicht ohne manuelles Nachfummeln. Das führt dazu, dass nicht wir als Admins eine Version von der Software X, die irgendwas macht, installieren und aktualisieren, die dann alle Vereinsmitgliedern benutzen, die das wollen, sondern jedes einzelne Mitglied lädt sich von irgendeiner Webseite irgendein zip[wp] herunter und packt das in seinem Webverzeichnis irgendwo aus um da irgendwo irgendeinen Ticker oder irgendein Fotoalbum oder weiß der Kuckuck was zu betreiben - und das dann die nächsten 10 Jahre nie mehr anzufassen. Das können wir als Admins nicht mehr zentral warten und überwachen, weil die Software im Bereich der Mitglieder herumliegt, und selbst wenn wir da reingreifen (obwohl's uns dann eigentlich nichts angeht), wissen wir oft nicht, was das für Software ist, woher sie kommt, oder überhaupt nur, was für eine Version das ist, weil das nur auf der Webseite oder im Dateinamen des zips stand, aber nicht in den PHP-Dateien. Und dann wissen wir nicht mal, was wir austauschen können, weil die Mitglieder ja irgendwas selbst dran gefummelt haben können (und das selbst nicht mehr wissen). Das ist, was Wartung und Sicherheit angeht, ein regelrechter Gau, ein großer Haufen Mist, durch den keiner durchblickt. Das Zeug ist nicht ordentlich wartbar. ProgrammierstilKatastrophe. Durcheinander wie Kraut und Rüben, die Leute blubbern einfach drauf los. Ich habe vor vielen Jahren mal versucht, WordPress[wp] so zu modifizieren, dass ich HTTP[wp] und HTTPS[wp] parallel mit demselben Blog machen kann. Das habe ich entnervt aufgegeben, weil ich irgendwann gemerkt habe, dass das ein fürchtliches Gestrüpp aus mindestens drei verschiedenen Programmierstilen war[wp] und mit jeder Version immer nur noch eine neue Lage Kuhfladen obendrauf kam. Da kommt immer einer und baut noch irgendein Feature oder irgendeinen Trick ein und der Haufen wird immer größer, aber aufräumbar sah das nicht mehr aus. Und PHP ermöglicht mit seiner Struktur auch keinen sauberen Stil, fördert im Gegenteil das Durcheinander und Gemurkse. LesbarkeitViele PHP-Programme sind schwer lesbar, schlicht weil es willkürlich durcheinander wie Kraut und Rüben geht. Die Struktur ist einfach nicht so, dass sie aufgeräumtes Programmieren fördert. FazitIch halte nichts von PHP. Das ist einfach Mist, Schrott. Typisches Ding für Webseiten-Fummler ohne ernstliche Ausbildung. Es gibt manchmal dynamische Kleinigkeiten, für die das noch OK ist, und es soll ja auch einfach umsetzbar sein, aber sobald das etwas komplexer oder gar ein Projekt wie WordPress oder all die anderen Content-Management-Systeme[wp] ist, ist PHP eindeutig untauglich, weit überfordert und das Ergebnis vom Standpunkt der Sicherheit, Wartbarkeit und Qualität, wenn, dann nur mit erheblicher Zusatzsorgfalt und sehr guten Entwicklungsprozessen und Sicherheitsprüfung vertretbar. PHP ist noch in Ordnung, wenn man in einer Webseite mal irgendwas dynamisch Erzeugtes auftauchen soll, aber ab einer gewissen Komplexität ist das nichts mehr. Alternativen
So etwas in dieser Art würde ich mir als Alternative vorstellen. | ||
– Hadmut Danisch[4] |
Einzelnachweise
- ↑ Rasmus Lerdorf: "PHP's design goal from the very beginning is very simple. To solve the common web problem. That's it."
- ↑ PHP-Handbuch: Datenbankerweiterungen
- ↑ PHP-Handbuch: Erweiterungen
- ↑ Hadmut Danisch: Über PHP, Ansichten eines Informatikers am 27. August 2019
Netzverweise
- PHP: a fractal of bad design, fuzzy notepad am 9. April 2012 (This article has been translated into Spanish (PDF, with some additions) by Jorge Amado Soria Ramirez)] (Murks-Katalog von PHP)