deleted by creator

1. What graphics card are you using?
2. What is the output of lspci -nnk | grep "Kernel driver in use"
3. What desktop environment?
4. What filesystems for your root drive and mounted drive?
5. Is your mounted drive able to be read, written to, and have programs run on it by your regular user account?

Try setting PROTON_USE_WINED3D=1 %command% as the game launch options for a few different games and launch them.

Try different versions of proton. Also try changing the version of steam to the flatpak version, or to the native version if you are already using flatpak.

Take the whole log and put it a pastebin like pastebin.com. Then reply with the link.

You know exactly the problem I am describing that comes along with trying to game on a non systemd OS, because you have experienced it yourself.

Sorry, but that issue had nothing to do with systemd.

…you are arguing that solving the person’s issue is irrelevant.

Irrelevant to proving. Context.

…then I’m sure you’ll be able to prove that by solving…

Which is why I said: … developed with systemd as the default, assumed, init system.

Next quote I’ll explain more.

…they expect that it will more or less work out of the box at a fundamental level…

Which more has to do with just being setup incorrectly, than missing systemd.

You ever tried gaming on a non systemd OS?

I do. It works.

…I’m sure you’ll be able to prove that by solving this person’s problem for them within Devuan.

Solving a random non-systemd user’s issue is irrelevant, even if we knew a lot more about their setup.

I would look at the proton log of a game that doesn’t work.

How do I create logs of a game I run with Proton?

Proton will create a log file for a particular game, if you set the launch parameter to:

PROTON_LOG=1 %command%

The log file will be created in your home folder with the name scheme steam-$STEAMID.log. For example:

$HOME/steam-379720.log

…will encounter many absurd and esoteric problems, all of which ultimately stem from the fact that the vast majority of linux software is developed with systemd as the default, assumed, init system.

Unless the application in question is directly interacting with systemd, then I believe this is overblown.

Applications largely simply expect certain features to be supported. DNS, for example, could be provided by systemd-resolvd or by dnscrypt-proxy.

This isn’t being built around systemd, this is being built around the expectation of a feature. This feature can be provided by different applications and still function.

In my experience, providing the features expected is far more important than providing specifically the systemd API.

Basically, any Linux OS that doesn’t use systemd should be considered entirely experimental, beyond any software that the OS devs explicitly state they support.

Hard disagree.

I think the init system is more abstracted away from the developers of a game/typical user app than you are implying.

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.

If by “unused” you mean not actively storing data, then the Linux kernel docs disagree.

vm.min_free_kbytes

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.

…including to minors.

I haven’t seen evidence of this.

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

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.

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.

Your needs must be different than mine.

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.

From what I’ve read, no. Though it doesn’t solve the fundamental problem of a root process handling untrusted input from a regular user.

The TTY method is IMO better as it ties privileges to a piece of physical hardware, bypassing the complexities of userspace elevation of privileges.