Am 15.08.2012 15:31, schrieb Felipe Contreras:
What argument? You _claim_ that it isn't simple, but you do not give any proof for that claim.
It is general knowledge that scripting languages are generally simpler than compiling languages.
Here I wanted to stop discussing with you, but I can't let this BULLSHIT mail stand without a reply. An argument that starts with "It is general knowledge that ..." is no argument at all. I will disregard this.
But fine, compare a few lines of rc.sysinit:
[ short snippet of shell code ]
To their equivalent in systemd:
[ long snippet of C code ]
The problem with shell code is that you work with an abstraction of the actual interfaces that is made for interactive usage. Most of the error handling is done via human-readable messages, there is only a single error code for each command. This makes proper error handling in non-interactive situations a nightmare. Input is done with arguments that are shell-parsed, which is very error-prone and limits the programmer's ability to pass what he wants to. The added overhead of repeated parsing and string-converting makes shell scripts slower. Shell code is checked for correctness on runtime instead of build-time. This makes it very complicated to write functioning shell scripts for complex tasks. You might notice that our initscripts are unable to handle most errors gracefully, they just keep going if something goes horribly wrong.
If you think the second one is simpler, then I don't you know what 'simple' means.
You are again comparing apples with oranges. First you talk about 'init' being simple, your example shows our initscripts, which is not part of 'init'. Then you show a code snippet from systemd that does much more than the initscripts snippet and claim it is not as simple. By only reading a few lines in this short code example, I already found another feature in systemd that people always wanted for initscripts, but was too hard to implement, because writing shell scripts for advanced functionality is not simple at all. So what are you comparing now? Our initscripts to systemd, or sysvinit to systemd?
Dependencies that are * used widely - check
Not as widely as shell, and libc, and util-linux. Some Arch Linux users don't use D-Bus, in fact, and it's not by default added to rc.conf precisely for that reason.
* in most systems - check
Less than the Arch Linux systems that use initscripts.
You cannot remove dbus from the Linux ecosystem. It's in there, everything uses it. Period. If you don't use it now, then you don't have bluetooth and you need root privileges to (u)mount removable devices. And lots more. Most importantly, dbus has been stable for years. It hasn't crashed for me in years.
* have few dependencies themselves - check
libx11 is a cheap dependency for you?
And now we make up imaginary dependencies. Do your homework.
* are simple themselves - ahemm
D-Bus is extremely complicated. It's more than 100k likes of code.
No argument here.
And I find completely the opposite to be the case. Scripts are easier to write, read, and debug.
Feel free to replace those binaries with shell scripts that perform the same task. Once you're finished, I'd be happy to congratulate you on wasting your time.
I'll stop discussing with you now, as this will lead nowhere. The fact remains that all you do is complain, instead of providing an alternative. The decisions are being made by the people who actually _maintain_ this stuff inside Arch.
The alternative is simple: stay with initscripts *at least* until the problems with systemd are sorted out.
Isn't that what we are currently doing? We still provide initscripts and sort out systemd bugs.
I just subscribed to this list, and 80% of the traffic I'm seeing is problems with systemd. That should tell you something; systemd has problems.
80% of the posts are random FUD about systemd. The other 20% are posts that address issues with systemd, which is part of the "sorting out systemd bugs". So, what exactly are you ranting about?