I like that comparison. It also doesn't hurt that the Qyoto QT bindings for.NET have gotten quite nice, to the point where I'm seriously looking at dumping WinForms for Qyoto. That'd make app porting even easier.
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 (though, like Java, bizlogic stuff tends to work right out of the box without trouble--it's when you get into more complex stuff that there can sometimes be issues). But these quirks exist everywhere, and rarely are they so significant that the applications don't run straight off the top. Now, the problem with cross-platform capabilities with Mono (at least before the Foundation frameworks like WPF and WCF, which very few people actually use because they're overengineered crap) is native code libraries. People find something they want to snarf up into a managed code app, so they do it. But if you've got builds of that library on multiple platforms they can be ported and packed with the executable to intelligently pick the native code library based on which OS it's being run on (picking libfoo.dll on Windows, libfoo.so on Linux, libfoo.dylib on OS X).
Regarding "might work on Windows"--Mono has a build for Windows. It works fine. Some small theming issues, but it works. System.Windows.Forms is supported on Windows, OS X, and Linux, although I personally am looking into the Qyoto QT libraries for easier use (because WinForms, though easy, has problems).
Mono already works on "Mac's various phone platforms". (It runs very well on OS X; right now I'm testing an app for use on OS X 10.5.) It runs on the iPhone, too, thanks to their newish static compilation stuff.
So...sorry, but no. It works and it works fine. Nice work on the Insightful mods though. I suggest actually reading what you're talking about if you want to actually be insightful, though.:-)
I wasn't sure what OS X named its shared libraries, hence why I wasn't sure whether it'd work. As the other poster says, BSD/Solaris use the.so extension as well as Linux so I don't think it'd work right out of the box.
.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...
Excellent post. Drupal is the bee's knees, the ant's elbow, and the major arthroscopic joint of every other insect species in existence when it comes to open source content management systems.
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.)
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. (Bad example, though, because I personally use PHP and mod_mono isn't really good yet. ASP.NET MVC makes it a lot nicer to use though.)
Desktop apps on Windows/Linux? Bog-standard.NET/Mono. C#, most of what I'm familiar with, without having to worry about...you get the idea.
I used Java for much the same reasons when I used Java. Same language, same framework, different application for it.
(Plus, when it comes to Mono.CSharp and Mono.SIMD, I'm pretty sure you can package those specifically with your program to run them on the Windows.NET CLR. For Mono.SIMD in particular, it actually falls back to managed code on platforms without SIMD code support, which is a really nice feature.)
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.
Well, sure, and it's something to keep in mind, but--
To be honest though - there's not much of a chance that either of those things are going to happen.
--exactly, we both know it's a bullshit worry (and unlikely that people will develop enough C# apps for that to matter). This is all just a bunch of hair-shirting over nothing at all, I feel.
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.
I agree. My compiler targets ISO-3 because extension methods have come in handy and I like lambdas, but I target the.NET/Mono 2.0 libraries.
For your former point--what exactly does this do that Java doesn't? The Java runtimes update, too. Microsoft's update faster, but what of it? They're free to download and freely documented. You have to spend some time learning more, but only if you actually want to use it. LINQ (which I don't really use, I'm not a fan of it) is there, but it does nothing that cannot be done just as easily the "old way". The.NET guys don't deprecate stuff in favor of the new hotness in these sorts of cases; the old ways still stay fine. You can even use the.NET 1.0 non-generic types if you really want to. And unlike Java, you don't have ArrayList and ArrayList, with no under-the-hood difference (seriously, the type checking in Java is complete balls when it comes to generics).
As for mobile platforms--depends on the platform. The iPhone (and the XBox 360, which is obviously not a mobile platform but has similar rules) doesn't let software run other software, so Mono recently rolled out static compilation. The Mono static compilation system either currently does or is in the process of (I'm out of the loop, I worked for them for GSoC and haven't kept in touch much since) importing code from Linker to strip out the excess library cruft in those images.
On other mobile platforms such as WinMobile, Microsoft has the.NET Compact Framework. It's slimmed down mostly by removing Windows-specific libraries like WinForms, which takes up the largest amount of space. The "core" libraries like System.* (not the subtrees, but the language itself), System.Core (which includes LINQ), System.Web, System.Net, etc. are all really quite small. (You won't fit it on a 4MB Flash ROM, but if you're trying to do that you already screwed up when picking your tool set. Nobody's saying Mono's the solution for everything!) You're not going to have the upper-level libraries like WinForms on your toaster, but having them would be silly. Similarly, XNA (.NET on the 360) doesn't have WinForms, but does have libraries specific to the interfacing with the XBox 360 when running there and DirectX when running on Windows; you can use standard.NET libraries that are not included in the XNA redist when developing on Windows, but in years of working with the framework I've never found myself accidentially doing that or wishing I could get away with it. It just doesn't come up.
You make good points, but they're pretty much not problems, as far as I (and most other.NET/Mono devs, it seems) can see.
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.:(
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.
"Not being Windows" isn't enough to actually win, though. This is something that the Linux evangelists have never really understood, I don't think. The only way Linux is going to overtake Windows (and despite the fuckwits who call me a Microsoft troll or what-not, I'd love to see Linux do just that) is to be a better Windows than Windows. As easy or easier to use, as flexible or more flexible when it comes to applications. Thus, winning on merit.
Microsoft actually did something very cool with the Global Assembly Cache under.NET, but I have a feeling it would be damn near impossible to build something similar into Linux for native code libraries.
I think the important question to ask is this: if everyone's using the same packaging system (which they fucking well should, it's a no-brainer), then why not take that next step to basing all relevant distros off the same core distro?
I haven't had crapware on my last two laptops--I buy from Dell's Vostro line, which is their small/medium business line, and they don't put crapware on there.
I also think you're full of shit about drivers. On Dell's site you just punch in your service tag and it'll present you with all the appropriate drivers for your machine.
Yes. My audio never cuts out at random on Windows and I never have to make sure I have the exact version of some library (because most apps pack mission-critical libraries with them, thank god).
supports more hardware,
Certainly supports my graphics card a lot better. Hint: supporting "more" hardware is meaningless when you don't support my hardware, as far as I am concerned.
is more versatile?
Linux will run in more places, that's for sure--but where it matters to me, personally, it doesn't run as well. (I'm hoping that Android takes off for phones, though. Anything's better than Windows Mobile, and I won't buy an iPhone.)
"Compile from source" is a shitty alternative and essentially blocks proprietary development. The freetards will say that that's not a bad thing, but the freetards also think Stallman is right for doing crap like adding forced nag screens to emacs and screaming that others are bullying him when they say it's not a good idea.
Proprietary software development is not going away. Linux is not going to change "the market and system." Adapting to the way things work gives you a chance to move forward--not doing so does not. That means building a halfway decent cross-distro framework that ensures that if it runs on Ubuntu, it runs on SuSE or RedHat or whatever else. Not having that is pigheadedness at best.
Slashdot Mirror
I like that comparison. It also doesn't hurt that the Qyoto QT bindings for .NET have gotten quite nice, to the point where I'm seriously looking at dumping WinForms for Qyoto. That'd make app porting even easier.
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 (though, like Java, bizlogic stuff tends to work right out of the box without trouble--it's when you get into more complex stuff that there can sometimes be issues). But these quirks exist everywhere, and rarely are they so significant that the applications don't run straight off the top. Now, the problem with cross-platform capabilities with Mono (at least before the Foundation frameworks like WPF and WCF, which very few people actually use because they're overengineered crap) is native code libraries. People find something they want to snarf up into a managed code app, so they do it. But if you've got builds of that library on multiple platforms they can be ported and packed with the executable to intelligently pick the native code library based on which OS it's being run on (picking libfoo.dll on Windows, libfoo.so on Linux, libfoo.dylib on OS X).
Regarding "might work on Windows"--Mono has a build for Windows. It works fine. Some small theming issues, but it works. System.Windows.Forms is supported on Windows, OS X, and Linux, although I personally am looking into the Qyoto QT libraries for easier use (because WinForms, though easy, has problems).
Mono already works on "Mac's various phone platforms". (It runs very well on OS X; right now I'm testing an app for use on OS X 10.5.) It runs on the iPhone, too, thanks to their newish static compilation stuff.
So...sorry, but no. It works and it works fine. Nice work on the Insightful mods though. I suggest actually reading what you're talking about if you want to actually be insightful, though. :-)
Shut the hell up with your bad analogies and make with the car analogies!
I wasn't sure what OS X named its shared libraries, hence why I wasn't sure whether it'd work. As the other poster says, BSD/Solaris use the .so extension as well as Linux so I don't think it'd work right out of the box.
.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...
Excellent post. Drupal is the bee's knees, the ant's elbow, and the major arthroscopic joint of every other insect species in existence when it comes to open source content management systems.
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.)
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. (Bad example, though, because I personally use PHP and mod_mono isn't really good yet. ASP.NET MVC makes it a lot nicer to use though.)
Desktop apps on Windows/Linux? Bog-standard .NET/Mono. C#, most of what I'm familiar with, without having to worry about...you get the idea.
I used Java for much the same reasons when I used Java. Same language, same framework, different application for it.
(Plus, when it comes to Mono.CSharp and Mono.SIMD, I'm pretty sure you can package those specifically with your program to run them on the Windows .NET CLR. For Mono.SIMD in particular, it actually falls back to managed code on platforms without SIMD code support, which is a really nice feature.)
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.
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.
Well, sure, and it's something to keep in mind, but--
To be honest though - there's not much of a chance that either of those things are going to happen.
--exactly, we both know it's a bullshit worry (and unlikely that people will develop enough C# apps for that to matter). This is all just a bunch of hair-shirting over nothing at all, I feel.
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.
I agree. My compiler targets ISO-3 because extension methods have come in handy and I like lambdas, but I target the .NET/Mono 2.0 libraries.
But let Miguel rewrite GNOME as a Mono project
Miguel doesn't want to do this. Back under your bridge, sir. If you can't bother to keep your facts straight, why bother talking to you?
For your former point--what exactly does this do that Java doesn't? The Java runtimes update, too. Microsoft's update faster, but what of it? They're free to download and freely documented. You have to spend some time learning more, but only if you actually want to use it. LINQ (which I don't really use, I'm not a fan of it) is there, but it does nothing that cannot be done just as easily the "old way". The .NET guys don't deprecate stuff in favor of the new hotness in these sorts of cases; the old ways still stay fine. You can even use the .NET 1.0 non-generic types if you really want to. And unlike Java, you don't have ArrayList and ArrayList, with no under-the-hood difference (seriously, the type checking in Java is complete balls when it comes to generics).
As for mobile platforms--depends on the platform. The iPhone (and the XBox 360, which is obviously not a mobile platform but has similar rules) doesn't let software run other software, so Mono recently rolled out static compilation. The Mono static compilation system either currently does or is in the process of (I'm out of the loop, I worked for them for GSoC and haven't kept in touch much since) importing code from Linker to strip out the excess library cruft in those images.
On other mobile platforms such as WinMobile, Microsoft has the .NET Compact Framework. It's slimmed down mostly by removing Windows-specific libraries like WinForms, which takes up the largest amount of space. The "core" libraries like System.* (not the subtrees, but the language itself), System.Core (which includes LINQ), System.Web, System.Net, etc. are all really quite small. (You won't fit it on a 4MB Flash ROM, but if you're trying to do that you already screwed up when picking your tool set. Nobody's saying Mono's the solution for everything!) You're not going to have the upper-level libraries like WinForms on your toaster, but having them would be silly. Similarly, XNA (.NET on the 360) doesn't have WinForms, but does have libraries specific to the interfacing with the XBox 360 when running there and DirectX when running on Windows; you can use standard .NET libraries that are not included in the XNA redist when developing on Windows, but in years of working with the framework I've never found myself accidentially doing that or wishing I could get away with it. It just doesn't come up.
You make good points, but they're pretty much not problems, as far as I (and most other .NET/Mono devs, it seems) can see.
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. :(
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.
"Not being Windows" isn't enough to actually win, though. This is something that the Linux evangelists have never really understood, I don't think. The only way Linux is going to overtake Windows (and despite the fuckwits who call me a Microsoft troll or what-not, I'd love to see Linux do just that) is to be a better Windows than Windows. As easy or easier to use, as flexible or more flexible when it comes to applications. Thus, winning on merit.
Microsoft actually did something very cool with the Global Assembly Cache under .NET, but I have a feeling it would be damn near impossible to build something similar into Linux for native code libraries.
But packaging follows directly with the distro issue. It's a catch-22. :-P
I think the important question to ask is this: if everyone's using the same packaging system (which they fucking well should, it's a no-brainer), then why not take that next step to basing all relevant distros off the same core distro?
I haven't had crapware on my last two laptops--I buy from Dell's Vostro line, which is their small/medium business line, and they don't put crapware on there.
I also think you're full of shit about drivers. On Dell's site you just punch in your service tag and it'll present you with all the appropriate drivers for your machine.
Would you say Windows runs better than Linux,
Yes. My audio never cuts out at random on Windows and I never have to make sure I have the exact version of some library (because most apps pack mission-critical libraries with them, thank god).
supports more hardware,
Certainly supports my graphics card a lot better. Hint: supporting "more" hardware is meaningless when you don't support my hardware, as far as I am concerned.
is more versatile?
Linux will run in more places, that's for sure--but where it matters to me, personally, it doesn't run as well. (I'm hoping that Android takes off for phones, though. Anything's better than Windows Mobile, and I won't buy an iPhone.)
You do know that the same software will run on all of the Windows builds for the same arch (i.e., not the Itanic distros), right?
And that they all come on the same disc?
And that your false equivalency is fucking pathetic?
Can't win on merit?
Unless the "common system" is the kernel, this is a problem in design of either the package management system or the particular packages.
So? I personally don't care where the problem is. It's still an unresolved problem. And it's not going to get fixed anytime soon.
"Compile from source" is a shitty alternative and essentially blocks proprietary development. The freetards will say that that's not a bad thing, but the freetards also think Stallman is right for doing crap like adding forced nag screens to emacs and screaming that others are bullying him when they say it's not a good idea.
Proprietary software development is not going away. Linux is not going to change "the market and system." Adapting to the way things work gives you a chance to move forward--not doing so does not. That means building a halfway decent cross-distro framework that ensures that if it runs on Ubuntu, it runs on SuSE or RedHat or whatever else. Not having that is pigheadedness at best.
OO 3.0 actually can import PDFs. It's the only reason I have it installed on my machine.