@ArJun 不清楚二十万具体花哪里了，但应该覆盖了硬件设计、固件开发和第一批货。

@arbit 硬件的情况确实很关键，但他也不太懂，说时去外地签了合同就回来了，我问过几个比较关键的问题，他不太了解，感觉没跟对方细致沟通过，已经让他去了解了。一些问题要拿到样机或对方设计方案，才好估计。

@arbit 整个项目不方便描述太细致，但我估计连带移动端做出来，软件系统整体搞得有模有样，放大城市怎么得三五十万的项目吧，后期还要修 bug 升级什么的，要养小舰队的。但我们这做这个的少，只能估摸着差不多就行。

@johnsona 用到了，上面贴的链接了介绍了 rebase 和 reflog 的用法，都上用了，对这俩命令大致有了点了解。

@secondwtq 谢谢！关于 Merkle Tree 的解释很有启发性，我当时简单 Google 怎么改之前的 commit message，看到一个条目预览里有-c 参数的用法，没点进去细看，想当然地认为-c 是指定 commit id 的；认为可以直接改前面 commit 的 message 也是因为不了解这个类区块链的存储机制（其实现在也不了解，不过知道跟常见的存储不一样，有很强的前向依赖）。
我运行`git commit -c 6b2c8b16 --amend`时应该是重用了上一次的 message，对最近一次的 message 进行了编辑，这样一来最近一次就记录了上一次的 author date，然后我又不知道 git log 默认显示的是 author date，以为是 commit date，所以会有上面的疑惑。
现在疑惑解开了，再次感谢！

@ampedee 谢谢，参考 https://www.jianshu.com/p/0f1fbd50b4be 解决了问题，不过还是不大明白为什么会在步骤 3 中看到错误的 commit 时间，git 太深奥了……

@msg7086 了解关键了，结合 @ipwx 对 utf-8 的强调，可以这么理解吧？可无限扩展的 Unicode+8 位为基本单元的可变长度的 utf-8，足以适应未来可预见的扩展需求，并保证存储效率和后向兼容性。

在手动运行备份任务十几分钟后，收到无法连接的监控邮件了，不清楚为什么有这么长时间的延迟，服务器端备份进程还在继续，本地监控的下载速度一直稳定在 120-160k 之间，可能是锁表什么的吧。无论如何问题明确了，hoory ！感谢提供排查思路。
@nowheretoseek @redford42 @hefish @ysc3839

刚才大致明白怎么回事了，明天中午验证下。
我本地有个定时任务，每天中午用 ssh+mysqldump 备份服务器上的数据库，这个站未压缩的数据库有 170M+，而这台服务器带宽很小，所以很可能是我备份数据库时占满了带宽，导致新连接不能被接受；考虑到连接静态站时没问题，也可能时备份数据表时锁表什么的导致数据库不响应，总之很大可能是这个定时任务导致的。刚才手动运行备份任务验证下没有重现，明天中午再验证吧。
@redford42 @hefish @ysc3839

@ipwx 只是设问，我也知道涉及的概念在不同层面上，而我很可能混用了他们。的确基本只是在字符串的角度考虑问题，不大能从 int 、byte 、char 、char[]的角度理解，这是个硬伤。

@halfdb 是这么个意思，表达很清楚。

@wdssmq 二进制因为包含一些 ASCII 范围内的控制字符或不可见字符，不便显示，也会在复制过程中损坏，并且某些传输协议对二进制不够友好（协议内使用了某些字符的组合作为控制字符使用等等）。base64 现在的主要作用是避免了这些问题，代价是增加了 1/3 的体积。这样理解对吧？

谢谢各位，你们说的知识点和思路我大致都了解些，我想问的其实是目前操作系统的设计中 Unicode 的耦合度，是完全可插拔的，还是说底层上有相当程度的耦合。之所以假设外星文明语言，如前说为了符合字符量很大（超过 CJK 总量）这样一个假设，使其无法放到现在的 Unicode 集合中，只能搞一个 New Unicode 。（这跟将一个少数民族的文字放入当前的 Unicode 体系中有些区别）
所以，再次这么表述下问题：如果有上述需求，是不是做些体力活设计出这个 New Unicode 以及相应的字体，就可以几乎无成本的显示、处理这些新的语言文字了？（几乎无成本是说做些配置或修改少数一点代码什么的）@ipwx 提到的有些文件系统会考虑编码是我想知道而之前不知道的情形之一。
@ipwx @msg7086 @binux @cmdOptionKana

谢谢，理解认同大家的意思，因为知识有限，我对一些概念的理解和表述可能存在层次混乱什么的，重新提一下问题：
我的主要想法是计算机世界的现状是 Unicode 有巨大影响力，一些编程语言有底层的 Unicode 支持，操作系统层面会不会也有为了适应它而做的耦合？毕竟好像暂时不用考虑新的类似 Unicode 的编码方案。当然如果出现了新的语言，而 Unicode 可以轻松将其纳入自己的编码体系中，就不是这个层面的问题。
一些轻量的 Linux 环境，默认只有 en 语言支持，要显示、接受输入其它语言，就用 locale-gen 添加，这些支持当然也是通过特定库、模块实现的。而似乎无法想象没有 en （ ASCII ）支持的操作系统。
那么如果现在有这么个需求，要用计算机处理一个字符量很大的新文明语言，比如字符量是 CJK 的总和还多些，那么是否可以比较容易、低成本的实现一个新的 Unicode2，并将其在 windows 、linux 等操作系统上跑起来？
@nowheretoseek @iotwd @ayase252 @bitdepth @cmdOptionKana @wanguorui123 @ipwx

管理员大大，求删 12 楼或仅保留第一行，谢谢！
@Livid @Kai @Olivia @GordianZ @sparanoid @Girlphobia

@Rever1e 搞错了，12 楼的不是 custom table 的，没必要尝试了，代码写太久了给自己看糊涂了……

@ysc3839 就是在运行站点的服务器测试的，明天中午加-vv 试试。

@nowheretoseek @AoEiuV020 @lakehylia @Rever1e @blackshow @noe132 @polaa @sujin190 @ipwx 谢谢各位，学习了，之前对替换是密码和从字频入手破解有些了解，也了解了 base64 大致原理，但还是感觉破解起来有点难度，所以小范围用过，没想到竟这么脆弱，并且有现成工具。

@nowheretoseek @redford42 @hefish @ysc3839 补充个信息，就是中午问题重现时，测试发现重启后问题消失，所以应该不是腾讯云服务器网络方面的问题。