让Codex写了个同步碎碎念到推特的按钮,现在应该不会因为打开推特就刷两个小时然后忘记要干什么了……

这是一个测试。
让Codex写了个同步碎碎念到推特的按钮,现在应该不会因为打开推特就刷两个小时然后忘记要干什么了……

这是一个测试。
给我给整不会了…🤡🤡🤡
...
其实你的渲染架构已经比较接近墨水屏需要的模式了。
建议把渲染拆成两层:
Layout ↓ Paint 到内存 Buffer ↓ Diff ↓ Dirty Rect ↓ EPD Update也就是说:
GUI 仍然画完整 Buffer。
最后:
Old Buffer New Buffer ↓ 比较 ↓ 找出变化区域 ↓ 通知 EPD这样你的 GUI 不需要知道是不是墨水屏。
LCD Backend:
Memcpy framebufferEPD Backend:
Diff ↓ Update(Rect1) ↓ Update(Rect2)如果以后支持真正的 E-Ink 驱动,只需要替换最后一层 Backend 即可。
所以只要遍历所有像素点,找出 [min(x),min(y),max(x),max(y)] 构成的矩形,拷贝过去即可完成刷新。
最大的问题就是CPU快不快了。
文本排版需要自动换行,所以最好在一个地方处理。但是我不确定这样是否“标准”,于是在我刚开始修改了一点点实现的时候我就问了狗屁通,这一通回答下,我感觉自信满满。
但是凭心而论,这个排版方式其实更应该适用于所有的内联排版(比如图文混排),而不仅仅是文本。然后,图片其实也就是个“不会wrap的text”仅此而已。所以后面如果要增加图文混排,只会更简单?
另外,排版这个过程应该由<text>的父元素来执行(即便<text>内还有其它元素),因为:对于来换行的父元素来说,<text是没法知道父元素的总体大小的。
我的文本节点是
<text>,它里面可以有<b>、<i>、<code>等子元素,而且子元素可以嵌套。由于文本在渲染、排版的时候是可以自动换行的,我应该如何表示这层关系、并且方便渲染?
我看了你的代码,我觉得现在最大的瓶颈不是
<b>怎么表示,而是你的Text节点承担了两种职责:
- DOM 节点(树)
- 排版对象(Layout)
浏览器实际上把这两者分开了。
浏览器大概是这样
DOM:
1 2 3 4 5 6 7text ├── "Hello " ├── b │ ├── "World " │ └── i │ └── "!!!" └── " Bye"对应:
1 2 3 4 5 6 7 8<text> Hello <b> World <i>!!!</i> </b> Bye </text>但是 Layout 并不会递归画这个树。
而是先展开。
第一步:生成 TextRun
浏览器会得到类似:
1 2 3 4type TextRun struct { Text string Style Styles }例如:
1 2 3 4 5 6[ {Text:"Hello ", Style:normal}, {Text:"World ", Style:bold}, {Text:"!!!", Style:bold+italic}, {Text:" Bye", Style:normal}, ]注意:
已经没有 DOM。
只有:
1 2 3 4 5字符串 + 最终样式
第二步:Layout
Layout 输入:
1[]TextRun例如:
1Hello World !!! Bye然后:
1 2 3 4 5 6 7 8 9 10 11 12 13Segment() ↓ Line1 ↓ Line2 ↓ ...这里可以跨 Run。
例如:
1 2 3 4 5 6 7 8Run1 Hello Run2 World宽度:
1Hello Wo第一行:
1Hello Wo第二行:
1rld甚至:
1Hel也是合法的。
所以:
换行单位不是 Run,而是 Glyph。
第三步:生成 Line
例如:
1 2 3type TextLine struct { Runs []TextRunFragment }其中:
1 2 3 4 5type TextRunFragment struct { Run *TextRun Start int End int }例如:
1Hello World!!!可能得到:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21Line1 Hello Wo ↓ [ normal(Hello ), bold(Wo), ] Line2 rld!!! ↓ [ bold(rld), bold+italic(!!!), ]
Draw
Draw 就非常简单:
1 2 3 4 5 6 7 8 9 10 11 12 13for _, line := range lines { x := 0 for _, run := range line.Runs { face := fontManager.Face(run.Style) DrawString(run.Text) x += run.Width } }
对你的代码
我会把:
1 2 3 4 5 6 7type Text struct { BaseBox Data string face FontFace }改掉。
Data 不应该存在。
应该:
1 2 3 4 5type Text struct { BaseBox Lines []TextLine }真正的数据来自:
1Children例如:
1 2 3 4 5 6 7 8 9 10 11 12 13Text ↓ Children ↓ TextNode Bold Italic
然后新增一种:
1 2 3 4 5 6type TextData struct { BaseBox Data string }注意:
现在:
1Text不再保存:
1Data而是:
1 2 3 4 5 6 7 8 9 10 11 12 13Text ↓ TextData ↓ Bold ↓ Italic这样:
1 2 3 4 5 6<text> Hello <b> World </b> </text>就是:
1 2 3 4 5 6 7Text ├──TextData("Hello") └──Bold └──TextData("World")
Calc()
Calc 时:
第一步:
DFS。
把树:
1 2 3 4 5 6 7 8 9Text ↓ Bold ↓ Italic展开:
1[]TextRun每个 Run 带:
1最终 Styles例如:
1 2 3 4 5Bold ↓ Style.FontBold=trueItalic:
1 2 3FontBold=true FontItalic=true全部继承好了。
然后:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15Runs ↓ Layout ↓ Lines ↓ 保存到 Text.Lines
Draw:
完全不用递归。
直接:
1 2 3 4 5for line for run Draw
我为什么推荐这种结构
因为以后你肯定还会支持:
1 2 3 4 5<b> <i> <code> <span> <color>甚至:
1<a>如果每一种都在 Draw 里面递归:
1 2 3 4 5 6 7 8 9Draw() ↓ Draw() ↓ Draw()最后:
1 2 3 4 5 6 7 8 9自动换行 跨节点 选中 复制 光标都会变得非常痛苦。
而浏览器几十年来一直都是:
DOM → TextRun → Line → Glyph → Draw
DOM 只是输入。
真正负责排版的是一组已经扁平化的 TextRun。
结合你现在的代码,我建议把
Text从“叶子节点”改成“文本容器”,新增一个真正的文本叶子节点(例如你已经有的_TextData,把它完善即可)。 然后在Text.Calc()中递归遍历子树,继承样式并生成[]TextRun,再进行换行和排版。这一步完成后,Draw()就完全不需要关心 DOM 树了,只负责按排版结果绘制。这种结构和浏览器、Qt、Flutter 的文本引擎都非常接近,而且以后加<i>、<code>、<span>、超链接等都不用推翻整个设计。
我实现好了,感觉非常优雅:fbiw/box.go at main · movsb/fbiw。
1 2 3 |
|
以下是手写图像合成时AlphaBlend过程代码片段:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
虽然官方写的是Trial(免费试用),但是命令行帮助文档又写是Freeware(免费软件),这就让我很难懂。

另外,7-zip的命令行版本竟然不支持解压RAR,我明明记得以前是可以的(我专门为此下载过p7zip很多次)。
从大学拥有笔记本开始,用西部数据的硬盘比较多。但是基本上都是没过太久硬盘内部就开始作响,读取速度极慢。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
|
但是如果让AI分析一下smart信息,却又显示……很好。我认为:这基本等同于说这盘没有自恢复/重映射/磨损均衡1。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 |
|
我隐约觉得可以拯救一下:用badblocks来个全盘读写测试(可能需要几天时间),然后只把好的扇区划分出新的盘,坏的就不管了。然后把它作为BT下载盘,物尽其用。
1 2 3 4 |
|
按照这个进度,完成此4T大小的机械硬盘的读写测试需要大概520个小时。
这应该属于闪存介质层面的概念。这里借用来说明主控芯片的重分配功能是垃圾。 ^
“copy the link to this tweet” 按照语法分析,“to”是哪部分?修饰link还是copy…to语法?
这是一个很好的语法分析题。
在 "Copy the link to this tweet." 中,to this tweet 是修饰 link 的,而不是 copy 的补足语。
整个结构可以分析为:
- Copy —— 动词(祈使句)
- the link to this tweet —— 宾语(名词短语)
- the link —— 名词
- to this tweet —— 介词短语,作后置定语,修饰 link
也就是:
the link [to this tweet]
「指向这条推文的链接」
相当于:
- the key to the door(门的钥匙)
- the answer to the question(问题的答案)
- the solution to the problem(问题的解决方案)
- the road to Beijing(通往北京的路)
这里 to 表示「通向、指向、关于」。
为什么不是 "copy ... to ..."?
英语确实有 copy A to B 这种结构,例如:
- Copy the file to your desktop.
- Copy this text to the clipboard.
- Copy the photo to another folder.
这里的 to + 地点 是表示复制到哪里去,属于动词 copy 的补足语。
例如:
Copy the file to your desktop.
分析:
- Copy(动词)
- the file(宾语)
- to your desktop(地点状语,表示复制到哪里)
为什么这里不能这样理解?
如果把它理解成:
Copy
the link
to this tweet
意思就会变成:
把链接复制到这条推文里。
但实际上:
- 一条推文不是一个可以粘贴内容的目标位置;
- 在 X(Twitter)的界面中,Copy link to this tweet 是一个固定菜单项,它表示:
复制这条推文的链接。
所以这里 to this tweet 必须和 link 连在一起。
可以画成语法树
Copy └── the link └── to this tweet而不是
Copy ├── the link └── to this tweet
一个验证方法
把名词换掉就很容易看出来:
- Copy the URL to this page.
- Copy the link to this video.
- Copy the path to this folder.
这里:
- the URL to this page(这个页面的 URL)
- the link to this video(这个视频的链接)
- the path to this folder(这个文件夹的路径)
其中 to ... 都是修饰前面的名词,而不是表示复制的目标。
因此,"Copy the link to this tweet." 中的 to this tweet 是 link 的后置定语,整个名词短语 the link to this tweet 作 copy 的宾语,而不是 copy ... to ... 的句型。
那如何翻译“把链接复制到这条推文里。”?
如果要表达 “把链接复制到这条推文里。”,英语就会采用 copy A to B 的结构,其中 to 属于动词 copy。
例如:
Copy the link to this tweet.
单独看这句话其实有歧义:
- Copy [the link to this tweet].(复制这条推文的链接)✅ 在 X/Twitter 的界面中就是这个意思。
- Copy [the link] [to this tweet].(把链接复制到这条推文里。)语法上也可以分析,但语义不太自然,因为推文本身不是一个可作为目标位置的容器。
因此,英语母语者通常会把第二种意思说得更明确。
常见表达有:
- Paste the link into this tweet.(把链接粘贴到这条推文里。)⭐⭐⭐⭐⭐ 最自然
- Copy the link into this tweet.(把链接复制到这条推文里。)虽然能理解,但 copy into 不如 paste into 常见。
- Copy the link and paste it into this tweet.(复制链接,然后把它粘贴到这条推文里。)最明确。
- Paste the link into the tweet you're composing.(把链接粘贴到你正在编辑的这条推文中。)如果指的是正在写的新推文。
为什么不用
to?对于表示目标位置时:
- copy ... to ... 更常用于文件、目录、设备等,例如:
- Copy the file to your desktop.
- Copy the image to another folder.
而对于文本编辑框、邮件、聊天窗口、推文等可以输入文字的地方,英语更习惯用:
- paste ... into ...
- insert ... into ...
例如:
- Paste the URL into the email.
- Paste the code into the editor.
- Paste the link into the tweet.
所以,如果真的想表达中文的“把链接复制到这条推文里”,最地道的英语通常不是 Copy the link to this tweet,而是:
Paste the link into this tweet.
因为英语里 copy 强调“复制到剪贴板”,paste 才强调“放到目标位置”。
为什么“推文本身不是一个可作为目标位置的容器”?
这是一个涉及**英语语义习惯(selectional preference,搭配偏好)**的问题,而不是严格的语法规则。
从语法上说,Copy the link to this tweet. 完全可以分析成:
copy + the link + to this tweet
没有任何语法错误。
真正的问题是语义。
为什么说 "tweet" 不像一个目标位置?
英语里的 copy A to B,其中 B 往往是一个存放对象的地方(destination)。
例如:
- Copy the file to your desktop.
- Copy the photo to the SD card.
- Copy the folder to the USB drive.
- Copy the text to the clipboard.
这些目的地都有一个共同特点:
它们是存储对象的地方。
Tweet 更像什么?
一条已经发布的 tweet,英语母语者通常把它理解为:
一个已经存在的内容(a piece of content)
而不是
一个可以放东西进去的容器(a container)。
所以:
Copy the link to this tweet.
更容易被理解为:
the link to this tweet
(这条推文的链接)
因为 link to X 是一个极其固定的搭配:
- link to this page
- link to this article
- link to the video
- link to your profile
看到 link to,大脑几乎会立刻把它作为一个整体来解析。
如果是在编辑推文呢?
情况就不同了。
例如:
- Paste the link into the tweet.
- Paste the link into your reply.
- Paste the URL into the comment.
- Paste the code into the editor.
这里用的是 into。
为什么?
因为:
- editor(编辑器)
- comment box(评论框)
- text field(文本框)
- compose window(编辑窗口)
这些都是真正意义上的输入区域。
如果说的是:
the tweet you're writing
也可以:
Paste the link into the tweet you're writing.
这里的 tweet 实际上是借代为正在编辑的文本内容,因此 into 很自然。
为什么不用 to?
英语里:
- copy ... to ... 更强调复制到某个存储位置(文件系统、设备、剪贴板等)。
- paste ... into ... 更强调把内容插入某个文本或文档内部。
例如:
- Copy the file to Downloads.
- Paste the text into the document.
因此,如果目标是一条推文(尤其是正在编辑的推文),英语通常会说:
Paste the link into the tweet.
而不是:
Copy the link to the tweet.
所以,我之前说“推文本身不是一个可作为目标位置的容器”,更准确地说应该是:
在英语的惯用表达中,一条 tweet 通常不会和
copy ... to ...搭配来表示复制的目标;如果是往推文内容中放文字,更自然的搭配是paste ... into ...。这是一种搭配习惯,而不是语法上的禁止。事实上,如果上下文明确是在编辑一条推文,听者仍然有可能理解你的意思,只是会觉得 paste ... into ... 更符合英语的自然表达。
https://chatgpt.com/share/6a578b02-cc74-83e8-8449-1c6ca029ce12
上一次尝试使用Jellyfin1至少应该是在五年前。这两天又尝试了一下,体验了几分钟,再次放弃。
走WebDAV/Samba共享硬解直接播放的播放器可能完全不需要耗费CPU,但是用Jellyfin在网页上播放直接快要跑满了我的12核小主机,风扇直接起飞。我感觉我是吃饱了撑的,真的。

而且,明明内网网速极快,但是在网页上Seek却需要卡好几秒。这跟在线平台看有啥区别?没有……

我一个非前端都知道在URL中使用/#/home这种东西已经是非常落后的技术了,怎么还有人在用啊?
非常希望IINA出一个手机版!
更新一条:
X 上的 蓝点网:“软件资讯 开源媒体服务器项目 Jellyfin 创始团队接连离开,项目后续治理和路线变得灰暗,暂时也没有继任安排。 近期 Jellyfin 两名联合创始人和一名长期核心成员接连宣布离开,离开的原因五花八门,有个人原因,也有项目开发和社区原因。 离任后没有接任计划,这让 Jellyfin https://t.co/3wxUrFEKGn” / X
谨防有人不知道:Jellyfin简单说是一个把自己的电影文件整理成家庭影院似的播放器。 ^

心疼、肉痛!去了天才吧,她不建议我修,说需要换整个外壳,¥5000🤡。然后她又现场给我看了以旧换新:残值¥5000,补差价¥20000可以上M5同配置🤡。
你🉑拉倒吧,听你的我就是大冤种。
刚看OpenWRT版本25.12.5的更新记录1,对OpenSSL的更新有点儿吓人……
OpenSSL: update to 3.5.7, fixing multiple security vulnerabilities (CVE-2026-7383, CVE-2026-9076, CVE-2026-34180, CVE-2026-34181, CVE-2026-34182, CVE-2026-34183, CVE-2026-42764, CVE-2026-42766, CVE-2026-42767, CVE-2026-42768, CVE-2026-42769, CVE-2026-42770, CVE-2026-45445, CVE-2026-45446, CVE-2026-45447).
虽然没看具体是什么问题,但是感觉OpenSSL这堆屎山迟早会再次掀起像几年前的“心脏流血”事件一样的重大互联网安全事故。
年纪大了,牙周不太好,所以去了一次医院做个正经的牙周治疗,但我感觉就是个稍微专业点的洗牙?相比于机构的50块钱的洗牙并没有太大区别?


噢对了,这仅是单次的,上周还做了一次。所以到目前为止,一共花了¥2000. 😭
感觉手被紫外线烤得特别烧,不知道每个月不停换美甲、出门又戴防晒的是怎么想的。
怎么样,好看吗?![doge [doge]](/v3/dynamic/emojis/weixin/doge.png)
![doge [doge]](/v3/dynamic/emojis/weixin/doge.png)
![doge [doge]](/v3/dynamic/emojis/weixin/doge.png)
在深圳的路边停车,我发现有个非常奇怪的现象:
终于找到了一个能找到的最便宜的车位:300/月,在公园内。
悬着的心终于放下来了……
最开始的时候服务器只有nginx一个必要组件;后来把http2tcp装进去了,为的是能让ssh走https连接,尽量防止服务器被屏蔽;再后来又加上了http2socks,它能基于1条http2tcp连接mux出多条tcp连接,作为SOCKS协议使用;再再后来还加上了类似hysteria这种第三方组件。所以,维护成本就变得更高了;二进制文件分散、配置文件分散,特别是有多台服务器的时候,每台都需要重新弄一遍,很是麻烦。
拖了很久,今晚才抽空把它们全部装进了一个名为“serverd”的容器中。里面同时包含了服务器证书、各种配置文件,所以这个容器是个私有容器。靠在本地build后save到文件然后load到服务器。
感觉极大地降低了心智负担。
以前还没那么明显,老实说。因为加了商家的群,偶尔有人会交流经验,然后我就会经常留意到最新的价格。
我去年买的时候是170左右,后面因为内存原因一波涨到250,持续了很久。这几天为了迎接618,直接拉爆了。只能说,平台跟商家没一个好东西。


时间刚好是半年零半个月。难受,焦虑😐。
不知道是不是最近打游戏导致的…

我决定卸载游戏。
怎么说呢,感觉是最近看过的最朴素、无感的一部剧了。
虽然说名字是音乐剧,但是就我而言,我感觉音乐一点都不好听。全程是那种打击乐➕跺脚表演,没有起伏,没有递进。听了不到半小时我就已经坐不住了,后面干脆迷迷糊糊开始睡觉了。
再说剧情,真实的表演我其实没太看懂,章节之间比较割裂。看了门票/海报上的介绍才知道这是一个出轨剧,我去……
噢,还有一点。我发现我不喜欢法语。口齿好像非常不清晰,舌头👅在打架式地绕圈子,以至于让不懂法语的人有一种听起来完全没有抑扬顿挫的感觉,所以又给整个剧更徒增了乏味。


必须再重听一遍《摇滚红与黑 | 法语音乐剧》涤荡一下我的心灵。

笑死我了,这游戏是不是已经没有太多人玩了?
超凡大师?信不信马上超鬼给你看,不说假话。
最强王者🤴

很感人、很催泪。

到底怎么读,打一架吧要不?



我拍的:


谢幕:
剧照:



















所以binwalk是个什么工具啊,为什么需要安装这么多附加包,太吓人了……
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 |
|
我想念 AlpineLinux APK。
AlpineLinux 上没有 binwalk 这个包 🤡。
结果没几天就掉地上摔了个狗吃屎,这质量……



老实说,我已经很多很多年没有见过这种“牛屎”型封装的芯片了,成本节省到了极致。
这应该是第二次吃吧,第一次是2024年在埃及的赫尔格达。


这龙虾还真好看,身体竟然是彩色的。

强如苹果词典中的牛津词典对“Attack”在乐理中的含义也没有比较准确的释义,难怪八年前我看着全英文的百科一头雾水。


“Envelope”是另外一个当时完全不知道如何理解的词。
不然的话,音乐的模拟怎么也不应该缺席。不会只写了个开头就八年没再动过了。当然,现在更不会有时间去研究了。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
项目地址:movsb/taones。
银梅塘茶行记
遇事不决泥岗E,
春风不语茶光D;
峰回路转梅林B,
径通幽处桃源D。

这条路有超过20公里长,大部分是像下面这样的起起伏伏,很舒服,一点不热。

今天背了个50mm的定焦,所以大部分是近距离拍摄。


















感觉最难打的是愚人斗兽场(三)吧,感觉前前后后、断断续续打了几个月。


我只能说,差不多是半睡半清醒看完的吧,总体剧情递进过程还是清楚。
所以结论是:我还是不太喜欢类似的科幻、星球类电影。这样类似的还包括:《流浪地球🌍️》、《星际穿越》。
都尝试过认真看,后面两部真的是只看了半个小时就睡着了,很助眠。
起因是尝试了一下用do-release-upgrade把Ubuntu升级到最新的系统,用ssh远程升级的,升级过程中ssh被断开,且2222备用端口几分钟内也连接不上后,我尝试了重启系统,然后……系统就挂掉了,启动不了了。一气之下dd了一个最新的AlpineLinux到U盘中,然后把系统一键重装了。
太轻松了,系统极致的轻量。当然,musl和glibc的问题后面再解决。
一直觉得microk8s很好用,k3s很难用。但是没想到现在又多了个k0s,尝试了一下,远比k3s还要简单。暂时就用它了。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
U盘、运行在内存中的AlpineLinux居然不能识别wlan0接口(Wi-Fi),被迫用有线网络连上后才安装成功。有点离谱,什么年代了,WiFi比有线连接更容易接入好吗。但是,安装成功后却能自动识别到。








