clang deterministic build

https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html

这个文章很有学问。把概念分为四层：
Basic determinism
Incremental basic determinism
Local determinism
Universal determinism

对于多语言写就，且使用多语言而来的库的稍大点的软件，我个人认为没有tool能做到universal determinism。tool瞄准第四层也没多大意义。

但是检查前面几种，应该是很好的practice。

很不幸的是，我發現這種先明確定義再討論問題的做法，很多成天在簡體字文化教育下面長大的人，輕則感到不快，重則咬牙切齒地會和你急，雖然我並不能理解這種做法的動機。
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html: 这个文章很有学问。把概念分为四层：
: Basic determinism
: Incremental basic determinism
: Local determinism
: Universal determinism
: 对于多语言写就，且使用多语言而来的库的稍大点的软件，我个人认为没有tool能做到
: universal determinism。tool瞄准第四层也没多大意义。
: 但是检查前面几种，应该是很好的practice。

多數在錯誤教育裏出來的不理解formal reasoning的重要性。沒有基本的對严格性的理解。讨论稍微长点，就丧
失严
格性，有的连字符串match都不认了。完了还不会自己修复。写程序必定是一个样。
这种思维类型的，其实不适合搞技术。无法enjoy。那还有什么意思。人总不能一辈子
面目狰狞的
自己找罪受。

另外这是东土大能故意为之的。提高识字率在当时是第一要求。至于认识的是什么字，无人考
究。简化字是毛泽东亲自参与和审查决定的。
【 在 netghost(Up to Isomorphism) 的大作中提到: 】
<br>: 很不幸的是，我發現這種先明確定義再討論問題的做法，很多成天在簡體字文化
教育下
<br>: 面長大的人，輕則感到不快，重則咬牙切齒地會和你急，雖然我並不能理解這種
做法的
<br>: 動機。
<br>

AI里的automated reasoning是比machine learning厉害得多的技术，只是因为还没有
突破，没什么好推广的，所以只在圈子里转。

【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 多數在錯誤教育裏出來的不理解formal reasoning的重要性。沒有基本的對严格性的理
: 解。讨论稍微长点，就丧
: 失严
: 格性，有的连字符串match都不认了。完了还不会自己修复。写程序必定是一个样。
: 这种思维类型的，其实不适合搞技术。无法enjoy。那还有什么意思。人总不能一辈子
: 自己找罪受。
: 另外这是东土大能故意为之的。提高识字率在当时是第一要求。至于认识的是什么字，
: 无人考
: 究。简化字是毛泽东亲自参与和审查决定的。
:
: 很不幸的是，我發現這種先明確定義再討論問題的做法，很多成天在簡體
: ...................

多少年前Automate reasoning就实用了,只是不叫ai這個名字而已。大规模集成电路
的逻辑正确就是程序验证的。
最近东土不是嚷嚷着没有自己的芯片工具链么。其核心之一就是ai
为基础的各种自动推理和验证算法。
吴文俊写过不少数学机械化用于电路板什么的论文。我本科时候就看过。那就是AI。

【 在 iDemocracy(DEMO) 的大作中提到: 】
<br>: AI里的automated reasoning是比machine learning厉害得多的技术，只
是因为
还没有
<br>: 突破，没什么好推广的，所以只在圈子里转。
<br>

LOL，一帮连reproduce build都不做的人，突然一个个都成为build专家了。。。LOL。笑死人了。

不管对错。显然技术讨论和研究不能给你带来任何愉快。那又何必呢？

你就按你公司给的那个框填填完事了。没啥不好的。

【 在 skybluewei(weilan) 的大作中提到: 】

: LOL，一帮连reproduce build都不做的人，突然一个个都成为build专家了。。
。LOL。

: 笑死人了。

LOL，讨论技术没问题啊！我讲个公司要求reproduce build，并分享一下我的经历，一帮人上来把我臭骂一顿，“不可能啦”，“没用啦”，“没公司会干这事儿啦”，然后转头网上找篇文章，俨然一个个摇身一变都成了rebuild专家了！至于吗？这玩意儿又
不是啥高科技。LOL

【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 不管对错。显然技术讨论和研究不能给你带来任何愉快。那又何必呢？
: 你就按你公司给的那个框填填完事了。没啥不好的。
:
: LOL，一帮连reproduce build都不做的人，突然一个个都成为build专家了。。
: 。LOL。
:
: 笑死人了。
:

★ 发自iPhone App: ChinaWeb 1.1.5

(A)纯java project，远不是你说的修好mainifest这一条,加上备份这个那个这几条，
就一定可以把java的jar给reproduce 出来的。

这命题你认为是T or F?
我认为是T。

determinstic的byte/native code,还真就是高科技。

【 在 skybluewei (weilan) 的大作中提到: 】
: LOL，讨论技术没问题啊！我讲个公司要求reproduce build，并分享一下我的经历，一
: 帮人上来把我臭骂一顿，“不可能啦”，“没用啦”，“没公司会干这事儿啦”，然后
: 转头网上找篇文章，俨然一个个摇身一变都成了rebuild专家了！至于吗？这玩意儿又
: 不是啥高科技。LOL
: ★ 发自iPhone App: ChinaWeb 1.1.5

你rebuild过吗？LOL。又一个喷子。。。自己动手试一下。。。
【 在 chebyshev (......) 的大作中提到: 】
: (A)纯java project，远不是你说的修好mainifest这一条,加上备份这个那个这几条，
: 就一定可以把java的jar给reproduce 出来的。
: 这命题你认为是T or F?
: 我认为是T。
: determinstic的byte/native code,还真就是高科技。

你基本的逻辑有问题。这不是能rebuild出来例子就说明是对的。你得看compiler文档。

【 在 skybluewei(weilan) 的大作中提到: 】
<br>: 你rebuild过吗？LOL。又一个喷子。。。自己动手试一下。。。
<br>

搞cross compiling都几十年了
这个build又什么讲究法吗

输入和资源文件啥的先不说。太复杂了。只能分门别类几十项排除。

不看文档无法知道是否有dict,set 之类的东西被用来生成语法树。尤其是加优化flag
的时候。几个if else 互换不影响编译之正确性。但是产生的语法树不一定每次都一样。

这就跟print一个set每次结果不同是一个道理。所以deterministic build真
是高科技。尤其是多语言不同版本的库involved的时候。

我看这问题只能定义些conventional rule。靠经验。

【 在 walkrandom(walkrandom) 的大作中提到: 】
<br>: 搞cross compiling都几十年了
<br>: 这个build又什么讲究法吗
<br>

F

这东西没在软件大厂干过（不带任何贬义）可能真不了解。 比如说https://zlika.
github.io/reproducible-build-maven-plugin/
互联网公司可能也不太care, 企业软件这些应该是标配。

【 在 chebyshev (......) 的大作中提到: 】
: (A)纯java project，远不是你说的修好mainifest这一条,加上备份这个那个这几条，
: 就一定可以把java的jar给reproduce 出来的。
: 这命题你认为是T or F?
: 我认为是T。
: determinstic的byte/native code,还真就是高科技。

这种网上的tool不能乱用。不然说不定给你搞废了。
你不信算了。

能不能bit by bit rebuild必须是先说好哪些输入不能用。
你想想看。如果你的resource文件是hashmap产生的。
每次产生的resource都是不一样的。然后你把resource打包到jar。那就不一样了。

【 在 TonyHoare(TonyHoare) 的大作中提到: 】

: F

: 这东西没在软件大厂干过（不带任何贬义）可能真不了解。 比如说https://
zlika.

: github.io/reproducible-build-maven-plugin/

: 互联网公司可能也不太care, 企业软件这些应该是标配。

只是举个例子， 公司一般都有自己的pipeline. maven现在也自带了https://maven.
apache.org/guides/mini/guide-reproducible-builds.html
一般流程是build几次，如果不一样就说明用了不合规的东西，也就不能提交，打回重
写直到reproducible。
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 这种网上的tool不能乱用。不然说不定给你搞废了。
: 你不信算了。
: 能不能bit by bit rebuild必须是先说好哪些输入不能用。
: 你想想看。如果你的resource文件是hashmap产生的。
: 每次产生的resource都是不一样的。然后你把resource打包到jar。那就不一样了。
:
: F
:
: 这东西没在软件大厂干过（不带任何贬义）可能真不了解。 比如说https://
: zlika.
:
: github.io/reproducible-build-maven-plugin/
:
: 互联网公司可能也不太care, 企业软件这些应该是标配。
: ...................

追求jar bit for bit的reproduce純粹是某些大廠追求的一個形式而已，你如果不能同時控制jvm，你追求jar一模一樣的意義何在？除了能聲稱自己reproduce了之外？

【 在 TonyHoare (TonyHoare) 的大作中提到: 】
: F
: 这东西没在软件大厂干过（不带任何贬义）可能真不了解。 比如说https://zlika.
: github.io/reproducible-build-maven-plugin/
: 互联网公司可能也不太care, 企业软件这些应该是标配。

这点我理解。

我想我表达清楚了。

公司的流程P，公司软件之可能写法之集合为D。

D加P保证了产品之rebuild没问题。简言之，写法要合规才可以。不是maven 什么的
rebuild tool单方面的事。

但是你的P换了另一个domain 就可能出问题。之前的争论之原因在于有人把自己公司的流程，往cpp套用。

你java 比我熟，写个简单的压缩软件，obfuscate 什么的能让你公司的流程fail 应该是简单的事情。对吧？

【 在 TonyHoare(TonyHoare) 的大作中提到: 】
<br>: 只是举个例子， 公司一般都有自己的pipeline. maven现在也自带了https://
maven.
<br>: apache.org/guides/mini/guide-reproducible-builds.html
<br>: 一般流程是build几次，如果不一样就说明用了不合规的东西，也就不能
提交，
打回重
<br>: 写直到reproducible。
<br>

简言之。我认为：没有写法合规这条，是无法保证jar能reproduce的。不管你用什么
tool都一样。
其他语言也一样。都有deterministic 之类的flag, setup等等。但是仍然要写法合规
才可以。

【 在 TonyHoare(TonyHoare) 的大作中提到: 】
<br>: 只是举个例子， 公司一般都有自己的pipeline. maven现在也自带了https://
maven.
<br>: apache.org/guides/mini/guide-reproducible-builds.html
<br>: 一般流程是build几次，如果不一样就说明用了不合规的东西，也就不能
提交，
打回重
<br>: 写直到reproducible。
<br>

有些人是肉烂嘴不烂，脸都被抽肿了，还要硬拗。LOL
【 在 TonyHoare (TonyHoare) 的大作中提到: 】
: 只是举个例子， 公司一般都有自己的pipeline. maven现在也自带了https://maven.: apache.org/guides/mini/guide-reproducible-builds.html
: 一般流程是build几次，如果不一样就说明用了不合规的东西，也就不能提交，打回重
: 写直到reproducible。

没有写法合规这一条，光你说的那几个备份。改改配置清单。
你一定能reproduce jar么?

但是什么是合规，是语言相关的的。所以你公司的办法跟python，cpp，那都是不一样
的。
这是很复杂么？

这最后一次了。你不明白就算了。
【 在 skybluewei (weilan) 的大作中提到: 】
: 有些人是肉烂嘴不烂，脸都被抽肿了，还要硬拗。LOL

能不能看一下上面的link再说啊。。。能不能不要老转进啊？https://github.com/jvm-repo-rebuild/reproducible-central
maven build大部分是java的吧，list里打绿钩的不都是reproducible builds么？
Debian's Reproducible Builds project那个是不是c/cpp packages啊？https://wiki.debian.org/ReproducibleBuilds
绿色的不都是可以reproducible builds吗？

至于我们公司怎么做的，有关系吗？我一开始就说了，我们公司要求reproducible
build，怎么实现是技术员自己去搞，其中包括我说的哪些，仅此而已。而不是像你们
那这些喷子们，一会儿公司没要求啦，一会儿不需要啦，一会儿又不可能啦，巴拉巴拉巴拉。。。上面的link把你们脸都打肿了，还在那瞎逼逼。还最后一次，最后一次被打脸么？承认自己无知就那么难么？

【 在 chebyshev (......) 的大作中提到: 】
: 没有写法合规这一条，光你说的那几个备份。改改配置清单。
: 你一定能reproduce jar么?
: 但是什么是合规，是语言相关的的。所以你公司的办法跟python，cpp，那都是不一样
: 的。
: 这是很复杂么？
: 这最后一次了。你不明白就算了。

这是谁在转进啊？任何一个java过关的。都能用写个你说的那几条备份，无法
reproduce 出来的jar。

你举再多的例子与此事实有什么关系。你是不是压根对这问题一窍不通啊？这事有这么难理解么。

这不是公司有没有公司要不要的问题。问题是要的公司必须定死流程。也就是合规。不可能是你随便写什么都能reproduce的。这不是光靠tool以及你说的那几条备份这个那
个就能搞定的事情好吧。

【 在 skybluewei(weilan) 的大作中提到: 】
<br>: 能不能看一下上面的link再说啊。。。能不能不要老转进啊？
<br>: https://github.com/jvm-repo-rebuild/reproducible-central
<br>: maven build大部分是java的吧，list里打绿钩的不都是reproducible
builds么？
<br>: Debian's Reproducible Builds project那个是不是c/cpp packages啊？https:
//wiki
<br>: .debian.org/ReproducibleBuilds
<br>: 绿色的不都是可以reproducible builds吗？
<br>: 至于我们公司怎么做的，有关系吗？我一开始就说了，我们公司要求
reproducible
<br>: build，怎么实现是技术员自己去搞，其中包括我说的哪些，仅此而已。
而不是
像你们
<br>: 那这些喷子们，一会儿公司没要求啦，一会儿不需要啦，一会儿又不可能啦，巴
拉巴拉
<br>: 巴拉。。。上面的link把你们脸都打肿了，还在那瞎逼逼。还最后一次，最后一
次被打
: ...................
<br>

这和我们公司具体怎么实现的有关系吗？

讨论的问题主要就是这两点，人家问的也就是“怎么做binary级别的rebuild”
1，要不要做reproducible build？我们公司要求做，我们不算大厂。上面也有网友说
了，有些大厂要求做。你们这些喷子的回答是：没必要啦，很少有公司要求，吃饱了撑的啦。
2，能不能做到binary 级别的rebuild？我们公司可以做，上面links里的java和c/cpp projects 都可以做。你们喷子的观点是，哎呀，java编译出来的byte code和jar怎么
可能一样呢？c/cpp这么高大上的东西，每次编译怎么会一样呢？compiler这么牛逼的
东西，怎么可能编译出来一样呢？

LOL，脸肿的都数不出话来了吧？

【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 这是谁在转进啊？任何一个java过关的。都能用写个你说的那几条备份，无法
: reproduce 出来的jar。
: 你举再多的例子与此事实有什么关系。你是不是压根对这问题一窍不通啊？这事有这么
: 难理解么。
: 这不是公司有没有公司要不要的问题。问题是要的公司必须定死流程。也就是合规。不
: 可能是你随便写什么都能reproduce的。这不是光靠tool以及你说的那几条备份这个那
: 个就能搞定的事情好吧。
:
: 能不能看一下上面的link再说啊。。。能不能不要老转进啊？
:
: https://github.com/jvm-repo-rebuild/reproducible-central
:
: maven build大部分是java的吧，list里打绿钩的不都是reproducible
: ...................

你是不是与或非都不知道怎么回事。没人说reproduce 不可以做。也没人说“很
少公司要求”。不信你找原文来看看。

我说的是。只靠tool,不靠制定很多规矩来约束写法和程序应用之范围。是覆盖不了全
部之情况的。你之前说这个那个
备份就可以了。是把这问题想的太简单了。

只按你说的那几条，jar都未必能reproduce出来。这个事实显然是在你理解之外的。

你前后说的你自己公司情况也是矛盾的。之前你说这样那样几条就可以reproduce
binary。这个答案，当然是有问题的。

然后你的position 现在成了“怎么实现是技术员自己去搞”。

【 在 skybluewei(weilan) 的大作中提到: 】
<br>: 这和我们公司具体怎么实现的有关系吗？
<br>: 讨论的问题主要就是这两点，人家问的也就是“怎么做binary级别
的rebuild”
<br>: 1，要不要做reproducible build？我们公司要求做，我们不算大厂。上
面也有
网友说
<br>: 了，有些大厂要求做。你们这些喷子的回答是：没必要啦，很少有公司要求，吃
饱了撑
<br>: 的啦。
<br>: 2，能不能做到binary 级别的rebuild？我们公司可以做，上面links里的java和
c/cpp
<br>: projects 都可以做。你们喷子的观点是，哎呀，java编译出来的byte
code和
jar怎么
<br>: 可能一样呢？c/cpp这么高大上的东西，每次编译怎么会一样呢？
compiler这么
牛逼的
<br>: 东西，怎么可能编译出来一样呢？
<br>: LOL，脸肿的都数不出话来了吧？
<br>

好吧，我一条条来打脸：
这是在说没有point吧？
【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 你如果不做系統安全方面軟件，這個reproducible builds有什麼point麼？
: 此外，如果有一堆三方庫 dependency的軟件，本身安全性已經沒有了。

这是在说不可能吧：
【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 那你這個就是dependency management不是binary 級別的rebuild。
: 因爲即使庫版本完全一樣，也不能保證兩次編譯的binary完全一樣。
: packages

这是在说不可能吧：
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 大家且冷静。回到问题本身。
: 这问题java的人和c/cpp的说不到一起。
: 例如对c/cpp来说，程序每次build出来之后binary 不一样是常事。不是包管理就可以
: 搞定的。
: 1.本身compiler的deterministic 就很难保证。
: 2.os有无数状态，每次启动机器，那都是不一样的。
: 你要完全备份环境，是很难的。
: 3.另外很多文件还可能有格式内嵌的状态与签名。
: 4. ...

这点是说不可能、不会有人这么干吧，“难相信你们QA每次都重新build然后比对hash
或者check sum才算通过”

【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
限定在java范围。你只能说精神上你的working process是deterministic 的追求。
但是我很难相信你们QA每次都重新build然后比对hash或者check sum才算通过。
板上写java的很多。哪个公司的QA是这么做的? 这点大家可以交流，实证与学习。

====我想问一句，你现在相信“我们QA每次都重新build然后比对hash或者check sum才算通过”么？
====我说的只是一个guidelines，几乎没有涉及任何技术细节，大家自己的源程序
build的东西都不一样，我怎么可能给你提供技术细节？我连c/cpp都不会写，怎么可能指导您怎么做c/cpp的reproducible build？我又不是喷子。。。我通篇发言只有几个
point，1.本公司要求build要reproducible，2.本公司基本做到了（我都没说完全做到了，我说的是对不上的要给出理由为啥对不上，才能sign off），3.reproduce build
的guidelines，比如，source code, build环境备份，package management 等等最基
本的方面要考虑，也就是最大程度的减少build的不确定性。（基本不涉及具体技术细
节，唯一提到的是jar的manifest file，因为有时间戳，是个很好的例子说明为啥编译结果可能会不一样，正常思维的人都会想到，假如我源程序里有时间戳，如果不把时间戳确定下来，那不是怎么build结果都不会一样么？我怎么去从源头上和过程上去保证
build的确定性？而不是去纠结，jar file是binary还是bytecode？仅仅改改menifest
是不是jar就能一样了？等等。）

【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 你是不是与或非都不知道怎么回事。没人说reproduce 不可以做。也没人说“很
: 少公司要求”。不信你找原文来看看。
: 我说的是。只靠tool,不靠制定很多规矩来约束写法和程序应用之范围。是覆盖不了全
: 部之情况的。你之前说这个那个
: 备份就可以了。是把这问题想的太简单了。
: 只按你说的那几条，jar都未必能reproduce出来。这个事实显然是在你理解之外的。: 你前后说的你自己公司情况也是矛盾的。之前你说这样那样几条就可以reproduce
: binary。这个答案，当然是有问题的。
: 然后你的position 现在成了“怎么实现是技术员自己去搞”。
:
: 这和我们公司具体怎么实现的有关系吗？
: ...................

Let's start small.

光靠tool搞不定jar reproduce。还得要求developer合规才行。这条同意不。

【 在 skybluewei (weilan) 的大作中提到: 】
: 好吧，我一条条来打脸：
: 这是在说没有point吧？
: 这是在说不可能吧：
: 这是在说不可能吧：
: 这点是说不可能、不会有人这么干吧，“难相信你们QA每次都重新build然后比对
hash
: 或者check sum才算通过”
: 限定在java范围。你只能说精神上你的working process是deterministic 的追求。
: 但是我很难相信你们QA每次都重新build然后比对hash或者check sum才算通过。
: 板上写java的很多。哪个公司的QA是这么做的? 这点大家可以交流，实证与学习。
: ====我想问一句，你现在相信“我们QA每次都重新build然后比对hash或者check sum才
: ...................