# Sucker-Tree vs. stabiler Vanilla-Tree

## hoschi

Hallo,

frueher kamm es mal vor, dass der Vanilla-Kernel eine vierte Versionsnummer bekommen hat um eine kritische Sicherheitsluecke im offiziellen Zweig schnell schliessen zu koennen (z.B. Vanilla-Kernel 2.6.8.1).

Als dann einige Leute unbedingt staendige Updates fuer den offziellen Zweig durchsetzen wollten gab es natuerlich boeses Blut, es handelt sich schliesslich um den Betriebssystem-Kernel. Vorsichtig gesagt, es ist unnatuerlich und extrem aufwendig alle drei Tage den Kernel zu patchen, schliesslich ist das kein Prerelease mehr.

Torvalds nannte das ganze (in seiner Ablehnung) Sucker-Tree, als Anspielung darauf dass der zustaendige Maintainer wirklich die Arschkarte gezogen hat  :Very Happy: 

Ich persoenlich sehe es wie Torvalds. Es ist der stabile Systemkernel, denn man wirklich nur in Notfaellen patchen sollte und halte es in der Praxis auch so. Er setzte sich aber nicht durch. Der Maintainer der Gentoo-Kernel sieht es offenbar auch aehnlich, bis es da mal ein Update kommt sind bei mir alle Zimmerpflanzen verdurstet.

So geht dann jeder seinen Weg, die einen starten alle vier Tage die Systeme neu, die anderen eben nur alle vier Wochen (bildlich gesprochen).

Damit leben wir alle in dieser Situation, aber inzwischen nimmt es meiner Meinung nach Ueberhand. Wir sind innerhalb weniger Tage von 2.6.16 auf 2.6.16.9(!) gesprungen. Entschuldigt, aber wenn ein Konzept gescheitert ist, dann sollte man es auch einsehen.

Ich weiss nicht wie viele Zeilen Code der Kernel hat, ich bin mir nur ziemlich sicher dass da im Durchschnitt genau so viele Fehler sind wie in den grossen Kernelversionen davor (2.4, 2.2, 2.0). Nur hat man die Fehler vor der Einfuehrung des Sucker-Trees wohl etwas aufgebauscht, ich weiss nur: 5000 Zeilen Code ohne Fehler ~ unrealistisch

Ich bin kein Freund von Verschleierungstaktiken bei Luecken, im Gegenteil, aber man sollte nicht ganz so kritische Fehler  einfach Fehler sein lassen, und es beim naechsten mal gleich richtig machen. Teilweise kriegt man mit 100 Zeilen zur Bugbehebung (so lange darf ein Bugfix im Sucker-Tree sein) doch nichts gebacken. Lieber dann doch gleich das Problem genau betrachten, und dann eine saubere Gesamtloesung im naechsten Kernel raus bringen, und die dann noch mehrmals kontrollieren lassen.

Ich erledige solche Probleme lieber auf die "deutsche Art", sauber und gruendlich, und nicht schnell und schmutzig.

Die AC und MM-Trees habe ja auch einen Zweck als quelle fuer einzelen Patches.

Mir ist klar dass da fast jeder eine eigene Meinung hat.

Artikel dazu:

http://www.heise.de/newsticker/meldung/72127

----------

## manuels

nur 14 von 15 fragen richtig   :Embarassed: 

aber wie kann ich denn herausfinden, was ich falsch getippt hab?

----------

## hoschi

Aehm? Falscher Thread?

Die rege Diskussion begeistert mich   :Surprised: 

----------

## manuels

 :Embarassed:  hmm, war wohl gestern doch ein bier zuviel...

----------

## UncleOwen

Wo ist Dein Problem? Wenn ein Bug gefunden wird, wird er gepatched. Wenn der Bug Dich nicht betrifft, update nicht. Besser als ein offener Bug fuer 3 Monate.

Vielleicht solltest Du Dir mal anschauen, was fuer Patches ueberhaupt in -stable einfliessen. Das sind nicht wirklich grosse Aenderungen...

----------

## hoschi

Das meine ich ja, man kann auf den ersten Blick einfach nicht sehen ob der Patch kritisch ist oder nicht, dass war frueher ganz klar. Als man bei 2.6.8.1 die "1" gesehen hat war klar was Sache ist, Update!

Jetzt hat man entweder Glueck und bekommt es auf eine Mailingliste mit, oder auf einer Newssite. Das Changelog ist zwar durchaus eine Informationsquelle (boses heise), aber wohl nicht sehr praktisch (jeden Bugzilla Eintrag anschauen?).

Vanilla-Sources bei Gentoo:

2.6.16.9 

2.6.16.5 	

2.6.16.1 	

2.6.16

Da fehlen seches Versionen. Und ich unterstelle da Gentoo einfach keine Nachlaessigkeit, sondern sehe den Fehler beim Sucker-Tree an sich. Ich uberlege mir ernsthaft ob ich das Update durchziehe, sofern ich bei slashdot oder computerbase nicht irgend einen Eintrag finde dass das wirklich kritisch ist.

Wir hatten uber die Osterfeiertage (Feiertage!!!) vier Updates.

Wir reden hier ja ueber den stabilen Zweig, stabil wohl gemerkt. Dass es da Upates gibt ist klar, auch Mozilla gibt da regelmaessig Update raus, aber da sammelt man dann halt erstmal und haelt es vernunftbedingt zurueck. Ich sehe ja ein dass es nicht dem Open-Source Gedanken entspricht einen Bug erstmal nicht breitzutreten, aber irgendwo muss man realistisch bleiben, sonst duerfen wir einen Kernel nicht mehr als "stable" markieren.

Stabil heisst stabil, und nicht alle drei Tage eine Update.

Auf der Flucht heisst schliesslich "Auf der Flucht", und nicht "Nach fuenf Minuten geschnappt".

Gruss

Der Anwender hat eine Holschuld, aber die Bringschuld (sofern es bei Open-Source eine gibt) sollte nicht den Anwender letztendlich erschlagen.

<Henrik Brix Andersen> :thumbsup:

----------

## think4urs11

 *hoschi wrote:*   

> Jetzt hat man entweder Glueck und bekommt es auf eine Mailingliste mit, oder auf einer Newssite. Das Changelog ist zwar durchaus eine Informationsquelle (boses heise), aber wohl nicht sehr praktisch (jeden Bugzilla Eintrag anschauen?).

 

Hast du dich jetzt freiwillig gemeldet für den Suckertree pro Release eine kurze. übersichtliche und leicht verständliche Zusammenfassung zu verfassen?

Es ist eben Definitionssache was man als kritischen Bug ansieht und die Maintainer nehmens eben sehr genau bzw. übergenau.

Wenn man sich manchmal die Changes anschaut fragt man sich aber wirklich ob manche der sehr spezifischen Fehler ein neues Release rechtfertigen, muß ich dir zustimmen.

Andererseits ist mir der status quo immer noch lieber als bei den Jungs aus Redmond wo es Fehler (äh Patches) nur einmal im Monat gibt - alleine die Idee ist schon etwas daneben.

----------

## hoschi

Think4UrS11:

Sehe ich genauso, ein Patch ist besser als keiner. Aber so wie es jetzt ist, fuehle ich mich langsam "diskrimiert", ich kriege ja bald Schuldgefuehle, nur weil ich diese Unterversionen nicht installiere.

z.B. einer der ersten Sucker-Tree Releases behandelte eine Kompilierungsfehler bei den ATA-Treibern unter PPC, was hat sowas mit Sicherheit zu tun? Sowas ist richtig aergerlich (zeigt vor allem die geringe Bereitschaft -rc's zu testen bei den Anwendern), aber eben nicht sicherheitskritisch. Ich wuerde das unter x86 uebrigens genau so sehen, eine zwei Klassengesellschaft gibts nicht.

Entweder AC/MM-Patches, ein einzelner Flicken oder eben beim naechsten Major-Release

----------

## think4urs11

 *hoschi wrote:*   

> Sehe ich genauso, ein Patch ist besser als keiner. Aber so wie es jetzt ist, fuehle ich mich langsam "diskrimiert", ich kriege ja bald Schuldgefuehle, nur weil ich diese Unterversionen nicht installiere.

 

Wieso? Changelog lesen ... 'ah, könnte mich betreffen, wird installiert' oder 'aha, ppc, s390, xxx changes, is mir wurst - wird nicht installiert'.

Ob man manches nun als neues w.x.y.z-Release rausbringt oder als einzelnen Patch ist doch eigentlich nur eine kosmetische Frage.

Oder um mich auf meine Sig zu beziehen - security is always a tradeoff with usability; wers sicher haben will muß sich aktiv kümmern, auch wenns lästig ist (kryptische Changelogs lesen)

----------

## hoschi

Zeig mir einen Betrieb, der ueber die Feiertage die ganzen Updates installiert hat!

Eben...

PS: Ein alter Kernel schuetzt erst recht nicht, entweder weil er die Luecken auch hat, oder wegen Distro-Backports

<edit>

Wenn es dafuer ein irregulaeres Update gibt, dann ziehe ich es durch:

http://software.newsforge.com/article.pl?sid=06/04/18/1941251

Linus rult ja mal alles weg, wie geil  :Very Happy: 

----------

## think4urs11

 *hoschi wrote:*   

> Zeig mir einen Betrieb, der ueber die Feiertage die ganzen Updates installiert hat!

 

Die blackhats schlafen nie, die whitehats auch nicht, was willst du damit nun aussagen?

Wäre es dir also lieber wenn - wie ja angedacht - sämtliche bugfixes und Co. den Distri-Maintainern auf die Backe zu drücken?

Dann köcheln noch mehr am Kernel herum als jetzt schon und im schlimmsten Fall beheben verschiedene Distris den gleichen Fehler auf unterschiedliche Art was dann auch wieder unterschiedliche Folgefehler nach sich zieht...

Dann ist mir persönlich aber lieber einen 'offiziellen' 'distriunabhängigen' Patch in Form eines neuen Suckerreleases zu bekommen.

----------

## mrsteven

Ein Bug ist ein Bug und sollte so schnell wie möglich ausgebessert werden. Es zwingt dich niemand alle paar Tage einen neuen Kernel zu kompilieren. Wenn du feststellst, dass der behobene Fehler für dich nicht relevant ist (z.B der Fehler beim Kompilieren), brauchst du ja nicht unbedingt einen neuen Kernel installieren.

Die letzten paar Releases waren vielleicht Schnellschüsse, von mir aus. Aber nehmen wir z.B. an, es gibt einen Fehler, der von der Mehrheit nicht als wichtig angesehen ist, z.B. weil er nur bei böswilligen lokalen Usern zu Problemen führen kann. Dummerweise betreust du halt ein paar öffentlich zugängliche Rechner (z.B. in einer Uni). Dann bist du natürlich auf einen möglichst sicheren Kernel angewiesen. Je früher dann eine neue Version draußen ist, umso besser. Klar, dank OpenSource kannst du auch selber patchen, das kommt aber von der Ausfallzeit her auf das gleiche raus wie ein Reboot mit einem neuen Kernel. Wenn es das, was von manchen herablassend als Sucker-Tree bezeichnet wird, nicht geben würde, müsste sich jeder Admin seinen Kernel selbst zusammenpatchen, weil halt der Fehler nur im aktuellen git-Snapshot korrigiert wurde. Und wer lässt schon gerne einen eigentlich noch nicht fertigen Kernel auf einem Produktivsystem laufen, das zudem noch öffentlich zugänglich ist? Es ist doch besser, wenn diese Reparaturen von kompetenten Kernel-Entwicklern durchgeführt werden. Spart dem geplagten Admin einfach auch Zeit...  :Wink: 

Das Konzept ist also richtig, auch wenn es in der Durchführung in den letzten Tagen halt etwas gehakt hat.

Die Versionsnummerierung wird aber langsam wirklich unübersichtlich: Da die 2.6.16.x-Serie ja nun weiterhin gepflegt werden soll, gibt es bald Kernel 2.6.16.24 und gleichzeitig Kernel 2.6.29.3. Da blickt doch keiner mehr durch. Wie wäre es denn, den Kernel, der als 2.6.17 herauskommen wird, einfach als 2.7.1 zu veröffentlichen und wieder einen echten Entwicklerkernel einzuführen?

So, und jetzt möchte ich mich entschuldigen, denn das gehört eigentlich eher in die Kernel-Mailingliste...  :Confused: 

----------

## hoschi

Punkt. Genau.

Ich bin fuer die vierte Versionsnummer, aber man sollte versuchen sich bei einem Zeitraum von ein bis zwei Monaten auf die Ziffern 0-3 einzuschraenken, da sollte wohl auch ein Konsens moeglich sein. Dann kann man sich Linus herablassende Bezeichnung auch schenken, den Job koennen dann naemlich Linus+Morten auch so erledigen.

----------

## UncleOwen

 *hoschi wrote:*   

> Punkt. Genau.
> 
> Ich bin fuer die vierte Versionsnummer, aber man sollte versuchen sich bei einem Zeitraum von ein bis zwei Monaten auf die Ziffern 0-3 einzuschraenken, da sollte wohl auch ein Konsens moeglich sein.

 

Und wenn man mehr als 3 Bugs findet, werden die nicht gefixed? Sorry, wenn Du Patch-Days willst, geh zu Microsoft.

----------

## hoschi

Wenn du es so auslegen willst, bitte...hoffentlich bist du dir im klaren was fuer einen Behauptung du da gerade aufstellst.

Genauso gut kann man zwischen "When it's done!" und "Fester Zeitrahmen" eine Linie ziehen, sowas geht nicht.

Tschuldigung, aber Securtiy by Obscurity zu unterstellen ist gemein.

----------

## mrsteven

Das macht er doch gar nicht. Es geht nur darum, dass (sicherheitsrelevante) Bugs so schnell wie möglich gefixed werden, von mir aus auch mit hohen Versionsnummern an der vierten Stelle. Du kannst ja selbst entscheiden, ob du Updaten willst, damit dein Assemblervirus läuft...  :Wink:  Die weniger praktische Alternative wäre es eben, dass sich jeder Admin die Patches selber zusammenträgt.

Ich dachte eigentlich daran, dass es künftig wieder etwas ähnliches wie einen Entwicklerkernel geben sollte. Das wäre dann die Serie von Linus, also der Kernel der bald als 2.6.17 erscheinen wird. Um die Nummerierung etwas zu vereinfachen, wäre es IMHO besser, diesen Kernel als ersten Kernel einer 2.7-Serie zu veröffentlichen. Für die 2.6.16.xy-Serie, die von Adrian Bunk verwaltet wird, würde bei kleineren Bugfixes die vierte Nummer erhöht werden, bei größeren die dritte.

Aber wie gesagt, das gehört eigentlich nicht hier her...

----------

## hoschi

Ich glaube Vorhersagen in diesem Bereich sind nicht wirklich zuverlaessig. Linus wird sicher eine Vorstellung haben in welche Linux in Zukunft wandern soll. Plan9 und eine hoeher Modularisierung sind da sicher Punkte, und dass sollte mit dem GNU-System ja auch Hand und Fuss haben.

Aber bloss nicht das alte 2.4-System...

----------

## sschlueter

Ich kann's mir nicht verkneifen, auch was dazu zu sagen.

Ich finde es grundsätzlich gut, dass es den Sucker-Tree gibt. 

Wenn also in dem "Haupt-Release" (weiss nicht, wie das offiziell heisst, ich meine 2.6.16) Fehler gefunden werden, die entweder die Sicherheit betreffen oder die Stabilität schwerwiegend beeinträchtigen können, dann ist es meiner Ansicht nach absolut richtig und wichtig, Patches für diese Fehler anzubieten. Voraussetzung ist allerdings, dass der Fehler klar erkannt worden ist und dass der Patch ebenso klar den Fehler behebt und klar erkennbarerweise keine schädlichen Nebenwirkungen hat (zum Beispiel weil er so kurz und übersichtlich ist).

Ich finde das total natürlich. OpenBSD bietet ja zur Release auch "security fixes" und "reliability fixes".

Ich finde es auch richtig, nicht erst zu warten, bis man eine gewisse Menge Patches beisammen hat. Wenn der Fehler klar ist und der Patch auch klar ist, kann man den auch sofort rausbringen.

Ist ein wenig ungewöhnlich, dass man dann ein neues "Sub-Release" draus macht. Das machen andere Projekte ja auch nicht. Man könnte auch einfach alle Patches zum Haupt-Release herausbringen, und zwar alle einzeln, so wie andere das auch machen.

Das einzige, was ich wirklich nicht gut finde, ist, dass es keine vernünftigen Beschreibungen zu den Fehlern gibt. Oft gibt es nur die Kommentarzeile aus dem Commit, die abgesehen von anderen involvierten Entwicklern wahrscheinlich niemand auf der Welt versteht. Sicher, es gibt manchmal auch zumindest CVE-Nummern oder Bugzilla-IDs. Aber das ist definitiv zu selten und auch noch zu wenig. 

Eine vernünftige Beschreibung des des Problems bedeutet: Eine in vollständigen Sätzen formulierte Zusammenfassung des Problems. Dann einen Absatz, der definiert, welche Bedingungen erfüllt sein müssen, um davon betroffen zu sein. Dann muss ein Absatz folgen, indem die möglichen Auswirkungen des Problems beschrieben werden. Dann muss ein Absatz folgen, in dem mögliche Workarounds beschrieben werden für Leute, die nicht sofort patchen können. Zum Schluss muss beschrieben werden, wie das Problem behoben werden kann.

FreeBSD macht das vorbildlich. Microsoft macht das übrigens auch vorbildlich. Aber beim Linux-Kernel gibt es im wesentlichen nur Changelogs mit kryptischen Commit-Kommentaren. 

Ich stimme also hoschi insgesamt zwar nicht zu, aber wenn es so gemacht werden würde, wie ich das vorgeschlagen habe, also alle Patches einzeln zum Haupt-Release und mit klaren Beschreibungen, wer wann davon betroffen ist und wie schwerwiegend das dann sein kann, dann wäre vermutlich auch hoschi zufrieden. Dann könnte nämlich jeder selbst entscheiden, ob er den Patch sofort akut braucht oder nicht. Die meisten Leute müssten dann trotzdem nicht alle 4 Tage patchen und rebooten, weil nicht jeder von jedem Problem betroffen ist. Die Leute wären aber insgesamt besser informiert und insgesamt wahrscheinlich sogar besser abgesichert (etwa wegen Angabe von Workarounds und weil man sich auf die wirklich wichtigen Fälle konzentrieren kann).

----------

## mrsteven

 *sschlueter wrote:*   

> FreeBSD macht das vorbildlich. Microsoft macht das übrigens auch vorbildlich. Aber beim Linux-Kernel gibt es im wesentlichen nur Changelogs mit kryptischen Commit-Kommentaren.

 

Wie es bei FreeBSD gemacht wird, weiß ich nicht, aber das Vorgehen von Microsoft ist dafür in anderer Hinsicht einfach unter aller Sau. Sicherheitslücken müssen so schnell wie möglich gestopft werden, da kann man doch nicht auf irgendeinen blöden Patch-Day warten...  :Rolling Eyes: 

Aber prinzipiell gebe ich dir recht, es ist schon etwas - ahem - schwierig, die Änderungen zwischen zwei Releases (nicht nur innerhalb des "Sucker-Trees") nachzuvollziehen...

Dass bei einem neuen Patch die Versionsnummer erhöht wird ist eigentlich auch nur logisch... Wie gesagt, ich finde das prinzipielle Vorgehen ganz gut, nur wie du sagst, die Informationspolitik könnte etwas transparenter sein. Und die Versionsnummerierung etwas einfacher...

----------

## sschlueter

 *mrsteven wrote:*   

> 
> 
> Wie es bei FreeBSD gemacht wird, weiß ich nicht, aber das Vorgehen von Microsoft ist dafür in anderer Hinsicht einfach unter aller Sau.

 

Nur um Missverständnisse auszuschließen: Das bezog sich ausschließlich auf die Art der Fehlerbeschreibung. Und die ist bei Microsoft absolut vorbildlich.

Schau selbst:

Microsoft-Beispiel: http://www.microsoft.com/technet/security/Bulletin/MS06-013.mspx

FreeBSD-Beispiel: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:14.fpu.asc

----------

## schachti

Ich stimme sschlueter voll zu - Bugs sollten so schnell wie möglich bereinigt werden, das gilt umso mehr, wenn es sich um sicherheitskritische oder die Datensicherheit bzw. Stabilität beeinflussende Bugs handelt.

Für den durchschnittlichen Anwender, der vom Kernel nicht allzu viel Ahnung hat, sind in der Tat die Beschreibungen in den changelogs nicht ausreichend, um zu beurteilen, ob er updaten sollte oder nicht. Da sehe ich aber eher die Distributionen gefordert als die Kernel-Programmierer - mir ist es lieber, die Jungs kümmern sich um die Weiterentwicklung des Kernels, als daß sie stundenlang seitenlange Security Advisories schreiben.

----------

## hoschi

 *sschlueter wrote:*   

> 
> 
> Ich stimme also hoschi insgesamt zwar nicht zu, aber wenn es so gemacht werden würde, wie ich das vorgeschlagen habe, also alle Patches einzeln zum Haupt-Release und mit klaren Beschreibungen, wer wann davon betroffen ist und wie schwerwiegend das dann sein kann, dann wäre vermutlich auch hoschi zufrieden. Dann könnte nämlich jeder selbst entscheiden, ob er den Patch sofort akut braucht oder nicht. Die meisten Leute müssten dann trotzdem nicht alle 4 Tage patchen und rebooten, weil nicht jeder von jedem Problem betroffen ist. Die Leute wären aber insgesamt besser informiert und insgesamt wahrscheinlich sogar besser abgesichert (etwa wegen Angabe von Workarounds und weil man sich auf die wirklich wichtigen Fälle konzentrieren kann).

 

100% Akzeptanz

@schachti:

Die Verantwortung alleine auf die Distributionen zu legen halte ich nicht fur richtig, schon alleine aus dem Grund weil dann ein und der selbe Job mind. 100xmal von einer extra Person bei den Distributoren erledigt wird. Bei kernel.org koennte es dann einmal fuer alle gemacht werden, von den Leute die den Code kennen. Ich denke dir leuchtet das ein.

Die Distrubtoren sollte das ganze aber durchaus mit umsetzen und auch ein Auge darauf haben, einfach die Buildnummer zu aendern reicht ja auch nicht immer.

Ich weiss das Programmier faul sind "Zaehler++;", aber das schreibfaule Dokumentieren sollte man einigen echt austreiben, wenn es ein Feld gibt wo GNU/LINUX aufholen muss dann da  :Wink: 

PS: Der Patchday ist gemeingefaehrlich (Oracle, Microsoft), Software entwickelt man nach dem "When it's done" Prinzip und nicht nach eine Stundenplan (ich meine damit jetzt ausdruecklich keine Roadmap), auch fuer Bugfixes trifft sowas im groben Rahmen zu. All zu oft ist ein Pacht eben doch schmutzig, und dann muss man wieder nachbessern (siehe aktuelle MS).

----------

## sschlueter

 *schachti wrote:*   

> Da sehe ich aber eher die Distributionen gefordert als die Kernel-Programmierer - mir ist es lieber, die Jungs kümmern sich um die Weiterentwicklung des Kernels, als daß sie stundenlang seitenlange Security Advisories schreiben.

 

An dieser Stelle bringe ich gerne ein fieses Beispiel   :Twisted Evil: 

Das Problem ist, dass selbst die Distributoren nicht unbedingt wissen, welcher Bug kritisch ist und welcher nicht.

Das kann man an dem berühmten "Debian-Hack" von 2003 sehen. Dort ist ein bis zu dem Zeitpunkt unbekannter local root exploit eingesetzt worden, um mehrere Systeme aus der Debian-Infrastruktur zu kompromittieren. Weil auch der ausgenutzte Fehler unbekannt gewesen ist, hat man zunächst vermutet, dass es sich um einen der gefürchteten zero day exploits gehandelt hat. Letztendlich hat sich jedoch herausgestellt, dass der Fehler bei den Kernel-Entwicklern längst bekannt gewesen und auch bereits gefixt worden ist. Aber die Distributoren hatten einfach nicht gewusst, dass dieser Fehler kritisch ist - und die Kernel-Entwickler hatten es auch nicht für nötig gehalten, es irgend jemandem mitzuteilen.

http://www.debian.org/News/2003/20031202.de.html

 *Quote:*   

> Selbst obwohl dieser Kernelcode im September von Andrew Morton verbessert und bereits in einen aktuellen pre-release-Kernel seit Oktober kopiert ist, wurden die Sicherheitsauswirkungen der Verbesserung nicht betrachtet. Deshalb wurde von keinem Distributor ein Sicherheitsgutachten ausgestellt. 

 

----------

## UncleOwen

 *sschlueter wrote:*   

> und die Kernel-Entwickler hatten es auch nicht für nötig gehalten, es irgend jemandem mitzuteilen.

 

Vermutlich, weils sies selber nicht wussten. Was lernen wir daraus? Zu fordern, dass die Kernel-Entwickler Advisories rausgeben, ist 'ne schlechte Idee.

----------

## think4urs11

 *UncleOwen wrote:*   

>  *sschlueter wrote:*   und die Kernel-Entwickler hatten es auch nicht für nötig gehalten, es irgend jemandem mitzuteilen. 
> 
> Vermutlich, weils sies selber nicht wussten. Was lernen wir daraus? Zu fordern, dass die Kernel-Entwickler Advisories rausgeben, ist 'ne schlechte Idee.

 

Ergo müßte sich dem Advisory schreiben jemand annehmen der technisch in etwa auf Augenhöhe mit den Kernelentwicklern steht.

Da Leute in dieser 'Gewichtsklasse' aber i.d.R. deswegen so viel wissen weil sie selbst (lieber) coden als dokumentieren ist das Thema nicht ganz einfach zu lösen. Freiwillige zu finden die permanent die Changelogs incl. der Code-Änderungen durchgehen und anhand dessen zusammen mit dem Entwickler des Patches ein allgemeinverständliches ausführliches Advisory erstellen können dürften rar gesäht sein.

Andererseits klappt es bei *BSD ja augenscheinlich auch. Angeblich sind bei *BSD ja eher die langjährigen erfahrenen Gurus zu finden und bei Linux eher die jungen Wilden, keine Ahnung ob das so stimmt. (Nach der Logik muß ich demnächst in Richtung BSD verschwinden *g* ... womit ich aber nicht sagen will das ich mit Kernelgurus auf Augenhöhe bin... höchstens auf Hühneraugenhöhe)

Könnte aber ggf. ein Teil der Erklärung sein.

----------

## hoschi

Du beziehst dich doch auf das Slashdot-Interview von Linus und einem der BSD-Jungs, ich weiss den Namen nicht mehr  :Sad: 

Die Uebersetzung von heise.de war damals mehr als frei und gewagt, die haben da beiden Parteien Worte verdreht...brrrr

Inzwischen folge ich deswegen lieber mal den Links auf heise.de oder guck gleich bei slasdot/Konsorten, die Kernel-Bugs nach 2.6.8.1 hat heise.de auch "etwas aufgebauscht".

----------

## mrsteven

 *hoschi wrote:*   

> PS: Der Patchday ist gemeingefaehrlich (Oracle, Microsoft), Software entwickelt man nach dem "When it's done" Prinzip und nicht nach eine Stundenplan (ich meine damit jetzt ausdruecklich keine Roadmap), auch fuer Bugfixes trifft sowas im groben Rahmen zu. All zu oft ist ein Pacht eben doch schmutzig, und dann muss man wieder nachbessern (siehe aktuelle MS).

 

Vollkommen richtig, es ist ein großer Vorteil von Linux, dass das Entwicklerteam nicht irgendwelche Release-Termine einhalten muss, die sowieso meistens völlig unrealistisch sind...

Die Horrorgeschichten von Software-Entwicklern, die mehrere Nächte ohne Schlaf verbracht haben, sind ja ebenfalls bekannt. Übermüdete Programmierer können eben nicht gut programmieren, genau so wenig, wie übermüdete Piloten ein Flugzeug steuern können. Und rein menschlich ist das sowieso mehr als nur fragwürdig...  :Rolling Eyes: 

----------

## hoschi

Wir koennten jetzt ueber Gnome reden, aber wir lassen es besser  :Smile: 

----------

## Hilefoks

Moin,

richtig an den Ausführungen bisher finde ich, das Kernel-Updates besser dokumentiert werden sollten. Ob das allerdings möglich ist, dürfte zumindest fraglich sein. *sschlueter wrote:*   

> Dann könnte nämlich jeder selbst entscheiden, ob er den Patch sofort akut braucht oder nicht. 

 

Einzelne Patches halte ich allerdings für eine schlechte Idee. Was ist wenn ich 10 "unwichtige" Patches auslasse und den Patch Nr. 11 dann einspielen möchte? Wer garantiert dann das dieser Patch ohne die anderen funktioniert? Auf jeden Fall würde es eine Menge mehrarbeit für die Kernelentwickler bedeuten, - oder aber der ganze Vorteil der einzelnen Patches wär dahin.

Somit halte ich die aktuelle Lösung für Momentan am besten, - auch wenn die einzelnen Kernel-Updates durchaus besser beschrieben werden dürften.

Aber hier kann man, denke ich, auch ein wenig verantwortung den Distributionen übertragen. Und wenn meine Distribution mir diese arbeit nicht abnimmt und ich ebenfalls nicht bereit bin mir selbst diese arbeit zu machen - dann sollte ich die Distribution wechseln.

MfG Hilefoks

----------

## schachti

Ich halte es mit dem Kernel so, daß ich immer auf die aktuellste x86 Version der gentoo-sources update, sobald verfügbar - bisher bin ich damit sehr gut gefahren.

----------

## sschlueter

 *Hilefoks wrote:*   

> Einzelne Patches halte ich allerdings für eine schlechte Idee. Was ist wenn ich 10 "unwichtige" Patches auslasse und den Patch Nr. 11 dann einspielen möchte? Wer garantiert dann das dieser Patch ohne die anderen funktioniert?
> 
> 

 

Weil es Patches zum Release-Stand sind. Hatte ich doch geschrieben.

 *Hilefoks wrote:*   

> Auf jeden Fall würde es eine Menge mehrarbeit für die Kernelentwickler bedeuten, - oder aber der ganze Vorteil der einzelnen Patches wär dahin.
> 
> 

 

Naja, das hatten wir doch schon...

Wenn die Kernel-Entwickler es nicht machen, müssen es die Distributoren machen - was insgesamt betrachtet dann noch mehr Mehrarbeit bedeutet.

----------

## hoschi

 *Hilefoks wrote:*   

> Und wenn meine Distribution mir diese arbeit nicht abnimmt und ich ebenfalls nicht bereit bin mir selbst diese arbeit zu machen - dann sollte ich die Distribution wechseln.
> 
> MfG Hilefoks

 

Schau lieber nicht in das Verzeichnis der vanilla und gentoo-sources im Portage-Tree   :Cool: 

Ich koennte der Maintainer sein, so kahl wie es da ausschaut  :Very Happy: 

----------

## _hephaistos_

schön zu sehen, dass man NIX versäumt, wenn man lange nicht im forum is  :Wink: 

----------

## hoschi

 :Very Happy: 

----------

