According to the latest Slackware users stats roughly 30% of us are old farts, or sort of, hopefully more wise instead of grumpy
I just recalled that I've spent some time (hopefully not wasted) on a similar but older thread some years ago, and following are my inputs (digging up the dead):
https://www.linuxquestions.org/quest...ml#post5771074
https://www.linuxquestions.org/quest...ml#post5772948
The last post (last paragraph) also contains my view on systemd integration, consider it also as an answer to your last question. I'm not against having it provided by Slackware, much like as an alternative, but I doubt it'll be possible without messing up the whole distribution. If they just designed it as an overlay like webmin (not using it either), it would have been fine, hence, this is one of the design issues I mentioned.
Speaking of flexibility, if systemd will become a de facto standard (again, I doubt it will) and I'll need to conform to its operation mode and syntax, my concern is that I'll loose details (or granularity) over the administrative tasks I like to perform. I'm pretty sure I'll develop a series of small scripts to hack & tune it, and I'll be back to where I started - bash init scripts, well with some unnecessary overhead.

Speaking of design flaws, I gathered a few that I remember reading about and considered "scary" enough to get concerned:
- overall, IMHO one of the truly big design flaws is the complexity, size (pushing all the crap into the init), interconnections & dependencies. I don't see a sysadmin (myself included) lecturing the systemd sources to gain more knowledge and troubleshoot issues. Instead, he/she will be dependent on the Poettering & co. Not the case with a "clear text" scripted init system.
- to the complexity I can add the constant "invention" of features some Biggus Dickus came up with or was told to implement (more likely) and the precarious (bad code & design) way these are implemented, many times needing several patches.
- security - adding everything into the init process increases its attack surface/vulnerability
- an unnecessary PITA changing the boot order. I remember the parallel execution was the only feature I considered novel/useful, not anymore, just an useless over-complication for gaining a few seconds (minutes?) in boot time.
https://serverfault.com/questions/48...and-boot-order
- binary logs and the "rationale", right... very rational rationale
https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3
-"simplifying" the network setup, guessing interface names
https://www.freedesktop.org/wiki/Sof...nterfaceNames/
https://access.redhat.com/solutions/2592561
- hard coding nameservers? really?
https://github.com/systemd/systemd/issues/494
- etc - just use google for some more interesting design (& features) examples

I do question Monsieur Poettering & team both intelligence & wisdom, based on the outcome of their work, which I consider, apart from what they were instructed to do, driven more by typical "youth exuberance" (and other affections like boredom) ending up in a "premature ejaculation" and not in a serious product. Sorry, not impressed and doubtful that things will improve given the "kind and fruitful" interaction these folks have with the Linux community.

__

I guess I spent enough on this subject (again) - @enorbert - please do ask the mods to lock your thread

3 members found this post helpful.

There's a worrisome difference, to my mind. If I don't like bash I can with little effort install and use csh instead of the default; with systemd, not so much. How much effort did it take to get Devuan going?

2 members found this post helpful.

Isn't part of the problem that there are two Linux communities, not one? On the one hand, most servers run Linux. The whole Internet runs on Linux. And then you have the desktop Linux community, which is itself split into hacker types and people like me who just want an easy-to-understand OS which is secure against malware.

These communities have totally different priorities and Red Hat is oriented towards the server market. Most server admins prefer systemd and not just systemd either. The new nomenclature for network interfaces is also aimed at the server market where machines often have several different network cards, which need reliably constant names. And I suspect the replacement of simple partition device names by UUIDs is also server oriented.

For desktop users all this is a pain in the a***. We didn't ask for any of it but we are given it anyway. Desktop users value the modularity of Linux because it gives us the freedom to mix and match software. We don't like the tight integration that comes with systemd.

I'm currently wrestling with BLFS-9.0 (sysV version) and finding it quite dispiriting. I can't quickly put up a functional but minimalist system as I could with earlier versions because of all the new dependencies that have been introduced. They are necessary, apparently, to allow higher level software to run without systemd. This is definitely the last LFS that I do and I don't even know if I shall finish it. It just isn't fun any more.

I'm beginning to wonder if the best answer is some kind of "conscious uncoupling" of the two communities.

9 members found this post helpful.

I think most of the opinions on this thread can be summed up in a systemd that is:

a blob of unnecessary software that creates too many dependencies and breaks the system and principles of the GNU/Linux community implemented by the thoughtless and inconsiderate and greedy corporate lackeys and their uncaring newbie and lazy followers who allows it.

??? Why would I do that? I truly do not grasp why people think uncomfortable things should fall into the "he who shall not be named" category like cancer, aids, teenage pregnancy and drug abuse and propose sticking our heads in the sand. Free Speech is the single most important freedom there is and I don't think it is at all wise to minimize and diffuse it by ignore-ance.

1 members found this post helpful.

Seriously, WTF? Have you not seen enough reprimands for posting the same old bi-polar crap we all have suffered so long? You have offered nothing new or exerience-based and it is still completely one-sided and as invasive as you claim Poettering's work is, since you apparently assume your POV is Sacred Truth. Please stop.

1 members found this post helpful.

I'm just summing up this thread, don't blame me for the content.

1 members found this post helpful.

The off-topic and back-and-forth personal attacks will not be tolerated moving forward. Challenge others' points of view and opinions, but do so respectfully and thoughtfully... without insult and personal attack. Differing opinions is one of the things that make this site great. LQ is a great place for public discourse, and something we encourage, but the recent escalating trend of that discourse not being possible is both disconcerting and disappointing. If you're like to continue participating here, I encourage you keep this post in mind. If there are any questions, please feel free to contact me.

--jeremy

8 members found this post helpful.

It's easy to setup csh as a default shell for a user. Replacing bash with csh in a distro is a completely different story. Imagine one minute the effort to remove bash and replace it.: rewrite all the scripts everywhere in /etc, all the commands implemented as bash scripts in /usr (most of them coming directly from upstream), slackpkg, all the slackbuilds...

Just look at all the effort to use dash as a default shell in debian and ubuntu. Yet it was much easier since dash is (as bash) a POSIX/bourne shell...

So yes, when (most of) the world settled on the bourne shell, it would have been increasingly difficult and costly for a distro maintainer to keep csh as the default shell.

I used this analogy just to highlight why I am worried. When the rest of the world switches away from a piece you rely on, you are condemned either to adapt, or to a looong uphill battle.

This is what devuan is facing. I don't know how they are doing. I don't know how motivated their (unpaid) contributors will be, five years down the road.

AntiX has the same problem. They use a special repository with nonsystemd versions of programs like cups, which takes precedence over the Debian repos. But I've seen this cause horrendous problems when, for any reason, the nonsystemd repo isn't accessible. Then the Debian versions are referenced and they want to install systemd and get rid of eudev (which means also getting rid of a lot of software including the X desktop). A naive user who answers "yes" to this can get into a lot of trouble. I've seen it happen.

4 members found this post helpful.

why has this thread not died yet. Slackware is more than likely not going to switch to systemd, so get over it and let this thread die, if you want a systemd distro then switch distros, there are plenty of zombie distros that have sold their soul for systemd

2 members found this post helpful.

I would consider ubuntu to be a shallow clone of debian, for that matter.

2 members found this post helpful.

As far as I know (but correct me, more knowledgable people, if I'm wrong) csh (and especially tcsh) is still the default shell in the *BSD's (csh originated in the BSD flavor of Unix, just like ex/vi, by the way).
I'm actually using both, whichever is more appropiate to the problem I'm writing a script for. For instance, my "backup" script uses tcsh, but to restore something FROM such a backup bash is used (as it's using "$@", which is a bash'ism).
And I think there are still quite some people using ksh, which is NOT a Bourne-shell replacement (although bash did borrow some enhancements from it).

You are right for FreeBSD (it uses tcsh as a system/root shell, but a Bourne shell as default user shell - I think it is ash). NetBSD defaults to ash. OpenBSD uses ksh.

Regarding ksh, I thought that it was compatible with the Bourne shell (ie. for example an ash script would run ok in ksh - the opposite is obviously not true). Maybe I am wrong here.

When I said "(most of) the world settled on the bourne shell" I admit that I was a bit "Linux-centric" :-) Sorry for that.

I wasn't really serious with my suggestion to lock this thread. However, as mentioned, I've spent some effort already with this systemd subject (older thread too) and since it's not something Slackware would be able to easily adopt, more likely to transform/morph into, I find further discussions (never ending) on the subject not really beneficial. It's up to Patrick & co to asses (the effort & opportunity) and decide.
Then, there is the sustained potential of this thread, as previously highlighted by Lysander666, to attract trolls and spark flame wars.
It's not about free speech, which I obviously support, but about useless speech, because nothing changed with systemd ever since it was launched. Same design, well, maybe the code is a little bit more mature (patched & overpatched).

I remember someone mentioned the Dlackware project some time ago, forgot about it and found it again now:
https://github.com/Dlackware/dlackware
https://github.com/Dlackware/systemd
https://github.com/Dlackware/pam
It's there, the effort has been made, there are two maintainers that could provide valuable feedback and the project can be both an alternative and a source of inspiration.