Re: [Printing-user-general] Why has nothing changed?

In article <[email protected]>, [email protected] (Roger 
Morgan) writes:

> Two years ago, Eric Raymond posted his experiences with CUPS:
> http://www.catb.org/esr/writings/cups-horror.html
> in which he points out, with specific examples, that CUPS is a nightmare
> to configure.

He doesn't "point out" -- he erroneously assumes!

Because the main problem he did run into were not at all caused by CUPS, but 
by his distro's packagers,...

  ...first, by the crappy redhat-printer-config tool his distro shipped to 
     work around the native CUPS configuration tools,
  ...and second, their various patches they used to effectively fork
     CUPS from the upstream source, while at the same time not providing
     documentation + configuration tools that handled the fork's substantial
     differences well.

> Today, in 2006, it is obvious to anyone who looks at the forums that CUPS is
> *still* a nightmare to configure. Practically no progress has been made in 2
> years.

CUPS in itself in fact is much easier to configure now, and even more powerful 
than 2 years ago.

But I still have to agree with this point: the nightmare has continued. The 
distro-based forking of CUPS is even worse now. Take Ubuntu. While CUPS 1.2 
has removed the previously supported "RunAsUser" feature for good, Ubuntu are 
now enforcing it, without even retaining a cupsd.conf option to set it 
to "RunAsUser No"!

This leads to all kinds of weird bugs and difficulties for Ubuntu users, some 
of which have been spelled out well in Kurt Pfeifle's blog 
(http://www.kdedevelopers.org/blog/418 ), who also was the first one to make 
me aware of what's going on with CUPS packaging on the distro front.

> What needs to change is not just the unusable documentation and misleading
> GUI. What needs to change is some attitudes.
> 
> Most people who try to configure CUPS eventually come to Kurt Pfeifle's 
> page on CUPS Troubleshooting:
> 
> 
http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/VII.cups-help/
VII.cups-help.html
> 
> Almost everything on this page is WRONG. I don't mean technically wrong; 
> I mean that any piece of software that requires this advice, needs to be
> junked and rewritten. 

Dude! Take your pick: 
 - *Either* accuse Kurt Pfeifle of writing crappy documentation.
 - *Or* ask the CUPS developers for a re-write of their software 
   (better do it yourself, man, if you are clever enough for this rant!).

It's very easy to demand a piece of software to be junked and rewritten. 
Especially if you don't pay a penny to its developers, or don't contribute a 
line of code for it. 

But it is very difficult to be taken seriously when airing such ultimatums in 
public forums, dude.

> Examples:
> 
> Example 1:
> "Did you make sure you checked the CUPS man pages ? The most important 
> ones are those for lpadmin, lpr, lp, lpc, lpq, lpstat, cupsd.conf, lprm. 
> At the end of most man pages you might be pointed to other man pages. Go 
> read them too."
> 
> My response:
> You mean I need to read an unspecified number of 'man' documents but at 
> least *eight*, IN ADDITION to the CUPS manual, just to configure a printer? 
> GET OUT!!

If Kurt Pfeifle *really* gets out, you personally won't be able to replace 
him. Not with your trolling. You'd first need to learn how to present and 
explain well technically difficult stuff in your writings...

My rebuttal 1: 
Man, you are quoting a troubleshooting guide, understand? A TROU-BLE-SHOO-TING 
GUI-DE! That type of document typically is not meant to be consumed by end 
users. You only turn to it if you have problems. And if you come across 
problems you need to solve, you have to read documentation. Sorry for that, 
can't change this.

To "just configure a printer" I'd expect the *distribution* to prepare 
everything in a way that it Just Works (TM). After all, the distros get money 
for Linux, not the developers of free-as-in-beer (as well as 
free-as-in-liberty) software developers.

If a distro makes modifications (for the sake of supposedly improved 
security), that make the software less user friendly, don't flame the original 
software developers, please! And don't flame the very people either who spend 
their free time to write up documentation (that was only required to work 
around and troubleshoot the distro's messing up) -- you're just exposing 
yourself to ridicule.
 
> Example 2:
> "What was the exact command you gave to install it? Example: lpadmin -p
> 1st-printer -v socket://10.160.16.102 -L "Next to my desk" (Won't work: you
> used a dash in the printer name and it doesn't start with a character, 
> which at present is "illegal" with CUPS; your socket device URL will most
> likely not work if you don't give a Port number; you forgot the "-E"
> parameter..."
> 
> My response:
> The response is meaningless as written, which suggests that nobody has 
> read it seriously in a couple of years. Yes, I know we all make typos, 
> this post probably has a few. But mistakes in troubleshooting advice 
> which make the piece of advice incomprehensible should be weeded out.

My rebuttal 2:
OK, go for it. I'm looking forward to the much better troubleshooting guide 
you are going to write, dude. (My secret suspicion however is this: a troll 
will very rarely turn into a useful member of the community - but wonders 
sometimes do happen).

> Example 3:
> "Switch on the "debug" mode in the LogLevel directive for your CUPS 
> daemon. Edit /etc/cups/cupsd.conf (....) Watch what is written to your 
> CUPS error log"
> 
> My response:
> Debug mode and a logfile are debugging tools for the developers. No 
> user should ever need to go near either of them. The CUPS software 
> should be able to figure out whether or not bits are getting as far 
> as the printer. And it should be able to tell the user which piece 
> of the chain is missing (if that's what's wrong).

My rebuttal 3:
Yes, debug mode and debug logfiles are debugging tools. Yes, they are mainly 
meant for developers, administrators, help desk people and ambitious power 
users. But who, if not the user himself, should enable them? Who should 
retrieve the logs? Who should send them (or extracts) to the developers? You 
are not seriously suggesting this should be implemented in a way that makes 
the software automatically "phone home", are you?

Kurt has just describe (very well, IMHO) to administrators, help desk people 
and ambitious power users how to enable the debugging, and how to draw the 
best benefit from it. And you, you are slamming him for this service? "GET 
OUT!", to use your own fine words...


> Time to fork the CUPS project?

Muahuhahahahaaaaaa!!! That's hilarious! I couldn't help to laugh out loud when 
reading this.

Either you are trolling. Or you are serious about it. 

*If* you are serious, I wish you luck and success!

In *any* case, you don't seem to understand, that CUPS in fact is already 
forked by some careless distro packagers, but not in a very conscious, planned 
and knowledgeable way. They didn't even have printing functionality and ease 
of printing in mind when they forked it (they cared very little) -- they 
mainly had some theoretical improvement in *security* in mind, and were very 
willing to let hundred of thousands of users pay with reduced functionality 
for that dubious benefit.

And also, you don't seem to understand *at* *all* under which conditions a 
fork usually occurs in the Free Software world. Examples:

 * A project's group of developers can't continue to cooperate on a common 
   base. Either because of clashes over personalities, or because of
   fundamental differences over product design (often because of a 
   combination of both). The groups part ways, their forks compete (or 
   cover different niches and survive both) and in the end one prevails, 
   by merits of their free competition for users.

 * A valuable project dies due to its developer(s) becoming inactive. For 
   some reason new people willing to take over the torch can't get direct
   access to the old project.

 * A valuable project turns back and rejects new people arriving on the 
   scene with new ideas, which they try to implement in the framework of 
   the existing project first.

None of these general conditions apply to CUPS. CUPS is not dead, but very 
actively developed. CUPS developers are very open to suggestions. Even you 
would be allowed to submit any number of "STRs" (software trouble reports) 
and "RFEs" (request for feature enhancment) at http://www.cups.org/str.php and 
have all the world to see how your requests are dealt with. You can submit 
code, documentation, translations and have a good chance to get it accepted if 
it is worth harsh criticism you express here. Please do at least try this 3 
times, and have it rejected, before you even *think* again about "fork the 
CUPS project"...

Please also read up at http://www.hyperdictionary.com/ about the meanings of 
such words as "loony" and "babbling" (and also brainless, crackbrained, daft, 
dumb, gaga, half-baked, moronic, wacky, silly, insane and 5 dozen more) before 
you ever again *mention* in public that "fork the CUPS project" brainfart of 
yours.

Ts, tss...