association-list

I was bored tonight and procrastinating, as per usual, so I decided to toy around with some simple simulations. The subject for these experiments was taxation, which I’m sure everyone and their dog finds wildly exciting, but these kinds of things are important, and if my life was exciting I wouldn’t be writing simulations.

The setup is this; take some fixed number of individuals, toss them into bins according to a normal distribution (Likely too narrow, really, as a lot of them end up empty. Might need to raise my sigma?), then crudely apply the effects of income, inflation, taxation, random chance, etc. The taxation comes in two modes. Progressive, rising steeply towards the top, and flat for income and capital gains. I eyeballed the curve for progressive, since I didn’t want to calculating each time, and I was too lazy to calculate it in the first place. Rates are 95% for the top bracket.

Some stats:

• Twenty bins in 5000 unit increments, starting at 20000.
• 10000 + 0-10000 starting investment capital.
• 10000 unit tax brackets (at the start).
• Inflation fixed at 4% per year, and brackets scale with it.
• Yearly wage increase is inflation +- 2%, with a 5% chance of losing or gaining 0-10% to simulate job changes.
• Capital gain is 5% if your capital is below a certain point, 8% above that, to simulate incredibly crudely that if you have more money, you have access to a better class of investments. Also there is a 10% chance of losing or gaining 0-20% to simulate above or below average years.
• No one ever dies or has major life changes.
• Income is the sum of your post-tax wages and post tax investment capital for bracket calculation purposes.

Initial results are what you would expect, if you’re reasonably familiar with the theory. Flat taxes tend to spread people out over time, eventually popping people off the top of the simulation and dropping them off the bottom.

Progressive taxes tend to squeeze people towards a stable middle, with outliers being fairly quickly corrected. It’s critical to lock the brackets to inflation or everyone falls off of the bottom in short order.

Observations:

• Capital tends to vanish if you have very little of it to start. At first, I started each person with 0-20000 unit of investment capitol. After a few thousand iterations, the vast majority of people had nothing. I’m fairly sure that this is a modeling issue.
• Programming to learn something new is a great way to remember why you started doing it in the first place.
• This is likely the least interesting post I’ve ever done. I haven’t defamed a single person!

If anyone is interested in looking at the code, or has a suggestion for refining the model, drop me a note. I’d have to clean the code up a little, but it’s not shamefully messy.

Thesis

Lately, in addition to spending more time writing fiction than reading it, I’ve been studying Haskell, a programming language. Familiarity with Haskell in this case is not really necessary, as the theory that that I’ve been formulating while comparing Haskell and Lisp has little to do with the practice of programming. This might be old hat to old time programmers, but I’ve never seen it formulated in quite this manner before. People often talk about ‘power’ and ‘expressiveness’, when talking of high-level languages like Haskell and Lisp, but I wonder if this isn’t missing the point, or expressing the correct point in a way that obscures what’s really going on. I’ve begun to think about programming as having two parts, Logic and Implementation. This could be extended to have a third level, Runtime System, but even then, I’m thinking of the Runtime as parts of the Implementation that are so popular and useful to users of a given language that they’ve calcified into the substrate of that language; there is a level at which this distinction is important, however, and that is compatibility. The thrust of the argument that I’m putting forward is this: The looser the coupling between the Logic and Implementation in a particular programming language, the more powerful and expressive that programming language is. Which is to say, for those of you who abhor semi-circular definitions, the looser this coupling is, the easier the language is to use for truly wizardtastic (technical term) uses of computing power.

DWIM, ye beastie!

At its most basic level, programming is the task of telling a computer what to do. Ideally we’d be able to tell a computer to ‘log all the incoming connections to port 1337 and sue the sender’ or ‘reply to all the wfm postings on craigslist with that picture of Brad Pitt with my face’ or just ‘fix that shit!’. It doesn’t work that way, fortunately, which is why the rest of you pay those of us who can so very much money. So in getting a computer to do something, you have to tell it what to do (Logic) and how to do it (Implementation). In most languages, telling the machine these things are so entangled that they’re essentially the same step. In C, programming is the process of telling the machine in really fucking small, fiddly steps, do a then do b then do c with a and b.blerg. I make it sound horrible, but it isn’t. C is a great implementation language. It’s a terrible language for expressing high level program logic in a modular way, though, because there is no clean separation between what you’re doing and how you’re doing it. In C, you are what you do. This is fine for prototyping, but it’s a pain in the ass when it comes to refactoring and maintenance. If, in a C program, something that we’re doing is too slow, we actually have to visibly change what we’re doing to alter what should rightly be an implementation detail.

This is not to say that you cannot create this separation in C or any of the other languages out there. They’re all Turing complete and can all do the same things. The problem is that you have to think about it all the time, which means that you’re spending less time thinking about more important things, like how that obscure corner case on multi-core machines could really bite you when a switch port starts to flap, or whether the attractive person in the office across the hall is available this weekend for a date. Not having to think about the separation between what and how means it’s easier to design the system in a way that the Implementation is as orthogonal as possible to the Logic, meaning that it’s easier to chunk it up and give different parts to other people, or to improve performance without having to alter your understanding of how the entire system works. The ultimate expression of this is moving to a compiler that’s smarter about how it does things, and then turns out faster code without any effort on your part, but it functions on the applications level as well.

I would argue that it also makes it easier to reason about parts of your program as well. Not in the high level, formal correctness reasoning type of way, but just to break it into chunks and move them around in your head, thinking of new ways to solve problems, or better ways to do what you’re already doing. There’s nothing magic about this. The brain (oh, here he goes, appealing to science…) can only hold so many parts of a complicated problem at any one time. So the coarser chunks you can break a problem up into, while still being able to usefully think about the way that they interact and interrelate, the better off you are.

Additionally, I would like to put forward that OO-type implementation hiding isn’t really a useful exemplar of this strategy all on its own. This may have nothing to do with what it’s capable of and more to do with the way that it is used, which seems to me to be overly focused upon code sharing and ‘defining good APIs’. I am an OO skeptic in general and I don’t think much of code sharing as a target in and of itself (’First, order within. Second, order within the familiy…’).

How I think it works.

In Lisp, you have macros. Not like crappy C preprocessor macros that take code as input and return text to be parsed, but functions that take ASTs and then can manipulate them in arbitrary ways. A trivial example is something like with-mutex which you pass a chunk of code, presumably containing stuff that pertains to the mutex that you’ve grabbed. The macro then grabs the mutex that you’ve specified, executes the code that you’ve passed in, and releases the mutex. More complex uses loop a deeply complex mini-language within Lisp having to do with simply expressing really hairy looping constructs. It’s code that writes other code.

In Haskell, you have monads. Disregarding their category theory use, monads are a really clever way of abstracting away state changes in a purely functional language, which otherwise does not allow the mutation of values. A monad returns actions which then can be taken by a program, which may then alter the program’s state. Examples include IO, parser state, and most of the other interesting things that you want to do with a program. It’s code that expresses actions in a packagable, cleanly reusable way.

Although their implementation could not be more different, I say that these two mechanisms are doing more or less the same thing, which is enabling the separation of what you’re doing from how you’re doing it. They’re both often cited as things in these languages that are hard to wrap your head around, which I think stems from the fact that this separation isn’t always an easy one to make, at least on the level of thinking about a program. Once you get it, though, they seem almost like magical tools, allowing you to act as if your language arbitrarily powerful primitives. You can define things that act like new control constructs or operators. This is a huge win because once you have them right you don’t have to think about them anymore. On the flip side, if I need to change something about how something is done, either for robustness or efficiency, I can change it in one place, without having to worry about the rest of the program. We, as programmers, like to think of ourselves as smart people, perhaps uniquely skilled, but it all comes back to our limitations. The smaller bits of the program that we can work with, the better we are at it.

This, I would argue, is why more excellent programmers are drawn to languages with these properties (lest I be accused of arrogance, I am explicitly not an excellent programmer. I am, however, quite good at learning from the mistakes that other, smarter people make). It allows them to elide away the niggling details of the huge problems that they’re hacking away at, building a structure for reasoning more effectively about the problem that they are trying to solve. Paul Graham has talked about bottom up programming, which, I suppose is the root of the ideas that I’m trying to express here, but I think that it’s useful to re-express the process as defining what you’re trying to do, then defining how to do it, which sounds top down, but which has a lot of bottom-up parts, mostly because if you find that the way that what you’re doing is wrong, you can often re-use parts of the implementation of the previous strategy without having to change them. Instead of spending a lot of time defining a spec and interfaces and objects, you just write a quick spec right there in the code, then write the code that implements that code right under it.

This method of programming, I think, eludes a quick, visual metaphor like an arch or a lintel or a blueprint, mostly because its consequences are so subtle. Most of the work is done in the bottom-up style, but there are many top-down aspects, as they allow you to better reason about which bits at the base are important to get to first. Perhaps a good metaphor would be found in Haskell’s default of lazy evaluation. The top level spec defines a massive solution space comprised of all of the possible programs that you could write to do the thing that you’re trying to do, and then you only write just the bits that you need to write to get it working, much as Haskell can define a list or matrix of theoretically infinite extent and then pluck out just the values it actually needs, rather than precomputing the entire thing. By exposing the shape of this solution space, the high level spec allows us to better reason about what low level chunks of the program we need to attack first.

One of the thing that makes CL a pain in the ass sometimes is that there are a lot of strangely named functions specialized for different types of objects. The language has a trillion keywords and a lot of them don’t really help the language learner get comfortable with the language. As an example, iteration:

In the language standard there are a couple of different iteration constructs, do, dolist, docount, and loop. Strangely, there is no doarray. It’s easy enough to write one:

(defmacro do-svect ((counter array) &rest body)
  (let ((ctr (gensym)))
    `(dotimes (,ctr (fill-pointer ,array)) 
       (let ((,counter (aref ,array ,ctr)))
     ,@body))))

That’s all well and good, but it’s a pain to have to write a macro for each and every sequence type of thing that you have to deal with, and while I understand why it isn’t there, I don’t understand why there isn’t some general foreach type of function. It would be easy enough to write, just a macro that detects the type of the sequence type the function was called on that writes out the appropriate thing. There are a number of situations where this would help a lot, to the beginner. Just layer them as macros over the normal syntax and keywords, which, of course, would all still be there if you needed to do something more complicated.

Syntax, I think, makes things easier to remember, because (and I’m theorizing here) it calls in some other part of the brain than the part that we use to remember vocabulary, which is what we’re being asked to do with Lisp. I’ve never in my life written a line of Smalltalk, but I can remember that their lambda syntax is something like [ x y | x * y ]. I know very little Erlang, but I know that their binary pattern matching syntax is << x/integer, y/float >> = val. I’ve been reading about lisp for years and staring at it for ten of the last sixteen hours and I’ll be damned if I can remember how to pass multiple values back from a function.

Perhaps Arc will fix all of this, but I think that it would be of no little value to the Lisp community, and to those who want to learn lisp, if people started working on a package that everyone agreed to include and use with their distributions (hah!) that made some things a little easier. It could be something like the modern package that comes with ACL. Hell, everyone could make their own and then we could give them six months, then put them all in a ring and make them fight and then make something more or less agreeable to everyone with the parts that are left over.

Lisp is famed for it’s ability to quickly generate Domain Specific Languages, so perhaps it’s time that we bent that ability towards a different kind of domain, that of learning the language itself. It might also point to the kinds of things that would be interesting to put into the next version of the spec, in the far-off, misty future when that fabled document is actually generated.

So, the other day I was reading programming blogs, which seems to be the thing do do when you don’t actually want to work, and I ran into Erlang’s facility for binary pattern matching. Essentially it’s a rather nice syntax for taking a wodge (that’s a technical term) of binary data and decomposing it into variables. So:

<< foo:8, monkey/integer, bazzle:16, arrr:4/string, rest/binary >> = packet

will get you ubyte called foo with the first 8 bits of packet, an unsigned integer called monkey from the 9th through 40th bits, a ushort called bazzle, a 4 byte string called arrr (you could specify further what type of string, I think, if you needed something else), and a binary glob called rest with the rest of packet. I thought that this was pretty neat, and was thinking that making a nice, general facility for this in Lisp would make an interesting project, at least for me, because even though I know a fair amount about Lisp, I haven’t really used it that much. In any case, I was reading up about how someone might go about doing something like this when I ran into something in Practical Common Lisp that was more or less exactly what I was thinking of, expressed in a macro that really isn’t that long. it’s called define-binary-class and generates the class and a constructor that will read in binary data in a similar manner to the above. Plus, with some trivial modifications, I’m sure that you could alter it to make either structures or classes and to nest definitions, which is something that the static syntax of Erlang cannot do.

This, to me, is the primary virtue of Lisp, but it’s sometimes frustrating that most things are so trivial in the language that there’s nothing to do as an intro but leap into application code. This, perhaps, is one of the things that keeps people from getting into the language. You can do anything, but it’s either trivial or hard (or at least time consuming). Also, you’re forever doing things and then realizing that the massive standard library already has something that does exactly that. And then there’s the constant impetus to refactor the code into something cleaner, which the macro facilities of the language makes easy, fun and powerful, so the temptation to cat-hoover away all of your programming time cleaning up the code is pretty strong. That all of this is exacerbated by my lack of ability to think of enthralling software projects to work on is, I’m sure, incidental.

I want this. And a gumstix computer with one of these, instead of the XScale and an SD reader instead of the clunky MMC. And a flexible touchscreen. I would then combine all of these things with my friend Ian’s Roadster software and a handlebar bag (can’t forget a big battery of some sort and a big antenna for listening to GPS/talking to networks) in order to make the best bike touring computer eV4r. Unfortunately, all of that stuff would cost me about five grand. Dear lazy(rich)web! Provide, provide!

The other project (also bike-related) that I would like to undertake is a touring recharger system. You put one of these on your front wheel, then wire it to a setup (WARNING: violent hand-waving ahead!) in your rear pannier which has a big capacitor and some regulator hardware (look at those hands go, folks!) which trickle charges all of your batteries (AAAs for lights, a spare battery for the computer mentioned above, perhaps a battery or two for a small laptop, batteries for an LED camping lantern, cell phone batteries, etc.). Once done (and suitably waterproofed) you have most of life’s modern electronic conveniences whilst on the road. In theory. The dynohub only provides a couple of watts, but one imagines that a couple of hours a day would be enough to keep a fair amount of gear charged up. The really unfortunate thing about the front hub systems is that you can’t use the bike as a generator unless it’s moving, so there’s no putting the bike up at night and pedaling free for an hour to get some more juice. You have what you have at the end of the day.

Of the two projects, the first is far more likely to bear fruit despite its staggering cost (and occasionally fictional equipment), as I have the pertinent skills to put a bunch of premade parts together and program them up into something useful, whereas the second wants many skills and much knowledge that I do not have, and am ultimately too ADD to acquire. Still, they’re both neat ideas. Now I just need to suddenly become rich and totally idle so that I can pursue them.

it’s been years since I’ve been able to call someone a carbon facist in an argument. Ah, academia, I miss you and your over-earnest, drunken arguments.

This article on worldchanging, along with some conversations that I was exposed to on RAGBRAI (where the people that I was riding with were seriously into sustainable agriculture, got me thinking. So I’m not into the farming thing. I have no affinity with the land whatsoever. However, I’m pretty into computer systems, and it disappoints me that there are so few opportunities to apply my skills in a socially responsible manner (or, to be more honest about my level of selfishness, to do so and make a reasonable living). Which got me thinking. It would be pretty interesting to me to put together some software to optimize drip irrigation in a few years when solar powered wireless sensors get cheaper. You could even put together an NGO or charity around the product, with optimized plans for effectively irrigating ground, donation subsidized kits, volunteer labor (help with putting the systems in place and supervision for installation and repair). The system would work something like this:

• The core: A small, weatherproofed system-on-a-board computer, possibly solar powered (or you could just station it by the pump, where there’s power). Contains the control software.

• A variable speed computer controlled pump big enough to push water from the water source to the farthest edge of the field, or a network of them.

• The sensors are on stakes, a couple of feet high with solar panels up top. They’re simple soil hygrometers and some internal diagnostics, and maybe a green/red led to report health. They’d need to be really cheap, as you’d want to have a fair amount of them.

• Your drip irrigation equipment has some solar powered and wirelessly controlled shunts with caps or batteries big enough to actuate a couple of times a night if needed, even when there isn’t much sun. They should also be able to report their health. You’d use these for routing water around places where the ground didn’t need to be watered.

That’s pretty much it. You could do a web UI accessible from a OLPC machine (which could talk to the control center wirelessly) so the farmers could fine tune the system for their crops and local environment, and you could work on a much simpler and intuitive system of control for locales where the level of education and/or laptop access is much lower, (but setting one person in a village with one of these laptops would likely be enough, as that person could do all of the fine tuning for many farms). The notional organization could also have educational initiatives for improving water use and could also lobby for smarter water use laws around the nation. It could also subsidize itself by offering up a certain (small) percentage of its people (on a rotating basis) as water use consultants for larger farms (although it’s unclear how desired this service is). In a world where clean, usable water is growing increasingly scarce and hence increasingly expensive, it seems to me that these systems (especially when subsidized) could pay for themselves in short order, and would leave more usable excess water in the system for the expansion of agriculture and for use as drinking water where it is scarce.

Unannounced vacation. I went on RAGBRAI with some friends, so I was gone for a week. This has taught me a couple of things:

• I need better sun block. The crap that I was using has left me covered in pimples and rashes and supremely unhappy, plus I still got burnt a little, though it’s not as bad as it could be.

• For anything above 20 miles, I really need to do something about my handlebars. I think that I’m going to have to get a new stem to raise them up a little and move them closer. A lot of hand pain was experienced.

• I think that I’m going to pony up for a Brooks B.17 leather saddle. People were singing their praises, and my saddle isn’t all that comfortable past 30 miles or so.

• I need some new pedals, again for the greater distances. I think that I’m going to get a new commuter bike and transfer the egg beaters to that one and then get some quattros to go on the road bike.

• I need better bike luggage. I think that I’m going to put a rack on both bikes and get some panniers (something big enough at least to take my laptop and a change of clothes and shoes). It’s all well and good to haul stuff to work in my bag, but there’s really something to be said for real luggage for anything longer than a couple of miles.

Anyway, enough bike dorkery. I did do some reading on the trip, and I thought that I’d spend some time going over that. I took a lot more things along than I was able to get through, but then, I thought that I was going to be able to read at night and there just wasn’t the time or the energy for that. On the plane to and from, I got through Mr. Dozois’ 23rd annual collection of the year’s best science fiction short stories. I really do love short fiction, though I don’t really read enough of it. I need to catch up on all of the stuff that I haven’t read, but then, I have something like 30 unread novels waiting as well, so we’ll see what kind of time I can make for all of it. In any case, a few comments on each of the stories contained (those that I’ve read, at least), to give you a bit of the flavor so that you go out and buy it now like you already should have.

Actually, after about half an hour of writing a little bit about each one, I find that I’m bored with the project. Here’s a short list of the really, really good stories from it that you really shouldn’t miss (because I am a painfully lazy slackass):

• “Camouflage”, by Robert Reed.
  A Great Ship story. I really like Reed’s stuff.

• “A Case of Consilience”, by Ken MacLeod.

• “Little Faces”, by Vonda McIntyre.
  Quite weird. Gracefully establishes a very strange setting with characters who aren’t really anything like human, but gets you emotionally involved in any case.

• “Deus Ex Homine”, by Hannu Rajaniemi.
  I’d never heard of the author before I picked up the Nova Scotia anthology earlier this year. I really liked this one. Looking forward to hearing more from the author.

• “Softly Spoke the Gabbleduck”, by Neal Asher.
  A Polity short story, with a gabbleduck far from home. Every time I read an Asher novel, I keep reading the word gabberduck, which gives me the mental image of some coked out late 90s English raver type wearing a duck hat. I think that this dampens some of the terror, at least for me, some of the terror that Mr. Asher means the gabbleduck to inspire.

• “Beyond the Aquila Rift” & “Zima Blue”, by Alastair Reynolds.
  Both of his short stories in this collection are, to me, indications that Reynolds might be pushing to hard with the novels. He’s still really good at the short form, which makes me think that if he focused on writing shorter, more economical novels, instead of the massive tomes that he’s been pushing out once per year lately (I’m sure that’s publisher pressure more than choice, though), he’d be writing books that I’d be more interested in reading.

• “The Clockwork Atom Bomb”, by Dominic Green.
  Never heard of the author before, but this is an interesting one, about weapons inspector/disarmament expert type handling some really nasty relic weapons.

• “Gold Mountain”, by Chris Roberson.
  Another entry in his series of stories (leading to a novel, I think) about a world where China never turns inwards, but becomes the leader of the civilized world, about the construction of a space elevator using American and other foreign labor around the same time that in our world the railroads were getting built. All about the human aspects, though as what they’re building really wouldn’t have mattered all that much. Affecting.

• “The Fulcrum”, by Gwyneth Jones.
  Jones is almost channeling M. John Harrison here, but doing so in her own inimitable style. Mayhem, weirdness, hateful characters and utter despair in the outer reaches of the solar system.

• “Two Dreams on Trains”, by Elizabeth Bear.
  An really great far future snippet about art and the lengths to which we’ll go to express ourselves.

• “Burn”, by James Patrick Kelly.
  I bought this a while ago as a stand alone novella. It has its weaknesses, but it’s a very good story about the choice to remain human in a universe that has definitely moved right on.

Also read Warpath by Tony Daniel. I really like his short stories and the two other novels of his that I’ve read, Metaplanetary and Superluminal. This is his first novel, and it shows in a lot of ways. I doesn’t have a lot of the confidence and panache that he developed later on, and the pacing is quite uneven. Still, entertaining if you’re a fan. The cover and back copy (and the title! I think that the one word title fad has done on long enough [as an aside, Haldeman’s Camouflage was originally called Sea Change, and was changed for the same reasons. I think that was lessened a little by that alteration, but then, I’m one of those weird people who think that titles matter]) are pretty dire. Ahh, the late 80s and early 90s. Things are getting better, but it’s very, very slow. Anyway, if you’re a Daniel fan, pick it up, although you’re unlikely to find it unless you have a really good used bookstore or you look online. If you’re Tony Daniel, write some more stuff! Looking on the internet, it seems that all of his projects are stalled at the moment, which is assy. I really liked the first two, and would love to see at least some short fiction, but it seems like the man dropped off the face of the Earth in 2003 or so. I hope that he makes a triumphant return at some point. It’d be kinda sad if he didn’t, as he was one of the more interesting up and comers of the last few years.

In other news, it looks like Elizabeth Bear saw my little capsule review of her last couple of books. Again, I really should write something longer, at least about Blood & Iron. It really is quite good.

This paper is possibly the grimmest thing that I’ve read about computer science in years, and covers a lot of why I think that working in the industry is boring and a lot of why I haven’t gone back to grad school. I don’t agree with all of it, though, and the suggestions aren’t really suggestions, more ‘just do the right thing already’ bitching that doesn’t really get anything done. Of course, I don’t have the answers either, or I’d be pursuing them. A lot of the trends that he’s pointed out have been continuing. There are precious few new and interesting OSes out there, and the ones that there are don’t seem to get any traction. It’s impossible to market a totally novel chip architecture. Even Intel can’t manage it and there is no one in the world with more leverage or money to spend on getting people to adopt and write software for something. An enormous amount of money is spent developing deeper and deeper emulation and virtualization layers to get the stuff that we already have to work on new systems and chips. The issue is that all of it is fundamentally boring. The OS and applications chicken and egg problem is huge, and it’s likely to grow, with no end in sight. I think that if you asked most people today what the answer is, they’d likely say the web, which is possible. If most applications are delivered that way, then a new system really only needs a few applications: a windowing system, a C compiler, a text editor and a web browser. This might allow for some interesting new operating systems to sprout up and make the cost of migration between them lower, which is always a good thing. However, it also reduces the urge to innovate or adopt new systems, since most of what you’re doing is all on the web anyway, and if your system is good enough, there’s little real benefit to adopting a new system.

Which brings us to the crux of the issue, which is primarily that there are few new problems that we’re trying to solve with computers. I can’t, off the top of my head, think of a new CS problem that I’ve heard people talking about. Ubicomp, maybe, but most of the things that I’ve heard of as applications for it are just retreads of older things. There’s still a lot of interest in the old ones, and there are a lot of problems yet to be solved, but there aren’t a whole lot of actual new topics. Nothing new under the sun? Maybe, but I feel like there must be something that we’re missing, whole categories of new things that one can do with computers other than making better web servers at the top end and better web browsers at the bottom end.

I’m getting tired of hearing about them. Yes, they suck. However, it’s trivial, from what I understand, to defeat people who want to scan them without your permission. Just carry the damned thing around in a wallet woven with copper wires, or a solid case made out of some some conductive metal. You’d think that after two hundred and seventy years, more people would have heard of Faraday cages. That said, we shouldn’t have to bother, but if the government is going to go on about their idiot quest to make us less safe through ill-considered technological initiatives and pointless wars of agression, then we should do more than just wring our hands and make ourselves martyrs to other people’s idiocy. I mean, sure, most people won’t figure out about it and might just get taken advantage of because they’re easily identifiable. Me? I’m gonna hang around in foriegn airports with a bag of the aforementioned cases and wallets and a scanner. Sell them to tourists on their way out into the big bad world along with pamphlets about how to pass yourself off as a native of Toronto.