On Mon, Feb 24, 2014 at 9:42 PM, Yuri K. Shatroff <yks-...@yandex.ru> wrote: > > > 24.02.2014 16:39, Mark David Dumlao пишет: > >> On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff <yks-...@yandex.ru> >> wrote: >>> >>> 24.02.2014 02:32, Alan McKinnon wrote: >>>> >>>> [1] For lack of a better term, let's just call systemd here a "system >>>> controller". What is this ONE thing a system controller should do and do >>>> it well? >>> >>> >>> >>> An init daemon generally does one thing well. >> >> >> it's obvious you haven't thought this through. >> >> consider, for a moment, that the "one thing well" that an init daemon >> is supposed to do is >> "run programs that do arbitrary things to get the system to an arbitrary >> state". >> >> do you not see a problem? > > > No. As you say, ``an init daemon is supposed to do is "run programs``, until > here you're right, but then you start talking about things the init doesn't > do but the programs do. In your wording, an init daemon is also a DBMS, an > MTA, a network startup daemon, a firewall, a getty and whatever program runs > on the system.
Let's try to talk you through to a soft landing here. When we say init, are we just referring to pid 1, or are we referring to something else entirely? OpenRC is often spoken of in the same breath as systemd, as if they were the same kind of thing. That sounds fair but think about it for a second: openrc - as most people talk about it - isn't even pid 1. as most people talk about it, openrc includes the functions.sh, the net.eth0 scripts, the script for starting your /sys, /proc, mounting local and network filesystems, setting the hostname and so on. They may be written in a different language from pid1, but when people talk about openrc, they are talking about that whole ball of wax. From a systems perspective - they're parts of the same thing. Even discounting the parts that you think are ridiculous, like databases and loggers, there are clearly more parts in there above than can be cleanly defined as "one thing". Who gets to decide which is the "one thing" or not? You? Don't you rely on openrc to set your hostname? Load your kernel modules? Run your sysctl? Set any miscellaneous options in /sys? Mount your filesystems? Go ahead, define for everyone, once and for all, what this "one thing" is. Does this one thing init include a subsystem for reading separate environment files per-service? Isn't this just feature creep? Can't you just edit the init scripts to add those in? I mean, they are already scripts after all. And they're in /etc, they're meant to be configured. Does this one thing include service dependencies? Why sysv has gone for a LONG time without them, just a sequencing, and that works fine for almost all cases anyways. Isn't this just feature creep? Can't you just edit the init scripts to start any dependent services? Point is - go look at any arbitrary feature that's part of your "init system" and you could cry to hell and high water that it's violating the "one thing", whatever that "one thing" is that doesn't seem to be defined. At least with systemd the parts are cleanly split off into separate executables. Yes, it's technically not needed for pid 1 to create tempfiles for other programs. That's why systemd-tmpfiles is its own tiny program, that does one "one thing" (create tempfiles for other programs) and nothing else. Yes, it's technically not needed for pid 1 to check your filesystems. That's why systemd-fsck is once again, a separate utility, that does "one thing" (run fsck) well. Yes, it's technically not needed for pid 1 to remount your filesystems readwrite. Again there's a separate utilty for that, that does nothing but just that. It's clear to me that there's an analogue between the different parts of a full openrc system - that just happen to be implemented in scripts - and the different parts of a systemd system - that just happen to be implemented in small binaries. Every time people complain about systemd having too many features, they just _casually_ forget to mention that, for instance, their init actually asks them if they want to run interactive (why do that when you can specify from the boot loader?) or checks the configuration files of their daemons to see if they're valid and prompts the user to config if not. They just _casually_ fail to mention that their init has plugins for NetworkManager and ifplugd, that it comes with scripts for setting the consolefont. Meanwhile systemd does those same things, and it's bloated, theirs isn't. Oh you're going to say that that's not fair, it's external optional stuff, it's not _really_ part of openrc, but that's not intellectually honest is it? Heck, I could do that same. I could control my bootup process so that I run my own stuff instead of systemd-fsck, systemd-tmpfiles, systemd-mount and all that jazz and run plain old init scripts in their place. Why bother? The reality is that - init scripts don't do just one thing, and don't even do it well. -- This email is: [ ] actionable [ ] fyi [x] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate [ ] soon [x] none
