Older blog entries for raph (starting at number 96)

I got somewhat stuck today implementing the PDF 1.4 blend modes. I did an algebraic simplification that I thought was nice, but it turns out to introduce a division by 1 - alpha. Since alpha can approach 1, this leads to numerical problems. Ah well, I'll just add yet another alpha channel when compositing non-isolated groups (that brings the total up to three).

You may find one of my bug images or another amusing. I suspect I'll have a lot more bug images before I'm done. PDF 1.4 blend modes are hard! Of course, I like challenges, and it's probably good for business - if I find it hard, presumably other people might as well, and would be inclined to simply use Libart.

While feeling stuck, I wandered over to the C2 Wiki. I had played with Wikis before, but somehow didn't appreciate how cool they are until now. Basically, they're structured as a nearly pure anarchy - anyone can edit any page. The cool thing is that this gives you the power to make the text you're reading better. Virtually all other "community" systems leave you powerless in this regard. Sure, you can add your own text, but sometimes that pales in comparison to simply being able to fix something that's wrong.

I also find that Advogato has just become part of the InterWiki namespace (see the Meatball:AdvoGato entry). This pleases me greatly. I feel like doing something to reciprocate, perhaps by adding an <interwiki> tag.

Also speaking of distributed networking thingies, Mojo Nation continues to show quite a lot of promise, and has gotten over some rather bad bugs that prevented the system from being useful. I've actually downloaded some music that I wanted to listen to :)

There's a lot of room for Mojo Nation to improve, but the Evil Geniuses For a Better Tomorrow seem to be quite good at that, and the code is also LGPL (and written in Python), so help yourself. In fact, once the substrate becomes solid, I wouldn't be surprised if a whole industry popped up of people doing interesting things with the network.

A few more pictures on the web pages of Alan and Max.

I'm back from lwce. It was quite a show - commercial beyond belief, but still it was a gathering place of geeks, so was worthwhile. The Eazel after-party was the high point for me, I think.

I've said it before, and I'll say it again: by focussing exclusively on the trade show aspect of the Linux business, lwce is doing a strong disservice. On and around the show floor, I put up a few dozen copies of a poster in protest. I would have put up more, but instead spent my time actually talking to other hackers, a better use of my time. In any case, I hope someone in the organization of the show listened, and that they start turning away from alienating the very people that make free software what it is.

The design of the ".org pavilion" was strange at least. All the .org booths were lined up against the far wall, with cage-like metal grids between the booths. I think they were shooting for a "spaceship" theme, but it came off as a minimum security prison instead.

I have very mixed feelings about the corporatization of free software. It's nice to be successful, but we need to stay true to our roots. Most people, including many in free software, don't have a clear picture of what our roots are. I think it's mostly about learning. I have a lot more thoughts on this subject, and will probably write up an editorial when I have a bit of time.

The ipaq is a very cool device. Jim Gettys carried one around running Linux, X, and a few simple apps, and was basically mobbed the whole time. I look forward to getting mine :)

I burned a CD of music for Alan. He'd been singing "Love Shack", "Larger Than Life" and several other songs he'd heard on the radio, and I wanted him to be able to listen to high-quality originals. I'm really looking forward to him being on the Internet and being able to get the music for himself. I don't think people have a clue how incredibly empowering it is for kids to be able to choose their own music. Downloading music from the Internet is here. Those who try to stand in its way are simply going to get run over. I hope we end up with a system that compensates artists better than the one we have now, but this is far from assured.

I've been listening to music using XMMS recently, and also playing with the waterfall plugin. Very pretty stuff, but the fact that the spectrum display is linear, rather than logarithmic, really bothers me. 90% of the screen area is given over to the high frequencies in the track. So when there's interesting things going on with flanged hi-hats, etc., you see nice patterns, but for the actual voice and melody, it's all munged together. I think I'd ditch xmms and go back to mpg123, but I find that the latter dies on a number of malformed mp3's, while xmms plays gamely through.

Code reuse

Dijkstra has long been a skeptic of code reuse. He has a quote that reads something like "the only reason to reuse a piece of code is if it's exceptionally high quality." I tend to agree with him. Take a skim through sourceforge or freshmeat one day and ask yourself how much of that code really deserves to be reused.

On the flip side, there is code out there that has been lovingly crafted and refined over a period of years (libjpeg and zlib immediately come to mind, but there are others). For some reason, these bits of code find themselves reused without inheritance, frameworks, contract programming, factoring, xp, or any of these other purported silver bullets.

So, I know am I crotchety old man, but I file code reuse and the many supporting technologies intended to foster it into the "only vaguely interesting" category. Concentrate on getting really high quality code out there, and the rest will take care of itself. Of course, that's really, really hard, probably beyond the reach of most free software hackers. Feel free to prove me wrong, though :)

Scripting

While we're on the subject, I find that a lot of the really low quality code out there is infected by what I call the "scripting mentality." Three facets particularly bother me:

1. Not checking error codes. Virtually all invocations of functions or commands should be of the form of: status = invocation(...); if (status) { cleanup() }. Having cleanup do the right thing (error logging, reporting to the user interface, making sure the system doesn't go into an inconsistent state) is often much more difficult than the task at hand. Yet it is absolutely necessary if the goal is a program that doesn't just break randomly. Commands do fail. Most script writers just ignore that.

Here, I think, is the perfect illustration of the syndrome: as of perl 5.005_03, the print function does not return a false value when it fails (for example, when writing into a full disk), even though that's promised by the manual. I find the fact that this bug is not even noticed enough to get it fixed is revealing.

2. Sloppy config information. Most scripts require some kind of config information just to function, and more to do useful things. Yet, getting the config information into the script is often compeletely ad-hoc, often involving both environment variables and hand-editing files.

3. Quoting. Since scripting languages and the interfaces to scriptable components tend to be string-based, there are usually string quoting and escaping rules that have to be followed. Yet, it's so easy to ignore these issues. The Web, with it's wonky URL and query escaping rules, is particularly vulnerable. Unix sh quoting problems are a rich source of material for the Unix Hater's Handbook as well.

Thus, I consider the scripting approach to be quite valid for one-off jobs when programmer time is critical, and the person using the script can understand and deal with the consequences of errors without too much pain. It doesn't tend to scale very well to the case when lots of people other than the author will be using the code.

DDoS

This morning's slowness at Advogato was caused by a DDoS against the Berkeley computer science subnets, facilitated by people breaking into RedHat boxes on campus.

Our computing infrastructure is so fragile and untrustworthy that it really should only be considered a toy. Yet, somehow, we manage to get our work done!

Woohoo! Serious progress on the glyph cache. You can check out my most recent code from nautilus/librsvg. The new test rig (test-ft-gtk) shows quite decent performance, and I'm not done optimizing. It also has a nice, pretty display when used with the xdvng.pfa font from itrans.

This test shows that client-side rendering of aa text is probably a lot more reasonable than many people think. Of course, when the Render extension happens, aa text will be almost indistinguishable in speed from xlib's current text.

Thought I might touch a chord with the Adobe font rant.

graydon: Yes, unifont is cool stuff. It's not at all fair for me to say that there's nothing going on in the world of free software fonts. Reaching into history a bit, you'd also have to give the Metafont project major props both for incredible technical innovation and a library of highly distinctive, useful fonts.

But my point still stands; if you try to point to any free font work that directly compares with Adobe's latest OpenType efforts, you will come up empty.

Regarding compilers and other bits of infrastructure: yeah, that stuff either needs to be free software or something very much like it. The idea of putting bits of this infrastructure into brightly colored shrinkwrap boxes distorts the whole endeavor incredibly destructively. Proprietary operating systems and tools tend to suck really hard because of this. However, the new Adobe fonts most emphatically do not suck.

Mulad: I'm not complaining that there's no money for free software development. In fact, I manage to get paid pretty well for the work I do. What I'm complaining about is the indirect nature of this funding. OctobrX, Raster, and others are in the position of being sponsored by a patron (in their case, a public corporation losing money at a dizzying pace). Further, I support my free software habit through consulting and other "day job"-like activities. It's a very different thing than simply being paid for the work I do, an option provided by the proprietary model, but denied me by free software.

Let me try to present my argument again. All software sucks, most of it pretty badly. When you try to analyze the causes of this suckage, two winning strategies to make software suck become immediately apparent.

First, you can fail to bring adequate resources and talent to the project, dooming it to being hopelessly amateur. For some projects, free software does manage to make these resources available, mostly for bits of widely-needed infrastructure. For many others, it simply doesn't.

Another good way to make software suck is the familiar story of decommoditization: basing it on complex, ambiguous, and ever-changing "standards" as a way to create lock-in and drive the upgrade treadmill. Microsoft Office is basically a canonical example of this, but certainly not the only one.

Note that neither proprietary nor free software have a lock on either kind of suckage. For example, I consider sendmail a really good example of a piece of software which has managed to lock in its market segment by being bad. And for demonstrations of lack of resources, just look at any segment of the market without an ultra-compelling economic argument, for example Be applications.

All I'm saying is that whenever somebody comes up with software that doesn't suck (or sucks less, anyway), we should sit up and take notice, and ask how it came into existence in spite of the powerful forces which always seem to subvert it.

C++

Over the past few days, I've had the pleasure of speaking with the creators of both Inti and Gtk-- about techniques for wrapping C libraries with C++ API's (this is in the context of Libart). It's not hard to see how the split came about. These two projects have radically different approaches. Karl Nelson seems to be in love with every trick in the C++ book. He encouraged me to consider multiple inheritance, using streams for operations on images, String-like objects for paths with copy-on-write semantics, and more. Havoc, on the other hand, encouraged me to use refcounted pointers, with a link back from the C object to the C++ counterpart. Inti is basically very C-like (ie, pointers are still pointers), but with type-safety and some other nice features that C++ provides. Even though the relative simplicity of Inti appeals to me, I don't think it's what I want. A user of Libart will often create many short-lived objects. It makes a lot of sense to use stack (auto) allocation for those - you get static enforcement of constructor/destructor pairing, almost for free, and code is a lot cleaner if it doesn't have a lot of explicit memory management stuff hanging around.

Taking a step back from the Inti/Gtk-- split for a minute, though, I'm convinced that the real problem is simply C++'s overweening complexity. Providing a nice, high-level wrapper for Libart should be a relatively simple task. However, C++ makes my design space really, really big, especially when it comes to options for memory management. I'm becoming more attracted to C++ now that it's (sorta) becoming a standard, and that decent implementations are becoming available, but I also feel that constant vigilance is needed to fight back the complexity that the language introduces, to keep it from infecting the rest of the project.

Ah, I can breathe a bit easier. Finished up one consulting job and sent an invoice. Now I can turn my attention to all the other consulting jobs I'm a bit behind on :)

I spent a bit of time looking at Adobe's new OpenType fonts. Wow. There is some amazing work that's gone into those.

Not to sound like a broken record, but I think it's a damn fine thing that the designers of those fonts are getting paid for their work. This is a golden age of font design, and it wouldn't be happening if there weren't copyright protection for the fonts, and if it weren't for the legal right of companies to demand payment for the use of the font.

Seeing beautiful work like this causes me to question my involvement in free software - what we're doing in terms of fonts is so pitiful and ugly by comparison, it's not funny. The fact that the free software model can't directly compensate people for their development work is one of the worst things that's broken about the model.

Of course, this is fonts. For software that makes up the computing infrastructure, the usual proprietary software model is even more broken, giving as it does incentive to produce complex, bad, buggy stuff. I really wish there were a better model. I don't know what it would look like, though.

I'll be at LWCE Wednesday and Thursday next week. I'm not looking forward to the show at all, though. I wouldn't be going at all if it weren't for the fact that there are going to be quite a few people there I really want to meet. For the organizers, it's obviously just another trade show, with no concept at all about what makes free software unique. I will doing a small, modest, low-tech hack. If you're going too, let me know and you can join in as well!

I'm still at Pacific Yearly Meeting, but will be back in a couple of days. It's really nice to have some time away from the daily crush. It's also a good way to spend more time with the family. As I expected, everybody loves Max, and Alan seems to be finding his legs this year - he's really making friends.

This year, I'm on Secretariat Committee, which means putting out the daily newsletter, and also dealing with the various disks that people bring in for printing, editing, etc. I knew that file format conversion from word processors was problematic, but I didn't know until now just how much of a mess it is. Very basic things you'd expect to work, don't.

My sense is that this is an extraordinary opportunity for free software. All you have to do is create a word processor that does a reasonably good job at handling all these wacky file formats. That's probably a fantastically hard problem, but on the other hand, it feels to me like something us hackers can deal with. Samba, for example, is an excellent example of a piece of software organized primarily around compatibility with strange proprietary protocols.

Between some intense controversy on the Gnome lists and some of my own work, the subject of taking on dependencies has become interesting to me. I think I'll write a front page essay on the subject, but here are a few scattered notes in the meantime.

How do you choose whether to take on a depencency to another project? On the positive side, you're reusing code, delegating maintenance tasks to others, and in general going in the direction of sharing. On the negative side, you're placing quite a bit of trust in the maintainers to provide usable, maintained code of sufficient quality. Further, you're taking on the risks of "impedance mismatch" where your needs don't match the functionality provided. Lastly, you're taking on the cost of version skew.

In my essay, I'll probably do a ToC-inspired analysis where you have N different projects using a single dependency. If each takes on a fair share of the maintenance responsibility, then the cost of using the dependency is 1/N the total maintenance cost, plus whatever integration cost is incurred. In some cases, this can be a strong win.

A really fabulous example of a dependency that's desirable to take on is libjpeg. It provides high-value functionality (ie, you don't want to write your own jpeg codec), is already used by a huge number of important projects, and is mature and stable enough that you're probably not going to get bitten badly by version skew. Does your app deal with jpeg files? If so, use libjpeg or suffer the consequences.

Dependencies can be libraries, languages, or build tools (and probably other things I'm not thinking of right now - actually, standards came to mind as I was previewing). I think many of the same analysis applies to all three. Certainly, a dependency on build tools is a serious issue for many free software projects. In addition, I think the importance of version skew for language choice is often underestimated. This is, I believe, one of the major reasons we prefer C so much. Only now that C++ is slowly converging on a (well-implemented) standard is it a reasonable choice as a dependency for serious free software work. Similarly, scripting languages such as Perl and Python are hardly suitable for code expected to last a long time - both are undergoing deep-seated revision.

Anyway, these are just ramblings - I'll try to pull together an actual point when I write it up for the front page.

I'll be spending next week at Pacific Yearly Meeting with my family. Don't be surprised if I'm hard to get in touch with.

The last couple of weeks have been pretty intense, mostly with nonbillable, noncoding work. I guess it all pays off in the end, but I'm looking forward to getting back to some actual developement after I get back. Of course, then there's LWE. Ah well.

Max just started laughing today (or maybe yesterday). All else pales.

I just got back from visiting Transmeta and attending the VA Printing Summit. For a good picture of the latter, read Grant Taylor's excellent notes.

Kudos to VA for organizing the event, and in style. It's always a great service to bring a number of passionate hackers together to work on free software, and even nicer when done in style - a nice hotel, good food, good discussion rooms, etc.

One of the interesting aspects of the summit is the way it brought together people from disparate communities (that's what "summit" means, I guess).

The speaker for the HP presentation explained that since they wanted "great Linux printing", they naturally went to VA Linux (Nasdaq: LNUX). Ok, so they didn't quote the ticker symbol, but it was clear that their thinking was business-to-business. Yet, after many months of work by a number of talented hackers, the results aren't that impressive. Yes, there is quite a bunch of code now for print spooling scripts, GUI config tools, libraries to deal with some of the low-level detritus that inhabits printer space, etc., but almost none of that is shipping with distros or particularly well integrated with other projects.

Part of the explanation, I think, is that HP's goals are somewhat different than those of the free software community. Our goal is not "great Linux printing", it's printing that doesn't suck.

To me, one of the high points of the summit was the vendor relations breakout session. It's clear that most printer manufacturers want to support Linux well, but just don't understand very well how to do it. After all, their business is making printers and selling ink, not acting as an arm of the Borg. So a lot of time was taken up (very productively, I think) thoughtfully explaining how our development processes work, answering questions, and going deeper into some of the more subtle points. I think it would be interesting to distill and bottle the discussion we had. In the meantime, support for inkjet printers benefits.

The summit really highlighted for me how we're not just forming a community, we're developing a complete culture around what we do. From this culture flows the way we make decisions, manage change control, cooperate intensely even as we compete, and our passionate, complex, subtle and certainly not homogenous attitudes towards intellectual property. And all of this is wildly different than in the proprietary software world.

More down to earth, the IBM Omni driver sure looks interesting. Basically, they're taking the printer driver library from OS/2 and releasing them as free software. It appears to be a clean, modular design, and obviously a huge amount of testing and development with real printers went into it.

I was also amazed at the rapid rate of progress that the Gimp-Print project has been making. I'd say those drivers are now roughly on par with Epson's, certainly in some ways noticeably better. Robert Krawitz and I are both eager to integrate Even Toned Screening, which should hopefully improve quality even more.

A few more quickies. kuro5hin, really sorry to see what assholes have done to your site. I eagerly look forward to its return. matt, you raise a lot of good points. The trust metric tries its best, but the accuracy of rankings is clearly limited by the quality of data going in. People, read the cert guidelines. Just using free software is not enough to earn a cert - you have to actually contribute something back. Not that there's anything wrong with using free software (I'm sure that's how we recruit nearly all of our developers), but that's just not what this site is about.

Word up to all the homies I've been spending time with in the last few days. I do greatly enjoy the real human contact.

I'll be at the VA Printing Summit in Sunnyvale Thursday and Friday. If you are in town and want to meet me, probably the best bet is to leave a message at the Sheraton, where I'll be staying (unless, of course, you know my pager number).

The summit itself ought to be quite an experience. There are a lot of issues to be hashed out. I have little or no hope that any of this will actually get resolved at the summit, but I do expect that a number of personal relationships between people in Linux printing space will grow. In my experience, it's these relationships that drive actually getting the work done. Kudos to VA for organizing the summit - we'd probably be wringing our hands a lot longer if they hadn't done it.

I made rinkj print samples today. Of course, rinkj (using Even Toned Screening) is better than anything else out there, but Gimp-Print has made dramatic improvements in the last couple of months. I'll be talking to Robert Krawitz about folding in rinkj, so it should be even better.

Next week is Quaker Pacific Yearly Meeting. I've been working at full bore recently. I think this will be an excellent time to take a step back and reflect a little. Plus, it's a really good way to spend lots of time with my family.

Oh, and there are new Libart mailing lists - follow the link. I won't be around much in the next couple of weeks to respond, but maybe people will find it useful to join up anyway.