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.

I wanted to do this since a long time, but always then procrastinated it. But next weekend Püppi's Igor Freevo ))MediaStation(( needs to be ready, because she comes to Ilm and wants to take it with her. So I had a very good reason to set it up now. Especially since I again procrastinated the whole project, because I don't like muddling with hardware - and Igor had to get some new guts in the form of a new mainboard.
Well, after I finally did this last Saturday (and it was pretty painless, only took about an hour or so), I started installing the latest Gentoo 2006.0. And let me tell you - the new installer is not worth a shi# - sucks completely - I lost about a complete day because of it. Going the old-school way, I was set up and running in about two hours.
This time I decided to go with a stage3 and then recompile it completely, instead of doing a plain stage1. Theoretically (and I also believe in the practical aspect ;) ) this gives you the most amazing Gentoo-system possible. Knowing, that I would still have some configuration-work in front of me, I am a little concerned still about the time, the compiles will take. A way to shorten it, would be to distribute compilations. This is especially interesting, since I have a pretty good amd64-workhorse here as my own machine. And this 64bitness also created my most used reason for delaying this DistCC-setup: I need to cross-compile. Which means, that I have to build a complete toolchain (compiler, linker, binutils, kernel-headers also) for a 32bit architecture. It now turned out, that for DistCC-cross-compiling I don't need glibc and kernel headers, but well..
The Gentoo crossdev-package proved a great help here. It emerges all the above mentioned tools suited for the target architecture. It has some flaws still, but turned out, that they can be solved with some smart linking. crossdev doesn't really know, where to look for it's own stuff. :P
I wonder, why they don't put more emphasis on this... seems, like there are not so many people cross-compiling, which actually sounds reasonable.
Setting up DistCC then, was no big problem. There's a good Gentoo tutorial on it, which solves the most common problem easily. Well, so now igor is distributedly compiling in collaboration with the x-compiling ben! :)
Benchmarks are to come, currently I'm running

# emerge -atv --update --deep --newuse world

I think, that something like glibc or qt(which is pronounced cute as I learned today) will be a good target for benchmarking.

So - anyone has a spare iPod for compiling Gentoo on it? ;P

I have been suffering from a lame internet connection, since we got the new provider and the Fritz!Box. I just couldn't really determine, what is the culprit for it being so slow - despite raising speed from 1000 to 3000 kBit/s.

When I some time ago found out, that my flatsharer with his Windoze XP machine, doesn't suffer from performance reduction (that dumbass - why couldn't he tell me that before?!? He knew, that I had problems!!), the only question remaining to me, was:

What cool technology do I use with Linux, that he doesn't on XP?

Well, the answer is simple - IPv6 !

After recompiling my kernel to have IPv6 support as a module and not loading that - weeee, do I have some fast internet! :)

This also explains, why it was much faster with the former setup - using a SuSE 9.1 machine for routing. The Linux-machine knows, how to handle IPv6 - Fritz!Box doesn't... :-/

Let's hope, that they will fix this!

Yup, yup, you can reach this site by http://amette.eu now.

For now it's only a redirect to alexander-mette.de. I don't feel, that .eu represents me better than .de. Though amette is still better than alexander-mette.

What do you think?

So today was the "European Legislation" test, which I feared pretty much - this morning I was pretty sure still, that I won't make it.

But well, it went pretty nicely, with a lot of questioning in the beginning about the development of the European Union. I could pretty much gather points here. After that there was a case to solve, which was really a difficult one. I could have never made it alone, but luckily we were three examinees, so that the work distributed on the three of us. And the other two were pretty good in that, so I only had to add a little bit here and there.. ;)

So, after the 4 in the written part, I got a 2,3 in this oral test today. Pretty good, so today is holiday! The rest I have to do regarding my studies is pretty fun stuff, so I don't bother any more too much. :)