The Vietnameese government goes Open Source. WOW
Posted on 30 Oct 2003
Mono people: Lets get together on Tuesday 28th at 6pm at the West Tower Lobby in the LA Conventions Center at the PDC to discuss Mono. Pass the message.
After this we can head over to the "Meet the Experts" session at 7pm.
Posted on 28 Oct 2003
Tomorrow we will devise a plot to get more people interested in Mono to get together; My plan right now is to take over one of those empty areas around 7pm and just get together around the tables. I spotted a few places that seem to be deserted, will confirm tomorrow, and we can have a massive Mono love-fest.
Posted on 27 Oct 2003
The fine folks at the `Microsoft and Academia' BOF have welcomed us to participate on their track so we can discuss Mono from an academic perspective.
The BOF is at 7pm at the Conventions Center.
We just arrived to the PDC, and we put open source in practice and did some patching of the BOF announcements to reflect the Mono session.
Posted on 26 Oct 2003
After a nice evening improving the new System.Drawing foundation built by Alexandre am ready for some airplane hacking. Will be arriving early to LA for the Microsoft PDC.
The language specs for C# have been published
Posted on 24 Oct 2003
As I upgraded the hard drive on my machine today --which took a few hours to copy the rats' nest that is my home directory-- I begun the process of assimilating the GDIPlus Flat API.
A few weeks ago, Alexandre Pigolkine, Jordi Mas and myself were discussing the development roadblocks that we had with System.Drawing (as part of the Windows.Forms effort). The problem is that we made one of the most common engineering mistakes: when faced with the issue of multiple choices, instead of choosing one, we chose them all.
Being seasoned C# developers, we created an internal interface, and had each backend implement the interface. Then the official System.Drawing API was implemented and it became a multiplexor for the various implementations. We had Win32, Xr and Gtk backends. Of course the issue is that improving the backends becomes fairly hard: a change has to be reflected in five places: three backends, the interface and the multiplexing call site. Not terribly hard for one or two API calls, but it starts to become hard with an API as big as this one. I take all the blame for the mistake.
After some discussion, we decided on a new strategy: System.Drawing would only have one implementation, and this implementation would be based on GDI+. On Windows, the implementation would just call into the real GDI+ library, and on Unix systems we would provide a full implementation of it. To implement GDI+ on Unix, we have based our implementation on Cairo which has pretty much the same imaging model that GDI+ (and PDF) have.
This has several advantages: we maintain and write less code; we can test against the real GDI+ implementation on Windows and remove a variable in the debugging process; and we can contribute this code back to the Wine project.
But plenty of assumptions we had made before do not apply necessarily now. Before we had a managed implementation of the image loaders: it was just as fast as the C code and by virtue of being C# code, by extension it was cooler. But now in this GDI+ world, we will move things like the image loaders into the C code API, and the C# code will become thin wrappers around it.
The above also explains why there is a regression in Windows.Forms and System.Drawing on CVS as opposed to the latest official Mono release. So now I should be able to assist the System.Drawing developers.
The upcoming Mono not only will add Cairo as a depedency (if you care about System.Drawing), but our internationalization support will also require the International Components for Unicode library.
We will continue to provide packages on Red Carpet, and RPMs on the site for downloading, but we are seriously considering reusing the Ximian Desktop installer to install Mono on a machine. That means that instead of downloading a dozen packages from our site, you would only download one. This hopefully will reduce the number of problems that people have with installations and we would also ship the Apache module pre-configured in the distribution.
Duncan is researching this, and we will keep people posted.
Posted on 21 Oct 2003
Wondering about the organization of a meeting of Mono users at the PDC, it seems like Monday afternoon before the reception, or Thursday are good time slots for getting together.
Alternatively, the Mono folks will be wearing the cool Mono t-shirts, so if you are interested in discussing a Mono topic, feel free to come and join us.
Today's most beautiful blog update goes to Nat for his fantastic photographic update on the Bangalore trip and his insight on his trip to ramp up the new Novell open source hackers that will be working on improving Gnome, OpenOffice, Mozilla and Mono.
In other news, am going to Bangalore in early December, and I have to plan something with convenient stops in the middle. It has to involve a Paris stop, so I can meet the Mono hackers in Paris, and introduce myself to Fabrice Bellard.
In November the Gnome Hackers will descend into New York for the Gnome Summit where we will talk about the major problems facing the Linux desktop today. This event is a follow up to last years Boston Gnome Summit.
There are tons of new topics for this year that I am looking forward to discuss:
And of course, get everyone to adopt Mono for their projects, as we know it is the One True Runtime (bug reports, happily accepted
Posted on 18 Oct 2003
I just received a letter from the INETA PDC organizers informing me that the Mono BOF would not be happening. I was looking forward to discuss Mono. The BOF suggestion had a pretty good rating and hat plenty of voters, I guess it was a far stretch to have Microsoft have a BOF on Mono :-)
Notice that there is an estimated of 60 BOF talks, but only 48 were approved.
If there are people interested, we can still sit down and discuss Mono at the PDC, there will be at least three of us: Gonzalo, Lluis and myself.
Posted on 15 Oct 2003
I am looking to hire a full-time developer to work on the Mono JIT engine. This would include working on the code generation engine of the JIT (so compiler experience, low-level programming experience is a plus), advanced optimizations for the compilation engine (various SSA-based optimizations, array-bounds check elimination, fast-call conventions, loop optimizations), debugging interfaces and would involve dealing with a garbage collected, multi-threaded runtime environment.
We are porting the Mono JIT to various platforms, so you would be learning new assembly languages, new ABIs and more. If you are interested, drop me an email at [email protected]
Posted on 14 Oct 2003
I have been applying every one of those "Apply this patch immediately" updates that I have received on e-mail from [email protected], and my machine seems slower every time.
Update: I have received on last count 9 emails from people informing me that the above is a virus. Guys, it was a joke. Obviously I failed in my attempt to be funny.
Chris Toshok today has been working on embedding Mono and Mono-based applications inside Evolution in their new UI branch.
Here is a screenshot embedding the Mono documentation browser in Evolution:
Posted on 13 Oct 2003
Posted on 12 Oct 2003
Some people have asked me about the theme for this year Birthday's present. This year theme is going to be `Nice and Expensive'. It is a repetition of an old-time favorite. But this year, lets try harder to stick to the theme.
Posted on 09 Oct 2003
We modified the Monologue software to use multiple-threads to download the RSS feeds concurrently, and this exposed a couple of tricky bugs in the runtime and our DNS setup. Gonzalo was on a quest to track all of these problems down, and our abusive version of Monologue is now fully functional.
Now the major source of problems was not a Mono bug, but a dead-lock condition that was not obvious. Turns out that Monologue/threaded happened to fill the Threadpool queue (no surprises there: threadpool will just take care of things), but the Http code needed a thread from the pool to download things (the API is using the async version of this as well), and that caused a deadlock.
Posted on 07 Oct 2003
Ben wrote an RSS aggregator that we are running now on http://www.go-mono.com/monologue to track the Mono blogs. You can now get all your Mono news in a single spot. This is similar in spirit to Jeff's Planet GNOME
If you are interested in running the aggregator in your machine for your own personal blog reading, just download the `monologue' module from our AnonCVS repository.
I have tried three kinds of RSS aggregators out there: desktop-based, mozilla-based and html-based. From my personal browsing experience I believe that the HTML-based aggregators are the best kind. Specially when we you are using Mozilla/Firebird with tab browsing.
There are plenty of desktop-based aggregators for both Windows and Linux (I tried them all in a quest for the perfect UI). The desktop-based aggregators typically embed a web browser in the browsing pane to render the news. And this is the source of most frustration with them.
The embedded HTML rendering engine has some very bizarre interaction glitches when you follow links, and you try to go back in history, or when you start following links inside the aggregator (which it is bound to happen).
Since it is not really possible to read comfortably the news inside the aggregator, you can either open a new window (uncomfortable) or hope that the aggregator can instruct your browser to open a new tab, but it is still annoying to use.
The obvious answer to the above problem is to put the aggregator inside the browser. Luckily Mozilla/Firebird have made plugin authoring a breeze, and there are a couple of options out there.
These aggregators today suffer from a problem shared by the desktop-based aggregators: they are based on the modern news-reading/mail-reading model. These present the user with a collection of folders with items old and new, and you read your feeds one by one. This model is ill-suited for blog reading because blogs do not produce large volumes of data per day, and you most likely want to read all the new things in the day at once. Not once per week, so the interaction model is basically to read a single post on each folder and move to the next one, and repeat this a number of times per day. Not very efficient.
The third kind, the one I like the most are the aggregators that generate an HTML page with the consolidated data. This in my opinion is the best model because you get to read HTML content on your main HTML browser and all the tools available on your browser are available to you and most important: there are no surprises on the behavior. Since it aggregates all the data at once, every time you visit it, you can get a snapshot of what is happening, rather than having to check 20 sources one by one.
Firebird users probably will like the last one the most, since its a feature packed browser, and with a rich set of extensions that make browsing more efficient. But in general any user of a tabbed-based browser will enjoy the later kind the most.
Yesterday there was another suicide bombing in Israel. The reaction was an attack on an alleged terrorist training camp in Syria. Following the Bush doctrine of `destroy evidence first, cover-up with non-answers later'.
Been thinking this morning that it is time to write a Israeli-Palestine Conflict Primer. On second thought, maybe I should just strongly recommend reading John Pilger's Palestine Is Still The Issue an eight-parth documentary available online (wish they sold the video on DVD).
The Hamas group that has been striking at the civilian population was initially funded by Israel in the 70's to undermine the growing popularity of the PLO and Arafat. A policy that now has backfired. Some details here.
Posted on 05 Oct 2003
We completed the SouceGear project!
The project included adding a lot of functionality to Mono to support Web Services on the client (mostly having a full XmlSerializer implementation as well as its close family members) and making Mono robust.
To make sure that Mono was robust, SourceGear designed a series of extensive tests that Mono would be put under, and the acceptance criteria for the work we did included running the tests for a 24 hour period of time on a single instance of the virtual machine. Needless to say, making the Mono VM robust enough to run these tests for 24 hours was not easy, and we ran into all sorts of low-level interesting features, memory leaks, race conditions and other assorted small problems that would not have shown under normal circumstances. We are very happy about this.
In the meantime, while parts of the team were tracking down the elusive bugs in the runtime, Lluis took the time to implement the server side component of ASP.NET, so as part of the SourceGear effort, we also got our web services stack implement on the server, which was a nice plus.
I was feeling that I should argue a bit more about exceptions, until I received a mail from Krzysztof Cwalina at Microsoft, he raises a good point about exceptions and the null return pattern: they do not allow an error to be propagated, nor details about the error.
He is absolutely right, and my example with files was not a good one. I had in mind APIs that did not need to propagate a rich error or details about the condition. Krzysztof said:
One problem with null is that you may get notified about the problem really far away from the point when the error occurred. Exception will be thrown right there at the point where the error occurs. The other problem is that null cannot tell you why the error occurred. Error codes have their own set of problems.
Of course (as with every design) it's a tradeoff. In this case a tradeoff between better error reporting (fail fast, rich error message) and performance (and other things). In general, we err on the side of better reliability, clarity of errors, etc. when designing the Framework. We have several exceptions to the general rule in explicitly identified performance-sensitive APIs.
Lluis the man behind the Mono implementation of Remoting and Xml Serializer explains on his latest blog entry how the undocumented IXmlSerializable interface works. If you ever wondered how you could have precise control over the Xml mapping in XmlSerializer, this is the interface used internally by the framework.
Sebastien, the man behind the Mono cryptographic infrastructure now has his own blog.
Duncan also started his
Posted on 01 Oct 2003