Plan 9

I've been reading about "Plan 9 from Bell Labs" (Pike et al.)

Plan 9 was an operating system developed in the mid 1980s by members of the Computing Science Research Center at Bell Labs. This is the same group that developed UNIX and the C and C++ languages. In essence, the project is radical redesign of UNIX. "The problems of UNIX were too deep to fix," Pike writes. "But some of its ideas could be brought along..."

The filesystem is the heart and soul of Plan 9. Most system resources are accessed and controlled through the filesystem-- even things that have not traditionally been thought of as files. For example, to get information about a process, you look under its "/proc" directory. An application can control its terminal by reading and writing its "/dev/cons" file. The graphical windowing system itself is can be viewed as a file server.

Furthermore, unlike in conventional operating systems, where all processes share the same file system, under Plan 9, each application has its own view of what is going on. When process A reads /dev/cons, it is not reading the same /dev/cons that process B is reading. As Pike writes, "the disjoint hierarchies provided by different services are joined together into a single private hierarchical namespace."

Plan 9 has a single protocol for dealing with filesystems, called 9P. This has been extended to allow network filesystems, which make files on a remote computer look exactly like local ones. Since the window system itself is simply a file server, there is no need to implement anything like an "X server"-- 9P fills this function!

Plan 9 abolishes the old distinction between processes and threads, opting instead to give users more options about what resources processes can share. There are also some other new things in the OS, like a new shell called RC, which tries to improve on the Bourne Shell.

As an engineer, I feel a little bit sad that Plan 9 has not had more influence. I am typing this from a linux system. Most of my friends use UNIX in one way or another, but nobody uses Plan 9, and few have heard of it. Perhaps the problems in UNIX were not as deep as Pike thought. And here's another thought: at the time this paper was published, around the mid nineties, a very different operating system was taking root-- an operating system named Windows 95. What would the folks at Bell Labs, in their quiet, meticulous academic environment, have thought about this one?

There are some other Plan 9 innovations that have found their way into linux, and perhaps other operating systems, over the years. For example, linux has the /proc filesystem for getting information about processes, and the /sys filesystem for digging up stuff about the system. NFS, the network filesystem, and SAMBA, are distributed filesystems that may not be as clean as 9P, but which get the job done.

Ironically, the main Plan 9 invention that is in use today is a UTF-8, a way of representing unicode text. Ken Thompson created UTF-8 to be the native character encoding for Plan 9-- and it is used throughout the whole operating system. UTF-8 is popular because it is somewhat backwards-compatible with existing C string libraries, and because it sidesteps endianness issues.

As bold as Plan 9 was, it still stopped short of a full design of UNIX. I would like to see an operating system that has a strongly-typed shell, and is based on capabilities rather than on privileges. But I guess change comes slowly sometimes.

Some perspectives on Information Security

This paper by Ross Anderson gives an economic perspective on why information security is hard. It talks a little bit about the security of bank teller machines, computer networks, and web sites. Along the way, it makes some really insightful comments about the information economy in general.

"In general, when the party who is in a position to protect a system is not the party who would suffer the result of security failure, then problems may be expected," Anderson writes. This may sound obvious, but if you think about it, there are quite a number of systems in use today where this is the case. Some would argue that the widespread incidence of identity fraud today is a result of such perverse incentive systems. An identity thief ruins the credit rating of the person whose identity he steals, NOT of the bank or credit card company whose lax security allowed the attack to happen in the first place!

Anderson then spends some time discussing economic pressures that lead to insecure systems. He begins by talking about "network externalities" and Metcalfe's Law. Basically this law states that the more people use certain networks, the more valuable the networks become for everyone. For example, "the more merchants take credit cards, the more useful they are to customers, and so more customers will buy them... and the more customers have them, the more merchants will want to accept them." In my opinion, this is almost the guiding principle behind the rise of Microsoft and many other computer companies. Popular technologies tend to get more popular, even if they aren't perfect. Customers get "locked-in" to using a particular technology because of the high cost of switching technologies.

Given all these network externalities, Anderson continues, software companies have a huge incentive to get products out the door quickly, even if that means sacrificing security or stability. In many cases, a rational manager will not want his product to ship later than those of other companies, even if waiting would make his product better.

Companies often use a proprietary, obscure architecture instead of a standard, well-analyzed and tested one. This helps to promote lock-in, and also make differentiated pricing possible. In short, differentiated pricing is when a company prices its product not on its cost, but on its value to the consumer, in order to optimize profit. "This is familiar to the world of air travel," Anderson writes: "you can spend $200 to fly the Atlantic in coach class, $2000 in business class, or $5000 in first." Obviously, it doesn't cost the airline $1800 more to seat a business class passenger than a coach class passenger. But by pricing this way, they can optimize their profit by charging each customer what he can afford to pay, rather than the true value of what he is being sold.

In this context, "digital rights management" schemes start to seem even more sinister. By promoting even more customer lock-in than is currently the case, DRM would allow companies to engage in even more differentiated pricing. This has already happened: one of the first DRM schemes to see the light of day, the CSS scheme which protects DVD movies, was designed to allow movie studios to price movies differently (and release them at different times) in different parts of the world. That is the function of the so-called "region codes."

Anderson then moves on to discuss some peculiarities of information technology itself. The technology favors attack over defense, he maintains, because even if "white hat" security consultants find 100 times the bugs that a lone "black hat" hacker finds, the hacker might only need one bug to compromise the system! "Defending a modern information system can... be likened to defending a large, thinly-populated territory like the nineteenth-century Wild West," he comments. "The men in black hats can strike anywhere, while the men in white hats have to defend everywhere."

The politicization of information security only makes this situation worse. Government agencies engaged in economic intelligence missions have every incentive to use security bugs to spy on foreign nations, and little incentive to fix the bugs. Unless people are aware there is a security problem, successful fixers seldom get credit, while successful attackers always do.

In my opinion, this is only a specific example of a broader phenomenon where doing preventive maintenance on systems often earns you little respect, even if the maintenance is vital. Before Hurricane Katrina, how many voters in New Orleans voted for politicans based on their record of strengthening the levies? Voters are seldom aware of the most important things that politicans do for them; instead, they focus on media circuses and talking points which are of little real consequence.

Anyway, to continue: there are other reasons why information technology buyers often don't get a secure system. They may not be knowledgeable enough to evaluate the system that they are buying. Security certifications often mean little, and, at least in the past, most companies had little in-house security know-how. (Maybe this will improve in the future.)

I should finish with Anderson's conclusion.
In an ideal world, the removal of perverse economic incentives to create insecure systems would de-politicize most issues. Security engineering would then be a matter of rational risk management rather than risk dumping. But as information security is about power and money ­, about raising barriers to trade, segmenting markets and differentiating products, the evaluator should not restrict herself to technical tools like cryptanalysis and information flow, but also apply economic tools such as the analysis of asymmetric information and moral hazard. As fast as one perverse incentive can be removed by regulators, businesses (and governments) are likely to create two more.

swimming pools + Linux

"Swimming pool control with Linux" puts together two technologies not normally associated with one another.
Richard Kinch, the inventor, lists the following reasons for using Linux to control his pool:

Reduced effort to manually check and treat chemistry. While Version 1 runs "open loop", having no sensors to use for "closed loop" operation, pool chemistry is predictable enough to be manageable in that form.

Saving money by running the circulation pump and chlorine feed only during ephemeral mid-daylight hours rather than a dumb timer's fixed, daily schedule. This requires the sophistication of PC software to know the present date and time, to compute daylight hours, and to sequence the interactions of various pumps. The equivalent function in a programmable astronomic timer costs about $700, such as this unit made by Intermatic. (Update: In 2004, Intermatic had available an wall-outlet version, the "SS8 Self-Adjusting Digital In-Wall Timer", specs here.) Solar cell daylight sensors cannot be used for this purpose because they cannot predict when the sun will set.

Heh. I can't think of any disadvantages to using shell scripts to control the feed of chlorine chemicals into a pool that you are using. What could possibly go wrong?
Of course, according to the inventor, "the chemical feed rates are limited and cannot rapidly overcontrol the chlorine or pH if they were to be 'stuck on' from hacking or system problems."

There's also a kind of hard-to-follow discussion about the chemistry of swimming pools. Apparently Kinch is very much against the use of "cyanurics" which are supposed to make chlorine solutions more managable, but which he claims make them much more ineffective.

There's some discussion of electronics as well. I'm surprised his original system didn't use optoisolators to isolate the parallel port of his computer from the outdoor cabling. I thought that was standard practice for systems like this. To be fair, he mentions that he would like to do this in the future.

I think it would be much better if the system were a closed-loop system, though. (A "closed loop" controller responds to changes in the thing it's controlling, rather than operating "blind.") A closed-loop system would know what the current condition of the pool was, and so could decide how much chlorine to add based on that, rather than just on a preset schedule. Also, it could alert the operator to potential dangerous conditions. I guess the main obstacle is how tremendously expensive automated pool sensors are.

There's a great potential for systems like this to control everyday things presently controlled by hand, like light bulbs. Combined with wireless technology, this could be pretty easy to install, and would save a lot of energy. I think I remember reading about a project related to this at Microsoft... I'm too lazy to dig up the link right now, though. I wonder if these systems will ever be widely accepted in households. Maybe if the price of energy goes up enough.