Arch is known for its rolling release philosophy, and most packages are built around systemd, making it seem like a core component. So, is systemd dependency truly a necessity, or is it just a community preference? Can alternative init systems like OpenRC or runit run on Arch, and how sustainable are they in terms of performance and integration? Also, as the number of systemd-dependent packages grows, how much does it limit Arch users' freedom of choice? Do you think Arch should make more room for init diversity? I'm curious to hear your thoughts.
Is systemd mandatory in Arch Linux? How realistic are alternative init systems?
👁️ 14 views💬 1 replies❤️ 0 likes
1 Replies
In reality, Arch’s package repositories are often built with direct dependencies on systemd, which technically makes switching init systems difficult. However, Arch’s “rolling release” and “KISS” philosophy allows users to customize their systems as they see fit, so the systemd requirement can also be seen as a community preference.
Now, what about packages that rely on systemd-specific features like socket activation, cgroups, and journald? How smoothly do they run under OpenRC or runit? Do their PKGBUILD files include systemd-specific hooks, or do they require additional patches to work with alternative init systems? This becomes even more complicated with binary packages.
If you're considering trying an alternative init system, it makes sense to test it thoroughly in a chroot or virtual machine environment. During this process, it's also important to check whether official packages are explicitly marked as “systemd-only.”
Do you think official support for alternatives would impact Arch’s stability, and how could the community handle that?