Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Linux 6.0 promoted to Stable, Debian 12 will include closed-source binaries, and Google Cloud opens its first Africa region. (more…)
Linus Torvalds told attendees of the Open Source Summit Europe conference today that he is hopeful the foundational work needed to add support for the Rust programming language will be laid in a forthcoming version 6.1 of the Linux operating system.
It would take several additional releases of Linux to add full support for Rust, but the ability to more easily build and deploy applications written in Rust will go a long way toward improving the overall state of application security on Linux platforms.
The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, has called for replacing programming languages like Java that are not memory-safe as part of a larger plan to secure open source software supply chains. Rust is a memory-safe language that employs a compiler to track the ownership of values that can be used once and a borrow checker that manages how data is used without relying on traditional garbage collection techniques.
Earlier this week, the Rust Foundation allied with OpenSSF and JFrog to address other security issues that might arise as applications are developed in Rust.
It’s not clear just how many developers are adopting Rust, but Torvalds said he personally was looking forward to learning the Rust syntax—using a recently-acquired laptop based on an Arm processor—should the maintainers of Linux approve the effort. However, Torvalds also left open the possibility that adding support for Rust might not be as successful as initially hoped.
Torvalds also bemoaned the overall state of cybersecurity transparency at the operating system level. Many of the bugs that are encountered at the hardware level cannot be shared with the entire open source community, so any fix to those efforts is not subject to the same level of peer review as the rest of the operating system. The overall situation is improving, but it’s still very painful from a development perspective, he said. Secrecy is counter to the open source ethos, he said.
As new applications are built using a memory-safe programming language, the overall security posture of an organization will steadily improve. The challenge, of course, is that the number of developers that know how to build applications using those languages is still relatively small. Of course, replacing trillions of lines of code that have already been constructed using a variety of legacy non-memory-safe languages represents a gargantuan task that might never be fully completed—but shifting to a modern programming language is a major step in the right direction when it comes to application security.
There may even come a day when the way applications are coded is a lot more secure by default than it is today. That may not necessarily resolve every application security issue, but as the programming languages become inherently more secure, the pressure on developers to become cybersecurity experts should ease—assuming, of course, they are willing to learn a new way to write code.
Git, the version control system that arguably has enabled many DevOps advances over the last decade, is turning 15 this month. Git was developed by Linus Torvalds, best known for his contributions to Linux, and was so-named after he and the rest of the Linux community referred to it as “that stupid content tracker.” The term “Git” is British slang for “contemptible person.”
Today, Git is now arguably one of the most important and successful open source projects ever launched. For the past 15 years, the Git project has been led by Junio Hamano, a software engineer who today works for Google.
Git gained traction among developers because it provides support for rapid branching and merging of code in a way that also enables visualizing and navigating a non-linear development history. While even as far back as 2005 that was not a new idea, Git has emerged as the de facto standard for version control.
“Git is an essential part of everything we do,” said Pratik Wadher, a vice president at Intuit, which has made extensive use of the version control system within the context of multiple DevOps initiatives over the last half-dozen years. “It’s the single source of truth.”
As the de facto standard, Git has been the driving force behind what is now a multi-billion segment of the IT industry. In fact, with more individual developer and organizations contributing to Git than ever, the pace of innovation remains surprisingly strong 15 years into the open source project.
GitLab, GitHub, Microsoft and Google, for example, contributed a partial clone capability, available as an experiment via GitHub and GitLab, that makes it easier to work with large files. Instead of having to clone every file in a Git repository, it soon will become possible to more efficiently set up clones of repositories regardless of the size of the files in that repository.
That capability not only will prove critical to teams of developers working across multiple geographic regions but also will enable DevOps teams to employ Git to develop, for example, gaming applications that require DevOps teams to routinely work with large files, said Brendan O’Leary, senior developer evangelist for GitLab.
“It will enable new use cases,” said O’Leary.
The steady flow of innovations over the past 15 years has kept the base of organizations that rely on Git coming back for more. “The interesting thing about Git is that it has had real staying power,” said Kelly Stirman, vice president of product strategy and marketing for GitHub.
In terms of industry standards, Git can take its place alongside SQL and Linux in terms of impact, noted Stirman.
That staying power has even surprised some of the most ardent proponents of DevOps. “It’s been quite a journey,” said Ido Green, vice president of technology for JFrog, noting no one really knew 15 years ago just how big an impact the repository would have on software development.
Today, most organizations are employing Git because development teams don’t know any other way to manage source code.
“Git is now the default way to manage source code,” said François Dechery, chief strategy officer for CloudBees. “Ten years ago that was not the case.”
Where Git will be 10 years from now is, of course, anyone’s guess. But with the rise of various forms of artificial intelligence (AI) and the eventual embrace of best DevSecOps practices, it’s clear there are still many innovations to come that will revolve around a Git repository in some way.
The Linux Foundation announced today it will host the seL4 Foundation, the nonprofit organization established by Data61, an arm of Commonwealth Scientific and Industrial Research Organization (CSIRO) in Australia that has been developing the seL4 microkernel operating system.
Gernot Heiser, who will serve as chair of the new foundation, said the seL4 is unique in that it is mathematically proven to be secure, which provides a robust foundation on which a new generation of embedded systems can be built to drive, for example, internet of things (IoT) applications.
Founding members of the seL4 Foundation include Data61, University of New South Wales in Sydney, HENSOLDT Cyber GmbH, Ghost Locomotion Inc., Cog Systems Inc. and DornerWorks Ltd.
The hosting of the seL4 Foundation is sure to add more fuel to an increasingly fierce debate over the future of operating systems. Advocates of microkernels contend operating systems in terms of functions and size should be kept to an absolute minimum to both ensure security and maximize flexibility.
Rather than loading functions into the operating system, most functions should be accessed in user space above the operating system. That approach allows organizations to take advantage of a modular architecture to swap capabilities out as they best see fit.
However, supporters of traditional operating systems such as Linux and Windows contend organizations are better served by operating systems that run the same functions consistently. Linus Torvalds, who oversees the development of the core Linux operating system, has been especially critical of microkernel-based approaches to building operating systems.
Between those two extremes have emerged containers, which package many of the functions once handled by the operating system into a container alongside application code to make it easier to run containers on multiple variants of operating systems. That shift has subsequently led to increased reliance on lighter-weight operating systems that only provide the basic functions required to run a container.
Microkernel-based operating systems in time most will likely lend themselves better to many emerging use cases, especially on various emerging edge computing platforms where security is a paramount concern. The smaller the operating system, the less attack surface there is to defend. One of the issues that organizations of all sizes contend with today is the stack of software that needs to be defended is a lot larger than they may absolutely require.
Of course, it remains to be seen how much momentum The Linux Foundation can generate for the seL4 project, which currently is supported only by a relatively small number of organizations. The degree to which organizations may back seL4 or some other similar initiative may come down to the degree to which they have grown tired of ceding control over what goes into an operating system to either Microsoft or the oligarchy that currently dominates the development of Linux. Regardless of where any organization falls on that spectrum, the one thing that is clear is given the scope of all the other open source projects supported by The Linux Foundation, it’s probable a lot more organizations are about to become a lot more involved in that debate whether they want to or not.
Linux founder Linus Torvalds, today at the KubeCon + CloudNative + Open Source Summit China conference, warned attendees that managing software is about to become a lot more challenging, largely because of two hardware issues that are beyond the control of DevOps teams.
The first, he said, is the steady stream of patches being generated as new cybersecurity issues related to the speculative execution model that Intel and other processor vendors rely on to accelerate performance. That model is the root cause of malware such as Spectre and Meltdown that have roiled the IT industry. Additional bugs in speculative execution with colorful names such as Fallout and ZombieLoad are showing up more frequently. Each of those bugs requires another patch to the Linux kernel that, depending on when they arrive, can require painful updates to the kernel, Torvalds told conference attendees.
Short of disabling hyperthreading altogether to eliminate reliance on speculative execution, each patch requires organizations to update both the Linux kernel and the BIOS to ensure security. Turning off hyperthreading eliminates the patch management issue, but also reduces application performance by about 15 percent.
The second major issue hardware issue looms a little further over the horizon, Torvalds said. Moore’s Law has guaranteed a doubling of hardware performance every 18 months for decades. But as processor vendors approach the limits of Moore’s Law, many developers will need to reoptimize their code to continue achieving increased performance. In many cases, that requirement will be a shock to many development teams that have counted on those performance improvements to make up for inefficient coding processes, he said.
In the meantime, Torvalds noted updates to the Linux kernel are still coming at a rate of every three months, and the Linux team is basically working on a six-month planning cycle—there is no master five-year plan the Linux team is working from. Roughly 1,500 developers work on contributions to the Linux kernel, with 100 maintainers overseeing the implementation of those contributions.
Naturally, cybersecurity patches at the kernel level have significant implications for all of DevOps. Changes to the kernel need to be absorbed by all the various distributions of Linux, which in turn impacts all the stacks of software that depend on Linux. Jim Zemlin, executive director for The Linux Foundation, said that in the wake of the rise of these hardware issues and previous cybersecurity issues involving open source software such as the Heartbleed vulnerability, cybersecurity is the top priority for The Linux Foundation. As part of that effort, The Linux Foundation is researching various DevSecOps approaches to better securing the global open source supply chain, he said.
In the meantime, organizations large and small alike will need to up their DevSecOps game significantly if they want to continue to push application performance limits.