/tech/ - Tech


Mode: Reply

Max message length: 8192


Max file size: 20.00 MB

Max files: 3


(used to delete files and postings)


Remember to follow the rules

(13.31 KB 600x600 systemd.png)
(74.21 KB 900x740 xorg.jpg)
(18.17 KB 226x209 Grill.jpg)
systemd? xorg? Comrade 07/02/2020 (Thu) 19:06:07 No. 3056
I'm no certified Linuggs Eggspert, but I've just continuously heard about systemd and how bad it is over the years from all manner of /g/entoomen, but I still really don't understand it like at all. I essentially "just wanna grill for god's sake" when it comes to using my computer, so I try to stick in the realm of Linux things that just werk. So my question is what's so bad about these things in general I guess? Both for nixlets like myself, as well as for the experts and the whole of Linux? General discussion thread as well for these things.
Nothing is actually bad about it. The maintainer is an autist that made pulseaudio which used to suck really bad but is now alright, so oldfriends who remember how bad pulseaudio used to be are a little sour. Anyway i've been using systemd since gentoo started supporting it and it works fine, no issues and it makes writing new services really easy. Runit might be just as good or better in some ways but who cares, it is all still better than sysvinit.
>>3057 What about OpenRC?
The important thing is that it's open source software (aka, not spyware). Use what you want, or whatever fits your needs in line with that. Everything else is just autists screeching.
systemd is annoying as fuck to use when you want to do anything even remotely advanced with it. /g/ likes to bitch about everything but systemd is unironically annoying as fuck to use if you’re a sysadmin. the syntax for creating services is fucking tedious and autistic.
(3.99 MB 426x284 systemd.gif)
What's bad about systemd is it's quite simply a betrayal of the Unix philosophy of doing one thing and doing it well.
>>3056 i dont have a problem with systemd
>>3064 > doing one thing and doing it well t. system where every utility implements its own idiosyncratic way of handling command line arguments
>>3067 systemd is analogous to a well functioning ML One Party state, and is good
>>3056 >systemd Basically, Linux used to have a bunch of random programs made by random people that did random things that Linux users needed their computers to use. -need to synchronize network time? -need to get an IP address? -need to schedule a program to execute once a week? -need to write system logs somewhere? There are random programs written by random people to do all of that, and they were called by shell scripts that executed them in the original Linux init daemons. What systemd did is, it made a very excellent init daemon that used this trick with sockets that allowed it to start all services at once, making the computer boot really fast. If it had stopped at that, people would have loved it. But instead what it did, is, it started writing replacements for all of these random programs, and bundling them with systemd, and forcing you to use their own homebrewed replacements for all these random programs. Want to use your own program to get an IP address because you don't like the way systemd does it? Then you're at the mercy of the systemd developers to give you an option to use a different program to do it. Don't need to write logs and so you don't want to install a logger? Then you're at the mercy of your distro packagers to carve out the systemd logger into a different package if you don't want it on your computer. If you don't care though then you don't care. >xorg really old display server from the 80's. the way it works is nowhere similar to how modern graphics cards work, so it's a nightmare to write software for it. Also it's really insecure, and suffers from graphical glitches (which are sometimes but not always fixable). BUT, it REQUIRES all programs that use it to be network transparent. (this is technically an oversimplification, but essentially true.) What this means is, you can type "ssh -X" into a program that's running on a server in another building, and the GUI for that program will pop up on your computer as though it is running locally, even though it's running on that distant server. Wayland is trying to clean all that up, but people have problems with it: -mandatory network transparency is gone. it is now entirely up to the whim of the application developer whether he wants to add a feature that lets you run an application remotely, and the vast majority of them will never bother. so it will essentually become impossible to use GUI Linux remotely unless your internet connection is fast enough to stream a live video feed of a computer desktop. -"fragmentation": xorg "tries to do everything", and desktop environments are just thin wrappers around xorg. wayland on the other hand does almost nothing, and puts the onus on the desktop environments to do all the heavy work. this would normally not be a problem, who hates free choice, right? except, all the linux desktop environments have this autism where they have to have their own custom bespoke implementation of everything under the sun ("not invented here syndrome"). and each desktop's programs are tightly integrated with each other, meaning they work like shit with programs from OTHER desktop environments, so it's a pain in the ass to pick and choose which programs you like. this problem will only get worse as even MORE functionality is swallowed up by the desktop environments. -wayland generally being shitty: there's been a big long almost comedic series of fuckups by the wayland devs. it's taking ages and ages to stabilize and gain features. it's insanely restrictive for security reasons (stuff like preventing keyloggers), meaning you lose a lot of functionality you get with Xorg that allows programs like AutoKey and x2x to function. Nvidia refuses to support wayland. there was this huge shitstorm about screen recording being shitty. i think it was completely impossible for a long time (because applications recording the screen is a security hazard), and then when the devs added the feature, they required you to use THEIR program to do it, instead of making it modular so people could write their own screen recording programs. -lack of backwards compatibility: many apps don't support wayland, so to use them you have to run an Xorg server in the background anyways. so by switching to wayland you don't really gain much and you just lose network transparency.
>>3068 Based


no cookies?