Is systemd an NSA attempt?

[Rich]

https://muchweb.me/systemd-nsa-attempt

Quoting from the URL above:

Is systemd really an attempt of NSA to corrupt GNU distributions?

Ignoring for the moment the various technical problems with systemd, I
have my suspicions that its provenance and scope are cause for alarm.

Systemd comes from Red Hat. Red Hat, in the Linux world, is the company
with the largest ties to the US government and the various state
security organizations around the world--including NSA. The US
government (DoD) is Red Hat's number one customer. Red Hat also happens
to be Lennart Poettering's employer.

The Linux kernel, I believe, is clean. As long as Linus lives, you're
not going to subvert the kernel. Let's just assume that is true for the
sake of argument. If you can't get into the kernel, what is your next
option? You need something low level (PID 1?), ubiquitous, and vast in
scope and complexity.

This describes systemd perfectly. It was almost like it was designed to
touch as much of a Linux system as possible. It has hooks into some many
different subsystems and APIs that it's almost impossible to build a
modern distro with current software without pulling in systemd as a
dependency. This happened almost overnight, and I think there are
malicious forces at work here.

...

[Marko Rauhamaa]

Rich <ri...@example.invalid>:

> Is systemd really an attempt of NSA to corrupt GNU distributions?
>

> [...]

>
> Systemd comes from Red Hat. Red Hat, in the Linux world, is the
> company with the largest ties to the US government and the various
> state security organizations around the world--including NSA. The
> US government (DoD) is Red Hat's number one customer. Red Hat also
> happens to be Lennart Poettering's employer.

Well, why not mention the obvious: RedHat is the main promoter of
SELinux, which was developed by the NSA. The tentacles of SELinux are
everywhere in the kernel.

> This describes systemd perfectly. It was almost like it was designed to
> touch as much of a Linux system as possible. It has hooks into some many
> different subsystems and APIs that it's almost impossible to build a
> modern distro with current software without pulling in systemd as a
> dependency. This happened almost overnight, and I think there are
> malicious forces at work here.

Better stick to the technical merits. I don't particularly like systemd,
but it's really the only contender out there.

Unix came with several elegant principles (eg, "everything is a file"),
but I suppose the principles became evident only years after the fact.
What's missing from systemd is the crystallization of similar
principles. Lennart Poettering is communicating through his code; I
suspect it will be up to others to come up with the systemd philosophy.


Marko

[Dan Espen]

The systemd philosophy couldn't be more obvious.
It takes all the things that a myriad of start up and shutdown shells
were doing, added features that keep those same services running and
turned them into a bunch of keyword/value pairs in plain text files.

So, gone, are the hundreds of shells, directory nests, function
shells, and individually crafted messages. Now we have a nice
uniform well documented set of keywords in single files that cover the
functions of start, restart, and stop. One simple file for each
service. Couldn't be simpler.

As far as an NSA attempt? That's nuts.
Remember, paranoia strikes deep.
Keep believing this stuff and you'll wind up in a ward somewhere.


--
Dan Espen

[RS Wood]

On 2016-12-11, Rich <ri...@example.invalid> wrote:
> https://muchweb.me/systemd-nsa-attempt
>
> Quoting from the URL above:
>
> Is systemd really an attempt of NSA to corrupt GNU distributions?

Occam's razor says ... "NO."

Can't say i'm a huge fan of systemd, though it seems to be working
well enough on my laptop. Don't believe I'd want it on a server.
Some diabolical scheme, though? Not likely.

[Andy K.]

On Mon, 12 Dec 2016 00:05:57 +0000 (UTC)
RS Wood <r...@therandymon.com> wrote:

> On 2016-12-11, Rich <ri...@example.invalid> wrote:
> > https://muchweb.me/systemd-nsa-attempt
> >
> > Quoting from the URL above:
> >
> > Is systemd really an attempt of NSA to corrupt GNU distributions?
>
> Occam's razor says ... "NO."

Betteridge concurs.

--
AndyK

[Marko Rauhamaa]

Dan Espen <des...@verizon.net>:

> Marko Rauhamaa <ma...@pacujo.net> writes:
>> Unix came with several elegant principles (eg, "everything is a
>> file"), but I suppose the principles became evident only years after
>> the fact. What's missing from systemd is the crystallization of
>> similar principles. Lennart Poettering is communicating through his
>> code; I suspect it will be up to others to come up with the systemd
>> philosophy.
>
> The systemd philosophy couldn't be more obvious.
> It takes all the things that a myriad of start up and shutdown shells
> were doing, added features that keep those same services running and
> turned them into a bunch of keyword/value pairs in plain text files.

Reducing your system to key/value pairs is not much of a philosophy,
even if it were true

Of course, at a trivial level, the systemd unit files contain little
more than key/value pairs, but that is not saying much more than that
they consist of 0's and 1's. First of all, the values have key-specific
syntax. Just look at the mile-long description under the section
"COMMAND LINES" or the systemd.service(5) man page.

Secondly, just like all developed rule languages, systemd unit files are
riddled with ad hoc semantic interdependencies that don't follow any
particular pattern. Take for example the "RestartForceExistStatus" entry
on the same man page.

Clearly, some philosophical justification/clarification is called for.
What I'd like to see is a treatise about how to develop native,
systemd-aware services. What should the service take into account, and
how should it interact with its surroundings?

Something like this:

<URL: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html>

only for systemd.

Also, what are the roles and responsibilities? Who should write the unit
file(s) for the service:

1. the sysadmin

2. the integrator (eg, RedHat)

3. the developer


Marko

[Dan Espen]

Marko Rauhamaa <ma...@pacujo.net> writes:

> Dan Espen <des...@verizon.net>:
>
>> Marko Rauhamaa <ma...@pacujo.net> writes:
>>> Unix came with several elegant principles (eg, "everything is a
>>> file"), but I suppose the principles became evident only years after
>>> the fact. What's missing from systemd is the crystallization of
>>> similar principles. Lennart Poettering is communicating through his
>>> code; I suspect it will be up to others to come up with the systemd
>>> philosophy.
>>
>> The systemd philosophy couldn't be more obvious.
>> It takes all the things that a myriad of start up and shutdown shells
>> were doing, added features that keep those same services running and
>> turned them into a bunch of keyword/value pairs in plain text files.
>
> Reducing your system to key/value pairs is not much of a philosophy,
> even if it were true

Of course, it is true. The fact that for EXEC type keys command line
values need more definition is a feature.
If systemd had gone with XML or some other arcane syntax the cries of
foul would be deafening.

> Of course, at a trivial level, the systemd unit files contain little
> more than key/value pairs, but that is not saying much more than that
> they consist of 0's and 1's.

Your point here is lost on me.
These config files could have contained a meta language, or even
worse a script or programming language, making them impossible to
parse by software.

> First of all, the values have key-specific
> syntax. Just look at the mile-long description under the section
> "COMMAND LINES" or the systemd.service(5) man page.

I just read it, I think mile-long is unfair.

"This syntax is intended to be very similar to shell syntax, but only
the meta-characters and expansions described in the following
paragraphs are understood."

That pretty much explains all the rules.

> Secondly, just like all developed rule languages, systemd unit files are
> riddled with ad hoc semantic interdependencies that don't follow any
> particular pattern. Take for example the "RestartForceExistStatus" entry
> on the same man page.

Assuming you meant:

RestartForceExitStatus=
Takes a list of exit status definitions
that, when returned by the main service process, will force
automatic service restarts, regardless of the restart setting
configured with Restart=. The argument format is similar to
RestartPreventExitStatus=.

I'm missing the problem.

> Clearly, some philosophical justification/clarification is called for.

First you have to make the case.

> What I'd like to see is a treatise about how to develop native,
> systemd-aware services. What should the service take into account, and
> how should it interact with its surroundings?
>
> Something like this:
>
> <URL: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html>
>
> only for systemd.

No. Linux daemons are Linux daemons. SystemD is not supposed to change
that.

> Also, what are the roles and responsibilities? Who should write the unit
> file(s) for the service:
>
> 1. the sysadmin
>
> 2. the integrator (eg, RedHat)
>
> 3. the developer

As with the prior initd scheme, all of the above.
If the developer puts systemd config files in the package,
the integrator is very likely to use them. Intact if possible.

The sysadmin needs the ability to support locally developed services
so having the sysadmin do some of the files is a feature.

I still think systemd does an admirable job of replacing complexity
with order without loss of flexibility and adding function (restart).

I just don't get all the complaints about systemd. The old initd
approach was a mess.

--
Dan Espen

[Richard Kettlewell]

Dan Espen <des...@verizon.net> writes:

> Marko Rauhamaa <ma...@pacujo.net> writes:

>> What I'd like to see is a treatise about how to develop native,
>> systemd-aware services. What should the service take into account,
>> and how should it interact with its surroundings?
>>
>> Something like this:
>>
>> <URL: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html>
>>
>> only for systemd.
>
> No. Linux daemons are Linux daemons. SystemD is not supposed to change
> that.

It’s a bit more complicated than that. One of the possibilities is that
the service notifies systemd that it has completed setup. See for
instance [1] in particular the bit about Type=notify, and [2] for the
API. Another possibility is socket activation, which to some extend was
supported already via inetd, but AIUI has grown in scope with systemd.

[1] https://www.freedesktop.org/software/systemd/man/systemd.service.html
[2] https://www.freedesktop.org/software/systemd/man/sd_notify.html

(This isn’t an answer to Marco’s question, it’s just something that such
a treatise would presumably include.)

--
http://www.greenend.org.uk/rjk/

[Marko Rauhamaa]

Dan Espen <des...@verizon.net>:

> Marko Rauhamaa <ma...@pacujo.net> writes:
>> Reducing your system to key/value pairs is not much of a philosophy,
>> even if it were true
>
> Of course, it is true. The fact that for EXEC type keys command line
> values need more definition is a feature. If systemd had gone with XML
> or some other arcane syntax the cries of foul would be deafening.

XML would be horrible. JSON, on the other hand, would have been a saner
option.

>> First of all, the values have key-specific syntax. Just look at the
>> mile-long description under the section "COMMAND LINES" or the
>> systemd.service(5) man page.
>
> I just read it, I think mile-long is unfair.
>
> "This syntax is intended to be very similar to shell syntax, but only
> the meta-characters and expansions described in the following
> paragraphs are understood."
>
> That pretty much explains all the rules.

Suppose I have a command line in a canonical form (say, a string list in
Python), do you have an algorithm to turn that into a valid ExecStart
value? I have tried and failed.

>> Secondly, just like all developed rule languages, systemd unit files
>> are riddled with ad hoc semantic interdependencies that don't follow
>> any particular pattern. Take for example the
>> "RestartForceExistStatus" entry on the same man page.
>
> Assuming you meant:
>
> RestartForceExitStatus=
> Takes a list of exit status definitions
> that, when returned by the main service process, will force
> automatic service restarts, regardless of the restart setting
> configured with Restart=. The argument format is similar to
> RestartPreventExitStatus=.
>
> I'm missing the problem.

What you have is a large selection of enumerated behaviors instead of a
tiny set of primitives that can produce any desired behavior.

>> What I'd like to see is a treatise about how to develop native,
>> systemd-aware services. What should the service take into account, and
>> how should it interact with its surroundings?
>>
>> Something like this:
>>
>> <URL: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html>
>>
>> only for systemd.
>
> No. Linux daemons are Linux daemons. SystemD is not supposed to change
> that.
>
>> Also, what are the roles and responsibilities? Who should write the unit
>> file(s) for the service:
>>
>> 1. the sysadmin
>>
>> 2. the integrator (eg, RedHat)
>>
>> 3. the developer
>
> As with the prior initd scheme, all of the above.

What you are saying is that systemd is aggravating us for nothing. It's
precisely those questions that were in chaos by the pre-systemd world.

> I just don't get all the complaints about systemd. The old initd
> approach was a mess.

Yet, you are saying systemd is not offering a way out of the mess.

Thing is, the mess wasn't bash scripts or the init.d system. The mess
was the belief that a Linux system is a collection of disparate
components delivered to the system administrator in a bag that is the
distro. Then, the system administrator fiddles with the components to
create a system in his image.


Marko

[Dan Espen]

Agreed. As I wrote that reply, I was aware of a few APIs daemons
can use to enhance their function with systemd. Any daemon that relies
on that would doubtless cause an uproar among the systemd detractors.
Those APIs are documented, there's no reason to write a systemd
treatise on the subject of daemons.

--
Dan Espen

[Dan Espen]

Marko Rauhamaa <ma...@pacujo.net> writes:

> Dan Espen <des...@verizon.net>:
>
>> Marko Rauhamaa <ma...@pacujo.net> writes:
>>> Reducing your system to key/value pairs is not much of a philosophy,
>>> even if it were true
>>
>> Of course, it is true. The fact that for EXEC type keys command line
>> values need more definition is a feature. If systemd had gone with XML
>> or some other arcane syntax the cries of foul would be deafening.
>
> XML would be horrible. JSON, on the other hand, would have been a saner
> option.

Oh please NO.

>>> First of all, the values have key-specific syntax. Just look at the
>>> mile-long description under the section "COMMAND LINES" or the
>>> systemd.service(5) man page.
>>
>> I just read it, I think mile-long is unfair.
>>
>> "This syntax is intended to be very similar to shell syntax, but only
>> the meta-characters and expansions described in the following
>> paragraphs are understood."
>>
>> That pretty much explains all the rules.
>
> Suppose I have a command line in a canonical form (say, a string list in
> Python), do you have an algorithm to turn that into a valid ExecStart
> value? I have tried and failed.

Real world, it's trivially simple.
Don't understand or know what you were up to.

>>> Secondly, just like all developed rule languages, systemd unit files
>>> are riddled with ad hoc semantic interdependencies that don't follow
>>> any particular pattern. Take for example the
>>> "RestartForceExistStatus" entry on the same man page.
>>
>> Assuming you meant:
>>
>> RestartForceExitStatus=
>> Takes a list of exit status definitions
>> that, when returned by the main service process, will force
>> automatic service restarts, regardless of the restart setting
>> configured with Restart=. The argument format is similar to
>> RestartPreventExitStatus=.
>>
>> I'm missing the problem.
>
> What you have is a large selection of enumerated behaviors instead of a
> tiny set of primitives that can produce any desired behavior.

Sorry, can't parse your answer.

>>> What I'd like to see is a treatise about how to develop native,
>>> systemd-aware services. What should the service take into account, and
>>> how should it interact with its surroundings?
>>>
>>> Something like this:
>>>
>>> <URL: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html>
>>>
>>> only for systemd.
>>
>> No. Linux daemons are Linux daemons. SystemD is not supposed to change
>> that.
>>
>>> Also, what are the roles and responsibilities? Who should write the unit
>>> file(s) for the service:
>>>
>>> 1. the sysadmin
>>>
>>> 2. the integrator (eg, RedHat)
>>>
>>> 3. the developer
>>
>> As with the prior initd scheme, all of the above.
>
> What you are saying is that systemd is aggravating us for nothing. It's
> precisely those questions that were in chaos by the pre-systemd world.

Systemd is not responsible for users getting aggravated over nothing.
The issue you posed existed before systemd.

>> I just don't get all the complaints about systemd. The old initd
>> approach was a mess.
>
> Yet, you are saying systemd is not offering a way out of the mess.

On the contrary, I'm saying systemd eliminated the mess.
The initd scripts each uniquely crafted
start/stop/restart/reload/refresh. A user or external process
had no way of knowing which of the functions were implemented.
The same applied to dependencies between services.

> Thing is, the mess wasn't bash scripts or the init.d system. The mess
> was the belief that a Linux system is a collection of disparate
> components delivered to the system administrator in a bag that is the
> distro. Then, the system administrator fiddles with the components to
> create a system in his image.

The bash or sh or whatever scripts and the directory nest was a mess.
The mess is gone with systemd. I've seen admins mess with init.d.
No admin experience with systemd. My own personal experience
is that I sometimes had to mess with initd. Never with systemd.

What seems to be lost with the systemd detractors is that Solaris
long ago changed to not only start and stop services, but also to
monitor and restart services. Initd had no chance of ever reaching
that goal. Systemd provides everything needed to get there.
The average home user doesn't really care that much. But data centers
care a lot. Linux needed systemd or some other monitor/restart
system to hold it's own. Crafting individual start/stop scripts
had to go.

--
Dan Espen

[Shadow]

On Sun, 11 Dec 2016 16:53:20 +0000 (UTC), Rich <ri...@example.invalid>
wrote:

No, it was an NSA accomplishment.

>https://muchweb.me/systemd-nsa-attempt

HTH
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012

[Mike Spencer]

Dan Espen <des...@verizon.net> writes:

> The average home user doesn't really care that much. But data centers
> care a lot.

Fine. RedHat or somebody, do a DataCenterLinux distro. Hack all the
heavy-lifting software to play nice in that environment. But don't
try to make those hacks the default or mandatory for normal people,
normal systems.

Don't make my desktop/laptop systems any more impenetrable than they
already are. I *like* having small pieces that, once they come to my
attention, I can take apart and understand.

Am I an "average home [Linux] user"? Never been an IT pro, done some
coding in C, lisp, csh, perl for my own ends. Can occasionally find
and correct a bug in OSS C code written by True Hackers. But I'm an
artist blacksmith, sculptor, weldor, millwright and Linux as it is,
without a global supervisor, appeals to me. Oh, and I'm an Old Guy,
too, happy to learn *new* stuff, unwilling to labor to learn the
*same* stuff over again with a shiny new management interface.

http://xkcd.com/1770/

> Linux needed systemd or some other monitor/restart
> system to hold it's own.

Against what?

> Crafting individual start/stop scripts had to go.

Feh.

--
Mike Spencer Nova Scotia, Canada

[Marko Rauhamaa]

Mike Spencer <m...@bogus.nodomain.nowhere>:

> Dan Espen <des...@verizon.net> writes:
>> The average home user doesn't really care that much. But data centers
>> care a lot.
>
> Fine. RedHat or somebody, do a DataCenterLinux distro. Hack all the
> heavy-lifting software to play nice in that environment. But don't
> try to make those hacks the default or mandatory for normal people,
> normal systems.

That's what RedHat is doing. That's *all* RedHat is doing.

> Don't make my desktop/laptop systems any more impenetrable than they
> already are.

Impenetrability has been there since the beginning of RedHat. Scripts
calling scripts calling scripts, with comments telling you not to touch
those scripts. You have needed quite a bit of detective work to figure
out how the DNS, X11, PAM, Bluetooth etc have been integrated with the
operating system.

> I *like* having small pieces that, once they come to my attention, I
> can take apart and understand.

Still, somebody should have laid down the law about the fundamental
assumptions and contracts between the pieces, and written it down in
large, friendly letters.

> Linux as it is, without a global supervisor, appeals to me.

If you want to implement

* a daemon

* a file system

* a shell

* a terminal emulator

* etc

You need to read up on the protocol your thingy needs to comply with.

I think Linux was in dire need for such protocols for the system as a
whole.

In the early days of automobiles, all you needed was an interest in
mechanics and not minding getting yourself dirty. In the end it became
evident that some standards and traffic rules were necessary.

> Oh, and I'm an Old Guy, too, happy to learn *new* stuff, unwilling to
> labor to learn the *same* stuff over again with a shiny new management
> interface.

I think systemd's main problem is not what it tries to accomplish but
how it is shoved down our throats without properly convincing the
Unix-minded people. I'm not convinced that Poettering's technical
approach is optimal, but at the same time, much of the opposition comes
from sysadmins who don't see any reason for any kind of law.

An example:

/etc/init.d/xyz reload

has classically been implemented by sending a SIGHUP to the daemon
process (which is found with a PID file). Systemd documentation rightly
points out that this is an untenable mechanism since there is no way of
knowing when the reload operation has truly taken effect.

The seasoned sysadmin doesn't care because the effect will be virtually
instantaneous and the command has been executed manually. However, this
detail is a source of recurrent failures in automated tests on virtual
machines, which often need seconds to get access to the disk.

>> Linux needed systemd or some other monitor/restart
>> system to hold it's own.
>
> Against what?

OSX, I'm guessing.

>> Crafting individual start/stop scripts had to go.
>
> Feh.

The init.d scripts themselves had a decent enough interface. If you had
just stripped the awful

. functions

from them and imposed stricter guidelines, you wouldn't have needed
systemd.

Admittedly, it might not have been possible to impose anything on the
distros and the developer community. It was simpler to impose systemd.


Marko

[Rich]

Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
>
> Dan Espen <des...@verizon.net> writes:
>
>> The average home user doesn't really care that much. But data centers
>> care a lot.
>
> Fine. RedHat or somebody, do a DataCenterLinux distro. Hack all the
> heavy-lifting software to play nice in that environment. But don't
> try to make those hacks the default or mandatory for normal people,
> normal systems.
>
> Don't make my desktop/laptop systems any more impenetrable than they
> already are. I *like* having small pieces that, once they come to my
> attention, I can take apart and understand.

And I'd submit that a proper traditional Unix sys-admin person also
appreciates the "tool box" approach of small modular pieces that can be
fit together in ways not thought of by their creators as well.

I.e., the difference beteen a box of old generic Lego bricks vs. an
injection molded plastic model. The plastic model goes together only
one way. The lego's provide infinite possibilities.

The old way with Bash scripts being the "lego box", the new systemd way
being the "only this one way, nothing more".

Which also might explain why Redhat's been pushing systemd dev. so
much. The vast majority of RedHat installs in their profit center
(govt. and corporate data centers) are managed not by old-school Unix
sysadmins with the "toolbox" mindset. They are being managed by
"admins" who have a MSCE (i.e., managed by those who know only
windows). Providing a MSCE, assustomed to the windows tabbed dialog of
1,000 checkboxes method of configuring a system with a "lego block set"
system (Init & Bash) just blows their minds and they can't (or won't)
even try to make any changes. And when they do need to "add"
something, they don't know how.

Enter systemd. Now those same MSCE's who know only "check the boxes
until I get the config I want" can "enter key value pairs until I get
the config I want". Same mindset, just in a text editor instead of a
GUI dialog.

> ...

>
>> Linux needed systemd or some other monitor/restart
>> system to hold it's own.
>
> Against what?

Translation:

_Redhat_ needed systemd ... to hold it's own in selling its product to
its core customer group (that core being winblows MSCE devheads).

[Rich]

Marko Rauhamaa <ma...@pacujo.net> wrote:
> Mike Spencer <m...@bogus.nodomain.nowhere>:
>
>> Dan Espen <des...@verizon.net> writes:
>>> The average home user doesn't really care that much. But data
>>> centers care a lot.
>>
>> Fine. RedHat or somebody, do a DataCenterLinux distro. Hack all
>> the heavy-lifting software to play nice in that environment. But
>> don't try to make those hacks the default or mandatory for normal
>> people, normal systems.
>
> That's what RedHat is doing. That's *all* RedHat is doing.
>
>> Don't make my desktop/laptop systems any more impenetrable than they
>> already are.
>
> Impenetrability has been there since the beginning of RedHat. Scripts
> calling scripts calling scripts, with comments telling you not to
> touch those scripts. You have needed quite a bit of detective work
> to figure out how the DNS, X11, PAM, Bluetooth etc have been
> integrated with the operating system.

Not a flaw with "Linux" - a rather flaw with "Redhat's particular
variant".

[Marko Rauhamaa]

Rich <ri...@example.invalid>:

> And I'd submit that a proper traditional Unix sys-admin person also
> appreciates the "tool box" approach of small modular pieces that can
> be fit together in ways not thought of by their creators as well.

I'd submit that attitude is a problem. A computer system is like a home,
a dam or a helicopter. There are numerous things to consider and get
right. Improvising will lead to surprising problems.

A general-purpose computer should have vast degrees of freedom. However,
there should be a method to the madness, proper, safe idioms and
conventions.

> I.e., the difference beteen a box of old generic Lego bricks vs. an
> injection molded plastic model. The plastic model goes together only
> one way. The lego's provide infinite possibilities.

No problem with Lego bricks. They make it possible for the system
designer to build the system. However, the point is not for the customer
to take the system apart after delivery.

In my previous workplace, we shipped our solution as bag of Lego bricks.
The installation crew spent months at the customer facilities putting
the custom solution together. Once they finally got the solution to
work, they wouldn't know how to do it a second time. It was more like,
it's working now -- nobody touch anything!

Made bug fixes a nightmare, and upgrades all but impossible.

> Enter systemd. Now those same MSCE's who know only "check the boxes
> until I get the config I want" can "enter key value pairs until I get
> the config I want". Same mindset, just in a text editor instead of a
> GUI dialog.

I agree that naive approach is one of the weakest points of systemd.


Marko

[Marko Rauhamaa]

Rich <ri...@example.invalid>:

> Marko Rauhamaa <ma...@pacujo.net> wrote:
>> Impenetrability has been there since the beginning of RedHat. Scripts
>> calling scripts calling scripts, with comments telling you not to
>> touch those scripts. You have needed quite a bit of detective work to
>> figure out how the DNS, X11, PAM, Bluetooth etc have been integrated
>> with the operating system.
>
> Not a flaw with "Linux" -

Who mentioned Linux?

> a rather flaw with "Redhat's particular variant".

With *all* of them "particular variants."


Marko

[Rich]

Yep. I once peered into the RedHat startup system on a friends
computer that ran RedHat. They wanted something tweaked (I forget
what) and I was the "guy to ask".

It looked to be an overt attempt to purposefully complicate the system
well beyond the ability of anyone to comprehend and understand.

[Dan Espen]

Mike Spencer <m...@bogus.nodomain.nowhere> writes:

> Dan Espen <des...@verizon.net> writes:
>
>> The average home user doesn't really care that much. But data centers
>> care a lot.
>
> Fine. RedHat or somebody, do a DataCenterLinux distro. Hack all the
> heavy-lifting software to play nice in that environment. But don't
> try to make those hacks the default or mandatory for normal people,
> normal systems.
>
> Don't make my desktop/laptop systems any more impenetrable than they
> already are. I *like* having small pieces that, once they come to my
> attention, I can take apart and understand.
>
> Am I an "average home [Linux] user"? Never been an IT pro, done some
> coding in C, lisp, csh, perl for my own ends. Can occasionally find
> and correct a bug in OSS C code written by True Hackers. But I'm an
> artist blacksmith, sculptor, weldor, millwright and Linux as it is,
> without a global supervisor, appeals to me. Oh, and I'm an Old Guy,
> too, happy to learn *new* stuff, unwilling to labor to learn the
> *same* stuff over again with a shiny new management interface.
>
> http://xkcd.com/1770/

Sorry, I don't find systemd impenetrable. Reading the systemd
config files, it's clear enough what systemd does with them.

I was an IT pro before I retired. Over 50 years of system
design and implementation. Not sure what that has to do with
my opinions about systemd.

>> Linux needed systemd or some other monitor/restart
>> system to hold it's own.
>
> Against what?

The premier competitor to Linux is Solaris.
As I mentioned, Solaris built it's own systemd long before
systemd surfaced.

--
Dan Espen

[Dan Espen]

I failed to mention . functions because I didn't think the audience
would follow. With initd, the actual function of a single daemons
function was spread over the start/stop/restart/reload script itself
and . functions, and the aforementioned forest of soft links and
the sequence numbers that had absolutely nothing to do with the
individual service. Dependency wasn't declared anywhere and only
implied by the forest and numbers.

--
Dan Espen

[Mike Spencer]

Rich <ri...@example.invalid> writes:

> And I'd submit that a proper traditional Unix sys-admin person also
> appreciates the "tool box" approach of small modular pieces that can be
> fit together in ways not thought of by their creators as well.
>
> I.e., the difference beteen a box of old generic Lego bricks vs. an
> injection molded plastic model. The plastic model goes together only
> one way. The lego's provide infinite possibilities.

Just so.

> The old way with Bash scripts being the "lego box", the new systemd way
> being the "only this one way, nothing more".
>
> Which also might explain why Redhat's been pushing systemd dev. so
> much. The vast majority of RedHat installs in their profit center
> (govt. and corporate data centers) are managed not by old-school Unix
> sysadmins with the "toolbox" mindset. They are being managed by
> "admins" who have a MSCE (i.e., managed by those who know only
> windows). Providing a MSCE, assustomed to the windows tabbed dialog of
> 1,000 checkboxes method of configuring a system with a "lego block set"
> system (Init & Bash) just blows their minds and they can't (or won't)
> even try to make any changes. And when they do need to "add"
> something, they don't know how.

This has been my belief, too. I hesitated to say as much because I
haven't seen the phenomenon first-hand. My only high-level IT
experience has been hanging out (not employed) for a few weeks a year
in an all-Unix dev environment. At that time, they were running on
the tail ends of large contributions from DEC and IBM. Since I
stopped doing that, M$ has made a similarly huge contribution and much
has changed there.

The phenomenon to which you point vaguely resembles "physics envy" in
the social sciences. Only in the sys admin case, it's not Windows
envy, it's the specious notion of Windows MCSE as a defining
credential for how a computer is supposed to be managed. Clunk.

> Enter systemd. Now those same MSCE's who know only "check the boxes
> until I get the config I want" can "enter key value pairs until I get
> the config I want". Same mindset, just in a text editor instead of a
> GUI dialog.

Scripting is (like) language. Clicking boxes is (like) shopping.
Attention, shoppers: We're hiring sys admins. :-\

>>> Linux needed systemd or some other monitor/restart
>>> system to hold it's own.
>>
>> Against what?
>
> Translation:
>
> _Redhat_ needed systemd ... to hold it's own in selling its product to
> its core customer group (that core being winblows MSCE devheads).

That certainly fits with my impression from fragmentary information.