Perian's own page, my own experience, and numerous posts scattered over the internet say Perian only adds the ability to play the mpeg2 codec, not MPEG-PS or MPEG-TS. To play those containers, you need Apple's MPEG component, which costs extra. You're the only person that has ever claimed to me that Quicktime+Perian can play MPEG files without additional software. Maybe some of your video software came with Apple's MPEG component.
And yes, Windows 7 does indeed ship with MPEG2 and MPEG4 decoders. A very simple google search will confirm that if you don't believe me.
Video hardware acceleration has been a fairly gradual progression. On the Windows side of things, what really got it going in a useful sense was the standardization of DirectX Video Acceleration in Windows 2000. Over the years video card manufacturers have implemented more and more of the video decoding pipeline. We're now at a point where basically all of the mpeg2 decoding pipeline can be done in hardware, but CPU-intensive pieces have been done for quite a while. Pre-2000 video cards like the TNT2 did mpeg2 motion compensation in hardware, and the ATI Rage Fury even did iDCT operations.
I don't know exactly what year it became really commonplace on the Windows side of things, but I can give one data point. There was significant use of hardware accelerated playback by the time I started playing around with Home Theater PCs in 2003.
Even H.264 and VC-1 acceleration isn't terribly new. The GeForce 6600 had limited H.264 and VC-1 acceleration (that was in 2004). The GeForce 8000 series and the ATI HD 2000 series both added significant hardware acceleration of H.264 and VC-1 video (that was in ~2006-2007). It's adoption was mainly hampered by the lack of support for DXVA 2.0 in Windows XP, though you still do get some benefit with DVXA 1.0 in XP too.
So I guess my point is I don't think hardware acceleration- particularly mpeg2 hardware acceleration- is a new thing. Apple has just been slow to join the party. But maybe we have different interpretations for what "new" is.
There are a lot more options for video playback on Windows. A lot more. There are extremely limited options for hardware accelerated playback on Macs. My experience over the last nearly 7 years of playing with this stuff is that software playback is not terribly reliable. Even if CPU usage is relatively low, and even if the renderer doesn't report any dropped frames, my experience has been playback is not always perfect. Sometimes it shows itself with jerky playback, sometimes with little glitches. Sometimes it only happens with interlaced video. Sometimes it only happens if you're working on the computer at the same time. A lot of little things can go wrong, and maybe a lot of people wouldn't notice. Hardware accelerated playback isn't always perfect either, but in my experience it has been noticeably more reliable. There's a reason why basically every video chipset, discrete or integrated, offloads nearly all mpeg2, H.264 and VC-1 decoding, and its not because the hardware developers got bored.
In addition, there are some things that simply aren't supported on the Mac at all. I didn't realize this until yesterday, but apparently there aren't any blu-ray players on Macs.
So that's basically why I said I think Windows is way ahead of Macs in terms of video playback.
By the way, I don't know how efficient the Windows H.264 decoder is. I have a ATI HD3850 video card that basically offloads the work from the CPU. For all I know it could be a resource hog if it needs to fall back on software decoding. What I do know is that the hardware acceleration works, and the playback quality is good.
Yep. I did. I found forum posts with very similar crash logs too.
In my case, the file in question was an HD TV show recorded over firewire. I'm not sure, but it's certainly possible that the file had errors in it. A fair number of firewire recordings do. If the problems were caused by some sort of error in video stream, should I expect VLC to play it back? I don't know. I certainly wouldn't expect them to make it a very high priority. But since I do play back firewire recordings frequently I had to look for more robust playback options- at least for the firewire recordings.
In the end I pretty much gave up on video playback on the Mac. Since nothing really supports hardware acceleration on the Mac I just bring my PC laptop along when I go on travel. The Mac just went through the battery too quickly and would get way too hot when playing back HD video.
I've had problems with VLC too. Specifically, with mpeg2 video/ AC3 audio in a TS container. Mplayer worked, as did many decoders on Windows, but not VLC.
Generally speaking, though, VLC is very very good at playing back whatever is thrown at it. I really wish it could implement hardware acceleration though.
If you check the Perian page you'll see that they don't support the mpeg container. So yes, you can play back mpeg2 encoded files, but not if they are *.mpg files. At least, not without buying the Apple MPEG component. Your files probably used a different container.
Really, I'm not a big fan of VLC when it comes to dealing with HD video either. Even on a 2.4Ghz Core2 Duo, I couldn't play back 1080i material smoothly after turning on deinterlacing in VLC.
Windows absolutely comes with an Mpeg2 decoder. In fact, Windows 7 ships with Mpeg2 and Mpeg4/H.264 decoders. They're very good too, and implement hardware acceleration. Windows XP didn't include decoders, but Vista Home Premium had the mpeg2 decoder.
And hardware acceleration is by no means a relatively new phenomenon. Mpeg2 hardware acceleration has been commonplace on Windows for many, many years. Mpeg4 hardware acceleration is relatively new, but has been supported on Vista and Windows 7. There are several options for hardware accelerated Mpeg4 decoders on Windows (including the one bundled with Win7).
Hardware acceleration isn't a trivial thing either. Decoding 1080i material is tough work. Even beefy processors often can't play back 1080i material smoothly. This is getting to be less and less of a problem, I realize, because of increases in processing power, but there's no good reason not to implement it. HTPC people have a lot of experience with this, and pretty much all of them will tell you its important to get a video card with good hardware acceleration capabilities (and decoders to go with them). My Macbook gets very, very hot playing HD video, but my Windows laptops stay nice and cool because of hardware acceleration (not to mention the impact on battery life).
I use the MKV format for my Handbrake encodes. I rip all my DVDs on to my media server. Generally I'll rip the whole movie and keep it in its native format, but I compress my TV episodes into H.264 encoded MKV files. No, MKV is a popular file format for purchased videos, but it is moderately popular for user-created/encoded videos.
Since MKV is basically just a file format, there's no reason it would be resource intensive. MKV files that you find online are often H.264 files though, and those are moderately resource intensive to play back (compared to Divx/xvid/mpeg2 files). Maybe that's why you had problems.
Windows 7 actually has very good codec support out of the box. I think every version of Windows 7, except possibly basic, includes mpeg2 and mpeg4 decoders. And they're very good. They produce high-quality output, and they make use of hardware acceleration. Really, Windows is a much, much, much better platform for video playback. I just found out yesterday that there isn't any blu-ray support on the Mac. Considering the Mac used to be the multimedia platform, this seems crazy.
I can't play back mpeg2 files. Well, I think Perian plays back the mpeg2 codec fine, but it doesn't support the mpeg file format.
Not to mention it doesn't support hardware acceleration. Not that VLC does either... That alone is enough to keep me away from Macs. I have a Mac for work and I've tried playing videos back on it, but nothing reliably plays back 1080i material, enough though its a 2.4GHz Core2 Duo based Macbook Pro.
Exactly- the tax benefits for mortgage interest is substantially more generous than for student loan interest. I really don't understand this. It seems like it should be the other way around.
In a practical sense, yes, but the generic preimage attacks against the 512-bit variant of CubeHash work better as the "b" parameter increases. It's still well above the birthday bound, so maybe people shouldn't care. But, it does mean CubeHash16/32-512 "only" provides 384 bits of preimage resistance. That's probably beyond theoretical computation limits for the universe, so I think there's a pretty good argument we shouldn't care. At the same time, all the attacks, and preimage attacks in particular, we're likely to see on 512-bit variants are likely to be well beyond anything that could seen as remotely practical.
Encryption was considered a munition for export-control purposes (technically, I think it still is), but that didn't extend to hash functions.
It will be interesting to see what NSA does with the eventual SHA-3. NSA has cleared AES for Top Secret classified information. We'll see if they do the same thing with SHA-3. If so, then you really could call it military-grade. Though, really its tamper-resistant hardware chips that sets military-grade stuff apart from commercial stuff.
I think WHIRLPOOL is probably too slow for the SHA-3 competition. NIST said they are looking for something that is at least as fast as SHA-2, and WHIRLPOOL is quite a bit slower.
Depending on what you call a revision, Bernstein just revised CubeHash. A few days ago he posted a parameter tweak that significantly increases performance at the cost of some security. You can read about his tweak on his website at: http://cubehash.cr.yp.to/submission/tweak.pdf
How is Arizona's system not susceptible to the same attacks as the more traditional notion of Internet voting systems? You still have problems with having to trust that the software on the election server isn't changing votes. You still have to hope voters aren't being tricked into going to a phishing website and giving up their voting credential- their signature. You still have to worry about malicious code on voters' computers. You still have to worry about denial-of-service attacks. So, what exactly is significantly safer about this type of Internet voting system?
Plus, this system still just relies on comparing voters' signatures for voter authentication. Do you really think the election officials and poll workers verifying these signatures are experts in signature verification? At least with Internet voting there's an opportunity to do stronger, more automated authentication, but this completely avoids that.
Digital signatures only deal with a very, very, small part of the security issues with Internet voting- authentication. The problem with Internet voting is what happens on the client-side. Is malicious code on voters' computers switching votes? Are voters being tricked to going to phishing sites performing some sort of man-in-the-middle attack? Are voters just selling their private keys to the highest bidders?
There are solutions for dealing with privacy in Internet voting systems. Look up blind signatures to get one idea. But, no one really knows how to deal with the client-side security problems. And, even if you could, you still basically end up with a glorified DRE that you can't effectively audit.
That's a little different. You don't have grocery stores buying apples with the intention of sitting on them indefinitely until apples become scarce.
If I was going to argue with myself, using agricultural examples, I'd probably use midwestern farmers with grain. Farmers grow corn and soybeans and store them quite a while until prices go up. But, even that is a little different because there's a relatively short window of time where the farmer can sell it. They don't have unlimited amounts of storage space, and the grain will eventually go bad.
You could compare real estate investment to buying and selling stocks (and many people do). But there you're really not talking about taking something that is intrinsically useful and basically letting it go to waste (or not letting it be used as 'efficiently' as possible) until prices go up.
In general there's just something a little unsettling about speculators. I've read plenty of things that indicate that they stabilize prices over the long term, but it seems like when they screw up and *really* screw up (e.g., house prices, oil, NASDAQ, etc.). I definitely don't feel very bad for the real estate investors out there that helped house prices skyrocket out of control who now own several properties worth less than they paid for them. And, I wouldn't feel bad for a domain name speculator that spends a bunch of money on a domain name only to later find it worthless for legal or technical reasons.
I certainly don't think speculation should be outlawed, or even particularly restricted. I just don't think very many speculators are doing a great service to the rest of us, and I don't feel bad for them when things go wrong.
Read your link again. Honestly, I don't know what kind of rules ICANN has, but the rules you linked to do not apply to this case. Those rules were specific to what we generally think of when we think of cybersquatters- someone who purchases a domain knowing there is a specific institution with would want it. Three out of the four items under paragraph 4b (http://www.icann.org/en/udrp/udrp-policy-24oct99.htm) specifically called out trademarks or brands, which aren't an issue in this case as the OP doesn't have a trademark yet. And, the fourth item is heavily related to trademarks and brands.
Here we have a squatter that registered a domain he thought someone at some point would desire. The squatter registered the domain without having any particular set of customers in mind, (probably) without any intent to extort an existing trademark holder, and without the intent of creating confusion about the cybersquatted domain's affiliation. As other commenters have noted, this is basically like real estate speculation. People buy property all the time with the sole intent of selling it to someone else when it becomes more valuable. I think that's a little sleazy too, but not tremendously so.
Don't get me wrong, I enjoy playing Left 4 Dead, but I was really hoping we'd finally get an update on Half Life 2: Episode 3. Left 4 Dead gets a sequel after one year, but we have to wait three years (presumably) for Episode 3?
I agree PGP never really accomplished much. However, I think you could make the argument that PGP was the first piece of software to advance the movement towards opening up crypto export controls. It brought very high-strength crypto to the masses, including any "bad guys" in other countries. I think it helped policy makers, and the public, see that crypto export controls were pretty silly when everyone had computers. So, I suppose in that way you could consider it an application that changed computing.
However, it's my personal opinion that PGP didn't do a whole lot to advance that movement. Crypto controls were a goner as soon as it was apparent e-commerce was going to take off. If I had to pick a crypto application, I'd pick SSL. SSL (now TLS) has been, and continues to be, responsible for securing most e-commerce applications.
By that standard this entire story should be modded Troll. At least, the commentary after the article blurb should be (or, perhaps, flamebait). Say what you will about the RIAA's actions here, but it's not even making a fair/accurate comparison between the AMPA's situation in 1897 and the RIAA's today. It would be more accurate to say the AMPA didn't dream of suing the recipients of the copyrighted material. It's my understanding the RIAA didn't do that either- they went after the people that [they argued] distributed the copyrighted material. Now, I agree the "making available" argument was bogus, but I can at least see their reasoning there. And, it's more consistent with going after distributors than it is recipients. It's just that P2P systems have been designed so that those two groups are the same thing.
Actually, for the most part, the A380 can takeoff and land on any runway that can handle the 747. The A380 is a bit heavier than the 747, but its weight is spread out more. The bigger problem is maneuvering around the runways and fitting next to airport gates. Neither of those should really a problem. Some airports might not be able to handle several A380s at once safely, but they could handle a single A380. And, Air Force One doesn't pull up to airport gates, so that won't be a problem either.
I strongly suspect they'll go with a Boeing aircraft, but I don't think the A380 is completely out of the question.
First of all, we already pay to be advertised to. It's called cable TV, and we pay to see that advertising in two ways: 1) in our cable bill, and 2) in our electric bill. So, I really don't see that as a problem. It just becomes part of the cost in using online and offline computer services.
Furthermore, the idea that a computer virus could wrack up charges for a user isn't new. Remember some of the dialer viruses from years past? They were viruses that would use your modem to call some 900 number in Timbuktu.
You're already paying to run seti and folding@home. Do you think you're computer uses the same amount of power when it's chugging away at full speed as when it's idling? Do you keep your computer on when you're not using it just so it can run those programs? Then it's certainly using more electricity.
As long as you're letting your computer sleep while you're not using it, it's probably not raising your electric bill too much. But, then again, they don't use that much bandwidth, so they're not likely to cost you very much in that way either.
Modern cryptography includes hash functions and message authentication codes, in addition to encryption functions. This is because you need hash functions and/or MACs to do most cryptographic protocols. Also, modern hash function design is very close to block cipher design, except that designers generally tend to side on speed versus security. That's starting to change a little bit now, after some of the recent attacks against hash functions, but it's still mostly true.
While I would agree that mere association isn't evidence of a crime, I strongly disagree with your statement that "Association is a guaranteed way of convicting an innocent person." Many crimes are conducted by groups of individuals, rather than a single person. If investigators catch an offender yet see that the crime was committed by a group of people, you know they're going to check out the offender's associates. And there's probably a pretty good chance one or more of those associates would be the co-offenders.
Slashdot Mirror
Perian's own page, my own experience, and numerous posts scattered over the internet say Perian only adds the ability to play the mpeg2 codec, not MPEG-PS or MPEG-TS. To play those containers, you need Apple's MPEG component, which costs extra. You're the only person that has ever claimed to me that Quicktime+Perian can play MPEG files without additional software. Maybe some of your video software came with Apple's MPEG component.
And yes, Windows 7 does indeed ship with MPEG2 and MPEG4 decoders. A very simple google search will confirm that if you don't believe me.
Video hardware acceleration has been a fairly gradual progression. On the Windows side of things, what really got it going in a useful sense was the standardization of DirectX Video Acceleration in Windows 2000. Over the years video card manufacturers have implemented more and more of the video decoding pipeline. We're now at a point where basically all of the mpeg2 decoding pipeline can be done in hardware, but CPU-intensive pieces have been done for quite a while. Pre-2000 video cards like the TNT2 did mpeg2 motion compensation in hardware, and the ATI Rage Fury even did iDCT operations.
I don't know exactly what year it became really commonplace on the Windows side of things, but I can give one data point. There was significant use of hardware accelerated playback by the time I started playing around with Home Theater PCs in 2003.
Even H.264 and VC-1 acceleration isn't terribly new. The GeForce 6600 had limited H.264 and VC-1 acceleration (that was in 2004). The GeForce 8000 series and the ATI HD 2000 series both added significant hardware acceleration of H.264 and VC-1 video (that was in ~2006-2007). It's adoption was mainly hampered by the lack of support for DXVA 2.0 in Windows XP, though you still do get some benefit with DVXA 1.0 in XP too.
So I guess my point is I don't think hardware acceleration- particularly mpeg2 hardware acceleration- is a new thing. Apple has just been slow to join the party. But maybe we have different interpretations for what "new" is.
There are a lot more options for video playback on Windows. A lot more. There are extremely limited options for hardware accelerated playback on Macs. My experience over the last nearly 7 years of playing with this stuff is that software playback is not terribly reliable. Even if CPU usage is relatively low, and even if the renderer doesn't report any dropped frames, my experience has been playback is not always perfect. Sometimes it shows itself with jerky playback, sometimes with little glitches. Sometimes it only happens with interlaced video. Sometimes it only happens if you're working on the computer at the same time. A lot of little things can go wrong, and maybe a lot of people wouldn't notice. Hardware accelerated playback isn't always perfect either, but in my experience it has been noticeably more reliable. There's a reason why basically every video chipset, discrete or integrated, offloads nearly all mpeg2, H.264 and VC-1 decoding, and its not because the hardware developers got bored.
In addition, there are some things that simply aren't supported on the Mac at all. I didn't realize this until yesterday, but apparently there aren't any blu-ray players on Macs.
So that's basically why I said I think Windows is way ahead of Macs in terms of video playback.
By the way, I don't know how efficient the Windows H.264 decoder is. I have a ATI HD3850 video card that basically offloads the work from the CPU. For all I know it could be a resource hog if it needs to fall back on software decoding. What I do know is that the hardware acceleration works, and the playback quality is good.
Yep. I did. I found forum posts with very similar crash logs too.
In my case, the file in question was an HD TV show recorded over firewire. I'm not sure, but it's certainly possible that the file had errors in it. A fair number of firewire recordings do. If the problems were caused by some sort of error in video stream, should I expect VLC to play it back? I don't know. I certainly wouldn't expect them to make it a very high priority. But since I do play back firewire recordings frequently I had to look for more robust playback options- at least for the firewire recordings.
In the end I pretty much gave up on video playback on the Mac. Since nothing really supports hardware acceleration on the Mac I just bring my PC laptop along when I go on travel. The Mac just went through the battery too quickly and would get way too hot when playing back HD video.
I've had problems with VLC too. Specifically, with mpeg2 video/ AC3 audio in a TS container. Mplayer worked, as did many decoders on Windows, but not VLC.
Generally speaking, though, VLC is very very good at playing back whatever is thrown at it. I really wish it could implement hardware acceleration though.
If you check the Perian page you'll see that they don't support the mpeg container. So yes, you can play back mpeg2 encoded files, but not if they are *.mpg files. At least, not without buying the Apple MPEG component. Your files probably used a different container.
Really, I'm not a big fan of VLC when it comes to dealing with HD video either. Even on a 2.4Ghz Core2 Duo, I couldn't play back 1080i material smoothly after turning on deinterlacing in VLC.
Windows absolutely comes with an Mpeg2 decoder. In fact, Windows 7 ships with Mpeg2 and Mpeg4/H.264 decoders. They're very good too, and implement hardware acceleration. Windows XP didn't include decoders, but Vista Home Premium had the mpeg2 decoder.
And hardware acceleration is by no means a relatively new phenomenon. Mpeg2 hardware acceleration has been commonplace on Windows for many, many years. Mpeg4 hardware acceleration is relatively new, but has been supported on Vista and Windows 7. There are several options for hardware accelerated Mpeg4 decoders on Windows (including the one bundled with Win7).
Hardware acceleration isn't a trivial thing either. Decoding 1080i material is tough work. Even beefy processors often can't play back 1080i material smoothly. This is getting to be less and less of a problem, I realize, because of increases in processing power, but there's no good reason not to implement it. HTPC people have a lot of experience with this, and pretty much all of them will tell you its important to get a video card with good hardware acceleration capabilities (and decoders to go with them). My Macbook gets very, very hot playing HD video, but my Windows laptops stay nice and cool because of hardware acceleration (not to mention the impact on battery life).
I use the MKV format for my Handbrake encodes. I rip all my DVDs on to my media server. Generally I'll rip the whole movie and keep it in its native format, but I compress my TV episodes into H.264 encoded MKV files. No, MKV is a popular file format for purchased videos, but it is moderately popular for user-created/encoded videos.
Since MKV is basically just a file format, there's no reason it would be resource intensive. MKV files that you find online are often H.264 files though, and those are moderately resource intensive to play back (compared to Divx/xvid/mpeg2 files). Maybe that's why you had problems.
Windows 7 actually has very good codec support out of the box. I think every version of Windows 7, except possibly basic, includes mpeg2 and mpeg4 decoders. And they're very good. They produce high-quality output, and they make use of hardware acceleration. Really, Windows is a much, much, much better platform for video playback. I just found out yesterday that there isn't any blu-ray support on the Mac. Considering the Mac used to be the multimedia platform, this seems crazy.
I can't play back mpeg2 files. Well, I think Perian plays back the mpeg2 codec fine, but it doesn't support the mpeg file format. Not to mention it doesn't support hardware acceleration. Not that VLC does either... That alone is enough to keep me away from Macs. I have a Mac for work and I've tried playing videos back on it, but nothing reliably plays back 1080i material, enough though its a 2.4GHz Core2 Duo based Macbook Pro.
Exactly- the tax benefits for mortgage interest is substantially more generous than for student loan interest. I really don't understand this. It seems like it should be the other way around.
In a practical sense, yes, but the generic preimage attacks against the 512-bit variant of CubeHash work better as the "b" parameter increases. It's still well above the birthday bound, so maybe people shouldn't care. But, it does mean CubeHash16/32-512 "only" provides 384 bits of preimage resistance. That's probably beyond theoretical computation limits for the universe, so I think there's a pretty good argument we shouldn't care. At the same time, all the attacks, and preimage attacks in particular, we're likely to see on 512-bit variants are likely to be well beyond anything that could seen as remotely practical.
Encryption was considered a munition for export-control purposes (technically, I think it still is), but that didn't extend to hash functions. It will be interesting to see what NSA does with the eventual SHA-3. NSA has cleared AES for Top Secret classified information. We'll see if they do the same thing with SHA-3. If so, then you really could call it military-grade. Though, really its tamper-resistant hardware chips that sets military-grade stuff apart from commercial stuff.
I think WHIRLPOOL is probably too slow for the SHA-3 competition. NIST said they are looking for something that is at least as fast as SHA-2, and WHIRLPOOL is quite a bit slower.
Depending on what you call a revision, Bernstein just revised CubeHash. A few days ago he posted a parameter tweak that significantly increases performance at the cost of some security. You can read about his tweak on his website at: http://cubehash.cr.yp.to/submission/tweak.pdf
How is Arizona's system not susceptible to the same attacks as the more traditional notion of Internet voting systems? You still have problems with having to trust that the software on the election server isn't changing votes. You still have to hope voters aren't being tricked into going to a phishing website and giving up their voting credential- their signature. You still have to worry about malicious code on voters' computers. You still have to worry about denial-of-service attacks. So, what exactly is significantly safer about this type of Internet voting system?
Plus, this system still just relies on comparing voters' signatures for voter authentication. Do you really think the election officials and poll workers verifying these signatures are experts in signature verification? At least with Internet voting there's an opportunity to do stronger, more automated authentication, but this completely avoids that.
Digital signatures only deal with a very, very, small part of the security issues with Internet voting- authentication. The problem with Internet voting is what happens on the client-side. Is malicious code on voters' computers switching votes? Are voters being tricked to going to phishing sites performing some sort of man-in-the-middle attack? Are voters just selling their private keys to the highest bidders?
There are solutions for dealing with privacy in Internet voting systems. Look up blind signatures to get one idea. But, no one really knows how to deal with the client-side security problems. And, even if you could, you still basically end up with a glorified DRE that you can't effectively audit.
If you're going to make everyone mail in a paper ballot, why even bother with the electronic ballot?
That's a little different. You don't have grocery stores buying apples with the intention of sitting on them indefinitely until apples become scarce.
If I was going to argue with myself, using agricultural examples, I'd probably use midwestern farmers with grain. Farmers grow corn and soybeans and store them quite a while until prices go up. But, even that is a little different because there's a relatively short window of time where the farmer can sell it. They don't have unlimited amounts of storage space, and the grain will eventually go bad.
You could compare real estate investment to buying and selling stocks (and many people do). But there you're really not talking about taking something that is intrinsically useful and basically letting it go to waste (or not letting it be used as 'efficiently' as possible) until prices go up.
In general there's just something a little unsettling about speculators. I've read plenty of things that indicate that they stabilize prices over the long term, but it seems like when they screw up and *really* screw up (e.g., house prices, oil, NASDAQ, etc.). I definitely don't feel very bad for the real estate investors out there that helped house prices skyrocket out of control who now own several properties worth less than they paid for them. And, I wouldn't feel bad for a domain name speculator that spends a bunch of money on a domain name only to later find it worthless for legal or technical reasons.
I certainly don't think speculation should be outlawed, or even particularly restricted. I just don't think very many speculators are doing a great service to the rest of us, and I don't feel bad for them when things go wrong.
Read your link again. Honestly, I don't know what kind of rules ICANN has, but the rules you linked to do not apply to this case. Those rules were specific to what we generally think of when we think of cybersquatters- someone who purchases a domain knowing there is a specific institution with would want it. Three out of the four items under paragraph 4b (http://www.icann.org/en/udrp/udrp-policy-24oct99.htm) specifically called out trademarks or brands, which aren't an issue in this case as the OP doesn't have a trademark yet. And, the fourth item is heavily related to trademarks and brands.
Here we have a squatter that registered a domain he thought someone at some point would desire. The squatter registered the domain without having any particular set of customers in mind, (probably) without any intent to extort an existing trademark holder, and without the intent of creating confusion about the cybersquatted domain's affiliation. As other commenters have noted, this is basically like real estate speculation. People buy property all the time with the sole intent of selling it to someone else when it becomes more valuable. I think that's a little sleazy too, but not tremendously so.
Don't get me wrong, I enjoy playing Left 4 Dead, but I was really hoping we'd finally get an update on Half Life 2: Episode 3. Left 4 Dead gets a sequel after one year, but we have to wait three years (presumably) for Episode 3?
I agree PGP never really accomplished much. However, I think you could make the argument that PGP was the first piece of software to advance the movement towards opening up crypto export controls. It brought very high-strength crypto to the masses, including any "bad guys" in other countries. I think it helped policy makers, and the public, see that crypto export controls were pretty silly when everyone had computers. So, I suppose in that way you could consider it an application that changed computing.
However, it's my personal opinion that PGP didn't do a whole lot to advance that movement. Crypto controls were a goner as soon as it was apparent e-commerce was going to take off. If I had to pick a crypto application, I'd pick SSL. SSL (now TLS) has been, and continues to be, responsible for securing most e-commerce applications.
By that standard this entire story should be modded Troll. At least, the commentary after the article blurb should be (or, perhaps, flamebait). Say what you will about the RIAA's actions here, but it's not even making a fair/accurate comparison between the AMPA's situation in 1897 and the RIAA's today. It would be more accurate to say the AMPA didn't dream of suing the recipients of the copyrighted material. It's my understanding the RIAA didn't do that either- they went after the people that [they argued] distributed the copyrighted material. Now, I agree the "making available" argument was bogus, but I can at least see their reasoning there. And, it's more consistent with going after distributors than it is recipients. It's just that P2P systems have been designed so that those two groups are the same thing.
Actually, for the most part, the A380 can takeoff and land on any runway that can handle the 747. The A380 is a bit heavier than the 747, but its weight is spread out more. The bigger problem is maneuvering around the runways and fitting next to airport gates. Neither of those should really a problem. Some airports might not be able to handle several A380s at once safely, but they could handle a single A380. And, Air Force One doesn't pull up to airport gates, so that won't be a problem either.
I strongly suspect they'll go with a Boeing aircraft, but I don't think the A380 is completely out of the question.
First of all, we already pay to be advertised to. It's called cable TV, and we pay to see that advertising in two ways: 1) in our cable bill, and 2) in our electric bill. So, I really don't see that as a problem. It just becomes part of the cost in using online and offline computer services.
Furthermore, the idea that a computer virus could wrack up charges for a user isn't new. Remember some of the dialer viruses from years past? They were viruses that would use your modem to call some 900 number in Timbuktu.
You're already paying to run seti and folding@home. Do you think you're computer uses the same amount of power when it's chugging away at full speed as when it's idling? Do you keep your computer on when you're not using it just so it can run those programs? Then it's certainly using more electricity.
As long as you're letting your computer sleep while you're not using it, it's probably not raising your electric bill too much. But, then again, they don't use that much bandwidth, so they're not likely to cost you very much in that way either.
Modern cryptography includes hash functions and message authentication codes, in addition to encryption functions. This is because you need hash functions and/or MACs to do most cryptographic protocols. Also, modern hash function design is very close to block cipher design, except that designers generally tend to side on speed versus security. That's starting to change a little bit now, after some of the recent attacks against hash functions, but it's still mostly true.
While I would agree that mere association isn't evidence of a crime, I strongly disagree with your statement that "Association is a guaranteed way of convicting an innocent person." Many crimes are conducted by groups of individuals, rather than a single person. If investigators catch an offender yet see that the crime was committed by a group of people, you know they're going to check out the offender's associates. And there's probably a pretty good chance one or more of those associates would be the co-offenders.