this post was submitted on 10 Dec 2024
62 points (97.0% liked)

Linux

5491 readers
564 users here now

A community for everything relating to the linux operating system

Also check out !linux_memes@programming.dev

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS
top 19 comments
sorted by: hot top controversial new old
[–] infeeeee@lemm.ee 41 points 1 week ago* (last edited 1 week ago) (5 children)

They have an example service on the website:

(define sshd
  (service
    '(sshd ssh-daemon)                ;the secure shell daemon
    #:start (make-inetd-constructor   ;start on demand
             '("/usr/sbin/sshd" "-D" "-i")
             (list (endpoint
                    (make-socket-address AF_INET INADDR_ANY 22))
                   (endpoint
                    (make-socket-address AF_INET6 IN6ADDR_ANY 22)))
             #:max-connections 10)
    #:stop (make-inetd-destructor)
    #:respawn? #t))

(register-services (list sshd))
(start-in-the-background '(sshd))

Let's see how the same service looks like with systemd:

[Unit]
Description=OpenSSH Daemon
Wants=sshdgenkeys.service
After=sshdgenkeys.service
After=network.target

[Service]
Type=notify-reload
ExecStart=/usr/bin/sshd -D
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target

I have some lisp knowledge, so the scheme version doesn't look frightening to me, but I guess for sysadmins, who should write these kind of files frequently systemd's TOML like language is much more easier to understand.

Some differences I see: Shepherd does some firewall management with ports, and I don't see the services it depends on.

Why this kind of files should be written in a programming language at all? I guess it's a remnant from the old times, but I like when tools abstract away the programming parts, and users shouldn't have to deal with that. I like the same thing in docker-compose: I can configure a program whatever language it's written, I don't have to deal with what's happening under the hood.

I guess there is some usefulness with defining services as code, if you need more complex situations, but it should the more rare case nowadays.

[–] deadcream@sopuli.xyz 17 points 1 week ago* (last edited 1 week ago) (2 children)

Some differences I see: Shepherd does some firewall management with ports, and I don't see the services it depends on.

That looks like it sets up sshd to start when someone connect to its port, not on boot. You can do the same with systemd, but you need additional .socket unit that will configure how .service unit is activated.

Why this kind of files should be written in a programming language at all? I guess it's a remnant from the old times, but I like when tools abstract away the programming parts, and users shouldn't have to deal with that

Systemd invents its own configuration language (it looks like ini but there no standard for that and systemd's flavor is its own) so you still need to learn it.

[–] infeeeee@lemm.ee 14 points 1 week ago* (last edited 1 week ago)

Systemd invents its own configuration language (it looks like ini but there no standard for that and systemd’s flavor is its own) so you still need to learn it.

Yeah, but it's much more straightforward and less exotic than scheme. But I guess this type of configuration fits perfectly in Guix, where everything is already configured similarly.

[–] JustEnoughDucks@feddit.nl 4 points 1 week ago* (last edited 1 week ago)

Yes but as a somewhat layperson (electronics engineer and light firmware design, and some hobby sysadmin stuff), I can learn systemd's "language" in 30 minutes and most attributes are so self evident that you can puzzle them together without learning the language at all.

That Shepherd mess I would have no idea what to change to make a small tweak without spending hours and hours learning it because it is written extremely cryptically in comparison.

It's the difference between modifying a config with human readable names and having to go into the source code to change heavily abbreviated variables that require a lot of background knowledge to even read.

[–] devfuuu@lemmy.world 11 points 1 week ago* (last edited 1 week ago) (1 children)

For as much as I want to like and learn guix, guile and all that stuff, it's very very ugly and confusing. I even have a book around for scheme and the parentheses and ' and # in a bunch of places scare me too much and make no sense.

It's a system and language that doesn't work well with more basic editors and tooling and unfortunately for how cool it is I don't guess it will ever catch on for multiple reasons.

[–] infeeeee@lemm.ee 7 points 1 week ago* (last edited 1 week ago)

Scheme is just lisp with blackjack and hookers. It has some huge advantages, that's why it's called God's own programming language

It's older than C, that's why it doesn't have C-like syntax like otger common languages

[–] vividspecter@lemm.ee 4 points 1 week ago

I have some lisp knowledge, so the scheme version doesn’t look frightening to me, but I guess for sysadmins, who should write these kind of files frequently systemd’s TOML like language is much more easier to understand.

People who only know C-style languages tend to struggle with anything that deviates from that too (which is a lot of developers). The Shepard example looks readable to me, but then I'm a Emacs user and have learned a few languages with "weird" syntax so something that looks a bit different is fine.

Why this kind of files should be written in a programming language at all? I guess it’s a remnant from the old times, but I like when tools abstract away the programming parts, and users shouldn’t have to deal with that

It's user base is akin to the NixOS audience. It's more aimed at advanced users and sysadmins (with some programming ability) that want to configure their whole system declaratively. Using a real programming language gives a lot of power and flexibility to achieve this that you'd effectively have to create a new language to replicate that (I.e. Nix or Guile).

On the other hand, something like Shepard is potentially overkill for even Nix and Guix. Nix works quite well as a layer on top of systemd to declare a NixOS system, and still gives you enough power to do most things.

[–] TunaCowboy@lemmy.world 2 points 1 week ago* (last edited 1 week ago) (1 children)

a remnant from the old times

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.

[–] FizzyOrange@programming.dev 3 points 1 week ago* (last edited 1 week ago) (1 children)

Ah right so sherperd is designed for developers and professional sysadmins, and systemd is something that "normal" users (e.g. Ubuntu users) might use?

[–] Badabinski@kbin.earth 6 points 1 week ago (1 children)

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.

[–] FizzyOrange@programming.dev 5 points 1 week ago (2 children)

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.

[–] Badabinski@kbin.earth 5 points 1 week ago

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.

[–] robinm@programming.dev 1 points 1 week ago

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.

[–] possiblylinux127@lemmy.zip -1 points 1 week ago

Leave it to the community to do something in Lisp. That language should've died 20 years ago.

[–] vividspecter@lemm.ee 16 points 1 week ago

And from GNU: https://www.gnu.org/software/shepherd/

To be clear, this is mainly intended to be used with Guix which is a package manager and OS akin to NixOS but written in Guile Scheme.

[–] GolfNovemberUniform@infosec.pub 1 points 1 week ago (1 children)

How is it different to runit or openrc?

[–] DarkMetatron 4 points 1 week ago (1 children)

It has a different name and is written in Guile

[–] GolfNovemberUniform@infosec.pub 3 points 1 week ago (1 children)

Ok so it's basically a yet another point of fragmentation. Nice.