Re:Google’s in-house desktop Linux
by mindentropy on Wednesday August 03, 2022 @07:02AM
(#32330086)
> 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.
I am interested in working on this. Do you know if there positions open and where and which group to apply?
You can check on our careers page, we do post all available positions there, you can filter for stuff like chromeos or firmware or kernel engineer, etc. Example: https://careers.google.com/jobs/results/?distance=50&hl=en_U...
Re:Google’s in-house desktop Linux
by mindentropy on Thursday August 04, 2022 @10:32AM
(#32343432)
A quick question as it very hard to get an answer back on this. Does Google ask leetcode stuff for firmware and kernel engineers too?
From an enterprise management perspective nobody (as far as I know) has made some kind of tooling to manage linux desktops in a similar way admins can do with ChromeOS or Windows. I think that is the real dealbreaker for linux in the enterprise for general use.
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