This is not rocket science here. The 100% certified, no-assembly-required, Makes Baby Jesus Happy (TM) solution to this "problem" is to use your database's built-in programmability feature (better known as stored procedures) every single time you need to pull data push data from your database. No exceptions. And that's it. Stop using lame inline SQL.
I hear even MySQL supports stored procedures now, so I don't see what the problem is, other than millions of lines of sloppy existing code that won't die. But the "fix" has always been there.
Even stored procedures are vulnerable to SQL injection.
The 100% certified, etc., solution is to not use a text-based query language.
Of course, then you lose the massive forms of flexibility that SQL gives you.
I have to say this is the most succinct explanation of why SQL Server is specifically vulnerable to the attack. It's certainly something for Microsoft to look at the next time they look into modifying T-SQL.
I do not, however, think this rises to the level of actually being able to blame Microsoft for the attack. The fault there lies 100% on the shoulders of programmers who did not use the tools available to them to eliminate SQL injection.
The structure of T-SQL did allow the hackers to add the javascript to every text field in the database, yes. But the fact that they were able to allow javascript to *any* text field is entirely the fault of the site programmers.
Jeff Atwood had an interesting article on the subject a couple weeks ago. It generated a metric buttload of comments, so you might consider mining for ideas there.
Well, yes, and the next time someone posts on a Slashdot discussion "Why don't they just build skyscrapers out of spoons", that'll be relevant. However, the question someone asked in this thread was (paraphrased) why don't people reverse-engineering.NET just use the MSDN documentation, so the answer that the MSDN documentation (however adequate its accuracy may be for other purposes) is not sufficiently accurate to support that is perfectly reasonable and appropriate, and your spoon-skyscraper comparison entirely misses the point of why the accuracy of MSDN was being discussed in the first place. Ahh, I see the problem: You misinterpreted the original remark. Or I did, depending on how you look at it. The remark was this:
Why not just have the developer read the.Net MSDN docs for the.Net API. It's not like anything they are doing is extremely complicated. You should be able to get things almost identical by just reading the.Net API docs. Granted, there's a lot of functionality, and it would take quite an effort to code all that, especially considering Microsoft's tendency to continuously add to the API, but it's not something that you would need to see the source to implement.
My read is that the suggestion was not to reverse-engineer the.Net API but to *duplicate* the API. That should be quite possible using just the MSDN docs, which are surprisingly detailed and rarely inaccurate. Mono has done a great job so far doing just that. You don't have to do every method of every class exactly the same way Microsoft did step-for-step as long as the inputs, outputs, and state changes remain the same.
Detail is meaningless if you cannot trust the accuracy of said details.
Given the size of MSDN and my own anecdotal evidence using it, I'd say that "inaccurate" details in MSDN are fairly rare. They are there, yes, but on the whole I'd say the docs are pretty accurate. MSDN is frequently not detailed enough, I'll grant you, but as I said, it's heads and shoulders above the detail provided by far too many software shops and middle-ware library providers (open source or not) these days.
The MSDN docs are next to useless for the purposes of reverse engineering without a lot of messing around.
Very true. Of course it's also true that a spoon is next to useless for the purposes of building a skyscraper, but such is not the purpose of the spoon.
Because the MSDN documents are not accurate. Many times I found the API documentation do not contain the true behavior of certain APIs. This is one of the reasons why Wine requires testing API functionality on Windows first instead of just basing it all on the MSDN documentation.
Heh... sounds like just about every software shop in the history of everything.:D
Sometimes I wish the documentation at my current job came even *close* to the amount of detail provided by MSDN. Ok, scratch that. *EVERY DAY* I wish the documentation at my current job came even close to the amount of detail provided by MSDN.
Office 2007 does, but I get your point. Mostly, however, that's a marketing choice on the part of Microsoft's competitors rather than an implementation issue. Yes, OOXML has a complex XML schema, but it's quite possible to write to the format.
Then due to the fact that there are blobs of binary data in it, in propriety Microsoft formats. Others are not free to implement code that reads or writes these formats. These formats are not publically documented. Let alone public standards.
I'm not sure I follow you here. Are you saying that OOXML has proprietary MS formats for its binary data? I was led to believe OOXML follows the Open Packaging Convention which, although written by Microsoft, is amazingly similar to ODF's packaging; both being, essentially, a zip collection of XML files and binary files, the binary files being images, movies, or code.
What proprietary binary blobs are you talking about? Now, I'll admit that you could embed, say, a.WMV file in an OOXML file, which is a proprietary Microsoft binary blob, but you could also embed that.WMV file in an ODF file. Or you could embed a.MOV file in either format, which is a proprietary Apple binary blob.
Who else will ever be able to read MS-OOXML?
Anybody with a zip tool like GZIP or WinZip and a text reader like EMACS or Notepad.
Who else will be able to write to it?
See above.
Only Microsoft.
Again, I'd like to know what those proprietary binary blobs are. If they exist, sure, you might be right. But all evidence is to the contrary.
At least when you are talking about xhtml or html5 it is possible to create a browser that can read and render both formats.
And it's quite possible to create a word processor that can read, write, and render both ODF and OOXML. Hell, both MicrosoftandSun have plugins for Word 2007 that do that. Are they full translations? Probably not always, 'cause there *are* major differences in the way things are organized in the schema.
But they do render the issue moot, in my opinion, hence my original "Meh" post. What do I really care, as a consumer? Not a hell of a lot -- I can work with either format I choose, and as long as I don't need the fancy bells and whistles that don't translate well, I can translate between them pretty much without pain.
What do I really care as a programmer? Not a lot, as long as I can figure out the XML schema for either format when I need to mess with them. Thankfully, there is plenty of documentation on both sides on the subject. I already have the tools to get into both formats, in the form of zip reading code and XML parsers. Will I get more pain trying to program against OOXML? Probably, because it's a more complex format. Does that really matter in the long run?
It is important because the ODF standard came first, yet Microsoft blatantly choose to, once again, ignore an established standard in favor of their own solution.
So? How many folks fork open source projects because it doesn't fit their needs? How many just do it their own way themselves? MySQL is open source... PostgresSQL is open source... should I stick to MySQL just because it came first? (Ignore the fact that Postgres came first, please.:) ) <Br/><br/>
Have you looked into the whole HTML 5 vs XHTML 2 debate? ODF vs OOXML is pretty much the same thing. As long as they're both standards and both standards are supported by browsers, does it really matter if one wins over the other? <br/><br/>
Not really. Why? Because there will be HTML 6 or XHTML 3. There will be ODF 2 or OOXML 2. Or something else. It doesn't really matter all that much, and arguing about it ad nauseum doesn't do all that much. Get busy with the conversion and move on, says I.
I'm tired of the whole OOXML/ODF pissing match. Who cares? I mean, really, they both do almost exactly the same thing, in almost exactly the same way. The only real difference is the XML schema, and do I really, either as a consumer or as a programmer, care about that?
Not really. There are tools for writing and converting back and forth for both. They're both open standards which any party can use. Well, open enough -- do I really care who who controls modifications to it?
Not really. This is even less relevant than the HD-DVD/Blu-ray war. At least that is important because it decides who gets royalties. Does either party get royalties for the use of their format?
Not really. Sure, there's the my tool vs your tool thing, but do I, as a consumer, care about that?
This sounds like the Mother of All Backwards and Cross-Platform Incompatibilities -- especially since there appears to be no transition period where both the old and new scripting languages will be simultaneously supported. And as past experience with Visual Studio.NET has shown, upgrade tools are far less than perfect.
For those interested in, say, accuracy:
Microsoft has concurrently supported VSTO and VBA since Office 2003.
VSTA, however is a different beast, indeed, it's an entirely different way of doing things, completely unrelated to the extensions you get from VBA. The upgrade path is via VSTO, and yes, Microsoft has been providing that path for years.
MFC is actually a great way to build windows applications in C++, provided you absolutely love and worship pseudo-Hungarian notation, which I in fact hate.
Note that ROW_NUMBER() is only available in SQL Server 2005. In SQL Server 2000, you had to do a TOPped TOPped subselect, which was fast for early pages (depending on the query) but DAMN SLOW when you wanted, later pages.
Um, why would you *want* the bug to be in the runtime such that it would be a widespread issue?
I have to wonder if you've been living under a rock or something. This is SLASHDOT! Obviously, he wants it to be a bug because it's popular on Slashdot to hate Microsoft. Typically, this is done with references to the Borg, or (the one that really makes them cry) replacing the 's' character with a '$' character, like this: M$. Micro$oft.
I think the problem is that in order to create the propulsion, the laser has to *hit* the craft, not be directed away from it. If I read this correctly, the heat questioned in the grandparent post comes not from powering the laser but from the laser beam smacking against the drive plate.
And given the lack of atmosphere, a heat sink wouldn't help much. The only way to dissipate the heat would be through radiation, and that's slow compared to convection.
The question is, of course, is this really an issue? How much heat is generated from the laser blasting against the drive plate? How quickly will the heat be dissipated?
Have you ever looked at your cell phone after using it on a hot, sunny day?
Yeah, telephone sanitation ain't all *that* bad. 'Course, they make wipes for that now, so we can still safely cut out the middlemen -- as long as we're not too busy dreaming stuff up and doing stuff to remember to wipe our phones...
They immediately ran a catheter up my groin, into my heart, and attached to an external pace-maker.
Wait, what? OUfrigginCH!
Seriously, do you even *have* a direct pathway from your penis to your heart? Wouldn't a catheter break something if it went straight to your heart? If so, why not just go through the chest?
Emperor Palpatine has this to say about your lack of funny: Uh-DUUUUUHHHH
Seriously, though, Lucas has apparently stated that he took the Endosymbiotic theory as inspiration for midichlorians, so the grandparent's ob-quote isn't that far off.
I stopped reading after the first paragraph. A tablet? Orders of magnitude more expensive? What?
That was hardly a good reason to stop reading any of the articles. You yourself mentioned that you don't like using a tablet as an input device, and I don't blame you -- I don't draw and can't stand using a pen for anything other than drawing. The article is about how we software dudes over-use mouse input, and does a fair job backing that point up, regardless of the "an order of magnitude" hyperbole.
That said, the hyperbole isn't that far from the truth. Let's look at the math, and since TFA was talking USian, and since Euros are worth like 30% more than U.S. Dollars, let's normalize the costs. For the sake of argument, let's use values from the manufacturer's online American-version store, rather than third-party distributors, and let's ignore shipping costs. Yes, the items in question are likely cheaper elsewhere.
The cheapest digital tablet direct from WACOM costs a hundred bucks (99.95 U.S. Dollars). In contrast, the cheapest non-travel mouse from Logitec runs around fifteen bucks (14.95 U.S. Dollars). A tablet is nearly 7 times more expensive than a mouse in U.S. dollars. Now, you're right, that's not exactly a full order of magnitude difference, but it is two thirds of an order of magnitude difference, and that's strong enough to support a slight exaggeration, regardless of the veracity of the claim that a tablet is a better input device than a mouse.
Slashdot Mirror
Oh, and you'd sing the verses out of order.
I hear even MySQL supports stored procedures now, so I don't see what the problem is, other than millions of lines of sloppy existing code that won't die. But the "fix" has always been there.
Even stored procedures are vulnerable to SQL injection.The 100% certified, etc., solution is to not use a text-based query language.
Of course, then you lose the massive forms of flexibility that SQL gives you.
I have to say this is the most succinct explanation of why SQL Server is specifically vulnerable to the attack. It's certainly something for Microsoft to look at the next time they look into modifying T-SQL.
I do not, however, think this rises to the level of actually being able to blame Microsoft for the attack. The fault there lies 100% on the shoulders of programmers who did not use the tools available to them to eliminate SQL injection.
The structure of T-SQL did allow the hackers to add the javascript to every text field in the database, yes. But the fact that they were able to allow javascript to *any* text field is entirely the fault of the site programmers.
If it's a Backronym, it's crap.
Seriously, though, the AMD/Intel wars are long over. Is "chip piracy" really an issue?
Jeff Atwood had an interesting article on the subject a couple weeks ago. It generated a metric buttload of comments, so you might consider mining for ideas there.
Sometimes I wish the documentation at my current job came even *close* to the amount of detail provided by MSDN. Ok, scratch that. *EVERY DAY* I wish the documentation at my current job came even close to the amount of detail provided by MSDN.
What proprietary binary blobs are you talking about? Now, I'll admit that you could embed, say, a
But they do render the issue moot, in my opinion, hence my original "Meh" post. What do I really care, as a consumer? Not a hell of a lot -- I can work with either format I choose, and as long as I don't need the fancy bells and whistles that don't translate well, I can translate between them pretty much without pain.
What do I really care as a programmer? Not a lot, as long as I can figure out the XML schema for either format when I need to mess with them. Thankfully, there is plenty of documentation on both sides on the subject. I already have the tools to get into both formats, in the form of zip reading code and XML parsers. Will I get more pain trying to program against OOXML? Probably, because it's a more complex format. Does that really matter in the long run?
Not really.
I'm tired of the whole OOXML/ODF pissing match. Who cares? I mean, really, they both do almost exactly the same thing, in almost exactly the same way. The only real difference is the XML schema, and do I really, either as a consumer or as a programmer, care about that?
Not really. There are tools for writing and converting back and forth for both. They're both open standards which any party can use. Well, open enough -- do I really care who who controls modifications to it?
Not really. This is even less relevant than the HD-DVD/Blu-ray war. At least that is important because it decides who gets royalties. Does either party get royalties for the use of their format?
Not really. Sure, there's the my tool vs your tool thing, but do I, as a consumer, care about that?
Not really.
Microsoft has concurrently supported VSTO and VBA since Office 2003.
VSTA, however is a different beast, indeed, it's an entirely different way of doing things, completely unrelated to the extensions you get from VBA. The upgrade path is via VSTO, and yes, Microsoft has been providing that path for years.
MFC is actually a great way to build windows applications in C++, provided you absolutely love and worship pseudo-Hungarian notation, which I in fact hate.
Note that ROW_NUMBER() is only available in SQL Server 2005. In SQL Server 2000, you had to do a TOPped TOPped subselect, which was fast for early pages (depending on the query) but DAMN SLOW when you wanted, later pages.
Whiskey Tango Foxtrot? Over.
A statement like that is worse than failure.
Great... the new face of internet delivery services is actually an ass.
I think the problem is that in order to create the propulsion, the laser has to *hit* the craft, not be directed away from it. If I read this correctly, the heat questioned in the grandparent post comes not from powering the laser but from the laser beam smacking against the drive plate.
And given the lack of atmosphere, a heat sink wouldn't help much. The only way to dissipate the heat would be through radiation, and that's slow compared to convection.
The question is, of course, is this really an issue? How much heat is generated from the laser blasting against the drive plate? How quickly will the heat be dissipated?
Have you ever looked at your cell phone after using it on a hot, sunny day?
Yeah, telephone sanitation ain't all *that* bad. 'Course, they make wipes for that now, so we can still safely cut out the middlemen -- as long as we're not too busy dreaming stuff up and doing stuff to remember to wipe our phones...
Seriously, do you even *have* a direct pathway from your penis to your heart? Wouldn't a catheter break something if it went straight to your heart? If so, why not just go through the chest?
Seriously, though, Lucas has apparently stated that he took the Endosymbiotic theory as inspiration for midichlorians, so the grandparent's ob-quote isn't that far off.
That said, the hyperbole isn't that far from the truth. Let's look at the math, and since TFA was talking USian, and since Euros are worth like 30% more than U.S. Dollars, let's normalize the costs. For the sake of argument, let's use values from the manufacturer's online American-version store, rather than third-party distributors, and let's ignore shipping costs. Yes, the items in question are likely cheaper elsewhere.
The cheapest digital tablet direct from WACOM costs a hundred bucks (99.95 U.S. Dollars). In contrast, the cheapest non-travel mouse from Logitec runs around fifteen bucks (14.95 U.S. Dollars). A tablet is nearly 7 times more expensive than a mouse in U.S. dollars. Now, you're right, that's not exactly a full order of magnitude difference, but it is two thirds of an order of magnitude difference, and that's strong enough to support a slight exaggeration, regardless of the veracity of the claim that a tablet is a better input device than a mouse.
Thanks, you've just given me an idea for next week's D&D game. :D