Slashdot Mirror
Mono-culture And The .NETwork Effect
Sun Tzu writes "This article discusses the dangers posed by a very successful Mono project. Microsoft has several means at their disposal to effectively shut down Mono if it should ever gain critical mass. Unfortunately, Linux would be the big loser if that were to happen."
Wow, and I thought FUD was something only the commercial software vendors used against its competitors. I guess the Open Source community can't claim the moral high ground anymore.
"Unfortunately, Linux would be the big loser if that were to happen."
Linux would be at exactly the same spot in which is started. Mono is a work in progress and really isn't embedded itself into Linux yet or probably will for a long while.
Linux's strength lies in its variety, not everyone will commit to developing with mono.
.net.
There will always be alternatives.
Whereas with Windows development everyone and their dog are jumping into
You don't have to use mono on Linux, on Windows this is becoming less of a choice.
The parts of .NET that are standard are safe.
The parts that aren't standard aren't required to Mono and can be replaced with other libraries.
Sure MS can keep changing APIs, but that will hurt them and their customers too. But even if they did, Mono is still a big gain as a Linux development plateform.
The people from Mono explain this at Mono / FAQ
I think the idea behind that comment is this: Someone invests large dollars creating a .net app, and run it on MONO. They get a notice that using MONO is not legal. Will that person a) run the app legally on a copy of Windows, or b) invest time and money to rewrite the app in a different technology that they may be unfamiliar with, so that it can still run on linux?
I think it basically comes down to several things.
1. How much do you trust Microsoft?
2. How much do you trust patent laws and the Patent Office?
Microsoft has several means at their disposal to effectively shut down Mono if it should ever gain critical mass.
.NET compatibility and that Mono applications are .NET applications. That's, in fact, just false. Most current uses of Mono are based on ECMA C# and Gtk#, not .NET. In fact, one of the big strengths of C# is that, unlike Java, C# makes it easy to reuse existing C and C++ libraries; in that, it is much like the relationship of C++ to C. If you already know Gnome, you can start using C# to develop Gnome applications much more easily than picking up Java and Swing (and the Mono/Gtk# applications will work better, too).
.NET, just don't use .NET. In fact, I wouldn't touch .NET simply because I think it's technically not very good. But you can still use Mono, which is shaping up to be a great, general-purpose programming platform. And because existing open source libraries, like Gtk+, Gnome, expat, X11, etc., is so easily accessible, it's very easy to start using Mono--it's just a nicer version of C++.
Those claims are based on the inaccurate perception that the success of Mono depends on
The company to worry about is Sun: open source Java applications do use all-Sun APIs; interfacing with native libraries is just too much hassle, and that's no accident: Sun wants you to use their APIs and give up on the free, open source APIs. And, despite all the JCP mumbo-jumbo, Sun has a lot of control over the Java platform, through numerous patents, through owning key parts of the actual implementation of key parts of the Java platform (e.g., Swing), and through their ownership of the specification and the certification process.
So, if you are worried about Microsoft's ownership of
It's not about the domination of net via .NET, it's about a true, open source virtual machine project with a proper, OO language to go with it. Java is not open source, but Mono is. And Mono happens to be a superset of the Java functionality.
That fact that it lets you take Windows code and run it faster, better, more securely -- that's just icing.
To think that this is supporting Microsoft is to think that Samba supports Microsoft just because it implements protocols that Microsoft uses.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Let me change the example:
Well, it did change things. Java has lots of problems on the "run anywhere" side of things as it is, and when major java programs were written with MS-only APIs, cross-platform dreams were totally over.
I suspect that .NET will also have major Win32-only parts. If a goal of mono is just to be a development platform, fine. If anyone thinks that apps written for MS .NET will be cross-platform, then they haven't been reading their recent history.
And if Mono is just about a dev environment, then why bother? I can't really see why I should switch to C#.
Which one is practically required to exist on every PC that Dell/Gateway/etc. sell? What percentage of these companies' customers will actually go on to purchase a $400 software suite?
MS has bet the farm on its hammerlock control of the OS. If it were really forced to compete based solely on its Office suite and other apps, it's profits would fall face-first in the mud, relative to where they are now. I don't see them doing that intentionally.
"Orthodoxy is unconsciousness" - Orwell
Do you know who is our enemy and who is our friend? You may not like SUN for all its policies, but they are and always shall be part of the good guys (as one of the very few remaining). I can't believe reading such statements from someone who cares for open source and UNIX/Linux.
It is the only company that has not given in to the enemy in any way. Without SUN UNIX would have died a long time ago (in the real corporate world that is) and thus Linux and FreeBSD would have been much less relevant as well.
SUN wants to keep control to prevent abuse and beaurocracy. Whether you think this works and is necessary or not does not matter. Fact is, SUN has NEVER misused its control over API's, but instead has given away many products and standards without ever playing tricks or misusing its position (think about virtually any UNIX network protocol and influence in most UNIX API's).
MSFT is an entirely other story, they have misused almost each time they controlled some API's, even when it was a so called standard (HTML comes to ming). Why would it be different this time?
Please, don't forget who your enemy is and who your friend is, take just a bit of historical perspective!
Actually, I think that Miguel has the right idea. Unlike Wine Miguel is not trying to be binary compatible, he is simply trying to provide a mostly compatible API. In a few years, when it is time to re-up your Windows Licensing 6.0 contracts to Windows oldest-child licensing there are going to be a lot of shops contemplating a way out. Unfortunately, many of these shops will have a lot of time and effort rolled up into .NET applications.
Mono doesn't have to be 100% compatible to be a good option for these shops. Heck, chances are very good that no matter what Microsoft does a .NET to Mono migration will be less painful than a VB to VB.Net migration. Even a painful Mono migration will probably be better than the alternative. The fact that Mono runs on both Linux and Windows will be pure gravy.
Mono will also serve to keep Microsoft honest. If Mono is relatively compatible with .NET then it severely limits how much Microsoft can change the APIs. After all, if they change the APIs then they break people's applications. Microsoft can do that if their customers don't have a way to migrate away from Microsoft's API, but if they do have a migration path available (ie. Mono), then severely incompatible changes will be very likely to drive their customers into the waiting arms of the competition.
Just like IBM's Java VM makes it less likely that Sun will try any seriously deranged shenanigans with the Sun Java VM, Mono makes it less likely that Microsoft will be able to tighten their grip around .NET customers.
Not that I am interested in jumping into the .NET/Mono vise. I am perfectly happy with Python and Zope, but I can see why Miguel is building Mono. He sees that lots of customers are painting themselves into a corner with Microsoft's .NET, and he plans to make a living lending them a hand getting out of their predicament.
Pretty good plan, all things considered.
Microsoft changes some stuff so that there is an incompatibility.
You then chose to go with .NET or stay with Mono and break the compatability. One might argue that Mono can change to keep chasing .NET, but this is a loser's game. Too much resource just gets swallowed up with juggling compatability etc. People running a "mission critical" app will just shell out dollars and buy .NET to get going again.
Microsoft has used this tactic many times over. While Borland and other compiler vendors served Microsoft's interests they wore tolerated, but as soon as they were seen to be the enemy (ie MS wanted people to use Visual Studio), they started changing stuff in such a way that the other vendors just could not really keep up. Eventually even die-hard Borland supporters had to switch to keep going.
They did a similar thing with NT. They provided a Unix streams model to encourage people to port their Unix drivers to NT but then crippled the streams driver support and finally killed it, thus breaking compatability.
It is a safe bet that Mono will be treated the same way. MS has no fear of anti-trust.
Engineering is the art of compromise.
He sees that lots of customers are painting themselves into a corner with Microsoft's .NET
.NET, exactly because they wantto be painted into a corner.
.NET stuff _do not want_ alternatives. If they wanted alternatives, they would be using Java, Python, etc.
Except that these customers are painting themselves into a corner with Microsoft's
Development houses using the MS
A plan that includes selling product to someone that doesn't want the thing you are selling, doesn't sound so good to me.
Fade in. Courtroom.
Miguel: "But we had tons of meetings, you can't sue us!"
Steve Ballmer: "What meetings?"
it's very easy to start using Mono--it's just a nicer version of C++
You have a lot of reading, coding and listening to do. Then you will see the error of what you have said.
Stick Men
I wish I knew whether you were the real Miguel. Slashdot is loaded with fake ones. :-(
:-)
.NET VM. C# is supposed to (as may be obvious, I'm not a C# user) fix a number of issues with Java.
"hasuseraclue()"...Note: by reverse engineering the code, we know that above system call return 0 when ran on the system of the author of the previous paper.
Actually, this is one of the funniest and most germane comments you could have made. Think about it for a moment. Traditionally, MS library calls return TRUE for success and FALSE for failure. Traditionally, Unix library calls return the opposite -- 0 for success and non-zero (well, negative) for failure. You don't have a problem with MS-produced APIs and so wrote a comment that the other person would consider a compliment -- because presumably he adheres only to Unix APIs.
In a world where Mono is vastly successful, if Microsoft changes/introduce new APIs, do you think it will matter?
While I wish you luck and respect your work (if you are, indeed, the real Miguel), I think that you may have missed a point. Your argument that Mono will be a binding influence on Microsoft is predicated on the fact that Mono will achieve significant "market" share, before any sort of nasty compatibility-splitting moves are made by Microsoft. I'm not sure Mono will do that. Microsoft has a tremendous team of language designers that had a head start of *years* on you folks. It takes a while to catch up, and given that this is still a new, sexy initiative at Microsoft, it's going to be a moving target.
However, I really don't see the problem as all that severe anyway -- I'd support your argument for entirely different reasons. (a) Presumably Mono can be made to work on Windows, providing a common runtime everywhere. So if Microsoft changes things, there will still be a runtime that C#-using developers could ship with their applications. (b) Even if Microsoft changes course...so what? How would the situation be worse than before? We already don't have binary compatibility between the C Unix applications written to an entirely different set of APIs and the MFC-based Windows software. The only different thing would that there would be a fairly solid development tool available to to rapid application development on Linux -- and a tool that would make it easier for experienced C# developers to transition to Linux.
But let's assume that Mono *will* hurt Linux. I'd like to point out to the grandparent poster that Miguel is hardly under any onus to drop a project because it isn't in Linux's immediate favor, anyway. Open Source is all about writing good software and then sharing it with other interested people, folding improvements back in. Miguel's doing exactly that -- providing a good tool. He's done immense amounts of work in the past that have enormously benefited the OSS and Linux worlds -- likely more than the grandparent poster.
Finally, Java is, frankly, not a particularly well designed language. It was well marketed, and it managed to win over a large chunk of the C++ crowd, and is an improvement over earlier languages for folks who want a C-like safe language. However, many of the design decisions were poor. Furthermore, the JVM has some fundamental design limitations that prevent it from being useful for some non-Java languages like ocaml. I believe that this is not the case for the
Miguel, I have my differences with some design in GNOME -- I think that, in retrospect, CORBA and XML were overly heavyweight. I'm sad that the decision was made not to include an barber pole-like "infinite progress bar" widget in GNOME to denote tasks with an unknown completion time. However, it's the fact that I can pick such minor nits that makes it really clear how much your work in the past has done for us now. I can sit down and work on an Excel spreadsheet. My Windows-using friends can comfortably use Linux.
Thanks again. And whatever happens, don't wind up like Eazel.
May we never see th
Most of the systems running Windows 95 and Windows 3.1 aren't running services. They're also usually not 24/7 connected to the Internet and facing it in a way that malcontents or malware can capture and use the machine. So a monoculture of Windows 95 machines only poses a threat for peer-peer outbreaks, i.e. Outlook viruses, etc. Windows 3.1 machines are even less of a threat.
They're so completely different from the problem that broken Sendmail and BIND implementations represent, that I just have to ask:
So what was your point?
A Good Intro to NetBS
No, no, no.
.NET is MS reading the writing on the wall: namely, that Windows is a dying brand, that will not be relevant in the long-term future as a major cash cow.
.NET is a 10-year hedge against that. Thanks to .NET, MS has the ability to ditch Windows in the future. As Windows fades, MS can be assured that its other cash cows - MS Office, the backend products, etc are still viable and dont need rapid porting to a new platform.
.NET ensures MS's relevance even if Windows fails. Virtually all of the Windows software developed in the next decade will be developed with varying degress of support for .NET. Even now its starting to trickle into the marketplace. Desktop software, server-side software, everything. Even games will soon be enginered with maanged C# code. MS has started using it for their internal development of various products. As hardware adapts and as performance is tweaked and improved, everything MS writes will be done with .NET. At that point - 5 years, 10 years, etc - in the future MS will have successfully allowed themselves to be #1 regardless of hardware vendor, architecture, operating system, and even written language!
.NET around, healthy, and adopted for alot of software development is currently in MS's best interests. It means that even if they are directly profiting they will be relevant no matter what happens in the industry.
.NET now will be seen by analysts as MS's most brillant move. Windows decline has begun in ernest. Linux is on the rise. Apple is on the (modest) rise. But yet MS will continue to thrive. And be poised to be viciously competitive regardless of what the "next big thing" is.
You are bigtime wrong.
"Little" OS's chipping at Windows: Linux, MacOS, etc will eventually force desktop OS's to be commoditized, and MS knows this, and realized it a long time ago.
Look at it this way:
Sun is virtually a solved problem: they are sick company who cannot continue to compete with MS in the fashion it has been. COntinued massive losses pile up to spending cuts and focusing only on profitable products. McNealey already is having to focus on profitable businesses at the expense of "long-term vision". Shareholders won't tolerate the types of losses that Sun has posted recently for very long. As it is Sun isn't even profiting from Sun as much as other major players: that's a bad thing from a business perspective.
It all boils down to this: keeping
In another decade moving to
develop using MS IDEs(faster learning curve) ,and deploy on Linux.
.NET, J2EE, etc. are not panaceas, and it is inevitable that platform-specific nuances will leak through. Just wait for something to work on an MS IDE to break on Linux, because some idiot developer didn't use the right file abstractions, for example.
This is a bad idea, unless very frequent testing is done on the target platform throughout development.
Healthcare article at Kuro5hin