NekkoDroid

doas is relativly simple (a few hundred LOC), especially compared to sudo. The main benefit of run0 over doas is that it isn't a SUID binary, they are similary complex.

But the funny thing is that even with a larger user base, Spotify has NEVER posted a profit

I honestly doubt if you'd isolate Apple Music it'd be any different for them.

Lossless is pointless

I wouldn't say its pointless, but it really doesn't help much considering the quality of your average headset/earpieces.

It’s incredibly easy to fuck your partitions to hell and back, especially through Windows.

Fun fact: Windows won't allow you to delete any EFI partition (that is the only one I know of/tried) unless its through diskpart with a specific override/force option.

But then again, I somehow nuked my recovery partition by accident at some point as well.

bless the drive with a boot loader that doesn’t suck, like Grub

Ah yes, I need a whole separate OS just to boot my actual OS...

I would in no world call GRUB a bootloader that doesn't suck.

Basically. systemd-run was already able to do it, all that really changed is the interface for it. The change to run.c in the patch itself was <400LOC, and the entire patch was <1.4k lines with most being docs, tests and utils for coloring the terminal.

I don’t understand how this is any improvement over pkexec

That has the same problem as sudo: the SUID bit is set for it.

The fact that run0 uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone can systemctl status, but systemctl reboot needs to be in the wheel group) which is why its generally used within systemd already. And it wouldn't surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.

This has already been possible, the patch modifying run.c to be able to do this is not even 400 lines long and was mostly just exposing its feature in a different way. (the entire patch was <1.5k lines, with most being docs, tests and a bit of plumbing for the colored terminal)

As the other comment said, no. But I've had the idea and will to at some point write a edit script (that I can just set EDITOR= to) that would just choose one of the first common editors. That could in theory have a -0 option to run as root (there also probably looking through run0, doas, sudo and su). Not the editor, but doing the editing on a temp file and then copying with root

I don't know, unless I personally allow the admin to have that kinda access to my files I wouldn't really want it. And for that case you can enroll recovery keys (which would need to be manually stored, but still) or a fido token or whatever other supported mechanism there is, its LUKS2 backed encryption after all. Then there is also the possibility to just not encrypt the home directory at all.

1. The attack surface is there either way, this is just functionality repackaged that existed already before (systemd-run, which is calling into PID1)
2. all compression libraries (actually most libraries at this point) are dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)

Sure, the other option is having it tied to an email, which is reliant on your single vendor and is also an easier way to create an army of spam bots. Phone numbers at least are transferable between carriers.