Tweet
Originally posted by gens
View Post
1) I do care about logging. I do care about making logs hard to tamper with, in ways which are hard to detect. I do care about loss of log records before logging daemon is operational. Systemd takes care of it. Others chosen to ignore it. So they have to face the result of their ignorance. Nothing more, nothing less.
2) I also care about sane boot sequence failures logging. It is very nice when I can get idea what goes wrong in simple and civilized way. Systemd seems to be best here. Upstart takes some care but overall seems to be worse on this. Not to mention in realistic cases it also half-upstart and half-sysv system. And in sysv init ... nobody gives it a fuck. It is completely up to me to code all logging if something goes wrong. Most init scripts would totally ignore return codes and do not care about failures either. Hmmph.
3) I also care about more or less sane enable/disable of services. And I would not call what sysv init does "sane". This is real insanity. Not to mention this "runleves" idiocy maps very poorly on upstart. Let kill it with fire. Hopefully no traces of this shit will remain in most Linux systems I would like to deal with.
4) I do care about proper boot sequencing and dependencies. I may want to start "this fancy program" right before or after "something". And one more time, systemd wins - just couple of lines in config file and I get what I want. Upstart? Okay, it can handle it. Most of time. Yet, some approaches used in upstart could make dependency expression quite hard in some cases. Sysv init? Oh, let it burn in hell.
5) I also care to set proper UID, GID and priority. Sure, some programs can do it on their own. But not all of them. Upstart and systemd take care of this and this is really convenient. Systemd haves more features of this kind and therefore declared winner for me. Basically it is much easier to issue few syscalls from C program rather than mess with all this crap via scripts. Systemd and upstart can do it for me. Nice.
6) In some cases I also care if particular program will restart on crash without human intervention. In systemd and upstart it is matter of couple config lines. As well as limiting intensity of restarts, should service runtime data became broken to degree service fails to start at all. In sysv init I'm basically on my own.
7) I do care about containers. Even lame and insecure chroot is a challenge to set up if I use sysv init. Not to mention containers. OTOH systemd is the only thing around which is aware of the fact Linux got cgroups and namespaces and these are far more fun than just sucking chroot. Sure, I can code my own launcher in C to put my process to separate namespaces and so on. Yet it will be great if I do not have to reinvent the wheel. Systemd takes care of it. That's what I warmly welcome!
. It is not yet does all I want, but it was the ONLY solution which recognized mentioned problems and bothered self to relieve admins from hardcore system-level coding. Its really wrong Linux had such nice features but lacked proper tooling to use them except doing all syscalls directly on my own.8) I also care about VMs and somesuch. Poettering seems to share this idea and also cares about deployment from templates, accounting running VMs/containers and managing these. Granted KVM is a part of Linux kernel, I warmly welcome tools to use modern Linux features with minimal efforts. Not like if I want to write my own VM registration facility or tools to deploy VM or container from template.
9) I also care about snapshots, "reset system to defaults" and somesuch. On VM I usually can revert snapshot in a matter of seconds and voila: clean, working system is here, ready to serve. Somehow, I think it is a time for bare metal to be "blessed" with snaphot magic as well. And obviously I do not want to reinvent the wheel myself.
10) Last but not least, I also care about simplicity and sanity. Patching shell code from (probably drunken) coders who embed configuration data right into 500th line of code is not a fun at all. Its just fucking wrong to mix code and configuration data in same place and almost nobody of shell script kiddies bothered self to learn how to do it right. Not to mention each and every distro does it their own way, usually incompatible with others. So it is pain in the ass to fix or port such scripts. I think scripts should be exception for "difficult cases" when there was no way to avoid program logic rather than norm instead of configuration data, when even simple, very usual program comes with some hundreds of lines of unobvious code just to launch it.
Comment