

I really like to get some feedback. Have fun everyone!
Remove the “MILITARY-GRADE” stuff. It doesn’t relay any useful information and has been used as a phrase in countless crappy products.
I really like to get some feedback. Have fun everyone!
Remove the “MILITARY-GRADE” stuff. It doesn’t relay any useful information and has been used as a phrase in countless crappy products.
Different variation of the Sorites Paradox.
Gay Breakfast is a legendary name.
The solution is to have stronger privacy laws.
Many people have the power to make certain privacy attacks impossible right now. I consider making that change better for those people than adding a law which can’t stop the behavior, but just adds a negative incentive.
I wouldn’t wait around for the law to prosecute MITM attacks, I would use end to end encryption.
Choosing an esoteric system for yourself is a good way for a free people to protect their privacy, but it won’t scale.
If this is referencing using a barely-used system as a privacy or security protection, then I would regard that as bad protection.
Everyone using GrapheneOS would be a net security upgrade. All the protections in place wouldn’t just fade away now that Facebook wants to spy on that OS. They’re still in place; Facebook’s job is still harder than it otherwise would be.
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.
And there’s the typical non-answer…
There wasn’t any question asked in the thread I replied to.
“just use fstab”
What I actually said was:
You can just run a mount command for your drive on startup as root.
Which is significant because its less verbose than the fstab
a helpful answer would read something like; To auto mount drives on Bazzite open terminal and type…
Its not a given that someone would know how to automount disks in X desktop environment. One can’t provide a step-by-step process on something they do not know.
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.
All fstab does is provide data for the mount
command. Typically your OS just runs something like mount -a
on boot and it mounts all the filesystems as listed in the fstab.
You can just run a mount command for your drive on startup as root. It would be doing essentially the same thing and its quite simple even for a new CLI user.
(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.
…thus denying the artists revenue.
This assumes they would otherwise pay for it, and that they measurably harmed the artist’s revenue. Those aren’t a given.
Until such a time as we come up with a new word…
Use of copyrighted material without permission and possible deprivation of revenue. It doesn’t need to be a single word.
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).
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.