futz f&ts v.i. To tinker experimentally; to change something just to see what it does.
Getting things done with today's computer systems requires a lot of futzing. This is both expensive and aggravating. The mission of the No-Futz Computing project is to learn how to build general-purpose computer systems where less tinkering is required.
In 1999, the OS researchers at HotOS identified "futz" as the most important problem facing the community. Progress since then (as of late 2003):
...and read our paper from HotOS 2001 that discusses the research agenda for no-futz computing.
This is the general case of the way systems must be handled today. When you install a system, or it stops working, you have to update its configuration. Even though you may have a fairly good idea of what you want the system to do or how you want it to behave, there usually isn't any way to express that directly. Instead, you must change the configuration — experimentally — until the observed behavior appears to match your expectations.
Usually, there isn't any easy way to predict what change you need to make. Sometimes, the thing you need to change may be hidden off in a corner someplace. In many cases, the state variables that you might need to adjust are deliberately hidden from you: the system designer, in a futile attempt to make the system "easy" to use, has buried switches and knobs that really need to be accessible.
Experience with a particular system can streamline this process. By the time you've configured 3-4 PCMCIA network cards in Red Hat Linux, for instance, you have probably learned what the trick is, and doing another one will usually be straightforward. Unfortunately, most users only have one system to fiddle with (their own) and so they only ever do these things once. If they have to fiddle with the same thing again, it's probably months later and they've forgotten the details.
Worse, even in the general case, such knowledge is deeply platform-specific: network configuration in Red Hat may not even transfer effectively to Debian, much less to FreeBSD or Solaris... let alone Windows.
State management has received little attention from researchers until recently.
These approaches do not generalize.
In our HotOS paper we went through a bunch of state we found on our systems and classified it. Based on what we found, and later experience, we believe that the problem is tractable.
1. Identify and eliminate state that
2. Represent state in its natural form. State should not be represented as computation. It is not necessary or appropriate for the configuration system to support Towers of Hanoi or other programs.
Programmable state is useful when a (sub)system is new and its operating environment not clearly understood yet. However, the general purpose computer system, and most of its components, have developed to a state of maturity where this should no longer be necessary.
3. Catalogue the system state. Once the gunk has been flushed out, it's important to get a complete inventory of everything. As we argued in our paper, working on just a subset of the state doesn't get you anywhere, because it's not clear that the "proper" structure of the subset will or should remain unchanged when the rest of the state is factored in.
4. and 5. Orthogonalize and decompose the state. Just how one does this properly (other than "have a smart person look at it for six months") is one of the key research questions facing us.
We think programming-by-contract, if applied at the system level rather than at the subroutine level, has promise for helping to keep subsystems separate.
How do we know we've succeeded?
FutzMark f&tsmärk n. a unit of measure that indicates the "futziness" of a system.Derived from:
The time to act is now!