jybox 最近的时间轴更新
现在似乎能占个前排
2014-02-12 21:45:56 +08:00
jybox

jybox

🏢  LeanCloud / Node.js 服务器端开发工程师
V2EX 第 15969 号会员,加入于 2012-01-23 22:25:42 +08:00
62 S 93 B
昵称「精子」,20 岁,高中退学进入互联网行业,坚持十余年的独立博客作者,皮蛋豆腐的主人,创建了 Atom 中文社区,还有一个「精子粉丝团」。
根据自己的使用场景为 M1 的 MBA 设计了一组性能测试
  •  3   
    MacBook  •  jybox  •  9 天前  •  最后回复来自 Jim142857
    3
    入手自动猫砂盆之后,我做了一个自动猫砂盆汇总网站
  •  2   
    分享创造  •  jybox  •  2019-03-09 21:17:30 PM  •  最后回复来自 luan
    17
    抛砖引玉:如何实现绝对公平的年会抽奖程序
    分享创造  •  jybox  •  2017-02-03 17:45:14 PM  •  最后回复来自 appstore001
    38
    Stream: 给机器人用的 Twitter
  •  2   
    分享创造  •  jybox  •  2017-01-23 15:03:58 PM
    JavaScript 和服务器端方向推荐书单(附简评)
  •  5   
    程序员  •  jybox  •  2017-01-16 13:24:38 PM  •  最后回复来自 bk201
    13
    强/弱类型、动/静类型、GC 和 VM,你分清楚了么?
    程序员  •  jybox  •  2016-12-17 11:45:40 AM  •  最后回复来自 FrankHB
    3
    我们真的有必要全站 HTTPS 么?
    SSL  •  jybox  •  2016-10-20 23:59:53 PM  •  最后回复来自 msg7086
    84
    jybox 最近回复了
    屏幕亮度 Pro 要高一点,其他应该没区别了。如果希望用时间久一点,建议加内存(可以考虑舍弃 Pro 或存储空间)。
    我的 M1 Air 测评 https://jysperm.me/2021/01/macbook-air-apple-silicon
    @helloworld000 #4 销量同时决定了软件生态,另外你怎么知道我不是苹果的(小)股东呢 ...
    71 天前
    回复了 FreeWong 创建的主题 问与答 问个前端公钥加密防止中间人攻击的问题
    因为响应也是加密的,中间人只能把请求转交过去而看不到响应的内容;同时因为 https 握手的时候会有随机数来避免重放攻击,所以中间人也只能转交一次,或者不转交。
    72 天前
    回复了 LeanCloud 创建的主题 NAS 开源技术够用了么?我的 NAS 选型与搭建过程
    @BostonCorbett 热插拔主要看硬件的支持,群辉低端的型号应该也是不支持的,文章中的 Gen10 也是不支持热插拔。
    72 天前
    回复了 LeanCloud 创建的主题 NAS 开源技术够用了么?我的 NAS 选型与搭建过程
    @calpes unraid 起步价就 $59,打消了尝试的念头
    @ntgeralt 文章中有提,ZFS 的 raidz ( RAID5 )因为有定期的数据校验,会比普通的 RAID5 更健壮一点,当然也要综合盘位数量和容量,数量越多、容量越大,重建的风险越高。
    @felixcode FaceTime 是漏洞并不是故意为之;被发到 Google 和腾讯的数据只是一个 4 字节的散列值
    @levn 苹果七成以上的收入来自硬件销售
    www.samba.org/samba/docs/current/man-html/smb.conf.5.html

    www.samba.org/samba/docs 这里点「 Samba man pages in html 」不就可以链接过去嘛 ...
    154 天前
    回复了 firhome 创建的主题 程序员 有没有那种可以提供 api 的数据库云?
    LeanCloud 了解一下?
    176 天前
    回复了 JasonLaw 创建的主题 Redis 我对 Redlock 算法的疑问
    >为什么要顺序地尝试获取所有实例里的锁呢?同时尝试获取会存在什么问题呢?

    同时获取可能会死锁(每个客户端成功在一半的实例加锁),所有客户端都顺序访问就不会出现死锁了。

    >键是在不同时间被设置的,所以也会在不同的时间失效。这样子还能够保证 mutual exclusion 属性吗?

    按我的理解这个 TTL 只是为了避免出现加锁后(因进程崩溃)没有解锁的情况,在一定时间后自动解锁,这本来就是一个特殊情况下的措施,其实在发生达到 TTL 时,锁的有效性就已经得不到保证了(你不知道是进程真的崩了还是暂时卡住了),所以这个 TTL 差个几毫秒并不是那么重要。

    正常的应用中不应该出现「期望在获取到锁之后的 ttl 时间内都能够唯一拥有锁」的情况,应该(比如在时间用掉了一半的时候)不断地续期,在结束后主动地释放锁。
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2607 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 15:43 · PVG 23:43 · LAX 07:43 · JFK 10:43
    ♥ Do have faith in what you're doing.