They're being careful because they don't want to wreck their launch pad.
On the previous flight, they were going for the same ocean soft landing as this flight, but several engines on the booster failed to start during the landing burn (reportedly due to ice clogging propellant feed). Had this crash not happened they likely would have tried for a tower catch today.
They want to be sure the mitigation for this failure worked before they put the pad & tower at risk.
Improved fare gates for BART have increased revenue and dramatically reduced maintenance costs:
"Comparing the six month period before the 'next generation' fare gates debuted, to the six months that followed, Embarcadero station saw a significant reduction in the need for maintenance work — from 112 hours to two hours. "
...
"When you see how dramatically these maintenance requests fell, the numbers tell us that these fare gates are preventing unwanted behavior that impacts the station environment," BART spokesperson Alicia Trost told the Chronicle. "Those people are no longer entering BART."
Contractually dual-path, or actually dual-path? My understanding is that there's enough infrastructure horse-trading going on behind the scenes that it's very difficulty to be certain that two circuits between points A and B don't share the same infrastructure somewhere in between.
First big oops of this form that I remember:
"In December 1986, the ARPANET had 7 dedicated trunk lines between NY and Boston, except that they all went through the same conduit -- which was accidentally cut by a backhoe. "
I'm talking about data not able to leave the building, not even data getting lost on the way.
One example was a site that had fiber and coax, from different companies. They might have shared a pipe at some point along their length, hard to say. But both connections went down at the same time for digital reasons, not physical. The providers had simultaneous unrelated backend router problems and the site lost contact to both gateways.
This was with a nice SD-WAN system that routed everything dynamically across both pipes to address latency and errors, but if the packets get dropped at the first hop in both networks, there's not much you can do!
The saving grace in that case was the third redundant connection, a 4G cell modem, with a lot less bandwidth but able to keep the critical transactions going. These days I'd certainly want Starlink on the roof as well.
Yup. Seven different paths comes with seven different sets of equipment, and seven different rights-of-way that have to be negotiated, purchased, leased, whatever.
zfs-style scrub only reads allocated blocks and skips unallocated blocks; if the pool is mostly empty it can complete very quickly.
Layered storage systems with a RAID layer that makes N disks look like one big disk generally don't have visibility into which blocks are free and which are allocated so they must "scrub" all the disks on initialization and repair even if only 1% is used.
In addition to the (n^2)^2 sudokus, you can also make them with rectangular sub-blocks -- (n x m) ^ 2 sudokus -- such as a 6x6 grid with six (3x2) sub-blocks, or a 10x10 with 10 5x2 sub-blocks.
> That points to a glaring hole in the modern-day automated web PKI, not Tesla's dangling DNS record.
It's not. They control a long-term high-value asset (the domain tesla.com). They decided to delegate part of that asset to a large number of "random" people that they do not have a contract or agreement with.
Being able to issue certs for cloud IPs has nothing to do with this since it is not a long term asset, and if it is you probably don't delegate it to random people to control unless you do not value that asset.
This is why IP certificates are limited to a max lifetime of 6 days.
> IP address certificates allow server operators to authenticate TLS connections to IP addresses rather than domain names. Let’s Encrypt supports both IPv4 and IPv6. IP address certificates must be short-lived certificates, a decision we made because IP addresses are more transient than domain names, so validating more frequently is important.
And multithreaded code -- and anything that does asynchronous I/O, networking, etc. -- frequently exhibits nondeterministic behavior even without explicit calls to a random number generator.
> Every single thing they could do wrong at, they did.
There are just too many ways to screw up for that ever to be the case.
For instance, they could also have been lined up to land on something other than the runway they were cleared to land on -- see Air Canada Flight 759, https://en.wikipedia.org/wiki/Air_Canada_Flight_759, which came within 14 feet of colliding with an aircraft on the taxiway they mistook for the runway..
Nitter's author has suggested at least once that due to problems with Nim, a rewrite in Go is in the works:
"The long-term plan is to rewrite the source code in Go, as I'm no longer interested in using Nim. This isn't a small task, but building more features with the current state of things is painful. Before doing that I'll fix some feature parity issues, and work on some conveniences for instance operators. Stay tuned."
Interesting, well too bad. Personally I find Nim more useful and productive than ever with LLMs.
Nitter uses Jester which seems dead for sure, but doing static binaries is easy. Personally I just forked Mummy to continue as MummyNG since I prefer threaded servers so things like JSON parsing doesn’t cause latency issues.
Though that being written over a year ago it’s either not a high priority or harder than it seems. I’ll be curious to see which. LLMs make it easier than ever for others to contribute or to fix up deps.
Genuinely curious what is keeping you using Nim. Is it just sunk cost fallacy at this point?
LLMs actually make the case for Nim worse IMO. The language is more expressive than Go and more productive for human coders, but in the age of LLMs this doesn’t matter as much.
And yes, I can confirm that Jester is dead. Surprised Nitter is still using it.
Go has Google behind it. It's a much more established language with far more mature packages and a much bigger ecosystem. If you're using Nim then you're relying on few libraries/tools written by hobbyists who don't have time to ensure they work well, or even more likely you're having to write these yourself.
But the bigger problem is the culture of the Nim community and its leadership. I made a hard decision to stop spending my free time contributing to it a few years ago now and I'm glad I did.
More stable, commonly supported platform I presume. You don't want to be on a snowflake platform for a long running project, it only causes endless problems.
There is zero chance I would approach a kid on their own that isn't mine. Because there is a very non-zero chance that someone would accuse me of that. If it gets to charges, even if I do successfully defend myself, then my name is mud and it costs me a ton.
I'd call security too. Not my monkey, not my circus.
Yes. In my "other life" I work in fire and EMS, and in uniform regularly have parents stop us and point us out to their kids - "If you're ever hurt or in trouble, you can ALWAYS go to these people, they're safe.", or the look of absolute trust when someone thrusts their sick child at you, hoping for you to make it better. And that, somewhat unsurprisingly, sometimes include seeing that child in undress.
Take off my uniform.
My partner spent several years in childcare, both at centers and as a nanny. We're out in public and she sees a crying child? She goes to it, talks to it, hugs it perhaps, reassures.
Me? Not a chance. For better or worse, societal conditioning is that that is something I as a male /do/ /not/ /do/. Because it's nefarious that I'd even want to.
On the previous flight, they were going for the same ocean soft landing as this flight, but several engines on the booster failed to start during the landing burn (reportedly due to ice clogging propellant feed). Had this crash not happened they likely would have tried for a tower catch today.
They want to be sure the mitigation for this failure worked before they put the pad & tower at risk.
reply