纵使有千言万语欲与诉说,坐到电脑面前便一个字也不想打。
放一个 Ujico*/Snail’s House 前几天的曲子吧。Magical Holiday。因为暂时上不了 SoundCloud,就放 Youtube 上的视频吧,也很漂亮。
另外,在点 Profile 的时候请戴上耳机。
别的留给新年再说吧。
纵使有千言万语欲与诉说,坐到电脑面前便一个字也不想打。
放一个 Ujico*/Snail’s House 前几天的曲子吧。Magical Holiday。因为暂时上不了 SoundCloud,就放 Youtube 上的视频吧,也很漂亮。
另外,在点 Profile 的时候请戴上耳机。
别的留给新年再说吧。
I had a dream.
It’s the two of us. Beside the river. Orange light flickered in the water. Grass whirled up in the summer breeze.
Continue reading今天没打游戏。
磨了一点 Your Diary 的感想,就没动了,买了另外一本三秋的书,加上一本书凑免邮。反而是看纸城境介的继母的拖油瓶是前女友看到快 6 点。
很有趣的小说。男性向的。
因为看轻小说不用带脑子,所以这也是不带脑子的评论。这也是我的一种心理安慰。一个人如果因为一本无趣的小说而熬夜,那未免也太空虚了吧。
在访谈中,关于连载,作者纸城大致是这么说的:如果小说被印刷成书出版,那只能让读者享受 3 小时;而如果放在网络上连载,则能够让读者每周都享受 168 小时。
关于这部书有趣的地方,作者大致是这么说的:我写这部作品,就专注于这一点,而不是加入学园祭等各种元素来充实内容,这使得这部作品非常纯粹。
因为我记的不太清楚了,所以就不加 quote 了。当然这也不代表我个人观点,虽然说人会把记忆改造成自己想要的样子,但我觉得这观点怎样都好,所以就忘的差不多了,更别说根据自己的好恶改造了。
我个人觉得误会是这部作品的一个支撑,也是全篇反复出现的一个要素。男女主人公因为小小的误会,关系出现了隔阂,导致最终的分手。男主自认为讨厌女主,但心里还给女主留着位置,他并努力和女主保持着适当的距离;而反观女主,男主在面前的时候针锋相对,不在面前的时候变身大花痴。导致怎么看,都是变相秀恩爱。
这让我想起了作品时间和现实时间同步的一部网络小说,其天气也是忠实于日本某地的天气。可名字忘了。
今天下雨。
看了一点人间失格,感觉不能理解。先不管三张相片是想表达什么(从内容上看推测是概括了主角的一生),几页看下来,大致是一位神经性厌食症少年的独白。具体是不是还要继续往下看。
我不摄影。
看了一篇关于 Magnum Contact Sheets 的博客,讲的很长很详细,地址忘了。
Contact sheets 是在底片时代,摄影师为了降低成本,就先把底片的缩小版印下来,再在其中挑选想要的照片。从 contact sheets 中可以看到摄影师的思考,过程,以及失败。Magnum 是有名的摄影师社区,其成员都是经过遴选的,因此这本书里的 contact sheets 也可算是大师级别的作品。
看到 Dali Atomicus 的时候,我以为里面的人是随便一个演员,结果一查是达利本人,而其创意也来自达利的画 Leda Atomica,里面的物体都是漂浮着的,在照片中该画被悬在右侧。照片里的猫也是真的,是助手丢出去的。大概那时候没有动物保护组织,可以随便来。照片一共拍了28次,可以说不管是摄影师,达利,打扫的人,还是猫都辛苦了,猫还会被水浇到,所以可能最辛苦。
总而言之,文章想对广大摄影爱好者表达的几点建议,一个是多拍,一个是拍了要看,一个是以前拍的也要看,说不定会有新的发现(因此不要立即删掉觉得不好的照片)。
方正面向移动端阅读,推出了方正悠宋。当然要钱,而且不能发布。因此我没用。当然如果遇到什么好的免费的衬线体,大概是会换的,不然英文是衬线,中文是黑体,不免有些不协调。
注:移动端是这样,电脑端可能不是这样。
Hymmnos 字体也会加回来的,大概。
其他的记不清了。
想不到要写什么了。
GitHub Pages 是 GitHub 不知道在哪一年推出的网站托管服务。用户将网站内容放在一个 GitHub 仓库中(无论仓库是公共还是私有的),然后喝口水的功夫,网站就建立起来了。
GitHub Pages 有如下几个好处:
用户可以通过如下的几种方式部署 GitHub Pages:
<username/org name>.github.io
的仓库作为网站的根目录 (webroot)master
或 gh-pages
分支作为网站的根目录master
分支的 docs/
文件夹作为网站的根目录在方式 1 下,默认可以通过<username/org name>.github.io
访问建立的网站;而在方式 2 和 3 下,默认通过 <username/org name>.github.io/<repo name>
进行访问。
除了给定的域名,GitHub Pages 还提供了自定义域名的选项,支持 example.com
和 www.example.com
形式的域名。具体看 wiki 。
通常来说,建一个博客需要如下几个部分:
使用网页托管服务,相当于用户交出了对服务器的完全控制,这有其两面性:用户可以不管什么阿帕奇,什么引擎X,但用户在服务器层面上能有多大的自由,完全取决于托管服务商的支持。
在 GitHub Pages 为例,用户失去了:
其实没怎么。
由于上一篇博客中做的修改,现在的 RSS 变成了一个到中文 RSS Feed 的 HTTP 重定向。用 GitHub Pages 会使得无法重定向,导致 RSS 订阅会掉。
另外一个没有提及的问题是 GitHub Pages 的罪恶连锁:
不使用
.github.io -> 自定义域名不能使用 CNAME -> 自定义域名使用 A 记录 -> 每次部署的时候报警
以及
不使用
.github.io -> 自定义域名不能使用 CNAME -> 自定义域名使用 A 记录 -> 随机 302
其中第二个问题是由于 GitHub 方面需要平衡负载而导致的。
再说。
之前没看懂 PAM 怎么用,今天重新看了一下pam(8)
,打算搞好之前想弄的 yubikey 解锁桌面。
看pam(8)
的结果:这在说什么?
看了一篇讲 PAM 的博客:噢,我明白了(没有懂),甚至应该修改 /etc/pam.d
下的哪一个文件都不清楚。
还是另一篇博客让我豁然开朗。
先在 Arch Linux 上安装yubico-pam
包。
然后修改/etc/pam.d/system-auth
,将下面一行添加到 auth required pam_unix.so ...
那一行的前面。如果添加到后面的话,还会先调用 pam_unix.so
来索取密码,而且失败了就失败了,并不能 fallback 到 Yubikey 登陆,然而将 sufficient
的 pam_yubico
放在最前,当 yubikey 验证成功了就一定成功。
如果写的是 required
而不是 sufficient
,结果就是不仅要 yubikey 验证成功,而且还要接着再输一遍密码,相当于倒过来的二步验证。
auth sufficient pam_yubico.so id=<yubikey API id> authfile=/etc/yubikeys |
这样就大功告成了!现在 sudo,解锁屏,登陆都可以用 Yubikey 一摁完成了!
当然,如果 KDE 的用户
/etc/pam.d/kde
里的对应位置,注意当前用户需要有 authfile 的读权限,否则无法使用/etc/pam.d/sddm
里的对应位置如果只想用 yubikey 登陆 console (估计没有这样的人),就把这一行放到 /etc/pam.d/login
里就行了,ssh类似,大概。
而如果想离线也能验证,或者嫌在线验证时间过长的话,就换用 challenge-response 模式就可以了。具体见 Yubico 官网的相关页面,就懒得再翻译一遍了。设置好之后甚至连一摁都不需要了。
Arch Wiki 关于 Yubikey 的条目可以说比较混乱,而 Fedora Wiki 的页面则较为简洁直白,可以作为参考。
顺便一提,也是 Fedora Wiki 告诉我有 modhex 这种东西。 Yubikey 作为键盘输入,它只会向机器发送键盘扫描码,机器再将其转换为按键。因此 Yubikey 不能控制键盘的 layout ,也就导致如果随意输入,在不同的键盘 layout 上可能会输出不同的字符。比如QWERTY的Y,在德语键盘上就成了Z(它交换了Y和Z),而在日语键盘上差不多就是假名 N (说差不多的意思是在假名输入下才是 N)。因此 Yubikey 选择了那些在任何键盘 layout 下都不会变的16个字符,用以表示16进制数,这就是 modhex 。
请关掉假名输入!不然そそそそそそりこはすいきまにすこまきましすいりそなままりこのかいそひひしきのにすきしのき
今天读了一篇关于硬件中断,以及如何用 PIC 处理的博文,因为没怎么看懂,就不翻译了。
Arcaea 潜力值终于上 9 了,或者说,才上 9 。啊……
慢慢来吧。
A progamer.
Student(probably)