The Case For Supporting and Using Mono 570
snydeq writes "Fatal Exception's Neil McAllister argues in favor of Mono, asking those among the open source community who have 'variously described Mono as a trap, a kludge, or simply a waste of effort' to look past Miguel de Icaza and Mono's associations with Microsoft and give the open source implementation of .Net a second chance, as he himself has, having predicted Mono's demise at the hands of open source Java in 2006. Far from being just a clone of .Net for Linux, McAllister argues, Mono has been 'expanding its presence into exciting and unexpected new niches.' And for those who argue that 'developing open-source software based on Microsoft technologies is like walking into a lion's den,' McAllister suggests taking a look at the direction Mono is heading. The more Mono evolves, the less likely Microsoft is to use patent claims or some other dirty trick to bring down the platform."
Objective Review (Score:3, Insightful)
Ok, sure. I can do that. In fact, I wrote just such a journal entry in mid-07:
It is quite obvious to anyone using the platform that the Mono team is not in bed with Microsoft. In fact, it would seem that the Mono team is explicitly trying to warn you away from .NET technology. Otherwise, why would they make it SO GODDAMN HARD TO DEVELOP FOR?
Read More: A Day Without Mono is like a Day Without a Bullet in my Head [slashdot.org]
Ooooh. That wasn't positive at all, was it? Huh.
Re:Objective Review (Score:5, Interesting)
Ohhh, yeaaah. I remember this guy. This is the same nitwit who used logic from 1996 to try and convince us all to burn our webapps [slashdot.org]. I see he's back with even more faulty reasoning.
I guess there's only one thing to say. Slashdot, meet the new John C. Dvorak [slashdot.org].
Re:Objective Review (Score:5, Insightful)
Actually, I'm inclined to agree that WebApps generally suck when compared to a Windows App performing the same task. Obviously, WebApps have their advantages (easy distribution, usage monitoring, centralized access, no risk of rogue versions); but when the situation doesn't make it necessary to create a product as a WebApp, I think it's generally stupid to do so.
As for Mono, the product is a valiant effort, but I can't understand why you would run software on something other than its native platform. After the App is deployed, if it encounters any problems, you'll always have to wonder, is it the App, or is it Mono?
Re: (Score:3, Interesting)
We are in such a case.
We are a multi-national, and in one research site tooling was developed for building, first all Win32 C++, later .NET C#.
Recently came the day that we got in bed with people who only work on Linux, so all our tools must now run on Linux. There is NO gui dependency here. In this case, Mono was really our rescue.
Re: (Score:3, Funny)
"First they ignore you. Then they fight you."
Then Google kick's Microsoft's ass, eats their lunch and takes their milk money? Ya, I was thinking the same thing.
Re: (Score:3, Funny)
Re: (Score:3, Interesting)
Just sort of have to throw my two cents on to this as well and agree whole-heartedly. I FAR prefer native GUI front ends on whatever platform to a web app. For most big web apps, they tend to be a basic form or two with "complex" stuff being called behind the scenes, in which case all of the real programming work went in to that "behind the scenes" stuff and that's not what I'd call a web app either.
I'm actually even considering going to the trouble of coding my own front ends for some internal web apps a
Re: (Score:3, Interesting)
as unpopular as it is to say so, I have to agree, I personally haven't found a single useful webapp for what I normally do, I see the usefulness of intranet server based apps, but webapps are generally useless, slow, buggy and problematic
Either what you do normally is pretty intensive of resources (not webapps strong point to date) or you're not doing a lot of work across multiple organizations. Trying to deploy something in a highly distributed and heterogenous setting is an utter nightmare, and using a webapp instead turns it into just plain sucky.
Re: (Score:3, Informative)
I'll throw out my anecdote, because, as always, my anecdote is better than your anecdote.
I've since moved on, but I worked for a company in the financial sector that needed to input
Re:Objective Review (Score:5, Insightful)
I regret that he apparently wasn't more successful in convincing us to burn our web apps. I'd hazard a guess that 80% of my computer-related headaches is a result of web apps, which I have now almost completely swore off if there's any way I can avoid them.
Crap like Google Maps I find insulting. We had map software 15 years ago. The only thing we needed was periodic udpates, but web apps go to a completely opposite extreme, every single data request is serviced live, nobody finds it acceptable to risk that data might be hours or days old. If I'm actually using my connection to retrieve data (files, audio, video, etc.) all those web-apps slow to a crawl.
With web apps, even with the fastest modern computers we're working at speeds closer to what we had back in 1995. We don't need all data to be streamed from the source, I would much prefer most of the applications reside on a local computer and function at native speeds instead of everything being bottle-necked by my ISP. I don't even mind using a thin-client running applications through terminal services, but having all basic desktop applications running from a web server is just ridiculous.
Re: (Score:3, Interesting)
Crap like Google Maps I find insulting. We had map software 15 years ago. The only thing we needed was periodic udpates, but web apps go to a completely opposite extreme, every single data request is serviced live, nobody finds it acceptable to risk that data might be hours or days old. If I'm actually using my connection to retrieve data (files, audio, video, etc.) all those web-apps slow to a crawl.
Well them, buy your map software or even a dedicated GPS device. Personally I'm happy with google maps. It also makes a nice backup to my gps that I have it installed on my blackberry. If I had enough of a need I'd buy mapping software.
Youtube is an example of a great webapp. For most video needs it works great. There are times I want better than a small flv file, and I will watch a dvd or mpeg 4 in those cases.
Re:Objective Review (Score:4, Informative)
The microsoft documentation is only useful if you're using Visual Studio. Period. Find me a
Now it is technically possible to write
Just fork out the $$ for VS and you've instantly saved yourself weeks of development. But Mono.... just give up now. Unless things have changed over the past 2 or 3 years. But I doubt it. I don't even really understand why they bother.
Re:Objective Review (Score:5, Informative)
Re:Objective Review (Score:4, Informative)
I write .NET code and support other developers doing the same as my day job, and we fully support mono. In fact, one product that's due for release soon by a third party that I support is running mono on a headless linux box (it's intended as a sort of "black box" from the customers point of view - the choice was made for Linux and Mono purely because of price - this thing is to be MASS distributed, so Windows licenses would bump up the price too much). This product will be very widely used by our customers, so to me at least, it's clear that mono is mature enough now to be used in the 'real world'.
As far as developing it without Visual Studio - I use VS at work (although still on VS2005 - haven't found a compelling reason to upgrade yet), but at home, where I also do a lot of work when I can't be bothered heading in to the office, I use MonoDevelop. And, for Mac Specific projects, I generally write my back-end in MonoDevelop, compile as DLL(s) and then write the GUI with XCode (Cocoa#). I think I COULD do it with a plain ol' text-editor and get by okay, but I prefer to use a real IDE. With MonoDevelop existing though, Visual Studio is definitely NOT a requirement.
Re:Objective Review (Score:4, Informative)
SharpDevelop is BSD licensed, and quite excellent. There is very little preventing you from using this as your primary development environment. SharpDevelop on Mono is also possible.
The sole reason I still buy the VS licenses, is because I also keep juniors using Resharper (a VS refactoring/quality addin) and Diamond Binding (a database access addin/library, again VS only), which pretty much add 20% on the productivity of a bunch of noobs.
Sometimes (rarely) the place I go into uses MS Project Server "properly", and the TFS changeset/issue tracking makes VS worthwhile over SVN as well.
The reasons against using Mono (if you are going for minimising cost of development, and putting ideology aside), is being able to use things like WPF/WCF/WF. This is above and beyond what you need to develop most applications though.
Re:Objective Review (Score:4, Informative)
Just fork out the $$ for VS and you've instantly saved yourself weeks of development. But Mono.... just give up now. Unless things have changed over the past 2 or 3 years. But I doubt it.
So basically, you're ranting against something you haven't tested for close to 3 years. But you 'doubt' it has changed, so you are sure your opinion is still valid.
And you've been modded Informative!
Re: (Score:3, Interesting)
> Many C and C++ programmers aren't so good at doing shell scripts. *shrug*
But I can assure you that most shell "scripters" aren't good for C, and even less for any non trivial programming project.
That's one of the top reasons IDEs are popular: they hide the build process from the developer.
I just don't understand why people defends autoconf as "the right tool(tm)". Maybe it's right for your case or knowledge, but most users (and developers) find it really annoying, yet is the sanctified open-source-buil
Re: (Score:3, Informative)
Exciting new niches (Score:3, Funny)
Mono has been 'expanding its presence into exciting and unexpected new niches.'
Yes, just recently there have been several more [engadget.com]!
Here at the Mono bar, we play every kind of music - country *and* western!
For bit rates less than 24 Kbps (Score:5, Funny)
For bit rates less than 24 Kbps I prefer mono.
(What, RTFA ? Who has time for that ?)
But the political reasons... (Score:4, Insightful)
A third party implementation of a standard defined by the first-party implementor is always going to lag behind the original. Even if .Net is technical nirvana, if your platform's only implementation comes from a third party, your platform is a second-class citizen.
The case against Mono has nothing to do with the technical niceties he presents, nor do the fears of Microsoft "pulling out the rug" matter... What matters is that when developers and end users pick a technology, they pick the leader, not the follower. Accepting Mono is giving up and giving in to Microsoft vendor lock-in.
Re:But the political reasons... (Score:5, Informative)
I guess all that stuff in the Mono.* namespace that Microsoft's release of their framework doesn't support is just following right along. Like Mono.SIMD. Or Mono.CSharp, which (unlike Microsoft's libraries) contains a fully featured compiler service and runtime evaluator. Or the other Mono stuff that Microsoft's releases can't do, like full static compilation for the iPhone and Microsoft's own XBox 360.
I'm guessing you don't know much about what you're talking about, but hey, it's Slashdot, that's par for the course.
Re:But the political reasons... (Score:5, Insightful)
But then we get into the topic of if Mono is .NET or an imitator. If it gets too powerful, or too feature full, who's to say if MS doesn't retract their promise and claim that Mono is infringing on their patents, suing whatever company might have worked on said products?
What I dislike about Mono/.NET isn't the technology. It's a cool way to do things (up to a point when it becomes brainless cut and paste as I've seen a lot recently.) I like the general coding and namespacing standards, but there's always the looming Microsoft update around the next corner and you feel like you are always playing catch up. With C/C++, you have additional libraries that come into play from year to year, but the language itself is defined. You continue to use your libraries, they get better... it's a slowly changing target. Yes, there's a new revision coming to extend it even more, but once that's there you won't have Microsoft adding LINQ to the core in 3 months causing a new revision and a new learning dependence. A dependence on MS and marketing of feature sets. I feel as though the language is going to get so bloated with "new"/"handy"/"neato"/"swell" features that it will become cumbersome to learn for someone just coming into it. Yeah, it's great for those in on the ground floor that know and learn as it grows... but there's another side to that growing wall.
Not only the learning curve, but the libraries alone. You mentioned libraries on top of the core structure of the language that are added in requiring bigger downloads for the RTE and more initial overhead. Now you have to look toward embedded devices or mobile platforms. Are they going to be filled with libraries that aren't needed or do you create a slimmed version of the .NET framework to run on them? If you cut out the cruft, now you have virtually two different environments. You might have been able to do LINQ on your desktop, but now since you cut out all those libraries to be able to fit it on a flash ROM... you have to code entirely different.
Disclaimer: I was picking on LINQ... but you could replace it with any method you use.
Re:But the political reasons... (Score:4, Insightful)
So long as the features are backwards compatible I wouldn't worry too much about it. For example, when they introduced the Windows Presentation Foundation in .NET 3.0 you could simply ignore it if you chose to.
I think of it similarly to the Qt framework. Sure, it's grown tremendously over the years but generally if you knew how to use Qt 3 it isn't much work to transition to Qt 4 (at least not conceptually, converting old code could be bothersome depending on how the code was written). There may be tons of new classes you're unfamiliar with but if you don't want to use them nobody is forcing you to learn about them.
I think Microsoft has learned from the days of Visual C++ (6 and earlier) and will not return to the mess that was MFC.
The patent issue is a red herring (Score:5, Insightful)
"If it gets too powerful, or too feature full, who's to say if MS doesn't retract their promise and claim that Mono is infringing on their patents, suing whatever company might have worked on said products?"
MS patents are going to be general (as all patents with "business goodness" are). In other words, MS isn't going to limit any patent description in such a way that only .NET implementations would be in violation. If mono violates a MS patent it's very likely that Java and many other projects will violate it too. The mere fact that Mono is an attempt to implement a sub-set of .NET doesn't mean it has any greater risk than other projects.
In any case, I seriously doubt that MS has any desire to start a patent war anyway. Between the DOJ and IBM, it wouldn't be a winning strategy.
Re:But the political reasons... (Score:5, Insightful)
If it gets too powerful, or too feature full, who's to say if MS doesn't retract their promise and claim that Mono is infringing on their patents, suing whatever company might have worked on said products?
The law. That would be called estoppel [wikipedia.org]. If they sue you, and you can show that Microsoft has said something to give you an expectation that they would not sue, you win.
I'm not a lawyer, but that seems to be one of those laws that is pretty easy to interpret.
Re: (Score:3, Informative)
Untrue. You can run 1.1 applications in 2.0. The default is to install both side-by-side.
And .NET 3/3.5 both run on the 2.0 CLR.
Re: (Score:3, Interesting)
.NET CF has forms support, but it's not WinForms as we know them. AFAIK the libraries are managed by different teams and while they present some of the same interfaces they're entirely different under the hood. Much smaller, too.
I didn't know about .NET Micro, but looking at the Wikipedia page makes me start involuntarily drooling, if this is true...
Re: (Score:3, Informative)
Honestly? I don't use .NET/Mono specifically for cross-platform programming, although it's a nice plus when you can get it "for free," or nearly so. I use it because it's a single language and coherent system for a lot of different stuff.
Rich web content? Silverlight. C# (or any other CLR language), most of what I'm familiar with, without having to worry about relearning my tools or language.
Websites? ASP.NET. C#, most of what I'm familiar with, without having to worry about relearning my tools or language.
Re:But the political reasons... (Score:5, Informative)
I am not a Mono dev, just an occasional contributor via Google Summer of Code, but I don't really see a reason you can't do both. I think it's kind of obvious, really--Java's the same way. If you stay "within the lines" (which are usually very clear), your code will be cross-platform. If you do more out-there stuff, it's going to require more and more work to make it work in a cross-platform manner.
(.NET/Mono is already pretty awesome even for projects that require native libraries, though. Package libfoo.dll and libfoo.so in with your executable and assemblies, and it will intelligently grab the right one on Linux/Windows. Not so easy on BSD, Solaris, or OS X, but those really aren't primary platforms for that particular effort.)
Re: (Score:3, Interesting)
(.NET/Mono is already pretty awesome even for projects that require native libraries, though. Package libfoo.dll and libfoo.so in with your executable and assemblies, and it will intelligently grab the right one on Linux/Windows. Not so easy on BSD, Solaris, or OS X, but those really aren't primary platforms for that particular effort.)
Actually, it is just as easy on MacOS X. My company's SDK is .NET based, and we provide a "Mono version" for both OS X and Linux. Of course, the .NET assemblies themselves are the same, but there's just a couple of parts that are platform specific, which here we'll just call "libfoo". I can package in "libfoo.dll", "libfoo.so" and "libfoo.dylib", and it happily works on Windows, Linux and OS X. Not sure about the BSD and Solaris worlds though. Worst case scenario, it should be trivial enough to check f
Re: (Score:3, Interesting)
Not necessarily. Intel seems to do pretty well with x86-64, better than AMD even. Apple has finally brought Unix(tm) to the masses. Fujitsu's processors are better than Sun's.
Re: (Score:3, Interesting)
While that is true it actually rarely matters in this case. How many stable dotnet applications actually require dotnet 3.5? The commercial application I'm using on both MS Windows and linux is using version 1 (and development is continuing with that version), and there's a whole lot of stuff using version 2 - it seems every time you install a dotnet program on MS Windows you need to
Re:But the political reasons... (Score:4, Informative)
A third party implementation of a standard defined by the first-party implementor is always going to lag behind the original. Even if .Net is technical nirvana, if your platform's only implementation comes from a third party, your platform is a second-class citizen.
Only if you care about or need the "latest whizz-bang features". For most serious development I've never needed anything over .NET 2.0 so far, which Mono implements very admirably (plus a bit more).
Yes, it does mean I need to be a little more careful if I want things to run cross-platform - mono isn't in itself a final solution for cross platform stuff, and it's VERY possible to write Windows only code, Linux only code or even MacOS only code when using the .NET Framework and/or mono, but if you're targetting being cross-platform it really isn't too hard to do, and you definitely don't feel "second class" with the current mono versions (definitely did before there was much .NET 2.0 support, but because everything above that is "fluff" to someone developing core back-end stuff, there's been plenty of time for catch-up on the stuff that matters).
then you shouldn't be using Linux either (Score:3, Interesting)
A third party implementation of a standard defined by the first-party implementor is always going to lag behind the original.
Linux, GNU, GNU C++, libc, and many other tools that we take for granted all started out as clones of proprietary software from a litigious, monopolistic company. So did many other open source projects. If people had followed your reasoning, free software and open source software wouldn't exist. .. What matters is that when developers and end users pick a technology, they pick the l
precisely the problem (Score:4, Insightful)
Mono developer = Microsoft .NET developer, but a Microsoft .NET developer != Mono developer.
And that's a good thing? If Mono were merely a separate 'take what you like and leave the rest' clone of .NET it wouldn't be so bad, I guess. It might be yet another potentially portable platform (albeit one that carries vague patent threats).
But Miguel has actively promoted it as a way to get all that great .NET code being developed out there onto Linux. And that it is not. Probably never will be. Microsoft certainly doesn't want it (or won't once they displace Flash), and Miguel can't do it in any practical way.
He'll come close. Achingly close. But Mono code will be limited practically to Linux. Or it might work on Windows in whatever limited way GTK stuff works there today. Certainly not likely to work on Mac's or various phone platforms.
And there are technologies that already work on all those platforms. If Microsoft wanted it (and if anybody would - or could - ever trust them), .NET could work on all those platforms. But they don't, and it won't.
So keep working on Mono. It may someday be a nice technology in its own right. But *please* stop trying to justify it by saying that someday it'll make all Windows code 'just work' on Linux. Does anybody really believe that?
Re: (Score:3, Insightful)
Certainly not likely to work on Mac's or various phone platforms.
I use it on a Mac... professionally... My only complaint with it on MacOS is that I can't reasonably expect an end user to have mono, and so I tend to include the whole thing in to the one package, which makes for amazingly large looking programs when the basic functionality is so small (especially when I've just migrated a Windows app that was only a "few hundred KB" (as far as "migrating" goes - my Windows .NET apps do "just run" on mono, as that's actually one of my strict requirements at my workplace,
Re: (Score:3, Insightful)
> But Mono code will be limited practically to Linux. Or it might work on Windows in whatever limited way GTK stuff works there today. Certainly not likely to work on Mac's or various phone platforms.
I really don't get why some people are thinking inside the box like this.
Who said Mono is interesting only for WinForms/Gtk applications? Who said Gtk can be the only cross-platform GUI toolkit for Mono?
There actually is a wx.NET effort (wxWidgets) which is not really popular, but instead of bitching about i
Re: (Score:3, Informative)
This is not true.
The majority of .NET code is bizlogic stuff. It stays within its "box", using only framework APIs and such. Stuff that's well-documented and, important for this discussion, already implemented in Mono. You get a lot of "woah!"'s when you copy their bizlogic app onto a flash drive, plug it into a Linux machine, and run it without even a recompile. Of course, there's no perfectly write-once, run-anywhere architecture, and sometimes you will encounter oddities from OS to OS in applications (th
Re: (Score:3, Insightful)
Hmmmm. That might be OK is Mono was leading and not following, and it might be OK if people were not developing all their code on the .Net platform first before trying Mono. Alas, neither is the case.
healthy distrust (Score:5, Informative)
Microsoft has a history of using patents to protect its desktop market share. They attempted to scare people out of using open source software because it supposedly violated 235 of their patents. Therefore, I believe it is prudent that the open source community remain sceptical of Microsoft as well as implimentations of any of its technology including the .net platform.
Re:healthy distrust (Score:5, Insightful)
Miguel has smacked around this stupid argument before. Mono is a relatively small effort. There are people certainly violating Microsoft's IP in areas like Samba and the myriad Exchange clients, which are a far bigger threat to Microsoft's revenue streams. Mono, if anything, improves their revenue streams, because it makes .NET more feasible for some developers who otherwise wouldn't consider it.
But they're going to go after Mono, right? Let's just ignore that Samba 4 is (supposedly) going to eat Microsoft's lunch on the AD side of things. They're gonna go right after Mono! Rar! BE SCARED! Because that makes so much sense for them to do, right? It's not cutting off their noses to spite their face at all.
I'm really starting to think that the main reason Slashdot gets pissy over Mono is because Microsoft doesn't "lose" because of it. It's a case where everybody wins. And Microsoft can't be allowed to benefit, oh teh nos. :(
Re:healthy distrust (Score:5, Insightful)
Miguel has smacked around this stupid argument before. Mono is a relatively small effort. There are people certainly violating Microsoft's IP in areas like Samba and the myriad Exchange clients, which are a far bigger threat to Microsoft's revenue streams. Mono, if anything, improves their revenue streams, because it makes .NET more feasible for some developers who otherwise wouldn't consider it.
In the past, Microsoft has "cut off the air supply" of competitors. That's difficult to do with Linux as it is less a single-sourced product line than amorphous multi-vendor entity. Microsoft's strategy then has been to try and pigeon-hole Linux. But how to do that? You need to become a gate-keeper.
That's the fear over Mono. Gain developers. Gain support. Develop a dependency. Pull out the patents and seize the keys to that dependency. You are now the gatekeeper.
So what about SAMBA 4 and Exchange compatible clients? Don't they also support Microsoft products? That's win-win too, right? Surely they wouldn't go after those. Or would they? Who knows. Ballmer's threats lack detail.
And there's the key. You want to make your "everybody wins" technology widely accepted? Stifle the threats from a CEO who's continues to generate distrust in your company. No tin foil hat required.
Re:healthy distrust (Score:5, Insightful)
The difference between Mono & Samba is that C# is dev language.
If, for instance, Samba is sued into oblivion by Microsoft then we loose a single application. Yes, it's sad and everybody cries... but there's technical ways to solve that problem that are relatively doable - such as developing a new NAS network transport protocol that doesn't break any patents.
Alternatively, if Microsoft sues Mono into oblivion - and we've all been happily developing C# code for hundreds of applications - then it's going to be a total meltdown.
To be honest though - there's not much of a chance that either of those things are going to happen.
I like C# - it's a smart, clean language. I don't utilize much beyond the stock language (2.0 & generics) and don't see much need too.
Re: (Score:3, Interesting)
There's one vital difference. Samba is not adhering to a standard that has been ratified by the ECMA that they can use to say "Ahhhhh, you're infringing!" and where the ECMA has not ruled that it w
Re: (Score:3, Insightful)
> Gee. I was quite certain that ECMA was the gatekeeper..
Right.... ECMA is where crooks and liars go to get an official looking stamp put their turd sandwiches. And even the ISO proved to be corruptable by the huge sacks of cash Microsoft can toss around.
Re:healthy distrust (Score:4, Insightful)
Yes, fear. Make all companies fear using/donating to/working on open source because they might be sued.
When Ballmer stands in front of a crowd and states that Linux has violated patents... people (albeit stupid) will listen. It would be like an alien race telling everyone that they are going to destroy Earth, then waiting for everyone to leave.
Re: (Score:3, Interesting)
Ballmer has said Linux violates 235 patents. That is using their patents.
No, they are never going to identify any patents or do a real court case, unless there is a significant change in the environment (like they are actually threatened by a competitor using Linux). The threat is much more effective.
They refuse to ever identify any patent directly. The reason they do this is that the patent may be shot down for prior art, or that it will be shown that Linux does not violate it, or that it will take about 1
clone or unique, but not both (Score:5, Insightful)
Mono is in a precarious, teetering position. Somewhere between tepid and antagonistic reaction amongst professional and casual developers, a designer community that is seen as a puppet or apprentice to the hegemony, and not even a clear path forward for compatibility. Be distinct, or be identical, but there's no way to be both.
Re:clone or unique, but not both (Score:5, Insightful)
I still honestly don't see what the supposed benefit of Mono is supposed to be. If you want to write nice graphical applications, there's plenty of toolkits available for C, C++, Python, etc. Many of them are even cross-platform, so making a version for a different OS only requires a recompile. If you want truly compile-once, run-anywhere code, there's already Java. What's the point of Mono?
Qt (Score:5, Interesting)
With Qt 4.5 going LGPL in March, one would have to wonder why you would use Mono over Qt or Java.
There are legitimate reasons - the CLR for instance or the multi-language support. But Qt has a Java API if you're addicted to virtual machines, and the C++ toolkit compiles anywhere with a modern C++ compiler. It supports Javascript (QtScript) and Python bindings. But unlike Mono, which is Microsoft derived, there will be no patent worries. Nokia really does want Qt everywhere.
The picture is getting more and more complicated when it comes to software development, and I think that's wrong. I liked .Net as an idea. We could all code to one platform, but the business/IP aspects prevented that technical utopia. I am hoping that LGPL Qt will, while a little more limited be that multi-platform toolkit that everyone can use to solve new problems, instead of continually recoding the old ones.
Re:Qt (Score:5, Informative)
Because you need to consider your target audiences - Windows users vs Linux users.
Not to make this a flamefest about intelligence, but I think we can all agree that, almost by definition, Linux users tend to have a far higher comfort level with trying new things on their machines.
Simply put, Linux users, if they want to use a given package, will install Wine/Mono/Dependency-X to get the package to work. Windows users will not install QT unless it comes as part of the whole one-click
Re: (Score:3, Insightful)
Just compile statically, and you won't have to bundle anything. OK, you'll probably need to include the mingw10.dll. And libmysql.dll if your app accesses a MySQL database, like mine does.
I've read some things that make me think that you can build the mingw library into your app, but I've also read things that make me run away from that idea screaming.
Also, it's probably possible to build MySQL statically, and then wrap it into the executable as well, but it's not something I want to try.
Re: (Score:3, Informative)
Lucky for Windows users, Windows will always search the current directory first for DLLs that an app needs. So just include them. QtCore4.dll and a few others. Many apps ship their own version of Microsoft's DLLs just to make sure the app will call the correct version without worrying about a newer version being in system32 or the wrong version being called from WinSxS.
No, there is no case for using Java or Qt now. Qt looks sleek on every OS and is SO incredibly easy to program. It is native and is very fas
Re:Qt (Score:5, Insightful)
Speaking as a long time windows user and being fairly new at using Linux as a dedicated work-OS, I must say that that whole one-click .msi stuff is pretty damn awesome.
To elaborate the whole perception that users are dumb is pretty misguided. I'm not a dumb user, but even I like things to be easy. It's because (usually) I don't give much of a shit how the thing works, just that it does.
Before you declare that you're any different, think of how you put gas in your vehicle.. Do you care how the fuel pump works? If you're like me you only throw a fit when the clip that holds the fuel lever open is broken, but otherwise don't pay much attention.
See it's about motivation not intelligence. I do like using OSS because I think it's a GoodThing(tm) therefore I'm motivated to try it. It's a lot of the reason it took so long for Java to get a toe hold. "I just want to run PrettyWidgetBox, wtf is this JVM thing I have to have?" It's seen as ancillary or superfluous to the average user, and they don't often care enough to figure it out.
It kinda spoils one of my favorite quotes for me though regarding trash cans, bears, and tourists. Yellowstone added some trash cans with tricky openings to keep the bears out, but it turned out most of the tourists couldn't figure it out. The quote goes, "It turns out there is considerable overlap between the smartest bears and the dumbest tourists." Which is unfortunately hogwash. The bears are motivated by survival to get in the trash can. The tourists are demotivated by apathy to take the time to figure out a trashcan. They just want to be able to put shit in the trash hole and be done with it. If they're frustrated for more than a few seconds they just throw it on the ground.
As far as I know (Score:4, Insightful)
There's no reason it can't. I recently bought some new virtual instruments. Those are large sets of samples of real instruments, combined with playback software for making music on the computer. They came with a new sampler I'd never used before, developed by the company that sells them (EastWest Play, if you are wondering). I was mildly surprised that as it was installing I saw Qt4Core.dll, Qt4Gui.dll and QtNetwork4.dll were copied to my system directory. Turns out they decided that QT would be good to use for drawing the GUI. Probably in part because it's Mac and PC.
At any rate, there was no additional install of QT required. The necessary libraries were included in the installer, and installed to the system with the software. So if you wish to use QT for your program, go for it. Windows programs very frequently include third party libraries (FMOD would be a popular one with games). You just have the installer handle it.
However comparing QT to .NET is kinda off base, they aren't the same. The reason to use .NET is because it is a managed framework, just just because it can do GUI easily. Visual C++ provides easy GUI tools and will compile to native code.
Also using .NET doesn't preclude using QT, there are bindings for QT to C#.
Re:Qt (Score:5, Interesting)
That's a rather rosy way of looking at it. In truth, Sun sort of messed up the marketing on a variety of different levels. The only reason why it caught on was that developers had a chance to try it out through Java Applets. (Originally supported through a partnership with Netscape.) Developers who tried the Java platform were so impressed by it (compared to the standard C library of the day) that they lobbied for its use everywhere. In fact, there was an entire news site devoted to Java promotion called JavaLobby. In its day, it handily competed with sites like Slashdot for readers.
Sun (thankfully) wasn't stupid. They took a look at where developers were trying to use Java and started supporting them. Some of the ideas took flight (e.g. servlets) while others floundered (e.g. Java3D). But at the end of the day, Sun managed to produce a superior platform that the vast majority of the market wanted to use.
The only reason why it gets so much criticism today is because other languages and platforms have invested considerable effort in catching up to where Java is today. And even then, it's hard to argue the rich availability of libraries for the Java platform. If you use Java, you are guaranteed to always be able to use the latest and the most obscure technologies. Nothing escapes its roving field of vision.
When Java gets replaced (and I'm sure it will happen eventually), it will not be because of marketing. It will be because the replacement platform yet again turns the entire industry on its head. Love it or hate it, the new technology will make us all step back and think.
Re: (Score:3, Funny)
cut kitty screen saver? count me in!
Okay, I'm a pretty pro-Linux guy. But even I'd never portray the Windows masses as kitten murdering mascochists.
Think before you post, you sick fuck!
Why not develop on the JVM instead? (Score:5, Insightful)
Now that Java is open source, wouldn't it make more sense to use the JVM as the standard runtime, instead of something that "might" not get sued for copying the .NET runtime?
Java has already been made to run on .NET. I wonder if it'd really be that hard to get standardized C# running on the JVM?
Re: (Score:3, Insightful)
Well, lets take WPF as an example. There are, and have been for years, equivalent Java frameworks. SWT and Swing really aren't the same thing at all, they're widget toolkits, not presentation frameworks.
What would have stopped WPF from being implemented on Java? Nothing. Nothing except the narrowly self interested strategy of one company, who could have provided a technology that EVERYONE could use on a mature platform, but instead we have no such thing. Instead man lifetimes worth of engineering talent had
Mono just miss one thing (Score:4, Informative)
Re:Mono just miss one thing (Score:4, Interesting)
It's unfortunately not easy to develop on Mono right now, but IMHO only due to the debugger.
I disagree. MonoDevelop is the bane of my existence. It's not even that it's missing features - it's that the damn thing crashes randomly and the basic features (like code completion) are broken. It's been this way for me for years... so long that I almost wanted to start contributing to the project. But then I just installed Visual Studio 2008 on a Windows VM and it solved everything.
I swear, I haven't really hobby coded too much since I started using Linux years ago. Part of it is because I have everything I need and don't need to change much. The other part of it is that I haven't used a single goddamn IDE in Linux that doesn't make me want to shoot myself in the face. Fanatics can gab on about how a real developer doesn't need a a decent IDE, and that's true - but what's also true is that once you've had access to elegant debugging, code completion, and compilation, you don't ever want to go back.
WPF Support (Score:5, Interesting)
Until Mono gets WPF support there isn't going to be much cross-compatibility. Any Windows .NET developer with any sense is writing in WPF already. WinForms is dead.
But Mono seems quite content to ignore WPF for now. One can't help but think it was part of that Novell/Microsoft deal.
The subset of WPF in Moonlight is useless for non-web development. It's great way for MS to pretend their Flash-killer format is multi-platform though.
Re:WPF Support (Score:5, Informative)
Until Mono gets WPF support there isn't going to be much cross-compatibility. Any Windows .NET developer with any sense is writing in WPF already. WinForms is dead.
This is pretty lame reasoning - new applications are only part of the reasoning behind deciding which apis to support. Supporting the huge number of *existing* applications is also important, and the vast majority of the desktop .net applications out there now use winforms.
But Mono seems quite content to ignore WPF for now. One can't help but think it was part of that Novell/Microsoft deal.
More faulty reasoning - have you seen the WPF api? It's enormous. As one of the people with the most commits in WPF-land, I can assure you, it's not prioritized based on any deal. It's strictly a resource issue. Moonlight is just more bang for the buck. Much smaller api to implement, much quicker adoption than WPF. Makes good business sense. That said, WPF remains a spare time project for me (and others).
The subset of WPF in Moonlight is useless for non-web development. It's great way for MS to pretend their Flash-killer format is multi-platform though.
Again, not really true. Silverlight 2.0's api is more than capable of building apps for both webpages and desktop, and will become more so as WPF and Silverlight converge. It will take some extending on the mono side for desktop integration, but again, when the choice is using an existing technology and extending it slightly (as in Moonlight) or starting fresh on a GIANT api (as in WPF), which would you choose?
Re:WPF Support (Score:5, Insightful)
Only Microsoft consultants will tell you that WinForms is dead. I've know developers at 2 organizations that moved from WinForms to WPF, and they hated it. (Caveat: I was at one of them). The app went from using 10MB of RAM to 200MB. It went from a minute to compile to 15 minutes. It went from taking 2 hours to make a change, to taking 2 days.
WPF is powerful, robust, pretty, inefficient, hard to use, and in beta. (Yes, Microsoft says it is not beta, but WPF is still not ready for anything more than experimental use.)
As for Silverlight, since it offers no benefit over Flash, and since even Microsoft Gold Partners have told me that they use Flash unless forced to use Silverlight, I think it will be a non-competitor unless Microsoft starts shipping it with the OS (maybe they do in Vista - if so, then Flash is dead no matter how good it is)
I wouldn't say WinForms is dead.. (Score:5, Insightful)
WinForms isn't dead. In some circles, I'd say WPF is stillborn, and if there's anything good that came out of it, it was in fact Silverlight.
In fact, I would say that while WPF has its plus sides, its got a few drawbacks as well. Its -really- slow compared to WinForms, the nested control architecture isn't as good, the layouts and sizing aren't as flexible, and worst of all, there's no datagrid.
I understand the inspiration. Microsoft tried to make a modern client gui toolkit that gives you some of what html does, but I frankly think they missed the mark. If anything, WPF will inspire the idea that developer's have choices in control and widget sets and that will lead developers to look at things like Qt and Java or even Webkit, as I have done.
Sorry, I will never trust Microsoft (Score:5, Insightful)
Sorry, I will never trust Microsoft enough to put them in a position to control a key technology. So that means there is no discussing the issue as far as I'm concerned. There is NO rational basis to argue. I don't trust em.
And I don't trust the judgement of anyone who isn't themselves suspicious of Microsoft and Miguel's motives.
Mono is a trap if it is allowed to be deployed beyond a browser plugin to support .net content in the browser. Come the day my current distro of choice loses any finctionality when removing the mono packges I'll be running something different as soon as bittorrent can supply me a new install image. Again, that position is 100% non-negotiable. I have used binary drivers in the past, bought closed source apps and committed many 'sins' against the Church of GNU but this is one case where compromise simply isn't possible. They want us dead, you can't compromise with that.
Re:Sorry, I will never trust Microsoft (Score:5, Insightful)
I haven't sent a "100% agree with everything you just said" post to anybody since I started dropping by here a couple of years ago. Time to change that.
You're right.
Regardless of its virtues, expecting Microsoft to use Mono as anything but a club to beat Open Source to death is plain stupid. Their track record in this respect is far beyond arguable, and their part in the ISO situation proves they have no intention of changing. You'd do better expecting discipline from a starving weasel in a hen house.
Re:Sorry, I will never trust Microsoft (Score:5, Funny)
Captain's log, stardate 9522.6: I've never trusted Microsoft, and I never will. I could never forgive them for the death of Netscape and countless other companies. It seems to me our mission to support .NET on Linux is problematic at best. McAllister says this could be an historic occasion, and I'd like to believe him, but how on earth can history get past people like me?
They're animals. Don't believe them. Don't trust them.
(They're dying)
Let them die!
Sorry, I couldn't resist. I got a kick out of the way you started your post.
Joking aside, mod parent up. :-)
What's the point with Qt now fully free? (Score:5, Insightful)
Most people think of Qt as a GUI toolkit. They're not wrong, but that's like calling a Swiss Army Knife a "pocket knife." That's only one thing it does, and the characterization completely misses the point. Qt is an application framework. It fixes every gripe developers have with C++.
Qt promotes clean and well-developed code that is easily ported to Windows, X11 (Linux et al), Mac, and Embedded (Linux sans-X11). That's something even Java doesn't do well (have you ever tried porting between J2SE and J2ME? nothing works!), even disregarding the whole performance loss from the JVM emulation-like interpreting that goes on.
The LGPL relicensing [qtsoftware.com] of Qt coming this spring will change the entire programing language landscape. Nokia is moving in to crush Java. C#/.NET and it's mediocre OSS implementation in Mono aren't even on the radar.
I cite the LGPL announcement because that's the kiss of death, placing Qt firmly above GTK (GTK being an incidental casualty on the way to said crushing of Java). With Mono relying so heavily upon GTK#, that puts it behind the game already (the Qt# [mono-project.com] project is cited on the Mono page as completely dead).
Recall that Nokia is a phone company. They need not make money from the software. Freeing and promoting Qt (and getting it to supplant J2ME) merely feeds this primary function. And while they're at it, they're sweeping in a wonderful set of perks for software engineers in and out of the Free Software community, on both embedded platforms and desktops.
Re:What's the point with Qt now fully free? (Score:5, Insightful)
Qt is an application framework. It fixes every gripe developers have with C++.
Except for the fact that you are still programming in C++ which is bloated, monstrosity of a language.
Qt promotes clean and well-developed code that is easily ported to Windows, X11 (Linux et al), Mac, and Embedded (Linux sans-X11).
It doesn't seem to promote to well considering the amount of crappy C++ code written with Qt there is floating around.
Nokia is moving in to crush Java.
Considering Java's biggest adopted base is in server-side programming, I really doubt Qt is going to do all of jack and shit to change that. I seriously doubt many of those people writing server-side apps in Java would even have a use for Qt in their work. Sure it might pull away some of the desktop app developers, but they have been pretty much the minority when it came to the adoption of Java anyway.
Re: (Score:3, Informative)
Objective-C
Re:What's the point with Qt now fully free? (Score:4, Interesting)
Amazing what difference a license change makes, eh ?
Re:What's the point with Qt now fully free? (Score:4, Informative)
No, QT is a library. It provides (very good) APIs to C++ programmers to do most of the really onerous crap that C++ developers are tired of doing, and are doing in a hundred different ways already.
Stereo is Better... (Score:3, Funny)
Come on, this debate's been over since the mid-1960s. Stereo won, Mono lost... end of story.
All this time and (Score:3, Funny)
it just dawned on me...
Microsoft is giving Linux Mono!
I guarantee, if you grep the source, you'll find epstein-barr.
People seem to use Mono to go native MS if needed (Score:4, Insightful)
AFAICT people use mono to go MS 'native' - meaning .Net - when needed. The only non-trivial application in Mono I can think of right now is Unity [unity3d.com], and that's a closed-source RT3D toolkit for x-plattform developement on Mac OS X. And apparently a very good one at that. They are being bugged left, right and center to deliver on Windows. And are preparing that now.
I have to admit that Mono has gotten me curious, because Monodevelop is a very neat looking IDE, C# doesn't seem so much of a PITA than C++ or Java and it appears to be more suitable for stronger ties to multimedia hardware than Java. I still haven't seen a convincing multimedia app in Java in 10 years, allthough the current 3D stuff with native OpenGL does look and run well.
On top of that it appears to me that Mono apps are easyer to deploy that Java apps. I'd expect Java developement to get up to speed fast in any revent Version of Netbeans. However, I catch myself still trusting Mono for good performance more than Java.
Bottom line:
Going Mono to me basically means nothing other than spending time learning C# and watching out that no MS dependancies sneak into my work. A risk I'd be willing to take, given that it has evolved into a feasable tool recently. However, the don't-trust-MS arguments delivered here are valid, and you ought to know what you're doing and calculate your risks well when dicking with MS-controlled tech.
Re:The thing is... (Score:4, Informative)
Re:The thing is... (Score:4, Insightful)
"If I was going to buy a new car, it would probably be Ford or Chevy and not GMC."
"Ford and Chevy aren't cars," would be one possible response, but an unnecessary attempt at correcting something that could have been interpreted in a way that made sense to begin with.
It makes sense to speak of a language being
Re: (Score:3, Informative)
Yeah, that's because most ARM platforms can execute Java bytecode natively.
The processor IS the JVM.
Re:The thing is... (Score:5, Insightful)
Learn x86, C, Java, JavaScript. EOL.
Anything more is bonus.
Anything less is lacking.
Re:The thing is... (Score:5, Insightful)
Then you are a fool.
Axioms of software design:
1. Algorithmic improvements will always trump optimizing execution speed.
2. Unless there is a hard requirement, development time is more important than raw performance.
3. Hardware is cheaper than developers.
4. A rich and flexible library is more useful and stable than custom coding for performance.
Re: (Score:3, Insightful)
More axioms:
1. Once the application is developed, you will be told that there is a hard requirement that no one knew of, until faced with waiting 5 seconds per record commit.
2. Once the application is developed, rewriting it in C++ is almost as difficult as writing it that way from the first.
Re: (Score:3, Insightful)
I think we have to be careful not to dismiss interpreted languages, and not to think they should be used everywhere either. Each language has a place.
I have to disagree with statement #2 though. In my research, it seems that it is usually quicker to prototype and THEN write in C++.
To prototype in something like python usually saves a lot of time.
Re: (Score:3, Insightful)
More axioms:
1. Once the application is developed, you will be told that there is a hard requirement that no one knew of, until faced with waiting 5 seconds per record commit.
2. Once the application is developed, rewriting it in C++ is almost as difficult as writing it that way from the first.
There's one you forgot:
3. After rewriting your application in C++, you find that it still runs as slow as it did before. This is because all it does is calling a bunch of library calls, which is going to be the same performance-wise in C++ and C# (and Java, and for the most part even Python...).
Re: (Score:3, Insightful)
1. Algorithmic improvements will always trump optimizing execution speed.
And what are these magical algorithms that only work in Java and C# but don't work in C/C++?
2. Unless there is a hard requirement, development time is more important than raw performance.
I fail to see how Java and C# reduce development time.
3. Hardware is cheaper than developers.
You have clearly never done any embedded work. You think a customer is going to want to pay the extra money for a device that runs Java instead of one that does the same thing and runs on a $1 micro running C/C++? Furthermore if you seel 100,000 pieces, every $1 of hardware is $100,000.
4. A rich and flexible library is more useful and stable than custom coding for performance.
Depends on the application. Write a CAD tool in Java and see if customers
Re: (Score:3, Insightful)
I would rather pay $100 more for a sleek native program vs a Java one.
Like M$ word, or perhaps the highly responsive XL. Or the ultra sleek and responsive vista OS with 1/2 the memory footprint and 2x the performance....
Bloat, sleekness, performance is much much less a function of language than *how* that language was used.
Re:The thing is... (Score:4, Interesting)
Re: (Score:3, Interesting)
Yeah, because you can compile standard C and standard C++ on just about EVERY platform. Unfortunately the phone OS makers do not want us to make native code and instead want us to program Java apps. With that we will never be able to trash the idea that phone apps are slow and pseudo-3D.
Re:The thing is... (Score:5, Interesting)
I used to code Java in the JDK 1.1 - 1.4 days. It sucked ass. It was slow, had weird dependencies on X11, required a lot of boilerplate code (such that up to half of the LOC could be logging inside exception blocks), had various JRE incompatibilities all over the place (such that some applications just couldn't be run bug-free on ALL of AIX/Solaris/Windows/Linux/Mac), and the reference JDK/JRE was Sun's proprietary property. I left Java and went on to C, Perl, C++, and Lisp. Naturally I used Emacs and SLIME.
Then I found Clojure. And I got a $350 laptop from Walmart last week that had 3 gigs of RAM and a single-core 1.8GHz AMD processor. And I thought, "I wonder if Eclipse will run decent on this thing?" And it does, and it's not all that slow, and it is by far the best IDE I've ever used.
I'm now re-climbing the learning curve on modern Java, and it's looking pretty good now. AspectJ does a good job eliminating a lot of repetitive code, eclipse-metrics warns me when I'm not being decent at OOP design, and the available libraries are top-notch. Java the language isn't so bad anymore, and now with Clojure on top I have plenty of linguistic room to prototype and get to choose the best among many paradigms for each situation.
Give Java a fresh look, it's come a long way.
Re: (Score:3, Insightful)
Java the language isn't so bad anymore ... Give Java a fresh look, it's come a long way.
The problem is that other languages came a long way too. Today, not having support for closures for a language is a shame (consider that VB has it already for more than a year now, and even C++ is adding it) - yet we are not going to see that in Java 7, that's still more than a year in the future, and God knows when Java 8 will be released, if it ever happens. Some other stuff in Java is rather messed up - generics are a prime example of that. It really is becoming a language that is too burdened by backwar
Scala (Score:3, Interesting)
Re:What are the mysterious patents (Score:5, Insightful)
There was a famous story about Sun and IBM that got aired a lot during the MS antitrust trial. It goes like this:
One day, a bunch of IBM patent lawyers show up at Sun's headquarters, saying that Sun is infringing on patents A, B, C, etc. They demand a hefty license fee. Sun engineers (remember, it started as a company of engineers) sit down in a boardroom with the lawyers, look at the patents, and are surprised--they're for various obvious things like mathematically adding a variable stroke to a line, and such. The engineers walk the lawyers through their own patents, explaining how they're all obvious and wouldn't stand up in a court of law. The lawyers remain silent until they're done. Then the chief lawyer says "Perhaps you're right. But after one big court case dragging on for years, we'd just come back with another set of patents and repeat the whole process. Eventually we'd find something that you'd infringed on, and then you'd have to pay damages rather than a licensing fee."
Sun signs a cross-licensing agreement with IBM the next day.
That's the worry. It's not that Microsoft has patents that can allow it to launch SCO 2.0 with a better hope of success. It's the worry that, if they decide to snuff out Mono, they can launch a legal crusade to so encumber Mono in litigation and FUD that it dies an ignominious death. Then all that effort is wasted, OSS and Linux get a bad name in the process, and a lot of developers and customers are soured on Mono, Linux, and anything that doesn't come from a Fortune 500 company. This is why Novell signing a patent cross-licensing agreement caused such bad blood--it implies that MS does have patents that are or could be infringed. On the fateful day that MS decides to crush Mono, Novell's agreement strengthens MS's case, if only in PR terms.
Re: (Score:3, Insightful)
I know the story, but I don't see how it is relevant here. Microsoft could do the same thing to Java, or anything else for that matter. If the only argument is that "Microsoft might strong-arm you out of the market" then nobody else on the planet should write software.
I agree with you about Novell - my hatred for them is the strongest reason I avoid Mono.
Re: (Score:3, Insightful)
It's not just that MS might come after you. It's that Mono, being an OSS implementation of .NET, would appear to be uniquely vulnerable to being crushed by MS if the beast deems it to be too great a threat, in a way that Java isn't as an independent technology.
C# and the CLR are ECMA standards, and as part of the standardization process, MS gave up the ability to make any patent claims. The idea that Microsoft might somehow be able to torpedo Mono is pure fantasy.
Hell, there's not even much reason to think Microsoft would want to torpedo Mono. They wouldn't have submitted their standard to ECMA if they didn't want it to be implemented.
Of course, all the logic and explicit legal agreements in the world won't change the minds of the folks here who are dead-set on t
Re:What are the mysterious patents (Score:5, Insightful)
Nope. ECMA has not forced Microsoft to give up its patent claims. The only requirement with respect to patents is that they be available under "reasonable and nondiscriminitory" terms -- which basically means that Microsoft can charge whatever it wants for patent licences, as long as it's the same fee for everyone. So MS can still threaten to sue for patent violations. And any fee of significant size is of course fatal for free software. So you are wrong.
Re:to the casual observer (Score:4, Insightful)
not very successful proprietary virtual machine and framework
So .NET is not successful? Can you please explain why, exactly, a technology that counts millions of active developers and thousands of products is not "successful"? What exactly constitutes success, in your book?
has been partially abandoned by its own masters
Uh, abandoned how, exactly? Please be specific, you were modded up for your comment so I assume you have more than just a Slashdot-style FOSS advocacy blurb here to back it up.
You might recall Microsoft spent like three years rewriting parts of Windows in .NET
You might recall that they did indeed rewrite parts of Windows in .NET, like the management console subsystem and several tools like PowerShell. Were you expecting them to rewrite the whole thing in C#, and is that why you claim .NET is not successful? And please, I'd like to see some evidence that they didn't do something they claimed they were going to do in Vista with .NET, because as far as I remember they did exactly what they said they would - nothing more and nothing less.
Maybe we can learn from their very expensive learning experience?
Maybe you can cut down on the impressive-sounding hyperbole a bit. I feel liked I just walked into the Slashdot Spin Zone(TM) here.
Re:to the casual observer (Score:4, Informative)
Wow....what? .NET is pretty much everywhere now...and parts of Windows -ARE- in it...not the kernel, no (thats like saying C/C++ are failures because you still need assembly for performance critical parts...), but a significant chunk of the user land tools, and a very very big portion of the various tools Microsoft provide are in .NET... from PowerShell, to Sharepoint, going by parts of Visual Studio, SQL Server, Biztalk, the UI of most of their new tools and components, etc.
The huge chunks of legacy code (Office...) can't easily be ported for obvious reason, but abandoned platform? Thats amusing as hell.
Re: (Score:3, Insightful)
but a significant chunk of the user land tools, and a very very big portion of the various tools Microsoft provide are in .NET... from PowerShell, to Sharepoint, going by parts of Visual Studio, SQL Server, Biztalk, the UI of most of their new tools and components, etc.
What you've done right there is called "damning with faint praise".
Re: (Score:3, Interesting)
Yep that's right. I remember back in the day, I worked at a Microsoft "Very Valued" Partner which basically meant they could screw you over whenever they wanted just because and if you didn't comply, no more partner for you (*yank MSDN library and cheap licensing*). I almost brought the company to the brink of losing their partnership just by recommending Linux machines (which we did sell but apparently not advertised) to users that needed a xAMP stack.
Either way, the company had to build their own ERP (sim