📸 @Kendo_Jidai ×4
剣道時代７月号にて全日本剣道演武大会の模様を掲載しています。武徳祭は素晴らしいですね。
https://www.taiiku-sports.co.jp/ #剣道 #京都大会
原文 #剣道
剣道時代７月号にて全日本剣道演武大会の模様を掲載しています。武徳祭は素晴らしいですね。
https://www.taiiku-sports.co.jp/ #剣道 #京都大会
原文 #剣道
Bloom Filter：一个靠"撒谎"节省空间的聪明数据结构
假设你在做一个爬虫，URL 去重是每天都要面对的问题。最直觉的方案是用 HashSet，但当地址库膨胀到十亿级，内存直接爆掉。有人就想：能不能接受一点误判，换来数量级的空间压缩？Bloom Filter 就是这个思路的产物。
它底层就是一个长度为 m 的位数组，全初始化为 0，再配 k 个独立的哈希函数。插入一个元素时，用 k 个哈希函数算出 k 个位置，全部置 1。查询时同样算出 k 个位置，只要有一个是 0，这个元素一定不在集合里——这是确定性结论；但如果全为 1，只能说"可能在"，因为那些 1 位可能被其他元素碰巧填上了。所以 Bloom Filter 的核心特性是：没有假阴性，但有假阳性。
这个"只可能多报，不会漏报"的性质让它特别适合做前置过滤器。Chrome 用它检查恶意 URL，Cassandra 用它减少磁盘 IO，Bitcoin Core 也用它在节点间同步时先过滤不需要的交易块。当 Bloom Filter 说"不在"，你就可以完全信任这个判断，直接跳过后续操作；只有当它说"可能在"时，才需要去精确数据结构里二次确认。
空间效率有多夸张？1% 误判率下，每个元素只需要约 9.6 bit，对比 HashSet 的几十字节，差了两个数量级。误判率随 m 增大而下降、随 n 增大而上升，k 的最优选择大约是 (m/n)·ln2，这可以从最小化假阳性概率的推导中得出。
Bloom Filter 最明显的短板是删除困难——把某元素对应的位清零会影响其他共享这些位的元素。一个工程上的修补方案是 Counting Bloom Filter：把每一位扩展为计数器，插入加 1、删除减 1，代价是空间膨胀到原来的 4 倍左右。另一个方向是 Cuckoo Filter，它支持删除且在低误判率下空间更优，不过最坏情况插入复杂度更高。 还有一个常被忽略的性质：多个相同参数的 Bloom Filter 可以直接按位 OR 合并，非常适合分布式场景下各节点独立构建后再汇总。
#CS
假设你在做一个爬虫，URL 去重是每天都要面对的问题。最直觉的方案是用 HashSet，但当地址库膨胀到十亿级，内存直接爆掉。有人就想：能不能接受一点误判，换来数量级的空间压缩？Bloom Filter 就是这个思路的产物。
它底层就是一个长度为 m 的位数组，全初始化为 0，再配 k 个独立的哈希函数。插入一个元素时，用 k 个哈希函数算出 k 个位置，全部置 1。查询时同样算出 k 个位置，只要有一个是 0，这个元素一定不在集合里——这是确定性结论；但如果全为 1，只能说"可能在"，因为那些 1 位可能被其他元素碰巧填上了。所以 Bloom Filter 的核心特性是：没有假阴性，但有假阳性。
这个"只可能多报，不会漏报"的性质让它特别适合做前置过滤器。Chrome 用它检查恶意 URL，Cassandra 用它减少磁盘 IO，Bitcoin Core 也用它在节点间同步时先过滤不需要的交易块。当 Bloom Filter 说"不在"，你就可以完全信任这个判断，直接跳过后续操作；只有当它说"可能在"时，才需要去精确数据结构里二次确认。
空间效率有多夸张？1% 误判率下，每个元素只需要约 9.6 bit，对比 HashSet 的几十字节，差了两个数量级。误判率随 m 增大而下降、随 n 增大而上升，k 的最优选择大约是 (m/n)·ln2，这可以从最小化假阳性概率的推导中得出。
Bloom Filter 最明显的短板是删除困难——把某元素对应的位清零会影响其他共享这些位的元素。
#CS
当你的 SSH 密钥不再只属于你：SSH Agent 转发的隐性代价
很多人日常用 SSH Agent 转发（
更隐蔽的是，攻击者不需要偷走你的私钥文件。他只是"借"你的 agent 做签名，私钥从头到尾没离开过你的笔记本。这就像你把家门钥匙扣在了门外的锁匠窗口——钥匙还在你手上，但任何人都能让锁匠用你的钥匙开锁。
实际攻击链是这样的：攻击者先拿下跳板机，找到
替代方案有几个：用 ProxyJump（
思考：如果你的跳板机被植入了一个每隔 5 分钟就遍历所有 agent socket 尝试连接的内网主机的 cron job，你怎么检测到这种慢速横向移动？
#Security
很多人日常用 SSH Agent 转发（
-A 参数）跳板登录内网机器，图的是方便——本地密钥不用拷到跳板机，看似很安全。但问题出在转发之后的那段路上。当你启用了 Agent 转发，跳板机上会开一个 Unix domain socket，任何能访问这个 socket 的进程都可以让你的 agent 签名认证请求。这意味着如果跳板机被攻陷，或者上面有个恶意用户拿到了 root 权限，他可以直接通过这个 socket 用你的身份去连接任何你授权访问的机器，而你全程无感知。更隐蔽的是，攻击者不需要偷走你的私钥文件。他只是"借"你的 agent 做签名，私钥从头到尾没离开过你的笔记本。这就像你把家门钥匙扣在了门外的锁匠窗口——钥匙还在你手上，但任何人都能让锁匠用你的钥匙开锁。
实际攻击链是这样的：攻击者先拿下跳板机，找到
/tmp/ssh-*/agent.* 这样的 socket 文件，然后 SSH_AUTH_SOCK=/tmp/ssh-xxx/agent.xxx ssh target.internal，直接以你的身份登录下一个目标。在大型内网里，一个高权限用户的 agent 转发足以横向移动到大量服务器。替代方案有几个：用 ProxyJump（
-J）代替 Agent 转发，它只在本地建立隧道，不在远端暴露 socket；或者用 SSH Certificate 配合短时效证书，限制横向移动的窗口；再或者直接跳板机上加 AllowAgentForwarding no 从服务端堵死。#Security
「にかかわらず」和「にもかかわらず」差一个字，差一个语气
读论文的时候经常看到「にもかかわらず」这个表达，很多人会把它和「にかかわらず」混在一起用。这两个长得确实像，但逻辑方向完全不同。「にかかわらず」是逆条件——不管A还是B，结果都一样。比如「国籍にかかわらず平等に扱う」，不管你是哪国人，待遇相同。这里A和B是对立的两种情况，而结果不受影响。而「にもかかわらず」是让步——明明有A这个不利条件，结果却还是B。比如「警告を受けたにもかかわらず再犯した」，明明被警告了，还是再犯。前者是"不管怎样都"，后者是"明明这样还"。
写学术文章的时候区分其实很直觉：如果你的句子在说"无论X如何，Y都成立"，用「にかかわらず」；如果你的句子在说"尽管X，Y依然成立"，用「にもかかわらず」。最简单的判断方法是看能不能替换成"尽管"。能替换的就是にもかかわらず，不能的就是にかかわらず。
来想一个问题：「雨にかかわらず試合を行う」和「雨にもかかわらず試合を行う」，哪一句听起来更自然？「雨にかかわらず」稍显不自然，因为"雨"不是对立的两种情况，一般说「雨にもかかわらず」（尽管下雨）。而「天候にかかわらず」就很自然，因为天候包含晴雨等多种对立情况。
#日本語
读论文的时候经常看到「にもかかわらず」这个表达，很多人会把它和「にかかわらず」混在一起用。这两个长得确实像，但逻辑方向完全不同。「にかかわらず」是逆条件——不管A还是B，结果都一样。比如「国籍にかかわらず平等に扱う」，不管你是哪国人，待遇相同。这里A和B是对立的两种情况，而结果不受影响。而「にもかかわらず」是让步——明明有A这个不利条件，结果却还是B。比如「警告を受けたにもかかわらず再犯した」，明明被警告了，还是再犯。前者是"不管怎样都"，后者是"明明这样还"。
写学术文章的时候区分其实很直觉：如果你的句子在说"无论X如何，Y都成立"，用「にかかわらず」；如果你的句子在说"尽管X，Y依然成立"，用「にもかかわらず」。最简单的判断方法是看能不能替换成"尽管"。能替换的就是にもかかわらず，不能的就是にかかわらず。
来想一个问题：「雨にかかわらず試合を行う」和「雨にもかかわらず試合を行う」，哪一句听起来更自然？
#日本語
This media is not supported in your browser
VIEW IN TELEGRAM
📸 @nisiosazane ×3
こんな動画見つけましたが長いので3つに分けました
めちゃくちゃ可愛いですね✨
動画内で言ってる「加藤小夏らしい女優になる」は本当に叶ってますね☺️ #加藤小夏
原文 #加藤小夏
こんな動画見つけましたが長いので3つに分けました
めちゃくちゃ可愛いですね✨
動画内で言ってる「加藤小夏らしい女優になる」は本当に叶ってますね☺️ #加藤小夏
原文 #加藤小夏