Would you hire a well known electrician who was not bonded and insured? Sometimes it's nice to know there is more than blind trust.

It's FOSS, you're more than welcome to inspect the code yourself

They may not want to do that, just like they may not want to fix their own electrical issues.

You’re sidestepping their point of professionalism and attempting to shove in something else.

The FLOSS license allows you to rely on the community for the verification.

You are, once again, sidestepping their point.

They are saying they want a verified authority, not "the community".

You're already running this on top of Linux. You're already relying on community support, unless you got scammed by Canonical[1] or RedHat^W IBM[2].

[1]: https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu2404Bpf...

[2]: https://en.wikipedia.org/wiki/Dehomag

This isn't about support, this is about trusting the download.

If I get Ubuntu or Debian or download the mainline kernel, I'm trusting specific entities. That's very different from a vague idea that it's open source and hopefully someone checked if this particular random guy on github is putting out legitimate builds.

As I recall, studies have looked into this, and the bystander effect in open source is very real.

"You can view the source on GitHub" is very different than "A knowledgable person has audited the millions of lines of source code and confirmed that nobody added anything shady or stupid." People often don't take the time to comprehend all the source of the things they depend on, especially for large dependencies and/or prototyping-scale projects.

> the bystander effect in open source is very real.

Outside of open source, it was a NYT excuse for the NYPD failing to save Kitty Genovese. The number of witnesses was greatly exaggerated, and the police were called at least once.

I don't think you mean to refer to the bystander effect, because the bystander effect says that the likelihood of intervention goes down as the number of bystanders goes up. You don't seem to be arguing that people are less likely to look at the source because the source is available to more people. More just claiming that people don't look at the source as often as you would like? That open source isn't always perfectly bug and backdoor free? Because I don't know if:

> "A knowledgable person has audited the millions of lines of source code and confirmed that nobody added anything shady or stupid."

Has been claimed about many large pieces of software, proprietary or not.

It's a solvable problem.

1. Fully automated and reproducible builds, bootstrapped through a verifiable chain. GNU Guix has done this: https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

2. Unapologetically, ruthlessly, and tirelessly simplify the software. Suckless.org is a bit on the extreme end, but I continue to be impressed by OpenBSD - it strikes a beautiful balance between clarity and function. They've also meticulously combed the entire source tree around 2010, looking for any signs of the supposed FBI backdoor.

It takes a lot of motivation to do either, let alone both. The financial incentives are elsewhere. But it's been (and being) done.

Disregarding the contributions of some of the biggest players in Linux/OSS has me immediately disregarding your comment.

You can for sure like whatever homegrown community Linux distro you want. It doesn't remove the work those players have done. :)

You've disregarded it so much that you felt compelled to respond.

Whatever track record these companies might have had, doesn't justify their current stance or actions. Hans Reiser also made a pretty darn good filesystem - before he murdered his wife.

Exactly what 'authority' would be sufficient here?

That's for OP to chime in on. I'm just pointing out that the person I'm responding to is missing the point of OPs post entirely.

Alright, just give me 5 minutes to quickly inspect the likely over 100,000,000 lines of code that either go directly into a ROM or are part of the build tooling, and reverse engineer however many binary blobs are involved in the process.

The "you can just read the code" mindset is completely unrealistic, even for software that's orders of magnitudes smaller. If the issue at hand is entering my Google password, I'd rather do it in a ROM built by Google.

Use some LLM which is good at understanding code/coding, maybe supervised by one which is good at reasoning.

Would you hire Electroboom?

Probably not, he might zap himself for a gag and scare the crap out of me.

and then he teaches you about safety around a thousand times more effectively afterward <3

Let's assume you have a ROM straight from Google, and they've actually given you some meaningful promise to support it. How exactly are you running it? Because I'm quite confident that waydroid isn't "bonded and insured", and I rather doubt you're running on top of an operating system that is. So it seems like an odd sticking point.

There's no phone on earth which runs AOSP so it's the same on a real phone, you put a blind trust on the phone manufacturer.

What software are you using that has a parent company that pays out damages to you if it fails?

Because that is the purpose of 'bonded and insured'.

I haven't looked at every EULA and license of every piece of software I use, but I bet that "without warranty" clauses are part of every single one of them.

Different industries have different standard procedures. A huge portion of the world's internet relies on FOSS software, and none of those are insured.

Community reputation is the current _de facto_ standard for consumer-facing software, even for stuff sold by big corporations. There's not much else to rely on.

Just had a conversation about this on a waydroid github issue. The LineageOS X86 image is outdated compared to also open source Bliss OS' Android 12.

/? Android play store APK GitHub actions

It looks like Android Emulator has the most current version of Android that will run on x86?