Re: Dropping SysV init script support? (was: systemd prerelease 254-rc3)

[Tomasz Pala <gotar@xxxxxxxxxx>]

On Mon, Aug 07, 2023 at 16:44:43 +0200, Lennart Poettering wrote:

>> 0. systemd implements SysV-compat disable knob,
> 
> We do since about forever.

Hmmm... I'm using systemd since v37 (reading all the release notes) and
it's a bit of new to me... I've just run through some docs and can't
find anything neither. It might be some documentation issue then.

I hope you're not referring to -Dsysvinit-path -Dsysvrcnd-path?
As I meant the runtime-knob.

>> 1. distributions use SysV-disabled by default, allowing users to switch
>>    it on when needed, therefore it's impact is reduced, but notes
>>    taken,
> 
> This is outside of our control.

Did you gave us the tooling required for disabling this? The runtime-togglable one?

You can't expect any user-oriented distro would disable this without an
_easy_ way to reenable by user themself.

>> 2. systemd enables some irritating behavior for SysV-enabled systems,
>>    like 30 second sleep with console beeping or rotating the screen
>>    upside down,
> 
> We do log about this loudly, even with emojis since a while.
> 
> I am pretty sure this should suffice.

Do you expect users to read the logs? ;D

Logs are passive, you need an _active_ distractor.

> We didn't "just remove" it btw. We just announced that we'll remove it.

Fully aware of it. And looking forward to it, as I expect more vendors to
provide native units.
I've written enough SysV-style inits in my life to really, really want
them gone. Therefore I fully support your decision to finally disable the
compat glue. The sooner, the better.
I would have disabled them myself a long time ago, but I'm not aware of
any switch (just masking the units or removing the files or generator).

> It seems to me you are complaining that we are announcing the removal
> ahead of time telling us to announce this ahead of time. Which doesn't

I'm not complaining, just anticipating the shitstorm that's coming.
And I'd like to be minimal, as this technically and objectively correct
decision doesn't deserve the subjectively reasoned complains that will
follow.

Because I've read the announcement (not if that matters to me anyway,
getting rid of SysV for years, I'd like my systems to ignore them
entirely) and I know most users won't. Until the change is going to
strike them in their faces.

Just like the GNU/screen-killing on logout. This was the right thing to
do, but some people are emotionally attached to their workflows:
https://xkcd.com/1172/

> Consider this NEWS file entry your "stimulation" to transition the
> holdouts.

End-users with their 'curl http://example.net/ | bash -c' are out of
scope of this and the distribution capabilities to inform them.


All I'm saying is that you shouldn't disable it silently (release notes,
logs - they ARE silent). No matter when it's going to happen, it should
be end-user VISIBLE before that date and _some_ drop-in salvation should be
available for them, buying some time for updating inits.

Anyway, that's just my 2 cents hoping the road ahead to be less bumpy.

-- 
Tomasz Pala <gotar@xxxxxxxxxxxxx>