1. Zlibrary官方开通了 Telegram 频道。
https://t.me/zlibrary_official
2. 因为私人明网域名的出现,Zlibrary 明网镜像也出现了(不能登录,只能下载)。
https://zlibrary.cf/s/
ref:https://bbs.yibook.org/d/927-wo-men-zhao-dao-liao-zlibrary-zui-xin-jing-xiang-wang-zhan
btw,在 Reddit 上看到有人提出应该让zlib的工作人员获得诺贝尔和平奖,我举双手赞成!
https://r.nf/r/zlibrary/comments/10qgyi7/the_folks_working_on_zlib_deserve_a_nobel_peace/
《“不ooc”最终如何变成了寓言——一部错误的历史》
1.不ooc的世界,作者、原作粉丝和深刻理解原著的同人女可以达到——她生活于其中,她就是它。
(标准的最古老形式,比较巧妙、简单、令人信服。是下述命题的改写:“我,阅读原著八遍以上熟悉每一个人物性格行为和心路历程,就是不ooc。”)
2.不ooc,现在无法达到,但许诺给作者、原作粉丝和深刻理解原著的同人女(“许诺给忏悔的创作者”)。
(标准的进步:它变得更精致、更困难、更难以理解——它变成了纸片,它变成了二次元式的……)
3.不ooc,无法达到、无法证明、无法许诺,但被视为一个安慰、一个义务、一个律令。
(其实还是旧的太阳,只不过被浓雾和怀疑笼罩着;标准变成了崇高的、苍白的、北方式的、恶魔证明式的。)
4.不ooc——无法达到吗?总之未达到。未达到的也就是未知的。因此,也就不能是安慰性的、拯救性的、有约束力的;某种未知的东西怎么可能让我们对其尽义务呢?……
(天蒙蒙亮。叛逆同人女的第一个呵欠。后现代的鸡叫。)
5.“不ooc”——一个不再有任何用处、不再有任何约束力的标准,——一个变得无用的、多余的标准,因而是一个被驳倒的标准:让我们废除它!
(大白天;早餐;好的感觉(bon sens)和愉快心情的回归;原教旨原作粉丝的脸红;一切自由灵魂起哄。)
6.我们废除了不ooc的世界:剩下的是什么世界?也许是ooc的世界?……不!随着不ooc的世界的废除,我们同时废除了ooc的世界!
(正午;阴影最短的时刻;最长的错误的结束;人类的顶点的开始。lofter热度榜前三同人文免责的开头词。)
致谢:普鲁士大喷子尼采(最美的胡须奖获得者之一)
(主要是概括加逗乐啦!
写论文
参考的文献有讲古代对于海洋生物的一些描写,觉得挺有趣的……个人觉得这方面应该是属于民俗学的领域了?就是有关“迷信”方面的东西。先人对于迷信对象/行为与所处的世界建立起联系,想要通过建立一套可供追溯的证据链,来更深刻地了解神秘的自然的这种努力,最终就会以瑰丽奇妙的想象呈现出来。
刚看到淮南子·览冥的一句:“东风至而酒湛溢,蚕咡丝而商弦绝……画随灰而月运阙,鲸鱼死而彗星出,或动之也。”意思是:东风到来酒就会涨多,蚕吐丝琴弦就容易断裂……用草灰在月光下画圆而有缺角,月晕便会出现圆缺,鲸鱼死于海滨,天空就会有彗星出现。
而有关“鲸鱼死而彗星出”的说法,在其他不同的史书也有记载,“鲸鱼死,彗星合”“海精死,彗星出”之类的。鲸鱼跟彗星当然是不可能有因果关系,所以可能是第一次被观测到的时候,一只鲸鱼在海岸边搁浅了,此刻刚好天空划过一颗流星,之后不久又发生了国家性的动荡。于是之后就被当作一组可作参考的范本记下来。emmm我也不知道能不能表达出来,但就是觉得“第一次被观测到的,死去的鲸鱼和彗星,灾祸”这几个词组组合在一起,好奇妙好浪漫啊...... ![]()
安娜:最近一直作为Z-Library替代的网站,她是整合Z-Library、Library Genesis、Sci-Hub等网站资源的搜索引擎,尤其下载是无限制的,不过有时候比较缓慢。
她的主页有一个不知从何而来的、动人的进度条: 5% 的人类书面遗产得到永久保存。这赋予我每一次下载以人类的尊严。
#长毛象安利大会
https://zh.annas-archive.org/
https://ent.creaders.net/2023/01/29/2571900.html 这篇里“孤注一掷的赌博式大计划”的分析非常一针见血了,也指出了计划主义的死穴:计划本身没问题,但如果计划完了倾家荡产一路走到黑就是大问题。
感觉我的码农经验能帮助解释这一点。一个sophisticated的developer最重要的skill不是对某种代码语言的熟悉程度,不是对数据结构/算法的掌握,不是一遍过写代码的效率和质量,甚至不是设计一个完美solution,而是从一个还不知道怎么做的project requirements生成一个flexible plan——既要有大体的规划和估计(不然manager和client要跳脚),又要留有足够的松动/灵活去处理之后肯定会出现的各种surprises,然后在过程中不断wayfinding。见过太多那种先计划好一个完美solution然后倾尽所有资源去做但到一半发现有大问题却已经骑虎难下的尴尬。而真正有效率的开发方式是看似一开始很慢很浪费的那种:prototyping -> MVP -> beta -> alpha -> production。每一个stage都会积累到新的经验和信息去修改计划和校正下一个iteration的方向,而这些是绝不可能最初就知道的,也因此千万不要上来就搞一个没法中途不断去改的“终极计划”。Uncle Bob的software architecture讲座里有一个概念我一直印象深刻:尽量延迟去做没法回头的高代价决定,延后越多你手上就有越多信息帮助你去做更好的决定;在开发早期要尽量去把高代价决定替换为低代价决定。(P.S. 这种开发方式看似每一个stage都会有比较高比例的代码重写,但这种improvement式的重写比搞错solution需要推倒重来要的重写轻松&快速太多)
并不是所有时候都有足够的资源可以完全平行地“把鸡蛋分散到许多篮子里”,但即使是计划也并不必须是那种世界未来皆我所知的傲慢计划,恰恰相反,从做第一版计划的时候就要预见到它必然会随着实施一路被改到妈都不认识,允许被不断修正的计划才是真正的好计划。
喜欢读书的uu们注意啦!
Z-Library 私有域名上线啦!!!
只要以前曾经捐赠过或者现在捐赠,登录后自动会跳转到分配给你的私有域名。毕竟是私有的,没被墙和难以被墙简直理所当然。
ps:希望它能活得久一点
Z-Library登录地址(被墙):https://singlelogin.me
菩薩清涼月,游于畢竟空。