If you don't know how to take advantage of those guarantees, so that for you undefined-at-the-language-level is the same as undefined-at-the-application-level, that's your problem. I do, however, know how to take advantage of those guarantees, as do many other programmers.
I have had enough of your continued insinuations that I should somehow be unable to divine the true meaning of your words just because I don't agree with them.
I might as well note at this point that the way you keep obsessing over minor implementation details such as pointer and index errors just goes to show what a lousy programmer you are and how little systems programming experience you really have. If you can't even keep track of an index variable I fail to see how you could ever successfully deploy a large heterogenous system.
That aside, and apart for the fact that you've repeatedly chosen to ignore the points I made about the primacy of prevention over protection, I enjoyed discussing this with you. Lest I start repeating myself, and assuming there is nothing further to discuss which would necessitate a response on my part, I shall bow out at this point to leave the final word to you.
If the plugin acquires a resource and doesn't release it, at worst, that resource would be unavailable to the rest of the application; that doesn't make the state of the application "undefined".
Since it is impossible to know what may or may not have been relinquished and what conditions may or may not have been met, at the application (or perhaps system is a better word) level, the state of the system as a whole, that is, as a situated entity with a well-defined purpose, is undefined.
The important issue is not being able to recover from unexpected errors, but to prevent them from happening in the first place. The way to do that is to integrate as tightly as feasible and to shun excessive modularity. There is not much use in being able to recover from index errors if the system as a whole is no longer capable of displaying any results (e.g. because the video hardware was left in a partially initialized state). More safety is always desirable, but only in so far as it allows the application (system) to more gracefully return to a known state (i.e. reboot). The Java model does offer some advantages over the C model (or lack of model) in that respect, but just not that many.
In fact, a large part of OpenOffice is just implementing in user code what something like a Java runtime implements much more efficiently: COM-like objects.
Exactly. It's not the language or the runtime per se which are responsible for horrible software. It's a development philosophy that puts nebulous notions of safety (as opposed to reliability), flexibility and extensibility ahead of the primary system task. But some languages accomodate this philosophy better than others.
When the code reaches "after", I can know with certainty that the privilege has been relinquished, no matter what happened in the plug-in.
That's a spurious example. If a resource is acquired inside the plugin and never relinquished because of an unexpected error, the state of the application is undefined. Since it is impossible to know in advance what resources a plugin might acquire, the only safe assumption to make is that the application is in an undefined state whenever an unexpected error occurs.
Note that you cannot dismiss this scenario by saying that the plugin writer should take care to always relinquish resources, since you've been arguing that safe languages protect against exactly those kind of lapses.
Again, the kind of faults that safe languages help to prevent do nothing to correct the much more insidious and catastrophic failures at the application level.
Software is slow because it is written in unsafe languages: unsafe languages require clumsy and inefficient fault isolation mechanisms (processes, IPC), and they greatly interfere with the ability of programmers to optimize and design for performance.
I have no experience with applications on the scale for which that is true. But I know that OpenOffice is a slow bug-riddled pig.
In contrast, most other programming languages leave programs in well-defined states after the occurrence of errors detected by the runtime.
Which is largely irrelevant in determining the state of the application as a whole. Were all transactions properly closed? Were all privileges relinquished? Generally when you encounter an unexpected error the only sensible thing to do is to terminate the application. Regardless of language.
more and more programs use plug-ins, components, and COM-like constructions.
I see your point, but the language level is the wrong place to solve these problems. We're much better off addressing them at the kernel level through orthogonal persistance and a more powerful process abstraction. Some hardware assistance wouldn't hurt either. Software is slow enough as it is.
And C never has had good answers to that problem--you just get the wrong results.
Broken code yields broken results. Regardless of language. When a particular programming practice makes it hard to rule out errors, the answer is not to design a fault-tolerant language; the answer is to avoid the practice. Ironically that can be construed to support your position as well as mine;)
Let's say I write an on-line banking application that loads a third-party communications module. In a reasonable programming language, if I invoke the third-party communications module and it crashes with some unexpected error, I can just tell the user that there is a problem with that module and the user can go on using the rest of the application.
You cannot be serious. The module might have acquired critical locks, hardware may be left in an inconsistent state, stray threads may be left running, external programs might be left dangling... Anything could be corrupted.
In C, if there is an error in a dynamically loaded module, anything could be corrupted.
Well, yes. Which is why you should make sure that you the modules you use work as intended when you build a system to perform a task. That goes for any language.
At least in C the dynamically loaded modules don't explode with NoSuchMethodExceptions and InvocationTargetExceptions.
In contrast, when you get a segmentation fault in C, all bets are off: there is no safe way to handle a segmentation fault or other C runtime error because the entire program state is undefined.
There is no safe way to handle a segmentation fault because your program should not throw segmentation faults in the first place. There is nothing a Java program can do when it catches an OutOfMemoryException either.
In any case, C programmers generally achieve fault isolation by separating their program into multiple processes. I think that works a whole lot better than: while(godWilling) {
try {
prayThisWorks();
} catch(Error e) {
System.out.println("Something bad happened, sorry");
} }
When I get an exception in, say, Java, the program is still in a state that is completely well-defined. That means that well-designed programs can recover safely even from unexpected errors.
The notion that you can recover from errors that you didn't anticipate is flawed. When your application cannot complete the user's request because of some unexpected error the game is already over.
Logging the error and moving on is not "recovering". It's limping along.
When your application encounters an unexpected error then your application needs to be fixed. This is true regardless of the programming language!
Concretely, you can have a pointer error, it messes up some data structure, and nothing may ever signal that error--it will just corrupt your bank account or do something else bad.
That's just FUD. The memory could develop bit errors. The DMA transfer might not complete cleanly. The CPU might be hit by a high-enery particle.
I don't dispute that a pointer error cannot have catastrophic consequences. But contrary to your claim, programs generally do crash when a datastructure is trampled. This tends to weeds out those kinds of bugs very fast. But it is always possible to use checksums to verify the integrity of your datastructures. And powerful tools exist to catch indexing errors and pointer errors.
You are conjuring an image of evil hidden pointer bugs, lurking in the shadows for an opportunity to destroy your bankaccount. That's just hysterical.
C error handling is not like error handling in other high-level languages: C guarantees much less, and the consequences of that are dire for the quality and security of C programs.
The reality is that the most disastrous errors generally do not occur at the hardware, OS or language levels, but at the application level.
We are talking about the fact that it takes years to get a new major release of the Linux kernel, Gnome, or KDE out, and they still keep crashing. We are talking about almost daily security holes in Windows and Linux network servers.
More hyperbole. Software reliability has increased by leaps and bounds over the past two decades, even as complexity has ballooned.
The most exploited security holes aren't buffer overflows or pointer errors; they're in scripting implementations (VB) and poorly written website apps (Perl/PHP/ASP/...).
in C, there are potentially relationships between everything anywhere in the code because of pointer manipulation and lack of safety.
Uh. OK. But since at the hardware level this is generally true no matter what language is being used I think this argument is rather specious.
The absence of buffer overflows, stale pointers, and index errors in Perl and Python alone dwarfs any problems Perl may have relative to C.
OutOfMemoryExceptions, ArrayIndexOutOfBoundsExceptions and NoSuchMethodExceptions break applications just like segmentation faults do. You might argue that the first type of breakage is "better" on the general principle that it yields more predictable behavior, but for the user whose application stops working that's a largely academic distinction.
Perl, Python, and other scripting languages have plenty of problems, but they are still enormously better than C in terms of reliability.
The only way to ensure safety and reliability is to have a consistent type system and consistent error checking built into the language. Perl's error checking is not all that great, but C is much worse.
Safety is only marginally served by stuffing ever more implicit safety measures into your language. It's largely a matter of keeping your eyes on the road.
From a pragmatic perspective there is no difference between "Safety exception! Program shut down!" or "Type error! No such method!" and the good old "Core dump".
Probably because the professors that teach those students know something you don't.
Ignorance is bliss.
Both C and Perl are "mashed potatoes" when it comes to building reliable systems.
When you are beholden to some measure of reliability that most people will never need or even want, maybe.
Second, these programs cannot help you with the fundamental problem that you have written more code and on average the number of bugs is proportional to the amount of code.
Bugs are not a fixed property of code. Code that was bugfree when it was written may develop bugs over time as a result of subtle changes in requirements or operating environment. The chances of this happening are proportional to the flexibility of the operating environment, i.e. much greater in a scripting environment.
A larger body of code that is better controlled and understood may lead to fewer overall bugs than a smaller body of code whose behavior is less well controlled and understood.
Slashdot is widely acknowledged to be written in piss-poor Perl and is no more fragile than sites written in Java and is probably more reliable than those few sites written in C.
A website is a highly dynamic application which demands a great amount of flexibility. What's more, errors are usually not fatal, both in the sense that they don't lead to data loss, but also in the sense that websites do not generally store important data in the first place (and why is that?). Finally the website runtime environment is tightly controlled and rarely subject to change (it comes as no surprise that Slashdot still runs Apache 1.3.26). Scripting is ideally suited to these kinds of tasks.
The secret to reliable software is testing, testing and testing.
The real secret is to minimize the number of things that need testing, which is not something you can do by minimizing lines of code. The relationships, dependencies and exceptions expressed in a single line of Python code may require far more testing than 2 pages of portable C code.
The benefits of scripting over languages such as C are grossly overrated.
C requires painstaking attention to detail, but there is a large number of tools to check C programs for common mistakes such as memory allocation errors and pointer bugs. Scripting languages generally do not have an equally powerful toolset to check for runtime problems such as the typing and dependency errors which may occur when (components of) the scripting runtime are upgraded.
Scripts are fragile. Truly the last thing operating systems need is more fragility.
By adhering strictly to a formalized development process which includes unit tests as well as rigorous system tests it is possible to overcome some of this fragility, but then you also lose many of the benefits that scripting is supposed to provide, viz. rapid development and turnaround.
God only knows why colleges keep churning out students who insist that mashed potatoes are the most flexible material to build a bookshelf...
That statement posits a kind of equality between Hitler and the RIAA which is more fundamental than their many differences. That is madness.
The original poster argues that morality and legality are not one and the same thing. I agree -- but that elementary truth is irrelevant to the matter at hand without an answer to the question: what moral cause is being served by the music swappers?
I've said it before, I'll say it again: if you are confused about the moral difference between music swapping and the Holocaust, you need to have your head examined. What just cause is being pursued by the music swappers?
"We have the capability of injecting wonder, joy and levels of customization into a portable device so it becomes more like a companion or a friend to a lifestyle that uses digital technology."
-- Masanobu Yoshida, president of Sony Corporation's Handheld Computing Company
Look, power invites abuse. The RIAA is abusing it's power to break privacy. The music swappers are abusing their power to break copyright. There will always be a RIAA. There will always be music swappers.
If you don't want to risk the fine and are not willing to move to another country, then don't break copyright. I'll risk the fine because and when it is convenient. But I won't risk the fine out of some delusion that I'm entitled to free music.
I don't believe that the RIAA is fair, not to customers, not even to artists, although I would guess that they pay your salary in some way.
The RIAA has a lot of power and with that power comes a lot of abuse. Some of their initiatives, such as collecting fines through the sales of blank CDs, are deeply objectionable. Which is why it is good to see they have finally adopted the only fair strategy, i.e. to go after those who violate copyright.
Current copyright law is most certainly not fair.
As far as I can tell, copyright law gives copyright holders the right to determine the conditions under which their works may be distributed. I believe this right belongs quite naturally to the copyright holders. Who else should it belong to? The music swappers?
Frankly, I don't believe in copyrights at all for non-commercial uses. You can't own patterns of zeros and ones. You can't own raw information per se. (It wants to be free:))
I would argue that there is no such things as raw information. Just because you can view an MP3 as a pattern of ones and zeroes doesn't mean that that's all it is. I could view you as a bag of water. That doesn't mean I can treat you like one.
It's not even like I disagree with you in principle. I'd like to just copy music (and in fact I do, even if not in bulk). But in practice, I think your stance will only lead to more draconian measures such as strong, mandatory user identification and mandatory, tamperresistant hardware & software.
At that time I imagine you will look back and say, "We didn't have it so bad back then".
Yes, a large group of people can organize themselves to impose their will on a smaller group of people. That is called mob rule, and it is neither fair nor efficient.
If the people want to download music without regard for copyright law, who is going to pay the artists?
You raise some good points, but I feel that by and large the infrastructure that would be required to address your points (ranging from the ability to unambiguously identify Internet users to mandatory tamperresistant OS & software) is much more invasive and gives much larger potential for abuse than the current situation, even if the current situation is also flawed.
I'm wondering why such a fuss is being made about this. If you illegally distribute copyrighted material you are liable for damages. The damages are real. They aren't as big as the RIAA makes them out to be, but they are real nevertheless. Privacy and grandiose interpretations of the First Amendment have nothing to do with it. Nobody is entitled to do stuff that is not legal.
All the people who think the RIAA is trying to protect an outdated business model and should just fall over and die need to take a good look at their own morals. Just because their business model is outdated (is it?) doesn't mean you can take the law into your own hands. What's more, the model isn't outdated at all. The musical horizons of most of you would not extend beyond playing the banjo if it wasn't for the RIAA.
The people who think technology will solve this problem need to think again. There will always be ways to illegally exchange copyrighted materials. But there won't be some kind of Uber-P2P app that destroys the RIAA in one fell swoop, with kissing and credits. Reliable, Cheap, Mass-appeal: pick one-and-a-half.
Some people seem to think it's more of a social dynamic. The cat's out of the bag, can't put the genie back into the bottle, so much for Pandora's box. They think nothing of sharing music. It's just a natural thing to do, and since so many people are doing it, everybody else will just have to adapt. It's the mob mentality: democracy at its very worst. These people talk about freedom and individuality, but they seek cover behind the anonymity provided by the mob. Even if that anonymity is just an illusion, like it is on the Internet.
What the RIAA is doing now is exactly what they should be doing. They are not demonizing any particular technology. They are not pushing for overly broad and vague laws. They are simply tracking copyright violations. If you don't like that idea, then stop violating copyright. It's really simple.
Personally, I couldn't care less. Sometimes I'll grab a few tunes off Gnutella or Usenet, or post a few albums. But I've stopped telling myself that file sharing will dramatically change the way the music industry works. If anything, it is the other way around: the music industry will do more to change the computing industry than vice versa.
Besides, I like to go outside and browse in the record store. It's not so bad.
AMD had a great product with the Athlon a few years ago, but they never managed to shake off the low-cost hobbyist image and never really competed with Intel for the markets where Intel has traditionally been the strongest, i.e. business & industry.
AMDs 64 bit offering is an attempt to finally challenge Intel's dominance in those markets, but its very late, and apart from (again) the hobbyists and perhaps a few scientists who are low on funds, nobody is planning to support it (Microsoft? Yeah, right. Look what happened to Microsoft's support for PPC and Alpha).
You should see it the other way around. Intel has been stomping the entire CPU industry for the past quarter century.
If Symantec is anything like any of the companies I've worked for, they are way too busy just attending the regular day-to-day business to invent and distribute new viruses. It's absurd to think that they could be this efficient, releasing new viruses into the wild every couple of months that work this well.
Much easier, and probably just as effective, to just throw around some inflated numbers, like claiming billions upon billions in damages and what not.
Slashdot Mirror
If you don't know how to take advantage of those guarantees, so that for you undefined-at-the-language-level is the same as undefined-at-the-application-level, that's your problem. I do, however, know how to take advantage of those guarantees, as do many other programmers.
I have had enough of your continued insinuations that I should somehow be unable to divine the true meaning of your words just because I don't agree with them.
I might as well note at this point that the way you keep obsessing over minor implementation details such as pointer and index errors just goes to show what a lousy programmer you are and how little systems programming experience you really have. If you can't even keep track of an index variable I fail to see how you could ever successfully deploy a large heterogenous system.
That aside, and apart for the fact that you've repeatedly chosen to ignore the points I made about the primacy of prevention over protection, I enjoyed discussing this with you. Lest I start repeating myself, and assuming there is nothing further to discuss which would necessitate a response on my part, I shall bow out at this point to leave the final word to you.
If the plugin acquires a resource and doesn't release it, at worst, that resource would be unavailable to the rest of the application; that doesn't make the state of the application "undefined".
Since it is impossible to know what may or may not have been relinquished and what conditions may or may not have been met, at the application (or perhaps system is a better word) level, the state of the system as a whole, that is, as a situated entity with a well-defined purpose, is undefined.
The important issue is not being able to recover from unexpected errors, but to prevent them from happening in the first place. The way to do that is to integrate as tightly as feasible and to shun excessive modularity. There is not much use in being able to recover from index errors if the system as a whole is no longer capable of displaying any results (e.g. because the video hardware was left in a partially initialized state). More safety is always desirable, but only in so far as it allows the application (system) to more gracefully return to a known state (i.e. reboot). The Java model does offer some advantages over the C model (or lack of model) in that respect, but just not that many.
In fact, a large part of OpenOffice is just implementing in user code what something like a Java runtime implements much more efficiently: COM-like objects.
Exactly. It's not the language or the runtime per se which are responsible for horrible software. It's a development philosophy that puts nebulous notions of safety (as opposed to reliability), flexibility and extensibility ahead of the primary system task. But some languages accomodate this philosophy better than others.
When the code reaches "after", I can know with certainty that the privilege has been relinquished, no matter what happened in the plug-in.
That's a spurious example. If a resource is acquired inside the plugin and never relinquished because of an unexpected error, the state of the application is undefined. Since it is impossible to know in advance what resources a plugin might acquire, the only safe assumption to make is that the application is in an undefined state whenever an unexpected error occurs.
Note that you cannot dismiss this scenario by saying that the plugin writer should take care to always relinquish resources, since you've been arguing that safe languages protect against exactly those kind of lapses.
Again, the kind of faults that safe languages help to prevent do nothing to correct the much more insidious and catastrophic failures at the application level.
Software is slow because it is written in unsafe languages: unsafe languages require clumsy and inefficient fault isolation mechanisms (processes, IPC), and they greatly interfere with the ability of programmers to optimize and design for performance.
I have no experience with applications on the scale for which that is true. But I know that OpenOffice is a slow bug-riddled pig.
In contrast, most other programming languages leave programs in well-defined states after the occurrence of errors detected by the runtime.
;)
Which is largely irrelevant in determining the state of the application as a whole. Were all transactions properly closed? Were all privileges relinquished? Generally when you encounter an unexpected error the only sensible thing to do is to terminate the application. Regardless of language.
more and more programs use plug-ins, components, and COM-like constructions.
I see your point, but the language level is the wrong place to solve these problems. We're much better off addressing them at the kernel level through orthogonal persistance and a more powerful process abstraction. Some hardware assistance wouldn't hurt either. Software is slow enough as it is.
And C never has had good answers to that problem--you just get the wrong results.
Broken code yields broken results. Regardless of language. When a particular programming practice makes it hard to rule out errors, the answer is not to design a fault-tolerant language; the answer is to avoid the practice. Ironically that can be construed to support your position as well as mine
Let's say I write an on-line banking application that loads a third-party communications module. In a reasonable programming language, if I invoke the third-party communications module and it crashes with some unexpected error, I can just tell the user that there is a problem with that module and the user can go on using the rest of the application.
You cannot be serious. The module might have acquired critical locks, hardware may be left in an inconsistent state, stray threads may be left running, external programs might be left dangling... Anything could be corrupted.
In C, if there is an error in a dynamically loaded module, anything could be corrupted.
Well, yes. Which is why you should make sure that you the modules you use work as intended when you build a system to perform a task. That goes for any language.
At least in C the dynamically loaded modules don't explode with NoSuchMethodExceptions and InvocationTargetExceptions.
In contrast, when you get a segmentation fault in C, all bets are off: there is no safe way to handle a segmentation fault or other C runtime error because the entire program state is undefined.
There is no safe way to handle a segmentation fault because your program should not throw segmentation faults in the first place. There is nothing a Java program can do when it catches an OutOfMemoryException either.
In any case, C programmers generally achieve fault isolation by separating their program into multiple processes. I think that works a whole lot better than:
while(godWilling) {
try {
prayThisWorks();
} catch(Error e) {
System.out.println("Something bad happened, sorry");
}
}
When I get an exception in, say, Java, the program is still in a state that is completely well-defined. That means that well-designed programs can recover safely even from unexpected errors.
The notion that you can recover from errors that you didn't anticipate is flawed. When your application cannot complete the user's request because of some unexpected error the game is already over.
Logging the error and moving on is not "recovering". It's limping along.
When your application encounters an unexpected error then your application needs to be fixed. This is true regardless of the programming language!
Concretely, you can have a pointer error, it messes up some data structure, and nothing may ever signal that error--it will just corrupt your bank account or do something else bad.
That's just FUD. The memory could develop bit errors. The DMA transfer might not complete cleanly. The CPU might be hit by a high-enery particle.
I don't dispute that a pointer error cannot have catastrophic consequences. But contrary to your claim, programs generally do crash when a datastructure is trampled. This tends to weeds out those kinds of bugs very fast. But it is always possible to use checksums to verify the integrity of your datastructures. And powerful tools exist to catch indexing errors and pointer errors.
You are conjuring an image of evil hidden pointer bugs, lurking in the shadows for an opportunity to destroy your bankaccount. That's just hysterical.
C error handling is not like error handling in other high-level languages: C guarantees much less, and the consequences of that are dire for the quality and security of C programs.
The reality is that the most disastrous errors generally do not occur at the hardware, OS or language levels, but at the application level.
We are talking about the fact that it takes years to get a new major release of the Linux kernel, Gnome, or KDE out, and they still keep crashing. We are talking about almost daily security holes in Windows and Linux network servers.
More hyperbole. Software reliability has increased by leaps and bounds over the past two decades, even as complexity has ballooned.
The most exploited security holes aren't buffer overflows or pointer errors; they're in scripting implementations (VB) and poorly written website apps (Perl/PHP/ASP/...).
in C, there are potentially relationships between everything anywhere in the code because of pointer manipulation and lack of safety.
Uh. OK. But since at the hardware level this is generally true no matter what language is being used I think this argument is rather specious.
The absence of buffer overflows, stale pointers, and index errors in Perl and Python alone dwarfs any problems Perl may have relative to C.
OutOfMemoryExceptions, ArrayIndexOutOfBoundsExceptions and NoSuchMethodExceptions break applications just like segmentation faults do. You might argue that the first type of breakage is "better" on the general principle that it yields more predictable behavior, but for the user whose application stops working that's a largely academic distinction.
Perl, Python, and other scripting languages have plenty of problems, but they are still enormously better than C in terms of reliability.
Safer, yes. More reliable, sometimes.
The only way to ensure safety and reliability is to have a consistent type system and consistent error checking built into the language. Perl's error checking is not all that great, but C is much worse.
Safety is only marginally served by stuffing ever more implicit safety measures into your language. It's largely a matter of keeping your eyes on the road.
From a pragmatic perspective there is no difference between "Safety exception! Program shut down!" or "Type error! No such method!" and the good old "Core dump".
Probably because the professors that teach those students know something you don't.
Ignorance is bliss.
Both C and Perl are "mashed potatoes" when it comes to building reliable systems.
When you are beholden to some measure of reliability that most people will never need or even want, maybe.
Second, these programs cannot help you with the fundamental problem that you have written more code and on average the number of bugs is proportional to the amount of code.
Bugs are not a fixed property of code. Code that was bugfree when it was written may develop bugs over time as a result of subtle changes in requirements or operating environment. The chances of this happening are proportional to the flexibility of the operating environment, i.e. much greater in a scripting environment.
A larger body of code that is better controlled and understood may lead to fewer overall bugs than a smaller body of code whose behavior is less well controlled and understood.
Slashdot is widely acknowledged to be written in piss-poor Perl and is no more fragile than sites written in Java and is probably more reliable than those few sites written in C.
A website is a highly dynamic application which demands a great amount of flexibility. What's more, errors are usually not fatal, both in the sense that they don't lead to data loss, but also in the sense that websites do not generally store important data in the first place (and why is that?). Finally the website runtime environment is tightly controlled and rarely subject to change (it comes as no surprise that Slashdot still runs Apache 1.3.26). Scripting is ideally suited to these kinds of tasks.
The secret to reliable software is testing, testing and testing.
The real secret is to minimize the number of things that need testing, which is not something you can do by minimizing lines of code. The relationships, dependencies and exceptions expressed in a single line of Python code may require far more testing than 2 pages of portable C code.
The benefits of scripting over languages such as C are grossly overrated.
C requires painstaking attention to detail, but there is a large number of tools to check C programs for common mistakes such as memory allocation errors and pointer bugs. Scripting languages generally do not have an equally powerful toolset to check for runtime problems such as the typing and dependency errors which may occur when (components of) the scripting runtime are upgraded.
Scripts are fragile. Truly the last thing operating systems need is more fragility.
By adhering strictly to a formalized development process which includes unit tests as well as rigorous system tests it is possible to overcome some of this fragility, but then you also lose many of the benefits that scripting is supposed to provide, viz. rapid development and turnaround.
God only knows why colleges keep churning out students who insist that mashed potatoes are the most flexible material to build a bookshelf...
He said:
the RIAA and Hitler are both tyrants
That statement posits a kind of equality between Hitler and the RIAA which is more fundamental than their many differences. That is madness.
The original poster argues that morality and legality are not one and the same thing. I agree -- but that elementary truth is irrelevant to the matter at hand without an answer to the question: what moral cause is being served by the music swappers?
No, I didn't miss the point. You are equating the Hitler with the RIAA. It's madness.
I've said it before, I'll say it again: if you are confused about the moral difference between music swapping and the Holocaust, you need to have your head examined. What just cause is being pursued by the music swappers?
I'd rather bring a book.
"We have the capability of injecting wonder, joy and levels of customization into a portable device so it becomes more like a companion or a friend to a lifestyle that uses digital technology."
-- Masanobu Yoshida, president of Sony Corporation's Handheld Computing Company
Look, power invites abuse. The RIAA is abusing it's power to break privacy. The music swappers are abusing their power to break copyright. There will always be a RIAA. There will always be music swappers.
If you don't want to risk the fine and are not willing to move to another country, then don't break copyright. I'll risk the fine because and when it is convenient. But I won't risk the fine out of some delusion that I'm entitled to free music.
I don't believe that the RIAA is fair, not to customers, not even to artists, although I would guess that they pay your salary in some way.
:))
The RIAA has a lot of power and with that power comes a lot of abuse. Some of their initiatives, such as collecting fines through the sales of blank CDs, are deeply objectionable. Which is why it is good to see they have finally adopted the only fair strategy, i.e. to go after those who violate copyright.
Current copyright law is most certainly not fair.
As far as I can tell, copyright law gives copyright holders the right to determine the conditions under which their works may be distributed. I believe this right belongs quite naturally to the copyright holders. Who else should it belong to? The music swappers?
Frankly, I don't believe in copyrights at all for non-commercial uses. You can't own patterns of zeros and ones. You can't own raw information per se. (It wants to be free
I would argue that there is no such things as raw information. Just because you can view an MP3 as a pattern of ones and zeroes doesn't mean that that's all it is. I could view you as a bag of water. That doesn't mean I can treat you like one.
It's not even like I disagree with you in principle. I'd like to just copy music (and in fact I do, even if not in bulk). But in practice, I think your stance will only lead to more draconian measures such as strong, mandatory user identification and mandatory, tamperresistant hardware & software.
At that time I imagine you will look back and say, "We didn't have it so bad back then".
A good point. If you are willing to equate slavery with music downloading, that is.
If you loose the ability to make simple moral distinctions, then yeah, the law has nothing to tell you.
Yes, a large group of people can organize themselves to impose their will on a smaller group of people. That is called mob rule, and it is neither fair nor efficient.
If the people want to download music without regard for copyright law, who is going to pay the artists?
You raise some good points, but I feel that by and large the infrastructure that would be required to address your points (ranging from the ability to unambiguously identify Internet users to mandatory tamperresistant OS & software) is much more invasive and gives much larger potential for abuse than the current situation, even if the current situation is also flawed.
Like my dad says..."The people have spoken, they want to download music."
The people don't want parking tickets either.
I'm wondering why such a fuss is being made about this. If you illegally distribute copyrighted material you are liable for damages. The damages are real. They aren't as big as the RIAA makes them out to be, but they are real nevertheless. Privacy and grandiose interpretations of the First Amendment have nothing to do with it. Nobody is entitled to do stuff that is not legal.
All the people who think the RIAA is trying to protect an outdated business model and should just fall over and die need to take a good look at their own morals. Just because their business model is outdated (is it?) doesn't mean you can take the law into your own hands. What's more, the model isn't outdated at all. The musical horizons of most of you would not extend beyond playing the banjo if it wasn't for the RIAA.
The people who think technology will solve this problem need to think again. There will always be ways to illegally exchange copyrighted materials. But there won't be some kind of Uber-P2P app that destroys the RIAA in one fell swoop, with kissing and credits. Reliable, Cheap, Mass-appeal: pick one-and-a-half.
Some people seem to think it's more of a social dynamic. The cat's out of the bag, can't put the genie back into the bottle, so much for Pandora's box. They think nothing of sharing music. It's just a natural thing to do, and since so many people are doing it, everybody else will just have to adapt. It's the mob mentality: democracy at its very worst. These people talk about freedom and individuality, but they seek cover behind the anonymity provided by the mob. Even if that anonymity is just an illusion, like it is on the Internet.
What the RIAA is doing now is exactly what they should be doing. They are not demonizing any particular technology. They are not pushing for overly broad and vague laws. They are simply tracking copyright violations. If you don't like that idea, then stop violating copyright. It's really simple.
Personally, I couldn't care less. Sometimes I'll grab a few tunes off Gnutella or Usenet, or post a few albums. But I've stopped telling myself that file sharing will dramatically change the way the music industry works. If anything, it is the other way around: the music industry will do more to change the computing industry than vice versa.
Besides, I like to go outside and browse in the record store. It's not so bad.
AMD had a great product with the Athlon a few years ago, but they never managed to shake off the low-cost hobbyist image and never really competed with Intel for the markets where Intel has traditionally been the strongest, i.e. business & industry.
AMDs 64 bit offering is an attempt to finally challenge Intel's dominance in those markets, but its very late, and apart from (again) the hobbyists and perhaps a few scientists who are low on funds, nobody is planning to support it (Microsoft? Yeah, right. Look what happened to Microsoft's support for PPC and Alpha).
You should see it the other way around. Intel has been stomping the entire CPU industry for the past quarter century.
If Symantec is anything like any of the companies I've worked for, they are way too busy just attending the regular day-to-day business to invent and distribute new viruses. It's absurd to think that they could be this efficient, releasing new viruses into the wild every couple of months that work this well. Much easier, and probably just as effective, to just throw around some inflated numbers, like claiming billions upon billions in damages and what not.