
Results of the Debian systemd survey - radimm
http://people.debian.org/~stapelberg/2013/05/27/systemd-survey-results.html
======
radimm
If you haven't done so I recommend reading 'systemd - The Biggest Myths'
<http://0pointer.de/blog/projects/the-biggest-myths.html>

~~~
VLM
That's a good list of 30 or so myths and a pro-systemd explanation. It would
be interesting to have an anti-systemd rebuttal. The explanation that systemd
is non-monolithic "in design" because each binary can be separately packaged
"in packaging phase" was pretty lame because it confuses the topic to "win",
although also completely irrelevant (A better answer would have been, ok,
assume inductively for the sake of this discussion that it's monolithic...
given that inductive assumption, so what?).

1) Are there any significant/serious myths not listed?

2) Does it matter? What I mean by that is the systemd wars remind me a lot of
the sound wars from years ago. $user installs a sound system (alsa, pulse,
oss, doesn't really matter). It'll probably either work perfectly or miserably
fail. If it works, $user will blindly love that sound system and brag about
it. If it doesn't work, $user will trash talk it all over the internet. The
facts don't seem to matter, just the results of one anecdotal experience. In
an environment like that its nearly impossible to learn anything from the
community about systemd.

It reminds me a lot of those geniuses who post on world wide forums how no one
in the world should sign up for $cellphone_provider because their local tower
has poor coverage. That's just great, as if the other 99.9999% of the
population should care.

~~~
rmk2
Of course its a "pro-systemd explanation", it's Lennart Poettering's blog. Not
that it takes anything away from his explanations, it's a good post. One can
at least assume he knows what he's talking about...

------
npsimons
This is one of many reasons why I love Debian. Very agnostic, very reasonable
approaches to issues like this, and above all, whether or not systemd ends up
as the default, I can almost guarantee people will still have the option to
very easily switch to (or from) it in Debian.

That being said, I can definitely second many of the top concerns listed,
chief among them: non-greppable logs (binary formatted) and too much
complexity/trying to do too much.

~~~
jlgreco
I had no problems with systemd when I was using Fedora on my laptops (I never
had to interact with it at all), though right now I'm using Debian without
systemd and have no problems either. I don't really have a dog in this fight;
it seems either solution is going to stay out of my hair and do what it needs
to.

Nevertheless, the concept of binary logs really annoys me and I have yet to
see a satisfying explanation of why it should be necessary. The best I've seen
is _"well windows uses binary logging too"_ and _"the syslog text format
sucks"_ , but neither of those satisfies. Windows does plenty of shit that
should not be mimicked, and the benefits of text logging are severely dampened
on Windows anyway (on account of Windows not being Unix.) Furthermore, the
syslog text format sucking is not an argument for not using text logs in
general, only an argument for not using the syslog text format specifically.

Why can't we have a reasonable non-syslog text format for logs?

~~~
anonyfuss
> _Why can't we have a reasonable non-syslog text format for logs?_

I think the real question is: why is systemd defining a logging format at all?

~~~
jlgreco
Well, technically I suppose systemd doesn't, journald does (and systemd
requires journald, and journald is made and shipped by the same people....).

I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that
should be done in such close connection with systemd. A better approach would
be to make rsyslog more than just a syslog daemon and build up a new protocol
and storage format with it, with the full intention of standardizing it. (the
syslog protocol _is_ a pain in the ass, particularly that hard limit on
facility numbers... Fix that first, then roll from there. Make rsyslog treat
syslog like Vim treats vi: capable of falling back to compat mode, but better
by default.)

~~~
anonyfuss
> _Well, technically I suppose systemd doesn't, journald does (and systemd
> requires journald, and journald is made and shipped by the same
> people....)._

 _Technically_ indeed. If you try to forcibly disable journald, it causes
causes dependency failures that result in you dropping to an emergency prompt.

Of course this doesn't stop Lennart Poettering from using the existence of
separate but interdependent daemons as 'proof' that systemd isn't a monolithic
ball of mud.

> _I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that
> should be done in such close connection with systemd. A better approach
> would be to make rsyslog more than just a syslog daemon and build up a new
> protocol and storage format with it, with the full intention of
> standardizing it. (the syslog protocol is a pain in the ass, particularly
> that hard limit on facility numbers... Fix that first, then roll from there.
> Make rsyslog treat syslog like Vim treats vi: capable of falling back to
> compat mode, but better by default.)_

Agreed. This is what Apple did with asl(3); it's a modern syslog replacement
that happens to still support the syslog protocol and syslog(3) APIs.

There's no reason a modern logging daemon can't be portable to other systems,
too; it shouldn't be doing anything so crazy as to be impossible to run
elsewhere, whereas since systemd is an intentionally non-portable kitchen
sink, no other UNIX is going to run with journald.

------
viraptor
If Debian manages to actually use systemd by default, that may have
interesting implications for Ubuntu which I think is the only major distro
using upstart. All depends on how deeply would systemd be integrated of
course, since Ubuntu already rewrites most of the system startup scripts for
use with upstart anyway. I'd like to see some comment from Canonical people
about how that would affect them.

~~~
buster
Well, i hope this way Canonical learns the difference between open source
community projects and going your own lonely path.

~~~
nknighthb
So, "open source" now means "Do everything Red Hat's way."? Interesting change
in definitions.

~~~
buster
In my own definition open source means "work together, be open about your
intentions, contribute".

~~~
nknighthb
Lennart works almost alone, his "open intentions" are to explicitly _not_
support the wider open source community (like non-Linux kernels and non-GNOME
desktops), and he "contributes" to virtually nothing but his own inventions of
questionable technical merit.

Why you think Canonical is any worse eludes me.

~~~
buster
I don't see anything wrong with a single developer concentrating on a few
projects? How many developers do you know that make significant contributions
to many different projects?!

Do you have a source for you claim that lennarts explicitely not supports non-
Gnome? I think it is pretty clear that he doesn't support non-Linux, but why
is that wrong?

Looking into the git contributions he is not even the one who contributed
most! <http://pastebin.com/bkUs3jXa>

On the other hand: What i don't like about Canonical is their latest move to
first pretend to support Wayland and then mysteriously presenting Mir all the
while spreading bullshit about how Wayland is not good enough.

~~~
nknighthb
> _I don't see anything wrong with a single developer concentrating on a few
> projects?_

Neither would I, if they were projects worth concentrating on or of any
meaningful long-term value to the community.

> _I think it is pretty clear that he doesn't support non-Linux, but why is
> that wrong?_

systemd invites/demands dependencies on its own, unique interfaces that do not
and will not exist outside Linux. This retards progress of other projects in
supporting non-Linux systems.

Lennart has actively encouraged this:
[https://mail.gnome.org/archives/desktop-devel-
list/2011-May/...](https://mail.gnome.org/archives/desktop-devel-
list/2011-May/msg00427.html)

> _What i don't like about Canonical is their latest move to first pretend to
> support Wayland and then mysteriously presenting Mir all the while spreading
> bullshit about how Wayland is not good enough._

Red Hat began to support Upstart before switching to their in-house systemd
and spreading bullshit about how Upstart is not good enough.

Why is it OK when Red Hat tries to come up with new things but not Canonical?
Do you work for one of these companies?

> _Looking into the git contributions he is not even the one who contributed
> most!_

See my other post downthread. You are incorrect.

~~~
buster
No, not working for any of them. See my comment that it's still incorrect
saying Lennart does all the work. You can easily check the git yourself, go
ahead.

~~~
jeltz
Was there something wron with the methodology used in
<http://lists.debian.org/debian-devel/2013/05/msg01365.html> which showed a
78% contribution from Pottering?

Personally I do not see anything wrong with that, but 78% is basically doing
all the coding.

~~~
buster
Well, i did the same and came to vastly different numbers. It's easy to do: Do
a git checkout and run

git ls-files | grep -v udev | xargs -n1 -d'\n' -i git blame {} | perl -n -e
'/\s\\((.*?)\s[0-9]{4}/ && print "$1\n"' | sort -f | uniq -c -w3 | sort -n

Even taking out udev shows Kay Sievers contributing nearly as much as Lennart.
It also shows many other people contributing. That there is a main developer
that does a lot of work is not something negative about a project, isn't it?!

~~~
nknighthb
> _i did the same_

No, you didn't. Your command line is not limited to source code, but includes,
for starters, the massive hardware database checked in by Kay:

    
    
       66888 hwdb/20-pci-vendor-model.hwdb
       66185 hwdb/20-OUI.hwdb
       49014 hwdb/20-usb-vendor-model.hwdb
        6596 hwdb/20-acpi-vendor.hwdb
    

You performed a fundamentally different and flawed test.

> _That there is a main developer that does a lot of work is not something
> negative about a project, isn't it?!_

You were the one who complained about Canonical not "working together", not
me. I'm just holding you to your own standard.

------
kunai
I wonder why no distributions have adopted launchd as their SysV init
replacement. Not only does it combine cron, at, and other daemons into init
itself, but it's also licensed liberally and would serve as a quite decent
replacement for init. It's also cross-compatible with BSD and Linux systems.

Is it perhaps the stigma that comes with using a product developed by Apple?

~~~
jff
> Not only does it combine cron, at, and other daemons into init itself

I think I found the reason.

~~~
kunai
When is that last time you used cron to schedule jobs?

Be honest.

~~~
e1ven
Earlier this morning?

It might be because I'm an ops guy, but I use Cron to schedule things on a
regular basis, even in my personal work.

It's pretty crazy good at what it does. Being able to say "Filter my email
every 5 minutes", is awesome.

    
    
      */5 * * * /usr/local/bin/filter-email.sh

------
jeltz
Does anyone know if the GSoC last year attempting to write a systemd ->
sysvinit converter got anywhere? To me that sounded like a very ambitious
project given the socket activation in systemd.

<https://github.com/akhilvij/systemd-to-sysvinit-converter>

~~~
secure
It got to a state where it is somewhat working, but it doesn’t handle a lot of
cases. When I tried to use it for a simple real-world daemon, it didn’t work.
AFAICT, nobody actually cares enough to continue development (though some
people want to see it succeed).

------
buster
Sounds great.. i'm using Debian on my Desktop and i would welcome such a move!
Let the good old sys-v init system die, it has served long enough. I
understand that most old init scripts would even work in systemd, so i imagine
the migration not being as painful as it may seem..

~~~
viraptor
I've got mixed feelings about this. I really like the idea behind
systemd/upstart (they're quite similar in practice) and was glad to migrate to
systemd when Arch sorted out most of its integration issues.

But to be honest, I prefer upstart much more. It's simple, it does one thing,
it's clear about what happens (most of the time). With systemd I find myself
quite often with no idea where to even look for information about something
not starting. I still have a service in the system that I don't know how to
remove (it's failing to start apparently, not even sure where does it get
created). I spent hours debugging issues and trying to get it all-green on my
system... and failed. In my opinion it's just too big and complex for it's own
good. For my deployments upstart provides the equivalent behaviour in the part
that matters (actually running the software) in a simpler way and does not try
anything else.

~~~
fuzzix
"With systemd I find myself quite often with no idea where to even look for
information about something not starting"

You could read the (currently) 20-part sysadmin guide.

[http://0pointer.de/blog/projects/socket-activated-
containers...](http://0pointer.de/blog/projects/socket-activated-
containers.html)

/sbin/init and its simple shell scripts never required this much explanation.

~~~
viraptor
I read (most of) it, but there's a big difference between "I know how this
works" and "I can debug why things don't work as I expect them to work after
reading documentation" with systemd. This gap doesn't exist with sysv style
init scripts and I couldn't find much information addressing the issue.

~~~
bkor
You're confusing existing knowledge you already have with how easy another
system is. Obviously if you already know one system, the other system will
seem more difficult.

I have had my fair share of daemons not starting due to various problems. E.g.
openldap (terribly confusing debug messages). Give me systemd any day over the
complexity of a lot of those scripts.

~~~
ldng
Had not seen your comment before adding mine but I think you're spot on. And
having had to fight with openladp last week I can only agree with you. I used
to know the "old" standard text file config and the new slap.d config style is
confusing.

But I think it's comparable to systemd in that if you manage an LDAP directory
day to day, the new system probably makes more sens once you're used to it.

We have to relearn the config and, man, sometimes we can be a lazy whiny bunch
when we should try to evaluate systemd more objectively ;-)

As an aside, the survey pleased me as I expected more conservatism from Debian

~~~
bkor
I didn't mean the openldap config. Sometimes the daemon just plainly does not
start. You basically have to resort to using strace to figure out what is
wrong with the thing. Systemd redirects stderr and stdout, highly useful IMO.

Openldap gives difficult to debug starting problems in loads of cases. E.g.
problem in a certificate, config problem, etc. Then you might want to increase
the debugging level. Really not fun to look into some script and figure out
what actually eventually is passed to the openldap daemon as arguments.

