t's a limitation imposed by the ping programme itself, it'll refuse to use very short intervals if you're not root. This is documented in the man page. Or, use the source, Luke:
case 'i': /* wait between sending packets */
t = strtod(optarg, &ep) * 1000.0;
if (*ep || ep == optarg || t > (double)INT_MAX)
errx(EX_USAGE, "invalid timing interval: `%s'",
optarg);
options |= F_INTERVAL;
interval = (int)t;
if (uid && interval < 100) {
errno = EPERM;
err(EX_NOPERM, "-i interval too short");
}
break;
And if you keep looking, Apple's version of ping keeps track of the number of sent and received probes, but does not keep track of the largest difference between the sequence nubmer of sent and received probes, so it will not print the same "pipe" value as the iputils version of ping (ie. the version you typically get in Linux).
$ dpkg -S /bin/ping
iputils-ping: /bin/ping
$ grep 'downloaded from' /usr/share/doc/iputils-ping/copyright
It was downloaded from https://github.com/iputils/iputils
$ git clone https://github.com/iputils/iputils
...
$ cd iputils/ping
Then a bit of looking around shows that in acknowledge() (an inline helper defined in ping.h), pipesize records the largest difference between the sequence number of the (last) outbound probe and than the sequence number of the inbound probe we're receiving. That function is called from gather_statistics() (for the happy path) and in a couple of other locations when receiving an ICMP error.
$ pacman -Qqo $(which ping) # -Qqo is --query --quiet --own
iputils
$ asp export iputils && cd iputils
$ # see PKGBUILD for URLs, or if you just want to have a look:
$ gpg --import keys/pgp/*.asc # or pass --skippgpcheck to makepkg below
$ makepkg -od && cd src # -od is --nobuild --nodeps
for the second step usually works, although I don’t know how to figure out the package name reliably (ls -l will usually point you in the right direction, but for ping it just gives you the wrapper).
Using DHCP, the same tool that can configure any client computer with addresses and gateways, meaning you hopefully secure that already.
Some switches give you tools to mark a few physical ports as "truster", allowing DHCP OFFER from those; and drop (or ever shutdown the port!) when such a packet is received on an untrusted port.
Where did you get the idea that anybody on the Internet can?
The first step to network booting (PXE or UEFI boot) requires DHCP, which means a DHCP server or relay on your local broadcast domain (switched LAN, and I'm sure there are extensions for boot-over-WIFI somewhere).
Sure your computer could fetch the boot image over the Internet, if you're okay with involving the unreliability of the Internet in your boot process, but that'd require explicit configuration on your DHCP server.
I work in networking, not particularly close to the hardware. I have colleagues who manipulate IP addresses by looking at the string representation of the address, splitting on the `.`, casting each part back to an integer, etc. Their code breaks as soon as we use a netmask other that /24 or (shock, horror!) we run in an IPv6 environments.
TCP tries really hard to avoid fragmentation, by setting the DF flag and reducing the MSS when it sees a PTB error.
Of course that sometimes fails, so if you still have TCP fragmented segments, the next best thing is to filter by source/destination address, saving to a PCAP file, then run tshark on that file with the "-2" flag which does packet reassembly.
(I don't know if tshark can be made to do on-the-fly reassembly, that would require keeping a buffer of un-reassembled fragments until the rest of the packets are seen.)
Wooly jumpers, especially when made of fragile merino wool, remain usable for much longer when they are made of a mix that includes plastic fibers (maybe 75% merino, 25% polyester).
The sweaters are 100% wool, but are the thick knitted type. Think a classic fisherman sweater or the Icelandic lopapeysa. These are not merino. Base layer is merino, might be a polyester/wool mix.
> But that set must have a member whose value is closest to zero
This is not true for real numbers with the usual "less-than" relation. In fact, considering real numbers, no open subset of R admits a lower member.
According to Zorn's lemma, there exist some order relation where your assertion is true, but I seem to remember from my math course a few (!) years ago that Zorn's lemma is equivalent to the axiom of choice.
According to the well-ordering theorem which is equivalent to the axiom of choice (and Zorn's lemma), you can well-order any set. That's usually when people start doubting the axiom of choice because, well, that's quite unintuitive. There is a joke about it which has already been posted here.
You can well order any set, but you need to have the "right" ordering to do so. As your parent is pointing out, the usual ordering on the reals is not a well ordering, and one cannot achieve a well ordering of the reals using that ordering.
https://github.com/apple-oss-distributions/network_cmds/blob...
And if you keep looking, Apple's version of ping keeps track of the number of sent and received probes, but does not keep track of the largest difference between the sequence nubmer of sent and received probes, so it will not print the same "pipe" value as the iputils version of ping (ie. the version you typically get in Linux).