@Hieast
@hxndg
@auxox
图数据库？文档数据库？ 好的，我去了解一下。


@tabris17 #4 > “我觉得楼主把数据库索引和真正的数据搞混了”
没有吧，你可以看一下主题里提到的那个帖子。一个树形结构，如果使用内存对象，那么查找和修改的算法分别可以在 O(N)和 O(1)的时间复杂度完成。而使用关系型数据库，应该是达不到这个时间复杂度的，至少不能同时达到。

@hxdng #7 > “你说的该是硬盘吧，关系数据库不是完全不能随机访问的”
有可以随机访问的关系型数据库吗？这块不了解，可以举个例子吗？

前一阵正好研究过这个，来说一嘴。
手机 GPS 记录真的费电！ 3000mAh 的电池，3~5 秒记录一次的话，大概能用 6~8 小时吧，这还是不开其他应用，不开屏幕，只在后台记录的情况下。GPS 应用一般都会阻止 Android 系统进入睡眠，因为一旦睡眠，应用就与 GPS 设备“失联”了，这就导致系统一直在唤醒状态，浪费无谓的电量。所以，感觉还是用专门的 GPS 记录仪会比较好一些(不过我也没试过)。

感谢提出这么好的问题！一个感谢敬上。
搜了下发现相关的主题叫做"Fair Exchange"，直译就是“公平交换”。

很有意思的密码学问题。大概看了下，发现目前的方案好像跟你说的差不多，都是通过逐段发送密钥的方式，这样在双方有一方反悔停发时，两人都处于相似的处境，比如都拥有了一半的密钥，要么都解密不了密文，要么都要花相近的计算量暴力破解密文，而率先终止交易也就是说多接收了一段密钥的那个人，最多也只比另外一方稍占优势而已。

还没仔细研究所以只能卖弄这么多，楼主你还是看下研究论文吧。

@kickcellardoor

记账软件只是一个类比的例子： 软件服务的提供方，不想把运算的逻辑暴露在客户端(容易泄露技术)。而客户也不愿把自己的明文数据交给软件服务的提供方。两不相让，这就尴尬了。。

而全同态加密可以完美应对这种情形。

我自己正在开发一款，现在距离最小可用版本还有 1 周时间吧。我觉得能完美匹配你说的需求。
有兴趣的话，可以加我的 v：SillyDaddy

@sillydaddy #26
程序模拟是一瞬间的事，但是各个角色的策略设定，是需要迭代的。

比如当你给水军的角色设定了一个策略，结果模拟显示这个策略没有成功，然而真实世界中的水军此时会更换策略。所以，模拟的话，难点应该在这儿——除非你把所有可能有效的策略都试一遍，不然不知道有没有漏洞。

@byzf #21 >“比例同一时间只有一个值啊，一个达标另一个肯定不达标。”
哦，是这样的，我没看清有“比例”一词。看起来是个有希望的方案。不过很多动态的过程没有办法直接想象。

我真的觉得，可以写一个验证程序模拟验证一下。

——模拟一下真实用户、水军用户的操作，看最后的效果怎样。这个模拟应该不会很费时间，主要需要对每个人的策略设置一下，比如真实用户的点赞、点踩的策略，水军的策略。

——举个例子来说，真实用户每天的点赞 /点踩数量是有限的，那么，他(她)会考虑，怎样最大化自己的收益，那就要考虑到底给哪个回复点赞 /点踩，才能有更大的把握拿到经验收益。然后还要引入一些随机变化，毕竟不是所有的用户都这么理性。。

——模拟计算可能是一瞬间就出结果，但事前的策略需要好好烧脑一番。

大概能明白楼主的意思。
作为一个软件开发者，我觉得楼主的思考很好。

> “...对于人而言，人是不会清晰的知道这些体验的具体时间的，人只会有一个模糊的时间印象，正是这种模糊是人的幸福感的来源...”
> “...这些体验归根结底是落在个体那里的，是每个人私人的体验，这是清晰的事实，产品要立足这一点...”

这个关于体验的事实是很清晰的，但具体来说，私人的体验是什么样子呢？ 怎么样让计算机去提供私人的体验？ 你说的“机械”的方式，是理性的、清晰的、机械式的，因为这就是计算机最擅长的表现与输出形式。就像“识别人脸”这种人说不上来怎么做到的任务，对于追求精确的计算机来说，反而是最难的任务，直到最近才由深度学习神经网络在一定程度上解决。

或者换个角度说，你觉得现有的哪个产品具有你说的这种体验呢？

密码学无所不能：
- 区块链工作量机制，解决密钥的去中心化生成与分发
- 零知识证明，解决密钥的验证
- secret sharing，解决投票解密
。。以上是我瞎猜的。

目前的手机 gps 定位功能，耗电还是比较高的。几秒钟读一次的话，满电几个小时就耗完了。不过几分钟读一次，耗电就不明显了。

之前发帖，提到“手机上的惯性传感器”，不需要显式权限就可以读取，而且耗电很低。( /t/760637 )
不知道这些流氓公司会不会偷偷读取呢？

@cmmulxuk
你用的什么版本啊？ 我把微信的位置权限给关掉了，也没碰到微信请求过位置权限啊。
天哪！！刚明白你说的是后台啊，原来如此，果真如此。唉！真是 sb 臭流氓！！恶心到家了。

> 3. 如果一个被点赞的帖子赞的比例超过一个值，那么每个点赞的用户都将获得经验。
> 4. 如果一个被点赞的帖子踩的比例超过一个值，那么所有对这个帖子点赞的用户直接降级。

这 2 点直接冲突吧，如果既有点赞，又有点踩的，都超过了一个值，该怎么办？

这最后不就演变成了“水军”和“真人”大战了吗？ “水军”如果要买“真人”的号(或者说买号、养号)，提高自己的攻击水平，该怎么办？“真人”个体能团结起来不被“水军”团体各个击破吗？

@anUglyDog 建议发帖时选好节点

@Livid 建议移动到"分享创造"节点

“递”“归”解释的很形象哦

标题太简短了，差点错过这么一篇好文。
说好文，不光是行文表达，更多是文字中透出楼主的独立思考，向往自由的思想。
引人思考的文章，给楼主点赞。

看了回复，决定给 Rust 种颗草。

@levelworm #11
嗯，数据相关的文档肯定是不能省的。我上面指的需求文档主要是程序逻辑相关的，比如业务逻辑。

至于你说的程序不支持相关的数据，按照我的理解，没有什么不支持的数据吧：
>表的每个字段都是汇总
为什么开发人员不能提供汇总后的数据，而需要你去拆分数据？
>有些数据服务器端拿不到，只有客户端才有
既然数据分析需要这些数据，为什么拿不到？如果要拿到，需要哪些工作？
>有些数据某些微服务才能输出但是这个战斗的程序不需要这个微服务，所以就没有相关数据
数据分析需要这些数据，这个问题不能够被技术解决吗？
>最后我还得把需求拆成几个需求，分别给不同的程序员，又放弃了几个特别困难的，最后才算是凑齐了大部分的需求
感觉你太委屈了。
作为一个开发，虽然我不懂具体你说的这些技术，但我能相当肯定，这些数据来源的问题是可以用技术解决的。可能你跟具体的开发人员中间，少了一个沟通的渠道，比如对接的人，或者说是一个对接的机制(比如敏捷会议)，以至于额外的工作都被你负担了。但你不懂开发啊，这些技术细节交给你处理就不合理。

另外，友情提醒一下啊：
> 比如说 telemetry 从 Kafka 进来，需要丢到 Vertica 里，这个表应该是什么样的？ telemetry 里哪些部分需要进什么表，表和表之间关系是什么
从这句话，可以发现你的表达方式是可以改进的。因为这里面的几个名词，甚至对于一般开发人员来说，都是无法理解的，如果把它们换成可以被理解的概念，是不是好一些？ 这就引申出一点： 如果你与你们公司的开发沟通，能不能采用一种大家都可以理解的中间语言，来避免“鸡同鸭讲”的现象？你也就不用去学习那么多开发的东西了。

@HeyXiao #1
@SilenceRE
对，拆分子任务可以只拆当下要做的，只需要第一步(first action)就足够了。目标就是克服跨出第一步的阻碍。
有时，心理总想着定个时间把这个任务结束，把任务**集中**安排到某几天，心理压力很大，不喜欢的任务集中程度太高很容易产生厌烦，反而进展甚微。还不如把它们分散到不同的时间里，每天都有一点进展。