There's some time limit before having to re input it.
Inputting a password multiple times into sudo has downsides too. Larger window for attackers to do something like: add a directory to your path, which has a fake sudo in it, and capture your password.
Yes. Memory allocated, but not written to, still counts toward your limit, unlike in overcommit modes 0 or 1.
The default is to hope that not enough applications on the system cash out on their memory and force the system OOM. You get more efficient use of memory, but I don't like this approach.
And as a bonus, if you use overcommit 2, you get access to vm.admin_reserve_kbytes which allows you to reserve memory only for admin users. Quite nice.
Unless you have the vm.overcommit_memory sysctl set to 2, and your overcommit is set to less than your system memory.
Then, when an application requests more memory than you have available, it will just get an error instead of needing to be killed by OOM when it attempts to use the memory at a later time.
Only that Valve doesn't require an ID to open cases in counterstrike, which makes it easier for a minor to open cases (Which I would consider a massive violation of privacy for them to do, as well as a tasty target for data leaks).
I wouldn't call not adding ID checks "pushing" gambling to minors
Simple solution is to use cryptsetup to encrypt it, forget the key, and optionally overwrite the first megabyte or so of the disk (where the LUKS header is).
If such a project were to become compromised (the way XZ-Utils was), it would eventually spread to Ventoy.
What a lot of people don't know is that the XZ attack entirely relied on binary blobs: Partially in the repo as binary test files, and partially in only the github release (binary).
If someone actually built it from source, they weren't vulnerable. So contrary to some, it wasn't a vulnerability that was in plain view that somehow passed volunteer review.
This is why allowing binary data in open-source repos should be heavily frowned upon.
I'm fairly sure the complexity of flatpak/appimage solutions are far more than the static linking of a binary (at least on non-glibc systems). Its often a single flag (Ex: -static) that builds the DLLs into the binary, not a whole container and namespace.
Because the application working is more important than the downsides in my case. Its quite useful for an application which hasn't been updated in a long time, will never receive updates again, or doesn't work in my nonstandard environment.
I have had older applications fail to function due to DLL hell.
You can modify the keybinds in software too. You would need to change your console keymap (TTY) and your desktop environment keybindings. Programmable keyboard is most likely easier though.
I played around with it and changed both to just use F1 = tty1 and so on, without requiring CTRL+ALT.
I press one button combination and have root without ever entering a password. I press a similar combination and go back. Not sure how this is a pain in the ass.
All I do is have agetty --autologin root tty2 linux run as a service. It launches on startup, and I just hit CTRL + ALT + F2 if I ever need a root shell.
All its doing is just auto logging-in as root on TTY2.
The nosuid mount option disables this behavior per mount. Just be sure you don't use suid binaries.
Example: sudo or doas. I replaced those with switching to a tty with an already open root account on startup. Generally faster and (for me) more secure (you need physical access to get to the tty).
Irrelevant to the point. I was pointing out the value proposition. Certain things exist for a minority of people. I view the 'reason why" as valuable, even if only a minority care about it.
Inputting a password multiple times into sudo has downsides too. Larger window for attackers to do something like: add a directory to your path, which has a fake sudo in it, and capture your password.