lxdlam 最近的时间轴更新 lxdlam 最近的时间轴更新 ONLINE |
lxdlamStay hungry, stay foolish V2EX 第 91515 号会员，加入于 2015-01-13 12:44:59 +08:00今日活跃度排名 339 |
blog.lxdlam.com
北京海淀
lxdlam
lxdlam
lxdlam
lxdlam 最近回复了
6 天前 回复了 Kivy 创建的主题 › 分享创造 › [独立开发者] 开发的 Android Emby 第三方客户端 - Yamby 上线，抽 3 个永久 Pro 兑换码 |
支持了，如果能看到 TV 支持就更好了哈哈
7 天前 回复了 cherryas 创建的主题 › 程序员 › 已经用了 copilot 订阅快两年了，突然发现我已经废了。 |
Copilot 对临近 context 的学习能力很强，写日志和监控的输出、接口的相似实现实在是太好用了。虽然核心逻辑始终现在的 AI 还是不够好，但是大量的人力工作也就是在写这些纯模板代码上，确实帮我节省了大把时间。
9 天前 回复了 digd 创建的主题 › Apple › 8GB 内存版苹果 iPad Pro 疑似搭载 12GB 内存颗粒 |
有一种可能是跟屏幕一样，8G 跟 2x6G 混用了，然后软件限制都是 8G 。目前应该只拆了一些机器，所以不好说，看看后面有没有更多人拆
12 天前 回复了 lsk569937453 创建的主题 › 程序员 › 目前来看 CAP 理论中的 CP 和 AP 最容易造的轮子是？ |
@lxdlam 有一定差距 -> 有一定不同
12 天前 回复了 lsk569937453 创建的主题 › 程序员 › 目前来看 CAP 理论中的 CP 和 AP 最容易造的轮子是？ |
Zookeeper 不是 Paxos ，而是自己发明的协议 ZAB ，跟 Paxos 有一定差距；实现了 Paxos 的系统有很多，比如 Google 的 Chubby 和 Scylla DB 。
同样，根据 DDIA 的说法，现代 CAP 其实逐渐式微，因为现代系统设计里面这三个每一个话题都会有很多需要考虑的问题，不再只是单纯的 3 选 2 了。
同样，根据 DDIA 的说法，现代 CAP 其实逐渐式微，因为现代系统设计里面这三个每一个话题都会有很多需要考虑的问题，不再只是单纯的 3 选 2 了。
13 天前 回复了 onlyApple 创建的主题 › 程序员 › Al 可以推理 AES 算法？？ |
@ShinichiYao #28 如果 Key space 足够小且 IV 的 space 也足够小的情况下，知道一定的 plaintext 才是可以攻击出密钥的，这个叫做 Known-plaintext Attack 。
在已知范围内，如果不满足上面的结论，AES （所有模式）都免疫 KPA ，这是因为 KPA 的一种最直接的攻击就是遍历 key 跟 iv space ，尝试每一种可能的 combination ，如果都在 2^16 这个级别，现在的好一点的家用电脑可能不需要一晚上时间。而在现代实践中，AES 一般使用 128bit 及以上的 key ，这种情况下即使 IV space 较小，攻击难度也非常大。跟知道多少 (plaintext, encrypted) 无关。
Reference： https://crypto.stackexchange.com/questions/100521/for-aes-gcm-does-knowing-plaintext-and-ciphertext-allow-attacker-to-learn-the-k
在已知范围内，如果不满足上面的结论，AES （所有模式）都免疫 KPA ，这是因为 KPA 的一种最直接的攻击就是遍历 key 跟 iv space ，尝试每一种可能的 combination ，如果都在 2^16 这个级别，现在的好一点的家用电脑可能不需要一晚上时间。而在现代实践中，AES 一般使用 128bit 及以上的 key ，这种情况下即使 IV space 较小，攻击难度也非常大。跟知道多少 (plaintext, encrypted) 无关。
Reference： https://crypto.stackexchange.com/questions/100521/for-aes-gcm-does-knowing-plaintext-and-ciphertext-allow-attacker-to-learn-the-k
14 天前 回复了 wdssmq 创建的主题 › 奇思妙想 › 脑洞讨论：用所谓的「三观」来做身份认证？ |
零知识证明。
15 天前 回复了 shinelamla 创建的主题 › 程序员 › 为什么 golang 提倡 「接收接口，返回结构体」这样的原则呢？ |
@kuanat OCaml 有两种数据对象，一种是传统的函数式对象 Record ，这个是 nomimal 的，类型 tag 区分不同类型，而 object 和 module system 是 structural 的，实际上我例子中提到的函数可以这么写：
```ocaml
let print (bar : < foo : string; .. >) = print_endline bar#foo;;
```
注意到这个独特的签名，其实要求 `bar` 需要具有一个特定的 foo 即可，对其他的都不要求。
```ocaml
let print (bar : < foo : string; .. >) = print_endline bar#foo;;
```
注意到这个独特的签名，其实要求 `bar` 需要具有一个特定的 foo 即可，对其他的都不要求。
15 天前 回复了 shinelamla 创建的主题 › 程序员 › 为什么 golang 提倡 「接收接口，返回结构体」这样的原则呢？ |
@lxdlam oops ，应该是 #10 ，看错楼了
15 天前 回复了 shinelamla 创建的主题 › 程序员 › 为什么 golang 提倡 「接收接口，返回结构体」这样的原则呢？ |
@lxdlam 补充一点，Go 的基于 Signature 的 interface matching ，实际上 OCaml 早实现出来了，即使是 First class module ，也是 2011 年引入的，早于 Go 。
```ocaml
module type Foo = sig val foo : string end;;
class a = object method foo = "A" end;;
class b = object method foo = "B" end;;
let print bar = print_endline bar#foo;;
print (new a);; (* "A" *)
print (new b);; (* "B" *)
```
```ocaml
module type Foo = sig val foo : string end;;
class a = object method foo = "A" end;;
class b = object method foo = "B" end;;
let print bar = print_endline bar#foo;;
print (new a);; (* "A" *)
print (new b);; (* "B" *)
```
Select Language