Before I get to the heart of the matter, I should first say that I am not only very happy with Slackware, I am particularly sort of proud we didn't go systemd, which is why I'm choosing to post here rather than in General or elsewhere. I even took some pride in that Debian nearly imploded over it and that the more serious like BSD and Gentoo stood up against it, too.

Anyway let me make it perfectly clear that I don't think was ever rabid in my opposition to systemd, but I saw no upside for me (I couldn't care less about faster boot times) and saw lots of downsides, not the least of which I've since come to see as just a tad reactionary, "It isn't Unix-like!!!" and I am not at all looking forward to a time, if ever, that Slackware adopts it or anything like it. It's just that I take more pride in challenging my assumptions to try to properly assess reality and not devolve into an "echo chamber" from being intellectually lazy.

The purpose of this thread is purely to understand better what developers face and what, if anything, any manner of altered init system might provide for them which means ultimately to us all, since apparently there is more than just faster boot times to systemd's credit.

Today I watched a video of a fascinating 2019 symposium titled "The Tragedy of SystemD" and frankly it shook up some of my negative assumptions and I'd like to know more about where Linux, in general, may be headed, and what possible value there actually might be to get a more realistic assessment than I have apparently had so far.

Whatever your POV I think most will find this sober symposium interesting if not enlightening. I'd like to see comments on the video, the speaker and his points in his talk. I sincerely hope my title is appropriate since surely we are all adult enough to resist flame fests, right?

Anyway here it is ====>>> https://www.youtube.com/watch?v=o_AIw9bGogo

Thanks in advance for any comments.

Oh great, systemd again.
http://0pointer.de/blog/projects/the-biggest-myths.html:

I'm not expert on systemd (yet, I should add because I need to learn it sooner or later - recently I was asked about it in a job interview) but one thing I really dislike about it are binary logs. I just think text is better but that's it.

I trust our maintainer to continue to develop Slackware using a sane approach. I have an ambivalent opinion about the issue(that shall not be named). Whatever Mr. Volkerding and the Team decides to do is fine with me.

2 members found this post helpful.

Well, average_user, that has been a negative aspect I thought was endemic as well but what the video made me aware of is that due to the way it actually functions transport of logs is some easier and more efficient. This may only be useful in larger networks such as in Enterprise, but I'd like to know more about that.

Also, I can't help but comment on your opener, "Oh great, systemd again.". Now that hopefully only embers are left from the initial firestorm isn't there value in a real assessment of how it has actually panned out in use? of who and what it can possibly benefit and at what cost? I have to tell you the video even made me reassess at least a little bit my assumptions about Lennart Voldemort It was indeed a massive undertaking and I was not aware he actually received death threats over it as a reward for his hard work. OK he is socially abrasive but so is Linus sometimes yet both have accomplished good work that has benefited much of the modern world. I think that deserves more than knee jerk condemnation. I was at least to some degree, in the wrong, and I'm choosing to rectify that.

PS: I still despise Pulseaudio

3 members found this post helpful.

I agree with a lot that's in that talk. I actually think SystemD is useful for a machine that I don't want to tinker much with. Distros that run it do seem to boot very quickly, they seem to have sorted out most of the issues that a 'normal user' encountered and it's no longer the disaster that it started out as.

I was forced into SystemD a couple of months back because I had to use a distro based on it for work (a requirement imposed by someone else, not chosen by me), and I think my biggest annoyance was its integration with DNS. The first thing I do to sort out DNS issues is to run my own Dnsmasq and it was a pain to just get SystemD out of the way. Of course there is loads of help because so many distros use it, so that mitigates. Ultimately I managed to get it to do what I wanted.

I'm used to bringing up Slackware with shell scripts. I know how the various commands work: iptables, brctl, ifconfig etc... I've been using some tried-and-trusted sequences for more than a decade so when I have to deal with a more 'modern' system all those commands need to be turned into cfg, and slotted into some framework that does it all in the right order, and you'd better hope that the config caters for all the options of all the commands you make use of. You no longer have much control. Slackware gives you *some* framework. But in the end it doesn't care whether you use it. If you don't like rc.inet1, just ditch it and write your own. You don't need to be an expert and I've been hacking those init scripts ever since I was a beginner. Barrier for entry is ridiculously low.

But my biggest disappointment with SystemD is that it doesn't translate well to embedded systems. It was touted as modular so you could only use what you needed but in practice nobody bothered. You can find plenty of arguments and counter-arguments about memory usage but I haven't seen it in systems with 4MB flash.

Show me it working with OpenWrt or Busybox without using any more RAM and I'll bow down at the Poettering altar like everyone else, but until then...

For me, the question is: What does it do that isn't currently being done? And what are the benefits of those features?

SSDs took care of boot times. Computers boot in seconds now, regardless of the OS or init choice.

What we have now works. There is no real reason to change to something bigger and more complicated.

BTW: There are real benefits to using PulseAudio. eg: Bluetooth works out of the box and it handles Intel HD Audio properly with no tweaking at all.

Maybe it's better in some circumstances. But I can imagine a situation in which I'd have to copy logs to another device or read them using some Live system after a crash and I couldn't do that without converting them to text first using some specialized program that may not be at hand.
There is. It's just that this is yet another topic on systemd and there were already many discussions about it in the past.
I do not, I can finally use my Bluetooth headphones comfortably.

That issue is also discussed in The Biggest Myths article I've already linked to in my previous post: http://0pointer.net/blog/projects/th...est-myths.html. See myth 4 and 22.

That is funny becasue Busybox used to support systemd: https://news.ycombinator.com/item?id=10483780

enorbet, that was the same lecture he gave back in 2017 as well or 2018. He blocked comments on the youtube channel which is/was a shame because the viewpoints pro/con would have been interesting.

IMO the pros of systemd are few and mainly revolve around consolidating Linux and having it be more homogeneous which is easier for corporate maintainers, new breed of admins etc... The cons of systemd are plentiful including bugs being poorly resolved or not at all (infamous not a bug report closed), attack surface is increased as predicted and confirmed with the numerous CVE's issued, problems with systemd and AMD, assumptions by dev's that most people are using similar boxes as them etc...

If broken into parts (elogind, eudev etc...) then perhaps its benefits can be utilized with minimizing the cons, however, it still appears that it was a solution looking for a problem of which better solutions could have been utilized. Without having Gnome dependent on systemd, I do not think it would have succeeded in replacing init. I do think it will be replaced, just a matter of when not if. my 2 .

PS: a short list:
https://nvd.nist.gov/vuln/detail/CVE-2018-20839
https://thehackernews.com/2019/01/li...d-exploit.html
https://security.netapp.com/advisory...20190530-0002/
https://sensorstechforum.com/systemd...ve-2018-16866/

4 members found this post helpful.

I'm not a systemd hater, but I am now* a systemd mistruster**.

There's one really important question for me - can it be easily replaced if*** it causes me problems? As long as the answer is "no" it's not going on my computer (my bail out from Linux, if necessary, is ready and waiting).

Edit: Which means that as soon as I see from Redhat a trivially easy recipe for removing systemd if I don't like it, I'd be willing to use it again (eg if it became part of a standard Slackware install).


*Originally I thought the fuss was just resistance to change and couldn't be bothered looking into it.

**Mostly because of its "feature creep". Partly because what's good for Redhat isn't necessarily good for me.

***I used a systemd distro for some years thinking it was JUST an init system and I admit I've never had a problem with it.

6 members found this post helpful.

I've found S6 to be more Unix like than systemd.

2 members found this post helpful.

Generally, I'm a systemd user. Do I like it? NO. But, all my favorite distro's moved to it, so I use it. It works* (*mostly, for the most part). Honestly the BIGGEST thing I dislike about it is binary logs. If journald saved everything as a straight text file, I'd probably like systemd. But I definitely agree with everyone who says they don't trust it...it's been a security NIGHTMARE since coming out. If it were easier to use my preferred distro's without it, I would. As it's difficult, if not impossible, to do so, I use it and I'll continue using it.

3 members found this post helpful.

You seem to have taken the words "shell script" out of what I wrote, and found the same words in myth 4, and linked the two. You're missing the point. My problem isn't that I can't script something it's how those scripts fit together with the rest of the system. You don't gain anything by scripting something only to have your work undone by some other part of the framework. You need to learn up-front much more of the system to do something useful.

You can link to all the 'myth busting' articles you want. Something is either quick to learn or it isn't. I gave an honest opinion about how I'd found it, so how about you do the same instead of just linking to stuff we can already google?

Yes, busybox is just Linux, so you can add all you want including full glibc and thereby run whatever you want. I specifically mentioned 4MB flash, because I knew someone would come back with a google hit like that. Again, missing the point.

You said you want to configure your system with shell scripts and you can still do that within the framework provided by systemd.
It's different, that's way you find it hard to learn. You've worked on your scripts for years and know them well. It's just like people saying that Linux is hard because it doesn't look like Windows.
4MB is really very little these days. The trend I see is different - get more expensive hardware and cut development time using JavaScript instead of C, Linux instead of RTOS etc. I think that systemd was not written with such small devices in mind. It's mostly geared for desktops and servers.

Thanks for posting this. It's a valuable perspective and an interesting historical account.