| 1 |
On 19/12/2016 16:52, Marc Joliet wrote: |
| 2 |
|
| 3 |
... |
| 4 |
|
| 5 |
> I'm not convinced that you actually understand systemd particularly well. It |
| 6 |
> seems to me that if you want to develop an informed opinion about it, you |
| 7 |
> should: |
| 8 |
> |
| 9 |
> a) Read the official documentation (don't just rely on what others say; even |
| 10 |
> when well-intentioned, people can say stupid things). |
| 11 |
> |
| 12 |
> b) Try to set up and/or run a systemd-based system, and seriously try to grok |
| 13 |
> it. Only then will you be able to compare it to other init systems properly. |
| 14 |
|
| 15 |
... |
| 16 |
|
| 17 |
I feel the same way. |
| 18 |
|
| 19 |
systemd is declarative and simple variables in a unit define what you |
| 20 |
want. This makes sense - the list of what management functions a service |
| 21 |
supports is a very short list - start/stop/restart/status. Apart from |
| 22 |
configtest (a la Apache) what else is there really? |
| 23 |
|
| 24 |
systemd could be the poster child for the declarative style and knock |
| 25 |
ansible off it's perch where it currently reigns :-) |
| 26 |
|
| 27 |
Looking at SysVInit, it's only real grace is that it's been around for |
| 28 |
30+ years. But it defers all decisions to the daemon author/packager; |
| 29 |
after a short while the ecosystem is so cluttered with weird scripts, |
| 30 |
that packagers resort to bolting a declarative layer on top of init |
| 31 |
scripts, as in the boilerplate you mentioned. The truth is, as designs |
| 32 |
go, sysvinit is a /terrible/ design. It only lasted 30 years because it |
| 33 |
forces all the tricky bits to be someone else's problem |
| 34 |
|
| 35 |
-- |
| 36 |
Alan McKinnon |
| 37 |
alan.mckinnon@×××××.com |
Archives