Just a little bit of background:

When '/etc/network/interfaces' (or any one of its sourced files) includes a line "auto eth0", it is a signal to the networking init script, that it should bring up eth0 on boot. That init script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.

When '/etc/network/interfaces' (or any one of its sourced files) includes a line "allow-hotplug eth0", it is a signal to udev, that it should bring up eth0 on boot (and also keep monitoring for later cable events). Its control script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.

Of course, dhclient is only used as part of bringing up the interface if '/etc/network/interfaces' also has the line 'iface eth0 inet dhcp'.

If you are using a network manager, then you should avoid telling the networking init script or udev to bring up eth0, but rather let the network manager daemon deal with it. Whether that induces a boot delay or not depends on whether it has been improved in parity with the scripts.

btw, for the sake of clarity: I write 'improved' but I mean 'destroyed'.

That's such a beautifully mis-informed notion!

It reads as a praise to the layers and layers of code in between the person and the action, simply to make a drawing of it, so it can be operated without articulated thought.

Other than that, I have nothing

You probably can set something up based on using a network namespace for the proxy server. That's in principle the same as the notion of it running in a VM, but without the VM.

The default namespace would be set up with its default route into the proxy namespace. The proxy namespace would be set up with its default route through NAT back out to the default namespace, and that traffic would need rule based routing to channel it through an outgoing NAT.

Or alternatively, you use rule based routing to direct traffic into the proxy namespace, and rely on the default route for the final channeling. I think you'll need the two NAT in either case.

The direct answer is "No". The notion of "master file" only concerns that example, and refers to the "salient path name" encoded into the automatic setup script. (As you know, that example is not ideal in my view, with the automatic setup attached to and repeated with any and all interface(s) coming up.)

iptables-persistent instead enshrines the path names /etc/iptables/rules.v4 and /etc/iptables/rules.v6 as being its "master files".

Hmm, by attaching the loading of table rules to the event(s) of bringing up an interface, you probably make life a little bit difficult for yourself. It's not "wrong" per se, and probably the only major complication is that in a typical set up, the network interfaces are brought up by udev in the pre-pivot boot up stage.

If that is your case, you will need to ensure that the rules files are included in your initrd, as well as the iptables-restore program and its dependencies (libraries). (I believe the if-pre-up.d script gets pulled in to the initrd automagically when remaking initrd).

Or alternatively, make that not be your case by not letting udev start networking. I.e., remove all "allow-hotplug" phrases from /etc/nework/interfaces. Possibly use "auto <if>" phrases instead, which tells the post-pivot networking init script that "these are yours, mate", or if then you also have a separate network manager, you'll need to leave all song and dance to it.

EDIT: I see from your other post that you're using wicd, so my thought about udev is probably not applicable here. Maybe it's enough to make your script exit more promptly when lo is brought up; or even tie it explicitly to $IFACE=wlan0.

Yes, according to FSSTND, you'll need to venture off the ranch for that one.

Fair enough. If you are in the mood for tinkering, it's not really a difficult thing to start an X program over slim. The fundamental aspects are to have the XAUTHORITY and DISPLAY properly set when starting the program, and to start the program at the right time, i.e., after slim.

I don't have florence but can illustrate using xvkbd instead.

For example, it might be sufficient to add a line into your /etc/rc.local file, making it look like this at the end:

( sleep 5 ; XAUTHORITY=/var/run/slim.auth DISPLAY=:0 /usr/bin/xvkbd ) &
exit 0

That line supposedly will start the virtual keyboard xvkbd upon reboot, after 5 seconds, on top of the slim login splash.

You will need to adjust as appropriate for florence of course.

Note that (assuming it works) the virtual keyboard only comes up after reboot, and not again when you log out. But maybe that is sufficient.

Since I (and you?) don't have cups, disabling it for cups is not a solution.

I managed to get the (standard) ASCII 4.9.0-4-amd64 kernel to avoid loading parport and friends by having boot parameter

lp=none

together with blacklisting:

# echo blacklist parport > /etc/modprobe.d/blacklist-parport.conf
# echo blacklist parport_pc >> /etc/modprobe.d/blacklist-parport.conf
# update-initramfs -u

It needs both kernel parameter and blacklisting. Possibly lp=0 would work as well, but I couldn't bother testing it.

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.