Nuclear Irrationality

I was recently thinking about my college studies of nuclear warfare. At the time it seemed like a relevant topic, and I took two courses on it. Like everything, the more you look into it the more complex it gets. The depth of the thinking in nuclear warfare planning was both impressive and appalling.

One of the more interesting cases was driven by the fear of a Soviet invasion of Western Europe. In retrospect we know there was never a danger of that, but at the time it was a real concern. The western strategists feared that in a conventional war, the Soviet tanks would rapidly rout the smaller European armies. The use of nuclear weapons, or at least their potential use, was an obvious way to counter this threat.

However, most of the nuclear weapons were in the U.S. It was clear that no U.S. president would launch nuclear weapons at the Soviet Union in order to forestall an invasion of Europe. The U.S. promised to support Europe, but if the war actually started, a nuclear attack on the U.S.S.R. could only end in a nuclear counter-attack on the U.S. That would never happen. England and France had a few nuclear weapons, but would their leaders really launch them, knowing that they would face certain death in the overwhelming nuclear counter-attack? A bold and calculating leader of the Soviet Union might be willing to risk that nobody would take the nuclear option, and be willing to gamble that they would win a conventional war (again, this was the fear of the U.S. and Europe, the Soviet Union knew perfectly well that they could not win such a war). How could the U.S. and Europe use nuclear weapons as a credible deterrent to a conventional invasion?

The answer was, as I said, both impressive and appalling. NATO distributed low-yield nuclear weapons throughout Europe (they even had nuclear landmines). In the event of an invasion, complete control over the weapons was handed over to local commanders. The decision to use nuclear weapons would not be in the hands of an elected leader far from the war zone. It would be in the hands of a local colonel facing the immediate loss of his command. The Soviet Union might gamble (so the thinking went) on the reactions of a few political leaders they could study closely. They would never gamble on the reactions of several hundred local military commanders. Although the weapons were relatively low-yield, the expectation was that once a war went nuclear, the only thing that would stop it from escalating would be a quick complete cessation of hostilities.

This is a nice example of achieving your goal by explicitly giving up your ability to act rationally.

Comments (7)

Sudoku

I’ve been playing Sudoku on Google+. i’ve more or less mastered the easy and medium levels, but it takes me about 30 minutes to do a hard level, and I haven’t tried expert yet. Sudoku is a fairly dumb game in some ways; as a colleague of mine pointed out, it’s trivial to write a computer program which will win every time. But I find the game somewhat interesting because it mirrors, in reverse, the way I think about programming.

You can write a computer program more or less any way you like. So I tend to think of a program in terms of constraints. Typical constraints are: the desired behaviour; the available runtime; the algorithmic complexity; the available libraries; the language; maintainability; who is going to review the code and what they will accept. Write a program is a matter of finding the simplest solution which meets the constraints. Difficult programming problems are ones where the constraints come into conflict, and it’s hard to see your way through.

Sudoku works the same way, only in reverse. In programming you are allowed to write any code that meets the constraints. In Sudoku you know that there is only one solution, so you have to look for moves that are forced by the constraints. Solving a Sudoku puzzle is a matter of looking deeper and deeper into the problem until you have eliminated all moves but one.

My hope is that practice in this area will subconsciously encourage me to look deeper for constraints when writing code, which will save time in the long run because I will have to throw away less code. I doubt this will actually work, but it seems worth a try.

Also Sudoku is a good way to exercise short term memory, as I’m avoiding writing anything down while solving the puzzle. I used to play cards regularly (bridge, whist) and I was able to remember the location of many of the cards in other people’s hands. I noticed that I lost that facility as I’ve failed to practice it. As i write this I realize that short term memory is not too important in today’s world, but at least it makes me feel smarter.

Comments (4)

Pay Voting

New plan: let’s let people pay to vote. Everybody gets one vote free, just like today. You can also pay, say, $1000 for another vote, then $2000 for the next one, $3000 for the one after that, etc. Also, you can sell your vote, so a cheaper way to get more votes is to pay a bunch of people $500.

Advantage: it’s no longer necessary to give candidates money so that they can advertise for votes. Currently politicians spend at least half their time asking for money. This would let them spend all their time on their actual job.

Advantage: money paid for votes goes straight to the treasury, rather than to television stations.

Advantage: Many fewer horrible political ads.

Disadvantage: politicians do what rich people want them to do. But wait, that is already the case. So this isn’t a disadvantage at all.

The U.S. is already a plutocracy. Making it explicit is more efficient all around.

Comments (6)

Voluntary Foreclosure

The otherwise completely forgettable movie Larry Crowne had one scene I found quite interesting. The eponymous protagonist, played by Tom Hanks in his blandest mode, is presented as an all-around good guy. He is gentlemanly, helpful, considerate, and in fact has no flaws except for the rather minor one which starts the little action there is in the movie: he did not go to college. In college he studies, among other things, economics, in a class taught by Lt. Sulu.

Studying economics leads Larry Crowne to the one interesting scene: he abandons his mortgage and returns his house to the bank. The bank representative warns him that this will hurt his credit, but he assures her that it is the right thing for him to do, and that he has the right to do it, provided he vacates the house in 30 days.

The U.S. is a country which famously agreed to pay all its debts when it was founded—the newly created federal government assumed the debts that the various states had accumulated during and before the War of Independence. In general American culture assumes that you are required to pay all your debts. Declaring bankruptcy is a sign of personal failure.

Apparently the financial crisis, and the stagnation of middle class income compared with the increasing price of housing, has now made it acceptable for a mainstream movie character to renege on his debt. This is of course a calculation that businesses make routinely, but not individuals. Admittedly voluntary foreclosure is not quite as bad as bankruptcy. After all, the bank does get the house, which is worth something although it is clearly understood that the bank does not want it.

Given the current main news story, I just have to hope that this acceptance of foreclosure does not carry over to thinking it is OK for the entire country to go into default.

Comments (2)

CVS SSH

Sorry for the long posting hiatus. I have enough readers now that it’s hard to write the usual random nonsense.

I was recently reminded of an old problem using CVS over SSH, which was an interesting example of various different instances of reasonable behaviour adding up to a bug. It’s possible that this bug has been fixed, but I’ll assume that it hasn’t. The bug is that “cvs diff 2>&1 | less” will sometimes drop data, leaving you looking at an incomplete diff.

When CVS invokes SSH, it sets up file descriptors 0 (standard input) and 1 (standard output), but not 2 (standard error). Thus SSH inherits file descriptor 2 from CVS. This means that any SSH errors get reported to the standard error passed to CVS, which is what you want to have happen. However, when using 2>&1, this means that SSH’s file descriptor 2 will be the same as CVS’s file descriptors 1 and 2.

SSH puts its file descriptors 0, 1, and 2 into nonblocking mode, so that it can use select to send data back and forth without blocking. This means that SSH puts CVS’s file descriptor 2 into nonblocking mode. When using 2>&1, file descriptors 1 and 2 are the same, so this puts CVS’s file descriptor 1 into nonblocking mode.

CVS uses stdio to output data to standard output. When writing to a pipe, the buffer can fill up. CVS naturally never puts the descriptor into nonblocking mode, but when SSH has done it indirectly, and the buffer fills, the data being written will be discarded. This is what causes the bug: the discarded data is never seen by the user.

So what’s the fix? It’s reasonable for SSH to put its descriptors into nonblocking mode. It’s reasonable for CVS to pass its file descriptor 2 to SSH. It’s reasonable for CVS to use stdio to output data. It’s reasonable for stdio to not specially handle a nonblocking file descriptor—any program which wants to use a nonblocking descriptor needs to handle I/O retries itself. It’s reasonable for 2>&1 to mean that file descriptors 1 and 2 refer to the same underlying pipe. It’s reasonable for the user to use 2>&1 when piping cvs diff output to less.

I think the only remaining link in the sequence leading to the bug is that when SSH sets its file descriptor 2 to nonblocking mode, this affects the file in CVS. This is a consequence of the Unix file model, in which file descriptors refer to underlying files. A file descriptor has only one flag: whether it is closed if the exec system cal is run. All the other information is attached to the underlying file. Using 2>&1 means that two file descriptors point to the same file. Forking and execing SSH does not change this–in fact, it adds two more file descriptors, in the SSH process, which point to the same file. Any change in the flags associated with that file is seen by all the associated file descriptors.

This separation of file descriptor and file is what makes 2>&1 work. It’s also what makes >> work; >> opens a file in append mode, and the append flag is inherited by other processes which refer to that file. In any case, what really counts here is not the exec, but the fork; forking a process should not change the flags associated with a file. Further, I’m sure there programs which depend on the fact that changing the flags on a file after a fork affects the file as seen by the parent process.

It’s possible to imagine that file descriptors point to a new shared structure which then points to the underlying file. The file position and some flags would stay with the underlying flie. The new shared structure would just hold some flags which need not always be shared: O_NONBLOCK, O_ASYNC, etc. Calling fork would not create a new shared structure, but calling exec would, copying the existing structure. That would let some flags not be copied across exec process boundaries.

However, that would be a significant change to the Unix file model, a model which has lasted for decades and is not clearly broken. Absent that change, we are left with a complex bug, in which all choices are reasonable.

The workaround for the problem is to invoke SSH with 2>/dev/null, and assume that SSH never writes anything useful to standard error. The 2>/dev/null disassociates SSH file descriptor 2 from CVS file descriptor 2, so CVS file descriptor 1 is not accidentally set into nonblocking mode.

Comments (7)

« Previous Page« Previous entries « Previous Page · Next Page » Next entries »Next Page »