OMG Sea Otters

I haven't done a "cute animal" post for quite a while, because I haven't had any cute animal photos worth sharing in quite a while. It's time to remedy that, big time. Here are a few photos of sea otters at the Monterey Bay Aquarium. Awwwwww....

Now, it just wouldn't be right to post cute photos without any serious content attached. I'm not sure why, but I know I'd feel guilty, like I was failing in my duties as a responsible and occasionally civic-minded blogger, or something. So here are a few interesting otter-related items:

• The Monterey-based "Friends of the Sea Otter" has an informative website including legislative and other news.
  
• ScienceDaily: "Is That Sea Otter Stealing Your Lunch -- Or Making It?"
  
• Info on efforts to bring sea otters back to Oregon.
  
• More about otter reintroduction from the Oregon Zoo.
  
• "Sea Otter Classic" cycling festival, also in Monterey. FWIW. The main reason we went to Monterey in February was to catch part of the 2008 Tour of California, so it's interesting to see the two topics come together, in a way.
  
• And I couldn't let this go without noting there are tons of otter photos on Flickr and Google Images.
  

In any case, here are the rest of the photos:

unseasonable, unreasonable

So here I am, a responsible, professional grownup, becoming all giddy over a few preliminary signs of spring. Yesterday it was a few early bulbs, today it's a tree budding out. No doubt this all comes across as a tad silly and superficial, at least to any other Portlanders who may happen to read this. A core tenet of our local mythology holds that we are inherently sophisticated and morally superior because we get rained on all the time. As the story goes, the rain forces us all to stay inside and read books, instead of surfing and tanning and carrying on like those poor, benighted, sun-addled Californians.

It's kind of an odd notion, isn't it, that reading and sunshine are mutually exclusive? If that was true, one would expect that Powell's would shut down during our fair city's summer month(s), but visit the store on a hot summer's day and you'll be far from alone. It is, in fact, possible to sit outside on a warm day with a good book. I know this is possible because I've done it, and hope to do it again someday once the warm days return.

The myth, in essence, says that we read because the weather leaves us no alternative. So we go about endlessly congratulating ourselves for choosing the only option available to us. Essentially we boast of eating our Brussels sprouts, because they're good for us and we've gradually learned to like them over the years, and it just so happens that Brussels sprouts are the only item on the menu. To me this seems a rather halfhearted defense of reading, but there you have it. Never mind that there are a number of other things one can do indoors besides read. Like, oh, watching TV, for example -- an activity I suspect is just as popular here as it is everywhere else.

I didn't plan on going off on a rant like this, but our smug Portland mythology really grates on me at times. There's really no call for any intelligent person to pretend that rain is preferable to sunshine. That's just an idiotic opinion, unless you're a plant -- and even then it's best to have a mix of both.

In any case, the sun's out again today. So I think I'll wrap this up and head outside...

OMG Springtime (almost)

So I wandered away from the office around lunch, as I often do, and I saw the very last thing I expected. Flowers. Real, live flowers. Blooming. Right here in Portland, of all places. Seriously. I swear I'm not making this up.



And it's about damn time. I was really starting to wonder if we'd ever see spring again, or if it was just going to be nothing but bare trees and endless drizzly gloom from here on out. I mean, logically that's a silly notion, of course, but under the circumstances I still couldn't help but wonder. There certainly weren't any signs of spring when we headed off to vacation in cold, rainy California, so this must've all happened while we were away. It's almost as if we'd triggered it somehow. So the gradual changing of the seasons is probably my doing, at least in part. Or at least I like to think so.



Now here's the counterintuitive part. Out of curiosity, I tracked down last year's semi-obligatory "OMG Springtime" post, and it sure looks like we're only lagging a week or so behind last year, foliage-wise. I wouldn't have expected that. Go figure. At least my photos are a lot better this year. So that's something, I guess.



This springtime business still seems too good to be true. I expect we'll probably have a late freeze that takes out anything that dared to bloom, followed by another six months of cold, dreary rain and wind. It just stands to reason. And that's if we're lucky. If we're really unlucky we'll get a nice nuclear winter or something, and then the rain will be the least of our worries.

Feh.

Well, in any case, enjoy the flowers while they last. If you'd like to see the full set from today, I've got 'em on Flickr here.

A garden in Monterey

View Larger Map

Just got back from a much-needed vacation, which explains a.) the lack of new posts here over the last two weeks, and b.) this post full of vacation photos.

These were taken in a small garden near the Custom House Plaza in Monterey, CA. The full photoset is here, if you're interested. Or whatever.

Bridge 5.1

View Larger Map

A few photos of the railroad bridge in St. Johns. The bridge is officially known as "Burlington Northern Railroad Bridge 5.1", the 5.1 being the distance in miles from Union Station. I've always liked this bridge, first because it's so obscure, and secondly because it just looks cool, in a muscular, heavy-industrial sort of way. Just looking at it, you'd never guess the central lift span only dates to 1989. You'd just sort of expect anything build in 1989 to be all mauve and teal and loaded with silly postmodern crap, I mean, "pastiche", and it'd look as dated as parachute pants and big hair.

Anyway, I originally wanted to get closer to the bridge than this, but it's quite hard for mere mortals to get close to it on either side of the river. On the east bank there are, technically, roads down to the vicinity of the bridge, but there are also signs informing you that the whole area is a federal Superfund site. I think it has something to do with creosote manufacturing, which sounds kind of icky to me. I imagine that even if you could get down there as a mere mortal, you might very well leave as something else entirely. Longtime Gentle Reader(s) of this blog have probably noticed how I often say I really go to the mat for you guys, and I think I do on occasion, but I do draw a line at "Superfund". This post on Sprol names the old McCormick & Baxter site as one of the "Worst Places in the World", and talks about what's down there. More at Portland Public Art, believe it or not, since apparently there's some interesting graffiti around the place.

There's been talk of eventually putting a city park on the site, if they can ever get it cleaned up to everyone's satisfaction. Which I think may be a big if. In any event, we'll probably end up with luxury condo towers instead, since that's what always seems to happen.

So I have an idea about the bridge that I've been batting around, and I thought I'd toss it out in case anyone with power and influence happens to read this. A few years ago when the city revamped the Eastside Esplanade across from downtown, they added a pedestrian/bike path to the lower deck of the Steel Bridge, next to but completely separate from the railroad tracks. It might be a good idea to do the same with Bridge 5.1 here. We're forever hearing about how dangerous the St. Johns Bridge is for cyclists, and I'm sure that's true. I once knew a guy whose bike hit some bad pavement on the St. Johns, causing him to crash and break his arm in three places. And it would've been much worse if the semi behind him hadn't swerved out of the way just in time. We're told there's nowhere to put separate bike lanes on the St. Johns, and again, I'm sure that's true. The lanes are narrow as it is, and I don't see how you could safely narrow them any further. What's more, the St. Johns is the only game in town right now if you live up in that part of town and need to cross the river. So wouldn't it make sense to have a safer alternative in place? I'm not a civil engineer, so someone else would have to figure out whether a walk/bikeway is even possible with this bridge, much less how much it'd cost. I'm just saying it sounds like a good idea. Hint, hint.

If you'd like to see some pics that are a bit more professionally done, Portland Bridges has a couple of nice photos of the bridge here and here.

photo friday, midwinter edition

Moss on bricks. Lichens on tree trunks. Ferns growing in trees.

Our pioneer ancestors chopped down much of the Northwest's temperate rainforest, a century ago and more. Now it looks like the rainforest is back with a vengeance, and soon it'll be payback time. When angry Ents show up and start hurling boulders at my building, I won't be the least bit surprised.

"these are for you..."

Windows Vista, spawn of Satan

I don't talk about work very much on this humble blog. In fact I almost never do. But for the past roughly two months I've been saddled with tweaking a Windows app so it works "properly" on Vista, and I need to vent a little. Ok, a lot. And not about obvious stuff like the ugly UI, or the way the OS badgers you to authorize and confirm every little thing you try to do. I turned most of that off right off the bat. No, once you elbow your way past the glossy nonsense and try to write some actual code, you run into a whole new set of annoyances.

• They've changed the event logs all around, for no obvious reason. In particular, they've tinkered with the security log and changed the event formats around, so any code that walks the log looking for logon/logoff events, filesystem activity, etc., is going to need to change. They haven't added much of anything useful that I've seen so far. At least, for "compatibility reasons", they've also changed the event IDs, bumping everything up by a nice round 4096. So that event #560 (request for privs on a file or other object) is now event #4656. Oh, and even though they've been working on Vista since around the time Win98 SE shipped, they don't have any formal documentation on the new formats just yet. Nice.
  
  Oh, and they've also added a whole new API for reading and writing to the event log, although you aren't actually obligated to use it. Yet.
  
  The only improvement I've noticed so far is that the security log will finally tell you which registry value changed, instead of just telling you the key name and making you guess. It's taken umpteen years and a day, but they finally fixed that. So that's hopeful in a way -- maybe, just maybe, all the other things that suck about Windows aren't permanent after all. But don't hold your breath waiting.
  
  
• MS quietly added some mandatory access control features, by kludging MAC data into objects' security descriptors as part of the SACL, where it doesn't really belong at all. And then they go and defeat the entire point of mandatory access control, by having all regular apps run under the High security label. Yes, even IE. Bastards.
  
  I realize it would've been a pain to add a new component to security descriptors, and I imagine they kludged it into the SACL because the OS protects that a bit more. But now Windows has to check two places instead of one (the DACL) to see whether you have access to a file or not. This probably isn't the main reason Vista is so slow, but I'm sure it can't be helping.
  
  Since this is a new feature in Vista, you can't reasonably expect it to be supported in Explorer. And if you did, you'd be wrong, because it's not there. Even though it's physically part of the SACL, you only get it back if you also specify the new LABEL_SECURITY_INFORMATION flag when querying an object's security descriptor. Naturally Explorer doesn't do that. At least there's a command line tool (icacls.exe) you can use if you need to.
  
  In fairness, M$ hasn't been promoting this at all, so they may realize it isn't ready for prime time just yet. If they handle it like they've handled other filesystem features, they may let it sit for a decade or so before making it do something useful (like hardlinks), or they may just abandon it in place, leaving mysterious stubs here and there around the OS (like COM-style "structured storage", or OS/2-style "extended attributes"). Or it'll just remain in limbo for eternity, present but not easily seen or used, like alternate data streams.
  
  
• Oh, and there's always folder virtualization, where your app thinks it's writing a file to Program Files, but Vista lies to you and silently redirects the file to somewhere else, so as to keep Program Files all pristine and whatever. It turns out that you can sort of turn this off. But unlike the 32 vs. 64-bit virtualization that appeared in 64-bit XP, there's no brain-melting API to toggle this on and off for your app. No, instead you mark the app as requiring administrative rights, and you do this with an XML file called a "manifest". That gets compiled into a string resource that Vista looks at first when deciding whether to run your app or not.
  
  So the plus side is that your files really do go where you put them. The minus side is that you've got to do the "Run as Administrator" dance first, with scary UAC dialogs galore. Unless you turn off UAC. Signing your app with a nice, expensive Authenticode cert will give users a somewhat less scary UAC dialog, for whatever that's worth.
  
  
• Someone ought to sue MS for multiple abuse of the word "Virtual". On top of at least two unrelated kinds of folder virtualization, and at least one kind of registry virtualization, they've also added a new file attribute bit, "FILE_ATTRIBUTE_VIRTUAL", which MSDN merely describes as "The file is a virtual file." Which is not overly helpful. I'm pretty sure it's unrelated to the Program Files thing in the previous item, but I still have no idea what this is for, or whether I need to worry about it. Bastards.
  
  
• Did you know Vista supports hard links and symlinks now? It's true! Under the hood, symlinks are implemented with complex entities called "reparse points", and there are six other kinds of reparse point, including directory junctions, mount points, DFS mount points, Hierarchical Storage Management doohickeys, Single Information Store ( a sort of fancy distributed copy-on-write symlink-ish arrangement), and much, much more. Hard links, on the other hand, are a low-level NTFS feature implemented with alternate data streams, more or less. Don't get me started about alternate data streams. Actually hard links have been around since the NT 3.1 days, but MS didn't bother to document them much until now.
  
  Kind of a shame that Explorer doesn't know squat about directory junctions, even the ones created as part of the Vista default install (like "C:\Documents and Settings", which now points to "C:\Users", for example).
  
  
• If you're feeling brave, install SUA ("Services for Unix-based Applications") on Vista. Enable case-sensitive filenames during the install, open a shell window, and create a couple of files whose names differ only by case. Then try opening either one in Explorer and see what happens. Snort. Giggle. This isn't exactly new behavior or anything, but the way they've been pushing this SUA stuff lately you'd think they'd have taken the time to iron out certain longstanding kinks.
  
  
• I actually ended up deactivating SUA, because it didn't get along with Visual Studio 2005. I never quite figured out the details, but when SUA was enabled builds would either stall out, take forever to run, or fail with unspecified errors. But be warned, if you deactivate SUA, you also need to disable the Posix debugging plugin within VS2k5. Otherwise the IDE will explode whenever you try to debug an app, any app, not just Posix ones. It's kind of a shame really; I was starting to warm up to SUA. I'd installed gcc and almost got bash working when I realized it simply wasn't to be. Oh, well.
  
  
• Yet another obscure and poorly documented tidbit: Vista added a new registry function called RegLoadAppKey, which basically lets apps create their own private chunks of registry that aren't visible in Regedit, because they lie outside the usual HKEY_LOCAL_MACHINE / HKEY_USERS / etc. keys. The Windows kernel uses a different namespace than mere mortal apps do, so to it HKEY_LOCAL_MACHINE is "\Registry\Machine", HKEY_USERS is "\Registry\Users". C:\ is usually something like "\Device\Harddisk0\Partition1", but I digress. When you create a private registry hive, it mounts under "\Registry\A\{GUID}", where {GUID} is a unique ID generated new each time a hive is loaded. If spyware isn't already exploiting this, it's only a matter of time. Granted, you could already mount a hive under \Registry if you knew your way around the native API, but now they've made it so easy even a script kiddie can do it.
  
  I don't know for a fact that private hives always show up under "\Registry\A", since the whole thing's totally undocumented. But that's the behavior I've seen so far.
  
  
• Transactional NTFS isn't an inherently terrible idea. I can see cases where you'd want to be sure either all of your file & registry changes happen or none of them do, so that your app data doesn't get wedged in an inconsistent state. It's kind of a shame they had to introduce new "transacted" forms of all the existing file & registry functions just to support this. (Actually I'm not sure they did all of them, because I haven't checked.)
  
  It'll probably be years before we get a handle on all the oddities and implications around doing access on a transactional model, but I've seen at least one thing already. If you, say, delete a file as part of a transaction, the audit event for the delete includes a "transaction ID", which is just a big ugly GUID (this being Windows and all). Then when you commit or roll back a transaction, another event shows up in the log saying the transaction state has changed, giving you the transaction ID and the new state, which is an opaque integer. If I recall correctly, "commit" is 52 and "rollback" is 56. Or perhaps it's the other way around, I forget now. So if there's a rollback, you have to go back and look at all the activity you saw earlier tagged with that transaction ID and treat it as if it never happened, basically. It's always an adventure... Yeah...
  
  

Before starting this post, I spent a fair amount of time carping about Vista elsewhere. I figured I'd copy-n-paste those comments here so I can concentrate all my whining in one place....

---

From IV

So at the office I just (sorta) wrapped up a Linux coding project that's been sucking up most of my available cycles for a while now. And fresh of that, I've been tasked with tweaking a different app to make it play nice with Vista. Understand that 90% of my coworkers are Java & web folks who know zilch about underlying operating systems, and I wear both the Unix and Win32 guru hats in these parts. Which is good, most of the time. It certainly makes for great job security.

It's even convenient to start on Vista now because I just got a shiny new Core 2 Duo box, which may be just barely fast enough to run Vista halfway decently. But there's a problem. Corporate IS has decreed that Vista is Verboten companywide. I can't blame them, of course, and I think I actually crowed about that policy here once upon a time, but now it's becoming a problem. The official line is that I *can* install it on my new box, but if I do I can't connect it to the network. I may have to go to IS in the near future, hat in hand, and beg them to bend the rules just this once on my behalf. For stupid freakin' Vista, of all things.

[ I've used Vista exactly once before, while trying to fix my mother's fancy new HP touchscreen machine. Ten minutes of that, and I concluded that Vista is evil and everything about it is wrong. But mom likes it because of the flashy graphics. When I told her my home is Windows-free, she looked at me like I was from Neptune. But at least I fixed the problem, which turned out to be the lack of a USB cable between the computer and the printer. :) ]

Again from IV:

So, as you might be aware, I'm stuck with Vista, and every day it sucks worse than the day before. Today I came in to the office and noticed Firefox had gone haywire, in a way I haven't seen it do on any other OS. Somehow it had picked up a memory leak, and was using 1.4GB memory and 50% cpu. Or at least that's what Vista said it was doing. Possibly this is a genuine problem in FF, but it's also possible a certain predatory OS+browser monopolist is messing about with a certain competing browser. It's happened before, and nothing would surprise me at this point.

But that's not the really cheesy part. I went ahead and killed FF, and Vista -- the OS with the fancy gee-whiz graphics and all -- can't seem to figure out that I no longer require a grey outline of where my FF window used to be. It's not just an artifact of lazy screen drawing or anything; it redraws over top of all other windows. You move something around, and the big grey outline is still there. I thought they'd sorted out this crap back around Windows 2.11 or so, but apparently not.

"Fortunately", Windows Update has downloaded the latest set of critical bug fixes and security patches and such, and every few minutes it pesters me to reboot. So reboot I shall.

Stupid Vista.

More of the same. A little redundant, and not all of it Vista-specific, but hey.

Ah, the weird, wonderful world of Windows filesystem oddities. As I've mentioned before, I'm currently in the midst of tweaking an existing Windows app so it runs properly on Vista, so I've been forced to remember a bunch of ugly details I'd happily paged out.

A few of my favorites, just off the top of my head:

• If you want to know the access & write times on a file, the value you see depends on how you ask. My theory is that Windows flushes metadata updates to disk on a very lazy, periodic basis, although I don't believe they've ever documented this. GetFileTimes() appears to return the in-memory values, in the disk cache or somewhere, while FindFirstFile/FindNextFile always hits the disk and returns whatever's there. I've seen the two out of sync by up to an hour at times. Naturally there's an obscure registry setting that lets you turn off updating of file access times entirely, and this seems to be the default on Vista. Although again, this is completely undocumented.
  
  
• Filenames are not case sensitive, except when they are. There are several ways to get two files in a directory whose names differ only by case: Unix drives shared via Samba, or files created under Services for Unix, or files created with plain old CreateFile() with the FILE_FLAG_POSIX_SEMANTICS option (although the latter doesn't work by default on XP & later). Explorer gets deeply confused when you try to open one of these, and opens whichever comes first alphabetically (I think), regardless of which one you actually clicked on.
  
  
• Paths are limited to MAX_PATH (260) characters, except when they aren't. 260 characters too restrictive? Just prepend "\\?\" to your path and away you go, up to around 32000 chars. Except that nearly all Windows apps don't know about this trick either, so you can create directory trees that almost nobody can see into. To be fair, you can do something similar on Unix too. It's easy to write a little program that creates a directory with a long name, chdir's into it, creates a subdirectory with a long name, chdir's into it, and so forth, and do a getcwd() at each iteration. Eventually getcwd() starts failing, but the OS is quite happy to go on creating subdirs for you until you fill up the disk.
  
  
• The registry has a different trick for creating keys nobody can see into. The underlying (and little-known) Native API refers to object names with counted strings, not null-terminated ones, so you're free to use embedded null characters in the names of things. Well, some things. I don't think NTFS accepts null chars in names, at least. But the registry's just fine with it. The regular Win32 API everyone uses *does* use null-terminated names, though, so if you create a key with an embedded null in the name, there is simply no way to open it with RegOpenKeyEx(), because its name is basically "unspeakable" as far as Win32 is concerned. MS actually used this trick to secure sensitive bits of the registry, like parts of the local SAM db. Which works great so long as nobody learns the trick. Security through obscurity...
  
  
• Vista introduced a new twist on "unspeakable" registry names. There's a new function called RegLoadAppKey(), which promises to give your app its own private chunk of registry nobody else can see. And it's true, you get a bit of registry that can't be located with HKEY_LOCAL_MACHINE, HKEY_USERS, or any of the other predefined keys.
  
  A bit of background is in order here. The NT kernel uses a different path scheme than what people are used to seeing in Regedit, or Explorer for that matter, and the names of things you encounter are not their *true* names. HKEY_LOCAL_MACHINE is really \Registry\Machine, HKEY_USERS is \Registry\Users, C:\ is usually something like \Device\Harddisk0\Partition1, and so forth. I rather like this unified namespace, actually, as it makes things feel just a little more Unix-like. So of course it's completely invisible to end users, with occasional exceptions such as registry audit events.
  
  So the new trick from Redmond is to mount "private" registry hives under \Registry\A\{GUID}, where GUID is newly assigned each time a hive is mounted. Once you know where to look, "private" isn't quite so private anymore. Still, Regedit and other apps using Win32 functions can't see this stuff, so I expect it's only a matter of time before the spyware crowd starts exploiting this "feature".
  
  
• Vista now offers symlinks, which are not the same thing as hardlinks, or directory junctions, or shortcuts. Symlinks are implemented as "reparse points", and the symlink data is stored as an alternate data stream. Directory junctions are "reparse points" too. Actually there are at least seven different kinds of reparse point, and counting, and there's a complex API that lets you define your own types too, like you'd really want to do that. Hardlinks are a low-level NTFS feature that's been around since the beginning, although poorly supported until recently. Shortcuts are a higher-level feature, belonging to the UI part of the OS, and are implemented with COM.