:: Re: [DNG] vdev - udev is a dead end
Top Page
Delete this message
Reply to this message
Author: Adam Borowski
Date:  
To: dng
Subject: Re: [DNG] vdev - udev is a dead end
On Sun, Aug 14, 2016 at 01:19:20PM -0400, Steve Litt wrote:
> On Sun, 14 Aug 2016 09:02:59 +0200
> Didier Kryn <kryn@???> wrote:
> > They only support theur own software; isn't that
> > legitimate?
>
> Half of "their own software" was bought, either by acquisition or by
> hiring project programmers. They then inserted Halloween Code in their
> newly acquired software so it wouldn't run with non-systemd and
> non-Freedesktop stuff. Insertion of Halloween code was characterized as
> "intentional sabotage" by Adam Borowski in this email:
> https://lists.dyne.org/lurker/message/20160813.211227.9340d5a5.en.html


That's not what I meant.

There are three possibilities for breaking users of a competing platform:

1) callous disregard for others
No malice, just being inconsiderate while making changes that benefit
users of your platform.

2) goodies that intentionally don't work elsewhere
Making a feature that could easily be made portable, or even
intentionally designing it with a detriment in functionality, usable
only by your users. This is often Microsoft's tactics, but even the good
guys sometimes do so: https://www.gnu.org/licenses/why-not-lgpl.en.html

3) outright sabotage
Planting a logic bomb without even a shred of benefit for the user.
That's code whose only purpose is to damage someone else. Kind of
Microsoft's anti-DR-DOS checks. Or, recent timebombing of xscreensaver
by jwz.

Systemd crew tends to do 1), sometimes 2) if an individual coder is
malicious -- but I don't think most of them do so intentionally.
I know of no case they are guilty of 3).

I've read your message in
https://lists.dyne.org/lurker/message/20160813.204905.04e0a813.en.html as
encouraging 3). Let's not go there. Let's not do 2) either -- I don't
expect you to actively pepper your code with sd_notify, but as long as
systemd doesn't break a standard Unix behaviour, your code should work.
As for 1), systemd's components are so volatile and short-lived that
pandering to this week's specification might indeed be too much effort.
Thus, not porting your code to some platform you don't care about or
not working around their bugs or braindeadness (like KillUserProcesses)
is excusable. But, intentionally breaking things is bad.

--
An imaginary friend squared is a real enemy.