关于Starship-Superheavy首飞的一些想法
【What happened】
基于SpaceX直播的时间线以及一些社区的分析：
T-3s 点火
T+6s 第一个肉眼可见的碎片飞出来
T+7s 3块巨大的碎片飞出来
T+16s 第一次出现图像展示，3个raptor熄火
T+31s 液压系统爆炸
T+40s 第四个引擎熄火
T+57s 液氧开始泄露
T+62s 第五个引擎熄火
T+62s ish 液氧泄露停止
T+100s 丢了第六个引擎
T+112s 第六个引擎重新点燃
T+134s 失去姿态控制
T+168s booster engine cut off call-out，但实际还在点火
T+239s FTS激活

【What I believe happened】
Superheavy 33枚引擎90%推力点火，产生的巨大冲击力摧毁了Orbital Launch Mount底部的水泥，产生的碎片损坏了Superheavy的箭体和引擎，导致了多个引擎失效+液压系统失效。Starship+Superheavy的组合体由于控制面安装在重心前方，本身气动不稳定。在失去多个引擎推力不平衡+推力不足飞行轨迹过低+失去液压模块引擎矢量受影响+为了回到正常轨迹的大攻角飞行姿态下，在134秒失去姿态控制能力，导致Loss of Vehicle

【我的看法】
不管马先生再怎么sugarcoating，这就是一次失败。这个失败本身不可耻，If you are don’t blow things up，you are not innovating enough.
但是！但是！但是！
这是一个非常糟糕的事件。勇敢和冒进是有区别的。大胆创新和盲目蛮干是有区别的。SpaceX团队目前在我看来，倾向于后者。
早在2020年，不采用导流槽的设计就已经是一个concern了。2022年BN7进行静态点火的时候，33枚引擎，50%推力就龙卷风摧毁OLM了。整个团队在明知道这个设计有问题，新的保护装备还有3个月才能就绪的情况下，仍然选择了go for launch。结果是，炸掉了目前唯一可用的OLM，严重损坏了Stage0, 并且导致了发射失败。
实在是太过于，莽撞了。整个团队都觉得，oh it’s normal if not exciting to blow it up。带着这样的一种态度，太过于儿戏了。
包括这个FTS。火箭在失去姿态控制以后硬生生还是飞了100多秒才被终止。我不管这是因为发送命令晚了，还是因为FTS没有足够快起效，这都是绝对不应该出现的事情。
带着这样的一种态度进行研发，我觉得是非常糟糕的一个状态。SpaceX团队应当重视这个问题。我不反对采用敏捷开发的思路来研发火箭，我也认为，炸个火箭是完全可以接受的。但至少，应当秉承着严肃、严谨的态度来研发目前世界上最大的运载火箭。
People’s lives are at risk

朋友对星舰首飞的评价。咱不完全同意，但是值得参考（？

与此同时，谁急了我不说（）

看热闹不嫌事大的星舰重新涂装
https://m.weibo.cn/detail/4894153320170765

Commercial lunar lander presumed lost after moon landing attempt (Score: 150+ in 7 hours)

Link: https://readhacker.news/s/5Dj8E
Comments: https://readhacker.news/c/5Dj8E

差两米没油了

CI/CD 是什么.jpg

到现在群友还没搞明白这个结果是怎么算出来的

罗马数字。C（100）I（1）/C（100）D（500）=101/400=0.2525

是咱的错觉，还是现在 90% 的厂商离开战斗元素就不会做游戏了

起名鬼才 来源

md 编译个东西碰到了一个十年没修的 clang bug

TL;DR: 在编译含有函数指针的结构体的时候，clang 有时会把函数指针变成指向空结构体的指针（{}*）

如：

struct Foo {
  int (*foo)(int*);
}

偶尔会被编译成

%struct.Foo = { {}* }

而不是

%struct.Foo = { int* (int*)* }

https://stackoverflow.com/questions/18730620/why-a-function-pointer-field-in-a-llvm-ir-struct-is-replaced-by

https://bugs.llvm.org/show_bug.cgi?id=14920

https://github.com/llvm/llvm-project/issues/15292