systemd: please stop trying to take over the world :)
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.
systemctl --all shows 258 units total on my machine,
thus systemd uses ~40 *KILO*bytes of state per unit?
I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know. It's called "featuritis".
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?
libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?
libwrap? systemd is a network application now too?
libaudit? What systemd has in common with audit?
libdbus?... this is a lost battle I guess...
I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*
At the very least, I would like to see its memory consumption
to go down substantially.
It is an *init replacement*, not the replacement for everything.
One of init's goal is to be *simple* and *stable*.
Every new feature you add and library you link against
works against that goal.
To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...
devel mailing list