From 6a42c8de66e3b2dc7293ddeadaa3ee396db2624d Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Sat, 12 Oct 2013 13:47:42 -0400 Subject: initial commit --- public/arch-systemd.md | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 public/arch-systemd.md (limited to 'public/arch-systemd.md') diff --git a/public/arch-systemd.md b/public/arch-systemd.md new file mode 100644 index 0000000..c3b9b37 --- /dev/null +++ b/public/arch-systemd.md @@ -0,0 +1,56 @@ +What Arch Linux's switch to systemd means for users +=================================================== +:copyright 2012 Luke Shumaker + +This is based on a post on [reddit][1], published on 2012-09-11. + +[1]: http://www.reddit.com/r/archlinux/comments/zoffo/systemd_we_will_keep_making_it_the_distro_we_like/c66nrcb + +systemd is a replacement for UNIX System V-style init; instead of +having `/etc/init.d/*` or `/etc/rc.d/*` scripts, systemd runs in the +background to manage them. + +This has the **advantages** that there is proper dependency tracking, +easing the life of the administrator and allowing for things to be run +in parallel safely. It also uses "targets" instead of "init levels", +which just makes more sense. It also means that a target can be +started or stopped on the fly, such as mounting or unmounting a drive, +which has in the past only been done at boot up and shut down. + +The **downside** is that it is (allegedly) big, bloated[[1](#foot1)], and does +(arguably) more than it should. Why is there a dedicated systemd-fsck? +Why does systemd encapsulate the functionality of syslog? That, and it +means somebody is standing on my lawn. + +The **changes** an Arch user needs to worry about is that everything +is being moved out of `/etc/rc.conf`. Arch users will still have the +choice between systemd and SysV-init, but rc.conf is becoming the +SysV-init configuration file, rather than the general system +configuration file. If you will still be using SysV-init, basically +the only thing in rc.conf will be `DAEMONS`.[[2](#foot2)] For now +there is compatibility for the variables that used to be there, but +that is going away. + +[1] + +*I* don't think it's bloated, but that is the criticism. Basically, I +discount any argument that uses "bloated" without backing it up. I +was trying to say that it takes a lot of heat for being bloated, and +that there is be some truth to that (the systemd-fsck and syslog +comments), but that these claims are largely unsubstantiated, and more +along the lines of "I would have done it differently". Maybe your +ideas are better, but you haven't written the code. + +I personally don't have an opinion either way about SysV-init vs +systemd. I recently migrated my boxes to systemd, but that was because +the SysV init scripts for NFSv4 in Arch are problematic. I suppose +this is another **advantage** I missed: *people generally consider +systemd "units" to be more robust and easier to write than SysV +"scripts".* + +I'm actually not a fan of either. If I had more time on my hands, I'd +be running a `make`-based init system based on a research project IBM +did a while ago. So I consider myself fairly objective. + +[2] You can still have `USEDMRAID`, `USELVM`, `interface`, `address`, +`netmask`, and `gateway`. But those are minor. -- cgit v1.2.3