Could you be specific, please. Is it that you cannot start the keyboard over slim? or that it comes up but its input is not delivered to slim's login box? Or something else. Please include any error responses of any commands that your try.

Someone on a not dissimilar platform had success with the problem in 2009:
https://ubuntuforums.org/showthread.php … 455&page=2
The key was to "also disable loading lp module in default configuration of cups in /etc/default/cups".

sometime a sleep 1 beforehand makes wonders

Just picking up the smallest of your crumbs:

which could provide a similar layout separation as a code block, though not scrolling.

As for network interface re-naming, I can't offer anything not already said. Basically it's a udev thingy, and (stupid as it is, one might think), one of those warts that come with the "modern" and "improved" wheel. Slightly easier to fix than rid yourself of avahi and gvfs and packaged and uuidd and whatnot, I think.

I liked post #19 though; it was short and succinct, and its mere presence so elegantly violated its own sentiment.

Why don't you find yourself a blog site somewhere, where it'd be good and natural to line up all those beautiful words. This forum is populated by mostly intelligent people with no need or desire to waste (more) time and thought on systemd.

libgnutls-deb0-28.so.28 ?

Thank you, and welcome. Good practice for another time, when you run into something harder.

You mention /usr/lib/mozilla/plugins/flash-mozilla.so twice already, so if I mention it once more, it'll sure be the right place

I'm not too well versed in this, but I might be able to help.

Firstly, I think that your /etc/udev/rules.d/10-scanner.rules should have a single rule line. It should be read "if the vendor is 0x04f9 and the product is 0x0330, then make the /dev/whatever pathname have group scanner". All that needs to be on a single line.

What you have done is rather three independent statements: "if the vendor is 0x04f9, then eeh nothing", "if the product is 0x0330, then ehh nothing", "if whatever, then set /dev/whatever to have group scanner". That last one in particular is quite "destructive" (although there might be some kind of protection in udev for that kind of mistake).

But, when I look at the libsane rules (i.e., /lib/udev/rules.d/60-libsane.rules) it suggests that you should rather have the assignment

..., ENV{libsane_matched}="yes"

as effect instead of setting access group. I think the deal is that the scanner dev's (for whatever [expletive] reason) have decided to use "acl" rather than unix file protection, and they also have programmed their rules to use a common, actual effect via the setting of the libsane_matched variable.

So, if making it a single line doesn't work, you might try replacing the GROUP assignment with that assignment.

EDIT: note the comma (",") between the terms; i.e., when you join your lines, you need to add "," comma between them.

If I may suggest a couple of "improvements" within that scheme, to in particular simplify the picture for the helpee.

Firstly that you set up key based authentication for helpee, to ssh to you without password.

Secondly that you set up ~/.ssh/config for helpee with a short logical hostname to your host. In that you would also reverse forward to both ports 22 and 5900 in the single ssh link. E.g. like the following stanza

Host help
   hostname ...
   user ...
   identityfile ...
   remoteforward 7000 localhost:22
   remoteforward 5901 localhost:5900

Thirdly a script for the helpee to run the two things as one:

ssh help & x11vnc

With the second forwarding, you, the helper, would only need to run vinagre against localhost:5901, or indeed xvnc4viewer against :1, and also have the ssh back link on localhost:7000.

I suppose x11vnc accessed with xvnc4viewer via ssh is too old-fashioned?