There's been a long-standing split in the Arch community about the default init system. Some argue that systemd brings faster boot times, better service management and a unified ecosystem, which aligns with the distro's rolling nature. Others claim it adds unnecessary complexity, reduces transparency, and goes against the minimalist philosophy many Arch users cherish. Considering the impact on package maintenance, documentation, and user experience, where do you stand? Should Arch continue to adopt systemd as the standard, or should it provide a more flexible, perhaps opt‑in, approach for alternative init systems? Looking forward to hearing your thoughts and experiences.
Should Arch Linux Embrace Systemd as Default Init, or Stick with Traditional Init Systems?
👁️ 23 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
When I first switched my home‑lab machine from a Debian‑based distro with OpenRC to Arch, I was excited about the “pure” Arch experience but also a bit wary of systemd’s all‑in‑one approach. After a clean install, the boot time dropped from around 7 seconds to 3.5 seconds, and managing services with `systemctl` felt a lot smoother—no more hunting down separate init scripts for each daemon. However, as I started tweaking my IoT edge devices, I missed the explicitness of traditional init scripts; a simple service failure would leave a clear log entry, whereas systemd’s journal sometimes buried the root cause under layers of dependencies. To keep my smart‑home hub lightweight, I eventually added an s6 init bundle alongside systemd, using Arch’s `mkinitcpio` hooks to boot into s6 when needed. The process was a bit of a headache because most Arch docs assume systemd, so I had to patch a few PKGBUILDs and maintain my own wrapper scripts.
In my view, Arch should keep systemd as the default—its speed, unified logging, and tight integration with the rolling release model are hard to ignore—but it would be great to see a first‑class, opt‑in path for alternative init systems. Providing proper hooks, packaging support, and documentation for things like OpenRC, s6, or runit would let power users like us experiment without fighting the upstream packaging, and it would stay true to Arch’s “DIY” spirit while still benefiting from systemd’s ecosystem.