SCIENTIFIC-LINUX-USERS Archives

January 2021

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Sun, 24 Jan 2021 13:24:36 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (24 lines)
On Fri, Jan 22, 2021 at 9:20 PM Yasha Karant <[log in to unmask]> wrote:
>
> I had not heard the history of SystemD in any detail.  What, if any,
> were the software engineering and design justifications for SystemD?  I

The unreliability of SysV init scripts, especially for dependent
services, and the lack of logging for extremely low level operations
such as booting up. There have been many attempts to resolve the init
script issue: i rather liked "deamontools" by Dan J. Bernstein, but he
unfortunately had an insane licensing model that prevented anyone from
including it for years. (You could not publish binaries built from
modified code, if you wanted patches they had to be compiled by the
user, not the vendor, even if the vendor carefully published the
patches alongside the original source code.)

It's since gotten way, way out of hand, replacing the DHCP and DNS and
killing user processes when you log out, which broke "nohup" and "tux"
for interrupted SSH sessions, and killing the process without any log
or notification whatsoever "because no one would want that, they can
just edit tux if they need to. *That* one led to screaming. The
replacement of /etc/resolv.conf with a symlink pointing elsewhere led
to fracturing a lot of network configuration tools for servers. It
really is quite dangerous.

ATOM RSS1 RSS2