Linux runs pretty much everything: all 500 of the world’s 500 fastest supercomputers; most of the public cloud, even on Microsoft Azure; and 74 percent of smartphones. Indeed, thanks to Android, Linux is the most popular end-user operating system, nudging out Windows by 4 percent (39% vs. 35%).
So, where does Linux go next? After covering Linux for almost all 29 years of its history and knowing pretty much anyone who’s anyone in Linux development circles, up to and including Linus Torvalds, I think I have a clue.
Recent Linux kernel improvements
The biggest recent improvement—and nothing else is even close—is Linux will now become the platform for virtual private networks (VPNs). While Linux, thanks largely to OpenVPN, has long been an important VPN player, the addition of WireGuard, a revolutionary approach to VPNs, changes everything.
Torvalds really, really likes WireGuard: “Can I just once again state my love for it and hope it gets merged soon?” he wrote. What Linus wants, Linus gets. Wireguard was merged into the Linux 5.6 kernel in March 2020.
Why is it such a big deal? WireGuard has a rare quality in a security program: Its code is clean and simple. It also comes with state-of-the-art cryptography technology support for the Noise protocol framework, Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, and HKDF.
What’s even more important for users is it’s much faster than its rivals. Benchmarks have shown WireGuard is more than twice as fast as OpenVPN. It’s also cross-platform, so while you can run on a Linux server, your clients can be on Windows, macOS, BSD, iOS, Android, and of course, the Linux desktop.
“Rust is completely memory safe.”
The Linux 5.6 kernel also boasted several other major improvements. First, for those still running 32-bit systems, Linux solved its “end of time” problem. You see, at 03:14:08 Greenwich Mean Time (GMT, a.k.a. Coordinated Universal Time) on Tuesday, Jan. 19, 2038, the world ends.
What will happen is the value for time in 32-bit-based Unix-based operating systems, like Linux and older versions of macOS, will run out of 32-bit numbers. They would then start counting time backward with negative numbers. And you thought the Y2K bug was scary!
It all began because Unix, Linux’s dad, dates the beginning of time in seconds from the Epoch: 00:00:00 GMT on Jan. 1, 1970. The rub was, since Unix started as a 32-bit operating system, it kept time as a single signed 32-bit integer number. Those are a lot of seconds, but it’s not enough. The fix retrofits even 32-bit Linux to use 64-bit numbers. Of course, this only delays the problem until 5:30:08 GMT Sunday, Dec. 4, 29,227,702,659. I’m OK with that.
Android and Linux get into sync
Everyone who pays attention to operating systems knows that Android is a mobile-specialized Linux distribution. What may not be known is that, for many years, Android was a Linux fork. Even now, 10 years after Android and core Linux developers started to work and play nicely with each other again, they’re not quite on the same page. That’s changing.
As Jonathan Corbet, Linux kernel developer and writer, said in his annual Linux Kernel Report, the “latest stable kernel is on its way to becoming part of the Android generic system image, then they will track the stable updates. This will mean they’re much closer to the current state of the art.”
That may not sound like a big deal to you, but it is.
Here’s why. Today, before Linux ends up on that shiny new Android phone in your hand, it goes through three separate, time-consuming stages. First, Google takes a Long Term Support (LTS) kernel and adds in Android-specific code to make the Android common kernel. Next, Google ships that Android common kernel to a system-on-a-chip (SoC) manufacturer, such as Qualcomm. The OEM then customizes the kernel to a specific SoC and chipset. Finally, the SoC kernel goes to the smartphone manufacturer. The manufacturer, in turn, adds its home brew, proprietary drivers for the display, camera, and Wi-Fi/cellular modem. This device kernel is what’s on your phone.
Along the way, every phone picks up literally millions of lines of kernel code not part of the standard distribution. Most of this is device drivers. Each smartphone or Android tablet comes with its own blend of drivers. That’s why making a true universal Android smartphone distribution, such as the /e/ operating system, is so hard. The result? That sharp new phone in your pocket has a 2-year-old Linux kernel. It’s because of these ancient kernels that Linux LTS kernels now come with six years of support.
Google and the vendors are no more eager than you would be to backport security patches to dusty, old kernels. So Google, along with the developer community, is trying to bring the shipping versions of Android in line with mainline, current Linux kernels.
This is going to take a while. A pair of eternal Android problems—the refusal of Linux developers to support a stable application binary interface (ABI) and the equally firm refusal of hardware vendors to open source their drivers—are still with us for the time being. An ABI defines how a program works with hardware when you don’t know how to work with it at an application code level. Open source developers want to work at an API level, while vendors all too often want to keep their devices mysterious hidden data that can be reached only by an ABI. Despite this, we’re finally closer to speeding up the integration of Linux in the Android production pipeline. This means Android will be more secure out of the box.
eBPF: The network firewall that became a Linux debugger
Corbet also talked about the continued rise of the extended Berkeley Packet Filter (eBPF) as a powerful Linux kernel debugger tool. How could that possibly happen you ask? Like this.
While eBPF, like any firewall, can capture, filter, and block network packets, it does this by running user-space code inside an in-kernel virtual machine. Ah, you begin to see.
You can make eBPF run in response to activities on tracepoints, kprobes, and perf events. This enables you to debug kernel problems and run performance analysis. Better still, since eBPF programs can access kernel data structures, you can write, add, and test new debugging code without recompiling the kernel. This is a major time-saver for busy developers. Now, system administrators and programmers outside of the Linux kernel’s inner circle are beginning to use eBPF’s power.
Rust becomes Linux’s second language
Since day one, if you wanted to develop in the Linux kernel, or anything that runs close to it, you had to do it in C. Indeed, you could argue Linux is the reason why C remains a popular language. Not anymore.
At the virtual 2020 Linux Plumbers Conference, where the top Linux kernel developers hash out Linux’s future, they talked about introducing Rust as the kernel’s second language. Rust is a high-level system language that is sponsored by Mozilla, Firefox’s parent organization. Believe it or not, this notion is receiving widespread support. Torvalds himself is sure Linux won’t end up being written in Rust. But then, that’s not the goal. No one’s going to rewrite the kernel’s 25 million lines of C in Rust.
Led by Josh Triplett, Rust language lead, and Nick Desaulniers, a Google engineer, they proposed using the system-level Rust language inside the kernel. Why? Because, it’s much safer than C, especially when it comes to handling memory.
As Ryan Levick, a Microsoft principal cloud developer advocate, explained, “Rust is completely memory safe.” Since roughly two-thirds of security issues can be traced back to handling memory badly, this is a major improvement. In addition, “Rust prevents those issues usually without adding any runtime overhead,” he said.
Torvalds sees the advantages. While he’s encouraging a slow but steady approach to introducing Rust into Linux, he has also said that using Rust interfaces for drivers and other non-core kernel programs makes sense: “I’m convinced it’s going to happen. It might not be Rust, but it is going to happen that we will have different models for writing these kinds of things, and C won’t be the only one.”
While the core kernel developers are moving slowly, other Linux distribution developers have wasted no time in adopting Rust. Amazon Web Services (AWS) has announced that its just-released Bottlerocket Linux for containers is largely written in Rust.
Like Microsoft and Firefox, to name two others incorporating Rust into their development plans, AWS likes Rust for its memory security features. Samartha Chandrashekar, an AWS product manager, said it “helps ensure thread safety and prevent memory-related errors, such as buffer overflows that can lead to security vulnerabilities.”
Looking ahead, it’s clear that Rust will soon be playing a major role in both Linux kernel and distribution development. Who would have ever thought that C would be displaced in even a small way in these programming circles?
Linux 6.0 Kernel and beyond
By the end of the year, Linux 6.0 will appear. But don’t get too excited about the number. As Torvalds said about the 5.0 release, “I’d like to point out (yet again) that we don’t do feature-based releases, and that ‘5.0’ doesn’t mean anything more than that the 4.x numbers started getting big enough that I ran out of fingers and toes.”
Looking ahead, most of Linux 6, like almost all Linux releases, will consist of new and improved hardware drivers. One prospective change, however, will be noticed by everyone: Linux will finally support the AMD and Intel FSGSBASE instruction set. OK, unless you’re a seriously hard-core developer, I’ve just lost you. Here’s the important thing about Linux supporting this chip instruction set: Your machine will run significantly faster.
How much faster? Early benchmarks with the first Linux 5.9 beta show significant I/O improvements. With Redis, the open source, in-memory data structure store, which is often used as a database, there was more than a 50 percent performance boost. That’s none too shabby!
So what it all comes down to is Linux is continuing to improve both its speed and security. And, as amazing as it may seem, Linux is continuing to expand its markets, thanks to its newly integrated WireGuard VPN.
Who knows? Perhaps, 2021 will be the year of the Linux desktop. After all, 2020 was the year of Linux on the Windows desktop.
What’s new in Linux: Lessons for leaders
- Systems running on old software are probably not running as well as they might.
- New generations of software, certainly including Linux, create new technology and business opportunities.
- Operating systems are not a completely mature technology; there are still big improvements to be made
