>> How do you take a picture of an OS?
>
>    "iPhone 4S" is not an OS. It's a cellphone.

Hmm, interesting...

>> after all, 10MB is enough space to store the contents of
>> an entire *library*, right?
>
>    Not really. A medium-length book may well take 1 MB to store, especially
> if you store layout and style as well.

I think my numbers are off slightly. Regardless, the original quote 
[which I can't seem to find now] was that "in 10 years' time" computers 
will have so much storage that you can easily store a textual 
representation of everything that ever happens in your life.

Think about it. I've got a file somewhere which contains a complete copy 
of The Holy Bible. It's 0.5MB. And that's quite big, as books go. So 
with a 3TB HD, I ought to be able to store quite a few books. If we 
assume 1MB per book, that's... over one million books. More material 
that you can read in a single human lifetime.

The point being, when they wrote that, they were assuming that text is 
all you would ever use computers to store. Consider the possibility of 
storing graphics, sound and even video, and suddenly 3TB doesn't seem 
very big at all. Suddenly it starts to actually look kinda small... and 
that's something that writers decades ago wouldn't have foreseen.

>>>     zlib consists of a lot more than just two functions.
>
>> And here I was thinking it just takes data and returns compressed data...
>
>    It's not that simple. There are many places where you could be reading
> from or writing to. For example if you want to decompress from RAM to RAM,
> that's a completely different process than if you want to decompress from
> a file to RAM streamed (iow. you don't want to load the entire compressed
> file to RAM at once). Compressing is even more complicated because you have
> all kinds of options. Then there are utility functions to make this process
> easier so that you can skip the nitty-gritty details if you don't care about
> them.
>
>    (Remember that zlib is in C, and hence there's not much abstraction.)

I had expected the zlib itself merely takes a pointer to a buffer full 
of data, and a pointer to an empty buffer, and moves data from one to 
the other, compressing or decompressing as requested. I'm surprised it 
actually implements anything as high-level as file access.

Post a reply to this message