Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Google got to rolling Linux releases for Desktops

cloud.google.com

Post reply on HN
Print view View original

151–160 of 167 posts

Re: How Google got to rolling Linux releases for Desktops

#151

Post by erik_seaberg »

jillesvangurp wrote: post #128
erik_seaberg wrote: post #90

Earlier quoted context omitted.

This, remaining on a known-good release is a form of technical debt to use judiciously and pay down when more convenient. Beta testing everything immediately can be a favor to the community, but it’s probably not your main job.

Actually, it's the opposite in my experience. Beta testing is typically done when most software is released. Basically, at that point your technical debt is all the known & fixed issues that you still have, the features you don't have access to and can't benefit from, the performance issues you still have, the newly deprecated APIs that you are still using, etc. Opting into all that without good reason is a bad idea.…

> If you are afraid things will break, the best way to find out is to just try it.

How much of the team is awake, sober, and on the grid at that moment? Some times are worse than others for an outage.

Re: How Google got to rolling Linux releases for Desktops

#152

Post by Arnavion »

nyanpasu64 wrote: post #22
Arnavion wrote: post #17

Earlier quoted context omitted.

Yes. I've been using it for over a decade and it's still great. Like Fedora it's leading the charge in modernization (btrfs, /usr/etc, snapper, Yast, etc) and like Arch it has a big set of up-to-date packages, except they're in the main repo instead of an untrusted AUR.

You need third party repositories if you want full ffmpeg with h.264 support, and since these are binary (IIRC) repos, each third-party package is often either compatible with the latest or older snapshot, or tumbleweed, but often not both (unlike Arch's AUR which only has one distro to target, though it's a moving target).

>You need third party repositories if you want full ffmpeg with h.264 support

Repository. Singular. Packman.

>each third-party package is often either compatible with the latest or older snapshot, or tumbleweed, but often not both

The conversation was about TW. There is a packman repo for TW.

Re: How Google got to rolling Linux releases for Desktops

#153

Post by Schroedingersat »

paskozdilar wrote: post #106
sangnoir wrote: post #105

Earlier quoted context omitted.

> GPL absolutely has strings attached. Only if you're redistributing the resulting work. If not, you do whatever you like.

Note that AGPL (Affero GPL) expands the attached strings to any kind of user-facing network interface. So if you take AGPL code and make a Service-as-a-Software-Substitute with it, you're still legally obliged to provide source code to the users of your SaaSS. In fact, AGPL is so badass that not even Google [0] wants to touch it with a 10 yard stick :) [0] https://opensource.google/documentation/reference/using/agpl.…

> So if you take AGPL code and make a Service-as-a-Software-Substitute with it, you're still legally obliged to provide source code to the users of your SaaSS.

So the users of the software can do whatever they want with it with no strings attached then. I don't see how this concept is so hard.

Re: How Google got to rolling Linux releases for Desktops

#154

Post by csdvrx »

watermelon0 wrote: post #43
csdvrx wrote: post #38

Earlier quoted context omitted.

> So first this comment is clearly influenced by your own preferences for MacOS. I've always found very strange the love for MacOS professed by so many here on HN! > Stackoverflow Developer Survey shows irl about 40% of development is done on Windows, 30% Mac and 30% Linux. So the platforms are at least equally appealing in real world circumstances. Indeed. I use Windows and there's no amount of money you could pay m…

> I want an OLED screen, and there's no such option on MacOS. Mini LED on M1 MBPs is not OLED quality, but it's quite close in many cases. Additionally, in my experience (and from reading various reviews), M1 laptops are really quiet (fans are not loud even under load), have great battery life, and don't get nearly as hot as most (if not all) PC counterparts (under the same load conditions.)

> Mini LED on M1 MBPs is not OLED quality, but it's quite close in many cases.

No, it's not even close.

When I say OLED, I mean OLED, not qled or something that's "almost like" it.

To be clear: no OLED= I won't buy it.

> Additionally, in my experience (and from reading various reviews), M1 laptops are really quiet (fans are not loud even under load), have great battery life, and don't get nearly as hot as most (if not all) PC counterparts (under the same load conditions.)

Thanks, it might be nice if I cared about such things, but I absolutely don't - especially if the only non negotiable requirement (OLED) can't even be met.

FYI, if you want to know other things I care about once the bare minimum of an OLED screen is there: ECC RAM, removable NVMe drives, ideally 2 of them (or better: 3x)

Unfortunately, there're no such things on macs.

I'm sure "quiet, long battery life, cold to the touch" are important factors for those who purchase macs- but not for me.

It seems that those who have found the M1 macs suitable to their needs think that it must be ideal for everyone else - it's not!

Different people have different needs.

Re: How Google got to rolling Linux releases for Desktops

#155

Post by technofiend »

bgro wrote: post #148
haik90 wrote: post #140

Earlier quoted context omitted.

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 reall…

The driver behind a unix desktop is you're usually deploying to a unix environment, so parity between the environments means little to no friction developing or debugging.

Re: How Google got to rolling Linux releases for Desktops

#156

Post by nyanpasu64 »

Arnavion wrote: post #152
nyanpasu64 wrote: post #22

Earlier quoted context omitted.

You need third party repositories if you want full ffmpeg with h.264 support, and since these are binary (IIRC) repos, each third-party package is often either compatible with the latest or older snapshot, or tumbleweed, but often not both (unlike Arch's AUR which only has one distro to target, though it's a moving target).

>You need third party repositories if you want full ffmpeg with h.264 support Repository. Singular. Packman. >each third-party package is often either compatible with the latest or older snapshot, or tumbleweed, but often not both The conversation was about TW. There is a packman repo for TW.

The conversation was about getting packages "in the main repo instead of an untrusted AUR". I used Tumbleweed a few years ago. To get a package selection as rich as the full AUR (which is very broad but not 100% comprehensive for niche packages), I had to use multiple package repos besides Packman, and many packages I wanted didn't ship Tumbleweed builds (reminding me of my experiences with Ubuntu's PPAs).

Re: How Google got to rolling Linux releases for Desktops

#157

Post by antod »

bgro wrote: post #148
haik90 wrote: post #140

Earlier quoted context omitted.

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 reall…

> 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.

I thought Teams was shitty on Linux, then I got switched to a Mac. Teams was just as shitty there too. I don't think it's any better on Windows either.

> 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.

Depends on the stack. One example: Being able to use Docker Engine natively rather than Docker Desktop saves a lot of resources.

Re: How Google got to rolling Linux releases for Desktops

#158

Post by swaranga »

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.

I am loving the Netflix model. You can ask for a MacBook or a thinkpad. If you opt for the thinkpad, you can also install whatever Linux you want and all tools will still work.

In fact you can bring your own laptop and without reimaging use that for development. All interval tools (of which there aren’t too many are written in Go so are cross platform). I ordered a framework laptop and will expense it once it is here.

Re: How Google got to rolling Linux releases for Desktops

#159

Post by pabs3 »

RealStickman_ wrote: post #145
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.

The Debian archive is updated 4 times daily, so I update my system after each Debian update. I do that no matter whether I am working or not.

Packages almost always aren't broken in Debian testing but if they were, a reboot would not fix them anyway.

I restart processes instead of rebooting (using the needrestart/needrestart-session tools). I only reboot after Linux kernel image/module updates or microcode updates, because Debian cannot yet live-update those components.

Re: How Google got to rolling Linux releases for Desktops

#160

Post by whateveracct »

zamalek wrote: post #27
whateveracct wrote: post #9

Earlier quoted context omitted.

Or NixOS unstable hehe

The nice thing with flake-based NixOS is that it's trivial to cherry-pick unstable onto a stable base. I do a bunch of that in my nixconfigs: https://gitlab.com/jcdickinson/nix

Thanks for sharing. I'm new to flakes, so seeing that idiom of having a separate nixpkgs-unstable arg propagated around set off a lightbulb!
Post reply on HN