No rational company is going to create useless projects just to retain expensive engineers. What's the point in retaining engineers if you're just going to pay them to work on something without expected ROI?
(Short) story time!
Windows on ARM was a solo pet project of a high level engineer at Microsoft!
There are some engineers who are so valuable that letting them spend non-trivial amounts of time on whatever they want is a very good use of company resources.
Sometimes just not letting the competition have them is valuable!
I've worked with a few 10x-20x engineers, if someone is that productive, they can spend 2 years off on another non-ROI project, come back, and spend 2 years on a project with ROI, and the company still comes out ahead.
Most company's aren't smart enough to figure this out, then again determining who these people are is also a problem. That latter part is funny (ironic?), because on the ground floor everyone who encounters a world class engineer is pretty darn sure of it.
I'm not claiming that Google or other companies often do this, but just to play Devil's advocate, here are reasons why they might:
* Prevents them from going to the competition.
* Uses their prestige to attract or retain other developers.
* Keeps them "on retainer" in case a hard problem that needs their rare skills appears in the future.
When I worked at EA, we had a star engineer that spent, like, 75% of his time totally dicking around on whatever he felt like. But when say, it was a month away from FIFA's ship date and they couldn't get the game to run faster than 5 FPS, they would call him in. He would work some magic, the game would ship on time and with adequate perf, and he'd return to goofing off. Well worth EA's money to keep him on salary.
As others have pointed out, the ROI can be something entirely different than $$ in the accounting ledger.
9 years into my BigCorp career and I still find it flabbergasting.
Since I was got into programming in middle school, I was obsessed with OS design (yeah, reading the source code for L4 in high school). As I went further in my education, I felt the landscape was pretty stagnate at this point and went into other areas (initially driver development and now developer tooling).
While I've not had a chance to jump over to Fuschia to participate, it warms my heart to see the development going on.
The majority of microkernel based OSes just implement these APIs to emulate UNIX APIs and that IMHO is a waste of potential but understandable in order to be backward compatible and not have to develop whole new userspace applications from scratch.
But I really like Fuchsia's take on the design of this userspace and the way the 'capability security model' is integrated into it. The amount of APIs built into the base 'Fuchsia platform' really blurs the line between and OS and a stack with OS plus essential services. Today, IMHO, things like automatic updates, software distribution, crash reports, and other low level application centric facilities should really be provided by the OS and that is done in the base Fuchsia platform.
Google were so convinced of the value of open source that they didn't anticipate that almost all OEM's would rather ship their Android forks than to stay close to upstream. If they hadn't intervened, Android as a platform would be useless by now and app developers would need to implement various ways of handling notifications, storage access, etc just to ship their apps to a broad audience of device owners, Samsung would've never upped their update game and there wouldn't be 2-3 versions of Android on the majority of devices, but more like 5-10, depending on how many manufacturers would've survived in the market.
Android still allows for easy side loading of applications, there are still major independent after market Android versions out there, you can develop for Android in various languages, using a huge selection of IDEs and there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against. Google didn't even manage to gain any relevant market share with their Pixel line of devices, of which most run Android. They could've done a lot of nefarious things by keeping newer Android versions Pixel exclusive until they publish the source code to OEMs, for example. Instead, they are making it easier to quickly move an existing Android code base to the latest version by abstracting away a lot of the complexity (project treble).
Is Google still primarily am advertising company that tracks its users? Of course. Do they have their own motives to keep Android at the top of the mobile OS market? Of course. But a lot of the comments see evil scheming where Google probably had to act quickly to ensure that Android has a future and that developers didn't lose interest in the platform in favor of iOS.
AFAIK these are reverse-engineered. Do you sincerely believe that developers' time is best spent reverse engineering and maintaining play services alts to undo a blockade that Google put in, just to be able to get full freedom over their android derivative? Wouldn't it be better spent in playing with cool new tech (as Google engineers seem to be doing)?
> that developers didn't lose interest in the platform in favor of iOS.
Developers go where users are. Some developers sell their apps on the store, others get hired to build apps that are distributed for free to make people use services they buy outside the store. Banking, business apps, etc. It's impossible to lose interest in Android. It's too big. Compare it with Windows phone which died for lack of users.
ATM OEMs are NOT allowed to use Project Treble. There is only one OEM in the whole world that did an upgrade using Project Treble. What does this OEM have special? Well it's Meizu, they ship only in China, and doesn't care about Google certification. The certification that you say helped prevent Android from being fragmented. Turns out it actually helps fragmentation.
Meizu, Amazon, and Huawei are not Google certified. I have yet to hear developers say they are specifically worse than other Android devices. Last time I had an Android device with stupidly broken video aspect ratio (I'm a multimedia developer amongst other things), it wasn't a Meizu, Amazon or Huawei device. It was a properly certified Philips TV.
Project Treble is sincerely a superb engineering project. But the truth severely lags behind.
If you don't care about Google certification, you can upgrade an Android 8 device to Android 11 finger in the nose, keeping Android 8. It's bootable in a day, usable in a week, production ready in a month. If you care about Google certification? Well, you need to upgrades your drivers to Android 11 base, which is a non-sense when mentioning Project Treble.
How to upgrade drivers? Well it depends. Usually the first step is to upgrade your build scripts. Because well of course, every two major upgrades Android build system is "upgraded". Well, OEM got the trick, now they are building their drivers out of Android, and their build system is a giant shell script. Way to go! Makes upgrading to newer Android version much better!
Now you've managed to build your Oreo drivers into Android 11, congrats! Now let's start them! Oh, new "security" features have appeared, and now half of your code no longer works. (fdsan I believe is way more annoying that it is meant to be)
Let's not forget about Android 9 Go mess as well. (Hint: The only post-Oreo Samsung devices that didn't get their 2 upgrades are Android Go devices) Basically Google cares about RAM consumption two weeks every 2 year, so only this exact release is usable on low-end devices.
Is Google evil? I don't believe it is. Hell I believe that every Google engineers believe they are working towards a better future. However I do believe that even within Android itself, there are many units, that are (mostly unwillingly) shooting at each other's foot. So yes having AOSP is awesome, Project Treble is beyond any hope I had back then. Still, overall the improvement is far from what has been advertised.
To come back to Fuchsia, I believe it is going to be pushed to Android devices in two years (so Android T). OEMs won't have a word to say in this: Google gave a try at such a big change through GKI, and OEMs have been complying nicely, so going to Fuchsia should be pretty easy too. I'm expecting some Android features to be offloaded to Fuchsia for "security" reasons, like Window Manager, which will constraint OEMs even further down as to what they can change, because the Fuchsia "core" image will be like Google Services, mandatory Google-signed. (There'll be Fuchsia app images as well, which people will be able to do whatever they want with, but that's something else) I hope I'm wrong.
(And I just learned about the GSI image for Pixel 1/2, thanks for that!)
The couple of devices I've broken down a release for and rebuilt just to clean out Trojans included in the firmware were devilishly difficult. And does it ever piss me off that there's nothing generic and updated to run on them.
It is as black and white as, "Chinese market."
A primary reason why I would choose open over closed source is the ability to avoid ads and tracking. Can the user remove all the phone home nonsense from Fuschia. Of course not. This defeats the purpose of open source for me -- control. With this, I have to share control over the computer with Google.
Apple and Microsoft both have something similar but with their own website, and AFAIK there's no way to change the url on iOS.
Also, please tell me the ":wq" was unintentional.
I mean search the kernel for references to use-after-free or null pointer dereference.
Since then, there's been big improvements in development practices, tooling, and languages to prevent security issues from occurring in the first place.
Why do we need this? We have Linux. It works. It is open-source, general purpose. It needs more support to become more mainstream (like what Valve has done with Proton).
Don't like Linux? Start with one of the BSDs. Heck, start with Haiku. Any of these projects are lightyears ahead of anything that's just starting.
The most likely explanation is that _we_ don't need this, but Google does, for some strategic purpose. It must be for some pretty compelling use-case, because we know how happy they are to kill projects.
Because every once in a while, it‘s easier to free yourself from the shackles of architectural decisions that were made because of the hardware and constraints of their time that are obsolete now but are supported for legacy reasons.
A security model that is designed from scratch into such a deep OS concern as with Fuchsia is one of the aspects that would be next to impossible to bolt onto such a conplex project such as Linux or BSD.
I‘m not saying it will play out, but it certainly brings a wave of fresh and radical new ideas into open source operating systems I haven‘t seen since the times of BeOS and Plan 9.
But Minix, the hero of the Microkernel research, became the guardian of Intel systems and preventer of tinkering and exploration.
Can we certainly say that Fuschia will be Free and mild natured like BSD and Linux or will it become another silent "hard-layer" like Minix?
GP (and I) certainly fear about the latter. Given Google's transformation to Modern day Microsoft of the 90s, it's not too far-fetched it seems.
For something that interests me personally, the POSIX idea of ptrace and signals for debugging is a fundamentally broken and obtuse API that just don't work very well with how modern software is designed, and requires a decent amount of hacks to do anything rational with hardware traps. I did think a little bit about what kind of API I wanted if I were designing de novo, and happened to pop through Fuchsia's API at a glance to see what it decided... and it was exactly the kind of way I'd have thought about this space.
One application they’re probably interested in is a sandbox/containerization system with a drastically smaller surface area than the Linux primitives. That’s what excites me, we may get to the point where things like Firecracker VM and gVisor are no longer needed for robust isolation.
About the biggest piece I can see which benefits the outside world is the fact that Fuchsia's drivers are independent of kernel version. This is one of the biggest pain points for Android upgrades.
A Fuchsia based kernel upgrade won't be held hostage by lack of Qualcomm/ Nvidia/ Mediatec binary drivers.
But mostly, I suspect Google just wants an OS that isn't burdened by GPL.
* All code in the kernel including all drivers is 100% trusted. This is very bad for security.
* No stable driver ABI, so writing out-of-tree device drivers is very difficult.
* GUI is an afterthought, which means it is very difficult to do things like graphical secure attention keys, and frankly graphics/display support on Linux is very janky as a result.
* Many of its features are firmly stuck in the 80s.
There are two ways out of this situation. You can either replace Linux with another kernel with stable driver API or you can replace SoC manufacturers with those willing to upstream their drivers. Probably it's easier to go to the first route.
Of course from a business perspective it's definitely a power-grab, just like Chrome was. But from a technical perspective I think it makes a ton of sense.
* - considering google's software mortality rate, i am skeptical of anything new and daring getting enough time to mature. It will be google plus'd.
So Google own the kernel under a license that lets them add secret sauce.
There generally tends to be an insular 'cathedral' rather than 'bazaar' approach to Google projects where those working for the company get considerably more say and control than outside contributors.
The whole issue I have with it is that they pretend otherwise. With go many people laboured under the misapprehension that they could have more input than was actually possible. Not so different with chromium.
The cathedral model is fine but be honest about it.
With the Linux kernel if you have a good idea and can defend it you have a genuine chance of contributing. So I know my limited spare time efforts aren't wasted. With fuchsia I couldn't be so sure.
I hope I am wrong but the fact they are only now taking potential contributions suggests otherwise.
As someone who knows little about open source politics, I'm genuinely curious about how people expect this should work. What are the large open source projects that have the gold standard for this that I can learn about?
My initial reaction is that if a company contributes considerably more to a project, shouldn't they have considerable more say? For example if they have 20 full time engineers working on it and have contributed 95% of the code, then if I come along and make a few changes should I have equal say and control over the project?
I think that’s often the (subconscious?) attitude Google has towards its open source projects at least. Which would be fine if they didn’t try to make it seem like their OS projects are a welcome place where anyone can contribute ideas and code and move the project forward.
As an example: Angular is open source but it’s very much a Google project. Rails is also open source but it’s a broad collaboration, certainly not a “37signals project”. Most people would rather spend their time contributing to the second kind of project.
The oft-cited case with Go (and I'm paraphrasing heavily, so this account is likely unfair to everyone involved) was when Peter Bourgon formed a committee to design a Go packaging system, there were a bunch of meetings held that included core team members, and Russ apparently surprisingly came out with the Go modules proposal. The core team decided to adopt Russ' work. The team's perspective is it solved their problems simply and cleanly, and it came with an implementation. The community perspective was that the core team was now a sort of cabal.
I think the issue here isn't that the community's project was rejected, it's that there is a perception that folks were let to waste their time. It seems that sometimes people want this idealized model where an open project has a community that is on equal footing with the project owners, but I rarely see this to be the case in practice. Ultimately some individual or group holds a "voting share" that outweighs the community.
We have a documented process for system changes in Fuchsia that we have already been following internally. I've seen various proposals rejected; I've had proposals of my own rejected. It's always disappointing to have work rejected, because no matter what, it takes effort to come up, submit, and socialize work proposals. It's easy to feel slighted, especially when you're contributing for free while the folks making the decisions... well, it's their job.
I think I can say that it is nobody's goal on Fuchsia to waste folks' time. But I think it would be naive to think this kind situation couldn't or won't occur in the future. I just hope our transparency about our process and our availability to communicate with the community through lists will help mitigate negative feelings when a proposal representing a non-trivial effort is rejected.
As an open source contributor, it’s very unfulfilling and disappointing to find out you’re essentially an unpaid contributor to a company project.
> The whole issue I have with it is that they pretend otherwise. With go many people laboured under the misapprehension that they could have more input than was actually possible.
> The cathedral model is fine but be honest about it.
At the same time, it is an active project with active development that are informed by goals and processes not all of which are open. And really, while the development has been "in the open", it hasn't engaged the public until now. To that end, it's not possible to engage in a "bazaar" approach off the bat, whether or not that's a goal of the project.
Having been active in Go development and seeing some of the issues there, I understand what you mean. I don't think we state anywhere "this is clearly a cathedral model of development", but I think we're pretty clear on it:
* We have a section of documentation on project governance https://fuchsia.dev/fuchsia-src/contribute/governance
* We have a section of documentation detailing different kinds of contributors, acknowledging that there are kinds of contributors with special powers, and also reserving the right to revoke contribution privileges in some cases: https://fuchsia.dev/fuchsia-src/contribute/community/contrib...
To the extent that you can look at these as a set of policies, follow all the policies, submit a change, and have that change rejected, I think that is unfortunate. I think this is much less likely if you first engage with the stakeholders, and having opened up mailing lists, we've made it simpler to do that.
However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion. I can fork the repo, but that's also already the case with Fuchsia.
> the fact they are only now taking potential contributions
We were honest about this too, and our documentation used to explicitly say that we did not accept external contributions.
The bazaar certainly exists for the Linux kernel insomuch that this can and does happen (partly as a result of the fact many companies contribute but none control it). For go it does not, for chromium it does not seem to either.
It is tough for a company with internal aims and pressure to adhere to that kind of model for sure.
And it is good you have been honest about your approach prior to this in that no contributions were taken but now it is a matter of whether or not a non Googler has the opportunity to make such a change, in accordance with your policies.
But obviously as a hobbyist with limited free time I am understandably cautious as to where I put my effort.
Honestly on a personal level it is probably no loss on fuschia's part, I am a minor contributor at best, but the general point stands.
I am aware of one, but an important one: ZeroMQ. Thanks to the late Pieter Hintjens, this project has C4 model. I have not seen any other project where I submitted a PR and maintainer accepted it less than half-hour later, no questions asked. And it works wonderfully; ZeroMQ is live and well.
The word "bazaar" alone should imply discussions, including some haggling and shouting. If no discussions were expected, it should've been called supermarket or something like that.
Bazaar is not a myth at all. The distinction was never 'are patches always merged' but is the development done in public. The issue with Google projects is more about in-group and out-group and if you're not in Google, it's hard to be considered 'in-group.
But even if the complaint was that all projects had this issue; it's just wrong. I've made and received plenty of drive by contributions with no discussion before the PR was made. You can't expect it to be merged any more than you can expect a romantic interest to agree to a date. But that's just interacting with people.
And probably that works well for go and keeps a very clear philosophy and style for the language. It is just the fact they very blatantly misled the community on the scope of possible contributions that frustrates me.
Fuschia does, in all fairness, appear to be considerably more honest on these issues.
There's nothing wrong with an open source being controlled by a company or even existing only to privilege a specific company, but it's important not to mislead open source developers into thinking that a project has different objectives than what it has.
Things like the networking stack can run in user space, and be written in memory safe languages like Rust.
An OS that “can’t” get viruses or be hacked sounds pretty desirable. Cynically it makes things like “jail breaking” a google home much more difficult.
I don’t think these claims hold. It is still written in a memory unsafe language, so exploitation is totally possible. As well, for malicious software you’re just looking for a process handing out high privilege handles.
Fuchsia specifically is looking to be a full-fledged OS, I think, for devices like Chromebooks or similar. I think they expect to get Fuchsia to a place where it can run Android apps natively, then put out an OS that can run native apps, Android apps, etc, all while being tied in to Google's services.
This is definitely some speculation, but that's what I'm seeing so far.
Because the important parts of Fuchsia are all controlled by google, it means they can theoretically keep devices running and up to date indefinitely. They can control the majority of the software while manufactures only need to supply their drivers.
Manufacturers dropping driver support, while bad, isn't the end of the world. It's a much smaller attack vector than the whole kernel never getting updates.
They want to get a Linux free OS.
This is a big difference relative to Linux, and its part of why Linux works so well as a collaboration between competitors. The GPL's copyleft acts as a joint development agreement between equals.
IMO, Fuchsia's model only works well for integration partners that are willing to act as sharecroppers in the ecosystem. That certainly does work for some device manufacturers, but it cannot serve as the foundation of a new Free operating system.
That is not accurate. Fuchsia uses the standard Google CLA:
"You do not surrender ownership of your contribution, and you do not give up any of your rights to use your contribution elsewhere."
You used to not be able to contribute to most GNU projects (maybe you still can't) without assigning copyright ownership to the FSF.
I don't see what practical difference the assignment to Google will make. Without using the words "equality", "between equals" and "sharecropper", can you give an example of something you or I will not be able to do with the code that you or I would have been able to do if the copyright had remained with the contributors?
If you assign your copyright to Google, they may make use of those changes and integrate them into further development and then _not_ release those changes or release those changes under another license. Do you see the practical difference now?
Even were that true today, the difference is that I basically trust the FSF.
With GPL-style licenses, there's an incentive to avoid putting effort into development, and instead undercut other parties who did invest, and then had to share their code.
Sure, but there are plenty of copyleft-licensed projects that also work? This isn't a very convincing argument.
Do they really need to be developer hostile just because Github is owned by Microsoft? I mean seriously, who has time to commit to a project with a random set of tooling.
It's not "developer hostile" to not use Github. Git works everywhere. It might mean that to contribute to an operating system a developer may have to learn how to use something that isn't Github, but honestly if that's a bar to contribution for somebody they probably weren't gonna anyway.
(disclosure: I work on Fuchsia at Google)
sure you can contribute to the Linux kernel pseudonymously. Think of a plausible name, "git commit --signoff", and you're good to go. There's no enforcement of slave names for kernel contributions, it's all just a minimally viable legal fiction.
Chrome -> Make chromium opensource but add spyware that phones home on every second and with new manifest v3 make sure extensions like ublock origin don't work
Andriod -> Make tip of iceberg opensource but force every vendor to use Service and lock down whole ecosystem around it. And make sure there is no way to block ads on youtube for andriod.
Fuchsia -> Initial Stage make people think they are open they are helping community for first 5-10 years. After that implant spyware etc.
Same strategy different form === Modern Polymorphism by Modern Liars.
- The new Edge, Opera, and Brave are based on Chromium
- China has a huge ecosystem of non-Google Android devices
Google does exert strong control of their open source code, and Google is clearly the prime beneficiary of them, but the external world has still leveraged these projects nonetheless
Largely because Google has pushed enough complexity into the browser that maintaining a browser engine is unaffordable, so you use Chrome as is.
Have any of these projects successfully managed to contribute meaningfully, or are they just adding alternative window trimming to chrome?
Chromium homes every second? That seems interesting. It has been a long time since I last used Chromium. Does it also come with Google auth now?
> Make tip of iceberg opensource but force every vendor to use Service and lock down whole ecosystem around it.
If they add Google specific services into core Android is it not worse? Companies like Amazon and a lot of Chinese companies seem to be fine with using just the core Android.
Not necessarily. Take for example push notifications - the push notification client could be part of the OS, with build configurations to specify a server or disable this altogether.
Or, given OS update issues, Google Play Services could be a separate open source project with the Google URLs and keys supplied as build configs.
Sorry/not sorry for the cynicism; I feel it is warranted given what "open source" means on Android. Google talking like they have noble open source ambitions means nothing. They have a lot of amends to make before they begin to seem like a win for society and the industry and they seem to be going in the opposite direction.
You cannot expect they would not do the same bait and switch as with android without a legally binding pledge.
And even then, I bet Sundar will try to wiggle around it.
There is a clear repeating pattern in what he does:
"Google does not store geographic information of AGPS requests" — It did.
"Google will never attempt to block adblock from Android store" — It did.
"Google never shares your cellphone network data" — It did!
Clearly, he lies, and does it very intentionally.
If they do the same with Fuschia, they'd better make it closed sources then.
Is there even a functioning darwin build for Big Sur??
This would probably be a good time to mention https://github.com/zephyrproject-rtos/zephyr.
Chromium is an open source project, but proprietary chrome has the largest browser market share and they like to abuse their position to not play well with standards bodies.
Google can develop Fuchsia. It'll even be cool piece of tech, but I do not for a second believe that contributing to the project would benefit anyone but Google.
If built without API keys, Chromium warns 'Google API keys are missing. Some functionality of Google Chrome will be disabled.' [4] [5]
The APIs used include [6]:
* Calendar API
* Contacts API
* Drive API (Optional)
* Chrome Remote Desktop API
* Chrome Spelling API
* Chrome Suggest API
* Chrome Sync API
* Chrome Translate Element
* Chrome Web Store API
* Chrome OS Hardware ID API (Optional, Chrome OS)
* Device Registration API (Optional, Chrome OS)
* Google Cloud DNS API
* Google Cloud Storage
* Google Cloud Storage JSON API
* Google Maps Geolocation API (Optional)
* Google Maps Time Zone API
* Google Now For Chrome API (Optional)
* Nearby Messages API
* Safe Browsing API
* Speech API
[1] https://git.alpinelinux.org/aports/tree/community/chromium/A...
[2] https://github.com/archlinux/svntogit-packages/blob/packages...
[3] https://git.launchpad.net/~chromium-team/chromium-browser/+g...
[4] https://chromium.googlesource.com/chromium/src/+/9a11dadde80...
[5] https://sources.debian.org/patches/chromium/83.0.4103.116-1~...
* Alpine Linux (community port) - https://git.alpinelinux.org/aports/tree/community/chromium/A...
* Arch Linux (svntogit, AUR) - https://github.com/archlinux/svntogit-packages/blob/1e8f3fe7... - https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chrom...
* Fedora Linux - https://src.fedoraproject.org/rpms/chromium/blob/e78656ce58d...
* Gentoo - https://github.com/gentoo/gentoo/blob/9acf51b665b6f4b5b97edb...
* OpenSuSE - https://build.opensuse.org/package/view_file/openSUSE:Factor...
* Slackware - http://www.slackware.com/~alien/slackbuilds/chromium/build/c...
* Ubuntu, Linux Mint (Canonincal Chromium Snap) - https://git.launchpad.net/~chromium-team/chromium-browser/+g...
[1] https://developers.google.com/terms (specifically: "You will only access (or attempt to access) an API by the means described in the documentation of that API. If Google assigns you developer credentials (e.g. client IDs), you must use them with the applicable APIs. You will not misrepresent or mask either your identity or your API Client's identity when using the APIs or developer accounts." and "Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.")
[2] https://www.chromium.org/developers/how-tos/api-keys (specifically: "Note that the keys you have now acquired are not for distribution purposes and must not be shared with other users.")
Edit: Looks like many don't understand that you have alternatives to Google and you can use them.
Are we talking about Ubuntu, or Android? Because honestly in either case... what would you improve? Ubuntu has updates rolled into GNOME's package management frontend and it's seemed to work well, and Android has decent UX around updates (especially with A/B system partitions) although of course it suffers from vendors not actually releasing updates.
sudo apt install unattended-upgradesAlso, there are large number of "contenders" in the Linux based OS space which may have the UX you want, and if there isn't one this sort of thing tends to be pretty easy to tweak and suggest changes for (unlike in most of Google's OSes.)
This is simply an advertisement for Google, and just like any other advertisement it has nothing to do in technical documentation, especially in a project where they want other companies to contribute.
Google will bait and switch you again, like it did with Android.
Android too was advertised as a nearly "community driven" OS.
Few years down the line, and good sales, and they turn Android into a locked down hell, start to stonewall communications with contributors, throw musings about community governance out of the windows, and break pledge to never block the adblock, nor introduce political censorship on the Android Store.
I get the sense that its advances are probably too low-level for most app developers to care, but that's kind of precisely why I'd love a comment elucidating them a bit.
Edit: For example, the Fuchsia docs list the primary talking points as secure, updatable, inclusive, and pragmatic. How well does it live up to those principles? Will they bring practical benefits? What's exciting/new about what's being done here?
Besides, a greater part of the cruft we have today is rooted in the development model companies adopt that is "develop it, make it work, and ship so not to delay the schedule/budget so much". And that is OK too given that companies just want to develop a product and don't have lots of time, budget and resources... But, as things are in software engineering, that model doesn't produce as good a piece of software as it would with more iterations and refactoring seeking the best software model and implementation. In the end, that results in greater issues issues than what was really needed and the backward compatibility hinders an actual solution. But Fuchsia being meant as a foundation, cannot be developed like that. Like a product that "just works". It would end up being just another bad designed (and chances are, bad implemented too) system based on concepts of the beginnings of computer industry that doesn't necessarily apply for today's systems.
As I've loosely accompanied Fuchsia's development, they've done a lot of early bring up work just so that other parts of the system could be developed. And that is expected because they developed arguably almost everything from scratch. You cant expect ending up with really great system design and implementation just from these first iterations. Then, with the experiences from that, they've done lots of refactorings that refined system's abstractions, APIs and implementation. And, if they are serious about Fuchsia being a good foundational system, they have to solve these left over from the early development.
What's interesting imho is to compare seL4 with zircon. The former is a third generation microkernel. The latter is still a first generation microkernel or, according to google, not a microkernel at all.
It's thus not very interesting from a computer science perspective. In practical terms, I'm sure it'll be better than Linux and IOS/OSX, but that's a very low bar to meet.
Did anyone get it to run on a raspberry pi yet? There has to be _some_ arm support...
Also, I guess the adoption of Fuchsia will be a litmus test of the GPL. Will its possibly technical merits outweight the strength of GPL to avoid fragmentation? I suspect the GPL has served Linux very well in this regard.
Given Google's muscles it will most likely have an impact in the mobile world, but whether it will reach beyond into the area of general computing is less certain.