Linked by jessesmith on Wed 5th Nov 2014 10:39 UTC
Linux Over the past year I've been reading a lot of opinions on the new init technology, systemd. Some people think systemd is wonderful, the bee's knees. Others claim that systemd is broken by design. Some see systemd as a unifying force, a way to unite the majority of the Linux distributions. Others see systemd as a growing blob that is slowly becoming an overly large portion of the operating system. One thing that has surprised me a little is just how much people care about systemd, whether their opinion of the technology is good or bad. People in favour faithfully (and sometimes falsely) make wonderful claims about what systemd is and what it can supposedly do. Opponents claim systemd will divide the Linux community and drive many technical users to other operating systems. There is a lot of hype and surprisingly few people presenting facts.
Permalink for comment 599029
To read all comments associated with this story, please click here.
Complexity
by tbullock on Wed 5th Nov 2014 18:53 UTC
tbullock
Member since:
2012-01-30

I've been running OpenBSD using cwm (for when I need graphical stuff) and just a serial console or ssh to the shell otherwise. My operating systems don't restart more than once or twice a year if I can help it.

Obviously systemd won't ever become a part of OpenBSD (or any other BSD), so largely I've been ignoring the yakyak around the program.

On the whole, the systemd software appears complex and full of magic, moreover it doesn't seem to be in keeping with the traditional philosophy of keeping stuff small, simple and independent of each other.

I took a moment a minute ago to download the latest systemd tarball and looked at the source. Some things jumped out at me:

- 37.5 MB in uncompressed stuff
- 12.8 MB of c source (This is huge!?)
- Dependencies: dbus, udev, cap, attr, selinux, pam, libaudit, others?
- Dependencies of dependencies: Rabbit hole, but there are some here, like X11.
- Presumably these are all statically linked into the binary so that emergency booting is possible (like if I cannot mount /usr or /var or something else important).

All that to turn some software on and off.

My opinion is that this is way too complex for an init system; for me to use something like this I'd want to see less than, say 6 (arbitrary!) c source files each with less than 2k lines of code and probably a dependency to libevent and imsg for a small privsep state machine. Then you'd at least know what you're getting into.

Even then, the small collection of sh (not bash) scripts that starts my handful of daemons is just immensely preferable for me.

Reply Score: 3