The summary and the article it was taken from are misleading and poorly written. They only use the term 'fuel efficiency' to describe one possible effect of mucking around with your tires in general, probably by increasing their pressure or using harder tires. However, the CamberTire appears to have nothing to do with tire rigidity - and hence fuel economy - whatsoever. What the article appears to describe is a tire which is optimized by shape for negative camber, in order to improve handling of the vehicle, without the faster tire wear that putting negative camber on regular symmetrical tires produces.
WIth negative camber, the tire will be able to withstand more lateral force since it is angled out at the bottom, 'into' the turns. Thus it will be able to corner harder without losing grip.
Not
We have announced that our upcoming Mono release (2.8) will default to 4.0:
http://www.mono-project.com/Roadmap
For the first time in Mono's history our C# compiler and its supporting engine and core libraries were done before Microsoft released the product, we were usually one to two years behind. This time we are some five months ahead of time:
http://tirania.org/blog/archive/2009/Dec-09.html
There are still a handful of loose ends here and there, but luckily, nothing major.
.NET was released in July of 2000.
And Google uses a mix of languages and tools: different features require different tools and all that. Had there been no legal problems, it would have been a no-brainer to use
It did not have to be Mono, it could have been a third party
Rather, submit patches to replace System.Data with Sqlite-net and you have protection from Microsoft patents on
You are mixing two different things.
Microsoft claims that they have patents had a chilling effect on Mono adoption.
That does not mean that I do not stand 100% by our position in the Mono project regarding patents. To begin with, we think it is a bullshit argument, since everything you use is infringing on someone else's patents (Microsoft included).
Microsoft like any other corporation will do a cost/benefit analysis of suing someone over patents. So far the kernel has been a juicier target than Mono has.
I provided some context to the SD times article on my blog today:
http://tirania.org/blog/archive/2010/Mar-25.html
Miguel.
Perhaps you need to read the GPL FAQ:
As the other poster said, the fact that we do not have 1:1 parity has never been a problem.
Some other technologies that are subsets and are wildly successful:
* Android's Java is not a 1:1 mapping to Java either, and that has not prevented it from being successful.
* iPhoneOS is not MacOS 1:1, and yet, it is incredibly successful.
* Chrome the browser, does not have every feature of Firefox, that did not stop it either.
* JBoss is a subset of the full J2EE stack, and for years it has been wildly successful.
* Linux for years was not even POSIX compliant, and yet, many of us jumped on it, and it became wildly successful.
In Mono we implement what makes sense, and what people are actually using in day to day applications, we do this using metrics that we obtain from our Mono Migration Analysis that helps us identify which APIs are used, by how many applications and we have collected this data from some 10,000 applications:
http://go-mono.com/momareports/
Call this the data-driven prioritization of development.
Mono was born as a technology to bring the best that
(a) Organica growth: as the Mono community grew, we identify missing features, we envisioned better ways of doing something and created tools, APIs, languages and extensions that mattered to us. In this category you can find things like Gtk#, Taglib#, Cairo#, Cecil, Mono.Options, Mono.Security, Mono.Data, Mono.Math, Mono.Management, Mono's C# REPL, Mono's SIMD extensions, Mono's large array support. Mono's dynamic JIT extensions, Mono's static compiler and much more.
For instance, today, more than 350 applications on the AppStore and 10 of the top 100 apps in there are built using Mono.
(b) Better compatibility with
Is it correct that we do not have a full implementation of
(i) Some APIs are Windows specific, and makes no sense to bring to Linux, in particular things like System.Management which is a thin wrapper around WMI. Our advise: replace that code with Linux and MacOS specific code and use one or the other at runtime.
(ii) Some APIs are too larger for us to take with our current community. This includes things like WPF and Workflow. If someone steps up, we will embrace them, but until that happens, we are focused on improving the other areas that have more users and that we have more requests to implement. Additionally, the WPF "lite" is a killer stack (also known as Silverlight).
(iii) Focus, we do not want to spread ourselves too thin.
As for
Moonlight is behind Silverlight, but I am not driven by despair, I am driven by the world of possibility. If I were driven by despair, I would not have written a single line of code.
If Silverlight never succeeds, then who cares how behind Moonlight is. But if Silverlight succeeds, and Linux users want to access that content, but the feature is either broken, not implemented or missing in Moonlight, those users will be in a position to contribute the code, and everyone wins.
Very happy to hear that!
I can only hope we will continue to improve Mono and MonoDevelop.
Serving coffee on aircraft causes turbulence.