5 ms·

Helios author here. I tried to think of a nice spin for this comment, but came up short. If there is a future of computing with Fuschia in it, it will have ever

Helios author here. I tried to think of a nice spin for this comment, but came up short. If there is a future of computing with Fuschia in it, it will have everything to do with Google's industry weight and nothing to do with its good systems engineering and design. Fuschia is an extraordinarily complex kernel design. Hell, it's a "microkernel" which is bigger than Linux! It's fairly typical of Google's inwardly-focused engineering culture, using questionable tools (with large shadows) such as Bazel and gRPC, which were likely chosen simply because they plug into the Googler engineering culture. At the same time, these decisions give way to a very complex system with heaps of moving parts, in this rube goldberg design which is endemic of Google engineering. Helios is much, much simpler. The kernel itself will probably clock in at under, say, 20,000 lines of code (for x86_64, at least), and it has a very small syscall API, less than two dozen in the final design. Many of the things Fuschia does in the kernel will be done in userspace on Helios, in the Mercury component, such as service discovery and capability allocation. Finally, Helios is written in Hare, which itself is a much simpler language than C++, and kernel hackers at the very least should be convinced of the argument that the complexity of your implementation language contributes to the complexity of your implementation.

patrec 4y ago
> questionable tools (with large shadows) such as Bazel and gRPC, Bazel and gRPC, whilst both saddled with problems stemming from Google's inwardly-focused engineering culture (and also just some sub-optimal historical decisions) are not "questionable tools" in the sense that they solve the wrong problems or something else solves the same problems much better. Blaze/Bazel (and its various clones like Buck) are basically the only general purpose build systems out there that even attempt to do the basic tasks of a build system, namely actually figuring out what has changed and needs to be rebuilt. So of course they are gonna use it, nothing else comes even close (and the main downsides don't apply to them). Similarly, gRPC has a lot of warts in both how its encoding, type system, API and transport work. But anything in that space that doesn't completely suck (such as cap'n proto) is basically a clone of the core design. Again what else even attempts to solve the core problem of having some backwards/forwards compatibly reasonably efficient rpc, messaging and data storage?
- ahartmetz 4y ago
  > basically the only general purpose build systems out there that even attempt to do the basic tasks of a build system, namely actually figuring out what has changed and needs to be rebuilt. Extraordinary claim. You will need to explain how Bazel does that and, say, CMake + Ninja don't.
  - brabel 4y ago
    Even [task](https://github.com/go-task/task https://github.com/go-task/task) (a tiny task-runner tool) does that... I don't know any build system that doesn't. Perhaps the OP means full incremental compilation, which requires "cooperation" from the compilers, really (or the build tool actually parsing the language's AST like Gradle does, I believe). Or in the case of Bazel, the build author explicitly explaining to the build what the fine-grained dependencies are (I don't use Bazel so I may be wrong, happy to be corrected).
    - patrec 4y ago
      > I don't know any build system that doesn't. Sure you do. Any build system which has a "clean" command that you'd use for anything other than freeing up space.
      - brabel 4y ago
        And which one is that?
        patrec 4y ago
        Make, cmake, cargo and npm are all examples of popular build tools that require you to manually "clean" to correct build problems. Make and cmake pretty much all the time, IME, cargo less so, but it happens. Bazel/Blaze and derivatives basically don't.
  - patrec 4y ago
    > Extraordinary claim. If you think this claim is extraordinary and CMake is a counterexample, I don't know what to say. Have you really not have had to manually fuzz around with stale builds (by e.g. issuing "clean" commands, removing build/ directories etc) when using CMake or had to figure out why something worked on your machine but not a colleagues? > You will need to explain how Bazel does that and, say, CMake + Ninja don't. CMake makes no serious effort at all at "figuring out what has changed". Even trivial stuff doesn't work. If you have a wildcard pattern in a CMake file and you add a file that matches the wildcard, you will generally get a stale result (which is why it's "not recommended"). So not even explicitly specified inputs work correctly and CMake makes no real attempt to to detect unspecified implicit dependencies. Does your CMake build setup correctly detect when you updated gcc or some system library? That some build artifact implicitly depends on another? By contrast Bazel goes through some fair amount of effort not only to detect changes to specified dependencies correctly but also to sandbox build steps to check that they don't depend on stuff that has not been explicitly specified. As the blaze docs say: > When given the same input source code and product configuration, a hermetic build system always returns the same output by isolating the build from changes to the host system. You can get pretty close with bazel; good luck with CMake.
shrubble 4y ago
Curious if you have looked at the Niklaus Wirth based OSes such as that used on the native Oberon and Lilith implementations. Small kernels that ran on what we would today call underpowered systems.
- eterps 4y ago
  It seems that this project is going for a Unix like kernel with a planned POSIX compatibility layer. Oberon was going for the 'Make it as simple as possible, but not simpler' mantra. Oberon is about 10.000 lines of code for the complete OS, including its UI, compiler etc. I love the architecture of Oberon, but today it would be more fitting to use within an E-ink e-reader device. But Helios could eventually evolve into an OS that runs a mail server or web server efficiently. Or even run an existing UI setup like Wayland/Sway.
  - ddevault 4y ago
    The high-level OS will be more like Plan 9 than Unix, but appreciably distinct from either.
  - pjmlp 4y ago
    Oberon was a great experience, for 1990's computers. Now it is only a source of inspiration.
wrycoder 4y ago
And Fuchsia has BSD, MIT type licenses, while Helios is GPL3. Thank you, ddevault.

patrec 4y ago

> questionable tools (with large shadows) such as Bazel and gRPC, Bazel and gRPC, whilst both saddled with problems stemming from Google's inwardly-focused engineering culture (and also just some sub-optimal historical decisions) are not "questionable tools" in the sense that they solve the wrong problems or something else solves the same problems much better. Blaze/Bazel (and its various clones like Buck) are basically the only general purpose build systems out there that even attempt to do the basic tasks of a build system, namely actually figuring out what has changed and needs to be rebuilt. So of course they are gonna use it, nothing else comes even close (and the main downsides don't apply to them). Similarly, gRPC has a lot of warts in both how its encoding, type system, API and transport work. But anything in that space that doesn't completely suck (such as cap'n proto) is basically a clone of the core design. Again what else even attempts to solve the core problem of having some backwards/forwards compatibly reasonably efficient rpc, messaging and data storage?

ahartmetz 4y ago
> basically the only general purpose build systems out there that even attempt to do the basic tasks of a build system, namely actually figuring out what has changed and needs to be rebuilt. Extraordinary claim. You will need to explain how Bazel does that and, say, CMake + Ninja don't.
- brabel 4y ago
  Even [task](https://github.com/go-task/task https://github.com/go-task/task) (a tiny task-runner tool) does that... I don't know any build system that doesn't. Perhaps the OP means full incremental compilation, which requires "cooperation" from the compilers, really (or the build tool actually parsing the language's AST like Gradle does, I believe). Or in the case of Bazel, the build author explicitly explaining to the build what the fine-grained dependencies are (I don't use Bazel so I may be wrong, happy to be corrected).
  - patrec 4y ago
    > I don't know any build system that doesn't. Sure you do. Any build system which has a "clean" command that you'd use for anything other than freeing up space.
    - brabel 4y ago
      And which one is that?
      - patrec 4y ago
        Make, cmake, cargo and npm are all examples of popular build tools that require you to manually "clean" to correct build problems. Make and cmake pretty much all the time, IME, cargo less so, but it happens. Bazel/Blaze and derivatives basically don't.
- patrec 4y ago
  > Extraordinary claim. If you think this claim is extraordinary and CMake is a counterexample, I don't know what to say. Have you really not have had to manually fuzz around with stale builds (by e.g. issuing "clean" commands, removing build/ directories etc) when using CMake or had to figure out why something worked on your machine but not a colleagues? > You will need to explain how Bazel does that and, say, CMake + Ninja don't. CMake makes no serious effort at all at "figuring out what has changed". Even trivial stuff doesn't work. If you have a wildcard pattern in a CMake file and you add a file that matches the wildcard, you will generally get a stale result (which is why it's "not recommended"). So not even explicitly specified inputs work correctly and CMake makes no real attempt to to detect unspecified implicit dependencies. Does your CMake build setup correctly detect when you updated gcc or some system library? That some build artifact implicitly depends on another? By contrast Bazel goes through some fair amount of effort not only to detect changes to specified dependencies correctly but also to sandbox build steps to check that they don't depend on stuff that has not been explicitly specified. As the blaze docs say: > When given the same input source code and product configuration, a hermetic build system always returns the same output by isolating the build from changes to the host system. You can get pretty close with bazel; good luck with CMake.

shrubble 4y ago

Curious if you have looked at the Niklaus Wirth based OSes such as that used on the native Oberon and Lilith implementations. Small kernels that ran on what we would today call underpowered systems.

eterps 4y ago
It seems that this project is going for a Unix like kernel with a planned POSIX compatibility layer. Oberon was going for the 'Make it as simple as possible, but not simpler' mantra. Oberon is about 10.000 lines of code for the complete OS, including its UI, compiler etc. I love the architecture of Oberon, but today it would be more fitting to use within an E-ink e-reader device. But Helios could eventually evolve into an OS that runs a mail server or web server efficiently. Or even run an existing UI setup like Wayland/Sway.
- ddevault 4y ago
  The high-level OS will be more like Plan 9 than Unix, but appreciably distinct from either.
- pjmlp 4y ago
  Oberon was a great experience, for 1990's computers. Now it is only a source of inspiration.

wrycoder 4y ago

And Fuchsia has BSD, MIT type licenses, while Helios is GPL3. Thank you, ddevault.