Web-Schecki schrieb:
"Kernel-Leute" sind doch zu großen Teilen Angestellte der Hardwarehersteller selbst. Und die müssen sich nunmal an die Vorgaben ihrer Vorgesetzten halten, die nach wirtschaftlichen Gesichtspunkten entscheiden.
Ähm das ist ja dann nur noch mehr ein Pro-Punkt für stabile Schnittstellen. Weil umso stabiler die sind, umso weniger muss man beim Treibercode pflegen.
Aber noch mal ein Schritt zurück bevor ich weiter (also auch auf den Rest Deines Postings) antworte. Also es kam irgendwie das Scanner-Beispiel rein was Du ja abgefeiert hast sozusagen als Beleg dafür, das das Linux-Modell mit dem Monolithen und sich ändernden Schnittstellen super funktioniert und langfristige Unterstützung ermöglicht.
Wie gesagt. Sowas wie Scannertreiber usw. liegen gar nicht im Kernel. Klar interagieren die auch mit dem Kernel. Aber das über externe Schnittstellen. Und die sind
Trommelwirbel STABIL.
Was auch gut ist und hilft das solche Treiber langfristig funktionieren. Denn gerade im Bereich von Consumer-Hardware hast Du auch gern mal den Fall, das Treiber nur einmalig gedropt werden und dann nie wieder neue Versionen erscheinen. Oder Du hast erst gar keine Treiber aber z.B. ein Open-Source-Entwickler der sich mal die Mühe gemacht hat einen Treiber zu schreiben aber dann irgendwann die Hardware nicht mehr hatte und dann auch kein Interesse mehr an der Pflege des Treibers hat. Der funktioniert aber häufig trotzdem noch dank gewisser Stabilität.
Womit wir gleich zum nächsten Punkt kommen über den offenbar viel Missverständnisse bestehen. Du sagst immer das es schön ist die Treiber gleich direkt im Linux-Kernel zu haben. Aber was denkst Du eigentlich, wie kommen die da rein? Ist ja nicht so das man eine Mail (mit dem Treiber als .tar.gz-Anhang) zu den Kernelentwicklern mit der Bitte um Aufnahme schickt und nach ein paar Wochen kriegt man dann ne Antwort, das man das integriert hätte und ab der nächsten Kernelversion ist das drin.
Aber so läuft das ja nicht. Die Aufnahme in den Linux-Kernel ist ein durchaus aufwendiger Prozess. Für große Firmen a-la Intel und Co ist das weniger ein Problem. Die haben halt genug Cash und Manpower um das einfach zu machen. Als kleine Firma oder gar Hobbyentwickler wirst Du Dir das also drei mal überlegen, ob Du das dann wirklich machst.
Man kann schon irgendwie davon sprechen das dies eine Eintrittsbarriere ist, die finanzstarke Leute bevorzugt. Kleine Entwickler werden da so ziemlich allein gelassen. Ironischerweise von einem Projekt welches selbst mal als Hobbyprojekt gestartet ist.
Es gibt aber noch andere Punkte. Da gehts auch so ein bisschen darum über den eigenen Tellerrand zu schauen (etwas, was Linuxern ja gerne Windowslern vorwerfen wenn die Linux ignorieren).
Es gibt nämlich noch andere freie Betriebssysteme. Und für die ist die Treibersituation meist noch deutlich schlechter als für Linux. Was machen die also? Die Integrieren in ihr Projekt Linux-Treiber (etwas, was man unter Linux ja auch schon gemacht hat; man denke nur mal an den ndiswrapper, wo Linux selbst Profiteur von stabilen Schnittstellen war).
Für die ist das natürlich ein Problem, wenn im Linux-Kernel ständig irgendwelche Schnittstellen geändert werden, weil die das dann immer nacharbeiten müssen.
Und eigentlich ist die Idee hinter Open-Source ja genau die: Man hat denn Quelltext und stellt den frei zur Verfügung, damit andere ihn benutzen und in ihr Projekt einbauen können. Durch volatile Schnittstellen erschwert man das. Jetzt sicher nicht mit Absicht, aber ein Kollateralschaden ist das auf jeden Fall.
Web-Schecki schrieb:
Aktuell werden sie auf der anderen Seite von den anderen Kernel-Entwicklern kontrolliert. Wenn sie versuchen, ihre Treiberarchitektur derart abzuändern, dass künftig nur noch bestimmte Generationen der Hardware unterstützt und alte Generationen links liegen gelassen werden, dann würden sie das wohl technisch gut begründen müssen, wenn der Patch nicht abgelehnt werden soll.
Die Kernelentwickler als Kontrollinstanz für die Treiberentwickler? Ok. Nehmen wir mal an, das ist ne gute Idee.
Es spricht ja (trotz stabiler API und trotz out-of-tree-Treiber) nichts dagegen das zu tun. Sozusagen als eine Art Qualitätsmerkmal. Die Kernelentwickler nehmen sich dem (wie jetzt auch auch) an und sagen: Für die und die Treiber, da übernehmen wir eine Kontrollfunktion.
Und den Rest überlässt man dann dem Anwender (von mir aus auch über den Umweg einer Distribution) die Wahl. Der kann dann halt sagen: "Ich will nur Treiber haben, die die Kernelentwickler auch abgenickt haben." Ein anderer sagt sich: "Och. Mir egal. Ich nehm' auch Treiber mit die nicht abgesegnet sind."
Dieses Wählen können, diese Freiheit .... das ist doch immer dieses Mantra was die ganzen Linux-Fanboys vor sich hertragen. Hier wäre mal ne 1A Gelegenheit Taten sprechen zu lassen.
Web-Schecki schrieb:
Es sind vielleicht nicht die technischen Argumente, die du wolltest
Naja. Es kamen halt nicht wirklich technische Argumente dafür. Und die Argumente die Du mir verkaufen wolltest für "instabile interne Kernel-APIs sind toll" belegen eher das Gegenteil.
Web-Schecki schrieb:
Praktisch hat sich die eigentlich unterlegene Lösung aber durchgesetzt
Wie ich bereits sagte: Lösungen haben ihre Zeit. Was heute noch hinreichend brauchbar ist, muss es morgen nicht mehr sein.
Das Minix-Beispiel zeigt das auch ziemlich gut. Als es mit Linux los ging war die Hardware im Vergleich zu heute relativ schwach (jeder billige Plaste-Router hat heute mehr Rechenpower/RAM als ein typischer Rechner mitten in den 90er Jahren). Unter diesen Bedingungen haben es monolithische Ansätze viel einfacher, weil da die "Dienstwege" kürzer sind und da man damals ohnehin stetig viel zu wenig Hardware-Ressourcen hatte wollte man da halt sparen (unter inkaufnahme von Nachteilen).
Gut. Bei Minix gabs jetzt auch noch ne Reihe anderer Faktoren. So war Minix lange Zeit gar nicht frei verfügbar. Zudem war es als akademisches System für die Lehre gedacht und nicht primär als Produktivsystem. Viele Optimierungen und Funktionen fehlen zugunsten der Anschaulichkeit.
Erst mit Version 3 wurde Minix so ganz langsam auch als Produktivsystem interessant, aber da war der Zug natürlich schon längst Richtung Linux abgefahren.
Für alternative Systeme ists dann halt auch schwer, weil bekannte Systeme viel Aufmerksamkeit und damit natürlich auch Ressourcen aufsich ziehen. Was einerseits gut ist, weil man den "viele ziehen an einem Strang"-Effekt hat, aber auch den Nachteil, das es Diversität killt.
