News Tuxedo OS: Eigene Updates sollen Debian Testing absichern

[PhiE]

Tuxedo will den Wechsel von Ubuntu LTS auf Debian Testing mit einer eigenen Sicherheitsinfrastruktur flankieren. Kritische Korrekturen sollen bei Bedarf vor der regulären Aufnahme in Debian Testing über eigene Paketquellen verteilt werden.

Zur News: Tuxedo OS: Eigene Updates sollen Debian Testing absichern

 

[konkretor]

Wärs nicht sinnvoll die Patches dann gleich per upstream ins Debian Projekt zu geben? Sonst wird ja die Arbeit zwei mal gemacht.
Habe ich etwas überlesen?

 

[Clanker]

Ich befürworte jede Abkehr von Ubuntu.

Unter allen Distributionen würde ich mich nicht für Ubuntu entscheiden, da die vergangenen Entscheidungen und Ziele der Führung meiner Meinung nach nicht mit der Philosophie von Linux vereinbar sind.

 

[rorian]

Wärs nicht sinnvoll die Patches dann gleich per upstream ins Debian Projekt zu geben? Sonst wird ja die Arbeit zwei mal gemacht.
Habe ich etwas überlesen?

Das war auch mein erster Gedanke.

Ich befürworte jede Abkehr von Ubuntu.

Unter allen Distributionen würde ich mich nicht für Ubuntu entscheiden, da die vergangenen Entscheidungen und Ziele der Führung meiner Meinung nach nicht mit der Philosophie von Linux vereinbar sind.

Geht mir ähnlich. Ubunutu hat vieles für Linux getan und tut es sicher auch heute noch, aber bis auf sehr sehr wenige Ausnahmen fällt mir immer eine bessere Distro ein als Ubuntu für den Zweck. Auch ist mir deren Grundhaltung zu manchen Themen zuwieder und dann ist da ja noch Snaps...

 

[AAS]

Ich befürworte jede Abkehr von Ubuntu.

Unter allen Distributionen würde ich mich nicht für Ubuntu entscheiden, da die vergangenen Entscheidungen und Ziele der Führung meiner Meinung nach nicht mit der Philosophie von Linux vereinbar sind.

Ich glaube du verwechselst Linux und Unix Philosophie.
Amazone-Gate und Snap kann man hingegen gut kritisieren.

 

[silentcreek]

Wärs nicht sinnvoll die Patches dann gleich per upstream ins Debian Projekt zu geben? Sonst wird ja die Arbeit zwei mal gemacht.
Habe ich etwas überlesen?

Das Problem sind die festgelegten Wartezeiten für einen Upload ins Testing-Archiv in Debian. Oft werden Sicherheitslücken in Debian sowohl in stable (bzw. stable-security) als auch unstable (dem Entwicklungszweig, in den Entwickler neue Paketversionen hochladen) praktisch zeitgleich behoben. Das heißt die Patches sind bereits in Debian. Aber weil es Mindestwartezeiten für die Migration zu testing gibt, kommen sie dort für den Entnutzer später an. Insofern macht das geplante Vorgehen schon Sinn und es würde auch nicht helfen, wenn Tuxedo einen Patch an die Debian Maintainer schickt - denn der darf trotzdem nicht früher ins testing-Repository.

Tatsächlich ergibt der Ganze Wechsel von Tuxedo von Ubuntu zu Debian so überhaupt erst Sinn in meinen Augen. Denn Tuxedo hatte in seiner Ankündigung ja kritisiert, dass manche Sicherheitsupdates in Ubuntu nicht schnell genug ankämen. Deshalb hatte ich anderenorts schon geschrieben, dass der Wechsel zu Debian testing vor diesem Hintergrund fragwürdig ist, weil dort eben keine zeitnahen Sicherheitsupdates garantiert sind.

 

[Serana]

Wärs nicht sinnvoll die Patches dann gleich per upstream ins Debian Projekt zu geben?

Anscheinend hast du wirklich etwas überlesen.
Zitat aus dem Artikel:

Ist eine Sicherheitslücke in Testing aus Sicht des Unternehmens zu lange ungepatcht, soll ein bereits korrigiertes Paket direkt aus Unstable übernommen oder die Änderung als eigener Backport bereitgestellt werden. Nutzer sollen den Patch dadurch erhalten können, bevor er regulär in Debian Testing ankommt.

Mit anderen Worten ausgedrückt hat sich Tuxedo hier aus nachvollziehbaren Gründen entschlossen die Debian-Prozesse an der Stelle bewußt zu mißachten. Und während das für Tuxedo selbst auch Sinn ergibt, schließlich will man eine tatsächlich nutzbare Distribution bereitstellen, würde das für Debian eben keinen Sinn ergeben, da es ja für den Stable-Zweig eine Versorgung gibt und der Testing-Zweig eben über den Unstable-Zweig versorgt wird.

Generell würde ich für eigene Installationen im Allgemeinen empfehlen entweder Debian-Stable einzusetzen oder aber gleich auf Debian-Unstable zu gehen. Testing hat eben regelmäßig das Problem die Updates über Unstable zu bekommen. Und wenn es da hakt kann es dann durchaus sein, daß es auf Unstable zwar aktualisierte Pakete gibt, diese aber, weil eben erst in Unstable geschaut wird ob es offensichtliche Probleme gibt, nicht direkt nach Testing weitergegeben werden. Noch schlimmer wird es wenn im Vorfeld eines neuen Stable-Releases Testing eingefroren wird. Dann kommen nämlich erst einmal gar keine neuen Pakete aus Unstable nach sondern nur Sicherheitsupdates und Bugfixes.

Ich empfehle in dem Zusammenhang auch einen Blick in die Debian-FAQ. Dort wird das Problem mit Testing nochmal ausführlicher beschrieben:
https://www.debian.org/doc/manuals/debian-faq/choosing.de.html#s3.1.5

 

[andy_m4]

Wärs nicht sinnvoll die Patches dann gleich per upstream ins Debian Projekt zu geben?

Die Patches (die vermutlich ja auch nicht selbst geschrieben, sondern übernommen werden) sind wahrscheinlich eh auch in Debian drin. Und zwar in unstable.
Du hast aber ein Lücke von mehreren Tagen, bis die auch in testing ankommen.
Und in den meisten Fällen wird es darum gehen diese zeitliche Lücke zu überbrücken.

Ein einfachsten ließe sich das freilich so lösen, das man einfach die unstable-Pakete nach gründlichen Tests 1:1 übernimmt statt nur die Security-Fixes zu backporten.

Vermutlich wird es auf eine Einzelfallentscheidung hinauslaufen, wie man im konkreten Fall verfährt.

Die Alternative (die hier ja auch schon erwähnt worden ist) wäre, direkt unstable zu nehmen. Nur beraubt man sich damit eben der Testphase. Debian tut ja genau deshalb Dinge in unstable, damit grobe Fehler sofort auffallen.

Insofern ergibt das schon einen gewissen Sinn.

 

[Bigfoot29]

Man darf nicht vergessen: TESTING ist eigentlich auch keine gute Quelle für eine Distri. Nicht umsonst nutzen Rolling Release-Distris normalerweise Experimental UNSTABLE. TESTING ist nur dafür da, um das nächste stabile Release vorzubereiten. Das ist nicht im Ansatz für den Live-Betrieb gedacht sondern nur für abgeschottete Tests, ob die Paket-Konfigurationen sauber zusammenspielen.

Irgendwann kurz vor einem Release wird TESTING deswegen auch eingefroren, es werden nur noch Bugfixes gemacht, dann wird Testing zum neuen "Stable" und ein neues "Testing" wird eröffnet. (Zumindest so am einfachsten für die eigene Vorstellungskraft.)

Ich drücke Tuxedo wirklich die Daumen. Aber warum sie nicht gleich auf eine der Debian Experimental UNSTABLE Distris gesetzt haben... Selbst Experimental UNSTABLE ist normalerweise stabiler als so manches Ubuntu Non-LTS-Release...

Regards, Bigfoot29

 

[Serana]

@Bigfoot29
Dir ist aber schon klar, daß Debian Experimental keine vollständige Distribution ist? Dort landen jene Pakete die, aus welchen Gründen auch immer, nicht direkt nach Unstable kommen. Deshalb kann man Experimental auch nur zusammen mit Unstable benutzen aber niemals alleine.

Okay, rein theoretisch könntest du Experimental auch zusammen mit Stable oder Testing benutzen, aber damit würdest du um Abhängigkeitsprobleme geradezu betteln.

https://wiki.debianforum.de/Experimental

Aus Experimental installiert man immer nur einzelne Pakete. Bei einem normalen #apt full-upgrade wird das System auch dann keine Pakete automatisch aus Experimental ziehen wenn es in den Paketquellen drinsteht, und zwar (in diesem speziellen Fall) auch ganz ohne pinning.

Das hört sich zwar zunächst etwas umständlich an, aber dieser Zweig ist ausdrücklich nicht zur gewohnheitsmäßigen Nutzung vorgesehen. Bei Paketen von dort muß man immer mit Problemen rechnen.

 

[Bigfoot29]

@Serana: Mea Culpa. - Ich hab die beiden verwechselt. Du hast vollständig Recht.

Regards, Bigfoot29

 

[andy_m4]

Man darf nicht vergessen: TESTING ist eigentlich auch keine gute Quelle für eine Distri.

Erzähle das bei Canonical. :-)

TESTING ist nur dafür da, um das nächste stabile Release vorzubereiten. Das ist nicht im Ansatz für den Live-Betrieb gedacht sondern nur für abgeschottete Tests, ob die Paket-Konfigurationen sauber zusammenspielen.

Das ändert aber erst mal nichts daran, das die (außer halt in der Freeze-Phase) kontinuierlich aktualisiert wird.
Und klar kann man darüber streiten, ob man das als as-is nimmt (wobei es ja Usergibt, die das so machen). Aber das als Basis für eine eigene Distribution zu nehmen, ist auch nicht völlig abwegig.

Selbst Experimental

Das offizielle Debian-Wiki sagt folgendes:

Warnung: Experimental enthält viele Pakete, die sich noch im Alpha Stadium befinden, unvollständig sind oder auf eine andere Art Schaden am System anrichten können. Unerfahrenen Benutzern ist die Verwendung abzuraten!

https://wiki.debianforum.de/Experimental

Ich finde es eh lustig: testing willst Du nicht nehmen weil ist doch nur für Testzwecke. Aber experimental ist ok.

Ergänzung (Gestern um 14:07)

Ich hab die beiden verwechselt.

Ah ok. Kann natürlich passieren. :-)

 

[Grimba]

Ich finde die Wahl von Testing auch kritsch. Verzögerte Updates und Freeze vor Debian Stable Releases machen es einfach zu keiner guten Basis. Debian stable mit ein paar Sachen, die man selber aktueller hält, hielte ich für die effizientere Idee.

 

[Serana]

@Grimba
Das was du vorschlägst wäre ja basically Debian Stable + Backports.

Es stellt sich ohnehin die Frage, wenn Tuxedo OS ohnehin auf Debian basiert, ob es am Ende nicht am besten wäre direkt entweder Debian Stable oder Unstable zu nehmen. Zur Not könnte man ja den Kernel von Tuxedo OS nehmen um eventuelle Patches für die verbaute Hardware zu bekommen.

Auf der anderen Seite werden diejenigen die das können es vermutlich ohnehin genau so machen, wenn nicht die eigene Lieblings-Distribution zum Einsatz kommt.

 

[andy_m4]

Ich finde die Wahl von Testing auch kritsch. Verzögerte Updates und Freeze vor Debian Stable Releases machen es einfach zu keiner guten Basis

Das wurde jetzt schon rauf und runter diskutiert. Den Punkt einfach nur zu wiederholen, ohne auf das Gesagte einzugehen macht nur begrenzt Sinn.

Debian stable mit ein paar Sachen, die man selber aktueller hält, hielte ich für die effizientere Idee.

Das wäre Debian stable + Backports. :-)

Tuxedo hat ja auch begründet, warum sie es so machen, wie sie es machen.
Auch hier wieder: Wenn man einfach nur seine Meinung raushaut, ohne auf das einzugehen, was bereits gesagt wird, wirds ein bisschen sinnlos.

 

[Grimba]

Das was du vorschlägst wäre ja basically Debian Stable + Backports.

Kommt drauf an, was man möchte. Bei den Debian Backports bist du ja eben auf das Angebot dort angewiesen. Wenn du bei Kernel, Mesa, Nvidia Treiber etc. ggf. einen eigenen Weg gehen möchtest, wärst du eher ähnlich wie Pop!OS zu Ubuntu LTS.