Slashdot Mirror

We use CUPS (The Common Unix Printing System) and find it very good. It seems they added quota support in 1.1.5, but I can't find any docs. It may be worth investigating this.

Dealing with printer drivers on Linux, I've had the most success using the CUPS printer system. It replaces the standard Unix lp* tools, adds a neat web interface for printer configuration, ships with a heap of drivers supporting most of available laser printers. Support for spooling via samba is also possible.

Here's my procedure for supporting proprietary clients from an open standard print server.

I typically buy a printer that's supported by Linux, set up a Linux print server, then export that via lpd, Appletalk, and Samba. Then I install the standard Apple Laserwriter driver on any Windows clients, because it's simply a Postscript driver. In fact, you'll find that a lot of the entries in the Windows driver database are simply alternate names for or versions of the Apple Laserwriter driver because it's just Postscript. Then I install MacOS's standard Postscript lpr client on the MacOS client hosts.

Another time, I made Linux print to a totally proprietary printer. It was an HP 3150, which is an excellent value although proprietary; sometimes you take the hit and run with it. You can install an ethernet adapter from HP, on any parallel printer device of any kind. Then on the aforementioned print server, I installed VMware and Windows 98 with the proprietary drivers, which exported the printer to Samba, which reexported it as Postscript. That whole virtual machine was just another printer driver!

That's almost as crazy as writing an open source, open standard implementation of a reverse engineered Microsoft protocol based on their buggy specs and implementations. ;) But it's still a good idea to try to eventually directly support the alleged standards, to support the exceptional cases where a direct local client-side driver is necessary.

I am sure there are people who are unfortunate enough to have chosen very driver-specific proprietary devices for printing and imaging, but in most cases it was technicall preventable.

===

Here's my procedure for supporting proprietary clients from an open standard print server.

I typically buy a printer that's supported by Linux, set up a Linux print server, then export that via lpd, Appletalk, and Samba. Then I install the standard Apple Laserwriter driver on any Windows clients, because it's simply a Postscript driver. In fact, you'll find that a lot of the entries in the Windows driver database are simply alternate names for or versions of the Apple Laserwriter driver because it's just Postscript. Then I install MacOS's standard Postscript lpr client on the MacOS client hosts.

Another time, I made Linux print to a totally proprietary printer. It was an HP 3150, which is an excellent value although proprietary; sometimes you take the hit and run with it. You can install an ethernet adapter from HP, on any parallel printer device of any kind. Then on the aforementioned print server, I installed VMware and Windows 98 with the proprietary drivers, which exported the printer to Samba, which reexported it as Postscript. That whole virtual machine was just another printer driver!

That's almost as crazy as writing an open source, open standard implementation of a reverse engineered Microsoft protocol based on their buggy specs and implementations. ;) But it's still a good idea to try to eventually directly support the alleged standards, to support the exceptional cases where a direct local client-side driver is necessary.

I am sure there are people who are unfortunate enough to have chosen very driver-specific proprietary devices for printing and imaging, but in most cases it was technicall preventable.

===

Here's my procedure for supporting proprietary clients from an open standard print server.

I typically buy a printer that's supported by Linux, set up a Linux print server, then export that via lpd, Appletalk, and Samba. Then I install the standard Apple Laserwriter driver on any Windows clients, because it's simply a Postscript driver. In fact, you'll find that a lot of the entries in the Windows driver database are simply alternate names for or versions of the Apple Laserwriter driver because it's just Postscript. Then I install MacOS's standard Postscript lpr client on the MacOS client hosts.

Another time, I made Linux print to a totally proprietary printer. It was an HP 3150, which is an excellent value although proprietary; sometimes you take the hit and run with it. You can install an ethernet adapter from HP, on any parallel printer device of any kind. Then on the aforementioned print server, I installed VMware and Windows 98 with the proprietary drivers, which exported the printer to Samba, which reexported it as Postscript. That whole virtual machine was just another printer driver!

That's almost as crazy as writing an open source, open standard implementation of a reverse engineered Microsoft protocol based on their buggy specs and implementations. ;) But it's still a good idea to try to eventually directly support the alleged standards, to support the exceptional cases where a direct local client-side driver is necessary.

I am sure there are people who are unfortunate enough to have chosen very driver-specific proprietary devices for printing and imaging, but in most cases it was technicall preventable.

===

1. No really solid HTML editors

a lot of the best webpages are written by hand anyway, use vi or emacs.

Vi and emacs have horrible workgroup support.

While I agree vi and emacs may not be appropriate for Joe in Sales who needs to update the product information page, have you looked at some of the other editors available. If there is one thing Linux/UNIX has is text editors. Try Quanta or BlueFish. I don't use it myself but you could use an editor with integrated CVS support, using CVS to update websites can work out very well. There may also be an editor with WebDAV support which may be even better. vi and emacs aren't the only text editors ever created. 8^)

2. Poor application linking

my linker and links seem okay.

I chuckled when I read this. I'm talking about application communication services that go a lot futher than "|" or ">" do.

Again, you may have a point there. This is debatable, though, and definately won't stay behind forever. We currently have DCOP and Bonobo with a damn near guaranteed upgrade path for both. The developmenet process is open so you can at least follow where everything is going, if not participating yourself.

3. Poor printing services

HP just released JetDirect for Linux.

I'm talking about color management, spools, trays, easy to use multiple printers. Take a look at what MacOS can do and come back with educated comment.

The comment about JetDirect is pretty silly, but there are more advance print systems than lpr (gack!) available. CUPS is a good example it can do everything you want (I don't know about color-correction, only Macs and SGI's seem to do this acceptably).

4. Its harder to update anything on Linux than Windows and MacOS

# apt-get dist-upgrade

apt-get? You're joking right? It's version tracking blows, take a look at how a Mac handles it

I have worked a little with Mac systems but I have no idea what you are talking about. The Debian APT system, filled with packages conforming to the Debian Packaging Guide book, is the best packaging and software distribution I have had the pleasure to use. Ever. Could you enlighten me as to what system Apple has that compares to APT, please?

5. Poor graphics support

OpenGL, OpenInventor, Nvidia, ATI, Matrox...

All need to custom configured, and if you think Mesa is a replacement for OpenGL you need to open your eyes. OpenInventer is no where near production quality. Getting Mesa to work with any given graphics card is not easy.

I'm not sure what your beef with Mesa is, my experience shows that it is one of the best OpenGL API implementations that exists. I haven't had nearly the trouble you seem to have had getting it working (I assume you mean with hardware accelerated graphics, GLX outputting to a regular X window is a no-brainer). It usually goes along the lines of: Compile DRI module, modprobe DRI module, start X. Look Ma, 3D. Maybe I've just been living my life right or something. I've had more trouble with video drivers on Win9x/NT systems installing in different, strange ways or corrupting the system settings so that it doesn't boot. Strange graphical glitches that occur on a per-app basis are common as well. Macs may be easier, I haven't used them enough to know.

6. No unified GUI (KDE, Gnome, who cares, just make ONE of them work)

My ximian gnome box works fine.

Yeah and it works and is coded for in a totally independant way from KDE

So? If you want to use GNOME you have no need to worry about KDE, and vice-versa. Each environment seems to be quite self-sufficient. Of course if there is some app you just can't live without in the other camp, the only thing you sacrifice by running both is disk space and memory. Just because there is choice doesn't mean you need to go crazy obsessing about it.

7. Each Linux variant ships with security holes to some extent,

all s/w products have security holes. or

Tell that the the OpenBSD team. Tell that to Apple.

perhaps you mean the recent bind problems? fixed months ago, and the "apt-get" lines above (provided the security.debian.org entry is in your sources.list) took care of that pretty fast...provided you use bind...long before the Lion was out. Or perhaps you mean a boot disk against a non-passwd protected bios? all mainstream OSen are subject to that. Go install a stock NT 4.0 box and stick that on the web. I dare ya.

I'm talking about the fact that all Linux systems ever shipped always have had some misconfiguration that allows remote attacks. All of them. Not good for desktop use. IHMO NT is a piece of shit

Hell, you're both right. All Operating Systems have shipped with security problems of varying severity (even OpenBSD). RedHat has been getting better but are definately not there yet, Debian or Immunix is a much better bet. There are also some tools like Bastille, OpenWall, LIDS, SE Linux, Pitbull, etc. that can make a Linux system very secure. Also many security vulnerabilities are in third party software that may or may not be distributed along with a copy of Linux. Holes in wu-ftpd and BIND effect many more operating systems than just Linux!

Internet security has only become the important field that it is in the last couple of years. Linux, *BSD and UNIX have been at the forefront of operational security technology throughout this period (discounting academic research projects). Heck most other vendors haven't figured out that you shouldn't send cleartext passwords over an open network. As an example look at the OpenSSH project, from OpenBSD. They recently issued a security update to fix bugs allowing passive traffic analysis to discover the length of a password as it was typed in. I have not seen any other, commercial, systems that have reached a level where they would even consider fixing this kind of thing, most seem to be still trying to figure out that blank admin passwords and world writable files are a bad thing.

In conclusion let me summerize: All software sucks! Some software packages (Linux, *BSD) suck less than others (UNIX, Win*). When we have the perfect operating system with the perfect utilities, I'll let you know. 8^)

Yes, its default printing system blows. However, if you happen to have an HP or EPSON printer, go to www.cups.org and download the Common UNIX Printing System. Unbelievably frickin awesome, and installation is seamless. Administration is as simple as browsing to localhost:631.

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.

It's based on IPP, the Internet Printing Protocol, which is being standardized by the IETF.

... I'm a Sys/Net Architect, so guess where my biases are? :-)

Anyway, what you have on the desktop matters (esp the mechanism you use for clone workstations (you are planning to clone workstations, right?)), but I'll concentrate on something else equally important, and which will affect how you set up the desktops: Network and Backend System Design

First off, you don't want any data locally. That's right. I don't care who has the workstation, the only thing sitting on the local disk should be the OS. All user files, and major applications should be sitting on a remote filesystem. Otherwise, you end up with a completely intractible backup and upgrade problem. Trust me on this.

As a correllary to the last statement, you don't want to use NFS as your file sharing method. Hell, even SMB would be better. You want to look at either AFS or Coda. I would recommend the latter, as it's nowhere near as nasty to set up.

As part of Coda/AFS, you are going to have to think about how you design your file server setup. A central bank of servers is tempting, but this tends to be really harsh on the campus backbone, as it puts the workstation relatively "far" from the server, and all traffic has to traverse the backbone. Consider local file servers which may cache user data for replication back to the master server(s) later.

Printing is also a bit of a problem. I heartily recommend the CUPS system talked about here a couple of days ago. Have all your workstations spool to dedicated print servers. They don't have to be powerful, but make them dedicated. You won't regret it.

As far as security and other mishmash goes, do the usual /etc/inetd.conf edit, and comment EVERYTHING out. Don't run ANY daemons on the clients (other than what is absolutely necessary for Coda). Have all mail blindly forwarded to a central mail server. As a correllary, use IMAP (preferably IMAP-over-SSL) as your mail server. Stay away from local UNIX mail, and POP. And look at running postfix or exim instead of sendmail.

You can think about using application servers (i.e. run X apps remotely) if you want, but realize that this will up the bandwidth requirement, and honestly, you probably can't run more than two dozen major X apps over a LAN before it bogs down completely. That is, you need a local app server with 100Mbit connections to about 25 machines so each can run 1 or 2 X apps remotely.

If you can afford it, and have the time, use LDAP as your user info directory - avoid NIS and NIS+ (the first is horribly insecure, and the second is nasty).

This is a first approximation of what you might do. If you want a serious proposal, I'm available nights and weekends (for a modest fee, of course... heehee)

Good luck!

-Erik

I've had good luck with CUPS the Common Unix Printing System. It supports LPD, SMB, AppleTalk, TCP (JetDirect), and the new IPP RFC (Internet Printing Protocol). Also the company that makes it Easy Software Products makes a graphical configurator (not needed) and a set of high quality print filters (very nice) based on GhostScript and .ppd files.

It is intended as a "printer-agnostic" scheme for getting at printing capabilities.

It is somewhat unfortunate that there have been few realistic attempts to really upgrade printing; this is a weakness for business applications.

I don't know but that Corel is creating another "island" not unlike CUPS ; I'd be more impressed if Corel was putting some programmers into something like Display Postscript so as to both make it functional and to help provide whatever integration is possible with XFree86. (There's some "license impedance" that, regardless of any flaming that might take place on Slashdot, is unlikely to change any time soon...)

1440x720 DPI for the EPSON printers *is* available today; we have our ESP Print Pro drivers based on CUPS, and Robert Krawitz has been extending my print plug-in to support the Photo printers and the 1440x720 DPI modes in GIMP (available in the 1.1.x development versions.)

That architecture (to develop printer drivers for Linux) is already available with CUPS (http://www.cups.org, GPL'd)

Debian is including CUPS and LPR in their next distribution, and we're hoping more vendors will do the same.

As for libraries, there are several people working on that, most notably Corel, the KDE folks, the GNOME folks, and the VA Linux folks. We've contributed code to the Corel (LGPL'd) and VA Linux efforts already.

I dont see why Linux has bad printing mechanisms...i think lpr is perfectly good as a remote print spooler and the drivers + printtool utility with redhat work great with all my HP printers.
Heck, ive even begun to replace HP JetDirect print servers with redhat or slackware boxen..do we really need another print system ? Besides, even the CUPS guys are trying to build one...

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).

• New, cheap computers with Linux installed. Setting up X is horrible, and that's just the way it is. Setting up Windows isn't that easy either. So we'll avoid it just like Windows does. The great thing is that Linux computers could be really cheap. We need an eMachine, not a VA Linux.
• Printing needs to be fixed. Printing under Un*x just isn't very good. Ideally, a whole new system could be set up, complete with nice libraries. Maybe CUPS would be a good alternative. I don't see any real salvation for lprd.
• Applications aren't that important. Lots of people never need anything more than the MS Works that comes with their computers -- StarOffice clearly matches that, and hopefully with a little polish the Free alternatives (KOffice, AbiWord, the GNOME efforts, etc.) will be there soon too. Polish is more important than features at this point.
• Mindshare (uck... I feel dirty for using that word). Anyway, people have friends who know Windows, and that provides an important support structure for people. This makes for a chicken and egg problem, but the Internet has already shown us the solution. Linux has a great Internet support structure, but for Internet newbies this can seem a little intimidating. Making something a little more friendly would be helpful.
• Games. Linux doesn't have lots of good games. People like games, parents buy computers with the notion that while the computer might not be for games, the kids would really like to play them. And some people just buy a computer to get games. LokiSoft is really the best short-term model for this. Commercial companies will dominate this for a long time, and that's just fine IMHO.
• A few things need to be hidden. Like all those libraries. Debian's Apt provides a good start for this. People shouldn't need to think about what libraries they have to have installed, it should just happen.

I've done similar tricks. I'm using some techniques on a home computer which I intend to use soon at the office. I'll take a copy from home to the office for our use there before I infect my home copy with the GPL.

Anyone can fork, but establishing a name and a presence takes time.

The Common UNIX Printing System utilizes GNU GhostScript 4.03 to convert PostScript files into a stream of raster images.

How Is CUPS Licensed?

CUPS is provided under the GNU General Public License, Version 2. A copy of this license follows this introduction. For those not familiar with the GNU General Public License, the license basically allows you to:

Use the CUPS software at no charge.
Distribute verbatim copies of the software in source or binary form.
Sell verbatim copies of the software for a media fee, or sell support for the software.
Distribute or sell printer drivers and filters that use the CUPS API so long as source code is made available under the GPL.

What this license does not allow you to do is make changes or add features to CUPS and then sell a binary distribution without source code. You have to provide source for any new drivers, changes, or additions to the software, and all code must be provided under the GPL.