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.
Pink was the original codename for the work within Apple that became Taligent. I wonder what is Purple?
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.
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.
because it ever becomes the fractured mess that is Android, the name can be easily re-interpreted as “f#cks-ya”
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.
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.
On the contrary, they are obviously all problems that cannot be solved by a device.
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
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.
Purple could be for Ubuntu, as their default background has been purple for a while, and Google is known to use Ubuntu internally.
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…
* 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
Hey Thom,
Are you helloworld517 at HackerNews?
https://news.ycombinator.com/item?id=12271372
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).
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.
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.
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.
Is NewOS good. I would prefer they used a L4 variant,or even better, seL4.
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
With all those colors, it seems like a next gen AmigaOS badge
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.
Wrong. The internals are C (not a good choice IMO), UI layer is Dart.
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.
Vanders,
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.
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
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
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/
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.
Vanders,
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.
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.
ssokolow,
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.
I don’t disagree that familiarity is one a reason to choose C…but it’s also not a bad reason.
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
Vanders,
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
No, that isn’t what I’m saying. C is well known and well understood as a systems programming language. That has merit. Rust is less well understood as a systems programming language.
Rust has merit but there is less knowledge about how to use it effectively to write an operating system.
Vanders,
What compilers do is perfectly understood in both cases – they take source code and translate it into machine code, that’s it. Machine code for kernels isn’t particularly special. You might argue that most languages don’t have operators to manipulate special CPU registers & flags and therefor have to invoke assembly, which is a deficiency. However it’s a deficiency that is shared by the C language.
Seriously, there is nothing whatsoever special about C kernel code. This is abundantly clear to DOS programmers because regular code ran in the exact same context as kernel code without any barriers – anything the kernel could do, you could do too. If your program only relied on BIOS calls, then a very neat side effect was that it could actually get loaded and executed from a bootloader by loading it into an appropriate address without any changes at all. I did this with pascal programs back in the day.
I doubt anyone can find anything about the C language itself that makes it inherently more suitable to kernel development than all other languages invented since. So can you at least concede that the original statement “nobody has yet come up with a better language for writing a kernel” is debatable
I think Vanders is saying that, while Rust has all of the technical boxes ticked off, it’s young enough that people don’t feel confident that their knowledge of C translates over when it comes to the hidden gotchas (either time-wasting or logic flaw-encouraging) in how design pattern X interacts with language feature Y.
Edited 2016-08-15 16:01 UTC
ssokolow,
Do you have a specific design pattern in mind or is it just hypothetical?
For me, macros come to mind. I’m of the opinion that it’s better to have typed macros than naive text substitution. But obviously the C pre-processor performs naive text substitution with no contextual rules or scope, which can drastically change the source & header files, even syntactically. Different programmers have mixed feelings about this.
One thing I strongly dislike about C it’s compulsory use of macros at times just to work around C’s shortcomings. A universal one is using a text macro for array size declarations even though a typed integer constant is what we really want to do instead. It’s stuff like this that makes C antiquated.
Ultimately you may be right that some patterns might not translate perfectly from source because of language differences. However I’d argue most projects shouldn’t be switching at all if they’re already working. It’s far better to target a language from day one.
I don’t think it is so much the output of the compiler as it is a general well understood idea of what the pros and cons of C are and where the pitfalls lie. Essentially how coders use and react the language if they are to be using it to write an OS.
Rust, to take any random example, has yet to prove empirically that the outcome will be better than a kernel written in C. Some “Hello World” kernel proof from Rust fans has a long way to go when its compared to decades of commercially successful C kernels.
You also have to keep in mind it sometimes takes a long time for people to get a good understanding of how to best use a language. Take early C++ vs C++14 “best practices”. Early C# vs the latest iterations. Etc etc. By choosing C there’s decades of knowledge on what is the best way to attack the “how to write a kernel” problem.
dpJudas,
As you illustrate, this phenomenon isn’t specific to Rust, that’s the nature of having many chefs with different ideas of how to do things. Even when sticking to a single language like C, each project has different conventions. There are things I would do differently in linux.
I’ll leave you guys with this thought: Is it better to be the bigger chef, or is it better to be the better chef?
I wouldn’t call that popularity. I’d call it risk management.
If Google is using Rust everywhere, then they must have already done the expensive, hard work of vetting Rust as a safe choice. That’s the whole point of including testimonials in your marketing materials.
Then the question becomes the less demanding one of “are we similar enough to Google in the ways that matter to this problem for their experience to apply to our circumstances?”
Edited 2016-08-15 22:19 UTC
ssokolow,
Actually the example was meant to be a hypothetical lie with no substance – just the lie could generate more interest than anything they do internally. Of course if it wasn’t a lie that would be even better – like apple/ms/google announcing rust as a first class language for app development. It would put it on the map in a major way.
One thing is for sure, which I already knew, but all these comments really hammered down the point: the real challenge isn’t finding a better language, the real challenge is changing people’s minds.
Here’s one for you: the best chefs are usually those too busy cooking than spending their time on forums telling other people how they should cook.
(yes, I know that means I’m probably not the best chef either. Then again, I never could cook.
)
dpJudas,
I didn’t say anyone should. My point was to highlight the consequences if no one did.
The costs of developing another operating system from scratch with the breadth of linux capabilities might require around $1.4B for a kernel and another $9.4B for productivity applications.
https://www.linux.com/publications/estimating-total-cost-linux-distr…
That’s not really economically feasible or justifiable. I’d expect you to do what so many including myself and the big corps have done: use linux and be grateful for it. I genuinely am. I’m less grateful for C, and I wish something better had taken it’s place. However C’s dominance in kernels was determined at the outset and it’s difficult to imagine any way it could realistically be replaced in the mainstream now.
What it takes is the security threat caused by possible buffer overruns to get so critical that something has to be done. Even then, it would probably be solved by an extension to C than rewriting everything from scratch, as newer languages would demand.
dpJudas,
C has already caused a great deal of damage over it’s history. Instead of becoming motivated to switch to more secure languages, we’re becoming placated by features designed to limit the damages caused by insecure code, such as address space randomization. If it hasn’t mattered to the industry up till now, then what makes you think it could ever matter?
They plan to move parts of C code into C++.
https://news.ycombinator.com/item?id=12273176
The LK part is hardly new: https://github.com/littlekernel/lk
“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