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.

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.

Good thing almost all flavors of Linux run flawlessly on the x86 models.

5G was mostly about cramming more connections into the spectrum and expanding broadcast range (as well as some other things), but it wasn’t just about node speed on the network.

Heel yaw 👊

Same as you would on MacOS :

• ditch the .deb package because it’s the wrong tool for the job here.
• Squashfs image with encryption
• Set keyring entries and a wrapper script to manage lock/unlock. If you already know the hardware platform of all users, this can even be improved upon

I have no idea why someone would be using Debian packages to distribute something like this though, if that’s the question. Absolutely not going to work well.

Well that engineer is fired.

I thought the last couple moves were the nail in the coffin, but this might be it 🤣

You’ll still be running into frequent issues if you go with R-V, so be warned.

That being said, the Framework R-V board only comes for the 13" format, so you can buy a cheap Framework 13 refurb from their store (fully warranted and everything), and swap the board out for the R-V for $200.

There are other R-V laptops out there, but I think the build quality is nowhere near the Framework, AND if you feel like it sucks, just swap that board back with the one it shipped with.

If you just want the machine to do something only WHEN it detects the TV, that’s a bit different. You want an HDMI or DP switcher. You can just make a tiny listener for DBUS events that launches BPM when it detects the TV coming online.

Simple bash script set to run once your DE is loaded would do it. Detect the TV with xrandr or equivalent, then start Steam in BPM. If not, do nothing.

Yet none of this will reduce Fuckerberg’s cash pile. We need to take that back.

This sounds like some RFK “facts” bullshit. I assume the number is not actually zero, but will wait for the math.

Clop Slop

Also, possibly an STI? “They got the Clop Slop!”

Edit: Actually, I think just “Clop” works

MacOS, phones, off-brand handhelds that run SteamOS…that’s the goal.

It’s not going to be effortless. That’s not really the goal. Anything that uses Google Play Services is going to be a problem still as the underlying service layer just mocks out those API calls a la Waydroid. They’re working more on the FEX stuff from what I’ve seen in the repos.

Having the disks connected externally is the same as having them connected internally

No, it 1000% is not, especially in the case of USB that I used. Even in the way Linux handles everything as a file and target, it is vastly different.

No RAID solution I know of would lose the array on a power outage

Hardware RAID enclosures have batteries on the disk controllers for this very reason. We aren’t talking about those though, we’re talking about software RAID on JBOD, which wouldn’t have those sanity protections. Here’s some random blog explaining deeper.

Honestly I don’t see how interrupt handling would be any different between internally or externally connected devives, except for different buses/protocols handling it differently intrinsicly

See above

Maybe I’m too spolied by using ZFS, but again I don’t think this would actually be a problem

That’s a filesystem solution to a hardware problem, so yes, probably a bit spoiled there, or at least it’s skewing your understanding of what RAID is and how it works. One of the reasons ZFS exists, actually. It’s nice to have nice things though.

Well…don’t overspeak. There WILL eventually be something better, and then people will complain about that as well 🤣

Also software. Literally in the description and options.

There are very few use cases for hardware controllers anymore, and they are on SAN controllers at a massive scale. Every single device you point me to at under $50k is going to be software.

Just wanted to clarify so you understand.