Blog consolidation

I'm an irregular blogger to be sure but just in case anyone is subscribed to this blog, I've decided to start afresh in a new blog here. If you still care to subscribe, please change your links to the new blog as this one will go dead after this posting.

Getting started with home media streaming

I've had a PlayStation 3 for about a year now. I use it for gaming and as a blu-ray player. It's great at both and it owes me nothing for all the entertainment I've gotten out of it. But I was feeling a bit greedy so I decided to see how hard it would be to use it as a streaming media player hooked up initially to my home server.

Now, don't get excited. My "server" is just a cheap Windows desktop sitting in my office at home. It's not like I have a data center in my basement or something. Over the last year or so, I've managed to rip most of my CDs onto an external terabyte drive. I would not have pictured myself walking out of Costco with a terabyte under my arms a few years ago but that's Kryder's Law for you. I've also experimented a bit with ripping DVDs but haven't quite found the right set of tools for that yet. Anyway, there is a fairly big wad of media (including all my digital photos) sitting on this drive.

My house is networked (wireless) and I've used the PS3 wireless connection connect to the internet to do software updates and putz around on it's browser (although without a keyboard and mouse, the experience is too clunky to be useful). I knew the PS3 was connected so, hey, why not stream that audio and video off the home server? This is where I started messing around with Windows & its Media Player.

I kind of like the interface to Windows Media Player but found a few annoying things that pushed me away from it. I now use Media Monkey which is faster, doesn't screwup my library and has a much smarter web-based tag lookup and automatic library organizer than WMP. But then I started reading about connecting the PS3 to the desktop/server and the most common advice was to download WMP 11 which allegedly supports DLNA, also supported on the PS3. I must have messed around off and on for a couple of weeks trying to make this work. I got WMP 11 to act as a server for other Windows machines on the network but couldn't get the PS3 and desktop to recognize each other at all.

So I gave up on WMP 11 and decided to install TVersity. Wow. This software has what is so often lacking in Microsoft software - the "it works" feature. I just installed it, fired it up, pointed it at my media directories and then walked downstairs to the PS3 and there was my media. I can now browse digital photos on my TV, stream any music I want and even stream video (although there are some glitches there). Getting still greedier, I wondered if I could stream the media out to my daughter's iPod touch (I'm too cheap to buy one for myself :-). The touch is supported through the web interface of TVersity so I wasn't sure what to expect but all I needed to do was type a URL into Safari on the touch and wham, all the media is there. Not only that, but the video is automatically transcoded on the server side before it gets streamed down to the iPod. Very slick (but I need a faster server :-).

What else can you do with TVersity? It also provides an interface to internet video sources like youtube or the various TV networks. Being in Canada, many of these are blocked (boo!) but I played with some that aren't and must say that this makes browsing internet video much more enjoyable (sitting on a couch with a beer and remote instead of perched over a keyboard). I haven't played too much with this except to verify that it works. The hard part will be finding decent content that our big brother government hasn't blocked.

TVersity will also apparently allow you to access your home server from the internet but, given how pitifully slow my uplink speed it, I haven't bothered trying that yet.

So, what about those glitches in video? Well, this may be showing some inexperience on my part in ripping the video in the first place but I've found two problems. First, the audio is just 2-channel stereo. I expect that is a problem with the way I've encoded the sound tracks in my ripped video but not sure yet. The second problem is that some videos will display just fine (as if I were playing a DVD directly, although without the menus) but others stutter showing that something isn't keeping up with the frame rate. I'm sure it's not the PS3. So that leaves the network, the "server" CPUs (assuming it's doing some transcoding) or the server hard drive. Since I'm connected using 802.11g (the PS3 doesn't have an 11n adapter yet), my first suspicion is the network.

I know I could test this theory by moving my PS3 and desktop next to each other and wiring them up with ethernet but I also know I'm going to need more network bandwidth eventually if I want to stream HD video so now I need a wired networking solution for home (even 802.11n is unlikely to cut it). I could pull a load of ethernet cable through the walls but I hate doing that, especially between floors, so I looked around for alternatives. I happened to be listening to the HDTV podcast and they reviewed some powerline networking gear from Corinex. The conclusion was that the setup was easy and the equipment delivered performance near to the claims of 200Mbps. So, that's my next step. I'll report back here when I get that running.

The universal translator

I don't know anybody that didn't find the universal translator one of the coolest ideas on Star Trek. Being able to translate, in real-time, one language into another has got to have a transformational impact on society. Of course, the idea was not unique to Star Trek and some real-life versions of the device are actually starting to be used today.

However, in this blog post, I want to cover a different and easier universal translation problem that, to the collective shame of compiler engineers such as myself, has not yet been solved. I am referring here to the problem of universally translating software written in any of a number of different programming languages to be executed on any of a number of available computing platforms. Surely, given the well-defined nature of both programming languages and computer architectures, this should be much simpler than the translation between more ambiguous and more semantically rich human languages!

Sadly, we still live in a world where software is designed and built to run on some specific target machine or set of such machines. Yes, platforms like Java which promise "write once, run anywhere" have allowed us to make progress. However, even for Java, the practice of software development is closer to "write once, then test, debug and tune for each new platform".

The biggest negative impact of this practice is a forced trade-off between software availability and capability and/or quality. A given software developer or development organization can only afford to do so much porting, testing and debugging. Therefore, given that this is always required when moving to or certifying for new platforms, there is always a conscious trade-off between platform support and core software features or quality.

This where the universal translator comes in. In principle, compilers should be able to map well-written software into efficient code on any given platform. But do they? Well, gcc is certainly a great example of a compiler that does a good job of targeting lots of platforms and supporting a range of programming languages.

However, there are still two problems.

The first is that, while gcc is portable and widely used, it is not usually the best compiler to use on a given platform. Windows developers will more commonly use Microsoft's compilers. Professional developers on UNIX platforms will tend to use the platform vendor's compilers. Even on Linux, Intel's compilers are often preferred to gcc because of the greater performance they can extract from the hardware.

The second problem is that gcc doesn't support all the programming languages one would want to use and fails to provide good support for languages which are best compiled at run time such as Java or any of a number of dynamic languages such as Ruby or Python.

So .. if not gcc, then what?

Of course, both the Java Virtual Machine and the Microsoft CLI need to be considered as good candidates as universal translators. Unlike gcc, both of these are generally well supported and tunedb major computer vendors. They are also capable of and have demonstrated good quality runtime compilation and optimization.

The JVM, while not designed to support multiple languages, has been reasonably successful in supporting languages such as Ruby and Python. However, the JVM really is all about Java. There are technical challenges in trying to support a range of languages on the JVM, either because of their dynamic nature or because the language wants to manipulate low level constructs such as addresses and native memory that Java tries to abstract away. Even if these technical hurdles can be overcome (and projects like this one certainly show that it is feasible!), the fact remains that the providers of JVM implementations mostly worry about Java and other languages get short shrift.

What about the CLI? Well, unlike Java, it was designed to support a range of languages - at least the ones that Microsoft cares about. The CLI divides the world into "managed" and "unmanaged", referring mostly to the management of memory. This allows a certain amount of interoperability between these worlds (via, for example, Platform Invoke). However, support for languages which don't adhere to the constraints of managed code has been accomplished by forcing changes into the languages themselves. Managed C++, for example, is advertised as a set of extensions to C++ but more important than the extensions is a long list of limitations which really makes this a different language than C++.

So, if not Java or the CLI, then what?

I'm encouraged by the progress of the LLVM (Low-Level Virtual Machine) project at the University of Illinois. Like the JVM and CLI, LLVM is a virtual machine which can be targeted by compilers for a number of different languages and can be implemented efficiently on a number of different machines. Unlike the JVM and CLI, however, there are no constraints on the input language and no implied support for "management" functions like enforcement of memory safety. That doesn't mean that such management can't be implemented on top of LLVM of course. The VMKit project has shown that. While LLVM is lower level in terms of its instruction set and memory model, it is richer in other ways. It integrates data flow and control flow information with the code generated by the compiler, which preserves information that may be critical in generating good native code and accelerate later static or dynamic compilation steps. Of course, I would be remiss not to point out that there have been several successes and failures in introducing such interfaces in the past but I think LLVM is appearing at a point in time where compilation technology is ready to make it work and there is a broad appetite for this kind of solution.

Is LLVM the universal translator? Well, it's still under active research & development and not yet supported by major vendors but, in my opinion, is targeted at exactly the right place architecturally. A low level but portable virtual machine interface is a natural distribution format for software, written in any of a number of languages. It won't replace Java or CLI bytecodes but it could replace the native binaries used to distribute all kinds of other software. It also gives platform vendors the ability to optimize software for their operating systems and hardware with the portability and applicability of gcc but the dynamicity of Java. I'll be keeping my eye on it.

Are you a Pakled ?

Many of you may be fans of Star Trek. I was for a long time. First the original series then the Next Generation, Deep Space Nine and Voyager series. My interest sort of waned sometime during the Voyager era. However, one episode I remember very clearly was from the Next Generation series and was entitled "Samaritan Snare".

In Samaritan Snare, the Enterprise encounters an alien ship (ok, this happens alot :-). The ship needs help but the aliens (called Pakleds) are inexplicably incoherent about what they need. It turns out that the Pakleds are really a race of technology scavengers, just picking up technology that seems about right for what they need and using it. They have no idea how the technology works. When things go wrong, they are clueless about how to fix the problem.

I remember for many years after the episode aired when I worked in the guts of our compilers how much entertainment we got from interacting with people who, to us, could easily have been Pakleds. These were otherwise intelligent people, many of them literate in the use or even programming of computers, who clearly had no idea how computers actually work. This didn't appear to matter until something broke. Then, they would desparately seek help but would be absolutely incoherent in describing the problem, often not much better than the Pakled's classic "It is broken, can you make it go?".

I've had alot of time to think about this phenomenon and it really isn't a joke. For years, decades really, the IT industry has been building an edifice of abstractions and interfaces (or, if you prefer frameworks) which have provided, with varying degrees of success, ways to interact with and program computers which are provide progressively richer experiences and semantics. We have also trained an entire generation of programmers to work exclusively at these higher levels of abstraction. This richness has come with costs, however.

The first cost is the one already alluded to - that computer users and programmers have become less and less aware of how the technology actually works. This isn't just true about the hardware. I would wager that most software developers know close to nothing about the operational details of anything other than the layer below them and the layer above (if they happen to be framework developers themselves). Does this matter?

Well, many people use the analogy of a car - that many people know how to drive one but few understand even the basics of how it works; yet, people get along quite well without this knowledge. This is true for the most part, although it becomes a bit more of an issue when stranded in sub-zero weather outside of cellular telephone range. Nevertheless, the relationship between cars and drivers generally works. Why isn't this true with computers?

I think this is simply a statement of technology maturity. The rate of change in the basic technology going into cars has been undergoing relatively slow change for a long time (recent innovations in alternate fuels and hybrids being a notable departure). Computer technology, on the other hand, changes like the weather. Software engineering is also a far less mature discipline than mechanical engineering, rarely employing basic notions of modularity and change control, let alone more advanced architectural processes. The result? Complex and often unforeseen dependencies among software components. This becomes a hornet's nest for a software engineer to enter when there is either some kind of failure or, equally, when the system isn't performing quite as well as expected.

Now onto the second cost. This is one that is not yet a big issue but is sneaking up on us. Performance, by and large, has not been a serious software issue for many years. That isn't because we've stopped trying to build new things with software nor is it because we've all become brilliant performance engineers. It is because exponential growth in hardware performance, and specifically advances in processor speed and memory capacity, have propelled us forward despite the additional software-driven overhead. As Bob Metcalfe said, "Grove giveth and Gates taketh away". If you are unconvinced about the magintude of software bloat, check out this sample call stack from a Java application running on the JBoss application server or this striking illustration of how much it costs in time and memory to do even the simplest operations with todays frameworks and protocols.

So what's the problem? Well, processor speed just isn't improving like it used to. In particular, Grove (or his successors) still giveth but it is not in the simple form of faster processors. Instead, we're just getting more that run about the same speed. And memory? Well, it is still getting denser, faster and cheaper but it is now one of the most expensive components of a computer, both in terms of dollars and power consumption. Meanwhile, Gates (or his successors) continue to taketh away, if anything at a faster pace.

This is not just an indictment of Intel or Microsoft, although both play prominent roles. The entire hardware industry is being driven by the same physical forces as Intel and virtually all software developers continue to create fatter, more wasteful (although, in fairness, probably quite innovative) software, oblivious of the collision course with hardware. Modern software developers are like Pakleds wandering through space not realizing that their ship is almost out of fuel and without a clue how to fix it if it does.

Are you a Pakled ?

Innovating without thrashing

I enjoyed the recent article by Bill Buxton in BusinessWeek. It is entitled "How to Keep Innovating" but it is as much advice for the busy mind as it is a recipe for innovation. Bill starts by making the case that, while depth of skill is essential, especially in one's profession, there are diminishing returns to trying to perfect that skill. Instead, he advises that there should always be a new passion in the pipeline, something to broaden one's experience and inform ongoing innovation.

Along the way, Bill points out the temptations of the curious mind, which I definitely experience and sometimes call "thrashing":

Always being in the throes of a passionate beginning is one of my primary methods of sustenance. But as is all too frequently the case, too much of a good thing can cause its own set of problems. The energy of pursuing such passions can be addictive, and take over at the expense of other things that are equally or more important. It can become destructive. I found this out the hard way, and my wife was able to help me when I most needed it. It was she who reminded me that the limitlessness of life has to be shoe-horned through the limitations of the present.

Lacking the discipline to focus on a small number of passions at one time can lead one to become a jack of all trades but master of none (or very few at any rate). I have plenty of passions - mathematics, technology, literature, history, geopolitics, music and more. Unfortunately, there are times when I thrash between them deriving only a tiny amount of benefit from my investment in each (not to mention shortchanging other parts of my life like my family).

I'm getting better at this but am glad to see that I'm not the only one with this affliction!

Cringley on multicore

I just picked up the latest copy of Technology Review and read Cringley's article on multicore.

First of all, I have to say that Cringley can write. I have struggled to explain this trend and the set of associated software challenges many times, to technical and non-technical people alike and never approached the concise and approachable description given in this article. I'm a techie at heart and it's at times like this that I realize I have a long way to go as a writer and communicator.

Anyway, self-incrimination aside, I think this article (assuming people aren't sick of reading about this subject by now) really does a service by putting this trend into a historical context that everyone can understand and by clearly explaining some of the subtleties here, like frequency not equating to performance and, for that matter core count not equating to performance. Those messages are suprisingly hard to deliver to people that insist on a simple characterization of how computers work or even more important to those that have no interest at all in how computers work. It also does a pretty good job of explaining why parallel programming might be hard to get right.

I do wish that Cringley had at least mentioned the distinction between multicore as a client/mobile phenomenon vs. multicore in the server space. He does mention map/reduce (which is completely a server-side programming model) but fails to observe, especially in his conclusion, that while client software may fail to drive for ever greater parallelism, there is a virtually insatiable appetite for it in the server world. However, like the video processing example he gave, while the parallelism is often easy to find in server-side programs, there are many reasons why it is difficult to extract.

Some of those reasons are bound up in the issues he does cover like the lack of good tools and languages but another big issue is the inertia of existing large software environments. This so-called "legacy" software (I've been told by many that hold this stuff dear that "legacy" is pejorative, kind of like used cars vs. "previously enjoyed " cars I guess) .. sorry side-tracked. This "previously enjoyed" software has a suprisingly long life - often measured in decades rather than years. The problem here is that, even if we had the tools and languages and skills and even the desire to make this software exploit parallelism, there aren't enough programmers in the world to even put a dent in it. We're talking about trillions of lines of code. Hard to fathom I know but it's true. And much of civilization depends upon it (that is not an exaggeration). This is a particularly hard nut to crack and we in the server/enterprise computing world have this problem in spades. On the client, people change their software alot more frequently - usually when the shiny new version is available or Microsoft breaks compatibility, whichever comes first.

Parochial interests aside, I highly recommend the article. It contains no new revelations but, if you work in this area, it just might be something your spouse or friends will understand when they ask what you do for a living.

Clouds without the nuts & bolts

I recommend reading Jon Stokes interview (and part 2) of Russ Daniels of HP on Cloud Computing. I read quite a bit about Cloud and, as a techie, get completely frustrated by the lack of consensus about what it all means. On the other hand, it is clear that consumers and businesses both see alot of potential value in Cloud. Daniels does an excellent job in this interview of explaining that value, from both consumer and enterprise perspectives. He does it without getting into the nuts & bolts of what a Cloud is (which is good, because it's easy to get bogged down there) and, to his credit, without too much boosting of HP products & services.

Daniels' sees the cloud as the intersection of utility computing (resources on-demand) with SOA (loosely coupled application architecture) and Web 2.0 (pervasive accessibility and social experience). He pulls it together in a very compelling way and with some good examples that left me wondering whether I've fully understood the implications of Cloud.