With kernel development the approach is much more to make sure that the core can cope with whatever needs expressing. It’s not always done in the core – for example, sometimes the issue is due to unusually limited hardware and very likely to never come up again – but it’s very unusual to see code merged that doesn’t at least fit in with the design of the subsystem.

This post is inspired by a brief exchange with Thomas Gleixner on linux-kernel who articulated the advantages of doing things this way very well:

 - It's usually simpler and faster as the core code has all the
   necessary information. So that's even an argument which managers
   might understand.

 - Such workarounds, when not caught, tend to spread themself
   magically because driver writers checkout the existing code of
   similar devices and copy/paste/modify^Wuglify them over and over.

 - In the worst case such workarounds make the core maintainence
   harder and in some cases impossible, because they silently imply
   semantics on the core w/o the core maintainer knowing about them.

The last point is the most important one to me as a subsystem maintainer – I really don’t want to be merging code that is going to create issues with ongoing development of the subsystem. This is all another facet of the policy on stable APIs: APIs are only worth working around if they’re fixed, and the assumptions that end up embedded in a workaroud are as much part of the API as the explicit interfaces.

It’s things like this that make Linux such a pleasure to work on.

One of the most interesting decisions I’ve noticed is the model that things have for handling network I/O. At one end of the scale you’ve got iPhone OS which does very little network I/O off-line – it will fetch mail in the background and there’s MobileMe sync but that’s about it. Everything else is triggered by direct user action and is generally visible to them. Even with the mail there’s an element of interactivity – it will notify the user about mail before it’s actually been downloaded, for example. At the other end of the scale the Blackberry does its level best to mask the existence of the network – any updates go on in the background, with the fact that there’s any interaction with a remote system being hidden everywhere except with things like unsent messages. Both these are reasonable choices.

The iPhone model flows from the same place as the decision not to allow background apps, trading interactive performance and a degree of usability (especially where the network is slow or intermittent) for a tight control on things that incur power and bandwidth costs. This avoids surprises, especially given the number of third party apps out there, ensuring that the system always behaves as expected.

The Blackberry avoids the user being troubled by the vagaries of spotty connectivity but also means resources get consumed without user interaction, which can impact performance all round without it being clear to users what the device has been spending resources on. Then again, it’s much less common to use anything except the standard application set on a Blackberry and that is highly optimized for its function – there’s less to be worried about.

I’m not sure I’d say either approach is better – they’re not solving quite the same problem and they’re certainly part of very different systems – so it’s interesting to consider the differences. Personally I find waiting for the network annoying, but then I’m a pretty technical user so the drawbacks in terms of understanding power consumption aren’t so important for me as they will be for many other users.

Where it falls down is in the music player. One problem is that the controls aren’t consistently in the same place and have no tactile feedback. Worse, unlocking the device when the controls have been idle for a while requires a relatively complex operation (either a treble click of the home button or swiping a software unlock control across the breadth of the screen). This means that if using the Touch isn’t your sole focus, for example when listening to it in the gym or walking around town, it is intrusive to use, demanding too much attention. Even for basic operations like pausing or changing the volume you need to look at it to find out what controls are available and where they are.

It’s an interesting direction for user interfaces but I don’t think it works for a device that should be unintrusive.