systemd is destructive

[arochester]

15 Advanced Linux Interview Questions and Answers - http://linoxide.com/linux-how-to/advanc ... s-answers/

9) systemd over init system, What do you think?

Systemd is well designed. It was conceived from the top, not just to fix bugs, but to be a correct implementation of the base system services. A systemd, may refer to all the packages, utilities and libraries around daemon. It was designed to overcome the shortcomings of init. It itself is a background process which is designed to start processes in parallel, thus reducing the boot time and computational overhead. It has a lot other features as compared to init while Sysvinit was never designed to cope with the dynamic/event-based architecture of the current Linux kernel. The only reason why we still use it today is the cost of a migration.

Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-install, localectl). In Debian, they use the existing configuration files without breaking compatibility.
Systemd makes the boot process much simpler, entirely removing the need to specify dependencies in many cases thanks to D-Bus activation, socket activation, file/inotify activation and udev integration.
Systemd supports SELinux integration while SysV doesn't
Systemd can handle the boot process from head to toe, without needing to use any of the existing shell scripts. Systemd extends the logging features of the system in many ways with journald, and can remain integrated with the existing rsyslog daemon. Logs are in a structured format, attributed to filename, line of code, PID and service. They include the early boot (starting from initramfs). They can be quickly filtered and programmatically accessed through an efficient interface.
Systemd unit files, unlike SysV scripts, can usually be shipped by upstream, or at least shared with other distributions (already more than 1000 existing unit files in Fedora) without any changes, the Debian specifics being handled by systemd itself.
Systemd is incredibly fast (1 second to boot). It was not designed with speed in mind, but doing things correctly avoids all the delays currently incurred by the boot process.
The transition plan is easy, since existing init scripts are treated as first-class services: scripts can depend (using LSB headers) on units, units can depend on scripts. More than 99% of init scripts can be used without a modification.
It is not just init. It unifies, in fewer lines of code, everything that is related to starting services and managing session groups: user login, cron jobs, network services (inetd), virtual TTY management… Having a single system to handle all of that allows us to remove a lot of cruft, and to use less memory on the system.

[Danielsan]

Cool, this seems written by Pottering himself... This is the same stuff from a lot of time and I don't want taking out the counter arguments like, for example, the famous PID 1 issue.

But is interesting the reason behind Google choice, it says about systemd:

SysV vs Debian Insserv vs Upstart vs Systemd: Systemd

• Originally went into Fedora for testing and tuning.
• Not yet included in server distributions like RHEL.
• Very disruptive, big redesign of how Linux systems boot. It replaces many core parts of low level Linux.
• On the plus side, Lennart has done a very good job in explaining the rationale behind the required changes and the gains.
• Ideal design does not rely on dependencies being specified by the packagers, they are auto computed on demand. Real life is sometimes otherwise though, and requires manual dependencies.
• Like upstart, given boot order not specified, could trigger race conditions in our scripts or daemons, and only on 1% of our machines.
• Systemd sounded simple, but the implementation and getting everything right is much more complex than we're comfortable with.

http://marc.merlins.org/linux/talks/ProdNG-LISA/ProdNG.pdf

If we are looking for a better init system against sysv all the alternatives are better, when we confront systemd with the rest of the alternatives those are pretty good as well, the main difference is systemd does more than initializing the system, for many that is a problem for other it is better. There is nothing absolute in systemd if not the fact it was pushed and promoted by Red Hat and all the projects related directly and indirectly with Red Hat decided to strictly integrate it like Gnome3 which relies on systemd.

[arochester]

Date of PDF?

Not yet included in server distributions like RHEL.

systemd in RHEL repository June 2014

[phenest]

Hands up all those against systemd for whatever reason.

Now put your hand down if you can't provide a link or quote to a source those is neither out of date or speculative/opinionated.

Hmmm. How strange. No one has got their hands up.

[oswaldkelso]

Has silly season started, I thought it was spring.

Hands up all those for systemd for whatever reason.

Now put your hand down if you can't provide a link or quote to a source those is neither out of date or speculative/opinionated.

Hmmm. How strange. No one has got their hands up.

By the way, how does this date thing work with the Unix philosophy.

[phenest]

Perhaps you should read some of arochester's posts on this thread. There have been plenty of links to sources that support systemd. Trouble is, those who are against systemd, think they're all written by Poettering.

[acewiza]

I posted on the previous page that Google on its Debian derivated doesn't use systemd but insserv and startpar.

So what? Since when is Google the standard by which init systems are judged?

I know the monkey-see monkey-do thing is tempting to follow when you don't know what you are talking about, but still...

[Danielsan]

@ arochester & Phenest

It's not my fault if this document is dated 2013, what you can learn about it is since the 2013 google use Debian without systemd. Actually as systemd is a part of strategy of Red Hat I believe is pretty natural that now RHEL is released with systemd.

As a desktop user I believe the benefit of systemd are very few, initially I wasn't again systemd and I was using it in a couple of computers. I was also ingenuously convinced that we would have had by Debian the options to select which init using. But after it came out all the crappy thing, Gnome3 always more bonded with systemd, an arguable commitee, the arrogance of Poettering a general behavior that nobody is allowed to criticize systemd (as well as Gnome3).

For many years I had a laptop with Testing and Xfce4, it had a lot of issue with systemd because of Xfce4 was init agnostic and it had to fix itself to use systemd, the laptop never speed-up the boot because systemd. I have to learn using something unwanted, even if we are in do-ocracy I have my reason to be against systemd. I also wrote I gave up to find an alternative, eventually I decided to close the nose when I use Debian but this doesn't means I must stop to be against it.

@ acewiza

Probably a monkey would reply better, if a big IT player decides to not use systemd maybe we can't stop to say systemd is better by default as a "mantra", despite all the enhancement it brings within it, Google uses neither sysv but insserv and startpar for its server.

[dasein]

'blah-blah-Argument from authority-blah'

'Oh yeah? Ad hominem-blah-blah-blah'

'Well, Double ad hominem on you!'

'blah-blah Straw man-blah-blah'

'Ha! Red herring AND non-sequitur-blah-blah! So there!'

'blah-blah-Bandwagon fallacy!! False dichotomy!'

ad nauseam

The end result of all this "reasoned debate"...

[dasein]

It is about time to close this thread.

With all due respect, methinks that time was 2016-09-20 19:10 (about one minute after it was started).

FDN already has roughly a dozen existing troll threads on systemd; it just doesn't need another. Anyone who misses the "good old days" of that community meltdown can go read any of those existing threads; aside from a couple of neologisms and gratuitous references to Nazism, they read exactly like this one.

(See also: viewtopic.php?f=3&t=119178)

[Fernando Negro]

After having I watched, a few days ago, a video presentation concerning the launch of a "systemd-less" Debian-derived distribution (https://www.youtube.com/watch?v=wMvyOGawNwo) I was immediately surrendered to the arguments presented by the people who criticise the uniform adoption of "systemd" by all the major GNU/Linux distributions.

But, having those arguments (that I heard) been only about the advantages of having a diversity of evolution, in the way that GNU/Linux continues to be developed, I took yesterday the opportunity to expose, in a forum of that same "systemd-less" Debian-derived distribution, what I see as a big security problem that was created by the adoption of "systemd" - having I also taken the opportunity to call people's attention to a similar problem, that was created by the recent addition of another daemon to the Debian family of distributions - called "zeitgeist" - this last one, fortunately, not one that people are now forced to install.

And, because I think that these are serious concerns that should be shared with other (Debian) GNU/Linux users, I'm then "copy-pasting" what I've written (https://dev1galaxy.org/viewtopic.php?id=1986) in that other forum to here.

Writing as a user, that has adopted GNU/Linux in order to have more security on his computer, the following are (besides the very good principles of diversity in evolution - that should also be applied to "init" systems, and other pieces of the GNU/Linux operating system - to allow us to compare which ones are the best results that better suit each particular situation) the reasons why I really don't like "systemd".


First of all,

Whenever I hear of "unification" and "uniformization" applied to human organizations or development (in situations where they are not needed, for practical reasons, and don't make people's life better) I raise my guard. Because, it automatically makes me thing of the same principle applied to bigger/political organizations.

The more centralized the power of decision is, the less democratic it becomes. Since that, it makes it much harder for minority voices to be heard, and doesn't allow for different groups to follow each one their own path.

(When I speak of this happening in "bigger/political organizations", just look at the example of small Iceland, where the people easily changed their own government when they realized that it was corrupt, and compare that to the situation in the EU, where this super-state repeatedly imposes its will on whole different countries, and doesn't allow them to do things their own way.)

And, I've heard part of this same principle being discussed by the people who criticise the uniform adoption of "systemd" by the major GNU/Linux distributions.

But, the main problem I see with the adoption of "systemd" is (not even this one - but) one that relates to security.

(Important note: The following, is something that I'm writing as a mere user, with limited knowledge of how GNU/Linux works. And, therefore, I might be wrong concerning some of the details of what I describe. But, the general principle of such concern of mine, is something that I believe to the undoubtedly true...)

And, what I mean by this is,

(From the limited knowledge I have of what the different "init" systems do - and, knowing that "systemd" is not now responsible for everything yet,)

If you want to install a piece of malware on a computer, that surveils/controls the different aspects of its operating system...

1) In a pre/non-"systemd" environment, in order to surveil/control all those same different components, you will have to build a piece of software that does that altogether, including possibly at the same time - which results in a rather complex piece of software whose (complex - and, therefore big) activity might be spotted by the operating system or its user.

2) While, on the other hand, if you already have a daemon running, that controls all those same different aspects/components of the operating system, if you want to install a surveilling/controlling malware, all that you have to do is "stick" to that same daemon. That is, if you want to surveil/control the different aspects/components of the operating system altogether, there's no need to go any further than infecting (or remain connected to) one single daemon. Which,

a) not only reduces greatly the complexity of such malware - and, by that,

I) reduces greatly the probability of it being spotted, from its reduced size and activity, or

II) makes it possible for it to operate within certain limits/restrictions - like those of a small chip implanted on your hardware (ex: https://libreboot.org/faq.html#intel) - but also

b) serves as a perfect hiding place and, above all, *cover* (that couldn't be used before the existence of "systemd") for the activity of such piece of malware - because, if a knowledgeable user notices something odd and asks "What is this active program that is surveilling and controlling all these different aspects of my computer?" his/her reaction now will be "Oh, that's just 'systemd'...".

It's a similar security risk as the one created by the "zeitgeist" daemon, whose development is sponsored by Canonical...

If you have a daemon that already keeps a log of all of the user's most important activity,

You don't even need to have a piece of malware installed on the computer, all the time, to know what the user is up to.

All that you need now, is to somehow read that same log, whenever you can - like, when a user decides to try out one of the many proprietary programs that Ubuntu encourages people to, on its "Software Centre" (and, more specifically, one that behaves like this: http://linux.slashdot.org/story/07/08/2 ... ox-profile) - and there goes a whole log of the user's activity into the hands of Big Brother.

[Head_on_a_Stick]

Yes, yes, more code == more bugs, this is nothing new

@Admin, please append this thread to the locked systemd "discussion", we don't need any more of this.

@OP, if you don't like systemd then don't use it, there are several high-quality operating systems available that do not use it.

Code: Select all

Puffy:~$ uname -a
OpenBSD Puffy.lan 6.3 GENERIC.MP#173 amd64
Puffy:~$

^ I can recommend that one

[Fernando Negro]

Head_on_a_Stick,

The point I'm raising has nothing to do with "bugs"...

It's a whole separate discussion, about another problem that "systemd" and another daemon create.

A problem that I think that most people are not even aware of (or have ever thought about).

And, a problem that, because of its seriousness, I really don't think the discussion of which should be "locked" or hidden.

[Fernando Negro]

Nevertheless,

I now realize that I have made the post in the wrong section.

This type of post/thread should be in the "General Discussion" or "Debian Development" sub-forums instead.

(So, if a moderator could move it...)

I really think that these are most serious and pertinent issues, in relation to security, that everyone (be it users or developers) should be aware of - or really think about.

[Wheelerof4te]

^If systemd is such a big problem for you, why are you using Debian? Debian devs have decided to ship systemd as default init/service software in Jessie. It's been 3+ years now. While heading to Buster, it's impossible to revert that decision.
Along with OpenBSD and other BSDs, you have several non-systemd distros such as MX Linux. Maybe try those?