Ist es immer noch so, dass ungerade Versionsnummer beim Linux-Kernel darauf hinweisen, dass dieser ein Test-Kernel für neue Funktionen ist, während die geraden Nummern auf stabile Versionen hinweisen? In dem Fall verwundert es nicht, dass .27 und .29 größere Patches mit sich brachten als .28.
Und schön zu sehen, dass Linux gedeiht und wächst!
man kann über die Zeit aber schon beobachten, dass sich Kernel mit mehr oder weniger intensiven Änderungen abwechseln. Nach einem langwierigen Kernel versucht Linus eher einen schnellen zu machen, und dann wird der nächste automatisch länger.
Mit Stabilität hat das aber Nichts zu tun. Die stabilen Kernel sind jetzt 2.6.x.y mit y > 0 und möglichst hoch.
Einen richtigen vollen Entwicklungszyklus (das an den Urheber des Threads) gibt es garnicht mehr. Die hohe Rate an Änderungen erlaubt es nicht mehr, nur alle paar Jahre massive Änderungen zu machen. Dafür passieren jetzt bei jedem Release massive Änderungen und davon immer mehr in immer kürzerer Zeit.
Bin gespannt, wie sehr sich der Kernel noch in seiner Entwicklung beschleunigen wird. Schon jetzt gibt in jeder Minor mehr Änderungen und neue Features als zum Teil in grossen Versionen anderer Kernel. Alleine das Lesen der Änderungen bei kernelnewbies dauert ja schon Stunden.
Von Hermann Headcrash am Mo, 12. Januar 2009 um 05:03 #
Ist es immer noch so, dass ungerade Versionsnummer beim Linux-Kernel darauf hinweisen, dass dieser ein Test-Kernel für neue Funktionen ist, während die geraden Nummern auf stabile Versionen hinweisen?
Man munkelt, in 2.5.x seien die Nummern in der dritten Stelle ausgegangen und so ist auch 2.6.x jetzt "unstable"...
Also der Entwickler hat sogar einen X-Server in Wayland zum Laufen bekommen. Soweit ich das verstanden habe, hat er einen eigenen ``Treiber'' entwickelt, der die ganzen Hardwarezugriffe durch Wayland und somit ueber den Kernel umleitet. Somit kann der X-Server sogar im Userspace laufen. Uebrigens: Wayland hat sogar ein eigenes Terminal. Dafuer braucht man also nicht extra einen X-Server zu starten (welcher direkt unter Wayland laueft, mehrere Instanzen sind auch moeglich). Was mich jetzt noch interessieren wuerde, waere die Grafikbeschleunigung. Wie sieht es damit aus? Schade ist allerdings, dass Pro-Linux und andere einschlaegigen Nachrichtenseiten nicht ueber die Fortschritte berichten. Daher kann ich jedem, der sich fuer Wayland und Kernelmodelines interessiert, den Blog des Entwicklers ans Herz legen.
Weil Suse/Redhat nur die 2.6.18er Patches relativ fricklig forward-geported haben - das Zeug läuft eigenen Erfahrungen zu Folge aber wesentlich instabiler als 2.6.18.
Demnach besteht wohl keine große Chance darauf, dass ein funktionierender dom0-Kernel >=2.6.27 in Bälde offiziell das Licht der Welt erblickt? Sei's als in-Kernel (was mir am liebsten wäre) oder als externer Patch von Xensource/Citrix?
Ich bin leider auf Xen angewiesen, da der zu virtualisierende Rechner keine Virtualisierungsunterstützung in den CPUs besitzt (alte Opterons von gaaanz früher ).
Was für mich wesentlich interessanter ist: der rt2860-Treiber von Ralink ist von Greg Kroah-Hartmann als experimenteller Patch in den Kernel aufgenommen - eine gute Voraussetzung, um vom SerialMonkey-Team demnächst zu einem stabilen Treiber verarbeitet zu werden, wie bereits bei den rt2x00-Treibern geschehen. Dieser WLAN-Chipsatz findet sich übrigens in vielen Netbooks wieder.
Hallo, kann mir das mal jemand kurz erklären? Ist es so, dass der Linux-Kernel immer größer werden muss, weil immer mehr Treiber integriert werden? Stimmt es, dass es einen grundsätzlichen Unterschied zwischen dem Win- und Lin-Kernel bezüglich seines Aufbau gibt? Ich habe mal gehört, dass einer von beiden ein modularer Kernel wäre, also nur bei Bedarf Dinge (Treiber) hinzugefügt werden, während sie bei dem anderen komplett integriert sind. Angeblich soll der Lin-Kernel da Nachteile haben. Danke!
Das ist falsch, beide Kernel sind modular, allerdings beides mal weit entfernt davon rein modulare Kernel zu sein.
Richtig ist: - Man kann den Linuxkernel monolitisch kompilieren, d.h. so dass alle module direkt im Kernel sind und auch beim Start geladen werden. Das macht aber (mir bekannte) keine Distribution und ist so auch recht sinnlos. Vorteilhaft ist es natürlich Treiber direkt in den Kernel einzubinden die man auf jeden Fall braucht (z.b. Dateisystemtreiber). Andere Treiber (Audio, Drucker, serielle Modems, pppoe-Modems) sind bei Linux weitgehend außerhalb des Kernels (also z.b ist nur der Parallelport-treiber und der usb-Treiber im Kernel, die Befehle für den Drucker werden über einen Dämon bereitsgestellt der im userspace läuft). Mit FUSE gibt es auch eine Schnittstelle die es sogar erlaubt Dateisystem außerhalb des Kernels zu implementieren. Generell würde ich daher sagen, der Linuxkernel lagert mehr Funktionalität aus als Windows. Das hat allerdings nichts mit Modularität zu tun, denn Module sind imho Teil des Kernels (laufen NICHT im userspace). Wieviel Modularität man für sinnvoll hält kann jeder Anwender / Distributor beim Kompilieren des Linuxkernels selber entscheiden.
Beide sind monolitische Kernel, aber der Linux-Kernel hat einen entscheidenen Vorteil: Da der Quellcode zur Verfuegung steht kannst du dir den gesammten Code runterladen und dann einfach beim Kompilieren die Treiber/Features entfernen die du nicht brauchst. Dadurch erhaellst du einen sehr speziellen und schlanken Kernel der alles dabei hat was deine Hardware hergibt. Fuer Arch Linux kannst du dir z.B. einen speziellen Kernel fuer den Aspire One Netbook aus AUR herunterladen.
Ein weiterer Vorteil ist natuerlich, dass ein Treiber gleich eine gesammte Hardwarefamilie ansprechen kann, im Gegensatz zu Windows, da dort man fuer jede Hardware einen neuen Treiber installieren muss. Dies ist ein plus fuer die Kernelgrosse und vor allem fuer die Sicherheit und Stabilitaet.
Es ist immer lustig auf heise.de die Trolle zu lesen, die behaupten das der Kernel immer grosser und groesser wird. Das stimmt nur fuer den gesammten Code des Kernels, aber die Distributoren lassen ja dann alte Treiber, selten benutze Faehigkeiten, usw. weg, so dass fuer den Endbenutzer der Kernel eigentlich in der Groesse gleich bleibt.
Ja, dank der Tools zur Kernelkonfiguration geht das recht simpel von der Hand, wenn man weiss, was man braucht. Frueher hat man noch alles per Konfigurationsdatei direkt konfiguriert, da musste man schon etwas mehr auspassen und wissen, was sich kombinieren laesst und wie.
Die riesige Gruppe potentielle User ist nur zu einem sehr geringen Prozentsatz fähig, die verschiedenen Konfigurationsmöglichkeiten, deren Bezeichnungen und Bedeutungen zu erfassen. Wie unter Windows Treiber-CD einlegen und durch das Installationsprogramm durchklicken, kriegen deutlich mehr Menschen hin. Das Adjektiv "simpel" ist somit nicht gerechtfertigt.
Wenn ich es richtig verstehe, geht es hier einzig und alleine um die Möglichkeit! Der Linux Kernel versteht schon von alleine die nötigen Module selbstständig reinzuladen. Bin ich der einzige der mehr Zeit damit verbringt Treiber unter Windows zu installieren, als unter Linux?
> Wenn ich es richtig verstehe, geht es hier einzig und alleine um die Möglichkeit!
Es muß darum gehen, den Massenmarkt zu erreichen und da ist die Mehrheit nunmal gerade in der Lage mit einem System wie Windows eiigermaßen umzugehen, von tieferem Verständnis nicht erst zu reden. Dazu den Quellcode anzugucken, make anzustoßen o.ä. sind 99,9% der Mitbürger zu doof oder zu desinteressiert. Die Möglichkeit den Quellcode anzugucken, ist im Rahmen ihrer Möglichkeiten, für fast alle irrelevant. Und von dieser Warte ist der monolithische Kernel ein echtes Problem: Ein niegelneues Gerät funktioniert nicht oder nur eingeschränkt, weil keine Treiber-CD für Linux dabeiliegt, ein halbwegs passabler Treiber erst nach Monaten in einen neuen Linux-Kernel einzug hält. Das ist aus Benutzersicht inakzeptabel.
Linux hat - ein bisschen optimistisch ausgedrückt - vielleicht Software-Turnaround-Zeiten von wenigen Monaten (bis die nächste Distro draußen ist).
Wenn jeder Hardware-Hersteller _rechtzeitig_ (also mit anderen Worten, __gleichzeitig__ mit der Windows-Treiber-Entwicklung) Treiber-Support für Linux bereitstellen würde, dann wäre das ruckzuck im Zuge der allgemein durchgeführten Entwicklungsschritte bei Linux beim Endanwender aufgeschlagen.
Das Problem ist aber, dass Firmen das nicht machen. Und genau das ist es, sonst nix.
Zu sagen, das Problem läge ausschließlich bei den Unternehmen, ist der übliche Abwehrreflex verbohrter FLOSS-Verfechter, stellt aber nur ein Zerrbild der Realität dar. Richtig ist, daß die Firmen gefragt sind Entwicklungsarbeit zu leisten bzw. zu finanzieren. Ansonsten liegst Du falsch.
> Linux hat - ein bisschen optimistisch ausgedrückt - vielleicht Software-Turnaround-Zeiten von wenigen Monaten (bis die nächste Distro draußen ist).
Bis die Bananaware-Treiber im Kernel gereift sind, dauert es in manchem Fall Jahre, das eine oder andere spezielle Feature einer Hardware funktioniert nie oder nur fehlerhaft. Großartig. Und nein: Selbst wenn Treiber in einem neuen Kernel gefixt werden, heißt das in einer riesigen Anzahl von Anwendungsfällen (von Joe-User-Gadgets bis zu zertifizierten Systemen), daß das Einspielen neuer Kernel akzeptabel ist.
Das ist aber kein Unterschied zu Windows, denn wenn ich mir eine komplette Treiber CD/DVD, für so ziemlich alle Hardware die es gibt, besorge (es gibt solche CD/DVDs gelegentlich in den einschlägigen Heftchen) und installiere dann habe ich auch Unmengen an Treibern und zugehörigem Quellcode (der liegt allerdings meist gar nicht extra bei). Alleine Nvidia bietet aktuell bereits über 500MB an Treibern (mit Instller) für den Betrieb eigener Hardware unter Windows... das ist weit mehr als bei Linux!
Hier mit Zahlen wie "500MB" zu hantieren ist einfach völlig daneben.
Warum?
Ganz einfach: weil Linux wesentlich weniger bloatige Treiber-Spielchen betreibt (u.a. durch wesentlich zentraler implementierte Funktionalität, die von mehreren Treibern genutzt werden kann).
Bei einem Treiber kommt es überwiegend auf die Kern-Funktionalität an, schmückendes Beiwerk oder Bloat ist häufig gar nicht sonderlich erwünscht.
Wenn ich sehe, dass man für einen einzigen "Treiber" bei Windows manchmal 37, 40, 45 MB ziehen muss, dann ist das schon fast lachhaft. Soviel Platz haben früher noch nicht einmal ganze Rechenzentren belegt.
Natürlich mögen bei einem sehr großen Treiberpackage noch viele Desktop-Gehilfen dabei sein, das ist sehr sinnvoll, aber Bloat ist da so oder so ziemlich viel dabei.
Und wozu brauch ich bei einem Treiber einen _herstellerspezifischen_ "Installer", der ungefähr so 58% der Gesamt-Packagegröße ausmacht (wenn man Glück hat)? Bloat, Bloat, Bloat... echte Betriebssysteme brauchen keine kunterbunte Mischung aus Treiber-"Installern".
Beide sind monolitische Kernel, aber der Linux-Kernel hat einen entscheidenen Vorteil:
Nur Linux ist ein monolitischer Kernel. Windows besteht im wesentlichem aus einem Microkernel, was die Sache aber keineswegs besser macht. Unter Windows werden nicht nur die reinen Treiber in den Kernel geladen, sondern auch noch das grafische Beiwerk, um die Hardware administrieren zu können (die grafische Oberfläche ist ja Teil des Betriebssystems). Da laufen dann z.B. die Programme zum Einstellen einer Grafikkarte mit Systemrechten (höher als der User Administrator!) und enthaltene Fehler schaffen so nicht nur Sicherheitsprobleme, sondern vor allem Instabilitäten.
Unter Linux kann man die meisten Treiber zwar direkt in den Kern compilieren, zumeist wird aber so ziemlich alles als Modul compiliert. Abhängig von der vorhandenen Hardware, werden dann nur die jeweiligen Treiber geladen, die benötigt werden. Das geschieht zumeist ohne das Zutun des Anwenders und versteckt im Hintergrund. Zu dem kann ein Treiber, sonfern er von keinem Anwendungsprogramm benötigt wird, auch während des Betriebs entladen werden. Etwas, das bei Windows nicht geht. Windows ist sogar so schlimm, dass alle installierten Treiber beim Starten immer geladen werden, unabhängig davon, ob die entsprechende Hardware vorhanden ist oder nicht. Da sind Probleme dann vorprogrammiert.
Unter Linux stehen entsprechende Hilfsmittel bereit um genau überprüfen zu können, welche Treiber geladen sind und ob, bzw. von welcher Anwendung sie verwendet werden. Unter Windows kann das, wenn überhaupt, nur unvollständig ermittelt werden (ist Windows erst einmal kaputtkonfiguriert, muss man es neu installieren).
Nun kann man natürlich über die verwendeten Konzepte streiten, aber Fakt ist, dass Windows in jeder Hinsicht das genaue Gegenteil von Linux oder *NIX ist. Oder kurz gesagt: Windows ist unbrauchbar!
> Zu dem kann ein Treiber, sonfern er von keinem Anwendungsprogramm benötigt wird, auch während des Betriebs entladen werden. > Etwas, das bei Windows nicht geht. So ein Unsinn.
Wie sieht man denn unter Windows welche Treiber geladen sind, von welchen Applikationen sie verwendet werden und vor allem, wie entlade ich unter Windows einen nicht benötigten Treiber? Wenn ich also Unsinn geschrieben habe, dann kläre mich bitte auf.
Liest man die Beschreibung dieses Programms eines Drittherstellers wird deutlich, dass man die Treiber, welche in der Tat angezeigt werden, lediglich aus der Registry löschen kann. Damit wird der Treiber aber keineswegs beendet oder gar aus dem Kernel entfernt (Treiber können maximal inaktiv gesetzt werden). Erst beim nächsten Reboot wird er dann nicht mehr geladen, weil ja nicht mehr in der Registry. Für eine Spielkonsole ist das durchaus ausreichend <scnr>.
Ich gehe natürlich davon aus, dass du den Unterschied zwischen einem Service und einem Treiber kennst.
" This was designed as a modified microkernel, as the Windows NT kernel does not meet all of the criteria of a pure microkernel. Both the kernel and the executive are linked together into the single loaded module ntoskrnl.exe; "
Bis XP lief sogar der ganze GUI Kram im System selbst. Hat sich erst bei Vista geaendert.
Und schön zu sehen, dass Linux gedeiht und wächst!
also z.B. 2.1.x, 2.3.x und 2.5.x
man kann über die Zeit aber schon beobachten, dass sich Kernel mit mehr oder weniger intensiven Änderungen abwechseln. Nach einem langwierigen Kernel versucht Linus eher einen schnellen zu machen, und dann wird der nächste automatisch länger.
Mit Stabilität hat das aber Nichts zu tun. Die stabilen Kernel sind jetzt 2.6.x.y mit y > 0 und möglichst hoch.
Einen richtigen vollen Entwicklungszyklus (das an den Urheber des Threads) gibt es garnicht mehr. Die hohe Rate an Änderungen erlaubt es nicht mehr, nur alle paar Jahre massive Änderungen zu machen. Dafür passieren jetzt bei jedem Release massive Änderungen und davon immer mehr in immer kürzerer Zeit.
Bin gespannt, wie sehr sich der Kernel noch in seiner Entwicklung beschleunigen wird. Schon jetzt gibt in jeder Minor mehr Änderungen und neue Features als zum Teil in grossen Versionen anderer Kernel. Alleine das Lesen der Änderungen bei kernelnewbies dauert ja schon Stunden.
Gruss,
Kay
Man munkelt, in 2.5.x seien die Nummern in der dritten Stelle ausgegangen und so ist auch 2.6.x jetzt "unstable"...
Hrrr hrr hrrrrrr
ist. Vermute, dass hat was mit dem Snapshotting zu tun.
Der Omega13.
http://bugzilla.kernel.org/show_bug.cgi?id=12435
Der Omega13.
Schade ist allerdings, dass Pro-Linux und andere einschlaegigen Nachrichtenseiten nicht ueber die Fortschritte berichten. Daher kann ich jedem, der sich fuer Wayland und Kernelmodelines interessiert, den Blog des Entwicklers ans Herz legen.
Hast Du auch einen Link zum Blog?
Ich bin leider auf Xen angewiesen, da der zu virtualisierende Rechner keine Virtualisierungsunterstützung in den CPUs besitzt (alte Opterons von gaaanz früher
).
Gruß, LX
Halleluja!
lg
Erik
lg
Erik
kann mir das mal jemand kurz erklären?
Ist es so, dass der Linux-Kernel immer größer werden muss, weil immer mehr Treiber integriert werden?
Stimmt es, dass es einen grundsätzlichen Unterschied zwischen dem Win- und Lin-Kernel bezüglich seines Aufbau gibt? Ich habe mal gehört, dass einer von beiden ein modularer Kernel wäre, also nur bei Bedarf Dinge (Treiber) hinzugefügt werden, während sie bei dem anderen komplett integriert sind. Angeblich soll der Lin-Kernel da Nachteile haben.
Danke!
Richtig ist:
- Man kann den Linuxkernel monolitisch kompilieren, d.h. so dass alle module direkt im Kernel sind und auch beim Start geladen werden. Das macht aber (mir bekannte) keine Distribution und ist so auch recht sinnlos. Vorteilhaft ist es natürlich Treiber direkt in den Kernel einzubinden die man auf jeden Fall braucht (z.b. Dateisystemtreiber). Andere Treiber (Audio, Drucker, serielle Modems, pppoe-Modems) sind bei Linux weitgehend außerhalb des Kernels (also z.b ist nur der Parallelport-treiber und der usb-Treiber im Kernel, die Befehle für den Drucker werden über einen Dämon bereitsgestellt der im userspace läuft). Mit FUSE gibt es auch eine Schnittstelle die es sogar erlaubt Dateisystem außerhalb des Kernels zu implementieren. Generell würde ich daher sagen, der Linuxkernel lagert mehr Funktionalität aus als Windows. Das hat allerdings nichts mit Modularität zu tun, denn Module sind imho Teil des Kernels (laufen NICHT im userspace). Wieviel Modularität man für sinnvoll hält kann jeder Anwender / Distributor beim Kompilieren des Linuxkernels selber entscheiden.
Wenn alles einkompiliert wird, kann man das Zeug zum Modulladen rausschmeissen.
Da der Quellcode zur Verfuegung steht kannst du dir den gesammten Code runterladen und dann einfach beim Kompilieren die Treiber/Features entfernen die du nicht brauchst. Dadurch erhaellst du einen sehr speziellen und schlanken Kernel der alles dabei hat was deine Hardware hergibt. Fuer Arch Linux kannst du dir z.B. einen speziellen Kernel fuer den Aspire One Netbook aus AUR herunterladen.
Ein weiterer Vorteil ist natuerlich, dass ein Treiber gleich eine gesammte Hardwarefamilie ansprechen kann, im Gegensatz zu Windows, da dort man fuer jede Hardware einen neuen Treiber installieren muss. Dies ist ein plus fuer die Kernelgrosse und vor allem fuer die Sicherheit und Stabilitaet.
Es ist immer lustig auf heise.de die Trolle zu lesen, die behaupten das der Kernel immer grosser und groesser wird. Das stimmt nur fuer den gesammten Code des Kernels, aber die Distributoren lassen ja dann alte Treiber, selten benutze Faehigkeiten, usw. weg, so dass fuer den Endbenutzer der Kernel eigentlich in der Groesse gleich bleibt.
mehr auspassen und wissen, was sich kombinieren laesst und wie.
Der Linux Kernel versteht schon von alleine die nötigen Module selbstständig reinzuladen.
Bin ich der einzige der mehr Zeit damit verbringt Treiber unter Windows zu installieren, als unter Linux?
Es muß darum gehen, den Massenmarkt zu erreichen und da ist die Mehrheit nunmal gerade in der Lage mit einem System wie Windows eiigermaßen umzugehen, von tieferem Verständnis nicht erst zu reden. Dazu den Quellcode anzugucken, make anzustoßen o.ä. sind 99,9% der Mitbürger zu doof oder zu desinteressiert. Die Möglichkeit den Quellcode anzugucken, ist im Rahmen ihrer Möglichkeiten, für fast alle irrelevant. Und von dieser Warte ist der monolithische Kernel ein echtes Problem: Ein niegelneues Gerät funktioniert nicht oder nur eingeschränkt, weil keine Treiber-CD für Linux dabeiliegt, ein halbwegs passabler Treiber erst nach Monaten in einen neuen Linux-Kernel einzug hält. Das ist aus Benutzersicht inakzeptabel.
Linux hat - ein bisschen optimistisch ausgedrückt - vielleicht Software-Turnaround-Zeiten von wenigen Monaten (bis die nächste Distro draußen ist).
Wenn jeder Hardware-Hersteller _rechtzeitig_ (also mit anderen Worten, __gleichzeitig__ mit der Windows-Treiber-Entwicklung) Treiber-Support für Linux bereitstellen würde, dann wäre das ruckzuck im Zuge der allgemein durchgeführten Entwicklungsschritte bei Linux beim Endanwender aufgeschlagen.
Das Problem ist aber, dass Firmen das nicht machen. Und genau das ist es, sonst nix.
> Linux hat - ein bisschen optimistisch ausgedrückt - vielleicht Software-Turnaround-Zeiten von wenigen Monaten (bis die nächste Distro draußen ist).
Bis die Bananaware-Treiber im Kernel gereift sind, dauert es in manchem Fall Jahre, das eine oder andere spezielle Feature einer Hardware funktioniert nie oder nur fehlerhaft. Großartig. Und nein: Selbst wenn Treiber in einem neuen Kernel gefixt werden, heißt das in einer riesigen Anzahl von Anwendungsfällen (von Joe-User-Gadgets bis zu zertifizierten Systemen), daß das Einspielen neuer Kernel akzeptabel ist.
Warum?
Ganz einfach: weil Linux wesentlich weniger bloatige Treiber-Spielchen betreibt (u.a. durch wesentlich zentraler implementierte Funktionalität, die von mehreren Treibern genutzt werden kann).
Bei einem Treiber kommt es überwiegend auf die Kern-Funktionalität an, schmückendes Beiwerk oder Bloat ist häufig gar nicht sonderlich erwünscht.
Wenn ich sehe, dass man für einen einzigen "Treiber" bei Windows manchmal 37, 40, 45 MB ziehen muss, dann ist das schon fast lachhaft. Soviel Platz haben früher noch nicht einmal ganze Rechenzentren belegt.
Natürlich mögen bei einem sehr großen Treiberpackage noch viele Desktop-Gehilfen dabei sein, das ist sehr sinnvoll, aber Bloat ist da so oder so ziemlich viel dabei.
Und wozu brauch ich bei einem Treiber einen _herstellerspezifischen_ "Installer", der ungefähr so 58% der Gesamt-Packagegröße ausmacht (wenn man Glück hat)? Bloat, Bloat, Bloat... echte Betriebssysteme brauchen keine kunterbunte Mischung aus Treiber-"Installern".
Nur Linux ist ein monolitischer Kernel. Windows besteht im wesentlichem aus einem Microkernel, was die Sache aber keineswegs besser macht. Unter Windows werden nicht nur die reinen Treiber in den Kernel geladen, sondern auch noch das grafische Beiwerk, um die Hardware administrieren zu können (die grafische Oberfläche ist ja Teil des Betriebssystems). Da laufen dann z.B. die Programme zum Einstellen einer Grafikkarte mit Systemrechten (höher als der User Administrator!) und enthaltene Fehler schaffen so nicht nur Sicherheitsprobleme, sondern vor allem Instabilitäten.
Unter Linux kann man die meisten Treiber zwar direkt in den Kern compilieren, zumeist wird aber so ziemlich alles als Modul compiliert. Abhängig von der vorhandenen Hardware, werden dann nur die jeweiligen Treiber geladen, die benötigt werden. Das geschieht zumeist ohne das Zutun des Anwenders und versteckt im Hintergrund. Zu dem kann ein Treiber, sonfern er von keinem Anwendungsprogramm benötigt wird, auch während des Betriebs entladen werden. Etwas, das bei Windows nicht geht. Windows ist sogar so schlimm, dass alle installierten Treiber beim Starten immer geladen werden, unabhängig davon, ob die entsprechende Hardware vorhanden ist oder nicht. Da sind Probleme dann vorprogrammiert.
Unter Linux stehen entsprechende Hilfsmittel bereit um genau überprüfen zu können, welche Treiber geladen sind und ob, bzw. von welcher Anwendung sie verwendet werden. Unter Windows kann das, wenn überhaupt, nur unvollständig ermittelt werden (ist Windows erst einmal kaputtkonfiguriert, muss man es neu installieren).
Nun kann man natürlich über die verwendeten Konzepte streiten, aber Fakt ist, dass Windows in jeder Hinsicht das genaue Gegenteil von Linux oder *NIX ist. Oder kurz gesagt: Windows ist unbrauchbar!
A.T.
> Etwas, das bei Windows nicht geht.
So ein Unsinn.
lg
Erik
Wie sieht man denn unter Windows welche Treiber geladen sind, von welchen Applikationen sie verwendet werden und vor allem, wie entlade ich unter Windows einen nicht benötigten Treiber? Wenn ich also Unsinn geschrieben habe, dann kläre mich bitte auf.
A.T.
lg
Erik
Ich gehe natürlich davon aus, dass du den Unterschied zwischen einem Service und einem Treiber kennst.
A.T.
http://en.wikipedia.org/wiki/Windows_NT#Development
"
This was designed as a modified microkernel, as the Windows NT
kernel does not meet all of the criteria of a pure microkernel.
Both the kernel and the executive are linked together into the
single loaded module ntoskrnl.exe;
"
Bis XP lief sogar der ganze GUI Kram im System selbst.
Hat sich erst bei Vista geaendert.
Der Omega13.