Hubris is a big fault of Google and its engineers. They have a culture of thinking "there's one way to do it, we're smart, and we know best."

Shrug, seems like every application that's not designed to live in debian package repositories from the ground up eventually evolves an updater, or even a package manager for plugins. This hubris isn't unique to google, it's everywhere because we fundamentally haven't figured out how to manage updates in a way that meets requirements.

> we fundamentally haven't figured out how to manage updates in a way that meets requirements.

Depends whose requirements. The user's requirements are incredibly straightforward:

1. Never update; there's no benefit.

Updating is pushed on users anyway on the theory that they're connected to the internet, but it's not meant to help them. It's meant to help other people. Updates that help the user are generally provided on a pull model, and often charged for.

Thats the first user requirement. You forgot this one

2. Never be vulnerable to known attacks.

I didn't forget. That is not a requirement for most users. The whole idea of forcing people to update is that we don't want them to be vulnerable, so that their machines aren't used against us. The users commonly don't suffer negative effects from being exploited.

Ransomware is big enough news that I don't think that's true even for very non-technical users.

I wish both OSX/MacOS and Windows had a generic solution for 3rd party applications to check for updates, that wasn't tied to their respective stores. It's such a common pattern and requirement, the OS should/could provide the infrastructure to have a background service that periodically checks external links for availability of new software.

It seems like nearly every piece of macOS software outside of the App Store uses Sparkle for updates https://sparkle-project.org/

Right; except sparkle is terrible. At exactly the moment I want to use the app I get bothered by a difficult decision: Do I want to interrupt the flow of my work and wait a couple minutes so it can download and update, moving something that should happen in the background into something that directly interrupts my flow. Or skip the update and hope there were no important security / compatibility issues fixed. (Or kick the cart down the road and have it remind me later.)

The button I want is “update in the background when you close the app”, and it shouldn’t ask; it should just quietly do that. For all that chrome’s updater is like a tropical disease, it sure has way better UX than sparkle.

You forgot that, after you've told it to download the update, it pops up another interrupting dialog asking whether you want to install the update. If you just tell it to update and go get a coffee, when you come back, it won't be done.

If you ask me, everything should copy Paint.NET for update process. You get three choices: ignore, install now, install when I quit.

I like how Sparkle mentions being “modern” and uses “supports [...] Xcode 5.0 through 7.0” as evidence. Xcode 7 was released in 2015; the current version of Xcode is 11. Looks like the website needs a little updating...

(To clarify, I’m just pointing out a humorous observation, not making a statement on Sparkle)

Germane to this, the Debian package update model breaks both Chrome and Firefox:

http://neugierig.org/software/chromium/notes/2011/08/zygote....

More fuel for the "immutable install paths" cause :)

A good point and one of those strange troughs we get stuck in, every application having it's own different incompatible update system is clearly a bad idea but solving it requires the co-operation of disparate teams each of whom consider the amount of pain it causes end users as minor.

Honestly Fedora (and arch, ubuntu, debian and so on) simply spoils me, everything I need to do my job is a `dnf install` away and it just works.

I'm reminded of that every time I have to interact with a windows desktop how poorly the other (majority) side have it.

The flip side is stuff like Windows getting Firefox updates months ahead of Ubuntu (not sure if Fedora addresses this somehow), back in the day.

There is something to be said about letting application developers control the update rhythm of their application's releases.

Ubuntu gets Firefox updates within a day or two of release. It's been like that for years.

Same with Fedora.

Don't forget the "never question us" attitude as well.

It makes "don't be evil" a lot easier.

I have reported two Chrome OS bugs that allow bypassing Chrome's Own enterprise security policies. Both bypasses involved using Chrome extensions... written by Google.

Bingo. Per my comment below...

Specifically: https://news.ycombinator.com/item?id=21083277

Well, it sounds like a lot of defaults would have to have been changed to insecure settings for Chrome to have the permissions, so... you're right and Apple agrees. I mean if `/` is writable by your login user, then something has gone terribly wrong in your process somewhere.

Thankfully, with SIP, they don't.

edit: not https://en.wikipedia.org/wiki/Session_Initiation_Protocol, https://en.wikipedia.org/wiki/System_Integrity_Protection for anybody else

In this context, SIP is macOS's "System Integrity Protection", not the Session Initiation Protocol:

https://en.wikipedia.org/wiki/System_Integrity_Protection

Nope, https://en.wikipedia.org/wiki/System_Integrity_Protection .

This is why excessive TLA usage is bad.

What do you have against that little Alaskan airport?

Well, they use this acronym in the article so it makes perfect sense in context.

The article defines the acronym:

> SIP, as system integrity protection is usually abbreviated, was introduced in 2015

Which is why SIP exists.

Red flag #1 should have been when Chrome could install itself on Windows while bypassing administrator restrictions by not being installed in Program Files.