January 2007

In a similar vein to the overreaction about Super Mario question blocks in Ravenna, Ohio, I give you today’s freak out in Boston:

Exhibit A.

Exhibit B.

Peter said that the talking head on the radio said that some group called “The Aqua Teen Hunger Force” was “claiming responsibility” for the “suspicious packages”.

Update: LOL IMHO :)

Update 2: The terrorist device in action. Why are all the news outlets and politicans calling this a “hoax”? That implies some sort of malicious intent to trick someone into thinking these things were “suspicious”.

I came across OSDL’s Desktop Linux Survey today and was pleased to find Beagle called out among other technologies like Firefox, LTSP, and Mono. The report says, “a major factor in the adoption of Linux on the desktop is the availability of applications,” and lists Beagle as one of “several significant commercial and open source applications [that] were realized for the Linux desktop.”

Also, I neglected to mention a few weeks ago about the European Union’s “Study on the Economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU.” (PDF). It’s a long document, but there’s a lot of good information in there. One thing that made me pretty proud but that struck me as surprising was seeing Ximian as the 8th highest contributing firm to free and open source software. Novell isn’t in the top 10, but there’s no doubt that the combination of Novell’s previous and subsequent open source efforts, SUSE’s many contributions, and Ximian’s code prior to its acquisition would bump Novell up a notch or two above Ximian’s 8th place.

Speaking of SUSE, the code behind the openSUSE build service was released under the GPL yesterday. I’ve been using it for a little while to build updated Beagle packages for SUSE, and it’s been a great tool to use. Congrats to everyone who made it happen.

Beagle 0.2.15 is out. As always, bug fixes, performance improvements, new features. We’ve got it all.

This version should be much better behaved than previous versions. We now take advantage of Linux’s SCHED_BATCH scheduling policy when available, we’ve replaced the RTF filter, we’ve moved the troublesome MS Word filter out of process for reliability reasons, and we’ve fixed problems with looping directories.

We have new KDE backends: KOrganizer and Konversation. I’m hoping the Konversation backend can be used as a template for things like an X-Chat backend (hint, hint).

And for the Mono geeks in the audience, this release is the first following our switch to Mono’s gmcs compiler (finally). We’re now on the .NET 2.0 profile, which has been a focus of the Mono community for some time. The class libraries are improved, but the biggest win for us is generics. We now get typesafe collections and value types are no longer boxed, saving us a bunch of unnecessary allocations. Hooray.

As always, get it from the Beagle wiki.

Christian: I’ve never been happy with the MIME spec either, and Ubuntu’s proposal doesn’t address my biggest issue: Sometimes you want to do something other than “open” a file.

This is a problem we ran into while doing the Beagle UI. If you have an MP3 file, you don’t necessarily want to “open” and play that file right away. Maybe you want to queue the song up at the end of your current playlist. Maybe you want to edit a photo rather than viewing it, or maybe you want to set it as your background.

So what you really want isn’t a MIME type to application mapping but more of a MIME type and action to application mapping. That way we can easily say, “What are the actions we can do with a file of image/jpeg?” and present them to the user, with an application behind it.

You can then extend this to replace the ugly command-line entries in things like gnome-volume-manager. You give devices special MIME types and actions as well. So you could have x-device/x-camera as the MIME type for a digital camera, “attached” or “hotplug” or “open” as the action, and have a .desktop file which handles the action, like launching F-Spot with the appropriate import command-line options.

Today is my 7th anniversary working for Ximian/Novell. When I started here, I was 19, I had just dropped out of college, I was basically penniless, I didn’t know anybody, and I didn’t have any idea what I was doing, but I was happy. Today, I’m a little older, I still don’t have a degree, I’m doing pretty well for myself, and I still don’t have any idea what I am doing, but I’m happy.

(Haha: Achtung, Spidermonkey (aka, Helix GNOME), and no sleeping.)

Tonight, my Ohio State Buckeyes take on Robert Love’s reviled Florida “we suck” Gators for the National Championship of the Universe in football. Robert was too much of a coward to show his face at work today, and so let’s just say he’ll be in for a rude awakening when he returns to the office.

Now to listen to the Ohio State fight song, Carmen Ohio, and Hang on Sloopy on repeat for the next 9 and a half hours.

Update: My lovely girlfriend Brette — herself an Ohio State alumna — has just informed me that a Meijer in Columbus has been selling gator meat for the last week or so. I think it’s a safe assumption that the alligator consumption rate in Ohio will have increased by at least an order of magnitude as a result of this soon-to-be-blowout. More shit-talking as the situation warrants.

Richard: The problem with all these build systems is that they’re all scripting-based, which has the same downsides as automake and autoconf. Yes, the syntax of the languages might be nicer and easier to deal with — I’ll take python over m4 any day — but they’re essentially non-deterministic. IDEs can’t easily autogenerate them and they can’t parse ones that have been edited by hand.

On the other hand, while a build system with some well-defined rules and a fairly strict grammar might be easier to handle with tools, there are always corner cases needed by projects that wouldn’t be possible with such a system.

Dan looked at using cmake for Beagle to learn a bit about it at the GNOME hackfest, but it would need a lot of work for GNOME.

The font rendering (in GNOME, at least) on openSUSE 10.2 is terrible out of the box on all 3 of my machines. Federico pointed me to this bug which gives some ideas on how to fix it, although it’s not clear to me how to fix it generally.

None of the presets under “Font Rendering” in gnome-font-properties are good enough. “Best shapes” is the best of the four, but then I went into the “Details” to fine tune it. First, I set the “Smoothing” to “Subpixel (LCDs)” since I’m running on only LCDs and I set “Hinting” to “Slight”. Now font rendering is pretty again in GNOME.

Firefox, however, doesn’t seem to follow the GNOME settings. So it’s necessary for me to put the following in my ~/.fonts.conf file:

<fontconfig>
<!-- Need this to override fontconfig/freetype defaults for Firefox -->

<match target="font" >
  <edit mode="assign" name="rgba" >
   <const>rgb</const>
  </edit>
 </match>

 <match target="font" >
  <edit mode="assign" name="hinting" >
   <bool>true</bool>
  </edit>
 </match>

 <match target="font" >
  <edit mode="assign" name="autohint" >
   <bool>false</bool>
  </edit>
 </match>

 <match target="font" >
  <edit mode="assign" name="hintstyle" >
   <const>hintslight</const>
  </edit>
 </match>

 <match target="font" >
  <edit mode="assign" name="antialias" >
   <bool>true</bool>
  </edit>
 </match>

 <match target="font" >
  <edit mode="assign" name="dpi" >
   <double>96</double>
  </edit>
 </match>
</fontconfig>

(Hmm, wordpress doesn’t seem to do CDATA…)

Restart Firefox, and font rendering is pretty there again too.

Kevin already mentioned it but didn’t provide a link: an excellent HOWTO on getting Beagle up and running on Ubuntu Edgy.

I just ran into a (fixed) Subversion bug when trying to merge changes onto a branch. If you run into similar problems, upgrade your svn to at least 1.4.

On the trunk, there was a ChangeLog file. That file was moved to ChangeLog.cvs, and a new ChangeLog file was created and committed to the trunk. This scenario is the cause of the bug.

The first thing I did was merge the changes from the trunk into my branch:

$ svn merge -r3160:HEAD svn+ssh://joeshaw@svn.gnome.org/svn/beagle/trunk/beagle

I fixed the few conflicts, and went to commit:

$ svn commit
Deleting       .cvsignore
Deleting       BeagleClient/.cvsignore
[...]
Transmitting file data ................svn: Commit failed (details follow):
svn: Out of date: '/branches/beagle-unified-indexes-branch/ChangeLog' in transaction '3192-1'

svn was confused because it looked like the replaced ChangeLog file that was merged in was older than the one already in the repository. Looking through the Subversion book, the right thing to do when you see this message is to run svn update. But that yielded an error too:

$ svn update
svn: Working copy path 'ChangeLog' does not exist in repository

After a little more digging I came across this mailing list post and this bug, pointing to a fix in 1.4.0. SLED ships 1.3.0, but openSUSE 10.2 ships 1.4.0, and when I did it on my openSUSE-powered laptop, everything worked fine. So if you see similar issues when doing branch merges, you know you need to update your svn. You can install updated subversion packages from the openSUSE build service subversion repo.