Simon said on Thu, 25 Nov 2021 18:11:09 +0000

>Peter Duffy <peter@???> wrote:
>
>> So customers pay to be insulated from complexity. Just so obviously a
>> blatant restating of the M$ attitude - which is the reason why there
>> are so many clueless computer users the world over, and by
>> extension, so much cybercrime.
>
>That’s a “complicated” discussion.
>Take the car analogy that’s previously been raised - and they are
>usually not good analogies anyway, be hey-ho.
>
>In the early days of motoring, you had a lot to learn and cars were
>non-trivial to drive and to keep going - to the extent that many users
>employed someone to do the driving for them. Roll forward through the
>years, and cars have got more and more complicated, but also easier
>and easier to operate and more and more reliable.

I think once you got rid of the crank and manual choke, and brought in
the automatic transmission, any fool could already drive a car. That
was in the late 1950's. My first car, a 1959 Plymouth with manual
transmission and 2 foot fins, was trivial to drive if you could drive a
stick, and the flat head 6 was trivial to work on. Tune up took about
20 minutes with an adjustable wrench and a gapping tool, and replacing
the thermostat was about 20 minutes. This meant that even if you had
the shop do these things, the cost was much less than today. My theory
is a lot of the complexification of cars (and they've never had their
engine compartment welded shut) was marketing krap to get people to buy
what they didn't need.

A lot of the other complexification was to increase mileage and
decrease smog. Well, that's a very good justification for complexity,
unlike the complexity of systemd.

> At one time I used
>to carry a basic tool kit all the time, now I don’t as a) the car is
>quite unlikely to break down and b) there’s probably nothing I can do
>anyway. But now, anyone with basic skills can make a car get them from
>A to B, in relative comfort, and typically without drama.

Relative comfort without drama was true in the late 1950's too.

>
>By analogy, back in the days when “computers” really only meant the
>likes of big IBM iron, few could “drive” it - to the point that most
>business people employed people to do the driving and they simply said
>where they want to go (e.g. get some numbers out on a printed report).
>Now, for many, they do their own driving using BI tools, dashboards,
>and the like.
>
>But in both cases, when the modern, complicated but very easy to use,
>but highly reliable system develops a fault - then it needs an
>increasingly high-tech person and tools to fix it.

Systemd hasn't made Linux easier to use (or harder when it functions
correctly). The debate is whether it's made Linux easier to admin. I'd
say NO, but even for those who say "yes", there were better, more
modular, less crazy ways to implement every one of those supposed
benefits. Ways that didn't involve PID1. Ways that didn't complexify
Linux to the point where the admins needed to hire Redhat.

>But it’s not the fault of the tool that users are clueless - that’s
>the fault of the industries and society for pushing the agenda of
>users not needing to know anything about what they are doing. And of
>course, they could now sell the more expensive Windows instead of DOS,
>or the more expensive Mac instead of Apple 2.

Jobs and Gates. People were using MS-DOS and CLI Lotus and Wordperfect
quite well, when Jobs and Gates persuaded people they were too stupid
to interoperate with the machine, and needed all sorts of crutches.
Jobs and Gates imprinted a mental block on the population. Now the
employers of Poetterpunk are moving the mental block up to admins.

> The
>classic example is the volume of, sometimes entertaining, material to
>be found on ‘internet where people have managed to completely f-up
>something in Excel because “it’s only a case of some random clicking,
>who cares about skills or training”. The vendors of anything are only
>too keen to persuade users that their product is easy to use (perhaps
>mentioning Boing and the 737-Max is in poor taste),

ROFLMAO!

> but the reality is
>that most people value “ease of use” and far too many don’t value
>actually having a f’in clue what they’re doing.
>
>> But if systemd makes it more difficult to solve problems, and makes
>> the system more unreliable, then the customers aren't even getting
>> what they paid for before systemd was introduced. The problem is
>> obviously proving whether or not systemd really does make a system
>> more unreliable/undiagnosable.
>
>Well provided nothing goes wrong, clearly SystemD is easier to use for
>an admin without a clue.

I don't think so. In my opinion, a person trained in neither would have
an easier time with runit than with systemd.

> Clearly writing a unit file to start
>something is so much easier than having to learn how to write in Bash.

Not so sure. Remember, a runit or s6 run script is usually less than 5
lines long, including the shebang. We're not talking sysvinit or OpenRC
here.

>I think that much is hard to disagree with. And if the tools make
>looking at a journal file easier, (I’ve no idea),

What could possibly be easier than vim /var/log/messages, or
vi /var/log/messages, or emacs /var/log/messages, or
nano /var/log/messages? And notice with the old way, you have a choice,
rather than having to look at log output with the vendor's proprietary
tool.

> then that bit is
>also true.
>
>So in some ways it’s a step along the road of making things easier for
>the general user, or in this case, the power user or novice admin. So
>yes, the user does get what they are asking for - but the downside is
>that when it breaks, it’s harder to fix.

Once again, there were many ways to make those things easier for those
people without making PID1 a gigantic nest of kudzu growing its roots
into everything.

[snip]

>> I've wondered for a long time if it would be independently possible
>> to make systemd optional.
>
>I think you found that the answer is no.

I think you might be pleasantly surprised. In, to use the term loosely,
"discussions" with systemd's biggest fanboy whose initials weren't LP,
I found out, according to him, that the only two systemd services that
can't be removed are PID1 and journald. If the fanboy is correct, then
you can install the runit process supervisor (not the whole init
system), and one by one, disable systemd's handling of the other
services, so all systemd does is launch runit and act as a logging
mechanism. I haven't done this because I don't have that itch --- I
don't have systemd.

>IIF, and that’s a massive IF, SystemD had only been “another init
>system” then yes. But there are so many dependencies where devs of all
>sorts of software have to make an either/or choice of whether to
>support SystemD (which you can’t do if you want your package to run on
>the majority of platforms) or support the “traditional” way, that it
>would mean every package developer putting a lot of work in to deal
>with the alternatives.

You've just put your finger on *everyone's* objection to systemd. If
the init system is kept to the black box it should be, nobody would
have raised an eyebrow. But the init system governing the network, and
home directories, and replacing xinetd --- really? Like I said in 2014,
they won't quit until the cat command requires systemd.

> E.g. simple logging of diagnostics etc would
>mean having two lots of logging code to handle syslog or SystemD
>logging. On this, I am in agreement with Steve Litt - the SystemD
>project has an incentive to maximise their intrusion into every aspect
>of system operation. Because the harder they can make it for devs to
>make they software run on SystemD or any other init system, the more
>they can make other software depend on SystemD and thus make it harder
>to keep SystemD optional in the wider view.

Hey, did somebody just mention Gnome and Flatpack?

>So having had SystemD create such a gulf between the requirements to
>run on “traditional” systems dn SystemD systems, effectively any shim
>would have to recreate a heck of a lot of SystemD. <sarcasm>And we all
>know that such a shim would be trivial to write given the well
>documented and stable interfaces between the SystemD components
></sarcasm>

And don't forget, they pay over a million dollars a year to programmers
ready, willing and able to crash in the presence of a shim. Judging
from the number of systemd WONTFIXs, those programmers aren't too busy
fixing bugs.



SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques