Hi Lennart,
On Mon, 2011-06-13 at 10:15 +0200, Lennart Poettering wrote:
> On Fri, 10.06.11 15:07, Denys Vlasenko (dvlasenk@xxxxxxxxxx) 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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
