J5’s Blog

It seems that Moblin will be switching from Ubuntu to Fedora Linux as their base operating system.  I’m interested in finding out the underlying reasoning for such a move.  The stated reason is because they wanted to use RPM instead of DEB.  I can’t quite buy that but perhaps that is because having come from both camps I think that packaging is an implementation detail that too many people put way too much stock in.  This has the effect of causing unnecessary emotional splits within the community resulting in animosity which often overshadows real threats.

The second reason given, which has to do with building a community is pretty broad but more believable.  Fedora has made huge strides while also sticking to its guns in the freedom department and being valuable upstream contributors. It may be that we sacrificed short term gains which can be gotten via a bit more differentiation, or out of the box “just works” on closed hardware but as companies are being convinced to open up their specs and open drivers are being written, a large portion of which is being done by Fedora developers working upstream, little of the short term gains matter much.

I suspect the real reason is somewhere in the community vein, staring with the Kernel and X team developers who work tirelessly making sure their work is fit for upstream consumption and can be supported in the long term. Following their lead the rest falls naturally out of that single notion of moving Linux forward as a whole. Kudo’s to all my Fedora friends - keep moving forward.

We’ll I’m going to dive into the deep end (flames welcome) because I have been talking to people about the Qt “possibility” since Nokia bought Trolltech and GNOME was considering what to do for the future of its toolkit.  I can see the headlines of yet another GNOME developer advocating using Qt4 as the basis of future releases but this simply is not the case.  It is, in its basic form, an exercise in “what ifs?” and an iterative process of looking inward at our ecosystem and seeing the pros and cons of certain directions we could take.

Is this going to happen?

First off this is a highly unlikely scenario. The planets would have to align, Qt would have to go LGPL, Nokia would have to loosen controls on contributions to avoid a fork, the Qt team would have to accept a community which has slightly different goals and the GTK+ team would have to signal their willingness to move. We are not going to turn our back on the great work the GTK+ teams are doing and most certainly the base libraries we use such as GStreamer wouldn’t change.

What are the possible advantages?

• Less confusion for the non-insiders on what to learn and program for
• We can get rid of the whole Freedesktop common widgets talk (e.g. Print and File dialogs) which is nonsense and a distraction anyway
• Hopefully less bickering in the community meaning a more unified and focused front against larger threats
• Focus can move from the lower toolkit layers to the higher level desktop layer which really define the value differences between GNOME and KDE
• Easier technology sharing

Note that these are all only possible advantages and may not even happen even if there was a move.

 What are the possible disadvantages?

• More bickering on how to write applications (who’s approach to usability wins out?)
• Less focus and a return to writing applications without a shared guideline (just look at old XLib interfaces - almost like snowflakes)
• A loss of identity
• Loss of amazing GTK+ developers who may feel abandoned
• Splintering of the community so we have parallel GTK+ GNOME and Qt4 GNOME development
• Screwing ISV’s who bank on GTK+’s stable interface
• GTK+ isn’t just a license - we would be losing a lot by switching away from the codebase
• Falling into the growing pains GTK+ 2.0 brought GNOME and Qt4 is still bringing KDE
• A loss of activity at Freedesktop.org which is actually sometimes useful in producing dialogue and shared practices
• A loss of control over the direction of the toolkit effecting the quality and feel of the GNOME desktop
• Really a lot of development is moving to the web - will toolkits be important enough to warrant the pain of the move

What this wouldn’t be

This wouldn’t be a merging of GNOME and KDE.  Each community has a different idea of what constitutes a usable desktop and Qt would simply be an implementation detail bellow GNOME.

Conclusion

This is pretty much a pipe dream.  It solves some issues while creating a whole host of different ones.  I’m not going to advocate it other than seeing what peoples reactions are.  On the flip side if the work was put behind it, the planets aligned, and both communities came to an agreement I wouldn’t object to the arrangement.  Needless to say, I’m not holding my breath nor would I be elated or saddened if it did or did not happen. To me it is all what is best for Linux, GNOME, Free Software and the wider market. It is unclear what direction would be best (any claims to that knowledge would be suspect) but honestly and actively looking at the possibilities is a useful activity, however remote. People reading should not put their “hopes and dreams” on this or believe it to be more than it is.

Istanbul was a great place to have GUADEC this year though I wasn’t really able to be a part of the regular conference schedule due to my Foundation duties.  These days I am mostly around for the community aspects and to get a feel for where said community is headed.  To that effect for me GUADEC is mostly about friends, food, beer and moving GNOME forward in a stampede of boisterous hackers with common interests.  Along those lines here is a summary of GUADEC though my eyes (more…)

That’s right, in order to support the upcomming release of GNOME 3.0 which is introducing a new tabbed interface, we’ve totally made D-Bus HIG compliant by adding tabs to the API.  No longer do you have to select a system or session bus while connecting.  Now all you have to do is select the correct tab and you are connected.  Now you might be saying, I can’t see these tabs.  Because of constraints of the D-Bus system, namely not having a GUI, we had to add virtual tabs.  Don’t worry, they are there, you just have to randomly click and eventually you will select the right bus.  Or you can simply use the new D-Bus Gtk+ bindings which exist to provide a GUI in which to display the tabs.  A word of warning though, because of Qt4’s abstraction layers when using the D-Bus Qt4 library they will show up as plasmoids.  We here at Freedesktop.org hopes this makes your D-Bus hacking a much more enjoyable experience.

When asked who in the audience

• are GIT users? - roughly 90% of the hands in the room went up
• are BZR users? - less than 5% of the hands in the room went up
• are Hg(Mercurial) users? - roughly the same as BZR, perhaps a few hands less

Converse amongst yourselves.

That is to say I have a direct flight today from New York to Istanbul today.  I’ll be ariving early tomorrow morning and will be staying at the Hotel Golden Horn in Sultanahmet.  This should prove to be one of the best GUADECs ever.

Reading the comments in Zeeshan Ali’s blog make me a bit sad that the issue of giving credit was somehow brushed aside instead of fomenting a good debate on the nature of credit within our communities.  I would have to agree that Zeeshan’s post was a bit polarizing and in any polarized situation people tend to retreat to their corners and bend their arguments around the space they feel they need to defend.  For the sake of academics let’s take it from a different angle and examine the nature of credit in GNOME.

Being that no license that is used by GNOME has an attribution clause (besides having to keep copyright notices intact) is it legal not to give attribution in a document which references a licensed work?

Perfectly legal.  It has been noted that there are attribution licenses but only one is accepted by the OSI and none are compatible with the GPL or its derivatives.

What about ethical, especially if the author has requested it?

This one is up for debate.  If the author has not legally bound you to do so it is correct that it could be needlessly burdensome to list out every contributor in every press release.  This is the number one reason why attribution licenses are frowned upon.  However it behooves an entity to point out and acknowledge the contributions of others, a topic I will go into later.  It is utterly unethical to claim credit for others work or use language that implies such.

Why is credit important then if things can be taken and used legally without attribution?

Like it or not, everyone has their own reasons for contributing to the Open Source ecosystem (shockingly we are a diverse bunch).  Far from being the vestige of communism that many people tried to paint the Free Software and Open Source movements in the early days, the ecosystem is a true free market.  Remember the free in Free Software is about freedom not price.  The price paid for people releasing their code into the wild increasingly these days has been money but is still overwhelmingly supported by code being contributed back, recognition from peers and credit for the time spent not doing something else.  To push aside giving people credit for that work that they have done runs the risk that they will not contribute in the future.  Credit is the grease that allow our cogs to spin freely.  Karl’s contribution to some may seem small but if it wasn’t him would anyone else step up to the to do the same things?

So if putting every author of every package on a press release is prohibitively expensive what should we be doing?

Language and attitude are key here, especially in public.  If an author feels they aren’t getting enough credit it is something to look into.  Words should spell out what has come from the hard work of external contributors, because if after all we are willing to praise ourselves for our own contributions then acknowledging that we stand on the shoulders of giants shouldn’t be a burden.  Blogs and talks are excellent places to give credit.  The kernel talks often do this very well even though they can’t list out every contributor, and I recently saw an animation of the development of python that excellently visualized all of the contributors over a period of time.

Credit where, credit is due.  It is an important part of our culture.  Without it the ecosystem breaks down and that is a large price to pay for not saying thank you. Viva La Upstream!!!

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.

I’m at the Red Hat Summit and FUDCon listening to Joel Cohen’s keynote. If his name doesn’t ring a bell, he is the associate producer of the Simpsons. What does this have to do with Linux? Scenes from the Simpsons are actually rendered on Red Hat Linux before being approved and going the more traditional, and expensive route of hand drawing the cells. It is a cool example of how technology and specifically Linux can streamline traditional work flows.

…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.