Tuesday, November 17, 2009

I've moved

see blog.darkuncle.net (hosted by tumblr). Better interface, more updates, just need to clone the posts from this blog over there for completeness.

Monday, June 22, 2009

the best weapon against terrorism isn't a gun

The following was prompted by an email forwarded from my dad, who gets a lot of things sent to him by people who are long on emotion and short on logic. Much like a politician who says we must do whatever-it-is "at any cost", the authors of these various items clearly haven't stopped to consider what their statements really mean. -- ed.


original email:

Why We Like Australians

T. B. Bechtel, a City Councilor from Newcastle, Australia , was asked on a local live radio talk show, just what he thought about the allegations of torture of suspected terrorists.

His reply prompted his ejection from the studio, but to thunderous applause from the audience.

HIS STATEMENT:

"If hooking up one raghead terrorist prisoner's testicles to a car battery to get the truth out of the lying little camelshagger will save just one Australian life, then I have only three things to say...

Red is positive, Black is negative, and make sure his nuts are wet."

(end original email)


[ warning: facts and citations ahead. I took the time to collect these; at the very least, read item [9] below. ]

If you can be sure they're terrorists, and not some saps that were in the wrong place at the wrong time (like the Chinese Uighurs - the religious refugees that were cleared by the US of all terrorism charges five years ago, but who were still refused release until last month [1][2]), that's one thing.

Of course, the United States has always stood for justice and the rule of law; do we disregard those principles when it's inconvenient? If they are terrorists, try them and then lock them up or execute them. If they're not, let them go. Holding anybody without any kind of due process, for seven years, on an anonymous say-so (in the case of the aforementioned refugees, the say-so was that of Pakistani bounty hunters who were being paid for prisoners they turned in - conflict of interest much? [3]) is simply not consistent with who we are as Americans. Worse, when push comes to shove, we've been forced to admit that we had no more evidence than unsubstantiated rumors on many of these people, and they've been released back to what's left of their original lives. Even if I weren't originally opposed to the US, I think I might be if they took me away from my wife and kids for 6-7 years for no reason, and then refused to admit they'd made a mistake [4][5].

This is roughly akin to the no-fly list: a list of people so dangerous that they cannot be allowed to fly under any circumstances, but who are also so innocent that we can't arrest or accuse them of anything, even with the expanded powers of the PATRIOT Act [6]. This is a list that's reached nearly 400,000 names now [7]. With fewer than 200 known terrorist groups worldwide [8], if we assume 200 terrorists on average for every group (a wildly inflated figure for the vast majority of groups), the number of names on the no-fly list is an order of magnitude greater than the number of terrorists in all known terror groups worldwide.

I appreciate the sentiment, but there's three things we need to remember (as a country) when fighting this (or any) war:

1) we're Americans, and we hold ourselves to a higher standard than those we're fighting;
2) if we abandon our standards when they become inconvenient, or allow ourselves to be frightened into giving up the liberties we've fought and died for, the terrorists have already won - even if we capture and execute every last one of them.
3) how we conduct ourselves and prosecute a war against terrorists is chiefly responsible for whether we win allies or create easy recruiting for the very people we're fighting.

The best tool we can use in this fight is our common sense, and our refusal to be terrorized [9].


  1. http://en.wikipedia.org/wiki/Uyghur_people

  2. http://www.abc.net.au/news/stories/2009/06/16/2599957.htm?section=world

  3. http://www.npr.org/templates/story/story.php?storyId=105188932

  4. http://en.wikipedia.org/wiki/Lakhdar_Boumediene

  5. http://abcnews.go.com/Video/playerIndex?id=7781827

  6. http://www.schneier.com/blog/archives/2008/09/my_la_times_op.html

  7. http://en.wikipedia.org/wiki/No_Fly_List

  8. http://www.nationmaster.com/graph/ter_num_of_kno_ter_org_pre-number-known-terrorist-organizations-present

  9. http://www.schneier.com/essay-124.html

Friday, May 15, 2009

weekly^Wmonthly^Wannual update!

if I'm going to have a blog at all, it doesn't really serve much purpose if I don't write in it regularly. I started it so I'd have an easy, public place to write down particularly interesting, frustrating and/or thorny technology issues so that I both a) could avoid reinventing my own wheels, whenever possible, and b) so that others could benefit from any useful insights I come across.

Having not had a blog before (well, not since I had a private diary that I kept on 5.25" floppies on my TRS-80 Model III in grade school - Doogie Howser style!), getting in the habit of writing here regularly is clearly not going to happen without some consistent effort. To that end, I'm writing this update and making notes about other recent topics of note that should end up here in the near future.

Tuesday, May 20, 2008

VMware on NFS

in related news to my previous post:
http://storagefoo.blogspot.com/2007/09/vmware-over-nfs.html

ESX, OS X and NFS (or, ne'er the twain shall meet)

for the Googlers: after a week of troubleshooting problems using an OS X XServe (acting as a temporary NAS head to an XSan while we wait for our NetApp to arrive) as NFS server to some ESX-3.5 clients, it looks like this is the culprit there as well (referring to this other post about similar errors with a Fedora Core 6 client and Tru64 server). Symptoms are that when using esxcfg-nas(8) to mount NFS shares, the shares will mount, and files can be accessed if you know the full path name. Any attempts to ls(1) a directory or file fail with "Function not implemented" - _almost_ as if the execute bit had been removed from the directories in question. However, if the same share is accessed via the service console via e.g. "mount -t nfs ...", we get the normal behavior we'd expect from a functioning NFS client.

There appear to be two problems here:
1) tcpdump on the ESX service console will not monitor vmkernel traffic (and NFS traffic goes over the vmkernel port, if the mount was initiated by esxcfg-nas; if initiated by mount(8) on the service console, the NFS traffic runs over the service console port and can be sniffed out with e.g. 'tcpdump -nlei vswif0'). I'm pretty sure there's a way to do this, but I haven't sorted out the details yet. However, the real problem is:
2) OS X NFS server (as of 10.5 Leopard) apparently does not grok readdirplus() - after comparing tcpdump outputs on the server side between ls(1) attempts on the share mounted via mount(8) and esxcfg-nas(8), I finally noticed that the former was issuing readdir(), while the latter was using readdirplus().

As of ESX-3.5 (requirement introduced in ESX-3.0 I believe), nfsv3 over TCP is the only supported transport mechanism, so I can't just drop back to nfsv2 to get around the issue. I'm now looking into whether there's a secret knob in OS X that will make it parse readdirplus() properly, but I'm not optimistic. Perhaps the upcoming 10.5.3 update will fix the problem.

*sigh*