Tizen conference, wrapping up

The Linux Foundation sponsored me to travel to and attend the Tizen Conference 2012 in San Francisco and as part of this sponsorship, I'll be blogging about the conference and my insights and thoughts of the talks and keynotes at it. This is my last post in a two-parter about the conference.

When attending a conference, or a music festival, or any other event with multiple tracks, there will always be sessions that you for some reason do not end up attending, be it because of meeting somebody suddenly at the coffee table while a session you'd like to see is about to start, or because there's a session that you'd rather see, or simply because you decided to take a break. The solution to this is the conference recording the sessions on video, which is not often performed very well.

I've encountered the usual screw-ups in conferences: session recording that does not include the slides at all, session recording where the A/V people forgot to wire up the microphone to the recording equipment(!), or so bad audio that you couldn't even hear the speaker. It's also more difficult, when viewing the session afterwards, to having to focus on three things - the movements of the speaker, his/her voice and the slide content.

That's why I welcome a better format, which is what the Tizen conference will be utilizing it seems - recording the speaker audio and along with that, the slide content, but not the speaker him/herself. And exporting it in podcast format, allowing you to catch up while on the move on the newest technology. Without having to dedicate your full attention to it.

Which brings me to that I didn't participate in that many sessions during the last day. But I got to attend the ones that mattered to me the most: Open Build Service—Facts, Features and Future, by adrianS and mls from openSUSE and Next Gen OS Initialization Done Right, by Auke Kok. And missed out on Tizen IVI architecture with Mikko Ylinen.

Meeting the OBS guys is always a pleasure - you get to sync on what their ideas and plans are and they listen to what your expectations and sometimes crazy ideas are. Compared to many other distribution build systems, OBS does not only function or serve their own community (openSUSE) -  it is entirely usable, deployable and fantastic for building other distributions. OBS has leveled the amount of infrastructure you previously needed in other to run/roll your own distribution. And that's why we love it in Mer. It enables anyone with a minimum of OBS knowledge to maintain their own customized distribution. And for ISVs, to build against your distribution. 

As with most technical discussions - the hallway track is the most interesting. The questions and concerns the audience comes up with during the session seeds the ground for the continued discussion in the hallway afterwards. One concern, that was raised by Dominique Le Foll, of Intel OTC was that OBS-to-OBS links are simply too fragile and too often causes build stalls and problems, was actually a matter we approached at first with Mer too, given the very unstable nature of the meego.com API - we needed a way to synchronize and access the OBS projects MeeGo consisted of, offline. Their need was simply needing a way to export MeeGo (well, now Tizen) releases to customers in a reliable manner and allowing them to modify it too.

What we invented there was a piece of software called FakeOBS (now Mer Delivery System) which, to make a long story short, serves up a HTTP/REST interface that is similar enough to the OBS-to-OBS protocol as to make it able to have another OBS connect to it and it thinking it's a remote OBS. 

While in fact, it is a cache of sorts - we extracted through the OBS API the entire OBS project history of sources, built binaries and put it into a on-disk format that FakeOBS could then use to provide those over the OBS-to-OBS protocol, giving us effectively offline access - leaving us able to not have to care about external entities. You can view the latest iteration of it here. There's also a file called 'gitmer.py' which is how we deal with the git-based approach that Mer uses, for sources.

When we generate Mer releases, we do not only export the built binaries, we also export this on-disk format for FakeOBS, allowing anyone to re-create Mer and re-build it in their own OBS, along with the additional use case that we have built OBS package repositories for ISVs to build against. Meaning that even if Merproject.org shuts down, anybody can resurrect the project. As well as that vendors do not have to rely on merproject.org being up.

Next session was Auke Kok's systemd session. Auke's one of my personal open source heroes, always working on quite interesting things. As some of you might know, the traditional way that most UIs are launching applications and daemons on boot are through D-Bus and /etc/xdg/autostart .desktop files. In Mer and MeeGo, this was accomplished with uxlaunch (another of Auke's inventions)

But what if you could use the same flexibility that systemd offers you, in order to create a proper dependency tree for proper optimized booting within the user session? Well, guess what Auke invented :) 

Instead of starting uxlaunch, you'd instead start systemd --user as a user, which would properly start up X, perhaps services that do not need X before X starts,  and ability to indicate session-internal dependencies. Which leads to amazing results. You can check out the systemd discussion on this mailing list thread. 

Another thing that happened was the availability to all conference attendees (except for Intel & Samsung, it seems) of a Tizen reference device, the so-called Lunchbox. It's an amazing piece of hardware, 1280x720 AMOLED display, 4.3", with dual-core Samsung Exonys 4210, Cortex-A9, 1gb ram, 16gb eMMC, microSD slot, sim slot (though modem ability is unknown), Mali GFX chipset, u-boot boot loader, 8mp back camera, 1mp front camera, PN544 NFC chip (unsure how to use), GPS chip, WLAN (WiFi Direct possible).. so, a quite nice kit. And a possible replacement for the N800 as well.

And if you're wondering if we've tried to put Mer on it. Now, of course we have. We've found most interesting pieces, including a "Boot to SD card" mode (with no success just yet - press power key, volume up and volume down at same time), kernel source code (2.6.36) and investigated the system which uses currently Xorg 1.9.3 with a Xorg driver we can't find source for yet. But it'd surprise me if it wasn't somehow similar to the Mali Xorg driver. Once we've figured out SD card boot, it should be a breeze to run Mer on there. Even with X11-GLESv2 acceleration.

That's all I have to say about the conference, will look forward to the next one.

Tizen Conference 2012, first days

The Linux Foundation sponsored me to travel to and attend the Tizen Conference 2012 in San Francisco and as part of this sponsorship, I'll be blogging about the conference and my insights and thoughts of the talks and keynotes at it. While some parts may seem negative, please keep reading as I have a point with those parts that is illustrated later on.

While some people might think that I see Mer as a competitor to Tizen, or think that I don't like Tizen, in fact, I see the benefit of Tizen for the entire open source community that they're pushing a proper, fast and working, standards compliant web runtime for Linux based devices. And I hope we'll see people putting this on top of Mer. Mer plays a different game than Tizen and hence not a competitor - it's a solid mobile core that everybody can build on and most importantly, rely on despite the moods of corporate giants, to make their devices - where solid delivery, ability to productise and code is king.

There's always a challenge in how to properly launch a commercial open source project. Especially in mobile Linux, there is unnecessary high media and developer expectations to the features and ability of a mobile handset stack that often enough causes mobile OS projects to break their necks and die.

But Rome wasn't built in a day. And so weren't the mobile stacks you see around the today - Android took over 3 years to get to a remotely functioning stack. And this has a tendency to make mobile OS developers develop in 'closed mode' in order to launch properly on day one.

Tizen has drawn a lot of crap from their complete silence and secret cathedral building behaviour up to 1.0 release. But I can say that if I was in their shoes, having to launch a handset device .. and handset stack. I would probably end up doing the same things as they had. In a world where you will see your semi-ugly alpha release screenshots laughed at in news articles about your 1.0 launch, when you have a perfectly working and very shiny final release that nobody seems to bother to even check out, it's hard to argue for transparent development from day zero.

Luckily I'm not in their shoes and I can concentrate on technical core side of things and make it easier for people to make exciting new devices. I'm not a fan of whole-stack projects - for the reasons listed above. And that's why Mer doesn't contain UIs and hardware adaptations - we let people base and develop on a sane core that we can maintain the openness of, while people work on exciting new devices and UIs in seperate projects from the Mer project.

Reputation and history matters a lot as well - There was a lot of disappointment in the demise of MeeGo and the messaging on MeeGo site was that Tizen was the new direction. And people expected there'd be some kind of relation. But there's not - Tizen, at least the handset side (IVI is more related on the Core side), is so very different from anything you knew in MeeGo - your employees would need complete retraining to work with it. The stack is based off Samsung Linux Platform and actually says it's that, when booting up, last I saw. That should lead to interesting discussions with your company lawyers.

And with reputation and history in mind - many from MeeGo remember last years keynote, Monday Morning with MeeGo.. February 11 had happened months before and there was still a fighting spirit in the community, we needed people who were showing passion in their work, the same fighting spirit. And we got something that was closer to Monday Mourning with MeeGo. Which left many people depressed and unimpressed. A talk that spoke more about the fantastic deployments of the platforms that MeeGo was in practical competition with, than about MeeGo itself and it's qualities and achievements.

When a last moment change in the Tizen conference schedule came in, that moved the first keynote which was supposed to be Imad from Intel and JD from Samsung to the morning after and instead, we got a recycled keynote, void of genuine and documented passion for Tizen, with the same recycled material as in the Monday Morning with MeeGo talk and the same speaker as last year - with him even talking about that if people had noticed he would be on schedule, there'd probably be fewer in the room. I was left unimpressed and depressed, again.

I'm ashamed to say it, but I've grown to appreciate the famous "Developers! Developers! Developers!" dance. Somebody showing passion for their work - people who truly believe in their product and their stack. Someone who wants to stirr excitement in developers, CTOs and platform integrators alike. And I harbour a lot of respect for people who truly believe in what they do and that they want to do a good product and good software.

And we got that in the morning after keynote, Imad, the head of Intel OTC and JD, EVP of Samsung, the Tizen technical steering group. They showed their excitement about what they were doing, showing excellent live demos and they understood the challenges in presenting a mobile OS and explained to depth both the challenges and reasoning behind their choices for the Tizen stack - even the controversial ones. I can recommend watching the video when it gets put online.

This is what the first keynote of the conference should have been like. And I was more excited again.

The second keynote, from Tizen Association was interesting, showing the need of operators to provide and control content and the benefit of having to write to one platform (HTML5). Which is funny, when there were also talks about "The web always wins" .. that in practice, the walled garden never wins, the properitary standards will not either. That content from outside the walled garden will always be more interesting and varied than your own content. Doesn't anybody remember AOL? :)

I might be an idealist, but I have difficulty seeing the word 'open' together with the working method of the Tizen Association. When their terms of membership states at http://www.tizenassociation.org/en/tizen-association/board-of-directors
that there is an annual due of membership of Two Hundred and Twenty Thousand USD. And talking about confidentiality clauses.

But I was reminded of a quote from my former boss, Harri Hakulinen, from his MeeGo blog, speaking of Nokia's choice of WP7: "... What I had witnessed from the side, thanks to Sami J. Mäkinen, was of course the birth of Linux. And, in so many ways, I feel that we have now "replayed" the same with MeeGo in last 12 months.
Co-incidentally, at that time I had a summer job where we replaced some ancient Nixdorf and IBM mainframes with another new OS, called Windows NT. It was hard to explain to Sami and others, that from the point of view of those companies I worked for, Windows NT was, in fact, like "open environment", compared to those things that they had been using before."

And perhaps this is how it's like with Tizen. That compared to how it has been before, this is actually more open than the previous situation for the ecosystem. At least the code is open, actively developed, looking to be intended to be developed in the open, not only codedrops, with a proper code submission process. So perhaps that's an improvement on top of what we have had with Symbian and Android.

What I am more encouraged by in terms of openness, is what I learned in the Tizen Architecture talks, where there is a strong push towards that there will actually be as little Tizen specific WebAPIs as possible. That there's an active desire to use W3C standards where possible and to submit APIs to the standards process. Which makes me hope that for the parts that really matters - the developer facing APIs, that there will no vendor lock down. In the end, the winner would be the Web. And even if Tizen did go away one day, that the code would be living on. Just like MeeGo's code has. Because it's open source.

From an entirely architectural point of view, Tizen architecture (SLP-based) has a lot of NIH in it - it's own telephony stack instead of oFono (though I hear that's coming), and a lot of self-made libraries and methods. Which may impact the portability of the web runtime.

I'm hoping that Tizen will realize the importance of separating the web runtime from OS stack. That one of the reasons that the web standards have developed so fast, has been the ability to get many people to upgrade their browsers over the air.

We probably cannot assume we'll see Tizen 1.0 to Tizen 2.0 upgrades on our handsets - aftermarket hardware adaptation is really hard.  But we should make sure that at least for a few generations, we can keep on delivering the web runtime to older devices. To foster a standards compliant and secure web runtime for our apps - just like the browsers has fostered it for the web. And I think this is one area Tizen could potentially be very agile in, comparing to other platforms.

The last talk of the day was on Tizen security - Ryan Ware was presenting along with his Samsung counterpart, where compared to many other platforms, the focus has been to ensure end-user privacy, and not on the need to protect content owner content. That's the right direction - especially in a world where devices are turning very promiscuous and interacting in sometimes unsafe manners with other devices.

One of the most important parts of a conference is not so much the presentations, but the people there and the discussions in the hallway - the 'hallway track'. This is a concept that any conferences doesn't always understand - the importance that people can discuss outside the conference rooms. Tizen conference has as usual done a great job on this (thanks to Amy Leeland's fantastic work), providing good space and hacker lounges with whiteboards for people to properly discuss. I've sat down together with many key people in my line of work and had intellectual discussions about the challenges we meet. And I've gotten to know more people that I previously didn't.

And of course - when working on a distributed-across-the-world project, I've been able to go out and have our traditional icecream shop visit (since 2009) with the rest of the participants of my project. So far it has been a good conference, looking forward to be seeing more presentations today.