1. 36
  1.  

  2. 6

    There is a comparison to Plan9 and Hurd, but not to GenodeOS (which superficially seems more similar).

    I am not sure if Fuchsia brings anything actually good compared to Genode (and it would be interesting to see); of course, the adoption question is drivers, and Fuchsia will get adoption if Google forces manufacturers to support it, now without any problems around closed-source drivers.

    1. 8

      I heard more BeOS influence, due to the Be alumni working on it.

      1. 6

        And we don’t get a BeOS comparison, either.

        A bit like explaining Git while being careful to never compare it to preexisting DVCSes, only to Monotone — on the other hand, that approach usually works…

        (And I guess running Android apps on Fuchsia also means that security changes will matter more in terms of protecting manufacturer from consumers actually owning the device, than in providing consumers with securities, as most of the user-facing security problems are apps being happy to leak their entire state — although indeed it might also make it simpler for a custm build to provide fake sensitive data)

        1. 1

          Well, with no global file system, it should be easier for apps to have their own private storage to protect the customer from greedy data scouting.

          1. 2

            Hard to say how many vulnerabilities are exploited as single-app takeovers (these will probably stay in Fuchsia).

            On the other hand, cross-application interoperation becomes harder and users lose the ability to have file managers…

            (And some kind of cross-app message-passing will probably formally exist — inherited from intents — but will continue to require too much opt-in from apps to be widely useful — like OpenIntents that apparently didn’t even take off among apps explicitly wishing to ship in F-Droid)

          2. 1

            The speaker isn’t actually working on the OS so perhaps wasn’t aware of those comparisons to be made.

          3. 2

            If Fushia internals are remotely comparable to Be’s KernelKit then it’s a great architecture. I wrote an embedded kernel in grad school using Be’s documented Kernel API, and it’s extremely well designed. The VFS is a piece of art*; I still have fond memories implementing vfs_walk(). It’s a shame BeOS’ architecture is not better studied.

            *not technically part of the kernel and well detailed in Practical Filesystem Design de D. Giampaolo.

            1. 4

              It’s not really like BeOS, no; BeOS was a monokernel, and Fuchsia is a microkernel. There are some vague similarities, but not anything too major.

              On the other hand, Haiku is a complete re-implementation of BeOS including the kernel, and IMO our APIs are even more beautiful than Be’s … but I am biased, of course. :)

            2. 1

              And we don’t get a BeOS comparison, either.

              A bit like explaining Git while being careful to never compare it to preexisting DVCSes, only to Monotone — on the other hand, that approach usually works…

              (And I guess running Android apps on Fuchsia also means that security changes will matter more in terms of protecting manufacturer from consumers actually owning the device, than in providing consumers with securities, as most of the user-facing security problems are apps being happy to leak their entire state — although indeed it might also make it simpler for a custm build to provide fake sensitive data)

          4. 6

            I always find it annoying when existing concepts (pipes/fifos) are renamed (channels).

            Are Cox, Pike et al involved in the project at all?

            1. 9

              I don’t know all the details about channels but it’s clear that they’re not the same as pipes/fifos. For one thing, it seems like it takes discrete messages and not a stream.

              1. 0

                That just means they are slightly less flexible than pipes/fifos, and I’m not sure why. Isn’t sending data “as it’s received” over a “channel” still a valid usecase?

                So once again, the wheel is reinvented in a worse way than before with no reason for doing so…

                1. 9

                  I’m not sure why.

                  Exactly. I don’t think you should rush to judgment on this one. I don’t know the answer but a good way to find out would be to ask the developers or use the source.

                  no reason for doing so…

                  Do you have to trap to send data on a channel? If not, it could be a lot more efficient than pipes are.

                  1. 0

                    OK, so then the analogy is a UNIX domain socket, not a pipe/FIFO. It still does not make a ton of sense that you can’t send stream data over them…

                    1. 2

                      I just RTFM’d a bit on channels and it seems to have very specific semantics which distinguish it from other IPC.

                      I think it makes sense to have the features that channels do – they help satisfy the microkernel design and the partitioning/encapsulation of the different OS functions while hopefully not introducing significant overhead beyond what a monolithic kernel would have.

                  2. 1

                    Exactly. I don’t think you should rush to judgment on this one. I don’t know the answer but a good way to find out would be to ask the developers or use the source.

                    Why worse? If a message is a single thing, then you don’t need to worry about PIPE_BUF size when sending? Could you not just send a stream of 4096 sized byte arrays to get a pipe?

              2. 1

                It looks to me like while the process isolation enhancements are a big deal, the main reason for Fuchsia is the explicit support for proprietary device drivers. The Linux device driver model is good, actually – you upstream your device drivers, in which case everything Just Works out of the box, or you maintain them out of tree, in which case they eventually bitrot. Android hardware vendors have explicitly made the decision to never upstream drivers, which means that effectively you never have kernel updates for most devices. And never having kernel updates eventually puts an upper bound on Android updates. Having proprietary driver support takes the pressure off of hardware vendors to do the right thing, while allowing kernel updates.

                If Fuchsia actually replaces Android-on-Linux, I may be in the market for a GNU/Linux phone eventually. The Purism Librem 5 is a bit rich for my blood, but the Pinephone proves that GNU/Linux phones don’t have to be…

                1. [Comment from banned user removed]

                  1. 4

                    Any elaboration on why?