addingnumbers

grep isn't necessary at all here:

  lsof -s TCP:LISTEN -i :$port

Proxy ARP would have the raspberry pi provide its own MAC address as the MAC for the server IP. All the traffic from the clients to the backup server would have to pass through the Pi's network interface for the duration of the session.

With this ARP stand-in, it provides the server's MAC to the client so subsequent traffic to the server doesn't need to pass through the Pi.

The alerts tend to be geared more toward attempts to reach a secured system that isn't accessible to you.

> Answer "I don't know" if you are not 95% certain they exist.

Technically, this could be read as == instead of >=, meaning it should answer "I don't know" when it is 99% or 100% certain...

> All it takes to get rid of snaps forever is `sudo apt purge snapd`.

That's not enough. Some package could eventually drag it back in.

    $ apt show firefox
    Package: firefox
    ...
    Pre-Depends: debconf, snapd

If you really want to keep it off your system for good, you need something like this:

    $ cat /etc/apt/preferences.d/no-snapd
    Package: snapd
    Pin: release a=*
    Pin-Priority: -1
    $

Add this to your login script:

  export FZF_DEFAULT_OPTS="--exact"

Or invoke it with one of these:

  fzf --exact
  fzf -e

Or if you start your search with a single quote ' it disables fuzz. (But maybe you already knew that, it sounds like you want the first option.)

It returns non-zero exit codes when there are no matches or no selections made, so you can shorten that:

  fuzz() { file=$(fzf) && nvim "$file"; }

Won't recursing also spread your queries across multiple providers? And in the clear for deep packet inspectors to see, instead of encrypted?

> In Gilbert and Sullivan's Pirates of Penzance, Frederick is indentured to a band of pirates until his 21st birthday.

That particular wording coming back around to bite him when it's pointed out that he was born on February 29th in a leap year...

That's a petty interpretation, it's a big leap reading "don't send your unique identity to strange servers by default" as "never use private keys, always use passwords instead."

Nothing about that config snippet precludes using private keys for known servers.

That's all from the 1807 moralized version, the 1734 version doesn't have any golden eggs, goose, or harp. In the older version the giant swings a sword at him and dies himself instead by the protection of a magic ring Jack found on the way up. Then the giant's human servants appoint him king of the castle.

> only including data from users who have turned on "Make searches and browsing better (Sends URLs of pages you visit to Google)"

One big problem there is that we don't know what percentage of users for whom "turned on" is a euphemism for "didn't notice."

I'm surprised they didn't recommend dnsmasq to begin with, it's a lot lighter on resources which could be important with low-end machines, and with DNS and DHCP services baked in to one process you don't need to worry about configuring hungrier services like dhcpd and BIND to read each other's state.

The only reason I'd recommend dhcpd/bind over dnsmasq for a small lab is if you are trying to familiarize yourself with the former pair for use in larger networks with more expansive requirements.