Android... is it Linux ?

This i just something that I saw on LWN (from Harald Welte) and felt needed a little more visibility here at maemo.

The presentation shows how Google has simply thrown 5-10 years of Linux userspace evolution into the trashcan and re-implemented it partially for no reason. Things like hard-coded device lists/permissions in object code rather than config files, the lack of support for hot-plugging devices (udev), the lack of kernel headers. A libc that throws away System V IPC that every unix/Linux software developer takes for granted. The lack of complete POSIX threads. I could continue this list, but hey, you should read those slides. now!

 The slides

As usual the commentary at LWN raises some interesting counters.

Ovi Maps... Really? Is this the best we can do?

I got caught in a nasty traffic jam tonight just a few miles from home.

There was a road that I've never been down - windy country lanes, right general direction...

I grin and whip out my N900 and give it to my wife to navigate us - just the ticket?

No.

An hour later we've been lost several times, argued and are generally very annoyed and unhappy. My wife thinks that *I* think she's stupid 'cos she can't use a map application. She hates that. I hate that.

The maps UI sucks. It is unusable to a novice. The GPS seems to update randomly every 10 mins or so. It blocks the screen with messages. It tries to connect to GPRS when there's no signal (and clearly no need). Mostly it just completely fails to meet its purpose.

As we hit a road we recognised I realised that I was so pissed off with this experience that if I were a consumer who'd paid retail for this device I would want my money back - and as someone who has breathed Maemo for almost a year now, that makes me very, very sad.

Maemo Security - Lockdown or Liberation?

At the Maemo2009 Summit Nokia shared a great deal of information about the security mechanisms that would be available and/or mandated in upcoming platforms.

The concepts outlined include well established favourites in the OSS world (like privilege management) as well as some that are rather less well regarded - such as relatives of the Trusted Computing Platform and DRM.

Inevitably there will be a significant amount of interest and concern about how this affects the open nature of the Maemo platform.

I'd like to highlight that there is a specific boot-path designed in to allow a community kernel to be booted with, as far as I could tell, no loss of functionality other than access to DRM content. That's amazingly positive.

For what it's worth I will say that I was massively sceptical as soon as I saw "Trusted Computing" and "DRM"; however after listening and thinking about it I came to the conclusion that this solution could be a huge benefit to the OSS community. Certainly Nokia can abuse it - but that's not the point. The point is do we - and should we - trust them.

We certainly need more security. Right now when I download an application from Extras-Devel it can do anything to my device; on an N800 that's not so bad - on an N900 that can incur significant cost and could conceivably (and almost trivially) be used to perpetrate fraud. I'd like to be able to say "no, scrabble game, you can't access my contacts data or make phonecalls - what on earth do you need to do that for?" An open security infrastructure would make me feel a whole lot more comfortable.

As a starting point to a rational response I think a sensible thing to do is to brainstorm the key questions we need to ask Nokia in order to gather the data needed to come to a conclusion.

The presentation was a great start - as was Elena's offer to continue the discussion on the mailing lists and respond to our queries and concerns (Thanks Elena).

So,I have started a Maemo Security page on the wiki which I hope can capture community questions (and, eventually I hope, Nokia's answers) about these issues.

The first questions are draft (I just landed and I'm tired!) to get people thinking. Certainly I want to re-watch Elena's presentation video several times before going much further.

I suggest we initially add questions to the  Maemo Security discussion page and  and once they've been refined and consolidated, we'll add them onto the main page.Obviously discussion needs to happen on talk, email and irc too.

I'll wrap up with a plea - please don't over-react  - jumping to conclusions and misleading the rest of the OSS community before we know the facts can only hurt what has so far been the most amazingly open phone device I could have dreamt of!

PS The Summit was brilliant!

Important Summit Announcement

Well, it's important if you arrive for the Summit on Thursday and want to meet up for a beer (or, if Copenhagen was anything to go by... an ice-cream) in the evening.

More details here:
  http://wiki.maemo.org/Maemo_Summit_2009/Schedule

Meet up at 19:00 (so after early registration closes).

There will be free beer available













if someone offers to buy it ;)

Want to PUSH... need a kickstart?

So one problem with the PUSH is that it's a bit tough for us software nerds to get into the real world. What would be cool is a nice easy "apt-get install HARDWARE" ... interested? read on...

A few years ago I bought a couple of these boards for about £25.

They provide:

• 5 digital input channels
• 8 digital output channels
• 2 analogue inputs
• 2 analogue outputs (8 bit resolution)
  

You can also have up to 4 of these plugged in via a usb hub.

So, I thought... how hard can it be... and actually it is quite easy. The source is on sourceforge and I'm packaging it so you can pull libvelleman from garage, plug in a board and PUSH :)


As you can see the test program implements K.I.T.T. for you...




So now all we need is someone with an N900 to help me test it...

(Warning: Don't get your hopes up - it appears that the N900 can't (yet?) act as a normal USB host; so no plugging in printers....)

The Summit: Git/Gitorious - Untracked talks: consider adding them...

I proposed a talk at the summit on DVCS and git and it has not been accepted (or rejected) by the talk selection group. This isn't a complaint  :)     . . . . .   however I do worry that it might worth pushing ... what do you think? (Breaking news... sounds like there has been an acceptance - also it may make sense to do a BOF session after any presentations). I still would appreciate feedback - what' important to you?

This message is just to solicit opinions and hopefully will validate their decision. If it causes a rethink then that's fine too.

Heh - I could do without the extra work involved!!

I personally thing think that as a development community with git on garage and gitorious.org we should be making efforts to understand how best to use DVCS processes to collaborate.

Maybe it's just me but I see a lot of devs who are new to DVCS and very few community guidelines on how to use DVCS. Qt uses it but, as we've recently been discussing, it could be going better.

Frankly I don't care which 'good practice' I use - I can go out and find lots of them. But it strikes me that as a community we should at least say "hey, quite a few of us are using this approach - if you don't have any strong preferences then you can use it too"

So why now?

Well, real soon now (I hope) we're going to have 3 different versions to support.

• Fremantle
• Diablo
• Mer

They'll each have different capabilities and some apps just won't care - they'll support Fremantle or Diablo and ignore the others. That's fine.
(Although being open-source you might find patches being sent in to add support for another flavour - how will you cope? Wouldn't you like some help in doing the boring stuff?)

Other apps will decide to embrace that diversity from the start.

So how do we (you) manage the build-variations (ie debian/* may well vary for each of them. Maybe ./configure too)? Do we use branches? How?

Now how do we manage adding features and back-porting simple bug fixes to the stable release whilst you work on that big new feature set.

How are contributions and teams handled?

It sounds horrendous - and it can be!


But actually this is all fairly simple stuff with DVCS once you have it explained and once you grok it - but it's bloody hard to figure out from scratch and it's also very unlikely that you'll arrive at the same solution as another team.

Which means if you're a member of multiple teams you might find they each have different approaches - "whoo hoo!" - not!

So anyway... I thought a talk would be a good idea.

Now at the time no-one had volunteered so I did - some of you may have noticed my name at the bottom of:
  http://www.kernel.org/pub/software/scm/git/docs/git.html
(yes, I'm proud of that contribution)

Now you may think that qualifies me to offer this talk - you'd be wrong ;)

I was hanging around the kernel lists at the time, got interested and acted as an 'editor' pulling together words of wisdom. Since then I've used git a little but it wasn't until we started to need it in Mer that I reviewed the state-of-play and tried to pull in other people's good ideas - so that's what I'd use as a base.

However we also have Johan Sørensen who wrote Gitorious.org - I think having him speak on using git and gitorious would be an opportunity that we shouldn't miss.

Equally there must be developers in Nokia/Trolltech who could say "we know this stuff and this is how we think you might want to do it."

So... speak now...

PS If anyone fancies collaborating and doing a multi-person presentation then I'm up for it.

GrandCentral for Mer... connecting the components

First, I'm sorry but this isn't an N900 post :) instead I've been looking at one of the areas that's holding back Mer. It's fairly simple conceptually: just handling interaction between various parts of the system; and by this I mean things like screen dimming; what happens when you press the power key; shutting down when the battery is low; waking up for an alarm... Things that should just work.  Well, I think I have a potential solution. (Oh, and some of you may be interested... I also found out how far eclipse has come in the UML modelling space too!)

Currently this is handled by powerlaunch; it is really not a bad bit of code and does most of its job well.

Sadly it really sucks at being configurable!

Here's a snippet:
global_key_press_power = timer_set _key_power_long $powerkey_longdelay; timer_set _key_power_medium $powerkey_mediumdelay; set powerkey_short 1; call _key_press_power_short
global_key_release_power = timer_cancel _key_power_long; timer_cancel _key_power_medium; if $powerkey_short _key_release_power_short key_release_power_long


I don't know what it does and the only way I'd be happy changing it would be after extensive research. Frankly it scares me!

Here's what I was thinking we'd do for a 'configuration' syntax in Mer:

# describe some action
def on_wifi_up():
  notify "The wifi is up"
  os.system("mail me@gmail.com -S 'wifi is up'")

connect(wifi, "Connection.up", on_wifi_up)

connect(camera, "Camera.active", takePhotoAfter10Secs)
connect(camera, "Camera.turn",   media.play, "/home/lbt/sounds/camera_click.wav")
connect(powerButton, "Button.longPress", powermenu.show_menu)


This uses a python signal library (like Qt or libsigc++) and provides a set of component objects that emit nice signals like "Connection.up".

The benefits of this approach:

• simple syntax is nice and readable
• interpreted so can easily be edited
• python understood by many so can be easily extended
• re-uses some powerlaunch code (eg powered)

Of course there are drawbacks:

• it's not a config file - it's code (but considering we want to configure functional behaviour then any config syntax needs to be a language... so use a decent one)
• python is quite large (but it's now in memory and .so are available)
• it's another re-write :(  (it only took a few days and I'm using powerlaunch as a prototype for config rules - if I can understand them!!)

So anyway, as I said, I found eclipse Modelling edition...

This says (well, I hope it says):

• There is a system and a user dispatcher
• They're based on a common Dispatcher
• Which contains components (such as Headphone, Menu etc) that can
• send signals (eg when the camera on the N800 is turned)
• take requests (dim the screen)
• provide state information (a headphone is connected)
• be accesed on D-Bus
• The Dispatcher creates Connections which
• listen() for Components to emit signals (also listening on D-Bus)
• run Scriptlets which might
• run arbitary code
• make requests to components
• emit signals that (other) Connections can listen() for
• Scriptlets are part of the Dispatcher

Oh, and the good news is that it's up and running... I'll put the code on gitorious RSN.