mono: the runtime is based on a lot of libraries. It needs libc 2.x which itself needs other libraries.
pnet: need only a few external libraries
mono: runtime licensed under LGPL, Compiler under GPL, Libraries MIT/X11-license
pnet: all GPL/LGPL
mono: compiler are running on .net/mono/pnet platform and are written in C# itself
pnet compiler is written in C
mono: includes C# (mcs), Basic (mbas) and JavaScript-Compiler.
pnet: includes C# and C compiler (both cscc)
mono: primary GUI for Novell is Gtk#. But they also want to create WinForms based on Cairo.
pnet: primary GUI are WinForms. On Linux/Unix the widgets are create with X-Sharp, the .net-bindings to the XServer written by DotGnu.
I think, mono is more mature then pnet.
The only problem, what both have is the license.
I have heard, that in any article anybody have suggested, that Novell demands from Microsoft, that Microsoft sign a peper, where stand, that all parts which are ECMA and/or ISO Standard are without patents.
For stability. Generics required changes throughout the entire compiler, which could de-stabalize everything. Since mcs is needed to build the class library, introducing such instability would be a Bad Thing. Consequently, generics support was branched off.
When generics support is stable/complete, gmcs and mcs will probably be merged back into mcs, and gmcs will be removed.
Nothing, except that it didn’t work well before. For example see http://bugs.debian.org/257998. I experienced that too.
MonoDevelop FAQ claims that it should work with any EWMH-complaitn window managers. And XFCE is EWMH-compliant, so there certainly was a bug somewhere in the past.
If you’re not using SUSE/Fedora, Mono takes a good bit of work to install and stay current. Enough work, I think, to discourage adotion of the nice Mono applications that are starting to appear.
Anyone know if the Mono team is giving any thought to the creation of an installer? Something directly analagous to Sun’s Java installers — one for the runtime, one for the development tools — seems appropriate.
(Yes, packages are available for Debian, etc., but they aren’t official and you’re relying on the kindness of strangers for updates and fixes.)
“Fix it yourself” is the kind of attitude that keeps good software locked up in the geek ghetto. Why would anyone using a Mono application even consider “fixing” it? They’d just throw it away as broken, and they’d be right.
I like Mono, but if it is ever going to become something that real people use to do real work, it needs to transparently installable. Right now, it’s rather opaque.
I like Mono, but if it is ever going to become something that real people use to do real work, it needs to transparently installable. Right now, it’s rather opaque.
Then put pressure on your distribution to provide stable packages. They are, after all, providing the end user operating system. This is not the mono team’s responsibility.
Ultimately, you can easily ./configure, make, sudo make install it yourself.
I would, however, love to see mono delivered by autopackage. That would, in my eyes, be the crowning moment for linux software delivery.
1. How, exactly, am I supposed to “pressure” a distribution? Threaten not to use it? They’re not selling it, so what do they care?
2. Why isn’t it the responsibility of developers to make their code as easy to use as possible? Presumably, that’s why Novell is paying people to work on Mono. You might as well argue that the kernel ought only be available in source.
3. I’ve installed Mono from source. It’s a pain. No software that needs to be installed from source — regardless of how easy that might be for a developer — will ever be widely adopted by users. Mono applications — which is the point, after all — will be DOA unless Mono itself can be delivered in a point-and-click install.
Well the Windows and Mac OSX packages are one click installs, I don’t know about Linux but one thing that I do know is that there are several packaging systems for Linux / Unix / BSD / et al. To expect the developers to support all the various packaging systems is not realistic.
The solution is not to try to support the packaging systems. Build an installer and let the distributions worry about wrapping that up in their system du jour. The point remains that users will not use any application if it requires the manual installation of several other pieces of code. To the extent that that is due to Linux’s obsession with packaging schemes, then Linux has a problem.
If the point of Mono is porting .NET to Linux, the fact that it is not easy to install ought to be of concern to the Mono people. A working product is always preferable to a box of bits.
I think it is slightly ironic that Debian make it easy to use Mono (I had it up and running on Ubuntu quite easily) and hard to use Java, where with certain other major distributions it is just the opposite.
Whilst Linux users love choice, the plethora of approaches adopted by all these distributions must be a real pain to people like Mono. It might not be their responsibility to do so, but it is in their interest to ease the path of adopting their product.
The point is that if the kernel wasn’t made available in binary form by distributions, hardly anyone would be using Linux, either.
Exactly my point – the distributions provide the binary kernel. Hence it is the responsibility of the distribution to provide the mono binaries. Ultimately they only have to package what they are willing to support.
I take it, then, you believe developers have no responsiblity to users to make thier products easy to install and use. Perverse.
All I asked is whether or not Novell was considering bundling Mono in an installer. It seems obvious that, if they want Mono to be widely used, they’d make an effort to ease its installation. Assertions about who or what is “responsible” for anything are besides the point.
mono: the runtime is based on a lot of libraries. It needs libc 2.x which itself needs other libraries.
pnet: need only a few external libraries
Are these libraries included in the respective downloads or must they be downloaded? Or do you talk about system libraries that are available anyway? If so, why does it matter?
mono: runtime licensed under LGPL, Compiler under GPL, Libraries MIT/X11-license
pnet: all GPL/LGPL
I heard pnet has got a special exception note?!
mono: compiler are running on .net/mono/pnet platform and are written in C# itself
pnet compiler is written in C
Apart from the “trust problem” that they mention on pnet’s website regarding mono, does it make a difference, technically, perhaps in terms of performance?
mono: includes C# (mcs), Basic (mbas) and JavaScript-Compiler.
pnet: includes C# and C compiler (both cscc)
mono: primary GUI for Novell is Gtk#. But they also want to create WinForms based on Cairo.
pnet: primary GUI are WinForms. On Linux/Unix the widgets are create with X-Sharp, the .net-bindings to the XServer written by DotGnu.
It seems that none of the projects is completed. Do you know if there have been technical or (at least any) reasons why they don’t work as one team to make at least one fully working solution? I mean, if both eventually want to implement WinForms, it seems strange everyone reinvents the wheel, doesn’t it.
…the Red Carpet client appears to be available only for the Novell/SUSE and some Fedora releases. I’ve used it on SUSE. It’s a great piece of work, but if I’m using something else, I can’t use it.
Again, I’ve no interest in starting a pointless discussion about who is responsible for what. I’m just suggesting that Mono’s acceptance by users — which will be driven by appications that use it — would be significantly enhanced if it was easy to install on any distribution. The alternative is to wait until individual distributions decide to package it.
Feature lists for both releases are at:
http://www.go-mono.com/archive/1.0.4 (stable)
http://www.go-mono.com/archive/1.1.2 (development)
Of interest to folks might be the C# 2.0 features that
now are distributed.
mod_mono unloading apps now
MonoDevelop seems to be working correctly in XFCE now.
Why is there a separate compiler for generics?
what does MonoDevelop have to do with xfce?
mono works again on nptl!
so – everyone – get beagle, blam, and other 7 cool apps of mono
Is there any up-to-date site or page that explains and/or discusses the differences, advantages, drawbacks of Mono and Portable.Net in detail? Mathias
i tried ASP.NET pages on linux with mono,it’s amazing
i think that novell/ximian team have done a good work
and the next release will implement much more features.
mono: the runtime is based on a lot of libraries. It needs libc 2.x which itself needs other libraries.
pnet: need only a few external libraries
mono: runtime licensed under LGPL, Compiler under GPL, Libraries MIT/X11-license
pnet: all GPL/LGPL
mono: compiler are running on .net/mono/pnet platform and are written in C# itself
pnet compiler is written in C
mono: includes C# (mcs), Basic (mbas) and JavaScript-Compiler.
pnet: includes C# and C compiler (both cscc)
mono: primary GUI for Novell is Gtk#. But they also want to create WinForms based on Cairo.
pnet: primary GUI are WinForms. On Linux/Unix the widgets are create with X-Sharp, the .net-bindings to the XServer written by DotGnu.
I think, mono is more mature then pnet.
The only problem, what both have is the license.
I have heard, that in any article anybody have suggested, that Novell demands from Microsoft, that Microsoft sign a peper, where stand, that all parts which are ECMA and/or ISO Standard are without patents.
At the moment they only belive what Jim Miller at Microsoft have written in a mail ( http://www.mono-project.com/about/licensing.html#patents )
But Sun and Microsoft saying from time to time contradictorily statements.
So, a statement which was not signed on paper is wothless / valueless.
Why is there a separate compiler for generics?
For stability. Generics required changes throughout the entire compiler, which could de-stabalize everything. Since mcs is needed to build the class library, introducing such instability would be a Bad Thing. Consequently, generics support was branched off.
When generics support is stable/complete, gmcs and mcs will probably be merged back into mcs, and gmcs will be removed.
> It needs libc 2.x which itself needs other libraries.
Oh sorry. I mean glib 2.x
And sorry argan. 🙁
> The only problem, what both have is the license.
I mean “the patents” and not “license”.
Sorry again
foo: Nothing, but it didn’t work correctly before. (The application window was stuck over everything else, even it’s own child-windows)
Glad to see that it works now, even though xfrun4 can’t launch it..
> What does MonoDevelop have to do with XFCE?
Nothing, except that it didn’t work well before. For example see http://bugs.debian.org/257998. I experienced that too.
MonoDevelop FAQ claims that it should work with any EWMH-complaitn window managers. And XFCE is EWMH-compliant, so there certainly was a bug somewhere in the past.
If you’re not using SUSE/Fedora, Mono takes a good bit of work to install and stay current. Enough work, I think, to discourage adotion of the nice Mono applications that are starting to appear.
Anyone know if the Mono team is giving any thought to the creation of an installer? Something directly analagous to Sun’s Java installers — one for the runtime, one for the development tools — seems appropriate.
(Yes, packages are available for Debian, etc., but they aren’t official and you’re relying on the kindness of strangers for updates and fixes.)
(Yes, packages are available for Debian, etc., but they aren’t official and you’re relying on the kindness of strangers for updates and fixes.)
or fix it yourself
“Fix it yourself” is the kind of attitude that keeps good software locked up in the geek ghetto. Why would anyone using a Mono application even consider “fixing” it? They’d just throw it away as broken, and they’d be right.
I like Mono, but if it is ever going to become something that real people use to do real work, it needs to transparently installable. Right now, it’s rather opaque.
I like Mono, but if it is ever going to become something that real people use to do real work, it needs to transparently installable. Right now, it’s rather opaque.
Then put pressure on your distribution to provide stable packages. They are, after all, providing the end user operating system. This is not the mono team’s responsibility.
Ultimately, you can easily ./configure, make, sudo make install it yourself.
I would, however, love to see mono delivered by autopackage. That would, in my eyes, be the crowning moment for linux software delivery.
Check it out at http://www.autopackage.org if you haven’t already
Is Mono native on OSX or do you need the X11 libs as well?
I guess it needs both X11 and GTK libs to work (have GUI) on Mac OS X.
1. How, exactly, am I supposed to “pressure” a distribution? Threaten not to use it? They’re not selling it, so what do they care?
2. Why isn’t it the responsibility of developers to make their code as easy to use as possible? Presumably, that’s why Novell is paying people to work on Mono. You might as well argue that the kernel ought only be available in source.
3. I’ve installed Mono from source. It’s a pain. No software that needs to be installed from source — regardless of how easy that might be for a developer — will ever be widely adopted by users. Mono applications — which is the point, after all — will be DOA unless Mono itself can be delivered in a point-and-click install.
Well the Windows and Mac OSX packages are one click installs, I don’t know about Linux but one thing that I do know is that there are several packaging systems for Linux / Unix / BSD / et al. To expect the developers to support all the various packaging systems is not realistic.
The solution is not to try to support the packaging systems. Build an installer and let the distributions worry about wrapping that up in their system du jour. The point remains that users will not use any application if it requires the manual installation of several other pieces of code. To the extent that that is due to Linux’s obsession with packaging schemes, then Linux has a problem.
(Yes, packages are available for Debian, etc., but they aren’t official and you’re relying on the kindness of strangers for updates and fixes.)
Umm, right now version 1.0.2 of Mono is in the official Debian package repository. How official do you need to get?
> You might as well argue that the kernel ought only be available in source.
No arguing necessary. You’ll only get the source from kernel.org — just as with mono.
If the point of Mono is porting .NET to Linux, the fact that it is not easy to install ought to be of concern to the Mono people. A working product is always preferable to a box of bits.
I think it is slightly ironic that Debian make it easy to use Mono (I had it up and running on Ubuntu quite easily) and hard to use Java, where with certain other major distributions it is just the opposite.
Whilst Linux users love choice, the plethora of approaches adopted by all these distributions must be a real pain to people like Mono. It might not be their responsibility to do so, but it is in their interest to ease the path of adopting their product.
damm beagle it’s awesome,hey take a look at this
http://primates.ximian.com/~glesage/wiki/doku.php?id=beagle:spec-1….
there are some layout ideas.
The point is that if the kernel wasn’t made available in binary form by distributions, hardly anyone would be using Linux, either.
Here is an idea. Use gentoo, run “emerge mono” and you’re all set. How is that for simple.
The point is that if the kernel wasn’t made available in binary form by distributions, hardly anyone would be using Linux, either.
Exactly my point – the distributions provide the binary kernel. Hence it is the responsibility of the distribution to provide the mono binaries. Ultimately they only have to package what they are willing to support.
Hi, I’m just wondering how you know this, on the release notes it doesn’t say anything about nptl, but if thats true, it would be great.
Can anyone attest to the performance improvements?
Any benchmarks out there comparing earlier releases to 1.0.4?
I’ve seen the benchmarks comparing it to the .NET framework and Java…not very impressive…quite a bit slower.
I take it, then, you believe developers have no responsiblity to users to make thier products easy to install and use. Perverse.
All I asked is whether or not Novell was considering bundling Mono in an installer. It seems obvious that, if they want Mono to be widely used, they’d make an effort to ease its installation. Assertions about who or what is “responsible” for anything are besides the point.
hopefully it’s fixed the mod_mono and XSP memory leak in the previous versions
asp.net on unix is kewlness!
Novell already bundles Mono in an installer as part
of its SUSE Linux distribution.
In addition to that, we developed a general purpose
installer called `Red Carpet’ that will install not only
Mono but anything else, and allow individuals or groups
to publish software to be installed easily.
You must run this installer to use it.
Miguel.
mono: the runtime is based on a lot of libraries. It needs libc 2.x which itself needs other libraries.
pnet: need only a few external libraries
Are these libraries included in the respective downloads or must they be downloaded? Or do you talk about system libraries that are available anyway? If so, why does it matter?
mono: runtime licensed under LGPL, Compiler under GPL, Libraries MIT/X11-license
pnet: all GPL/LGPL
I heard pnet has got a special exception note?!
mono: compiler are running on .net/mono/pnet platform and are written in C# itself
pnet compiler is written in C
Apart from the “trust problem” that they mention on pnet’s website regarding mono, does it make a difference, technically, perhaps in terms of performance?
mono: includes C# (mcs), Basic (mbas) and JavaScript-Compiler.
pnet: includes C# and C compiler (both cscc)
mono: primary GUI for Novell is Gtk#. But they also want to create WinForms based on Cairo.
pnet: primary GUI are WinForms. On Linux/Unix the widgets are create with X-Sharp, the .net-bindings to the XServer written by DotGnu.
It seems that none of the projects is completed. Do you know if there have been technical or (at least any) reasons why they don’t work as one team to make at least one fully working solution? I mean, if both eventually want to implement WinForms, it seems strange everyone reinvents the wheel, doesn’t it.
Thanks, Mathias
…the Red Carpet client appears to be available only for the Novell/SUSE and some Fedora releases. I’ve used it on SUSE. It’s a great piece of work, but if I’m using something else, I can’t use it.
Again, I’ve no interest in starting a pointless discussion about who is responsible for what. I’m just suggesting that Mono’s acceptance by users — which will be driven by appications that use it — would be significantly enhanced if it was easy to install on any distribution. The alternative is to wait until individual distributions decide to package it.