Well, the jail sentence hasn't actually been set. And, actually, in a good system, yes, the maximum possible sentence should be too high - that way, the correct range of sentencing is possible. His minimum possible sentence assuming conviction is six months. If this system is running correctly, you should feel that's too short.
Ideally, you want the minimum to be too low, and the maximum too high; that way the right number is always available to the judge. It seems to me that that's exactly what's going on here.
As far as the fine, given that fraud is involved, the judge can basically do whatever the hell they want, as long as there's a justifying argument. Considering that this is the same circuit court that handed a $16.4m fine to Howard Carmack, who was at that time believed to have profited about $14m from his deeds, I think maybe you're jumping the gun a little bit on worrying the fine will be too low.
All they did was arrest the spammer. Nothing's been decided yet.
*65* years? That seems way over the top. Why can't laws just reflect some reason in the usa?
Don't put so much trust in the legal comprehension of your fellow slashdotter. 65 years is the number you get when you look at the maximum sentence for every single thing he's accused of, and then add them up. This virtually never happens in court. Much more likely is that the court will pick the worst penalty, set it near its maximum term, and make him serve most of that with the other penalties set concurrent.
Consecutive sentences are exceedingly rare in this country, outside of violent crime. We teach our jurisprudents to be very, very careful about using that particular hammer, and almost every state has an automatic investigation of any judge who uses more than a certain amount of consecutive sentencing.
I very much expect the spammer to be sentenced to 10-12 years for the fraud, with a potential early release around five years. That's quite reasonable - this kind of behavior can cost people their jobs (a spammer almost killed an ISP I worked at once.) Remember, we don't just punish for the bad things people do; we also punish for the risks they put other people at, even when nothing bad happens. That's why you lose your license for speeding, even if you didn't crash.
Can we then arrest someone at Microsoft who was responsible for making it so easy to create bots?
Absolutely not. Contrary to popular SlashDot opinion, it's actually very difficult to get the security down for a several hundred million line application (the largest in human history.)
but it sure would be nice if Microsoft was called into the spotlight
My local TV news bitches about MS security on a weekly basis. Frankly, I'm pretty tired of hearing about it. Viruses were around before MS was the dominant OS vendor. There were two points at my life in which I saw a significant change in virus activity: first, when I exposed myself to BBSes, then later, when I exposed myself to the internet.
65 years is basically a life sentence. Is that excessive?
Depends. Do you want to forget that he's done more than just spamming? The truth is we have no idea what damage this guy caused. He went out of his way to make other people - sometimes businesses - look responsible for his behavior. An ISP I used to work at very nearly went out of business because of such an attack once. Eleven people - one pregnant - would have lost their jobs, and this was at the very worst part of what we now call the dot com bust.
So I mean, yeah, a life sentence seems pretty harsh. But, look - that's the worst possible sentence, not what he's actually gotten; furthermore, that assumes that the judge wants consecutive terms rather than concurrent terms. It's quite a bit more likely that Solway will end up spending the bulk of the single largest charge in jail (presumably the fraud charge.) I'm expecting twelve years, and for the amount of damage his kind of behavior can cause, that sounds entirely reasonable to me. This guy could potentially have cost thousands of jobs. You're damn right he needs to be behind bars long enough to miss a fashion trend.
This isn't about the spam, in my eyes. This is about the fraud. Spam's one thing. Making other people take the brunt - that's something else entirely.
It seems that they've already begun to develop services akin to the message passing systems in Erlang and Mozart-Oz. Given that those message passing systems are how those languages avoid the vast bulk of problems described, it seems likely that their attempts to prevent these problems are in fact well underway.
You're the one suggesting threads, not me, not the article. Confusing threading with parallelism is problematic. You'll notice for example that the language I'm suggesting the use of - Erlang - doesn't use threads. They're distinct processes, and *don't* have access to each other's memory.
As far as why not to use fork, well, it's just too heavy. Fork becomes problematic around a few dozen invokations. Parallel programming, depending on approach, may lead into the millions of concurrent active processes, in languages which aren't dependant on OS implementations (erlang isn't alone in this, either: mozart-oz, twisted python, some ML dialects, and suddenly Java wrt: green threads are starting to catch on to the extremely lightweight process model.)
Green threads are too heavy, and their design precludes that ever being fixed. I retain my doubts that Java will survive the transition to massive parallelism. If you look into my crystal ball, you see a future dominated by erlang, concurrent c, fortress, twisted python, and mozart-oz.
It is definitely hard to justify parallel programming
It's hard to justify any programming technique. This is tautological. The implication you're making - that it's harder to use parallel implementations for a given project than single-path (my god, if one more person calls that imperative...) seems fundamentally broken. The suggestion seems to be that you have to qualify fundamental aspects of your design to someone who is unable to grasp them. If that's the case, the problem isn't the difficulty of justification, but rather the person to whom you're forced to justify.
The thing isn't necessarily that it is particularly hard to write multi-threaded applications -- the thing is that it is a lot harder to write a multi-threaded program than to write a single-threaded program.
... in some languages, at certain levels of experience, yes. However, as many other programmers in this story have pointed out, the threaded exchange of control is frequently far simpler than the non-threaded exchange of control. The vast bulk of problems about threading come from naive programmers attempting to make interdependant threads and then screwing up the connection logic. Believe it or not, some of us don't make that mistake. Threading doesn't have to be a minefield.
Suddenly, you have to introduce locks in all shared data structures and ensure proper locking in all parts of the program.
Only if you're naive enough to introduce data structures that are available to several threads.
That kind of thing just adds a significant part to the complexity of a program, and it requires a lot more testing as well. Therefore, justification is definitely needed.
With all due respect, I think you're confusing what the basis of that need is. The problem there isn't parallelism at all. The problem there is a novice's view of threading. I mean, the very first thing you said after discussing the impact of threading was to bring up the single most important thing you should not do.
There are lots of people who found life becoming far easier once they embraced the principles of modularization, typically through object orientation. OO seems to be the de rigeur thing to teach these days. As such, a lot of people can lean back and say to themselves "oh yeah, I remember how much harder life was before I learned to divide tasks into discrete pieces."
Are you open to the possibility that there are other such things you have yet to learn, particularly in the area of parallelism?
Asynchronous message passing does not fix deadlocks. Deadlocks are a design flaw, not a ramification of language design. A simple case is between three processes, A waiting on B, B waiting on C and C waiting on A. Any experienced message passing language programmer will tell you that the problems they heard got magically solved just got harder to make. In the case of asynchronous message passing, Erlang is about the only language I can think of that's been around long enough to have genuinely experienced programmers, but hey, one's good enough.
one has to ask: is parallel programming just too difficult for most programmers? Are the tools inadequate or perhaps is it that it is very difficult to think about parallel systems?
God, no. Just start learning the appropriate tools (erlang, twisted python, mozart-oz, et cetera.)
I've said it before; I've worked in the banking industry, and it is widely known that requiring a PIN number for every transaction would reduce credit card fraud to almost zero.
Given that ATM fraud is nowhere near zero (indeed, I've been ATM defrauded more than once, but never credit card defrauded) and given that nobody's ever tried PINs at large scale on credit cards, I wonder how exactly they propose they know this. I mean, I don't even see how it'd affect this particular attack against credit cards.
Credit cards and ATM cards have one enormous difference: companies keep credit cards for repeat payments. If companies could keep ATM cards to make repeat payments, you'd see this problem spread to ATMs at the same level it has spread to credit cards. That's the real difference here: these small web firms can't lose control of your ATM data because they never had it in the first place.
A pin wouldn't help for the same reason that the security code doesn't help - these records are being exposed by accident, so any data that needs to be kept will be exposed at the same time. Required to write down a security passphrase? Someone's maiden name? Address, backwards, in Greek? No problem: it's all automated for the store, and since that automation is what's being broken, it's just one more field to read.
The fundamental problem is that no amount of security will halt the loss of data from a poorly written customer processing system. Any system that can automate payments has enough information to be used as a seed site for fraud.
The problem is nowhere near as simple as you suggest. Banks do, in fact, spend a tremendous amount of money on this problem, even if it's not through directly funding the merchants' errors. This money comes out of them in customer education, system deployment, insurance, and a variety of other places. Furthermore, customer confidence determines how often these cards are used, and banks make money when these cards are used; the less confidence the consumer has in the system, the smaller that revenue stream gets.
Banks understand that these thefts diminish that revenue stream. They are taking significant action. It's not easy to upgrade a network with tens of millions of ubiquitous, frequently completely unmanned terminals across the globe.
Am I saying the system is good enough? Hell, no. But, I do think you're dramatically undervaluing the difficulty of fixing it, as well as the amount of work being put towards improvement.
Uh, Slashdot has a history of finding authors that one editor enjoys and posting most of their stories.
Obviously the system isn't going to change for you, so attempting to complain about them as a way for making karma is the only alternative motive I can imagine. That and you're a million plus uid user who is realizing his opinion amounts to nothing in the greater scheme of things.
That said, there are times - and this is one of them - that I'm glad my recently most common database isn't fundamentally SQL, or anything well-recognized. It also helps that (I believe) mnesia is immune to injection, given that its queries are never textual, but rather always functional, and given that data are always presented as arguments. Every route to injection I'm aware of just doesn't make sense in context (though if someone knows a way attack Mnesia, I'd love to hear about it.)
Sure, there are times at which SQL is a major win over mnemosyne, but they're not common. Sure, it's nice to have a database be ready for you at any host, instead of having to take the time to find a good host who lets you run stuff. But when it comes down to it, the atypical performance characteristics of Erlang (especially since I write multiplayer games, for which massive concurrency is win) and the ridiculous speed of Mnesia make me miss SQL less every day.
'Course, client stuff still needs to work on MySQL. :(
That depends. If the system shows repeated failure, sometimes it can be important to start on a replacement system. Most flaws can be repaired, but every so often you find an architecture built on unsound principles, or a core design failure on which other systems are irrevocably dependant.
Now, I'd like to think that every nuclear plant in the country has a better control system (not that I'd know.) That said, if I walked in and saw a defect rate that PSP and TSP said were a death spiral, you'd better believe I'd suck it up, put down the cash and buy a second engineering team to work in parallel on a replacement product. The only thing worse than a nuclear plant which is radically over budget because of critical system redesign is a nuclear plant which is reduced to hot gas by the lack of critical system redesign.
I applaud you for suggesting caution when discussing the gutting and re-stuffing of the fish. That said, "back in the real world," there are times at which starting over is significantly less expensive in time and money than fixing what you already have. They're rare, and I should hope they essentially don't exist at facilities with safety concerns at this level, but it is important to acknowledge that a software system can be so large a failure that replacement is the better option, so that when you do in fact hit such a situation, you handle it appropriately.
At times like those, I don't think I could act without a statistical defect control practice. Otherwise, getting out of analysis paralysis would seem to consist of the worst and scariest guess ever.
Actually, power plants have to have a connection to the outside world.
Doesn't have to be on the Internet, though. 'Course, then again, the Internet itself was once an isolated network to prevent critical systems being exposed to this sort of thing. Maybe we need a new ArpaNET?
seriously though, I think something like Second Life will only really take off when an open-source, decentralized metaverse comes along.
I don't. From my (admittedly limited) experience as a commercial game designer, I believe that Second Life's primary two benefits are the open scripting (obvious) and the size of the player base (less so.) The game that got famous inside Second Life, called Tringo, is an excellent example. What Second Life brought to Tringo's author wasn't a scripting enviroment s/he couldn't have found in the past, nor a UI paradigm nor anything like that. What SL brought him/her was players, and an open decentralized metaverse won't have those.
Think of it like retail. You can have all the stores you want, but for the most part, unless you're a destination store, people are gonna go to malls. Second Life is a huge mall. It has enormous foot traffic that stores like Bed Bath and Beyond could never, ever generate.
Decentralization is small-scale poison. MUSHes and MUDs have existed (and been graphical and scriptable - one of the big VRML clients, Chaco Pueblo, was actually a MUSHing client) for 20 years, but none of them stuck, because their player bases were too small. Lots of them are still around, but they don't even have the population of a Perplex City, let alone a World of Warcraft.
Centralization is the win here, not the other way around.
Rent one and go to the club. Then you'll understand. Young people are easily impressed by large expensive pointless things. They're not called cockmobiles because they're used to transport chickens.
A small heads-up: after college I lived with a mechanic for a roommate, and he told me that it was helpful to accelerate hard once in a while to burn off carbon deposits in the engine.
Slashdot Mirror
Well, the jail sentence hasn't actually been set. And, actually, in a good system, yes, the maximum possible sentence should be too high - that way, the correct range of sentencing is possible. His minimum possible sentence assuming conviction is six months. If this system is running correctly, you should feel that's too short.
Ideally, you want the minimum to be too low, and the maximum too high; that way the right number is always available to the judge. It seems to me that that's exactly what's going on here.
As far as the fine, given that fraud is involved, the judge can basically do whatever the hell they want, as long as there's a justifying argument. Considering that this is the same circuit court that handed a $16.4m fine to Howard Carmack, who was at that time believed to have profited about $14m from his deeds, I think maybe you're jumping the gun a little bit on worrying the fine will be too low.
All they did was arrest the spammer. Nothing's been decided yet.
Consecutive sentences are exceedingly rare in this country, outside of violent crime. We teach our jurisprudents to be very, very careful about using that particular hammer, and almost every state has an automatic investigation of any judge who uses more than a certain amount of consecutive sentencing.
I very much expect the spammer to be sentenced to 10-12 years for the fraud, with a potential early release around five years. That's quite reasonable - this kind of behavior can cost people their jobs (a spammer almost killed an ISP I worked at once.) Remember, we don't just punish for the bad things people do; we also punish for the risks they put other people at, even when nothing bad happens. That's why you lose your license for speeding, even if you didn't crash.
Given that he hasn't received a penalty yet, I'm willing to guess "no." The harshest penalty I'm aware of for a spammer was the seven year, 3.5 year minimum term with $16.4 million fine issued by Elliot Spitzer/NY to Howard Carmack (the "Buffalo Spammer".) However, this isn't exactly something I follow, so there may be something more severe elsewhere.
The real culprit here is other people.
So I mean, yeah, a life sentence seems pretty harsh. But, look - that's the worst possible sentence, not what he's actually gotten; furthermore, that assumes that the judge wants consecutive terms rather than concurrent terms. It's quite a bit more likely that Solway will end up spending the bulk of the single largest charge in jail (presumably the fraud charge.) I'm expecting twelve years, and for the amount of damage his kind of behavior can cause, that sounds entirely reasonable to me. This guy could potentially have cost thousands of jobs. You're damn right he needs to be behind bars long enough to miss a fashion trend.
This isn't about the spam, in my eyes. This is about the fraud. Spam's one thing. Making other people take the brunt - that's something else entirely.
It seems that they've already begun to develop services akin to the message passing systems in Erlang and Mozart-Oz. Given that those message passing systems are how those languages avoid the vast bulk of problems described, it seems likely that their attempts to prevent these problems are in fact well underway.
Er, Origami is still under development.
You're the one suggesting threads, not me, not the article. Confusing threading with parallelism is problematic. You'll notice for example that the language I'm suggesting the use of - Erlang - doesn't use threads. They're distinct processes, and *don't* have access to each other's memory.
As far as why not to use fork, well, it's just too heavy. Fork becomes problematic around a few dozen invokations. Parallel programming, depending on approach, may lead into the millions of concurrent active processes, in languages which aren't dependant on OS implementations (erlang isn't alone in this, either: mozart-oz, twisted python, some ML dialects, and suddenly Java wrt: green threads are starting to catch on to the extremely lightweight process model.)
Green threads are too heavy, and their design precludes that ever being fixed. I retain my doubts that Java will survive the transition to massive parallelism. If you look into my crystal ball, you see a future dominated by erlang, concurrent c, fortress, twisted python, and mozart-oz.
There are lots of people who found life becoming far easier once they embraced the principles of modularization, typically through object orientation. OO seems to be the de rigeur thing to teach these days. As such, a lot of people can lean back and say to themselves "oh yeah, I remember how much harder life was before I learned to divide tasks into discrete pieces."
Are you open to the possibility that there are other such things you have yet to learn, particularly in the area of parallelism?
Asynchronous message passing does not fix deadlocks. Deadlocks are a design flaw, not a ramification of language design. A simple case is between three processes, A waiting on B, B waiting on C and C waiting on A. Any experienced message passing language programmer will tell you that the problems they heard got magically solved just got harder to make. In the case of asynchronous message passing, Erlang is about the only language I can think of that's been around long enough to have genuinely experienced programmers, but hey, one's good enough.
The language you're describing has been around for a long time, under various names. I recommend you look into either erlang or mozart-oz.
Parallel programming's actually pretty easy.
Credit cards and ATM cards have one enormous difference: companies keep credit cards for repeat payments. If companies could keep ATM cards to make repeat payments, you'd see this problem spread to ATMs at the same level it has spread to credit cards. That's the real difference here: these small web firms can't lose control of your ATM data because they never had it in the first place.
A pin wouldn't help for the same reason that the security code doesn't help - these records are being exposed by accident, so any data that needs to be kept will be exposed at the same time. Required to write down a security passphrase? Someone's maiden name? Address, backwards, in Greek? No problem: it's all automated for the store, and since that automation is what's being broken, it's just one more field to read.
The fundamental problem is that no amount of security will halt the loss of data from a poorly written customer processing system. Any system that can automate payments has enough information to be used as a seed site for fraud.
The problem is nowhere near as simple as you suggest. Banks do, in fact, spend a tremendous amount of money on this problem, even if it's not through directly funding the merchants' errors. This money comes out of them in customer education, system deployment, insurance, and a variety of other places. Furthermore, customer confidence determines how often these cards are used, and banks make money when these cards are used; the less confidence the consumer has in the system, the smaller that revenue stream gets.
Banks understand that these thefts diminish that revenue stream. They are taking significant action. It's not easy to upgrade a network with tens of millions of ubiquitous, frequently completely unmanned terminals across the globe.
Am I saying the system is good enough? Hell, no. But, I do think you're dramatically undervaluing the difficulty of fixing it, as well as the amount of work being put towards improvement.
Uh, Slashdot has a history of finding authors that one editor enjoys and posting most of their stories.
Obviously the system isn't going to change for you, so attempting to complain about them as a way for making karma is the only alternative motive I can imagine. That and you're a million plus uid user who is realizing his opinion amounts to nothing in the greater scheme of things.
Guess what, buddy? That's life.
Of course, security through obscurity is badbear.
:(
That said, there are times - and this is one of them - that I'm glad my recently most common database isn't fundamentally SQL, or anything well-recognized. It also helps that (I believe) mnesia is immune to injection, given that its queries are never textual, but rather always functional, and given that data are always presented as arguments. Every route to injection I'm aware of just doesn't make sense in context (though if someone knows a way attack Mnesia, I'd love to hear about it.)
Sure, there are times at which SQL is a major win over mnemosyne, but they're not common. Sure, it's nice to have a database be ready for you at any host, instead of having to take the time to find a good host who lets you run stuff. But when it comes down to it, the atypical performance characteristics of Erlang (especially since I write multiplayer games, for which massive concurrency is win) and the ridiculous speed of Mnesia make me miss SQL less every day.
'Course, client stuff still needs to work on MySQL.
That depends. If the system shows repeated failure, sometimes it can be important to start on a replacement system. Most flaws can be repaired, but every so often you find an architecture built on unsound principles, or a core design failure on which other systems are irrevocably dependant.
Now, I'd like to think that every nuclear plant in the country has a better control system (not that I'd know.) That said, if I walked in and saw a defect rate that PSP and TSP said were a death spiral, you'd better believe I'd suck it up, put down the cash and buy a second engineering team to work in parallel on a replacement product. The only thing worse than a nuclear plant which is radically over budget because of critical system redesign is a nuclear plant which is reduced to hot gas by the lack of critical system redesign.
I applaud you for suggesting caution when discussing the gutting and re-stuffing of the fish. That said, "back in the real world," there are times at which starting over is significantly less expensive in time and money than fixing what you already have. They're rare, and I should hope they essentially don't exist at facilities with safety concerns at this level, but it is important to acknowledge that a software system can be so large a failure that replacement is the better option, so that when you do in fact hit such a situation, you handle it appropriately.
At times like those, I don't think I could act without a statistical defect control practice. Otherwise, getting out of analysis paralysis would seem to consist of the worst and scariest guess ever.
Think of it like retail. You can have all the stores you want, but for the most part, unless you're a destination store, people are gonna go to malls. Second Life is a huge mall. It has enormous foot traffic that stores like Bed Bath and Beyond could never, ever generate.
Decentralization is small-scale poison. MUSHes and MUDs have existed (and been graphical and scriptable - one of the big VRML clients, Chaco Pueblo, was actually a MUSHing client) for 20 years, but none of them stuck, because their player bases were too small. Lots of them are still around, but they don't even have the population of a Perplex City, let alone a World of Warcraft.
Centralization is the win here, not the other way around.
Windmills do not work that way!
That explains why Hawking is in a wheelchair. Quick, find me a programmer with a skateboard.
Rent one and go to the club. Then you'll understand. Young people are easily impressed by large expensive pointless things. They're not called cockmobiles because they're used to transport chickens.
A small heads-up: after college I lived with a mechanic for a roommate, and he told me that it was helpful to accelerate hard once in a while to burn off carbon deposits in the engine.