I buy a DVD with the expectation that I will be able to enjoy the contents on that DVD. I have equipment which is sufficient to allow me to do so (to wit: A computer equipped with a DVD-ROM drive), and so this would seem to be a reasonable expectation. I bring it home, pop it in, and find out that, for no better reason than I choose to use Linux (instead of Windows), I am unable to play the contents of this media.
Obviously, your expectation was false. You should have some research before buying the media. If a business can't expect its business model to be honored, then why should a customer expect his expectations to be honored? That, IMHO, is the other side of the coin.
Under the DMCA, it is very possible for me to find myself out the money for a DVD which I might actually enjoy. Somebody has stolen some time from me, and I have no recourse. Now, before you tell me to use Windows, keep in mind that I must buy Windows, somehow, some way. Which means that I am out even more time. Or a stand-alone DVD player, which has the same issue.
You bought a DVD on the assumption that it would play on your system. Nobody forced you to buy that DVD. Your assumption turned out to be false. I don't see how anybody has stolen anything from you.
The DMCA steals from me the ability to help others make use of the items which they have rightfully purchased with their time.
The key word here is "rightfully". You cannot play DVDs "rightfully" without the appropriate licenses. Its like complaining that somebody stole from you because you can't go into a movie theater without a ticket. After all, you spent some time going to the theatre. And the ticket is not a strict requirement for watching the movie: a pair of eyeballs and buttocks will do, and you have those.
So from your point of view, there is no reason why you shouldn't be able to watch the movie. But the bouncer disagrees. Do you call him a thief?
And another stupid idea dies a well deserved death. You would think someday companies would learn not to sell things for less than it cost to make them. We are talking econ 101 here people.
The more often I hear this argument, the shallower it sounds.
All business is based on some assumption of law. For example, you can't just beat up your competitors. Is it moral that the law protects the weak from the strong? I think so, but there is a case to be made for the opposite.
In this case, we're the strong, and it's the artists, writers, programmers who are the weak. The DMCA is an effort to protect them. Is it therefore a shaky, ambiguous, and morally reprehensible law? Or just inconvenient to us?
I can't say I have personal experience, but I've heard from people who are supposed to know that flying a helicopter is much more difficult than flying a plane. A helicopter has a much greater degree of freedom, and much less tolerance for error. It's not that long ago that simply keeping one of these things steady in the air was considered a major feat. Seriously.
This is like a proposal to take down all those ugly, messy websites, and recode them to comply with the most strict interpretations of the very latest W3C standards, and everybody will live happily ever after.
It's nonsense. Because the messiness and ugliness follows directly from the ease with which people can (try to) fill a niche. Take away the messiness and ugliness, and you take away half to three-quarters of the software. And with that all the vibrancy.
To get back to the World Wide Web analogy: if HTML had been more formal, there would be fewer junk. But there also wouldn't have been a Web as we know it. The Web as well as Linux have been successful because they are extremely open and free. Not because they provide "one way of doing things".
And if we don't do it, Bill, IBM, or Novell WILL.
So what? We're not in the same race as them. "We" don't have the same goals.
In any case, my observations were mostly about what it would take to get people to start using Linux on the desktop. *shrug* Hey, if it's what people want, why not give it to 'em?
Because giving it to them takes time and effort. Besides, why give them something they already have?
It's like all the comments on this thread have been generated from the same database by the same computer program. Ridiculous generalizations formulated in a stiffly "realist" corporate lingo. Noble self-proclaimed champions of mothers world-wide. Except that not a single mom is endeared by their flat and lifeless pseudo-ideas.
If Linux ever becomes a success, it won't be because anybody follows your dreary advice. It will be because somebody creates an excellent implementation of a great idea.
It's like all the comments on this thread have been generated from the same database by the same computer program. Ridiculous generalizations formulated in a stiffly "realist" corporate lingo. Noble self-proclaimed champions of mothers world-wide. Except that not a single mom is endeared by their flat and lifeless pseudo-ideas.
If Linux ever becomes a success, it won't be because anybody follows your dreary advice. It will be because somebody creates an excellent implementation of a great idea.
I love X... but I have to admit that you've hit the nail on the head. It's astonishing how bad cut and paste works between applications. It really only works for text, and then only if the text is flat ASCII. Because it's so bad, many applications have their own, internal version of the clipboard, and you're never really sure whether you're manipulating X's clipboard or the internal clipboard, or what information makes it onto X's clipboard and in what form. It's a total disaster.
Cut and paste on X is so bad, that I use it so little, that my expectations have sunk so low, that I've basically forgotten how it is to have a clipboard system that does work. Thanks for the reminder.
But spare us the cynicism. What exactly is the problem? A bunch of guys on Slashdot love their new Macs and you have a problem. I say: get over it. We're nerds.
Cynicism? No. Experience.
I'm glad people love their Macs. It's just that they seem to forget they're not the first people to use them. It's the holier-than-thou "you'll never understand it" attitude. I understand perfectly well. And eventually I got over it.
And BTW: we're talking about the new Napster vs. other services like iTunes. That is NOT something you've 'been doing all along' because these services are NEW.
Selling music on the Internet. Big whoop. If it was a patent it would be in the "my dog could have thought of that" category.
No seriously. It's probably very well done. But I haven't seen it yet. And I don't feel any less for not having seen it. That's my whole point. This isn't the second coming. Not interested. Keep it to yourself. Thanks.
Look, I can appreciate how thrilling it must be to all the nouveau-Appleians to finally have a computer that does what you want, but by now I've gotten fairly fed up with the non-stop gushing on Slashdot. It's gotten to the point that I'm waiting for the headline "Steve Jobs Takes Shit, Finds Gold Nugget".
To some of us, none of this stuff is new, you see. We've always chosen our computers based on our needs and interests of the moment, rather than going by some company or market diktat, and as a result our computers have always done pretty much what we want, seamlessly and flawlessly. Back in the day we have all had our love affairs with Sinclairs, Tandys, Macs, Acorns, Amigas, Ataris, BeBoxes -- until one day the man with the axe came and obliterated our dreams. So we moved on.
So I know what it's like to be in love. The sky seems a little bit bluer, the sun a little bit brighter, and the hormonal imbalance makes that you don't even notice when you stub your toe on the table leg. And its okay to bore your friends to death with tales about how pretty she is, and flawless, and how her shit doesn't stink. That's what friends are for.
But please. Guys. I really just don't want to see you get hurt when she dumps you for some other target demographic.
GNU software is better, cheaper and freer than its UNIX counterparts. It's no wonder that GNU is finishing off the lame and deaf UNIX moloch. Besides, that has always been the project's goal. It's not like that's a secret or anything.
As for "lock-in", well, if GNU's the prison, I don't mind being a criminal.
WM environments (because you can't really call it a desktop) like XFce are a step backwards. They don't provide any of the facilities that a modern (or even ancient!) desktop should provide. By and large they're little more than a pretty means to run xterm, xclock and xload on a single screen.
The people using this stuff love to brag about the efficiency of their minimalist "Desktop", but there is nothing efficient about not being able to drag and drop images between applications, about spending hours to get a printer to work, about endless menu editing.
Call me a troll, but that's the way I see it. To each his own and all that, but please, let this stuff die already, don't give it any more publicity than it deserves. It's not a desktop, it's a graphical shell.
I don't have any hard numbers here, but certainly you agree that a very significant portion of all attacks today are based on these kinds of bugs.
But what's the actual damage? The script kids don't seem to actually do anything with the compromised machines except for whatever it is that the rootkit allows them to do. Then they swagger on IRC. Don't you agree considering the sheer volume of incidences that the actual impact is remarkably small?
"The process" should include making it as hard as possible to hack the box in the first place.
But we've probably become too antagonized. You can have the final word if you wish.
What are you talking about? VB and Javascript are client-side scripting languages with sandboxes.
My point is that both VB and JS don't allow stack smashing. Still they're at the root of numerous security breaches. The reason of course being that they're embedded in some sort of process: an application or a workflow. It's the flaws in the process that are much more insidious than any flaws in the language.
buffer overflows and the like in network services are what enable the really damaging, large-scale, automated attacks.
How do you know that? By what measure?
I would argue that the small cost of writing things in Java is more than outweighed by eliminating the most severe, hard-to-find errors that cause the worst security holes.
I think you're confusing a couple of things. If the box is your whole world, then yes, the ability to execute arbitrary code is probably the worst thing that can happen. But the box is not an end in itself. It is part of a process. From that perspective it's just a transient blip, one which normal process security should account for anyway, through checks and balances, insurance, backups, hardcopy, double books, periodic reviews, etcetera. The scary part isn't when the box gets hacked. It's when the process gets hacked.
Now I have to be careful. Stack smashing is a big problem. It is not a small or insignificant problem. But there is no solution. Just workarounds and compromises.
I consider bugs that can only cause a DoS much less bad than bugs which can cause the machine to be compromised.
Then the question becomes: how helpful is defense against stack smashing in preventing exploits, given that most exploits come about through social engineering or bugs at the application level (see VB macros, JavaScript holes)? Because the defense comes at a cost. You can argue that the cost is immaterial, that no cost is too high to prevent even the most innocent and trivial exploit.
That's a reasonable, principled argument, but not one I agree with. I take an economists view. If the estimated cost of an exploit is $25,000, but the cost of a thousand employees running slow, cumbersome software is $50 per employee per year, then the choice is clear. Especially since there is no guarantee that the slow, cumbersome software won't be subject to an exploit!
I'll even admit, shamefully, that I've personally written Java software where, due to a deadlock, a thread that should have been killed for security reasons was never notified of such and kept running. I don't blame Java for that. Maybe I'm just a bad programmer. But that's the whole point: the language's ability to provide application level security is limited. Conversely, also the degree to which a language can be held responsible for security breaches is limited.
What on earth do these two things have to do with Java's buffer overflow protection? If these things are hard to do in Java, that's because the APIs are badly designed, not because the language itself is secure.
Many of the Java security guarantees are derived by isolating programs from the underlying system. That is not a bad approach per se (it's pretty much the definition of an operating system kernel for example). But it does have its limitations. One of them being that you almost always end up with a lowest-common denominator design, through which the systems inherent capabilities cannot fully be excercised.
Java. Won't have any double-free bugs or stack-smashing attacks. But offers great potential for deadlock bugs due to the braindead IO model. And explodes in out of memory situations -- not unlikely given the tens or hundreds of MBs the Java runtime consumes. Further exacerbated by the ease with which memory is leaked. Then there are the subtle but devastating differences between the various Java runtimes. As well as the fact that the same isolationist principles that make Java immune to buffer overflows also make it very hard to interact meaningfully with the file system (ever tried setting creation dates on a file? ownership?).
The funny thing is that although fruitflies on a restricted diet live much longer, they basically stop all reproductive activity -- which, arguably, is the whole point of this "life thing". So the longer lifespan, in some sense, is more like a drawn out death.
Slashdot Mirror
Yeah, it was a sincere comment.
I buy a DVD with the expectation that I will be able to enjoy the contents on that DVD. I have equipment which is sufficient to allow me to do so (to wit: A computer equipped with a DVD-ROM drive), and so this would seem to be a reasonable expectation. I bring it home, pop it in, and find out that, for no better reason than I choose to use Linux (instead of Windows), I am unable to play the contents of this media.
Obviously, your expectation was false. You should have some research before buying the media. If a business can't expect its business model to be honored, then why should a customer expect his expectations to be honored? That, IMHO, is the other side of the coin.
Under the DMCA, it is very possible for me to find myself out the money for a DVD which I might actually enjoy. Somebody has stolen some time from me, and I have no recourse. Now, before you tell me to use Windows, keep in mind that I must buy Windows, somehow, some way. Which means that I am out even more time. Or a stand-alone DVD player, which has the same issue.
You bought a DVD on the assumption that it would play on your system. Nobody forced you to buy that DVD. Your assumption turned out to be false. I don't see how anybody has stolen anything from you.
The DMCA steals from me the ability to help others make use of the items which they have rightfully purchased with their time.
The key word here is "rightfully". You cannot play DVDs "rightfully" without the appropriate licenses. Its like complaining that somebody stole from you because you can't go into a movie theater without a ticket. After all, you spent some time going to the theatre. And the ticket is not a strict requirement for watching the movie: a pair of eyeballs and buttocks will do, and you have those.
So from your point of view, there is no reason why you shouldn't be able to watch the movie. But the bouncer disagrees. Do you call him a thief?
And another stupid idea dies a well deserved death. You would think someday companies would learn not to sell things for less than it cost to make them. We are talking econ 101 here people.
Yeah, and it shows. Try econ 201 some time.
The more often I hear this argument, the shallower it sounds.
All business is based on some assumption of law. For example, you can't just beat up your competitors. Is it moral that the law protects the weak from the strong? I think so, but there is a case to be made for the opposite.
In this case, we're the strong, and it's the artists, writers, programmers who are the weak. The DMCA is an effort to protect them. Is it therefore a shaky, ambiguous, and morally reprehensible law? Or just inconvenient to us?
I can't say I have personal experience, but I've heard from people who are supposed to know that flying a helicopter is much more difficult than flying a plane. A helicopter has a much greater degree of freedom, and much less tolerance for error. It's not that long ago that simply keeping one of these things steady in the air was considered a major feat. Seriously.
This is like a proposal to take down all those ugly, messy websites, and recode them to comply with the most strict interpretations of the very latest W3C standards, and everybody will live happily ever after.
It's nonsense. Because the messiness and ugliness follows directly from the ease with which people can (try to) fill a niche. Take away the messiness and ugliness, and you take away half to three-quarters of the software. And with that all the vibrancy.
To get back to the World Wide Web analogy: if HTML had been more formal, there would be fewer junk. But there also wouldn't have been a Web as we know it. The Web as well as Linux have been successful because they are extremely open and free. Not because they provide "one way of doing things".
And if we don't do it, Bill, IBM, or Novell WILL.
So what? We're not in the same race as them. "We" don't have the same goals.
In any case, my observations were mostly about what it would take to get people to start using Linux on the desktop. *shrug* Hey, if it's what people want, why not give it to 'em?
Because giving it to them takes time and effort. Besides, why give them something they already have?
It's like all the comments on this thread have been generated from the same database by the same computer program. Ridiculous generalizations formulated in a stiffly "realist" corporate lingo. Noble self-proclaimed champions of mothers world-wide. Except that not a single mom is endeared by their flat and lifeless pseudo-ideas.
If Linux ever becomes a success, it won't be because anybody follows your dreary advice. It will be because somebody creates an excellent implementation of a great idea.
It's like all the comments on this thread have been generated from the same database by the same computer program. Ridiculous generalizations formulated in a stiffly "realist" corporate lingo. Noble self-proclaimed champions of mothers world-wide. Except that not a single mom is endeared by their flat and lifeless pseudo-ideas.
If Linux ever becomes a success, it won't be because anybody follows your dreary advice. It will be because somebody creates an excellent implementation of a great idea.
Not only do you want boring office software, you also want it to be just like Microsoft's office software. But then why not just use that?
I love X... but I have to admit that you've hit the nail on the head. It's astonishing how bad cut and paste works between applications. It really only works for text, and then only if the text is flat ASCII. Because it's so bad, many applications have their own, internal version of the clipboard, and you're never really sure whether you're manipulating X's clipboard or the internal clipboard, or what information makes it onto X's clipboard and in what form. It's a total disaster.
Cut and paste on X is so bad, that I use it so little, that my expectations have sunk so low, that I've basically forgotten how it is to have a clipboard system that does work. Thanks for the reminder.
They could just release the documentation.
But spare us the cynicism. What exactly is the problem? A bunch of guys on Slashdot love their new Macs and you have a problem. I say: get over it. We're nerds.
Cynicism? No. Experience.
I'm glad people love their Macs. It's just that they seem to forget they're not the first people to use them. It's the holier-than-thou "you'll never understand it" attitude. I understand perfectly well. And eventually I got over it.
And BTW: we're talking about the new Napster vs. other services like iTunes. That is NOT something you've 'been doing all along' because these services are NEW.
Selling music on the Internet. Big whoop. If it was a patent it would be in the "my dog could have thought of that" category.
No seriously. It's probably very well done. But I haven't seen it yet. And I don't feel any less for not having seen it. That's my whole point. This isn't the second coming. Not interested. Keep it to yourself. Thanks.
The screenshot you posted is terrible, take a look at the JuK screenshot here. Looks much nicer doesn it?
Ah. And why is that? Could it be that it looks nicer because it looks more like MacOS X?
Talk about missing the point...
Look, I can appreciate how thrilling it must be to all the nouveau-Appleians to finally have a computer that does what you want, but by now I've gotten fairly fed up with the non-stop gushing on Slashdot. It's gotten to the point that I'm waiting for the headline "Steve Jobs Takes Shit, Finds Gold Nugget".
To some of us, none of this stuff is new, you see. We've always chosen our computers based on our needs and interests of the moment, rather than going by some company or market diktat, and as a result our computers have always done pretty much what we want, seamlessly and flawlessly. Back in the day we have all had our love affairs with Sinclairs, Tandys, Macs, Acorns, Amigas, Ataris, BeBoxes -- until one day the man with the axe came and obliterated our dreams. So we moved on.
So I know what it's like to be in love. The sky seems a little bit bluer, the sun a little bit brighter, and the hormonal imbalance makes that you don't even notice when you stub your toe on the table leg. And its okay to bore your friends to death with tales about how pretty she is, and flawless, and how her shit doesn't stink. That's what friends are for.
But please. Guys. I really just don't want to see you get hurt when she dumps you for some other target demographic.
Xlib compatibility will automatically give you toolkit compatibility. Behold:
/usr/lib/libgtk-1.2.so.0.9.1 /usr/X11R6/lib/libXi.so.6 (0x40166000) /usr/X11R6/lib/libXext.so.6 (0x4016e000) /usr/X11R6/lib/libX11.so.6 (0x4017c000)
/usr/lib/qt-1.45/lib/libqt.so /usr/X11R6/lib/libX11.so.6 (0x401d5000) /usr/X11R6/lib/libXext.so.6 (0x402a4000)
$ ldd
libXi.so.6 =>
libXext.so.6 =>
libX11.so.6 =>
$ ldd
libX11.so.6 =>
libXext.so.6 =>
At least that's the theory.
GNU software is better, cheaper and freer than its UNIX counterparts. It's no wonder that GNU is finishing off the lame and deaf UNIX moloch. Besides, that has always been the project's goal. It's not like that's a secret or anything.
As for "lock-in", well, if GNU's the prison, I don't mind being a criminal.
WM environments (because you can't really call it a desktop) like XFce are a step backwards. They don't provide any of the facilities that a modern (or even ancient!) desktop should provide. By and large they're little more than a pretty means to run xterm, xclock and xload on a single screen.
The people using this stuff love to brag about the efficiency of their minimalist "Desktop", but there is nothing efficient about not being able to drag and drop images between applications, about spending hours to get a printer to work, about endless menu editing.
Call me a troll, but that's the way I see it. To each his own and all that, but please, let this stuff die already, don't give it any more publicity than it deserves. It's not a desktop, it's a graphical shell.
I don't have any hard numbers here, but certainly you agree that a very significant portion of all attacks today are based on these kinds of bugs.
But what's the actual damage? The script kids don't seem to actually do anything with the compromised machines except for whatever it is that the rootkit allows them to do. Then they swagger on IRC. Don't you agree considering the sheer volume of incidences that the actual impact is remarkably small?
"The process" should include making it as hard as possible to hack the box in the first place.
But we've probably become too antagonized. You can have the final word if you wish.
What are you talking about? VB and Javascript are client-side scripting languages with sandboxes.
My point is that both VB and JS don't allow stack smashing. Still they're at the root of numerous security breaches. The reason of course being that they're embedded in some sort of process: an application or a workflow. It's the flaws in the process that are much more insidious than any flaws in the language.
buffer overflows and the like in network services are what enable the really damaging, large-scale, automated attacks.
How do you know that? By what measure?
I would argue that the small cost of writing things in Java is more than outweighed by eliminating the most severe, hard-to-find errors that cause the worst security holes.
I think you're confusing a couple of things. If the box is your whole world, then yes, the ability to execute arbitrary code is probably the worst thing that can happen. But the box is not an end in itself. It is part of a process. From that perspective it's just a transient blip, one which normal process security should account for anyway, through checks and balances, insurance, backups, hardcopy, double books, periodic reviews, etcetera. The scary part isn't when the box gets hacked. It's when the process gets hacked.
Now I have to be careful. Stack smashing is a big problem. It is not a small or insignificant problem. But there is no solution. Just workarounds and compromises.
Ralph Waldo Emerson once said, "In my walks, every man I meet is my superior in some way, and in that I learn from him."
What Ralph Waldo forgets to mention is that he's considered an idiot by many.
I consider bugs that can only cause a DoS much less bad than bugs which can cause the machine to be compromised.
Then the question becomes: how helpful is defense against stack smashing in preventing exploits, given that most exploits come about through social engineering or bugs at the application level (see VB macros, JavaScript holes)? Because the defense comes at a cost. You can argue that the cost is immaterial, that no cost is too high to prevent even the most innocent and trivial exploit.
That's a reasonable, principled argument, but not one I agree with. I take an economists view. If the estimated cost of an exploit is $25,000, but the cost of a thousand employees running slow, cumbersome software is $50 per employee per year, then the choice is clear. Especially since there is no guarantee that the slow, cumbersome software won't be subject to an exploit!
I'll even admit, shamefully, that I've personally written Java software where, due to a deadlock, a thread that should have been killed for security reasons was never notified of such and kept running. I don't blame Java for that. Maybe I'm just a bad programmer. But that's the whole point: the language's ability to provide application level security is limited. Conversely, also the degree to which a language can be held responsible for security breaches is limited.
What on earth do these two things have to do with Java's buffer overflow protection? If these things are hard to do in Java, that's because the APIs are badly designed, not because the language itself is secure.
Many of the Java security guarantees are derived by isolating programs from the underlying system. That is not a bad approach per se (it's pretty much the definition of an operating system kernel for example). But it does have its limitations. One of them being that you almost always end up with a lowest-common denominator design, through which the systems inherent capabilities cannot fully be excercised.
make it very hard to interact meaningfully with the file system
Crap. That should be, "make it very hard to interact meaningfully with the system period".
Sigh. The language card again. OK.
Java. Won't have any double-free bugs or stack-smashing attacks. But offers great potential for deadlock bugs due to the braindead IO model. And explodes in out of memory situations -- not unlikely given the tens or hundreds of MBs the Java runtime consumes. Further exacerbated by the ease with which memory is leaked. Then there are the subtle but devastating differences between the various Java runtimes. As well as the fact that the same isolationist principles that make Java immune to buffer overflows also make it very hard to interact meaningfully with the file system (ever tried setting creation dates on a file? ownership?).
Yeah. Java.
The funny thing is that although fruitflies on a restricted diet live much longer, they basically stop all reproductive activity -- which, arguably, is the whole point of this "life thing". So the longer lifespan, in some sense, is more like a drawn out death.
If that's not irony I don't know what is.
If the writologist proofreadicated his articlation, he might findify prosage less awkwarditious.
Genius, my friend, pure genius.