It may not be meant to be free in a monetary sense, but in practice, it turns out that way. Because I can pay for my copy and turn around and give it away for free to anyone who wants it, making a business model out of selling GPL software is not feasible. In practice, the GPL tends to mean free as in beer, as well as free as in speech.
I want my pull-down menus at the top of my windows, but they are so confident that being able to bump your mouse against the top of the screen is a better UI design that they absolutely refuse to give me the option. Right on, there. It's a very similar issue.
I want a second mouse button, but they know that the second button leads to UI confusion, so they will not give me an option to turn on support for another button. Erm. Huh? Apple supports right-clicks. The Mighty Mouse (default mouse shipped with desktop systems) uses capacitance to determine if you're right- or left-clicking. You've been able to use a third-party mouse for right-clicks for years. The only place where this is even possibly an issue is on notebooks, where the touchpad only has one physical button (and doesn't use capacitance.) You can, however, change the settings to allow for right-click if you tap the touch pad with two fingers.
What Apple did there was give the option to use right-clicks. Just what people are asking for in Pidgin--the option to use the old style.
I want to run on hardware that I built myself, but they know I'm better off running on their hardware so they won't let me. Oh come on. This has nothing to do with being better off, and everything to do with Apple wanting to sell high-priced computers to people who only care about OS X. It's lock-in--a completely separate issue to be angry about.
It's always interesting to see this sort of software evolution in action. It reminds me of the XFree86/X.org split. I'm pretty interested to see if one or the other IM project takes dominance. Most likely, it will be the one that Ubuntu chooses to go with in its next release.
From the images, it looks like they were referring largely to the percentage area taken up by the input box compared to the percentage area taken up by the conversation display.
Mostly, I think that it's a case of "the computer doesn't know better than I do when it comes to what I need." Looking at the link in the article, I can see why there are complaints.
I don't think that we're talking about a case where there would be separate, significant code paths to maintain. Scroll bars and resizeable windows are easy-easy-easy--GUI 101, really. I don't think that a design which allowed for either (primarily through the use of message passing to indicate resizing, and if there's a box checked somewhere, that message just drops on the floor) would be complex at all.
Honestly, the best way to deal with it would be to auto-resize unless the user explicitly changes the size. From that point on, give them control of the window.
But if you look at the images in the linked page, there definitely appear to be some usability concerns here.
Another difference is that Microsoft has to sell their product. If they make a change which alienates the majority of their users, they lose money. They are developing for their users.
OSS projects tend to be staffed by people developing for themselves. They are their own users. If they don't sell a million copies, big deal (and they probably weren't selling them to begin with.)
Well, I was talking about a world where we've moved on from off-CPU GPUs. Right now, yes, it's rare for people to upgrade the CPU without also upgrading many other components--but it's not always as dark an outlook as you suggest. The Core Duo, for example, is pin-compatible with the Core2Duo, and the performance difference is noticeable (at least on Macs.)
It seems like you could still have specialized ray-tracing hardware. Whether that's integrated into the main CPU as a specialized core, or as an expansion card really isn't relevant, though.
I think the best thing about heading in this direction is that "accelerated" graphics no longer becomes limited by your OS--assuming your OS supports the full instruction set of the CPU. No more whining that Mac Minis have crappy graphics cards, no more whining that Linux has crappy GPU driver support....
The downside is that an easy upgrade path gets lost. Right now, you can breathe new life into your aging system by upgrading the graphics card (if you're wanting to play newer games, of course.) Upgrading the CPU is a little more intimidating.
This prompted an interesting question in my mind. Are there any browsers which incorrectly render the standards, and for which the only way to get the page to display as intended is to intentionally write code that breaks the standards?
Such a situation would put the developer in a real pickle. I suspect I know the answer to this question, but I'll see if anyone responds (to avoid potentially poisoning the replies.)
Before you go on a rant about how stupid a whole forum of users are I said that they didn't do critical thinking, not that they were incapable of it.
you should be able to demonstrate a reasonable understanding of the topic you're judging people on. And I wasn't judging them on database design, I was judging them on nitpicking every last little detail in an effort to sound smart when someone doesn't enumerate every last detail of an idea in a web forum post.
Imposing a somewhat drastic limitation on a programmer's data access "by default" (whatever that means) Do you really not understand what such a thing might mean?
I mean, there are multiple ways to do it. You might set a flag while you're connecting to the database which says, "Allow multiple statements." You might set a flag per-call. You might toggle a setting in the application stack.
Crippling the capabilities of one library and enabling them elsewhere in the same framework would only serve to make a more obscure library the new "default", as you call it. Maybe. Anectodally, I've read through many PHP books, and almost none of them deviate from the default database connection settings until you get into the advanced topics.
As far as your language, I wouldn't call this example crippling. Most OSS projects (again, I can only speak anecdotally of the ones that I've examined) make minimal use of multiple statements. Someone suggested that PHP's MySQL driver now restricts multiple statements unless you set a flag, too.
The combination of proper programming practices, security functions built into the database server and thorough documentation are the appropriate way to prevent stupid vulnerabilities like SQL injection. And let's be honest, it's a terribly silly thing to let happen in your code. We may simply have to agree to disagree. I think that making software safe and secure by default, while allowing people the option to explicitly override that default, is the proper way to go. If someone has to go to the trouble of explicitly allowing unsafe behavior, we may assume that they've at least glanced at the documentation, where hopefully it mentions that this is a really bad thing to do. Note that I'm talking about a general case, here. Multiple statements may not be a really bad thing to do but allowing them is certainly less safe than disallowing them--again, all in the defaults.
Microsoft has done the only things you could reasonably expect in the way of due diligence by frequently iterating best practices for data access. They've provided abstracted data access controls and binding techniques for people with typical data access requirements. They've even gone so far as to provide data access in larger options like the enterprise library. Anyone who uses unchecked, ad-hoc queries with sqlclient in their codebehind has simply gone out of their way to do something dumb. So those half-a-million web application designers went out of their way to do something dumb? This seems to indicate a problem.
All this aside, you've failed to recognize that many other popular web stacks (not just.Net on IIS with MSSQL) allow the same behavior. See, you're just assuming here. I didn't say that other stacks are bullet proof. In other posts, I've noted my dislike for PHP. I'm no Microsoft fanboy--I'm a fan of using the right tool for the job. I'm also a fan of secure-by-default designs--something of which PHP (for example) has a terrible history, as does Microsoft.
http://www.appleinsider.com/articles/08/02/07/macbook_air_hdd_and_ssd_battery_benchmarks.html indicates that the battery usage (at least compared to the HDD shipped with the Macbook Air) is negligible. No moving parts is nice, though manufacturers have addressed some of the ruggedness issues by including drop sensors. Actual, real world wear hasn't had a chance to surface yet--I'll definitely be curious to find out if SSDs live up to the speculation.
Botnet authors have a strong desire to avoid disrupting the machine. They want to be able to use the machine's excess resources, and nothing more. If they get noticed, they (likely) get deleted, and that's one less computer to make money from.
Someone trying to distribute code to clean the infected computer has much less of an impetus to avoid utterly destroying the system. Sure, they don't want to, but there's no direct hardship if they do. Might they be a little less careful? Maybe.
Worse, a botnet author might include self-destruct code if it detects tampering. Presumably, the white hats would test for this extensively on their own systems, but maybe they miss something? Maybe an update to do this comes in after they've created their payload, but before they send it? There are a lot of risks here that need to be weighed before deciding to fix other people's computers without their consent.
Though in this case, we're not really talking about creating a worm, are we? We're talking about using an infection to clean that same infection on a local machine. This specific use case is not clearly abuse. Doing anything else to the machine at all would be way out of line.
There should certainly be a way to perform multiple statements in a single call, but it should not be the default. Just like we disallow kernel calls unless you do it in a special way because they are dangerous.
Unfortunately, it seems like the majority of Slashdotters can't seem to think beyond the printed words on the screen. It makes me sad--there was a time when this place was full of pretty bright people. Now it seems like it's just full of people who want to get in their "You're wrong!" reply without doing any critical thinking.
So what you are saying is that (and quoting the article you reference) Microsoft is at fault for providing these "high end features"? No, that's not what I said. I said that Microsoft could have prevented it, not that they were at fault. There's a world of difference.
And that the lack of that feature is actually an advantage for platforms like PHP and Perl? I think that the protection against multiple statements in the MySQL driver for PHP and Perl is an advantage, yes. Much in the same way that I would consider default-bounds checking in a language an advantage. It'd be even better if you could explicitly turn the feature off in order to use "unsafe" statements. The C API to MySQL allows this--I'm not sure if the PHP version does, because frankly, I've never encountered a situation where I needed this behavior.
I'm curious, is the lack of that feature the reason for the multiple and well-documented injection attacks against LAMP applications? Or is it something else? Are you being sarcastic, or am I inferring incorrectly? Damned lack of inflection in plain text....
Disallowing multiple statements does not prevent SQL injection. It prevents injecting new statements. It's still quite possible to inject unintended content into the query.
Morevover, I understand that the multiple statement protection is relatively new, so who knows if it would have had a large impact on the number of injection vulnerabilities in applications built on LAMP.
You will forgive me here if I imagine for a second what the general sentiment would be if the PHP MySQL driver actually provided this useful time- and bandwidth-saving feature while ADO/ADO.NET didn't. Well, I think that the bandwidth and time savings are going to be fairly minimal. I'd like to think that I'd feel the same way if this situation were reversed.
And like I said from the beginning of this post, I'm not laying blame solely on Microsoft. Quite obviously, the developers are at least 50% culpable. But the truth is, I don't understand the usefulness of this feature, and it has shown to allow for a great deal of harm. There's something to be said for anticipating security problems with features before you add them (take, for example, register_globals in PHP--a useful feature to the lazy programmer, but the bane of security analysts. I'd much rather that feature have never seen the light of day.)
Ultimately, I'm no fan of PHP for the same reason. It's a poorly designed language that lets the developer shoot himself in the foot far too easily. It's also easy to use, so it's attracted a large number of non-programmers. The combination of the two means that there are huge numbers of flaws in PHP applications. If PHP were more strict, these flaws wouldn't exist. I've probably even got a PHP rant or two hanging around on Slashdot....
If I were guessing, I'd say that Coldfusion has a fairly low market share. The main reason that I'd say this is that it's a) an expensive solution that b) isn't Microsoft.
Lots of people pick free solutions. Lots of people who don't pick free solutions know about IIS and MS SQL. They stick with Microsoft because it's the brand, and it's a one-stop shop for support. There are also a lot more VBS/.Net developers than Coldfusion ones, so developers will be cheaper.
That said, there are 38,000 hits from Google for coldfusion sql injection. Most of the hits in the first few pages aren't talking about how Coldfusion is magically immune. While that doesn't mean that it isn't, I know where I'd lay my money if I were a betting man.
http://hackademix.net/2008/04/26/mass-attack-faq/#comment-7742 has a decent explanation of why this is primarily hitting IIS. SQL injection is common to many platforms, but Microsoft's database driver has some features that made it particularly easy to generalize the exploit. Specifically, prior knowledge of the table layout was apparently unnecessary to create the exploit, meaning that it was easy to hit a large number of websites in a short period of time.
Some of these complexity and efficiency issues can be resolved by partial denormalization of the database design, but again, that introduces inefficiency. Which efficiency does this reduce? Normally, from a database perspective, normalizing increases data integrity at the expense of database efficiency, doesn't it?
Database frameworks can often deal with complex databases for read operations which, in this day and age, tend to be a high percentage of the operations that a database performs. They're probably worth using for read operations, and write operations where good performance isn't a requirement. You can always fall back on raw SQL (with stringently checked values) in order to gain performance where it's needed.
As others have posted, it's pretty easy to prevent multiple instruction SQL injection. That's a function of the database driver, which Microsoft controls.
It's much harder to prevent injection of additional parameters e.g. typing ' or '1'='1 into the text box--that's something that will be language and developer dependent. From my very brief scan of the details of this vulnerability, it looks like it would have been prevented if Microsoft had disallowed multiple statements in the driver.
* ASP classic, due to the poor coding standards among the average VBScripters who hardly known about prepared statements (even though they are supported)
* ADO as the DB client layer, allowing stacked queries (multiple SQL statements together in a single string), which are not supported, for instance, by JDBC or by the mysql_query() PHP API
* Microsoft SQL Server, because its Transact SQL supports a rich feature set including loops, metadata enumeration and Dynamic SQL (crucial for generalization), and because itâ(TM)s the most common ASP database back-end with such high-end features. Apparently, if stacked queries weren't allowed, this wouldn't nearly so easy to exploit.
It seems like Java really has a bad case of "first impression syndrome." At the time, the only thing that it really seemed to have going for it was wide compatibility--and even that was not always true (I've had to deal with incompatibility issues between JVM versions in some applications that we support.) It sounds like Java is pretty nice now, so I may have to give it another look.
I haven't kept up with Java--has its speed really improved, or is it just that hardware has caught up enough to make delays primarily the result of waiting for user input?
When I first started messing around with Java (fairly shortly after it was released), it really was much, much slower than compiled code of just about any language. I wasn't a big Perl user at the time, so I really couldn't compare, and the joy of Python wasn't even a twinkle in my eye.
Slashdot Mirror
It may not be meant to be free in a monetary sense, but in practice, it turns out that way. Because I can pay for my copy and turn around and give it away for free to anyone who wants it, making a business model out of selling GPL software is not feasible. In practice, the GPL tends to mean free as in beer, as well as free as in speech.
Of course, razor handles are laregely useless without the blade. Operating systems can be quite useful without support.
Worse, there's lots of community support out there for free. It'd be like someone giving away compatible razors that work with your free razor handle.
The razor blade business model only works when what you give away has extremely limited usefulness by itself.
Adium is not Pidgin. It uses the same IM libraries, like many open-source IM clients, but they are separate programs.
What Apple did there was give the option to use right-clicks. Just what people are asking for in Pidgin--the option to use the old style. I want to run on hardware that I built myself, but they know I'm better off running on their hardware so they won't let me. Oh come on. This has nothing to do with being better off, and everything to do with Apple wanting to sell high-priced computers to people who only care about OS X. It's lock-in--a completely separate issue to be angry about.
It's always interesting to see this sort of software evolution in action. It reminds me of the XFree86/X.org split. I'm pretty interested to see if one or the other IM project takes dominance. Most likely, it will be the one that Ubuntu chooses to go with in its next release.
From the images, it looks like they were referring largely to the percentage area taken up by the input box compared to the percentage area taken up by the conversation display.
Mostly, I think that it's a case of "the computer doesn't know better than I do when it comes to what I need." Looking at the link in the article, I can see why there are complaints.
I don't think that we're talking about a case where there would be separate, significant code paths to maintain. Scroll bars and resizeable windows are easy-easy-easy--GUI 101, really. I don't think that a design which allowed for either (primarily through the use of message passing to indicate resizing, and if there's a box checked somewhere, that message just drops on the floor) would be complex at all.
Honestly, the best way to deal with it would be to auto-resize unless the user explicitly changes the size. From that point on, give them control of the window.
But if you look at the images in the linked page, there definitely appear to be some usability concerns here.
Another difference is that Microsoft has to sell their product. If they make a change which alienates the majority of their users, they lose money. They are developing for their users.
OSS projects tend to be staffed by people developing for themselves. They are their own users. If they don't sell a million copies, big deal (and they probably weren't selling them to begin with.)
Well, I was talking about a world where we've moved on from off-CPU GPUs. Right now, yes, it's rare for people to upgrade the CPU without also upgrading many other components--but it's not always as dark an outlook as you suggest. The Core Duo, for example, is pin-compatible with the Core2Duo, and the performance difference is noticeable (at least on Macs.)
It seems like you could still have specialized ray-tracing hardware. Whether that's integrated into the main CPU as a specialized core, or as an expansion card really isn't relevant, though.
I think the best thing about heading in this direction is that "accelerated" graphics no longer becomes limited by your OS--assuming your OS supports the full instruction set of the CPU. No more whining that Mac Minis have crappy graphics cards, no more whining that Linux has crappy GPU driver support....
The downside is that an easy upgrade path gets lost. Right now, you can breathe new life into your aging system by upgrading the graphics card (if you're wanting to play newer games, of course.) Upgrading the CPU is a little more intimidating.
This prompted an interesting question in my mind. Are there any browsers which incorrectly render the standards, and for which the only way to get the page to display as intended is to intentionally write code that breaks the standards?
Such a situation would put the developer in a real pickle. I suspect I know the answer to this question, but I'll see if anyone responds (to avoid potentially poisoning the replies.)
I mean, there are multiple ways to do it. You might set a flag while you're connecting to the database which says, "Allow multiple statements." You might set a flag per-call. You might toggle a setting in the application stack. Crippling the capabilities of one library and enabling them elsewhere in the same framework would only serve to make a more obscure library the new "default", as you call it. Maybe. Anectodally, I've read through many PHP books, and almost none of them deviate from the default database connection settings until you get into the advanced topics.
As far as your language, I wouldn't call this example crippling. Most OSS projects (again, I can only speak anecdotally of the ones that I've examined) make minimal use of multiple statements. Someone suggested that PHP's MySQL driver now restricts multiple statements unless you set a flag, too. The combination of proper programming practices, security functions built into the database server and thorough documentation are the appropriate way to prevent stupid vulnerabilities like SQL injection. And let's be honest, it's a terribly silly thing to let happen in your code. We may simply have to agree to disagree. I think that making software safe and secure by default, while allowing people the option to explicitly override that default, is the proper way to go. If someone has to go to the trouble of explicitly allowing unsafe behavior, we may assume that they've at least glanced at the documentation, where hopefully it mentions that this is a really bad thing to do. Note that I'm talking about a general case, here. Multiple statements may not be a really bad thing to do but allowing them is certainly less safe than disallowing them--again, all in the defaults. Microsoft has done the only things you could reasonably expect in the way of due diligence by frequently iterating best practices for data access. They've provided abstracted data access controls and binding techniques for people with typical data access requirements. They've even gone so far as to provide data access in larger options like the enterprise library. Anyone who uses unchecked, ad-hoc queries with sqlclient in their codebehind has simply gone out of their way to do something dumb. So those half-a-million web application designers went out of their way to do something dumb? This seems to indicate a problem. All this aside, you've failed to recognize that many other popular web stacks (not just
http://www.appleinsider.com/articles/08/02/07/macbook_air_hdd_and_ssd_battery_benchmarks.html indicates that the battery usage (at least compared to the HDD shipped with the Macbook Air) is negligible. No moving parts is nice, though manufacturers have addressed some of the ruggedness issues by including drop sensors. Actual, real world wear hasn't had a chance to surface yet--I'll definitely be curious to find out if SSDs live up to the speculation.
Botnet authors have a strong desire to avoid disrupting the machine. They want to be able to use the machine's excess resources, and nothing more. If they get noticed, they (likely) get deleted, and that's one less computer to make money from.
Someone trying to distribute code to clean the infected computer has much less of an impetus to avoid utterly destroying the system. Sure, they don't want to, but there's no direct hardship if they do. Might they be a little less careful? Maybe.
Worse, a botnet author might include self-destruct code if it detects tampering. Presumably, the white hats would test for this extensively on their own systems, but maybe they miss something? Maybe an update to do this comes in after they've created their payload, but before they send it? There are a lot of risks here that need to be weighed before deciding to fix other people's computers without their consent.
Though in this case, we're not really talking about creating a worm, are we? We're talking about using an infection to clean that same infection on a local machine. This specific use case is not clearly abuse. Doing anything else to the machine at all would be way out of line.
There should certainly be a way to perform multiple statements in a single call, but it should not be the default. Just like we disallow kernel calls unless you do it in a special way because they are dangerous.
Unfortunately, it seems like the majority of Slashdotters can't seem to think beyond the printed words on the screen. It makes me sad--there was a time when this place was full of pretty bright people. Now it seems like it's just full of people who want to get in their "You're wrong!" reply without doing any critical thinking.
Disallowing multiple statements does not prevent SQL injection. It prevents injecting new statements. It's still quite possible to inject unintended content into the query.
Morevover, I understand that the multiple statement protection is relatively new, so who knows if it would have had a large impact on the number of injection vulnerabilities in applications built on LAMP. You will forgive me here if I imagine for a second what the general sentiment would be if the PHP MySQL driver actually provided this useful time- and bandwidth-saving feature while ADO/ADO.NET didn't. Well, I think that the bandwidth and time savings are going to be fairly minimal. I'd like to think that I'd feel the same way if this situation were reversed.
And like I said from the beginning of this post, I'm not laying blame solely on Microsoft. Quite obviously, the developers are at least 50% culpable. But the truth is, I don't understand the usefulness of this feature, and it has shown to allow for a great deal of harm. There's something to be said for anticipating security problems with features before you add them (take, for example, register_globals in PHP--a useful feature to the lazy programmer, but the bane of security analysts. I'd much rather that feature have never seen the light of day.)
Ultimately, I'm no fan of PHP for the same reason. It's a poorly designed language that lets the developer shoot himself in the foot far too easily. It's also easy to use, so it's attracted a large number of non-programmers. The combination of the two means that there are huge numbers of flaws in PHP applications. If PHP were more strict, these flaws wouldn't exist. I've probably even got a PHP rant or two hanging around on Slashdot....
If I were guessing, I'd say that Coldfusion has a fairly low market share. The main reason that I'd say this is that it's a) an expensive solution that b) isn't Microsoft.
Lots of people pick free solutions. Lots of people who don't pick free solutions know about IIS and MS SQL. They stick with Microsoft because it's the brand, and it's a one-stop shop for support. There are also a lot more VBS/.Net developers than Coldfusion ones, so developers will be cheaper.
That said, there are 38,000 hits from Google for coldfusion sql injection. Most of the hits in the first few pages aren't talking about how Coldfusion is magically immune. While that doesn't mean that it isn't, I know where I'd lay my money if I were a betting man.
That's close.
http://hackademix.net/2008/04/26/mass-attack-faq/#comment-7742 has a decent explanation of why this is primarily hitting IIS. SQL injection is common to many platforms, but Microsoft's database driver has some features that made it particularly easy to generalize the exploit. Specifically, prior knowledge of the table layout was apparently unnecessary to create the exploit, meaning that it was easy to hit a large number of websites in a short period of time.
Database frameworks can often deal with complex databases for read operations which, in this day and age, tend to be a high percentage of the operations that a database performs. They're probably worth using for read operations, and write operations where good performance isn't a requirement. You can always fall back on raw SQL (with stringently checked values) in order to gain performance where it's needed.
It's much harder to prevent injection of additional parameters e.g. typing ' or '1'='1 into the text box--that's something that will be language and developer dependent. From my very brief scan of the details of this vulnerability, it looks like it would have been prevented if Microsoft had disallowed multiple statements in the driver.
This page supports my interpretation. I note, specifically: Attackers carefully weighted the easiest spot, being a combination of
* ASP classic, due to the poor coding standards among the average VBScripters who hardly known about prepared statements (even though they are supported)
* ADO as the DB client layer, allowing stacked queries (multiple SQL statements together in a single string), which are not supported, for instance, by JDBC or by the mysql_query() PHP API
* Microsoft SQL Server, because its Transact SQL supports a rich feature set including loops, metadata enumeration and Dynamic SQL (crucial for generalization), and because itâ(TM)s the most common ASP database back-end with such high-end features. Apparently, if stacked queries weren't allowed, this wouldn't nearly so easy to exploit.
Thanks to you and jrumney for the explanations.
It seems like Java really has a bad case of "first impression syndrome." At the time, the only thing that it really seemed to have going for it was wide compatibility--and even that was not always true (I've had to deal with incompatibility issues between JVM versions in some applications that we support.) It sounds like Java is pretty nice now, so I may have to give it another look.
I haven't kept up with Java--has its speed really improved, or is it just that hardware has caught up enough to make delays primarily the result of waiting for user input?
When I first started messing around with Java (fairly shortly after it was released), it really was much, much slower than compiled code of just about any language. I wasn't a big Perl user at the time, so I really couldn't compare, and the joy of Python wasn't even a twinkle in my eye.
As others have pointed out, the obvious way around this clause in the EULA is to label the computer: Apple.