Dev.SN ♥ developers
Sections
Dev.SN
from the Boot-him?-I-just-met-him! dept.
jbernardo writes:
"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.
So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."
[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]
(Score: 3, Informative) by caseih on Wednesday February 26 2014, @11:26AM
It's in RH now, well version 7, which is in beta. I'm running RHEL 7 beta, and it runs quite nicely with systemd. In fact I'd rather write systemd service files than mess with fragile, hard-to-debug init scripts that sometimes run for hundreds of lines of bash code. While systemd seems a bit opaque at first (though I understand the source code is fairly easy to understand), it's quite a bit better than having every daemon reinvent the wheel with locking code to prevent multiple instances, and having automatic process supervision.
And yes, RHEL 7 beta still a normal syslog daemon, and a text-file-based logger facility will always be there as long as people require it (usually for security audit purposes).
It's natural to be uncomfortable with something you don't understand. So just get more familiar with it, how it works, and how to use it. My only complaint is that Lenart seems to love using "ctl" in the names of his commands. journalctl, systemctl, etc. Doesn't exactly roll of the fingers on the QWERTY keyboard.
So far I think my concerns about systemd have largely been unfounded, and I'm a lot more comfortable with it. As with Wayland, it seems that most people's hate on it are based on ignorance mostly, which is unfortunate.
(Score: 1, Informative) by Grishnakh on Wednesday February 26 2014, @02:55PM
In fact I'd rather write systemd service files than mess with fragile, hard-to-debug init scripts that sometimes run for hundreds of lines of bash code. While systemd seems a bit opaque at first (though I understand the source code is fairly easy to understand), it's quite a bit better than having every daemon reinvent the wheel with locking code to prevent multiple instances, and having automatic process supervision.
Exactly. The sysvinit system is really a mess, because it offloads most of the logic to the init scripts, so it's incumbent on those scripts to do everything right, be bug-free, handle corner cases, etc. sysvinit really doesn't do much more than call these scripts; you could probably write a sysvinit clone in Perl in an hour.
systemd moves most of this logic into the core code of the daemon and its associated utilities, so all that's needed for each service is a short, simple descriptor file. The result is more centralization, and less "surface area" for bugs or security flaws. It's not much different than writing a C++ program using libraries vs. not using any libraries. In the latter case, you have to reinvent the wheel for everything: linked lists and other containers, strings, graphic widgets, etc. Why would you do that when you can just use something that an expert created and which is highly tested and deployed on a large scale so that it's reasonably bug-free?
(Score: 3, Insightful) by VLM on Wednesday February 26 2014, @03:23PM
"you could probably write a sysvinit clone in Perl in an hour."
So... why not? Or a shell script "library" for that matter.
Extremely stereotypically, systemd supporters make a well written and eloquent and true explanation of why libraries and include files were invented in the 70s, then outta nowhere switch gears into a total rewrite and rearchitecture of the entire system is necessary, and everyone's going to have to change absolutely everything in order to do exactly the same thing we've always done with no new benefit ... but don't worry its really easy.
OK a support library for sysvinit would be a great idea. Or perhaps a macro-preprocessor that eats a 3 line file and squirts out a 500 line long sysvinit script... although most of the scripts I've had to mess with have been like 10 lines but whatever. Anyway I agree with the general idea, write a support system for init. Now, what does the other 99% of systemd have to do with that?
By analogy it sounds a lot like... "I wanted to change the volume control widget on my mp3 player so it can go up to 11, not just 10. But that is a lot of work, you know, legacy code and such. So instead I merely rewrote the entire kernel interface for the PCI bus and also changed the API for the virtual memory system and embedded BASH into the kernel so you may never use any other shell again. Oh and some DE you don't use now demands it. But hey don't worry, its a really nice new API and once everyone is forced to rewrite everything you'll see how nice it really is."
(Score: 2, Informative) by Grishnakh on Wednesday February 26 2014, @04:30PM
No, it's more like "I wanted to change the volume control widget, but I also realized I wanted to be able to control that widget remotely so that I could manage a whole cluster of MP3 players easily. This required an entirely new architecture rather than making a crude hack onto something that was never designed for this."
systemd does a lot more than the old sysvinit ever did. For remotely-administered servers and embedded systems, these features are a boon.
Also, other UNIXes have had more modern init systems for ages.
(Score: 0) by caseih on Thursday February 27 2014, @01:20PM
But that's just it. You don't have to rewrite daemons to take advantage of systemd. Nor do you have to rewrite any other userspace program. There are features you can take advantage of if you want, like socket activations. I don't really understand your bizarre analogy. Seems an emotional response rather than factual.
But old-school init scripts work just fine, and if you want to take advantage of process supervision and run control (no more hacking with PID files), you just create a service file that runs your daemon in foreground mode (all daemons support this for debugging). In fact while running in debug mode you can turn on full debugging if you want and it's all captured to the log in a nice and usable way. It makes it super easy to drop in third party daemons and just run. In the old days I had to deal with poorly written init scripts that didn't really integrate well with my fedora program, or write my own init script, or punt and stick it in rc.local.
What's ironic is that OS X has been using a systemd-style init system since the beginning and there are many fans of OS X in this community. Somehow launchd is okay but systemd isn't? Come on. Launchd took some getting used to, but it works well. It replaces init, atd, and crond with a nice, easy to use system with simple service definition files.
Why is it that open source people are so quick to jump on the cutting edge (Linux 3.14 FTW), but get all bent out of shape when people try to innovate and actually make things better in user space?
Anyway, this is well past the actual discussion here, but I had to vent a bit even if no one ever reads this.