Le 15/10/2018 à 20:33, Rowland Penny a écrit :
> On Mon, 15 Oct 2018 11:12:41 -0700
> Rick Moen <rick@???> wrote:
>
>> Quoting Didier Kryn (kryn@???):
>>
>>> This is fine if you always work in the same place. During my
>>> professional life, I used to travel to various labs and found it
>>> convenient to automatically find, in the cups menu of my laptop, a
>>> list of the local printers. And to always have the list up to date
>>> when the computing department installed/removed old/new printers.
>> I respect that. For the sake of community knowledge, I'll also tell
>> you what I do as an alternative:
>>
>> When I visit a new location, I look around for a networked printer,
>> and see if it happens to have a label on it including its IP address
>> (usually not). If not, I can usually figure out from the printer's
>> front-panel controls how to make it print out an information sheet to
>> proclaim its network access details. (For example, all HP laser
>> printers have a standard way to do this.) If I cannot easily figure
>> that out, I type its make/model into a Web browser to look up how on
>> the Web. Either way, within a couple of minutes, I know details of
>> how to print on it, usually over my choice of several protocols (lpr,
>> ipp, etc.)
>>
>> Or, if there's someone technical handy, I lazily ask 'Hey, how would I
>> print directly to this printer?'
>>
>>
>> And a possibly amusing cautionary tale: After the dot-com collapse, a
>> small firm named California Digital Corporation (CDC) picked up the
>> hardware business that Larry Augustin decided my old firm VA Linux
>> Systems could no longer compete in, resuming manufacture and sale of
>> VA Linux's models (and successors to those) under their new brand.
>> (Incidentally, they showed that Augustin's pessimistic conclusion had
>> been in error, as they were prosperous in that industry segment for
>> quite a few years, and had numerous achievements to boast, including
>> building for Lawrence Livermore Labs the #2 HPC cluster in the world,
>> a 1024 quad-Itanium computing cluster named 'Thunder'.)
>>
>> CDC was run by a husband and wife firm, the Aruns. I was for a while
>> their system administrator and de-facto IT guy. One morning, I walked
>> in, and Ms. Arun was very vexed, because she said that printing was
>> not working anywhere around the firm. Notably, she said there had
>> been a power outage right at the beginning of the business day.
>>
>> I conducted tests of printing to several of the HP JetDirect printers
>> across the network, and everything worked fine. Moreover, all of the
>> technical staff were having no problem at all printing. It was just
>> the executive staff reporting total printing failure.
>>
>> Getting to the bottom of the problem required looking at the printing
>> setup objects of those people's -- yes -- Microsoft Windows
>> workstations. Each of them had a printer object that was defined as a
>> queue on the controller's (the main company accountant's) workstation.
>> Every single executive was routing all print jobs through that poor
>> fellow's workstation, before those jobs then recrossed the network out
>> to the printer near the executive offices. (Meanwhile, the technical
>> staff were enjoying faster, more reliable, more direct printing.)
>>
>> As it happened, the controller's workstation had an ATX power supply
>> that was set to put the workstation in standby power mode after a
>> power loss, rather than come back online. So, from
>>
>> I politely asked 'Why aren't people printing directly to the executive
>> LaserJet?' -- and, predictably, heard 'How do you do that?'
>>
>> It seems that someone had originally helped the controller print to
>> the executive printer and, in so doing, had created on that
>> workstation a Network Neighbourhood queue object, advertised to the
>> network. Subsequently, every time someone on the executive staff set
>> up printing, he/she groped in Network Neighbourhood, found the
>> accountant's printing object, and assumed that was the only way to
>> reach the executive printer.
>>
>> I re-did all of the executives' printing so that they did JetDirect
>> printing straight to the printer, replacing their convoluted and
>> fragile workaround.
>>
>> This is part of why I would rather not trust to automated printer
>> discovery. I'd rather know what I'm doing, instead of assuming
>> someone else knows what's good for me, as that often is not the case.
>>

    Well, it's a burden to always do everything by hand.


> This reminds of the time I was asked at work why printing was so slow.
> This was after a so called expert had supposedly set up the network.
> It was years ago and it was a small XP workgroup, I traced it down to
> the print server the 'expert' had installed on the network and connected
> to the main printer i.e. the one everybody used. This by itself wasn't
> the problem, the problem was that he had then setup the printer driver
> on one PC and then shared it across the network, all printing went
> through that PC. After I spent about an hour sorting this out and
> print speed went up by a large amount, the 'expert' was asked not to
> come back and I got a promotion.


    I never had that problem of printing being slow because of the
server. Of course it must be run on a decent machine. But, at some time,
half people in my lab had Macs, and the Macs came with CUPS installed
and always configured to export the printers, which includes, of course
the remote ones, which means that there was a large numbers of paths to
every printer, hopping from mac to mac. It made it necessary to restrict
the search to the one final print server. By that time, it was CUPS
private protocol, not dnssd. And now, Mac developped its own printing
system, different of CUPS, because Mac always has to be incompatible,
but they still have CUPS available.

    Didier