Re: GNOME, .Net and Mono

On Sun, 2002-02-03 at 13:28, Sander Vesik wrote:
> On 1 Feb 2002, Sean Middleditch wrote:
> > 
> > On Fri, 2002-02-01 at 19:03, Gérard Milmeister wrote:
> > > 
> [snip]
> > 
> > Why then would being based on Mono, a fully Open Source codebase, be
> > something to be worried about, any more than basing it on an "arcane"
> > language like C (GNOME now) or a "bloated" language like C++ (KDE).  
> > (And just for the record, my favorite languages are C and C++ - I just
> > used the stereotypes for those languages).
> > 
> A very legitimate reason not to want to use .NET is it being based on a
> new, largely untried VM - if the goal really was to go with a VM, then
> there are much older, tried and quite probbaly in the mid-term, better VMs
> around than Mono. And this isn't a plug for java - its use of a VM is
> nothing new.

That is a good point.  But, do any of these VM's do what Mono does?  Can
language like Perl, Python, Ruby, and so on all run on top of these

Also, would the plan for this Mono migration be to make all of GTk and
GNOME run inside of this VM, or would it simply be that the VM would
have access to the underlying C libraries, along with the C/C++
applications currently available?

> > THe way I'm imagining being based on Mono would work is similar to how
> > things are based on CORBA now, although perhaps better integrated,
> > easier to work with, and in many cases faster.  Instead of making a
> > CORBA call, you'd make a Mono call.
> > 
> > Just because it's Mono, I don't think that means we'll be forced to use
> > any of the (likely) security/stability problems with MS's
> > implementation, or be forced to run closed code, or have to program in
> > C#.  As I understand it, it'll be more like the ultimate wrapper, the
> > ultime plugin architecture, the ultime scripting interface, etc. (or, at
> > least, until someone invents something better.  ^,^)
> > 
> > Or is there some deeper point I'm missing that would make it very bad
> > for GNOME to go this way?  Would mono slow things down a lot, being
> > interpreted bytecode in many cases?  Would mono possibly have
> > unavoidable security concerns wrt untrusted code?  Would mono lock out
> > certain languages?  Would mono force developers to use a restrictive
> > license? (not in the GPL-type restrictive, either)
> Mono uses developers to change how they work and use new (untried,
> containing bugs, not optimising as well as they could/should) compilers. 

Well, now, ya.  I suppose the current GTK/GNOME libraries were 100%
perfect when they were first released, yes?  ~,^

I can understand there being a problem if all of GNOME just up and
jumped onto Mono.  That would likely cause some serious problems.  I
really hope that wasn't the plan MIguel and others had.

> > 
> > I'm curious as to exactly *how* integrating GNOME with Mono makes things
> > better, and what reaons there would be *not* to do this (other than that
> > it would take a lot of work).
> > 
> Maybe you should have figured these couple of things out to some extent
> before writing that 'as I understand it it'll be more like the ultimate
> wrapper, the ultime plugin architecture, the ultime scripting interface,
> etc.' paragraph up there, or at least give some reasons...

I think I could've left that last bit out.  I think I've already got
that figured out.  Shows what happens when you don't have enough
caffeine in your system.

> yes, mono is a new, interesting and in many ways excting architecture -
> whetever I want it to run significant parts of my desktop withinthe next 5
> years, is another matter entirely.

Aye.  I suppose it all comes down to what the final released Mono can
do, how fast/securely it can do it, and so on.  What looks good on paper
has a habit of not working out the best in the end.

> As usual, all opinions are my own.
> 	Sander
> 	I see a dark sail on the horizon
> 	Set under a dark cloud that hides the sun
> 	Bring me my Broadsword and clear understanding
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]