Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Programming Operating Systems Software Windows IT Technology

Mono 1.0-beta3 Released 38

steve_deobald writes "The Mono team just released Beta 3, the final beta before we see the 1.0 release candidate and final. Binary packages can be had for Red Hat, Fedora, and SuSE. Although not officially released, the new website is up and running. Also of note, MonoDevelop 0.4 was recently released, and has RPMs available for the first time."
This discussion has been archived. No new comments can be posted.

Mono 1.0-beta3 Released

Comments Filter:
  • by vbweenie ( 587927 ) <dominic.fox1@ntl ... m minus language> on Wednesday June 16, 2004 @03:18PM (#9445467) Homepage

    I think Miguel's made a great play for the future of applications development on the Linux platform and I hope it pays off. Anything to wean Linux developers off C/++ (not kernel developers, obviously...). The only other project that shows anything like the same promise, IMHO, is Parrot and the great assortment of "dynamic" languages that are being ported to it.

    Let a thousand flowers bloom!

    • by nelsonal ( 549144 ) on Wednesday June 16, 2004 @03:27PM (#9445547) Journal
      A year ago in January I brought Mono up to MS execs who were talking about the portability of .NET (except to Linux) and they stated point blank that the project would never finish. Good on all of you.
      • The core product groups never doubted for a second that Miguel would pull it off, mainly because Don Box and other architects working on .NET told them he would after they looked at the first alpha.

        There might be some "static" coming from the evangelism or strategy folks; I don't know. My perception of this is mostly positive.

        Microsoft, believe it or not, is happy (at least at that level) that Mono exists. There is nothing like having one of the main figures in open source sit down and implement a techn

  • explain Mono (Score:5, Interesting)

    by acomj ( 20611 ) on Wednesday June 16, 2004 @03:55PM (#9445801) Homepage
    I've visited the website..
    I can't figure out if mono is.

    1) A c# compiler? (bytecode??)
    2) A api library the is kinda like MS C# libraries
    3) An api library that had been developed from scratch.

    Or any combination of the above.

    Does it compile and run native or does it use bytecode like java?
    Can I build cross platform apps in it? (like java was supposed to be)

    I'm looking for a cross platform application building toolkit. I run OSX and linux.QT/GTK and C are some options I'm looking at, so far it looks like java/eclipse is the way I'm leaning, but this looked interesting and worth considering.

    • Mono FAQ (Score:2, Funny)

      by acomj ( 20611 )
      Repling to my own post..
      But this helped. mono faq [go-mono.com]

      An this quote explained why its hard to figure exactle what it its...
      The ".NET Initiative" is a somewhat nebulous company-wide effort by Microsoft, one part of which is a cross-platform development framework.

    • Re:explain Mono (Score:2, Informative)

      by genneth ( 649285 )
      It's the .NET framework, but cross platform. It currently consists mainly of a C# compiler and the .NET framework libraries. Several GNOME related libaries (think GTK+) have had bindings made for it.
    • by Anonymous Coward
      Mono is a disease.

      GCJ is the cure.

    • I can't figure out if mono is...[cut]

      Excellent! It is meant to be a OSS version of .net, which nobody understood what the heck it was either. (MS representatives tried to explain it for months).

      This means Mono is a success! ;-)
  • I hate to say it (Score:3, Interesting)

    by Anonymous Coward on Wednesday June 16, 2004 @08:02PM (#9447947)
    I see no measurable benefit of .NET vs J2EE. since I use and develop with both, I can say with all honesty it's a matter of preference. If someone wants to build GUI's but doesn't want to go to all the trouble of implementing custom tableModel, and treeModels, then .NET forms is easier. Of course that means your apps will look like everyone else's and reduces your competative advantage. If you prefer to code custom GUI's then you're better off using something like C++, QT, SWT or any other GUI package. On the serverside, I find .NET inadequate and the threading model inappropriate. Having to manually manage threads and constantly do callWait is not a good way to build scalable server applications. But that's from first hand experience. If I had to build server apps in .NET, I would rather do it C++ and not C#.
  • I'm quite impressed with Mono, but I'm still waiting for Windows.Forms. Until support for them is reasonably complete, Mono will remain unable to run a large number of programs written in C# or other managed languages.
    • Even Microsoft is abandoning Windows.Forms as they move towards Longhorn, which is based on a completely different GUI programming model (Avalon,XAML). Windows.Forms was always very Windows-specific, being little more than wrappers for the Win32 API. Without a complete Win32 API implementation, it's nearly impossible to bring up a 100% compatible Windows.Forms implementation on any other platform. And given that 1) again, Microsoft itself is abandoning it, and 2) there are alternatives for cross-platform
      • Microsoft may be abandonning it, but that is not going to happen until 2006 or 2007. Certainly 2-3 years of continued exclusive Windows.Forms use warrants a working implementation.

        Last I heard, Mono's implementation of Windows.Forms used WINE. So there really is an (almost) complete implementation of the Win32 API behind Mono's Windows.Forms support. I just want them to finish it, as I think it's a priority.

        Gtk# doesn't help at all for existing code (would require a port to GTK#), nor does it help for alr
        • And I also agree that the current Windows.Forms (incomplete though it is) will be used for 2-3 years by real applications prior to anyone ever really seeing Longhorn.

          I guess I'm concerned that requiring WINE to run Windows.Forms is a *huge* amount of overhead just to throw up a GUI. Especially since WINE isn't completely perfectly compatible with Windows, despite many years of trying very, very hard (perhaps I'm ignoring CrossOver Office? Begin laughter now, if I'm being too glib).

          So where would I use W
          • You seem to be considering the position of existing code; while I was talking about that, I was talking also (perhaps moreso) about existing applications.

            Consider, for example, Joe User. Joe runs Linux. Joe wants to use a program, but it's for windows. Joe has heard that Mono can run .NET applications, since they're compiled into CLI, which Mono can interpret (I believe so at least, let me know if I'm wrong). Joe tries to run the EXE on his linux machine, only to find that Mono refuses to do so because Win
            • It would be, if there were any existing windows.forms based applications, which there aren't. There are a few .net apps which use windows.forms to wrap calls to standard win32 com objects. But mostly its still straight win32 programming, and doesn't look to change before longhorn, except for the form entry type custom one-off apps that people used vb for in the past, and use HTML for nowadays.
              • I'm very surprised about that... Any .NET application designed with the integrated GUI designer would be done with Windows.Forms, no? Why would somebody writing a GUI app in a .NET language do the GUI from scratch when there's already a perfectly good (and powerful!) GUI designer/toolkit provided?
  • Portable.NET (Score:2, Informative)

    by Anonymous Coward
    For all of you talking about winforms, Portable.NET has a beautifully portable version of winforms, and its soon to get a kick in the pants with native theming support to really open some eyes.

    http://216.58.40.193/qtwinforms2.jpg
  • What languages can I currently use to write production quality CLR programs that run on Mono (and its libraries like GTK#/Gnome#) ?

    (Except for C#, of course.)

  • unless they learn how to deploy their apps on linux. It's just not good enough to target one or two point release for a couple of distros and (somehow) make it impossible to run or compile on all others.

An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.

Working...