Porting systemd to musl Libc-powered Linux

• > boots in 1/3rd the time of OpenRC on the same system

  Wow, that's a suspiciously impressive difference. I was under the impression that OpenRC and systemd support similar parallel service startup features and usually boot systems in approximately the same amount of time, with maybe a slight edge to systemd. 3x speed makes me wonder if there's something else going on, like the current early systemd port having some bugs that cause it to incorrectly skip some important work.

  Either way, super cool. What's the likelihood that this ends up getting upstreamed?
  -- bhaney Reply

• > I was under the impression that OpenRC and systemd support similar parallel service startup features

  It's not enabled by default in OpenRC because it's not stable.

  > WARNING: whilst we have improved parallel, it can still potentially lock the boot process. Don't file bugs about this unless you can supply patches that fix it without breaking other things!

  https://github.com/OpenRC/openrc/blob/ea310b2e580a25038f9592...
  -- jiripospisil Reply

• I'm amazed projects like that are still active.

  This isn't a case where systemd is ahead of the curve, every other OS also starts services in parallel.
  -- NavinF Reply

• Folks who evangelise these "just as good as systemd" solutions always hide a key factor.

  There is a reason systemd took over, its massively supported and widely tested.
  -- happymellon Reply

• It couldn't be massively supported until it took over, though? It's more than a little platform effect going on, it's not all by virtue of systemd being just all over great. It has some great ideas but it's an entire world unto itself which feels very NIH-ish.

  Edit: I think it serves as both a warning and an inspiration. Don't let a duct tape solution (such as for instance boot via rc shell files) live for too long, or it might be replaced by something baroque.
  -- actionfromafar Reply

• Ideas are just 1% if implementation. Systemd (while being a little problematic in beginning) has had huge amount of amazing work being done in it.
  -- trueismywork Reply
• The improved boot times are likely largely due to systemd's parallelization, OpenRC's support is buggy and OpenRC overall is known to be quite slow.

  Thankfully, there are plenty of other non-systemd inits besides OpenRC :)
  -- DaSHacka Reply

• The inflection point was GNOME 3.8 not working properly with anything other than systemd and it being night impossible to implement compatible alternatives for some of the interfaces involved.
  -- p_l Reply
• Yes, it's massively sponsored as well. So it went heavily imposed almost everywhere even when a quite big chunk of the Linux community deeply disagreed about the imposition.
  -- mrfinn Reply
• It must be something in the air. I find flatpak, appimage, snap etc underwhelming. The go reimplementation¹ of appimage looks promising, but it would be nicer if one could more easily link Linux applications statically.

  Another idea would be to build a "meta-libc", MIT licensed, which exports a glibc compatible interface but called musl or whatever else libc under the hood for implementation. This is slightly complicated by the fact that musl does not export any version define or symbol.

  Or just fork musl and start adding glibc-isms to it...

  1: https://github.com/probonopd/go-appimage
  -- actionfromafar Reply

• I'm with you, if what you're saying is that containerized applications are a cop-out. In the other hand, they have their uses. For example Valve seems to have a hard time packaging Steam (being a weird 32bit web browser with DRM), but their flatpak works nicely, and because it's closed source it's your best option.

  (Also I think it's too kind to include Snap with the others, I find it uniquely objectionable since it's neither convenient nor functional.)
  -- Y_Y Reply