The snatching comes in when MS decides to exercise patent control over Mono. MS have patented a bunch of things in.Net and who knows how they'll use those patents in the coming years...
Microsoft has patents on lots of things--they can try to exercise control over Perl, Python, C++, Java, Qt, KDE, whatever your favorite language/library is. That's just a fact of life.
As for Mono, it is actually in a better situation than many other platforms: as part of the standardization process for ECMA C#, Microsoft and all other ECMA members had to disclose the totality of their intellectual property related to it.
Maybe for your small needs you don't need cross-platform.
Quite correct: for my "small" needs, I don't need it. Apple doesn't need it for its small needs, like Finder, Safari, etc. Microsoft doesn't need it for its small needs, either, like Explorer, IE, etc. Not only don't we need it, we find it a waste of time to try to make applications cross platform when the goal is to build the best application for a specific given platform.
So please, stop building iron walls and let the Windows prisoners escape to a safer world.
People like you won't be attracted to Linux if it is the lowest common denominator among all platforms, and that's pretty much what it comes down to if everything one does on it is cross platform.
After all, don't you want to be among the ones who were there, the day Microsoft died?
Sure, and that won't happen if people waste their time trying to build cross-platform applications, as opposed to creating the best applications they can for Linux. If they also happen to run on Windows, that's a nice accident, but nobody should be spending any significant amount of time worrying about that.
Which raises the interesting question of whether we should be looking for another level of abstraction for GUIs beyond widget toolkits that let you write one codebase that then applies the HIG rules of the platform (which, of course, have to be something formally codified rather than just a spec document) to generate a (relatively speaking) HIG compliant UI.
Well, you go looking, and if you figure out how to do a reasonable job at building such a high-level GUI toolkit, you go right ahead and share it with the rest of us.
Until then, however, the fact is that we have to work with what we have. And none of the cross-platform toolkits we have (Swing, Qt, wxWindows, Tcl/Tk,...) automatically make applications conform to HIGs. Therefore, if you write cross-platform applications using those toolkits, you either end up with a poor result, or you have to invest a lot of effort in each application, not only implementing the HIGs, but also fixing those areas where the cross-platform toolkit deviates from the target platform.
Again, successful commercial companies like Microsoft or Apple don't waste time on this for mainstream apps: they develop for their desktop, anything else is secondary. Linux desktops need the same focus if they want to compete.
The reverse engineering comes in when you try to emulate all the places where Microsoft has intentionally diverged from their own spec.
What difference does it make to Linux developers of Mono applications whether Microsoft fails to implement their own spec?
You can't even trust the MSDN documentation on simple Windows functions, how can you expect an entire application framework to actually adhere to the spec?
I don't expect them to. In fact, I don't care because it doesn't matter what Microsoft does with.NET or C# in the future.
The ECMA C# standard includes a significant set of libraries. Mono implements those and you can use them.
Microsoft's.NET includes a lot more APIs that are not part of ECMA C#. Mono implements many of those as well, but you don't have to use them because Mono provides comparable functionality in bindings to existing open source libraries. In fact, if you are writing software for Linux, using the Mono bindings to open source libraries is both technically and practically a better choice for you.
This isn't 100% accurate since there is also the issue of patents to consider. In order to implement some parts of the.NET standard there would be some "use" of MS patents (I'm talking about ASP.NET and ADO.NET in particular)
Did you even bother to read what I wrote? These are mostly Gnome applications written in the C# language. They don't use ASP.NET or ADO.NET.
Even the Mono team acknowledges this as an issue but they promise they'll somehow code around the patent or they just won't implement parts of the standard. Certainly not an optimal solution.
My point was and is: the non-standardized parts of.NET are a red herring because open source applications simply don't use them. That's what this list of applications shows.
The non-standardized parts of.NET are only an issue if you use Mono to deploy your Windows-based ASP.NET or ADO.NET applications on Linux. Your risk and exposure to Microsoft IP results from your choice of using ASP.NET and ADO.NET in the first place; the existence of Mono, if anything, reduces your risk and exposure somewhat, but, of course, it can't completely eliminate it.
MS gets to say that their solution (C#) is cross platform and usable on numerous platforms. In short, publicity.
Good for them: they let the language undergo standardization by an independent standards body, and now people are creating third party implementations of it for other platforms. That is as it should be.
Contrast that with Sun, which promised to standardize Java, and then pulled out of standardization processes twice when they discovered that those bodies had requirements for intellectual property disclosure and withdrew twice. Sun now falsely gives the impression that Java is an open standard and that the JCP is an open process, when neither is anything of the sort. That is not as it should be.
Yes, and that's a good thing. I don't want cross-platform apps, I want the best apps possible for the Gnome desktop. I don't get the best apps possible for the Gnome desktop if people waste their time worrying about how their application is going to look on Windows or OS X. The whiners on those platforms are only going to complain that the application doesn't look "native enough" anyway.
Microsoft doesn't lose focus by worrying about how to port their apps to UNIX and neither should Linux developers worry about how their applications look on Windows. When Microsoft does create applications for multiple platforms, they hand-craft them for each target platform.
Mainstream applications shouldn't be cross-platform; it's a waste of time and results in a poor quality user experience.
The catch is that C# and CLR are not open standards - they are just ECMA standards.
That is what an open standard is: something that is published by a recognized standards body and that anybody is free to implement.
Apparently it was a brilliant move by MSFT because now people will automatically believe CLR is somehow "open".
They believe that because it's true..NET is not open, but ECMA C# is.
In fact, a while ago Novell was asking MSFT for a clear declaration that Mono does not infringe MSFT IP.
Yes, Novell did ask that. That question doesn't refer to ECMA C#, which is as open as any language standard, it refers to Mono's implementation of.NET.
It provides a hose that MSFT can step on to end the distribution of the appications.
Erroneous statements like that seem calculated to create unjustified fear, uncertainty, and doubt about C# in order to keep people from using it. ECMA C# is open. Microsoft can no more "step on its hose" than they can step on C++ or Python or Java (on which, incidentally, they may also hold related patents).
We should never become too dependent on Mono, or Java, or any other proprietary technology.
Mono is not proprietary technology: it's an open source project implementing a de-facto industry standard. As such, it is no different from Linux, for example. As such, Mono consists of two parts: a part that implements an open standard (ECMA C#), and a part that implements a proprietary set of APIs (the parts of.NET that are not in ECMA C#).
If you want to use purely open APIs, just use ECMA C# and Gtk# and don't use any of the non-standard.NET libraries that Mono happens to implement as well. That's what I do.
Those same applications will also run under Windows,
These are not.NET applications, they are Gtk+ applications written in C#. As a result, they don't run on Windows or.NET out of the box.
You can run them on Windows, but you can do that with lots of other Gnome and KDE apps as well.
Plus, they can sell MS Office.NET to Linux users too, as it can run on Linux.
I think this would be great for Linux. Unfortunately, Mono will likely never be compatible enough for that, and hell would freeze over before Microsoft would even contemplate such a thing.
Neither Microsoft nor Gnome hackers came up with this first; providing useful information without requiring the user to make explicit queries has been studied on and off in various areas of computer science. There was a bout of academic interest half a dozen years ago, and those graduates have moved on to Microsoft and other industry labs, hence this is making it into products now.
I know you are trying to be funny, but please don't confuse people: these are generally not Microsoft.NET applications; they use the C# language and standard library together with common open source libraries.
By analogy, Qt applications written in C++ have nothing to do with MFC applications written in C++; they are two different application frameworks that happen to be based on the same programming language.
It is perfectly reasonable to say that software patents are the law of the land and that therefore one has to use them for one's business as best one can. That is, however, no excuse for applying for a patent on IsNot. The problem with IsNot is not that it is a software patent, it's that it is ridiculous even among software patents.
Microsoft files several thousand patents a year, but they also have a lot of people working for them in R&D. While they may or may not have an unlimited legal budget, they still have to prioritize like any other company because there is only so much time their employees can spend writing patents.
If IsNot made the cut, then both at the corporate level and for Vick's own work, it must be among the best they can do, and that is frankly not much of a recommendation.
It implies that very bad things can happen, but how can you know, if so little of these matters are understood?
Do you have to know how to land an airplane in order to figure out that the consequences of doing it wrong are bad?
because I too fear playing around with the environment might cause destruction of a magnitude we cant even imagine. There seem to be some indications that this is possible, but I havent seen any proof yet. But until it's not disproven I's rather be safe.
Actually, we do know some of the consequences. Numerous human civilizations have been wiped out by self-inflicted ecological disaster. We know how sea levels have varied over time. We know of species that have disappeared because they inflicted ecological disaster on themselves (of course, they couldn't reason about their own behavior). And there are indications that global weather patterns can be pushed into various fairly stable states, some of which are highly unfavorable to human life and civilization.
So, we know all sorts of bad things can happen. We don't know what effects our actions will have, but we do know that current conditions are pretty good for us, so we should avoid doing things that might change them until we know what we are doing.
Inaction is just another choice, not necessarily less risky
Oh, it's a lot less risky. We know a lot about the earth's history without global human interference.
If we wait, we will just be playing another game of roulette: whether we can find another planet in time before Earth can no longer sustain us.
Based on what we know from biology, paleontology, and geology, we know that we can expect that Earth can sustain us for many millions of years to come if we don't mess up its ecology. After tinkering with its ecology, all bets are off.
I just don't get the fascination with Halo/Halo 2. Compared to games like HalfLife, Unreal, Quake 1-3, or Doom 1-3, Halo to me seemed like a rather "corporate" effort: the Halos were competently implemented and offered pretty good game play, but ultimately, I didn't find them as entertaining.
I found the single player campaigns in the Halos particularly dull (I didn't even bother finishing the one in Halo 2). Halo and Halo 2 seems at its best in multiplayer mode, where I think it offers a fairly user-friendly multiplayer FPS.
Of course, maybe I could just relate better to Gordon Freeman, nerd that he is, than to whatever the guy in Halo was called. Still, Half Life didn't take itself too seriously and was funny at times, yet also creepy and entertaining, and I didn't find much of that in Halo.
Everyone knows that nature is static, and how things were 50, 100, or 1000 years ago are the way that they should be today, tomorrow, and forever!
The reason why large scale or long-term changes to the environment are so risky is not, as you mistakenly state, that nature is static. Rather, it is that nature is highly dynamic on time scales spanning millennia and we don't understand the dynamics yet. A significant change that we think produces benefits may, in the long term, have devastating consequences.
Once we understand natural systems sufficiently well to be able to predict the consequences of our actions in the long term, then we can engage in deliberate planet-wide engineering efforts, here on earth on on Mars. Until then, anything that alters our atmosphere, oceans, or ecology significantly is Russian roulette.
Potentially lots more software than for any of the other platforms: it's the same kernel and APIs as on the desktop (not true for any of the other phone platforms), and there is lots of Linux software that runs on small screens and limited memory (due to the age and previous uses of UNIX).
FUD stands for "fear, uncertainty, and doubt", a particular strategy used by sales people from a large company (IBM, then) to get customers not to buy competitors that are new to the market. You have to be pushing a large product as "the safe, mainstream choice" in order to be "spreading FUD".
FUD does not stand for misinformation or stupidity. We have better words for that, like misinformation and stupidity.
According to the web site, the guy who founded the company has a patent (filed in 1995) for a combination of "mobile PC with a cellular telephone" and then in 2005, he "founded" this company, whose "goal" it is to create a product. The product "photographs" are obviously fake: the scale of the screen is wrong and a keyboard with concave keycaps makes no sense on a small device. This guy may be trying to cause some trouble with his patent, that's all.
Motorola makes several Linux-based cell phones that are apparently quite nice. Otherwise, the Nokia 9300 and 9500 are great little cell phones with a decent operating system (Symbian).
XUL and XAML are general markup languages for GUIs. And Flash is a complete runtime. The notion that XUL and XAML are substitutes for a forms standard makes about as much sense as saying that a C compiler is a replacement for a web browser: just add a little bit of code yourself. I guess we should count our blessings that at least they aren't proposing to use Java.
XForms is specifically for forms: things you fill in and submit. XForms also has facilities for off-line filling and mailing of forms. We need a standard like that.
Having said that, I find neither XForms nor Web Forms 2.0 particulary persuasive. XForms suffers from second system effect: there is just too much of it. And Web Forms 2.0 seems like a mess; reliance on JavaScript is a no-no.
Thanks, but not thanks: everybody should go back to the drawing board. Maybe in another few years, they'll come back with something reasonable.
It's not "Microsoft's technology", they didn't invent it--they are only trying to patent it. Whether the patent holds up despite that remains to be seen, but Google has enough money and clout to at least fight it.
Slashdot Mirror
That web page is a rambling, disorganized mess--the author should take a writing class.
The snatching comes in when MS decides to exercise patent control over Mono. MS have patented a bunch of things in .Net and who knows how they'll use those patents in the coming years...
Microsoft has patents on lots of things--they can try to exercise control over Perl, Python, C++, Java, Qt, KDE, whatever your favorite language/library is. That's just a fact of life.
As for Mono, it is actually in a better situation than many other platforms: as part of the standardization process for ECMA C#, Microsoft and all other ECMA members had to disclose the totality of their intellectual property related to it.
Maybe for your small needs you don't need cross-platform.
Quite correct: for my "small" needs, I don't need it. Apple doesn't need it for its small needs, like Finder, Safari, etc. Microsoft doesn't need it for its small needs, either, like Explorer, IE, etc. Not only don't we need it, we find it a waste of time to try to make applications cross platform when the goal is to build the best application for a specific given platform.
So please, stop building iron walls and let the Windows prisoners escape to a safer world.
People like you won't be attracted to Linux if it is the lowest common denominator among all platforms, and that's pretty much what it comes down to if everything one does on it is cross platform.
After all, don't you want to be among the ones who were there, the day Microsoft died?
Sure, and that won't happen if people waste their time trying to build cross-platform applications, as opposed to creating the best applications they can for Linux. If they also happen to run on Windows, that's a nice accident, but nobody should be spending any significant amount of time worrying about that.
Which raises the interesting question of whether we should be looking for another level of abstraction for GUIs beyond widget toolkits that let you write one codebase that then applies the HIG rules of the platform (which, of course, have to be something formally codified rather than just a spec document) to generate a (relatively speaking) HIG compliant UI.
...) automatically make applications conform to HIGs. Therefore, if you write cross-platform applications using those toolkits, you either end up with a poor result, or you have to invest a lot of effort in each application, not only implementing the HIGs, but also fixing those areas where the cross-platform toolkit deviates from the target platform.
Well, you go looking, and if you figure out how to do a reasonable job at building such a high-level GUI toolkit, you go right ahead and share it with the rest of us.
Until then, however, the fact is that we have to work with what we have. And none of the cross-platform toolkits we have (Swing, Qt, wxWindows, Tcl/Tk,
Again, successful commercial companies like Microsoft or Apple don't waste time on this for mainstream apps: they develop for their desktop, anything else is secondary. Linux desktops need the same focus if they want to compete.
The reverse engineering comes in when you try to emulate all the places where Microsoft has intentionally diverged from their own spec.
.NET or C# in the future.
What difference does it make to Linux developers of Mono applications whether Microsoft fails to implement their own spec?
You can't even trust the MSDN documentation on simple Windows functions, how can you expect an entire application framework to actually adhere to the spec?
I don't expect them to. In fact, I don't care because it doesn't matter what Microsoft does with
What use is a managed runtime without libraries?
.NET includes a lot more APIs that are not part of ECMA C#. Mono implements many of those as well, but you don't have to use them because Mono provides comparable functionality in bindings to existing open source libraries. In fact, if you are writing software for Linux, using the Mono bindings to open source libraries is both technically and practically a better choice for you.
The ECMA C# standard includes a significant set of libraries. Mono implements those and you can use them.
Microsoft's
This isn't 100% accurate since there is also the issue of patents to consider. In order to implement some parts of the .NET standard there would be some "use" of MS patents (I'm talking about ASP.NET and ADO.NET in particular)
.NET are a red herring because open source applications simply don't use them. That's what this list of applications shows.
.NET are only an issue if you use Mono to deploy your Windows-based ASP.NET or ADO.NET applications on Linux. Your risk and exposure to Microsoft IP results from your choice of using ASP.NET and ADO.NET in the first place; the existence of Mono, if anything, reduces your risk and exposure somewhat, but, of course, it can't completely eliminate it.
Did you even bother to read what I wrote? These are mostly Gnome applications written in the C# language. They don't use ASP.NET or ADO.NET.
Even the Mono team acknowledges this as an issue but they promise they'll somehow code around the patent or they just won't implement parts of the standard. Certainly not an optimal solution.
My point was and is: the non-standardized parts of
The non-standardized parts of
MS gets to say that their solution (C#) is cross platform and usable on numerous platforms. In short, publicity.
Good for them: they let the language undergo standardization by an independent standards body, and now people are creating third party implementations of it for other platforms. That is as it should be.
Contrast that with Sun, which promised to standardize Java, and then pulled out of standardization processes twice when they discovered that those bodies had requirements for intellectual property disclosure and withdrew twice. Sun now falsely gives the impression that Java is an open standard and that the JCP is an open process, when neither is anything of the sort. That is not as it should be.
That's because they keep thinking "Linux-only"
Yes, and that's a good thing. I don't want cross-platform apps, I want the best apps possible for the Gnome desktop. I don't get the best apps possible for the Gnome desktop if people waste their time worrying about how their application is going to look on Windows or OS X. The whiners on those platforms are only going to complain that the application doesn't look "native enough" anyway.
Microsoft doesn't lose focus by worrying about how to port their apps to UNIX and neither should Linux developers worry about how their applications look on Windows. When Microsoft does create applications for multiple platforms, they hand-craft them for each target platform.
Mainstream applications shouldn't be cross-platform; it's a waste of time and results in a poor quality user experience.
The catch is that C# and CLR are not open standards - they are just ECMA standards.
.NET is not open, but ECMA C# is.
.NET.
.NET that are not in ECMA C#).
.NET libraries that Mono happens to implement as well. That's what I do.
That is what an open standard is: something that is published by a recognized standards body and that anybody is free to implement.
Apparently it was a brilliant move by MSFT because now people will automatically believe CLR is somehow "open".
They believe that because it's true.
In fact, a while ago Novell was asking MSFT for a clear declaration that Mono does not infringe MSFT IP.
Yes, Novell did ask that. That question doesn't refer to ECMA C#, which is as open as any language standard, it refers to Mono's implementation of
It provides a hose that MSFT can step on to end the distribution of the appications.
Erroneous statements like that seem calculated to create unjustified fear, uncertainty, and doubt about C# in order to keep people from using it. ECMA C# is open. Microsoft can no more "step on its hose" than they can step on C++ or Python or Java (on which, incidentally, they may also hold related patents).
We should never become too dependent on Mono, or Java, or any other proprietary technology.
Mono is not proprietary technology: it's an open source project implementing a de-facto industry standard. As such, it is no different from Linux, for example. As such, Mono consists of two parts: a part that implements an open standard (ECMA C#), and a part that implements a proprietary set of APIs (the parts of
If you want to use purely open APIs, just use ECMA C# and Gtk# and don't use any of the non-standard
Those same applications will also run under Windows,
.NET applications, they are Gtk+ applications written in C#. As a result, they don't run on Windows or .NET out of the box.
These are not
You can run them on Windows, but you can do that with lots of other Gnome and KDE apps as well.
Plus, they can sell MS Office.NET to Linux users too, as it can run on Linux.
I think this would be great for Linux. Unfortunately, Mono will likely never be compatible enough for that, and hell would freeze over before Microsoft would even contemplate such a thing.
Neither Microsoft nor Gnome hackers came up with this first; providing useful information without requiring the user to make explicit queries has been studied on and off in various areas of computer science. There was a bout of academic interest half a dozen years ago, and those graduates have moved on to Microsoft and other industry labs, hence this is making it into products now.
I know you are trying to be funny, but please don't confuse people: these are generally not Microsoft .NET applications; they use the C# language and standard library together with common open source libraries.
By analogy, Qt applications written in C++ have nothing to do with MFC applications written in C++; they are two different application frameworks that happen to be based on the same programming language.
Mono is a wonderful piece of reverse engineering
There is no "reverse engineering" involved. These applications are written in C#, an open ECMA standard, and the open source Gtk+ toolkit.
I fear the day when Microsoft will come and snatch this out from under the Mono team,
There is nothing to "snatch": these are applications implemented in a non-Microsoft toolkit using an open language standard.
I really think this benifits Microsoft
I don't see how writing Gnome applications in C# benefits Microsoft any more than writing Gnome applications in C++ or Python.
It is perfectly reasonable to say that software patents are the law of the land and that therefore one has to use them for one's business as best one can. That is, however, no excuse for applying for a patent on IsNot. The problem with IsNot is not that it is a software patent, it's that it is ridiculous even among software patents.
Microsoft files several thousand patents a year, but they also have a lot of people working for them in R&D. While they may or may not have an unlimited legal budget, they still have to prioritize like any other company because there is only so much time their employees can spend writing patents.
If IsNot made the cut, then both at the corporate level and for Vick's own work, it must be among the best they can do, and that is frankly not much of a recommendation.
It implies that very bad things can happen, but how can you know, if so little of these matters are understood?
Do you have to know how to land an airplane in order to figure out that the consequences of doing it wrong are bad?
because I too fear playing around with the environment might cause destruction of a magnitude we cant even imagine. There seem to be some indications that this is possible, but I havent seen any proof yet. But until it's not disproven I's rather be safe.
Actually, we do know some of the consequences. Numerous human civilizations have been wiped out by self-inflicted ecological disaster. We know how sea levels have varied over time. We know of species that have disappeared because they inflicted ecological disaster on themselves (of course, they couldn't reason about their own behavior). And there are indications that global weather patterns can be pushed into various fairly stable states, some of which are highly unfavorable to human life and civilization.
So, we know all sorts of bad things can happen. We don't know what effects our actions will have, but we do know that current conditions are pretty good for us, so we should avoid doing things that might change them until we know what we are doing.
Inaction is just another choice, not necessarily less risky
Oh, it's a lot less risky. We know a lot about the earth's history without global human interference.
If we wait, we will just be playing another game of roulette: whether we can find another planet in time before Earth can no longer sustain us.
Based on what we know from biology, paleontology, and geology, we know that we can expect that Earth can sustain us for many millions of years to come if we don't mess up its ecology. After tinkering with its ecology, all bets are off.
I just don't get the fascination with Halo/Halo 2. Compared to games like HalfLife, Unreal, Quake 1-3, or Doom 1-3, Halo to me seemed like a rather "corporate" effort: the Halos were competently implemented and offered pretty good game play, but ultimately, I didn't find them as entertaining.
I found the single player campaigns in the Halos particularly dull (I didn't even bother finishing the one in Halo 2). Halo and Halo 2 seems at its best in multiplayer mode, where I think it offers a fairly user-friendly multiplayer FPS.
Of course, maybe I could just relate better to Gordon Freeman, nerd that he is, than to whatever the guy in Halo was called. Still, Half Life didn't take itself too seriously and was funny at times, yet also creepy and entertaining, and I didn't find much of that in Halo.
That's still open to debate.
Everyone knows that nature is static, and how things were 50, 100, or 1000 years ago are the way that they should be today, tomorrow, and forever!
The reason why large scale or long-term changes to the environment are so risky is not, as you mistakenly state, that nature is static. Rather, it is that nature is highly dynamic on time scales spanning millennia and we don't understand the dynamics yet. A significant change that we think produces benefits may, in the long term, have devastating consequences.
Once we understand natural systems sufficiently well to be able to predict the consequences of our actions in the long term, then we can engage in deliberate planet-wide engineering efforts, here on earth on on Mars. Until then, anything that alters our atmosphere, oceans, or ecology significantly is Russian roulette.
Anyone know why the "Y" and "Z" keys are switched?
I ask myself that every day.
but what about in day-to-day operations?
Potentially lots more software than for any of the other platforms: it's the same kernel and APIs as on the desktop (not true for any of the other phone platforms), and there is lots of Linux software that runs on small screens and limited memory (due to the age and previous uses of UNIX).
FUD stands for "fear, uncertainty, and doubt", a particular strategy used by sales people from a large company (IBM, then) to get customers not to buy competitors that are new to the market. You have to be pushing a large product as "the safe, mainstream choice" in order to be "spreading FUD".
FUD does not stand for misinformation or stupidity. We have better words for that, like misinformation and stupidity.
According to the web site, the guy who founded the company has a patent (filed in 1995) for a combination of "mobile PC with a cellular telephone" and then in 2005, he "founded" this company, whose "goal" it is to create a product. The product "photographs" are obviously fake: the scale of the screen is wrong and a keyboard with concave keycaps makes no sense on a small device. This guy may be trying to cause some trouble with his patent, that's all.
Motorola makes several Linux-based cell phones that are apparently quite nice. Otherwise, the Nokia 9300 and 9500 are great little cell phones with a decent operating system (Symbian).
XUL and XAML are general markup languages for GUIs. And Flash is a complete runtime.
The notion that XUL and XAML are substitutes for a forms standard makes about as much sense as saying that a C compiler is a replacement for a web browser: just add a little bit of code yourself. I guess we should count our blessings that at least they aren't proposing to use Java.
XForms is specifically for forms: things you fill in and submit. XForms also has facilities for off-line filling and mailing of forms. We need a standard like that.
Having said that, I find neither XForms nor Web Forms 2.0 particulary persuasive. XForms suffers from second system effect: there is just too much of it. And Web Forms 2.0 seems like a mess; reliance on JavaScript is a no-no.
Thanks, but not thanks: everybody should go back to the drawing board. Maybe in another few years, they'll come back with something reasonable.
It's not "Microsoft's technology", they didn't invent it--they are only trying to patent it. Whether the patent holds up despite that remains to be seen, but Google has enough money and clout to at least fight it.