Login
Newsletter
Werbung

Thema: Stabile Kernelreihe auf Basis von 2.6.16 geplant

28 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Andi am Fr, 24. März 2006 um 11:03 #
Einem stabilen Kernel-API erteilt Bunk dennoch eine Absage. Änderungen von internen Funktionen sind also weiterhin möglich.

Und was für ein Sinn macht es? Es ist gerade die Stärke von Red Hat, SUSE oder Debian, dass sie mehrere Jahre lang den Kernel pflegen, ohne dass sie die Schnittstellen ändern. So können Hersteller ihre Systeme an die bestehende Kernel-Version anpassen. Wenn ich bei jedem Update des Kernels fürchten muss, dass meine alternativen Patches, Treiber und so weiter wieder nicht funktionieren, weil Schnittstellen geändert wurden, dann kann ich ja gleich die aktuellste stabile Variante des Kernels nehmen.

Andere Entwickler warnten bereits im Dezember vor dem Aufwand, den die Pflege eines solchen Kernels darstellt.
Haben auch recht, denn der Nutzen eines solchen "stabilen" Kernels ist gleich Null.

[
| Versenden | Drucken ]
  • 0
    Von Erik am Fr, 24. März 2006 um 11:32 #
    Das Adrien es nicht ausschließt, heißt nicht, daß er es tun will. Er verschließt sich halt nur nicht von vorn herein einer Entwicklung, die er nicht abschätzen kann. Ansich finde ich die Idee ganz gut, denn sie stabilisiert (prinzipiell) die API und versorgt den Zweig nachhaltig mit wichtigen Patches. Ich würde es aber vielleicht ein wenig anders anpacken.

    Anstatt jetzt den 2.6.16 willkürlich zu wählen und die danach folgenden Releases (2.6.17, etc.) nicht, würde sich eine Art Nachzugverfahren anbieten. Man wählt (beispielsweise) beginnend mit dem 2.6.16 die letzten fünf (sieben, zehn) Releases aus und versorgt diese an für alle Zweige geltenden halbjährlichen Terminen mit Updates (2.6.16.1, 2.6.16.2, ...), bis sie irgendwann unten rausfallen, neue stabile Releases rücken automatisch von oben nach. So binde ich relativ wenige Leute, deren Arbeitsaufwand auch geringer wird, je älter der von ihnen gewartete Zweig ist und schaffe für den Anwender/Distributor eine einfache Möglichkeit, seiner Anschauung über Stabilität und Neuheit der Features Rechnung zu tragen, indem er jeweils an einer für ihn "sinnvollen" Stelle in die jeweilige Benutzung eines Zweigs einsteigt. Und jene, die gerne eine stabile API haben, verfolgen einen Zweig von Anfang bis Ende und machen dann einen größeren Sprung, wenn ihr Zweig wegfällt.


    lg
    Erik

    [
    | Versenden | Drucken ]
    0
    Von Jochen Schmitt am Fr, 24. März 2006 um 11:43 #
    Gerade die NIchexistenz einer stabilen Kernel-API ist nach meiner Meinung ein Hinderungsgrund für die Entwicklung von Gerätetreibern durch kommerzielle Firmen. Entwickler solcher Treiber müssen ständig damit rechnen, dass durch Änderungen der Kernel-API eine Anpassung des Treibers notwendig wird.

    Nach meiner Meinung wäre es sinnvoll, wenn es wieder zwei Entwicklungszweige beim Linux-Kernel gäbe:

    Eine, der eine stabilen Kernel-API besitzt und bei dem nur Änderungen vorgenommen werden, durch die diese Stabilität nicht verletzt wird.

    Der andere Zweig würde dann zur Fortentwicklung des Kernels dienen, wobei eine Änderung der Kernel-API aufgrund der Fortentwicklung möglich wäre.

    mfg: Jochen Schmitt

    [
    | Versenden | Drucken ]
    • 0
      Von api am Fr, 24. März 2006 um 12:20 #
      aja dann fang an und schreibe eine. dass es keine gibt, bedeutet doch nur, dass die mehrheit der entwickler keine will. durch eine feste api wird halt die weiterentwicklung des systems verlangsamt, was nicht im interesse der entwickler ist.
      [
      | Versenden | Drucken ]
      • 0
        Von glasen am Fr, 24. März 2006 um 15:28 #
        Das ist der größte Blödsinn den ich je gelesen habe.

        Eine feste und stabile API würde es Dutzenden von Treiberentwicklern leichter machen, sich auf das Wesentliche zu konzentrieren, nämlich die Entwicklung und Stabilisierung des Treibers und nicht dem Anpassen an jede neue Kernelversion.

        [
        | Versenden | Drucken ]
        • 0
          Von my2cent am Fr, 24. März 2006 um 19:34 #
          ...würde es den _propitaeren_ Treiberentwicklern leichter machen...
          [
          | Versenden | Drucken ]
          • 0
            Von G. W. am Fr, 24. März 2006 um 20:51 #
            Herzlichen Glückwunsch zur abermaligen Verfehlung des Themas.

            1. Auch _proprietäre_ Treiber können in Form von Quelltexten verbreitet werden (quelloffen != frei), d.h. die Nichtexistenz einer stabilen ABI erschwert die Nutzung proprietärer Treiber _nicht_

            2. Die Nichtexistenz einer stabilen ABI erschwert nicht nur die Verbreitung proprietärer, sondern auch die Verbreitung _freier_ Treiber in binärer Form

            3. Nein, die Migration aller freier Treiber, die irgendwo auf der Welt existieren, in das kernel.org-Repository ist _kein_ gangbarer Weg

            4. Es gibt auch Kunden, die eigene Kernelmodule nur für den Eigengebrauch entwickeln - diese müssen sie gemäß Freiheit 0 selbstverständlich _nicht_ veröffentlichen, weder frei oder proprietär oder sonstwie - an genau diese Kunden richten sich die Angebote von RedHat, Novell und anderen

            [
            | Versenden | Drucken ]
            • 0
              Von DoomWarrior am Fr, 24. März 2006 um 21:13 #
              nein eine stabile ABI erschwert nicht das verbreiten freier Software. Das würde nur eine instabile API schaffen!
              [
              | Versenden | Drucken ]
              0
              Von my2cent am Fr, 24. März 2006 um 21:41 #
              Nur mal so zur Information: API != ABI. In diesem Beitrag ging es um das API, womit die Kompatibilität auf Quellebene gemeint ist und nicht die Kompatibilität der Schnittstellen auf binärer Ebene.
              Wie war das mit der Verpfehlung des Themas? :-)
              [
              | Versenden | Drucken ]
      0
      Von L00NIX am Mo, 27. März 2006 um 15:28 #
      Hallo.

      > Gerade die NIchexistenz einer stabilen Kernel-API ist nach
      > meiner Meinung ein Hinderungsgrund für die Entwicklung von
      > Gerätetreibern durch kommerzielle Firmen. Entwickler solcher
      > Treiber müssen ständig damit rechnen, dass durch Änderungen
      > der Kernel-API eine Anpassung des Treibers notwendig wird.

      Zum Thema festgelegte, binäre Schnittstellen innerhalb des
      Kernels kann man sich mal folgendes zu Gemüte führen, bevor
      sinn- und planlos weiter diskutiert wird: Stable API Nonsense

      Aus dem verlinkten Text:
      Die externen Schnittstellen, also die, auf die Treibermodule
      aufbauen, sind fest und das schon lange.

      Allein aufgrund der Plattformunabhängigkeit wegen ist eine
      binäre Schnittstelle blödsinnig.

      Gruß
      L00NIX

      [
      | Versenden | Drucken ]
    0
    Von düse am Fr, 24. März 2006 um 11:50 #
    Es ist wohl besser wenn es eine offizielle Serie gibt, vor allem für die Leute die sich selber Kernel compilieren. Der Standard-Kernel ist immer noch sehr viel stabiler als das was sich bei SUSE und Fedora findet. Viele kleine Distros haben keine eigenen Kernel, die dürfen sich jetzt freuen. Ich sehe eigentlich überhaupt keinen Grund den Kernel zu patchen, es wäre ja technisch auch gar nicht möglich dass deine Patches weiterfunktionieren. Der Nutzen eines solchen Kernels ist sehr hoch, da die Stabilität höher wird. Ich weiss ja nicht ob dir der Begriff "Server" was sagt, aber speziell dort ist es ein grosses Ärgernis wenn man asu Sicherheitsgründen den Kernel updaten muss, noch ärgerlicher ist es wenn man in einen neuen Zweig ändern muss. Bin mir auch sicher, dass es sehr viele server gibt die auf den "standard"-kernel setzen anstatt auf irgendwelche patches.
    [
    | Versenden | Drucken ]
    • 0
      Von Andi am Fr, 24. März 2006 um 12:26 #
      Ja, Server sagt mir etwas und entgegen Deiner Aussage sind die Kernels in RH oder SUSE Enterprise-Varianten stabiler als die der offiziellen Serie.

      Ich sehe eigentlich überhaupt keinen Grund den Kernel zu patchen
      Nur weil Du es nicht siehst, soll es auch nicht heissen, dass auch keinen gibt. Ich habe meine Gründe und die sind bei mir durchaus berechtigt, denn ohne einen separaten Treiber wir meine ganze Raid-Struktur nicht funktionieren. Ohne separate Patches darf ich bei jedem Kernel-Release die komplette Struktur der Server validieren, nur weil ich eine Luecke schliessen musste. Wozu? Ich habe keine neue Funktion gebraucht? Soll ich also neue Funktionen einbauen, potentielle Fehlerquellen einschleusen nur weil ich eine Luecke schliessen wollte?

      Bin mir auch sicher, dass es sehr viele server gibt die auf den "standard"-kernel setzen anstatt auf irgendwelche patches
      Na dann viel Spass. Setzte Dich nur eine Sekunde mit Enterprise-Varianten von Distributionen und Du wirst sehr schnell feststellen, dass es ein Fehler ist auf den "stabilen" Kernel zu setzen. Bestes Beispiel ist die do_replace()-Lücke, die im Kernel 2.6.16 gefixt wurde und auch in frueheren Versionen vorhanden ist. Ohne einen Patch für meine stabile und validierte Kernel-Version darf ich den kompletten Kernel updaten. Darauf folgt eine Validierung der kompletten Systeme und so weiter...

      Aus diesem Grund liefern Red Hat oder SUSE immer eine und die selbe Version des Kernels, die sich in den Schnittstellen nie aendern wird. Man erstellt ein binaeres Modul zum Beispiel fuer den Raid-Controller oder fuer die Netzwerkkarte und ist sich auch nach einem Update des Kernels sicher, dass das Modul genauso funktioniert wie zuvor.

      [
      | Versenden | Drucken ]
      • 0
        Von fuffy am Fr, 24. März 2006 um 15:41 #
        Für die wenigsten dedizierten Server sind zertifizierte Distributionen notwendig. Wer installiert z.B. SAP R/3 auf dem Rechner, der die Firmenwebsite beherbergt? ;-)

        Ohne einen Patch für meine stabile und validierte Kernel-Version darf ich den kompletten Kernel updaten.
        Warum hast du nicht einfach den Patch auf die stabile Kernel-Version angewandt?

        Man erstellt ein binaeres Modul zum Beispiel fuer den Raid-Controller oder fuer die Netzwerkkarte und ist sich auch nach einem Update des Kernels sicher, dass das Modul genauso funktioniert wie zuvor.
        Problematisch ist, dass RedHat und SUSE den Kernel-Version-String ändern und so die Module mit modprobe -f geladen werden müssten, damit sie nicht vom Kernel Module Loader abgewiesen werden. Deshalb wird auch nach jedem Kernelupdate das Kernelinterface neu kompiliert, obwohl das eigentlich nicht notwendig wäre.

        [
        | Versenden | Drucken ]
      0
      Von Random Debian Developer am Fr, 24. März 2006 um 12:46 #
      > Der Standard-Kernel ist immer noch sehr viel stabiler als das was sich bei SUSE und Fedora findet.

      Du hast keine Ahnung.

      [
      | Versenden | Drucken ]
      0
      Von G. W. am Fr, 24. März 2006 um 21:02 #
      > Der Standard-Kernel ist immer noch sehr viel stabiler als das
      > was sich bei SUSE und Fedora findet.

      Ja, genau. Die Patcherei von SuSE und Fedora ist komplett sinnlos, fügt keine Features hinzu, die nachgefragt sind, fixt keine Bugs, sondern führt nur neue Bugs ein und wird von den Distributoren ausschließlich als Arbeitsbeschaffungsmaßnahme genutzt. Außerdem patchen SuSE und Fedora unendlich viel am Kernel rum, Debian, Ubuntu und kleinere Distributionen dagegen überhaupt nicht.

      Außerdem haben die Patcherei-Zuständigen dieser Distributoren keine Ahnung, welche Patches gut und welche nicht gut sind, weil die Patcherei-Zuständigen keine Kernel-Entwickler sind und nicht von Red Hat bzw. Novell dafür bezahlt werden, am Kernel zu arbeiten. Ferner sind die Überzahl dieser Patches weder Backports aus einem Entwicklerzweig noch werden sie früher oder später in den Vanilla-Kernel übernommen, sondern sind lediglich proprietäre Änderungen, die ausschließlich dazu dienen, inkompatibel zur Restwelt zu sein und die Stabilität des Kernels zu verschlechtern.

      > Viele kleine Distros haben keine eigenen Kernel, [...]

      Richtig, die übernehmen ja schließlich 1:1 die Kernel-Quellpakete von Fedora oder Debian. Inklusive der Patches.

      > Ich sehe eigentlich überhaupt keinen Grund den Kernel zu patchen, [...]

      Dann mach doch mal ein Praktikum beim Linux-Distributor bei der Wahl. Vielleicht siehst Du den Grund dann, vielleicht genügt aber auch ein kurzer Blick ins Quellpaket des Kernels Deiner Lieblingsdistribution. Dabei ist es übrigens unerheblich, ob diese Lieblingsdistribution SuSE, Fedora, Debian oder Ubuntu heißt, weil die Qualität und Quantität der Patches dieselbe ist. Alternativ kannst Du auch ein Unternehmen gründen, das sich mit der Verteilung von Linux-Distributionen und Dienstleistungen rund um diese befasst, und mit Hilfe dieses Unternehmens den Beweis antreten, dass es auch ohne Patches geht. Viel Erfolg.

      [
      | Versenden | Drucken ]
0
Von Udo am Fr, 24. März 2006 um 11:17 #
Dann könnten sie sich Arbeit beim Kernel-Updaten die nächsten 5 Jahre teilen. Aber ich glaube kaum die geben ihren getunten 2.6.15.5 jetzt noch auf.

Eigentlich schade, dass das terminlich nicht passt.

[
| Versenden | Drucken ]
mehr 2.7
0
Von me² am Fr, 24. März 2006 um 11:37 #
Kommt eigentlich irgendwann mal 2.7 oder wird es irgendwann 2.6.465456.1 sein?
[
| Versenden | Drucken ]
  • 0
    Von troll am Fr, 24. März 2006 um 14:16 #
    2.7 gibt es schon und heißt 2.6.
    [
    | Versenden | Drucken ]
    • 0
      Von skyhy am Fr, 24. März 2006 um 15:22 #
      ist den der 2.8 schon irgentwie angekündigt das er in naher zukunft kommen wird?
      [
      | Versenden | Drucken ]
      • 0
        Von troll am Fr, 24. März 2006 um 15:58 #
        Wozu das denn?

        Ein Entwicklungskernel macht doch viel mehr Spaß:
        neue Features implementieren, und Fehler/Bugs erst mal liegen lassen:

        If it compiles, it is good, if it boots up it is perfect!
        (Linus Torvalds)

        [
        | Versenden | Drucken ]
    0
    Von sq am Fr, 24. März 2006 um 16:38 #
    nöe, eher (2.6.x.y)²
    [
    | Versenden | Drucken ]
0
Von Mario am Fr, 24. März 2006 um 15:35 #
Irgendwie erinnert mich das ganze an den letzten Versuch von Andres Salomon mit dem Kernel 2.6.10 (http://www.pro-linux.de/news/2005/7713.html). Mal schauen, wie lange es Bunk "aushalten" wird.
[
| Versenden | Drucken ]
0
Von Andre Homberg am Fr, 24. März 2006 um 15:44 #
Hallo,
ansich kann ich diesen Schritt nur begruessen. Noch besser faend ichs wenn der Kernel im selben Tree zumindest kompatibel bleiben wuerde. Klar dann wuerden groessere Aenderungen erst deutlich spaeter integriert. Aber das Problem fuer mich ist nun , ich moechte Debian-Stable einsetzen. Leider war zu Kernel2.6.8-Zeiten noch keine 100% saubere SATA-Unterstuetzung vorhanden. Wenn ich nun SATA-Festplatten einsetzen moechte, muss ich einen neuen neueren Kernel installieren, und stehe dann vor dem Problem das etliche Programm mit geupdatet werden muessen. Das war imho zu Kernel-2.4-Zeiten einfacher.

Gruss,
André Homberg

[
| Versenden | Drucken ]
mehr hmm
0
Von Patrick am So, 26. März 2006 um 05:21 #
hmm, also ich verstehe das nicht, warum die dort meinen, dass das backen vom kernel immer schwieriger wird.
wenn man nun eine komplett neue config erstellt, dann wird es so sein, da es verdammt viele optionen gibt, die ja auch nötig sind. aber wenn ich zB einen sprung von 2.6.14 auf 2.6.16 mit make oldconfig durchführe, finde ich das überhaupt nicht schwer.

greetz by http://www.linux-development.org

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung