Hi Lennart,
On Mon, 2011-06-13 at 10:15 +0200, Lennart Poettering wrote:
On Fri, 10.06.11 15:07, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> I understand your desire to replace everything by systemd.
I have no such desire.
What is this then?
int main(int argc, char *argv[]) {
...
if (arg_running_as == MANAGER_SYSTEM && !serialization) {
locale_setup();
if (arg_show_status || plymouth_running()) <== ??
status_welcome();
kmod_setup(); <=== ???
hostname_setup(); <=== ???
machine_id_setup(); <=== ???
loopback_setup();
test_mtab();
test_usr();
test_cgroups();
}
"plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?
This is an antithesis to modular, Unix way of doing things.
It starts to have shadows of monolithic Windows-like
"we know better than you what you need" approach.
hostname_setup()?
machine_id_setup()? Why systemd has *source-code-level knowledge*
about it? I would say that if admin wants to have /etc/machine-id,
he can set up startup code to generate it.
For one, I had no /etc/machine-id on machines I was administering
for decades, with no ill effects. I don't want init to know better
than me what I want to have.
kmod_setup() loads autofs4, ipv6 and unix modules.
Why? What if I don't want to run automounter?
systemd will force me to do so?
Why it (a *program*) took upon itself to decide what modules should
be running? There decisions are traditionally up to *humans*
in Unix world.
> I really do. syslogd, klogd, mount, fsck, and a dozen other
things
We don't replace syslogd, klogd, mount, fsck and dozen of other things.
What is /lib/systemd/systemd-fsck then?
/lib/systemd/systemd-logger?
(Also, most of them don't emit useful info on --help...)
> Now I hear about plans to incorporate ConsoleKit into it
> (hearsay, so maybe it's not true).
Yes, systemd as a platform will include a tiny daemon which takes over
the role of CK.
That's what I was referring to by "taking over the world".
Today I can remove CK from my Fedora install if I want to.
If it goes into systemd, I will be unable to do so.
Yet another bit of freedom taken away.
> 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*
I think systemd is much more optimized that what existed
previously. (what else is parallelization but optimization?) I bet with
you that a systemd system (modulo SELinux) can be built in a way that
uses much less resources and boot time than one built on Upstart.
I never used upstart. I used daemontools. I bet you can't beat *that*
on resource front. Boot time is comparable.
(How?
We simply spawn shell (or even zero) shells and other interpretors, and
start a number of seldom-things only when needed and the rest in
parallel).
Optimizing towards not spawning shell at all is a strange optimization
target. Reducing the need to spawn shells - yes, eliminating - no.
> It is an *init replacement*, not the replacement for
everything.
I like to see it as a modular platform to build an OS from.
That's what I was referring to by "taking over the world".
It includes an
init system and a few auxiliary tools (readahead for example, and C
implementations of the basic boot scripts).
Readahead is a band aid for stuff which is bloated enough
to affect boot by sheer amount of necessary reading.
I don't say others must not use it, but I would like to be able
to switch it off. (For one, it makes bloat more noticeable,
so I can see what needs fixing.)
As I said, freedom to do things as admin wants
is important trait of Unix way.
C implementation of shell scripts tends to be too rigid.
I don't see why you are trying to do that.
If it because bash startup time is too long, I have
a few faster shells for you...
> Every new feature you add and library you link against
> works against that goal.
Nah, don't think so. We have fewer deps, and less dependencies than the
equivalent Upstart- and shell based boot.
Competing with Upstart is easy :)
It is my intention to minimize
the minimum set of packages you need to bootstrap a Linux system. While
the systemd package might get a bit bigger than sysvinit through that --
*overall* you get a much smaller and simpler system, build from a much
smaller number of source packages. That saves resources, makes things
simpler and faster.
Everyone who likes coding thinks that his favorite package is great.
I have no doubt that you are proud of systemd. It actually isn't
a bad software.
However, allow me to have a not completely rosy view of it either.
"Saves resources" is not exactly true, as I see it,
on memory consumption front.
> 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.
No, that would complicate things for little reason.
How running under PID != 1 makes any difference? I was running
various service monitoring tools as ordinary
(non-init) processes and it works equally good. No, better,
because crashes in non-init are not as detrimental.
I find a system
whose PID after boot is in the 500 range much simpler and leaner than
one that is in the 5000 range.
That's what I was referring to by "taking over the world".
You want to be "special". You want to have PID 1.
--
vda