World of Warcraft in Linux using Wine

Many manuals of installing and using World of Warcraft (or simply WoW) in Linux using Wine (Windows emulation) are outdated and provide lots of complex instructions for old Wine version. The truth is very simple:

  1. Take a recent Wine version. Any version from this year (2007) will do. Debian and Ubuntu users can either use the wine from the latest releases of the distros or use the repositories.

  2. Install WoW via the usual installer

  3. Edit $WOW/WTF/ and add following lines:

    SET gxApi "OpenGL"
    SET SoundOutputSystem "1"
    SET SoundBufferSize "100"

  4. Run 'wine regedit' and set HKEY_CURRENT_USER->Software->Wine->OpenGL->DisabledExtensions to "GL_ARB_vertex_buffer_object" (you will need to create this string value)

That is it! You can now simple run 'wine WoW.exe' and play the game. Updates also work perfectly. The speed is a bit faster then in the other operating systems and (just like in MacOs X) you can have all your software opened on one virtual desktop, WoW on another and switch between them instantly.

Debconf7 photos

My blog server has been down ever since I left off to Edinburgh for the 7th Debian conference. Since then I have been busy taking photos of everything and everyone here AND I am not alone in that. Enjoy!

Debconf - fun and motivation (and pictures)

Debconf is coming. And I fully agree with Amaya regarding the much needed battery recharge that brings to people (and me in particular.
And to the contrary to the information two posts ago, thanks to getting an unexpected side income from the nice folks of FFII, I did manage to buy myself a Canon 400D instead of my old camera that was stolen from me recently. Unfortunately, I do not earn well enough to also buy a good lens, so I will have to document this Debconf with the kit lens :P. If you want something better, then I beg you to lend me some better Canon (EF or EF-S) lens for the time of the Debconf. Canon EF 17-40 f/4 L (like the one that I took the last years group photos) would really be great! :D
This year I am thinking of doing both the group photo and the mugshots. Any other ideas for the paparazzi? :)

SBackup new beta - test and translate please!

With great help from Ouattara Oumar Aziz an new version of SBackup is shaping up in the svn repo and a day ago I created a public beta version - 0.10.4~beta10 which can be downloaded here.
Please report any bugs or regressions to Sourceforge bug tracker. Also an update for translations and new translations can be added. You can either translate in Launchpad or download the template file from the SVN. But beware that there are more translations in Launchpad then in the SVN at the moment, so check there first.
If no blocker bugs are found, we could see a new stable release of SBackup in a weeks time. I am sure that a lot of people will be happy to hear that :).

Edit: For some reason, the DEB on the Sourceforge site was cut to third of its size, I uploaded a new version, it should be fine now. And by popular request here is a screenshot, note that by using simple timing the /etc/cron.{daily,weekly,monthly} folders are used and thus anacron runs the backups if the computer was off at the scheduled time.
New screenshot

Stuff happening

You know that you haven't blogged in a while, when you realize that you have changed your address twice since the last post.

Changes in my life since last post:
* finished my Masters paper and submitted it, waiting for viva now :S
* moved back to Latvia, lived for some time with parents (and no Internet) and now moved into an apartment in Riga - great place :D
* working on projects to make living :|
* got my camera stolen at some point during my move from UK to Latvia, and my finances will not allow to replace it this year ;(
* another person is contributing heavily to SBackup and is single-handedly doing the bulk of the bug fixing for a new stable release of SBackup :D !
* another patent treat is looming (EPLA - a united patent court under EPO), but this time we are asked for our opinion by our government - nice change of pace there :)


Because something mangled my signature along the way (I suspect it was GMail), I also post it here along with a GPG signed text file:
I hereby nominate myself for the position of Debian Project Leader in the DPL elections of 2007.

Home folder organisation

After last post about a FHS amendment to address the structure of user's home folders, I received a lot of comments and there is one very significant thing that can be changed in the proposal - instead of having $HOME/{.data|.cache|.config}/appname structure, to change that to a mandatory $HOME/.library/appname/{cache|config|...} . This version still has all the benefits of the first solution (configuration for an application can be easily identified and erase, and all cache can easily be excluded from backups using "$HOME/.library/*/cache" regexp) and also has additional benefits, main of which is the ability to later introduce the concept of user installed packages. The idea is that it would be possible to support having /bin, /lib and /share subdirectories in these application directories thus making an ability for the whole application to e packed in a single directory and allowing the application to be installed simply by unpacking this directory. I admit that much of this is glanced over from MacOS X world, but I do not think that it diminishes the idea itself.
Some problems appear there - support of these distributed bin folders, support of separate lib folders, handling of application plugins, handling of dependencies, handling of the application menu, upgrading notifications for the user software vs. system software. But nothing there that can not be solved. I feel that this can bring together FHS and LSB by providing something of an API for software being installed by users. Having no registry of the software in this solution allows for some interesting things, for example having multiple versions of one program just by renaming the application folder.
A lot of specification work is required here, therefore I proposed a workshop on this topic in Debconf7. I hope to have something that everyone can agree on and maybe even some code by then, so that after Debconf7 there can be a formal policy amendment proposal.

So there are two questions:

  1. Is there something better in $HOME/.cache/appname vs. $HOME/.library/appname/cache ? Any other trade-offs that I have forgot?

  2. What do you think about the further idea of users having the ability to install software in their home folders or remove such software in a very simple fashion?

A must

It is really a must have - my blog gets mentioned on the DWN for the first time and at the same time (or even a bit earlier) the electricity cuts to the building where my server is co-located. And it takes a couple of days for the local administrator to get from all that chaos to turning my server back on. Perfect timing :P.

FHS extension for user home folders


Currently there is a huge mess of files and folders that start with a "." in any users home folder. There is no structure or policy on how applications should choose file and folder names for data that needs to be stored in users home directory. Additionally there is no established consistency between Gnome, KDE and most other applications. Gnome application have part of their configuration information in gconf folder and other part in a gnome subfolder. KDE applications have a complex structure under .kde/. And most other applications either have one file directly in users home folder or have their own dot-folder there.


There are two major problems with current ad-hoc approach:

  1. Namespace pollution of users home space. In any desktop system "ls -al" in the home folder would be a very lengthy affair. Moreeven this namespace is folded - KDE and Gnome apps live in their own subfolders.

  2. Lack of structure in folders makes it much harder to properly understand their purpose. For example, if a user has misconfigured an application and would like to reset it to default settings, it currently could be hard to figure out how to do that. Especially without losing his data in that application.


I propose to implement a policy on where an application can store data and configuration information in users home folder. Such specification would be proposed as an extension for FHS, first implemented in Debian and then promoted for inclusion upstream and in other distributions.


I propose a following structure for a users home folder:

  • data/appname/ - each application, that stores user data in application-specific format, will have to store this data into this folder. Only configuration information that is essential to load this data would be permitted into this folder (in hidden dot files). For example, Evolution could store emails and email access information here.

  • .conf/appname/ - each application that stores any configuration information whould have to store all of it in this folder. GConf will have to also store applications configuration info here. If this folder would be deleted, application must revert to default configuration, but still be able to fully access user data in data/appname/ or other, generic folders (below). For example, if .conf/evolution/ is erased, then on next start-up Evoution should still be able to access all email that is stored in data/evolution/ without any configuration wizards.

  • .tmp/appname/ - each application that would need to create temporary files that survive reboot, would put them here. These folders can be safely deleted at any time with no data or configuration loss. For example, Firefox cache information and Nautilus thumbnail cache would have to be here.

  • Desktop/ - the desktop folder, just like it is now

  • Media folders - (Documents/, Photos/, Videos/, Music/, ...) a suggestion of basic document structure for user to use or ignore. Applications dealing with particular media types would default to use files from such folders, but should also cope with working with any other folders on users choice. For example, a screensaver with slideshow function would by default use photos from Photos/, but will have to have a configuration option for user to change that setting.

  • Additionally I would propose having a .mounts/ folder where applications could mount user specific media and other mounts, such as FUSE. For example, FUSE could be used for automatic archive introspection.


The main benefit for such system for me is twofold:

  • SBackup can be configured to exclude .tmp/ and .mounts/ by default thus saving significant space in backups.

  • A tool can be made to restore settings and/or data for specific applications in an uniform fashion.

So, any suggestions on the idea and on where this should be best discussed?

I'm blue!

Me and a Blue Man
In the last day of Lastguru's visit, I convinced him to go to The Blue Man group performance in the New London Theatre. The performance was just great - a combination of rhythmic music, dramatic light and a hilarious comedy show. Just wonderful!
There was a lot of classic Blue Man moments - weird looks, colour-splashing drums, rock concert movements, textual and emotional sketches with the audience and the great "You Are LATE!" intermission. It really was 100 minutes of pure fun.
And best of all, on the exit I was given a special ticket with which I can get back in again for free if I bring a friend - yay!