On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@xxxxxxxxxxxxx> wrote: > Am 15.08.2012 13:34, schrieb Felipe Contreras: >>>> 1./ Be a small simple binary >>> >>> The systemd main binary is not very large (larger than sysvinit's >>> /sbin/init, but not by much). >> >> But that binary alone is useless, and certainly not *simple*. > > /sbin/init from sysvinit alone is useless. What is your point? The rest are rather simple scripts (in the case of Arch Linux). And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument. >>>> 2./ Have no dependencies >>> >>> That is pure BS. If something has no dependencies, it has to do >>> everything in the binary itself. You either end up with no features, or >>> potential for tons of bugs. >>> >>> Having NO dependencies also means you have to bypass the C library and >>> implement everything from scratch - that is the worst idea ever. >> >> No need to overreact, the meaning is clear: >> >> 2. Have as few dependencies as possible, preferably dependencies that >> are used widely in most systems and that have few dependencies >> themselves, and are simple themselves > > Okay, where exactly does systemd violate that? d-bus, for starters. >>>> 3./ Be easy to follow, fix and lockdown, best fit being interpreted >>>> languages. >>> >>> So, init should be a small binary in an interpreted language? Am I the >>> only one who notices you are contradicting yourself. >> >> No. The "services" (in systemd lingo) should be in an interpreted >> language: e.g. shell. > > Why should they be? As far as I understand, they're human-readable text > files. One might say this is an "interpreted language". No, they are compiled binaries. The code is in C (not interpreted). -- Felipe Contreras