Amazing, I wonder what advertising platform paid for the Internet before this generation of marketers declared themselves essential to pay for the Internet? I can host a website for $4.99 a month, buy a Linux VM for $20 a month. Plenty of content is made by people not paid by your advertising dollars. Advertisers, we don't need you, don't test us.
Spoiler, for those of you who haven't read the books, stop reading here.
This isn't going to work. There will not be a significant number of people who purchase this Mozilla phone. Mozilla phone will have less sales than Zune.
I find it funny that nobody brings up Launchpad on OSX. Not that OSX forces Launchpad on you, but it is similar in that it's essentially a full screen start menu with an app-like interface on a desktop OS.
How about the same thing the factory worker does when he's replaced by automation or his job is outsourced to cheaper labor markets. Survive. Adapt. Why is it so unthinkable that highly educated people would be put out of work by progress, instead of simply the low wage laborers?
Wow, that's funny. I must be on acid, because I thought I just compiled a.NET app in Visual Studio, copied it to Linux, and literally ran the Portable Executable file (.EXE) with Mono.
"Probably you would have to code in a subset of Mono, this coupled with the fact that Mono will always play catch up to.NET means that developing cross-platform apps in Mono will always place severe restrictions on you."
CodeContracts - API complete, partial tooling EntityFrameworks - Not available. Server-side OData - Depends on Entity Framework. WCF - silverlight 2.0 subset completed WPF - no plans to implement WF - Will implement WF 4 instead on future versions of Mono. System.Management - does not map to Linux System.EnterpriseServices - deprecated
So other than the above Microsoft specific technology plus Entity Framework (use NHibernate instead), the entire C# 4.0,.NET 4.0, and ASP.NET 4.0 platforms are supported. Oh, and what really matters is ISO/IEC 23271:2006 and ISO/IEC 23270:2006... you know the ISO standards that Mono implements.
So basically, your entire point against Mono as a multi-platform solution for ISO standards based.NET development is bullshit. The few libraries that are limited on Mono aren't that critical for applications, web, or backend development. WinForms is supported, ASP.NET is supported, and services (as console apps) are supported.
Yeah those Mono license fees are expensive. Almost wiped out my company with those fees. It's not like they have.NET 2 through.NET 4 implemented in Mono for free, which you can run on Linux or Windows. Idiot.
Are you serious? We abandoned C++ Builder for Visual Studio and C#.NET and every other developer meeting we're praising the flying spaghetti monster that we did. The massive reduction in defects and the massive improvement in productivity were huge for our team. C++ Builder is great for breaking compatibility with every release (we owned literally every version up to XE), the IDE and/or compiler crashing at random intervals or producing broken code that itself crashes at random intervals. Plus you're serious about real code when you're talking about writing software that's based on the VCL?
Oh and by the way, a base class library that requires you to *new* every BCL object but doesn't have garbage collection, simply begs for access violations and memory leaks. Simply idiotic. You couldn't pay us to switch back.
As a bonus, we can compile our.NET binaries to native code with one drop down box selection, rather than code that pushes all of our data through a Delphi interface and back and beats the hell out of a shitty heap implementation. At least they switched to a 3rd party C++ STL implementation rather than their own buggy garbage.
Microsoft hasn't abandoned DOS or Win16???? Have you tried running a DOS program or a Windows 3.x program in Windows 7? I think you'll find that your information is more than a little out of date.
And NT was a complete and total abandonment of the Windows 9x codebase. The entire OS was rewritten from scratch in C, an entire NT API exists under the hood that powers that OS, and then the Win32 API/ABI was added as a compatibility layer on top of that OS. As was their POSIX and OS/2 compatibility layer.
I know you probably can't be bothered to validate what you're saying before you say it, but perhaps a little bit of Google is in order before you spout off? Or try running a DOS app. Or something. Or let the grown ups talk.
I hate having to explain this to non-.NET developers over and over again. Try to follow along.
In Visual Studio, if you select x86 or x64 or Itanium as your target instruction set, CIL (formerly MSIL) is not generated. NATIVE machine language is generated, doing the job that the JIT would normally do. You with me so far? You can target native platforms, and produce native code.
Beyond that, if you do choose to generate an "Any CPU" binary,.NET caches all of its JIT compiles in the GAC. Thus for a particular platform, the CIL is only compiled into native code ONCE. The second time the code is executed, even between shutdowns and reboots, the native code is executed. You can read more about the GAC here:
Your argument is like saying, because you have to run a tarball of source through./configure && make once on a particular platform, the code is interpreted. That's ridiculous. Interpreted code is read by an interpreter AT runtime. Deferring final compilation to 0.01 seconds before the program entrypoint is executed doesn't mean a program is interpreted. What actually executes at runtime is native x86 or x64 or Itanium assembly language, generated exactly once.
Again, *know* what you're talking about. We're not talking about just any generic theoretical JIT. We're talking about the.NET CLR which *does* cache all of the JIT compiles in the GAC. Here, let me help you know more about what you're talking about: http://en.wikipedia.org/wiki/Global_Assembly_Cache
.NET is a great platform, and C# is a great language. All of this.NET hate from anti-Microsoft types with no knowledge of the platform is just about as useful as all of the patent fear-mongering associated with Mono. Anything Microsoft invents, these people are going to try to tear down, whether it's a good innovation or a bad one.
Except AJAX of course. They just pretend Microsoft didn't invent XMLHttpRequest or iframe.
How exactly is.NET interpreted? CIL (formerly MSIL) is JIT compiled, just like Java is. The JIT compiles of assemblies are cached in the GAC, so it only happens once. After that it's native code for the platform you're running on, whether that's 32bit Intel, 64bit Intel, or Itanium. Or you can choose a specific platform in Visual Studio and compile directly to that platform and avoid the intermediate language altogether. From your description of.NET it seems like you have no knowledge of the platform.
Non-Affected Software Windows 7 for 32-bit Systems Windows 7 for x64-based Systems Windows Server 2008 R2 for x64-based Systems Windows Server 2008 R2 for Itanium-based Systems
Direct2D and Direct3D are a part of the "hardware graphics calls in Windows". The fact that it's not in the GDI/GDI+ libraries doesn't change that. DirectX ships with the OS, is required for the OS to function, and thus DirectX IS literally one of the OS APIs for rendering graphics.
At the same time as people like you are grousing about how the web isn't composed of static HTML and GIF files anymore, we have the web developers of the world going on about the need for supporting HTML 5 canvas, video, and SVG. Microsoft decides that it makes sense to do all of those things with hardware acceleration, making use of the expensive video card many of us have paid for, and this is somehow their fault? Microsoft isn't the one pushing canvas, video, and SVG, they're just responding to the web moving in that direction.
This may shock you, but Firefox, Chrome, and Safari for Windows all take advantage of another proprietary API... Win32 API. Or to be more specific, GDI. The fact that Microsoft is using DirectX rather than GDI doesn't change anything. It's not an open source application and it doesn't support multiple platforms. What APIs they use internally is of no relevence to the merits of IE9 as a Windows based browser, and it's performance.
It's not like Firefox, Chrome, and Safari are all taking the (ridiculous) high road you're implying by doing 100% of their rendering in OpenGL currently. They're using a proprietary Microsoft API.
Managed code is the future. Doesn't matter if it's C#.NET, VB.NET, Java, Python, or something else. The languages save as intermediate language or bytecode, but in the end they're cached as platform specific optimized native code. The performance is very near that of the most optimal C. As our hardware power increases thanks to crazy leaps in processor and memory performance (thank you Nehalem) the costs of managed code performance are being minimized. And what is it that slows managed code anyway except for the checks that you should be hand coding in your C? Those same checks that prevent these kinds of attacks on a managed application.
I was a C developer for years who focused on writing the highest performance code at every turn. And for kernels, drivers, and maybe the highest performance demanding services, properly written C may be the right answer. But for many services and almost all applications, there is absolutely no reason I can see why a managed language shouldn't be used. There will still be security flaws but they will be much fewer and far between.
Slashdot Mirror
You think that's bad, try Kings Quest 5, the last version offered on floppy disk. Shit's ridiculous, and then one of the floppies goes bad.
Amazing, I wonder what advertising platform paid for the Internet before this generation of marketers declared themselves essential to pay for the Internet? I can host a website for $4.99 a month, buy a Linux VM for $20 a month. Plenty of content is made by people not paid by your advertising dollars. Advertisers, we don't need you, don't test us.
Spoiler, for those of you who haven't read the books, stop reading here.
This isn't going to work. There will not be a significant number of people who purchase this Mozilla phone. Mozilla phone will have less sales than Zune.
No offense, but it seems like your understanding of the Supremacy Clause is somewhat lacking.
http://en.wikipedia.org/wiki/Supremacy_Clause
This isn't just in theory, look what happened to Qwest when they dared to disagree.
I find it funny that nobody brings up Launchpad on OSX. Not that OSX forces Launchpad on you, but it is similar in that it's essentially a full screen start menu with an app-like interface on a desktop OS.
or aliens or robots from the future... whatever, fuck you! You'll watch it anyway.
How can that be true? If Steve Jobs is living tissue over metal endoskeleton, he should last 120 years with his existing power cell...
How about the same thing the factory worker does when he's replaced by automation or his job is outsourced to cheaper labor markets. Survive. Adapt. Why is it so unthinkable that highly educated people would be put out of work by progress, instead of simply the low wage laborers?
"This article is based on a prerelease version of the .NET Framework 2.0"
Can I recommend that you find a slightly newer source?
"Mono can't run .NET apps."
Wow, that's funny. I must be on acid, because I thought I just compiled a .NET app in Visual Studio, copied it to Linux, and literally ran the Portable Executable file (.EXE) with Mono.
"Probably you would have to code in a subset of Mono, this coupled with the fact that Mono will always play catch up to .NET means that developing cross-platform apps in Mono will always place severe restrictions on you."
Let's see how true this is:
http://mono-project.com/Compatibility
So here's what's missing:
CodeContracts - API complete, partial tooling
EntityFrameworks - Not available.
Server-side OData - Depends on Entity Framework.
WCF - silverlight 2.0 subset completed
WPF - no plans to implement
WF - Will implement WF 4 instead on future versions of Mono.
System.Management - does not map to Linux
System.EnterpriseServices - deprecated
So other than the above Microsoft specific technology plus Entity Framework (use NHibernate instead), the entire C# 4.0, .NET 4.0, and ASP.NET 4.0 platforms are supported. Oh, and what really matters is ISO/IEC 23271:2006 and ISO/IEC 23270:2006... you know the ISO standards that Mono implements.
So basically, your entire point against Mono as a multi-platform solution for ISO standards based .NET development is bullshit. The few libraries that are limited on Mono aren't that critical for applications, web, or backend development. WinForms is supported, ASP.NET is supported, and services (as console apps) are supported.
Yeah those Mono license fees are expensive. Almost wiped out my company with those fees. It's not like they have .NET 2 through .NET 4 implemented in Mono for free, which you can run on Linux or Windows. Idiot.
Are you serious? We abandoned C++ Builder for Visual Studio and C# .NET and every other developer meeting we're praising the flying spaghetti monster that we did. The massive reduction in defects and the massive improvement in productivity were huge for our team. C++ Builder is great for breaking compatibility with every release (we owned literally every version up to XE), the IDE and/or compiler crashing at random intervals or producing broken code that itself crashes at random intervals. Plus you're serious about real code when you're talking about writing software that's based on the VCL?
Oh and by the way, a base class library that requires you to *new* every BCL object but doesn't have garbage collection, simply begs for access violations and memory leaks. Simply idiotic. You couldn't pay us to switch back.
As a bonus, we can compile our .NET binaries to native code with one drop down box selection, rather than code that pushes all of our data through a Delphi interface and back and beats the hell out of a shitty heap implementation. At least they switched to a 3rd party C++ STL implementation rather than their own buggy garbage.
Microsoft hasn't abandoned DOS or Win16???? Have you tried running a DOS program or a Windows 3.x program in Windows 7? I think you'll find that your information is more than a little out of date.
And NT was a complete and total abandonment of the Windows 9x codebase. The entire OS was rewritten from scratch in C, an entire NT API exists under the hood that powers that OS, and then the Win32 API/ABI was added as a compatibility layer on top of that OS. As was their POSIX and OS/2 compatibility layer.
I know you probably can't be bothered to validate what you're saying before you say it, but perhaps a little bit of Google is in order before you spout off? Or try running a DOS app. Or something. Or let the grown ups talk.
I hate having to explain this to non-.NET developers over and over again. Try to follow along.
In Visual Studio, if you select x86 or x64 or Itanium as your target instruction set, CIL (formerly MSIL) is not generated. NATIVE machine language is generated, doing the job that the JIT would normally do. You with me so far? You can target native platforms, and produce native code.
Beyond that, if you do choose to generate an "Any CPU" binary, .NET caches all of its JIT compiles in the GAC. Thus for a particular platform, the CIL is only compiled into native code ONCE. The second time the code is executed, even between shutdowns and reboots, the native code is executed. You can read more about the GAC here:
http://en.wikipedia.org/wiki/Global_Assembly_Cache
Your argument is like saying, because you have to run a tarball of source through ./configure && make once on a particular platform, the code is interpreted. That's ridiculous. Interpreted code is read by an interpreter AT runtime. Deferring final compilation to 0.01 seconds before the program entrypoint is executed doesn't mean a program is interpreted. What actually executes at runtime is native x86 or x64 or Itanium assembly language, generated exactly once.
Again, *know* what you're talking about. We're not talking about just any generic theoretical JIT. We're talking about the .NET CLR which *does* cache all of the JIT compiles in the GAC. Here, let me help you know more about what you're talking about: http://en.wikipedia.org/wiki/Global_Assembly_Cache
.NET is a great platform, and C# is a great language. All of this .NET hate from anti-Microsoft types with no knowledge of the platform is just about as useful as all of the patent fear-mongering associated with Mono. Anything Microsoft invents, these people are going to try to tear down, whether it's a good innovation or a bad one.
Except AJAX of course. They just pretend Microsoft didn't invent XMLHttpRequest or iframe.
How exactly is .NET interpreted? CIL (formerly MSIL) is JIT compiled, just like Java is. The JIT compiles of assemblies are cached in the GAC, so it only happens once. After that it's native code for the platform you're running on, whether that's 32bit Intel, 64bit Intel, or Itanium. Or you can choose a specific platform in Visual Studio and compile directly to that platform and avoid the intermediate language altogether. From your description of .NET it seems like you have no knowledge of the platform.
Insightful? Come on mods, do better.
No, as you can see from the following, the standard Win32 message pump isn't an infinite loop...
while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
Non-Affected Software
Windows 7 for 32-bit Systems
Windows 7 for x64-based Systems
Windows Server 2008 R2 for x64-based Systems
Windows Server 2008 R2 for Itanium-based Systems
Direct2D and Direct3D are a part of the "hardware graphics calls in Windows". The fact that it's not in the GDI/GDI+ libraries doesn't change that. DirectX ships with the OS, is required for the OS to function, and thus DirectX IS literally one of the OS APIs for rendering graphics.
At the same time as people like you are grousing about how the web isn't composed of static HTML and GIF files anymore, we have the web developers of the world going on about the need for supporting HTML 5 canvas, video, and SVG. Microsoft decides that it makes sense to do all of those things with hardware acceleration, making use of the expensive video card many of us have paid for, and this is somehow their fault? Microsoft isn't the one pushing canvas, video, and SVG, they're just responding to the web moving in that direction.
This may shock you, but Firefox, Chrome, and Safari for Windows all take advantage of another proprietary API... Win32 API. Or to be more specific, GDI. The fact that Microsoft is using DirectX rather than GDI doesn't change anything. It's not an open source application and it doesn't support multiple platforms. What APIs they use internally is of no relevence to the merits of IE9 as a Windows based browser, and it's performance.
It's not like Firefox, Chrome, and Safari are all taking the (ridiculous) high road you're implying by doing 100% of their rendering in OpenGL currently. They're using a proprietary Microsoft API.
Managed code is the future. Doesn't matter if it's C# .NET, VB .NET, Java, Python, or something else. The languages save as intermediate language or bytecode, but in the end they're cached as platform specific optimized native code. The performance is very near that of the most optimal C. As our hardware power increases thanks to crazy leaps in processor and memory performance (thank you Nehalem) the costs of managed code performance are being minimized. And what is it that slows managed code anyway except for the checks that you should be hand coding in your C? Those same checks that prevent these kinds of attacks on a managed application.
I was a C developer for years who focused on writing the highest performance code at every turn. And for kernels, drivers, and maybe the highest performance demanding services, properly written C may be the right answer. But for many services and almost all applications, there is absolutely no reason I can see why a managed language shouldn't be used. There will still be security flaws but they will be much fewer and far between.
Yeah, because Firefox's exploit stats aren't worse than any other modern browser right? Maybe you need to do a little research.