.NET 3.0 is not part of the standard. Half of the.NET developers out there target.NET 3.0. Unless they restrict themselves to the parts covered by.NET 2.0, they WILL be using non-standardized extensions. What is worse is the fact that MSDN actively encourages developers to use non-standardized stuff.
As hard as it might be to believe, historically most Windows developers didn't really give a S*** whether their applications worked on Linux or not.
What makes you think that it is hard to believe? It is well known that an overwhelming majority of Windows developers don't care about portability. None of the C++/Windows developers among my friends really know or care about what "ISO C++" means. To them, "C++" means opening M$ Visual Studio IDE and coding according to the specifications of Visual Studio Help or MSDN.
Hey, I have no complaints against Mono. Those poor guys are doing a lot of hard work. And they've done great so far. My complaints are against.NET as a whole. My chief complaint is that neither the Mono team nor the programmers who write.NET/Mono applications seem to realize that Mono is always going to be a second class citizen and always playing catch-up no matter how competent the Mono team is. Another complaint is that M$ is falsely advertising.NET as a cross-platform framework while in fact it is only interoperable across those platforms which M$ dictates through its deals.
The APIs you can use from.Net are documented on the MSDN. If they aren't documented, then you can't use them.
Hey kid, I'm not referring to the APIs that are offered to you by.NET. I'm referring to the OS's APIs used by the.NET runtime. In other words, I'm referring to the interactions between.NET runtime and Windows OS.
Microsoft cough out new versions of.NET faster than you can blink, and Mono is always playing catching up...
That's precisely what I was saying. M$ can always decide the ideal date for releasing new.NET version because coding some libraries and then documenting them is much faster than coding a library conforming to somebody else's specifications. For this reason, Mono will always be playing catch-up. I don't see any difference or contradiction here.
...if your code has anything involving p/invoke (calling native code), a Mono port goes out of the Windows (unless you rewrite that part). Both of those situations are very common, and probably account for 90%+ of the incompatibilities.
This situation is very common because most.NET developers read only M$.NET's documentation and not the ECMA standard. Moreover, MSDN actively encourages developers to make use of M$-specific extensions by calling the ECMA-standardized parts as "legacy APIs". As you can see, M$ is in perfect control of what fraction of.NET applications work with Mono. Either the Mono developers are feeling an illusory sense of control or they're being paid to be the engines behind all this drama.
Do a quick google search for ".NET". All the first results are about MS.NET, not ECMA.NET. WOW, there's even a wikipedia page for MS.NET but not for ECMA.NET.
All the budding developers who hear about.NET's cross-platform nature will want to learn it. All, except the wisest, of them will be forced to learn MS.NET from MSDN. They'll code a few.NET applications in C#, test them on M$ Windows and let their brains embrace.NET beyond all question. One day they find that most of their applications don't work on Linux/Mono. They'll scream on all public forums - "Linux is crap!!!". Someone tries to explain to them that the problem is because of their heavy usage of M$-specific extensions which are not part of ECMA.NET. Then they'll scream again - "ECMA.NET?#??!!#! WTF is that?". Such is the depth of lock-in involved with.NET.
I forgot there's a hell lot in MS.NET that's not in ECMA.NET. I forgot more than 99% of the.NET developers read the MS. NET documentation rather than the ECMA.NET documentation or the Mono documentation. I forgot lot of foolish but vocal people consider the compatibility between Mono and MS.NET as a measure of.NET's cros-platformity while they should actually consider the incompatibility between dotgnu and MS.NET as a measure of the lock-in involved.
...only about half of the.NET apps out there will work on Mono 2.0, for a variety of reasons...
All those reasons can be traced back, in one way or the other, to the fact that M$ gets to decide what fraction of the.NET applications will work with Mono. M$ chooses the fraction to be big enough so that people will be fooled into thinking.NET is a truly cross-platform API yet small enough to keep Mono always as a second-class citizen compared to.NET.
Windows provides lot of interfaces to applications. Only some of these are documented as Win32. Only M$ software (or software compiled with M$'s development tools) can use the undocumented interfaces properly..NET is one such software. So it will never work perfectly under Wine, unless M$ releases the lock-in.
The existence of Mono depends on its developers having deal with M$. But it's being advertised as if it's something like WINE. While M$ claims.NET is a cross-platform standard, it is cross-platform only across the platforms that M$ permits Mono developers to target. Mono is compatible with.NET only to an extent that is determined by M$. So here's the bottomline:
Mono allows M$ to advertise itself as allowing competition while in reality it only allows competition to the extent that M$ wants to.
Sure, but weren't you supposed to be talking about Mono there somewhere? Java used to provide lock-in, too. Hence, the GNU Classpath project, which is pretty much identical in its goals to Mono. Funny that I never saw you people screaming about that one being a trap.
WINE allows you to run Win32 applications on X/Unix. Mono allows you to run.NET applications on Linux. While superficially these appear similar, there's an important difference: WINE and classpath implement specifications that are publicly available whereas Mono, through a deal with M$, implements something which is not freely implementable. The difference shows up like this: you can write an alternative for classpath or for WINE (although it would take another 10 years) but you can't write an alternative to Mono (no matter how many years you take) without having a deal with M$ either directly or indirectly. In summary, M$ CONTROLS who can implement.NET while that is not the case with Win32 or Java. Can you see the Lock-In now? Anything that requires you to have a deal in order to implement it is not an open standard.
As far as possible, code for open standards and avoid using (unimplementable) proprietary extensions unless you are forced to use them. This will ensure that the usefulness of your code won't be in control of a single vendor.
You wonder what sin you had to commit in a previous life to find yourself the official dog poop examiner of Petah Tikva, Israel.
And I wonder what sin the official dog poop examiner had to commit in his previous life.
Actually, Microsoft is the last company to add IPv6 support to its OSs. By the time of arrival of WinXP, most other OSs including Linux, Solaris and BSDs had it atleast for 2 years. And WinXP offered it as an optional protocol that had to be installed manually. Vista is the first version of windows to offer IPv6 in a default install.
My point is: We're slowly being fed wrong notions about China by US government. It's not really as difficult as it first appears to be. In fact, it is much easier for agencies like CIA to buy newswriters than for M$ to buy ISO. The government agencies only have to secretly fund a couple of "independent and objective 3rd party" articles like "Chinese hack pentagon's computers" or "Chinese involvement suspected in the recent electric blackout", etc and stop after that. Obviously, not many will believe such stories at first. But the few idiots who happen to believe these will go on to suspect Chinese involvement in everything. They will create more stories. The increasing number of such stories from new sources will cause more people, who were not previously idiotic enough, to start changing their opinions. And thus the cycle goes on continuously increasing public hatred. This is part of a bigger plan whose objective is to make people more acceptable and tolerable towards a future attack on China. Let me be bold. You say that China is definitely more repressive than Cuba. Have you ever been to Cuba or China? The same sort of poison is trying to enter our minds about both Cuba and China. The difference is: in case of China, it's just beginning to enter whereas in case of Cuba, it already did.
I don't give a damn about Windows, Linux or any OS. I just want to be sure that it is at-least theoretically possible for everybody to write a driver for their OS. That way, I won't have the idiosyncratic restrictions like "you MUST use the OSs which are in the following list:", etc.
Sending SMSes to China requires a cross-connect agreement, which means both sides have to agree to connect. Why does the author think it's nothing to do with the Chinese themselves?
And why do most people think it's got something to do with the Chinese? Because, the US government has spent a lot of money secretly to initiate online propaganda against the Chinese.
Slashdot Mirror
.NET 3.0 is not part of the standard. Half of the .NET developers out there target .NET 3.0. Unless they restrict themselves to the parts covered by .NET 2.0, they WILL be using non-standardized extensions. What is worse is the fact that MSDN actively encourages developers to use non-standardized stuff.
As hard as it might be to believe, historically most Windows developers didn't really give a S*** whether their applications worked on Linux or not.
What makes you think that it is hard to believe? It is well known that an overwhelming majority of Windows developers don't care about portability. None of the C++/Windows developers among my friends really know or care about what "ISO C++" means. To them, "C++" means opening M$ Visual Studio IDE and coding according to the specifications of Visual Studio Help or MSDN.
Hey, I have no complaints against Mono. Those poor guys are doing a lot of hard work. And they've done great so far. My complaints are against .NET as a whole. My chief complaint is that neither the Mono team nor the programmers who write .NET/Mono applications seem to realize that Mono is always going to be a second class citizen and always playing catch-up no matter how competent the Mono team is. Another complaint is that M$ is falsely advertising .NET as a cross-platform framework while in fact it is only interoperable across those platforms which M$ dictates through its deals.
The APIs you can use from .Net are documented on the MSDN. If they aren't documented, then you can't use them.
Hey kid, I'm not referring to the APIs that are offered to you by .NET. I'm referring to the OS's APIs used by the .NET runtime. In other words, I'm referring to the interactions between .NET runtime and Windows OS.
Microsoft cough out new versions of .NET faster than you can blink, and Mono is always playing catching up...
That's precisely what I was saying. M$ can always decide the ideal date for releasing new .NET version because coding some libraries and then documenting them is much faster than coding a library conforming to somebody else's specifications. For this reason, Mono will always be playing catch-up. I don't see any difference or contradiction here.
...if your code has anything involving p/invoke (calling native code), a Mono port goes out of the Windows (unless you rewrite that part). Both of those situations are very common, and probably account for 90%+ of the incompatibilities.
This situation is very common because most .NET developers read only M$ .NET's documentation and not the ECMA standard. Moreover, MSDN actively encourages developers to make use of M$-specific extensions by calling the ECMA-standardized parts as "legacy APIs". As you can see, M$ is in perfect control of what fraction of .NET applications work with Mono. Either the Mono developers are feeling an illusory sense of control or they're being paid to be the engines behind all this drama.
All the budding developers who hear about .NET's cross-platform nature will want to learn it. All, except the wisest, of them will be forced to learn MS .NET from MSDN. They'll code a few .NET applications in C#, test them on M$ Windows and let their brains embrace .NET beyond all question. One day they find that most of their applications don't work on Linux/Mono. They'll scream on all public forums - "Linux is crap!!!". Someone tries to explain to them that the problem is because of their heavy usage of M$-specific extensions which are not part of ECMA .NET. Then they'll scream again - "ECMA .NET?#??!!#! WTF is that?". Such is the depth of lock-in involved with .NET.
I forgot there's a hell lot in MS .NET that's not in ECMA .NET. I forgot more than 99% of the .NET developers read the MS. NET documentation rather than the ECMA .NET documentation or the Mono documentation. I forgot lot of foolish but vocal people consider the compatibility between Mono and MS .NET as a measure of .NET's cros-platformity while they should actually consider the incompatibility between dotgnu and MS .NET as a measure of the lock-in involved.
...only about half of the .NET apps out there will work on Mono 2.0, for a variety of reasons...
All those reasons can be traced back, in one way or the other, to the fact that M$ gets to decide what fraction of the .NET applications will work with Mono. M$ chooses the fraction to be big enough so that people will be fooled into thinking .NET is a truly cross-platform API yet small enough to keep Mono always as a second-class citizen compared to .NET.
Windows provides lot of interfaces to applications. Only some of these are documented as Win32. Only M$ software (or software compiled with M$'s development tools) can use the undocumented interfaces properly. .NET is one such software. So it will never work perfectly under Wine, unless M$ releases the lock-in.
Mono allows competition and competition is good.
The existence of Mono depends on its developers having deal with M$. But it's being advertised as if it's something like WINE. While M$ claims .NET is a cross-platform standard, it is cross-platform only across the platforms that M$ permits Mono developers to target. Mono is compatible with .NET only to an extent that is determined by M$. So here's the bottomline:
Mono allows M$ to advertise itself as allowing competition while in reality it only allows competition to the extent that M$ wants to.
WINE is as to Windows as Mono is as to .NET This is basic logical reasoning.
You are wrong. Read the reply that I've written to the parent post of the parent post of the parent post of your post to know why.
Sure, but weren't you supposed to be talking about Mono there somewhere? Java used to provide lock-in, too. Hence, the GNU Classpath project, which is pretty much identical in its goals to Mono. Funny that I never saw you people screaming about that one being a trap.
WINE allows you to run Win32 applications on X/Unix. Mono allows you to run .NET applications on Linux. While superficially these appear similar, there's an important difference: WINE and classpath implement specifications that are publicly available whereas Mono, through a deal with M$, implements something which is not freely implementable. The difference shows up like this: you can write an alternative for classpath or for WINE (although it would take another 10 years) but you can't write an alternative to Mono (no matter how many years you take) without having a deal with M$ either directly or indirectly. In summary, M$ CONTROLS who can implement .NET while that is not the case with Win32 or Java. Can you see the Lock-In now? Anything that requires you to have a deal in order to implement it is not an open standard.
The truly paranoid user would use OpenBSD, assuming of course that he's got out of M$ world.
Slashdot is heavily biased towards truth. They don't need to support an evil like M$ to be "fair and balanced".
As far as possible, code for open standards and avoid using (unimplementable) proprietary extensions unless you are forced to use them. This will ensure that the usefulness of your code won't be in control of a single vendor.
Both are restrictive, in varying ways. Openmoko is the way to go.
www.opendns.com
You wonder what sin you had to commit in a previous life to find yourself the official dog poop examiner of Petah Tikva, Israel. And I wonder what sin the official dog poop examiner had to commit in his previous life.
Actually, Microsoft is the last company to add IPv6 support to its OSs. By the time of arrival of WinXP, most other OSs including Linux, Solaris and BSDs had it atleast for 2 years. And WinXP offered it as an optional protocol that had to be installed manually. Vista is the first version of windows to offer IPv6 in a default install.
My point is: We're slowly being fed wrong notions about China by US government. It's not really as difficult as it first appears to be. In fact, it is much easier for agencies like CIA to buy newswriters than for M$ to buy ISO. The government agencies only have to secretly fund a couple of "independent and objective 3rd party" articles like "Chinese hack pentagon's computers" or "Chinese involvement suspected in the recent electric blackout", etc and stop after that. Obviously, not many will believe such stories at first. But the few idiots who happen to believe these will go on to suspect Chinese involvement in everything. They will create more stories. The increasing number of such stories from new sources will cause more people, who were not previously idiotic enough, to start changing their opinions. And thus the cycle goes on continuously increasing public hatred. This is part of a bigger plan whose objective is to make people more acceptable and tolerable towards a future attack on China. Let me be bold. You say that China is definitely more repressive than Cuba. Have you ever been to Cuba or China? The same sort of poison is trying to enter our minds about both Cuba and China. The difference is: in case of China, it's just beginning to enter whereas in case of Cuba, it already did.
Sure they did. But it doesn't matter because M$ doesn't call the ISO-OOXML as OOXML. They are calling something else as OOXML.
That should tell you something about what kind of "truth" we're being fed about those countries.
That's also the exact kind of "truth" some of us were fed about China. And we spread it.
I don't give a damn about Windows, Linux or any OS. I just want to be sure that it is at-least theoretically possible for everybody to write a driver for their OS. That way, I won't have the idiosyncratic restrictions like "you MUST use the OSs which are in the following list:", etc.
Sending SMSes to China requires a cross-connect agreement, which means both sides have to agree to connect. Why does the author think it's nothing to do with the Chinese themselves?
And why do most people think it's got something to do with the Chinese? Because, the US government has spent a lot of money secretly to initiate online propaganda against the Chinese.
They did write it. But they don't implement it properly.