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.


> >(Check the authors of Avahi, and you'll see a familiar name.)
>
>     I guess some Lennart guy is involved.

Got it in one.

> I don't think he is pure evil.

Nor I. I just find it amusing that he went out of his way to implement
a network protocol that I consider a blight on networks, a thing that
IMO is best eliminated.

Back in the 1980s, I worked as IT staff (or, as we then said, MIS) at a
firm called Blyth Software. This was just before the transition from
network hubs to network switches, where the latter implicitly helped
alleviate network congestion by localising traffic. Blyth's LAN was
a somewhat monstrous thing with an odd history, and putting a network
analyser box onto it revealed interesting things, which we spent some
time studying.

In those days, if there was a cable problem, or a failing/chattering
ethernet card, or various other sources of excessive or malformed
traffic, you could have a huge traffic jam across the local LAN. And
Blyth as a software firm with a diversity of OSes had quite a few
networking stacks active simultaneously. We noticed, if the network
became saturated, the stacks became unusable in this order:

1. AppleTalk (Apple)
2. NetBEUI (Microsoft)
3. IPX/SPX (Novell Netware)

The fourth stack, TCP/IP, was never observed to become unusable (though
of course a severe enough problem _could_ take it down).

The difference owed mostly to good vs. bad design, but in no small part
to how 'chatty' they were -- how some plastered the network with
excessive announcement and acknowledgement blasts, and others did not.

The DNS-SD ('dnssd') / mDNS stack _absolutely_, in that regard, reminds
me of AppleTalk.

Kill it with fire. ;->

-- 
Cheers,                     « Le doute n'est pas une état bien agréable, mais
Rick Moen                   l'assurance est un état ridicule. »  ("Doubt is not 
rick@???         a pleasant condition, but certainty is absurd.')
McQ! (4x80)                                                       -- Voltaire