Re: dbus-deamon avoiding reboot after upgrade
On Fri, Aug 16, 2019 at 11:23:48PM +0100, Brian wrote:
> On Fri 16 Aug 2019 at 22:39:09 +0300, Reco wrote:
>
> > On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote:
> > > On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote:
> > >
> > > > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote:
> > > >
> > > > > Nowadays that system often relies on printer/print queue Bonjour
> > > > > broadcasts.
> > > >
> > > > And that is called "jumping to conclusions".
> > > > Printing itself haven't changed a bit for last 15 years - a print server
> > > > takes user's PS or PDF, mangles it to fit printer's representation (be
> > > > it PCL or something else), and feeds it to the printer. By utilizing
> > > > unicasts of course.
> > >
> > > I was going to let this go because it takes us beyond the server
> > > situation we are discussing and is a reasonable, succinct description
> > > of classic printing (which will become unsupported by CUPS in a few
> > > years time).
> > >
> > > However, modern printers will accept and print jobs (e.g. PDF and JPEG)
> > > without the mangling. These AirPrint-enabled, IPP printers completely
> > > do away with having to use non-free software or plugins also. What is
> > > there to dislike about that?
> >
> > Nothing. But it also means that one only needs something like ipptool
> > ([1]) on client-side, leaving CUPS (and a whole notion of a "print
> > server") out of the equation completely.
>
> ipptool depends on libcups2.
Which does not make it require CUPS on the other side - [2].
And note - a conventional RFC1918 IP is used there. No "discovery"
involved.
> > > > A user can discover a print server via mDNS multicasts (*not*
> > > > broadcasts). Or a user can be told a location of such print server.
> > >
> > > So - I give my VIP, Android-using customer a piece of paper with a URI
> > > to type into his phone rather than telling him which printer to use to
> > > print out the multimillion Euro contract he has just signed?
> > > Very last century.
> >
> > Multicasts are limited to a single L2 network segment by their very
> > definition.
>
> DNS-SD/Bonjour not scaling on typical multi-segment networks is a
> recognised issue by CUPS upstream.
An interesting example of corporate doublespeak, but it does not change
what I wrote - you need multicasts working - you put both sender and
receiver in a single network segment.
And that's bad for security, and is so last century.
> > Besides, "multimillion Euro contract" can involve some pretty secretary
> > lady who's happy to print said contract. Just saying.
>
> I have no idea whether a secretary likes to be typecast, but is being
> pretty, male and amenable a prerequisite to obtaining the post?
>
> Anyway, the secretary has knocked off and I am left to instruct my VIP
> how to use his Android phone to type the printer location without a
> mistype:
>
> dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2
You overcomplicate things without the need.
ipp://<ur_printer> is all you need.
Reco
[2] https://stackoverflow.com/questions/19232082/printing-using-ipp-without-drivers-ipp-client
Reply to: