
GNU Shepherd 0.5.0 released - ymse
https://lists.gnu.org/archive/html/guix-devel/2018-09/msg00282.html
======
peatmoss
Man, I’ve really wanted to take the plunge and dedicate some play time to GUIX
for a while now. I feel like between the GUIX package system and Shepherd,
they’re creating an authentically new and exciting thing in the universe of
Linux distributions.

The fact that they’re using Scheme for so much of it is also pretty cool, as I
think this sort of high level systems programming is a great potential use
case for showcasing meta programming as well as the unique power of lisps for
code-as-data.

~~~
rufugee
Same here...as a NixOS user, I really wish it used scheme instead of the nix
language.

However, I do like the pragmatic nature of NixOS (you're able to easily
install non-free packages). GUIX doesn't make this easy at all from what I
understand. I appreciate those virtues, but practically speaking, I have to
use non-free software on the desktop all the time.

~~~
_emacsomancer_
Guix does have the capacity to add 'channels', e.g.
[https://gitlab.com/mbakke/guix-chromium](https://gitlab.com/mbakke/guix-
chromium) , so while non-free software while never be part of the distribution
itself, it could be done unofficially. Also, you can run the Nix standalone on
top of GuixSD, so you could run GuixSD and then use Nix to install whatever's
missing.

~~~
yorwba
> you could run GuixSD and then use Nix to install whatever's missing.

How much cooperation between the two is necessary? If I wanted to install CUDA
drivers with Nix would it "just work" (i.e. if it works on NixOS it works on
GuixSD) or could GuixSD make problems?

I found a comment from a year ago claiming that the kernel wouldn't load
blobs:
[https://news.ycombinator.com/item?id=14630581](https://news.ycombinator.com/item?id=14630581)

~~~
_emacsomancer_
I'm not certain about CUDA drivers and whether this sort of thing work "just
work" via the Nix package manager on GuixSD. That sounds like you might need
to recompile kernel headers or the like.

Re: the comment about the Guix kernel and blobs: Guix uses the linux-libre
kernel which has blobs removed. BUT you can use a custom kernel on Guix, so
you could use a blobby kernel, but you would have to configure it. If you poke
around, you can find examples of people doing this, e.g.:
[https://gist.github.com/TeMPOraL/306bbb7c627ab0d32fa84af8319...](https://gist.github.com/TeMPOraL/306bbb7c627ab0d32fa84af831963563)

But, in general, the standalone Nix package manager (and the standalone Guix
package manager, for that matter) are designed to work as isolated units, not
depending as much on the 'host' system, so lots of stuff does 'just work'
regardless of whether the host distro is GuixSD or Debian or Void or Arch or
whatever.

------
bjoli
For anyone interested in guile, guile 3.0 will have a JIT, making it even
faster than 2.2 (by quite a large margin).

Guile is becoming really nice, and I find myself reaching for other lisps less
and less.

~~~
logicchains
How far along is it towards becoming the underlying runtime for Emacs lisp?

~~~
bjoli
With the bikeshedding we see for much less controversial changes in the Emacs
codebase, I suspect it will be released around the release of Duke Nukem
forever II.

Elisp code runs fine under guile, but it has seen virtually no optimisation
work and does a lot of unnecessary work. I suspect there is an lot of low
hanging fruit, but since there is virtually no interest in guile-emacs apart
from in comments on HN and Reddit I doubt the situation will get much better.

The guile VM is getting better and better though. Maybe they'll come around by
guile 4 :)

~~~
yepguy
I've always thought someone should use guile to add support for elisp plugins
to vim & neovim using their rpc interfaces. Then maybe if something like that
existed the org-mode authors could be convinced to cleanly separate out the
emacs-specific code, and we could have org-mode on vim using the same codebase
as emacs.

I have no idea how viable that is, but it would be pretty sweet. Too much for
me to take on right now, but the idea has been rattling around my brain for a
few years.

------
jonathanstrange
Interesting,after all this criticism of systemd.

This makes me wonder about the GuixSD distribution. Is this distro ready for
prime-time. Suppose I switched from Linux Mint to GuixSD, what would be the
advantages and disadvantages?

I like Lisp and program in Racket, so Guile wouldn't be far from that. I just
wonder about experiences of other. How much does switching to such a lesser
known free distro as the main OS "constrain" you?

~~~
rhabarba
> Suppose I switched from Linux Mint to GuixSD, what would be the advantages
> and disadvantages?

You'd lose a lot of software choices. Actually, the restriction to "GNU-
friendly software" was what made me skip GuixSD so far. I guess that my WiFi
wouldn't work.

~~~
serhart
Not true. You can write your own packages in the same high level interface.
Including the mainline Linux kernel and broadcom drivers. I have GuixSd
running on my 2013 MBP

~~~
noobermin
Is there a...non official repository of these somewhere?

~~~
dreamofkoholint
There are a smattering of code snippets around

This[1] is the one I used as a reference for my kernel build which includes
brcmfmac

There is also a feature called 'channels' (not widely documented AFAIK) which
allows you to describe an outside repository of code you can reference to
install packages. There is one[2] that provides Chromium (though I cannot get
the build to succeed).

The downside to all of these not being provided in mainline is the amount of
time and energy to build them. I suspect there are more people than I would
like curating their build of the linux kernel, manually specifying drivers
included in the kernel. I really wish the community were a little less hard-
set on the principle of 'freedom' and a little more pragmatic; I am sure the
community is smaller due to people being turned away at the sheer amount of
effort required to get their machine to a usable state.

[1]: [https://github.com/wingo/guix-nonfree](https://github.com/wingo/guix-
nonfree) [2]: [https://gitlab.com/mbakke/guix-
chromium](https://gitlab.com/mbakke/guix-chromium)

~~~
noobermin
As someone who is sympathetic to their cause and their stance, I think the
extreme position of excluding all non-free software can actually hamper the
movement by making it less accessible to people. I get you always have to draw
a line somewhere, but FSF draw it too firmly.

~~~
_emacsomancer_
> you always have to draw a line somewhere, but FSF draw it too firmly.

They actually don't draw it exactly where I would. I don't care so much for
games if they're open/free or not (it's nice when they are of course), but I
am concerned with unauditable code on, for instance, the SATA controllers in
my machine, even if it 'read only' code. Where the FSF is more concerned with
the first and less with the second.

On the other topic, I think the ability to create (and share) your own
recipes/channels for software on Guix allows for people to create fairly easy
ways to install non-free software (or using Nix on top of GuixSD) without the
Guix team having to support unethical software.

------
arminiusreturns
This is awesome! I have really been impressed with gnu's use of guile, and I
really like how much more quickly iteration is than many other gnu projects.
For those heavy cron users, mcron (guile based cron replacement) has been my
favorite so far.

With a good deamon manager, we're one step closer to HURD!

------
theamk
Does anyone know if they solved their "trust init script too much" problems?

Last time I checked, they were loading user-defined scripts right into PID 1,
so a badly written script could bring down the whole system.

People blame systemd for pid 1 instability, but at least systemd crashes get
fixed eventually. With Shepherd, any package on the system can cause PID 1 to
crash, and this just seems to crazy for me.

~~~
lfam
Can you give any more detail about this? Or a reference to a bug report or
mailing list thread?

~~~
theamk
The manual [1] starts by saying: "When shepherd gets started, it reads and
evaluates a configuration file." That config is full-featured, seemingly
unrestricted, lisp file. While I saw some mentions of handling syntax errors
on the mailing list, I saw no mentions of what happens if there is an infinite
loop or if a script just reads a huge files and OOM's the process.

Now, one could imagine that maybe configs are parsed in a separate process,
and then serialized and shipped to the main process for safe execution. But it
does not seem to be the case -- the manual explicitly says you can use any
Guile code to start processes, not just a safe subset.

Another option is that maybe there is a thread or a forked process for parsing
config. But this does not seem to be the case either -- the manual does not
mention that, and searching of the source code for "fork" or "thread" or
"timeout" does not seem to indicate anything related.

The only mention of timeness expectation seem to be a single sentence "Actions
are expected to be non-blocking." in one of the mailing lists [2].

So together, it seems to me that any bad script will just cause the daemon,
and by extension the whole system, to not start.

[1]
"[https://www.gnu.org/software/shepherd/manual/shepherd.html#S...](https://www.gnu.org/software/shepherd/manual/shepherd.html#Services")

[2] [http://lists.gnu.org/archive/html/guix-
devel/2016-11/msg0094...](http://lists.gnu.org/archive/html/guix-
devel/2016-11/msg00945.html)

------
tomkat0789
Pardon me, I'm sort of a casual Linux user and I have no idea what people are
talking about. What are GNU Guix and Shepherd? A cursory glance at Wikipedia
makes it seem like they're GNU alternatives to the apt-get and init/systemD
I've been on for awhile.

I'm outside of my Debian comfort zone, apologies for my ignorance! What's
significant about this?

~~~
pjmlp
Basically they follow similar ideas to NixOS, but using Scheme instead of a
custom script language.

------
_emacsomancer_
There's a quote from the GNU Shepherd manual I really appreciated:

> I decided to not make it too sophisticated by trying to guess what the user
> might want just to theoretically fulfill the request we are processing. If
> something goes wrong, it is usually better to tell the user about the
> problem and let her fix it, taking care to make finding solutions or
> workarounds for problems (like a misconfigured service) easy. This way, the
> user is in control of what happens and we can keep the implementation
> simple. To make a long story short, we _don 't try to be too clever_, which
> is usually a good idea in developing software.

------
rhabarba
> The GNU Shepherd is developed jointly with the GNU Guix project

Wasn't it made for the hurd?

~~~
CamTin
Shepherd should run on Hurd, since Guile does, but it was created as part of
the GNU system, which is in reality usually run on the Linux kernel.

