Showing 7 posts
A long while ago — just before buying the MacBook Pro — I already complained about software bloat. A year and two months later, it is time to complain again. I am thinking on renewing my MacBook Pro assuming I can sell this one for a good price. The reasons for this are to get slightly better hardware (more disk, better GPU and maybe 4GB of RAM) and software updates. The problem is: if I am able to find a buyer, I will be left without a computer for some days, and that's not a good scenario. I certainly don't want to order the new one without being certain that I will be paid enough for the current one. So yesterday I started assembling some old components I had lying around aiming at having an old but functional computer to work with. But today I realized that I also had the PlayStation 3 with Fedora 8 already installed, and that it'd be enough to use as a desktop for a week or so. I had trimmed down the installation to the bare minimum so that it'd boot as fast as possible and to leave free resources for testing Cell-related stuff. But if I wanted to use the PS3 as a desktop, I needed, for example, GNOME. Ew. Doing a yum groupinstall "GNOME Desktop Environment" took quite a while, and not because of the network connection. But even if we leave that aside, starting the environment was painful. Really painful. And Mono was not there, at all! It is amazing how unusable the desktop is with "only" 256MB of RAM; the machine is constantly going to swap, and the disk being slow does not help either. I still remember the days when 256MB was a lot, and desktop machines were snappy enough with only half of that, or even less. OK, so GNOME is a lot for 256MB of RAM. I am now writing this from the PS3 itself running WindowMaker. Which unfortunately does not solve all the problems — and the biggest one is that it is not a desktop environment. Firefox also requires lots of resources to start, and doing something else in the background still makes the machine use swap. (Note that I have disabled almost all of the system services enabled by default in Fedora, including SELinux.) If I finally sell my MBP, this will certainly be enough for a few days... but it's a pity to see how unusable it is. (Yeah, by today's standards, the PS3 is extremely short on RAM, I know, but GNOME used to run quite well with this amount of RAM just a few years ago.)
February 28, 2008
·
Tags:
<a href="/tags/bloat">bloat</a>, <a href="/tags/gnome">gnome</a>, <a href="/tags/ps3">ps3</a>, <a href="/tags/software">software</a>
Continue reading (about
3 minutes)
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 :-)
November 5, 2007
·
Tags:
<a href="/tags/games">games</a>, <a href="/tags/ps3">ps3</a>
Continue reading (about
2 minutes)
A bit more than a week ago, I posted about considering to buy a PlayStation 3 and, finally, yesterday evening I took the plunge and bought a Starter Pack that comes with a PlayStation 3 (60GB model, about to be deprecated), 2 Sixaxis controllers (I know the DualShock 3 is about to be published) and two games (Resistance: Fall of Man and Motorstorm). I love the machine so far and think that the money was well spent, even though I haven't had a chance to install Linux yet. Sincerely, I tried but failed: Fedora 8 (Test 3) doesn't seem to be supported by the installer, but I'll keep trying. My setup: But this screws everything up: Eww, ugly, isn't it? ;-) What's the point of a machine able to output Full HD when I only have this crappy monitor? Specially when the signal of the PS3 is going through an old Avermedia TV Phone card plugged into an old computer that is later connected to this flat panel though an analog VGA connection. Lots of image quality loss! (The Linux console looks even uglier. No joy in using it as a desktop system with this setup, as I wanted to do.) By the way, the monitor is showing the Folding@Home client bundled in the PS3 system.
October 14, 2007
·
Tags:
<a href="/tags/ps3">ps3</a>
Continue reading (about
2 minutes)
For the last couple of weeks, I've been considering to get a PlayStation 3. Not because of gaming, as I'm not a hardcore gamer, but because of the development platform it provides: a rather compact and cheap machine with an heterogeneous multiprocessor — the Cell Broadband Engine — that can easily run third-part OSes. My current research tasks focus on this area, so having a personal Cell machine at home to tinker with would be nice. Sure, we do already have a PS3 at the department and access to the Cell blades at the BSC, but none of these are easy to access physically and they are used by other researchers to do work. Leaving them unusable or doing drastic changes to the installed systems could annoy them. (OK, the PS3 is here to allow us to install custom kernels and do more bizarre changes, but still people is working on it periodically.) But making the decision is hard. Pros: A machine with a Cell processor. Ideal for my current work. A Blu-ray player.Cheap considering the above two points.Additionally *grin*, it's a gaming machine. Never owned one myself. Installing third-party OSes is supported by the official firmware.Possibility to install NetBSD and help in the port.Possibility to try other distributions of Linux rather than the ones officially supported by the Cell SDK. (We are currently use Fedora 6 on the PS3 at the department, and I don't like it that much, but I can't easily convince my tutor to try something else.) Easy access to the machine, with a monitor and keyboard.Maybe provide a "decent" desktop computer for lightweight tasks. I've heard rumors of a DVB kit for the PS3 coming in christmas. This could be a great selling point for me. Cons: Considering it's a gaming machine, it's too darn expensive.In my eyes, it's the worst third-generation gaming machine nowadays. The Xbox 360 has a lot more games. The Wii has the Wiimote (and my brother already owns this, so I can play with it if I want to). And as I already said, I'm not a hardcore gamer (and don't want to be one). But hey, I'd be getting a gaming machine, but the worst option... I'd also have to buy a monitor for it, and flat displays above 22" (the ones that support 1080 lines) are not cheap. Sum this (even if I'd end up with a 20" one) to the PS3's price and a couple of games.It's ugly, but oh well, you can surely have a different opinion.I'm afraid I'd not use as much as I think I'd do now. Any other points? I see I listed more pros than cons, but still... I'm unsure. Update (Sep 6th): And now, Sony has officially announced a price drop for the PS3...
October 5, 2007
·
Tags:
<a href="/tags/ps3">ps3</a>
Continue reading (about
3 minutes)
The deadline for my PFC (the project that will conclude my computer science degree) is approaching. I have to hand out the final report next week and present the project on July 6th. Its title is "Efficient resource management in heterogeneous multiprocessor systems" and its basic goal is to inspect the poor management of such machines in current operating systems and how this situation could be improved in the future. Our specific case study has been the Cell processor, the PlayStation 3 and Linux, as these form a clear example of an heterogeneous multiprocessor system that may become widespread due to its relatively cheap price and the attractive features (gaming, multimedia playback, etc.) it provides to a "home user". Most of the project has been an analysis of the current state of the art and the proposal of ideas at an abstract level. Due to timing constraints and the complexity of the subject (should I also mention bad planning?), I have been unable to implement most of them even though I wanted to do so at the very beginning. The code I've done is so crappy that I won't be sharing it anytime soon, but if there is interest I might clean it up (I mean, rewrite it from the ground up) and publish it to a wider audience. Anyway, to the real point of this post. I've published an almost definitive copy of the final report so that you can take a look at it if you want to. I will certainly welcome any comments you have, be it mentioning bugs, typos, wrong explanOctations or anything! Feel free to post them as comments here or to send me a mail, but do so before next Monday as that's the deadline for printing. Many thanks in advance if you take the time to do a quick review! (And yes... this means I'll be completely free from now on to work on my SoC project, which is being delayed too much already...) Edit (Oct 17th): Moved the report in the server; fixed the link here.
June 19, 2007
·
Tags:
<a href="/tags/cell">cell</a>, <a href="/tags/linux">linux</a>, <a href="/tags/pfc">pfc</a>, <a href="/tags/ps3">ps3</a>
Continue reading (about
2 minutes)
The mainstream Linux sources have some support for the PlayStation 3, but it is marked as incomplete. Trying to boot such a kernel results in a stalled machine, as the kernel configuration option says: CONFIG_PPC_PS3: This option enables support for the Sony PS3 game console and other platforms using the PS3 hypervisor. Support for this platform is not yet complete, so enabling this will not result in a bootable kernel on a PS3 system.To make things easier, I'd simply have used the Linux sources provided by YellowDog Linux 5 (YDL5), which correspond to a modified 2.6.16 kernel. However, as I have to do some kernel development on this platform, I objected to using such old sources: when developing for an open source project, it is much better to use the development branch of the code — if available — because custom changes will remain synchronized with mainstream changes. This means that, if those changes are accepted by the maintainers, it will be a lot easier to later merge them with the upstream code. So, after a bit of fiddling, I found the public kernel branch used to develop for the PS3. It is named ps3-linux, is maintained by Geoff Levand and can be found in the kernel's git repository under the project linux/kernel/git/geoff/ps3-linux.git. Fetching the code was "interesting". I was (and still am) a novice to git, but fortunately my prior experiences with CVS, Subversion and specially Monotone helped to understand what was going on. Let's now see how to fetch the code, cross-build a custom kernel and install it on the PS3 using YDL5. To checkout the latest code, which at this moment corresponds to a patched Linux 2.6.21-rc3 sources, do this: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git ps3-linux This will clone the ps3-linux project from the main repository and leave it in a directory with the same name. You can keep it up to date by running git pull within the directory, but I'm not going to talk about git any more today. As I cross-compile the PS3 kernel from a FC6 Intel-based machine with the Cell SDK 2.0, I need to tell it which is the target platform and which is the cross-compiler before being able to build or even configure a kernel. I manually add these lines to the top-level Makefile, but setting them in the environment should work too: ARCH=powerpc CROSS_COMPILE=ppu- Now you can create a sample configuration file by executing the following command inside the tree: $ make ps3_defconfig Then proceed to modify the default configuration to your likings. To ease development, I want my kernels to be as small and easy to install as possible; this reduces the test-build-install-reboot cycle to the minimum (well, not exactly; see below). Therefore I disable all stuff I do not need, which includes modules support. Why? Keeping all the code in a single image will make later installation a lot easier. Once the kernel is configured, it is time to build it. But before doing so you need to install a helper utility used by the PS3 build code: the Device Tree Compiler (or dtc). Fetch its sources from the git repository that appears in that page, run make to build it and manually install the dtc binary into /usr/local/bin. With the above done, just run make and wait until your kernel is built. Then copy the resulting vmlinux file to your PS3; I put mine in /boot/vmlinux-jmerino to keep its name version-agnostic and specific to my user account. Note that I do not have to mess with modules as I disabled them; otherwise I'd have to copy them all to the machine — or alternatively set up a NFS root for simplicity as described in Geoff Levand's HOWTO. To boot the kernel, you should know that the PS3 uses the kboot boot loader, a minimal Linux system that chainloads another Linux system by means of the kexec functionality. It is very powerful, but the documentation is scarce. Your best bet is to mimic the entries already present in the file. With this in mind, I added the following line to /etc/kboot.conf: jmerino='/dev/sda1:/vmlinux-jmerino root=/dev/sda2 init=/sbin/init 4' I'd much rather fetch the kernel from a TFTP server, but I have not got this to work yet. Anyway, note that the above line does not specify an initrd image, although all the other entries in the file do. I did this on purpose: the less magic in the boot, the better. However, bypassing the initrd results in a failed boot with: Warning: Unable to open an initial console. This is because the /dev directory on the root partition is unpopulated, as YDL5 uses udev. Hence the need for an initrd image. Getting a workaround for this is trivial though: just create the minimum necessary devices on the disk — "below udev" —, as shown below. # mount --bind / /mnt # MAKEDEV -d /mnt/dev console zero null # umount /mnt And that's it! Your new, fresh and custom kernel is ready to be executed. Reboot the PS3, wait for the kboot prompt and type your configuration name (jmerino in my case). If all goes fine, the kernel should boot and then start userland initialization. Thanks go to the guys at the cbe-oss-dev mailing list for helping me in building the kernel and solving the missing console problem. Update (23:01): Added a link to a NFS-root tutorial.
March 16, 2007
·
Tags:
<a href="/tags/linux">linux</a>, <a href="/tags/pfc">pfc</a>, <a href="/tags/ps3">ps3</a>, <a href="/tags/yellowdog">yellowdog</a>
Continue reading (about
5 minutes)
The Linux kernel, when built for a Cell-based platform, provides the spufs pseudo-file system that allows userland applications to interact with the Synergistic Processing Engines (SPEs). However, this interface is too low-level to be useful for application-level programs and hence another level of abstraction is provided over it through the libspe library. There are two versions of the libspe: 1.x: Distributed as part of the Cell SDK 2.0, is the most widely used nowadays by applications designed to run on the Cell architecture.2.x: A rewrite of the library that provides a better and cleaner interface — e.g. less black boxes —, but which is currently distributed for evaluation and testing purposes. Further development will happen on this version, so I needed to have it available. The YellowDog Linux 5.0 (YDL5) distribution for the PlayStation 3 only provides an SRPM package for the 1.x version, but there is no support for 2.x. Fortunately, installing the libspe2 is trivial if you use the appropriate binary packages provided by BSC, but things get interesting if you try to build it from sources. As I need to inspect its code and do some changes in it, I have to be able to rebuild its code, so I had to go with the latter option. Let's see how to build and install libspe2 from sources on a PS3 running YDL5. The first step is to download the most up-to-date SRPM package for the libspe2, which at the time of this writing was libspe2-2.0.1-1.src.rpm. Once downloaded, install it on the system: # rpm -i libspe2-2.0.1-1.src.rpm The above command leaves the original source tarball, any necessary patches and the spec file all properly laid out inside the /usr/src/yellowdog hierarchy. Now, before we can build the libspe2 package, we need to fulfill two requisites. The first is the installation of quilt (for which no binary package exists in the YDL5 repositories), a required tool in libspe2's build process. The second is the updating of bash to a newer version, as the one distributed in YDL5 has a quoting bug that prevents quilt from being built properly. The easiest way to solve these problems is to look for the corresponding SRPM packages for quilt and an updated bash. As YDL5 is based on Fedora Core, a safe bet is to fetch the necessary files from the Fedora Core 6 (FC6) repositories; these were: quilt-0.46-1.fc6.src.rpm and bash-3.1-16.1.src.rpm. After that, proceed with their installation as shown above for libspe2 (using rpm -i). With all the sources in place, it is time to build and install them in the right order. Luckily the FC6 SRPMs we need work fine in YDL5, but this might not be true for other packages. Here is what to do: # cd /usr/src/yellowdog/SRPMS # rpmbuild -ba --target=ppc bash.spec # rpm -U ../RPMS/ppc/bash-3.1-16.1.ppc.rpm # rpmbuild -ba --target=ppc quilt.spec # rpm -i ../RPMS/ppc/quilt-0.46-1.ppc.rpm # rpmbuild -ba libspe2.spec # rpm -i ../RPMS/ppc64/libspe2-2.0.1-1.ppc64.rpm # rpm -i ../RPMS/ppc64/libspe2-devel-2.0.1-1.ppc64.rpm And that's it! libspe2 is now installed and ready to be used. Of course, with the build requisites in place, you compile libspe2 in your home directory for testing purposes by using the tar.gz package instead of the SRPM. At last, complete the installation by adding the elfspe2-2.0.1-1.ppc.rpm package to the mix.
March 14, 2007
·
Tags:
<a href="/tags/cell">cell</a>, <a href="/tags/pfc">pfc</a>, <a href="/tags/ps3">ps3</a>, <a href="/tags/yellowdog">yellowdog</a>
Continue reading (about
3 minutes)