Expanding Fuchsia's open source model
opensource.googleblog.com
opensource.googleblog.com
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)?
It is as black and white as, "Chinese market."
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!)
GSI isn't specifically for Pixel 1 and 2, but they can use those, just like every other device whose OEM have abandonned them, since it is a generic image.
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.
As a user, however, it is severely locked down. Installing apps from 3rd party app store was okay-ish years ago. Nowadays, Android just frightens you as much as possible so that you don't install 3rd party apps. The battery thing that has already been mentioned is an issue as well. Nowadays you can't even use an alternate Camera app, you have to stick to whatever OEM gave you.
Thank you for the clarification! I haven't had the extra time to tinker with the latest devices since it's a bit outside my day to day. That's a bit more nuanced and it's good to hear from someone who develops on the platform regularly.
And then maybe "what app a user selects", if the user manages to follow the procedure.
The only way to run an app non-stop is to have a persistent notification. And even then, apps are killed off left and right by the likes of Samsung. See https://dontkillmyapp.com for more details
> 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.
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.
Also, please tell me the ":wq" was unintentional.
Apple and Microsoft both have something similar but with their own website, and AFAIK there's no way to change the url on iOS.
That is what I look for in "open source". If I cannot edit, re-compile and re-install, much of the value to me of "open source" is lost.
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.
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.
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.
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.
One of the cases that people cite for Go rejecting the community outright is the modules work. My perspective is that could've been handled better, but I didn't have a stake in that. But then I look at the error handling proposals, all rejected, including the ones originating from Googlers. And the iteration on generics, which has been reworked several times due to dissatisfaction expressed by community members of all experience levels. I think it's fair to say that even though there are deciders of what happens, they hold themselves to the same standard.
I hope you'll consider at least taking a look as a hobbyist. It's a large system, so both lots of opportunity for contribution and lots to learn. I think many of us are very eager to work with people outside the team, especially as many strive for more social interaction in general, and I know many of us are individually looking forward to welcoming external contributions. Certainly we can never find out if the process works if no one tries.
edit: redundancies
It's hard for an open source project started (or dominated) by a single company to shake the appearance of being insular. At this point I believe Kubernetes has major contributors from various companies, but I still mentally think of it as Google because, among other things, a bunch of the infrastructure is still Google so it feels very much like Google has dominant control. The dominant company will need to actively drum up interest and try to convince external contributors to take up the work to make it look less lop-sided.
I don't mean this as an attack on Google — getting good community governance is hard; I've also been on the dominant company side on other projects (generally not great at fostering a good external community). I believe it takes extra concerted effort.
I guess, but my point is that many of the rejected ones are attached with Google names. Also it's unclear to me that the reason for not remembering is due to who proposes and implements the things -- it seems more likely that this is due to a huge volume of proposals over a long span of time. WRT generics, it's also very clear that community feedback is being incorporated.
So this is why I think the issue is really rejection. Nobody's really upset about how error reporting or generics are being handled because it's clear that community feedback is being honored, and it's clear that the core team is holding themselves to the same standard the community is being held to. Those two properties aren't as clear in the packaging situation.
That's why I think Fuchsia having a documented community process and also having been working within that process for some time is important. We're already holding ourselves to the standard we're asking of the community.
> I believe it takes extra concerted effort.
This is absolutely true, and it's why I'm here trying to make sure that folks know there are people involved in the project who care greatly about its open nature.
Many people have pointed out that the existence of open source doesn't necessarily make the project accessible for contribution, and that's I think the more difficult problem to solve in the short-to-medium-term.
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.
>16. Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.
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.
It might sound like I'm being pernicious but I think fuchsia is great tech and I want it to succeed. I feel compelled to cheer you on in seeing the bazaar model as very real and good thing to pursue.
On the topic of more community engagement... despite Zircon not being an outright microkernel, maybe it's still appropriate for someone in the Fuchsia community to submit a talk to the FOSDEM 21 Microkernel devroom
When I said "in this regard", the intent was to signal that "bazaar" explicitly doesn't mean an anarchic situation where all change is accepted. It's maybe more anarchic than the cathedral model, but it's controlled anarchy.
The reality is that most projects fall somewhere between the two models. The people most heavily invested in the projects tend to drive change, and this is sometimes at the behest of the community. That doesn't automatically make the project a cathedral.
Similarly, while Google controls the direction and funds the development of Fuchsia, our development process (which we publish on fuchsia.dev in the Governance section) is very much bazaar-like. This is difficult to see because we haven't been open about our processes, and we haven't engaged externally with developers. To that extent, we've been very much "cathedral". This expanded model is us inviting folks to join us in the bazaar.
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?
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.
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.
As an open source contributor, it’s very unfulfilling and disappointing to find out you’re essentially an unpaid contributor to a company project.
I think we really need to divorce "profit" from "open source". OSS is great because we can contribute our own ideas to it, because we can learn from it, because we can form communities around it. It's also useful because it's a vector for entrepreneurship. Edit: why should these be mutually exclusive properties?
It's fair to point out that it can be a vector for exploiting unpaid labor. But that's an accessibility issue that exists already. For example, it's easy to tell folks interested in the field to "do open source work" if they want to get a job in the field. If you're a low-income single parent, this doesn't make CS more accessible, it's a sick joke. Even without profit, open source isn't this bastion of opportunity that we sometimes like to think it is.
You make an excellent point that it's hard to learn large new systems. But it's not impossible. Indeed, it's possible to make super meaningful contributions to the system in "limited time", starting with net zero knowledge: https://blog.quarkslab.com/playing-around-with-the-fuchsia-o.... To that end, I have to disagree that we're the kind of project that outsiders can't meaningfully contribute to.
I've addressed the point of community consensus elsewhere. All I can say here is that I personally owe my career to open source, and I'm therefore committed to helping others do the same. We opened the project to communicate with people. My personal goal is to do this and help as many people as possible succeed professionally through this vector.
Personally I would rather contribute to a GPL licensed project, because if big companies try to profit of it, they will also have to release their changes. Those could improve the project, and now the community does no longer have to do themselves -> Community devs get payed back in development time that they would have to spend themselves.
With permissively licensed projects (or commercially dual-licensed), where big companies are allowed to just take and improve it internally without giving anything back to the community, a community dev would pretty much be an unpaid developer for those companies.
Strictly speaking, they only have to release their changes to people they distribute their product to. It's convenient to keep it entirely open, but not a requirement.
I agree that folks should contribute code to places they feel comfortable in any case. As I mentioned in GP, if you separate out pay, there are other reasons to work on OSS, and these motivations can coexist.
It makes sense you are not happy to do unpaid internship, but the only thing it shows is that you are not the target audience.
Unpaid internships are definitely questioned. You're very much incorrect here.
> 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.
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.
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/c...
https://docs.github.com/en/free-pro-team@latest/github/creat...
https://docs.gitlab.com/ee/user/project/code_owners.html
It's not meant to be a place for developer bios. If for no other reason than one developer could appear in many OWNERS files scattered throughout a repo, or in multiple repos, and keeping the bio current across all of them would be a nightmare.
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.
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.
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.
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.
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.")
If I fork one of the aforementioned Chromium packages, is my fork covered under that agreement? Is my right to build and produce my own binaries from the original unmodified source still intact?
But, I also don't see anyone ever talk about this, and I think it's worth people being aware.
Edit: Looks like many don't understand that you have alternatives to Google and you can use them.
Google has a search monopoly effective enough that they can solely make or break anyone who relies on search. They have enough dominance in the market that if they were to choose to delete something from search results, it could utterly devastate all sorts of players in the market who cannot at all get by on the tiny fraction of traffic they get from other sources.
This is not the case for all areas of search, but it's the case for enough of them that the concerns about Google's monopoly are valid.
> it could utterly devastate all sorts of players in the market
That's the risk you take if you bank your entire business off of your search rank on Google. You should diversify accordingly.
This fuzziness you speak of has lead to massive overreach in the past, and it needs to stop.
Google's search dominance is under threat from competition, but they do enough anti-competitive stuff to keep their dominance that it's an issue.
Maybe a big step would be just to block Google from paying Apple and others to make Google the default. I don't know. Probably the more impactful would be to separate the Google search business from the Android stuff. The benefit Google has from tying those two together makes it really so much harder for competition to gain ground.
If you want a pretty neutral balanced view of the issues of anti-trust, Planet Money did a good little series on how overreach in the past led to excessive caution and underreaction now.
https://www.npr.org/sections/money/2019/03/20/704426033/anti...
I don't see how this answers my statement. Of course they can, it's their platform. I'm sure MS pushes their new browser on bing. There's another thread open today where people have listed a ton of alternates so one can de-google. I did it 2 years ago, it's been fine. Apple Maps is much better than it used to be, bing is better than it used to be. Lots of email options.
For iOS/Android, I'm not seeing a problem just because they are popular. Is there some specific legislation you would like passed which would interfere and most likely overreach into their companies?
Like you said, it's not cut and dry because there isn't a monopoly. If an upstart company came along and wanted to make a new mobileOS, I wish them well. If Google or Apple did something wrong to interfere with their success, bring a suit at that time with specific claims.
Since "Google is not a monopoly" I am sure no one would have a problem with this behavior... :)
Google does NOT have a monopoly on searching for the sorts of products you buy on Amazon. In that particular exceptional case, a lot of people do go straight to Amazon for the search.
Google's monopoly is on other sorts of searching.
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.
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?
GCC itself has definitely been inhibited by the copyright assignment. There have been a few different ports that were not upstreamed specifically because of the CLA. AVR32 and C6000 come to mind off the top of my head.
Can you think of a single instance in which code written by an individual contributor not bound by an employment contract was prevented from being incorporated into a project that required copyright be assigned to a central entity?
I have read multiple accounts of open-source contributors who have successfully negotiated when being hired that copyright to any code written on their own time on the own hardware will remain with them (so as not to complicate their contributions to open-source projects).
Wikipedia has to worry about the same thing, BTW: contributors who upload text whose copyright is owned by some entity who never consented to the upload, and they have policies in procedures in place to correct it when it happens.
It's not like CLA's are the only obstacle to employees contributing to the open-source projects. In fact, you might say that the main purpose of a CLA is to surface copyright-ownership problems early, when the cost of correcting them is lower.
Intel and ARM both collaborate on GCC and Linux all the time while being fierce competitors. Google, Canonical, Red Hat, etc all contribute to Linux while being fierce competitors.
But the only companies that contribute to Android and ChromeOS are device partners, and the partner contributions are far more limited in scope.
Basically I trust the FSF to stand by the spirit of open source. I don't trust that out of Google.
(It doesn't help that the FSF's processes for copyright assignment are incredibly clunky. It was a big deal when they started accepting scanned papers in 2012, for example.)
1: TBH it's hard to tease apart the cultural aspects from the legal. Most GNU projects were roughly "We'll post a tarball once in a while and not have public CVS" when I first started getting involved in OSS; projects with public CVS it was a lot easier to tell if someone was already was working on something, particularly for people as shy as I was back then; I got the impression that the "proper" thing to do would be to introduce yourself on the mailing list, propose the idea, &c. and then start working on a patch.
My particular combination of low-confidence and misanthropy steered me away from such projects.
And that's with trust that the FSFs goals on copyright align with mine.
I don't trust Google to do what I want with my assigned copyright.
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?
You have not said anything about the difference between a BSD-like license with copyright remaining with the contributors versus BSD-like license with copyright assigned to Google.
In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference, then why would Google require the contribution in the first place?
edit: If this ( https://cla.developers.google.com/about/google-individual ) is the CLA in question, then you additionally agree on a patent grant to Google and those those Google distributes it to. So if Samsung takes the code and distributes it to other customers those customers and Samsung are not covered by the same grant? Why is this all centered on Google? Why is not simply a general patent grant as part of the submission to anyone receiving the code?
The difference isn't relevant 99% of the time, but it comes up if the maintainership of a work tries to re-license the work. Works without assigned ownership cannot practically be re-licensed, as you'd have to get individual consent from all owning parties.
This came up a lot when GPLv3 was introduced — many projects wanted to migrate from GPLv2 to GPLv3, but couldn't, because they never acquired legal ownership of contributed code, and so didn't have the right to re-license the contributors' code.
Bingo! Google will relicense Fuchsia to OEMs etc. under new terms if they want to include Google services.
Google establishes with the public a warranty- and guarantee-free use license. If someone feels they've been harmed by the software, they're prevented by the open source license from suing Google, but they're (more importantly) also giving up their right to sue the individual contributors.
At the same time, vendors want to be able to hold suppliers accountable for support and warranty on products that are supplied. Permitting sublicensing allows Google to sell the software to OEMs and vendors with support agreements that allow those vendors to hold Google responsible for that support (rather than the individual contributors).
There's a lot of complaint about the sublicensing going on, but I think most vendors aren't going to build systems where they can't get support, and I don't think contributors actually want to be liable under tort law for the code they provided for free.
Then again, maybe the objection is to giving code to Google that Google can profit from. I guess that's fair, but you don't _have_ to contribute code and you're also not prevented from sublicensing and trying to turn a profit yourself.
(edit: typo)
Yeah I understand this. Hence there _is_ a difference and maybe one I don't prefer. I understand why Google would want this, but maybe I view Google's inability to relicense my code as a feature and not a bug.
In any case, I think the people involved in this back and forth essentially understand the state of things. I only seems some of us disagree on whether we should care. If people want to sign CLA's with Google that's their prerogative. If they understand what they're doing, more power to them. I don't like that Google has special preference over other actors, but that's just me.
edit:
> This came up a lot when GPLv3 was introduced — many projects wanted to migrate from GPLv2 to GPLv3, but couldn't, because they never acquired legal ownership of contributed code, and so didn't have the right to re-license the contributors' code.
Sure there are a lot of people who didn't like that, but maybe those who contributed their code under the GPLv2 never would have done so if they knew it would change to GPLv3 (not that he's more important than others, but Torvalds seems to fall in this camp)? Their wishes should be respected. Besides in those specific cases the projects could have avoided it by only accepting code licensed as "GPLv2 or later" so a CLA wasn't really required in that case anyway (though obviously that only applies to this specific GPLv2 -> GPLv3 case and not more generally).
Imagine a country with direct democracy, where a 100% consensus of all citizens is required for any law to be passed. Now imagine that a single citizen of that country decides to go live in the mountains, out of contact with the rest of the country, but still legally alive and legally a citizen, and therefore legally a "required" vote. The legislative process grinds to a halt!
This is, of course, why no government is run that way. And it's equally silly to run a FOSS project that way. Even if literally everybody likes some change, just one contributor failing to get in contact means you're stuck without the ability to make the change.
Maybe yes and maybe no.
> ...The legislative process grinds to a halt!
You're being a bit overly dramatic. The software development process can continue just as it did before, they just can't retroactively change the license on code they do not own. It is true that maybe the project might die partially due to a lack of adoption due to people not liking the license, but he project may die for many other reasons as well. Also the project isn't gone anyway. It continues just as before.
> This is, of course, why no government is run that way. And it's equally silly to run a FOSS project that way. Even if literally everybody likes some change, just one contributor failing to get in contact means you're stuck without the ability to make the change.
There is one government, but there are many competing software projects. If one goes into decline it's not the end of the world. Besides the software project is not gone, it's still there. The fact that there are so many popular projects without the ability to change their licenses shows that the model can work just fine.
Look if you want to start a project and require a CLA be my guest. If you want to join a project with a CLA, go ahead. Just be aware that CLA's will deter some contributors. Weigh these trade-offs however you wish.
This is false. The GPL does not require you to make source code available to anybody who asks, only those you distribute the software too (in source or binary form).
If you modify a GPL'ed application and then distribute that to 3 friends, those friends have the right to ask for the (modified) source code. Nobody else does.
GPLv2 is even more stringent, if you do not accompany the source with the object than any third party with or without access to the object is entitled to request the source code. (This is a short and incomplete summary of section 3).
You're incorrect about GPLv2. Section 3 states that if you distribute the work "in object code or executable form", you have to do one of 3 possible things:
1. accompany the object/executable with machine readable code
2. accompany the object/executable with a written offer of access to machine readable code
3. accompany the object/executable with the same information you received with the object/executable. (This option is only available for non-commercial distribution)
> b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
GPLv3 has transitivity not GPLv2, but GPLv2 doesn't need it because it already specified any 3rd party.
Edit: Reread what you wrote, GPLv3 b (i.e. written offers) has transitivity, I do think that GPLv3 d does not (but does distribute the source simultaneously with the binary in some sense).
But you only have to give the offer to whomever you give the object/executable to. So you tell them "you can get the source from foo://bar.baz/phaf" ... this just has to be a publically accessible address with no additional authentication or authorization. You are not required to announce this in any way other than in the written offer which accompanies the object/executable.
So, although in theory any third party has access to the source code, you are not being required to put it in a publically visible location, merely a publically accessible one.
[EDIT: I was saying that GPLv3 also does not have transitivity,so we agree about that ]
[EDIT: I admit that I am misleading in my final sentence ... yes, any third party has the right to access the source code, but you are not required to notify "any third party" of this fact, only those you gave the object/executable to. ]
However, Google need not provide the source to people that they do not distribute the code to (well obviously there are differences between e.g. GPLv2 and GPLv3, but whatever this isn't a legal analysis). For example, if Google uses it internally they may not need to release the source to anyone at all. They're all important points that more people need to understand, but they aren't really the ones that I was making in this thread and none of them are really specific to Google vs. other companies.
In particular, it seems that the license terms of Linux caused Android to become "as open as it needs to be, and no more open".
I expect that Fucshia will take the same path as Android, as opposed to the path of core Linux.
Even were that true today, the difference is that I basically trust the FSF.
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."
See (5) and (6) in the open source definition: no discrimination against persons or groups, and no discrimination against fields of endeavor.
If you're unwilling to relinquish control, no open source license is going to be good enough. At best you might scare some risk-adverse companies away from using it, but there are still going to be a lot of people you dislike who can use your software to nefarious ends.
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.
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.
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.
But the thing is the way Fuchsia's implementation of the 'capability security model' is done. The capabilities a process (or, a 'component' in Fuchsia's model) use/consume are explicitly given to it. And this scheme is implemented in a way that is easy to see and account for where/from these capabilities are going to/from. An process can do nothing that is not provided by the capabilities it got during creation.
Of course, components might be buggy/malicious and leak capabilities. But the security holes bottleneck in this capability routing scheme, so even with buggy/malicious components, it's much easier to audit and fix. And from an attacker perspective, it's much harder to reach a component given the routing path of capabilities that it's received.
In Fuschia's case it will be like that but the exploitation either gives you access to that driver's capabilities, or simply that driver is giving out handles with permissions insufficiently removed from them.
It will be cool to see a full system audit of capabilities, but I don't think that analysis exists yet.
Yes, and then you would have to own a component in some route that received the driver exposed capability. Either way, the tight sandoxing and compartmentalization of functionality make things difficult.
There's an example of analysis here: https://blog.quarkslab.com/playing-around-with-the-fuchsia-o...
(disclosure: i work on fuchsia, big rust fanboy)
(edited to make explicit other half)
They want to get a Linux free OS.
If I was a pseudonymous developer, I would probably not go through that.
As for forking, that option only becomes practical if the community version can muster adequate resources versus the Google controlled version.
Forking can be practical without competing for the same use case.
However that seek unlikely given that there are many actors who would like to exclude Google services from their devices and Google is at the same existential risk if that happens as they were when they introduced Android.
And yes forking can be practical, but it very often isn’t, partially in the case of a very large corporately sponsored codebase. So ‘we can just fork it’ doesn’t mitigate the concerns.
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.
You can lie about your name, I suppose, but strictly speaking you're violating the stated rules and could face having your code rejected or removed: "code from anonymous (or pseudonymous) contributors will not be accepted". (https://www.kernel.org/doc/html/latest/process/1.Intro.html)
And since you mentioned GNU, would you be able to pull the same trick on a GNU project? Don't they require you to sign away your copyright, with paperwork? So you wouldn't be able to contribute to (some portions of) GNU/Linux pseudonymously.
It's a common way that pseudonym aficionados refer to their civil names. Gallows humor.
> You can lie about your name, I suppose, but strictly speaking you're violating the stated rules and could face having your code rejected or removed: "code from anonymous (or pseudonymous) contributors will not be accepted"
And yet it won't be rejected or removed. The preceding sentence is "It is imperative that all code contributed to the kernel be legitimately free software." If you don't betray the project, nobody will make it a problem.
Fair enough. That verbiage made me think you were a "freeman on the land" or something.
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?
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.
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.
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.
It’s also worth noting that the Fuchsia equivalent would be Zircon, which is a relatively small part of the Fuchsia project (and will only get smaller in proportion).
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.
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.
So Google own the kernel under a license that lets them add secret sauce.
* - 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.
* 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.
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.
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.
- 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?
Nowhere else in the world is there a market where Android is free from Google's iron grip, outside of tech enthusiast/hacker circles.
You could count those, but I don't consider them relevant the same way I don't consider those cheap chinese TV boxes, smart watches, fridges, and other appliances to be relevant here (they could just as well be using Windows 98)
What I did say is that Chromium was based on WebKit and then a fork of WebKit, blink.
Let’s not credit Google for Chromium without recognizing that it was Apple’s open source work that made it possible.
To suggest that WebKit isn’t open makes no sense at all. It may not have a governance model or development processes people like, but the fact that the source is open and has been used to build competitor products and has been forked means that it is unquestionably open source.
It seems like you agree with the person you originally responded to, who noted that Chromium is an open source browser, and Safari is not.
Yes, they did:
“WebKit is sometimes a bit closed until it reaches embargo that Apple sets.”
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.
I think this is the greater challenge now for Google. A system being very well designed and implemented only attracts enthusiasts and people like that with free time. Even the 'better security' aspect doesn't convince the majority of developers. For general usage in IoT and primarily in smartphone/tablet devices, Google would have to:
1. Port ART together with all of Android's public facing APIs to Fuchsia. Evidence says they are doing it, at least for Android ART. As people say, "there's no way without Android app compatibility"...
2. Convince OEMs to switch to Fuchsia platform instead of Linux. That I believe is under way with project Treble, or at least has a path for a possible solution. And Fuchsia's architecture solving Linux big pain points would be a strong argument in convincing OEMs to switch. Woundn't be easy though as drivers would have to be (re)developed or some bridge would have to be built.
With above done, developers would have a push to develop targeting Fuchsia natively. Then Fuchsia's better system architecture together with security advantages would be more strongly perceived by end developers.
If Google managed to develop some new fancy end product on top of Fuchsia that got traction, then that process would be a lot easier for 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-upgradesNot if you just want automatic security updates? The package is part of the server task, and defaults to installing security updates. It does not install other updates, and does not automatically reboot.
> Auto-updating security updates should be the default if you run servers in the wild.
It pretty much is (for Ubuntu server)?
Also, 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.)
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.
If they do the same with Fuschia, they'd better make it closed sources then.
We can have open source OSs on top of Android that build with a specific service set. Sort of how Ubuntu builds over Debian.
Also worth noting that when someone does build on top of AOSP, they are at the mercy of Google’s roadmap for the closed versions of Android.
The fact that this is possible is something I have commented about on this very forum for years. It is trivial for the Amazons and Huaweis of the world to build an API like this that supports Google's FCM, Amazon's ADM, etc. and provide a library for developers to use that will let them easily deploy push-enabled apps on devices across all ecosystems.
“The OpenPush project aims to create ... Development is still ongoing.”
Doesn’t sound like it from the website.
The repo says it is unfinished, and commits seem to have stopped a year ago. It looks like it has been abandoned.
Has it been used in production somewhere?
I wouldn't be surprised if Amazon has their own internal implementation of the same thing to use in their Android apps.
You speculate that Amazon may have an internal framework for this, but so what? Even if your guess was correct, that’s not AOSP, and it’s not open.
Your statement that AOSP ‘already does’ this simply isn’t true.
It seems like you don’t distinguish between things that are possible in principle, and things that are actually true.
This is unlike iOS, which is the real broken platform.
Also who said anything about Tor? What relevance does it have?
Of course any open source project can have features added in private. Those are not part of the platform.
It’s certainly not true to say those features already exist in the platform, as you falsely tried to claim upthread.
It also doesn’t mean you can add them to the platform if the maintainers don’t accept them.
As I say, you are confusing what is possible in some other reality with what is actually true.
Now you say it doesn’t make even sense to put this feature in the platform, confirming that you were lying when you said it already was part of the platform.
Why are you talking about iOS?
> Now you say it doesn’t make even sense to put this feature in the platform
Of course it doesn't make sense to build that library into the platform.
> Why are you talking about iOS?
iOS doesn't provide the ability to make this possible, which is probably why you are so confused.
You pointed me to an abandoned codebase. When I pointed out that it seemed incomplete you said:
“It is already usable.” ( https://news.ycombinator.com/item?id=25361587 )
Do you still claim it’s already usable? If not, why did you say it is?
You say: “Of course it doesn't make sense to build that library into the platform.”
I agree, but nobody is talking about building that library into the platform. The comment you are replying to is talking about the feature, not that library:
“Now you say it doesn’t make even sense to put this feature in the platform”
Do you think it makes sense to put this feature into the platform?
How many times do I have to tell you that it doesn't?
Do you think AOSP should have a framework specifically for uploading photos to a photo sharing service in the background? That is another standard feature for smartphones. Of course not, it just needs the ability to support uploading photos to multiple services, and people can build libraries on top of the platform to make it easier. This is notably another thing that is not possible on iOS.
> You pointed me to an abandoned codebase.
And another one that isn't abandoned.
> Do you still claim it’s already usable? If not, why did you say it is?
No. I assumed it was because they had already announced it. Any developer who would like it can simply finish the library themselves.
We seem to be in agreement except for your wacky ideas of how much should be in the platform vs. how much should be built on top of the platform.
You said it was already usable after I said that the link you posted showed that it was incomplete.
I.e: You made a claim that you didn’t know was true, but stated it as fact, even when you were asked to confirm it.
This is known as lying - saying something is true, when you don’t know it is true.
In this case I didn’t even call you on it - I just asked whether you were sure it was usable.
Your response was to immediately reply with a false statement.
A true answer would have been: “I don’t know, but I assume so because it has been announced.”
Because you do this, what you say simply cannot be taken at face value.
If this were true, you’d be able to link to an example of me intentionally stating a falsehood.
> after he finally found a single time that I lied
This is the single time you have confessed to lying.
"Telegram" / "Push service: tap to learn more" (tapping opens https://github.com/Telegram-FOSS-Team/Telegram-FOSS/blob/mas...)
"Signal" / "Background connection enabled"
Both are serving the same purpose, for different apps. Even before we get to network connections and servers (the things that might make sense to be proprietary), without Google's ecosystem the local side has a bad UX and requires hacks.
Is there even a functioning darwin build for Big Sur??
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.
This would probably be a good time to mention https://github.com/zephyrproject-rtos/zephyr.
"Fuchsia is an open source effort to create a production-grade operating system that prioritizes security, updatability, and performance. Fuchsia is a foundation for developers to create long-lasting products and experiences across a broad range of devices."
"The Zephyr ProjectTM strives to deliver the best-in-class RTOS for connected resource-constrained devices, built to be secure and safe."
This sounds a lot like the same to me - Fuchsia is perhaps more a general OS, but I would think that Zephyr can solve the same problems as Fuchsia.
What I like about Zephyr is that it is developed in the open and not in some google lab.
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.
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.
Did anyone get it to run on a raspberry pi yet? There has to be _some_ arm support...
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.
And not, in fact, open source. Due to the non-GPL license, every single Android device out there is effectively running a closed-source fork of AOSP.
I had an old Samsung device automatically install TikTok when I powered it on after sitting in a drawer for years. TikTok didn't even exist when I bought the phone, yet someone with more control over my device than me sold the remote access (they gave themselves, without my consent) to TikTok.
Of course this is not a new development, but the proprietary BS and Google's increasingly evil actions over the past decade really highlight how much of a problem that is. Trusting Fuchsia is just repeating that mistake.
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.
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
fetch --nohooks chromium && cd src
./build/install-build-deps.sh
gclient runhooks
gn gen out/Default
autoninja -C out/Default chrome
(disclosure: I work on Fuchsia at Google)
The best part is the cross-references: try clicking on any identifier in https://cs.opensource.google/fuchsia/fuchsia/+/master:src/li... for instance.
I'm not sure how rendering works, I'm only a happy user :-)