Your logic is very bad. It's exactly the opposite. The more road blocks the DRM throws up and the more complicated the hacks are, then the more skilled one has to be to overcome them. Increasing complexity => decreasing pool of users capable of getting the hacked version. Stop thinking weakest link in the chain. Think from the company's perspective for risk reduction of piracy
First. The hugely elaborate schemes are elaborate by way of implementation, which is of the concern of the developer, not the user. For the user, they click a button to start the game and it just works--like magic. Second. Windows makes burning a CD look like a file copy, which most users know how to do. Your comparison terrible.
So what you're saying is that it's ok for companies to dick 99.7% of their customer base, who would never pirate the game in the first place, just to delay downloaders from getting it by a day?
I love that kind of rationale.
I never said that nor did I imply it. Do not attribute to me things I did not say. It is dishonest and it turns you into a liar.
I said the GP was not thinking like a board member. He clearly wasn't, nor are the majority of the insolent slashdorks buzzing around this topic.
To be honest, I don't think you get it. How many regular, normal users are going to google/torrent the hack? Then scan it for trojans? (Believe me most copies will have one.) And then install it from the cryptic readme text file? I'm talking non-geeks. People who send their PCs to the geek squad. People who've got no idea how a byte is different from a bit. You know, the other 99.7% of the user base. Well, I'll tell you: very few. They use DRM because DRM works on the majority of consumers. You are thinking from the perspective of a consumer--not of an executive on the board. If DRM causes the company to lose 10% of their base but pickup a new 11%, they don't care.
You know. I once worked at a shop and I felt their software was crap so I when I worked up a new design for the internal website I started playing around with a palette of colors harmonious with human shit. My doodling evolved into a full administration website. To this day they are using an interface inspired by the colors of shit and none of them know the reason why.
You assholes will never be satisfied. You ask for anecdotes proving ESP, you get them, then you work to "disprove" them. Well, my response to that fuck all of you. The entire lot of you.
Has anyone been able to announce a reasonaby random event before it happened while experiencing a deja vu? Something like "Bob will walk in though that door now" or "Bob is going to spill his drink".
I predicted my van was stolen before I saw the empty parking space. I had went outside and began walking down the sidewalk to go start it up. At my vantage point I could not see the parking space due to a handful of large buildings blocking the view. Before I got there I saw an empty parking space in my mind's eye, and I knew in advance the van was gone. I was so convinced I started running and when I turned the corner it was indeed gone. On the ground where the van had been was broken glass. This was the only time a vehicle of mine had been stolen.
I also have regular episodes of deja vue. Sometimes a few a year, sometimes not so much. The last 2 episodes predicted my move to another state, getting a new job, and then leaving that job before I had even left the original state.
When a plane crashes people die so given your argument we should never replay those types of videos as well. We should never replay Challenger videos. We should never replay race crash videos. We should never replay any war videos.
The video is newsworthy so transparency in reporting is called for. It is better to openly show these things instead of covering them up and denying the public knowledge of what occurred. Denying access to the information leads down the road toward enabling corporations and governments with the power to cover up their deadly mistakes.
...except in this case "anyone" means "a small cabal of editors with all the time to spend guarding their pet pages against edits submitted by the likes of filthy scoundrels such as you".
I like the concept of wikipedia and all but let's stop kidding ourselves. The site stopped being editable by all a few years back. Good luck trying to edit any existing pages because your edits will be rolled back faster than you can hit refresh.
I can't quite figure out if this is flamebait, or if I'm just the only person who can't make a connection between liquid sensors in a consumer electronic device and a dystopian police state.
You must be the one those users who mods every post they don't understand as flamebait.
This is not the same scenario. The client is authenticating while running on a PC controlled by the user, which includes control over the clock, random number generators, and hardware.
This is client side authentication--not server side. Who cares about nonces and server authentication. It's irrelevant when we host the client and control the fake server.
Capture the packets in the authentication session.
Setup script to listen on the port and replay the packets back.
Edit hosts file to point dns to the dummy DRM host.
Flakey, problematic DRM server solved.
There's a good chance it would work if the DRM protocol does not rely on a close synchronization of clocks. I doubt it because it would be impossible to guarantee across untrusted machines.
Pro-tip: Anything that's "resuable" that has a limit on the number of times it can be re-used like, say CD-RWs or this plastic paper, are actually consumable
Not to be a contrarian but... your monitor is a form of reusable "paper". An LCD monitor is theoretically reusable for centuries if properly cared for and shielded from power spikes.
There isn't anyone in America who actually believes that the Imperial system is easier or more useful
Imperial is entrenched in the construction industry and it's not something that will convert to metric any time soon because building codes and materials are all based on inches. It's industry-wide. For example wood studs commonly come in units of 8, 10, 12, and 14 feet. The height of ceilings is guided by these units. Building codes mandate 2x4s 16 inches on center or 2x6s 24 inches on center which means insulation comes in 16 or 24 inches width. It's all those little things that will keep us on imperial for quite some time.
Also 12 is a magic number in construction. This is due to the ease of integer division by 2, 3, 4, 6 which makes for nice round divisions of 1/2, 1/3, 1/4. This is invaluable when your tools are primitive.
Query parsing has such low overhead compared to the time it took to do everything possible to not increase the size of structs.
Then you were basically working on a toy system processing very few transactions. In any system processing between mid to high volume, a SQL engine is serious overhead and should be accounted for in the design.
You should really think about the possible situation at hand before stating how something is 'pretty obvious'.
It was obvious. It is still obvious. Either the developers at your shop were blistering idiots for designing a solution for a problem that does not exist or you were the idiot for not understanding the software requirements.
When you're sampling music, you're crediting them.
Then where is the credit? You are just familiar with the sampled work and immediately recognize it. What about users hearing the sampling for the first time? How would they know it was sampled?
And talk about diabolical... the "database" consisted of arrays of structs written directly to disk. Upgrades of data structures meant hours of importing the old data, copying it into a new struct that was bigger, and writing it back out. SQL databases were available in the 80''s... what gives?
Network database storage has network latency, SQL parsing, and storage overhead. Local database storage has SQL parsing and storage overhead. Local binary data storage is very fast and minimal. I'm a bit surprised you would ask what gives. It's pretty obvious.
So anyway. They were probably keeping the structs small to minimize storage requirements. Padding out the structs for future expansion used expensive storage space and increased disk IO.
I think the biggest trouble is with knowing why things were done. You will look at the code and see that decisions appear to have been made arbitrarily. You'll scratch your head wondering "they had 3 design options but they chose this one, why?". You need to understand the use cases to know the why. It's not always obvious because many times its based on tribal knowledge that was obvious at the time but not now so no one thought to document it.
Ask around and find out of any of the higher ups from the original project still remain. Setup an interview with them to get the project history and go over the use cases. When you go back to the code, you'll better understand why things were done.
So an individual is going to rewrite a production system composed of 30-40k lines of code all by themselves when the original team had a bigger budget, more teammates, more time, face to face access to clients, and participation in all the requirements gathering sessions?
Don't underestimate the effort that went into legacy systems. Unless your team resources on par with the original team or you have a magic productivity bullet (perhaps migrating from old school Fortran to Java), don't even try it. Go with a piecemeal series of revisions over time. It can be done (I've done it before) but you must prioritize and cull the list of worst offenders. It requires having solid understanding of the code base and a clear plan for the bits to rework and the bits to keep.
Slashdot Mirror
Your logic is very bad. It's exactly the opposite. The more road blocks the DRM throws up and the more complicated the hacks are, then the more skilled one has to be to overcome them. Increasing complexity => decreasing pool of users capable of getting the hacked version. Stop thinking weakest link in the chain. Think from the company's perspective for risk reduction of piracy
First. The hugely elaborate schemes are elaborate by way of implementation, which is of the concern of the developer, not the user. For the user, they click a button to start the game and it just works--like magic. Second. Windows makes burning a CD look like a file copy, which most users know how to do. Your comparison terrible.
I never said that nor did I imply it. Do not attribute to me things I did not say. It is dishonest and it turns you into a liar.
I said the GP was not thinking like a board member. He clearly wasn't, nor are the majority of the insolent slashdorks buzzing around this topic.
To be honest, I don't think you get it. How many regular, normal users are going to google/torrent the hack? Then scan it for trojans? (Believe me most copies will have one.) And then install it from the cryptic readme text file? I'm talking non-geeks. People who send their PCs to the geek squad. People who've got no idea how a byte is different from a bit. You know, the other 99.7% of the user base. Well, I'll tell you: very few. They use DRM because DRM works on the majority of consumers. You are thinking from the perspective of a consumer--not of an executive on the board. If DRM causes the company to lose 10% of their base but pickup a new 11%, they don't care.
You know. I once worked at a shop and I felt their software was crap so I when I worked up a new design for the internal website I started playing around with a palette of colors harmonious with human shit. My doodling evolved into a full administration website. To this day they are using an interface inspired by the colors of shit and none of them know the reason why.
It isn't possible to be a dangerous thug when it's playing. http://www.youtube.com/watch?v=rVS3QqrXhD8
How about GraphGiraffe? PixelPup? RenderRabbit? TraceTripe?
You assholes will never be satisfied. You ask for anecdotes proving ESP, you get them, then you work to "disprove" them. Well, my response to that fuck all of you. The entire lot of you.
I wrote what I said. I meant what I wrote. Now, either accept what I wrote.. or fuck off with your suppositions. Seriously.
I predicted my van was stolen before I saw the empty parking space. I had went outside and began walking down the sidewalk to go start it up. At my vantage point I could not see the parking space due to a handful of large buildings blocking the view. Before I got there I saw an empty parking space in my mind's eye, and I knew in advance the van was gone. I was so convinced I started running and when I turned the corner it was indeed gone. On the ground where the van had been was broken glass. This was the only time a vehicle of mine had been stolen.
I also have regular episodes of deja vue. Sometimes a few a year, sometimes not so much. The last 2 episodes predicted my move to another state, getting a new job, and then leaving that job before I had even left the original state.
When a plane crashes people die so given your argument we should never replay those types of videos as well. We should never replay Challenger videos. We should never replay race crash videos. We should never replay any war videos.
The video is newsworthy so transparency in reporting is called for. It is better to openly show these things instead of covering them up and denying the public knowledge of what occurred. Denying access to the information leads down the road toward enabling corporations and governments with the power to cover up their deadly mistakes.
Admit it. You wanted the mod points.. didn't ya?
No. Typically the reason is retarded such as disagreement over comma placement. The second being the reverter is usually a dick guarding his pet page.
...except in this case "anyone" means "a small cabal of editors with all the time to spend guarding their pet pages against edits submitted by the likes of filthy scoundrels such as you".
I like the concept of wikipedia and all but let's stop kidding ourselves. The site stopped being editable by all a few years back. Good luck trying to edit any existing pages because your edits will be rolled back faster than you can hit refresh.
You must be the one those users who mods every post they don't understand as flamebait.
This is not the same scenario. The client is authenticating while running on a PC controlled by the user, which includes control over the clock, random number generators, and hardware.
This is client side authentication--not server side. Who cares about nonces and server authentication. It's irrelevant when we host the client and control the fake server.
There's a good chance it would work if the DRM protocol does not rely on a close synchronization of clocks. I doubt it because it would be impossible to guarantee across untrusted machines.
Not to be a contrarian but... your monitor is a form of reusable "paper". An LCD monitor is theoretically reusable for centuries if properly cared for and shielded from power spikes.
Imperial is entrenched in the construction industry and it's not something that will convert to metric any time soon because building codes and materials are all based on inches. It's industry-wide. For example wood studs commonly come in units of 8, 10, 12, and 14 feet. The height of ceilings is guided by these units. Building codes mandate 2x4s 16 inches on center or 2x6s 24 inches on center which means insulation comes in 16 or 24 inches width. It's all those little things that will keep us on imperial for quite some time.
Also 12 is a magic number in construction. This is due to the ease of integer division by 2, 3, 4, 6 which makes for nice round divisions of 1/2, 1/3, 1/4. This is invaluable when your tools are primitive.
Then you were basically working on a toy system processing very few transactions. In any system processing between mid to high volume, a SQL engine is serious overhead and should be accounted for in the design.
It was obvious. It is still obvious. Either the developers at your shop were blistering idiots for designing a solution for a problem that does not exist or you were the idiot for not understanding the software requirements.
Then where is the credit? You are just familiar with the sampled work and immediately recognize it. What about users hearing the sampling for the first time? How would they know it was sampled?
Network database storage has network latency, SQL parsing, and storage overhead. Local database storage has SQL parsing and storage overhead. Local binary data storage is very fast and minimal. I'm a bit surprised you would ask what gives. It's pretty obvious.
So anyway. They were probably keeping the structs small to minimize storage requirements. Padding out the structs for future expansion used expensive storage space and increased disk IO.
I think the biggest trouble is with knowing why things were done. You will look at the code and see that decisions appear to have been made arbitrarily. You'll scratch your head wondering "they had 3 design options but they chose this one, why?". You need to understand the use cases to know the why. It's not always obvious because many times its based on tribal knowledge that was obvious at the time but not now so no one thought to document it.
Ask around and find out of any of the higher ups from the original project still remain. Setup an interview with them to get the project history and go over the use cases. When you go back to the code, you'll better understand why things were done.
So an individual is going to rewrite a production system composed of 30-40k lines of code all by themselves when the original team had a bigger budget, more teammates, more time, face to face access to clients, and participation in all the requirements gathering sessions?
Don't underestimate the effort that went into legacy systems. Unless your team resources on par with the original team or you have a magic productivity bullet (perhaps migrating from old school Fortran to Java), don't even try it. Go with a piecemeal series of revisions over time. It can be done (I've done it before) but you must prioritize and cull the list of worst offenders. It requires having solid understanding of the code base and a clear plan for the bits to rework and the bits to keep.