On 22/07/2015 22:20, T.J. Duchene wrote:
> That said, the reality of the situation is quite different than it is
> in theory. As the old saying goes in the American Midwest: "The
> proof is in the pudding." Until someone provides a systemd
> alternative that works better than systemd, yet provides conveniences
> and the same API, no one who has latched on to systemd is going to
> change their mind.

Right. And that's why it's difficult: systemd has manpower, so it can
provide a lot of features - features that we have to replicate if we are
to offer a viable alternative, and we don't have as much manpower.

For udev, login, and such, I don't think it's a problem, though. udev,
login et al. were working before systemd came along, so it's just a
question of cutting the BS and performing the right communication.
(Which is another issue per se, because the systemd people also have
manpower for communication - but it's not a technical issue.)


> In my humble opinion, the best way to kill systemd is to dilute it by
> cloning the API.

I respectfully disagree. I'm of the opinion that cloning the API
acknowledges its value; to me, the best way to kill systemd is to
provide a serious alternative to everything that it does, but to
do it *right*, offering the advantages of systemd without the drawbacks;
and the API should be designed with that goal, to do things right -
which mostly precludes using systemd APIs.

The problem with the systemd APIs is that they kinda enforce the
underlying architecture, and using them amounts to basically rewrite
systemd. The APIs themselves are not bad from a programmer's point of
view, but the architecture is, from an architect's point of view, and
that is what must be deconstructed.

OT: I would like it if the list host could set the "Mailing-List:"
header on list messages. Most MUAs understand it and implement a
"reply to list" feature; without it, we're stuck with manual configuration
or hitting "reply to all", which causes duplicates.

--
Laurent