you're being stupid. the post that started this said something like "proving doesn't work, you need to test". your point is that proving doesn't work because people make mistakes. well, testers make mistakes too, nitwit, so you have no point.
I didn't say testing was perfect, that would be silly. But at this point, you're just being rude.
Let me try to put it in a way that cannot be misconstrued easily. Proving is fine and dandy for those who want to do it. But like anything in software development, it doesn't mean "bug-free", or even excellent code will result. That was my only point that I was trying to make by giving the Naur example. The idea behind the Naur program was very simple, yet it still had errors in it. Personally, I regard proving as less effective (costwise, maybe) than testing. Again, personally, I would appreciate the statement "The software has gone through rigorous testing" more than "The software has been proven to be correct". It's not an either-or situation, I realize, I'm just proving a point. That's my opinion, and everyone has their own, so if you don't like mine, then ignore it. Software methodologies discussions are full of opinions, and mine is just another one of them. Feel free to dismiss it.
If he had actually had a proof, there couldn't have been any bugs in the program relative to the specifications
"Relative to the specifications" doesn't mean too much in the end, because it assumes that the specifications are the end-all be-all to what goes in the software, and are by definition correct. Of course, we are human, and this is hardly the case. There are sometimes "gotchas" or special cases that come up that aren't in the specs. Someone thought they were being absolutely clear when they weren't, etc. Is that a valid bug when it surfaces in the code? Absolutely.
Then the responsibility is put on the specs, so one may say "well, make sure the specs are right." That's not as easy as it seems, since the English language alone has communication problems. Add on that someone has to read through it all and flush out everything that it says, ensuring that no other person could possibly find something misleading or incorrect in it. This has to be done to a certain extent, but eventually you're going to hit a wall where it doesn't pay to refine the specs any more. Of course, it still won't be perfect, and software that is proven to operate by it still won't necessarily be bug-free.
Don't get me wrong, proofs are fine as a first step, but people make mistakes. Specs can be misleading, cases can be missed, etc. You need to also test, plain and simple.
Not making mistakes is what makes software robust.
It sounds pretty simple doesn't it? Just be perfect, and your software will be robust. That's fine for the gods, now what about us mere mortals?
Proving software correct shouldn't hold much weight. Testing is really the only way to go.
For instance, here is a pdf that mentions Naur "proving" a very simple ALGOL program correct, but obviously not testing the code. The program was only 25 lines long and reformatted text (basically a word wrapper). Later on there were (at least) 5 bugs found in the code.
Which goes to show that testing is what makes software robust.
The main reason that microkernels have not gained more acceptance in OS circles (although Windows NT is based on microkernel design)
Hmm, well let me elaborate on that comment. IIRC, both user mode and kernel mode drivers can be done in NT. Before NT4, it was all user mode drivers. After that, it became optional, presumably for efficiency's sake. Oreilly has a good sample chapter page on the NT I/O subsystem:
http://www.mcdonalds.com/legal/legal.html
Scroll down to the tradmark info, listed in alphabetical order. Smile isn't one of them, but "We love to see you smile" is.
While I'm not going to argue you're first point (cards were expensive, for what they were), the second point is definitely from left field. I remember that the "tournament legal" decks had to ban/restrict some of the old cards just because they ended up ruining the game outright due to their power. Certain card combos could end up with a game being over before it even really started.
The number of "trouble cards" slowly decreased with each edition as Wotc got pretty smart about balance. Sure, they had their mistakes, but overall, they've made good, balanced cards. I've looked at the new cards these days, and they tend to have "penalties on the side" or strange side effects, or effects that generally aren't all that useful but could be interesting with other cards. In essence, it became more about building a good deck that getting the best cards. Today's Magic is a far cry from the old days of "I got a good draw, so you don't get your first turn...I will draw 3 more cards, then a new hand...now I have plenty of land, and a very powerful creature. You now have three turns to live, if you're lucky. I could have killed you already, but I decided to make it interesting."
One of my chemistry professors once claimed that everything boils down to chemistry. One of my physics professors said that in acuality, everything boils down to physics. I'll always remember those two statements, but the statement that I find rings truer than those is one by Galileo himself:
The book of nature is written in mathematical equations.
A rough quote from memory, so excuse me if it's not exactly correct. It seems that everything can be expressed in mathematical terms. In a sense, it is the mother of all sciences. Does this mean that all science is computer science? Possibly. Computers, at their core, are simply playing with numbers. Heck, there's a reason that it's called a computer. Saying that all science is computer science might also be giving too much credit to the computer itself, if you ask me. I believe a more honest statement would be "All science is mathematical in nature. Computers are mathematical devices. Therefore, assuming an appropriate computer, all science can be expressed in computational terms."
The idea that all IP is just "numbers" and can't be owned is a fallacy. Anything in the universe can be hashed to a numerical representation. My car has a number, and I most certainly can own it. To suggest otherwise is to advocate a communist system.
To quote Galileo (roughly):
"The book of nature is written in mathematics."
but the fact is that the very first "real program" I wrote at my job was in C. Not C++, not Object C, damn sure not Java: straight C. And if I'd only been trained in Java at that point, I'd have been fucked.
All of your points mentioned, (pointers, main, GC) really don't have anything to do with OO programming. Ok, maybe the "main()" comment had something to do with it, but I couldn't really see how having a main outside of an object could cause someone much grief. Besides, OO programming does not necessarily demand that construct.
The points you mentioned are for lower-level languages and against higher-level ones. You could have easily said "Perl programmers have problems understanding freeing their data and pointers" instead of Java programmers having those problems, and the argument still fits.
That was pretty funny. But it's important to note that sometimes readability isn't a big issue. There are times when I want to quickly write something on the fly in 15 minutes to perform a task (analyzing the contents of a text file, say), and I'm not going to use the program later, or it's short enough to where it won't be too difficult to see what's going on. If I need to write a quick script for an easy-to-describe, but time-consuming-to-do-by-hand task, then I want a language that allows me a quick and dirty solution. Sometimes, the terser I can be, the better. Granted, my example is perl's forte, but even outside of that, this still can hold true.
More importantly, the the power is produced in centralized locations. This means if the power plants become 5% more efficient all of the EXISTING vehicles create less polution. Not to mention that as more power plants shift away from nasty sources of energy like coal, every electric cars on the road will become truely polution-free almost overnight.
It seems that everything is going client-server these days, eh?
Bad geek joke, I know. But this really is the power of an architecture manifesting in another area. Put too much into the client (the car), and it's harder to undo later.
For OO geeks, that means that there is now an abstraction layer between the car and the...ah, never mind... =)
But what you're doing isn't boycotting. A boycott is when you don't use a product for moral reasons. You are still using their product.
Well, maybe so, if his boycott target is music in general. Perhaps, instead, he is boycotting the distribution model. He has no moral problem with music in general (who does?), and that is the product that he is getting. What is being abstained from is the distribution model (or, potentially, the companies that use the model) that he gets reamed by financially.
Your Montgomery Bus Boycott analogy would work better if he had been stealing CDs from the store. However, if we take into account that he is against overpriced CDs as a form of music distribution, then the dilemma has been resolved. Well, maybe one could argue that mp3s come from CDs and that's a problem, but hey, close enough. The Montgomery Bus Boycotters effectively said "I'll use another form of transportation", and he is saying "I'll use another form of distribution".
Is he still a "thief"? Probably. But I think he's still making a statement.
Perhaps I didn't state my comment correctly. I do appreciate one-liners in a sense. After all, I _did_ admit that it was novel. When I see something implemented in one line, or two lines, or whatever small number of lines, I think to myself "Yea, that's kinda cool", but I know that it says little about the program's problem domain. In the end, it really says something about the language it was written in and the ability of the programmer to use that language to its fullest.
The reason that I said what I said is that the article on slashdot basically made it sound like the program made a statement about the technology behind CSS. To quote the article:
It's also a bit of an embarassment for Hollywood when you consider that the basis of a multi-billion dollar revenue-stream can be foiled by such a small piece of code!
Therefore my point is that this statement is out of line. How small a piece of code is has little to do with the algorithm behind it. While there is the debate about whether laws are enforceable or not, the size of the code is insignificant.
I agree with the original post that the size doesn't matter. The only thing that is proven by this program is that perl can be extremely terse and can do just about anything. I'm willing to bet that this algorithm could be expressed in a shorter way using a different language. To bring it to the point of absurdity, I could propose a new, hypothetical language, "DeCSS/C", where a standard library call called "d()" will decode a file. We could all stand back and say "Ha! One line of code to crack the encryption! Don't you feel silly now!", but really it says nothing, as we just have chosen a more efficient/simple tool for the job.
Sure, it hit the/. radar. I'll agree that it's novel as well. But I don't believe that it should be taken as a proof that the DeCSS matter is off-base.
Is anyone going to translate that into something readable? Why is it that when someone writes a perl script there always seems to be a challenge of making it use fewer characters, sacrificing readability? In the end, it doesn't matter if you only used XX number of characters if the code is the same, right?
Yes, I program in perl, so don't think I'm talking about "those other people". I know I have fallen victim to the same disease: no matter how small a script is, it would be cooler if it were smaller. I try not to go as far as removing whitespace, but even that urge is hard to resist. What I have to come to terms with is no matter how many characters I use, if the implementation is the same, in the end it doesn't matter enough to make changes. Perhaps reducing the _source_ lines of code can be different, but even that has its potential for obfuscation.
Ok, off the soapbox. Perhaps I'll parse through that later, when I have some spare time. This is just my commentary, take it or leave it, mod me down, whatever, but it had to be said.
Here's a good GPS info page, for those who aren't sure about things like selective availability, P/Y vs CA codes, the differnet bands, etc. Some people have mentioned some of this already, but this covers a decent amount without going to in depth. At the bottom it even mentions differential GPS, which is the concept behind the Wide Area Augmentation System (WAAS). Interesting stuff.
In 2001, there is none; nearly every PC bought new is connected to the internet at some point. But at the time at when these events occured, say 1995-1996, using the internet was not necessary a primary use of a home PC, and thus, the browser could have been unnecessary for many people. And *this* is the timeframe in which this trial is about, not what happened since that point.
All MS needs to say is that it saw a trend and a new market emerging. MS can just say "We were looking ahead. We saw the internet's increasing popularity on the horizon and prepared for it." You can't really punish a company for being ahead of its time, can you?
Recently Microsoft has been claiming that the Judge was biased during the trial, because afterwards he said a few choice words about the company. Their Lawyers are trying to use this to wriggle out of the judgement, however the simple fact is that once the judgement has been reached by due process in a court of law then the judge is allowed to be predjudiced - he has to sentence them, after all.
Well, he also said a few choice words _during_ the trial as well, from what I understand. Apparently he had an agreement that those words not be published until after the trial.
But it doesn't just boil down to that. There are arguments that Jackson's idea for a breakup really didn't have any backing behind it. And now there's talk that MS was really doing what the consumer wanted by putting the browser in the OS. Apparently the idea is that there is no market for a browserless OS, so MS wouldn't supply one.
Not quite. The law rightfully takes something else into consideration...
motive
Agreed. While the argument that you are not any more dead is true, this is not just about paying for the damage you do (although that is important as well). Prison time also takes into account your threat to society.
Even with the above considered, it is also important to note that many people claim that hate crimes are different because they affect an entire population. The logic behind that reasoning is that when a person kills another just because he/she is a certain race/ethnicity/religon/whatever, then all people of that type are affected. It affects the lives of people that weren't even involved in the crime because they have to live in fear. It's strange how the act of one person can affect so many in this way, but for things like this, that can be the case.
I'm not saying that I totally agree with the argument above or that it's valid reasoning for determination of punishment, but that's the way some people feel.
I'm in the DC area, in MD, and I pay 40 a month for basic cable, and then if I wanted to get cable modem access, it would be another 40 (50 if you're not subscribing to their cable service). That's a good chunk of change.
"Very well put Yoshi! TCO is something that's often overlooked by non-financial types, but it ends up right on the bottom line, IMHO"
Excuse me, but while I would assume that your low userid number means you've been reading slashdot for a while, your post indicates that you are clearly confused. All slashdot replies must be of the following form:
Always begin with a sarcastic remark about the person's stupidity or ignorance. When in doubt, pick a single sentence out of context and simply say something like "From this sentence, I can see that it's obvious you don't know what you're talking about." Doing so means that you are incredibly smart, and makes your post more correct. Other good choices are:
"You've obviously never heard of -x-."
"Anyone who has done -put simple thing here- knows that you're wrong on all counts."
"I don't know if you were dropped on your head as a child, but..."
"I'm thoroughly surprised that you are able to form complete sentences. Were you drooling on your keyboard while you typed that?"
Bonus points if you add that you are especially qualified in the subject, because you claim that you've been involved with it thoroughly for some time (greater than 5 mins is all that's necessary for condescending tone).
Always refer to the article and claim the person didn't do their research. This is always a favorite because it is similar to the oh-so-famous RTFM. Even better if you point out that slashdot doesn't do their homwork. Don't worry if people before you have already pointed that out, because sometimes people can miss 10 comments in a row.
Lastly, end with an encoded message or silly programming puzzle of some sort. Perl is always good. Most slashdot readers just hang out for the puzzles at the end of each comment.
Your post was entirely too friendly and, even worse, it agreed with someone. See that it doesn't happen again.
you're being stupid. the post that started this said something like "proving doesn't work, you need to test". your point is that proving doesn't work because people make mistakes. well, testers make mistakes too, nitwit, so you have no point.
I didn't say testing was perfect, that would be silly. But at this point, you're just being rude.
Let me try to put it in a way that cannot be misconstrued easily. Proving is fine and dandy for those who want to do it. But like anything in software development, it doesn't mean "bug-free", or even excellent code will result. That was my only point that I was trying to make by giving the Naur example. The idea behind the Naur program was very simple, yet it still had errors in it. Personally, I regard proving as less effective (costwise, maybe) than testing. Again, personally, I would appreciate the statement "The software has gone through rigorous testing" more than "The software has been proven to be correct". It's not an either-or situation, I realize, I'm just proving a point. That's my opinion, and everyone has their own, so if you don't like mine, then ignore it. Software methodologies discussions are full of opinions, and mine is just another one of them. Feel free to dismiss it.
If he had actually had a proof, there couldn't have been any bugs in the program relative to the specifications
"Relative to the specifications" doesn't mean too much in the end, because it assumes that the specifications are the end-all be-all to what goes in the software, and are by definition correct. Of course, we are human, and this is hardly the case. There are sometimes "gotchas" or special cases that come up that aren't in the specs. Someone thought they were being absolutely clear when they weren't, etc. Is that a valid bug when it surfaces in the code? Absolutely.
Then the responsibility is put on the specs, so one may say "well, make sure the specs are right." That's not as easy as it seems, since the English language alone has communication problems. Add on that someone has to read through it all and flush out everything that it says, ensuring that no other person could possibly find something misleading or incorrect in it. This has to be done to a certain extent, but eventually you're going to hit a wall where it doesn't pay to refine the specs any more. Of course, it still won't be perfect, and software that is proven to operate by it still won't necessarily be bug-free.
Don't get me wrong, proofs are fine as a first step, but people make mistakes. Specs can be misleading, cases can be missed, etc. You need to also test, plain and simple.
Not making mistakes is what makes software robust.
It sounds pretty simple doesn't it? Just be perfect, and your software will be robust. That's fine for the gods, now what about us mere mortals?
Proving software correct shouldn't hold much weight. Testing is really the only way to go.
For instance, here is a pdf that mentions Naur "proving" a very simple ALGOL program correct, but obviously not testing the code. The program was only 25 lines long and reformatted text (basically a word wrapper). Later on there were (at least) 5 bugs found in the code.
Which goes to show that testing is what makes software robust.
The main reason that microkernels have not gained more acceptance in OS circles (although Windows NT is based on microkernel design)
Hmm, well let me elaborate on that comment. IIRC, both user mode and kernel mode drivers can be done in NT. Before NT4, it was all user mode drivers. After that, it became optional, presumably for efficiency's sake. Oreilly has a good sample chapter page on the NT I/O subsystem:
http://www.oreilly.com/catalog/wininternals/chapte r/ch04.html
http://www.mcdonalds.com/legal/legal.html
Scroll down to the tradmark info, listed in alphabetical order. Smile isn't one of them, but "We love to see you smile" is.
I haven't seen the cup, but I hope you're not referring to their saying "We love to see you smile". Isn't that the correct trademark?m ile/index.html
http://www.mcdonalds.com/countries/usa/whatsnew/s
Dammit, that was a goatse.cx link. Fooled me, unfortunately.
Wel, now we all konw that the misspelings on slashdot are meerly a batle against sensership.
While I'm not going to argue you're first point (cards were expensive, for what they were), the second point is definitely from left field. I remember that the "tournament legal" decks had to ban/restrict some of the old cards just because they ended up ruining the game outright due to their power. Certain card combos could end up with a game being over before it even really started.
The number of "trouble cards" slowly decreased with each edition as Wotc got pretty smart about balance. Sure, they had their mistakes, but overall, they've made good, balanced cards. I've looked at the new cards these days, and they tend to have "penalties on the side" or strange side effects, or effects that generally aren't all that useful but could be interesting with other cards. In essence, it became more about building a good deck that getting the best cards. Today's Magic is a far cry from the old days of "I got a good draw, so you don't get your first turn...I will draw 3 more cards, then a new hand...now I have plenty of land, and a very powerful creature. You now have three turns to live, if you're lucky. I could have killed you already, but I decided to make it interesting."
One of my chemistry professors once claimed that everything boils down to chemistry. One of my physics professors said that in acuality, everything boils down to physics. I'll always remember those two statements, but the statement that I find rings truer than those is one by Galileo himself:
The book of nature is written in mathematical equations.
A rough quote from memory, so excuse me if it's not exactly correct. It seems that everything can be expressed in mathematical terms. In a sense, it is the mother of all sciences. Does this mean that all science is computer science? Possibly. Computers, at their core, are simply playing with numbers. Heck, there's a reason that it's called a computer. Saying that all science is computer science might also be giving too much credit to the computer itself, if you ask me. I believe a more honest statement would be "All science is mathematical in nature. Computers are mathematical devices. Therefore, assuming an appropriate computer, all science can be expressed in computational terms."
The idea that all IP is just "numbers" and can't be owned is a fallacy. Anything in the universe can be hashed to a numerical representation. My car has a number, and I most certainly can own it. To suggest otherwise is to advocate a communist system.
To quote Galileo (roughly):"The book of nature is written in mathematics."
but the fact is that the very first "real program" I wrote at my job was in C. Not C++, not Object C, damn sure not Java: straight C. And if I'd only been trained in Java at that point, I'd have been fucked.
All of your points mentioned, (pointers, main, GC) really don't have anything to do with OO programming. Ok, maybe the "main()" comment had something to do with it, but I couldn't really see how having a main outside of an object could cause someone much grief. Besides, OO programming does not necessarily demand that construct.
The points you mentioned are for lower-level languages and against higher-level ones. You could have easily said "Perl programmers have problems understanding freeing their data and pointers" instead of Java programmers having those problems, and the argument still fits.
That was pretty funny. But it's important to note that sometimes readability isn't a big issue. There are times when I want to quickly write something on the fly in 15 minutes to perform a task (analyzing the contents of a text file, say), and I'm not going to use the program later, or it's short enough to where it won't be too difficult to see what's going on. If I need to write a quick script for an easy-to-describe, but time-consuming-to-do-by-hand task, then I want a language that allows me a quick and dirty solution. Sometimes, the terser I can be, the better. Granted, my example is perl's forte, but even outside of that, this still can hold true.
More importantly, the the power is produced in centralized locations. This means if the power plants become 5% more efficient all of the EXISTING vehicles create less polution. Not to mention that as more power plants shift away from nasty sources of energy like coal, every electric cars on the road will become truely polution-free almost overnight.
It seems that everything is going client-server these days, eh?
Bad geek joke, I know. But this really is the power of an architecture manifesting in another area. Put too much into the client (the car), and it's harder to undo later.
For OO geeks, that means that there is now an abstraction layer between the car and the...ah, never mind... =)
But what you're doing isn't boycotting. A boycott is when you don't use a product for moral reasons. You are still using their product.
Well, maybe so, if his boycott target is music in general. Perhaps, instead, he is boycotting the distribution model. He has no moral problem with music in general (who does?), and that is the product that he is getting. What is being abstained from is the distribution model (or, potentially, the companies that use the model) that he gets reamed by financially.
Your Montgomery Bus Boycott analogy would work better if he had been stealing CDs from the store. However, if we take into account that he is against overpriced CDs as a form of music distribution, then the dilemma has been resolved. Well, maybe one could argue that mp3s come from CDs and that's a problem, but hey, close enough. The Montgomery Bus Boycotters effectively said "I'll use another form of transportation", and he is saying "I'll use another form of distribution".
Is he still a "thief"? Probably. But I think he's still making a statement.
Perhaps I didn't state my comment correctly. I do appreciate one-liners in a sense. After all, I _did_ admit that it was novel. When I see something implemented in one line, or two lines, or whatever small number of lines, I think to myself "Yea, that's kinda cool", but I know that it says little about the program's problem domain. In the end, it really says something about the language it was written in and the ability of the programmer to use that language to its fullest.
The reason that I said what I said is that the article on slashdot basically made it sound like the program made a statement about the technology behind CSS. To quote the article:
It's also a bit of an embarassment for Hollywood when you consider that the basis of a multi-billion dollar revenue-stream can be foiled by such a small piece of code!
Therefore my point is that this statement is out of line. How small a piece of code is has little to do with the algorithm behind it. While there is the debate about whether laws are enforceable or not, the size of the code is insignificant.
I agree with the original post that the size doesn't matter. The only thing that is proven by this program is that perl can be extremely terse and can do just about anything. I'm willing to bet that this algorithm could be expressed in a shorter way using a different language. To bring it to the point of absurdity, I could propose a new, hypothetical language, "DeCSS/C", where a standard library call called "d()" will decode a file. We could all stand back and say "Ha! One line of code to crack the encryption! Don't you feel silly now!", but really it says nothing, as we just have chosen a more efficient/simple tool for the job.
Sure, it hit the /. radar. I'll agree that it's novel as well. But I don't believe that it should be taken as a proof that the DeCSS matter is off-base.
Is anyone going to translate that into something readable? Why is it that when someone writes a perl script there always seems to be a challenge of making it use fewer characters, sacrificing readability? In the end, it doesn't matter if you only used XX number of characters if the code is the same, right?
Yes, I program in perl, so don't think I'm talking about "those other people". I know I have fallen victim to the same disease: no matter how small a script is, it would be cooler if it were smaller. I try not to go as far as removing whitespace, but even that urge is hard to resist. What I have to come to terms with is no matter how many characters I use, if the implementation is the same, in the end it doesn't matter enough to make changes. Perhaps reducing the _source_ lines of code can be different, but even that has its potential for obfuscation.
Ok, off the soapbox. Perhaps I'll parse through that later, when I have some spare time. This is just my commentary, take it or leave it, mod me down, whatever, but it had to be said.
s/\b(.*?)(.{1})\b/$2$1/g;
I expect that I will hear from Aimster's lawyers soon. Slashdot, watch out! You're housing illegal code!
Now if someone wants to sing this and record it to mp3, etc, feel free.
Here's a good GPS info page, for those who aren't sure about things like selective availability, P/Y vs CA codes, the differnet bands, etc. Some people have mentioned some of this already, but this covers a decent amount without going to in depth. At the bottom it even mentions differential GPS, which is the concept behind the Wide Area Augmentation System (WAAS). Interesting stuff.
http://www.colorado.edu/geography/gcraft/notes/gpIn 2001, there is none; nearly every PC bought new is connected to the internet at some point. But at the time at when these events occured, say 1995-1996, using the internet was not necessary a primary use of a home PC, and thus, the browser could have been unnecessary for many people. And *this* is the timeframe in which this trial is about, not what happened since that point.
All MS needs to say is that it saw a trend and a new market emerging. MS can just say "We were looking ahead. We saw the internet's increasing popularity on the horizon and prepared for it." You can't really punish a company for being ahead of its time, can you?
Recently Microsoft has been claiming that the Judge was biased during the trial, because afterwards he said a few choice words about the company. Their Lawyers are trying to use this to wriggle out of the judgement, however the simple fact is that once the judgement has been reached by due process in a court of law then the judge is allowed to be predjudiced - he has to sentence them, after all.
Well, he also said a few choice words _during_ the trial as well, from what I understand. Apparently he had an agreement that those words not be published until after the trial.
But it doesn't just boil down to that. There are arguments that Jackson's idea for a breakup really didn't have any backing behind it. And now there's talk that MS was really doing what the consumer wanted by putting the browser in the OS. Apparently the idea is that there is no market for a browserless OS, so MS wouldn't supply one.
The issue has a few more colors, apparently.
Not quite. The law rightfully takes something else into consideration... motive
Agreed. While the argument that you are not any more dead is true, this is not just about paying for the damage you do (although that is important as well). Prison time also takes into account your threat to society.
Even with the above considered, it is also important to note that many people claim that hate crimes are different because they affect an entire population. The logic behind that reasoning is that when a person kills another just because he/she is a certain race/ethnicity/religon/whatever, then all people of that type are affected. It affects the lives of people that weren't even involved in the crime because they have to live in fear. It's strange how the act of one person can affect so many in this way, but for things like this, that can be the case.
I'm not saying that I totally agree with the argument above or that it's valid reasoning for determination of punishment, but that's the way some people feel.
I'm in the DC area, in MD, and I pay 40 a month for basic cable, and then if I wanted to get cable modem access, it would be another 40 (50 if you're not subscribing to their cable service). That's a good chunk of change.
"Very well put Yoshi! TCO is something that's often overlooked by non-financial types, but it ends up right on the bottom line, IMHO"
Excuse me, but while I would assume that your low userid number means you've been reading slashdot for a while, your post indicates that you are clearly confused. All slashdot replies must be of the following form:
Always begin with a sarcastic remark about the person's stupidity or ignorance. When in doubt, pick a single sentence out of context and simply say something like "From this sentence, I can see that it's obvious you don't know what you're talking about." Doing so means that you are incredibly smart, and makes your post more correct. Other good choices are:
"You've obviously never heard of -x-."
"Anyone who has done -put simple thing here- knows that you're wrong on all counts."
"I don't know if you were dropped on your head as a child, but..."
"I'm thoroughly surprised that you are able to form complete sentences. Were you drooling on your keyboard while you typed that?"
Bonus points if you add that you are especially qualified in the subject, because you claim that you've been involved with it thoroughly for some time (greater than 5 mins is all that's necessary for condescending tone).
Always refer to the article and claim the person didn't do their research. This is always a favorite because it is similar to the oh-so-famous RTFM. Even better if you point out that slashdot doesn't do their homwork. Don't worry if people before you have already pointed that out, because sometimes people can miss 10 comments in a row.
Lastly, end with an encoded message or silly programming puzzle of some sort. Perl is always good. Most slashdot readers just hang out for the puzzles at the end of each comment.
Your post was entirely too friendly and, even worse, it agreed with someone. See that it doesn't happen again.
$a = "Ypv bsf xbtujoh ujnf xjui uijt tuvqje nfttbhf";$a =~ tr/b-y/a-z/;
print $a;