The bugs aren’t necessarily the browsers fault.

I must have one of those units oh my god

Someone needs to sell replicas (forgive the pun) of these.

It's like a toaster oven, but it toasts time.

The M.2 form factor isn't that conducive to having lots of them, since they're on the board and need large connectors and physical standoffs. They're also a pain in the ass to install because they lie flat, close to the board, so you're likely to have to remove a bunch of shit to get to them. This is why I've never cared about and mostly hated every "tool-less" M.2 latching mechanism cooked up by the motherboard manufacturers: I already have a screwdriver because I needed to remove my GPU and my ethernet card and the stupid motherboard "armor" to even get at the damn slots.

SATA was a cabling nightmare, sure, but cables let you relocate bulk somewhere else in the case, so you can bunch all the connectors up on the board.

Frankly, given that most advertised M.2 speeds are not sustained or even hit most of the time, I could deal with some slower speeds due to cable length if it meant I could mount my SSDs anywhere but underneath my triple slot GPU.

> I could deal with some slower speeds due to cable length

Observing server mainboards reveals many PCIe 5.0 connectors for cables to attach PCIe-SSDs looking similar to SATA ones.

Agree that M.2 is fiddly. PCIE cards with M.2 sockets are nice nice for desktops and servers, then one can just unplug it to do operations.

Users buying Macs to put BSD on them are less likely to buy things in the Mac App Store.

This is more or less how a lot of it works on macOS via the “Transparency, Consent, and Control” subsystem. Even non-sandboxed apps cannot just go rooting around my Desktop without the OS throwing a popup up asking me if it’s ok.

Keychain ACLs on macOS use the codesigning requirement of the executable requesting the secret.

It’s almost as if the user/group/everyone permission model developed for time sharing mainframes isn’t sufficient anymore for absolutely everything anymore.

Zero disagreement but GNOME I don't think is the one in a position to fix this as I'm not aware of any implementation of the better application level security model that doesn't require a lot of kernel support.

For some reason the OS can manage to ask me about what windows I want to screen share, but not about if i want to share secrets between apps or not? I don't see how this require kernel support - it just needs people recognising it as a problem that is wanting to spend the time actually solving it.

I mean kinda yeah. Literally any program running as your user can connect to dbus, grab your secrets and slurp your home directory. Flatpak 'solves' this issue by putting the program in a sandbox that can't talk directly to dbus and proxies the messages with a filter.

The thing you need the kernel for is to attach meaningful identities to programs and restrict them without needing to sandbox them. And there is a ready made solution to this, one that dbus is already aware of and can use natively. But on systems where it's available a lot of users immediately disable it—SELinux.

There's precious little evidence of these sort of things being problems for linux desktop users, in practice.

Because no one cares about 3% of desktop users, when much juicier and larger targets also exist.

Keychain access can be limited with ACLs, enforced with code signing signatures as well on iOS and more so on macOS where the “keychain” can still be the older file based type.

There are secrets I cannot export from my system keychain without disabling SIP on my Mac.

I believe the sole author is doing finals for their last year of university at the moment.

Aging Wheels did some tests on YouTube and it’s heavily affected by aerodynamics.