No, it means that some of the dependency libraries (Gtk in this case) are native applications an not CIL applications, so you need to have the.so files in Linux compiled with C or the.dll files in Windows compiled with C.
The menu reorganization was actually something that we took quite seriously. The issue that we were facing was that the contents of the menus on the default configuration of Gnome was hard to use, and the organization was the remainings of the work that had been done many years before.
So we actually conducted usability tests on real users to try out Gnome, and perform a number of tasks. We observed them, we interviewed them, and we made changes to the software to reflect the needs of users.
Our intention is to allow Linux to be used as a desktop solution.
We tried our best to make it easy for newcomers, and am sorry to hear that you disagree. But at least you could use this experience to advise new users: depending on their needs maybe Ximian is right for them, or maybe not.
Anyways, you can file a bug report against the problems that you found on bugzilla.ximian.com, they might be worth following up.
The.NET Framework is actually a new platform for software development, and incorporates many ideas that have been floating around before.
The.NET Framework includes basically three components: programming languages, a common language runtime and a set of class libraries for acomplishing various kinds of tasks.
The framework was designed so multiple programming languages could share the same set of class libraries with minimal effort, and also to allow a large set of programming languages to work together rather than having each one create its own "micro platform".
Now, the.NET Framework offers a couple of ways of doing distributed computing with RPC calls: one is called the Remoting framework and the other one is called Web Services (its not exactly like this, but for now this will work).
Remoting is the closest thing to a CORBA replacement, but its not a great replacement. I personally like CORBA more for plenty of reasons that I hope one day I will write down.
Web Services is the "in" thing to do today, so the.NET Framework has some tools as well for making it easy for developers to write client and server applications using the web services protocols.
Another things that.NET does is it simplifies the development of COM components and the use of COM components (there is plenty of literature on this subject on msdn.microsoft.com).
Most COM developers I have talked to claim that.NET makes them more productive. You wont loose a lot by trying it out, you can always go back to your current tool set if you do not like.NET.
The "contract" for language interoperability is called the Common Language Specification (CLS) and furthermore, languages are divided in CLS producers, consumers and consumer/producers.
You can think of the "CLS" as a richer contract than say the CORBA IDL or the COM IDL: they define APIs. Now on top there is a virtual machine that allows you to run either native code or "CIL" code that executes on the common runtime.
There are plenty of CIL compilers (C, C++, C#, JavaScript, Fortran, Cobol, Eiffel, Ada, VB, Haskell) that can produce/consume CLS code.
It is great if your language can produce and consume CLS classes, but its also good it it can consume them, because then a large body of code is available to you.
Software developed with Gtk# will run on Windows, you only need to install Gtk# in Windows as well.
(I heard today on the irc channel for mono (irc.gnome.org, channel #mono) that the upcoming 0.6 release of Gtk# will distribute all the files you need for running on Windows as well).
Well, having ASP.NET is very convenient to move applications and components from Windows and deploy them on Linux or Unix systems. So I think that this is a plus on its own.
In terms of choices, I have to admit that I personally am more of an old school strongly-typed kind of person, and I like programming more with a language that I understand like C#. There is nothing wrong with PHP or Perl, but I feel a bit insecure with them. Like when you have to order water in a restaurant, and you do not want to look cheap, so you end up asking for `bottled water' even when you are trying to not spend a lot of money [1].
Mono and.NET offer a very interesting crossroads: the possibility of sharing components and existing classes independently of the language that was used to create it.
I strongly believe that scripting languages are great for quickly building web solutions, and I would love to see more work between the PHP (and other scripting communities) and Mono. We are certainly interested in helping out.
For instance, the Mono runtime is easily embeddable, it could be used in existing systems with ease: for example, allow any language but use the PHP API to write web pages is one option (check the link for a few more samples and the tutorials), or hosting any programming language on Apache (as its done with the Apache/Mono module mod_haydn.
Miguel.
[1] Although as you grow older, you become more cynical, and you just tell the waiter `Get me a glass of the cheapest form of water you have'.
The volume of database providers in this release is the work of very few but very active hackers: Brian, Dan, Rodrigo, Tim and Ville. It is amazing the amount of code that these hackers pulled in the last two months.
It is easy to know when the System.Data hackers are working, your inbox gets hammered with patches from the mono-patches list.
You can help us support DB2, but you will have to get your hands dirty and start coding like the crazy hackers that brought all these providers (and Reggie has agreed to contribute his optimized provider as well).
An old version of the VB compiler is included in the release, but we did not have time to integrate the new VB compiler patches from Marco, but hopefully those will make it into the next release. There are screenshots of it in windows and with Gtk#.
SharpDevelop does require Windows.Forms, if you are interested in getting this superb development environment running on Linux with Mono (it includes Intellisense), you could help with the Windows.Forms porting effort
Mono today works on LinuxPPC in interpreted mode, but does not work on MacOS X since the calling conventions are not the same.
We started work three months ago on a new JIT engine whose main aim was portability (although the current JIT can be ported, most optimizations and coarse-opcodes had to be reimplemented over and over). The new JIT engine design has two intermediate level representations: a higher level one, and a low-level that can be as precise as required for a target CPU. The funny thing is that the new JIT is actually faster JITing code than the current JIT even with the added layer.
The lower-level layer is actually something we are very proud of, Paolo architected a register allocator and instruction scheduler at the same stage, and we are using the PowerPC on MacOS X as the second platform to target to guarantee this time that the JIT is actually easy to port.
We are hoping to release the new JIT engine in February/March.
People are working hard to get Windows.Forms to work. We initially planned to have a Gtk backend, but turns out that Windows.Forms sadly exposes bits from the Win32 API that would be very hard to emulate (or at least terribly painful to debug).
The major problem is the Control.Wndproc method which effectively allows any control to hook up to the Windows message system. This is not a problem for most applications, but many special "effects" in widgets are created by hooking up here and processing the messages here.
To avoid emulating Win32 ourselves, we chose to use WineLib as the foundation for implementing Windows.Forms. Later to match the native look of the linux desktop we will provide the Wine team with patches to use the Gtk rendering engine on Unix and the Cocoa rendering engine on MacOS.
Far from ideal, but its the only way we can guarantee good portability with minimal pain to the developers.
There is now a new momentum to get this work moving, and given that it is possible today to test the various controls in Windows against the real implementation, you do not have to fight the incomplete Windows.Forms code before testing your code.
More details: http://www.go-mono.com/winforms.html (for the Windows.Forms plans and mailing lists)
Greg Palast is an investigative reporter that researches and goes deep into various issues (he broke the news on the Florida ballot cleaning in 2000). The book covers a number of interesting topics from Enron and its alliances to the government and how they got preferential treatment and how they used this in the US and abroad to their advantage.
A few months ago, someone told me `Remember: all governments lie', which I figured, seems pretty acurrate, but not much to debate over dinner in that topic. I think there is a tacit agreement that governments lie.
The shocking news came from reading Daniel Ellsberg's Secrets book in which he details how five consecutive adminisrtrations lied to congress, and lie to the american people about what they were doing in Vietnam. An interesting interview with Daniel Ellsberg in Salon (here) gives a quick overview of the book. For those who do not know, Daniel took some secret documents from the government in the 70's and got them published by the New York Times. The documents exposed the lies from the five administrations. Although the government tried to stop the publication of the documents (known from then on as "The Pentagon Papers", google found this which gives you some context, as well as the history around the event).
So anyways, the short story is that democracy needs to be revamped with new technology. Hundreds of years ago it was perfectly possible to elect a leader/representative, trust him to do what he promised on behalf of the voters and revisit the issue on an upcoming election.
But today's leader's loyalty is not to the voters, but to those who allow them to get the votes, people with enough funds to drive the agenda in any direction they please. Greg Palast's book points out that the current administration unlike previous administrations no longer has to deal with external lobbysts, the lobby now has got offices right in the White House (he goes on detail about the Enron's hand-picked policy makers and those who reverted Clinton's decisions regarding Enron's involvement in California).
With the technology available today, democracy could be referendum-based, through electronic voting on key issues.
dare, I do not agree with your assumptions, and hence with your conclussion.
Linux is just starting to make inroads in the enterprise and critical application markets, say it became useful in 2001. This is the area that has been dominated by Unix since 1986. So it took us "only" 16 years to duplicate the enterprise functionality of a Unix operating system.
Sometimes copying is easier than innovating: but achieving total compatibility -which can not be ignored- is a massive task. Wine has been cloning the Win32 API, and it is one of the most ancient projects from the Linux community: it was there back in 1996, and we have still not managed to clone the entire Win32 API. Yes, copying certain things are easy, but achieving the compatibility is a completely different matter.
Am going to give you another example which must be closer to you: the Xml implementation in.NET features state of the art innovations for large XML document handling, and in Mono we will have an extremely hard time implementing your XPathNavigator-based XSLT. Even with reference implementations (like Daniel Veillard's), this is a truly advanced piece of code. We can emulate it using slower, more inneficient mechanisms, but we wont be able to perform as well as Microsoft's.NET XML implementation.
I rather see Microsoft stay on the innovation track, than go into a legal battle against Open Source projects.
Proprietary software has some advantanges, and open source has different ones. Open Source is making some inroads into a Microsoft-dominated world. And I do not see anything wrong with having more than one operating system in our day to day environments: it promotes open standards, it promotes well written and well documented reliable solutions, and ultimately, it allows the consumer to choose a solution that is right for him.
Miguel
Re:How usably is Mono atm?
on
KDE Adopting Mono
·
· Score: 3, Informative
http://haydn.sf.net is your embedding into apache.
You can already embed ASP.NET in there (or if you werea the O'Reilly conference, you could have seen ASP.NET embedded into Gnumeric).
Mono self-sustains, so that means that we can compile it with itself (the compiler and class libraries are written in C#). So you could say that for compiler work it is already usable;-)))
Other than that, it depends on the particular class libraries that you are looking for.
I am pretty excited by the work that Adam has been doing with the Qt# bindings as well as the work of Mike and Rachel on the Gtk# bindings, they bring the toolkits to the.NET framework and to Mono.
People building Gtk# apps and Qt# apps will be able to share components written for Mono and the.NET framework easily.
So even if Gnome and KDE can not share a lot of code currently because of the two divergining code bases, in the future we will be able to exchange code and chunks of it more easily.
For instance, Adam is working on a documentation system for Mono written in Qt# and some of his code will be reused for a web-based version of the documentation system, and perhaps a Gtk# version of the documentation system.
I remember the migration from ".ARC" to ".ZIP" a few years ago, it happened very quickly, and was surprised it actually had happened.
The same thing can be said about the.Z to.z (and later renamed to.gz) transitions. Eventually freedom concerns took place, and the migrations happened.
On the other hand, you have gif, and we never quit got rid of it, but the good side is that we got a nice, better format in the meantime that is wildely used (png).
I am confident ogg will happen, and I am waiting for cheap hardware decoders to exist.
The interview was done long before I posted those messages to the mono-list. After the interview I looked at the problem in more depth, and focused on the current strategy.
I fail to have my entire life planned in advance, so I have to make changes as I go, sorry if this annoys you;-)
Portable.NET and Mono are doing the same things. Mono is a lot more advanced than Portable.NET: JIT, a working compiler, large development team.
About the `other_stuff', I have never been able to figure out what it is, or what they are doing.
It is a duplicated effort as you very well point out. From the Ximian perspective, we did have the resources to work on this project, and we had our developers work on it.
I am not aware of the IE-isms in ASP.NET, but maybe they are there.
That being said, I would like the Mono version of ASP.NET to eventually use the SOAP functionality from JavaScript in IE and Mozilla to avoid reloading the entire page whenever possible (only some controls allow this).
Also, you could make things different if you contribute to the ASP.NET effort in Mono, we are rendering quite a few pages already.
But we are planning on staying compatible with their class libraries and not make changes, for the sake of users, developers and customers.
That being said, we also encourage people to create new technologies and new classes and innovative things in their own class libraries. For instance Vorbis# (mostly done by Mark) and Gtk# (mostly done by Mike and Rachel) are extensions that originated in the Mono world.
You really want your new classes/assemblies to work on both Windows and Unix, because that gives you a larger user base.
Well,.NET 1.0 was released on January, so by that metric Mono is already late to the game. But so is every other piece of free software, and we still manage to do a great job.
Developers in the Windows world that do not care about cross platform issues (which is, 99% of them) are tired of C++, and Visual Basic, and C# happens to be a nice language to move to delivered by the company that does their OS.
So people will be adopting C# as a programming language no matter what anyone does. The language is here, and the tools are here, and the community is rapidly growing.
So what we are enabling is to bring a number of things to Linux: we bring the people, the knowledge and we are reusing Microsoft's investment in documenting, promoting and producing training materials to benefit us.
So, I am fairly possitive that this is good.
And then, there is the added advantage of open source: now you got a compiler, a runtime and classes. If they serve your purposes, take it, improve it, extend it, change it, modify it, rip it, research, reuse what you feel like reusing.
Well, when the Linux movement began it started putting together tools from various sources. GNU tools played an important role, but many things were missing and those were created.
During these initial phases of the history of Linux,/sbin/fdisk, the boot loader assembler code, and even tools to customize your boot device were as important or even more than the userland tools.
The community that sprung out of the "kernel" went beyond hacking on the kernel: they assembled the operating system from the pieces they found, and they created the missing pieces that were missing.
To those people, "Linux" was the operating system. The fact that the kernel came in the shape of a tarball called linux-0.99.5pl5.tar.gz was just a mere interesting data point.
People created distributions, and called those in whatever way they saw fit. Some were called `Soft Landing System for Linux', others later were branded as the universities or organizations that created them.
Yes, they happen to match the definition that RMS had for GNU: a set of free tools.
Giving credit to GNU is fine, and raising up the issues of freedom is something we should be involved in doing every day. But boycotting presentations and pressuring for renaming things the GNU way is pointless.
This is like ESR saying `Any Linux used to read mail with mutt and fetch-mail should be called a Mail/Linux station'. Well, it is fine that it matches ESR's definition, but pushing for this is not a bit silly, but using the harsher RMS methods of pushing GNU is just a slap in the face.
Some time ago, he asked us if Mono was part of the GNU project. Mono was free and was under one of the FSF approved licenses. The breaking point was that we should refer to Linux as GNU/Linux in our marketing materials. Thats when Mono stopped being part of "GNU".
I could not take the GNU rebranding stuff anymore. It happened gradually: RMS first started to check on me when I did not say GNU/Linux. Then later he asked me to mail reporters to change things to GNU/Linux, and then to verify I had done it, to forward him reporter's reply.
I am interested in developing free software, and making more software available to the people. And I try to bring up the benefits that opensource/freesoftware brings to an organization depending on their needs. They are old enough that if they have an interest in learning the antropolgy of the system they can learn where the origins are. My mission in life is not to first dump the political agenda and then move on to why the code I have written is interesting/appealing to the people I talk to.
Long time collaborators like Ulrich Drepper have been driven away by RMS and this policy.
Slashdot Mirror
No, it means that some of the dependency libraries (Gtk in this case) are native applications an not CIL applications, so you need to have the .so files in Linux compiled with C or the .dll files in Windows compiled with C.
Yes, I can explain.
The menu reorganization was actually something that we took quite seriously. The issue that we were facing was that the contents of the menus on the default configuration of Gnome was hard to use, and the organization was the remainings of the work that had been done many years before.
So we actually conducted usability tests on real users to try out Gnome, and perform a number of tasks. We observed them, we interviewed them, and we made changes to the software to reflect the needs of users.
Our intention is to allow Linux to be used as a desktop solution.
We tried our best to make it easy for newcomers, and am sorry to hear that you disagree. But at least you could use this experience to advise new users: depending on their needs maybe Ximian is right for them, or maybe not.
Anyways, you can file a bug report against the problems that you found on bugzilla.ximian.com, they might be worth following up.
Miguel.
I am going to try.
.NET Framework is actually a new platform for software development, and incorporates many ideas that have been floating around before.
.NET Framework includes basically three components: programming languages, a common language runtime and a set of class libraries for acomplishing various kinds of tasks.
.NET Framework offers a couple of ways of doing distributed computing with RPC calls: one is called the Remoting framework and the other one is called Web Services (its not exactly like this, but for now this will work).
.NET Framework has some tools as well for making it easy for developers to write client and server applications using the web services protocols.
.NET does is it simplifies the development of COM components and the use of COM components (there is plenty of literature on this subject on msdn.microsoft.com).
.NET makes them more productive. You wont loose a lot by trying it out, you can always go back to your current tool set if you do not like .NET.
The
The
The framework was designed so multiple programming languages could share the same set of class libraries with minimal effort, and also to allow a large set of programming languages to work together rather than having each one create its own "micro platform".
Now, the
Remoting is the closest thing to a CORBA replacement, but its not a great replacement. I personally like CORBA more for plenty of reasons that I hope one day I will write down.
Web Services is the "in" thing to do today, so the
Another things that
Most COM developers I have talked to claim that
Miguel
The "contract" for language interoperability is called the Common Language Specification (CLS) and furthermore, languages are divided in CLS producers, consumers and consumer/producers.
You can think of the "CLS" as a richer contract than say the CORBA IDL or the COM IDL: they define APIs. Now on top there is a virtual machine that allows you to run either native code or "CIL" code that executes on the common runtime.
There are plenty of CIL compilers (C, C++, C#, JavaScript, Fortran, Cobol, Eiffel, Ada, VB, Haskell) that can produce/consume CLS code.
It is great if your language can produce and consume CLS classes, but its also good it it can consume them, because then a large body of code is available to you.
Miguel.
Software developed with Gtk# will run on Windows, you only need to install Gtk# in Windows as well .
(I heard today on the irc channel for mono (irc.gnome.org, channel #mono) that the upcoming 0.6 release of Gtk# will distribute all the files you need for running on Windows as well).
Well, having ASP.NET is very convenient to move applications and components from Windows and deploy them on Linux or Unix systems. So I think that this is a plus on its own.
.NET offer a very interesting crossroads: the possibility of sharing components and existing classes independently of the language that was used to create it.
In terms of choices, I have to admit that I personally am more of an old school strongly-typed kind of person, and I like programming more with a language that I understand like C#. There is nothing wrong with PHP or Perl, but I feel a bit insecure with them. Like when you have to order water in a restaurant, and you do not want to look cheap, so you end up asking for `bottled water' even when you are trying to not spend a lot of money [1].
Mono and
I strongly believe that scripting languages are great for quickly building web solutions, and I would love to see more work between the PHP (and other scripting communities) and Mono. We are certainly interested in helping out.
For instance, the Mono runtime is easily embeddable, it could be used in existing systems with ease: for example, allow any language but use the PHP API to write web pages is one option (check the link for a few more samples and the tutorials), or hosting any programming language on Apache (as its done with the Apache/Mono module mod_haydn.
Miguel.
[1] Although as you grow older, you become more cynical, and you just tell the waiter `Get me a glass of the cheapest form of water you have'.
The volume of database providers in this release is the work of very few but very active hackers: Brian, Dan, Rodrigo, Tim and Ville. It is amazing the amount of code that these hackers pulled in the last two months.
It is easy to know when the System.Data hackers are working, your inbox gets hammered with patches from the mono-patches list.
You can help us support DB2, but you will have to get your hands dirty and start coding like the crazy hackers that brought all these providers (and Reggie has agreed to contribute his optimized provider as well).
An old version of the VB compiler is included in the release, but we did not have time to integrate the new VB compiler patches from Marco, but hopefully those will make it into the next release. There are screenshots of it in windows and with Gtk#.
SharpDevelop does require Windows.Forms, if you are interested in getting this superb development environment running on Linux with Mono (it includes Intellisense), you could help with the Windows.Forms porting effort
Miguel.
Mono today works on LinuxPPC in interpreted mode, but does not work on MacOS X since the calling conventions are not the same.
We started work three months ago on a new JIT engine whose main aim was portability (although the current JIT can be ported, most optimizations and coarse-opcodes had to be reimplemented over and over). The new JIT engine design has two intermediate level representations: a higher level one, and a low-level that can be as precise as required for a target CPU. The funny thing is that the new JIT is actually faster JITing code than the current JIT even with the added layer.
The lower-level layer is actually something we are very proud of, Paolo architected a register allocator and instruction scheduler at the same stage, and we are using the PowerPC on MacOS X as the second platform to target to guarantee this time that the JIT is actually easy to port.
We are hoping to release the new JIT engine in February/March.
People are working hard to get Windows.Forms to work. We initially planned to have a Gtk backend, but turns out that Windows.Forms sadly exposes bits from the Win32 API that would be very hard to emulate (or at least terribly painful to debug).
The major problem is the Control.Wndproc method which effectively allows any control to hook up to the Windows message system. This is not a problem for most applications, but many special "effects" in widgets are created by hooking up here and processing the messages here.
To avoid emulating Win32 ourselves, we chose to use WineLib as the foundation for implementing Windows.Forms. Later to match the native look of the linux desktop we will provide the Wine team with patches to use the Gtk rendering engine on Unix and the Cocoa rendering engine on MacOS.
Far from ideal, but its the only way we can guarantee good portability with minimal pain to the developers.
There is now a new momentum to get this work moving, and given that it is possible today to test the various controls in Windows against the real implementation, you do not have to fight the incomplete Windows.Forms code before testing your code.
More details: http://www.go-mono.com/winforms.html (for the Windows.Forms plans and mailing lists)
Miguel
As sad as this is, it is not a new thing. I recently have been reading Greg Palast's book The Best Democracy Money can Buy. A fascinating reading.
Greg Palast is an investigative reporter that researches and goes deep into various issues (he broke the news on the Florida ballot cleaning in 2000). The book covers a number of interesting topics from Enron and its alliances to the government and how they got preferential treatment and how they used this in the US and abroad to their advantage.
A few months ago, someone told me `Remember: all governments lie', which I figured, seems pretty acurrate, but not much to debate over dinner in that topic. I think there is a tacit agreement that governments lie.
The shocking news came from reading Daniel Ellsberg's Secrets book in which he details how five consecutive adminisrtrations lied to congress, and lie to the american people about what they were doing in Vietnam. An interesting interview with Daniel Ellsberg in Salon (here) gives a quick overview of the book. For those who do not know, Daniel took some secret documents from the government in the 70's and got them published by the New York Times. The documents exposed the lies from the five administrations. Although the government tried to stop the publication of the documents (known from then on as "The Pentagon Papers", google found this which gives you some context, as well as the history around the event).
So anyways, the short story is that democracy needs to be revamped with new technology. Hundreds of years ago it was perfectly possible to elect a leader/representative, trust him to do what he promised on behalf of the voters and revisit the issue on an upcoming election.
But today's leader's loyalty is not to the voters, but to those who allow them to get the votes, people with enough funds to drive the agenda in any direction they please. Greg Palast's book points out that the current administration unlike previous administrations no longer has to deal with external lobbysts, the lobby now has got offices right in the White House (he goes on detail about the Enron's hand-picked policy makers and those who reverted Clinton's decisions regarding Enron's involvement in California).
With the technology available today, democracy could be referendum-based, through electronic voting on key issues.
Miguel.
dare, I do not agree with your assumptions, and hence with your conclussion.
.NET features state of the art innovations for large XML document handling, and in Mono we will have an extremely hard time implementing your XPathNavigator-based XSLT. Even with reference implementations (like Daniel Veillard's), this is a truly advanced piece of code. We can emulate it using slower, more inneficient mechanisms, but we wont be able to perform as well as Microsoft's .NET XML implementation.
Linux is just starting to make inroads in the enterprise and critical application markets, say it became useful in 2001. This is the area that has been dominated by Unix since 1986. So it took us "only" 16 years to duplicate the enterprise functionality of a Unix operating system.
Sometimes copying is easier than innovating: but achieving total compatibility -which can not be ignored- is a massive task. Wine has been cloning the Win32 API, and it is one of the most ancient projects from the Linux community: it was there back in 1996, and we have still not managed to clone the entire Win32 API. Yes, copying certain things are easy, but achieving the compatibility is a completely different matter.
Am going to give you another example which must be closer to you: the Xml implementation in
I rather see Microsoft stay on the innovation track, than go into a legal battle against Open Source projects.
Proprietary software has some advantanges, and open source has different ones. Open Source is making some inroads into a Microsoft-dominated world. And I do not see anything wrong with having more than one operating system in our day to day environments: it promotes open standards, it promotes well written and well documented reliable solutions, and ultimately, it allows the consumer to choose a solution that is right for him.
Miguel
http://haydn.sf.net is your embedding into apache.
;-)))
You can already embed ASP.NET in there (or if you werea the O'Reilly conference, you could have seen ASP.NET embedded into Gnumeric).
Mono self-sustains, so that means that we can compile it with itself (the compiler and class libraries are written in C#). So you could say that for compiler work it is already usable
Other than that, it depends on the particular class libraries that you are looking for.
I am pretty excited by the work that Adam has been doing with the Qt# bindings as well as the work of Mike and Rachel on the Gtk# bindings, they bring the toolkits to the .NET framework and to Mono.
.NET framework easily.
People building Gtk# apps and Qt# apps will be able to share components written for Mono and the
So even if Gnome and KDE can not share a lot of code currently because of the two divergining code bases, in the future we will be able to exchange code and chunks of it more easily.
For instance, Adam is working on a documentation system for Mono written in Qt# and some of his code will be reused for a web-based version of the documentation system, and perhaps a Gtk# version of the documentation system.
Miguel
I remember the migration from ".ARC" to ".ZIP" a few years ago, it happened very quickly, and was surprised it actually had happened.
.Z to .z (and later renamed to .gz) transitions. Eventually freedom concerns took place, and the migrations happened.
The same thing can be said about the
On the other hand, you have gif, and we never quit got rid of it, but the good side is that we got a nice, better format in the meantime that is wildely used (png).
I am confident ogg will happen, and I am waiting for cheap hardware decoders to exist.
Miguel.
The interview was done long before I posted those messages to the mono-list. After the interview I looked at the problem in more depth, and focused on the current strategy.
;-)
I fail to have my entire life planned in advance, so I have to make changes as I go, sorry if this annoys you
DotGNU is = Portable.NET + other_stuff.
Portable.NET and Mono are doing the same things. Mono is a lot more advanced than Portable.NET: JIT, a working compiler, large development team.
About the `other_stuff', I have never been able to figure out what it is, or what they are doing.
It is a duplicated effort as you very well point out. From the Ximian perspective, we did have the resources to work on this project, and we had our developers work on it.
People said the same thing about Linux a few years ago, so this comment has no effect on me ;-)
Love and Peace
Miguel.
I am not aware of the IE-isms in ASP.NET, but maybe they are there.
That being said, I would like the Mono version of ASP.NET to eventually use the SOAP functionality from JavaScript in IE and Mozilla to avoid reloading the entire page whenever possible (only some controls allow this).
Also, you could make things different if you contribute to the ASP.NET effort in Mono, we are rendering quite a few pages already.
Miguel
Yes ;-)
But we are planning on staying compatible with their class libraries and not make changes, for the sake of users, developers and customers.
That being said, we also encourage people to create new technologies and new classes and innovative things in their own class libraries. For instance Vorbis# (mostly done by Mark) and Gtk# (mostly done by Mike and Rachel) are extensions that originated in the Mono world.
You really want your new classes/assemblies to work on both Windows and Unix, because that gives you a larger user base.
Miguel
We are not planning ourselves on writing one, but several people have expressed their interest on doing so.
There is already a proof that this can be done (Microsoft's JUMP), but it is not fundamentally a hard problem either.
There are three groups of people to my knowledge working on free software versions of such a tool.
Miguel
Well, .NET 1.0 was released on January, so by that metric Mono is already late to the game. But so is every other piece of free software, and we still manage to do a great job.
Miguel
Developers in the Windows world that do not care about cross platform issues (which is, 99% of them) are tired of C++, and Visual Basic, and C# happens to be a nice language to move to delivered by the company that does their OS.
So people will be adopting C# as a programming language no matter what anyone does. The language is here, and the tools are here, and the community is rapidly growing.
So what we are enabling is to bring a number of things to Linux: we bring the people, the knowledge and we are reusing Microsoft's investment in documenting, promoting and producing training materials to benefit us.
So, I am fairly possitive that this is good.
And then, there is the added advantage of open source: now you got a compiler, a runtime and classes. If they serve your purposes, take it, improve it, extend it, change it, modify it, rip it, research, reuse what you feel like reusing.
Miguel
Actually, some new tools probably do not even use the GNU libc because it is so big.
;-)
That being said, any code that Ulrich has contributed to GNU libc is not part of GNU, but part of the package
miguel
Well, when the Linux movement began it started putting together tools from various sources. GNU tools played an important role, but many things were missing and those were created.
/sbin/fdisk, the boot loader assembler code, and even tools to customize your boot device were as important or even more than the userland tools.
During these initial phases of the history of Linux,
The community that sprung out of the "kernel" went beyond hacking on the kernel: they assembled the operating system from the pieces they found, and they created the missing pieces that were missing.
To those people, "Linux" was the operating system. The fact that the kernel came in the shape of a tarball called linux-0.99.5pl5.tar.gz was just a mere interesting data point.
People created distributions, and called those in whatever way they saw fit. Some were called `Soft Landing System for Linux', others later were branded as the universities or organizations that created them.
Yes, they happen to match the definition that RMS had for GNU: a set of free tools.
Giving credit to GNU is fine, and raising up the issues of freedom is something we should be involved in doing every day. But boycotting presentations and pressuring for renaming things the GNU way is pointless.
This is like ESR saying `Any Linux used to read mail with mutt and fetch-mail should be called a Mail/Linux station'. Well, it is fine that it matches ESR's definition, but pushing for this is not a bit silly, but using the harsher RMS methods of pushing GNU is just a slap in the face.
Some time ago, he asked us if Mono was part of the GNU project. Mono was free and was under one of the FSF approved licenses. The breaking point was that we should refer to Linux as GNU/Linux in our marketing materials. Thats when Mono stopped being part of "GNU".
I could not take the GNU rebranding stuff anymore. It happened gradually: RMS first started to check on me when I did not say GNU/Linux. Then later he asked me to mail reporters to change things to GNU/Linux, and then to verify I had done it, to forward him reporter's reply.
I am interested in developing free software, and making more software available to the people. And I try to bring up the benefits that opensource/freesoftware brings to an organization depending on their needs. They are old enough that if they have an interest in learning the antropolgy of the system they can learn where the origins are. My mission in life is not to first dump the political agenda and then move on to why the code I have written is interesting/appealing to the people I talk to.
Long time collaborators like Ulrich Drepper have been driven away by RMS and this policy.
Miguel