> If interested, you can configure your Workstation to receive automatic updates.

If it stays here, I'm 100% on board; I wouldn't even mind defaulting to on. Forced automatic updates (hi, Microsoft) are a terrible move. I would also say that separating bug/security fixes from features and breaking changes helps, if my OS vendor had a way to auto-patch only security issues, and could ensure zero breakage as a result - no new features, no changing UX, nothing but invisible security patches - I'd enable it in a heartbeat. And they won't, so I won't:)

it sounds like you're looking for debian stable ;)

It makes sense if Fuchsia's main use cases are IoT devices, given how common public-facing vulnerable IoT devices made by defunct companies there are. It also makes sense if Fuchsia eventually replaces Linux as the Android kernel, given the historical short EoLs and lack of security updates (see: https://androidvulnerabilities.org).

For a development machine, I'd honestly... be pretty fine with it. That's similar to how Arch Linux operates (but change hourly to daily or weekly) and it causes very few problems. I think I've had maybe two or three big issues caused by updates in the past year, plus a couple application-specific issues (not kernel-level or os-level). With a more extensive regression testing team I can see Fuchsia following through with the promise of seamless updates.

Windows updates also have possibly the worst reputation you can get (except, maybe, iOS update's reputation when Apple was slowing down older devices), so almost anything Google does will be better. Not needing to reboot (presumably, if they're checking every hour) after an update will also help.

Windows updates are unpopular due to their implementation. Among other issues: they require a restart, they run complicated transactional flow rather than snapshots + patching the files, they kill the desktop state, they require extra processing on the next startup right as you want to actually do work, the whole delivery system is super complicated to suit enterprises, and yet it is still not able to handle user apps in the same flow.

If they implemented a proper A/B booting with preserving the intent/state of open apps most people wouldn't even realise an update happened and wouldn't complain.

I find them awful.

Even ignoring the philosophical "it's my machine dammit, it'll update when I damn well want it to and not before" POV[0] it is a practical mess on[1] two fronts:

1. I use my windows machine for computation, ergo it needs to be running, and it costs me money and productivity when it is not. If it restarts to update, I lose hours at minimum of cpu-time and more until I notice and can get things restarted.

2. It makes what should be core user functionality useless. I would like to set up my desktop, with some programs open, a few spreadsheets mayhaps, browser to discord, reddit, HN, etc. Maybe a second desktop relegated to some other task. I can't do this, because windows will force a restart in the next 144 hours which will invariably fubar anything I've tried to set up.

[0]To which I strongly adhere.

[1]At least.

It looks like everything runs decoupled in user-space, even the filesystem, drivers and packages. Meaning that updates to the system happens per part and requires no re-boots when updating (not even file-system updates, according to docs). So the updates are independent, the packages have their own life-cycles and works independent of the underlying system.

Having an auto-updating, fully sandboxed OS, without reboots, really doesn't sound that bad.

Especially if it's only kernel, stability and security updates.

Running in user space doesn't automatically decouple things; dbus is a user space process, but restarting it is traumatic because half the system uses it.

That's because dbus hasn't been written with no-downtime restarts in mind, but it's not that challenging to implement, especially when client apps are interfacing through (UNIX) sockets.

It's not dissimilar to writing zero-downtime web services.

Sure, but that's not a function of user/kernel space; Linux has live patching and dbus doesn't. It would be cool if fuchsia makes every OS component support non-disruptive updates, I'm just trying to point out that that doesn't automatically follow from running parts in user space.

Good point, updated my reply. While Google don't explicitly say that they want to support run-time updates of the kernel and OS; it's implied in their system architecture that such is the case.

Very difficult to do that though without enormous effort in transparent state persistence across restarts. Restarting even something with a very simple non-transactional API and state base like a filing system requires persisting all the file handle state, and that's the best case. Restarting a UI subsystem is much harder still because the apps may have a lot of uploaded state, things may need to be changed transactionally, etc.

Web apps update every time you open them, so it seems we won’t be able to escape this in the long run.

This and the fact that they (usually) install in under a second is the entire explanation for the success of the Web, in my opinion.

Windows updates are mostly unpopular because they have a tendency to happen when you are in the middle of something else which is incredibly annoying.

The problem is that automatic updates are both feature updates and security updates.

I doubt many people will have a problem with security updates that have no impact on the feature space.

But feature updates tend to break UX flows and not many people are happy about that.Your comment about corporate control also applies to feature updates.

I can imagine eventual (de-googled?) variants which will update only from a local server. In principle, at that local server level one might manually update repositories and control the version(s) presented to Fuchia clients.

I guess it depends on how it’s handled. If their success rate is as poor as windows updates then obviously I wouldn’t touch them with a ten foot pole for anything critical. But if the updates go as smoothly as iOS (or windows defender/macOS security) updates tend to, then I think the pros outweigh the cons for the majority of individuals for any devices that are regularly on the internet.

Please. Help us small business. Extend cycles to have a better coverage of security issues, and less feature changes, in updates.

I would imagine any consumer product running it would work like ChromeOS with a second system library that gets updated in the background and then swapped in at boot. Windows update is hated for how bad the implementation is..but people also don't like having out of date software and features.

fuchsia has an interesstin new approach for the handling of updates (should be more stable). We will see how this plays out, when it is no longer a developer playground with nightly builds.