@rgegriff @lupyuen It's mostly a matter of philosophy. Some feel that systemd takes on too many roles, violating the Unix principles. This does bleed into it being technically undesirable sometimes, since it might be "bloated" in some regard (e.g. slow, unmanageable, etc.).

From a regular user's perspective; it won't affect you. systemd would very likely benefit you.

From a systems administrator's or enthusiast's; you might have concerns about systemd.

@skunksarebetter @rgegriff @lupyuen

> From a regular user's perspective; it won't affect you. systemd would very likely benefit you.

until you try to setup a vpn with networkmanager and systemd-resolved manages to be even more broken in regards of updating your resolvers than any hack used previously. welcome to hell.

@rgegriff @lupyuen

#slackware somehow is missing from this list, while being systemd free all the time. maybe it's not "sexy" enough :)

"stable" 14.2 is a bit outdated, you could try slackware-current. it's rather stable for a bleeding-edge thing, probably because most things are kept vanilla and not patched to death.

if you want to try -current, AlienBOB creates unofficial installer ISOs for that:
https://slackware.nl/slackware/slackware64-current-iso/

version 15.0 should be ready sometime this year, if everything goes well.

@bonifartius I'd be shocked to read about Slackware on Linux journo websites. I would think I woke up in an alternate universe. @rgegriff @lupyuen

@livestradamus @rgegriff @lupyuen tbh, the current times already feel like an alternate universe ;)

@rgegriff @lupyuen
my first Mastodon post 🙂 ...

Systemd can introduce problems, because it tries to integrate a lot of different services that were distinct and customizable in the past. I think to logginng for example: with Systemd you have integrated logging. But if you have a very big server, generating a lot of logs, it is difficult to customize the Systemd default logging system, while before Systemd you had a lot of different options from which choose.

Before Systemd, the service specification was less elegant, but Linux administrators were in full control, because they can swap parts. With Systemd they had to accept the choices of Systemd, and in some usage scenario, when they need to swap parts, it is not configurable/customizable enough.

It is a complete change of philosophy for Unx, because in Unix usually you assume to being in control of the details of the system, when you need this.

@mzan Welcome to Mastodon! 🙂

@lupyuen thanks! I'm studying different fediverse/P2P tools. Now I have doubts... if I hello to you, I'm using Mastodon as a chat, and is this good? 🙂

As Twitter alternative it seems rather good.

@mzan haha yep Mastodon is great! 🙂

@lupyuen @mzan You can still use a syslog daemon a daemontools or anything else beside journalctl on the same host or use a daemon other host via rsyslog. Systemd doesn't forbid to use other tools if you prefer in some specific cases. But it also allow a lot of things that couldn't be easily made with former system management, including user side daemon management, memorize the state (enable/disable) of a deamon, independently of the current usage (start/stop). There is an homogeneous syntax for services now, and lot of possible, prebuild dependencies/limits/notification parameters : man systemd.service
On ArchLinux, it take 24.3MB installed, that is a bit too big, for some architectures.

@popolon @lupyuen yes, probably you know better than me. Thanks and sorry for the FUD.

I'm rather sure that in the past there were problems with Systemd and syslog integration, as reported here https://news.ycombinator.com/item?id=9359167 but they are mainly bugs, probably nowdays resolved, and not defect by design, so you are right.

A possible "defect by design" is the fact that Systemd in any case want to be the first logging service in the pipeline, and then it can redirect to other syslog daemons. But obviously if the code is not a disaster, it should not introduce new problems, because you can disable journalctl heavy operations, and then Systemd will do only a very simple redirect.

On Hacker News there were regular posts against Systemd, written by administrators. It seems that it tried to do too much, and too fast, introducing some incompatibilities, and not being rock-solid in its implementation. So it generated some hate, because it solved problems already well managed by experienced administrators, but introducing new bugs and integration problems.

Probably nowdays the benefits are more than the left problems. I don't know in details because I administer only few servers, and I'm mainly a programmer.

In any case, indipendently from Systemd, the task to init a system and services is a very complex one, and a tool cannot cover all possible usage scenario. In extreme cases I think that there will be devop tools, with a minimal Systemd automation.

@mzan @lupyuen No problem, this is a normal questioning. I don't know so much either, and I just add information why I know about it ;). Ubuntu for example, progressively moved to Systemd, so you can mix both. I didn't looked at bugs, as I only used what was on distribution I used (mainly Debian, Ubuntu and ArchLinux(+arm version), and a bit of FreeBSD (but I try to avoid it)). And it worked fine. I agree it take some time to understand how to integrate some stuff after the changes, and there are still some I am not really happy with, because I didn't find the good answer. I don't know if it's possible, but it take time also on previous system to understand all parts. I didn't read the whole doc but just learn by practising, when there is a need, that's probably not the best way to work. There are also problem with PulseAudio, by the same author, and now PipeWire that is slowly replacing PulseAudio+Jack, especially on Arch where the transition is followed at the same time that new releases. At least, will we have a good global and very powerful integrated sound+video system at the end. I just hope it will not take to much time to really stabilizing. pipewire 0.3.17, had the ability to use both jack and pulseaudio applications at the same time, this is no more the case since 0.3.18 (current version is 0.3.22), I suppose they enable this feature by error, as the Jack compatible API is not finished.

@rgegriff

@rgegriff sorry, big fingers :)