[PRL] Re: "dia" in the gimp?

Richard C. Cobbe cobbe at ccs.neu.edu
Mon Jun 2 09:40:44 EDT 2003


Lo, on Monday, June 2, Greg Pettyjohn did write:

Huh?  Greg, I don't see your point here.  So, I'll just respond to a few
of the minor details that I was able to understand.  If you can restate
the main idea, then we can concentrate on that.

> How many parameters does it take to configure an OS?

Well, how much control over your operating environment do you want?
(Note that I'm drawing a distinction between an OS and an Operating
Environment here.)

I don't know of an operating environment that provides a high level of
configurability and customizability and is `easy to use.'  Perhaps
combining the two is impossible; perhaps not; in either case, it's
probably a good area for research in HCI.

In the Unix case, at least, this is not helped by the fact that Unix
knowledge is, by and large, an oral tradition.  I learned most of what I
know about Unix basics by talking to the upperclassmen sitting next to
me in the labs at Rice.  You're essentially going through a similar
process now, Greg.  (Note that I'm not defending this process, I'm
simply describing it.)

So, there are two ways to find out about this particular parameter.  You
can either do what Mitch did and get an error message, then ask the Unix
guru what it means and how to fix it, or you can pore through the
documentation trying to find out the answer on your own.  Unfortunately,
the documentation is large, often cryptic, and incomplete.  I'm not sure
where in the canonical Unix docs I would find the answer to Mitch's
question.  (The advent of Google tends to make this easier.)

This, obviously, is broken; at the very least, Xlib needs to give you a
better error message.

> Why can't they default to something that works?

For the specific case under discussion (DISPLAY), both ssh -X and recent
versions of telnet do just this.

Using telnet, of course, still requires that you play with the X server
security settings on the local machine, but that's a security issue.  I
don't think you're going to get a consensus on a reasonable default
there, so it defaults to the more secure (and thus less usable) option.

The experience of the Linux community demonstrates that this is probably
the right choice: it forces people to figure out what the security
tradeoffs are and make the appropriate decision.  Going the other way
tends to result in people not knowing about the options, leaving them
set at the (insecure) defaults, and then being very surprised when their
machines get broken into.

Similarly, I think ssh doesn't do X forwarding by default because of
some security issues, but I'm not completely sure of that.

<SNIP>

> The problem is that a typical application has the form:
> 
> (lambda (env ...)
>   (lambda (x ...)
>      ... body ...))
> 
> In this analogy, the parameters to the inner lambda are the things that
> you know about when you conciously execute the program. The parameters to
> the outer lambda are the things that you don't (can't possibly keep track
> of them all...) know about. To make things worse, the env ... can and
> often are mutated *after* the closure is created, or even when the body is
> running! This is why I played with an interpreter that allowed you to
> specify and capture first-class environments. Most of the people I shared
> the idea with said that it would be an unsafe language feature that was
> hard to reason about --- equivalent to dynamic binding.
> 
> So in answer to one of my questions: it is not "just syntax", the OS is
> broken because of *semantics*. The OS uses dynamic binding.

First, I'm a little confused by what `env' in your analogy above is
supposed to represent.  The AVP-list that is typically referred to, in
Unix circles, as the process environment?

If that's the case, then lambda and dynamic binding are not a good model
for this; I think MzScheme-like parameters work better.  When a process
changes its environment, the change is visible only to that process.
And, as with MzScheme threads, when a process forks off a child, that
child gets a copy of its parent's environment, but changes in the
child's environment are not visible in the parent, and vice versa.

If this is not what you're referring to, then could you restate this?

(Oh, and by `dynamic binding', do you mean the same thing as `dynamic
scoping'?)

Richard


More information about the PRL mailing list