Re: Drawbacks von Linux (war: OT:::Re: Mal was Lustiges)
On Wed, 16 Apr 2003 21:06:28 +0200 Ingo Juergensmann wrote:
Ich muss jetzt was dazu sagen!
> Ich halte folgendes an "Linux" fuer verbesserungswuerdig:
>
> - Kernel: viel zu gross, zu ueberladen, "zu monolithisch".
> Wenn man sich einmal die Groesse des Kernels und die
> Kompilierungszeiten anschaut, dann wird einem irgendwie klar, dass das
> so nicht mehr lange weiter gehen kann. Auf meinem PII-350 hab ich mit
> Kernel 2.0.36 angefangen, der innerhalb weniger Minuten komplett
> durchkompiliert war und nur einen Bruchteil des heutigen Platzes
> beanspruchte. Heutzutage sind die gepackten Kernelsourcen auf ueber 30
> MB angewachsen, meine Hardware ist aber im Grunde die gleiche
Das liegt daran, dass das meiste im Kernel nicht portabel ist. Achtung:
Portabel heisst nicht - wie oftmals angenommen - laeuft auf moeglichst
vielen Plattformen, sondern eher ein Grossteil des Codes ist
Plattformunabhaengig und nur ein geringer Teil muss jeweils angepasst
werden. Das ist bei Linux schonmal nicht so. Dann gibt es keine
(sinnvollen) Schnittstellen, die vorhandenen werden staendig veraendert
usw.
> geblieben. Ein Kernelcompile von 2.4.20-xfs dauert inkl. Module fast
> eine komplette Stunde. Wenn ich nun 3 mal so viel Hardware wie damals
> drin haette, wuerde ich ja nix sagen, aber das ist nunmal nicht der
> Fall, aber bei jedem neuen Kernelrelease dauert es immer laenger, bis
> ein Kernel fertig ist. Und das nicht nur beim Kompilieren, sondern
> auch beim Release. 2.4.21 ist ja eigentlich mehr als ueberfaellig, so
> dass ich mir die Frage stelle, wieso es so lange dauert?
Das liegt teilweise auch am Compiler, der gcc > 3 ist irgendwie
langsamer geworden. Und langsamen Code erzeugt er auch noch (weswegen er
wohl selbst langsamer ist ;( ) Beispiel: mit einem SCO-UNIX c-Compiler,
der auch ELF-Objects erzeugt, kann man unter Linux nutzbare Binaries
erstellen, die locker 40% schneller sind (vorausgesetzt, die Sourcen
waren tatsaechlich in ansi oder iso C und nicht in "gcc-c", denn dann
kompiliert gar nix!
> Wenn man jeden popeligen Treiber in den Maintree vom Kernel packt,
> obwohl man das meiste Zeugs eigentlich gar nicht braucht, wundert mich
> das nicht, dass 2.4.21 noch nicht released wurde. Zuviel muss unter
> einem Hut gebracht werden.
Das soll ruhig so bleiben, nur sollte das die Compile-Zeit nicht
veraendern, denn was ich nicht brauche, sollte auch nicht compiliert
werden muessen, scheint es aber trotzdem zu werden.
> Ausserdem werden "alle Nase lang" irgendwelche Dinge geaendert. Bei
> 2.0 hatte man ipfw oder so, bei 2.2 ipchains und bei 2.4 nun iptables.
> Gut, die Funktionalitaet ist auch gestiegen, aber wieso muss man
> staendig alles komplett ueber den Haufen schmeissen, statt sich einmal
> *richtige* Gedanken ueber eine API zu machen, die dann auch lange Zeit
> bestand haben und erweitert werden kann? So koennte man dann auch
> etliches aus der eigentlichen Kernelentwicklung heraushalten, etwa USB
> Treiber. Man hat nur eine generische USB API im Kernel und die Treiber
> laufen als Subprojekt. Wenn ich eh kein USB im Rechner habe oder kein
> USB brauch, brauch ich mir doch den Krams auch nicht downloaden und
> mit auf die Platte zu knallen? Wie wird es bei Kernelversion 3.2 oder
> 4.6 aussehen? Braucht man dann eine T3 Leitung, um die Kernelsourcen
> binnen Tagesfrist downzuloaden und ein NAS, damit man die Sourcen
> entpacken kann? Das kann's ja wohl echt nicht sein....
Wenn sich nix aendert: Ja
> - Speicherverwaltung.... grausig!!!
Ui, ein Leidensgenosse!
> Kleines Beispiel:
>
> Mem: 644908k total, 632568k used, 12340k free, 4k
> buffers Swap: 1394604k total, 150148k used, 1244456k free,
> 396976k cached
[...]
> Interessanter verbraet W2k auf meinem Laptop deutlich weniger Ram als
> Linux, so dass dort dann auch mal das abschalten der Festplatte
> funktioniert, weil nicht staendig irgendwas auf die Platte geswappt
> wird (trotz noflushd).
Noch besser: Nimm mal nen 2.2 Kernel! Wenn du nicht auf bestimmte Dinge
angewiesen bist (USB2.0, FireWire o.ae.), ist das ne Alternative.
Ploetzlich laueft das System wieder, ist schnell, benutzt den Swap
nicht, spricht schnell an usw. und warum? Am Speichermanangement kann es
jedenfalls nicht liegen, das ist ganz toll und ausgefeilt. Komisch nur,
das es waehrend der stabilen (!) Serie schon mehrere komplette Rewrites
gegeben hat, das Verhalten aber doch nicht besser geworden ist. Daraus
laesst sich nur schliessen, dass da noch der Wurm drin ist, aber
sagen darfst du das nicht, denn die Kernelentwickler wissen ja genau was
sie tun. Und da liegt mal wieder das Problem: Die Kernelentwickler sind
groesstenteils ziemlich arrogant und lassen keine andere Meinung zu,
auch wenn sie noch so fundiert und ueberlegt ist. Sie auf Fehler
hinzuweisen kann man sich schenken, denn die werden gar nicht erst
ernst genommen. Oder warum kann immer noch kein ungepatchter 2.4er
Kernel DMA bei Blockgroessen <> n*512 Bytes?
1. Weil das ja kein wirkliches Problem ist, heutige Rechner sind ja so
schnell und da macht das vielleicht 20% systemlast aus, das ist ja halb
so wild. Ich moechte aber auch gerne in alten Rechner aktuelle
CD-Brenner einsetzen und mal ne Audio- oder Video-CD brennen, dann hoert
man:
2. AudioCDs sollte man eh nicht 40x Brennen, da einige Player diese CDs
dann nicht mehr lesen koennen (Was ja dann eigentlich mein Problem ist)
3. (und damit kommen wir der Wahrheit schon naeher) Weil es eben keine
triviale Aenderung ist. Das liegt an nicht portablen, nicht
strukturiertem Code ohne vernuenftige Schnittstellen (Womit wir wieder
beim Anfang waeren)
4. Weil dann irgendwer zugeben muesste, Scheisse gebaut zu haben.
> - SMP support
"Wir haben nur einen globalen Kernel-Lock, damit bleibt das System
einfach und effektiv" so oder so aehnlich hat das mal LT gesagt, nur
sollte man nicht versuchen, so ein System MP-faehig zu machen.
Kernel-Locks sind ne nicht ganz triviale Sache und immer ein
Nadeloehr in MP-Systemen. Ohne gut strukturiertes Konzept mit
ordentlichen Schnittstellen und moeglichst wenigen, nicht
ineinandergreifenden syscalls ist das definitiv nicht effektiv und
fehlerfrei umzusetzen.
> So, und nun bin ich mal auf die typischen "der depp hat ja eh keine
> Ahnung" Flames gespannt... ;-))
Er blieb dir erspart, aber ich werde ihn mir bestimmt anhoeren duerfen.
Wobei ich nochmal erwaehnen moechte, dass ich gerne Linux benutze (auch
mangels besserer Alternativen). Nichts bietet einem so viele
Moeglichkeiten. Trotzdem gibt es halt gewisse Dinge, die mich einfach
nur aufregen, und die meisten davon haben was mit dem Kernel oder GNU zu
tun. :(
/dirk
--
dirk haage | dh@a-n-t-s.de
fon +49 (0) 30 44 65 29 45
mobile +49 (0) 178 DIRK HAAGE
Reply to: