Ben Cardy networking, lego, programming, photography, and more

NASA Administrator Remembers Mission Control Pioneer Chris Kraft

Chris Kraft, NASA’s first Flight Director, died yesterday, two days after the 50th anniversary of the first man on the moon.

Once comparing his complex work as a flight director to a conductor’s, Kraft said, ‘The conductor can’t play all the instruments–he may not even be able to play any one of them. But, he knows when the first violin should be playing, and he knows when the trumpets should be loud or soft, and when the drummer should be drumming. He mixes all this up and out comes music. That’s what we do here.’

It’s almost as if he waited for the anniversary. The world remembers the names of the men who set foot on the moon, but Chris Kraft was another hugely important person managing the hundreds of highly skilled engineers and scientists without whom the moon landing would not have been possible.

We’re fast approaching a time where there will be nobody left who was involved in project Apollo. It will never be forgotten, but it will be sad to no longer be remembered first hand.

Self-Host Your Static Assets

Harry Roberts, writing at CSS Wizardry:

One of the quickest wins—and one of the first things I recommend my clients do—to make websites faster can at first seem counter-intuitive: you should self-host all of your static assets, forgoing others’ CDNs/infrastructure. In this short and hopefully very straightforward post, I want to outline the disadvantages of hosting your static assets ‘off-site’, and the overwhelming benefits of hosting them on your own origin.

I’m a little late to this (the post was written back in May), but it’s an interesting counter argument to the common practice of serving third party resources from a provider’s CDN. The post goes into a lot more detail, but if you can, host it yourself.

The Two-Napkin Protocol

An interesting piece of history I didn’t previously know.

It was 1989. Kirk Lougheed of Cisco and Yakov Rekhter of IBM were having lunch in a meeting hall cafeteria at an Internet Engineering Task Force (IETF) conference.

They wrote a new routing protocol that became RFC (Request for Comment) 1105, the Border Gateway Protocol (BGP), known to many as the “Two Napkin Protocol” — in reference to the napkins they used to capture their thoughts.

The post is worth a read just to see the photos of the napkins. I’ve never really thought before about how RFCs come to be. I’d always assumed they were the result of clever people in offices, not really thought up on the back of a napkin over drinks!

Also, as it’s 2019… happy 30th birthday, BGP (and the World Wide Web).

The Infrastructure Mess Causing Countless Internet Outages

Roland Dobbins from Netscout Arbor, quoted in this Wired article:

“Nonspecialists kind of view the internet as this high-tech, gleaming thing like the bridge of the starship Enterprise. It’s not like that at all. It’s more like an 18th-century Royal Navy frigate. There’s a lot of running around and screaming and shouting and pulling on ropes to try to get things going in the right direction.”

It’s amazing how fragile some of the technologies that power something the world takes for granted are; BGP is a great example of that. The Internet is everywhere, and it’s becoming increasingly more necessary to be connected in order to be able to just go about our lives.

Regarding the choice of headline, however, I don’t think the word “mess” is fair. That does a disservice to the hundreds of very talented people that design, implement, and maintain the infrastructre that underpins our connected world.

Junos: Confirm a commit cleanly

For years, I have loved the fact that Junos allows you to perform a commit confirmed to apply the configuration with an automatic rollback in a certain number of minutes.

I have always believed that the only way to confirm the commit (i.e. stop the automatic rollback) was to commit again. This creates two commits in the commit history, one containing the actual config diff, and an empty one purely used to stop the rollback. I’ve always thought that this creates a somewhat messy commit history, and confuses the use of show | compare rollback:

[edit]
ben@device> run show system commit
0   2018-07-27 08:44:26 BST by ben via cli
1   2018-07-27 08:44:07 BST by ben via cli commit confirmed, rollback in 5mins
2   2018-07-23 10:04:29 BST by ben via cli
3   2018-07-23 10:03:58 BST by ben via cli commit confirmed, rollback in 2mins

[edit]
ben@device> show | compare rollback 1

[edit]
ben@device> # Huh, it's empty?! I'm sure I did some work...

[edit]
ben@device> show | compare rollback 2
[edit system]
-   host-name old-device
+   host-name device

[edit]
ben@device> # Oh, there it is...

However, today I learnt that a commit check is enough to stop the rollback, and doesn’t create an empty commit! My commit histories are now much cleaner, and show | compare rollback commands a lot easier to work out what you’re actually looking at.

[edit]
ben@device> run show system commit
1   2018-07-27 08:44:07 BST by ben via cli commit confirmed, rollback in 5mins
3   2018-07-23 10:03:58 BST by ben via cli commit confirmed, rollback in 2mins

[edit]
ben@device> show | compare rollback 1
[edit system]
-   host-name old-device
+   host-name device

Much better!