5 ms·

This makes no sense to me. Why is google building it? They want a more stable experience by using a microkernel and pushing everything to the userland? Maybe th

by stjo 5y ago

This makes no sense to me. Why is google building it? They want a more stable experience by using a microkernel and pushing everything to the userland? Maybe this will help with updates and vendors letting their devices rot? Or is it something to do with licensing?

kenhwang 5y ago
It's probably preferable than continuing to use the JVM-clone like it's an OS, while porting Linux to be the actual OS to run their JVM-clone OS.
wolpoli 5y ago
A large investment like this is likely a strategic move. Perhaps it is a corporate wide move to stop contributing to Linux. Or perhaps they plan on displacing Linux from the computing world.
tomComb 5y ago
Good questions, and I don't know the answers, but it is kind of odd (particularly given the pace of change in other areas of computer tech) that the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area. Of course, Apple is hard at work on iOS, but we don't know what sort of under the cover innovations that might good. So. I'm glad to see something new.
- LordDragonfang 5y ago
  >the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area. Are you talking about Linux, or Android specifically? Either way, I don't really agree that there's "little" going on there.
extrapickles 5y ago
Most OS's out there are unsuitable for making appliances, which this seems aimed at. Right now your choices are a Realtime OS or Linux. Realtime OS don't support making GUIs and Linux has a lot of foot-guns. Normally, updates to an appliance are one binary blob, this looks to support all of the various pieces having their own blob, and allow the OS to be updated independently from the application binaries, so security updates can happen without the appliance vendor needing to do anything.
- nyanpasu64 5y ago
  QNX is a microkernel RTOS which supported GUIs... but BlackBerry killed off support for using it on the desktop, and BlackBerry phones died out. IDK what else is using QNX technology now.
  - kemonocode 5y ago
    Cars [0], apparently. [0] https://blackberry.qnx.com/en/software-solutions/automotive/qnx-car-platform https://blackberry.qnx.com/en/software-solutions/automotive/...
    - jaywalk 5y ago
      Ford uses QNX for SYNC 3, although they are abandoning it and switching to Android Automotive starting with the 2023 model year.
- handrous 5y ago
  > Realtime OS don't support making GUIs My three favorite GUI operating systems, putting aside software support, are iOS, BeOS, and... Photon on QNX.
AshamedCaptain 5y ago
Who needs an excuse to keep a lot of very senior OS developers happy to be employees?
jcranmer 5y ago
I can't speak as to their motivations specifically, but one of the things that I've noticed from poking around the kernel API is that the kernel APIs are much more coherently designed than the conventional kernels we have are. In particular, one of the key design goals appears to be a heavy use of a capabilities-enabled handle-based API, even for more conventional syscalls (e.g., mmap). One of the benefits of this approach is that it simplifies a lot more cross-process management stuff; you can inspect (or edit!) another process's memory maps, for example, with the same system call that a process would use to edit its own. It would also enable something like CreateRemoteThread; it would definitely be far easier to write a debugger for Fuchsia than it is for Linux.
- astrange 5y ago
  Mach/Darwin/iOS has this and I suppose it's nice, but it does break down when you introduce POSIX compatibility, because you have to deal with the less expressive and insecure concepts like pids and file descriptors there.
  - wallscratch 5y ago
    Os noob here, what’s less expressive / insecure about PIDs or file descriptors?
    - jcranmer 5y ago
      PIDs and file descriptors are effectively global tables indexed by integers that are reused. This means that you have inherent race conditions: you want to an operation on pid X, but in between the time you decided you want to do it and the time you actually did it, pid X died and a new pid X was created. This is even worse for PIDs, since there's basically nothing you can do to actually have any sort of locking to avoid race conditions.
      - zozbot234 5y ago
        Linux has PID namespaces now, so it's not global. But yes, the race conditions you describe are real, and can only be addressed via new API's.
Daishiman 5y ago
Because things have changed since the time Linux became ubiquitous. We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing (no shared memory, no shared filesystem), capabilities, new and extremely aggressive attack vectors, and a need to compartmentalize and virtualize at more fundamental layers even if it comes at a performance penalty. You can't retrofit a microkernel-like abstraction on top of Linux. At the same time, a lot of the features you need for a shared multi-user system are basically cruft for modern mobile, single-user systems with little use for shared resources (not saying they're not shared; it's just that you can no longer trust apps installed in the user system so expecting apps to behave nicely is out of the window). The new wave of OSes embraces formal correctness when possible, JIT, garbage-collected application programming languages, tightly-enforced resource boundaries, deny-by-default security models, provably-safe system programming languages (Rust and whatever else will come), immutability and copy-on-write at the cost of filesystem space, and secure memory abstractions for more RAM. So why spend time supporting features that new OSes don't need, optimizing things that are no longer priority (HDD schedulers vs no-op SSD schedulers), when for once it _is_ actually easier to start over and fixing a lot of traditional pain points?
- zozbot234 5y ago
  > a lot of the features you need for a shared multi-user system are basically cruft That's just not true. A "single-user" system running multiple "apps" where each app is actually endowed with its own user-like privileges is just a shared multi-user system by another name. There's no reason not to reuse the existing infrastructure, if perhaps with some tweaks.
  - Daishiman 5y ago
    Too many tweaks to be worth it. To this date we still find bugs in sudo, interactive shells, weird env var interactions from su and inheriting variables. The Unix permissions system is complicated yet insufficient for protecting systems. There are multiple, orthogonal machineries for isolation (jails, chroot, namespaces,SELinux thingies, setuid and sticky bits) and they all interact in horrendous ways that leave huge security gaps. Just reconsidering their use cases and redoing al lot of that having learned the lessons of the past twenty years is a huge advance.
dragonwriter 5y ago
> Why is google building it? As the longer-payoff/higher-risk companion to Chrome OS as the longer-payoff/higher-risk companion to Android, in a nested generalization of the Poseidon-and-Polaris strategy discussed as a model (among other places) in Mary and Tom Poppendieck’s Implementing Lean Software Development. It’s kind of a go-to strategy for Google in important markets; when you are essentially made of more money than you can figure out ways to spend, internal diversification so that you literally don’t make the choice between the immediately useful but maybe future-limited approach and the longer-time-to-payoff, higher-risk approach less tied to what is currently optimal makes a lot of sense.

by stjo 5y ago

kenhwang 5y ago

It's probably preferable than continuing to use the JVM-clone like it's an OS, while porting Linux to be the actual OS to run their JVM-clone OS.

wolpoli 5y ago

A large investment like this is likely a strategic move. Perhaps it is a corporate wide move to stop contributing to Linux. Or perhaps they plan on displacing Linux from the computing world.

tomComb 5y ago

Good questions, and I don't know the answers, but it is kind of odd (particularly given the pace of change in other areas of computer tech) that the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area. Of course, Apple is hard at work on iOS, but we don't know what sort of under the cover innovations that might good. So. I'm glad to see something new.

LordDragonfang 5y ago
>the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area. Are you talking about Linux, or Android specifically? Either way, I don't really agree that there's "little" going on there.

extrapickles 5y ago

Most OS's out there are unsuitable for making appliances, which this seems aimed at. Right now your choices are a Realtime OS or Linux. Realtime OS don't support making GUIs and Linux has a lot of foot-guns. Normally, updates to an appliance are one binary blob, this looks to support all of the various pieces having their own blob, and allow the OS to be updated independently from the application binaries, so security updates can happen without the appliance vendor needing to do anything.

nyanpasu64 5y ago
QNX is a microkernel RTOS which supported GUIs... but BlackBerry killed off support for using it on the desktop, and BlackBerry phones died out. IDK what else is using QNX technology now.
- kemonocode 5y ago
  Cars [0], apparently. [0] https://blackberry.qnx.com/en/software-solutions/automotive/qnx-car-platform https://blackberry.qnx.com/en/software-solutions/automotive/...
  - jaywalk 5y ago
    Ford uses QNX for SYNC 3, although they are abandoning it and switching to Android Automotive starting with the 2023 model year.
handrous 5y ago
> Realtime OS don't support making GUIs My three favorite GUI operating systems, putting aside software support, are iOS, BeOS, and... Photon on QNX.

AshamedCaptain 5y ago

Who needs an excuse to keep a lot of very senior OS developers happy to be employees?

jcranmer 5y ago

I can't speak as to their motivations specifically, but one of the things that I've noticed from poking around the kernel API is that the kernel APIs are much more coherently designed than the conventional kernels we have are. In particular, one of the key design goals appears to be a heavy use of a capabilities-enabled handle-based API, even for more conventional syscalls (e.g., mmap). One of the benefits of this approach is that it simplifies a lot more cross-process management stuff; you can inspect (or edit!) another process's memory maps, for example, with the same system call that a process would use to edit its own. It would also enable something like CreateRemoteThread; it would definitely be far easier to write a debugger for Fuchsia than it is for Linux.

astrange 5y ago
Mach/Darwin/iOS has this and I suppose it's nice, but it does break down when you introduce POSIX compatibility, because you have to deal with the less expressive and insecure concepts like pids and file descriptors there.
- wallscratch 5y ago
  Os noob here, what’s less expressive / insecure about PIDs or file descriptors?
  - jcranmer 5y ago
    PIDs and file descriptors are effectively global tables indexed by integers that are reused. This means that you have inherent race conditions: you want to an operation on pid X, but in between the time you decided you want to do it and the time you actually did it, pid X died and a new pid X was created. This is even worse for PIDs, since there's basically nothing you can do to actually have any sort of locking to avoid race conditions.
    - zozbot234 5y ago
      Linux has PID namespaces now, so it's not global. But yes, the race conditions you describe are real, and can only be addressed via new API's.

Daishiman 5y ago

Because things have changed since the time Linux became ubiquitous. We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing (no shared memory, no shared filesystem), capabilities, new and extremely aggressive attack vectors, and a need to compartmentalize and virtualize at more fundamental layers even if it comes at a performance penalty. You can't retrofit a microkernel-like abstraction on top of Linux. At the same time, a lot of the features you need for a shared multi-user system are basically cruft for modern mobile, single-user systems with little use for shared resources (not saying they're not shared; it's just that you can no longer trust apps installed in the user system so expecting apps to behave nicely is out of the window). The new wave of OSes embraces formal correctness when possible, JIT, garbage-collected application programming languages, tightly-enforced resource boundaries, deny-by-default security models, provably-safe system programming languages (Rust and whatever else will come), immutability and copy-on-write at the cost of filesystem space, and secure memory abstractions for more RAM. So why spend time supporting features that new OSes don't need, optimizing things that are no longer priority (HDD schedulers vs no-op SSD schedulers), when for once it _is_ actually easier to start over and fixing a lot of traditional pain points?

zozbot234 5y ago
> a lot of the features you need for a shared multi-user system are basically cruft That's just not true. A "single-user" system running multiple "apps" where each app is actually endowed with its own user-like privileges is just a shared multi-user system by another name. There's no reason not to reuse the existing infrastructure, if perhaps with some tweaks.
- Daishiman 5y ago
  Too many tweaks to be worth it. To this date we still find bugs in sudo, interactive shells, weird env var interactions from su and inheriting variables. The Unix permissions system is complicated yet insufficient for protecting systems. There are multiple, orthogonal machineries for isolation (jails, chroot, namespaces,SELinux thingies, setuid and sticky bits) and they all interact in horrendous ways that leave huge security gaps. Just reconsidering their use cases and redoing al lot of that having learned the lessons of the past twenty years is a huge advance.

dragonwriter 5y ago

> Why is google building it? As the longer-payoff/higher-risk companion to Chrome OS as the longer-payoff/higher-risk companion to Android, in a nested generalization of the Poseidon-and-Polaris strategy discussed as a model (among other places) in Mary and Tom Poppendieck’s Implementing Lean Software Development. It’s kind of a go-to strategy for Google in important markets; when you are essentially made of more money than you can figure out ways to spend, internal diversification so that you literally don’t make the choice between the immediately useful but maybe future-limited approach and the longer-time-to-payoff, higher-risk approach less tied to what is currently optimal makes a lot of sense.