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 ;)
Planet maemo: category "feed:fb2e01f2b05f173de4f8ef523cd2a4d2"
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:
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....)
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)
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....)
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?
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!)
Open source is about opening things up... right?
Well, yes.
But I think there's more to it than that.
Well, yes.
But I think there's more to it than that.
So I've been working on accelerating the Open Build Service recently.
That's what the OBS does for us.
The openSuse builder provides Mer with an incredibly powerful tool for building packages.
It gives us:
Think of it as a wrapper around the distribution's standard build tools which provides queue management and a good web interface.
What's good about that then?
And it does this around multiple base distributions inclding Debian/Ubuntu/Redhat/Centos/Moblin and of course SUSE and openSUSE.
Just try building a Redhat package on the Debian build system - or vice versa.
What makes it particularly interesting for Mer is that it also does this with multiple architectures including ARM.
So what Mer essentially does is to feed it a large number (~200) standard debian format source packages and wait for it to spit out .deb files in an sources.list compatible repository.
Doing this correctly means it needs to analyse build dependencies and, make-like, consider the freshness of those dependencies to determine if a rebuild is required. So if a change is needed in libhildonfm2 then all the packages that depend on it will be rebuilt - nice.
If you'd like to read a bit more about how Mer uses it then start on the Mer Build pages.
The openSuse builder provides Mer with an incredibly powerful tool for building packages.
It gives us:
- over 150 build cores !!
- powerful monitoring and control tools - web and cli
- total access - it's all GPL
- proven capability - openSUSE and SLE are built using it
- distribution neutrality
Think of it as a wrapper around the distribution's standard build tools which provides queue management and a good web interface.
What's good about that then?
- No wheels being re-invented - it uses the 'standard' tools
- Quality control - packages must specify exactly what they depend on to build; and a build installs clean packages and builds from clean source
- Management wrappers - more about this later
And it does this around multiple base distributions inclding Debian/Ubuntu/Redhat/Centos/Moblin and of course SUSE and openSUSE.
Just try building a Redhat package on the Debian build system - or vice versa.
What makes it particularly interesting for Mer is that it also does this with multiple architectures including ARM.
So what Mer essentially does is to feed it a large number (~200) standard debian format source packages and wait for it to spit out .deb files in an sources.list compatible repository.
Doing this correctly means it needs to analyse build dependencies and, make-like, consider the freshness of those dependencies to determine if a rebuild is required. So if a change is needed in libhildonfm2 then all the packages that depend on it will be rebuilt - nice.
If you'd like to read a bit more about how Mer uses it then start on the Mer Build pages.