Tablet on VirtualBox guest

If you're Linux user and you have Wacom Intuos3 tablet - it's obvious that GIMP will not satisfy your needs. Solution exists: you can download and install free VirtualBox, install WindowsXP as guest system and work with your tablet in guest system, installing your favourite graphics application on Windows guest.
I did those steps: installed VirtualBox 3.0.8 on my SUSE Linux 11.1, installed WindowsXP as guest. But I couldn't configure it - checkbox to turn on tablet in guest system was disabled (grayed out).

I spent few hours reading different forums and bugreports, most of them suggested to mount tablet as usbfs to your system, but it didn't worked for me. When I found solution - it was fast and simple:
1. Open your /etc/udev/rules.d/10-vboxdrv.rules as root. You will see something like this:

KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600"
SUBSYSTEM=="usb_device", GROUP="vboxusers", MODE="0664"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="vboxusers", MODE="0664"

2. Modify third line like this (adding name):

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="VirtualBox/$env{BUSNUM}/$env{DEVNUM}", GROUP="vboxusers", MODE="0664"

3. Restart your system to be sure.

That's it! Now checkbox will be enabled and you will be able to turn on your USB tablet for guest system. VirtualBox will fail with error (something like couldn't create usb proxy device) but only 2 times, when pressing third time - tablet will be recognised by guest system and you will be able to use it. Of course you should also disable mouse integration and your tablet will no longer be available to your host Linux system, but what for do you need it there anyway?

KDE 4.3 RC3

You may already know that KDE 4.3 RC3 released, and release delayed for a week. I can't stand that news, I thought that is will be released this Monday, but another 2 weeks... And of course I want to try it without harming my every day system with KDE 4.2.4 and only stable packages. In that moment I remembered about kde4live CDs, that I used some time before SUSE 11.1 released. And of course I found it fast enought using Google. And there are good news - on top of the page there is message that KDE 4.3 RC3 already packed to LiveCD and can be downloaded from SUSE's repositories. Well, Kubuntu users, don't you feel betrayed that your favourite "KDE-oriented" distro is far behind great and green OpenSUSE?

Yet another opinion in Mono case

There were many Mono debates on Tuxmachines for last few weeks. Of course I have my own opinion on this topic. I will not blame Mono right now, just my thoughts about distributing it with Linuxes.

Default distribution
As far as I know, all those debates started when Debian guys thought about including Mono into default installation. But what it default installation? Isn't it related to target users? It's obvious that when you installing Ubuntu - you target home desktops, SLED or Mandrake - office, SLES or Slackware - servers. Depending on that choice "defaults" are very subjective. But is there any distribution problem? I don't see it. Being SUSE user I have my distribution on DVD media, lots of stuff could be fitted there, why not include Mono? If you're single CD distribution - you should think twice and count all Mono-based software you'd like to install. If it's just single application - it will be funny to install mono because of it.

Next, most of Mono apps are made for GNOME. I see no reasons to install it with KDE-based distribution, or console installations.

Thinking about users
In perfect world user should never bother with technology used in his favourite apps. Application should just do it's job, not promote or blame something. To mono or not to mono should depend on those user apps, but should not be some politics or religion choice. As for me I hate beagle, banshee and f-spot. Mono should not be installed for me. And vice-versa. If user will notice any Mono application he will run - it will look like there is some problem with Mono, don't you think so?

System core
While it's completely OK to depend some desktop apps on Mono or other interpreted stuff - it's totally wrong to use it for system parts. Every next level of abstraction and interpretation adds additional level of possible problems, removes some part of integration and requires more resources to work. Can you imagine our world if HAL will be written in ruby or python or something like that? System must not be related on interpretator vendor or on subjective solutions. You may already see some bad examples like ZEN in SUSE 10.0, pulseaudio in current distributions, gcj instead of Sun JRE in fedoras and many more.

From my perspective
It's strange to see, but all mono-based apps I know makes me sick. Beagle that starts and scans event without any GUI installed. ZEN that made me think about switching away from SUSE. Banshee with it's crippled playlists. F-spot with it's lack of features. MonoDevelop with it's lame possibilities totally unexpected in any IDE. I think that the day I will not be able to set "taboo" on Mono in my SUSE installation will be the last day of me as SUSE user.

KTorrent vs Anti-Cheater

After updating to SUSE 11.0 torrent client for KDE updated from KTorrent 2.2.1 to KTorrent 3.0.x. But on my favourite tracker I receive "Anti-Cheater: You cannot use this agent" as status message while using KTorrent 3. I installed KTorrent 3.1 - and get same message. But after installing back 2.2.x - everything works fine. So, problem is User-Agent string. It is not very hard to search over KTorrent sources and modify it a bit to change User-Agent string. I already mentioned great tutorial about rpm building, and this time it saved me again...

Get the source
Download the src.rpm file and unpack it. I am using mc to navigate into src.rpm and copy all files from there to /home/to_build/src/ktorrent folder.

Diff to change user-agent
You can add diff to any spec file to apply it before build. It is much better than modify and pack sources back. So, here is my diff to change KTorrent 3.1 User-Agent string from "KTorrent + version" to plain "KTorrent". Now just save it in same folder ("/home/to_build/src/ktorrent" for me).

Modify spec file
Now only few modifications to spec file and time to start building:
Add this lines:

Patch10: user-agent.diff
%patch10

It is easy enough to find where to insert it, there are already few patches applyed.

And now, to enable blocked by SUSE trackers, comment this two lines:

#Patch2: remove-links.diff
#%patch2

Now just build and use your favourite torrent-client with your favourite tracker!

SUSE 11.0 handmade

SUSE 11.0 released about a week ago. As few previous versions, there is lack of proprietary multimedia formats support. And there is few ways to resolve it. First, most common way - to add packman repository and install everything from there, and to find other repositories for freetype2 and few other packages. But I don't like this way. SUSE team did a great job with packages and integration, downloaded from other sources packages rarely have this level of integration. My way - to take official SUSE src.rpm packages from official source repositories, and build it with SUSE build tools.

Preparing:
There is a great tutorial about "build", it will introduce build procedure for you. It will prepare you for reading this article.
Also, there is some packages from internet repository you will need. I don't know why aren't they on DVD. You can store them to folder of provided packages, "/home/to_build/provided" for me. I got them from x86_64 repository, and videolan repository for libmad and libdvdcss.

avahi-lang-0.6.22-68.1.x86_64.rpm
flac-devel-1.2.1-43.1.x86_64.rpm
gconf2-lang-2.22.0-28.1.x86_64.rpm
gnome-vfs2-lang-2.22.0-33.1.x86_64.rpm
gstreamer-0_10-lang-0.10.19-16.1.x86_64.rpm
gstreamer-0_10-plugins-base-lang-0.10.19-24.1.x86_64.rpm
libbonobo-lang-2.22.0-21.1.x86_64.rpm
libcdio++0-0.80-3.1.x86_64.rpm
libcdio-devel-0.80-3.1.x86_64.rpm
libdvdcss-1.2.9-5.1.x86_64.rpm
libgnutls-devel-2.2.2-17.1.x86_64.rpm
libiso9660-5-0.80-3.1.x86_64.rpm
libmad-0.15.1b-5.1.x86_64.rpm
libmad-devel-0.15.1b-5.1.x86_64.rpm
libtheora-devel-1.0.beta2-3.1.x86_64.rpm
libudf0-0.80-3.1.x86_64.rpm
speex-devel-1.1.99.3-28.1.x86_64.rpm
vcdimager-0.7.23-132.1.x86_64.rpm
vcdimager-devel-0.7.23-132.1.x86_64.rpm

Step One - xine
The most important multimedia part of SUSE distro - xine engine. Let's build it first.
1. Download xine-lib-1.1.12-8.1.src.rpm from SUSE repositories and unpack it to some (target) folder.
2. Remove xine-lib-1.1.12-crippled.tar.bz2 from target folder.
3. Download xine-lib-1.1.12.tar.bz2 from official sourceforge website and save it to target folder.
4. Open xine-lib.spec with your favourite editor.
5. Change line like this:
from "%define BUILD_XINE %{?_with_internal:2}%{!?_with_internal:%build_xine_default}" to "%define BUILD_XINE 2".
6. Set Release to "Release: 8.1.1" - it will with pleasure override already installed xine.
7. Modify source declaration from crippled:
from:

Source: xine-lib-%version-crippled.tar.bz2
%if 0
Source: xine-lib-%version.tar.bz2
%endif

to:

Source: xine-lib-%version.tar.bz2

8. Find and comment each of lines to let sources be uncrippled:

Source99: precheckin_cripple_tarball.sh
Patch70: xine-lib-crippled-LOCAL.diff
%patch70

9. Also, change all "mad" and "mad-devel" dependencies to "libmad" and "libmad-devel".
10. just build it:
build --root /home/to_build/root --rpms /home/to_build/provided xine-lib.spec
11. Take your packages from "/home/to_build/root/usr/src/packages/RPMS/".

Step Two - Kaffeine
Kaffeine is best front-end for xine ever-made. Let's build it with DVD support!
1. Download kaffeine-0.8.6-54.1.src.rpm and unpack it.
2. Comment each of this lines:

Patch0: %name.diff
Patch2: messagebox-dvd.diff

3. Build it. I got small problem with some locale files, so you can just add locale files after icons packaging:
from:

/opt/kde3/share/appl*/*/*
/opt/kde3/share/apps/kaffeine
/opt/kde3/share/apps/konqueror
/opt/kde3/share/apps/profiles
/opt/kde3/share/icons/*
/opt/kde3/share/mimelnk/*/*.desktop

to:

/opt/kde3/share/appl*/*/*
/opt/kde3/share/apps/kaffeine
/opt/kde3/share/apps/konqueror
/opt/kde3/share/apps/profiles
/opt/kde3/share/icons/*
/opt/kde3/share/locale/*/*/*
/opt/kde3/share/mimelnk/*/*.desktop

Step Three - FreeType2
There is no subpixel font smoothing in SUSE, so it will be useful for LCD owners.
1. Download freetype2-2.3.5-62.1.src.rpm from SUSE repository and unpack it, for example into "/home/to_build/src/freetype".
2. Download full FreeType2 from official website into same folder ("/home/to_build/src/freetype"), replacing old one.
3. Change two blocks:
from

Source0: http://download.savannah.gnu.org/releases/freetype/freetype-%{version}.tar.bz2
Source1: http://download.savannah.gnu.org/releases/freetype/freetype-doc-%{version}.tar.bz2

to

Source0: freetype-%{version}.tar.bz2
Source1: freetype-doc-%{version}.tar.bz2

and from

%define enable_subpixel_rendering 0%{?opensuse_bs}

to

%define enable_subpixel_rendering 1

4. Just build it and install packages from same folder - "/home/to_build/root/usr/src/packages/RPMS/"

That is all! Now you have your SUSE good as new, without less integrated third-party packages and without crippled multimedia. It's time to install win32 codecs from packman and libdvdcss from videolan before first kaffeine launch, install amarok-xine and remove buggy amarok-yauap plugin.

SUSE 11.0 first impression

Yesterday I have installed new SUSE 11.0 linux at home. Impressions are very ambiguous...

1. Package manager works great! Starting from SUSE 10.0 it was slower and slower, scanning repositories for minutes, than hours, checking depencencies, updating indexes and doing lots of interesting, but totally unusable staff. New package manager in 11.0 is faster than light! Adding huge repositories takes less than second, depencency checks are done faster than you can even notice!
Second great improvement for package manager - much better dependencies lists. I hate mono, banshee and other dotnet staff, I totally disregard it. But in SUSE 10.1 and 10.2 I HAD TO install mono just because of some yast pattern. That time I even downloaded few distros to look for SUSE replacement. Why, the Hell, I need software patterns for package manager if there are plain dependencies with straight structure?! But now I am totally happy - no mono, no beagle, no banshee, no gtk-sharps and other crap in my fresh system.

2. Older SUSEs with first boot after installing loaded yast to configure different devices, network and graphics. This did not. It was very hard to read fonts with default screen resolution (1280x1024), while installer worked with 1024x768.

3. Selection of KDE version is very hard. KDE 4.0.4 is very interesting, giving great fast new desktop experience. While there are some leaks: 1) I am not extreme enough to use PIM from unstable 4.1 sources; 2) Alt+Tab hangs sometimes when you have few windows from other users; 3) there is no printer configuration in KDE control center now, and YaST module changed from 10.2 and can't configure it for some reason... So, clicking few hours in KDE4 is great, but I'll wait a month for 4.1 to arrive.

4. It is hard to choose all programs from one of KDE desktops. KTorrent is KDE4 by default, KGet in KDE4 is totally great. But Dolphin will never move Krusader away, K3b and Amarok still not ported to KDE4, Gwenview of KDE4 differs too much from original KDE3 version, and older is much more usable.

current KDE version determination

I have a problem. KDE4 is comming, and I need to determine current running version from Java application. Do you know how?

After some investigations I found few ways. KDE is setting it's own env variables. For KDE3:

KDE_FULL_SESSION=true
DESKTOP_SESSION=kde

For KDE4:

DESKTOP_SESSION=kde4
KDE_SESSION_VERSION=4
KDE_FULL_SESSION=true

But it works only for SUSE, Kubuntu have only KDE_SESSION_VERSION=4 and KDE_FULL_SESSION=true. And this is only for 8.04 KDE4 release of Kubuntu, there was no such flags in 8.04beta. So, determination is simple:

public static boolean isKDERunning() {
  return "true".equals(System.getenv("KDE_FULL_SESSION"));
}

public static boolean isKDE4Running() {
  if (!isKDERunning()) {
    throw new IllegalStateException("KDE is not running");
  }
  return "4".equals(System.getenv("KDE_SESSION_VERSION")) ||
    "kde4".equals(System.getenv("DESKTOP_SESSION"));
}

If you feel paranoid and want to get 100% result it will be better to run Konsole (konsole --version) and parse output. Output for different versions looks like this:

konsole --version
Qt: 3.3.8
KDE: 3.5.7 "release 72"
Konsole: 1.6.6

/usr/bin/konsole --version
Qt: 4.3.4
KDE: 4.0.3 (KDE 4.0.3) "release 9.1"
Konsole: 2.0

So, parsing code:

public static boolean isKDE4Version() throws Exception {
  Process process = Runtime.getRuntime().exec("konsole --version");
  InputStream in = process.getInputStream();
  byte[] buffer = new byte[32];
  ByteArrayOutputStream out = new ByteArrayOutputStream();
  int read = 0;
  while ((read = in.read(buffer)) >= 0) {
    out.write(buffer, 0, read);
  }
  String output = out.toString();
  int indexOfKde = output.indexOf("KDE:");
  if (indexOfKde >= 0) {
    char v = output.charAt(indexOfKde + 5);
    return '4' == v;
  }
  throw new IllegalStateException("KDE version information not found");
}

And don't fear performance issues - on my Athlon X2 6000+ this operation takes only 26 millis!

life before KDE 4.1

Lots of Linux distros will release major versions before KDE 4.1 will arrive. What for? May be better to still use KDE 3.5.x?

according to Wikipedia:

In principle, in subsequent releases, the major number is increased when there are significant jumps in functionality, the minor number is incremented when only minor features or significant fixes have been added, and the revision number is incremented when minor bugs are fixed.

again, according to Wikipedia:

KDE 4.0 was released on January 11, 2008. Despite being a stable release, it is intended for early adopters.[22] Users wanting a stable, "feature complete" desktop may wish to continue using KDE 3.5 for now.[23]

Kubuntu will be released this month with KDE 4.0, Mandriva was released with KDE 4.0.2, and SUSE will be released just few days before KDE 4.1 will arrive, with latest KDE 4.0.x on board.

I am not against releasing. I am just afraid of possible low quality of KDE 4.1 from update centers...