Reply to post: Re: Also systemd is the svchost.exe for Linux

Linux greybeards release beta of systemd-free Debian fork

asdf Silver badge

Re: Also systemd is the svchost.exe for Linux

>What is the similarity of design (and philosophy) between systemd and svchost.exe?

Sorry in advance for length. Stolen from http://forums.funtoo.org/topic/626-my-2-cents-on-systemd/page-5 but hits my points better than I could.

"It's simple really: systemd is wrong for Linux.

It may be right for something else, but not (default) Linux.

It violates the "UNIX Philosophy", which is best summarized by the famous quote from the inventor of the UNIX-pipe, McIlroy:

Quote

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

This is important for very many reasons.

If one non-critical functions fails, it should not mean that the entire system becomes unusable as it has been on Windows where svchost.exe is used to run almost any arbitrary process and each of those svchost.exe processes can "host" several sub-functionalities. This results in that if any of those sub-functionalities "goes nuts", even if it's one that the user does not care about at all, the entire process with all its hosted sub-functionality is immediately affected. Also made obvious by the svchost.exe example is how it makes granular permissions management impossible even with third party tools like anti-virus and firewalls as if you have even ONE svchost.exe sub-functionality requiring network access to do its job, you must grant network access to the entire process and thus to everything else hosted by the same binary and this can lead to very undesirable security implications.

I use svchost.exe as the example because we Linux- (and UNIX- in general) users used to laugh at Windows' poor design in this regard for these reasons... but now when Windows is moving more and more away from this design, Linux is moving to it.

What's even worse is that there used to be several alternatives to chose from regarding system init provider, but now there are only two main ones and one that is being migrated away from, so if any major flaw is discovered in for example systemd, there is now effectively only ONE choice left.

With software now increasingly being made specifically designed for systemd, they build bi-directional dependencies so that the user can not really choose individual components anymore, which again can cause very bad security results as well as very much waste in system resources.

Imagine for example if there is a bug that causes the boot process to take half an hour each time using systemd and OpenRC can't be used because the core functionality of the system specifically depends on systemd... This can cause very expensive fines for corporations with Service Level Agreements to honor.

The migration to systemd results in user-unfriendly, bloated, unnecessarily restricted and potentially very costly systems.

It could be AN option, but should definitely not become the ONLY option as it is becoming now.

If you want a Windows/Mac-like system where the user is put out of control through the assumption that the programmers will be able to predict every usage scenario and never write flawed code so no options are needed, then it should be considered as an option.

I could go on, but I fear I have already passed the wall-of-text/TL;DR-threshold.

P.S.: The example scenarios in this post are all ones that I have personally encountered, so not at all hypothetical."

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019