Hallo Reinhard,
On Tue, Apr 09, 2002 at 06:28:24PM +0200, Reinhard Foerster wrote:
Die libc ist wichtig. Bei den von dir genannten Anwendungen spielt sie allerdings keine Rolle. Ein Kompressionsprogramm wird 99,x% der CPU-Zeit im Kompressionsalgorithmus verbringen. Eine schnellere libc bringt da nix. Eine kleinere w?rde eventuell etwas bringen (wegen caches) Es w?rde also reichen, nur das Kompressionsprogramm besser zu optimieren.
Aber ein Kompressionsprogramm - wenn es nicht gerade in Assembler geschrieben wurde - macht doch trotzdem dauernd Gebrauch von Bibliotheksfunktionen, oder? Ich hab mir die Sourcen z.B. von der mpeglib noch nicht angeschaut und w�rde da sicher auch erst mal gar nichts damit anzufangen wissen. Bringen solche Programme auch immer gleich ihre eigenen Math.-Libs mit?
Au?erdem: Optimierung und Nutzung von fertigen Paketen widersprechen sich nicht. Nimm doch die source-rpms oder source-debs und schreib dort deine Compilerflags mit rein. Dann hast du trotz deiner Optimierung alle Vorteile des Pakets.
Ich �berlege schon eine Weile, vielleicht Debian seine 4. Chance zu geben. Erfahrungen damit habe ich schon etwas, seit Hamm habe ich jede "offizielle" Version ausprobiert und auch eine Weile verwendet. Seit Potato �rgert mich der Umfang (9 CDs!) und daher mein Wechsel zu Slackware, dass als Basis f�r mein jetziges LFS diente. �berlebt hat allerdings nicht mal /etc/rc.d - das ist jetzt alles neu geschrieben. Das hat nichts mit Minimalismus zu tun, aber f�r mich ist eines der Hauptkriterien der Umfang. Ich habe zu Hause kein schnelles Netz, aus dem ich mir mal schnell mal ein paar Pakete runtersaugen kann, und auch keinen DVD-Rekorder, mit dem ich mir die Jongliererei mit 10 CDs ersparen k�nnte. Eine oder maximal zwei CDs w�ren optimal. Ich schau mir mal den Autobuilder genauer an, den mir Torsten empfohlen hat. Vom Ansatz her w�rde ich auf jeden Fall ein paketorientiertes System wie Debian vorziehen!
Viele Gr��e,
Matthias