Re: gzip-te libraries

Marc Santhoff <M.Santhoff(at)t-online.de> wrote:
> Am Mo, 2004-02-16 um 17.11 schrieb Bernd Walter:
> [...]
> > Letzlich hat man ja inzwischen die Platten weniger durch Software als
> > durch Daten voll.
>
> Schon, wenn man eine Festplatte einsetzen will. Ich versuche es gerade
> ohne. NAja, dann muß der CF-Speicher eben größer werden. Oder doch eine
> grafische Bibliothek ohne XFree86 her.

Alternativ mehr RAM reinstecken, und auf das (kleinere)
CF-Kärtchen das ganze Filesystem komprimiert drauftun.
Dann beim Booten in eine RAM-Disk auspacken. Angenehmer
Nebeneffekt: Es ist sehr viel schneller, als direkt vom
CF zu arbeiten.

Man sollte im Hinterkopf behalten, daß RAM nicht nur
erheblich schneller, sondern auch etwas billiger ist als
die gleiche Menge Flash.

> Oder gibt es mittlerweile ein funktionierendes komprimierendes
> DAteisystem?

Kein wirklich effizientes, da -- damit mmap() & Co noch
funktionieren -- die Kompression nur mit relativ kleinen
autarken Blockgrößen arbeiten kann und mithin nicht
sonderlich gut komprimieren kann, _oder_ saulangsam ist,
weil für jeden Zugriff ein größerer Block dekomprimiert
werden muß, _oder_ sehr viel RAM benötigt, um die dekom-
primierten Pages zu cachen -- aber da kann man dann auch
gleich wieder zu obiger Lösung mit der RAM-Disk greifen.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"Python tricks" is a tough one, cuz the language is so clean. E.g.,
C makes an art of confusing pointers with arrays and strings, which
leads to lotsa neat pointer tricks; APL mistakes everything for an
array, leading to neat one-liners; and Perl confuses everything
period, making each line a joyous adventure <wink>.
        -- Tim Peters
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message