[cups.general] CUPS sucks!

Tue Aug 25 10:41:02 PDT 2009

On Aug 25, 2009, at 12:34 AM, ncoesel wrote:
>> *Embedded* platforms have different hardware, resources, and
>> capabilities than desktop or server systems.
>
> Wrong. Embedded platforms are just a few years behind. My old Linux  
> server (retired last year after 12 years of service) had a 90MHz cpu  
> and 32MB of ram and that machine ran X, SMB server, webserver,  
> printing, etc. The 'embedded' platform I'm working with has a 300MHz  
> cpu and 64MB of ram. It also runs X, SMB server, etc, etc. If it had  
> a bigger flash drive I could simply install Debian Linux on it (and  
> use it like a desktop system when I attach a keyboard and mouse to  
> the USB port).

OK, so you're saying that embedded platforms have different hardware,  
resources, and capabilities than desktop or server systems.

I don't care if today's embedded hardware runs as fast as 12 year old  
hardware - embedded systems have different hardware, which means the  
OS and software needs to support that hardware.

Most embedded hardware lacks an internal hard drive, which means  
either using flash which is slow for writing and not generally a good  
choice for temporary files or external USB hard drives which are  
significantly slower than an internal drive.

Most/all embedded hardware has a slower CPU (ARM is about 1/3 the  
instruction rate of X86 at the same clock speed) and less RAM.  
Printing to anything but PostScript printers is RAM and CPU intensive,  
especially if you use things like Ghostscript with Gutenprint or  
Foomatic drivers.

Now, CUPS is more than a print spooler (which is basically all LPRng  
is - you have to manually add/configure filters to make it do more),  
and there are a lot of non-CUPS components that get used to get dots  
on the page.

An embeddable version of CUPS would not necessarily provide everything  
that the current version of CUPS provides. In particular, we'd want to  
offer a direct print path (no spooling or queuing) since most embedded  
devices lack large quantities of high-speed storage space. And since  
the memory and CPU are typically limited as well, it would make sense  
to not do a lot of filtering or run lots of programs to convert the  
incoming print file to something the printer can handle.

So, it is no surprise that you were disappointed with CUPS on your  
embedded platform - CUPS is not designed to run there.

>>>>> Now I still need to solve an 'Unsupported format' problem.
>>>>
>>>> Sounds like you may want to enable raw printing - look at the
>>>> mime.types and mime.convs files included with CUPS.
>>>
>>> Sorry to be rude but 'Sounds like' isn't good enough for me. I want
>>> to know exactly why CUPS is giving me 'unsupported format'. Which
>>> programs it is trying to run (including paths and arguments), where
>>> parsing of a config file goes wrong, etc. According to internet
>>> forums there are several possible causes for the 'Unsupport format'
>>> error. The logfile should contain crystal clear information on what
>>> is causing the problem.
>>
>> Well, if you don't provide us with enough information about what you
>> are doing, how can you possibly expect an exact answer?!?
>
> See my answer to Helge. I'm just trying to print the test page.  
> Besides, my issue is not with the fact Cups doesn't print; I already  
> switched to LPRng which works like a charm. My issue is that Cups  
> cannot be diagnosed!

No, your issue is that you don't RTFM or ask questions with enough  
information so that you can get an answer.  Instead, you insult the  
very people you want help from.

WRT the test page, it is PostScript. The error says that that format  
is not supported for your printer, which likely means you are using a  
raw queue with no driver. The web interface is designed for DESKTOP or  
SERVER usage, which on Linux both rely on things like Ghostscript and  
the various printer drivers installed on the system.

The INSTALL.txt file in the CUPS sources says:

     **** IF YOU HAVE A NON-POSTSCRIPT PRINTER AND ARE NOT       ****
     **** RUNNING MAC OS X, YOU WILL ALSO NEED TO INSTALL GPL    ****
     **** GHOSTSCRIPT WITH THE "cups" DRIVER AFTER YOU INSTALL   ****
     **** CUPS.                                                  ****

> This is a big mistake! Every step should be logged when the log  
> level is set to maximum! Being able to trace the steps a piece of  
> software takes is essential to help system administrators solve  
> problems. I have a feeling that message is not getting thru. You  
> should work as a system administrator for a few months. I'm sure it  
> will change your perspective on how to write software that is easy  
> to maintain from a system administrator's point of view.

Um, I've done the system admin job (along with being a developer) for  
20 years.  I've also done the software support job (along with the  
admin and developer jobs) for the last 15 years, specifically for  
printing and this software.

The log messages that exist today are there specifically because they  
provide admins, developers, and tech support people the necessary  
information to identify and resolve problems. We *don't* log every  
step in debug2 anymore (look at CUPS 1.1.x's verbosity) because it was  
not found to be helpful - too much noise and you'd usually only get a  
small fraction of what you needed because the logs would be rotated  
too often with the default MaxLogSize values.

Instead, we've gone the path of reporting common problems in the log  
file ("Do you have Ghostscript installed?"), and in CUPS 1.4 we even  
have an auto-debug mode where the system can run with a low log level  
("LogLevel warn" is the default now) and when a problem happens we  
record the last N messages that were filtered out.