Fuchsia, a new operating system | Hacker News Reader

Fuchsia, a new operating system

github.com

384 pointshelloworld517165 comments

The repo at https://fuchsia.googlesource.com reveals a rather interesting UI story for this new operating system.

It seems like the intention is to use Flutter [1] as the UI layer. Flutter uses the Dart language, so there's a Dart environment included in Fuchsia too [2].

For rendering, Fuchsia includes a project called Escher [3] which is described as a physically based renderer that supports soft shadows, light diffusion and other advanced effects. Looking at the source code, Escher is designed to use either OpenGL or Vulkan as the underlying graphics API. (There's an iOS example project included in Escher's source tree. Would be interesting to build that.)

It's not immediately obvious why a lightweight operating system would need a renderer that can do realtime soft shadows and light effects...! But I think the idea here is to build an UI layer that's designed from scratch for Google's Material design language. Shadows and subtle color reflections are a major part of that "layered paper" aesthetic.

So, the stack seems to be: Dart is the language for GUI apps, Flutter provides the widgets, and Escher renders the layers.

The underlying application framework is called Mojo [4]. It already offers bindings for Go, Java, JavaScript, Python and Rust in addition to Dart, but maybe those languages are meant for services rather than GUI apps. (At least I can't see an easy way to create Flutter widgets from something like Rust without loading the Dart VM.)

[1] https://flutter.io

[2] https://fuchsia.googlesource.com/dart_content_handler/

[3] https://fuchsia.googlesource.com/escher/

[4] https://fuchsia.googlesource.com/mojo/

> Shadows and subtle color reflections are a major part of that "layered paper" aesthetic.

They're a part of design language, raw elements of design. This can get much bigger than the Material Design of now. It can make sure that the subtle or even zany, domineering design of tomorrow has just the right level of refinement for its intended audience.

IMO as a graphic designer and as someone who has been doing 3D rendering as a hobby for 15 years, it's pretty awesome to think about PBR moving into the area of UI.

PBR == Physically-based rendering?

Yes

Most interesting for me was the Mojo interfaces defined at https://github.com/fuchsia-mirror/mojo/tree/master/public/in... and https://github.com/fuchsia-mirror/mojo/tree/master/services.

E.g. the application interface at https://github.com/fuchsia-mirror/mojo/blob/master/public/in...

And the framebuffer interface https://github.com/fuchsia-mirror/mojo/blob/master/services/...

I don't see any mention of a file system.

I'm calling it now: this is for augmented reality displays and similar. You want an RTOS for loss and predictable latency. And current GUIs aren't really suited to 3D environments you can walk around inside.

This is Google's next Android, with a low latency rendering pipeline for the next generation of mobile devices.

Wouldn't that be nice after Google has affirmed again and again that Java would be the only supported way to develop Android apps, even though they keep Dart funded internally...

Hey, I'll bite. Let's see.

I predict this will end up being a completely new platform.

It will share nothing with the present Android architecture initially. They'll probably shove in an Android sandbox, so that you can run some existing Android apps and stick them somewhere in your virtual space. But those won't be native apps on this new platform.

The new apps will have drastically different needs, input methods and such.

Consider the simple example of a new turn-by-turn navigation app. It will have a waypoint shown in your field of view, with an arrow pointing to the next waypoint after it. It has to 'stick' in a virtual location that corresponds to a physical one.

There's no way to do that sort of thing with the existing Android API, the concepts simply don't exist. Rather than have everyone write their own (like video games do that implement navigation inside the game world), they'll create a new API for this. And a whole new operating system.

When did they "affirm" that? They've said a couple times that "Java at this time is the only way to build apps," etc. They never ruled it out for the future, AFAIK. Please feel free to prove me wrong, but I would honestly be surprised if you found anything.

Having been to the last several I/Os where the question is asked at the fireside chats, the answer has always been "right now...". No one is saying dump Java, but if we could get some native hooks through something like Dart, that would be pretty awesome.

"Java at this time is the only way to build apps" is the right answer for Android OS, because the Android OS is a combination of an app runtime and a Java middleware layer. Adding another runtime to Android would make it a second class citizen, or it would involve building a parallel middleware. What they really mean is that the result would be messy, and it wouldn't be Android-as-we-know-it.

You can, of course, move the Android middleware layer to other OSs, for Android compatibility. Which is how you can run Android apps alongside Tizen apps: https://youtu.be/nmiHPcHGgSM

Android was designed for one runtime, Dalvik and later ART. But there is nothing preventing a new OS being designed for multiple runtimes that includes runtime support for Android apps.

I'm generally not sympathetic to Java complainers. If you have Android Studio, or any other decent IDE, verbosity isn't a problem. But an OS built for Dart apps and a Dart UI stack would be the logical next step.

Brian has been talking about how much he hates Java, its programming model, event loop, and everything else about it for many years, to anyone who will listen. Tastefully chosen for the augmented reality, self-organizing, and real-time use cases, the building blocks: UI, rendering, and app framework, all this looks like what he would create for the next generation of connected devices, of which phones are just a momentarily important example. Without Andy Rubin shoving a tech stack down his throat, I would add. I am somewhat disappointed by the DART choice, but overall really excited to see what this turns into. Great that it is open source for now, but this is Google, so you know where that will go.

Google is simply telling you what they currently want you to know. They're not going to disclose their roadmap.

Good job

Brilliant.

Fuchsia is not a combination of pink and purple. It is the color your brain comes up with when it sees contradictory color signals (such as very high and very low wavelengths without the appropriate middle stimulation). It's the only color not in the rainbow. As you can see from this additive color program (http://trycolors.com/?try=1&ffb5d9=0&c31cff=0), pink and purple create a lavender color. Whereas fuscia is what happens when you combine colors in an unusual way (http://www.exploratorium.edu/sites/default/files/ColoredShad...). Normally I wouldn't be this pedantic, but this is hackernews after all.

To be clear on its origin its from the fuchsia flower which was made into the fuchsine dye which has these properties. See for its relationship to the visual spectrum [1] noting that the visual spectrum is ~400-700nm. The plant absorbs only the middle of the visual spectrum not the ends. This is the kind of stuff neither RGB monitors nor CMYK prints can capture well.

Note this isnt the complete story either as your eye may percieve it very similarly to purple anyway due to the way we see light (through our rods and cones which clump the spectra again anyway and are subtlety different for everyone).

[1] https://www.researchgate.net/profile/Bo_Hu12/publication/231...

To be yet more pedantic, it's the only fully-saturated color that's not present in the rainbow.

Colors are perceptual phenomena- the interpretation of a spectrum of light impinging on a patch of retina that almost invariably contains more than one frequency at a time. Colors include white, black, gray, pink, tan, beige, baby blue- none of which are in the rainbow.

How do I read more about this "not being in the rainbow" aspect of this color ?

Wikipedia[1] has nothing to say about it ... in fact, the wiki definition of "fuchsia and magenta are exactly the same color, made by mixing blue and red light at full and equal intensity" makes it seem not that interesting at all ...

[1] https://en.wikipedia.org/wiki/Fuchsia_(color)

>How do I read more about this "not being in the rainbow" aspect of this color ?

By a color "not being in the rainbow" we mean that if you take light and spatially separate its different frequencies (like what happens in a prism or droplet of water), none of those individual frequencies will produce that given color response. And no, it's not that interesting. Almost all color perception experiences involve stimulating a patch of retina with multiple frequencies; we've given names to many of those experiences.

A way that I have had the idea of this explained is this. There are two ways to experience most colours.

Take yellow. You could experience yellow by seeing pure yellow light which is at the yellow wavelength. The other way to experience yellow is by seeing a mixture of red and green wavelength light.

Your eye can't tell the difference between these two types of yellow. The yellow as reflected off a banana is "real" yellow. The yellow you see coming out of your computer monitor is actually just a mix of red and green.

Magenta is interesting because the only way to experience it is by a combinations blue and red. There is no "real" magenta.

This video explains this concept very well:

https://www.youtube.com/watch?v=R3unPcJDbCc

Actually, lutein in banana absorbs blue and violet, reflecting the lower wavelengths. http://jn.nutrition.org/content/132/3/540S/F2.large.jpg

I don't understand why a single wavelength would be considered the "real" stimulus that results in a color perception while other metamers for that perception are somehow less "real".

That's why I put "real" in quotes. There isn't really another single word I can think of that gets the idea across.

"Pure"?

"Simplest"?

If you're really into colors, I suggest to read the xkcd: https://blog.xkcd.com/2010/05/03/color-survey-results/

Have fun!

I forgot about this, Randall Munroe sometimes does things I'd like to do. And, I also "weep for my gender".

Some more background on the 'line of purples', of which fuchsia is a part: http://hyperphysics.phy-astr.gsu.edu/HBASE/vision/colper.htm...

From your reference: "The 'line of purples' across the bottom represents colors that cannot be produced by any single wavelength of light." The GP is suggesting that fuchsia is special, but surely what he/she said applies to all the purples?

A rainbow starts at red and ends a violet. In your brain, the rainbow wraps around in a circle, connecting red and violet. This is not the reality of the wavelengths, so your brain makes up a color that fits between red and violet.

It's also almost an octave of color---I cut my brain some slack

Do you mean a cylinder?

> It's the only color not in the rainbow.

Wrong.

I hate this argument about pink/fuchsia being "special".

most colors are not in the rainbow. most colors are what our brain comes up with when it gets contradictory signals. However, most colors are "close enough" to a color that's in the rainbow. Pink isn't. But this is very subjective and depends on the culture you originate from -- for example, in Japan green and blue are often regarded to be shades of the same color. I'm sure that similar things can happen with pink and red. If you've grown up with the same word for pink and red, thought of them as the same color, and only later learned names for the individuals shades, you'd probably say that pink is in the rainbow (and perhaps some subdivision of blue is not)

No you're wrong.

Pink is the only colour that doesn't correspond to a colour on the rainbow (a "real" colour if you like). Rainbow colours are single-frequency, i.e. they can be generated by a laser. You can have a red laser, a blue laser, a yellow laser, etc. But you can't have a pink laser.

But also, that doesn't mean that fuschia isn't a combination of pink and purple. OP is being super-pedantic to the point of being wrong.

You haven't refuted my point. I agree that rainbow colors are single-frequency. I'm asserting that most colors we see are not.

Rainbow red is single-frequency. Most shades of red which we see are not. Rainbow blue is single-frequency. Most shades of blue which we see are not. Etc. You can have a red laser, but not a laser for most shades of red. You can't have things like a maroon laser.

The only reason pink is special is because we do not consider it to be a shade of a rainbow color, which is a cultural thing.

I think you are conflating purple with (spectral) violet here. All purples are created from the mixing of high and low wavelength and are not present in the rainbow.

Violet, which is present in the rainbow, is not available for addition in the links provided since it can't be represented on computers using blue as their lowest wavelength primary.

yes and from !wen:

"In the RGB color model, used to create colors on computers and television screens, and in web colors, fuchsia and magenta are exactly the same color, made by mixing blue and red light at full and equal intensity."

Some useful bits from IRC:

[16:21] <ocdtrekkie_web> Why's it public (mirrored to GitHub even) but not announced or even documented what it's for?

[16:22] <@swetland> ocdtrekkie_web: the decision was made to build it open source, so might as well start there from the beginning

[16:22] <lanechr> ocdtrekkie_web: things will eventually be public, documented and announced, just not yet

[16:23] <@swetland> currently booting reasonably well on broadwell and skylake NUCs and the Acer Switch Alpha 12, though driver support is still a work in progress

[16:24] <@travisg> yeah and soon we'll have raspberry pi 3 support which should be interesting to some folk

Sidebar comment: I wonder how much more activity this thread would be getting if the subject line had "by Google" in it. LOL

Hmm, Travis Geiselbrecht of NewOS, Danger and BeOS fame and Brian Swetland of BeOS fame as well? Interesting.

I did also work on this Android thing that shipped on a few phones over the years, as well as on Danger/HiptopOS.

(Not that I'm not proud of my BeOS work, but that was almost 20 years ago now...)

Travis should get credit for work on iOS and WebOS too, if we're keeping score, I suppose!

Hehe, sure, and you could say Android is HiptopOS-the-next-generation. FWIW, I've also omitted Travis's Jawbone work. I mean, it was very public where Travis worked after Be, but I didn't really know what you have been up to, sorry that I didn't know more.

BeOS stands out to me, and I honestly don't care how long ago it was. WebOS was nice, but Android and iOS don't even register on my personal radar of cool tech. I hope you're not offended by that. For instance, while it was possible to do low-latency audio on BeOS in 1998, it's only possible with a lot of trickery on Android. You can do low-latency audio on Linux and Windows too, but again it needs special tooling and config, though not as hard as on Android's Java-based stack.

Think of it like this: people will remember artists for certain work during specific periods because it touched them in a special way. BeOS was that during my formative years, and you could say it was the Amiga of the 90s. Sadly, there's nothing that replaces the innovative features of it, even though we've improved other parts of the stack.

It's just such a shame that BeOS is locked in some IP locker in Japan (Access Ltd) now.

Not at all offended. BeOS did a lot of neat stuff and was ahead of its time in many ways. It had its warts too and sadly did not survive, though the Haiku folks have been working hard to re-create it over the years. Much of that has surfaced in other platforms since then (node monitoring and a true device filesystem were big features of BeOS I liked a lot that are available in Linux today, for example).

BeOS got me out on the west coast and doing OS development for a living. I learned a ton of stuff while working at Be and got to work with a bunch of amazing people (some of whom I still work with today).

Pink = mobile, Purple = PC

Warm?

Any chance you could write the OS in Rust, while it's still in its early stage? It could avoid a whole lot of security issues down the road, which I think even Dart's VM won't be immune against (at least from what we've seen with Android - like the dozen+ stagefright vulnerabilities).

Travis is on it!?!? Oh boy now I'm interested..

I was just think of the BeOS connections too.. very interesting indeed.

The original title of the thread was indeed "Fuchsia. (a new operating system from Google?)"

I came here through the RSS feed, and likely would have ignored it without the "Google" mention.

Aha! Dart Flutter Go ... it's going to be interesting for sure.

Cannot wait for rpi3 support!

I remember a post earlier today about how open source projects needed better marketing. prime example. I had to dive in to know what was the project all about...

The problem isn't marketing. It's culture. While there are many benefits to free and open source software it encourages a take-it-or-leave-it attitude where software is released that's user unfriendly, full of bugs, and has little to no documentation. If someone dare ask about a problem they are having, often the closest thing to help they receive is "Why didn't you just use [esoteric Linux command]? Are you an idiot?"

Maybe the cultural problem is actually that people like you expect open source projects to be like companies except that you don't have to give them money? Most open source code is written by someone because they want it and then they release it so others can see the code. Of course there's a take-it-or-leave-it attitude... why would they care if you take it? They don't get anything if you take it, you taking it was never their goal. You're just some entitled guy on the internet who decided he wanted to use the software, had a problem and now thinks the developer should do some free work for him.

There's a problem somewhere in the system of open source and the people who use it, and everyone above me provided many examples of dysfunction.

It's dysfunction of a system with a very unclear reward framework, primarily centered around curiosity, pride, and drive. Developers want to build something they consider good; often they want to build something that others will find good and use, and there's intrinsic value and joy in that for them: not all developers are selfish, many do it for others. Users find their creation fascinating and good, if not better than anything out there; users who are programmers both demand more goodness and contribute of their own accord, making a kind of trade in kind. Users who are not programmers or not skilled enough (by no fault of their own) are using it out of necessity or because it is good, but due to the disconnects in the method of creation, it's not inherently good in ways that users expect, and it could be seen as helpful or at least informative to give the creators an idea of how this pridefully created thing could be made better and help more people. This is natural. No one owes anyone anything; this is all just unavoidable human behavior and psychology.

It is not a particular group or person's fault that this convoluted system is not effective. But the wise will look beyond the individual needs and wants of the actors and help find ways to improve how the Open Source paradigm—the system itself—can be improved.

Admittedly my response is another extreme from the parent comment. I run an open-source project and certainly don't have a take-it-or-leave-it attitude toward it. Although I also run a company behind that project and do get paid for some small subset of the work I do on the project; it'd be a lot harder to maintain that attitude if I didn't. I don't think open-source is perfect, it could be better and in my opinion is constantly improving. I disagree quite a bit with your characterization here though.

You talk about there being a problem somewhere in open source and how it's not any particular persons fault that this convoluted system is not effective... what on earth is your definition of "effective" that it's failing to meet? You mention how "Users find their creation fascinating and good, if not better than anything out there" that sounds pretty effective to me. Consider some concrete examples here:

- Linux, cornerstone of the web used by millions would have cost several billion dollars to build in a non open-source way. - Android, used on millions of phones because it's open source and others can modify it. - Chrome and firefox - Every programming language

Believe it or not these projects didn't succeed despite the fact that they're open-source, they succeed very much because of it. So yeah, let's all grab the dick to the left and pretend that open-source is some broken paradigm that doesn't produce results because some new project doesn't have nice enough documentation.

> Users who are not programmers or not skilled enough (by no fault of their own) are using it out of necessity or because it is good, but due to the disconnects in the method of creation, it's not inherently good in ways that users expect

Some projects will care about these types of users, many won't. That's just the reality of software and there's no obligation to include everyone. Talk to an illiterate person and they'll tell you all about how ineffective the publishing industry is. That doesn't mean publishing should change.

Maybe it's useful to point out here that:

  - Chrome is built on Chromium, which is open source,
    but Chrome itself is not.
  - Android is based on open source technologies, but is,
    again, not itself open source in many cases.
  - Many, if not most, programming language implementations
    are not open source.  In fact, you're dating yourself
    with this claim, as those with more experience remember
    the dark days of paying for compilers.
    Even C compilers.

I wholly agree with your sentiment, that open source projects work very hard and get little credit. I'd expect the GP agrees as well.

Could you be a bit more generous to the author of the comment you responded to? Your point really lines up quite well with theirs, if you spend a few moments considering them.

I spent plenty of time considering it the GP, my point lines up with it insomuch as I agree that open-source isn't perfect and can / is being improved. That's really quite a platitude though and on the important pieces we do disagree. I don't think open-source has an unclear reward framework that's causing it to under server nonprogrammers. It's just the there's only very seldom a reward for serving nonprogrammers. And quite often there is a reward for alienating those people so that developers don't have to spend all their time explaining basic principles to them. This doesn't fit into some high minded view of open-source that it's all about getting contributions from everyone and working together. In reality open-source projects make progress by attracting a few very motivated and talented people. Projects do miss out on good people because no one's willing to teach them, but there's many more people who will gladly suck up developer time and never give anything back and you have to draw the line somewhere or you'll never get anything done. I think fundamentally, where we disagree is that what you consider signs of dysfunction are really signs that the system is functioning as intended.

Finally I don't see any use in pointing out that these projects aren't 100% open-source with the RMS seal of approval. In fact I think it's pretty inane. To some people open-source is this high-minded ideology for Android, Chrome and most other open-source projects open-source is technique; we use it to solve real problems when it's the right tool for the job. Do you really not believe that Android and Chrome are effective applications of this technique? I may be dating myself, although I do know that not literally every language is open-source these days it seems like it's all but true. It wasn't in the dark days but that's a lot of why they were so dark isn't it?

> It's just the there's only very seldom a reward for serving nonprogrammers. And quite often there is a reward for alienating those people so that developers don't have to spend all their time explaining basic principles to them.

This was definitely one of my main points. We just differ on whether that's "system functioning as intended" or if there's room for change. That's something that makes sense to disagree on. I'm describing the state of the system, and sure I made some judgement calls on whether that state was good or bad, but we still agree on the reality.

What you've described as the system functioning as intended are the things you've recognized bring a stability to the system at play; that without these ways of operating, the complex interplay between developer time, motivation to continue, and ability to produce would come to a screeching halt. The simplest solution is just to cut off from the outside world and continue in isolation, all I'm saying is that there are also other solutions that could be considered to keep that stability and make things even more productive. Do I know what they are? No. So I'm largely useless in that respect, but I will at least try to point out that stability is not the same thing as optimal function.

> - Chrome is built on Chromium, which is open source, but Chrome itself is not.

If you've actually tried using Chromium then you realize that this distinction doesn't make much sense. Chrome IS Chromium + Netflix + Flash + updater/Omaha + flashier logo.

> - Android is based on open source technologies, but is, again, not itself open source in many cases.

Android itself is open source (AOSP) and is very much a usable system without Play Services.

> - Many, if not most, programming language implementations are not open source. In fact, you're dating yourself with this claim, as those with more experience remember the dark days of paying for compilers. Even C compilers.

As you said yourself, your claims are out-of-date. AFAIK, the only three remaining language implementations that matter today that are not open source would be Oracle Java (very close to OpenJDK), Apple's LLVM form (naturally very close to real LLVM), and Microsoft's C++ compiler (AFAIK generally considered to be crap).

> As you said yourself, your claims are out-of-date. AFAIK, the only three remaining language implementations that matter today that are not open source would be Oracle Java (very close to OpenJDK), Apple's LLVM form (naturally very close to real LLVM), and Microsoft's C++ compiler (AFAIK generally considered to be crap).

Not a much of experience in the embedded market, high integrity market, medical devices, hardware design, Fintech, HPC or deployments that require certified compilers, right?

That's certainly a difference from much of the open source world, with half the mobile phone market based on Android, for example. The market for certified compilers in the grand scheme is very small in comparison, so it could be argued that in general languages and programming is an area where open source has been wildly successful.

And that makes sense—the tools that developers use being metatools that they can work on and improve, targeted directly at the audience that can work on them—I'd expect nothing less than near complete adoption of such a thing.

> Android itself is open source (AOSP) and is very much a usable system without Play Services.

It's open source by the most limited definition possible. Google throw the source code over the fence occasionally.

A+, then K, Q/kdb are closed source. I wonder in dollars, not users, how much of the market for paid compilers/systems they have at the price per seat they fetch. The fintech community pays dearly for them because they are effective.

I use J, which is not that popular. It was closed, but has been open source for a while now.

> In fact, you're dating yourself with this claim, as those with more experience remember the dark days of paying for compilers. Even C compilers.

And how many bugs (and security issues) have their roots in the limited stack size that those shareware compilers came with?

Yeah, it works for what it is—it's not wholly dysfunctional, obviously, but I was responding to a discussion bringing up several imperfect parts from both a creator and user perspective. I think they're common challenges in open source, and the problems are real, and shouldn't be ignored but rather improved.

Every system has flaws. Some systems are better than others despite their flaws. Yet, I have never met a system that couldn't be improved in some way with careful understanding of its structure, states and flows, and leverage points.

That's a huge problem. Some times we end up shitty solutions to problems because the people who wrote the software do not care to fix its bugs and there's a lack of investment in creating better solutions because the free, open source solutions exist. Just look at the state of version control software.

Other times we end up with a good, expensive commercial product and a free, crappy open source product with a huge gulf in quality and price between. Examples: Photoshop and GIMP, MS Office and OpenOffice.

You're always going to end up with shitty solutions to some problems. Making open-source projects good requires several people to devote their lives to it. Very few projects achieve critical mass and all the other ones languish in obscurity. There's always going to be way more failed projects than successful ones. If you consider their existence a huge problem in open-source then it seems the only fix would be to stop trying. I don't think crappy solutions dissuade people from making better ones, if anything all they do is cause people to think: "These guys obviously got nowhere with this project and I don't see what I'm going to do better." But given the amount of duplication in open-source I don't think people really even think that either. It's just that they attempt to make a better version and fail leaving the world with another shitty project. Or, in rare cases they actually succeed and we do wind up with something great. But we wouldn't ever get there if we didn't make 10 of those "shitty solutions" along the way.

True, gigantic GUI programs such as full Office suites featuring heavy featuritis aren't the best match for volunteer-based development efforts. They just involve too much mind-numbing busywork.

What's your point regarding versin control software?

"you taking it was never their goal"

I'd disagree. That's pretty much the point of making the software open source: so that others can take and use it within the confines of whatever licence the dev decides. The point is to get it out there and into the hands of other devs, not for them to simply look at or dive through but very often to manipulate, improve and use.

In that sense these projects do actually operate the way companies do, but without the depth of support and speed that we would expect if we were actually laying down our cold, hard cash to get the goods.

Maybe with a little help understanding it, more people would be able to contribute more back.

It depends on the forum/group.

For example I've been a more active member on XDA for Cyanogen mod and I did a rude comment; I got my attention immediately called and the maintainer respond the question, same goes for HN.

OTOH... the Linux kernel group it's probably a "little bit" tougher....

This appears to be a somewhat informative page to link to: https://github.com/littlekernel/lk/wiki

I had to find it buried inside the magenta repository somewhere. It's hard to piece together what this project is all about, indeed.

When one OP's piqued curiosity meets HN's hype machine, hilarity / project management philosophy advice ensues. Fun for the whole team!

Whatever piece of media this is a description of, I'll buy 20.

It's a Google project with non-public members, so maybe it has only recently been opened up and before that it was subject to secrecy. https://flutter.io/

I am pretty sure the Fuchsia devs were not planning on being (slightly more) famous today.

That appears to be on purpose.

> Pink + Purple == Fuchsia (a new Operating System)

Pink [1] and Purple [2] were both Apple codenames for operating systems. Probably not a coincidence, but I don't see an obvious connection...

[1] https://en.wikipedia.org/wiki/Taligent#Pink_and_Blue

[2] http://www.phonearena.com/news/Did-you-know-that-the-codenam...

Purple - A system with high performance graphics, low-latency input, and a beautiful UI.

Pink - An incredibly modular system for developers and users.

If you hang out on #fuchsia long enough you will realize that we are all a bunch of OS nerds that have worked on many, many systems in the past (BeOS, ChromeOS, Android, webOS, QNX, DangerOS, iOS, MacOS, ...).

That explains it. Thanks, congratulations on the release, and welcome to HN! :)

Any details on the Pink modular system?

Hosted on https://fuchsia.googlesource.com/ is what looks like an early in development operating system.

Mirrored on Github where it's described as Pink + Purple == Fuchsia (a new Operating System)

The kernel component 'Magenta' reveals it "targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation." [1]

[1] https://github.com/fuchsia-mirror/magenta/blob/master/docs/m...

> It is good alternative to commercial offerings like FreeRTOS [1]

FreeRTOS is GPL with an exception for static linking making it effectively free if you make no modifications. There is, however, an onerous clause prohibiting the publication of comparative benchmarks. [2]

[1] https://fuchsia.googlesource.com/magenta/+/HEAD/docs/mg_and_...

[2] http://www.freertos.org/license.txt

> FreeRTOS is GPL with an exception for static linking making it effectively free if you make no modifications. There is, however, an onerous clause prohibiting the publication of comparative benchmarks. [2]

This is why I don't like the GPLv2 and wish more people would switch to the GPLv3. Section 6 of the GPLv2 implies that you can remove the restrictions you mentioned from the license, but section 7 and 10 of the GPLv3 make it clear that such restrictions would not be binding and could be removed by recipients of the software.

Also, "effectively free if you make no changes" doesn't make sense -- free software requires you to have the freedom to make changes to the software.

But as far as I can see, clause 2 is very broad (what is a "competitive purpose"). I consider that to be an "additional restriction" under section 6 and as per the license terms they've given us, I'm allowed to ignore that restriction. Otherwise they've modified the license and must not call it the GPL. In addition, if that term is actually binding it would not classify in my book as free software.

> Also, "effectively free if you make no changes" doesn't make sense -- free software requires you to have the freedom to make changes to the software.

The GPL places some conditions on distribution; most notably, anyone distributing binaries is required to also make the source available. In the "standard" GPL, this applies even if the distributed binaries are compiled directly from the upstream source -- this is sometimes used as a "gotcha" to harass companies that use GPLed code (e.g, in embedded devices), but which fail to make every single piece of source code available for download. The exception granted by FreeRTOS makes perfect sense in this light.

> In the "standard" GPL

This is only true for GPLv2. GPLv3 fixed this problem, as well as many other real problems (though I don't agree that it is as big of a problem as you claim).

> The exception granted by FreeRTOS makes perfect sense in this light.

Which exception is that? I read it as "this is kinda like the LGPL, but you also can't be 'competitive'". Also, none of this has anything to do with the statement "effectively free if you make no changes". Requiring you to provide the source does not make the software non-free.

There doesn't seem to be much point to that benchmark clause.

If it's GPL the source is effectively mine to do what I like.

I could make a trivial change to the source (or not perhaps), and call the result a FreeRTOS derivative and publish my derivative's benchmarks.

No, you couldn't because it's not GPL. It's a license that is nearly identical to the GPL, but slightly different.

I think that added restriction actually makes it GPL incompatible, and disqualifies it from being an actual open source license.

> No, you couldn't because it's not GPL. It's a license that is nearly identical to the GPL, but slightly different.

Then they actually are not allowed to call it the "GNU General Public License" (or in fact, they are not allowed to modify the license terms). It's the first condition in the license text of the GPL, I'm surprised their lawyers didn't notice that little chestnut.

You clearly have a better understanding of this issue than I do.

My reading was that they were calling theirs the "FreeRTOS open source license", and it just referenced the GPL.

Given that their exception explicitly contains the quote "Linking FreeRTOS with other modules is making a combined work based on FreeRTOS. Thus, the terms and conditions of the GNU General Public License V2 cover the whole combination.", I feel like they've not got much leg to stand on with that claim.

Hmmm. I'm not sure what the FSF's opinion on it would be. Since they don't call it the GPL (I must've skipped over that part) then they might be in the clear -- though they're still modifying the license text by prepending restrictions to it that make the rest of the license text contradictory.

I'm very glad to have found this discussion, as I have concerns (as expressed above) with FreeRTOS for some time. I would be really interested what FSF would say too. cyphar, emmelaich, slavik81, et al. - would anyone of you be interested enough in this case to actually try to follow with FSF/related parties? Please reply here if you're interested, or feel free to get in touch at pfalcon-at-users.sourceforge.net.

I emailed RMS. His response was that he will investigate it. If it becomes a thing there'll probably be a post on HN describing what went down.

Thanks for response cyphar, and thanks for taking an action. And glad to hear RMS reads email and even replies, I'd think one would need to chase FSF's legal advisers to bring up this matter.

Email rms@gnu.org. That's literally all there is to it. If he thinks there's a valid case then he'll forward it to the right FSF people.

I think that added restriction actually makes it GPL incompatible, and disqualifies it from being an actual open source license.

I can't see any way that this license could be considered Open Source by the Open Source Definition[1], as that benchmarking clause is almost certainly going to trip over the "no field of use restrictions" bit.

[1]: https://opensource.org/osd-annotated

I guess it depends on how you interpret this clause:

> Linking FreeRTOS with other modules is making a combined work based on FreeRTOS. Thus, the terms and conditions of the GNU General Public License V2 cover the whole combination.

Does this mean the combination (which could be a trivial combination) can be licensed under the pure GPLv2, or is it just an explanation of the consequences of "combined work", and "the terms and conditions of the GNU General Public License V2" is actually intended to mean the modified version thereof?

That's a good point. I would think they meant with the exception, because their first sentence is very clear:

> Any FreeRTOS source code, whether modified or in it's original release form, or whether in whole or in part, can only be distributed by you under the terms of the GNU General Public License plus this exception.

The "thus" in your quote also seems to imply it's a clarification of the consequences of previous rules, not a new rule itself. But, IANAL.

[sorry for cross-post]

A license covers copying and distribution. You can reject the FreeRTOS license and publish benchmarks. You will lose your ability to distribute FreeRTOS under their variant of the GPL.

They could alternatively add a clause that forces you to extract an agreement from anyone you distribute the source code to. That would require at least some sort of click through license agreement to be binding.

The only thing that really bothers me with this new OS is that the kernel is no longer GPL. With a GPL kernel like Linux we had a chance of getting the kernel source code ( some companies don't care if it's GPL anyway ) for our devices but if it's Apache or BSD good luck with that.

I suspect that's intentional. Google seems to prefer Apache-style licensing, as that's what they used with Android. By not relying on the Linux kernel, they get to avoid the whole copyleft kerfuffle.

Written in C. What a shame.

edit: Thank you to all of the repliers, I had no idea that most OSes were written in C. Er, actually, I'm more than well aware of that fact and I'm familiar with the number of CVEs that have occurred over the years because of the lack of memory safety involved in that C code.

Sorry, I simply don't get the appeal of writing more operating systems and network-exposed code that isn't written in a safer language. Say like Rust; see Redox.

I love Rust immensely, and it is perhaps my favorite programming language as of late.

However.

This is a microkernel. There is very, very little code inside a microkernel which, if written in Rust, would not end up inside an unsafe block. You are building the safe abstractions here; that code is inherently unsafe.

You could use Rust as a C replacement, but it is a worse C than C, and unsafe rust contains more perils (i.e. UB) than C.

The Magenta kernel is maybe a bit more of a minikernel (97% of drivers and services live in userspace, but the syscall surface provides a wider variety of primitives than just send/recv/exit that a hardcore microkernel design might embrace).

It inherits from LK, which was written in C, but the new surfaces in the Magenta kernel are written in C++ (a restrained, limited C++, intended to take advantage of nice things C++ brings without getting us in too much trouble in the controlled kernel environment).

The core Magenta userspace drivers and services are mostly C at the moment, some will shift to C++ over time, and provided they use the same RPC protocols there's nothing preventing one from building such components in other languages once those other languages are building suitable binaries for Magenta.

Redox is microkernelish, and used to have a lot of unsafe, but has cut it down significantly. You'd be surprised :)

That said, this is pretty much an open research question at this point, so you're right to be skeptical.

(I would also argue that unsafe Rust has more _unspecified_ behavior than C, but not more undefined behavior, but until we get those semantics truly nailed down, can't say for sure. See above "open research question" comment)

The LK inner construct is ~15KB. I don't think you could use Rust's safety features and get that size for the LK portion. Maybe the Magenta portion of it though.

"Magenta has a capability-based security model. In LK all code is trusted."

Pony lang is a PL using capability-based concepts too.

  > I don't think you could use Rust's safety features and get that size for the LK portion.

What do you mean? Rust's safety features are mostly compile-time; it shouldn't have implications for binary size. https://github.com/helena-project/tock is an RTOS that runs on an Atmel SAM4L Cortex-M4, and is about ~30kb in size, in my understanding. But that's for the whole OS...

You're right about binary size. I shouldn't have worded it that way.

The point I attempted to make is that when you go small, and pare away what you used to create it, you could have used C and verified it with a certifier/prover. How does Rust address this goal? Truly curious, since I just started learning Rust. I program in C, not C++.

How does your example of the RTOS on the Cortex-M4 at ~30KB compare in complexity to LK at ~15KB in terms of what they deliver in that package size?

I don't know enough about LK to make the comparison.

  > How does Rust address this goal?

Currently? Not as well. There's no total proof framework for Rust yet, it's too early. In a few years? The same way, but with more "proven" by default, without the extra tooling. Tool maturity is certainly one of the areas where C has a leg-up on Rust, by virtues of being decades older.

I took a quick peek at the redox source code and found kernel mode audio and network drivers. This is not a microkernel.

As for UB: Maybe it has less, but that which exists (e.g. noalias on mut refs) is very dangerous.

Yes, they're in the middle of some refactoring stuff; they had to put some things back in the kernel. Should be back out when they're done.

No more dangerous than existing UB in C, just that we're not used to it. And it's easy to disable for your types.

Like Steve said, the exact nature of this UB isn't completely specified yet (as in, when it actually is UB), so it is dangerous right now, but that's just temporary.

You could probably write one in forth though ;p, what's good enough for EFI is good enough for the kernel. (You'd end up with a lot of inline assembly probably though, but hey that's less complicated than C++.)

Did you mean OFW rather than EFI?

Why is this voted down? To build a new OS from scratch takes a huge effort. If you're going to do it then you should really try to advance the state of the art in big ways. An obvious way to do that is to use memory safe / managed code as deep as possible into the stack (and then you can do things like eliminate the notion of a process entirely). JNode is an example of the latter. Redox has a less radical architecture but is still on the right path.

When Microsoft did their own new OS research project, Midori, that's the path they walked.

> To build a new OS from scratch takes a huge effort. If you're going to do it then you should really try to advance the state of the art in big ways

I do not get the impression that Fuchsia is a "research project", and it's purpose is not to advance the state of the art.

> When Microsoft did their own new OS research project, Midori, that's the path they walked.

How did it work out for them?

Midori was really interesting. I don't know of another that removed context switching.

> Midori was really interesting

No doubt, and so are some art-house movies I've watched - they usually leave me thinking (or flummoxed).

There is a place for art-house movies and a place for more commercial fare (e.g. blockbusters) - it is important not to confuse the two.Some gifted auteurs manage to blend the two, but IMO,it is wrong for anyone to say "if you're taking the time to make a movie, make it intellectual"

Actually, C is a perfect tool for writing portable operating systems.

Let's ignore that your operating system is probably written in c.

Its a new RTOS...

Basically that means more than just cell phones as you have embedded systems in vehicles that use RTOS, watches, medical devices, etc.

Its the operating system that runs the baseband cpu/chip other wise known as the BaseBandProcessor.

Is it? I'm not so sure. Certainly the presence of LittleKernel, a lightweight real-time kernel suggests it's an RTOS but that kernel is wrapped by something called 'Magenta' which says "Magenta targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation." [1]

[1] https://github.com/fuchsia-mirror/magenta/blob/master/docs/m...

Does anyone have an idea of what kind of technical problems this is trying to solve?

It sounds like it's trying to be a RTOS for phones and modern hardware. But I know there has to be more to it than that.

There's a distinct lack of information in their repos README's.

Actually this compiles pretty easy. It however only runs on the provided qemu. And actually without adding some user space tools you only can use kilo which is akward to handle under a MacOS terminal :( But it's really really easy to setup and even integrate userspace programs. kind of extremly simple to do useful stuff on it.

It runs on some Broadwell and Skylake hardware. Docs are coming for http://www.acer.com/ac/en/US/content/series/switchalpha12.

https://fuchsia.googlesource.com/magenta/+/master/docs/targe...

Has some notes on setting up the Acer UEFI BIOS to boot the system and creating USB flash boot media.

Hoping to get some more general "HOWTO Run On Hardware" docs up in the near future, including netbooting w/ NUC and other useful things.

actually I don't have had a Broadwell / Skylake which I can play with. I have a MacBook Pro 2013 Late (Haswell). But I wouldn't try out something on my production laptop anyway ;)

I also have a two Xeon Sandy Bridges lying around, but I didn't tried em, but I guess even with some changes it would run on it. I just didn't had time, after it compiled it already was 2 o Clock at night.

It will likely boot on earlier Intel platforms, though some tinkering may be necessary. The focus has been on Qemu and on some modern UEFI based systems (and the latter booting with gigaboot20x6, also part of the Fuchsia repos). Debugging early boot / bringup issues is massively easier if the machine has a standard serial port.

What about AMD hardware? Will you support all x86_64?

There's no intention not to. Might need a little work to play nice with AMD, but probably not a lot.

Put Fuchsia and Android green on a color wheel. I dare you.

Heh. As a young kid, "pink and green" was how I'd describe how I felt to my parents when I was nauseous.

(they still 'bring that up' 40+ yrs later)

D2639C

http://meyerweb.com/eric/tools/color-blend/#A4C639:FF00FF:1:...

You get napolitean ice cream?

Apache2 and MIT. Sounds interesting

Would someone most kindly provide a VM?

It's fairly easy to build one on Mac and Linux.

Not sure why I'm being down voted here.

Its nontrivial to build it. I see the developers saying it's got a beautiful UX, and I'd love to play around with it, but Not everyone can devote as much time.

>> It seems like the intention is to use Flutter [1] as the UI layer.

Flutter already ready for use? If Flutter is not ready for use then how it can be used?

There are people using it already. Inside and outside of Google. http://flutter.io/

No, flutter is still in tech preview mode. There are working example demos in the codebase but that's it. I have no idea on their release schedule but my guess is that Q1 of 2017 can be a target for a beta release.

Probably you mixed Flutter with Dart.

Nope. I also don't think that our statements are at odds with each other. Flutter isn't done yet but that isn't preventing a lot of folks from using it for real work.

I'm (not) eagerly awaiting the day when some IoT thing "Fucks ya".

No screenshots?

Not terribly exciting, but here's a shot of virtual console 0 with the tail end of the boot log on an Acer Switch Alpha 12: http://i.imgur.com/LqDRoyG.jpg

I'm working on a Twitter client that only runs on this OS. Wait a sec... Oh, I see. Time machine was NOT set to 2010.

Working on a Pokemon GO client that only runs on this OS.

Twit Plays Pokemon (GO)? :)

(no slur intended)

Fuchsia = deep mind + Ai

(Getting to there Ultimate goal) we can also expect updated Google glass too

Well, if it takes off, it'll have the side-effect of getting more people to be able to spell 'Fuchsia' correctly...

Easy to remember if you know that fuchsia is named after a German botanist by the name of Leonhart Fuchs.

(Lionheart Fox, how badass is that name?)

It's a hell of a lot classier than the mnemonic I currently use: "trying to spell fuchsia really 'fucks ya'"...

Thanks!

or if you're German!

('hart' translates to 'tough' or 'brave' though, not heart. The German equivalent would be 'Herz')

I consider myself fairly tech savvy, and have done a little programming here and there.

But from the linked page I couldn't figure out where any of the documentation of this "thing" is, nor how to install it, nor what platforms it's for.

Was it just me?

Instructions for getting and building the code are here:

https://fuchsia.googlesource.com/manifest/+/master/README.md

It runs on arm, arm64, and x64.

I tried the Ubuntu instructions on a Debian box but it errors out with:

fuchsia/.jiri_root/tmp/src/v.io/x/lib/cmdline/cmdline.go:236: undefined: os.Unsetenv

I suspect it is because the version of go in the repo is too old, I tried manually installing the newer version but still no joy

Well, it may be difficult to fathom what this project is all about but, at least, I've learned one thing. I've been spelling FUCHSIA wrong all these years. I always thought it was FUSCHIA.

[As I have several growing in the garden, this is an important development]

That's basically the non-endorsement clause from the BSD license. Nothing unusual about that.

The license is not unusual. What is unusual is that Google appears to be writing a new mobile operating system. Is this someone's 20% time project? What is the use case for Google?

Google needs an OS that works better for realtime applications like VR/AR and robotics. Note how they spelled out how it is designed for a non-trivial amount of RAM. This is in contrast to the tiny hardware that a realtime OS would typically run on.

Personally, I'm hoping that this is a cleaner foundation for Android that we can all use to build more advanced AR and robotics applications.

I'd like to see another big player in the os market. Something really new, not based on UNIX (don't get me wrong people...).

Just for the sake of diversity. And maybe the illusory desire of a clean slate.

I have not looked in to this and don't have expertise, but my first split second thought was "how are they going to keep up with security exploits?" Sad when my first thought it that someone's going try to steal from people using it.

Reply on news.ycombinator.com