Linked by Thom Holwerda on Thu 11th Aug 2016 22:49 UTC
Google

Update: interesting summary of the repository - "So, the stack seems to be: Dart is the language for GUI apps, Flutter provides the widgets, and Escher renders the layers."


Something intriguing: a new open source operating system from Google, Fuchsia, has found its way to Google's repositories. There's pretty much no information anywhere about this, and maybe I'm making way too much of this, but until we know more - anybody care to speculate?

There's a Fuchsia file that just reads "Pink + Purple == Fuchsia (a new Operating System)", so that's not much help. There's documentation on the kernel, Magenta, which may be of more use - it reads, among other things, "Magenta targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation." There's probably a lot more documentation in the repository, but I don't have the proper background to infer too much from what's going on.

Another very, very intriguing piece of information: it turns out several big names from the operating system industry (is that even a thing?) are involved - people who worked on NewOS, BeOS, Danger, iOS, and Palm's webOS, such as Travis Geiselbrecht and Brian Swetland.

This could be "just" a research project, or something more. Very interesting.

Order by: Score:
Pink == Taligent?
by rafial on Thu 11th Aug 2016 23:01 UTC
rafial
Member since:
2007-12-04

Pink was the original codename for the work within Apple that became Taligent. I wonder what is Purple?

Reply Score: 2

RE: Pink == Taligent?
by Flatland_Spider on Fri 12th Aug 2016 02:21 UTC in reply to "Pink == Taligent?"
Flatland_Spider Member since:
2006-09-01

There is the prpl Foundation (https://prpl.works/) which focuses on Linux on IoT stuff and MIPS. Mainly OpenWRT and LEDE.

I'd like to think this is the successor to Android and ChromeOS that gets rid of Java and Chrome runtime environments in favor of native code. It looks to use LLVM prominently, so ditching those two for some sort of LLVM JIT would be a good move.

Reply Score: 2

RE: Pink == Taligent?
by Bill Shooter of Bul on Fri 12th Aug 2016 17:44 UTC in reply to "Pink == Taligent?"
Bill Shooter of Bul Member since:
2006-07-14

Purple == iphone project.

http://www.wired.com/2012/08/forstall-talks-ingenuity-ui/

So pink desktop os was the future of the desktop. Purple was the future of mobile.

pink + purple = future of both.

Reply Score: 3

Good choice of name
by bannor99 on Fri 12th Aug 2016 02:17 UTC
bannor99
Member since:
2005-09-15

because it ever becomes the fractured mess that is Android, the name can be easily re-interpreted as "f#cks-ya"

Reply Score: 8

RE: Good choice of name
by Flatland_Spider on Fri 12th Aug 2016 02:36 UTC in reply to "Good choice of name"
Flatland_Spider Member since:
2006-09-01

I suspect this is the answer to the Android mess, or at least an experiment in solving it by Google engineers.

The kernel looks to be released under the MIT license, so that's one less problem for hardware manufacturers.

Reply Score: 2

RE[2]: Good choice of name
by Spiron on Fri 12th Aug 2016 06:45 UTC in reply to "RE: Good choice of name"
Spiron Member since:
2011-03-08

And how exactly do you reckon that it would actually solve the mess, which tends to be a distrubution problem more than a technical one. Assuming google replaced the Linux parts of Android with whatever Fuchsia does turn out to be, how would it's technical prowress solve the problem that the device makers take ages to adapt their custom skins to the new Android version, only ship that update to a few devices, and in more than a few places the update then has to get greenlit by the carrier. How would Fuchsia solve any of that?

Reply Score: 9

RE[3]: Good choice of name
by unclefester on Fri 12th Aug 2016 09:42 UTC in reply to "RE[2]: Good choice of name"
unclefester Member since:
2007-01-13

And how exactly do you reckon that it would actually solve the mess, which tends to be a distrubution problem more than a technical one. Assuming google replaced the Linux parts of Android with whatever Fuchsia does turn out to be, how would it's technical prowress solve the problem that the device makers take ages to adapt their custom skins to the new Android version, only ship that update to a few devices, and in more than a few places the update then has to get greenlit by the carrier. How would Fuchsia solve any of that?



I've got a cheap Alcatel phone. It has vanilla Android 5.1, a MTK chipset and supports all Australian (and most international) 3G and 4G bands. It appears to have solved all the problems you mention.

Reply Score: 1

RE[4]: Good choice of name
by winter skies on Fri 12th Aug 2016 09:52 UTC in reply to "RE[3]: Good choice of name"
winter skies Member since:
2009-08-21

On the contrary, they are obviously all problems that cannot be solved by a device.

Reply Score: 3

RE[4]: Good choice of name
by Spiron on Fri 12th Aug 2016 10:05 UTC in reply to "RE[3]: Good choice of name"
Spiron Member since:
2011-03-08

My phone running Cyanogenmod gets around the problems too, but the undeniable truth is that most phones don't run pure google like the nexus, or vanilla on a device like yours that keeps up to date, or a custom rom like mine. They run a system which is often held to ransom by the OEMs need to create their own version of Android with their own features, and often on carriers that must approve updates. Creating a new underlying base OS wouldn't solve that issue, nor would it solve hardware manufacturers issuing better drivers and keeping them up to date.

Reply Score: 3

RE[5]: Good choice of name
by unclefester on Fri 12th Aug 2016 10:45 UTC in reply to "RE[4]: Good choice of name"
unclefester Member since:
2007-01-13

My phone running Cyanogenmod gets around the problems too, but the undeniable truth is that most phones don't run pure google like the nexus, or vanilla on a device like yours that keeps up to date, or a custom rom like mine. They run a system which is often held to ransom by the OEMs need to create their own version of Android with their own features, and often on carriers that must approve updates. Creating a new underlying base OS wouldn't solve that issue, nor would it solve hardware manufacturers issuing better drivers and keeping them up to date.


Apple and MS provide OTA updates and banned carriers from making UI modifications to their phones. There is nothing to stop Google doing the same with a new OS.

Edited 2016-08-12 10:46 UTC

Reply Score: 3

Who knows what this is.
by Flatland_Spider on Fri 12th Aug 2016 02:32 UTC
Flatland_Spider
Member since:
2006-09-01

Google has a tendency to produce a product then abandon in, and then produce another product that does the same thing. Or they have multiple products that do the same thing active at the same time.

Optimistically, this is a BSD licensed hybrid kernel that has pluggable drivers (Windows, MacOS style) that side steps a lot of the problems the hardware manufacturers, who hold onto drivers like it's gold, have with Linux.

Using Linux provides a lot of hardware, but it does set certain design paradigms. Especially with graphics and sound. A clean sheet consumer OS would look a little bit different the Linux.

Pessimistically, this is an interesting distraction for some very talented engineers they have on the roster. Nothing more, and this will end up being another dead code repo that people pick over.

Reply Score: 6

Ubuntu
by mr_pinsky on Fri 12th Aug 2016 05:56 UTC
mr_pinsky
Member since:
2010-09-06

Purple could be for Ubuntu, as their default background has been purple for a while, and Google is known to use Ubuntu internally.

Reply Score: 3

Promising recipe
by ThomasFuhringer on Fri 12th Aug 2016 08:28 UTC
ThomasFuhringer
Member since:
2007-01-25

I think we have been there, when "several big names from the operating system industry" come together and draft the next big thing on paper...

Reply Score: 2

Let the guessing begin
by avgalen on Fri 12th Aug 2016 08:46 UTC
avgalen
Member since:
2010-09-23

* This comes from Google that normally runs extremely big distributed server loads, but also has tiny-mobile-OSses like Android and ChromeOS
* We know they are trying to merge Android and ChromeOS into 1 OS, but I have never heard these colors in reference to Android/ChromeOS
* Reading "Magenta targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation."
* Reading your list of people and OS-ses they have worked on it again points to mobile

My guess, this IS about merging Android and ChromeOS and makes it possible to run Google Now like computations locally on mobile devices

Reply Score: 2

v Comment by ansidotsys
by ansidotsys on Fri 12th Aug 2016 11:36 UTC
RE: Comment by ansidotsys
by Thom_Holwerda on Fri 12th Aug 2016 12:05 UTC in reply to "Comment by ansidotsys"
Thom_Holwerda Member since:
2005-06-29

If not, why wasn't the original source quoted and linked?


?

The article here is full of links to where information comes from. Fuchsia itself was pointed out to me on Twitter (https://twitter.com/dictvm/status/763865235044302848).

Reply Score: 2

Wasted?
by fithisux on Fri 12th Aug 2016 12:52 UTC
fithisux
Member since:
2006-01-22

IMHO, it would be more appropriate if they could have started a research project that help device makers provide FOSS drivers for Android and Linux while protecting their IP and keep them in Android code base.

Reply Score: 3

NewOS
by Vanders on Fri 12th Aug 2016 14:08 UTC
Vanders
Member since:
2005-07-06

Browsing the source for Magenta looked quite familiar; it has Travis Geiselbrecht's copyright on the top. It appears to be derived from NewOS, which means it shares a bunch of features with BeOS (and, dare I say it, AtheOS & Syllable) such as message ports & kernel threads.

This is a good thing and maybe we'll finally see someone develop a modern kernel lightweight kernel that's more suited to the sorts of responsive interface-heavy workloads we're using them for these days.

Reply Score: 6

RE: NewOS
by BlueofRainbow on Fri 12th Aug 2016 21:43 UTC in reply to "NewOS"
BlueofRainbow Member since:
2009-01-06

There may be technical merits starting afresh using the NewOS hybrid kernel. This may also bring some indirect development assistance to Haiku - which is also using the NewOS kernel.

It is unclear from the little amount of information available on this project at this time what is the ultimate goal being pursued. While Google has the cash flow to experiment with kernel implementation models and APIs, there has to be a business reason for the project to be internally sponsored.

Reply Score: 3

RE: NewOS
by jgfenix on Sat 13th Aug 2016 19:07 UTC in reply to "NewOS"
jgfenix Member since:
2006-05-25

Is NewOS good. I would prefer they used a L4 variant,or even better, seL4.

Reply Score: 2

RE: NewOS
by moochris on Sun 14th Aug 2016 10:18 UTC in reply to "NewOS"
moochris Member since:
2009-03-20

Not only that, check out IRC logs for #Haiku today... Travis Geiselbrecht is proposing to use BeFS as the main FS.

https://echelog.com/logs/browse/haiku/1471125600

Edited 2016-08-14 10:22 UTC

Reply Score: 2

New Amiga finally coming :-)
by -pekr- on Fri 12th Aug 2016 18:37 UTC
-pekr-
Member since:
2006-03-28

With all those colors, it seems like a next gen AmigaOS badge :-)

Reply Score: 3

Predictions
by Verenkeitin on Fri 12th Aug 2016 19:28 UTC
Verenkeitin
Member since:
2007-07-01

My crystal ball shows javascript. Javascript all the way with a bastardized version of html and css (AMP). It'll have a NoSQL database thing and use files only through cloud storage. The API will be a convoluted cluster f*** and redesigned weekly.

Reply Score: 2

RE: Predictions
by satai on Sat 13th Aug 2016 06:38 UTC in reply to "Predictions"
satai Member since:
2005-07-30

Wrong. The internals are C (not a good choice IMO), UI layer is Dart.

Reply Score: 2

RE[2]: Predictions
by Vanders on Sat 13th Aug 2016 23:29 UTC in reply to "RE: Predictions"
Vanders Member since:
2005-07-06

Wrong. The internals are C

The kernel is C & C++. Only the most lowest level parts are in C, and they're in C because nobody has yet come up with a better language for writing a kernel.

Reply Score: 2

RE[3]: Predictions
by Alfman on Sun 14th Aug 2016 04:59 UTC in reply to "RE[2]: Predictions"
Alfman Member since:
2011-01-28

Vanders,

The kernel is C & C++. Only the most lowest level parts are in C, and they're in C because nobody has yet come up with a better language for writing a kernel.


IMHO we should not conflate popularity with merit.

Developers often choose c/c++ because it is the path of least resistance due to network effects, rather than because it has the most merit. All else being equal, any static language could be a candidate and here are ones I think would be good:

ADA has lots of merit for building robust code and has been used for kernels (RTEMS, ASOS). Ada is niche, but not so obscure that it would be impractical.
http://www.adacore.com/uploads_gems/Ada_Safe_and_Secure_Booklet.pdf


The NimRod language has an interesting approach, it takes advantage of all the work that's gone into optimizing and porting C compilers by trans-coding it's output into C. The language offers powerful notation that I often feel deprived of in C with many zero-overhead constructs and direct access to hardware.
http://nim-lang.org/
It would be a good fit for kernel development.


Rustlang would also be an excellent choice due to it's zero-overhead compile-time code validation.
https://www.rust-lang.org/en-US/


DLang's is a major housecleaning of C/C++, they support the same use cases but fix all the things about C/C++ that make them frustrating. As such I think it would be a good choice.
http://dlang.org/overview.html


Ultimately I don't think there's anything unique about C among static languages that makes it especially suitable for kernel development over other languages. But the fact is operating systems are heavily invested in C/C++, and switching has enormous costs to re-write file systems/drivers/everything.

If you disagree I'd like to hear the reasons.

Reply Score: 2

RE[4]: Predictions
by ssokolow on Sun 14th Aug 2016 09:30 UTC in reply to "RE[3]: Predictions"
ssokolow Member since:
2010-01-21

I'm not sure about Nim, but I know D suffers from having its standard library depend on the optional garbage collection being enabled.

I recently saw a post on /r/rust by someone who had left D because they got fed up with every GC-less D project having its own home-grown/reinvented data structures and helper functions that you had to learn.

To the best of my knowledge, Rust is just as suitable as C.

As for Ada, the base language doesn't have as much compile-time verification as Rust, nor does it have the excited and growing community of potential employees, so you'd probably want to use the SPARK dialect for high-reliability systems programming.

https://en.wikipedia.org/wiki/SPARK_(programming_language)

However, at that point, you'll probably want to consider just buying your programmers copies of the MISRA C and/or MISRA C++ specs and verifiers to play to their existing strengths.

https://en.wikipedia.org/wiki/MISRA_C

MISRA C and C++ are the auto industry's restricted C and C++ dialects for reliable systems. Whenever you read articles like "Toyota's killer firmware: Bad design and its consequences", you're pretty much guaranteed to read that the code violated MISRA C six ways from sunday.

(Though, in that case, there were many other cut corners, like using a slightly cheaper alternative to EDAC (Error Detecting And Correcting RAM) and solder joints that produced tin whiskers.)

In case you're curious:
http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmwa...

Edited 2016-08-14 09:34 UTC

Reply Score: 2

RE[5]: Predictions
by Alfman on Sun 14th Aug 2016 15:57 UTC in reply to "RE[4]: Predictions"
Alfman Member since:
2011-01-28

I recently saw a post on /r/rust by someone who had left D because they got fed up with every GC-less D project having its own home-grown/reinvented data structures and helper functions that you had to learn.


I can see that being an issue, although to be fair the GC is optional when not using libraries that depend on it and kernel development generally isn't done with standard libraries. Consider that even in a C++ kernel, the standard library wouldn't be available.

I don't know how many features this actually breaks in D, but I did find this, so I guess it might get better in the future:
http://dlang.org/spec/garbage.html
"There is currently work in progress to make the runtime library free of GC heap allocations, to allow its use in scenarios where the use of GC infrastructure is not possible."

As for Ada, the base language doesn't have as much compile-time verification as Rust, nor does it have the excited and growing community of potential employees, so you'd probably want to use the SPARK dialect for high-reliability systems programming.


Yea Rust is in a league of it's own. I'm not sure if Spark is compatible with the free Ada compilers? I'm wary of using commercial feature for hobby projects. A gripe I have is when they don't even list the price: "if you have to ask, you can't afford it".
http://www.adacore.com/sparkpro/




Interesting to read. They mention the source code was very buggy. They don't specify to what extent these are caused by unsafe languages though.


I have a question about one of the claims:
Mirroring (where key data is written to redundant variables) was not always done. This gains extra significance in light of ...

...

Two key items were not mirrored: The RTOS' critical internal data structures; and—the most important bytes of all, the final result of all this firmware—the TargetThrottleAngle global variable.


I have no idea why the author let the first sentence trail off, I'm curious what is supposed to go there? The following paragraph talks about stack overflow, which is a problem but has no obvious relation to mirroring. Also, what is the technical merit with mirroring variables in software? Either the code is correct, in which case mirroring adds complexity and brings no benefit, or the code is incorrect, in which case I don't know what mirroring is supposed to help with? Can anyone explain this?

Edited 2016-08-14 16:00 UTC

Reply Score: 2

RE[6]: Predictions
by ssokolow on Sun 14th Aug 2016 19:55 UTC in reply to "RE[5]: Predictions"
ssokolow Member since:
2010-01-21

Yea Rust is in a league of it's own. I'm not sure if Spark is compatible with the free Ada compilers? I'm wary of using commercial feature for hobby projects. A gripe I have is when they don't even list the price: "if you have to ask, you can't afford it".


The AdaCore SPARK compiler is under a multi-licensing scheme similar to "GPL but not LGPL"-era Qt:

http://libre.adacore.com/comparisonchart/
http://libre.adacore.com/download/

Reply Score: 2

RE[4]: Predictions
by Vanders on Sun 14th Aug 2016 10:08 UTC in reply to "RE[3]: Predictions"
Vanders Member since:
2005-07-06

I think ssokolow above got most of the reasons why your suggestions don't really work. To add to that, you have to find developers who know those languages, and a of hardware relies on C DDKs/SDKs that you're either going to have to re-write or wrap. If you wrap it it's still C and you've got very little advantage over just using the C directly.

C didn't become popular as a systems programming language by accident; it's popular because it offers a sensible balance between usability, ease of development & power that systems programmers want.

Rust may turn out to be a suitable replacement but it's far too earlier to tell, and if Fuchsia does turn out to be a real project then I don't see Google betting their fortunes on an immature language like Rust; at least not on an immature language they don't control.

Reply Score: 2

RE[5]: Predictions
by Alfman on Sun 14th Aug 2016 17:03 UTC in reply to "RE[4]: Predictions"
Alfman Member since:
2011-01-28

Vanders,

I think ssokolow above got most of the reasons why your suggestions don't really work. To add to that, you have to find developers who know those languages, and a of hardware relies on C DDKs/SDKs that you're either going to have to re-write or wrap. If you wrap it it's still C and you've got very little advantage over just using the C directly.


That's weird because I don't have much disagreement with ssokolow. I agree with your next point though, many developers use C because it's what everyone uses. This is exactly what I meant by "we should not conflate popularity with merit."


C didn't become popular as a systems programming language by accident; it's popular because it offers a sensible balance between usability, ease of development & power that systems programmers want.


Sure C was an obvious choice back when Unix developers wrote C to replace assembly. Much of C's popularity today is due to network effects rather than anything intrinsically unique to it. Some languages aren't appropriate for that use case, but the truth is that many are.

Rust may turn out to be a suitable replacement but it's far too earlier to tell, and if Fuchsia does turn out to be a real project then I don't see Google betting their fortunes on an immature language like Rust; at least not on an immature language they don't control.


It's already being used to write operating system code:
https://www.redox-os.org/
Operating systems have their own network effects too, being good doesn't necessarily equate to strong market share.

Reply Score: 2

RE[6]: Predictions
by ssokolow on Sun 14th Aug 2016 19:56 UTC in reply to "RE[5]: Predictions"
ssokolow Member since:
2010-01-21

Sure C was an obvious choice back when Unix developers wrote C to replace assembly. Much of C's popularity today is due to network effects rather than anything intrinsically unique to it. Some languages aren't appropriate for that use case, but the truth is that many are.


Funny you should mention that. Everything I've read has said that C won out over Ada because cc came free with UNIX while there were no free Ada compilers of note at the time.

Reply Score: 2

RE[7]: Predictions
by Alfman on Sun 14th Aug 2016 20:32 UTC in reply to "RE[6]: Predictions"
Alfman Member since:
2011-01-28

ssokolow,

Funny you should mention that. Everything I've read has said that C won out over Ada because cc came free with UNIX while there were no free Ada compilers of note at the time.


Yeah, the bundled languages have quite an advantage, think of all those universities and businesses who just used it because it was there. This was before my time, but a similar thing happened with ASP due to the dominance of microsoft/windows in many businesses. Had it not been attached to microsoft, it would have died at birth. Unlike C, ASP was not good enough. Luckily everyone including microsoft has moved on.

Reply Score: 2

RE[6]: Predictions
by Vanders on Sun 14th Aug 2016 21:45 UTC in reply to "RE[5]: Predictions"
Vanders Member since:
2005-07-06

I don't disagree that familiarity is one a reason to choose C...but it's also not a bad reason.

Rust is..already being used to write operating system code:
https://www.redox-os.org/

One operating system is not an entire corpus of knowledge. It's a good demonstration but we're a long way from Rust equaling C in that space.

Edited 2016-08-14 21:45 UTC

Reply Score: 2

RE[7]: Predictions
by Alfman on Mon 15th Aug 2016 01:03 UTC in reply to "RE[6]: Predictions"
Alfman Member since:
2011-01-28

Vanders,

I don't disagree that familiarity is one a reason to choose C...but it's also not a bad reason.


While going with the most familiar might seem reasonable, when everyone does the same thing it empowers incumbents regardless of merit and creates very large barriers to entry, which can be bad.

One operating system is not an entire corpus of knowledge. It's a good demonstration but we're a long way from Rust equaling C in that space.


But this is exactly what I keep warning about: taking popularity to equate merit, or unpopularity to equate non-merit.

Can we at least agree that if Rust had come on the scene back in the 70s & 80s that it would have had a much better chance to compete with C?

Edited 2016-08-15 01:05 UTC

Reply Score: 2

RE[3]: Predictions
by moondevil on Mon 15th Aug 2016 21:36 UTC in reply to "RE[2]: Predictions"
moondevil Member since:
2005-07-08

They plan to move parts of C code into 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.




https://news.ycombinator.com/item?id=12273176

Reply Score: 2

LK
by owczi on Sat 13th Aug 2016 22:35 UTC
owczi
Member since:
2009-11-04

The LK part is hardly new: https://github.com/littlekernel/lk

Reply Score: 2

unlucky choice of name for the renderer
by timl on Sun 14th Aug 2016 16:29 UTC
timl
Member since:
2005-12-06

"and Escher renders the layers"

Oh, the joy of old-school tiled desktop backgrounds. And it'll be continually going downhill from there!

But seriously, this sounds like a potentially cool project. Good to see that at least something of the hobby OS'es of the late 90's and early 2000's gets picked up again. Let's see where it goes from here.

Edited 2016-08-14 16:38 UTC

Reply Score: 1