Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

我喜欢

By: fivestone
5 October 2023 at 03:05

大概我们每个人,哪怕三观再正的人,应该都经历过:一些自己真的有在喜欢的东西,可能是「不正确」的,由此产生的内心冲突和纠结。

  • 喜欢的文学作品、武侠小说、网文……里面,充满了腐臭的男性气概;
  • 各种爱豆或综艺秀,有多少是女性凝视?
  • 喜欢看的马戏表演、宠物店、或者一些消费品,在虐待动物;
  • 喜欢吃的冰淇淋,厂商卖过毒奶粉;
  • 自己的一些性癖,或者心动的对象,是不是在「慕强」?

这个内心冲突的过程,可能会很难受,而且很可能没有确定的答案。——很多时候,是选择继续喜欢下去的,因为从「喜欢」变得「让自己不喜欢」,其实是个很玄学,很难做到的事情。于是只能喜欢且痛苦着,或者让自己把那些痛苦的思考,渐渐无视遗忘。

也可能,通过反思,真的能让自己对以前喜欢的东西祛魅,从此对它没啥感觉。——(其实很多时候,是被「反思成功」的成就感所掩盖……)。但失去了一个兴趣,也是很难受的事,尤其是周围还有很多人,仍然把这个当作兴趣,甚至是日常交流沟通的话题的时候。

也有很多时候,是脱离了二分法,就这么在二者之间悬浮着。因为那个「不正确」的事情,是否 100% 不正确,有没有好的一面,通常也是可以辩论的……以及,这个发现「不正确」的过程,可能是自己渐渐觉悟到,也可能是别人硬戳过来,说你喜欢这个不对。于是又涉及维护面子;或者先声讨对方的态度……

这些都是可以理解,可以接受的反应。——甚至连艰难地无视,也可以说是合理的。因为,如果避开那些「不正确」背后的,错综复杂到无法撼动的因素和体系,而单纯要求你拿出一个面面俱到的态度,这本身也是一种不公。


但至少不要——

因为「我真的喜欢」,所以理直气壮地认为这东西没有问题。

「我喜欢」,从来都不是「这个东西是正确的」的理由。一方面,你之所以喜欢它,可能已经是某种糟粕文化的后果。另一方面,同样的事物或行为,不同环境下人们对它的感受是不同的。就像跳脱衣舞或者买芭比娃娃,可能在你的环境下,它真的意味着个性、张扬、多样性;而对其它很多人而言,也确实是剥削、是凝视、是痛苦的印象。那么,这东西的合理性,是否因此对你就没那么理直气壮?

如今的很多争吵,大概都源于某种「我的个性自由不应被阻挡」的态度。但很多事情,是需要在微妙地平衡中,甚至是在让自我痛苦的过程中,才能更好形成的。


就像恋爱脑爱上了渣男。尽管会为此而痛苦、犹豫,最终可能选择爱或不爱,但毕竟是清楚他是个渣男的;而不是拼命要去说服他并不渣呀。

图床

By: fivestone
10 September 2023 at 13:31

趁着服务器搬家,打算把死掉很多年的摄影网站,重新恢复起来。把如今流行的自建图库程序看了一圈:piwigo、lychee……仍然没有哪个很靠谱。

其实我在浏览这些程序之前,并没有太多具体的需求,只是期待,快 10 年没看这类东西了,会不会有什么让我惊艳的产品。——并没有。而且,在体验每个程序时,都迅速地发现一些,让我觉得很不爽的点。于是,所谓自己的需求,就是在这个不断吐槽的过程中形成的。

除了最基本的

  • 便捷的上传
  • 并不是难看到很离谱的展示界面

之外,

如果,我要的是一个图床,那么我需要——

照片的 url 和我本地储存的目录结构和文件名是一致的,类似于

https://..../blog/20230909_1.jpg
https://..../blog/20230910_cat.jpg

而不是

https://..../21/27/4c1b46114f8.jpg

这样的东西。前者的文件名,在编辑文章时便于管理。而且,以后迁移图床时,可以统一替换图片 url 的前缀,实现无缝迁移。

如果,我要的是一个摄影作品的展示网站,那么我需要——

!!!不要在网页的任何地方,显示多余的 exif 信息!!!

感觉这十年来,所有的图库程序,都把心思花在,如何去识别各种图片格式的内嵌 exif,然后把它们各种花式归档、搜索、展示……展示在网页边角、在动态的弹出菜单、甚至悬浮在照片上面。——我不需要啊!谁要在摄影作品上,标明照片的 exif 是哪天拍的,甚至是哪天上传的啊!!我连标题都不想展示啊!

甚至,各路图库程序比拼的重点,已经变成了如何调用外部地图软件,然后把照片根据 GPS 信息显示在地图上。(翻白眼

如果,我要的是一个管理图片的工具,能够便捷地挑出一些照片来展示。那么我需要——

在一个相册里,可以便捷地拖动更改,照片之间的顺序。而不是靠手动修改文件名这种粗糙的排序方式。


没有。能够满足这些需求的哪怕其中之一的,都没有。有一些静态网站生成程序,能够把已经彻底整理好的照片,生成看着还行的展示网站。但与其一个个试过来,再试着根据自己需求去魔改各种瑕疵;我觉得我还是在 wordpress 上慢慢拼吧……

于是又变成了

打算做点啥 → 考察相关的工具 → 做不成,开始吐槽各种工具……


以及,在这些干扰下,想趁此机会整理从前照片的希望,大概又落空了……不仅仅是在一些照片里的人,我不想去回顾。也包括,在翻看以前照片时,仍然能够识别出的,自己当年用摄影的视角,去凝视世界的方式,以及对这种方式本身的思考和改变。——我现在是否适合,把这种方式,重新调用起来?

苟日新

By: fivestone
5 September 2023 at 07:41

突然被人跑来问,是怎么做到写博客坚持这么久的,而且可以持续输出?

(荣幸地,拿起话筒:)啊,我不觉得我这个样子,叫做「持续输出」啦。早就连每月一更都不能保证了,而且那些技术相关的帖子,在我心里都不能算是「更新博客」的,用这些凑数也为我自己所不齿……

但我看到这个问题时,首先想到的,一个很重要的因素:大概是因为,这个站就一直在这儿吧~ 我的技术能力,不需要花什么额外的精力,就能让这个 blog 一直存活下去。于是,想写东西的时候,这里始终有个地方,可以让我写。

——也有很多时期,是完全写不下去的,长时期没法去面对、去反刍自己的生活;然而也没必要因此而关站,就让 blog 存活在那里,终归是个表述的出口。大概是因为,我也是希望,自己能够从那些「无法整理自己」的状态中,渐渐走出来,回复到可以写东西的状态吧。所以站点的持续存在,满重要的,因为确实能感觉到,想写点什么的时候,如果没有这么个站,又或者需要自己重新架一个,可能也就不写了……


这种「随时可以在站点写东西」的状态,也影响着对 blog 平台的选择(怎么又拐到技术贴去了?好吧,之前也一直想吐槽这方面,就顺带提一下)。这些年一直有 〖wordpress vs 各种静态博客〗哪个更好的争论。双方确实各有利弊。总体来说,静态博客最大的优点就是……省钱,可以薅 github、vercel 之类托管网站的羊毛。但另一方面,静态博客每次发布、或者修改一篇文章的过程,其实满折腾的。通常情况下,它需要

  • 一台固定的电脑,安装静态博客编译程序,并且从这台电脑发布到 github 的专门权限。而不是随便打开一台电脑或手机,从浏览器就能编辑发文;
  • 每次发文时的一系列专门操作。

我不乏看到有人,好久没有更新,突然想写一篇文章时,忘了怎么操作,翻出攻略来重温一遍;甚至忘了连接 github 的 ssh-key……可能别人觉得这样的折腾无所谓,或者自我管理优秀的话,不会出现这种情况。但我个人觉得,这是会在主观上,影响发文章的状态的。所以,随便在任何地方任何电脑上都能直观地发文,感觉还是蛮重要的。

好像也是可以通过一系列操作,实现用浏览器某个网站上编辑文章,然后自动编译发布到托管网站的。我没有仔细去关注。但是,如果把 blog 的生命周期,放到 5~10 年这个尺度上,那么这些网站之间的复杂依赖关系,很大程度上是不靠谱的。譬如我已经看到好几个静态 blog 的外挂评论系统,不知为什么不工作了……总之,相比之下,我可能更宁愿去使用那些免费带广告的 blog 平台。

我对写 blog 的新人的推荐,一直是——

  • 如果有技术能力、也有服务器的话,自建 wordpress;
  • 或者找人蹭一个。如果我们比较熟,你可以去买个域名,把 blog 挂在我的服务器上。这并不是很大的负担。(ps,个人 wordpress 小站,是可以不必安装开销很大的 mysql 数据库的);
  • 如果上面两条都不行,那么,我优先推荐去注册现成的 wordpress.com 或者 blogspot.com,目前看起来,长期靠谱的只有这两家了。虽然免费版界面不好看、还有广告,但长期写着应该没问题的;
  • 当然,我不会给乐于尝试静态博客的人泼冷水。但我会根据你的技术能力和气质,暗戳戳地担心:
    • 你能坚持写多久;
    • 你写出来的,会不会很多都是关于你怎么建站的经历和心得……

转一张,对于熟悉这十几年来 blog 平台变迁的人,应该会很搞笑:用不同工具写 blog 的人,(写 blog 文章)vs(写关于怎么配置 blog 的文章)的对比。右下角那些术语,都是在各个年代,需要各种不同程度的折腾的,静态 blog 方案:gatsby、org mode、jekyll、hugo、git workflow……


ps,两个月前,用这段代码方案,把我在 twitter 的所有 po 文,都导入到了自建的 mastodon 里。Twitter 那边,应该会随着 Elon Musk 的各种不靠谱折腾,渐渐放弃掉了吧。而每条推文的字数限制,从 twitter 的 140 字,变成 mastodon 的 500 字后,很多几百字的感受,要不要专门写到 blog 这边来,就比从前,更让人犹豫。具体怎么处理,我还没想好。

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

By: fivestone
30 August 2023 at 05:12

本攻略适用于——

  • 自建 mastodon(非大站)
  • 使用 docker compose
  • 将媒体文件直接保存在服务器上,而不使用 s3 外部存储

这个搭配虽然不多见,但其实用起来满爽的。很多人用的 s3 服务都是在薅羊毛,而 mastodon 那个变态的,把别人家的媒体文件缓存到自家的架构,流量的吞吐其实很大的(开了 relay 就更夸张),薅羊毛时很容易就超出了。反而是 vps 本身的流量上限很高。对于个人建站而言,媒体文件总量通常 <50GB,某些 vps 自带 200GB 硬盘,足够用了。

缺点是,除了数据库定期备份外,也要考虑媒体文件的异地备份问题。但其实只需要备份存储本地附件的 media_attachments,而 cache 是不需要备份的,所以工作量也不大。

两年前我把媒体文件转移到本地时,参照了 antisocial science 的设置。但因为我用 docker,官方默认的设置,docker 内外权限不一致,无法将媒体文件写到本地。于是匆匆又在本地建了个 minio s3 来中转……这样其实很浪费资源了,minio 的开销也不小。所以最近趁着搬家,又试了一下,终于把 docker + 本地存储 跑通了。


1. 在 docker-compose.yml 里,

web 和 sidekiq 容器中,已经预设了媒体文件的卷映射

volumes:
- ./public/system:/mastodon/public/system

这个不用动。——也可以改成其它的路径,但要和后面的设置一致(本文用相同的颜色标明)。

2. 修改 .env.production

S3_ENABLED=false
PAPERCLIP_ROOT_PATH=/mastodon/public/system
PAPERCLIP_ROOT_URL=/fivestone-mastodon-media

PAPERCLIP_ROOT_URL 是服务器的所有媒体文件链接的子文件夹名称,形如:

https://mastodon.fivest.one/fivestone-mastodon-media/media_attachments/.../x.jpg

默认值是 /system;但是建议改成独特一些的名字,而且建议和 S3_BUCKET 一致。以后需要在本地存储和 s3 之间转换时,可以省一点心。(所以要独特一些,防止回头在 s3 上和别人撞名)

3. 修改 nginx 的域名配置文件

参照官方的配置,把域名文件夹里的 proxy_pass ,直接改成本地的 alias

server 
{
  server_name mastodon.fivest.one;
# ......

  location /fivestone-mastodon-media/
  {
    alias /path-to...docker-compose-folder/public/system/ ;

    proxy_cache CACHE;
    proxy_cache_valid 200 48h;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_lock on;

    expires 1y;
    add_header Cache-Control public;
    add_header 'Access-Control-Allow-Origin' '*';
    add_header X-Cache-Status $upstream_cache_status;
    add_header X-Content-Type-Options nosniff;
    add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
  }
}

然后重启 nginx

sudo systemctl reload nginx.service

4. 通过 docker 设置媒体文件夹的权限

在 docker 内部,是以 mastodon 用户的身份,来运行程序的,所以要把媒体文件夹的所有者改成(docker 内部的)mastodon:

sudo docker-compose run --user=root --rm web chown -R mastodon /mastodon/public/system

如果是从 s3 迁移到本地,把媒体文件移入这个本地文件夹(/path-to…docker-compose-folder/public/system/)后,也要再执行一遍上面这条命令。

或者在 mastodon docker 服务已经启动的情况下,执行:

sudo docker exec -u 0 mastodon_container_web chown -R mastodon /mastodon/public/system

但在这条命令执行结束之前,mastodon 在后台写入媒体文件时,仍然可能出现文件夹权限不足,无法写入的问题。

❌
❌