In 2018, the Camp Fire devastated a huge swathe of California, claiming 85 lives and costing 16.65 billion dollars. Measured in terms of insured losses, it was the most expensive natural disaster of the year, and the 13th deadliest wildfire in recorded history.
The cause of the fire was determined to be a single failed component on an electrical transmission tower, causing a short circuit and throwing sparks into the dry brush below – with predictable results. The story behind the failure was the focus of a Twitter thread by [Tube Time] this week, who did an incredible job of illuminating the material evidence that shows how the disaster came to be, and how it could have been avoided.
Mismanagement and Money
The blame for the incident has been laid at the feet of Pacific Gas and Electric, or PG&E, who acquired the existing Caribou-Palermo transmission line when it purchased Great Western Power Company back in 1930. The line was originally built in 1921, making the transmission line 97 years old at the time of the disaster. Despite owning the line for almost a full century, much of the original hardware was not replaced in the entire period of PG&Es ownership. Virtually no records were created or kept, and hardware from the early 20th century was still in service on the line in 2018.
Back in 2018, Microsoft began Project Natick, deploying a custom-designed data center to the sea floor off the coast of Scotland. Aiming to determine whether the underwater environment would bring benefits to energy efficiency, reliability, and performance, the project was spawned during ThinkWeek in 2014, an event designed to share and explore unconventional ideas.
This week, Microsoft reported that the project had been a success. The Northern Isles data center was recently lifted from the ocean floor in a day-long operation, and teams swooped in to analyse the hardware, and the results coming out of the project are surprisingly impressive.
Since the widespread manufacture of plastics began in earnest in the early 1950s, plastic pollution in the environment has become a major global problem. Nowhere is this more evident than the Great Pacific Garbage Patch. A large ocean gyre that has become a swirling vortex full of slowly decaying plastic trash, it has become a primary target for ocean cleanup campaigns in recent years.
However, plastic just doesn’t magically appear in the middle of the ocean by magic. The vast majority of plastic in the ocean first passes through river systems around the globe. Thanks to new research, efforts are now beginning to turn to tackling the issue of plastic pollution before it gets out to the broader ocean, where it can be even harder to clean up. Continue reading “Targeting Rivers To Keep Plastic Pollution Out Of The Ocean”→
Netflix has recently announced that they now stream optimized shot-based encoding content for 4K. When I read that news title I though to myself: “Well, that’s great! Sounds good but… what exactly does that mean? And what’s shot-based encoding anyway?”
Later this month, people who use GitHub may find themselves suddenly getting an error message while trying to authenticate against the GitHub API or perform actions on a GitHub repository with a username and password. The reason for this is the removal of this authentication option by GitHub, with a few ‘brown-out’ periods involving the rejection of passwords to give people warning of this fact.
This change was originally announced by GitHub in November of 2019, had a deprecation timeline assigned in February of 2020 and another blog update in July repeating the information. As noted there, only GitHub Enterprise Server remains unaffected for now. For everyone else, as of November 13th, 2020, in order to use GitHub services, the use of an OAuth token, personal token or SSH key is required.
While this is likely to affect a fair number of people who are using GitHub’s REST API and repositories, perhaps the more interesting question here is whether this is merely the beginning of a larger transformation away from username and password logins in services.
While early prototypes for SpaceX’s Starship have been exploding fairly regularly at the company’s Texas test facility, the overall program has been moving forward at a terrific pace. The towering spacecraft, which CEO Elon Musk believes will be the key to building a sustainable human colony on Mars, has gone from CGI rendering to flight hardware in just a few short years. That’s fast even by conventional rocket terms, but then, there’s little about Starship that anyone would dare call conventional.
An early Starship prototype being assembled.
Nearly every component of the deep space vehicle is either a technological leap forward or a deviation from the norm. Its revolutionary full-flow staged combustion engines, the first of their kind to ever fly, are so complex that the rest of the aerospace industry gave up trying to build them decades ago. To support rapid reusability, Starship’s sleek fuselage abandons finicky carbon fiber for much hardier (and heavier) stainless steel; a material that hasn’t been used to build a rocket since the dawn of the Space Age.
Then there’s the sheer size of it: when Starship is mounted atop its matching Super Heavy booster, it will be taller and heavier than both the iconic Saturn V and NASA’s upcoming Space Launch System. At liftoff the booster’s 31 Raptor engines will produce an incredible 16,000,000 pounds of thrust, unleashing a fearsome pressure wave on the ground that would literally be fatal for anyone who got too close.
Which leads to an interesting question: where could you safely launch (and land) such a massive rocket? Even under ideal circumstances you would need to keep people several kilometers away from the pad, but what if the worst should happen? It’s one thing if a single-engine prototype goes up in flames, but should a fully fueled Starship stack explode on the pad, the resulting fireball would have the equivalent energy of several kilotons of TNT.
Thanks to the stream of consciousness that Elon often unloads on Twitter, we might have our answer. While responding to a comment about past efforts to launch orbital rockets from the ocean, he casually mentioned that Starship would likely operate from floating spaceports once it started flying regularly:
While history cautions us against looking too deeply into Elon’s social media comments, the potential advantages to launching Starship from the ocean are a bit too much to dismiss out of hand. Especially since it’s a proven technology: the Zenit rocket he references made more than 30 successful orbital launches from its unique floating pad.
Regular expressions — the things you feed to programs like grep — are a bit like riding a bike. It seems impossible until you learn to do it, and then it’s easy. Part of their bad reputation is because they use a very concise and abbreviated syntax that alarms people. To help people who don’t use regular expressions every day, I created a tool that lets you write them in something a little closer to plain English. Actually, I’ve written several versions of this over the years, but this incarnation that targets grep is the latest. Unlike some previous versions, this time I did it all using Bash.
Those who don’t know regular expressions might freak out when they see something like:
[0-9]{5}(-[0-9]{4})?
How long does it take to figure out what that does? What if you could write that in a more literate way? For example:
Not as fast to type, sure. But you can probably deduce what it does: it reads US Zipcodes.
I’ve found that some of the most popular tools I’ve created over the years are ones that I don’t need myself. I’m sure you’ve had that experience, too. You know how to operate a computer, but you create a menu system for people who don’t and they love it. That’s how it is with this tool. You might not need it, but there’s a good chance you know someone who does. Along the way, the code uses some interesting features of Bash, so even if you don’t want to be verbose with your regular expressions, you might pick up a trick or two.
