On Thu, 2021-11-25 at 18:11 +0000, Simon wrote:
> 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. 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.

Very true. I used to have a Morris Minor, and did virtually all the
maintenance myself (well, anything which didn't involve getting the
engine out of the car). But in the case of my current car, I'd be scared
to touch anything but the most trivial problems, in case I broke
something and turned a problem into a disaster: it's all just so much
more complex and interconnected.

Maybe the problem with the car analogy is that it's only really
applicable to end-user computers - desktops and laptops. For servers,
the analogy would need to be extended to buses and HGVs. In those cases,
where many people rely on the availability and punctuality of the
vehicles, the drivers and pilots don't fix the problems themselves, and
also don't go back to the manufacturers to get problems fixed: the
companies which run the vehicles have teams of engineers who can strip
the thing down to components and reassemble it.

>
> 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.

I think that in the "big iron" days, it was even more extreme: companies
just went to IBM etc. and said they wanted a computer. IBM sent in their
team, did systems analysis on the company's existing paper system, then
spec'd a computer to do the job. All the company did was agree to IBM's
price, take delivery of the beast, and then pay IBM even more dosh to
teach them how to use it. When people found that they could now buy
something off the shelf, and it would (more or less) do what they
needed, it was a revelation. To say nothing of a big problem for IBM.

<snip>

>
> > 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. Clearly writing a unit file to start
> something is so much easier than having to learn how to write in Bash.
> I think that much is hard to disagree with.
> And if the tools make looking at a journal file easier, (I’ve no
> idea), 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.

Is it easier to use systemd? If someone's clueless, then they're
probably not going to be doing much system administration anyway, and if
something breaks, they're probably going to be picking up the phone and
whining to their mate who happens to be a sysadmin.

In most cases, anyone using linux who has any interest at all in the
system is actively encouraged to at least dip their toe into bash
shellscripting - simply because it's there, useful, and potentially
interesting. It's always seemed to me that a basic level of shellscript
skill is all that's required to craft init scripts: there are always
plenty of examples lying around; there are probably web sites devoted to
writing them.

The great thing about a shell-based init script is the infinite
flexibility; also the knowledge that if I've written it myself, I know
what it's doing and if it goes wrong, I'll hopefully have some clue as
to what has gone wrong. Writing a systemd unit file - I admit I've never
tried it (yet) - looks to be a daunting prospect. And even given the
vast number of options, it's a straitjacket compared with bash
facilities.

<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.
> 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. E.g. simple logging of diagnostics etc would
> mean having two lots of logging code to handle syslog or SystemD
> logging.

Agreed. One of the things which gives me the red mist about this is that
there'll come a point - if it hasn't come already - where anyone
developing or modifying a linux application will need to go cap-in-hand
to the systemd equivalent of Barad-dûr and check that what they're doing
will be compatible with the latest incarnation of systemd.

And maybe that's being too paranoid. I once tried the experiment of
setting up a sacrificial virtualbox VM, installing centos 7, and then
forcing the removal of systemd, just to see what would happen. It was
interesting. Over 500 dependent packages got removed; I then rebooted,
and was dropped into a single-user shell (probably reasonable, as I'd
removed the init system). To add insult to injury, both background and
foreground were set to black, so that I couldn't even see what I was
typing. I remember that the phrase "nuked back to the stone age" kept
going through my mind.

I noted the names of a few of the more surprising packages which had
been removed as dependents, then reverted back to the
pre-systemd-removal virtualbox snapshot (oh yes, I had taken one!). I
then poked about inside the noted packages. One of the ones removed was
ebtables - I found that the only thing which made it dependent on
systemd was the existence of a systemd config file (kind of
chicken-and-egg). The old init script was still there. I removed the
systemd config file, fiddled about with the rpm configuration files and
rebuilt the package: systemd dependency gone. I did think of continuing
the experiment and writing something to work through all the
auto-removed packages to find all the ones which fell into the same
category and process them in the same way, but I got pulled off onto
other things. I might take it up again at some point: the existence of a
devuan analogue to an RPM-based distro like centos or scientific linux
might put the cat among the pigeons.

> 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.
>
> 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>

I'm not convinced that writing an "init subsystem plugboard" would be
impossible - although certainly non-trivial. But after all, it's just
software. Anything's possible. During the days when the hurd was being
actively developed, it must have seemed as though there would never be
an open-source equivalent of unix. Then Linus Torvalds appeared on the
horizon. Andrew Tridgell reverse-engineered a rather obscure network
protocol and wrote a server for it - and then discovered that he'd
implemented a linux-based version of SMB and opened up the door for
linux access to windows file shares.

We who know and appreciate the benefits of devuan can push it towards
others - but convincing them and getting them to try it is another
matter. But if there existed a package which interposed itself between
systemd and the rest of the system, so that systemd could be trivially
replaced with another init subsystem, it would open up vast scope for
demonstrating that it was actually possible for linux to work without
systemd. The stakes couldn't be higher, and there are obviously many
other people who are thinking on these lines. Cometh the hour, cometh
the programmer. Maybe?

>
> >> Peter Duffy said on Thu, 25 Nov 2021 13:51:18 +0000
> >>
> >>> I've said it before and I'll say it again. All this could have
> been
> >>> avoided - if systemd had been made optional from day 1. People who
> >>> liked it could use it; people who didn't like it could use
> something
> >>> else.
>
> And in the Debian world, I distinctly recall there being an air of
> “don’t worry, it’s optional anyway” alongside the “and it’s only
> another init system” arguments.
> It was only once it was too late and the GR had been fudged to get a
> pro-SystemD vote that people realised that it was never going to be
> optional.
>

I remember the reply from one of the systemd mob to someone expressing
hatred for systemd: "If you don't like it, use something else". That's
another thing which brings on the red mist.