[Bradford] Defcon 3: Debian thermo global nuclear init standoff [systemd vs Upstart]

[David Spencer]

Oh no Nick, this is the No.1 topic guaranteed to turn me into Angry Dave
from the parallel universe :-(
Read this page.  Someone you know contributed to it:
http://www.linuxquestions.org/questions/slackware-14/slackware-and-systemd-885228/

And there's this:
http://monolight.cc/2011/05/the-systemd-fallacy/

In Debianland this has been going on since at least February.  As a Slacker
I love reading the Debian mailing lists (popcorn in hand) when there's
blood on the floor.
Regarding the wit and charm aspect, read this:
http://sporkbox.us/blog/?r=page/108
("The Dangers of Software Evangelism - Case Study: systemd and Debian
GNU/Linux": "In this case, the evangelism is *encouraged* by the lead
developer. Is this the sort of behavior that we wish to see from developers
of free software?")
Here's the same guy on what happened in Arch
http://sporkbox.us/blog/?r=page/95
(Arch has always brought to mind the phrase: Lions led by donkeys.)

And check out the editing history of the Wikipedia articles on Lennart, Kay
and Harald.  They don't censor their own articles, noooo, that would be
un-Wikial.  Instead, every time someone adds a "controversy" section, the
next guy in the three way Dead Rat circle jerk censors it for his pal.

And now of course systemd is in ur udev watching u get assimilated.  Joy.
Here is what Linus himself thinks of that:
http://article.gmane.org/gmane.linux.kernel/1369384
"Kay, you are so full of sh*t that it's not funny. You're refusing to
acknowledge your bugs, you refuse to fix them even when a patch is sent to
you, and then you make excuses for the fact that we have to work around *
*your** bugs, and say that we should have done so from the very beginning."

And here are four more highly significant data points from just four weeks
ago:
"I would like to request CVE ids for 4 systemd issues"
http://seclists.org/oss-sec/2013/q4/4
And the person credited for finding them works for Red Hat QA in Germany,
which raises deep questions about Red Hat's internal processes...  the
underlying cause being that new code will have bugs that decades old
sysvinit does not have, and that the "one process to rule them all" will
inevitably have bugs to pwn them all and in the darkness bind them.
I despair when the trivial real problem (i.e. Red Hat's init scripts are
ludicrous shitspawn from hell, and always have been) somehow is turned into
pressure for everybody to fall into line. Besides the evangelism, here is
how it happens bit by bit: for example, Pat Volkerding just a week ago
mentioning a recent version of cups that was broken if systemd wasn't
present:
http://www.linuxquestions.org/questions/slackware-14/%5Bslackware-14-1rc1%5D-some-loose-ends-4175481200/#post5048743

And, Nick, when you say: "Reliable process start/stop is nice for systemd
(cgroups based)" I hope you know about the new close coupling between
cgroups and systemd, which fucks up LXC containers for everyone not running
systemd... and the cgroups maintainer, surprise!  works for Red Hat.

These are the same people who brought you Gnome 3, and the same people who
effectively told XFCE etc that GTK+3 is gnome-only (hence wireshark and so
many more migrating to QT), and the same people who thought embedding
Javascript in Polkit was a great idea, and who fucked up udisks, and who
want dbus in the kernel, and who inflicted on us the policykit/consolekit
stuff that's now *abandoned* in favour of systemd.  Some more links:
http://igurublog.wordpress.com/2012/03/11/udisks2-another-loss-for-linux/
http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/
http://www.linuxquestions.org/questions/slackware-14/slackware-is-systemd-inevitable-4175460337/page35.html#post4976314

These corporate wankers are stealing our revolution.  Red Hat holds
maintainership of stuff like udev and cgroups in trust for the whole
community, and with that great power should come great responsibility.
Meanwhile these developers all have what anyone on this mailing list would
consider to be dream jobs, yet they are using them as a platform for
corporate and personal advancement instead of listening to and giving back
to the community that gave them the one big chance.  It leaves open the
question of whether senior Red Hat management is encouraging them, in
pursuit of monopoly, or whether they are just fast asleep.  Meanwhile,
alas, Fedora belongs to the zombies now.  Abandon it.

People criticise Canonical for not contributing to upstream projects, but
hell fire, at least when Canonical go off on something vastly stupid (Mir)
everybody sane can just ignore it.

Thanks Nick for having the good sense and taste to be on the right side of
the argument.
Me go lie down now.
-D.




On 29 October 2013 14:18, Nick Rhodes <nick at ngrhodes.co.uk> wrote:

> There is a bug report:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
>
> There are debate wiki pages:
> https://wiki.debian.org/Debate/initsystem
>
> But no-one is selling pop corn yet !
>
> I can't even work out what Debian's requirements are for a replacement
> init system.
>
> Anyhow my view so far:
>
> I don't see the need for binary logs.
> Reliable process start/stop is nice for systemd (cgroups based).
> systemd is becoming like a blackhole kernel broker for all
> process/job/user/auth/connectivity management OF ALL THE USERSPACE THINGS !!
>
> Upstream projects are already providing systemd configs.
>
> Upstart is a surprisingly adequate product.
>
> Upstart leaves gaps in core system functionality, needing patched versions
> of logind, soon dbus will go the same way. No upstream alternatives as
> Redhat continues to steam roller ALL OF THE USERSPACE THINGS into systemd.
>
> I am sure others can comment on the intelligence, wit and charm of the
> respective systemd and Upstart developers and owners and of course should
> not be a factor in the choice ;)
>
> Cheers, Nick.
>
>
> _______________________________________________
> Bradford mailing list
> Bradford at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/bradford
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/bradford/attachments/20131029/558fe4aa/attachment.html>