Forwarded from 知乎暴论
顶刊《 #柳叶刀 》发表 #中成药 大规模随机 #双盲试验 结果
高清不分割完整版：https://www.tg-me.com/mightyflame/26288?comment=56905
相关阅读：为什么人们宁可相信传入中国不到两百年的 #现代医学 ，却不肯相信已经在中国 #传承 几千年的 #中医 ？ https://www.tg-me.com/mightyflame/12272
#中药 里面都是掺 #西药 卖 https://www.tg-me.com/mightyflame/21714
https://www.tg-me.com/mightyflame/25692
科学巨匠 #钱学森 说， #中医 是国之瑰宝，是顶级 #生命科学 。 #中医黑 们怎么看？ https://www.tg-me.com/mightyflame/24051
现代中医中药太牛逼了，至少没毒 😭
高清不分割完整版：https://www.tg-me.com/mightyflame/26288?comment=56905
相关阅读：为什么人们宁可相信传入中国不到两百年的 #现代医学 ，却不肯相信已经在中国 #传承 几千年的 #中医 ？ https://www.tg-me.com/mightyflame/12272
#中药 里面都是掺 #西药 卖 https://www.tg-me.com/mightyflame/21714
https://www.tg-me.com/mightyflame/25692
科学巨匠 #钱学森 说， #中医 是国之瑰宝，是顶级 #生命科学 。 #中医黑 们怎么看？ https://www.tg-me.com/mightyflame/24051
现代中医中药太牛逼了，至少没毒 😭
可不可以称之为乱加启发式算法的后果🌚实在是难以理解给每个API都加上Best-Fit自动转换的动机，我甚至不能理解为啥要把所有字符串都当作文字对待。
_(:_」∠)_
https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/
_(:_」∠)_
https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/
Orange Tsai
WorstFit: Unveiling Hidden Transformers in Windows ANSI!
📌 This is a cross-post from DEVCORE. The research was first published at Black Hat Europe 2024. Personally, I would like to thank splitline, the co-author of this research & article, whose help
Asahi Linux lead developer Hector Martin resigns from Linux kernel
读了邮件，这个事情确实挺复杂的。
事情的起因是Abdiel想要提交一个Rust模块与dma有关，属于Christoph管理的dma子系统。这个模块抽象了一个dma内部功能，这个功能可能会有更动。
这个补丁更新了7个版本，在第8个版本。
Christoph不希望在dma子系统中接受Rust代码。他不想接受多语言的代码基，认为这会影响维护，降低可读性和可搜索性（这个模块是放在rust文件夹下的）。
Danilo提出Rust代码由他们自己维护，Christoph可以任意处理C API，哪怕不兼容了也由他们维护。
Christoph不接受。
Robin认为这个模块只是使用dma提供的API。如果出现问题也不会影响其它人，而且出问题了rust的人也会很乐意处理，这样的话应该没问题。
Danilo也回复Robin说他不担心，这就是内核开发过程中正常互动而已，而且内核团队对此也习以为常。
Sima回复了Danilo的这条消息，认为既然已经知道了会有API的变化，应该为此做好准备。Rust的接口应该非常干净，以将未来可能的重构限制在中间层里。
Christoph继续回复说他不愿意接受这个补丁，并且取消了这个会话的订阅。他也不接受Rust部分单独维护者的提案，认为多语言交叉的代码基只是用来逃离flameware brigade的“癌”。
Danilo认为维护者不应该因为个人喜好就阻止其它模块使用公开的内核API，呼叫了Greg和Linus进场。
Jason指出Linus之前并不允许rust构建失败，并且还因此推迟了一个PR，而这个推迟的问题由rust的Kbuild引起。这让维护者必须维护Rust代码。
Greg反驳说这只是一个很小的工具问题，只是因为休假才没来得及修。（针对目前讨论的这个补丁）API的改变可以破坏staging阶段的代码，维护者不需要修，只要rust的人修就行。
Jason问那如果rust构建不通过Linus会不会推迟合并，Greg说他没法代替Linus回答。
Jason做了测试，发现哪怕不启用Rust，修改PCI的C API都会导致相应Rust部分构建失败。
这时Christoph发表了更详细的对于他动机的回应。认为增加一个Rust部分维护者并不会帮上他什么忙，他抱怨任何一点其它语言都会极大地影响内核作为一个整体的易维护。内核能生存下来就是因为内核内部没有知识边界，添加另一个语言破坏了这个情况，他会尽一切努力阻止它。他并不是恨Rust，而是他不想让他维护的大型C代码基靠近它。
Hector发表意见说：如果Linus没有发表什么意见，rust部分的人应该自行合并这个补丁。如果Linus或者Christoph不合并这个补丁，那么Rust 4 Linux项目就跟死了差不多。
他认为rust部分的人不应该浪费时间在这个会话上，决定权都在Linus手上。他们阻止你只是因为他们知道他们会输给内存安全语言。
他认为Christoph的“癌症”评论违反了Code of Conduct，但反正什么都不会发生。
Abdiel回复Christoph表示：我知道了你的想法，希望我们能找到共识。问Christoph有没有什么建议让Rust驱动不用每个都复制一遍这个模块，或者rust部分的人有什么能帮上忙的。
Christoph回应感谢理解，但是他不想帮忙扩散多语言交叉的代码基。他支持在新代码中使用Rust，但完全不想在Linux中用它。
Paolo和Hector争论。Paolo虽然支持合并这个补丁，但是他认为Hector这样说不会有帮助，Christoph的“癌症”说法好歹还算是技术讨论。Hector辩称他在鼓励人们不要再表演好人，因为表演好人对一些人完全没用。他认为Christoph完全在谋杀Rust 4 Linux项目，技术讨论不会有结果，唯一的解决方法是绕过Christoph。
Sima反驳Hector，举例一个Hector的嘟文（后来被删除了），认为现在的情况都是Hector造成的。Dave表示他支持Sima，r4l团队和drm团队正在正常处理这个补丁的问题，类似的行为没有帮助。原话：Being toxic on the right side of an argument is still toxic。
Linus回应Hector：也许你该接受事实，你才是那个问题。你觉得你知道更好的方法，但是现在的流程能用。它确实有问题，但问题就是生活的真实，不存在完美。
他认为Hector的行为反而让他不想接触Hector的方法。如果内核开发模式有问题，社交媒体并不是解法，就跟政治一样。
Danilo回应Hector：最重要的是保持在好的技术争论中，不要被周围的细节分散注意力。目标不是烧掉桥就能达到的。虽然很可惜这样需要时间和精力，但是没有捷径。
Hector回应Danilo，认为这不是技术问题，而是社区问题，并且根本没有什么投入去改变现状。
Hector对Sima的指控发表回应：
1）针对Sima新发表的嘟文，认为Sima竟然会认为这样的流程“流畅”和“没有夸张的drama”，还是在一个r4l的维护者因为数次敌意无奈离开之后。
2）他认为高等级维护者从公司支薪这一事实让内核离FOSS社区项目渐渐远去了，
Greg提醒Hector，2003年左右就有80%的贡献是公司资助的了。https://lore.kernel.org/rust-for-linux/2025020738-observant-rocklike-75cc@gregkh/
Sima回应Hector：
1）他在两年前就已经被烦到了。他还是继续聊天一段时间，但是Hector没有任何改变。你告诉别人错了并不会改变任何人。
2）从他收到的私下反馈来看，Hector行为造成的寒蝉效应比他预想的还严重。
3）他不想批评别人赚钱的方式。但是Hector有可能是想制造关注从而转化成支持asahi项目的捐赠。但是有人得给Hector收拾残局，反正这个人不是Hector。这就意味着他和其他人的心理健康给Hector付账单，他不会尊重这种做法。
Hector回应称这样并不会给他带来更多的捐款，会话就此终止吧。
Konstantin发表声明：之前有一群人（正确地）指出邮件列表已经是20年前的东西，软件开发已经逐渐转向依赖forges（注：大概就是专门管理项目开发的软件，比如GitHub）；另一群人（也正确地）指出我们不该依赖于一个仁慈实体，这会给它太多的政治、经济上的影响力，最少也是个单点故障。他希望能这两群人能够争辩着共存。
他非常警惕仁慈的实体，因为我们最近看到非常多公司因为政治原因就“重排优先级”。
从他的角度，他希望Linux内核开发能够避免绑定在单个forge上。因为这很难避免被“仁慈实体”控制。
他们原先是把 lore.kernel.org 作为像一个全局信息总线一样，让邮件被索引并且可被搜索。但是今时不同往日，他们已经桥接了了bugliza，并且很快就会桥接forges。
他回应Hector称他非常高兴Hector觉得b4有用。
（人称均无性别意味）
读了邮件，这个事情确实挺复杂的。
事情的起因是Abdiel想要提交一个Rust模块与dma有关，属于Christoph管理的dma子系统。这个模块抽象了一个dma内部功能，这个功能可能会有更动。
这个补丁更新了7个版本，在第8个版本。
Christoph不希望在dma子系统中接受Rust代码。他不想接受多语言的代码基，认为这会影响维护，降低可读性和可搜索性（这个模块是放在rust文件夹下的）。
Danilo提出Rust代码由他们自己维护，Christoph可以任意处理C API，哪怕不兼容了也由他们维护。
Christoph不接受。
Robin认为这个模块只是使用dma提供的API。如果出现问题也不会影响其它人，而且出问题了rust的人也会很乐意处理，这样的话应该没问题。
Danilo也回复Robin说他不担心，这就是内核开发过程中正常互动而已，而且内核团队对此也习以为常。
Sima回复了Danilo的这条消息，认为既然已经知道了会有API的变化，应该为此做好准备。Rust的接口应该非常干净，以将未来可能的重构限制在中间层里。
Christoph继续回复说他不愿意接受这个补丁，并且取消了这个会话的订阅。他也不接受Rust部分单独维护者的提案，认为多语言交叉的代码基只是用来逃离flameware brigade的“癌”。
Danilo认为维护者不应该因为个人喜好就阻止其它模块使用公开的内核API，呼叫了Greg和Linus进场。
Jason指出Linus之前并不允许rust构建失败，并且还因此推迟了一个PR，而这个推迟的问题由rust的Kbuild引起。这让维护者必须维护Rust代码。
Greg反驳说这只是一个很小的工具问题，只是因为休假才没来得及修。（针对目前讨论的这个补丁）API的改变可以破坏staging阶段的代码，维护者不需要修，只要rust的人修就行。
Jason问那如果rust构建不通过Linus会不会推迟合并，Greg说他没法代替Linus回答。
Jason做了测试，发现哪怕不启用Rust，修改PCI的C API都会导致相应Rust部分构建失败。
这时Christoph发表了更详细的对于他动机的回应。认为增加一个Rust部分维护者并不会帮上他什么忙，他抱怨任何一点其它语言都会极大地影响内核作为一个整体的易维护。内核能生存下来就是因为内核内部没有知识边界，添加另一个语言破坏了这个情况，他会尽一切努力阻止它。他并不是恨Rust，而是他不想让他维护的大型C代码基靠近它。
Hector发表意见说：如果Linus没有发表什么意见，rust部分的人应该自行合并这个补丁。如果Linus或者Christoph不合并这个补丁，那么Rust 4 Linux项目就跟死了差不多。
他认为rust部分的人不应该浪费时间在这个会话上，决定权都在Linus手上。他们阻止你只是因为他们知道他们会输给内存安全语言。
他认为Christoph的“癌症”评论违反了Code of Conduct，但反正什么都不会发生。
Abdiel回复Christoph表示：我知道了你的想法，希望我们能找到共识。问Christoph有没有什么建议让Rust驱动不用每个都复制一遍这个模块，或者rust部分的人有什么能帮上忙的。
Christoph回应感谢理解，但是他不想帮忙扩散多语言交叉的代码基。他支持在新代码中使用Rust，但完全不想在Linux中用它。
Paolo和Hector争论。Paolo虽然支持合并这个补丁，但是他认为Hector这样说不会有帮助，Christoph的“癌症”说法好歹还算是技术讨论。Hector辩称他在鼓励人们不要再表演好人，因为表演好人对一些人完全没用。他认为Christoph完全在谋杀Rust 4 Linux项目，技术讨论不会有结果，唯一的解决方法是绕过Christoph。
Sima反驳Hector，举例一个Hector的嘟文（后来被删除了），认为现在的情况都是Hector造成的。Dave表示他支持Sima，r4l团队和drm团队正在正常处理这个补丁的问题，类似的行为没有帮助。原话：Being toxic on the right side of an argument is still toxic。
Linus回应Hector：也许你该接受事实，你才是那个问题。你觉得你知道更好的方法，但是现在的流程能用。它确实有问题，但问题就是生活的真实，不存在完美。
他认为Hector的行为反而让他不想接触Hector的方法。如果内核开发模式有问题，社交媒体并不是解法，就跟政治一样。
Danilo回应Hector：最重要的是保持在好的技术争论中，不要被周围的细节分散注意力。目标不是烧掉桥就能达到的。虽然很可惜这样需要时间和精力，但是没有捷径。
Hector回应Danilo，认为这不是技术问题，而是社区问题，并且根本没有什么投入去改变现状。
Hector对Sima的指控发表回应：
1）针对Sima新发表的嘟文，认为Sima竟然会认为这样的流程“流畅”和“没有夸张的drama”，还是在一个r4l的维护者因为数次敌意无奈离开之后。
2）他认为高等级维护者从公司支薪这一事实让内核离FOSS社区项目渐渐远去了，
Greg提醒Hector，2003年左右就有80%的贡献是公司资助的了。https://lore.kernel.org/rust-for-linux/2025020738-observant-rocklike-75cc@gregkh/
Sima回应Hector：
1）他在两年前就已经被烦到了。他还是继续聊天一段时间，但是Hector没有任何改变。你告诉别人错了并不会改变任何人。
2）从他收到的私下反馈来看，Hector行为造成的寒蝉效应比他预想的还严重。
3）他不想批评别人赚钱的方式。但是Hector有可能是想制造关注从而转化成支持asahi项目的捐赠。但是有人得给Hector收拾残局，反正这个人不是Hector。这就意味着他和其他人的心理健康给Hector付账单，他不会尊重这种做法。
Hector回应称这样并不会给他带来更多的捐款，会话就此终止吧。
Konstantin发表声明：之前有一群人（正确地）指出邮件列表已经是20年前的东西，软件开发已经逐渐转向依赖forges（注：大概就是专门管理项目开发的软件，比如GitHub）；另一群人（也正确地）指出我们不该依赖于一个仁慈实体，这会给它太多的政治、经济上的影响力，最少也是个单点故障。他希望能这两群人能够争辩着共存。
他非常警惕仁慈的实体，因为我们最近看到非常多公司因为政治原因就“重排优先级”。
从他的角度，他希望Linux内核开发能够避免绑定在单个forge上。因为这很难避免被“仁慈实体”控制。
他们原先是把 lore.kernel.org 作为像一个全局信息总线一样，让邮件被索引并且可被搜索。但是今时不同往日，他们已经桥接了了bugliza，并且很快就会桥接forges。
他回应Hector称他非常高兴Hector觉得b4有用。
（人称均无性别意味）