systemd has many options to reduce the privileges of a service: like running as a normal user with only certain POSIX capabilities, setting up a mount namespace with a limited view of the root filesystem, locking down which system calls can be invoked, etc.
GNU Shepherd itself doesn't implement sandboxing, but you can use the least-authority-wrapper to do namespaces. There are other tools to do more comphrensive sandboxing, which Shepherd can use, e.g. nsjail.
Shepherd doesn't include this as it is quite lean and extensible (service start/stop hooks are functions that can do anything) but Guix includes a Linux container implementation and an abstraction built on top for use by services. The long term vision is to use an object capability security model so, rather than "locking down", a service can only interact with the resources to which it has been passed a reference. No ambient authority, no confused deputies.
I really like systemd but am also Guix-curious. This sandboxing topic has been a bit of a blocker for me to properly go deeper with Guix. Do you know of any good places to read more about this vision? Sounds powerful and unique.
For day to day use, what are the benefits for gnu guix? From it’s website, what I could understand is it provides installation of different version of the same package, similar to rbenv or conda. Apart from this, is there anything else that will be considered useful over something like aptitude?
From a quick glance, Guix seems to have a similar learning curve as Nix (at least it's based on Scheme, which I know). Is that impression correct? Anyway, I didn't find this “intuitively comprehensible” as an outsider.
Guix is a reimagining of the concepts of Nix with Guile/Scheme instead of the Nix language, so they are very similar in overall feel, but differ in the details (e.g. GNU Shepherd vs systemd).
As for learning curve, I find Nix substantially easier, since the language is much simpler (JSON-like with lazy-functions) and doesn't need all that weirdness that result from using Scheme as configuration language (lots of quoting, module system, etc.)
As someone who has tried both, I found the learning curve for Guix much more pleasant than for Nix. With Nix, the community is for sure a lot larger, and more things are available (notably it is a lot faster, too). But I could never get everything clear in my head, how it hangs together, and the community seemed very much more fragmented than with Guix. I think the Guix documentation and manual, as well as the CLI and secondary docs written in people's blogs, were much easier to get a handle on than with Nix. Flakes are a great example, I still have no idea what a flake is, they are still an experimental feature, and I have no idea how I should think about them. I've been using NixOS full time for 3 years by the way.
I also think the shepherd alone is almost a killer app relative to something like systemd. I had to write a service myself for restarting ssh tunnels, and I could even do "advanced" things like templated configuration, almost trivially. It felt like a superpower, relative to systemd services.
I don't think it's possible to just "wing it" by copy-and-paste.
2.
I did not understand the introductory paragraph about how services "extend" each other. Does every service have hooks for possible extensions? What if a new service doesn't fit existing extension hooks?
(I can understand service dependencies of course, but it seems to go beyond that.)
This is less flexible-by-default than NixOS module, where any module can modify any other module. That is by design. The Guix developers see NixOS's approach as failing the principle-of-least-authority, where any arbitrary module (even those imported via flakes) can add a root SSH key.
Does GNU Shepherd support some form of sanboxing?
systemd has many options to reduce the privileges of a service: like running as a normal user with only certain POSIX capabilities, setting up a mount namespace with a limited view of the root filesystem, locking down which system calls can be invoked, etc.
GNU Shepherd itself doesn't implement sandboxing, but you can use the least-authority-wrapper to do namespaces. There are other tools to do more comphrensive sandboxing, which Shepherd can use, e.g. nsjail.
least-authority-wrapper: https://codeberg.org/guix/guix/src/commit/e3fbaeee1386fd447f...
Uoh, nsjail ha? The namespace for project names seems exhausted. No germans on the dev team, ey?
https://github.com/google/nsjail
What is the problematic connotation for 'nsjail' in German?
Shepherd doesn't include this as it is quite lean and extensible (service start/stop hooks are functions that can do anything) but Guix includes a Linux container implementation and an abstraction built on top for use by services. The long term vision is to use an object capability security model so, rather than "locking down", a service can only interact with the resources to which it has been passed a reference. No ambient authority, no confused deputies.
I really like systemd but am also Guix-curious. This sandboxing topic has been a bit of a blocker for me to properly go deeper with Guix. Do you know of any good places to read more about this vision? Sounds powerful and unique.
https://fosdem.org/2025/schedule/event/fosdem-2025-5315-shep...
For day to day use, what are the benefits for gnu guix? From it’s website, what I could understand is it provides installation of different version of the same package, similar to rbenv or conda. Apart from this, is there anything else that will be considered useful over something like aptitude?
Reproducibility, just like Nix.
You can be certain that, if you've managed to get a piece of software running with Guix, you can also get it running identically on any other machine.
Except if nvidia cards and embedded systems are involved. Then whether you get it running is still a gamble.
From a quick glance, Guix seems to have a similar learning curve as Nix (at least it's based on Scheme, which I know). Is that impression correct? Anyway, I didn't find this “intuitively comprehensible” as an outsider.
Guix is a reimagining of the concepts of Nix with Guile/Scheme instead of the Nix language, so they are very similar in overall feel, but differ in the details (e.g. GNU Shepherd vs systemd).
As for learning curve, I find Nix substantially easier, since the language is much simpler (JSON-like with lazy-functions) and doesn't need all that weirdness that result from using Scheme as configuration language (lots of quoting, module system, etc.)
Correct, and it's Linux-only and more hardcore FOSS (i .e. they don't have any blessed way to use non-free software).
I'm not sure why it's being sold as an alternative to Nix/NixOS
If you regard it as an alternative to NixOS rather than Nix the package manager then both are Linux.
Some people want FOSS only, some people dislike systemd, some people like Scheme....
Because it's an alternative which guarantees freedom?
just not freedom to use propriety software
Only Free Software guarantees that you have the final say in a matter of using arbitrary proprietary software.
It's easy to use proprietary software with Guix and nearly all users do this.
Cool, I didn't realize I could use it on my Windows or Mac machines. That's actually what's been holding me back.
As someone who has tried both, I found the learning curve for Guix much more pleasant than for Nix. With Nix, the community is for sure a lot larger, and more things are available (notably it is a lot faster, too). But I could never get everything clear in my head, how it hangs together, and the community seemed very much more fragmented than with Guix. I think the Guix documentation and manual, as well as the CLI and secondary docs written in people's blogs, were much easier to get a handle on than with Nix. Flakes are a great example, I still have no idea what a flake is, they are still an experimental feature, and I have no idea how I should think about them. I've been using NixOS full time for 3 years by the way.
I also think the shepherd alone is almost a killer app relative to something like systemd. I had to write a service myself for restarting ssh tunnels, and I could even do "advanced" things like templated configuration, almost trivially. It felt like a superpower, relative to systemd services.
Two notes from reading the first several paragraphs:
1. It seems one needs to know some Scheme in order to write these files:
https://www.scheme.org/
I don't think it's possible to just "wing it" by copy-and-paste.
2. I did not understand the introductory paragraph about how services "extend" each other. Does every service have hooks for possible extensions? What if a new service doesn't fit existing extension hooks?
(I can understand service dependencies of course, but it seems to go beyond that.)
> Does every service have hooks for possible extensions? What if a new service doesn't fit existing extension hooks?
No, only few services define service extensions.
It's more common for services to be configured solely via their configuration struct.
See the following for docs:
* https://guix.gnu.org/manual/en/html_node/Service-Composition...
* https://guix.gnu.org/manual/en/html_node/Service-Types-and-S...
This is less flexible-by-default than NixOS module, where any module can modify any other module. That is by design. The Guix developers see NixOS's approach as failing the principle-of-least-authority, where any arbitrary module (even those imported via flakes) can add a root SSH key.
I use NixOS, but it's an interesting tradeoff.