Sven Hartge <[EMAIL PROTECTED]> writes: > Das wäre dann gegeben, wenn der neue Kernel keine Änderungen in z.B. > udev nötig machen würde. Verblüffend finde ich da eher, das solcherlei > Änderungen in der stabilen Kernel-Server stattfinden, aber das ist, wie > du schon schreibst, nicht Debians Fehler.
Greg KH schreibt, es waere ein alter fehler in sysfs. ich habe das nicht bemerkt, da ich udev auf servern nicht verwende. es zwischen -rc6 und dem endgueltigen kernel einfliessen zu lassen halte ich fuer das wirkliche problem, aber der grosse guru ist ja der meinung, namen seien schall und rauch, und 'rc' habe nichts mit 'release candidate' zu tun. arggh. > Allerdings muss sich Debian der neuen Methode, den Kernel zu entwickeln, > anpassen und z.B. auch für das stabile Sarge Updates für z.B. udev (oder > die module-init-tools, oder ...) herausbringen, selbst wenn dies heißt, > das eine neue Version des Tools ausgeliefert werden muss. muss? nein, sehe ich anders. 2.6.8-debian ist erstmal ganz in ordnung und reicht noch locker fuer ein, anderthalb jahre auf produktiven maschinen. auf meinen persoenlichen daddelkisten werde ich weiterhin auch so sachen wie 2.6.current mit zwei, drei cvs-sachen fahren, aber da kann ich kleinkram auch aus Sid nehmen. > volatile.debian.net wurde ja für solche moving targets ins Leben > gerufen. > > Was für spamassassin, amavisd, clamav, whois etc. gut ist, sollte auch > für udev oder die module-init-tools oder ... möglich sein, selbst wenn diese > in > base sein sollten. ueber spamass werde ich mich nur aeussern, wenn ich meine pillen genommen habe, die anderen sind fuer ein stable sehr nuetzlich. aktuelle kernel sind _nicht_ nuetzlich, da immer irgendwas neues kaputt gedaddelt wird, eben weil kaputtdaddeln das neue modell ist. wenn entwickler das fuer volatile pflegen wollen: bitteschoen. ich halte das weder fuer sinnvoll noch fuer notwendig. > Mehr möchte ich ja nicht. > > Es wäre doch schon sehr peinsam, wenn man auf dem "universal operation > system" keinen aktuellen Betriebsystemkern benutzen könnte, sondern auf > den Stand des Releases festgenagelt ist. Linus sagt, es sei aufgabe der distributoren, stabile kernel zu veroeffentlichen. Debian hat das mit 2.6.8-debian fuer Sarge getan und wird das mit unknown-debian fuer Etch auch wieder tun. fuer die masse der user (bzw. masse der maschinen) sehe ich keinen bedarf an schnelleren kernelupdates. -- frobnicate foo
