Free Shipping on orders over US$39.99 How to make these links

The story behind Google’s in-house desktop Linux

If you look around the Google offices in Mountain View, CA, you’ll see Windows machines, Chromebooks, Macs — and gLinux desktops. What, you ask? Well, in addition to relying on Linux for its servers, Google has its own Linux desktop distribution.

You can’t get it – darn it! — but for more than a decade, Google has been cooking and eating its own homemade Linux desktop distribution. The first version is Goobuntu. (As you may have guessed from the name, it is based on Ubuntu.)

In 2018, Google moved its in-house Linux desktop from Goobuntu to a new Linux distro, the Debian-based gLinux. Why? Because, as Google explains, Ubuntu’s two-year Long Term Support (LTS) release “means we have to upgrade every machine in our fleet of more than 100,000 devices without the end-of-life date of the OS.”

It was painful. Add the time-consuming need to fully customize PCs with engineers, and Google decided it was too expensive. Besides, the “effort to upgrade our Goobuntu fleet usually took the better part of a year. With a two-year support window, there was only one year left until we had to go through the same process again for the next LTS. This whole process is a big stress factor for our team, because we get hundreds of bugs with requests for help for corner cases.

So, when Google had enough of that, it switched to Debian Linux (though not just vanilla Debian). The company created a rolling Debian distribution: GLinux Rolling Debian Testing (Rodete). The idea is that users and developers are best served by providing them with the latest updates and patches as they are developed and considered ready for production. Such distros include Arch Linux, Debian Testing, and openSUSE Tumbleweed.

For Google, the immediate goal is to get rid of the two-year upgrade cycle. As shown in the Continuous Integration / Continuous Deployment (CI / CD) movement, these incremental changes are working well. They are also easier to control and rollback if something goes wrong.

To do all this work without a lot of blood, sweat, and tears, Google created a new workflow system, Sieve. Whenever Sieve detects a new version of a Debian package, it starts a new build. These packages are built into package groups because other packages often need to be upgraded together. Once the entire team is established, Google runs a virtualized test suite to ensure that no key components and developer workflows are broken. Next, each group is tested separately with a full system installation, boot, and run in the local test suite. The package can be completed in a few minutes, but the test can take up to an hour.

Once done, all new packages are merged into the latest gLinux package pool. Then, when Google decides it’s time to release it into production, the team takes a snapshot of the pool. Finally, it rolled out the new release ships. Of course, users don’t just drop it. Instead, it uses principles of Site reliability engineering (SRE) such as incremental canarying to ensure that nothing goes wrong.

Over the years, Google has gotten better at this. Now, thanks to Sieve, the entire gLinux development team consists of an on-duty release engineer position that rotates among the team members. There are no major fleet upgrade drives. No multi-stage alpha, betas, and general availability (GA) releases.

Even better, thanks to the rolling release schedule, Google can patch security holes across the fleet quickly without compromising stability. In the past, security engineers had to carefully review each Debian Security Advisory (DSA) to ensure that a fix was available.

In addition, Google’s “enhanced testing suite and integration tests with key partner teams that run critical developer systems also provide a more robust experience using the Linux distribution that provides in the latest version of the Linux Kernel. greatly reduced the effort and stress within the team. It is now possible for us to report bugs and incompatibilities in other versions of the library while ensuring better that Google tools will work within the Linux ecosystem.”

Looking ahead, the Google team stated that it will work “closer to upstream Debian and contribute more to our internal patches to maintain the Debian package ecosystem.”

Everything is very nice. But I have two thoughts to share.

First, for some organizations, LTS releases still make sense. If you don’t need the latest, shiniest programs for your business, an Ubuntu or Red Hat LTS Linux makes sense.

Second, and this is important: The sieve sounds like a cat’s meow. A program that can automate a rolling distro production pipeline to the point where it only takes one engineer to maintain a desktop used by 100,000+ users? Sign me up!

Better yet, release the Sieve code so we can all start making rolling Linux desktop releases. What, Google? What do you say?

Copyright © 2022 IDG Communications, Inc.

Source link

We will be happy to hear your thoughts

Leave a reply

Info Bbea
Enable registration in settings - general
Compare items
  • Total (0)
Shopping cart