Noel Torres wrote:
> On Sunday, 30 de November de 2014 18:12:02 Keith escribió:
>> Supporting (systemd) in any form while forking seems like a lost cause.
>> Why support it at all ? Its too much work. The fork itself will put an
>> end
>> to (systemd) in very short order.
> We should not support it *now*. And probably you are right about systemd's
> future. But that is not the point. Freedom is.
>> Systemd is the wrong way down a one way street of sorts. Freedom is
>> straight
>> ahead and Sytemd made a left at the light.
> That seems like a hate speech. Wrong way.

Just for the record: Reads more like technical judgement to me, and,
putting on a technology assessment / design review hat (which I do a lot
in my day job), I'd agree with such a technical/architectural judgement.

Not necessarily that there's anything wrong with the pure init
functionality of systemd - it seems to solve some real problems for some
people (not me - I like more control over my servers than afforded by
the systemd approach - but that's situation specific and personal
preference) - but the implementation, its gross feature-creep, and the
explicitly stated design philosophy and goals of its primary developers
-- those are definitely (IMHO) a turn in the wrong direction, perhaps
180 degrees from the overall "Unix Way" that has served us all very well.

To the larger question of freedom: Every choice restricts freedom in
some way. A choice to support everything is a choice to do nothing.
Right now, without a lot of work, it sure seems like a choice to support
(or allow) systemd implies either:
a) accepting all the negatives that come with systemd, and friends, that
are driving the need to fork in the first place, or,
b) LOTS of work to "fix" things that come with systemd - working
directly against upstream

Raises the question of: what do we mean by "freedom?" What price are we
willing to pay for the "freedom" to run systemd?

Personally, I'd like to see a server-oriented distro that runs a full
complement of core and application software, without any dependencies
that bring in the systemd family of code (unless and until upstream
systemd developers change direction). If folks want to then install
stuff from upstream that requires stuff from the systemd family (what to
call that?), and install dependencies from upstream, we shouldn't stand
in their way - but let's not go out of our way to make it easy. (Break
out udev and journald and so forth back into independent modules, take
away any need for systemd to be running at PID1 to use other functions,
unwind all the crazy dependencies - maybe then; but until then...).
> Wrong way to go. Kicking users out of Devuan because they want systemd is not
> what I understand as supporting users' freedom. Having systemd support is not
> a good step in starting the fork, but rejecting it forever just now is a
> concept error.
>
> We should not waste efforts in supporting or modifying systemd now, but we must
> do it in the future, if feasible.

Or push back on upstream.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra