How Google got to rolling Linux releases for Desktops • Hacker News Board

Re: How Google got to rolling Linux releases for Desktops

#141

Post by happymellon » Wed, Jul 13, 2022, 2:04 PM UTC

surban wrote: post #80

happymellon wrote: post #74

Earlier quoted context omitted.

Unlikely to work in any corporate environment that I've witnessed. This is why so many devs I know moved to Mac's. Not because Mac's are necessary that great, who cares about battery life when it just sits on a desk, but because it's the closest you can get to Linux in a corporate environment. I would take native Linux on an ThinkPad as first option, but denied that I would go for Mac over Windows. I don't find WSL f…

Windows 11 natively supports multiple desktops.

Is it better than 7 or 10? As those "supported" multiple desktops, but was implemented in such a bad way.

Gnome and KDE are so much smoother when it comes to these workflows.

Re: How Google got to rolling Linux releases for Desktops

#142

Post by js2 » Wed, Jul 13, 2022, 2:11 PM UTC

baby wrote: post #85

sytse wrote: post #21

Cool article. My two takeaways: 1) If your deployment process hurts do it it more often (small releases frequently are easier than few big bang releases. 2) Don't commit to being x days behind upstream, if there is a big workload on your team (upgrading, vacations, etc.) you have the flexibility to delay upgrades and reduce the stream of incoming issues.

This is true for your codebase and your dependencies as well.

Any sort of integration, but some can be broken down into steps more easily than others. About a decade ago one of my roles at the startup I was at was keeping our browser built atop Chromium up-to-date with Chromium trunk. I normally would merge in all Chromium's changes each morning. Some weeks I just had other stuff to do and so it would be a full week I'd gone without merging.

Merging a full week of Chromium changes in all at once was just too many merge conflicts to deal with.

So I'd simulate as if I'd been merging daily by just doing 5-7 separate merges, which worked out well enough.

Re: How Google got to rolling Linux releases for Desktops

#143

Post by kevincox » Wed, Jul 13, 2022, 3:10 PM UTC

funcDropShadow wrote: post #98

baby wrote: post #83

Interesting post! I’ve been thinking about trying Linux with a rolling distrib. They mention NixOS, do people here have an opinion on that one?

I am not sure I would call NixOs a rolling release distribution. It has releases every 6 month like Ubuntu, but it does not have LTS releases. And due to the relatively small community only the latest release is supported. I am doing software development on a desktop workstation, that followed all releases since the start of 2018. And overall it has been rock solid. If an update, either a new release or a config chan…

nixos-unstable is a rolling release. I use it daily and on all of my servers.

Re: How Google got to rolling Linux releases for Desktops

#144

Post by kevincox » Wed, Jul 13, 2022, 3:13 PM UTC

baby wrote: post #83

Interesting post! I’ve been thinking about trying Linux with a rolling distrib. They mention NixOS, do people here have an opinion on that one?

I love NixOS. I would 100% recommend it for servers and probably 70% recommend it for desktop usage.

Feel free to ask me anything but instead of repeating past points I'll just link some past writings:

- https://kevincox.ca/2015/12/13/nixos-managed-system/

- https://kevincox.ca/2020/09/06/switching-to-desktop-nixos/

- https://kevincox.ca/2021/05/06/workstation-install-with-nixo...

Re: How Google got to rolling Linux releases for Desktops

#145

Post by RealStickman_ » Wed, Jul 13, 2022, 3:49 PM UTC

pabs3 wrote: post #76

I'm using Debian testing for years with unattended-upgrades upgrading everything 4 times daily (once for each Debian repository update). Not at Google. AMA!

Why 4 times daily and do you do that while you're working?

How do you deal with packages being broken until the next reboot if you do updates during the day?

I don't even update my Arch boxes that regularly and always do a reboot afterwards.

Re: How Google got to rolling Linux releases for Desktops

#146

Post by viccuad » Wed, Jul 13, 2022, 4:14 PM UTC

SkeuomorphicBee wrote: post #130

viccuad wrote: post #112

Earlier quoted context omitted.

it exists: either Debian Testing (a week or so of proven stability) or Debian Unstable (latest and greatest). If one follows the best practices for them[1] (installing apt-listbugs and apt-listpackages), one gets information of bugs and API-breaking changes before performing the upgrade, and can decide to pin the specific package as needed, and it will automatically get released when the bug is solved. This is thanks…

No, it didn't exist (outside Google). Debian testing is not a rolling release because it is not a "release", it lacks internal coherence. As the article mentioned, testing packages are built in unstable and then simply moved to testing individually, with no regard to moving all the build dependency chain together. So you end up with packages in testing that were built using packages that are not in testing yet. Edit:…

That sounds like moving goalposts: the OP mentions Arch's rolling release. And Arch doesn't rebuild the dependents when a package gets updated.

On the point of Testing lacking timely security updates, it's fair. But I invite you to compare the timelines with other distributions (including from corporate backers), and you will realize that their manual testing takes even more time.

Plus, you always have Debian Unstable. And apt-listchanges and apt-listbugs work fine in Unstable. It's the same experience: you get notified of serious bugs before upgrading, you get to pin packages and the pins are automatically lifted with the fixed version.

Re: How Google got to rolling Linux releases for Desktops

#147

Post by nemetroid » Wed, Jul 13, 2022, 4:44 PM UTC

viccuad wrote: post #146

SkeuomorphicBee wrote: post #130

Earlier quoted context omitted.

No, it didn't exist (outside Google). Debian testing is not a rolling release because it is not a "release", it lacks internal coherence. As the article mentioned, testing packages are built in unstable and then simply moved to testing individually, with no regard to moving all the build dependency chain together. So you end up with packages in testing that were built using packages that are not in testing yet. Edit:…

That sounds like moving goalposts: the OP mentions Arch's rolling release. And Arch doesn't rebuild the dependents when a package gets updated. On the point of Testing lacking timely security updates, it's fair. But I invite you to compare the timelines with other distributions (including from corporate backers), and you will realize that their manual testing takes even more time. Plus, you always have Debian Unstabl…

> And Arch doesn't rebuild the dependents when a package gets updated.

That’s not the point they argued, though. According to the comment you replied to, given version X of package A built against version Y of package B, Debian testing might contain package A version X but not package B version Y.

As far as I know, this situation does not occur in Arch.

Re: How Google got to rolling Linux releases for Desktops

#148

Post by bgro » Wed, Jul 13, 2022, 6:49 PM UTC

haik90 wrote: post #140

akdor1154 wrote: post #46

Jesus.. here i am in my BigCorp being disallowed to dev with Linux because too much mandated corporate crapware doesn't work. I dream of the day my employer provides an in-house distro for me.

We're on the same boat. Since a lot of people complaint, they allow Linux, but only under VM (VirtualBox), still better than no Linux at all.

I've only seen Windows and Mac options at work other than rare devops / sys admins who are using like red hat in some cases. Is there a generally agreed upon standard distro?

A lot of random programs that seem to be needed for corporate work, like outlook and teams, I imagine don't work or are somehow even worse on linux. Or is that what people are referring to with the junk software?

Does the general dev stack really run significantly more performant on linux distros? Significant as in uses 50% of the resources, compared to a 5% performance increase.

Windows drivers are relatively so optimized, I've seen battery life double when switching from Ubuntu to Windows on laptops although I haven't tested it in a while. The constant random headaches with webcams / mics / mice not working as expected has basically been my deal breaker in the past. Mac has been a decent medium.

Re: How Google got to rolling Linux releases for Desktops

#149

Post by merb » Wed, Jul 13, 2022, 7:38 PM UTC

Barrin92 wrote: post #5

personally I'm a pretty big fan of opensuse tumbleweed for a rolling distribution because they ship fully tested snapshots each day rather than individual packages. If I understand the article correctly Google's Sieve is similar to the Opensuse Build Service in that regard. It seems like they went for Debian because of the proximity to Ubuntu but I wonder if they ever considered Suse, the ecosystem is pretty good.

well if opensuse tumbleweed would use apt I would use it instantly, however zypper is so niche...

Re: How Google got to rolling Linux releases for Desktops

#150

Post by bluGill » Wed, Jul 13, 2022, 9:15 PM UTC

jillesvangurp wrote: post #138

bluGill wrote: post #127

Earlier quoted context omitted.

Fast deploy is good for many things, but that 5 times the testing effort means the few releases you do are higher quality. When it has to be perfect, like many embedded systems you don't do many releases. If course the above assumes you actually do the 5 times the testing before release. Most companies skipped that, and it showed.

Automated tests are key for this. If you have those, it empowers deploying frequently. There is only so much that can break for a small delta. That typically also enables very targeted manual testing if you need that. Many companies have the wrong reflex of releasing less often when things don't go smoothly so they can test more not realizing that if they release more often, they can get away with less testing becaus…

Automated tests are good, but even a large suite misses things. End to end full integration issues for example are very hard to automate and use a lot of time to run.