Why No One Cares About Surround Sound

I started pondering new home theatre equipment a few days ago, as you do. What really brought me on to thinking about whether to have a surround sound system or not was when I was encoding my DVDs to put on my MythTV box and deciding whether to save space and encode to 2-channel Ogg Vorbis or keep the original AC3 autio tracks. Should I save myself a good few gigabytes over many films and series or will I really be using surround sound in the future and the extra channels in my audio? I then came to the conclusion that apart from hard core audiophiles and videophiles with the wherewithall to set up such a system it's out of reach for the vast majority:

1. The vast majority of people will buy a television first and then look to add surround sound later. They will then give up when they realise how complex it is and how you need a receiver and can't just plug speakers into the back of the TV.
2. The vast majority of people just do not have rooms that lend themselves to placing speakers around it. Many people have to compromise on where they put the TV and this makes dotting speakers to the left, right and rear totally impractical. If you don't place them well then it sounds crap.
   
3. Wires are a real problem with surround sound systems, they have to be hidden away, they sometimes can't in many peoples' rooms and the only practical solution is wireless speakers. I haven't seen too many wireless systems around and those I have seen have become impractical because you need to connect the rear speakers to a transmitter box..............which means more wires, finding a space to put them and getting power to them.
4. Surround sound systems are just too damn bulky. People just don't have too much space for receivers and other shit under their TV.
5. Moving on to surround sound tracks on DVDs, and considering the above, then for most they will have their audio tracks downmixed to two channels. On the vast majority of systems with most speakers, certainly TV ones, this sounds crap and far worse than 2-channel recorded TV sound.
6. Point 5 just reinforces to me why BluRay is a waste of time. No one is replacing their entire DVD collection and they're certainly not going to do it for even better surround sound they've never been able to listen to in the first place.
   

All things considered you're best off getting two very decent speakers and placing them either side of your TV with perhaps a bass woofer and/or receiver if you want better sound, assuming you have the space that is. Just skip the extra speakers and don't pay any attention to the Dolby Digital or DTS logos.

I know lots of people will be up in arms about someone saying this but maybe it's just the elephant in the room no one really wants to say anything about. Maybe there's too many people making money off surround sound equipment for those who'll actually buy into it, those who have it don't want to admit that it's largely a waste of time and money and those who don't have it know that they probably never will and don't want to criticise.

AutoMKV, xvid_encraw and the .Net Framework

I've been playing around with getting my entire DVD collection on to a little Shuttle machine running MythTV using AutoMKV (maybe more on that later) and MKV containers with Xvid. I decided to run this on a reasonably beefy machine with a RAID array running Windows 2003 and I kept getting a 'Failed to Initialize' dialogue error coming up whenever it got to using xvid_encraw for encoding. x264 worked fine, but this was just too slow to encode and decode for me for the benefits it allegedly brings. I did think this was a Windows 2003 incompatibility but it all started to work once I had installed the .Net framework version 2.0. So, if you have trouble getting this to work then the .Net framework seems to be a dependency.

VMware Server 2's VM Shutdown Problem

For quite a while now I've been running VMware Server 2 in a testing and development environment and for the most part, it's been excellent. I have a few Linux machines up and running providing network services like DHCP and DNS and a few Windows machines, one of which is running SQL Server and has four gigabytes of allocated RAM. While it's been quite reasonable, there are a few things now that makes me question it.

VMware Server 2 has one fairly serious failing, especially as a server product, and that is that it fails to shut down virtual machines when the host or the VMware service shuts down at all. There is a way of supposedly setting the startup and shutdown order of machines in the web interface and while the startup of machines works, shutting them down or suspending them automatically doesn't. When you shutdown the VMware service it merely skips past shutting down or suspending the VMs, shuts down the VMware management processes and leaves the machine processes running. If you do this often enough it breaks the config and you have to issue a vmware-config.pl again. This is an install on a vanilla CentOS 5 system (RHEL 5 basically) by the way, so there's nothing exotic going on. For the time being I've had to hack up a rough script to suspend the VMs on shutdown, but resuming machines from a suspension doesn't always work if the machines have been down for a few hours I've noticed. They simply hang.

The only reason why I haven't mulled over a move to ESXi is because I have a Bacula client running on the guest and it's possible that there are one or two other bits of software I would want to run on the host as well. ESXi is pretty much just a hypervisor that's pretty restrictive with the hardware it will run on and is much more restrictive on what can be installed on the host. I am certainly mulling over a move to VirtualBox. While I'm not one to get excited about ecomomising on disk space and efficiency the size of the VMware Server download certainly makes me question it.

Qt Goes LGPL

So, Qt has gone LGPL and now people can link proprietary and other non-GPL compatible software with it. Some will say "I told you so", but most of them are from the "develop everything for nothing, developers don't pay for development tools" bedroom programmer brigade. Qt is far superior to any other LGPLed or more liberally licensed cross-platform development toolkit there is, and there's a reason for that - selling commercial licenses and investing in Qt and its future has put it in that position. Using GTK+ as an equivalent example, no one has been willing to put in the gruntwork to really move it forwards versus other platforms beyond bugfixing and deprecation because there was no real incentive. Now Nokia would like to expand the usage of Qt, use Qt to help it sell more products and the licensing revenue is not as vitally important as it once was for Qt's survival. Now the hard work begins.

It has certainly changed the game as far as reliable cross-platform (GUI) development goes, and it is certainly a much more viable option than Java, GTK, wxWidgets or any of the other inferior methods that made the wrong decisions about GUI native look and feel (wxWidgets, SWT) + bugs versus alien look and feel + less bugs (Java). The problem with wxWidgets and SWT is that they have to find some commonality between all the platforms that they want to work on and port to that subset. There's a reason why SWT has a very long bug list and the Win32 version works far better than the GTK or Mac versions. For the bugs that exist developers have to find a way to replicate functionality or even bugs that work natively on all platforms so that code that works in one way on one platform works in the same way on another platform, allowing for any native nuances they can get away with. This is incredibly hard and is never likely to be a winning solution as they always have to provide the lowest common denominator of functionality.

Qt does cross-platform GUI development the correct way that allows things to work, most of the time, and that's GUI emulation. While I'm sure that Qt uses as much of the native platform as it can for native look and feel, the GUI has always been drawn within the toolkit. This enables developers to have more control over what is and isn't available, means they don't have to fight fires trying to achieve the lowest common denominator between platforms and they don't have an open ended bug list.

We will now see whether Nokia actually gets development and whether the Qt people can guide them. Nokia really needs Qt to work to help fend off companies like Microsoft outdoing them through developers and using their current monopoly to do so. What Qt needs is the following:

1. A way of breaking out from basic cross-platform and GUI development that encompasses network communication like DCOM and RMI as well as bringing Qt into the web development world. Plasma within KDE has done a great deal on that front. The new licensing additions will really help to remove any licensing questions developers might have had with doing the latter and makes things a lot simpler.
   
2. Head-off one of Microsoft's lock-ins for developers within desktop development. Qt needs a simple set of cross-platform APIs for dealing with Microsoft Office documents, a simple set of cross-platform APIs for dealing with Open Document programmatically and a way of getting the former to the latter programmatically. Do this and you're removing a huge impediment.
3. Make installation better. No one, in the Linux distro world certainly, thinks that easy installation of third-party software by users is necessary. It looks as though Qt might have to go alone by allowing Qt software to be easily installed.

If Qt software can look at these three things then they will head off any threat from Microsoft, get developers flocking to their platform and Nokia devices and allow alternative desktops, probably based on Linux, to actually start working for developers and users.

Free VMware ESXi and the Hypervisor Wars

It seems as though VMware ESXi is now free. I hope no one paid for it on Friday! At the moment we're using VMware Server to provide us with virtual machines running various services on Linux, as well as some Windows Server test machines that are running quite well on 8 gigabytes of RAM. All this runs on a CentOS host with the VM images residing on a XFS partition, and with Adaptec Storage Manager nicely monitoring the local RAID array.

While something like ESXi is nice from the point of view that I can worry an awful lot less about the host OS, the trouble with a limited hypervisor only install like ESXi, or even ESX, is that I don't necessarily get all the hardware drivers and support to install it on any machine I might want to and I am severely limited with regards to installing needed software on the host like RAID monitoring. In fact, I can't do it. Only ESX comes with a service console that allows you to manage the host, albeit in a fairly limited and restricted way. I suppose this duplication of effort, and the misplaced notion that the hypervisor is where everything should be, is why some people have had a go at the direction VMware and others like Xen seem to have been heading in. I think this whole separate hypervisor thing is nonsense as well, because when it comes down to it, you need to actually run something on the base hardware that actually makes the hardware.........work. With something like KVM it is tested, compiled and shipped with the kernel it runs within and can run as little or as much as anyone wants. Red Hat have already started. With hardware virtualisation that KVM uses it stops the imperfect need to trap instructions through software or through paravirtualisation, a much better approach, and simply leaves I/O virtualisation. This obviously needs a complete, robust and well tested set of device drivers, and guess who has these? That's right. Linux. Then there is power management, which Xen and VMware hosts simply do not have. Technically, KVM is just the better solution in terms of maintenance, and ultimately, performance.

Ultimately, I believe that this is where things will naturally head. Duplicating effort by forking kernels to retrofit Xen is just expensive and pointless, as is VMware's efforts to come up with their own customised and limited hypervisor-only host platform. Basically, anywhere that Linux can run, KVM can run, and any software you can run on Linux you can run on the host. In terms of reach, economies of scale and the wide range of devices KVM can be taken and run on will ultimately turn it into the clear leader. Lots of companies can also wade in and provide management tools. There are lots of places for KVM to go from where it is now, and is probably why the competition is trying to come up with an argument. While many people believe that the free ESXi is a response to Microsoft and Hyper-V, it is probably equally a play to fight off competition from Xen, and especially future competition from KVM, in their own back yard which are just simply going to be more flexible, run on more hardware and have more places to go. Free virtualisation is just going to be more widespread than a platform very much tied to Windows. Additionally, still charging for ESXi was pointless for VMware since it didn't do very much, and it's there to provide people with an upgrade path to ESX.

Having said all that, KVM is still a work-in-progress. ESXi is freely available, we can install it in no time and if it's any good maybe we'll just pay for ESX? Maybe we'll just sweat the hardware we have now on VMware Server and then just wait for KVM? If you can use virtualisation properly, sweat your hardware and don't buy into hype then the cost savings and the added functionality you can have can be quite large.

Getting apcupsd Working on CentOS, and Probably Elsewhere

In order to provide proper resilience for any server, it needs to react well in power outages. This means using a UPS (Universal Power Supply) and shutting down gracefully when all battery power has been exhausted, coming back up automatically when power is restored.

In order to do this we need an application that is able to communicate with the UPS, detect that there is a power outage and when the batteries have run down to a certain level, gracefully shut the system down. There is a piece of open source software called apcupsd that does this. Download the RPM for Enterprise Linux 5 from here.

Install via the normal rpm -ivh method. It’s also possible to get apcupsd through the DAG extended repository for CentOS and Red Hat, via RPMforge. As this is a one off package, we’ll just install it manually.

However, if you’re installing on a system that uses LVM, or you have a /usr partition that is separate from / then some further work will be needed. Make sure that your / partition is not on LVM. When you test shut down the machine you will notice that apcupsd does not power off the UPS correctly because it cannot find certain components – namely libnetsnmp.so.10, libz.so.1 and the wall executable. We can fix this by making copies to the /lib64 directory (if you run a 64-bit system):

cp /usr/lib64/libnetsnmp.so.10 /lib64
cp /usr/lib64/libz.so.1.2.3 /lib64
ln -s /lib64/libnetsnmp.so.10.0.1 /lib64/libnetsnmp.so.10
ln -s /lib64/libz.so.1.2.3 /lib64/libz.so.1

In addition, the wall executable cannot be found, as it resides in /usr/bin. If you do a check on the dependencies for wall you will see the following:

ldd /usr/bin/wall
libc.so.6 => /lib64/libc.so.6 (0×0000003092200000)
/lib64/ld-linux-x86-64.so.2 (0×0000555555554000)

This is fine, and shows the dependencies are there in the / directory. All we need to do is make a copy of wall to the root bin directory:

cp /usr/bin/wall /bin/span>

apcupsd will now have all the dependencies it needs when shutting down the machine, and when shutting down the UPS when all but the / partition has been unmounted.

PostgreSQL Versus...........Everyone Else

Recently, I have been pushing for us to move our databases for our web-based systems from MySQL to Postgres. This has finally been happening with very little trouble or drama, although many of our systems are now based on Rails and ActiveRecord so the change is transparent.

Things have finally got to a head where the features MySQL are adding are already there in Postgres, MySQL isn't quite as stable as we though it would be for a database system we will leave unattended for months at a time and the advantage of performance that MySQL supposedly once had has all but evaporated. From where I sit, it's becoming much easier for PostgreSQL to work away on getting their many features more efficient than it is for MySQL to add some of the features it lacks reliably. This isn't really a solid reason, but now that MySQL has been taken over by Sun I'm also not sure of their future direction. I've seen first hand how Sun have managed takeovers before, particularly in the case of Cobalt, and it doesn't inspire confidence. Sun always seem to pay over the odds for companies that don't really fit well with them or their current customers and market.

Additionally, I'm also pushing (begging on occasion) for one of our major clients (no names!) to update a system from using Access..............to just about anything else. They're not swallowing this at the moment because the current system works just about OK with the hacks we've put into it (we only keep a few days of the most recent data in the main database and then back up to another) and we get the odd corruption. This is a hangover from how the system was initially developed via another third-party. MTS was going to be used, and this was then dispensed with as they discovered they were trying to store stateful objects in it and the thing died, and then they had all the clients connecting directly to the Access database over a network share as a last resort. Surprisingly, with a few clients this seems to work, although Access 97 seems to be far better at concurrent connections than any later versions. The performance, as you can imagine, is terrible and getting meaningful data out of these databases ,which are kept on different sites, is a nightmare.

I wouldn't care, but this is a financial system! It just shows how temporary hacks that just about work turn into permanent solutions. Postgres would be an absolutely ideal replacement for this, would increase performance markedly, we'd have no corruption trouble, we could introduce proper transactions which would help enormously, we wouldn't need to back up data into another Access database (some of which are now creaking under the stress of their size and historical data), it's far easier to get access to the databases over a leased line with limited bandwidth, it would make support and new systems development far easier for us - and then there's the cost. The rest of the organisation pretty much uses Oracle, and installing and configuring Oracle at all these remote sites would be a really significant cost in terms of licensing and support for the Oracle DBAs.

I've read a lot of arguments about how Postgres is not suitable as a replacement for Oracle, but for all but the really, really, really high end features that pretty much no one uses, it's actually an improvement. I laughed at the comments in that article about editing the pg_hba.conf file being unintuitive (most things in Oracle are unintuitive) and crashing under extreme load. The first time I saw Oracle 9i and 10g start on a Windows box I was shocked. It took a full two or three minutes for it to come up, and that's when there was no data running on it yet. You needed a good gigabyte of memory on the server before it did anything. In contrast, the Windows ports of Postgres and MySQL start up in no time and take up far less resources than any Oracle installation.

I've been really impressed with how much Postgres has improved through the 8.x cycle, and the performance ideas and improvements that has come through such as asynchronous commit, autovacuum is now on by default in 8.3, full text search, lots of procedural language support and a native Windows port that is now truly excellent. These kind of steady improvements increase my confidence in Postgres still further.