so the next time somebody views the same images in that resolution,
it will be snappy as usual.</p>
so the next time somebody views the same images in that resolution,
it will be snappy as usual.</p>
<p>Because it didn't fit my needs, and the same goes for all other systems
I've seen. I wanted something no-nonsense that would work for <em>my</em>
<p>Because it didn't fit my needs, and the same goes for all other systems
I've seen. I wanted something no-nonsense that would work for <em>my</em>
SATA disks. (The server does a lot of other stuff besides running pr0n, of
course.) pr0n itself is a custom-made system by myself, tightly coupled
into <a href="http://www.apache.org/">Apache</a> 2.2, <a
SATA disks. (The server does a lot of other stuff besides running pr0n, of
course.) pr0n itself is a custom-made system by myself, tightly coupled
into <a href="http://www.apache.org/">Apache</a> 2.2, <a
href="http://www.debian.org/">Debian</a> lenny (ie. “testing”).</p>
<p>The Perl modules aren't really that big — we're talking about only
href="http://www.debian.org/">Debian</a> lenny (ie. “testing”).</p>
<p>The Perl modules aren't really that big — we're talking about only
really make that a bit cleaner once). Most of the real work is done by
the software on which pr0n builds on.</p>
<h2>How much data is there in there, anyway?</h2>
really make that a bit cleaner once). Most of the real work is done by
the software on which pr0n builds on.</p>
<h2>How much data is there in there, anyway?</h2>
- <p>At the time of writing, approximately 115GB of image data (that is, over
- 67000 different images), plus cache, plus metadata in the SQL database.
+ <p>At the time of writing, approximately 140GB of image data (that is, over
+ 72000 different images), plus cache, plus metadata in the SQL database.