Zeit wirds... Linux ist nicht mehr zu gebrauchen, seit sich die Entwickler dazu entschlossen haben keinen 2.7er Tree aufzumachen, sondern wie wild an 2.6 rumzuschrauben, und mit jedem Release alles moegliche kaputt zu machen.
ja, ja - du profi... was ist schon tolles daran, jahrelang auf treiber zu verzichten, die in einem wackeligen .7er-zweig geführt werden, der dann am ende notdürftig stabilisiert werden muss, was wieder jahre dauert (siehe 2.5er-zweig!)? das aktuelle entwicklungsmodell ist da wesentlich besser.
Irgendwie glaube ich nicht so richtig an Hurd, der Zug dürfte doch inzwischen abgefahren sein. Natürlich ist das Konzept des Mikrokernels überlegen, aber reicht das allein um die nötige Nachfrage in der Industrie zu wecken? Ist es nicht wahrscheinlicher (und schmerzfreier), dass sich der Linux-Kernel weiterhin Schritt für Schritt in Richtung Userspace orientiert?
Der Treiber kann einfach unabhängig entwickelt werden und ganz normal wie ein gewöhnliches Softwarepaket in die Distribution eingepielt werden.
Das geht im Prinzip auch unter Linux. Der Kernel kann dynamisch Treiber-Module laden. Das Problem ist, dass es unter Linux keine stabile Modul-Api gibt und deswegen die Module fuer jeden Kernel neu kompiliert werden muessen. Das ist aber kein technisches Problem, sondern eine bewusste Entscheidung der Kernel-Entwickler um properitaere binary-only Kernelmodule zu verhindern.
Von M wie Meikel am Di, 6. Februar 2007 um 10:59 #
> Das geht im Prinzip auch unter Linux. Der Kernel kann dynamisch Treiber-Module laden.
Dynamisch Treiber laden ist aber etwas anderes als ein Microkernel, wo die einzelnen Teile des Kernels voneinander getrennt sind.
> Das Problem ist, dass es unter Linux keine stabile Modul-Api gibt und deswegen die Module fuer jeden Kernel neu kompiliert werden muessen. Das ist aber kein technisches Problem, sondern eine bewusste Entscheidung der Kernel-Entwickler um properitaere binary-only Kernelmodule zu verhindern.
Nein, ich glaube, dass das der wirkliche Grund viel egoistischer ist. Für einen Kernel-Entwickler ist es einfach angenehmer, alles und jedes über den Haufen zu schmeißen und verändern zu können, wenn es ihm opportun scheint und keine Rücksicht auf Treiber- oder Applikationsentwickler nehmen zu müssen. Und bei Linux bestimmen nun mal die Kernel-Entwickler die Richtung, bei anderen Betriebssystemen werden solche Entscheidungen mit Blick auf das gesamte System getroffen und nicht nur von den Leuten, die den Kernel entwickeln.
Nein, ich glaube, dass das der wirkliche Grund viel egoistischer ist.
Praktischer. Nicht egoistischer.
Für einen Kernel-Entwickler ist es einfach angenehmer, alles und jedes über den Haufen zu schmeißen und verändern zu können, wenn es ihm opportun scheint und keine Rücksicht auf Treiber- oder Applikationsentwickler nehmen zu müssen
So ist es. Ansonsten schleift man halt, wie z.B. bei Windows, 4 oder 5 USB-Schnittstellen-Implementierungen mit durch, weil man von den alten natürlich nicht lassen kann. Das gibt irgendwann übles Chaos.
Nebenbei bemerkt, die Kernelentwickler pflegen in den Kernel aufgenommene Treiber auch weiter. Also nix mit, "der Treiber-Entwickler sitzt dann da".
Ausnahme sind natürlich binäre, proprietäre Treiber. Deren Hersteller haben gelitten. Da gibt es drei Alternativen: 1. Sourcen freigeben und in den Kernel einbauen lassen 2. Zähne zusammenbeißen 3. Support einstellen
Für die Kernel-Jungs ist es eben so am schmerzärmsten und entspricht auch ihrer Philosophie. Und wenn man binäre Treiber im Kernel hat, kann man eine vernünftige Fehlersuche auch gleich abhaken.
Du siehst, es hat andere Gründe als den "Egoismus" der Kernelentwickler. Wobei da auch die Frage erlaubt sein sollte, warum die Kernelentwickler den Herstellern binärer Treiber Arbeit abnehmen sollten. Letztere verdienen damit idR auch Geld, dann können sie dafür auch arbeiten. Oder die Sourcen freigeben, dann haben sie die Arbeit nicht mehr.
Von M wie Meikel am Di, 6. Februar 2007 um 13:18 #
> > Nein, ich glaube, dass das der wirkliche Grund viel egoistischer ist.
> Praktischer. Nicht egoistischer.
Praktischer für die Kernel-Maintainer. Für den Rest der Welt: nein. Insofern ist es voll und ganz gerechtfertigt, das egoistisch zu nennen. Ich bin gespannt, was du für Gegenbeispiele bringen kannst, warum dieses Entwicklungsmodell auch für den Rest der Welt Vorteile haben soll.
> Ansonsten schleift man halt, wie z.B. bei Windows, 4 oder 5 USB-Schnittstellen-Implementierungen mit durch, weil man von den alten natürlich nicht lassen kann. Das gibt irgendwann übles Chaos.
Chaos gibt es bei Linux doch auch schon genug, Ob es wirklich die bessere Idee ist, alle paar Monate Details der Schnittstellen zu ändern, damit Gott und die Welt hinterherdackeln darf, wage ich zu bezweifeln.
Saubere, dokumentierte, stabile Schnittstellen sind überall sinnvoll. Warum gäbe es sonst DIN oder ISO? Was wäre das W3C wert, wenn Microsoft (IE), Operal oder Mozilla/Netscape alle paar Monate die Funktionalität ihrer Browser ändern würden? Saubere Schnittstellen sind nur für eine Gruppe lästig: die Entwickler, denn für sie bedeutet das Mehrarbeit in mehrfacher Hinsicht.
> Nebenbei bemerkt, die Kernelentwickler pflegen in den Kernel aufgenommene Treiber auch weiter. Also nix mit, "der Treiber-Entwickler sitzt dann da".
Das ist künstlich generierte Arbeit, die eigentlich überflüssig ist. Die man allerdings bei Linux prima dazu nutzen kann, den Nachwuchs bei Laune zu halten.
> Und wenn man binäre Treiber im Kernel hat, kann man eine vernünftige Fehlersuche auch gleich abhaken.
Das wird durch ständiges Wiederholen auch nicht wahrer. Andere Betriebssysteme bekommen das auch hin, Linux hat sich da selber reingeritten.
Kleine Ironie am Rande: Fault injection kennen andere Betriebssysteme schon lange, ebenso automatisierte Tests. Da ist bei Linux noch vieles im Argen.
Praktischer für die Kernel-Maintainer. Für den Rest der Welt: nein. Insofern ist es voll und ganz gerechtfertigt, das egoistisch zu nennen.
Nein. Die Kernel-Entwickler machen die Arbeit; natürlich entscheiden sie dann auch, was sie tun und was sie lassen. Arbeite mit, dann kannst Du den Kurs mitbestimmen. Nutznießen, ohne dafür was zu leisten, aber Forderungen stellen, ist frech.
Ich bin gespannt, was du für Gegenbeispiele bringen kannst, warum dieses Entwicklungsmodell auch für den Rest der Welt Vorteile haben soll.
Das nenn ich mal ein zugkräftiges Argument. Schon klar.
Ob es wirklich die bessere Idee ist, alle paar Monate Details der Schnittstellen zu ändern, damit Gott und die Welt hinterherdackeln darf, wage ich zu bezweifeln.
Wenn Du nicht liest und parst, was ich schreibe, werde ich mir die Mühe fürderhin schenken. Gott und die Welt muß nicht hinterherdackeln, sondern nur einmal die Treiber in den Kernel einbringen, dann hat sich das Problem gelöst. Wer das nicht möchte, ist eben allein auf hoher See.
Saubere, dokumentierte, stabile Schnittstellen sind überall sinnvoll.
Lies das verdammte Paper von Greg Kroah-Hartmann. Davor hat es keinen Sinn, zu diskutieren.
Warum gäbe es sonst DIN oder ISO?
Du würfelst Normen und deren versuchte Umsetzung durcheinander.
Saubere Schnittstellen sind nur für eine Gruppe lästig: die Entwickler, denn für sie bedeutet das Mehrarbeit in mehrfacher Hinsicht.
Nochmal: Lies das verdammte Paper.
Das ist künstlich generierte Arbeit, die eigentlich überflüssig ist.
Schon klar. Lieber lassen wir fehlerhafte Schnittstellen so, wie sie sind, damit uralte Binärtreiber weiter funktionieren; wir propfen dann einfach die nächste Stufe dazu, wenn es eine Erweiterung gibt usw.; und versuchen dann irgendwann, den ganzen Mist einigermaßen im Überblick zu halten. Was war noch gleich Dein Punkt?
Die man allerdings bei Linux prima dazu nutzen kann, den Nachwuchs bei Laune zu halten.
Deine polemische Argumentationsweise hängt mir zum Halse raus; ich werde Dich nach diesem Posting hinfort ignorieren.
Das wird durch ständiges Wiederholen auch nicht wahrer.
Dann zeig mir mal, wie man einen Fehler sucht, wenn man einen Teil des Codes nicht einsehen kann bzw. darf.
Andere Betriebssysteme bekommen das auch hin
Sie tun's einfach. Niemand behauptet, daß das super oder gar fehlerfrei klappen würde.
Linux hat sich da selber reingeritten.
Jetzt hast Du's mir aber gegeben.
Eine weitere Diskussion mit Dir werde ich mir schenken; Du polemisierst, gehst auf meine Argumente nicht ein - dafür ist mir meine Zeit zu schade.
Von M wie Meikel am Di, 6. Februar 2007 um 19:39 #
> Nein. Die Kernel-Entwickler machen die Arbeit; natürlich entscheiden sie dann auch, was sie tun und was sie lassen. Arbeite mit, dann kannst Du den Kurs mitbestimmen. Nutznießen, ohne dafür was zu leisten, aber Forderungen stellen, ist frech.
So ein Quatsch. Ich muß nicht erst selber ein Auto bauen, um beurteilen zu können, ob ein Auto eine gute Straßenlage hat oder wenig verbraucht. Aber das Totschlagargument ist ja unter Linux-Aposteln recht beliebt, um jedweder Kritik zu begegnen. Merkt ihr eigentlich nicht, wie lächerlich das ist?
> Lies das verdammte Paper von Greg Kroah-Hartmann. Davor hat es keinen Sinn, zu diskutieren.
Das habe ich schon längst gelesen. Und das Pamphlet ist in meinen Augen ziemlicher Unfug. Hätten wir gerne etwas näher drauf eingehen wollen, aber wenn du die Diskussion sofort wieder abwürgst...
> Lieber lassen wir fehlerhafte Schnittstellen so, wie sie sind, damit uralte Binärtreiber weiter funktionieren; wir propfen dann einfach die nächste Stufe dazu, wenn es eine Erweiterung gibt usw.; und versuchen dann irgendwann, den ganzen Mist einigermaßen im Überblick zu halten.
Das ständige Frickeln ist ja wohl eher der Fall bei Linux, oder willst du ernsthaft behaupten, dass in der kurzen Zeit zwischen zwei Releases größere Umstellungsarbeiten gemacht werden können?
Lieber von Zeit zu Zeit einen sauberen Schnitt machen und etwas vernünftig renovieren, als ständig ein bisschen dran herumzupfuschen. Aber das würde ja ein Minimum an Planung erfordern und da tun sich die Kernel-Götter ja leider ziemlich schwer mit...
Apropos alte Zöpfe und Doppelentwicklungen: da gibt reichlich von im Linux-Kernel. Warum mit ALSA und OSS zwei Sound-Architekturen? Warum fünfzig Dateisysteme, von denen gerade mal eine Handvoll halbwegs populär ist und die sich gerade mal in Details unterscheiden? Bei Virtualisierungslösungen scheint man da ja langsam was gelernt zu haben, da ist man erst bei zwei...
> Dann zeig mir mal, wie man einen Fehler sucht, wenn man einen Teil des Codes nicht einsehen kann bzw. darf.
Klingt so, als hättest du überhaupt keine Ahnung von Softwareentwicklung. Als ob im Code eingestreute printf's die einzige Methode zum Debuggen wären. Da ist der Rest der Welt schon ein bisschen weiter.
> Eine weitere Diskussion mit Dir werde ich mir schenken; Du polemisierst, gehst auf meine Argumente nicht ein - dafür ist mir meine Zeit zu schade.
Ach, du willst doch gar nicht diskutieren. Aber wenn du dennoch antworten willst, kannst du das ja unter einem anderen Namen machen. Merkt hier ja eh niemand.
Warum mit ALSA und OSS zwei Sound-Architekturen? Es gibt doch nur eine: ALSA. OSS ist seit langem als *deprecated* ausgezeichnet.
Warum fünfzig Dateisysteme, von denen gerade mal eine Handvoll halbwegs populär ist und die sich gerade mal in Details unterscheiden? So viele gibt es gar nicht und die meisten müssen unterstützt werden. ISO9660, UDF, CIFS, VFAT, NTFS sind schon allein wegen des marktbeherrschenden Betriebssystems quasi Pflicht.
Bei Virtualisierungslösungen scheint man da ja langsam was gelernt zu haben, da ist man erst bei zwei... Welches ist denn das Zweite?
Als ob im Code eingestreute printf's die einzige Methode zum Debuggen wären. Wie debuggst du denn Software ohne Zugriff auf den Quellcode?
Von M wie Meikel am Mi, 7. Februar 2007 um 20:06 #
> > Warum mit ALSA und OSS zwei Sound-Architekturen? > Es gibt doch nur eine: ALSA. OSS ist seit langem als *deprecated* ausgezeichnet.
Und es ist immer noch drin. Auf der einen Seite wird dauernd geändert, das wenigstens halbwegs stabil sein sollte, auf der anderen Seite werden uralte Zöpfe weder abgeschnitten noch emuliert.
> > Warum fünfzig Dateisysteme, von denen gerade mal eine Handvoll halbwegs populär ist und die sich gerade mal in Details unterscheiden? > So viele gibt es gar nicht und die meisten müssen unterstützt werden. ISO9660, UDF, CIFS, VFAT, NTFS sind schon allein wegen des marktbeherrschenden Betriebssystems quasi Pflicht.
Auf dem System hier enthält /lib/modules/2.6.15-27-386/kernel/fs 50 Unterverzeichnisse. Dass viele wie NTFS oder UFS gerade mal zum Datenaustausch taugen und nicht als primäres Dateisystem, dürfte so manchem auch nicht klar sein. Wenn sogar IBM bei uns ext3 anstelle von JFS empfiehlt, dann frage ich mich doch, wieviele von den 50 Dateisystemen Leichen sind, die man ruhig mal entsorgen könnte.
> > Bei Virtualisierungslösungen scheint man da ja langsam was gelernt zu haben, da ist man erst bei zwei... > Welches ist denn das Zweite?
http://www.pro-linux.de/news/2007/10801.html
Neben KVM versucht man sich ja wenigstens, auf eine Schnittstelle für Virtualisierungslösungen zu einigen, da scheint man aus der Vergangenheit gelernt zu haben. Und irgendwie kehren damit ja auch stabile Schnittstellen in den Kernel ein, zumindestens an einer Baustelle.
> > Als ob im Code eingestreute printf's die einzige Methode zum Debuggen wären. > Wie debuggst du denn Software ohne Zugriff auf den Quellcode?
Mit Symbolen, mit Kerneldebuggern oder Crashdumps, mit Hooks oder Probes, da gibt es reichlich Möglichkeiten. Das klingt schon manchmal sehr amüsant, wie manche Leute das abtun, weil sie glauben, jenseits der Sourcen könne man nicht vernünftig debuggen.
Nebenbei bemerkt, die Kernelentwickler pflegen in den Kernel aufgenommene Treiber auch weiter. Also nix mit, "der Treiber-Entwickler sitzt dann da". Doch.
Ausnahme sind natürlich binäre, proprietäre Treiber. Es gibt genug freie Treiber, die nie in den offiziellen Kernel-Tree aufgenommen werden.
GNU/HURD wird wohl nie den Status eines Vollwärtigen OS erreichen (obwohl es ja läuft), zumindest nicht mit MACH. L4 ist als Kernel im Gespräch, aber es steht noch nichts fest
(mit der Gefahr, daß ich einem Troll antworte) Sehe ich nicht so. Schließlich hat sich an der grundlegenden Art der Kernelentwicklung nichts geändert. Lediglich der Releasezyklus hat sich zu gunsten der Treiberentwicklung geändert. Mit dem neuen System kann man besser neuen Code priorisieren.
Wenn man sich natürlich wieder auf die neusten Features stürzt, kann man schlecht erwarten, daß alles perfekt funktioniert.
Bis auf den einen Bug im 2.6.19 Kernel, war in letzter Zeit nichts von grundlegenden Problemen zu hören. Aber Du kannst nach wie vor einen Kernel der 2.4 Reihe verwenden, welche nach wie vor noch gewartet wird.
Ansonsten nenne einfach einmal ein Beispiel, wo Dein Problem zu finden ist.
Wem der aktuelle Kernel nicht zusagt, kann ja auch beim 2.6.16.39er bleiben. Ich hatte aber noch nie Probleme mit dem aktuellen, wieso sollte ich da nicht den aktuellsten verwenden
Von Anonymer Feigling am Di, 6. Februar 2007 um 10:46 #
Schaut euch doch mal ernsthaft den Linux Kernel an! Im neuesten Machwerk gibts jetzt ganze 2 Virtualisierungslösungen. Ist ja toll, aber wozu braucht man zwei, wenns doch auch eine tut? Vor ein paar Jahren wurde mal auf der LKML diskutiert (die hatte ich mal abonniert mit 500+ Mails am Tag...), dass der 2.6er Kernel ganze 18 hex2string-Funktionen drin hat, die alle das gleiche machen, nämlich eine Hexzahl in einen String zu konvertieren. Hier hättens auch 3 getan (manche auf Schnelligkeit optmiert, andere auf Speicher...). Doch hat sich jemand seitdem drum gekümmert? Nö. Gleiches gilt für den serial-bus layer. Da wurde seit 10 Jahren nix mehr dran gemacht. Der müsste dringenst neu programmiert werden, man denke nur an USB, das darauf aufsetzt.
Kurzum. Die Linux-Gemeinde (und da ist der Kernel nun mal keine Ausnahme) wird zunehmend zu einer Frickel-Werkstatt. Anstatt eine Sache mal richtig zu ende zu programmieren, werden mehrere Sachen halbwertig "implementiert". Da leistet das BSD-Team wirklich bessere Arbeit.
Ein 2.7er Kernel muss wirklich her! Denn seit Jahren wurde am Unterbau vom Kernel kaum etwas verändert. Viele grundlegende Teile sind total veraltert.
Ich weiß wovon ich rede, ich muss beruflich am Linux Kernel portieren.
BSD ist besser und stabiler. Nur stört mich ein Mischmasch aus Debian und FreeBSD. Wäre es da nicht sinnvoller, wenn Debian die vorhandenen Packages für FreeBSD fertig anbieten würde. Von mir aus auch gerne mit apt. Als FreeBSD-User muß man sich dann halt entscheiden, ob man lieber die Ports nimmt oder die Debian Packages. Das fände ich dann eine Superlösung. Zwei ziemlich perfekte Welten vereinigen sich: Das OS FreeBSD und die Package-Verwaltung für Debian.(Weihnachten und Ostern fielen zusammen oder so ähnlich )
Da ich allerdings Verfechter der Ports bin (noch nie hat selber kompilieren soviel Spaß gemacht) finde ich es mehr als eklig, wenn Debian mit diesem Stable/Testing/SID apt-Schmarrn ein BSD verhunzt.
Wahre Worte. Die Kernel-Entwickler haben eine Grube gehoben, aus der sie nicht mehr rauskommen. Wie Eingangs schon jemand geschrieben hat, kann der Nutzer natürlich nicht mehr Jahre darauf warten, bis ein neuer Kernel mit neuen Treibern erscheint. Die jetzige Praxis erlaubt dagegen keine größeren Änderungen. Man schaue sich nur den Netzwerk-Layer an, der fast allen Systemen an Funktionalität hinterherhinkt. Hier aber etwas zu ändern würde Anpassungen an duzenden weiteren Treibern bedeuten, was natürlich keiner zwischen zwei Releases schaffen kann. So wird drumherum gewerkelt und gestückelt. Hinzu kommt noch die Sturheit und die Angst der Hacker vor stabilen Schnittstellen. Dass sie damit nicht nur proprätere Treiber ausschließen, sondern auch dem Nutzer gleich die Gelegenheit nehmen einfach neue Hardware zu installieren juckt sie nicht. Man hat ja schließlich einen gemeinsamen Feind und den gilt es mit allen Mitteln zu bekämpfen.
Der Linux kernel ist Bloatware und kaum zu warten. FreeBSD wird von der Industrie ungern gesehen, weil es nicht unter GPL steht. Also bleibt nur GNU/HURD übrig, daß technisch aber so ansruchsvoll ist, daß sich nur wenige Entwickler da ran trauen. Aber aus Benutzersicht wäre GNU/HURD ein Traum OS für alle.
Ein Endanwender müßte nie wieder einen Kernel kompilieren nur um eine bestimmte Hardware seines Rechners zum laufen zu bringen. Einfach Treiber downloaden, einbinden und fertig und schon läuf die Hardware. So würde es bei GNU/Hurd aussehen.
>FreeBSD wird von der Industrie ungern gesehen, weil es nicht unter GPL steht.
What? Was soll das denn? Gerade weil es nicht unter der GPL steht würde ich sagen, dass es gerne gesehen wird! Wer, der Geld machen will, will schon die GPL am Hals?
> What? Was soll das denn? Gerade weil es nicht unter der GPL steht würde ich sagen, dass es gerne gesehen wird! Wer, der Geld machen will, will schon die GPL am Hals?
Von Firmen wird die BSD Lizenz nur dann gerne gesehen, wenn sie planen daraus ihr eigenes geschlossenes System zu machen.
Ist der Plan aber eine gemeinsamme Entwicklung unter vielen verschiedenen Firmen, dann bevorzugen alle die GPL, da keiner will, daß einer ihnen den Braten wegnimmt.
Der Linux kernel ist Bloatware und kaum zu warten. FreeBSD wird von der Industrie ungern gesehen, weil es nicht unter GPL steht. Also bleibt nur GNU/HURD übrig, daß technisch aber so ansruchsvoll ist, daß sich nur wenige Entwickler da ran trauen. Aber aus Benutzersicht wäre GNU/HURD ein Traum OS für alle.
Linux stoesst auf breite Akzeptanz weil es sehr viel verschiedene Hardware unterstuetzt. Die ganzen Treiber machen wahrscheinlich 90% oder mehr der Linux-Kernel-Sourcen aus und die ganzen Treiber sind es, die wirklich Arbeit machen. Ich hab mir vor ein paar Jahren mal GNU/HURD installiert. Das war damals schon durchaus benutzbar. Aber was nuetzt mir ein supertolles Betriebssystem, dass meine Hardware nicht unterstuetzt?
Ein Endanwender müßte nie wieder einen Kernel kompilieren nur um eine bestimmte Hardware seines Rechners zum laufen zu bringen. Einfach Treiber downloaden, einbinden und fertig und schon läuf die Hardware. So würde es bei GNU/Hurd aussehen.
Wie schon oben erwaehnt, dass waere auch unter Linux eigentlich nicht noetig. Kernel-Modul laden und fertig. Ob das jetzt im Userspace oder Kernelspace laeuft, ist letztlich irrelevant. Wenn man einen Microkernel ohne stabile Kernel-API hat, muss man die Module auch jedesmal neukompilieren, wenn man den Kernel updated.
Von M wie Meikel am Di, 6. Februar 2007 um 13:08 #
> Der Linux kernel ist Bloatware und kaum zu warten.
Naja, Bloat wirst du in jedem Betriebssystem finden, das mehr als ein Minimum an Features hat. Aber ich gebe dir insofern Recht, dass die Linux-Entwicklung viel zu unstrukturiert und chaotisch ist.
> FreeBSD wird von der Industrie ungern gesehen, weil es nicht unter GPL steht.
Nö, ich glaube, dass die Lizenz den meisten Firmen relativ egal ist. Kritisch ist da noch am ehesten die GPL wegen ihre "viralen" Eigenschaften. FreeBSD hat in der Industrie wohl eher das Problem, dass es nicht die Popularität wie Linux hat und dass Firmen wie Redhat oder Novell fehlen.
> dem Nutzer gleich die Gelegenheit nehmen einfach neue Hardware zu installieren Das kann man auch anders herum sehen: Der proprietäre Hersteller nutzt die rechtliche Grauzone und die freie und kostenlose Vorleistung Anderer, anstatt sich den Gepflogenheiten anzupassen und einen freien Treiber zu entwickeln bzw. entwickeln zu lassen.
Bist Du in Paris, verhalte Dich wie ein Pariser und willst Du Deine Hardware auf einem freien Betriebssystem funktionieren sehen, ermögliche einen freien Treiber. Aber man ist es ja in Deutschland gewohnt, sich aufdrücken zu lassen, was man bitteschön wie zu benutzen hat, wenn man schon noch so frech war, Hardware für's Geld zu verlangen.
Verzeihe mir, aber mit der Polemik kann ich nichts anfangen. Keiner redet hier über proprietäre Hersteller, oder gar die Sitten und Gepflogenheiten der Deutschen. Es geht einzig und alleine um fehlende Schnittstellen.
Wieso kommt gleich jeder mit dem Argument, dass proprietäre Hersteller eine Grauzone nutzen? Und was hat es freien Autoren, oder Firmen, die ihre Software unter der GPL ausliefern, zu tun? Intel, Broadcom, Marvell, D-Link, Linksys sind nur die wenigen im Netzerksegment. Alle diese Treiber liegen unter der GPL vor, müssen aber Monate auf eine Aufnahme in den Kernel warten. Bis sie von den Distributoren ausgeliefert werden, vergehen oftmals Jahre. Und das nur weil die Hacker Angst von Nvidia und ATI haben?
Aus purem Hass auf eine Handvoll Hersteller verbauen die Hacker absichtlich jegliche Aussicht auf stabile APIs und eine einfache Einbindung von neuer Hardware. Jede wichtigere Applikation schafft es stabille APIs zu haben und ermöglicht die Funktionalität durch Plug-Ins zu erweitern. Jedes brauchbare Betriebssystem schafft es. Warum also nicht der Linux-Kernel?
Aus purem Hass auf eine Handvoll Hersteller verbauen die Hacker absichtlich jegliche Aussicht auf stabile APIs und eine einfache Einbindung von neuer Hardware
Weiter oben hast Du Dir noch Polemik verbeten. Das da IST pure Polemik. Greg Kroah-Hartmann hat in einem Paper geschildert, warum die Kernel-Entwickler keine stabile, interne API im Kernel haben wollen. Lies es halt.
> Jede wichtigere Applikation schafft es stabille APIs zu haben und ermöglicht die Funktionalität durch Plug-Ins zu erweitern. Jedes brauchbare Betriebssystem schafft es. Warum also nicht der Linux-Kernel?
Das ist eben unerträglich. Warum machen die Firmen, welche die Kernentwickler bezahlen nicht klare Vorgaben und einigen sich? Ian Murdock ruft schon seit Jahr und Tag nach Stabilität.
> Verzeihe mir, aber mit der Polemik kann ich nichts anfangen Ich glaube Dein und mein Posting haben sich diesbezüglich nicht viel genommen.
> Es geht einzig und alleine um fehlende Schnittstellen Sie sind da, sie liegen innerhalb des Kernels und wenn es die freien Treiber geschafft haben, in den Vanilla-Tree zu kommen, können sie sie nutzen und werden bei Bedarf angepasst.
> Alle diese Treiber liegen unter der GPL vor, müssen aber Monate auf eine Aufnahme in den Kernel warten Werde bitte mal konkreter, denn das interessiert mich wirklich. Welcher Hersteller? Welche freien Treiber?
> verbauen die Hacker absichtlich jegliche Aussicht auf stabile APIs Eine stabile API ist nicht erwünscht, weil sie im von den Kernelentwicklern gewollten Modell (siehe oben) nicht nötig ist. Freie Treiber sollen (wo der Code einigermaßen sauber ist) in den Tree, alle anderen können nachbessern oder müssen eben (im Falle proprietärer Treiber) draußen bleiben. Das es im Alltag des Kernelgeschäftes auch mal Ungerechtigkeit (zB in puncto "sauberen Codes") geben kann bestreitet niemand.
>Das kann man auch anders herum sehen: Der proprietäre Hersteller nutzt die rechtliche Grauzone und die freie und kostenlose Vorleistung Anderer, anstatt sich den Gepflogenheiten anzupassen und einen freien Treiber zu entwickeln bzw. entwickeln zu lassen.
Lies doch bitte seinen Satz noch einmal.
Er bezog sich auf Open Source Treiber und davon sind die ebenfalls betroffen, siehe auch seine Worte zuvor:"Dass sie damit nicht nur proprätere Treiber ausschließen," Die Bedeutung von "nicht nur" sollte dir eigentlich bekannt sein:
Es ist nicht nur alles Weiß, sondern auch noch eiskalt. Das sind 2 verschiedene unabhängige Zustände.
Und fakt ist nunmal das unter Linux ohne Neucompilierung oder Update auf eine neue Kernelversion fast nichts geht wenn man hochmoderne Hardware einsetzen möchte von denen es Open Source Treiber gibt.
> Er bezog sich auf Open Source Treiber und davon sind die ebenfalls betroffen, Aber nicht in dem Maße, wie es proprietäre Treiber sind. Die Kernel-API ändert sich nicht von heute auf morgen aber dann und wann - und wenn sie es tut, sind die in den Linux-Quellen befindlichen Treiber schnell mitgeändert.
Das es eine erhebliche Schwelle für das eine oder andere freie Projekt geben kann, welches in den Tree aufgenommen werden will, bestreitet doch niemand und dass eine stabile Kernel-API hauptsächlich proprietären Treibern zugute käme, denn alle anderen haben (bei entsprechendem Design) die Möglichkeit, integriert zu werden, muss man ebenfalls mal zur Kenntnis nehmen.
Von Anonymer Feigling am Di, 6. Februar 2007 um 13:34 #
Nun das mit der stabilen Kernel-API ist so eine Sache. Die guten LK-Hacker ändern tatsächlich in atemberaubender Zeit irgendwelche Zugriffsparameter. Aber das sollte die großen Netzwerkhersteller nicht weiter stören. Zufällig arbeite ich für einem. Wir haben uns daher vor geraumer Zeit dazu entschieden, erstmal bei 2.6.13 zu bleiben und dafür zu entwickeln und dann später alles nochmal schnell an die neuste Version anzupassen und dann die Treiber (nach einer gewissen Anlaufszeit) unter GPL zu veröffentlichem. Um den Rest, da kümmert sich dann halt die OpenSource-Gemeinde. Die eigentlichen angestellten Programmierer warten das dann nur noch nebenbei und haben schon ganz wieder andere Aufgaben. Das nächste Ding werden auf jeden Fall "Mini-Linux-PCs" mit "Media Center" sein. Das einzige Problem ist da allerdings DRM und dieser ganze HD-Encryption-Mist.
Was GNU/Hurd angeht, so ist der Kernel aus einem einzigen Grund nicht erfolgreich: Es entwickelt ihn nur eine zwar recht gute, aber dafür sehr kleine, eingeschworene Gemeinschaft aus Elite-Hackern, die schlicht keine anderen "unfähigen" Hacker bei sich haben wollen.
Von M wie Meikel am Di, 6. Februar 2007 um 13:46 #
> Die Kernel-API ändert sich nicht von heute auf morgen aber dann und wann - und wenn sie es tut, sind die in den Linux-Quellen befindlichen Treiber schnell mitgeändert.
Doch, das tun sie. Wie vorhin schon angesprochen: der Treiber für ein Winmodem (ja, incl. Sourcen) war für 2.6.8 gedacht. Nach einigem Recherchieren hätte ich die nötigen Änderungen für 2.6.11 nachziehen können, blöderweise enthält Ubuntu 6.06 aber 2.6.15, und da waren dann doch einige heftige Änderungen nötig.
Der Dreh- und Angelpunkt ist es doch, Treiber als Teil des Kernels zu betrachten. Sobald man das nicht mehr tut (welche Betriebssystem außer Linux tut das?), hätten sich eine ganze Menge Probleme erledigt.
Das finde ich volkommen falsch! Den Nutzern bringen stabile Kernel-APIs den meisten Gewinn, da sie endlich mal Treiber installieren können ohne gleich einen kompletten Kernel installieren zu müssen. Ich brauche keinen neuen Kernel nur weil ich eine aktuelle TV, Sound oder Netzwerkkarte einbauen möchte. Aber was noch viel übler ist, die Kernelentwickler ändern auch regelmäßig die externen Schnittstellen (alles was im Userspace läuft) und erfordern so ein neues Release meiner Distribution. Das verlagert die Arbeit nur zu den Distributoren und Anwendern.
Von M wie Meikel am Mi, 7. Februar 2007 um 20:08 #
> Ich brauche keinen neuen Kernel nur weil ich eine aktuelle TV, Sound oder Netzwerkkarte einbauen möchte.
Ja. Aber dann müßten die Kernel-Entwickler für _dich_ und _mich_ Arbeit und Zeit investieren. Sie müßten - igitt! - deutlich mehr dokumentieren und testen. Und das sie dazu nicht gewillt sind, haben sie ja schon mehrfach dokumentiert.
wenn ich die Diskussionen hier so verfolge, scheint ja Linux vom Untergang bedroht zu sein. Und der Kernel ist totaler Mist. Oder habe ich das was falsch verstanden?
Komischerweise nutze ich beruflich und privat seit Jahren Linux und hatte mit dem Kernel praktisch noch keine Probleme - bis auf fehlende Treiber. Zum Beispiel für die beknackten "Winmodems". Aber da suche ich die Schuld definitiv nicht bei den Kernelentwicklern.
Es ist schön, in einer total MS-zentrierten und -dominierten Welt eine - gute - Alternative zu haben. Und ich bedanke mich bei allen, die es ermöglicht haben - und weiter ermöglichen werden.
Von Erlaubte HTML-Tags: am Di, 6. Februar 2007 um 12:54 #
> wenn ich die Diskussionen hier so verfolge, scheint ja Linux vom Untergang bedroht zu sein. > Und der Kernel ist totaler Mist. > Oder habe ich das was falsch verstanden?
Nein, nein, das hast du ganz richtig verstanden.
> Komischerweise nutze ich beruflich und privat seit Jahren Linux und hatte mit dem Kernel > praktisch noch keine Probleme - bis auf fehlende Treiber. Zum Beispiel für die beknackten > "Winmodems".
Das ist aber kein Argument! Das ist dir schon bewusst, oder?
> Es ist schön, in einer total MS-zentrierten und -dominierten Welt eine - gute - Alternative zu > haben. Und ich bedanke mich bei allen, die es ermöglicht haben - und weiter ermöglichen werden.
Von M wie Meikel am Di, 6. Februar 2007 um 13:28 #
> Komischerweise nutze ich beruflich und privat seit Jahren Linux und hatte mit dem Kernel praktisch noch keine Probleme - bis auf fehlende Treiber. Zum Beispiel für die beknackten "Winmodems".
Ich benutze Unix seit 20 Jahren (angefangen mit Sinix auf einer MX-2) und bin immer wieder erstaunt, wie betriebsblind die Linux-Anhänger bei vielen Dingen sind und dass sie reflexartig jede Kritik sofort als Angriff betrachten. Linux ist eine tolle Sache, aber weit davon entfernt perfekt zu sein. Solche Einschränkungen sind für manche Leuten aber scheinbar ein rotes Tuch. Blasphemie!
> Aber da suche ich die Schuld definitiv nicht bei den Kernelentwicklern.
Gäbe es stabile Schnittstellen im Kernel, hätte ich z.B. nicht längerem Experimentieren und Googlen herausfinden müssen, dass der Treiber für das Winmodem im neuen Laptop nur bis Kernel 2.6.8 läuft. Neuerer Kernel -> Treiber bei Conexant kaufen. Insofern sehe ich zumindestens eine Teilschuld bei den Kernel-Maintainern.
Wie wäre es mit einer Mitschuld der Notebookherstellers, weil er Dir ein "Winmodem" sprich D/A Chip als Modem angedreht hat? Warum wurde der Treiber nicht gewartet, wie es eigentlich sein sollte? Warum hat der Treiberhersteller nicht darauf hingewiesen?
Und nein eine stabile API/ABI schützt einem auch davor nicht. --> siehe Windows NT, 2000 bzw. XP Es gibt genügend Treiber von USB Geräten, Videokarten, etc.. welche nach dem Einspielen eines Servicepacks etc. plötzlich für immer den Dienst verweigerten.
Wie wäre es mit einer Mitschuld der Notebookherstellers, weil er Dir ein "Winmodem" sprich D/A Chip als Modem angedreht hat?
Wie wäre es mit einer Schuld des Herstellers? Was können die Kernel-Entwickler dafür? Nichts? Na also. Wenn der Hersteller ein verkrüppeltes Modem verkauft, ist er dran schuld.
Es gibt genügend Treiber von USB Geräten, Videokarten, etc.. welche nach dem Einspielen eines Servicepacks etc. plötzlich für immer den Dienst verweigerten. Dann hatte sich das ABI eben doch an irgendeiner Stelle geändert.
Von M wie Meikel am Di, 6. Februar 2007 um 19:46 #
> Wie wäre es mit einer Mitschuld der Notebookherstellers, weil er Dir ein "Winmodem" sprich D/A Chip als Modem angedreht hat?
Wie wäre es mit: Treiber für Linux existierten. Es ist die Schuld der Kernel-Götter, dass diese Treiber nicht mehr funktionieren.
> Warum wurde der Treiber nicht gewartet, wie es eigentlich sein sollte?
Warum muß ein Treiber gewartet werden? Was würdest du sagen, wenn ein Webmaster dir vorschreibt, einen Firefox aus dem CVS zu bauen, weil alle anderen Browser seine Seiten nicht korrekt anzeigen können? Den Firefox bauen oder dem Webmaster einen Vogel zeigen?
> Es gibt genügend Treiber von USB Geräten, Videokarten, etc.. welche nach dem Einspielen eines Servicepacks etc. plötzlich für immer den Dienst verweigerten.
Ich habe wenig mit Windows zu tun, aber damit bisher noch keine wirklichen Probleme gehabt. Im Gegensatz dazu kann ich eine Menge unschöner Erlebnisse erzählen, wo dieser Zoo von subtilen Abhängigkeiten das Leben unter Linux zur Hölle macht. Gerade die letzte Woche habe ich wieder mit Kernel backen verplempert, weil man ein aktualisierter Treiber für die Bootplatten unter Linux ein Staatsakt ist, was unter anderen Betriebssystemen in ein paar Minuten erledigt ist.
Wie wäre es mit: Treiber für Linux existierten. Es ist die Schuld der Kernel-Götter, dass diese Treiber nicht mehr funktionieren.
Wenn der Treiber nicht offizieller Bestandteil des Kernels ist, liegst Du leider falsch. --> der Treiberhersteller und nicht Dritte sind für das Funktionieren des Treibers verantwortlich. Die Änderungen an der API ist ein Recht, welches sich die Kernelentwickler vorbehalten haben. Du magst mit dieser Politik vielleicht nicht einverstanden sein, jedoch sind diese Änderungen nicht nur Fluch sondern auch Segen zugleich.
Warum muß ein Treiber gewartet werden? Warum muß Du das Öl in Deinem Auto wechseln? Sysadmin bist Du auf alle Fälle keiner, der würde eine solch kindliche Frage nicht stellen. --> Übrigens hinkt Dein nachfolgender Vergleich so derartig, daß es weh tut und ich das noch nicht einmal zitieren möchte. Ein besserer Vergleich wären HTML Standards im Laufe der Zeit. --> da kann es schon einmal passieren, daß Browserhersteller und Webdesigner nach dem verabschieden eines neuen Standards nachbessern müssen um auch weiterhin korrekte Ergebnisse zu liefern.
> Ein besserer Vergleich wären HTML Standards im Laufe der Zeit. --> da kann es schon einmal passieren, daß Browserhersteller und Webdesigner nach dem verabschieden eines neuen Standards nachbessern müssen um auch weiterhin korrekte Ergebnisse zu liefern.
Falsch, man kann im HTML Code nämlich angeben, welche HTML Version unterstützt wird. Browser müssen diese sogar erkennen und Mozilla bzw. Firefox haben dafür sogar mehrere Engines nach denen der HTML Code dann behandlet wird.
Der HTML Code ist daher sogar ein gutes Beispiel für mehrere Standards die man in mehreren Versionen noch mitschleppt. Dies würde einem Kernel mit fester API gleichkommen, der nach einem Bruch eine zweite stabile API mitliefert.
Von M wie Meikel am Mi, 7. Februar 2007 um 20:23 #
> Die Änderungen an der API ist ein Recht, welches sich die Kernelentwickler vorbehalten haben.
Schon kleinen Kindern bringt man bei, dass es neben Rechten auch Pflichten gibt. Da scheinen sich die Kernel-Entwickler nur die Rosinen rauspicken zu wollen.
> Sysadmin bist Du auf alle Fälle keiner, der würde eine solch kindliche Frage nicht stellen.
Been there, done that. Inzwischen bin ich zu teuer, um als einfacher Admin eingesetzt zu werden.
> Übrigens hinkt Dein nachfolgender Vergleich so derartig, daß es weh tut und ich das noch nicht einmal zitieren möchte.
Nein, er hinkt nicht. Die Kernel-Götter glauben, dass sie die Vorgaben machen können. Das mag bis zu einem gewissen Punkt auch stimmen, aber wenn diese Vorgaben zu weit von den Vorstellungen der Anwender abweichen, dann suchen die sich halt Alternativen.
> Ein besserer Vergleich wären HTML Standards im Laufe der Zeit. --> da kann es schon einmal passieren, daß Browserhersteller und Webdesigner nach dem verabschieden eines neuen Standards nachbessern müssen um auch weiterhin korrekte Ergebnisse zu liefern.
Wie schon gesagt: warum sollten sich Browserhersteller und Webdesigner absprechen und auf Standards einigen, während die Kernel-Götter glauben, alles nach ihrem Gusto bestimmen zu können? Oder möchtest du in die Zeit zurück, wo Netscape den Browsermarkt nach Belieben dominiert hat und nach eigenem Gusto neue Tags erfunden hat? Wohl eher nicht.
Von Anonymer Feigling am Di, 6. Februar 2007 um 13:41 #
Linux ist sicher nicht vom Untergang bedroht. Nur leider hat der Herr Torvalds bei der Entwicklung eine falsche Richtung eingeschlagen - und das bereits vor einigen Jahren. Linux ist mittlerweile nicht mehr das "bahnbrechende, innovative" Betriebssystem was es einmal war, sondern nur noch das am weiteste verbreitete Unix.
Vielleicht soll dieser Thread nur dazu dienen, dass langjährige Linux-Nutzer auch mal über den Tellerrand schauen, was es denn da noch für andere OpenSource-Betriebssysteme gibt. Und kann jeder sich sein eigenes Bild machen.
Im übrigen ist die BSD-Lizenz weitaus großzüger als die GPL, was vor allem von Firmen eigentlich lieber gesehen wird.
Übrigens basiert Apples Mac OS X auf ein FreeBSD 4.x Derivat.
Leider einem total verstümmelten FreeBSD. So wäre es wohl besser gewesen, sie hätten die Jails und das Dateinsystem gleich mit genommen. Da hat Apple verdammt stümperhaft gearbeitet, wenn auch der Rest einigermaßen gelungen ist.
Nein, aber es sind hier wieder mal einige Besserwisser unterwegs, welche PR Meldungen nachplappern:
die Altbekannten: *) Es muß eine stabile API/ABI her *) Microkernel sind immer besser *) BSD ist freier als GPL *) (füge beliebiges hinzu)
Kaum einer hat jemals eine Zeile Code zu irgendeinem Betriebssystemkern beigetragen. Aber es wissen natürlich "alle" besser.
Übesehen natürlich gleich, daß die so großartig propagierten Änderungen bzw. Kernelarten, oftmals Probleme an anderen Stellen verursachen und sich genau aus diesem Grund bisher nicht durchsetzen konnten. Der Linuxkernel muß ein sehr reiches Spektrum an Anwendungsfällen abdecken (Microcontroller --> Hochleistungsprozessor)! Auch versucht man möglichst aktuelle Hardware zu unterstützen, welche teilweise noch nicht mal am Markt ist, aber bereits bei der Markteinführung funktionieren soll.
Ja es gibt sicher trotzdem viele Kritikpunkte am Linux Kernel, jedoch leisten die Kernelentwickler mit Sicherheit sehr gute Arbeit und man kann im Zweifelsfall ja auch noch selbst Hand anlegen.
> und man kann im Zweifelsfall ja auch noch selbst Hand anlegen.
Tolles Argument mit dem viele versuchen wünsche der Nutzer abzutun. Man kann auch an den Nutzern "vorbeiprogrammieren" und die immer leuter werdenden Aufschreie ignorieren oder abtun oder man kann darauf eingehen und diese berücksichtigen.
Seltsam, früher war genau das das erfolgsgeheimnis eines Betriebsystemes Namens Linux...
Von Microkernel Fan am Di, 6. Februar 2007 um 15:10 #
Und trotzdem spielt hier ein richtiger Microkernel mit seinen spezifizierten Schnittstellen voll seine Stärken aus.
Die Schnittstelle eines Microkernels ändert sich nur selten, wenn der Kernel einmal fertig geschrieben ist.
Und an diese Schnittstelle kann man alles anpflanschen was man will. Auch mehrere Versionen einer USB API Schnittstelle, auch Herstellereigene wenn so etwas unbedingt notwendig sein sollte, und zwar ohne Neucompilieren des Microkernels. Einfach anheften und fertig.
Diesen Traum gibt es bei Linux nicht.
Der Kernel ist monolitisch, zwar gibt es Module, aber die hängen wiederum von den diversen Modulschnittstelle vom Kernel ab und dafür gibt es alle möglichen Varianten. Von der Modulschnittstelle für OSS Module bis zu i2c Module. Ist der Kernel aber ohne eine dieser Modulschnittstellen kompiliert, dann kann man den ganzen Kenel nochmal neu kompilieren, weil der Kernel diese Modulschnittstelle nicht kennt, die das Treibermodul aber braucht.
Ein Problem was man bei einem Microkernel schon aufgrund des Designs nie haben wird. Beim Microkernel kann man den Treiber direkt auf den Microkernel aufsetzen, oder eine gemeinsamme Schnittstelle für mehrere Treiber gleichen Typs (z.B. OSS oder i2c) auf den Microkernel aufsetzen. Wie man will. Und ein Hersteller der binäre Treiber anbieten möchte, der wird wohl Variante 1 nehmen und die wird über Jahrzehnte auf so einem Kernel laufen, solange sich die Schnittstellen des Microkernels nicht selbst ändern. Aber genau das passiert so gut wie nie, denn wenn ein Microkernel mal fertig ist, dann gibt es da nicht mehr viel an den Schnittstellen zum ändern, da ein Microkernel nunmal extrem schlank ist und extrem flexibel aufgebaut ist und somit sehr gut wartbar ist. Features die es im Microkernel nicht gibt, werden einfach per Design über die Schnittstelle angepflanscht und nicht in den Kernel direkt wie bei Linux implementiert.
Ein fertiges OS mit Microkernel wie GNU/Hurd wäre für den Endanwender jedenfalls ein Traum, da das nachrüsten mit Support neuester oder ältestert Hardware ein Kinderspiel wäre, daß man sogar wie bei BeOS in Form von Drag & Drop lösen könnte. Einfach Treiber in ein Verzeichnis installiert und schon ist er installiert. So geht das z.B. bei BeOS.
Auch wenn es nicht auf jeden Microkernel auf jeder Architektur zutrifft jedoch:
*) Microkernel sind in der Regel um etliche Prozent langsamer als monolithe Kernels (wenn man so manchen Zahlen trauen darf, sogar bis zu 20%) *) Komplexität und Performance bei div. synchronen Abläufen (--> diese müssen dann über IPC oder ähnliches behandelt werden)
Duch die hohe Anzahl der Kontextwechsel eignet sich insbesondere ein Microkernel sehr schlecht für die x86 Architektur.
Ich habe kein Problem mit Microkernel an sich, jedoch sehe ich keinen Grund wieso Linux ein Microkernel sein muß? Es ist vielleicht ein etwas besseres Grundkonzept, jedoch ist die tatsächliche Implementation entscheidend.
Übrigens gibt es schon einige Projekte, welche statt dem Linuxkernel einen Microkernel verwenden.
Trotzdem scheint sich das Interresse von Endanwender und Hardwarehersteller stark in Grenzen zu halten. Insofern scheint der aktuelle Kernel weitestgehend die Wünsche erfüllen zu können (wenn auch nicht alle --> aber es wird keine Technik geben, welche das jemals kann).
> *) Microkernel sind in der Regel um etliche Prozent langsamer als monolithe Kernels (wenn man so manchen Zahlen trauen darf, sogar bis zu 20%)
Das macht doch nichts wenn man dafür mehr Usability bekommt.
Die Leute die heute von Windows XP nach Windows Vista umsteigen bekommen auch ein OS, daß 20 % langsamer ist, dafür ist es aber wieder ein kleines Stückchen benutzerfreundlicher als WinXP.
> ch habe kein Problem mit Microkernel an sich, jedoch sehe ich keinen Grund wieso Linux ein Microkernel sein muß? Nicht Linux, Hurd. Linux wird ersetzt duch Hurd, sobald das ausgereift ist.
Eventuell sind das jetzt ein paar ziemlich blöde Fragen, aber ich stell sie mal trotzdem. Ist der Hurd-Kernel denn nun fertig oder nicht? (Das ist jetzt nicht als alle Jahre wiederkehrende Scherzfrage gemeint, ich kenn mich wirklich nicht mit dem Thema aus) Wenn nein: Was ist dann so schwierig daran einen Mircokernel zu Programmieren, der nichts anderes können muß, als Schnittstellen/Treiber anzuflanschen? Wenn ja: Woran fehlts? Zu wenig Manpower, zu wenig benutzbare Schnittstellen/Treiber, zuwenig Akzeptanz seitens der Industrie oder noch ganz andere Gründe? Warum kann als Übergangslösung für fehlende Treiber für Hurd nicht einfach eine Schnittstelle geschaffen werden, die Linuxtreiber, Freebsd-Treiber usw. verwenden kann, oder gibt's sowas schon?
Das soll jetzt bitte nicht als Flameware gegen Hurd verstanden werden! Ich wäre sehr dankbar über um eine möglichst sachliche Erklärung zu dem Thema.
Mit dem Kernel hat man ja auch nicht zwangsläufig Probleme. Und dieses typische "Kernel-bloat"-Gerede ist für den Endanwender auch nur zum Teil relevant. Von mir aus können gerne 20, ja, sogar 80 Hex2String-Varianten enthalten sein. Solange der Rest drumherum funktioniert (und das tut er hier), ist mir das ziemlich egal, und auch wie sauber der Quellcode ist, ist mir als Anwender wurscht.
Designtechnische Fragen (Paketverwaltung vs. Ports), politische Fragen (GPL vs. BSD-Lizenz), etc. sind schon andere Sachen; da liegen für mich die echten Unterschiede.
Ich habe im letzten Jahr einen ausführlichen Trip nach Linux unternommen, sehe beim BSD-Design aber nach wie vor große Vorteile, wenngleich Linux in Bezug auf krude Hardware bessere Unterstützung liefert und z.B. das v4l(2)-Framework echt edel ist.
Gentoo hatte vor 4 Jahren noch auf der Hauptseite des Projektes stehen, dass die Paketverwaltung (portage) auf von den BSD-Ports und Debians apt abgeguckten Ideen basiert (auch der Bezug zu LFS wird da heute nicht mehr so rausgestellt wie früher). Heute ist Gentoo zu etabliert, um noch ausdrücklich darauf hinzuweisen aber es ist natürlich immernoch so. Wenn Du also nochmal einen ausgedehnten Ausflug zu Linux machen willst/musst, schau Dir das doch mal an. Fast jeder BSD'ler der es sich angesehen hat, war danach eher mit Linux einverstanden .
Danke, kenne ich schon. forums.gentoo.org => Joined: 04 Jan 2004
Funktionierte hier im Prinzip auch nicht schlecht, wirkt auf mich (möglicherweise mangels genauerer Einarbeitung) wesentlich komplizierter. Lauter Kram in lauter Slots installieren, vieles blockt sich plötzlich irgendwann irgendwie gegenseitig. Alles Probleme, die ich unter BSD nicht habe. Und seit 2004 gab es mehr als eine simple Designänderung bei Gentoo, während FreeBSD viel statischer ist und im wesentlichen dem alten zuverlässigen Weg folgt. Von den Totalschrott-baselayout-emerges mal ganz abgesehen ....
Wenn eines Tages die GPL Redmond unterwandert hat und alle Entwickler ihren Eid auf die GPL schwören müssen, könnte der Tag kommen, an dem Debian GNU/kVista released werden wird.
Nach Voraussagen unter LSD soll dies genau 7 Tage nach Fertigstellung des HURD geschehen!
Wenn dann dieser Tag gekommen sein wird, wird es nur noch eine Enklave geben, wo es nicht schlecht riechen wird: Plan9!
Als reiner Desktopuser ist es mir völlig egal ob unter meinen GNU-Tools Linux, Hurd oder BSD steckt vor allem da alles wenn es genug gepflegt wird sicher auch sogut läuft wie Debian GNU/Linux
Der Treiber kann einfach unabhängig entwickelt werden und ganz normal wie ein gewöhnliches Softwarepaket
in die Distribution eingepielt werden.
lg
Erik
in die Distribution eingepielt werden.
Das geht im Prinzip auch unter Linux. Der Kernel kann dynamisch Treiber-Module laden. Das Problem ist, dass es unter Linux keine stabile Modul-Api gibt und deswegen die Module fuer jeden Kernel neu kompiliert werden muessen. Das ist aber kein technisches Problem, sondern eine bewusste Entscheidung der Kernel-Entwickler um properitaere binary-only Kernelmodule zu verhindern.
Dynamisch Treiber laden ist aber etwas anderes als ein Microkernel, wo die einzelnen Teile des Kernels voneinander getrennt sind.
> Das Problem ist, dass es unter Linux keine stabile Modul-Api gibt und deswegen die Module fuer jeden Kernel neu kompiliert werden muessen. Das ist aber kein technisches Problem, sondern eine bewusste Entscheidung der Kernel-Entwickler um properitaere binary-only Kernelmodule zu verhindern.
Nein, ich glaube, dass das der wirkliche Grund viel egoistischer ist. Für einen Kernel-Entwickler ist es einfach angenehmer, alles und jedes über den Haufen zu schmeißen und verändern zu können, wenn es ihm opportun scheint und keine Rücksicht auf Treiber- oder Applikationsentwickler nehmen zu müssen. Und bei Linux bestimmen nun mal die Kernel-Entwickler die Richtung, bei anderen Betriebssystemen werden solche Entscheidungen mit Blick auf das gesamte System getroffen und nicht nur von den Leuten, die den Kernel entwickeln.
Praktischer. Nicht egoistischer.
Für einen Kernel-Entwickler ist es einfach angenehmer, alles und jedes über den Haufen zu schmeißen und verändern zu können, wenn es ihm opportun scheint und keine Rücksicht auf Treiber- oder Applikationsentwickler nehmen zu müssen
So ist es. Ansonsten schleift man halt, wie z.B. bei Windows, 4 oder 5 USB-Schnittstellen-Implementierungen mit durch, weil man von den alten natürlich nicht lassen kann. Das gibt irgendwann übles Chaos.
Nebenbei bemerkt, die Kernelentwickler pflegen in den Kernel aufgenommene Treiber auch weiter. Also nix mit, "der Treiber-Entwickler sitzt dann da".
Ausnahme sind natürlich binäre, proprietäre Treiber. Deren Hersteller haben gelitten. Da gibt es drei Alternativen: 1. Sourcen freigeben und in den Kernel einbauen lassen 2. Zähne zusammenbeißen 3. Support einstellen
Für die Kernel-Jungs ist es eben so am schmerzärmsten und entspricht auch ihrer Philosophie. Und wenn man binäre Treiber im Kernel hat, kann man eine vernünftige Fehlersuche auch gleich abhaken.
Du siehst, es hat andere Gründe als den "Egoismus" der Kernelentwickler. Wobei da auch die Frage erlaubt sein sollte, warum die Kernelentwickler den Herstellern binärer Treiber Arbeit abnehmen sollten. Letztere verdienen damit idR auch Geld, dann können sie dafür auch arbeiten. Oder die Sourcen freigeben, dann haben sie die Arbeit nicht mehr.
> Praktischer. Nicht egoistischer.
Praktischer für die Kernel-Maintainer. Für den Rest der Welt: nein. Insofern ist es voll und ganz gerechtfertigt, das egoistisch zu nennen. Ich bin gespannt, was du für Gegenbeispiele bringen kannst, warum dieses Entwicklungsmodell auch für den Rest der Welt Vorteile haben soll.
> Ansonsten schleift man halt, wie z.B. bei Windows, 4 oder 5 USB-Schnittstellen-Implementierungen mit durch, weil man von den alten natürlich nicht lassen kann. Das gibt irgendwann übles Chaos.
Chaos gibt es bei Linux doch auch schon genug, Ob es wirklich die bessere Idee ist, alle paar Monate Details der Schnittstellen zu ändern, damit Gott und die Welt hinterherdackeln darf, wage ich zu bezweifeln.
Saubere, dokumentierte, stabile Schnittstellen sind überall sinnvoll. Warum gäbe es sonst DIN oder ISO? Was wäre das W3C wert, wenn Microsoft (IE), Operal oder Mozilla/Netscape alle paar Monate die Funktionalität ihrer Browser ändern würden? Saubere Schnittstellen sind nur für eine Gruppe lästig: die Entwickler, denn für sie bedeutet das Mehrarbeit in mehrfacher Hinsicht.
> Nebenbei bemerkt, die Kernelentwickler pflegen in den Kernel aufgenommene Treiber auch weiter. Also nix mit, "der Treiber-Entwickler sitzt dann da".
Das ist künstlich generierte Arbeit, die eigentlich überflüssig ist. Die man allerdings bei Linux prima dazu nutzen kann, den Nachwuchs bei Laune zu halten.
> Und wenn man binäre Treiber im Kernel hat, kann man eine vernünftige Fehlersuche auch gleich abhaken.
Das wird durch ständiges Wiederholen auch nicht wahrer. Andere Betriebssysteme bekommen das auch hin, Linux hat sich da selber reingeritten.
Kleine Ironie am Rande: Fault injection kennen andere Betriebssysteme schon lange, ebenso automatisierte Tests. Da ist bei Linux noch vieles im Argen.
Nein. Die Kernel-Entwickler machen die Arbeit; natürlich entscheiden sie dann auch, was sie tun und was sie lassen. Arbeite mit, dann kannst Du den Kurs mitbestimmen. Nutznießen, ohne dafür was zu leisten, aber Forderungen stellen, ist frech.
Ich bin gespannt, was du für Gegenbeispiele bringen kannst, warum dieses Entwicklungsmodell auch für den Rest der Welt Vorteile haben soll.
Habe ich: USB-Schnittstelle z.B.; Deine Antwort darauf:
Chaos gibt es bei Linux doch auch schon genug
Das nenn ich mal ein zugkräftiges Argument. Schon klar.
Ob es wirklich die bessere Idee ist, alle paar Monate Details der Schnittstellen zu ändern, damit Gott und die Welt hinterherdackeln darf, wage ich zu bezweifeln.
Wenn Du nicht liest und parst, was ich schreibe, werde ich mir die Mühe fürderhin schenken. Gott und die Welt muß nicht hinterherdackeln, sondern nur einmal die Treiber in den Kernel einbringen, dann hat sich das Problem gelöst. Wer das nicht möchte, ist eben allein auf hoher See.
Saubere, dokumentierte, stabile Schnittstellen sind überall sinnvoll.
Lies das verdammte Paper von Greg Kroah-Hartmann. Davor hat es keinen Sinn, zu diskutieren.
Warum gäbe es sonst DIN oder ISO?
Du würfelst Normen und deren versuchte Umsetzung durcheinander.
Saubere Schnittstellen sind nur für eine Gruppe lästig: die Entwickler, denn für sie bedeutet das Mehrarbeit in mehrfacher Hinsicht.
Nochmal: Lies das verdammte Paper.
Das ist künstlich generierte Arbeit, die eigentlich überflüssig ist.
Schon klar. Lieber lassen wir fehlerhafte Schnittstellen so, wie sie sind, damit uralte Binärtreiber weiter funktionieren; wir propfen dann einfach die nächste Stufe dazu, wenn es eine Erweiterung gibt usw.; und versuchen dann irgendwann, den ganzen Mist einigermaßen im Überblick zu halten. Was war noch gleich Dein Punkt?
Die man allerdings bei Linux prima dazu nutzen kann, den Nachwuchs bei Laune zu halten.
Deine polemische Argumentationsweise hängt mir zum Halse raus; ich werde Dich nach diesem Posting hinfort ignorieren.
Das wird durch ständiges Wiederholen auch nicht wahrer.
Dann zeig mir mal, wie man einen Fehler sucht, wenn man einen Teil des Codes nicht einsehen kann bzw. darf.
Andere Betriebssysteme bekommen das auch hin
Sie tun's einfach. Niemand behauptet, daß das super oder gar fehlerfrei klappen würde.
Linux hat sich da selber reingeritten.
Jetzt hast Du's mir aber gegeben.
Eine weitere Diskussion mit Dir werde ich mir schenken; Du polemisierst, gehst auf meine Argumente nicht ein - dafür ist mir meine Zeit zu schade.
Hatte die Ehre.
So ein Quatsch. Ich muß nicht erst selber ein Auto bauen, um beurteilen zu können, ob ein Auto eine gute Straßenlage hat oder wenig verbraucht. Aber das Totschlagargument ist ja unter Linux-Aposteln recht beliebt, um jedweder Kritik zu begegnen. Merkt ihr eigentlich nicht, wie lächerlich das ist?
> Lies das verdammte Paper von Greg Kroah-Hartmann. Davor hat es keinen Sinn, zu diskutieren.
Das habe ich schon längst gelesen. Und das Pamphlet ist in meinen Augen ziemlicher Unfug. Hätten wir gerne etwas näher drauf eingehen wollen, aber wenn du die Diskussion sofort wieder abwürgst...
> Lieber lassen wir fehlerhafte Schnittstellen so, wie sie sind, damit uralte Binärtreiber weiter funktionieren; wir propfen dann einfach die nächste Stufe dazu, wenn es eine Erweiterung gibt usw.; und versuchen dann irgendwann, den ganzen Mist einigermaßen im Überblick zu halten.
Das ständige Frickeln ist ja wohl eher der Fall bei Linux, oder willst du ernsthaft behaupten, dass in der kurzen Zeit zwischen zwei Releases größere Umstellungsarbeiten gemacht werden können?
Lieber von Zeit zu Zeit einen sauberen Schnitt machen und etwas vernünftig renovieren, als ständig ein bisschen dran herumzupfuschen. Aber das würde ja ein Minimum an Planung erfordern und da tun sich die Kernel-Götter ja leider ziemlich schwer mit...
Apropos alte Zöpfe und Doppelentwicklungen: da gibt reichlich von im Linux-Kernel. Warum mit ALSA und OSS zwei Sound-Architekturen? Warum fünfzig Dateisysteme, von denen gerade mal eine Handvoll halbwegs populär ist und die sich gerade mal in Details unterscheiden? Bei Virtualisierungslösungen scheint man da ja langsam was gelernt zu haben, da ist man erst bei zwei...
> Dann zeig mir mal, wie man einen Fehler sucht, wenn man einen Teil des Codes nicht einsehen kann bzw. darf.
Klingt so, als hättest du überhaupt keine Ahnung von Softwareentwicklung. Als ob im Code eingestreute printf's die einzige Methode zum Debuggen wären. Da ist der Rest der Welt schon ein bisschen weiter.
> Eine weitere Diskussion mit Dir werde ich mir schenken; Du polemisierst, gehst auf meine Argumente nicht ein - dafür ist mir meine Zeit zu schade.
Ach, du willst doch gar nicht diskutieren. Aber wenn du dennoch antworten willst, kannst du das ja unter einem anderen Namen machen. Merkt hier ja eh niemand.
Es gibt doch nur eine: ALSA. OSS ist seit langem als *deprecated* ausgezeichnet.
Warum fünfzig Dateisysteme, von denen gerade mal eine Handvoll halbwegs populär ist und die sich gerade mal in Details unterscheiden?
So viele gibt es gar nicht und die meisten müssen unterstützt werden. ISO9660, UDF, CIFS, VFAT, NTFS sind schon allein wegen des marktbeherrschenden Betriebssystems quasi Pflicht.
Bei Virtualisierungslösungen scheint man da ja langsam was gelernt zu haben, da ist man erst bei zwei...
Welches ist denn das Zweite?
Als ob im Code eingestreute printf's die einzige Methode zum Debuggen wären.
Wie debuggst du denn Software ohne Zugriff auf den Quellcode?
> Es gibt doch nur eine: ALSA. OSS ist seit langem als *deprecated* ausgezeichnet.
Und es ist immer noch drin. Auf der einen Seite wird dauernd geändert, das wenigstens halbwegs stabil sein sollte, auf der anderen Seite werden uralte Zöpfe weder abgeschnitten noch emuliert.
> > Warum fünfzig Dateisysteme, von denen gerade mal eine Handvoll halbwegs populär ist und die sich gerade mal in Details unterscheiden?
> So viele gibt es gar nicht und die meisten müssen unterstützt werden. ISO9660, UDF, CIFS, VFAT, NTFS sind schon allein wegen des marktbeherrschenden Betriebssystems quasi Pflicht.
Auf dem System hier enthält /lib/modules/2.6.15-27-386/kernel/fs 50 Unterverzeichnisse. Dass viele wie NTFS oder UFS gerade mal zum Datenaustausch taugen und nicht als primäres Dateisystem, dürfte so manchem auch nicht klar sein. Wenn sogar IBM bei uns ext3 anstelle von JFS empfiehlt, dann frage ich mich doch, wieviele von den 50 Dateisystemen Leichen sind, die man ruhig mal entsorgen könnte.
> > Bei Virtualisierungslösungen scheint man da ja langsam was gelernt zu haben, da ist man erst bei zwei...
> Welches ist denn das Zweite?
http://www.pro-linux.de/news/2007/10801.html
Neben KVM versucht man sich ja wenigstens, auf eine Schnittstelle für Virtualisierungslösungen zu einigen, da scheint man aus der Vergangenheit gelernt zu haben. Und irgendwie kehren damit ja auch stabile Schnittstellen in den Kernel ein, zumindestens an einer Baustelle.
> > Als ob im Code eingestreute printf's die einzige Methode zum Debuggen wären.
> Wie debuggst du denn Software ohne Zugriff auf den Quellcode?
Mit Symbolen, mit Kerneldebuggern oder Crashdumps, mit Hooks oder Probes, da gibt es reichlich Möglichkeiten. Das klingt schon manchmal sehr amüsant, wie manche Leute das abtun, weil sie glauben, jenseits der Sourcen könne man nicht vernünftig debuggen.
Doch.
Ausnahme sind natürlich binäre, proprietäre Treiber.
Es gibt genug freie Treiber, die nie in den offiziellen Kernel-Tree aufgenommen werden.
Sehe ich nicht so. Schließlich hat sich an der grundlegenden Art der Kernelentwicklung nichts geändert. Lediglich der Releasezyklus hat sich zu gunsten der Treiberentwicklung geändert. Mit dem neuen System kann man besser neuen Code priorisieren.
Wenn man sich natürlich wieder auf die neusten Features stürzt, kann man schlecht erwarten, daß alles perfekt funktioniert.
Bis auf den einen Bug im 2.6.19 Kernel, war in letzter Zeit nichts von grundlegenden Problemen zu hören. Aber Du kannst nach wie vor einen Kernel der 2.4 Reihe verwenden, welche nach wie vor noch gewartet wird.
Ansonsten nenne einfach einmal ein Beispiel, wo Dein Problem zu finden ist.
mfg
unreal
Ich kann mit dem jetzigen Modell sehr gut leben.
Kurzum. Die Linux-Gemeinde (und da ist der Kernel nun mal keine Ausnahme) wird zunehmend zu einer Frickel-Werkstatt. Anstatt eine Sache mal richtig zu ende zu programmieren, werden mehrere Sachen halbwertig "implementiert". Da leistet das BSD-Team wirklich bessere Arbeit.
Ein 2.7er Kernel muss wirklich her! Denn seit Jahren wurde am Unterbau vom Kernel kaum etwas verändert. Viele grundlegende Teile sind total veraltert.
Ich weiß wovon ich rede, ich muss beruflich am Linux Kernel portieren.
Der Linux kernel ist Bloatware und kaum zu warten.
FreeBSD wird von der Industrie ungern gesehen, weil es nicht unter GPL steht.
Also bleibt nur GNU/HURD übrig, daß technisch aber so ansruchsvoll ist,
daß sich nur wenige Entwickler da ran trauen.
Aber aus Benutzersicht wäre GNU/HURD ein Traum OS für alle.
Ein Endanwender müßte nie wieder einen Kernel kompilieren nur um
eine bestimmte Hardware seines Rechners zum laufen zu bringen.
Einfach Treiber downloaden, einbinden und fertig und schon läuf die Hardware.
So würde es bei GNU/Hurd aussehen.
What? Was soll das denn? Gerade weil es nicht unter der GPL steht würde ich sagen, dass es gerne gesehen wird! Wer, der Geld machen will, will schon die GPL am Hals?
Von Firmen wird die BSD Lizenz nur dann gerne gesehen, wenn sie planen daraus ihr eigenes geschlossenes System zu machen.
Ist der Plan aber eine gemeinsamme Entwicklung unter vielen verschiedenen Firmen, dann bevorzugen alle die GPL, da keiner will, daß einer ihnen den Braten wegnimmt.
FreeBSD wird von der Industrie ungern gesehen, weil es nicht unter GPL steht.
Also bleibt nur GNU/HURD übrig, daß technisch aber so ansruchsvoll ist,
daß sich nur wenige Entwickler da ran trauen.
Aber aus Benutzersicht wäre GNU/HURD ein Traum OS für alle.
Linux stoesst auf breite Akzeptanz weil es sehr viel verschiedene Hardware unterstuetzt. Die ganzen Treiber machen wahrscheinlich 90% oder mehr der Linux-Kernel-Sourcen aus und die ganzen Treiber sind es, die wirklich Arbeit machen. Ich hab mir vor ein paar Jahren mal GNU/HURD installiert. Das war damals schon durchaus benutzbar. Aber was nuetzt mir ein supertolles Betriebssystem, dass meine Hardware nicht unterstuetzt?
Ein Endanwender müßte nie wieder einen Kernel kompilieren nur um
eine bestimmte Hardware seines Rechners zum laufen zu bringen.
Einfach Treiber downloaden, einbinden und fertig und schon läuf die Hardware.
So würde es bei GNU/Hurd aussehen.
Wie schon oben erwaehnt, dass waere auch unter Linux eigentlich nicht noetig. Kernel-Modul laden und fertig. Ob das jetzt im Userspace oder Kernelspace laeuft, ist letztlich irrelevant. Wenn man einen Microkernel ohne stabile Kernel-API hat, muss man die Module auch jedesmal neukompilieren, wenn man den Kernel updated.
Naja, Bloat wirst du in jedem Betriebssystem finden, das mehr als ein Minimum an Features hat. Aber ich gebe dir insofern Recht, dass die Linux-Entwicklung viel zu unstrukturiert und chaotisch ist.
> FreeBSD wird von der Industrie ungern gesehen, weil es nicht unter GPL steht.
Nö, ich glaube, dass die Lizenz den meisten Firmen relativ egal ist. Kritisch ist da noch am ehesten die GPL wegen ihre "viralen" Eigenschaften. FreeBSD hat in der Industrie wohl eher das Problem, dass es nicht die Popularität wie Linux hat und dass Firmen wie Redhat oder Novell fehlen.
Das kann man auch anders herum sehen: Der proprietäre Hersteller nutzt die rechtliche Grauzone und die freie und kostenlose Vorleistung Anderer, anstatt sich den Gepflogenheiten anzupassen und einen freien Treiber zu entwickeln bzw. entwickeln zu lassen.
Bist Du in Paris, verhalte Dich wie ein Pariser und willst Du Deine Hardware auf einem freien Betriebssystem funktionieren sehen, ermögliche einen freien Treiber. Aber man ist es ja in Deutschland gewohnt, sich aufdrücken zu lassen, was man bitteschön wie zu benutzen hat, wenn man schon noch so frech war, Hardware für's Geld zu verlangen.
lg
Erik
Wieso kommt gleich jeder mit dem Argument, dass proprietäre Hersteller eine Grauzone nutzen? Und was hat es freien Autoren, oder Firmen, die ihre Software unter der GPL ausliefern, zu tun? Intel, Broadcom, Marvell, D-Link, Linksys sind nur die wenigen im Netzerksegment. Alle diese Treiber liegen unter der GPL vor, müssen aber Monate auf eine Aufnahme in den Kernel warten. Bis sie von den Distributoren ausgeliefert werden, vergehen oftmals Jahre. Und das nur weil die Hacker Angst von Nvidia und ATI haben?
Aus purem Hass auf eine Handvoll Hersteller verbauen die Hacker absichtlich jegliche Aussicht auf stabile APIs und eine einfache Einbindung von neuer Hardware. Jede wichtigere Applikation schafft es stabille APIs zu haben und ermöglicht die Funktionalität durch Plug-Ins zu erweitern. Jedes brauchbare Betriebssystem schafft es. Warum also nicht der Linux-Kernel?
Weiter oben hast Du Dir noch Polemik verbeten. Das da IST pure Polemik. Greg Kroah-Hartmann hat in einem Paper geschildert, warum die Kernel-Entwickler keine stabile, interne API im Kernel haben wollen. Lies es halt.
> Jede wichtigere Applikation schafft es stabille APIs zu haben und ermöglicht die Funktionalität durch Plug-Ins zu erweitern. Jedes brauchbare Betriebssystem schafft es. Warum also nicht der Linux-Kernel?
Lies das Paper. Dann weißt Du, warum dem so ist.
Ich glaube Dein und mein Posting haben sich diesbezüglich nicht viel genommen.
> Es geht einzig und alleine um fehlende Schnittstellen
Sie sind da, sie liegen innerhalb des Kernels und wenn es die freien Treiber geschafft haben, in den Vanilla-Tree zu kommen, können sie sie nutzen und werden bei Bedarf angepasst.
> Alle diese Treiber liegen unter der GPL vor, müssen aber Monate auf eine Aufnahme in den Kernel warten
Werde bitte mal konkreter, denn das interessiert mich wirklich. Welcher Hersteller? Welche freien Treiber?
> verbauen die Hacker absichtlich jegliche Aussicht auf stabile APIs
Eine stabile API ist nicht erwünscht, weil sie im von den Kernelentwicklern gewollten Modell (siehe oben) nicht nötig ist. Freie Treiber sollen (wo der Code einigermaßen sauber ist) in den Tree, alle anderen können nachbessern oder müssen eben (im Falle proprietärer Treiber) draußen bleiben. Das es im Alltag des Kernelgeschäftes auch mal Ungerechtigkeit (zB in puncto "sauberen Codes") geben kann bestreitet niemand.
lg
Erik
Lies doch bitte seinen Satz noch einmal.
Er bezog sich auf Open Source Treiber und davon sind die ebenfalls betroffen,
siehe auch seine Worte zuvor:"Dass sie damit nicht nur proprätere Treiber ausschließen,"
Die Bedeutung von "nicht nur" sollte dir eigentlich bekannt sein:
Es ist nicht nur alles Weiß, sondern auch noch eiskalt.
Das sind 2 verschiedene unabhängige Zustände.
Und fakt ist nunmal das unter Linux ohne Neucompilierung oder Update auf eine neue Kernelversion fast nichts geht wenn man hochmoderne Hardware einsetzen möchte von denen es Open Source Treiber gibt.
Aber nicht in dem Maße, wie es proprietäre Treiber sind. Die Kernel-API ändert sich nicht von heute auf morgen aber dann und wann - und wenn sie es tut, sind die in den Linux-Quellen befindlichen Treiber schnell mitgeändert.
Das es eine erhebliche Schwelle für das eine oder andere freie Projekt geben kann, welches in den Tree aufgenommen werden will, bestreitet doch niemand und dass eine stabile Kernel-API hauptsächlich proprietären Treibern zugute käme, denn alle anderen haben (bei entsprechendem Design) die Möglichkeit, integriert zu werden, muss man ebenfalls mal zur Kenntnis nehmen.
lg
Erik
Was GNU/Hurd angeht, so ist der Kernel aus einem einzigen Grund nicht erfolgreich: Es entwickelt ihn nur eine zwar recht gute, aber dafür sehr kleine, eingeschworene Gemeinschaft aus Elite-Hackern, die schlicht keine anderen "unfähigen" Hacker bei sich haben wollen.
Doch, das tun sie. Wie vorhin schon angesprochen: der Treiber für ein Winmodem (ja, incl. Sourcen) war für 2.6.8 gedacht. Nach einigem Recherchieren hätte ich die nötigen Änderungen für 2.6.11 nachziehen können, blöderweise enthält Ubuntu 6.06 aber 2.6.15, und da waren dann doch einige heftige Änderungen nötig.
Der Dreh- und Angelpunkt ist es doch, Treiber als Teil des Kernels zu betrachten. Sobald man das nicht mehr tut (welche Betriebssystem außer Linux tut das?), hätten sich eine ganze Menge Probleme erledigt.
Ja. Aber dann müßten die Kernel-Entwickler für _dich_ und _mich_ Arbeit und Zeit investieren. Sie müßten - igitt! - deutlich mehr dokumentieren und testen. Und das sie dazu nicht gewillt sind, haben sie ja schon mehrfach dokumentiert.
wenn ich die Diskussionen hier so verfolge, scheint ja Linux vom Untergang bedroht zu sein.
Und der Kernel ist totaler Mist.
Oder habe ich das was falsch verstanden?
Komischerweise nutze ich beruflich und privat seit Jahren Linux und hatte mit dem Kernel praktisch noch keine Probleme - bis auf fehlende Treiber. Zum Beispiel für die beknackten "Winmodems".
Aber da suche ich die Schuld definitiv nicht bei den Kernelentwicklern.
Es ist schön, in einer total MS-zentrierten und -dominierten Welt eine - gute - Alternative zu haben. Und ich bedanke mich bei allen, die es ermöglicht haben - und weiter ermöglichen werden.
Nur meine 2 Cents
> Und der Kernel ist totaler Mist.
> Oder habe ich das was falsch verstanden?
Nein, nein, das hast du ganz richtig verstanden.
> Komischerweise nutze ich beruflich und privat seit Jahren Linux und hatte mit dem Kernel
> praktisch noch keine Probleme - bis auf fehlende Treiber. Zum Beispiel für die beknackten
> "Winmodems".
Das ist aber kein Argument! Das ist dir schon bewusst, oder?
> Es ist schön, in einer total MS-zentrierten und -dominierten Welt eine - gute - Alternative zu
> haben. Und ich bedanke mich bei allen, die es ermöglicht haben - und weiter ermöglichen werden.
Noch besser: merhere gute Alternativen!
Ich benutze Unix seit 20 Jahren (angefangen mit Sinix auf einer MX-2) und bin immer wieder erstaunt, wie betriebsblind die Linux-Anhänger bei vielen Dingen sind und dass sie reflexartig jede Kritik sofort als Angriff betrachten. Linux ist eine tolle Sache, aber weit davon entfernt perfekt zu sein. Solche Einschränkungen sind für manche Leuten aber scheinbar ein rotes Tuch. Blasphemie!
> Aber da suche ich die Schuld definitiv nicht bei den Kernelentwicklern.
Gäbe es stabile Schnittstellen im Kernel, hätte ich z.B. nicht längerem Experimentieren und Googlen herausfinden müssen, dass der Treiber für das Winmodem im neuen Laptop nur bis Kernel 2.6.8 läuft. Neuerer Kernel -> Treiber bei Conexant kaufen. Insofern sehe ich zumindestens eine Teilschuld bei den Kernel-Maintainern.
Wie wäre es mit einer Mitschuld der Notebookherstellers, weil er Dir ein "Winmodem" sprich D/A Chip als Modem angedreht hat?
Warum wurde der Treiber nicht gewartet, wie es eigentlich sein sollte?
Warum hat der Treiberhersteller nicht darauf hingewiesen?
Und nein eine stabile API/ABI schützt einem auch davor nicht. --> siehe Windows NT, 2000 bzw. XP
Es gibt genügend Treiber von USB Geräten, Videokarten, etc.. welche nach dem Einspielen eines Servicepacks etc. plötzlich für immer den Dienst verweigerten.
mfg
unreal
Wie wäre es mit einer Schuld des Herstellers? Was können die Kernel-Entwickler dafür? Nichts? Na also.
Wenn der Hersteller ein verkrüppeltes Modem verkauft, ist er dran schuld.
Dann hatte sich das ABI eben doch an irgendeiner Stelle geändert.
Wie wäre es mit: Treiber für Linux existierten. Es ist die Schuld der Kernel-Götter, dass diese Treiber nicht mehr funktionieren.
> Warum wurde der Treiber nicht gewartet, wie es eigentlich sein sollte?
Warum muß ein Treiber gewartet werden? Was würdest du sagen, wenn ein Webmaster dir vorschreibt, einen Firefox aus dem CVS zu bauen, weil alle anderen Browser seine Seiten nicht korrekt anzeigen können? Den Firefox bauen oder dem Webmaster einen Vogel zeigen?
> Es gibt genügend Treiber von USB Geräten, Videokarten, etc.. welche nach dem Einspielen eines Servicepacks etc. plötzlich für immer den Dienst verweigerten.
Ich habe wenig mit Windows zu tun, aber damit bisher noch keine wirklichen Probleme gehabt. Im Gegensatz dazu kann ich eine Menge unschöner Erlebnisse erzählen, wo dieser Zoo von subtilen Abhängigkeiten das Leben unter Linux zur Hölle macht. Gerade die letzte Woche habe ich wieder mit Kernel backen verplempert, weil man ein aktualisierter Treiber für die Bootplatten unter Linux ein Staatsakt ist, was unter anderen Betriebssystemen in ein paar Minuten erledigt ist.
Wenn der Treiber nicht offizieller Bestandteil des Kernels ist, liegst Du leider falsch. --> der Treiberhersteller und nicht Dritte sind für das Funktionieren des Treibers verantwortlich. Die Änderungen an der API ist ein Recht, welches sich die Kernelentwickler vorbehalten haben.
Du magst mit dieser Politik vielleicht nicht einverstanden sein, jedoch sind diese Änderungen nicht nur Fluch sondern auch Segen zugleich.
Warum muß ein Treiber gewartet werden?
Warum muß Du das Öl in Deinem Auto wechseln? Sysadmin bist Du auf alle Fälle keiner, der würde eine solch kindliche Frage nicht stellen. --> Übrigens hinkt Dein nachfolgender Vergleich so derartig, daß es weh tut und ich das noch nicht einmal zitieren möchte.
Ein besserer Vergleich wären HTML Standards im Laufe der Zeit. --> da kann es schon einmal passieren, daß Browserhersteller und Webdesigner nach dem verabschieden eines neuen Standards nachbessern müssen um auch weiterhin korrekte Ergebnisse zu liefern.
mfg
unreal
Falsch, man kann im HTML Code nämlich angeben, welche HTML Version unterstützt wird.
Browser müssen diese sogar erkennen und Mozilla bzw. Firefox haben dafür sogar mehrere Engines nach denen der HTML Code dann behandlet wird.
Der HTML Code ist daher sogar ein gutes Beispiel für mehrere Standards die man in mehreren Versionen noch mitschleppt. Dies würde einem Kernel mit fester API gleichkommen, der nach einem Bruch eine zweite stabile API mitliefert.
Schon kleinen Kindern bringt man bei, dass es neben Rechten auch Pflichten gibt. Da scheinen sich die Kernel-Entwickler nur die Rosinen rauspicken zu wollen.
> Sysadmin bist Du auf alle Fälle keiner, der würde eine solch kindliche Frage nicht stellen.
Been there, done that. Inzwischen bin ich zu teuer, um als einfacher Admin eingesetzt zu werden.
> Übrigens hinkt Dein nachfolgender Vergleich so derartig, daß es weh tut und ich das noch nicht einmal zitieren möchte.
Nein, er hinkt nicht. Die Kernel-Götter glauben, dass sie die Vorgaben machen können. Das mag bis zu einem gewissen Punkt auch stimmen, aber wenn diese Vorgaben zu weit von den Vorstellungen der Anwender abweichen, dann suchen die sich halt Alternativen.
> Ein besserer Vergleich wären HTML Standards im Laufe der Zeit. --> da kann es schon einmal passieren, daß Browserhersteller und Webdesigner nach dem verabschieden eines neuen Standards nachbessern müssen um auch weiterhin korrekte Ergebnisse zu liefern.
Wie schon gesagt: warum sollten sich Browserhersteller und Webdesigner absprechen und auf Standards einigen, während die Kernel-Götter glauben, alles nach ihrem Gusto bestimmen zu können? Oder möchtest du in die Zeit zurück, wo Netscape den Browsermarkt nach Belieben dominiert hat und nach eigenem Gusto neue Tags erfunden hat? Wohl eher nicht.
Vielleicht soll dieser Thread nur dazu dienen, dass langjährige Linux-Nutzer auch mal über den Tellerrand schauen, was es denn da noch für andere OpenSource-Betriebssysteme gibt. Und kann jeder sich sein eigenes Bild machen.
Im übrigen ist die BSD-Lizenz weitaus großzüger als die GPL, was vor allem von Firmen eigentlich lieber gesehen wird.
Übrigens basiert Apples Mac OS X auf ein FreeBSD 4.x Derivat.
Das schreit nach Erläuterungen! Linux war doch nie mehr als ein traditionelles Unix-Clone...
die Altbekannten:
*) Es muß eine stabile API/ABI her
*) Microkernel sind immer besser
*) BSD ist freier als GPL
*) (füge beliebiges hinzu)
Kaum einer hat jemals eine Zeile Code zu irgendeinem Betriebssystemkern beigetragen. Aber es wissen natürlich "alle" besser.
Übesehen natürlich gleich, daß die so großartig propagierten Änderungen bzw. Kernelarten, oftmals Probleme an anderen Stellen verursachen und sich genau aus diesem Grund bisher nicht durchsetzen konnten.
Der Linuxkernel muß ein sehr reiches Spektrum an Anwendungsfällen abdecken (Microcontroller --> Hochleistungsprozessor)! Auch versucht man möglichst aktuelle Hardware zu unterstützen, welche teilweise noch nicht mal am Markt ist, aber bereits bei der Markteinführung funktionieren soll.
Ja es gibt sicher trotzdem viele Kritikpunkte am Linux Kernel, jedoch leisten die Kernelentwickler mit Sicherheit sehr gute Arbeit und man kann im Zweifelsfall ja auch noch selbst Hand anlegen.
mfg
unreal
Tolles Argument mit dem viele versuchen wünsche der Nutzer abzutun.
Man kann auch an den Nutzern "vorbeiprogrammieren" und die immer leuter werdenden Aufschreie ignorieren oder abtun oder man kann darauf eingehen und diese berücksichtigen.
Seltsam, früher war genau das das erfolgsgeheimnis eines Betriebsystemes Namens Linux...
Wünsche von User != sinnlose Kritik und Besserwisserei
mfg
unreal
Die Schnittstelle eines Microkernels ändert sich nur selten, wenn der Kernel einmal fertig geschrieben ist.
Und an diese Schnittstelle kann man alles anpflanschen was man will.
Auch mehrere Versionen einer USB API Schnittstelle, auch Herstellereigene wenn so etwas unbedingt notwendig sein sollte, und zwar ohne Neucompilieren des Microkernels.
Einfach anheften und fertig.
Diesen Traum gibt es bei Linux nicht.
Der Kernel ist monolitisch, zwar gibt es Module, aber die hängen wiederum von den diversen Modulschnittstelle vom Kernel ab und dafür gibt es alle möglichen Varianten.
Von der Modulschnittstelle für OSS Module bis zu i2c Module.
Ist der Kernel aber ohne eine dieser Modulschnittstellen kompiliert, dann kann man den ganzen Kenel nochmal neu kompilieren, weil der Kernel diese Modulschnittstelle nicht kennt, die das Treibermodul aber braucht.
Ein Problem was man bei einem Microkernel schon aufgrund des Designs nie haben wird.
Beim Microkernel kann man den Treiber direkt auf den Microkernel aufsetzen, oder eine gemeinsamme Schnittstelle für mehrere Treiber gleichen Typs (z.B. OSS oder i2c) auf den Microkernel aufsetzen.
Wie man will.
Und ein Hersteller der binäre Treiber anbieten möchte, der wird wohl Variante 1 nehmen und die wird über Jahrzehnte auf so einem Kernel laufen, solange sich die Schnittstellen des Microkernels nicht selbst ändern.
Aber genau das passiert so gut wie nie, denn wenn ein Microkernel mal fertig ist, dann gibt es da nicht mehr viel an den Schnittstellen zum ändern, da ein Microkernel nunmal extrem schlank ist und extrem flexibel aufgebaut ist und somit sehr gut wartbar ist.
Features die es im Microkernel nicht gibt, werden einfach per Design über die Schnittstelle angepflanscht und nicht in den Kernel direkt wie bei Linux implementiert.
Ein fertiges OS mit Microkernel wie GNU/Hurd wäre für den Endanwender jedenfalls ein Traum,
da das nachrüsten mit Support neuester oder ältestert Hardware ein Kinderspiel wäre,
daß man sogar wie bei BeOS in Form von Drag & Drop lösen könnte.
Einfach Treiber in ein Verzeichnis installiert und schon ist er installiert.
So geht das z.B. bei BeOS.
*) Microkernel sind in der Regel um etliche Prozent langsamer als monolithe Kernels (wenn man so manchen Zahlen trauen darf, sogar bis zu 20%)
*) Komplexität und Performance bei div. synchronen Abläufen (--> diese müssen dann über IPC oder ähnliches behandelt werden)
Duch die hohe Anzahl der Kontextwechsel eignet sich insbesondere ein Microkernel sehr schlecht für die x86 Architektur.
Ich habe kein Problem mit Microkernel an sich, jedoch sehe ich keinen Grund wieso Linux ein Microkernel sein muß? Es ist vielleicht ein etwas besseres Grundkonzept, jedoch ist die tatsächliche Implementation entscheidend.
Übrigens gibt es schon einige Projekte, welche statt dem Linuxkernel einen Microkernel verwenden.
Trotzdem scheint sich das Interresse von Endanwender und Hardwarehersteller stark in Grenzen zu halten. Insofern scheint der aktuelle Kernel weitestgehend die Wünsche erfüllen zu können (wenn auch nicht alle --> aber es wird keine Technik geben, welche das jemals kann).
mfg
unreal
Das macht doch nichts wenn man dafür mehr Usability bekommt.
Die Leute die heute von Windows XP nach Windows Vista umsteigen bekommen auch ein OS, daß 20 % langsamer ist, dafür ist es aber wieder ein kleines Stückchen benutzerfreundlicher als WinXP.
> ch habe kein Problem mit Microkernel an sich, jedoch sehe ich keinen Grund wieso Linux ein Microkernel sein muß?
Nicht Linux, Hurd.
Linux wird ersetzt duch Hurd, sobald das ausgereift ist.
Ist der Hurd-Kernel denn nun fertig oder nicht? (Das ist jetzt nicht als alle Jahre wiederkehrende Scherzfrage gemeint, ich kenn mich wirklich nicht mit dem Thema aus)
Wenn nein:
Was ist dann so schwierig daran einen Mircokernel zu Programmieren, der nichts anderes können muß, als Schnittstellen/Treiber anzuflanschen?
Wenn ja:
Woran fehlts? Zu wenig Manpower, zu wenig benutzbare Schnittstellen/Treiber, zuwenig Akzeptanz seitens der Industrie oder noch ganz andere Gründe?
Warum kann als Übergangslösung für fehlende Treiber für Hurd nicht einfach eine Schnittstelle geschaffen werden, die Linuxtreiber, Freebsd-Treiber usw. verwenden kann, oder gibt's sowas schon?
Das soll jetzt bitte nicht als Flameware gegen Hurd verstanden werden! Ich wäre sehr dankbar über um eine möglichst sachliche Erklärung zu dem Thema.
Designtechnische Fragen (Paketverwaltung vs. Ports), politische Fragen (GPL vs. BSD-Lizenz), etc. sind schon andere Sachen; da liegen für mich die echten Unterschiede.
Ich habe im letzten Jahr einen ausführlichen Trip nach Linux unternommen, sehe beim BSD-Design aber nach wie vor große Vorteile, wenngleich Linux in Bezug auf krude Hardware bessere Unterstützung liefert und z.B. das v4l(2)-Framework echt edel ist.
Wenn Du also nochmal einen ausgedehnten Ausflug zu Linux machen willst/musst, schau Dir das doch mal an. Fast jeder BSD'ler der es sich angesehen hat, war danach eher mit Linux einverstanden
Funktionierte hier im Prinzip auch nicht schlecht, wirkt auf mich (möglicherweise mangels genauerer Einarbeitung) wesentlich komplizierter. Lauter Kram in lauter Slots installieren, vieles blockt sich plötzlich irgendwann irgendwie gegenseitig. Alles Probleme, die ich unter BSD nicht habe. Und seit 2004 gab es mehr als eine simple Designänderung bei Gentoo, während FreeBSD viel statischer ist und im wesentlichen dem alten zuverlässigen Weg folgt. Von den Totalschrott-baselayout-emerges mal ganz abgesehen ....
Der war gut, den lass ich mir rahmen
)
Btw. BSD is dying und Linux ist total überlegen und während die einen coden bei *BSD, betet ihr eure Tux-Götze an
und alle Entwickler ihren Eid auf die GPL schwören müssen,
könnte der Tag kommen,
an dem Debian GNU/kVista released werden wird.
Nach Voraussagen unter LSD soll dies genau 7 Tage
nach Fertigstellung des HURD geschehen!
Wenn dann dieser Tag gekommen sein wird,
wird es nur noch eine Enklave geben, wo es
nicht schlecht riechen wird: Plan9!
LG, eurer Prachttroll
hmm :s