271–280 of 334 posts
Earlier quoted context omitted.
As a pseudonymous developer, I fail to see any harm in contributing to projects run by Google in general. Fuchsia is not a monopolist way to exert control over the market (not today at least), it doesn't seem to be explicitly made for evil, and can be forked to let the community steer it.
Since Fuschia seems to be a replacement for Android, why would you think it isn’t a way for Google to exert control over the market? 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.
Earlier quoted context omitted.
If only there were some way to let the phone's owner decide what apps were allowed to run in the background, we could all be happy.
It takes about 15 seconds of googling to find out that yes, the user can decide what apps are allowed to run in the background. It's just that now, it's not "every app by default" and instead "what apps a user selects".
And then maybe "what app a user selects", if the user manages to follow the procedure.
Earlier quoted context omitted.
The real question is, moving forward, if somebody submits a proposal, properly tested, described and discussed with the community that makes a fundamental or deeper change whether that is likely to be accepted or not. 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 i…
I understand the concern. I spent the vast majority of my career not at Google while also involved in open source communities, and I can empathize with this. I think one place we have a leg up here is that we do have documented processes for performing this type of work. It's certainly possible that the outcome of a proposal is rejection, but the hope would be the process does that quickly. We're all human and we don…
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 don't understand the cynicism here. Android's fragmentation was the original sin that lead to fragmentation and the new that we've seen for years, until Google semi-fixed the mess with a) Play Services (short term) and b) Project Treble. 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…
I don't understand the cynicism here. Android's fragmentation was the original sin that lead to fragmentation and the new that we've seen for years, until Google semi-fixed the mess with a) Play Services (short term) and b) Project Treble. 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…
I believe they should have closed source the OS, Android being open-source is the number one reason for its fragmentation. What i dont understand is the "security" logic given by fuchsia. How is Linux less secure ? I dont think anyone starting a new kernel now can guarantee its security to be superior to Linux, because Linux had 25 yrs of evolution to where it is now. That logic is pure garbage, the real reason proba…
I don't understand the cynicism here. Android's fragmentation was the original sin that lead to fragmentation and the new that we've seen for years, until Google semi-fixed the mess with a) Play Services (short term) and b) Project Treble. 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…
I believe they should have closed source the OS, Android being open-source is the number one reason for its fragmentation. What i dont understand is the "security" logic given by fuchsia. How is Linux less secure ? I dont think anyone starting a new kernel now can guarantee its security to be superior to Linux, because Linux had 25 yrs of evolution to where it is now. That logic is pure garbage, the real reason proba…
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.
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.
I am a Linux kernel contributor and former golang and chromium contributor and to be honest the latter experiences makes me leary about contributing to another Google project. 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…
It's kind of unfortunate because existing developers have the privilege of experience with the systems and where they're going that external contributors simply don't have, and it will take a non-trivial amount time for interested parties to develop that knowledge. 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 th…
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.
Earlier quoted context omitted.
And not just that, Android also severely lags behind upgrading its mainline kernels, so you can't even avoid the issues by upstreaming your drivers. You have to fork them. People get mad at vendors that they don't upstream their drivers but there is currently zero benefit in that. Google should reward vendors for that, and maybe we'll start seeing more drivers upstream.
They are working on Kernel Issues, which while not the exact solution to the problem you mentioned but goes a long way https://source.android.com/devices/architecture/kernel/gener...