systemd

Lennart Poettering
PulseAudio, systemd, Avahi
works for redhat
long term contributor of the GNOME project and GNOME Foundation member
key developer of kdbus

debian switched yesterday to systemd

``In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!'' --Lennart

Please. No more.

everything in this thread is awful

debian switched yesterday to systemd

FUCK

>>1
Who are you quoting, by the way?

>>5
I am quoting wikipedia

>>6
Ctrl+F didn't yield any results in
http://en.wikipedia.org/wiki/Systemd or http://en.wikipedia.org/wiki/Debian.

That's not how quoting works.

Which one of you guys was this?

http://lists.debian.org/debian-ctte/2014/02/msg00376.html

>>7

I commend you for the effort.

>>7
try https://en.wikipedia.org/wiki/Lennart_Poettering
each line is different quote

>>8
he must be from /g/

>>8

This thread is great. https://lists.debian.org/debian-ctte/2014/02/msg00392.html

"Oh. My. Money"
'Don't you mean God?'
"You worship your thing, I'll worship mine"
--Seto Kaiba
:: Correct way to do things.

Writing from ``fklennart.pottering@aol.com'' no less, making a point about the Unix philosophy. And I thought I was mad.

I would appreciate it if the amount of pointless /g/ crossposting could be kept to a minimum.

_please

>>12
I went on /g/ to confirm this. There is a thread with the exact same content in >>1-kun's post.

>>1
Please stay there.

>>12-13
no

Avahi is a privacy disaster. Pulse is pretty nice. I don't know about systemd; are there plans to port it to the *BSDs?

>>15
Hell no.

LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups, udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux API has been taking the role of the POSIX API and the other systems are irrelevant ?
Lennart : Yes, I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit.

I can't find the quote, but he's also stated that he doesn't care about POSIX or cross-platform design, as opposed to answering ``yes'' when someone else asked the question. Which is, frankly a good thing. Given systemd's problems (see e.g. http://ewontfix.com/14/ and http://ewontfix.com/15/ ) I would sooner switch to FreeBSD than let it on my system, and Lennart, Gnome, and the rest of the RedHat bunch ignoring FreeBSD means they won't fuck it up.

Pulse is okay once you rip out consolekit and associated baggage (I don't have to write clean_up_pulse.sh scripts anymore that blindly rm magic files), but I wish OSS was still a viable solution.

>>16
Is it possible to write a shitty not-as-featured version that is still compatible with it, though?

>>17
There would be nothing to gain from doing so (I, a user, would still be shafted out of my init system), and it would send a message to daemon developers that ``Yeah, even the *BSDs are fine with systemd, so go ahead and bind your programs as tightly as you like to that API!'' I don't want to compromise with sytemd at all. I don't think the OpenSSH folks are going to merrily bake systemd-specific code into sshd, but I don't want to give them any more incentive to than what RedHat is already undoubtedly offering.

>>16-18
I think all the discussion of systemd being overly complex is missing the point. systemd is large and complex because the kernel interface it must mediate to robustly start and stop daemons is also complex. The exposed surface of the Linux kernel today is *huge* and just keeps getting bigger; unless that trend is reversed init systems are just going to get hairier and hairier. Using shell scripts like sysvinit does may or may not be a better way to deal with the complexity, but it certainly doesn't eliminate it in any way.

I think the real problem that nobody wants to talk about is this: Linux is becoming a mature system. That means that the cost of removing problematic but useful features for the most part outweights the cost of doing so. The result is a system that either ossifies, continues to grow until it becomes unmanageable, or is replaced (perhaps incrementally).

It's sad, but many of the discussions that you now see happening about Linux are the same discussions you used to see happening about Windows 10 years ago (endemic security problems, painful ABI regressions, etc.) Weren't we supposed to be better at this?

>>19
Your point is interesting, although my first instinct is to quibble over terms, but I think you're assuming that just because the exposed surface of the kernel is large, init systems must use it, and I completely disagree with that. Sysvinit is hardly complex, and [a modified version of] it works for me despite growth of the kernel. Unless too many devs sell their souls to dbus I forsee no problems in the future, no matter how many features are added to Linux.

Certainly it is true that as the surface of the kernel becomes larger, the possible maximum complexity of an init system skyrockets, but I am hopeful that secondary forces such as user adoption will prevent that complexity from actually being reached.

>>20
There are a few things about systemd's design goals that mean it ends up touching a lot of kernel interfaces. These are

1. The ability track a daemon's status after they are started, irrespective of whether the daemon spawns children and / or dies

2. The ability to start daemons in response to socket activity (like xinetd)

3. The ability to start daemons that depend on other daemons in a race-free way

If you do away with some of these you can potentially produce a simpler init system, but that just pushes the problem somewhere else. sysvinit did this and the result was init scripts with crazy things like sleeping for random intervals to give daemons time to start up.

>>21
I am aware of systemd's design goals. I just think those design goals are either needless, or don't require as much complexity as systemd demands. Arbitrary sleep N is pretty much the only problem I've ever had with sysvinit, and (from a user's perspective, at least) Gentoo's setup of Sysvinit + OpenRC has solved that for me without resorting to Systemd-levels of complexity or dubious daemon-lockin.

So they're trying to copy Apple and doing a poor job of it. Sounds typical.

I feel I should point out this entire chain: http://lkml.org/lkml/2014/4/2/415

In which Systemd decides to make passing ``debug'' to the kernel command line completely useless. The punchline is the tongue-in-cheek proposal of the following patch:

--- a/fs/read_write.c~a
+++ a/fs/read_write.c
@@ -513,6 +513,8 @@ SYSCALL_DEFINE3(read, unsigned int, fd,
struct fd f = fdget_pos(fd);
ssize_t ret = -EBADF;

+ BUG_ON(!strcmp(current->comm, "systemd"));
+
if (f.file) {
loff_t pos = file_pos_read(f.file);
ret = vfs_read(f.file, buf, count, &pos);

>>23
Systemd doesn't care about simply copying Apple. Systemd is about managing the whole system, this isn't something that Apple achieves with their system booting.

>>25
I think the joke was that ``managing the whole system'' is something Apple does. So systemd is copying Apple itself, not iOS/OS X's init system, whatever that is. This is funny because an init system and a software company are, on the surface, two different things, but a similarity between them can be constructed. This is a subversion of expectation and therefore humorous.

>>24
Oh wow.

Generic terms are generic, not the first user owns them.

- Red Hat employee, describing how their product is at the root of everyone's namespace and there's nothing you can do about it

I knew these guys were arrogant, but wow. That's just... amazing.

>>27
Red Hat is the biggest, or one of the biggest FOSS companies out there, and I'm pretty sure that as an organization they are the top contributor to the Linux kernel. I want to like them, but pretty much every terrible, misengineered thing about FOSS^* I can think of in recent years (except Mono) seems to end up tracing back to RH employees. I hope that's just saturation, as opposed to an organization-wide direction that is remaining mostly unnoticed by me, a user.

^{* At least, among FOSS that associates itself with the Linux kernel}

>>28
Saturation is an organization-wide strategy. Just look at what Google has done with WebKit.

$ cat /etc/redhat-release
Fedora release 20 (Heisenbug)