On 04/16/2013 04:33 AM, Kevin Chadwick wrote:
The Unix Philosophy is overapplied and used way too much like gospel. Is it a bad approach to system software? No, of course not! Is it the One True Way and Every Other Other Way the worst/evil? No, of course not!+ dropping human readable textfiles in favour of c binary code, which makes it needless more complex to debug the whole show.That's non-sense. systemd unit files are text-files in ini-like format and much more readable then shell scripts with all their boiler plate.I think you miss the point which is those unit files depend on C code that is not as easy to follow or as well documented as tools which follow the unix philosophy such as grep and you also don't seem to have read between the lines about the detail of "more complex to debug". In any case systemd has had more attention than it deserves so look inthis archive or likely any other archive (Gentoos a good one for a balanced view) and lwn.net for the arguments and make your own decision. Just don't believe the hype and understand that many pages on freedesktop.org aren't official or balanced but abused as if they are.
The problem with the Unix Philosophy is it was created in a day where its design principles actually were essential. Today it really is less important and in some ways detrimental in software engineering.
Am I saying the "do everything" approach is best? Absolutely not. But that's not systemd's goal either. It's just expanded from being merely a drop-in init replacement with a nice feature set to being something that is probably better for Linux, being a full-scale system manager with init-like capabilities.
The problem with those "objective" views of systemd you speak of is that they're entirely based on incorrect assertions of precisely how systemd works. A lot of people, for example, automatically assume that systemd is "against" shell scripts. This is simply not true. It can run shell scripts, even init scripts, just fine. It's just that it identifies that shell scripts needn't be a *requirement* in bringing up or breaking down a system. It really is better for the init system to use a minimal approach to invoking daemons as systemd does and no initscript does. And of course, if you need to do more than just "run a binary" in the unit file, systemd doesn't stop you from using an initscript approach either.
As far as "C code that is easy to follow and is well documented" I should point out a couple things.
I don't see why it's important to know how systemd works at the SOURCE level to write a unit. Unit files are very simple and systemd has very well-written documentation on how to make/interpret unit files for yourself. I should also point out that those "Unix Philosophy" tools you cite, as well are "C code that is not easy to follow and is not well documented." Ever try to grok grep's source code? Have you ever needed to to understant how you use it?
Systemd is just as open source as any other compiled program you use on Linux, and I find this argument lacking in merit. I'm a programmer. I'd like to think I'm a skilled programmer. Do I REALLY need to know how GCC, the Linux kernel, Xorg, vi, ZSH, or any other of my tools are programmed to use them? Nope. All I need is good documentation on how to use them (And whatever APIs I program with.).
Further, I also don't see it essential to delve into systemd's source code to debug unit files. In fact, I do believe systemd provides more than a suffificient framework to debug unit files. It just won't provide one to debug whatever it launches. Code quality of someone else's programming is not and should not be a goal of systemd. If you're using a buggy initscript in systemd, then look at the initscript, which systemd merely launched.
I concede there's plenty of hype about systemd. But SysV really does need to be laid to rest, and Upstart does things in a very backwards way. OpenRC is good, but not as fast/flexible/well supported as systemd, and was primarily designed for Gentoo.
Conrad