Mad at the Cell SDK

I've been installing the Cell SDK 3.0 on two Fedora 8 systems at home — a PlayStation 3 and an old AMD box — and I cannot understand how someone (IBM and BSC) can publish such an utterly broken piece of crap and be proud of it. Sorry, had to say it. (If you are one of those who wrote the installer, please excuse me, but that's what I really think. Take this as a constructive criticism.)

Before saying that Fedora 8 is not supported and that I should only run this on Fedora 7, shut up. I am sure all the problems are there too, because none of them can be related to the system version.

Strictly speaking, it is not that the installer does not work, because if you follow the instructions it does. But it is a very strange program that leaves garbage all around your system, produces warning messages during execution and the garbage left around will keep producing warnings indefinitely. Plus, to make things worse, the network connection to the BSC — where the free software packages are downloaded from by yum — is extremely unreliable from outside the university's direct connection (that is, from home), which means that you will have to retry the installation lots of times until you are able to download all the huge packages. (In fact, that's what annoys me most.) And this is not a problem that happened today only; it also bit me half a year ago when installing the 2.1 version.

Let's talk about the installer, that marvelous application.

Starting with version 3, the SDK is composed of a RPM package called cell-install and two ISO images (Devel and Extras). When I saw that, I was pretty happy because I thought that, with the RPM package alone, I'd be able to do all the installation without having to deal with ISO images. It turns out that that is not true, as some components only seem to be available from within them (most likely the non-free ones, but I haven't paid attention).

Ah, you want to know what the SDK contains. Basically, it is composed of a free GCC-based toolchain for both the PPU and SPUs, the free run-time environment (the libspe2), a proprietary toolchain, the proprietary IBM SystemSim for Cell simulator and some other tools (a mixture of free and non-free ones). So, as you can see, we have some free components and some proprietary ones. You can, in fact, develop for the Cell architecture by using the free components alone. So why on earth do you need the proprietary ones? Why can't you skip them? Why aren't they available in some nice repository that I can use without any external "installer" and avoid such crap? That's something I don't get. (Maybe it's possible with some extra effort, but not what the instructions tell you.)

OK, back to the installer. So you need to copy the two ISOs in a temporary directory, say /tmp/iso and then run the installer by doing something like:

# cd /opt/cell
# ./cellsdk --iso /tmp/dir install

This will first proceed to show you some license agreements. Here is one funny point: you must accept the GPL and LGPL terms. Come on! I am using Fedora, and I am already using lots of GPL'd components for which I did not see the license. Why do I have to do that? And why do I have to reaccept the IBM license terms when I already did that in the downloads page?

After the license thing, it mounts the images under /tmp/sdk (keep this in mind because we'll get back to it later), probably does some black magic and at last launches yum groupinstall with multiple parameters to install all the SDK components. All right, you accept the installation details and it starts installing stuff. This would be OK if it wasn't for the network connection problems I mentioned earlier; I've had to restart this part dozens of times (literally) to be able to get all packages. So, again, question: why couldn't you simply tell me what to put in yum's configuration, define some installation groups for the free components alone and let me use yum to install those without having to trust some foreign and crappy installer script? Why do you insist on using /opt for some components and uninconsistently between architectures?

And why did I mention /tmp/sdk? Because the yum repositories registered by the installer have this location hardcoded in. Once you unmount the ISO images (that is, when the installation is done), yum will keep complaining about missing files in /tmp/sdk forever — unless you manually change yum's configuration, that is. What is nicer, though, is that yum always complains about one specific repository because it is only available online, yet it also looks for a corresponding image in /tmp/sdk.

At last, there are also some random problems (probably caused by all the above inconsistencies). Once, the script finalized successfully but the SDK was left half installed: some components were missing. Another time, the installer hang in the middle (no CPU consuption at all, no system activity) when it seemed it had finished and had to manually kill it. After restarting it, it effectively had not finished as it had to install some more stuff.

Summarizing... all these problems may not be so important, but they make one feel that the whole SDK is a very clunky thing.

I wish someone could create native packages for the free components of the SDK and import them into the official Fedora (or, please, please, please, Debian) repositories. After all, these are just a native compiler for the PPU, a cross-compiler for the SPUs, the libspe2 and the SPU's newlib. Note that the GCC backends for both the PPU and SPUs are already part of the FSF trees, so it shouldn't be too difficult to achieve by using official, nicer sources.

Rant time over.

« Previous

Featured software

Featured posts