X-Git-Url: https://git.sesse.net/?a=blobdiff_plain;ds=sidebyside;f=files%2Ffaq.html;h=c07aa567d5ddd8a422f6300db1cf0dffb0bfdf1a;hb=388116cb107c3cae1f53a264caa324a367f01a5c;hp=55d93bc4839e127bde493f8f5af45c022dcaf25a;hpb=9d3807c2b196f5845e8657c40a5419fc6e4269bb;p=pr0n diff --git a/files/faq.html b/files/faq.html index 55d93bc..c07aa56 100644 --- a/files/faq.html +++ b/files/faq.html @@ -9,7 +9,7 @@
Last updated April 13th, 2007
+Last updated November 20th, 2015
Yes! By Norwegian law you have the right to deny publication of an image + where you are identifiable (with a few exceptions). Just send me an e-mail + (see below) with the URL of the images you want removed, and I'll remove them. + No questions asked.
+Probably the requested size was never generated before, so the server @@ -54,7 +61,7 @@ so the next time somebody views the same images in that resolution, it will be snappy as usual.
-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 my @@ -68,36 +75,37 @@ Also, it has dynamical rescaling (of good quality â proper, sharp thumbnails, no crappy nearest-neighbor scaling) of both thumbnails and images (most client-side scaling sucks quality-wise, unfortunately), - an easy-to-use WebDAV-based upload + an easy-to-use HTML5 upload interface, cache awareness and in general good performance (being a set of persistent, optimized Perl modules; I've seen it throw out over 300 - hits a second even without the Squid in front, but I won't guarantee it + hits a second even without the Varnish in front, but I won't guarantee it would withstand a Slashdot attack ;-) ). Also, it has quite OK skinning capabilities, so it's able to adapt into different designs quite easily.
pr0n currently runs on an Athlon 64 X2 3800+ with 4GB RAM and ordinary - 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 Apache 2.2, mod_perl 2.0 and ImageMagick 6.x (as well as various - other Perl modules), using PostgreSQL 8.2 as the back-end - database for metadata et al. The base operating system is Debian lenny (ie. âtestingâ).
+pr0n currently runs on two Intel E5-2650v3 (2x10 cores at 2.30GHz) with 64GB RAM and + SATA disks, with some SSDs in front for cache. (The server does a lot of other stuff besides running pr0n, of + course.) pr0n itself is a custom-made system by myself, + a PSGI + app server running under Starlet + behind Varnish 4.1, + using ImageMagick 6.x + (as well as various other Perl modules) and + qscale, using + PostgreSQL 9.4 as the back-end + database for metadata et al. The base operating system is + Debian jessie.
The Perl modules aren't really that big â we're talking about only - approx. 2500 lines of code (of which ~25% is the WebDAV part; I should - really make that a bit cleaner once). Most of the real work is done by + approx. 2600 lines of code. Most of the real work is done by the software on which pr0n builds on.
At the time of writing, approximately 72GB of image data (that is, over - 46000 different images), plus cache, plus metadata in the SQL database. +
At the time of writing, approximately 720GB of image data (that is, over + 195000 different images), plus cache, plus metadata in the SQL database. (These numbers are growing rather rapidly, so they could be outdated at any given time.)
@@ -106,10 +114,10 @@Probably, but are you sure you can get it to work? It's non-trivial to set up, as it depends on lots of odd modules and a lot of custom configuring; this is not a pre-made, user friendly package for your - favourite Linux distribution. There is a bzr repository at - http://bzr.sesse.net/pr0n/, but + favourite Linux distribution. There is a git repository at + http://git.sesse.net/pr0n/, but I'm not going to hold your hand configuring it. :-) (Hint: If you do not - know what bzr is, and cannot find out on your own, pr0n is not for + know what git is, and cannot find out on your own, pr0n is not for you.)
Unfortunately, no. When and if somebody makes a sane framework for - making WebDAV servers I can use, it probably will, but ATM it's just - too much work for what I need it for. It would be a lot easier if - I only had to support WebDAV level 1, but due to silly restrictions - in Mac OS X' WebDAV client I have to support WebDAV level 2 as well, - and, well, most of that is faked. ;-) In addition, there are multiple - minor features in the system (like autorenaming files on name clashes) - that just aren't easy to adapt to WebDAV. The WebDAV service is - restricted, though, so I guess rather few people will get hurt just - because I'm not fully compliant ;-)
-Try e-mail, or reach me on IRC as Sesse on EFnet, IRCnet, Freenode or OFTC.