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

 



Forgot your password?
typodupeerror
×
Programming The Internet IT Technology

Mono Beta 2 Released 289

A little birdy writes "Less than a month after Beta 1 was released, Mono Beta 2 has been released. See the Release Notes, or go directly to the download page. It includes a C# compiler, an implementation of the Common Language Infrastructure and two stacks of APIs: a Unix, Linux, GNOME, Mono stack for APIs that takes the most advantage of your Unix server and desktop and a set of APIs compatible with the Microsoft .NET Framework 1.1 that provides support for ASP.NET (web services and web forms), ADO.NET and many other components." And in a related story: darthcamaro writes "The drive to develop a FOSS implementation of Microsoft's .NET framework by DotGNU and Novell's Mono project is being painted as a contest between the Free and Open Source communities in an article on internetnews.com. The article details the running argument between DotGNU's Norbert Bollow and Mono's Miguel de Icaza on the issues of commercial involvement, software patents and all the 'religious' stuff that the Free software community holds against the open source community."
This discussion has been archived. No new comments can be posted.

Mono Beta 2 Released

Comments Filter:
  • by Anonymous Coward on Thursday June 03, 2004 @12:28PM (#9326869)
    Is this the same as Stereo Alpha 1?
  • by barcodez ( 580516 ) on Thursday June 03, 2004 @12:30PM (#9326889)
    Does anyone know of any significant applications developed using the Mono Linux API stack yet?

    Also will the applications I write with this stack work on Windows?
    • by Tobias Luetke ( 707936 ) on Thursday June 03, 2004 @12:35PM (#9326938)
      Well there is a compelete java vm which can run exclipse for mono. ( i know thats pretty hard to get the head around )

      ikvm [ikvm.net]

      also all major asp.net applications run
    • Sort of putting the cart before the horse is it not, building significant applications when the platform is in beta. Personally I would have anyone suggesting porting major applications, or building them for that matter, to an unproven beta platform taken outside and beaten thoroughly.
    • by Trigun ( 685027 ) <<xc.hta.eripmelive> <ta> <live>> on Thursday June 03, 2004 @01:00PM (#9327199)
      will the applications I write with this stack work on Windows?

      If you write a pure C# program that does not use the GTK-Sharp , QT-sharp, or any other neat bindings, it should run. The very simple Hello World apps work.

      I still think that the mono developers are straying a bit from what they should be doing. For the windows forms, they are relying on certain wine-libs. This works, but is not as elegant as it can be. Miguel was talking about the next incarnation of gnome being written in C#, essentially using the Gnome bindings for it. My opinion is that they should build gnome to natively handle the windows.forms portion. I am not so tied to the look of the applications as I am functionality. I could care less if Microsoft.office.NET looks like gnome when run on gnome.
      • by miguel ( 7116 ) on Thursday June 03, 2004 @01:06PM (#9327257) Homepage
        I agree that building on top of Wine is far from
        ideal, but it has some benefits. For instance
        we are able to support applications that want
        to embed IE, or use Direct3D.

        Miguel.
        • by wasabii ( 693236 ) on Thursday June 03, 2004 @01:27PM (#9327468)
          Additionally, Gnome GUI programming is much different, and SUPERIOUR to the Windows.Forms layout. Windows.Forms reflects that exactly, Windows. Absolutly positioned buttons, and loosely wrapped COM controls. GTK layout is vastly different, using theming engines, multilingual input methods, and automated layout and positioning. Additionally the font support in the Gnome stack can select glyphs from multiple fonts.

          Windows.Forms is built for Windows... and thusly, running it under Wine is a perfect compromise.
          • by Anonvmous Coward ( 589068 ) on Thursday June 03, 2004 @01:33PM (#9327521)
            "Absolutly positioned buttons..."

            I'm looking forward to Longhorn's vector based UI. The static buttons problem goes away at that point. Within the last year or so, MS made a deal with ... oh I wanna say Viewsonic, but I could be in error about which company it is. They were going to create a 300dpi LCD screen. The idea was that Longhorn would just get clearer and clearer as the resolution goes up, as opposed to the buttons getting smaller and smaller. I've seen interfaces made with Flash that do that. Fun stuff.

            We got some cool stuff coming along in the next few years.
            • I'm not sure that vector graphics really solve the widget layout problem. Say I have a 1024x768 desktop, and I have an editor window (a toolbar across the top and a big text area) open which is sized to 640x480.

              If I maximize the window, I want the toolbar to stay the same size, but the text area to get bigger... just scaling everything won't work.
              • "If I maximize the window, I want the toolbar to stay the same size, but the text area to get bigger... just scaling everything won't work."

                I don't think he meant rescale in lieu of resize. No reason why you couldn't have both. The simple fact of the matter is that you need your toolbars at etc to be resolution independent.
        • The Wine Mono combonation is really a blurring of the platforms. Does anyone know if GTK# and the other linux only libs will be ported to run on the Windows version of Mono?
          • by rootmon ( 203439 ) on Thursday June 03, 2004 @02:40PM (#9328237)
            Yes, they already are ported. You can write GTK/GTK+/GTK# apps for Windows today.

            See http://www.nullenvoid.com/gtksharp/wiki/index.php/ BuildingGuide?PHPSESSID=d0459fba82585e5219f9d4c95c 24721f
            for an on-line guide.

            I've been using GTK apps like GIMP and DIA at work where I'm stuck with Windows for a long time now.

            GIMP Win32 installer: http://www2.arnes.si/~sopjsimo/gimp/

            DIA Win32 installer:
            http://dia-installer.sourceforge.net/

            BTW there are very few if any "linux only" libs. Most of those libs are part of the GNU System, they work with the Linux kernel, BSD variants, Solaris, and most UNIX Systems. Many have Win32 ports or ports to the Cygwin POSIX environment for Windows.
        • I have no arguments about your great work towards Mono on a technical basis.

          I am worried with wine and about vendor lock in as well since the Windows version will always be better since MS would just set the standards. This is how MS beat Borland.

          Have you ever thought about releasing gtk# to .NET on Windows or having a 100% free gnu mono set like mingw on Windows with a free windows.form api?

          THis might convince some developers to cross platform their apps rather then only focusing on Windows after standa
      • by Pflipp ( 130638 ) on Thursday June 03, 2004 @01:08PM (#9327272)
        I could care less if Microsoft.office.NET looks like gnome when run on gnome.

        Dude, in the UNIX world we call this a major accomplishment!
      • by misleb ( 129952 ) on Thursday June 03, 2004 @01:43PM (#9327633)
        If you write a pure C# program that does not use the GTK-Sharp , QT-sharp, or any other neat bindings, it should run. The very simple Hello World apps work.

        This isn't exactly true. You can run gtk-sharp applications on Windows. There is a Win32 port of GTK. You can't, however, run gnome-sharp applications on Windows. But GTK is good enough for most GUI apps. I am not sure about qt-sharp and Windows though. There is QT for windows, so I imagine qt-sharp should work.

        -matthew

      • by IamTheRealMike ( 537420 ) on Thursday June 03, 2004 @01:56PM (#9327769)
        OK, so the fundamental issue here is one of toolkit quality.

        You said that if you don't use GTK# your app will run on Windows. This is wrong. GTK# apps can work on Windows, or MacOS X just fine.

        Understand this: the portability of an application is not defined by the type of machine (virtual or not) it's running on, it is by and large defined by the portability of the compilers and frameworks/libraries it relies upon.

        GTK+ is a portable widget toolkit, it works pretty well on Windows and MacOS. The Win32 widget toolkit is not very portable, mostly because the only open source implementation is the Wine implementation and Wine by policy only concentrates on application compatibility, not on having nice pretty widgets.

        So, if you are writing a .NET application you are best advised to use GTK# - this is true even if you are writing a program meant for Windows as in future if you wish to port things to another platform it will be a lot easier. There are a few other things to consider as well, such as the nicer API GTK has.

        As to the DotGNU approach vs the Mono approach, basically I think you'd have to be insane to want to reimplement what Wine has done. Nobody is going to use System.Windows.Forms on Linux because it blows goats, everybody will use GTK# or (maybe when it is mature) Qt# - therefore a SWF implementation is useful only for application compatibility.

        As to mapping S.W.F to Gnome/GTK, forget it. Back in the day (waaaaay back) Wine attempted to map the Win32 widget toolkit to Tk which was one of the better toolkits available back then. Didn't work. Widget toolkits differ too much to succesfully map between, and in particular the differential between a modern toolkit like GTK+ and Win32 is enormous - why do you think Microsoft are so keen to scrap it and start over with Avalon?

      • >> I could care less if Microsoft.office.NET looks like gnome when run on gnome.

        You could care less? So it does bother you then? So why did you say "I am not so tied to the look.." ?
    • Also will the applications I write with this stack work on Windows?

      Yes. Even apps written with GTK-sharp will work on Windows (provided you install the gtk-sharp .dlls).

      -matthew

    • by arvindn ( 542080 ) on Thursday June 03, 2004 @01:36PM (#9327556) Homepage Journal
      Mono apps for gnome:

      Muine [gooeylinux.org], a media player

      Woodpusher [sourceforge.net], an ICS chess client (seems to have stagnated recently though).

      Dashboard [nat.org], an exciting new user interfact paradigm.

      I'm sure there are others, these are the ones I remember off the top of my head.

      • That should read:

        "Mono apps for gnome on x86."

        This is my major problem with Mono. They chose a development path which prevents a huge portion of their class library from working on non-x86 systems. Because they chose to lean on Wine libraries, I can't do anything useful with Mono in my primary development domain.

        Any chance of X11 bindings in an upcoming release? I'd love to make my projects portable across platforms with Mono, but it just doesn't seem feasible right now.

        Taft

        • by pridkett ( 2666 ) on Thursday June 03, 2004 @02:02PM (#9327840) Homepage Journal
          Umm, you obviously haven't look at mono that carefully have you? The JIT also exists for PowerPC linux and S390 linux, in addition to Solaris SPARC, PowerPC MaxOSX and Linux x86. There is an interpreter for a whole slew else.

          As for the class library, that's just FUD that you're spewing. Yes they have chosen to use Wine for Windows.Forms, no use in reinventing the wheel here for a tiny population. But all the applications the parent of your post mentioned don't use windows.forms. In fact, the engine is flexible enough that Miguel got MonoDevelop (the IDE they've ported from SharpDevelop) to run on his Mac under OSX. See his blog entry [ximian.com] for more information.

          I wrote a fairly complex simulation engine under Mono that runs flawlessly on my Mac and Windows. This includes a user interface that is not Windows.Forms.
        • by miguel ( 7116 ) on Thursday June 03, 2004 @03:47PM (#9328881) Homepage
          That is incorrect.

          All the applications listed above are Gtk applications
          and I have run them all on Linux/x86, Solaris/SPARC,
          MacOS/ppc, LInux/PPC.

          Miguel.
  • wait (Score:2, Interesting)

    by Anonymous Coward
    Do we like this project, or hate it?
  • C# compiler (Score:4, Interesting)

    by Anonymous Coward on Thursday June 03, 2004 @12:35PM (#9326935)
    The mono C# compiler is a work of engineering genius.

    It uses a program called TreeCC which goes beyond the Lex+Yacc model and provides an aspect-oriented tree programming model. This makes it very easy to write visitor patterns on your tree, and you can do syntax and semantic analysis with ease.

    The resulting source code for a full working C# compiler is minute. TreeCC expands it into the real code.

    Check it out!
    • Re:C# compiler (Score:5, Insightful)

      by albalbo ( 33890 ) on Thursday June 03, 2004 @12:53PM (#9327141) Homepage
      Are you sure TreeCC is used for Mono?

      It is on the same website [southern-storm.com.au] as Portable.NET, the C# compiler for the Dot GNU project, not Mono.
    • Re:C# compiler (Score:5, Insightful)

      by CommandNotFound ( 571326 ) on Thursday June 03, 2004 @02:17PM (#9328018)
      ...from your description, it sounds like TreeCC is the work of engineering genius, not the C# compiler.
    • Re:C# compiler (Score:3, Informative)

      by TummyX ( 84871 )
      WTF!!!. Who the hell modeded this guy up. The Mono C# compiler is a work of crap.

      The Portable.NET C# compiler is a work of genius. It was written by Rhys Weatherly who is the guy who *INVENTED* treecc. The Portable.NET C# compiler (cscc) can also compile C and Java to *PURE* IL code. It is a properly designed compiler with pluggable frontends and backends (like gcc).

      Downoad the source to Portable.NET and you'll discover which project will suceed in the long run. It just doesn't get much press.
      • Hey dude.

        Chill it out man.

        There is hardly a need to be so abrasive, especially of people working on open source software.

        The mono C# compiler isn't "a work of crap". It's a compiler. Use it, don't use it, but until TummyX has written a better one, I'd suggest you not denounce that with such fervor.

        PNET C# compiler's features are to be lauded, to be sure, but I'm thinking that you may be overstating the impact of the facts. Is it really amazing that a compiler can emit (in your emphasis) *PURE* il? So d
  • Performance (Score:4, Interesting)

    by grunt107 ( 739510 ) on Thursday June 03, 2004 @12:35PM (#9326937)
    It will be interesting to see what the performance comparisons of MSNET/MonoNET and MonoNet/LinJava. I would also like to see the CLI for Java project gain steam to take over some MS mkt share on the Winserver side (and allow seamless upgrades to Lin/Unix for those). Since C-pound is much like a C++/Java mutant it is not hard to transfer to the language.
    • Re:Performance (Score:5, Informative)

      by miguel ( 7116 ) on Thursday June 03, 2004 @12:53PM (#9327147) Homepage
      Mono is fairly efficient, but there is a lot of
      room to grow optimization wise. There is no clear
      answer to this question. Although Our JIT engine
      implements a fairly advanced SSA code optimization
      platform, and it also allows for pre-compilation
      in batch mode (we typically get a 20-25%
      performance on applications) it really depends
      on the software you run.

      Typically we have been able to tune Mono when
      people have pointed out a major performance issue
      by profiling the problem: sometimes the fix is
      simple, sometimes it requires the JIT codebase
      to be improved.

      Work on improving the JIT engine continues,
      we recently checked in better register allocation
      for some corner cases, better inlining of intrinsic
      functions, loop-based optimizations and removing
      array bounds checks.

      If your program is I/O bound, a different set of
      issues arise, so am sad to say `it depends'.

      miguel.
      • Yeah this is not suprising as such a big framework as .net should be difficult to implement efficiently. I don't understand how big complicated projects like mono,wine, etc. get developpers when the simple things in linux don't work well yet. The desktop interfaces are buggy, hardware support is flaky, program installation is a bitch unless you have an RMP for your exact version of your exact distribution. It took me forever to install Mandrake or Fedora on my computer with brand name hardware (ASUS mothe
        • Because while there is a little overlap, "the developers" of Linux and "the developers" of Fedora/Mandrake/etc and "the developers" of Mono are different people.
      • by illsorted ( 12593 ) on Thursday June 03, 2004 @01:59PM (#9327802)
        I don't know
        which is worse,
        reading or
        writing comments
        for slashdot on
        my cell phone.

        Keep up the great
        work Miguel.
      • Re:Performance (Score:5, Interesting)

        by Chester K ( 145560 ) on Thursday June 03, 2004 @02:27PM (#9328128) Homepage
        Mono is fairly efficient, but there is a lot of room to grow optimization wise.

        The Slashdot crowd might be interested to know that recently on the mono-devel list there have been benchmarks and discussions on moving the implemention of Mono's System.String class from native code to managed code since Mono's JIT actually already provides better performance than the native code does in that case.

        Though the performance increase (which is 50% in one case!) can be mostly attributed to no longer having to go between managed/native code, that a pure managed solution is faster is impressive on its own regardless.
    • Take a look here [cornell.edu] and see if this is what you're looking for.
  • by bryhhh ( 317224 ) on Thursday June 03, 2004 @12:35PM (#9326941)
    I'm quite interested in seeing the first tools to take advantage of System.DirectoryServices [go-mono.com], as this should enable us to manage a windows Active Directory natively from Linux.
  • by jacksonyee ( 590218 ) on Thursday June 03, 2004 @12:36PM (#9326946) Homepage
    For Bollow, the decision to build a framework that is compatible with .NET is based on market reality. "In the industry, companies are using Microsoft stuff. The only way we can make it possible at acceptable cost to migrate to GNU/Linux is by making it possible for them to run their essential apps on both systems," he said. "My goal is to prevent Microsoft from catching the world in their .NET."

    I agree with Bollow's reasoning and reality, but I fear that his sentiments may fall far short of his dream. He'll have to cope with

    1. Trying to implement a moving standard as Microsoft continues to update libraries and APIs
    2. Dealing with any incompatibilities and bugs within Microsoft's .NET code
    3. Potential legal threats from miscellaneous things which Microsoft may choose to patent
    4. Acceptance from both Microsoft supporters and Linux supporters to convince both sides to use one common platform

    With that said, I think it's a very good idea to try to slowly nudge Microsoft developers over to other platforms, particularly if we come out with more advanced and/or convenient features than Microsoft's own standards. Nevertheless, time will tell whether this project pans out or not.

    • by SuperKendall ( 25149 ) * on Thursday June 03, 2004 @12:45PM (#9327058)
      Here's what is actually happening. When companies are deciding on .Net or other technologies, these projects are held up as examples of how choosing .Net will not lock you into Windows. Then they go ahead with buying the Windows servers and developing the half working .Net app.

      He may think he's giving companies choice to move to Linux. But what he is really doing is providing justification for choosing Windows.
      • He may think he's giving companies choice to move to Linux. But what he is really doing is providing justification for choosing Windows.

        Well said. I wish the Mono developers would concentrate their considerable talents elsewhere.
    • by WombatControl ( 74685 ) on Thursday June 03, 2004 @12:51PM (#9327119)

      This seems like a legitimate set of concerns, but I think the ability of Microsoft to change the game at this point is severely limited.

      The reason why Microsoft can't radically alter .NET is because of the existance of legacy apps. The company I work for has thousands of man-hours and hundreds of thousands of dollars into our ASP.NET applications. Microsoft can't break these applications. The .NET API has to remain consistant or they'll lose that legacy application support and lose customers. The fastest way to piss off an IT department is to make a change that breaks their apps. Believe me, I know...

      So, if Mono can get the .NET 1.1 standards done, they can support all those legacy apps with few changes. Even if/when Microsoft introduces some spiffy new libraries with .NET 2.0, businesses can still say "it's cheaper for us to get off the forced upgrade wagon and move to Mono as a platform for .NET and we can keep our legacy applications." Unless .NET 2.0 comes up with some massively useful new system, there isn't that strong a reason to upgrade.

      Granted, Microsoft can still pull out a patent and try to shut Mono down, which remains a threat, but I don't see them as doing that. All Mono has to do is use that as a talking point - don't develop for .NET because of patent issues. This hurts Microsoft by slowing the adoption of .NET. The worst that happens is that Mono has to fall back on its own libraries, and given that things like Gtk# are useful on their own they still have something to show for their work.

      The more I think about it, the more I think Mono is in a strong position. I'd be more worried about Microsoft unleashing a patent infringement case than I would about them changing the APIs to shut out Mono. If they did that, they'd be shooting themselves in the foot.

      It's as if Linux were able to run all Win95 applications just as Windows 2000 was coming around. Yes, Windows 2000 was infinitely better than 95, but if you're a PHB and you have a choice of moving your legacy apps to an expensive proprietary system or a free open one, you're going to be more inclined to do the latter as it makes your bottom line better. Legacy app support is absolutely crucial and right now Mono can do something that not even Linux can do - support Microsoft-based legacy apps with a minimum of changes. That gives Mono a big advantage in the marketplace, and while it helps Microsoft move developers to .NET it also helps make Linux a more attractive platform for enterprise development, especially on the backend.

      • >The reason why Microsoft can't radically alter .NET is because of the existance of legacy apps. The company I work for has thousands of man-hours and hundreds of thousands of dollars into our ASP.NET applications. Microsoft can't break these applications.

        Hehe. Heeeheeeheee. Thanks.
      • Microsoft can't break these applications.

        Are you serious, or in denial? There are precious few interfaces in this business that are so carefully and completely defined that they never change, or that are so absolutely backward compatible over time. (The ones that are, are a wonder to behold). For history, look at DOS to Win16 to Win32, or HTML support in IE, all claiming some measure of backward compatibility but with gaping holes. Look at the list of software that breaks when a major OS release come

        • by WombatControl ( 74685 ) on Thursday June 03, 2004 @01:51PM (#9327713)

          Granted, specifications do change, but:

          • In order to break Mono, Microsoft would have to break many apps using the current MS.NET implementations as well.
          • This would require every .NET application to be rewritten to the new spec.
          • If people are going to rewrite their applications they're going to be far more likely to switch to a new platform, especially if they've already migrated to an open platform with .NET.
          • Legacy applications are a fact of life. There are tons of applications build for Win95 that are still used every day. Windows 98 still has considerable marketshare in the business world.
          • Breaking legacy applications is a good way to go out of business, which is why Microsoft bends over backwards for compatibility wherever they can.

          Businesses tend not to be early adopters. I still use Office 2000 at work. My boss uses Windows ME (ugh, I know...). Our apps are designed around ASP.NET 1.1 on the server side. If Microsoft started forcing us to upgrade everything, we'd have to tell them to kiss off. Our IT budget doesn't support forced upgrades. Believe me, we're not alone in that, and that's why Microsoft can't suddenly start breaking widely-used libraries to kill Mono - it would be shooting themselves in the foot.

      • The reason why Microsoft can't radically alter .NET is because of the existance of legacy apps. The company I work for has thousands of man-hours and hundreds of thousands of dollars into our ASP.NET applications. Microsoft can't break these applications.

        Really? VB.net is not backward compatibile with VB6. [ftponline.com] How many millions of man hours were spent writing VB code that now has to be rewritten to play in .net? Microsoft is concerned with their own position. You will be screwed over insofar as you are sti
        • That's FUD.
          VB6 apps would run just fine. Just use old VB6 for development. Hell.. some companies still use Visual Studio 5.0 for development (I worked for such a company).
          Don't want .net? OK, write your apps in VB6 as you always did.
          vb6 and vb.net use different technologies and even syntax in some parts is different. It's different product, that's all. They didn't break any API.
        • Talk about some FUD... Give me a break man. You quoted apples, then compared oranges. Microsoft did not intend .NET to be backwards compatible with VB6. It's an entirely different technology. As another poster pointed out, you can run VB6 apps and .NET apps side-by-side with zero issues. VB.NET is not an upgrade to VB6, its an entirely new language. They share syntax in many ways, but VB.NET is an entirely different way of thinking in that its OOP implementation isn't incomplete/just a hack. Why in the wor
  • Does Anyone know.. (Score:2, Interesting)

    by millahtime ( 710421 )
    Does anyone know if M$ has gotten or is getting a patent for the way .NET works. If Mono is to close to something like that they could try and squash the whole project.
    • by Erwos ( 553607 )
      I would highly recommend you actually do some research for yourself rather than forcing /.'ers to do it.

      However, for those who were wondering:
      When Microsoft got .Net as an ECMA standard, they were forced into giving out the patents as RAND: royalty-free and non-discriminatory licensing. Non-discriminatory does not _necessarily_ mean GPL compatible, which is where the problems could arise. However, other people have noted that Microsoft does not generally use _patents_ offensively, and thus the threat is p
      • by albalbo ( 33890 ) on Thursday June 03, 2004 @12:51PM (#9327118) Homepage
        "I would highly recommend you actually do some research for yourself rather than forcing /.'ers to do it."

        Well, quite.

        RAND != Royalty Free and Non-Discriminatory

        RAND == Reasonable And Non-Discriminatory

        So, in fact, they *can* and *do* charge money to licence patents under RAND. RAND is not good enough for any Free Software, GPL or otherwise.
        • by Gopal.V ( 532678 )
          You cannot pay Royalty licensing for a GPL'd codebase ...

          GPL is very clear about that ... quoting ...

          Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

          Novell might be forced to make it proprietary if Microsoft

      • "RAND" is generally considered a bad thing by the open source/free world. As another poster has pointed out, it does not mean "royalty-free" -- it means "reasonable". This means that, yes, royalties may be charged for any software using said patent (which obviously creates barriers for anything that is distributed free-as-in-beer and is incompatible with the GPL/LGPL).

        The W3C is one of the tech standards organizations that does *not* allow RAND (thanks to outcry from the community when HP, Apple, Microso
      • by burnin1965 ( 535071 ) on Thursday June 03, 2004 @03:03PM (#9328495) Homepage
        Do not presume that MS's past use of patents for defensive purposes only means there is a low probability of threat to the Mono project...

        MS has hired an IP manager who not only believes in but has spearheaded IP rampages. [legalmediagroup.com]

        "Marshall Phelps has long been a vocal advocate of the need for companies to take IP licensing seriously."

        "...he inspired at his previous company, IBM, which is now reaping almost $2 billion a year from licensing its patents."

        "At IBM we did a lot of it. We had lots of lawyers doing preparation and prosecution around the world. At Microsoft, we don't have anyone doing that, but we are going to start."

        "According to Phelps, managers too often fall into the trap of seeing patents as a purely defensive measure, a tool with which to stop the competition in their tracks.

        Phelps says he is pleasantly surprised by just how understanding Microsoft's executives have been. "On these IP issues I don't have much of a problem getting anyone's attention at Microsoft. It starts at the top, and if you've got a guy like Bill Gates who's really concerned about IP and really likes it then you don't have much of a management problem."



        Make no mistake about it, Microsoft has learned to do business by using its capital to get what it wants. Microsoft cannot buy out FOSS but they sure as hell can litigate FOSS directly or indirectly to "stop the competition in their tracks."

        As most everyone here knows, FOSS has been on the Microsoft radar for several years now and they have been very active and very unsuccessful in halting the progress of FOSS.

        This is the last ditch effort on Microsoft's part to stop what is becoming an unstoppable force. It will not matter if the FOSS community produces a better and more technologically advanced product because Microsoft will not be competing based on the merit of their products.

        Whether or not the patents that are filed are frivilous and ridiculous, they will be used offensively to diminish the threat of FOSS to the Microsoft revenue stream.

        Be prepared, there is more of the SCO syndrome to come.

        burnin
  • by mrright ( 301778 ) <rudi AT lambda-computing DOT com> on Thursday June 03, 2004 @12:42PM (#9327018) Homepage
    The only information that is needed for the success of mono is the following: are the relevant ECMA standards 334 [ecma-international.org] and 335 [ecma-international.org] and just RAND, or are they really RAND and royalty free as miguel [oreillynet.com] and others have claimed?

    If it is really RAND and royalty free, it will become my favorite development platform. Working with .NET is really very nice and productive. Microsoft will finally have made a valuable and lasting contribution to computer science.

    If not, it is just another poisoned fruit by microsoft.
    --
    • are the relevant ECMA standards 334 and 335 and just RAND, or are they really RAND and royalty free as miguel and others have claimed?

      The standards are royalty free, however the standards only cover the CLR (the VM/JIT) and C# the language, not the Framework (all the classes that do stuff).

      That's partially why the Mono folks are making two stacks -- the Microsoft-compatible stack, which may be patent encumbered (though Microsoft has never yet used a patent offensively); and the Mono stack, which isn't ch
  • Garbage Collector? (Score:5, Interesting)

    by mrright ( 301778 ) <rudi AT lambda-computing DOT com> on Thursday June 03, 2004 @12:50PM (#9327100) Homepage
    I was under impression that mono has switched to a modern generational garbage collector, the Intel ORP GC [sourceforge.net]. But the current beta uses the conservative boehm garbage collector [hp.com].

    A conservative GC is nice for a quick hack, but it really does not cut it for a modern VM.

    So which one will it use in mono 1.0? Boehm or ORP? And if it is the boehm collector, what plans are there to switch to a modern GC?

    By the way: the conservative garbage collector is the only real technical flaw of mono. Other than that it is quite a modern VM. Quite amazing for this short development time...

    --
    • by miguel ( 7116 ) on Thursday June 03, 2004 @12:58PM (#9327178) Homepage
      We are using the Boehm collector in precise mode,
      so all we are missing is the compacting features. It does a fairly good job, and we can run large
      applications with good success.

      Doing a compacting collector is in our radar,
      but we have to balance our resources: port to
      new platforms, support 2.0 features and improve
      performance.

      Mono 1.0 will use Boehm, but after that we might
      consider using a different collector (in fact,
      we have some preliminary patches for doing
      refcount-based systems).
      • by mrright ( 301778 ) <rudi AT lambda-computing DOT com> on Thursday June 03, 2004 @01:08PM (#9327274) Homepage
        We are using the Boehm collector in precise mode, so all we are missing is the compacting features. It does a fairly good job, and we can run large applications with good success.
        But a generational GC would have much better performance for short-lived objects, wouldn't it?

        Doing a compacting collector is in our radar, but we have to balance our resources: port to new platforms, support 2.0 features and improve performance.
        As long as you keep in mind that you will have to change to a generational GC some day, thats O.K. The generics of 2.0 will reduce the load to the garbage collector because putting valuetypes into a (typed)collection will no longer require boxing.

        Mono 1.0 will use Boehm, but after that we might consider using a different collector (in fact, we have some preliminary patches for doing refcount-based systems).
        Refcounts? I thought the problem with refcount-based systems was that they were not able to deal with circular references. What have I missed?
        --
        • by miguel ( 7116 ) on Thursday June 03, 2004 @01:11PM (#9327301) Homepage
          You can do cycle detection in reference counting,
          there are various papers on the subject.

          Refcount is bad for small apps, but good when you
          have applications that use a lot of memory (since
          scanning even with generations is an expensive
          process).

          There are various papers on Citeseer on the
          subject.
        • Refcounts? I thought the problem with refcount-based systems was that they were not able to deal with circular references. What have I missed?




          Cycle breaking. See python.


          Basically, ref counting is used as an optimisation : for things which this works on, its a great boost. For the rest, mark-and-sweep is used anyway.
        • Isn't the boehm collector generational?
  • by LilMikey ( 615759 ) on Thursday June 03, 2004 @12:54PM (#9327152) Homepage
    ... let's see those windows.forms! By the release notes it sounds like progress is being made but they said what's shipping with 1.0 will be pre-alpha.
    • by miguel ( 7116 ) on Thursday June 03, 2004 @01:04PM (#9327229) Homepage
      Yes, we are not able to fully support the
      Windows.Forms API on the 1.0 timeframe (you can
      get the previews, but they are not ready to ship).

      Windows.Forms has a number of problems for
      open source software anyways: for instance, it
      does not do constraing-based layout, so for
      every language that you want to support, you must
      relayout your dialog boxes manually (or if you
      have a larger font size).

      By using Gtk# you take advantage of the Linux-specific
      APIs and Linux-specific features (you can use
      Gtk# on Windows, Linux and MacOS).

      On the other hand, there is a community of
      MacOS developers working on bindings to Cocoa
      bindings to give them the same flexibility and
      OS integration on the Mac.

      Windows.Forms would give you a Windows-solution
      everywhere.

      We are going to support it for the sake of helping
      Windows developers move to Unix, but it is not
      a particularly great toolkit.

      miguel.

  • by SPravin ( 646932 ) <rfc9000&yahoo,com> on Thursday June 03, 2004 @12:57PM (#9327175) Homepage
    Ive seen MonoDevelop and SharpDevelop and am not impressed with either. The day Novell is able to churn out an IDE like VS.NET for MONO is when Mono will be really able to make waves.
  • Why? (Score:3, Interesting)

    by Saeed al-Sahaf ( 665390 ) on Thursday June 03, 2004 @01:05PM (#9327244) Homepage
    There is a post that asks about any apps that actually use Mono (and really, was that the best choice of names), so mybe this is redundent.

    But... it this something that is a serious effort, or is it just an "If Microsoft can do it, Open Source can do it better" thing? Is there really a need / purpose / use for this other then to "one-up" the hated M$?

  • by Eric Damron ( 553630 ) on Thursday June 03, 2004 @01:06PM (#9327252)
    MONO is a very exciting concept. Having some degree of compatibility with Microsoft but with the current SCO-like strategies of litigating competition out of the picture and with the general feeling that Microsoft will use patents as a way of stifling it's biggest threat why should I feel good about the project?

    Maybe someone can help me out here? What is going to prevent Microsoft from playing the patent card when it suits them?
    • What is going to prevent Microsoft from playing the patent card when it suits them?

      Microsoft has never used a patent in that manner. Nor do most companies, actually -- patent portfolios are built more for defense than for offense. Making money out of patent litigation is something that fly-by-night vulture companies do, not blue chips like MSFT.

      Second, Microsoft has much to lose themselves from shutting down Mono. They often point to Mono as an example of the flexibility and interoperability of their pla
  • Does mono do SSL? (Score:2, Interesting)

    by Anonymous Coward
    That was the big showstopper and why my last project used java. Has it changed?
  • workable stack? (Score:3, Insightful)

    by BigGerman ( 541312 ) on Thursday June 03, 2004 @01:36PM (#9327562)
    So if I am to start developing a new desktop GUI application, what should I use to make it cross platform? And don't say "java" or "wxwindows".
    It cannot be C#, Windows Forms combination because Mono does not have real support for Windows Forms yet.
    Would I be able to package GTK# in some kind of installable form for distribution on Windows so I can do C#, GTK# on Mono? Is this the right way to think about this?
    Can I use Visual Studio to develop Mono, GTK# applications?
    • Re:workable stack? (Score:4, Interesting)

      by CoolMoDee ( 683437 ) on Thursday June 03, 2004 @03:08PM (#9328533) Homepage Journal
      I too am fixing to being developing a new desktop gui app. I first thought 'Java' because I like cross platformness, however, working with Swing is a bitch. So, my idea so far is to take C#, develop on the logic and db access etc. in it (using the ado.net sqlite dll), slap it into a dll. All of a sudden all of brains of my app is crossplatform from Windows to Linux/OS X. Then, all one has todo is reference the dll and build a gui in Windows.Forms or GTK# etc. I will be doing a seperate gui in Windows.Forms and one in GTK# at a later date since windows support is needed first. The above solution would allow you to use Visual Studio to create apps that should run on mono without any problems (assuming you don't take advantage of any windows specific features in the logic dll).
  • No VB.NET support (Score:5, Interesting)

    by Anonymous Coward on Thursday June 03, 2004 @01:44PM (#9327652)
    I develop ASP.NET applications using VB.NET, and it's disappointing that the VB.NET development seems to be at a complete standstill. I've been tracking the mbas [go-mono.com] (Mono Basic) project since the beginning of the Mono project, and there's been virtually no activity on it. It appears to be the work of a single hacker in his non-existant spare time.

    Although the official reason that GnomeBasic [gnome.org] was dropped was because of "stagnation", the real reason that it died was because Mono was supposed to take it's place.

    If that happened, I've seen no evidence of it.

    While you can write Mono code in Java [weblogs.com], PHP [php.net], Logo [sf.net], Oberon [oberon.ethz.ch], Pascal [qut.edu.au], Forth [dataman.ro] and Lisp [sourceforge.net], VB is still unavailable.

    It's a pity such a popular language appears to be entirely ignored.

    • Re:No VB.NET support (Score:5, Informative)

      by miguel ( 7116 ) on Thursday June 03, 2004 @05:34PM (#9329916) Homepage
      A few updates on VB.NET:

      We have a full time developer working on this
      (Anirban) and you will see a lot of work on
      compliance from him.

      Mainsoft has donated a full VB.NET runtime that
      we are now integrating.

      Rafael and others have just obtained a grant
      from the government of Brazil to complete the
      VB.NET support in Mono.

      And in addition to that, a few open source developers
      work on it on their spare time.

      You are right, the Open Source developers are not
      particularly thrilled at doing VB.NET, but it is
      important to bring developers from Windows, so
      that is why the effort is being funded.

      Miguel.
  • Mono vs DotGNU (Score:3, Interesting)

    by APDent ( 81994 ) on Thursday June 03, 2004 @01:45PM (#9327657)

    I'm sure it is heresy to ask, but am I the only one who's confused by the Mono and DotGNU difference? I read the internetnews article, and the controversy is still pretty opaque. I don't use .NET, and don't have any imminent plans to do so, but if I did, why should I prefer one implementation over the other? Is it purely a religious issue?

    To paraphrase Life of Brian: The only people we hate more than Microsoft are the f*ing Mono developers. Or the f*ing DotGNU developers. Take your pick.

    Splitters!

  • Diversity (Score:3, Insightful)

    by ChaoticCoyote ( 195677 ) on Thursday June 03, 2004 @02:53PM (#9328370) Homepage

    I've written free, open, and closed software; I've accepted money from companies big and small, and I've also been paid to work on non-commercial free projects. I try, very hard, to be an agnostic when it comes to conflicts of religion -- such as the debate of Windows vs. Linux, or KDE vs. Gnome, of C# vs. Java. Tools are tools, and it is how they are used that matters.

    And given that case, I do not like how Gnome is being used. Money drives everything, so Novell's involvement only bothers me when I consider their past history of screwing up good things like WordPerfect.

    Foremost among my concerns is how Mono can be used as a wedge by Microsoft; if they can not "beat" free software with legal trickery (e.g., SCO), they can slip behind the lines via involvement in Linux via proxies. Microsoft has proven itself untrustworthy, in my personal dealings with them as well as their highly-publicized run-ins with anti-trust law.

    I'm not against .NET or C#; I've written some C# code, just as I've written Java and C++ and Python and Fortran and COBOL over the years. I dislike proprietary standards (like .NET and Java) because they trap people, limiting choices and input form the community at large. Give me the chaos of C and C++ over the corporate machinations of C# and Java; I will accept a bit of chaos if my tools can evolve based on conceptual and community diversity.

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Working...