>>>>> "Sanjai" == Sanjai Narain <[EMAIL PROTECTED]> writes:
Sanjai> Logic-based languages are great for expressing complex Sanjai> constraints arising in system administration. However, it is Sanjai> also considered axiomatic that system administrators will Sanjai> never use such languages. The reason given is that they Sanjai> require too much mathematical training. I would like to Sanjai> challenge this view. What is so hard about logic? Everyone Sanjai> knows Boolean constraints. First-order logic is simply Sanjai> Boolean logic + quantifiers. This is adequate for specifying Sanjai> a very large class of constraints. If system administrators Sanjai> can handle complexities of procedural languages like Perl, Sanjai> then surely a declarative language like FOL should be a Sanjai> breeze, shouldn't it? In particular, I think we should stop Sanjai> trying hard to sweep FOL under the rug of GUIs. Even if we Sanjai> could create a GUI in which one could express all of FOL, it Sanjai> would be so cumbersome that it would be much easier to use Sanjai> text. What do you think? Well, I disagree about the issue with FOL. It isn't so much that FOL is hard, rather, that there can be substantial semantic distance between the specification and results. The larger this distance is, the less intuitive the system is. The other factor that has bearing on this issue is the lack of uniform global knowledge about large environments. We've had serious issues with previous generations of tools where seemingly localized changes had far-ranging results. In most environments, there is one lead who knows most of the details, but others usually deal with particular subsystems or architectures. All of the folks with more localized knowledge are far more likely to make changes that affect the environment (and hence other admins) in unexpected ways. Another aspect of this equation is fear; gaining trust in any new tool is hard and time consuming. The more abstract and powerful the tool is, the longer and harder this process is. At the same time, we have a boolean logic engine in the core of bcfg2. This has made the tool harder for some users to understand initially, but there have been a few things that we've been able to do to speed the process along. We've added diagnostic tools that expose specification results to admins in a sandboxed environment and tools that show misconfiguration/reconfiguration patterns when things go wrong. I am not sure if these would be sufficient were we to extend the bcfg2 internal system to FOL from boolean logic; we would have to try it and see... -nld _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
