Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mono & SourceGear Move Forward

Hemos posted more than 11 years ago | from the partnering-together dept.

Programming 56

miguel writes "The Mono project keeps evolving and is quickly becoming a mature platform for running .NET applications on Linux. SourceGear and Ximian have entered into a partnership to make their .NET-based Vault client software available to Linux and Unix users by implementing the missing web services support in Mono. The formal announcement is here and a developer overview is here. OpenLink has also contributed the functionality to turn Wine into a library that Mono is using to implement the System.Windows.Forms namespace. Another recent progress bit is the fact that Mono can run Eclipse with the IKVM Java VM for .NET"

cancel ×

56 comments

Sorry! There are no comments related to the filter you selected.

!fefwefwefwfwefw (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6181260)

fp but who cares

What do you think they will do? (3, Funny)

shibbydude (622591) | more than 11 years ago | (#6181289)

Popular business plan: Step 1: Design product that runs a proprietary Microsoft system. Step 2: Make it run on Linux, Windows' leading business threat. Step 3: ??? Step 4: Profit!!! If no one could figure it out, step 3 might be sell the code to (or settle with) Microsoft so that .NET is once again a Windows-only system. At least this would be my business plan.

Re:What do you think they will do? (1)

Burb (620144) | more than 11 years ago | (#6181536)

Was this a troll? OK, I'll bite. If it's been released as part of the GPL, what's to sell back to Microsoft?

Re:What do you think they will do? (1)

shibbydude (622591) | more than 11 years ago | (#6181715)

Actually, I didn't RTFA, so it was just speculation on what could happen if the developers were corrupt, but under the GPL that would not happen.

ooops... (2, Insightful)

hummassa (157160) | more than 11 years ago | (#6181922)

Not "as part of the GPL", but GPL-licensed. Microsoft can buy it (the copyright from every Mono copyright owner), pull it from public view, and you and I -- well, we can still fork it! From the source that I checked out from cvs just few seconds before the transaction. He.

Re:ooops... (0, Troll)

Miguel de Icaza (660439) | more than 11 years ago | (#6183017)

actually Microsoft can buy mono copyright becuase all the developers have signed over their copyrights to Ximian. sneeky huh :^)

from the faq [go-mono.com] :

"The Mono runtime and the Mono C# Compiler are also available under a proprietary license for those who can not use the LGPL and the GPL in their code."

For licensing details, contact mono-licensing@ximian.com

Re:What do you think they will do? (3, Informative)

Miguel de Icaza (660439) | more than 11 years ago | (#6182477)

"If it's been released as part of the GPL"

Ximian has changed the license for a key part of Mono from the GPL to a license that permits the software to be used in closed-source projects.

The change was made to accommodate Intel, which wanted to contribute to class library work but chafed at the GPL's requirement that software remain open-source only. That provision of the GPL helps ensure that the work of open-source programmers--often volunteers--isn't appropriated for others' gain. Companies that want to adopt the software don't always want to reveal all their software secrets.

We're partnering with Intel and Hewlett-Packard to develop those pieces. One of the concessions we had to make was to switch from one open-source license to another

Intel has a .Net research lab, but part of its requirement is that software produced may be used in proprietary projects as well as open-source projects

Open-source software has been a rallying cry for programmers who wished to undermine Microsoft's power, but with the tightened economy the near-religious fervor for the open-source movement has given way to a more pragmatic view among businesses.

Microsoft has issued legal warnings about the GPL but is more favorably disposed toward this license.

Among programmers writing the class library, about 80 percent said they liked the new license better. However, this opinion wasn't shared by Richard Stallman, a founding father of what has become the open-source movement and the creator and tireless advocate of the GPL.

RMS doesn't like the license switch. It allows proprietary companies to benefit from the software

more here:
http://news.com.com/2100-1001-823734.html

80% of what programmers? (2, Interesting)

phr1 (211689) | more than 11 years ago | (#6209539)

What programmers writing the class library liked the new license? In particular, were they volunteers, or getting paid to write it?

My own attitude towards these questions is I'm a relative GPL zealot when it comes to code that I write for free on my own time. I don't see why I should develop products for proprietary software companies without getting paid. However, if I am getting paid, then I'm not so fussy about the license. I suspect a lot of other programmers feel the same way at some level, though they may not be explicit about it.

So if it was paid programmers who liked the license switch, it's easier to understand, even if it means the project will attract fewer volunteers. If it was volunteers who wanted to switch, that just seems kind of self-defeating.

I hope project leaders thinking of choosing non-GPL licenses consider these issues. Some projects of course need volunteers more than others do.

Re:What do you think they will do? (1, Interesting)

Miguel de Icaza (660439) | more than 11 years ago | (#6182637)

the entry level mono stuff is free but you will have to pay ximian & VC partners to get the connector stuff that actually makes it work.

theres your step 3.

the WINE projects been doing this for ages, WINE is free but if you want to run something like office xp you need a commercial versian/fork of WINE.

the differnce with mono is the core software is not actually GPL - it is more like a BSD license - so the commercial improvements don't have to be rolled back into core mono.

$$$ PROFIT! $$$

How mature is it? (3, Interesting)

Burb (620144) | more than 11 years ago | (#6181480)

Let me say first off that I love the idea of Mono and wish it every success. Although it will one day (hopefully) have pretty comprehensive coverage of .NET features, right now it doesn't.

I've just downloaded the port for FreeBsd of mono 0.24 and was delighted to find that hello world works. True, not an exhaustive test but nice to see. Then, I thought, how about seeing if my current applications would be ported. So I looked for the System.DirectoryServices library only to find it wasn't there. OK, not a big deal for some but I need LDAP access. The JIT stuff seems pretty good, but the libs are incomplete.

So a qualified hurrah to all this. I'm delighed so far, but it won't run all .NET code today.

Re:How mature is it? (0, Troll)

Miguel de Icaza (660439) | more than 11 years ago | (#6183094)

interestingly enough the System.DirectoryServices library is available under a closed source license.

Its only recently been completed and is still fairly 'betaish'.

for further information please contact: mono-licensing@ximian.com

Re:How mature is it? (2, Interesting)

sab39 (10510) | more than 11 years ago | (#6183376)

Interesting - are there any plans to open this up eventually?

Are there any other assemblies that are planned to be released in this way?

If someone in the community contributed an alternative implementation of DirectoryServices under the standard Mono license, would it be accepted?

Thanks,
Stuart (occasional mono user who had to #if out references to this namespace in some code to make it compile under Mono)

MODERATORS BEWARE (2, Informative)

The Bungi (221687) | more than 11 years ago | (#6184251)

This guy is a troll. This [slashdot.org] is the real Miguel de Icaza. Simply look at the troll's posting history [slashdot.org] as well as his journal entries and make up your mind.

Re:MODERATORS BEWARE (0, Troll)

Miguel de Icaza (660439) | more than 11 years ago | (#6184754)

CURSES!
i'll get you next time The Bungi

Re:MODERATORS BEWARE (1)

Skeezix (14602) | more than 11 years ago | (#6235541)

This guy is not the real miguel, just an imposter. this [slashdot.org] is the real miguel. Notice the uid.

This Mono thing is for clever people... (2, Funny)

d-Orb (551682) | more than 11 years ago | (#6181780)

Mono can run Eclipse with the IKVM Java VM for .NET"

Well, I am pretty sure that that is a fine achievement, but it looks like one of those scary organical molecules to me :-)

Re:This Mono thing is for clever people... (2, Informative)

Miguel de Icaza (660439) | more than 11 years ago | (#6183184)

What this shows is two things: the maturity of the IKVM JITer and the maturity of the Mono runtime as it is able to host this technologically advanced VM to run a large and complex application.

IKVM also helps bridge the two worlds: Java and CIL. Your Java code can then be loaded and used by CIL applications (C#, VB, etc) all running together.

personally i don't rate Eclipse much as a development environment compared to Visual Studio.NET. But i am a big fan of the Standard Widget Toolkit (SWT)

Re:This Mono thing is for clever people... (1)

Pengo (28814) | more than 11 years ago | (#6183578)


Sorry if this has been answered somewhere else, but wouldn't something like Eclipse be a perfect foundation for development of C# on Linux? I haven't seen another development tool that has the extensive cross-platform and cross-language support and seem to be outside the scope of a religion.

I am currently doing a lot of C# development, using visual studio .Net naturally, but being a native Java developer and a fan of Eclipse, it wouldn't be a monumental task to turn Eclipse via plugins into a decent C# development environment. For console type applications.

Of course this is just about writing C# console and server side type apps, not about the features of things like code generation of Windows Form code is what makes Visual Studio .NET such an interesting solution. I can't imagine that until Mono has solid WindowsForm compatibility , it's not going to be a compeling option over Java or microsofts own solutions. I personally would jump up and down to be able to run my windows-form code in mono on linux, and even more so do my development in linux.

I guess this rant is leading to the point of, better to build on something than build it yourself. Maybe with a widely adapted editor such as Ecplipse, and a solid plugin and CIL support, you will get wider adaption of C# on linux for console and server tasks. Wider adoption will bring a stronger userbase and hopefully accelarated development (which is what we are all praying for).

Thanks Miguel

Re:This Mono thing is for clever people... (0)

Anonymous Coward | more than 11 years ago | (#6187737)

Um, that guy's a troll. The real Miguel is here [slashdot.org] .

Re:This Mono thing is for clever people... (0)

Anonymous Coward | more than 11 years ago | (#6188286)

there is a plugin for C# for eclipse. It's pretty basic, but google for it or look at one of the many eclipse plugin sites. I've tried it and it is a decent start.

Mature? (4, Insightful)

truthsearch (249536) | more than 11 years ago | (#6182569)

A mature platform? It's in version 0.24. As of today they state 77% of just the core library is implemented. Teamwork and recognition does not imply maturity. The term needs to be used correctly and more sparingly or it'll lose all meaning.

Re:Mature? (4, Insightful)

pmz (462998) | more than 11 years ago | (#6182982)

The term needs to be used correctly and more sparingly or it'll lose all meaning.

I think much of the meaning is already gone. People will jump on whatever techology looks well presented enough. They get burned, eventually, but, for some reason, these setbacks are quickly forgotten. This process has been repeating for decades and is probably due to the constant influx of unqualified people into the software and IT industries.

Re:Mature? (5, Funny)

Miguel de Icaza (660439) | more than 11 years ago | (#6183263)

"Teamwork and recognition does not imply maturity"
actually mono was mature, stable, 100% compatible and bug-free as soon as the Ximian marketing department said so
something else the mono team has copied from Microsoft :^)

MODERATORS (0)

Anonymous Coward | more than 11 years ago | (#6184280)

This guy is a troll. This [slashdot.org] is the real Miguel de Icaza. Read the troll's posting history [slashdot.org] and rent a clue.

Re:MODERATORS (1)

The Bungi (221687) | more than 11 years ago | (#6184767)

I didn't post this - I'd rather not go around replying to this guy's posts all over the place and crying foul, and I certainly wouldn't do it as an AC. But moderators that are rewarding this asshole should be aware of what is happening.

MODERATORS BUNGI IS OFFTOPIC AGAIN! (0)

Anonymous Coward | more than 11 years ago | (#6184810)

Actually, looks like a joke to me. Pretty funny one at that. Rent a goddarn humor to suit your name.

hmmm *remembers reading somewhere that the bungi is a notorious troll*

dique :)

Re:MODERATORS (0)

Anonymous Coward | more than 11 years ago | (#6184792)

Actually, looks like a joke to me. Pretty funny one too. Did you only rent 'A Clue' personally I thought it was a keeper.

Re:Mature? (1)

Skeezix (14602) | more than 11 years ago | (#6235576)

This guy is not the real miguel, just an imposter. this [slashdot.org] is the real miguel. Notice the uid.

Once "The Vault" works... (1)

Aardvark99 (261926) | more than 11 years ago | (#6183120)

Will Mono development switch from CVS?

Re:Once "The Vault" works... (1)

benwb (96829) | more than 11 years ago | (#6183262)

Since the vault runs about $400 a client license, I don't think so.

I knew it! (5, Insightful)

Arandir (19206) | more than 11 years ago | (#6184079)

For almost two years now I have been subjected to the religious proselityzing of the .NET cult. "It's platform neutral," they said. "It will run on Linux," they said. "Just trust Miguel and you will be saved," they said. But now they say they will use Wine. What a crock of shit! If .NET is crossplatform then so is MS Word!

I see their fiendish plot now. When every application is a .NET application, and Linux is a merely bootloader for Wine, then there will no longer be a need for Linux.

Re:I knew it! (4, Interesting)

The Bungi (221687) | more than 11 years ago | (#6184790)

But now they say they will use Wine. What a crock of shit! If .NET is crossplatform then so is MS Word!

Did you RTFA? They are using Wine to implement the forms package only. The rest of the non Win32-specific stuff runs without Wine just fine. There's even bindings for GTK if you're not interested in the full forms package.

Just another "Oh, Ximian/Miguel/et.al are in bed with Microsoft, they suck" uninformed post.

& Another (0)

Anonymous Coward | more than 11 years ago | (#6184904)

Oh, Ximian/Miguel/et.al are in bed with Microsoft, they suck

Re:I knew it! (3, Interesting)

rhyd (614491) | more than 11 years ago | (#6185135)

Well I have to say I find your reply a little bit harsh. Arandir had obviously 'RTFA' because they had picked up the whole Wine fiasco.

its like when the mplayer (don't get me wrong i love mplayer and use it every day) team announced the ability to playback Realplayer videos provided you installed the latest version of Realplayer....?

as i understood it the original goal of mono was to implement the EMCA c# CLR specs and nothing more. Now they are going way beyond that - and the problems they are hitting are because .NET is way to entangled in the win32 api to be truly crossplatform as is. Early adopters caught up in their enthusiasm are understandably disapointed when they hear Wine is the key to making their app crossplatform because they are really not much better off than before .NET. Infact it would be better to reverse the Ximian approach to the problem and implement a lightweight .NET compatibility service as a core Wine module - at least that would be consisistant with the current rule:

if you wanna run windows programs on linux use a Wine

I use KDE, java and Mozilla mail because yeah I do kindof suspect Ximian are in bed with Microsoft

WINE is unnecessary (4, Informative)

GCP (122438) | more than 11 years ago | (#6185536)

Only client-side GUI apps that use WinForms need WINE. All other .Net apps -- including ASP.Net, non-GUI apps, Web services, apps that use browsers for their UI, client-side GUI apps using GTK, etc. -- will run without WINE.

Re:WINE is unnecessary (0)

Anonymous Coward | more than 11 years ago | (#6186306)

Correct, now guess once what all desktop apps will be using? Guess what MS Office .NET will be using?

The desktop market belongs to MS, Mono will not change that. On the server market MS isn't that strong, MONO will make switching easier there. Although Java did that allready, so i don't see the added value of MONO. I'll keep looking to .NET as windows only...

Re:I knew it! (2, Insightful)

miguel (7116) | more than 11 years ago | (#6188209)

Well, we always said we would implement the whole .NET Framework. The C# compiler, CLI and core class libraries are just a step in that direction.

There are two versions of Windows.Forms: one uses Gtk# and another one uses Wine for its implementation. The differences are covered in our FAQ and on our Winforms page. The wine version is there for those who want complete compatibility with their GUI apps developed on Windows.

If you are willing to live without overriding the WndProc method in the Control class, you can safely stick to the Gtk#-based implementation.

Miguel

Re:I knew it! (1)

Nevyn (5505) | more than 11 years ago | (#6192059)

There are two versions of Windows.Forms: one uses Gtk# and another one uses Wine for its implementation.

Ahh, cool. You should make that fact more obvious. From what I had read it looked like you either needed to write directly to Gtk# or install wine and use Win.Forms.

Re:I knew it! (1)

Arandir (19206) | more than 11 years ago | (#6187354)

They are using Wine to implement the forms package only.

Can you imagine a GTK+ or Qt that was touted as cross-platform, but you needed Wine to have a GUI? I would call that bullshit.

Maybe you don't need Wine for your .NET server, but the client will. The client will be dependent upon either Wine or a web browser. How long until that web browser is a .NET application that requires Wine?

Re:I knew it! (1)

hedge_death_shootout (681628) | more than 11 years ago | (#6204926)

Maybe you don't need Wine for your .NET server, but the client will.

Why?
If your '.NET server' is serving a web-app (i.e. html) then why would you need WINE on the client?
If your '.NET server' is using remoting as the communications protocol, then again, why does this mandate the use of WINE?

Maybe you could clarify what you're talking about here.

The client will be dependent upon either Wine or a web browser. How long until that web browser is a .NET application that requires Wine?

Well, we all know what a web-browser is, why should viewing HTML suddenly require the use of WINE? Doesnt make sense to me...

Re:I knew it! (1)

Arandir (19206) | more than 11 years ago | (#6206082)

If your '.NET server' is serving a web-app (i.e. html) then why would you need WINE on the client?

If it's just a normal web page I get, I wouldn't have any problems with it. But I don't trust .NET to remain a server-only infrastructure. Microsoft's own goals say differently. What's the point of distributed components if you don't distribute them to the client? Even if WINE isn't a requirement, GNOME, Mono, or something else will be. Even if that something else is "free", it's still a major imposition on the end user.

Besides which, if present web designers aren't disciplined enough to stop requiring flash for their sites, what makes you think future designers will be any different with regards to .NET?

Well, we all know what a web-browser is, why should viewing HTML suddenly require the use of WINE? Doesnt make sense to me...

Because the browser itself will be a .NET application whose GUI will require WINE.

Re:I knew it! (0)

hedge_death_shootout (681628) | more than 11 years ago | (#6307647)

So, what your saying is:

A) if somebody writes a web-app that requires a .NET enabled client, then it will only run on .NET enabled clients.

hardly rocket science, and of course there's no way in the world that ".NET" on the server can force what bytes you serve to web clients to include .NET client-side components in some way.

B) If somebody writes a web browser in .NET then it will need .NET installed on the machine to run.

Cant argue with that, although the point seems a little pointless IYSWIM :-)

They're Not Using Wine (1)

Vagary (21383) | more than 11 years ago | (#6185277)

At least I sure-as-hell haven't been able to get Windows.Forms to work. :(

ignorant question (1, Interesting)

Anonymous Coward | more than 11 years ago | (#6188375)

Has anyone done a comparison between Mono threading and Microsoft's C# threading library? The reason I ask is I've been testing the threading in C# for heavy weight service threads and it sucks. I will qualify this with an example. Say I have a daemon thread that needs to run inside a webserver ( in this case it's IIS). The reason it runs inside IIS is because it's a webservice. therefore using IIS allows me to use the stock soap and wsdl support. It also gives me stock HTTP protocol support. The problem is this. The current .NET caching mechanism is really meant for object caching. I could be reading the API wrong and mis-interpreted the articles on MSDN about the caching support. In this particular case, I can't use COM+, since COM+ runs in it's own processes and would mean serialization. the goal of this service thread is to get updates in a push fashion from a variety of remote sources. Basically, an event driven model, so that data updates happen in small increments when needed, not based on some pull interval. I don't want to query the database for data changes, since that will be hard to scale and likely kill the database connection pool under heavy loads.

the ideal situation is to have the database have C#, C, C++ or Java triggers that can push the new values to an application layer. Having that mechanism would make it easier to distribute processes into discrete categories and tiers. With an event driven architecture, processes can proceed in either sync or async manner depending on the runtime context. So back to the threads. I've read several MSDN articles that recommend 1 heavy weight thread per CPU. Specially the recommendation for tuning Sql Server recommends 1-to-1 ratio. So if you consider IIS a heavy weight thread and a COM+ (for data access) another heavy weight thread, it would take a system with a minimum of 3 CPU's to run IIS with a heavy weight service thread. Now if I want to have more than 1 service thread running inside IIS, that means scaling vertically. Looking at the current prices for systems with 5 or more CPU's it's not cheap. From my limited understanding, the thread limitation is due to the window's thread architecture, so C# isn't to blame.

If MONO can provide the flexibility of Unix threads with a compatible CLR, it would go a long way to show OSS can produce superior server software than microsoft. I've probably over generalized and made mistakes, but hopefully some one with more knowledge will correct me.

Re:ignorant question (1)

Burb (620144) | more than 11 years ago | (#6188741)

I'm not sure what you mean by "heavy weight service threads" in this context. But in Windows terms you might be better off writing an NT service in C# (which is supported, native, out of the box) and writing an ASP.NET front end. Or maybe I've misunderstood what you are trying to achieve ...

CLR has support for explicit threading (create thread, abort thread, rendezvous...) and also a highly efficient thread pool for async execution.

Re:ignorant question (1)

f00zbll (526151) | more than 11 years ago | (#6202840)

CLR has support for explicit threading (create thread, abort thread, rendezvous...) and also a highly efficient thread pool for async execution.

Not sure what AC was referring to, but sounds like it is the equivalent to a NT Service, which would qualify the process as a heavy weight thread. Most of the threading examples given in .NET threading books, MSDN and Technet are client centric, which are not daemons. An example to compare contrast might be a multi-threaded HTTP connection like C# webclient and a server within a server. A webclient sends the request and returns the result by providing sync internally. A server within a server sounds closer to AC's description. If that is the case, perhaps a third party solution for .NET would be better.

Certainly able to write NT services using .NET (1)

Burb (620144) | more than 11 years ago | (#6211791)

.. and I've had no problems writing multithreaded listeners and the like. In fairness, I should say that I didn't have a requirement for very high performance, but I didn't think it was a slouch either.

Re:Certainly able to write NT services using .NET (1)

f00zbll (526151) | more than 11 years ago | (#6219292)

and I've had no problems writing multithreaded listeners and the like

that's actually not uncommon. I'm sure plenty of people have written multi-threaded listeners for simple HTTP server and messaging systems. The hard task is making it handle 2-4K connections/requests per second :) . Having said that, getting any kind of server/NT service to perform at that level is hard. The hardest issues with scalability that I've come across are the result of processes that absolutely had to be sync-ed. Most things you can cheat with async handling, but there are some things like transactional integrity that absolutely need sync access. Of course, most things don't actually need 100% transactional integrity. AFAIK, only hardcore real-time trading systems require that level of synchronization using event driven architecture. trying to scale distributed transaction without a semi-intelligent event system is pretty darn difficult. Many trading systems that claim real-time processing actually have quite a bit of lag (ie, minutes or post-trade-processing) and aren't real-time in the strict technical sense. I've yet to find actual applications written in C# for .NET that comes close to sub-second real-time processing. That doesn't mean there isn't. Just that I'm not aware of them.

Re:Certainly able to write NT services using .NET (1)

Burb (620144) | more than 11 years ago | (#6220708)

Seems like a fair comment.

My experience was that we could get multi-threaded C# servers to take, say, tens of requests per second, all backed onto a SQL server backend and generally with each net request corresponding to one or two stored procedure calls. This was with fairly bland hardware. That suggests (very unscientifically) that by tweaking the code and scaling up the hardware we could get in sight of maybe 100 req/sec for each server. Beyond that, not sure. This was not HTTP by the way but custom protocol based on TCP with XML content packets.

Re:Certainly able to write NT services using .NET (1)

f00zbll (526151) | more than 11 years ago | (#6228622)

You can get to 100 req/sec with some heavy duty hardware right. Look at TPC [tpc.org] and HP's superdome. I looked at the numbers and it roughly translates to 184 transactions per second per CPU. In the case of the HP TPC results, the full disclosure showed they used embedded C module to crank up the performance of 64bit Sql Server. The server also isn't your typical dual or quad CPU box. The motherboard uses NGIO or something similar which uses switch architecture to share memory across 64 CPU's. I believe mainframes are still king when it comes to multi-CPU setups. The biggest mainframes are capable of supporting 128 CPU's, but you also pay through the nose for it.

There was an article recently on MSDN that talked about async request handling in IIS 6.0, which is supposed to use .NET thread pool instead of the I/O thread pool like IIS 4 and 5. I could be wrong and mis-quoting the facts from the article. The author of the article did use a custom thread pool library to improve async request handling, so there are limitations of the standard thread pool class.

More WINE-ing (-1, Offtopic)

poptones (653660) | more than 11 years ago | (#6188995)

So it's another GPL project tied to WINE and the MonSter that ate Redmond?

I wish I had the skills to craft a better deskptop for linux, because it sadly needs it. And every time I see some neat new desktop I look carefully, hoping to find it uses some wonderful new system that does away with the hideous kludge that has become of both Gnome and KDE and X11 in general. I hope because I want a *nix desktop that will carry me into the new millenia feeling like an astronaut and not a WWI aviator held in the sky with toothpicks and rubber bands. I keep hoping that I won't have to switch form one proprietary system (windows) to another (apple) just to get all this.

I have the will to switch, but I don't have the skills to craft a better desktop. And, apparently, neither does anyone else in the open source community.

Pretty offtopic really (2, Insightful)

Burb (620144) | more than 11 years ago | (#6189049)

"So it's another GPL project tied to WINE and the MonSter that ate Redmond?"

No

WineLib is there to aid people who want to write Windows.Forms (fat client) applications that are cross-platform. But you could write "pure" *nix stuff using the GTK bindings without using Wine, and you can write console mode and asp.net apps without Wine.

Has nothing to do with the desktop.

Sure it does (1)

poptones (653660) | more than 11 years ago | (#6189271)

GTK is just more ugly crap. Why not make a windows.forms widget set that departs enough from both to allow writing "fat cient" code for either platform? Make it something better than the MS version instead of just making it something almost as good as.

Re:Sure it does (1)

wazlaf (681158) | more than 11 years ago | (#6189544)

How would you want to magically turn it into something better? You are limited by the Windows.Forms API, you do not really have the space for modifications if you want the whole thing to be compatible with applications designed to run on .NET for windows.

Mono is about more than the desktop| (1)

Burb (620144) | more than 11 years ago | (#6189662)

My point was really that Mono is about more than "the desktop".

Mono is progressing nicely! (2, Interesting)

r4lv3k (638084) | more than 11 years ago | (#6203215)

I have an application that relies heavily on XML serialization, and am happy to report that the latest System.Xml.Serialization in CVS is now working as it as it should. All the Xml attributes are completely compatible AFAIK and I am seriously considering porting 5% of the code of my app that depends on Managed C++ to use P/Invoke and Mono.

This is a great leap forward for supporting SOAP/WSDL I imagine. My applications pretty much persist themselves into an XML language.

Great work Mono team!

BTW it would be awesome if Mono was optimized for the new AMD64 Opteron!

r4lv3k
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?