This article is missing a key detail: that the expected workflow is that the workstations are basically just build machines.
My workstation is just an SSH server that I do builds on, everything else is on my laptop. I can’t remember the last time I used the internet on my workstation. I install packages but those come via a mirror, I scp files back and forth but that’s internal only.
Lots of people aren’t on this workflow yet, but I don’t think anyone is suggesting airgapping the main interface people are using.
All the coverage on this memo has missed this point. I guess they can’t imagine a company giving its employees two computers!
You can BYO ChromeOS devices too which make great thin terminals to a remote workstation or cloud VM. I have a whole bunch from dogfooding preproduction Chromebooks.
I feel like much of the internal coverage missed the point. There were a lot of people arguing in bad faith, ignoring the fact that the whole idea was clearly tied to the rollout of the particular workflow where no internet would be needed on the machines in question. Most devs still aren't working like that yet, and so pushed back hard.
Memegen is unbearably whiny now, but doesn't feel like it's because Google hires whiners. It feels more like valid employee feedback, accurately capturing valid worker sentiment toward shitty, randomizing leadership.
My first job out of college I ended up with the absolutely slowest box in the office, which definitely pushed me toward optimizing our app (it wasn't even good on fast machines, but it was tragic on slow), but compile times were murder.
We had a Sparcstation somewhere in the office being used as a mail server and nothing else. I don't recall how but I managed to SMB or NFS mount a directory so that I could edit code on my piddly little desktop but compile it on the Sparc. First time Java really worked as advertised for me.
Saved me loads of time and let me iterate on ideas that I don't think I or my boss would have had the patience for otherwise.
I'm not entirely keen on language servers, but those would be another area where distributed computing could come in handy. I think what might be missing though is a multitenant version. Everyone on my team has a duplicate model of our dependencies loaded into Webstorm and it's a pig.
>I ended up with the absolutely slowest box in the office, which definitely pushed me toward optimizing our app
Aside, but I 100% believe most developers of user-facing programs should be forced to use their app on a slow computer/phone with a slow internet connection before being able to ship it.
By “bunch” you mean the entire SRE org. I felt like it was a good setup, but I also felt that the long-term strategy of reducing the access necessary to operate the infrastructure was a good one. But why not both, as the child in the meme asks?
It seems so weird to me to want to use Linux on the desktop. This is not The Year.
I decided at the very start of my career, before Google, to use a laptop at the primary interface and only use workstation / dev environment / etc. remotely. That way I have the same working experience at my desk, at a cafe, on my desk at home. The only thing that changes is the number and size of monitors. It's worked out really well, and during the COVID era it only got better due to investments in the remote workflows.
I wouldn't even notice if my VM lost internet access and root.
What's wrong with the desktop at Linux, why "classical desktop" at all? I love my tiled wm setup so much since >10 years, and absolutely hate my corp windows desktop so much for everything it does to me. Gf similar regrets her chosing a private Mac Airbook everytime she uses it and swears to never buy one again every time she uses it (but uses it to seldom to consider just installing an Ubuntu, otherwise would do that)... so we are maybe strange people but
> It seems so weird to me to want to use Linux on the desktop. This is not The Year.
It seems so weird to me everybody considering their Windows or Mac as desktop ;)
I understand that a large proportion of Googlers use Google's slightly customized Linux on laptops (which is also the default/recommended), which is completely compatible with your workflow, so I'm not sure what argument you were trying to make (unless you don't count laptops as "Linux on the desktop"?)
I can only infer that you're suggesting people would only want to use Macbooks? Setting aside the fact that that is wrong, you don't make any argument as to why that would be.
gLinux laptops are OK I guess? I dunno. Every time I've tried to use Linux as my main interface, it's been crashy and confusing. Maybe it's gotten better since the last time I tried.
The other option is provisioning dev servers as VMs on big hosts, which some other companies do. That’s where the build and development happens, using an IDE locally on the issued laptop which uses remoting.
I also ran that setup when I worked at Google. I liked it a lot. ChromeOS was a great desktop OS; even when I was in the office, I just ssh'd to my Linux workstation from a Chromebox. Thus, "local" and "remote" had the same experience.
Are you sure?
Why would a build machine need access to GMail?
>The report says Google's new pilot program "will disable Internet access on the select desktops, with the exception of internal web-based tools and Google-owned websites like Google Drive and Gmail.
> Are you sure? Why would a build machine need access to GMail?
Because some people like to use remote desktop with it. And because some people's "build machine" is a VM, or a physical desktop in the office for some others.
My build machine sometimes needs to send logs to attach to bugs or have other humans inspect them. This obviously doesn't have to be Gmail but it comes pretty handy.
Laptops almost always have cooling which definitely won't sustain 100% CPU or GPU usage for 2 hours for a buildjob. On my desktop with fairly standard, non-fancy air cooling, I could run it on 100% for hours, and the only thing which would happen is the fans spinning loudly. On my work laptop, the poor thing (with an i9!) begins to heat up like crazy after 5-10 minutes of virtual machine usage.
Many people at Google still use desktop Linux workstations. Those would be airgapped too under this plan and force these people to change to another workflow. There are at least hundreds of people who have been there 10+ years still using desktops for all development. For example on the team I was previously on, 4/8 people used a desktop workstation as their main device.
I used a cloud VM as my main machine, and still used internet all the time. I used github to sync my configuration (using a proxy would be out of date and no way to push), amongst other things.
~5 years ago I had desktop Linux and a chrome book. All compilation happened via cloud build and the preferred IDE was the cloud-based web app. I didn't really use my desktop for anything, not even ssh.
I switched to a Chromebook in the pandemic and honestly it was fine. My workflow barely changed. I wasn't a vim fanatic at the time so I didn't really care.
Many people don't do that. They sit in front of a desktop with a monitor plugged into it and use the desktop for everything, including stack overflow etc
They don't need the desktop for stack overflow. They're launching a browser. They can launch the browser in any computer without breaking their workflow.
The editor for people I'm talking about is running locally on the desktop. The user is viewing a window on a monitor attached to the desktop. How does this work without changing that workflow?
possibly, not everybody is ok with using a not so good editor, no debugger integration and keeping their ssh and pgp keys somewhere else than a local machine.
The in-browser editor at Google is actually very good and has built in debugging support. Some people still don't use it though, and this change seems to ignore that.
As I said, many people are still not on this workflow, but it’s clearly the workflow everything is moving towards. I don’t believe anyone wants to take the internet away from people not on this workflow, but I’d give it up and be essentially unaffected, and I think there’s a growing minority in that position. Therefore, it seems like a reasonable experiment to pursue to inform future development.
I have a number of co-workers that do the same, but I can't live without my full Linux desktop environment. This is especially true if you use intelliJ or other desktop apps. Yes you can remote desktop, but it's just not the same.
For many people the experience of working from a laptop is poor. Mixing screen resolutions and density. Audio devices constantly changing as a plug into or out of my docking station. Yet another thing to fight for space on the desks they're always trying to densify. Etc. Etc.
For various workflows, the only viable solution is to remote desktop into my workstation and run the browser there. SSH isn't enough. And don't get me started on the disaster of trying to do things locally (Cmd+C) and remotely (Ctrl+C) simultaneously or the awful experience of mixing screen DPI when connecting a linux laptop to external monitors...
VSC Remote I can agree with. Gateway feels like such an after thought. So many bugs and it's very resource intense in my experience. I really like Jetbrains products but their remote offerings are lacking. Makes me wonder if that’s why they are working on Fleet to fill that gap.
we do the same. Codespaces, gitpod, or coder.dev all provide for this kind of workflow and honestly it just makes so much sense. Corporate desktop for comms and internet, ssh to a devcontainer (or vm if that is desired) for development activity.
Exactly. It's really just about isolating builds and code that runs from everything else. If you can afford the infrastructure, and can afford to make the infrastructure work well for everyone (arguably much harder), then it's a good idea with few downsides.
I wonder if more package management tools should adopt the zero-install approach of Yarn Berry. You don’t even need a mirror: everything is right there in the repository. Want to update a dependency? That’s a commit, thank you very much.
How do you remote access an air-gapped workstation? Seems like you'd need to be constantly switching whether your laptop is on the internet-connected network or the isolated network. If the laptop can switch between them automatically, wouldn't that make it possible for an attacker to jump the gap?
Even just having hosts that are sometimes internet connected and sometimes on the airgap network will greatly weaken the isolation. Stuxnet could cross an airgap with just static media, allowing thousands of computers that sometimes connect to the internet across the airgap seems like a fatal weakness.
The other key detail missing is presumably that the workstation is not air gapped at all, just prevented from accessing the internet with some firewall rules.
For those that don't know: air gapped means completely disconnected, as in literally pull the network cable out the back and never back in again. File transfers have to happen using some physical medium (traditionally write-once CDs/DVDs). You can have an air gapped network so long as the machines are just connected to each other and there's no physical route whatsoever to the internet.
The other key detail missing was that this was just an experiment that was going to be active only on a small set of machines for a limited time. They wanted to get data on how much it impacts users workflows, what the opt out rate is, etc.
There's not even a current plan to continue limiting access after the trial period ends, much less a plan for expanding it to more machines.
A lot of people I know don't use them like that. They have a chromebook and RDP onto their cloudtop and never close it. One thing I like(d) about google is that they let you bring whatever workflow you're most productive with, rather than prescribing an "expected" workflow on you.
My workstation is just an SSH server that I do builds on, everything else is on my laptop. I can’t remember the last time I used the internet on my workstation. I install packages but those come via a mirror, I scp files back and forth but that’s internal only.
Lots of people aren’t on this workflow yet, but I don’t think anyone is suggesting airgapping the main interface people are using.