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@xxxxxxxxxx> Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
