Save The Web Project – Telegram
今天(6月9日)是国际存档日(International Archives Day)
22
Save The Web Project
STWP 2025 第 19 周周报 本周的产量同样稀少,记一点流水账吧。 - 用 Go 重写了两年前写的 https://github.com/saveweb/fdroidswh 小玩意,用于跟踪 F-Droid Repo 的应用更新,将源代码仓库推送到 SWH 存档。 https://service-fdroidswh.saveweb.org/ - 响应了 6 个画吧备份导出请求。 - dokuwiki dumper 小重构 WIP: https://github.com/saveweb/dokuwiki…
STWP 2025 20 至 25 周,合并周报。

过去一个月是期末,没时间。现在好久没发周报了,快速过一下最近5周做了啥。主要做的事是 Zeno,没有开其它存档项目。

week 20-21 https://github.com/internetarchive/Zeno/pull/281 稍微重构 Zeno 处理对象存储的代码,添加解析 Azure Blob 的能力。 https://github.com/internetarchive/Zeno/pull/295 让 Zeno 终端输出的日志变彩色。

week 23
https://github.com/internetarchive/Zeno/pull/324 小小地引入标准 css 解析器,替换掉原本简陋的容易产生误报的正则提取方式。 (CSS 1/3)

week 24
None

week 25
- https://github.com/Crossbell-Box/xLog/pull/2230 前几周惊人地发现 xLog 上的一半的新文章是 spam,于是打标然后跑了个简单的 TF-IDF 分类器来识别 spam 账号。这周把识别结果人工检查了一下,把 spam 账号列表发给 xLog。
- https://github.com/internetarchive/Zeno/pull/339 支持提取 CSS 的 @import 链接。(CSS 2/3)
- https://github.com/internetarchive/Zeno/pull/345 完整支持解析 html 嵌入和引用的 css 资源。同时,发现上游的 css parser 不支持 CSS Nesting 和未适配“现代” css 语法。由于没有精力给上游修bug,因此写了个更鲁棒的正则来作为 parser 失败时的 fallback parser 当作 workaround。 (CSS 3/3)
- https://github.com/microsoft/vscode-css/pull/43 在 debug CSS 的过程中发现 VSC 自带的 CSS 高亮也没适配11年前的“新”语法标准。@overflowcat 得知后刷了一个 PR 。
- https://github.com/internetarchive/Zeno/pull/353 改善了对 GitHub Issue 页面的存档效果。
- 向 Zeno 添加 Headless/Headfull 存档功能(进行中)

这几周看 w3c 和 whatwg 都要看吐了,之后会发点关于 CSS、浏览器、URL、HTML、编码 之类的小故事。
8🥰2
Save The Web Project
STWP 2025 20 至 25 周,合并周报。 过去一个月是期末,没时间。现在好久没发周报了,快速过一下最近5周做了啥。主要做的事是 Zeno,没有开其它存档项目。 week 20-21 https://github.com/internetarchive/Zeno/pull/281 稍微重构 Zeno 处理对象存储的代码,添加解析 Azure Blob 的能力。 https://github.com/internetarchive/Zeno/pull/295 让 Zeno 终端输出的日志变彩色。…
STWP 2025 26 周周报

还是全是 Zeno 。

- https://github.com/internetarchive/Zeno/pull/356 Headless/Headfull 存档 PR 发了,PR 仍在 WIP。(测试可以存档知乎专栏!)
- https://github.com/internetarchive/Zeno/pull/370 解析非 UTF-8 的 HTML,PR 仍在 WIP 。
- https://github.com/internetarchive/Zeno/pull/369 加了丢弃超过指定 payload 大小的响应的功能。
- https://github.com/internetarchive/gowarc/pull/115 主要是修了 gowarc 在上层的 HTTP TCP Conn 出现异常关闭时 (early EOF, io timeout, conn closed/reset),由于没有向下 .CloseWithError(),而是调用常规的 .Close(),导致下层的 MITM 套娃 HTTP TCP Conn 以为是正常 EOF,最终导致,对于没有 Content-Length 头的流式响应,这类 early EOF 的响应被当成正常响应而被写入了 WARC 存档中。(而对于更常见的非流式响应,由于存在 Content-Length,即使 early EOF 仍然被当成了正常 EOF,但是由于 go 的 http 标准库的 http.ReadRespon() 会用 io.LimitReader 来组装 Response.Body ,这样的 Response.Body 会自己做一次额外的 EOF 位置与 Content-Length 位置的匹配检查,如果不匹配会返回 early EOF。换句话说,这 BUG 在大部分情况下被标准库缓解了导致我们没发现。)。然后还修了 Conn.SetReadDeadline() 木有生效、临时文件泄漏的问题。
👍2
STWP 2025 27 周周报

这周啥也没干,给大家看看猫猫吧/
🥰156🤪1
Forwarded from Programmer Jokes
17
Save The Web Project
Photo
STWP 2025 28 至 30 周,合并周报

- https://github.com/internetarchive/Zeno/pull/356 Headless/Headful 终于做好了。
- https://github.com/internetarchive/Zeno/pull/370 解析非 UTF-8 的 HTML+URL 也做好了。
- 修了两个小 bug
- https://github.com/internetarchive/Zeno/pull/403 加上了第一个 e2e 测试。
- https://github.com/internetarchive/Zeno/pull/376 加了 Window 二进制构建,但实际上并不能用。用来忽悠 Windows 用户。
- https://github.com/internetarchive/Zeno/pull/374 纯 Go 崛起失败。
3🥰3🤬21
Save The Web Project
F**K YOU GOOGLE
Google 改主意了,计划只删“非活跃”的 goo.gl 链接,其它保留。

https://blog.google/technology/developers/googl-link-shortening-update/

但还保留多久呢?肯定不会一直保留下去吧?
总之,所有短链服务都是**。
16
不要乱说,V8 和 SpiderMonkey 一直是这个速度,🌐🌐🌐很难的,有时候找找自己原因,这么多年了换没换硬件,有没有跟上🕸革命的脚步?

点我👀⬅️💻🌄💪
Please open Telegram to view this post
VIEW IN TELEGRAM
20
https://css-loop.saveweb.org/

凡最终加载此网页者,奖一块华为手表。
8
晚上好,感谢Google感谢IA感谢WBM感谢群友感谢猫

现在我购得了新玩具:磁带库(4U,可装48盘)。目前装有一个L6的磁带机。

磁带库真好玩。
13🆒5😭3
STWP 2025 第 36 周周报

- CGO-free via WASM

ada (ada-url.com) 是 Zeno 使用的 URL Parser。

在 GSoC 报告中我提到:

ada 作为一个 C++ URL Parser 的质量非常好,如果它的 Go Binding (goada) 能摆脱 CGO 的话就更好了。
未来可以尝试用把 ada 编译成 wasm 然后用 wazero 来从 Golang 跨语言调用来避免 CGO,方便交叉编译(ncruces/go-sqlite3 就是这样干的)。


这周试着做了下(LLM 帮了活),发现异常地简单。
https://github.com/yzqzss/goada-wasm/

相较于 CGO 版,解析url顺序性能下降1x,并发性能下降0.1x。主要是要在GO和WASM端传递 raw url 和 parsed url,序列化、反序列化、malloc 成本有点高。

我现在有个新灵感:用 WASM 来做轻量的跨平台 warrior。这个 warrior 就是个 runner,从我们服务器上下载 wasm payload 然后执行。

这样又有动态运行代码的能力,我 release 也只需要打 wasm 就行了。似乎一切都很完美。

- 《LTO 磁带存储入门初探🤪——环境搭建

买了台 HP MSL4048 磁带库,有48盘磁带和4个驱动器槽位。(花费1.1k)
买了块LTO6驱动器。(花费1.3k)
还有数据带、清洗带若干。

这个磁带机运行起来比R730还吵,主要是驱动器的外置暴力风扇,上电就疯狂吹。

翻了下库的带外管理,发现可以单独开关机磁带机,单独关机后就不算吵了。

但是库本身也还有点吵,我不希望它一直开机不干事还一直负压往里面吸灰。

然后,这个库的带外管理模块需要库本身开机才能工作。😅

而且我没找到来电开机的设置,所以不能简单用智能插座解决远程开机问题。

于是我淘宝了个支持米家的蓝牙断路器,准备烙在库的开机键上。

磁带库和磁带机相比服务器要金贵,最重要的就是做好无尘,磁带库手册上明确说需要基本的 ISO 8 级无尘(大部分无尘机房的环境)。有幸见识过在普通室内环境7x24工作多年的库、机、平均全量读写400次的带子,袋子里面都进了肉眼可见的一层灰,它们最终都提前退休报废了。

我的低成本方案是把空卧室封闭起来,然后把收来的小米空气净化器,倒着放,让它把干净空气从上至下灌进机柜里。

怎么知道这样的逆天 DIY 方案到底能不能行呢?

ISO 规定的洁净等级是按照每立方各直径的颗粒数量来区分的。而我们从一般的空气质量传感器和气象站看到的 PM2.5 和 PM10 用的单位是 ug/m3。

PM10,颗粒直径按平均 5um 算。
单位体积 V = 4/3 * π * (5/2)^3 = 65.45 um3

颗粒数量 PCS = X / (V * D)

X = 气象站出的数据 (ug/m3)
V = 65.45 μm3
D = 1.7 g/cm3 = 1.7*10^9 μg/m3 (用 https://pubs.acs.org/doi/abs/10.1021/es204073t 推算)

V = 65.45 * 1e-18 # m3
D = 1.7e9 # ug/m3
def pcs(x): # x in ug/m3
return x / (V * D)


ISO 8 级洁净要求

>= 0.5um 3520,000
>= 1um 832,000
>= 5um 29,300

就按 5um 来算,29300 pcs/ m3

pcs_limit = 29300 # pcs/m3
def quota(x): # x in ug/m3
return pcs(x) / pcs_limit


>>> quota(1)
306.7423972746551
>>> quota(22)
6748.332740042413


这样粗略算下来,我家附近的环境空气洁净度超标6.7k倍。就算 PM10 是 1ug/m3,也超标了 300 倍。而多数成品空气质量检测器(包块空气净化器自带的)的输出分辨率也才 1ug/m3,所以它们都不能用来测机柜内到底是 ISO 8 洁净。

网上卖的正经尘埃颗粒计数器成品卖几百几千,但是家用空气净化器同款的检测模块只要52包邮,TTL 读数据就行。

模块能输出 0.3~10um 等各个直径的颗粒物的单位空间的质量和数量。

这种模块被多款空气净化器使用,厂商故意在低端机上面只读取PM2.5的质量数据,而在“高端机”上则再多读取PM10质量数据,美其名曰:“具有PM10粉尘传感器”。

另外,磁带库运行的允许湿度范围是 20-80,建议范围是 20-50。这个要求简单,放个小米蓝牙温湿度计,然后要用磁带库的时候提前开空调除湿就行。
Please open Telegram to view this post
VIEW IN TELEGRAM
91