I've essentially done a version of this for the scanner drivers for a brother printer - printer works fine, scanner is a special kind of beast...

wine turned out to work - just... it was a large amount of trial and error to determine which utility of the dozen or so was the actual printer manager - once that was worked out it worked just fine...

I don't think it is a permanent solution though - it's rather winXP still...

On 23 May 2018 at 00:07, Craig Sanders via luv-main <luv-main@luv.asn.au> wrote:
On Tue, May 22, 2018 at 11:13:05PM +1000, russell@coker.com.au wrote:
> It seems to me that Docker and similar technologies are a good solution to
> this.  They can encapsulate the shared objects needed (a driver from a badly
> made .deb or from a .tar.ge won't stop "apt autoremove" from removing things
> it needs), and deal with architectural issues (I probably don't really need
> the full overhead of multi-arch just to have an i386 printer driver running
> on an AMD64 system).  Docker etc all have security features that cups lacks
> which are needed to prevent the (presumably badly written) printer driver
> from having exploitable security flaws or from just using all memory or disk
> space.

Docker can have difficulty running really old distros.  Some time ago, I had
to create a frankenwheezy docker container (wheezie + libc6 from jessie) in
order to keep an old wheezy app running after an upgrade of the docker host.

http://blog.taz.net.au/2016/09/16/frankenwheezy-keeping-wheezy-alive-on-a-container-host-running-libc6-2-24/

BTW, I tried something similar to keep an old etch container running.
Couldn't get it working, no matter what I tried.  Ended up building a full VM
for it to run with KVM.

A full VM is a little more runtime overhead than docker (but if all it's
running is a print server & print driver, it won't need much RAM or CPU), but
it's completely isolated from the host machine so host upgrades will never
break the VM (unless they break KVM itself, of course).  Cerainly easier to
keep working than building new docker images whenever something breaks.


Also, a VM or container is a damn good way of keeping proprietary software
isolated from the rest of your system.  Even if they're not actively malicious
spyware, the code is probably crap - just looking at some of the install
and startup scripts by proprietary developers is a freaking horror show. I
wouldn't expect the binary-blob compiled code to be any better.

Anyway, create the VM, get it running, install and configure the proprietary
crapware and when it's working, take a snapshot.  If it suicides with a buggy
startup or whatever script (sadly more common that you'd think - usually
because the script doesn't double-quote variables or check that the variable
has a sane value before blithely 'rm -rf'-ing with it) then rollback to the
snapshot.

craig

--
craig sanders <cas@taz.net.au>

BOFH excuse #262:

Our POP server was kidnapped by a weasel.
_______________________________________________
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main



--
Dr Paul van den Bergen