| Tools | |
| Short link http://www.qaiku.com/go/6oj9/ | |
|
|
Daniel Frye: 10+ years of Linux at IBM. Linux timeline:
IBM mission:
The Internet bubble in late 90s was what made Open Source happen... less risk-averse culture, need for rapid, shared innovation and a level playing field.
IBM's Linux strategy started in 1998 as a Fellow excercise of figuring out what would happen with it. Conclusion: question was just how fast it would grow. Concerns included the sustainability of the Open Source community, the ability to actually deliver releases, defensibility of GPL.
In 2001 IBM invested $1B in Linux. Remarkable risk on technology they didn't control. But it payed off.
IBM's lessons:
Join somebody else's community. It is a lot easier than to launch your own community.
Instead of recruiting from upstream communities, IBM hired from outside and trained people to become contributors. That added to the communities instead of just reprioritizing them.
Code drops don't work. Instead, propose goals early and work out in the open. Deliver via incremental change.
Solutions have to be general enough to fit the needs of the whole upstream community, not just for the particular use case of one company. If the plan is announced and discussed early, then the community will be able to help in generalizing it. But still, ensure your itch gets scratched.
If you engage actively with the community you will be able to influence it. Meaningful contributions are power in an Open Source community. And you need to be in it for the long, sustainable run. In the community the web of trust is everything.
You have to be on the IRC and mailing list, participate in the discussions.
Don't be hung up on whose code gets used as long as the project delivers the results.
Panel: Does Open Source mean Open Cloud? Red Hat, Sonoa, Cisco, IBM. Issue is that Open Source runs much of the cloud infrastructure, but on cloud they don't guarantee the same freedoms as in more traditional software environments. Open Source fuels the cloud, but does the cloud fuel Open Source?
With cloud the key is data, and the context of data. If you take your data out from Facebook, most of it would be meaningless without the larger Facebook context.
Amazon and Facebook are both making substantial contributions on the Open Source projects they rely on. But still the project upstream can't affect the way those two services operate. There is very little user-driven innovation.
Ubuntu and Eucalyptus are working on a more open cloud architecture. But it remains to be seen if any major cloud provider will provide that. Now every cloud is quite different, on infra, management tool and data storage levels. Eucalyptus can emulate AWS APIs, but they will be unlikely to be able to push their improvements to Amazon. That slows innovation.
Licensing is one question. Most free software licenses don't force you to open your changes if you only provide it via SaaS. Of course there is AGPL.
Microsoft is much more open on clouds now. Just look at the botnets. (laughter)
The conficker botnet is a way bigger cloud processor than Google or Amazon, making the Russian mafia the world's leading cloud vendor. Could P2P be the basis for an open cloud, SETI@home style?
Current state of non-interoperability and lock-in means that moving to a cheaper cloud provider is like a heart transplant. Plenty of risk.
For third-tier providers cooperation would make sense. They can't compete with Amazon on their own, so sharing code and infrastructure may be the only way. This could be the beginning of an open cloud.
What are the expectations from the open cloud? Being able to hot-swap vendors? Being able push a patch for Google Docs?
Current differentiation between being Windows, Mac, Linux user may become to whether you're a Google, Amazon or Yahoo user. Lock-in moves from operating system on client side to the server-side service provider.
Heroku is interesting in the sense that it provides PaaS for Rails, but you can still run your Rails app also on a regular RoR install. This is similar to what we're building for Midgard. You cannot install Heroku on another cloud provider, but your Rails application will still work.
Now differentiation happens by hard lock-in, but in an open cloud it could come from SLAs, reliability, management tools, geographical coverage.
@ihmis-suski doing that for many lives will be a tough job. But then again, life needs to have challenges :-P
Ari Jaaksi, Nokia: MeeGo, the free and standard Linux for the mobile industry.
Nokia is going through a lot of changes technology-wise. Even though Ari still has a maemo t-shirt his unit is now MeeGo Devices. Nokia's open source history with Maemo goes back to more than five years. Not quite IBM level of Linux experience but we're getting there.
N900 is exceeding Nokia's expectations in sales. And N900 has the best multitasking capability of smartphones out there.
With developers Nokia hasn't done such a great job yet. As web hasn't replaced native apps completely yet Nokia will need to work better with app developers than they do.
With MeeGo N900 will serve as a developer device for Arm-based devices.
How to provide a better user experience? A lot of it in in the core of the platform... things like networking and multitasking where decisions by kernel developers will affect the UX. You need to put attention to the features people actually use. With the N900 this means the browser and the conversations tool.
Maemo, Moblin, LIMO and Android are largely built on same free components. But each company used to intregrate and release separately. MeeGo is intended for providing a platform for each of the companies to use same versions, same upstream collaboration and same testing effort. Both Palm and Google have been using Nokia's Linux work in their products already, Palm even earlier than Nokia had their products out.
In the MeeGo stack slide: ofono, X, gstreamer, connman, Qt, WebKit, Telepathy, Linux, Fennec, RPM and GNOME. Steering group discussions where decisions about the stack are made are all done out in the open.
First MeeGo code dump is out there but it is still far from being a usable release. But this is a good time to jump in and start working with the codebase. Nokia is working on the next MeeGo-based devices as we speak, and they will be mobile phones.
MeeGo is designed for multiple device categories from smartphones via TVs and tablets to Netbooks. The different devices obviously need different user interfaces, but everything under that can be the shared MeeGo stack.
Acer, Asus, BMW, Cisco, Careland, CS2C, Ericsson, DeviceVM, Gameloft, EA, Kingsoft, Linpus, Mandriva, Metasys, MontaSys, Neusoft, Novell, PixArt, Red Flag and others have already joined the MeeGo community.
Kernel panel. Linux kernel is one of the most prominent collaborative projects out there. A new release every 3 months, containing some 10,000 changes on average, made by some 150 companies and about 11,000 developers.
Panelists are talking about some new things in kernel, including better SSD support and a Linux equivalent of DTrace.
Linux has kernel support for almost everything now. Though not all hardware works correctly with the drivers Linux has. Most enterprise-level hardware works very well, but with cheap wireless devices there are sometimes problem, mostly because the hardware is quite bad and/or has binary-only drivers like the broadcom wireless chips on netbooks.
Discussing about the 'greying' of kernel developers. Most contributors have been doing this since 90s, and very few people are joining the project. Somebody in a conference in Japan remarked: you're all so old. Partially the problem is the receding coolness factor of kernel development, and also that the long-time developers are so expert in their areas that the code they write is hard to understand for newcomers. Of course having only the experienced (and usually salaried) developers around also means that the contributors are more deeply dedicated.
Imad Sousou, Intel and MeeGo technical steering group. Intel is the 2nd biggest Linux contributor (behind Red Hat but ahead of IBM, Novell, Nokia and Oracle). "The Secret" is following the open model.
If you want a kernel patch into MeeGo, send it to kernel upstream instead of MeeGo. If you want a Qt patch into MeeGo, send it to Qt.
MeeGo aims to have the best of Moblin and the best of Maemo, in an open way and providing common APIs across different devices. It is an independent project run under the Linux Foundation.
In-vehicle is an important area. This doesn't mean only car consoles, but also airplanes, trains and so forth.
MeeGo is all about the experience. The user experience and the developer experience. Qt and tools like Qt Creator help a lot on the latter.
MeeGo will be an uniform platform. This means all MeeGo devices must pass compliance testing, ensuring MeeGo applications can run on all the devices.
Solving problems of Linux on constrained devices has required building tools like PowerTOP, Fast Boot, TimeChart and QML. These help developers to figure oiut what is eating battery power or improve boot times.
MeeGo will have a timed 6 month release cycle. 1.0 in Q2 2010, and after that the releases will probably happen around November and May.
The first MeeGo Conference will be held in November 2010 somewhere in Europe.
Linux in critical environments, talk by the German air traffic control organization. Promo video shown on what it air traffic control no pilot starts their engine or takes off without the authorization by an controller. Cue cheesy Muzak.
Air traffic in Europe has grown from 7 million flights per year to 11 million in 13 years. In 2020 it is estimated to be 20 million, most of it over Germany. 9000 flights a day cross Germany.
Unix is the base of current air traffic control system, but as Linux hardware is becoming faster and cheaper, they're moving to that.
DFS has two Linux competence centers providing specs and testing on new systems. The software needs are quite specialized, for example Wacom tablets are used completely differently than designers use them. This means sometimes DFS has to make patches to Linux kernel or other parts of the stack. Testing process for a change will take weeks.
Air traffic control is highly regulated environment. For that open source works well because you can do white box testing and you can ensure 10-15 year life cycles that no software vendor could provide. In such environment upgrades are almost impossible so you need software from OS level up with extreme long-term support insourced. A US company asked 3 million for a change in the software but sold its rights for only 300,000. And so DFS now maintains it, some as open source.
All new air traffic systems at DFS are developed on Linux only. High reliability is ensured by having two separate groups of developers developing on same spec. This means you will have to separate implementations of everything, so if one has a bug you can switch to the other one.
This approach has provided substantial savings because of cheaper PC hardware, less reliance on expensive external consultants, and the ability to better utilize in-house expertise.
DFS has started contributing directly to Linux kernel upstream, also by working with device manufacturers to get drivers into the kernel.
With enough planning Linux is stable enough to be used in ATC. But in-house expertise is needed to provide sufficient response time.
DFS is marketing their open source ATC system to other countries. For example Brazil has deployed it.
Josh Berkus, the Linux hit man (wearing dark glasses and a black suit, carrying a nerf gun): how to prevent communities.
If you make good releases and good software, your community may grow. You may receive thousands of email messages and have to fly to dozens of conferences. Your community is out of control. Community growth causes global warming.
First of all:
7 habits of highly stagnant communities can help:
Chris DiBona, Google. Developers need the quiet, they need to get into the flow, use great tools and be creative. Then throw it over the wall, put it on Sourceforge or GitHub. Don't hold your breath on contributions, it usually takes a project a year or two to attract external developers.
Pick one of the licenses out these, like GPL, and minimize the legalese. Or even better, use a permissive license of ASL. Then you don't need to police the viral part of the license.
Keep on releasing, release as often as possible. Even if nobody is paying attention. It is a lot easier to keep that process running and natural than decide what projects are important to have in the open.
Most open source projects never grow larger than one developers. Samba is only about ten people.
Ban your trolls. Let their keep their rants in their blog, that is what those are for. After you ban them you don't have to spend time thinking about them.
IRC meetings are great when you have the community. Before that even in-house meetings are OK, as long as your actually meet.
Don't focus on an enemy. For Android to succeed MeeGo doesn't have to fail. The market is large enough for both, and the competition and idea sharing make both stronger.
Google has released 915 open source projects. 200+ Googlers are patching upstream projects all the time. They also provide infra for projects like the kernel. Last 6 summer of codes have had 4000 students paid to hack free software.
Whenever you're using Google you're using Linux.
MeeGo is a personal OS for personal devices. MeeGo takes upstream projects, handles integration, makes a release every 6 months that device manufacturers can take, provide their value-add and ship with devices.
In most cases stock MeeGo will work on any compatible device, but some platforms may require proprietary drivers.
Application developers can rely on the standard platform and services to be there on every MeeGo device, so your app will only require UI modifications to be portable. If your application is built on Qt then it will just work. Obviously interaction options like touchscreen, keyboard, mouse may be different on different devices. To make it run on different kind of devices you need to skin your application for each device category.
MeeGo compatible devices must have Qt. Gtk may be there or may not be. Nokia is trying to align the Qt release schedule to match the MeeGo 6 month cadence.
The language to write MeeGo apps is Qt and C++. PySide can be used for Python development but is not guaranteed to be available on every device. JavaScript can be used in QML applications as the UI scripting language.
GConf is the configuration system, but that may change when something better appears.
WebKit is the embeddable web viewer, but as for actual web browser the decision will depend on the device. Browser is just an application, it may be Fennec or Chromium for example.
If you develop a MeeGo application, you have to write it in Qt. The compliance tests may require this.
Qt Mobility will be there, but the final APIs on that are not ready yet.
There will be different User Experiences with their own interaction models... Handheld, netbook, in-vehicle etc. Each category will have interaction designers working to make nice, usable interfaces. iPad mentioned as good UX. Netbook UX will assume mouse and keyboard, not touch.
Both Intel and ARM are supported. Patches from hardware manufacturers should go first to upstream, not directly to MeeGo. We as MeeGo don't want to have one-time hardware-specific forks like Android has had.
Every MeeGo device must ship the full MeeGo stack as provided by MeeGo. Patches can be applied on top of that but application-level API must not be broken. Only compliant devices can use the MeeGo logo and trademark.
ISVs will be able to provide one RPM package that will work on all MeeGo devices.
MeeGo developer infra will have git repos, bugzilla, OBS for builds and package repositories, and some kind of garage for projects.
MeeGo OS will mostly use LGPLv2. For UX level and reference applications permissive license like BSD is encouraged. All licenses must be compatible with the Open Source Definition. We try to keep GPLv3 out of the core for now.
The Technical Steering Group elects themselves, they can invite new members. If a company is a big contributor they may get on board.
The release cadence will target April and October releases, to match the rest of the Open Source ecosystem... Kernel, Ubuntu, Fedora, ... The April release will be planned in the November Summit, though things may change when reality kicks in.
Qt Creator is the recommended development tool. It will enable you to build your application for both Atom and ARM.
There will be a MeeGo community app store, but for proprietary apps there will be Ovi Store and other manufacturer-specific stores. Vendors may or may not allow 3rd party app repositories to be enabled on a device.
Operators may be another party that will limit 3rd party app installation capabilities.
Greg from Novell is showing the MeeGo netbook UI. Apparently it had been leaked from Beijing to Engadget so there is a video available.
Banshee is now the media player and Evolution is the email system but with a different UI. There is Exchange, SyncML and Google sync for contacts and calendar. Mobile Me too. Banshee uses Tracker for storage, and Evolution will switch to it too.
Novell is helping a bunch of net book manufacturers to ship MeeGo. Expect announcements.
Battery usage -wise MeeGo netbook will be similar to Windows XP.
Having Banshee on board means that MeeGo on netbooks will ship Mono, so C# is another language people can use.
Chrome is the default browser shipped.
MeeGo netbooks will use the Intel app store.
@qgil on MeeGo decision making. There will be working groups for handheld UX, netbook UX where vendors can propose new modules to be part of next release of MeeGo. Other things should either happen in upstream, or vendor-specific modules.
Generally with MeeGo this will be business as usual, the way most distros work.
Qt Quick (QML) presentation. The CSS-like way of defining your UI together with some Javascript imperative parts seems quite simple to work with. Qt Creator is the main development tool for MeeGo, especially when combined together with Madde.
The QML idea is that actual business logic of an application is written in C++, but the UI and its transitions in QML and JavaScript. This enables UI designers to actually work on the real application, and the UI to be quickly adapted to new hardware. The native business logic is exposed via QMetaObject that will provide all the signals, slots and properties.
MeeGo technical panel: Sakari Poussa, Dawn Foster, Mark Skarpness and Andy Wilson. The background of the MeeGo fusion was that Maemo and Moblin were reasonably similar approaches to mobile Linux, and the business goals of Nokia and Intel were compatible.
late last year, when the MeeGo project was ramping up... interesting.
The big platform decisions like RPM and Qt included lots of wrangling and meetings, but in the end the two parties were able to agree. Most of the rest of the software of shared already anyway. At Nokia there were also many components that had been closed for no reason. Opening them up required time.
To maximize reach of an application an ISV should publish their apps to multiple MeeGo app stores (Ovi, Intel, ...). The SDK will provide single-button functionality for doing that.
Next MeeGo release will be ported to the N900. It will not be perfect but will be available. That progress should be opened soon to the MeeGo-dev mailing list.
Community will be able to contribute to components inside MeeGo just like in any regular open source project.
@dneary: aren't all these working groups and program committees a bit heavy model, making it difficult for individual developers to get it? A: The program committee shouldn't micromanage development, just go to Bugzilla instead. LIMO is a negative example where lots of lawyer time and legalese were spent before writing a single line of code. MeeGo contrasts this by having an actual codebase (or, well, two) to start with.
Every package will contain a URL to the correct Bugzilla for reporting issues against it.
MeeGo will try to work with upstream projects to try to get patches in as quickly as possible. But it is also important that the upstream makes it easy to provide patches. The kernel staging repository where even bad drivers are accepted if they compile is a good example. Kernel gets the driver, and distro can ship it.
Projects chosen for the MeeGo architecture have been chosen on the ground that either Nokia or Intel has some investment in it. If they pick new projects they will most likely either place their own people into the project or contract the project's developers. Especially Nokia has been doing lots of subcontracting with small open source projects, Intel seems to do more in-house.
N900 was an experiment in openness and a successful one at that. But operators want to be lock their phones, so in future the devices will be more closed. MeeGo aims to have unlocked developer devices available.
@qgil: if you buy a MeeGo flagship phone from nokia.com, then there will certainly be a way to unlock and open it.
For OS updates to happen on devices first MeeGo has to publish them, then device manufacturer has to make them available, and finally the operator has to allow them to be upgraded. This may not always be the case.
Nokia's MeeGo devices will support OTA upgrades, just like the N900.
Copyright Rohea Oy 2010 | Mobile version | Feedback | API | Terms of Service | Applications and tools
