6 ms·

Is Shepherd meant to be a replacement for systemd (et al), then? If so, what makes it different? If not, what's it for?

bjoli 8y ago
It is the unit system of GNU guix, and it has a better integration with the guix. You write guix packages and manage the Daemon using the same language. I'd suspect that you with ease can programmatically interface with both of them using guile as well. As a scheme fanboy I like the idea of being able to use a proper programming language (opinions may differ) for my startup scripts Edit: read about how guix uses services here: https://www.gnu.org/software/guix/manual/en/html_node/Defining-Services.html#Defining-Services https://www.gnu.org/software/guix/manual/en/html_node/Defini...
- majewsky 8y ago
  > I like the idea of being able to use a proper programming language (opinions may differ) for my startup scripts I don't know. I rather like the NixOS way, where a proper programming language generates the startup scripts (or, in that case, systemd units), but then those scripts are dumb and obvious. Many things are better when they're dumb and obvious.
  - armitron 8y ago
    The problem with Nix is that it's not a proper programming language. I'll take Scheme over yet another obscure language that manages to irritate me in many ways.
    - res0nat0r 8y ago
      I setup and used a headless nixos box for about a year or so, it was fun to play around with but I did get tired after a while of the nix programming language. It was just too weird to figure out and google around to try and find what I needed to do sometimes. Trying to get virtualenvs of python packages, or using rbenv / bundler type installs for ruby was also just too much of a pain in the butt. https://nixos.org/nixpkgs/manual/#sec-language-ruby https://nixos.org/nixpkgs/manual/#sec-language-ruby Trying to figure my way around installing ruby/python libraries just was too hard most of the time without a good amount of work that it wasn't worth it in the long run. Guix has been on my radar to try and install and play with in-depth soon. If their installer will work with a VM without a days worth of research to work around any quirks I'm all in for checking it out.
      - lfam 8y ago
        Installing Guix in a VM has its own section of the manual: https://www.gnu.org/software/guix/manual/en/html_node/Installing-GuixSD-in-a-VM.html https://www.gnu.org/software/guix/manual/en/html_node/Instal...
        res0nat0r 8y ago
        I think I remember trying that a while back and couldn't quite get it working, I'll need to try again soon.
    - pknopf 8y ago
      If you want immutability with a traditional package manager, try Darch: https://godarch.com https://godarch.com
  - bjoli 8y ago
    I agree, but having an option instead of having to do ExecStop=path-to-shell-script-that-does-some-stupid-housekeeping is pretty neat. Most shepherd service definitions are simple and stupid, but as always it is a matter of taste.
    - nerdponx 8y ago
      But the shell scripts are more or less portable across systems, whereas this way you were asking developers to re-implement the same cleanup logic in another language.
    - stephenr 8y ago
      > but having an option instead of having to do ExecStop=path-to-shell-script-that-does-some-stupid-housekeeping is pretty neat. IMO this is usually the result of eg a Debian package that also ships sysvinit startup scripts, and thus they share some logic. If it’s not that case I wonder why the cleanup can’t just be handled in the unit directly.
      - Skunkleton 8y ago
        Perhaps the service being managed doesn't clean up after itself properly? It is a fairly common pattern for a program to ship without startup scripts, and then have startup scripts added by package maintainers.
        stephenr 8y ago
        Right that’s certainly a thing but what I meant is, why not just put the cleanup instructions in the unit file.
        Skunkleton 8y ago
        Because "cleanup" can be non-trivial. Maintaining scripts inside unit files is a pain in the ass.
- 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 ago
    Well, 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 ago
      It’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 ago
      It 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.
nerdponx 8y ago
https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/ It replaces the init & service management features of systemd.
nextos 8y ago
Yes, it is an alternative init system. So it can replace systemd. It is in fact used as such in GuixSD, the NixOS alternative by GNU which is written in Guile Scheme.
- privateSFacct 8y ago
  Yowks - I know systemd gets lots of hate and this is “real” programming - but it does feel a bit niche from a language etc perspective?
  - nextos 8y ago
    I don't think Guile is too niche. In fact, Guix has a quite active community. Nowhere as Nix in terms of activity, but it's pretty nice and very friendly too.
    - dwohnitmok 8y ago
      I don't know about Guile's popularity, but I use NixOS as my daily driver distro and in my experience Nix is already very niche in the programming circles I run in. That's not to say Guix shouldn't be developed or that Shepherd is bad, it's just that I would definitely call Guix niche.
laumars 8y ago
> what makes it different? It's GNU, others aren't. There will be other well reasoned arguments in favour of Shepherd but it essentially boils down to the same reason Hurd (the kernel) is a thing when GNU/Linux is already widespread. That all said, I don't see the harm in competing solutions. Better to have a choice rather than lock ins.
- aries1980 8y ago
  Systemd is licenced under LGPL, why would it lock you in?
  - laumars 8y ago
    Sorry, that was a poor choice of words on my part. What I really meant was "better to have more options rather than fewer".
  - yarrel 8y ago
    It's locking people in by eating the OS and making it difficult to move away from its tightly coupled and increasingly tightly integrated components (that, we must never forget, are not a single binary).
  - yjftsjthsd-h 8y ago
    It only supports Linux, for one. Shepherd supports HURD and probably other systems.
deleted 8y ago
[deleted]
bitwize 8y ago
Shepherd (as dmd) predates the systemd project considerably. It is intended to fill the same niche (init system, process monitor) as systemd, though.

It is the unit system of GNU guix, and it has a better integration with the guix. You write guix packages and manage the Daemon using the same language. I'd suspect that you with ease can programmatically interface with both of them using guile as well. As a scheme fanboy I like the idea of being able to use a proper programming language (opinions may differ) for my startup scripts Edit: read about how guix uses services here: https://www.gnu.org/software/guix/manual/en/html_node/Defining-Services.html#Defining-Services https://www.gnu.org/software/guix/manual/en/html_node/Defini...

majewsky 8y ago
> I like the idea of being able to use a proper programming language (opinions may differ) for my startup scripts I don't know. I rather like the NixOS way, where a proper programming language generates the startup scripts (or, in that case, systemd units), but then those scripts are dumb and obvious. Many things are better when they're dumb and obvious.
- armitron 8y ago
  The problem with Nix is that it's not a proper programming language. I'll take Scheme over yet another obscure language that manages to irritate me in many ways.
  - res0nat0r 8y ago
    I setup and used a headless nixos box for about a year or so, it was fun to play around with but I did get tired after a while of the nix programming language. It was just too weird to figure out and google around to try and find what I needed to do sometimes. Trying to get virtualenvs of python packages, or using rbenv / bundler type installs for ruby was also just too much of a pain in the butt. https://nixos.org/nixpkgs/manual/#sec-language-ruby https://nixos.org/nixpkgs/manual/#sec-language-ruby Trying to figure my way around installing ruby/python libraries just was too hard most of the time without a good amount of work that it wasn't worth it in the long run. Guix has been on my radar to try and install and play with in-depth soon. If their installer will work with a VM without a days worth of research to work around any quirks I'm all in for checking it out.
    - lfam 8y ago
      Installing Guix in a VM has its own section of the manual: https://www.gnu.org/software/guix/manual/en/html_node/Installing-GuixSD-in-a-VM.html https://www.gnu.org/software/guix/manual/en/html_node/Instal...
      - res0nat0r 8y ago
        I think I remember trying that a while back and couldn't quite get it working, I'll need to try again soon.
  - pknopf 8y ago
    If you want immutability with a traditional package manager, try Darch: https://godarch.com https://godarch.com
- bjoli 8y ago
  I agree, but having an option instead of having to do ExecStop=path-to-shell-script-that-does-some-stupid-housekeeping is pretty neat. Most shepherd service definitions are simple and stupid, but as always it is a matter of taste.
  - nerdponx 8y ago
    But the shell scripts are more or less portable across systems, whereas this way you were asking developers to re-implement the same cleanup logic in another language.
  - stephenr 8y ago
    > but having an option instead of having to do ExecStop=path-to-shell-script-that-does-some-stupid-housekeeping is pretty neat. IMO this is usually the result of eg a Debian package that also ships sysvinit startup scripts, and thus they share some logic. If it’s not that case I wonder why the cleanup can’t just be handled in the unit directly.
    - Skunkleton 8y ago
      Perhaps the service being managed doesn't clean up after itself properly? It is a fairly common pattern for a program to ship without startup scripts, and then have startup scripts added by package maintainers.
      - stephenr 8y ago
        Right that’s certainly a thing but what I meant is, why not just put the cleanup instructions in the unit file.
        Skunkleton 8y ago
        Because "cleanup" can be non-trivial. Maintaining scripts inside unit files is a pain in the ass.
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 ago
  Well, 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 ago
    It’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 ago
    It 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.

nerdponx 8y ago

https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/ It replaces the init & service management features of systemd.

nextos 8y ago

Yes, it is an alternative init system. So it can replace systemd. It is in fact used as such in GuixSD, the NixOS alternative by GNU which is written in Guile Scheme.

privateSFacct 8y ago
Yowks - I know systemd gets lots of hate and this is “real” programming - but it does feel a bit niche from a language etc perspective?
- nextos 8y ago
  I don't think Guile is too niche. In fact, Guix has a quite active community. Nowhere as Nix in terms of activity, but it's pretty nice and very friendly too.
  - dwohnitmok 8y ago
    I don't know about Guile's popularity, but I use NixOS as my daily driver distro and in my experience Nix is already very niche in the programming circles I run in. That's not to say Guix shouldn't be developed or that Shepherd is bad, it's just that I would definitely call Guix niche.

laumars 8y ago

> what makes it different? It's GNU, others aren't. There will be other well reasoned arguments in favour of Shepherd but it essentially boils down to the same reason Hurd (the kernel) is a thing when GNU/Linux is already widespread. That all said, I don't see the harm in competing solutions. Better to have a choice rather than lock ins.

aries1980 8y ago
Systemd is licenced under LGPL, why would it lock you in?
- laumars 8y ago
  Sorry, that was a poor choice of words on my part. What I really meant was "better to have more options rather than fewer".
- yarrel 8y ago
  It's locking people in by eating the OS and making it difficult to move away from its tightly coupled and increasingly tightly integrated components (that, we must never forget, are not a single binary).
- yjftsjthsd-h 8y ago
  It only supports Linux, for one. Shepherd supports HURD and probably other systems.

deleted 8y ago

[deleted]

bitwize 8y ago

Shepherd (as dmd) predates the systemd project considerably. It is intended to fill the same niche (init system, process monitor) as systemd, though.