Slashdot Mirror

They aren't very good for ANY task as far as I can see.

Doesn't sound like you can see too far, and you're not helping anyone else see any further either.

Why not contribute some actual information. Take whatever c mp3 library you used in your "tests" and get it compiling with Portable.NET's C compiler. Then benchmark it against the natively-compiled version and post the results.

If you wanted to get wild, you could even run a profiler on the results and let the pnet guys know about any particularly slow bits so they can address them.

DotGNU Homepage:
http://www.dotgnu.org/

DotGNU FAQ:
http://www.southern-storm.com.au/pnet_faq.html

We all know that Pugs does not have to target Parrot bytecode at all in order to accomplish the goal of having a Perl6 compiler. There are much simpler and better back ends available - both JIT and non-jit: Java bytecode, CIL, libjit and LLVM come to mind.

Parrot is not a very good design to put on a chip, for one single reason.

Morover parrot has opcodes which do very complicated things like "print_nc" which prints a FLOATVAL constant. Compared to that IL opcodes are simpler and JVM is still more simpler (CVM is even simpler - which is what I'm working on now).

It's an embedded chip which has a CLR on top of it. Nice idea, sorry that Sun thought of it earlier ( The Green Project) - Sun seems to be consistently missing the BUS here. They came up with "Network is the computer" and now MS is selling ".NET " :)

Microsoft dont need to port it.

Mono
Portable.NET
DotGnu

So some of the biggest groups in OSS development seem to think that it might be a good idea to have an implementation of the CLI for other operating systems (Linux, OSX, Windows, Solaris, NetBSD, FreeBSD) and architectures (x86, PowerPC, ARM, Sparc, PARISC, s390, Alpha, and IA-64 to name a few).

What you have to keep in mind is that the CLI (the virtual machine in a sense) is an ISO standard (Java still isnt). The API's such as the System.* namespaces are still in a murky area and they may still be controlled vigorously through MS legal. But that doesnt stop any developer from using API's developed independantly - ie gtk#/Wx.NET for cross platform gui across the above mentioned platforms (still in development.. but it will get there soon).

The old UNIX SYSV kernel took a whopping 54kb of memory !. I'm now running the same kernel in user space and playing around with it.

When I first saw it , I wondered how he actually typed in the C code, and then I saw the keyboard buffer code :). It'd have been fun to say, to save in ED, press Down Down , Up Left, X (Mortal Kombat memories).

Lookup Unix Version7 sources which have been ported to run on 32 Bit CPUs . With a 50k kernel binary and similarly shrunk libs , it's a nice thing to play around with.

Portable.net : Southern Storm Australia .

Are you sure TreeCC is used for Mono?

It is on the same website as Portable.NET, the C# compiler for the Dot GNU project, not Mono.

It would be nice if the open source community could take Mono and optimize for various chips and cards.

Mono's current codebase isn't very suitable for that. However, if you're interested in this kind of thing, have a look at the DotGNU project, specifically libjit.

Yes, definately.

That said, in the middle of FUD that post has some interesting claims, like impractible goals of DotGNU

I'm not sure what you mean with "impractible goals of DotGNU". Fundamentally I'd say that there are two types of goals: "essential goals" and "dreams". With an "essentail goal" I mean a goal which is essential for making the project a success; if we don't reach that goal, the project hasn't been fully successful. For DotGNU, "making it easy to port apps that were written for .NET so that they become truly portable with DotGNU Portable.NET" is an "essential goal" in this sense. With "dreams" on the other hand I mean the type of goal that would be great to achieve, but where it's not really essential to achieve it. I have lots of DotGNU-related dreams, probably most of them will never get realised, but some will, and I think there's nothing wrong with that.

Maybe you mean Miguel's statement "the DotGNU team wanted to invent a new virtual machine that supported Java and .NET at the same time"? That dream is not as impractible as it might appear at first. Read this. We do have a working runtime for IL which has been designed in such a way that there no serious obstacles (besides lack of volunteers) against adding support for JVM bytecode into this same runtime engine. Miguel criticises the JVM bytecode support as "slow, untested, and very broken"; I'm not interested in debating these claims. This JVM bytecode support is not something that we publicise as a feature; rather it's a proof of concept showing that with pnet's design it is possible to implement this, and an invitation to anyone who is interested in JVM-IL interop to come on board and work out the details.

reading Rotor code

Miguel's statement "Pnet follows a different approach: read Rotor, and do a new implementation of it" is mostly FUD. The truth of the matter is that Rhys has asked Eben Moglen, who is the General Counsel of the Free Software Foundation (and also the author of the GNU GPL and LGPL) for legal advice concering the question of whether looking at Rotor code is ok, and received the following response (posted with a bit more context in the pnet FAQ):

My advice is to tell people to code where possible from the ECMA standard. Where (which is likely to be everywhere), ECMA is insufficiently descriptive to create interoperable code, it is acceptable to read the source of the Rotor implementation. Notes taken in the course of reading that source should be made in pseudocode, so that programmers do not copy snippets of the Rotor source as aides to their memory. We want every line of code in our projects to have come out of the original invention of one of our coders, having been expressed in his or her own way. Ideas abstracted from the Rotor implementation should always have been put in our programmer's own "words," because copyright protects expressions, not ideas.

• DotGNU is part of GNU, Mono isn't. So, if you'd like to support the GNU project, that is a reason to contribute to DotGNU Portable.Net
• Learn from the better compiler architect. Rhys, the chief architect of DotGNU Portable.Net was an experienced compiler architect already before starting to work on Portable.Net; he's also the author of treecc, a great aspect-oriented tool for compiler construction.
• Choice of implementation language: Portable.Net's compilers are implemented in C, while Mono's C# compiler is implemented in C#. If you think that working on a compiler for a language is a good way to learn that language (that was Miguel's stated reason for implementing, in C#, the C# compiler project that eventually became Mono's C# compiler), maybe you should contribute to Mono.
• Do you believe in the power of large corporations? Mono is sponsored by Novell, Inc and has several people working on it full-time, and the Mono folks can afford to spend money on PR, too. That is clearly an advantage, at least for now. However, there are strong economic reasons why in the long run, platform projects that are controlled by a corporation should not be able to progress as quickly as true community projects like DotGNU or the Linux kernel. (Email me - nb AT pobox DOT com - for a draft of an economics paper on these matters.)
• The threat of patent-based attacks. There are several reasons why DotGNU is less vulnerable to patent-related threats than Mono is. First of all, the difference in licensing is relevant. Mono's libraries are licensed under an X11-style license while the DotGNU project uses GPL with a linking exception, just like Classpath. Both are Free Software, both libraries can be used from proprietary software, but Mono's licensing terms are compatible with third-party demands for patent royalties, while DotGNU's licensing terms are not compatible with that. This means that when you contribute to Mono and someone has a patent and says "pay royalties!", the result is that Mono suddenly stops being Free Software. With the kind of licensing used by the DotGNU project, patent holders cannot require the payment of royalties (because that would be incompatible with the GPL) and if they say "DotGNU must not implement that at all" that'd be an antitrust violation, rendering the patent unenforcable and hence invalid. The worst that can happen to DotGNU on the patent front is that MS might say "don't use our patented APIs", but even then MS can't stop me from still distributing the code on a public ftp server since I'm in Europe, and around here patent law isn't nearly as broken as in the US. Even in the US, if those API patents are granted and MS tries to enforce them against DotGNU, it should be only a question of time until those silly API patents of Microsoft's have been desclared invalid by a US court of law. On the other hand, Mono project leader Miguel de Icaza has stated that if MS says that a paid license from MS is required for distributing Mono code implementing those patented APIs, Novell would buy such a license. This would mean that the affected parts of Mono would stop being Free Software / open source, since it would no longer permitted to freely redistribute them without buying a license from Microsoft first. In other words, if you crontribute code to Mono's library and Microsoft says "we have a patent", Novell will give in immediately and not fight for the freedom of the code that you have contributed. DotGNU on the other hand is part of GNU, and the Free Software Foundation will fight very hard to make sure that code which you contribute remains Free Software.

I read with some concern that the Free Trade Agreement with the US will involve harmonising our intellectual property laws with the US, in particular with the Digital Millenium Copyright Act. This would be a disaster for innovation in Australia.

I refer you to the following paper, entitled "Unintended Consequences: Five Years under the DMCA" by the Electronic Frontier Foundation:

http://www.eff.org/IP/DMCA/unintended_consequences .php

This paper describes the harm that has been done in the US to free speech, scientific research, and fair use since the DMCA's introduction. Introducing a similar law here would be devastating.

My own company, Southern Storm Software, Pty Ltd, would be directly affected by such as change. At present, Australian law protects those who reverse engineer a competitor's product for the purpose of interoperation. DMCA-style laws would make me a felon solely for trying to compete fairly in my chosen market.

I urge you to please reconsider, so that Australia remains competitive in the Information Technology industry, and does not become a victim of the large Copyright interests in the US who are not interested in true and open competition.

Name and address added.

http://www.southern-storm.com.au/

Well Portable.net does seem to have a pure IL C compiler. And there was something called "Jindalee" discussed for development , which would have a Virtual Machine but still run at almost native speeds . Never worked out anyway .. nobody was interested.

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.

Of course, I want to see Win(E)Forms working on an IPaq or an OS X.... will it ever happen ?..

Also it is all about convergence eg Embedding X11 Apps -- A screenshot of GEDIT (aka Gtk apps) and KCalc (KDE app) running in a single window inside Portable.net UI Toolkits.. Hacked up... duuuh !

127 comments at this point, and a quick search showed that not one mentioned Mono! This is very surprising being as, like Wine and Samba, Mono is a project with the specific purpose of cloning an existinng Microsoft technology and making it available on other platforms. And Mono is an even greater threat than the others in the sense that Wine and Samba are Linux only while the Mono project's long term goal is to port to just about everything.

There has been a concern for some time that Mono may be on shaky ground IP-wise. Certainly MS opened the C# and IL specifications by giving it to a valid standards body (ECMA), but they did not include all (or even the majority) of the .Net libraries in the open spec. Considering that MS hold patents on some of this technology this makes it a risky situation because even a 'clean-room' clone like Mono or DotGNU Portable.NET can infringe patents, leaving them open even if no copyrights are infringed. The real problem is that, like Java, the true power of .Net lies not in the languages but in the libraries.

This is of great concern to me because of a descision I made last winter which was based, at least partly, on the existance and viability of Mono. Up to this point MS has made no moves against Mono, even providing them some back-door help upon occaision. Perhaps they are just using Mono as another nail in Java's coffin and will turn on Miguel de Icaza the minute he is of no more use to them.

However I find it difficult to believe that someone as smart as Miguel would allow himself to be used as a pawn. (Leaving me hope that he has covered his bases on this.) In the meantime the whole SCO thing can influence IP rights in two directions: In one we get a future where IP rights are king and anyone can take you down for the smallest mis-use or percieved mis-use. in the other way we get a future where IP rights are tempered with a little reality.

In my opinion one of those paths leads to doom. In the meantime, I might want to start re-thinking my plans...

Where should I send you the 200.000 usd? ooouh great master of the universe, gimme a break.

Easy - send it here or here. At least they know what they are doing and have concrete results. Their VMs can run any interpreted language you can shake a stick at. No need for Parrot at all.

First, this is a patent application, not an actual patent grant. I doubt that the application would last very long in its current form - it's too broad, even by the USPTO's narrow criteria for broadness.

Second, because Microsoft is standardizing this technology through the ECMA, as an eventual lead-in to ISO, they will be in a difficult position if they start demanding royalties or playing RAND games.

They backed off on the Kerberos thing, and they could be made to back off here too - blatantly targetting the only two competitors in the CLR space (Mono and Portable.NET) won't win them any PR points.

Third, most of what is discussed here has precedents in prior art. If Mono and Portable.NET infringe, then so does the JVM, and that's definite prior art.

We perhaps need to organise a bit to lobby on this one, but it isn't the end of the world - yet.

More information on Portable.NET here.

The features being added to Java are mainly features from C# being copied in an attempt to keep Java as popular as it has been. If one wishes to use C# with the JVM and Java class libraries, however, the GNU Portable.NET project has a compiler available.

It's called DotGNU ... It works in OS X ... not in older MacOSes.. And it's GPL'd. And it builds here as well.. (which is rare)

And I saw a fink package somewhere too....

Ximian and I18n ... that's a sick Joke

Well Ximian had no hand in mono's I18n development. From what I heard it was developed by somebody called Rhys who has his own .NET project called Portable.Net ..

But looks like Miguel is making KDE swallow some Ximian droppings .. as well as try to stick KDE with some of their bloated compiler offerings

The Alphora Dataphor DAE is the first relational database management system since IBM BS12 and the QUEL version of Postgres.

It was coded for MS .Net, thus it should be readily portable to Ximian Mono or GNUs & Southern Storms DotGNU Portable.Net.

If such a potentially useful software became publicized and free software, we could have a really innovating no Marketspeak intended , probably killer application the proprietary vendors would have a hard time scrambling after.

And that with unreprochable theoretical foundations attested by the luminars of the field.

The Alphora Dataphor DAE is the first relational database management system since IBM BS12 and the QUEL version of Postgres.

It was coded for MS .Net, thus it should be readily portable to Ximian Mono or GNUs & Southern Storms DotGNU Portable.Net.

If such a potentially useful software became publicized and free software, we could have a really innovating no Marketspeak intended , probably killer application the proprietary vendors would have a hard time scrambling after.

And that with unreprochable theoretical foundations attested by the luminars of the field.

Yes, it runs on Linux: 1, 2

niko

Hey maybe someone will put a platpus logo for Portable.NET . After all if "Mono" means Monkey , Pnet can be a Platypus.NET any day :)

But seems like it will be a Peanut (PUN intended) soon...... Please mail to make it a flying platypus !

What .NET security issues? This virus spreads via email and infects files relating to .NET which have to be executed to further infect. The .NET environment is not instrumental in the attack, you could substitute in any executable in.
.NET is not an unfeasable technology simply because it was developed by Microsoft. From what I have seen on the DotGNU Portable.NET environment on *NIX, C# bitcode is able to be executed with low overhead. You could be fooled for thinking you were executing native binaries.

This leaves DotGNU Portable.NET as the only true Free Software project tackling the implementation of the CLR, C# compiler, C# class library, etc.

http://www.southern-storm.com.au/portable_net.html .

We are looking for developers to help us build our system into a truly-Free implementation. Portable.NET has been around longer than Mono, and remains true to the principles of Free Software.

Languages that are implemented in themselves suffer from the "magic binary" problem. You have to trust a magic binary version of the compiler to bootstrap. Since inspecting binaries for trojans is hard, this gives unscrupulous individuals an avenue of attack.

Portable.NET's Web Site

...and it's Southern Storm Software, not Sourther Storm, at least judging by the URL as the site is Slashdotted.

i put pnet in the ports tree.

So, yes.

The focus of Mono and .NET is slightly different: we are writing as much as we can in a high level language like C#, and writing reusable pieces of software out of it. Portable.NET is being written in C.

Portable.NET has a different focus to Mono. Writing the compiler in C has two benefits: speed and bootstrapping. A well-crafted compiler in C will always be faster than one written in a garbage collected language, no matter how good the JIT is.

Bootstrapping is also easier with a C compiler: anyone with gcc can install Portable.NET and get it to run on their system. To bootstrap Mono, you have to have Microsoft's system installed.

There are many people who don't have Windows or don't want Windows. They then have to install the binary version of Mono. This introduces a security problem: you have to trust that the binary is correct, because you cannot guarantee that the published source matches the binary. With Portable.NET, if you trust your copy of gcc, and you can't find any backdoors in the code, you can trust your copy of Portable.NET.

In reality, it comes down to preference: I prefer to write compilers in C, because I believe that is the best language for writing compilers. Miguel has a different preference.

Rhys Weatherley - author of Portable.NET
http://www.southern-storm.com.au/portable_net.html

Sure. See Portable.NET