Older blog entries for bwh (starting at number 27)

Linux hardware support

Ted made an interesting point that Microsoft is failing to market the benefits of Windows, and instead seems to just be getting angry with people who are converting.

One of the features he mentions is Windows hardware compatibility. By and large, any random piece of hardware bought from a store is more likely to work properly with a Windows machine than it would with a Linux machine.

Of course, the more interesting question is, "How can we change that?"

Last week, Tridge and I had a discussion about exactly this. Tridge's idea is to create a distributed driver test farm, along the same ideas as the samba build farm (or distcc, or Seti@Home), except for kernel testing.

The idea's pretty compelling: I get ahold of some brand new (or old, or esoteric) piece of hardware that's unsupported under linux, stick it into a spare box, and run a shell script on the box that causes it to hook up to the distributed test system. Periodically, it gets told to download, compile, and run some new kernel code and tests, and rsync the results back up to the server. A fwe weeks later you pull the card out and put it in your main box, upgrade your kernel, and presto! it's now got full support and a lot of testing.

Of course, it gets interesting when you think about the details. What if the kernel panics, wedges, or otherwise goes out to lunch? There's a few ideas for this - software/hardware watchdogs, kexec, grub fallback, etc. I've been fiddling with these ideas a bit this last week (no eureka's so far, but still much to learn.) As a last resort, I suppose we could just encourage everyone to invest in a remotely controllable UPS so the system could power cycle their hardware as needed; this seems inelegant (and possibly hard on the hardware), but might be the ultimate solution.

I'm also curious about the testing itself. Initially, we could just do install tests (just load and unload the module), but I think ultimately we'd really need a crapload of tests. Maybe a given test could work across a range of drivers, but even so I imagine we'd be talking about a LOT of tests. Recruiting enough people to write enough tests seems like it'd be a challenge.

Yet despite the devils in the details, this idea has a huge upside. Imagine helping Linux beat Microsoft at its own game, and steal its #1 best feature? Imagine having MORE confidence plugging some random dohicky into your Linux laptop than you'd have plugging it into a Windows system? :-)

Aside from the boot robustness / power cycling functionality, I think it would not really be all that difficult to do. The code to do a test farm like this is a little complicated but nothing we've not done before. A lot of us hardcore geeks have at least one spare box sitting aside that they'd probably be willing to devote to this cause. And I'm sure like me you've got a random assortment of hardware that doesn't quite work right on Linux, (and probably some old stuff that doesn't work under Windows anymore either!) So the hardware should be doable too.

Summer of Code projects for inkscape

It's great to see the summer of code projects wrapping up. They've sure been effective at injecting some really interesting new features into Inkscape that I think users are going to be impressed with.

Also, it sounds like the students have had a good experience and felt included as part of the team. I've long felt that having an open, friendly community is the best way for an open source project to become prolifically successful, and I'm always happy to see the evidence at work. :-)

MythTV Club

I love Tivo. I want a Tivo access everywhere that I have a TV or computer, but of course the idea of buying a bunch of Tivo's and paying an extra $7/mo each seems just silly.

So I got thinking about it, and decided that MythTV is the way to go. I mean, setting it up shouldn't be a big deal; after all I install Linux on funky hardware all the time at work for testing NFS, and MythTV sounds simple in comparison. Besides, I know Kees, the guy who builds cables for disposable camcorders, develops MPEG2 editing software, and analyzes the Tivo file format for fun.

Of course, the devil's in the details and neither Kees nor I really relish the idea of gaining another project that takes tons of time for researching and tweaking. But we got to thinking and decided, why not set up a MythTV club at work. We know several other people who'd be interested in learning/experimenting/fiddling with it, and by being able to share notes and tag team on problems, it seems like we ought to be able to get it figured out pretty easily. Maybe we could even come up with some improvements to contribute back.


Several people on planet.inkscape.org have shared thoughts about the hurricane. If there is any silver lining to this disaster, it's that it's caused people to think more intently on issues such as the limits of our global oil supply, global warming, the ugly face of racism, and the fragility of our society in the face of natural disasters. I think a lot of people are really wondering at the clear failure of leadership shown in this disaster. I truly hope that people who believed that global warming, racism, and oil are not problems, or that are problems we can ignore, finally understand they are real problems that all of us have to find ways to solve. I also hope that people see that whatever your political beliefs, we desperately need a better national leadership than we currently have.

In ancient Greece, democracy was more than just voting for a candidate, as often seems to be the limit of American democracy these days. An important aspect in Greece was the notion of 'accountability'; the Greeks put as much (or more) emphasis into making office holders responsible for their actions (or lack thereof) as for selecting them for the position. I hope there will be accountability for those leaders who have failed to provide swift help to the victims of this hurricane, and I hope that the problems are fixed before our next major disaster, because scientists like those who predicted this "worst case scenario" have predicted other scenarios much more dire that may well lay in our near future.

RSS Feed for Inkscape

Today I implemented a new RSS feed mechanism for Inkscape. We'd been using WordoPress, but hardly anyone was posting news, and I found it too inconvenient to use and wasn't really posting much news myself. Before WordPress, we'd been rating a news item every few days very regularly, which users loved to see and set Inkscape apart from many other open source projects that rarely updated their homepage; ironically and unfortunately, while WordPress was in use it was unusual to see more than a couple news items a month.

Anyway, I finally decided to switch us back to the old system and get back to doing news items. Obviously this new system was not working for us. The two issues that had been identified with the old system was that it was hard for people to add news, and that there were not RSS feeds. For the former issue, WordPress may have made it easier for people but clearly there weren't enough people taking advantage of it to make it worthwhile.

The second issue was more problematic, and I quickly started receiving "bug reports" that the RSS feeds were broken after I started posting news items. Hrm.

So like any good Perl hacker, I hit cpan.org and found a handy dandy Perl module XML::RSS::SimpleGen, which automatically generates an RSS feed from an HTML page. This makes a static .rss file once an hour, which will make the Inkscape homepage more robust in the face of a slashdotting (we got hit during the 0.43 release with more traffic than WP could handle, and the homepage and rss feeds became unreliable).

Anyway, I'm also looking at using this for syndication of test results. The NFSv4 developers had requested such a capability a couple months ago. Also, my manager at work thought this would be a nice-to-have for our department, so we could present all of OSDL's testing news and data in an aggregated fashion.

dms screenshots


This is a cgi app running on my local box, that accesses the DMS server running on freedesktop.org and retrieves a list of 20 documents (unsorted), and then prints out a table of their basic metadata.


This shows updating a document's state (new, accepted, rejected, broken, etc.) You select the new state and click submit, the web client then submits the update request through soap to freedesktop.org, then when you reload the list view, the state is updated correctly.

28 Jul 2005 (updated 28 Jul 2005 at 16:32 UTC) »
Cairo tutorial at OLS

On Friday, Carl Worth gave a Cairo tutorial. He went through the Cairo API and explained what each function did, and we played with several example files to see how to draw shapes, write text, and so on. He showed how the same code could be used for drawing to the screen as well as to generating postscript output. The tutorial plus the required dependencies are posted here:


It was a very enjoyable tutorial. I learned a ton and found it quite inspiring. After the tutorial I browsed through the Inkscape codebase and got a little bit of an idea on where Cairo would plug in, and what sorts of changes would be needed to get us there. Migrating to Cairo looks like a lot of work, but it also sounds like it'll be quite fun.

Cairo is still in heavy development, and the focus to date has been on getting correct results moreso than optimization. I got a copy of ScislaC's Gaze SVG image for use as a stress case, and Carl and I tested cairo on it, and compared its rendering and performance with Inkscape. Cairo rendered the file badly, making ScislaC's fairie look like some undead creature. Carl found out that this was caused by a small bug in Cairo, which he's now fixed, and the image renders well. Carl measured that it took 48 seconds to render this with Cairo, compared with around a second or so by Inkscape. Carl will be able to use this file as a performance test case, with the objective of getting the performance down within range of Inkscape. He feels confident that between liboil and some profiling, this should be very doable.

I don't know if there has been very extensive comparisons of livarot and cairo, but my own tests and the informal testing I've seen others do seems to indicate that cairo is pretty close to livarot in terms of rendering functionality, however I'd want to see much more testing before we can say for sure. I'm confident that if any differences do emerge, and if cairo is found to be incorrect, the issues are going to get fixed swiftly. I don't think Cairo would be a drop-in replacement for livarot; I think there is additional code that livarot (and libnr) has that is out of scope for Cairo, that we'd need to repackage somehow and use, but it will take some investigation to identify what these things would be specifically.

The big news at the conference was the integration of GNOME/librsvg and cairo. Several people were experimenting with use of cairo for rendering the desktop widgets and such. Currently, it appears that Cairo development is heavily focused on supporting these efforts. Thus, Cairo seems to have reached a point where it is a viable replacement for the libart-based rendering code in librsvg, and work is progressing with that goal in mind.

However, note that the librsvg SVG backend that is under development isn't precisely what we'd need for Inkscape. The 'r' in rsvg implies that it's designed for single-pass-through rendering such as is needed for static SVG displays as you'd need for widgets and desktop stuff. Since Inkscape is an editor, what we need is a 'dynamic' SVG renderer, that allows us to interactively alter the drawing as the user moves things around, adds new drawing elements, updates style definitions, and so forth.

The good news is that Cairo itself is designed as a dynamic drawing library. It does not hold state on the items being drawn, and depends on higher level code to track the drawing elements. Thus, what we'd need to do is establish something like Inkscape's Repr and shape hierarchy, but have it render by making cairo calls instead of libnr/livarot calls. I think this will touch a LOT of the Inkscape code, but on the plus side by replacing the rendering code it should really cut down the amount of code we will have to maintain inside Inkscape.

21 Jul 2005 (updated 21 Jul 2005 at 05:47 UTC) »

Been catching all the talks on X and Cairo that I can here. I definitely think we need to get started on getting cairo integrated into Inkscape. It turns out that Worth joined Red Hat, he moved to Wilsonville, which is only about 15 from me.

I don't know if I have time, but I'd love to experiment with adding cairo as an optional renderer, so people could compare it with the regular renderer. It sounds like performance issues are expected with cairo, so probably users would like being able to select between the two depending on if they need correctness or speed of use.

Rejon and I also attended the talk on liboil, a library for "optimization of inline loops", which is a collection of MMX / Assembler code for optimizing things such as graphics rendering, transformation math, etc. Rejon and I chatted with David Schleef, the liboil author, afterwards, and it sounds like it could be a great candidate for majorly improving cairo's performance.

19 Jul 2005 (updated 21 Jul 2005 at 03:47 UTC) »
Naming inkscape

Mental blogged about back when we named Inkscape, and how eery it is seeing the name everywhere, and hearing everyone talk about it.

I don't remember all the details, but I remember brainstorming names with Mental. It was really important to me to pick a good names, because I know that for the name of a project can be key to its success or failure. A lot of people pick names that are silly, or inside jokes, or boring, meaningless acronyms, but I think these are limiting; they make your project sound too unprofessional, or too hard to remember, or too boring. We cracked the thesaurus and went through a LOT of variations of various words and combinations. Just about everything art related was already used. I remember when the name 'inkscape' came up, it was like, "Aha, that's it!" :-)

15 Jul 2005 (updated 15 Jul 2005 at 20:47 UTC) »
Inkscape in Ottawa

Next week at the Desktop Developers' Conference, I'll be giving a presentation on Inkscape. Good timing too, since we're also within a week of having the new 0.42 out. I'm hoping to be able to directly demo the new features, but using Inkscape with my laptop's touchpad is a bit cumbersome, and the mouse connector is not ps2 or usb so I'm not certain if I can get a mouse working with it. But I have a few days to figure this out so who knows...

Speaking of presentations, I was down at DreamWorks yesterday giving a presentation about NFSv4 on Linux to the film industry, and a guy from Novell (named Guy) noticed I'd been hacking on the Inkscape code in one of my xterms, and excitedly mentioned he'd just been playing around with it earlier that day. It's great to see how far Inkscape's spread through the Open Source world.

I'm also continually amazed at how well the Inkscape bug fixing process works. Before we started the release I was rather concerned about the quantity of bugs that built up since our last release. At first after starting the bug fixing phase, progress seemed slow, but I remembered from prior releases that it always takes time to build up momentum, so just waited. Holy cow! After a couple weeks it really got going, and in fact the last couple weeks has been the largest bug massacre I think we've ever had. I'm also impressed at how much teamwork there's been in the bug fixing this time through; it's common for five or six people to be involved in generating the fixes for the bug, integrating them, and validating them.

Render Test

I've started a tool to allow testing SVG renderers. Here's an Example. This allows you to take a set of .svg's and render them with a variety of svg renderers, and then generate a "diff" image to show how their SVG rendering varies. I'm hoping to extend this with more renderers, better reports, and more controls over the rendering process. I also want to run this over the W3C testsuite, and to start tracking it against the Inkscape codebase so we can see how rendering changes over time.

Inkscape and Google Summer of Code

If any students out there are interested, Inkscape's been accepted as one of the mentor projects for Google's Summer of Code. More info is at http://code.google.com.

18 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!