When MeeGo was announced in February of this year, a big part of the news was that the platform would support a broad range of computing devices, taking mobile computing far beyond the smartphone to support tablets, notebooks, media phones, connected TVs, in-vehicle infotainment devices, and much more.

Today’s MeeGo v1.0 release represents an important step in reaching that vision: MeeGo v1.0 is available now and with it, we get the MeeGo API and the stable core foundation for application development for the user experience on Netbooks. This is good news for developers and for OEMs and service providers who want to begin customizing MeeGo for their Netbook offerings. Especially good timing considering Computex kicks off next week.

According to Imad Sousou’s blog over at MeeGo.com, MeeGo v1.0’s Netbook user experience includes a variety of features that deliver Internet, computing and communications experiences with rich graphics, multi-tasking and multimedia capabilities, as well as Google Chrome browser integration. Instant access to synchronized calendar, tasks, appointments and real-time social networking updates; easy apps for email, calendar and media player; and support for 19 languages are a few examples.

The development of the handset user experience will follow shortly with availability in June. Support for touch-based devices, such as tablets, and in-vehicle infotainment systems, is expected in MeeGo v1.1 in October.

Join me next week in keeping an eye on news coming out of Computex. What happens there is sure to influence the MeeGo community’s work.

It’s been a hectic few months narrowing down the content for this year’s LinuxCon. Craig Ross and I have been working on this schedule for what seems like years, but we are very proud to announce it today. You can find it here.

I think the program has an amazing mix of business, operations and of course developer content that reflects the growing ecosystem that is Linux. I’m especially proud of the technical content that features many of the best minds behind the kernel and other upstream Linux projects. But LinuxCon is much more than just technical kernel topics: it also has content touching mobile computing, cloud and legal and business issues facing enterprise IT managers today. Linux is now becoming dominant in mobile and cloud computing so it’s no surprise LinuxCon’s content matches those themes.
So what sessions will people be talking about after LinuxCon?
Mobile. No surprise here as Linux has taken off challenging all mobile incumbents with Android, Meego, PalmOS and more. I’m looking forward to Matthew Garrett’s take on the Android/Linux kernel issues and as he says,  ”to take a look back at what caused the problems and how they could have been avoided – by both sides.”   We also have a keynote presentation on Meego and its open approach to building a mobile project.

Wildcard. We added a healthy dose of wildcard talks this year to spice things up. From flying rockets with open source to how the new generation is responding to Linux development today.

Legal. We have the man himself, Eben Moglen, delivering a keynote you won’t want to miss. We also have multiple sessions on everyone’s favorite topics: patents and what to do about them.

Cloud Computing. Do you want one cloud API to rule them all? They get ye to the presentation on Delta Cloud from David Lutterkort.  We also have a mini-summit devoted to the Open Cloud on Sunday before LinuxCon which will be a deep dive into all things fluffy and white.

File Systems. Does your system have over one billion files? If so (or even if you have considerably less than that), you’ll want to hear from file system expert Ric Wheeler. Heard about Btrfs? If not, you will and you should hear it directly from the source and Oracle’s Chris Mason.

Desktop. This may not be the year of the Linux desktop but we still have good desktop content! Matt Asay has a terrific panel on Where the Linux Desktop Is Succeeding (hint: instant on is one of them), and we also have Jeff Osier-Mixon refereeing the distribution smack down as he looks at common tasks across your favorite desktop distribution. Should be interesting!

I hope you join us for a great party in Boston in August. You can register here before the prices go up as it gets closer.

This is an ongoing Linux.com series that profiles The Linux Foundation’s individual supporters and begins to collectively illustrate a very important part of the Linux community. Individuals help support the work of Linux creator Linus Torvalds and other important activities that advance Linux, while getting a variety of other fun and valuable benefits. It is this collective support that enables The Linux Foundation to provide important services for industry and community.

The series began with senior application developer Matthew Fernandez. Today, we talk to Kevyn-Alexandre Paré.

Some Linux Foundation supporters don’t do anything just a little. That’s certainly the case with Paré, a software engineer based in Montreal who traveled nearly 4,000 miles by car last summer to attend the first ever LinuxCon (part of a 9,000-mile summer road trip). Apparently, his trek did nothing to slow him down, because upon arriving at LinuxCon, the BUG community gave him an award for enthusiasm.

Last summer is also when Paré became a Linux Foundation supporter, taking advantage of both discounted event registration and training courses, including Linux Foundation training courses “Developing Linux Device Drivers” and “Linux Kernel Internals and Debugging.”

“Those two courses taught me a lot, were practical, and the teacher used real life experiences. I’m even thinking of retaking ‘Developing Linux Device Drivers’ since it is now offered as a 5-day course,” said Paré.

Paré was originally introduced to Linux in college and quickly became passionate about embedded devices. Today, he uses Linux both at work and at home and participates in the beagleboard, gumstix, Android and Ben NanoNote projects.

“My favorite Linux innovation is the Ben NanoNote because they’re applying copyleft to hardware and software. Do it yourself? Do it together!” says Paré.

His recommendation to new Linux users and developers is to keep working with others and sharing as much as you can to help. Paré says he supports the Linux Foundation as a way to contribute to and be a part of The Linux Foundation, home to Linux creator Linus Torvalds, while gaining advantages such as discounts and networking opportunities.

“I expect it will help me stay up to date with training and making new contacts during conferences. I expect to gain a lot of positive visibility.”


Thanks to the Free Software Foundation and its donors for producing this video that helps to expose the absurdity of our patent system today. It debuted earlier this month at the Connecticut Film Festival.

The 28-minute video (it’s worth it) does two things particularly well: 1) helps us to understand today’s issues based on where the patent system began, and 2) uses a style that puts a spotlight on how far some have gone to exploit our very broken patent system. Hopefully, this video can inform how we approach patent reform and call attention to the urgency for action.

There are some especially useful comments from Mark Webbink and Eben Moglen. Check it out here or by visiting http://patentabsurdity.com/watch.html.

So, as most people will have heard, the 2.6.34 kernel was released on May 16. Back in February, I was predicting a mid-May release, so I hit it almost exactly. That says nothing about my prediction skills, though (which are horrible) and a lot about how the kernel development process is going. It has become a very predictable, nearly boring affair.

The cycle itself is highly predictable: kernel releases are routinely 10-12 weeks apart with little variation. This is a big change from the Good Old Days, when the 2.3 kernel was in “feature freeze” for over a year with no visible progress toward a release being made. We, as a community, have figured out how to create a predictable development cycle with little in the way of surprises. Getting there took a combination of discipline, experience, and improved tools, but now we have all three.

Feature sets are still less predictable; a day or so into the 2.6.35 cycle, I cannot really say what will be in that release, despite the fact that much of the new code is already staged in the linux-next tree. One of the headline features of 2.6.34 – the LogFS flash-oriented filesystem – came as a surprise to many. LogFS had been under development for years, sometimes with support from the CE Linux Forum, but it went below the radar for some time until its author decided it was ready. But, beyond LogFS, there was little about 2.6.34 that was truly surprising.

2.6.35 may be similar. There will certainly be improvements to a number of subsystems and a lot of new drivers. We may get a new subsystem for infrared controllers, and the fanotify API (meant to provide hooks for anti-malware scanning software) may finally be merged. With some luck, we will see some important code from the Android kernel make its way into the mainline; if this effort succeeds, it will be the result of a lot of work by a lot of people and some support from the Linux Foundation.

But I predict that there will be nothing truly earthshaking in 2.6.35. No new schedulers, no massive code reorganizations, and no surprising new features. What we’ll see, instead, is the ongoing, predictable improvement of the Linux kernel. If I’m wrong (remember what I said about my prediction abilities), you can give me grief at LinuxCon, which will be happening right about when 2.6.35 is due.

Andrew Morton once famously predicted that the patch volume would have to drop sometime soon because we’d have to actually finish this kernel someday. When he made that prediction (2.6.14), a typical release had about 4,000 changes. Now anything under 10,000 seems slow. So, clearly, we have not finished yet – but might that day be coming? I don’t expect it to happen anytime soon. Even if the world were unchanging, we would have a lot of work to do just improving today’s kernel. In a rapidly-changing world, we’ll continue to need a rapidly-changing kernel too. So there will be lots of changes in our future, many of which may be exciting indeed. In the mean time, perhaps we can enjoy a relatively calm (northern hemisphere) summer.

I honor and loveEvery pig that I seeFor maybe one dayThat pig will love me. Our friendship with pigswill always lastIt doesn’t matterWhether it’s slow or fast. If we continue to hugEvery pig we canOur love will growAs large as this land. So I promise to helpEvery pig in defeatFor if it weren’t for pigsThere would be no bacon to eat. What can I say? Daniela (my middle one) is a real poet. It scans a bit oddly, but I think that falls solidly under the heading of “artistic”.


The annual Linux.com Planning meeting took place at the Linux Foundation Collaboration Summit last month. It was a great opportunity to meet face-to-face with some of the most active Linux.com community members and to understand what kinds of things are working and not working on the site. We even had some hard-core contributors who dialed in for the four-hour session!

The feedback we got was invaluable, and we’re working on implementing some priority updates in the short term and have also captured a short list of improvements to be made over the longer term.

First, we are updating the Linux.com Guru program point allocations. The Linux.com Guru program will no longer allocate points for joining groups, and points will not be deducted for leaving groups. In addition, we will be getting in contact in the weeks ahead with group owners who have had no activity in their groups for more than 60 days. From now on, any groups that are inactive for more than two months will be removed. This will help decrease fragmentation in threads across multiple groups. Lastly on the Guru Points system, we will be awarding points for both articles and blogs. Article submissions that are published will receive five (5) points and blogs will receive three (3) points.

We’ve updated the point allocations values here.

Moderators are so important to the quality of our forums and groups, and we received some excellent ideas about moderation of the site. I would like to invite any one interested in moderating forums to email me at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
. It is worth calling out one of our most dedicated contributors to the Linux.com community – Matthew Fillpot (mfillpot). Matthew has been moderating most of our forums and I know would enjoy a partner or two in crime.

We found the Linux.com Planning meeting so useful that we will not be waiting a full year to talk again. We will host an annual phone call in addition to the in-person meeting at Collaboration Summit each year. The Linux.com conference call will take place in the third quarter of this year and details will be provided on this blog.

A big thanks to everyone who participated in the Linux.com planning meeting and to the rest of the Linux.com community, which makes the site the rich resource it is today. Let’s keep making it even better together!

Lately I have been hearing criticism about embedded Linux and how fragmentation, as represented by the many flourishing Linux projects such as Meego, Android and webOS, is bad and dangerous for Linux; these critics suggest that fragmentation will hinder Linux’ ability to compete with companies like Microsoft and Apple. I disagree, which is not surprising. But the market and marketing strategists also disagree. Citing the familiar ogre of fragmentation shows a limited view of the Linux economy.

The Linux platform is both fragmented and unified.

Linux already has a unified base: it’s called upstream components. An Embedded Linux OS, just like an enterprise Linux OS, is comprised of core upstream components like the Linux kernel. First, at the kernel level — where most hardware support happens including all driver support — the Linux ecosystem is extremely unified. Device makers or silicon suppliers that wish to support their hardware with Linux – whatever the variety – simply contribute code to the mainline Linux kernel project hosted at kernel.org. Use a mainline kernel and you are using the right base. Recently Google has been working with the kernel community to ensure their drivers are in the mainline kernel and great progress has been made to “unify” Android with the mainline kernel.

Linux distributions are also unified at the core library level. In addition to the kernel, you have projects like X.org, glibc, gstreamer, Gnome, QT, webkit, CUPS, clutter, etc. These are all example of core libraries that generally are included in almost every variant of mobile Linux; Chrome, Android, MeeGo, WebOS, LiMo, etc. They all use these same “base” components. In the MeeGo project, for example, the development philosophy echos this with an “upstream first” mantra. Most of the actual coding for MeeGo or many of these other Linux distributions takes place upstream. That means that when Meego contributes upstream, all downstream distributions benefit. This is the same in the server and desktop market, and why it’s so important for distributions to focus their development upstream.

There is an area of fragmentation: it is within the application ecosystem and API. Application APIs are defined at a higher level where the market often decides which version of Linux will dominate. In many cases there are multiple versions of Linux that succeed in the market. Google’s Linux-based mobile OS Android handles application compatibility with their Java-based run time. Applications are made available to consumers through the Android marketplace. WebOS (soon to be HP’s Linux variant) has a similar approach, though with a different run time and SDK. MeeGo has an SDK based on Qt, which can be used to create apps that run on Symbian, Mac, Windows, or MeeGo. Even the Amazon Kindle has an application SDK.

These are not random versions of Linux; each effort is critically backed by a combination of major industry players, each of which creates their own ecosystem; Google, HP, Intel, Nokia, Amazon, etc. How is this bad for Linux? Linux is about choice and allowing companies, projects and individuals to compete and thrive. API differentiation allows companies to compete and incents them to keep enhancing the platform. Actors can opt in or out of a Linux application API effort based on network benefits of that particular project and ease of participation.

Again, all good news for Linux and good news for the various ecosystem members, since they can now all share in the upstream improvements. Having various brands address a huge and growing market is not unique to embedded Linux. Just look at consumer brands and how Proctor and Gamble, for instance, will have multiple brands of diapers, just to ensure their products cover the market. Segmentation is a smart strategy, especially when you have Intel, Nokia, Google, HP, Motorola and more making products based on yours.

Android, Meego, Chrome and webOS are all Linux-based yet no one is confused about the kind of application they are building or which market they are reaching. The reality here is that aside from Apple, RIM, and Microsoft, almost no one is building client computing devices with anything but Linux. There will be multiple application ecosystems on top of the various Linux systems that will remain unified at the lower levels of the computing stack. This provides an excellent balance of shared R&D and market competition. What is important now is for industry players to align themselves with one or more of the Linux efforts which are backed by credible industry players and make sure that those efforts continue to develop their code upstream. Will we see more efforts? Perhaps, but hat we don’t want to see is the creation of yet another effort in the name of “unification” if it attempts to restrict, dictate or reinvent technologies or processes that already work.

The market doesn’t seem to think Linux fragmentation at the application level is a problem at all. The world’s largest chip maker and the world’s largest mobile handset maker just merged two Linux efforts into one, based on Linux. More and more hardware OEM’s and carriers are jumping on board MeeGo. Android just surpassed the Apple iPhone in unit shipments. HP just paid over a billion dollars to use webOS as a platform for their own devices, while at the same time dumping their tablet project with Microsoft. Linux dominates market share in embedded systems. We are in the early stages of a very long game in mobile computing and I for one am glad that Linux is so massively hedged.


The Linux Foundation’s individual supporters help to support the work of Linux creator Linus Torvalds and other important activities that advance Linux, while getting a variety of other fun and valuable benefits.It is this collective support from thousands of individual members that enables The Linux Foundation to provide important services for industry and community. That is why we’re launching a new Linux.com series today that profiles these individuals and that begins to collectively illustrate a very important part of the Linux community. 

The series begins with Matthew Fernandez, a senior application developer based in Sydney, Australia. Matthew has been using Linux since 2001 and just recently became a Linux Foundation supporter.

How do you use Linux? At work? At home?

Fernandez: I had dabbled with Linux in school, but I really only got into it at university. With the exception of my partner, very few things excite me as much as open source software; and Linux, as an open source operating system, struck a chord with me. These days I use Linux on several machines at home for development, email and web browsing; as a server; as a media center; and on my phone.


Why did you recently become a Linux Foundation supporter?

Fernandez: I’ve been using Linux for years. I find it an inspiring community and I had $99 to spare! Kernel development is something I’d like to get into eventually and The Linux Foundation provides some great resources for learning more about the kernel and the developer community. Sponsoring the Foundation (from my few weeks of experience) is a great way to stay on top of new developments in Linux and connect with the Linux community. To be honest, more than any of these reasons, I wanted to give something back to a community that has made such a big difference in my daily life.

What member benefit are you looking forward to taking advantage of the most?

Fernandez: The Briefing Book is fantastic; although, I don’t know if that counts because I’ve already been taking advantage of it in these first few weeks. Sadly {there are} no hardware discounts for me, because I live in Australia; although, I am excited about the discount conference registration and books. Oh, I just noticed I get ThinkGeek discounts!

What’s your advice for your fellow Linux users?

Fernandez: Keep doing what you’re doing. The Linux developer community is the most impressive and successful group in the IT world. Linux is making progress in leaps and bounds. In terms of end users, Linux is being adopted by more and more people every day. Over the past ten years I’ve had many of my non-geeky friends (I like to refer to them as civilians) ask me questions like: “Hey, what’s this Linux thing I’ve been hearing about? Should I be using Linux?” The biggest message to people new to Linux is this: Linux is easy. Live CDs and distros with GUIs preconfigured have removed many of the previous barriers to adopting Linux as your primary operating system. It’s free; what have you got to lose?

What’s your favorite, latest Linux innovation?

Fernandez: Everybody’s been raving about KVM, but personally, for me, the biggest gain in each successive release (although it’s not really “innovation”) is device drivers. The day I updated my laptop’s kernel and discovered the wireless now worked out-of-the-box without wpasupplicant fiddling was a good day. Device support is probably the single biggest barrier to consumer adoption of Linux (at least among the people I speak to). Yesterday my extremely non-geeky partner asked me if I would install Linux on her laptop. Now that’s impressive 🙂

Jon Corbet is a highly-recognized contributor to the Linux kernel community. He is a developer and the executive editor of Linux Weekly News (LWN). He is also The Linux Foundation’s chief meteorologist, a role in which he translates kernel-level milestones into an industry outlook for Linux. Corbet has also written extensively on how to work within the Linux kernel development community and has moderated a variety of panels on the topic. Today, he gives us an update on the Linux “weather forecast,” why sharing your code upstream is critical, and the state of virtualization in the kernel.

You’ve been the “chief meteorologist” for the Linux Weather Forecast for a while now. What’s the general forecast for Linux today?

Corbet: Bright and sunny with occasional thunderstorms.

That’s a broad question; I’ll restrict myself to the kernel level where I can at least pretend to know what I’m talking about. Things are going quite well, for the most part. The development process is humming along with very few glitches, and we have more developers involved with every release. Things look very healthy.

The 2.6.34 kernel will hit the net sometime this month; it seems to be stabilizing well. It’s full of improvements to our power management and tracing infrastructures, both of which have been slower than we might have liked it to mature over the last few years. There’s two new filesystems: LogFS is aimed at solid-state devices, while Ceph is meant for high-reliability network-distributed storage. Things have been improved across the board; it should be a good release.

You’ve also written a lot about how to participate in the Linux development community and have moderated a number of panels on the topic. What is the most common question you get and how do you address it?

Corbet: The most common question I get must certainly be: “how do I get started

working on the kernel?” It is true that getting into the community can be an intimidating prospect: the code is large and complex; the mailing list gets 400 messages per day; and the community does not have a reputation for

always being overly friendly to those who are just beginning to feel their way around.

That said, it’s not as bad as it seems. Most community discussions are quite polite and professional anymore, and people do try to guide newcomers in the right direction. The quality of the kernel’s code base has increased over the years; it has also always been a highly modular system, so it’s easy to just focus on one little piece. And the documentation for newcomers has gone from nonexistent to significant.

Aspiring kernel developers still often wonder where to get started. Too many of them try to make their entrance with things like coding style patches or spelling fixes. That’s understandable; it must be tempting to start learning the ropes with a patch, which, with any luck at all, cannot break anything.  But that kind of work is not hugely helpful, to either the developer or the kernel as a whole. That’s why I tend to pass on Andrew Morton’s advice: the first thing any kernel developer should do is make the kernel work flawlessly on every system they have access to. Fixing bugs is a far more valuable exercise and a great way to start building a reputation within the community.

The other thing I like to suggest is reviewing of patches. That can be hard for a newcomer, who can only feel out of place asking questions about code posted by established developers.  But code review is always in short supply, and there’s no better way to learn than to look at a lot of code and figure out how it works. Review comments which are expressed as questions (rather than as criticism) will always get a polite reply – and often thanks.

With an increase in the number of companies using Linux, especially in the mobile/embedded space, is it changing the dynamic of the Linux development process? If so, how?

Corbet: There have been many companies using Linux for years, and most kernel developers have been employed to do that work for just as long; so, in one

way, things haven’t changed much. We just have some new companies showing up, and they are all welcome.

That said, the embedded world is different. Embedded developers are bringing some good things, including a stronger focus on power efficiency and code size and support for a wide variety of new hardware. On the other hand, embedded developers often work in an environment of strict secrecy and tight deadlines that can make it very hard for them to work effectively with the community.  We are still working on ways to help these developers get their code upstream. Progress has been made, but the problem is not fully solved by any means.

Can you tell us a little about the virtualization work happening at the kernel level and what still needs to be done?

Corbet: I’ve been saying for a while that, at the kernel level, the virtualization problem has been solved. We have three virtualization mechanisms in the kernel (Lguest, KVM, and Xen), two of which are being widely used commercially.

The large number of developers working on Linux virtualization would be amused to hear me say that there’s nothing left for them to do, though. Most of the activity at this point is in the performance area. The intersection of memory management and virtualization appears to be especially tricky, so there is a lot of work being done to make it function more efficiently.

Some people question the importance of “mainlining” their code in the Linux kernel. Can you talk about the benefits and the payoff of getting your code accepted?

Corbet: Well, that’s a long list. Some of the things I routinely tell people include:

* Code that is in the mainline kernel is invariably better code. There has never been a code submission to come out from behind a corporate firewall – or even from a community project site – which did not need major improvements. Those improvements will happen, either as part of the merging process or afterward. Anybody who cares about the quality of their code will want to get it into the kernel, where it can be reviewed and improved.

* The maintenance of out-of-tree code can be an exercise in pain; there is quite a bit of work required just to keep up with mainline kernel changes. Once the code is merged, that work simply vanishes.  When a kernel API changes, all in-tree users are fixed as part of the change; out-of-tree code is out of luck. Merging code into the mainline allows the contributor to forget about much of the maintenance work, freeing them to go build new things.

* Code in the mainline kernel gets to users automatically; they do not have to go digging through other repositories to find it. Distributors will enable it. That makes life easier for your users, and they will appreciate it.

* That’s simply how our community works.  We would not have the kernel we have now if all those contributors did not do the work to get their changes upstream.

* It should also be noted that the contribution of code is the best way to influence the direction of the kernel going into the future. The kernel belongs, literally, to all who have contributed to it; each contributor has helped to build a kernel that meets their needs a little better. A code contribution is like a vote that helps to decide what kernel we’ll be running tomorrow.