That advertisement would be interpreted as Node C’s advertisement.

The plan is to treat public keys as node’s identity and trust mechanism similar to OpenPGP (e.g. include any node key signed by a master key as a cluster member)

Right now, none of the encryption part is done and it is not a priority right now. I need to first implement transitive node detection, actually forward packets between nodes, some way to store and manage routes, and then trust and encryption mechanisms before I’d dare to test this stuff on a real network.

The UI is desktop only for now, I’ll make the mobile UI some day.

I didn’t know the answer either, but usually you can compose solution from solutions of smaller problems.

solution(0): There are no disks. Nothing to do. solution(n): Let’s see if I can use solution(n-1) here. I’ll use solution(n-1) to move all but last disk A->B, just need to rename the pins. Then move the largest disk A->C. Then use solution(n-1) to move disks B->C by renaming the pins. There we go, we have a stack based solution running in exponential time.

It’s one of the easiest problem in algorithm design, but running the solution by hand would give you a PTSD.

Replacing “Programmers:” with “Program:” is more accurate.

Technically, containers always run in Linux. (Even on windows/OS X; on those platforms docker runs a lightweight Linux VM that then runs your containers.)

And I wasn’t even using Docker.

How I lost a Postgres database:

1. Installed Postgres container without configuring a volume
2. Made a mental note that I need to configure a volume
3. After a few days of usage, restarted the container to configure the volume
4. …
5. Acceptance

You are not alone.

Just did some basic testing on broadcast addresses using socat, broadcast is not working at all with /32 addresses. With /24 addresses, broadcast only reaches nodes that share a subnet. Nodes that don’t share the subnet aren’t reachable by broadcast even when they’re reachable via unicast.

Edit1: Did more testing, it seems like broadcast traffic ignores routing tables.

On 192.168.0.2, I am running socat -u udp-recv:8000,reuseaddr - to print UDP messages.

Case 1: add 192.168.0.1/24

# ip addr add 192.168.0.1/24 dev eth0
# # Testing unicast
# socat - udp-sendto:192.168.0.2:8000 <<< "Message"
# # Worked
# socat - udp-sendto:192.168.0.255:8000,broadcast <<< "Message"
# # Worked

Case 2: Same as above but delete 192.168.0.0/24 route

# ip addr add 192.168.0.1/24 dev eth0
# ip route del 192.168.0.0/24 dev eth0
# # Testing unicast
# socat - udp-sendto:192.168.0.2:8000 <<< "Message"
2024/02/13 22:00:23 socat[90844] E sendto(5, 0x5d3cdaa2b000, 8, 0, AF=2 192.168.0.2:8000, 16): Network is unreachable
# # Testing broadcast
# socat - udp-sendto:192.168.0.255:8000,broadcast <<< "Message"
# # Worked

Here is a trick that has been tried and tested over the years: Install another distro, and use that to install Arch. This way, you can rely on an already working linux distro till your Arch install works the way you want.

You have rust.

You get a horse and arrive at the castle within seconds but the horse is too old and doesn’t work with the castle.

You remove the horse, destructure the castle and rescue the princess within seconds, but now you have no horse.

While you’re finding a compatible horse and thinking whether you should write your own horse, Bowser recaptures the princess and moves her to another castle.

https://imgur.com/8p7oPbp

That error doesn’t occur if you only ever copy the code as-is taps head

I just keep my stuff far away from $HOME and not bother about the junk. Not even a subdirectory under $HOME.

Same goes for ’ My documents’ on windows.

I don’t like the mess some software makes when it install in my system

I gave up bothering about this a decade ago and I just store my files elsewhere while software treat the home directory as ‘application data’.

Well, we could allow root login via passwordless telnet so that they can be extra sure that we aren’t hiding anything.

Together we can make this happen!

sleep 120 #TODO: actually solve a problem
echo "Sorry, we could not solve this problem."

Gosh, if I ever get into the business of writing software for spacecraft with long duration missions, I have to test for such cases.

Features necessary for most btrfs use cases are all stable, plus btrfs is readily available in Linux kernel whereas for zfs you need additional kernel module. The availability advantage of btrfs is a big plus in case of a disaster. i.e. no additional work is required to recover your files.

(All the above only applies if your primary OS is Linux, if you use Solaris then zfs might be better.)

Go: Why is your every second sentence a caution?