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 <[email protected]> wrote: > On Tue, May 22, 2018 at 11:13:05PM +1000, [email protected] 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 <[email protected]> > > BOFH excuse #262: > > Our POP server was kidnapped by a weasel. > _______________________________________________ > luv-main mailing list > [email protected] > https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main > -- Dr Paul van den Bergen
_______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
