@r000t i'd wait for the systemd apologists to arrive, but they usually are on the fEdibLoCk servers.. :)

@bonifartius @r000t Systemd is a piece of shit, as we don't have enough with kernel bugs and vulnerabilities and now we have to deal with that piece of shit.

@r000t @bonifartius @jrballesteros05 we don't have to deal with it. I don't use it, for instance. there're distributions without it, no problem. it's the same useless as it was when it appeared.

@iron_bug @r000t @bonifartius In the desktop, there is not problem because there are alternatives, actually I use Artixlinux with s6. But in the corporate the options are less.

@r000t @bonifartius @jrballesteros05 there's no difference between desktop and server. Linux is well scalable, always was. we used gentoo on one work, it was very well "corporate". no difference, really. I would say that developer builds with fresh software are more rare than standard builds for servers without need of daily updates.

@iron_bug @r000t @bonifartius When I work I tried to replace Debian with Devuan but we use Proxmox a lot and currently is not possible to install Proxmox in Devuan. If you see the main cloud providers (This could be another debate), you barely see non-systemd options. That's why I mean and many companies go "standard".

In my case I don't mind to use qemu in cli but I don't take those choices in the company I work.

My concern is that more apps have hard depends on systemd.

@jrballesteros05 @iron_bug

i think it's very hard to find companies who don't use a systemd distribution after even debian switched. many people like this "unification" and don't see the bad deal they make with using systemd: bugs non existent before (like the current systemd-crash-bug), shitty reimplementations of >30 year old modular software systems (systemd-resolved is utter crap, even the local-dnsmasq-solution was better) and exponential raise in linking dependencies, because things now use systemd includes everywhere. we've had IPC via sane text based protocols (with the binary exception if it made sense). now we have crazy dbus constructs and people trying to reimplement windows.

systemd proponents say ".service files are so easy to write!" when in reality you only have to write the PID to a file and add a signal handler to your program if it needs to shutdown gracefully. hell, build a "myprogramctl" tool which talks to the daemon via IPC, also fine. i think 95% of the people don't know, and probably don't care because "it's old!", how these things work anymore.

if your software needs fancy systemd features to run correctly, it's broken. if you need the automagick-restart-feature, it's broken. systemd is enabling laziness/bad software in exchange for brittle, inscrutable complexity.

@r000t

@r000t @bonifartius @jrballesteros05 I can't understand why people bother about start scripts. especially on ready-for-noobs Debian-like distros. do they ever had to write any? I'm sure they didn't. I keep my own build of a distro and even I rarely write startup scripts by hand because they're already written by many people before me. and it's not a problem to write a script for my own software if I need it. so this argument is absoultely nullable.
adding PID to somewhere is not a "graceful shutdown". it's killing a process, generally. every application had its own way of graceful exit with cleaning up its resourtces. there's no single and universal way to do it.

and no software needs useless-d features. there's no any special features in it that could ever be needed on Linux. it's a lump of terrible code.
Follow

@iron_bug

> adding PID to somewhere is not a "graceful shutdown". it's killing a process, generally. every application had its own way of graceful exit with cleaning up its resourtces. there's no single and universal way to do it.

sure you still need a signal handler for gradeful shutdown :) you can also add a myprogramctl tool which does IPC (but please not dbus :D) with the daemon. whatever fits best!

> and no software needs useless-d features. there's no any special features in it that could ever be needed on Linux. it's a lump of terrible code.

i truly dread the day when linus steps down. they already tried to cancel him. i fear after he's gone, the floodgates are open for all the crappy ideas like kdbus etc. :/

@r000t @jrballesteros05

@r000t @bonifartius @jrballesteros05 I think till that day I will have my fork of kernel :)
sooner or later this should happen: kernel must split to coprorate and opensource community branches. because there's no need in that thousands of changes coprorations shove in its code. these fat and useless features are only needed by some coprorations. and let them go to hell with this.
I think, the kernel must be purified of any proprietary software support and it should remain simple and slim, without tons of code that nobody even needed.

@iron_bug @r000t @bonifartius I read an article when Linus mentioned the kernel was bloated, and then by companies pressure he had to take his words back. There is a libre version of Linux, used by 100% free software distros. That's why I support ideas like this mntmn.com/reform/ because I think I should start buying hardware made to support 100% free software.

@bonifartius @iron_bug @r000t It's not 100% free/libre because HDMI needs proprietary blobs to work but I guess it's the first step. They even have a Mastodon account.

@iron_bug
I noticed that too a few major releases ago when running make oldconfig. There's shit that's only there for Google servers and I'm here left wondering why Google can't add a single 'patch' command to their build scripts
@bonifartius @jrballesteros05

@r000t @bonifartius @jrballesteros05 exactly. why the master branch of a generic kernel contains patches that are used by 1.5 people once in eternity.
Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.