恕我直言，楼主你所担心(worry)的方向不对。

楼主担心哪些职业会消失，其实应该担心的是，AI 会带来哪些社会形态的变化，像是 #27 楼 @hussar 提到的全民基本收入？生产力如此发达的情况下，分配制度会变成什么样，是不是每个人都可以享有免费的住房、医疗等等。还是说变成了各种电影中的，少数人利用没有意识的 AI 奴役多数人的地狱场景？

害怕大部分职业都消失，想极力保有自己的职业优势，这是最不需要担心的事情。

我觉得 #30 楼 @GeruzoniAnsasu 的公私钥方案是最简单可靠的。

端对端加密中间商无法偷看，且只有特定接收人才可以解密。当然要实现楼主说的需求，现阶段条件不成熟，因为没人习惯用私钥公钥的方式，都是用账号和密码，账号和密码对第三方是保密的，但对中间商是裸露的，这也是楼主问这个问题的原因，担心中间商窃密。

但我相信随着 web3 的发展，每个人都会习惯拥有自己的 N 多个私钥，每个人都真正拥有自己的数据，获取自己的数据产生的价值。

@dearroy 楼主，看了一下 EarlyBird 的产品，感觉很不错。付款那块我没明白，是在产品出来之前，用户就可以支付了吗，然后等产品出来了，再通知付款的用户？

@cangcang 也对。但这个成功是信息差带来的。
@lookStupiToForce 分析的有道理。

@dx3759 “到一定岁数就不能卖了”，其实也是在说竞争大，不是真的不能卖了。。
@netabare 纯粹上班其实就是卖自己了
@xiaoz 到了长期维护和更新这一步，就算是成功了，毕竟前面的风险已经跨过去了。
@zhaojun1998 嗯产品就是有无人问津的风险，所以一般都是接项目，然后提取产品思路吧，这种就像 @westoy 说的，如果产品很标准化，那么做的人也会多，竞争激励利润低。如果产品需要大量订制，那么也要投入很多时间。

附议。另外我想建的网站还包括：

归谁管。政.府有哪些部门，国省市县乡村，日常非日常的生活中，哪些事归哪个部门管，部门之间是什么关系。
纳税钱。统计生活中的哪些东西包含了哪些税。收集官方资料，看税收都花在哪里了。
五毛言。收集网络上的典型五毛言论，给出具体的例子，比如 v 站上的。

“基本是对性能要求比较高的” 说的不严谨，应该说是“对压榨硬件性能的要求比较高”。

得看语言适用的行业，跟语言没关系。楼主有没有调研过 C++适用的行业呢？基本是对性能要求比较高的。

未来水世界，跟疯狂麦克斯比较像
掠食城市，超级大场面的追逐

记笔记心里要想着 10 年后，你觉得 10 年之后可能会有价值的材料，就记下来。
读书的话，如果没有自己的思考要记录下来，那还需要记啥笔记呢，想回顾就直接看书不行吗？

复制粘贴挺好的，只要觉得有价值，这些都是后续加工的素材。如果能再加上点自己的评论，就更好了，可以知道自己的思想轨迹。

我发在 v 站的呕心沥血之作：
笔记软件最重要的功能是搜索——关于笔记工具的思考(上篇) ： /t/818822
笔记的标签结构——关于笔记工具的思考(中篇)： /t/825142

> “正如 Snow Dashboard UI Kit, 它就是为了让中小微企业更快地搭建更为先进的中后台产品.”
对楼主的东西比较感兴趣，想进一步了解一下，但“中后台产品”这个名词，把我吓着了😂，具体是做什么的呢？看示意图也没有看明白。

大家都是划水高手，你怎么捍卫护城河？

@0o0o0o0 #129
改签是先买后退，不涉及同步。因为票总是能退的：买不到就改签失败，无需退票；买到了就改签成功，总能退掉原票；
买多张票也是一个道理。

@0o0o0o0 #107
你说的这些里面，都不会影响各车次、各区间、各时间的并发独立性啊。我这里说的并发独立性，是指数据的写入。

比如“铁路一个人买两张票时间不能有重合”，这个只要查询一下这个人已经买的和将要买的票的信息就可以了，只涉及读取数据。

@watzds #115
预设的票数更合理吧，
一是因为预设票数有背后统计数据的支撑；
二是实时计算有明显的问题：因为订单是按时间先后提交的，如果短途先提交订单，那么长途就都给占用了。分配车票肯定不能这么明显的受订单次序的影响，如果要给长途票预留一定的数量，那不又回到统计长短途比例的思路了嘛。

@picone #78
所以啊，1 天才对应 32M 内存呢。不同天的数据是可以分布式的，1 台机器只处理 1 天的订票工作不就可以减轻负担了吗？

按照前楼的说法，买了 A-D 的票不影响买 A-B 的票，内存还可以减少。20 个站，两两形成 200 个起点-终点对，每个起点-终点对维护一个剩余票数，2*200=400 字节就够了。

其实把这个问题简化，很多都是可以并发的，而且是完全的并发，不需要同步。
- 5000 个车次，分给 5000 台机器，每个机器处理 1 个车次的订票操作，互不干扰
- 20 天内的订票，分给 20 台机器，每个机器只处理某 1 天的订票
- 20 个站，两两之间形成 200 个起点-终点对，彼此之间的剩余票数也是独立的(按照前楼说法)，分给 200 台机器去各自处理。

按照每天发送 1000 万次旅客的高峰，5000*200 台机器并发，每台机器只需要响应 10 次订票请求就可以了。

我觉得#1 说的很对，难度被夸大了。

直到现在，12306 的余票数量还是像量子力学一样，一会儿显示有票一会儿又突然消失一会儿又出现那个数字，然后点进去买票，就显示出票失败。
所以，同步加锁并没有想象的那么严酷。

另外，铁路看起来那么多条挺吓人，但是各个线路是没有关系的啊，所以考虑难度的话，只考虑 1 条线路就好了，1 条还觉得很难吗？

内存方面#1 楼也论证了，几个 G 的内存就足够了，1 台机器不行的话，就多加几台，内存纠错，大带宽同步传输。挺快的。:doge