sind SuSE, Mandrake oder Nutzer einer anderen kommerziellen Distri, und werden sich (vernünftigerweise) schwer hüten ein Kernelupdate ihrer optimierten Kernel mit dem Original zu machen.
Außerdem können die allermeisten das auch garnicht nicht. - Was nicht über die diversen Updatefunktionen wie z.B. SuSE-Updater kommt und automatisch installiert wird, ist fast durchweg ein Buch mit 7 Siegeln für diese Nutzergruppe.
Der größere Teil der Linux-Nutzer ist auf seinem System also genau so ein DAU, wie die Mehrheit der Windows-Nutzer das auf ihrem System sind.
> sind SuSE, Mandrake oder Nutzer einer anderen kommerziellen Distri, und werden sich (vernünftigerweise) schwer hüten ein Kernelupdate ihrer optimierten Kernel mit dem Original zu machen.
Wenn er denn wirklich optimiert ist. Manche Distributionen setzen mittlerweile auf den USB Low Performance Block Driver, der meinen USB-Stick nicht erkennt. Da ist eine Rekompilierung des Kernels quasi Pflicht.
Solange das System stabil läuft und es alle Dinge erledigt die sie jeden Tag zum Arbeiten brauchen, kann es ihnen Sch**ßegal sein ob sie sich damit auskennen oder nicht. Und für Probleme gibt es den netten "Computerexperten" in der Nachbarschaft!
Da empfehle ich den Trottelusern doch das trottelsichere Libranet, das hat in seinem Adminmenü sogar eine GUI zum Kernel- und Modulebacken, ansonsten ist es 100% Debian kompatibel, sozusagen ein Debian mit einem richtig guten Konfigurationstool und einem gediegenen Installer (hat Debian ja jetzt zwar auch ...)
Also, man kann es auch einfach haben, man muß nur wissen, wo man zu suchen hat ... nur muß man vorher noch wissen, warum man einen Kernel kompilieren sollte und was ein Kernel überhaupt ist. Ich sage dann immer, lösch mal die kernel32.dll aus dem Windows-Systemordner, die macht eh immer nur Probleme, und dann weißt Du was ein Kernel ist, har har ...
> Ich sage dann immer, lösch mal die kernel32.dll > aus dem Windows-Systemordner, die macht eh immer > nur Probleme, und dann weißt Du was ein Kernel > ist, har har ...
Du scheinst es jedenfalls nicht zu wissen, was ein Kernel ist. Kleiner Tipp: kernel32.dll ist es nicht. ;)
Eines habe ich doch glatt vergessen, was hier mal wieder hinpasst: Weder die kernel32.dll noch die ntoskrnl.exe müssen für die Unterstützung von zusätzlichen Netzwerkchips neu kompiliert werden. Tja, es hat halt doch seine Vorteile, eine funktionierende Hardwareabstraktionsschicht, stabile Schnittstellen und das saubere Design eines VMS-Klons zu haben. Aber wahrscheinlich wird jetzt wieder gekontert, dass es gut sei, dass man den Kernel regelmäßig neu kompilieren muss, wegen der sog. Vielfalt und der sog. Freiheit. Kleiner Tipp dazu: Es ist ja wirklich wunderbar, dass man es kann, im Idealfall sollte man es aber wirklich nur können und nicht müssen. Das ist kein Widerspruch, ganz im Gegenteil, auch wenn es möglicherweise nicht in den Kram passt.
Nein, die kernel32.dll ist es nicht, es ist eine dynamic link library, wie die Endung ja sagt, aber wenn diese fehlt, stellt sich der Kernel beim User persönlich vor ...
Und keiner muß einen neuen Kernel kompilieren, wenn er einfach ein Modul im laufenden Betrieb dazuladen kann. Wäre nur eben zu schön, wenn mehr Hersteller mal Treibermodule bereitstellten ...
> Und keiner muß einen neuen Kernel kompilieren, > wenn er einfach ein Modul im laufenden Betrieb > dazuladen kann.
Tja, nur muss dieses Modul leider ganz genau zum Kernel passen und für genau den Kernel kompiliert werden, mit dem es benutzt werden soll. Also immer schön beim Distributor die genau passenden Kernelquellen suchen, genau passend konfigurieren und genau passend kompilieren, sonst geht gar nichts.
Die aktuelle Version von VMWare unter SuSE 9.1 nutzen? Vergiss es. Die vorletzte Version von VMWare unter SuSE 9.3 nutzen? Vergiss es. Die aktuelle Version von VMWare unter Windows 2000 nutzen? Kein Problem. Die vorletzte Version von VMWare unter Windows 2003 nutzen? Kein Problem.
> Wäre nur eben zu schön, wenn mehr Hersteller > mal Treibermodule bereitstellten ...
Kein Wunder, dass viele Hersteller es nicht gerne tun, wenn ein für Kernel 2.6.9 erstelltes Modul mit Kernel 2.6.10 nicht mehr geht, was leider viel zu oft passiert. Wirklich binärkompatible Schnittstellen wären doch mal was feines, aber wenn man das Thema anspricht, kommen leider zuviele Zealots an und sind dagegen, weil dies die Hersteller ja davon abhalten könnte, ihr Eigentum unter die GPL zu stellen...
reicht es nicht für den kernel.org kernel das modul zu bauen ... und seit ndiswrapper könnten viele hersteller mit minimalaufwand linuxunterstützung herbeizaubern ohne ihren treibercode auf den tisch zu legen, einfach als freeware rausgeben und vielleicht minimal anpassen ...
win4lin hat eine möglichkeit gefunden mit dem kernelzoo klar zu kommen, nicht wenige distros sind sogar schon für win4lin vorbereitet, installieren, fertig. wenn vmware da probleme hat haben sie eben nur die zweitbeste lösung am start.
Ich weiß nicht was du für ein Problem hast. VMWare hat bei mir bis jetzt noch mit jedem Kernel funktioniert. Auch die NV-Treiber laufen seit Jahren Problemlos. Natürlich muß man die Kernelschnittstellen für jeden Kernel neu kompilieren. Aber ist das wirklich so schwer?
> Wirklich binärkompatible Schnittstellen wären doch mal was feines, aber wenn man das Thema anspricht, kommen leider zuviele Zealots an und sind dagegen, weil dies die Hersteller ja davon abhalten könnte, ihr Eigentum unter die GPL zu stellen...
Es ist einfach praktisch nicht durchführbar, da schon unterschiedliche Compilerversionen unterschiedliche ABIs erzeugen. Das Problem ist also historisch gewachsen. Man kann den Leuten halt keinen fest definierten Kernel mit einem ganz bestimmten Compiler vorschreiben. Unter Windows werden die Treiber alle mit dem MS C++ Compiler kompiliert und MS wird sich natürlich hüten, was an der Binärschnittstelle zu ändern.
Übrigens gibts dafür bei Windows das Problem, dass viele Hersteller bis heute nicht geschnallt haben, dass Windows mittlerweile auch multiuserfähig ist, und bis heute noch Win 3.11-like programmieren.
Bestes Beispiel: Unreal Tournament in allen Versionen. Die Windows-Version installiert sich z.B. in C:\UT2004. Selbst die Einstellungen und Savegames landen dort, d.h. es kann quasi nur einer am PC dieses Spiel spielen. Der andere würde ihm die Konfiguration durcheinander bringen, wenn er ne andere Tastenbelegung bevorzugt. Die Linux-Version war von Anfang an multiuserfähig, d.h. Einstellungen und Savegames landen in ~/.ut2004.
Es gibt für Linux auch deshalb keine stabilen ABI's weil die Entwickler von Linux dadurch den enormen Vorteil der Flexibilität bekommen. D.h. sie können die momentanen Schnittstellen komplett über den Haufen werfen wenn sie müssen, ein Luxus den ein Windows-Entwickler nicht hat. Das ist mit ein Grund warum sich die Lonhorn-Programmierer so schwer tun. Alles muß binär-kompatibel bleiben, das erschwert es enorm eine optimale Lösung für ein neues Feature zu finden. Linux bricht hin und wieder (kommt ja trotzdem selten vor) mit der Rückwärtskompatibilität, dann müssen eben alle Programme neu compiliert werden. Nachdem Software zunehmend Service-orientiert ist, ist das üblicherweise auch kein Problem.
Ich benutze tatsächlich Libranet 2.81 seit einigen Wochen und es ist trotz einiger Zicken bis jetzt das beste Linux, was mir bislang unter die Finger gekommen ist. Bin ich deswegen jetzt ein "Trotteluser"? Was soll das? Aber mal eine andere Frage: Wird der Linux-Kernel nicht durch die AMD-64-Unterstützung sehr aufgebläht? Kann man die beim Selbstkompilieren ausschalten?
Oh nein, das bist Du NICHT. Ich habe mir gerade die LN 3.0 bestellt, und was ich gelesen habe vom Adminmenü ist, daß damit auch ein "Trotteluser" einen Kernel backen kann. Also genau das richtige für mich ... und gut zu hören, daß da jemand mit der 2.8.1 zufrieden ist ...
Wieso kompliziert wenn es auch einfach geht, wieso 120 Kommandozeilenbefehle memorisieren, wenn ich sie besser aus einer gut gemachten GUI ablesen kann. Das war also keinesfalls diskreditierend gemeint. Und ja, mit Sicherheit kann man die AMD64 Unterstützung abschalten, ich wäre mir aber nicht sicher, ob man sie denn, wenn man sie braucht nicht EINCHALTEN muß, d.h. daß diese per default eh nicht aktiviert ist. Die Mehrheit der User hat ja auch noch keinen 64er ...
> Aber mal eine andere Frage: Wird der Linux-Kernel nicht durch die AMD-64-Unterstützung sehr aufgebläht? Kann man die beim Selbstkompilieren ausschalten?
Wozu? Entweder verwendest du ne 64-Bit-Distribution mit 64-Bit-Kernel. Dann brauchst du eh AMD64-Unterstützung, sonst läuft da keine 64-Bit-Software drauf. Oder du verwendest ne 32-Bit-Distribution mit 32-Bit-Kernel. Der 32-Bit-Kernel hat ohnehin keine AMD64-Unterstützung, weil er eben nur 32-Bit kann.
Fragt sich halt auf was die optimieren? Ich bin mir sicher auf Verkaufszahlen, ist nun mal eine Firma, dank Novell noch viel mehr. Dann kann das Ding *NIE* stabil sein. Punktaus. Wer anderes schreibt, lügt.
Aus meiner langjährigen Erfahrung als Unternehmensberater, der auch bei IT-Einführungen tätig war, weiß ich, das ECHTE Experten soviel Ahnung haben, dass sie es nicht nötig haben, sich über Anwender lustig zu machen. Die Art und Weise, wie du hier die Anwender verurteilst, lässt auf die übliche Profilierungsneurose im IT-Bereich schließen. Wenn schon nicht das schnellere Auto oder mehr Geld, hat man doch zumindest dadurch den Längsten, dass man mehr über Linux weiß als andere.
Linux 2.0 ist auch noch nicht eingestellt sondern wird von David Weinehall noch weiter gepflegt. Die aktuelle Version ist 2.0.40 von vor etwa einem Jahr. David hat mal in einem Interview geschrieben, er plane, dass die Releasezyklen nach und nach immer länger würden, so dass dann zu Ehren von Douglas Adams 2.0.42 das letzte Release wäre. Ob er diesen Plan umsetzen kann, wird sich noch zeigen (-;
und werden sich (vernünftigerweise) schwer hüten ein Kernelupdate ihrer
optimierten Kernel mit dem Original zu machen.
Außerdem können die allermeisten das auch garnicht nicht. - Was nicht über
die diversen Updatefunktionen wie z.B. SuSE-Updater kommt und automatisch
installiert wird, ist fast durchweg ein Buch mit 7 Siegeln für diese
Nutzergruppe.
Der größere Teil der Linux-Nutzer ist auf seinem System also genau so ein DAU,
wie die Mehrheit der Windows-Nutzer das auf ihrem System sind.
Immerhin aber, sind jetzt beide schön bunt.
Sebastian.
Wenn er denn wirklich optimiert ist. Manche Distributionen setzen mittlerweile auf den USB Low Performance Block Driver, der meinen USB-Stick nicht erkennt. Da ist eine Rekompilierung des Kernels quasi Pflicht.
You made my day
Solange das System stabil läuft und es alle Dinge erledigt die sie jeden Tag zum Arbeiten brauchen, kann es ihnen Sch**ßegal sein ob sie sich damit auskennen oder nicht. Und für Probleme gibt es den netten "Computerexperten" in der Nachbarschaft!
Welcher Nachbar kennt sich schon mit Linux aus.
Kernel,was ist denn das?
Also, man kann es auch einfach haben, man muß nur wissen, wo man zu suchen hat ... nur muß man vorher noch wissen, warum man einen Kernel kompilieren sollte und was ein Kernel überhaupt ist. Ich sage dann immer, lösch mal die kernel32.dll aus dem Windows-Systemordner, die macht eh immer nur Probleme, und dann weißt Du was ein Kernel ist, har har ...
> aus dem Windows-Systemordner, die macht eh immer
> nur Probleme, und dann weißt Du was ein Kernel
> ist, har har ...
Du scheinst es jedenfalls nicht zu wissen, was ein Kernel ist. Kleiner Tipp: kernel32.dll ist es nicht. ;)
[Zaunpfahl]ntoskrnl.exe[/Zaunpfahl]
Und keiner muß einen neuen Kernel kompilieren, wenn er einfach ein Modul im laufenden Betrieb dazuladen kann. Wäre nur eben zu schön, wenn mehr Hersteller mal Treibermodule bereitstellten ...
> wenn er einfach ein Modul im laufenden Betrieb
> dazuladen kann.
Tja, nur muss dieses Modul leider ganz genau zum Kernel passen und für genau den Kernel kompiliert werden, mit dem es benutzt werden soll. Also immer schön beim Distributor die genau passenden Kernelquellen suchen, genau passend konfigurieren und genau passend kompilieren, sonst geht gar nichts.
Die aktuelle Version von VMWare unter SuSE 9.1 nutzen? Vergiss es. Die vorletzte Version von VMWare unter SuSE 9.3 nutzen? Vergiss es. Die aktuelle Version von VMWare unter Windows 2000 nutzen? Kein Problem. Die vorletzte Version von VMWare unter Windows 2003 nutzen? Kein Problem.
> Wäre nur eben zu schön, wenn mehr Hersteller
> mal Treibermodule bereitstellten ...
Kein Wunder, dass viele Hersteller es nicht gerne tun, wenn ein für Kernel 2.6.9 erstelltes Modul mit Kernel 2.6.10 nicht mehr geht, was leider viel zu oft passiert. Wirklich binärkompatible Schnittstellen wären doch mal was feines, aber wenn man das Thema anspricht, kommen leider zuviele Zealots an und sind dagegen, weil dies die Hersteller ja davon abhalten könnte, ihr Eigentum unter die GPL zu stellen...
win4lin hat eine möglichkeit gefunden mit dem kernelzoo klar zu kommen, nicht wenige distros sind sogar schon für win4lin vorbereitet, installieren, fertig. wenn vmware da probleme hat haben sie eben nur die zweitbeste lösung am start.
Auch die NV-Treiber laufen seit Jahren Problemlos. Natürlich muß man die Kernelschnittstellen für jeden Kernel neu kompilieren. Aber ist das wirklich so schwer?
mohikaner
Es ist einfach praktisch nicht durchführbar, da schon unterschiedliche Compilerversionen unterschiedliche ABIs erzeugen. Das Problem ist also historisch gewachsen. Man kann den Leuten halt keinen fest definierten Kernel mit einem ganz bestimmten Compiler vorschreiben.
Unter Windows werden die Treiber alle mit dem MS C++ Compiler kompiliert und MS wird sich natürlich hüten, was an der Binärschnittstelle zu ändern.
Übrigens gibts dafür bei Windows das Problem, dass viele Hersteller bis heute nicht geschnallt haben, dass Windows mittlerweile auch multiuserfähig ist, und bis heute noch Win 3.11-like programmieren.
Bestes Beispiel: Unreal Tournament in allen Versionen.
Die Windows-Version installiert sich z.B. in C:\UT2004. Selbst die Einstellungen und Savegames landen dort, d.h. es kann quasi nur einer am PC dieses Spiel spielen. Der andere würde ihm die Konfiguration durcheinander bringen, wenn er ne andere Tastenbelegung bevorzugt.
Die Linux-Version war von Anfang an multiuserfähig, d.h. Einstellungen und Savegames landen in ~/.ut2004.
Linux bricht hin und wieder (kommt ja trotzdem selten vor) mit der Rückwärtskompatibilität, dann müssen eben alle Programme neu compiliert werden. Nachdem Software zunehmend Service-orientiert ist, ist das üblicherweise auch kein Problem.
Aber mal eine andere Frage: Wird der Linux-Kernel nicht durch die AMD-64-Unterstützung sehr aufgebläht? Kann man die beim Selbstkompilieren ausschalten?
Viele Grüße, Ludwig
Wieso kompliziert wenn es auch einfach geht, wieso 120 Kommandozeilenbefehle memorisieren, wenn ich sie besser aus einer gut gemachten GUI ablesen kann. Das war also keinesfalls diskreditierend gemeint. Und ja, mit Sicherheit kann man die AMD64 Unterstützung abschalten, ich wäre mir aber nicht sicher, ob man sie denn, wenn man sie braucht nicht EINCHALTEN muß, d.h. daß diese per default eh nicht aktiviert ist. Die Mehrheit der User hat ja auch noch keinen 64er ...
Wozu? Entweder verwendest du ne 64-Bit-Distribution mit 64-Bit-Kernel. Dann brauchst du eh AMD64-Unterstützung, sonst läuft da keine 64-Bit-Software drauf.
Oder du verwendest ne 32-Bit-Distribution mit 32-Bit-Kernel. Der 32-Bit-Kernel hat ohnehin keine AMD64-Unterstützung, weil er eben nur 32-Bit kann.
Fragt sich halt auf was die optimieren? Ich bin mir sicher auf Verkaufszahlen, ist nun mal eine Firma, dank Novell noch viel mehr. Dann kann das Ding *NIE* stabil sein. Punktaus. Wer anderes schreibt, lügt.
Du hast SUSE mit Sicherheit nicht im Einsatz. Sonst würdest du nicht so einen Müll schreiben.
mohikaner
<>
Linux 2.0 ist auch noch nicht eingestellt sondern wird von David Weinehall noch weiter gepflegt. Die aktuelle Version ist 2.0.40 von vor etwa einem Jahr. David hat mal in einem Interview geschrieben, er plane, dass die Releasezyklen nach und nach immer länger würden, so dass dann zu Ehren von Douglas Adams 2.0.42 das letzte Release wäre. Ob er diesen Plan umsetzen kann, wird sich noch zeigen (-;
jwm