Defying the laws of Common Sense™, I have created some virtual machines with VirtualBox 3.0.8 to run Windows 95 OSR 2.0, Windows 98 SE and Windows Me. There's no practical use for them whatsoever, except maybe testing how good modern websites look on old operating systems and browsers or something, or pushing the emulator/virtualizer to its limits, out of the "safe area".

The thing is, they actually work, to various degrees:

• Windows 95 OSR 2.0 cannot run with hardware (AMD-V) virtualization enabled; otherwise, it will halt the system complaining about a "Windows protection error" when loading some component.
• Windows 98 SE works somewhat slowly in software emulation mode, and crashes very frequently during the boot process when using hardware virtualization.
• Windows Me is unusably slow in software emulation mode; however, it works mostly fine and fast with hardware virtualization enabled, bar some occasional boot-time BSODs.

The network card drivers included with each one work just fine, out of the box even, except that Windows 95 OSR 2.0 doesn't install the TCP/IP stack by default and it's necessary to add it by hand with the Network control panel. And we are talking about software that included Internet Explorer 3, forcibly preinstalled even.

For the video controller I am using the VBEMP x86 driver for Windows 9x (more specifically the 2008.10.21 build) which supports extended graphic modes, up to 1600x1200 with a color depth of 32 bpp. It is mostly stable if not a little slow for some operations, especially when running without hardware virtualization; reducing the color depth and/or resolution should help. The only major problem I have spotted so far is that the screen gets garbled when opening a command (DOS) prompt, but that is easily solved by switching the prompt's fullscreen mode a few times. It also happens at random times when running Windows Me because of some stupid background process that runs from time to time with a minimized console; in such cases, I use CTRL+ESC and then R to bring the Run dialog and start a DOS prompt (command.com) from there and toggle fullscreen mode as required.

It goes without saying that performance may be increased by disabling some features such as window animations, showing window contents while moving, etc.

There's a somewhat detailed tutorial on the VirtualBox forums about running Windows 9x as well, but I didn't follow it, and I found about the VBE drivers from a qemu-related FAQ instead.

Obviously, this is just experimenting with VirtualBox a little too much, and for real work it's better to use Windows 2000 or XP instead. The main motivation for trying these operating systems in it despite Sun's recommendations is that qemu's Cirrus Logic emulation has gone downhill ever since 0.10.0, making the VBE drivers almost a requirement, and the introduction of a resizable window frame in 0.11.0 is more a bug than a feature for me. It is only annoying when running operating systems in resolutions greater than what my KDE 3.5 setup supports because it doesn't play nice with KWin, and when the window gets resized there's no apparent easy way to get rid of the blurry appearance.

I'm not trying VirtualBox 3.0.10 yet since there are no changelog items of my interest at the moment; it's a fairly large download after all.

UPDATE 2009/11/07: updated to 3.0.10, no new problems with Windows 95 OSR 2, 98 SE or Me so far.

I was tired this afternoon after some work and decided to quickly hack something useless.

The result? There's now a little script that displays a random fortune cookie from a copy of the database kept in the Battle for Wesnoth project's mainline repository.

• Wesnoth fortune cookies (undecorated XHTML version here).

(And if you still don't get it...)

Some time ago I was searching for a legendary irssi script that would allow me to use commands like /1, /2, etc. to switch to the respective window numbers without having to type the complete /window command. Although I didn't succeed in my search, one of the freenode staffers gave me a little command to populate the command aliases list with some adequate (99) entries.

That's very nice except that the config file becomes a bit larger.

I was bored last night so I decided to reinvent the wheel and write such a script that doesn't require any client configuration changes to bind the same aliases automagically on startup. I am pretty sure it already existed, but since I couldn't find it...

• window-cmd.pl (1.4 KB)

The installation procedure is the same as with any other irssi scripts.

(... or why I am not a good father, explained in a ridiculously long article.)

As explained in detail in the recently overhauled projects section, Invasion from the Unknown and After the Storm are two campaigns I am maintaining as external add-ons for the Battle for Wesnoth Project with the power of the Wesnoth-UMC-Dev repository. Both are sequels to the mainline Under the Burning Suns campaign, and, in a way, to Descent into Darkness and the infamous The Dark Hordes as well.

One of my first experiments after I became administrator/code technician of the Wesnoth.org forum around Feb. 2009 was porting that little "select code" link that phpBB 3 includes in the headers of [code] blocks when using the mainline prosilver template, to the good old subsilver2 template.

Although it was rather easy to do, it doesn't work in certain browsers (including Konqueror), but the original code used by prosilver doesn't work with them either.

Since someone on freenode IRC pointed out to me that the audience may want to use such a thing in other phpBB 3 forums for those who are die-hard fans of the subsilver2 template, I decided to publish a little modification package here.

• Version 0.1.0 (Zip, 8.4 KB)

Mandatory screenshot at the right.

I am not going to submit it to the official mod database (or publish a ModX-based instructions file) since it's a very small hack for subsilver2, and according to the mod database policies, a prosilver component is required... (?!).

So, I've got a multifunctional printer. It was part of a special discount offer for the laptop I got last December. That's cool and dandy. Problem: it doesn't provide drivers but for that Other Operating System.

I am extremely lazy so I didn't try to find drivers for using it on Debian lenny until just last night a few days ago. Found some references to a japanese website which provides Linux drivers for quite a lot of EPSON hardware (apparently due to some sort of partnership with the original manufacturer): they provide only 32-bit binaries for the printer component's drivers, and not even for the new Debian stable, and building the source code is pretty useless since I cannot figure out their weird post-installation config procedures, which is part of the auto-installing 32-bit binaries, but isn't documented or (apparently) provided in the source code distro.

Hit the nail with a spanish forum post. I had to install a newer version of the Gutenprint driver (lenny provides 5.0, the post stated 5.2.3 as minimum requirement, which also happens to be the latest provided at SF.net). A simple backport from the unstable (Sid) distribution was sufficient.

# apt-get -b source cups-driver-gutenprint

The first hard part was chasing down the generated .debs mixed between the ones from my other simple backport from sid (GIMP 2.6). Okay, not so bad. But then I figured out that the new drivers I was expecting wouldn't appear in foomatic-gui or KDE's printer manager tool (kcmshell printers, although you may know it better for its entry in the Control Center). Uncanny.

Then I figured it would appear in the CUPS config itself.

Next step: scanning with SANE!

With EXA support enabled in the xorg.conf for radeonhd, I started to get X.org lock-ups when resuming from s2disk on the 2.6.28.8 kernel at random times; sometimes after 2 days of uptime, sometimes after just 15 minutes. Since I'm using a laptop with that funny Fn key layout, pressing alt-sysrq-k (SAK), alt-sysrq-u (remount read-only) and alt-sysrq-i (kill all tasks but init IIRC) makes the kernel believe I have pressed alt-sysrq-<insert numpad key here>, which doesn't do anything but set the kernel loglevel. Not being able to see anything on the pitch-black screen, all I have left then is alt-sysrq-s (sync system call) and alt-sysreq-b (reboot) and let fsck replay the ext3 journals while restarting.

Hearing that the drm kernel modules at the freedesktop.org repositories are not updated with the mainline kernel changes, I decided to try out the kernel 2.6.30-rc2. Fear. Despair. It locked up forever while suspending to disk.

Either it apparently did something more than mereley locking up, or the freedesktop.org drm and radeon kernel modules are more broken than I expected, but some hours after rebooting to 2.6.28.8 and doing my homework on the laptop, most of the running GUI programs crashed with random SIGSEGVs and SIGABRTs. Yes, what you read - even the KDE window manager got busted. Interestingly, I could bring it up again with some effort without restarting X, but then I noticed that one of the apps I was working with, Eclipse (3.4.x), didn't want to start again. When launched from the console, it would exit around 2 seconds after being invoked, with no explanation. After fiddling around with my ~/.eclipse dir, restarting X various times just to see knotify and artsd crashing like mad on KDE startup, I started session as another (dummy) user in X and tried to launch Eclipse 3.2 instead - its explanation was a bit more satisfactory: missing libraries.

"Of course", I thought, "the ldconfig cache may have become corrupted".

I kind of hit the nail:

bluecore:~# ldconfig
ldconfig: Cannot mmap file /usr/lib/libartsmidi.so.0.0.0.

ldconfig: Cannot lstat /usr/lib/libartsgui.so.0.0.0: Input/output error
ldconfig: Cannot lstat /usr/lib/libpangox-1.0.so.0.2002.3: Input/output error
ldconfig: Cannot mmap file /usr/lib/libwine.so.1.

ldconfig: Cannot mmap file /usr/lib/libpangox-1.0.so.

ldconfig: Cannot lstat /usr/lib/libpangoft2-1.0.so.0.2002.3: Input/output error
ldconfig: Cannot lstat /usr/lib/libakregatorprivate.so: Input/output error
ldconfig: Cannot mmap file /usr/lib/libartsmidi.so.0.

ldconfig: Cannot mmap file /usr/lib/libpangoxft-1.0.so.0.2002.3.

ldconfig: Cannot lstat /usr/lib/libartsgui_idl.so.0.0.0: Stale NFS file handle
ldconfig: Cannot lstat /usr/lib/libartsbuilder.so.0.0.0: Input/output error
ldconfig: Cannot mmap file /usr/lib/libpangoft2-1.0.so.0.

ldconfig: /usr/lib/libwine.so.1 is not a symbolic link

Apr 21 00:21:56 bluecore kernel: init_special_inode: bogus i_mode (3000)
Apr 21 00:22:44 bluecore kernel: init_special_inode: bogus i_mode (473)
Apr 21 00:26:40 bluecore kernel: init_special_inode: bogus i_mode (55000)
Apr 21 00:26:40 bluecore kernel: init_special_inode: bogus i_mode (0)
Apr 21 00:26:40 bluecore kernel: init_special_inode: bogus i_mode (71165)

My thoughts at that moment: WHAT THE F***** HELL HAS HAPPENED!!!?!?! Considering that I hadn't run Wine for months, and it wasn't running at that moment either... I ran some ls's to see what had become of those libraries... it wasn't pretty. They had become character, block devices and FIFOs. . I rebooted, and fsck still ignored the "clean" /usr (/dev/sda5) filesystem until I forced it to check it all filesystems again by setting their mount counts to some funny values using tune2fs.

Indeed, /usr was corrupted.

After init dropped me to a emergency console to run fsck manually on sda5, running e2fsck threw some interesting stuff, which I forgot to save to a file, but it was something like this:

inode ####### has 'compressed' flag set on an unsupported filesystem
inode ####### has invalid size
inode ####### (fifo) has non-zero size

inode ######## has 'compressed' flag set on an unsupported filesystem
(ad infinitum, ad nauseam)

After it finished, I noticed that the /usr/lost+found directory got populated with files and directories resembling parts of the Python 2.4 and 2.5 foundations installed. Of course, missing entire directories is a really bad sign. But I could recover the affect packages I noticed, with help of apt-get install --reinstall. Those where anything aRts, Python, wine, Pango and Akregator (which I actually remembered to reinstall right now, while writing this), although I reinstalled the Samba server I had installed just some hours before the crash, just in case. Apparently I didn't lose anything else. None of the other filesystems were affected by whatever smashed parts of /usr.

The obvious course of action then was blacklisting drm and radeon, and removing the Option "AccelMethod" "exa" line in xorg.conf, and nuking the 2.6.30-rc2 kernel image just in case. Eclipse and artsd worked again, and nothing else has shown any symptoms of being affected by fsck's decisions since then. It's been just 5 days though, and I have many apps lying around that I only use when asked/forced to, so I don't even remember their names.

I didn't say goodbye to kompmgr, however; it has a pretty decent performance and marginal CPU usage even while using a shadow framebuffer, with just one CPU core enabled at half of its maximum frequency, and even if the system is under load, so I figured that I really didn't need DRI or EXA all the time (radeonhd still doesn't have a opengl implementation, so having DRI enabled made no difference for clients) Still, it was nice to be able to scroll a huge konsole or Iceweasel/Firefox window without experiencing flickering.

Thanks to the help of the guys at the #radeonhd channel on Freenode.net, I could quickly find out how to make DRI (and thus, EXA) work with my laptop's onboard graphics... thingy... I'll let lspci speak for itself; it's much easier that way:

shadowm@bluecore:~$ lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge

[...]
01:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics]
[...]

Let's not forget that this is my current (it was new on December) laptop, not the old, broken lappy, and I'm running Debian stable.

The thing is, with their help I installed a newer-than-Debian (or actually, newer-than-the-kernel-that-is-newer-than-Debian's) radeon drm module, and also solved a little mistake that made X lock up after resuming from suspend-to-disk with DRI and EXA enabled. Now I can enjoy some real 2D acceleration at last!

Although it seems, judging from the git repository's logs, that the official EXA and XRender acceleration support for this chipset is pretty recent, it is very stable compared to a certain other driver for another onboard chipset which I won't mention here. I could even enable KWin's composition manager (kompmgr)!

I have not tried the other big composition/window managers (e.g. compiz), nor intend to, as they require a hardware OpenGL interface which is not available yet for this chipset, and since they are labeled "window managers", I'm guessing that I'll definitively lose the KWin look-and-feel that kompmgr doesn't intend to replace).

Nonetheless, my very limited candy set-up has an incredibly low CPU overhead (either that or the radeonhd driver is f***ing awesome), and I can even let it enabled while in powersave mode, and no matter what I do, I don't see any impact in the other program's performance. I couldn't say the same thing about radeonhd before getting EXA.

One really odd thing I noticed, though, is that kompmgr doesn't seem to want to have anything to do with translucency and pop-up menus. Side-effect, it is KDE (Qt3?) itself who must provide and option for that in the Control Center -> Styles page. But even if I tell it to use XRender acceleration, something doesn't fit - and it is that the changes going on windows below a pop up menu are not seen, e.g. the pop up menu rendering is completely static. This unlike regular translucent windows. I don't know what benefits this design decision may bring, but it's KDE 3.5.10 anyway, and KDE 4 users would laugh at me for my obsession with not switching to 4.x.

Note that I am aware that 4.2.x has fixed a lot of the stunningly awful usability and configurability regressions seen in earlier 4.x versions. But I am still pondering why all Qt 4 widget engines are pretty slow, compared to Qt 3 - so, until I get an answer of the kind "it's just you" or "can be solved" or "has been solved already", I'll not consider switching to KDE 4 an option.

Lately I have had no time to write new blog entries, as I've have been very busy fixing and preparing stuff in Wesnoth's mainline for 1.6. Similarly, my Wesnoth add-on Invasion from the Unknown experienced a new rebirth in December 2008 when I finally got around to make it work properly with Wesnoth 1.5.x and fix some quirks in the mainline game engine which I noticed in the process.

I wouldn't have made it without the support of... heck, too many people actually.

My biggest thanks go to the now MIA Wesnoth Developer and website Administrator, Cycholka/Mist. He made the initial port of IftU for Wesnoth 1.5.0 or 1.5.1 on May 2008, with some help from wmllint and manual fixing, and encouraged me to continue fixing and improving the campaign in this new development branch. He demonstrated great interest in seeing it eventually mainlined. It's a shame that he disappeared shortly after the Grand Wesnoth.org Hard-Disk Crash of July 2008 - not without restoring and repairing the severely damaged website, of course.

Mica and Espreon are some of the youngest members of the community, but without their enthusiasm and encouragement, even IftU for 1.4.x would have been abandoned. Actually, I'd have abandoned even greater things than IftU or Wesnoth without their support. It's also a shame that Mica disappeared last December.

ESR's encouragement and help with the text revisions helped me get around to start improving IftU from Cycholka's port, adding stuff not seen before in the 1.4.x versions. However, ESR went missing for a time, and I got distracted with mainline development. It was not until Patterner, Elvish Pillager, and Loonycyborg started playtesting the half-broken, non-released IftU for 1.5.x around August, that I didn't realize that it was worth the effort to salvage the campaign.

AI0867 removed most of the pressure I had during that time by taking over my role as the lead administrator of Wesnoth-UMC-Dev. He also contributed some critical bugfixes to IftU's WML and English text strings. Kitty's work on the original portraits since October made me take a new route in RL, and at the same time, summon all the possible manpower to polish IftU, fix most (if not all) regressions from 1.4, overhaul some of my original sprites, and get Invasion from the Unknown version 1.10.1a released on Christmas Eve, 11:30 PM CLT (GMT-04:00 + DST) - not without releasing two interim test releases: 1.10.0 and 1.10.1. After releasing IftU, I got my Christmas present from my parents: a new laptop. Just what I needed!

It was a bumpy path indeed, and 1.10.0 was actually scheduled to be released on November 10th 2008. That didn't happen due to the extreme bugginess of the mainline engine at that moment. At the end, the campaign's definitive release announcement on the Wesnoth.org forums is probably the longest one I have written for a long time.

At the moment, mainline is in good shape for 1.6 (with the first Release Candidate published today) and my attention is directed to IftU yet again. Although since the Xmas 2008 release there has been some development in it (1.10.2, 1.10.3, 1.10.4, 1.10.5, 1.11.0 and 1.11.1 have been released, not counting today's 1.11.1.1), there's still lots of things to improve. Recently Solsword brought up some continuity issues in IftU scenarios 3, 8x and 10, which I have addressed, and contributed some text revisions. Thespaceinvader contributed new graphics and code for the Water Serpent unit, and Kitty contributed portraits for a major enemy boss, portraits which certainly exceeded my expectations.

I'm looking forward to see how Kitty will depict the last major enemy boss in IftU, the Shadow Master himself (oh noes!). I also look forward to animate the Elyssa and Shadow Master sprites, and overhaul part of the Shaxthal unit tree (and add animations while at it).

I just stumbled upon this interesting commit message in a git-svn tree I made out of /<trunk|branches/*>/Invasion_from_the_Unknown at Wesnoth-UMC-Dev:

commit def6408717c794e7ac23702978c313e68ed127b4
Author: shikadilord <shikadilord@87cc232e-6748-0410-ac04-a3fa75566414>
Date:   Wed Jan 14 02:31:05 2009 +0000

    Thanks to my awesome time-traveling powers, there are macros in mainline since 1.3.10 or so, wrapping up the [debug_message] tag so I do not need to worry about 1.5.6-1.5.8 compatibility with IftU after the [debug_message] deprecation in 1.5.7+svn.
    
    
    git-svn-id: https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/Invasion_from_the_Unknown@3299 87cc232e-6748-0410-ac04-a3fa75566414

23:27 <Shadow_Master> hey, this is nice!
23:27 <Shadow_Master> look, in the future I was gonna have so many problems with the deprecation of [debug_message] and  my intention to keep IftU compatible with 1.5.6...
23:28 <Shadow_Master> that I sent myself to the past to put some macros into mainline in 1.3.x (Yes, 1.3.x)
23:28  * Shadow_Master now wonders if having done that in 1.3.x will break the space-time continuum

Four Buttons for the Multimedia-maniacs under the window,
Twelve for the UI Designers in their skyscrappers,
Three for the Emacs Men doomed to hack,
One for the Power Source on its dark throne
In the Land of Silicon where the Circuits lie.

I have been victim of a horrendous accident in which the power-on button of my laptop broke to never work again. For a week, I kept beside my desktop computer, to hack and hack Mesiga as I haven't for a long time. Yesterday, I went to the capital to connect to the Internet, inform the Wesnoth project of my situation, and find information about the official technical support offices for my laptop's brand in Chile. (If you're curious, it is an Acer Aspire 5050, and certainly not a choice I liked, but it was a birthday present and I couldn't reject it.)

So, I found a single location at Ñuñoa, Santago. Went there. Talked to the... salesperson. The deal was unacceptable.

The laptop has three hardware problems (known to me) at the moment: pinkish LCD at the middle, non-functional touchpad keys and, oh, the power button that sank like the first ship destroyed by the Kracken on Pirates of the Caribbean II (and this is not a metaphor). The support service would not let me decide what to repair, and they would examine the computer by themselves within a period of 4 work days, and then get me a nice report of what should be fixed and at what price. I managed to convince the man to spit the usual price for repairing the issues I'm aware of, in particular. It was beyond my possibilities. He told me that the other option was to buy the components myself and get someone to replace them.

To hell with them! How can there be a way such laptop components (the display, power button and touchpad parts) can be distributed in the same fashion as their desktop counterparts, and still make profit with that? I mean, WE ALL KNOW that every laptop model has completely different shape and size; worse if we put every manufacturer in the game. There are generic laptops that can be built from scratch with generic components, but if I owned one of these I'd not be coming to your damn offices in the first place!

So, knowing that there is no commercial solution for me, I decided to try and disassemble the laptop.

I removed the panel above the keyboard, and got access to the mechanism of the sunken button. Examining it in detail, there is a push-button below the plastic thing I usually press, just connected to the circuit below. However, that push-button didn't work. So the breakage affected more parts than I suspected, oh great...

Around 2:00 AM, I was examining the board with a non-conductor artifact, namely the remainings of an ink pen's external plastic tube, and while searching for clues as to where was the LED which illuminates when the power is on, I slipped my fingers and accidentally touched (rather impacted) a component which I didn't see, causing the computer to turn on, and notice that the LED seems to be part of a miniature chip. I'm no hardware man and I know little to nothing of this stuff.

Oh joys, so I have two options: either the round push-button below the laptop's cover is a fake button, just put there to make a click sound and have bindings to the circuitry for no reason at all, or it was damaged long ago and the broken external button just made it worse. Because, well, the power button was faulty for a long time; it wouldn't work unless I pressed its bottom-left corner in particular, an almost non-issue for me.

Now, if I only knew how to fix it, I'd be happy, LCD and touchpad aside. Really, I can live with the other problems*, but I want to be able to turn on and off the laptop without having to use OS facilities, which are unavailable when the power is down. For the mean time I'll not turn it down and only use suspend to RAM to let it inactive, connected to a power outlet. I'll have to specially make sure Linux kernel doesn't crash, and that I don't issue a power-off command accidentally.

Since the introduction of the testing SCons-based build system to the Battle for Wesnoth project, I have been annoyed repeteadly by its decreased performance in comparison with the old autotools based system we were using, and its increased power consumption in my laptop.

I felt alone in this world... since March IIRC, until I stumbled upon our Debian packager's blog entry about it just yesterday. *grin*

I cannot deny that Loonycyborg and ESR have done a great job in making the SCons build recipe for Wesnoth better over time, but there are these tiny issues that they cannot overcome without modifying SCons' source code itself and requesting all our users to use a patched version of SCons for that. Nonetheless, it annoys me that users have to install a non-GNU tool to be able to even see the build options for the software. This is certainly one of the good things about autotools: you generate the processed recipe and it will run on any machine with the UNIX or GNU coreutils, a compatible sh* and make! Of course, assuming the author of the raw recipe (configure.ac/in and friends) did not use what is called "bad practice" in it (bashisms, silent environment requirements, etc.). I still have to find a processed autotools recipe (Makefile.in, configure) that fails to run and do its job from a released source code distribution in any FLOSS project.

So with autotools it is rarely needed to install the recipe-processor tools (aclocal, autoconf, automake, autoheader, autopoint) if one wants to run software, not develop it. Yet with SCons and... CMake (the other candidate replacement for autotools at Wesnoth), it is necessary to install the equivalent of Apache server in the client machines for the equivalent of downloading a set of files from a public area of the server. Why?

That said, I'm personally sticking to autotools for managing builds (and have fun tailoring them to temporary needs at times!) in my personal project, Mesiga, until the GNU project comes with a better solution... should that be possible. Moreover, I'd personally maintain the autotools recipe in Wesnoth if our Release Manager wouldn't have been so persistent in the "let it rot" policy.

The fact that SCons project's homepage is filled with propaganda from big people in the software industry such as iD Software and ESR, is even more disturbing for me. It makes me think it... it... IT IS A TRAP! The "What makes SCons better?" section is fearsome... to me it looks like 'featuritis'. There are so many features built into SCons that they are overwhelming to me. Why users have to install this big piece of software in their machines if they just want to build some software, I mean?

And this question has haunted me in nightmares for quite a few months already... because of that, I have been sleeping less than 6 hours a day, so no wonder if I'm writing nonsense here.

Thanks goodness they didn't make adding new source code files to targets harder than with autotools.