Any recent printer I've used has just been plug it in and hit print. A better experience than Windows in terms of included drivers and bonjour support too.
It's never been that way for Windows: you've obviously never used a network printer in a large office.
Part of this is the byzantine config of network discovery, CUPS, driver sources, etc. A big part of the problem is the pieces may be there but distros have done a mediocre job getting everything together on this in the best way for the user.
By contrast, I had a contract job a year or so ago at a large company where I was given a Win7 laptop and tried to connect to a big Ricoh laser printer. I spent hours messing around with driver downloads trying to get that to work. I finally had to call IT and they sent someone over, and he couldn't get it to work either; he finally found some crazy work-around which I've totally forgotten the details of now.
The only real problem I see with printing on Linux now is that, sometimes, there's multiple CUPS drivers for the same printer (foomatic, hpijs, Postscript, etc.), so it won't automatically pick one and it's not clear which is the best so you might have to just try one and see if it works. Most likely, they all work, but some might have additional features. HP printers are probably the best, though, since they seem to explicitly support Linux (such as with their hpijs drivers). If all printer makers had this level of support, and they cleaned up the redundant/competing drivers, there wouldn't be complaints.
Not saying this is necessarily a good idea, but it avoids a system-wide print queue, all you need at the system level is a service locator to let you know where the printer is that you need to contact.
You could call it 'lpd' and then the circle would be complete.
For printer that attach directly, there could be a daemon that arbitrates access and handles accounting or the system could simply allocate the printer to the logged-in user. For directly connected printers on multi-user systems, you'd want a real daemon, of course.
For daemons that mediate access, IMO the arbitration and accounting should be split from formatting and rasterization (if needed). For accounting and arbitration, the right way to do it is to speak something like Printer Job Language. I actually wrote a daemon like this years ago. I wonder if I still have the code. It actually counted pages regardless of how they were submitted.
Anyway, for a normal desktop machine, I think that the system daemon is silly these days.
If three users on a workstation each print a document that uses lots of RAM, two of them are going to have to wait no matter what.
But this is already sounding archaic and difficult isn't it? Just download and run an installation script? Give it the host name? No way a nontechnical user is going to be able to do either of those things.
Why doesn't the printer just appear like it does on my Mac? I'm not even sure what my printer's host name is so I wouldn't even be able to do that step myself!
"Download this .ZIP file from the Brother website. Then unpack it somewhere. Go through these dialog boxes from the Devices and Printers control panel. Be sure to uncheck such and such before clicking next in such and such. Then at this point, choose "Have Disk" and browse for where you unzipped the drivers and find the ".inf" file in there somewhere."
If the printer is on a dynamically assigned IP address, chances are that the port created for it will use a hard-coded entry like "192.168.1.13" which will break. The DHCP host name requested by the printer can be used, but you will have to manually enter that. It is some awful serial number: a mixture of random digits and letters. It's better to navigate to the printer's web firmware first, and rename it to some human-readable name, then edit the printer port to match.
Personally, I've never understood this. Are there a lot of admins who let their printers take IPs from the DHCP pool?
Re-addressing a couple hundred printers was not fun when each of them was configured manually via the front panel.
That is exactly how, just over a week ago, I gave that brand new printer its Wi-Fi password: moving a cursor and incrementing through a character set.
Just like naming the presets on a Yamaha audio effects processor I bought in 1989.
You mean just about every single home network?
Although, in an enterprise setting, if you count DHCP reservations then that's what we do, having our whole office use them has greatly simplified our network configuration.
I could imagine a world where printers had a built-in DDNS client which would make them truly plug-and-play in an office but that's probably more complicated than it's worth.
Bingo!
No home user is going to statically assigns an IP to their printer on Wi-Fi; that would require a power user who even knows what that is.
Pretty much my de-facto solution for networking, managing static IP's is a pain even with something like Puppet - one mistake with the configuration and I have to open up vCenter to get to the console and fix the configuration to get network connectivity. I literally use DHCP reservations for everything with the exception of intra-cluster communication for my PostgreSQL replicas (those are on a separate VMWare network and I manage those statically, but they never change).
> I could imagine a world where printers had a built-in DDNS client which would make them truly plug-and-play in an office but that's probably more complicated than it's worth.
This is what a DHCP hostname is for, no? My cheapie ASUS AC1900 at home uses the DHCP hostname from any device it allocates an IP address to as a local DNS alias, if I run `nslookup ls410d9a3.local 192.168.1.1` on any system on my home network it will point me to my Buffalo NAS (without needing multicast DNS, though that would still work as a fallback) - same for BRW142D2763B66E.local (which is my printer).
I could just as easily configure any dhcp server I use to automatically register DNS entries for new hosts if I wanted (probably in a separate DNS zone to prevent peoples phones from showing up in the default DNS search path).
Of course I'm limited to occassional document or a few tickets.