systemd and changes

[Matthew Miller]

On Mon, Aug 23, 2010 at 05:51:30PM +0200, Lennart Poettering wrote:
> Well, we took the liberty to interpret noauto a little bit differently
> than you: everything marked "auto" will be mounted at boot, and boot
> will not proceed until all devices listed as auto appeared and are fully
> mounted (or things timed out). File systems marked as "noauto" won't
> delay the boot process if they aren't, but they'll still be mounted when
> they are plugged in, regardless whether that is at boot or during
> runtime.
> 
> i.e. "auto" → wait for this on boot; "noauto" → don't delay boot for this.

This seems like a useful behavior, but we can't just make old options have
radically different meaning -- there's really no room for interpretation.

How about having a new option called "noboot", "nowait", "nobootwait",
"nowaitonboot", "autolater", or somesuch? Although, arguably, if one needs
that kind of functionality, the existing autofs daemon does it in a more
flexibile way already.

Is it helpful at this point if I file a bug for systemd's noauto behavior?

This is the second such surprise that I've come across -- "shutdown -r +1"
of course being the other. And of course before that, the long thread about
the chkconfig and service commands. I was positively impressed by your
responsiveness and flexibility on the shutdown delay issue, but I have to
say that the pattern here is making me worried. I don't mean it as a flame
or attack on either you or the project, but I wonder if things are moving
too fast for systemd to be a good choice for Fedora 14.

Again, with no intent to troll, can you estimate how many more changes like
this are in store? Like I hope was illustrated in the "the next steps"
thread, change in itself isn't cost-neutral. When you're replacing a core
component of the OS, and you're faced with a point where a human interface
could be changed, the first thought must be "how can we make this
improvement with minimal disruption?".

So, my question is serious. If we go ahead with systemd for F14, will we be
hit with an onslaught of confusion, trouble, and change? That would be good
for testing systemd, but *not awesome* for the distribution or for its
users. Or, on the other hand, is it a matter of a few kinks which we can get
solved before release?


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences