On your parenthetical point, I also agree: some really weird camera selections, and frustrating dropouts, during the crucial moments of the launch.
Nevertheless, a real triumph, and I particularly enjoyed the "full send" remark from (I think) the commander. I also really enjoy the fact that the livestream is relatively light on commentary and that most of what you hear is from mission control and the crew.
I was cussing at the director of that video stream during that. It was a totally useless shot as well that they lingered on that already had me bothered, and then to cut back to the SRBs fully separated had me in full contempt. Nothing to see here and everything to miss. It's like music videos showing the singer doing nothing while the guitarist is shredding a solo. Like WTF. You have one job, and you totally botched the hell out of it. You get what you pay for I guess. Lowest bidding contractor???
It was probably deemed a relatively high-risk moment which they did not want to broadcast in case of failure like it was when the Challenger mission exploded.
NASA had another feed that was just the view of the launch from Kennedy Space Center, no commentary. It was a few seconds ahead of the main broadcast, so it seems they already had a delay built in for the masses.
I certainly missed that one. Is it available somewhere recorded? If it is, can you please send a link to it? I'm sorry if I'm asking something stupid, it's just that I can't find anything like that and I also want to see this badly.
Still an odd choice. It is what it is. It’s a fairly risky mission and they chose to go ahead with that. Yet they avert their eyes, like a child watching a scary scene in a movie. Like it’s somehow ok to actually risk lives of four people, but not ok to televise that.
> And what does the customer do if the vendor has discontinued it? Or charges for an upgrade? Or has gone out of business?
Those can all be filed under Not My Problem (as in, Microsoft's problem,) and safely ignored. On the other hand, when Highly Influential So-And-So upgrades from 3.1 to 95 or whatever, and Very Population Application v4.9.6 starts falling over, Microsoft gets the black eye whether they deserve it or not. The whole equation changes.
I mean, you can't blame them. It's not like there was any recent precedent for a large thundering superpower to start a conflict (not a "war", of course)--under the assumption that a quick decapitation strike would end things in a few days--with an underestimated asymmetric adversary (one supported by a larger enemy) that responds with cheap drones and the like, resulting in an increasing quagmire, not to mention one resulting in the loss of valuable and irreplaceable airborne command-and-control aircraft during the conflict
What would happen "normally" (i.e. the normalization of deviance) was that the rotation (from the SRB joints bowing--essentially "ballooning") would create a gap, and the O-rings would get blown into that gap and ultimately seal in there
With Challenger, it was too cold, so the O-ring rubber was not malleable enough to seal into that space (like the O-ring towards the right of the diagram), so the hot gases were allowed to blow by and erode the O-ring. If they had sealed in (like the one on the left) it would have just taken the pressure but not worn away
Tangentially related, but while we're talking about eerily prescient writings, I nominate "The MADCOM [Machine-Driven Communication] Future: How Artificial Intelligence Will Enhance Computational Propaganda, Reprogram Human Culture, And Threaten Democracy… And What Can Be Done About It (2017)"
"Heterogeneous democracies like the United
States devolve into perpetual conflict as
adversaries use MADCOMs to manipulate the
population, by exacerbating cultural differences
and undermining narratives that unify the
country. The social consensus disintegrates,
and political opponents are labeled traitors and
enemies...
"The US public believes that MADCOM
activities are just a more sophisticated
form of advertising, and reflexively relies
on appeals to free speech. In fact, there are
active manipulation campaigns pushing these
narratives to convince the public it isn’t being
manipulated at all. Any time people interact with
an electronic device—whether a smartphone,
augmented-reality device, or social media—their
data is captured, their behavior is tested and
recorded, and algorithms adapt to make devices
more addictive, advertisements more persuasive,
and propaganda more manipulative...
"Some individuals
flee to private social spaces online, but this
reinforces their filter bubbles, exacerbating
political polarization. A small number of people
flee online social spaces entirely, creating a
minor resurgence in offline, mass-market media.
These information-savvy individuals are the
least likely to be susceptible to disinformation
in the first place, so their absence simply
removes rational voices from the conversation.
The affluent pay for the luxury of privacy, as
brands emerge specifically targeting those who
wish to protect their data and their cognition...
"Agreed-upon facts become a relic of the past.
No one knows what is true anymore, because
expertise has been subsumed to the tyranny
of MADCOM-manipulated public opinion. AI
video- and speech-manipulation tools invent and
revise reality on the fly. The only truth is what
you can convince people to believe. The new
definition of a fact is “information that aligns
with preconceived opinions,” and any contrary
evidence is discarded as likely disinformation.
The story is all that matters. The three-hundred-
year-old Age of Enlightenment, based on reason
and a quest for truth, ends."
It boggles my mind that instead of this being a UI projection, git instead ingrains a process where developers habitually destroy their history (and bisection options, and merge conflict resolution), therein loading an additional footgun that goes off every now and again when it turns out a now-squashed branch was the basis of (or merged into) some other branch
It’s important to note that not all history is worth keeping, and keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.
I very much prefer keeping histories by default (both my personal workflows and the tools I build default to that) but squash is a valuable tool.
> keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.
How so? When I bisect I want to get down to a small diff, landing on a stretch of several commits (because some didn't build) is still better than landing on a big squashed commit that includes all those changes and more. The absolute worst case when you keep the original history is the same as the default case when you squash.
> Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change.
Do you restrict yourself to 1 non-broken commit per PR? I don't, and nor does anyone I've worked with. If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win. (If you didn't care about that sort of thing you wouldn't be bisecting at all).
> No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
What are you "evaluating"? If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too. Better to have the extra details and not need them than need them and not have them.
> Do you restrict yourself to 1 non-broken commit per PR?
No. To the extent that I can however I do restrict myself to only non-broken commits.
> If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win
It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.
And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
> What are you "evaluating"?
Whether the commit is the one that caused the issue I’m bisecting for.
> If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too.
Neither of these is true. git bisect (run) lands me on a commit, it’s broken, now I need to look whether the commit is broken in a way that is relevant to what I’m seeking.
> Better to have the extra details and not need them than need them and not have them.
Garbage is “extra details” only in the hoarder sense.
> It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.
Skipping a commit that doesn't build is trivial (especially if you're automating your bisects).
> And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that is massive overkill, and the costs outweigh the benefits.
I would assume most people who would enable an "auto squash" option also aren't carefully creating and curating commits. Bisect is useless if half your commits are broken. People regularly make commits that don't even build, much less pass QA and deliver a valid version of the software. These are works in progress, broken versions and should be deleted.
If you actually do like to deliver the correct number of commits then it's frustrating to work with people who don't care. In that case I would suggest making the squash optional but you could also try selling your team on doing smaller commits. In my experience you either "get it" or you don't, though. I've never successfully got someone to understand small commits.
> I would assume most people who would enable an "auto squash" option also aren't carefully creating and curating commits.
Or don't have a choice. Our department-wide rules were almost to require that for all repos, I had to push hard just to make it "strongly suggested" instead.
Yes, a good Git log viewer that would auto-squash branches down to a summary, and allow "expanding" them, would be useful. But the way branching and merging creates confusing train-track graphs is IMHO one of the reasons why many teams end up using the squash-and-merge workflow. There's definitely room for improvement there...
Git doesn't do that. People needlessly destroying history do that.
Git will happily let you merge branches and preserve the history there. GP seems to like that history being in PRs only on github instead. I don't get why, that just seems worse to me.
That is an issue of ignorance, not laziness. It’s not obvious at all to an average developer that only uses `add/commit/merge/fetch/push/pull/rebase/restore/reset` that they can manipulate their change history.
> Why carbon dioxide? Because everyone who exhales COVID (or flu, or RSV) aerosols also exhales carbon dioxide, and good ventilation removes both disease aerosols and CO2. Under many conditions, the concentration of CO2 particles in a space can give us an idea of how much risk there is of catching or passing on a respiratory disease.
> Unfortunately, the relationship between the numbers on a carbon dioxide monitor and the disease risk is complicated, so there are some things to know if you want to do your own monitoring.
That's what's different about this one. "Enter the Ryzen 9 9950X3D2 Dual Edition, a mouthful of a chip that includes 64MB of 3D V-Cache on both processor dies, without the hybrid arrangement that has defined the other chips up until now."
(That being said, I can't believe they cut to people on the ground during SRB separation!)
edit: here's better footage from Everyday Astronaut: https://www.youtube.com/watch?v=QOsSRRBMNoc&t=24512s
reply