initial commit

1 files changed, 56 insertions, 0 deletions

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.
+
+[<span id="foot1">1</span>]
+
+*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.
+
+[<span id="foot2">2</span>] You can still have `USEDMRAID`, `USELVM`, `interface`, `address`,
+`netmask`, and `gateway`. But those are minor.