How to keep track of fast-changing Linux OS
Change is inevitable, and how we deal with it defines us. In the Linux world change happens fast, probably faster than any other kernel in history. The Penguin is Evolving. How should we deal with this high-speed development?
Rapid evolution is both the greatest strength of Linux, and one of its weaknesses.
Unlike most other operating systems, it does not have a tightly controlled development cycle.
Anyone is free to download the source code, develop it in any direction they see fit and submit patches back to the community. We see drivers for obscure hardware, applications from handheld devices to supercomputers. Schedulers get replaced, architectures added. This would be impossible if Linus Torvalds and his deputies tried to keep rigid control of the development process.
But this rapid development also has a downside. For anyone wanting to develop a commercial product using Linux it is very hard to know just where to start.
Issues present in any given version of the kernel can be quite different to any other version. But it does not end at the kernel, this is true also of the tool-chain and, to varying degrees, of every user-land application. One must deal with all of this before starting to develop the actual application that will become the end product.
Of course, there is some control, without it, anarchy would reign absolute. The community would fragment and ultimately Linux would falter. We have seen this with some other Open Source projects in the past. Linus et al have done a great job of balancing evolutionary forces.
But still, development is fast, really fast. As a recent post on the Linux Kernel Mailing List from Linus demonstrates-in response to a list of bugs posted by Michal Piotrowski, Linus queried his source code repository and calculated that in any given day there are approximately 65 contributed changes or ‘commits’.
He commented: “That translates to five hundred commits a week, two thousand commits per month, and 25 thousand commits per year-as a fairly constant stream. Will mistakes happen? Hell yes!“
What this means is ‘rolling your own’ Linux distribution is hard. It takes time and resources and it takes expertise and experience.
This is why, to create our commercial-grade distribution of Linux, we must always take a kernel, tool-chain and user-land applications at a given point in time, test them thoroughly, fix issues and re-implement features where necessary.
We then maintain and support this validated version for years to come. Meanwhile, the Linux community moves on with each new release.
That is not to say we stand still. We watch the development of all the projects that form our platforms and regularly update them, offering our customers the chance to get new features, but continuing to support those using older versions throughout their development process.
And it does not end there. We add tools such as Diagnostics, ScopeTools, System Viewer and JTAG debugging hardware and integrate everything within Workbench, our Eclipse-based development environment.
All this provides stability in a rapidly changing world.
That is the kind of stable foundation device manufacturers have come to rely on to build their products. Free from the concerns of keeping up with the community, our customers can focus their attention, their development teams and other valuable resources, on what differentiates them from everyone else.
So how should you handle the changing world caused by those evolutionary forces? Chose a platform, concentrate on your product, and in my view let experts reconcile the conflicting needs of progress and stability.
Richard Danter is a Linux engineering specialist at Wind River
See also: Electronics Weekly’s Focus on Mobile Linux, a roundup of content related to the open source operating system shaped for mobile devices.