Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 11/15/2014 06:49 AM, Andrei POPESCU wrote:
On Vi, 14 nov 14, 08:04:00, Marty wrote:
On 11/14/2014 05:26 AM, Andrei POPESCU wrote:
>On Vi, 14 nov 14, 08:59:11, Joel Rees wrote:
Jumping in here as myself, not Joel's tag-team member. :)
>"Debian" as an entity doesn't really do much. There are only one or
>several volunteers who start doing things. Setting up a separate "port"
>for systemd would have been a major waste of resources (both human and
>hardware) with no real gain.
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.
I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.
>You are completely dismissing the work of Debian Developers who *did*
>have a very good look at the options and decided switching to systemd is
>doable and would be a good thing from a *technical* point of view.
Non-responsive to his argument. If the work was biased and over-optimistic
then it doesn't matter how much they looked at it.
This argument cuts both ways :)
>However, you and several others are rejecting systemd on ideological
>grounds. There's not much that can be done about that, short or
>re-implementing systemd according to your vision.
Many others reject choice and the anti-choice stance is the ideological
position at issue here. It is in direct conflict with Debian policy.
The systemd upstream are the ones with "vision," ideology, rejecting
opponents as "haters" in an overt campaign to establish a Linux monopoly.
They have a financial interest in *psychological projection* of this kind. I
still cannot see what Debian stands to gain by jumping on their marketing
At least some of people rejecting systemd demand that it be removed
completely, including libsystemd. How is it pro-choice to forbid me from
being able to use a software at its full potential?
For me it's more about being unable to remove it completely, because of
vendor lock-in. There's no technical reason that I know of that anything
in userspace cannot modular, and replaceable, so when something cannot
be replaced then an alternative must be provided, or else my default
assumption is that vendor lock-in is in effect.
>I hope you do understand why neither the systemd developers, maintainers
>or users have any interest whatsoever in doing that.
But upstreams have other interests, like establishment of a Linux monopoly
via tying and customer lock-in. Why should there not be a rational effort to
In my opinion the best "defence" against a monopoly of any kind is to
develop competitive alternatives.
That's true on a level playing field, but here is just one player with
control of the user-space software stack, fully leveraging it by
dependency tying. It's like a manufacturing business that creates a
monopoly by vertically integrating, in a way that no competitor can.
 which I don't believe applies, but will ignore for the moment.
They seem determined to make it apply in the future, so that's what
drives the original concern (for me). It may apply in a way you are not
After all, systemd
>already works fine for them.
Windows already works fine for most people, and it is consistent with the
anti-choice philosophy, so why bother with Linux at all?
Doesn't work fine for me. At $dayjob I'm forced to use it and I can tell
you my private laptop with a Dual Core 1,8 GHz and 2 GB RAM runs circles
around a Core i5 with Windows 7. But this is off-topic for d-u.
It might be somewhat on-topic after all, because I was thinking more
about Windows 10, which is Red Hat's likely target and competitor.
Debian and the other free software distros are just Wall Street cannon