I'm not sure the programming language systemd is written in really matters to those that have a strong view about it one way or the other. Not really sure where you're going with the Python comments tho.

I wondered where RMS stands on the subject - other than "it's not an issue, ethically speaking", seems he's not fussed; provided it's "free software".

"Convenience" might be the context here, at least according to RMS.

From what I understand Linus isn't all that dissimilar in his views about systemd - other than "it has a few insane design features" IIRC.

IMO the implementation language does matter, some.

Traditional init is implemented in C, but most of the logic is in the shell scripts, where sysadmins can change init behavior to their liking. That worked well.

Nowadays it's pretty common for sysadmins to also know perl and/or python. They're the next step up from bash in terms of capability.

If systemd were implemented in perl or python, tweaking the code to adjust its behavior to situational needs would be within the reach of many sysadmins (as they do now with shell scripts in traditional init systems).

Since systemd is implemented in C, and fairly obscure, that option is simply not available to most users. Vanishingly few sysadmins have C skills, and recompiling / redeploying the entire init system to change some bad behavior is a much heavier operation.

In this case, the choice of programming language imposes a real obstacle to doing a sysadmin's job.

3 members found this post helpful.

Well, the unit files are human editable text, there is some system wide configuration (e.g. system.conf) and units can be deleted or masked (symlinked to /dev/null) or simply not implemented in the first place. Most sysadmins wouldn't need to hack the C sources. Silliness like journals can be set to "storage = none" and a traditional syslogd configuration can be used (or you can just redirect the journals to syslogd). You can also do away with systemd's networking and use traditional ifup/down etc. if you wish to.

PART of the yuck factor is distro implementation, for example SystemD in Arch is used more sensibly than, say, SystemD in Ubuntu. That really depends on how the units are set up and how many there are (including static ones that do init or configuration steps at every boot). Just for example.

Definitely more rigid than a tiny init program and the choice of shell scripting though, of course. I would always prefer that (and simple boot scripts at that, like you know whose :-) )

There are some things I don't mind about systemd, for example using systemctl to manage services. Enable, disable, mask etc. Though there is some strangeness to get used to, for example some services in distros use templates, when multiple instances of, or different implementations of a service may be used. When you configure the service to start, YOU have to name the unit with the template as you enable it. For example the unit may ship as "syslog-ng@.service" which is bollocks, it won't enable like that. You have to go look at /etc/default and find the name of the template, for example syslog-ng@default and enable the service like: "systemctl enable syslog-ng@default.service" and that will create the symlinks accordingly. I found that to be counter intuitive. Another weirdo thing is that some services start on demand through a systemd socket. You have to mask those to disable them.

I don't hate everything about systemd, just most everything.

3 members found this post helpful.

One feature that's very nice to have is journalctl -p err. Answers the question "Is there something wrong on my server?" in a matter of seconds. Extremely helpful. Add this to persistent logs, and you can search for things like "What went wrong on the last boot?"

Believe or not, also today "init" binary from Slackware is written in this "fairly obscure" C programming language.

This is from the FUD series "you know, commies eats babies at dinner", right?

Probably that was really fun on '60 but now we are almost in 2020, still...

The sysadmins does not need to learn C/C++ programming to customize systemd services, but to learn how to write some config files. At least, this way is on Ubuntu.

But let's look within the real Slackware-current, which already ships some of those systemd's unit files, like "/lib/systemd/man-db.service"

What we have there?
If a sysadmin can't learn in half of hour how to write a file like this, I bet that's better for him to throw the towel and focus in gardening instead. Or growing the nephews.

Don't treat people like they are stupid if they don't orate every detail. Of course "init" is a C program, everybody here knows that. This is a Slackware forum where people tend to know things. He was talking about init being a simple program, with the rest being implemented by defining runlevels in inittab and your choice of shell scripting being the rest of the coding, as opposed to (quite literally) a million lines of C code and some configuration files.

That's because this has crept into upstream projects. That's not a good thing, moreover, it serves as an example of why we hate this one way mentality. Those files could simply be removed before rolling up the packages, they aren't doing anything... mandb runs via shell script in cron.daily. Those unit files have nothing to do with Slackware. I noticed those a few months ago and deleted /lib/systemd and recently did so again when the mandb package was upgraded.

2 members found this post helpful.

Yes, knowing how to work journalctl is useful, I can't deny that, but my problem with the journals is that they get to be quite large databases. When they got to be 50 Mb+, I even noticed system initialization taking a few seconds longer. At first I was reigning them in with journald.conf and maximum file size and maximum usage settings, but it's still ridiculous that the logs are tens of megabytes on my desktop systems, vs. a few hundred kilobytes of text based syslogs. On servers the journals get quite large.

I'd rather use tail and grep on text files, personally.

P.S. The journals are also easily corrupted. I didn't like that either.

1 members found this post helpful.

personally, I agree with Dave on this.

1 members found this post helpful.

I agree. And that's exactly why the systemd critics should not treat people who maybe do not care about this "issue" like being stupids, and serve us claims like in the following quote...

Oh, well... In my humble opinion, insisting that systemd is just an init system because it contains an init system and comparing it with the traditional "init", is like insisting that Plasma5 is just a windows manager because it contains a windows manager and comparing it with "TWM" all the ways, just because it ships a windows manager named "KWin"...

Yes, it contains a windows manager, BUT the Plasma5 contains much more features than a windows manager, and even itself, that KWin offers much more features than TWM.

Same is with systemd. A fair comparation of it with the traditional "init" could not be done because of the really huge differences of features.

And anyway, if we want to be barely fair in comparations, I believe we should compare systemd with the flock of packages shipped by Slackware to resolve some features in the likes of systemd. True, starting with init system, but you should add also eudev, ConsoleKit2, PolicyKit, WhateverKit, udisks{,2} and God knows which ones other.

If we will do the sums, maybe we will discover that "our solution" is several times more complicated than that million lines, also as lines of code, not only as packaging, which probably is obvious.

1 members found this post helpful.

There are unit files, yes, but they are limited to providing parameters to systemd's hard-coded behavior. They are not comparable to bash, perl or python, which are general-purpose programming languages capable of exhibiting any behavior.

1 members found this post helpful.

The systemd's unit files could be used to launch in certain manner and with certain parameters, not only of any binary but also of whatever scripts written in bash, perl or python.

A behavior not dissimilar with what ConsoleKit2 could do, for example...

https://linuxconfig.org/how-to-autom...-systemd-linux

While true, that doesn't help sysadmins do their jobs when systemd is hard-coded to do skmething stupid. The script-wrapping unit files you describe can introduce additional behavior, but cannot provide a workaround.

3 members found this post helpful.

You are kind to give details about this "hard-coded" behavior of systemd?

This is one of the myths ventilated many times over Internet, regarding systemd.

But, speaking of the part of init system from systemd, from what I seen, it uses a huge set of unit files to know how to boot whatever services and in which order, from UDEV to Apache and MySQL.

Now, the systemd itself ships a series of daemons or services. One of them is UDEV, which we love to cannibalize and use it proudly as eudev. Other is login1, which we still try to clone in the form of ConsoleKit2 with the help of XFCE guys. Other is timedated, which is vaguely similar with ntpdate. And so on.

Which one has hard-coded a stupid behavior? And how you explain that when systemd is used by RedHat on Enterprise Linux, it is used also by SUSE or Ubuntu even on Enterprise Linux, and those companies have each one thousands of full time hired programmers, nobody do not bother to fix this "stupid behavior" if it exists?

You do not believe that is expected that systemd source code to be read and considered by so many skilled programmers on that "obscure" C programming language, that something stupid should be certainly noticed?

That is not a relevant argument and that is putting words in people' s mouths. The point was about Microsoft and how systemD and Microsoft share the same type of spirit.



Not sure what argument to make if one cannot understand the significance and implications of Microsoft owning the largest software repository in the world, and has ever seen.


Microsoft is not all to blame, they are taking advantage of an opportunity that was handed to them; and just following their behavioral patterns as they have for decades. No surprise there. The problem is it was handed to them on a silver platter because freedom and open have become corporate buzzwords and the fundamentals to ensure these buzzwords have been forgotten in the majority. Centralizing most of open source development onto one site was stupid.

1 members found this post helpful.

Because someone disagreed? There is no name calling, or other rude behaviour, sure some passionate moments. Yet, it is passion that is the vehicle behind free software and if people were not passionate about their free systems we would be using shitty systems from the 90s or earlier on shitty hardware with CPU and RAM still measured in Mb and hard drives weighed in pounds and three digit resolution sizes.