J5’s Blog

I feel I owe this blog post to Chris being that I’ve been cited as one of the catalysts for some in the GNOME community aligning themselves with WebKit.  Not that I think that is bad that there is competition in the browser market (competition is one thing but a line in the sand is just counterproductive here) but my original intent was merely to ask what are our priorities and what projects would align closer to those priorities.

In any case it was reported on Slashdot that according to an article at Dot Net Perls, Firefox is now one of the most efficient browsers when it comes to memory usage.  This meshes with the internal tests Mozilla was doing and Chris blogged about.  It was one of my main gripes with Firefox when using the XULRunner and Gecko engine as the basis for an embedded browser.  At the time I was a bit nonplussed as the work that was being done to make Firefox better revolved around blaming and removing important libraries instead of fixing the root causes.

If the data is to be believed (and be transferable to Linux as the tests were run on Windows) then it does point to significant improvements in Firefox and I thank the Mozilla community for listening and dealing with the issues head on.  Software is hard and we shouldn’t turn our backs on a friend of the Linux community even when they might not be walking lock step with us.  The flip side is Mozilla does need to be concious of the needs of downstream developers and not use its market position as bludgeon to get its way. To that end there are still the issues of a stable embedded API and better platform integration. I hear those are being worked on so hopefully it won’t be an issue going forward.

Again I would like to thank the Mozilla community for putting out a great browser that is a serious competitor with Internet Explorer. I would also like to thank the Mozilla Foundation for helping fund accessibility work in GNOME. By working with each other instead of butting heads, as happens every once in awhile, the ecosystem grows and benefits both communities.

…and say hello to Cappuccino in a Cloud.

The Red Hat “Boston” office just moved into new diggs down the street from our old office space.  This is the second move we have made since I got here four years ago and a needed one as the company continues to grow at a steady pace. Inevitably the discussion of coffee makers comes up every time we make a move (and quite frequently in the interim too) with a new coffee gadget showing up shortly after. We opted for the Flavia drink station this time around. This brings up the issue that any new gadget presented to a large audience will inevitably see high traffic for the first few days before the novelty wears off and the traffic reduces to a steady level of consumers.

There are many questions that need to be considered here. Will the machine stand up to the first few weeks of abuse? If it was engineered for a high peak capacity is it still economical to run when that traffic has fallen off? Do we just accept that the first few weeks will see some breakdowns, pissed customers who will not come back because of the failed experience and keep on chugging with the knowledge that our initial costs were low? If coffee making could be parallelized could it scale up and down economically and efficiently?

This is the Cappuccino in a Cloud problem. How do you make processes efficient and scalable for both high load peak and the inevitable lower day to day traffic? The travelling salesman problem dealt with efficiencies of one single entity (the salesman) finding the most efficient (read cheapest) single threaded route through a number of destinations. In today’s word the consumer comes to the buisness or service, sometimes all at once, and it is important to figure out the most efficient way (measured in the consumer’s satisfaction and producer’s bottom line) to handle that load.

I got back from the BOSSA conference last week. It still is my favorite conference for just talking to people and getting things rolling. The organizers keep it small and limit the number of talks so that people can get to what they do best and just talk to each other. While I am no longer directly involved in embedded development I still feel this should be the target of most developers. A win on current generation embedded devices means improvements across the board from those devices to the desktop and even the server room. Most of my debugging and optimization techniques for D-Bus, the focus of my BOSSA talk, were gained from working with it on embedded devices. I continue to gear my work with the idea that in the near future a large portion of the people consuming those technologies will be doing so on devices that are considered to be “embedded”.

For those of you in Fedora land who don’t know Matthew Garrett has just accepted an offer from Red Hat . If that name doesn’t ring a bell, it should. Matthew is one of the reasons Linux works on laptops. Being one of the few people who truly understands Linux from the hardware all the way up to the desktop, he will be spending his time working on power management in both Kernel land and Userspace.

It is great to see my company recognize the need for such improvements and hire top notch people to get it done. Welcome aboard Matthew.