Over the last month, I've been poking around OpenMoko. The real reason was because toolz had a prototype phone with him. But the real reason I got anything done on the platform is because of the software emulation mode, with qemu-arm. The openmoko wiki has a fair bit of detail on running under QEMU - but if you just want pre-packaged ready to run QEMU images, take a look at jebba's pre-built images. All I've added to that is the qemu tun-tap network adapter ( -net nic -net tap ) so that I can scp stuff in & out of the phone image. Here's how the applications actually look on the emulator phone (it is *very* CPU heavy - if you have a Core2Duo or something, this would be a nice time to take a look at man taskset(1))
pnet on moko: Back in 2005, krokas had built the OE based packages for pnet. So essentially, building pnet ipks for OpenMoko is no different from building it for any other OE platform, especially because pnet hsa nearly no dependencies on anything beyong libc and libX11.
But the register asm() trick pnet uses to ensure that values like program counter and frame pointer are stored in the correct registers does not work on arm gcc-4.1.1. Aleksey has implemented a couple of solutions like the __asm__ barriers. But as of now, the engine is running in pure interpreter mode, which is not fast enough.
The emulator mode is pretty decent - even with the stock qemu-arm. If my interest keeps up, I'll probably try the OpenMoko patched qemu. I did build the whole toolchain and rootfs from scratch with MokoMakefile - but monotone is really painful to set up and the entire build takes a whopping 14 gigs of space on my disk. So if you're thinking of playing around with moko, don't try that first up :)
--Telephone, n.:
An invention of the devil which abrogates some of the advantages of making a disagreeable person keep his distance.
-- Ambrose Bierce
Recently AfC wrote a HOW post on linux & open source, but the question I'm more often asked is WHY.
Most of the content in this entry comes from the similarly titled GNUnify 2006 BoF session with inputs from spo0nman, premshree, lunatech, pradeepto, G0SUB and the students at the conf. And it attacks the topic from the other side of the problem - what more does a F/OSS programmer bring to the table at a job than the other guy.
Not Technical Talent: For a long time, I had assumed that it was the proven technical competency which has been tested in the real world. But in the recent past, I've met enough technically adept folks from both sides of the divide to take that assumption to peices. People from the proprietary code land are equally capable and just because your code is open does not make it any better by default. Having your code out in the open does make it easier to judge your ability for a third party - but that'd be end of this blog entry if a programmer was merely a code producing machine.Co-operation: The transition from college to the workplace is rather jarring. Having spent the last fifteen-odd years in constant competition with your peers, suddenly you are thrown into a world where you need to co-operate with, rather than screw over, the next guy. Most people who work in a successful open source project with multiple contributors have gotten past that particular hurdle much more earlier and the transition into a workplace where the focus is on getting things done rather than merely doing your own part is much more easier.
You got Bugs ! (and users): I've often been shocked by the way people deal with bugs and criticism. The immediate 'full power to shields' reaction is probably understandable, but rather unpleasant. But for someone who has worked with other people in a serious project, criticism from your peers is easier to handle or at least something they have handled in the past (or you'd think so). Also bugs from end users gives a developer some level of user focus which is totally absent in the college graduate. Seeing the user and his problems as one of the factors while coding is hard to acquire if you've written code for a college professor to run once.
Communication Skills: Most f/oss teams are spread across the world. Their communication happens mostly through filtered channels such as mailing lists, irc or bugzilla. It does take some effort to involve yourself in such a global environment when communication can be easily misinterpreted for tone and context. Working in such an environment easily carries across into the modern world of distributed development required for global product development.
Consensus: Have you ever been in a technical argument at work ? There are always people who have a hard time accepting someone else's point. If you've worked on a real peice of code long enough with a group, you've had one of these hard-to-swallow decisions to deal with. It does come as a nasty surprise to most graduates out of college when they run into one of those. Having gone through the standard sulk phase for the first few such run-ins, most f/oss developers are more understanding and less obnoxious about accepting someone else's idea.
Oh the humanity !: Somehow, getting involved with a project, working with different people and enjoying the experience does result in a more rounded work persona. The whole community effect can easily seperate the assholes from the good guys as easily as it seperates the men from the boys (uh... women from the girls too). In general, it also selects for a person of the community rather than the brilliant loner and most employers prefer the former.
There are many more qualities which are quintessential to the f/oss hacker ethos - passion, commitment and plain old curiosity. But they are not unique to the group - anybody who has run into a mac fanboi would agree on the passion part at least :)
I'm by no means the first guy to say that F/OSS hackers are better hires - virtual referral and loudthinking do reinforce my conclusion - but someone needs to tell the students.
--Yacc owes much to a most stimulating collection of users. Their irritating unwillingness to learn how to
do things my way has usually led to my doing things their way; most of the time, they have been right.
-- S.C Johnson.