Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Comment Dear creators of content: DRM won't cut it! (Score 1) 383

It wasn't a big deal when DRM meant leaving a CD in the tray. That was about the last time when buying a game meant less hassle than copying it. From then on, it was straight downhill.

From shitty, half-baked CD-drivers that crapped out on various machines and thought the game was a copy despite being legit, to authentication servers that first could not be connected and then crashed the game if your ISP had even a minor hiccup in its connection, to the latest "lemme look what's on your machine to play my game". And I didn't even get into the crap I should have had to put up with Windows Live.

Any of those problems do ONLY apply to people who are honest (or stupid) enough to actually buy the game. Nobody who ever copied the game had any of these problems. And that's poisoning your own pool.

From a market point, you compete with the copies for your customers. They offer the same product you do, illegally, ok, but it's still the same product offered. You cannot compete on price, for obvious reasons. You don't want to compete on content, since printing manuals seems to be too expensive. But throwing out the last advantage you had over copies, i.e. convenience and compatibility, was just plain out stupid. You managed to make your products worth LESS than the copies. It's not even on par with the copy, it's worth LESS than it.

How? Because the value of an item is not only its price, it's the usefulness to its user. A game that runs without hassle is more valuable than one where I have trouble getting it to run properly. For the longest time, this was in your favor. Running a bought game was heaps easier than running a copy. You slipped it in and it worked. With a copy, you had to apply a crack, hope that it works, and often you had to install it manually with some tricky "copy this there and that there, and then run this, then copy that and run..." you get the idea. It was LESS convenient than buying the game.

This was turned around when DRM meant that it became more of a hassle to play a bought game than playing one that was copied. This was achieved for some when the copy protection CD-drivers weren't fully compatible with some CD drives, but it was reached for the mass of your customers when you insisted on authentication servers that could not handle the load during release and that dropped the connection (which meant that the game instantly stopped working). From then on, it was plain MORE convenient to NOT buy but to copy!

The more draconian and the more invasive DRM becomes, the worse the favor tips towards copying. Because for copying, the "hassle" for the user stays invariably the same: Copy game, crack game, run game. What will you want next from us? A blood sample to tie to our account? How much less convenient do you want to make playing games I buy? And how much more inconvenient will it have to become for me to say "screw this" and join the copying crowd?

Comment Re:Don't need it (Score 1) 214

That's why the devil invented cost accounting and along with it cost and profit centers. Just to make sure that you have to "sell" your services to the other department. Which leads to such harebrained systems like having a too small mail box 'cause IT would have to "sell" you a larger one but your superior won't "buy" it, while a few terabyte on the mailserver are running empty.

Comment Re:With that big an organization... (Score 2) 214

This can work out if, and only if, you steer clear of some cardinal sins I encountered during my years.

1. Keep the devs away from the other departments.
If you separate development and operations, do it all the way. Operations is what the departments talk to if they have problems. This of course requires good documentation so the ops can actually solve problems. If you don't do that, everything will eventually end up on the devs desks.

2. Keep the devs away from anything "live"
There must not be any kind of interaction between developers and the "live" systems. None. Zero. For exactly the same reason, they are after all the ones that created your software, so they are probably the ones that could solve a problem fastest. They are also the ones, though, who should be working at something completely different by now.

Separate ops and dev, but do it ALL the way. Else you end up with very overworked developers and very bored operators who won't have much of a clue of your system, usually ending in such a way that the ops get fired and the departments get merged. Of course, without hiring additional staff to do the workload.

Comment Re:Counterproductive IMO (Score 3, Insightful) 214

I'm in an IT-Security department of a pretty large company, vice-CSO. Our department got the inofficial name "cover-your-ass-dept". Why? Because that's ALL we actually do. I try hard (honestly, no kidding) to make it more than that, actually giving people answers when they ask instead of just drowning them in "shut the fuck up" papers (called that way because they consist of strategy papers, position papers and job instructions, each about 500 pages of very IT-Legalese heavy text, intended not to be read but to shut the person asking up in a neat and simple way, telling them to RTFM. It's like the bible, ya know, whatever they're asking for, it's in there. Somewhere. Most likely in more than one spot. Most likely contradicting itself).

The reason is quite simple. When the shit hits the fan (not if. Please. No company with more than 100 employees is tightly secure, you can't tell me that. If you want to, I'll be there for an audit. I'm actually quite affordable, I do it more for fun than profit...), everyone start pummeling the IT-SEC department, and then you better have a cover-your-ass paper handy to show them that THEY fucked up. Else, someone gets fired. That cover-your-ass paper is usually one or more of those 500ish page heavy documents nobody ever reads. The usual course of action is like this, you could pretty much script it.

1. Shit hits fan
2. IT-SEC gets flak
3. IT-SEC collectively disappears between thousands of sheets of paper in desperate search of "but we told you this could happen if you don't...".
4. IT-SEC finds said "but we told you so" and presents it.
5. Nobody gets fired because IT-SEC did their job (yeah, right) and the poor sod who fucked up couldn't have known it better 'cause he's no IT-SEC.

That's pretty much what IT-SEC is like in some companies. And that's what is actually wrong with it. So you shouldn't have an IT-SEC department. You don't need one! Hire some IT-SEC guru by the hour, have him design your company security policy (we usually have templates ready, just needs a bit of adjustment and you're good to go), and have him come in for a checkup every couple month, maybe 2-3 times a year. That's enough. And plenty cheaper than having a guy sitting around doing nothing but covering his ass.

Slashdot Top Deals

If you want to put yourself on the map, publish your own map.

Working...