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.