Printing Trends in Linux (O'ReillyNet)

Printing Trends in Linux (O'ReillyNet)

Posted Sep 28, 2007 1:03 UTC (Fri) by rlk (subscriber, #47505)
In reply to: Printing Trends in Linux (O'ReillyNet) by nim-nim
Parent article: Printing Trends in Linux (O'ReillyNet)

I think there's a bit of confusion here between Gutenprint (for which I'm project lead) and OpenPrinting (which I participate in in my role as Gutenprint project lead). I'm speaking for Gutenprint here.

>> different distributors take different approaches and basically supply different driver API's
>...
>> we've had to support three different driver frameworks over the year

> So you've contributed to three different frameworks equally, making none obviously better feature-wise than the others, and you wonder distributions didn't know which one to distribute?

More accurately, we (Gutenprint) have *supported* three different frameworks (different API's) -- basically, competing standards for drivers. Otherwise we'd be limiting who could use Gutenprint. Distributors pick their preferred driver framework; we don't get to make that decision for them.

>> So we have to fix bugs in both, come up with different workarounds for things like borderless vs. non-borderless printing (don't -- I repeat, do NOT -- get me started on that!), and every time we make changes, duplicate the testing.

> And time is wasted there, which you try to make up for by short-circuiting distribution release cycles

No, we just have to make sure that Gutenprint works with both of the currently-supported driver frameworks (CUPS raster and Ghostscript/IJS/Foomatic). People get really unhappy if we don't do our testing and we break their printer.

>> But what it does mean is that there has to be a reasonably straightforward way to install new printer drivers on top of an existing distribution.

> No, that means printer manufacturers must work together on a single common driver codebase with frequent stable releases distributions can easily package both before a distribution release and later as a in-cycle update.

Good luck getting that to happen. The only major cross-vendor driver package for inkjets *is* Gutenprint. The individual vendors at best release drivers for their own printers (open source in the case of HP, partially proprietary in the case of Epson, and not at all in the case of Canon).

> You're reinventing the third party binary drivers hell major distributions have spent major efforts weaning hardware manufacturers of, and you don't even have the constraints that make kernel updating difficult.

> Stop trying to do distribution and integration work in the distribution stead, focus on providing distributions what they want (a reliable code source), and your problems will just vanish. You've got enough problems on the code side without getting in the binary distribution business too.

Come again? The only binaries we distribute are for OS X, which is a special case. We do not distribute binaries for anything else. For that matter, we kicked all of the distribution-specific packaging (Debian control files, RPM .spec files) out of our source base before 5.0; we decided that either we had to support every distribution (which is of course hopeless) or just distribute source. We went the pure source route and let distributors and end users compile it.

> Speaking has someone who packaged distribution material for years, you're a victim of the common "distributions hate me" developer syndrome, where a bad source code release policy results in delays in the distribution-side propagation of your stuff, and instead of trying to understand why distributions can not work with your code releases, you try to short-circuit them and design custom binary payload distribution circuits instead. These attempts almost always fail miserably, because users have other things to do than learn a gazillon different installation methods, and anyway without the distribution integration QA level the result is a windows-like mess. But in the meanwhile all the useless stuff you've added to enable direct binary distribution makes your source even less easy to build cleanly for distributors, and you've wasted everyone's time.

I think this is the exact reverse of the true situation -- it's certainly the opposite of what I think I'm frustrated about.

The problem we've had (again, as Gutenprint lead) is that each distribution comes up with its own administration tools for printing, and uses a different database to store information about printing. Gutenprint can generate CUPS PPD files and Foomatic XML data, but that isn't always how distributors package their printing data, so if an end user wants to try our latest code drop, they don't manage to integrate it and complain (with merit) about the situation.

It isn't as bad as it was maybe 3 years ago, but even now SUSE expects you to use YAST to configure printers (and doesn't support http://localhost:631 out of the box), Fedora has its own tool, and I have no idea what other distributions do. So it doesn't matter, source or binary, users aren't able to pick up our latest driver package and "just use" it.

> The working strategy is:

> 1. agree with all the driver providers on a single driver code project, so you can make it obviously better than the others and have distributions focus on it

That just isn't going to happen: there are too many printers out there for any one volunteer project to support all of them. In any case, there are standards for drivers -- CUPS raster and IJS with Foomatic data -- that work. I'd rather see all the distributors switch to CUPS and use CUPS PPD files as their database, and support the web interface to CUPS as their primary administrative interface, but that doesn't seem to have completely happened.

> 2. have a fast release schedule so there's always a fresh & stable driver code collection for distributions to package when they hit release time.

We release when we have enough changes to usefully do so. However, there's a somewhat delicate tension between "fast release" and "stable", and sometimes we have to distribute beta quality drivers for new printers to let them stabilize.

> 3. always release solid code so distributions know they can rebuild new versions in-cycle as updates without fearing it will go bang on user systems

See above about testing. We try very, very hard to avoid incompatible changes during stable release trains (4.2 and 5.0). I'm very proud of what we did with 4.2. I also think 5.0 is a very good release. Unfortunately, we did have to make an incompatible change (related to margins) in 5.0.1. Even more unfortunately, we could only do it for the native CUPS driver; there was no way to do it with Foomatic.

> 4. Listen to distribution feedback, make the packagers trust you to fix stuff quickly when one of your releases have a problem

We listen to distribution feedback when we receive it. However, sometimes we don't receive it, and distributors try to fix things on their own without discussing them with us first. Two big examples that come to mind are one distribution (one of the more solid ones, in fact) that started using 4.3 (development) releases despite warnings that they should stick with 4.2 (stable) releases, and a distribution that tried to work around the paper margin issue in 5.0.0 via a really ugly hack. If the distributors don't discuss things with us ahead of time -- and some do, but some don't -- it's very hard for us to see what's going on.

---

(Log in to post comments)