4 ms·

> By not having something competitive Alpine is less and less attractive for newer production deployments. Alpine uses OpenRC (https://wiki.gentoo.org/wiki/Ope

by jph 5y ago

> By not having something competitive Alpine is less and less attractive for newer production deployments. Alpine uses OpenRC (https://wiki.gentoo.org/wiki/OpenRC https://wiki.gentoo.org/wiki/OpenRC). IMHO Alpine and OpenRC tend to make production deployments more predictable and reliable, because of deliberately simple init ordering, as well as a smaller surface area as compared to systemd.

detaro 5y ago
There is some work on a replacement that does more while fitting the requirements and philosophy of alpine: https://skarnet.com/projects/service-manager.html https://skarnet.com/projects/service-manager.html
- mendelmaleh 5y ago
  Good read, thank you!
- GekkePrutser 5y ago
  Interesting, I have a lot more faith in the alpine team implementing something like this than in RedHat. Even when RedHat made consumer OSes (before spinning them off to Fedora) I didn't like them. What they're doing looks like a great alternative. I also hope they will not have any reliance on dbus as systemd does. Reliance on dbus is one of the main issues I have with systemd (besides its size and complexity).
  - zxzax 5y ago
    I've seen a lot of these comments to this effect but I'm still not quite sure: what is the issue with dbus? Is there another replacement that meets all the use cases?
    - detaro 5y ago
      Question is if an init system needs all the use cases dbus can support. Dbus always feels unwieldy to work with, especially once you leave specific desktop stacks, and for me personally, the biggest failures of systemd-based systems have been issues with dbus not working properly for whatever reason.
      - zxzax 5y ago
        I don't know the status of this on a practical level (e.g. in any given distro) but systemd does support daemonless dbus access over a private socket (/var/run/systemd/private) in some scenarios. Would that help?
    - GekkePrutser 5y ago
      The problem I have with it is that it's not easy to interact with, and something that's very desktop focused. I think it's one of the examples of Systemd pulling in way too wide a scope.
      - zxzax 5y ago
        Can you elaborate? I found it very easy to interact with once I learned how to use the tooling (busctl, d-feet, etc). I also don't think I would say it's desktop-focused, it was designed for that use case originally, but it seems it can be used by anything else that happens to use a similar OOP-based RPC design (and it seems systemd is one of those things). Is there another replacement that's of a smaller scope that would cover all the use cases that systemd needs?
- jart 5y ago
  According to that page "the main reason Alpine aims to replace" OpenRC is they want the init system to "interface with external events". Huh? The thing I like about OpenRC is is if I `grep -R socket` on its codebase then it comes up empty. Alpine seems to be leaning towards s6 according to that page, which appears to have a treasure trove of network services. Last thing I want is to wake up one morning after updating Alpine and have all these scampering daemons like skadnsd, s6-fdholderd, s6-sudod, s6-ipcserverd, s6-ftrigrd, s6lockd, and ucspilogd skulking in the background. Also the boldness of the name. If you name it System 6 then you're claiming you've built something better than Bell System V. The init process has total power over the rest of userspace. I'm sorry but I don't think your system administration paradigm that MiTMs DNS deserves to be /sbin/init. I just want a UNIX-like system with few opinions that stays out of the way.
  - CameronNemo 5y ago
    Those last four s6-* programs are not daemons. They are chain loading programs that modify permissions or the environment then exec into the next program in the chain.
  - medstrom 5y ago
    To be frank s6 and its cousins like runit have so much fewer lines of code -- I'm pretty sure it's fewer than OpenRC and traditional SysV both -- because of simple and thought-through architecture. If you're gonna do a systemd alternative at all, ever, it'd have to be on one of these sane foundations.
coolreader18 5y ago
I think given these lines in the article (and the fact that she mentions OpenRC): > I have been an Alpine user for almost a decade and it's one of my favorite linux distributions. > This talk is intended to show how green the grass is on the other side and how Alpine can benefit from these basic ideas. She's probably familiar with it.

by jph 5y ago

detaro 5y ago

There is some work on a replacement that does more while fitting the requirements and philosophy of alpine: https://skarnet.com/projects/service-manager.html https://skarnet.com/projects/service-manager.html

mendelmaleh 5y ago
Good read, thank you!
GekkePrutser 5y ago
Interesting, I have a lot more faith in the alpine team implementing something like this than in RedHat. Even when RedHat made consumer OSes (before spinning them off to Fedora) I didn't like them. What they're doing looks like a great alternative. I also hope they will not have any reliance on dbus as systemd does. Reliance on dbus is one of the main issues I have with systemd (besides its size and complexity).
- zxzax 5y ago
  I've seen a lot of these comments to this effect but I'm still not quite sure: what is the issue with dbus? Is there another replacement that meets all the use cases?
  - detaro 5y ago
    Question is if an init system needs all the use cases dbus can support. Dbus always feels unwieldy to work with, especially once you leave specific desktop stacks, and for me personally, the biggest failures of systemd-based systems have been issues with dbus not working properly for whatever reason.
    - zxzax 5y ago
      I don't know the status of this on a practical level (e.g. in any given distro) but systemd does support daemonless dbus access over a private socket (/var/run/systemd/private) in some scenarios. Would that help?
  - GekkePrutser 5y ago
    The problem I have with it is that it's not easy to interact with, and something that's very desktop focused. I think it's one of the examples of Systemd pulling in way too wide a scope.
    - zxzax 5y ago
      Can you elaborate? I found it very easy to interact with once I learned how to use the tooling (busctl, d-feet, etc). I also don't think I would say it's desktop-focused, it was designed for that use case originally, but it seems it can be used by anything else that happens to use a similar OOP-based RPC design (and it seems systemd is one of those things). Is there another replacement that's of a smaller scope that would cover all the use cases that systemd needs?
jart 5y ago
According to that page "the main reason Alpine aims to replace" OpenRC is they want the init system to "interface with external events". Huh? The thing I like about OpenRC is is if I `grep -R socket` on its codebase then it comes up empty. Alpine seems to be leaning towards s6 according to that page, which appears to have a treasure trove of network services. Last thing I want is to wake up one morning after updating Alpine and have all these scampering daemons like skadnsd, s6-fdholderd, s6-sudod, s6-ipcserverd, s6-ftrigrd, s6lockd, and ucspilogd skulking in the background. Also the boldness of the name. If you name it System 6 then you're claiming you've built something better than Bell System V. The init process has total power over the rest of userspace. I'm sorry but I don't think your system administration paradigm that MiTMs DNS deserves to be /sbin/init. I just want a UNIX-like system with few opinions that stays out of the way.
- CameronNemo 5y ago
  Those last four s6-* programs are not daemons. They are chain loading programs that modify permissions or the environment then exec into the next program in the chain.
- medstrom 5y ago
  To be frank s6 and its cousins like runit have so much fewer lines of code -- I'm pretty sure it's fewer than OpenRC and traditional SysV both -- because of simple and thought-through architecture. If you're gonna do a systemd alternative at all, ever, it'd have to be on one of these sane foundations.

coolreader18 5y ago

I think given these lines in the article (and the fact that she mentions OpenRC): > I have been an Alpine user for almost a decade and it's one of my favorite linux distributions. > This talk is intended to show how green the grass is on the other side and how Alpine can benefit from these basic ideas. She's probably familiar with it.