Munckfish.net

I am relatively new to the Ubuntu PS3 Port team. I joined about a month before Hardy was released when I was told by Gouki that there really wasn’t any development happening on it because it was a community maintained port just like the PowerPC port now is too. I just felt I had to do something - Ubuntu on the PlayStation3 is just too compelling for me to sit back and watch it bit-rot!

One of the first things that needed doing was to update the bootloader (otheros.bld) as the old Gutsy one wasn’t able to boot Hardy’s kernel. Once this was achieved (thanks to some great mentoring by a very busy Colin Watson and others) I was able to upgrade to Hardy and start fire-fighting.

Unfortunately we weren’t able to fix things in time for Hardy’s first release. X was crashing and trying to choose the wrong video driver (both now fixed), and the Kernel (still) has a memory allocation problem (fix on the way). There are various other problems waiting to be resolved, and a few suggested features too, but we’ll get to them all in good time.

Although initially the plan was to try and have an installable/usable Hardy by 8.04.1 in July, I think focus will probably be on Intrepid from now on. Getting fixes back into critical components such as the kernel and X for Hardy in time would be tough as this is considered an “unmaintained port” in Hardy.

So far working on this project has been a great experience for me. I am gaining a very broad knowledge of all aspects of how Ubuntu works, and also how Linux works on the PS3. I highly recommend any folks who are using Ubuntu on PS3 and have Debian/Ubuntu dev experience please jump on the development mailing list and look out for ways to contribute.

A status update has just been posted to the dev list today. I’ve tried to outline as best as I can the current state of the project.

Thanks to everyone upstream, downstream (ubuntu-ps3-dev, ubuntu-x, kernel-team), and in the community who has helped out so far!

I have now got Ubuntu installed on my PS3. This is very cool! The potential of no longer having to have a desktop computer sat in the corner taking up space is fantastic. Instead I have a mini super computer in a small beautifully styled consumer device’s clothing connected to a widescreen TV as a monitor. Woo-hoo!

I followed the instructions on PSUbuntu.com to install the port of 7.10 Gutsy Gibbon. The instructions are good but this is very early days for Linux on PS3; naturally there’s plenty of work still to do to smooth over the user experience. The Ubuntu builds for PS3 are maintained voluntarily by literally only 2 or 3 guys at Canonical, so it’s impressive it works as well as it does.

Setting up the screen resolution didn’t work quite as described - stopping gdm (the Gnome Display Manager) and setting the screen mode only changes the resolution for the current terminal not for the one which Xorg starts in, and if you specify a non-compatible mode your display may be a mess so you have to type blind to fix it (or better use the up/down cursor keys to access a previous working mode using shell history). Not a big deal for a techy but obviously could be quite a hurdle for your average punter. Anyway once the correct mode has been found setting up a script under /etc/event.d/ ensures it always boots into the desired mode.

Second issue was that the OS didn’t seem to be finding the ethernet network card. Luckily browsing the PSUbuntu Networking and Connectivity forum revealed the solution - disable NetworkManager and configure the network settings manually using the Gnome Network tool (or by editing /etc/network/interfaces directly if you know how). Seems NetworkManager doesn’t work quite right with the PS3 ethernet card yet.

Having got it up and running the next task was to choose a lighter desktop system than Gnome. I love Gnome but there’s only 256MB of RAM on the PS3 and the Gnome desktop on it’s own uses most of that so applications are likely to be swapped out to disk way to too quickly for my liking. There are some interesting instructions on the PSUbuntu forum which suggest all sorts of things like disabling the graphical login screen (gdm) and changing to use the Fluxbox window manager instead of the default Metacity, but I felt I wanted something less custom and more complete so I decided to install the Xfce desktop.

Xfce is the base of the XUbuntu distribution and is a lightweight Gtk based desktop system with its own window manager. It has some slick themes and also supports pretty features like transparency and drop shadows (using Xorg’s Composite extension). You can choose to install the entire XUbuntu default installation by installing the xubuntu-desktop package from Synaptic, but this will pull in all sorts of other peripheral tools such as the Abiword office suite. I didn’t need this stuff so I opted to install just the Xfce components by installing the xfce4 package.

Of course one thing which I want to take advantage of is the chance to experiment programming the amazing Cell Microprocessor. Included in the package repositories are the required development libraries and tools. Just search for the keyword ‘cell’ in Synaptic to find the relevant packages. There’s also a packaged copy of the Cell Programming Primer from kernel.org.

Flicking through the menus on a Panasonic Viera 32″ LCD I discovered a “Software Licence” link in the setup menu. Amazingly this links to a full copy of the GPL and a link to am-linux.jp. Seems it runs Linux!

I upgraded my desktop machine to Gutsy today to have a play with it before upgrading my laptop. I’m really glad I did it in this order as it appears there may be a regression in the version of Java 6 shipping on Gutsy.

I happened to test out a Java game which uses Full Screen Exclusive Mode with a DisplayMode of 800×600. So far this app has been working ok on Feisty but when I tested it today on Gutsy it couldn’t change display mode. I discovered that Java was only able to see the current screen mode of 1280×1024 and no others.

I’ve opened a bug on Launchpad here: #154613: Java cannot change display modes / screen resolution in Gutsy, and I’ve been digging in trying to work out what’s going wrong.

I managed to locate the JNI function call in Java’s native C source code where it gets the list of modes. It’s called Java_sun_awt_X11GraphicsDevice_enumDisplayModes(...) and is in the file j2se/src/solaris/native/sun/awt/awt_GraphicsEnv.c. As expected the Ubuntu packages are built from the Sun Linux binaries - no source code. I couldn’t find the Java 6 source on Sun’s site, the link appears to be wrong. Instead I found the file in the Icedtea/OpenJDK source tree. Icedtea on Gutsy has the same problem so I’m fairly happy this is the the same or roughly the same code as in Java 6.

The function makes use of the XRandr Xorg extension to query the available display modes. I coded up a small test to see if XRandr was behaving correctly. It is, on both Gutsy and Feisty. So it looks like it could be something in Java 6 u3.

Will keep digging, as I really need this to work.

Bryce Harrington (an Ubuntu Developer) has created an article demonstrating the new BulletProofX feature which will be included in the upcoming 7.10 (Gutsy) release of the OS: BulletProofX

It’s fantastic to see this finally implemented, Graphics Card and Screen issues, in my experience, have been the most visible deficiency of the Linux distros compared with other operating systems.

Here’s some more background on this feature and the X server from the Ubuntu Fridge:  10 Rocking Features in 10 Days: Day 2: Bulletproof X and Graphical X configuration

I just heard today that RM will be selling a tiny Asus laptop pre-installed with Linux. It’s a very small machine 22.5 x 16.5 x 2.1-3.5cm and will cost only £169.

Instead of a hard drive it will use solid state memory apparently either 2GB or 4GB. Anecdotal evidence from the comments on this page, suggest it will be running a version of Suse Linux.

This is more great news for Linux as it shows that there is a growing confidence that it is a viable alternative to Windows and Mac. We already have Dell introducing Ubuntu pre-installed machines into for the European market. RM are a big supplier of IT hardware and services into schools and this laptop will probably be targeted directly at the education market. Lets hope we see more and more of the education market share heading towards Linux (and Mac) so there’s a more level playing field and kids don’t grow up thinking that computers and Windows are the same thing.

Update: Here’s the link to the product description page on the RM site - RM Asus miniBook. I notice in the features page the operating system is described as an “Asus developed Linux based operating system”. A little Googling turns up a story on Slashdot from from last Sunday mentioning about an ASUS motherboard called the P5E3 Deluxe/WiFi-AP@n that includes an embedded Linux OS called Splashtop which boots from the BIOS on the motherboard and allows you to use Firefox+Flash, and Skype in under 5 seconds from pressing ‘Power On’. The Splashtop site has a decent FAQ, and even a blog-post with a YouTube vid demostrating the OS. I’m not sure this is definitely the exact technologies the RM machine is using because Splashtop is developed by DeviceVM not Asus. The RM machine is basically a rebranded Asus Eee PC. The Eee PC site doesn’t give specific detail on the version of Linux it uses but it’s support page does link to Xandros Linux.

I’ve just read over the Gnome 2.20 Release Notes and I must say I’m looking forward to using it in Ubuntu 7.10 (Gutsy). There are quite a few small improvements that I’ve been waiting for. For instance:

• Finally the Evolution mail client has an icon for the Gnome Panel’s Notification Area, I hope it supports minimizing of Evolution too (without leaving behind the task bar button).
• Evolution now has a built-in backup utility to help export and move settings to another machine.
• The properties dialog for a mounted disk now shows a disk-usage pie chart - very useful.
• One neat feature is that if you lock your screen and go away someone can leave you a message to read once you return (no more sticky post-its stuck to your screen).
• Automatic unlocking of the Gnome Keyring (Password Manager) when you login or unlock your screen.

However, the thing I am most happy to see is the new Gnome Library documentation site. This is a very polished site collecting together Gnome related tutorials, manuals, and API references. I think this is a great step forward for the Gnome project; I have felt in the past the resources were not as well presented or well maintained as they could be, particularly developer docs on subjects such as Gtk and Glib.

Came across an excellent JavaOne conference session on software packaging for Ubuntu/Debian. It has a specific focus on packaging Java software but I found it gave an excellent general insight into the process of getting a piece of software, commercial or free, into the Ubuntu repositories. The main example used was the experience of the Sun engineer Harpreet Singh who was responsible for packaging the Glassfish application server which is now available in the Ubuntu multiverse repository.

Here’s the link, you will need a Sun Online account to access the talk:

JavaOne Technical Sessions - Packaging Java Platform Applications into Ubuntu

I’ve been studying shell scripting in more depth recently. Here’s some of the things I found useful on the way.

1) Write your scripts to run on a real POSIX / Bourne Shell compatible sh interpreter first rather than bash or any of the other advanced shells. This improves the portability of your scripts and helps you to clearly learn the differences between the basic shell syntax and the advanced syntax introduced in shells such as bash.

On most Linux systems in recent years /bin/sh is a symlink to bash which has allowed people to ‘leak’ bash syntax in without error. Scripts like this only fail when run on a system that’s using a strict sh like on the FreeBSD or Ubuntu Feisty where /bin/sh is symlinked to ‘dash’ - The Debian Almquist Shell, which is a “lightweight POSIX compliant Bourne shell implementation”. IMO this is a better way to internalize the differences between sh and bash than using tools like ‘checkbashisms’ after you’ve created your script.

Firstly always specify ‘/bin/sh’ in the ’shebang’ line at the top of your scripts:

To see what your /bin/sh is linked to try this:

You’ll see that on my system (Ubuntu Feisty) the output at the end of the ls command is ‘/bin/sh -> dash’ which indicates that /bin/sh is linked (->) to dash. If on your system it links to bash do not try to link sh to anything else! If you do you may not be able to boot your system! Instead install the ‘ash’ or ‘dash’ shells and run you script in those directly like this:

2) Bookmark and read these reference manuals:

• Bourne Shell Manual - Steve Parker’s html version of the original Bourne Shell manual great to check exactly what syntax is available in the real Bourne Shell.
• Advanced Bash-Scripting Guide - The best tutorial on bash with loads of practical examples. The section on ‘tests’ (conditional logic) is particularly good.
• Bash Reference Manual - The actual bash manual. It can be a little difficult to find things in this sometimes so it’s worth getting used to its structure

3) Use shell options to help you debug problems. You can do this either by using the ’set’ command (in bash type ‘help set’ to see usage or ‘man sh’ to view the man page) in your script or by passing the option on the command line as you run your script e.g.

Here are the options I find most useful:

• -x Prints commands and their arguments as they are executed
• -u Treat unset variables as an error when substituting
• -e Exit immediately if a command exits with a non-zero status. Note this should be used with caution as there will be no warning when ths happens, you need to use -x to help discover where the problem is happening

There are loads so it’s worth looking through the list.

4) Use bash to discover syntax errors not highlighted by sh. If you script is failing silently in sh it can sometimes be due to a syntax error. On my system dash isn’t reporting these but I’ve found that explicitly running the script in bash often helps locate the cause of the problem.

5) Consider portability. If you know your script is going to be used across many different systems then it’s worth making sure you are only using commands available in the POSIX standard or on Linux now we can use the ones defined in the Linux Standards Base. See LSB Base - Commands and Utilities for more information.