12 ms·

> 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 sup

by bhaney 2y ago

> 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?

frankjr 2y ago
> 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/ea310b2e580a25038f9592da4160d017ebfce3fc/etc/rc.conf#L7 https://github.com/OpenRC/openrc/blob/ea310b2e580a25038f9592...
- NavinF 2y ago
  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.
  - amszmidt 2y ago
    Plenty don’t, e.g. BSDs. Bunch of embedded GNU/Linux systems. Etc.
    - NavinF 2y ago
      I meant OSs that have consumer market share. Eg on people's desktops and phones. Nobody cares about BSDs and a bunch of embedded GNU/Linux systems
      - awilfox 2y ago
        A lot of people care about BSDs and embedded Linux systems. Such as: Netflix (FreeBSD), anyone with a Linux-based router or cable/DSL modem, and so on. That said, parallel startup is possible on those systems too. There was an out-of-tree patch for parallel rc(8) on FreeBSD some time ago, and dinit is parallel, etc. I think OpenRC should move towards making parallel startup stable and supported so that those systems can do that as well.
      - zekica 2y ago
        Almost everyone's router is an embedded Busybox/Musl/Linux system. There are billions of them running every day.
        synergy20 2y ago
        they don't use openrc though
      - btreecat 2y ago
        Alpine has market share. It's just targeting a different market space than what you're measuring.
        mort96 2y ago
        > consumer market share
        marcthe12 2y ago
        Some Alpine linux derivatives are kinda want switch to systemd and hence the porting
      - deleted 2y ago
        [deleted]
      - bee_rider 2y ago
        OpenRC doesn’t have huge consumer market share, at least in the context where this sort of thing matters. For regular Linux desktops, most of the distros use SystemD.
  - bee_rider 2y ago
    It is a simple little startup system with some dedicated users. Open source projects don’t need huge user-counts to justify their existence. It isn’t a profit center, people just do this stuff for fun, because they enjoy tinkering, or maybe they coded it up and decided to just share it out of altruism.
happymellon 2y ago
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.
- actionfromafar 2y ago
  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.
  - trueismywork 2y ago
    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.
    - p_l 2y ago
      Doesn't mean the result is all that good. Having dealt with it for some time now, the amount of "good idea, bad implementation" I hit is too damn high. And it's nigh impossible to replace for various reasons, including at one point critical interfaces that various user-important programs depended on being a constant treadmill of updates, lack of documentation, and hidden dependencies on internals.
      - awilfox 2y ago
        It's true. systemd has a lot of good ideas with questionable implementations. I'd love networkd if it didn't have silly decisions made. And it has some questionable ideas with good implementations. For example, I hate the journal, but admit it is implemented well. At the end of the day, it's about tradeoffs and using what suits the system at hand. For some people that will be systemd, and bringing systemd to Adélie and other musl libc distributions means that it can be used by those people. Call me old-fashioned, but I also hold out hope that at least some of those questionable implementations could be fixed if only someone with the desire would write a patch and send it upstream. Bringing systemd to musl means the people in musl land that aren't knee-jerk anti-systemd maybe might be more enthused to do just that, improving it for everyone using it.
awilfox 2y ago
> Either way, super cool. What's the likelihood that this ends up getting upstreamed? High: <https://github.com/systemd/systemd/pulls?q=is%3Apr+author%3Aawilfox https://github.com/systemd/systemd/pulls?q=is%3Apr+author%3A...>.
- blueflow 2y ago
  Did Lennart change his mind? https://lists.freedesktop.org/archives/systemd-devel/2014-October/023869.html https://lists.freedesktop.org/archives/systemd-devel/2014-Oc...
  - kokada 2y ago
    I don't think Lennart changed his opinion, if you look further in this thread[1] Lenart wasn't ever against musl per se, it is more like "we use non-POSIX features from glibc that we found useful, and we are not going to reinvent them, so either convince musl to implement those features or carry patches fixing the issues". That I kind concur with him, instead of workaround missing functions it may be better to just write a compatibility library that complements musl with the missing functions. This way, any program that needs those functions could just import this library if they're compiling in a non-glibc system. I am seeing that lots of the fixes proposed by the author are things like "missing import because glibc exposes some symbols by mistake and musl does not". And this is definitely the kind of fix that upstream would accept[2]. [1]: https://github.com/systemd/systemd/issues/10130 https://github.com/systemd/systemd/issues/10130 [2]: https://github.com/systemd/systemd/pull/34066 https://github.com/systemd/systemd/pull/34066
    - NewJazz 2y ago
      it may be better to just write a compatibility library that complements musl with the missing functions It exists. See gcompat. https://github.com/Stantheman/gcompat https://github.com/Stantheman/gcompat
      - awilfox 2y ago

by bhaney 2y ago

frankjr 2y ago

> 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/ea310b2e580a25038f9592da4160d017ebfce3fc/etc/rc.conf#L7 https://github.com/OpenRC/openrc/blob/ea310b2e580a25038f9592...

NavinF 2y ago
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.
- amszmidt 2y ago
  Plenty don’t, e.g. BSDs. Bunch of embedded GNU/Linux systems. Etc.
  - NavinF 2y ago
    I meant OSs that have consumer market share. Eg on people's desktops and phones. Nobody cares about BSDs and a bunch of embedded GNU/Linux systems
    - awilfox 2y ago
      A lot of people care about BSDs and embedded Linux systems. Such as: Netflix (FreeBSD), anyone with a Linux-based router or cable/DSL modem, and so on. That said, parallel startup is possible on those systems too. There was an out-of-tree patch for parallel rc(8) on FreeBSD some time ago, and dinit is parallel, etc. I think OpenRC should move towards making parallel startup stable and supported so that those systems can do that as well.
    - zekica 2y ago
      Almost everyone's router is an embedded Busybox/Musl/Linux system. There are billions of them running every day.
      - synergy20 2y ago
        they don't use openrc though
    - btreecat 2y ago
      Alpine has market share. It's just targeting a different market space than what you're measuring.
      - mort96 2y ago
        > consumer market share
      - marcthe12 2y ago
        Some Alpine linux derivatives are kinda want switch to systemd and hence the porting
    - deleted 2y ago
      [deleted]
    - bee_rider 2y ago
      OpenRC doesn’t have huge consumer market share, at least in the context where this sort of thing matters. For regular Linux desktops, most of the distros use SystemD.
- bee_rider 2y ago
  It is a simple little startup system with some dedicated users. Open source projects don’t need huge user-counts to justify their existence. It isn’t a profit center, people just do this stuff for fun, because they enjoy tinkering, or maybe they coded it up and decided to just share it out of altruism.

happymellon 2y ago

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.

actionfromafar 2y ago
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.
- trueismywork 2y ago
  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.
  - p_l 2y ago
    Doesn't mean the result is all that good. Having dealt with it for some time now, the amount of "good idea, bad implementation" I hit is too damn high. And it's nigh impossible to replace for various reasons, including at one point critical interfaces that various user-important programs depended on being a constant treadmill of updates, lack of documentation, and hidden dependencies on internals.
    - awilfox 2y ago
      It's true. systemd has a lot of good ideas with questionable implementations. I'd love networkd if it didn't have silly decisions made. And it has some questionable ideas with good implementations. For example, I hate the journal, but admit it is implemented well. At the end of the day, it's about tradeoffs and using what suits the system at hand. For some people that will be systemd, and bringing systemd to Adélie and other musl libc distributions means that it can be used by those people. Call me old-fashioned, but I also hold out hope that at least some of those questionable implementations could be fixed if only someone with the desire would write a patch and send it upstream. Bringing systemd to musl means the people in musl land that aren't knee-jerk anti-systemd maybe might be more enthused to do just that, improving it for everyone using it.

awilfox 2y ago

> Either way, super cool. What's the likelihood that this ends up getting upstreamed? High: <https://github.com/systemd/systemd/pulls?q=is%3Apr+author%3Aawilfox https://github.com/systemd/systemd/pulls?q=is%3Apr+author%3A...>.

blueflow 2y ago
Did Lennart change his mind? https://lists.freedesktop.org/archives/systemd-devel/2014-October/023869.html https://lists.freedesktop.org/archives/systemd-devel/2014-Oc...
- kokada 2y ago
  I don't think Lennart changed his opinion, if you look further in this thread[1] Lenart wasn't ever against musl per se, it is more like "we use non-POSIX features from glibc that we found useful, and we are not going to reinvent them, so either convince musl to implement those features or carry patches fixing the issues". That I kind concur with him, instead of workaround missing functions it may be better to just write a compatibility library that complements musl with the missing functions. This way, any program that needs those functions could just import this library if they're compiling in a non-glibc system. I am seeing that lots of the fixes proposed by the author are things like "missing import because glibc exposes some symbols by mistake and musl does not". And this is definitely the kind of fix that upstream would accept[2]. [1]: https://github.com/systemd/systemd/issues/10130 https://github.com/systemd/systemd/issues/10130 [2]: https://github.com/systemd/systemd/pull/34066 https://github.com/systemd/systemd/pull/34066
  - NewJazz 2y ago
    it may be better to just write a compatibility library that complements musl with the missing functions It exists. See gcompat. https://github.com/Stantheman/gcompat https://github.com/Stantheman/gcompat
    - awilfox 2y ago