On openSUSE, this means you can install the VirtualBox package using Yast (or zypper, or whatever you’d like to use) and then open VirtualBox, go to File > Preferences > Extensions, click the top “Add package” button, select the downloaded file and you’re done.

Well, almost done. After you add a USB device filter to your VM and boot it, you’ll notice that all entries in the Devices > USB menu are grayed out.

Reason for this is a permission problem. Usually, VirtualBox installs a udev rule that gives all users in the vboxusers group permission to access all USB files. openSUSE chose to disable this udev rule by default for security reasons without visible notice to the users.
So, to cut a long story short, open /etc/udev/rules.d/60-vboxdrv.rules, and replace the lines that are commented out with the ones below (these are almost like the commented-out lines, but replace NAME with SYMLINK+):

KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600"
#these two lines give access permission to vboxusers to properly work with usb nodes, this could be security risk (bnc#664520) !!
SUBSYSTEM=="usb_device", ATTR{devnum}=="?*", ATTR{busnum}=="?*",SYMLINK+="vboxusb/$attr{busnum}/$attr{devnum}", GROUP="vboxusers"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{devnum}=="?*", ATTR{busnum}=="?*",SYMLINK+="vboxusb/$attr{busnum}/$attr{devnum}", GROUP="vboxusers"

Now reboot and you should have all USB devices available (at least if you’re in the vboxusers group, check this with the id command in a terminal window).

And while you’re at it, please ignore forum posts that modify usbfs or anything like that, newer VirtualBox versions don’t need these things any more.

If you only have a 10-vboxdrv.rules file, then you most likely installed VirtualBox not from the openSUSE repositories, but from the VirtualBox download site. Remove this version first and install the openSUSE version if you want to use this guide (and save you from recompiling the kernel module with every update).

(Post updated on 2011-08-15 to incorporate some user comments. Thanks guys!)

But actually there is a way to get it all work together nicely and it’s not hard at all:

1. Enable PulseAudio (#> is a root console)

   #> setup-pulseaudio --enable

2. Install the missing PulseAudio mixer (without it it’s like sitting in a car without driving wheel)

   #> zypper install pavucontrol

3. Reboot (just to make sure …)
4. Start pavucontrol. You’ll see your sound devices (e.g. the sound card and your headset), the per-application volume controls as soon as an application uses an input or output and everything else you dreamed of.

Now you can start Skype and do a test call, and you’ll be able to use pavucontrol to route its output and input to the right device (e.g. to your headset).

Enjoy!

PS: It seems that there has been some progress on KDE4 integration with PulseAudio, and I hope in openSUSE 11.4 everything will work out of the box.

Then I got the solution for you: introducing Majordomo Web API

I needed to sync an address database in eGroupware with different Majordomo mailing lists (every night). I did this by building a small API that looks like a normal asynchronous API – just with the difference that in be background a mail request to Majordomo is sent and the results are retrieved from an IMAP or POP3 account.

Get the code, or look at egroupware_update_mailinglists.php script for an example. It should be easy to build a modern AJAX web interface on top of the JSON-based RPC interface.

As it always is, our mailing list provider switched from Majordomo to Mailman only a couple weeks after I finished the scripts. So the work didn’t really pay off, but I hope it’s useful to somebody out there.

• if you use (and need) ACLs (the default POSIX ACLs), do not switch to NFSv4. It probably will take ten more years to be fully working (the speed of NFS development seems to be close to GNU Hurd).
• if you modify the “Domain” entry in /etc/idmapd.conf, modify it on all clients and the server, otherwise all users and groups will be mapped to “nobody”.
• I don’t know yet if the Firefox locking problems are gone (I hope so …)

As a side note, there will be no official release for XForms for Firefox 3.5. The XPI package available at my builds page has been tested by many people and works well, but no further development efforts will go into that version.

Yeah, documentation in an unstable wiki is great. I wonder if MDC uses HTTPS only to make it even slower …

http://philipp.wagner.name/cafeteriamenu/

Der Quellcode ist ebenfalls im Mercurial Repository verfügbar (nein, Code zum Parsen von HTML-Seiten ist nicht schön).

Have a lot of fun…

• Fix the cmake build files to work with newer KDE versions.
• Add caching and network status detection to the data engine. The menu for the next week is cached if you are online and available without network connection. The cached data is only used if no network connection is available and refreshed as soon as you’re online again.

Download the source packages:
cafeteria_engine-0.2.tar.bz2
cafeteria_plasmoid-0.2.tar.bz2

Build instructions are included in the README files.

I’ve added the code to my Mercurial repository as well.

source$ ssh root@192.168.66.2 -- nc -l 3333 \| dd of=/dev/VolGroupData/data1 &
source$ dd if=/dev/VolGroupData/data1 | nc 192.168.66.2 3333

dstat on the target host shows:

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
[... removed first few lines until memory caches are full ...]
 0   1  88  10   0   0|  15M   15M|  16M  493k|   0     0 |  15k 9177
 0   1  88  10   0   0|  16M   17M|  17M  538k|   0     0 |  16k 9597
 0   1  89  10   0   0|  16M   16M|  17M  547k|   0     0 |  16k 9767
 0   1  88  10   0   0|  16M   15M|  17M  541k|   0     0 |  16k 9413

Only 17 MB/s over Gigabit ethernet? And where are the disk reads coming from? Well, after some more experimenting, the answer was not that hard: block size. dd uses a default block size of 512 Bytes, increasing it to 4 KB shows an entirely different picture:

source$ ssh root@192.168.66.2 -- nc -l 3333 \| dd obs=4K of=/dev/VolGroupData/data1 &
source$ dd ibs=4K if=/dev/VolGroupData/data1 | nc 192.168.66.2 3333

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
[... removed first few lines until memory caches are full ...]
1   6  92   0   0   0|   0    74M|  77M 1821k|   0     0 |  57k   85k
1   7  92   0   0   0|1638B   73M|  77M 1819k|   0     0 |  59k   88k
1   8  91   0   0   0|   0    70M|  74M 1724k|   0     0 |  49k   72k
1   7  92   0   0   0|   0    70M|  74M 1737k|   0     0 |  56k   82k
1   6  92   0   0   0|   0    73M|  76M 1795k|   0     0 |  57k   86k
1   6  93   0   0   0|   0    72M|  75M 1779k|   0     0 |  56k   85k

Now, how about that? Average was in the end around 65 MB/s, which is much closer to what I expected.