tag:blogger.com,1999:blog-28393804395580715042024-03-13T05:56:23.125+00:00Come on in...Developing for MeeGo, Mer, Maemo and other OSS systemslbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.comBlogger30125tag:blogger.com,1999:blog-2839380439558071504.post-43122260713522471842011-08-07T00:10:00.000+01:002011-08-07T00:10:11.318+01:00Restructure MeeGo : By InstallmentsI've just published a series of articles that reflect my thoughts on<br />
improving MeeGo and setting some directon. This outline should help navigate.<br />
<br />
<ul><dt> <a href="http://mer-l-in.blogspot.com/2011/08/restructuring-meego-executive-summary.html ">Restructuring MeeGo : Executive Summary</a><br />
<dd> Where should MeeGo be targeted?<br />
<br />
<dt> <a href="http://mer-l-in.blogspot.com/2011/08/meego-core-focus.html ">MeeGo Core : focus</a><br />
<dd> What should MeeGo Core be delivering?<br />
<br />
<dt> <a href="http://mer-l-in.blogspot.com/2011/08/meego-systems-and-processes.html ">MeeGo: Systems and Processes</a><br />
<dd> What else should MeeGo be delivering?<br />
<br />
<dt> <a href="http://mer-l-in.blogspot.com/2011/08/meego-evaluating-meego.html ">MeeGo : Evaluating MeeGo</a><br />
<dd> How do we support MeeGo evangelists?<br />
<br />
<dt> <a href="http://mer-l-in.blogspot.com/2011/08/meego-lead-by-example.html ">MeeGo : Lead by example</a><br />
<dd> How we should walk in our customers shoes.<br />
<br />
<dt> <a href="http://mer-l-in.blogspot.com/2011/08/meego-and-hacker-community.html ">MeeGo and the hacker community</a><br />
<dd> How do we embrace the hacker community?<br />
<br />
<dt> <a href="http://mer-l-in.blogspot.com/2011/08/meego-infrastructure.html ">MeeGo : Infrastructure</a><br />
<dd> Pragmatics... what services should we run?<br />
<br />
<dt> <a href="http://mer-l-in.blogspot.com/2011/08/meego-restructured.html ">MeeGo :Restructured</a><br />
<dd> How could we approach this?<br />
</ul>lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-832164381118048452011-08-03T13:33:00.001+01:002011-08-04T10:25:56.068+01:00MeeGo :RestructuredOf all these posts this one is the biggest strawman. It is not a concrete proposal... more an exploration of possible structures.<br />
<br />
<h2>Development and Maintainance Projects.</h2><br />
(note ... the term "native packages" is explained at the bottom)<br />
<br />
<h3>Core</h3><br />
Packages needed to create a MeeGo image that boots to a bare X/Wayland screen (with no applications) on a reference device (eg ExoPC). Middleware packages driven by the IVI, Tablet and Handset verticals are in the scope of Core. Reference UXes are not.<br />
<br />
Focus is on providing a minimal set of packages to allow a product be built upon. Everything required for compliance and very little more.<br />
<br />
"I can build a compliant product from the source released from this area."<br />
<br />
Question: How to manage the reference device Hardware Adaptation (HA) without giving special treatment?<br />
<br />
Primarily a maintenance project with few native packages.<br />
<br />
<br />
<h3>Tools, build-root and toolchain</h3><br />
Packages needed by developers to compile and create MeeGo images: gcc, spectacle, gdb, make etc.<br />
<br />
Note that some tools like mic2 that need to be supported on non-MeeGo platforms (SuSE, Debian, RHEL/Fedora, Ubuntu etc) may be better placed in the 'External Tools' project.<br />
<br />
Primarily a maintenance project with few native packages.<br />
<br />
Tied tightly to Core release schedules.<br />
<br />
<br />
<h3>Distro : Apps + Surrounds == "MeeGo, the distro"</h3><br />
MeeGo isn't a distro - but for the convenience of the hacking community of users on MeeGo devices it should have one. This area provides packages for apps and upstream libraries required to support them like emacs, vim, python etc. It would be made up from Apps and Surrounds. MeeGo should be the reference to be developing on for MeeGo<br />
<br />
Surrounds is primarily a maintenance project with few native packages. Very similar to typical distros.<br />
<br />
Apps is primarily a development project with native packages.<br />
<br />
Related to Core releases.<br />
<br />
<br />
<h3>SDK</h3><br />
Packages needed to develop Apps for MeeGo.<br />
<br />
Primarily a development project with native packages.<br />
<br />
Related to Core release schedules.<br />
<br />
<br />
<h3>External Tools and Systems</h3><br />
Packages, documentation and IT information for build and deployment systems/packages used by MeeGo and vendors. Typically intended to run on OSes other than MeeGo. Scope includes OBS, Bugzilla, BOSS, OTS, mic2, REVS, IMG<br />
<br />
A mix of maintenance and development packages.<br />
<br />
<br />
<h3>Reference Tablet UX, Handset UX, IVI UX</h3><br />
Packages providing a reference UX layer that can be built on top of the Core. No Core packages can be touched. These projects are intended to be used not just as reference implemenatations but also as reference working models.<br />
<br />
Requests and bug-reports to Core from the MeeGo UX project should not be treated any differently to a customer project developing a closed UX.<br />
<br />
It would make most sense to develop the UX as an aspect of an integration project.<br />
<br />
Primarily a development project with native packages.<br />
<br />
They could have an release schedule independent to Core (as a vendor would).<br />
<br />
<br />
<h3>Multiple Hardware Adaptation Projects</h3><br />
Community or openly managed packages needed to adapt or supplement Core to boot and run to the same level as Core on individual devices such as ExoPC, IdeaPad, N9* etc. Working with Core and a suitable CE project would be a good approach that would exercise problems faced by vendors with multiple hardware devices.<br />
<br />
A mix of maintenance and development packages.<br />
<br />
<h2>Integration Projects</h2><br />
Eventually these projects should support MeeGo overall by highlighting and helping to resolve interoperability issues based on different MeeGo releases or form-factors.<br />
<br />
<h3>Handset Community Edition / CE</h3><br />
Packages from Core, the N9* HA and one (or more) Reference UXes as well as CE-specific packages.<br />
<br />
The CE project acts as a 'Reference Vendor' http://mer-l-in.blogspot.com/2011/04/meego-de-that-is-how-you-do-it.html<br />
<br />
<br />
<h3>Tablet Edition</h3><br />
As with the Handset CE but using different HA projects. The ExoPC MeeGo images should be released by this project.<br />
<br />
This project too should be contributing to the 'Reference Vendor' concept.<br />
<br />
<br />
<h3>IVI Edition</h3><br />
As with the Tablet Edition but for IVI.<br />
<br />
<h2>Futures</h2><br />
What else? Well how about some future gazing?<br />
<br />
<h3>MeeGo Python</h3><br />
A set of packages supported by MeeGo. Device vendors who see the value in QML apps with python as the underlying language may include this in a "Compliant" device under an appropriate "MeeGo" label.<br />
<br />
<h2>Mini-Glossary</h2><br />
<h3>native packages</h3><br />
MeeGo tends to use upstream packages wherever possible; but of course some areas will develop new software - these packages are known as 'native' packages since the code and the packaging are managed at the same time.lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-17357747840719546502011-08-03T13:20:00.000+01:002011-08-03T13:20:47.092+01:00MeeGo : InfrastructureAs mentioned, we want MeeGo projects to use and validate the interfaces and procedures we expect our customers to use. To support this we should provide an operating environment to enable that goal.<br />
<br />
An accident of history means the infrastructure we use is already set up in a way that would allow us to replicate some aspects of a vendor's view of MeeGo; we should take advantage of this and as well as clarifying the organisational lines between projects we should strive to replicate the technical interfaces too.<br />
<br />
In order to support this new project setup I propose we *don't* change our infrastructure in any significant way.<br />
<br />
One key objective (IMO) is to help vendors deliver MeeGo products. This means ensuring that when they deploy systems like OBS, OTS, Bugzilla, BOSS, REVS and others they can get up and running quickly. It also means that they should be able to interoperate smoothly with the MeeGo projects identified above.<br />
<br />
We have 2 OBS deployments - we should expand this to include additional systems such as Bugzilla and we should live through the "remote system" issues we expect customers to face.lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-18848730153709347532011-08-03T13:17:00.001+01:002011-08-03T13:28:58.918+01:00MeeGo and the hacker communityWe know that : "The MeeGo project provides a Linux-based, open source software platform for the next generation of computing devices." <a href="https://meego.com/about">(https://meego.com/about)</a><br />
<br />
So from that I suggest our target customers are pretty obvious: Device manufacturers. Not individual OSS community hackers.<br />
<br />
I suggest that we hackers (I consider myself a community hacker as well as a paid MeeGo contributor) should approach MeeGo by recognising that:<br />
<br />
<blockquote><b>MeeGo is not aimed at us -- Sorry but it's not.</b></blockquote><br />
Think about it - we don't want it to be aimed at us. We want devices running MeeGo that we can hack. So lets help make it super-attractive to device vendors; then we get to buy their hardware and do what we do best ... hack on it!<br />
<br />
Having another Debian/openSuSE/Fedora isn't going to help - if device vendors wanted this then they already exist. MeeGo *has* to be different.<br />
<br />
But this doesn't stop us from building cool stuff using MeeGo. Nothing is stopping us from contributing back.<br />
<br />
However, by letting MeeGo Core focus on delivering to device vendors we in the hacker community can set up projects like the N900 CE where we have *much* more freedom to construct a real distro. MeeGo Core by itself is not much fun - CE is where the cool stuff happens ;)lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-83361287615165145122011-08-03T13:14:00.000+01:002011-08-03T13:14:08.842+01:00MeeGo : Lead by exampleOne of MeeGo's biggest failings IMHO is related to its customers.<br />
<br />
We expect our customers to work with us and against our systems: OBS, BZ etc - but do we even know how that 'work with us' is supposed to work?<br />
<br />
We expect our customers to track bugs in our Bugzilla and link to their private Bugzilla. How exactly?<br />
<br />
When a problem is seen in MeeGo we expect a bug report and/or a patch - yet we can't even make that work ourselves; our UX team are granted special rights that customers don't have. Certain patches appear referencing private bug trackers (eg B.O.O bugs) - if Intel can't get this right then our customers have no chance. The only way to solve this problem, and to keep on top of it, is to ensure that significant parts of the MeeGo project act as if they were external customers - still very much a part of the open community but experiencing the social and technical interfaces that we expect customers to use.<br />
<br />
I propose we handle this in 2 ways:<br />
<ul> <li> CE, UX and Tools to become discretely scheduled MeeGo Projects<br />
<li> Seperate OBS, BZ and REVS infrastructure for Projects and Core<br />
(reviewed in more detail later)<br />
<li> No special handling of any Projects (eg UX)<br />
</ul><br />
A more powerful long term solution is to take the opportunity that the Community Edition project offers to fulfill the role of a 'reference vendor' and openly demonstrate how effectively MeeGo can deliver. We should use this to explain, demonstrate - and validate - how real vendors should interact with the MeeGo project at all levels: features, bugs, processes, release management, communication and even infrastructure.<br />
<br />
Essentially we should make "How to be a MeeGo Product Builder" a MeeGo Project deliverable.lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-70784773374497078522011-08-03T13:12:00.000+01:002011-08-03T13:12:00.079+01:00MeeGo : Evaluating MeeGoMeeGo is most likely to enter an organisation via an exhaustive evaluation process.<br />
<br />
We need to understand where those performing the evaluation will have come from. Clearly many will have significant experience in the embedded space and there are some good projects in MeeGo supporting these experienced developers in establishing a prototype MeeGo port to their hardware.<br />
<br />
What we're missing though is a solution that allows this 'one man hacker' type evaluation to scale into a multi-person team evaluation and demonstrate MeeGo's suitability for an international, multi-team, delivery organisation with hundreds of people.<br />
<br />
MeeGo can do this already - for free. So why aren't we shouting about it?lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-33901817433009640792011-08-03T13:10:00.000+01:002011-08-03T13:10:45.583+01:00MeeGo: Systems and ProcessesVendors need much more than lots of source code and a toolchain: they need clarity, consistency, guidance, processes and systems.<br />
<br />
Whilst we've looked at clarity at the package level there are a lot more areas where guidance would be welcome; setting up an end-to-end delivery system with various organisational units is a daunting task.<br />
<br />
MeeGo has knowledge in this area and can - and should - be delivering more of what device manufacturers (and those in the ecosystem around them) need to prepare themselves to make these MeeGo based products.<br />
<br />
Whilst relatively straightforward, probably the most valuable initial delivery would be a consistent set of terminology. This will establish a baseline for communication and improve comprehension of the entities in the MeeGo world and how they relate to previous experiences.<br />
<br />
We already provide and suggest some systems: OBS, OTS, BOSS, Bugzilla, IMG, GIT, REVS - the next step is to suggest how these are deployed and configured. This would improve deployment speed and reduce "time to productivity".<br />
<br />
Following on from this we can provide information to support sizing estimates for various aspects of the deployment; from build and test systems to training.<br />
<br />
Finally we can outline proven approaches to integration; handling code flows from GIT to OBS; bug handling strategies; managing daily and weekly snapshots; MeeGo synchronisation schedules.<br />
<br />
This area is likely to be seen as the domain of SIs - however MeeGo will benefit from establishing a reasonably consistent approach across the board; having a 'preferred' deployment/integration solution will reduce variation and hence support costs (both to MeeGo and upstream tools like the OBS); confusion is less likely to arise from mismatched expectations; Vendors and SIs will be able to interoperate more easily;<br />
<br />
Proposal:<br />
<li> Support the MINT (MeeGo Integration Tools) project<br />
<li> Deliver a Vendor Manuallbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-2835201509111113902011-08-03T13:07:00.000+01:002011-08-03T13:07:54.162+01:00MeeGo Core : focusMeeGo does deliver a great set of packages which experienced teams can use as an excellent baseline for building product.<br />
<br />
What is not needed is yet another general purpose linux distro where each vendor has to interpret the structure and determine for themselves exactly which packages belong where.<br />
<br />
Instead we should be clear about what packages the MeeGo project delivers : A tight baseline which can be relied on when delivering a commercial product.<br />
<br />
When approaching MeeGo it is not at all clear what is required for compliance and what is part of the sample distribution that vendors are expected to either replace or significantly change.<br />
<br />
I suggest MeeGo package areas are clarified and redefined and that interfaces between them (especially reference projects) are made more explicit.<br />
<br />
In particular MeeGo should offer a Core which provides a minimal set of packages - enough to build a compliant product. The processes used in Core must obviously be appropriate for MeeGo development - but they *must* also be appropriate for customers too. Around the Core MeeGo will have a number of associated projects forming a well-defined structure around a "bullseye" and not a fuzzy melting pot. These are very much part of the MeeGo project but may only be loosely tied to the release schedule of Core.<br />
<br />
Tasks :<br />
<li> rip out what's not neeeded from Core<br />
<li> create UX and Tools projects<br />
<li> create an open MeeGo distro built on these projects<br />
<br />
Benefits:<br />
<li> Smaller groups are easier to manage<br />
<li> Permits properly exploring the vendor:MeeGo relationship at the<br />
operational level<br />
<li> Much easier for alternative 'reference' solutions to take rootlbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-61371895618517047752011-08-03T12:57:00.000+01:002011-08-03T12:57:59.082+01:00Restructuring MeeGo : Executive SummaryWhilst the MeeGo Project has the potential to be incredibly beneficial to the linux device market it can and must do more to fulfill that aspiration.<br />
<br />
MeeGo is in danger of becoming "Yet Another Linux Distro". As with any venture; in order to succeed MeeGo must first identify and focus on satisfying its customers.<br />
<br />
Identification is not too hard : organisations involved in building devices based on MeeGo.<br />
<br />
Satisfying them is harder : these organisations are not your typical linux hackers, nor are they linux-friendly IT teams. They are software product delivery professionals. They care about more than just the source that comes out of MeeGo - they care about managing their build and delivery environments. The last thing these people want is to re-invent the wheel; they are under pressure and need as much help as they can get - automation, QA, progress reporting, minimising overhead and cookie-cutter deployments.<br />
<br />
Delivering a repo full of packages is a great start but it's not enough .. not by a long shot.<br />
<br />
This is the first in a series of few articles that make some concrete proposals.<br />
<br />
(Thanks to the community people who've helped review this : I'll put the text onto the MeeGo wiki for further comment and editing).lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-52095702166803158632011-04-27T12:48:00.001+01:002011-04-27T13:10:03.432+01:00MeeGo DE - *THAT* is how you do it ....Over the past several weeks I've been hitting one concept over and over again: "reference".<br />
<br />
I'm talking here about the idea of a reference implementation; and I don't mean something so comprehensive that it's almost useless... rather a manageable set of information aimed at easing entry into a project.<br />
<br />
I've been accused of being a bit long-winded :) So let me offer a short proposal:<br />
<br />
<blockquote>Justify the DE project by extending the "DE Project Vision" to include "Be a reference vendor". Extend the deliverables to include documentation about processes, organisational layout and tool usage. Test, challenge and improve the MeeGo <-> Vendor interface.<br />
</blockquote><br />
I put this to Carsten and Jukka a while ago and they were very positive about it - so if it sounds intriguing then here's my thinking:<br />
<br />
MeeGo is (or should be) aimed at vendors. So what is a vendor? Or perhaps, in this context, what aspects of a vendor are we interested in? I think the following three areas are relevant:<br />
<ul><li> The Veneer ("Value Add Layer" if you're marketing a device)<br />
<li> Hardware Adaptation<br />
<li> Contributing Back (A phb may prefer to hear: "Influencing MeeGo's direction")<br />
</ul>
As a vendor newly arriving at MeeGo I am going to need to work in one or more of these areas - so what do I do? What systems do I need? How do I setup teams, OBS projects? How do they interact with MeeGo? What testing processes should I use? What tools and systems are already available? How do I avoid re-inventing the wheel? How do I link to the core OBS? How do I get a feature included in the core?
<p>
Answering these questions correctly is vital if a vendor is to effectively assess the cost of operating in the MeeGo ecosystem; and that assesment should influence their decision to work with MeeGo. Quite simply: the lower we can make barriers to entry, the more vendors will join MeeGo. Not only that; if we can identify and resolve problems with them then that will improve satisfaction. It is also worth remembering that many vendors will be new to working in the open - using the reference project may help to overcome 'shyness' be it cultural or confidentiality based.
<p>
This is not just about vendors either. MeeGo as a project has to support the vendor ecosystem - and whilst we do want a diverse community out there, we don't want to support needless variations in process or even terminology. Providing a "suggested way of working" and ensuring that all our tools and processes work with it means that we can minimise the cost of these interactions from MeeGo's point-of-view.
<p>
MeeGo also provides interfaces to these vendors - but has no real mechanism for reviewing or testing them (although I'd like to address that in my <a href="http://sf2011.meego.com/program/sessions/bof-fixing-meego-setting-open-vendor-ecosystem">BoF session at MeeGo 2011</a>). For example
<ul><li> the handling and communication of significant API changes during development;<br />
<li> simple operational communication;<br />
<li> how are vendor products supported *after* a MeeGo release? <br />
<li> how should vendors operate near releases (forks);<br />
<li> I need a change to a MeeGo component : it's not going to be accepted this release; what do I do?<br />
</ul>
DE operates in all of the layers I mentioned but it's not clear what activity is related to what layers. I'd like to see:
<ul><li> DE provide some clarity around the three roles: particularly a review of the OBS project structure and role-specific processes.<br />
<li> Clear product-oriented and release-managed deliverables in the veneer layer with testing and automation<br />
<li> Documentation of a requirements driven approach to MeeGo core contributions<br />
<li> Documentation of a requirements driven approach to hardware adaptation<br />
</ul><br />
Of course the objective of these deliverables is to support new vendors and contributors to DE/MeeGo; not to overburden the contibutors. bearing in mind that<br />
<br />
I think the success criteria in this ares would be if any organisation can quickly and easily setup a new initiative to thoroughly evaluate MeeGo for a new product.<br />
<br />
There are other areas where we can support vendors by pursuing this model; the use of the MeeGo community OBS mimics the separation between the MeeGo OBS and the vendor's internal OBS. This allow issues dealing with the relationship to MeeGo to be examined openly: what is the recommended link to the core OBS; how are vendors impacted by downtime; what's the best approach to provide a reasonably stable MeeGo base to build the 'veneer layer' on during a sprint whilst still allowing the vendor to be aware of emerging issues in Trunk.<br />
<br />
MeeGo also has other system tools: BOSS, REVS, IMG and OTS are freely available and were designed at Nokia using their product building expertise - how can we offer these to the MeeGo vendor ecosystem to once again reduce cost and probably more importantly: time to market. These tools are used in MeeGo core - but they are not documented or discussed (and are probably not relevant to vendors anyway since their business goals are different). Using them in DE allows increased public scrutiny.<br />
<br />
So here's another success criteria (for both DE and MeeGo tools): is DE using MeeGo tools to deliver their product? Do the managment reports from REVS provide useful data? Is BOSS automation effective and sufficiently low-overhead? Does OTS work in resource-limited environments?<br />
<br />
Finally - you have to ask what the point of the DE project is? I think if it can be held up as an example of "How to work with MeeGo" and has real deliverables beyond supporting an aging device then it provides a tangible benefit to everyone in MeeGo.<br />
<br />
A little post-script too : whilst I've focused on DE here this concept applies to a lot of what's done around MeeGo. Opensource succeeds because we stand on the shoulders of midgets - a *lot* of midgets. We should each aim to ensure that when we 'deliver' something to the opensource community we ask "how easy have I made it to let someone else improve on this?"lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-37662049531593582382011-02-12T09:59:00.001+00:002011-02-12T13:51:07.833+00:00What now for MeeGo?So Nokia has dramatically reduced commitment to MeeGo and has cited,
amongst other thinks, MeeGo's inability to deliver a focussed baseline
with sufficient speed. I happen to agree with this failure (and given
Nokia was a significant part of MeeGo's management I don't think
there's a blame issue - more a how do we fix it issue)
<h2>Assumptions and observations:</h2>
<ul>
<li> MeeGo is intended to provide a viable but focussed baseline upon
which vendors can build compliant products; not to be an expansive
and 'complete' linux distribution.
<li> MeeGo has limited dedicated resourcs and focusing them on a
reduced MeeGo core will improve quality.
<li> MeeGo's main customers are not end-users - they are device
vendors : they should be the focus of our core engineering team's
design, delivery and QA effort.
<li> MeeGo core does not appreciate the difficulties a vendor has in
tracking MeeGo;
<li> A visibly secure development model is important to the perceived
integrity of MeeGo - so visibly restricting write access to the
core is important.
</ul>
<h2>Proposal:</h2>
<ul>
<li> MeeGo Core is confirmed as not being a linux distribution
<li> An open MeeGo project (openMeeGo?) is created on the community
infrastructure to provide a reference MeeGo distribution
<li> Packages not *essential* to the delivery of a compliant MeeGo
Core are moved into the community OBS (emacs, vi etc - maybe even
the reference UXes) where they are available for use by
development teams and end users.
<li> "openMeeGo" acts as a reference vendor and provides a forum for
reviewing and improving the processes MeeGo uses to communicate
releases
<li> MeeGo community (which includes core developers) has a
significantly lower barrier to entry.
</ul>lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com3tag:blogger.com,1999:blog-2839380439558071504.post-18891856377932860342011-01-27T01:19:00.000+00:002011-01-27T01:19:11.683+00:00MeeGo Community Development: Apps, Surrounds and the Community OBSSo... lets say we have some device that run MeeGo; what else can
it do? Where are the apps?
<br/><br/>
<h3>Apps - the area formerly known as "Extras"</h3>
Borrowing <a href="http://lists.meego.com/pipermail/meego-community/2010-December/003021.html">Andrew Flegg (Jaffa)'s mission statement</a> for MeeGo Community
Apps: we need to ensure a vibrant and quality area for community open
source software. <br/><br/>
So MeeGo Apps is the community app store and follows on from the
succesful <a href="http://maemo.org/downloads/Maemo5">Maemo Extras.</a> <br/><br/>
It allows app developers to build MeeGo compliant (and other) apps and
distribute them to users. <br/><br/>
What makes Apps different from a 'random repository' is the community
QA process that is applied; the objective of this QA process is to
permit users to trust the apps and to deliver a collection of apps
that a commercial vendor could enable on a shipping device (as Nokia
did with 'Maemo Extras' on the N900). <br/><br/>
Clearly then, there needs to be some processes (and automation) to
define how QA checks are carried out and what to do when certain
events occur. We already have a process automation sytem (called BOSS
- it's is being developed by Nokia and is essentially an integration
of various OSS libraries) - now we need to decide what processes and
criteria we use to manage and promote apps. Initially I suggest we
start with <a href="http://wiki.maemo.org/Extras_repository_process_definition">the Maemo Extras process</a> and refine that. <br/><br/>
When we talk about process we are also talking about policy. I've
discussed this below and quite a few of the points apply to Apps.<br/><br/>
Now, it's not yet clear what OBS targets Apps should build
against. Currently <a href="https://build.pub.meego.com/project/list_public">we have</a>:
<ul>
<li> MeeGo:1.1:Core
<li> MeeGo:1.1:Core:Handset
<li> MeeGo:1.1:Core:IVI
<li> MeeGo:1.1:Core:Netbook
</ul>
These correspond to the MeeGo Core and then a number of UXes. However
there are plans to consolidate them in the main MeeGo OBS - but how
should the Apps area look? Should a handset user be presented with apps
which were only intended to run on a netbook? OTOH is this anything to
do with the repo and build target - should it be determined by
metadata and selectively presented by the download application?
<br/><br/>
Well, until this is resolved, an app developer simply needs to enable
each target that the app supports to make it available in that
repository.<br/><br/>
I think the discussion up to this point is fairly simple and
uncontentious; we can start to address the issues mentioned and
<a href="http://wiki.meego.com/Community_Application_Support">just get on with it</a> and start to deliver MeeGo Apps :)<br/><br/>
However, as mentioned, the Apps area allows both MeeGo-compliant and
MeeGo-extra applications. <i>MeeGo-compliant</i> apps are those which only
use libraries in MeeGo core/UX; <i>MeeGo-extra</i> apps have a little extra
open-source goodness sprinkled in... Surrounds.
<h2>MeeGo: The Linux Distro</h2>
Before I tackle 'Surrounds' lets step back a little:<br/><br/>
Since MeeGo was announced around a year ago I've been interested in
how development happens around MeeGo as well as in the centre. The
following is intended to be a discussion document; there are clearly
some large gaps and I expect some of my proposals to be shot down -
but I really hope that only happens when better ones are proposed!
<br/><br/>
In order to address this I think it's important to ask... what is the
point of MeeGo? Well, IMHO, MeeGo is primarily a modern linux baseline
upon which commercial mobile computer products can be delivered.
MeeGo's main customers are not end-users - they are device vendors;
*they* should be the focus of our core engineering team's design,
delivery and QA effort. <br/><br/>
So MeeGo clearly has a focused development area with the main OBS
supporting the development and delivery of the MeeGo core system
software and reference UXes. <br/><br/>
Of course MeeGo is also capable of being a wonderful and open linux
distro in its own right. However I personally think that to be a
success, the MeeGo core needs to focus on the primary goal and allow
more of the "linux distro" side to be managed as a surrounding
project. <br/><br/>
Incidentally, in my day job I care a lot about how MeeGo presents
itself to us as a vendor. I think it would be a good thing for MeeGo
to have it's own "reference product" built around the core that it
offers to vendors. This would expose issues like:
<ul>
<li> How does MeeGo communicate significant upcoming changes to it's
customers?
<li> How do we deal with package naming clashes?
<li> How much of MeeGo is needed for compliance vs the parts that are
needed to make a reference implementation?
<li> With more than one community product: how connected are devices?
</ul>
So, 'Surrounds' is a proposal that aims to provide a collection of
open source libraries, tools and applications that support the
building of collaborative bazaar-style applications and yes, maybe
even MeeGo distributions. <br/><br/>
Whilst I don't think this is an immediate change, I do think it's an
interesting direction for MeeGo to take that may allow more focus on
the core deliverables.
<br/><br/>
In the meantime lets look at this "extra open-source goodness" I
promised:
<h2>Surrounds</h2>
As we know, the open source world is a world of sharing; we regularly
stand on the shoulders of our peers and it's considered very bad taste
to just 'bundle' a library into a monolithic application. (Notice how
I didn't mention any kind of compliance programme by name - aren't I
good!) <br/><br/>
Surrounds provides a collection of libraries and tools that encourages
this <b>best practice</b> way of working in MeeGo and delivers <i>MeeGo-extra</i>
apps. The most obvious area would be for languages like perl, python
and ruby. These languages have large numbers of useful libs that
clearly are not going to be present in core MeeGo. Of course there
will be many other tools and applications that would also be at home
in Surrounds. <br/><br/>
Over time, packages may migrate into core MeeGo and equally, some are
going to be deprecated. Hopefully Surrounds makes both of those
actions a little easier but we do need to decide how we handle
deprecation/promotion of applications/libs between core and Surrounds.
<br/><br/>
There are many complexities when dealing with a collection of packages
like this:
<br/><br/>
<h3>QA and Releases</h3>
The fundamental question is "How is Surrounds QA'ed and released?".
<br/><br/>
This is a significant undertaking and needs a lot of resource and
users. This alone means that Surrounds should probably start off
slowly and ramp up as MeeGo users and developers arrive in larger
numbers. The important thing is to prepare for the main issues we're
likely to face.
<br/><br/>
I propose that Surrounds is actually only populated on an "as needed"
basis; tools can be submitted directly but libraries have to be needed
by a tool or by an application submitted to the Apps area.
<br/><br/>
<h3>Upgrades and concurrent installations</h3>
For example: let's look at a device that has MeeGo 1.2 installed on it
and an application "Wowee" built against an imaginary libvisual-1.0
which is in the Surrounds-1.2-A stable release of Surrounds.
<br/><br/>
9 months later many libraries have been updated and developers
want to use the latest versions... it's time to release a new
version of Surrounds-1.2. Sadly libvisual is up to version 1.0a
with a minor tweak which would break Wowee; not only that but
the Wowee developer has gone awol (so there's no-one to test
it) and no-one's stepped up to update it. Even worse there are
50,000 users using Wowee which is working like a dream.
<br/><br/>
Looking at the large number of apps in Maemo Extras I think
problems like this will arise and are beyond the resources of
the community to handle at this point.
<br/><br/>
A technical solution may be that when Surrounds-1.2-A is installed it
goes into /opt/surrounds/1.2-A/... and any apps use the appropriate
path to find their dependencies. <br/><br/>
This allows apps that use libraries from Surrounds-1.2-A and
Surrounds-1.2-B to be installed concurrently even if they use
different versions.
<br/><br/>
I'm not sure how Surrounds-1.2 handles upgrades from MeeGo 1.2 to 1.3.
<br/><br/>
The message however is that there are many issues like this that it
would be good to identify in advance. Just ask a maemo developer about
the <a href="http://wiki.maemo.org/Opt_Problem">"optification"</a> hack :)
<br/><br/>
<h3>Porting vs Maintaining : A MeeGo partner</h3>
When it comes to populating Surrounds we need to look to the larger
linux ecosystem.<br/><br/>
Some tools and libraries will have comitted maintainers who have time
to monitor their packages and fix bugs and security issues in a timely
manner. <br/><br/> This is the classic distribution 'maintainer'
role. <br/><br/>
Some libraries won't. Developers will simply need a particular library
and 'grab' a source rpm that looks like it's good-enough. They throw
it at the OBS and a few minutes later have an installable package for
their application. This is what happens in Maemo Extras. <br/><br/>
I call this activity 'porting'. <br/><br/>
The problem arises when another developer does the same thing a
few weeks later with a slightly different version of the
package. This may cause the original app to fail.
<br/><br/>
Equally, none of those developers want to commit to maintaining
the library. So when a security issue arises, no-one is ready
to update the package.
<br/><br/>
I'm actually a little concerned about prolific porting - and sadly
this is the bit that gets the fame and glory : "look how many packages
he's ported". The truth is that this doesn't bode well for MeeGo in
the long run. <br/><br/>
My suggestion for this group of packages is to nominate an upstream or
partner distro with a good security record and a wide base of
packages. Surrounds releases would closely track this distro (and will
likely differ from core MeeGo). Packages taken from this distro would
be fast tracked as 'ported' rather than 'maintained' and only minimal
packaging changes would be allowed. This would allow Surrounds to
leverage the partner-distro's security efforts (and hopefully offer
benefits to the partner in return). <br/><br/>
For obvious reasons I propose openSuse as the partner distro. (For the
record I'm a Debian guy - but lets be sensible here!) <br/><br/>
For equally obvious reasons this is a political minefield :)
<br/><br/>
<h3>Some random policy questions:</h3>
There are a lot of policy considerations for the community; some I
wrote in a bit of rant (forgive me Shane). Some apply to Surrounds and
Apps, some to the OBS in general <br/><br/>
<ul>
<li> Licenses: OSI only licenses? GPL3 (considering the "promotion
to core" target).
<li> People: What's the process for absent devs? If someone says
"hey, lbt, let me upload a new version of that library Shane
uploaded" ... do I just let her? What if there's a security
issue in it? What if you've not been seen in 3 months? Do
maintainers need to demonstrate reliability to handle timely
updates?
<li> Legal : Do we accept mp3 players? libdecss? What about porn?
What about apps with a rather rude splash screen? Any patent
issues? (Don't forget the system physically lives in the
"land of the free" so is subject to state seizure by the
RIAA).
<li> Commercial: I've had commercial organisations enquire about using
the community OBS. I've had them ask to sponsor it. How do we deal
with this? My first reaction is "no commercial work"... but why not?
<li> Quality: Do we insist on a valid bugtracker being identified
for all Surrounds packages? Must it proxy via a bmc#?
<li> Packages scope: Where's the ITP?
<li> Can we rebuild MeeGo with some different compiler flags (think
non-ssse3 ... yay ... I can run MeeGo on my AMD desktop at last!)
<li> Do we sign any of the community repos? What does that mean?
<li> Acceptable Use Policy : at what point do we ask users to stop
doing what they're doing?
<li> Non-MeeGo targets? When Smeegol becomes Sogmeel will we allow it
to be a target?
</ul>
Again the message is "there's a lot to think about".
<h2>The Community OBS</h2>
We have a <a href="http://build.pub.meego.com">MeeGo Community OBS</a> already; and it builds apps for MeeGo.
<br/><br/>
It is currently managed by Niels Breet (X-fade) and I (lbt) - but we
need more help. In part this whole post is a way to structure what
we'd like to achieve and to make it easier to identify tasks.
<br/><br/>
<h3>Structure</h3>
So what project structure do we need? We've not assumed MeeGo at the
top level namespace to allow us to support additional distros such as
Fremantle and hopefully others.
<br/><br/>
One common use for structure is to provide a QA route. Packages go
from some sub-project in a developer's home: area to a 'Team' area and
then into a Testing area. Each transition is subject to policy and
quality checks. Defining these workflows and structures correctly will
make life easier.
<br/><br/>
<h3>Team Areas</h3>
It makes sense for teams to have collaboration for things like KDE,
Gnome, Python, LibreOffice, Emacs etc. This would allow more thorough
testing to take place before releasing either to Surrounds or Apps
<br/><br/>
However, what's needed to form a team? Can anyone just step up and
claim Team:KDE or should we ask for some relationship with upstream?
Do we just want to assess a proposal? Who does the assesment? Do we
announce this and give time for the community to raise objections or
considerations?<br/><br/>
<br/><br/>
<h3>PPAs</h3>
The general policy for *home* projects is "OSI, nothing illegal and
don't take the piss". We may (or may not) need a more formal one :)
<br/><br/>
Certainly these PPAs offer developers a huge amount of freedom. They
can start by uploading and building a package in a "home" directory
(which can have a structure underneath it for multiple projects). This
will allow them to build against any of the main targets; any
group/community projects or even any other community member home
projects. Oh, and they can use each others code as a baseline
too. Once built the packages are automatically published to a repo on
the community downloads server.
<br/><br/>
AFAIUI this is a lot like the Ubuntu PPA solution (hence the heading).
<br/><br/>
At that point developers can stop if they want. They have a complete
set of repositories (1 per subproject). No painful QA processes for
them and no 'fragmentation' for the MeeGo community. But equally these
repo(s) will needed to be manually added to a device in order for it
to appear in any apt-get/zypper/yum etc. Oh, and the Apps downloader
team really should pay attention here.
<br/><br/>
A huge benefit here is that to for a user to get at a development
version of an application they use a specific repository, not a
mishmash of randomly unstable packages (like the Maemo Extras-devel
area).
<br/><br/>
<h3>MeeGo Targets</h3>
What MeeGo targets do we support?
<br/><br/>
MeeGo 1.0? Really? Does anyone use that?
<br/><br/>
MeeGo 1.1 and above make sense. But what architectures? As released is
fine - but what if there are community rebuilds of non-ssse3?
<br/><br/>
Also, when MeeGo releases distro updates, do we just rebuild all apps?
What happens to QA at this point?
<br/><br/>
<h3>MeeGo Snapshots</h3>
One area to look at is how often we import MeeGo snapshots - and incur
the rebuild cost for any projects targetting them.
<br/><br/>
<br/><br/>
<h3>MeeGo Rebuilds</h3>
Frankly I'm a bit fed up that after a year I can't run MeeGo on my
desktop. It has an AMD phenom chip and an ATI card - both well
supported in the opensource world. It's time to build a community
MeeGo :)
<br/><br/>
Do we need a community version targetting the DublinBook? What about
the O2 Joggler? Are there any policy issues here? Can anyone ask for
this - there's potentially a lot of resource tied up doing this kind
of rebuild.
<br/><br/>
<h3>Surrounds</h3>
What projects are needed in the Surrounds area? Certainly some
unstable->testing->stable cycle makes sense; but this is not likely to
be finalised until the workflow is understood.
<br/><br/>
<h3>Fremantle</h3>
The Fremantle migration. Mmmm. Well it might happen at some point :)
<h1>Actions and Ideas</h1>
<ul>
<li> Establish a task-force/group to coordinate and deliver activity and
to act as a communications hub.
<li> Design and implement OBS project structures and targets for Surrounds,
Apps, Teams and (suggestions for) home areas
<li> Design and communicate process/policy for putting packages into
these projects and migrating them
<li> How do packages move from Community OBS into MeeGo core
<li> Implement and automate stuff
<li> Structure and enrich the outstanding issues outlined above
<li> Design project structures
<li> Work up a proposal which sees MeeGo split into Core and Distro
<li> Copy this list into a Wiki so it's actually useful
</ul>lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com3tag:blogger.com,1999:blog-2839380439558071504.post-9950542334778460482010-08-11T20:14:00.003+01:002010-08-11T20:57:11.753+01:00Are Intel subverting MeeGo.com?Well... there's a "challenging" blog title :)<br />
<br />
Please read on and allow me to explain.<br />
<h2>Intro</h2>So what's making me risk offending one of the powerhouses behind MeeGo?<br />
<br />
<br />
First off, let me say that I think the answer is "No"; but I do think there's a problem and it should be solved.<br />
<br />
<br />
So having hopefully gotten your attention; what's the problem? Well, quelle surprise, it's that inconvenient "openness" again.<br />
<br />
<br />
MeeGo is an open distribution; I don't think that's really in doubt. However there have been many discussions on what makes something open and I'd like to add another: "Inclusiveness".<br />
<br />
<br />
For the record : In the remainder of this post I've included issues that I've seen raised that I may not personally support.<br />
<br />
<br />
<h2>Issue</h2>The question is ... who gets to use the builds that are produced at meego.com? Well, technically "anyone", but practically "only people who've bought recent Intel hardware".<br />
<br />
<br />
Why? Because the MeeGo.com builds are optimised for the Intel Atom processor; not a generic x86.<br />
<br />
<br />
So what's the impact of this?<br />
<br />
<br />
Pros: Less CPU usage for some functions (3D and audio codecs AFAIUI get +20% performance on certain tasks)<br />
<br />
<br />
.... that's it<br />
<br />
<br />
Cons. Well machines with a non-Atom CPU running MeeGo netbook edition may boot up but often fail to run. Additionally non Atom machines can't easily develop for MeeGo (eg the image building app uses ssse3 instructions inside somewhere.)<br />
<br />
<br />
<h2>Impact</h2>If a developer wanders over to look at MeeGo and sees that she needs to buy an Atom netbook to run it then: "Oh, I need special HW to run it? Ubuntu just runs on my laptop. Bye MeeGo, hello Ubuntu."<br />
<br />
<br />
Making it hard to use MeeGo is *not* inclusive.<br />
<br />
<br />
<h2>Details</h2><br />
The way MeeGo is built any binary could contain SSSE3 instructions; however which ones actually do depends on the optimisation flags used, the compiler version and the source code and and a change in any of them can add or remove instructions.<br />
<br />
<br />
Essentially it's "random" - or at least not humanly determinable if a given application will suddenly choke on non-Atom hardware.<br />
<br />
<br />
In irc Thiago scanned the Qt binaries to try and find any SSSE3 instructions. When he ran a quick and dirty analysis he couldn't find any SSSE3 instruction in QtCore and QtWebKit; and found a total of 4 SSSE3 instructions on QtGui - that's many 10s or 100s of Mb of binary code and only a handful of instructions.<br />
<br />
<br />
So given the entirety of Qt uses *4* instructions there was a challenge to the "performance benefit" it offers by using these options "across the board".<br />
<br />
<h2>Postition</h2><br />
Given MeeGo.com is supposed to be open and to minimise barrier to entry this exclusion seems wrong.<br />
<br />
<br />
MeeGo is managed by the Linux Foundation and I was under the impression that we had a Linux Foundation managed build service at build.meego.com; so why are we building for exclusivity and not inclusivity?<br />
<br />
<br />
<h2>Fairness</h2><br />
My understanding of the business model is that Nokia and other vendors would have an internal OBS to allow them to tailor and optimise MeeGo for their commercial product<br />
<br />
<br />
MeeGo's model is that Intel, Nokia and others (as vendors) have their own internal build service (OBS) to optimise for a commercial product so why does Intel get to optimise for Atom on the MeeGo.com build service?<br />
<br />
<br />
Why do we optimise for only Atom machines on the MeeGo.com builder? Why isn't that done on build.meego.intel.com? Is Intel essentially using MeeGo.com to make "the Intel MeeGo" not "the community MeeGo"?<br />
<br />
<br />
Obviously, as a fallback the community OBS is a potential place for this generic build but that was *not* the point. We have often been told that MeeGo *is* the community.<br />
<br />
<br />
<h2>Counters</h2><br />
One point has been of the "cost" of the shared infrastructure and Intel employees having said that Intel should not be burdened with the cost of supporting other arch/platforms/builds.<br />
<br />
<br />
There's some validity to this - and I don't think the community would object in the slightest to seeing optimisations for Atom made available *as well* as a generic build.<br />
<br />
<br />
One question is: Is MeeGo an open and inclusive distro? Who dictates the commercial aspects of the "shared resources" and who gets to dictate what is and is not on the agenda.<br />
<br />
<br />
One argument has been "Intel contributed the hardware and they want it optimised for their platform"; However that's not a community platform; that's a vendor specific build platform.<br />
<br />
<br />
And are we seriously saying that a vendor producing a version of MeeGo for a non-Intel based x86 device is going to have a problem rebuilding with appropriate gcc flags?<br />
<br />
<br />
<h2>Proposal</h2><br />
Add a 'generic x86' target to the MeeGo.com build architectures. This will form the basis for more inclusive MeeGo variants.<br />
<br />
<br />
Allow the builder to create targetted binaries for some hardware; this is going to become a requirement as more hardware appears.<br />
<br />
<br />
As we know: 'optimized for Atom' sells and attracts developers to the platform and a set of development hardware, etc..<br />
<br />
<br />
But surely we can be "optimized for Atom" without excluding non-Atom users.<br />
<br />
<br />
This means anyone with a non-Atom device could at least start MeeGo on eg an AMD desktop. As Arjan says: "I and several of my coworkers run MeeGo to develop MeeGo" "it's still very much intended to be a quite complete *client* PC linux"<br />
<br />
<br />
<a href="http://lists.meego.com/pipermail/meego-dev/2010-April/001318.html">http://lists.meego.com/pipermail/meego-dev/2010-April/001318.html</a><br />
<a href="http://lists.meego.com/pipermail/meego-dev/2010-April/001392.html">http://lists.meego.com/pipermail/meego-dev/2010-April/001392.html</a><br />
<br />
<br />
<h2>Works for everyone</h2>Well, isn't that the job of MeeGo.com?<br />
<br />
<br />
MeeGo.com is supposed to be open and to minimise barrier to entry - lets help it do that<br />
<br />
<br />
<h2>Conclusion</h2>The point is that MeeGo should be doing a generic i586 build<br />
<br />
<br />
Not Intel, MeeGolbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com5tag:blogger.com,1999:blog-2839380439558071504.post-15740760304844174412010-06-16T14:18:00.000+01:002010-06-16T14:18:46.523+01:00Open Letter / Proposal to allow Maemo on the MeeGo Community OBSThis is an open letter to the whole MeeGo community and on behalf of the Maemo development community. The purpose of this letter is to ask the MeeGo community for their permission to bring Maemo build targets (currently Fremantle eventually Harmattan, Diablo, Chinook?) to the MeeGo Community OBS and to ask the Maemo development community for their support in this project.<br />
<br />
*<a href="http://lists.meego.com/pipermail/meego-community/2010-June/001041.html">Please discuss on meego-community mailing list</a>*<br />
<br />
I would like to emphasise that this is a Maemo Community initiative and is not being pushed by Nokia.<br />
<br />
At this point we are not aware of any similar initiatives related to the Moblin community but we would fully support any that arise.<br />
<br />
The Maemo community has built up around Nokia devices which, in many ways, are amongst the most open devices available in their class. There is a passion for openness in the Maemo community and we know that the future for this family of devices lies with MeeGo.<br />
<br />
Many of us are looking forward to MeeGo and are keen to transition as smoothly as possible.<br />
<br />
However our devices are not fully open and developing for them has dependencies on vendor proprietary binaries which would need to be available on the build service. This would mean putting closed binaries on the MeeGo OBS and having a part of the MeeGo Community OBS functionality being 'restricted' to Maemo developers.<br />
<br />
Naturally we recognise and respect that MeeGo is an open source project and there may be ideological issues in allowing closed binaries into the ecosystem (even though they're just for build/linking). We also recognise the risk of "opening the door" to closed binaries and suggest that this arrangement could be agreed as a one-time "grandfathering in" (http://en.wikipedia.org/wiki/Grandfather_clause) situation for the Maemo community.<br />
<br />
However we also feel that the benefits of supporting a smooth transition for the vibrant Maemo development community would be worthwhile both for MeeGo and Maemo:<br />
<br />
<ul><li>developers would be able to use the OBS' natural ability to target Fremantle, Harmattan and MeeGo from a single location. This would bring more developers and their applications to MeeGo sooner. </li>
<li>many of the same people in the Maemo and MeeGo community teams look after the Maemo Autobuilder and the MeeGo application OBS. Our limited volunteer time would be used more effectively on a single platform instance.</li>
<li>resources earmarked for Maemo could be added to the MeeGo estate and would naturally be used at peak efficiency as Maemo demand decreases and MeeGo demand rises.</li>
<li>new Maemo community Quality Assurance processes would evolve around the shared OBS and could assist the development of MeeGo QA processes.</li>
</ul><br />
and perhaps most important of all:<br />
<br />
<ul><li>users of existing devices could expect a significantly longer maintainable life from products built on a consolidated build service and could look forward to their applications being available on MeeGo as soon as devices become available.</li>
</ul><br />
The maemo.org buildservice already has a 'proof of concept' instance of the OBS which allows the Fremantle target to co-exist with a MeeGo target and we already intend to use this as a basis for the MeeGo community OBS.<br />
<br />
The proposed solution *must* allow MeeGo community users to use the MeeGo Community OBS without any reference to Nokia closed binaries; this facet of the service should be entirely optional.<br />
<br />
Equally the legal issues around the closed binaries require an EULA related to demonstrated possession of a relevant device. This can be handled in a similar manner to the Maemo Autobuilder service; ie registration of a serial# to a developer account.<br />
<br />
The proposal therefore is:<br />
<br />
<ul><li>To provide the closed binaries as a build-target repository (probably DoD for those who know and care) on the community OBS.</li>
<li>To grant ACL based access to this repository based on acceptance of an EULA</li>
<li>To *not* require any such EULA for 'MeeGo-only' accounts on the service</li>
</ul><br />
I've run this by Tero Kejo in Nokia and he's very supportive of the idea.<br />
<br />
From:<br />
<br />
David Greaves / lbt<br />
Community Member and build systems guy.<br />
Niels Breet / X-Fade<br />
maemo.org webmaster and autobuild owner <br />
Carsten Munk / Stskeeps<br />
maemo.org distmaster<br />
Andrew Flegg / Jaffa<br />
on behalf of the Maemo Community Councillbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com3tag:blogger.com,1999:blog-2839380439558071504.post-68020224950478396982010-05-23T22:54:00.000+01:002010-05-23T22:54:34.907+01:00I like crashes like that...So I'm ssh'ed into my kerberos kdc server and at the same time I'm playing with nfsv4 and I clearly push the boundary somewhere and my NFS server has a kernel BUG and goes wibbly... ctrl-alt-sysreq S-U-B wibbly...<br />
<br />
Now the kerberos kdc is a VM on the nfs server; which also holds the home directory for my desktop. So my desktop hangs hard.... toast.<br />
<br />
I wander over to the nfs server and shut it down as best I can and reboot it.<br />
<br />
It comes back... and as it does my desktop wanders into life, my ssh session to the VM is still active; nothing happened.<br />
<br />
I like crashes like that :)lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-68589314870175904752010-05-22T22:00:00.000+01:002010-05-22T22:00:21.606+01:00Kerberos and sshSo you're setting up Kerberos and you've got a ticket with kinit<br />
<br />
the target has a host/<dns name>@REALM<br />
<br />
but ssh fails with:<br />
<pre>debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
</pre><br />
Well the first thing to realise is that you're probably not using gssapi-keyex, you're probably using gssapi-with-mic (see http://www.ietf.org/rfc/rfc4462.txt if you want to know more).<br />
<br />
Running:<br />
<pre>/usr/bin/sshd -D -ddd -e
</pre>may give<br />
<pre>debug2: input_userauth_request: try method gssapi-with-mic
debug3: mm_request_send entering: type 38
debug3: mm_request_receive_expect entering: type 39
debug3: mm_request_receive entering
debug3: monitor_read: checking request 38
debug1: Unspecified GSS failure. Minor code may provide more information
Key table entry not found
</pre><br />
The problem I has was a typical one in kerberos setups... DNS and name resolution has to work.<br />
In this case a simple entry in the hosts file with a non-fqdn and there are very few clues.<br />
<br />
So maybe you'll google some of that and it'll help... :)lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-70378510339070066322010-05-16T11:38:00.000+01:002010-05-16T11:38:03.487+01:00OBS and Fremantle ... huge success :) and HELP!!!!As you may know I recently volunteered to setup a community OBS in my "spare time" (hah, right!). This is a progress report because I've reached a significant milestone... the following 193 applications have been built from 'Extras' most on both ARM and X86:<br />
<br />
<span style="font-size: small;"><blockquote>accdisplay, acl, actman, adblock-plus-1.0, adflashblock-css, alienblaster, anarchism, attitude, attr, audiofile, avahi, battery-eye, belltower, blubbels, bluetooth-dun, bluezwitch, brainparty-data, burgerspace, catorise, clutter, clutter-gtk, copernicium, crimson, currencyconverter, datetoday-home-widget, dbus-python, de-lite, dialcentral, doom-wad-shareware, easy-deb-chroot, easypark, ejpi, fapn, feedingit, feedparser, flac, flatzebra, fm-boost, fmradio, freecell4maemo, fschedule, fuse, gboggle, glibmm2.4, glogarchive, gnome-python, gonvert, goocanvas, gpe-icons, gpodder-icon-theme, greekiradio, gst-plugins-good0.10-flv, gst-plugins-good0.10-mkv, gst-plugins-good0.10-ogg, gst0.10-python, gstreamer0.10-ffmpeg, gtk+extra2, gweled, headphoned, healthcheck, hex-a-hop, host, irssi, jamaendo, json-glib, kernel-power-settings, libart-lgpl, libcap, libdaemon, libevent, libffi, libgnomecanvas, libgnomeprint, libgtkhtml2, libliqbase, libmad, libmicrofeed, libmodplug, libraw-lite, librsvg, libsidplay, libsigc++-2.0, libsoup2.26-1, libxinerama, liqflow, lirc, lybniz, lzma, lzo2, madbomber, maemo-optify, mafw-lastfm, mancala, mastory, masudoku, mauku, mclock, meanwhile, mediabox, microfeed, microfeed-providers-unstable, microfeed-utils, milkyway-wallpaper, mirror, mplayer, mspede, mutagen, mygpoclient, n900-fmrx-enabler, n900fly, nako, ncalc, nmap, notify-python, omweather, openvpn, openvpn-applet, panucci, pedometerhomewidget, pexpect, polipo, poppler, proximityd, pycairo, pycurl, pygame, pygobject, pygtk, pygtkeditor, pyinotify, pymaemo-optify, pypianobar, pyrecipe, python-central, python-dbus, python-evolution, python-facebook, python-gdata, python-gtkhtml2, python-imaging, python-location, python-numeric, python-support, python-twitter, python-xml, python-ystockquote, qtsixa, quickbrownfox, quicknote, recaller, reflect, rfk, rmz-helsinki-wallpaper, rmz-senaatintori-wallpaper, rootsh, rsync, sdl-net1.2, sdl-ttf2.0, sdlgfx, sdlpango, sense, sgt-puzzles, shortcutd, sip4, sleeper, solarwolf, sopwith, sqlite, ssh-status, stockthis, storageusage, supertux-stable, systeminfowidget, tar, tennix, thai-ttf, tickstill, tor, touchsearch, tsocks, uqm-3do-data, uqm-data, uremote, ussd-common, ussd-widget, vim, vor, vultures, wget, witter, worldtv99, xkblayouts-rx51-ru, zoutube</blockquote></span><br />
There are a lot that don't build but I think we're at the point where I need help from some experts and it's time to open the beta service up to early adopters. You can see what I've done <a href="http://wiki.maemo.org/OpenSuse_Build_Service/Fremantle_Setup">to setup Fremantle on the OBS</a>.<br />
<br />
<span style="font-size: large;">As I said </span><span style="font-size: x-large;">HELP</span><br />
I now need to fix build issues like:<br />
<pre>installing hildon-update-category-database
/usr/bin/hildon-update-category-database: I don't have write permission on /usr/share/mime.
Try rerunning me as root.
dpkg: error processing hildon-update-category-database (--install):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
hildon-update-category-database
exit ...
</pre>which blocks a large number of applications<br />
<br />
and package specific ones like this in libogg:<br />
<pre>automake: configure.in: installing `./mkinstalldirs'
Makefile.am:3: require version 1.6, but have 1.4-p6
include/ogg/Makefile.am:6: invalid variable `nodist_ogginclude_HEADERS'
autoreconf: automake failed with exit status: 1
make: *** [configure-stamp] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
</pre><br />
I can fix almost all of them myself but that's not the point - we need a team to make this work. Please get in touch and help.lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com1tag:blogger.com,1999:blog-2839380439558071504.post-82618045813864153162010-05-16T10:28:00.000+01:002010-05-16T10:28:02.468+01:00Community Building for Maemo and MeeGo - What does the OBS *Do*?In a closed environment you use what's in the SDK and you get your own little space; talking to others is discouraged and sharing and re-use outside the blessed area is frowned upon. This dictatorial style has the advantage of making life easier for the vendor. In an open world we have more interactions... and as students of networks know: increased connectivity brings increased complexity as well as increased benefits. So this is an initial proposal for the organisation of OBS build projects and packages to support a QA process into an app-store / Extras or garage-like environment. I'll introduce some basic OBS concepts and then describe how this might work. I would like this to raise awareness of some potential complexities that we may face and get some thoughts on how to deal with them. ...... Oh, and this is about both Maemo and MeeGo.<br />
<br />
<span style="font-size: large;">First an OBS Intro</span><br />
<ol><li> It's a build system (fully local) and a build service (like the autobuilder).<br />
</li>
<li> You put source into it and say "use this repository" and it spits binary packages out.<br />
</li>
<li> It builds a minimal and "clean" SDK using the repository you told it to use<br />
</li>
<li> It has packages - a package corresponds to a tarball and a spec/dsc<br />
</li>
<li> It has projects - a project is like a directory with packages<br />
</li>
<li> Packages are 'published' into a corresponding repository (which can be shared with others)<br />
</li>
<li> The published repositories can also be used by devices to download binary packages.<br />
</li>
</ol><br />
There is a lot more to it; scheduling, dependency based building, multiple architecture support, home projects, package signing...<br />
<br />
The 'trick' then, is to set up a structure of projects that we can use to support the publishing and sharing activities that we need.<br />
<br />
<span style="font-size: large;">So What are our Goals?</span><br />
We want:<br />
<ul><li> to allow freedom for developers to develop;<br />
</li>
<li> to provide a great build service and SDK<br />
</li>
<li> to work with the core distro as much as possible<br />
</li>
<li> to provide excellent quality assured applications for our "app store";<br />
</li>
<li> and for MeeGo, to extend the core distro with a community supported area for libraries and packages that are depended upon by more than one application. <br />
</li>
</ul><br />
<span style="font-size: large;">First thing we get: Individual Homes and PPAs</span><br />
You'll start by uploading and building a package in your "home" directory (which can have a structure underneath it for multiple projects). This will allow you to build against any of the main distros; any group/community projects or even any other community member home projects. Oh, and they can use your code as a baseline too. Once built your code is automatically published to a repo on the<br />
community downloads server.<br />
<br />
This is a lot like the Ubuntu PPA solution.<br />
<br />
At that point you can stop if you want. You have a complete set of repositories (1/subproject). No painful QA processes. No 'fragmentation'. But equally your repo(s) will needed to be manually added to a device in order for it to appear in any apt-get/zypper/yum etc.<br />
<br />
A huge benefit here is that to get at a development version of an application you use a specific repository, not a mishmash of randomly unstable packages like Extras-devel.<br />
<br />
<span style="font-size: large;">For the pros: Community QA'ed Repository - Extras</span><br />
If you'd like your application to appear in the Extras repo which is pre-installed on devices then you can submit to the QA process.<br />
<br />
First you register for the package name, then submit your code to the distro promoter; there it is QA checked, copied to Extras:Testing, built, QA'ed again and becomes available in the Testing repository.<br />
<br />
<here be dragons> The community testers then approve your code. </dragons><br />
<br />
(I know that's a contentious point - and I don't have an answer. I do however have confidence that we can solve the problem through collaboration and co-operation.)<br />
<br />
Once approved the code is copied to the Extras:Stable repository for publication.<br />
<br />
<span style="font-size: large;">Conclusion</span><br />
<br />
Much of this text is online at: <br />
<a href="http://wiki.maemo.org/OpenSuse_Build_Service">http://wiki.maemo.org/OpenSuse_Build_Service</a><br />
(I really hate it when things get locked up in blog posts and forums)<br />
<br />
How can you help?<br />
<br />
Some tasks needed to get the OBS running:<br />
<ul><li> OBS Installation - a detailed guide on how the system was setup.<br />
</li>
<li> Application QA Process on the OBS - a proposal<br />
</li>
<li> Setting up Fremantle - WIP - post to follow<br />
</li>
<li> Fixing the Fremantle SDK - mmmm<br />
</li>
<li> Setting up cross-building - started, not imported yet<br />
</li>
<li> An OBS Autobuilder queue - not started<br />
</li>
<li> Reporting - not started <br />
</li>
</ul><br />
Also see:<br />
<ul><li> <a href="http://wiki.meego.com/Proposal_for_Community_Application_Support">http://wiki.meego.com/Proposal_for_Community_Application_Support</a><br />
</li>
<li> <a href="http://wiki.meego.com/Proposal_for_a_Repository_working_group">http://wiki.meego.com/Proposal_for_a_Repository_working_group</a><br />
</li>
</ul>lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-80137833313897232982010-05-07T18:20:00.003+01:002010-05-07T18:27:08.610+01:00It was the Dawn of the 3rd Age......and not only is the Shadow War over but it looks like we <span style="font-size: small;"><b>will</b></span> have a community OBS thanks to the team formerly known as maemo.org infrastructure :)<br />
<br />
I'm really excited as I see this as a way for the Maemo and Moblin development communities to transition smoothly into a MeeGo future; we should eventually be able to offer an easy way to build applications for Fremantle, Harmattan, MeeGo and future device OSes too.<br />
<span style="font-size: large;"><br />
</span><br />
<span style="font-size: large;">So what's happened?</span><br />
<br />
A while ago the <a href="http://wiki.meego.com/Proposal_for_a_Repository_working_group">RWG proposal</a> was begun and we've been pushing it ever since. Tero, Mike, Neils and others have been working on the <a href="http://wiki.meego.com/Proposal_for_Community_Application_Support">CAT proposal</a> as well as the RWG. We got together on irc and had a chat about the scope and how to proceed.<br />
<br />
Last week <a href="http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-05-05-18.58.html">the TSG agreed</a> we need something (kinda!) - so we decided that we'd go ahead and do it.<br />
<br />
We now (thanks to Tero & Nokia?) have a test machine behind a firewall and I've setup an OBS (<a href="http://wiki.maemo.org/OpenSuse_Build_Service/Installation">more than you ever wanted to know... but you said to work in the open, right?</a>) to prototype how we'd deploy it for community use. This has a link to the MeeGo OBS and successfully builds MeeGo packages.<br />
<br />
<span style="font-size: large;">Where are we going?</span><br />
<br />
I don't know yet; but here's what I'm proposing (my ideas tempered with some input from others):<br />
<br />
Initially we should offer a MeeGo OBS and a Maemo OBS. There are corporate issues around this and whilst my personal aim is a single build system able to build debs and rpms against any M[aemG]*o distro, that isn't the first step.<br />
<br />
The MeeGo OBS will probably offer home directories and a way to build against the MeeGo weekly snapshots. We may be able to offer a 'live' feed if some OBS bugs are resolved and we have the build resources.<br />
<br />
The Maemo OBS will provide an alternative to the autobuilder for Fremantle and, eventually, for Harmattan. This makes sense as our longer term future with MeeGo is clearly the OBS.<br />
<br />
One thing I dread is having to go to each device vendor's build system to make build my app for their community app store; so maybe off into the future we'll even provide a neutral place where we can support multiple vendors: a single build system that can build community MeeGo apps for devices from any vendor that participate.<br />
<br />
Another area of interest to me is something I call "Surrounds" (yes, Quim, I know... it needs work). This isn't my idea... lots of software products and distros have it. It's that chaotic area around a product where 'outsiders' or community people contribute their "unsupported" bits and pieces. Actually this deserves a post on its own. Anyhow, I think the OBS will make managing this a lot easier for the community.<br />
<br />
<span style="font-size: large;">There is still a lot to do...</span><br />
<br />
We've asked a few community devs to join (and please come and talk to us if you feel you can help - bear in mind that we need documentation and build system process experience more than development skills).<br />
<br />
A big task is the setup of an OBS build system for Fremantle. I managed to get this 80% done a while ago so that work needs digging up and finishing off. Once that's done we will need a lot of help validating all the Extras apps.<br />
<br />
Yet more work is required on my cross-compilation system used by the OBS. That was deployed for Mer and we need to redeploy it for Fremantle too.<br />
<br />
There is work on reporting systems and QA automation systems going on that we can re-use which will help in transforming the autobuilder promotion type processes and figuring out what is and isn't needed in the OBS world.<br />
<br />
Speaking of which ... do we take this opportunity to tweak the Extras promotion policy?<br />
I think we need something like the Devel->Testing->Stable process for Maemo apps - but maybe we should be working with the CAT guys to figure this one out?<br />
<br />
Finally please don't ask me when you'll get to use it, we don't have a schedule yet :(<br />
<br />
However, do feel free to ask me what we're working on or what we've done or what you can help with.lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-13587513618412302842009-12-22T12:30:00.000+00:002009-12-22T12:30:32.178+00:00N900 and Mozilla on the BBCHere's the <a href="http://news.bbc.co.uk/1/hi/technology/8425906.stm">BBC Technology story</a> it's good that the N900 is being seen as an open system at this level.<br />
<br />
snippets:<br />
<blockquote>The browser, codenamed Fennec, will initially be available for Nokia's N900 phone, followed by other handsets. <br />
</blockquote> and<br />
<blockquote> Apple is very restrictive. It doesn't allow other browsers.<br />
</blockquote>which is all promoting the core values the community loves about Maemo...lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-12719907308658028022009-11-06T23:51:00.000+00:002009-11-06T23:51:50.555+00:00Android... 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.<br />
<blockquote>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! <br />
</blockquote> <a href="http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=get&target=Mythbusters_Android.pdf">The slides</a><br />
<br />
As usual the <a href="http://lwn.net/Articles/360343/">commentary</a> at LWN raises some interesting counters.lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com4tag:blogger.com,1999:blog-2839380439558071504.post-72644653325763793962009-10-27T12:51:00.000+00:002009-10-27T12:51:20.225+00:00Ovi Maps... Really? Is this the best we can do?I got caught in a nasty traffic jam tonight just a few miles from home.<br />
<br />
There was a road that I've never been down - windy country lanes, right general direction...<br />
<br />
I grin and whip out my N900 and give it to my wife to navigate us - just the ticket?<br />
<br />
No.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 <span style="font-size: large;">I would want my money back </span>- and as someone who has breathed Maemo for almost a year now, that makes me very, very sad.<br />
<br />
<a href="http://www.flickr.com/photos/96141280@N00/4048158716/" title="Ovi Maps is Crap by davidmg, on Flickr"><img alt="Ovi Maps is Crap" height="376" src="http://farm3.static.flickr.com/2464/4048158716_49c82da6be.jpg" width="500" /></a>lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com17tag:blogger.com,1999:blog-2839380439558071504.post-68409825494664795802009-10-12T18:54:00.000+01:002009-10-12T18:54:12.595+01:00Maemo 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.<p>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.<p>Inevitably there will be a significant amount of interest and concern about how this affects the open nature of the Maemo platform.<br />
<br />
I'd like to highlight that there is a specific boot-path <b>designed in</b> 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.<br />
<br />
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.<br />
<br />
We certainly <b>need</b> more security. Right now when I download an application from Extras-Devel it can do <b>anything</b> 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 <style type="text/css">
p, li { white-space: pre-
</style>perpetrate fraud. I'd <b>like</b> 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.<br />
<br />
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.<br />
<br />
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).<br />
<br />
So,I have started a <a href="http://wiki.maemo.org/MaemoSecurity">Maemo Security</a> page on the wiki which I hope can capture community questions (and, eventually I hope, Nokia's answers) about these issues.<br />
<br />
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.<br />
<br />
I suggest we initially add questions to the <a class="new" href="http://wiki.maemo.org/Talk:MaemoSecurity" title="Talk:MaemoSecurity discussion">Maemo Security discussion</a> 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.<br />
<br />
I'll wrap up with a plea - <span style="font-size: large;">please don't over-react</span> - 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!<br />
<br />
PS The Summit was brilliant!lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com0tag:blogger.com,1999:blog-2839380439558071504.post-54201659320046411422009-10-06T23:22:00.001+01:002009-10-06T23:39:43.087+01:00Important Summit AnnouncementWell, 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.<br />
<br />
More details here: <br />
http://wiki.maemo.org/Maemo_Summit_2009/Schedule<br />
<br />
Meet up at 19:00 (so after early registration closes).<br />
<br />
There will be free beer available<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
if someone offers to buy it ;)lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com1tag:blogger.com,1999:blog-2839380439558071504.post-74543256235658247042009-09-21T09:54:00.000+01:002009-09-21T09:54:36.281+01:00Want to PUSH... need a kickstart?So one problem with the <a href="http://blogs.nokia.com/pushn900/">PUSH</a> 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...<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://www.velleman.eu/images/products/0/k8055.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="150" src="http://www.velleman.eu/images/products/0/k8055.jpg" width="200" /></a><br />
</div>A few years ago I bought a couple of these boards for about £25.<br />
<br />
They provide: <br />
<ul><li><span id="Description">5 digital input channels</span></li>
<li><span id="Description">8 digital output channels</span></li>
<li><span id="Description">2 analogue inputs</span></li>
<li><span id="Description">2</span><span id="Description"> analogue outputs (8 bit resolution)</span><span id="Description"> <br />
</span></li>
</ul><span id="Description"> You can also have up to 4 of these plugged in via a usb hub</span><span id="Description">.</span><br />
<br />
<span id="Description">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</span><span id="Description"> libvelleman from garage, plug in a board and PUSH :) </span><br />
<span id="Description"><br />
</span><br />
<span id="Description">As you can see the test program implements K.I.T.T. for you...<br />
</span><br />
<br />
<object height="344" width="425"><param name="movie" value="http://www.youtube.com/v/xPXyES0-9-Q&hl=en&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/xPXyES0-9-Q&hl=en&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><br />
<br />
So now all we need is someone with an N900 to help me test it...<br />
<br />
(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....)lbthttp://www.blogger.com/profile/11594429320228093113noreply@blogger.com3