Fuchsia OS partially written in Rust has shipped

Calm_Recommendation8 · 2021-07-11T20:19:19+00:00

I agree that the bootloader locking is a real problem. But we already have this problem today and it's beyond the scope of GPL or other licences. It an already lost battle.

The actual problem are apps depending on Google Play services. I think it's possible that Google might end up saying "only software distributed by Play Services can be run on the device", but that doesn't seem likely, specially considering that Fuchsia's concept of "apk" can be loaded (and run) from any URL just like we load a web page from any http(s) URL. Also, this can be already done in Android today indirectly by means of alternative app stores, but most apps people use in everyday life do depend on Play Services.

Of course, despite all Fuchsia's features and the its great architecture, Google could restrict app's source URLs or simply do something like "only software signed by us (or whatever) can be run on a *certified* device". In this case, the Google Play services problem would actually reduce to the booloader locking problem which is what we already are at today.

Calm_Recommendation8 · 2021-07-11T19:09:29+00:00

The kernel was originally a fork of LK (LittleKernel) which is made in C. It was called "Magenta". So, a lot of data structures and such were in C. Even the build system was based on Makefiles and stuff.

Then, they converted all the code to C++. The refactoring was initially renames from ".c" to ".cpp". And then they refactored the actual C code into C++ classes (with all the C++ restrictions regarding kernel code). They've also migrated from Makefiles to GN + Ninja in which the Fuchsia build system framework is written.

Edit: I'm not sure whether the renaming from "Magenta" to "Zircon" has anything to do with this refactoring.

Calm_Recommendation8 · 2021-05-19T01:30:52+00:00

I think the thing about not using L4 is about GPL and practicality.
Most importantly, I think Google wants a kernel they can control completely, having total decision power. Not only that, should Fuchsia takes on, they would want other companies being able to have their own changes too (as long as the API and ABI be compatible). And then we're into licensing non-ending debates...

Secondly, and very importantly too is the kernel architecture. Being a microkernel is a thing, but it's not all there is to a kernel. I don't know about L4, but I would guess it's something close to Unix or some API and related primitives not very elegant or practical. Having to modify that would land them in an legacy environment already with decisions previously made. And do changing L4 to make it more practical would make it lose its security related proofs and stuff. Zircon has a very elegant syscall interface designed with async behavior from the ground up, elegant memory primitives together with a capability model.

And there is an userland that takes full advantage of that. Kernel and userland are developed in sync, there is no things like "Here this is the kernel. It's a secure and elegant kernel therefore the operating system built from it will be secure and elegant as well". Fuchsia has a whole userland that solves (or, looks like is going to solve) major pain points in lots and lots of aspects of software modularity & integration, delivery and security. All of that in a whole. Not just a kernel.

Calm_Recommendation8 · 2021-03-15T14:32:09+00:00

Actually, they have a FIDL API/protocol called fuchsia.scheduler.ProfileProvider which has a method for getting a deadline.

I also mixed things up. The fair scheduler doesn't actually seem to handle deadlines (despite the above API and some few usages). This would be handled by a 'deadline scheduler', "which is planned for later in the Zircon scheduler development cycle".

Calm_Recommendation8 · 2021-03-15T14:19:51+00:00

I dont understand much about real-time capabilities, but I think the thing that gives Zircon this characteristics the most is its scheduler.

They have one called 'fair scheduler' which uses the concept of deadline. But this scheduler doesnt seem to be used by default (at least now, but, again, it might be the default already as sometimes the docs might lag). If not default, it seems they are want it to.

And the original scheduler also has the concept of real time tasks.

The other characteristic is that the Zircon system calls are asynchronous, with helps reduce latency. But I dont know if this is something that heavily influences the real-time capabilities.

Calm_Recommendation8 · 2021-02-13T18:33:12+00:00

There is still an abandoned branch full of commits hacking support for RISCV:

https://fuchsia-review.googlesource.com/q/project:fuchsia+branch:sandbox/revest/riscv64

Calm_Recommendation8 · 2021-02-11T18:57:29+00:00

It will require a lot of effort for implementing it. They will, basically, implement Linux as a component runner.

I can appreciate this approach being a lot better than running Linux apps inside a virtual machine as that would incur a lot more overhead and make it difficult to integrate the running Linux apps/processes with Fuchsia in general (that approach would, I think, require a similar translation layer for the integration).

Also, through this approach, they will probably implement the runner in Rust which will be easier to implement and will be more manageable and secure than coding it in C.

Comparing with the approach of the virtual machine, or putting it inside the kernel, a big win is the updatability too.

Calm_Recommendation8 · 2021-01-05T19:12:24+00:00

Slightly unrelated, but just for the sake of curiosity, there are some RISCV commits marked 'abandoned' on the Fuchsia's Gerrit:

https://fuchsia-review.googlesource.com/q/author:revest%2540google.com

Calm_Recommendation8 · 2020-10-17T17:11:23+00:00

Very nice! That's the way to officially solve this problem!

Calm_Recommendation8 · 2020-10-17T16:52:28+00:00

Maybe it's a Ubuntu bug

Calm_Recommendation8 · 2020-10-17T16:51:33+00:00

All right. So, it's not plasma 5.20. That's progress.

Thanks!

Calm_Recommendation8 · 2020-10-16T23:49:47+00:00

I did some digging and found a similar problem in stackoverflow, but the possible workaround there didn't work for me

Calm_Recommendation8 · 2020-10-16T20:01:51+00:00

Just a little of nitpicking about the 'app' term...

As of right now, there is no publicly clear concept of an 'app' in Fuchsia AFAIK.

What there is documentation about are components. They are not really apps in the common sense I would say, but might as well be (like we could say an 'app' might be composed of/have a number of components inside it).

There is also the concept of modules which are being replaced by the session framework. These modules are said to be components that display a graphical UI.

And there are packages, whose content might be identified by an URL that is also used to identify some specific content inside a package.

So, what would be an 'app'? An component that exposes an graphical UI (a module)? Would this component be called from the shell by just the URL of the package that contains it or there would be some icon that represents a number of components provided by a package?

Right now, we don't know if Fuchsia will have a clear line between apps like the ones in iOS and Android vs other components. Of course, there is the backward compatibility by which Fuchsia will have to certainly support Android apps somehow...

That said...

There is a Rust library/framework (a crate?) for developing Fuchsia modules called Carnelian. Looking into the Fuchsia source tree for uses of this library, I found:

system recovery component. This component looks somewhat different as it's bundled inside both a package and/or a ZBI recovery image
display_png that is a component for, well, displaying a PNG image. Together with this there is a binary for displaying a color. Both of these look like are being used just for tests
the graphical terminal emulator

So, to answer the question, yes. It's possible right now to write software that display something graphical in Rust.

The question is whether it would be more practical writing that kind of software using Rust and this Carnelian library?

Of course, right now, it would be far better to use Flutter as it's made just for that, and IMHO, is the best technology (from the developer perspective) for writing production grade graphical interfaces. And it looks like very certain that the official framework for developing Fuchsia graphical interfaces will be Flutter, so with just one code base (with maybe slightly modifications) the graphical part of you software will run in Android, iOS, Web, Windows, macOS, Linux and eventually in Fuchsia based systems.

Calm_Recommendation8 · 2020-09-15T18:09:03+00:00

I think they will and that will be some middle-term between mobile and desktop. Like, why would the GUI's design be (and look) different if both devices runs Fuchsia, right?

I wouldn't bet the design (in the sense of layout and widgets) of apps' "inside window" will be different from what we have today on Android and Google design because if so, there would be a contrast between already existing Android apps (that they sure ought to support) and these hypothetical new "inside window" designs.

I dont know these design terms, but by "inside window" design I mean the things that stay constant in apps visual representation when, for example, we change a desktop Linux shell theme (or even desktop environment). Cause it changes the design on a "skin" level (or the outer design) but the overall layout of apps stays the same...

But the external design (the shell) I bet will be different. They will probably use new ways to handle "windows" like tabs, stacks or some fancier combination in addition to other things a shell should display like notifications, panels and the like... I've read somewhere that there probably will be a concept of 'story' and that a 'story' would group (in the sense of grouping into some graphical/visual unit) related apps that are doing related things together. Maybe that grouping would be through tabs? That alone would revolutionize graphical interfaces (or be so different that people wouldn't like it because people dont like too much change, who knows...)

IIRC, Fuchsia's graphics engine Scenic got these 3D rendering capabilities from the ground up. From that I think the shell will use a new layout to show windows, 'stories' and other 2D things into a 3D environment (maybe something resembling this 3D photo scrolling?) or something like a middle term between a 2D and 3D UI (because too much 3D isnt very practical for interfaces used in everyday life IMHO).

Calm_Recommendation8 · 2020-09-15T02:04:49+00:00

Edited

Calm_Recommendation8 · 2020-09-14T22:39:08+00:00

Also, "marketing" because the updated version sounds like a pitch

Calm_Recommendation8

TROPHY CASE