“Apple, Customer Service; Customer Service…”

Apple’s MobileMe services, including the various web hosting services associated with homepage.[mac|me].com were shutdown at the start of this month. Apple, a company that has built data centers the size of small towns to support its iCloud Internet services, appears not to have been able to find any resources to keep its existing Internet services going (even after spending years integrating “dot mac”/“Mobile Me” publishing into their various content production/manipulation apps). In the lead-up to shutting down their web hosting service, they were also incapable of providing customers with support for a service as fundamental as setting-up HTTP 303 permanent redirects, so that users’ browsers and search engine crawlers, alike, could be told where all those displaced web pages had gone to.

Apple’s best advice was “associate a custom domain with your homepage well in advance, then change where that domain points at the switchover.” A sound approach as far as it goes (it does nothing to address the loss of some features dot mac customers have been accustomed to for many years), but “dot mac”/”Mobile Me” was supposed to be web hosting for the rest of us – and I think that’s a bit much for many of the “rest of us,” especially if you’ve taken a fresh-eyed look at the home pages of the various domain registrars and web hosting companies – they’re an undifferentiated hell of “do this,” “do that” advertisements for their own mess of conflated/conjoined services. And some of the user experiences behind those sign-up buttons stop me cold, even when they don’t appear to lead into a trap or scam … and I’m one of the people who knows what they’re doing, at least in principle. (Figuring out how to just get services A and B out of companies intent on selling you the world and/or the Brooklyn Bridge is another matter.)

So, Apple’s paying customers are cutoff (if that’s how they’ve decided to treat their paying customers…), chucked out of the confines of the walled garden of dot mac, and granted their freedom in the middle of an unmapped swamp stretching from horizon to horizon. A review of basic customer service principles, and a reading of The Paradox of Choice, seems overdue in Cupertino. Better late than never.

(Sure, lots of companies do worse to their customers everyday, and I feel no need to criticize them for two reasons: in most cases I don’t even know about those incidents, and that’s because I select companies like Apple to deal with … firms that repay any extra up-front costs with the quality of their products or services in the long run. You know … usually … in principle. Which reminds me: Hey, Apple, Mac OS X 10.7 still doesn’t support your own RAID drivers! Screw your Pro users. Maximize the disk I/O performance bottleneck. WTF?)

FireWire 400 Devices Incompatible with FireWire 800 Macs?

If anyone knows of a solution to this, it'd sure come in handy.... I'm dealing with several converters that turn analog audio/video signals into standard DV video. All of them use the FireWire 400 interface, as is traditional for DV devices. My problem is that my Mac, a Mac Pro (4,1), has FireWire 800 ports. I've bought two different FireWire 400-to-800 adapters, both of which make the DV encoder boxes visible to most video capture applications (QuickTime Pro and iMovie, but not to Apple's example code for performing QuickTime video capture on the modern Mac OS). However, in no case can I capture video. No preview of the video shows-up prior to initiating the capture, and clicking on "record" in QuickTime Pro or iMovie produces nothing (literally zero byte movies - no data whatsoever is captured).

I've Googled for answers, and found indications that other people have had the same, or similar, problems, but I haven't found any answers. (At this point, I'd even settle for an explanation of why Apple seems to have screwed me.) If anyone has any insights, please share.

Owl Box Work, Sorta

As usual, I'm doing this later than I should have, but fans of Chris' Eastern Screech Owl Nest Box Cam' will be interested to know that—better late than never—I am in the process of preparing the box for owl occupation. At the moment, the major work is on fox squirrel eviction. As always, I hate kicking out the little mammals, especially when the weather has been so bad, and pups may be on the way (or arrived?), but fox squirrels have no shortage of nesting opportunities, since they can make their own nests, while screech owls depend on finding existing nesting cavities, so the owls need help and the squirrels don't. Except that the trees have now lost their leaves, so good nest building material is currently unavailable to the squirrels. Which brings me back to feeling rotten about evicting whatever sensible squirrel inevitably claims the owl box around this time of year. (Sigh.)

So, my squirrel eviction has, as of this weekend, been focused on converting a bird roosting box that I built 13(?) years ago, and that has been gathering dust in my garage for about as long, into a fancy fox squirrel nest box. I gave up on the roosting box, because, even in the coldest local weather, I never saw any indication that birds used it, and, worse, starlings would nest in it in the spring. Unfortunately, back then I was doing very simple nail & glue woodworking, not the proper woodworking of box- and dovetail-joints that I used on the modular, camera-ridden owl nest box that has served me so well for the past eleven years. So, the old roosting box needed reinforcing; refinishing (with multiple coats of exterior latex paint, instead of the so-called "waterproofing" agent I used way back when); a totally different internal arrangement; a new, relocated entryway; and so on. It also needed a mount in the relevant tree, and, because there isn't a straight limb anywhere in that tree, some means to keep the box vertical, and to provide a path from the tree to the box's entrance. Almost all of that is done now.

Also, I've brought down the owl nest box, and removed a fallen limb that had fouled the system of pulleys and cables that allow me to hoist the box in and out of the tree.

There are still plenty of problems, however. For one thing, my local owls may not be looking for a new nest site, or may have already selected another one. For another, I still haven't written the software, or added the necessary hardware, to integrate a new analog-to-digital converter to my computer and the box's infrared entryway sensor, so I'll have no way of knowing if the owls are checking-out the nest box. Also, Apple has dropped QuickTime for Java from their current system software (yes, it was always a rotten API seemingly built of bailing wire & spit, but, since they've provided no replacement, they've made this developer very unhappy). As a result, my custom frame-grabbing, noise reducing, image enhancing, image uploading and web page building code can't run on modern Macs. I'll have to bring an old Mac out of retirement, which is just that much more extra work I could do without. And, ultimately, it'll be a support burden. (Grumble.)

There's also the matter of transplanting the squirrel. It almost certainly won't cooperate with such an effort, and, yet, if all I succeed in doing is scaring it away, my recent work to create a squirrel nest box as a salve for my conscience will have been in vain. It's an imperfect plan—knew that when I started—but it's the only plan I've got.

And the cleanup job on the interior of the owl nest box is likely to be a much bigger issue than usual, due to the fact that a swarm of honeybees (or the highly misrepresented Africanized "killer" bees – who can tell which is which?), took up residence in the box this spring. By the summer they'd either moved out, or died off. In any case, the cleanup effort was begun promptly when the local squirrels raided the box for every bit of honey-laden comb they could carry off. Thank you, squirrels – good eating for you, and one less messy job for me.

Oh, and to top it all off, the punishing drought we endured this year may have killed the owl box tree, in spite of the fact that it's old, very well established, and has been through droughts before. Right now, all I know is that it dropped all of its leaves mid-summer. Maybe it went dormant at that point, and will make a comeback this spring. Or maybe it died. Not being an arborist, I know of no way to tell at this point. I'll just have to wait and see. If it died, that may not present a structural problem for years, but the owlets, after leaving the nest, tend to depend on the foliage of the nest tree for their initial shelter. If the tree is dead, there won't be any such shelter.

Problems. Always problems. (Sigh.)

Gatekeeper Released 21 Years Ago Today

Twenty one years ago today, on January 2nd, 1989, I released version 1.0 of the freeware Gatekeeper anti-virus system for Macintosh. It would have been better to note its twentieth anniversary a year ago, what with twenty being a big round number and all, but, frankly, I forgot.

Anyway, it was 21 years ago today. For reasons now obscure, it wouldn't appear in "comp.binaries.mac" until the 13th. Those reasons may have included the need to be harangued by the legendary Werner Uhrig, who wanted to know why I'd released a Macintosh anti-virus product without first running it past the secret society of Macintosh anti-virus researchers. I actually had to explain that it's impossible to communicate with a secret group, when nobody has let you in on the secret that the group exists. Based on that technicality, I think he let me off with a stern warning. And he had me promptly inducted.

Egads, what an experience Gatekeeper was. To this day, it remains the most punishing software development task I've undertaken. As a sign of things to come, before version 1.0 was even complete, it had already been scoffed at by Apple, probably costing me the chance of a job there – but the interviewer was equipped with a priori certainty that such an anti-virus system was impossible, and no amount of explanation or demonstration would convince him otherwise. After it was released, Gatekeeper seemed to earn me quiet, unshakable contempt from Apple. I never figured-out why. It was true that I believed that I'd had to write Gatekeeper to bring a measure of control to the computational public health mess that Apple had created by overlooking basically all security issues in the design of the original Mac OS (not an uncommon failing in those days, especially in the microcomputer world), but I don't remember making pronouncements to that effect. I admired (most of) Apple's work enormously then, and in spite of everything, I still do.

Apple notwithstanding, Gatekeeper went on to win me an award from the then-existent and prestigious Boston Computer Society; to be almost completely ignored by the Macintosh press (I naïvely believed then that the trade press went looking for stories relevant to its subject matter, but realized years too late that the apocalypse would be hard-pressed to get a column inch unless it sent out press releases first); to get me an all-expenses-paid trip to Scotland to deliver a paper about it (never having seen papers delivered before, I had no idea what was expected, and the less said about the result, the better); to bring me so many picture postcards from users all over the world that my local post office started to reflexively deliver postcards to me, no matter to whom they were actually addressed; to give me the opportunity to get drunk as hell on cheap gin & tonics one night with John Norstad (author of Disinfectant, and clever issuer of press-releases) at some vendor's World-Wide Developer's Conference party; to get itself written-up in an honest-to-goodness book on computer viruses that must be around here somewhere; and, over four+ years of work, to build within me such a fierce case of burn-out that when a company offered me the chance to take Gatekeeper commercial, I couldn't bring myself to do it, even though an industry insider told me that such a deal ought to be worth around a million dollars to me over a few years. I think it was ten years before I had the energy to single-handedly take on another software project of that complexity. So, if your letter or email went unanswered, now you have some idea why.

And, to my initial surprise, in something like the last four or five years Gatekeeper has risen from the dead to take on a new life as prior art in patent cases. I'd hoped to be able to announce years ago that it had triumphed in invalidating some odious software patent or other, but the case I was assured would take no more than a year dragged on for something like four, and then was resolved out of court, as I understand it. That was an interesting experience (for one thing, I had a very fine dinner with Henry Spencer, inventor of grep), but mostly it was a whole lot of no fun. And the blasted lawyers seem to have lost a major portion of the postcards I'd collected from Gatekeeper users. Now, an inquiry from a CS professor turned expert witness, suggests that it is once again involved in a patent case, and not for the last time, I expect.

When I first had the idea for Gatekeeper I thought it innovative in a "why the hell is nobody else doing this" sort of way, and the verdict of time seems to be quietly trending in my direction. So, I'd like to take this opportunity to say something to everyone at Apple who scoffed at, cold-shouldered, or otherwise entirely failed to provide an iota of support for a free product that was saving their Macintosh from itself. And that something would be this: Screw you.

Maze Wars SVG Finally Released

I’ve re-created the classic, multi-player, first-person shooter game “Maze Wars” using modern web technologies (server-side: Java; client-side: XHTML, Javascript, Ajax, and Scalable Vector Graphics). Today, that re-creation has reached beta status, and I believe is ready for general use. It's available on SourceForge, where you can find not only the GPL source, but a pre-built WAR file just waiting to be deployed to your favorite Java web application server. (I’ve only tested it with Tomcat, however.)

Work on this project began sometime around July, 2008, and after going through several periods of dormancy, is finally clean enough and feature complete enough to merit public promotion. It is based on my recollections (and a few graphics files I held onto) of playing a version written for the original Macintosh, sometime around 1987. When the consulting phone wasn’t ringing, it brought productivity to a halt among our office Mac users for several weeks. Legend has it that it had exactly the same effect on a little corporation called Apple Computer.

I’m not talking about the commercial version that eventually appeared (MacroMind “Maze Wars+”). No, this implementation was something else, and earlier. If memory serves, it had the video RAM address of the original 128K Mac hard-coded into it. I remember patching the binary several times in subsequent years to keep it working (video RAM kept moving as Macs gained memory), but eventually Macs changed enough that keeping the game working was beyond mere binary hacking, and the game effectively died. I have no idea who wrote it (let me know if you do), but thanks to whoever was responsible. A lot of people had a lot of fun with it.

(Of course, profound thanks must also go to the creators of the original Maze War game in 1973: Steve Colley, Howard Palmer and Greg Thompson.)

All these years later, I found myself missing the Maze Wars game, and decided that with Scalable Vector Graphics (SVG) resurgent among modern browsers (Safari, Firefox, and now Chrome) I might be able to recreate it for the web. And it looks very much like I’ve succeeded.

You can get some idea of what the original Macintosh game looked like, and how it built its graphics, from the following files (originally in MacPaint format) that were a part of that game.

There were the eyeballs, of course. All the players were represented by eyeballs. As you can see, they were pre-rendered in parts that could be blitted together to form an eyeball at any of the supported sizes (9) and angles (4). If it’s not obvious, the “ball” portion of each eyeball was the same for every view at any given size. It was only the middle portion that changed, which is why there are renderings of the iris and sclera facing head-on, to the left, and to the right, next to each eyeball, and that’s also why the tail, which appears on the eyeballs by default, is carefully drawn such that it stays within that middle portion of the ball – blitting an iris/sclera section onto the eyeball would completely hide the tail. By blitting (or not) a new middle segment onto each ball, any eyeball view could be created very simply. (The four images occupying the right side of the file weren’t visible in the game. They seem to be the doodlings that led the artist to the final renderings on the left side.)

My eyeballs are a bit simpler, omitting the veins in the sclera, for instance, but they’ve gained things the originals didn’t have, like gradient shadings, and individually colored irises. Seen from behind, they retain the pointed tail, because it just wouldn’t have been the same without it, but, because it took me something like three hours to work out the spline curve definitions for drawing the tail, I decided to forgo including any portion of it in the side views.

The game’s screen looked like the top half of this graphic. The first-person maze view was on the left, on the right was the maze map showing the location of yourself and the teleport stations (the circles), and, if memory serves, in the empty space below the first-person maze view was a list of players and, presumably, their scores. The first-person maze view was, like the eyeballs, built by blitting together the pre-rendered elements in the bottom two squares. Wherever a corridor branched-off the one you were looking into, a vertical slice from the right hand square was blitted over the corresponding portion of the left hand square, and—presto!—the uninterrupted walls meeting at a distant vanishing point were now interrupted wherever necessary. No drawing, as such, was required, just a lot of clever blitting together of off-screen bitmaps.

I’ve used a very similar approach in my implementation—not with bitmaps, of course, but with a collection of pre-positioned SVG wall polygons and corridor rectangles which can effortlessly be made visible or invisible by altering their “style.display” properties—because it’s wonderfully simple and effective, and remarkably authentic. It also uncomplicates the implementation in a lot of subtle but important ways, and it even, I realized, creates a rendering bug in one case. I didn’t notice that bug until I’d implemented it myself, but I’m sure it must have been present (though a bit less obvious) in the original version. In practice, I think almost no one will notice it, so I’ll leave it for you to find – or not.

There are, of course, a number of differences between my first-person rendering and the original. For one thing, there’s gradient shading so that everything fades to black by the time it reaches the vanishing point. There’s a hint of color to the floor. Stretches of wall are not featureless; they are interrupted by vertical black lines where corridors would otherwise branch off. (That may enhance the sense of perspective, but I’d’ve preferred not to have those lines. Things just kind of inevitably turned-out that way, and I couldn’t find a good work-around, or an overwhelming reason for being displeased, so the lines remain.) Teleport discs are visible in the first-person view, and they’re a very obvious blue – matched by their representation in the maze map. And, by the way, the sky is black. I’m almost certain that real killer eyeballs only come out at night, so that was a detail that needed fixing.

Other differences: On-screen instructions as you enter the game! A new, random maze for every round of the game. (However, I’ve retained the original 33 X 46 dimensions of the maze. After some experimenting, the original size seemed just right - neither too big, nor too small, for good play.) Problems with clipping long player names due to bugs in the SVG implementations of Safari, Chrome and Firefox. Bonuses for killing campers. And, last (I think), but not least: Bots, so there’ll never be fewer than ten players in the game, even if you can’t get anyone else to play.

The results look something like this, but, being rendered using SVG, they are resolution independent. So, stretch out the game window to fill your screen and everything scales-up immaculately – giant killer eyeballs!

If you’re comfortable deploying Java web applications, and believe in using modern web browsers, give Maze Wars SVG a try, and please have fun.

Parallel Number Crunching – Java and C Source Code

As requested, I've made the source code and sample data for my coplanarity scanning example programs available. These are the programs used to produce the timings shown in my previous post, “Parallel Number Crunching – Java vs. C & Grand Central Dispatch.” Feel free to experiment with them as you wish.

Note that both are hard-coded to break out of their processing loops after the first 5,999,600 planes have been checked for coplanarity with the 30,000 sample points provided in the "data/lc-data-30000.bin" file. That seemed to be a reasonable amount of computation for demonstrating the relative performance of the two implementations. If you want to try to complete the full scan of all possible planes, you'll need to remove that hard-coded break – and then you'll need to wait for a very, very long time.

The more complete Java implementation I've been using for my actual number crunching work has features like saving its processing state periodically, so the program can be quit and later resume running from roughly where it left-off. I've pulled those features out of this example code in order to keep the two implementations similar, small and straightforward.

Here’s wishing you a good night, and good coding.

Parallel Number Crunching – Java vs. C & Grand Central Dispatch

I've been doing some parallel number crunching lately using Java 1.6 (1.6.0_17) on a MacPro (4,1) with a 2.93 GHz quad-core Nehalem processor. This weekend I decided to brush the dust off my C programming skills and re-implement the core of my Java code in C using Apple's Grand Central Dispatch (GCD) technology to see if I could get a dramatic speed boost. The results were both better and worse than expected.

The number crunching in question was the examination of data from a pseudo-random number generator (PRNG). Specifically, the PRNG output was interpreted as 30,000 triplets of 32-bit signed integers. The triplets were treated as points in 3-space, and the number crunching consisted of the search for every point coplanar with every possible plane those points could define. It's been done before, of course, and found weaknesses in PRNGs like multiplicative congruential generators. For my own edification, I wanted to look for the same weaknesses in some other PRNGs. I have yet to complete a single run, however, so those who've done it in the past either used better techniques than my brute-force approach, had more than my 23 GHz to work with, or were very patient. Maybe some even used worse techniques that were faster. I don't know. In any case, I've been giving the brute-force approach a shot.

My implementation identifies coplanarity as discussed in Wolfram MathWorld: by computing the determinant of a 4X4 matrix. If the determinant is zero, the point is coplanar. The determinant computation includes a lot of multiplies that can be precomputed, because the three points that define the plane don't change for each 30,000 point test, and my code (Java and C) dutifully precomputes the lot. [Some future version of the C code may be able to bring the CPU's vector processing unit, or the GPU's resources, to bear on this problem, but I've never tried vector processing, so that's a challenge I'll leave for another time.]

With that out of the way, here are the results for checking all 30,000 points for coplanarity with each of the first 5,999,600 planes. As you'd expect, lower test times are better.

Language	Environment	Time
Java 1.6 (64-bit)	Mac OS X command line	811 secs.
Java 1.6 (64-bit)	IntelliJ IDEA 7.0.5 console	814 secs.
C & GCD (64-bit)	Mac OS X command line	658 secs.
C & GCD (64-bit)	Xcode 3.2.1 debugger console	657 secs.
C & GCD (64-bit)	Xcode 3.2.1 debugger console with GuardMalloc 18 enabled	1,814 secs.

More details: The C compiler was the one supplied with the current Xcode tools, GNU gdb 6.3.50-20050815 (Apple version gdb-1346) configured as "x86_64-apple-darwin". The Java runtime version was 1.6.0_17-b04-248-10M3025 and the virtual machine was "Java HotSpot(TM) 64-Bit Server VM" – in other words it was the current version of Java supplied by Apple for Mac OS X 10.6.2.

The results: Running on a quiescent machine, both the Java and C/GCD applications were able to push the CPU utilization to roughly 795% and keep it there at all times (the "Hyper-Threading" feature of the Nehalem cores enabled each of the four cores to act like two, so 800% was the theoretical maximum in this case). In general, Java was 23% slower than C/GCD. Personally, I'd expected Java to either closely approximate or even slightly exceed C/GCD's performance (because the Java just-in-time compiler can optimize and natively compile the code in a manner optimal to the specific hardware it finds itself running on at any given time, whereas the C compiler might make have to make more generalized assumptions), or for C/GCD to beat Java by many times. Neither outcome manifested, though the first was closest to the truth.

I think that the actual results can be interpreted in a couple of ways: (1) "C with GCD is meaningfully faster than Java for this sort of number crunching", or (2) "Java is a reasonable choice for this sort of number crunching." I lean toward the second interpretation, due to two issues. First, the Java code was, in my opinion, much cleaner, clearer and more re-usable than the C code. Second, Java is doing a lot more work for you at the same time it is crunching numbers – helpful work that can affect the reliability of your code, and/or the integrity of its results, like ensuring memory integrity and runtime type-correctness – and that's work that C mostly doesn't do at all, or does very badly, as seen in the case of running the C version of the program with GuardMalloc enabled at the cost of it taking 2.24 times longer to run than the Java program.

Those issues aside, it must be said that, for this comparatively simple program, Apple's Grand Central Dispatch and its extensions to the C language worked very well, and were easy to use. I still find the new syntax difficult, but past experience with closures, and the examples in Apple's documentation, were enough to let me produce the code I needed, in spite of that. Whether the GCD language extensions, or the GCD API, provide as complete a set of services for concurrent programming as the Java language and its "java.util.concurrent" package, I don't know. The general impression I took away from the GCD documentation was that it provides fewer features to aid the development of concurrent software than does Java, but a day's work with GCD isn't sufficient to let me judge.

To conclude: Compared to C, Java's not half bad for number crunching as I'm currently doing it (in fact, it's somewhere between merely 23% bad, and 224% good); and Apple's Grand Central Dispatch is an interesting and useful extension to the C language.

IntelliJ IDEA 7.0.x Subversion Problem Solved

Just in case I'm not the only person still using one of the 7.0.x versions of IntelliJ IDEA, be aware that if you run it with JDK 1.6 its Subversion features will not work. For example, if you pick "Browse Subversion Repository..." from the "Version Control" menu nothing will happen; you won't even get an error message. The good news is that the nice folks at JetBrains have a fix for this problem, in the form of a new version of the built-in Subversion plug-in. As a Mac user who upgraded to Mac OS X 10.6, AKA "Snow Leopard", Java 1.6 is all I can run, so this was a vital fix for me.

My thanks to Serge Baranov for his prompt and helpful response to this problem.

(And, for anyone, like me, who managed to miss it, there is an IDEA 7.0.5 release.)

* * *

P.S. Serge notes that this issue won't affect most Windows users, because IDEA 7 was bundled with an older version of Java 1.6 in which this problem does not manifest. However, users of Mac OS X 10.6 (and 10.6.1) are using Java version 1.6.0_15 (there's no choice), in which the problem does manifest. Linux users will also encounter this problem if they use Java version 1.6.0_12, or later.

Why Safari Ruins the Text in Some SVG

I recently had the opportunity to write a fun bit of software: an automatic organization chart generator that generates the chart using Scalable Vector Graphics (SVG).

Little did I know that, when I sent an example of the software's output to my boss, declaring it to be working, and rather nicely I thought, what he saw when he viewed it in Safari was a hideous mess – unrecognizably bad compared to how it looked in Safari on both of the Macs I use. For one thing, the text was incredibly ugly. Seemingly bit mapped. For another, the portions of the text that were supposed to be bold were rendered plain (and, again, incredibly ugly). To top it all off, the conformance of the text to the stated metrics was terrible. Had I known that my boss would see something so awful, I wouldn't have sent it.

It took some back and forth, but I finally figured out why the SVG looks so bad on most other people's Macs. It's a setting in the "Appearance" pane of "System Preferences"; the one at the bottom labelled "Turn off text smoothing for font sizes __ and smaller." I believe the default value is 12, though I changed the setting so long ago, I don't remember for sure. In any case, being a big believer in anti-aliased type, I always set that value to the smallest one possible, which is currently 4. In my org. charts, I was using a font size of 8 pixels. While I'm not sure how we're mapping pixels to points these days, the key was that the font size in the SVG fell beneath the system's "Turn off text smoothing" threshold. So, "unsmoothed" text was drawn, and, judging by how badly it scaled and how ghastly it looked, I think it actually reverted to a bit map.

Interestingly, Firefox ignores that setting and uses "smooth" fonts anyway. Also, Firefox, at least as of version 3.0.11 and Safari 4.0.1, draws the text much nicer (for lack of a more specific term) than Safari – even after you get Safari using "smooth" fonts. Usually I find that Safari's SVG support is better than Firefox's, but not in this case. Well done, Firefox developers.

An example organization chart is included below. It describes the structure of the U.T. Austin Computation Center in February, 1988.

A lot has changed since then. One change is that U.T. Austin no longer has a Computation Center, and is rapidly running out of people who remember when it did have one, which is a shame. Also, only a handful of the people in that chart still work for the University at all.