The Physicists’ Club

0. 问题现象 本来在Android用得是KeePass2Android, 可惜passkey功能到现在(20260907)都没上正式版, 暂且换为KeePassDX, 除了没有云端同步以外体感没区别. KeePassDX passkey功能在ColorOS手机测试正常, 但在HyperOS测试异常 设备环境: Xiaomi 14 Pro Android 16 / 国行 HyperOS 3 KeePassDX 包名: com.kunzisoft.keepass.free 在 HyperOS 3 设置中已经将 KeePassDX 选择为密码/凭据服务, 但 Firefox、Chrome 等浏览器访问 WebAuthn 网站时, Android 仍然无法调用 KeePassDX, Passkey 注册会提示Registration ceremony was sent an abort signal. 1. 确认 ADB 已连接手机 本文不展开 ADB 安装及 USB 调试配置, 确保执行 adb devices 能正常识别手机即可. 2. 查看当前 Credential Provider 执行: adb shell settings get secure credential_service adb shell settings get secure credential_service_primary 输出 ...

引言 联通很是抠门, 1000Mbps的网只给了个1000Mbps并且性能十分羸弱的光猫, 跑PT只要速度高一点点, 光猫和路由器之间的延迟就开始飙升. 于是想将光猫改为路由器桥接拨号, 互联网上关于这款光猫获取超密的信息很少, 只在恩山找到一篇拆机光猫后使用ttl来获取超密的教程, 但相信大多数人没有这种设备. 之前在咸鱼花20块钱买过一次远程获取超密服务(后因跑PT限速被运维上门重置光猫超密失效), 观看其操作, 只是远程我的电脑打开了一个CLI程序, 证明超密获取不需要使用任何外部物理工具, 经过一晚上折腾(晚上睡觉前折腾网络是大忌), 得到了在不拆解光猫, 不借助任何外部物理工具的情况下获取超密的方法. 提示: 本教程可能仅针对部分省份生效. 虽然本文为SG631Z, 但对于其他部分光猫可能有效. SG631Z使用的是sidbg, 其他光猫用的可能是sendcmd, 自行替换命令即可. 1. 网页直接获取超级密码(推荐) 推荐本方案, 无需重置光猫和操作telnet. 根据评论区uflr提到的恩山帖子, 可以直接在user用户下访问 http://192.168.1.1/hidden_cmd.gch?pwd=aDm8H%25MdA 来到这个界面, 此界面相当于telnet登录后su的命令界面, 输入 sidbg 1 DB decry /userconfig/cfg/db_user_cfg.xml && cat /tmp/debug-decry-cfg | grep -A 12 DevAuthInfo 即可获取超级密码 Pass行即为超级密码. 2. Telnet方式获取超级密码 如已经通过网页的方式获取到超级密码可忽略本章节. 开启Telnet并固化 首先使用光猫背面记录的账号密码登录光猫后台, 记录loid和password, 以让我们重置光猫后可以重新注册. 现在联通的光猫用户名和超级密码在手动重置光猫并且未连接光纤的情况下多数情况下是 CUAdmin CUAdmin 基于此, 我们可以在未连接光纤(准确说是运营商未云端下发配置)前将Telnet固化, 使得运营商即使远程下发了新的配置, 我们也可以获取新的超密. 首先断开光纤连接, 长按光猫后面的reset按钮大概20s, 等待所有指示灯熄灭并且重新闪烁后, 松开. 此时使用上述的用户名,密码登录. 在登录后的的界面地址栏输入 http://192.168.1.1/getpage.gch?pid=1002&nextpage=tele_sec_tserver_t.gch ...

引言 在进行TCP下载的时候, 观察网络, 会发现同时会有"很大"的上行, 比如我的Steam下载 下载速度大概为1000Mbps的时候, 我会产生20Mbps的上行. 同时qBittorrent的[Options]-[Speed]中有一个选项[对传送总开销进行速度限制] 在开启了这个选项, 并且设定一个小于你最大上行的速度限制后, 会发现当你下载速度变高后, 其他种子的上行会随之降低. 这些现象为什么发生, 是本文要探讨的内容. TCP 无论是HTTP下载, 还是BT下载, 所依赖的都是TCP协议. 要了解上述现象, 就要先了解这些行为所依赖的协议. 根据RFC的定义, 当我们下载的时候, 每当Server端发送给我们一个TCP报文段, 我们就要回应一个没有数据的TCP报文段(ACK) 表示已经完全收到并请求下一个报文段(暂且不考虑Cumulative Acknowledgment和Delayed Acknowledgment). 举例 具体举例来说: 本地网络设置的MTU是1480, 则Server端TCP报文中, IP头+最大的数据量=1480. 使用iperf3进行测试(IPv4) Server端发送给我们的内容则为: 名称 报文大小 说明 数据(Payload) 1480-32-20=1428 MTU限制了最大数据 IP头 20 IPv4 TCP头 32 因为包含了OPTION, 所以变大了 Eth头 14 目标MAC, 源MAC, 以太网类型 FCS 4 帧校验序列 则我们接收到的一个以太网帧大小为MTU+ETH头+FCS(帧校验序列)=1480+14+4=1498Byte. 我们的ACK只会包含TCP头,IP头,Eth头, 而不会包含数据, 所以ACK的大小为32+20+14+4=70Byte. 则我们的上行速率会是实际下载数据速率的$\frac{70}{1498}=4.672897196 \%$ 这是在每一个ACK包都对应了一个TCP包情况下的最大占用上行. 在实际的网络请求中, 我们会有累积确认 (Cumulative Acknowledgment)和延迟确认 (Delayed Acknowledgment), 这两种机制会使得我们的ACK包的数量小于接收到的TCP包的数量. ...

引言 无论是在中文论坛还是英语论坛, 都会看到一个说法 即如果第一个怪物是Cultist(邪教徒Kakka), 则有80%的概率, 你的下一个事件(问号)会变成战斗, 导致你无法使用捏奥的悲恸白嫖到精英. 这个让我很是奇怪, 在我之前的认知中, 杀戮尖塔遇到什么怪物, 问号碰到什么事件, 都是已经注定好的行为, 为什么会有Bug会让第一支怪物, 影响到后续的问号事件呢? 所幸杀戮尖塔是用Java写的, 所以我们可以很直接的反编译他的Jar文件, 看到源代码 源代码获取方式 打开杀戮尖塔文件夹, 里面会有一个名为desktop-1.0.jar的文件, 使用任意反编译工具即可获取源代码. 这里我使用的是JD-GUI, 将其解析之后获得到源码 生成怪物和事件的关系 生成怪物 其中生成怪物的代码在desktop-1.0.jar.src\com\megacrit\cardcrawl\dungeons\Exordium.java protected void generateMonsters() { generateWeakEnemies(3); generateStrongEnemies(12); generateElites(10); } 这里是Exordium, 即第一章序幕也就是第一层, 会生成3个弱怪, 12个强怪, 10个精英. 这里可以证明, 3个弱怪之后就是强怪池. 其中生成弱怪的代码 protected void generateWeakEnemies(int count) { ArrayList<MonsterInfo> monsters = new ArrayList<>(); monsters.add(new MonsterInfo("Cultist", 2.0F)); monsters.add(new MonsterInfo("Jaw Worm", 2.0F)); monsters.add(new MonsterInfo("2 Louse", 2.0F)); monsters.add(new MonsterInfo("Small Slimes", 2.0F)); MonsterInfo.normalizeWeights(monsters); populateMonsterList(monsters, count, false); } 其中MonsterInfo中, 第一个参数为怪物名称, 第二个是生成权重, 这里面四个怪物的权重是一样的, 所以理论上生成的概率是相同的. ...

问题Problem 在codility看到的题目, 题目内容如下 题目内容 英文题目 A non-empty array A consisting of N integers is given. A pair of integers $(P, Q)$, such that $0 ≤ P < Q < N$, is called a slice of array A (notice that the slice contains at least two elements). The average of a slice $(P, Q)$ is the sum of $A[P] + A[P + 1] + … + A[Q]$ divided by the length of the slice. To be precise, the average equals $(A[P] + A[P + 1] + … + A[Q]) / (Q − P + 1)$. ...

引言 之前只是看书的时候看过Python多继承的MRO顺序, 从来没在代码里面具体实践过, 今天终于遇到了一次. 在写NWU.ICU的过程中, 有课程评价一项, 建立Model的时候, 为了实现标记删除, 继承了自定义的SoftDeleteModel模型, class Review(SoftDeleteModel): .... pinyin = models.TextField(verbose_name='拼音', blank=True) search_vector = SearchVectorField(null=True) objects = SearchManager() SoftDeleteModel如下 class SoftDeleteManager(models.Manager): def get_queryset(self): return super().get_queryset().filter(is_deleted=False) class SoftDeleteModel(models.Model): is_deleted = models.BooleanField(default=False) deleted_at = models.DateTimeField(null=True, blank=True) objects = SoftDeleteManager() all_objects = models.Manager() def soft_delete(self): self.is_deleted = True self.deleted_at = timezone.now() self.save() soft_delete_signal.send(sender=self.__class__, instance=self) def restore(self): self.is_deleted = False self.deleted_at = None self.save() class Meta: abstract = True 概括就是删除的时候标记is_deleted为true, 并且重写了get_queryset方法, 使得model.objects.get()时, 让已被标记删除的数据不被查询到. 这本来工作好好的, 但为了引入拼音模糊搜索功能, 我在Review模型, 加了几行, 也就是上文里面的 pinyin = models.TextField(verbose_name='拼音', blank=True) search_vector = SearchVectorField(null=True) objects = SearchManager() 使得我的model.objects.get()一直可以获取到已经被标记删除的数据. 解决方案 其中SearchManager如下 class SearchQuerySet(models.QuerySet): def search(self, query, query_table_name): ... class SearchManager(models.Manager): def get_queryset(self): return SearchQuerySet(self.model, using=self._db) def search(self, query, page_size=10, current_page=1): ... search_results = self.get_queryset().search(query, query_table_name) return ... 原因很明显, objects = SearchManager()中get_queryset的覆盖了我在SoftDeleteModel定义的objects的原有方法. ...