6 ms·

yes, I'll try to sum up the article as i understand: * better process isolation * stable hw/driver api (this is a huge mistake in linux, agreed) * less histo

yes, I'll try to sum up the article as i understand: * better process isolation * stable hw/driver api (this is a huge mistake in linux, agreed) * less historical craziness(who likes fork()?) * more micro-kernel some of the things I personally cannot buy: * vulkan native. android is not vulkan-native, it provides both opengl es and vulkan, for your choice * flutter. why bundling and bringing opinions to the system becomes a benefit? it was a major problem with android that you have to interact with java if you want any native ui => I would prefer more ways/languages/bindings to interop with the UI * fidl ipc. cool, again, why bundling something with the os? * vDSO. why is even vdso on the slides - vdso is important, but it already with us for a decade. This article is great because its one of the first that breaks down Fuchsia on a tech level. But at the same time, its not an article that explains all the reasons the fuchsia is better that what google have now.

microcolonel 8y ago
> stable hw/driver api (this is a huge mistake in linux, agreed) Not to get into a flamewar over this, but there are real benefits to Linux's rolling driver ABI (the "API", however, is mostly stable, contrary to what you say). It encourages mainline collaboration, and greatly improves the quality and compactness of the drivers. On Windows (and to some extent macOS), you'll find whole classes of driver where each driver has its own proprietary internal implementation of something that should have been in the API and ABI, but is not (or just was not when the driver was written). Linux has great, up to date drivers for the vast majority of devices you'd want to use†, and all of the best ones are built (compactly!) right in to the kernel, so it is more or less moot at this point whether a stable ABI is a good thing (at worst, it didn't matter in the long run; at best, it made the system better). The level of integration and standardization in the Linux kernel is spectacular, and absolutely would not have been achieved if vendors were empowered to link ABI-compatible binary blobs into end user kernels. There is tremendous value in the fact that I can manage, consistently, every LED, every DVFS controller, every fan controller, every GPIO pin, etc. on each supported system in a consistent fashion. Left to their own devices, each vendor would use their pet interface (as seen with NVIDIA putting their foot down and demanding EGL surfaces be used with their driver on Wayland, despite the fact that no standard software supports it); NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no. † Outside of the Android ecosystem, which, through what could maybe be called poor stewardship on the part of Google, inexplicably refuses to develop against the mainline kernel, so is constantly fighting to maintain literally thousands of vendor-, OEM-, model-, SKU-, country-, and carrier-specific kernel trees for absolutely no recognizable benefit, and against the clearest and most consistent advice of the highest experts on the subject.
- snvzz 8y ago
  >NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no. I have some bad news for you. They got their way.
- ebg13 8y ago
  > It encourages mainline collaboration I feel like this is demonstrably a false promise by looking at the billions of mobile devices never getting any updates because of vendor neglect. > and greatly improves the quality Compared to what? > and compactness of the drivers Which no user has ever cared about. > up to date drivers for the vast majority of devices you'd want to use† I notice that you excepted billions of devices in order to make this claim. > inexplicably refuses to develop against the mainline kernel It's not inexplicable. It's easier and cheaper.
  - jhasse 8y ago
    > Which no user has ever cared about. The user cares because it results in fewer bugs.
    - pjmlp 8y ago
      Which paper proves such correlation?
      - jhasse 8y ago
        https://www.researchgate.net/publication/316922118_An_Investigation_of_the_Relationships_between_Lines_of_Code_and_Defects https://www.researchgate.net/publication/316922118_An_Invest...
        pjmlp 8y ago
        Thanks.
  - yc12340 8y ago
    > feel like this is demonstrably a false promise by looking at the billions of mobile devices never getting any updates Third-party firmware like CyanogenMod exists only because in-kernel GPL parts can be ported to new OS versions. With Fuchisa there won't be anything like CyanogenMod anymore.
nwah1 8y ago
I don't understand why they didn't want to base it on the formally-verified, capability-based micro-kernel called seL4. Formal verification is the difficult but necessary next step for security-intensive applications. Also, any new kernel should only be written in a memory-safe language. Rust would be the best, since it is also safe from data races, outside of unsafe blocks.
- im_down_w_otp 8y ago
  Well... it's non-trivial to use seL4 correctly. It has all of the facilities to build something great and very little rails to ensure that you actually do. CAmkES, the component framework to help you do that, is... challenging in all the wrong ways. The proof evidence is very hard to extend meaningfully for new platforms, and you're limited to environments which have a sufficient MMU. We're starting with seL4 and building a whole Rust-based userland around it, and creating a whole pile of compile-time assurances along the way to make sure we're not inadvertently doing something dangerous or stupid with the rope seL4 gives you. It's worth it for us. However, it is a colossal pain in the ass. That said, in the coming months we're likely to open source some of our progress in making it easier and more reliable to work with, integrate with, and otherwise leverage seL4 for certain use cases.
  - Scramblejams 8y ago
    Deets would be appreciated. Sounds interesting.
  - thenewwazoo 8y ago
    I'm super interested in the work you're doing. I spent a couple of weekends building bindings and trampolines to get Rust binaries linked into Chibi/OS and FreeRTOS and it worked really well. I've always wanted to work with seL4, so I downloaded the source and started working through the tutorials and... oh dear. There ended my experiments trying to add Rust into the mix. So if there's any way I can subscribe or otherwise keep abreast of the work you're doing, I'd love to do that. As an aside, I wonder just how much async/await in Rust will obviate the need for small kernels in deeply embedded applications. If I can do blocking IO with my peripherals and use the async state machines to do "task" switching, well... who needs tasks and capabilities? It'd land somewhere on the "language OS" side of an embedded OS almost.
atombender 8y ago
FIDL is used extensively through the OS, and looks like it will be the primary means of communication between processes, not too different from macOS's XPC (which is used for a lot of services as well as very low-level stuff like talking to the T2 processor, apparently). Fuchsia being a microkernel, it makes sense to make this part of the OS. The alternative of inventing ad-hoc RPC mechanisms for each area of the system would be worse.
- wongarsu 8y ago
  If I remember correctly Android also has IPC in the kernel, using it to enforce permissions and the security model between apps.
  - pjmlp 8y ago
    Moreso after Project Treble, now Android Linux behaves a bit like a micro-kernel.
suby 8y ago
Regarding Fuschia only having an option for vulkan and not opengl, it doesn't seem like that would necessarily stop opengl software from working on fuchsia, right? There are opengl implementations on top of Vulkan like MoltenVK. I don't have a great understanding of this stuff, but assuming that this is true, I imagine that it has upsides like eliminating potential driver bugs which have plagued opengl in the past.
- earenndil 8y ago
  MoltenVK implements vulkan itself, on top of metal, and its counterpart, moltengl is closed-source. There do exist projects to implement opengl on top of vulkan, but I don't think any of them are mature yet.
josephg 8y ago
> * vulkan native. android is not vulkan-native, it provides both opengl es and vulkan, for your choice IMO vulkan-native is the right choice because opengl (or opengles, or anything else) can always be reimplemented on top of vulkan anyway. Layering opengl on top of vulkan means you're no longer at the mercy of hardware vendors to provide a bug-free opengl implementation. And if you're calling a userland opengl library running on top of vulkan, you can actually debug into graphics system and much more easily tune performance. (Debugging through into opengl calls is almost impossible when the opengl implementation is hardware-specific and part of the graphics driver itself).
- hornetblack 8y ago
  Case in point. Google's ANGLE library has a in-progress Vulkan back-end. (Used for WebGL in Chrome and Firefox). ANGLE does only provide OpenGL ES, but then so does Android. I wouldn't be surprised if an upcoming android version required Vulkan suppport and Android shipped with ANGLE for OpenGL. https://github.com/google/angle https://github.com/google/angle
- kllrnohj 8y ago
  In reality this is entirely moot and comes down purely to driver development cost. Nothing in the OS is designed around the idea of being "vulkan native" or not. That's just not a system architecture thing at all. But what is a thing is whether or not the GPU driver bothers to have an OpenGL ES path or not. It's obviously simpler if the driver doesn't, but a quality driver implementation will also obviously always beat something like ANGLE in every way. So take a hypothetical Nvidia Shield 5 running Fuchsia in 5 years or whatever. If games are still dominantly in OpenGL ES, then you can bet your ass Nvidia will be shipping a first-class GLES driver and not use ANGLE-on-Vulkan.
fouc 8y ago
How tied to the internet will it be? How many callbacks to google will it have? Will it rely on google DNS?
- hrdwdmrbl 8y ago
  not
- sagartewari01 8y ago
  > Will it rely on google DNS? You bet!
  - HeWhoLurksLate 8y ago
    As default, that makes a lot of sense. I guarantee there will be a lot of pushback from enterprises if they can't change the DNS servers to their own.
j16sdiz 8y ago
Google does not mix well with stable api. They love the shiny new stuffs and break things often.

microcolonel 8y ago

> stable hw/driver api (this is a huge mistake in linux, agreed) Not to get into a flamewar over this, but there are real benefits to Linux's rolling driver ABI (the "API", however, is mostly stable, contrary to what you say). It encourages mainline collaboration, and greatly improves the quality and compactness of the drivers. On Windows (and to some extent macOS), you'll find whole classes of driver where each driver has its own proprietary internal implementation of something that should have been in the API and ABI, but is not (or just was not when the driver was written). Linux has great, up to date drivers for the vast majority of devices you'd want to use†, and all of the best ones are built (compactly!) right in to the kernel, so it is more or less moot at this point whether a stable ABI is a good thing (at worst, it didn't matter in the long run; at best, it made the system better). The level of integration and standardization in the Linux kernel is spectacular, and absolutely would not have been achieved if vendors were empowered to link ABI-compatible binary blobs into end user kernels. There is tremendous value in the fact that I can manage, consistently, every LED, every DVFS controller, every fan controller, every GPIO pin, etc. on each supported system in a consistent fashion. Left to their own devices, each vendor would use their pet interface (as seen with NVIDIA putting their foot down and demanding EGL surfaces be used with their driver on Wayland, despite the fact that no standard software supports it); NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no. † Outside of the Android ecosystem, which, through what could maybe be called poor stewardship on the part of Google, inexplicably refuses to develop against the mainline kernel, so is constantly fighting to maintain literally thousands of vendor-, OEM-, model-, SKU-, country-, and carrier-specific kernel trees for absolutely no recognizable benefit, and against the clearest and most consistent advice of the highest experts on the subject.

snvzz 8y ago
>NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no. I have some bad news for you. They got their way.
ebg13 8y ago
> It encourages mainline collaboration I feel like this is demonstrably a false promise by looking at the billions of mobile devices never getting any updates because of vendor neglect. > and greatly improves the quality Compared to what? > and compactness of the drivers Which no user has ever cared about. > up to date drivers for the vast majority of devices you'd want to use† I notice that you excepted billions of devices in order to make this claim. > inexplicably refuses to develop against the mainline kernel It's not inexplicable. It's easier and cheaper.
- jhasse 8y ago
  > Which no user has ever cared about. The user cares because it results in fewer bugs.
  - pjmlp 8y ago
    Which paper proves such correlation?
    - jhasse 8y ago
      https://www.researchgate.net/publication/316922118_An_Investigation_of_the_Relationships_between_Lines_of_Code_and_Defects https://www.researchgate.net/publication/316922118_An_Invest...
      - pjmlp 8y ago
        Thanks.
- yc12340 8y ago
  > feel like this is demonstrably a false promise by looking at the billions of mobile devices never getting any updates Third-party firmware like CyanogenMod exists only because in-kernel GPL parts can be ported to new OS versions. With Fuchisa there won't be anything like CyanogenMod anymore.

nwah1 8y ago

I don't understand why they didn't want to base it on the formally-verified, capability-based micro-kernel called seL4. Formal verification is the difficult but necessary next step for security-intensive applications. Also, any new kernel should only be written in a memory-safe language. Rust would be the best, since it is also safe from data races, outside of unsafe blocks.

im_down_w_otp 8y ago
Well... it's non-trivial to use seL4 correctly. It has all of the facilities to build something great and very little rails to ensure that you actually do. CAmkES, the component framework to help you do that, is... challenging in all the wrong ways. The proof evidence is very hard to extend meaningfully for new platforms, and you're limited to environments which have a sufficient MMU. We're starting with seL4 and building a whole Rust-based userland around it, and creating a whole pile of compile-time assurances along the way to make sure we're not inadvertently doing something dangerous or stupid with the rope seL4 gives you. It's worth it for us. However, it is a colossal pain in the ass. That said, in the coming months we're likely to open source some of our progress in making it easier and more reliable to work with, integrate with, and otherwise leverage seL4 for certain use cases.
- Scramblejams 8y ago
  Deets would be appreciated. Sounds interesting.
- thenewwazoo 8y ago
  I'm super interested in the work you're doing. I spent a couple of weekends building bindings and trampolines to get Rust binaries linked into Chibi/OS and FreeRTOS and it worked really well. I've always wanted to work with seL4, so I downloaded the source and started working through the tutorials and... oh dear. There ended my experiments trying to add Rust into the mix. So if there's any way I can subscribe or otherwise keep abreast of the work you're doing, I'd love to do that. As an aside, I wonder just how much async/await in Rust will obviate the need for small kernels in deeply embedded applications. If I can do blocking IO with my peripherals and use the async state machines to do "task" switching, well... who needs tasks and capabilities? It'd land somewhere on the "language OS" side of an embedded OS almost.

atombender 8y ago

FIDL is used extensively through the OS, and looks like it will be the primary means of communication between processes, not too different from macOS's XPC (which is used for a lot of services as well as very low-level stuff like talking to the T2 processor, apparently). Fuchsia being a microkernel, it makes sense to make this part of the OS. The alternative of inventing ad-hoc RPC mechanisms for each area of the system would be worse.

wongarsu 8y ago
If I remember correctly Android also has IPC in the kernel, using it to enforce permissions and the security model between apps.
- pjmlp 8y ago
  Moreso after Project Treble, now Android Linux behaves a bit like a micro-kernel.

suby 8y ago

Regarding Fuschia only having an option for vulkan and not opengl, it doesn't seem like that would necessarily stop opengl software from working on fuchsia, right? There are opengl implementations on top of Vulkan like MoltenVK. I don't have a great understanding of this stuff, but assuming that this is true, I imagine that it has upsides like eliminating potential driver bugs which have plagued opengl in the past.

earenndil 8y ago
MoltenVK implements vulkan itself, on top of metal, and its counterpart, moltengl is closed-source. There do exist projects to implement opengl on top of vulkan, but I don't think any of them are mature yet.

josephg 8y ago

> * vulkan native. android is not vulkan-native, it provides both opengl es and vulkan, for your choice IMO vulkan-native is the right choice because opengl (or opengles, or anything else) can always be reimplemented on top of vulkan anyway. Layering opengl on top of vulkan means you're no longer at the mercy of hardware vendors to provide a bug-free opengl implementation. And if you're calling a userland opengl library running on top of vulkan, you can actually debug into graphics system and much more easily tune performance. (Debugging through into opengl calls is almost impossible when the opengl implementation is hardware-specific and part of the graphics driver itself).

hornetblack 8y ago
Case in point. Google's ANGLE library has a in-progress Vulkan back-end. (Used for WebGL in Chrome and Firefox). ANGLE does only provide OpenGL ES, but then so does Android. I wouldn't be surprised if an upcoming android version required Vulkan suppport and Android shipped with ANGLE for OpenGL. https://github.com/google/angle https://github.com/google/angle
kllrnohj 8y ago
In reality this is entirely moot and comes down purely to driver development cost. Nothing in the OS is designed around the idea of being "vulkan native" or not. That's just not a system architecture thing at all. But what is a thing is whether or not the GPU driver bothers to have an OpenGL ES path or not. It's obviously simpler if the driver doesn't, but a quality driver implementation will also obviously always beat something like ANGLE in every way. So take a hypothetical Nvidia Shield 5 running Fuchsia in 5 years or whatever. If games are still dominantly in OpenGL ES, then you can bet your ass Nvidia will be shipping a first-class GLES driver and not use ANGLE-on-Vulkan.

fouc 8y ago

How tied to the internet will it be? How many callbacks to google will it have? Will it rely on google DNS?

hrdwdmrbl 8y ago
not
sagartewari01 8y ago
> Will it rely on google DNS? You bet!
- HeWhoLurksLate 8y ago
  As default, that makes a lot of sense. I guarantee there will be a lot of pushback from enterprises if they can't change the DNS servers to their own.

j16sdiz 8y ago

Google does not mix well with stable api. They love the shiny new stuffs and break things often.