CUPS: Linux-Drucken leicht gemacht -- für Heimanwender wie für ...

für die Abfrage verfügbarer Drucker im Netz vor den IPP-Karren gespannt werden. Proxys (also Vermittlungs-
und Zwischenspeicherungs-Rechner, die oft an den Grenzen zwischen Intra-Nets und dem Internet
Dienst tun) können ohne Änderung im Quellcode ihres Programms IPP-Daten vermitteln und weiterleiten.
Betriebssysteme (Server, Client und Standalone):
CUPS und ESP PrintPro sind erhältlich für Linux und UNIX, insbesondere für...
...alle Linux-Versionen ab Kernel 2.0 (auf Intel-Prozessoren);
...SUN-Solaris (für Intel und SPARC-Prozessoren) ab Version 2.5 bis zur neuesten Version (8);
...HP-UX ab Version 10.20 bis zur neuesten Version (11.0);
...Silicon Graphics IRIX ab Version 5.3 bis zur neuesten Version (6.5);
...Digital Unix ab Version 4.0;
...Compaq Tru64 Unix ab Version 4.0;
...OSF/1 ab Version 4.0.
CUPS ist zwischenzeitlich auch auf *BSD portiert worden (allerdings nicht von den CUPS-Entwicklern
selbst). Eine Version für IBM-AIX ist in Vorbereitung. ESP PrintPro- oder CUPS-Clients beliebiger
unterstützter Linux- und UNIX-Versionen können cross-plattform auf ESP PrintPro- oder CUPS-Server
aller unterstützten Linux- und UNIX-Versionen drucken.
Warum wird der LPD beerdigt?
Zum Zeitpunkt, als der LPD entstand, Mitte der 70er Jahre, war das heutige Internet mit seinen -zig Millionen
über TCP/IP verbundenen Rechnern noch unvorstellbar (sein Vorläufer hat erst ca. 1985 die Anzahl
von 1.000 vernetzten Rechnern erreicht). Fragen von Authentifizierung und Verschlüsselung waren
entsprechend unwichtig und spielten noch keine zentrale Rolle. Drucker hatten noch keinerlei "Eigenintelligenz":
diese erlaubt ihnen heute beispielsweise, ganze Seiten als Farb-Grafik aus entsprechenden
PostScript-Anweisungen als Bitmap-Muster mit 1200 dpi Auflösung zu berechnen, im eigenen Speicher
zwischenzulagern und dann "auf ein Mal" auf ein Blatt aufzutragen. Drucker der damaligen Zeit hämmerten
Buchstabe für Buchstabe und zeilenweise ASCII-Text auf Papier, das in Form einer Endlos-Schlange aus
einem Karton gezogen wurde. Drucker waren noch keine eigenständige Knoten im Netz, sondern immer
direkt an einen der "Gross"-Rechner angeschlossen, der sie dann u.U. per LPR/LPD seinen "Nachbar"-Rechnern
zur Verfügung stellte.
Das LPD/LPR-Protokoll war nie ein verbindlicher Standard. Als "RFC 1179" wurde es erst 1990
niedergeschrieben. Es kam bei der IETF nie über den den Status "informational" hinaus. Es brachte
lediglich die Praxis-Konventionen zu Papier, die sich zum damaligen Zeitpunkt herauskristallisiert hatten
und an die sich als Minimalbasis die meisten Hersteller auch fortan irgendwie hielten... oder auch nicht.
Je weiter die Drucker- und Netzwerktechnik sich in der Folgezeit entwickelte, umso mehr Abweichungen
und herstellerspezifische Erweiterungen flossen in die einzelnen Implementierungen ein -- und umso unvereinbarer
miteinander wurden diese. Hersteller wie HP versuchten gar, mit "HP JetDirect" einen eigenen
Standard zu etablieren. In der UNIX- und Linux-Welt wurden verschiedenen Versuche unternommen,
über den klassischen Line Printer Daemon hinauszugehen: LPRng, PPR, PDQ, PLP u.a. sind verschiedene
Versuche, dessen Beschränkungen aufzuheben und etwas Neues an seine Stelle zu setzen. Sie setzten sich
jedoch nie auf breiter Front durch.
Rückwärtskompatibilität
Muss man befürchten, dass bei breiter Einführung des IPP alte Anwendungen, Programme und Shellscripte,
die drucken wollen, hinfällig werden? Oder dass herkömmliche Drucker nicht mehr verwendbar sind? Nein
-- das IPP beugt diesen Gefahren vor: es kann eingeführt werden, ohne dass bestehende Anwendungen in
Gefahr kommen, nicht mehr drucken zu können, und ohne ihre Druck-Schnittstellen umzuprogrammieren
zu müssen: es hat ein "Mapping" zum LPD vorgesehen, das die wichtigsten Funktionen berücksichtigt.
CUPS selbst setzt dies beispielsweise dadurch um, dass es die unter Linux verwendeten Druckbefehle
"lpr" und "lp" ebenfalls versteht (es setzt allerdings eigene Versionen an die Stelle der alten, die zusätzlich
2