Slashdot Mirror

Novell, you had a good run. We shall miss you.

Novell's behind Suse, Ximian, and Mono.

I don't think they'll be going away just yet...

For this it states:

The core of the .NET Framework, and what has been patented by Microsoft falls under the ECMA/ISO submission. Jim Miller at Microsoft has made a statement on the patents covering ISO/ECMA, (he is one of the inventors listed in the patent): here [the link is incorrect -- clintp].

Basically a grant is given to anyone who want to implement those components for free and for any purpose.

The Mono project is an open source effort sponsored by Novell to create a free implementation of the .NET Development Framework.

Does anyone else find this interesting? We have Microsoft "creating" MS-DOS, Digital Research creating DR-DOS, Novell creating Novell Netware, Novell buying Digital Research, Microsoft creating Windows 95 and NT and killing DR-DOS and Novell Netware, Microsoft creating .NET and basing their new Longhorn OS on it, and Novell creating a free version of .NET specifically to run .NET apps on non-Microsoft platforms.

Can anyone guess what happens next? Anyone?

Novell, you had a good run. We shall miss you.

This project, I think, offers a small amount of comfort to businesses (think enterprise and small biz, too) who have invested exorbitant amounts of programmer-time and dollars on in-house, 'vertical applications'.

Though I'm admittedly intrigued by ReactOS' idea of shooting for NT 4.0, why pour resources into an already unsupported platform? Isn't the .NET platform, targetted already by the open source Mono project a better use of resources?

In the Mono case, we've even got a relatively good breaking point. There's enough C# in the ECMA standard (so even ignoring WinAPIs) for us to build a right good, copyright issue free (IANAL, etc) platform that'll support current and future work that leverages .NET. Instead of asking people to migrate code that runs and works on NT, which I'd argue from the company's point of view that there's no need to jostle, why not have them target new development towards the current [and optionally MS-free] platform Mono/Rotor/.NET CLR represents?

NT 4.0 isn't rusting; it still does what it's always done. The easiest way for a business to keep NT 4.0 apps running is to keep running NT 4.0, not to migrate to anything less than absolutely seamless, licensing fees included.

You can't make a successful business case to enough people using NT 4.0 to switch to an open reproduction to bother. You can, I'll wager, get people to target C#/.NET via a robust Mono with new development. To use what's lately become much too popular a metaphor, target the tip of the spear, not the shaft.

The question isn't, "Why bother creating a drop-in replacement for Windows?" but, rather, "Why bother creating a drop-in replacement for NT 4.0 instead of .NET?" Allow new development to easily target multiple platforms. If you haven't learned anything else from the lack of Linux game ports... "Targetting after the fact" is a bad idea.

(boy, sorry for the liberal use of bold there)

monoculture of their monopoly (enough monos for you?).

Not quite -- you forgot the one that might help deal with the .NET mono{culture,poly} :-)

-Stephen

I think mono is available from fink (or in the process of being made available).

There is also rotor from Microsoft, which is supposed to compile under MacOS X.

Install the .NET Framework (run Windows Update). It will install one at %WINDIR%\Microsoft.NET\Framework\v1.1.4322\csc.exe You can compile this with csc /out:DrDRMS.exe *.cs

And if you're on Linux, you can download Mono and compile with mcs DeDRMS.cs.

It's not under the LGPL, and I don't even believe that it has been put out under Microsofts Shared Source license (yet). Even the Mono implementations aren't released under the LGPL they are licensed under the MIT X11 license with exceptions. Which you can read about in the Mono FAQ at go-mono.com

Licensing

The class library is being licensed under the terms of the MIT license. This is the same license used by the X11 window system.

C# != .NET

Think Mono

Compiling:

* With MonoDevelop [1]: Open DeDRMS.cmbx and click F8.
* With mcs [2]: mcs -out:DeDRMS.exe *.cs
* With csc [3]: csc /out:DeDRMS.exe *.cs

[1] http://www.monodevelop.org
[2] http://www.go-mono.com
[3] http://msdn.microsoft.com/netframework/technologyi nfo/howtoget/

Usage:

* DeDRMS.exe file.m4p

Notes:

DeDRMS requires that you already have the user key file(s) for
your files. The user key file(s) can be generated by playing
your files with the VideoLAN Client [1][2].

DeDRMS does not remove the UserID, name and email address.
The purpose of DeDRMS is to enable Fair Use, not facilitate
copyright infringement.

[1] http://www.videolan.org/vlc/
[2] http://wiki.videolan.org/tiki-read_article.php?art icleId=5

WIthout java, Linux is doomed soon too. After all everyone and their brother will use .NET. How can you write apps to run on both platforms?

You are overlooking something, mono. For the longest time, I saw it as another pathetic attempt to follow Windows, which I still maintain is not the way to win the desktop war. However, hearing Miguel De Icaza speak at a recent Novell event, my view has changed. It's quite a mature platform with value in it's own right. It's a great way for Windows developers to migrate to Linux seamlessly. More so even than Java. As much as it may disgust certain Linux zealots to develop on a Microsoft-tainted platform, it's a viable option. And really, why is it any worse than the start button? That's hardly a Linux innovation.
Alternatives exist. I'd be sorry to see Java disappear into obscurity, but don't think it would slow the Linux community down at all, we are far to resourceful and flexible.

anonymous just cuz I already moderated this topic

Gee, that's funny, because according to the Mono project FAQ, GUI.Forms support is indeed being worked on.

Passport is important not because of it being a breakthrough technologically speaking, but because the company is in a position to drive most people toward being suscribers of it. There is already a Large list of participating sites. There are many current users of it and Microsoft will be driving more users towards Passport as it integrates it in their upcoming release of Windows. Microsoft has also developed a toolkit to enable current web merchants to integrate their services with passport. To the end user, there is a clear benefit: they only have to log into a single network and not remember multiple passwords across sites on the internet. Companies that adopt passport will have a competition advantage over those that dont.

read more at http://www.go-mono.com/passport.html

I suspect you'd like C# then. It has C/Java-like syntax, a strong OO paradigm with escape hatches for direct memory manipluation (among other things). If you don't like Microsoft, that's OK too, as the Mono project has made some serious progress in producing an open source C# / .Net platform.

Can someone point to where Microsoft has said that .NET/C# and all associated patents are royalty-free?

Jim Miller of Microsoft on the .NET patents
quote:
"But Microsoft (and our co-sponsors, Intel and Hewlett-Packard) went further and have agreed that our patents essential to implementing C# and CLI will be available on a "royalty-free and otherwise RAND" basis for this purpose."

uhh.. can I get that in writing, Jim?
I don't know about ya'll, but I'm sure as hell
not going to trust Microsoft. Especially when
they become backed into a corner by gnu/linux.

I think we need to mirror any apps developed with mono. Mirrored in a "safe" language.

see Mono's FAQ#131 from the horses mouth.
They must be _insane_ to trust Microsoft.

-metric

At least he has the balls to be in the public eye and say flat out MONO is a trap and a stupid direction for anyone involved in Gnome to consider.

Like what idiocy is next? Cloning the Longhorn API?

Seems the only way Linux can survive is play copy cat to all things Redmond.

Or so some Microsoft employee says.

C# is fine for many programs, but just TRY to implement a network protocol using it!

The managed SQL Server provider for Mono has its protocol implemented in C#. Or is that not what you meant.

Maybe C is not just dead yet ... or Miguel will not be hawking Gtk#,Gnome#... all wrappers of stuff over good old C code ... he'll be rewriting Windows.Forms in C# ... like some other fools are doing

Wake up ! ... he's just trying to sell the Mono idea to the Gnome community

Question 54: What architectures does Mono support?

Mono today ships with a Just-in-Time compiler for x86-based systems. It is tested regularly on Linux, FreeBSD and Windows (with the XP/NT core).

There is also an interpreter, which is slower that runs on the s390, SPARC and PowerPC architectures.

Interestingly, Mono's C# compiler is written in none other than C#.

On the otherside, Microsoft creats C#, sells it for a hell of a lot of money

Mono is a project that comprises many subprojects. One of those subprojects is .NET compatibility. But if that subproject were dropped from Mono, you'd still be left with a vibrant, useful project. It is therefore wrong to talk of Mono as "extending .NET" as if .NET was the foundation of everything Mono does.

Visit Mono's home page and see the first paragraph in the center of the page. Allow me to quote:

"The Mono project is an open source effort sponsored by Novell to create a free implementation of the .NET Development Framework."

I don't know why I even have to say this; it's obvious from everything about the project. Why on earth you'd want to deny it is only eclipsed by the fact that somehow you've become ABLE to deny it. No, .NET isn't the "foundation of everything Mono does"; but Mono is primarily an implementation of .NET.

-Billy

There was a project, GNOME Basic, which was going to try to create a VB-compatible language. The project has been abandoned, though. Instead, the Mono system has a VB-compatible component:

http://www.go-mono.com/mbas.html

IBM could spend a bunch of money helping to get OO.o to run Mono Basic in an Office-compatible way. That would be a longer-term strategy, though. Customers would be happier to have 100% Office compatability right away.

steveha

Why don't you just read the Mono FAQ?

but I need to know where you are going with this, and I need to now whether it is 'safe' for me (and my conscience) to use Mono and, for example, your windows forms library.

If you are writing code that needs to run primarily on Windows but that you may also want to run on Linux, use the Microsoft APIs (in that case, what's the problem with your conscience if you develop for Windows anyway?). There is a small chance that Mono will run into patent problems over their implementation of the .NET APIs, but so far, there isn't much indication of that either way. And by developing on and for Linux (as opposed to developing under Visual.NET), you'll help the quality of those API implementations on Linux.

If you are writing code that is intended primarily for OSS platforms or if you are worried about patents, use open APIs like Gtk#, Gnome, etc. They are technically better anyway. And they will work on Windows as well, it will just mean a somewhat larger download.

With dotnet the choice boils down to completely closed-source (Microsoft) or completely open-source (Mono).

Sun's half-arsed approach, cosy-up to open-source but keep Sun Java closed, has resulted in only limited attepmts to produce an open Java; why bother, since Sun seem friendly-enough?

Sun needs to start recognising dotnet as a threat and respond appropriately. Choose sides. Open or closed.

If you have been following gcj's progress recently it is maturing rapidly, just give those dirty gnu hippies a few more years they'll be on par with Sun's own implimentation.

Gcj is far more mature than mono is.

Competition is good for the software industry, good for Microsoft in particular (as Adam Smith pointed out, monopoly is a great enemy to good management), and most importantly, good for consumers. It is great for everyone when the open-source movement provides credible competition. At times, however, I do wish that all that passion, energy and skill went into something, well, a bit more useful.

The only way something like this could possibly work is if Microsoft made it their new "standard", and what are the chances of Microsoft standardising on something open and cross-platform? Pretty slim, unless they break it such that it only works properly on Windows.

Technically, that would be .NET provided you count in mono which pretty much makes .NET a cross-platform.. er.. platform. IMO, Microsoft hasn't bet the farm on this technology but it does have a good deal of momentum as standards and practices go. And you're right, it is "broken" outside win32 since mono doesn't support Windows.Forms directly. (But you can leverage wine to do this which brings us back to the article)

If you use mono and stick to the Gtk# libs you're pretty close to being cross platform for win32, linux and some unixes (virtually anywhere mono and Gtk will compile).

Its not perfect, but it works.

• mint
• mono
• monodis
• monograph
• monosn
• pedump
• mcs

You would that instead of perpetually being behind Microsoft in the current state of the libraries, that we would develop a completely new set of libraries. That way we aren't always playing catch up to what will ultimately be a windows only set of libraries.

Wrong. ASP.NET does not only run on IIS, it runs on apache with the mod_mono apache module: http://www.go-mono.com/download.html

Then take your Java library code, compile it with IKVM running on Mono, and write code in C# using it without being locked into any vendor :)

According to Netcraft: The site www.orkut.com is running Orkut's Palace of Love on Linux. Maybe they're using the Mono ASP.NET component.

According to Netcraft: The site www.orkut.com is running Orkut's Palace of Love on Linux. Maybe they're using the Mono ASP.NET component.

Then, with more and more languages, especially ones with VMs, you get further and further away from the hardware. The end result: you lose performance. It does more and more for you, but at the expense of real optimizations, the kind that only you can do.

Now the zealots will come out and say, "Language X is better than language Y, see!" To me this argument is boring. I tend to use the appropriate tool for the job. So:

• Python for scripts, prototypes, proofs of concept, or components where performance generally is not an issue.
• For desktop apps, Visual Basic (yep, most IT apps are in VB). There is no justifiable reason for an IT department group to write a sales force reporting system in C++! If you want C++, go get a job at a software company. Stop wasting money and time making yourself feel like a hotshot. [I'd consider Kylix here if it was based on Basic. Why? Because honestly, Pascal is just about dead, and Basic is the king of the simple app. Let's just live with it and move on. I do want a cross-platform VB . . . ]
• For web apps, well, I stick around PHP/ASP.NET. Why? Portability! And moreover, the sticking point in a web-based app is not the UI layer; it's usually the underlying data extraction and formatting. Don't waste your time with lower level languages there. IMHO it's just not worth it. JSP and Java stuff, yuck! Too much time for too little bang.
• Java/C# (also consider mono/LISP for most production apps. Why? Portability! I want no vendor holding me by the balls. I want platform independence on the back end, and these are the few ways to achieve it. I'd include Haskell/OCAML here when appropriate. Perl? I'm loathe to use Perl as production, considering most Perl code cannot be understood 2 weeks after it's written. I'd rather take the hit in performance and be able to pass the code to someone else later.
• C++/C for components--just components--where performance is at an absolute premium or there exists some critical library that only has this kind of interface. But this step has to be justified by the team, with considerable explanation why a different architecture could not suffice. Otherwise, the team could waste time checking for dangling pointers when instead it could be doing other things, like finishing up other projects.
• Assembly? Only when there is not a C complier around. Embedded stuff. Nowadays, you just do not have the time to play.

Yes, my teams use many languages, but they also put their effort to where they get the biggest bang for the buck. And in any business approach, that's the key goal. You don't see carpenters use saws to hammer in nails or drive screws. Wise up!

So you've not heard of the Mono c# compiler then ?

That's the one written by Ximian, which runs on Linux and Windows (and probably a lot more platforms in the future).

Have a look at VirtualPC here. (Yes, it's a MS product, but like most of their good products, they bought it from someone else.)

Mono is here.

It's called mono. Of course Microsoft forgt to mention that in their "facts".

• When you write in Gtk+, you can get an application that runs on all the platforms you listed. My gtk+ newsreader Pan runs on Linux, Windows, and Mac OSX.

• The window manager is orthogonal to the topic of what's important from the software maker's point of view: ICCCM compliance is the only feature any application writer cares about. No application requires a specific WM. To do so would needlessly limit their audience.

• Likewise, you're misinformed about Mono: nobody is telling anyone that they have to port anything to Mono. C# is just another language that Gnome supports. Never in the 4+ years I've worked on Pan has anyone mentioned porting Pan to C#.

• gtk doesn't lack documentation. In fact the documentation team has made leaps and bounds over the last year.

• If you prefer RAD tools, Anjuta and Glade are available.

• Discussing Qt as a `modern C++ based toolkit' and disparaging Gtk+ as lacking a `modern API' is just language bias (and ignores moc's pre-STL cruftiness). If you want to use gtk+ in an OO language, many language bindings are available.

Again, this isn't to take anything away from Qt -- its tools are pretty good, and its documentation is excellent. However, Gtk+ is very good too.

Hmmm, technophobes won't use the command line no matter what. Many novices do not have geek friends to show them how to use the command line. So apt-get and emerge are out of the question for mainstream acceptance.

kpackage works fine most of the time but if you get into trouble, then you will definitely need to go to the command line.

I attempted to use kpackage to install the stable version of mono on debian. It failed and mozilla was thoroughly hosed after that. I had to use dpkg to fix it. It was easier than hacking the registry but harder than shopping on Amazon.

For this purpose Ximian insisted thateveryone either contribute with an X11 license or GPL under (C) Ximian.com. Which is not wholly acceptable to FSF (who sponsors DotGNU).....

It isn't like it's a Gnome-KDE war. Portable.net has re-licensed their I18N (ie those damed CJK decoder/encoders) for use for Mono by relicensing it to X11 (to suit Miguel's "sell" aims). Portable.net has also taken some off mono, the most prominent of it will be ml-pnet , which will allow people to use Mono Libs (eg ADO.net) with Pnet. Unfortunately very few of those initiatives come from Mono end of things, maybe they don't want to attract attention to competition.

The real breaking point is the WinForms fiasco. DotGNU and Mono had formally agreed to co-operate on Winforms and Ximian officially pulled the carpet from under their Winforms project. Also what they had was a VM that ran under Wine and used MFC like it would on Win32 . Of course they were focussing mainly on Gtk# and Winforms would have affected the marketability of that. But would they do something like that ? . Failed promises and the Novell acquisition have reduced trust as now it's not one freesoftware developer to another but one corporation to a free software developer. Of course no-one wants another SCO-like copyright war.

For that you'll have to go waaaay back to the origin of the problem. Mono has a proprietary commercial plan ie Proprietary Mono Sales. I'm not saying that it's bad , but for a GNU project to turn a blind eye to that happening to its code.

For this purpose Ximian insisted thateveryone either contribute with an X11 license or GPL under (C) Ximian.com. Which is not wholly acceptable to FSF (who sponsors DotGNU).....

It isn't like it's a total war. Portable.net has re-licensed their I18N (ie those damed CJK decoder/encoders) for use for Mono by relicensing it to X11 (to suit Miguel's "sell" aims). Portable.net has also taken some GPL code off mono, the most prominent of it will be ml-pnet , which will allow people to use Mono Libs with Pnet.

Oh, I'll just wait till Novell kill's Mono and moves those developers back into Evolution integration.

Since Novell purchased us 3 months ago, we have increased our investment in all of our products, using Novell's resources. And we've been aggressive about driving open source and Linux throughout the company.

Here's a little evidence, all postdating the acquisition by Novell:

- My notes on our new desktop development center in Bangalore
- An article from the Times of India about our new developers there
- The freshly-published (today!) Mono Roadmap showing where we're going with the development platform
- The first entry in our new Evolution blog, describing the plans for Evolution 2.0, to be released early next year
- The announcement and wiki for the Brooklyn GNOME developer's summit we are sponsoring this month
- The announcement that our Exchange connector now supports Exchange 2003

And this is really just the beginning. As you can imagine, most of the super exciting stuff we are doing is behind the scenes.

From time to time since we were acquired three months ago I've heard people say things like "Novell bought Ximian just for XYZ," where XYZ has been either: Mono, our Exchange 2000 connector, GNOME, Evolution, Red Carpet, "the name," ...

I think it should be clear that this is ridiculous.

Yes, we will still support KDE on SuSE. However, we hope to use this opportunity to provide Linux developers and ISVs with a single stable platform for desktop application development.

Yes, we will keep the desktop distro free. We will even make things more free than they have been.

We're only just getting started. Stay tuned.

Well it is great that Novell has embraced linux big time but whether it is late or not is yet to be seen. Recent SCO drama does not seem to have affected Novell's plans, which is good since it shows positive signs that they are not too concerned about SCO lawsuits. One thing Novell should do is to make sure that they continue devlopment on Mono. Why? because this may encourage more developers to work on it which means more application for Unix/Linux. Remember that Windows is not the reason people still use it but it is because of the application which run on it .It also makes the life of the developer easy since maintaining two versions of source code is huge headache.

would not doubt that the dotnet runtime on Longhorn is not going to call the Win32 API much; They might just be doing it internally and only using the Executive (NT/2K/XP's kernel native API) when necessary.

I can't wait for that to happen. Would make Mono's job that much easier. Of course, for the same reason I rather fear for its political survival...

Maybe you want to take a look a mono.

One of Mono's sub-projects is to port VB.NET. It seems it is not very actively worked on at the moment, though...

at least, not without an equally comprehensive yet-to-appear WINE layer

Even without full-blown portability between .NET and Mono, some useful libraries have already been written that are usable on both platforms - RSS.NET is being used by both GTK#RSS, a Mono/GTK# news feed reader and Monologue, Mono's blog aggregator, in addition to having its own .NET RSS client.

Portability is good :)

by calling Microsoft's "C# Open Standard" bluff, Mono has thrown a huge monkey-wrench into Microsoft's plans.
I strongly disagree. Microsoft is well aware of the open-source community's skill at developing compilers. There are open-source compilers for more languages than you can shake a stick at. To assume that Microsoft didn't think anyone would develop a compiler for C# is incredulous. Rather, I expect they planned on it.

Fear #1: Microsoft will change the APIs/protocols
Why not? They have a long history of it: DirectX is on version 9!

Fear #2: Microsoft will attack Mono with patents
The Mono FAQ says it isn't patentable, but when you ask Microsoft ... A quote from "Microsoft and Patents":
In 2002/03 Steve Ballmer, CEO of Microsoft, declared that Microsoft's new standard DotNet was protected by patents and free implementations would not be allowed.
In 2003/04 Microsoft published patent license terms for CIFS which disallow the use ore reimplementation of this communication architecture by GNU software.
In late 2002, Microsoft began dissuade corproporate customers from introducing GNU/Linux by pointing out that if they use free software nobody would protect them from being sued for patent infringement.

This difference in interpretation means this will be an issue in the future.

Fear #3: Mono will be continually chasing Microsoft's tail
MS doesn't care what Mono does, just as long as it quietly voilates (or even just appears to violate) one of Microsoft's patents. For example, even though the SCO lawsuit is completely bogus, it is costing MS's enemies valuable time and money. A .Net lawsuit could do the same thing -- and I personally believe the SCO lawsuit is a "proof of concept".

Mono will soon be protecting us from a .Net monopoly
To be perfectly honest, I'd really like to think so. However, if you think MS is going to stand idly by while Mono does what Samba, Mozilla, and PHP have already done, you grossly underestimate their cunning. I have a strong feeling that this time, MS is prepared and their weapon of choice will be the patent.

That is, unless we ... commit suicide by stopping work on Mono now.
Damned if we do, damned if we don't. Microsoft has done their homework on this one.

Link: MS patents .Everything