I think that rocket still stands [0] :) [0]: https://en.wikipedia.org/wiki/Maxus_(rocket) [1]: http://www.astronautix.com/m/maxus.html

There are no see cows mentioned in the Wikipedia article about Merovech [0]. I have no knowledge about this, but such a juicy databit should just jump at you, if it was true. Instead, a quite mundane etymology around ‘merovech’ is provided.

One of these articles are wrong :)

0: https://en.wikipedia.org/wiki/Merovech

The link you gave does not seem to work :)

In 1995, World War III almost broke out after a rocket launch from the exact same location [1]. It was only a coincidence that stopped the Russians from doing retaliatory nuclear rocket launches. So, indeed, launching to the east is not a good idea from this latitude.

1: https://en.wikipedia.org/wiki/Norwegian_rocket_incident

Else is a common name in my part of the world and capitalizing the word makes the connection more explicit.

Bear? It is more like a stray dog that keeps shitting on your living room carpet. You don’t need to hate the dog, you just keep it on the outside where it can run around and have a great time on it’s own.

Interesting. I came in contact with dynamic programming as a means to implement the Viterbi algorithm in an equalizer. This relates to calculating “cost” of routes through a trellis, where you accumulate partial results corresponding to alternative routes.

DSPy?

If writing performance is critical, why bother with deduplication at writing time? Do deduplication afterwards, concurrently and with lower priority?

Keep in mind ZFS was created at a time when disks were glacial in comparison to CPUs. And, the fastest write is the one you don't perform, so you can afford some CPU time to check for duplicate blocks.

That said, NVMe has changed that balance a lot, and you can afford a lot less before you're bottlenecking the drives.

Because to make this work without a lot of copying, you would need to mutate things that ZFS absolutely does not want to make mutable.

If the block to be written is already being stored then you will match the hash and the block won't have to be written. This can save a lot of write IO in real world use.

Kinda like log structured merge tree?

This is an interception scenario, no? If issued intentionally, traffic will pass through hardware in… unfriendly territory.

Yes, but doing it intentionally isn't as simple as one might think. First, BGP generally prefers the shortest path and yours is going to be a little long, so unless the best original path is very long you need on some transit provider to use policy-based routing and trust you as transit. Second, if you want the traffic to pass through your hardware you have to have sufficient bandwidth, otherwise you'll just trigger packet loss and disrupt service (fine if disruption is your goal, not so fine if you want the traffic to pass through your hardware). Third, some people use signed routes, which also complicates your job.

About

> First, BGP generally prefers the shortest path and yours is going to be a little long, so unless the best original path is very long you need on some transit provider to use policy-based routing and trust you as transit.

the article states:

> The leaked route is likely preferable because of a localpref setting which would prefer sending traffic for free through a peer regardless of the AS path length, over paying to send traffic through a transit provider.

Right. That's policy routing. You can talk to an ISP, have a cable installed and a peering session, gain trust, offer cheap or free traffic delivery, and then publish a route via that session. Your trusting peer may/will then send traffic to that route via you.

This happens legitimately, e.g. when an end-user becomes multihomed or starts using anycast, so the trusting peer can't necessarily discover this algorithmically. Route signing helps.