4 ms·

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 requir

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.

yjftsjthsd-h 5y ago
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.
- sph 5y ago
  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.
  - yjftsjthsd-h 5y ago
    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.
    - tmikaeld 5y ago
      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.
      - native_samples 5y ago
        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.

yjftsjthsd-h 5y ago

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.

sph 5y ago
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.
- yjftsjthsd-h 5y ago
  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.
  - tmikaeld 5y ago
    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.
    - native_samples 5y ago
      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.