Well, if things work as is, then you may well leave it at that.

Otherwise, the one thing I could pick up was the missing broadcast address in wicd-wired-settings.conf, which might make a difference; perhaps it causes the networking stack to fail in its ARP. You should probably assign that to 192.168.0.255 or whatever is correct for your subnet.

And otherwise^2, I think the "proper" way to avoid wicd managing eth0 would be to avoid the wired_interface = eth0 assignment in wicd-manager-settings.conf, and instead make that wired_interface = (or remove it, perhaps). For myself, I use wicd-curses rather than editing the configuration files directly.

In general, and as you probably know, the interfaces file is used by the ifupdown network management system, whereas wired-settings.conf is used by the wicd network management system. The former is more passive, and only operates on interfaces as explicitly commanded, e.g. # ifup eth0.

wicd is actively managing the interfaces it is told to manage; it's a daemon program that discovers changes to interface status and acts on these. Especially, if you have told wicd to manage eth0 it will do so, but if you haven't, it won't. I think wicd by default will configure itself to manage eth0 upon installation, but it's certainly the first thing to confirm.

If wicd is set to manage eth0, then it will do so according to wired-settings.conf. There's barely any magic involved at all, though in some cases mis-behaviour would be due to some bug rather than configuration mistakes. So let's see yours.

A simple way to download all installed binary packages could the following command:

$ dpkg-query -f '${Package}=${Version}\n' -W | xargs -n 1 apt-get download

Similarly, to download all source packages you would use the following:

$ dpkg-query -f '${Package}=${Version}\n' -W | xargs -n 1 apt-get source --download-only

Both will populate the working directory.

Yes, your IP got classified as "dubious", not so much as a quality assessment of your posts, but automatically because you (or your software) made a spurious "HEAD /req_message HTTP/1.1" request, which is an unserviceable request. All unserviceable requests gain the dubious qualification, and the subsequent lockout from the server. (I shouldn't tell you when it happened to golinux, or myself even ).

Which program did you use?

If you don't know, then you probably haven't set any pin preferences.

You do know that the last image was 116 Mb, I suppose. Please use the text copied into the posts, rather. You can pipe output to file, or use script to get a typescript file.

Anyhow, I'm guesing your iptables (v1.6.1) is from ascii-backports; where's your kernel from?
Do you have the /lib/modules/$(uname -r) sub tree with kernel modules?
Specifically do you have /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko, which is the module concerned?

Isn't that just a matter of choosing which encryption algorithm(s) your server accepts? I.e., it's your choice, and a property of your running server; not a property of the software as such. And based on a rather superficial web search, I believe that the answer is "Yes": there is a sufficient number of algorithms to use to make your ssh service compliant.

I suppose you'll then need to arrange for running /sbin/getty 38400 tty7 in runlevel 3. For example, you add a line for this to /etc/inittab, to let init manage it:. E.g., the following as a line after the tty6 line might do the job:

7:3:respawn:/sbin/getty 38400 tty7

Have you tried with rfkill (tool for enabling and disabling wireless devices)? As in a "googled" example:

# modprobe -rf ath9k ath9k_htc
# rfkill unblock all
# modprobe ath9k ath9k_htc

I'm not sure what's the difference from Debian though. It would depend on versions, since the code for bringing up interfaces has had some development recently (last few years). Not long ago, it had a bug where the script could query the interface state too early after power-on. The patch against that problem was to add a sleep into the script between starting the interface and checking its state.

You could also try to use the "auto" method rather than "allow-hotplug", to let the networking init script raise the interface instead of (e)udev.

Well, I'm no expert on this, but I think it's the lines following that log line that should tell whether the input is actually added or ignored. On the other hand, it's apparently eudev that presents the lid switch to X in the first place, presumably during its traversal of /sys. Perhaps it traces back to /lib/udev/rules.d/80-libinput-device-groups.rules  or 90-libinput-model-quirks.rules, or some other rule(s), and perhaps there's a suitable knuckle-rap to make eudev ignore the lid switch instead.

Thus I'm thinking that whatever it is that results in the /dev/input/eventX device node should be patched to not do that for the lid switch, and then it won't be presented to X. I tried this by removing /dev/input/eventX manually, and restarting X (not rebooting), which resulted in a log without a "Lid Switch" discovery line. Maybe you could try that as an experiment to see if it makes any difference for your graphics problem. Otherwise it's probably no use in digging deeper.

actually it's the  opposite for in/out .... it's page zoom and not text zoom, but ctrl-+ works now.

Right. I suppose you'll need a sibling or replace of /usr/share/xsessions/xfce.desktop to make that happen. Perhaps by replacing all "xfce" with "mate"; and maybe add some particular hand-crafting to the "Exec=..." line at the bottom. Or, just hang around until someone who knows something swings by

Great. You might even want to lodge a bug report on pm-utils to add the appropriate vendor quirk combination into the database for T400.