Author: fivestone

  • 我喜欢

    大概我们每个人,哪怕三观再正的人,应该都经历过:一些自己真的有在喜欢的东西,可能是「不正确」的,由此产生的内心冲突和纠结。 这个内心冲突的过程,可能会很难受,而且很可能没有确定的答案。——很多时候,是选择继续喜欢下去的,因为从「喜欢」变得「让自己不喜欢」,其实是个很玄学,很难做到的事情。于是只能喜欢且痛苦着,或者让自己把那些痛苦的思考,渐渐无视遗忘。 也可能,通过反思,真的能让自己对以前喜欢的东西祛魅,从此对它没啥感觉。——(其实很多时候,是被「反思成功」的成就感所掩盖……)。但失去了一个兴趣,也是很难受的事,尤其是周围还有很多人,仍然把这个当作兴趣,甚至是日常交流沟通的话题的时候。 也有很多时候,是脱离了二分法,就这么在二者之间悬浮着。因为那个「不正确」的事情,是否 100% 不正确,有没有好的一面,通常也是可以辩论的……以及,这个发现「不正确」的过程,可能是自己渐渐觉悟到,也可能是别人硬戳过来,说你喜欢这个不对。于是又涉及维护面子;或者先声讨对方的态度…… 这些都是可以理解,可以接受的反应。——甚至连艰难地无视,也可以说是合理的。因为,如果避开那些「不正确」背后的,错综复杂到无法撼动的因素和体系,而单纯要求你拿出一个面面俱到的态度,这本身也是一种不公。 但至少不要—— 因为「我真的喜欢」,所以理直气壮地认为这东西没有问题。 「我喜欢」,从来都不是「这个东西是正确的」的理由。一方面,你之所以喜欢它,可能已经是某种糟粕文化的后果。另一方面,同样的事物或行为,不同环境下人们对它的感受是不同的。就像跳脱衣舞或者买芭比娃娃,可能在你的环境下,它真的意味着个性、张扬、多样性;而对其它很多人而言,也确实是剥削、是凝视、是痛苦的印象。那么,这东西的合理性,是否因此对你就没那么理直气壮? 如今的很多争吵,大概都源于某种「我的个性自由不应被阻挡」的态度。但很多事情,是需要在微妙地平衡中,甚至是在让自我痛苦的过程中,才能更好形成的。 就像恋爱脑爱上了渣男。尽管会为此而痛苦、犹豫,最终可能选择爱或不爱,但毕竟是清楚他是个渣男的;而不是拼命要去说服他并不渣呀。

  • 写作工具

    为了写长篇论文,整理各种散碎的构思和素材,尝试了一圈现有的写作工具。把体验的过程记一下。 先说结论。符合刚需,可供选择的,只有下面这几个。目前的考虑次序是: 参考过,因为不满足刚需被淘汰的: 有一些我知道但没有去试的,譬如 IA Writer。以及这些年似乎有很多,给网文作者开发的写作工具,就不去一个个试了。毕竟我只是要找个自己能用的,而不是做这方面的全面评测。 不在意的要素: 首先,我寻找的这个工具,是为了一个特定的写作项目,而不是日常泛泛的信息管理。所以,一些对于后者而言,很重要的功能,我是不需要考虑的。 一些对我而言的刚性需求: 一些不是刚需,但会是我选择的重要因素: 其它可有可无的加分项: 六种工具的横向比较。空白的是我还没仔细看的。 Scrivener Lattics 思源 Manuskript CherryTree Joplin 界面 ★★★ ★★★ ★★★ ★★ ★ ★★ markdown x √ √ x x √ 内部链接 √ √ √ x √ √ 分屏 √ √ √ √ x x 切换项目 √ x √ √ √ x 外部编辑器 x…

  • 机场

    看到 Richard Russell 在西雅图机场偷着开飞机上天的事件,也被一些女性讨论者,总结成「男蛆偷飞机造成森林大火,被男蛆叫好」,突然意识到自己对这个群体的违和感是什么了。 这些人,在「循规蹈矩」这一方面,其实是被加强了的。无论是在通过参政议政实现女性地位提升,还是在女性群体抱团的过程中,其实都在强化着「要在其它方面循规蹈矩,融入群体,才能用群体的力量去改变」这样的认知。于是,从对性别权利的反思,导向对其它权力结构的反思和批判,这样的过程其实未必存在。而是相反地:我已经努力地在这个框架里,混的很好了,如果性别权益能够提升,就更好了。 我并不想用「激进主义」这样的人群标签,而且说话的人,之前这方面的印象不是特别明显,所以这一次才让我印象深刻。但我确实看着一些人,在这个抱团的过程中,言辞渐渐极端化。不知这个过程,是否像兄弟会一样:你也要说出类似的言语,才能融入这个群体,并以此再吸引他人。 而「粉红女权」的存在,从这个角度上,其实也能说通了。以及一些以讨论求职升职为主要氛围的性别社区……当然,这些存在仍然是可以理解,甚至可以共情的。在已经很艰难的状况下,首先能做的是努力向上爬,这有什么不对吗?我也在反思,是不是「已经在框架中享有 privilege 的男性,才有去挣脱这个框架的 privilege」?但我觉得不是这个样子的。 只是又突然寂寥起来。就像那个最终开着飞机想去看鲸鱼的人,每天对着这片机场时的寂寥。这不是《末路狂花》,而是某种相反的东西。

  • 主宾谓

    之前聊到,日文、藏文的语序结构,和我们习惯的中文、英文不同,是谓语动词放在句子最后的「主语-宾语-谓语」的形式。 :(吐槽)所以人们常说的,日本人懂礼貌,会听人把话说完。其实是因为这样的结构,需要认真听到最后一个词,才知道整个句子要说「是」或「不是」啊。 :对于需要使用不同敬语的日本人,也方便他们先把宾语对象列出来,再根据其身份,决定用什么样的敬语去修饰动词。 另一个 blog 有时候写得少的原因,大概是在「文章是在写给谁?」这方面,无意识地发生了混乱。 除去一部分 的篇目;其它很多文章,应该是(有意识或无意识地)有一个,潜在的写作对象的。他可能是 于是,经常写到一半,突然意识到这个对象的存在,然后陷入「我这样写,有什么意义吗」的沮丧,也就不写了。 又或者,吐槽吐到一半,突然意识到,我所吐槽的特质,其实和来看 blog 的人,并不相关。于是反而担心,会不会让读者们对号入座产生误解,或者觉得我这个对空掰扯道理的样子很爹味儿之类的。 ——就像在「主-宾-谓」的句子里,谓语写一半了,才意识到,那个预设的宾语的存在。

  • 图床

    趁着服务器搬家,打算把死掉很多年的摄影网站,重新恢复起来。把如今流行的自建图库程序看了一圈:piwigo、lychee……仍然没有哪个很靠谱。 其实我在浏览这些程序之前,并没有太多具体的需求,只是期待,快 10 年没看这类东西了,会不会有什么让我惊艳的产品。——并没有。而且,在体验每个程序时,都迅速地发现一些,让我觉得很不爽的点。于是,所谓自己的需求,就是在这个不断吐槽的过程中形成的。 除了最基本的 之外, 如果,我要的是一个图床,那么我需要—— 照片的 url 和我本地储存的目录结构和文件名是一致的,类似于 https://…./blog/20230909_1.jpghttps://…./blog/20230910_cat.jpg 而不是 https://…./21/27/4c1b46114f8.jpg 这样的东西。前者的文件名,在编辑文章时便于管理。而且,以后迁移图床时,可以统一替换图片 url 的前缀,实现无缝迁移。 如果,我要的是一个摄影作品的展示网站,那么我需要—— !!!不要在网页的任何地方,显示多余的 exif 信息!!! 感觉这十年来,所有的图库程序,都把心思花在,如何去识别各种图片格式的内嵌 exif,然后把它们各种花式归档、搜索、展示……展示在网页边角、在动态的弹出菜单、甚至悬浮在照片上面。——我不需要啊!谁要在摄影作品上,标明照片的 exif 是哪天拍的,甚至是哪天上传的啊!!我连标题都不想展示啊! 甚至,各路图库程序比拼的重点,已经变成了如何调用外部地图软件,然后把照片根据 GPS 信息显示在地图上。(翻白眼 如果,我要的是一个管理图片的工具,能够便捷地挑出一些照片来展示。那么我需要—— 在一个相册里,可以便捷地拖动更改,照片之间的顺序。而不是靠手动修改文件名这种粗糙的排序方式。 没有。能够满足这些需求的哪怕其中之一的,都没有。有一些静态网站生成程序,能够把已经彻底整理好的照片,生成看着还行的展示网站。但与其一个个试过来,再试着根据自己需求去魔改各种瑕疵;我觉得我还是在 wordpress 上慢慢拼吧…… 于是又变成了 打算做点啥 → 考察相关的工具 → 做不成,开始吐槽各种工具…… 以及,在这些干扰下,想趁此机会整理从前照片的希望,大概又落空了……不仅仅是在一些照片里的人,我不想去回顾。也包括,在翻看以前照片时,仍然能够识别出的,自己当年用摄影的视角,去凝视世界的方式,以及对这种方式本身的思考和改变。——我现在是否适合,把这种方式,重新调用起来?

  • 苟富贵

    最近好几次在对话里,见到类似的思路。譬如 :你不用担心瓶盖的密封是不是靠谱,泡在洪水里是否受污染。这个工艺已经很成熟了,制造商都在卷。如果某一家做的不靠谱,被人发现了,它家自然会倒闭的。所以大家都会靠谱的。 又或者 :手游公司肯定会出这个角色的,毕竟很多人想要。公司要赚钱的啊。 这样的思路并不难反驳,譬如 但我更关心的,不是这些话题本身是什么答案,而是,说话的人,是怎样不暇思索地,用这种新自由主义的思路,来解决问题的?——或者说,潜意识里以为祭起了这个思路,就可以解决问题的? 毕竟,在这种思路的对话里,近期给我印象最深的是—— :我们(在上海疫情封城期间)过的很好啊。毕竟,只要小区物业想赚钱,他们终归会想方设法提供各种服务,把我们照顾好的啊。

  • 苟日新

    突然被人跑来问,是怎么做到写博客坚持这么久的,而且可以持续输出? (荣幸地,拿起话筒:)啊,我不觉得我这个样子,叫做「持续输出」啦。早就连每月一更都不能保证了,而且那些技术相关的帖子,在我心里都不能算是「更新博客」的,用这些凑数也为我自己所不齿…… 但我看到这个问题时,首先想到的,一个很重要的因素:大概是因为,这个站就一直在这儿吧~ 我的技术能力,不需要花什么额外的精力,就能让这个 blog 一直存活下去。于是,想写东西的时候,这里始终有个地方,可以让我写。 ——也有很多时期,是完全写不下去的,长时期没法去面对、去反刍自己的生活;然而也没必要因此而关站,就让 blog 存活在那里,终归是个表述的出口。大概是因为,我也是希望,自己能够从那些「无法整理自己」的状态中,渐渐走出来,回复到可以写东西的状态吧。所以站点的持续存在,满重要的,因为确实能感觉到,想写点什么的时候,如果没有这么个站,又或者需要自己重新架一个,可能也就不写了…… 这种「随时可以在站点写东西」的状态,也影响着对 blog 平台的选择(怎么又拐到技术贴去了?好吧,之前也一直想吐槽这方面,就顺带提一下)。这些年一直有 〖wordpress vs 各种静态博客〗哪个更好的争论。双方确实各有利弊。总体来说,静态博客最大的优点就是……省钱,可以薅 github、vercel 之类托管网站的羊毛。但另一方面,静态博客每次发布、或者修改一篇文章的过程,其实满折腾的。通常情况下,它需要 我不乏看到有人,好久没有更新,突然想写一篇文章时,忘了怎么操作,翻出攻略来重温一遍;甚至忘了连接 github 的 ssh-key……可能别人觉得这样的折腾无所谓,或者自我管理优秀的话,不会出现这种情况。但我个人觉得,这是会在主观上,影响发文章的状态的。所以,随便在任何地方任何电脑上都能直观地发文,感觉还是蛮重要的。 好像也是可以通过一系列操作,实现用浏览器某个网站上编辑文章,然后自动编译发布到托管网站的。我没有仔细去关注。但是,如果把 blog 的生命周期,放到 5~10 年这个尺度上,那么这些网站之间的复杂依赖关系,很大程度上是不靠谱的。譬如我已经看到好几个静态 blog 的外挂评论系统,不知为什么不工作了……总之,相比之下,我可能更宁愿去使用那些免费带广告的 blog 平台。 我对写 blog 的新人的推荐,一直是—— 转一张图,对于熟悉这十几年来 blog 平台变迁的人,应该会很搞笑:用不同工具写 blog 的人,(写 blog 文章)vs(写关于怎么配置 blog 的文章)的对比。右下角那些术语,都是在各个年代,需要各种不同程度的折腾的,静态 blog 方案:gatsby、org mode、jekyll、hugo、git workflow…… ps,两个月前,用这段代码方案,把我在 twitter 的所有 po 文,都导入到了自建的 mastodon 里。Twitter 那边,应该会随着 Elon…

  • Mastodon: 将媒体文件存放在本地(docker 版)

    本攻略适用于—— 这个搭配虽然不多见,但其实用起来满爽的。很多人用的 s3 服务都是在薅羊毛,而 mastodon 那个变态的,把别人家的媒体文件缓存到自家的架构,流量的吞吐其实很大的(开了 relay 就更夸张),薅羊毛时很容易就超出了。反而是 vps 本身的流量上限很高。对于个人建站而言,媒体文件总量通常 <50GB,某些 vps 自带 200GB 硬盘,足够用了。 缺点是,除了数据库定期备份外,也要考虑媒体文件的异地备份问题。但其实只需要备份存储本地附件的 media_attachments,而 cache 是不需要备份的,所以工作量也不大。 两年前我把媒体文件转移到本地时,参照了 antisocial science 的设置。但因为我用 docker,官方默认的设置,docker 内外权限不一致,无法将媒体文件写到本地。于是匆匆又在本地建了个 minio s3 来中转……这样其实很浪费资源了,minio 的开销也不小。所以最近趁着搬家,又试了一下,终于把 docker + 本地存储 跑通了。 1. 在 docker-compose.yml 里, web 和 sidekiq 容器中,已经预设了媒体文件的卷映射 这个不用动。——也可以改成其它的路径,但要和后面的设置一致(本文用相同的颜色标明)。 2. 修改 .env.production PAPERCLIP_ROOT_URL 是服务器的所有媒体文件链接的子文件夹名称,形如: 默认值是 /system;但是建议改成独特一些的名字,而且建议和 S3_BUCKET 一致。以后需要在本地存储和 s3 之间转换时,可以省一点心。(所以要独特一些,防止回头在 s3 上和别人撞名)…

  • 里世界 – 6

    看到年轻人旅行回来,继续打着鸡血,说「____那里很好,想时不时去呆上一阵」,突然意识到,自己最近这几年,纠结的点之一,在于:已经没有那样的地方了。 ——任何看上去很好,可以待着很欢乐的地方,或者人群,都需要我放弃一些方面的思考,才能去融入。而能够在这样的环境下安然欢乐,很大程度上,也是因为选择了去无视某些,这个环境里没有被提到的东西。然后,这种「无视」本身,作为一种文化,也会让安然其中的人们,发生变化。 那些没有提到的东西,包括但远远不限于:各种权力的体现(政治、性别、阶层……)、消费主义、对认同感的依赖和屈从、对多样性的接受以及主动探索……这些年研究文化对人的影响,也就对那些「无视」导致的变化,感知更加明显。 可以说,那些坚持去思考的东西,叫做「执念」。但「执念」这种说法,仍然只是为了舒适而放弃某些东西后的自我解释。 而我这些年的变化,也是从「要不要为了在这样的地方快乐生活,而改变呢」; 变成「不想改变的话,就真的没有这样的地方了吗?再努力找找吧」,然后因为找不到而焦虑,渐渐又因为意识到这样的地方不存在而焦虑; 再变成「这样的地方不存在,那又能怎样呢」,然后再分析,那样的一个理想化的环境,——无论是期望现实中存在的,还是在脑海中凭空构造的,——它对我的吸引力,是由哪些因素导致的呢?很多因素,经过这样的分析后,都可以选择从自我身上去剔除(aka 修仙)。 Stop finding neverland,不是因为要脚踏实地了,而是接受「没有」的状态,让自己根本不再需要,任何形式的 land,作为支撑。 当然,能够去玩得很开心的地方,我自信还是能找出很多的。但世界总体,仍然只是旅程。

  • 评论区

    如今很多 blog,尤其是这些年新人们搭建的静态 blog,都是没有给文章留言评论的功能的。 (略过 wordpress 和 hexo、hugo 等静态引擎对比若干)(略过静态 blog 外挂评论系统的技术难度和优劣若干) 最近读的一篇文章,让我想要和作者讨论一些感受,然而却没有评论的地方。——其实我是有作者的其它社交网络账号,甚至在聊天软件上加了好友的。但总感觉,在其它地方,另外开启一串讨论,有些违和。以及和文章的话题也有关系吧,一些和内心情绪相关的话题,反而不适合凑上前和人家私密地聊感受。文章底部的评论区,是个我觉得合适的,或者说在我的认知中习惯了的,豪猪之间的距离。 也许人家就是因为不想有这样的讨论,才不设评论区呢?——但也许人家并不是这样想的呢?也许他在这篇文章想要有人讨论,而那篇文章则不想,而无论想或不想,和他有没有在 blog 里加评论系统,并没有任何关系。所以那些「想 or 不想」,其实都只是我自己通过臆断,试图对当前状态的一种解释。甚至再从这样的解释,为自己总结出莫须有的规律和准则。 包括我觉得「评论区更舒适」,仍然是一种非常自我的总结。如今连 blog 都没几个人写,仅有的几个用户,也是不同年代不同环境不同引擎。于是,这种自以为的总结,不可能是被很多人共鸣认可的准则。所以真的有存在的必要么? 这种纠结的心态,大概来源于,自己在日常的其它方面,被这种潜在的总结准则所扰。虽然我在反思后,是倾向于让这些准则变得不存在的;但对很多人而言,似乎仍然是存在的(这个我不觉得是臆断),并以此构建出交流的障碍。 当然,即使如此,从权力关系的角度,这也不是让我能够有了感受就可以肆无忌惮地把读后感塞给人家的理由。(这是另一种纠结了……

  • Fediverse: 是否要自建实例?

    之前和人聊到,自建 fediverse 实例时,和在其它实例做注册用户相比,一些不同的体验。然后发现,谈到的许多东西,对于没有自建经历的网友,还是很新鲜的。所以索性在这里列出来,让大家了解一下。 自建实例的优点 1. (可能)更好的稳定性 是的,自建并不是「不稳定」的代名词;恰恰相反,如果技术能力达标,个人实例因为开销相对较少,稳定性反而比很多中小型实例要高。即使我完全有能力,担任几百名用户的实例管理员;和维护一个我自己用的实例相比,我也是对后者的稳定性更有信心的。 而另一方面,现有实例的站长们,也未必都是很靠谱的。他们会因为各种技术、非技术、甚至搞笑的原因,导致站点无法访问。常见例子包括: 目前 fediverse 更换一次账号,还是满麻烦的;也并没有旧帐号数据的导入功能。所以,如果想要让自己的账号,长久地存在下去,自建可能是更好的选择。 以及,自建实例有更好的安全性。——像 fediverse 这类的程序,暴露出的系统漏洞,其中相当大一部分,都是通过「站内用户的恶意攻击」来触发的(譬如上传会包含代码的媒体文件)。如果这个站点只有你自己在使用,那么,这类漏洞,对你来说是无关紧要的。 2. 更好的隐私控制 之前写过一篇《Fediverse 站长都能看到什么?》。普通用户的很多未公开信息,对于所在实例的站长,技术上都是可见的。如果你在这些隐私方面有所顾虑,或者打算把 fediverse 账号当成私密日记来用,那么,自己建站,信息被不相干的人看到的可能性,会更少一些。 3. 管理自己的全部数据 现有的 fediverse 服务程序,为普通用户提供了数据导出功能,但导出的数据内容很有限。譬如 mastodon 导出的数据中,包括: 但并不包括: 其它程序的数据导出,也都大同小异(twitter 也差不多);有的甚至会更少,譬如支持和 fedi 账号互 fo 的,图书管理程序 bookwyrm,用户能导出的,只能用惨烈来形容(只有书的链接;没有书的标题和简介!没有你的书评!)。如果你希望未来也能够看到这些自己交互过的信息,而不是随着网站的消失而听天由命,那么,可能一开始就选择自建比较好。 另外,mastodon 的搜索功能,做的很差劲的(尤其是中文)。elastic search 的开销极其巨大,效果也不好。虽然我也很少用搜索功能,但一旦真的有什么信息,需要精确查找,直接在自己建的站里用 SQL 搜索数据库,要舒适很多。 4. 更少的站内约束 很多 fediverse 实例,是有其内部的聊天「氛围」的。一些和氛围不合拍的发言,可能会遭到实例其它用户的抵制,甚至举报。很多时候,这样的分歧可能无关对错,但多少会对发言者产生困扰和拘束。又或者,站长决定,或者通过「民主表决」的方式,让全站屏蔽了某个实例,而你可能并不希望这样。如果是自建的话,做自己的站长,这样的约束可能会少一些。——虽然偶尔还是会看到一些来自外站的举报,但跨站举报本来就没有相应的处理和交互机制,无视就可以了。以及,我并不是指,自建站就可以肆无忌惮地发色情或者仇恨言论,那可能会让你的整个站点,被其它实例屏蔽的。 5. 使用自己的个性域名作为账号 这样看起来比较酷。但也仅仅是比较酷而已。 6. 免翻墙 随着 fediverse 逐渐进入某国审查机构的视野,那些几百甚至几十人的实例,未来被封杀的可能性也会急剧增加。相对来说,用个人域名在海外服务器搭建的,个人使用的实例,短期内被封的可能性,还不是很大。自建站的用户不必翻墙,就可以直接通过自己的实例,访问到其它被封实例的内容。——当然,翻墙属于必备技能,所以这也算不上是多大的优点。 自建实例的缺点…

  • Fediverse: 你的站长都能看到什么?

    当你注册成为某个 fediverse 实例(mastodon pleroma misskey …)的用户时,你所在的实例,可能是几十万用户的大站,站长离你遥不可及;也可能是几十个甚至几个用户的小站,站长和你关系密切,每天一起聊天玩耍。但无论是哪种,你的站长,都能看到和你有关的哪些内容呢?我觉得这是你应该知道的。 首先,所有人都能看到的: 然后,是你能看到,其它用户看不到,而且你可能也不希望别人看到的。这些,你的站长都能看到: 最后,是你作为普通用户也看不到,但你的站长能看到的: 还有哪些?欢迎大家补充~ P.S.