fach

Agreed. I was following Debian mainline releases but grew tired of out of date packages and putting my hopes and dreams into *-backports. After migrating to testing, it's been smooth sailing for well over a year and I've grown to appreciate a rolling release cycle.

One could argue the one lie by a public figure, given a large enough following, can translate into a lie repeated a billion times by main street users. It's certainly less probable when the lie is sourced in the other direction.

I would think engagement would be a core metric you would be measured against in this example. And if that’s the case, this certainly isn’t a side effect.

> RPKI is just crypto nerds trying to math their way in to a human and financial problem.

This is an interesting perspective. Do you have the same opinion of certificate authorities?

CNN isn't telling people there aren't enough of them. The governor of New York is telling people there aren't enough of them.

I don't know how you look at a metropolitan area like NYC overrun with cases, and decide there isn't a need there. Are they waiting until it hits Montana?

They are for the states but my favorite theory is a large number don't work[1] and the administration is attempting to save face until they can swindle replacements internationally.

[1] https://www.nytimes.com/2020/04/01/us/politics/coronavirus-v...

A portion of the heat is probably from their peers/friends/family outside the company since the company has such a negative stigma right now. Another portion is due to the fact a significant portion of their income is tied to the market value of the company, which is now back at Feb. 2017 levels and declining, both due to the negative press cycle and bearish long term outlook by the market.

There's an important aspect of BGP you're overlooking: mutual acceptance. If one party exports a prefix, the other party can choose to either reject or accept the prefix. If the former party does not advertise the prefix or the latter party does not accept the prefix, no unidirectional forwarding path is established. Yes, Google could have derived their export policy based on their RADB entries, which would have prevented this issue. But Verizon could have also derived their import policy based on their RADB entries, which would have prevented this. While Google is at blame for fucking up their export policy, Verizon is at blame for simply accepting these prefixes.

Doing a 1:1 comparison between what you're currently receiving on import and RADB isn't completely fair given most folks who preallocate address blocks will register route objects long before they are actually used.

What is preventing you from crafting your import policies based on this data? Google is clearly creating route objects for most of their prefixes and rejecting a handful of prefixes vs. the risk of accepting at worst a full table seems like a reasonable tradeoff. This is something Verizon could have done, and something other folks like Level3 have done for some time.

They don't?: https://pastebin.com/5ngq1cJi

Based on the article, you probably should be s/Google/Verizon here. Yes, Google's export policy was misconfigured towards Verizon but Verizon blindly accepted and propagated these prefixes.

What does "peer to peer with no routers mean"? Also, with all the benefits of FPGAs, you seem to gloss over power consumption. Any concern there?

This is the distinction between third-party recruiters and first-party recruiters. When I was hired via a third-party recruiting company, all negotiations happened via the recruiting company on behalf of myself. This was successfully because, as you mentioned, our interests were aligned, and as a result, I went from a 60k a year role to a 120k a year role. On the other hand, when I moved on from the 120k a year role, I dealt with first-party recruiters, where their interests were aligned with the hiring company, which means attempt to bring me on as cheap as possible. In the later case, it is clearly not in your best interest to disclose salary.