@BGLL 里面只有 gitattributes 和 gitignore.

明摆着应该用自动机

加一句, 说清楚才能洗清有可能侵犯 GPL 的嫌疑. 啥都不提算什么事.

楼主你直说用了谁家的算法吧.

@mewking 缺少 idea 就逛逛

deep learning 训练模型? 不过需要 N 家当代顶级计算卡, 几年前的话就算了吧.

@rrkelee 公开 merkle root hash 及其构建方法(需要加入 node size), 然后允许每个参与者验证自己的部分就可以. 如果组织者插入了私货那么 size 域会暴露.

@GKLuke random.org 会给他们输出的随机结果签名吗? 就算有签名, 开奖人能不能从大量结果里挑选自己想要的?

证明 (1) 概率分布 (2) 种子来自于不可预测不可操纵的公开数据源. 证明必然要公开展示重现的方法.

混乱的问题. 把 terminal emulator 和执行环境都混了

@yemenchun1 需要等待, 而且等待时间还是相当长的. 0.1ms 对于现代 CPU 来说能执行 30 万个 cycles, 这时间中能做很多事情了. RAID 0 增加的是并行性, 对延迟没有帮助.

大致可以这样考虑:
一个连接上能同时发几个请求?
能不按顺序的执行并返回吗?
其中一个请求失败了怎么办?
如果有一个请求体积很大会不会堵住其他的?
能不能高效的做路由?
(可能还有其他的)

都解决了你可能就搞定了一个再发明.

@allanwhl 如果整盘都是 0 的话只能节哀了. 跳着看看或者用工具找哪里还有非 0 数据吧.

@allanwhl 那篇文章对你没有用.
你需要确认的用二进制编辑器看两块盘上还有没有数据. 基本上前 64k 如果不都是 00 或者 ff 的话(或者你认识 MBR / 分区表 / 启动结构更好), 就还有希望.
用专用软件重建之后可以备份到另外的盘上, 如果手里有机械盘比两张盘总和还大的话更好(说不准可以直接启动).

@yemenchun1 这里的 stripe size 是 64k. 做 RAID 0 之后, 那么 64k 以内的随机读写性能必然加倍, 64k 以上的在碰到单块 SATA? 带宽瓶颈之前也加倍.

@ryd994 硬 RAID 在硬盘上不写 metadata / superblock. 你指向软 RAID 的修复方法可能没有意义. 解除 AHCI 的时候没被重写就有戏, 被发了 TRIM 就是灭顶之灾了.

当年 iOS 2.0 App Store 刚出的时候就明确知道主执行文件是加密的啊. 那个加密不愿意处理掉的话你需要设法另外注入解密相关的帐号信息, 或者是企业证书这样的方法.

nginx rewrite 直接能搞定的事为什么要 flask? 又慢又阻塞, wsgi 下只能发送 full response, 不是楼主想象的边收边发.

@msg7086 应该是在明白 RAID 0 原理之前理解错了. 以为自己有一个系统盘一个数据盘但其实都被硬 RAID 0 混在一起.