On Mon, 13.06.11 15:27, Denys Vlasenko (dvlasenk@xxxxxxxxxx) wrote: > kmod_setup(); <=== ??? We load a couple of kernel modules which systemd needs, and are sometimes compiled as module only and which cannot be autoloaded for a reason or another. This is ipv6, autofs4, unix.ko, and we load them explicitly so that we can use them. > hostname_setup(); <=== ??? We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, among other things (for example, the loopback device is always set up, you can always bind to 127.0.0.1 and ::1). > machine_id_setup(); <=== ??? Similar to the hostname we ensure that the machine id is always initialized, and has the same lifetime and validity guarantees as the hostname. i.e. that it is simply usable by *every* process started, regardless when. > "plymouth_running()"? Plymouth? Systemd knows about plymouth? Why? Because we need to constantly send updates to it. It's a trivial socket operation. It's a trivial thing and spawning a separate process to send those updates each and every single time is a major waste of resources and basically doubles the processes we have to spawn at boot. > This is an antithesis to modular, Unix way of doing things. Just because you can turn each trivial operation into a separate binary you shouldn't necessarily do that. It is what makes your system slow and heavy-weight. Insisting that we invoke sethostname() in a separate process is just stupid. I am mean, come on, think about it. It is *ONE* system call to the the hostname with sethostname(). Invoking /bin/hostname instead is at least 40 or so (and many of those quite heavy weight). And really, why are we even discussing the frickin hostname like this? And invoking the plymouth update tool after each process we start practically doubles the amount of processes we have to spawn. Which is a great way to make things slow, little more. > It starts to have shadows of monolithic Windows-like > "we know better than you what you need" approach. OMG! You used the "W"-word! Do you know what "mono" means? It's greek and means "one". And "lithic" means "stone". And if systemd communicates with Plymouth, then this is not monolothic at all, since systemd and ply are two processes, not one. systemd is not running Plymouth stuff in the same process, is it merely communicating with it. And the communication is very very trivial. > 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. Well, the point is to offer the machine id unconditionally, so that apps can start relying on them and stop misuing the hostname for stuff they shouldn't use it for. > kmod_setup() loads autofs4, ipv6 and unix modules. > Why? What if I don't want to run automounter? systemd supports .automount units, and to make that work we need to load the autofs kmod, if it is not compiled in. > systemd will force me to do so? No, systemd tries to load those modules but if you are into retro computing you can still blacklist them using the usual modprobe blacklisting, and systemd will honour that (i.e. by passing -b to modprobe). > Why it (a *program*) took upon itself to decide what modules should > be running? There decisions are traditionally up to *humans* > in Unix world. Nah. udev loads modules automatically. In fact on almost all systems there should be no need to ever load a module manually. And if the admin wants to blacklist a module he can easily do so via the modprobe config, how it should be done. > > We don't replace syslogd, klogd, mount, fsck and dozen of other things. > > What is /lib/systemd/systemd-fsck then? A wrapper, which handles the exit code and reacts properly to it. > /lib/systemd/systemd-logger? It's service systemd uses to provide logging for processes it spawns. i.e. in systemd you can simply configure in a service file that stdout/stderr of a process should go to syslog, and this is needed for that. > (Also, most of them don't emit useful info on --help...) They aren't user binaries. They are in /lib/systemd, not /usr/bin... > > > 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". Well, we simplify things a lot that way, and unify the behaviour of system and user services (i.e. they appear in the same cgroup hierarchy and so on). > Today I can remove CK from my Fedora install if I want to. You'll be left with very little if you do that. But why would you even want to remove that? > If it goes into systemd, I will be unable to do so. > Yet another bit of freedom taken away. Yes, correct. I hate freedom. Muauauauahah! > > 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. daemontools does not support socket activation for parallelizing execution of servers with its clients. So yes, we can beat *that*. > > We simply spawn fewer (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. Well, zero might not be realistic anytime soon, but as mentioned, I want to start fewer shells by default at boot. > 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.) You can easily disable readahead: systemctl disable systemd-readahead-replay.service systemd-readahead-collect.service > > 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 :) Why do you say that? It's the benchmark so far. The best solution that existed on Linux so far. > > 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. Hmm? systemd is an init system, so it is of course PID 1. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
