You will have noticed, that this site is deeeaaaad-slow. Well, that's due to an Apache-restriction, I had to make, because of the vServer limits. There are only two processes serving you - and when the search bots hit this site that results in - uhm - not being able to view this site. ;)
I wanted to try lighttpd, also lovingly called 'lighty', since some time now, but always feared the Debian on the server.... and rightly so.. :-/
The day before yesterday I didn't have any interest in doing the Freevo further - so I took some time for myself and tried to get lighttpd running - here's the story:

We start with a normal SSH remote login to the server. Nothing special here, except for Debian refusing to ship a decently configured SSH/Bash-combination, so that it hurts to use it - no scrollig up, a mess with special-characters, distorted man-pages, problems with 'trailing characters' once you accidentaly hit something with Ctrl. If anybody got an idea how to fix this, I'd be happy - I can't come up with any more keywords to throw at google.
Ok, so after that we do a simple

# apt-get install lighttpd
# aptitude search lighttpd
# aptitude search light

Darn, it's not in the aptitude repository. One really gotta run Debian unstable to have some packages to install (that Debian and unstable - that's a marketing gag anyways, I think - they have testing, too, right? hmm...)
Ok, so, let's see on the web, where we get lighty for debian unstable. Debian has a web-site for that, which is a nice move - but couldn't that be included in the package-management? (Well, perhaps it is - I counted 28 different tools for package-management - though most of them do the same stuff, it might well be, that one of them could look up, what's in the unstable branch.)
Aah, cool - there's it: http://packages.debian.org/unstable/web/lighttpd. I'm happy and go installing:

# wget http://ftp.us.debian.org/debian/pool/main/l/lighttpd/lighttpd_1.4.11-3_i386.deb
# dpkg -i lighttpd_1.4.11-3_i386.deb

(btw - in the code snippets, I intentionally left out all the double tries, where I had to pipe a command to less, because it otherwise ran out of the screen and - remember? - I can't scroll up...)
Well, that didn't work out....

# dpkg -i lighttpd_1.4.11-3_i386.deb
(Lese Datenbank ... 40709 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereiten zum Ersetzen von lighttpd 1.4.11-3 (durch lighttpd_1.4.11-3_i386.deb) ...
Entpacke Ersatz für lighttpd ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von lighttpd:
 lighttpd hängt ab von libc6 (>= 2.3.5-1); aber:
  Version von libc6 auf dem System ist 2.3.2.ds1-22sarge3.
 lighttpd hängt ab von libssl0.9.8 (>= 0.9.8a-1); aber:
  Paket libssl0.9.8 bereitstellt, ist nicht installiert.
 lighttpd hängt ab von lsb-base (>= 3.0-3); aber:
  Paket lsb-base bereitstellt, ist nicht installiert.
dpkg: Fehler beim Bearbeiten von lighttpd (--install):
 Abhängigkeitsprobleme - lasse es unkonfiguriert
Fehler traten auf beim Bearbeiten von:
 lighttpd

Humm... I expected that, so well, back onto the web - let's find another debian package, with a lower version. Debian's own websites won't be much of a help here apparantly. Interesting.. But hey, I read this tutorial on lighttpd's own homepage - yes, there's it, ah, a download folder - good lighty-guys! Oh, hmm.. latest version available there is 1.4.3 - dang, 1.4.11 is already out, but hey - I already lost too much time here, let's go for it.
wget - dpkg -i - you know it meanwhile.
I quickly edited the config-file to point it to a test-folder with a static index.html, since I haven't yet install php-cgi and I wanted to go step by step. Ok, so let's fire it up:

# /etc/init.d/lighttpd start

Whoa - no error messages - I'm a happy man - for a short time..
It doesn't serve pages, it gives an internal server error. Looking through the logs, finding the error, googling for it. Another quarter hour later, I know, that it's a problem with the kernel, that is shipped with debian and I should use a certain lighttpd config setting. Ok - but it doesn't work! Ah, need at least lighty 1.4.7. So again package-hunting on the net. Again the whole game from the beginning. Yeah, serving static pages finally. Ok, on to the dynamic PHP-pages.

# apt-get install php4-cgi

Heya, that's in there, that installs without problems and all looks good. Up to modifying the config of lighttpd. It's only about five lines to add and change, including a slight change in the php.ini for the cgi-version of it. But I get served the page as octet-stream!!! Can you believe that? I get a binary!! I'm going to shorten it here now, since I can't listen to myself any more, regarding this whole shit. I tried a lot, I surfed the fuc#!ng web, I even found something. But either it serves octet-stream or an empty page! Yes, an empty page - and claims, that everything is ok, nothing in logs, crank up log-level as far as you want. In the first try I even managed to use 100% CPU-time on all four of the host-computers CPUs. Great stuff, Debian! And don't come telling me, that 'it's an unsupported package' - god damnit, what do you guys support??

I was incredibly pissed and because I thought since two hours already, that this would have been a quick job on Gentoo, I did the test. I wanted to be in bed already - but I had to test out. So, the Freevo shall get a ))TikiWiki(( anyways, for documenting the installation. I didn't want to install Apache on Igor, because it shall be a lean, mean media machine. Ok, so, there's the test-bed. Let's go:

# emerge -atv lighttpd

The 'v' stands for verbose, which means, that you will see the USE-Flags, that get applied to the packages. And ok, there are some issues. PHP doesn't get compiled as CGI and with apache support. Right, my bad - so I explicitly decline apache and apach2 USE-Flags in /etc/make.conf. Then we want to tune it a little bit more finegrained and want to turn on CGI only for PHP for now, which is done like this

dev-lang/php cgi

Then there is a package, that pulls in ))LaTeX(( as a dependency, because it's documentation is made with it. Ok, we don't want nor need those 80 MB - so we take away the 'doc' useflag for it, no documentation, no ))LaTex((, simple, eh?
Ok, again the emerge command, starts running, then fails on PHP - but guess what: it gives me a concrete and reliable error-message including instructions on how to fix it!! How's that??
Problem is, that I can't use PHP with the recode library, if I use MySQL with unicode-support. So, ok, that's a fast decision and I'm changing my package.use again like this:

dev-lang/php cgi -recode

This takes the recode support away from PHP and now it compiles nicely. Let me mention, that I got the PHP compile error, before even one line of code was compiled! Gentoo's Portage is clever enough to know beforehand, what won't work!
So, after compiling, I have a quick look at /etc/lighttpd.conf - ok, fastcgi PHP support is already configured - actually I didn't expect anything less!

Next I go emerging ))TikiWiki((, I never did that before since I always use CVS-Code, but I'm really good in time, so I can play a bit now. The ))TikiWiki(( ebuild tells me, that I should make sure, that my PHP is compiled with either MySQL or Postgres support and that I will need the 'xml' USE-Flag on PHP for generating PDFs - ah, thanks for reminding! It gets installed into /usr/share/webapps/tikiwiki and pulls in another dependency 'webapp-config'. Never heard of it, but I think "Huh, sounds neat".
Well yes, it is neat, it even automatically creates the Tiki-database for me, but then fails on setting up the virtual host for ))TikiWiki((. I have the USE-Flag 'virtualhost', because I wanted to know, what it does - now I do! ;)
Why does 'webapp-config' fail? Because it is geared towards Apache and after recognizing, that I don't run Apache, it tells me, that I have to do it manually. Well, fair enough. So now I saw enough, know that it's nice 'n fancy and remove those packages:

# emerge -C tikiwiki webapp-config

Very speedily, they are removed and hey, even /usr/share/webapps gets removed. Yes, you read correctly - Portage realized, that I don't need /usr/share/webapps and more - Portage didn't only remove the tikiwiki directory in there - it removed also the webapps dir and leaves me a clean filesystem. That's a bit different as on Debian, where after 'purging' (which should do the same) the lighttpd package, I have to find out, that there are directories left, even with stuff in them!

So, classic ))TikiWiki(( install. Get the files, run setup.sh on them for setting permissions. Go to http://localhost with a webbrowser - aaaand - hmmmm... - what do you think? It works, it works right out of the box! A perfectly running lighttpd/PHP-fastcgi/))TikiWiki(( with no pain whatsoever. I enter my database connection settings (remember, I even already have a database from my webapps experiment), fill the database with Tiki's standard data and there it is - up and running in less than an hour - including compilation! Now, what a breeze - now I can go to bed finally! :)

For you now a comparison chart:

So I have done more in Gentoo and have a better result in about 1/8th to 1/infinite the time. Pardon me, I'm not that experienced with Debian, but I would think, that a guy like me, having some experience with Linux, should be able to set up a simple webserver in seven hours.

Debian is the Emacs of distributions and aptitude the Eclipse of package management tools - all I want and need is a vi, goddamnit.