My humble boot installer, no explicit bootloader, straight to the kernel:

    #!/bin/bash
    set -ueo pipefail

    # Remount EFI partition read/write and restore to readonly when done

    trap 'mount /sys/firmware/efi/efivars/ -o ro,remount &>/dev/null || true' EXIT
    mount /sys/firmware/efi/efivars/ -o rw,remount &>/dev/null || true

    # Remove all existing Arch Linux entries

    efibootmgr | grep 'Arch Linux' | grep -Po 'Boot\K\d+' | while read -r bn; do
      efibootmgr --delete-bootnum -b "$bn" &> /dev/null
    done || true

    # Install boot entry

    efibootmgr --verbose \
      --create --disk /dev/disk/by-id/nvme-abcdef --part 1 --label "Arch Linux" \
      --loader /vmlinuz-${_linux} \
      --unicode "initrd=\\intel-ucode.img initrd=\\initramfs-linux.img OTHER-KERNEL-BOOT-PARAMS"

EDIT: added initrd boot params

I buy old SAS/SATA drives that have lots of hours on them. They tend to look like this:

https://pastebin.com/raw/E39HuK59

Run SMART, check the stats, make sure the grown defect list is 0, make sure it's never been over-temp, run a SMART long test, run bad blocks, run another SMART long test. If it passes all those I'd be fine continuing to use it.

The HUH728080ALE600 drives in that server[1] idle at 5.1 watts[2], so it's 184 watts just on the drives. I'm guessing at idle the server runs around 300 watts. Which is not great, but it's not terrible. I pay ~ $1/watt/year in NC, so running that server 24x7 would cost me $300 annually.

If it were me I'd disconnect at least half the drives to keep as spares.

1. https://imgur.com/a/zb6Mqty

2. https://documents.westerndigital.com/content/dam/doc-library...

A shameless plug here I've been working on a project of my own called [Marmot](https://maxpert.github.io/marmot/) with the intention of making SQLite replication masterless and eventually consistent. Project is in very early stages, and I've been using it for one of my site replicating a cache based off SQLite. It builds on top of NATS (I love NATS), and distributes itself over JetStreams.

In many ways, IPv6 stacks are simpler than their IPv4 counterparts. The fixed packet headers are simpler and faster to parse, ICMPv6 includes both router and neighbour solicitation (as opposed to being separate protocols like ARP in IPv4), routers generally won’t fragment large packets in transit (instead giving way to Path MTU Discovery) and NAT is not so widely needed as it is in IPv4.

That said, the fixed packet headers being slightly longer means there’s actually slightly less room for the payload in an IPv6 packet compared to IPv4 on an otherwise equivalent link MTU.

I’m not entirely sure what to make of the results in the article though and the title really should be leading with asking why in order to be less sensational. The only explanation I can think of right now is that many routers have historically deprioritised ICMP traffic or even dropped it when under heavy load, but given that ICMPv6 is much more core to the functioning of IPv6 in general, it is perhaps not as feasible to do so for ICMPv6.