Steve Litt <slitt@???> wrote:

>>> 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’ll admit that I’ve not really followed the subject all that much, but it’s my understanding that you can’t just replace a couple of services.

It’s not that you can’t replace a SystemD service with something else, but the way SystemD has been extending it’s tentacles into all sorts of stuff that wasn't broken (and replacing it with broken alternatives - c.f. ntp). I may be completely wrong, but it was my impression that they’ve been so trigger happy replacing established APIs with “better because it’s new” APIs that a lot of packages won’t work OFF THE SHELF without SystemD running and servicing those new APIs.

So I think it comes down to whether the devs for the package you want to run took the time to encode multiple “if systemd then do X else do Y” (or ifdef buildforsystemd then do X else do Y) stuff in their code. At some point, if you are writing with an eye on distros that all run SystemD then someone could be tempted to just write “do X” - and then that package won’t work if the API for X isn’t present.

And of course, at some point (if there isn’t already) then it’s likely that SystemD will introduce something whose semantics are different - so it’s not just a case of “call API X or call API Y”, but case of do a bunch of stuff one way or do it a different way.

So the statement you’ve quoted may technically be correct, but may also be “somewhat misleading”.



Lars Noodén via Dng <dng@???> wrote:

> That's not too far off from new cars as they are today. They are lousy
> with sensors and everything is tied directly or indirectly to the
> dealer, either through proprietary programs + proprietary protocols or
> service contracts or both. You can't change your own oil though I think
> changing the wiper blades on your own is still allowed. And by "you" I
> mean the ostensible owner or an independent repair shop.
>
> The cars are not recognized as computer systems, but as Cory Doctorow
> pointed out they are a computer you put your body into. I have only a
> weak grasp of the situation, having kept my head in the sand as long as
> I could, but I think two non-excusive approaches to solving the car
> software / protocol problem might be through software liability (as
> outlined by Geer and Kamp [1]) and through the ongoing attempts to
> restore the "right to repair" as led by Rossmann [2], in particular the
> latter which is picking momentum in regards to heavy farm equipment.

I can’t speak for commercial vehicles or agricultural machinery, but for cars things took a positive turn in the EU many years ago.
At one point, car manufacturers were heading down the road towards “only a franchised dealer can do X, Y, Z” and independents would be locked out - due to lack of third party diagnostics etc as we’re seeing with (for example) John Deere. The first I recall was BMW where only franchised dealers were allowed access to the unit needed to reset the maintenance light - but as I recall, it wasn’t long before the protocol was reverse engineered and third parties started selling the ability to non-franchised dealers.
The car manufacturers rolled out all the familiar reasons why only franchised dealers should be allowed to do anything - the “think about idiots fitting substandard parts” one being the biggest.
But the rules were changed, the car market was stripped of it’s exemption from certain competition laws, and suddenly it was illegal to have franchised dealers with defined geographic areas, it was illegal to tie franchised dealers to only dealing with the one manufacturer, and the biggest benefit of all was that it was illegal to withhold maintenance and diagnostics information from non-franchised dealers.
I can’t remember whether it was part of this or a separate rule change, but at some point it was made a legal requirement to implement a standardised diagnostics port - and the EOBD port was born.

So I guess we have it easy over here, and I hope things change in that way for you over the other side of the pond.

Simon