Re: Drawbacks von Linux (war: OT:::Re: Mal was Lustiges)
On Fri, Apr 18, 2003 at 03:32:19AM +0200, Dirk Haage wrote:
> > - Kernel: viel zu gross, zu ueberladen, "zu monolithisch".
> > [....]
> 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.
... und daraus resultieren dann auch andere Probleme...
> > 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 ;( )
Naja, das gilt eingeschraenkt bis zu einer gewissen 3.2.x'er Version, bis zu
welcher weiss ich nun nicht genau. C++ ist immer noch tierisch lahm, was
aber eher weniger beim Kernel selber zum Tragen kommt.
> 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!
Brauchste mir nicht zu erzaehlen... ;))
Ich durfte mich schon mit Pseudo-C-Code herumschlagen, der sich nicht mit
MIPSpro kompilieren lassen wollte, weil der Autor lieber irgendwelche gcc
spezifische Dinger eingebaut hatte, so dass ich dann doch den gcc nehmen
musste, was deutlich langsamere und deutlich groessere Binaries (ja, auch
nach dem Strippen) zur Folge hat.
GCC ist generell ziemlich unoptimiert auf non-x86 Architekturen (bzw. auf
non-Mainstream, wenn man mal vielleicht PPC und IA64 dazu zaehlt), was sich
u.a. dann auf m68k in so lustigen Fehlern niederschlagen kann, wie in der
letzten Debian Weekly News erwaehnt.
> > 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.
Spaetestens beim make dep muessen solche nicht benoetigten Dinger aber auch
wenigstens mal beruecksichtigt werden. Auch spaeter beim make bzImage geht
make alle Verzeichnisse durch und schaut nach Makefiles, was natuerlich auch
- wenn auch wenig - zusaetzliche Zeit kostet.
> > - Speicherverwaltung.... grausig!!!
> Ui, ein Leidensgenosse!
*Seufz*
> > 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.
XFS gibt es nicht fuer 2.2.x ;)
> 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?
Naja, arrogant sind bestimmt nicht alle, aber viele. ;)
Aber viele moechten auch lieber tolle, neue Ideen einbauen anstatt alte
vorhandene Probleme zu beheben. Gut zu sehen an der Diskussion um die neuen
Prozess-Scheduler im Entwicklerkernel. Da werden erstmal (uebertrieben
ausgedrueckt) 10 verschiedene Modelle programmiert, dann ewig darueber
diskutiert und sich gegenseitig vollgeflamed, anstatt sich mal *gemeinsam*
vorher Gedanken zu machen, dann zu entscheiden und dieses dann eventuell in
einer Gruppe auch umzusetzen. Kurzum: ziemlich unproduktive Laberbude (wie
die Uno ;)) manchmal.
Irgendwie fehlt dort in entscheidenden Fragen die klare Struktur und die
gezielte Richtung. Oder anders: Viele Koeche verderben halt doch manchmal
den Brei.
> 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:
Meine Eltern haben sich letztens einen Celeron 533 mit 64 MB Ram zum Linux
ausprobieren und lernen hingestellt. Mit Gnome waren staendig min. 40 MB
Swap in *heftiger* Benutzung, ein "normales" Arbeiten eigentlich unmoeglich.
Seinen urspruenglichen Vorteil, dass Linux auch wunderbar schnell auf
aelteren Rechnern einsetzbar ist, ist inzwischen alles andere als wahr. Wer
z.B. einen 486dx100 mit 32 MB Ram hat, sollte zum Surfen meiner Meinung nach
lieber ein Win95 nehmen statt eines Linux.
Also Woody auf einem Rechner mit 12 MB zu installieren ist nahezu
unmoeglich. Ich bin schon seit 2 Tagen dabei, Woody auf einem A3000 mit 12
MB zu installieren, um einen Bug im sane Package zu testen (bzw. den Fix
dafuer) und danach dann den debian-installer bzw. die 2.4er Kernel fuer
m68k. Kerneltesten auf einem autobuilder ist halt schlecht, deswegen der
zweite A3000... aber dpkg ist ja nur noch auf der Platte beschaeftigt.
Potato war bedeutend kleiner und waere schon laengst installiert.
Resultat: Linux ist fuer alte Rechner nix mehr.
> 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)
... wobei ich da auch nicht so recht sehe, wo der Unterschied zwischen einer
gebrannten CD mit 4x und 40x sein soll? Brennt der Brenner die 40x anders?
Macht er schoenere Pits draus bei 4x? Wenn der Brenner die Pits nicht so
brennen kann bei 40x, dass sie den Vorschriften fuer eine CD entsprechen,
dann sollte er auch nicht als 40x verkauft werden, imho...
> 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)
Jupp...
> 4. Weil dann irgendwer zugeben muesste, Scheisse gebaut zu haben.
Quatsch... schuld sind immer die anderen! ;))
> > - 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.
Und wie wir schon vorhin festgestellt haben, mangelt es dem Kernel an einem
solchen Konzept und solcher Struktur. Q.e.d.
> 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).
Geht mir aehnlich.
> 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. :(
Vor allem, die schon seit Ewigkeiten bekannt sind, wo aber nichts dran getan
wird.
--
Ciao... //
Ingo \X/
Reply to: