Okay, as I said before, you had a technical issue you couldn’t fix for one specific use-case. Jumping down to a less efficient (which this is) abstract to solve for that problem isn’t a good solution, ESPECIALLY if you’re self-hosting as you describe.

If I go to a store to buy hot dogs, and they’re out of hot dogs, I wouldn’t buy hamburgers to cut in half and try to pass it off as hot dogs just because they fit in a hot dog bun.

You’re providing misguided information. You shouldn’t be ranked higher for that.

How is this anything like entitlement?

This has zero to do with anything. Please explain why you wouldn’t be able to expand storage otherwise, and how this solution helps with that. You’re aware of LVM, btrfs, or ZFS?

That’s just…a bad idea then. You have every opportunity to not do that, and you’re using a solution like this as a patch to solve for other issues you had. Not a good use-case.

I’m aware, but why would you self-host an S3-compatible storage implementation when you can host what this tool does via NFS or NBD? Makes no sense.

This sounds like a very expensive way to abstract away access to S3-type files, unless I’m missing something. Sounds pretty easy to make a very costly mistake here.

Might be sort of useful on R2 since they don’t charge for ingress/egress.

Horrible thumbnail. It’s Redfin’s data expert with a PhD in Economics discussing Land Value Tax. Kind of interesting if you’re unfamiliar.

Yeah, this should just be a series of build arguments.

Look up elsewhere about the reputation Brother has with compatibility. Personal experience: never fails. That’s their jam.

Trust me. It is.

This has more details: https://wiki.gnome.org/Projects/GnomeKeyring/SecurityFAQ

The security model skews towards convenience versus absolute security, meaning automation is it’s goal, not perfect security. They use a reasonable amount of security to protect unauthorized access, meaning untrusted apps can’t access keys by default, and container apps only have selective access. AppArmor is supposed to be handling some DBUS interactions in the background to prevent any old app from grabbing everything, but again, automation is the purpose here.

If you don’t have a reasonably trusted system, then sure, it’s about as secure as any other password manager. I remember reading some time ago there was a plan to make a global framework for trusted application.accessnto things like this, but it was shot down for being “oppressive” in the same way as Microsoft’s trust app mess.

Ideally there would be an advanced mode where each app is granted access to specific keys, and that interaction is controlled by the user. This would never be the default obviously as the user interaction would be an insane annoyance to people who don’t care.

It’s enough to build a pattern match and scan against it being elsewhere. Surely they did at least much to find all these packages with malware.

They should have some sort of static code scanners on the repos at rest at this point that look for certain patterns and issue warnings.

Apparently they can’t do beaver dams correctly. Why this person chose to accept this slop is confusing.

Hilarious

VMs were not viable yet in 2001 for an entire underlying OS stack like this in the way you might be thinking on end-user hardware. I think VMWare was just coming out, and Xen wasn’t released until a bit later.

F this dude

If there is a single SGI device still in use on the planet, I would be shocked.