So, I have a HP laptop; a Pavilion dv5-1132la, to be specific. It's pretty, it has some fancy multimedia buttons, a fingerprint reader, an annoying and huge illuminated logo on the lid, yet another of those fantastic touchpads that break near the end of the warranty period, a fan (a.k.a. hair magnet) that's impossible to clean without disassembling the whole machine, an utterly useless fingerprint reader, some Lightscribe thingy which I don't use, and yet another on-board graphics adapter from ATI that has very, very poor support in the Linux world. I couldn't choose otherwise — it was a Christmas present and I was really, really desperate.

Since Wesnoth uses 2D rendering (with plain SDL primitives) for everything, I do not need accelerated 3D rendering for software development. However, people in RL have asked me why I don't have fancy desktop effects (gaa, Compiz) or play 3D games like other Windows and Linux users do. And even worse, a handful of Wesnoth developers and artists started a side project that uses OpenGL for 2D rendering!

So, last Friday I finally got around to upgrade from Debian Lenny (Stable) to Squeeze (Testing), but not without facing some problems: network-manager got restarted too early while I still needed to download more packages to finish the upgrade, I got stuck for 20 minutes trying to convince cnetworkmanager to make the wifi adapter work again until I figured out I just needed to restart D-Bus, the Linux kernel package v2.6.30-2 in Squeeze has some patches that rendered the wifi adapter completely useless after restarting, had to quickly rebuild a custom kernel to solve that, and work with Squeeze's udevd and get rid of the annoying default console bell (BEEP! — in a university library, thrice), and then had to build another kernel enabling PAT support because the new X.org needs it for some reason or radeonhd gets unusably slow — phew.

It was much better than I expected and the migration from KDE 3.5.9/10 to 4.3.1 was relatively seamless; Opera 10.0 and VirtualBox 3.0.10 for Debian lenny still work fine after the upgrade, and KDE 4 didn't try to eat my /home dir, nor did I try to prevent that after all.

After a few hours of using the new desktop environment I started to like it. IMHO, rumors of KDE 4's suckiness are being greatly exaggerated now that it's at 4.3.x.

Of course not everything is perfect, and I hit a very bad bug in Dolphin, KDE 4's lightweight file manager, which turns it into a time-bomb of sorts, crashing roughly after 1 minute of use. However, that bug doesn't affect good old Konqueror and that gave me an opportunity to go "whoaaah" and "ahhhh" and "ohhhh" at the various user interface changes in this version; for example, the previews of directories are much better than on the KDE 3.5 version of Konqui — now we have actual previews embedded on the directory icons, rather than little icon overlays. IMHO such feature belongs in the realm of eye candy, but there's still a fair possibility of revealing your pr0n stash if you navigate the parent directory with this enabled.

KDE 4.3's performance here is far better than what I experienced with a amd64 openSUSE-based LiveCD image using KDE 4.2.x. I couldn't know if this is because it's Debian, or because it's KDE 4.3, or because my custom kernel config rocks. Regardless, the laptop's battery still lasts almost the same as before upgrading to Squeeze — roughly 45 minutes. Of course, although I did enable some eye-candy to give radeonhd's XRender acceleration a decent work-out, I made sure that the new power management applet will turn it off when running on batteries. This is all very handy and beautiful...

But Squeeze lacks an important component for me, uswsusp, which provided some reliable work-arounds to get my laptop working fine both before and after suspending to disk (S4 power state). It is currently excluded from Squeeze due to some rather astonishing bugs, which means I had to seek other solution for suspending my pretty Linux system to disk...

And the solution in my case is the TuxOnIce patch, which surprisingly manages to bring the screen, keyboard and touchpad back to life — a feat that the kernel's built-in S4 support won't perform here. With this patch applied on top of an otherwise vanilla Linux kernel I now have a completely usable Squeeze system that supports all the hardware and software features I need.

I switched from openSUSE 10.3 to Debian Lenny when it was the testing distribution back in... November 2008 IIRC. I also installed it on my HP Pavilion dv5-1132la laptop — which I received for Christmas the same year and still use as of this writing — but I continued tracking Lenny instead of the new testing distribution when Lenny became the new Stable on February 2009.

Defying all laws of Common Sense™ (again!), I'm now going to try to switch “back” to Debian testing — which is, this time, Squeeze.

I admit that I feel a lot of curiosity for trying KDE 4.3, but I also want to see how well are some other software packages doing: uswsusp, freetype, the GIMP, Iceweasel, VLC media player, and Boost, among others. I'm currently using a few packages that I built from their Sid sources with Lenny:

radeonhd module for X.org - constantly updated from the upstream git repository's HEAD

kvirc 4.0.0 RC1 + svn (r3496)

I love how well Debian has worked for me till now — despite running across some really, really bad issues (my fault) compromising the installed system's integrity, I've never needed to reinstall the distribution and I had forgotten how often Windows users need to reinstall everything when a single piece breaks. Although I'm running a kernel version greater than the one Debian Lenny ships with I've had mostly no problems except a very random bug with Audacious that crashes it when playing MP3 audio files.

So why would I switch to Squeeze if I seem to be perfectly safe and comfortable with my current system configuration?

I want to check any new and shiny stuff included with newer versions of the Boost library, which is an essential dependency for the Listra and Thoria, tools that I'm writing for the Wesnoth-UMC-Dev project.

I want to try KDE 4.3 in a live environment.

The VLC media player version included in Lenny is a bit “outdated”, the Squeeze/Sid versions pull dependencies not available in Lenny, and the upstream package is also a bit difficult to compile since apt-get build-dep won't help me here.

Firefox/Iceweasel 3.5 is hopefully more stable than Firefox/Iceweasel 3.0 (it's not a problem specific to Debian's fork, really) so it could be an opportunity to recover my faith in Mozilla...

I want to try KDE 4.3 in a live environment.

The version of scons which ships with Lenny has some mildly annoying bugs.

Did I mention I want to try KDE 4.3?

I don't really expect to have much trouble upgrading, but I've backed up my /etc and /srv trees, some stuff from /var, and not to mount the partition for /home on the first reboot with Squeeze; I'll be using a minimal /home tree from the rootfs partition first. It helps that I'm using separate partitions for /var, /usr, /usr/local, /opt and /home since day zero. Maybe I'm being slightly paranoid — why would KDE 4.3 kill my home dir anyway?

And, in case of emergency, I'm armed with a Debian GNU/Linux 5.0.2 DVD and a really, really BIG gunapt cache.

<+shadowmaster> ... I have acl, cs_info, and ns_info aliases on irssi.
<+shadowmaster> for some reason I tend to type ns_info when I want cs_info (for /msg ChanServ INFO)
<+shadowmaster> maybe I should just write a script for the /info command that decides which one is the correct service for me.

So here's a quick 5-minutes hack to patch my incompetence. This little irssi script introduces the /AINFO command for querying freenode's services (which are from the Atheme package) for information on a nickname or channel. I don't need to check whether I am querying the correct service anymore. Yays.

Time for another subsilver2 modification of my own! In this opportunity, it's a barely tested but probably perfectly safe hack to display the same user profile information in post footers as the prosilver style does in phpBB 3.0.x.

Basically, phpBB 2.x displayed the author's website URL, MSNM/WLM, AIM and ICQ ids in every post footer if they provided such information in their profile; this behavior is kept in phpBB 3.0.x, adding Yahoo! Messenger and Jabber links. However, for some strange reason these links are not included in the subsilver2 style, so only prosilver users can see these shortcuts in the viewtopic pages — subsilver2 fans must go to the user's profile instead.

This extremely simple template hack restores the subsilver2 shortcuts, providing an extra tiny bit of consistency for forums that allow users to choose between the good old subsilver2 style, and the shiny prosilver.

The script in question is one of my earliest experiments with bash scripting, and as such suffers from the quirks of a novice programmer trying to get work done fast. It's some sort of crapload of hacks that just ‘‘works’’, somehow. I have an odd habit of tempting fate and using my earliest programming experiments in production environments — and this includes Shikadibot and Soradoc, which is the PHP-based layout code generator used both here and at the Wesnoth-UMC-Dev website.

The only reasons for not killing it are the following features offered to the selected few who know how to use it:

It reliably produces a .tar.bz2 archive for add-on distributions on regular websites — including SF.net — provided a few simple arguments.

It roughly* conforms to the Wesnoth .ign file syntax, although it doesn't provide the same defaults as the game engine.

It knows how to cleanly handle SVN check-outs.

There's built-in, automatic support for XDelta patch generation, provided the xdelta tool is installed and in PATH.

Provides MD5 and SHA1 digests of produced packages and writes them to .MD5 and .SHA1 files for distribution.

No suitable replacement has been provided yet.

* Espreon pointed out on the #wesnoth-umc-dev channel at chat.freenode.net, that build-external-archive.sh may match .ign patterns only in the add-on's root directory, and not in its subdirectories. This, of course, a bug.

build-external-archive.sh has got a few inoffensive bugs in the past, perhaps the greatest of which was a set of dependencies upon Linux distribution-specific conventions (why, hello there, openSUSE!). However, yesterday I hit the nastiest, yet unseen bug.

Since I usually use actual SVN tag check-outs for creating the packages, or get someone else to do it for me, I had not checked the interactions of this script with an input directory that is actually a symbolic link pointing to a directory containing files or paths matched by a _server.ign file. This tool needs to copy the input directory to a separate temporary directory in order to physically remove the files (actually copies) that match the aforementioned .ign patterns, and then proceed to run tar to wrap the modified temp directory into a nifty bzip2 tarball.

And how was it copying the input directory to /tmp when the input is not a SVN check-out? Without going into much detail, it is similar to this:

The -a switch to GNU coreutils' cp is equivalent to -dpR, which roughly means ‘‘be recursive, preserve timestamps, access masks and never dereference symlinks and preserve them!’’ So you can start to imagine why this would become a huge problem when the $input_directoryis a symlink.

Such a small overlooked mistake ended up destroying the git-svn tree contained within my add-on's directory, which was indeed specified as a symlink in ~/.wesnoth-1.7/data/add-ons/After_the_Storm pointing to ~/src/wesnoth-umc-dev/git/trunk/After_the_Storm. The symlink itself was copied to the temporary directory and the removal of unwanted files took place on the original location instead of a temporary tree. This gave me that disturbing feeling of having a bucket with cold water dropped on my head whenever I accidentally remove files I wasn't supposed to remove. Thankfully, I had committed all my changes to the upstream SVN repository and only had to regenerate a git-svn tree to continue working after making the release using a fallback SVN check-out.

The correct pseudo-code, forcing symlinks to be dereferenced and timestamps, file modes and ownerships to be preserved, is actually:

As you can see, it's perfectly easy to screw up your own files with a technically small mistake in a command line. However, in this case some idiot (me!) didn't read the manual correctly and didn't notice that the -a switch had additional effects, and that's a big logical mistake. Fortunately, only Espreon, AI0867 and I rely on this script, as far as I know.

This tool is going to be eventually replaced by umcdist (codenamed Blackwater), which is written in manageable Perl, provides the same functionality plus archive signing with OpenPGP, and would be done in a few days if I actually concentrated on it — don't take me wrong, it exists and there's code written for it, but it still needs to be completed. Whereas build-external-archive.sh is a deliberately undocumented IftU-specific tool that was later inherited by the wesnoth-umc-dev project, umcdist is targeted to the project as a whole, it will have proper online and built-in documentation and it'll be readable by more than one person to allow easier bug-fixing and maintenance.

So, last night, I was trying to uninstall some software while using Windows Vista in ‘‘safe mode’’.

... but apparently you cannot uninstall Windows Installer-based software when running in safe mode. What the hell.

The screenshot comes from Windows 7 RC 1 but this problem also applies to earlier versions. Windows XP and earlier won't display any warning at all though — you will just be mercilessly thrown back to the Add/Remove Software control panel.

Apparently Windows is built upon the assumption that I won't want to save disk space and overall performance by disabling System Restore and, that way I cannot uninstall problematic software while in safe mode. Why would one to do that anyway? Well, some software components may run automatically whenever one logs into their account, and maybe the software isn't working properly and locks up the Windows desktop or maybe the entire systems when it runs. Granted, I could stop the software from automatically running when logging in using the Registry Editor or msconfig.exe... and hopefully it's not a shell extension that locks up the Windows desktop, though — those are harder to remove by hand, but I guess there are third-party tools out there (um, hopefully certified by Microsoft to be safe?!) to help in such cases. Then again, why can't I enjoy mass-removing software with the improved performance that safe mode implies? So, why shouldn't the Windows Installer service be able to run in safe mode? (Why is it supposed to be a system service that runs on the background stealing precious system resources anyway? Okay, Windows doesn't start it automatically unless some application demands it, but it'll continue running on the background after it's finished.)

Maybe all these limitations are useful or bearable to the regular ‘‘non-computer person’’, but when the software I use doesn't let me do what I want, the way I want, I feel like it's secretly laughing at me as if it was some sort of evil trap.

Fortunately there are still sane software developers out there that don't use the Windows Installer system, even if that means that the user and application programming interfaces for managing software packages in Windows will never be as consistent as they are in GNU/Linux distributions such as Debian (dpkg) and Red Hat (rpm) based ones.

And talking about Debian, dpkg and apt-get run perfectly fine here on the single-user runlevel. YaST2 (which has, amongst other nice things, a rpm front-end) also works under such conditions on openSUSE.

It's been less than a year since I bought this HP Pavilion dv5-1132la laptop and the touchpad's primary/right button (I'm left-handed with computer mice) is already malfunctioning. It triggers a button press event at the slightest touch in some areas, even before pushing it enough to hear the "click" sound". My older Acer Aspire 5050 laptop also had a similar issue right after the end of the 1-year warranty period, except that the primary button simply stopped working.

Some genius decided to make touchpads emulate mouse clicks with "tapping", which seems to be preferred by many end-users over the normal buttons - in fact, I've got people confused when lending them my laptop because tapping doesn't work at all! He he.

For some reason, I've never learned to use these devices properly and most of the time, while moving the pointer across the screen, I end up unconsciously "tapping" it. Depending on the driver or operating system I'm using, I could also accidentally drag stuff this way. At least Windows Vista keeps an old Windows 95 feature which asks the user prior to moving directories like \Program Files and \Windows. Oops.

Even if I'm not using Windows, closing a terminal emulator by accident while dpkg or something (not in a screen session) was running in it can't be good.

So, disabling this tapping "feature" gets rid of these annoyances and lets me use this thing as if it was a normal mouse, more or less. I have even successfully used it for drawing pixel art for my Wesnoth add-ons!.

But it seems that I'm not supposed to use touchpads that way for very long! What the hell, QA department? So now I should ponder whether to go and ask the manufacturer's tech support for help before the laptop's warranty period is over this Xmas, or live with the problem because I'm not really willing to leave my little toy alone for a few days!

Fortunately I still have a USB mouse for pixel art- oh wait, its scrolling wheel doesn't work very well anymore because manufacturers seem not to expect anyone to use those a lot! But that's no problem because it's a very cheap accessory and I can easily replace it, unlike, uh, a touchpad?

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.