Hehe, nice to know the ammount of comments/reads that my two previous posts had. Got people from OpenSource movements to Microsoft coders! The sad thing, and yes I think this is related, is that someone was trying to hack my server and I had to shut it down for a while… can’t people read an opinion and go easy?
So, in the last two posts I expressed my opinion about two specific problems that we have in Linux, compared to Windows (I never used a Mac, but from what I’ve read OSX is way faster than Linux too), and I’ve made a sort of closed-open source comparition.
The fact is that you can easly find some open source applications that are both successful and fast and in the majority of the cases you’ll find that they do reduce the ammount of redundant libraries and dependencies. Successful projects usually use the minimum ammount of programming languages (because that increses the number of deps and redudant libraries) and they surely have a good leadership and policies that imposes those at all costs.
Whats the connection between all this and Mono? Well, Mono and Java solve most of this problems, they provide you with a common set of libraries that in most cases are used by the applications so there’s no need to redundant libraries to be loaded. But, theres something that Java doesn’t solve; Mono (.Net) is designed to support multiple languages and to make bindings to unmanaged code easy so, integrating well with our current state of art.
At the present moment we have Mono compilers for many languages, PHP comes to mind, and that means you can use your PHP skills but use the XML library the system already has loaded, in fact, the same that Evolution could be using, and so on. The overrall result would be the reduction of memory usage and startup times.
This is what open source needs!
One drawback… Mono is an implementation of Microsoft .Net and has compability in mind, if .Net has a bug, Mono has a bug (but you can call it feature :P), if Microsoft designs something in a way, Mono does it that way, there’s no space for changes. This is exactly the kind of drawbacks that make people clone, fork and remake software creating more mess in Linux world.
I’ve told this before but I’ll re-tell it. If Mono wishes to be widely adopted by Linux it has to open its policies to changes. There should be a compatible implementation and an “Mono for real” where Microsoft bugs could be fixed and where we could change/implement new features. This way we could attract the attention of other Linux projects, because of our flexibility, and if they told us: hey I like you XML parser but I need a new Property in there (or some other thing), else I need to implement a new library for it…. That is the begin of the mess.
Conclusion
The way I see things, Linux has much to learn and improve. It can be secure and fast, it is and and I never told you it weren’t in this whole article! The problem is that people mix the words and concepts, Linux=The Kernel and that is fast and secure, Linux Software=THE PROBLEM. Yet, my opinion (shared with some friends) is that even the kernel is becoming obsolete and its not envolving to the Desktop as Linus promissed for 2.7. And without proper software and standarts that could kill and fire a lot of people…
I see Mono as a performance boost, security boost and standartization boost in Linux world. We only need to learn by the past mistaques and try to fix them, then more and more people will help and use.
Mono, like .Net is a pile of crap. It’s trying what Java tried to do,
which is maybe be feature full, but also be slow and a memory hog.
What’s really wrong with software under linux is that noone wants to play with a nother.
You are right that a lot of
apps use way to many (may be unessacery libs). Things that come to mind is the whole Gnome vs. KDE thing. Example.
Say I want a alsa mixer. I don’t run gnome, nor KDE. I run XFCE and
sometimes E17. So i’m looking at the choices of alsa mixers. alsamixer itself is very descent, lacks some configurability, but worst, it’s console. Sometimes you want a neat little GUI
app.
So there comes gnome-alsamixer, but to install that, I need a whole bunch of gnome libs, some 20+ megs worth (compressed!). Now what is up with that. It’s a friggin’ mixer, I couldn’t
see anything that would be a gnome only thing. I’m sure there could be some compile time excludes to put something like that to a minimum, but no.
And this is what’s happening with a lot of
software. KDE boys stay with QT and KDE integration, Gnome boys stay with GTK and Gnome integration, and everybody inbetween looses.
(I personally prefer gtk over qt as gtk just seems faster
and less memory intense. Also the compile time of gtk is 20minutes lower making QT just seem an even bigger hog to me. Oh and it beeing C vs C++ also helps :p)
A second thing what’s starting
to bother me is that with all these every growing list of dependancies, you need an ever more abunded supply of diskspace.
I used to think linux was ‘nice’ to my diskspace. Turns out, not so
much anymore. Now I don’t have a massive amount of applications installed, but my /usr/lib is 1.2GB. Excuse me? But that’s probably cause everybody wants to write their own library I suppose
….
Anyway, these are the real problems I think we have. Unison between enviroments should be based on GUI Design Documents, and not by forcal of integration libraries. Allthough there are
sittuations where you need _optional_ integration.
Developers should look at their library requirements more closley.
And less scripting! IIt’s cute that we can build apps in python, perl or
even bash, but use the tools intended for the task. You wouldn’t want to use a webbrowser written in Perl? Unless of course you have a 8-way opteron with 16gb of memory, I’m sure then, I wouldn’t
care either (I would, really : )
Are you sure Mono and .Net are a
piece of crap, slow and a memory hog? I don’t think so, specially taking into account what the framework gives you in terms of production and security. You need much less time and you focus on what
matters (compared to the intense debugging/knowledge/time you need with other languages to make your code secure and avoid memory leaks and stuff like that).
Thats an anoying thing when you
need a simple application that depends on a 20MB framework or something like that, the fact is that sometimes you can avoid that. For Mono you can use mkbundle that will create a native binary from
the .Net application including only the needed .Net libraries. For Linux in general you can build a static version of the application, in your case you could grab the source and build a static
version of gnome-alsamixer from it, so you won’t need to install GNOME.
Why don’t you do that? It takes time and it sucks. Why downloading 20MB its your only option? Because your
distribution doesn’t provide you a static version of gnome-alsamixer. Why? Because thats the concept of libraries, you install once and then you’re saving space because all the next applications
that need it don’t need to install their own version. If you used Gentoo or something like it you probably could avoid that.
I don’t agree with your opinion about QT vs Gtk+. I do use and
love Gtk+ but I still think that Qt is way faster and in fact I think thats the reason for the success of KDE. If it weren’t for Qt I bet KDE would be death by now. MHO.
Each language has its
purposes and fit better or worst in another. You pick your language of choise for a task but sometimes you have to use something like C/C++ just because you need performance or because of the
avaibility of libraries. Mono solves this for you. You can use the language of choise, performance would be nearly equal, lets say, for a Perl.Net and C# compiled assemblies, and the best part is
that whats done in C# is avaible to every other .Net language and vice-versa – no pain, no bindings, no hacks.
Hi Alexandre,
I’ve read all your
articles and agree with you in most cases.
Personally I am a big fan of managed programming languages, because of the development speed and comfort.
About Mono and Java:
I
guess, that a unique programming interface and platform is very important. We will see, that the .NET platform is a very big improvement for the windows world.
It’s sad, that the open
implementation of java has not been finished a few years ago. Then Linux already had such a platform for years.
The java platform isn’t only for one language too. There are also other
languages, e.g. python (jython). So there aren’t many differences between Java and Mono in that case.
But now, we have Mono as an open source implementation of .NET, ok. I really like to use
it, but sometimes it’s a pain in my head, that I am helping to make this microsoft technology more public
You said, that Mono should have enough space for own implementations and
libraries. Mono already implements some Posix-specific functions, or e.g. gtk#, gnome#, dbus# and so on.
So we already have the core .NET implementation, but additional functionality
especially for the *nix platform.
In another view Mono is very important for the linux platform. In the next years Microsoft will only provide the .NET platform for windows. The old Win32 is
obsolete. So a lot of people will start with learning C#. With Mono it is possible for those people to develop for *nix. And it is the same the other way around:
With my current C# knowledge
But I guess, that this is a very important fact for some developers.
it is possible for me to develop for windows. Maybe a lot of people don’t wanna do this
With Java of course you can
have the same. You can write it on linux or on windows. But .NET will be the more important platform for windows desktop. For serverside programming this is another topic.
So I am curious
about the next years, especially how the Mono project will handle windows applications based on avalon and indigo. IMHO these are technologies, where both projects will go different ways. Microsoft
windows will build their application on avalon/indigo, and linux guys will use gtk#.
So, if you only wanna write your application once, but use it on both platforms you should either use gtk#
(it is working on windows too), or use Java (SWT or Swing). Maybe this fact is a reason for some developers to use gtk# on windows too.
Greetings
Mike
Re Java: As I recall, Java platform was designed *specifically* for Java, not for Java + other languages. On the other hand, CLR was designed *specifically* for an ecosystem of languages
targetting it. Hence the existance of the CLS. If you talk to the CLR folks and the C# Compiler folks, I’m sure they’ll be happy to inform you of things C# has no clue about, which the CLR
supports.
Also, note Hugunin’s hiring at Microsoft — that was specifically to make the CLR friendlier to dynamic languages, and IronPython is the flagship for that mission. You don’t see
this effort from Sun.
Re diskspace: There are versions of the runtime that run on wristwatches. If diskspace is such a bother to you, might I suggest programming directly in assembly
language? Truly, diskspace is cheap nowadays.
Re memory: Memory is also cheap, but the fact that it isn’t as cheap as diskspace is valid.
Loading time: As I recall, you can mitigate
some of this by splitting your base framework assemblies across multiple files. Is mscorlib too big a chunk? Possibly… You can also ngen files once they are on the destination, and that can
trade off loading time at the expense of any future JITting opportunities.
I suppose you could potentially arrange to have the runtime always loaded, with all managed programs everywhere run
by spinning off new AppDomains and threads. This could allow for greater sharing of libraries between running applications, with the decrease in loading and JITting hits. I’m not sure what the
stability implications for this would be (that is, I don’t recall if programs can crash beyond the AppDomain level — it’s not been a problem). I suspect you’d want to set up some additional
inter-domain security, in any event. But this is all stuff that I’m sure will be addressed by the time .NET has a successor.
There have already been serious studies of relative performance
between managed and native apps, and the results are that 1) you get to high performance faster and easier with managed versus C++; 2) while you can squeeze out more speed with C++ eventually, the
code looks horrific by the time you’re done; 3) a good JITter knows more tricks than you do about doing this safely, and trying to be fancy may prevent such a trick from being used. See the
differences between CPython (a runtime specific to the needs of the Python language) and IronPython (a compiler/interpreter producing code for the CLR, and able to take advantage of having the JITter
as well as the BCL). See also Singularity at MSR: it runs not too far behind native OS speeds.
If you really want to, in C#, you can resort to pointers and other unsafe bits like that. Of
course, you’d only do so after profiling the code to discover that you actually had a need to do so (most code doesn’t, and why people obsess over insignificant efficiencies is beyond me). I
learned C# by analyzing terabytes of genome data, and never needed to touch unsafe code. In fact, we ported code from native to C# — developer performance was worth more than any potential drop in
computation performance.
miketech: Why should .NET and Mono diverge at Avalon and Indigo? I think they should converge. In fact,
I think at those points, Qt, GTK#, and the rest can also converge as a point where you’ve now described the end result, to be interpreted by Your Library Of Choice. That’s a way to hide
incompatibilities between the different systems and increase portability (sorry, but I more or less refuse to load Qt and GTK# when I already have the native Windows libraries on my
system).
Hi Keith,
I simply think, that Avalon and Indigo are two technologies,
which are very strong integrated in the underlaying OS and not so easy to port to another system.
Do you mean, that if I write my application in Gtk# it should use the native windows libs on
windows and if I write winforms, it should use Gtk on Linux? This way is already done, isn’t it? On windows Gtk is painted manually. I guess, that it is not easy to simply use the other library. In
the future we will have more and more different widgets. Microsofts Avalon makes it possible for developers to write GUIs similar to flash. How should this be displayed with Gtk? For this, we need a
library, that is able to display Microsoft Avalon GUI. So we have a new additional library. And maybe in the future we will have widgets in Gtk# that can not be displayed with the standard Microsoft
winforms API. So Gtk# needs to be rendered manually on Windows. The solution is, that Microsoft Windows and Linux in particular Gtk have the same widgets on their system, to display the same GUI. Or
do you have any other ideas? Maybe I misunderstood your posting.
You say, that Sun has never done any effort in bringing other languages than Java to the Java VM. But what about AspectJ, or
Groovy?
And Microsoft isn’t better. Microsoft proudly tells, that .NET is a platform independant technology. Well, but they don’t work on Mono afaik!? They are not working on a port of
IronPython for Mono, only for their .NET environment. So this is similar to Sun. Sun is primarily pushing their technology Java, with the language Java. Microsoft is doing the same with the .NET
technology. And to get .NET becoming more and more public they are trying to port a lot of languages to .NET. Mono doesn’t help that.
I only wanna say, that it wasn’t in the interest of Sun
to port other languages, because they wanted to spread java. And this can be similar to Microsoft in the future. Now, they are interested in spreading .NET, so they like the development of Mono. But
as soon as Mono plays an important role on the *nix desktop and .NET is spread on Linux servers this could change. And this is one big reason, why many developers still avoid using Mono imho. The
technology is great, but till now there is no official announcement, that there is no danger for Mono developers and their project. If Novell had any agreements with Microsoft they should tell it to
the public, because Mono and .NET is really nice and shouldn’t be obscured by any legal issues.
Greetings
Mike
About idingo and avalon, those are
things that are possible to port and at least XAML is beeing ported atm by some Mono folks. I do not know how much more than XAML Avalon is. But provided that Mono is able to port Windows, it should
work the same way with Avalon. The only problem I see is Avalon and Indigo beeing proprietary tecnologies and not a standart, so they can take your legs if you implement it. Same problem with
ASP.Net.
Java wasn’t developed thinking about another languages, their VM and the Java language are tied. C#, as told in this discussion before, doesn’t implement each piece of the CIL.
There are an extreme effort to make it language idependent and to access external libraries. You didn’t see a boom of languages targetting JVM did you?
When Microsoft released .Net they told
(and I was there): “It is cross-platformable but we won’t implement it but for Windows. In fact, one could even do a processor (as in CPU/Hardware) to process the CIL.”. .Net is at least as cross
platformable as Java, if not more.
Hi,
oh I didn’t know, that there are
already people porting XAML to Mono. But why not using XUL in Mono too?
And maybe Microsoft told, that it is cross-platformable. They had to do this, because it should be a competitor to
Java. And they don’t say, that .NET will be standardized in the future, or that they allow people to implement everything around (ASP.NET and Winforms and so on). I mean: They proudly tell, how
platform indepedant it is, but they give no guarantee, that you don’t have any legal issues when implementing it and the corresponding technologies asp.net and winforms (I know, that this part is
not standardized, but we also don’t know, if the core .NET libs will be standardized in the future).
But of course: Also if they don’t allow using asp.net or winforms we have a nice
development platform for the *nix desktop.
Greetings
Mike
Just an addendum:
My fear simply is, that people start learning
.NET and C# in order to write applications for the linux desktop. And they do ASP.NET programming for their websites and maybe later like avalon development on linux too.
And then, later,
Microsoft will tell you: No… no asp.net, not avalon. And no .NET 4.0, it is not standardized any longer. So: If I were a .NET developer I personally wouldn’t migrate to C, or C++. I had to install
a windows server for my asp.net applications. And personally I would change to windows, because there I can continue my work. So maybe a lot of professionals could have exactly those problems. So
this is the reason for a lot of developers to look carefully at Mono. Yes, I will use it and yes I will work with ASP.NET. And yes I will use it for Linux development, because I like it. But will
Microsoft ever tell me, that I am not allowed to use my asp.net applications and Mono apps I will have to totally migrate to Windows. And maybe I will do it, because changing the OS costs less, than
rewriting the whole stuff I am programming.
Greetings
Mike
The point is that CIL and C# are
standarts. Both for C# and CIL to work you need an implementation of the Corlib and something more – those are parts that I believe they will keep standarts. Specific APIs like ASP.Net and Windows
Forms are the only things they can create trouble from in next releases.
Even if they didn’t standartize the next C#/CIL versions, or even if they don’t allow you to implement ASP.Net thats
a question of sticking with the last standart Mono version and fork from there. ASP.Net isn’t *that* great deal. One could implement a MSP.Net quickly, just like we did with GTK# that would be the
logical MWF alternative.
I don’t think they will ever do that, they would lose and create more options to their own libraries, starting to lose the focus they wanted in the
begin.
Before you go off and implement MSP.Net,
I’d prefer y’all just do the right thing in making Avalon talk web. ASP.NET is very good at what it does, but as I’ve mentioned to my manager, there are still a lot of artificial dichotomies
(seperate controls for local versus remote UI, completely different databinding stories, etc).
Re IronPython: Isn’t it odd that Mono’s support of IronPython lags only by a version or so?
MS *hired* Hugunin, who had already by that point announced IP. It makes sense to develop IP using Microsoft’s implementation for two reasons: Hugunin’s charter is/was to make the CLR more
amenable to these sorts of languages, and without any intellectual property arrangement that passes Legal’s scrutiny, working too closely with Mono constitutes a intellectual property taint. I
don’t know if you’ve been lurking on ironpython-users, but there is quite a bit of cross-platform testing that occurs every time they make a release. I should know — I was the source of some of
it earlier on.
Re Avalon/Indigo/WWF/etc: My point with those is that they represent focus points where different frameworks can unify around. Rather than force the developer to learn
Framework-X customized insanities, just use the common declarative form. My hold out is for ASP.NET to be migrated into Avalon, but I suspect it’s too deeply engrained to manifest any time in the
next 5 years.
Re standardization: While it would be completely within their rights to do so, I don’t think MS will not standardize C#3 or 4. The draft spec for 3’s already been published
(covering the query syntax, etc), and while I don’t know what if any plans are currently floated for 4, I suspect that major shifts are very unlikely: the language is getting pushback as it is from
different fronts for being too complex (I don’t share that opinion — I see the actual use as getting simplified by pushing work to the compiler). Everything that happened in C#2 has, in my
opinion, been aimed specifically at C#3’s query support.
The alleged stranglehold over the ECMA specs has been the anti-MS FUD since .NET was announced. Microsoft has had years of
opportunity to squash any third party implementations, and yet my read of Mono’s own website is that MS has been, at least in some part, of assistance. That is inconsistent with the theory that
they’ll suddenly decide to pack up their framework and not play any more. A finite possibility exists, but I’ll drink a beer for you if I’m proven wrong (hint: I hate beer — I’m a Bailey’s
drinker, myself).
Incidentally, regarding Avalon and non-Windows systems, support was stated at the PDC:
http://uk.builder.com/programming/unix/0,39026612,39265897,00.htm