YESTERDAY we wrote about Novell promoting Apple with .NET. The story is in Slashdot under the headline "Novell Bringing .Net Developers To Apple iPad". It links to this article about Novell supporting the Apple iPad and also about Citrix doing something similar (earlier on we wrote about the possibility of a Citrix/Novell merger).
I personally migrated to Linux and FOSS after repeated let downs by Microsoft technology, I am loathed to give my custom to them again until they produce something which can compete with what I use now; thats either directly or indirectly. I am rather disturbed that after years of being dictated to as to how to do things by Microsoft, when I finally break away and get a better experience, I see Microsoft trying to creep into that better experience. Having said that Ubuntu is not on my main rig.
Conversely though, Canonical deserves to make money, as I say Canonical has made a great product that many people enjoy, but they need to keep in mind that whilst they may need revenue to keep “alive”, they are just as dependent on the users to keep with Ubuntu. Now its obvious that to change back to Google is a simple step, but could the perception of Yahoo provide a negative feeling from its user base towards Canonical?
[...]
With Ubuntu seemingly going in a pro-Mono direction, Mr De Icaza getting his MVP & Yahoo getting a default search status, without conjuring up any allegations of foul play, what we can say is Ubuntu seems to have a growing Microsoft theme about it. (Either directly or indirectly)
And what of GIMP? Have we had confirmation if it is definitely to be left out of 10.04 and if so replaced with what? A Mono app perhaps?
And to the outside community: * Garbage collection is necessary but insufficient for reliable code. We should move away from C/C++ for user-mode code. For new efforts, I recommend Mono or Python. Moving to fewer languages and runtimes will increase the amount of code sharing and increase the pace of progress. There is a large bias against Python in the free software community because of performance, but it is overblown because it has multiple workarounds. There is a large bias against Mono that is also overblown.
I debated putting Mono in there. But it is a codebase built by a quite diverse free software worldwide community. And I think it would be a shame that, after having built it, we throw it away. That is terribly inefficient. We can win any legal battles.
Flash isn't treated like such a pariah! Unlike Flash, the specs are free, the code is free, it has a lot of runtime and language tinkerers, etc. It is also good for Python to have competition. Python has no default IDE and debugger and is not JITed, unlike Mono. Python can learn from Mono.
Anyway, my major focus is on moving away from C++ and not moving to 100 different languages and runtimes.
[...]
Oh by the way, that doesn't mean I support building apps in XAML today. It is fine to separate the big tech pieces out and evaluate them each separately. Likewise, I wouldn't recommend VB.Net even though it is there.
Comments
dyfet
2010-01-30 15:30:20
Python can be a rather good cross-platform choice as well, though it has some tie in's to traditional scripting language practices and development concepts found commonly on pretty much all operating systems other than Microsoft Windows. The difficulty of deploying and using Python applications on Microsoft Windows is perhaps further hurt by the fact it is the only widely "in use" platform that does not include Python by default.
Mono/.NET is the only "claimed" cross-platform solution that has deliberate and deep tie in's to a specific vendor's platform characteristics, and hence cannot be described as either platform neutral or agnostic in the same way as the other two. Starting from .exe files and expectations of how what we would normally call shared libraries would not be "shared" but rather bundled with each application (something one better appreciates once reading Debian policies on packaging "Mono" applications), to language libraries and classes strongly to existing and Microsoft specific technologies and libraries, it is NOT a cross-platform technology or platform neutral at all, but when it is represented this way it is like the Trojan horse.
The real use of Mono could have been in enabling an "off-ramp" for certain ISV's and people that have been trapped in the Microsoft development world to migrate. Indeed, I think that could have been a worthwhile project goal, even if, like Wine, that methodology might be considered controversial by some, though at least Wine has a legal firewall between their implementation via reverse engineering, and without relying on Microsoft code or agreements.
But it seems to me those features for Mono which would be most helpful to such a goal are the very ones that deliberately never get developed or completed, while the ones most closely tied to Microsoft patents are the ones worked on and promoted by Novell, while at the same time the Mono team has merged their development with Microsoft ways that clearly does maximize potential legal liabilities in the future, and I mean in ways that may yet prove far more damaging in the long term than even the Novell / Microsoft patent agreement itself, and hence the reason I choose to compare it to how Wine carefully separates itself and contributing developers from such potential liabilities.
Indeed I once had a very neutral opinion of Mono, as there was a time I was looking for something to use simply for writing a purely cross-platform package. The more deeply you look at using Mono for such purposes, the more problems that rapidly rise out of it, both technical and legal, including some that are immediately obvious, as well as those which can be both short and long term risks.
Bertrand
2010-01-30 16:14:12
I'd like to know what you are referring to. The Debian CLI policy states : "Libraries that are installed into the GAC should provide decent ABI stability and be useful for other packages. Otherwise, they should remain private to the package." (http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html)
dyfet
2010-01-30 16:49:14
This practice is from Microsoft Windows, where everything seems installed in a /Program Files/packagename, and libraries (in this case C# ones) for a package are bundled together with the application rather than shared in a common /usr/lib like location, which is easier when you have freedom to share, such as free software licensing offers. Hence, I feel this is about better supporting proprietary programming practices, and hence contrary to the intent of the Debian social contract.
NotZed
2010-01-30 19:12:07
Although it is better, I'm not sure the Linux way is really *that* much better on the whole anyway, particularly the debian idea of splitting out internal shared libraries into separate packages just because they can. Because it takes a huge team of distro maintainers to keep track of the huge number of libraries and versions in use, and keep all the code up to date so you're not drowning in so many (incompatible) versions of each. And with so many api's to choose from, there's not a whole lot of 'sharing' going on of the 'shared libraries' anyway. e.g. out of the 275(!) loaded shared libraries i have on this system (admittedly not running much), 136 are only used by 1 process, with only 32 used by 10 or more (and they're the sort of system-stuff provided by any operating system so wouldn't need to be packaged). Hate to imagine if I fired off a random kde app that I rarely use ontop of that.
AmigaOS was about the only OS I know of that made shared libraries work effectively for code re-use. Partly because much was provided in the OS, so everyone used it (i.e. the 1 graphics library, not 10 different ones, the 1 font library, not 5, etc), and after a few misteps with the gadget toolkits, it moved to a more extensible architecture, like having single gadgets (widgets) in separate libraries. And since libraries were a bit funky to write, had a strict policy of backward compatibility, and only 1 version of a library could ever be loaded into the system globally - when people wrote shared libraries they wrote them with the intention of re-use by anyone, not just as a way to package up a few common utility routines.
But even this failed in the end to some extent since it is impossible to plan ahead so far into the future that you wont end up supporting so much baggage eventually that you need to clean it out. Even the best designed interface needs an overhaul once in a while.
Bertrand
2010-01-30 19:24:36
The whole point of the GAC is to share libraries while managing versionning issues.
When referring to "the package's [...] libraries", I think it is implied that they are not shared libraries.
It seems that for application-specific libraries that are of no interest for any other application, installing them under /usr/lib/application-name/ is common practice : for example there's quite a lot of .so files under /usr/lib/gimp/ on my system.
dyfet
2010-01-30 20:08:09
Dennis Murczak
2010-01-30 17:42:10
dyfet
2010-01-30 19:55:53
Roy Schestowitz
2010-01-31 09:04:55