Google’s in-house desktop Linux
computerworld.com
computerworld.com
My first "real" job as a sysadmin had this kind of setup, albeit with Sun servers and workstations running Solaris 8. I was impressed by how well it actually worked most of the time given all the quirkiness of kerberos/nfs/nsc/etc..
It did NOT go that well, but was a good learning experience.
"can someone telnet to 10200 on my box to reset nscd!?"
For early startups, I've been doing "Debian Stable" as the default, partly so that we don't have to spend any time on any surprise distro changes when we're focused on MVP, etc.
And in 2 years, the startup will probably have a lot more resources, and we can look at whether that still makes sense, though we might just end up doing an in-place APT `dist-upgrade`, or coast on `oldstable` awhile if the timing is not right yet.
I also try to use the same distro on workstations and in production, to permit lightweight efficiencies, like experimenting and debugging outside of containers on workstations, without special tooling, while still having a close match to production. So, Debian Stable everywhere.
A recent Ubuntu LTS would also work for this (and sometimes be easier for things like Nvidia SDK), though Debian has been arguably a bit better for security and stability lately.
For things not in the Debian Stable we're using, such as if we need a bleeding-edge version of some key thing, and we have big security/reliability requirements... I manage non-Debian-packaged third-party dependencies in our own Git repo, and track and vet updates. This also means trying to minimize these dependencies, more than we would if we were pulling in 100 packages casually from a language-specific package manager, since each package is additional work.
Even just the git has many releases during Debian Stable/Ubuntu LTS, which enhance user experience, that holding back users is not the best idea. And in most cases security fixes land first in the newest versions and are backported, so it is most likely to have a fix in HEAD than in some random older release.
So I might be two years out of date on ls, but it probably hasn't changed in the last 2 years anyway.
If I knew about Arch earlier I would have switched, because it sounds like my kind of distro - but I have to much customizations and too much kids to have time for that right now.
I never quite get why people want they development environment be similar to production - you install IDE on production? Or you just code in vim/emacs/ed without any plugins (because production doesn't need it)?
Debian Stable tends to hand pick the latest LTS version of packages everywhere applicable, so it's actually a good base to standardize on. Packages might be a bit older but they are reliable, predictable, and kept secure by a constant roll of security updates.
In other words, if it doesn't work on the latest Stable, you're probably moving too fast for a good part of the industry. Lots of customer and production stacks are not in the "move fast, release early, release often, and link the crap to the very latest bleeding edge dependency" bandwagon.
The whole point of stable vs testing is that versions are fixed, reviewed security updates make it, it’s all tested and vetted.
On the other hand, testing and backports haven’t been tested as well and could have issues.
If we use stable and incorporate backports from testing, is it still stable?
The "best" user experience you're referring to is getting surprises like your OpenSSH 9 suddenly stopping to work with your key agent [1] out of the blue because they decided to change the protocol (no big deal right?) without any hint of this whatsoever during normal usage, and you just casually upgraded your packages because, well, when did Linux package upgrades ever hurt anybody?
(Just the latest incredibly frustrating surprise your fellow "Windows person" literally had to spend hours on tracking down. And that I actually remember. Most definitely not the only one.)
It just so happens the software you mentioned, git, is in stable backports, so it is updated frequently. Regardless, I've been on Debian stable since 2007, and running "bleeding edge" stuff is trivial, depending on your desired workflow. (For example, I just install Debian testing packages in a schroot.) I used to bounce from distribution to distribution in the old days (Red Hat, Mandrake, Slackware, Gentoo, etc.) but once I found Debian Stable I could concentrate on getting work done.
For me it’s definitely been browsers and IDE’s, but I just install those to /opt.
Most of breakages of Linux was my own doing (e.g. by mistake overwritting MBR).
I use testing+unstable (I didn't know that backports exists, thanks) + self compile some software that doesn't exist in either or is too old. I also always compile kernel, prefer it to have less modules and configured towards performance on desktop.
It’s really nice to have the rest of the distribution more or less set it and forget it.
Windows users might be accustomed to having infrequent OS version releases, but they're used to their _apps_ being current.
(And, as another reply mentioned, you'll miss out on a lot of usability improvements to development tools by running stuff that's 2 years old or more)
> For things not in the Debian Stable we're using, such as if we need a bleeding-edge version of some key thing, and we have big security/reliability requirements... I manage non-Debian-packaged third-party dependencies in our own Git repo, and track and vet updates. This also means trying to minimize these dependencies, more than we would if we were pulling in 100 packages casually from a language-specific package manager, since each package is additional work.
Making it harder to have up-to-date dependencies is costing you far more than you're saving by not upgrading frequently.
For better or for worse, I think this is partly where my preference to use rbenv, pyenv, asdf, etc comes from.
The other part was from hosing my system installed pip packages for the Nth time because long ago I didn't fully understand pip (still don't, but I didn't then either) and I used a mix of "pip install" and "sudo pip install" when the former didn't work. I could only work on one thing at a time with this approach, and switching was a huge task because I had to figure out all the places where packages had landed and either remove them individually or blow the whole thing away.
For my development needs I prefer Debian Stable and install the dev tools locally in my home directory rather than using the packaged versions.
Since I don't share those boxes, it works well for me. I keep up with the frequent Android Studio / VSCode updates that way.
At that point you end up manually doing the job of a package manager.
Not if you're separating where you live from where you work - in a manner of speaking. Applying global changes to your system (e.g. using package manager to install a specific versions of packages required by your production app) is a terrible, terrible idea that will cost you more than isolation (standardized docker, dev VMs or similar, which ought to reflect your running environment). Debian stable provides a good workstation environment - the actual work should not be done against Debian-blessed packages. The opposite is true - your workstation packages should not be dictated by the needs of your prod software.
> Applying global changes to your system (e.g. using package manager to install a specific versions of packages required by your production app) is a terrible, terrible idea that will cost you more than isolation (standardized docker, dev VMs or similar, which ought to reflect your running environment).
Why? Your system is (or should be) a single-purpose tool. It absolutely should be managed and reproducible (using something like puppet), but keeping everything flat so that you're working on the same "bare metal" that your application works on has more advantages than disadvantages IME. (E.g. it's hugely helpful to be able to fire up a random REPL, integrated with your IDE or similar, and have the same versions of your libraries available that your application uses).
Stability. My assumption is that one would be using their workstation for tasks much broader than the production environment: development, debugging, slideshows, video conferencing, screen recording, etc. Without execution boundaries, it's almost inevitable that there will be incompatibilities.
Stability of the prod software may be impacted, when something on dev environment (and only on a specific dev environment) because the engineer added an implicit dependency on some aspect of their environment inadvertently.
Ummm.. No? Ubuntu LTS has a 5-year support window. Not 2.
Or maybe it didn't all the way back then? I don't recall.
A rolling distro does make sense though. Especially in a large org where you have a relatively homogenous usepatterns. All the edgecases you can find centrally and pre-empt them before rolling out the updates.
https://en.wikipedia.org/wiki/Ubuntu_version_history#Version...
Internal users demanded the upgrade every two years anyway.
Most of their server estate will be Linux based, including what's powering their desktop applications. But almost none of their efforts give back and enrich the desktop ecosystem. That said they do contribute a lot towards frameworks, libraries and the kernel. Certainly they are among the top alongside Microsoft in recent years and Facebook. So I do recognize my entitled call for more... with good cause
I cannot imagine that Google engineers would live with such deeply broken systems as daily drivers. So whatever that secret is, whether it consists of drivers, known hardware configurations, or even just config files they use to ensure optimal operation – that's what I'd like them to Open Source. I'm happy to buy whatever laptop spec Google uses for gLinux for myself to go along with their OS.
I have a manually crafted autorandr config but it's kind of hit and miss.
Then your imagination could be improved in a few ways:
1. Google has complete say over the software you're allowed to run at work. They can mandate using whatever tools they want as terms of your employment.
2. Google has complete say over the hardware they purchase you. Random drive incompatibility isn't a thing. They pick hardware that's been validated to work so they don't have random IT complaints.
3. This is a IT / compliance / security thing. The grand total of UX people dedicated to this probably amounts to designing the splash screens. The grand total for bug fixing is for issues impacting an obscene number of users. If you f'ed up your OS install you'll basically have to fix it yourself (IT will offer to reimage your machine and you'll be responsible for making sure you correctly managed your backups by hand - you get limited storage space at least when I worked there, so you had to make sure to exclude certain folders from backups).
4. They do have a slightly better story for Android development but most of that relies on Google3 / Blaze. I think they're doing some work to migrate to Bazel finally but I imagine they'll always have a bit better internal dev story.
About the only value-add they could be giving here is the hardware configurations but they're not really different from stock Linux laptops you'd buy as a consumer.
I have these problems with the Dell laptop running Windows 10 which I use for work, but not with my own desktop or laptop running Fedora. So, my experience is more or less the opposite apparently. This makes it harder for me to buy the theory that there's something uniquely inferior about these Linux desktops.
For example, my work laptop, a Macbook Pro, is always on my desk in my office. When I'm working, I have an external monitor plugged into it. If the laptop goes to sleep, then a bit later the monitor goes to sleep. But when the monitor goes to sleep, the laptop wakes up. Then a few minutes later the laptop goes to sleep and starts the cycle again. So every evening when I'm done working I have to unplug the laptop and manually put it to sleep. Then every once in a while (rarely, but multiple times this year) something else keeps waking the laptop up, or maybe I accidentally wake it up and don't manually put it to sleep again, who knows. When that happens, I have a dead Macbook Pro on my desk in the morning, and I say, "[Stuff] like this is why Linux on the desktop will never be popular.
The previous time I used a Mac (2015ish), it was the other way around.
Maybe I need to run OpenBSD.
Heh, most use Macs. Linux laptop users have the same problems, don't worry. My laptop hard locks up on suspend once every couple weeks, plus all the things you mentioned. Oh, I also have a weird audio latency bug.
A large IT team.
Hey there, Google engineer here (opinions are my own, etc etc). I work in the ChromeOS platform team. We have hundreds if not thousands of very talented (not me) engineers who work on low-level firmware, drivers, kernel, performance optimization, etc on Linux. ChromeOS is still Linux and almost entirely open source[0], we also upstream most of it[1]. A lot of the improvements that ChromeOS has had for multi-monitor support, plug-and-play devices, wayland, keyboard/touchpad firmware, etc have all entered mainline Linux kernel and should be perfectly usable by the whole Linux ecosystem and other distributions.
I don't work with the gLinux team anymore (used to in the past) so I don't know how what exactly they do with their stuff, but regardless of the "it's not a real linux distro!" hate ChromeOS might get, we still run on a fully open Linux environment ourselves.
[0] https://source.chromium.org/chromiumos/chromiumos/codesearch
[1] The stuff we don't upstream it's usually because either we can't (ChromeOS-specific hacks that the Linux kernel mainline wouldn't accept) or we haven't been able to yet due to needing to clean up patches before they are accepted. Regardless we'll still open source it in our kernel tree
I am interested in working on this. Do you know if there positions open and where and which group to apply?
Bluetooth accessories are not guaranteed to work. People struggle with screen configurations all the time. Nvidia driver updates are still a nightmare. I'm pretty sure there's no secret sauce.
> Bluetooth
Bluetooth is a dumpster fire and Linux bluetooth is a radioactive biohazardous dumpster fire. Stay away. My workaround: Linux -> SPIDF -> 1Mii B03Pro bluetooth transmitter. The chipset drivers that output 3.5mm and SPIDF are ancient, stable, and dumb as rocks, so they actually work. SPIDF beats 3.5mm because 3.5mm can detect connectedness and punish you by scrambling your sound settings every time you bump a cable. SPIDF can't do this so software can't screw it up.
Also, even if you get linux bluetooth working it will tend to scramble if you reboot into a different OS. Just say no. Use an external bluetooth transmitter.
BT is just a disaster everywhere. My experience is that for "normal" use cases (input devices & headphone audio, basically) Linux is no worse than anywhere else, but still bad. Apple users think it's great because Apple made AirPods work, but that's a testament to Apple's integration engineering and not the underlying technology.
> Plugging in a new display doesn't immediately work
I haven't seen this with Intel drivers on a major distro in a long time. But yes, the driver story for other hardware remains somewhat weak. And obviously the farther you get from "Gnome on Ubuntu/Fedora" into the weeds of desktop choices, the weirder the feature set is going to get.
> A USB microphone fails to register as an input sound device
No idea here. I haven't seen a USB audio failure in a LONG time (closest I can think of is a Razer headset that has two chat/game output streams and Linux sees only one by default). Mostly likely you had a broken piece of hardware that worked in windows only by installing its own driver. And that sucks, but poor standards compliance is just something we all live with.
So no one outside of apple is smart enough to get it working.
What bothers me about non apple stuff is. I can pair my AirPods to my phone, tv, and laptop. Even if they connect to the laptop if I press connect on the Apple TV or phone they switch.
With any non apple headphones. (Bose, Audio-Technica, Sony, Asus) I have to press Bluetooth pairing button and connect on the decide again. So switching between two laptops is a pain.
Why can’t other brands do what apple can? It’s not the tech problem when someone solves it…
Pretty much, yeah. And the reason is that Bluetooth is a disaster of complexity. One implementer thinks function X in state Y means "frob", but another interprets that as a "glim" command. Apple makes it work by controlling variables: their controller, their driver stack, their library framework, their app integration. If one team doesn't understand why another team's layer is doing something, they walk across campus and ask them.
You have to have the capability and be given/assigned the time to do it properly.
Things that are genuinely a mess (e.g. bluetooth?) often only work smoothly when there was a mountain of effort put into it - that consumers can't see.
Eeehhh... Specs are big, complex documents with fuzzy terms like SHALL, MAY, MUST and weird corner cases that no one thought of, being read by engineers with varying linguistic prowess, implementing them in disparate hardware and software vendors with radically different manufacturing/release pressures, different skillsets, different interpretations of the same damned specs... It's a wonder any of this shit works at all.
Apple's the only vendor out there with something approaching a consistent experience because they're the vendor with the greatest degree of control/integration over the entire stack. BT, ACPI, all the same.
What problems are you running into?
Oh yes, yes they do.
Anecdata, my airpods have been pairing seemlessly with Xubuntu out-of-the-box for over a year. I've similarly not have had any problems pairing with my Bose portable speaker or soundbar.
> Bluetooth pairing fails occasionally.
I never had this issue on Linux until my most recent laptop, which shipped with a Qualcomm 1103 card, which gave me no end of issues with Wifi and Bluetooth (resume from sleep failing, weird power drain, random drop outs).
I swapped out the wifi/BT module for an Intel wireless card (AX210), and all the above problems immediately resolved themselves.
Maybe it's just the bluetooth hardware?
> Plugging in a new display doesn't immediately work.
I've honestly not had to worry about this in at least ten years across ~8 different machines. It's just worked on all three major graphics vendors. I haven't used Wayland yet, so I don't know if if that's a factor.
I just chalk it up to the freedom I get from using Linux and just move on.
It was all really short lived though. I remember that uploader broke fairly quickly as, of course, some abi change in some library dep and of course there was never another release.
It's not really what's missing... it's just google's 'here today, gone tomorrow'. They really shouldn't be called engineers.
The fact that this effort is going towards this OS tells us they don't care about open-source and especially the Linux Desktop either. It is only to the Kernel which is fine, but it clear that the wider Linux Desktop ecosystem has had the same 20 year old issues still present today.
Is it a security thing? Are Googlers not allowed to directly control their own computers?
For example, security aside, as an engineer working on X that depends on internal tools Y, Z and W, I do not particularly care what variant of Linux is under the hood as long as I can run my favorite WM, editor and user apps. But I do want support on Y, Z and W if they misbehave. If I run a non-standard OS or distro I will likely get a lukewarm support because those teams will put debugging problems in "non-standard configurations" as a low priority.
Personally, I learned to live with most Linux distros. When I did roll out a non-standard setup I had a standby system in a standard configuration that I can show failures on before asking for help. My 2c.
Not to mention all the non-engineers, even in tech roles like PM, design, etc.
* By default, a tool called “Santa” keeps a naughty and nice list of runnable programs but all it took to get a program added to the nice list is any other googler vouching for it in an automated web tool.
If something doesn't work, they can communicate back to the (well-bearded) developer who sent them that weird build. The developer surely has some crazy esoteric distro on their bring-your-own device, but they also have desktops running the consistent distro available to them all around the office to reproduce the issue on. It's a bridge between worlds.
I work in academia and we manage our own Ubuntu spin for this reason, despite everyone we ship it to being very conventionally smart.
> if you're smart enough to work at Google, you're smart enough to manage your own OS.
I also like to think of myself as "smart" for self-managing most OS and cloud things. But the role of smarts is probably minor compared to the decade+ of experience I have doing it. When it's something I'm good at, I think it's because of intelligence. When it's something I can't do, I assume the people who can have lots of practice.
Nope. If you want access to more than just the basic corp resources, you’re doing it from a fully managed and approved OS on a company owned machine or VM.
First, if the computer is provided by the company, for company work, they're not "their own computers." They're the company's computers. And I don't know about Google, but yes it is VERY common in most mid- to large-size organizations that employees are not allowed to change things on the machines they use for work.
The IT department is usually required by either contracts or regulation to follow certain security standards and many of those prohibit end-user modification of machines. And further, these are often enforced through annual, semi-annual, or quarterly audits. Failure to follow these standards can result in the loss of a sales contract, a critical certification, or fines.
So, just like a manufacturing worker is not allowed to modify a machine on the factory floor (even to fix it, or improve it, regardless of their skill to do so), employees are not allowed to modify the organization's computing equipment.
And, it's important to note, the IT department generally has NO say in these rules since they are a business or legal requirement.
Edited to add: I've also worked in companies where the developers who write the in-house software might be masters of the business problem domain and their programming language, but have exactly ZERO knowledge of hardware or the most basic system administration principles. It doesn't cross their mind that RAM and disk space are actually finite things, for example, and that it makes for a Bad Day when one of their programs starts to consume ALL of it. These are the people who should not really be managing their own operating systems at work.
of course I was trying to get my brilliant colleague without a degree, noticed with that code; zero response, like stonewall. Later I read, that year Google got over 1million job applications.
weird place
What you didn't know is that it wouldn't work.
There is also an expectation that you don't just randomly start changing things in shared conference rooms. If there is an issue, you open a GUTS ticket and someone comes and solves the problem. Chances are if you discovered a real issue, there are 90 other rooms with the same issue that also would be updated.
Most bigcos are the same way, there’s a way to get root but there’s also security software or policies to counteract damage you could do. With most hardcore “zero-trust” setups you consider a device’s posture based on its current state and don’t take into account whether or not the user has admin rights (what do you care how what rights they used to install bad software, you just care that they installed bad software). No admin rights typically means nobody has time to do something better for end users or there’s a regulatory requirement (at the same time, bigcos can throw a sandboxed VM up in their data center that can’t access PII if devs need more access).
Or your software has all these customization options
Or your product has a bunch of different configurations
What was already hard just became a thousand times more painful
There's a tremendous value in having a somewhat homogenous environment. We have our own package repo and .deb packages to access internal resources. Even little stuff like editor plugins customized to our internal stuff we have packages for.
Plus, we hire a great deal of folks that aren't Linux experts. Have a sane set of defaults gets people going faster.
It makes a lot of sense to have our own distro when we're talking this kind of scale.
Smart isn't really a key point here. You can be smart and make choices that solve your immediate needs but may not be good for the company in the long run. The distro provides for some standardization and baseline in among other variance.
> Is it a security thing?
Yes, one of the forms of standardization are audit solutions that keep track of all kinds of data about the machines. In the time I worked there, I once received outreach because a service I had started on the machine had retained an outgoing port to a third party service provider for an extended period of time. I explained what it was, and I did not get in trouble, but I also shut it down. There are many other forms of audit systems.
> Are Googlers not allowed to directly control their own computers?
It depends on your role, but many roles have root on their machines. You can of course do just about anything from there, however some things may get undone by periodic scripts if they're defensive (e.g. removal of certain software), or in other cases trigger some kind of outreach as described above. For certain other policies, you may need to file a bug with a business justification to request specific policies - you can also do this for entire teams if it applies to their work.
No disrespect to you but this is a really naive take on how IT management works.
For one thing, not everyone at Google is an OS expert. There are people working for Google in marketing, sales, support, data science, graphic design, hardware design, and other fields where you can't depend on every person to "do the right thing" when it comes to "managing their own OS."
And even if they can, is that where you want them spending their time? Manually managing their OS? Don't you want them to do the job they were hired to do instead? Their computer is a work tool, not tinkertown.
Basically, the opposite of what you're saying is true: because 100,000 people work at Google, each person represents another way to potentially mess something up and cause problems for the whole company.
Assign each employee with probabilities:
- Probability of falling for a phishing scam
- Probability of installing malware
- Probability of an employee missing an announcement regarding OS/security policy
- Probability of an employee opening a support ticket with IT
These probabilities are very low for people who are computer-savvy, educated, very highly qualified people. The thing is, all you have to do is multiply those probabilities by 100,000 and now you've got a big problem.
It's much easier to run with zero IT automation if you've only got 10 people in your company and they all know each other.
For your probabilities, you describe many issues that aren't big issues at Google. Phishing credentials is mitigated by mandatory FIDO tokens, binary whitelisting heavily reduces installs of malware, security policy isn't needed on these desktops (really just needed for mobile devices incl laptops).
I just explained why it doesn’t matter that “most” people can manage their OS, that’s because Google has thousands of Linux users. If 1% of Google developers make a critical mistake that could be a hundred workstations or more.
On top of that, I still disagree. Many developers I’ve met are not that good at using the OS.
Remember that writing applications is a completely separate skill. You can learn to code completely separate from learning anything else about the computer. I had a college professor that taught C on a chalkboard, in this millennium.
Google’s own developer interviews are very CS and algorithm heavy and to my knowledge never test your abilities with OS management.
When you say “really just needed for mobile devices including laptops” that’s basically all devices isn’t it? You’d have to be incredibly specialized to need or prefer a desktop workstation.
I haven’t even brought up compliance controls and certifications yet, either. If you’re SOC 2 or HIPAA compliant you have to manage workstations to disable functionality and restrict system preferences. For example, there are typically restrictions on USB port data transmission and idle screen lock delay time.
This is a bit like saying if you can operate on human brains, you should absolutely be able to take apart your car and put it back together.
We’re root on both desktops and laptops though, I just rather use my time for work and I’m sure my employer would rather I do that too.
I don't really understand what "messing around mean" in your context. Exotic things like slackware or alpine aside, all major popular distros now offer unattended updates, easy upgrade path between major releases.
Your vscode, neovim, jetbrains whatever or emacs do not work differently from one distro to another and since nowadays many external stuff is either distributed as static binaries, containers or flatpacks or appimages everything is quite straightforward and not distro specific.
Actually one of my favorite Google experiences starting out was that I wanted to work with an Apple Magic Keyboard, and to get proper support for it I needed to compile some kernel driver I found on github. I asked IT support if I can do that, and the answer was "you're a SWE, review the code, make sure it looks legit and doesn't contain any security holes, and then it's your responsibility if you mess anything up". Which I did, and it worked just fine. It was in 2018 so it's not like I'm referring to some early days thing.
I would absolutely despise it if I had to manage my own OS, just like I despise thinking about my keyboard layout or text editor.
Hacker News overrepresents the hacker type which loves the feeling of full control but I'd estimate that at least 33% of engineers, including many very talented ones, don't want that, and only want to focus on the concrete problems they are trying to solve.
> Is it a security thing? Are Googlers not allowed to directly control their own computers?
This and simplicity I think. There's definitely some controls over what kind of things you install on the MacBooks as well, though it's actually not that restrictive.
Regardless of the scale, that is a recipe for having your highly capable, highly paid engineers losing hours, days, even worse - to annoying configuration issues etc. Sometimes it's the right thing to do (e.g. very early stage, no IT infra) but if you can have an IT person who is actually good/experienced at this sort of thing sort out the core problems, it's way more efficient.
It's astonishing how much collective time can be wasted on "well, it works on my machine" issues. This makes it worth coming up with some sort of systematic way to avoid (mostly) it.
Oh boy, have I got some stories to tell you!
Although to be fair the question of who "manages" a workstation is not always as simple as just "who has the technical ability to manage it". It's the intersection of who is legally responsible for the device and it's data (this is BY FAR the most important part), who has the time to maintain it (that's often NOT the user), and who technically can maintain it according to whatever standard it has to be maintained to (this gets complicated when you factor in reporting, patching etc).
In my experience, a common approach on non-Windows systems is to give the users privileged access to do what they need to do while also monitoring that closely, managing patching for them, and if you have some legal requirement to do so; running some kind of AV for reporting purposes. This tends to strike a happy medium between giving IT/Security peace of mind to some extent while also not totally ruining the developer experience.
https://debconf22.debconf.org/talks/11-scalable-support-for-...
That must have required an impressive amount of effort!
> Better still, thanks to the rolling release schedule, Google can patch security holes on the entire fleet quickly without compromising stability. Previously, security engineers had to carefully review each Debian Security Advisory (DSA) to make sure the fix was in.
I can only imagine Google upstreams an incredible number of patches from this process.
[1]: Are they still called Googlers?
Most of Google's services have a corresponding iOS app which requires a Mac to build / run a simulator. So if you're not actually picky about computer then it's more practical to have a Mac as it can handle debugging for Web/Android/iOS.
If you're at a desk you can have a dock with a different keyboard.
When your choices are:
1) A 16" MBP with an awful keyboard layout (death to the Command key, and put Ctrl in the corner) but a great screen and battery life
2) A Chromebook that's straightforward, reliable, but for some reason not available in a size >13" with a resolution >1080p (so a dealbreaker for development for many people)
3) A Linux laptop with all of the fun bluetooth, driver, and battery quirks that implies
Many people will choose #1. OS X is by far my least-favorite desktop OS for a wide variety of UX reasons, but when my workflow for the most part requires browser windows, terminals, and enough pixels to use many of them at once the 16" MBP is a pretty good choice (when I'm not paying, at least).
OSX lets me remap caps lock to control without digging in the registry or playing "find where they moved Xorg.conf." It's just an option in the preferences.
Emacs movement shortcuts like C-a and C-e (move-beginning-of-line and move-end-of-line) work everywhere out of the box. ^C can be kill and ^p can be previous-line because they don't collide with copy and print, so terminals Just Work instead of each having their own convention to memorize. Also, for some reason the OSX terminal is the only one that reliably gets SIGWINCH and unicode reliably correct, and has for a decade. It's weird that linux terminals are so bad at this, but whatever.
This is what good design looks like.
For native apps. Sort of.
* Though you can assign Ctrl to the Fn key, you cannot assign the Fn action to any key so you can't swap them without giving up the ability to use the Fn key at all.
* This doesn't work for web apps. Google Docs etc. will still use Command key shortcuts and will thus be different locally versus remoted into a machine.
* Some key mappings break in text boxes. I've remapped Find to Control+F, which works most of the time, but not if my cursor is in a text box, because then it moves the cursor forward. Control+B for bold and Control-A for select all are likewise. To make it worse, this only happens for certain text boxes, and heck if I can figure out the pattern.
In all, it's an incredibly frustrating experience.
Don't remap Cmd+<key> shortcuts to Ctrl+<key>. The great thing about the cmd key is that it doesn't conflict with anything else. Ctrl-f is forward, ctrl-b is back, ctrl-a is beginning of line, etc, these have been around in emacs (readline?) for a long time and it's great that native os textboxes implement them. This is why it's inconsistent; bad apps use their own snowflake controls and fail to implement them.
cmd-<key> don't conflict which is why they're used. Ctrl-c meaning both SIGINT and "copy to clipboard" is a disaster on terminals, the cmd-c life is much better. By trying to remap cmd to ctrl you're working against the OS and the OS will fight you back because it's not designed to do that.
In Linux you just have to add 'include "capslock(escape)"' in xkb symbols file and it works on any Linux distro. I just set it up in my dotfile installer in 2013 and never had to fiddle with the interface since.
I never have to wonder "where did they moved the option in the interface this time?". It's just a script I have to run when I set up a new distro install.
The only folks with Apple desktops were people doing iOS work and I think they may have had linux desktops as well.
It was fairly easy to get another linux "desktop" which was really just a virtualized linux machine in the cloud.
[1] Yes, still called googlers.
My experience was that the only encouragement one way or another was toward trying ChromeOS a first, and switching away if you wanted to later.
You can get a Windows machine, but they are not trusted devices and you can't access a lot of stuff. (At least that was the case a few years ago when I left)
Consider this happened after 2011.
Having a few different Linux distros at Google, okay then.
At one point, I had a RHEL5 desktop in Seattle, which I could (and had to) develope remotely on from the Toronto office[0]. The software libraries we used depended on something that RHEL5 had and newer versions of Red Hat didn't, as I understood it. Eventually a new and fantastic manager joined the Toronto office and convinced senior management to at least ship the desktops to Toronto.
[0] At the time, the 'office' was the warehouse in Mississauga.
In today's world with tools like Nix and more hermetic build systems that include libc, the need to build on RHEL5 wouldn't exist.
Of course it's always good practice to test on the environment you're going to eventually deploy.
Of course, it’s not officially supported by anyone, so when the (very) occasional bug does hit, you have to sort out rolling back to something that works yourself. Sounds like Google automated this side of things?
Googles change to debian-testing reflects my own rite of distribution passage. I used manual /etc/apt/sources.list upgrades within Ubuntu so often, after Unity was abandoned, there was no reason to stay on Canonicals flavour.
After a year on testing I went to unstable and subscribe to bugs affecting me from time to time. Usually there's either quickly a workaround or a flatpak as last resort. Not something I'd install on the family pc, but testing or unstable is a good choice for developers.
Contributing to Debian and adjacent projects like GNOME and freedesktop.org got easier (or standardized?) since they all run a gitlab instance each.
They could have simply done what Manjaro did: start as Arch, add some packages and over time fork completely and manage your own testing and stable (by getting inputs from mainstream Arch)
EDIT: The only FOSS license I know about that doesn't do this is AGPL, which Google is known to be extremely averse to.
* The OpenWatcom license requires source code publication on use. This was approved by the OSI but not FSF, which means its one of the few times a license can be described as Open Source but not Free Software.
* SSPL extends AGPL's copyleft clause to include support utilities, which didn't pass muster at either OSI or FSF (which is inconsistent with the OSI's prior opinion on OpenWatcom but )
IMHO, Google's not wrong to reject AGPL. The license makes it very difficult to use modern fork-and-pull-request workflows unless you write all your code to be a quine. And the lack of people using it makes it mostly useful as an exception sales vector rather than a legitimate renegotiation of the copyright bargain like GPL is. But Google's objection to it is rather weird, based on some hypothetical scenario of "GPL virality" making them publish internal tools. This is a misreading of underlying copyright law; I have yet to see a court demand specific performance of any source code publication requirement[0]. They will give you money damages and possibly an injunction prohibiting use of the specific application in question - not your entire internal stack.
[0] Practical example: that one time Atari hired a subcontractor to republish old Humongous Entertainment games on Wii and wound up infringing the GPL on SCUMMVM. Atari actually considered GPL compliance, but then realized that this would violate their obligation from Nintendo not to disclose game source at all.
http://sev-notes.blogspot.com/2009/06/gpl-scummvm-and-violat...
What do you mean? AGPL means that you have to open source your server stack, which of course proprietary server-software-based companies don't want to do.
Read the GPL...
If you want a mature, maintained Drive integration on Linux you can have it right now with ChromeOS.
https://source.chromium.org/chromium/chromium/src/+/main:chr...
Google barely squeaked by with $76 billion in revenue last year. It only has 156,500 employees.
You can't possibly expect something like that from a company this resource-constrained.
Per https://abc.xyz/investor/, Alphabet made $75 billion in Revenue in Q4. They made $76 billion in net income for all of 2021.
And that's why we now have N open source third party syncthing interfaces and no clone of the GDrive client.
* Google doesn't see enough gain in supporting a Drive client for Linux
* Linux users don't see gain in feeding the beast
... so nobody dedicating their finite lives to solving this problem is win-win.
Quota enforcement was a blocker for official Drive linux support because it would have made the abuse issues even worse. (Not saying its going to happen now, but one blocker has been cleared)
I left in 2017, and I was one of the last SWEs to use a Linux laptop. Everyone had moved to a Mac, after the Christmas Windows security disaster (which I won't detail here). It was pretty much forbidden for a SWE to use Windows, and for a while Linux had a lot of users but over time it became all Mac. Finally in 2016 I caved in and drank the Kool-Aid too.
I'd go to the Tech Stop for something or other, and the staff would never object, since, after all, it was the official Google Linux. But you could tell that they didn't see this very often.
Side note: the Tech Stop staff were some of the best, nicest, and most competent people I ever encountered in that role.
Furthermore, whatever I needed seemed to almost always require them to keep it overnight and wipe the machine completely.
Like I said: it was not unheard of to use one -- just a bit unusual.
Not quite. There is security hardware there, as I recall.
I think I fell into some bureaucratic limbo because I joined near the beginning of covid lockdowns. I don't think my recruiter fully understood my request for a Linux laptop either, and there was a general shortage of them at the same time.
Categorically not true, not then, not now.
I am a gLinux user. Before google I just installed linux on my laptop at previous companies.
But clearly remember my team at LAX (part of Ads-Quality) had mix of mac, linux and I think two or three people windows laptops... But all were dumb terminals. Also taht was 2014-2017