Fedora Core 5 includes Mono

cyberjessy writes "Surprise! The Fedora Core 5 Release will include Mono in the distribution, in spite of Red Hat's opposition. In addition to the Mono runtime, it will also include Mono applications like Beagle and F-Spot. Is the Linux community finally ready to accept Mono? Mono is becoming increasing important due to Windows Vista, which has WinFX (the next .Net Framework) as its core API. This will mean that in future, all native Windows applications will easily run on Linux, with Mono. Will Mono achieve what WINE could not?"

Comments

Summary

[Locarius]

Yes, off topic, but it's nice to see a well written and concise topic summary around here once in a while.

Re:Summary

[timeOday]

Yes, off topic, but it's nice to see a well written and concise topic summary around here once in a while.

But how accurate is it?

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.

I think that's far premature. Without even knowing yet what the catch is, I know there will be some. I just don't think Microsoft will let Windows apps seamlessly run under Linux, one way or another.

Re:Summary

[Anonymous Coward]

That's because the editor did not edit the summary, but took it verbatim, perhaps knowing that his limited knowledge of the English language and technical issues does not permit him to make any sensible contribution.

Re:Summary

[billybob2]

All native Windows applications will easily run on Linux, with Mono?

I seriously doubt it. It would be a titanic effort to recreate the full API that M$ has created with its hundreds of billions of dollars. Instead, all Mono will achieve is to steal FOSS developers from other projects that strive to provide a programming language with a clean-syntax and a low learning curve, most notably Python. I think that would be a shame, as Python is farther along in terms of its syntax, speed, and availability of specialized modules.

.NET on W$ also benefits from being able to programatically control with IIS and SQL Server, both of which have beginner-friendly GUI administrative tools and neither of which are available on Linux.

I know a lot of .NET developers, and frankly what they like about it is the intuitive IDE, which provides code completion and which is GUI-based, allowing developers to do a lot of work simply by point-&-click. Incidentally, Trolltech is making good progress in this regard with the release of Qt Designer.

Re:Summary

[Breakfast Pants]

Well, one thing that would be nice would be to get python running in the .net VM, as it currently can do with java VMs ("jython").

Re:Summary

[aesiamun]

http://www.ironpython.com/

Looks like it is already being done :)

Re:Summary

[Anonymous Coward]

Yes, but if you RTFA, it becomes evident that, while the reviewer clearly thought that Fedora Core 5 was shipping with Mono, it turns out it was just really bored.

Re:Summary

[Glock27]

I think that's far premature. Without even knowing yet what the catch is, I know there will be some. I just don't think Microsoft will let Windows apps seamlessly run under Linux, one way or another.

Yes, as far as I know, there are no plans to clone "WinFX" at this point for Vista compatibility. Mono doesn't even have working WinForms as far as I know (after how many years?), which would provide compatibility with current Win apps.

Java provides a better level of portability than C#/CLR...I'd look there instead for a VM based runtime.

On that note, there is a Java port that runs on top of the Mono runtime and is supposedly fast. That might be worth investigating. (IronPython too if it ends up significantly faster than the regular Python interpreter.)

Re:Summary

[mrtrumbe]

Anecdotal evidence proves nothing.

As an example, I'm a .Net developer and I think the IDE sucks (well, 'sucks' may be a bit strong--how's deficient?). Add ReSharper to it and it becomes far more useful, but who really picks a language on the basis of the GUI's available for it, anyway? If we were doing that, I'd pick Java with IDEA any day.

No, what attracts me to .Net is the large, well documented framework API's available out of the box, the rich set of free third party libraries available (many (most?) of which have been ported from Java), the relatively clean and feature-rich primary language, and the subsequent rise in productivity it gives me and my programmers.

The IDE itself is a bit buggy and constricting for my tastes. Try, for instance, checking out changes to two project files at the same time. Visual Studio will inform you that a project has changed outside the IDE and asks if you want to reload it. How nice! Until you realize that it only reloads one of the two projects, that is. Recycle time. Or how about the shitty way it handles references to other assemblies. Rather than treating the assigned path to a referenced assembly as the gospel, it treats it as a "hint." This can cause wierd and hard to debug problems when compiling on another programmer's machine (granted the incidents of this happening are relatively rare, but I've seen it bite people 4-5 times in the last few years alone--zero would be far more acceptable).

Another annoying point is that all folder management (moves, renames, etc.) have to be done from within the IDE. This requires a lot of point and click gymnastics in certain scenarios. No fun at all. And don't even get me started about C++ support. They really punted there (in 2003, anyway--supposedly they tried making it far better in 2005, but reports from my C++ collegues indicates that they ended up breaking things like intellisense entirely).

Taft

Re:Summary

[Breakfast Pants]

Ahh, indeed. The license doesn't look great unfortunately =(.

Re:Summary

[Anonymous Coward]

Too bad it's inaccurate....WinFX (the next .Net Framework)...

WinFX is NOT the next .NET Framework.

Re:Summary

[mrtrumbe]

Why you gotta be a hater?

Seriously, what do you have a against the people developing mono, anyway? Is this one of those "you aren't a real programmer unless you code in C++" attitudes? What's your beef, man?

Taft

Re:Summary

[Jugalator]

Yes, as far as I know, there are no plans to clone "WinFX" at this point for Vista compatibility.

WinFX is far from required for "Vista compatibility". Basically no applications will use WinFX when Vista is released, and I have to wonder how many Windows developers are actually ready to jump ship from unmanaged C++ to .NET and WinFX. The new WinFX development models with e.g. Windows Presentation Foundation and XAML for UI development, etc. are totally incompatible with current C++ applications. It feels like several years ahead at the very least.

As for the Windows.Forms namespace, it's well underway actually. In the November 2005 status report, word is:

Windows.Forms is the only piece that is holding us from officially renaming Mono to Mono 1.2, it is still missing a few features. Our plan is to complete the missing features by the end of this month and then move to bug fixing and testing open source our publicly accessible Windows.Forms applications. We are planning on spending three months on bug fixing at this point.

This hardly sounds too unattainable to me.

And before anyone asks, no, Windows Forms 2.0 support isn't required for "Vista compatibility" either.

Re:Summary

[BlueMud]

Accuracy? We don't need no stinkin' accuracy. This is the news. If you want accuracy, go to WP.

Re:Summary

[maxwell demon]

I thought real programmers use FORTRAN?

Re:Summary

[Anonymous Coward]

Given what Windows Presentation Framework is capable of, I suspect that a lot of people will jump on it fairly quickly. It is a huge departure from the current Win32 UI model, and that's a good thing. The adoption will likely be fastest among the small software shops and I bet we'll see a surge of absolutely nasty-looking skinned applications as any would-be graphics designer will try their hand at it.

That said, Mono in Fedora won't help. WPF is a lot more than a simple wrapper around Win32 UI, as WinForms is. A great deal of the core was written from scratch and is unmanaged code. Given the Mono people haven't even really figured out WinForms, I doubt they'll be able to get WPF anytime soon. However, given WPF abstracts completely from Win32 UI, it might be easier to port it to other platforms because of the removal from WndProc.

Re:Summary

[octopus72]

Is it technically impossible to have WinFX bindings (or some other new API for Vista) for C++ or it is just a policy by Microsoft not to have one (with purpose of forcing as many people as possible into .NET)?

Re:Summary

[Anonymous Coward]

Just curious but if they don't know how WinForms works how come they claim they're almost done with it?

Re:Summary

[JebusIsLord]

Well, first of all you have a terminology problem in the sense that Microsoft isn't forcing people off C++ and into .NET, but rather forcing people to use managed code. Managed C++ in the current .NET is pretty ugly, and very few people use it since C# is so much nicer. So i wouldn't be surprised at all to see MS drop managed C++ entirely.

The nice thing about .NET though is that you aren't stuck to any particular language though... if you or someone else wants to write .NET in Python or something, my guess is it will be perfectly doable. C++ too, if someone other than MS decides to carry that torch.

So in short, they're forcing you to .NET, but not off any particular language.

Re:Summary

[Anonymous Coward]

Regardng the summary:
I spot a trend in Slashdot summaries that really annoys me. I read this summary and think. . .Ok. Fedora Core 5 ships with Mono. What the F*!@ is Mono? The word Mono is used 6 times in the summary (apart from the article link) and not one of them is a hyperlink to the Mono project page or even a wikipedia ariticle on mono. Why does Slashdot do this? What happened to HYPERLINKS? Should I have to run to Google just to know what the hell the summary is talking about? Don't assume that everyone knows what these things are, since Open-source sofware has such a notorious habit of having entirely non-descriptive names. Links to Beagle and F-spot would be nice too since thier names don't give the reader a clue as to what they are either.

Re:Summary

[Anonymous Coward]

So i wouldn't be surprised at all to see MS drop managed C++ entirely.

Actually, MS is pushing C++/CLI for standardization. The .Net 2.0 Managed C++ is much less ugly than in .Net 1.x.

The nice thing about .NET though is that you aren't stuck to any particular language though...

Everyone touts this, and I agree that it's a seductive idea. However, I think few people consider the likely long-term ramifications, particularly in large applications built, augmented and maintained over long periods of time. Imagine some large organization having an internal CLR application which has accreted multiple modules in several .Net (or Mono) languages. Now imagine that Mr. VB.Net needs to track and correct a flaw in a module written by Mr. Perl.Net long after Mr. Perl.Net has left the company. Some will say that the modules written by Mr. Perl.Net would have been appropriately designed & documented so that any other CLR developer can understand & modify them regardless of programming language - but that doesn't happen on the planet most of us live on, especially with internal applications.

So in short, they're forcing you to .NET, but not off any particular language.

Agreed. MS gains the most as more developers move to a platform it "controls" - how much control is debatable, but I think no one is foolish enough to believe that MS's .Net push is in any way altruistic. However, the native Win32 C++ developers will be the hardest to convert, and that's why MS is investing effort in C++/CLI to entice them. Few native C++ programmers have any love for MFC, but also few seem willing to leave native Win32 for .Net drag-and-drop GUI capabilities. And for desktop/server applications, experienced C++ devs already know what native APIs to use for whatever they're working on - there's a perception that .Net has little to offer them when building these apps. That's a big hurdle for MS if they intend (regardless of their current public stance) to derive a crushing long-term strategic advantage from mass adoption of .Net.

T

Re:Summary

[JFitzsimmons]

It *is* perfectly doable.

http://www.ironpython.com/

Disclaimer: I've never actually tried it, yadda yadda.

Re:Summary

[confusion here]

Real programmers code in 80386.

Re:Summary

[Anonymous Coward]

Installing Debian over Fedora Core 4 right now. I was thinking about switching already as Fedora seems to be stagnating and including Mono in FC 5 is the last straw. Anything that's going to include and use Mono by default is something that I don't want to be a part of.

R.I.P. Fedora.

Re:Summary

[Mortlath]

And don't even get me started about C++ support. They really punted there (in 2003, anyway--supposedly they tried making it far better in 2005, but reports from my C++ collegues indicates that they ended up breaking things like intellisense entirely).

My experience with C++ development on Visual Studio .NET 2005 has been great. It seems to me that they have fixed a lot of C++ things that were broken in the 2003 version.

The intellisense seems to work about twice as well as in the older versions. Intellisense even works well with 3rd-party libraries now.

Re:Summary

[idlake]

Java provides a better level of portability than C#/CLR...I'd look there instead for a VM based runtime.

That's if portability is something you want. Gnome users don't want portability, they want high quality Gnome applications, and Mono supports that far better than Java.

Furthermore, you only get portability in Java if you run your code on different Sun-derived Java implementations; compatibility between Sun Java and open source Java implementation is far worse than compatibility between Microsoft C# and Mono.

Re:Summary

[Principal Skinner]

Unless, of course, you're in China.

Re:Summary

[Anonymous Coward]

Java is like C#, but without the useful features, like, I don't know, a method for copying a file. For fuck's sake. I know, it's simple to open one file as an output stream and another as an input stream and stream between the two, but it's a complete pain in ass, and results in a million developers writing their own little version. Not to mention simple fucking tasks like removing the read-only attribute for a file. Oh, you can set it, but you'd better not ever have to unset it.
Seems to me like the Sun devs are more concerned about making the language theorectically pure, rather than useful.

Re:Summary

[magisterx]

This definitely seems premature. Even if Mono is fully compliant, there are other things that make an operating system and many programs will rely on those other factors as well. Still, this should prove to be a step forward.

Re:Summary

[cloudmaster]

I'd just like to say thank you for not being one of those idiots who uses "seemlesly" when they mean "without a seam". Thanks.

Re:Summary

[szhao]

I think it isn't a matter of how likely, but rather is how complete is mono. Last time i used mono, about a year ago, after 2 days i gave up. Why might i give up on mono? UDPClient did not have a DataAvaliable property. GUYS this is basic, if i don't know how much data is avaliable, how am i going to use it. Plus, this is good news for microsoft, sell office to linux users and mac users. ~Shan

Re:Summary

[boots@work]

What is this "Google" you speak of? Why do you nerds have to use all these funny made-up words???!?!

Re:Summary

[Jugalator]

Something I have to wonder about though is how, with this huge flexibility they get, interfaces will be standardized. Maybe we'll get a "web in 1997" era with colorful flashy programs before it settles down a bit. :)

Now

[Anonymous Coward]

pigs will start flying ...

Maybe.

[torxic]

Maybe and hopefully linux apps can run on windows too.

Re:Maybe.

[ajs318]

They already can. You just need to tweak the source code a bit but they will run. Of course you could always get something like Cygwin, but why try to teach a cat to bark? Just install Linux {maybe on a dual boot} and have done with it.

Re:Maybe.

[bozho]

Something like this: http://www.cygwin.com/ ?
And there's a ports site, too: http://cygwinports.dotsrc.org/ KDE, Gnome, Xfce4 and many apps. Very nice :-)

Re:Maybe.

[lucm]

I think the word you look for is "port", not "tweak".

Also you suggest to install Linux in order to run Linux applications on Windows. This is a great, but I don't see where you fit Windows in this architecture...

Re:Maybe.

[bozho]

IMHO, dual boot is a pain. I prefer coLinux http://www.colinux.org/
And I think it runs on Linux, too :-)

The patent problems have not been addressed

[H4x0r Jim Duggan]

The strategy for dealing with patents is discussed on the Wikipedia article about Mono. It is not a well thought out strategy.

It's probably good that Mono exists, it may have uses in some situations. It may help people get out of .Net related lock-in, but in general it should not be built upon.

Re:The patent problems have not been addressed

[ajs318]

In Europe and in Britain, the law is quite clear: software patents are null and void. As long as development work is carried out in a software-patent-free environment, there should be no patent problems.

I seem to recall it being fair use to make a version of something covered by a patent as long as it is for your own use. So it might well be OK just to host the download servers outside the USA.

Of course the best strategy in the long term will be to elect representatives who oppose software patents, and get your stupid law changed.

Re:The patent problems have not been addressed

[Anonymous Coward]

"It's probably good that Mono exists,"

Huh?

Re:The patent problems have not been addressed

[Anonymous Coward]

And how do you know that these Microsoft patents on aspects of .NET, which may or may not even exist, will not be so broad as to cover aspects of similar programming projects like Parrot? Quite clearly, we should run away screaming from Ruby, too, because Microsoft might have a patent on something in there for all we know!

Re:The patent problems have not been addressed

[ranton]

It may help people get out of .Net related lock-in, but in general it should not be built upon.

What is this .Net related lock-in that you are speaking of? In my opinion .Net is one of the best things that Microsoft has ever done. Developing has never been as easy and feature rich as it is under the .Net platform. My development time since switching to .Net is on another level than it was before; I almost cannot imagine going back. .Net is one thing that Linux should definetly embrace, I havent found a problem or flaw with using the .Net framework yet (not including bugs, all software has bugs).

--

Re:The patent problems have not been addressed

[hey!]

Well, According to the article ASP.NET, ADO.NET and Windows Forms are the issue. There are free alternatives to all of these technologies (e.g. gnome-db, gtk#), and programmers concerned with portability should use them. Some would argue the alternatives are better.

Programmers who aren't concerned with portability should use whatever they like best, understanding that if they go MS then they might not be able to run.

The only suckers in this are people who use (or implement) MS proprietary APIs and assume they're going to be free. If you want a free API, use a free API.

I can also see a stragegy where design patterns wrap alternative proprietary and free components, like SWT and Hibernate in the Java world. While something like SWT wouldn't make much sense for app developers, it might be useful for developers of visual components. Hibernate is already available for Mono.

Re:The patent problems have not been addressed

[endoplasmicMessenger]

That could be said for any application framework, including Microsoft's. Have you noticed how many patent cases Microsoft has lost lately? Especially the Timeline case, which directly impacted developers.

With respect to patents, Mono is no less and no more dangerous to use than any other application development framework.

Re:The patent problems have not been addressed

[afabbro]

What is this .Net related lock-in that you are speaking of?

Hey, I'd like to develop a .Net program and run it on Solaris/AIX/Linux/etc. Oh, I can't? Gee, seems like I'm locked in to the Windows platform with .Net.

Compare and contrast with Java. Or open source code. Or a lot of closed-source code, for that matter. Just like Visual Basic, if you write in .Net, you're only writing for Windows.

Re:The patent problems have not been addressed

[MajinBlayze]

By far, I am not a Microsoft shill, but I enjoy programming in C#, and like the CLI.
Mono's main goal is an implementation of this: the ECMA CLI standard The windows.forms portion is there for compatibility with programs written for windows. (no different legally than WINE providing compatibility with win32 APIs)
It is suggested to develop using the GTK# toolkit, which is available for Mono or Windows.

IMHO, this is a step toward systems and applications that are OS-independent, making the "fight" between windows and Linux moot.

Re:The patent problems have not been addressed

[ranton]

Gee, seems like I'm locked in to the Windows platform with .Net.

But you do not have to develop for .Net on the Windows platform. You can program in Windows without .Net. If you are developing in .Net then it is for a reason; in my case it is because it is the best decision. For most people it is because they will be more productive, and really that is almost the only reason there is to pick a language/platform/methodology.

So if .Net is better than anything Linux has to offer, then you are only locked in to the Windows platform because it has the best tools. That isnt being "locked in", that is a choice.

--

Re:The patent problems have not been addressed

[MobyDisk]

The Wikipedia article is wrong. I think I'm going to update it unless someone can tell me why I'm wrong. It says:

Mono and Microsoft's Patents:
The problematic parts are not the core technologies submitted to the ECMA or the Unix/Gnome-specific parts. The problematic parts are technologies developed by Microsoft on top of the .NET Framework, such as ASP.NET, ADO.NET and Windows Forms.

I believe the above statement is false. The core technologies are patented. By submitting the core technologies to the ECMA, Microsoft agrees to "reasonable and non-discriminatory (RAND)" licensing. RAND does not mean free. That means that, worst case, Microsoft can charge you a per-copy license for using Mono. I consider that problematic, and I think most OSS developers would too.

Re:The patent problems have not been addressed

[drinkypoo]

I'm not doing .net yet but I am doing ASP (using jscript) and the problem is that nothing else is worth a crap on windows. Apache for windows has made great strides but I'm still hearing about performance and reliability issues. Granted, IIS is scary, but 5.1 seems to be pretty secure (as far as anyone can tell anyway) if you have all your patches. So, you end up stuck with ASP, which means you use ADO. And besides, where the hell else can I write in the same language for both the server and the web browser? ASP lets me use jscript for both, which means I don't have to think in two languages at once, I only have to think in two contexts (I'm not doing ACID yet.)

Re:The patent problems have not been addressed

[tenchiken]

That's the entire point. Mono removes that lock in. By the way, at a very basic level, Microsoft needs Mono. Their own open source effort around mono (ROTOR) failed. They need a competitor CIL/CLR to have creditability with large IT shops that could just as soon go to Java.

Re:The patent problems have not been addressed

[drinkypoo]

Hey, I'd like to develop a .Net program and run it on Solaris/AIX/Linux/etc. Oh, I can't? Gee, seems like I'm locked in to the Windows platform with .Net.

Did you miss the fact that we're currently discussing this in a thread about Mono, which lets you run .net/clr applications places other than Windows? The only problem [until WinFX] is that Windows.Forms support is currently incomplete and buggy. However, if you are writing the program, you don't have to use [much] Windows.Forms.

Re:The patent problems have not been addressed

[Anonymous Coward]

>>Gee, seems like I'm locked in to the Windows platform with .Net.

>But you do not have to develop for .Net on the Windows platform. You can program in Windows without .Net. If you are developing in .Net then it is for a reason; in my case it is because it is the best decision. For most people it is because they will be more productive, and really that is almost the only reason there is to pick a language/platform/methodology.

>So if .Net is better than anything Linux has to offer, then you are only locked in to the Windows platform because it has the best tools. That isnt being "locked in", that is a choice.

I am not the OP. You are redefining "locked in" to suit your argument, instead of using the standard def of the word. The CODE is certainly locked in -- you are just reframing the issue as a preference/choice, just like you could argue about converting Microsoft video formats to something else (with ASF, you can't).

The context is, is the code "your code" and will Microsoft prevent you from running "your code" whereever you want? Microsoft is not obligated to help you do so, but they should not GET IN THE WAY of porting their 'ECMA standard .net" libraries to other platforms.

In fact, several MS managers WANT mono to succeed. The mixed signals are so Microsoft can choose their cake: did Linux choose not to adopt .net because they "hate microsoft", or did Linux folk over-reach and "cancer" Microsoft's IP?

Libraries that claim to be portable, but the OEM interferes with porting, certainly is lock-in.

Re:The patent problems have not been addressed

[tolan-b]

I've not seen any evidence that the core is actually patented. Although it seems likely.

You might want to check that before altering the article.

Re:The patent problems have not been addressed

[Baki]

indeed, and since java offers all that .net offers, and more, I see no reason at all to use .net/mono.
just use java, it runs everywhere and is superior to .net

Re:The patent problems have not been addressed

[MobyDisk]

Good point. How would one go about determining that? Wouldn't Novell have already done this research? Patents aren't secret. Wouldn't they have had to submit those patents to the ECMA when they agreed to RAND? And why would they have have agreed to RAND on patents they don't have? I really wish I was sure about this stuff. Maybe it's time to email Miguel.

Re:The patent problems have not been addressed

[tolan-b]

Well I think you're right that if there were any obvious patents on it then Novell would probably be aware of them. Then I guess you're just left with the general software patents problem, meaning Mono is in no worse position than any other piece of software.

To be honest there's nothing in .Net that I've heard of that sounds particularly patentable. It's taken Java and the JVM, learnt some lessons about the implementation issues, and applied other well travelled language / VM ideas to address those issues.

There's nothing really new about .Net or C#, they're just a decent implementation of known techniques. In fact thinking about it, I'd have though Microsoft probably have more to fear patent-wise from Sun than Novell do from Microsoft.

Re:The patent problems have not been addressed

[Anonymous Coward]

How the hell did this get +5 Insightful?!?

You can develop .NET applications that run seamlessly on both Windows and Linux.

Re:The patent problems have not been addressed

[outofcoffee]

Hey, I'd like to use Evolution on Windows. Oh, I can't? Gee, seems like I'm locked in to the *nix platform... Please. Your characterisation of 'lock in' is woeful at best. "if you write in .Net, you're only writing for Windows" ..or anyone leveraging standardised ECMA directives. Or Mono. Or, shut up.

Re:The patent problems have not been addressed

[dcam]

You can run php on IIS. Both as a CGI or as an ISAPI. The ISAPI has the potential to perform better than the CGI option, but I'm not sure what the current progress on that is. A few years ago (last time I looked at it), the CGI was still the way to go.

Also there is a perl CGI module. I don't recommend perl to anyone as a means of building an application, but if you really like it...

Incidentally, if possible I'd strongly recommend moving to .Net if you are planning to build a serious application. Classic ASP just isn't built to handle larger applications (Althought it can be done). I'm speaking from hard experience (ie mistaked made) here.

Re:The patent problems have not been addressed

[jma05]

How naive! The whole point of Mono is that it offers so much beyond what Java offers (I have no interest in listing all the additional features. You can do a Google search yourself) and yes, Mono apps run everywhere (don't get confused with .NET and Visual Studio here. Develop with Mono/GTK# and you have just as much portability as with Java).

Re:The patent problems have not been addressed

[jbplou]

I think this is something most people don't seem to understand. The primary thing .NET is being used for is web apps ala ASP.NET and business apps. In both cases the people choosing to use .NET probably already have a Windows environment so the lock in issue is no big deal.

Re:The patent problems have not been addressed

[Anonymous Coward]

Hey, I'd like to develop a .Net program and run it on Solaris/AIX/Linux/etc. Oh, I can't? Gee, seems like I'm locked in to the Windows platform with .Net.
Compare and contrast with Java. Or open source code. Or a lot of closed-source code, for that matter. Just like Visual Basic, if you write in .Net, you're only writing for Windows.

Ok first, .Net is not a language. Second, Java IS a language. Third, Visual Basic is part of the .Net Framework. And finally, you posted this in the comment section following an article about how .Net functionality is coming to a major distro near you.

You need to get your shit straight before you haul off like that.

Re:The patent problems have not been addressed

[drinkypoo]

The website I'm currently developing does not need to scale very large or become very complex. If I muck with IIS in the future, it will certainly be ASP.NET. I think my real future plans are to work with mod_perl though (PHP pisses me off; why be so damned similar to perl yet not be perl? It would have made more sense to have PHP based around perl than Zend, for PHP's sake, though not Zend's of course.)

Re:The patent problems have not been addressed

[dcam]

Fair enough, it just worth being aware that you can run into scalability issues. Often things you don't expect to grow might do just that. FWIW ASP.Net isn't as good (IMO) as classic ASP for small projects.

Well, if you must work with perl ... The Active State binaries install a CGI module by default (it is an option during the install).

I do write some perl BTW, I just think it encourages people to write really, really illegible code.

If you do hit any issues with ASP, feel free to drop me a line (david [at] uberconcept.com). I used to pretty active on the wrox ASP and SQL Server mailing lists.

Simple question -- simple answer.

[Eivind]

No.

Re:Simple question -- simple answer.

[slavemowgli]

Indeed - especially considering that WINE and Mono are two very different beasts. WINE aims at binary compatibility with existing applications; Mono (from what *I* know, anyway) aims at source compatibility, which is a very different thing, and much easier to accomplish.

Re:Simple question -- simple answer.

[pe1rxq]

Not quite, Mono also includes a VM that interprets the .net bytecode, much like java.

Re:Simple question -- simple answer.

[Eivind]

Yeah, sure, it's something completely different from Wine. But my "no" was sorta based on something different, namely the idea that, as stated in the blurb:

This will mean that in future, all native Windows applications will easily run on Linux, with Mono. Will Mono achieve what WINE could not?"

Mono will certainly not ever come anywhere *close* to being able to run "all native Windows applications", there's like half a dozen independent reasons for that, ranging from your "it'd require a recompile in any case" trough unpleasant little facts like the fact that Mono is trying to chase a moving target that is willing to spend a lot of money and man-hours precicely to *avoid* that too much works with Mono.

In sum, they'll have all the problems of Wine, and then some. (the need for sourcecode f.ex)

Worse yet: the mono-developers are suggesting one migth want to develop OSS applications with a primary target being Free OSes under Mono. Doing so would be double hurtful: It'd ensure that any such application developed for Linux works perfectly under Windows (because mono is a *subset* of the MS-environment, AND because all OSS-applications come with source), but *not* the oposite.

It's a braindead waste of time. I don't see how I can put it more politely. It actively hurts the Free Software ecosystem.

Re:Simple question -- simple answer.

[jsight]

.Net aims for binary compatibility as well.

Re:Simple question -- simple answer.

[Breakfast Pants]

Well, mono still aims at "binary compatibility" but that isn't as hard as what wine is doing because it is with byte code and not machine code. Binary compatibility with byte code is basically effectively as easy as source compatibility. As an aside decompiling bytecode into source is much easier than decompiling machine code into source.

Re:Simple question -- simple answer.

[StrawberryFrog]

Doing so would be double hurtful: It'd ensure that any such application developed for Linux works perfectly under Windows

Why is this hurtful? I thought it had been firmly established that the availability of Free Open Source software on windows drives adoption of Open Source in two ways: it gets Windows users used to free, open source software; and when they move operating systems, their favorite apps like Firefox, Thunderbird, (and maybe even OpenOffice some day, and these c# programs) are still there.

Are you suggesting that Firefox on Win32 is a "hurtful, braindead waste of time"?

Re:Simple question -- simple answer.

[Anonymous Coward]

because mono is a *subset* of the MS-environment

Nope. They've got some libs and bindings (GTK springs to mind) That MS.NEt does not have.

Re:Simple question -- simple answer.

[StrawberryFrog]

Mono aims at source compatibility

I thought so too, but I've seen "hello world" compiled to bytecode, then run on Win32/net and Linux/mono, so there is bytecode compatibility.

Re:Simple question -- simple answer.

[space_dude_27]

Worse yet: the mono-developers are suggesting one migth want to develop OSS applications with a primary target being Free OSes under Mono. Doing so would be double hurtful: It'd ensure that any such application developed for Linux works perfectly under Windows (because mono is a *subset* of the MS-environment, AND because all OSS-applications come with source), but *not* the oposite.

I take your point here but I don't agree with your conclusion. I have to use Windows machines a lot at work and I have a Windows partition on my home computer. Open source apps like Firefox and Cygwin make my life a heck of a lot easier when I have to use Windows. Especially Cygwin (what does is say about Windows that my faviourite Windows app is one that makes it look just like UNIX.... ;-). Now, you can argue against the mere presence of these open source apps on Windows on the grounds that it increases the attractiveness of Windows. Maybe so. However, I argue that it's a good thing for two reasons:

As I said, it makes like easier when you *have* to use Windows from time to time.

It makes it easy to move from Windows to Linux (or other open source/free OS) because you don't have to learn a set of different apps. The number of people I know who use Firefox on Windows, for example, is growing rapidly and all of these people wouldn't have a problem using it on Linux either. Maybe one day, the same will be true of Mono apps too.

Re:Simple question -- simple answer.

[Burz]

and when they move operating systems,

To Mac OS X.

At least that has been the story so far. GNU/Linux simply isn't structured with most end users in mind (people who write/distribute apps and drivers independantly, and those who buy/download them independantly). It could be, through something like "LSB Desktop" spec, but that does not yet exist.

I think many desktop users who try "Linux" get the distinct impression that Linux enthusiasts don't care much for standards.

Re:Simple question -- simple answer.

[ninkendo84]

It's a braindead waste of time. I don't see how I can put it more politely. It actively hurts the Free Software ecosystem.

Except that it makes it easier for developers to create managable, maintainable software under Linux using a free, standards compliant (yes, it was submitted to ECMA and C# is a standard) open source, and familiar language.

As of right now, pretty much all the mono projects exist happily within the linux ecosystem and occasionally see windows ports. And yes, they're ports. In order to run mono apps in windows, you have to either recompile for .NET IL code, or actually install a mono runtime in windows. And even then, a lot of the code in the mono apps in linux use bindings to existing linux (C/C++) libraries such as GTK, gstreamer, etc... so porting those to windows would also involve porting the corresponding libraries.

I've used and programmed mono apps for a while, and I never once thought of it as a way to bridge a compatibility gap between linux and windows. It's just a kick-ass development environment for Linux. I'd want mono for Fedora simply so I can have Beagle, at the very least. If you'd stop trolling and actually look at it that way, you'd find that it is by no means a "brain-dead waste of time."

Re:Simple question -- simple answer.

[Doug Dante]

"It's a braindead waste of time. I don't see how I can put it more politely."

How about, "I disagree with the direction that Novell is taking its free software project, which they are spending their own time and money on, and giving away for free, but I won't insult their intelligence just because I don't agree with them".

I'm writing several applications for Linux using Mono. Yes, deployment is a pain, but the apps are designed for limited deployment. Mono is a great language, and the productivity gains are worth the extra effort.

Thank you Novell for supporting Mono and thank you Fedora for making my future deployments easier!

Re:Simple question -- simple answer.

[aztracker1]

Okay, there are several areas that .Net/Mono etc encompass. First, there is the core Common Language Runtime; this is what runs a given application. The CLR is well defined within the ECMA/ISO standards, as is most of (second) the core framework. Microsoft extends the core framework with ADO.Net (command data layer) Microsoft.* (VB Compatability objects and a few others), ASP.Net (web apps, and services) allong with SWF (Windows forms).

Mono already has the core framework, as well as compatability for most of the rest... Some areas are indeed incomplete, but not in a way that inhibits current apps. Mono also includes several DB adapters that aren't inside the MS distribution, in addition to GTK# (for gnome/gtk based app development, which can be relatively portable to windows and mac), there are also a few other goodies on the mono side (Posix library, etc).

You *can* develop a portable application under mono without touching any of MS's extensions, and it can still be portable. Which is imho a good thing. There are other libraries for QT (kde), audio, opengl etc, some of the projects around them are stagnant, but usable. Mono isn't just a subset of .Net, there are other areas it has that MS's framework doesn't include... By the same note, you could say similar things to C++ development, if doing GUI development. You don't get the MS libraries for windows development in GCC, but you can still create GUI apps that are portable.

Mono is an implimentation of a standard, with some compatability to proprietary extensions, and including some extensions (F/OSS) of their own. In addition to many 3rd party libraries. For rapid app dev (RAD), it's really a second to none thing. You get a complete framework, bytecode portability both of these other frameworks offer. In addition to a key element, *MUCH* easier interaction with system libraries not part of the core framework. This is the kicker here, you can target system APIs *VERY* readily, making core functionality easier to do, than other managed environments.

I am no big fan of MS by any means, but to be honest, regarding patent litigation, they haven't shut WINE down, which is *FAR* more infringing than anything mono is doing, not to mention that under litigation they could strip the infringing parts and still have core functionality in place. There's a lot of prior art for anything ASP.Net does, how ADO.Net interacts, and the current winforms are dying (as far as ms marketting is concerned in favor of WinFX). Mono has been around for several years now, with no litigation in sight.

Re:Simple question -- simple answer.

[carlislematthew]

Linux enthusiasts don't care much for standards

Wrong. Linux enthusiasts LOVE standards - lots and lots of them! And if (when) they don't find a standard that fits their own requirements, they'll happily make a new one to compete, thereby adding to the glorious beauty of standards: that there are so many to choose from.

Re:Simple question -- simple answer.

[aztracker1]

Mono is available for MAC OSX as well...

Re:Simple question -- simple answer.

[Anonymous Coward]

It shouldn't even require a recompile. the Mono CLR runtime will run distributed CLR bytecode without needing the original source code. Like Java, the idea is OS-independant bytecode, OS specific runtimes. Any .net compiled file is that OS independant bytecode.

[i]It's a braindead waste of time. I don't see how I can put it more politely. It actively hurts the Free Software ecosystem.[/i]

Technologicly its identical to Java, just with a possibly more popular source code syntax. I don't recall Java hurting the open source ecosystem....

Re:Simple question -- simple answer.

[StrawberryFrog]

Mac OS X maybe - but both Fireox/Mozilla/Thunderbird and Mono run on OS X.

Re:Simple question -- simple answer.

[C10H14N2]

...and for some god-unknown reason, SuSE have already tacked-on Mono dependencies all over the place in SuSE 10 roughly the same bloated footprint as XP for even the most minimal install. Sure, I was able to hunt down the offending bits, but geezuz.

Re:Simple question -- simple answer.

[Anonymous Coward]

What do you expect? Its a novell product. Both mono and suse are. Hell, its a linux distro.. if you want small go with gentoo. The linux philosophy is about choice... and that means 10 text editors and 4 browsers per install. Linux installs are BIGGER than Windows XP typically. Why? Apps. KDE and Gnome are big. I'm downloading redhat el ws 4 right now. Its 4 cds. XP is 1 cd. I'm tired of linux people complaining about bloat when they download 4 cds or 1 DVD to install redhat, fedora core, suse, mandrake etc. Now if i add the compiler, word processor, 10 text editors and the like windows becomes as big as linux. Apple systems are in the same boat.. its 4gb to install mac os 10.4 now. My disk image at work is 5.5gb for macs. Aside from gentoo, only bsd based systems are limited to 1 or 2 cds now. Its the way of the world.

Re:Simple question -- simple answer.

[IamTheRealMike]

Not exactly. The reason Wine is hard and Mono is less hard, is because there's a metric ton of Win32 apps out there that people want to use and not very many .NET apps. Binary compatibility is HARD no matter what platform you use, and with Wine the result of not having it is very visible, your apps crash. With Mono it's not so visible because I'd bet 99% of the people who've used Mono have used it with apps built for it specifically - not for running Windows .NET apps.

In fact, in the past I have tried running libraries and programs designed for Windows .NET on Mono, and they have failed every single time. Last time around I wrote a patch to fill in a missing piece actually.

I can guarantee, if there were actually apps or games out there written in pure .NET that people cared about, you'd see Mono having the same problems. Hell, they have the same problems anyway, I've seen more than one developer bitch about how they upgraded Mono or the toolchain and their app broke, usually due to lousy backwards compatibility and QA on the part of the Mono team! And that's compatibility with itself!

Re:Simple question -- simple answer.

[rrohbeck]

But would this be a viable model for commercial software?

Re:Simple question -- simple answer.

[Burz]

But that's just being shifty and fickle when it comes to standards. GNUists berate MS for not following the standard-du-jour. But now MS is playing that game too, turning it around on us. The former uses a few standards to needle MS, but they'll lose because MS is now using standards like chess pieces.

Throwing dozens of technical standards in users' faces and expecting them to make sense of it won't get desktop distros very far. They cannot continue to insist that their distros be structured for the enthusiast and expect to succeed in the wider market. They cannot continue to aim for the end-user but deliver enthusiast goods.

Bundle all the necessary little standards under a broader single standard like 'LSB Desktop', including ABIs, while drawing a sharp distinction between what is always supplied with the OS and what are extra services and apps. Most of latter stuff should come packaged with only one dependency 'LSB Desktop 1.0' and each package has to supply all other needs in a self-contained manner.

Enthusiasts and sysadmins wouldn't have the "freedom" to label just any mash-up of packages as "LSB Desktop". But other than that they can keep doing whatever they please with "Linux".

Like standards? Prove it: Create one that end-users can appreciate and count on.

Re:Simple question -- simple answer.

[carlislematthew]

I'm not sure if you knew I was kidding or not. Anyway, I *was* kidding, hence the old and well known joke regarding "the great thing about standards is that they are so many to choose from".

Re:Simple question -- simple answer.

[Burz]

Mac OS X maybe - but both Fireox/Mozilla/Thunderbird and Mono run on OS X.

OS X definately. Its been that way for years now: People are going to OS X instead of Linux, or they are moving away from Linux for their desktop//notbook needs.

Certainly the Mozilla and OpenOffice stuff will meet great success. They are end-user focused, with well-rounded (dare I say "commercial"?) programming methodologies in their work cultures.

How many GNU/Linux distros profile the behavior of their customers in use-case documents? Mindfully map-out user roles and prioritize the tasks they need/want to perform with the product? I'd say none of the desktop distros do this, because it immediately leads to analysis that highlight core distro features as inappropriate. "Download and Install Application from ISV." Is the answer to that essential use-case to create a monstrous, monolithic, centralized software database with myriad 'floating' APIs that most ISVs can't even begin to rely on? How about making the user cope with dependency problems?

Even most techies don't want to deal with that crap.

And as a result, most techies don't recommend Linux to their friends, family and colleagues. Application developers, never knowing just what toolset they can count on being in a *nix system, still mainly stick to the MS and Apple platforms.

Re:Simple question -- simple answer.

[Burz]

But funny (and wrong) as it is, that really seems to be the attutide around Linux desktops. Mash up a bunch of narrowly-defined standards and 1,000 different combinations, and let the end-users choose between those collections of standards.

End-users won't respond to a shell-game of SMB-ADC-PDC-USB1.0-USB1.1-USB2.0-FAT-VFAT-EXT2-EXT 3-DCOP-DBUS-sh-csh-bash-802.11a-802.11b-802.11g-ND IS-etc-etc...

End-users (and most techies) are application-oriented and always begin by specifying an application platform: Mac OS and Windows.

"Linux" doesn't exist in this application decision-space, except as a mirage to certain technorati.

Re:Simple question -- simple answer.

[Eivind]

First, I don't think it has been anywhere near "firmly established". Secondly, neither OpenOffice, nor Thunderbird or Firefox is built ontop of technology that is controlled by Microsoft.

Yes, I know, Microsoft doesn't directly control Mono. But they *do* set the de-facto standard for .net and C#.

I simply don't think it's a good strategic choise when you are in a competition to voluntarily choose to build your solution ontop of a platform controled by your main competitor. A competitor that is convicted of abusing it's monopoly-position.

Re:Simple question -- simple answer.

[Eivind]

Yes. There are benefits to having Free Software work on windows. But here it was a step or two sharper than that again: With a mono-developed Free Software program you end up having a program that works on Windows, ontop of a platform that is de-facto controlled by Microsoft, and for which the Free OSes have only a subset available.

It'd be, for example, trivial to extend such an app using some part that is not available under Mono so that the original Free Software, Mono application is, in its improved form, only usable under Windows .net

In essence this is the BSD vs GPL-licence discussion all over. Developing under mono allows anyone who wish so to fork the app, and make the fork Windows-only. This is true even if the app is under the GPL. Because the app itself is freely distributable, and delivered with source as per the GPL-demand. However that source doesn't help you any -- because you lack the nessecary facilities under Linux.

I personally don't like the idea that software I write suddenly ends up being Windows-only. So for that reason alone I'd never even consider writing to a platform where all we have is a *subset*.

Re:Simple question -- simple answer.

[Eivind]

Except that it makes it easier for developers to create managable, maintainable software under Linux using a free, standards compliant (yes, it was submitted to ECMA and C# is a standard) open source, and familiar language.

So, you're saying, the benefits of the language itself outweighs the drawbacks ?

I don't see what makes C# enormously much better than all other languages. If anything, it seems very much like a "me too" language with lots of its feature-set borrowed from Java.

Myself I don't like statically typed languages for most jobs anyway, so I tend to prefer Ruby or Python.

Re:Simple question -- simple answer.

[StrawberryFrog]

First, I don't think it has been anywhere near "firmly established"

It's been discussed on Slashdot, and the opinion is mostly in favour and the reasons robust. So if you can't trust what you read on Slashdot, what can you trust? ;)

I think it is somewhere near firmly established that good open source apps on windows drive adoption of the broader open-source platform rather than diluting it, for the two reasons given.

Other Linky here.

Re:Simple question -- simple answer.

[shutdown -p now]

ranging from your "it'd require a recompile in any case"

Except that it doesn't, because Mono has a bytecode JIT compiler, just like JRE. The same CLR .exe will run happily on any supported platform as long as all the libraries it references are available.

Worse yet: the mono-developers are suggesting one migth want to develop OSS applications with a primary target being Free OSes under Mono. Doing so would be double hurtful: It'd ensure that any such application developed for Linux works perfectly under Windows (because mono is a *subset* of the MS-environment, AND because all OSS-applications come with source)

Mono isn't a subset of .NET - much like the latter, it includes a few vendor-specific extensions, such as Mono.Posix namespace. Then there's Gtk#, which, while it is available for Windows (just like Gtk+ itself is), is not exactly a good UI library on that platform (unstable + L&F issues). All in all, a Mono/Gtk# application is not any better off than a GLib/Gtk+ application when it comes to running it on Windows, except that a Mono application will not need a recompile.

It actively hurts the Free Software ecosystem.

No, it only does, at worst, hurt the "crusade" against Microsoft, which some people for whatever reason believe is somehow relevant to F/OSS (which it isn't).

Re:Simple question -- simple answer.

[boots@work]

A more reasonable comparison is to the 10+ DVDs in the MSDN toolkit, since typical distros comes with compilers for a bunch of languages, some documentation, editors, debuggers, web server, and on and on.

Aside from gentoo, only bsd based systems are limited to 1 or 2 cds now.

Ubuntu comes on one CD. Doubtless you could find a dozen more on distrowatch.

Aha!

[Anonymous Coward]

So Fedora Core 5 will be shipping with a virus!

Re:Aha!

[QuantaStarFire]

It's the kissing disease, you know. Our little OS is growing up! :)

Re:Aha!

[Crayon Kid]

I don't see what the big deal is. Debian has had Mono and Beagle in unstable for quite some time. As official packages, not third party packages from obscure repositories.

I think this is good.

[TehBeer]

I noticed when I switched from FC3 to FC4 that dag didn't have mono anymore, and so I was forced to configure nrpms.net in my yum config.

It was really getting to be a pain to search around and FIND the "new" mono repo for Fedora.

I have 3 FC distros installed and 2 SuSE10 and I was just about ready to switch to SuSE for good on FC5 if stuff like mono and yumex didn't make it into the distro. I can only hope they include yumex this time around.

At any rate, I wrote about my new mono book in a recent blog entry with a nice pic of my mandrake stuffed penguin.

http://www.sitespaces.net/blog.php?viewblog&2322

Great news!

[Anonymous Coward]

I don't really care about windows programs running on linux, though this is of course an interesting subject.

What's more important is that the stupid infighting about what role mono could play in Gnome can now finally end.
Mono seems to offer something that many people like and can now finally simply be used to build great programs for Gnome (just like pythong, jave, etc.), without being preoccupied with Fedora and thus a large Gnome distribution not shipping mono.

Re:Great news!

[Anonymous Coward]

Everyone ships Python.

Heh.

[SatanicPuppy]

First time the "Kissing Disease" has ever been accessable to geeks.

One the one hand, I'm all in favor of open source alternatives, and it adds a lot to linux to be able to run .Net apps, but I can't help but think we'd be better off with another language. .Net is so freaking encumbered.

Still, it'd be nice to be able to host .Net apps on Linux servers...

Re:Heh.

[Anonymous Coward]

One the one hand, I'm all in favor of open source alternatives, and it adds a lot to linux to be able to run .Net apps, but I can't help but think we'd be better off with another language.

Well. If it was about running this or that app despite it being written in .NET, that would be all fine and dandy, but new and useful Unix/Linux apps are being written in C# as well. Take the desktop search Beagle for example, or the music player Muine. Some people just seem to like the language and the libraries.

Re:Heh.

[Hosiah]

linux to be able to run .Net apps,

Hey...wait a minute. Do you mean Net apps like in "Visual Basic Script-Kiddies EZ Virus Kit"? Maybe this isn't something to dance in the streets about after all...

Re:Heh.

[drinkypoo]

Maybe someday, but not until Windows.Forms is fully emulated/implemented. The IDE-built apps made with Windows will probably all have pretty serious Windows.Forms code.

Re:Heh.

[hobbit126]

Since ActiveScripting is implemented as a COM DLL, has nothing to do with .NET, probably not. You'd have to have full (Microsoft) COM support on linux, both the ActiveScripting DLL and the VBScript dll, all of their related dependencies (OLE32 etc.) and then you'd need the mono stack. And then...even to get ActiveScripting working on .NET for windows, you can either use the rather limited "ScriptControl" object, or you need to write a wrapper to expose all of this as a standard ActiveX COM object and then write a marshaling layer in order to access it through .NET. You'd have an easier time writing an application in C that used ActiveScripting (assuming of course that you had this imaginary win32 COM implementation for linux.)

Re:Heh.

[Anonymous Coward]

Christ. VBScript and Visual Basic are two different animals, and nobody writes viruses using the .Net framework.

Re:Heh.

[Hard_Code]

.NET/CLR comes with a pretty comprehensive security model that should essentially deter those types of things. Actually I've never heard of a "Visual Basic" virus kit. Usually even virus kit writers have more respect for themselves than to use VB.

Will all applications be rewritten?

[mwvdlee]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.
Will all major Windows applications be rewritten to .NET?
I just can't imagine Adobe, Autodesk, Corel, etc. translating their code to .NET in the near future.

Re:Will all applications be rewritten?

[anarxia]

All applications.. no chance. Some of them might.

The problem is that MS (intentionally or not) left a lot of functionality out of the .NET standard libraries _AND_ made it almost trivial to call native code from within .NET.
The end result is that most applications end up using Win32 DLLs directly so wine is still necessary.

Re:Will all applications be rewritten?

[compass46]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.

No it doesn't. There are still Windows classes that are additions to the .NET standard which are available for Windows and not for Mono. What about future classes tied directly to Vista and those features of it patented?

Re:Will all applications be rewritten?

[Anonymous Coward]

The reason that they are not easily run is because the Mono windows.forms implementation is not complete and immature. You can quite happily build apps using GTK# and have it running on .NET (with the GTK# runtime).

ASP.NET on the other hand is mostly implemented (except for noticeable exclusions like Directory Services) and it is quite trivial to run on Mono

Re:Will all applications be rewritten?

[vdboor]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.
Will all major Windows applications be rewritten to .NET?
I just can't imagine Adobe, Autodesk, Corel, etc. translating their code to .NET in the near future.

Don't expect a easy transition. Mono can only implement the core stuff, because things like WinFX and WinForms are covered with patents. They've implemented their own gui toolkit instaead (Gtk#). IIRC they made the migration path from WinForms to Gtk# relatively easy.

Other options to write nice cross-platform tools are:

• Qt from Trolltech. They offer a great class library like .Net and Java do.
• The upcoming KDE4 libs/framework classes will also support Windows.

Although the average slashdot uses rants about KDE/QT, they shouldn't be underestimated. Trolltech has some enthousiastic customers and the Windows-port for the kde4-libs raised some eyebrows of commercial parties too. :-)

Re:Will all applications be rewritten?

[ergo98]

The problem is that MS (intentionally or not) left a lot of functionality out of the .NET standard libraries _AND_ made it almost trivial to call native code from within .NET.

The .NET Framework is enormously comprehensive, and with additional free libraries you can do just about everything without ever knowingly touching "native" code (though of course most of the Framework is just a think veneer over native code, which was the optimal way of implementing it).

Nonetheless, it was created as a development platform for Windows, and that includes the ability to call native code where it's the best option (just yesterday I hooked HTML Tidy into a .NET project, easily using the Tidy DLL library to process some HTML streams).

The submission is flipping ridiculous - Not only is it completely ignorant of WinFX, but it's ridiculously optimistic about cross-platform capabilities, when the existing Mono framework is woefully incomplete for porting even basic WinForms apps.

Re:Will all applications be rewritten?

[DogDude]

The problem is that MS (intentionally or not) left a lot of functionality out of the .NET standard libraries _AND_ made it almost trivial to call native code from within .NET.

How exactly, is this a bad thing? MS makes it incredibly easy for people to develop software for their platform, and that's a *bad* thing? The whole Steve Baller screaming "developers" makes perfect sense.

Re:Will all applications be rewritten?

[Anonymous Coward]

DogShit, you lazy fuck...

The whole Steve Baller screaming "developers" makes perfect sense.

Your trolling's not what it was. You're not even trying to be subtle. You were more convincing talking about how your gerbil store runs Microsoft. That at least made sense; you being a Ballmer apologist is too sycophantic even for you.

Stick with the party line of your little doggie store being so important that only the mighty MS is good enough for it.

Twat.

Easily run

[DrXym]

Someone has obviously never tried running a .NET application under Mono. More often than not, it calls Win32 via PInvoke, uses an ActiveX control / COM interop, or does something else which renders it unusable on other platforms. Some apps might work, particularly command line tools, but it is by no means guaranteed or even probable.

And this is probably what MS had in mind all along. And I don't see it changing either. Microsoft make it easy to slap together apps with their stack and tools. Mono makes it hard to do the same with theirs. That means Mono will constantly be playing catch-up with Microsoft, reaching for but never getting close to 100% compatibility.

Re:Easily run

[Giometrix]

I've never done more with mono that the simple "Hello World" app. Does Mono have an equivilent (or near equivilent) of Windows Forms?

Re:Easily run

[PyroPunk]

You can use GTK# along with Glade to create GUI applications.

Re:Easily run

[Shulai]

That of course is neither the same thing or a compatible replacement for Windows Forms.

Sincerely, the last thing Miguel did I liked is Midnight Commander.

Re:Easily run

[Anonymous Coward]

Have you taken a look at the Mono framework? It provides a ton of extra libraries, such as Gtk# (which works very well), Gecko (which makes it very easy to create a simple web browser), Windows.Forms support, and LDAP controls. Also, C# 2.0 compatibility is almost complete. So yes, Mono will be playing catch-up for a little while, but I think the trend of Linux developers moving to Mono will continue. It's a stable and very usable platform. And now that it's standard on Fedora, more people will be exposed to it.

Most .NET developers are on Windows, so why are you surprised that they use Windows libraries? When there's more demand for cross-platform .NET applications, there will be more cross-platform .NET applications.

Re:Easily run

[adolfojp]

There is a WinForms compatibility layer in the making. Its first release will handle the WinForms of the 1.1 .net specification. Mono will be forced to play catching up with this GUI framework and it uses the compatibility stack instead of the ECMA compliant one.

If you want to make Linux applications using Mono I strongly recommend using GTK#. Beagle and F-Spot use GTK#.

Cheers,
Adolfo

Re:Easily run

[jonwil]

And that is where WINE comes in.
The people behind Mono and the WINE people should work together so that Mono will use WINE for any PInvoke (either standard win32 APIs or something custom that comes with the .NET app) and hence the WINE implementation of COM & OLE for any ActiveX controls or COM interop.
If the item being used (e.g. the API call being PInvoked) is a standard windows item, then the .NET app will run on any system that has a usable port of WINE and Mono on it. If it is a non standard item for which source code is available, again, it could be ported and run via WINE or WineLib somehow. (or if its closed source but documented, it could be cloned somehow)
Even if the item being used is a closed source propriatory item for which there is no possible clone or use on non x86 platforms, Mono with WINE could still be used to run the whole thing on x86 linux

The question is whether the WINE people are prepared to do what is necessary to allow Mono to use WINE for the bits it needs (including PInvoke, COM and the talked-about implementation of System.Windows.Forms which has to go on top of something looking like user32 so that all the support is there)

Re:Easily run

[CaptnMArk]

Long-term WINE is a kludge. So is MONO using Wine. Even Mono using Wine implementation of Windows.Forms.

Kludge. Kludge. Kludge.

Either implement Windows.Forms in C# native (on top of X protocol) or just use GTK# (1000% better choice)

(if Mono is actually used by FC5 or GNOME, I'm ditching them now).

Re:Easily run

[Xugumad]

Odd, I'd always more looked Mono for being useful when your boss tells you that you have to write something using .Net, and you really want to use Linux...

Re:Easily run

[Jugalator]

If you want to make Linux applications using Mono I strongly recommend using GTK#. Beagle and F-Spot use GTK#.

Yes, if you're mainly developing on Linux that's a good choice, and don't forget that there's a GTK# port for Windows and OS X too. It's not much harder than to supply that framework with the apps you ship, and you'll have a currently more "stable" framework than Windows Forms.

Re:Easily run

[petermgreen]

Either implement Windows.Forms in C# native
probablly a bad idea. if you base it on wine then you can correctly simulate its interactions with .nets native interface (which you would also point at wine).

Re:Easily run

[Giometrix]

Is there a stability issue w/ Windows Forms? I've never experienced any. Thanks for the info tho, I'd love to use my .NET experience on Linux (and have a pretty GUI too...).

Re:Easily run

[Anonymous Coward]

More often than not , it calls Win32 via PInvoke, uses an ActiveX control .... by no means probable.

What sample size you you base this statistically robust conclusion upon?

Re:Easily run

[Anonymous Coward]

And that wasn't innovation either, MC is a clone of good old Norton Commander.

Re:Easily run

[Anonymous Coward]

There are some patches to Mono that allows it to do COM Interop on Windows. It has not been committed to their repository yet. These patches do work, but they need some more implementation.

Visual MainWin or something like that from Mainsoft has an implementation of COM on Unix. So, in the future, this could be supported.

As for Wine and Mono, they are not a good combination because threading issues between the two.

System.Drawing in Mono uses a home-made libgdiplus which works like gdiplus on windows.

Re:Easily run

[electroniceric]

Has anyone considered the notion that Mono should be implemented because a Common Language Runtime is actually a good idea?

Microsoft put a lot of effort into .NET for a single reason - to get managed language support deep into their OS without supporting Java. Even a cursory learning of C# (what I've done) leaves no doubt that it is the marriage of Java with Microsoft's UI API talents. And I'd guess that while their non-support of Java does include a big lock-in component (after all, how hard would it have been to fix their JVM and add the features they wanted in C#?), it also is emblematic of the not-built-here mentality that's so aggravating.

I think Mono's best bet is not to chase .NET compatibility, but rather to take a page from Microsoft's playbook - emulate and learn from Microsoft's skill at designing a UI API, and then use it to provide broad managed language support - including good Java support. Sort of like marrying Java and .NET again, but making it easy to port from any major Unix toolkit: GTK, QT, Motif (uughgh), TCL, and especially web-friendly languages. Basically make it what Java should be UI-wise. For example, the DataSet support for client-side data operations that can be flushed back to the server via a set of transformations is a great idea. Implement stuff like that.

Mono will never run as quickly on Windows as .NET. Frankly it will likely never be as peformant as .NET even on *nix - Microsoft spends a lot money and a lot of talent on optimization, but hardware can cover for merely adequate performance of the library.

Re:Easily run

[adolfojp]

Windows Forms are not bad, but they could be a lot better. Microsoft realized this and is introducing XAML as a replacement, and I am eagerly awaiting its arrival.

WinForms don't provide an elegant method for separating the View from the Controller. WebForms achieve this by having an aspx markup page that links to a cs or vb controller page. GTK does this by linking a glade XML file to a code file. In this sense, GTK is superior to WinForms.

XAML solves the issue of code and design separation using the same approach that WebForm and GTK use.

Cheers,
Adolfo

Re:Easily run

[pthisis]

Has anyone considered the notion that Mono should be implemented because a Common Language Runtime is actually a good idea?

That's probably true, but approaches like PyPy and Parrot are probably going to be vastly superior in terms of both flexibility and performance (I'd bet on PyPy if I had to pick one right now--of course it only runs Python, Javascript, and a couple other languages at the moment, but it's got smart developers, serious European Union funding, and a design that lends itself easily to implementing other language front ends, and performance is improving at an incredible rate).

Re:Easily run

[damiam]

That means Mono will constantly be playing catch-up with Microsoft, reaching for but never getting close to 100% compatibility.

That's not the point. Mono wasn't created for Windows compatibility; it was created to provide a fast, simple dev environment for GNOME. And it's been quite successful at that. There are a lot of useful Mono/GNOME apps now that wouldn't be nearly as far along had they been written in C.

Re:Easily run

[OpenServe]

Sort of like marrying Java and .NET again, but making it easy to port from any major Unix toolkit: GTK, QT, Motif (uughgh), TCL, and especially web-friendly languages.

Well put. I'm glad somebody brought this up. I believe it is imperative that the Open Source world begin to refactor into managed languages -- whether through Mono/CLR, an enhanced JVM with multi-language support, or something completely original (PyPy, etc.). It's this simple: We need to create a more cohesive "platform" for our developers and the best way to start is a unified object model. Imagine if Python, PHP, Smalltalk, and Ruby developers could efficiently re-use the wealth of professional-quality Open Source Java software that now exists. Imagine if Mozilla XPCOM could safely hook into standard "desktop" components to access local hardware. Imagine if Qt and GTK apps were no longer separated by the DCOM vs. CORBA disparity. (and hey, maybe we can someday agree on a single DE project instead of having both KDE and GNOME)

Java is a single language that runs on any platform
.NET is a single platform that runs any language

What OSS really needs is a meta-platform that standardizes support for any language on any platform.

Re:Easily run

[electroniceric]

Wow, this is a very succinct statement of one of the points I was struggling to make. I observe this non-componentization every time I used KDE - there are 5 or more programs shipped with KDE (on Suse 10) for viewing/editing images, and none make use of the same components. I'm all for variety, but that's ridiculous, and it's indicative of the fact that dropping in a library is still too hard. I also agree very strongly with your point on Java. Since Java is de facto the language of enterprise, code that comes out of such projects tends to be well designed and audited. Making it readily available for use in other software would a huge win.

All that said, I don't really agree that KDE vs. GNOME is a bad thing. I'm all for people putting together their own DE's as they please, as long as all the elements can play nice together.

Re:Easily run

[jonwil]

The question is why you want Mono.

If you want Mono so you can run windows based .NET applications on a UNIX box, you need System.Windows.Forms. And you need the implementation of Systems.Windows.Forms to have an underlying native win32 api implementation so that when a .NET application uses PInvoke to call a user32.dll function on a "managed" System.Windows.Forms window (I dont know if you can get the HWND of a System.Windows.Forms window or not), things will function correctly.

If you want Mono because the idea of programming in C# or programming to the common language runtime is a good thing and you dont care about running windows based .NET applications, you can get away just fine with GTK# or something similar.

Re:Easily run

[Anonymous Coward]

WinForms don't provide an elegant method for separating the View from the Controller. WebForms achieve this by having an aspx markup page that links to a cs or vb controller page. GTK does this by linking a glade XML file to a code file. In this sense, GTK is superior to WinForms.

Not really true. What Glade does is separate out the *layout* of the view, removing the requirement to write code to create widgets and arrange them into a screen. It doesn't do anything to separate view elements from the rest of the code - it's still necessary to write code that knows about the widgets, e.g to write rules that say "when field A is blank, disable button B".

Re:Easily run

[typical]

Well put. I'm glad somebody brought this up. I believe it is imperative that the Open Source world begin to refactor into managed languages -- whether through Mono/CLR, an enhanced JVM with multi-language support, or something completely original (PyPy, etc.).

I have discovered that a general rule of thumb for determining the quality of an open source software package is that the newer the language of implementation, the worse the software. Almost all of the really reliable, high-performance Unix software is written in C. Go to C++, things get less good. Go to perl...and I don't think I've ever used a piece of Java software that wasn't buggy.

Mono and python

[amightywind]

As a Gentoo user I wouldn't expect any package to be summarily left out. What I worry about is for packages such like Mono to become deeply embedded in distributions and create lots of dependencies, like Python. Python is increasingly a boil on the butt of GNU/Linux systems. Mono could go the same way.

Re:Mono and python

[m50d]

How is it a boil? It's a great language, very useful, makes the base system smaller overall (because so many things can be made much smaller in python) and is nice to be able to depend on it being available. Slating distributions for depending on python is like criticising them for depending on libc.

Re:Mono and python

[SassyDave]

Slating distributions for depending on python is like criticising them for depending on libc.

Distributions depend on libc because they have to.

Distributions depend on Python because they want to.

Proof by analogy is logical fallacy.

I like Python too, but with Perl, Python, and all the shells that distros come with these days, it's no wonder Fedora comes on 4 CDs.

Re:Mono and python

[metamatic]

I'd rather see things written in Python than written as shell scripts--and I hate Python.

Re:Mono and python

[oringo]

First of all, I disagree with you on that Python is a boil on the butt. It's neat and clean with the base distribution. I run python applications on my 266MHz ARM-based network appliance (with 32MB RAM) everyday.
Secondly, I don't see how MONO could be used the same way as Python. Like WINE, MONO is not gonna be used to be used to build core system utils, it's meant to give you better portability only. Building any open system with heavy dependency on a closed technology is like building on a timed bomb.

Re:Mono and python

[oringo]

Good point with the analogy, but the reason why Fedora comes on 4 CDs is not because perl/python/*sh. It's the higher level user applications and graphics libraries such as qt, gtk+, KDE, gnome, openoffice, mozilla, etc.
There are plenty of distros that come packaged with perl/python/*sh but fit on 1 CD, such as ubuntu.

Re:Mono and python

[m50d]

Distributions depend on libc because they have to.

No they don't. They could write everything in assembler and just use the kernel calls. They depend on libc because it's easier to write programs in C and use the library - the exact same reason they depend on python.

Re:Mono and python

[Qbertino]

Hehe. Nice troll. Judging from the +5 insightfull and the protesting posts I'd even say people have bitten. :-)

(For the uninformed: Gentoo Ports system - really what Gentoo is all about - is written in Python)

Re:Mono and python

[sgtrock]

As a Gentoo user

...

Python is increasingly a boil on the butt of GNU/Linux systems

A Gentoo user complaining about Python????????????????

(blink)(shakes head in confusion)

Umm, do you know what language all the tools that make Gentoo Gentoo are written in? I'll give you a couple clues. It's not Perl, C, or ruby. :D

Re:Mono and python

[vdboor]

Did you know all ebuild scripts are written in Bash? You mention Gentoo as Python enabled but it actually has to read through tons of shell scripts to index the portage tree (after emerge sync). Tools like "qpkg -l" are slow compared to a "rpm -ql" command.

Re:Mono and python

[amightywind]

You stated precisely what I wanted to say. I'd mod you up, but I haven't gotten mod points in years.

Re:Mono and python

[SassyDave]

They could write everything in assembler and just use the kernel calls.

You mean to say that you believe distributions like Fedora write all the applications they include? In most cases, they don't (except for things like the redhat-config-* family of apps). Linux distributors don't have a choice about including libc unless they want to rewrite ls and every other application written in C. Take ls for example:

$ ldd `which ls`
libacl.so.1 => /lib/libacl.so.1 (0xb75d4000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb75d0000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7499000)
libattr.so.1 => /lib/libattr.so.1 (0xb7496000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)

Oh, and next time you compile a program in C, try statically linking libc into it.

Re:Mono and python

[drinkypoo]

The fact that portage (and a bunch of other shit) is implemented in python doesn't make it good. Portage is good because of the design, not the implementation, which as any longtime gentoo user can tell you has been chock full of problems since, uh, forever. And there's no reason that it couldn't have been implemented some other way. Personally, I don't care a lot, but I would prefer that perl achieve world domination than python, simply because I have more perl experience.

Re:Mono and python

[m50d]

You mean to say that you believe distributions like Fedora write all the applications they include? In most cases, they don't (except for things like the redhat-config-* family of apps). Linux distributors don't have a choice about including libc unless they want to rewrite ls and every other application written in C.

And they don't have a choice about including python unless they want to rewrite every application written in python. It's exactly the same situation.

Re:Mono and python

[sgtrock]

I've been running Gentoo for about 4 years, I think. I'm not positive of the exact starting time, but I think I popped in my first Gentoo CD some time in 2001. I was a Mandrake user for a few years before that, and a Redhat user before that. When I got dissatisfied with RPM dependency hell, I looked at attempting to resolve it with Suse and Debian. I've built a few boxes using Debian sarge and Debian unstable. I don't consider myself an expert by any means, but I have built enough boxes with the various distros to have a pretty good feel for what works for me.

I'm familiar with some of the problems with portage, as I've stumbled across my fair share of them over time. It's certainly not perfect. I don't think it's "chock full of problems", personally. I would still far rather use a Gentoo based system to any RPM based system. But, that's just one geek's personal opinion.

Back (semi) on topic. There really isn't anything wrong with Python. It does what it does very well. It has no pretensions of being a speed demon. As for any language acheiving world domination? Assembler all the way, baby! Put that in your .Net pipe and smoke it! :D (joke!)

Re:Mono and python

[jbengt]

It wasn't a proof. It was a simile.

talking about exaggeration

[Anonymous Coward]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.

How about

This may mean that in the future, some native Windows applications will run on Linux, with Mono.

Re:talking about exaggeration

[Rob T Firefly]

As I've told you people a billion times, don't exaggerate!

Re:talking about exaggeration

[Arandir]

I know someone who switched to .NET/C#, from Java. He was told by both Microsoft and Miguel that it was cross platform. His applications continue to ONLY run under Windows, but he doesn't care, because he has been told that they are cross platform. When his applications don't run under Linux (duh) he tells them that it's Linux's fault. People believe what they want to believe.

Re:talking about exaggeration

[Anonymous Coward]

No its not Linux fault - its Monos fault.

The Mono projekts goal seams to be to make sure noone wants to use Linux.

Will Mono achieve what WINE could not?

[overshoot]

Not a chance. All of the MS application base (including the new ".NET" stuff) still depends on the underlying Win32 system functions, DLLs, etc. The newer interpreted APIs are just wrappers around the older stuff.

Re:Will Mono achieve what WINE could not?

[MobyDisk]

Actually it is quite easy because of one crucial difference. It's not the implementation that matters, it is the interface. And .NET provides a good interface.

Even if Microsoft implemented the .NET APIs as wrappers around Windows APIs, the fact is that the APIs are clean and they are well documented. They follow the rules of encapsulation well. That makes it possible to re-implement them in a straightforward fashion. The problem with WINE is that the Windows API does not follow good design and rules of encapsulation, so the implementation is often exposed. WINE is not an implementation of an API as much as it is a reverse-engineering of one. But that problem goes away with .NET.

Mono today works stunningly well today. The only issue is Windows Forms, because it isn't as well encapsulated as the rest of the API.

Re:Will Mono achieve what WINE could not?

[oscartheduck]

I was thinking a very similar thing, namely that if mono manages to take care of all the new stuff, there's still going to be a shitload of old stuff that people want to use. The best that mono will achieve, from what I can tell of the project, will be to make the target APIs that WINE tries to recreate stand still instead of them having to keep up with every new version.

Re:Will Mono achieve what WINE could not?

[Max_Abernethy]

Might still need WINE for some games, though. I develop with Managed DirectX, which uses .NET, but it's just a wrapper around the unmanaged version. There might be other similar libraries that would need re-implementation in unmanaged code to work. Still, I think the prospects are great. It would be wonderful to have that compile once, run anywhere feature to C#, which has been my favorite language to work in for a couple years now. It would be a pretty big blow to java too, I suspect, since IMO that's the main edge it has over C# for application development.

Re:Will Mono achieve what WINE could not?

[WhiteWolf666]

Don't knock WINE like that :-)

Wine runs some serious Windows apps, like MS Office, and Photoshop, Internet Explorer, Windows Media Player.

Picassa, Google Earth, and even many DirectX 9 Games.

Wine is not the abject failure you make it out to be. It's develop is slower than Mozilla at its slowest, but Wine is quite a success, IMHO.

Re:Will Mono achieve what WINE could not?

[StrawberryFrog]

The newer interpreted APIs are just wrappers around .... the underlying Win32 system functions, DLLs, etc.

The Java class library is just wrappers around the OS system functions, DLLs, etc. How else could java work the filesystem, make sockets, get the current date and time, etc?

But this doesn't stop java from being portable, not in the slightest. In fact such a wrapper of the OS is the best way to do portability.

Re:Will Mono achieve what WINE could not?

[petermgreen]

indeed the difference is java worked on at least two totally different platforms (solaris and windows) from the start. If when designing your wrapper you design for just one OS you will probablly make it far more awkward to port to other OSes.

Re:Will Mono achieve what WINE could not?

[MBGMorden]

In fact such a wrapper of the OS is the best way to do portability.

And the worst way to make a useable application. Java applications are slow as molasses when compared to an app compiled specifically for the target platform.

Don't get me wrong, for certain applications where portability is a huge concern, Java is a good thing, and it's use is appropriate. Things like this should NOT be used for all system applications though. It basically serves to slow your PC back down to what it felt like about 5 years ago. Applications worked fine back then - I wouldn't have bothered to upgrade if it was just so I could use all "portable" applications.

This is one of the primary reasons for using open source software. It can be written to be portable, yet still be compiled for good speed on most platforms (even Windows can use most OSS software through the use of Cygwin).

Re:Will Mono achieve what WINE could not?

[evilpenguin]

I disagree with this. Using modern VMs with JIT compilation I see speeds that are comparable to C++ programs. Some things, like tight integer loops, are at parity (after the first execution anyways).

Where VMs do absolutely *suck* is in any kind of scripted context (such as a Java-based CLI utility invoked repeatedly in a shell script). The overhead of starting the VM is horribly huge. This is the bane of any VM based language/API. And it is why these are great in web/app server land.

Re:Will Mono achieve what WINE could not?

[Anonymous Coward]

but it's just a wrapper around the unmanaged version.

That's the thing about wrappers though, as long as the API is clean and doesn't rely on behind-the-scenes action on behalf of the wrapped library, that same wrapper could be made to wrap anything that implements the same things.

In the end though, I think the whole thing is moot. The first pure .net applications from microsoft will likely turn on assembly signing requirements, which would mean they won't run on Mono without it's Forms implementation (and whatever other assemblies they would use) being appropriately signed.

Re:Will Mono achieve what WINE could not?

[SquishyWaffle]

I would've never thought that I'd be able to run native Windows games under WINE/Cedega a number of years back, let alone some of the other programs I use. As with most things in Linux and OSDEV in general, it's only a matter of time before protocols and libraries are reverse engineered and implemented as the list of compatibility and features grows in other related tools.

Mono has its uses and I think it's good to see it progress even if I'm not a Windows/Gates fanboy. True cross-platform support is a great thing, and this is a good step in a long journey that may or may not ever have an end.

Re:Will Mono achieve what WINE could not?

[IamTheRealMike]

Not at all - try doing anything non-trivial with System.Drawing and you'll hit the same problem. And don't even *think* about Managed DirectX!

Did .NET just shoot M$ in the foot?

[ankura]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.

Additionally they should be able to run on non-x86 systems? (atleast apps which don't use pinvoke.)

Sounds like M$ just lost the greatest platform lock-in it had.

Ankur

Re:Did .NET just shoot M$ in the foot?

[Anonymous Coward]

LOL M$ RITE BECUZ THEY MAKE MONEY?!?!?

Fucking prole. Why is it perfectly acceptable for the open source community to rip .NET off and call it something else, yet if M$ (LOLZ) did the same with a *nix-based API there'd be an open source call to war?

They haven't just 'shot themselves in the foot' any more than they've been victims of blatent IP theft. All M$ (LOLZ) have got to do is wait until more of the Linux desktop becomes rooted in Mono before knocking on people's doors asking for compensation for the unlicensed API they've been using for the past x years. Then we'll see who's suffering with a sore foot.

Re:Did .NET just shoot M$ in the foot?

[ankura]

Erm... you dumbass .NET is not an M$ API. Ever heard of ECMA?

M$ got .NET and the CLR standardised by ECMA (which is a standardization body, btw.)

Take a look at:
http://www.ecma-international.org/publications/sta ndards/Ecma-335.htm

Ankur

Re:Did .NET just shoot M$ in the foot?

[Anonymous Coward]

did you heard about RAND???

One more thing

[lheal]

to turn off in Kickstart.

Patents are (supposed) to protect a novel way of doing something. If you can watch that something occur and come up with the same thing, how novel was it?

I know that doesn't mean much once someone already has a patent and a lawyer, but still.

Re:One more thing

[Anonymous Coward]

Patents are (supposed) to protect a novel way of doing something. If you can watch that something occur and come up with the same thing, how novel was it?

I believe that you are confused.

Novel = new.

Copying something = not new.

There are plenty of patented inventions that are ridiculously simple, yet they were novel and non-obvious until the person disclosed them to everyone else. The most famous example is barbed wire. I'm quite sure that you can look at barbed wire and crank out a 10 foot strand in a half hour, so long as you live within 15 minutes of a hardware store. I'm also quite sure that barbed wire was a revolutionary advance in fencing technology. By your standard, barbed wire should never have been patented.

Re:One more thing

[Otter]

Patents are (supposed) to protect a novel way of doing something. If you can watch that something occur and come up with the same thing, how novel was it?

Generally, I get the impression that most of you people literally don't understand what "innovate" (or in this case "novel") means, but you've provided the most obvious example yet.

Re:One more thing

[Breakfast Pants]

That's the biggest problem with patents, and for whatever reason it is especially the case with software patents. Two or more people independently can come up with the same idea. Look at physics, art, or anything and you see this happening all the time.

Re:One more thing

[Anonymous Coward]

What benefid did society at large have from patented barbed wire? Learning how it works?

Re:One more thing

[Anonymous Coward]

Let's see... before the inventor created barbed wire, there was none. After the inventor created barbed wire, a dozen companies spring up to sell millions of dollars worth of the product in violation of the inventor's patent. There was a clear benefit.

Unless you're arguing what benefit did society at large get from patented barbed wire, in which case I'd say you need to prove that barbed wire would have been invented at approximately the same time and developed at the same rate if there were no patents.

Then I'd say you need to prove that AZT would have been invented at approximately the same time and developed at the same rate if there were no patents. Just because you can copy the former once you've seen it and the latter would require an incredibly expensive reverse engineering effort does not mean that the former inventor does not deserve a patent.

Re:One more thing

[Anonymous Coward]

Unless you're arguing what benefit did society at large get from patented barbed wire, in which case I'd say you need to prove that barbed wire would have been invented at approximately the same time and developed at the same rate if there were no patents.

You are the one who should prove that barbed wire wouldn't have been invented at approximately the same time, do you think that the inventor sat down and with the idea to get a patent on a better fence or do you think he needed a better fence and happened to patent it after he solved his problem. As for speed of development it should be self evident that a multi-million dollar industry that stands to benefit greatly from a better production process would have developed faster if they didn't have to worry about patents.

Then I'd say you need to prove that AZT would have been invented at approximately the same time and developed at the same rate if there were no patents. Just because you can copy the former once you've seen it and the latter would require an incredibly expensive reverse engineering effort does not mean that the former inventor does not deserve a patent.

No one deserves patents, they are there to make the inventor do the right thing(tm)--release info. If it's not usefull to have info on barbed wire it's not useful to give anyone a monopoly over it.

Re:One more thing

[Anonymous Coward]

You are the one who should prove that barbed wire wouldn't have been invented at approximately the same time, do you think that the inventor sat down and with the idea to get a patent on a better fence or do you think he needed a better fence and happened to patent it after he solved his problem.

The former. Any economist will tell you that providing legal protection for an invention for a limited period of time will encourage greater investment in research and development by those seeking patents than would exist without a patent. Any scientist will tell you that increased research and development expenditures (within reason) will increase the probability of achieving a research goal, and/or decrease the time between achieving research goals. Do not pretend that individual or corporate R&D investments are made without careful consideration of the ROI. You can point to individual lucky fools, and I can point to a far greater number of unlucky fools. The majority of the money is invested after careful consideration.

The individual motivation is irrelevant because there is no way to test it. As a matter of social policy, and as set forth in the Constitution, patents are promised in exchange for disclosure so long as the invention is novel (and non-obvious, which is a statutory expansion of the constitution's requirement for novelty). Why would someone gamble that they 'deserve' a patent -- and you have presented no criteria for such an evaluation -- for something that is novel and non-obvious rather than maintain it as a trade secret? Would you like to be able to manufacture Coca-Cola yourself? Would you like society to have cheaper Coca-Cola? Well, tough luck, boy, that's a century old trade secret. Now extend that to teflon, antibiotics, fiber optics... just look at non-patented software that contains EULAs that prohibit reverse engineering, and imagine similar clauses in each and every sales contract. I can use obfuscation, contract law, and good old fashioned robber-baroning to maintain a technology monopoly that approaches that of a patent, it just takes too much effort (unless you eliminate patents).

As for speed of development it should be self evident that a multi-million dollar industry that stands to benefit greatly from a better production process would have developed faster if they didn't have to worry about patents.

No, it is only self evident if you assume that research and development expenditures would be the same with and without patents. If you can knock off AZT for $100,000, but you must develop AZT for $100 million, WHO IS THE SUCKER WHO IS GOING TO 'LOSE' $99.9 million? The U.S. patent system is almost 250 years old, and you're arguing that every single Congress has gotten it wrong? Anyone can argue that if you eliminate patents, development would take off... what they can't argue is that development would take off in the long term. It's a short term advantage obtained by allowing people to seize 'property', just like there would be a short term advantage to declaring that everyone could harvest timber from public lands at will. Once you've exhausted the previously protected stock, who is going to plant more?

Re:One more thing

[Anonymous Coward]

As I expected. Spout a bunch of irrational rhetoric and run away. Thankfully, nobody is foolish enough to enact your philosophy into law.

er, no

[Doktor Memory]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono.

If by "the future" you mean "never", then this is correct. Otherwise, this is balderdash.

To all the developers out there...

[bw_bur]

I don't really understand what Mono is. From the Mono site:

Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix.

What's a .NET client/server application? Is .NET something like Java? I would be grateful if someone could enlighten me...

Re:To all the developers out there...

[Christopher B. Brown]

In effect, yes, .NET is a lot like Java.

• It uses a byte-compiled code system called CLR that ought to be platform-independent
• It involves a whole lot of add-on libraries for additional services akin to J2EE
• The 'official' language, C#, is remarkably similar to Java

It is, in effect, Microsoft's "alternative" to Java.

The troublesome part, for those with wishful thoughts about portability, is that Microsoft can implement and encourage use of components not implemented in C#/CLR, but that instead are linking to "pure Win32" stuff. For instance, it makes sense to try to tie in as deeply and "proprietarily" as possible to their versions of Sybase SQL Server, IBM MQ-Series, web servers, the Win32 GUI, and such. That sort of thing is what will provide the desired anti-Java "vendor lock-in."

Re:To all the developers out there...

[Anonymous Coward]

Parent is correct, but unlike Java .Net lets you program in many languages (C# , C++, VB, Python, Eiffel, BOO, & more). And because everything complies down to the CLR all these languages can easily talk to each other.

Re:To all the developers out there...

[Anonymous Coward]

If you program, you are inept.

Java has the same multi-language capabilities .NET has:

CLR is basically the same thing as a JVM
IL is basically the same thing as Java Bytecode.

In fact, you're so completely inept, you don't even realize that Java supports more languages than .NET. In fact, when .NET and Java support the same language (which is common), the Java version is more mature and stable.

Languages for the Java VM
http://www.robert-tolksdorf.de/vmlanguages.html

Buy a clue!

Re:To all the developers out there...

[petermgreen]

but unlike Java .Net lets you program in many languages
both java and .net runtimes let you code in any language that is sufficiantly similar to java/.net in object model (garbage colected heap only objects) and that someone can be bothered writing a compiler for. I belive there are bytecode converters arround in both directions. Often existing languages are screwed about with to make a language that looks similar to the existing language but works enough like java/.net to fit with the vm (vb.net is the classic example of this).

managed C++ seems to be a tool primerally aimed at making linking with native C++ code easier though i admit i haven't looked into the details.

Re:To all the developers out there...

[Anonymous Coward]

C++ (and C) will never be able to run under the JVM (except phenominally slowly and with little or no integration with other languages) unless Sun does some radical modifications that'll upset the entire philosophy behind the system. I can't see a way of doing it, while supporting all of C and C++'s features, except by writing another VM in Java itself (a VM on top of a VM... yum!)

Re:To all the developers out there...

[Weedlekin]

And dynamically typed languages tend to run poorly under Microsoft's CLR, while they work very well indeed with the JVM, despite the fact that it was primarily written for a statically typed language.

NB: while MS are aware of the CLR's issues with dynamic languages, and will in all likelihood resolve them in the not too distant future, I doubt that supporting C and C++ has any importance whatsoever for Sun or anyone else involved with the JVM's specifications. The CLR after all was primarily designed as a multi-language system, and turned out to be nothing like as multi-language as MS had intended; the JVM on the other hand was meant for Java, and ended up being suitable for lots of other languages largely by accident.

Re:To all the developers out there...

[moro_666]

erm ... c++/c dont run under mono too, now do they ? :p

c/c++ are still used to be compiled into machine code while the new platforms all move towards the platform independant btecode and just in time compilation where ever it is executed.

c/c++ can be integrated into java, go grab a jni book.

if c#/mono would execute c/c++ inside it's virtual machine, it'd be just as slow as in jvm. and if it just inlines it, it's the same as jni, just more comfortable syntax.

c# is nowhere near the point where i'd accept it as a replacement for java. everything else aside, the c# api is still controlled by microsoft and therefor right at the fingertips of the great evil himself. if microsoft decides that c# v 2.1 must contain direct approach to directx or any other windows only lib, which doesn't exist anywhere outside, the c# effort from mono will be worthless within a day.

look at what windows vista did with it's direct3d alternative opengl. opengl is F-d in windows vista and doom3/quake4 only run normally in your wet dreams. microsoft wont ever give a real chance to alternatives. it just crushes them when the time is right.

ps. as long as windows programmers hardcode c:\program files\yada\yada paths into their applications, it's as portable as anything else that was invented on windows.

From the article you linked to:

[Anonymous Coward]

"The problematic parts are not the core technologies submitted to the ECMA or the Unix/Gnome-specific parts."

You know, you really should read the article before you post a link to it.

And while we are at it, if you say something is not well thought out, also saying why in your opinion something isn't well thought out usually helps a great deal.

Re:From the article you linked to:

[H4x0r Jim Duggan]

"The problematic parts are not the core technologies submitted to the ECMA or the Unix/Gnome-specific parts."

The problem (software patents) can affect any part. If MS have claimed they don't have patents on "core parts", you cannot trust them. If the Mono devs have claimed that MS don't have patents on "core parts", they are saying something they can't possibly know.

As well as including "according to the public statements of MS and the Mono devs", you should also read that sentence with the qualification: "for now anyway".

if you say something is not well thought out, also saying why

The reasons why their plan is not well though out are given in that article, in the last paragraph of that section, just after the list of the 3 strategies.

Re:From the article you linked to:

[jonwil]

What licence applies to the ECMA spec?
Does the ECMA spec (and attached licence) say anything at all about patents?

Re:From the article you linked to:

[JanneM]

This more general patent problem is not limited to Microsoft and not limited to Mono. Java is no more protected, and neither is any other reasonably modern implementation of anything non-trivial.

The only way to be _sure_ you aren't violating a patent is to turn off the computer and leave it altogether.

Re:From the article you linked to:

[Anonymous Coward]

"The problem (software patents) can affect any part."

As it can affect any software, not just mono, so what's you point?

"The reasons why their plan is not well though out are given in that article, in the last paragraph of that section, just after the list of the 3 strategies."

No, they aren't. The article simply points out why dealing with patents is always problematic. And again, it is only talking about the non-core parts.

Re:From the article you linked to:

[shaitand]

While that is certainly true. Sun does not have Microsoft's notorious history. Clearly, at this point, Microsoft has proven itself to be the least trustworthy of technology companies where compatibility is concerned.

Quite simply, no company has as large a history of trying to trap competitors with illusory compatibility. Publishing a full spec and then clenching down on the patents after significant adoption is one way to do this.

Re:From the article you linked to:

[drinkypoo]

While that is certainly true. Sun does not have Microsoft's notorious history.

Granted, but since Sun is now in bed with Microsoft, all bets are off.

It'll be 10 years before this matters

[Anonymous Coward]

Great to see, but it'll take forever for any big applications to transfer to all .NET. As it is, many .NET applications drop to native Windows calls for graphics, so these parts would need to be rewritten.

WinFX will change that, but while WinFX may be released as part of Vista, the editor for it (Orcas) won't be out until 2007-2008. And Mono still has to implement all of WinFX for that strategy to work.

windows application interoperability

[TehBeer]

http://www.mono-project.com/WinForms

Most .NET apps will most likely need to be ported from native windows to linux and unix based mono apps.
The 100% completion of the above package from Novell should go a long way towards easing that code portage by developers wishing to port their .NET application to mono.

Re:windows application interoperability

[TehBeer]

more info about java integration

http://tirania.org/blog/archive/2005/May-17.html

Am I the only person who reads Miguel's blog?

http://www.ikvm.net/

He posted about this almost a year ago. I've been using monodevelop on FC and SuSE for quite some time. It's gotten alot more stable. You all can compile java to mono IL through IVKM.

Re:windows application interoperability

[jilles]

If mono becomes good enough, developers might start to target it when developing for windows. Right now that is not the case though: it's not good enough. Mono under windows sort of half works but the tooling, sdk, etc. all assume a unix infrastructure. You can of course develop for microsoft .Net but then you end up with their tooling as well which sort of automatically leads you away from cross platform stuff like mono.

Mono as a porting tool has no future IMHO. Mono as a cross platform development kit does have a future. Or at least the potential is there. I don't see much happening in the community to push it that way. Focus so far has been on the infrastructure level: getting the compiler & vm to work and reimplementing microsoft APIs. And yes there's even a windows build of mono available. Development tooling however is linux only, even though much of it is written on top of mono!. If writing a cross platform mono application on linux is already hard, why would the other way be any easier?

I believe mono as a cross platform development kit can happen but I don't see it happening right now. Development focus has been and continues to be linux only. Like it or not, windows has, by far, the largest share of the desktop market. Being able to support linux is nice but windows support is crucial for application developers (or at least the ones that depend on marketshare for income). Right now mono is a nice tool to develop linux gnome applications. If developing linux gnome applications is your ambition, go for it. If you need to look beyond linux gnome, you need something else for your applications.

WinFX != .Net Framework

[rocjoe71]

WinFX (the next .Net Framework)

Not quite right, WinFX can work in tandem with .Net but it is actually an application of XML, used to define working applications and interfaces, pretty much exactly the same way that Mozilla has XUL.

Re:WinFX != .Net Framework

[iGN97]

Parent got it more right than you. WinFX is the next iteration of the .NET BCL which is a collection of managed APIs, including (that is, now adding) WCF (Windows Communication Foundation, formerly known as Indigo) and WPF (Windows Presentation Fondation, formerly known as Avalon) and WWF (Windows Workflow Foundation). XAML is the declarative (XML-markup) which is similar to XUL. All that can be done in XAML can also be done in code; elements used in mark-up will be immediately available as first class objects in C# and friends.

Re:WinFX != .Net Framework

[rocjoe71]

Thanks for the extra info, the brief time I spent with a WinFX beta last summer didn't make it all that clear. I still feel I was somewhat right, but "Troll"? Ouch... I'll just skip contributing altogether next time.

Re:WinFX != .Net Framework

[dmarsh]

Actually WinFX is not "the next iteration of the .NET BCL" either. WinFX is a set of Windows specific APIs built on top of .NET 2.0 runtime and framework. In other words, there will be no new runtime or framework for Vista. WinFX itself is really three sets of APIs rolled under one umbrella:

• Windows Presentation Foundsation (WPF) - provides scalable vector 2d, 3d, rich documents, etc... the "blinking lights" as they say
• Windows Communication Foundation (WCF) - provides communication support for SOAP and WS-* specs, P2P, supports pluggable protocols/wire formats
• Windows Workflow Foundation (WWF) - provides support for creating workflows (used by Office12 for example).

It's also important to note that WinFX is not tied to Vista either. There are different set of APIs within the WinFX umbrella that are going to be available on 2003 and XPSP2 as well. Most likely (perhaps obviously) however, the v1 release of WinFX for all platforms will coincide with Vista's release.

Not bad

[owlman17]

Not to overly simplify things, but Win apps running natively in Linux under Mono isn't necessarily a bad thing. Flame wars aside, Mono has a good chance of doing a better job than Wine in helping people make the transition from Windows to Linux.

All things considered, putting it in FC is a good move. I look forward to what this holds.

Some interesting stuff coming in .NET

[Sanity]

Microsoft has some interesting technologies in the pipeline for .NET 3.0. One of the most exciting is LINQ which will change the way we interact with SQL databases, and data in general from within our code. Other language enhancements will mean that Java has a lot of catching up to do (and no, I'm not a M$ fanboy, Java is my tool of choice and I use a Mac).

The question is: Will Mono support these new features, and if so, when?

Re:Some interesting stuff coming in .NET

[jonwil]

I would imagine that the new features are broken down into:
Runtime/VM changes & support
Class Library additions & changes
Compiler & language chages

Presumably the most important thing for Mono is to support the first one (including any new stuff added to the bytecodes and such) and the essential parts of the second one.

Re:Some interesting stuff coming in .NET

[Inkieminstrel]

One of the most exciting is LINQ which will change the way we interact with SQL databases

With my experiences, I'm betting it'll change the way we interact with MS SQL databases.

Re:Some interesting stuff coming in .NET

[EachLennyAPenny]

Java has lot to catch up? Even Cocoa has this feature which _now_. It is called "Predicates" (http://developer.apple.com/documentation/Cocoa/Co nceptual/Predicates/index.html#//apple_ref/doc/uid /TP40001789). And i think Apple has much fewer developers than Sun.

Re:Some interesting stuff coming in .NET

[asuffield]

One of the most exciting is LINQ which will change the way we interact with SQL databases

Change the way we interact with SQL databases? Only if you've been lumbered with clumsy systems so far. There's nothing in here that perl hasn't had for years, and done better - like the positively scary Class::DBI::Loader, which peers into your database and whips up a class heirarchy to access it on the fly. And if your language needs language extensions to handle interfacing with SQL of all things, then that's a good indicator that your language sucks.

Re:Some interesting stuff coming in .NET

[Decaff]

One of the most exciting is LINQ which will change the way we interact with SQL databases, and data in general from within our code.

The idea of embedding query languages was tried and abandoned in Java years ago (remember SQL/J). Now Java uses truly portable query languages (such as JDOQL) and persistence mechanisms like JDO 2.0 that allow storage to far more than just relational stores. This uses something called 'transparent persistence' where objects and fields are retrieved and persisted automatically without the need for a query language most of the time.

Other language enhancements will mean that Java has a lot of catching up to do

Even Java 1.5 (sorry 5.0!)?

Looking at matters like object persistence, Microsoft and .NET have a lot of catching up to do...

Re:Some interesting stuff coming in .NET

[run26.2]

It is amazing that anyone in the linux community favors c#.Net over java. I think that gnome should be boycotted. All arguments made in favor of mono could also be made in favor of java except vendor lockin by microsoft.

Re:Some interesting stuff coming in .NET

[owlstead]

If this were so, then the D programming language should have won. Any feature you want, it's in there. It even has a nice table to show off.

The thing about a language is that you need to do at least as much, if not more, to keep features *out* of the language. Java/Sun's choice was to keep it simple. This now pays off big time, for instance for real time parsing of Java (in various IDE's including Eclipse). But more importantly, it keeps the language readable and understandable.

C# has many many features (some very interesting features among them), and the way it grows it will become a very fat language indeed. Obese, if they are not carefull. Sun/Java is much more conservative, Java 1.5 was the first big change, and you should not expect *any* new language features in 1.6. They will enhance the API and speed Java up even more (new class verifier), which is much more interesting.

Re:Some interesting stuff coming in .NET

[youknowmewell]

Java and .NET are still catching up to Lisp, so meh :P

Re:Some interesting stuff coming in .NET

[multi io]

LINQ introduces anonymous and higher-order functions like filter, map etc. (a circa-1970 innovation) to C#, plus a syntax hack that allows you to write something like

var seniorNames = from p in people
where p.age>40
order by p.age
select p.name;

instead of

var seniorNames = people.Where(p => p.age > 40).OrderBy(p => p.age).Select(p => p.name)

to make people think that this is something completely new (me, I would prefer the 2nd version), plus an introspection hack that can *sometimes* translate this to SQL/XSLT if "people" is a database table/XML node (as you can imagine, this can't work with more complicated code in the Select/Order etc. code pieces because the implementation actually has to go out and take apart and try to "understand" that code in order to be able to translate it to SQL/XSLT). (no, integrating .NET into the database server directly won't do away with this problem)

Now, it seems the implementation is also pretty decent for cases where "people" is a normal .NET collection object ("deferred execution"), but still, decent OSS languages have had HOFs for years, and this isn't something that's particularly new or hard to do despite some PHBs who now start foaming on the mouth fantasizing how Microsoft is going to revolutionize the way we deal with data in programming languages...

Re:Some interesting stuff coming in .NET

[Sanity]

There's nothing in here that perl hasn't had for years

Um, so Perl is statically typed now? News to me.

And if your language needs language extensions to handle interfacing with SQL of all things, then that's a good indicator that your language sucks.

What a silly thing to say. .NET doesn't need a language extension to interface with SQL, but such an extension is beneficial.

Re:Some interesting stuff coming in .NET

[Anonymous Coward]

Hmm LINQ is storage independant. How about reading a few before posting any nonsense.

Re:Some interesting stuff coming in .NET

[Sanity]

to make people think that this is something completely new

No, like most things, this is built on ideas that will be familiar to those familiar with less "mainstream" programming languages such as ML. What is new here is that they are being brought to a much wider audience.

but still, decent OSS languages have had HOFs for years, and this isn't something that's particularly new or hard to do despite some PHBs who now start foaming on the mouth fantasizing how Microsoft is going to revolutionize the way we deal with data in programming languages...

By "decent" languages, I assume you are referring to languages like ML which receive scant attention outside the academic community. The point here is that .NET is bringing these features to a much wider audience.

Re:Some interesting stuff coming in .NET

[Decaff]

Hmm LINQ is storage independant. How about reading a few before posting any nonsense.

That isn't the point. The point is that Java includes transparent persistence (persistence by reachability using class enhancement or proxying) which means that there is no need for extensive use of such query languages. Once you have accesses one or two key objects, the fields of those objects (and objects that they refer to are automatically fetched (either in an optimised fashion, or lazily) without the developer having to do anything. The state of these objects is monitored, so that any changed objects/fields are automatically made persistent. In spite of Microsoft's anti-Java FUD on this matter (they like to think, against all the evidence, that Object Databases are dead), this approach really works well and is used effectively by hundreds of thousands of developers. It is far more advanced that doing everything with an embedded query language (no matter how portable), as it means that the logic of storage and retrieval does not need to be mixed with any other parts of your code. It means that you can transparently apply persistence even to code that is already written.

Sorry, but the embedded query language idea, no matter how portable, is a 'quick fix' messy solution and leads to increased, not reduced, code complexity. This is typical of how Microsoft approach things.

Re:Some interesting stuff coming in .NET

[shutdown -p now]

Strictly speaking, HOF are there already, with introduction of anonymous delegates in .NET 2.0. They're just not featured prominently in the standard library yet: no things like map, filter, fold etc; but nothing stops you from writing your own versions of those.

Re:Some interesting stuff coming in .NET

[boots@work]

This is a crying shame. On the other hand, there don't seem to be uptodate GNOME bindings for any Lisp implementation, so...

Unless you use python

[codepunk]

I use python for just about everything including machine automation at work. A distro without python would be absolutely worthless to me. Hell ain't the gentoo ports system built on python?(don't know for sure I don't use gentoo).

Re:Unless you use python

[amightywind]

Sadly the portage system is written in Python, which is my point. Gentoo depends on Python. A simple clean design would have Gentoo consist of a kernel, binutils, compiler stack, init scripts, and portage written in C and depending on the C library only. Instead the portage system pulls in Python for no particular reason. By all means use Python as an application language. Foundational system services should not be written in it.

Re:Unless you use python

[dancallaghan]

I agree totally. Since the beginning of time, Unices have included Perl, because that's what everyone used for automation. Python has (thankfully) changed things, to the point where most distros consider Python as obligatory as Perl.

Grand-parent is quite mistaken about how much of a "pain in the butt" (or was it "boil on the ass"? whatever) Python is though -- on my systems at least, it compiles faster and in less RAM (swap, rather) than Perl. And I can then rest assured that most Python scripts I find, or write myself, have access to a broad standard library included with Python -- unlike Perl, where it seems anything worthwhile written in it has a million stupid CPAN dependencies (thank heavens for g-cpan though!)

Re:Unless you use python

[dattaway]

I remember when I could run Gentoo happily on my P120 with 32MB of RAM. Not any more! Its now so slow on my 3GHz system and I'm looking for a faster source based distribution. I hate to say it, but FreeBSD is starting to look good.

Re:Unless you use python

[gowen]

Instead the portage system pulls in Python for no particular reason.

Portage is a complicated set of programs. Complicated programs are easier to write in python, because of the languages features, and complicated secure programs even more so. They're written in python because the developers consider it (one of) the best solutions to the problem.

If you know better, and think it should have been written in C, I', sure the present developers would be very interested in seeing your port.

Re:Unless you use python

[iamwahoo2]

I would say that the portage system pulls in Python for a very particular reason... It is written in Python. Python is also easy to learn so it makes it easy to be a package manager, which means Gentoo will have lots of packages available.

Re:Unless you use python

[codepunk]

Python is just another scripting language but a very powerful and flexible one. Not a whole lot different then using bash on a system should bash go away also?

Re:Unless you use python

[iamwahoo2]

If you run the same programs on a BSD system, your computer is not going to magically become faster. By most accounts that I have seen, Linux tends to be faster than BSD.

Also, I just checked the Gentoo website, they still have an install CD that is under 60 MB, so I know for a fact that the distribution can still be made small and light.

Re:Unless you use python

[Tsunam]

Let, me guess...you happen to think that portage is amazingly slow in doing anything right?

Have you tried the 2.1_pre releases yet, a lot of effort has gone into improving the scalability of it. You will notice a vast improvement on most systems with it. Especially when you hit the KDE modular ebuild updates.

You can also feel free to visit any of the developers in the irc channels ranging from #gentoo to #gentoo-portage for portage itself on irc.freenode.net. Generally, we're all willing to have a nice talk about our various area's with the end user, after all we are end users as well.

ps. just don't start in with the rewrite it in C so it's cool and awesome and python sucks...that'll quickly get you disliked :)

Re:Unless you use python

[birge]

Python is written in C. Therefore, just draw a box around the portage code and python interpreter code and consider that the portage system, and you should be happy.

Re:Unless you use python

[21chrisp]

This comes up in Gentoo Forums/IRC all the time. Gentoo is built w/ Python, so Python is part of the system core. I guess if you have such an aversion to it being there, don't use Gentoo. It takes up very little space and really runs just as fast as a C based system would. That's because the system is bound by the algorithms used to traverse the portage tree and not the overhead of the language used to code it. Recoding portage in C would have little to no effect on the speed of portage operations. It would just start that portage operation a few milliseconds faster, which isn't noticeable. The portage scan itself would take just as long. It would also have a huge effect on the amount of time required to write portage code. So you're trading a small positive for a big negative.

Syncing (and to a lesser extent) searching operations are slow simply due to the vast size of portage. Portage was not originally designed to be so massive. So while it does need to be re-architected, it's not due to any "slowness" incurred by Python.

Re:Unless you use python

[amightywind]

Let, me guess...you happen to think that portage is amazingly slow in doing anything right?

I admire the function of portage greatly. It is the distiguishing feature of Gentoo that makes it a 'living' OS. Its speed is not a huge issue compared to the time taken for compilation. I don't think the design is clean. Portage is not great because it is written in Python. It was not necessary to implement it in something other than C or shell.

Re:Unless you use python

[labratuk]

Your simple clean design would be unfinished for another 2 years with frustrated developers cursing why they had to write it in C.

It would probably also be full of security holes allowing poisoned distfiles repositories to run malicious code.

Re:Unless you use python

[Ashinberry]

Yes, if by "distribution" you mean "enough tools to boot and to download the rest of the system from the internet" then yes, the distribution can be slimmed down. I personally wouldn't expect anyone to use just what's on the install cd for their desktop system.

Re:Unless you use python

[Arandir]

FreeBSD ports are written in plain old make. Just make. A few ports here and there need a script for some things, and they're written in bourne shell. Not bash, just plain shell.

I am not criticizing Python, it's a great language. But you don't need a full blown high level language to manage a tree of ports.

Re:Unless you use python

[ultrabot]

Instead the portage system pulls in Python for no particular reason.

If you can't afford a hard drive with few megs for Python, you should not be running a modern Linux distro. However, I would look in a mirror and think hard why this Python dependency is a problem for you.

Ubuntu has gone the extra mile and implemented a "python-minimal" package, which only has essential libs and takes up less space. I, on the other hand don't really care.

People who program in Python are the ones that have functional code to back up their words, whereas people who want it all-C are typically just whiners who don't understand that developer time is a valuable resource that should not be wasted on implementing new stuff in C. Developer time is certainly much mure valuable than hard drive space of the aforementioned whiners.

Re:Unless you use python

[amightywind]

Here are my recent observations on use of the term "whiner" on this forum.

Re:Unless you use python

[gowen]

But you don't need a full blown high level language to manage a tree of ports.

You don't need anything other than a Turing machine. That doesn't mean that a Turing machine is the best option. The portage people think python struck the right balance between ease of coding/maintenance and portability. As I've said, if you think your way is better, you're quite free to implement it.

Re:Unless you use python

[SanityInAnarchy]

Gentoo depends on Python.

So what? apt depends on the standard C library. So does RPM. And I'm sure they create and maintain their own libraries.

Dependencies are a GOOD thing. Say that to yourself, over and over again, until it sinks in.

I would MUCH rather have to install Python, which I use for other things (BitTorrent) anyway (yes, even on my servers), than have something stupid like a compiled Portage -- still written in Python, but distributed as a small set of binaries -- because you'd STILL have it depending on Python, just Portage would essentially come with its own stripped-down Python that you couldn't use for anything else, or replace with a real Python when you needed it for BitTorrent (or whatever).

And even if you wrote it in C, I'm sure you'd have things you need which are not in the standard C library, meaning the size of the code would go up anyway, only instead of just having the overhead (roughly) of a statically-linked binary, you now have the developer time spent rewriting everything that wasn't already in the standard C library.

And why do you make an exception for the standard C library, anyway? You don't need it. People have written small sample programs in pure assembly, which don't depend on anything and fit inside a single ELF header. You could certainly write a base system that doesn't depend on the standard C library.

But again, such a system would be BIGGER, take up MORE space, and take MORE time to install, except for the time spent calculating dependencies.

You could rewrite Python to not depend on glibc and rewrite all "foundational system services" in Python. But again, all you do there is make Python bigger and spend hundreds or millions of man-years rewriting perfectly decent software in Python for no apparent reason. Stupid, yes? So is rewriting portage in C.

Whining about dependencies is STUPID. Don't complain to the program for depending on something. If anything, complain to what it depends on for not being broken up into smaller chunks. CPAN is a good example of how to do that.

Re:Unless you use python

[amightywind]

See this for what I think of your comment. The groupthink on this site never ceases to amaze me.

Re:Unless you use python

[Al Dimond]

I use both Portage and Ports, and there are some things that Portage does that Ports doesn't. For example, if you want to install some random package that might have a ton of dependencies, in Portage you can easily get a list of everything that will be installed when it's all said and done, and a prompt to allow or veto the installation based on this info (emerge -av foo). In Portage you have USE flags that can tell the system globally not to, for example, turn off Gnome-specific hooks if you don't have Gnome. Or to compile a version of octave without ATLAS (because I don't use octave enough that the speed advantage provided by ATLAS would justify the compile time, which on my old BSD machine would be measured in days; it can be done in BSD with some effort, but it can be done in Gentoo with almost none). I imagine those features would be pretty hard to implement in make. Probably a little easier in shell, probably easier than that in Python.

BSD Ports is clean and consistent, for sure, and it really feels like a natural extension of the Unix system. But Portage gives you a little more, and sometimes that little more is helpful.

At any rate, if your system is tight enough on space that you can't afford a Python installation then you probably won't have space for the Portage tree itself, and you're probably not working on a system that would enjoy doing much compiling either.

Re:Unless you use python

[Arandir]

As I've said, if you think your way is better, you're quite free to implement it.

We already did! Ports predates portage by at least a decade! :-)

For old-school Unix hackers, make and sh are better tools to use. That doesn't mean they're necessarily the best for you. If you want to argue, go find a Ruby advocate...

Re:Unless you use python

[gowen]

For old-school Unix hackers, make and sh are better tools to use.

For old-school Unix hackers, make and sh were the only tools widely available. When all you have is a hammer, everything begins to looks like a nail. It's admirable that it was done, but given the Bourne shell's syntax, I'll bet you a dime to a dollar that the python implementation is considerably cleaner, and easier to maintain and extend.

Consider this, old school unix hackers also used ed, the standard editor.
I imagine when sed and awk came along, there were old-school Unix hackers complaining about all these extra dependencies people seem to need nowadays.

Re:Unless you use python

[jacrawf]

To see a list of dependencies for a package (and other info) do this:

cd /usr/ports ; make search name=SOMEPACKAGE

To globally enable or disable features, see make.conf(5). Not all options are listed, unfortunately, but most will make sense and require only a minimal understanding of makefiles to figure out.

Portage is a little fancier, though, I'll give it that.

Re:Unless you use python

[ultrabot]

So the pattern of the use of the word whiner somehow disproves my point because I used that word?

It's an Open Source world where the needs of the developers matter as much as those of users. Major inconvonience for developers (and slowing of development, increase in bugs, more difficult maintenance) while saving the users a few megs on their hard drive is not a good deal, and when users complain about that... "whining" is just the word that comes to mind.

Re:Unless you use python

[iamwahoo2]

Well, I just checked distro watch and FreeBSD runs KDE 3.4+ and Gnome 2.10+ so I do not know how much improvement you expect to gain by switching. I assure you, it will not be much. It will probably be slower. If you want a lighter desktop you just need to sacrafice some of the bells and whistles that come with the more advanced desktops and switch to lighter weight alternatives.

let me consult the archive

[Anonymous Coward]

Of bullshit statements past to see if they are proven right or wrong...

"Fedora is Red Hat. We work on Fedora, we talk about Fedora release schedules, etc."

Guess not, huh?

Does Mono support Windows Forms now?

[schvenk]

Last time I looked at it, Mono didn't support Windows Forms (and thus couldn't just run your average .NET app out of the box). Has that changed?

Re:Does Mono support Windows Forms now?

[jsight]

Mono supports Windows Forms... it's fairly buggy, but they are supported.

Re:Does Mono support Windows Forms now?

[mayesa]

I believe most of the .Net framwork implemented in Mono is fairly buggy. It's not a surprise to me given that is no good to Microsoft that applications written for Windows, run correctly in other environments.

Re:Does Mono support Windows Forms now?

[Anonymous Coward]

Who really cares, most people use .NET to run web form applications.

Quit Wining

[digitaldc]

Quit Wining, that F-Spot just indicates you have Mono.

MONO is illegal

[Anonymous Coward]

... MS will probably sue them away one day due to license infrigments ...

Re:MONO is illegal

[ChicagoDave]

If Microsoft gave a rats ass about Mono or any of the work done related to Mono, they would have squashed it a long time ago. From all reports, Bill is flattered by Mono...and although Ballmer gets irritated when people ask him questions about it, I suspect he doesn't really care either.

Folks. Microsoft spends $6 billion dollars on R&D every year. They are building C# 3.0 and designing C# 4.0. The direction of C# is going towards a more functional programming capability. They are on the verge of delivering XAML, WPF, and WCF which will alter the way applications are designed and developed on Windows Vista. The new technologies will have no relation to what mono is doing now or even what .NET 1.1 is doing now.

They don't care because they're taking the whole development game up a notch. If you're developing applications in anything these days you should be paying attention not to what we develop in today, but what we will develop in 5 years from now. It will not resemble anything available today.

There's an article by Carl Zetie at Forrester on these new technologies and how they will impact future development. I highly recommend reading it:

The original is here: http://www.forrester.com/Research/Document/Excerpt /0,7211,38241,00.html

The free link is here: http://download.microsoft.com/download/7/c/5/7c51c 83b-d873-40ce-9405-7f792927eeca/Why%20WPF%20Will%2 0Dominate%20Rich%20Client%20Development.pdf

Mono is not threatening Microsoft in any way shape or form. Get over it.

David C.

Re:MONO is illegal

[Anonymous Coward]

Mono: Has a cost of $0 times the number of users at an average site = $0 .NET Environment Cost in $ thousands x Nbr of Users = many $thousands

Mono will blossom as the preferred development environment for applications on Linux. This allows zero cost Linux (C#/Gnome/PostgreSQL) to replace Windows applications.

I can't see Microsoft too happy about this.

$6 billion spent on the wrong things is worthless. Microsoft retired its most successful application language Visual Basic 6, and replaced it with something those programmers won't accept V.Net. Just because Microsoft is a big spender with many-syllabled technologies doesn't guarantee it any amount of success. Look at Xerox/Parc and Bell Labs -- old, previously successful tech companies. Microsoft is not different.

Re:MONO is illegal

[ChicagoDave]

If .NET would have failed, I would agree with this sentiment, but by all accounts, .NET is wildly successful in Fortune 1000 businesses and VB6 developers are beginning to adopt VB.NET and C# in greater numbers. The surveys of top CIO's shows that .NET has enormous respect and that Microsoft has garnered the trust needed to move development along their chosen lines.

Even Microsoft's horrible security track record hasn't kept businesses from adopting .NET. If that doesn't kill them, nothing will.

With the .NET foundation in place and Vista coming at a time when many shops are ready to upgrade their hardware, the next MS development platform is not only very likely to succeed, but also likely to become a standard.

Finally....if you don't think MS is aware of the factors involving the downfall of past corporations you're a fool. They have made enormous changes in the way they do business based on market factors. They have never rested on assumptions for long periods of time and they have never pushed their assumptions onto businesses without having a reasonable plan B.

I suggest you start learning C# because the vast majority of programming positions will be using that language in 5 years.

Re:MONO is illegal

[run26.2]

I agree that it is well worth learning C#; however, if you have already developed in java for several years you already know 95% C#. The IDE and .Net framework are where the differences are. I disagree that fortune 1000 companies are jumping wildly for c#.net. The largest of those companies have requirements and legacy investments requiring something that j2ee can handle that vb.net wasn't designed to accomplish.

The razor is sharp.

[Anonymous Coward]

This was for a variety of reasons; Some were business-related and others were strategic in nature but those don't really matter right now. In the end we came to the conclusion that it should be part of our offerings. And we're happy that we're able to help heal the rift that was slowly growing in the GNOME community.

Ummm someone was really late on this, the rift is now oceans apart and has been for quite some time now. Longtime Gnome users, no longer use it. Feel free to take a survey. As for mono, there is a reason it hasn't caught on. The apps are sound, fun even, the language isn't bad and it looks like fun all around. Except for the whole Microsoft thing. Which has now substantially put Fedora as an "at-risk" distribution. Meaning that simply I won't be recommended Fedora any longer. It not only entraps and puts the developer at risk but also the user. Until the issues of patents and Microsofts spec are fully explained, legalese and all in respect to free and opensource software. Can't touch it.

Why gamble?

Re:The razor is sharp.

[LnxAddct]

Patents are *never* an issue for the end user, only the distributor. If it is found that mono violates patents and MS sues and wins, only SuSE and the Fedora foundation would have to pay anything. Just like if MS violates a patent, every person using windows doesn't pay, only MS. In short, dont base your recommendation on this, worse case scenario is they just have to take it back out of the Fedora software repository.
Regards,
Steve

Re:The razor is sharp.

[deragon]

If part of the settlement requires the Fedora Foundation to remove the technology in the next FC release, the user looses functionnality. Apps that existed and worked for him are suddenly not available anymore, at least in an easy packaged form.

Because of patent litigation, users of the Blackberry in the US could potentially loose their service. Users do suffer from patent issues.

Re:The razor is sharp.

[aztracker1]

Does your fav. distro include Samba, Wine, etc? uh-oh, they may well infringe on MS patents.. better roll your own distro now.

Re:The razor is sharp.

[Anonymous Coward]

Already uninstalled Fedora Core. Fedora Core is going to support Mono therefore I will no longer support Fedora Core.

Since FC is going against RH...

[layer3switch]

Can we start packing ntfs-module and megp3/4 codecs on default FC distro now or at least in EXTRA??? Surely yum repo and other package source and original source compile is easy, but for heaven's sake, when will FC ever include packages based on community demand and not RH guideline?

Re:Since FC is going against RH...

[christooley]

At the time when the company sponsoring the project and taking legal responsibility for the actions of the project feel comfortable that they are either safe from patent infringement or are willing to take on the patent's legal standing. NTFS is a clearly patented technology, as is mp3 and case history shows that judges have been willing to rule in favor of the patent holder.

RedHat holds the strings on the Fedora project because it's RedHat's project. They pay for the equipment, bandwidth and a large portion of the developement community. It's their prerogative to do as they see fit, much like the Debian leaders control that project and Linus and team control the standard kernel tree. If you don't like, there are other distros out there, use something else.

Re:Since FC is going against RH...

[Anonymous Coward]

NTFS is a clearly patented technology

If NTFS were patented then the spec would be available. Good luck to find it!

Mono is like Java

[TCFOO]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono Maby, but Mono is sorta like java. the .Net Programs will be portable as long as the developers don't use Microsoft APIs like java is portable to gcj as long as you don't use the com.sun.* packages etc.

Re:Mono is like Java

[jsight]

Maby, but Mono is sorta like java. the .Net Programs will be portable as long as the developers don't use Microsoft APIs like java is portable to gcj as long as you don't use the com.sun.* packages etc.

Sort of... actually .Net is worse. In the Java world, using "com.sun.*" packages is considered to be a VERY BAD practice, even by Sun. The standard API documentation, for example, does not even include them.

People do still use them from time to time, but they can cause problems even without getting GCJ/GNUClasspath into the picture as often licensed VMs don't support or maintain those APIs either.

In the .Net world, the use of those APIs is not heavily discouraged at all in general.

Re:Mono is like Java

[kaffiene]

Bullshit.

You can program anything you like without using com.sun.* in Java, and Sun SPECIFICALLY warn you NOT to use anything under com.sun.*.

Vista will muddle the developer landscape

[boxlight]

Mono is becoming increasing important due to Windows Vista

As a developer, I have great concern over how Vista will muddle the Windows landscape. Microsoft is creating a situation where developers have to build and test for way too many Windows platforms.

That is, many developers and network administrators use Windows 2000 exclusively and most other pros and home users use XP -- and my father in law still uses Windows 98. NONE of these people have any intention of upgrading to Vista. So Vista will likely only be installed on new PCs

It's getting to the point where there's just too many versions of Windows out there to support:

Win 98 SE
Win 2k Workstation and Server(s)
Win XP Home and Pro
Win Vista??

And the pointy-haired-bosses will continue to shout that *all* versions of Windows must be supported. That means more development, more testing, more installers, more deep sighs.

The "write once run anywhere" of Java is becoming more attractive all the time.

boxlight

Re:Vista will muddle the developer landscape

[TehBeer]

"The "write once run anywhere" of Java is becoming more attractive all the time."

That's nice in theory, and maybe with gnome-java, but regular java swing ui looks like a trucker's behind, and the file dialogs won't even decend when you click on the folder. You have to sit there and click 4 or 5 times before the mouse click interupt actually reacts to the event in the program.

Java is great for shell apps, but not for ui. Gnome-java that eclipse uses is a step in the right direction.

Re:Vista will muddle the developer landscape

[adolfojp]

As long as you make your applications for the .NET framework your applications will run on the .NET framework.
You can get it here and according to their website it will run on the following:

Supported Operating Systems: Windows 2000 Service Pack 3; Windows 98; Windows 98 Second Edition; Windows ME; Windows Server 2003; Windows XP Service Pack 2

It is like Java, except that it is designed to feel and perform like a native windows app.

As for Vista. Considering the monumental effort that they made in making their .NET 2.0 compatible with the 1.1 I can't see any good reason for them to break it in the future.

Cheers,
Adolfo

Re:Vista will muddle the developer landscape

[Breakfast Pants]

Notably you didn't mention supporting windows 3.1. That's because no one does. And eventually that is Microsoft's plan for windows 95, etc. Looking at it in this light I don't see the point you are making. Microsoft has operated this way for decades.

Re:Vista will muddle the developer landscape

[Jugalator]

Win 98 SE
Win 2k Workstation and Server(s)
Win XP Home and Pro
Win Vista??

If one develop in .NET (and obviously don't make direct OS calls or use incompatible third party libraries), a single application compile will run on all these operating systems. Even the latest .NET Framework 2.0 released in November 2005 (IIRC) fully supports Windows 98 SE.

If you use the WinFX classes though, you need at least XP or Server 2003 due to new kernel changes made since the Windows 9x model.

Re:Vista will muddle the developer landscape

[smallpaul]

And the pointy-haired-bosses will continue to shout that *all* versions of Windows must be supported. That means more development, more testing, more installers, more deep sighs.

You act like this is a new problem and not just the situation that the industry has been in since the beginning. What about supporting old versions of Linux? Old versions of DOS? Old versions of Java? Old versions of Python?

The "write once run anywhere" of Java is becoming more attractive all the time.

Right: Java doesn't have a version skew problem at all. Not at all. It's never the case that a minor patch to the JVM will break a bunch of programs. Never. If you believe that you're living in a fantasy world.

Re:Vista will muddle the developer landscape

[bogie]

Not a problem.

98 support is already gone from many apps. The 9X OS series are dead. Time to move on.

2k support is disappearing but will continue for a few more years on apps that large corps use. It's a 7 year old OS already.

And finally XP support will continue for years to come. Just like how 2K killed off 95 support, Vista will be the ultimate end for 98. If your father in law uses 98 tell him to upgrade already. If he wants to keep using an abandoned OS despite his own best interest then he can do that as well. In that case spend $120 on XP Home and 512MB of memory and he'll be all set.

Re:Vista will muddle the developer landscape

[Arandir]

The "write once run anywhere" of Java is becoming more attractive all the time.

But it won't solve your problem. You will still have all those platforms to support. This is no different from C/C++, where one codebase creates one executable that runs on those Windows versions.

Eh... no

[adolfojp]

Mono is becoming increasing important due to Windows Vista, which has WinFX

Mono is becoming such an important platform because it is such a great platform to develop for. If you like statically typed languages C# has no equal. If you like virtual machines, mono is the only one that performs well and is open source. If you like python, you will be able to compile python to bytecode for added performance.

Winforms on mono is not complete yet and it will be a long time before a compatibility WinFX layer is ready. Mono is great for what it is, not for what it could be.

Cheers,
Adolfo

Re:Eh... no

[Anonymous Coward]

If you like statically typed languages C# has no equal.

That's right. C++ blows it out of the water.

Re:Eh... no

[BitwizeGHC]

...and Haskell pwns them both.

Re:Eh... no

[codepunk]

Why would I not just run python native which supports way more platforms?

Re:Eh... no

[jsight]

If you like virtual machines, mono is the only one that performs well and is open source.

Is this really true? I was under the impression that Cacao was actually fairly fast.

And the Mono runtime is far from wonderful at this point, IMO (not all that stable, and not particularly fast).

Re:Eh... no

[adolfojp]

Sir, you are absolutely correct and Cacao is great. And now, to undo my mistake, allow me to rewrite my previous statement.

If you like virtual machines, mono is the only one that performs well and is open source and is designed to be almost programming language independent.

Re:Eh... no

[Baki]

what are you talking about? java is faster than .net/C#. I benchmarked it myself. I don't care to prove it now, but believe me (and google around a bit for published benchmarks): java being slow is very very outdated and stems from times before a decent jit was available. it achieves about 80-90% of native (C/C++) speed in most cases, and .net is NOT faster than java.

it is very sad that so many people fall for the MSFT ploy to sabotage java and supply the world with incompatible and slow JVM, and now after all these years many still blindly assume that java is slow.

Re:Eh... no

[IamTheRealMike]

The Mono VM isn't all that great performance wise, from what I've seen. Suns Mustang VM implements many optimisations Mono does not, as does (it seems) MS .NET

And in the open source VM landscape, LLVM has a much more robust and well documented framework for writing new optimisations (it already has many that Mono does not). I've talked to the LLVM guys, quite a few of whom are compiler specialists or have spent many years writing compilers, and they don't have a high opinion of the Mono VM.

That said, the VM is only a small part of what makes Mono cool. So don't get me wrong. I'm not complaining. But to say "it's the only one that performs well" is rather misleading.

Re:Eh... no

[drinkypoo]

If you like python, you will be able to compile python to bytecode for added performance.

Why would I not just run python native which supports way more platforms?

I dunno, perhaps for added performance?

Re:Eh... no

[NatteringNabob]

Mono appears to be the single biggest consumer of CPU cycles on my laptop running SuSE 10, and I have no idea what it is doing but I seem to have a hang somewhere in the desktop launch. I'm guessing, that since it is the only thing running, Mono is the culprit. So if Fedora 5 core includes it, I won't be installing it. As near as I can tell, Mono is the FOSS answer to Microsoft's anser to a question that nobody asked, or to paraphrase Dennis Ritchie, Mono fills a much needed gap in computer languages/runtime environments.

Re:Eh... no

[Anonymous Coward]

Mono appears to be the single biggest consumer of CPU cycles on my laptop running SuSE 10, and I have no idea what it is doing but I seem to have a hang somewhere in the desktop launch. I'm guessing, that since it is the only thing running, Mono is the culprit. So if Fedora 5 core includes it, I won't be installing it.

So because one program running on Mono is causing problems, you're assumption is that the entire platform is bad and shouldn't be allowed near your machine?

For what it's worth, I have a handful of GTk#/Mono apps running on my desktop here (a antique Celeron), without noticing any great problem with performance.

Re:Eh... no

[typical]

If you like statically typed languages C# has no equal.

ML is more heavily statically-typed than C#.

Re:Eh... no

[shutdown -p now]

And don't forget about the ability to use a nice, modern programming language such as Nemerle, with all the FP, pattern-matching and macros goodness, while still retaining access to all the CLR libraries (and most importantly, Gtk#).

Re:Eh... no

[NatteringNabob]

[So because one program running on Mono is causing problems, you're assumption is that the entire platform is bad and shouldn't be allowed near your machine?]

Yep, that and because I can't easily tell what program is causing the problem. FWIW, I reinstalled SuSE 10 without installing Mono, and the problem is solved. Whatver the offending program was, I don't miss it now that it is gone.

I don't expect Mono to be around long anyway. Eventually Microsoft will sue Novell for patent infringement, and that will be the end of Mono. It is just a matter of time.

Why .MONO

[Anonymous Coward]

I still don't get Mono.

Summary is mostly un-true. You cannot run most .NET applications in Mono because .NET is too closely tied to older legacy MS stuff - you'd need to be able to host COM and ActiveX, use pInvoke, have access to the Windows registry and so on. Also as far as I know no WinForms compatible library exists so anything that uses the GUI won't work. And MONO doesn't support the version 2 libraries either (Vista etc.) as yet.

So what you actually have with Mono is another development environment that is neither compatible with .NET or compatible with anything much else and a Java clone called C# which basically has all of the headaches of Java with none of the benefits.

If you want to port your .NET applications to something similar that works on Linux, Solaris etc. why wouldn't you just use Java which has done the same job perfectly well for years.

Re:Why .MONO

[Christopher B. Brown]

There is a merit of MONO over Java, for free-ish software, namely that it is likely to be a more uniform platform than Java.

The trouble with Java, at present, is that full implementations (complete with all the latest J2EE, Java 1.whatever-is-latest) are proprietary to Sun and other commercial vendors. You can't include a full-scale Java with a Linux distribution; the licenses won't permit it, as the implementations aren't "free" the way Linux and attendant software in a Linux distribution need to be.

The lowest common denominator takes you back to partial implementations of Java 1.2 or the like; Kaffe, Classpath, and the like, with no Swing GUI and I'm not sure if Eclipse will run well with these "partial" Java environments.

MONO avoids all that; the free implementation is reasonably full featured, seemingly moreso than the "libre software" implementations of parts of Java.

I doubt it'll actually provide all that much interoperability with Windows. But the point of it was that the Ximian folk were getting tired of fighting with writing C memory management code for dynamic applications like Evolution. If they can write "Evolution Next Generation" using MONO, and have it be smaller, more componentized, more powerful, and more robust than struggling with the C version, that could be the "killer app" that makes MONO worthwhile in its own right, ignoring Microsoft's software.

It seems to me that Beagle is one of the relevant components for MONO-based "killer apps."

Re:Why .MONO

[0xABADC0DA]

What you said is true, but it also really sucks. Ximian and company could have made a JVM and classes, copying Sun instead of copying Microsoft. Lets be honest, the reason why they didn't is because Linux programmers are, by the large, antagonistic to Java. C#.NET is basically the same things as Java, only worse.

And that's the sad part. We get a crappy NamingConvention that does tell the reader anything, unlike Java's where the namingConvention actually tells the reader something useful (class vs method/variable). We get crappy delegates (method pointers) instead of inner classes, so your winforms for instance have many times more methods and it's just a mess. We get a bytecode format and native code interface basically make advanced optimizations like hotspot impossible, so making it fast is going to take a lot more work. You get C++-type generics that bloat the vm with types leading to slower operation (instanceof can take for freakin ever). ... etc.

So mark this troll. Fine. And there are some good things about C# (like value types and properties), but mostly it is just a crappy copy of Java in a lot more ways. And it really sucks that the unix crowd are going to adopt it basically because of their bias and prejudice. It's ironic, but if Sun hadn't ported the jvm to linux we'd all be using an oss version of it now. And be better off for it.

Re:Why .MONO

[sky_halud]

Since when is borrowing potentially patented technology from Microsoft can be considered free-ish? Not to mention that the whole .NET is a copy of Java (it really is). And how can Mono be uniform if it must keep pace with Microsoft's spec changes?

Honestly, how can someone be that silly to even put the terms .NET and free in the same sentence? I suppose Microsoft might have a special fund for this kind of misinformation.

I'm not sure how could it be easier to write "platform independent" applications in .NET than in "partially" implemented open-source Java implementations. Just look at the comparison between GNU Classpath and the JDK 1.4 API (http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14 -classpath.html) and see it for yourself.

Re:Why .MONO

[Christopher B. Brown]

If MONO turns out to be breaking MSFT patents, then I'd have to wonder why Java wouldn't also be...

Java has had the same trouble as C++; you can use it for things, as long as you chose a particular subset of the language/environment to use. With C++, if you go past [some subset], madness and insanity result; with Java, it's not madness, but rather that you're tied to someone's proprietary Java implementation.

If you had watched more carefully, you'd see that I never said anything about "free .NET"...

Re:Why .MONO

[sky_halud]

Fortunately Java could not break any .NET patents for what it is now because it was the firstcomer ("prior art"). Only in future developments there might be some problems. But Mono isn't on safe ground for sure.

I did not encounter situations during development in Java when I had to use a com.sun.* class and wasn't something alternative already available. But do you happen to have some examples on this?

My main problem with the Java API is rather of a different nature. There are several cases of missing native operating system bindings that should be hidden behind a standard API. And that's the point where native code (maintained for every target OS) needs to be developed. That's a real problem. But this is due to its platform independence and might get solved in time one step at a time.

You are right that you did not directly talk about free .NET but rather about a free-ish one. In any case, I hope that it has been made clear for outsiders why .NET isn't free.

Re:Why .MONO

[Anonymous Coward]

I don't see that as a persuasive argument any way around.

If you intend to run your free software on a fully free stack (and you should :), you need to write it to the free implementations of your chosen language, whatever it is. See RMS's article about the Java Trap; the same could be said for any language where proprietary implementations are the dominant ones that most people write their applications to, be it Java, C#, Delphi, or whatever.

Mono and other free runtimes are going to play catchup with the proprietary implementations as long as they are not the dominant implementations. Given that Sun Microsystems, BEA, IBM and Microsoft probably spend a few orders of magnitude more R&D cash on their implementations than Mono and the whole bunch of us on the java side combined, I don't see a point in dissing matches between Java and .net fans which free implementation of what sucks more than the other in relation to a proprietary runtime. Given their resources, I believe they are all doing very well, actually, both on the .net and on the Java side, in catching up.

I keep hearing success stories from the Mono devs, and I am involved in some of the success stories on the java side of free runtimes. I am happy to see Mono let people run their .net apps nicely, just like I am happy to see Kaffe, gcj, cacao, ikvm, etc. do it on the java side. Everyone's come a long way in the past five years, and I am enjoying encreasingly being able to pick the right free software tool for the job, without being forced to use a proprietary wedge in my software stack.

cheers,
dalibor topic

Re:Why .MONO

[Anonymous Coward]

But the point of it was that the Ximian folk were getting tired of fighting with writing C memory management code for dynamic applications like Evolution.

What the hell is dynamic about it? It's just crashware.

What I want to know is .....

[ajs318]

..... why wasn't the Open Source clone of the "C#" programming language called "Db" ?

Re:What I want to know is .....

[Arthur B.]

Mod parent funny or insightful... I think most people really don't get the C# joke.

Re:What I want to know is .....

[Kadin2048]

For those who haven't figured it out yet ... "C#" is prononuced "See - Sharp."

The joke will be left as an excercise for the reader.

Re:What I want to know is .....

[Anonymous Coward]

why wasn't the Open Source clone of the "C#" programming language called "Db" ?

Then they would be the same thing, which mono is not yet... :)

Re:What I want to know is .....

[WWWWolf]

Because the Open Source Community(TM)(R)(C) wanted to show that they don't want to "innovate" by making stupid puns on the original product names, but rather "clone" the commercial market by following the lead and pulling silly names out of the hat? =) =) =)

Also some musician might want to explain in detail why in some instruments Cis != Des. I'm not quite of the exact thing myself, but it had something to do with the ways how some instruments are tuned or played.

Re:What I want to know is .....

[Lobais]

Because mono isn't a c# clone, but a .net clone, and .com really is taken.

Re:What I want to know is .....

[TeknoHog]

Also some musician might want to explain in detail why in some instruments Cis != Des. I'm not quite of the exact thing myself, but it had something to do with the ways how some instruments are tuned or played.

First of all, these Cis/Des names are used in Finland and probably in other Nordic countries, but not everywhere. It's C# and Db like the original poster put it.

I can't give a complete explanation on the difference, but one way of putting it is that C# and Db are "originally" separate notes. The well-tempered scale that we use in keyboards, guitars etc. is a compromise relating to the fact that C# and Db are very close to each other, and they are treated as the same note.

Moreover, these "original" pure scales have the problem that you can tune your instrument to sound very nice in a certain key (like F major), but it will sound bad in other keys. The well-tempered compromise makes each key sound equally good, but none of them is quite as nice as a pure scale. There's also the practical problem of limited space on keyboards.

Re:What I want to know is .....

[Anonymous Coward]

D flat C sharp
And the open source guys couldn't bear to live with that one.

A brave prediction

[Flying pig]

Who is this "we"? Perhaps it won't have the slightest effect on 90% of us. Why does this post sound like a Microsoft marketing bulletin with a small addition to try and make it look less obvious?

Re:A brave prediction

[dragmorp]

Who is this "we"? Perhaps it won't have the slightest effect on 90% of us. Why does this post sound like a Microsoft marketing bulletin with a small addition to try and make it look less obvious?

The technology in C# 3.0 is innovative. It introduces powerful query capabilities into the language that allows you to generically query objects.

These concepts will be included in some way in future languages.

Therefore, it will change the way we work.

Re:A brave prediction

[Sanity]

Why does this post sound like a Microsoft marketing bulletin with a small addition to try and make it look less obvious?

It probably sounds like that to you because you are a slashbot.

If you disagree with something I said then why not offer more than a childish ad hominem?

Re:A brave prediction

[Pecisk]

If you want to check and change the way you work, I suggest you to try WebObjects/EnterpriseObjects with Java. So THAT is really new way of doing things.

Re:A brave prediction

[molarmass192]

After scanning the doc on LINQ, this is basically just a rip-off of Hibernate for Java. The problem with these highly abstracted APIs is that they mask too much native DB functionality. Unless you can code NATIVE sql, these kind of object abstractions will never be able to displace mid level interfaces like JDBC/ODBC. Even then, there's a whole vendor specific API that's only available in interaces like OCI for Oracle. I'm sure there's more to C# 3.0 than just LINQ, but this feature won't be the java "killer".

Re:A brave prediction

[lubricated]

> If you disagree with something I said then why not offer more than a childish ad hominem?

and make a crappy retort.
The truth is that your original post was light on substance but heavy on the use of marketing words like "exciting".
You made statements without qualifying them. Why is it exciting? How will it change the way we communicate?
Furthermore how can it change the way you communicate, if you program in java?
Your post made little sense, yet was filled with marketing words. That's why. There was little to disagree about.

Re:A brave prediction

[Narcissus]

I have not been following C# at all, but tell me: is this ability to query objects anything like the Query Object Framework?

I've never used the QOF to be honest, but I'm always trying to find a reason to :) Apparently Gnucash uses it for it's reporting engine. It effectively lets you write SQL-like queries and run them on your objects. For Gnucash at least, this means that an end user can create their entirely own reports by just writing the query for the report.

Be sure to understand that it does not use a SQL database for this. All of the classes inherit from a base QOF class and with a few lines of code, your class 'automatically' becomes queriable.

I think the whole concept is amazing and it astounds me that it seems to be only Gnucash that uses it...

So, back to my original question, I guess: is this C# feature the same concept? I'm assuming that it would probably be a bit tighter, maybe, without having to do those extra few lines of code?

Re:A brave prediction

[Sanity]

The truth is that your original post was light on substance

My post contained a link to as much information as you could ever need about LINQ, hypertext is this wonderful thing which means that you can just refer someone to more information without having to regurgitate it every time, as you seem to be suggesting.

Your post made little sense

You might think so, the people that modded it up clearly disagree, perhaps they know how to click on a hyperlink?

Re:A brave prediction

[Seahawk]

Btw - there is a perfectly fine port of Hibernate to .Net: Nhibernate

Re:A brave prediction

[Anonymous Coward]

One of the developers of Gnucash is the guy behind qof. Qof is his own little experimental project that is never stable, never fully functional... and Gnucash relies on it as well as being written in LISP.

Gnucash is a horrible, horrible mess that is (at its current pace) decades away from being a serious financial applications... meanwhile the authors wank off about LISP features and qof, and spend months writing and rewriting various database stuff for no good reason. It's the perfect example of computer science zealotry losing the plot and forgetting the actual goal. Madness.

Re:A brave prediction

[Anonymous Coward]

LINQ is more than just a database abstraction framework, although that is part of it's functionality. LINQ is the implementation of lambdas and extension methods together to produce an SQL-like syntax with which you can query any form of enumerable object, from an array to a collection of classes to XML to a database.

int[] numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
var query = from i in numbers where i % 2 == 0 select i;
foreach(int i in query) { Console.WriteLine(i); }
var query2 = numbers.Where(i => i % 2 == 0);
foreach(int i in query2) { Console.WriteLine(i); }

Both would list all even numbers in the array. The SQL syntax is sort of backwards, a decision made because intellisense features would function better if the source is known first. The VB9 team has decided to follow SQL more closely in it's implementation.

Any way you dice it LINQ provides an interesting new approach (for procedural or OOP languages) to tackling querying data, regardless of it's source.

Re:A brave prediction

[lubricated]

>> You might think so, the people that modded it up clearly disagree, perhaps they know how to click on a hyperlink?

so while you criticize someone for an ad hominem. You simply say, I'm right because someone agrees with me.
Yeah, that's sooooo much better.
You could just try explaining how advances in .net are exciting for a java developer.

>> My post contained a link to as much information as you could ever need about LINQ,

yet still failed to answer why YOU personally like it so much.
Like I said no substance, just a link and then buzzwords like "interesting exciting, catching up, etc. . ."

Re:A brave prediction

[milimetric]

wtf are you talking about. Mono isn't Microsoft. The fact that we may finally have a platform that both Linux and Windows developers agree to work on is a ... GOOD THING. Think before you post, don't drink and post, etc.

Re:A brave prediction

[maraist]

Any way you dice it LINQ provides an interesting new approach (for procedural or OOP languages)

Not seeing how this is innovative for OO languages. It's just new syntactic sugar for callbacks (or lambdas, if you're a sissy).

In Perl (also available in python/ruby)

print "hi $_\n" for sort { $a $b } map {$_ + 1} grep { $_ > 5 } ( 1 .. 50);

Ruby allows you to name the temporaries which is nicer.

Java is less elegant, but no less powerful (using things like apache-commons)
for (int item :
  Collections.sort(
    CollectionUtils.tranform(
        CollectionUtils.select(
            Arrays.asList(1,2,3,4,5,6,7,8,9,10,11),
            filter),
        transformer),
    comparator))
{
    stream.writeln("Hello " + item);
}

Where filter, transformer and comparator need to be separately instantiated but are of standard interfaces. Often, a class will define appropriate query/mutating tools alongside it; making the above seamless. And it is often that an object intrinsicly extends such services (such as Comparable).

Moreover, you have greater control in the Java world (and by extension .Net) because the intermediate sets can be internally unique, ordered, event-triggering, read-only, auto-generating, etc. It's harder to do this in many other languages, or at least the principle of least surprise does not come into play in such languages (tied variables in perl can be upsetting if not feature-incomplete).

If by "change the way you program", you guys mean that now you'll start using this paradigm, then good for you. Of course, if all you want to do is see how many items in a set match, then you're introducing a world of hurt using this technique.. E.G. a non-exhaustive scan/search is much more efficient than instantiating /processing intermediate sets (even if you're transparently deferring that thinking to the database layer). Not that every use of such a syntax produces such temporary data. But I find that in the rare circumstances that I do operate on data in Java in such a way, there are concerns. While I am new to LINQ, I doubt these concerns are obviated. I'm sure that set-based data access isn't manditory; you can always revert to procedural programming when it is more clear/scaleable.

Why .NET if we have Tomcat?

[michelcultivo]

Fedora guys, please promote more the Tomcat platform although telling that you have .NET support. It's better to community.

Misleading

[JanneM]

The whole "run Win-apps under Linux" really is a little misleading. That's not really the point of Mono for most users.

The point, rather, is that it is a very, very nice development environment and a very pleasant language, well-suited for application development, as f-spot and others are a testament to. As a bonus, the apps written under mono will be easy to deploy under Windows as well, should it be needed.

And when you use Mono to write desktop apps under Linux you aren't using anything Windows-related that isn't covered by the ECMA standard. You have no larger exposure to patent issues than you have under any other environment (possibly barring plain C and POSIX libs. Possibly).

Re:Misleading

[Anonymous Coward]

so, the true power of mono is that it allows one to develop on *nix and then deploy on linux and windows?

that is cool and very useful.

why pimp this feature out as "being able to run windows apps on linux?"

if i did application work, i might've gone this route. heck, if we could get some of the app makers to go this route, can anyone say quicken?, we'd all be better off.

it seems like a nice way to get apps to run on both linux and windows - *IF* that is the intent of the author.

thanks for summarizing the good things about mono - i was lost amongst all the other comments.

Re:Misleading

[drinkypoo]

As odious as this concept probably is for many people I'd like to see a full gnome on win32 that could replace explorer. That way, I could have my nice gnome interface, and use cygwin to provide Unixlike features, while still being able to run windows applications. This also makes a nice potential gateway from windows to linux; wean people off the windows interface, then off their windows apps, and finally off windows.

errata?

[Anonymous Coward]

Will Mono achieve what WINE could not?

Will Mono achieve what Microsoft could not?

who owns the fedora domains trademarks etc

[petermgreen]

e.g. could redhat say fuck you to the comunity and take over the process of finalising the official relase.

Re:who owns the fedora domains trademarks etc

[petermgreen]

how is this offtopic? the fedora community has decided to go against redhats wishes so isn't it ontopic to ask if redhat have the power to stop them doing so?

Re:who owns the fedora domains trademarks etc

[Anonymous Coward]

The Fedora community of non-Red Hat employees does a lot of work on Fedora, the Red Hat people do most of the work and the Red Hat people do all of the decisions.

This decision was done by Red Hat. Check Planet GNOME for details.

Re:who owns the fedora domains trademarks etc

[Anonymous Coward]

Look at who put the mono packages together for Fedora. It was a person from Red Hat (Alex Larsson). Somehow I don't think anyone has anything to worry about, and I think that the text about it being against Red Hat's wishes is misleading.

Big Deal

[smartin]

If anyone thinks that Mono will allow applications that were written on windows to the windows implementation of .net will somehow run seemlessly under linux, think again. .net is largely a scripting front end for native windows C++ dlls. Yes there are some implemenations of some of the .net libraries for mono but there is no way that 90% of the code written for .net will ever work under linux. Even applicatons written specifically for mono, like paperboy or beagle are shakey at best.

I suppose mono is interesting if you think the .net framework is useful, but if you want to get/write/use cross platform applications, say away from propietary M$ technology.

Re:Big Deal

[typical]

One complaint that I don't hear much about Java and C#/.NET is that they encourage you to write multithreaded programs. As you can tell from my signature, I don't have a high opinion of multithreaded software.

Will mono achieve what wine could not? No.

[caseih]

But that's not important anyway. I think Mono is just another framework that can be used to develope slick apps on Linux. Having compatibility with apps written for .NET is just a fringe benefit. As we all know, MS is apt to change apis and break mono's compatibility on a whim. Even when they do, though, Mono is still incredibly useful to the Linux community.

I think that Mono, Java, Python, Perl, C, and C++ will all be very useful languages and environments, all deeply integrated with GTK, Gnome, QT, KDE, etc, bringing us many useful apps. I'm not opposed to these bytecode languages and runtimes, and also interpreted scripting languages such as Python making C and C++ less and less relevant for pure application development. At some point I can see objects running in very dissimilar runtime environments instantiating and calling other objects. Right now one of the coolest features of Mono is the inclusion of IKVM, allowing Java apps to run in the .NET runtime and transparently call into both Java JAR libraries and Mono libraries.

So in short, I don't care in the least about being able to run MS .NET binaries on linux. However running cool apps like beagle I do care very much about.

solidarity

[H4x0r Jim Duggan]

People in Europe and Britain are kinda safe right now. Software patents are being granted, and are being used as the basis of litigation threats that the recipients can't afford to contest, but at least the courts are on our side, so far.

This situation is not stable. If China, India, and Latin America bring in software patents, then Europe will probably give in at a subsequent world trade agreement.

To keep people in Britain and Europe safe, people in Britain and Europe must take action - and one easy way to do this is to donate to competent, active groups such as FSFE. One way to do this is to join The Fellowship of FSFE, and also encourage others to join.

Here's a webpage about how and why to support FSFE's Fellowship campaign.

Re:solidarity

[ajs318]

If China, India, and Latin America bring in software patents, then Europe will probably give in at a subsequent world trade agreement.

I hardly think India, China or Latin America are in any danger of introducing software patents. Peru and Chile were about this far away from outlawing closed-source software altogether. Governments in countries with a high level of poverty are not going to do anything that benefits the rich at the expense of the poor -- they will be deposed quicker than you can spell AK-47.

Software patents are being granted, and are being used as the basis of litigation threats that the recipients can't afford to contest, but at least the courts are on our side, so far.

It's a statutory defence to patent infringement that the supposedly-infringed patent was improperly granted in the first place, and that won't take much effort to prove in court. The law is clear: abstract mathematics is not patentable.

Also, new laws generally can't be applied to events that took place before the law was made. So even assuming a government has granted unenforcible software patents, those patents will instantly become null and void the day that the scope of the law is widened to allow software patents, and the holders will have to re-apply for their patents. Otherwise that would constitute retroactive application of a new law {because if a new law says software patents are enforcible as of today then they must have been unenforcible yesterday}, and that would be unconstitutional in nearly every country. Meanwhile, any work which had "infringed" an improperly-granted patent would now constitute prior art which could be used to block the "proper" application.

Re:solidarity

[cortana]

I heard that India brought in software patents shortly after the Indian Ocean tsunami at the end of 2005. China has been issuing software patents for some time.

How about C#?

[Pecisk]

I think one of most important points is possible to code in C# for GNOME platform. C# is easy, object-oriented language (similar to Java), so it IS important to get various programmers which are familiar with Microsoft .NET Studio to even start to THINK about that. About Windows apps is also important, but I would not say that is is highly possible that all apps based on .NET will run on Mono - because, quite frankly, .NET is not as portable as Mono is.

I think we should move on and forget patent scare, because it is not how we are gonna win this war. Yes, someone will wonder - is there really a war? Do we need this? I want only my console, my Flubox, my Englightement minimalistic stylish desktop and that't all.

Problem is here if we won't fight, maybe tomorrow you won't have such freedom to run a simple console mp3 player on your old box and use it as jukebox.

So Mono is quite essental for getting "free desktop" to the masses.

Of course, there are problems. One of them are patents, quite clearly. I have thought about this and really, my pick is that is it is too obious that Microsoft would get penalty ticket about trying to force patents about .NET use. I simply think that Microsoft is not in position to attack open source with patents AND I have actually changed my mind about Microsoft and patents. They are clearly positioned to attack open source with different methods - marketing, PR stuff. It doesn't give away any possibility that it WILL happen, but I think in the case of Mono I trust Novell and lawyers of other companies who obivously have overlooked patents. If they use it - I think it should be safe.

Another problem is that Mono is not quite here for prime time - it is slow and sluggish. However, in last quater of 2005 I have seen lot of improvements of speed and memory usage of Mono base, so it is just time that Mono will be usable.

And in the end, I would like to point out that like it or not, quite lot of "killer apps" are written in Mono - F-Spot, Beagle, etc. I use them every day and they rock, period.

really

[petermgreen]

This will mean that in future, all native Windows applications will easily run on Linux, with Mono. Will Mono achieve what WINE could not?"

BULLSHIT

mono will run into the same problem wine and free java have. if developers develop for one implementation you will be hard pressed to make an alternate implementation that works flawlessly with the apps those developers develop.

IronPython

[lkcl]

the best bit about Moo is the CLR, for which IronPython has been written.

IronPython is a complete reimplementation of python, that uses the common lala rumbleburper and therefore it understands - and directly interfaces with - .NET and Mono binaries. this is _fantastic_, because it means that you can write code in python and yet access a stack of rubbish written in some daft microsoft language.

the only thing: you _do not_ have access to the python system libraries (but that's okay because you have full access to the .NET system ones instead).

when i said you are programming in .NET runtime but it's just that you're using a python syntax to do it i really meant it. so that even means that you have access to gtk-sharp.

so you really _can_ write platform-independent prprograms in a de ecent programming language.

.

Re:IronPython

[robotoverflow]

uses the common lala rumbleburper and therefore

You know those times when you're reading something and have a double-take, then keep reading the same thing over and over because it feels like somehow you've forgotten how to understand words?

Re:IronPython

[TeknoHog]

the only thing: you _do not_ have access to the python system libraries (but that's okay because you have full access to the .NET system ones instead).

so you really _can_ write platform-independent prprograms in a de ecent programming language.

I think a big part of Python's attraction is its own set of libraries (which is probably the same thing they say about Java and .NET :). Though I certainly love the syntax too.

IMHO, Python does everything that Java and .NET have been promising, except it's a little better in being more honestly platform-independent, not tied to any single vendor. Unfortunately this is also its major weakness, since there isn't a big commercial entity pushing it everywhere.

Re:IronPython

[multi io]

the best bit about Moo is the CLR, for which IronPython has been written.

well...

olaf@tack:~$ mono --version
Mono JIT compiler version 1.1.12.1, (C) 2002-2005 Novell, Inc and Contributors. www.mono-project.com
TLS: normal
GC: Included Boehm (with typed GC)
SIGSEGV : normal
olaf@tack:~$ /usr/local/src/IronPython-1.0-Beta1/IronPythonCons ole.exe
IronPython 1.0.2190 (Beta) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> 42

** ERROR **: file class.c: line 3319 (mono_class_get_field): assertion failed: (mono_metadata_token_code (field_token) == MONO_TOKEN_FIELD_DEF)
aborting...
Aborted (core dumped)
olaf@tack:~$

Re:IronPython

[miguel]

The recent beta of IronPython exposed some bugs in our 2.x VM implemnetation, luckly they have been fixed.

Download 1.1.13 (available now).

No, and let's get that out of the way first.

[Kadin2048]

While on the surface that might seem like a good solution, in the long run it's totally unacceptable.

First of all, the primary users of Linux (and arguably the most important, financially) have been corporations -- running webservers, scientific projects, etc. A patent problem could easily scare them away. There's already enough FUD spreading about FOSS -- do you really want to give Microsoft more ammunition? I can just see the letter's from Microsoft's legal department already. "We have received information that you may be using software that is in violation of Microsoft's software patents. If you do not cease and desist from using this software, we will be forced to seek an injunction against your business. By the way, here's a coupon for 20% off of Microsoft SQL Server!"

Also, a patent-violating project could spread 'virally' because of the nature of open source code and contaminate other projects, as well as producing derivative projects, which would then not be usable in the U.S. except for personal use.

Effectively, such a strategy would create a branch of code that would not be GPL-compatible if used in the U.S.

It's a really terrible idea. Linux as an O.S. and FOSS in general would be better off dumping support for Mono entirely, than risk a patent war with Microsoft that would essentially hand them the American commercial market for the next 20 years.

Idea - don't write windows native apps

[LarsWestergren]

Here is an idea, instead of aping after everything Microsoft does (monkey see, monkey do...), thereby giving them water on their millwheel, why don't you write good apps that run natively on Linux instead.

Or if you really want platform independence, write it in Java. Then you will be able to run it on Windows, Mac, Unix, Linux, BSD, mainframes...

Re:Idea - don't write windows native apps

[tacocat]

You are half right.

I personally believe that most projects spent on emulating something Microsoft has done is a waste of time. Historically Microsoft has had very little contribution to the computer industry that has any significant longevity or impact outside of their own interests.

With the exception of MONO, I am not aware of any projects to emulate Microsoft versions of languages (eg: Visual Basic). In contrast, Perl, Python, Ruby, Lisp, Java, C/C++ where all languages that were developed someplace other than Windows and have managed to remain rather viable to date. And they have some degree of cross platform compatability depending on the platforms and the constructs of the language used.

If you look at their other products: Office was nice but it's getting a bit out of hand. But OpenOffice covers >90% of the functionality. And it's something that is available on and compatible with more OS platforms than Office. Long term, it's ultimately a better buy.

About the only arena that Windows might have advantages is with IDE's. But I'm not a big fan of most of the IDE's out there. They tend to assume your code style and ultimately you end up debugging your code on the contributions of the IDE rather than your own contributions or the contributions of others. When you spend time trying to fix your code because of your Environment, it's time to move to a new environment. But that's just my opinion. A lot of people absolutely love their IDEs.

But I have to disagree with the conclusion that you can just write everything in Java to make it cross platform compatable. Yes, you probably can. But Java just isn't that special anymore. It's not the only language that's cross platform capable. It has never really lived up to it's proclaimed write once run anywhere mantra. It's done well, but it's never been a guarantee. More like, write once, test everywhere, hope you get lucky.

When you compare the speed of Java (start up and runtime) and the fact that it's compiled to the newer (alternative) languages like Python, Ruby (perl as an alternative) there really isn't much left for Java to do that's worth the overhead in development time and resources. My past experience with Java is that I have to keep watching out for Out of Memory errors on applications. This is the only programming language that I have experienced an Out of Memory error in the past 5 years.

I'm starting to think that languages that are not developed by companies are better than languages that are developed by companies, regardless of their intentions.

Re:Idea - don't write windows native apps

[Anonymous Coward]

I agree with everything you just said. In sun's defense, java "6" is supposed to use more native widgets, speed up drawing and startup times for the vm. If that actually happens, it might get more useful. Gosling has made a lot of statements lately about people's impressions of the language. They are trying. I don't think they understand the problems with swing or to a lesser degree the j2ee umbrella.

My biggest problem with java is anything that requires a view to be generated. swing and awt suck. jsp and jsf suck.

I think the reason .NET is so popular is that its amazingly easy to get started with it. The IDE does half the programming for you, but you must memorize some basic .NET data types. Once thats done, MSDN docs can save your day. Most open source languages and projects still lack good documentation. I think companies force you to document more than anything. This needs to be addressed in the OSS community.

Re:Idea - don't write windows native apps

[dcam]

Because sometimes the code is already written.

Re:Idea - don't write windows native apps

[tacocat]

Good points. Maybe '6' will be of some use. But the only real difference between Java and the other languages I mentioned is the GUI capability of Java. If that "sucks" as you say, then there is even less outstanding for Java.

I think it was a good idea at the time and may have some useful areas in the future, but I don't believe it's all it's been advertised to be.

can mono work with wine

[petermgreen]

to run .net apps that use winapi?

Re:can mono work with wine

[lamber45]

The most recent time this was discussed by the wine developers is in this thread. At one time some Mono developers were linking wine to mono, but then they got upset about the changes in the Wine API for Linux programs (this was before the 0.9 release), and they decided to just do all WinForms-related stuff with native .NET code. AFAIK no one has tried to do anything in that direction since the 0.9 release.

Accuracy

[palad1]

It's not really accurate...

WinFX, the next .Net framework... Beg your pardon?

Oh great...

[Goth Biker Babe]

Linux is becoming as bloaty as Windows...

Re:Oh great...

[myz24]

I think you mean Fedora Core is becoming as bloaty as Windows. There are other projects that are not bloated such as Damn Small Linux but then you'd complain it just can't cut it as a Desktop.

Re:Oh great...

[Tet]

Linux is becoming as bloaty as Windows...

Only if you make it that way. Although FC4 provides nearly 2000 packages as standard, I only have just over 500 installed. I start with a minimal install, and then just install extra things via yum as and when I need them.

From a practical point of view..

[rann]

I think this is good news. I use FC4 and include Novell's mono repos. It's the only outside repo I use, all other stuff I build/hack/package myself. This means I won't have to use any repos besides Core and Extras, which rocks. Maybe this will mean they'll also include Muine? My fave musicplayer, which happens to be a Mono app. Who cares about them windows compat features anyway? There's enough coolness in Mono on itself to warrant its inclusion into FC5. More languages, more choices. Sounds great!

MONO just got interesting

[Foofoobar]

You know I've been a big C# opponent for awhile (and still am) because of the fact that Microsoft owns it. Yes yes, it's an open standard but the Microsoft approach of embrace, extend and destroy still looms over the open standard on which the MONO projectis based.

But not once did I consider this fact that applications built for Windows would be running on Linux thus replacing WINE. This is a fascinating idea but I have to ask, will this replace other types of development if this is the standard across two major platforms?

Also, it has been noted that due to the different implementations, applications built for .NET may not work with MON due to the differences in the language and the underlying architecture of the OS.

I'm still no big fan of MONO/.NET but if this DOES pan out, it should be very interesting.

Re:MONO just got interesting

[Anonymous Coward]

Holy fuck. You are the biggest dumb piece of shit ever. I hope you fucking die. Grow up, faggot! Can you be any more immature in your hatred of MS? Please pull your Tux doll out of your ass. Fag.

Re:MONO just got interesting

[Foofoobar]

Spoken like a Microsoft executive. You just need to work on your chair throwing abilities.

eww

[ToddFFW]

Well I won't be kissing Fedora any time soon...

crackproof?

[TehBeer]

An interesting point not yet raised is that when you compile your code to such a weak instruction set as an intermediate limited opcode set like IL, you leave your code wide open to being decompiled, not just disassembled with something like the mamoth i686 or x86_64 opcode sets.

That means that compiling your code to these instruction sets inheritly makes them open source, unless you believe in the obfuscation fairy. And the obfuscation fairy doesn't fare too well in a debugger.

Is hacking disassembled code that much harder? No.

Is copying a huge chunk out of it and putting it in another program as useful when you only have the binary interface?
No way. A developer looking to do that will take the decompiled sources over disassebled opcodes any day of the week.

Interesting stuff to think about.

Re:crackproof?

[cnettel]

I would say that it's more important that Java and .NET both basically always give you debug symbols, for the needs of verifying type and memory safety.

I'm not sure about your point of obfuscation, do you mean that it's easy to see through it by using a debugger, or that it's hard to debug already obfuscated code. That's sometimes true for optimized x86, too.

It's not the IL that gives you nice decompilation, it's the metadata.

Accuracy

[blowdart]

Mono is becoming increasing important due to Windows Vista, which has WinFX (the next .Net Framework) as its core API.

WinFx is not the next .net framework, it is the next generation API set.

It's an encompassing term, covering Presentation Foundation (how you display things on screen), Communications Foundation (secure program to program stuff), WinFS (the meta data "file system"), Workflow and Infocard (authenication and authorisation), all of which exposed as a managed code API.

It is also not limited to Vista, most of it will be back ported to XP and 2003. Look upon it as a Win32 replacement for .net. Now imagine implementing that from clean room code. Stop crying at the back.

So whilst the summary may be concise, it is not, I am afraid, accurate.

mod parent down

[Anonymous Coward]

How is this not a huge stinking troll?

Serioiusly, python is there because it excels at doing what it does, which is being a high level clear and easy to use language which can be used for just about everything asides from ultra-high performance stuff (which can be written in C and used from python anyway).

Gentoo relies on python for it's portage system, calculating dependencies isn't cpu intensive, so python is well suited for this because it allows the designers to concentrate on making a great system (which amounts to fast because it does its job simply and reliably).

And it sounds to me like the poster has less of a problem with python than with gentoo.

Well guess what retard? You can have your python-less from-source system, it's called linux from scratch. Oh what's that? You'll have to do without portage? But it's just a boil on the butt of the source...

Go back to coding your portage replacement in C, oh what's that you don't contribute? And go back to coding your bittorrent replacement in C, and go back to helping with the code for that browser "Dillo" (oh what's that, that browser sucks for features... but it has teh *speed*).

And don't forget to go tell the Gentoo guys who actually code portage that they are wrong and you are right. Make sure to tell them they are the cause of the boil on the butt of gentoo.

Can you build and run this with MONO?

[lindi]

Can you build and run rasterbator

http://arje.net/rasterbator

with MONO? Here's what I tried (Debian unstable):

$ wget http://arje.net/files/Rasterbator_Standalone_1.2.z ip
$ cd "Rasterbator Standalone/source"
$ gmcs -unsafe *.cs
MainForm.cs(35,26): error CS0234: The type or namespace name `Windows' does not exist in the namespace `System'. Are you missing an assembly reference?
Compilation failed: 1 error(s), 0 warnings
$ gmcs --version
Mono C# compiler version 1.1.12.1

Any idea what's wrong?

Re:Can you build and run this with MONO?

[lupus-slash]

It compiles just fine with:
mcs -unsafe -resource:Rasterbator.MainForm.resources -r:System.Windows.Forms -r:System.Drawing -r:../itextsharp.dll *.cs
copy the resulting .exe to the parent dir, because it expects to find the files and directories there when you run it.

It has a couple of bugs related to the directory separator: basically the programmer added code to make sure his program didn't run on Linux :-). See how ApplicationDirectory is created in MainForm.cs. There is also a similar bug when saving the final file.
The app seems to work just fine after that change, kudos to the System.Windows.Forms team!
This is with mono 1.1.13ish.

Re:Can you build and run this with MONO?

[lindi]

Thanks for the info! I'll write these build instructions down and inform the upstream eventually to provide a Makefile if this works. Slashdot is probably the best place to debug this but "mcs" seems to only build the "AssemblyInfo.exe" here. Does it build Rasterbator.exe for you? Also, running the built AssemblyInfo.exe fails with a long backtrace: $ mcs -unsafe -resource:Rasterbator.MainForm.resources -r:System.Windows.Forms -r:System.Drawing -r:../itextsharp.dll *.cs MainForm.cs(1685,8): warning CS0169: The private method `Rasterbator.MainForm.NumericUpDown4KeyUp(object, System.Windows.Forms.KeyEventArgs)' is never used Rasterbator.cs(117,10): warning CS0169: The private property `Rasterbator.Rasterbator.Directory' is never used Compilation succeeded - 2 warning(s) lindi@sauna:~/local/raster/Rasterbator Standalone/source$ ls AssemblyInfo.cs MainForm.cs Rasterbator.MainForm.resources Rasterbator.cs Rasterbator.prjx rasterbator.ico AssemblyInfo.exe Makefile Rasterbator.cmbx Rasterbator.exe.manifest gpl.txt lindi@sauna:~/local/raster/Rasterbator Standalone/source$ cp AssemblyInfo.exe .. lindi@sauna:~/local/raster/Rasterbator Standalone/source$ cd .. lindi@sauna:~/local/raster/Rasterbator Standalone$ mono AssemblyInfo.exe Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.Form ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: gdiplus.dll in (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System .Drawing.GdiplusStartupOutput&) in System.Drawing.GDIPlus:.cctor ()--- End of inner exception stack trace --- in in System.Drawing.Image:InitFromStream (System.IO.Stream stream) in System.Drawing.Bitmap:.ctor (System.Runtime.Serialization.SerializationInfo info, StreamingContext context) in in (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[]) in System.Reflection.MonoCMethod:Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)--- End of inner exception stack trace --- in System.Reflection.MonoCMethod:Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) in System.Reflection.MethodBase:Invoke (System.Object obj, System.Object[] parameters) in System.Runtime.Serialization.ObjectRecord:LoadData (System.Runtime.Serialization.ObjectManager manager, ISurrogateSelector selector, StreamingContext context) in System.Runtime.Serialization.ObjectManager:DoFixup s () in System.Runtime.Serialization.Formatters.Binary.Obj ectReader:ReadNextObject (System.IO.BinaryReader reader) in System.Runtime.Serialization.Formatters.Binary.Obj ectReader:ReadObjectGraph (System.IO.BinaryReader reader, Boolean readHeaders, System.Object result, System.Runtime.Remoting.Messaging.Header[] headers) in System.Runtime.Serialization.Formatters.Binary.Bin aryFormatter:NoCheckDeserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) in System.Runtime.Serialization.Formatters.Binary.Bin aryFormatter:Deserialize (System.IO.Stream serializationStream) in System.Resources.ResourceReader:ReadNonPredefinedV alue (System.Type exp_type) in System.Resources.ResourceReader:ReadValueVer1 (System.Type type) in System.Resources.ResourceReader:ResourceValue (Int32 index) in System.Resources.ResourceReader+ResourceEnumerator :get_Value () in System.Resources.ResourceSet:ReadRe

Re:Can you build and run this with MONO?

[Anonymous Coward]

From the error message, it looks as though you are missing the System.Windows namespace. I have not looked at the source, but it is probably a WinForms application. This might, and I mean might, work on mono. However, you will need the most up-to-date version of libgdiplus. Even then it might throw errors. You may even try downloading and compiling the latest sources from the subversion repo. I know that the mono devs have announced that they are at full .NET 1.1 compatibility with all ECMA assemblies, and the only thing holding back the release of mono 1.2 is finishing up work on the System.Windows.Forms namespace. Good luck!

Re:Can you build and run this with MONO?

[lindi]

The above errors are more readable at http://rafb.net/paste/results/Q83ykY52.html

Re:Can you build and run this with MONO?

[compass46]

MainForm.cs(35,26): error CS0234: The type or namespace name `Windows' does not exist in the namespace `System'. Are you missing an assembly reference?

Also, C# 2.0 isn't complete, are you sure you shouldn't be using mcs over gmcs?

http://www.mono-project.com/CSharp_Compiler

Re:Can you build and run this with MONO?

[lupus-slash]

You're missing the libgdiplus library: install it or compile it (take it from the same place you downloaded the rest of mono).
Check the mcs -out option to give the binary the name you want.
You can also just rename the file after compiling, you know.
You'll still need the change to the source. The two broken lines will need to look like this:

ApplicationDirectory=ApplicationDirectory.Replace( "file://","");
ApplicationDirectory=ApplicationDirectory.Substrin g(0, ApplicationDirectory.LastIndexOf("/")+1);

Include a \ in the filename when saving if you don't fix also the saving code.

Re:Can you build and run this with MONO?

[lindi]

Wohoo! It works! Thanks a lot!
Seems there were also issues with paths that contain spaces since the program tries to open
20818 stat64("/home/lindi/local/raster/Rasterbator%20Sta ndalone/itextsharp.dll", 0xbfffef84) = -1 ENOENT (No such file or directory)
Any idea if mono should handle these or is it a bug in rasterbator?
For the record I've put all the necessary modifications online to

http://iki.fi/lindi/Rasterbator.buildfix1.diff

Because it's not related to D

[Benanov]

D is actually another whole language, unrelated to C# (but related to C).

Re:Because it's not related to D

[Anonymous Coward]

I guess you didn't study music at school Db (D flat) is the same note as C# (C sharp).

Fedora to exhibit at SCALE 4x

[irabinovitch]

Fedora will have a booth at SCALE 4x.

The Op-Ed from La-La-Land

[intnsred]

This story's initial headline and second sentence would have made an informative and possibly controversial news item -- FC5 including Mono over Red Hat's objections.

But the article wanders into 100% opinion mode, walks through the looking glass, and winds up smack dab in la-la-land. Case in point:

Is the Linux community finally ready to accept Mono? Mono is becoming increasing important due to Windows Vista, which has WinFX (the next .Net Framework) as its core API. This will mean that in future, all native Windows applications will easily run on Linux, with Mono. Will Mono achieve what WINE could not?

Good grief son, buy yourself a clue! Learn some computing history. Read up on OS/2's support for Windows apps in a much simpler API era. At that time, IBM had access to Windows' source code and could "easily" write support to run Windows programs on OS/2. Yet IBM finally gave up because Microsoft could break OS/2's Windows support easily and Microsoft did so many times. IBM finally came to the conlusion that customers bitching about broken Windows support was not worth the headache. Lesson learned: If you control the API, you control everything.

Do we really think that Microsoft will stand by and let Linux become a viable competitor in the .NET realm?

Microsoft is bound to stand by as some GNU/Linux use evolves in .NET. But make no mistake about it, they'll time a convenient -- but "mandatory" -- API change at a very opportune time to maximize Linux's second-class status as a .NET platform. What a perfect way to throw some mud on your competitor while appearing lily-white and innocent!

Of course, just like this article, this reply is 100% opinion. YMMV, depending on what side of the looking glass you're on.

Oh, and to answer the question: No, the GNU/Linux world is not ready for Mono/.NET -- not if we're smart.

Re:The Op-Ed from La-La-Land

[WhiteWolf666]

Good grief son, buy yourself a clue! Learn some computing history. Read up on OS/2's support for Windows apps in a much simpler API era. At that time, IBM had access to Windows' source code and could "easily" write support to run Windows programs on OS/2. Yet IBM finally gave up because Microsoft could break OS/2's Windows support easily and Microsoft did so many times. IBM finally came to the conlusion that customers bitching about broken Windows support was not worth the headache. Lesson learned: If you control the API, you control everything.

Things are different now. Take a look at the way Crossover Office works. Codeweaver's Crossover Office is a viable application used in quite a few large scale linux deployments.

Codeweaver's does, indeed, work on duplicating the Win32 API (yes, codeweavers contributes substantially to Wine), however, rather than set architectural goals, codeweavers works on an app-by-app basis. They certify one app at a time as a compatible, to a certain patch revision. The end-user commercial product works like that, and the enterprise level support is a customized environment for whatever your needs maybe.

Codeweavers is a good deal more nimble than Win32 (and Microsoft) can be.

Re:The Op-Ed from La-La-Land

[kaffiene]

Exactly! IBM with its considerable resources couldn't keep up with Windows compatibility due to M$ moving the API, yet Mono proponents tell us that they *can*.

Um... bullshit.

Alternative

[16K Ram Pack]

I do .net programming, but I really don't understand this.

Isn't part of the point of people using open source to get away from "lock in" by manufacturers? Wouldn't the effort be better expended on a truly open alternative, like something based around Python or Ruby?

Re:Alternative

[Anonymous Coward]

i think the point to mono

1. program in mono on linux.
2. works on linux.
3. gee, it also works on windows, too. this can't hurt.

the problem is that msft will wreck this as they wreck everything.

now that autoupdates are the norm, they can auto break your mono app.

They Had To

[ObsessiveMathsFreak]

The "article" fails to mention the single biggest reason why Mono was included. Fedora is a Gnome centric distro, and more and more Gnome applications are being written in Mono.

Miguel de Icaza has already been taken up on this. He basically said that the MS Sword of Damocles, didn't exist.

Whether it does or not, Gnome is getting Mono, and hence Fedora is too.

Mono?

[Oldsmobile]

So when do we get stereo?

LINQ? Looks like hacked embedded SQL

[Anonymous Coward]

Have you looked at the LINQ samples? Looks like a hacked version of SQL embedded in code. How is that special?

Mono Inclusion in Fedora 5

[Quenyar]

"with Mono. Will Mono achieve what WINE could not?" You mean, like making Linux vulnerable to all the Windows viruses, worms, and whatnot?

Best Development Environment: DOS Box!

[Anonymous Coward]

It's getting to the point where there's just too many versions of Windows out there to support:
Win 98 SE
Win 2k Workstation and Server(s)
Win XP Home and Pro
Win Vista??

Which is why our handheld data-entry software is written for a DOS box, with one executable that runs under all released versions of Windows (with slight installation differences), and will run under Vista as well, Allah willing!-))

Hyperbole in summary

[Anonymous Coward]

I'm sure FC includes many optional packages that nobody uses. Including mono by default would be like enabling True Type's hinting (patent held by Apple) in freetype, it would open all users to infringement claims. The submitter seems to have swallowed a bowl of MS Marketing chuff, nobody I know cares for Mono.

People hyping C# on linux are like chief lemmings.

Quality of unencumbered Java implementations

[lamber45]

The lowest common denominator takes you back to partial implementations of Java 1.2 or the like; Kaffe, Classpath, and the like, with no Swing GUI and I'm not sure if Eclipse will run well with these "partial" Java environments.

Eclipse is a package in FC4, compiled with gcj. It's fairly stable, and the user-interface is the same as in a version of Eclipse running with Sun Java on another platform.

Re:Quality of unencumbered Java implementations

[Anonymous Coward]

Yup, and in Debian and Ubuntu as well, and probably other places.

cheers,
dalibor topic

Re:Quality of unencumbered Java implementations

[LDoggg_]

And it includes an open source implementation of the Swing UI classes.

Completely missing the point

[GauteL]

The inclusion of Mono in Fedora is the first step towards healing a rather serious potential rift in the GNOME world. Up until now, you could not develop a Mono-app with GTK# and expect it to work on all major updated distributions without added software.

Don't worry about Windows compatibility, Mono is cool enough on it's own, especially because Novell/Ximian has done such a good job with the Mono-wrappers for GNOME-technologies. Hopefully this will see more GNOME-development.

Re:sluggish

[namekuseijin]

"Mono is not quite here for prime time - it is slow and sluggish"

that never hampered java and .net themselves...

Umm, so what?

[Anonymous Coward]

What exactly is the big deal about Mono being included in the distribution? Couldn't you just download and install it yourself if you wanted to? Or were there no Fedora-specific RPM's before this (which meant risking dependency hell)?

Python - or bash

[CustomDesigned]

Do you object to using shell scripts? Do you always write small C programs to avoid depending on an sh compatible shell? When shell scripts get to a certain level of complexity (I know I've gotten there when I have to turn to my coworkers and ask, "Did I get the quoting right in this script?"), you will save lots of development and maintenance time by using a scripting language with more large program features. I see Python, Perl, and Ruby as the major competitors for that slot. I could go into why I prefer Python to Perl or Ruby, but that would be an unneccesary flame war. I would absolutely respect any distro based on either. But it is nice when you can standardize on one language for complex system level scripts.

Dont count on it

[nurb432]

Dont count on microsoft apps running on mono. They will hide something that will be required to run that only microsoft has. And if you try to reverse engineer it, you will be sued.

Mono Is Dead

[broward]

http://www.realmeme.com/roller/page/realmeme?entry =mono_project_meme

"Will Mono achieve what WINE could not?"

[darthservo]

I don't know...WINE has seemed to accomplish quite a bit lately.

Shell language confusion

[amightywind]

Do you object to using shell scripts?

You are confused if you think of Python is a shell language. Shells invoke programs and provide variables and control flow for them. That's it. No classes, no inheritance, no cruft. Simple. Great in a base system application context. Great to string together the simple orthogonal programs that have made *nix famous. Python is a kitchen sink OO extension language which can link C libraries. Loaded with syntactic sugar, it has a much wider scope than shell and it is massive overkill. Python is also conceptually unstable. Constant incompatable upgrades are made. Again, most inappropriate for base system glue.

When shell scripts get to a certain level of complexity (I know I've gotten there when I have to turn to my coworkers and ask, "Did I get the quoting right in this script?"), you will save lots of development and maintenance time by using a scripting language with more large program features.

Supporting a program written by people who do not know what they are doing is a challenge regardless of the language used. The point is not germane to this discussion.

I see Python, Perl, and Ruby as the major competitors for that slot. I could go into why I prefer Python to Perl or Ruby, but that would be an unneccesary flame war. I would absolutely respect any distro based on either. But it is nice when you can standardize on one language for complex system level scripts.

A *nix init system written using Perl? You must be on acid.

Re:Shell language confusion

[boots@work]

Loaded with syntactic sugar, it has a much wider scope than shell and it is massive overkill.

Here's the complete grammar of Python 2.4, as good a measure of the amount of syntactic sugar as anything. I doubt the grammar of Bourne shell is any smaller. (I seem to recall that there are so many irregularities in shell syntax that it's not even possible to describe it in EBNF, but I might be wrong.)

Python is also conceptually unstable. Constant incompatable upgrades are made.

Such as?

I wouldn't bet the whole thing on Mono

[21mhz]

I think Mono is OK in GNOME as long as it's used to run applications at the top of the dependency stack. GNOME can live without Beagle if it must, but any pivotal library or service, such as GnomeVFS, should still be implemented in C, if only for fear of sudden patent complications.

Windows dependency

[towsonu2003]

as if we needed one more dependency in Linux

mono?

[Anonymous Coward]

just the thought of them including mono makes me feel weak at the knees.

Trust Microsoft.

[Burz]

Miguel de Icaza: Mono BOF Proposal Turned Down By Microsoft For Second Year Running?
"At the last PDC," Miguel de Icaza (pictured) notes, "the Mono BOF had the largest number of votes when half the spots were still available and it got dropped out of the list." Now it seems that history is about to repeat itself.

Writing, in his blog, of last year's disappointment, he explains:

        "When I asked the various people in charge what happened they kept pointing fingers at someone else until it reached full circle. Nobody could tell me why the most voted BOF proposal did not get selected. I would be happy with an honest answer even if it is "We do not want to promote open source/Mono/Novell" instead I heard a number of variations on "The problem is that `New frontiers for 6502 assembly language in the copy-editing industry had more votes'" (it didnt)."

This year's PDC, de Icaza fears, "is looking just like the last one. So it is time to get ready for a Mono meeting like we had the last time: in the middle of the hallway."

Very telling entry from Miguel's own blog.

What's on display here isn't even remotely close to a cooperative spirit to further a community standard. It is more of a Cold War.

ECMA? Who cares... ECMA trying to set the direction of C# and CLR is like steering a truck with a flea.

Re:Trust Microsoft.

[Azi Dahaka]

Well, CLR isn't a language, but the Common Intermediate Language is, and that is what matters. I believe it is not an ECMA language, although i certainly could be wrong. C# is, but it doesn't help very much when we really need to interpret the CIL to use .NET binaries.

Funny

[SuperKendall]

If you like virtual machines, mono is the only one that performs well and is open source and is designed to be almost programming language independent.

It's awfully funny how C# developers all the sudden get all teary-eyed over the ability to use any other language than C# when the topic of faster JVM's comes up...

But then someone has to go and mention that the JVM runs about 200 languages. How many does .Net run again? And how many are not bastard neutered languages like managed C++?

So I guess you need to re-phrase your statement to say "if you want to have access to many langauges, and have the fastest VM you should really just drop Mono/.Net like a hot potato and stick with Java - until you decide to try a real language on for size and move to Ruby."

Re:Funny

[drinkypoo]

It's true that more languages compile to the JVM than the CLR. However, by all accounts I've heard so far it's also true that the CLR is superior to the JVM, from design through implementation.

Re:Funny

[Anonymous Coward]

It's awfully funny how C# developers all the sudden get all teary-eyed over the ability to use any other language than C# when the topic of faster JVM's comes up...

But then someone has to go and mention that the JVM runs about 200 languages. How many does .Net run again? And how many are not bastard neutered languages like managed C++?

And it's awfully funny how the "JVM supports 200 languages" argument continues to be raised in these discussions even though it has been shot down every time.

First of all, that list contains everything from precompilers to Java language extensions. They are not all complete languages on their own. More importantly, though, many of these languages are able to target the JVM only by first translating the code into Java source and then compiling that down to Java byte code. The compiler is not written to target the JVM directly. I take it that this the easiest route for developers that are targeting a platform that was not designed for alternate languages.

OTOH, the .Net common language runtime was designed to allow compiler developers to target it directly. This may seem like a minor point. If the end result is the same then the developer probably doesn't care how it's accomplished. But in an argument about the relative merits of different VMs then this is definitely a plus for .Net.

MODS!

[Anonymous Coward]

How is parent offtopic? For anyone who doesn't konw about mono this is a useful question... the answers will help them follow the discussion.

Such as?

[Numen]

Sorry I'm going to have to call you on this. After years of developing commercially with .NET I've never once had to make a native call. I'd be interested to know what activities you think routinely require this.

Re:Such as?

[drinkypoo]

I don't remember him saying that it's required, just that it's trivial. That likely means it will be done often...

Re:Such as?

[IamTheRealMike]

Pretty much anything multimedia related ... or try getting the current machines IP address. There are a bunch of odd tasks that .NET doesn't cover.

That's for desktop stuff of course. For server-side stuff, it's probably pretty complete.

Re:Such as?

[nametaken]

Getting any/all of a machine's IP addresses is remarkably simple, and does not require a native call. Check out the System.Net namespace. Just thought you might want to know. :)

Re:Such as?

[anarxia]

I don't think there is a reporting solution that works with Mono. Please let me know if you know one that does. The two big players, Crystal Reports and ActiveReports, use Win32 hooks either for licensing or for functionality not present in .NET. Also, many commercial applications use the Infragistics components which also uses Win32 hooks

Native calls or the above libraries are not the only things preventing an application from running on Mono. Did you actually get your commercial application(s) to run on Mono?

Some sig pedantry

[mtdnelson]

"Effect is used as a noun, affect is used as a verb."

It is true, without doubt, but it really isn't the whole story. As it happens, either word can be used as a transitive verb, or a noun.

The differences are in the meaning of the words. Have a look at these definitions: http://dictionary.reference.com/search?q=effect and http://dictionary.reference.com/search?q=affect.

I know it's pedantic, but I just couldn't help myself.

Re:Some sig pedantry

[shaitand]

Congratulations. You have been caught in a troll trap. You are the latest in my campaign to capture and tag all the grammar trolls on Slashdot. Please refer to my journal for more information.

Re:Some sig pedantry

[mtdnelson]

So?

Which do you think is the more anti-social behaviour - posting misleading information deliberately, or politely pointing out an inaccuracy, for the benefit of anyone who might actually care?

For my part, I think hard about each one of my posts. They may veer off-topic occasionally, but that's how discussions work, isn't it? If you choose not to read them, that's your loss.

proof by analogy

[abe ferlman]

That's proof by *false* analogy buddy. Your wiki link is only helpful if you demonstrate that the analogy is false. Also, an argument by way of analogy is a fine way to make a normative argument, even if it's not a good way to construct a formal proof. This is because norms are in fact quite imprecise and depend greatly on context; a good analogy between things that are alike in meaningful ways can provide a great deal of insight into how to approach an issue.

LINQ is not MSSQL-only

[ravenlock]

Wrong. If you watch the video of Anders Hejlsberg demonstrating LINQ, you'll notice that it's a language feature, not a MSSQL-only layer, and he actually demonstrates using LINQ not only with MSSQL but XML documents and arrays (IIRC) too.
Miguel De Icaza's comment on the video was "Anders Hejlsberg is a man of excellent taste"

The video is a bit on the long side, but it's well worth it if you're interested in the topic :)

Re:LINQ is not MSSQL-only

[Inkieminstrel]

Indeed, I'm sure it works well with XML, Access, and SQL Server. In the video, he shows the extension to ADO .NET which allows you to query a database using compiler-checked syntax. Having experienced the wonders of ADO .NET with non-MS databases (Oracle, mostly), I'd put money on the fact that the new built in queries won't play nice with such databases.

Re:LINQ is not MSSQL-only

[Anonymous Coward]

What syntax features couldn't be mapped to Postgres or MySQL? I mean, it's not like LINQ was around when they originally wrote MSSQL -- LINQ must use existing MSSQL features, it must have been tacked on.

You must be 1st worlder

[aled]

Governments in countries with a high level of poverty are not going to do anything that benefits the rich at the expense of the poor -- they will be deposed quicker than you can spell AK-47.

Clearly you don't live in the third world. Things are a lot more complex than that.
In general governments are very big beasts. One sector can be pro Linux and another is just buying MS because is what they use. And we are having lots of pressure from USA and other countries to introduce patents on everything, from software to GM seeds.

Why I Hate Desktop Enviroments

[nuintari]

This is why I hate Gnome and KDE. Both of them are just windows cloners, and they are dragging Linux down with them. More and more, you can't install linux without either a pile of kde or gnome libs along with it, or you end up neutering the system. I don't get it, I've read things Miguel de Icaza has said, and the man is unbelieveably in love with Microsoft, to the point that he thinks gnome and Linux need to be more like microsoft products. So, why doesn't he just run Microsoft's stuff, and stop tainting an otherwise fine OS with crap like Mono?

My god, gnome and kde have managed, over the years, to eliminate anything goo about the average linux distro, simplicity, elegance, ability to run on super old hardware, and replaced them with bloat, complexity, and insecurity, all in the name of "user friendliness." And the distro's have gone along with it, tying themselves more closely to whichever camp they deicided to align themselves to in the old gnome/kde flame wars. I got news for ya, the only people who came out clean on the other side of that shit storm were debian, slack, and the bsd's.

Sorry, if I wanted user friendly, I would run Windows. But I never expected the Linux crowd to turn their backs on their strengths in this mad quest to be more like what all you zealots claim to hate. Desktop Linux may very well end up being a Windows killer some day, and it will be just as bad in the end, if not worse.

Glad I ran off to BSD land, where I have karma to burn slamming why I went from loving, to hating linux almost overnight. Go ahead, mod me down, I said something critical.

Re:Why I Hate Desktop Enviroments

[typical]

I use FC4. I *do* use four GNOME or GTK apps most of the time -- gkrellm, firefox, xmms, and sawfish.

But these are not really bad programs. There isn't really much by way of good competition for any of these. I don't run the "GNOME Desktop", and Fedora does not force you to do so. Just create a .xsession, and have it start your window manager. Use xbindkeys to launch programs. Hey, presto -- no icons on your desktop, no GNOME bar.

Re:Why I Hate Desktop Enviroments

[shutdown -p now]

If you can't install Linux without KDE or GNOME attached (which is a 100% /dev/hands problem), I don't see how running BSD can help. Just in case you didn't notice, FreeBSD at the very least has both KDE and GNOME in Ports, and even - o, horror - Mono! Of course, it doesn't install those by default, but neither does Slackware, Debian or Gentoo; and even in SuSE, all you need to do is to untick the "KDE Desktop Environment" checkbox in the installer.

And, of course, going a bit further in proving the statement that "Mono is crap" would also help with being modded down Flamebait.

Help

[Anonymous Coward]

Please remind me why anyone would write something with .NET in the first place, when they could use Java.

Welcome to the Machine

[Anonymous Coward]

Just spend all your time on MSDN trying to keep up with the latest [marketing names for] technology, and don't look behind the curtain.

Add Java

[Anonymous Coward]

Mono is doomed as far as keeping up with MS. MS will never allow it.
Why not include Java, which is a true fully functional cross platfrm env with a creator that has a history of supporting open standards.
Yes Jav ais not open source per se, but who cares, its free and you can get the source code to it and propose changes. It boggles my mind the way the Linux comunity ignores it.

Re:Add Java

[LDoggg_]

Redhat has had an open source java stack(gcj/gij) since Fedora Core 2.

like it or not

[idlake]

Mono is here to stay and it is quickly becoming an integral part of Gnome. Technically, I think Mono with the open source Gnome APIs (but not Mono with the .NET APIs, which is an entirely different thing) is also by far the best desktop platform right now. Neither Cocoa, nor Java, nor Qt come even close in my opinion.

The worry that people have about patents is understandable on the surface, but ultimately not warranted: Microsoft only has patents on .NET (and even those don't look like they are a problem); Microsoft just has no patents on Mono with the Gnome APIs.

by "footprint" I meant memory, not disk.

[C10H14N2]

...and Mono contributes heavily to that. It has _nothing_ to do with having 10 editors and 4 browsers yadda-yadda and everything to do with a handful of components that do not necessarily benefit from being shackled to the Mono CLI.

It's about better app development and deployment

[Anonymous Coward]

I don't know what is supposedly patented in .NET, you can't patent a language or a framework, just algorithms. I was one of those negative nancies that were against Mono for a long time for that very reason. I feared developing a code base in either Mono or Java only to have Sun or MS some how pull the rug out. We do need to be careful but we also need to keep on the cutting edge of development technology.

I'm not player hating C or C++, I think they are fine tools. However as apps become larger, more complex, and more sophisticated and security and reliability become more important I think a very important tool we have has a community is to use better tools to develop them. Tools that help us make them better. We have python, perl, squeak smalltalk, ruby, a world class Ada compiler, java, ocalm, and now Csharp in the form of mono among other tools. Choosing the right tool for the job is the key. It doesn't matter how good you are, you're more likely to have bugs in C and C++ than in languages that place some more limitations on what you can do; you're more likely to have memory leaks, more likely to have buffer overflows, etc.. There aren't any silver bullets that make that stuff go away but as a community we should be open to other options. There are performance concerns and all sorts of trade offs but I think reliability and quality are becoming more and more important; I also think that with multicore CPUs being the way of the future, easily being able to thread code is a desirable feature. Every time these subjects come up there is a group that dislikes things like mono just because and we have to get over that; having high quality high-level programming environments and tools is critical if Linux is going to continue to grow. We don't want to find ourselves in 2010 focused still on writing C apps and have the rest of the world using much higher level tools, producing higher quality apps, faster, regardless of the technologies we embrace as a community.

The other half is app deployment. Python and Ruby, IMO, fit the bill quite nicely. I could easily see a large chunk of the UI for a linux desktop being written in one of those languages. There isn't much that is performance critical that would exclude them. The biggest hurdle, IMO, is app deployment. I run RPM based linuxes for the most part, about once a year I'll see an update for Python or something and that update will essentially require installing like 30% of the RPMs I have installed and usually something (it's always psycopg in my case) stops working because it wasn't an RPM initially. The GTK and GNOME support is spread across I don't know how many different libraries and packages that all may or may not need refreshing. They have the ability to import from zips in python now but app deployment is still clunky. There is no .war or .ear file like there is in java land. .NET and mono formalize the process a little bit more an they're more in the vein of "compiled" app land. I think Python could advance itself greatly if they tackled the app deployment problem. Basically, I'd like to have a zip or something with the app code and all the requirements it needs in one nice little unit, or better managed modules and a little more standardization in the modules. Perl, Python and Ruby all suffer from having the interpreter a little too tightly coupled to the app. Java really got off to a clunky start but it's much much better now, I generally expect to pull down java apps and run them without any fuss anymore, I wish I felt the same way about every perl or python script I see.

Eclipse

[roca]

Now we just need someone to take the Eclipse JDT and convert it to an equivalent toolset for C#.

Dangerous

[kaffiene]

Mono is a trojan horse. Letting it into Linux distros is BAD. We're inviting patent issues into Linux which is stupid.

Well, time to switch to Debian - I *will not* run that crap.

Re:Dangerous

[typical]

Take a look at the FAQ.

Re:Dangerous

[shutdown -p now]

FYI, Mono is in Debian unstable already, and it's not even in the non-free repository. Details.

Just for everyone's information...

[jusdisgi]

...I went ahead and drilled down 5 or 6 levels here just to make sure.

Yep.

This guy is a fucking idiot.

First he says it's so terrible that so many things depend on Python (gee...turns out people *wrote* some shit in Python) and neglects the fact that *Portage* was written in Python. When everyone jumps him about this he replies with completely unfounded hatred of Python for no adequately explained reason, and therefore concludes that nothing should be written in Python and certainly not Portage, because Python "sucks."

His suggestion appears to be that everyone should always write everything in C. I can only assume this is due to his never having written an application in C.

Nothing to see here....move along.

Sigh

[JimXugle]

About 2 moths ago, I spaired no measure avoiding my sister so I wouldn't get mono. Now I'm screwed.

Ahh Well. Better get it out of the way while I can't give blood anyway.

Mono over WINE

[Dr. Shim]

That depends on how different the new .NET framework will be for Windows Vista. Most developers I'm sure will target Vista, depending heavily on all the APIs it will offer. Mono will have to have the same functionality. I'm hoping Mono will be able to do this as flawlessly as possible. The large variety of "managed" applications that could run on both Linux and Windows would be amazing. You can even do impressive "managed" games!

Personally, I'd rather target the Mono framework rather than .NET for Common Language Infratructure applications.

Somewhat design - few implementations to judge

[SuperKendall]

It's true that more languages compile to the JVM than the CLR. However, by all accounts I've heard so far it's also true that the CLR is superior to the JVM, from design through implementation.

From teh design standpoint that was more true before Java 5, less true now... the CLR does offer some feature which help implmentation of other langauges.

However as far as implementation the only studies I've seen show .Net as kind of the middle of the pack - there are lot of Java VM's around now, some of them very highly optimized. The implmentation of a VM may not be better depending on need, and Java has a lot of debugging and monitoring hooks built in.

unrepresentative

[idlake]

Dejanews is not a representative sample of the programming population anymore, so those statistics are meaningless.

Some patents are permissively licensed

[tepples]

Does the ECMA spec (and attached licence) say anything at all about patents?

Why, yes! It appears that any Microsoft patents covering ECMA parts of .NET are permissively licensed. This permissive license does not necessarily extend to System.Windows.Forms ("winforms"), but if the Mono developers discover essential patents that encumber winforms, they'll simply suggest that developers of free software switch to Gtk#.

Re:Heh. (whew!)

[Hosiah]

Thank you, professor. I will consider myself reassured. OLE...ActiveX...DLL...boy, I forgot all about those words during these years of exclusive Linux use. That's right, there's darn near no such thing as a stand-alone MS executable...even the dangerous stuff.

Re:Heh. (whew!)

[hobbit126]

yeah. well sorry if i came off a bit angry. not trying to be smart at you...just kind of sore because i'm working on a project for windows that makes use of the activescripting stuff in .NET and had to wrap things through several layers of cruft to get it working. it's so true though. ms developemnt almost always involves a lot more than just an executable! not that linux c/c++ dev. is pain-free either. you're still dealing with .so's and a much worse dependency nightmare than windows. thankfully you can compile most libraries statically. i only wish that people would start doing this. i would trade a bit of hard-drive space for some sanity. it's on my complaint list right next to the linux directory deployment structure.

Evolution isn't a development framework, dipsh!t

[Anonymous Coward]

If you don't want to stick with a FOSS Linux-only application, then you are free to convert the data to another app/platform. No one is blowing a smokescreen of secrecy to discourage you (at least not on the FOSS end). .NET competes with Java, in a market segment called "portable frameworks". But .NET code is only portable in theory.

Cut it in half then

[SuperKendall]

And it's awfully funny how the "JVM supports 200 languages" argument continues to be raised in these discussions even though it has been shot down every time.

First of all, that list contains everything from precompilers to Java language extensions. They are not all complete languages on their own. More importantly, though, many of these languages are able to target the JVM only by first translating the code into Java source and then compiling that down to Java byte code. The compiler is not written to target the JVM directly. I take it that this the easiest route for developers that are targeting a platform that was not designed for alternate languages.

Fine, cut the list in hlaf then and it's still a order of magnitue larger.

If that's what you call "shooting down" you shoudl stop using blanks.

OTOH, the .Net common language runtime was designed to allow compiler developers to target it directly. This may seem like a minor point. If the end result is the same then the developer probably doesn't care how it's accomplished. But in an argument about the relative merits of different VMs then this is definitely a plus for .Net.

It's a large point but in the end of little significance, as you say what matters is results. In the end almost no-one uses the multi-language feature of Net - it's a bullet point on a slide somewhere. Same for Java really.

Re:Heh. (whew!)

[Hosiah]

with .so's and a much worse dependency nightmare than windows.

You do realize that Linux libraries have version numbers in the names, so that we can have like five different versions of a library to keep five different programs happy and suffer no conflict?

it's on my complaint list right next to the linux directory deployment structure.

I'm afraid you won't see that go away any time soon. We count it as one of our strongest features. Where are the library files? In the /lib directory, right where I'd expect them to be. Also, it helps with security. Which system program did the executable that I downloaded attack? None of them, because nothing in my home directory has write permissions in /sbin. Computers should be organized.

would you please answer this?

[Fuzuli]

Ok, this is no way meant to be a provocative question, i'd really like to hear your opinions. As an enterprise developer, i'd love to have a .net implementation that's cross platform. Without going into another debate, i just want to say that .net is way more productive in many ways, compared to java. But i HAVE TO use java, since it's cross platform. Not only the language, but for everything that j2ee specs point out, i can find a cross platform implementation. so, for an n tier enterpise app, the underlying os is no problem, and this is a real requirement for me. If i was not forced to present a solution that can work on any major os, with all necessary features like n tier design and such, i'd go with .net.
no matter how i like the idea, i just can't see the support and large user base for mono appearing in a near future. what can i use for an application server ? what kind of development tools will i have? anything that can match eclipse or one of the commercial development tools.?
without these, i can't go with mono. sorry but these are my requirements. if i was writing software for my own pleasure, i'd take the burdens if i wanted to, but i'm writing for other people,and i can't provide what they want with mono.

Re:The patent problems...

[Commander Spock]

There is information straight from the monkey's mouth regarding the patent issue.

You should read that information before making any comments about patent issues.

Re:Heh. (whew!)

[hobbit126]

i had a nice big entry explaining further on these points. then i noticed your constant use of the word "we" and checked your journal and other entries to see if you were also a developer and contributer to any OSS projects, linux or otherwise. i found nothing to indicate that you were, and well...everything to indicate that you were more concerned with being part of the politics, snobbery and elitism that go with being little more than a loud voice when it comes to technology. your journal headlines: Top Ten Ways to "Play Dirty" against Microsoft (honestly, who cares about microsoft?) To all the weekend-only-Slashdotters... (uh oh...not loyal to the cause!) Computers are too easy to use. (now i see why your mindset would defend the antiquated linux directory structure.) Why I Don't care If You Use Linux (because if everyone else used it, where would your false feelings of elitism be?) Time to play Slashdot Flamewar (*rolling of eyes*) There's no point in me even having a conversation with you. I actually work on these things, make positive contributions, and am in it for the neat technology, and want to see technology help people and make the world a better place for everyone. You want to use an operating system and a software license (that you have little do with) to make yourself feel better than everyone else. That is when you aren't fantasizing about keyboards biting people's heads off(???) Keep "learning" all of those languages (try to a go a bit deeper than the surface perhaps) and maybe someday you'll be able to contribute something more than sociopathic venom.

Re:Heh. (whew!)

[Hosiah]

You don't get out much, do you?

Re:Heh. (whew!)

[hobbit126]

just enough to use my mind on better things than joining the crusades as you have :)