[SOLVED] Is 2019 Still Too Soon For Intelligent Assessment of SystemD?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
We've danced these songs before on the forum. Nothing that I write will be anything new that hasn't already been said in one of the many systemd threads in the Slackware subforum. In fact, much of my post will be a quote from my previous post back in 2015. In fact, that post was in reference to a question from enorbet asking what systemd can offer in a SOHO environment.
And just for those that are interested in typing the name of systemd properly, it is systemd. Their website goes into more detail:
Quote:
Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple.
As I and many others have said, speeding up the booting process was never the intention of systemd. It was due to changes they made in the init system that led to speedups (like parallelization).
Quote:
This is all gathered via a google search (not all are unique to systemd, but none are currently a part of Slackware's init system). I have not had any actual experience with systemd and I don't plan to unless it's included in Slackware in the future. This is to the best of *my* understanding. If I misunderstood something, please let me know.
Logging - Say what you will about binary logs, if they do function properly, you get immediate logging as soon as the init RAM disk is started all the way to the final shutdown of the system. (How many times have you tried to glean information from the boot process only to have it go by too quickly?) It can also store non-text, like memory dumps, which can be used later in further debugging. The old syslog can be used in place without the extra benefits of binary logs and without the possibility of corruption. Do the benefits of binary logging outweigh the possibility of corrupted logs? To me, no.
Unit files - Easy to make config files using declarative language used to start up system daemons. This replaces the various rc.* files. They are simplistic to make and seem to have little to no downsides (other than ReaperX7 stating that it could lead to people not learning proper scripting techniques). It still supports running shell scripts if needed (although, I believe it would require a basic unit file). Benefits outweigh the costs? To me, yes.
Dependencies - Services are able to be started once a certain set of dependencies are met. This is different than rc.* when startup is based on location in the script. The dependencies can be more than just a program/service starting, it can be based on udev, dbus, sockets, etc. One example of this is to mount the network harddrives after the network comes up, but mounting any physical discs before. The possible benefits from this are there, but I have no idea how well it works in practice. It could cause dependency circles when two things are waiting for each other to start. I don't know the likelihood of this, so do the benefits outweigh the costs? To me, unknown.
Parallelization - Allows the startup sequence to occur in parallel. This allows two or more services to start at the same time. Because of unit files and the dependencies specified, this should prevent programs from starting too early. This does usually equate to a boot speed increase and I am not aware of downsides of parallelization (short of the downsides listed in dependencies). Benefits outweigh the costs? To me, probably.
Cgroups - Cgroups containerizes a process and all child processes. This allows systemd to keep track of child processes even when the parent exits and shut them down if needed. This, in theory, is much better than using a PID, since we've all ran into the issue when a process won't start because an old PID is left in /run. It seems you are also able to limit resources to certain containers, meaning that you can limit how much RAM or CPU usage. I could see this adding complexity to the system, but the tradeoffs may be worth it. Benefits outweigh the costs? To me, undecided.
Additional Core Components - Replaces startup shell scripts, pm-utils, inetd, acpid, syslog, watchdog, cron, and atd with systemd components. This makes it easier for maintainers to provide the features those programs do, since they will all be included and won't need to be gathered separately and require verification they all work together. They also fall under a unified release schedule and come in the same tarball. Some replaced abandoned software, like logind replacing consolekit. However, all of this also causes feature creep and creates a larger amount of code to debug. This is probably one of my biggest complaints about systemd. The combination of many programs that don't need to be combined. It creates the possibility for more problems and works to prevent you from using alternatives if desired. You can see what it has taken over when you look at its ancillary components: consoled, journald, logind, networkd, timedated, udevd, and libudev. Adding more services to systemd seems very reminiscent of Windows and its svchost.exe file. Bug reports are sometimes ignored. Benefits outweigh the costs? To me, no.
Now, I do like to point out that I'm no systemd fanboy. I am very happy with Slackware's init system and hope Pat and team are able to continue to use it. But I have to also admit that systemd has benefits that Slackware doesn't offer... even if those benefits aren't even close to being enough to sway my preference from Slackware's to something else. Unfortunately, the objectiveness and awareness of the people can sometimes be overshadowed by the worry that systemd is ruining Linux by doing things very un-UNIX like. I have this same worry as well, but I do like to try and be informed on both the good and bad of situations. I think systemd brings more bad than good, but that is only my opinion, and it's obvious that many OS developers have felt it brings more good than bad.
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.
The binary logs are extremely frustrating. Hey, you know all those great Unix utilities you have for finding, parsing, redirecting, and otherwise using content in text files? Guess what, you can't use any of them for your logs now. You have to use our crappy limited journald system instead. It's the worst. And all for the sake of what, saving a few megabytes on your hard disk?
Last edited by montagdude; 08-02-2019 at 10:51 PM.
The binary logs are extremely frustrating. Hey, you know all those great Unix utilities you have for finding, parsing, redirecting, and otherwise using content in text files? Guess what, you can't use any of them for your logs now. You have to use our crappy limited journald system instead. It's the worst. And all for the sake of what, saving a few megabytes on your hard disk?
You're free to configure systemd journalling as you like (as already mentioned in bassmadrigal's post) so this is a non-issue.
You said you want to configure your system with shell scripts and you can still do that within the framework provided by systemd.
No, not in the same way. Can I ask a question: have you actually tried to replace bits of init using both systems, if so how did you get along?
Quote:
Originally Posted by average_user
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.
My experience of systems that call you is that it's inherently more complicated than systems where you control the top level. Your position is that I just don't remember, but I respectfully disagree.
Quote:
Originally Posted by average_user
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.
They are still today producing 1MB devices that can run Linux, and they are still cheaper than the 4MB devices. If you run a business shipping thousands of units it can make a difference.
PS: I'm very interested to know how javascript cuts development time, there could be another thread devoted to that one .
Discussing this in the LQ Slackware forum is like some thread discussing the benefits of Windows on LQ.
Agreed - I long ago gave up hoping to have a sensible dispassionate systemd discussion here. Reminds me of the Amish - the world just passes by what was once considered "honourable".
Likely to be get a more balanced perspective elsewhere. Or maybe not given the protagonists ... :shrug:
No, not in the same way. Can I ask a question: have you actually tried to replace bits of init using both systems, if so how did you get along?
I haven't. I have never had a need to touch most of Slackware startup scripts neither apart from modifying several switches here and there.
Quote:
Originally Posted by bifferos
PS: I'm very interested to know how javascript cuts development time, there could be another thread devoted to that one .
For starters, it's easier to find Javascript developers because this language is much more popular than C. There is no need to compile Javascript code. It's easier to avoid memory leaks thanks to built-in garbage collector. It's portable across various platforms, for example you can use React framework to create mobile apps https://facebook.github.io/react-native. But perhaps the most important advantage is that you can create web apps that run in the web browser that always executes remote code and by doing that you are able to upgrade your app in one place without deploying it on millions of your devices.
First: if they don't know themselves where they're going with it, how are we supposed to make an intelligent assessment of it?
Second: if nobody can point to a feature of systemd that we didn't already have, why exactly did they cause so much disruption by imposing it? And yes, they did impose it, because they made the burden of maintenance so much harder for developers offering alternatives.
systemd was the brainchild of the bully boys in the Linux world, people in various projects who like to think it's their way or the highway. No intelligent assessment is possible with people like these. They don't listen.
I've been using openSUSE for my LPIC course. I am yet to find a single feature of systemd that was not already available in Linux, nearly always from a more intelligent and respectful developer.
I am yet to find a single feature of systemd that was not already available in Linux, nearly always from a more intelligent and respectful developer.
For example: Slackware (with its ConsoleKit) supports the true Multi-Seat?
I seen that Multi-Seat in action at the school where learns my younger kid: imagine two kids having their own set of keyboard, mouse, headphones and LCD monitors, every one doing his independent job on their independent desktops, but having just a single computer between them.
The teacher told me that from their own experiences any of their average computers can drive decently up to 4 seats, but there appears the physical issues of how to organize the seats around computer, and that they are (already) quite happy with those double seats, which permits them to cut at half the number of computers.
RE: 20 (average) computers for 40 (happy) kids.
Could be that be done with Slackware instead of Ubuntu?
Last edited by LuckyCyborg; 08-03-2019 at 07:23 AM.
I have to say I'm rather disappointed that it appears few have actually watched the video. The speaker is a BSD guy and he explains some deep level uses, uses that have parallels in MacOS and Windows, in fact he castigates Lennart somewhat for his apparent fascination with (and "taking pages" from) Apple. The point is that if a software developer for BSD, with the deep background he seems to have, sees some developmental value in such init systems (one area mentioned is containers and security, others I understand even less) it is at least worthy of honest discussion IMHO.
Another point about which I was mistaken and some here seem still mistaken, is that while some people touted faster boot times with systemd, that was never a design goal.
As for the spelling, bassmadrigal, I have read that too and frankly I don't give a hoot. In a title where it is common to capitalize, given that not one single person would misunderstand "SystemD" I care even less. I want to know more about what alternatives it offers of which, in my ignorance of deep OpSys development, I am interested solely in cost/benefit. Currently I don't see that as even a break-even-point, but the video made me more aware of what I don't know well at all.
I commonly test out other distros and naturally many of those use systemd. I have struggled with it some but mostly that was from the learning curve for newly named processes and conventions. It was no great benefit but wasn't that big of a deal. It was fairly transparent but I'm now thinking maybe I got no benefit exactly because of that learning curve and I'd like to know if that is true or not. Granted I could learn that best by submitting to the curve but my time is valuable and I think it is inefficient to chase goals that are not well defined. So this thread is so I can hear from anyone who was forced into that curve and accepted that curve and found some value of which I am unaware and I don't mean necessarily limited to systemd, but the entire concept behind why anyone would consider it a good idea.
Years have now passed since so many distributions chose (or caved depending on your POV) to switch to it. Surely the community knows more now than they did then.
I would greatly appreciate fewer comments by people who can't be bothered to spend 47 minutes to get a 2019 update from someone experienced in the field, especially someone something of an outsider whose only affiliation is software development and seems to be reasonably objective. If it is just a rehash of how you (or I) initially reacted, as many have already noted, that's been done to death and doesn't belong in this thread.
I commonly test out other distros and naturally many of those use systemd. I have struggled with it some but mostly that was from the learning curve for newly named processes and conventions. It was no great benefit but wasn't that big of a deal. It was fairly transparent but I'm now thinking maybe I got no benefit exactly because of that learning curve and I'd like to know if that is true or not. Granted I could learn that best by submitting to the curve but my time is valuable and I think it is inefficient to chase goals that are not well defined. So this thread is so I can hear from anyone who was forced into that curve and accepted that curve and found some value of which I am unaware and I don't mean necessarily limited to systemd, but the entire concept behind why anyone would consider it a good idea.
Recently I experimented with running Arch and Debian. Over time I became accustomed to systemd conventions like systemctl. I am very fond of Arch, it is outstanding. The only glitch I noticed with Debian was occasional lock-ups. As I initially stated in this thread I have mixed feelings about systemd. I am comfortable with using systemd distros, but, I don't feel the need to permanently adopt any of them. Slackware meets my computing needs.
I am taking a wait and see attitude on this issue. What will be, will be. Acceptance.
I would greatly appreciate fewer comments by people who can't be bothered to spend 47 minutes to get a 2019 update from someone experienced in the field, especially someone something of an outsider whose only affiliation is software development and seems to be reasonably objective. If it is just a rehash of how you (or I) initially reacted, as many have already noted, that's been done to death and doesn't belong in this thread.
I was just answering the question in the thread title.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
.
