Regarding leaks, yes, there were rumors of battery pack replacements due to corrections on welds and a separate production issue with ground terminal bolts.[1]
These issues could be due to the different composition of the 3 compared to the S and X - more steel, less aluminum - or with them trying to build a denser automated production line, or just general gremlins setting up new production.
We have the iPhone because Apple was so ambitious. Imagine if they had just partnered with existing phone manufacturers rather than trying to build a magic touch slate.
Wait, we do know what would have happened - the Motorola ROKR, which everyone should be forgiven for forgetting.
If they're faced with a low probability landing scenario, such as the fastest re-entry velocity to date, and they need to "test" their control algorithms, which first stage would they choose? A near end-of-life used booster or a late block booster from which they would hope to get another several good launches? - assuming all others characteristics support the current launch parameters.
They're amazingly deliberate in how they mingle bleeding edge R&D and commercial activity. Something that fascinates me. And rockets.
Kapor Capital, investors in Uber, apparently also invest in "People Ops" startups. They're actively trying to feed a problem child into their own opportunities. Smart.
Give me a break. When a successful tech executive says, "It has always been a priority for me to give back to people who are less fortunate," the Gates Foundation or the US Digital Service come to mind. Getting another highly paid job is not at all in the same class.
I recommend watching the Hosted Webcast on one device and the Technical Webcast on another. Either mute the Technical Webcast or have it on lower volume. They're both easily found on YouTube under SpaceX.
I did this for the previous launch, Iridium-1, and was treated to unbroken views live from the first stage on the technical stream, while the hosts narrated and switched views more frequently on their stream.
I believe the comparison was not with text-based debuggers, but with the more mainstream Node.js debugging options that also provide Blink or Chrome DevTools UIs:
1. Node Inspector (https://github.com/node-inspector/node-inspector), the most prevalent Node.js debugging tool, at least until Node v6.3.0. And which also happens to be mentioned by Jam3/devtool in the Comparisons section.
Are there useful heuristics on where GSL is most applicable? Where it is relevant and powerful and not too meta; just the right amount of abstraction to represent a problem and its solution.
For example, "GSL is likely a good choice at <abstract problem description>, such as <some very concrete examples>. And it may not be appropriate for <abstract problem description>, such as <other concrete examples>. Because of <some specific reasons>."
I looked through the GSL website and also Scalable C and wasn't able to find any descriptions that place limits on the applications of GSL. A description of what a complex something isn't, from an expert, is almost as important as what that thing is.
Your writing style in Scalable C is incredible and enlightening. I will be studying and referencing that book, even if I'm not directly coding C.
Do others here use Square Cash? I much prefer payments to friends going directly from my bank account to their bank account. For all the alternatives I am familiar with (Venmo, PayPal), payments to me land in some intermediary account.
I feel either this distinction isn't important to many or that Square Cash is just widely unknown.
These issues could be due to the different composition of the 3 compared to the S and X - more steel, less aluminum - or with them trying to build a denser automated production line, or just general gremlins setting up new production.
[1] https://electrek.co/2017/09/29/tesla-model-3-production-ramp...