Chipped Chrome

VIA recently announced that they have opened their reference documentation for their GPUs and are even now actively working with the openChrome project. For me, however, it's too little too late.

I've finally grown tired of even trying to get accelerated video working on my VIA-based MythTV box. XvMC support is simply non-existent and accelerated anything just doesn't work. With standard 480i broadcast TV I had no problem being CPU-bound for MPEG2 decoding, but it just doesn't fly with 720p and a pcHDTV card. I throw in the towel.

I'm looking at what Shuttle has to offer instead with either an Intel, NVIDIA or AMD platform. It appears that the graphic chipset choices break down into either GeForce 8, Intel GMA X4500HD, Intel GMA 3100 or GeForce 7050PV. The best NVIDIA choice appears to be the 7050PV, as it seems to enjoy known XvMC acceleration on MythTV's feature matrix and some have even reported getting it to work in a dual-head environment. The Intel cards should theoretically offer great performance for the power and enjoy good Linux driver support due to Intel's great contributions to X.Org, however Myth's wiki seems to know painfully little about the Intel GMA's. As far as XvMC support goes, Intel's chipsets don't seem to have a great track record.

So GeForce 7050 seems to be the most sane choice for those who are tired of fisticuffs with xorg.conf. But wait! We have audio to worry about too. If I'm going with a Shuttle GeForce 7050, then it looks like I'm going with a Realtek ALC888DD. Here again, MythTV notes that yet another Intel chipset is a true pain to work with. Still, I noticed that the MythTV hardware database notes there was at least one other Shuttle user with a similar setup that was able to get things to work.

Weirdly enough, both of the GeForce 7050 Shuttle boxes I found were AMD boxes. Go figure...

Empty Spaces

Yup, I'm still trying to work my way around Jini. This time it's JavaSpaces.

Apache River hasn't gone much farther from the last time I looked at it, but I liked the bare-bones reference implementation aspect. GigaSpaces seems a bit thick for my tastes and seems to be tightly coupled with their application server. I thought Blitz JavaSpaces might be a better fit, especially if I could use their fault tolerant edition.

I was able to get Blitz up and running then configured it to do unicast discovery to a pre-existing Jini registrar without a problem. I was having problems getting my client to connect in its security context, so I decided to dig a little deeper. As I did I also kept an eye towards fault-tolerance, but found that branch seemingly suspended. I later found a post from the author indicating he didn't really see a good motivation for moving forward with his fault-tolerance work:

In my spare moments I've been doing a re-implementation but the fact of the matter is that it's not a trivial problem to solve (though I believe I do have a solution). And here's the rub, this work doesn't pay the bills which means that it's going to take a long time to implement because I have to do a day's work first. For those who don't know, most of Blitz has been written during time between periods of employment - not over weekends and evenings as you might expect.
This presents me with a problem - users seem to want this feature but I'm struggling to see doing this as a good thing. Here's some of my reasons:

1. I'd be building a significant feature which will, judging by demand, make a lot of money for those who use it but zilch for me.
   
2. Not only do I earn nothing from this venture but I have to earn a significant amount of cash just to allow me time to develop the feature. Basically, I'd be financing everybody else's money making ventures.
   
3. One of GigaSpaces key value adds is the clustering/replication feature - they are fully commercial and need to earn a crust plus they're one of only a few credible companies that can provide corporate grade support for JavaSpaces. Were I to do this work for Blitz I'd maybe be damaging the market I've been helping to create.
   

Right now, I feel like the price of this piece of work is too high for me personally and for others in the commercial JINI world (and like it or not they are an important element in any future success for JINI). I can see why Blitz users might want this feature - they can avoid paying Gigaspaces a license for starters.

So... it seems like the development of an enterprise ready Blitz isn't in the cards. Casually strolling through Wikipedia's definition of a Tuple space brought up Fly Object Space, a tuple space that is not a JavaSpace implementation. While it doesn't fit into the Jini realm I know and love, it is a more minimalistic implementation of an object space that fits my desire of something smaller and to-the-point. It doesn't appear to support replication or fail-over on the non-commercial level, but I'm checking to see if there are plans to support it on a commercial level.

It's tough. I need an object space that has a minimalistic implementation, has a small footprint and can at least run active/passive for fault tolerance. Maybe I might have to dust off my old Terracotta instance and try out SemiSpace.

EDIT: Be sure and see Nati Shalom's comments following this post.

Suspend to RAM - Actually Works? Really?

Let it be known that today I was actually able to get my Linux laptop, using the proprietary NVIDIA drivers no less, to suspend to RAM. I'll give you a moment to pick yourself up off the floor.

Using a less-than-stock build of OpenSUSE 11.0, KDE 4.1.3, the latest NVIDIA drivers and a Dell Precision M6300 I was able to successfully both SUSPEND TO and RESUME FROM RAM. I crap you not. I even took a picture.

Wow. That's... like... historic.

Dark Power Adjusting Laptop Brightness

One reason why I was really looking forward to KDE4 was the level of abstraction it offered from services and hardware while offering a lot of unification as far as end-user interaction and desktop integration.

One fantastic example of this has become PowerDevil, which was introduced around the KDE 4.1 time but is now standard in KDE 4.2. Its functionality is based upon Solid, KDE4's hardware abstraction layer (which also abstracts audio & bluetooth).

PowerDevil runs as a fully-fledged KDE4 service, meaning it doesn't need to be some awkward "TSR" or persistent applet in your system tray. That also means that it runs much leaner than kpowersave, which largely monitored events and then attempted to send system calls along to the appropriate background resources.

The PowerDevil coders may talk down the control panel UI, but it works rather well. And while it doesn't have a Plasmoid (applet) yet or much in the way of UI, the beauty of KDE4 means it doesn't immediately need to. Since PowerDevil is well integrated into the KDE4 desktop, KRunner displays all the immediate options you need when you type "power profile" into the runner dialog. Very nice.

This kind of desktop integration is exactly what will make KDE4 a success in the long run, and it's great to see projects like PowerDevil emerge that take advantage of what KDE4, Solid and Plasma have to offer.