开幕致辞

这次的建立内容站来的很突然。从这周的This Week in Rust上读了一篇文章，然后就不由自主地被它的主题吸引了。虽然看了一下然后发现它还是做了一些定制化，不过原版也足够令我感到愉悦了，于是就像中了魅惑一样创建了这个站出来。

嘛，最近真是越发变成自己都不认识的样子了。

设立内容站这件事，对我来说一直以来最大的困扰在于出于什么目的去写。以往写了几天就不写了，因为写的东西总是挺吃灵感的，而我的灵感又总是萦绕个几天就消失不见许久。上一个内容站的企划干脆就是纯粹点子记录合集，这玩意能长此以往地写下去就见鬼了。

于是这次我给自己找的主题是工作总结。不至于每天总结一次，但是每当一组工作告一段落的时候就可以登记一下。

当我（极偶尔地）回看以前写的内容时，最大的感触常常是出自对于自己过去所做的事毫无印象。这并不需要我对自己当时所作的事做多么有深度地加工，只是平淡无奇地把它们记下来，就足以让以后的我读到的时候感到满足了。

不会再像现在的我在回想本科早年间都做了什么的时候，因为什么也没记，连代码都删光了，而束手无策。

碰巧昨天𝒦跟我提起她的工作记录，说自从不用纸质记录了以后就混乱了起来。让我也来试试这到底能不能行得通。

---

最近也许真的也该记一记了。

长期以来有一种没有根据的感觉，不准确的描述是，我不管选择做什么事都是正确的选择。就算我在ddl之前摸鱼，那也是正确的选择，因为一方面这不会让我赶不上ddl（真的吗），另一方面通过这些摸鱼所收获的（是什么呢）总会在未来某个时候派上用场。最重要的是，凡是我需要做的，最终总会及时地做完的，不管我有没有优先去做它（多半是没有）。

最近这种感觉开始消失了。更确切地说，我开始反过来觉得，我对于做什么的选择很可能不是很理想。比如现在，相比写这个，我大抵是有着更应该做的事情的。

如果我转而做了更重要的事，也许我就再也不会在这写这个，那么也就是说写这个并不是一个早晚会轮的上的事。

那么更糟糕的，如果我做了一件本不一定会轮的上去做的事，也许就会让一件更应该做的事再也轮不上了。我不再觉得每一件想做的事最终都会轮的上了。

于是，时时记录哪些事情轮着（zhao）做了，然后扫一遍还没轮着的事情里面有没有什么需要抓紧的，就变得有些必要了。

无论如何，但愿这些只是我对于生活中新状况的些许不适应带来的一时错觉。任由自己想到什么就做什么的日子过起来还是要轻松得多的。

愿望单

我的上一个内容站企划采用了自研构建工具的方案，一方面也是想借此培养对那个站的感情（从结果上而言因为增加了太多麻烦而磨灭的感情要多于培养的），另一方面也是达到绝对的自由度，可以让它有着完全符合我需求的设计和功能。

上一个站最与众不同的设计是以卡片/便签作为内容的基本单位而不是相对长篇而完整的文章，从而希望以此督促我写出更短小精炼的段落。实际体验下来有点太打乱连续书写的节奏了，所以舍弃了也罢。

不过它带来的一个特色——为一小段「暴论」专门生成的「分享」式的页面，我还是挺留念的。我总是把内容写得很长，这种页面对于不喜欢/没必要读大篇幅内容的受众来说很合适。

这就是最主要的一个想要的功能了。目前的计划是给Jekyll上面糊一点把它实现出来，比如写个内容预处理脚本，为每一段话的页面自动生成一个承载的内容源文件，然后对接Jekyll按照原本的方式生成出来。与此有着类似解决思路的一个需求是我总是觉得创建新内容的时候手动填时间很麻烦，于是找了个脚本来一键创建，就觉得挺满意了。

我在上一个站实现的另一个功能是隐藏页面。会被渲染，但是不能从主页出发通过点链接抵达的页面。说实话我也说不清楚想要像这样掩耳盗铃是因为什么，就是一种癖好罢了。我怀疑这个可以用Jekyll的scope配置来实现，不能的话大概也可以写个简单的后处理脚本去藏一些链接来实现。

最后就是我还研究了一阵子怎么配置一套跨平台的衬线/宋体字方案。比预想中要麻烦，有点知难而退了。

那么就从这里开始

上面提到的那篇我觉得很赏心悦目的文章启发我（又）去读了一遍Zig的comptime文档。然后顺着读了一篇文章，批评Zig的comptime并不是一个完美无缺的设计。

我之前有设想过类似的类型系统/编译期计算设计，同时也为现有的语言把编译期和运行时两套运算的语法表达设计得这么不统一而感到不满。这篇文章实打实地消除了很多这种不满，引发我开始重新思考一门专为编译期计算设计的，更加受限也具有更多属性的语言应该如何设计。

为了接下来的阅读组重新读了SquirrelFS。又进一步为了补充背景知识读了Soft Updates。还没有彻底理解透，但是大体上对于采用软更新的动机逻辑搞清楚了。

给「形式化验证动态成员网络系统」的课题想法写了第一份笔记，暂且的代号为p2pcert，模仿compcert。这显然会是个很吃代码量的项目，然而更大的挑战是，我还没搞清楚想要把它推进到可以开始写代码的程度我还需要做些什么。

对于entropy的后续工作内容，ℒ指出我们得找到/设计出具体的估计存储网络规模的方案填进去，我指出我们需要写个更（或者说能算是）严谨的证明，以及对于编码再探索一下有没有改进的机会。目前这个做法在冗余度上面的膨胀以及其对于整个系统造成的设计冗余让我还是有点不舒服。

对于cover接下来的计划，我在考虑能不能/有没有必要把它做成一个高度围绕着zk技术的应用式的工作（zk for system?）。一种给系统社区写一个zk showcase的感觉。ℒ觉得想法可以但是工作量将会巨大。我也觉得。

跟𝒦聊了一些脉冲神经网络，有些鲁莽地得出了一个「这个领域继续发展最大的瓶颈就在于缺乏一门好的编程语言」的结论。准备再多了解一些关于脉冲神经网络的背景，使用例和用户需求，并且找找看有没有前人的工作参考一下，最好是可以直接拿来在其基础上改进。

需要看一下XLA的资料。现在就去看吧。