I do agree with your suggestion of providing more than one medium, though I would caution that interface specs tend to change more frequently than actual media. I'd worry a bit about electrical formats still being compatible in ten years, much less 25. Maybe you'd get lucky, though.
Of those formats, despite being the oldest format, IMHO, the CD is most likely to still be around. The DVD will likely be deprecated soonest because newer formats do a much better job. That doesn't mean nothing will read them, but video formats seem to have a much shorter shelf life than audio formats historically. Laserdisc's 30th anniversary is this year. Anybody know where I can find a player? Even VHS only lasted 30 years between its first and last major commercial releases. A CD, by contrast, is still "good enough" for mass music consumption 26 years after its inception and is showing no real signs of being replaced (except to some degree by downloads) despite numerous attempts to do so.
I see no reason to believe people will not still be playing CDs 25 years from now even if newer formats become more popular. Some people (who will remain nameless) will probably still be playing 45s in 25 years.... The point is that if people still want to play them in 25 years, odds are good that computer optical drives will still exist to support that desire, so the CD format seems relatively safe. For that reason, I would suggest a stack of CDs in UDF Bridge format. That way you have twice the chances of it working---an ISO-9660 filesystem and a UDF filesystem on the same media. Any disk format specific to one brand of computer is likely to be forgotten in 25 years, but ISO-9660 has been around long enough that it is supported pretty universally 22 years later. Thus, it seems likely that it will still be at least somewhat supported in 25 years even if UDF and the video disc formats based on it fizzle.
Now whether the format of the data files themselves will be safe or not is another question. Anybody remember PICT? Anybody try to open one recently?:-) For this reason, I would suggest multiple copies of the data in different formats--JPG, TIFF, maybe PNG. If you're really paranoid, you could include an uncompressed "raw data" format containing nothing but RGB triples or RGBA quads (3 or four bytes per pixel) containing each pixel's value in order across the top row, then the next row, etc. Include an info file for each image that tells the image size so that someone trying to read the file can easily determine where to split the lines. Also include an ASCII file somewhere on each piece of media that briefly describes the trivial structure of those uncompressed image files. With that info, any programmer with an ounce of skill should be able to reconstruct the image from the raw data in ten minutes even if nobody remembers what a JPEG, TIFF, or PNG file is.
Not necessarily. The iPhone supports both the headset profile (HSP) and the hands-free profile (HFP). You are correct that many hands-free devices use the headset profile (or support both profiles), though.
The drunk driving prevention campaigns (traffic stops, etc.) have significantly cut down highway deaths around the holidays, so at least there are hard numbers people can point to and say "this is helping", unlike traffic light cameras that seem to be frequently abused for the purposes of raising revenue. That's where I draw the line, personally. It is not unreasonable to expect people to not show reckless disregard for the safety of others even if they get lucky and nobody gets hurt. That's what drunk driving is. It is no less bad than cutting somebody off and swerving between lanes; if somebody does that, it seems perfectly reasonable to punish them for recklessness. I see drunk driving laws as largely the same thing.
That said, I do agree with you that open container laws are idiotic. If you haven't been drinking it, transporting it is irrelevant. It strikes me as primarily a way for officers who haven't met their quota to jail or fine somebody who they believe has been drinking even if the BAC evidence says they haven't. The obvious completely legitimate example that these laws prohibit is somebody carrying a half-consumed bottle of wine from a friend's house because the friend didn't like it. You can't put it in your trunk because it has been opened, so the cork might come out while it is rolling around, and then you'd have a horrible mess, so your passenger holds it or you wrap it in a blanket on your passenger seat and strap it in or whatever. That's not in any way contributing to drunk driving or reckless driving on the roads, but in many places, it is still technically illegal.... That's where the laws cross the line from preventing reckless disregard to being paranoid nanny state behavior. I'm not convinced that those laws do enough occasional good relative to the widespread inconvenience to meet the quality threshold that we should expect from our laws. I'm also not convinced the harm is bad enough to bother doing anything about it. It's in that fuzzy grey area between the two.:-)
I do agree also that random road blocks are pushing the limit a bit, if only because they are a major inconvenience to a lot of people and are a tremendous waste of resources that could be better spent elsewhere. I think it would be far more effective to station cops randomly outside local bar and liquor store parking lots to pull over people who get in their cars while unable to walk in a straight line... and prosecute the bar owners for not enforcing laws requiring that they take the keys and call a taxi for patrons who seem incapacitated when they leave. Unfortunately, in our sue-happy culture, bar owners would probably claim some kind of discrimination and get a damage award from the city/county/state.... *sigh*
No more unreasonable than requiring people to wear their driver's license in a plastic badge holder while walking on public sidewalks. Papers, please.
It should certainly be illegal to use such a tactic to evade a toll. That said, if you are not breaking the law, the only thing they truly have a legitimate need to see is the little colored sticker that says whether your plate has expired or not. Other than that, their "need" to read the plate and identify you is nothing more than a figment of their power tripping imaginations.
Emulation still counts as a crack. Regardless of whether somebody emulates the dongle or rips out the code that checks for it, the end result is the same: people using the software without paying for it. Most legitimate software doesn't use dongles, so it's pretty hard to think of dongle software that has been cracked merely because I can only think of about a handful of software I've ever encountered that used dongles (all of which has cracks available, most of which are reported to work better than the uncracked versions...).
My biggest objection to dongles is that if every >$200 piece of software I own used a dongle, I'd have to design a battery-powered 16-port USB hub to carry around with my laptop. Life's too short to put up with that bullshit. So I have a very simple rule: dongle = no sale. I've even rejected software made by companies that my employer owned at the time and bought competing products instead solely because of dongles. That product team subsequently dropped the dongles and I bought a copy the next week. So if anyone thinks dongles are a win, bear in mind that for every person who was prevented from using the app because of the dongle, that's one person using a competing product that they could crack, so if even a single pirate goes legit, stronger copy protection becomes a net loss for the company. And for every ten people who were prevented from using it illegally, there's one pissed off customer who was prevented from using it legally who will never buy anything from your company again and probably five people who took one look at the dongle and said "screw that", so it's still a net loss.
The only way copy protection is a win is if it forces people to "go legit". Outside of the video game product space, I have seen no evidence whatsoever that this occurs. Ever. In every case, when I heard somebody complaining on a message board about not being able to pirate a new version of something, there have been fifty people replying, all saying things like "You could try [insert free product here]." About the only people I've seen gain market share because of anti-piracy measures are free or inexpensive products like Ardour, Audacity, and Reaper.
Anyway you cut it, dongles are fundamentally evil. If you're finding that a large percentage of your users are stealing the software, it usually means that you've priced your products above what some significant portion of the market can bear. If you don't cater to that market segment (either by providing a low end version or by putting up with the piracy), then you can bet somebody else will, and those low end users will end up upgrading to that other company's high end software someday instead of yours. It is as simple as that.
These days, most folks have given up ripping out the dongle code because it is too pervasive and instead just emulate the dongle in software. The result, of course, is that the application performance is dramatically decreased by the amount of excess copy protection code.
Waves 6 came out in July and there are cracked versions available already (though I'm not remotely crazy enough to DL them and see if they're legit...). Once you consider that it probably took a couple of weeks from when they started shipping it to when anybody actually got a copy to start working on cracking it, that puts the crack time at about two weeks. A little more than a week, but not that far off. It may also have been added a while back. It looks like every warez torrent was just added within the last few days, so I have a feeling those dates there are not a useful indicator of when the crack came out.:-)
Then, there was Mac OS X. That protection lasted all of two or three weeks after its Intel release, IIRC, and that involved all sorts of customer driver and bootloader work. Each update since has been released within a week or so of the Apple release.
I'm struggling coming up with a third because I'm only familiar with one other app that has dongle protection and it was released long enough ago that I'm having a hard time determining when it was first cracked.:-)
You can't convince me that any of the current protections are any more effective than the protections of the past. In general, if a crack for a piece of software isn't available, it is because either A. nobody thinks it is important enough to bother cracking it or B. all of the people trying to crack it are relatively inexperienced at that sort of thing, not because it is hard to crack....:-)
And when that dongle goes bad, gets lost, gets stolen, gets run over by a truck outside a gig, etc., your $1000 piece of software is now worthless, and generally speaking, the manufacturer expects you to buy a whole new copy, though some will replace it at a reduced rate. Either way, I make it a rule never to buy software with dongles. If everybody did that, such unscrupulous practices would stop....
The thing is, dongles don't actually protect against the real pirates at all. They last maybe a week in the face of someone determined to crack an app, and usually less than a day. The extra six days are spent adding the spyware into the cracked app.:-D All the dongles really do is cause problems for legitimate customers and raise the price of the product.
Further, it is highly unlikely that anything the hardware manufacturers could do for these game publishers would make the slightest dent in piracy. Why? Ultimately, there's a piece of executable code that is being loaded into memory. Any protection measure will eventually result in unencrypted executable sitting in memory. That executable code can then be changed. Period. Believing in software copy protection requires the same fundamental logical flaw as believing in DRM.
Then, there's the question of whether it is worth protecting against at all. I'm of the opinion that piracy generally helps the software industry (except for games). No, I don't advocate piracy, but in my experience, most of the people who pirate software (not including commercial pirates) are people who can't afford the software at the time. Often, this can be combatted by offering low-end versions of the software and/or reducing the price to a more reasonable price point.
In any case, those people who can't afford it usually end up buying the software (assuming that they like it and have a good experience with it) once they are out of college and are no longer poor.... Even if they don't, however, they are creating an entrenched user base for the software, recommending it to their friends when people ask for suggestions, and creating files that often won't work as well (or at all) with competing products, thus contributing to vendor lock-in by other people who do buy the software.
For games, however, the story is a bit different. Games rapidly become less valuable once you've had them for a while. That's why the game publishers are terrified of piracy. They know that if people get their hands on pirated copies of a game, they are likely to play it for a couple of days, then stop playing without buying it. (The game publishers face basically the same situation as the music industry with its low quality pop music, and for precisely the same reasons.)
This leaves them three options:
Figure out why people are pirating the game and fix the problem. If that means lowering cost, lower the cost. If that means providing online sales, sell it as a downloadable package.
Figure out why the games don't have enough staying power that the users eventually decide "I've enjoyed this for a long time, so maybe I should buy a real copy." If that means adding more levels, add more levels. If that means adding more complexity, add more complexity. If that means giving out a free demo to whet their appetites, give out a free demo that is long enough to be worth playing on its own. If that means adding multiplayer online content that requires an account, go for it.
Continue to whine and moan about how everybody is against them while putting more and more draconian anti-piracy hacks into their code and lowering the quality of game play for legitimate users while utterly failing to prevent piracy.
Guess which two of these are likely to be effective solutions.... Guess which one of these they actually do more often than not.... Guess why they're losing their self-declared war.
Huh? The people providing the VOD service are the same people who provide the software that manages the caching, and the same people renting out the hardware involved (cable boxes)....
How do you multicast when each household can decide to start, pause, stop, fast-forward and rewind the video whenever they want?
Simple. I explained it in my post, though I didn't provide the details. You immediately add that user to a multicast group whose members are close by. Then, you multicast it to that user individually up to the point where it catches up with the main multicast stream. If somebody else joins, that somebody else joins both multicast streams up to some reasonable maximum number of streams. You then use the hard drive as a cache to buffer all the data from both the unicast "catch-up" stream and the multicast stream, then glue it all together when the user plays it back. When the user pauses, the computer continues to store the data from the stream. You should also probably provide a mechanism for re-requesting blocks that get dropped. That prevents a network glitch from casing you to lose data unless you're playing the unicast catch-up stream without enough buffering lag-benhind (and even then, it would mean that if you cared enough to hit the "skip back 7 seconds" button, it wouldn't glitch because your machine would have re-requested it..
Fast forward is the same. You open a new multicast stream and add everybody else to it, then continue to cache both streams. When the "everybody else" stream catches up with the start of this user's stream, you stop sending data on that stream except to new users who joined after the stream split.
It is an unholy amount of management on the server end to manage all the streams, but from a client perspective, it is pretty simple. The only change required to VOD receivers is that every client must have a hard drive. In this day and age, that's really not such an onerous requirement. That said, if there were some legacy clients, it would just provide additional pools for other receivers to stream from, at least up to a point. You'd probably have to make them wait to start playing a bit and maybe not allow them the same level of control, but again, these are legacy clients we're talking about here.
So set the limit at 6 Mbps. What, you mean Comcast can't deliver a continuous 5Mbps to all their customers? Are you telling me they oversold their bandwidth? Say it ain't so.:-D
But seriously, the right solution is to make VOD use multicast and treat multicast rates as the number of bytes streamed divided by the number of clients. Use the local hard drive as a very large cache, and by the end of the movie, you have the whole thing on your HD and aren't consuming any bandwidth. The notion of "live" streaming of movies off a hard drive in some server farm in a unicast client-server style is so 1985 (prior to RFC-966). After all, this is precisely what multicast was designed to do. If it doesn't get the job done, create a new RFC and a new underlying packet routing protocol that does, but could the cable companies PLEASE quit jerking everybody's chain and saying "Oh noes, VOD can haz mor bandwidth?" It got tiresome ten years ago. Now, it no longer qualifies as comedy and falls squarely into the bucket marked "that's just sad".
Sockets are somewhat easier to patent than instruction sets, though, as they represent an actual invention, while an instruction just represents a fact---if I see this bit sequence, I perform the following mathematically definable operation. While I don't doubt that there are plenty of patents on instruction sets, I do doubt that any of them would be upheld in court if push came to shove and the opposing counsel were competent.... The only reasonably strong instruction set patents are the ones that define the hardware needed to implement them. If, however, you can find a way to implement them with a hardware implementation that looks sufficiently different, though, you've just worked around the patent.... The ones that merely attempt to define what the hardware should do if presented with a particular instruction are pure comedy, as they are a pretty blatant example of purely algorithmic patents, which aren't allowed in the U.S.
AFAIK, the VIA Nano supports all of those four instruction sets (Intel 64 and AMD64 are basically the same ISA). None of them are specific to Intel or AMD anymore.
It is not necessary for things to be as bad as they can possibly be before one has the right to complain about things that are wrong. The U.S. has in many ways grown greatly more totalitarian over the past eight years. Saying "It's not as bad as China, so the problems don't matter" is the height of idiocy. That's like saying "Linux doesn't crash as much as Windows, so it must be perfect.
Indeed, it is precisely because people do appreciate those freedoms that they rant about signs of growing fascism in the U.S. government. They who have never seen the light cannot know that they live in darkness, and so do not complain. Therefore, I would contend that the people who do not rant are the ones who do not fully appreciate those freedoms.
They'd need to be clearly differentiated from literals -- maybe even require literals to be quoted.
No. That's exactly the opposite of what we need. It should be harder for something to not be a literal. If I were designing a regexp language, I would make it so that the contents of variables are always automatically quoted---none of this \Q and \E crap. You should have to add additional stuff around a variable to get the non-quoted behavior. This is the most common bug I've found in Perl code---user-entered text treated as part of an expression when it shouldn't be.
The problem is that regular expressions are often used for things that they aren't suited for. As soon as you add look-behind and crap like that, you're already beyond usable regular expressions. At that point, you need to take a step back and look at the problem again. Chances are, you'll find that the problem would be solved better programatically with a few lines of code rather than a jumbled, cryptic regexp that no one can understand without staring at it for five minutes. (Of course, it doesn't help that half the time, there's no comment before that snarled mess of a massive, bloated regexp to tell what it does....)
Regexp is good for quick text processing. As soon as you're writing things in it that would be better served by a proper parser, you're just asking for maintenance problems of the "Oh, this declaration formatting code doesn't indent correctly when the user puts a struct nested in another struct nested in a typedef struct:" variety.
No, no, no. It's not "almost" fusion. It is fusion. It is almost a fusion generator. That doesn't mean fusion isn't occurring. It means that the reaction is not self-sustaining. There's a huge difference. Saying that it isn't fusion is like saying that a match placed in a sealed jar and set ablaze using a laser isn't really fire because it consumes all the oxygen and burns out and there's no way to add more oxygen....
Well, as I understand it, there is some experimentation with that in the labs, but mostly at a microscopic level with a fixed substrate instead of a spinning disc.
I suspect the main reason not to do that is the complexity of doing thermal calibration for several times as many heads. Add to that the increased risk of head crashes because there are more of them to crash, then add the extra risk of head failure because there are more of them to fail, and you have a recipe for disaster. Oh, and there's also the extra space needed for the extra head arms. Not sure how much of a constraint that is.
That said, rotational latency is just a small part of total HD performance (on average), so a lot of it may be simply a reluctance to add lots of extra hardware to improve things by such a relatively small amount....
Anecdotally, I've met all of three people who admitted to being Republicans over my 9 years in the industry. On the other hand, this is the California part of the tech industry, so a good part of that may be the overall regional demographics interfering with any attempt to isolate the tech population.
To avoid a DMCA violation, the unescape function is left as an exercise for the reader. Hint: the hex function converts hex to base-10 integers, and printf can be used to convert numerical ASCII values into the corresponding characters....
Two minor mistakes. To avoid losing the initial prior to a block of actual JavaScript, you need to insert this line:
if ($1 eq "eval") { print $lastscript; }
after:
if ($part =~ s/^.*(eval|hp_d00)\(unescape\(["']//s) {
Also, while this is only a problem if you do a "use strict", you should add:
Slashdot Mirror
The CD-R spec was published in 1988, not 1998. I assume that was a typo.
I do agree with your suggestion of providing more than one medium, though I would caution that interface specs tend to change more frequently than actual media. I'd worry a bit about electrical formats still being compatible in ten years, much less 25. Maybe you'd get lucky, though.
Of those formats, despite being the oldest format, IMHO, the CD is most likely to still be around. The DVD will likely be deprecated soonest because newer formats do a much better job. That doesn't mean nothing will read them, but video formats seem to have a much shorter shelf life than audio formats historically. Laserdisc's 30th anniversary is this year. Anybody know where I can find a player? Even VHS only lasted 30 years between its first and last major commercial releases. A CD, by contrast, is still "good enough" for mass music consumption 26 years after its inception and is showing no real signs of being replaced (except to some degree by downloads) despite numerous attempts to do so.
I see no reason to believe people will not still be playing CDs 25 years from now even if newer formats become more popular. Some people (who will remain nameless) will probably still be playing 45s in 25 years.... The point is that if people still want to play them in 25 years, odds are good that computer optical drives will still exist to support that desire, so the CD format seems relatively safe. For that reason, I would suggest a stack of CDs in UDF Bridge format. That way you have twice the chances of it working---an ISO-9660 filesystem and a UDF filesystem on the same media. Any disk format specific to one brand of computer is likely to be forgotten in 25 years, but ISO-9660 has been around long enough that it is supported pretty universally 22 years later. Thus, it seems likely that it will still be at least somewhat supported in 25 years even if UDF and the video disc formats based on it fizzle.
Now whether the format of the data files themselves will be safe or not is another question. Anybody remember PICT? Anybody try to open one recently? :-) For this reason, I would suggest multiple copies of the data in different formats--JPG, TIFF, maybe PNG. If you're really paranoid, you could include an uncompressed "raw data" format containing nothing but RGB triples or RGBA quads (3 or four bytes per pixel) containing each pixel's value in order across the top row, then the next row, etc. Include an info file for each image that tells the image size so that someone trying to read the file can easily determine where to split the lines. Also include an ASCII file somewhere on each piece of media that briefly describes the trivial structure of those uncompressed image files. With that info, any programmer with an ounce of skill should be able to reconstruct the image from the raw data in ten minutes even if nobody remembers what a JPEG, TIFF, or PNG file is.
Not necessarily. The iPhone supports both the headset profile (HSP) and the hands-free profile (HFP). You are correct that many hands-free devices use the headset profile (or support both profiles), though.
The drunk driving prevention campaigns (traffic stops, etc.) have significantly cut down highway deaths around the holidays, so at least there are hard numbers people can point to and say "this is helping", unlike traffic light cameras that seem to be frequently abused for the purposes of raising revenue. That's where I draw the line, personally. It is not unreasonable to expect people to not show reckless disregard for the safety of others even if they get lucky and nobody gets hurt. That's what drunk driving is. It is no less bad than cutting somebody off and swerving between lanes; if somebody does that, it seems perfectly reasonable to punish them for recklessness. I see drunk driving laws as largely the same thing.
That said, I do agree with you that open container laws are idiotic. If you haven't been drinking it, transporting it is irrelevant. It strikes me as primarily a way for officers who haven't met their quota to jail or fine somebody who they believe has been drinking even if the BAC evidence says they haven't. The obvious completely legitimate example that these laws prohibit is somebody carrying a half-consumed bottle of wine from a friend's house because the friend didn't like it. You can't put it in your trunk because it has been opened, so the cork might come out while it is rolling around, and then you'd have a horrible mess, so your passenger holds it or you wrap it in a blanket on your passenger seat and strap it in or whatever. That's not in any way contributing to drunk driving or reckless driving on the roads, but in many places, it is still technically illegal.... That's where the laws cross the line from preventing reckless disregard to being paranoid nanny state behavior. I'm not convinced that those laws do enough occasional good relative to the widespread inconvenience to meet the quality threshold that we should expect from our laws. I'm also not convinced the harm is bad enough to bother doing anything about it. It's in that fuzzy grey area between the two. :-)
I do agree also that random road blocks are pushing the limit a bit, if only because they are a major inconvenience to a lot of people and are a tremendous waste of resources that could be better spent elsewhere. I think it would be far more effective to station cops randomly outside local bar and liquor store parking lots to pull over people who get in their cars while unable to walk in a straight line... and prosecute the bar owners for not enforcing laws requiring that they take the keys and call a taxi for patrons who seem incapacitated when they leave. Unfortunately, in our sue-happy culture, bar owners would probably claim some kind of discrimination and get a damage award from the city/county/state.... *sigh*
No more unreasonable than requiring people to wear their driver's license in a plastic badge holder while walking on public sidewalks. Papers, please.
It should certainly be illegal to use such a tactic to evade a toll. That said, if you are not breaking the law, the only thing they truly have a legitimate need to see is the little colored sticker that says whether your plate has expired or not. Other than that, their "need" to read the plate and identify you is nothing more than a figment of their power tripping imaginations.
Emulation still counts as a crack. Regardless of whether somebody emulates the dongle or rips out the code that checks for it, the end result is the same: people using the software without paying for it. Most legitimate software doesn't use dongles, so it's pretty hard to think of dongle software that has been cracked merely because I can only think of about a handful of software I've ever encountered that used dongles (all of which has cracks available, most of which are reported to work better than the uncracked versions...).
My biggest objection to dongles is that if every >$200 piece of software I own used a dongle, I'd have to design a battery-powered 16-port USB hub to carry around with my laptop. Life's too short to put up with that bullshit. So I have a very simple rule: dongle = no sale. I've even rejected software made by companies that my employer owned at the time and bought competing products instead solely because of dongles. That product team subsequently dropped the dongles and I bought a copy the next week. So if anyone thinks dongles are a win, bear in mind that for every person who was prevented from using the app because of the dongle, that's one person using a competing product that they could crack, so if even a single pirate goes legit, stronger copy protection becomes a net loss for the company. And for every ten people who were prevented from using it illegally, there's one pissed off customer who was prevented from using it legally who will never buy anything from your company again and probably five people who took one look at the dongle and said "screw that", so it's still a net loss.
The only way copy protection is a win is if it forces people to "go legit". Outside of the video game product space, I have seen no evidence whatsoever that this occurs. Ever. In every case, when I heard somebody complaining on a message board about not being able to pirate a new version of something, there have been fifty people replying, all saying things like "You could try [insert free product here]." About the only people I've seen gain market share because of anti-piracy measures are free or inexpensive products like Ardour, Audacity, and Reaper.
Anyway you cut it, dongles are fundamentally evil. If you're finding that a large percentage of your users are stealing the software, it usually means that you've priced your products above what some significant portion of the market can bear. If you don't cater to that market segment (either by providing a low end version or by putting up with the piracy), then you can bet somebody else will, and those low end users will end up upgrading to that other company's high end software someday instead of yours. It is as simple as that.
These days, most folks have given up ripping out the dongle code because it is too pervasive and instead just emulate the dongle in software. The result, of course, is that the application performance is dramatically decreased by the amount of excess copy protection code.
Waves 6 came out in July and there are cracked versions available already (though I'm not remotely crazy enough to DL them and see if they're legit...). Once you consider that it probably took a couple of weeks from when they started shipping it to when anybody actually got a copy to start working on cracking it, that puts the crack time at about two weeks. A little more than a week, but not that far off. It may also have been added a while back. It looks like every warez torrent was just added within the last few days, so I have a feeling those dates there are not a useful indicator of when the crack came out. :-)
Then, there was Mac OS X. That protection lasted all of two or three weeks after its Intel release, IIRC, and that involved all sorts of customer driver and bootloader work. Each update since has been released within a week or so of the Apple release.
I'm struggling coming up with a third because I'm only familiar with one other app that has dongle protection and it was released long enough ago that I'm having a hard time determining when it was first cracked. :-)
You can't convince me that any of the current protections are any more effective than the protections of the past. In general, if a crack for a piece of software isn't available, it is because either A. nobody thinks it is important enough to bother cracking it or B. all of the people trying to crack it are relatively inexperienced at that sort of thing, not because it is hard to crack.... :-)
And when that dongle goes bad, gets lost, gets stolen, gets run over by a truck outside a gig, etc., your $1000 piece of software is now worthless, and generally speaking, the manufacturer expects you to buy a whole new copy, though some will replace it at a reduced rate. Either way, I make it a rule never to buy software with dongles. If everybody did that, such unscrupulous practices would stop....
The thing is, dongles don't actually protect against the real pirates at all. They last maybe a week in the face of someone determined to crack an app, and usually less than a day. The extra six days are spent adding the spyware into the cracked app. :-D All the dongles really do is cause problems for legitimate customers and raise the price of the product.
Further, it is highly unlikely that anything the hardware manufacturers could do for these game publishers would make the slightest dent in piracy. Why? Ultimately, there's a piece of executable code that is being loaded into memory. Any protection measure will eventually result in unencrypted executable sitting in memory. That executable code can then be changed. Period. Believing in software copy protection requires the same fundamental logical flaw as believing in DRM.
Then, there's the question of whether it is worth protecting against at all. I'm of the opinion that piracy generally helps the software industry (except for games). No, I don't advocate piracy, but in my experience, most of the people who pirate software (not including commercial pirates) are people who can't afford the software at the time. Often, this can be combatted by offering low-end versions of the software and/or reducing the price to a more reasonable price point.
In any case, those people who can't afford it usually end up buying the software (assuming that they like it and have a good experience with it) once they are out of college and are no longer poor.... Even if they don't, however, they are creating an entrenched user base for the software, recommending it to their friends when people ask for suggestions, and creating files that often won't work as well (or at all) with competing products, thus contributing to vendor lock-in by other people who do buy the software.
For games, however, the story is a bit different. Games rapidly become less valuable once you've had them for a while. That's why the game publishers are terrified of piracy. They know that if people get their hands on pirated copies of a game, they are likely to play it for a couple of days, then stop playing without buying it. (The game publishers face basically the same situation as the music industry with its low quality pop music, and for precisely the same reasons.)
This leaves them three options:
Guess which two of these are likely to be effective solutions.... Guess which one of these they actually do more often than not.... Guess why they're losing their self-declared war.
Huh? The people providing the VOD service are the same people who provide the software that manages the caching, and the same people renting out the hardware involved (cable boxes)....
Simple. I explained it in my post, though I didn't provide the details. You immediately add that user to a multicast group whose members are close by. Then, you multicast it to that user individually up to the point where it catches up with the main multicast stream. If somebody else joins, that somebody else joins both multicast streams up to some reasonable maximum number of streams. You then use the hard drive as a cache to buffer all the data from both the unicast "catch-up" stream and the multicast stream, then glue it all together when the user plays it back. When the user pauses, the computer continues to store the data from the stream. You should also probably provide a mechanism for re-requesting blocks that get dropped. That prevents a network glitch from casing you to lose data unless you're playing the unicast catch-up stream without enough buffering lag-benhind (and even then, it would mean that if you cared enough to hit the "skip back 7 seconds" button, it wouldn't glitch because your machine would have re-requested it..
Fast forward is the same. You open a new multicast stream and add everybody else to it, then continue to cache both streams. When the "everybody else" stream catches up with the start of this user's stream, you stop sending data on that stream except to new users who joined after the stream split.
It is an unholy amount of management on the server end to manage all the streams, but from a client perspective, it is pretty simple. The only change required to VOD receivers is that every client must have a hard drive. In this day and age, that's really not such an onerous requirement. That said, if there were some legacy clients, it would just provide additional pools for other receivers to stream from, at least up to a point. You'd probably have to make them wait to start playing a bit and maybe not allow them the same level of control, but again, these are legacy clients we're talking about here.
Okay, raise your hand if the first thought that came to your mind was, "I'd like to fire Bill Gates... out of a cannon."
No? Maybe it's just me....
So set the limit at 6 Mbps. What, you mean Comcast can't deliver a continuous 5Mbps to all their customers? Are you telling me they oversold their bandwidth? Say it ain't so. :-D
But seriously, the right solution is to make VOD use multicast and treat multicast rates as the number of bytes streamed divided by the number of clients. Use the local hard drive as a very large cache, and by the end of the movie, you have the whole thing on your HD and aren't consuming any bandwidth. The notion of "live" streaming of movies off a hard drive in some server farm in a unicast client-server style is so 1985 (prior to RFC-966). After all, this is precisely what multicast was designed to do. If it doesn't get the job done, create a new RFC and a new underlying packet routing protocol that does, but could the cable companies PLEASE quit jerking everybody's chain and saying "Oh noes, VOD can haz mor bandwidth?" It got tiresome ten years ago. Now, it no longer qualifies as comedy and falls squarely into the bucket marked "that's just sad".
I interpreted your post that way, but if you didn't mean it that way, then I apologize for interpreting it as such. :-)
Sockets are somewhat easier to patent than instruction sets, though, as they represent an actual invention, while an instruction just represents a fact---if I see this bit sequence, I perform the following mathematically definable operation. While I don't doubt that there are plenty of patents on instruction sets, I do doubt that any of them would be upheld in court if push came to shove and the opposing counsel were competent.... The only reasonably strong instruction set patents are the ones that define the hardware needed to implement them. If, however, you can find a way to implement them with a hardware implementation that looks sufficiently different, though, you've just worked around the patent.... The ones that merely attempt to define what the hardware should do if presented with a particular instruction are pure comedy, as they are a pretty blatant example of purely algorithmic patents, which aren't allowed in the U.S.
AFAIK, the VIA Nano supports all of those four instruction sets (Intel 64 and AMD64 are basically the same ISA). None of them are specific to Intel or AMD anymore.
Wow. That's the first time I ever saw UID used as an estimator of age. That's pretty entertaining. I guess it's more of a lower bound, but still....
It is not necessary for things to be as bad as they can possibly be before one has the right to complain about things that are wrong. The U.S. has in many ways grown greatly more totalitarian over the past eight years. Saying "It's not as bad as China, so the problems don't matter" is the height of idiocy. That's like saying "Linux doesn't crash as much as Windows, so it must be perfect.
Indeed, it is precisely because people do appreciate those freedoms that they rant about signs of growing fascism in the U.S. government. They who have never seen the light cannot know that they live in darkness, and so do not complain. Therefore, I would contend that the people who do not rant are the ones who do not fully appreciate those freedoms.
You mean like the /x modifier in Perl?
http://www.regular-expressions.info/freespacing.html
No. That's exactly the opposite of what we need. It should be harder for something to not be a literal. If I were designing a regexp language, I would make it so that the contents of variables are always automatically quoted---none of this \Q and \E crap. You should have to add additional stuff around a variable to get the non-quoted behavior. This is the most common bug I've found in Perl code---user-entered text treated as part of an expression when it shouldn't be.
The problem is that regular expressions are often used for things that they aren't suited for. As soon as you add look-behind and crap like that, you're already beyond usable regular expressions. At that point, you need to take a step back and look at the problem again. Chances are, you'll find that the problem would be solved better programatically with a few lines of code rather than a jumbled, cryptic regexp that no one can understand without staring at it for five minutes. (Of course, it doesn't help that half the time, there's no comment before that snarled mess of a massive, bloated regexp to tell what it does....)
Regexp is good for quick text processing. As soon as you're writing things in it that would be better served by a proper parser, you're just asking for maintenance problems of the "Oh, this declaration formatting code doesn't indent correctly when the user puts a struct nested in another struct nested in a typedef struct:" variety.
No, no, no. It's not "almost" fusion. It is fusion. It is almost a fusion generator. That doesn't mean fusion isn't occurring. It means that the reaction is not self-sustaining. There's a huge difference. Saying that it isn't fusion is like saying that a match placed in a sealed jar and set ablaze using a laser isn't really fire because it consumes all the oxygen and burns out and there's no way to add more oxygen....
Well, as I understand it, there is some experimentation with that in the labs, but mostly at a microscopic level with a fixed substrate instead of a spinning disc.
I suspect the main reason not to do that is the complexity of doing thermal calibration for several times as many heads. Add to that the increased risk of head crashes because there are more of them to crash, then add the extra risk of head failure because there are more of them to fail, and you have a recipe for disaster. Oh, and there's also the extra space needed for the extra head arms. Not sure how much of a constraint that is.
That said, rotational latency is just a small part of total HD performance (on average), so a lot of it may be simply a reluctance to add lots of extra hardware to improve things by such a relatively small amount....
Good catch. Mod parent up. All of the GP post's numbers are too high by a factor of two.
One more error. Wrap the "$skip = 1" with an else.
Anecdotally, I've met all of three people who admitted to being Republicans over my 9 years in the industry. On the other hand, this is the California part of the tech industry, so a good part of that may be the overall regional demographics interfering with any attempt to isolate the tech population.
D'oh. To avoid losing the initial <script language="javascript">....
Forgot to do the < thing in that sentence. :-)
To avoid a DMCA violation, the unescape function is left as an exercise for the reader. Hint: the hex function converts hex to base-10 integers, and printf can be used to convert numerical ASCII values into the corresponding characters....
Two minor mistakes. To avoid losing the initial prior to a block of actual JavaScript, you need to insert this line:
after:
Also, while this is only a problem if you do a "use strict", you should add:
right after: