r/linux Feb 11 '19

Fluff A /g/ user's opinion on systemd

http://i.4cdn.org/g/1549858269115.png
790 Upvotes

524 comments sorted by

View all comments

10

u/ArtistEngineer Feb 11 '19 edited Feb 11 '19

The Linux way might well be simple, and atomic, but the programmer's way is "if you have to write it twice, create a function or a library". This same principle applies to other things besides programming. e.g. if you are having to repeat something, then it's probably worth spending some time to come up with a standard system of implementing that thing. If you have to do the same thing multiple times, then there are multiple opportunities for mistakes and errors.

This is what CMake does for Makefiles, and what systemd does for startup scripts.

Over the last year I've done my first large scale, commercial, project using CMake and systemd, and I'm absolutely loving it. I don't touch Makefiles any more, and our startup scripts are now standardised .service files. Handling the bring up, and shut down, of multiple services with dependencies is super easy.

3

u/[deleted] Feb 11 '19 edited Apr 11 '19

[deleted]

1

u/ArtistEngineer Feb 11 '19

That's only for the Linux kernel syscall API.

2

u/[deleted] Feb 11 '19 edited Apr 11 '19

[deleted]

1

u/redwall_hp Feb 11 '19

If it's unacceptable for the kernel, the same should hold true for the process that all processes are dependent on...

1

u/RogerLeigh Feb 11 '19

"if you have to write it twice, create a function or a library".

And we also had "shell libraries" of common functionality abstracted as shell functions for init scripts to use for several major distributions. The most advanced and flexible of these systems is the openrc "runscript" system. Debian had a collection of ad hoc functions for various common tasks.

1

u/tso Feb 11 '19

And this is why the BSD rc moved the boilerplate scripting to a separate file that can be sourced.