Paul Anderson wrote:
On 12 Oct 2006, at 16:19, Narayan Desai wrote:
Paul, I know that we've discussed this before, but I think that it is
important to mention this in public. I think that greatest weakness of
the current research regimen in configuration management is that
research is completely inaccessible to the vast majority of
practitioners.
Yes, some "research" is. I think this is a fault of the individual
research though. Certainly, to be rigorous, then you might have to use
some math to ultimately prove some point. However, configuration (as we
know it) has an essentially practical end (my "starting with a pile of
boxes .... make a system that does X"). If the research doesn't
contribute to that in some way that is understandable, then I'd say that
it wasn't really on topic.
On the other hand, much of the so-called "practical" work and
"implementation" that goes on is completely impenetrable - tools are
full of obscuring implementation details and the number of people who
understand more than one tool in any depth must be very small (?). I
would find it very hard to be confident of completing the most obvious
of tasks. (I think this is what you are saying about accessibility)
I think what Narayan meant about accessibility is that if the research
is not in the form of a tool that a sysadmin can download and use, then
it's not accessible. Most sysadmins aren't good at theory or
development, so expecting them to turn a research paper into a tool is
too much.
Here's an idea for the workshop ....
What if we take my example task from the SAGE book - "install a new Web
server at your site, replace it when it breaks, and decommission it."
Lets have four talks of 15mins each explaining what you would do using
four different tools. Then let's have a discussion extracting common
themes, difficulties etc ... ?
I think this would be an excellent thread on a mailing list, but I think
it would be too specific for a workshop.
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.
Certainly, there is a lot of theoretical work in this area (and some
work which I think is plain wrong/useless), but once you have a basic
configuration system in place, then your major errors and downtime come
from the kind of mistakes that could be avoided with a system such as
this - its rather like using a compiler which does some basic type
checking, and tells you when you are using, for example, a variable that
is never used ... Of course, if you don't have a reasonable
configuration system, then you have bigger things to worry about ....
I find this bit really interesting -- I'd love to spend time on Puppet's
compiler, doing interesting forms of validation. However, none of
Puppet's users or even the other committers have shown the least bit of
interest in working on the language, because it's pretty far outside
their skillset. If someone's going to add this kind of functionality to
Puppet, I'm the only one who can do it, and I'm only likely to do it if
I find myself with a lot of spare time (hah!) or a customer pays me to
do it, which is also unlikely.
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.
Yes. But things will go badly wrong later on unless you build your tools
on a solid foundation. BASIC is probably an accessible language, but if
you start trying to write an OS with it, you are going to run into
difficulties at some point which you can't really resolve ....
Unix is a pretty crappy operating system, C is a pretty crappy language,
sh is a pretty crappy shell, perl is a pretty crappy language, CISC is a
crappy instruction set type, X is a pretty crappy windowing system; all
of these tools have pretty big flaws, yet our world is built on them and
we haven't suffered horribly.
You can always hack your way out of a problem if necessary. Yes, I'd
prefer not to require hacking, but I'd rather shoot for it and have to
hack some than wait so long that the opportunity passes. I'm expecting
that Puppet's language won't survive for more than a few years, it's
library will get rewritten in a compiled language so it's accessible to
other languages, and most of its client/server systems will get replaced
entirely by someone who actually knows how to do that kind of work.
This doesn't bother me in the slightest, and in fact, I wouldn't have it
any other way.
I'm depressed at how *little* churn there is in the computer world, not
how much, and I hope that Puppet's abstraction layer will help to
*enable* churn, not decrease it.
--
The Roman Rule
The one who says it cannot be done should never interrupt the
one who is doing it.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
