Anyway Seraphim_72 is giving you the same answer. Your problem isn't SharePoint but admins that don't know how to admin SharePoint.
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.
Capable SP Admins/Consultants are relatively rare,
That is probably true and itself is a huge problem if you decide to go this route.
Your SP Admin is partly at fault, from your post it sounds like your SQL Admin, Domain Admin, and network guys all need to get on boeard with making this work right.
I'm not sure what the SP Admin can do to improve Office. The built-in Sharepoint Office features suuuuuck.
If you are trying to use SP as it is intended there are very few cases where you would move several thousand files at once.
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.
When setup right the integration reallly is that good but the big bugaboo is training.
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?
So if people aren't properly constructing their meta data...
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.
Our local SP happily hosts.bat and.exe files without issue. Hell, the.bats launch right from the browser.
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.
The integration is really good but it assumes you have a SharePoint administrator setting it up.
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.
As far as glacial file transfers that sounds like a SQLServer issue generally.
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.
SharePoint works well because it can allow deep linking within office documents to one another in a reliable version controlled way.
"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.
You can also do really powerful searches.
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.
As for not allowing extensions you need, that's definitely a configuration issue that shouldn't be happening.
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.
> 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".
It's amazing to me that people still act as if it is OK to treat the slaves so gently, like they were children. They, the Indians, and the poor white farmers were the only ones who actually knew how to live off of the land.
And once again, the Southern economy ended up collapsing anyway as a result of the war. At the time the South left the union, the thought of a sudden freeing of the slaves was unthinkable even to the vast majority of Northerners.
You don't just ban it, you migrate away from it while providing solutions to the massive hole left in the labour sector.
No, you ban it. The people that then lose their ill-gotten plantations can go pick cotton. They can consider themselves lucky that they aren't punished more directly.
The north had just spent a whole lot of money on other conflicts, and needed the resources.
The north even had slavery at an earlier point in history. Plenty of blame for slavery all around.
Slavery may not have been the direct reason cited for Southern succession, but it was most definitely the cause. Remove slavery and you have no motivation for any of the other stuff. Slavery was a major political football at the time, forcing even the admission of new states to be forced around the issue. Succession only became a real possibility once it became clear that free states would dominate the slave states politically. The South certainly had other grievances, but even collectively they don't add up to succession.
People are exactly the same as they were 150 years ago. I imagine the exact same thing would happen: Texas would declare itself independent. There would be a thorny issue of a bunch of federal property still in Texas. For a short time, there would be an uneasy peace as the Texans tolerated US forces within their borders. Eventually, someone would do something aggressive and you would have war.
Nonaya eggheads is gonna last through the zombies, man.
I think the article is firmly tongue in cheek. There is no practical use here, but it is a fun way to teach some fundamentals of geometry and statistics.
Each time I watch a two-hour movie on the 6W device, it uses around 43 kJ. On the 120W device a two-hour movie uses 864 kJ - a delta of 821 kJ per movie. Given the 2000MJ number you provide, that's over 2400 2-hour movies until break-even... might be my lifetime total.
Slashdot Mirror
Anyway Seraphim_72 is giving you the same answer. Your problem isn't SharePoint but admins that don't know how to admin SharePoint.
Actually, there are three problems:
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.
Capable SP Admins/Consultants are relatively rare,
That is probably true and itself is a huge problem if you decide to go this route.
Your SP Admin is partly at fault, from your post it sounds like your SQL Admin, Domain Admin, and network guys all need to get on boeard with making this work right.
I'm not sure what the SP Admin can do to improve Office. The built-in Sharepoint Office features suuuuuck.
If you are trying to use SP as it is intended there are very few cases where you would move several thousand files at once.
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.
When setup right the integration reallly is that good but the big bugaboo is training.
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?
So if people aren't properly constructing their meta data ...
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.
Our local SP happily hosts .bat and .exe files without issue. Hell, the .bats launch right from the browser.
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.
The integration is really good but it assumes you have a SharePoint administrator setting it up.
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.
As far as glacial file transfers that sounds like a SQLServer issue generally.
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.
SharePoint works well because it can allow deep linking within office documents to one another in a reliable version controlled way.
"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.
You can also do really powerful searches.
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.
As for not allowing extensions you need, that's definitely a configuration issue that shouldn't be happening.
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.
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".
"Live free or die"
It's amazing to me that people still act as if it is OK to treat the slaves so gently, like they were children. They, the Indians, and the poor white farmers were the only ones who actually knew how to live off of the land.
And once again, the Southern economy ended up collapsing anyway as a result of the war. At the time the South left the union, the thought of a sudden freeing of the slaves was unthinkable even to the vast majority of Northerners.
You don't just ban it, you migrate away from it while providing solutions to the massive hole left in the labour sector.
No, you ban it. The people that then lose their ill-gotten plantations can go pick cotton. They can consider themselves lucky that they aren't punished more directly.
The north had just spent a whole lot of money on other conflicts, and needed the resources.
The north even had slavery at an earlier point in history. Plenty of blame for slavery all around.
But the Civil War still boils down to slavery.
Again, I agree - but it doesn't make it any more moral to keep piling debt up for our children. The debt is a bigger travesty than overtaxing.
screw over the south economically
By "taking away their property"? Please...
Provide an economical way for the cotton fields to be harvested
There was no moral duty to prop up a fundamentally corrupt way of exploiting people.
While there is officially no slavery
Unless you are talking about the sex trade, there is nothing even close to approaching what was happening in the US South in the 1850s.
Slavery may not have been the direct reason cited for Southern succession, but it was most definitely the cause. Remove slavery and you have no motivation for any of the other stuff. Slavery was a major political football at the time, forcing even the admission of new states to be forced around the issue. Succession only became a real possibility once it became clear that free states would dominate the slave states politically. The South certainly had other grievances, but even collectively they don't add up to succession.
People are exactly the same as they were 150 years ago. I imagine the exact same thing would happen: Texas would declare itself independent. There would be a thorny issue of a bunch of federal property still in Texas. For a short time, there would be an uneasy peace as the Texans tolerated US forces within their borders. Eventually, someone would do something aggressive and you would have war.
I have to agree. I tend to fall on the "reduce spending" side of things - but top priority should be balancing the damn books.
Nonaya eggheads is gonna last through the zombies, man.
I think the article is firmly tongue in cheek. There is no practical use here, but it is a fun way to teach some fundamentals of geometry and statistics.
Each time I watch a two-hour movie on the 6W device, it uses around 43 kJ. On the 120W device a two-hour movie uses 864 kJ - a delta of 821 kJ per movie. Given the 2000MJ number you provide, that's over 2400 2-hour movies until break-even... might be my lifetime total.
You need to take it up with Dr. Seuss! :)