This was explained by Wizards at GenCon several years ago.
WotC is the Big Kid on the Block... very big. And as a result, WotC is slow... very slow. The products they'll be releasing six months to a year from now are already done, and in some cases, printed.
Other, smaller gaming companies are far more nimble, and can react to WotC rumors by producing simlar products, bringing them to market FIRST. So the rumor sites can hurt WotC by giving competitors ideas that can be used to reach market first.
I don't agree with it, I just repeat what I heard. One thing that puzzles me is why it takes Wizards (and White Wolf, and Paizo, and any other big gaming house,) so long to bring a product to market. Yes, they have have high quality standards (some would disagree, but I digress,) but that's no excuse to sit on a product for months after it has been completed.
We have some dupe checking code. It works often. Of course it can never be perfect.
Usually I get a good giggle out of the people that complain about the editing skills of slashdot's "editors," and don't care much about dupes, misspellings, grammar, etc.. If I wanted these things I'd read the WSJ or a "real" news site, which/. is not. As an old newsie myself, I feel your pain.
But dupe detecting code? Are you fucking kidding me? This is not a problem that needs to be solved with code! If your "editors" would read the daily article summaries, of which there are relatively few, dupes would not be a problem! Why rely on potentially faulty code when a human being is perfectly capable of doing the job in the same amount of time and with potentially greater accuracy?
Grammar and spelling checkers (and apparently dupe checkers,) have their place, but they're no substitute for a real human being with an understanding of the applicable language. If slashdot really things it's a true, journalistic news source, its editors may wish to consider returning to high school for some grammar and writing courses. But if is just a fancy blog, as I suspect it to be, then its critics should go pound sand. They're there their, its it's, dupe this and dupe that, and hieght and wieght don't bother me as long as I'm interested in the links to the stories (which should themselves be well written, thoroughly researched, and grammatically correct.)
As soon as we identified the problem, we split the team into "recovery" and "forensics." The forensics guys found the workstation that was deleting the data pretty quickly, and easily determined which script was actually doing the deletion. But that really didn't tell us WHY. We found only one "rm" in the script, but couldn't for the life of us figure out WHY it was deleting everything.
The common (and wrong) belief outside of the analysis team was that the analysis was incorrect, and that some rampant rsync has deleted everything. But on the last day before the incident report was due, we were going through the backup index of the affected workstation to finalize our report and saw the "-r" file and had one of those "ahah!" moments. A few minutes of testing proved it out. We knew from the snapshot of the affected workstation that the target directory of the 'cd' didn't exist, and figured the rest out from there.
rsync was believed to be the cause because of a previous, non-scripted and faaaar less severe incident caused by rsync's handling of trailing slashes. The following two commands may look the same, but are vastly different:
rsync -avP --delete source dest rsync -avP --delete source/ dest/
The first command will create a directory called source inside dest if dest exists. If dest/source exists, it will be updated to match source, oterwise it will be created anew.
The second command will write source on top of dest if it exists, creating it if it does not. If you intended to run the first command again after running it before, and dest also contains OTHER directories, you'll end up with a new copy of source and delete everything else in dest.
So a lot of people thought that rsync had tried to copy a directory on top of / with --delete turned on, something like:
rsync -avP --delete source:/blah/blah/ /
This would probably have been equally disasterous, but we would have seen a copy of the source data in / (assuming the delete finished and didn't wipe out system libraries and directories necessary to keep the system running,) and rsync would have taken so long creating the list to delete that it probably wouldn't have ever gotten around to the deletion. That and rsync skips deletion by default on any error, and undoubtedly would have hit one on such a large operation.
The worst/oddest I've seen went something like this:
1. Someone ran rsync with -r at the end, intending to do something recursive. This option was treated as an argument, causing a file called -r to be created. This was done in / on an HP-UX workstation.
2. Two years later, someone wrote a script to be run from cron that would run as root then change to a directory containing data files, erase them, and create new ones. This directory of data files was NFS mounted on the workstation in 1 above. Many, many other filesystems were also mounted on this workstation, all rw, all as root.
3. Some time after that, someone rebooted the workstation. Not All of the NFS mounts came up, so when the script in 2 ran as root and did not check to make sure the destination directory existed, it was not able to cd and ran in /
4. The script executed "rm -f *", intending to delete the data files. Unfortunately, the file called -r was still in / and was included in the argument list. Rm of course interpreted this as an option, so the command became "rm -f -r (everything else in/.)"
5. 3 and 4 happened on a saturday night when no one was around, so no one noticed all of the data disappearing until Monday, when it was all gone.
6. Several people had a very, very long day. Actually, several long days. A few weeks, actually.
Can you count the number of gross and avoidable administration mistakes, boys and girls?
What if it hadn't fallen off now? What if it had happened midway through launch?
I'll tell you what would have happened... some astronaut would've said "Well thank god the fucking window cover came off so we can goddamn see what's in front of us. What jacknutted imbecile left it on there in the first place?"
It's a window cover that just sits there while the shuttle is hanging out on the launchpad. It's to keep bird shit off the windscreen.
Yeah, I know they really don't actually look out the front window much during takeoff.
Yeah, if it WAS somehow left on there, and DID fall off during launch, and DID hit an engine pod at 900+ KPH, it would probably fuck it up a whole lot worse than a little piece of foam.
Not true. The bells can cut your service -- even to the point where you have no dialtone -- but you can still dial 911. You could go the the nastiest abandoned crack-house in the US, and as long as there's no physical damage to the phone lines you can dial those three magic digits.
Dunno, dude, I'm blind as a bat and have to get awfully close to my monitors. I've DEFINITELY noticed an increase in heat on my face since switching to the LCD.
Go ahead, try it... put your nose up to your LCD. Feel the heat? That's your face cooking right there. Never had that problem with a CRT before. Brain cancer, sure, but no cooked face. I'd rather be pretty than smart.
Many years ago I had one that was a random field of overlapping mouse pointers. Stop your mouse, even for a second, and you wouldn't be able to find it until it moved again. Fun trick, hours of entertainment when placed on every computer in the Mac lab and "locked" it in place.
I actually agree to an extent. Tasks do not appear to be occurring any "faster" with 64-bit SLES9. But in cases where the system is under extremely heavy load (CPU and disk IO,) the system continues to respond to other commands very quickly. Much more quickly than the same hardware with SLES9 32-bit under the same load. Hyperthreading is enabled in both cases.
Again, I'm in no way suggesting that "64-bit"ness is going to make the system faster overall. I'm simply pointing out what I've seen in some informal testing. Perhaps it has something to do with HT under EM64T, perhaps it has to do with memory, perhaps my test is flawed. But I stand by my statement that the system appears to be more responsive under the 64-bit OS.
64-bit analytical applications that can actually take advantage of 64-bit instructions (that do "64 bit math") will almost certainly see a boost in performance. Finally, we'll be able to perform simulations that require huge amounts of memory on cheap intel hardware.
I was about to make the same comment; I just picked up a 630 based system last week. I'm running 32-bit XP on it at the moment, and it is very, very fast. Of course, that doesn't say a thing about the 64-bit features. Then again, this desktop is an upgrade from a 1.4 GHz P4 mobile, so maybe I'm easily wowed.
I've run SLES9 64- and 32-bit on identical hardware with EM64T equipped Xeons for file servers, and I can definitely "feel" the difference. I don't have any hard benchmarks, but the system with the 64-bit OS definitely seems more responsive under heavy load than the 32-bit configuration.
The true test will come when we get some serious analytical apps running. Beyond the ability to allocate more memory under a 64-bit OS, I expect to see moderate performance increases, though nothing earth shattering. Time will tell.
You're forgetting that big customers get big attention. I've had storge vendors respond SAME DAY in times of crisis, bringing equipment from wherever they can just to satisfy a need.
Normal delivery times can take a long time, sure, but when a vendor can get you to think of the time they saved your ass the last time you had a disaster, they will. Because if you're thinking good thoughts about how they saved your ass, you're probably going to be more likely to buy oodles of hardware in the future.
Just for grins, I tested it with bash 2.05 and pdksh 5.2.14 on a SuSE 9.1 box with the same result. Same thing happens on RH 7.2 and 9 with ksh, too. zsh and ash... same thing.
I once saw an errant script run as a cron job (I DIDN'T WRITE IT, DAMN IT! WHY DON'T PEOPLE BELIEVE ME!!!) execute "rm -f *" in root AS root once. No big deal, right? What if someone accidentally (IT WASN'T ME!!!) created a file called "-r" in / two years prior to the errant rm? Hmm? Now what happens if you have nearly two terabytes of data mounted rw without root squashing via NFS on that workstation? Now what happens if that runs on a Saturday night and nobody notices until Monday morning?
I'll tell you what happens. What happens is that the next several days are very, very, very long and very, very, very uncomfortable.
Oh, and there was that part where (again as far as i know) if you have 3.0 core books you have to buy brand new 3.5 books all over again
Not really. WotC put out a free PDF that summarizes all of the important changes in all three of the core books and all major changes that need to be applied to supplements up to (I believe) FIend Folio. It does the trick for me. It isn't a perfect solution, but it is enough for people on a really tight budget. People at GenCon 2003 even got a printed copy.:)
It's apparently HUGE in the USN, particularly on submarines. The crewmen are trapped down in little sardine cans for months on end with little to do when not on duty, so a lot play D&D.
You know what? Just to prove it can be done, I'm going to run my next session using the rules for Chutes and Ladders... just to prove my point to, er, myself.
you have to ask if the depth of the game has been replaced by the stats that go with it. The answer has to be that the game has indeed shifted from a game of detailed and rich storytelling, such as with Ed Greenwood's additions, to a game of character advancement by hacking and slashing monsters, and people
You forget one very important thing about D&D and RPGs in general... the game is what you make of it. The system is incidental. If your GM and players all want a game about hacking and slashing, then the d20 rules will give you a great place to do that. If your group wants action, adventure, character development, intrigue, and all of the "flavor," then you can also do that within the framework that WoTC has provided with third edition. Or you could use another system. Or use no system at all.
Personally, I'm thrilled with the changes made from 2nd edition to 3rd. 3.5 doesn't sit as well, but they really did fix a lot from 3.0. But the books themselves are there as tools to help GMs (sorry, DMs) build worlds, and it's up to the storyteller to create a world in which the players can find adventure. You don't need rules for that... you need rules to keep everyone from arguing with each other when you do need to figure out what happens to the kobold when it gets hit with the +5 axe of vorpal soothing.
I assume you mean th GPSMAP 60CS; I have the same model. I gave up on the USB cable and purchased the Serial/AC Adaptor combo. My main reason for this choice wasn't laziness, but the fact that the USB cable DOES NOT PROVIDE POWER to the unit. The serial cable, on the other hand, does. Weird choice on Garmin's part, I think.
This is an interesting application of the basic premise of the plasma torch. A company called Startech Environmental has been working on the technology for quite some time. The basic gist is that if you heat just about anything hot enough, molecular bonds will break down, and you'll be left with a uniform mixture of all of the elements found in whatever you were trying to destroy. When cooled, you get a black glass and a flammable gas that can be used to power turbines that provide the power necessary to run the torch itself.
This is the first I've heard of it being used for radioactive disposal, but Startech uses it for disposing of toxic waste, biohazardous materials... all kinds of dangerous stuff.
With enough research and development, it may be possible to "skim" individual elements from the melted slag based on their density. Perfect recycling!
Slashdot Mirror
This was explained by Wizards at GenCon several years ago.
WotC is the Big Kid on the Block... very big. And as a result, WotC is slow... very slow. The products they'll be releasing six months to a year from now are already done, and in some cases, printed.
Other, smaller gaming companies are far more nimble, and can react to WotC rumors by producing simlar products, bringing them to market FIRST. So the rumor sites can hurt WotC by giving competitors ideas that can be used to reach market first.
I don't agree with it, I just repeat what I heard. One thing that puzzles me is why it takes Wizards (and White Wolf, and Paizo, and any other big gaming house,) so long to bring a product to market. Yes, they have have high quality standards (some would disagree, but I digress,) but that's no excuse to sit on a product for months after it has been completed.
Usually I get a good giggle out of the people that complain about the editing skills of slashdot's "editors," and don't care much about dupes, misspellings, grammar, etc.. If I wanted these things I'd read the WSJ or a "real" news site, which /. is not. As an old newsie myself, I feel your pain.
But dupe detecting code? Are you fucking kidding me? This is not a problem that needs to be solved with code! If your "editors" would read the daily article summaries, of which there are relatively few, dupes would not be a problem! Why rely on potentially faulty code when a human being is perfectly capable of doing the job in the same amount of time and with potentially greater accuracy?
Grammar and spelling checkers (and apparently dupe checkers,) have their place, but they're no substitute for a real human being with an understanding of the applicable language. If slashdot really things it's a true, journalistic news source, its editors may wish to consider returning to high school for some grammar and writing courses. But if is just a fancy blog, as I suspect it to be, then its critics should go pound sand. They're there their, its it's, dupe this and dupe that, and hieght and wieght don't bother me as long as I'm interested in the links to the stories (which should themselves be well written, thoroughly researched, and grammatically correct.)
As soon as we identified the problem, we split the team into "recovery" and "forensics." The forensics guys found the workstation that was deleting the data pretty quickly, and easily determined which script was actually doing the deletion. But that really didn't tell us WHY. We found only one "rm" in the script, but couldn't for the life of us figure out WHY it was deleting everything.
The common (and wrong) belief outside of the analysis team was that the analysis was incorrect, and that some rampant rsync has deleted everything. But on the last day before the incident report was due, we were going through the backup index of the affected workstation to finalize our report and saw the "-r" file and had one of those "ahah!" moments. A few minutes of testing proved it out. We knew from the snapshot of the affected workstation that the target directory of the 'cd' didn't exist, and figured the rest out from there.
rsync was believed to be the cause because of a previous, non-scripted and faaaar less severe incident caused by rsync's handling of trailing slashes. The following two commands may look the same, but are vastly different:
rsync -avP --delete source dest
rsync -avP --delete source/ dest/
The first command will create a directory called source inside dest if dest exists. If dest/source exists, it will be updated to match source, oterwise it will be created anew.
The second command will write source on top of dest if it exists, creating it if it does not. If you intended to run the first command again after running it before, and dest also contains OTHER directories, you'll end up with a new copy of source and delete everything else in dest.
So a lot of people thought that rsync had tried to copy a directory on top of / with --delete turned on, something like:
rsync -avP --delete source:/blah/blah/ /
This would probably have been equally disasterous, but we would have seen a copy of the source data in / (assuming the delete finished and didn't wipe out system libraries and directories necessary to keep the system running,) and rsync would have taken so long creating the list to delete that it probably wouldn't have ever gotten around to the deletion. That and rsync skips deletion by default on any error, and undoubtedly would have hit one on such a large operation.
The worst/oddest I've seen went something like this:
/.)"
1. Someone ran rsync with -r at the end, intending to do something recursive. This option was treated as an argument, causing a file called -r to be created. This was done in / on an HP-UX workstation.
2. Two years later, someone wrote a script to be run from cron that would run as root then change to a directory containing data files, erase them, and create new ones. This directory of data files was NFS mounted on the workstation in 1 above. Many, many other filesystems were also mounted on this workstation, all rw, all as root.
3. Some time after that, someone rebooted the workstation. Not All of the NFS mounts came up, so when the script in 2 ran as root and did not check to make sure the destination directory existed, it was not able to cd and ran in /
4. The script executed "rm -f *", intending to delete the data files. Unfortunately, the file called -r was still in / and was included in the argument list. Rm of course interpreted this as an option, so the command became "rm -f -r (everything else in
5. 3 and 4 happened on a saturday night when no one was around, so no one noticed all of the data disappearing until Monday, when it was all gone.
6. Several people had a very, very long day. Actually, several long days. A few weeks, actually.
Can you count the number of gross and avoidable administration mistakes, boys and girls?
I'll tell you what would have happened... some astronaut would've said "Well thank god the fucking window cover came off so we can goddamn see what's in front of us. What jacknutted imbecile left it on there in the first place?"
Alas, phone numbers cannot start with 1, even in St. Louis (314 area code.)
I like KeePass for password storage. It's secure, well organized, AND I get to say "Keep Ass" a lot. I don't know why that's funny, it just is.
Not true. The bells can cut your service -- even to the point where you have no dialtone -- but you can still dial 911. You could go the the nastiest abandoned crack-house in the US, and as long as there's no physical damage to the phone lines you can dial those three magic digits.
Dunno, dude, I'm blind as a bat and have to get awfully close to my monitors. I've DEFINITELY noticed an increase in heat on my face since switching to the LCD.
Go ahead, try it... put your nose up to your LCD. Feel the heat? That's your face cooking right there. Never had that problem with a CRT before. Brain cancer, sure, but no cooked face. I'd rather be pretty than smart.
Many years ago I had one that was a random field of overlapping mouse pointers. Stop your mouse, even for a second, and you wouldn't be able to find it until it moved again. Fun trick, hours of entertainment when placed on every computer in the Mac lab and "locked" it in place.
I actually agree to an extent. Tasks do not appear to be occurring any "faster" with 64-bit SLES9. But in cases where the system is under extremely heavy load (CPU and disk IO,) the system continues to respond to other commands very quickly. Much more quickly than the same hardware with SLES9 32-bit under the same load. Hyperthreading is enabled in both cases.
Again, I'm in no way suggesting that "64-bit"ness is going to make the system faster overall. I'm simply pointing out what I've seen in some informal testing. Perhaps it has something to do with HT under EM64T, perhaps it has to do with memory, perhaps my test is flawed. But I stand by my statement that the system appears to be more responsive under the 64-bit OS.
64-bit analytical applications that can actually take advantage of 64-bit instructions (that do "64 bit math") will almost certainly see a boost in performance. Finally, we'll be able to perform simulations that require huge amounts of memory on cheap intel hardware.
I was about to make the same comment; I just picked up a 630 based system last week. I'm running 32-bit XP on it at the moment, and it is very, very fast. Of course, that doesn't say a thing about the 64-bit features. Then again, this desktop is an upgrade from a 1.4 GHz P4 mobile, so maybe I'm easily wowed.
I've run SLES9 64- and 32-bit on identical hardware with EM64T equipped Xeons for file servers, and I can definitely "feel" the difference. I don't have any hard benchmarks, but the system with the 64-bit OS definitely seems more responsive under heavy load than the 32-bit configuration.
The true test will come when we get some serious analytical apps running. Beyond the ability to allocate more memory under a 64-bit OS, I expect to see moderate performance increases, though nothing earth shattering. Time will tell.
You're forgetting that big customers get big attention. I've had storge vendors respond SAME DAY in times of crisis, bringing equipment from wherever they can just to satisfy a need.
Normal delivery times can take a long time, sure, but when a vendor can get you to think of the time they saved your ass the last time you had a disaster, they will. Because if you're thinking good thoughts about how they saved your ass, you're probably going to be more likely to buy oodles of hardware in the future.
Just for grins, I tested it with bash 2.05 and pdksh 5.2.14 on a SuSE 9.1 box with the same result. Same thing happens on RH 7.2 and 9 with ksh, too. zsh and ash... same thing.
What shell are YOU using?
Try it with HP-UX 11.0:
foo:root:/tmp>mkdir -p test/subdirectory
foo:root:/tmp>cd test
foo:root:/tmp/test>touch -- -r
foo:root:/tmp/test>ls
-r subdirectory
foo:root:/tmp/test>rm -f *
foo:root:/tmp/test>ls
-r
foo:root:/tmp/test>
And no, rm -f will not delete an empty directory.
I once saw an errant script run as a cron job (I DIDN'T WRITE IT, DAMN IT! WHY DON'T PEOPLE BELIEVE ME!!!) execute "rm -f *" in root AS root once. No big deal, right? What if someone accidentally (IT WASN'T ME!!!) created a file called "-r" in / two years prior to the errant rm? Hmm? Now what happens if you have nearly two terabytes of data mounted rw without root squashing via NFS on that workstation? Now what happens if that runs on a Saturday night and nobody notices until Monday morning?
I'll tell you what happens. What happens is that the next several days are very, very, very long and very, very, very uncomfortable.
Not really. WotC put out a free PDF that summarizes all of the important changes in all three of the core books and all major changes that need to be applied to supplements up to (I believe) FIend Folio. It does the trick for me. It isn't a perfect solution, but it is enough for people on a really tight budget. People at GenCon 2003 even got a printed copy. :)
It's apparently HUGE in the USN, particularly on submarines. The crewmen are trapped down in little sardine cans for months on end with little to do when not on duty, so a lot play D&D.
You know what? Just to prove it can be done, I'm going to run my next session using the rules for Chutes and Ladders... just to prove my point to, er, myself.
You forget one very important thing about D&D and RPGs in general... the game is what you make of it. The system is incidental. If your GM and players all want a game about hacking and slashing, then the d20 rules will give you a great place to do that. If your group wants action, adventure, character development, intrigue, and all of the "flavor," then you can also do that within the framework that WoTC has provided with third edition. Or you could use another system. Or use no system at all.
Personally, I'm thrilled with the changes made from 2nd edition to 3rd. 3.5 doesn't sit as well, but they really did fix a lot from 3.0. But the books themselves are there as tools to help GMs (sorry, DMs) build worlds, and it's up to the storyteller to create a world in which the players can find adventure. You don't need rules for that... you need rules to keep everyone from arguing with each other when you do need to figure out what happens to the kobold when it gets hit with the +5 axe of vorpal soothing.
You're obviously using the wrong plants. How 'bout you EAT THEM? Make giant Corn greenhouses, or whatever.
I assume you mean th GPSMAP 60CS; I have the same model. I gave up on the USB cable and purchased the Serial/AC Adaptor combo. My main reason for this choice wasn't laziness, but the fact that the USB cable DOES NOT PROVIDE POWER to the unit. The serial cable, on the other hand, does. Weird choice on Garmin's part, I think.
Phht. Four digit ID, wife, dog, and a private getaway in the Caymans. Besides cowboyneal, who else can beat THAT?
This is an interesting application of the basic premise of the plasma torch. A company called Startech Environmental has been working on the technology for quite some time. The basic gist is that if you heat just about anything hot enough, molecular bonds will break down, and you'll be left with a uniform mixture of all of the elements found in whatever you were trying to destroy. When cooled, you get a black glass and a flammable gas that can be used to power turbines that provide the power necessary to run the torch itself.
This is the first I've heard of it being used for radioactive disposal, but Startech uses it for disposing of toxic waste, biohazardous materials... all kinds of dangerous stuff.
With enough research and development, it may be possible to "skim" individual elements from the melted slag based on their density. Perfect recycling!