No, you mis-understand me. I'm _not_ pro-communist, nor pro-totalitarian, nor pro-chinese-government, in any form or shape.
I'm just saying that not _everything_ they do is motivated by some need to torture, maim and oppress. Some stuff, like railroads or civillian sattellites or their own codecs are built just as well in the capitalist USA or in the mostly-socialist Western Europe.
Or to put it otherwise, there's enough evil stuff happening down there already, so there's no need to cry wolf and invent bogus threats where there are none. I'd wait until I hear that they actually tracked a disident by those sattellites (as opposed to plain old sending an agent to his home) before I start crying wolf.
That's the knee jerk reaction I was talking about.
The only problem with the "watching for people gathering in Tiananmen Square" theory is that such squares are already in the middle of cities, and patrolled by police. China _is_ a police state. Don't assume that communist police was like, say, German police, which you only see about once per month. Communist governments have police and informants all over the place.
So they don't really need a satellite to tell them that. A cop will relay that information quicker.
More importantly, a cop has a brain and can filter data easier than a computer can. A cop can tell if it's a demonstration shouting anti-communist slogans, or merely a crowded day with everyone going around their business.
An orbital camera only sees a crowd in both cases. Even if you program it to only react at over a certain crowd size, a cop could still have informed you faster, while the crowd was still forming.
That said, I'm sure they'd _love_ to be able to track everyone by satellite. In fact, if the press release is indeed worded like that, it can well be that someone actually _wanted_ to give the population the idea "we could mean watching _you_."
I'm just saying it's not practical.
1. Tracking people from above, seeing only the top of their head, isn't of as much use as the tinfoil hat crowd seems to assume. Half the office building I work in would look just the same from above: a mess of hair anywhere between blond and brown, on top of some black clothes. Good luck telling it's me, and not some guy from the second floor.
And let's remember that currently software has trouble even recognizing a face in a clear photo. Recognizing someone by their haircut from above is just SF.
2. It loses track as soon as you enter a building, car, bus, train, or subway. If I enter a subway station, I could come out _anywhere_. Just supervising all possible exits to see me come out, is gonna take half of those 100 satellites. Just for one person.
3. It becomes useless on any cloudy or foggy day.
Needless to say, a human agent has none of these 3 problems.
There are lots of "activities of society" that don't require a tin-foil hat, you know.
E.g., traffic congestions. If you can see those from the sattellite, you have a head start in telling people to take other routes.
E.g., fires. If in the middle of a forrested area you see a big bright infrared spot, you can react before the fire wiped out several square kilometres. And you'd be surprised how many forest fires are due to "activities of society". (A.k.a., idiot tourists.)
Even if it is China and the mandatory knee jerk reaction is "chinese govt==evil", it's actually easier for them too to watch for such _big_ things, than to try to track an individual dissident by sattellite. If they want to track an individual person, they can just send an agent. It's cheaper and doesn't lose track each time the target goes into a house or bus.
It's not just NWN. Diablo 2 took for ever to finish, but it sold like hot cakes because it was a good stable well-designed well-balanced product. Diablo 1 also came out of nowhere as a game that didn't even copy last year's best-seller, but it sold like crazy. Why? Quality. Or Epic and Id pretty much officially have "when it's ready" as a policy, and I you can't say they're going bankrupt because of it. Etc.
True, noone knows in advance the secret handshake that _guarantees_ a bestseller, but if you look at what did well and what failed, you notice a trend. Quality stuff tended to do a lot better than the buggy crap shoved out the door in a hurry.
Contrary to the mentality that hype is everything, quality does sell. People do talk to each other, and that's a big factor that works for the good games, and against the crap buggy ones.
And I don't even only mean code quality, but also design quality. If you look at some of the the things that, say, Blizard did right before, they include:
- very low learning curve (if you can click, you're already half-way to mastering Diablo or Diablo 2)
- well balanced (you don't end up stuck half-way through the game because you chose a class that dies even from a paper cut, or a skill that has no use whatsoever)
- just the right difficulty curve for the casual gamer (the majority of which do _not_ want to reload 25 times to get past a boss.) In fact, better yet, it let you adjust your difficulty curve by yourself, by going faster or slower.
Etc.
That's all things which aren't just stroke of genius, but I'll bet involved a lot of testing and tweaking. They're done well _because_ the games were not shoved out unfinished.
Especially balance _never_ comes from just a stroke of genius, and just writing down some genial numbers from the classes/races/whatever from the start. No matter how bright a designer you are, your first numbers will _always_ suck. Getting them right is invariably a matter of extensive testing, running simulations (e.g., how often does a halfling thief kill an orc barbarian, if you run all possible scenarios), and tweaking.
But somehow the PC game industry just can't get to take quality seriously. Basically they don't _care_ if they're producing crap, including, yes, by stressing the devs and driving away talent.
They just care about having some movie license, a design that's a verbatim clone of last year's bestseller (ironically: it often misses all the parts that made that one a bestseller), and having the game shoved out the door by christmas. Everything else can be fixed by lots of hype, right? (Wrong. But good luck convincing them.)
The character creator is the most generic in existance, so the comparison with selling you crayons and paper is very apt.
Basically it goes like this:
- you choose your body type: male, female or a _massively_ muscular male on steroids
- you choose your height
- you choose your, well, basically width multiplier. So you can drag this down and be a scrawny geek, or to the max and look pretty muscular. (Doing this for the already muscular model is quite impressive.)
- you choose your face, hair style, and clothes, from a surrealistic abbundance of models, colours, decals and patterns. Basically you can wear _almost_ anything you can think of, from spandex, to medieval armours, to robotic bodies/limbs, to jeans and sweaters, to business suits. In any colour you can think of.
Examples of actual characters I've created with it, include (but are not limited to):
- A robotic healer painted camouflage green. (Think: sorta Terminator-like, without the flesh cover.)
- Two dwarfs: traditional axe (tank), and broadsword version (all-out offense). Just take the massive muscular model, make it broad and muscular to the max, put a medieval armour on him, give him a huge beard and make him 4 ft tall. There you go: your own Gimli.
- A knight in shiny plate armour. Broadsword again.
- A tall and thin nerd with jeans, grey sweater and glasses. (You know, the high metabolism nerd variant, not the 300 lbs one;)
- An asian martial artist.
- A massively muscular black man in camouflage pants and combat boots. Sorta like Barret from Final Fantasy 7, except he fighst with his fists instead of the machinegun arm.
- A soldier in camo pants, combat boots, military helmet, and kevlar flak vest.
- A scrawny old doctor with white hair, glasses, goatee, and a grey suit and tie.
So basically you can create almost _anything_. And as you can see, most of them don't even resemble anything that Marvel can claim a trademark on. (If they want to try to trademark dwarfs, I believe Tolkien came before them.)
It's not just about masking artistic deficiencies. Sometimes the clean minimalistic look is actually the best.
The dot-com era was filled with clueless PHBs who thought that the user wants an artistic experience. Every single site had to have some horrible colour scheme (e.g., cyan on bright blue, or orange on light orange are actual colour schemes I was asked to implement.) It had to have gradients, 1 MB of animations per page, impossible to read funky fonts, and graphics _everywhere_.
Turns out that most users _don't_ want an experience. They want a simple an intuitive program that just works, or an easy to use and navigate site.
I.e., my advice to anyone would be:
1. Usability and clean layout before funky graphics. Remember that you're making a professional program, not a work of art. The purpose of that interface is functionality, _not_ expressing yourself or evoking feelings.
This is the main reason why graphics artists are bad web site designers, unless you get them to also learn proper web design. GUI design is a completely different skill from graphics design, and for that matter from programming. (Witness the many excellently programmed OSS programs, that nevertheless have an utter crap UI.)
2. Keep it simple. For a back button, a simple left-pointing arrow will suffice. For file operations, a 3.5" floppy icon works wonders.
Basically, if all you need is an icon, do _not_ try to paint the whole Book of The Dead, with the Pharaoh being led into the underworld and judged. You're making an icon, not a fresco.
3. Keep the learning curve low. If the users have already been educated that symbol X means operation Y, use that. E.g., everyone was already broken in that a left pointing arrow means "back", so use it for that and only for that. Don't try to teach them new tricks just for your program.
This may seem like a rehash of 2, but really has more to do with 1. It's all about usability. Steep learning curves are bad. Reusing the user's existing skills is good.
4. Keep it simple.
4.a. You have precious few pixels in an icon or button, so complex images tend to end up with details that are 1-2 pixels tall or wide. The images must be easy to recognize without squinting to see the details. To that end, for example, a stilized telephone symbol will actually work better than a 3D-rendered anti-aliased phone that's been shrunk to 32x32 pixels.
4.b. Remember that the role of icons, again, are to allow the user to quickly locate common actions on a toolbar. Again, functionality before artistic expression. They are _not_ there to evoke feelings or express yourself.
So simple and clear is good in that aspect too. An arrow or a magnifying glass are things that aren't just easy to draw, they're also very easy to recognize and visually locate.
Etc.
So basically what I'd argue is that often keeping it simple, abstract and clean is actually the _right_ way, and making it overly artistic is the _wrong_ way. Not being an artist or creative can actually be an advantage.
Yes, you can't take a programmer and expect him to be able to paint the sixtine chapel. But here's the fun part: you want an UI, _not_ the sixtine chapel. Someone who tries to make a sixtine chapel out of the UI is actually the _wrong_ person for the job.
Unfortunately, VIA doesn't out-sell Intell or AMD either. If you look at the market share figures, VIA is lost in the decimals. So they have the low price _and_ the low sales.
Or to put it otherwise, it's not that they deliberately sell them cheap to outsell everyone else, it's that they _have_ to give them at barely production price to sell them at all.
Hardly seems like an enviable situation to me.
They _could_ be a contender in the embedded CPU market, that's one good observation. But for some reason they don't seem to be a major (or even minor) player in that segment either.
Intel has basically been hanging itself with the awful lot of rope their own marketting gave them. The "MHz is everything" marketting was an easy thing to push, since most people actually _want_ one number that tells them everything about a CPU.
(True story: I actually spent some time arguing with a marketroid about it, and gave up. He was arguing that it must be Anantech's and everyone else's benchmarks that are at fault, because CPU A is in some apps 50% faster than CPU B, in some apps equal, and in some apps actually a little slower. "It can't be! If CPU A is X% faster than CPU B, it must be X% faster in everything!" Any explanations about differences in CPU architecture and such, went right above his head.)
So it was easy for Intel to push the MHz as the one true speed indicator. And for a while all they had to do was keep putting out CPUs with more and more MHz.
Except after a while it became a trap. Any new design _had_ to be higher MHz, or have Intel's own marketting working against it. All those many millions that went into telling people "buy a higher clocked CPU", now would basically tell them "don't buy the newest Intel CPU chip", if Intel made one with less MHz.
And now Intel finally _has_ to find a way out of the hole it dug itself into.
As for Cyrix (now VIA), it was never really a problem for Intel. Cyrix just fell behind performance-wise on its own. The last proper Cyrix versions were already falling beind in integer performance too, but it was their floating point performance that was abysmal. So what killed Cyrix was not as much Intel, as games going 3D: now everyone had benchmarks everywhere, clearly showing the Cyrix as barely crawling.
And Via's versions fell behind even more. They aren't just slower in MHz, they're also slower _per_ MHz. Other than being low power, they just suck.
And it's not that VIA really _wants_ to be the poor-man's niche, for Chinese families who can't afford an Intel or AMD. People find such niches to survive, but noone really wants to _stay_ in such a niche. Noone actually wants to sell their top CPU at $30 or less, instead of, say, the $600+ that an Athlon 64 FX sells for.
So if VIA could break out of that unprofitable niche, believe me, they would. The problem is simply that they can't.
As was already answered, it's a very different case, so I see no contradiction even for those who do share files.
But in my case, I'm firmly against sharing copyrighted material too, and I've been known to call it theft even here on Slashdot. I'm proud to say that all the MP3's I have are ripped off CDs I personally own, all my software is legally licensed (yes, I also actually went and bought a Windows 2000 license when I built the second computer), and all the movies I've seen were either in a cinema or off legally rented DVDs.
The games alone occupy some three bookcases, packet tightly. Without cardboard boxes or manuals.
Hence, even if you must put equals between spam and file sharing, I fail to see the problem: I don't do either of them.
Well, I understand what you're saying, but I don't see it as a XOR (exclusive or) situation. In this case it's not a case of "we only round up 10 spammers per year". I should hope it's more like "we keep rounding up as many of them as we can" _and_ lock them away.
So basically the difference is between:
A) "we round up as many as we can, and give them a $100 fine" and
B) "we round up as many as we can, and give them 9 years each in state prisons."... which of those do you think is more of a deterrent?
I'd say B by far. Situation A would just get factored in as the cost of business.
1. Deterrents work admirrably. The fact that you can walk on the street and not be mugged as soon as you open the front door, or for that matter that you didn't get that front door bashed in every night by everyone who would like your TV, is because of the deterrent effect. A lot of people would love to have your wallet or your TV, but wouldn't like the consequences. See? It works.
Sure, it doesn't deterr _everyone_ but if it works on, say, 99% of would-be spammers it already solved the problem perfectly.
2. In this case, you don't even really need it to be a deterrent. It was proven again and again that the majority of spam comes from a handful of fucktards.
So if we throw the top 100 spammers in jail for a decade, there you go, we'll enjoy a decade of email being usable again. It doesn't even matter if it was the best deterrent, or if it deterred anyone at all. We just took the problem out anyway.
I don't know, it seems to me like it's justified nevertheless.
1. Although I find it an inherently cold and heartless thought, we put a price in dollars on a human life all the time. Compare the losses caused by a spammer to that, and it's quite easy to end up higher than the cost of a life.
No, I'm not talking "but a second to delete a spam message costs nothing!" Even then, time is ultimately money. (E.g., you pay over $1000 for a faster computer, yes, to save time. And how many of those upgrades are ultimately just to be able to run an even slower antivirus, spyware killer, etc? That's money costs inflicted by the spammers upon society.)
I'm also talking lots of other effects, such as the cost incurred to companies and individuals to maintain all those spam filters. The IT costs of preventing and cleaning with viruses that exist only to install spam zombies. Costs incurred to ISP's and companies just to deal with the bandwidth and storage used up by spam _and_ all those viruses trying to install spam zombies. Costs related to false positives. (E.g., a missed business opportunity because an email from a legitimate business partner was filtered out.)
Plus the insidious cost of having a valuable communication resource plundered and turned into a worthless wasteland. Whereas we all used to gladly read and answer emails from strangers (e.g., questions about my walkthrough for a game, some yes, including attached pics of where they got lost), nowadays an email from a stranger is most likely to be junked without reading. Doubly so if it contains an attachment of any kind.
I also used to freely give my email address to everyone. Nowadays if someone did that, you'd call them an idiot clueless (l)user. Nowadays if you must enter an email address, it's some black hole account just supposed to be a garbage bin for spam.
All this is not just business opportunities, but literal pollution of a valuable resource, and it affects hundreds of millions of people. Even if you put a 1$ price on that resource for each user affected, you easily end up with a monumental loss that those spammers caused to society.
Yes, higher than what we currently price one life at. Cynical, but true.
2. My favourite example: I think of it not in dollars, but in seconds. A murderer has shortened someone's life by, say, 20 years. And we can execute him for that.
Now let's look at spam. Let's say 100,000,000 users receive spam. Let's also say each user is only robbed of 1 minute per day dealing with spam, installing and updating spam filters, de-installing spam zombies, etc. (Just spending an hour on that software every 2 months, already uses up that 1 minute per day quota. So not unrealistic.)
That means in just 2 months, those users have been robbed of 100,000,000 hours out of their lives! That's 4166667 days! Or more than 100,000 YEARS!
So we can execute someone for stealing 20 years out of someone's life, but you think 9 years in prison is too much for robbing 100,000+ years from us all? Seems to me like it's equivalent to more than 5000 murders. People have been hanged tried as war criminals and mass-murderers for far less than that.
So au contraire, I think the fucktard got off disproportionately lightly. If there was justice and keeping the punishment proportional, a spammer would need to die a thousand deaths. (Which, unfortunately, is impossible anyway.)
You know, I do realize that you just wanted to be funny, but nevertheless the unsettling thought is that there _are_ people who actually think like that seriously. Their kid is something which should shut the fuck up, stay the fuck out of mommy and daddy's way, and generally a pest that should have come with an on/off button so they can turn it off and store it in a closet. (OK, in the kid's room. A bigger closet to store the kid when they don't feel like using it.)
Let me see, someone took, say a $200 CPU, burned it and requested that the company pay for his own incompetence. Seems to me like any way you want to slice it, he caused at least that $200 loss.
And even if you reduce it to the chip's cost without profit margins, he still deliberatey conned someone into paying for _his_ _own_ mistake. Still doesn't look honest to me either way I want to look at it.
The cost of a CPU isn't simply the cost of a few grams of silicon, it also includes the whole chain, including packaging, warehouse space, retail shelf space, fab operating costs (a fab can only produce a given number of chips before you need a new process. You have a fixed X million chips to recoup the fab investment from, so you _must_ include it in the chip's cost) _and_ the salary of the poor sod that processes the RMA.
So let's say it only adds up to $100 out of that $200 cost. It's still dishonestly conning someone out of $100. I fail to see how their stealing "only" $100 is suddenly ok and morally justifiable.
And some of these people experiment with stuff more expensive than that.
E.g., it is commonly recommended on such fucktard boards that you flash a 6800 GT's bios to overvolt and overclock it. A 6800 GT is, what? A $400 video card? (I should know, I own one.)
E.g., with the advent of desktop motherboards for Dothans, the fucktards are already not considering anything lower than an overclock from 2.0 GHz to 2.8 GHz. Yes, needing some overvolting to get there. Want to bet that $400+ mobile CPUs will get burned and RMAed in the process?
If you frequent any kind of hardware forums, you'll see that it still happens all the time. In fact, it happens worse than that.
At least the DCs in your example returned a working card, which could then be resold. Though, yes, they had incurred other costs to the company.
The ones I'm running into are the kind that will _break_ a card or a CPU, for example via extreme overclocking and overvolting (i.e., thermally fry it) and then RMA it and ask for a replacement.
Or install some ludicrious cooler on it, mechanically break the card in the process (e.g., crunching the siliconm but damaging the PCB also isn't impossible for the determined overclocker.) Then put the stock cooler back on and RMA it. On account that it's nigh impossible to prove what's really been done to it.
I've seen into advice which even was as cynical as to state "yeah, AMD will know that you thermally fried the chip, but they send you one replacement anyway. So go ahead and raise the voltage as high as the motherboard lets you. It's safe. You'll get a replacement chip from AMD."
Which, sorry, is as dishonest as it gets. It's actually planning to mis-use and probably break a product, then shaft the company to pay for their hobby.
"No, that's what happens when you employ clueless morons to write code for you."
You are, of course, right. We can aggree on that wholeheartedly.
However, it doesn't invalidate what I've said. You just detailed one effect of what I was basically saying.
The problem is that the moment someone actually believes "nah, we can't have bugs because we're protected by the holy power of Java" (or "we don't need good coders because Java/VB/whatever is easy to program"), they invariably go and hire the cheapest morons they can find.
It's not even a slippery slope argument. It's not a case of A slowly leading to B which leads to C which eventually leads to D. Here it's direct cause and effect. A straight short road from A to D.
Being able to write all their programs with 2 ex-burger-flippers paid $5 per hour is _the_ wet dream of the industry. So anything which promises to make that even remotely viable, _is_ in fact used as a justification to do just that: fire all those high paid nerds and hire the cheapest monkey in a suit.
Unfortunately, it doesn't work that way. No matter how easy the IDE, language or libraries make it to program, they can't force an untrained monkey to understand security, do a security analysis and write secure code. The less skilled people you can use to string together OCX controlls they don't understand in VB.NET (or Java, or whatever other language), the less clue they'll also have about making it secure.
And even if the language prevents them from having straight buffer overflows, they'll find other ways to make the program even more insecure. Because they don't even understand what they're doing.
So in a sick and twisted way, as I've said, the better tools you have, the poorer programs you end up with. Among other ways, yes, because the more clueless morons get hired to use those tools.
"LOL! I don't know what kind of system it was but imagine that on any kind of business system. Sales clerk leaves... customer calls up asking "Where's my freakin stuff I ordered?!?" and the person taking the phonecall is like... "Mmmm, what order?... and er, who are you?". Then six months later, J.Random Taxman turns up and ask why your invoice numbers aren't contiguous.
Sheesh, even worse, imagine it's a bank!."
Even worse imagine that it's a business-to-business system. Also imagine that a user (representing another company) can personally cancel their own account. Basically completely removing any trace of himself/herself from the system.
"What? I never said I'd supply you with X tons of Y for 12 months, at Z dollars per ton. I never even was on your site!"
And there you have it in all its glory: a whole bloody factory is in limbo for lack of supplies and materials. The costs for that kinda fuckup, I'd assume, are quite nasty.
I'm open minded to malice explanations too. Or malice out of stupidity.
In this particular case, doubly so. It fits just nicely with another "feature" of theirs, namely the ability of a user to erase all traces of themselves. You see, in the old system, users and records were never deleted, they were just flagged as deactivated. In their system, deleting a user, did just that: deleted the record. And because of foreign keys, it cascaded through all tables and erased _all_ records related in any way. Suddenly that user... has never existed, never posted anything and generally was figment of everyone else's imagination.
However... in this case if they weren't utterly incompetent monkeys, they were damn good at faking it. There were a ton of other bugs and issues for which it's hard to find a malice-based explanation.
Stuff like that they couldn't parse the phone numbers in the existing database, so they literally requested that some bugger edits a few hundreds of thousands of records per hand to match their format. (And if you think requesting that is idiotic, let's just say a PHB actually approved it. How idiotic is that?)
Try as I might, I'd be hard pressed to imagine what devilishly clever advantage they'd get out of that. What clever back door can be gained by having one poor soul go manually through that mountain of data? It's just stupid.
Or whereas the system they were replacing ran comfortably on one PC in Tomcat, their architecture needed a _ludicrious_ server farm to support the same load. Think: literally dozens of computers. Took many hours just to start or stop the behemoth.
Again, I'm not sure what devilishly clever 0wnage would result from writing piss-poor unperformant code. Were they planning to DDOS it into submission later? Not much point in that, when you can already make yourself the highest ranking admin and cause more trouble.
So on the whole, dunno, I have no trouble whatsoever assuming that they were, simply put, too stupid for those exploits to have been planned. In fact so stupid that if they had tried to code a back door, it would have probably been too buggy to work.
Wrong. You do let arbitrary code download and run all the time.
Each time you go to a web site that uses JavaScript, guess what? You download and run arbitrary code. Interpreted code, yes, but arbitrary code nevertheless.
Each time you download a Java or Flash applet, even if just as an ad on a page, you are downloading and running arbitrary code. In Java's case even downloading and compiling it to binary code for your CPU.
As I've said before it would be possible to sandbox ActiveX to hell and back. Make it run in a virtual environment where it can't touch any files that it didn't create itself (e.g., a chroot jail), open any ports, or even call the OS methods without first going through a sanity checking layer.
Now Microsoft doesn't do that, and it's guilty as charged of bad design there. That much we can aggree upon.
But dismissing it all as "You simply don't allow arbitrary code to download and execute." is simplistic. And in fact it's over-simplified thinking like "Java=good, binary code=bad" is the arch-nemesis of security.
Real security doesn't involve mindlessly pinning magic talismans onto the code, nor repeating fashionable mantras. It involves a real security analysis. Who's going to attack us? How? What _can_ happen? How can we prevent that? Etc.
Again, obviously MS didn't do a real security analysis there. We can aggree on that. But that's no reason to assume that one can't possibly be done by anyone.
In theory you are right, and better tools already exist. E.g., Java has array bounds checking by language definition. E.g., dunno abound Microsoft Visual C++, but I've used C compilers before which could generate code with array bounds checking. (TopSpeed C, for example.) It didn't even require any IDE macros, it just plain and simple generated them in the code automatically, if told to.
The problem however is that, well, no language or library ever can force you to stop making mistakes.
E.g., Java does throw an Exception if you try to overflow a buffer, but that's not an automatic magic talisman against bugs. You still can't let any ex-burger-flipper loose on the keyboard and say "nah, they can't have bugs or security problems. The language won't let them." What happens in practice is that:
1. People catch the exception and ignore it, on account that "it can't happen." Or even write "catch (Throwable t) {}" blocks. (Catch anything whatsoever and ignore without as much as a line in the log.)
2. Which in turn can make the program malfunction in more subtle ways. Even if you don't ignore exceptions is forgetting that the exception may have skipped some code. E.g., closing files or database handles is the most benign, in that it just causes the program to eventually run out of resources and crash.
A less benign case is when the code skipped was, for example, the login authentication. Carefully malformed data might not execute random code, but allow the user to escallate their rights to super-user.
And while a buffer overflow might have turned your machine into a spam zombie, this will instead give them all your business data on a silver platter. Nicely formatted, indexed and searchable too. And allow them to change it too.
3. In a twisted way, a secure language is the worst language because it causes complacency. Yes, it's a bit of an exaggeration, but bear with me while I make a point. Thinking "nah, we're secure because we use Java" (or SSL, or whatever) is the arch-nemesis of security. That way lies madness and skipping a real security analysis.
E.g., where I work, we had a failed project coded not by us but by a team of uber-expensive consultants from a BIG corporation. Utterly incompetent monkeys, but expensive consultants anyway.
It allowed a user to change their id to another user by merely editting the parameter in the URL. Since user id 0 was the super-admin, there you go, an easy way for everyone to escalate their privileges.
It also allowed anyone to access and _edit_ any data, including other users' data and passwords, again by simply editting the URL. Including, yes, changing the passwords for the admin and then logging in as admin.
It also allowed users to embed HTML text and even JavaScript in their text, which would be faithfully included in the page without quoting. Just in case you wanted to cause a JavaScript exploit or redirect to be displayed in other users' or admins' browser, you know.
What was worse, though, was that it didn't quote text used to build SQL statements either, basically allowing anyone to exploit the program into giving them all the data in the system. (If they didn't already get to it via the previous two exploits. As they say, three's a charm.)
Etc.
Again, personally I'd rate that as _worse_ than a buffer overflow. Attacking a company's own web programs via buffer overflows, and finding your way from there to the data, is something only a die-hard black-hat would do. Even ordinary script kiddies with rootkits won't bother doing much more than installing a spam zombie or warez/porn ftp server there. Whereas this presented an intuitive, menu-driven, user-friendly way to own a company's business data. And _change_ that data as you see fit.
In a nutshell, that's what happens when you start thinking that the language or libraries are a magic talisman. The moment you think "nah, we don't need a security analysis, because the holy Java will protect us"... that's when you are the most vulnerable.
Yes, we're all nerds, and we're all arrogant. We all like to act as if _our_ code is perfect, while everyone else is a clueless monkey writing bad code. _Our_ bugs are few and minor, if they exist at all, while theirs are unforgivable and should warrant a death sentence. Or at the very least kicking out of the job and if possible out of the industry altogether.
The truth however is that there's an average number of bugs per thousand lines of code, and in spite of all the best practices and cool languages it's been actually _increasing_ lately.
Partially because problems get larger and larger, increasing internal communication problems and making it harder to keep in mind what every function call does. ("Oh? You mean _I_ was supposed to call that parameter's range before passing it to you?")
This becomes even more so when some unfortunate soul has to maintain someone else's mountain of code. They're never even given the time to learn what everything does and where it is, but are supposed to make changes until yesterday if possible. It's damn easy to miss something, like that extra parameter being a buffer length, except it was calculated somewhere else. Or even hard-coded because the original coder assumed that "highMagic(buf, '/:.', someData, 80)" should be obvious for everyone.
And partially because of the increassing aggressiveness of snake oil salesmen. Every year more and more baroque frameworks are sold, which are supposed to make even untrained monkeys able to write secure performant code. They don't. But clueless PHBs and beancounters buy them, and then actually hire untrained monkeys because they're cheap. And code quality shows it.
But either way, everyone has their own X bugs per 1000 lines of code, after testing and debugging. You may be the greatest coder to ever walk the Earth, and you'll still have your X. It might be smaller than someone else's X, but it exists.
And when you have a mountain of code of a few tens of _millions_ of lines of code, even if you had God's own coding practices and review practices, and got that X down to 0.1 errors per 1000 lines of code... it still will mean some thousands of bugs lurking in there.
No, a killer even by Bartle's own paper is someone who acts in unwanted ways upon the players. You will notice that he clearly makes the distinction between "interacting WITH players" (something bilateral) and "acting UPON players" (something unilateral, whether those players want it or not.)
"Acting upon players" is his way of saying "treating them as NPCs", in a nutshell.
It doesn't have to be a PK-er, yes. But it is nevertheless unwanted interaction.
A leader of a vocal minority may not be a "Killer" by Bartle's definition, if that vocal minority doesn't do anything to ruin the game for the others. E.g., the leader of a newbie helper guild may be as vocal as he wants, it usually doesn't detract to anyone's enjoyment.
A leader of a vocal minority _could_ be a "killer" if that position and being vocal is used to drive other players off the MUD. E.g., to defame and harrass.
In which case, sorry, they also fit in my view as a "griefer".
A willy merchant is _not_ automatically a "Killer". A merchant who merely sells and buys wares, even making a neat profit, is usually actually a socializer. Players _interact_ with him, are not _acted_ _upon_.
A scammer or thief on the other hand, is a "Killer". It's not bilateral interaction, it's unilaterally acting upon you just because he/she can.
And again, in my book they fit neatly under "griefer".
The "long term good" is usually just a piss-poor excuse for stuff that's just badly designed. Or for piss-poor hacked-together poorly-thought-out fixes for bad design.
A game is for the players. Period. Idiocies like "short term bad, long term good" mean no less than "it's not fun for the players, but it'll be good in the long term for the game". Which, sorry, is an idiotic contradiction in terms.
And I've yet to see any proof yet that stuff described as "long term good" is actually good in any form or shape. You're usually just supposed to believe some fucktard admin's "it's good because I want to code that. So what if nobody likes it? It's... umm... yeah, it's 'long term good'."
He also trolls his way around real issues, by dismissing them as stuff only newbies dislike. Well, gee. With a decade of playing on MUDs behind me, I think I'm anything _but_ a newbie, yet stuff like PD I hate with a passion.
Plus you'd think that if oldbies invariably loved these features, the oldbies already trained in other games would gravitate towards games offering these features, no? That you could just make a griefer's paradise MUD with PD, nowhere to hide, etc, and every grizzled veteran would gravitate to it. I mean, he says that experienced players want that, no? In practice it doesn't happen. Oldbies avoid these places just as well.
And what disturbs me about Bartle in particular is that he's always went above and beyond the call of duty to justify griefing.
E.g., he's went and argued before that you _need_ killers harrassing the socializers to have a good game. Never mind that in practice that cost Origin the number one place in a market they _created_. Origin took basically Bartle's view that being PK-ed on sight is good, while its players migrated en-masse to EQ and AC where they'd be more protected.
E.g., here not only he wants that an older griefer can _permanently_ kill you, he also wants that you have no rest and no place to hide from that griefer.
Read the point against instancing again. So basically the players actually want some peace and tranquility, but nah, he's more concerned with "what with someone else wants to find them and interact with them while they're in there?"
Well, gee. For friends everyone already was more than happy to invite them to the group. E.g., if I'm in an instanced dungeon in CoH and someone I know gives me a tell, I'll promptly get out of the dungeon and invite them. Or if they need help with their mission, I've been known to leave my mission and join in theirs.
So who are those poor souls who are prevented from interacting with you? Well, the ones you _don't_ want to interact with. The griefers, fucktards, and other scum of the (virtual) earth. Those are the only ones really hampered by instancing.
I.e., again Bartle just goes on a demagogy spree to hammer his old "griefing is good" preconception.
Slashdot Mirror
"If you are not an outright apologist then you are a provocateur."
;)
Guilty as charged, guv'nor. I try to provoke people to use their brains, instead of reaching for the ol' tin-foil hat
No, you mis-understand me. I'm _not_ pro-communist, nor pro-totalitarian, nor pro-chinese-government, in any form or shape.
I'm just saying that not _everything_ they do is motivated by some need to torture, maim and oppress. Some stuff, like railroads or civillian sattellites or their own codecs are built just as well in the capitalist USA or in the mostly-socialist Western Europe.
Or to put it otherwise, there's enough evil stuff happening down there already, so there's no need to cry wolf and invent bogus threats where there are none. I'd wait until I hear that they actually tracked a disident by those sattellites (as opposed to plain old sending an agent to his home) before I start crying wolf.
That's the knee jerk reaction I was talking about.
The only problem with the "watching for people gathering in Tiananmen Square" theory is that such squares are already in the middle of cities, and patrolled by police. China _is_ a police state. Don't assume that communist police was like, say, German police, which you only see about once per month. Communist governments have police and informants all over the place.
So they don't really need a satellite to tell them that. A cop will relay that information quicker.
More importantly, a cop has a brain and can filter data easier than a computer can. A cop can tell if it's a demonstration shouting anti-communist slogans, or merely a crowded day with everyone going around their business.
An orbital camera only sees a crowd in both cases. Even if you program it to only react at over a certain crowd size, a cop could still have informed you faster, while the crowd was still forming.
That said, I'm sure they'd _love_ to be able to track everyone by satellite. In fact, if the press release is indeed worded like that, it can well be that someone actually _wanted_ to give the population the idea "we could mean watching _you_."
I'm just saying it's not practical.
1. Tracking people from above, seeing only the top of their head, isn't of as much use as the tinfoil hat crowd seems to assume. Half the office building I work in would look just the same from above: a mess of hair anywhere between blond and brown, on top of some black clothes. Good luck telling it's me, and not some guy from the second floor.
And let's remember that currently software has trouble even recognizing a face in a clear photo. Recognizing someone by their haircut from above is just SF.
2. It loses track as soon as you enter a building, car, bus, train, or subway. If I enter a subway station, I could come out _anywhere_. Just supervising all possible exits to see me come out, is gonna take half of those 100 satellites. Just for one person.
3. It becomes useless on any cloudy or foggy day.
Needless to say, a human agent has none of these 3 problems.
There are lots of "activities of society" that don't require a tin-foil hat, you know.
E.g., traffic congestions. If you can see those from the sattellite, you have a head start in telling people to take other routes.
E.g., fires. If in the middle of a forrested area you see a big bright infrared spot, you can react before the fire wiped out several square kilometres. And you'd be surprised how many forest fires are due to "activities of society". (A.k.a., idiot tourists.)
Even if it is China and the mandatory knee jerk reaction is "chinese govt==evil", it's actually easier for them too to watch for such _big_ things, than to try to track an individual dissident by sattellite. If they want to track an individual person, they can just send an agent. It's cheaper and doesn't lose track each time the target goes into a house or bus.
It's not just NWN. Diablo 2 took for ever to finish, but it sold like hot cakes because it was a good stable well-designed well-balanced product. Diablo 1 also came out of nowhere as a game that didn't even copy last year's best-seller, but it sold like crazy. Why? Quality. Or Epic and Id pretty much officially have "when it's ready" as a policy, and I you can't say they're going bankrupt because of it. Etc.
True, noone knows in advance the secret handshake that _guarantees_ a bestseller, but if you look at what did well and what failed, you notice a trend. Quality stuff tended to do a lot better than the buggy crap shoved out the door in a hurry.
Contrary to the mentality that hype is everything, quality does sell. People do talk to each other, and that's a big factor that works for the good games, and against the crap buggy ones.
And I don't even only mean code quality, but also design quality. If you look at some of the the things that, say, Blizard did right before, they include:
- very low learning curve (if you can click, you're already half-way to mastering Diablo or Diablo 2)
- well balanced (you don't end up stuck half-way through the game because you chose a class that dies even from a paper cut, or a skill that has no use whatsoever)
- just the right difficulty curve for the casual gamer (the majority of which do _not_ want to reload 25 times to get past a boss.) In fact, better yet, it let you adjust your difficulty curve by yourself, by going faster or slower.
Etc.
That's all things which aren't just stroke of genius, but I'll bet involved a lot of testing and tweaking. They're done well _because_ the games were not shoved out unfinished.
Especially balance _never_ comes from just a stroke of genius, and just writing down some genial numbers from the classes/races/whatever from the start. No matter how bright a designer you are, your first numbers will _always_ suck. Getting them right is invariably a matter of extensive testing, running simulations (e.g., how often does a halfling thief kill an orc barbarian, if you run all possible scenarios), and tweaking.
But somehow the PC game industry just can't get to take quality seriously. Basically they don't _care_ if they're producing crap, including, yes, by stressing the devs and driving away talent.
They just care about having some movie license, a design that's a verbatim clone of last year's bestseller (ironically: it often misses all the parts that made that one a bestseller), and having the game shoved out the door by christmas. Everything else can be fixed by lots of hype, right? (Wrong. But good luck convincing them.)
The character creator is the most generic in existance, so the comparison with selling you crayons and paper is very apt.
Basically it goes like this:
- you choose your body type: male, female or a _massively_ muscular male on steroids
- you choose your height
- you choose your, well, basically width multiplier. So you can drag this down and be a scrawny geek, or to the max and look pretty muscular. (Doing this for the already muscular model is quite impressive.)
- you choose your face, hair style, and clothes, from a surrealistic abbundance of models, colours, decals and patterns. Basically you can wear _almost_ anything you can think of, from spandex, to medieval armours, to robotic bodies/limbs, to jeans and sweaters, to business suits. In any colour you can think of.
Examples of actual characters I've created with it, include (but are not limited to):
- A robotic healer painted camouflage green. (Think: sorta Terminator-like, without the flesh cover.)
- Two dwarfs: traditional axe (tank), and broadsword version (all-out offense). Just take the massive muscular model, make it broad and muscular to the max, put a medieval armour on him, give him a huge beard and make him 4 ft tall. There you go: your own Gimli.
- A knight in shiny plate armour. Broadsword again.
- A tall and thin nerd with jeans, grey sweater and glasses. (You know, the high metabolism nerd variant, not the 300 lbs one;)
- An asian martial artist.
- A massively muscular black man in camouflage pants and combat boots. Sorta like Barret from Final Fantasy 7, except he fighst with his fists instead of the machinegun arm.
- A soldier in camo pants, combat boots, military helmet, and kevlar flak vest.
- A scrawny old doctor with white hair, glasses, goatee, and a grey suit and tie.
So basically you can create almost _anything_. And as you can see, most of them don't even resemble anything that Marvel can claim a trademark on. (If they want to try to trademark dwarfs, I believe Tolkien came before them.)
It's not just about masking artistic deficiencies. Sometimes the clean minimalistic look is actually the best.
The dot-com era was filled with clueless PHBs who thought that the user wants an artistic experience. Every single site had to have some horrible colour scheme (e.g., cyan on bright blue, or orange on light orange are actual colour schemes I was asked to implement.) It had to have gradients, 1 MB of animations per page, impossible to read funky fonts, and graphics _everywhere_.
Turns out that most users _don't_ want an experience. They want a simple an intuitive program that just works, or an easy to use and navigate site.
I.e., my advice to anyone would be:
1. Usability and clean layout before funky graphics. Remember that you're making a professional program, not a work of art. The purpose of that interface is functionality, _not_ expressing yourself or evoking feelings.
This is the main reason why graphics artists are bad web site designers, unless you get them to also learn proper web design. GUI design is a completely different skill from graphics design, and for that matter from programming. (Witness the many excellently programmed OSS programs, that nevertheless have an utter crap UI.)
2. Keep it simple. For a back button, a simple left-pointing arrow will suffice. For file operations, a 3.5" floppy icon works wonders.
Basically, if all you need is an icon, do _not_ try to paint the whole Book of The Dead, with the Pharaoh being led into the underworld and judged. You're making an icon, not a fresco.
3. Keep the learning curve low. If the users have already been educated that symbol X means operation Y, use that. E.g., everyone was already broken in that a left pointing arrow means "back", so use it for that and only for that. Don't try to teach them new tricks just for your program.
This may seem like a rehash of 2, but really has more to do with 1. It's all about usability. Steep learning curves are bad. Reusing the user's existing skills is good.
4. Keep it simple.
4.a. You have precious few pixels in an icon or button, so complex images tend to end up with details that are 1-2 pixels tall or wide. The images must be easy to recognize without squinting to see the details. To that end, for example, a stilized telephone symbol will actually work better than a 3D-rendered anti-aliased phone that's been shrunk to 32x32 pixels.
4.b. Remember that the role of icons, again, are to allow the user to quickly locate common actions on a toolbar. Again, functionality before artistic expression. They are _not_ there to evoke feelings or express yourself.
So simple and clear is good in that aspect too. An arrow or a magnifying glass are things that aren't just easy to draw, they're also very easy to recognize and visually locate.
Etc.
So basically what I'd argue is that often keeping it simple, abstract and clean is actually the _right_ way, and making it overly artistic is the _wrong_ way. Not being an artist or creative can actually be an advantage.
Yes, you can't take a programmer and expect him to be able to paint the sixtine chapel. But here's the fun part: you want an UI, _not_ the sixtine chapel. Someone who tries to make a sixtine chapel out of the UI is actually the _wrong_ person for the job.
Unfortunately, VIA doesn't out-sell Intell or AMD either. If you look at the market share figures, VIA is lost in the decimals. So they have the low price _and_ the low sales.
Or to put it otherwise, it's not that they deliberately sell them cheap to outsell everyone else, it's that they _have_ to give them at barely production price to sell them at all.
Hardly seems like an enviable situation to me.
They _could_ be a contender in the embedded CPU market, that's one good observation. But for some reason they don't seem to be a major (or even minor) player in that segment either.
I don't think so.
Intel has basically been hanging itself with the awful lot of rope their own marketting gave them. The "MHz is everything" marketting was an easy thing to push, since most people actually _want_ one number that tells them everything about a CPU.
(True story: I actually spent some time arguing with a marketroid about it, and gave up. He was arguing that it must be Anantech's and everyone else's benchmarks that are at fault, because CPU A is in some apps 50% faster than CPU B, in some apps equal, and in some apps actually a little slower. "It can't be! If CPU A is X% faster than CPU B, it must be X% faster in everything!" Any explanations about differences in CPU architecture and such, went right above his head.)
So it was easy for Intel to push the MHz as the one true speed indicator. And for a while all they had to do was keep putting out CPUs with more and more MHz.
Except after a while it became a trap. Any new design _had_ to be higher MHz, or have Intel's own marketting working against it. All those many millions that went into telling people "buy a higher clocked CPU", now would basically tell them "don't buy the newest Intel CPU chip", if Intel made one with less MHz.
And now Intel finally _has_ to find a way out of the hole it dug itself into.
As for Cyrix (now VIA), it was never really a problem for Intel. Cyrix just fell behind performance-wise on its own. The last proper Cyrix versions were already falling beind in integer performance too, but it was their floating point performance that was abysmal. So what killed Cyrix was not as much Intel, as games going 3D: now everyone had benchmarks everywhere, clearly showing the Cyrix as barely crawling.
And Via's versions fell behind even more. They aren't just slower in MHz, they're also slower _per_ MHz. Other than being low power, they just suck.
And it's not that VIA really _wants_ to be the poor-man's niche, for Chinese families who can't afford an Intel or AMD. People find such niches to survive, but noone really wants to _stay_ in such a niche. Noone actually wants to sell their top CPU at $30 or less, instead of, say, the $600+ that an Athlon 64 FX sells for.
So if VIA could break out of that unprofitable niche, believe me, they would. The problem is simply that they can't.
As was already answered, it's a very different case, so I see no contradiction even for those who do share files.
But in my case, I'm firmly against sharing copyrighted material too, and I've been known to call it theft even here on Slashdot. I'm proud to say that all the MP3's I have are ripped off CDs I personally own, all my software is legally licensed (yes, I also actually went and bought a Windows 2000 license when I built the second computer), and all the movies I've seen were either in a cinema or off legally rented DVDs.
The games alone occupy some three bookcases, packet tightly. Without cardboard boxes or manuals.
Hence, even if you must put equals between spam and file sharing, I fail to see the problem: I don't do either of them.
Well, I understand what you're saying, but I don't see it as a XOR (exclusive or) situation. In this case it's not a case of "we only round up 10 spammers per year". I should hope it's more like "we keep rounding up as many of them as we can" _and_ lock them away.
... which of those do you think is more of a deterrent?
So basically the difference is between:
A) "we round up as many as we can, and give them a $100 fine" and
B) "we round up as many as we can, and give them 9 years each in state prisons."
I'd say B by far. Situation A would just get factored in as the cost of business.
Actually,
1. Deterrents work admirrably. The fact that you can walk on the street and not be mugged as soon as you open the front door, or for that matter that you didn't get that front door bashed in every night by everyone who would like your TV, is because of the deterrent effect. A lot of people would love to have your wallet or your TV, but wouldn't like the consequences. See? It works.
Sure, it doesn't deterr _everyone_ but if it works on, say, 99% of would-be spammers it already solved the problem perfectly.
2. In this case, you don't even really need it to be a deterrent. It was proven again and again that the majority of spam comes from a handful of fucktards.
So if we throw the top 100 spammers in jail for a decade, there you go, we'll enjoy a decade of email being usable again. It doesn't even matter if it was the best deterrent, or if it deterred anyone at all. We just took the problem out anyway.
I don't know, it seems to me like it's justified nevertheless.
1. Although I find it an inherently cold and heartless thought, we put a price in dollars on a human life all the time. Compare the losses caused by a spammer to that, and it's quite easy to end up higher than the cost of a life.
No, I'm not talking "but a second to delete a spam message costs nothing!" Even then, time is ultimately money. (E.g., you pay over $1000 for a faster computer, yes, to save time. And how many of those upgrades are ultimately just to be able to run an even slower antivirus, spyware killer, etc? That's money costs inflicted by the spammers upon society.)
I'm also talking lots of other effects, such as the cost incurred to companies and individuals to maintain all those spam filters. The IT costs of preventing and cleaning with viruses that exist only to install spam zombies. Costs incurred to ISP's and companies just to deal with the bandwidth and storage used up by spam _and_ all those viruses trying to install spam zombies. Costs related to false positives. (E.g., a missed business opportunity because an email from a legitimate business partner was filtered out.)
Plus the insidious cost of having a valuable communication resource plundered and turned into a worthless wasteland. Whereas we all used to gladly read and answer emails from strangers (e.g., questions about my walkthrough for a game, some yes, including attached pics of where they got lost), nowadays an email from a stranger is most likely to be junked without reading. Doubly so if it contains an attachment of any kind.
I also used to freely give my email address to everyone. Nowadays if someone did that, you'd call them an idiot clueless (l)user. Nowadays if you must enter an email address, it's some black hole account just supposed to be a garbage bin for spam.
All this is not just business opportunities, but literal pollution of a valuable resource, and it affects hundreds of millions of people. Even if you put a 1$ price on that resource for each user affected, you easily end up with a monumental loss that those spammers caused to society.
Yes, higher than what we currently price one life at. Cynical, but true.
2. My favourite example: I think of it not in dollars, but in seconds. A murderer has shortened someone's life by, say, 20 years. And we can execute him for that.
Now let's look at spam. Let's say 100,000,000 users receive spam. Let's also say each user is only robbed of 1 minute per day dealing with spam, installing and updating spam filters, de-installing spam zombies, etc. (Just spending an hour on that software every 2 months, already uses up that 1 minute per day quota. So not unrealistic.)
That means in just 2 months, those users have been robbed of 100,000,000 hours out of their lives! That's 4166667 days! Or more than 100,000 YEARS!
So we can execute someone for stealing 20 years out of someone's life, but you think 9 years in prison is too much for robbing 100,000+ years from us all? Seems to me like it's equivalent to more than 5000 murders. People have been hanged tried as war criminals and mass-murderers for far less than that.
So au contraire, I think the fucktard got off disproportionately lightly. If there was justice and keeping the punishment proportional, a spammer would need to die a thousand deaths. (Which, unfortunately, is impossible anyway.)
You know, I do realize that you just wanted to be funny, but nevertheless the unsettling thought is that there _are_ people who actually think like that seriously. Their kid is something which should shut the fuck up, stay the fuck out of mommy and daddy's way, and generally a pest that should have come with an on/off button so they can turn it off and store it in a closet. (OK, in the kid's room. A bigger closet to store the kid when they don't feel like using it.)
Let me see, someone took, say a $200 CPU, burned it and requested that the company pay for his own incompetence. Seems to me like any way you want to slice it, he caused at least that $200 loss.
And even if you reduce it to the chip's cost without profit margins, he still deliberatey conned someone into paying for _his_ _own_ mistake. Still doesn't look honest to me either way I want to look at it.
The cost of a CPU isn't simply the cost of a few grams of silicon, it also includes the whole chain, including packaging, warehouse space, retail shelf space, fab operating costs (a fab can only produce a given number of chips before you need a new process. You have a fixed X million chips to recoup the fab investment from, so you _must_ include it in the chip's cost) _and_ the salary of the poor sod that processes the RMA.
So let's say it only adds up to $100 out of that $200 cost. It's still dishonestly conning someone out of $100. I fail to see how their stealing "only" $100 is suddenly ok and morally justifiable.
And some of these people experiment with stuff more expensive than that.
E.g., it is commonly recommended on such fucktard boards that you flash a 6800 GT's bios to overvolt and overclock it. A 6800 GT is, what? A $400 video card? (I should know, I own one.)
E.g., with the advent of desktop motherboards for Dothans, the fucktards are already not considering anything lower than an overclock from 2.0 GHz to 2.8 GHz. Yes, needing some overvolting to get there. Want to bet that $400+ mobile CPUs will get burned and RMAed in the process?
If you frequent any kind of hardware forums, you'll see that it still happens all the time. In fact, it happens worse than that.
At least the DCs in your example returned a working card, which could then be resold. Though, yes, they had incurred other costs to the company.
The ones I'm running into are the kind that will _break_ a card or a CPU, for example via extreme overclocking and overvolting (i.e., thermally fry it) and then RMA it and ask for a replacement.
Or install some ludicrious cooler on it, mechanically break the card in the process (e.g., crunching the siliconm but damaging the PCB also isn't impossible for the determined overclocker.) Then put the stock cooler back on and RMA it. On account that it's nigh impossible to prove what's really been done to it.
I've seen into advice which even was as cynical as to state "yeah, AMD will know that you thermally fried the chip, but they send you one replacement anyway. So go ahead and raise the voltage as high as the motherboard lets you. It's safe. You'll get a replacement chip from AMD."
Which, sorry, is as dishonest as it gets. It's actually planning to mis-use and probably break a product, then shaft the company to pay for their hobby.
What can I say? I'm thoroughly disgusted.
"No, that's what happens when you employ clueless morons to write code for you."
You are, of course, right. We can aggree on that wholeheartedly.
However, it doesn't invalidate what I've said. You just detailed one effect of what I was basically saying.
The problem is that the moment someone actually believes "nah, we can't have bugs because we're protected by the holy power of Java" (or "we don't need good coders because Java/VB/whatever is easy to program"), they invariably go and hire the cheapest morons they can find.
It's not even a slippery slope argument. It's not a case of A slowly leading to B which leads to C which eventually leads to D. Here it's direct cause and effect. A straight short road from A to D.
Being able to write all their programs with 2 ex-burger-flippers paid $5 per hour is _the_ wet dream of the industry. So anything which promises to make that even remotely viable, _is_ in fact used as a justification to do just that: fire all those high paid nerds and hire the cheapest monkey in a suit.
Unfortunately, it doesn't work that way. No matter how easy the IDE, language or libraries make it to program, they can't force an untrained monkey to understand security, do a security analysis and write secure code. The less skilled people you can use to string together OCX controlls they don't understand in VB.NET (or Java, or whatever other language), the less clue they'll also have about making it secure.
And even if the language prevents them from having straight buffer overflows, they'll find other ways to make the program even more insecure. Because they don't even understand what they're doing.
So in a sick and twisted way, as I've said, the better tools you have, the poorer programs you end up with. Among other ways, yes, because the more clueless morons get hired to use those tools.
"LOL! I don't know what kind of system it was but imagine that on any kind of business system. Sales clerk leaves ... customer calls up asking "Where's my freakin stuff I ordered?!?" and the person taking the phonecall is like ... "Mmmm, what order? ... and er, who are you?".
."
Then six months later, J.Random Taxman turns up and ask why your invoice numbers aren't contiguous.
Sheesh, even worse, imagine it's a bank!
Even worse imagine that it's a business-to-business system. Also imagine that a user (representing another company) can personally cancel their own account. Basically completely removing any trace of himself/herself from the system.
"What? I never said I'd supply you with X tons of Y for 12 months, at Z dollars per ton. I never even was on your site!"
And there you have it in all its glory: a whole bloody factory is in limbo for lack of supplies and materials. The costs for that kinda fuckup, I'd assume, are quite nasty.
I'm open minded to malice explanations too. Or malice out of stupidity.
In this particular case, doubly so. It fits just nicely with another "feature" of theirs, namely the ability of a user to erase all traces of themselves. You see, in the old system, users and records were never deleted, they were just flagged as deactivated. In their system, deleting a user, did just that: deleted the record. And because of foreign keys, it cascaded through all tables and erased _all_ records related in any way. Suddenly that user... has never existed, never posted anything and generally was figment of everyone else's imagination.
However... in this case if they weren't utterly incompetent monkeys, they were damn good at faking it. There were a ton of other bugs and issues for which it's hard to find a malice-based explanation.
Stuff like that they couldn't parse the phone numbers in the existing database, so they literally requested that some bugger edits a few hundreds of thousands of records per hand to match their format. (And if you think requesting that is idiotic, let's just say a PHB actually approved it. How idiotic is that?)
Try as I might, I'd be hard pressed to imagine what devilishly clever advantage they'd get out of that. What clever back door can be gained by having one poor soul go manually through that mountain of data? It's just stupid.
Or whereas the system they were replacing ran comfortably on one PC in Tomcat, their architecture needed a _ludicrious_ server farm to support the same load. Think: literally dozens of computers. Took many hours just to start or stop the behemoth.
Again, I'm not sure what devilishly clever 0wnage would result from writing piss-poor unperformant code. Were they planning to DDOS it into submission later? Not much point in that, when you can already make yourself the highest ranking admin and cause more trouble.
So on the whole, dunno, I have no trouble whatsoever assuming that they were, simply put, too stupid for those exploits to have been planned. In fact so stupid that if they had tried to code a back door, it would have probably been too buggy to work.
Wrong. You do let arbitrary code download and run all the time.
Each time you go to a web site that uses JavaScript, guess what? You download and run arbitrary code. Interpreted code, yes, but arbitrary code nevertheless.
Each time you download a Java or Flash applet, even if just as an ad on a page, you are downloading and running arbitrary code. In Java's case even downloading and compiling it to binary code for your CPU.
As I've said before it would be possible to sandbox ActiveX to hell and back. Make it run in a virtual environment where it can't touch any files that it didn't create itself (e.g., a chroot jail), open any ports, or even call the OS methods without first going through a sanity checking layer.
Now Microsoft doesn't do that, and it's guilty as charged of bad design there. That much we can aggree upon.
But dismissing it all as "You simply don't allow arbitrary code to download and execute." is simplistic. And in fact it's over-simplified thinking like "Java=good, binary code=bad" is the arch-nemesis of security.
Real security doesn't involve mindlessly pinning magic talismans onto the code, nor repeating fashionable mantras. It involves a real security analysis. Who's going to attack us? How? What _can_ happen? How can we prevent that? Etc.
Again, obviously MS didn't do a real security analysis there. We can aggree on that. But that's no reason to assume that one can't possibly be done by anyone.
I thought the flood was wiping the test data and starting with a clean database :P
In theory you are right, and better tools already exist. E.g., Java has array bounds checking by language definition. E.g., dunno abound Microsoft Visual C++, but I've used C compilers before which could generate code with array bounds checking. (TopSpeed C, for example.) It didn't even require any IDE macros, it just plain and simple generated them in the code automatically, if told to.
The problem however is that, well, no language or library ever can force you to stop making mistakes.
E.g., Java does throw an Exception if you try to overflow a buffer, but that's not an automatic magic talisman against bugs. You still can't let any ex-burger-flipper loose on the keyboard and say "nah, they can't have bugs or security problems. The language won't let them." What happens in practice is that:
1. People catch the exception and ignore it, on account that "it can't happen." Or even write "catch (Throwable t) {}" blocks. (Catch anything whatsoever and ignore without as much as a line in the log.)
2. Which in turn can make the program malfunction in more subtle ways. Even if you don't ignore exceptions is forgetting that the exception may have skipped some code. E.g., closing files or database handles is the most benign, in that it just causes the program to eventually run out of resources and crash.
A less benign case is when the code skipped was, for example, the login authentication. Carefully malformed data might not execute random code, but allow the user to escallate their rights to super-user.
And while a buffer overflow might have turned your machine into a spam zombie, this will instead give them all your business data on a silver platter. Nicely formatted, indexed and searchable too. And allow them to change it too.
3. In a twisted way, a secure language is the worst language because it causes complacency. Yes, it's a bit of an exaggeration, but bear with me while I make a point. Thinking "nah, we're secure because we use Java" (or SSL, or whatever) is the arch-nemesis of security. That way lies madness and skipping a real security analysis.
E.g., where I work, we had a failed project coded not by us but by a team of uber-expensive consultants from a BIG corporation. Utterly incompetent monkeys, but expensive consultants anyway.
It allowed a user to change their id to another user by merely editting the parameter in the URL. Since user id 0 was the super-admin, there you go, an easy way for everyone to escalate their privileges.
It also allowed anyone to access and _edit_ any data, including other users' data and passwords, again by simply editting the URL. Including, yes, changing the passwords for the admin and then logging in as admin.
It also allowed users to embed HTML text and even JavaScript in their text, which would be faithfully included in the page without quoting. Just in case you wanted to cause a JavaScript exploit or redirect to be displayed in other users' or admins' browser, you know.
What was worse, though, was that it didn't quote text used to build SQL statements either, basically allowing anyone to exploit the program into giving them all the data in the system. (If they didn't already get to it via the previous two exploits. As they say, three's a charm.)
Etc.
Again, personally I'd rate that as _worse_ than a buffer overflow. Attacking a company's own web programs via buffer overflows, and finding your way from there to the data, is something only a die-hard black-hat would do. Even ordinary script kiddies with rootkits won't bother doing much more than installing a spam zombie or warez/porn ftp server there. Whereas this presented an intuitive, menu-driven, user-friendly way to own a company's business data. And _change_ that data as you see fit.
In a nutshell, that's what happens when you start thinking that the language or libraries are a magic talisman. The moment you think "nah, we don't need a security analysis, because the holy Java will protect us"... that's when you are the most vulnerable.
The problem is that nobody writes perfect code.
Yes, we're all nerds, and we're all arrogant. We all like to act as if _our_ code is perfect, while everyone else is a clueless monkey writing bad code. _Our_ bugs are few and minor, if they exist at all, while theirs are unforgivable and should warrant a death sentence. Or at the very least kicking out of the job and if possible out of the industry altogether.
The truth however is that there's an average number of bugs per thousand lines of code, and in spite of all the best practices and cool languages it's been actually _increasing_ lately.
Partially because problems get larger and larger, increasing internal communication problems and making it harder to keep in mind what every function call does. ("Oh? You mean _I_ was supposed to call that parameter's range before passing it to you?")
This becomes even more so when some unfortunate soul has to maintain someone else's mountain of code. They're never even given the time to learn what everything does and where it is, but are supposed to make changes until yesterday if possible. It's damn easy to miss something, like that extra parameter being a buffer length, except it was calculated somewhere else. Or even hard-coded because the original coder assumed that "highMagic(buf, '/:.', someData, 80)" should be obvious for everyone.
And partially because of the increassing aggressiveness of snake oil salesmen. Every year more and more baroque frameworks are sold, which are supposed to make even untrained monkeys able to write secure performant code. They don't. But clueless PHBs and beancounters buy them, and then actually hire untrained monkeys because they're cheap. And code quality shows it.
But either way, everyone has their own X bugs per 1000 lines of code, after testing and debugging. You may be the greatest coder to ever walk the Earth, and you'll still have your X. It might be smaller than someone else's X, but it exists.
And when you have a mountain of code of a few tens of _millions_ of lines of code, even if you had God's own coding practices and review practices, and got that X down to 0.1 errors per 1000 lines of code... it still will mean some thousands of bugs lurking in there.
No, a killer even by Bartle's own paper is someone who acts in unwanted ways upon the players. You will notice that he clearly makes the distinction between "interacting WITH players" (something bilateral) and "acting UPON players" (something unilateral, whether those players want it or not.)
"Acting upon players" is his way of saying "treating them as NPCs", in a nutshell.
It doesn't have to be a PK-er, yes. But it is nevertheless unwanted interaction.
A leader of a vocal minority may not be a "Killer" by Bartle's definition, if that vocal minority doesn't do anything to ruin the game for the others. E.g., the leader of a newbie helper guild may be as vocal as he wants, it usually doesn't detract to anyone's enjoyment.
A leader of a vocal minority _could_ be a "killer" if that position and being vocal is used to drive other players off the MUD. E.g., to defame and harrass.
In which case, sorry, they also fit in my view as a "griefer".
A willy merchant is _not_ automatically a "Killer". A merchant who merely sells and buys wares, even making a neat profit, is usually actually a socializer. Players _interact_ with him, are not _acted_ _upon_.
A scammer or thief on the other hand, is a "Killer". It's not bilateral interaction, it's unilaterally acting upon you just because he/she can.
And again, in my book they fit neatly under "griefer".
The "long term good" is usually just a piss-poor excuse for stuff that's just badly designed. Or for piss-poor hacked-together poorly-thought-out fixes for bad design.
A game is for the players. Period. Idiocies like "short term bad, long term good" mean no less than "it's not fun for the players, but it'll be good in the long term for the game". Which, sorry, is an idiotic contradiction in terms.
And I've yet to see any proof yet that stuff described as "long term good" is actually good in any form or shape. You're usually just supposed to believe some fucktard admin's "it's good because I want to code that. So what if nobody likes it? It's... umm... yeah, it's 'long term good'."
He also trolls his way around real issues, by dismissing them as stuff only newbies dislike. Well, gee. With a decade of playing on MUDs behind me, I think I'm anything _but_ a newbie, yet stuff like PD I hate with a passion.
Plus you'd think that if oldbies invariably loved these features, the oldbies already trained in other games would gravitate towards games offering these features, no? That you could just make a griefer's paradise MUD with PD, nowhere to hide, etc, and every grizzled veteran would gravitate to it. I mean, he says that experienced players want that, no? In practice it doesn't happen. Oldbies avoid these places just as well.
And what disturbs me about Bartle in particular is that he's always went above and beyond the call of duty to justify griefing.
E.g., he's went and argued before that you _need_ killers harrassing the socializers to have a good game. Never mind that in practice that cost Origin the number one place in a market they _created_. Origin took basically Bartle's view that being PK-ed on sight is good, while its players migrated en-masse to EQ and AC where they'd be more protected.
E.g., here not only he wants that an older griefer can _permanently_ kill you, he also wants that you have no rest and no place to hide from that griefer.
Read the point against instancing again. So basically the players actually want some peace and tranquility, but nah, he's more concerned with "what with someone else wants to find them and interact with them while they're in there?"
Well, gee. For friends everyone already was more than happy to invite them to the group. E.g., if I'm in an instanced dungeon in CoH and someone I know gives me a tell, I'll promptly get out of the dungeon and invite them. Or if they need help with their mission, I've been known to leave my mission and join in theirs.
So who are those poor souls who are prevented from interacting with you? Well, the ones you _don't_ want to interact with. The griefers, fucktards, and other scum of the (virtual) earth. Those are the only ones really hampered by instancing.
I.e., again Bartle just goes on a demagogy spree to hammer his old "griefing is good" preconception.