Message-ID: <2838655.H5W5zNkR37@merkaba>
Date:	Wed, 13 Aug 2014 11:37:28 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Måns Rullgård <mans@...sr.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Christopher Barry <christopher.r.barry@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: OT: Open letter to the Linux World

Am Mittwoch, 13. August 2014, 10:27:56 schrieb Peter Zijlstra:
> On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote:
> > Steven Rostedt <rostedt@...dmis.org> writes:
> > > Nice rant, I sympathize with you (just complaining about this on G+).
> > 
> > Made my day.
> > 
> > > I'm just waiting for Linus to get pissed enough to write his own init
> > > routine. Maybe he'll call it "Boot Init Through Computer Hardware".
> > 
> > The trouble is that most of the heavy-weight kernel developers don't
> > seem to care at all about what goes on in userspace.
> 
> Well, I know for a fact that quite a number do; but so far most people
> who care have been able to steer clear of this trainwreck so we did.
> 
> I'm about to switch all my machines to Gentoo (from Debian) because that
> will indeed allow you to build a distro without much of this nonsense
> in -- because as has been eloquently said; you simply don't need this
> fucking shite to run a 'normal' machine.
> 
> And the thing is; we're all very busy so we tend to take the 'easy' way
> out for things like this; but wholesale switching all my machines is
> indeed painful, and I'm not liking.

Just for record:

Debian continues and will (for now and supposedly Jessie lifetime) continue to 
work without systemd as PID 1 using systemd-shim and cgmanager.

And no: Debian didn´t make the choice easily or without discussion. I believe 
this to be the most controversial decision inside the Debian project and of 
the Tech CTTE in a decade or so, *after* tons over tons of discussion before. 
But one part of the decision is that Debian will continue to support other 
init systems at the moment.

Its still being discussed in about all major Debian mailing lists up to now 
popping up every now and then.

I am not completely opposed to quite some ideas within systemd, but what 
really upsets me most in this is the "I know it better than you, go away!" 
kind of attitude I also experienced with PulseAudio developers who just give a 
damn about my use case of wanting to start music playback on one X11 session 
and then switch to another session and *continue* to listen to that music. 
Just as one example where I ran into problems with PulseAudio I can just get 
rid of with an easy apt-get purge of it.

And yes, this is where I think wisdom is missing and the ability to accept 
constructive criticism is missing. Not all use cases are the same, its that 
simple.

Its the attitude of knowing best for others without willing to accept feedback 
and discuss things that I am fed up with totally. If it doesn´t fit into my own 
agenda, I don´t care, go away. This kind of attitude is not likely to help in 
the long time. And I think its exactly this attitude that contributes *a lot* 
to the polarity around systemd. If people would get the impression that 
systemd upstream acts *sane* and in a *cooperative* way instead of *forcing* 
things I think there would be lot less resentment about it.

One can have different oppinions about the tone on this mailing list at times, 
but so far I never found anyone so stubborn not even to let a feedback sink in 
before responding on a regular basis. But I think for systemd developers some 
kind of feedback ridicules their world view by an amount that they just 
iptable -j DROP it before even receiving it. They may still answer it, but 
also that sometimes to my perception without even having received the feedback 
first.

That said, systemd in Debian works for me mostly, except some issues with 
mounting NFS at the workstation at work. But I will keep sysvinit-core 
installed for the time being.

That all said: I believe that any feedback like this is best served on 
systemd-devel mailing list – maybe in an attempt to express it in a somewhat 
polite, yet also direct way. Instead of on LKML, debian-user, debian-devel and 
you name it what other mailinglists. Cause that would increase the chance of 
upstream noticing it.

BTW I am still using KDE / Plasma and last I looked on GNOME (in Debian 
Wheezy) I just thought "Oh my god" and knowing that GNOME also insists on 
PulseAudio, I will continue with a desktop environment that leaves me choice. 
KDE developers invented Phonon for a reason. One reason is to be independent 
of any insanity going on in the lower layers of multimedia handling. Same 
thing with Solid. I think meanwhile they rely on systemd-logind, cause 
ConsoleKit is unmaintained, but at least they do not depend directly on it. I 
really hope this will stay this way and they continue to abstract all systemd 
use away so that in case systemd will not work out in the long term, they can 
adapt easily.

For any account: Depending on a particular init system in a desktop 
environment is a *bug*. And no way of intelligent arguing around this is 
likely going to convince me of the opposite.


Also I think:

martin@...kaba:~> ls -l /sbin/init
-rwxr-xr-x 1 root root 40648 Aug  3 21:01 /sbin/init
martin@...kaba:~> ls -l /bin/systemd
lrwxrwxrwx 1 root root 20 Aug  6 13:41 /bin/systemd -> /lib/systemd/systemd
martin@...kaba:~> ls -l /lib/systemd/systemd
-rwxr-xr-x 1 root root 1084816 Aug  6 13:42 /lib/systemd/systemd

martin@...kaba:~> apt list 2>&1 | egrep "(^systemd/|sysvinit-core)"
systemd/unstable,now 208-7 amd64 [installed]
sysvinit-core/unstable,now 2.88dsf-53.3 amd64 [installed,automatic]

is highly worrying. A one MiB binary as PID 1? Really?

I think I would also have separated cgroup managing from PID 1 also for the 
price of limited functionality should it not be available. I know there are 
arguments of systemd developers against it, but one MiB binary for PID 1 just 
asks for trouble and bugs.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists