More provocative and highly entertaining Lisp (in this case scheme) propaganda from Shriram Krishnamurthi: download the MP3 and follow along on the pdf slides.

Lately i've been spending a lot of time studying (IE trying to grasp) capability based systems. The basic idea is that each program in a system has a set of capabilities, and can do nothing else in the system (in fact doesn't even know any more about the system) then the capabilities it has. To follow the example used in the soon-to-follow-link, Solitaire has rights to make archives of your confidential email and sell them on ebay, when all it really needs is the rights to write to its window area, and save the highest score for future program executions.

EROS looks to be one of the only active capability based operating systems at the moment. The design is actual quite fascinating, and includes system persistence. (IE: pull the power plug out of the wall, plug back in and return to the state before incident) Unfortunately, the documentation seems to be sparse; several of the more practical parts of how the system works have been more trouble to me then the theory.

Tonight i ran across a colloquium by Mike Miller, Building a Virus-Safe Computing Platform Don\'t Add Security, Remove Insecurity, which filled in a lot of the missing pieces. What follows are some of the high points from the lecture.

• Its informative to notice the subtle difference between two ways of copying files:

  cp foo.txt bar.txt cat < foo.txt bar.txt

  Invoking cp, you tell it what file paths you are interested in, and it is responsible for opening those files. As such it needs all of the permissions that you have, and you have to trust that its not going to misbehave in the zillions of ways that it could. On the other hand, cat is passed two file descriptors--it really doesn't have to have access to anything else to do its job!.
• Capability based systems are reliant on TCBs (trusted computing bases) to delegate access. Each TCB has all the access it needs for the domain its responsible, and passes those rights off to sub processes on a need-to-know/need-to-do basis. Following the cat example used above, the user's shell is a TCB, which has all the rights of the user; it passes rights to read foo.txt and write to bar.txt to the cat process.
• Carefully designed TCBs and UIs can largely be coupled, again as seen in the cat example. So rather then popping up windows asking the user if they want to give such and such applet such and such access (not to mention any names like java), the UI can use the user interaction to provide data needed disseminate capabilities.
• Actually, this is true on a more fundamental level. Capabilities can be passed around in the same way, and at the same time that normal data references (object, whatever..) are passed around. Actually, this is all that is needed for a capability system; any more and any less erode the system. For example, if there are global variables in the system, that is a mechanism for capabilities to be obtain and/or distributed in non-need-to-know basis. Calls such as open(2) are similar in nature in eroding the system.
• Language/system designers usually think about security after they've added features such as mentioned above, and then try to patch things up by adding ad hocishness, rather then removing the impure features.

Combex, the company which Mike Miller seems to be associated with, has a variety of papers and technology that might be of interest.

David McNeill gave an excellent talk titled A Pebble, a broomstick, and the color brown on faith and science, or equally on each person's search for God. Applicable, short, and to the point: definitely worth watching! You can also read the transcript.

Recorded back in the 1980s, but still as relevant as lisp is today, this freely available lecture series, Structure and Interpretation of Comptuer Programs is really a very fascinating and entertaining way to learn about scheme, as well as see some of the enlightening aspects of lisp. This has to be about the only intro-to-programming class in the world which is building a symbolic calculus program by the sixth hour of class!

Regarding Lisp, Sussman offered the following piece of wisdom:

``Lisp is a lousy language for doing any particular problem; what it's good for is figuring out the right language that you want and embedding that in Lisp'' -- Gerald Jay Sussman

The radio had an interesting speech i stumbled across; information that is not getting a lot of air-time: sex has a price tag. While true, that this information is mostly irrelevant if following the Bible, no man is an island, and we are called upon at random times to provide information and evidence to others who are in need of such.

You can listen to the speeches, sex has a price tag, with real audio.

There is also an interesting twist in part one where the speaker gives her personal testimony regarding abortion. That starts around 17.0 minutes into the real audio stream.

Larry Lessig gave an excellent presentation at the Stanford Computer Systems Laboratory Colloquium on Feb 20, 2002. The topic of choice was that of IP and included sub-discussions on topics such as Open Source Software and the entertainment industry.

One very interesting point that is briefly mentioned is the fact that lawyers write code, but by law their code is public domain: anyone is free to draw on existing laws, arguments, etc. for their own benefit, gratis. Why can't software be written in the same way? This very well works with a number of comments made by Tom Lord on the Arch Users Mailing list (See mailing list posts: Arch for package management, Arch for package management II, and business proposal: arch revision control).

The basic idea is that code is free. Todays IT departments are replaced (or rather upgraded) to centers (in-house or out-sourced) which, given a company need, do what it takes to get software to solve that problem. This may be as simple as installing software from an existing project, or modifying an existing project, or creating an entirely new project. This very well solves the question of Won't programmers starve? (See also the GNU Manifesto). Now, just like lawyers, programmers are experts who are paid well to glue together solutions, to stand on shoulders, and achieve the needs of their clients.

Many societal benefits can be seen in this model.

• The cost of entry is low for newly developing countries, poor communities, small businesses, etc.
• Businesses will have software that exactly matches their needs. If they need a word processor, except with a twist, they have it for low cost, rather then trying to make due with what they can get in a box.
• Programmers will be working much closer to their clients problems, thus coming much closer to eliminating the effect of solving problems or adding features that nobody is really interested in.
• Programmers will be doing much more standing on shoulders rather than reinventing the wheel.
• Software updates can be much faster and safer. Right now a big obstacle to installing binary security fixes is often the granularity of them. For instance, some big company fixes a big security whole in their webserver. In the same patch though, they also upgrade some parts of their software and end up breaking some needed features. Using something like the arch-Tech would allow the individual IT departments to review the source code for security fixes, and know exactly what parts of the system will potentially be effected.
• Open Source projects would get much better funding, and the rate of ingenuity would soar.
• With program source code, and an intelligent IT department, companies would not have to be locked into particular sets of hardware, or even combinations of softwares.

Oh yeah, you can view the (obviously inspiring) presentation of Lessig by going to the Stanford University Computer Systems Laboratory EE380 Colloquium Schedule for 2001-2002, searching for Larry Lessig, and clicking on the camera icon found on the right of the line. MPlayer can be used to view the presentation, as documented on the Linux Player for Colloquium Tapes page.