Fuchsia IDL Overview
fuchsia.dev
fuchsia.dev
[0] https://en.m.wikipedia.org/wiki/Component-based_software_eng...
Edit: I say this because fuchsia seems to be an attempt to build an OS from scratch. Introducing a new IPC layer built specifically for the permissions-based language agnostic model of the zicron microkernel will make cross language/cross application interoperability way easier.
Sun RPC, DCE, CORBA, COM, D-BUS, gRPC, AIDL, XPC,.....
DCE's RPC and IDL were derived from Apollo's NCS RPC and IDL.
I'm unaware of a direct link between NCS and Mach, but Mach's RPC and Matchmaker IDL (and the 'mig' tool) I think pre-dated NCS? Ironically, they're the basis for Apple's XPC today.
I'm old :-)
DBus as well, but DBus is horrible.
Instead of creating a new language for interface definitions; why not just use an existing general purpose language? C++, Objective-C, Java, TypeScript ...
Or take this new language you have created and extend it with control structures and other basic language features, and write the OS in that.
In my opinion Oberon (and similar) is an example of a fundamental massive task (building an OS from scratch) actually becomes easier if the scope of the task is expanded (by creating a language suitable for the task).
Google has so many resources and so many dispersed projects that individually are world class (virtual machines, programming languages, UI design, OS microkernels etc.) but they don't bring them together to a coherent something that really could bring things forward.
This is the curse of being a big company. Google is not unique in this sense. I remember a conversation I had with Cory Doctrow few years back. I met him at Cambridge's(UK) Judge Business School where he was giving a lecture to promote open-source ideology. After the lecture I was walking back home and he was going to the bus-stop. So we started chatting, and I bragged about my employer telling him that my company has open-sourced its Operating System. He looked stunned and asked "Which company??". I said Symbian :) And he said, "Ah! Nokia!" :) And then he pulls out an N95 out of his pocket and says "Nokia makes fantastic hardware, but look at the software! You can't even find a menu item. One has to press 2-3 buttons to just find an app." Then he pauses as says, "I visit Nokia, and meet lot of people there. They have some of the smartest people. You talk to them individually, you realise how smart they are." And then he waves the N95 and says, "But you put them together, and they come up with this!" :) I understood what he was saying!
The UI uses Flutter.
Surely you can find a general purpose language that gives you that ...
Hashicorp HCL2 might also be, but I don't know if they are turning-complete off the top of my head. Some blog suggests it actually is TC, but I cannot corroborate.
Starlark/bazel is TC.
You can add Berkeley Packet Filters and BLooP to the list of TI languages: https://www.quora.com/What-is-an-example-of-a-Turing-incompl...
Now maintained by independent developers.
To clarify slightly: Encoded Protobufs cannot be mutated in-place at all. You have to parse into language-specific in-memory objects, mutate those, and then serialize again. Cap'n Proto does support in-place mutation, with the caveat that if any object changes size, it'll be moved to the end of the message, leaving behind a "hole". You can "garbage collect" the holes by copying the whole tree into a new message, which should be much less expensive overall than parsing and serializing the whole message as Protobuf would require.
If you could convince multiple languages to share the same notion of a heap (including how to malloc() and free() memory), you might be able to get closer, allowing for truly mutable objects without the caveats Cap'n Proto has. However, memory allocation is a major place where languages tend to differ wildly.
- Renaming a field: Does FIDL rely on the traversal order for stable IDs?
- Converting the type of any field backed by a varint to any other varint field (bool, ints)
- Converting a singular field to a repeated field.
https://fuchsia.dev/fuchsia-src/development/languages/fidl/g...
There can be a lot of value in rebuilding the same things from the ground up. There'll always be differences and novel things that people earlier hadn't seen. Of course it's costly and disruptive because you kill a lot of stuff, but especially in software building new things is relatively fast.
People will always complain about companies that kill a lot of products or software but at the end of the day they get more chances to build things from the ground up.
If you create a product then there is an external cost borne by the users who need to use it. And then if you replace that product with some other product, those users need to retrain.
It's really easy to create a new product, but it is a commitment for someone else to adopt it. And just because the cost is externalised, doesn't mean it doesn't exist.
Maybe there is value for managers (who got promotions) and programmers (who got promotions and learned something), but for Google there is no value at all - it losts its users.
I remember everyone using gmail chat.. that they "remade" (killed) like two times.
Everyone just moved on.
Also I dont understand why investors arent unhappy with that. Google can still earn hundreds of millions on chat. Those wont be billions, but it is still money. And "hudred million here, hundred million there" start to add up.
* Google+ (rip)
* Google Allo
* Google Chat
* Google Groups (separate from Google's Usenet service)
* Google Hangouts
* Google Messenger
* Google Duo
* SMS via Google Project Fi
* Google Voice
> And how many dozens more have they already killed?
Too many: https://killedbygoogle.com/
I expect, for example, that it is vastly more efficient to send a known datastructure over the wire in FIDL, but it is vastly more efficient to parse, modify/extend a repeated subfield, and then reserialize a protobuf.
You can't "fix" a system to achieve two goals that are in conflict, sometimes it is in fact better to have N opinionated systems, than one that is only okay at everything.
That said, there are certainly many design decisions that FIDL does do differently because the constraints of the problems it tries to solve are different as you mention.
Looks like "structs" you can only remove boxed fields by setting their references to null, but not add fields.
Also if you are trying to be comprehensive, don't forget about AIDL/Binder which is used by Android, and mojo, which is used by Chrome. Both of these are IPC, however they are not general enough to be used outside of their respective platforms.
To be more specific, is there really a justifiable specific of either of these applications which prevent us from having a single tool which would cover both?
Could we have a single IDL that generates two sets of serialization code one optimized for IPC and the other for network transport?
There are more of these sorts of examples I could enumerate if you find it worthwhile.
While you can have tightly-coupled, highly interactive IPC that would be pathological over RPC, where DSL/IDL and protocol semantics rightly focus on more loosly-coupled service interfaces with network error recovery, I question whether it is desirable even in the IPC case. Intra-service IPC within a single runtime can be as chatty as needed without becoming an Inter-service call (and potentially RPC in other architectures), so does Fuschia answer to an actual need - is there actually a valid use case for tight-coupled highly interactive local inter-service IPC that isn't better architected assuming RPC? Is the benefit of assumed IPC between co-located client/servers an actual problem that 'colocation optimised' RPC doesn't already solve well enough?
[1] https://www.omniorb-support.com/pipermail/omniorb-list/2006-...
It's a pretty straightforward & extendable way to do permission handling, rather than needing the kernel to do all of that natively. Whereas if you go the RPC route, then you're into not just a monolithic kernel but a larger-than-ever monolithic kernel as it's now doing permission management, too.
Really? I know you can use SCM_RIGHTS on a socket, if that is what you mean. In my mind IPC means shared mmap'd memory, though
Compared to protobufs, it's much more concerned with being more fixed width, word aligned, efficient copy-free in-memory accessable. Proto3 spends a lot of effort compressing ints on one hand but remaining flexible and allowing fields to be optional on the other.
On top of all that, there's a good deal that's specific to it's kernel, Zircon, it's permission/capabilities model, and how these messages interact with their syscalls.
I'd imagine these kinda details are going to matter a lot for a microkernel.
I don't know it as deeply but I'd say it's much closer to cap'n proto. Not sure who uses that though!
[0]: https://fuchsia.dev/fuchsia-src/reference/fidl/language/wire...
[1] https://opensource.googleblog.com/2014/06/flatbuffers-memory...
[2] https://google.github.io/flatbuffers/flatbuffers_guide_use_c...
To be fair, Binder originates at Palm[1] and seems to have been originally intended to be a full cross-platform replacement for COM, including DCOM (intended but unimplemented) and OLE (apparently implemented but unreleased[2]).
[1] http://www.angryredplanet.com/~hackbod/openbinder/
[2] https://www.osnews.com/story/13674/introduction-to-openbinde...
Except there's also an older legacy system still used in spots, though it doesn't have an IDL it's more defined in C++ macros.
I've read somewhere that Fuchsia's UI is being developed behind closed doors, so it may be in a more ready state than what we believe. I wonder if Starnix and ART are already functional.
So hardware has gotten more complex and featureful, which requires more effort and code to handle. There is a variety of popular hardware to support (ARMv7, ARM64, x86, amd64), not to mention network cards, and peripherals. There are so many new protocols and standards to support nowadays.
Basically, implementing an OS from scratch seems to get progressively harder and harder as the years go by. The funny thing is, despite how time consuming and difficult it is to get right, web browsers have become so bloated that they're basically just as hard to to implement from scratch.
I'm very happy to see the concept does crop up somewhere. It's always a shame to see IDLs that don't leave much room for languages to leverage null-safety features. Especially ones that don't make the distinction between the concept of optional and default (looking at you proto3).
what is the current status of fuchsia?
In the sense, of when could one to expect to use it as a daily, stable driver?
Probably will first replace the Linux kernel in ChromeOS first, then Android later.
[0] https://9to5google.com/2022/03/04/full-google-chrome-browser...
Well, in ChromeOS I do not really use (or have) much more, so I could probably actually work with that, if all is stable. But I was just curious and maybe look into dahliaOS, if I find the time.
https://9to5google.com/2022/03/04/full-google-chrome-browser...
For example, imagine a function call in C++, when compiling with all the optimization on. If a parameter is fixed or unused, the compiler can remove it and the associated memory location and code.
But in Fuchsia IDL, there is no opportunity to do similar things. The client must make a fully formed request, and the server must make a fully formed response.
They'd need to encode present/absent for every single field? Too many optional fields and you end up encoding variable lengths over and over too.
They go through great lengths to define alignment, how address space specific pointers are meant to be encoded/decoded in-place, field ordering etc. They seem like opposite ends of the tradeoff spectrum to me.
Protobufs drifted towards maximizing optionals, this seems geared towards minimizing them.
It could also 'inline' some IPC calls by moving server code to the client.
COM is one of the most battle tested IPC in production, with support for in-process shared libraries, and Microsoft never was crazy enough to try such optimizations on the Windows dynamic linker when loading COM libraries.
You would have the same concern with any kind of dynamic linking. It's nothing new, it simply allows for forward compatibility with future versions of the external code.
Please someone tell me they've learned from the decades of C/C++ gotchas and not made them arbitrary-length null-terminated sequences of bytes...
However I wouldn't advise doing that direcly unless you trust the callee.
"Security", "Updatability" ... "Long-Lasting". You'll forgive me google, if I don't believe that these are your true goals. History suggests otherwise. What I'd really like is the list of the ways you're planning to use this to increase how much data you collect on people.
I don't know which argument carries more weight. Should we expect Fuchsia to take a defense in depth approach to component authentication?
Putting aside their technical capability to do so, which is not a small issue, all consumer android phones must be certified by google to be able to install play services. If google mandates they need to use Fushia for it they will do so or get out the market.
Regardless of the reason why Amazon Fire Tablets get sold, they are sold.
Ah yes, the Android reskin (see: https://arstechnica.com/gadgets/2021/02/harmonyos-hands-on-h...)
> Samsung once threatened to switch their Phones to Tizen
An empty threat -- Samsung knows that no one would buy their phones based on Samsung specific software selling points like Bixby™
Having driver APIs is a good thing. Drivers belong in userspace, where they can get the benefits of compartmentalization.
Their motive is very simple: control. Mostly they actually do a good job because they just have a lot of skilled people. Go is a nice language, people seem to like Flutter (even if I don't), Chrome is arguably the most popular browser by far, etc. So, from Google's perspective this probably is a proven strategy.
With Linux vs Fuchsia, their motive is crystal clear. Linux is kind of high maintenance in the sense of cat herding its community in any kind of direction is somewhat of a challenge. That's Linus Torvald's job and he isn't a Googler and fiercely independent and hard to manage. Google soft forked years ago with Android and the Android kernel is way behind what happens in the Linux kernel and has lots of custom patches. Fuchsia is an attempt to break away from that and have something that is easier to deal with technically, without GPL and other IP issues, and something they control. It's the same reason Apple and Microsoft don't ship operating systems based on Linux (yet, MS came close a few times): they like having control.
In my view the challenges with Fuchsia are actually non technical and related to Google's control over it. That is not going to sit well with OEMs that have already had to deal with Google's level of control over Android. Are the likes of Samsung, Huawei, etc. going to jump on the band wagon? I think that they won't be in a hurry to do that. I think that's one of the reasons why Google is taking their sweet time getting to market with this with a more serious product than the Nest stuff they did a while back. Maybe I'm wrong and the next Pixel phone is going to be Fuchsia based. Or maybe that will never happen.
I bet it will happen.
I also bet during this decade and the next that at least one Pixel phone will be Fuchsia based and ChromeOS will also be Fuchsia based.
Google's intentions with Fuchsia are absolutely clear.
Samsung is already a fushia contributer, so they are to some degree considering jumping on board.
That's not really true at all? Upstream finally took a lot of the stuff they objected to almost a decade ago (like wakelocks & binder), and since then Google has reduced the amount of forks not increased them (like contributing F_SEAL_FUTURE_WRITE to memfd to allow memfd to be a viable replacement for ashmem: https://lwn.net/Articles/768785/ )
And then the most recent biggest "downstream patches" for Linux where around the scheduler, and that's all been upstreamed, too (and again quite a while ago), in the form of EAS: https://developer.arm.com/tools-and-software/open-source-sof...
It happened before also. At one point Samsung was suppose to smother every android native app with their versions and alongside develop new OS (Tizen). And in intervening years Samsung or others have not proven that they can create large, quality software projects and ecosystems. So Google really have to do no more than reduce staffing for Android if and when they like to promote Fuchsia over it. All these phone makers are not gonna pick up slack and start maintaining.
Also the likes of Samsung are really vulnerable to low cost manufacturers from China. So challenging Google on low level technical layer as far as business goes is hardly wise.
One can argue vendors can just fork whatever "last/latest" release of Android and go their path. This indeed can work for few years. But with Apple/Google marketing of new experiences and features only supported by new OS this will be tough. These small vendors can't hire top software engineers who are used to Google level salaries to help develop features which otherwise estranged partner would have done.