A lot of CUPS defenders in here, but they're all talking about the usefulness of CUPS in more complicated situations.
It seems far more friendly to mention that netcat is an option to the average home linux user.
Bye CUPS: Printing with Netcat
91–100 of 183 posts
Re: Bye CUPS: Printing with Netcat
#92Earlier quoted context omitted.
KISS Linux taught me this! Once I realized I could read/write to IRC over netcat, I paired that will all the Bash magic KISS taught me and created a pure bash IRC client in 54LoC: https://github.com/retrohacker/irc-sh
Also, I forgot, poor man's dictionary: dict(){ echo "define * $1\\n\\q" | nc dict.org 2628 | less ; } dict unix
Woah! This is awesome!
Re: Bye CUPS: Printing with Netcat
#93that's great and all but not everyone has an HP...once we have better driver support, sure. Or am I misunderstanding something?
Re: Bye CUPS: Printing with Netcat
#94Earlier quoted context omitted.
> At least PipeWire is saner compared to PulseAudio. In what way?
Pipewire implements both ALSA psuedo-devices, the JACK API and the PulseAudio API. You only need a single daemon to address all possible audio I/O needs, something that PulseAudio could not do.
That doesn't sound like a recipe for sanity.
Re: Bye CUPS: Printing with Netcat
#95CUPS exist because not all printers are HP. Magic in printing is still an arcanum. PPD files. Windows 10 as a print server. (some print devices are not networked) Prelude files. in-printing logic like line reversal, density adjustments for photos. Double sided printing meta-signalling, n-up.. "oh, I don't need that stuff" fine, fine, nc is going to work for you, at the end of a bumpy road to a printer which supports…
I guess some people need CUPS but.. I have a $90 Brother laser printer and it has support for all kinds of protocols, and I can send multiple text files (9100 is the "raw data" port, not anything else) to it at the same time on port 9100 and it figures everything out and doesn't get confused.
I can send stuff to it over FTP, too.
$90!
I will never use CUPS again. I'll need a printer driver, yes, but I'll never need CUPS.
Re: Bye CUPS: Printing with Netcat
#96FWIW, the Internet Printing Protocol (and IPP Everywhere in particular) make printer setup in CUPS far, far easier, but distributors seem reluctant to encourage it. I wrote about my experiences with IPP back in June ( https://lwn.net/Articles/857502/ ). I expect to never have to hassle with printer drivers again...
keep in mind not every printer has a good http stack, especially if the device never gets restarted this can be a problem.
Didn't know about that, you got some examples?
Re: Bye CUPS: Printing with Netcat
#97While the article is correct, it omits most of the actual function of CUPS. Many printers are capable of accepting various types of documents directly over the network, with postscript, HP PCL, and PDF being commonly supported---and ASCII pretty much universally supported.
The problem is that few printers support _all_ of these standards. Postscript, for example, is surprisingly complex to implement in practice, which leads to a lot of inexpensive network printers actually lacking postscript support. Further, printers are very slow at rasterizing, and so while support for PDF rasterization is very common you probably don't want to use it. You can easily see a minute per page for printing modest PDFs. In-printer PDF rasterization is also of very uneven quality, and I have seen issues like completely broken kerning in documents due to the printer's poor handling of embedded fonts.
One of the key functions of something like CUPS is to address this problem: CUPS standardizes the format of all printed documents to something that is well-supported by the printer, and performs much of the rasterization ahead of time on the much faster print server. This saves time and improves reliability since you don't need to figure out if a given document is supported by the printer. For most printers these days some variant of PCL is the preferred language for jobs, as it's simpler and easier to implement than Postscript. It also presents fewer security concerns.
Of course the other major problem CUPS solves is the management of the queue, including across multiple users. That's an important feature but not one that matters in a lot of home situations. That said, if you don't use a printing system you can and will run into annoying situations where you cannot print a document because you are waiting for the previous one to complete sending, which often gets blocked on the printer's memory space or rasterization.
Re: Bye CUPS: Printing with Netcat
#98Earlier quoted context omitted.
Pipewire implements both ALSA psuedo-devices, the JACK API and the PulseAudio API. You only need a single daemon to address all possible audio I/O needs, something that PulseAudio could not do.
That doesn't sound like a recipe for sanity.
My experience with pipewire is it works better than pulseaudio, is faster, has lower latency, and fewer bugs. And it gets better all the time!
Re: Bye CUPS: Printing with Netcat
#99That's pretty neat... But does it work with postscript files? Or maybe pdf? I also assume it only works for networked printers?
Re: Bye CUPS: Printing with Netcat
#100Earlier quoted context omitted.
Since I switched to pipewire, my audio is crackling every time the cpu is loaded (a ryzen 7...) not even jack was struggling with that on this machine
Pipewire is not finished at this point. It is being deployed "early" by some distros, apparently in the belief that it will help find bugs and help them being fixed.
[deleted]