Slashdot Mirror

That's exactly right. If you're going to an LPD capable printer, you can just set up a queue to the printer directly. You then don't need the HP 4000 print server at all!

I do wish people would apply a little more brainpower before getting their undies in a bunch over a triviality.

Of course, if you're setting up a new network, you'd be better to start thinking about the Common Unix Printing Ssytem or maybe LPR Next Generation instead of dealing much with LPD.

So the next problem is how to change the stuff so the printer understands it. You may want to look at IFHP which was written by the same guy who wrote LPRng. It's quite good at talking different printer languages.

There is also magicfilter which can talk to plenty of printers as well though you often need to collect all the auxiallary programs for it to fully work.

I have a HP printer, and so know of two other programs. They're packaged together as djtools in Debian distribution but I think they're called hpset and djutils or something similar. They help with using the HP PCL.

Remember, the copyright holder can release code under multiple incompatible licenses. So, the key thing is for you to insist that all patches be signed over to you (or, more appropriately, the company you found to handle the commercial side of things); if they won't sign the patch over, refuse to accept it. So, then the copyright holder is Widgets, Inc., and is free to release under both the GPL (or LGPL, or BSD, or Artistic, or whatever) and under a commercial license.

You can then track who gives you patches, make them shareholders in Widgets, Inc., and give them a portion of the proceeds. The key thing is to get all the code under one copyright holder, so you can then do whatever the hell you want.

For some real-life examples of this, check out CUPS and LPRng. Both release both GPLed and commercial versions, and both operate like I've suggested (though I don't believe either one contributes net profits back to patch contributors).

But those are all technology companies, and there are many programming jobs that aren't in technology companies. Almost every medium-to-large company has an IS department that has real technology problems to solve every day, and it's in this kind of results-centirc environment that Linux and its kin have flourished in the past, and they still do today.

One shining example of this is Burlington Coat Factory. They have been using Unix for about as long as there has been Unix to use. They have an IS department that is constantly creating and improving the software that they need to use every day to sell coats. They have long realized that opening the source code for many of their tools can only help them, and that by using Open Source tools that already exist, they can leverage good stable code as a basis for their own future improvements. People in thier IS department have been contributing to projects like lprng , and the Red Hat distribution. It is in no small part due to their positive experiences with these projects that they felt comfortable embracing Linux.

There have got to be plenty of jobs doing real programming work for non-technology companies where Open Source is so natural a solution that it's hardly worth mentioning, and thus rarely gets news coverage.

I do not work for Burlington Coat Factory, although I have friends that do. I do not speak for BCF.

--Chouser

Since I hate stock lpr (who doesn't?), I recently tried a late beta of CUPS. They may have fixed all the problems I encountered, but while I was thrilled by the idea, I found the execution poor. In particular, the server had a tendency to crash with a segmentation fault whenever anything slightly strange happenned; and in the course of blundering about trying to set it up, I managed to cause many slightly strange things.

Trying to figure out why, I started looking at the source... and discovered that in many places they lack even elementary error checking. NULL pointers are passed to functions that don't check for it, system calls are made with no return value tests, etc.

Now, as I mentioned, it's quite plausible that they fixed the specific bugs I ran into (e.g. when I tried to enable a printer class, instead of a specific printer, it died). It's also possible that the code examples I saw were an aberration, and that most of the project has much better quality code.

Still, I was very taken aback; remember, this is code that is implementing a network service directly -- sloppiness often leads to security holes.

Based on this experience, I instead chose to use LPRng: http://www.astart.com/lprng/LPRng.html. It took more effort to set up, and didn't work "magically" out of the box the way CUPS did (I had to install a version of apsfilter myself, for example), but in the end it did most of the same things -- and didn't crash all the time.

Unfortunately, LPRng has "yet another wacky license", which they claim is "Open Source", but which may have restrictions on commercial use. But if you're interested in CUPS, you should check out LPRng too.

Jason