1. 32
  1.  

  2. 18

    All I want in my technical life at this point is to use less google software.

    1. 3

      I understand staying away from Chrome, Gmail, and Android due to the surveillance, but what’s inherently wrong with a new OS kernel, even if it is Google that’s developing it?

    2. 15

      I’m excited by modern OS kernels not based on 50-year-old designs, and especially in capability-based systems. Both Fuchsia and Genode/Sculpt look really interesting. How do they compare technically?

      (A nitpick on the article: “Pink” the name was entirely Apple’s. Pink the OS was already up and running by the time IBM joined in. In 1991 I was working in the same building as Pink, De Anza 6, and I remember the day we saw a group of guys wearing suits 😳 walking up to the 3rd floor. Later found out it was an IBM delegation coming for a demo.)

      1. 3

        I chuckled at the pink/purple guesswork, because there’s another sad connotation to “pink” that google probably also didn’t intend: A large number of engineers who didn’t jump from Danger to Android ended up getting swept into a doomed Microsoft phone project called “Project Pink” which finally expired with the release of the Kin.

      2. 9

        babymosesinabasket, was not expecting to see Google use suckless.org’s sbase, all with their minimalist software and quirky argument parsing (ahh, arg.h, my favorite) in the name of “simplicity” (since when did Google care about that?). Maybe because it’d be easier to port, being much smaller than, say, Busybox or GNU coreutils?

        1. 19

          We also use a fork of musl for our libc. When you’re really not unix it’s way easier to get something very simple up and running. The things I did to get opensshd running are not pretty.

          (I work on Fuchsia, I do not speak for my employer, etc)

          1. 5

            As someone who works on Fuchsia, can you comment on something that’s missing from the article: namely, there’s fear that a primary motivation for developing an alternative to Linux is to avoid the copyleft requirements of the GPLv2. This would result in creating devices for which alternative operating systems such as LineagoOS or PostmarketOS would no longer be possible. Is this discussed or a concern by people who are working directly on Fuchsia?

            1. 3

              I can’t comment on what my lovely employer’s motivations are - they seem to have a general policy of releasing under Apache-style licenses which I think is roughly what most of what Fuchsia is released under. Much of the internal documentation about this stuff is posted publicly. If the primary goal was to have an operating system that didn’t have the constraints of the GPL then building something largely from scratch would seem to me to be a terribly inefficient way to do it. There are plenty of great operating systems like FreeBSD that could easily be taken as the basis for a non-GPL Linux replacement. FreeBSD, being a POSIX-style OS is much much closer to Linux than Fuchsia is or is designed to be.

              I personally am an ardent believer in copyleft, especially the *GPL family. I remember where I was sitting about 25 years ago when my friend Peter told me to read What Is Free Software. Over the past 25 years I’ve worked for companies that have written both free software (under a variety of licenses including GPL, MPL & Apache) and proprietary software. I’ve contributed to a open source projects and released my own creations. When I own the copyright on something I almost always choose the GPL or LGPL unless there’s a clearly established alternative license within the ecosystem I’m contributing to. While lots of the work I’ve done hasn’t increased the amount of software freedom in the world I wouldn’t work on something that I thought would reduce the amount of software freedom and I don’t think Fuchsia does.

          2. 6

            I also assume they used our sbase due to portability and licensing, and am glad to know they were able to make use of it.

            What’s wrong with arg.h’s rock-solid argument parsing? :)

            1. 2

              What’s wrong with arg.h’s rock-solid argument parsing? :)

              I have a love-hate relation with it. On one hand, it’s slightly more straightforward to use than getopt, and works perfectly on Windows. On the other hand, it doesn’t support long arguments and I recall it having strange parsing issues with certain inputs (but that was a while ago, it’s entirely possible that I’m misremembering or that the issues were fixed in the mean time).

          3. 6

            This article looks pretty great. I’ve been working on Fuchsia at the $DAYJOB since we started it, basically, and the article seems to grok a lot of what we’ve built.

            1. 1

              ARM would be nice. New macs and rpi are popular.

              1. 2

                Fuchsia runs on ARM64, I just don’t think we’re building a darwin/arm64 host toolchain, yet.