| Thank you for taking the time to write this! When using CUPS in my previous posts as an example of "Standard OpenSource component that could be a drop-in replacement in a vast majority of deployments/installations", I was hoping, that somebody knowledgeable would reply with some details about the (speciality-use) features/use-cases of the Windows Print-System. You mentioned a few points, that I'll try to itemize, and respond to: * Specialty hardware setup, and UI's for that:
In these times(for non-ancient devices/deployments), is that not easily solved by the [WEB-]UI of the printer? * Speciality hardware runtime control for printjobs (staples, binds, folds, glue, mailing, ...):
I thought, all of these are commonly abstracted into "verbs" in the PCL/PJL, and just need to be "included" in the PrintJob. * Decent integration into enterprise setups.
In what ways do you find CUPS lacking here? I find CUPS+AD-Auth_to_Samba4AD works great, and all the RSAT tools are functional from a domain member workstation * Driver support:
Is that really still a problem these days? * Availability of paid support for Windows Printsystem for X amount of money in 2031:
If commercial interest is there, I have no doubt, that MS will offer something like for WinXP and Win7 years after the normal EOL of Srv201{6,9}. I just thought, It was already visible now, that the "commercial interest" for this was going to be small, but then again I might be underestimating the (future) size of the "Seriously large-scale paper printing" market. > "When was the last you heard somebody say: "I would buy Windows server, if it had CUPS printing support in it"? " Admittedly, never, but I can probably count in years the paid time, that I have worked helping clients with their Windows Print problems, many times calming them down to get the screaming and crying under control. So maybe a replaced print-system (In WinServer) could (by some) be seen as net positive, while the average Windows Home user wont notice/care. ;) |