Von mgraesslin am Fr, 9. September 2011 um 06:51 #
na endlich hat's geklingelt Und danke für das Feedback - das hab ich im Artikel dann nicht gut genug ausgearbeitet.
Übrigens die Argumentation im Artikel warum ein Fachfremder nicht an allen Bereichen qualitativ arbeiten kann, gilt um so mehr für security. Wie soll jemand der den Code nicht kennt und nicht versteht eine Sicherheitslücke identifizieren und beheben?
So ist es. Das gilt spätestens seit dem Openssl-Debakel. Auch das vorherige Nichtnachfragen auf der Mailingliste stößt mir sauer auf. Wenn man nicht weiß, was Sache ist, muss man vorher nachfragen oder die Codeänderungen sein lassen. Auf der Evergreen-Mailingliste sind solche Nachfragen normal, ob es sich um die Tragweite eines Blowfish-Bugs handelt oder um das Ausmass von Änderungen eines gepatchten yast2-core. Von daher geht mein Verständnis für solche einsamen kde-core-Änderungen gegen Null.
Unter Squeeze wollte ich mir ebenfalls Trinity hinzuinstallieren, was ich aber aufgegeben habe, als mir Synaptic anzeigte, dass das debianeigene "sudo" durch ein Trinity-"kde-sudo" ersetzt werden sollte. Mir war ziemlich klar, was dann passieren würde. Nach einigem Überlegen habe ich dann openSUSE 11.4 hinzuinstalliert, wegen KDE3.
Am KDE3-Code in openSUSE bzw. openSUSE-Factory scheint nur Weniges geändert worden zu sein, KWin müsste hier noch intakt sein. Mir ist dabei nur ein Kommentar eines Suse-Maintainers aufgefallen ("do not require something we don't build in factory"; zu finden in den Paketen kdebase3-workspace und kdebase3-apps), der diese Bemerkung anscheinend kurz nach einer in Verbindung mit dem Hal-Support stehenden Änderung abgegeben und den Fehler wohl zurückgenommen hat.
KDE3 ist in openSUSE 11.4 fast noch komplett und in openSUSE Factory noch vollständig enthalten. Ich brauche hier aus den externen openSUSE-OBS-KDE3-Repos lediglich die Pakete kdebase3-session, kdebase3-apps, kdebase3-workspace und kdebase3-ksysguardd.
Allerdings muss man auch hier generell aufpassen. So wird qt3 in openSUSE standardmäßig als qt3-3.3.8b bezeichnet, in den openSUSE-OBS-Repos liegt qt3 in Form einer sog. qt3-3.3.8c vor, die optional zur Verfügung steht. Qt3-3.3.8b ist das originale qt3, qt3-3.3.8c ist ein Trinity-gepatchtes qt3. Auch hier hätte ich mir gewünscht, dass der Trinityursprung so dabei gestanden hätte, das man diesen ohne Sucherei bemerkt. Ich hatte schon auf qt3-3.3.8c geupdatet, habe jetzt aber die Änderungen wieder zurückgefahren.
Was ich damit auch sagen will: Diese Namensmitbenutzung geht so nicht mehr weiter. Alles, was von Trinity kommt, sollte fairerweise auch so bezeichnet werden, damit man im vorhinein merken kann, was man installiert, unabhängig davon, was man persönlich danach damit anfangen möchte. Ich bin eigentlich bisher davon ausgegangen, dass es in den openSUSE-KDE3-OBS-Repos gar keine Trinity-gepatchten Pakete gibt. Es steht ja auch überall nur "KDE3" oder "qt3".
Die openSUSE-KDE3-Pakete in Factory, die zu Kompatibilitätszwecken mitgeschleppt werden, sind sauber. Der KDE3-OBS-Maintainer hatte nur übersehen, das Hal gerade aus openSUSE-Factory entfernt worden war.
Ansonsten bist Du auf Dich gestellt, d.h. Du musst schon wissen, was Du Dir aus OBS-Repos installierst.
Das einfache Rezept gegen solche Überraschungen kennst Du bestimmt: Niedrigste Priorität für openSUSE-Updates, eine "mittlere" für openSUSE-OSS (bzw. Deine DVD), eine höhere für OBS-Repos wie KDE3. Damit wird meist sichergestellt, dass nichts unbeabsichtigt auf eine OBS-Repo-Version aktualisiert wird.
Auf die Dauer wird man KDE3 nicht so erhalten können, wie er jetzt noch im kde3.org-KDE 3.5.10 erscheint. Änderungen am Code, auch in zentralen Bereichen, sind unausweichlich. Und natürlich wird es zu Fehlern kommen.
Das, was dann entsteht, sollte dann natürlich nicht mehr "KDE" heißen, sondern z.B. "Trinity DE" oder "TDE". Es muss erkennbar sein, dass kde.org dafür keinerlei Verantwortung trägt.
Das würde z.B. gerade auch dann gelten, wenn etwa das Limux-Projekt auf seinem Limux-Ubuntu 10.04 als KDE3 den Trinity-KDE3 und nicht den originalen KDE3 einsetzen würde.
na endlich hat's geklingelt
Und danke für das Feedback - das hab ich im Artikel dann nicht gut genug ausgearbeitet.
Übrigens die Argumentation im Artikel warum ein Fachfremder nicht an allen Bereichen qualitativ arbeiten kann, gilt um so mehr für security. Wie soll jemand der den Code nicht kennt und nicht versteht eine Sicherheitslücke identifizieren und beheben?
So ist es.
Das gilt spätestens seit dem Openssl-Debakel.
Auch das vorherige Nichtnachfragen auf der Mailingliste stößt mir sauer auf. Wenn man nicht weiß, was Sache ist, muss man vorher nachfragen oder die Codeänderungen sein lassen.
Auf der Evergreen-Mailingliste sind solche Nachfragen normal, ob es sich um die Tragweite eines Blowfish-Bugs handelt oder um das Ausmass von Änderungen eines gepatchten yast2-core.
Von daher geht mein Verständnis für solche einsamen kde-core-Änderungen gegen Null.
Unter Squeeze wollte ich mir ebenfalls Trinity hinzuinstallieren, was ich aber aufgegeben habe, als mir Synaptic anzeigte, dass das debianeigene "sudo" durch ein Trinity-"kde-sudo" ersetzt werden sollte. Mir war ziemlich klar, was dann passieren würde.
Nach einigem Überlegen habe ich dann openSUSE 11.4 hinzuinstalliert, wegen KDE3.
Am KDE3-Code in openSUSE bzw. openSUSE-Factory scheint nur Weniges geändert worden zu sein, KWin müsste hier noch intakt sein. Mir ist dabei nur ein Kommentar eines Suse-Maintainers aufgefallen ("do not require something we don't build in factory"; zu finden in den Paketen kdebase3-workspace und kdebase3-apps), der diese Bemerkung anscheinend kurz nach einer in Verbindung mit dem Hal-Support stehenden Änderung abgegeben und den Fehler wohl zurückgenommen hat.
KDE3 ist in openSUSE 11.4 fast noch komplett und in openSUSE Factory noch vollständig enthalten. Ich brauche hier aus den externen openSUSE-OBS-KDE3-Repos lediglich die Pakete kdebase3-session, kdebase3-apps, kdebase3-workspace und kdebase3-ksysguardd.
Allerdings muss man auch hier generell aufpassen. So wird qt3 in openSUSE standardmäßig als qt3-3.3.8b bezeichnet, in den openSUSE-OBS-Repos liegt qt3 in Form einer sog. qt3-3.3.8c vor, die optional zur Verfügung steht. Qt3-3.3.8b ist das originale qt3, qt3-3.3.8c ist ein Trinity-gepatchtes qt3. Auch hier hätte ich mir gewünscht, dass der Trinityursprung so dabei gestanden hätte, das man diesen ohne Sucherei bemerkt. Ich hatte schon auf qt3-3.3.8c geupdatet, habe jetzt aber die Änderungen wieder zurückgefahren.
Was ich damit auch sagen will:
Diese Namensmitbenutzung geht so nicht mehr weiter.
Alles, was von Trinity kommt, sollte fairerweise auch so bezeichnet werden, damit man im vorhinein merken kann, was man installiert, unabhängig davon, was man persönlich danach damit anfangen möchte.
Ich bin eigentlich bisher davon ausgegangen, dass es in den openSUSE-KDE3-OBS-Repos gar keine Trinity-gepatchten Pakete gibt. Es steht ja auch überall nur "KDE3" oder "qt3".
Die openSUSE-KDE3-Pakete in Factory, die zu Kompatibilitätszwecken mitgeschleppt werden, sind sauber.
Der KDE3-OBS-Maintainer hatte nur übersehen, das Hal gerade aus openSUSE-Factory entfernt worden war.
Ansonsten bist Du auf Dich gestellt, d.h. Du musst schon wissen, was Du Dir aus OBS-Repos installierst.
Das einfache Rezept gegen solche Überraschungen kennst Du bestimmt:
Niedrigste Priorität für openSUSE-Updates, eine "mittlere" für openSUSE-OSS (bzw. Deine DVD), eine höhere für OBS-Repos wie KDE3. Damit wird meist sichergestellt, dass nichts unbeabsichtigt auf eine OBS-Repo-Version aktualisiert wird.
Sag Bescheid, wenn "KDE3" auseinanderfällt.
Auf die Dauer wird man KDE3 nicht so erhalten können, wie er jetzt noch im kde3.org-KDE 3.5.10 erscheint. Änderungen am Code, auch in zentralen Bereichen, sind unausweichlich. Und natürlich wird es zu Fehlern kommen.
Das, was dann entsteht, sollte dann natürlich nicht mehr "KDE" heißen, sondern z.B. "Trinity DE" oder "TDE". Es muss erkennbar sein, dass kde.org dafür keinerlei Verantwortung trägt.
Das würde z.B. gerade auch dann gelten, wenn etwa das Limux-Projekt auf seinem Limux-Ubuntu 10.04 als KDE3 den Trinity-KDE3 und nicht den originalen KDE3 einsetzen würde.