btw if you care about  IEEE Registration Authority, a "locally administered mac address" needs bit 2 of first byte set and bit 1 cleared. Thus "5e" would be better than "5c".
see eg http://www.noah.org/wiki/MAC_address

Ideally you should insert the locking program before the suspend action as otherwise it'll wake up unlocked until the locking starts. For example:

if [  "$3" = "close" ] ; then
     DISPLAY=:0 su -c "xtrlock -b" ralph &
     /usr/bin/obsession-exit -s
fi

Note also that (afaik) the lid button script is run by acpid as root and not "the DE user", so a sudo isn't needed, but some way to ensure GUI access is. The added command line above includes the two parts of making the locking program (xtrlock) have the right $DISPLAY set up, and (via su) be the right user (for my laptop).

A smaller footprint  solution would simply read byte triplets from /dev/input/mice, where <9,0,0> means left button down, and <8,0,0> means left button up; all other triplets mean other things. I would use newlisp, of course, to remain in small foot print scripting, but a small C program could also do.

Sorry. I lost interest there. Too many words. To paraphrase Ramsey: "What you can't say in just a few words, you should whistle.".

To be clear, ICMP is a protocol and not a port; it's the Internet Control Message Protocol, whereby routers may exchange meta-data about IP level connectivity. There are several networking protocols to consider, both within the IP class (such as in particular TCP and UDP), and outside the IP class (in a range of varying obscurity).

As said before, there is no such thing as "invisible" on the Internet, short of not being connected at all. But there is a gray scale of "protection layers" of setting blockages for certain network traffic, depending on how you want your host to handle it. I'.e., like the rules you showed on top, which indeed tells the host to drop certain incoming ICMP packets, rather than deliver them to their normal handling (by the kernel). I think you'd do well in dropping IGMP as well, and then consider blocks for TCP and UDP messaging, which offer the majority of intentionally harmful networking.

You can install eudev=220:3.2.2-devuan1 from experimental on Jessie, but you need to make sure to also install libudev1=220:3.2.2-devuan1, which is its companion (despite the name).  The latter might be noted as a downgrade (relative jessie-backports), but that's nothing to worry about.

Nothing to worry about. I'm pretty sure it's the right pathname.
But it just made me think about the Bellman.

To be sure, each rule is on a single line. Refer to

man udev

for details.

Make a failed login attempt and see that btmp has grown

man last
man lastb

... a bit sad to learn there was no magic

As for the reverse port forwarding, you might have overlooked the option of reverse-forwarding port 5900, which is the default port vnc uses for the :0 display. Though, with gitso working for you, there's no need to pursue this.

If it's similar to my problem, https://dev1galaxy.org/viewtopic.php?pid=4135#p4135, then that xhci quirk setting might be a good thing for you as well.

According to the hopefully relevant web page, here, you need to add a udev rule, which they provide a script for. That script however seems to concern a different idVendor:idProduct device from yours, and it would therefore not be immediately applicable.

However, since the script merely creates a new file to the udev configurations, /etc/udev/rules.d/73-beaglebone.rules, it is safe to try it, but first edit the script: replace the two occurrences of 0403 with your idVendor code, 1d6b, and the two occurrences of a6d0 with your idProduct code, 0104, before running the script (as root).

If it's helpful, it's all good, and if not, you can just remove the file.