Passwords in Firebird

Firebird has some funny ways of handling passwords. The maximum length of passwords that is evaluated is 8 characters. Every character after the 8th is silently ignored. That's especially funny because the 'default' password for a Firebird-installation is 'masterkey', which has 9 characters. You can, however, successfully log in to freshly installed Firebird-servers providing the password 'masterke'.
I'm working with Interbase and Firebird for more than four years and just now realized that when a co-worker at our company found it out while learning SQL.
The only program that I know that makes note of that is gsec, which prints a warning when setting the password to something longer than 8 characters.

Why Crisis Core - Final Fantasy VII disappoints me

Man was I glad when my Crisis Core package arrived. I've been already playing this game since Wednesday and have played 7:30 hours until now.

Crisis Core, in contrast to Final Fantasy VII, does not have tactical battles. In fact, they're the direct opposite: They're random. Really random. Well, of course entering a battle was always random for Final Fantasy VII, but in Crisis Core even your special attacks, materia upgrade and Level-Ups are random! Who on earth had that stupid idea? There's a slot-machine-like thing called DMW (Digital Mind Wave - wtf?) in the upper left corner which spins while you beat your enemies. It spins pictures of characters and numbers. When the pictures match on the first and last slot, the "Limit Verge" appears and depending on the outcome of the middle slot you'll execute a Limit Attack.

Everything here is absolutely not influenced by you in any way. You can't tell the slots when to stop, you can't do nothing. Depending on the outcome of the numbers of the Limit Verge you or your materia might level up if the numbers come out right. Theoretically this means that you can gain two levels in twenty seconds or gain no level at all in 5 hours. More fighting doesn't necessarily increase your level either. Well, obvisouly Squeenix was smart enough not to make it as random as a true random number generator, but it's still unpredictable.

The Limit Attacks are somewhat strange, too. Sometimes there are some FMV sequences that tell a part of the story -- right while you're battling totally unrelated enemies or you are on a mission or something, before the attack begins. I don't understand this at all, it makes no sense to me.

You don't have weapons with materia slots, either. In fact, you don't even have different weapons! Instead you have a fixed number of materia slots where you can put your materia, which sometimes increases when finding special items or so. At least you have two Accessorie-slots in the beginning... but again, no weapons. This actually pisses me off most. There are no connections between materia-slot, no slots with doubled materia-exp-increase, no new weapons that do more damage, nothing.

And then there's Material Fusion. You can fuse any two materia together to gain a new one. The outcome, however, is always sooo teeny-weeny better than the originals that it almost never brings you a significant advantage. Plus, you can't predict the outcome at all and sometimes you basically just lose one of the materia, while the other stays the same. Absolutely useless.

Then there's the difficulty of the game. Being a hardcore-gamer I picked the Hard Mode over the Normal Mode. It lasted 30 minutes and I nearly threw my PSP through the room, out of desperation. I died multiple times on the first hard enemy, and the bad thing about that was that there's 5 minute sequence that YOU CAN'T SKIP before that battle. Oh jesus how I hate this! That was the reason why I didn't finish God of War, too, by the way. Un-skippable sequences are the most sinful thing a game-developer can ever do. (By the way: In Crisis Core you can ALWAYS interrupt the game by pressing Start. This somewhat makes up for not being able to skip sequences... but only somewhat.

So I decided to start from the beginning in the Normal Mode. This was a good decision, because the game basically becomes child's play after that. It's actually so easy that it's making it boring at times. Most of the time, when hitting the enemy, it's pushed back and gives you time for the next slash. This makes matches where you don't get a scratch on more than common.

The mission system is used for leveling and resembles Monster Hunter in many ways. Because you're more often in areas without enemies than you were in Final Fantasy VII, it's harder to run around and level up as I often did in the original. The missions kick in here, which you can enter on every savepoint. Pick a mission by category and difficulty, enter it, beat it, get a reward, go on to the next mission. Those are always in the same environments, like the various levels in Monster Hunter. Missions are actually a bit less boring than running around on the field to fight the same monsters over and over again. That's what I did in Final Fantasy VII for hours... or well, actually even for days and weeks. :-)

Oh and here's the moooooost disappointing thing ever: You don't have a party! You're always running around alone as Zack and you can't switch party members! That's so unbelievably boring!

There are good things about the game anyways and it's quiet fun to play, but I must say that I would have more fun if I put FFVII on my PSP again and played that for the nth time. It's just so much more tactical and muuuuch deeper than Crisis Core. Crisis Core seems to be meant for the occasional gamer and not the typical Final Fantasy RPG fan. It's more an action game with a good story than an RPG if you ask me. I hope that there are at least 60 hours play-time in that game, but I'm not too sure about that yet... I'm looking forward to find out more as the story continues, maybe I'll write some positive aspects of the game after I've finished it.

That being said, the game is still much fun. But again, it's not as much fun as Final Fantasy VII was.

New hardware for my lil server

I recently ordered new hardware for my little file-serving, downloading and IRCing box. As the nature of this 'server' is to be always on and not demanding powerful hardware, I went for the following components:

• Intel Celeron 420 (1.6GHz, Single-Core, 35W power-consumption)
• ASUS P5B-VM Motherboard (5 SATA-ports, GBit ethernet, on-board VGA)
• Crucial 1GB DDR2-667

The hardware that was being replaced was:

• Tyan Tiger motherboard
• 2x Pentium III 1GHz
• 2x 512MB SD-RAM
• 2x Adaptec 1210SA
• 1x Intel 1GBit Ethernet (eepro1000)
• ATI Radeon 8500

(Note that I currently have the Intel Ethernet adapter still plugged in since network didn't work out of the box and I haven't found the time to fiddle with it, yet).

As you can see this box is optimized on low cost, low power consumption and replacing as many of the old parts as possible. At a total of 136 EUR (the CPU was only 35 EUR!) including shipping, I'm really satisfied. One additional Adaptec controller would've cost 50 EUR and would've added only 2 SATA ports, so this was probably the best solution. I still have 2 SATA ports unused on the mainboard and have 2 SATA-controllers lying around ready to be plugged in if even those will be used up. Finallly I have potential to grow my RAID even bigger. :-)

Fixing raid-5 failures, the adventurous approach

You might remember the trouble I had with my raid5 before. Well, it's still not 100% sorted out, but I know the cause now. It really was a faulty drive! I came to notice that after I replaced the motherboard, CPU and RAM with new components. After I've added them and booted into the system (which worked flawlessly on the first try, by the way, although the hardware is absolutely unrelated to the previous one) I noticed a click-sound from one of the harddisks. I immediately realized that I bought new hardware for nuthin. But at least I was sure which component was causing the failure now, plus I got 5 free SATA ports to upgrade the RAID. Previously I had non unused ports, leaving no potential for a possible upgrade. But somehow the raid got messed up in the process. I wasn't able to assemble it with the remaining 3 discs because one disc was always added as spare. So I had 2 functional devices and one spare added, which is obviously not enough to run the raid. This is due to some corrupted superblock, but luckily the superblock is just metadata which can be recreated. If I knew the correct devices and slots they corresponded to before all this happened, I could've created the array with mdadm --create and the correct params. Unfortunately, I did not know the exact params so I had take a more... adventurous approach. There's a perl-script on the linux-raid wiki which permutates over each possible combination of devices (including one missing device) and tries to mount the created array. It does everything in read-only mode so no actual data is being touched, only metadata. If it could mount the raid it prints the mdadm --create command used to build it, stops the array and goes on. You can then execute the creation-commands yourself and see if everything's right. In my case, luckily it was and I got all my data back. Note that I had to connect the failed drive for this to work because it always replaces one given device with 'missing' ('missing' tells mdadm that this device is, well, missing) instead of adding 'missing' to the devices-list. This is because it's not supposed to recreate a partial, but only a complete array. So you need to provide ALL raid-members to the command-line, otherwise it won't work. It should be fairly easy to hack the script to work for partial arrays, too, but it was easier for me to add the drive again than to hack perl-code.

After this the raid was up and I needed to mark the drive as faulty and remove it so it can't cause problems anymore. It's always a bit problematic to map the device-names (/dev/sdx) to the real harddrives and you might pull out the wrong one, possibly leading to more problems. I found out a reliable way to identify the drives:

hdparm -I /dev/sdx | grep 'Serial Number'

This will print the serial number, which usually is visible on the actual discs, too. Somehow the -I option to hdparm never occured to me before. The serial-number matched one of my disks and so I was able to locate and remove the faulty drive.

Yay!

Next step is to contact the reseller for a replacement. I hope the next bad drive will be less problematic.

Qt debugging with Visual Studio 2005

zbenjamin, one of the fine folks from the Qxt-project just gave me his additions to the AutoExp.dat-file that lets you debug native Qt-types (e.g. QString) far more easily. Here's the before/after-comparison:

Before

After

How it's done

And here's what you have to do to use it yourself:
First, open up the file

C:\Program\ Files\Microsoft\ Visual\ Studio\ 8\Common7\Packages\Debugger\autoexp.dat

Important: Under Windows Vista, you need to open the file as Administrator, because it is not writeable by the user and the program-files-virtualisation will get in your way.

Then, add the following lines under the [AutoExpand]-mark:

QObject =classname=<staticMetaObject.d.stringdata,s> superclassname=<staticMetaObject.d.superdata->d.stringdata,s>
QList<*>=size=<d->end,i>
QLinkedList<*>=size=<d->end,i>
QString=<d->data,su> size=<d->size,u>
QByteArray=<d->data,s> size=<d->size,u>
QUrl =<d->encodedOriginal.d->data,s>
QUrlInfo =<d->name.d->data,su>
QPoint =x=<xp> y=<yp>
QPointF =x=<xp> y=<yp>
QRect =x1=<x1> y1=<y1> x2=<x2> y2=<y2>
QRectF =x=<xp> y=<yp> w=<w> h=<h>
QSize =width=<wd> height=<ht>
QSizeF =width=<wd> height=<ht>
QMap<*> =size=<d->size>
QVector<*> =size=<d->size>
QHash<*> =size=<d->size>
QVarLengthArray<*> =size=<s> data=<ptr>
QFont =family=<d->request.family.d->data,su> size=<d->request.pointSize, f>
QDomNode =name=<impl->name.d->data,su> value=<impl->value.d->data,su>

Now restart Visual Studio and you should be good to go.

More slime goodness

Remember the Slimy Lisp Video I've posted earlier this year? Well, some other blogger, Peter Christensen has put more effort into it and has written a reference/annotation for the video, including a timeline, a transcript of important parts and introductory explanations on how to set up SLIME to use that video. This will give SLIME-beginners an even better kickstart.
Thanks very much for your effort, Peter!

Fixing my software raid-5 with mdadm

On my server-box I have a software raid-5 /dev/md0 consisting of 4 500GB SATA-harddisks, namely sda1, sdb1, sdc1, sdd1. When I was working on my other box where I was pulling off some dd-stunts on a lvm-volume my raid suddenly died on the server. There was some output in dmesg that both sda and sdb are somewhat corrupt and that they've been removed from the raid, leaving it unfunctional (you need to have at least n-1 disks in a raid-5 to keep it operational). I was very shocked by this. I restarted the PC and tried to re-assemble the raid with

mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

to no avail. mdadm said 'bad superblock on device /dev/sda1' (or similar) and leaving out sda1 worked and I had the mdadm assembled with 3 out of 4 disks. That's of course not satisfactory. I stopped the raid and ran S.M.A.R.T.-checks on each of the 4 disks with

smartctl -t long /dev/sdx1

. This took over an hour so I went to sleep and checked the results the next day -- 100% error-free, according to smart! That's really strange. Assembling the array still does not work because of sda1. I opened up sda in cfdisk and saw the exact same partition-size as on sdb and the others, but I knew that something was corrupt. So I wrote the partition-table to a file to back it up, removed the partition and re-added it. Then I used

mdadm --add /dev/md0 /dev/sda1

to re-add the partition that was formerly part of the array, anyways... mdadm did it's job and recovered the raid. You can watch the progress by doing

cat /proc/mdstat

. It took around 7 hours or so to complete, and now the raid5 is fully functional again.
What a horror-trip! I'm still wondering what was going on and why sda1 has been kicked out of the array.
A small addition: After I've fixed the raid it was ok for a day or two, but then one day when I came home I noticed it broke again. I remembered that I stepped onto the USB-keyboard that was attached to the server right after I came home and found an unhandled IRQ-oops in the kernel-log at what happens exactly that timespan. So my suggestion is that the USB-handler somehow messed up something, which in turn has killed the RAID again. But I'm still investigating the issue, for now rebooting and forcing the assembly worked fine. I hope I'll not have any more problems with it...