There is a fairly all-or-nothing-security group of people within the GrapheneOS community. They will defend using a Google device on the claim of enhanced security.
Security is nice, but I’ll take a hit to security if it means I get to support the growth of an ecosystem that respects the user.
lspci -nnk | grep "Kernel driver in use"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.
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.
Same could’ve once been said about a free OS like Linux. Now it is absolutely possible, with the downsides shrinking bit by bit.
The goal of 100% free is one I support. And these people are working to make it possible.
(DBus-based?)
Yeah. iwd even has this issue where it needs you to run a system dbus (presumably so regular users can configure network and the admin can apply dbus polices) even if you do everything as root. No dbus, no function.
Not good.
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).
Really Linux distros just didn’t work with it right out of the box…
From what I’ve read, this is misleading. Default secureboot within Windows will only boot a bootloader signed with Microsoft’s key. Although Microsoft does seem to provide a signing service for signing with their keys, this is at their mercy. Windows made a change that broke booting alternative operating systems unless they use a service that Windows provides to fix it, or disable secureboot.
The “I hate change.” Mindset.
Or maybe it’s extra complexity that often leads to the first recommendation to fixing Linux not booting being “disable secureboot” and how this is an extra hurdle to jump through for new users. As well as increased likelihood of problems, due to secureboot.
Sounds like flatpaks/appimages with extra steps.
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.
The question should by why you’d want to.
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.
From my experience a user account needs to be in the “wheel” group to elevate privileges through sudo. So try that.
Simply: Do the protections against someone taking your computer and installing a malicious program before/as your OS, or a program that has attained root on your machine and installs itself before/as your OS, matter enough to you to justify the increased risk of being locked out of your machine and the effort to set it up and understand it.
If you don’t understand and don’t want to put in the effort to, then my advice would be to leave it off. Its simple, and the likelihood it saves you is probably very miniscule.
I might have been experiencing this issue for the longest time. System fully locks up and is completely unresponsive. Happened on every distro I used.
Last distro I had it on was Artix Linux. Then I tried Alpine and I don’t think I’ve had it happen since.