EAC尼为什么挂惹

从家里背了几张砖回学校准备重新抓一下,把各种TAG填好以后准备抓,EAC就crash了。

反复数次以后确认在任何需要弹出确认保存位置的窗口的时候,EAC就会挂。

曲折地搜索了一番以后发现一位鬼佬给dokany提了一个issue。dokany是win下的一个fuse库,我当然没有装那玩意,不过之前耍rclone的时候装过类似的winfsp库,卸掉以后就正常了= =

寒假看的几个COC跑团实况

春节在老家还是一个人苟在外婆家小阁楼上,和全功率运行的取暖器以及几分钟断流一次的wifi作伴/w\

百无聊赖找了几部COC跑团实况看,简单记录一下。

狂気と茶番とクトゥルフと

好像几乎是规则书上的现成模组。欢乐向,还不错。

最適解

制作精良,剧情呵呵。

ゴールデン・スランバーを求めて

未完结,制作比较精良。套着COC团皮的11eyes,作为拉屎黑表示呵呵 但是RP还不错

楽しむことをあきらめないクトゥルフ『ピース・メイカー』

这作我觉得各方面都挺好哒,值得一看。

Compile qBittorrent 4.1.5 under Linux 3.16

最近稍稍速成了一些pt刷流的技巧,在此记录一点东西。

有时我们需要在比较旧(更精确地说,带着的内核比较旧。有时我们需要某个发行版下特定版本的内核)的Linux发行版下面跑比较新的bittorrent客户端(依赖高版本libtorrent的那些)。作为一个怕麻烦的人,我很自然地选择装一套gentoo-prefix。毕竟可以对各种依赖包的版本已经各种flag进行较好的控制,而且万一要打些patch也很方便。无非是编译会稍稍花点时间。

qbittorrent是我最常用的bittorrent客户端。虽然它对libtorrent的控制不如deluge那样开放,不过webui比后者强不少。

用官方脚本bootstrap已经不太容易出问题了。但之后会遇到一些问题(只要你尝试的时间不早于2019年1月)。

Boost库的路径问题

官方overlay里libtorrent-rasterbar和qbittorrent的ebuild可能是没有在gentoo-prefix下面测试过。这两个包的configure脚本鲁棒性不太好,在用gentoo-prefix的时候没法正确找到boost的位置,需要手动改一下ebuild,指定一下--with-boost--with-boost-libdir两个参数。

Qt5版本过高

如果你在比较新的内核(>=4.16)下尝试,上面的修改就足以编译出能正常工作的qbittorrent了。但在标题提到的3.16下面仍然不行,原因是最新的官方overlay里提供的是qt5.11.3,其中用到了Linux4.16引入的statx系统调用。所以我们需要找一个老版本qt的ebuild(以及对应的eclass)来用。我选择的是qt5.9.6,在18年6月到8月官方overlay的snapshot里都能找到。

然而qt5.9.6仍然不能直接编译成功。bootstrap完成的时候所安装的openssl是1.1.0分支中的较新版本,而qt5.9.6只兼容1.0.2分支。mask掉>=openssl-1.1.0然后重新编译相关的包即可。如果赶时髦换成libressl的话可以编译,然而许多用到ssl库的程序都会崩溃,原因是libressl似乎只支持3.18之后的内核。

具体的ebuild修改可以参考这里

Latest API for Chrome Data-Saver

背景故事

众所周知,批评空间(a.k.a. 黄油空间)很久以前就ban了自己国内的很多ip段。因为这个原因,我的主力跳板vps就打不开批评空间。如果专门为了上批评空间再长期维持一台主机显得有点蠢,换掉目前的主机的话又上不去dmm和dlsite。

容易发现使用google translate和chrome官方的“流量节省程序”插件能够打开黄油空间(的http服务)。说白了就是,google提供了一个访问非https站的http/https代理,能把各种http payload设法压缩以后再吐出来给客户端。使用这个http代理需要在request header里面加一点点东西,详情可以参考这里。因此长久以来的对策是,自己实现一个用compress.googlezip.net:80作为upstream server的正向/反向http代理服务器(当时是随手用go写了一下,主要的工作就是改http头)。自己供各种移动设备使用的squid http代理里给黄油空间设一条规则,以前面实现的正向代理作为upstream server。寝室的路由设好DNAT规则,目标是前述的反向代理。

……脆弱的日常

但是这个办法在昨天(2018年11月16日)失效了。开启chrome的data saver插件浏览网页抓包可以发现,request header里新加的东西变成了这样。

Chrome-Proxy: s=CjAKEwiP6rXAs9veAhUJOJYKHcVMC2oSDAiIr8XfBRDJ1vu3ARoJCgdkZWZhdWx0KAESRjBEAiA7u3cwWjYlau6BbSn8yRW07agXrQFa2Skphk0RjOmFxgIgfzPBKBcVuQddUOL-F93AkwAZPaDmN1BuwmkwkLK3e5c=, c=win, b=3538, p=102

严格地说,并不是变成了这样。似乎高版本的chrome至少从2016年开始的行为就是这样的了,应该是最近google的服务器开始拒绝旧版本的header(sid=xxxx)了。

某reddit网友反映,这个s=xxx的key每过一天就会更换。

Continue Reading...