Recherches récentes
Options de recherche
@postroutine Two thoughts:
- For me, one main selling point of #guix is that it doesn't use systemd.
- A user space program /requiring/ systemd seems like a broken concept.
@postroutine I don't think so but it has elogind
@postroutine And you should be able to start containers automatically using Guix's services
My main needs are:
- An init System quick to start the whole system
- Can manage system dependencies, including network and FS mount
- Can manage socket and start a service when receive communication on service socket
- System and users services
- Easy to use and declare new units (services, FS mount, etc)
- Quadlet compatibility
And if I can start a service by pointinq to a Systemd unit config file I was provided by the software dev, without the need to rewrite it, is a welcome bonus.
Sometime, when want to run a service in a container and I don't have time, I start the service systemd unit inside the podman container. Podman is made to allow that and it's time saving. But I don't know if it's need systemd outside of the container.
AFAIK, Guix has its own init system, called GNU Sheperd.
@alexshendi @postroutine this does not mean systemd could not be used to run services on top of sheperd 
This is true, and I think with the new work to introduce shepherd@1 the potential ability to be able to configure an alternative PID1 is much diminished, sadly. #guix
@khleedril Was it ever a realistic option? I haven't seen any appetite for alternate init systems in Guix. I don't think the recent Shepherd releases have changed that.
@carlozancanaro @khleedril I think it's important to distinguish #Guix and #GuixSystem. Guix doesn't care what PID 1 is; Guix System will run Shepherd as the init process, though in my experience the dependency isn't really fundamental. My computers run Guix System with an (operating-system ...) without Shepherd services, see https://rentry.co/mnuo4fp6 -- it points to an initrd running a tiny busybox shell script to decrypt and mount the root filesystem and exec minit, https://codeberg.org/gtw/minit
@carlozancanaro @khleedril I suppose that was a long winded way of agreeing with you 
You're right, I don't see much "appetite" for alternative init systems. (I don't see much preventing users who want them from specifying them, either.)
@gtw @khleedril That's pretty neat!
Yeah, I considered saying something about how the Guix operating-system is actually really flexible, and it's just that the default in the upstream operating system is to use the Shepherd. It's technically possible to replace the Shepherd with systemd in your operating-system definition, but then you also need to write service extensions which extend that, etc.
Nothing in Guix prevents you from doing that, but it would be a pretty fundamental shift, so it's a fair bit of work to create a whole distribution for a different init system.
Your example obviously shows this to be true: that's exactly what you're doing. I haven't actually seen it done before, so this is pretty cool. It's easy to see how this could lead to a whole system with a different PID1, but without people doing the work it's more of a curiosity than a realistic prospect.
The lack of appetite for this upstream also means that you're effectively creating a whole different distribution on top of Guix. One nice thing about Guix is that this doesn't need to be a fork, it can be parallel to the existing Guix system by replacing the right internal services.
This is too many words to basically say: what you've done is cool! I love that Guix makes it relatively straightforward.
@gtw @carlozancanaro This is interesting. You say you run without shepherd services, but how do you actually turn the shepherd daemon off? There is no clause in (operating-system ...) that says to use or not to use shepherd?
@khleedril There's nothing special about the Shepherd service. shepherd-root-service-type is defined in the same way as all the other service types, and it just extends boot-service-type to start the Shepherd as PID1 (see gnu/services/shepherd.scm for its definition). It's part of the default value of operating-system's essential-services field, but you can change that by providing an explicit value to your operating-system definition.
If you look at @gtw's paste from earlier (https://rentry.co/mnuo4fp6), you can see that this operating-system definition specifies essential-services, and does not include the shepherd-root-service-type. That means a system built from this definition will not have PID1 be the Shepherd. While this is unusual it doesn't fundamentally break Guix, it just removes the pieces that a bunch of other services rely on so you can't use those services.
@khleedril Yes, exactly what @carlozancanaro wrote! I see the documentation https://guix.gnu.org/manual/en/html_node/operating_002dsystem-Reference.html warns "As a user you should NEVER need to touch this field", which makes sense, since deleting the Shepherd service without providing substitutes for the vital things it does would leave the system booting into an unusable state. But it can be made to work.
@carlozancanaro @khleedril For a user wanting both Guix and systemd, I can imagine two main approaches: 1) start with a foreign distro already running systemd (NixOS would be an interesting choice), install Guix on top, and never actually introduce Guix System.
Or...
@carlozancanaro @khleedril 2) Install Guix System, then modify (operating-system ...) to remove Shepherd from (essential-services ...) and add a custom systemd replacement. I think this should be feasible, although a lot of work. I imagine the hardest parts would be writing systemd replacements for all the normal Shepherd (operating-system (services ...)) entries, and having to make nuanced choices about where systemd starts and (services ...) ends.