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.
If one puts conspiracy aside, as an false assumption, all answers that are left are either complicated or non conclusive.
Only conspiracy alone, can make the whys and who's simple to understand, as well as the motivation for the significant spent effort.
Simple as that.
Being ignorant of an conspiracy is by far no proof there isn't one at deed.
@SCerovec
It doesn't really look to be any conspiracy around here, but only some tasty sarcasm, which is part of a healthy rational thinking.
Nevertheless, regarded objectively, there are real driving forces behind these new trends/implementations, systemd included, and some of them are obviously commercial by nature, although Monsieur Poettering, a RedHat employee, denies that blatantly. Funny enough, it's again RedHat, the very ones that continuously messed up their distributions some 15-20 years ago, exactly by adding mostly faulty (not properly functional) layers of abstraction (interfaces) over the system configuration.
Now, there are some other trends to take into consideration. As mentioned in my last post, there are some developments designed only to suit KDE/Gnome that are imposing themselves (getting adopted) over the entire system. D-Bus is one central such (under)development, systemd relies on it, that has been adopted by the freedesktop Linux components (and not only). Some of its adoptions/implementations were so badly designed that they are forcing you to run X in order to get the full functionality, which is a really sad development. I just hope that the non-graphical console operating mode will still be preserved in the future and the X-System (the Desktop) will remain a separate part/development. For instance, I wouldn't see myself running X on IoT devices...
Then there is an industrial need for a so called "convergence" - an obsession nowadays - where it is called upon unifying/converging the system configuration in order to ease the administration/scalability in the cloud computing realm.
Another observation is the tendency to copycat Redmond, like its latest developments are not enough to teach everyone a good lesson especially about don'ts.
@Fat_Elvis
Quote:
More and more I get the feeling that it bothers some people that people in the wild can have that amount of knowledge and control.
Don't worry, It's part of the definition of the not-so-gifted human, what he hasn't got enough bothers the ones around, and what the ones around have got extra bothers him. Just a joke, some shared wisdom too I have more, but I'm afraid AlienBob will jump over me and call me a bad elitist.
@Qury
I agree with you about the falsely perceived heighten productivity in using configuration interfaces "where full control is hidden away behind ease of use, automation and oversimplification", however, systemd looks to be the opposite, not to mention its troubleshooting. There are add-ons like Webmin&co that help you achieve GUI control without messing up the underlying system (Linux). Nevertheless, you would also need to consider the purpose of the OS and target user-base. That's why you have so many Linux flavors, isn't it?
Quote:
Even at work, i struggle to find employees who take their own initiative to find out how "stuff" works.
Sorry about your experience, I must admit there's a certain superficiality to be observed with the "debutantes/new gen" that could be caused by the pretty complex actual IT environment, shortened period to catch-up and start to be productive, shortened PLC of the systems/programs, etc. However, you shouldn't despair, seriousness/commitment is what makes some shine and distinguish from the crowd, additionally it is said that the sum of intelligence on the planet is constant, only the population is growing ... or was that a joke too? Never mind.
__
I hope that the beloved and benevolent dictator (together with the other folks involved) will take the right decisions and adopt some of these developments only if they're really necessary, in a more flexible fashion, if possible, like it has been done before.
@abga: all this boring and useless systemd-bashing put aside, let me tell you that I do find freedesktop.org specs useful, even though it's not a standard body like ISO. Here is an example.
I had hard time making some software communicate together (speechd-el and speech-dispatcher in this case), because the former didn't find the socket of the latter. I could have solved that with an ugly symlink (which I first did), or maybe setting some specific environments variables, but instead...
And bingo! I can hear Emacs speak as soon as started.
Additionally this provides an auto-cleaning of the user's cache directory as it disappears after a reboot, and probably makes the system slightly more responsive.
And amazingly so far none of the software that previously wrote stuff in ~/.cache complained. They just now all write in /dev/shm/didier instead. Isn't that nice?
Of course I was helped by Slackware mounting a tmpfs on /dev/shm by default, thanks Pat.
Last edited by Didier Spaier; 10-23-2017 at 12:38 PM.
@Didier Spaier
Salut!
Happy to hear about your private satisfaction with the XDG Base Directory Specification alternative automated resolution of your particular problem, feel free to use it anytime you like for your other particular needs. Hopefully it's not that complicated to manually install it and use it whenever you need it.
First off, I'll say I'm not a fan of systemd. I think it is too invasive and flies in the face of what unix/linux programs should do. However, when incorrect information is passed around, I still like to correct it. As for "no obvious benefits", did you miss the opening paragraph on freedesktop.org's page on systemd? It lists the following benefits (which I made into a bulleted list):
Quote:
system and service manager that runs as PID 1 and starts the rest of the system
aggressive parallelization capabilities
uses socket and D-Bus activation for starting services
offers on-demand starting of daemons
keeps track of processes using Linux control groups
maintains mount and automount points
implements an elaborate transactional dependency-based service control logic
supports SysV and LSB init scripts and works as a replacement for sysvinit
logging daemon
utilities to control basic system configuration like the hostname, date, locale
maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons
manage simple network configuration, network time synchronization, log forwarding, and name resolution
On Lennart's blog post that you linked (written in 2010), he goes even more in-depth on the features:
Quote:
For each process that is spawned, you may control: the environment, resource limits, working and root directory, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, supplementary group ids, readable/writable/inaccessible directories, shared/private/slave mount flags, capabilities/bounding set, secure bits, CPU scheduler reset of fork, private /tmp name-space, cgroup control for various subsystems. Also, you can easily connect stdin/stdout/stderr of services to syslog, /dev/kmsg, arbitrary TTYs. If connected to a TTY for input systemd will make sure a process gets exclusive access, optionally waiting or enforcing it.
Every executed process gets its own cgroup (currently by default in the debug subsystem, since that subsystem is not otherwise used and does not much more than the most basic process grouping), and it is very easy to configure systemd to place services in cgroups that have been configured externally, for example via the libcgroups utilities.
The native configuration files use a syntax that closely follows the well-known .desktop files. It is a simple syntax for which parsers exist already in many software frameworks. Also, this allows us to rely on existing tools for i18n for service descriptions, and similar. Administrators and developers don't need to learn a new syntax.
As mentioned, we provide compatibility with SysV init scripts. We take advantages of LSB and Red Hat chkconfig headers if they are available. If they aren't we try to make the best of the otherwise available information, such as the start priorities in /etc/rc.d. These init scripts are simply considered a different source of configuration, hence an easy upgrade path to proper systemd services is available. Optionally we can read classic PID files for services to identify the main pid of a daemon. Note that we make use of the dependency information from the LSB init script headers, and translate those into native systemd dependencies. Side note: Upstart is unable to harvest and make use of that information. Boot-up on a plain Upstart system with mostly LSB SysV init scripts will hence not be parallelized, a similar system running systemd however will. In fact, for Upstart all SysV scripts together make one job that is executed, they are not treated individually, again in contrast to systemd where SysV init scripts are just another source of configuration and are all treated and controlled individually, much like any other native systemd service.
Similarly, we read the existing /etc/fstab configuration file, and consider it just another source of configuration. Using the comment= fstab option you can even mark /etc/fstab entries to become systemd controlled automount points.
If the same unit is configured in multiple configuration sources (e.g. /etc/systemd/system/avahi.service exists, and /etc/init.d/avahi too), then the native configuration will always take precedence, the legacy format is ignored, allowing an easy upgrade path and packages to carry both a SysV init script and a systemd service file for a while.
We support a simple templating/instance mechanism. Example: instead of having six configuration files for six gettys, we only have one getty@.service file which gets instantiated to getty@tty2.service and suchlike. The interface part can even be inherited by dependency expressions, i.e. it is easy to encode that a service dhcpcd@eth0.service pulls in avahi-autoipd@eth0.service, while leaving the eth0 string wild-carded.
For socket activation we support full compatibility with the traditional inetd modes, as well as a very simple mode that tries to mimic launchd socket activation and is recommended for new services. The inetd mode only allows passing one socket to the started daemon, while the native mode supports passing arbitrary numbers of file descriptors. We also support one instance per connection, as well as one instance for all connections modes. In the former mode we name the cgroup the daemon will be started in after the connection parameters, and utilize the templating logic mentioned above for this. Example: sshd.socket might spawn services sshd@192.168.0.1-4711-192.168.0.2-22.service with a cgroup of sshd@.service/192.168.0.1-4711-192.168.0.2-22 (i.e. the IP address and port numbers are used in the instance names. For AF_UNIX sockets we use PID and user id of the connecting client). This provides a nice way for the administrator to identify the various instances of a daemon and control their runtime individually. The native socket passing mode is very easily implementable in applications: if $LISTEN_FDS is set it contains the number of sockets passed and the daemon will find them sorted as listed in the .service file, starting from file descriptor 3 (a nicely written daemon could also use fstat() and getsockname() to identify the sockets in case it receives more than one). In addition we set $LISTEN_PID to the PID of the daemon that shall receive the fds, because environment variables are normally inherited by sub-processes and hence could confuse processes further down the chain. Even though this socket passing logic is very simple to implement in daemons, we will provide a BSD-licensed reference implementation that shows how to do this. We have ported a couple of existing daemons to this new scheme.
We provide compatibility with /dev/initctl to a certain extent. This compatibility is in fact implemented with a FIFO-activated service, which simply translates these legacy requests to D-Bus requests. Effectively this means the old shutdown, poweroff and similar commands from Upstart and sysvinit continue to work with systemd.
We also provide compatibility with utmp and wtmp. Possibly even to an extent that is far more than healthy, given how crufty utmp and wtmp are.
systemd supports several kinds of dependencies between units. After/Before can be used to fix the ordering how units are activated. It is completely orthogonal to Requires and Wants, which express a positive requirement dependency, either mandatory, or optional. Then, there is Conflicts which expresses a negative requirement dependency. Finally, there are three further, less used dependency types.
systemd has a minimal transaction system. Meaning: if a unit is requested to start up or shut down we will add it and all its dependencies to a temporary transaction. Then, we will verify if the transaction is consistent (i.e. whether the ordering via After/Before of all units is cycle-free). If it is not, systemd will try to fix it up, and removes non-essential jobs from the transaction that might remove the loop. Also, systemd tries to suppress non-essential jobs in the transaction that would stop a running service. Non-essential jobs are those which the original request did not directly include but which where pulled in by Wants type of dependencies. Finally we check whether the jobs of the transaction contradict jobs that have already been queued, and optionally the transaction is aborted then. If all worked out and the transaction is consistent and minimized in its impact it is merged with all already outstanding jobs and added to the run queue. Effectively this means that before executing a requested operation, we will verify that it makes sense, fixing it if possible, and only failing if it really cannot work.
We record start/exit time as well as the PID and exit status of every process we spawn and supervise. This data can be used to cross-link daemons with their data in abrtd, auditd and syslog. Think of an UI that will highlight crashed daemons for you, and allows you to easily navigate to the respective UIs for syslog, abrt, and auditd that will show the data generated from and for this daemon on a specific run.
We support reexecution of the init process itself at any time. The daemon state is serialized before the reexecution and deserialized afterwards. That way we provide a simple way to facilitate init system upgrades as well as handover from an initrd daemon to the final daemon. Open sockets and autofs mounts are properly serialized away, so that they stay connectible all the time, in a way that clients will not even notice that the init system reexecuted itself. Also, the fact that a big part of the service state is encoded anyway in the cgroup virtual file system would even allow us to resume execution without access to the serialization data. The reexecution code paths are actually mostly the same as the init system configuration reloading code paths, which guarantees that reexecution (which is probably more seldom triggered) gets similar testing as reloading (which is probably more common).
Starting the work of removing shell scripts from the boot process we have recoded part of the basic system setup in C and moved it directly into systemd. Among that is mounting of the API file systems (i.e. virtual file systems such as /proc, /sys and /dev.) and setting of the host-name.
Server state is introspectable and controllable via D-Bus. This is not complete yet but quite extensive.
While we want to emphasize socket-based and bus-name-based activation, and we hence support dependencies between sockets and services, we also support traditional inter-service dependencies. We support multiple ways how such a service can signal its readiness: by forking and having the start process exit (i.e. traditional daemonize() behaviour), as well as by watching the bus until a configured service name appears.
There's an interactive mode which asks for confirmation each time a process is spawned by systemd. You may enable it by passing systemd.confirm_spawn=1 on the kernel command line.
With the systemd.default= kernel command line parameter you can specify which unit systemd should start on boot-up. Normally you'd specify something like multi-user.target here, but another choice could even be a single service instead of a target, for example out-of-the-box we ship a service emergency.service that is similar in its usefulness as init=/bin/bash, however has the advantage of actually running the init system, hence offering the option to boot up the full system from the emergency shell.
There's a minimal UI that allows you to start/stop/introspect services. It's far from complete but useful as a debugging tool. It's written in Vala (yay!) and goes by the name of systemadm.
Now, whether those benefits are a big enough deal to you are a completely different story, but just because they aren't important to you doesn't discount them as still being benefits. You also need to take into account the issues that systemd presents, which there are plenty of sites and posts that go into that (I've written several on this forum about the things I dislike about systemd, so I'm not some fanboy -- I'd much prefer to stick with Slackware's init system).
Thanks for the hints! I guess the word "incorrect" is a bit extreme when describing my summary and implied comparison with the actual BSD style init. Incomplete would be more appropriate.
Indeed, I was only looking at the freedesktop.org's page and considered that you can easily obtain the majority of the so called benefits by using the simple (available and basic) Linux commands/tools, maybe with the help of some simple scripting.
Out of your pasted long list that you took from his blog, which I also tried to read, ended up in the FAQ section - "eulogy" and closed the tab, there are only 2-3 items that are an improvement/benefit, the rest are compatibility/support/incomplete&future developments.
I guess I'm unsubscribing from this thread, fearing that I'll annoy someone else or even worse, bore Didier again. My scope has been fulfilled, I'm happy that this is still discussed and hope that it will reach out and influence in a positive way. I love Slack to much to see it getting crippled by whatever fancy (and sponsored) Redmond-like svchost.exe Linux port
I am sick of ignorants who happened to read somewhere, everywhere, that SystemD sucks and so on...
Long story short, SystemD is a little crap which do its job. And gives some advantages, beyond probably better boot time.
In other hand, our BDFL looks being quite happy with the actual in-house init system, so the SystemD is not our bussiness (yet).
With all respect, I will show to SystemD "hatters" who dare to blurp in the Slackware forum, this emoticon: :fu:
PS. You ever thought that the "SystemD Political Issue" could be just a social experiment made by some Three Letters Company about people's mass manipulation, aka social engineering?
In fact, the SystemD was dramatic widely adopted, by all major Linux distributions, even by the so reticent Debian.
Last edited by Darth Vader; 10-23-2017 at 09:43 PM.
It's cheaper than going to the zoo and watch monkeys throw poo at the audience, but I've never had a desire to see that either. (Mainly because I'd be in the audience.)
There are ample resources on the web to learn about systemd, both pro and con. There are many distributions you can run to see how well it works for you, so you can see who (if any) of the pros or cons were BSing you or using old information. If you like systemd better, change distro.
@SCerovec
It doesn't really look to be any conspiracy around here, but only some tasty sarcasm, which is part of a healthy rational thinking.
Nevertheless, regarded objectively, there are real driving forces behind these new trends/implementations, systemd included, and some of them are obviously commercial by nature, although Monsieur Poettering, a RedHat employee, denies that blatantly. Funny enough, it's again RedHat, the very ones that continuously messed up their distributions some 15-20 years ago, exactly by adding mostly faulty (not properly functional) layers of abstraction (interfaces) over the system configuration.
[snip]
There You got it buddy, the essence of any conspiracy:
1. secretive - non public (hidden or non obvious)
2. motivation
3. denial
Didn't see the trees of the wood? case closed.
Weather systemd is useful, compares in performance or reliability, doesn't change the way it was forcibly put into the community.
There really is no "conspiracy"; it's simply monetary benefit and a higher leverage of
control over the ecosystem.
> Weather systemd is useful, compares in performance or reliability, doesn't
> change the way it was forcibly put into the community.
Agreed. I would write it "whether" rather than "weather", though.
I always found the change in debian a lot more interesting since systemd existing
is only one thing of the whole aspect. And that Fedora "adopted" it is no surprise
given who paid for systemd - but how did this get into debian? Who voted for it?
I mean the answers are obvious. Developers decided this question. I found this to
be the by far biggest issue in the systemd-debate.
Apropos debate:
> Long story short, SystemD is a little crap which do its job. And gives some
> advantages, beyond probably better boot time.
This may or may not be - however had, it is often compared to e g. sysvinit.
And I do not understand this comparison if what systemd does is a lot more
than sysvinit.
This is like comparing a bike with an airplane and wondering why you can not
use the bike to reach an island. (Though in this case, the systemd-airplane
is not the one to be trusted to fly a long time ...)
abga:
> I guess I'm unsubscribing from this thread, fearing that I'll annoy
> someone else or even worse, bore Didier again.
You mean the thread will be locked and discussion banned because someone
exercises control over others? I think that would say a lot more about the
person who bans such discussions than it does about anyone participating
in such a discussion.
bassmadrigal wrote:
> As for "no obvious benefits", did you miss the opening paragraph on
> freedesktop.org's page on systemd?
Written by the authors - you think that is an objective analysis?
Seriously?
And I am not even saying whether any of it is true or not. I am simply
wondering why you quote as-is verbatim. It's like picking up a company
PR and propagating it. I mean, come on dude ... you think that the
folks who wrote systemd would EVER write anything negative about
systemd?
bassmadrigal wrote:
> Now, whether those benefits are a big enough deal to you are a completely
> different story, but just because they aren't important to you doesn't
> discount them as still being benefits
And neither does it make ANY of the purported claims to be real "benefits".
I manage my whole *nix systems via ruby, for example, since almost 2
decades by now. I mostly batch-compile everything from source unless
there are reasons to not do so (a few being very long compile cycles).
I can not relate to any of the "benefits" as I do not see why or how
I could profit from any of the behaviour. But this use case may well
differ. If systemd works for you, that's great! And if it does not
work for other people, then leave them alone.
The LFS/BLFS project does the only sane way here - they offer BOTH
a systemd variant and a systemd-free variant. That is IMO the only
logical way to go about it. It's about choice. And that was what
did not happen in e. g. debian (though now you do have a choice
thanks to the devuan guys).
Distribution: Slackware/Salix while testing others
Posts: 1,718
Rep:
Quote:
Originally Posted by shevegen
The LFS/BLFS project does the only sane way here - they offer BOTH
a systemd variant and a systemd-free variant. That is IMO the only
logical way to go about it. It's about choice. And that was what
did not happen in e. g. debian (though now you do have a choice
thanks to the devuan guys).
You miss an important point though, systemd was/is not designed to play with other options, it insists on using its ball on its court by its rules. So, the option is systemd or not, both cannot occupy the same space at the same time or big bang and all.....
Has anyone compared the long famed "faster boot time" of system(devil) lately?
I have a rig that I test full bare metal installs on an it's not a new rig by any means. It's a 2007 Inspiron 1520, 2GHz C2D, 4GB RAM, 800MHz FSB. Occasionally I load up Linux Mint on it to see what has changed, added, removed etc. I must say that there is no faster boot with systemd. Honestly I think that it takes longer from boot to DE than Slackware (I am using Cinnamon DE on Slackware just like LM), although I have not timed it.
Can we have a vote somewhere that any time a systemd thread shows up in the forum it gets instantly locked?
Has anyone compared the long famed "faster boot time" of system(devil) lately?
I have a rig that I test full bare metal installs on an it's not a new rig by any means. It's a 2007 Inspiron 1520, 2GHz C2D, 4GB RAM, 800MHz FSB. Occasionally I load up Linux Mint on it to see what has changed, added, removed etc. I must say that there is no faster boot with systemd. Honestly I think that it takes longer from boot to DE than Slackware (I am using Cinnamon DE on Slackware just like LM), although I have not timed it.
For most distributions using systemd, all it means is that more crap can bet set to start during boot up. My Slackware system boots up faster than my CentOS 7.4 system. It's the same story with one of my Raspberry Pis that is running CentOS vs the Pi running Slackware. In both cases, even if I disable most of what is started during boot, the output of 'ps aux' in CentOS is double the length of Slackware.
Quote:
Originally Posted by Skaendo
Can we have a vote somewhere that any time a systemd thread shows up in the forum it gets instantly locked?
I agree. Slackware and any other distribution running systemd are so very different. Trying to compare them is pointless. Systemd in the Slackware forum should just be considered off-topic and the thread should be moved to the "Linux - General" forum.
> I guess I'm unsubscribing from this thread, fearing that I'll annoy
> someone else or even worse, bore Didier again.
You mean the thread will be locked and discussion banned because someone
exercises control over others? I think that would say a lot more about the
person who bans such discussions than it does about anyone participating
in such a discussion.
Discussing systemd does not cause locking of threads... it's when the topic gets heated and forum rules start getting violated. Unfortunately, discussions like these frequently heat up, so it does occasionally cause the threads to get locked... but it is only when the forum rules get violated repeatedly after warnings from mods.
Quote:
Originally Posted by shevegen
bassmadrigal wrote:
> As for "no obvious benefits", did you miss the opening paragraph on
> freedesktop.org's page on systemd?
Written by the authors - you think that is an objective analysis?
Seriously?
And I am not even saying whether any of it is true or not. I am simply
wondering why you quote as-is verbatim. It's like picking up a company
PR and propagating it. I mean, come on dude ... you think that the
folks who wrote systemd would EVER write anything negative about
systemd?
Of course getting information from the people trying to push it out may not provide the most biased perspective... but it doesn't automatically invalidate the information. Do people not believe that Slackware tries to be the most Unix-like distro since it is included on slackware.com? Do you discount any information about Ford vehicles from the Ford website because they are biased and won't write anything negative about their vehicles? The reason I provided what I did is because abga listed those specific websites and stated there were no obvious benefits found on them. I felt that they did list benefits, so I replied to that in my post. Whether or not I agree with those benefits had nothing to do with the text I included from those sites.
Just because there might be negatives to systemd doesn't mean there aren't positives as well. However, the most common thing I see listed is that the "only benefit" is that it speeds up the boot process. This was not an immediate goal of systemd. They weren't out there to make a faster init, but many of the things they did (most notably, parallelization) led to this nice side-effect.
Quote:
Originally Posted by shevegen
bassmadrigal wrote:
> Now, whether those benefits are a big enough deal to you are a completely
> different story, but just because they aren't important to you doesn't
> discount them as still being benefits
And neither does it make ANY of the purported claims to be real "benefits".
I manage my whole *nix systems via ruby, for example, since almost 2
decades by now. I mostly batch-compile everything from source unless
there are reasons to not do so (a few being very long compile cycles).
I can not relate to any of the "benefits" as I do not see why or how
I could profit from any of the behaviour. But this use case may well
differ. If systemd works for you, that's great! And if it does not
work for other people, then leave them alone.
Just because *you* can't relate to the benefits doesn't mean they don't resonate with someone else. As I've said countless times in this forum, I'm no systemd fanboy. If I had my way, it would go away. I'm extremely glad that Pat and team have been able to avoid it thus far and I'm grateful for the projects that have prevented the addition of systemd (logind, eudev, etc). But maybe I could provide the following, which is a copy/paste from my post here. This is a decent breakdown of what are commonly listed as benefits for systemd and what they could do. I also add my personal belief on if the benefits outweigh the costs on that specific benefit.
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.
The benefits (and the costs) are there and it is up to the individual if the benefits outweigh the costs.
Quote:
Originally Posted by shevegen
The LFS/BLFS project does the only sane way here - they offer BOTH
a systemd variant and a systemd-free variant. That is IMO the only
logical way to go about it. It's about choice. And that was what
did not happen in e. g. debian (though now you do have a choice
thanks to the devuan guys).
The choice ultimately comes down to what is pushed out to the endusers based on decisions by the developers. If the OS maintainers decided they didn't want to possibly double their workload by supporting two init systems, I totally understand that. Managing a handful of SlackBuilds for SBo can take enough of my time for just one system (Slackware 14.2), I can't imagine the extra work to maintain a whole distro, let alone with two different init systems. The problem nowadays is Person A expects Developer B to do what is best for Person A, but when Person A is not a paying customer, Developer B is free to do what they want. Person A is free to switch to Developer C if they offer what Person A is looking for, but unless Person A becomes a developer, they are only able to get what Developers A-Z provide to them. Do I wish Debian stayed away from systemd? Sure. With the size of that distro (and all its spinoffs), it would make it harder for systemd to become the defacto init. But ultimately, it is the developers' choice and if they only want to support one init system, then I don't fault them for it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
I have more, but I'm afraid AlienBob will jump over me and call me a bad elitist.
case closed.
