It seems like the intention is to use Flutter  as the UI layer. Flutter uses the Dart language, so there's a Dart environment included in Fuchsia too .
For rendering, Fuchsia includes a project called Escher  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.
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.
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.
This is Google's next Android, with a low latency rendering pipeline for the next generation of mobile devices.
Hey, I'll bite. Let's see.
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.
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.
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.
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).
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.
Wikipedia 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 ...
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.
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:
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)
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.
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.
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.
"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."
[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
(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!
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.
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).
I came here through the RSS feed, and likely would have ignored it without the "Google" mention.
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.
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.
- 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.
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.
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?
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.
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).
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?
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.
It's open source by the most limited definition possible. Google throw the source code over the fence occasionally.
I use J, which is not that popular. It was closed, but has been open source for a while now.
And how many bugs (and security issues) have their roots in the limited stack size that those shareware compilers came with?
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.
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.
What's your point regarding versin control software?
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.
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....
I had to find it buried inside the magenta repository somewhere. It's hard to piece together what this project is all about, indeed.
Pink  and Purple  were both Apple codenames for operating systems. Probably not a coincidence, but I don't see an obvious connection...
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, ...).
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." 
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. 
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.
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.
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.
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.
I think that added restriction actually makes it GPL incompatible, and disqualifies it from being an actual open source license.
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.
My reading was that they were calling theirs the "FreeRTOS open source license", and it just referenced the GPL.
I can't see any way that this license could be considered Open Source by the Open Source Definition, as that benchmarking clause is almost certainly going to trip over the "no field of use restrictions" bit.
> 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?
> 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]
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.
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.
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.
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.
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)
"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.
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?
> How does Rust address this goal?
As for UB: Maybe it has less, but that which exists (e.g. noalias on mut refs) is very dangerous.
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.
When Microsoft did their own new OS research project, Midori, that's the path they walked.
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?
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"
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.
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.
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.
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.
(they still 'bring that up' 40+ yrs later)
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.
Flutter already ready for use?
If Flutter is not ready for use then how it can be used?
Working on a Pokemon GO client that only runs on this OS.
(no slur intended)
(Getting to there Ultimate goal) we can also expect updated Google glass too
(Lionheart Fox, how badass is that name?)
('hart' translates to 'tough' or 'brave' though, not heart. The German equivalent would be 'Herz')
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?
It runs on arm, arm64, and x64.
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
[As I have several growing in the garden, this is an important development]
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.
Just for the sake of diversity. And maybe the illusory desire of a clean slate.