Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Shepherd 1.0.0 released

guix.gnu.org

Post reply on HN
Print view View original

31–40 of 58 posts

Re: The Shepherd 1.0.0 released

#31

Post by yencabulator »

uludag wrote: post #7
danudey wrote: post #2

Taking a quick look at this, the first thing I notice is that the configuration file syntax is obtuse and nigh-illegible unless you already know what things are, and even then it's cumbersome and looks frustrating to write. e.g. instead of systemd's simple: Exec=/path/to/ntpd -n -c /etc/ntpd.conf -u ntpd -g We have this mess: #:start (make-forkexec-constructor (list "…/bin/ntpd" "-n" "-c" "/…/…-ntpd.conf" "-u" "ntpd"…

I think this may be just due to unfamiliarity. Like, if that mess you shared was written as follows: { start: makeForkexecConstructor(["…/bin/ntpd", "-n", "-c", "/…/…-ntpd.conf", "-u", "ntpd", "-g"]), logFile: "/var/log/ntpd.log" } this wouldn't bat an eye. Even though I've never used Guile, just familiarity with Elisp makes that example pretty straightforward. Lisp-adjacent people would all pretty quickly grok this…

I would definitely bat an eye at "make fork exec constructor", regardless of what syntax sugar you sprinkle on that abomination.

Re: The Shepherd 1.0.0 released

#32

Post by tmtvl »

davexunit wrote: post #16

Shepherd is a wonderful little service manager. The project has been integrating the good features of systemd (socket activation, timers, etc.) while retaining the hackability of using a fully featured programming language for configuration. Been happily using it with Guix for over a decade! NLnet has funded a really cool project to turn Shepherd into a distributed system that enables a fleet of Shepherds to cooperat…

Eh, I'd say systemd still has far better dmcrypt support. The bad (I used to think it was terrible, but I tried installing Debian today, which lowered the bar even further) support for full-disk encryption is what keeps me off Guix, as a matter of fact.

Re: The Shepherd 1.0.0 released

#33

Post by choobacker »

danudey wrote: post #2

Taking a quick look at this, the first thing I notice is that the configuration file syntax is obtuse and nigh-illegible unless you already know what things are, and even then it's cumbersome and looks frustrating to write. e.g. instead of systemd's simple: Exec=/path/to/ntpd -n -c /etc/ntpd.conf -u ntpd -g We have this mess: #:start (make-forkexec-constructor (list "…/bin/ntpd" "-n" "-c" "/…/…-ntpd.conf" "-u" "ntpd"…

I agree systemd's is easier to understand, and I'm a happy systemd user.

But some of Shepherd's strengths are in other examples, and it makes sense to evaluate the whole.

A few examples:

* if we want multiple similar services, I'd prefer writing a Guile function than using systemd templates.

* the above Shepherd guile code lives lexically alongside your wider Guix guile code. AST-aware syntax highlighting and refactoring tools would treat them the same. That's pretty neat and beats having two different languages. Guix calls this g-expressions.

This "one language for all your system" is pretty compelling, but Guix's feature set is a bit too far behind NixOS at the moment for me.

Re: The Shepherd 1.0.0 released

#34

Post by davexunit »

tmtvl wrote: post #32
davexunit wrote: post #16

Shepherd is a wonderful little service manager. The project has been integrating the good features of systemd (socket activation, timers, etc.) while retaining the hackability of using a fully featured programming language for configuration. Been happily using it with Guix for over a decade! NLnet has funded a really cool project to turn Shepherd into a distributed system that enables a fleet of Shepherds to cooperat…

Eh, I'd say systemd still has far better dmcrypt support. The bad (I used to think it was terrible, but I tried installing Debian today, which lowered the bar even further) support for full-disk encryption is what keeps me off Guix, as a matter of fact.

okay

Re: The Shepherd 1.0.0 released

#35

Post by zamalek »

danudey wrote: post #2

Taking a quick look at this, the first thing I notice is that the configuration file syntax is obtuse and nigh-illegible unless you already know what things are, and even then it's cumbersome and looks frustrating to write. e.g. instead of systemd's simple: Exec=/path/to/ntpd -n -c /etc/ntpd.conf -u ntpd -g We have this mess: #:start (make-forkexec-constructor (list "…/bin/ntpd" "-n" "-c" "/…/…-ntpd.conf" "-u" "ntpd"…

> NIH syndrome

I would be using nonGuix if it booted on my machine (libre seemingly has its claws too deep), instead of Nix, precisely because Guix has far less NIH: Nix is homegrown everything. Guile was a pre-existing project (for both Guix and The Shepherd), for a pre-existing language family.

Re: The Shepherd 1.0.0 released

#36

Post by ebilgenius »

uludag wrote: post #7
danudey wrote: post #2

Taking a quick look at this, the first thing I notice is that the configuration file syntax is obtuse and nigh-illegible unless you already know what things are, and even then it's cumbersome and looks frustrating to write. e.g. instead of systemd's simple: Exec=/path/to/ntpd -n -c /etc/ntpd.conf -u ntpd -g We have this mess: #:start (make-forkexec-constructor (list "…/bin/ntpd" "-n" "-c" "/…/…-ntpd.conf" "-u" "ntpd"…

I think this may be just due to unfamiliarity. Like, if that mess you shared was written as follows: { start: makeForkexecConstructor(["…/bin/ntpd", "-n", "-c", "/…/…-ntpd.conf", "-u", "ntpd", "-g"]), logFile: "/var/log/ntpd.log" } this wouldn't bat an eye. Even though I've never used Guile, just familiarity with Elisp makes that example pretty straightforward. Lisp-adjacent people would all pretty quickly grok this…

While I agree it's hard to claim one is outright better than the other and there are a lot of factors that go into it, I do feel it's important to toss my chip in as someone who's not familiar with Lisp, Scheme, or any other functional language that I find it's syntax and layout particularly difficult to parse, let alone get started with compared to say, the INI-inspired systemd conf files. I can detail why but the mere fact that I'd have to learn an entire functional programming language (no matter how "easy/simple" it's claimed to be) to be able to competently edit a service file is a huge immediate turn-off for me.

Re: The Shepherd 1.0.0 released

#37

Post by pkkm »

kstrauser wrote: post #13
baq wrote: post #9

Earlier quoted context omitted.

Guile has been the scripting language of choice for GNU before the Internet was called Internet. It hasn't even been disliked, it's been simply ignored, for the most part.

I know that's true, having heard it talked about a lot over the years. But why, though? What is it about Guile that made GNU pick it over CL or Scheme (or TCL or Lua or...)? NM, answered my own question. It’s literally Scheme.

> TCL

I actually know the answer to that one!

> The principal lesson of Emacs is that a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that!

> Another lesson from Emacs is that the way to make sure an extension facility is really flexible is to use it to write a large portion of the ordinary released system. If you try to do that with Tcl, you will encounter its limitations.

> Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow.

From Why you should not use Tcl by Richard Stallman [1].

[1] https://vanderburg.org/old_pages/Tcl/war/0000.html

Re: The Shepherd 1.0.0 released

#38

Post by worik »

davexunit wrote: post #16

Shepherd is a wonderful little service manager. The project has been integrating the good features of systemd (socket activation, timers, etc.) while retaining the hackability of using a fully featured programming language for configuration. Been happily using it with Guix for over a decade! NLnet has funded a really cool project to turn Shepherd into a distributed system that enables a fleet of Shepherds to cooperat…

> Shepherd is a wonderful little service manager

I believe you

But what practical use is it?

I cannot tell.

Re: The Shepherd 1.0.0 released

#39

Post by doublerabbit »

worik wrote: post #38
davexunit wrote: post #16

Shepherd is a wonderful little service manager. The project has been integrating the good features of systemd (socket activation, timers, etc.) while retaining the hackability of using a fully featured programming language for configuration. Been happily using it with Guix for over a decade! NLnet has funded a really cool project to turn Shepherd into a distributed system that enables a fleet of Shepherds to cooperat…

> Shepherd is a wonderful little service manager I believe you But what practical use is it? I cannot tell.

> practical use

service manager.

Where by you can create a service of your own application in userland without needing to be PID 1 to execute the service. With all the bells and whistles of monitoring and trigger.

Re: The Shepherd 1.0.0 released

#40

Post by kstrauser »

pkkm wrote: post #37
kstrauser wrote: post #13

Earlier quoted context omitted.

I know that's true, having heard it talked about a lot over the years. But why, though? What is it about Guile that made GNU pick it over CL or Scheme (or TCL or Lua or...)? NM, answered my own question. It’s literally Scheme.

> TCL I actually know the answer to that one! > The principal lesson of Emacs is that a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that! > Another lesson from Emacs is that the way to make sure an extension facility is really flexible is to use it to write a large…

Brilliant. That's exactly the kind of information I was missing. I don't know enough about Tcl to opine on whether he was right, but if that's what RMS thought about it, I can see why he'd push back hard against it..
Post reply on HN