These are a little late, but better late from never. The one on the left is Cindy and her nephew Eli. This is the last picture taken with my Minolta DImage X20 before it died. The one on the right is the egg left for us by the Easter Platypus on Sunday.

EliEaster Platypus egg


Tech Central Station, everyone’s favorite front for a lobbying firm, has published a particularly egregious article called The Absurdity of Egalitarianism. There’s so much wrong with this piece as an argument against egalitarianism that I won’t even dignify it by addressing it as such. However, it does have value as an excellent example of the low-down tactics employed by the laissez-fairies, so that’s where I’ll focus my attention.

Let’s start with the illustration. What people or symbols would you choose to represent egalitarianism? Maybe you’d choose some of the leaders of the French revolution, who made the word part of a national motto, or the folks who subscribed to “all men are created equal” in the American revolution? None of them make an appearance in the TCS illustration. Instead we get Robin Hood (fair enough), Karl Marx (barely acceptable), and two guys in hooded sweatshirts – one with his face completely covered to represent terrorism and the other looking distinctly scruffy and pointing a gun to represent crime. The implied message, of course, is that egalitarianism is the philosophy of terrorists and criminals. Nice touch, huh? Let’s move on to the text.

Egalitarians believe that inequality is unjust and justice requires a society to move steadily toward greater equality. This is the aim and the justification of proportional taxation, affirmative action, equal opportunity programs, and of the whole panoply of anti-poverty policies that bring us ever closer to the socialist dream of a welfare state. These policies cost money. The egalitarian approach to getting it is to tax those who have more in order to benefit those who have less.

Notice how, in the very first sentence, the author fails to distinguish between equal opportunity and equal outcomes. As one reads through the rest of the article it becomes very clear that his arguments are against equal outcomes – a goal that very few believe in – but are presented as applying to equal opportunity as well. This particular strawman is a favorite of anti-liberals, and deserves to be noted up front as it affects how the remainder must be interpreted.

The absurdity of this is that egalitarians suppose that justice requires ignoring whether people deserve what they have and whether they are responsible for what they lack.

This is an even more blatant strawman than the first. ‘Nuff said.

Here is a consequence of egalitarianism. According to the Statistical Abstract of the United States, men’s life expectancy is on the average about 7 years less than women’s. There is thus an inequality between men and women…Egalitarians, thus must see it as a requirement of justice to equalize the life expectancy of men and women.

Thus begins a far more elaborate kind of strawman. The author is trying a form of argument known as reductio ad absurdum, in which an argument is followed to its logically necessary conclusion to show that flaws in that conclusion represent flaws in the argument. This is a perfectly valid tactic but, when the conclusion is not in fact logically necessary, it can turn into a slippery slope fallacy. In this case the attempt turns into a slightly different fallacy, as we’ll see shortly.

Can egalitarians avoid these absurdities? They might claim…It will be said…They may say

Here we see a prime example of disproof by fallacy. The author makes several half-hearted attempts to answer his own argument – half-hearted because he has, after all, no real desire to find a compelling counterargument. Having made a pretense of answering objections, he then concludes that no valid objection could exist…as though the objections he mentions are the only ones possible. This is similar to claiming that just because he can’t run a mile – not that he tried very hard – nobody else can either.

Suppose that egalitarianism is seen for what it is: an absurd attempt to deny in the name of justice that people should be held responsible for their actions and treated as they deserve based on their merits or demerits.

The more subtle disproof by fallacy complete, the author now returns to the more blatant strawman from before.

anyone committed to justice will want people to have what they deserve and not to have what they do not deserve. Innocent victims do not deserve to suffer, yet they do. A decent society should do what it can to alleviate their suffering. But this has nothing to do with equality or egalitarianism.

This time the fallacy is known as poisoning the well. “A decent society…” sets a moral standard, and then “this has nothing…” deliberately excludes egalitarianism from that standard. What he’s trying to say is that by definition egalitarianism goes beyond what a decent society would do, so that only beliefs not connected with it need be considered. This attempt to control the debate by appropriating terms and definitions is another favorite anti-liberal tactic.

There you have it: prejudicial imagery, conflation, strawman, disproof by fallacy, poisoning the well. Does Mr. Kekes provide any actual proof that egalitarians believe what he claims they do? Of course not. Does he provide any actual proof that opportunity – the real object of egalitarians’ interest – is reasonably well distributed? Again, of course not. Does he provide any actual explanation of how his favored policies ensure the equality he claims exists, instead of driving ever greater levels of inequality? Strike three. Such failures become more understandable when one realizes that Kekes isn’t even trying to provide a valid argument. Rather, his goal is to create a context in which he can call beliefs contrary to his own “absurd” as many times as possible – 11 in all, in such a short piece. That’s the real anti-liberal talking point that readers are supposed to use. He’s providing sympathetic readers not with an actual argument, but with a word that they can use to smear opponents and get under their skin. All of that false logic is really being presented only to promote use of a one-word insult. Expect to see “absurd” used more by anti-liberal demagogues in the coming weeks.


I think this puzzle is actually impossible to solve, based on the reasoning described here. Can anyone prove me wrong?

One Little Thing

One of the first rules of having a status web-page on the net is that it must be kept current. Verizon is a particularly bad violator of that rule. Right now, about a quarter of the net seems unreachable – obviously not including this site. Last week we had a similar routing problem in the middle of the day. Nevertheless, Verizon’s status page says everything is fine. In fact, as near as I can tell they have never admitted to a problem in my area. They do report a few problems (e.g. recently in Florida and Georgia) so I just have to wonder: how big a problem does it have to be before they’ll report it? If an entire city is off-line for half a day, does that make it onto their status page, or does that fall into the “not a problem” category for them?

Subservient Chicken

I just don’t know what to make of this. Is it a cool exercise in language processing, or a guy in a chicken suit getting instructions from off-screen, or just the creepiest ad campaign ever?

Ahhh, Spring

As I walk around from my car to the front door at work, few things can put a smile on my face as much as hearing and then seeing a red-winged blackbird in the tree right out front.

Rationale for Stack Ripping

Last night, after dealing with the latest piece of gcc nastiness that I have to deal with in my stack ripper, I got to wondering whether the whole effort was really worthwhile. Compiling the ripped code is a bit of a pain, and then it’s very hard to recognize or follow in a debugger. Why not just use plain old threads? It’s a very reasonable question. I’d have to say that in many cases people should use plain old threads. However, there are reasons why stack-ripping might be more appropriate at least in some situations.

  • One thread per connection is simply too limiting. Any serious generic server infrastructure must be prepared to track context per request, not per connection, and handle very large numbers of concurrent requests.
  • In a 1:1 threading model depending on OS threads, each thread has to have its own kernel stack and other associated data structures, which can become a serious issue if you have a very large number of threads corresponding to requests. There is also a non-trivial performance penalty, no matter how hard the Linux folks pat themselves on the back for their supposed brilliance.
  • A lightweight N:1 user-level threading model, such as one might implement using the ucontext or signal-stack methods (reference), doesn’t have the same performance problems, and does allow the user to set the per-thread stack size, so that might seem like an ideal approach. However, the stack size in any threading model needs to include not only the context for internal functions but also for any library functions it might call. Do you know how much stack space printf – which you might well be tempted to use for debugging output – consumes, for example? Many times you’d be surprised. The stack overhead for library functions is problematic both because it’s unknown and because it’s potentially too large to be acceptable for very large numbers of threads. Ripped code associates the internal context with the request, but borrows the stack of the executing thread for library calls.
  • N:1 thread models are also incapable of using multiple processors effectively, whereas it’s trivial for ripped code to do so.
  • In some environments such as kernels or embedded systems, the sorts of stack manipulation necessary to implement any kind of threads might not be possible or safe. It has always been one of my primary goals to have a method that can be used even in those environments, which is definitely true for the stack ripper but highly questionable for threading.

As I said in my main server-design article, “mildly parallel” applications aren’t really my primary concern and models which only work on one processor are lame. For those types of applications it hardly matters what your infrastructure looks like. For a really serious server, though, the stack-ripping approach still seems to have an advantage. It can use multiple processors, its resource usage is very conservative so it scales well to very high concurrency levels, it preserves the essential benefit of expressing complex logic as sequential code instead of having to break it up into a plethora of event handlers with explicit state, and it’s still applicable to kernel or embedded code. The only real drawback is that the generated code is hard to read or step through in a debugger. The first shouldn’t be an issue because only a compiler should really need to read it anyway. With regard to the second, I offer an observation. If you can afford to sit in a debugger and step through code, you’re obviously not dealing with a timing problem or worried about performance. If that’s the case, you can run the original unripped version of your code in a threading system; the block() pseudo-function that the ripper uses to recognize blocking points is very closely analagous to a yield() call in a user-level threading library. Once you’re done debugging your code that way, you can go back to building the semantically-identical ripped version for performance.

Ripper Update

I decided to write a (slightly) more realistic example for my stack-ripping program. It’s a server for a protocol called JTP (Junk Transfer Protocol). All it does is get/put of arbitrary-length pieces of binary data into numbered slots on the server, with practically no error checking or reporting. However, the server is more sophisticated than the protocol, because that’s the technology it’s supposed to illustrate. The front end is a pretty generic poll loop, both accepting connections and checking whether they’re ready to read or write. The stack-ripped back end uses a single request to represent an entire connection which might include multiple transactions. Non-blocking I/O is used throughout, with the back end returning when it needs to and the front end redispatching the connection/request when I/O becomes possible again.

While writing the example, I had to make a few more tweaks to the stack ripper itself. The most serious has to do with the incredibly nasty way gcc handles certain pointer operations. Usually it handles the C arrow operator as “(*x).y” which is not too bad, but every once in a while it turns it into “x+(t *)k)” instead, where k is the offset of the field within the structure. Similarly, it sometimes turns an array reference “a[b]” into “a+((t *)(b*k))” where k this time is the size of an array element. In either case it ends up adding two pointers of potentially different types together as though they were integers, without scaling by the size of the underlying type. Without recognizing this and handling it specially, the ripper would generate code that either doesn’t compile or that returns the wrong value for this kind of expression. I think I’ve found a way to handle these constructs without risk of mangling perfectly valid user-written pointer expressions, but it certainly turned out to be more difficult than it seems it should have been.