On 5/14/2011 9:20 AM, Serge Hallyn wrote: > Quoting David Serrano (dserra...@gmail.com): >> On Sat, May 14, 2011 at 00:15, Serge Hallyn<serge.hal...@canonical.com> >> wrote: >>> >>> I'm curious, whatcha got in mind? >> >> I don't think you have to have something in mind to implement this. >> Just that old motto "Be lenient in what you accept" :). > > So if I type 'lcx.' instead of 'lxc.', as I often do, it'll silently > ignore it? No, that's a bad idea. > > In any case I wasn't (until now) doubting Daniel's motivations, rather > I was pretty sure he had something neat in mind.
I like it but I can't think of anything off hand that I'd use it for that I couldn't just as easily use either comments or a separate file to do. And obviously as you point out there's an argument for enforcing only known options as a basic sanity check. On the other hand there have been plenty of times where I wished something would gracefully ignore options it didn't recognize which came from newer versions or from distribution patched versions. It gets in the way of portability and site/organization-wide administration in some cases unnecessarily. Sometimes the unknown options could be simply ignored and the end result would still be what I wanted. Ideally it should be a user-configurable behavior whether to die/abort or try to limp along if possible. Sometimes you really would rather a service not run at all if there is even any hint of a question about it's configuration. -- bkw ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users