On Jan 19, 2007, at 10:24 AM, Narayan Desai wrote:
This looks pretty exciting. Will it be publicly available in some
form?
sgplan5 is on the web somewhere
(http://manip.crhc.uiuc.edu/programs/SGPlan/index.html)
as for generating the input, i can send you the input files i used and
how i invoked it
if you send me email.
As far as pitfalls, we found that building the appropriate feedback
for reconfiguration workflows was pretty tough. (at least in an
automatic fashion) In your case, you have basically a boolean setting
that you can probe. When you try to extend this to system
configuration workflows, I suspect that you will need to deal with
much more information, due to all of the interdependence included in
system configurations. This is why we targeted overall specification
states as the states in our FSM, and used overall client configuration
state (clean/dirty) as the criterion for advancement.
-nld
this is close to teh nub of the matter.
we spend all our time warping tools to cope with unmanageable objects
and packages.
you need to make a stand and insist on manageability.
this is just like make. i was (and am) an author of a make-like tool
(mk).
occasionally, users would run into a problem with a makefile that
produced bad results.
quite often, it was because some tool relied on side effects, or the
makefile rules themselves
relied on side effects. (it was exacerbated because mk is aggressively
parallel.)
i never relented to their pleas to change mk; i insisted that the path
to happiness
was to TELL THE TRUTH. all these bugs occurred because someone assumed
something
or not al the truth was told. the rare exceptions (like yacc always
producing y.tab.[ch])
were fixed (yacc got an option to put its output under a different
name).
polemics and homilies aside, we need a model of how things behave,
and how we can test for success and failure. and i think the 90/10 rule
really works
here; some stuff will nearly always have to be done manually, but lets
get rolling
on the easier 90%.
----
Andrew Hume (best -> Telework) +1 732-886-1886
[EMAIL PROTECTED] (Work) +1 973-360-8651
AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
