Jetzt gibt es ein Meta Paket für linux-3.1, weil die Version 3.2 zuerst noch nicht ausgereift war. Der kernel linux-3.2 ist jetzt jedoch schon so schön und stabil. Und die Aussicht besteht, dass das noch besser wird besonders mit dieser Version (Ubuntu macht damit ein LTS), dass es gut wäre ein neues Linux Kernel Meta Paket anzubieten:
linux-image-siduction-stable, oder
linux-image-siduction-solid
mit dem die siduction Nutzer mit ihrem DU länger auf der version linux-3.2 hängen bleiben dürfen! Es könnte ein Meta Paket sein, was die Kernel allgemein erst eine Punkt-Version upgradet, wenn sich die Lage stabilisiert hat (zb .4).
... eine grundsätzlich interessante idee. Aber damit sie chancen hätte in die tat umgesetzt zu werden bedarf es wohl jemandes, der das team in dieser hinsicht auch tatkräftig und kompetent unterstützen würde ...
Finde es gut, wenn Dinge neu gedacht werden und bestehendes immer wieder in Frage gestellt wird. dafür schonmal +1 :-)
Die Frage ist, ob die Zielgruppe bei uns damit groß genug ist...
Die meisten, die ne rolling Distro möchten, nehemn auch den aktuellen kernel.
Allerdings fände ich einen solchen "stable"-kernel gut zu verwenden für meinen VDR. Denn bei dem brauche ich nicht immer das neuste. Wenn so ein VDR mal aufgesetzt ist und im Wohnzimmer seinen Dienst tut, dann braucht es im Grunde nur noch die Bugfixes - da wäre ein stabiler Kernel gut.
Hi zusammen,
die Idee fände ich gut wenn es einen "stabilen" Kernel bei Siduction geben würde. Eine Zielgruppe innerhalb der Community gibt es mit Sicherheit. Ist halt nur die Frage, wer das als Maintertainer dieses Paketes fachlich und zeitlich stemmen kann?
@bluelupo; Ich hab mir da schon mehrmals Gedanken zu gemacht - unter anderem, weil ich selbst so ein Teil haben möchte. Es ist mir einfach zu lästig, die Maschinen, die nicht die neueste Hardware haben oder die neuesten Optionen nicht brauchen, immer so hektisch zu aktualisieren.
Ich habe allerdings eher in die Richtung LTS-Kernel gedacht. Hätte für mich den Vorteil, wenn ich das wirklich mal zusammenklopfe, dass man damit relativ wenig Wartungsaufwand hat. Das würde meiner natürlichen Faulheit unbedingt zugute kommen.
Alternativ und für Towo wahrscheinlich die geringste Arbeit, einfach anders rum:
Für die, die den allerneuesten Kernel unbedingt sofort immer haben wollen, könnte es auch ein Meta-Paket "linux-image-siduction-frontrunner" geben. Und das normale Linux-Kernel Metapaket könnte dann bis mindestens zum .6 Release den bewährteren Kernel weiterlaufen lassen ...
Am wenigsten Arbeit ist es, einfach fast gar nichts zu machen. In anderen Worten: Wir verzichten auf fancy naming, nehmen im Normalfall den aktuellen Stable-Stand und alles bleibt beim alten.
Towo baut so oder so schon wie ein Wilder. Eine Idee wäre es, einfach mal die letzte Version des alten Stable im Repo zu lassen. bei der Namensgebung über 3.x-y sicherlich eine zu bewältigende Aufgabe. Persönlich finde ich die Idee eines LTS-Kernels so blöde nicht. Über die Ausrichtung müsste man reden. Da LTS, sollte der stockkonservativ aufgebaut sein und aus die Maus.
Ich fand die Idee immer Klasse, dass es bei Arch nur 1 Kernel gab, ohne dass man was tun musste. Für einen Rettungskernel musste selbst gesorgt werden, das hat der geneigte Neueinsteiger aber nach dem ersten fehlgeschlagenen Kernelupdate tief verinnerlicht. Das Vorgehen hat große Vorteile. Es ist einfach, verständlich, im Fall des Falles wird die Verwendung von Chroot geübt und es funktioniert reibungslos. Ich für meinen Fall habe mir angewöhnt, immer den LTS als Notnagel auf dem System zu lassen, das gibt so ein gewisses Gefühl der Sicherheit.
Quote from: "agaida"
[...]
Eine Idee wäre es, einfach mal die letzte Version des alten Stable im Repo zu lassen. bei der Namensgebung über 3.x-y sicherlich eine zu bewältigende Aufgabe. Persönlich finde ich die Idee eines LTS-Kernels so blöde nicht. Über die Ausrichtung müsste man reden. Da LTS, sollte der stockkonservativ aufgebaut sein und aus die Maus.
[...]
Hi agaida,
ja deine Idee finde ich gut, würde aber noch einen Schritt weitergehen und alle Stable-Kernel eines Release-Jahres im Repository belassen. Die Community hätte dann mind. 3 stabile Kernel parat die sich jederzeit installieren lassen.
Wäre so etwas vom Coreteam zu stemmen?
ich bin dafür wir stimmen darüber ab ob ralul *zwangsweise* dem siductionteam beigetreten wird um die LTS kernel zu pflegen.
community rulez
Sehe ich das richtig, Ihr wünscht quasi
linux-siduction-head <== immer mainline
linux-siduction-lts <== länger auf einem Branch, im Moment 3.2
??
Ins unreine gedacht: Was hindert uns daran. Ein Kernel wie der 3.1-x ist klinisch tot und wird sich nicht mehr ändern. Bei Erscheinen des stabilen 3.3 wird das mit 3.2-x ebenso sein. und so weiter. 2 oder 3 Versionen zu halten, sollte kein Problem sein. Genau aus diesem Grund habe ich den letzten 3.1 im Repo gelassen.
apt-get wird das Zeug nicht freiwillig installieren, da die neuen Kernel eigentlich bei allen, wenn sie denn wollen, per Meta-Paket um die Ecke kommen. Was mich bei aptosid gestört hat, war z.B. dass alte Versionen ohne Rücksicht auf Verluste aus dem Repo entfernt wurden.
Die Arch-Idee: Es gibt nur einen Kernel - kernel26 fand ich auch irgendwo ein wenig zu extrem. Da Arch aber ein Extrem an sich ist, war das auch nicht weiter schlimm, da mehr oder weniger offen für einen Reserve-Kernel geworben wurde. Irgendwo muss man bestimmt einen Schnitt machen, aber die letzten beiden Punkt-Releases stellen für mich kein mentales Problem dar. Wer dann das alte Zeug benutzen will, weiss, worauf er sich einlässt, dank git sollte es auch möglich sein, die jeweiligen End-Versionen zu taggen und im absoluten Ernstfall (wenn es wirklich nicht anders geht) auch noch mit Sicherheitspatches zu versorgen.
towo: Ich meinte mit lts wirklich den LTS-Kernel, der von Kroah-Hartman gepflegt wird. Wenn wir uns dazu entschließen sollten, würde ich mich auch um den kümmern. Der dann halt ohne Schnickschnack und einfach nur der Mainline folgen. Mit der von uns gewünschten Konfiguration. Ansonsten halt einen "Oldstable", der kein Brot frisst und der halt ein wenig länger im Repo bleibt.
Wie gesagt, nur so eine Idee ins unreine gedacht.
Quote
ich bin dafür wir stimmen darüber ab ob ralul *zwangsweise* dem siductionteam beigetreten wird um die LTS kernel zu pflegen.
Und wer pflegt dann das Team? :shock: :D
greetz
devil
Quote from: "devil"Quote
ich bin dafür wir stimmen darüber ab ob ralul *zwangsweise* dem siductionteam beigetreten wird um die LTS kernel zu pflegen.
Und wer pflegt dann das Team? :shock: :D
greetz
devil
... wußte gar nicht dass dies raluls bisherige aufgabe war ...
ähm, ja, ne, is klar :)
Quote from: "towo"Sehe ich das richtig, Ihr wünscht quasi
linux-siduction-head <== immer mainline
linux-siduction-lts <== länger auf einem Branch, im Moment 3.2
Ich meine es genau so!
Nur, dass ich statt linux-siduction-lts lieber einfach nur als default hätte:
linux-siduction
Ich habe dafür auch eine Begründung:
Irgendwo habe ich hier schonmal darüber einen Beitrag reingestellt, der davon handelte, dass GKH einen xfs Patch des xfs-Maintainers, der für eine bestimmte Version gedacht war, für alle Versionen, die GKH pflegt, aufgelegt hat. Prompt kam eine Mail, dass dies aber nicht und keinmal und überhaupt NICHt getestet war. Was sehe ich daraus: Man kann den Queue-Patches, die auch SLH immer sofort für alle genommen hat, überhaupt nicht trauen. Wenn man sie als default für alle einsetzt, schickt man alle in ein potentielles Minenfeld!
Aber:
Wenn du unbedingt eine neueste Linux-Punkt.Nuller Version einsetzen willst, bist du praktisch darauf angewiesen die Queue-Patches auch zu nehmen....
Nur um eine meiner Intentionen richtig darzustellen: Ich will einen LTS-Kernel haben. So einen: http://www.linux-archive.org/general-discussion-about-arch-linux-arch-general-archlinux-org/619264-new-lts-kernel-soon.html
Und der wird ganz sauber die Version 3.0.y haben. Und da ist aber auch nichts, wirklich nichts von meiner Seite mit irgendwas aus irgendwelchen Queues gedacht. Meine Intention ist: Erscheinen lassen, eine Woche oder so beobachten,bauen und veröffentlichen. Stressfrei. Wenn es da einmal im Vierteljahr ein Update geben muss, dann bin ich glücklich. Öfter brauch ich das nicht.
Und das scheint zu funktionieren. Der letzte Commit in den LTS-Kernel ist von 23. Dezember.
EDIT: Nochmal explizt - LTS als Long Term Support. Auf keinen Fall habe ich vor, irgendein Old-Stable-Zeug in irgend einer Art und Weise am Leben zu erhalten. Wenn wir uns entschließen, den jeweiligen letzten Vorgänger 3.x stehen zu lassen, dann hab ich nichts dagegen. Der frisst kein Brot und kann ganz sinnvoll sein. Eher möchte ich aber 3.x.y-1 stehen lassen. Was man damit erreichen will, sollte und muss aber lebhaft diskutiert werden.
Auch wenn es sich nicht so anhört: Ich habe im Allgemeinen recht wenig Spass an Kernelbau. Ich mache so was nur, wenn mir etwas sehr spezielles im Kernel fehlt, ich eine Extrawurst haben will und um nicht aus der Übung zu kommen. Dank der exzellenten Arbeit von Towo ist das Bauen von eigenen Kernels ausser zu Übungszwecken und weil man es mal gemacht haben muss, in Siduction wirklich eine recht sinnfreie Angelegenheit. Es gibt sehr viel andere Sachen zu tun, in die man überschüssige Zeit, wenn man die denn hat, reinstecken kann.
Nur zur Info: LTS-Kernel ist von meiner Seite gestorben. Ich habe einfach keine Lust mehr, meine Zeit mit dem Bau eines debiankonformen LTS-Kernels zu verschwenden. Dazu ist mir meine Restlebenszeit zu kostbar.
Den LTS Kernel für Deine Server hast du doch sowieso: Debian + Ubuntu linux-3.2