Actually, there are three problems:

• It's probably true that my admin is not the best. Oh well.
• The Office integration is terrible. It's an obviously bolted-on hack. Failing silently on the client is NOT alright.
• Sharepoint is oversold as a solution.

It is an expensive Wiki with marginally better Office integration than competing products. Other than the integration, it has little competitive advantage. I'm sure the ability to version control Powerpoint is useful to someone, but for me they are typically one-offs. Anything more complicated than that is best on a shared drive or in a proper version control system. Once you have all your real engineering data out of Sharepoint, it becomes a required hassle and not a tool for day-to-day work. At that point, you are depending on your engineers to document everything and be careful with metadata - which they suck at or you wouldn't have been lured by something like Sharepoint in the first place. I have trouble searching for documents that I created with known contents, let alone using it as some sort of knowledge base.

That is probably true and itself is a huge problem if you decide to go this route.

I'm not sure what the SP Admin can do to improve Office. The built-in Sharepoint Office features suuuuuck.

Unless you are collaborating with other people and part of that collaboration includes data collection. So now instead of one spot to keep everything, we have two. It's no big deal, but like I said when you avoid Sharepoint because of a shortcoming, you also lose it's benefits. In this case, we can't keep data, data collection scripts, or data analysis scripts in Sharepoint - they sit on a shared drive. Then we need ANOTHER version control system to be maintained in parallel with Sharepoint. Yay. Sharepoint is a Totally Awesome Place(c) for executives to post Powerpoints. My understanding is that Sharepoint is best left to setting up with NEW fileshares, since permissions and version problems hamper things on legacy network shares but maybe my admin is just overwhelmed.

Again, the product is fundamentally broken on the client side if a change can appear to be saved, but in fact is not. How hard would it be for Excel to write the change and then read back the file for verification? I'm sure you are right that something is not set up just right - but man, how delicate can something be?

Reliance on metadata is a flawed concept IMHO. The humans (or at least some of them) will always do the bare minimum to make the annoying box go away. Even with the best of intentions, mistakes get made. Misspellings, selecting the wrong item in a dropdown, etc. Sharepoint search struggles mightily if the metadata isn't as expected. Even Windows search works better. And again, back to the shitty integration. If you don't click the boxes (missing metadata, edit this document, trust this document) in just the right order within Office, things go to hell and you end up working on a local copy.

My admin isn't willing to open everything up. As a result I can't save files with "dangerous" extensions that might open automatically in the web browser. One big one is ".MAT" files for Matlab, which apparently also get used by Access as a shortcut. Another is ".JSL" which is a JMP script file. So our sharepoint Data folders are littered with text files that say stuff like "please go to \\someserver\datafolder to see the files for this project". Not Windows shortcuts, because God forbid MS supported their own technology in their "tightly integrated" product. And pretty Powerpoints, because that's what engineering needs is a place to stick and search for their Powerpoints.

Don't get me wrong, we had the same problem with our old Wiki. The problems that Sharepoint promises to solve are difficult and age-old (at least computer-age-old). But you can't really blame MS for overselling it, and that they most certainly do. I do not see our organization any better off for this experiment, and it is painful enough that I suspect it will go away the next time they are looking for money in the couch cushions... Sharepoint is quite expensive.

I agree that regulations are probably tighter than they were when the money was originally escrowed for decommissioning. However, it is naive to think that this won't happen and we can probably adjust the escrow amounts for future plants - if there are any.

My cynicism is probably in the 95th percentile, but even I recognize that markets have wild swings, even without "manipulation". The problem here is that you can convert a coal plant to natural gas and then back to coal relatively quickly and cost effectively as fuel prices change. Nuclear is another kettle of fish... while I won't miss a 45-year-old plant that is past it's design lifetime and of obsolete design, it won't be so easy to bring nuclear back online when it becomes cost effective to do so.

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.

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.

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".