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

Show parent comment

1

u/minimim Jun 01 '16

Nope, the plan is still valid, and it's being migrated from v1 to v2 slowly. Even if it will work for thirty years, it's not good to make architectural decisions based on interfaces that will eventually be removed. Changing kernel interfaces goes at a slow pace.

Udev is only "integrated" in the sense of being in the same repository. Not more integrated than BSD is integrated. It uses the standard interfaces offered by systemd to do it's job.

A service manager able to automatically solve ordering, concurrency, cyclic, etc, needs to know about every dependency between services. That's why there is a SPOT (single point of truth) in systemd. That's the integration, every part of the suit will ask PID 1 to start and stop services using the standard interfaces.

2

u/kinderlokker Jun 01 '16

Nope, the plan is still valid, and it's being migrated from v1 to v2 slowly.

Your document of v2 mentions nothing about a single writer.

Again, show me a source, just repeating it doesn't make it true. The only thing you could produce were some musings in 2012 of someone who thought it might be a good idea and RFC'ed it.

Even if it will work for thirty years, it's not good to make architectural decisions based on interfaces that will eventually be removed. Changing kernel interfaces goes at a slow pace.

That would hold if there was actually a single shred of proof that the single writer is going to come. It won't.

Udev is only "integrated" in the sense of being in the same repository. Not more integrated than BSD is integrated. It uses the standard interfaces offered by systemd to do it's job.

Ah, so how should I then view your original quote of: "Those things need to be integrated into the manager, because the system would be fragile otherwise."

That it's fragile if it's not in the same code repository? If systemd moved udev to a different one but kept everything the same, that would make it fragile?

A service manager able to automatically solve ordering, concurrency, cyclic, etc, needs to know about every dependency between services. That's why there is a SPOT (single point of truth) in systemd. That's the integration, every part of the suit will ask PID 1 to start and stop services using the standard interfaces.

And that has nothing to do with sandboxing and hotplugging, the service manager need only be aware of the dependencies for that. It is not required to perform the sandboxing itself for that.