aloxaf 最近的时间轴更新
aloxaf

aloxaf

V2EX 第 457420 号会员,加入于 2019-12-04 18:50:00 +08:00
aloxaf 最近回复了
@ALLROBOT

> 我应该找个不带金融意义且无上限发行的虚拟币,假设每人注册一个虚拟地址就赠与一个 token ,每一次下载别人文件就付小额 token ,分享的文件被别人下载就获取小额 token ,也可以设置 token 不到一定额度就禁止用户下载文件,用于鼓励一些人上传文件互相分享应该可以吧?

你怎么阻止我生成一堆地址而获得无限的 token 呢。而且你这个经济系统里面的 token 「产生」方式只有新地址?这完全难以为继啊,就是在逼着人不断生成地址。
大多数虚拟货币都不追求价值稳定,因为稳定的话就没炒作空间了……

稳定币一般都是有抵押的。纯智能合约实现的也有,这类币叫算法稳定币,比如 UST ,它通过和 Luna 之间套利来维持其价值。然后 Luna 前两年归零了,从 100U 跌倒小数点后几个零。
12 天前
回复了 ZGeek 创建的主题 NAS NAS 磁盘文件系统如何设计
@heimoshuiyu #41 这是 raid10 吧,那确实坏两块盘有大概率炸。
12 天前
回复了 LnTrx 创建的主题 Android 评小米 Bootloader 解锁进一步收紧
@LnTrx 小米此举确实忘记了初心。但是这和粉丝运营有啥关系,小米用户总不至于全是被刷机吸引来的吧。
12 天前
回复了 ZGeek 创建的主题 NAS NAS 磁盘文件系统如何设计
@heimoshuiyu

你说的「缓存因为意外无法写入」,任何文件系统都存在这个问题,对缓存利用越激进(如 ZFS )就越容易有这个问题。但 btrfs 和 zfs 一样是抗断电的,它和 ZFS 一样有校验、有 CoW ,元数据默认存两份,虽然会炸,但也不是这个原因炸。

zfs 通常性能确实比 btrfs 好,这类 CoW 文件系统都无可避免地存在碎片化问题,zfs 靠缓存来弥补。btrfs 在这方面只能根据负载来手动优化。

比如你说 ls 一个 10000+ 文件的目录要 5s+,我猜是你没有启用 noatime 挂载,导致每次访问都会修改 atime ,在 HDD+小文件+CoW 的组合下,这简直就是灾难。
又比如你说 sqlite3 很慢,这也是碎片的锅,btrfs 确实不适合数据库这种负载。如果要用,建议使用 chattr +C 对数据库关闭 CoW ,可以有效提升性能。

btrfs raid1 没有读取加速是真的,但是 4 坏 2 就会导致数据全部丢失没听说过,那 2 块盘 raid1 岂不是一坏就炸 。btrfs 在降级状态默认会拒绝挂载,是不是和这个搞混了?

最终结论我没什么意见,我自己也是 nas zfs + PC btrfs 。
看了下前面人说的猫咪大战争,这个游戏就是每个账号初始生成一个种子并且永久不变,而且用的还是非密码学安全的随机算法,而且计算最终抽卡结果用的还是简单的取模,这才被人做到了预测自己的抽卡结果,而且也只是预测,无法控制。

如果想做到控制结果,那必须得有其他方法来影响这个种子,但是这样你能猜到算法的难度就大大增加了。我觉得只有阅读了服务端代码的拉普拉斯抽卡妖能做到。
挺难的,不安全的伪随机数生成器最多让你能预测下一个数字。但你不知道服务端具体是怎么使用这个生成器的,更不用说为了减少极端的抽卡体验,不少游戏都不是真正的随机。
rust 的借用检查器一直在改进

它早期是基于词法作用域的,所以会出现你书里说的那种情况,你在 godbolt 里测试早期的 rust 版本就能看到报错了。当时写 rust 程序常常需要把一些创建临时引用的代码用大括号另起一个作用域,看起来莫名其妙的,就是为了规避这个问题。

后面引入了 non-lexical lifetimes (NLL) 版本,会智能分析这个引用和其他引用之间是否存在冲突,而不是粗暴地看作用域,大部分情况下都能给出复合直觉的结果。少量 edge case 可能要等下一代检查器 polonius 了,不过这几年都没啥动静。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1009 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 16ms · UTC 17:15 · PVG 01:15 · LAX 09:15 · JFK 12:15
Developed with CodeLauncher
♥ Do have faith in what you're doing.