I know this is/. and we rabble rabble hate M$$$$$ rabble, but can someone point me to another company that actually applauded the hackers who jailbroke their hardware? The standard reaction is quite the opposite.
I don't think you got my point, which is that strongly typed languages and APIs do not "mitigate SQL injections. Completely." You don't understand software security, do you?
At this point does any tech savvy user still have the Java Runtime Environment installed? These days it doesn't seem to be good for much beyond extremely reliable arbitrary remote code execution.
The suggestion of the GP to work around the issues of one framework's security by using an even more closed framework is naive at best. I like the.NET stack, even more with ASP.Net MVC, LINQ etc. But it isn't the end-all, be-all by a long shot. Every language/platform I've used has me longing at times for something else that does X, Y or Z easier/better.
I overlooked this comment. Anyway, I did not suggest that EF was some end-all-be-all solution to security, because it is certainly not that. But if you're developing with ASP.NET, it's a safe bet that Microsoft's flagship ORM is going to play nicely with it, very nicely. LINQ-to-Entities with SQL offers a extremely pleasant experience, with the declarative style closely mirroring that of the SQL the queries are compiled into. This leads to cleaner, more concise code as opposed to other ORMs like Hibernate/NHibernate. And of course because you're writing strongly typed queries, the chances of SQL injection vulnerabilities are cut down dramatically. This should not be used as a crutch, and for reasons I've mentioned elsewhere in this thread SQL injection can still occur in just about all ORMs. There's no substitute for actually understanding software vulnerabilities, but don't be so quick to discount class-wide mitigations; they have proven to be effective in protecting end-users when developers make mistakes.
Like Entity Framework, which I mentioned in my previous post? And be careful of absolutes when you're talking about security. Out of necessity, most ORMs offer ways to execute queries constructed via string concatenation and thus SQL injection can still occur.
If this is some sort of eink display as it appears to be, it is going to be useless for anything but reading, and personally I don't want my reader bending and contorting like a flimsy piece of paper. But hey, at least I could lay a bunch of these things out to view large monochrome images or something.
Let's see how well console gamers handle having to deal with minimum/recommended requirements and upgrading. What advantage does this offer over a PC, again?
Parameterized queries used correctly mitigate SQL, but guess what? It's surprisingly easy to use them wrong, resulting in a false sense of security and vulnerable code.
If the current leader, the 360, is a zombie, then the same is even more true for the PS3.
For Microsoft it wasn’t until 2008 that it began to see an upturn, while for Sony it wasn’t until 2010.
However despite these late improvements, it doesn’t even come close to making a dent in the expenditure. In total Microsoft saw a loss of just under $3 billion, while Sony accounts for much more of the total, itself racking up losses of just less than $5 billion.
Sorry buddy, but MS won. And while I don't regularly play games on the 360, I've found some of the titles to be enjoyable while remaining quite fit.
Funny you say that because the console to kill is Microsoft's. But anyway, he is right, the PC running Microsoft Windows will be superior to consoles for the foreseeable future.
After all, if these little boxes can simply stream from powerful servers, how can the stalwarts of gaming keep up?
Assuming streaming is the future of gaming (and I don't think it is at all) the major players could keep up and surpass the little guys by simply buying more powerful servers.
I frequently find myself writing native code, but bytecode does have its place.
The problem with that sort of bytecode is that it has no advantages over native code.
This is not entirely true. One advantage bytecode has is that it can be Just In Time compiled into native object code that is optimized for the specific architecture. This is less cumbersome than dealing with architecture specific blobs or recompiling source. Also,.NET assemblies contain pretty much all of the type metadata necessary to decompile them into extremely readable high level languages e.g. C# or VB.NET. Because of this, unless they're obfuscated,.NET assemblies are effectively open source.
Good job handwaving away Mono. I can see how you'd be forced to, since it undermines your entire argument. Mono supports most of the BCL, all the way up to.NET 4.5. Again, please take the time to understand what you're talking about.
http://www.mono-project.com/Compatibility
You are referring to the.NET Base Class Library, which is completely independent from the language. Just because it is frequently used with C# does not make the language itself proprietary, nor are languages "nothing." If they were we wouldn't fight so much over which one to choose. While API is important, your statement that "It's the libraries that matter" makes me question your skill as a programmer.
Microsoft only languages just can't compete. [...] Is there even a VB for WP?
Maybe you should take the time to understand how these things work before you make sweeping generalizations like this. C#, VB et al compile into Common Intermediate Language (CIL) bytecode, which is platform independent. Windows Phone uses the Common Language Runtime (CLR) to execute said bytecode, so yes, there is "a VB for WP", just like there can be an any-other-language-you-want for WP, provided a compiler that emits CIL object code is available.
Slashdot Mirror
In C#, var is used to declare implicitly typed variables. They're still strongly typed.
Yeah, I remember that time reflection based vulnerabilities in .NET were used in ~50% of cyber attacks. Oh, wait...
I know this is /. and we rabble rabble hate M$$$$$ rabble, but can someone point me to another company that actually applauded the hackers who jailbroke their hardware? The standard reaction is quite the opposite.
Great, then you should have no problem understanding why I took issue with your claim. Very difficult <> impossible.
I don't think you got my point, which is that strongly typed languages and APIs do not "mitigate SQL injections. Completely." You don't understand software security, do you?
At this point does any tech savvy user still have the Java Runtime Environment installed? These days it doesn't seem to be good for much beyond extremely reliable arbitrary remote code execution.
The suggestion of the GP to work around the issues of one framework's security by using an even more closed framework is naive at best. I like the .NET stack, even more with ASP.Net MVC, LINQ etc. But it isn't the end-all, be-all by a long shot. Every language/platform I've used has me longing at times for something else that does X, Y or Z easier/better.
I overlooked this comment. Anyway, I did not suggest that EF was some end-all-be-all solution to security, because it is certainly not that. But if you're developing with ASP.NET, it's a safe bet that Microsoft's flagship ORM is going to play nicely with it, very nicely. LINQ-to-Entities with SQL offers a extremely pleasant experience, with the declarative style closely mirroring that of the SQL the queries are compiled into. This leads to cleaner, more concise code as opposed to other ORMs like Hibernate/NHibernate. And of course because you're writing strongly typed queries, the chances of SQL injection vulnerabilities are cut down dramatically. This should not be used as a crutch, and for reasons I've mentioned elsewhere in this thread SQL injection can still occur in just about all ORMs. There's no substitute for actually understanding software vulnerabilities, but don't be so quick to discount class-wide mitigations; they have proven to be effective in protecting end-users when developers make mistakes.
Like Entity Framework, which I mentioned in my previous post? And be careful of absolutes when you're talking about security. Out of necessity, most ORMs offer ways to execute queries constructed via string concatenation and thus SQL injection can still occur.
If this is some sort of eink display as it appears to be, it is going to be useless for anything but reading, and personally I don't want my reader bending and contorting like a flimsy piece of paper. But hey, at least I could lay a bunch of these things out to view large monochrome images or something.
Just what my oven needs: a hopelessly fragmented, privacy invading, bug riddled operating system.
The 360 has been the top selling console for almost a year and a half now. Keep grasping.
Let's see how well console gamers handle having to deal with minimum/recommended requirements and upgrading. What advantage does this offer over a PC, again?
Amen brother. My passion for LINQ runs deep.
Parameterized queries used correctly mitigate SQL, but guess what? It's surprisingly easy to use them wrong, resulting in a false sense of security and vulnerable code.
Laugh it up buddy, but LINQ to Entities largely eliminates SQL injection in ASP.NET web applications.
For Microsoft it wasn’t until 2008 that it began to see an upturn, while for Sony it wasn’t until 2010. However despite these late improvements, it doesn’t even come close to making a dent in the expenditure. In total Microsoft saw a loss of just under $3 billion, while Sony accounts for much more of the total, itself racking up losses of just less than $5 billion.
Sorry buddy, but MS won. And while I don't regularly play games on the 360, I've found some of the titles to be enjoyable while remaining quite fit.
Funny you say that because the console to kill is Microsoft's. But anyway, he is right, the PC running Microsoft Windows will be superior to consoles for the foreseeable future.
After all, if these little boxes can simply stream from powerful servers, how can the stalwarts of gaming keep up?
Assuming streaming is the future of gaming (and I don't think it is at all) the major players could keep up and surpass the little guys by simply buying more powerful servers.
You go right on running that itsy bitsy percentile of .Net applications that actually work with Mono
Oh look, an end-user. Pretty much everything I write except the WPF stuff is mono compatible, so yes, I will go right on.
The problem with that sort of bytecode is that it has no advantages over native code.
This is not entirely true. One advantage bytecode has is that it can be Just In Time compiled into native object code that is optimized for the specific architecture. This is less cumbersome than dealing with architecture specific blobs or recompiling source. Also, .NET assemblies contain pretty much all of the type metadata necessary to decompile them into extremely readable high level languages e.g. C# or VB.NET. Because of this, unless they're obfuscated, .NET assemblies are effectively open source.
So I take it you have the same problems with Java, since it uses an even more inefficient virtual machine, right?
Good job handwaving away Mono. I can see how you'd be forced to, since it undermines your entire argument. Mono supports most of the BCL, all the way up to .NET 4.5. Again, please take the time to understand what you're talking about.
http://www.mono-project.com/Compatibility
You are referring to the .NET Base Class Library, which is completely independent from the language. Just because it is frequently used with C# does not make the language itself proprietary, nor are languages "nothing." If they were we wouldn't fight so much over which one to choose. While API is important, your statement that "It's the libraries that matter" makes me question your skill as a programmer.
Microsoft only languages just can't compete. [...] Is there even a VB for WP?
Maybe you should take the time to understand how these things work before you make sweeping generalizations like this. C#, VB et al compile into Common Intermediate Language (CIL) bytecode, which is platform independent. Windows Phone uses the Common Language Runtime (CLR) to execute said bytecode, so yes, there is "a VB for WP", just like there can be an any-other-language-you-want for WP, provided a compiler that emits CIL object code is available.
If a simple tab control is all you're after JQuery UI is rather nice, as far as JavaScript goes.