I have completed an initial new port of systemd to musl. This patch set does not share much in common with the existing OpenEmbedded patchset. I wanted to make a fully updated patch series targetin…

I have completed an initial new port of systemd to musl. This patch set does not share much in common with the existing OpenEmbedded patchset. I wanted to make a fully updated patch series targeting more current releases of systemd and musl, taking advantage of the latest features and updates in both. I also took a focus on writing patches that could be sent for consideration of inclusion upstream.

The final result is a system that appears to be surprisingly reliable considering the newness of the port, and very fast to boot.

…

And that is how I became the first person alive to see systemd passing its entire test suite on a big-endian 64-bit PowerPC musl libc system.

…

While the system works really well, and boots in 1/3rd the time of OpenRC on the same system, it isn’t ready for prime time just yet.

…

There aren’t any service unit files written or packaged yet, other than OpenSSH and utmps. We are working with our sponsor on an effort to add -systemd split packages to any of the packages with -openrc splits. We should be able to rely on upstream units where present, and lean on Gentoo and Fedora’s systemd experts to have good base files to reference when needed. I’ve already landed support for this in abuild.

This work is part of Adélie Linux

  • markstos@lemmy.world
    51·
    4 months ago

    If I need systemd for a specific use, like testing systemd services, that’s essential, not bloat.

    • corsicanguppy@lemmy.caEnglish
      3·
      4 months ago

      If I need systemd for a specific use, like testing systemd services

      So you’re hoping to test systemd in this theoretical test environment, but your prod isn’t built like this? Tell us why you’re ignoring the first rule of testing and deploying internal software?