3 ms·

> - it uses GNU Shepherd as the service manager instead of systemd I wish they didn't do this part. Despite the furor that was around systemd, it's actually qu

> - it uses GNU Shepherd as the service manager instead of systemd I wish they didn't do this part. Despite the furor that was around systemd, it's actually quite nice to use day-to-day. But also, I realize that the FSF has to do what the FSF has to do, glad they're around.

rekado 3y ago
The FSF is not involved in the project. The FSF had no say in what service manager we use. A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh?
- hardwaresofton 3y ago
  Apologies, I assumed that being a GNU project (which is supported by the FSF), the project identified as an FSF project. > A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh? I didn't have this misconception, but let me correct my statement: But also, I realize that guix devs have to do what guix devs have to do, glad they're around.
amszmidt 3y ago
GNU Shepherd (was aka DMD) predates systemd by many years. And many other “PID 1” efforts. It also had different goals when Wolfgang and I designed it, one might say even incompatible since we were targeting the GNU/Hurd specifically and wanted easy ways to manage translators there on a per user basis.
- rekado 3y ago
  One thing that hasn't changed, though, is that compatibility with the Hurd is still a major goal. Sadly (but understandably) development pushes forward for Shepherd on Linux and then we aim to make it work on the Hurd, instead of letting Hurd-native facilities guide development. But this might change as there is considerable overlap between Guix contributors and Hurd enthusiasts.

rekado 3y ago

The FSF is not involved in the project. The FSF had no say in what service manager we use. A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh?

hardwaresofton 3y ago
Apologies, I assumed that being a GNU project (which is supported by the FSF), the project identified as an FSF project. > A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh? I didn't have this misconception, but let me correct my statement: But also, I realize that guix devs have to do what guix devs have to do, glad they're around.

amszmidt 3y ago

GNU Shepherd (was aka DMD) predates systemd by many years. And many other “PID 1” efforts. It also had different goals when Wolfgang and I designed it, one might say even incompatible since we were targeting the GNU/Hurd specifically and wanted easy ways to manage translators there on a per user basis.

rekado 3y ago
One thing that hasn't changed, though, is that compatibility with the Hurd is still a major goal. Sadly (but understandably) development pushes forward for Shepherd on Linux and then we aim to make it work on the Hurd, instead of letting Hurd-native facilities guide development. But this might change as there is considerable overlap between Guix contributors and Hurd enthusiasts.