StefanBP schrieb:
Ja daran sieht man aber auch immer wie viel Schrott selbst in Linux drin ist.
Naja lieber so wie in der Windows welt wo du beim einspielen jeder neuen Windows version erstaml deine Drucker und Scanner aufn Schrott werfen kannst (oder seit ner weile notduerftig ueber ein virtualisiertes Windows benutzen kannst, was extrem umstaendlich ist und viel resourcen kostet).
Da nunmal das Kernelteam nicht staendig die Treiberschnittstelle grundsaetzlich neu erfindet und man wenn dann wohl bei den treibern einfach mal fuer alle mit irgend nem Script die schnittstellen aktuallieren kann ohne zutun der Hersteller die Treiber aktualisieren muessten, ist das doch super.
Und ja es ist nett wenn man code der keine funktionalitaet mehr hat entfernen kann oder gleich viel funktionalitaet mit weniger zeilen code erzeugen kann (sofern man dazu nicht den code sehr unverstaendlich zusammenfassen muss), aber wenn der nutzen / die kosten des erhalts updates der treiber noch in einem halbwegs guten verhaeltnis steht, steht nix im wege den code weiter zu pflegen sofern es noch leute gibt die das benutzen.
Nur wenn eben niemand mehr den code pflegt und es resourcen kostet oder die treiber schlicht sonst kaputt waeren macht es sinn sie raus zu schmeisen, nach ein paar aufrufen ob noch jemand interesse dran hat.
Wie gesagt was Microsoft da macht bzw deren treibermodell das zu kuenstlicher obsoleszens von funktionstuechtiger Hardware fuehrt ist viel schlimmer.
Auch wenn da natuerlich Microsoft die Schuld an die Hersteller weiter geben kann, aber das ist halt der unterschied zwischen einem ausschliesslich fuer Hersteller teilweise guten Treibermodell vs einem offenen das vorteile fuer kunden in fordergrund stellt.
NACHTRAG:
Nachteile aus mehr zeilen Code haben die Endanwender eigentlich keine so gut wie niemand kompiliert heute mehr den kernel selber und wenn ist er modular, also der kenrel wird nicht schneller wenn man treiber aus dem source loescht, distributionen oder leute die sich kernel selber bauen koennen ja ganz einfach diese module deaktivieren und den binaere kernel ist dann trotzdem genauso schlank ob dann nochmal 5x mehr treiber da waeren im source oder nicht.
Aber natuerlich ist ein Kernel also vorallem der Source dessen groesser von einem system das prinzipiel alle Hardware direkt ueber den kernel supporten will als ziel, als bei einem system das erstmal kaum hardware unterstuetzt und jeder hardwarehersteller nochmal ein eigenes halbes betriebssystem mit als treiberpaket anbietet.
Update 2:
immerhin egal ob man den reinen Kernel als source oder auch als compilierten Kernel nimmt ist der Kernel sehr klein im vergleich zu nur einem Treiber in der Widnows welt:
Kernel 3.15
Kernel sourcecode: 76 mb
kernel fedora: 137 mb
Nvidia Treiber: 268 mb
AMD Treiber: 256 mb
Denk da hat amd noch luft nach oben, da ist naemlich auch ein amd und ein nvidia treiber drin, wenn auch speziel der fuer nvidia deutlich lahmer ist wie der proprietaere, aber das hat wohl wenig mit der treibergroesse zu tun. Der amd treiber im kernel ist mal deutlich schneller und sicher nicht viel groesser wie der freie fuer nvidia hardware.
In letzten benches zieht er schon teilweise am proprietaeren blob vorbei:
http://www.phoronix.com/scan.php?page=article&item=amd_linux316_good&num=1
Gleiches Prinzip wie oben.
