Tuesday, 17 April 2012 10:22
Joe 'Zonker' Brockmeier
There's a new Linux Mint in town, and something new has been added. Specifically, Mint's Cinnamon desktop is now part of Linux Mint's Debian Edition (LMDE). Mint giveth, and Mint taketh away. The 201204 LMDE release also says goodbye to GNOME 2.x, though users do have a transition plan one way or another.
A flurry of press coverage came with the news two weeks ago that for the first time Microsoft had made the top-20 list in the Linux Foundation’s annual development report on top contributors to the Linux kernel.
The announcement generated an audible buzz at the Collaboration Summit as well, where Microsoft engineers K.Y. Srinivasan and Tom Hanrahan presented “Microsoft’s journey to the Linux kernel.” They gave a technical talk, but much of the discussion revolved around Microsoft’s noticeable shift toward open source. And the pair fielded an intense round of questions from attendees, including kernel developers Greg Kroah-Hartman and James Bottomley.
Hanrahan began by asserting that Microsoft hadn’t done anything special to deserve the press attention. It was “just another company that decided to go down the path of contributing,” he said.
But the discussion opened wide when Kroah-Hartman didn’t accept that answer. To be fair, he said, Microsoft isn’t like every other company because it’s been “so anti-Linux.”
That attitude has been slowly changing within Microsoft, Hanrahan said, driven by customer demand for Linux integration. In fact, the biggest challenge Microsoft faced in the development process wasn’t resistance to Linux, but internal pressure to meet release deadlines. The Hyper-V team quickly learned that the open source community isn’t concerned as much with a company’s internal schedule but rather, with the quality of the code.
Hyper-V has benefited enormously from that extensive community exchange. Six Hyper-V drivers have now emerged from the kernel staging tree process with significant stability and performance improvements that expand what the drivers are capable of doing, Hanrahan said. And that was just the first phase of Microsoft’s work on Hyper-V.
The press attention and the obvious improvements to Hyper-V have also started to shift Microsoft’s internal culture to be more open and collaborative, Srinivasan said.
Has it also then, Bottomley asked, changed the way the Hyper-V group works to reflect a “more iterative feedback model?” And perhaps that model is creeping into other areas of the company?
“I’m not sure we’re there yet. But your feedback is important to help fix issues in a way that will help all operating systems on Hyper-V,” Srinivasan said. “We learned the hard way how best to deal with community comments and I suspect other companies have similar issues when they start working with open source.”
Overall, the presenters said, the community has been extremely helpful and welcoming throughout the past four years.
Said Srinivasan in conclusion: "Our goal is to make Linux a first-class citizen on Hyper-V."
Last week, we had our biggest turn-out ever for our Linux Foundation Collaboration Summit and our Legal Summit held immediately before. Collab has come a long way since the first meeting in 2007 at the Googleplex. While some of the issues and players have changed at heart the result is the same: a cross-section of people from the industry and community who may otherwise not meet collaborating together. We have assembled slides and videos from the week so if you weren't able to join us, please enjoy. I especially enjoyed Feargal O'Sullivan from NYSE's talk on OpenMama, the legal track on...
It’s a pretty nice dream. On your morning commute, you send a text message to the office espresso machine with your order for a double Americano and the warm mug is waiting when you get in.
For Seattle-based cloud texting company Zipwhip, the dream is reality. Its engineers custom-built an espresso machine that takes orders via SMS using their own cloud messaging application. (Watch the video, it’s pretty sweet.)
To make this dream perfect, though, it’s got to be built with Linux. So we wanted to know: what’s the underlying technology?
Zipwhip CEO John Lauer quickly and enthusiastically responded, “we couldn’t survive without Linux.”
While the “Textspresso” machine isn’t for sale, it operates entirely on Java code and could easily be built with a Linux box, Lauer said. Zipwhip plans to open source the entire application and release circuit designs with Arduino code so you can build your own, he said.
But really, open source coffee serves as a nice demo for their true product, the Zipwhip Android app, which runs on a whole suite of Linux-based products.
Zipwhip sends text messages to and from your desktop or tablet – fully synchronized with your phone to delete messages or mark them as read – via the cloud. The four-year-old company now runs 150 virtual machines across three datacenters that handle nearly a billion text messages each month.
Linux is already being adopted by an increasing number of car makers such as GM and Jaguar predominantly for in-vehicle infotainment systems. But much work remains to ensure that Linux is automotive-grade. In this article we will discuss the opportunities for Linux in vehicles and the five requirements that need to be addressed to bring it up to speed.
Where does Linux fit into a car?
Today there can be over 100 electronic control modules (ECU) in a car performing a myriad of functions to assist the driver and provide comfort and convenience to the passengers. Anti-lock brakes and airbags; electronic climate control; central locking and unlocking systems; satellite navigation; in-vehicle infotainment systems. The list of features seems to be endless. But where does Linux fit into this picture?
Not everywhere. Many of these modules perform a small range of very specific tasks in a constraint environment for which a rather heavyweight general purpose operating system such as Linux is not a good fit. Examples are engine management, airbag control, anti-lock brakes, automatic gearbox etc. These will not benefit from features such as memory management, multitasking, multi-core and multi-cpu support and more that the Linux kernel offers.
However, there is one component in a modern car that seems to be predestined for Linux: the head unit. Formerly just a simple control for the car stereo, the head unit has evolved into a universal command center providing a unified user interface for entertainment, climate control, communication, navigation and more. It commonly features a color LCD display which can include touch capability for interaction but can also be controlled via wheels and knobs integrated in the center console or buttons placed in the steering wheel at the driver's fingertips and increasingly through natural speech.
Because the head unit has to integrate and perform a range of tasks and often interrupts one task to carry out another it could greatly benefit from Linux. And indeed this is where car makers today are looking to deploy Linux. Below are five requirements that need to be addressed for Linux to meet the automotive grade needs of electronic control modules.
(Note: Linux is also a good fit for is a wide number of systems and services that fall under the umbrella term telematics. These form the core of the connected car: automated emergency call with location flagging, remote vehicle security and tracking, real-time traffic information, location-based services, concierge services, payment services for toll roads and parking, remote diagnostics and repair, breakdown prevention and maintenance scheduling, live audio-visual content and video-on-demand, and many more. All of the telematics systems and services will not only require an in-vehicle component but also infrastructure components. More great opportunities for Linux, although outside the scope of this article.)
5 ways to bring Linux up to speed
More ECUs in a car inevitably means increased consumption of electric power. But because there is considerable investment in the current electronic architecture, energy conservation to stay within the confines of the current 14.2 V system is the mandate. ECUs must reduce the peak and average power consumption during operation as well as their standby draw by dropping into a completely passive mode, waking up when they are needed and then returning to a dormant state. Reducing the total number of ECUs by integrating their functions into one or taking advantage of multi-core CPUs is another approach.
In electric vehicles the power challenges are magnified because all the power has to be provided by the batteries: for propulsion as well as for heating, cooling and every electrically-powered device including brought-in media players, smartphones and other gadgets.
Power management is a relatively new discipline within Linux. Instrumentation allowing the Linux kernel to measure power consumption of hardware components and to control power usage by turning them off is necessary to meet the automotive, as well as mobile, power challenges.
2. On-demand Configuration and Adaptation
A vehicle's systems constantly change their mode of operation dependent on many external and internal factors. The electronic systems must be capable of dynamically reconfiguring themselves within milliseconds and without user interaction dependent on the situation and requirements.
Linux already provides a strong set of features with loadable kernel modules, udev and others. Other features may be required such as incrementally loadable kernel modules. For example, only the portion of a Bluetooth driver that handles the link management protocol (LMP) is loaded and once a connection is established the driver will load other portions according to the required Bluetooth profiles.
3. Startup, Shutdown and Loss of Power
Driver assist systems with audio-visual interfaces such as rear-view cameras, proximity sensor in the bumpers, etc., need to be ready and available within 2 to 3 seconds from starting the car. Vehicular communication buses must be initialized within as little as 50 ms from cold-starting the ECU.
Linux has made great progress in speeding up the boot process with systemd and other efforts, however, there is still more work necessary to accelerate system startup even more from various hardware states to meet all automotive requirements.
Behavior during shutdown and sudden loss of power are another area where designers of embedded systems need to take great care. At no time must an interrupted shutdown or a sudden loss of power leave the system in a state from which it cannot recover.
4. Remote Software Updates
At first glance this seems like an easy problem to solve. Any Linux system can update kernel and packages over the network. However, for embedded and automotive systems things are quite different from regular computers. Updates may need to be downloaded via cellular data networks as cars are typically not connected to wired or wireless data networks.
Bandwidth is very limited and quality-of-service may greatly vary. Updates need to be carried out transparently for the user since the user cannot or should not have to monitor the process. Certain vehicle states may prevent installing software or rebooting the ECU. In case of an error the system must be able to roll back an update autonomously and return to the previous state.
Linux package managers are a good start but they typically update the entire package, which very often is not necessary if only a few files of the package has changed. Differential or delta package updates could be a solution. Verification of update package integrity is a must. Checksums are pretty much standard and help discover accidental corruption but are no protection from malicious activity.
5. Caution! Malware Ahead!
As the connected car is becoming a reality so will remote attacks on its systems.Wireless and web-based systems for vehicle control such as unlocking doors, starting/stopping the engine, or immobilization intended as a theft deterrent could be manipulated to compromise cars belonging to unsuspecting owners.
If not secured, over-the-air software update mechanisms could be used to infiltrate vehicle systems with malware potentially compromising not only privacy but also safety and health of passengers.
To become automotive-grade Linux will need to implement additional security mechanisms throughout the system. That starts with secure bootloaders, software components signed with hardware keys, hardware security support in form of cryptographic modules, etc.