I used to be hosted at http://bergwerk-medien.de before I moved to this crappy vServer. And I also had my screenshots saved there. And out of lazyness (need to adjust my scripts, need to set it up on the vServer, need to muddle around in the Tiki-database to fix links), I didn't move the screenshot-hosting to the vServer yet. Bergwerk-Medien mostly wanted me to go, because they claimed, that Tiki is responsible for their database-corruptions. I fixed that problem as quickly as possible by moving away (and I never experienced database corruptions with Tiki being the culprit).

And some months later that made the admin think, that he can just nuke my homedir on their server. Thanks a lot for the hospitality and not asking beforehand! (Well, my user with his remaining couple of kilobytes homedir was considered 'rank growth' - thanks again!)

So, now I have seven blog-posts (luckily not as much as I thought) with dead links to screenshots. Great! I try to provide permalinks. I use Tiki's internal cache for external HTML, so that you can even later on read exactly, what I was referring to. And now the stuff breaks, which I was providing 'myself' - because someone was in 'clean-up mood'.

I wonder, what the "conclusive backup concept" is, that they promote on their homepage?!?

... so no blog post in almost a month now. What was up?

I was at LinuxTag 2006. And I couldn't blog from there, because the f#*$ing vServer hosting this iste just plain sucks (and I didn't come up with just rebooting it from the provider's web-interface - the Linux-isn't-rebooted-attitude is deep in me ;) ).

I was visiting Püppi at her new home in Düsseldorf for the first time. And while I was there, I noticed, that I missed ))LinuxTag(( completely. It was just in the week after the weekend, where I was in Düsseldorf. So I booked a hotel on short term and just went there. I also ordered a TikiWiki shirt from my spreadshirt-shop and let them sent it directly to my hotel - that worked out very well and now I really know, what that shop is good for! :P

LinuxTag itself was pretty disappointing. Nearly everybody said, that it was worse than last year. I'm not going into detail here - and I'm really sorry for not having blogged during it! :(

The major highlight perhaps was the keynote of Ubuntu founder Mark Shuttleworth - he's a really charismatic guy - just the type of people we need for promoting Open Source!

After LinuxTag I was in Düsseldorf again for a couple of days and then came back to Ilmenau. Need to do some university stuff again - so that I finally get to do some real work soon. ;)

Perhaps the worst about my non-blogging during LinuxTag is, that I won't have my own diary-entries to read back in some years... LinuxTag was fun after all and there surely were some nice anecdotes to tell - but I can't recall them now already, which really is a pity.. :-/

Every year there are the jazz days in Ilmenau, with a lot of different jazz acts from around the world. I went there the first time about five years ago and immediately loved it. Jazz isn't something I necessarily listen to at home - but in some club atmosphere it is just great! And yesterday it was just amazing!! :)

Gutbucket are a 'Punk-Jazz' band from New York. Punk Jazz sounds like coined just for them - and hell yeah: it fits! Currently they are on their 'Sludge Test' tour and stopped by in Ilmenau. With the band and tour name, you gotta concede some skills in wordplays to them. (Gutbucket actually is the bucket in which people used to carry alcohol home, but also a music instrument and also... well, see the logo on the Gutbucket-homepage ;) )
They started slow and pretty melodic sounding like Dog Eat Dog at first. This is surely due to the Saxophone and my lack of being music-savvy, but I think, this claim can be upheld. ;)
When the drummer began thrashing on his drums like Metallica's Lars Ulrich in 'One', I was completely sold at the latest. We finished out cigarettes and beer and moved forward to the stage only to see the Tom Morello of the saxophone. His fingers were unbelievably quick and he was jumping up and down and around all the time - just much smoother than Tom Morello. ;)
There were a lot of comparisons now, but those guys have a style of their own and they quickly showed it. From extremely jazzy cacophony to energetic melodic to the very silent tones there was everything. Combined with the very rocky, punky drums and guitar, that sounded just great! I couldn't get the smile out of my face all the time and already feared sore face muscles (which I actually can feel a little bit right now). Gutbucket were a real evening saver and worth every cent.
I bought a CD afterwards and got autographs from all four of them on it. Additionally I had a fun argument with the drummer about the Star Wars prequels - he really thinks, they are good!? Pfff... at least we agreed immediately on Fightclub being a great movie!

So, people, if you get a chance - go see Gutbucket!! Those guys rock! :)

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