Make them finance the decommissioning at build time. I believe they did this in the 70s with Vermont Yankee, though clearly they screwed up. Presumably we can do better with the actuarial stuff now that some of these older plants are shutting down.

The main problem is that no one can justify building one right now. Hell, it is hard to justify the _operation_ of one. Natural gas is cheap, and even coal plants are shutting down because they cannot compete.

We do have an administrator, now internal. Originally we were using an outside vendor. Either way, I'm not sure how the administrator could be responsible for the embarrassing kludge that is the Office-Sharepoint "integration". It is so clearly a bolt-on afterthought to the whole office suite that I'm a little surprised I have to defend my position.

It could be, but this is two setups now - one with the outside vendor and one done internally. I guess they could both be clueless, but it sure seems par for the course with webdav. SMB blows it away. Try copying a folder with a few thousand files in it to Sharepoint and then perform the same action on a shared network drive.

"Works well" is where you lost me. Every once in a while, it simply fails to save the document you are editing silently. The result is that people make a local copy to work on and then upload it as a new version manually (either through webdav or through the web interface). It's a major flaw somewhere - maybe in the kludgy Office "integration", maybe somewhere else. I don't know, but it takes away the major convenience of being able to work with Sharepoint documents directly in Office.

I don't find the searches to be any better than the Twiki searches were with the Google appliance. Sure, the admin can require metadata to be filled in, but that is only as useful as the person who filled it in. And it doesn't help at all for older documents where search would be most useful.

Yes, the admin will remove them when I request... sometimes. Apparently some of them are big security problems when hosted on a "trusted" internal site so he won't unblock all of them. So I just keep my documents on the shared drive, like I always did, and they don't derive any benefit at all from Sharepoint's search. Or I zip them up to put them in Sharepoint and lose the ability to edit directly.

Yeah, Excel is obtuse compared to it's former competitors. My favorite was Quattro Pro. It took years for Excel to catch up on some features. Sadly, the macro language was primitive even by VBA standards. Later on it adopted VBA, but it was too late - I had long abandoned it.

No, we absolutely are NOT using it as a shared network drive, because it sucks for that. It uses an inefficient protocol (webdav) and so is absolutely glacial when writing many files. It also has a large black list of file extensions. We end up putting a bunch of links to files on the shared drives. One of the intentions was to make documents (and information in general) easier to find then when they were in the Wiki. It definitely has not accomplished that, but I don't fault the product for that - it seems geared toward the control freak and it delivers there. It is also sold as being integrated with Office. I'd say that while it is more integrated than any other product, the integration is half-assed, unreliable, and somewhat painful.

One of the most important pieces of career advice I've received is to make sure that people who cause pain feel the pain. It is not my job to be a whipping boy who suffers for every bad decision I tried to warn someone about. If management insists that I do something really goofy, then they should not be spared from the consequences of their plans. Insulating them only enables them to keep making bad choices and inflicting them on codependent organizations.

You say "rubbing their nose in it". I say "making sure decision makers understand the results of those decisions".

And having succeeded, they continue to use those same computers to this day.

Yes, good suggestion, especially if you already know MATLAB... they syntax and overall workflow is similar for plotting. I personally like the "Pyzo" distribution for Python.

I still find Excel plots to be faster, easier to modify, and easier to share for trivial data sets.

I really detest Sharepoint. It's the flavor of the moment at work. It's slow and saves from MS Office applications sometimes fail silently. It pretends to be a suitable replacement for shared network drives, but it doesn't work for that.

I use it rather than the old Wiki (TWiki, no gem itself) just to be a good sport, but it really sucks. It really exposes how poorly integrated MS's own internal teams must me - it is such an obvious bolt-on.

From a review of the Samsung 840 EVO 1TB SSD I just stuck in my MacBook Pro:

From the same site reviewing a WD Black 4TB HDD:

So assuming IOPS scales linearly with heads (they don't), you'd need about 1,000 heads to get similar random access performance out of HDDs as one SSD.

There's a reason everyone's migrating to SSDs for anything remotely IO related.

Excel is fantastic for exploring small sets of data... "quick and dirty" stuff. When you want rigorous statistics or a more formal analysis of data, R and friends are far superior. And anything even remotely repetitive should be done in something with a better scripting language. But I'd hate to lose Excel just as much as I'd hate to be forced to use MATLAB or Python to plot results from some small screening experiment.

And of course, we are completely deviating from Excel's forte as a financial tool, where it is much stronger.

Sometimes I'll even use it to clean up data for insertion into a database or some other such task. It has some nice built-in "Filter" functions.

Lifting should be hell on your knees, not your back. "You're doing it wrong."

The formatting is intentional, blockquoted to indicate that I am quoting it and did not write it.

> I was recently perusing the /dev directory on a next
> when I came upon the entry /dev/drum. This seemed a bit odd, I thought
> that drum memory went out of fashion long, long ago. The man pages
> didn't have anything to say about drum. Does any have any insight
> on this odd device entry?

This actually has nothing to do with drum memory. It's a part of the
UUCP system.

Long, long ago, even before version 6, somebody wanted to implement a
program to copy files between two machines running Unix. At the time
there were no modems becuase there weren't even any telephones. A
Bell Labs researcher who had just visited Africa seized upon the idea
of communicating by beating on drums, as the native Africans did. He
added a drum interface to his PDP-11 and the device driver was called,
of course, /dev/drum. Uucp would call a lower level program called
`bang' to activate this device driver. Messages could also be sent
manually by typing `bang drum' at your shell prompt. People soon
devised shell scripts that would take a mail message, convert it
appropriately, and call bang to send it. Soon they were sending
multi-hop messages though several sites this way, which is how the
`bang path' got its name.

With the advancements in communications technology (semaphores in
particular), /dev/drum was removed from UNIX around version 6 or 7, I
believe. The NeXT developers reinstated it on the NeXT because they
felt that a true multimedia machine should have as many options as
possible.

I hope this explanation helped.

cjs

curt@cynic.UUCP | "The unconscious self is the real genius.
curt@cynic.wimsey.bc.ca | Your breathing goes wrong the minute your
{uunet|ubc-cs}!van-bc!cynic!curt | conscious self meddles with it." --GBS

Yeah, standing at the register all day was rough on my body at 16... I can't imagine how my [ahem] slightly older frame would deal with it. Back then I was a "stock boy" and was much more comfortable doing the manual labor than the standing-in-one-place routine of register duty.

"Executive" is thrown around very loosely at banks. Everyone I've ever dealt with at my bank has either had the title "Teller" or "Vice President". A big bank must have thousands (tens of thousands?) of "Vice Presidents".