3 ms·
As someone typically working with others startup units but sometimes writing my own, I appreciate a declarative format that allows user-overrides and has pretty
by stephenr 8y ago
As someone typically working with others startup units but sometimes writing my own, I appreciate a declarative format that allows user-overrides and has pretty standardised ways of doing things.
Sysvinit scripts showed us what happens when you give startup authors more power.
Even if you hate systemd’s politics/etc the actual units themselves are objectively better IMO because they’re declarative.
- bjoli 8y agoWell, the service difinition part of shepherd is pretty declarative: (make <service> #:provides '(blahblah) #:start (...) #:stop (...))) The difference is that start/stop must be guile procedures that starts or stops a command. I suspect there is a nice macro for just running a regular shell command, but I'm not sure.
- stephenr 8y agoIt’s guile. They’re instances of the <service> class (apparently). That is specifically not declarative and the fact that the only example in the official documentation is essentially the same as your example, says this project is not ready for use by humans. If you (the project) cant show a full example service definition to start something why would anyone bother going forward.
- _emacsomancer_ 8y ago> Even if you hate systemd’s politics/etc the actual units themselves are objectively better IMO because they’re declarative. It's a pity the overall system is so inflexible and brittle. Well, that and the 'death by a thousand (theoretically independent but tightly coupled) systemd components'.
- stephenr 8y agoIt has it's issues, definitely, and I'm not thrilled about "make everything part of the systemd project" - but in terms of providing a way to run your services, I think it's got a lot of functionality that e.g. sysvinit could never really support.
- _emacsomancer_ 8y agoYes, but it would be more useful to compare systemd to something that's actually comparable, i.e. a modern init like shepherd or runit, rather than sysvinit.
- stephenr 8y agoRunit to the best I can tell doesn’t have a declarative service definition. It executes (albeit simple) scripts in directories. Shepherd service definitions also don’t appear to be declarative, and they’re written in guile, a language I can best sum up as someone’s “hold my beer” response when told Perl was too hard for causal users to understand. Searching for examples of shepherd service definitions gives me one such example: the skeleton example without any details for “Apache”. So sorry but no. Regardless of systemd’s issues those are not comparable alternatives.
- _emacsomancer_ 8y ago> Regardless of systemd’s issues those are not comparable alternatives. I agree with this, but for different reasons. I have various machines, with various distros, using various init/daemon-managers, including a number of fairly complicated setups (multiple LUKS drives, ZFS, etc.). The systemd systems are invariably more burdensome to maintain, and it's nearly always systemd that's the issue. > and they’re written in guile, a language I can best sum up as someone’s “hold my beer” response when told Perl was too hard for causal users to understand. I agree that the current shepherd configuration itself seems more opaque than one would like, but to compare guile to perl in this fashion is ridiculous. Guile is a Scheme, which means it has consistent, simple syntax and is more easily understandable than C, much less perl.