The Linux Thread - The Autist's OS of Choice

[Considered HARMful]

So who uses Linux for vidya? what are your experiences so far, yay or nay?

Mostly yay, there's an increasing number of games for linux (mostly low to mid-tier indies, but also some AAAs) and many non-natively supported games run well on Proton. Check out www.protondb.com.

re: Gentoo sperging
I attest that it's not that of a high-maintenance system that many seem to paint it as such. Though it's quite likely that any first-time linux user will stumble around for some time due to information overload, until they settle themselves and feel comfortable. Then it's ez as pie and very amenable to non-standard shit for which the binary distros are less friendly.

Why is systemd shit? I've read a lot of arguments on both sides, but I still don't really follow them.

Adding to what was already said in this thread, systemd is a complex piece of software in a critical space (e.g. init system) for the whole OS. You want your software in such places to be as simple as possible and easy to inspect because bugs will be fatal. Systemd has a bad track record on OS-killing bugs due to its init handling responsibilities.

Old-school init systems of Unix are dumb as a box of rocks and That's A Good Thing™. They basically spawn processes with fork() and wait until any child process dies and than wait()s for it to clean up system resources.

I had never, ever heard that one. How many other secret man pages that don't correspond to a program are lurking out there?

Section 3 manpages provide documentation for C, does that count?

Manpages are divided into sections. Check out "man man", notice the difference between "man printf" and "man 3 printf". Dive into /usr/share/man

[EDIT]
Check out also related commands "apropos" and "whatis"

 

[Never Scored]

systemd doesn't manage network connections (unless they swallowed another project while I wasn't looking). NetworkManager does this on distros like Ubuntu. The normal Ubuntu or other "foolproof" desktop distro user would not even know if he was using systemd or not. It does not change anything for them.

The issue as I understand it isn't anything readily apparent to the average end user. The issue is the codebase getting so large and convoluted those who have the knowledge to look into such things do not have the ability to alert end users of potential problems.

I made an assumption that most distros that use systemd made use of networkd in some fashion. If that is incorrect, I stand corrected, but I believe my explanation of the issue many have with systemd is correct, is it not?

*Edit* I just checked out the services that run on startup by default on my Manjaro install, and systemd-networkd.service is indeed enabled for whatever that's worth.

 

[byuu]

I made an assumption that most distros that use systemd made use of networkd in some fashion. If that is incorrect, I stand corrected, but I believe my explanation of the issue many have with systemd is correct, is it not?

networkd is more the analogue of configuring your network solely with init scripts. It just brings up interfaces and maybe spawn wpa_supplicant. To configure your network that way you need to hand-edit files like with init scripts.
Almost all desktop distros use NetworkManager instead, which allows users to set their network settings through a GUI and does not care what init you use.

There seems to be that weird misconception that systemd makes desktop Linux easier or something. But at its core systemd is an init, a service manager, and a system logger. Nothing that an end-user needs to directly tinker with. It swallowed some desktop-oriented technologies like dbus, PolicyKit and ConsoleKit. But all of these existed before systemd and can still be made to run without systemd.

 

[Pinochet Was Right]

I like systemd if only because it allows me to make GNUtards go ballistic by telling them you should either call it Linux or GNU/systemd/Linux since systemd is arguably more essential in TYOOL2020.

 

[byuu]

I like systemd if only because it allows me to make GNUtards go ballistic by telling them you should either call it Linux or GNU/systemd/Linux since systemd is arguably more essential in TYOOL2020.

Akshually it wouldn't change anything for GNUtards since the old init, udev, dbus, etc. weren't GNU projects either.

 

[cecograph]

Adding to what was already said in this thread, systemd is a complex piece of software in a critical space (e.g. init system) for the whole OS. You want your software in such places to be as simple as possible and easy to inspect because bugs will be fatal. Systemd has a bad track record on OS-killing bugs due to its init handling responsibilities.

Old-school init systems of Unix are dumb as a box of rocks and That's A Good Thing™. They basically spawn processes with fork() and wait until any child process dies and than wait()s for it to clean up system resources.

A buggy init process is definitely bad, and I've heard that Poettering's other big project pulseaudio was pretty unstable historically.

As for it being dumb as a box of rocks, what about service supervision and managing their dependencies, and do you have opinions on other init systems (openRC, upstart, or shepherd on GUIX)? I'm on NixOS, which is closest to GUIX, and I'd really love it if they came up with their own init system. It uses systemd, but no-one on Nix writes service files themselves. All configuration is done in the nix language, and the service files are then generated. It'd be cool if Nix just used its own init instead.

I know another complaint was that log files are in binary, which might be annoying for some sysadmin's preferred workflow.

 

[AmpleApricots]

To add what has been said, systemd is a massive piece of software that does away with standards in favor of doing things it's own way (which is not always necessarily bad, but in the case of systemd makes it seem like the developers really, really want to lock you into systemd and not make you use anything else, even with it) on source level, it also has it's components intertwined in a weird yarnball way of programming that makes it kinda difficult to fork specific functionality off. The systemd developers also have a shitty attitude of "our way or the highway" or claiming that obvious bugs are "works as intended". They also seem directionless sometimes, just implementing some new systemd concept which is radically different and then just kinda abandoning it halfway through and moving on to the next big idea. All this makes a lot more sense if you look at the company who's mainly behind systemd, which is Red Hat. Red Hat has tried to turn the Linux software landscape into a shitty knockoff Windows it can sell service contracts to and lock corporate customers in for a while now. I doubt that will get better with them being owned by IBM. Most folks here are probably to young to remember but when IBM still was the overreaching mammoth in the PC space, they loved to lock their customers in with proprietary stuff and applied that walled garden concept before the term even existed so what Red Hat has been doing to the Linux landscape in the last years is extremely up their alley.

The joke is that living systemd free isn't even difficult and it does nothing better simpler components couldn't do also. I had been using systemd for a while a few years ago to get my own perspective and found personally that "ease of use" factor skin deep, as you had to learn to do everything the systemd way and good luck if you wanted to do something just slightly different from what the software engineers intended. On top of that, and I don't know if that is still the case, that "systemd way" could change on a moments notice. Then there were the bugs and fundamental security issues which apparently they're still struggling with and which I doubt will get any better by adding complexity. I simply did not see the gain and there aren't any if you're not content with just copy-pasting configuration files, which I guess is what made it so attractive to some.

 

[Considered HARMful]

A buggy init process is definitely bad, and I've heard that Poettering's other big project pulseaudio was pretty unstable historically.

Oh right, I forgot about that. For many years pulseaudio was known as "that thing which causes you to not have sound on Ubuntu".

As for it being dumb as a box of rocks, what about service supervision and managing their dependencies, and do you have opinions on other init systems (openRC, upstart, or shepherd on GUIX)? I'm on NixOS, which is closest to GUIX, and I'd really love it if they came up with their own init system. It uses systemd, but no-one on Nix writes service files themselves. All configuration is done in the nix language, and the service files are then generated. It'd be cool if Nix just used its own init instead.

I use openRC on my gentoo boxes. I didn't yet have the necessity to write my own initscripts for any custom services, so I can't speak if the openRC grants any special features. A long time ago I had written one old-school bash initscripts for one of my jobs. Nothing especially terrific, but I can recognize where the criticisms from systemd camp come from: the amount of boilerplate code is significant.

In professional setting, I had to write a set of systemd service files for a suite of VoIP network services. I think it's OK.

Frankly, besides the mess that was the systemd and the history of buggy crap spewed by Poettering, I find the .service approach to specifying initial service handling superior to bash scripts. But keep in mind that I'm retarded: I prefer C++ to C, think OOP is eh OK I guess (and .service file approach reeks of OOP) and dislike bash scripting despite being more skilled in it than in Python (which sux big time as a programming language BTW).

I know another complaint was that log files are in binary, which might be annoying for some sysadmin's preferred workflow.

Binary log files are retarded beyond any recognition. I don't know if they (systemd developers) improved their format and error recovery, but I vividly remember a bugreport when one of the maintainers plainly told the user to delete the logfiles after some failure (don't remember if it was software or hardware related) made them unrecoverable.

I mean, if my system fails, I'd really, really, really like to get these logs to investigate what went wrong. Well, screw you I guess.

 

[cecograph]

Oh, one other bit of drama I remember reading about last year was systemd breaking "nohup" and "screen", something about it terminating all user processes on logout, rather than just sending SIGHUP. Here's a debian bug report.

I've never been burned by it, but that might be because NixOS has "KillUserProcesses = no" by default, and I was on Gentoo before then.

The accusation was that this completely broke 30 years of expected behaviour, was possibly POSIX non-compliant, and that Poeterring mostly ignored complaints.

 

[⠠⠠⠅⠑⠋⠋⠁⠇⠎ ⠠⠠⠊⠎ ⠠⠠⠁ ⠠⠠⠋⠁⠛]

systemd doesn't manage network connections (unless they swallowed another project while I wasn't looking). NetworkManager does this on distros like Ubuntu. The normal Ubuntu or other "foolproof" desktop distro user would not even know if he was using systemd or not. It does not change anything for them.

Ohhohohohoh how wrong you are. They even interfere in name resolution now.

I am not someone who wanks over 'The Cathedral and the Bazaar'. I hate systemd not because it is part of a conspiracy by Red Hat (IBM) to destroy the Linux ecosystem, or because of the totally unusable binary log files that someone else called out, but because Poettering is an incompetent sick freak who insists on using the foothold his disgusting abomination already has to constantly expand into new areas with more and more badly written code until you have less control over core parts of the system like networking than you have on Windows. He should have his fingernails pulled out with rusty pliers.

Binary log files are retarded beyond any recognition. I don't know if they (systemd developers) improved their format and error recovery, but I vividly remember a bugreport when one of the maintainers plainly told the user to delete the logfiles after some failure (don't remember if it was software or hardware related) made them unrecoverable.

I mean, if my system fails, I'd really, really, really like to get these logs to investigate what went wrong. Well, screw you I guess.

Exactly. Any supposed 'benefit' from the binary logs can be obtained by logging to a database, natively or via a syslog daemon. And there's a better chance of being able to read that data even if a failure occurs, because database software is mostly written by competent people.

 

[Basil II]

Ohhohohohoh how wrong you are. They even interfere in name resolution now.

I am not someone who wanks over 'The Cathedral and the Bazaar'. I hate systemd not because it is part of a conspiracy by Red Hat (IBM) to destroy the Linux ecosystem, or because of the totally unusable binary log files that someone else called out, but because Poettering is an incompetent sick freak who insists on using the foothold his disgusting abomination already has to constantly expand into new areas with more and more badly written code until you have less control over core parts of the system like networking than you have on Windows. He should have his fingernails pulled out with rusty pliers.

wow this is pretty hateful towards the disabled.

 

[teriyakiburns]

networkd is more the analogue of configuring your network solely with init scripts. It just brings up interfaces and maybe spawn wpa_supplicant. To configure your network that way you need to hand-edit files like with init scripts.
Almost all desktop distros use NetworkManager instead, which allows users to set their network settings through a GUI and does not care what init you use.

There seems to be that weird misconception that systemd makes desktop Linux easier or something. But at its core systemd is an init, a service manager, and a system logger. Nothing that an end-user needs to directly tinker with. It swallowed some desktop-oriented technologies like dbus, PolicyKit and ConsoleKit. But all of these existed before systemd and can still be made to run without systemd.

The problem is that these were all independent systems that could be swapped out with alternatives (for performance or security reasons, say), but now they're rolled into systemd and can't be easily separated out, and they're all under the control of WONTFIX poettering, who still refuses to address major bugs in both systemd and pulseaudio.

systemd controls the messaging bus between processes, which has nothing to do with an init and was formerly an independentsystem that could be replaced. it manages user logins with systemd-logind, which is a hard dependency for gnome, where previously login management was an independent system that could easily be replaced. it has rolled up udev, which populates /dev and manages device control and configuration; it replaces human readable text logs with a completely opaque binary logging daemon. it configures dns with an insecure default (because an init should be configuring your dns i guess). it replaces the user's choice of cron with its own internal cron daemon. it's probably two majors away from having its own mail server, and current versions have replaced the home directory with a "portable" encrypted home container (systemd-homed) that fucks up ssh management, reduces overall system manageability, and creates a whole new bunch of security holes that didn't exist before that massive extra surface was opened up for attack. it is expanding to become the entire system.

A putative init manager should not be fucking with your crons and your home directory, and it should not be a hard dependency for your desktop environment. it should start and stop daemons, and nothing more.

tl;dr systemd is a bloated, expansive, bug-ridden mess of code that takes on multiple responsibilities from formerly independent subsystems and daemons, reduces user choice, increases potential attack vectors, and largely exists to satisfy the ego of a very, very bad software developer, who is still salty that Linus yelled at him for breaking userspace with his shit code.

 

[Pinochet Was Right]

Akshually it wouldn't change anything for GNUtards since the old init, udev, dbus, etc. weren't GNU projects either.

Or even X.

 

[cecograph]

Akshually it wouldn't change anything for GNUtards since the old init, udev, dbus, etc. weren't GNU projects either.

Guix is a GNU project, and it has its own init and service manager.

I love NixOS, on which Guix is based, and if I liked Guile/Scheme enough and was enough of a GNUtard, I'd probably go with Guix.

 

[AmpleApricots]

There's this strange misconception that inits/service managers/supervisors need to hold the hands of daemons all the time which in practice is rarely necessary. The weirdest thing that grew out of that is this dependency-based design where daemons are started in an exact order in relation to in which way they're dependant on each others functionality, which is plain unnecessary for most well-written daemons I ever encountered. If you write a daemon that is dependent on a network connection to do it's thing for example, you should have code in there that it can handle a missing network connection in a configurable way or at least gracefully anyways, mediating at these levels should IMO not be the job of any service manager or init system. I feel this functionality just exists to keep the hastily scripted rube goldberg contraptions of some sysadmins and distro-maintainers alive. If you want to see something funny look at most of gentoos openrc init scripts or what the maintainer did to runit and openrc. (all the same guy)

 

[Basil II]

I'd just like to interject for a moment. What you're referring to as systemd, is in fact, Soy/systemd, or as I've recently taken to calling it, Soy plus systemd. systemd is not an init system unto itself, but rather another free creation of a fully narcissistic german made useless by eating Soy.

 

[gasthekikes1488]

The weirdest thing that grew out of that is this dependency-based design where daemons are started in an exact order in relation to in which way they're dependant on each others functionality

Fortunately one of the original design goals of systemd was to make most explicit dependencies and ordering unnecessary.

which is plain unnecessary for most well-written daemons I ever encountered.

This is patently false, the vast majority of Unix daemons have mandatory dependencies. A GNU/Linux system that doesn’t resolve dependencies between services in some way will fail to boot. Try it out.

If you write a daemon that is dependent on a network connection to do it's thing for example, you should have code in there that it can handle a missing network connection in a configurable way or at least gracefully anyways

There is no way a program can tell if networking has been set up as intended in the general case. Networking services always require explicit ordering to function securely and properly.
As regards your general point: sure, let’s reimplement the same functionality over and over again thousands of times and introduce countless unfixable race conditions. No, actually, dependency handling is the job of the service manager. A service with unsupervised dependencies almost always can be hijacked.
There is a lot to dislike about systemd, within its ever-expanding scope, but the core ideas are sound and significantly reduce the system maintenance burden (and almost none of them is original). In particular, people who think that unsupervised rc.d scripts running with non-deterministic state are a viable alternative to anything have certainly lost their minds. That said, if you do have a decent service manager, you can likely implement the good parts of systemd yourself, in particular socket and D-Bus activation (the latter is especially important, because D-Bus uses a broken fallback mechanism resulting in unfixable race conditions).

 

[Dante Alighieri]

I believe the logic goes something like this: In order for the software to remain free as in freedom(You are free to know what the program does, modify what it does and distriubute your new version), you have to be able to look at the code and know what it's doing. Therefore each piece of software and its code should be kept concise and simple and essentially serve one purpose, enabling any individual with the know-how to check out the code and determine if the software is doing anything they don't want it to do. Linux distros are generally built in this way. The kernel(Linux), the window manager, the web browser, the compilers(gnu) etc are all separate pieces of software made by separate groups and the code for each is available to anyone who wants it, unlike say, Windows where everything is a part of Windows by default and everything is made by Microsoft and you cannot look at the code.

Systemd has evolved to the point where it manages most of your distro's essential services like network connections and it has gotten so big and complicated it's difficult for a single individual or even group of individuals to take a look at the code and make sure it isn't doing anything untoward, such as, say, creating a backdoor for the NSA. This goes against the traditional Linux/Open Source/GNU philosophy.

On the flipside, systemd does so much that the average end user has to do a lot less fucking around to make their computer work. I can remember using Ubuntu back in the early 2000s, for example, and even though it was aimed at novices, there were often things that just didn't work and I'd have to scour the internet looking for a way to get my wireless connection working. That's something I don't really have to do today thanks to systemd managing things like network connections.

Today, most distros are totally dependent on systemd and many pieces of open source software rely on it, causing more controversy because it gives its developers a disproportionate amount of control over the open source community. What if say, the systemd developers decided that the developer of another piece of open source software which relies on systemd is problematic, and thus they purposely break compatibility? Who would stop them? Traditionally you'd just fork the software in that situation, but systemd is so big now, you'd need a whole team of people to do that.

Someone who knows more can correct or add, but I think I have the major points in there.

That's a really good explanation, thank you.

 

[Dick Justice]

So who uses Linux for vidya? what are your experiences so far, yay or nay?

I am personally waiting till Easy Anti Cheat can be implemented (somehow) then I can make the jump for good. There are some games that I play every now and use EAC for cheat protection.

Between native ports, proton, playonlinux, and lutris I'm going to say that depending on your target genres:
50-75% of games work right out of the box, so easy your grandma could do it.
5-15% of games simply do not work satisfactorily
the remainder can be made to work with effort ranging from trivial to heraclean, but if the solution to the problem isn't immediately obvious when you encounter the problem half the solution is going to be figuring out what terms to websearch.
If vidya is what you want to do your best bet is honestly either to dualboot or setup a second desktop running headless and use something like steam streaming to play anything that doesn't run easily.

One thing worth noting that I don't think gets enough airtime is this very weird situation we've somehow found ourselves in where running older games, particularly late 90s-late 00s is very often much easier on *nix because of the ease and flexibility of mimicking the games expected host environment in wine. For example I tried to play Max Payne on windows once and after much hassle with compatibility mode and pcgw patches it seemed to work except for no audio in cutscenes. A few years later I couldn't get it to work at all. I tried running it in wine and the whole thing was clicking one button to change the host environment to windows xp and then running the executable. If you've ever had to fuck with CPU affinity or force single-core rendering to get a game to work your experience will probably be improved by switching to *nix. It's crazy to think that POSIX is becoming the optimal way to preserve old windows games. Now that I think about it emulators tend to be easier as well.

E:

I believe the logic goes something like this: In order for the software to remain free as in freedom(You are free to know what the program does, modify what it does and distriubute your new version), you have to be able to look at the code and know what it's doing. Therefore each piece of software and its code should be kept concise and simple and essentially serve one purpose, enabling any individual with the know-how to check out the code and determine if the software is doing anything they don't want it to do. Linux distros are generally built in this way. The kernel(Linux), the window manager, the web browser, the compilers(gnu) etc are all separate pieces of software made by separate groups and the code for each is available to anyone who wants it, unlike say, Windows where everything is a part of Windows by default and everything is made by Microsoft and you cannot look at the code.

I can't speak to systemd, but what you're referring to is the "Unix philosophy". Exact definitions naturally vary, but I think it can mostly be boiled down to the bullet points:

• Write tools that do one thing and do it well. Expect the output of your tool to be the input to some as of yet unknown tool.
• Output to text because it's the universal interface.
• Worse is better, perfect is the enemy of good. Design tools that can be deployed, tested, and iterated quickly. Be willing to sacrifice functionality for simplicity. Don't be afraid to throw out and rewrite code that's not working well. Avoid feature creep.

The overarching goal, imo is to be able to quickly and easily create functional software and rapidly improve it through iteration.

 

[Jamal McGucci]

I've been having FPS drops while playing games when I get a notifications. Does this happen to anyone else on KDE and arch?