:: Re: [DNG] The Shepherd 1.0.0 releas…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Steve Litt
Fecha:  
A: dng
Asunto: Re: [DNG] The Shepherd 1.0.0 released
viverna via Dng said on Wed, 18 Dec 2024 20:58:37 +0100

>It's a bit old news but i have read this today:
>https://www.gnu.org/software/shepherd/news/2024/12/the-shepherd-1.0.0-released/
>I known it being made in Guile and the configuration seems declarative
>(epoch and systemd style), but i have never used it.
>Has anyone in this list tried it to know how it works?
>Thanks in advance.


I know enough about Guile to know it's a tough language.

It's been in the making for 21 years, making its inception year 2003 or
2004. IIRC this is about the same time DJB created the spectacular
Daemontools, and a few years later than (urk) upstart. If they'd come
out with Shepherd in, let's say 2006, it would have been simpler than
upstart and would have had the ordered bootup that Daemontools lacked.
It would have been a contender.

But somewhere around 2014 Daemontools was extended (independently) to
s6 and runit, both of which proved ordered startup unnecessary if you
simply put test dependencies in the (mercifully short) startup scripts,
and both s6 and runit could assume PID1 duties. In the past couple
years, s6 came out with some addons that made ordered start a reality.
And actually, before Covid I came out with Littkit, a set of
shellscripts that could facilitate ordered startup on Daemontools, s6
and runit, although Littkit needed a little modification to accommodate
the different commands of those three inits.

So here comes Shepherd, 10 years after runit and s6 and 20 years after
Daemontools, with something more complex and harder for most users to
work with, because Guile's a lot harder than sh or ksh. And did you
take a look at that dependency graph on the referenced page? Ho dam,
that borders on poetterism.

If Shepherd had achieved stability in 2006, I would have learned more
Guile and sung Shepherd's praises forever. But coming out in 2024, it's
solving problems already solved ten years ago. Too little too late.

SteveT

Steve Litt

http://444domains.com