Slashdot Mirror

I'd like to point you at an article I wrote for kuro5hin on the subject of .net here.

Microsoft's introduction is here.

Mono's information is here.

(Score:5, Informative) by miguel (7116)
(Score:5, Informative) by miguel (7116)
(Score:5, Informative) by miguel (7116)
(Score:5, Informative) by miguel (7116)
(Score:5, Informative) by miguel (7116)

Okay, I don't know who you think you are, Mr. miguel (7116) (if that's even your real name), but if you think you can Karma Whore your way to success by posting a bunch of information from other sites and posting a mess of links, you have another think coming!

You big jerk. ;)

PDHoss

I wouldn't worry about .Net "smart clients" too much... the API is very well-defined, and the good folks at the Mono project are making sure the Free world will be on board.

.Net will be as portable as Java within a few years. Wherever MS doesn't take .Net, the OSS community will.

With or without a full equivalent of .Net, I expect to see a lot of ISO C# implementations, optimized for various interesting tasks and platforms. Nothing about the ECMA C# spec requires IL (.Net's "bytecode"). Apple could certainly create an ISO C# implementation, call it Apple C# (MS released the name with the standard), have it natively compiled to PPC instructions, and have it use some combination of .Net APIs and Cocoa APIs.

Other platforms could do likewise, if MS doesn't do it for them. I think C#, if not all of .Net, is going to be less "pure" than Java (more variants) and ultimately far more broadly used.

As far as I know, one of the major complaints about Java is the fact that it isn't standardized by an outside party like ECMA or ISO, but by Sun itself, meaning developers have as much say in the Java standard as they do over MS's VB. (please let me know if i'm wrong about this).

personally, I've taken a look at C# and like it. of course MS claims it's more related to C++ thna Java, but C# has more in common with Java than anthing else.

I assume the reasoning behind the standardization is to compete with Java... MS hasn't really had its own enterprise-level language before this (the candidates would be VB, which IMHO sucks and forces you to stick with Windoze and C++ which doesn't mean you have to use VC++). personally I'm much more likely to use it if its standardized, because I know MS can't easily pull off an "upgrade" or change the EULA and break/change the language for their benefit.

of course, by the time C# is ISO standardized (assuming it will be) the MONO project should be well enough along to use C# seriously... of course since the languages are so similiar why not just use Java in the first place?

lots of questions, not many answers.

For people interested in Logo there is also a Logo project called MonoLogo
that creates a .net version of Logo on top of Mono.

Download the SDK from MS. It's just like downloading the Java SDK (JDK) from Sun.

It's free. You'll get a C# compiler, a bunch of class libraries, and a runtime, plus other goodies (e.g. other languages, but stick with C# if you're starting new.)

Get a beginning C# book and go to work. It's no different from learning what Java was about in Java's early days.

If your complaint is then, "but I'm not a Windows user", I can relate. One of the main reasons I became a Windows user was because I was having such a hard time learning the "cross-platform" Java language on my Mac back in the early days.

If you're not a Windows user, you should be used to waiting by now, so wait for (or go help) Mono. Since I'm not a Windows user on the server side, I have to wait with you for some things, but I think that there will eventually be an excellent .Net for non-Windows platforms.

Yes I have tried, and last time I checked neither PHP nor MySQL supported UTF-8. I'm not saying that you can't simply pass a byte sequence through them unprocessed. You can usually do that with anything. I'm saying that the data processing features that had no trouble processing Latin-1-encoded text could not successfully perform the same processing if the text were encoded as UTF-8.

I'm not claiming I built such a system and it failed. I'm saying I tried designing one with the help of the official docs and the online experts with each technology, and was assured that "sorry, you can't do that."

Contrast that with the other technologies I mentioned where the data is always normalized into some form of Unicode internally before the processing even begins so that all processing is language-independent. All algorithms (features) will work on any sequence of characters, regardless of what language or mix of languages they represent.

I've built many such systems with Java/Oracle, and a few new ones with .Net/SQLServer. Both approaches are terrific. (I now prefer C#/.Net to Java, but I *strongly* prefer Unix to Windows on the server, so I'm still mostly using the Java/Oracle approach for production until I can get a good C# and .Net for Unix platforms. Go Mono!)

I keep saying "the last I checked" because eventually all non-Unicode systems will either add Unicode support or die. These two will eventually retrofit something, probably UTF-8, and maybe it has already happened, but systems like Java and .Net are so far ahead in globalization that it will be a long time before I'd consider PHP/MySQL for any company beyond a local shoe store or bakery (where I admit they have a pretty good niche).

Mono already step back from its previous claim and said they will not implement Winforms etc.

What estonishing speed are you talking about???? .NET is there for more than 2 years. Mono is there for 1.5 years, still no release.

I think .NET is the real reason MS is changing. They realize that their OS monopoly won't last, and they're clearly adjusting their business plans.

I'm not talking about web services, because that was a crock. But .NET is a beautiful thing. It's Java with Microsoft's blessing. And I like Sun better than MS too, but let's face it folks: Microsoft can take this concept much farther than Sun ever could, and it will use its OS monopoly to do so. .NET is also great news for users of non-Windows platforms. Visual Studio is now Visual Studio.NET. All the i386 binaries and Win32 calls in your standard Windows application will be replaced with bytecode and .NET class library and Windows.Forms calls.

This is a good thing for Linux users. This is a good thing for Mac users. This is a good thing for everyone.

And I know a lot of Slashbots will come and say, "but mono won't implement Windows.Forms"! Yes, yes they will. It might take a few years. Maybe less; mono has progressed at an astonishing rate. There might be some legal issues, and that is the big question. If MS sees mono as a threat, they could pull out the lawyers, I admit. But I believe that mono will ultimately prevail.

And many of you will say, "but I like Java more!" Very well. That's cool. You don't have to code with .NET. Just don't badmouth the ability to eventually run Visual Studio.NET under UNIX with Mono. That's nothing to laugh at. Besides, mono folks have considered wrapping Java with mono.

I think .NET is the real reason MS is changing. They realize that their OS monopoly won't last, and they're clearly adjusting their business plans.

I'm not talking about web services, because that was a crock. But .NET is a beautiful thing. It's Java with Microsoft's blessing. And I like Sun better than MS too, but let's face it folks: Microsoft can take this concept much farther than Sun ever could, and it will use its OS monopoly to do so. .NET is also great news for users of non-Windows platforms. Visual Studio is now Visual Studio.NET. All the i386 binaries and Win32 calls in your standard Windows application will be replaced with bytecode and .NET class library and Windows.Forms calls.

This is a good thing for Linux users. This is a good thing for Mac users. This is a good thing for everyone.

And I know a lot of Slashbots will come and say, "but mono won't implement Windows.Forms"! Yes, yes they will. It might take a few years. Maybe less; mono has progressed at an astonishing rate. There might be some legal issues, and that is the big question. If MS sees mono as a threat, they could pull out the lawyers, I admit. But I believe that mono will ultimately prevail.

And many of you will say, "but I like Java more!" Very well. That's cool. You don't have to code with .NET. Just don't badmouth the ability to eventually run Visual Studio.NET under UNIX with Mono. That's nothing to laugh at. Besides, mono folks have considered wrapping Java with mono.

Since Mono is not being developed by Microsoft and is being released under various open source licenses, this is not a possibility. Microsoft has already submitted the C# language specs and the CLR specs to ECMA anyway. There's no "taking it back" now. It might be a good idea for you to read the FAQ on the Mono site.

Since Mono is not being developed by Microsoft and is being released under various open source licenses, this is not a possibility. Microsoft has already submitted the C# language specs and the CLR specs to ECMA anyway. There's no "taking it back" now. It might be a good idea for you to read the FAQ on the Mono site.

Will .net apps written for windows similarly only work with the "windows gui toolkit" (or whatever)?

Yes, they will. As soon as the implementation of the Windows.Forms classes are implemented. That's within the scope of the project and is a big challenge, check it out here.

It's not necessary for MS to create .Net for other platforms. We're not at the mercy of MS.

Even Java gets support for most of its many platforms from entities other than Sun.

.Net on Linux is already well on it's way. It's called theMono Project by Ximian, the same people who created Gnome. If developers on other platforms want to have .Net support and can't get it from MS, they'll get a huge headstart from the LGPL'ed Mono code.

J# isn't meant to run on a JVM. It's just one of the .Net family of languages.

All .Net languages are compiled to the same "bytecode" that MS calls MSIL. J# is no exception. It is compiled to MSIL, not to Java bytecode.

Whether you prefer to write your source in Java (using J#), or C#, or VB.Net, or Perl.Net, or whatever, the source gets compiled to the same MSIL.

The MSIL code then runs on the .Net framework in a thing called the "common language runtime", which is similar to a JVM, but designed from the start to *try* to accommodate as wide a range of source languages as possible.

After they become MSIL, they are completely interchangable, regardless of their original source language. You could grab a cool C# utility class off the Web somewhere and use Java "extends" to write a subclass in Java. If you find it easier to parse text with Perl than with Java (who doesn't?), then you could write just the text parser classes in your Java app in Perl.Net.

The idea is that you get to work in a source language that you choose. Unlike the Java world, .Net doesn't limit you to doing everything in a single language. (However, it *does* currently limit you to Windows only, quite unlike Java, but that's changing quickly.

The point of J# is to let Java lovers use Java to create .Net applications. When Ximian's Mono Project is fully up and running (Go Mono!), the MSIL output from J# will become executable on a Linux box. When that happens, a Java programmer who wants to deploy on Linux will suddenly have two excellent class frameworks to choose from: the Java standard and .Net.

J# isn't meant to run on a JVM. It's just one of the .Net family of languages.

All .Net languages are compiled to the same "bytecode" that MS calls MSIL. J# is no exception. It is compiled to MSIL, not to Java bytecode.

Whether you prefer to write your source in Java (using J#), or C#, or VB.Net, or Perl.Net, or whatever, the source gets compiled to the same MSIL.

The MSIL code then runs on the .Net framework in a thing called the "common language runtime", which is similar to a JVM, but designed from the start to *try* to accommodate as wide a range of source languages as possible.

After they become MSIL, they are completely interchangable, regardless of their original source language. You could grab a cool C# utility class off the Web somewhere and use Java "extends" to write a subclass in Java. If you find it easier to parse text with Perl than with Java (who doesn't?), then you could write just the text parser classes in your Java app in Perl.Net.

The idea is that you get to work in a source language that you choose. Unlike the Java world, .Net doesn't limit you to doing everything in a single language. (However, it *does* currently limit you to Windows only, quite unlike Java, but that's changing quickly.

The point of J# is to let Java lovers use Java to create .Net applications. When Ximian's Mono Project is fully up and running (Go Mono!), the MSIL output from J# will become executable on a Linux box. When that happens, a Java programmer who wants to deploy on Linux will suddenly have two excellent class frameworks to choose from: the Java standard and .Net.

I've been fiddling with .NET on Linux. (click.) But I'm not Indian.

How in the hell are .NET and OS X similar? One is a new Unix-based operating system leveraging Apple technologies, and one is a completely new "applications as internet services" paradigm.

Is microsoft abandoning their drive to make Passport the authentication mechanism for *everything*, Starbucks and such, or are they just going to drop the pretense of making it an open system?

Passport was a seperate initiative from .NET MyServices (aka Hailstorm). Passport is an authentication mechanism while .NET MyServices was supposed to be a centralized repository of user information (calendar, preferences, inbox, contacts, bookmarks, etc) which could be queried by various vendors who would receive restricted access to the data based on the user's settings.

Is it possible for people to take the hailstorm protocol, if they so desire, and set up an independent, decentralized hailstorm network that just happens to not be affiliated at all with microsoft?

There are a couple of things to consider here. The first being whether there are any intellectual property(IP) issues, I have no idea about this but wouldn't advice anyone to start something like that without at first ensuring there aren't any patents or anything like that being violated. The second thing is exactly how one would use the technology. Personally when I first saw a Hailstorm presentation last summer I kept on thinking that it may face difficulty in gaining widespread acceptance for exactly the same reasons listed in the article; there was no justification for vendors to give up so much control to user information to a third party. One example touted was the ability to move music preferences from website to website but the question never asked is why Amazon.com [for example] would make it easier for users to grab all their painstakingly entered personal preferences and music ratings to CDNow.com or some other online site. I remember emailing the presenter about my thoughts but couldn't follow up since it happened close to the end of my internship. However, it may work within a closed environment like a corporate intranet but then again MSFT already has Exchange which has a lot of the important functionality that would be provided by .NET MyServices like an inbox, contacts, calendar etc.

Was GNOME MONO planning on implementing hailstorm as part of their .net workalike? Are they still going to?

Gnome is not related to Mono. Miguel De Icaza may have founded both but he no longer maintains any packages for Gnome nor does he do much (if any) active development but instead spends most of his energy on Mono.

As for your question, Mono is not interested in Passport or Hailstorm and went as far as creating a page about it because people kept on getting misconceptions about it.

Disclaimer:This post is my opinion and does not reflect the views, opinions, intentions or strategies of my employer.

I think you gloss over some of MS's flaws with that bullet list and claiming they're "credible" in all of thse areas.

Point by point -

* Compatibility and interoperability - Yeah, they're interoperable... with their own products. Interoperability with MS is a one way street - once you import all your wordperfect docs to Word, there's no going back.

* Stability of vendor - If by "stability" you mean that they're guaranteed to be around, yes, you're absolutely right.

* Amount of ongoing development - This they definitely have, too. No contest there. (I'm all about MS R&D - I'm rather looking forward to Mono ;)

* Feature set - yeah, they definitely have this one (for better or for worse...)

* Marketshare and userbase - once again, there can be no contest on this one. I'm hoping Mozilla and OpenOffice help erode this though. :)

* Adherence to standards - Ok, I'm going to flamebait for a second here... (yes, that's also a verb) Perhaps you've never heard of "Embrace and Extend"? MS adheres to standards only when forced to, not because they believe in industry standards. I could go off on this one for a while, but I have to say they *defintiely* don't get the point on this one.

* Ease of use - Perhaps. MS has made strides in making PCs easier to use, but I believe most of their "ease of use" comes from familiarity, not just being easier. Familiarity *is* good, but it can't replace actual usability. Mac still holds that crown, without a doubt, and GNOME is actually making major strides with this with GNOME 2. Finally, WinXP was a huge step BACKWARDS for ease of use - ever tried one of their new "WinXP-Wizards-on-Steroids"? They're terrifying. MS should have quit while they were ahead with Win2k - their first and only respectable OS, IMHO.

* Security - Once again, Win2k made some big improvements in this area, but it's still nowhere NEAR where it needs to be. Outlook worm, anyone? I've heard their new ".NET Server" product is actually much better, though - it encourages GOOD passwords, etc. So kudos to them for finally getting a clue, and forcing MCSEs to get one, too.

* Stability - Again, Win2k was their first stable OS. NT was a fscking joke, and the 9x series... don't get me started.

Finally, what's up with the IE comments? Why should its userbase and features make me "have second thoughts" when Mozilla is actually *faster* (this isn't just open source FUD - it's true. go try 0.9.9 if ya don't believe me!) and strongly adheres to W3C standards, not to mention having very nice features like tabs and popup blocking.

Besides, the Backstreet Boys have a large catalog and a huge following, and I don't like THEM just because other people do either. ;)

proprietary extensions/applets/applications built around the .net framework.

Isn't the .net framework an ECMA standard now?
Isn't someone working on a free implementation of that standard?
Are you calling it proprietary just because it comes from billy boy?

No longer will new features be added directly to office, but will be available on the web - provided the user has Windows and is using IE...

That sounds to me like it would primarily affect office users, not web surfers, and considering office's main platform is windows, so what if they use windows/ie for web-based updates/upgrades?

Heck, MS execs are even talking about how http's days are coming to an end...

You got a link to back that up?

I'm not necessarily defending microsoft[1], just questioning the statements you present as fact.

C-X C-S
[1] Although I don't think they're any more evil than any other money-grubbing corporation.
Media conglomerates and trade groups, now those scare me - they have hundreds of times more governmental influence than billy and friends will ever have.

You are making at least two assumptions here:
1) MS can force Ximian and other developers to pay for using the .NET framework.
>>Since Ximian is only using information submitted to a standards body, I guess we're saying that MS would use software patents and not copyright to force these payments. Patents, by their very nature, are supposed to be out in the open, right? What patents are we talking about here? Even if there are some patents being applied for (and thus not in the open), is there anything that Ximian is doing that hasn't already been done by Sun with Java? Here is a brief excerpt from Miguel's interview on MSDN that may go toward answering the but-is-it-patented? question:

"Dare Obasanjo: There have been conflicting reports about Ximian's relationship with Microsoft. On one hand there are reports that seem to indicate that there may be licensing problems between the license that will govern .NET and the GPL. On the other hand there is an indication that some within Microsoft are enthusiastic about Mono. So exactly what is Ximian's current relationship with Microsoft and what will be done to ensure that Mono does not violate Microsoft's licenses on .NET if they turn out to be restrictive?

Miguel de Icaza: Well, for one we are writing everything from scratch.

We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques."

2) Next assumption: the main purpose of Mono is to be compatible with .NET.
>>I believe that Miguel stated (Question 28) that while compatibility would be great, the Mono platform would be a real bonus in its own right, compatibility be damned. You could call it a fork of .NET, if you like. Is this horrible?

Just some things to think about...

Maybe you should read this

It also means the possibility for a form of binary compatibility with e.g. Unix systems that didn't exist before. An Open Source Unix implementation would be pretty nice to have -- which happens to be what Mono is doing.

It looks to me like enough of the core libraries are part of the ECMA standard that, once implemented, they'd provide almost the same level of compatibility (except binary, not just source) between the Mono CLR on Linux/Unix and the Microsoft CLR on Windows as there is between GNUStep and MacOS X.

That's icing, though. Microsoft could always play their usual compatibility games, limiting the usefulness of CLR for that purpose. Whether or not it's 100% compatible with Microsoft's version, if you have your own implementation that Microsoft doesn't control it's a really useful technology just for the sake of e.g. cross-platform Linux development.

There are some annoying things in CLR, but overall it's an improvement over the JVM (as practiced).

Note I'm not addressing C# versus Java as languages. You can host many different languages on both the JVM and CLR, although Microsoft seems to be actively touting that fact more than Sun is right now.

see this link