Not OP (and not Microsoft), but I would say it's a complicated road to get there.
I do believe we will see open source Windows in... the next decade?
Anyone want to take a longbet with me? ;-)
I do believe we will see open source Windows in... the next decade?
Anyone want to take a longbet with me? ;-)
When was the last you heard somebody say: "I bought windows (server) because of the print subsystem"? I could see them adopting CUPS, for example. That way in 10 years they can stop maintaining theirs when current versions EOL.
But for "intimate areas" that may take time, or may never happen. Or they move into the hardware. So I remain skeptical wrt a 100% auditable (modern) tech-stack.
In the case of the browser-engine I wish though, that they had not picked webkit. What were the reasons against Gecko? Not "embedable" enough?
The print subsystem is one of the backwards compatibility limits on redesigning parts of the classic control panel - I'm fairly sure Raymond Chen has written about it - because so many print drivers depend on the way it works to hack in pages and popup dialogs for specialist configurations for their printers.
It also integrates decently with Windows' granular permissions, file and printer sharing on networks, logging, has tons of specialist printers like label printers, receipt printers, etc and is used by a ton of 3rd party management and configuration tools. I would be hugely surprised if it's unsupported in 2031.
> "*"I bought windows (server) because of the print subsystem"?"
When was the last you heard somebody say: "I would buy Windows server, if it had CUPS printing support in it"?
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. ;)
* Trademark notice: JavaScript® is a registered trademark of Oracle America Inc.