@acess #40 正因为如此，就还是那句话，这种讨论本身意义并不大。本身就是几乎不能证明的事情。如果不信任厂家，可以直接选择退坑，游戏也并不是没得选，隔壁塞尔达也可以玩。一个 648 可以买两三款游戏甚至 3A 。

而且最主要的是，在抽卡这种有保底机制的存在下，必然是不可能真随机的，算法就是要做到随着次数递增而概率递增。这与数字币的需求完全不同。

而且厂家这么做的动机并不强烈，这款游戏还没有到恰烂饭的时候，暂时看起来还在上升期，这点小钱把自己名声搞臭并不值当。况且还有隔壁企鹅不遗余力的黑，这不至于。

@wuxkwnjjwoxk #30 讨论的前提不存在了，即使厂家愿意公布都不能证明是否存在作弊，更何况不可能公布。不能证明也不能证伪的问题，就没有讨论的必要。剩下的只是阴谋论。

提前生成序列是可以的，但是他不能预测你什么时候抽、抽多少，因此势必影响总体概率，如果要不影响总体概率，就要经常重新生成抽卡结果了。

假设预生成了一定序列给一个大怨种，结果大怨种弃坑不玩了，原本这个人的收益预期是低于平均值的，此时由于这个人弃坑，则总体概率会高于平均值，因此需要重新生成其他玩家的序列。要实现这种动态的平衡是比较困难的。

最后，这种问题，没有讨论基础，如果只是单纯阴谋论认为有鬼，完全可以弃坑或者按照自己认为对自己有利的方式去游戏。

@wuxkwnjjwoxk #21 这样说就没有意义了，结论就会变成不能证明，也不能证伪，这就失去了讨论的意义。从动机上来说，完全没有必要，收益太低。

我自己也是玩家，就实际体验来说，其实还不错，我个人是不充钱，能有几个角色，玩的还行。也有过运气好，10 连双黄，也吃过连续的大保底。

假设身份对换，我们变身成为游戏厂家，如果有玩家这样的质疑，我也没办法证明，即使我给出数据，还会有人怀疑数据真实性。我开源，也会有人怀疑开源代码与实际运行的不服。

@wuxkwnjjwoxk 你假定了在不同人群下的概率不一致，但要证明这一点需要有一批人群同时拥有你所说的特质，才能进行统计学上的分析，个体上的体验不同，否则大概率只能认为是幸存者偏差。

可以，但没必要。因为本身的预期收益距离保底已经非常接近，这里做手脚收益并不高，还不如让你多歪一次合算。

而且对于这种现象级游戏，在这种地方赚的钱，远不如设计一个新角色来售卖的收益更高。

gradle 这玩意，API 并不稳定（特别是有自定义构建流程的需求），经常会出现前几个版本用着好好的代码，新版本行为不一致或者不能使用。

所以一般这东西都是采用 gralde wrapper 。比较少采用系统 /用户换机提供的 gradle 。

一次业务操作需要读取百万条记录显然是不合理的。尝试业务流程上的优化。如果只是一些统计汇总的任务，完全没必要把所有记录加载到内存后处理。流式的处理并不需要什么内存空间。甚至还不如直接在数据库中汇总后再返回。

医保个人账户余额可以，医保统筹账户不行。

大白话就是个人账户余额是你每个月自己交的钱，干啥都可以的。而统筹账户就是国家（企业缴纳部分）的钱，只有限定医疗项目与限定药品可用。

我小时候，有见到过，脚踩是比较普遍的现象，不限于酸菜，各类腌制、发酵类都有这种做法。不过当时大多数是小作坊或农主自制。

arm kvm 很早之前，我自己企图尝试过。当时手上有一款退役的小米 8 。查找多方资料，高通的处理器很早之前就支持了虚拟化，但是几乎所有厂商都在 bootloader 中把虚拟化相关的功能给禁用了。原因不明。

同时很遗憾的，几乎没有什么厂家开源 bootloader 的代码，因此我最后的尝试并未成功。以现在国内 Android 手机的性能，实则过剩。不过这种虚拟化方案更具有实际意义的是双系统，如果走嵌套虚拟化的路线，则很可能被黑产用来刷设备，进而导致各个厂家的应用风控愈发严格，或更加严重的个人信息采集（手机号、身份证啥的）。

合理为啥不能改呢，单纯为了抬杠而抬杠就没意思了。大家都是出来赚钱的，可不是来抬杠的。

可以试试 adguard home ，上游直接走 DOH ，缓存时间可以稍微设置长一些，毕竟 DNS 不会频繁变更，副业顺带还可以过滤部分广告。反正简单配置下，现在小米电视和爱奇艺的广告是看不到了。

装是都可以装的，adb 以后啥应用都能装，主要两个问题。

1 、手机版应用在机顶盒上，可能横竖屏存在问题，即应用一直竖屏显示
2 、手机版应用大概率不支持遥控器操作，意味着你需要外接鼠标、键盘操作

特别是第二条，便利性还不如投屏方便。

待在深圳的时候，发现许多小区根本没有联通资源，最后选择了移动（毕竟便宜。

现在到了杭州，联通还算不错，当然可能和小区也有关系。720 两年 200M ，双拨一下，喜提 500M 带宽，上行也叠加到接近 100M 。算是性价比很不错了。

基本可以认为从诞生游戏就有这个玩意了。抽卡本质就是随机产生奖励。几乎所有游戏都有这个属性。

唔，各位都是多少收入，月收入三四万都没这些破烂事情。

@fisherwei 性能不太可能比 iSCSI 更好。我自己这里有过某个应用场景，高负载、大带宽的磁盘随机读，分别尝试过 SMB/FTP/WebDav/NFS/iSCSI 。

在内网 40G 的带宽以及 Intel M.2 固态的支持下，只有 iSCSI 能够在较低的磁盘负载下，提供更高的网络吞吐量。

其他各类协议的额外开销都很大，甚至部分协议在只读取文件部分内容时，会传输整个文件，导致网络带宽被浪费。

@yibo2018 唔 我的意思是，我的小伙伴在业务逻辑中自己组装数据的时候，很容易出现笛卡尔乘积。就是有一些小伙伴的业务能力相对欠缺，因此还不如直接把这些任务丢给数据库，至少数据库的下限高于许多开发人员。

至于数据库上的笛卡尔乘积，除了 inner join 以外，在多表查询或者嵌套了子查询的情况下，也容易出现。但是数据库上的问题相对好解决（即数据是通过视图返回的，即使存在问题后修改，保证字段一致，不需要修改程序），同时存在 explain 方便排查。