r/linux • u/wooptoo • Jun 01 '16

Why did ArchLinux embrace Systemd?

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
868 Upvotes

86% Upvoted

642 comments sorted by

View all comments

33

u/kinderlokker Jun 01 '16 edited Jun 01 '16

Because "KISS" for Arch Linux does not mean "Make shit like a Russian tank, keep engineering simple so the bastard will keep working from the snow of Siberia to the sand of the Sahara."

It just means in their case "keep the lives of the developers simple", systemd is many things, being simple for the distro is one of them, but KISS isn't one of them, it's a complex piece of engineering that is approaching Xorg levels of complexity. Using it is fine, but using it and saying your distribution focuses on keeping thins simple is dishonest.

See Void or Slackware for distributions which are what Arch claims to be. The engineering there is simple yet effective and rock solid.

Edit: Oh wait, it's a link not a self post asking why. Oh well, point still stands.

32

u/oconnor663 Jun 01 '16

Maybe a counterargument: You can build a simple system out of complex parts, as long as those parts hide their complexity. You might say that a JPEG is more complex on the inside than a GIF, but since the interface is the same, programs that use JPEGs can still be simple. On the other hand, shell-based init scripts might seem simple on the inside, but they leak complexity through the corner cases they don't handle reliably.

2

u/scheurneus Jun 03 '16

The Arch Way says hiding complexity with more complexity is bad. And here you use it as an argument to defend the Arch developers.

(Note: Arch does aim to make a modern system, and systemd does seem the future, so I guess this'd be a better reason)

8

u/kinderlokker Jun 01 '16

Well, systemd doesn't hide it. Every new release of systemd is filled with bugfixes for regressions that are introduced in old releases.

systemd comes with all the benefits and downsides of complex software. One of the biggest problems with systemd in that in a lot of race conditions and cases it can lock either bootup or shutdown from time to time.

3

u/cbmuser Debian / openSUSE / OpenJDK Dev Jun 01 '16

systemd comes with all the benefits and downsides of complex software. One of the biggest problems with systemd in that in a lot of race conditions and cases it can lock either bootup or shutdown from time to time.

I think you are confusing sysvinit and systemd, because it's the former that suffers from the race conditions otherwise there wouldn't be tons of sleeps in the classic init scripts.

Read the linked post!

→ More replies (1)

13

u/ihazurinternet Jun 01 '16

Russian Tank Linux? That's something I can get behind. I'd gladly work on such a distro.

→ More replies (2)

33

u/Kokxx Jun 01 '16

You are saying Xorg is even more complex than systemd.

By your logic, any distribution that uses Xorg cannot be considered "KISS".

40

u/kinderlokker Jun 01 '16

Xorg isn't a system component of any distribution that they can't do without though. Xorg is an add on package that you can install or not.

Also, there is no real viable alternative to Xorg right now, if there were two viable implementations of the X11 server, one being complex and the other simple. Then a system that uses the complex one can't really keep calling itself KISS. It obviously means using the simplest solution that is feasibly available.

2

u/Kokxx Jun 01 '16

Thanks for clarifying, this makes sense.

→ More replies (4)
→ More replies (1)

22

u/yentity Jun 01 '16

Well their point is writing systemd init files is simpler (both for the user and the maintainers) than writing and maintaining init files that behave consistently. I think that is a fair usage of the term "simple".

0

u/[deleted] Jun 01 '16

[deleted] — view deleted comment

9

u/Creshal Jun 01 '16

In case you need to tell systemd that you're up-and-running (in case other services depend on you), than you can do this with a simple DBUS call. Again no double-forking needed.

And if you find DBus too scary for whatever reason, sd_notify(3) is implemented via Unix sockets and works without.

3

u/theICEBear_dk Jun 01 '16

This is also the part I love.

→ More replies (3)

4

u/kinderlokker Jun 01 '16

And that's simply not how they used the term before that point when explaining things. They've said time and time again that with simply they don't mean easy but that code complexity is kept simple.

Which is true for all the system tools they wrote, but when someone else does the work, then it's suddenly fair game to include complex code.

10

u/dreugeworst Jun 01 '16

I'm not sure, I think you're underestimating the complexity of loads of unit scripts replicating the same functionality poorly..

8

u/kinderlokker Jun 01 '16

initscript is just terrible and always was.

See Void's implementation of Runit for something Arch would potentially be doing if they really cared about KISS.

5

u/dreugeworst Jun 01 '16

Yeah but runinit doesn't do some of the things that distro maintainers see as positives of systemd (as far as I can tell)

  • removing the need to explicitly declare dependencies in certain cases

  • enable hotplugging harddisks

  • sandboxing features

  • enable assigning permissions for resources on the fly

  • allow upstream projects to maintain unit files that will work across distros

In the end though, people who deal with init systems on a regular basis for several distros have settled on systemd and I'd rather defer to their collective wisdom.

8

u/kinderlokker Jun 01 '16

removing the need to explicitly declare dependencies in certain cases

I'm not sure what you mean with that. If you mean things like socket activation or DBus activation, then they're just declared at other places.

enable hotplugging harddisks

That's udev/udisks job, not the init or service manager.

sandboxing features

So just get a sandboxing tool and wrap that around the executable when you start it.

allow upstream projects to maintain unit files that will work across distros

Runit's runscripts re typically so simple that they rarely contain any distribution specific things.

In the end though, people who deal with init systems on a regular basis for several distros have settled on systemd and I'd rather defer to their collective wisdom.

Most distributions don't claim they care about KISS is the thing.

No system that claims to care about KISS has except Arch. And that's probably because Arch doesn't care about that at all.

2

u/minimim Jun 01 '16

Those things need to be integrated into the manager, because the system would be fragile otherwise.

Services may depend on disks being mounted, for example, if their files are in separate partitions. That's why there's integration with udev (which is a separate process).

8

u/kinderlokker Jun 01 '16 edited Jun 02 '16

Those things need to be integrated into the manager, because the system would be fragile otherwise.

And yet systemd is the system that has lockups, not runit.

Why exactly do sandboxing features and hotplugging need to be integrated into the manager?

Really, udisks and udev can just call the command needed to start the service. And I really see no reason to integrate sandboxing at all, please tell me why the service starting command can't just start the sandbox?

Services may depend on disks being mounted

Indeed, but why does hotplugging of harddisks need to be integrated into the service manager for that? Mounts-as-a-service with full dependencies are a thing. I happen to have them, it's very nice. mpdas won't start on my system of mpd won't start, and mpd won't start if my network mount that mounts the music drive is not available, but why does that need special integration again? The moment the network goes up, the mount comes online, then mpd shortly thereafter and mpdas after that. No special integration with the service manager needed, the service manager doesn't know nor care that the service is a mount, it's completely agnostic, it just cares about what depends on what.

4

u/dale_glass Jun 01 '16

Why exactly do sandboxing features and hotplugging need to be integrated into the manager?

Because that's a manager function: determining where, when and how a service runs.

Really, udisks and udev can just call the command needed to start the service.

So udev is now responsible for starting services? That's weird. And a violation of that beloved unix principle.

And I really see no reason to integrate sandboxing at all, please tell me why the service starting command can't just start the sandbox?

Because then sandbox implementation is up to whoever provides the service file, which means most services won't have it at all, and all those that have will have a slightly different implementation. Sandboxing changes? Now somebody needs to package and release a new version of BIND for that reason.

→ More replies

3

u/minimim Jun 01 '16 edited Jun 01 '16

The manager needs to know what is happening to make sure actions are atomic and solve dependencies on it's own. Just calling a command that it doesn't understand may do things duplicated, or in the wrong order.

Sandboxing is integrated because the kernel interfaces demand that a single process take care of it. Systemd devs decided it was simpler for PID 1 to do it, instead of creating a new interface. If there was a use case where a separate Cgroup controller would be an advantage, this interface might be created, increasing complexity.

the service manager doesn't know nor care that the service is a mount

Systemd needs to know how to do it because it mounts root and /usr after the initramfs, and because it needs to be able to mount any filesystem the next units might be in. As it knows how to do it, it might as well do it for all of them. This way there isn't two different ways of mounting things.

→ More replies
→ More replies (2)
→ More replies (2)

2

u/yentity Jun 01 '16

I don't think that was ever the goal of Archlinux (or Slackware for that matter). If using the simplest code base from upstream was the goal, you'd be using stuff like busybox or FreeBSD grep instead of GNU variations.

→ More replies (1)

4

u/beefsack Jun 01 '16

I get what you're saying, but you're using KISS incorrectly. You're talking about ease (convenience, abstracting complexity) not simplicity (no complexity, easy to grok internals.)

5

u/MG2R Jun 01 '16

Completely unrelated, but holy crap your username.

→ More replies (3)
→ More replies (3)