1. 37

  2. 14

    Fuchsia is not Unix. ;-)

    1. 3

      Technically, Linux isn’t Unix either…

      1. 3


        Not being Linux did not excluded it was a Unix (or a Plan 9), so I checked the syscall list.

        It’s a new operating system. Maybe Pike was wrong?

        1. 1

          That was a good stack of slides. Thanks for sharing.

    2. 7

      Good. The world does not need another Unix, we have more than enough of those.

      1. 1

        But does the world really need another Go of operating systems?

        1. 1

          Good point. Still, nothing ventured.

      2. 7

        An interesting part of this: Fuchsia uses it’s own IPC Schema / Definition system named FIDL.

        And since objects and messages are passed around describing … well … everything throughout the system, there are FIDL definitions for everything from “netstack”, “time_zone” and types used in graphics display to name a few.

        Here’s a bunch of FIDL examples.

        I’m also really digging how each component has it’s own namespace in place of a traditional global filesystem

        1. 2

          Another Google IPC format? Why not Protobuf?!

          1. 3

            At a first glance it does not seem a serialization format, but a binary RPC protocol.

            1. 2

              It looks like it not only handles data serialization but also stubs for interfaces to methods to be implemented in whatever languages that FIDL supports.

              For example see the time_zone FIDL:

              interface Timezone {
                // Returns local timezone offset (in minutes from UTC. Can be negative) for
                // the supplied number of milliseconds since the Unix epoch. Returns a
                // non-zero DST offset when appropriate.
                1: GetTimezoneOffsetMinutes(int64 milliseconds_since_epoch)
                    -> (int32 local_offset_minutes, int32 dst_offset_minutes);
                // Sets the timezone for the machine based on an ICU ID.
                2: SetTimezone(string timezone_id) -> (bool @status);
                // Gets the timezone ID string.
                3: GetTimezoneId() -> (string timezone_id);
                // Watches for updates to the timezone ID.
                4: Watch(TimezoneWatcher watcher);
              1. 1

                Protobuf, or any serialization format like that, isn’t directly usable for IPC without significant modification because Protobuf doesn’t give you mechanisms for sending resources like file descriptors.

                1. 1

                  Well, unix sockets send fds out of band :) but the point is, seems like they started from scratch instead of doing that modification.

                  1. 1

                    Sure, but if you want to use protobuf then you need to hack up protoc to emit file descriptors specially into cmsgbuf, at that point you’re not interoperable with any existing protobuf implementation, so what’s the point?

              2. 2

                See also mach’s mig.

              3. 5

                A modular, capability-based operating system

                Ooh, you got me at capability-based. This alone makes me very excited :)

                1. 18

                  We have capabilities on Plan 9!

                  We call them “file descriptors”.

                  1. 11

                    On FreeBSD, we also have:

                    • process descriptors, like file descriptors but for PIDs
                    • a capability mode sandbox that disallows all global namespace access
                      • you can only do things to file/process descriptors you have…
                      • and derived descriptors like an accept()ed connection or (this is the awesome part!!) a file you openat() below a directory that you have an fd to
                      • (plus it’s possible to further limit an fd’s permissions, even only allow specific ioctls)
                    • a whole new ABI that always starts already in capability mode and doesn’t have non-capability syscalls. (And there’s a userspace syscall translator for running CloudABI binaries on Linux/Mac in development.) Now supported in Rust!
                    1. 3

                      That’s the problem compared with Plan 9, though…why not only have 1 tool? :)

                      1. 4

                        Well, to be fair, Plan 9 does not allow further limitation of an open file descriptor: the open mode is part of the Chan structure shared among the descriptors opened from the dup device.

                        I considered to change this in Jehanne’s kernel, while implementing fcntl in my libposix (a userspace library), but I decided to delay such (little) increment in kernel complexity for when I will have completed the new protocol and its kernel integration.

                        1. 1

                          Because History, of course. But what are the “multiple tools”? Like, why is CloudABI “separate” from Capsicum? Well, it’s a new ABI designed around Capsicum, you can’t really “integrate” it back into normal FreeBSD executables.

                  2. 5

                    Is there a single Fuchsia user yet? When does that happen? Is this targeted at IOT? (I’ve heard that thrown around as a reason for its existence) or is this a take on what computers could be if you stripped away all the legacy?

                    1. 16

                      or is this a take on what computers could be if you stripped away all the legacy?

                      I think that’s the technical ambition.
                      A worth ambition, I would add, since I pursuit it too (if in a completely different direction).

                      But the political reason is pretty obvious: to build a GPL-free system that can get rid of Linus & friends.
                      Under Google’s own control.

                      1. 2

                        I’m a pretty heavy GPL advocate, but this at least is open source.

                        1. 5

                          Sadly this doesn’t mean much.

                          Beyond my own experience with open source operating systems developed by Google employees, I’ve seen in the past that a liberal license means nothing when it comes to the power of such large companies.

                          They have plenty of ways to discourage developers from using the freedoms that the license provides.

                          The careful wording in the PATENTS file is probably one of these.

                          Another could be unusual build infrastructure or huge build times (as in the case of Chromium).

                          Indeed I do not remember any abandoned project from such companies that was later taken from a community (like in the case of open office, for example), but I’m happy to be corrected in this regard.

                          1. 3

                            I take your point regarding the reality that all such agreements rely on parties, particularly the more powerful ones, acting in good faith, and stories like the one you link about HarveyOS certainly should discourage contributing to non-GPLed (or similarly Freely licensed) projects. Or, one may engage with them that way by presuming that your contributions will be appropriated and unremarked. The ability to simply choose to fork the project initially and never give back, though, is something that somewhat mitigates that in the case of BSD, even as it goes against the FSF pro-sharing ethos.

                            I’m not going to get into the patent release; I acknowledge your point but don’t think using that vector is likely. Same, I guess, with the technical discouragements like the build time in Chromium, because that’s extremely legit as a critique of the consequential impacts of that software. I do not think there’s an abstract philosophical defense against any of the points you raise, in the context of an FSF philosophy.

                            But as long as we’re getting consequentialist here, there are reasons to believe that the interests of Google and the People are aligned on this project. I think their ambition is to have a Zircon-based OS running on devices from the scale of phones and watches on up to a datacenter-sized supercomputer, seamlessly participating in distributed computation, and the only way to achieve that is to make it as ubiquitous as possible. In order to do that, it needs to be developer-friendly, because as an operating system, it needs to appeal to people like us (technical users, developers, etc.), whereas something like Chromium doesn’t. Regarding my thesis about their ambition, from https://fuchsia.googlesource.com/docs/+/master/the-book/life_of_an_open.md (emphasis added here):

                            Once the message has been transmitted from the client’s side of the channel, it lives in the server’s side of the channel, waiting to be read. The server is identified by “whoever holds the handle to the other end of the channel” – it may live in the same (or a different) process as the client, use the same (or a different) runtime than the client, and be written in the same (or a different language) than the client. By using an agreed-upon wire-format, the interprocess dependencies are bottlenecked at the thin communication layer that occurs over channels.

                            I have seen good operating systems be BSD-licensed (for example, *BSD). I’m pretty stoked about this project.

                            1. 7

                              Well, from a technical point of view, I’m pretty sure it will be a great piece of software.
                              And given how primitive are the mainstream operating systems right now, any piece of research is welcome for me.

                              But I do not think that “the interests of Google and the People are aligned on this project”.
                              I trust the Fuchsia developers’ skills, but Google is a huge corporation: its interests evolve independently from any ethical consideration, and its open source software is always a strategical marketing tool.

                              Take Chromium, for example: it’s a great software that pushed the web forward (and JavaScript abuse with it, but this is another story), but its main purpose was to defeat Microsoft.
                              I was naively fooled to think that the creation of Google Chrome Frame was a sort of philanthropic effort to helps those people who were stuck to IE. It was not.
                              Indeed IE still sucks and many people are still forced to use it, but Google abandoned GCF when they won the war they cared about.

                              While I still think that Microsoft purposely tried to slowdown the web for its own interests, Google was not better, just smarter: Google was able to dress its marketing strategies as philanthropic gifts, for years.

                              Now they are doing the same with Fuchsia.

                              If they will success, they will spread an os that is just “formerly” open source, but they will lead the development both technically and politically. And you will see a lot of effort from other companies too to make this happen. Just like such companies invest in LLVM, another great piece of software that is designed to defeat the most important piece of code controlled by the Free Software Foundation: GCC.

                              As of today, indeed, I don’t think big companies are scared by the “virality” of the GPL.

                              They are much, much more scared by the message it carries: programming is a powerful political act. Probably one of the most powerful.

                              Had this realization to mix with the consciousness of how primitive is our field, they would completely loose control of their programmers (that they already try to keep under strict control with various methods).

                              So just like Microsoft did not really understand what was happening with Chrome, now everybody looks at Fuchsia just for its technical design.

                              But don’t get fooled, the enemy now is the true hacker’s culture that people like Richard Stallman, Linus Torvalds and Theo de Raadt, despite their differences (or maybe exactly for their differences), represent.

                              1. 3

                                I can’t argue with you, and even wrote similarly last year: https://blog.joeardent.net/2017/01/say-no-to-corporate-friendly-licenses/

                                1. 1

                                  Nice read.

                                  We live in a world where a group of eight people have control of more economic means than the poorest four billion people, and the power disparity between our corporate masters and regular humans is unimaginably vast. There’s very little that you or I can do, but we do have one ace up our sleeves: we write software, and software increases our leverage. So don’t give that leverage to the leviathans trying to commoditize you.

                                  I really think that we, as hackers, should deeply reflect on the power that we have.

                                  And on the responsibility that comes with it.

                              2. 2

                                I’ve been interested in distributed, capability-based systems for a while, since EROS/CoyotOS in the early 2000s, and Zircon/Fuschia seem like the best shot at embodying the spirit of those systems, as in, eg, http://www.capros.org/overview.html

                              3. 1

                                How do huge build times restrict developers’ freedoms? Does Gentoo suffer the same fate?

                                1. 2

                                  Well, in 2015 I was asked by one of our customers (a large multinational bank) to evaluate the fork Google Chrome Frame when Google retired its support.
                                  They used it over IE8 for their intranet (a pretty secure environment, AFAICT) and just wanted someone to call in case of functional bugs for a couple of years.
                                  The budget they were ready to pay for this request was pretty high, and the technical skill of my team were (and are) pretty amazing.

                                  If I remember correctly, it took 3 days to get the build complete on my desktop.

                                  Managers were already pretty scared by the risks (that for the first time in their lives, they were over-estimating), so when I said this, they incredibly decided to refuse such opportunity.

                                  Explaining that we just needed another server for the continuous build, was not enough.

                                  This despite the Chromium license.

                                  1. 2

                                    It sucks that you lost a customer and I don’t want to get into the details of your build setup, but maybe the long build times are just inherent to a large C++ application? I understand your argument that a company with deep pockets can afford to work on more complex software faster, but was compiling Chromium that much slower than a comparable non-profit project like Firefox?

                                    1. 1

                                      Also, I was implicitly (sorry) replying to your comparison with Gentoo.

                                      While maybe the Gentoo team have a continuous build setup comparable to that of Google, few people need to fork Gentoo because they have been locked in.
                                      And even those who do, would not build it frequently as a whole.

                                      Forking a single complex application is a completely different matter.

                                      1. 0

                                        It sucks that you lost a customer

                                        Well… it’s still one of our best customers!
                                        But we lost a pretty interesting work (both economically and technically).

                                        I don’t want to get into the details of your build setup

                                        Frankly I do not remember much. It was the first and last time I had to build Google Chrome Frame.
                                        But I remember it was not an easy task: I remember an unusual number of WTF (why the hell they did it so?)

                                        I understand your argument that a company with deep pockets can afford to work on more complex software faster, but was compiling Chromium that much slower than a comparable non-profit project like Firefox?

                                        Honestly, I didn’t try.
                                        But as far as I can read, there is still a huge factor, between Firefox and Chrome.

                                        The point however is that people should realize that Open Source from big companies is just marketing.

                                        At best, they do not really care about external developers (as opposite to Free Software).

                                        Sometimes they just look for minions that work for free for them.

                                        At worst, they are fooling developers to give up their freedom (and power).
                                        And they are pretty good at this: I’ve talked with many smart developers that were not aware of how much they were working against their own long term interests.

                                        Note that the problem is not the license and while I value collaboration over competition, alternatives are always a good thing. The problem is who controls the projects for real.

                                        1. 2

                                          I am familiar with the high level of WTF for building Chromium (and AOSP too, right?).

                                          Do you think it has anything to do with this? https://lobste.rs/s/mbufwv/some_software_cannot_be_used_at_google

                                          make is GPL. So is autoconf. Etc?

                                          1. 1

                                            Maybe. Frankly I cannot say.

                                            I build my OS with a few disposable Go scripts. I will replace Go with a simpler general purpose language asap, but I will not use GNU Make or Autoconf (nor cmake or worse shits) because I want to see how far you can follow a minimalist approach.

                                            However building Jeanne, from source to the first drawterm connection, requires just a handful of commands documented in the README.

                                            And Jehanne is pure research.

                                            But I think that if I were going to write a Free Software browser, I would use the most battle tested and well known tools, exactly to minimize WTFs.

                                            In practice, it depends on what you want to do.

                                            If your goal is to create a distributed system that replace current computing techniques from the ground up, you probably do not care much with compatibility: your gift to the world is the brave innovation that breaks every conventions.

                                            On the other hand, if you want to create a Free Software for the current world you should focus on that and maximize for developer’s friendliness.

                                            But what if you want to spread a new browser to break a monopoly while keeping the full control of that software?

                                            Open source to the rescue!

                            2. 8

                              I think, like many of Google’s other “extra” projects, it’s mainly a hedge. It makes sure they can’t be boxed in in the future if something unfavorable happens with Linux, just like Android was created mainly to ensure they wouldn’t ever be at the mercy of other mobile OS makers choosing to switch away from the Google ecosystem. Like Android, if it turns out to be a pretty good OS that becomes massively popular, that’s a bonus for them. If it turns out to be a disaster, they can abandon it, it’s pocket change for them.

                              1. 4

                                My guess is that Google found that both ChromeOS and Android aren’t enough for business users, and are going all in on developing an alternative to Windows and macOS. Instead of .NET/C#, or Cocoa/Obj-C, you have Flutter/dart.

                                I’d expect a series of notebooks, eventually, that are similar, hardware wise to Chromebook Pixel, running Fuschia, that can be members of the “Google Apps domain controller” but have a traditional set of applications that don’t just run in a browser.

                                1. 4

                                  If you look on YouTube, you’ll see people actually running the graphical/desktop Fuchsia, either in VMs or on Google hardware. A lot of stuff is broken, but it gives you an idea of what the graphical environment will eventually look like.

                                  1. 1

                                    The plan to strip away all the legacy from unix was apparently numbered nine, which fell off with its parent company.

                                    It’s good that google is carrying it over with a bucket of bright paint. Namespace is great. FIDL is really just two letter more than fd. I really hope google will carry it through. No one want a plan b.

                                    Once Fuchsia achieves acme, I will be happy to run it in qemu.

                                  2. 4

                                    This is a very interesting project I’m excited to follow as it develops.

                                    I’d love to know more, however, on how IPC is implemented such that the performance penalty doesn’t make this prohibitively slow versus monolithic kernels. I know that syscalls in Linux, for example, require context switches that are very expensive relative to a lot of operations. I’ve done some fruitful optimizations that involve simply minimizing the number of syscalls. But the design of Fuchsia implies a much higher number of inter-process context switches. By reading the design docs, it appears sending a message across a TCP connection over wifi could require messages to be sent over several isolated processes (netstack, ethernet driver, WLAN MLME driver, softmac driver). In Linux this would be a single syscall.

                                    I won’t naively assume that syscalls are inherently expensive, and I assume Fuchsia’s syscalls are much cheaper than Linux’s. But is this quantified yet? If Fuchsia’s are much cheaper, what are the architectural and implement decisions that were made to take it true? How does Fuchsia differ from Linux in this respect?

                                    1. 3

                                      Zircon is a graphical IRC client I used a long, long time ago.


                                      1. 2

                                        What is interesting is that you see the Web Runtime along POSIX as “platform compatibility”

                                        1. -2

                                          This is not news