Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Ximian IT Technology

Mono & SourceGear Move Forward 56

Posted by Hemos from the partnering-together dept.
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"
This discussion has been archived. No new comments can be posted.

Mono & SourceGear Move Forward More

Mono & SourceGear Move Forward

Comments Filter:

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

    by shibbydude ( 622591 ) on Thursday June 12, 2003 @09:01AM (#6181289) Homepage Journal
    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.
    • 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?
      • 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... (Score:2, Insightful)

        by hummassa ( 157160 )
        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.
      • "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

        • 80% of what programmers? (Score:3, Interesting)

          by phr1 ( 211689 )
          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, thoug

    • 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? (Score:4, Interesting)

    by Burb ( 620144 ) on Thursday June 12, 2003 @09:23AM (#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.

  • This Mono thing is for clever people... (Score:3, Funny)

    by d-Orb ( 551682 ) on Thursday June 12, 2003 @09:55AM (#6181780) Homepage
    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 :-)

    • 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)

      • 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# de

  • Mature? (Score:5, Insightful)

    by truthsearch ( 249536 ) on Thursday June 12, 2003 @11:05AM (#6182569) Homepage Journal
    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? (Score:5, Insightful)

      by pmz ( 462998 ) on Thursday June 12, 2003 @11:43AM (#6182982) Homepage
      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? (Score:5, Funny)

      by Miguel de Icaza ( 660439 ) <trowel.gmail@com> on Thursday June 12, 2003 @12:08PM (#6183263) Homepage Journal
      "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 :^)
      • This guy is not the real miguel, just an imposter. this [slashdot.org] is the real miguel. Notice the uid.
  • Will Mono development switch from CVS?

  • I knew it! (Score:5, Insightful)

    by Arandir ( 19206 ) on Thursday June 12, 2003 @01:29PM (#6184079) Homepage Journal
    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! (Score:4, Interesting)

      by The Bungi ( 221687 ) <thebungi@gmail.com> on Thursday June 12, 2003 @02:50PM (#6184790) Homepage
      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.

      • Re:I knew it! (Score:4, Interesting)

        by rhyd ( 614491 ) on Thursday June 12, 2003 @03:26PM (#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 (Score:5, Informative)

          by GCP ( 122438 ) on Thursday June 12, 2003 @04:07PM (#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:I knew it! (Score:3, Insightful)

          by miguel ( 7116 )
          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 cl
          • 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.

      • 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?
        • 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
          • 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 t
    • At least I sure-as-hell haven't been able to get Windows.Forms to work. :(

  • ignorant question (Score:1, Interesting)

    by Anonymous Coward
    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
    • 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.

      • 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

        • .. 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.
          • 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 yo

            • 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 prot

              • 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 mainframe
  • 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 woul

Slashdot Top Deals

We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated.

Close