• Dying MacBook Pro battery

    I've had my MacBoook Pro for a bit over than 11 months. Not so long ago, I remember that the battery lasted for more than three and a half hours when using the machine very lightly (some web browsing or some e-mail reading, for example), and for a bit over an hour with (very) heavy usage. But recently, I started to notice that its capacity had shortened to alarming levels: it now only lasted for about an hour with the machine idle! That didn't feel right for a machine that only had a year of life.After installing coconutBattery, I was scared to see that the battery only had 53% of its original capacity, and that was after a modest number of 80 full charge cycles. Compared to several other similar machines with much higher cycles count and battery life, mine was in very bad condition.I don't know if that was due to a defective battery or misuse of it (like too much heat caused by the computer damaging it), but I'm inclined to think it's the former specially because I've read similar (well, worse) problems from people that bought this same machine around the same dates.Anyway, the thing is I went to an Apple Store on monday to explain the situation: they just took the battery, noted down the machine's serial number (no need to show the invoice!) and told me that they'd send me an SMS when they had resolved the problem. And... today... I received that message. Shiny new battery and no complaints from them! Kudos to the service, again. [Continue reading]

  • Hello world in Linux/ppc64

    I'm decided to improve my knowledge on the Cell platform, and the best way to get started seems to be to learn 64-bit PowerPC assembly given that the PPU uses this instruction set. Learning this will open the door to do some more interesting tricks with the architecture's low-level details.There are some excellent articles at IBM developerWorks dealing with this subject, and thanks to the first one in an introductory series to PPC64 I've been able to write the typical hello world program :-)Without further ado, here is the code!## The program's static data#.datamsg: .string "Hello, world!n" length = . - msg## Special section needed by the linker due to the C calling# conventions in this platform.#.section ".opd", "aw" # aw = allocatable/writable.global _start_start: .quad ._start, .TOC.@tocbase, 0## The program's code#.text._start: li 0, 4 # write(2) li 3, 1 # stdout file descriptor lis 4, msg@highest # load 64-bit buffer address ori 4, 4, msg@higher rldicr 4, 4, 32, 31 oris 4, 4, msg@h ori 4, 4, msg@l li 5, length # buffer length sc li 0, 1 # _exit(2) li 3, 0 # return success scYou can build it with the following commands:$ as -a64 -o hello.o hello.s$ ld -melf64ppc -o hello hello.oI'm curious about as(1)'s -a option; its purpose is pretty obvious, but it is not documented anywhere in the manual page nor in the info files.Anyway, back to coding! I guess I'll post more about this subject if I find interesting and/or non-obvious things that are not already documented clearly anywhere. But for beginner's stuff you already have the articles linked above. [Continue reading]

  • 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 installThis 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. [Continue reading]

  • Fixing id's command line parsing

    Today's work: been fixing NetBSD's id(1)'s command line parsing to match the documented syntax. Let's explain.Yesterday, for some unknown reason, I ended up running id(1) with two different user names as its arguments. Mysteriously, I only got the details for the first user back and no error for the second one. After looking at the manual page and what the GNU implementation did, I realized that the command is only supposed to take a single user or none at all as part of its arguments.OK, so "let's add a simple argc check to the code and raise the appropriate error when it is greater than 2". Yeah, right. If you look at id(1)'s main routine, you'll find an undecipherable piece of spaghetti code — have you ever thought about adding multiple ?flag variables and checking the result of the sum? — that comes from the fact that id(1)'s code is shared across three different programs: id(1), groups(1) and whoami(1).After spending some time trying to understand the rationale behind the code, I concluded that I could not safely fix the problem as easily as I first thought. And, most likely, touching the logic in there would most likely result in a regression somewhere else, basically because id(1) has multiple primary, mutually-exclusive options and groups(1) and whoami(1) are supposed to have their own syntax. Same unsafety as for refactoring it.So what did I do? Thanks to ATF being already in NetBSD, I spent the day writing tests for all possible usages of the three commands (which was not trivial at all) and, of course, added stronger tests to ensure that the documented command line syntax was enforced by the programs. After that, I was fairly confident that if I changed the code and all the new tests passed afterwards (specially those that did before), I had not broken it. So I did the change only after the tests were done.I know it will be hard to "impose" such testing/bug-fixing procedure to other developers, but I would really like them to consider extensive testing... even for obvious changes or for trivial tools such as these ones. You never know when you break something until someone else complains later. [Continue reading]

  • ATF imported into NetBSD

    Finally! After more than five months of development (with different intensities of work), I am very pleased to announce that ATF, my Google Summer of Code 2007 project, has been integrated into the NetBSD source tree.For more details see the official announcement in the tech-userlevel@ mailing list. [Continue reading]

  • ATF 0.3 released

    I've just published the 0.3 release of ATF. I could have delayed it indefinitely (basically because my time is limited now), so I decided it was time to do it even if it did not include some things I wanted.The important thing here is that this release will most likely be the one to be merged into the NetBSD source tree. If all goes well, this will happen during this week. Which finally will give a lot of exposure to the project :-) [Continue reading]

  • Games: Resistance: Fall of Man

    Yesterday night I finished playing "Resistance: Fall of Man", a game that came with the PlayStation 3 Starter Pack I bought. It was not as long as I expected but found it to be a very good game. The storytelling, sound and gameplay was nice, but I cannot judge the graphics. I already showed you the crappy monitor used with the PS3... so I'll surely go through the whole game again when I get a nicer screen.One specific thing I liked, when comparing it to other FPS such as Doom 3 or F.E.A.R., was that you barely have to use the flashlight, which in other games gets boring after a while. Well... I guess this is because Resistance was not meant to be a frightening game, as those other two are. Another point in favor is that the game has a nice set of guns, some of which are pretty original and different to all other games I've seen in this area. And it's hard to run out of ammo, at least in the most basic (but useful) guns.Speaking of other games, there are some levels that will remind you a lot to Call of Duty, and some others to Half Life 2. Not bad, but seems like developers of FPS are running out of ideas.To conclude, let me say that playing with the Sixaxis controller, as opposed to a keyboard plus mouse, was extra nice. It was very difficult to get used to it, but in the end makes for a good gaming experience. I'm now willing to try Metroid Prime 3 or Red Stell on the Wii with its Wiimote, which surely are better in this regard.Recommended game :-) [Continue reading]