It so happens that Regnum can be played either in windowed mode, or fullscreen. Obviously the latter takes advantage of the whole screen, but sadly it can not be minimized or alt-tabbed to a different window. Being able to minimize the Regnum window and switching to another task is interesting, for example, to leave your character resting after a battle (it takes some time to heal back to normality), and checking your e-mail meanwhile. However, playing in windowed mode feels uncomfortable, with not all the screen being used, and having your desktop bars above and/or below the window you are playing on.

To have the advantages of both windowed and fullscreen mode at the same time (and none of their disadvantages), I thought of the following: I can play on 1440×900 resolution (my whole screen), hiding the top and bottom bars (I use GNOME, with both bars), and getting rid of the window decoration of the Regnum window (which would eat some of the 900 vertical pixels). While we are at it, it would be cool to stop Compiz Fusion before running Regnum (to dedicate the whole video card to the game), and starting it again after closing it.

The problem is, I do not like to have autohiding panels in GNOME, and I like window decorations and Compiz effects, so the desktop settings for playing would have to be turned on before playing, and off after that. The next problem in the line is that I don’t like performing repetitive tasks such as pointing, clicking and choosing options from menus every time I feel like playing a game. Since I already click a button to start Regnum, it would be cool to have all configuration stuff happen by just clicking that same button. Obviously, that means automating all the configuration by placing the corresponding commands in a script, and making the Regnum button execute that script.

Stopping Compiz

That part was easy. We want to switch from Compiz to Metacity, which can be done with:

metacity --replace

Autohiding GNOME panels

Some googling yielded this ubuntu-tutorials page, which led me to:

gconftool-2 --set "/apps/panel/toplevels/top_panel_screen0/auto_hide" --type bool "true"
gconftool-2 --set "/apps/panel/toplevels/bottom_panel_screen0/auto_hide" --type bool "true"

Eliminating window decorations

All you can google about it will lead you to a little wonder called Devil’s Pie. In short, it’s a kind of daemon that checks for windows that match some user-defined rules, and performs on them the corresponding user-defined actions.

In my case, I defined a rule (in ~/.devilspie/regnum.ds):

(if
    (is (application_name) "Untitled window")
    (begin
        (undecorate)
    )
)

Running devilspie from the command line will show the properties of all open windows, which will help you create the appropriate condition for the rule. In my case, apparently the final Regnum window is identified only as “Untitled window”.

Running Regnum, and waiting for it to finish

Waiting for Regnum to finish is not trivial, since once fully running it returns the control to the shell. For that reason, the following will not work:

$ echo "start"
$ regnum-online
$ echo "end"

It will echo “start”, then start Regnum, then echo “end”, while Regnum is still running. To fix that, I added a loop to my script, which only exits once Regnum has finished. There must be more elegant and less hacky ways of doing it, but this one works:

while [[ -n "`ps aux| grep -e regnum-online -e "./game" | grep -v grep`" ]]
do
    sleep 5
done

Every 5 seconds, it runs some ps command, and exits when the output is empty. The command itself is a simple grep to a ps, adding the grep -v grep so that the grep command is not catched by itself.

After closing Regnum, and whole script

So, after the while loop above exits, all we have to do is undo the settings changes we just did, and exit. The whole script would read:

#!/bin/bash

# Substitute Compiz with Metacity:
metacity --replace &

# Autohide top and bottom pannels:
gconftool-2 --set "/apps/panel/toplevels/top_panel_screen0/auto_hide" --type bool "true"
gconftool-2 --set "/apps/panel/toplevels/bottom_panel_screen0/auto_hide" --type bool "true"

# Run devilspie, to remove decoration in Regnum Online windows:
/usr/bin/devilspie &

# Run Regnum Online:
/usr/bin/regnum-online

# Wait until RO finishes:
while [[ -n "`ps aux| grep -e regnum-online -e "./game" | grep -v grep`" ]]
do
    sleep 5
done

# Kill devilspie:
killall devilspie

# Show top and bottom pannels:
gconftool-2 --set "/apps/panel/toplevels/top_panel_screen0/auto_hide" --type bool "false"
gconftool-2 --set "/apps/panel/toplevels/bottom_panel_screen0/auto_hide" --type bool "false"

# Run Compiz again:
compiz --replace --sm-disable --ignore-desktop-hints ccp --loose-binding --indirect-rendering &

Finally, I just named this script “RegnumRun.sh”, made it executable, placed it in a suitable place, and associated the Regnum icon on my top panel with RegnumRun.sh, instead of with regnum-online directly, and voilà: every time I click on that icon I get to play Regnum with purpose-chosen settings, and I get my regular settings back once I exit Regnum.

Related posts

• Usable Compiz Fusion: zoom to window (0)
• Trivial use of md5sum (4)
• First impressions with Arch Linux (3)

I thought that one could make the document more portable by exporting it to PDF (using OpenOffice.org). Doing so, the resulting file has a size of 364 kB (1.29 times smaller than the original DOC).

Furthermore, text formatting could be waived, by using a plain text format. A copy/paste of the contents of the DOC into a TXT file yielded a 186 kB file (2.53x smaller).

Once in the mood, we can go one step further, and compress the TXT file: with gzip we get a 51 kb file (9.24x), and with xz a 42 kB one (11.2x)

So far, so good. No surprise. The surprise came when, just for fun, I exported the DOC to ODT. I obtained a document equivalent to the original one, but with a 75 kB size! (6.28x smaller than the DOC).

So, for summarizing:

DOC

Pros

• Editable.
• Allows for text formatting.

Cons

• Proprietary. In principle only MS Office can open it. OpenOffice.org can, but because of reverse engineering.
• If opened with OpenOffice.org, or just a different version of MS Office, the reader can not be sure of seeing the same formatting the writer intended.
• Size. 6 times bigger than ODT. Even bigger than PDF.
• MS invented and owns it. You need more reasons?

PDF

Pros

• Portability. You can open it in any OS (Windows, Linux, Mac, BSD…), on account of there being so many free PDF readers.
• Smaller than the DOC.
• Allows for text formatting, and the format the reader sees will be exactly the one the writer intended.

Cons

• Not editable (I really don’t see the point in editing PDFs. For me the PDF is a product of an underlying format (e.g. LaTeX), as what you see on your browser is the product of some HTML/PHP, or an exe is the product of some source code. But I digress.)
• Could be smaller

TXT

Pros

• Portability. You can’t get much more portable than a plain text file. You can edit it anywhere, with your favorite text editor.
• Size. You can’t get much smaller than a plain text file (as it contains the mere text content), and you can compress it further with ease.

Cons

• Formatting. If you need text formatting, or including pictures or content other than text, then plain text is not for you.

ODT

Pros

• Portability. It can be edited with OpenOffice.org (and probably others), which is free software, and has versions for Windows, Linux, and Mac.
• Editability. Every bit as editable as DOC.
• Size. 6 times smaller files than DOC.
• It’s a free standard, not some proprietary rubbish.

Cons

• None I can think of.

So please, if you send me some text, first consider if plain text will suffice. If not, and no edition is intended on my side, PDF is fine. If edition is important (or size, because it’s smaller than PDF), the ODT is the way to go.

Related posts

• Save HD space by using compressed files directly (3)
• plzma.py: a wrapper for parallel implementation of LZMA compression (3)
• ChopZip: a parallel implementation of arbitrary compression algorithms (6)

In the following data T2D means “time to domination” (the expected time for Windows/Linux shares to cross, counting from the present date). DT2D means difference (increase/decrease) in T2D, with respect to last report. CLP means “current Linux Percent”, as given by last logged data, and DD means domination day (in YYYY-MM-DD format), and DCLP means “difference in CLP”, with respect to last logged data.

The numbers (again) seem a bit discouraging, but the data is what it is. Now MalariaControl goes up (it went down in previous report), but QMC goes slightly down. All others go up. The Linux tide seems unstoppable, however its forward speed is not necessarily high.

As promised, today I’m showing the plots for Spinhenge@home. In next issue, QMC@home.

Number of hosts percent evolution for Spinhenge@home (click to enlarge)

Accumulated credit percent evolution for Spinhenge@home (click to enlarge)

Related posts

• LWD – October (0)
• LWD – March 2009 (0)
• LWD – June 2009 (0)

I have been using Amarok as music player even since I had first contact with it. I was really delighted with its capabilities, and everything was intuitive and useful in its UI. That was until version 1.4.x.

Version 2.0 was an almost complete rewrite of the code, and as such many things changed. The UI suffered a large redesign, in my opinion for worse… but that’s just an opinion. There are, however, other issues that are facts, not opinion. Amarok 2.0 lacked many of the features of Amarok 1.x, as the developers themselves admitted (not much room to deny). Fine, I have no problem with that. It is understandable: until version 2.x things will not settle down. The only problem is that Linux distros (at least Ubuntu) adopted Amarok 2.0 almost immediately, leaving us users with a broken toy. Not nice.

My latest gripe with Amarok? I run Ubuntu 9.10 at work (Amarok 2.2.0), and latest Arch at home. In the latter, I just updated Amarok 2.2.1 to 2.2.2 in the weekend (Arch is much more up to date than Ubuntu, since it’s based in almost bleeding-edge rolling releases). Well, unlike Amarok 2.2.1 before (or Amarok 2.2.0 at work), the new Amarok 2.2.2 does not have an option for random play. Yes, you read correctly. There is no way I know of to avoid playing all the songs in the playlist in the exact order (in principle, alphabetical) they are laid on. In older versions, you could play songs or albums randomly. With 2.2.2, they lost this capability. Amazing feature regression, if you ask me.

Related posts

• Desktop environment manipulation from the command line (0)
• Changing font style in PyGTK ComboBox (0)
• Usable Compiz Fusion: zoom to window (0)

Now, let’s pass to some personal experience with a webcam. I bought a webcam for my girlfriend’s laptop, which doesn’t have one integrated. The webcam was a cheap Logitech USB one, with “Designed for Skype” and “Windows compatible” written all around on the box. It even came with a CD, marked prominently as “Windows drivers”. My girlfriend’s laptop runs Windows Vista, and I decided to give it a chance, and plugged the webcam without further consideration. A message from our beloved OS informed me that a new device had been plugged (brilliant!) but Windows lacked the necessary drivers to make it work (bummer!). OK, no problem. We had the drivers, right? I unplugged the camera, inserted the CD, and followed the instructions to get the drivers installed. Everything went fine, except that the progress bar with the installation percent went on for more than 12 minutes (checked on the watch) before reaching 100%. After installation, Windows informed me that a system reboot was necessary, and so I did. After reboot, the camera would work.

As I had my Asus Eee at hand, I decided to try the webcam on it. I plugged it, and nothing happened. I just saw the green light on the camera turn on. Well, maybe it worked… I opened Cheese, a Linux program to show the output of webcams. I was a bit wary, because the Eee has an integrated webcam, so maybe there would be some interference or something. Not so. Cheese showed me immediately the output of the webcam I had just plugged, and offered me a menu with two entries (USB webcam and integrated one), so I could choose. That’s it. No CD with drivers, no 12-minute installation, no reboot, no nothing. Just plug and play.

Perhaps it is worth mentioning that the next time I tried to use the webcam on the Vista laptop, it would ask me for driver installation again! I don’t know why… I must have done something wrong in the first installation… With Windows, who knows?

Related posts

• Temperature and fan speed control on the Asus Eee PC (4)
• Making iSight camera work in Ubuntu (20)
• Ubuntu error: the installer needs to remove operating system files (3)

In the following data T2D means “time to domination” (the expected time for Windows/Linux shares to cross, counting from the present date). DT2D means difference (increase/decrease) in T2D, with respect to last report. CLP means “current Linux Percent”, as given by last logged data, and DD means domination day (in YYYY-MM-DD format), and DCLP means “difference in CLP”, with respect to last logged data. I have dropped the “Confidence” column, for it gave little or no info.

Except for the good news that Einstein@home has succumbed to the Linux hordes, the numbers (again) seem quite discouraging, but the data is what it is. All CLPs but MalariaControl have gone up (which goes down less than in previous report). The Linux tide seems unstoppable, however its forward speed is not necessarily high.

As promised, today I’m showing the plots for Rosetta@home, in next issue Spinhenge@home.

Number of hosts percent evolution for Rosetta@home (click to enlarge)

Accumulated credit percent evolution for Rosetta@home (click to enlarge)

Related posts

• LWD – October (0)
• LWD – March 2009 (0)
• LWD – June 2009 (0)

I have a file file.txt, and a collection of files file.txt.N, where N = 1, 2, 3… I know that the former is a copy of one of the latter, but I don’t know which. I could have run diff on all the possible matches, but I would have had to run it for every N until a match was found. However, md5sum comes to rescue. I can just run:

And check which file.txt.N has a MD5 signature equal to file.txt, so that one would be the match. This solution is still a bit annoying, because I have to visually search matches for a long string. Not to worry! Unix is our friend once again. Recover the above command with a single press to the “up” arrow, then extend the command a tiny bit:

Now, since the MD5 signatures are sorted, the match for our file.txt (if there is any), will appear right after the line for file.txt.

I challenge the reader to accomplish the same task as readily, comfortably and successfully in Windows or Mac, or in Linux without the command line.

Related posts

• Hardware compatibility is better with Windows… not (10)
• Desktop environment manipulation from the command line (0)
• Usable Compiz Fusion: zoom to window (0)

However comfortable Ubuntu might be, my inner geek wanted to get his hands a little bit dirtier with configurations, and obtain a more responsive OS in return. And that’s where Arch Linux fits in. Arch Linux is regarded as one of the fastest Linux distros, at least among the ones based on binary packages, not source code. Is this fame deserved? Well, in my short experience, it seem to be.

First off, let us clarify what one means with a “faster” Linux distro. There are as I see it, broadly speaking, three things that can be faster or slower in the users’ interaction with a computer. The first one, and very often cited one, is the boot (and shutdown) time. Any period of time between a user deciding to use the computer and being able to do so is wasted time (from the user’s point of view). Many computers stay on for long periods of time, but for a home user, short booting times are a must. A second speed-related item would be the startup time of applications. Booting would be a sub-section of this, if we consider the OS/kernel as an “app”, but I refer here to user apps such as an e-mail client or text editor. Granted, most start within seconds at most, many below one second or apparently “instantly”, but some others are renowned for their slugginess (OpenOffice.org, Firefox and Amarok come to mind). Even the not-very-slow apps that take a few seconds can become irritating if used with some frequency. The third speed-related item would be the execution of long-running CPU-intensive software, such as audio/video coding or scientific computation.

Of the three issues mentioned, it should be made clear that the third one (execution of CPU-intensive tasks) is seldom affected at all by the “speed” of the OS. Or it shouldn’t be. Of course having the latest versions of the libraries used by the CPU-intensive software should make a difference, but I doubt that encoding a video with MEncoder is any faster in Gentoo than Ubuntu (for the same version of mencoder and libraries). However, the first two (booting and start up of apps) are different from OS to OS.

Booting

I did some timings in Ubuntu and Arch, both in the same (dual boot) machine. I measured the time from GRUB to GDM, and then the time from GDM to a working desktop environment (GNOME in both). The exact data might not be that meaningful, as some details could be different from one installation to the other (different choice of firewall, or (minimally) different autostarted apps in the DE). But the big numbers are significant: where Ubuntu takes slightly below 1 minute to GDM, and around half a minute to GNOME, Arch takes below 20 seconds and 10 seconds, respectively.

App start up

Of the three applications mentioned, OpenOffice.org and Firefox start faster in Arch than in Ubuntu. I wrote down the numbers, but don’t have them now. Amarok, on the other hand, took equally long to start (some infamous 35 seconds) in both OSs. It is worth mentioning that all of them start up faster the second and successive times, and that the Ubuntu/Arch differences between second starts is correspondingly smaller (because both are fast). Still Arch is a bit faster (except for Amarok).

ABS, or custom compilation

But the benefits of Arch don’t end in a faster boot, or a more responsive desktop (which it has). Arch Linux makes it really easy to compile and install any custom package the user wants, and I decided to take advantage of it. With Debian/Ubuntu, you can download the source code of a package quite easily, but the compilation is more or less left to you, and the installation is different from that of a “official” package. With Arch, generating a package from the source is quite easy, and then installing it with Pacman is trivial. For more info, refer to the Arch wiki entry for ABS.

I first compiled MEncoder (inside the mplayer package), and found out that the compiled version made no difference with respect to the stock binary package. I should have known that, because I say so in this very post, don’t I? However, one always thinks that he can compile a package “better”, so I tried it (and failed to get any improvement).

On the other hand, when I recompiled Amarok, I did get a huge boost in speed. A simple custom compilation produced an Amarok that took only 15 seconds to start up, less than half of the vanilla binary distributed with Arch (I measured the 15 seconds even after rebooting, which rules out any “second time is faster” effect).

Is it hard to use?

Leaving the speed issue aside, one of the possible drawbacks of a geekier Linux distro is that it could be harder to use. Arch is, indeed, but not much. A seasoned Linux user should hardly find any difficulty to install and configure Arch. It is certainly not for beginners, but it is not super-hard either.

One of the few gripes I have with it regards the installation of a graphical environment. As it turns out, installing a DE such as GNOME does not trigger the installation of any X Window System, such as X.org Server, as dependencies are set only for really vital things. Well, that’s not too bad, Arch is not assuming I want something until I tell it I do. Fine. Then, when I do install Xorg, the tools for configuring it are a bit lacking. I am so spoiled by the automagic configurations in Ubuntu, where you are presented a full-fledged desktop with almost no decision on your side, that I miss a magic script that will make X “just work”. Anyway, I can live with that. But some thing that made me feel like giving up was that after following all the instruction in the really nice Arch Wiki, I was unable to start X (it would start as a black screen, then freeze, and I could only get out by rebooting the computer). The problem was that I have a Nvidia graphics card, and I needed the (proprietary) drivers. OK, of course I need them, but the default vesa driver should work as well!! In Ubuntu one can get a lower resolution, non-3D effect, desktop with the default vesa driver. Then the proprietary Nvidia drivers allow for more eye-candy and fanciness. But not in Arch. When I decided to skip the test with vesa, and download the proprietary drivers, the X server started without any problem.

Conclusions

I am quite happy with Arch so far. Yes, one has to work around some rough edges, but it is a nice experience as well, because one learns more than with other too user-friendly distros. I think Arch Linux is a very nice distro that is worth using, and I recommend it to any Linux user willing to learn and “get hands dirty”.

Related posts

• Making iSight camera work in Ubuntu (20)
• Poor Intel graphics performance in Ubuntu Jaunty Jackalope, and a fix for it (8)
• LaTeX input in Inkscape 0.46 (2)

Apparently a 40% of the visitors or the Koonsolo site use Windows, vs less than 23% for Linux. However, despite the majority of visitors using Windows (there are even more Mac visitors than Linux ones), the Linux version sales amount to a 34% of the total sales, whereas Windows sales are only 23%. Visit the site for some more numbers and comments.

Related posts

• LWD update (0)
• LWD – October (0)
• LWD – March 2010 (0)

In the following data T2D means “time to domination” (the expected time for Windows/Linux shares to cross, counting from the present date). DT2D means difference (increase/decrease) in T2D, with respect to last report. CLP means “current Linux Percent”, as given by last logged data, and DD means domination day (in YYYY-MM-DD format).

The numbers (again) seem quite discouraging, but the data is what it is. All CLPs but MalariaControl have gone up, with Spinhenge going up by almost a 0.4% in 3 months. The Linux tide seems unstoppable, however its forward speed is not necessarily high.

As promised, today I’m showing the plots for QMC@home, in next issue Rosetta@home.

Number of hosts percent evolution for QMC@home (click to enlarge)

Accumulated credit percent evolution for QMC”home (click to enlarge)

Related posts

• LWD – October (0)
• LWD – March 2009 (0)
• LWD – June 2009 (0)