> No, I provided two specific examples, one quoted and another linked to. None of them happend in the context of wrong comparisons being made.
You made a general statement here ("being known for"). You put a link there indeed with a quoted example and another link.
> Indeed the GrapheneOS community is known for attacking the GNU/Linux mobile with false claims, https://news.ycombinator.com/item?id=45562484.
You have to look at the parent replies of what you link. Read the thead properly, please. Like I said , "What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted". Replies that were literally mentioning GrapheneOS got a reaction. Thats not an unfounded attack. The statements that those other options are less secure are clearly backed up with technical information.
> All their contributions to Linux are carefully verified by many independent parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
That's really not how it works in practice. There is a ridiculius amoumt of code and code changes. Systematic proper exhaustive auditing doesnt happen. Also, you distrust Google and think they are malicious. Google can do their best to hide bad stuff in their code so quick reviews wont notice it. Do you think malware developers write functions called doTheBadStuff()?
> I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
I am not promoting Google. I am just countering your posts critizing Google using bad arguments. Google is a multi-faceted compamy some of the things they do are good for end users, some aren't, most things will be liked by some and disliked by others.
> This takes huge effort and time. One can't rely on it to be secure.
Reading and properly understanding source code also takes huge effort and time. And like I said, if you dont trust the devs, you cant trust function names, variables names and code comments to give a faithful portrayal of functionality anyway. So do you really lose that much if you decompile Java bytecode and mainly just miss naming and comments? It can even be argued it will remove preconceptions and let you read the code with a more open mind. Its a hurdle and annoying for sure, though. I would prefer Google to lower the embargo as well. But, public source availability just isnt the magic silver bullet you think it is.
> The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
You dont need a hard fork for that. If the sideload restriction were to be put in AOSP you can remove that in a soft fork.
> This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
I agree Googles plans arent a good approach. But it isnt a false sense of security either. Registering app IDs and associated public keys is a usefil thing. There are other, begger approaches though, tbat dont have the downsides of what they planned.
> This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
Based on what you were saying and your bad metaphor it is just clear you arent accurately informed or up to date about what the sideloading restrictions will be. The best place to read what the procedures will be is in Google's blog posts and documentation. I am not saying you have to go read that to make a value judgement on the merits. You just need to read that to understand what is actually being talked about. I dont like Google's plans either but I am aware of what they are.
Something being a non-profit doenst automatically mean all posts they write are of good quality. EFF does many good things but I dont see why their posts about things are somehow automatically good and authoritative because of their non-profit model. Best to judge individual posts on their merit.
You made a general statement here ("being known for"). You put a link there indeed with a quoted example and another link.
You have to look at the parent replies of what you link. Read the thead properly, please. Like I said , "What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted". Replies that were literally mentioning GrapheneOS got a reaction. Thats not an unfounded attack. The statements that those other options are less secure are clearly backed up with technical information.> All their contributions to Linux are carefully verified by many independent parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
That's really not how it works in practice. There is a ridiculius amoumt of code and code changes. Systematic proper exhaustive auditing doesnt happen. Also, you distrust Google and think they are malicious. Google can do their best to hide bad stuff in their code so quick reviews wont notice it. Do you think malware developers write functions called doTheBadStuff()?
> I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
I am not promoting Google. I am just countering your posts critizing Google using bad arguments. Google is a multi-faceted compamy some of the things they do are good for end users, some aren't, most things will be liked by some and disliked by others.
> This takes huge effort and time. One can't rely on it to be secure.
Reading and properly understanding source code also takes huge effort and time. And like I said, if you dont trust the devs, you cant trust function names, variables names and code comments to give a faithful portrayal of functionality anyway. So do you really lose that much if you decompile Java bytecode and mainly just miss naming and comments? It can even be argued it will remove preconceptions and let you read the code with a more open mind. Its a hurdle and annoying for sure, though. I would prefer Google to lower the embargo as well. But, public source availability just isnt the magic silver bullet you think it is.
> The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
You dont need a hard fork for that. If the sideload restriction were to be put in AOSP you can remove that in a soft fork.
> This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
I agree Googles plans arent a good approach. But it isnt a false sense of security either. Registering app IDs and associated public keys is a usefil thing. There are other, begger approaches though, tbat dont have the downsides of what they planned.
> This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
Based on what you were saying and your bad metaphor it is just clear you arent accurately informed or up to date about what the sideloading restrictions will be. The best place to read what the procedures will be is in Google's blog posts and documentation. I am not saying you have to go read that to make a value judgement on the merits. You just need to read that to understand what is actually being talked about. I dont like Google's plans either but I am aware of what they are.
Something being a non-profit doenst automatically mean all posts they write are of good quality. EFF does many good things but I dont see why their posts about things are somehow automatically good and authoritative because of their non-profit model. Best to judge individual posts on their merit.