Moin Sven,

[…] Außerdem kann ich so viel besser zusammenhängend ranten. :)

Weniger ranten, mehr konstruktiv arbeiten. Es ist nicht zielführend, potentielle Mitarbeiter durch Rants vor den Kopf zu stossen.

[…] in der Folge werden aber häufig auch Updates für Konfigurationsdateien notwendig, die in einem recht aufwendigen Merge-Prozess mit den eigenen Anpassungen zusammengeführt werden müssen.

So wie bei jeder anderen Distro auch. In Debian wirst du gefragt, ob du die Konfiguration überschreiben willst mit der im Paket, ob du die im Paket verwerfen willst, oder ob du sie mergen willst. In Arch wird sie neben die alte gelegt und man muss sich selber darum kümmern.

Das ist technisch auch gar nicht anders möglich. Wenn sich die Konfigurations-Dateien im Upstream ändern, muss sich die Änderung natürlich auch in der Installation wiederspiegeln. Ansonsten kann eine einwandfreie Funktionalität nicht sichergestellt werden.

Dies bedeutet: Derjenige, der das Update macht, muss von allen Konfigurationsdateien, die in diesem Schritt als updatenotwendig angezeigt werden, inhaltlich Ahnung haben. Das bedeutet: Er muss von sämtlichen Serverkomponenten, die irgendjemand mal via Gentoo-Emerge installiert hat, Ahnung haben - oder er macht wahrscheinlich was kaputt.

Das gleiche gilt auch für jede andere Distribution. Du beschreibst hier gerade den Job eines System-Administrators.

[…] und die die Installation von Software für jemanden, der genausoviel Ahnung hat, exzellent dokumentieren können, damit derjenige den Job ebenfalls machen und/oder übernehmen kann.

Das ist idR nicht notwendig. Ich bin ja mit den Self-Servern auch gut klargekommen, obwohl ich seit Jahren keinen Root-Zugriff mehr hatte. Ich war sogar in der Lage, hauseigene Patches auf neue Versionen der Programme zu migrieren. Vollständig ohne Dokumentation.

Ein weiteres Problem, dass beim Serverbetrieb immer wieder auftritt, ist die erforderliche Update-Frequenz für eigentlich alles, was man mal so installiert hat. Im Prinzip muss man regelmäßig updaten, damit das Delta der Veränderungen, die jedes Update mit sich bringt, nicht zu groß wird.

Auch das gilt für jede andere Distro. Im wesentlichen gilt: Updates sollten im Wochen-Rhythmus gefahren werden, unabhängig von der Distro. Debian veröffentlicht regelmäßig Security-Ports bzw. neue Versionen in den Backports. Archlinux als Rolling Release veröffentlicht täglich neue Versionen. FreeBSD sieht ähnlich aus. Etc, pp.

Das gilt für Betriebssystemkomponenten natürlich auch, insbesondere allerdings für die eingesetzte Standardsoftware der Webapplikationen. SELFHTML hat an ein paar Stellen Standardsoftware im Einsatz, beispielsweise "Trac" als Ticketsystem und Dokumentations-Wiki. Hier schlägt ein Update der Software unter Umständen mit großem Migrationsaufwand zu: Wenn das Update inkompatible Änderungen zum bestehenden System erfordert, insbesondere wenn wichtige Plugins noch nicht verfügbar sind, auf die man nicht verzichten kann, oder die für die neue Version gar nicht angeboten werden, weil vielleicht deren Funktionalität nicht mehr realisierbar oder überflüssig ist.

Hier beschreibst du wieder das übliche Dilemma. Nicht updaten geht nicht, weil man dann die Security-Fixes von Hand nachportieren müsste. Updaten bringt aber auch Arbeit mit sich. Ist halt so.

KONSEQUENZ 4: "Würde das jemand machen - kannst auch deine bevorzugte Sprache benutzen" - no way!

Diesen Luxus kann man sich erlauben, wenn man Überfluss in den Kapazitäten hat. Tatsache ist, dass SELFHTML chronische Unterkapazität hat. Hier gilt es, Leute überhaupt mal zu etwas Arbeit zu motivieren. Sie dann durch strikte Vorschriften abzuschrecken, die ggfls. sogar den Leuten nicht passen, ist ziemlich kontraproduktiv.

Standards definieren und einhalten. Man kann über PHP ja sagen, was man will, aber es ist definitiv die Skriptsprache mit der größten Community verglichen mit anderen Skriptsprachen - es ist zu vermuten, dass sich dafür recht leicht Experten finden lassen. Wildwuchs erschwert die Wartung vor dem Lebensende der Software.

Experte in PHP zu sein bedeutet nicht, eine Software warten zu können. Sobald eine Software eine bestimmte Größe überschritten hat, ist eine Einarbeitungszeit unabdinglich. Dabei ist die Sprache nur sekundär relevant.

LG,
 CK