I didn't see anything that suggested the new replacement was coming from within; sounds like they bought a packaged solution instead of building one. From the way I read that, I'd expect the good question to ask is "would you like me to keep working on building a competitor to the product you're buying from that new vendor? I just need rights to the code I've already done." That's a pretty easy sell to the kind of business people who like to keep their options open and their vendor lock-in minimized.
That's fair, but in the context it was being brought up in (8.2->8.3 replication) you won't be using most of the semantic changes introduced by 8.3. I'm not saying Slony is ready to replicate very complicated stuff using, say, the new XML and UUID features in all circumstances today, but it shouldn't be too much headache to get it to copy an 8.2 instance into a new 8.3 one.
This is one of those things that's painful only until you've crossed a certain threshold of information, then it never bothers you again. It's better now but still harder to put the pieces together than it should be.
Start with the documentation on creating a cluster: http://www.postgresql.org/docs/current/static/creating-cluster.html In 8.3 the default of using auth you mentioned has been removed, for the reasons you described. So it now runs as unsecured for local users by default and you have to worry about this yourself, which since it reduces the frustration at getting started was deemed an improvement.
That page suggests some options you can pass to initdb to adjust the default security level. Now you want to look at the initdb docs: http://www.postgresql.org/docs/current/static/app-initdb.html See that if you use -W/--pwprompt (same thing) you can assign a password to the database superuser at cluster creation time. If you do that, you can now change the default authentication scheme to password-based (-A md5 passed to initdb will do that), you'll be secure, and you'll have one user you can login as (postgres) to create more.
To see what other authentication methods are available and to learn what your options are look at http://www.postgresql.org/docs/current/static/client-authentication.html The one you really need to dive into is pg_hba.conf which is the magic text file to edit here. A new one of those will be put in the base directory of your new database cluster. Open that file up, look at the documentation, and you'll need to add a line to add network support like one those in the examples. Probably something like
host postgres all 192.168.12.0/24 md5
(allow access to anybody on the 192.168.12 subnet access the database with a password)
And then you should be able to find your away around from there using the psql command line tool.
Note that once you get past accepting connections over the network, you could use a tool like pgAdmin III to handle the rest of this work using a slicker interface. There's even a copy of it bundled with the Windows installer you can use on such a client to administer a remote server running a real OS. It's of course possible to install pgAdmin manually on other platforms as well, see http://www.pgadmin.org/ for other verions (note that binary packages for platforms like RPM don't show up in every release, you have to go back to v1.8.0 to get the last full set of packages).
Slony is already compatible with 8.3; the current maintainer (Chris Browne) is very on top of things. There are still some rumblings about problems with the dropping of some implicit casts to text in 8.3, but they have been squashing those as reported for months now already and they may already be completely gone. Since anybody with a database big enough that they need Slony to handle version upgrades is surely going to test heavily issues there should easily be caught during that.
Intrusive schema changes? Well, I guess most DBAs don't really understand programming magic like triggers so I wouldn't be surprised they don't like it. You've already gotten a good response here commenting on that topic.
Why would you risk losing data for speed? There are so many ways to tune things and speed things up without taking such drastic measures.
The new async commit feature bypasses the requirement that records physically hit disk in order to complete a commit. If you must wait for a disk commit (typically enforced by fsync), the maximum number of true commits any one client can do is limited by the rotation speed of the hard drive; typically an average of around 100/second for a standard 7200RPM disk with PostgreSQL. There is no way whatsoever to "tune things and speed things up" here; that's how fast the disk spins, that's how fast you get a physical commit, period.
In order to accelerate this right now one needs to purchase a disk controller with a good battery-backed disk controller and pray it always works. If it doesn't, your database might be corrupted. With async commit, you can adjust the commit rate to something your disks can keep up with (say 50/second) just with this software feature while still allowing a write rate much higher than that, and at no point is database corruption possible (from this cause anyway). This makes people who want to use PostgreSQL in things like shared hosting environments have an option that allows heavy writes even for a single client while having a reasonable data integrity policy--only server crashes should ever lose you that brief period since your last true commit. That's a fair trade for some applications (think web message boards for example) and lets PostgreSQL be more competitive against MySQL based solutions in those areas.
I get some sort of pop-up (which Firefox initally blocked) within a few refreshes of every time I clear the cookies on the browser. All the ones I've been getting are for Netflix and similarly decent companies, haven't seen the adware one yet.
If the NASDAQ / DOW / S&P falls, those with higher P/E's fall faster.
That isn't necessarily true, as stocks aren't traded based strictly on P/E. The figure for how volatile a stock's price is relative to the market at large is the stock's beta. That's what tracks how fast it's expected to rise/fall relative to the market at large.
From the reports you linked to, Wal-Mart's beta is 0.25. Apple's is 1.6.
The first perfect (meaning all the possible points were collected) game of Pac-Man wasn't until 1999 and was played by Billy Mitchell. It took him 17 years of playing to get that good. Here's some background. That page has one of my favorite quotes about the ill effects of video games:
Imagine a world in which Billy Mitchell never encountered Pac-Man. Put to good use his sharp mind, excellent hand-eye coordination, incredibly long attention span and his prodigious talent for problem-solving probably would have led the world into a utopian technological society by now. The human genome would have been mapped by the mid eighties. World poverty would have been eliminated entirely. The air and the earth would be clean. We'd be living in an age of unprecedented peace. Serbs and Kosovars would be frolicking hand in hand cracking jokes about their ethnic differences. Billy Mitchell would have a girlfriend. Instead, Billy Mitchell played Pac-Man and grew a moustache.
If you're ever near Weirs Beach, New Hampshire, be sure to visit Funspot--great arcade.
I'm a pretty good Ms. Pac Man player, and I consider my game a failure if I don't get the maximum of 14600 points on the first board. If the best the AI could do is averaging 8186 points per game, I think we're still pretty far from Skynet taking over.
Presuming that InformationWeek had their typical lame coverage here, a quick search found a much better article about this at Forbes (they even know to ask Bruce Schneier about it!) where they link to a nice background article about these SCADA systems.
Here's a thought experiment game I like to play with my friends. Let's say you're locked in a room for days and forced to keep the DVD player running. The only movies you have to watch are "Super Mario Bros", "Street Fighter", and "Doom". The question, then, is: what's the best way to break a DVD in half so there's a sharp enough edge that you can kill yourself with it?
As was pointed out by several people in the recent discussion of digital watermarking, good audio watermarks will survive passing through the "analog hole" just fine.
One possible future we may be heading toward is where the DRM on every music download someone makes is a watermark on the file, perhaps personal, perhaps anonymous but still indicating the source for the download. You can do any legitimate thing, without restriction, with such a file; there may be "trusted" players that reject playing other people's files but as always these will be easy to avoid. But if you push it onto the P2P networks it will be trivial to prove you've given out an infringing file, and unlike a CD rip your download will come with an EULA that makes it more obvious you're guilty if you do that (instead of the current fuzzy "fair use" situation).
Watermarking is way scarier than regular DRM because unless you've got the source code to the watermark detector, which only runs on systems consumers and potential pirates have no access to, you have no way to know for sure if you've really removed a watermark or not. This a very different situation from the current DRM setup where all the components necessary to bypass the protection must be on the consumer's system where they can be hacked.
Wow, pretty clever--average the waves together! I'm sure none of the math geeks doing audio watermark research ever thought of that!
Like any protection scheme, it's possible to hack watermarking, but it's not trivial. Good audio watermarking can survive all sorts of transformations while still being detectable. It can certainly survive averaging, conversion to other formats or passing through the "analog hole", and similar things that defeat simple DRM implementations.
A typical audio watermark implementation adds noise to the signal at some amplitude deemed inaudible; let's call it noise at a low volume level to pick a concept people understand. Detecting the watermark is essentially listening for that unique noise. Now, if you put a watermark into two copies of the file, then average them together, you've essentially mixed the two watermark noises together. What you'll end up with is the original music plus the watermarks for both accounts, with each watermark at half its original volume. Can the watermark detector still hear the noise if it's at half its original volume? If the original watermark was "loud" enough, sure.
Now, if you have more than just two copies, maybe you can mix enough of them together such that the individual watermarks are inaudible. But the problem here is that unless you know exactly how the watermark detector works, you'll never know whether you've done that. Maybe there's a base watermark that's the same on all the files and all you've accomplished is eliminating their ability to figure out which account it came from--but they still know it's definitely an illegally distributed copy. And who knows what happens to the fidelity if you start mixing too many copies of different noise together.
The whole idea of using the fact that you have an open network as a defense if someone commits a drive-by wireless crime is ridiculous. First off, you'll be having that argument about your guilt or innocence after all your computer equipment is seized as evidence--I don't know about you, but if all my home computer were gone I'd have a tough problem keeping my job. Also, many people around where I live have the kinds of jobs (security, finance) where the minute you're arrested for something series, you're fired, regardless of whether you ultimately are innocent or guilty.
If I were as awesome as Bruce Schneier, I wouldn't worry about such things. But since I'm not I keep my network closed.
Ah, if only it were true. The underlying technology was patented by Britain defense researchers in 1991 and licensed to Verity Group, a big audio company, in 1996 (see the end of this article for a readable history here). Verity has been the company funding the money-sucking venture all this time. Even with their resources, it's taken them ten years to get this technology into the market in any big way. NXT is hardly a poster-child for quick commercial spin-off success.
You say you're a nerd who is picked on by the popular jocks. Do I have a plan for you!
1) Take a buddy nerd and sneak into a party where your victim will be (since you're a nerd you obviously weren't invited) 2) Hand the jock a beer, have your friend snap a picture during that second he's holding it (but before you're being pounded with it) 3) Post picture to Facebook using a fake account 4) Wait for jock to be suspended
I'm still trying to figure out how to fit "Profit!" into there as well. Maybe blackmail?
All these "well you shouldn't have posted the picture" posts are forgetting the very common case where someone snaps pictures of a bunch of people and posts them all onto Facebook. It's amazing how fast the camera phones can go off if you do something stupid even for a second at a party.
You've supported their claim with this comment. Right now companies spend all sorts of hands-on time doing things like fixing where "Joe in accounting" screwed up their PC. Now, in large enterprises, there would be policy in place to keep Joe from being able to do that. But small companies can't afford the infrastructure to build such cages for their employees.
But if you were a big hosting company you sure could, and then such a locked down configuration would be available without the high support costs of a local machine. I'm watching this happen in a couple of industries right now. Some of the people I help out are insurance brokers. Increasingly they don't run their largest quoting software locally anymore, which saves them a huge amount of support mess--keeping the database component of that in particular running used to be a huge mess. Instead they connect to the software provider via Windows RDT. Makes no difference to them, and now the providers have the burden of keeping everything running instead of the small offices having to care.
Once you've moved to where applications like this are the main ones you're running, it becomes easier to make the local PC be a really stripped down install where the user can't adjust anything, and if it breaks it just gets re-imaged from the master. If Joe spends all this time on a remote system anyway there's no reason for him to fiddle with local settings.
Ah, I love uppity AC's calling other people illiterate when they don't know what they're talking about. It's particularly amusing when people use "erudite" in an attempt to appear erudite while making multiple mistakes in their rest of their comments.
A quick trip to m-w.com gives me this as the 3rd entry for "deprecate":
"play down : make little of 'speaks five languages...but deprecates this facility' -- Time"
That's the usage IT has taken on; when features are still around but not recommended (are played down) because there's a better way, their use is deprecated. Your suggestion of "obsolete" implies something is no longer used at all, which is clearly not appropriate here; deprecate is.
It's not a perfect adaptation of the original word but it's not bad; language does evolve. Amusingly, use of "deprecate" as only meaning "to pray against" has been deprecated--m-w even labels that usage as "archaic".
Re:That crackling sound you hear..
on
Sony BMG Dropping DRM
·
· Score: 5, Informative
The change of heart only happening after Christmas may have been because the holiday sales of CDs this year sucked, down 20%.
This guy was in a line with (at best) 10 people in earshot of what was said, not quite worth what he's suing for if the merit is based entirely on the buyer being 'humiliated'.
The guy has enough of an obsession that he spent $24,000 on mostly Data props, and Brent Spiner told him he was ripped off. I doubt his feelings of humiliation are based on who else was in the line.
Motown records from the 60's were engineered for the limitations of AM and compressed onto 45-rpm records using the same techniques people complain about now. Take a look at http://www.helium.com/tm/293860/movie-spinal-guitarist-titular and you can see Barry Gordon was decades ahead of the current "loudness wars".
SCO substantially slowed the use of Linux in corporations by suing IBM in 2003 and threating businesses with their own lawsuits if they used Linux. Their claims were on legally shaky ground and it was obvious to anyone who looked at the short "infringing" code samples that leaked out that their case was based on either gross incompetence or downright fraud. http://en.wikipedia.org/wiki/SCO_v._IBM has a good summary of how that played out on the legal+technical side.
...and there goes your karma for not even pretending to read TFA, where they specifically mention the Luxor will be exempt.
Of course, half the other comments here make similar mistakes: they're prohibiting 100% replicas, so the idea that they're copyrighting other pyramids and similarly shaped objects also isn't true. Just exact copies of the Egyptian ones. Everything else, from Mayan structures to the treasured d4 we all roll our magic user hit points with, are just fine.
They still don't have any right to do that, but it's helpful to at least get enraged about the actual issue.
Slashdot Mirror
I didn't see anything that suggested the new replacement was coming from within; sounds like they bought a packaged solution instead of building one. From the way I read that, I'd expect the good question to ask is "would you like me to keep working on building a competitor to the product you're buying from that new vendor? I just need rights to the code I've already done." That's a pretty easy sell to the kind of business people who like to keep their options open and their vendor lock-in minimized.
That's fair, but in the context it was being brought up in (8.2->8.3 replication) you won't be using most of the semantic changes introduced by 8.3. I'm not saying Slony is ready to replicate very complicated stuff using, say, the new XML and UUID features in all circumstances today, but it shouldn't be too much headache to get it to copy an 8.2 instance into a new 8.3 one.
This is one of those things that's painful only until you've crossed a certain threshold of information, then it never bothers you again. It's better now but still harder to put the pieces together than it should be.
Start with the documentation on creating a cluster: http://www.postgresql.org/docs/current/static/creating-cluster.html In 8.3 the default of using auth you mentioned has been removed, for the reasons you described. So it now runs as unsecured for local users by default and you have to worry about this yourself, which since it reduces the frustration at getting started was deemed an improvement.
That page suggests some options you can pass to initdb to adjust the default security level. Now you want to look at the initdb docs: http://www.postgresql.org/docs/current/static/app-initdb.html See that if you use -W/--pwprompt (same thing) you can assign a password to the database superuser at cluster creation time. If you do that, you can now change the default authentication scheme to password-based (-A md5 passed to initdb will do that), you'll be secure, and you'll have one user you can login as (postgres) to create more.
To see what other authentication methods are available and to learn what your options are look at http://www.postgresql.org/docs/current/static/client-authentication.html The one you really need to dive into is pg_hba.conf which is the magic text file to edit here. A new one of those will be put in the base directory of your new database cluster. Open that file up, look at the documentation, and you'll need to add a line to add network support like one those in the examples. Probably something like
host postgres all 192.168.12.0/24 md5
(allow access to anybody on the 192.168.12 subnet access the database with a password)
That should get you past the ugly initial hurdles. The next document you may need is how to add more users: http://www.postgresql.org/docs/current/static/sql-createrole.html
again look at the examples first and then backtrack to the parameters, will make more sense that way. After that you'll want to create more databases with createdb: http://www.postgresql.org/docs/current/static/app-createdb.html
And then you should be able to find your away around from there using the psql command line tool.
Note that once you get past accepting connections over the network, you could use a tool like pgAdmin III to handle the rest of this work using a slicker interface. There's even a copy of it bundled with the Windows installer you can use on such a client to administer a remote server running a real OS. It's of course possible to install pgAdmin manually on other platforms as well, see http://www.pgadmin.org/ for other verions (note that binary packages for platforms like RPM don't show up in every release, you have to go back to v1.8.0 to get the last full set of packages).
Slony is already compatible with 8.3; the current maintainer (Chris Browne) is very on top of things. There are still some rumblings about problems with the dropping of some implicit casts to text in 8.3, but they have been squashing those as reported for months now already and they may already be completely gone. Since anybody with a database big enough that they need Slony to handle version upgrades is surely going to test heavily issues there should easily be caught during that.
Intrusive schema changes? Well, I guess most DBAs don't really understand programming magic like triggers so I wouldn't be surprised they don't like it. You've already gotten a good response here commenting on that topic.
The new async commit feature bypasses the requirement that records physically hit disk in order to complete a commit. If you must wait for a disk commit (typically enforced by fsync), the maximum number of true commits any one client can do is limited by the rotation speed of the hard drive; typically an average of around 100/second for a standard 7200RPM disk with PostgreSQL. There is no way whatsoever to "tune things and speed things up" here; that's how fast the disk spins, that's how fast you get a physical commit, period.
In order to accelerate this right now one needs to purchase a disk controller with a good battery-backed disk controller and pray it always works. If it doesn't, your database might be corrupted. With async commit, you can adjust the commit rate to something your disks can keep up with (say 50/second) just with this software feature while still allowing a write rate much higher than that, and at no point is database corruption possible (from this cause anyway). This makes people who want to use PostgreSQL in things like shared hosting environments have an option that allows heavy writes even for a single client while having a reasonable data integrity policy--only server crashes should ever lose you that brief period since your last true commit. That's a fair trade for some applications (think web message boards for example) and lets PostgreSQL be more competitive against MySQL based solutions in those areas.
I get some sort of pop-up (which Firefox initally blocked) within a few refreshes of every time I clear the cookies on the browser. All the ones I've been getting are for Netflix and similarly decent companies, haven't seen the adware one yet.
That isn't necessarily true, as stocks aren't traded based strictly on P/E. The figure for how volatile a stock's price is relative to the market at large is the stock's beta. That's what tracks how fast it's expected to rise/fall relative to the market at large.
From the reports you linked to, Wal-Mart's beta is 0.25. Apple's is 1.6.
If you're ever near Weirs Beach, New Hampshire, be sure to visit Funspot--great arcade.
I'm a pretty good Ms. Pac Man player, and I consider my game a failure if I don't get the maximum of 14600 points on the first board. If the best the AI could do is averaging 8186 points per game, I think we're still pretty far from Skynet taking over.
Presuming that InformationWeek had their typical lame coverage here, a quick search found a much better article about this at Forbes (they even know to ask Bruce Schneier about it!) where they link to a nice background article about these SCADA systems.
Here's a thought experiment game I like to play with my friends. Let's say you're locked in a room for days and forced to keep the DVD player running. The only movies you have to watch are "Super Mario Bros", "Street Fighter", and "Doom". The question, then, is: what's the best way to break a DVD in half so there's a sharp enough edge that you can kill yourself with it?
As was pointed out by several people in the recent discussion of digital watermarking, good audio watermarks will survive passing through the "analog hole" just fine.
One possible future we may be heading toward is where the DRM on every music download someone makes is a watermark on the file, perhaps personal, perhaps anonymous but still indicating the source for the download. You can do any legitimate thing, without restriction, with such a file; there may be "trusted" players that reject playing other people's files but as always these will be easy to avoid. But if you push it onto the P2P networks it will be trivial to prove you've given out an infringing file, and unlike a CD rip your download will come with an EULA that makes it more obvious you're guilty if you do that (instead of the current fuzzy "fair use" situation).
Watermarking is way scarier than regular DRM because unless you've got the source code to the watermark detector, which only runs on systems consumers and potential pirates have no access to, you have no way to know for sure if you've really removed a watermark or not. This a very different situation from the current DRM setup where all the components necessary to bypass the protection must be on the consumer's system where they can be hacked.
I'll just have to return to my previous hobby, taking pictures of Chevy trucks sporting a window sticker with Calvin peeing on the Ford logo.
Wow, pretty clever--average the waves together! I'm sure none of the math geeks doing audio watermark research ever thought of that!
Like any protection scheme, it's possible to hack watermarking, but it's not trivial. Good audio watermarking can survive all sorts of transformations while still being detectable. It can certainly survive averaging, conversion to other formats or passing through the "analog hole", and similar things that defeat simple DRM implementations.
A typical audio watermark implementation adds noise to the signal at some amplitude deemed inaudible; let's call it noise at a low volume level to pick a concept people understand. Detecting the watermark is essentially listening for that unique noise. Now, if you put a watermark into two copies of the file, then average them together, you've essentially mixed the two watermark noises together. What you'll end up with is the original music plus the watermarks for both accounts, with each watermark at half its original volume. Can the watermark detector still hear the noise if it's at half its original volume? If the original watermark was "loud" enough, sure.
Now, if you have more than just two copies, maybe you can mix enough of them together such that the individual watermarks are inaudible. But the problem here is that unless you know exactly how the watermark detector works, you'll never know whether you've done that. Maybe there's a base watermark that's the same on all the files and all you've accomplished is eliminating their ability to figure out which account it came from--but they still know it's definitely an illegally distributed copy. And who knows what happens to the fidelity if you start mixing too many copies of different noise together.
The whole idea of using the fact that you have an open network as a defense if someone commits a drive-by wireless crime is ridiculous. First off, you'll be having that argument about your guilt or innocence after all your computer equipment is seized as evidence--I don't know about you, but if all my home computer were gone I'd have a tough problem keeping my job. Also, many people around where I live have the kinds of jobs (security, finance) where the minute you're arrested for something series, you're fired, regardless of whether you ultimately are innocent or guilty.
If I were as awesome as Bruce Schneier, I wouldn't worry about such things. But since I'm not I keep my network closed.
Ah, if only it were true. The underlying technology was patented by Britain defense researchers in 1991 and licensed to Verity Group, a big audio company, in 1996 (see the end of this article for a readable history here). Verity has been the company funding the money-sucking venture all this time. Even with their resources, it's taken them ten years to get this technology into the market in any big way. NXT is hardly a poster-child for quick commercial spin-off success.
You say you're a nerd who is picked on by the popular jocks. Do I have a plan for you!
1) Take a buddy nerd and sneak into a party where your victim will be (since you're a nerd you obviously weren't invited)
2) Hand the jock a beer, have your friend snap a picture during that second he's holding it (but before you're being pounded with it)
3) Post picture to Facebook using a fake account
4) Wait for jock to be suspended
I'm still trying to figure out how to fit "Profit!" into there as well. Maybe blackmail?
All these "well you shouldn't have posted the picture" posts are forgetting the very common case where someone snaps pictures of a bunch of people and posts them all onto Facebook. It's amazing how fast the camera phones can go off if you do something stupid even for a second at a party.
You've supported their claim with this comment. Right now companies spend all sorts of hands-on time doing things like fixing where "Joe in accounting" screwed up their PC. Now, in large enterprises, there would be policy in place to keep Joe from being able to do that. But small companies can't afford the infrastructure to build such cages for their employees.
But if you were a big hosting company you sure could, and then such a locked down configuration would be available without the high support costs of a local machine. I'm watching this happen in a couple of industries right now. Some of the people I help out are insurance brokers. Increasingly they don't run their largest quoting software locally anymore, which saves them a huge amount of support mess--keeping the database component of that in particular running used to be a huge mess. Instead they connect to the software provider via Windows RDT. Makes no difference to them, and now the providers have the burden of keeping everything running instead of the small offices having to care.
Once you've moved to where applications like this are the main ones you're running, it becomes easier to make the local PC be a really stripped down install where the user can't adjust anything, and if it breaks it just gets re-imaged from the master. If Joe spends all this time on a remote system anyway there's no reason for him to fiddle with local settings.
Ah, I love uppity AC's calling other people illiterate when they don't know what they're talking about. It's particularly amusing when people use "erudite" in an attempt to appear erudite while making multiple mistakes in their rest of their comments.
A quick trip to m-w.com gives me this as the 3rd entry for "deprecate":
"play down : make little of 'speaks five languages...but deprecates this facility' -- Time"
That's the usage IT has taken on; when features are still around but not recommended (are played down) because there's a better way, their use is deprecated. Your suggestion of "obsolete" implies something is no longer used at all, which is clearly not appropriate here; deprecate is.
It's not a perfect adaptation of the original word but it's not bad; language does evolve. Amusingly, use of "deprecate" as only meaning "to pray against" has been deprecated--m-w even labels that usage as "archaic".
The change of heart only happening after Christmas may have been because the holiday sales of CDs this year sucked, down 20%.
At least my open-source web browser warns me when I misspell "corporate" while trolling.
Yeah, it's a shame the copies of RHEL5 I deployed earlier this year will only be supported until 2014. Barely any time at all to test them.
The guy has enough of an obsession that he spent $24,000 on mostly Data props, and Brent Spiner told him he was ripped off. I doubt his feelings of humiliation are based on who else was in the line.
Motown records from the 60's were engineered for the limitations of AM and compressed onto 45-rpm records using the same techniques people complain about now. Take a look at http://www.helium.com/tm/293860/movie-spinal-guitarist-titular and you can see Barry Gordon was decades ahead of the current "loudness wars".
Chuck Norris doesn't fly on planes. He jumps and roundhouse kicks the world, and when it's spun underneath him to his destination he lands.
SCO substantially slowed the use of Linux in corporations by suing IBM in 2003 and threating businesses with their own lawsuits if they used Linux. Their claims were on legally shaky ground and it was obvious to anyone who looked at the short "infringing" code samples that leaked out that their case was based on either gross incompetence or downright fraud. http://en.wikipedia.org/wiki/SCO_v._IBM has a good summary of how that played out on the legal+technical side.
...and there goes your karma for not even pretending to read TFA, where they specifically mention the Luxor will be exempt.
Of course, half the other comments here make similar mistakes: they're prohibiting 100% replicas, so the idea that they're copyrighting other pyramids and similarly shaped objects also isn't true. Just exact copies of the Egyptian ones. Everything else, from Mayan structures to the treasured d4 we all roll our magic user hit points with, are just fine.
They still don't have any right to do that, but it's helpful to at least get enraged about the actual issue.