> Kann es sein, daß Du da was nicht verstanden hast?
Ganz falsche Einleitung, um sachlich miteinander zu diskutieren. Und ein ziemlich guter Indikator, dass da jemand mit mehr Idealismus als Sachwisssen schreibt.
> Falscher Punkt. Microsoft hat verschiedene Implementierungen von USB mitgeschleppt.
Du hast mich falsch verstanden. Es ist in vielen anderen Bereichen (z.B. bei den Hardware-Aspekten von USB, PCI und Co) möglich, Standards auch über längere Zeit beizubehalten, sie kompatibel(!) zu erweitern und auch ältere Komponenten mit neuen Revisionen des Standards zu benutzen.
Nur beim Linux-Kernel soll das rätselhafterweise nicht möglich sein.
Wenn Microsoft zwei ältere Versionen seines USB-APIs mitschleppt: hey, who cares? Das ist ein bisschen Mehraufwand, dafür freuen sich Anwender, Entwicklung und Third-Party-Hersteller.
> Weil es nicht um das können geht, sondern darum, ob es a) gewollt ist - und von den Kernel-Entwicklern ist es das eben nicht - und b) ob es sinnvoll ist. Und da sind die Kernel-Entwickler anderer Meinung als Du.
Und deswegen halte ich die Kernel-Entwickler in dem Punkt für Idioten. Nur weil das Idole der , sind die vor Fehlern nicht gefeit.
> > [...]Die fließen in seinen Treiber. Oder er gibt sie an die Kernel-Leute weiter, die sie in den nächsten Kernel einbauen. [...]
> Wo ist dann das Problem?
Hier installiere ich einen neuen Treiber, der ein Problem behebt, dort installiere ich einen neuen Kernel, der neben der Problembehebung noch ein Vielzahl an Änderungen, Bugfixes und neuen Features mitbringt. Wo gibt es wohl eher Probleme? Kaufst du dir ein neues Auto, wenn das alte dreckig ist?
> > Was ist aus Anwendersicht besser: wenn er bei Problemen mit einem Treiber einfach eine neuere Version des Treiber installiert
> Das ginge mit offenen Treibern problemlos. Einfach gegen den Kernel kompilieren - oder ein vorkompiliertes Paket nehmen. Es findet sich mit Sicherheit jemand, der das z.B. für die gängigen Distributionskernel (die Du ja nennst) täte. Wenn der Quellcode der Treiber offenliegt, dann kann man da auch gleich einzelne Treiber draus bauen, ist mir völlig wurst.
Du hast wirklich keine Ahnung, wovon du da sprichst, richtig? Ein bisschen Erfahrung mit externen Kernel-Modulen wie madwifi, OFED, mptlinux 4.x oder Lustre, und du würdest so einen Mist nicht erzählen.
> Ich halte es für eine egoistische Entscheidung, weil man seine Spezifikationen oder gleich die Treiber nicht offenlegen will, die Anwender an die kurze Kette zu legen, und sei es mit einer fixen API. Das sollte man mal aussprechen dürfen.
Das hat damit nichts zu tun. Wenn z.B. die Leute hinter USB ähnlich denken würden wie die Kernel-Entwickler, dann hätte USB 2 andere Stecker als Version 1 und ein leicht inkompatibles Protokoll, alles unter dem Vorwand, Altlasten nicht mitschleppen zu wollen. Die Hardware-Hersteller würde es freuen, die Kunden dürften die Zeche bezahlen. Mit USB 2.1 und 2.5 würde es dann wieder ein paar kleinere Änderungen geben, und wenn Microsoft dann einen eigenen Standard zu dem Thema präsentiert, könnten die Fanboys wieder schimpfen. Und würden einen großer Verschwörung wittern, weil die Kunden das begeistert annehmen.
Ganz falsche Einleitung, um sachlich miteinander zu diskutieren. Und ein ziemlich guter Indikator, dass da jemand mit mehr Idealismus als Sachwisssen schreibt.
> Falscher Punkt. Microsoft hat verschiedene Implementierungen von USB mitgeschleppt.
Du hast mich falsch verstanden. Es ist in vielen anderen Bereichen (z.B. bei den Hardware-Aspekten von USB, PCI und Co) möglich, Standards auch über längere Zeit beizubehalten, sie kompatibel(!) zu erweitern und auch ältere Komponenten mit neuen Revisionen des Standards zu benutzen.
Nur beim Linux-Kernel soll das rätselhafterweise nicht möglich sein.
Wenn Microsoft zwei ältere Versionen seines USB-APIs mitschleppt: hey, who cares? Das ist ein bisschen Mehraufwand, dafür freuen sich Anwender, Entwicklung und Third-Party-Hersteller.
> Weil es nicht um das können geht, sondern darum, ob es a) gewollt ist - und von den Kernel-Entwicklern ist es das eben nicht - und b) ob es sinnvoll ist. Und da sind die Kernel-Entwickler anderer Meinung als Du.
Und deswegen halte ich die Kernel-Entwickler in dem Punkt für Idioten. Nur weil das Idole der , sind die vor Fehlern nicht gefeit.
> > [...]Die fließen in seinen Treiber. Oder er gibt sie an die Kernel-Leute weiter, die sie in den nächsten Kernel einbauen. [...]
> Wo ist dann das Problem?
Hier installiere ich einen neuen Treiber, der ein Problem behebt, dort installiere ich einen neuen Kernel, der neben der Problembehebung noch ein Vielzahl an Änderungen, Bugfixes und neuen Features mitbringt. Wo gibt es wohl eher Probleme? Kaufst du dir ein neues Auto, wenn das alte dreckig ist?
> > Was ist aus Anwendersicht besser: wenn er bei Problemen mit einem Treiber einfach eine neuere Version des Treiber installiert
> Das ginge mit offenen Treibern problemlos. Einfach gegen den Kernel kompilieren - oder ein vorkompiliertes Paket nehmen. Es findet sich mit Sicherheit jemand, der das z.B. für die gängigen Distributionskernel (die Du ja nennst) täte. Wenn der Quellcode der Treiber offenliegt, dann kann man da auch gleich einzelne Treiber draus bauen, ist mir völlig wurst.
Du hast wirklich keine Ahnung, wovon du da sprichst, richtig? Ein bisschen Erfahrung mit externen Kernel-Modulen wie madwifi, OFED, mptlinux 4.x oder Lustre, und du würdest so einen Mist nicht erzählen.
> Ich halte es für eine egoistische Entscheidung, weil man seine Spezifikationen oder gleich die Treiber nicht offenlegen will, die Anwender an die kurze Kette zu legen, und sei es mit einer fixen API. Das sollte man mal aussprechen dürfen.
Das hat damit nichts zu tun. Wenn z.B. die Leute hinter USB ähnlich denken würden wie die Kernel-Entwickler, dann hätte USB 2 andere Stecker als Version 1 und ein leicht inkompatibles Protokoll, alles unter dem Vorwand, Altlasten nicht mitschleppen zu wollen. Die Hardware-Hersteller würde es freuen, die Kunden dürften die Zeche bezahlen. Mit USB 2.1 und 2.5 würde es dann wieder ein paar kleinere Änderungen geben, und wenn Microsoft dann einen eigenen Standard zu dem Thema präsentiert, könnten die Fanboys wieder schimpfen. Und würden einen großer Verschwörung wittern, weil die Kunden das begeistert annehmen.