After a good deal of gnashing of teeth, I finally managed to get Pulseaudio to Do The Right Thing™ (which is what the thing I want, not what it wants): downmixing Surround 5.1 to Stereo.

The problem was simple: I had a lot of lossless FLAC files containing Surround 5.1 audio (that is, 6 channels). However, at the moment I only own a couple of speakers which are good enough for casual listening (ergo, 2 channels stereo).

I thus wanted Rhythmbox, Totem, and other apps to simply make me listen to the rear channels; else, I would lose half of the guitar solos in Jethro Tull’s “Aqualung”, because when it was recorded it was spatially at the rear of the room.

“Many organizations which want to use Qt for their business applications choose commercial licenses, for a variety of reasons. These include restrictions in using open source licensed software in industries such as defense & aerospace, or the need to provide product warranties & indemnities such as in the medical device industry. Others choose a commercial relationship for access to Qt professional support and services to ensure successful development of their projects.”

and Matthias points out:

First, warranties, indemnities, support and services can be done with any GNU license. Qt is licensed under the GNU LGPL, so in this sense it is a commercial license. There is commercial Free Software, as well as non-commercial non-free software, or to put it in David Wheeler words:

“It’s time to end the nonsense. OSS is practically always commercial, which means that there are two major types of commercial software: proprietary software and OSS. Terms like ‘proprietary software’ or ‘closed source’ are plausible antonyms of OSS, but ‘commercial’ is absurd as an antonym, and phrases like ‘commercial or OSS’ make no sense.”

I agree with Matthias (and David) here; speaking as a software engineer, the biggest requirements in the aerospace and defense sectors are about testing and software reliability.

For example, NASA requires complete MC/DC for critical code. But that has absolutely nothing to do with licensing.

Most proprietary software does not qualify either. And its closed-source development model makes it only harder to assess its quality, because it is hard to ask for multiple third-party code reviews.

In fact, many times tenders for aerospace or the military ask for delivering *also the source code*. I wonder how any type of free software licensing scheme can hinder that.

As far as other points go: the GPL states that “this program is distributed without any warrant of any kind”. But indemnities can be offered as an additional service on top of the original license (like the GPL). This is not unalike to what happens with most EULAs.

Today I went down to try and have Cherokee working well with RVM. I wanted being able to switch the Ruby version with ease, in order to allow for a painless upgrading when patches are released upstream. More, I wanted to be able to create gemsets and such. Cherokee is fast as hell, and much easier to maintain than Apache.

After a little bit of fiddling, I came up with a nice and easy solution, which roughly goes like this:

Create a rails user on your system. My advice is to lock it down with “passwd -l rails” after creation.

If you installed any gems as root, it’s best to remove them. Then, follow the normal instructions to install rvm su-ing as the rails user. Compile and set as default a ruby instance of your choice (“rvm use –default ruby-1.8.7“, for example).

Always logged in as the rails user, install any gem you may need. You can do this later, if you prefer. Test if your website starts manually, by calling script/server, or if it complains about missing gems.

chmod -R your rails project to rails:rails. I keep my production sites under /var/www, but you can put ’em in /home/rails, for example.

Use the standard wizard that comes with Cherokee to prepare the sources for your website.

Under the “Interpreter command” text field of each of the three newly created sources, prepend the command that’s already there with (“/home/rails/spawner.sh“). For example: “/home/rails/spawner.sh example-website script/rails server -b 127.0.0.1 -e production -p 38161“. I omitted “/var/www/“, but you can put it there if you want.

For each of the sources, set the user and the group the site will be served with to “rails“.

Create a new file /home/rails/spawner.sh, which will do the simplest magic we need:

Now, if someone of the Cherokee project would be so kind to fix that ugly “Bad gateway” error the first time you try to access a Rails site and the interpreter hasn’t been spawned yet, I’d be immensely grateful. 🙂

Update: the non-opensource edition of VirtualBox 2.2, still not included in Jaunty, will enable you to skip all of this hassle; it’ll set up a bridged connection for you automatically. However, for 2.1, this still applies.

Many of you may know the OpenSource alternative to the proprietary VMWare solution. Sun’s VirtualBox is very fast and feature-complete enough to substitute most of VMWare’s functionalities. I use it at work since more than a year with wonderful results, both to virtualize Windows under GNU/Linux, or GNU/Linux under Windows.

However, network configuration isn’t as obvious as it should, since NetworkManager doesn’t support bridge-ing interfaces by default. Herein, you’ll find a short tutorial on how to enable your virtual machine to access the Internet when hosted inside a GNU/Linux OS using NetworkManager.