[U] Update channel content

This commit is contained in:
github-actions
2026-01-04 00:23:52 +00:00
parent fca149345e
commit 4cd50af7af
4 changed files with 40 additions and 14 deletions
+11 -1
View File
@@ -2,11 +2,21 @@
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="zh-cn">
<id>https://aza.moe/life</id>
<title>小桂桂的回忆录 📒</title>
<updated>2026-01-03T22:20:37.682607+00:00</updated>
<updated>2026-01-04T00:23:48.697507+00:00</updated>
<link href="https://aza.moe/life" rel="alternate"/>
<generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator>
<logo>https://aza.moe/meru_256px.png</logo>
<subtitle>「我们所经历的每个平凡的日常,也许就是连续发生的奇迹」</subtitle>
<entry>
<id>7661</id>
<title>小桂桂的回忆录 📒 #7661</title>
<updated>2026-01-04T00:23:12+00:00</updated>
<content>&lt;p&gt;前几天有人提到 &lt;a href="https://zh.wikipedia.org/wiki/2038%E5%B9%B4%E9%97%AE%E9%A2%98"&gt;Y2038 问题&lt;/a&gt;,就是用 int32 存储时间戳的程序在 2038-01-19 之后会溢出回到 1970 或者 1901 年的问题。当时还觉得肯定没事,毕竟至少我已经不记得上次见到 32 位系统和用 int32 存储时间的程序是什么时候了&lt;/p&gt;
&lt;p&gt;但是今天看着日历发呆的时候就在想,难道 int64 就真的够吗?虽然几乎所有程序都换成用 int64 存时间戳了,但是随着能存储的信息增加,大家期望的精度也上升了...之前用 int32 存的是秒,现在至少我写的程序获取时间的时候都是用纳秒 (1ns = 10^-9s),但是这么高精度即使用 int64 存也依然很有限,到 2262 年也依然会出现同样的溢出问题...&lt;/p&gt;
&lt;p&gt;到那时候 int128 会已经普及了吗?精度会继续增加吗?还是会直接跳过它用 int256 去存「时间的最小单位」普朗克时间呢?那时候的个人计算设备还会是二进制半导体计算机吗?&lt;del&gt;会不会在宇宙的尽头,在 292,277,026,596 年后,依然会有某台飘在无尽虚空中的放射发电机器人突然回到 1970 呢?&lt;/del&gt;&lt;/p&gt;
&lt;p&gt;...一年在时间的 scale 下真的好短好短&lt;/p&gt;</content>
<link href="https://aza.moe/life?post=7661" rel="alternate"/>
</entry>
<entry>
<id>7660</id>
<title>小桂桂的回忆录 📒 #7660</title>
File diff suppressed because one or more lines are too long
+18 -11
View File
@@ -85393,7 +85393,7 @@
"id": 6255,
"date": "2025-08-18T04:50:47",
"text": "clash-verge-rev 还有后续 <i class=\"custom-emoji\" emoji-src=\"emoji/5327839194758783219.webm\">🔥</i>\n\n在 Windows 上卸载 clash-verge-rev 2.3.2 的时候会删除整个用户开始菜单目录,会导致开始菜单被清空 <i class=\"custom-emoji\" emoji-src=\"emoji/6320856404055820121.webp\">😨</i>\n\n翻了一下源码,发现这个问题三周前<a href=\"https://github.com/clash-verge-rev/clash-verge-rev/commit/9661c5fd82bb6e3622c87cdb4767be6bf4ae686f\">在代码里修复了</a>,但是目前还没有发布带修复的正式版本。\n\n只有这一个版本有问题,这个版本之前卸载会留一个坏的链接在开始菜单里。如果你在 2.3.2 想要卸载的话,先覆盖安装<a href=\"https://github.com/clash-verge-rev/clash-verge-rev/releases/tag/autobuild\">预览版 2.4.0-autobuild</a> 再卸载就不会有问题了 <i class=\"custom-emoji\" emoji-src=\"emoji/6170075684434610033.webm\">⌨</i>\n\n(感谢 <a href=\"https://t.me/baked_3c\">@baked_3c</a> 投稿",
"views": 8394,
"views": 8395,
"forwards": 174,
"media_group_id": 14043941176651549,
"images": [
@@ -101716,7 +101716,7 @@
{
"id": 7586,
"date": "2025-12-25T19:22:09",
"views": 238,
"views": 239,
"forwards": 2,
"files": [
{
@@ -101797,7 +101797,7 @@
"id": 7591,
"date": "2025-12-27T06:40:25",
"text": "<del>《后天》灾难现场</del>\n\n...实际上只是多伦多的一般雪天",
"views": 216,
"views": 217,
"forwards": 1,
"media_group_id": 14134541001383469,
"images": [
@@ -101907,7 +101907,7 @@
"id": 7601,
"date": "2025-12-27T14:50:47",
"text": "🐈‍⬛️",
"views": 231,
"views": 232,
"forwards": 1,
"media_group_id": 14134776379626749,
"images": [
@@ -102259,14 +102259,14 @@
"id": 7628,
"date": "2026-01-01T02:05:47",
"text": "我要进入冬眠,明年叫醒我 <i class=\"custom-emoji\" emoji-src=\"emoji/6323364467388188938.webp\">😴</i>",
"views": 182,
"views": 184,
"forwards": 0
},
{
"id": 7629,
"date": "2026-01-01T06:02:05",
"text": "新年快乐!",
"views": 172,
"views": 176,
"forwards": 1,
"images": [
{
@@ -102285,7 +102285,7 @@
"id": 7634,
"date": "2026-01-01T18:53:18",
"text": "昨天的新年花火小会会!风真的超级大超级冷,从照片就能看出风有多大 🌚\n\n是和聊聊豆腐猫球松鼠一起去的,实际上对花火本身很失望,烟花真的太少了,而且一共只有两艘船在放。多伦多市资助的过年烟花还没有之前在北海道洞爷湖那边每晚一次的烟花规模大... 这种时候就好想念日本\n\n不过见到了很久没有见到的朋友,还拍到了好看照片,总之还是很开心啦 qwq\n\n以及能看出多伦多市政很用心,专门安排了免费公交地铁和「跨年快线」NYE EXPRESS(跨年快线听上去像是什么坐上去可以带我去下一年的时光机草)也确实有很多人挤在湖边看烟花... 要是烟花的规模可以对得起这么多人就好了",
"views": 140,
"views": 143,
"forwards": 3,
"media_group_id": 14138348790329469,
"images": [
@@ -102465,7 +102465,7 @@
"id": 7650,
"date": "2026-01-02T03:18:32",
"text": "<a href=\"##桂桂今天吃什么\">#桂桂今天吃什么</a>\n锅!(日式火锅!)\n\nTracer 和 Celestium 过来一起吃了。感觉日式火锅也是好吃又好做又便宜又 scalable,四个人吃的食材总共花了不到 $30 <i class=\"custom-emoji\" emoji-src=\"emoji/6111506770197219135.webm\">😮</i>\n\n怪不得摇曳露营里面喜欢在露营的时候煮锅 qwq",
"views": 161,
"views": 163,
"forwards": 2,
"media_group_id": 14138591297711077,
"images": [
@@ -102545,7 +102545,7 @@
"id": 7657,
"date": "2026-01-02T20:59:57",
"text": "窗户上刷了大蜗牛",
"views": 157,
"views": 163,
"forwards": 0,
"media_group_id": 14139100780291061,
"images": [
@@ -102575,7 +102575,7 @@
"id": 7659,
"date": "2026-01-03T04:58:35",
"text": "谷歌搜索 OrcaSlicer 前五个结果哪个是官网?\n\n1. <code>orca-slicer.com</code>\n2. <code>orcaslicer.net</code>\n3. <code>orcaslicer.org</code>\n4. <code>orcaslicer3d.com</code>\n5. <code>orcaslicer.pro</code>\n\n答:<span class=\"spoiler\"><span>全都不是!正确答案是 `orcaslicer.com`,还是去 github repo 上找到的,翻了十页都没找到</span></span>",
"views": 142,
"views": 156,
"forwards": 3,
"images": [
{
@@ -102594,7 +102594,7 @@
"id": 7660,
"date": "2026-01-03T18:14:49",
"text": "哭了,好讨厌苹果\n\nmenci 的苹果 pencil pro 不怎么用就送给我了。但是也因为她不怎么用,拿到的时候电池已经掉到 0% 了,充两天充不上电\n\n去线下找保修,发现保修只有一年... 然而因为 menci 是一年半之前买的,以及没有任何设备上了 Apple care,修的话要 $149 <i class=\"custom-emoji\" emoji-src=\"emoji/6320856404055820121.webp\">😨</i>(买一个全新的只要 $159",
"views": 79,
"views": 103,
"forwards": 0,
"images": [
{
@@ -102608,5 +102608,12 @@
"thumb": "media/7660.jpg_thumb.jpg"
}
]
},
{
"id": 7661,
"date": "2026-01-04T00:23:12",
"text": "前几天有人提到 <a href=\"https://zh.wikipedia.org/wiki/2038%E5%B9%B4%E9%97%AE%E9%A2%98\">Y2038 问题</a>,就是用 int32 存储时间戳的程序在 2038-01-19 之后会溢出回到 1970 或者 1901 年的问题。当时还觉得肯定没事,毕竟至少我已经不记得上次见到 32 位系统和用 int32 存储时间的程序是什么时候了\n\n但是今天看着日历发呆的时候就在想,难道 int64 就真的够吗?虽然几乎所有程序都换成用 int64 存时间戳了,但是随着能存储的信息增加,大家期望的精度也上升了...之前用 int32 存的是秒,现在至少我写的程序获取时间的时候都是用纳秒 (1ns = 10^-9s),但是这么高精度即使用 int64 存也依然很有限,到 2262 年也依然会出现同样的溢出问题...\n\n到那时候 int128 会已经普及了吗?精度会继续增加吗?还是会直接跳过它用 int256 去存「时间的最小单位」普朗克时间呢?那时候的个人计算设备还会是二进制半导体计算机吗?<del>会不会在宇宙的尽头,在 292,277,026,596 年后,依然会有某台飘在无尽虚空中的放射发电机器人突然回到 1970 呢?</del>\n\n...一年在时间的 scale 下真的好短好短",
"views": 5,
"forwards": 0
}
]
+10 -1
View File
@@ -12,7 +12,16 @@
<link>https://aza.moe/life</link>
</image>
<language>zh-cn</language>
<lastBuildDate>Sat, 03 Jan 2026 22:20:37 +0000</lastBuildDate>
<lastBuildDate>Sun, 04 Jan 2026 00:23:48 +0000</lastBuildDate>
<item>
<title>小桂桂的回忆录 📒 #7661</title>
<link>https://aza.moe/life?post=7661</link>
<description>&lt;p&gt;前几天有人提到 &lt;a href="https://zh.wikipedia.org/wiki/2038%E5%B9%B4%E9%97%AE%E9%A2%98"&gt;Y2038 问题&lt;/a&gt;,就是用 int32 存储时间戳的程序在 2038-01-19 之后会溢出回到 1970 或者 1901 年的问题。当时还觉得肯定没事,毕竟至少我已经不记得上次见到 32 位系统和用 int32 存储时间的程序是什么时候了&lt;/p&gt;
&lt;p&gt;但是今天看着日历发呆的时候就在想,难道 int64 就真的够吗?虽然几乎所有程序都换成用 int64 存时间戳了,但是随着能存储的信息增加,大家期望的精度也上升了...之前用 int32 存的是秒,现在至少我写的程序获取时间的时候都是用纳秒 (1ns = 10^-9s),但是这么高精度即使用 int64 存也依然很有限,到 2262 年也依然会出现同样的溢出问题...&lt;/p&gt;
&lt;p&gt;到那时候 int128 会已经普及了吗?精度会继续增加吗?还是会直接跳过它用 int256 去存「时间的最小单位」普朗克时间呢?那时候的个人计算设备还会是二进制半导体计算机吗?&lt;del&gt;会不会在宇宙的尽头,在 292,277,026,596 年后,依然会有某台飘在无尽虚空中的放射发电机器人突然回到 1970 呢?&lt;/del&gt;&lt;/p&gt;
&lt;p&gt;...一年在时间的 scale 下真的好短好短&lt;/p&gt;</description>
<guid isPermaLink="false">7661</guid>
</item>
<item>
<title>小桂桂的回忆录 📒 #7660</title>
<link>https://aza.moe/life?post=7660</link>