Also wie Morton schon richtig sagt, es sei jedem selbst überlassen den Kernel neu zu übersetzen und nur das zu laden was man wirklich auf dem jeweiligen System braucht. Ich halte es schon für richtig das Multimedia modultechnisch eine grosse rolle im Linux Kernel spielt denn gerade das ist das, was Desktop User haben wollen - das ihre XYZ Hardware vollständig unterstüzt wird (wem nutz da ein "Server-Kernel" ?)
Und wenn ihm die Entwicklung nicht passt, soll er doch einen Kernel-Server-Fork starten.
Der einzigste Clown der hier betitelt werden dürfte bist Du mit deinem absolut sinfreien Kommentar. FreeBSD ist Performance technisch den anderen BSD's überlegen siehe dazu:
Es ist schön zu sehen, dass es wohl keine User von Betriebssystemen gibt, die nicht andauernd sagen: "Mein ist besser als Deins! Nänänänä und ätschebätsche!" Jungs macht doch einfach einen Schwanzvergleich, wenn Ihr Euch messen wollt, aber lasst bitte die Betriebssysteme da raus! Vielen Dank für Euer Verständnis! Gruß Bernd
WIR brauchen unsere Nudeln nicht zu vergleichen. Aber bei Dir scheint das ja eine fixe Idee zu sein, vielleicht solltest Du es mal mit plastischer Chirurgie versuchen.
Wieso schreibt er denn Unfug ? Ich finde, er hat völlig recht. Und wer jetzt nur an die Treiber selbst denkt ("dann baut man sich halt einen Kernel ohne die Treiber"), der greift viel zu kurz. Interessant ist nämlich auch die Frage, wie oft z.B. Server-Features und auch -Fixes nicht in ein neues Kernel-Release kommen, weil andere, für Server (oder auch professionelle Workstations) völig uninteressante Funktionen vorgezogen werden und ja nun mal die Resourcen an Kernel-Maintainers begrenzt sind. Ich vermute mal, daß das ziemlich häufig vorkommen wird. Überhaupt ist diese ganze Eigenen-Kernel-Bauen-Einstellung in meinen Augen eine ziemlich üble Sache. Wer testet denn solche selbstgebackenen Dinger ? Ich meine damit richtige (Regressions-)Tests und nicht "Tests" ala "kompiliert ohne Fehler, Rechner fährt hoch - getestet !". Wer übernimmt denn die Verantwortung, wenn z.B. ein Datenbank-Server mit einem solchen selbsgepanschten Kernel abraucht und sich dann herausstellt, daß durch "Rausoptimieren" von angeblich unnützen Features/Treibern einige Dateien korrupt sind ? Und selbst ohne bleibende Folgen ist so ein Absturz schon eine unangenehme Sache, wenn da z.B. der Kundenservice mit 300 Mitarbeitern draufhängt und plötzlich ohne Datenbasis dasteht (denn die Kunden rufen dennoch an) ?
Vielleicht sollten sich die Herrn Kernel-Gurus langsam mal Gedanken machen, wie sie den Linux-Kernel aufbaumäßig endlich ins aktuelle Jahrtausend migrieren. Hardware-Treiber haben nun mal nix im Kernel zu suchen (philosophische Betrachtungen jetzt mal außen vorgelassen). Würde man sich bei Linux wirklich nur auf die Funktionalität beschränken, wenn dürften die Kernel-Maintainer mit einem Schlag viel weniger Arbeit haben (da sie ja nicht mehr jeden dämlichen Treiber in den Kernel-Code flicken müssen) und könnten sich stattdessen voll auf die eigentlichen Aufgaben eines Kernel konzentrieren. Hardware-Hersteller könnten - wie bei anderen Betriebssystemen auch - einfach Treiber mit ihrer Hardware ausliefern und via simplem Skript (z.B. durch Kopieren in ein festgelegtes Verzeichnis) auf dem Zielsystem installieren, ohne erst am Kernel rumfummeln zu müssen oder sich mit den Maintainers rumschlagen zu müssen, damit der Treiber reinkommt. Die Distributoren müßten dann nicht mehr für jeden Zweck einen eigenen Kernel bauen (und pflegen !!!), sondern würden einfach mal diese, mal jene Treiber installieren (ein Server braucht keine Unterstützung für Sound oder Graphik, ein Arbeitsplatzrechner wohl kaum Treiber für Server-Chipsets, die niemals in einem normalen PC verbaut werden. Damit sollte sich auch die Zeit, die Linux zum Hochfahren benötigt, deutlich reduzieren lassen - ohne daß man sich einen "optimierten" Kernel baut.
Eigentlich sehe ich nur Vorteile, wenn man diesen ganzen Treiberschlunz aus Linux rausoperieren würde. Als für mich angenehmen "Nebeneffekt" würde vermutlich endlich auch eine definierte stabile (!) Schnittstelle zwischen Treiber- und eigentlichem Kernel-Code rausspringen, denn sonst bringt das alles für die Kernel-Maintenance nicht wirklich was. Und vermutlich wird dies einer der Gründe sein, weshalb wohl Treiber bis ans Ende aller (Linux-)Tage im Kernel bleiben werden und dort Arbeit und Ärger machen. Denn es werden sich wieder jede Menge (meist selbsternannte) Experten finde, die zu wissen glauben, daß eine stabile Treiberschnittstelle nicht möglich ist (bei anderen Betriebssystemen geht das zwar, aber das ist natürlich was ganz anderes ...) oder die Linux sofort im ganz ultra bösen Closed-Source-Sumpf versickern sehen, weil man ja dann ohne weiteres Treiber verwenden kann, deren Source-Code nicht offengelegt ist.
Ich finde es schon erstaunlich, dass gerade die Techniken kritisiert werden vor denen sich M$ wahrscheinlich am meisten bei Linux fürchtet. Aufholen/Überholen im Multimediabereich, der im Grunde ja der einzige technische Vorteil von Windows ist und die Entwicklung einer leistungsfähigen Virtualisierungslösung, deren Bedeutung M$ ja dadurch den Kauf von Virtual PC dokumentiert hat.
Also, ich weiß ja nicht was nicht, was du genau Aufbaumäßig mit dem aktuellen Jahrtausend meinst. Also erstens ist Linux schon von Anfang an aufbaumäßig nicht auf der Höhe der Zeit, wie schon die Diskussion zwischen Andrew S. Tannebaum und Linus Torvalds auf der damaligen Minix Liste zeigt (Microkernel vs. Monolithischer Kernel). Aber die Praxis zeigt, es funktioniert. Während jede menge technologisch überlegene Betriebssysteme (z.B. Hurd) über eine absturzgefährdete Kommandozeile kaum hinauskommen, funktioniert Linux prächtig. Da wäre es doch mal an der Zeit die Theorie zu überdenken.
Ich denke, dass es durchaus ein Vorteil von Linux ist, dass die Treiber mit dem Kernel entwickelt werden.
1. ist deine Idee solange zu warten, bis die Hersteller ihre Hardware mit Treibern für Linux ausliefern ziemlich illusorisch und würde wohl eher den Tod von Linux durch fehlende Hardwareunterstützung bedeuten.
2. Sorgt dies meiner Ansicht nach für Stabilität. Denn die Treiber müssen ja Zugriff auf die Hardware haben und können damit jede Menge instabilitäten verursachen, wenn sie schlecht programmiert sind. Das hat ja auch schon M$ gemerkt und deshalb Prüfungen mit anschließender Signatur durch Microsoft eingeführt. Die Treiberentwicklung den Hardwareherstellern zu überlassen, die weniger vom Kernel verstehen, als die Kernelprogrammierer, würde deshalb wohl zu erheblichen Instabilitäten führen. Abgesehen davon, ist es
3. so, dass defakto einige Firmen die Treiber programmieren und anschließen an die Kernel Entwickler schicken, die sie dann integrieren (oder auch nicht). Also kann man das ganze so ähnlich wie die Treibertests und Signierung von Microsoft, also so eine Art Qualitätssicherung sehen. Nur gescheit programmierte Treiber werden in den offiziellen Kernel aufgenommen.
Wenn du der Ansicht bist, dass es ganz gut geht eine definierte stabile(!) Schnittstelle zur Treiberprogrammierung zu definieren, dann hält dich keiner davon ab es zu tun und an die Kernel Entwickler zu schicken. Ich bin sicher sie werden sich über deine Beiträge freuen. Wenn du es nicht kannst, dann solltest du vielleicht nich über Dinge reden, von denen du nichts verstehst.
Ich weiß jetzt nicht, ob Du "... dass gerade die Techniken kritisiert werden ..." auch auf mich beziehst, wenn ja, verstehe ich nicht wieso, denn ich kritisiere ja in keinster Weise, daß sich Linux in Sachen Fähigkeiten weiterentwickelt. Mir geht es nur um die Art und Weise, bzw. anderes gesagt, müßte man bei neuen Linux-Versionen nicht jedesmal noch den ganzen Treiberschlunz mitschleppen, wäre Linux vielleicht schon viel weiter als heute.
1. ist deine Idee solange zu warten, bis die Hersteller ihre Hardware mit Treibern für Linux ausliefern ziemlich illusorisch und würde wohl eher den Tod von Linux durch fehlende Hardwareunterstützung bedeuten.
Davon war doch gar keine Rede. Treiber können nach wie vor mit dem Kernel ausgeliefert werden, von mir aus kann dieser Grundbestand an Treibern auch von den Kernel-Maintainers gewartet werden. Aber darüberhinaus wäre es für Drittanbieter - neben dem Kernel-Maintainer und dem Distributor - deutlich einfacher, einen neuen Treiber in ein laufendes Linux-System zu integrieren (z.B. eben durch das einfach Kopieren in ein speziell benamstes Verzeichnis).
2 und 3
Nichts anders habe ich auch geschrieben (3), und daß Treiber durchaus die Systemstabilität gefährden können (2) ist mir durchaus bekannt, darum ging es doch auch dem guten Sam. Bloß, die Stabilität wird ganz sicher nicht dadurch schlechter, wenn ich statt 1000 nur noch 50 Treiber im System habe, oder siehst Du das etwa anders ? Und was ich mir nicht so ganz vorstellen kann, ist, daß die Kernel-Maintainer wirklich jeden Treiber logisch nachvollziehen. Die mögen auf gewisse Dinge achten, aber sicher nicht darauf, daß der Treiber keine Bugs enthält (außer vielleicht ganz offensichtliche).
Wenn du der Ansicht bist, dass es ganz gut geht eine definierte stabile(!) Schnittstelle zur Treiberprogrammierung zu definieren, dann hält dich keiner davon ab es zu tun und an die Kernel Entwickler zu schicken. Ich bin sicher sie werden sich über deine Beiträge freuen.
Es gibt Betriebssysteme, die bereits seit langem eine definierte stabile (!) Schnittstelle zur Treiberprogrammierung besitzen. Es ist daher denke ich müßig, darüber zu diskutieren, ob ich der Ansicht bin, daß es geht, oder eben nicht, einfach deshalb, weil es völlig unerheblich ist, ob ich es so sehe oder nicht.
Wenn du es nicht kannst, dann solltest du vielleicht nich über Dinge reden, von denen du nichts verstehst.
Ah ja, wieder die übliche Schiene: ich kann es nicht gleich programmieren oder wenigstens exakt beschreiben, also soll ich doch besser die Klappe halten, da ich ja gar keine Ahnung davon habe (wovon eigentlich ?). Hätte ich geschrieben, daß das jetztige Treibersystem von Linux toll ist, hättest Du das wahrscheinlich geschrieben. Aber das wäre ja auch keine Kritik gewesen ...
Davon war doch gar keine Rede. Treiber können nach wie vor mit dem Kernel ausgeliefert werden,... Bloß, die Stabilität wird ganz sicher nicht dadurch schlechter, wenn ich statt 1000 nur noch 50 Treiber im System habe, oder siehst Du das etwa anders ?
Also hier verstehe ich nicht ganz wie du das meinst. Ich kann den Kernel kompilieren wie ich will. Entweder mit 1000 oder mit 50 Treibern fest einkompiliert. Ich kann die meisten auch als Modul kompilieren, die bei Bedarf hinzugeladen werden. Was stört es mein System, wenn da in einem Verzeichnis ein Modul darauf warted gebraucht zu werden ohne das es jemals zur Ausführung kommt auch wenn es vielleicht 1000 sind? Und das Beste: du must gar keine Datei mehr in ein Verzeichnis kopieren (was allerdings auch funktionert) um den Treiber zur Laufzeit zu starten. Er ist schon da.
Oder meinst du es sollten nur noch insgesamt 50 Treiber in der Kernel Source integriert werden. Da wären wir wieder bei Punkt 1.
Es gibt Betriebssysteme, die bereits seit langem eine definierte stabile (!) Schnittstelle zur Treiberprogrammierung besitzen.
Welche meinst du denn? Und welche Vorteile haben sie deiner Meinung nach?
Ah ja, wieder die übliche Schiene: ich kann es nicht gleich programmieren oder wenigstens exakt beschreiben, also soll ich doch besser die Klappe halten
Wenn du diese "übliche" Schiene schon öfter erlebt hast, dann ist ja vielleicht auch was dran?
Aber hast du dir schon mal überlegt, dass solche kritik so ankommen kann als würdest versuchen Beethoven kompositionsunterricht zu geben indem du sagst: "Hey, mach mal schöne Musik, so wie der Mozart sie macht".
Ansonsten finde ich Kritik prima. Je konstruktiver desto besser;-)
Oder meinst du es sollten nur noch insgesamt 50 Treiber in der Kernel Source integriert werden. Da wären wir wieder bei Punkt 1.
Eigentlich meine ich mehr oder weniger genau das. Für mich haben Gerätetreiber generell nichts im Kernel zu suchen (was aber nichts damit zu tun hat, daß sie vom Kernel geladen und verwaltet werden). Bei Treibern für z.B. Motherboard-Chipsets würde ich da vielleicht Ausnahmen machen, weil es womöglich zu aufwändig sein dürfte bzw. man sich zu sehr an platformabhängige Legacy-Funktionen klammern müßte, um die auch rauszuziehen. Aber Treiber für Geräte wie Graphik-, Sound-, Netzwerk- oder andere Karten will ich nicht im Kernel selbst sehen (denn eigentlich haben sie mit dem Kernel selbst ja nix zu tun, sie kommunizieren ja nur mit ihm - so wie eigentlich jedes gewöhnliche Programm). Das bringt natürlich einen gewissen Aufwand mit sich, aber ich denke, längerfristig lohnt sich das, weil die Kernel-Entwickler einfach einiges an Arbeit von der Backe haben.
Nebenbei finde ich das Handling via "in Verzeichnis rein" bzw. "aus Verzeichnis raus" deutlich angenehmer, als am Kernel rumzuwursteln. So wird es beispielsweise unter BeOS gemacht. Einen (hoffentlich vorhandenen ;-)) Treiber für die Graphikkarte aus dem Internet saugen und installieren ? Ganz einfach: Datei holen (ohne passenden Treiber sollte BeOS zumindest im VESA-Mode laufen), ggfs. auspacken (oftmals via ZIP komprimiert) und in das entsprechende Verzeichnis (habe den exakten Pfad nicht im Kopf) ablegen. Nach dem nächsten Reboot funktioniert dann die Karte richtig (hoffentlich ;-)).
Welche meinst du denn? Und welche Vorteile haben sie deiner Meinung nach?
OS/2. Dort funktionieren die meisten Treiber von Version 2.0 (müßte 1991 erschienen sein) noch mit den aktuellsten Ausprägungen (Server for e-Business bzw. eComStation), obwohl sich an der Funktionalität schon einiges getan hat. Beispielsweise wurde der komplette I/O-Layer für Plattenzugriffe überarbeitet, aber das hat ja nun nicht wirklich Auswirkungen auf z.B. den Netzwerkbetrieb, also weshalb sollte man die Netzwerkkartentreiber ändern müssen ?
Wenn du diese "übliche" Schiene schon öfter erlebt hast, dann ist ja vielleicht auch was dran?
Vor allem beobachte ich dieses Schema auf dieser Seite hier immer wieder (ich lese hier ständig), sobald sich jemand erdreistet, Kritik an Linux/"Freier" Software/Open-Source zu äußern. Da wird man dann gerne abqualifiziert mit solch schlagkräftigen "Argumenten" wie "bleib doch bei Windoofs", "machst doch erst mal besser", "du moserst ja nur unproduktiv rum" oder "hast Du schon mal einen Treiber geschrieben ? nein ? dann beschwer Dich auch nicht, daß Dein Rechner unter Linux ständig absemmelt".
Aber hast du dir schon mal überlegt, dass solche kritik so ankommen kann als würdest versuchen Beethoven kompositionsunterricht zu geben indem du sagst: "Hey, mach mal schöne Musik, so wie der Mozart sie macht".
Um schön oder nicht schön geht es hier ja nicht. Aber wenn ein Herr Beethoven - würde er heute noch leben - behaupten, man könne nur mit Celli keine Rockmusik machen, obwohl das Apocalyptica bereits seit einiger Zeit ganz gut hinkriegen (finde ich), dann würde ich mich schon erdreisten, seine Aussage in Zweifel zu ziehen, obwohl ich selber nicht komponieren kann und dementsprechend ja - gemäß der von Dir angebrachten Logik - nicht befugt wäre, mich überhaupt zu dem Thema zu äußern. Herr Beethoven (oder der Linux-Kernel-Hacker) mag ja ein Genie (gewesen) sein, aber deshalb ist er noch lange nicht unfehlbar. Und das ist wiederum völlig unabhängig davon, ob ich komponieren (Treiber(modelle) programmieren) kann. Herr Beethoven (der Kernel-Entwickler) mag eine bestimmte Ansicht zu einer sein Fachgebiet betreffenden Frage/Problemstellung vertreten, aber nur weil er zweifelsohne sehr viel für die Musik (für Linux) geleistet hat, ist seine Ansicht nicht zwangsläufig richtig.
Ansonsten finde ich Kritik prima. Je konstruktiver desto besser;-)
So unkonstruktiv fand/finde ich meine Kritik nicht, ich sage, was man ändern sollte/könnte. Wie genau sie das dann machen, sollen sich besser diejenigen überlegen, die sich wirklich damit auskenne, also die Kernel-Hacker.
Nagut, ich muss ja zugeben, dass im Prinzip die Treiber eher zur Hardware als zum Kernel gehören. Aber ich denke dennoch, dass eine Trennung zwischen Kernel und Treibern im Endeffekt in der Praxis mehr Probleme bereiten als beseitigen würde. Wer verwaltet sie? Wer bestimmt was offiziell unterstützt wird, oder will man sich ohne Qualitätskontrolle auf die Hardwarehersteller/sonstige Programmierer verlassen. Wie wird die Zusammenarbeit zwischen Treiber- und Kernel-Programmereren koordiniert. No schlimmer, wie geht man beim Debuggen von Problemen vor?
Aber wie dem auch sei wir werden hier in unserer Diskussion nicht die (Linux-)Welt verändern. Denn in der Opensource Welt verändert man nur etwas -und das ist ja gerade das schöne an Opensource, das man im gegensatz zum Closed Source den Code verändern kann- indem man Code schreibt. Und da ist der Vergleich mit der Musik ja vielleicht auch ganz treffend. Denn auch dort kann man nur die Musikwerlt verändern indem man Musik schreibt/spielt. Es kann tausende geben die Beethovens 9. Symphonie forden, das ändert gar nichts. Es muss einen geben der sie schreibt. Beethoven hat sie geschrieben und zwar so, wie sie ihm gefiel und wie er es für richtig hielt. Und hinterher hats dem einen oder anderen gefallen. So änlich finde ich, ist das auch bei der Software (sogar bei Closed Source, nur das da die Unternehmensleitung und nicht der Programmierer bestimmt was gemacht wird. Das ist aber auch gar nicht so anders als bei der heutigen Musikindustrie). Und hinterher bestimmen die Zuhörer/Anwender darüber wie gut sie das ganze finden und ob und wie oft sie sich das "Produkt" anhören/anwenden. Und wer die meisten Zuhörer/Anwender hat, der war der tollste. (naja, vielleicht auch nicht immer...)
Also höre dir doch einfach Apocalyptica an und erfreue dich an der schönen Musik und fordere nicht von Beethoven Rockmusik zu machen;-)
Nagut, ich muss ja zugeben, dass im Prinzip die Treiber eher zur Hardware als zum Kernel gehören
Na, da sind wir ja dann doch einer Meinung. ;-)
Wer verwaltet sie? Wer bestimmt was offiziell unterstützt wird, oder will man sich ohne Qualitätskontrolle auf die Hardwarehersteller/sonstige Programmierer verlassen. Wie wird die Zusammenarbeit zwischen Treiber- und Kernel-Programmereren koordiniert. No schlimmer, wie geht man beim Debuggen von Problemen vor?
Ich sehe nicht, daß sich da soviel zum Status Quo ändern wird. Die Treiber, die auch heute schon vom Kernel-Team betreut werden, bleiben ja auch dann erhalten und werden auch dann noch vom Kernel-Team verwaltet (es sei denn, man lagert die Treiber dann in eine eigene Maintenance-Gruppe aus, was ja dann leicht möglich wäre). Aber auch heute schon kann man ja durchaus weitere Treiber in den Kernel einbauen, und diese Treiber können ohne weiteres miserabel sein. Und davon bekommen heute die Kernel-Maintainer auch nix mit.
Also höre dir doch einfach Apocalyptica an und erfreue dich an der schönen Musik und fordere nicht von Beethoven Rockmusik zu machen;-)
Wie ich schon sagte: ich fordere gar nichts. Ich tue nur meine Sicht der Dinge kund. Wenn die jetztige Struktur bei Linux beibehalten wird (und das wird sie sicher, da bin ich mir sicher), dann wird sich die Linux-Entwicklung in Zukunft immer mehr mit sich selbst beschäftigen (immer mehr Treiber sind bei neuen Releases anzupassen), und bei den Distributoren werden immer mehr Leute parallel das Rad neu erfinden, indem sie jeweils Kernels mit gleicher/ähnlicher Funktionalität bauen und warten (wobei sie jeweils auch die gleichen Fehler machen werden, was menschlich ist). Und wenn dann nicht doch irgendjemand sich wirklich dieses Problems annimmt, wird die Weiterentwicklung von Linux mehr und mehr in Richtung Stillstand tendieren (was man heute ja schon erahnen kann), es sei denn, man erspart sich den einen oder anderen Review des geänderten Code und riskiert damit (Sicherheits-)Probleme. Das alles natürlich IMHO.
Apocylyptica höre ich mir aber dennoch an und erfreue mich an der sehr schönen Musik.
> Es gibt Betriebssysteme, die bereits seit langem eine definierte stabile (!) Schnittstelle zur Treiberprogrammierung besitzen. Das Problem liegt zum großen Teil am gcc. Unterschiedliche Compiler erzeugen unterschiedliche Kernel-ABIs. Diverse Compilerflags (REGPARM) verändern das API. Solange das der Fall ist, ist er völlig vergeudete Zeit, die interne Kernel-API stabil zu halten, zumal die Kernelentwickler so falsche Ansätze korrigieren könnten, während sie sonst mehrere Interfaces über zig Versionen pflegen oder auf lange Zeit mit dem falschen Ansatz weiterarbeiten müssten. Nicht umsonst will z.B. Trolltech mit Qt4 das Qt-API ausmisten, da Qt3 aufgrund teilweise redundanter Interfaces viel zu aufgeblasen ist.
>> Es gibt Betriebssysteme, die bereits seit langem eine definierte stabile (!) Schnittstelle zur Treiberprogrammierung besitzen. > Das Problem liegt zum großen Teil am gcc. Unterschiedliche Compiler erzeugen unterschiedliche Kernel-ABIs. Diverse Compilerflags (REGPARM) verändern das API. > Solange das der Fall ist, ist er völlig vergeudete Zeit, die interne Kernel-API stabil zu halten, zumal die Kernelentwickler so falsche Ansätze korrigieren könnten, während sie sonst mehrere Interfaces über zig Versionen pflegen oder auf lange Zeit mit dem falschen Ansatz weiterarbeiten müssten.
Deine Begründung wird von diesem Artikel unterstrichen, der von dem Kernelentwickler Greg Kroah-Hartman stammt:
Von insmod rmmod modprobe am Di, 10. Mai 2005 um 16:13 #
>Aber darüberhinaus wäre es für Drittanbieter - neben dem Kernel-Maintainer und dem Distributor - deutlich einfacher, einen neuen Treiber in ein laufendes Linux-System zu integrieren
Wie ? Was meinst du da ? Man kann beim laufendem kernel keine Treiber hinzufügen ? Verstehe ich nicht.
Mit "laufendem System" meinte ich eher ein sich bereits im Einsatz befindliches System, in das ich z.B. einen neuen USB-Controller einbaue, für den ich dann den Treiber nachinstallieren muß.
So einfach ist das nicht. Ein Beispiel aus der Praxis: Bei uns läuft seit einiger Zeit eine Datenbank unter Linux (ca. 500GB groß) jetzt ist das Ding zu klein geworden und es sollen externe Platten dazu kommen. (Aufstockung auf ca. 1000GB) Dazu ist ein neuer Controller notwendig. Dieser aber benötigt einen neuen Treiber. Das Problem ist nun, dass ich den Treiber nur dann installieren kann wenn ich den kompletten Kernel neu übersetze, denn mit dem alten Kernel arbeitet der Treiber wieder nicht zusammen. Den Kernel kann ich aber nicht akualisieren, da mir sonst der Datenbankhersteller keine Unterstützung mehr gibt. Das Ergebnis sind nur Probleme. Mit einer stabilen Treiberschnittstelle wäre das Problem zu umgehen gewesen.
Aufholen vielleicht. Überholen? Da mus schon noch ne Menge passieren. Und MS muss die Entwicklung einstellen. Dann werden Deine Träume wahr.
> der im Grunde ja der einzige technische Vorteil von Windows ist
Ja, das ist die Überzeugung der Linuxfanatiker. MS ist nur bei Multimedia besser (wenn überhaupt). Sonst ist Linux haushoch überlegen. Komisch nur, dass sich Linux im Desktopmarkt immer noch nicht durchgesetzt hat. Nicht nur nicht durchgesetzt, der Marktanteil stagniert bei unter 5%. Seit Jahren.
Aber solange die Linuxer nicht sehen, das Windows noch ein paar Vorteile mehr zu bieten, solange wird sich auch nicht wirklich etwas ändern.
> Die Treiberentwicklung den Hardwareherstellern zu überlassen, die weniger vom > Kernel verstehen, als die Kernelprogrammierer, würde deshalb wohl zu erheblichen > Instabilitäten führen.
Wie machen das die HW-Hersteller dann mit den Treibern für Windows? Ist der Windowskernel (oder besser gesagt die Schnittstelle zu diesem) einfacher zu verstehen als der Linuxkernel?
> Ich bin sicher sie werden sich über deine Beiträge freuen. Wenn du es > nicht kannst, dann solltest du vielleicht nich über Dinge reden, von denen > du nichts verstehst.
Hast Du schon mal Software in größerem Maßstab entwickelt? Anscheinend nicht. Glaubnst Du ernsthaft, jemand will von einem Außenstehenden ein Konzept aufgedrückt bekommen? Die Kernelentwickler werfen doch nicht ihre eigenen Konzepte so mir nichts dir nichts über den Haufen und stricken den Kernel um. Aber ich sehe, Du verstehst etwas von den Dingen, über die Du schreibst.
Windows bietet eine definierte Schnittstelle für Treiber. Das ermöglicht es Firmen, zu vergleichsweise geringen Kosten Treiber für Win zu entwickeln. Und die funktionieren dann sogar. Linux bietet das nicht. Zusammen mit der geringen Verbreitung ergibt das ein extrem schlechtes Kosten-Nutzen-Verhältnis. Den rest kriegst Du vielleicht noch selber zusammen.
Du hast was wichtiges übersehen: der kernel wird von _freiwilligen_ entwickelt. die können machen, wozu sie lust haben.
ich kann mich entscheiden, heute nach feierabend meinen rasen zu mähen oder ein wenig am kernel mitzuhelfen, aber niemand kann mich zwingen (obwohl es die nachbarn bei der sache mit dem rasenmähen ständig versuchen ), und niemand kann mir vorschriften machen, _was_ ich zu programmieren habe.
wenn für dich persönlich ein bestimmtes feature wichtig ist: entwickle es (oder zahle jamenden dafür, dass er's tut), aber komm nicht zum jammern.
wenn dir die richtung bei linux nicht passt: wechsle zu *BSD oder Mac oder was. keiner zwingt dich.
natürlich muss produktive kritik erlaubt sein, aber sowas wie
> Vielleicht sollten sich die Herrn Kernel-Gurus langsam mal Gedanken machen, > wie sie den Linux-Kernel aufbaumäßig endlich ins aktuelle Jahrtausend migrieren
übersetze ich zu "ich will alles, und zwar gleich, und zwar umsonst!"
Hmmm, Du hast da aber ziemlich viel (Unsinn) in meinen Beitrag reininterpretiert. Also, ich jammere hier weder (worüber sollte ich denn jammern ?), noch möchte ich von irgendwem irgendwas haben (also gut, ich möchte eigentlich eine Menge, aber das hat alles nix mit Linux zu tun ;-)). Ich habe lediglich meine Meinung zum besten gegeben. Wenn Linux Fortschritte macht, finde ich das gut und freut mich für die Entwickler, die es voranbringen. Wenn in einem halben Jahr bekanntgegeben wird, daß Linux nicht mehr weiterentwickelt wird (rein illusorisch, kann/wird natürlich nicht passieren), ist mir das auch Wurst. Für mich ist Linux nur ein Unterbau für die Anwendung(en), die mich interessiert/en. Und wenn Oracle morgen sein RDBMS für *BSD rausbringt, ist Linux bei mir ruck-zuck von der Platte runter (auch wenn diese Meinung hier nicht wirklich populär ist, ich hatte bisher einfach weniger Aufwand/Probleme mit (Free)BSD als mit (SuSE)Linux). Für mich ist Linux nur ein Hilfsmittel und kein Selbstzweck oder Selbstverwirklichungstripp (womit ich hier wohl in der krassen Minderheit sein dürfte).
noch möchte ich von irgendwem irgendwas haben (also gut, ich möchte eigentlich eine Menge, aber das hat alles nix mit Linux zu tun;-))
Was machst du dann hier auf pro-linux?
Wenn in einem halben Jahr bekanntgegeben wird, daß Linux nicht mehr weiterentwickelt wird (rein illusorisch, kann/wird natürlich nicht passieren), ist mir das auch Wurst. [...] Und wenn Oracle morgen sein RDBMS für *BSD rausbringt, ist Linux bei mir ruck-zuck von der Platte runter
Und wenn es bis dahin Oracle immer noch nicht offiziell (inoffiziell funktioniert es schon) für BSD gibt?
Warum benutzt du nicht einfach Windows? Oder macht das mehr Aufwand/Probleme als Linux?
Weil ich mich generell schon für Linux interessiere, es hier immer so interessante und sachliche Diskussionen gibt (Vorsicht: Ironie ;-)) und weil ich nirgendwo ein Schild gesehen habe: "wer Linux nicht perfekt findet oder gar etwas an Linux verbesserungswürdig findet, hat hier nichts zu suchen".
Und wenn es bis dahin Oracle immer noch nicht offiziell (inoffiziell funktioniert es schon) für BSD gibt? Warum benutzt du nicht einfach Windows? Oder macht das mehr Aufwand/Probleme als Linux?
Wenn Linux tatsächlich "verschwinden" würde und es noch kein Oracle für *BSD geben sollte, würde ich tatsächlich Windows verwendet. Da ich aber berufsmäßig täglich mit Oracle auf UNIX arbeite und ich zudem kein Windows-Fan bin (zu unflexibel), ziehe ich natürlich ein UNIX-(artiges-)System vor. Ok, und Oracle auf Windows hat so seine Tücken, auf die ich eigentlich keine Lust habe. ;-)
Ürbigens, ich habe schon darüber nachgedacht, Oracle über die Linux-Schnittstelle von FreeBSD zu betreiben, bislang konnte ich mir nur noch nicht dazu durchringen, das ganze zum Laufen zu bekommen, denn meiner Erfahrung nach funktioniert in der Kombination Oracle und *BSD/Linux von Hause aus nichts so, wie es soll. Das ist natürlich nur meine ganz subjektive Meinung :-/
Weil ich mich generell schon für Linux interessiere, es hier immer so interessante und sachliche Diskussionen gibt (Vorsicht: Ironie;-))
Da frage ich mich jetzt aber, ob ich deine Erwartungen wegen der "sachlichen Diskussionen" erfüllt habe. Du scheinst mich ja für eine art Linux-Jünger zu halten.
Ich hoffe so schlimm ist es noch nicht mit mir. Habe mich nur jahrelang mit Windows rumgeärgert bis ich irgendwann ein Linux aufgespielt habe und bei vielen Dingen dachte. Ja genauso habe ich mir das bei einem Computer vorgestellt. Anfangs dauert vieles länger, aber man lernt viel und hinterher funktiert es (meist) reibungslos. Und man lernt sogar eine Menge, was man und Windows wieder einsetzen kann. Aber da sind wir ja wohl gar nicht so weit auseinander:
ich zudem kein Windows-Fan bin (zu unflexibel), ziehe ich natürlich ein UNIX-(artiges-)System vor
Aber ansonsten bin ich eigentlich gar nicht so ein fürchterlicher Überzeugungstäter, insbesondere wenn es einfach nur darum geht eine bestimmte Aufgabe zu erledigen.
*BSD wahrscheinlich das stabilere System.
Ürbigens, ich habe schon darüber nachgedacht, Oracle über die Linux-Schnittstelle von FreeBSD zu betreiben, bislang konnte ich mir nur noch nicht dazu durchringen, das ganze zum Laufen zu bekommen,...
Kenst du diesen link? http://www.scc.nl/~marcel/howto-oracle.html
Eigentlich sind wir langsam an einem Punkt angekommen an dem wir zum weiterdikutieren ein Glas Bier vor uns stehen haben sollten.
Da frage ich mich jetzt aber, ob ich deine Erwartungen wegen der "sachlichen Diskussionen" erfüllt habe. Du scheinst mich ja für eine art Linux-Jünger zu halten
Na, sagen wir mal, bei Deinem ersten Posting dachte ich, daß Du meinen Beitrag wirklich nur als blödes Rumgemecker verstanden hast, aber diese Meinung durfte ich dann bei Deiner nächsten Anwort zum Glück ins Positive korrigieren. Von daher denke ich, wir haben die Kurve bzgl. sachlicher Diskussion durchaus gut gekriegt.
Habe mich nur jahrelang mit Windows rumgeärgert bis ich irgendwann ein Linux aufgespielt habe und bei vielen Dingen dachte. Ja genauso habe ich mir das bei einem Computer vorgestellt.
Naja, der erste Teil war/ist bei mir genauso, ich ärger(t)e mich auch immer, daß es unter Windows einfach nicht möglich war/ist, zehn Handgriffe zu machen, ohne daß man auf etwas stößt, das nicht so funktioniert, wie man es eigentlich hätte erwarten dürfen. Leider waren meine Linux-Erfahrungen aber auch nicht nur von Erfolg gekrönt. Einer meiner ersten Kontakte mit Linux bestand darin, daß ich gerne zuhause irgendeine ältere SuSE-Distri (ich glaube, das war 4.irgendwas) installieren wollte, das aber nur mit Kernel 2.2 funktionierte (wegen dem SCSI-Adapter), unter dem aber wiederum meine Netzwerkkarte nicht lief, für die gab es nämlich nur einen 2.0er-Treiber. Vielleicht bin ich auch deshalb etwas geprägt, was die Treiberproblematik angeht. Dazu kam dann noch, daß mich die Stabilität und das Multitasking von Linux nicht wirklich vom Hocker riss, da ich damals privat OS/2 verwendete, was in beidem Linux zu dieser Zeit überlegen war.
Kenst du diesen link? http://www.scc.nl/~marcel/howto-oracle.html
Ne, kannte ich noch nicht, vielen Dank !!! Wie gesagt, ich habe mich bisher noch nicht so richtig um einen Ersatz für SuSE Linux bemüht, aber nachdem ich jetzt endlich Oracle installiert habe, werde ich mir das in einer ruhigen Minuten mal mit FreeBSD anschauen. Wäre mir sehr recht, wenn das klappen würde, denn SuSE ist mir einfach etwas aufgebläht dafür, das es einfach nur meine Oracle-DB betreiben soll. ;-)
Eigentlich sind wir langsam an einem Punkt angekommen an dem wir zum weiterdikutieren ein Glas Bier vor uns stehen haben sollten.
Yep, sehe ich auch so. Also, ein virtuelles Prost und einen schönen Nachmittag/Abend noch !
...Ja was den nu? Erst beschwerst du dich, das es unverantwotlich ist, den Kernel selber zusamen zu bauen, weil die wechselwirkung nicht vorhersagbar ist, und dann vorderst du das die Hartware-Hersteller sich um die Treiber kümmern sollen. Das ist doch genau das Problem von M$! Die Treiber von dritanbietern haben (z.T.) eine so lausige Quallität, das sie das ganze System kopromitieren.
Wenn ein Hardware-Hersteller für seine schlechten Treiber bekannt ist, dann meide ich ihn. Deswegen verwende ich ja auch eine Nvidia-Grafikkarte unter Linux, und keine von ATI!
Und die Diskussion ist schon ein paar mal auf der Kernel-Mailingliste geführt worden, mit dem Ergebnis dass eine feste Schnittstelle die Entwicklungsarbeit zu stark behindern würde. Hin und wieder ist es offensichtlich besser man zieht alle Treiber in eine neue Schnittstellendefinition hinüber, als man bleibt bei einer festgelegten Schnittstelle und verrenkt dabei alle möglichen Kernel-Bausteine. Ich nehme an, dass das mit ein Grund für die langsame Weiterentwicklung von Windows war (und ist). Da funktioniert ein und der selbe Treiber über mehrere Betriebssystemversionen hinweg, was man aber mit einer festgehaltenen Schnittstelle zu bezahlen hat. Nachdem bei den NT-Kerneln kaum noch was von der ursprünglichen Microkernel Architektur übriggeblieben ist, ist das Festhalten an einer Schnittstelle durchaus behindernd wenn man den Kernel weiterentwickeln möchte. Linux hat eben bei der Entwicklung den Vorteil, dass auf binäre Treiber keine Rücksicht genommen werden muß.
> Würde man sich bei Linux wirklich nur auf die Funktionalität beschränken, > wenn dürften die Kernel-Maintainer mit einem Schlag viel weniger Arbeit > haben (da sie ja nicht mehr jeden dämlichen Treiber in den Kernel-Code > flicken müssen) und könnten sich stattdessen voll auf die eigentlichen > Aufgaben eines Kernel konzentrieren. Hardware-Hersteller könnten - wie bei anderen > Betriebssystemen auch - einfach Treiber mit ihrer Hardware ausliefern und via simplem > Skript (z.B. durch Kopieren in ein festgelegtes Verzeichnis) auf dem Zielsystem > installieren
Der Gedanke greift leider etwas kurz, denn man ersetzt dadurch die Notwendigkeit, Treiber einmal in einen Kernel zu implementieren durch die Erfordernis, jeden Treiber in jede große Distribution zu integrieren. Wenn schon die Kernel-Maintainer damit überfordert sind, werden es die Distributoren dann erst Recht sein. Und die Hardware-Hersteller werden sich bedanken, für jede Distri wieder ein passendes Paket herausgeben zu dürfen.
Außerdem öffnet man Tür und Tor für Vendor Lock-Ins der Hersteller, die dann nur noch Binary-Treiber für eine Kernel-Version und eine Architektur rausgeben, die dann mit der nächsten wieder aus irgendeinem esotherischen Grund nicht mehr laufen. Schon jetzt gibt es solche Probleme z.B. mit nVidia-Grafikkarten auf PowerPC-Rechnern. Die Welt besteht eben nicht nur aus x86-Desktops.
"Vielleicht sollten sich die Herrn Kernel-Gurus langsam mal Gedanken machen, wie sie den Linux-Kernel aufbaumäßig endlich ins aktuelle Jahrtausend migrieren. Hardware-Treiber haben nun mal nix im Kernel zu suchen... endlich auch eine definierte stabile (!) Schnittstelle zwischen Treiber- und eigentlichem Kernel-Code"
Richtig. Nur wird nichts geschehen weil Linux selbst das Problem ist. Man hätte sich vor vielen Jahren nicht für einen Monoliten, sondern einem Microkernel und einem Hardware Abstraction Layer entscheiden sollen. So wie wir es von Windows und OSX her kennen, und es Richard Stallman auch immer wollte, mit Hurd allerdings Schiffbruch erlitt. Jetzt ist da nichts mehr zu machen. Der Kernel wird immer fetter und fehlerträchtiger werden. Wer zu spät kommt, den bestraft die Geschichte.
Gibt es nicht extra Distributionen für Servereinsatz und andere für Desktopeinsatz? Was ist denn sonst der Unterschied von normalen Distries und z.B. Enterprise-Editionen? Diese sind doch auf Server optimiert, ohne Multimedia-krams, oder? Ich hab noch nie eine Enterprise- oder Sonstwie-Edition ausprobiert, das ist nur eine Annahme von der ich bisher ausgegangen bin...
Morton beweist mit seiner ignoranten Haltung vollkommene Unkenntnis von Software-Evolution und ihrem Ende. Ich teile auch die Befürchtung von Greenblatt, dass der Kernel immer unwartbarer wird und in der Linux-Entwicklergemeinde jedes Crap-Feature akzeptiert wird. Wenn die Linux-Entwicklung so weitergeht, muss der Kenerl in einigen Jahren komplett neu geschrieben werden, da dann nichts mehr zu retten sein wird oder die Weiterentwicklung des Kernels wird ins Stocken geraten und man wird im Bugfixing untergehen.
Deutlich ist zumindest dass der Entwicklungszyklus des Kernels zusehends langsamer und nicht schneller wird. Da helfen auch die minor-Revisions nicht drüber hinwegzutäuschen. Die Linuxgemeinde muss erst die Lehren der Software Crisis erneut erfahren, bevor sie zur Besinnung auf die Unix Tradition kommen.
Wenn die Prophezeihung des Kernelendes in 4 Jahren eintritt, wird Linux etwa 10 Jahre Entwicklungsarbeit verloren haben, die Longhorn zugute kommen werden. Deshalb hätte man schon vor 2.6 über eine Neuimplementierung mit Ziel 3.0 nachdenken sollen.
ich sehe das nicht ganz so negativ. Der Kernel besteht aus Modulen mir sehr gut definierten Schnittstellen. Das Problem ist, dass die Hareware immer unübersichtlicher und schrottiger wird. Die neue HAL hilft hier aber etwas weiter.
Das ist meiner Meinung nach das Problem. Der Kernel mag vielleicht aus Modulen bestehen, doch sind die Schnittstellen weder gut dokumentiert noch definiert. Sie ändern sich ständig, was massive Anpassungen an vielen Treibern erfordert und Man-Power frisst. Die Modularität des Kernels ist also nur halbherzig durchgeführt worden.
Man mag gegen MS sagen wollen, was man will, aber ihre NDIS-Schnittstelle ist erste Sahne. So etwas fehlt es Linux und so lange es Torvalds und Co nicht gemerkt haben, wird weiter sinnlos Power verbraucht.
Kritik ist nicht wirklich nützlich, wenn sie keine brauchbaren Alternativen zu bieten vermag. Das ist hier leider das Problem. Deine Argumentation hinsichtlich Longhorn oder auch Tiger ist sicherlich richtig, nur: Nach dem Server-Bereich wird jetzt ganz gern auch mal von "Linux auf dem (Corporate) Desktop" geredet - wie genau soll das denn aussehen? GNU/Linux als Desktop-OS oder (extremer) als vorinstallierte OS-Plattform auf PCs für den Heimgebrauch erfordert Unterstützung für eine enorm breite Palette an (billiger) Hardware, die sich an keinerlei Standards hält, die lediglich mit herstellerspezifischen Treibern (für Windows) in Gang zu bringen ist, die aber nunmal von den Leuten genutzt wird. Du wirst es einem Home-User, der mit seinem neuen Computer lediglich ein paar genau umrissene Dinge machen will, nicht vermittelt kriegen, daß er, parallel zu dem neuen System (welches ihn eigentlich gar nicht interessiert...) noch Geld in Hardware stecken muß, die signifikant teurer ist als jene im Regal von $DISCOUNTER_SEINER_WAHL, aber letztlich für ihn auch nur "dasselbe" macht, nur weil Linux eben nicht mit "jeder" Hardware kann?
Die Tatsache, daß freie Entwickler freie Treiber für genau jenes Zeugs schreiben, ist nicht nur von Vorteil, sondern essentielle Voraussetzung für die Verbreitung von GNU/Linux außerhalb des Server-Bereichs. Nur müssen die Treiber irgendwohin...
Aber das ist doch genau das Problem ! Linux auf dem Server hat sich einigermaßen etabliert (zumindest für bestimmte Arten von Server: Web, Datei, kleine Datenbanken), aber auf dem Desktop hinkt es doch noch merklich hinterher, was die Unterstützung der Hardware oder typische Endanwender-Features angeht, was beides für Server uninteressant ist. Da es aber gerade angesagt ist, die Verbreitung von Linux auf dem Desktop zu erhöhen, wird am Kernel vieles für den Desktop gebastelt. Und dieser ganze Schlunz ist dann erst mal Kernel drin - auch auf dem Server, es sei denn, ein Distributor oder (schlimmer) der Sys-Admin baut einen eigenen, angepaßten Kernel. Besser wäre es doch, wenn gar nicht erst so viel im Kernel drinne wäre, das man dann je nach Anwendungsfall wieder rauswirft. Genau so verstehe ich die Kritik am Kernel.
Definiere mal bitte "bestimmte Arten von Server" genauer... Was sind z.B. für dich "kleine Datenbanken"?
Ein Oracle-Cluster mit mehrere Gigabyte-Datenbanken würde ich nämlich nicht unbedingt als "kleine Datenbanken" bezeichnen, und trotzdem funktioniert es super. Klar, mySQL mit ner 2 MB-Datenbank funktioniert auch.
Was ist für dich Hardware, die vom Server nicht unbedingt unterstützt werden muß? Das hängt sicher auch vom Server ab. Klar, nicht jeder Server braucht z.B. Firewire. Bei manchen allerdings wird darüber ein Drucker angeschlossen. Nicht jeder Server braucht unbedingt Multimedia-Features. Bei Webservern, die auch noch Streaming unterstützen und die Streams rendern, macht sowas alllerdings Sinn.
Dass alles im Kernel ist, mag sicher Vor- und Nachteile haben (siehe die allseits bekannte Diskussion Microkernel gegen monolithische Kernel). Mir ist es aber lieber, alles im Kernel drin zu haben und ungewünschte Sachen zu entfernen, als für jedes blöde Gerät erstmal im Internet zu suchen, ob es Treiber dafür vom Hersteller gibt... ob es Treiber dafür von freien Programmierern gibt... ob vielleicht irgendeine andere Hardware auf dem gleichen Chipset basiert, und ich die verwenden kann... danke, aber das Gefrickel hab ich schon unter Windows genug. Und wenn man einen Kernel selbst zusammen stellt (was sowieso kein DAU machen wird / machen sollte), und man dann einen Parameter vergißt, und die Oracle-Datenbank oder iptables oder sowas nicht mehr geht... da muß man sich dann halt selbst an die Nase fassen, denn gerade sowas ist gut dokumentiert. ( und wie gesagt: Kernel neukompilieren sollte sowieso kein völliger Laie machen )
Definiere mal bitte "bestimmte Arten von Server" genauer...
Hatte ich doch schon: Webserver, Fileserver, kleinere DB-Server
Was sind z.B. für dich "kleine Datenbanken"?
Hmm, sagen wir mal bis max. 500 Concurrent Users und 100 GB Größe, generell aber nichts mit hoher I/O-Last.
Ein Oracle-Cluster mit mehrere Gigabyte-Datenbanken würde ich nämlich nicht unbedingt als "kleine Datenbanken" bezeichnen, und trotzdem funktioniert es super.
Klar kann sowas funktionieren, aber a) ist mir die Kombination Oracle+Linux - zumindest im Moment - noch nicht so ganz geheuer, da man schon sehr genau darauf achten muß, welche Oracle-Version man auf welcher Distribution mit welcher GCC und welcher glibc-Version installiert, und b) denke ich, daß unserer Billing-System im Terabyte-Bereich mit mehr als 2000 Concurrent Users auf einem HP-UX-Cluster oder AIX-Cluster einfach besser aufgehoben ist. ;-)
Was ist für dich Hardware, die vom Server nicht unbedingt unterstützt werden muß? Das hängt sicher auch vom Server ab.
Eben, Du sagst es. Um so schöner wäre es doch, wenn man leicht Treiber entfernen oder hinzufügen könnte, ohne gleich den Kernel anfassen zu müssen, oder nicht !?
siehe die allseits bekannte Diskussion Microkernel gegen monolithische Kerne
Das Micro-Kernel-Konzept geht aber weit darüber hinaus, Gerätetreiber außerhalb des Kernel abzulegen (wo sie IMHO ohnehin nicht hingehören).
Mir ist es aber lieber, alles im Kernel drin zu haben und ungewünschte Sachen zu entfernen, als für jedes blöde Gerät erstmal im Internet zu suchen, ob es Treiber dafür vom Hersteller gibt
Das eine hat doch nichts mit dem anderen zu tun. Die Treiber können nach wie vor mit Kernel runtergeladen/installiert werden, nur eben nicht mehr als Teil des Kernel, sondern als eigene Dateien. Solange Du nicht einen Treiber hinzufügen oder löschen willst, wirst Du keinen Unterschied bemerken.
Und wenn man einen Kernel selbst zusammen stellt (was sowieso kein DAU machen wird / machen sollte), und man dann einen Parameter vergißt ...
... oder wie wär's mit dem Klassiker, das File-System der Boot-Partition als Modul zu laden. Genau aus diesem Grund finde ich das derzeitige Konzept nicht so prickelnd. Der Kernel sollte für mich etwas sein, das ich als Anwender und auch als Admin eigentlich nie anpacken muß.
Wie fast jede Software wird der Kernel inkrementell entwickelt, und das ist gut so. Patching und Refactoring ist einfacher, schneller und besser nachvollziehbar als Rewriting, behebt Bugs und Designfehler ohne dafür noch mehr neue einzuführen oder Features und Charakteristika zu verlieren (die sich im Lauf der Zeit an den Bedarf der User und Anwendungen angepaßt haben, und an die sich die User und Anwendungen angepaßt haben). Zwischen 2.4 und 2.6 gab es einige große, lang dauernde Refactorings, aber ein System auf 2.6 umzustellen ist erstaunlich problemlos.
Auch ein Grund die Grundausstattung an Treibern im Kernel-Source zu belassen: sie werden bei Refactoring und Weiterentwicklung mit erfaßt. Manchmal lese ich auf der LKML Sätze wie "Funktion x wird in 129 Stellen verwendet... unser Patch y ändert das wie folgt... das Ergebnis ist 470% schneller und hat Problem z nicht mehr..."
Mit anderen Worten: die Treiber-Grundausstattung ist auch deshalb Teil des Kernels weil sich dessen Entwicklung so am Bedarf der Treiber orientieren kann, und die Treiber bei der Gelegenheit gleich mit angepaßt werden. So ähnlich wie ein Hersteller Soft- und Hardware optimal einander anpassen kann wenn er die Kontrolle über beides hat. So etwas wie eine schlechte oder veraltete Treiberschnittstelle entsteht gar nicht erst.
Das kartesische Produkt aus Bussen, Chips, Boards, Customizings etc führt zur Treiberexplosion? Gut, separieren wir Treiberschichten wie in NetBSD. Oh, die 100.000 binären Treiber die gegen die coole Treiber-Schnittstelle entwickelt wurden, deren Source nur die Hersteller haben und die sie niemals anpassen werden weil sie neue Produkte verkaufen wollen sind dabei im Weg ? Wenn die Sourcen nur Teil des Kernels wären...
Linux ist produktionsfähig weil es gut verstanden, bewährt und in den Grundzügen stabil ist, und sich jeden Tag besser an den Bedarf der User anpaßt. Und es ist vielerorts die "Weapon of Choice" weil es offen ist und so viel Auswahl bietet. Wer ein superinnovatives, experimentelles "Research OS" will das jedes Semester mit dem Paradigma de Jour neu geschrieben wird kann sich gern woanders bedienen.
Und da sind wir beim Thema "Freedom of Choice".
Anders als die meiste Software wird der Kernel praktisch von der ganzen Welt "gefüttert"; für jede Anwendung, sei es noch so speziell, kann sich unter vielen Lösungen eine "beste" herausbilden, und wo es keine "beste" gibt bleiben mehrere zur Auswahl.
Klar, jeder wünscht sich ein schlankes System, weil er denkt das ist dann performanter, übersichtlicher, wartbarer und stabiler. Aber es soll bitteschön alle Features und Treiber beinhalten die *er* braucht. Wehe das schlanke "MiniBSX" hat - nur ein Dateisystem ("das Journalling ist so langsam.. aber ohne Journalling ist scheiße.. und ordered-writes sind für meine Anwendung langsam.. und es gibt kein Realtime -IO für Streaming.. aber das Realtime-IO ist so aufgebläht.. ohne Tail-Packing kann man keinen News-Server.. mit Tail-Packing wird mein System so langsam.. und für LVM brauch ich doch Online-Resize.. und für mich ist es zu CPU-lastig.. ohne Crypto und Kompression bin ich aufgeschmissen..") oder - nur einen Prozeß-Scheduler ("ich hab 1.000.000 Prozesse, warum gibts kein O(1).. aber ich will eine Batch-Prio.. aber für meine Multi-Prozeß-DB ist der Scheduler langsam.. aber bei mir verhungern die niedrig priorisierten Prozesse..") und - bestimmte Features nicht ("ohne inotify läuft mein Beagle nicht.. aber ohne QoS-Routing geht mein Server nicht richtig.. ich brauch aber RAID6 und AES192 einkompiliert für die Boot-Partition...")
Wißt Ihr was? Mit "make menuconfig" kann sich jeder seinen Kernel so schlank oder mächtig bauen wie er will, ohne Performance-Einbußen oder andere Kompromisse. Wer binäre Treiber nutzen will kann das tun. Wer die nicht will oder nicht kriegt ist froh daß die Grundausstattung so viel Auswahl bietet. Wer Treiber ohne Reboot einfügen oder austauschen will kann das tun, selbst wenn er sie erst kompilieren muß. Wer keine Module will weil er Angst vor Kernel-Rootkits hat kann Module abschalten. Wer will daß Kernel und Treiber über Registeraufrufe statt Stack kommunizieren kann das haben. Wer 400.000 Threads starten will ist froh daß man alles für 4k-Stacks kompilieren kann. Wer neue Treiber und/oder Features entwickelt ist froh daß sich der Kernel so gut zum Patchen eignet. Wer für seine Security-Policy ins VFS eingreifen muß ist froh daß er das kann.
All die vielen Patches, Architekturen, Virtualisierung und sonstigen Experimente führen zu Schnittstellen deren Flexibilität weit über das hinausgeht was sich ein einzelner Entwickler, Architekt oder Hersteller hätte ausdenken können.
Es gibt so viele verschiedene ideale Kernel wie es User gibt. Der Linux-Kernel kommt jedem davon so nahe wie sonst nichts. Deshalb hat Morton recht. Wer es besser weiß kann jederzeit auf der LKML posten.
Grüße von einem der froh ist daß Linux alles sein kann was er braucht, Jogbaer
> Mit anderen Worten: die Treiber-Grundausstattung ist auch deshalb Teil > des Kernels weil sich dessen Entwicklung so am Bedarf der Treiber orientieren > kann, und die Treiber bei der Gelegenheit gleich mit angepaßt werden. ... > So etwas wie eine schlechte oder veraltete Treiberschnittstelle entsteht gar > nicht erst.
Du bist bestimmt Entwickler großer Softwaresysteme.
Gäbe es eine gute Schnittstelle zwischen Kernel und Treibern, wären ständige Anpassungen gar nicht nötig. Das es doch nötig ist, beweist das Gegenteil. Und auch wenn ein Patch mal schnell xxx Stellen auf einen Rutsch ändert, ist damit dennoch immer ein erhöhter Aufwand verbunden. Das ist verlorenen Zeit, macht Entwicklern und Hardwareherstellern das Leben schwer und kostet schlicht Geld. Andere Systeme machen das besser.
> Und da sind wir beim Thema "Freedom of Choice".
Weißt Du, warum die römische Armee so erfolgreich war?
> All die vielen Patches, Architekturen, Virtualisierung und > sonstigen Experimente führen zu Schnittstellen deren Flexibilität weit > über das hinausgeht was sich ein einzelner Entwickler, Architekt oder > Hersteller hätte ausdenken können.
Du hast von Schnittstellen keinen blassen Schimmer. Kein Mensch will eine Hypermegasuperflexi-Schnittstelle, sondern eine stabile, einfach zu benutzende Schnittstelle. Was Du meinst, ist keine Schnittstelle, sondern ein chaotischer Haufen von vielen Schnittstellen. Am besten, Du rüstest Deine deine heimischen Steckdosen auf ein Dutzend verschiedene Typen um.
> Der Linux-Kernel kommt jedem davon so nahe wie sonst nichts.
>Und dieser ganze Schlunz ist dann erst mal Kernel drin - auch auf dem Server, es sei denn, ein Distributor oder (schlimmer) der Sys-Admin baut einen eigenen, angepaßten Kernel.
Also man sollte doch meinen, dass Distributoren Kernels bauen können - ansonsten kann man Linux gleich ins Eck treten. Da das nicht der Fall ist, behaupte ich mal, dass Distributoren Kernel bauen können! Und wird dieser modular gehalten, dann hast Du doch den ganzen "Treiberschlonz" evtl. dabei aber das Gedönse ist nicht aktiv, weil nicht geladen - ergo stabil. Sehen wir es doch einfach so: Linux ist eine neue Art. Das Tier Linux hat sich von dem urspr. Unix "abgespalten" (stimmt so nicht - ich weiß - aber sehen wir es mal biolog. so) und die Evolution wird zeigen, ob Linux überlebensfähig ist oder nicht. Ich denke der Basar wirds schaffen, wird sich aber in einer ganz anderen Ecke wieder finden, als das viele gedacht haben.
Du scherst grade ziemlich viel über einen Kamm. Warum soll/muss der Kernel in einige Jahren neu geschrieben werden? Taugen die internen Schnittstellen zu den einzelnen Subsystemen nichts? Kannst du das mal bitte etwas genauer ausführen? Ansonsten muss ich dein Statement leider unter leerem Gerede abtun.
Das Hauptproblem im Linux-Kernel ist die Architektur im Allgemeinen und nach wie vor das Speichermanagement im Speziellen, jede Komponente muss das nämlich selbst in die Hand nehmen (was die Bugquelle Nr. 1 derzeit ist). Hinzu kommt eine fehlende generische Hardware-Abstraktionsschicht, die es erlauben würde, einen gut gewarteten Kernel, der Resourcenmanagement und Scheduling betreibt abseits von diversen Speicherverletzungen aus der Geräte-Treiberecke zu halten. Darüber hinaus wäre auch ein klares internes Design wünschenswert, welches Subsystem darf was? Wie läuft ein sauberer Kontrollfluss ab, etc.pp. Das chaotische Design hat einige Vorteile, die aus Software Engineering Gesichtspunkten der reinste Alptraum sind, und das ist hohe Kopplung - diese führt im positiven Sinne zu sehr hoher Performance, aber zugleich zur Unwartbarkeit. Wäre der Linux-Kernel ein kommerzielles Produkt, wäre das Projekt längst gescheitert, da die Entwicklungskosten, die im Kernel stecken, extrem hoch liegen dürften durch die mangelhafte Architektur. Es geht hier nicht um Mikro vs Monolith, letzterer hat seine Vorzüge, ABER die Architektur muss dazu sauber designed sein. Und gerade beim Speichermanagement leidet man noch heute überall an Fehlern, die vor über 10 Jahren gemacht wurden...
Ob Du es glaubst oder nicht, der derzeitige Code-Moloch des Linux-Kernels wird mittelfristig neu geschrieben werden müssen... Es kann natürlich auch sein, dass aus der kommenden Linux-Krise mehrere Kernel entstehen, die sich dann verschiedene Prämissen setzen (würde generell vermutlich einiges mehr retten und das Scheitern des Gesamtprojektes hinauszögern) - Du kannst das mit der BSD-Aufsplittung vergleichen (die bis heute andauert).
"Ob Du es glaubst oder nicht, der derzeitige Code-Moloch des Linux-Kernels wird mittelfristig neu geschrieben werden müssen..."
Ich weiß nicht genau, was du mit neu schreiben meinst, aber eine echter rewrite ist ja nicht dein Ernst. Die Stärke des chaotischen Linuxmodells war ja bisher immer, dass es inkrementelle mini-rewrites in subsystemen gab. Wenn du dir anschaust, wie lange das Mozilla-Projekt gebraucht hat, bis die Suite so richtig abgehoben hat, und wie grausam der Verlust an Marktanteilen in dieser Zeit zugeschlagen hat, weil es die ganze Zeit eben nur die grottige 4er-Suite gab, und dann noch im Hinterkopf hast, dass Mozilla zwar codemäßig ungefähr den selben Umfang hat wie ein aktueller Kernel, aber das eben in C++ und nicht in C und auch auf weniger Plattformen und mit weniger Hardwarenähe als der Kernel, dann sollte dir klar sein, dass es keinen "rewrite" geben wird.
Dass der Kernel architekturelle Defizite hat, ist sicher jedem schon mal aufgefallen, der sich mit dem Quelltext beschäftigt hat - aber das heißt ja nicht, dass man das ganze Ding wegwerfen muss. Warte doch erstmal ab, wie sich HAL entwickelt, ob es nicht vielleicht irgendwann ein moderneres internes Speichermanagement geben wird, ob die jetzige Tendenz zur Ausfaktorierung von Subsystemen nicht weiter anhält.
Und der Vergleich mit *BSD hinkt übrigens wirklich - da der Linuxkernel nicht weiß, mit welchem gcc er übersetzt wird, kann er auch schlecht Binärkompatibilität garantieren - bei BSD ist der Kernel und der Compiler ja Teil eines fixen Systems.
Ich glaube, die Attraktivität von Linux liegt in erster Linie am Pragmatismus der Entwickler - und wer das eben nicht Attraktiv findet, nun gut, der wird mit *BSD wahrscheinlich wirklich glücklicher sein. Irgendwie finde ich das gerade aber gar nicht schlimm. Selbst wenn es einen "Server-Kernel"-Fork gibt oder andersrum einen "Desktop-Kernel", würde ich eh vermuten dass dann die beteiligten Entwickler sehr schnell merken würden, wie viel sie dann doch gemeinsam haben.
Der Linuxkernel wäre als kommerzielles Projekt gar nie entstanden, denn zum damaligen Zeitpunkt wäre ein weiteres kommerzielles Unix faktisch nicht verkaufbar gewesen, der Markt war schon zersplittert genug. Und daher kann man zwar berechnen, wie teuer die Entwicklung gewesen wäre, hätte man sie kommerziell durchgeführt, aber schlussendlich ist das ein unbrauchbarer Wert.
Über das Design lässt sich sicherlich streiten; nur muss man halt verstehen, daß eben alles nicht am Reissbrett entwurfen wurde. Sondern die einzelnen Strukturen wurden eben einmal entwickelt, erweitert, teilweise über den Haufen geworfen und so weiter. Eben gewachsen. Aber so wächst eben jedes Betriebssystem, sei es der Windows-, der Solaris- oder eben der Linuxkernel. Jeder hat gewisse Altlasten an Bord, die man heute am liebsten beseitigen würde. ABER LEIDER IST DAS VIEL ZU AUFWÄNDIG! (oder stösst auf Widerstand bei den Verantwortlichen).
Und der Linuxkernel wird nicht neugeschrieben werden. Vielleicht werden sich ein paar Leute der Probleme, die du angesprochen hast (und von denen ich noch nie als Schwierigkeit in der Kernelentwicklung gehört habe), annehmen und eine Reihe von Patches abliefern, die diese Missstände beheben werden. Vielleicht oder vielleicht auch nicht. Ich glaube schon, daß der harte Kern der Entwickler so vorausschauend sind, daß sie das Problem "Speicherverwaltung" -- wenn es denn eins sein sollte -- entdecken und dran arbeiten werden.
sind doch alles Module. Die Distributionen gehen sinnigerweise so vor, dass sie alle möglichen Module vorkompilieren. Muss man nicht mehr - wie teilweise früher - lästiges Selberkompilieren durchführen. Gut, für manche bedeutet das, auf ein intelektuelles Erfolgserlebnis zu verzichten, aber ihm Grunde ist die Selbstkompiliererei stumpfsinnig und öde. Insgesamt gute Sache.
Ich finde, das Wichtigste wurde mal wieder übersehen:
Neben dem Kernel wird auch der gute Linus immer fetter und dadurch immer ungeeigneter für den IT-Markt. Seine Gesundheit wird in Zukunft immer instabiler durch das Hinzufügen weiterer Ess- und Fressattacken. Existierende Diät- und Sportprogramme halte ich für ausreichend, stattdessen favorisiert Linus nur echtes Fast-Food im Magen.
Bei Diät- und Sportprogrammen handelt es sich um Ernährungsumstellungen, die den Körper optimal mit Nährstoffen versogen und gleichzeitig die Gesundheit fördern. Diese Technologie stammt aus der Ökotrophologie und wurde schon vor 2500 Jahren bei Griechen entwickelt.
Meine Kritik ist auch vor dem Hintergrund der zunehmenden Verfettung der Weltbevölkerung zu verstehen, die u.a. wachsenden Druck und Stress durch übermäßige Essensaufnahme ausgleicht.
Andrew Morton, Top-Sportler im Kernelprojekt, sieht die gegenwärtige Entwicklung von Linus entspannter. Zwar ist wahr, das sein Bauchumfang rasant voranschreitet. Allerdings gibt er zu bedenken, dass dieses Feature optional ist und einzelne Unternehmen noch immer genügend Raum in speziell zugeschnittener Bekleidung lassen. Dem beleibten Entwickler gewinnt Morton trotzdem eine positive Seite ab.
Dr. Best PS: Lieber Linus, beweg Dich mal wieder mehr, dann haben wir alle länger was von Dir!
>>Neben dem Kernel wird auch der gute Linus immer fetter<<
Wenn man Bilder von ihm von vor zehn Jahren sieht mag das so vorkommen. Allerdings ist das nur eine Täuschung. Heutzutage wird er mit viel mehr Polygonen gerendert, was zum runderen Bauchumfang beiträgt. Und dank Trueform kann man ihn (falls der ATI Treiber nicht vorher explodiert) in seiner vollen Pracht genießen.
Wenn ich mir den Webshop von CA so anschaue, dann habe ich nicht das Gefühl, dass sie sonderlich an einer Verbreitung an Linux auf dem Desktop interessiert sind. Ok Linuxapplikationen für den Server haben sie schon. Aber im Webshop wird man ja schon mit "Welcome Microsoft users" begrüßt. Allein die Tatsache, dass im "schlimmsten" Fall möglicherweise der Virenscanner und AntiSpyware unter Linux als dominantem Desktop OS überflüssig würden (ich das ist umstritten und nicht wirklich vorhersagbar, aber auf jeden Fall sind sie weit weniger notwendig als unter Windows) lässt sie dort sicherlich sorgenvoll auf die Bilanzen blicken. Von anderer Software, die sie verkaufen, die bei Linux umsonst dabei liegt (firewall etc.) ganz zu schweigen.
Also wenn man es anders betrachtet sagt Sam Greenblatt ja nichts anderes als: wir wollen Linux nicht auf dem Desktop. Denn wer will schon auf seinem Desktoprechner auf Unterstützung seiner Multimedia Hardware verzichten. Und seine oberste Loyalität gilt dabei sicherlich nicht der positiven Entwicklung von Linux für den Desktop, sondern den Bilanzen seines Unternehmens.
Warum er gerne Xen noch ein wenig aufhalten möchte ist mir nicht ganz klar. Aber vielleicht hatte da sein Kumpel aus Redmond eine kleine Bitte. Denn Xen ist für M$ schon ziemlich bedrohlich. Da habe sie gerade mit Virtual PC eine Virtualisierungslösung angeschafft und die einigermassen in Windows integriert, da ist Linux schon wieder einen Schritt weiter mit einer überlegenen Technologie. Die müssen sich langsam vorkommen wie beim Hase und Igel.
Sorry, aber der Laden nervt. Jammern, mosern, meckern, und das alles was von denen kommt. Wenn ihnen die Entwicklung von Linux nicht gefällt, dann sollen sie den Kernel 2.4 forken, und was eigenes draus machen, aber halt, das wäre ja arbeit, und würde möglicherweise sogar Geld kosten. Also macht man vermutlich nichts, und nöhlt weiter rum. Saftladen...
Für mich sind die Kritikpunkte von Sam Greenblatt nur Getrolle auf höherem Niveau. Wenn es CA nicht passt wie der Linuxkernel entwickelt wird, dann sollen sie halt den Source forken und die Sachen einbauen bzw. rausschmeissen, welche ihnen gefallen oder passen. Niemand zwingt irgendjemand Linux einzusetzen. Nur in der letzten Zeit häufen sich die Fälle in denen Firmen meckern das der Kernel sich nicht in die von ihnen gewünschte Richtung entwickelt. Sie haben keine Kontrolle darüber, also wirkt gemeckert anstatt konstruktiv daran was zu ändern.
Dabei übersehen alle das Linux zuallererst als Desktopsystem von Linus entwickelt wurde. Er wollte ein Unix für daheim!!!!! Nichts anderes!! Linux kehrt also zu seinen Wurzeln zurück als Desktopsystem zurück. Und da 99% aller Computer weltweit als Desktopsystem eingesetzt werden, werden in den nächsten Jahren die Desktopfeatures im Kernel noch eher zunehmen.
Was versteht der Mann unter folgender Aussage : "Mit Sorge bemerkt man bei CA eine wachsende Instabilität des Linuxkernel durch das Hinzufügen weiterer Treiber für Spiel- und Musikanwendungen." Wird ein laufendes System instabil? Die Kernel-API? Ein Treiber der nicht geladen ist kann doch ein System nicht instabil machen. Was soll also diese Aussage? Wenn ich ein Serversystem verkaufe lass ich halt alles weg was nach Desktop riecht. SuSE benutzt für sein Serversystem (SUSE LINUX Enterprise Server 9) auch einen anderen Kernel wie für das Desktopsystem SuSE 9.3. Der Kernel für SLES wird von der Firma extra gewartet. Ich hab also eine stabile API, weil eine Kernelversion und Compiler und Bugfixes fliessen auch regelmäßig ein. Und SuSE hat sich, glaube ich, noch nie über den Linuxkernel beschwert.
Zudem kommt die Aussage von einem Vizepräsidenten von CA! Wenn jemand mal soweit oben ist, sitzt so jemand doch den ganzen Tag in Strategiesitzungen und programmiert keine einzige Zeile Code mehr. Wenn die Kritik von einem Programmierer von CA kommen würde, der auch noch aktiv an der Kernelentwicklung beteiligt ist, dann könnte man sich auf eine Diskussion einlassen. So ist das nur ein weiteres belangloses Kapitel in der Linuxentwicklung.
Der Link hinter Hypervisor zeigt wieder auf diesen Artikel, ist das absicht?
ein '"' war falsch gesetzt, daher diese Konfusion! Jetzt funktioniert der Link richtig!
Danke für den Hinweis!
MfG
Präzise, die Ausgabe mit Werbung findet doch jeder ;-)
MfG
Und wenn ihm die Entwicklung nicht passt, soll er doch einen Kernel-Server-Fork starten.
F...BSD ist das schwächste unter den BSDs.
Open- und NetBSD sind genau die richtigen BSDs, die
die Welt braucht, F ist auf dem besten Wege ein Linux-Clown
zu werden.
Euer Brain
FreeBSD interpretiert, vielleicht meint er ja FuckingBrain?
FreeBSD ist Performance technisch den anderen BSD's überlegen siehe dazu:
http://www.bsdforen.de/showthread.php?t=1809
http://bulk.fefe.de/scalability/
Stichwort: Interpunktion.
http://bulk.fefe.de/scalability/
Ein Garant für Qualität in jeder Hinsicht, klaro und die
Erde ist eine Scheibe.
Vielen Dank für Euer Verständnis!
Gruß
Bernd
Troll...
Vielleicht sollten sich die Herrn Kernel-Gurus langsam mal Gedanken machen, wie sie den Linux-Kernel aufbaumäßig endlich ins aktuelle Jahrtausend migrieren. Hardware-Treiber haben nun mal nix im Kernel zu suchen (philosophische Betrachtungen jetzt mal außen vorgelassen). Würde man sich bei Linux wirklich nur auf die Funktionalität beschränken, wenn dürften die Kernel-Maintainer mit einem Schlag viel weniger Arbeit haben (da sie ja nicht mehr jeden dämlichen Treiber in den Kernel-Code flicken müssen) und könnten sich stattdessen voll auf die eigentlichen Aufgaben eines Kernel konzentrieren. Hardware-Hersteller könnten - wie bei anderen Betriebssystemen auch - einfach Treiber mit ihrer Hardware ausliefern und via simplem Skript (z.B. durch Kopieren in ein festgelegtes Verzeichnis) auf dem Zielsystem installieren, ohne erst am Kernel rumfummeln zu müssen oder sich mit den Maintainers rumschlagen zu müssen, damit der Treiber reinkommt. Die Distributoren müßten dann nicht mehr für jeden Zweck einen eigenen Kernel bauen (und pflegen !!!), sondern würden einfach mal diese, mal jene Treiber installieren (ein Server braucht keine Unterstützung für Sound oder Graphik, ein Arbeitsplatzrechner wohl kaum Treiber für Server-Chipsets, die niemals in einem normalen PC verbaut werden. Damit sollte sich auch die Zeit, die Linux zum Hochfahren benötigt, deutlich reduzieren lassen - ohne daß man sich einen "optimierten" Kernel baut.
Eigentlich sehe ich nur Vorteile, wenn man diesen ganzen Treiberschlunz aus Linux rausoperieren würde. Als für mich angenehmen "Nebeneffekt" würde vermutlich endlich auch eine definierte stabile (!) Schnittstelle zwischen Treiber- und eigentlichem Kernel-Code rausspringen, denn sonst bringt das alles für die Kernel-Maintenance nicht wirklich was. Und vermutlich wird dies einer der Gründe sein, weshalb wohl Treiber bis ans Ende aller (Linux-)Tage im Kernel bleiben werden und dort Arbeit und Ärger machen. Denn es werden sich wieder jede Menge (meist selbsternannte) Experten finde, die zu wissen glauben, daß eine stabile Treiberschnittstelle nicht möglich ist (bei anderen Betriebssystemen geht das zwar, aber das ist natürlich was ganz anderes ...) oder die Linux sofort im ganz ultra bösen Closed-Source-Sumpf versickern sehen, weil man ja dann ohne weiteres Treiber verwenden kann, deren Source-Code nicht offengelegt ist.
Tschö,
Carsten
Also, ich weiß ja nicht was nicht, was du genau Aufbaumäßig mit dem aktuellen Jahrtausend meinst. Also erstens ist Linux schon von Anfang an aufbaumäßig nicht auf der Höhe der Zeit, wie schon die Diskussion zwischen Andrew S. Tannebaum und Linus Torvalds auf der damaligen Minix Liste zeigt (Microkernel vs. Monolithischer Kernel). Aber die Praxis zeigt, es funktioniert. Während jede menge technologisch überlegene Betriebssysteme (z.B. Hurd) über eine absturzgefährdete Kommandozeile kaum hinauskommen, funktioniert Linux prächtig. Da wäre es doch mal an der Zeit die Theorie zu überdenken.
Ich denke, dass es durchaus ein Vorteil von Linux ist, dass die Treiber mit dem Kernel entwickelt werden.
1. ist deine Idee solange zu warten, bis die Hersteller ihre Hardware mit Treibern für Linux ausliefern ziemlich illusorisch und würde wohl eher den Tod von Linux durch fehlende Hardwareunterstützung bedeuten.
2. Sorgt dies meiner Ansicht nach für Stabilität. Denn die Treiber müssen ja Zugriff auf die Hardware haben und können damit jede Menge instabilitäten verursachen, wenn sie schlecht programmiert sind. Das hat ja auch schon M$ gemerkt und deshalb Prüfungen mit anschließender Signatur durch Microsoft eingeführt. Die Treiberentwicklung den Hardwareherstellern zu überlassen, die weniger vom Kernel verstehen, als die Kernelprogrammierer, würde deshalb wohl zu erheblichen Instabilitäten führen. Abgesehen davon, ist es
3. so, dass defakto einige Firmen die Treiber programmieren und anschließen an die Kernel Entwickler schicken, die sie dann integrieren (oder auch nicht). Also kann man das ganze so ähnlich wie die Treibertests und Signierung von Microsoft, also so eine Art Qualitätssicherung sehen. Nur gescheit programmierte Treiber werden in den offiziellen Kernel aufgenommen.
Wenn du der Ansicht bist, dass es ganz gut geht eine definierte stabile(!) Schnittstelle zur Treiberprogrammierung zu definieren, dann hält dich keiner davon ab es zu tun und an die Kernel Entwickler zu schicken. Ich bin sicher sie werden sich über deine Beiträge freuen. Wenn du es nicht kannst, dann solltest du vielleicht nich über Dinge reden, von denen du nichts verstehst.
Patrick
1. ist deine Idee solange zu warten, bis die Hersteller ihre Hardware mit Treibern für Linux ausliefern ziemlich illusorisch und würde wohl eher den Tod von Linux durch fehlende Hardwareunterstützung bedeuten.
Davon war doch gar keine Rede. Treiber können nach wie vor mit dem Kernel ausgeliefert werden, von mir aus kann dieser Grundbestand an Treibern auch von den Kernel-Maintainers gewartet werden. Aber darüberhinaus wäre es für Drittanbieter - neben dem Kernel-Maintainer und dem Distributor - deutlich einfacher, einen neuen Treiber in ein laufendes Linux-System zu integrieren (z.B. eben durch das einfach Kopieren in ein speziell benamstes Verzeichnis).
2 und 3
Nichts anders habe ich auch geschrieben (3), und daß Treiber durchaus die Systemstabilität gefährden können (2) ist mir durchaus bekannt, darum ging es doch auch dem guten Sam. Bloß, die Stabilität wird ganz sicher nicht dadurch schlechter, wenn ich statt 1000 nur noch 50 Treiber im System habe, oder siehst Du das etwa anders ? Und was ich mir nicht so ganz vorstellen kann, ist, daß die Kernel-Maintainer wirklich jeden Treiber logisch nachvollziehen. Die mögen auf gewisse Dinge achten, aber sicher nicht darauf, daß der Treiber keine Bugs enthält (außer vielleicht ganz offensichtliche).
Wenn du der Ansicht bist, dass es ganz gut geht eine definierte stabile(!) Schnittstelle zur Treiberprogrammierung zu definieren, dann hält dich keiner davon ab es zu tun und an die Kernel Entwickler zu schicken. Ich bin sicher sie werden sich über deine Beiträge freuen.
Es gibt Betriebssysteme, die bereits seit langem eine definierte stabile (!) Schnittstelle zur Treiberprogrammierung besitzen. Es ist daher denke ich müßig, darüber zu diskutieren, ob ich der Ansicht bin, daß es geht, oder eben nicht, einfach deshalb, weil es völlig unerheblich ist, ob ich es so sehe oder nicht.
Wenn du es nicht kannst, dann solltest du vielleicht nich über Dinge reden, von denen du nichts verstehst.
Ah ja, wieder die übliche Schiene: ich kann es nicht gleich programmieren oder wenigstens exakt beschreiben, also soll ich doch besser die Klappe halten, da ich ja gar keine Ahnung davon habe (wovon eigentlich ?). Hätte ich geschrieben, daß das jetztige Treibersystem von Linux toll ist, hättest Du das wahrscheinlich geschrieben. Aber das wäre ja auch keine Kritik gewesen ...
Bloß, die Stabilität wird ganz sicher nicht dadurch schlechter, wenn ich statt 1000 nur noch 50 Treiber im System habe, oder siehst Du das etwa anders ?
Also hier verstehe ich nicht ganz wie du das meinst. Ich kann den Kernel kompilieren wie ich will. Entweder mit 1000 oder mit 50 Treibern fest einkompiliert. Ich kann die meisten auch als Modul kompilieren, die bei Bedarf hinzugeladen werden. Was stört es mein System, wenn da in einem Verzeichnis ein Modul darauf warted gebraucht zu werden ohne das es jemals zur Ausführung kommt auch wenn es vielleicht 1000 sind? Und das Beste: du must gar keine Datei mehr in ein Verzeichnis kopieren (was allerdings auch funktionert) um den Treiber zur Laufzeit zu starten. Er ist schon da.
Oder meinst du es sollten nur noch insgesamt 50 Treiber in der Kernel Source integriert werden. Da wären wir wieder bei Punkt 1.
Es gibt Betriebssysteme, die bereits seit langem eine definierte stabile (!) Schnittstelle zur Treiberprogrammierung besitzen.
Welche meinst du denn? Und welche Vorteile haben sie deiner Meinung nach?
Ah ja, wieder die übliche Schiene: ich kann es nicht gleich programmieren oder wenigstens exakt beschreiben, also soll ich doch besser die Klappe halten
Wenn du diese "übliche" Schiene schon öfter erlebt hast, dann ist ja vielleicht auch was dran?
Aber hast du dir schon mal überlegt, dass solche kritik so ankommen kann als würdest versuchen Beethoven kompositionsunterricht zu geben indem du sagst: "Hey, mach mal schöne Musik, so wie der Mozart sie macht".
Ansonsten finde ich Kritik prima. Je konstruktiver desto besser;-)
Eigentlich meine ich mehr oder weniger genau das. Für mich haben Gerätetreiber generell nichts im Kernel zu suchen (was aber nichts damit zu tun hat, daß sie vom Kernel geladen und verwaltet werden). Bei Treibern für z.B. Motherboard-Chipsets würde ich da vielleicht Ausnahmen machen, weil es womöglich zu aufwändig sein dürfte bzw. man sich zu sehr an platformabhängige Legacy-Funktionen klammern müßte, um die auch rauszuziehen. Aber Treiber für Geräte wie Graphik-, Sound-, Netzwerk- oder andere Karten will ich nicht im Kernel selbst sehen (denn eigentlich haben sie mit dem Kernel selbst ja nix zu tun, sie kommunizieren ja nur mit ihm - so wie eigentlich jedes gewöhnliche Programm). Das bringt natürlich einen gewissen Aufwand mit sich, aber ich denke, längerfristig lohnt sich das, weil die Kernel-Entwickler einfach einiges an Arbeit von der Backe haben.
Nebenbei finde ich das Handling via "in Verzeichnis rein" bzw. "aus Verzeichnis raus" deutlich angenehmer, als am Kernel rumzuwursteln. So wird es beispielsweise unter BeOS gemacht. Einen (hoffentlich vorhandenen ;-)) Treiber für die Graphikkarte aus dem Internet saugen und installieren ? Ganz einfach: Datei holen (ohne passenden Treiber sollte BeOS zumindest im VESA-Mode laufen), ggfs. auspacken (oftmals via ZIP komprimiert) und in das entsprechende Verzeichnis (habe den exakten Pfad nicht im Kopf) ablegen. Nach dem nächsten Reboot funktioniert dann die Karte richtig (hoffentlich ;-)).
Welche meinst du denn? Und welche Vorteile haben sie deiner Meinung nach?
OS/2. Dort funktionieren die meisten Treiber von Version 2.0 (müßte 1991 erschienen sein) noch mit den aktuellsten Ausprägungen (Server for e-Business bzw. eComStation), obwohl sich an der Funktionalität schon einiges getan hat. Beispielsweise wurde der komplette I/O-Layer für Plattenzugriffe überarbeitet, aber das hat ja nun nicht wirklich Auswirkungen auf z.B. den Netzwerkbetrieb, also weshalb sollte man die Netzwerkkartentreiber ändern müssen ?
Wenn du diese "übliche" Schiene schon öfter erlebt hast, dann ist ja vielleicht auch was dran?
Vor allem beobachte ich dieses Schema auf dieser Seite hier immer wieder (ich lese hier ständig), sobald sich jemand erdreistet, Kritik an Linux/"Freier" Software/Open-Source zu äußern. Da wird man dann gerne abqualifiziert mit solch schlagkräftigen "Argumenten" wie "bleib doch bei Windoofs", "machst doch erst mal besser", "du moserst ja nur unproduktiv rum" oder "hast Du schon mal einen Treiber geschrieben ? nein ? dann beschwer Dich auch nicht, daß Dein Rechner unter Linux ständig absemmelt".
Aber hast du dir schon mal überlegt, dass solche kritik so ankommen kann als würdest versuchen Beethoven kompositionsunterricht zu geben indem du sagst: "Hey, mach mal schöne Musik, so wie der Mozart sie macht".
Um schön oder nicht schön geht es hier ja nicht. Aber wenn ein Herr Beethoven - würde er heute noch leben - behaupten, man könne nur mit Celli keine Rockmusik machen, obwohl das Apocalyptica bereits seit einiger Zeit ganz gut hinkriegen (finde ich), dann würde ich mich schon erdreisten, seine Aussage in Zweifel zu ziehen, obwohl ich selber nicht komponieren kann und dementsprechend ja - gemäß der von Dir angebrachten Logik - nicht befugt wäre, mich überhaupt zu dem Thema zu äußern. Herr Beethoven (oder der Linux-Kernel-Hacker) mag ja ein Genie (gewesen) sein, aber deshalb ist er noch lange nicht unfehlbar. Und das ist wiederum völlig unabhängig davon, ob ich komponieren (Treiber(modelle) programmieren) kann. Herr Beethoven (der Kernel-Entwickler) mag eine bestimmte Ansicht zu einer sein Fachgebiet betreffenden Frage/Problemstellung vertreten, aber nur weil er zweifelsohne sehr viel für die Musik (für Linux) geleistet hat, ist seine Ansicht nicht zwangsläufig richtig.
Ansonsten finde ich Kritik prima. Je konstruktiver desto besser;-)
So unkonstruktiv fand/finde ich meine Kritik nicht, ich sage, was man ändern sollte/könnte. Wie genau sie das dann machen, sollen sich besser diejenigen überlegen, die sich wirklich damit auskenne, also die Kernel-Hacker.
Aber wie dem auch sei wir werden hier in unserer Diskussion nicht die (Linux-)Welt verändern. Denn in der Opensource Welt verändert man nur etwas -und das ist ja gerade das schöne an Opensource, das man im gegensatz zum Closed Source den Code verändern kann- indem man Code schreibt. Und da ist der Vergleich mit der Musik ja vielleicht auch ganz treffend. Denn auch dort kann man nur die Musikwerlt verändern indem man Musik schreibt/spielt. Es kann tausende geben die Beethovens 9. Symphonie forden, das ändert gar nichts. Es muss einen geben der sie schreibt. Beethoven hat sie geschrieben und zwar so, wie sie ihm gefiel und wie er es für richtig hielt. Und hinterher hats dem einen oder anderen gefallen. So änlich finde ich, ist das auch bei der Software (sogar bei Closed Source, nur das da die Unternehmensleitung und nicht der Programmierer bestimmt was gemacht wird. Das ist aber auch gar nicht so anders als bei der heutigen Musikindustrie). Und hinterher bestimmen die Zuhörer/Anwender darüber wie gut sie das ganze finden und ob und wie oft sie sich das "Produkt" anhören/anwenden. Und wer die meisten Zuhörer/Anwender hat, der war der tollste. (naja, vielleicht auch nicht immer...)
Also höre dir doch einfach Apocalyptica an und erfreue dich an der schönen Musik und fordere nicht von Beethoven Rockmusik zu machen;-)
Na, da sind wir ja dann doch einer Meinung. ;-)
Wer verwaltet sie? Wer bestimmt was offiziell unterstützt wird, oder will man sich ohne Qualitätskontrolle auf die Hardwarehersteller/sonstige Programmierer verlassen. Wie wird die Zusammenarbeit zwischen Treiber- und Kernel-Programmereren koordiniert. No schlimmer, wie geht man beim Debuggen von Problemen vor?
Ich sehe nicht, daß sich da soviel zum Status Quo ändern wird. Die Treiber, die auch heute schon vom Kernel-Team betreut werden, bleiben ja auch dann erhalten und werden auch dann noch vom Kernel-Team verwaltet (es sei denn, man lagert die Treiber dann in eine eigene Maintenance-Gruppe aus, was ja dann leicht möglich wäre). Aber auch heute schon kann man ja durchaus weitere Treiber in den Kernel einbauen, und diese Treiber können ohne weiteres miserabel sein. Und davon bekommen heute die Kernel-Maintainer auch nix mit.
Also höre dir doch einfach Apocalyptica an und erfreue dich an der schönen Musik und fordere nicht von Beethoven Rockmusik zu machen;-)
Wie ich schon sagte: ich fordere gar nichts. Ich tue nur meine Sicht der Dinge kund. Wenn die jetztige Struktur bei Linux beibehalten wird (und das wird sie sicher, da bin ich mir sicher), dann wird sich die Linux-Entwicklung in Zukunft immer mehr mit sich selbst beschäftigen (immer mehr Treiber sind bei neuen Releases anzupassen), und bei den Distributoren werden immer mehr Leute parallel das Rad neu erfinden, indem sie jeweils Kernels mit gleicher/ähnlicher Funktionalität bauen und warten (wobei sie jeweils auch die gleichen Fehler machen werden, was menschlich ist). Und wenn dann nicht doch irgendjemand sich wirklich dieses Problems annimmt, wird die Weiterentwicklung von Linux mehr und mehr in Richtung Stillstand tendieren (was man heute ja schon erahnen kann), es sei denn, man erspart sich den einen oder anderen Review des geänderten Code und riskiert damit (Sicherheits-)Probleme. Das alles natürlich IMHO.
Apocylyptica höre ich mir aber dennoch an und erfreue mich an der sehr schönen Musik.
Das Problem liegt zum großen Teil am gcc. Unterschiedliche Compiler erzeugen unterschiedliche Kernel-ABIs. Diverse Compilerflags (REGPARM) verändern das API.
Solange das der Fall ist, ist er völlig vergeudete Zeit, die interne Kernel-API stabil zu halten, zumal die Kernelentwickler so falsche Ansätze korrigieren könnten, während sie sonst mehrere Interfaces über zig Versionen pflegen oder auf lange Zeit mit dem falschen Ansatz weiterarbeiten müssten.
Nicht umsonst will z.B. Trolltech mit Qt4 das Qt-API ausmisten, da Qt3 aufgrund teilweise redundanter Interfaces viel zu aufgeblasen ist.
> Das Problem liegt zum großen Teil am gcc. Unterschiedliche Compiler erzeugen unterschiedliche Kernel-ABIs. Diverse Compilerflags (REGPARM) verändern das API.
> Solange das der Fall ist, ist er völlig vergeudete Zeit, die interne Kernel-API stabil zu halten, zumal die Kernelentwickler so falsche Ansätze korrigieren könnten, während sie sonst mehrere Interfaces über zig Versionen pflegen oder auf lange Zeit mit dem falschen Ansatz weiterarbeiten müssten.
Deine Begründung wird von diesem Artikel unterstrichen, der von dem Kernelentwickler Greg Kroah-Hartman stammt:
http://www.kroah.com/log/linux/stable_api_nonsense.html?seemore=y
Wie ? Was meinst du da ? Man kann beim laufendem kernel keine Treiber hinzufügen ? Verstehe ich nicht.
Hast du schon was von "Loadable Kernel-Modules" gehört ?
Bei uns läuft seit einiger Zeit eine Datenbank unter Linux (ca. 500GB groß) jetzt ist das Ding zu klein geworden und es sollen externe Platten dazu kommen. (Aufstockung auf ca. 1000GB) Dazu ist ein neuer Controller notwendig. Dieser aber benötigt einen neuen Treiber. Das Problem ist nun, dass ich den Treiber nur dann installieren kann wenn ich den kompletten Kernel neu übersetze, denn mit dem alten Kernel arbeitet der Treiber wieder nicht zusammen. Den Kernel kann ich aber nicht akualisieren, da mir sonst der Datenbankhersteller keine Unterstützung mehr gibt. Das Ergebnis sind nur Probleme. Mit einer stabilen Treiberschnittstelle wäre das Problem zu umgehen gewesen.
Aufholen vielleicht. Überholen? Da mus schon noch ne Menge passieren. Und MS muss die Entwicklung einstellen. Dann werden Deine Träume wahr.
> der im Grunde ja der einzige technische Vorteil von Windows ist
Ja, das ist die Überzeugung der Linuxfanatiker. MS ist nur bei Multimedia besser (wenn überhaupt). Sonst ist Linux haushoch überlegen. Komisch nur, dass sich Linux im Desktopmarkt immer noch nicht durchgesetzt hat. Nicht nur nicht durchgesetzt, der Marktanteil stagniert bei unter 5%. Seit Jahren.
Aber solange die Linuxer nicht sehen, das Windows noch ein paar Vorteile mehr zu bieten, solange wird sich auch nicht wirklich etwas ändern.
> Die Treiberentwicklung den Hardwareherstellern zu überlassen, die weniger vom
> Kernel verstehen, als die Kernelprogrammierer, würde deshalb wohl zu erheblichen
> Instabilitäten führen.
Wie machen das die HW-Hersteller dann mit den Treibern für Windows? Ist der Windowskernel (oder besser gesagt die Schnittstelle zu diesem) einfacher zu verstehen als der Linuxkernel?
> Ich bin sicher sie werden sich über deine Beiträge freuen. Wenn du es
> nicht kannst, dann solltest du vielleicht nich über Dinge reden, von denen
> du nichts verstehst.
Hast Du schon mal Software in größerem Maßstab entwickelt? Anscheinend nicht. Glaubnst Du ernsthaft, jemand will von einem Außenstehenden ein Konzept aufgedrückt bekommen? Die Kernelentwickler werfen doch nicht ihre eigenen Konzepte so mir nichts dir nichts über den Haufen und stricken den Kernel um. Aber ich sehe, Du verstehst etwas von den Dingen, über die Du schreibst.
Windows bietet eine definierte Schnittstelle für Treiber. Das ermöglicht es Firmen, zu vergleichsweise geringen Kosten Treiber für Win zu entwickeln. Und die funktionieren dann sogar. Linux bietet das nicht. Zusammen mit der geringen Verbreitung ergibt das ein extrem schlechtes Kosten-Nutzen-Verhältnis. Den rest kriegst Du vielleicht noch selber zusammen.
ich kann mich entscheiden, heute nach feierabend meinen rasen zu mähen oder ein wenig am kernel mitzuhelfen, aber niemand kann mich zwingen (obwohl es die nachbarn bei der sache mit dem rasenmähen ständig versuchen
), und niemand kann mir vorschriften machen, _was_ ich zu programmieren habe.
wenn für dich persönlich ein bestimmtes feature wichtig ist: entwickle es (oder zahle jamenden dafür, dass er's tut), aber komm nicht zum jammern.
wenn dir die richtung bei linux nicht passt: wechsle zu *BSD oder Mac oder was. keiner zwingt dich.
natürlich muss produktive kritik erlaubt sein, aber sowas wie
> Vielleicht sollten sich die Herrn Kernel-Gurus langsam mal Gedanken machen,
> wie sie den Linux-Kernel aufbaumäßig endlich ins aktuelle Jahrtausend migrieren
übersetze ich zu "ich will alles, und zwar gleich, und zwar umsonst!"
just my 0,02
-- o
Was machst du dann hier auf pro-linux?
Wenn in einem halben Jahr bekanntgegeben wird, daß Linux nicht mehr weiterentwickelt wird (rein illusorisch, kann/wird natürlich nicht passieren), ist mir das auch Wurst. [...] Und wenn Oracle morgen sein RDBMS für *BSD rausbringt, ist Linux bei mir ruck-zuck von der Platte runter
Und wenn es bis dahin Oracle immer noch nicht offiziell (inoffiziell funktioniert es schon) für BSD gibt?
Warum benutzt du nicht einfach Windows? Oder macht das mehr Aufwand/Probleme als Linux?
my €0,02
Weil ich mich generell schon für Linux interessiere, es hier immer so interessante und sachliche Diskussionen gibt (Vorsicht: Ironie ;-)) und weil ich nirgendwo ein Schild gesehen habe: "wer Linux nicht perfekt findet oder gar etwas an Linux verbesserungswürdig findet, hat hier nichts zu suchen".
Und wenn es bis dahin Oracle immer noch nicht offiziell (inoffiziell funktioniert es schon) für BSD gibt?
Warum benutzt du nicht einfach Windows? Oder macht das mehr Aufwand/Probleme als Linux?
Wenn Linux tatsächlich "verschwinden" würde und es noch kein Oracle für *BSD geben sollte, würde ich tatsächlich Windows verwendet. Da ich aber berufsmäßig täglich mit Oracle auf UNIX arbeite und ich zudem kein Windows-Fan bin (zu unflexibel), ziehe ich natürlich ein UNIX-(artiges-)System vor. Ok, und Oracle auf Windows hat so seine Tücken, auf die ich eigentlich keine Lust habe. ;-)
Ürbigens, ich habe schon darüber nachgedacht, Oracle über die Linux-Schnittstelle von FreeBSD zu betreiben, bislang konnte ich mir nur noch nicht dazu durchringen, das ganze zum Laufen zu bekommen, denn meiner Erfahrung nach funktioniert in der Kombination Oracle und *BSD/Linux von Hause aus nichts so, wie es soll. Das ist natürlich nur meine ganz subjektive Meinung :-/
Da frage ich mich jetzt aber, ob ich deine Erwartungen wegen der "sachlichen Diskussionen" erfüllt habe. Du scheinst mich ja für eine art Linux-Jünger zu halten.
Ich hoffe so schlimm ist es noch nicht mit mir. Habe mich nur jahrelang mit Windows rumgeärgert bis ich irgendwann ein Linux aufgespielt habe und bei vielen Dingen dachte. Ja genauso habe ich mir das bei einem Computer vorgestellt. Anfangs dauert vieles länger, aber man lernt viel und hinterher funktiert es (meist) reibungslos. Und man lernt sogar eine Menge, was man und Windows wieder einsetzen kann. Aber da sind wir ja wohl gar nicht so weit auseinander:
ich zudem kein Windows-Fan bin (zu unflexibel), ziehe ich natürlich ein UNIX-(artiges-)System vor
Aber ansonsten bin ich eigentlich gar nicht so ein fürchterlicher Überzeugungstäter, insbesondere wenn es einfach nur darum geht eine bestimmte Aufgabe zu erledigen.
*BSD wahrscheinlich das stabilere System.
Ürbigens, ich habe schon darüber nachgedacht, Oracle über die Linux-Schnittstelle von FreeBSD zu betreiben, bislang konnte ich mir nur noch nicht dazu durchringen, das ganze zum Laufen zu bekommen,...
Kenst du diesen link?
http://www.scc.nl/~marcel/howto-oracle.html
Eigentlich sind wir langsam an einem Punkt angekommen an dem wir zum weiterdikutieren ein Glas Bier vor uns stehen haben sollten.
Na, sagen wir mal, bei Deinem ersten Posting dachte ich, daß Du meinen Beitrag wirklich nur als blödes Rumgemecker verstanden hast, aber diese Meinung durfte ich dann bei Deiner nächsten Anwort zum Glück ins Positive korrigieren.
Von daher denke ich, wir haben die Kurve bzgl. sachlicher Diskussion durchaus gut gekriegt.
Habe mich nur jahrelang mit Windows rumgeärgert bis ich irgendwann ein Linux aufgespielt habe und bei vielen Dingen dachte. Ja genauso habe ich mir das bei einem Computer vorgestellt.
Naja, der erste Teil war/ist bei mir genauso, ich ärger(t)e mich auch immer, daß es unter Windows einfach nicht möglich war/ist, zehn Handgriffe zu machen, ohne daß man auf etwas stößt, das nicht so funktioniert, wie man es eigentlich hätte erwarten dürfen. Leider waren meine Linux-Erfahrungen aber auch nicht nur von Erfolg gekrönt. Einer meiner ersten Kontakte mit Linux bestand darin, daß ich gerne zuhause irgendeine ältere SuSE-Distri (ich glaube, das war 4.irgendwas) installieren wollte, das aber nur mit Kernel 2.2 funktionierte (wegen dem SCSI-Adapter), unter dem aber wiederum meine Netzwerkkarte nicht lief, für die gab es nämlich nur einen 2.0er-Treiber. Vielleicht bin ich auch deshalb etwas geprägt, was die Treiberproblematik angeht.
Dazu kam dann noch, daß mich die Stabilität und das Multitasking von Linux nicht wirklich vom Hocker riss, da ich damals privat OS/2 verwendete, was in beidem Linux zu dieser Zeit überlegen war.
Kenst du diesen link?
http://www.scc.nl/~marcel/howto-oracle.html
Ne, kannte ich noch nicht, vielen Dank !!! Wie gesagt, ich habe mich bisher noch nicht so richtig um einen Ersatz für SuSE Linux bemüht, aber nachdem ich jetzt endlich Oracle installiert habe, werde ich mir das in einer ruhigen Minuten mal mit FreeBSD anschauen. Wäre mir sehr recht, wenn das klappen würde, denn SuSE ist mir einfach etwas aufgebläht dafür, das es einfach nur meine Oracle-DB betreiben soll. ;-)
Eigentlich sind wir langsam an einem Punkt angekommen an dem wir zum weiterdikutieren ein Glas Bier vor uns stehen haben sollten.
Yep, sehe ich auch so. Also, ein virtuelles Prost und einen schönen Nachmittag/Abend noch !
Ich nehme an, dass das mit ein Grund für die langsame Weiterentwicklung von Windows war (und ist). Da funktioniert ein und der selbe Treiber über mehrere Betriebssystemversionen hinweg, was man aber mit einer festgehaltenen Schnittstelle zu bezahlen hat. Nachdem bei den NT-Kerneln kaum noch was von der ursprünglichen Microkernel Architektur übriggeblieben ist, ist das Festhalten an einer Schnittstelle durchaus behindernd wenn man den Kernel weiterentwickeln möchte. Linux hat eben bei der Entwicklung den Vorteil, dass auf binäre Treiber keine Rücksicht genommen werden muß.
> wenn dürften die Kernel-Maintainer mit einem Schlag viel weniger Arbeit
> haben (da sie ja nicht mehr jeden dämlichen Treiber in den Kernel-Code
> flicken müssen) und könnten sich stattdessen voll auf die eigentlichen
> Aufgaben eines Kernel konzentrieren. Hardware-Hersteller könnten - wie bei anderen
> Betriebssystemen auch - einfach Treiber mit ihrer Hardware ausliefern und via simplem
> Skript (z.B. durch Kopieren in ein festgelegtes Verzeichnis) auf dem Zielsystem
> installieren
Der Gedanke greift leider etwas kurz, denn man ersetzt dadurch die Notwendigkeit, Treiber einmal in einen Kernel zu implementieren durch die Erfordernis, jeden Treiber in jede große Distribution zu integrieren. Wenn schon die Kernel-Maintainer damit überfordert sind, werden es die Distributoren dann erst Recht sein. Und die Hardware-Hersteller werden sich bedanken, für jede Distri wieder ein passendes Paket herausgeben zu dürfen.
Außerdem öffnet man Tür und Tor für Vendor Lock-Ins der Hersteller, die dann nur noch Binary-Treiber für eine Kernel-Version und eine Architektur rausgeben, die dann mit der nächsten wieder aus irgendeinem esotherischen Grund nicht mehr laufen. Schon jetzt gibt es solche Probleme z.B. mit nVidia-Grafikkarten auf PowerPC-Rechnern. Die Welt besteht eben nicht nur aus x86-Desktops.
Richtig. Nur wird nichts geschehen weil Linux selbst das Problem ist. Man hätte sich vor vielen Jahren nicht für einen Monoliten, sondern einem Microkernel und einem Hardware Abstraction Layer entscheiden sollen. So wie wir es von Windows und OSX her kennen, und es Richard Stallman auch immer wollte, mit Hurd allerdings Schiffbruch erlitt. Jetzt ist da nichts mehr zu machen. Der Kernel wird immer fetter und fehlerträchtiger werden. Wer zu spät kommt, den bestraft die Geschichte.
Was ist denn sonst der Unterschied von normalen Distries und z.B. Enterprise-Editionen?
Diese sind doch auf Server optimiert, ohne Multimedia-krams, oder?
Ich hab noch nie eine Enterprise- oder Sonstwie-Edition ausprobiert, das ist nur eine Annahme von der ich bisher ausgegangen bin...
??
Bitte um aufklärung
Deutlich ist zumindest dass der Entwicklungszyklus des Kernels zusehends langsamer und nicht schneller wird. Da helfen auch die minor-Revisions nicht drüber hinwegzutäuschen. Die Linuxgemeinde muss erst die Lehren der Software Crisis erneut erfahren, bevor sie zur Besinnung auf die Unix Tradition kommen.
Wenn die Prophezeihung des Kernelendes in 4 Jahren eintritt, wird Linux etwa 10 Jahre Entwicklungsarbeit verloren haben, die Longhorn zugute kommen werden. Deshalb hätte man schon vor 2.6 über eine Neuimplementierung mit Ziel 3.0 nachdenken sollen.
Full Ack!!
Euer Brain
Das Problem ist, dass die Hareware immer unübersichtlicher und schrottiger wird. Die neue HAL hilft hier aber etwas weiter.
Man mag gegen MS sagen wollen, was man will, aber ihre NDIS-Schnittstelle ist erste Sahne. So etwas fehlt es Linux und so lange es Torvalds und Co nicht gemerkt haben, wird weiter sinnlos Power verbraucht.
Meine 2 Cent dazu
Die Tatsache, daß freie Entwickler freie Treiber für genau jenes Zeugs schreiben, ist nicht nur von Vorteil, sondern essentielle Voraussetzung für die Verbreitung von GNU/Linux außerhalb des Server-Bereichs. Nur müssen die Treiber irgendwohin...
Was sind z.B. für dich "kleine Datenbanken"?
Ein Oracle-Cluster mit mehrere Gigabyte-Datenbanken würde ich nämlich nicht unbedingt als "kleine Datenbanken" bezeichnen, und trotzdem funktioniert es super.
Klar, mySQL mit ner 2 MB-Datenbank funktioniert auch.
Was ist für dich Hardware, die vom Server nicht unbedingt unterstützt werden muß? Das hängt sicher auch vom Server ab. Klar, nicht jeder Server braucht z.B. Firewire. Bei manchen allerdings wird darüber ein Drucker angeschlossen.
Nicht jeder Server braucht unbedingt Multimedia-Features. Bei Webservern, die auch noch Streaming unterstützen und die Streams rendern, macht sowas alllerdings Sinn.
Dass alles im Kernel ist, mag sicher Vor- und Nachteile haben (siehe die allseits bekannte Diskussion Microkernel gegen monolithische Kernel). Mir ist es aber lieber, alles im Kernel drin zu haben und ungewünschte Sachen zu entfernen, als für jedes blöde Gerät erstmal im Internet zu suchen, ob es Treiber dafür vom Hersteller gibt... ob es Treiber dafür von freien Programmierern gibt... ob vielleicht irgendeine andere Hardware auf dem gleichen Chipset basiert, und ich die verwenden kann... danke, aber das Gefrickel hab ich schon unter Windows genug.
Und wenn man einen Kernel selbst zusammen stellt (was sowieso kein DAU machen wird / machen sollte), und man dann einen Parameter vergißt, und die Oracle-Datenbank oder iptables oder sowas nicht mehr geht... da muß man sich dann halt selbst an die Nase fassen, denn gerade sowas ist gut dokumentiert.
( und wie gesagt: Kernel neukompilieren sollte sowieso kein völliger Laie machen )
Hatte ich doch schon: Webserver, Fileserver, kleinere DB-Server
Was sind z.B. für dich "kleine Datenbanken"?
Hmm, sagen wir mal bis max. 500 Concurrent Users und 100 GB Größe, generell aber nichts mit hoher I/O-Last.
Ein Oracle-Cluster mit mehrere Gigabyte-Datenbanken würde ich nämlich nicht unbedingt als "kleine Datenbanken" bezeichnen, und trotzdem funktioniert es super.
Klar kann sowas funktionieren, aber a) ist mir die Kombination Oracle+Linux - zumindest im Moment - noch nicht so ganz geheuer, da man schon sehr genau darauf achten muß, welche Oracle-Version man auf welcher Distribution mit welcher GCC und welcher glibc-Version installiert, und b) denke ich, daß unserer Billing-System im Terabyte-Bereich mit mehr als 2000 Concurrent Users auf einem HP-UX-Cluster oder AIX-Cluster einfach besser aufgehoben ist. ;-)
Was ist für dich Hardware, die vom Server nicht unbedingt unterstützt werden muß? Das hängt sicher auch vom Server ab.
Eben, Du sagst es. Um so schöner wäre es doch, wenn man leicht Treiber entfernen oder hinzufügen könnte, ohne gleich den Kernel anfassen zu müssen, oder nicht !?
siehe die allseits bekannte Diskussion Microkernel gegen monolithische Kerne
Das Micro-Kernel-Konzept geht aber weit darüber hinaus, Gerätetreiber außerhalb des Kernel abzulegen (wo sie IMHO ohnehin nicht hingehören).
Mir ist es aber lieber, alles im Kernel drin zu haben und ungewünschte Sachen zu entfernen, als für jedes blöde Gerät erstmal im Internet zu suchen, ob es Treiber dafür vom Hersteller gibt
Das eine hat doch nichts mit dem anderen zu tun. Die Treiber können nach wie vor mit Kernel runtergeladen/installiert werden, nur eben nicht mehr als Teil des Kernel, sondern als eigene Dateien. Solange Du nicht einen Treiber hinzufügen oder löschen willst, wirst Du keinen Unterschied bemerken.
Und wenn man einen Kernel selbst zusammen stellt (was sowieso kein DAU machen wird / machen sollte), und man dann einen Parameter vergißt ...
... oder wie wär's mit dem Klassiker, das File-System der Boot-Partition als Modul zu laden.
Genau aus diesem Grund finde ich das derzeitige Konzept nicht so prickelnd. Der Kernel sollte für mich etwas sein, das ich als Anwender und auch als Admin eigentlich nie anpacken muß.
Wo ist denn da das Problem? Es gibt InitRds.
Wechsel doch mal unter Windows den Festplatten-Controller-Chipsatz aus. Schon kommt es beim Booten zu nem UNMOUNTABLE_BOOT_VOLUME Bluescreen.
Wie fast jede Software wird der Kernel inkrementell entwickelt, und das ist gut so. Patching und Refactoring ist einfacher, schneller und besser nachvollziehbar als Rewriting, behebt Bugs und Designfehler ohne dafür noch mehr neue einzuführen oder Features und Charakteristika zu verlieren (die sich im Lauf der Zeit an den Bedarf der User und Anwendungen angepaßt haben, und an die sich die User und Anwendungen angepaßt haben). Zwischen 2.4 und 2.6 gab es einige große, lang dauernde Refactorings, aber ein System auf 2.6 umzustellen ist erstaunlich problemlos.
Auch ein Grund die Grundausstattung an Treibern im Kernel-Source zu belassen: sie werden bei Refactoring und Weiterentwicklung mit erfaßt. Manchmal lese ich auf der LKML Sätze wie "Funktion x wird in 129 Stellen verwendet... unser Patch y ändert das wie folgt... das Ergebnis ist 470% schneller und hat Problem z nicht mehr..."
Mit anderen Worten: die Treiber-Grundausstattung ist auch deshalb Teil des Kernels weil sich dessen Entwicklung so am Bedarf der Treiber orientieren kann, und die Treiber bei der Gelegenheit gleich mit angepaßt werden. So ähnlich wie ein Hersteller Soft- und Hardware optimal einander anpassen kann wenn er die Kontrolle über beides hat. So etwas wie eine schlechte oder veraltete Treiberschnittstelle entsteht gar nicht erst.
Das kartesische Produkt aus Bussen, Chips, Boards, Customizings etc führt zur Treiberexplosion? Gut, separieren wir Treiberschichten wie in NetBSD. Oh, die 100.000 binären Treiber die gegen die coole Treiber-Schnittstelle entwickelt wurden, deren Source nur die Hersteller haben und die sie niemals anpassen werden weil sie neue Produkte verkaufen wollen sind dabei im Weg ? Wenn die Sourcen nur Teil des Kernels wären...
Linux ist produktionsfähig weil es gut verstanden, bewährt und in den Grundzügen stabil ist, und sich jeden Tag besser an den Bedarf der User anpaßt. Und es ist vielerorts die "Weapon of Choice" weil es offen ist und so viel Auswahl bietet. Wer ein superinnovatives, experimentelles "Research OS" will das jedes Semester mit dem Paradigma de Jour neu geschrieben wird kann sich gern woanders bedienen.
Und da sind wir beim Thema "Freedom of Choice".
Anders als die meiste Software wird der Kernel praktisch von der ganzen Welt "gefüttert"; für jede Anwendung, sei es noch so speziell, kann sich unter vielen Lösungen eine "beste" herausbilden, und wo es keine "beste" gibt bleiben mehrere zur Auswahl.
Klar, jeder wünscht sich ein schlankes System, weil er denkt das ist dann performanter, übersichtlicher, wartbarer und stabiler. Aber es soll bitteschön alle Features und Treiber beinhalten die *er* braucht. Wehe das schlanke "MiniBSX" hat
- nur ein Dateisystem ("das Journalling ist so langsam.. aber ohne Journalling ist scheiße.. und ordered-writes sind für meine Anwendung langsam.. und es gibt kein Realtime -IO für Streaming.. aber das Realtime-IO ist so aufgebläht.. ohne Tail-Packing kann man keinen News-Server.. mit Tail-Packing wird mein System so langsam.. und für LVM brauch ich doch Online-Resize.. und für mich ist es zu CPU-lastig.. ohne Crypto und Kompression bin ich aufgeschmissen..") oder
- nur einen Prozeß-Scheduler ("ich hab 1.000.000 Prozesse, warum gibts kein O(1).. aber ich will eine Batch-Prio.. aber für meine Multi-Prozeß-DB ist der Scheduler langsam.. aber bei mir verhungern die niedrig priorisierten Prozesse..") und
- bestimmte Features nicht ("ohne inotify läuft mein Beagle nicht.. aber ohne QoS-Routing geht mein Server nicht richtig.. ich brauch aber RAID6 und AES192 einkompiliert für die Boot-Partition...")
Wißt Ihr was? Mit "make menuconfig" kann sich jeder seinen Kernel so schlank oder mächtig bauen wie er will, ohne Performance-Einbußen oder andere Kompromisse. Wer binäre Treiber nutzen will kann das tun. Wer die nicht will oder nicht kriegt ist froh daß die Grundausstattung so viel Auswahl bietet. Wer Treiber ohne Reboot einfügen oder austauschen will kann das tun, selbst wenn er sie erst kompilieren muß. Wer keine Module will weil er Angst vor Kernel-Rootkits hat kann Module abschalten. Wer will daß Kernel und Treiber über Registeraufrufe statt Stack kommunizieren kann das haben. Wer 400.000 Threads starten will ist froh daß man alles für 4k-Stacks kompilieren kann. Wer neue Treiber und/oder Features entwickelt ist froh daß sich der Kernel so gut zum Patchen eignet. Wer für seine Security-Policy ins VFS eingreifen muß ist froh daß er das kann.
All die vielen Patches, Architekturen, Virtualisierung und sonstigen Experimente führen zu Schnittstellen deren Flexibilität weit über das hinausgeht was sich ein einzelner Entwickler, Architekt oder Hersteller hätte ausdenken können.
Es gibt so viele verschiedene ideale Kernel wie es User gibt. Der Linux-Kernel kommt jedem davon so nahe wie sonst nichts. Deshalb hat Morton recht. Wer es besser weiß kann jederzeit auf der LKML posten.
Grüße von einem der froh ist daß Linux alles sein kann was er braucht,
Jogbaer
> des Kernels weil sich dessen Entwicklung so am Bedarf der Treiber orientieren
> kann, und die Treiber bei der Gelegenheit gleich mit angepaßt werden. ...
> So etwas wie eine schlechte oder veraltete Treiberschnittstelle entsteht gar
> nicht erst.
Du bist bestimmt Entwickler großer Softwaresysteme.
Gäbe es eine gute Schnittstelle zwischen Kernel und Treibern, wären ständige Anpassungen gar nicht nötig. Das es doch nötig ist, beweist das Gegenteil. Und auch wenn ein Patch mal schnell xxx Stellen auf einen Rutsch ändert, ist damit dennoch immer ein erhöhter Aufwand verbunden. Das ist verlorenen Zeit, macht Entwicklern und Hardwareherstellern das Leben schwer und kostet schlicht Geld. Andere Systeme machen das besser.
> Und da sind wir beim Thema "Freedom of Choice".
Weißt Du, warum die römische Armee so erfolgreich war?
> All die vielen Patches, Architekturen, Virtualisierung und
> sonstigen Experimente führen zu Schnittstellen deren Flexibilität weit
> über das hinausgeht was sich ein einzelner Entwickler, Architekt oder
> Hersteller hätte ausdenken können.
Du hast von Schnittstellen keinen blassen Schimmer. Kein Mensch will eine Hypermegasuperflexi-Schnittstelle, sondern eine stabile, einfach zu benutzende Schnittstelle. Was Du meinst, ist keine Schnittstelle, sondern ein chaotischer Haufen von vielen Schnittstellen. Am besten, Du rüstest Deine deine heimischen Steckdosen auf ein Dutzend verschiedene Typen um.
> Der Linux-Kernel kommt jedem davon so nahe wie sonst nichts.
Du träumst.
> daß Linux alles sein kann was er braucht,
Aber nichts richtig kann.
Also man sollte doch meinen, dass Distributoren Kernels bauen können - ansonsten kann man Linux gleich ins Eck treten. Da das nicht der Fall ist, behaupte ich mal, dass Distributoren Kernel bauen können! Und wird dieser modular gehalten, dann hast Du doch den ganzen "Treiberschlonz" evtl. dabei aber das Gedönse ist nicht aktiv, weil nicht geladen - ergo stabil.
Sehen wir es doch einfach so: Linux ist eine neue Art. Das Tier Linux hat sich von dem urspr. Unix "abgespalten" (stimmt so nicht - ich weiß - aber sehen wir es mal biolog. so) und die Evolution wird zeigen, ob Linux überlebensfähig ist oder nicht. Ich denke der Basar wirds schaffen, wird sich aber in einer ganz anderen Ecke wieder finden, als das viele gedacht haben.
Just my 2 plonks
Das chaotische Design hat einige Vorteile, die aus Software Engineering Gesichtspunkten der reinste Alptraum sind, und das ist hohe Kopplung - diese führt im positiven Sinne zu sehr hoher Performance, aber zugleich zur Unwartbarkeit.
Wäre der Linux-Kernel ein kommerzielles Produkt, wäre das Projekt längst gescheitert, da die Entwicklungskosten, die im Kernel stecken, extrem hoch liegen dürften durch die mangelhafte Architektur.
Es geht hier nicht um Mikro vs Monolith, letzterer hat seine Vorzüge, ABER die Architektur muss dazu sauber designed sein. Und gerade beim Speichermanagement leidet man noch heute überall an Fehlern, die vor über 10 Jahren gemacht wurden...
Ob Du es glaubst oder nicht, der derzeitige Code-Moloch des Linux-Kernels wird mittelfristig neu geschrieben werden müssen... Es kann natürlich auch sein, dass aus der kommenden Linux-Krise mehrere Kernel entstehen, die sich dann verschiedene Prämissen setzen (würde generell vermutlich einiges mehr retten und das Scheitern des Gesamtprojektes hinauszögern) - Du kannst das mit der BSD-Aufsplittung vergleichen (die bis heute andauert).
Ich weiß nicht genau, was du mit neu schreiben meinst, aber eine echter rewrite ist ja nicht dein Ernst. Die Stärke des chaotischen Linuxmodells war ja bisher immer, dass es inkrementelle mini-rewrites in subsystemen gab. Wenn du dir anschaust, wie lange das Mozilla-Projekt gebraucht hat, bis die Suite so richtig abgehoben hat, und wie grausam der Verlust an Marktanteilen in dieser Zeit zugeschlagen hat, weil es die ganze Zeit eben nur die grottige 4er-Suite gab, und dann noch im Hinterkopf hast, dass Mozilla zwar codemäßig ungefähr den selben Umfang hat wie ein aktueller Kernel, aber das eben in C++ und nicht in C und auch auf weniger Plattformen und mit weniger Hardwarenähe als der Kernel, dann sollte dir klar sein, dass es keinen "rewrite" geben wird.
Dass der Kernel architekturelle Defizite hat, ist sicher jedem schon mal aufgefallen, der sich mit dem Quelltext beschäftigt hat - aber das heißt ja nicht, dass man das ganze Ding wegwerfen muss. Warte doch erstmal ab, wie sich HAL entwickelt, ob es nicht vielleicht irgendwann ein moderneres internes Speichermanagement geben wird, ob die jetzige Tendenz zur Ausfaktorierung von Subsystemen nicht weiter anhält.
Und der Vergleich mit *BSD hinkt übrigens wirklich - da der Linuxkernel nicht weiß, mit welchem gcc er übersetzt wird, kann er auch schlecht Binärkompatibilität garantieren - bei BSD ist der Kernel und der Compiler ja Teil eines fixen Systems.
Ich glaube, die Attraktivität von Linux liegt in erster Linie am Pragmatismus der Entwickler - und wer das eben nicht Attraktiv findet, nun gut, der wird mit *BSD wahrscheinlich wirklich glücklicher sein. Irgendwie finde ich das gerade aber gar nicht schlimm. Selbst wenn es einen "Server-Kernel"-Fork gibt oder andersrum einen "Desktop-Kernel", würde ich eh vermuten dass dann die beteiligten Entwickler sehr schnell merken würden, wie viel sie dann doch gemeinsam haben.
Über das Design lässt sich sicherlich streiten; nur muss man halt verstehen, daß eben alles nicht am Reissbrett entwurfen wurde. Sondern die einzelnen Strukturen wurden eben einmal entwickelt, erweitert, teilweise über den Haufen geworfen und so weiter. Eben gewachsen. Aber so wächst eben jedes Betriebssystem, sei es der Windows-, der Solaris- oder eben der Linuxkernel. Jeder hat gewisse Altlasten an Bord, die man heute am liebsten beseitigen würde. ABER LEIDER IST DAS VIEL ZU AUFWÄNDIG! (oder stösst auf Widerstand bei den Verantwortlichen).
Und der Linuxkernel wird nicht neugeschrieben werden. Vielleicht werden sich ein paar Leute der Probleme, die du angesprochen hast (und von denen ich noch nie als Schwierigkeit in der Kernelentwicklung gehört habe), annehmen und eine Reihe von Patches abliefern, die diese Missstände beheben werden. Vielleicht oder vielleicht auch nicht. Ich glaube schon, daß der harte Kern der Entwickler so vorausschauend sind, daß sie das Problem "Speicherverwaltung" -- wenn es denn eins sein sollte -- entdecken und dran arbeiten werden.
Insgesamt gute Sache.
Neben dem Kernel wird auch der gute Linus immer fetter und dadurch immer ungeeigneter für den IT-Markt. Seine Gesundheit wird in Zukunft immer instabiler durch das Hinzufügen weiterer Ess- und Fressattacken. Existierende Diät- und Sportprogramme halte ich für ausreichend, stattdessen favorisiert Linus nur echtes Fast-Food im Magen.
Bei Diät- und Sportprogrammen handelt es sich um Ernährungsumstellungen, die den Körper optimal mit Nährstoffen versogen und gleichzeitig die Gesundheit fördern. Diese Technologie stammt aus der Ökotrophologie und wurde schon vor 2500 Jahren bei Griechen entwickelt.
Meine Kritik ist auch vor dem Hintergrund der zunehmenden Verfettung der Weltbevölkerung zu verstehen, die u.a. wachsenden Druck und Stress durch übermäßige Essensaufnahme ausgleicht.
Andrew Morton, Top-Sportler im Kernelprojekt, sieht die gegenwärtige Entwicklung von Linus entspannter. Zwar ist wahr, das sein Bauchumfang rasant voranschreitet. Allerdings gibt er zu bedenken, dass dieses Feature optional ist und einzelne Unternehmen noch immer genügend Raum in speziell zugeschnittener Bekleidung lassen. Dem beleibten Entwickler gewinnt Morton trotzdem eine positive Seite ab.
Dr. Best
PS: Lieber Linus, beweg Dich mal wieder mehr, dann haben wir alle länger was von Dir!
0,1185,OID4328452_TYP6_THE_NAV_REF1_BAB,00.html
Also muss sowohl Linus als auch Linux nach Detroit umziehen
Wenn man Bilder von ihm von vor zehn Jahren sieht mag das so vorkommen.
Allerdings ist das nur eine Täuschung.
Heutzutage wird er mit viel mehr Polygonen gerendert, was zum runderen Bauchumfang beiträgt.
Und dank Trueform kann man ihn (falls der ATI Treiber nicht vorher explodiert) in seiner vollen Pracht genießen.
Mfg
>vielfältigen Bemühungen, für den Desktop fit zu werden,
>immer fetter wird.
Das soll wohl indirekte Rede sein. Dann muss es aber "... immer fetter werde." heißen. Konjunktiv I.
Also wenn man es anders betrachtet sagt Sam Greenblatt ja nichts anderes als: wir wollen Linux nicht auf dem Desktop. Denn wer will schon auf seinem Desktoprechner auf Unterstützung seiner Multimedia Hardware verzichten. Und seine oberste Loyalität gilt dabei sicherlich nicht der positiven Entwicklung von Linux für den Desktop, sondern den Bilanzen seines Unternehmens.
Warum er gerne Xen noch ein wenig aufhalten möchte ist mir nicht ganz klar. Aber vielleicht hatte da sein Kumpel aus Redmond eine kleine Bitte. Denn Xen ist für M$ schon ziemlich bedrohlich. Da habe sie gerade mit Virtual PC eine Virtualisierungslösung angeschafft und die einigermassen in Windows integriert, da ist Linux schon wieder einen Schritt weiter mit einer überlegenen Technologie. Die müssen sich langsam vorkommen wie beim Hase und Igel.
Dabei übersehen alle das Linux zuallererst als Desktopsystem von Linus entwickelt wurde. Er wollte ein Unix für daheim!!!!! Nichts anderes!!
Linux kehrt also zu seinen Wurzeln zurück als Desktopsystem zurück. Und da 99% aller Computer weltweit als Desktopsystem eingesetzt werden, werden in den nächsten Jahren die Desktopfeatures im Kernel noch eher zunehmen.
Was versteht der Mann unter folgender Aussage : "Mit Sorge bemerkt man bei CA eine wachsende Instabilität des Linuxkernel durch das Hinzufügen weiterer Treiber für Spiel- und Musikanwendungen."
Wird ein laufendes System instabil? Die Kernel-API? Ein Treiber der nicht geladen ist kann doch ein System nicht instabil machen. Was soll also diese Aussage?
Wenn ich ein Serversystem verkaufe lass ich halt alles weg was nach Desktop riecht. SuSE benutzt für sein Serversystem (SUSE LINUX Enterprise Server 9) auch einen anderen Kernel wie für das Desktopsystem SuSE 9.3. Der Kernel für SLES wird von der Firma extra gewartet. Ich hab also eine stabile API, weil eine Kernelversion und Compiler und Bugfixes fliessen auch regelmäßig ein. Und SuSE hat sich, glaube ich, noch nie über den Linuxkernel beschwert.
Zudem kommt die Aussage von einem Vizepräsidenten von CA! Wenn jemand mal soweit oben ist, sitzt so jemand doch den ganzen Tag in Strategiesitzungen und programmiert keine einzige Zeile Code mehr. Wenn die Kritik von einem Programmierer von CA kommen würde, der auch noch aktiv an der Kernelentwicklung beteiligt ist, dann könnte man sich auf eine Diskussion einlassen. So ist das nur ein weiteres belangloses Kapitel in der Linuxentwicklung.