-
Nachteile von Monolitismus
Autor: AromorApp 19.02.10 - 17:14
Alles was in den Kernel soll, ist von der Gnade der Türsteher abhängig.
Von daher wäre schöner, wenn schmalbandige Dinge wie Drucker, Scanner, alle Bluetooth-Geräte und die meisten USB-Geräte-Sorten usw. besser über /dev/ bzw. /udev/-Einträge ihre Treiber für SMS-Versand mit dem Handy realisieren, als unbedingt Kernel-Treiber haben zu müssen.
Beim Drucken dürfte die Performance eines "user-mode"-Treibers in den meisten Fällen nicht gerade relevant sein.
Davon abgesehen wären Kernel-Spezial-Teams sinnvoll, die immer nur bestimmte Dinge überprüfen. Buffer overflows, memory lecks, gängige Fehler. Andere Teams aber z.b., das alle Treiber dieses LSM benutzen, wie es gedacht ist. -
Re: Nachteile von Monolitismus
Autor: Soulreaver 19.02.10 - 17:46
Sehe ich genau so, allerdings weiß ich auch nicht ob das ganze einen Guten Grund hat dass es nicht so ist....
Gruß -
Re: Nachteile von Monolitismus
Autor: Kinch 19.02.10 - 18:31
> Alles was in den Kernel soll, ist von der Gnade der Türsteher abhängig.
Wie muss ich mir das an einem Mikrokernel vorstellen? Jeder darf da Komponenten hinzufügen, die dann ausgeliefert werden?
> Davon abgesehen wären Kernel-Spezial-Teams sinnvoll,
Wie ist es denn im Moment? -
Re: Nachteile von Monolitismus
Autor: Sharra 19.02.10 - 18:38
Naja derzeit entscheidet eine kleine feine "Elitetruppe" darüber was wann und wie in den Kernel darf. Und da geht es mitnichten immer nur nach Fakten.
Aber warum muss eigentlich jeder Schrott direkt in den Kernel?
Wenn es allgemeingebräuchlich ist seh ich das noch ein (Dateisysteme ect) aber exotisches kann man genausogut als Modul einbinden. -
Re: Nachteile von Monolitismus
Autor: Kinch 19.02.10 - 18:56
> Naja derzeit entscheidet eine kleine feine "Elitetruppe" darüber was wann
> und wie in den Kernel darf. Und da geht es mitnichten immer nur nach
> Fakten.
Also dazu kann man zum einen sagen: Jeder ist frei den Kernel zu forken und seine Änderungen selbst an den Mann zu bringen, oder für sich einzusetzen. Was auch oft genug getan wird.
Zum anderen: Wie soll das anders Funktionieren? So wie ich das sehe muss bei einem Projekt dieser Größe jemand Entscheiden, was aufgenommen wird und was nicht. Mir fällt spontan kein Projekt ein, bei dem jeder nach gutdünken alles reincoden kann.
> Aber warum muss eigentlich jeder Schrott direkt in den Kernel?
> Wenn es allgemeingebräuchlich ist seh ich das noch ein (Dateisysteme ect)
> aber exotisches kann man genausogut als Modul einbinden.
Also Module werden ja durchaus genutzt. Der Unterschied zwischen einem Modul in einem Microkernel und in einem monolithischen Kernel ist nur, dass das Modul nicht in einem eigenen Prozess läuft. Beides hat Vor- und Nachteile; aber an der Strukturierung des Projekts ändert sich imho wenig. -
Re: Nachteile von Monolitismus
Autor: BT90 19.02.10 - 18:59
Weiß der Startposter eigentlich was Monotilismus bedeutet oder
hat er sich nur n Aufhänger für seinen,ich nenns mal Trollpost,gesucht?
Diese elitäre Gruppe ist gut wie sie ist und wenn man die Einwände
gegen die Aufnahme durchgelesen hätte,würde man diesen phösen Leuten
Recht geben.
Und dieses ausgliedern aus dem Kernel Bereich ist auch nicht grade
die eleganteste Lösung,da es schnell zu Rechteproblemen kommen kann. -
Re: Nachteile von Monolitismus
Autor: App Armor 19.02.10 - 19:22
Warum soll Ausgliedern mehr oder weniger Rechteprobleme geben als im Kernel ?
Samba läuft als Daemon. Hat es weniger Rechte, wenn es ein Kernel-Modul wäre ?
Und das Auslagern gibt es faktisch schon lange: Scanner und Drucker beispielsweise.
Und bei vielen USB_Geräten würde sich das auch anbieten.
pppd der die Einwahl macht, läuft als eigener Prozess. Darüber läuft die gesamte Internet-Connektivität. Nimm Dir daran mal ein Beispiel, das Auslagern doch oft einfacher geht, als irgendwelche Leute behaupten.
Wieso soll es keinen USB-Stick-Daemon geben ?
usb-storage läuft dann dort drin und er implementiert /dev/usb-stick-1 . Ein Block-Device.
Sowas wie ein FUSE-daemon benutzt dann /dev/usb-stick-1 und memmory-mapped es beispielsweise in seinen Speicher. Darauf implementiert es dann /dev/usbstick1a /dev/usbstick2b usw.
Es geht hier nicht um einen Micro-Kernel. Sondern darum, das Dinge die keine niedrige Latenz und/oder hohe Bandbreite brauchen oder auf die Hardware poken müssen, genau so gut über die vielen vorhandenen Bus_Systeme gehen können. Dann kann man das aber als Interface festlegen und eine Kiste drumherum packen und es auslagern.
Ach und wegen Microkernel: Bei OS/9 wurde Module in den Speicher gemappt bzw. waren im Rom und das im Speicher. Der Loader hat nach einen "NOP"-Opcode gesucht bzw. Magic-FileNumber und dann geschaut ob die Prüfsumme stimmte und dann war das Modul "drin". Ob es benutzt wurde, war dann eine andere Sache. zur Initialisierung weiss ich nichts.
Diese Embedded und Mikrokernelcoder haben schlauere Sachen drauf, als die etepetete wir machen alles mit C++-hyper die sich nur für was besseres halten und mischmasch-spaghetti-OO-Code liefern und gerne alles delegieren wie Stromberg im Büro und keiner weiss, wer die Arbeit macht.
"delegieren" ist ein wichtiges OO-Prinzip... .
Und bei PLAN9 wurden keine Memory-Bereiche kopiert so wie es bei Unix üblich ist, sondern "abgegeben". Linux ist durch "copy on write" natürlich effizienter aber nur so mal als Info, das andere Methoden durchaus machbar sind.
Und warum der grafikkarten-treiber auf den strukturen der soundkarte herum-poken sollen kann, kann hier auch keiner erklären.
Monolitisten sind die Leute, die dann aber selber im modularen PKW fahren und nicht im monolitistischen Linien-Bus.
"Aber dann muss doch jeder ein Auto selber kaufen und 90% der Zeit steht es nur auf dem Parkplatz herum" usw. wären die Argumente.
Wer für monolithische Kernels ist, muss auch Linienbus fahren. -
Re: Nachteile von Monolitismus
Autor: Ano Nymus 19.02.10 - 20:07
App Armor schrieb:
--------------------------------------------------------------------------------
> Wieso soll es keinen USB-Stick-Daemon geben ?
> usb-storage läuft dann dort drin und er implementiert /dev/usb-stick-1 .
> Ein Block-Device.
> Sowas wie ein FUSE-daemon benutzt dann /dev/usb-stick-1 und memmory-mapped
> es beispielsweise in seinen Speicher. Darauf implementiert es dann
> /dev/usbstick1a /dev/usbstick2b usw.
Das >könnte< man so machen ja. Aber ich würde es so nicht haben wollen. Warum? Stell dir mal vor für jeden hardwäre typ würde ein Daemon laufen... wohin soll denn das führen? In einen Bootvorgang der ne stunde dauert, weil man 300 daemons starten lassen muss? Im moment laufen bei mir folgende Daemons: syslog-ng hal (dbus) mpd boinc. Auf HAL und Dbus könnt ich theoretisch verzichten, aber ein bischen Komfort gönnt man sich eben doch...
Also die Treiber-Politik des Linux-Kernels finde ich bisher vollkommen in Ordnung. Man sollte allerdings (wie im WLAN-zweig) versuchen mehr Treiber zusammen zulegen (beispeil: rt28X0), damit es nicht allzuviele einzeltreiber werden. Aber eine Windows-Artige lösung ("yo, lad dir mal den und den und den und den und den und den und den treiber, den hab ich nähmlich nich dabei") will ich nicht. Und alles ins Userland auslagern ist auch keine Lösung... -
Re: Nachteile von Monolitismus
Autor: Wintrotz 19.02.10 - 20:54
Ano Nymus schrieb:
> Aber eine Windows-Artige lösung ("yo, lad dir mal den
> und den und den und den und den und den und den treiber, den hab ich
> nähmlich nich dabei") will ich nicht. Und alles ins Userland auslagern ist
> auch keine Lösung...
Man kann Windows viel Schlechtes nachsagen, aber bei Leibe die Treiberlandschaft und die damit einhergehende Unterstützung von Geräten ist bereits seit Windows XP hervorragend und hat sich mit Vista und 7 nochmals verbessert. Ich mag behaupten, dass Windows zu 99% der verbauten Hardware für einen PC nicht älter als 5 Jahre sicher erkennt und passende Treiber installiert. Bei seltenen Exoten tut es erstmal der Standard-0815-Treiber mit hohen Kompatibilität, bis man den vom Hersteller verfügbaren Treiber installieren kann. Aber Primärfunktionen wie Grafik, Sound, LAN, RAID, Brenner etc. ist selbstverständlich - noch nie nach weit über 1000 Installationen auf verschiedenen Systemen erlebt, das diese Grundlagen nicht funktionieren. Das hat OpenSUSE (egal wie schlecht es manche befinden) letztes Jahr bei zahlreichen Systemen nicht hinbekommen. Ich bin kein erfahrener Linuxanwender, aber das ist schlichtweg enttäuschend.
Das Linux mehr auf Standardtreiber bedacht ist, die womöglich von Hause aus mitgeliefert werden, mag u.a. daran begründet sein, dass es noch sehr viele Firmen gibt, die Linux nicht unterstützen bzw. die Hardwareerkennung nicht alles abdeckt. Fremdsystemen mehr als grauselig. Ja Linux ist gut, aber bitte bei den Tatsachen bleiben - an die Treiberunterstütung eines Vista bzw. 7 reicht Linux nicht mal zu 50% heran. Auch wenn Linux in vielen anderen Bereichen gleichauf oder gar besser ist. -
Re: Nachteile von Monolitismus
Autor: Roflkopter 19.02.10 - 21:43
AromorApp schrieb:
--------------------------------------------------------------------------------
> Alles was in den Kernel soll, ist von der Gnade der Türsteher abhängig.
>
> Von daher wäre schöner, wenn schmalbandige Dinge wie Drucker, Scanner, alle
> Bluetooth-Geräte und die meisten USB-Geräte-Sorten usw. besser über /dev/
> bzw. /udev/-Einträge ihre Treiber für SMS-Versand mit dem Handy
> realisieren, als unbedingt Kernel-Treiber haben zu müssen.
>
> Beim Drucken dürfte die Performance eines "user-mode"-Treibers in den
> meisten Fällen nicht gerade relevant sein.
>
> Davon abgesehen wären Kernel-Spezial-Teams sinnvoll, die immer nur
> bestimmte Dinge überprüfen. Buffer overflows, memory lecks, gängige Fehler.
> Andere Teams aber z.b., das alle Treiber dieses LSM benutzen, wie es
> gedacht ist.
Tut mir leid aber 90% der Drucker/Scanner Treiber sind nicht im Kernel... -
Re: Nachteile von Monolitismus
Autor: Roflkopter 19.02.10 - 21:49
Wintrotz schrieb:
--------------------------------------------------------------------------------
> Ano Nymus schrieb:
> > Aber eine Windows-Artige lösung ("yo, lad dir mal den
> > und den und den und den und den und den und den treiber, den hab ich
> > nähmlich nich dabei") will ich nicht. Und alles ins Userland auslagern
> ist
> > auch keine Lösung...
>
> Man kann Windows viel Schlechtes nachsagen, aber bei Leibe die
> Treiberlandschaft und die damit einhergehende Unterstützung von Geräten ist
> bereits seit Windows XP hervorragend und hat sich mit Vista und 7 nochmals
> verbessert.
Warum kennt Win 7 dann meinen Scanner, Drucker und meine TV Karte nicht mehr?
> Ich mag behaupten, dass Windows zu 99% der verbauten Hardware
> für einen PC nicht älter als 5 Jahre sicher erkennt und passende Treiber
> installiert. Bei seltenen Exoten tut es erstmal der Standard-0815-Treiber
> mit hohen Kompatibilität, bis man den vom Hersteller verfügbaren Treiber
Installier doch mal Windows auf einem Lenovo N200 3000 und guck dir mal an wieviel Hardware nicht OOTB funzt...
Dann mach das selbe mit einem Linux... ;)
> installieren kann. Aber Primärfunktionen wie Grafik, Sound, LAN, RAID,
> Brenner etc. ist selbstverständlich - noch nie nach weit über 1000
> Installationen auf verschiedenen Systemen erlebt, das diese Grundlagen
> nicht funktionieren. Das hat OpenSUSE (egal wie schlecht es manche
> befinden) letztes Jahr bei zahlreichen Systemen nicht hinbekommen. Ich bin
> kein erfahrener Linuxanwender, aber das ist schlichtweg enttäuschend.
>
> Das Linux mehr auf Standardtreiber bedacht ist, die womöglich von Hause aus
> mitgeliefert werden, mag u.a. daran begründet sein, dass es noch sehr viele
> Firmen gibt, die Linux nicht unterstützen bzw. die Hardwareerkennung nicht
> alles abdeckt. Fremdsystemen mehr als grauselig. Ja Linux ist gut, aber
> bitte bei den Tatsachen bleiben - an die Treiberunterstütung eines Vista
> bzw. 7 reicht Linux nicht mal zu 50% heran. Auch wenn Linux in vielen
> anderen Bereichen gleichauf oder gar besser ist.
Echt?
Haste mal verglichen auf wievielen Plattform der Vanilla-Kernel läuft und wieviele Treiber er mitbringt?
Da kannste Windows in die Tonne kloppen...
Vorallem bei 64Bit hinkt Windows hinterher und ich sag bewusst Windows da die Leute mangelnde Treiberunterstüzung der HW Hersteller auch immer dem System zuschieben wenn es mit L anfängt... -
Re: Nachteile von Monolitismus
Autor: lachenderdritter 19.02.10 - 22:21
Ich hab selten so gelacht und selten soviel Unwissen in einem einzigen Kommentar gesehen.
Kernel-Spezial Teams gibt es und zwar nicht in einer völlig schwachsinnigen Aufteilung nach "Leaks" und was weiss ich, sondern nach Themenbereichen, wie zum Beispiel Netzwerk, und Unterbereiche davon wie zum Beispiel WLAN. Es gibt doch zum Beispiel in der KFZ Produktion auch kein Team fürs Schrauben rein drehen, sondern Teams für die verschiedenen Bereiche, und die brauchen alle Schrauben. Genauso sollte jeder Entwickler am Kernel über seine Memory Leaks bescheid wissen.
Dann weiter: "Beim Drucken dürfte in den meisten Fällen ..." Was soll das denn? Raten einmal für alle? Da fällt mir direkt Dieter Nuhr ein.
Ich weiss nicht obs der gleiche war, aber in dieser Diskussion Kernel Module als alternative zum monolithischen Kernel zu bringen hat mich vom Stuhl gehauen. und zwar lachend.
Das war ernsthaft das erste Mal, dass ich solch geistigen Dünnschiss lesen durfte, der offensichtlich auch noch ernst gemeint war.
On-Topic: Niemand wird gezwungen seine Treiber in den Kernel zu bringen. Siehe ATI und nvidia. Die machen es so wie sie wollen. Der Vorteil eines Treibers im Kernel ist, dass er mit gepflegt wird. Er muss nicht wegen jedes schnipsels nachgezogen werden um zu einer neuen Kernelversion kompatibel zu sein. Das machen die, die Änderungen einbringen. Änderungen, die andere Dinge kaputtmachen werden nämlich nicht akzeptiert, bzw gar nicht erst eingereicht.
Nu is aber gut. Sowas affiges. -
Re: Nachteile von Monolitismus
Autor: App Armor 19.02.10 - 22:37
Ano Nymus schrieb:
Ich erwarte bei diesen "treiber-daemons" ja nicht, das sie über /etc/init.d-Scripte geladen werden.
Man schaut in pci.db oder usbid.db oder wie die heissen und lädt dann die entsprechenden "driverdaemons" beim booten oder wenn ein Gerät dran-gesteckt wird.
Auch kill -9 usw. sollte man damit nicht so einfach machen können.
Aber im Schulbus kann Dir jeder auf den Kopf hauen. Auch wenn das dummerweise wegen neulich ein doofes Beispiel ist.
Im Familienauto haut Dich nur Deine Familie.
Was ist besser ?
Ich habe auch nichts dagegen, das man .ko-Module daraus machen kann. Oder das man sie an das Kernel-File hinten dran hängt und gleich mit startet.
Nicht jeder hat den neuesten Rechner und manchmal will/muss man alten Treiberkrams laden um überhaupt z.b. an die Festplatten dranzukommen und den Rest des Systems laden zu können.
Statt yes, no, module oder wie die heissen im Kernel-Configuration-File käme dann noch 'extern' oder ".ko2" oder sowas dazu.
Die Leute sind unbedingt scharf drauf, in den Kernel zu kommen. Man sollte sie lieber anhalten, bestimmte Treibersorten über /dev/ oder was grade aktuell ist, zu implementieren.
Das klappt bei Druckern und Scannern ja auch.
Warum soll das bei einem Bluetooth-headset anders sein ?
Es erzwingt halt "nur" eine Zerlegung. Wenn es mal läuft, mussen sich alle Verhinderer fragen lassen, wieso sie das nicht schon früher "richtig" (also so wie jetzt) gemacht haben.
Und an die Windows-Fans:
Mein Medion-Grafik-Tablett hatte irgendwann XP-Treiber auf dem Server. Von anderer Hardware von anderen Herstellern kann ich das nicht behaupten.
Und Scanner und Handies und Tauchcomputer und Messgeräte halten länger als 5 Jahre. Und die will man durchaus unter Windows-7 noch benutzen. Ohne sich die teuer-Version mit Emulator kaufen zu müssen. Speziell wenn der Emulator gar nicht läuft, weil man einen der zillionen miesen Netbooks oder CPUs ohne "VT"-Technologie (bzw. dem Intel-Pendant) gekauft hat. Solche miesen CPUs gehören eigentlich verboten. Und sie werden überall verbaut :-((( So wie netbooks und laptops ohne gigabit-Ethernet.
Kurzum: Die Treiberhersteller liefern völlig nach gutdünken Windows-Treiber wie sie wollen. Zur Strafe sollte man linux-freie Hardware mit längeren steuerlichen Abschreibungs-Zaiträumen bestrafen.
Steuerzahler müssen es nicht mitbezahlen, das jemand auf Win7 wechselt und seine halbe Hardware-Ausstattung auf unsere Steuerkosten austauscht, nur weil Win7 damit nicht klarkommt.
Wenn die Geräte Linux-Tauglich wären, könnte er sie zum Restbuchwert an Linux-Leute verkaufen. So kann er sie nur wegwerfen und unnötige Entsorgungskosten produzieren.
Unternehmen haben die Kosten klein zu halten. Alles andere ist Untreue an den Aktionären und Gläubigern. -
Re: Nachteile von Monolitismus
Autor: 486dx4-160 20.02.10 - 01:24
App Armor schrieb:
> Man schaut in pci.db oder usbid.db oder wie die heissen und lädt dann die
> entsprechenden "driverdaemons" beim booten oder wenn ein Gerät
> dran-gesteckt wird.
Stell dir vor, genau so werden Kernel Module geladen.
> Auch kill -9 usw. sollte man damit nicht so einfach machen können.
rmmod geht auch nicht so einfach, nur als root.
> Oder
> das man sie an das Kernel-File hinten dran hängt und gleich mit startet.
Davon hat man Abstand genommen, da ein paar Geräte (z.B. PXE) Probleme mit großen Binärbrocken haben. Deswegen ist das in die Initial Ramdisk ausgelagert worde.
> Statt yes, no, module oder wie die heissen im Kernel-Configuration-File
> käme dann noch 'extern' oder ".ko2" oder sowas dazu.
Wenn du auf's Kernelbauen anspielst: Da gibt's meist die Auwahl Modul, intern oder gar nicht-
> Die Leute sind unbedingt scharf drauf, in den Kernel zu kommen. Man sollte
> sie lieber anhalten, bestimmte Treibersorten über /dev/ oder was grade
> aktuell ist, zu implementieren.
>
> Das klappt bei Druckern und Scannern ja auch.
> Warum soll das bei einem Bluetooth-headset anders sein ?
Auch um dein Bluetooth-Headset kümmert sich ein Userspace-Treiber (wahrscheinlich Pulseaudio).
Hardwarenahe Sachen kommen in den Kernel, hardwareferne nicht.
Die Kernelmodule schaffen eine Abstraktionsschicht, die es erst ermöglicht die Geräte anzusprechen. -
Re: Nachteile von Monolitismus
Autor: monolitisten 20.02.10 - 02:33
lachenderdritter schrieb:
--------------------------------------------------------------------------------
> Kernel-Spezial Teams gibt es und zwar nicht in einer völlig schwachsinnigen
> Aufteilung nach "Leaks" und was weiss ich, sondern nach Themenbereichen,
> wie zum Beispiel Netzwerk, und Unterbereiche davon wie zum Beispiel WLAN.
> Es gibt doch zum Beispiel in der KFZ Produktion auch kein Team fürs
> Schrauben rein drehen, sondern Teams für die verschiedenen Bereiche, und
> die brauchen alle Schrauben. Genauso sollte jeder Entwickler am Kernel über
> seine Memory Leaks bescheid wissen.
Querschnitt- und Linienfunktionen.
Und Qualitätskontrollen und "Revision" gibts in vielen Unternehmen auch. In wirklich guten Unternehmen funktionieren die auch.
Also bei LSM würde das LSM-Team sich drum kümmern, gnadenlos alle Module zu unterwerfen und zu LSMfizieren, die in Frage kommen.
Es muss also nicht unbedingt ein Spezialteam nur dafür geben, wenn das normale LSM-Team das erledigt.
Aber Leaks und Fehler sollen ruhig spezialisten AUCH suchen. Der profi-Kernel-Coder macht natürlich keine Fehler.
Du bist also für die Repatriierung von Drucker- und Scanner-Treibern in den Kernel... Na gut.
Wenn nicht, überleg mal, wieso USB_Geräte auch über Busstrukturen, also angesprochen werden könnten.
Und pppd usw. gehört auch in den Kernel laut Dir... .
Monolisten mögen .NET und Eintopf.
Modularisten mögen java. Wenn man älter ist, weiss man, warum monolitismus ärger macht, weil alles irgenwie zusammenverstrickt ist. Klüngel, Filz und "Seilschaften" beschreibt das gut. Filz sind verfilzte zusammengefrickelte Haare oder Fasern.
Autonom austauschbare Teile sind wartungstechnisch angenehmer und Fehlertechnisch oft unabhängiger. -
Re: Nachteile von Monolitismus
Autor: hd-scaler 20.02.10 - 02:48
486dx4-160 schrieb:
--------------------------------------------------------------------------------
> > Oder
> > das man sie an das Kernel-File hinten dran hängt und gleich mit startet.
> Davon hat man Abstand genommen, da ein paar Geräte (z.B. PXE) Probleme mit
> großen Binärbrocken haben. Deswegen ist das in die Initial Ramdisk
> ausgelagert worde.
Die braucht dann aber zugriff auf den Treiber für den alten laptop usw. Von daher die Idee einzelne nötige Treiber (und nicht alles mögliche was man nicht braucht) dranzuhängen.
Ähnliches Problem: Fli4l hatte z.b. Probleme mit 2.4(oder 2.6), weil 2.4(? oder 2.6) kein initar mehr konnte. Dann brauchte man tftp+nfs statt nur tftp.
> Hardwarenahe Sachen kommen in den Kernel, hardwareferne nicht.
> Die Kernelmodule schaffen eine Abstraktionsschicht, die es erst ermöglicht
> die Geräte anzusprechen.
Video ist hardwarenah, dvb und sound nicht ?
USB ist die Abstraktionsschicht.
Drucker, Scanner arbeiten über LPT oder usb-devices.
Alles mögliche fürs Handy und ppp usw. arbeitet über com-ports oder "simulierte" Comports fürs Handy usw .
Die haben es auch nicht nötig, unbedingt im Kernel zu laufen.
FUSE macht es vor. Es hat auch Nachteile, aber ist auch der Beweis, das sogar Filesysteme "draussen" gehen.
"Driverspace" würde ich sowas nennen. Das hat und braucht mit normalen Usern nichts zu tun zu haben. Man wird es dann zur Vereinfachung vielleicht über User bzw. Gruppen implementieren.
Wer eingeloggt ist, dem gehört das USB-Device was grade reingesteckt wurde. Ggf. lässt man dann z.B. dvb oder v4l-Treiber oder FUSE für dieses Gerät unter seiner User-ID laufen. Das device gehört ihm dann auch und er darf z.B. auch fdisk drauf machen oder was auch immer.
Hardwarenah ist Usb eigentlich nicht mehr wirklich. Zumindest nicht näher als lpt oder com-ports.
Wenn die Geschwindigkeit leiden würde, oder man auf die Hardware poken muss oder !DMA! genutzt wird, dann kommt man um Kernel wohl nicht herum. Aber bei Standard-Device-Strukturen könnte man einen Cut machen und es auslagern.
Modularisierung hat Vorteile.
Auch wenn manche es als Nachteil ansehen würden, wenn man solche Linux-"Treiber" dann unter bösem BSD oder Windows laufen lassen könnte. -
Re: Nachteile von Monolitismus
Autor: linman 20.02.10 - 10:37
Also ein Windows XP out of the Box erkennt an meinen Rechner fast nix. Ich habe hach der installation weder eine funktionierende Netzwerkkarte, noch sound und 16 Farben in einer beschießenen 800x600 Optik. Der xorg vesa treiber ist da 1000 mal besser. Bei Vista und Win 7 gibt es zwar mehr treiber als unter XP, jedoch müssen diese dann meist erst über Automatische updates heruntergeladen werden.
Wenn es um Out of the Box Treiber geht, kann Windows Linux nicht im entferntesten das Wasser reichen. -
Re: Nachteile von Monolitismus
Autor: ArmorApp 20.02.10 - 12:27
Das schlimme ist wohl, das M$ von den Herstellern geld will.
Und das es teilweise Treiber gibt, man sich aber bei Driverdownload-Sites usw. anmelden muss. Na danke.
M$ hat die Infrastruktur. Es kann die signierten Treiber als kleines .ini oder .xml-File ausspucken.
Dann geht das Update-Tool zuerst zur Hersteller-Site und downloaded es von dort. Oder bei chip.de sind "verwaiste Treiber" von ELSA oder sonstwem gelagert.
Updates für Windows holt man sich von microsoft.com . Updates von Abit von abit.com . M$ verwaltet nur die Signaturen und Informationen, welche Treiber zu welcher PCI-ID gehören und wo man sie findet und wie sie heissen.
Aktuelle Treiber anbieten darf dann auch nicht verboten sein. Ist es dann teilweise aber vielleicht oder man bekommt Post vom Anwalt, das man die Win7-Treiber für den 10 Jahre alten Scanner runternehmen soll.
Sowas ist einfach nur noch asozial. Und M$ kümmert es nicht.
Eigentlich sollte man M$ öffentlich anprangern, wie wenig Hardware noch unter Win7 läuft und das man nur linux-fähige hardware kaufen soll. Weil die bei Win8 dann unter Linux funktioniert.
Leider kümmert Elektroschrott keinen. -
Re: Nachteile von Monolitismus
Autor: UllaDieTrulla 20.02.10 - 17:06
> wie wenig Hardware noch unter Win7
Nahezu meine komplette Hardware, die schon älter als 5 Jahre alt ist.
Ausgenommen einer Logitech-Webcam, die noch älter ist.
Diese läuft nur unter 32-Bit Windows 7, hier habe ich aber nur ein 64-Bit Windows 7, das mit keinem anderen Gerät bisher Probleme hatte.
Man kann Windows 7 viel nachsagen, aber Treiberprobleme auf keinen Fall! -
Re: Nachteile von Monolitismus
Autor: Ralph_H 21.02.10 - 12:42
Ano Nymus schrieb:
--------------------------------------------------------------------------------
> Also die Treiber-Politik des Linux-Kernels finde ich bisher vollkommen in
> Ordnung. Man sollte allerdings (wie im WLAN-zweig) versuchen mehr Treiber
> zusammen zulegen (beispeil: rt28X0), damit es nicht allzuviele
> einzeltreiber werden. Aber eine Windows-Artige lösung ("yo, lad dir mal den
> und den und den und den und den und den und den treiber, den hab ich
> nähmlich nich dabei") will ich nicht. Und alles ins Userland auslagern ist
> auch keine Lösung...
Und das ist bei Linux das Problem. So lange es nicht so einfach ist, einen Treiber zu installieren, wie bei Windows, wird Linux ein Nischenprodukt bleiben. Ich habe einige Jahre lang versucht mit Linux zu arbeiten. Mit allgemein üblicher Hardware (nix exotischen an irgendwelchen IO Karten) und stand immer wieder vor dem Problem, woher jetzt den passenden Treiber nehmen. Sehr oft war es dann so, dass die Hersteller keine Unterstützung für Linux boten. Kann ich aber auch sehr gut nachvollziehen. Wenn von einer Kernelversion zur nächsten neu Treiber her müssen, ist das für ein gewinnorientiertes Unternehmen schlichtweg zu teuer.
Und da stellt sich schon die Frage, ob Software, die nicht zum ursprünglichen Funktionieren eines Systems unbedingt in den Kernel müssen. Unterstützung für USB Geräte, Drucker, Scanner, Joysticks etc. werde nzum Booten nicht benötigt. JA auch USB nicht.....die werden von SSD's doch eh abgelöst und die fahren auf SATA oder schnellerem.
Ich wäre dafür für z.B. einen Drucker eine mit Reserven ausgestattete API anzulegen, die für die mindestens kommenden 2 Jahre nach außen unverändert bleibt, damit die Hersteller überhaupt einmal erst die Chance bekommen Treiber zu etablieren.
Was nach Innen zum Kernel an Veränderungen umgesetzt werden interessiert dann Hersteller von Hardware nicht unbedingt. Und wenn ich dann einen Treiber auf der Website des Herstellers downloaden und mit einem Doppelklick installieren kann....dann ist Linux reif, um Windows konkurrenz bieten zu können.
Und bevor jetzt ein Sturm der Entrücstung ob der Bezugnahme auf Windows losbricht: Windows ist halt früher da gewesen und hat halt einfach eine breitere Unterstützung....daran MUSS sich jedes andere OS messen lassen....ob Windows gut oder schlecht ist steht dabei wieder auf einem anderen Blatt.



