>>>>> "Paul" == Paul Anderson <[EMAIL PROTECTED]> writes:
Paul> Yes, some "research" is. I think this is a fault of the Paul> individual research though. Certainly, to be rigorous, then Paul> you might have to use some math to ultimately prove some Paul> point. However, configuration (as we know it) has an Paul> essentially practical end (my "starting with a pile of boxes Paul> .... make a system that does X"). If the research doesn't Paul> contribute to that in some way that is understandable, then Paul> I'd say that it wasn't really on topic. The real question is, understandable to who? I don't think this statement really holds. For example, we experience poor performance from compilers on several systems at our installation. We know we have compiler problems, and are interested in the solutions to them. There is a huge body of active research in compilers right now, as there has been for quite a long time. Our most interested computational scientists (as opposed to computer scientists) are interested that (a) the research is occurring, (b) that the compilers are improving, and (c) how to use these advances to make their codes perform. (a) and (b) both amount to knowledge that work is being done. (c) isn't nearly as detailed as understanding the state of the art in compiler research; rather, users must just understand how to make the code easier for the compiler to optimize with new techniques. Users shouldn't need to have a deep knowledge of the research in order to gain benefit from the resulting improvements. I think there are two discrete audiences. There are researchers; that includes all of us, even if there is not active research occurring. These are people who are interested in the state of the art, and potential future advances. The second group is composed of practitioners. These are people that are interested in the state of the art, but only if it can be readily put into practice. Neither of these groups are completely distinct, most of the researchers are at least peripherally involved in the practice. Feedback from practice is critical to the research. Neither can occur in a vacuum. As you've pointed out, the theory is important to building tools that won't cause serious problems later, so a completely "pragmatic" approach is bad as well. Paul> On the other hand, much of the so-called "practical" work and Paul> "implementation" that goes on is completely impenetrable - Paul> tools are full of obscuring implementation details and the Paul> number of people who understand more than one tool in any Paul> depth must be very small (?). I would find it very hard to be Paul> confident of completing the most obvious of tasks. (I think Paul> this is what you are saying about accessibility) I don't think this is accurate. I would guess that most of bcfg2's user community (70%+) consists of people who are competent in one or more other tools, including lcfg and puppet. I actually got a question at one point including a trace from a system named lcfg-test ;) You're completely right; this is one of the accessibility issues I was talking about. Tools _must_ be completely transparent, or problems quickly occur. Paul> Here's an idea for the workshop .... Paul> What if we take my example task from the SAGE book - "install Paul> a new Web server at your site, replace it when it breaks, and Paul> decommission it." Lets have four talks of 15mins each Paul> explaining what you would do using four different tools. Then Paul> let's have a discussion extracting common themes, difficulties Paul> etc ... ? I think this sorts of comparisons have too tight of a focus to be useful. I think that a day in the life comparison would be much more interesting. These are where the real differences between tools spring out, in my experience. >> Most of the current work in autonomics, as well as Sanjai's >> excellent work in modelling and verification, are so complex that >> only sites that absolutely require them can possibly consider >> their use. Paul> Certainly, there is a lot of theoretical work in this area Paul> (and some work which I think is plain wrong/useless), but once Paul> you have a basic configuration system in place, then your Paul> major errors and downtime come from the kind of mistakes that Paul> could be avoided with a system such as this - its rather like Paul> using a compiler which does some basic type checking, and Paul> tells you when you are using, for example, a variable that is Paul> never used ... Of course, if you don't have a reasonable Paul> configuration system, then you have bigger things to worry Paul> about .... You're completely correct. These techniques show a lot of promise 2-5 years out. Most practitioners cannot employ them, so are disinterested in them. >> If we ever want the world to catch up, we need accessible tools >> now, so that practice can start to catch up with the research. Paul> Yes. But things will go badly wrong later on unless you build Paul> your tools on a solid foundation. BASIC is probably an Paul> accessible language, but if you start trying to write an OS Paul> with it, you are going to run into difficulties at some point Paul> which you can't really resolve .... Yes, you are absolutely correct. We can't built tools on unsound foundations, but tool building is similarly uninteresting to many practitioners. I think it is a good idea to have two workshops; one research/tool design focused, and one practice focused. Many of us would attend both, but would be urged to keep the discussion focused on the topic at hand. I think this approach would result in both types of focused discussion, sufficient communication, and better traction in the practitioner community. -nld _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
