You may remember that I’ve had my eye on the Openmoko phones since early 2007, but in between shifting across the world and starting a new job I never got around to purchasing one of the first versions. The second version, the “Freerunner”, was released in June this year and I placed an order with Pulster, a local distributor, shortly after. The phones have been in hot demand, so I only received my phone last week, a wait of of almost 2 months, and it turned up missing one of the cables that was meant to come with it. Still some distribution kinks to be worked out.

Distribution kinks are the least of Openmoko’s worries at the moment though. As advertised, the phone is definitely not ready for primetime distribution yet. I’ve tried three different software images on it: the original “stable” 2007.2 image, the current “devel” 2008.8 image and the latest completely rebuilt SHR release which is the most promising yet. With the SHR image I’ve been able to send and receive calls and text messages, although the interface is somewhat arcane. I’m most interested in the GPS which looks to be working reasonably well at this stage.

After almost a week with the phone I’m glad I purchased it, and I’m having fun hacking on it, but there is a huge way to go before I’ll be able to use it as my primary phone. So that’s gadget #1.

The second gadget is a new Digital SLR camera. I’ve been thinking about getting back into photography for a while (I last took photos seriously in high school) and when I saw how affordable digital SLRs had become I couldn’t resist. There isn’t much between Canon and Nikon when comparing mid-range SLRs these days, so after about a week of deliberation I decided on the Canon 450D, primarily because most of my workmates also have Canon SLRs!

I only got the camera on Friday, and spent half the weekend playing with the GPS on the phone (I want to set them up so I can geo tag all my photos), so I haven’t had quite as much time to play with it yet. I expect to spend plenty of quality time with it on our holiday in Malta next week. First impressions are favourable, although I’m fast discovering camera viewfinders were not really designed for people who wear glasses. I may have to consider wearing contacts again.

Once we get back from Malta I’d like to find a local (or online) photography club with some good weekly assignments to fire my creativity and motivate me to get the most out of my new toy.


matt@krypton:~$ dpkg -s flashplugin-nonfree | grep Version
Version: 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2


Granted this package is in hardy-backports not hardy proper, but still, what on earth?!?!

The report seems to be aimed at demonstrating to Government and Businesses that Open Source has become a very viable business strategy in Australia and in particular how increased adoption of Open Source would reduce the Australian trade deficit. You don’t need to worry about being put to sleep. The report is relatively casual in tone and easy to read with lots of bright graphs to present the key statistics and findings. Including:

• The Australian Open Source industry generates around AUD$500M in annual revenue. A small proportion of the AUD$54.4B total revenue for the Australian ICT Industry in 2004-2005. Lots of growth potential!
• 70-80% of the industry is based on the traditional development, customisation, support and maintenance business model.
• Most of the individuals making up the Australian Open Source community are working professionals, over half the community are in a relationship and a third of the community have children.

It would be fascinating to see a similar study of the New Zealand industry. I suspect that we would find that Open Source businesses are spread across the country similar to Australia. Obviously our community and financial figures would be smaller in absolute terms but would our proportion of Open Source based businesses be similar?

Maybe a good task for the current NZOSS committee would be to round up some of the larger Open Source businesses in New Zealand, along with the Ministry of Economic Development to sponsor a similar study for New Zealand!

• Auckland - January and February
• Dublin - February, photos
• Hamilton - March
• Miri - April, photos
• Sarikei - April, photos
• Kuching - April, photos
• Kota Kinabalu - April, photos
• Singapore - April, photos
• Dubai - April
• London - April, photos
• Dublin - May onwards, photos
• Galway - June
• Cork - June, photos
• New York - July, photos
• Cambridge - July, photos
• Belfast - August, photos
• Luxembourg - September, photos
• Paris - November, photos
• Whistler - November, photos
• San Francisco - November/December, photos
• Bratislava - December, photos
• Bad Gastein - December, photos
• Salzburg - December, photos
• Vienna - December, photos

18 cities, 5 towns/villages and a total of approximately 101,216km travelled in the air!

Essentially I want to delegate ‘root’ access for a portion of the filesystem to a particular group.

My first attempt at implementing this was to use the standard POSIX ACLs that are available for almost every filesystem Linux supports.

I recursively set an ACL on the top-level directory to give the group write access to all files and directories that currently exist and then I recursively set a default ACL to give the group write access on all the directories. This default ACL should be inherited by any new files that are created ensuring that the group keeps write access to everything.

Problem solved? Unfortunately not.

The intricacies of complying with POSIX means that ACLs are implemented as an ACL plus a mask. To gain access to a particular file or directory the user or group must match an appropriate ACL granting the access and the mask for that file or directory must also allow the requested permission to be granted.

When you add an ACL to a file or directory, the ‘group’ bits of the standard Unix permissions magically switch from controlling group access to controlling the mask portion of the ACL, effectively providing an upper bound on the permissions that an ACL entry can grant. This prevents legacy POSIX applications that do not understand ACLs from unintentionally granting excessive permissions - arguably a good thing.

Unfortunately this also makes it very hard to preserve the ACL granting write access to the ‘root’ group which I legitimately intended to have in place on this portion of the filesystem.

Newly created files under the hierarchy generally inherit the ACL as intended, as most applications attempt to create files with as many permissions as possible, leaving it up to the umask to remove undesired permissions.

However any file that is copied into the hierarchy without the ‘group’ write bit set, or any file that has the ‘group’ write bit removed via chmod will actually remove the write bit from the ACL mask invalidating the ACL and leaving me back at square one!

After a bit of Googling I thought that NFSv4 ACLs might be the answer to this problem, as they are marketed as “very similar to Windows ACLs” and I’m sure that I vaugely recall Windows being able to properly inherit ACLs from parent directories. Unfortunately after downloading the NFSv4 ACL patches and trying all the various mount options I cannot find any combination that will offer the functionality I need. The implementation conforms to POSIX, so it still has a mask parameter and the same problems as the standard POSIX ACLs. The only benefit from using NFSv4 ACLs that I can see is that you have more permissions to grant.

So once again, I’m back to square one. I’m hoping that there is some fundamental point that I’m missing as this seems like a very common use-case that I would have thought would be well supported.

If a command-line example is clearer to you look at:
http://www.mattb.net.nz/blog/dump/acl-inheritance-problems.txt

My current solution is to run a cronjob every X minutes to recursively ‘chmod -R g+w /dir’, however that’s far from optimal as it exposes all sorts of race conditions and just seems ugly!

Any suggestions or solutions will be gratefully received.