Time to jump into a thread about systemd and inevitably make roughly half of everyone on the internet angry.

My company ran into major issues with terrible clock disciple at the hands of systemd-timesyncd when attempting to introduce a few new appliances. Unchecked drift that seeped through the cracks and hosed a good chunk of data. That was fun. That day, the shadowy board of "yes-men" upstairs learned what Patrick Wayne Swayze meant when he said, "Nobody puts ntpd in the corner."

Is their mistake in not properly vetting the new stuff in anyway systemd's fault? Of course not. However, I do like a clock to be trustworthy.

5 members found this post helpful.

The systemd paradox:

1. systemd is worse than nothing.

2. Nothing is worse than systemd.

6 members found this post helpful.

Quality absolutely has to be maintained. More places you go on the internet now are replete with bad language, poor grammar and spelling, childish arguments and attention-seeking. Other communities, even in the Linux world, have had one or two forum members who desperately battled over time to keep the quality up, but as soon as they left, their absence was very noticeable and the community[ies] turned into a playgroup.

Fortunately bass is just one of many forum members here who do their utmost to keep the level of debate, thought, advice and English, high. It's not hyperbole when I say that the Slackware LQ forum is one of the last bastions of quality advice and debate that I know on the internet and that's because of the consistent efforts of such members.

1 members found this post helpful.

My I used systemd briefly on Arch and for rather longer on Debian. One of my LFS builds was the systemd version, because I wanted to say I had done it. But I still prefer not to use it.

I did like the fast boot, not so important now, but it was on some of my older machines. I liked the .ini style configuration files, which I found easier to write than shell scripts. In a way, those files are not unlike the "name=value" files that are part of most sysvinit systems nowadays, with the names being script variables for the sysadmin to set. This is a kind of silent admission that the hand-editing of shell scripts on modern systems is becoming impractical for most of us; they are just too complicated.

But I hate the binary journal, and I do not like the underlying complexity of the way systemd works. Above all, I am deeply unhappy about the way it seems to put out tentacles into more and more parts of the OS. Linux has never been a fully integrated system like OSX or BSD. It used to be a modular system, and I like it that way.

4 members found this post helpful.

That's because at a certain point it hands over to syslog. Whatever was missing from the output of dmesg will be in /var/log/messages provided that your /etc/rc.d/rc.syslog file is executable.

Just a heads up: Slackware comes with a default cron job which rotates the logs generated by syslog every day at 4:40am.

That the scripting language that is used to start the system up is the exact same language and syntax that the user uses on the command line has always struck me as genius. As the presenter of that talk said -- though I don't think it's an original quote: I've heard Brian Kernighan use it before -- "UNIX is simple; brutally so." The problem is that because shell script is so powerful, people over engineered the startup scripts. What do I mean by that? Take a look at the first bits of rc.S on slackware:
why not just:
It's not a particularly good example, but it sort of makes the point. Do we really need all those 'if's checking on stuff that we damn well know will be true?

Similarly why have hundreds of lines of rc.inet1 when what it essentially boils down to is running a couple of 'ifconfig's and a 'route' command.

The system startup scripts were intended to be brutally simple, and that's been forgotten over the years.

So when systemd proponents point at rc scripts and say "ewwww, look how complicated this mess is", that was never the intention for them. People just got carried away.

As for systemd. My thoughts are inline with the first paragraph of what Jeebizz posted

3 members found this post helpful.

Is 2019 Still Too Soon For Intelligent Assessment of Vim and Emacs?

In my small handful of use-cases, systemd doesn't really give me any benefit over sysvinit or rc scripts, but it did have a bug in how it handles LUKS and mdraid that made my home server fail to boot more often than it booted successfully. The strange thing is that when it would drop to shell, just exiting the shell without entering any commands would allow it to finish booting. Eventually I changed the configuration to just restart on fail instead of dropping to shell and shortened the timers, but it still took forever to boot most days since it only had a 1 in 5 chance of working on each boot. Others had this bug as well, and it went unsolved for over a year before I got tired of waiting 20 minutes for my server to boot. Switched it over to Devuan with sysvinit and haven't had an issue since. I'll probably switch it to Slackware when 15 comes out, or when the franken-apt house of cards I've built finally collapses...

I still use systemd on some ARM SoCs and on spare machines with generic hardware and disk configurations that I don't intend on tinkering with, but only because in some situations it's more hassle to remove/avoid than it is to just deal with it. I doubt I'll be using it on my main machine or server again until it either can't be avoided anymore or if the ratio of features to bugs improves dramatically.

If people like it and want to use it that's fine, I don't think it's right how hard it's being pushed though. It's irritating how often I've seen developers drop support for non-systemd init systems, then when i try using the new version of the software with an unmodified init script from an older version it works perfectly. Why would you drop support and inconvenience users like that when it still worked and dropping the support took more effort than keeping it?

4 members found this post helpful.

Thank you, ttk. This is some of the kind of experience I was hoping for.

Thanks, cowpoke. I was hoping for actual experiences. I've tried some distros that have it but have not worked with them enough to accumulate as much experience as what occurs on an intranet.

'

There ya go. It seems to me that any restructuring to adopt a parallel structure implies "tentacles". I am very aware of how bad that can be and it was even mentioned in the video as just one well-known characteristic problem, "Dll Hell". However what Bassmadrigal said was essentially true, in that 4 years later I don't know much more than I did then about what benefits might be involved in such a far-reaching alteration. Like you I prefer modular and still see none of the benefits that others, including the speaker in the video I linked, to come anywhere near offsetting the problems and downsides.

@ Bassmadrigal - Since I have many times thanked you publicly and personally for your excellent help over the years, I certainly do not want an impression of any animosity to exist between you and I. Much of what you pointed out in your posts in this thread is very accurate. One, with which I disagree however, is that this thread would be of little or no benefit here in the Slackware sub-forum.

I can't speak for anyone else but I have already learned a few new things and for that I am grateful. I still do not prefer it and still see it's cost as greater than it's benefit(s) which may well have been expected here for good reasons but now I have some specifics from people who have used it more than I and/or work in environments where it is forced on them but have many user experiences to relate.

Anyway, I hope we are still forum friends.

1 members found this post helpful.

maybe theres couple quality mods in one of the other forums with a sense a humor who could jump in here as necessary to sort things out

my -v comment was intended as clever slackware cli joke, apparently not


these forums are accessed by thousands of people from around the world with varying perspectives about everything, that's what makes and keeps things interesting

1 members found this post helpful.

Another systemd thread, where are you Darth?

1 members found this post helpful.

Slackware's boot scripts are not "too complicated". That's one of the advantages of linear boot scripts, they are easy to follow and I can understand every line of it. I edit them, remove everything I don't want including condition checks, and it initializes faster than any SystemD based distro I've ever used.

I don't like SystemD and I don't want to see it in Slackware. I grudgingly use it on other distros... I can work with it, but I practically have to sabotage it to get it to stop doing things I don't like.

Another thing that royally burns my ass about SystemD... that they don't want to implement localtime properly. I use it anyway, but it cripples NTP adjustments (I just use ntpdate manually if I want to correct anyway, though) and daylight savings time changes. I'm not switching my other OSes to UTC just because Poettering has decided localtime shouldn't exist.

Also, that SystemD does things it has no business doing, has resulted in non-booting systems for a lot of people. For example, forcing the use of a random number generator. Sure, it's the CPU's logic at fault in advertising a feature that doesn't work, but the point is that SystemD shouldn't have been going there in the first place.

As for binary logs, they can go ride the baloney pony... I disable the utterly ridiculous journals and use syslogd.

5 members found this post helpful.

systemD goes against the simplicity of the UNIX philosophy, and i am glad there are some distros refusing to include systemD in to their distros

systemD is too much of a single point of failure, and is like an Achilles heel, which will either be used to break and crash a running Linux, or to root and control it, i dont trust systemD

7 members found this post helpful.