This comment demonstrates a misunderstanding of shepherd and guix. Using an actual programming language vs some bastardized version of a markup language to describe complex configurations is increasingly popular because it is better. guix is inspired by nix and allows you to specify the entire system as code in a reproducible manner - which you don’t want to do in ‘human readable’ toml+, yaml+, etc. because it fucking sucks.
I like when tools abstract away the programming parts
You can use scheme to abstract away scheme lol. These are advanced tools for advanced systems.
*I use systemd all the time, but a direct comparison between systemd and shepherd without additional context is misleading and flawed.
Ah right so sherperd is designed for developers and professional sysadmins, and systemd is something that “normal” users (e.g. Ubuntu users) might use?
I’m a developer who does the whole devops thing and I’d consider systemd to be a professional tool with pretty advanced features. My team deploys and operates Kubernetes across tens of thousands of VMs (using our own images, not managed node pools), and all those nodes are using systemd as the foundational service manager.
Shepherd just seems to be another implementation of service management that’s centered around the use of GNU Scheme. I think it’s neat, and it’s far more flexible than systemd units. Flexibility is good, but to much flexibility also lets you build your own footguns. I have no idea if Shepherd lets you build a gun to blow your foot off, so this may not be a concern at all. Scheme is a really powerful language that I know nothing about, so I’m going to assume that the GNU folks are using language features (or the runtime itself) to prevent accidental amputation. The example service looks almost entirely declarative which gives me warm fuzzies.
As an example of something too flexible, just look at old sysvinit scripts. You could do literally anything you wanted because you were just writing Bash. Bash is already the shittiest language in existence and service management is hard, so there were a lot of terribly broken init scripts out there (which is why systemd was created).
From an aesthetic perspective, I do kinda hate Scheme (and the example service by extension). My eyes just do not want to read it, but that’s a personal failing. Many folks love Scheme and lispy languages.
EDIT: I used “Scheme” a lot, but to be technically correct, I should have been saying Guile. It’s GNU’s implementation of Scheme with some nice extensions.
Yeah I didn’t mean to imply systemd wasn’t suitable for professional use, rather that shepherd is only going to be used by people who want to set this up themselves programmatically.
Like how the average computer user is never going to use Nix to install Firefox or whatever.
Like how the average computer user is never going to […] install Firefox or whatever.
Not right know but in 2005-2010 (or something like that), the average user was installing firefox because IE was so bad. It used to be at 80% market share IIRC.
I could see it being nice for software appliances. I spent many years working for a company that made an appliance (run this OVA/stick this pre-imaged box on your network), and they had this godawful mess of perl they used to orchestrate the box (e.g. updating a configuration file from the GUI and then restarting the sysvinit (and later systemd) service). I could see someone writing a system orchestrator in Guile that, rather than shelling out to systemctl, imports (or whatever it’s called in Scheme) the service definition and directly starts the service using a function call, complete with error handling and all of the nice shit that you don’t get by execing some binary.
libsystemd exists for systemd which lets you have some of the same benefits, but it’s a C library which doesn’t integrate nicely with all languages. I remember not liking any of the Python wrappers I tried, even though Python generally does a great job interfacing with C.
This comment demonstrates a misunderstanding of
shepherdandguix. Using an actual programming language vs some bastardized version of a markup language to describe complex configurations is increasingly popular because it is better.guixis inspired bynixand allows you to specify the entire system as code in a reproducible manner - which you don’t want to do in ‘human readable’toml+,yaml+, etc. because it fucking sucks.You can use
schemeto abstract awayschemelol. These are advanced tools for advanced systems.*I use
systemdall the time, but a direct comparison betweensystemdandshepherdwithout additional context is misleading and flawed.Ah right so sherperd is designed for developers and professional sysadmins, and systemd is something that “normal” users (e.g. Ubuntu users) might use?
I’m a developer who does the whole devops thing and I’d consider systemd to be a professional tool with pretty advanced features. My team deploys and operates Kubernetes across tens of thousands of VMs (using our own images, not managed node pools), and all those nodes are using systemd as the foundational service manager.
Shepherd just seems to be another implementation of service management that’s centered around the use of GNU Scheme. I think it’s neat, and it’s far more flexible than systemd units. Flexibility is good, but to much flexibility also lets you build your own footguns. I have no idea if Shepherd lets you build a gun to blow your foot off, so this may not be a concern at all. Scheme is a really powerful language that I know nothing about, so I’m going to assume that the GNU folks are using language features (or the runtime itself) to prevent accidental amputation. The example service looks almost entirely declarative which gives me warm fuzzies.
As an example of something too flexible, just look at old sysvinit scripts. You could do literally anything you wanted because you were just writing Bash. Bash is already the shittiest language in existence and service management is hard, so there were a lot of terribly broken init scripts out there (which is why systemd was created).
From an aesthetic perspective, I do kinda hate Scheme (and the example service by extension). My eyes just do not want to read it, but that’s a personal failing. Many folks love Scheme and lispy languages.
EDIT: I used “Scheme” a lot, but to be technically correct, I should have been saying Guile. It’s GNU’s implementation of Scheme with some nice extensions.
Yeah I didn’t mean to imply systemd wasn’t suitable for professional use, rather that shepherd is only going to be used by people who want to set this up themselves programmatically.
Like how the average computer user is never going to use Nix to install Firefox or whatever.
Not right know but in 2005-2010 (or something like that), the average user was installing firefox because IE was so bad. It used to be at 80% market share IIRC.
I could see it being nice for software appliances. I spent many years working for a company that made an appliance (run this OVA/stick this pre-imaged box on your network), and they had this godawful mess of perl they used to orchestrate the box (e.g. updating a configuration file from the GUI and then restarting the sysvinit (and later systemd) service). I could see someone writing a system orchestrator in Guile that, rather than shelling out to
systemctl, imports (or whatever it’s called in Scheme) the service definition and directly starts the service using a function call, complete with error handling and all of the nice shit that you don’t get byexecing some binary.libsystemdexists for systemd which lets you have some of the same benefits, but it’s a C library which doesn’t integrate nicely with all languages. I remember not liking any of the Python wrappers I tried, even though Python generally does a great job interfacing with C.