每周完成一个 ARTS: 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。(也就是 Algorithm、Review、Tips、Share 简称 ARTS)

一些细节:
1)咱们不知道 head 也不需要知道
2)如果 cur 的值等于需要删除的 node 的值,那么怎么操作呢?
1、咱们不需要返回 head 这个方法是 void
2、如果咱们的需要替换格子 B 那么现在需要把 B 的 next 设置成 D
格子A 格子B 格子C 格子D
[4] → [5] → [1] → [9]
↑
node(只能动 B)3、咱们现在需要最终效果是:A → C → D
那么如果是只能修改 B 和 C,那么咱们直接把 C 的内容设置到 B 即可
/**
* Definition for singly-linked list.
* public class ListNode {
* int val;
* ListNode next;
* ListNode(int x) { val = x; }
* }
*/
class Solution {
public void deleteNode(ListNode node) {
ListNode cur = node;
while (cur != null) {
if (cur.val == node.val) {
cur.val = cur.next.val;
cur.next = cur.next.next;
return;
}
cur = cur.next;
}
}
}文章: https://oldblog.antirez.com/post/redis-persistence-demystified.html
核心就一句话:写进内存不算安全,write() 只扛进程挂,fsync() 才扛断电;Redis 默认 AOF everysec,最坏丢 2 秒,和 Postgres / MySQL 调完参数之后其实差不多。
大概分为 5 步:
步骤二是设计会非常复杂,有时候会使用其他的线程进行操作
步骤三是 kernel 实现的,一般会有很多层。在 Linux 系统中,一般是文件系统的 page cache,也是使用缓存等到何时的时机再进行提交到磁盘。有些数据库会自己实现这个层,就使用文件系统的 page cache。也有 API 可以跳过 page cache 直接写入数据,比如 O_DIRECT 和 O_SYNC
步骤五,只有执行到步骤五才能说数据是完全安全的,正常情况下执行完步骤三,一般就没有什么问题了。
POSIX API
步骤三:我们可以使用 POSIX API 进行控制,但是我们能控制的有限。比如我们进行系统调用把内容写到文件里面,但是内核写缓冲区的大小是有限的,如果磁盘无法应对应用程序的写入带宽,内核写缓冲区将达到其最大容量,内核就会阻塞我们的写入。这个时候如果有更多的数据来了之后,那么系统就会拒绝这个写入请求。
步骤四:一般来说写入不会太频繁,因为大块的内容写入速度更快。对于 Linux 系统来说默认 30 秒 ,也就是说如果在 30 秒内出现问题,数据还是可能会丢失的。
当然也有办法控制,可以使用 POSIX API 控制立刻写入数据,但是这个 fsync 操作非常消耗资源。
步骤五:严格来说,从这个角度来看,我们无法通过 POSIX API 对其进行控制。也许某些内核实现会尝试告诉驱动器,实际将数据提交到物理介质上,或者控制器反而会为了速度而重新排序写入操作,并不会尽快将数据真正写入磁盘,而是再等待几毫秒。这完全超出了我们的控制范围。
1)现在 Cursor 支持可以不导入其他 agent 工具的 skills,要不然在 claude 里面的内容全部都跑到 Cursor 里面了。我个人是更习惯分开的,分开便于管理并且不会让 Cursor 的上下文无端增加很多上下文占用。

2)跨会话 skills 推荐:/handoff ,Github 开源地址 内容很简单,如下:
---
name: handoff
description: Write or update a handoff document so the next agent with fresh context can continue this work.
---
Write or update a handoff document so the next agent with fresh context can continue this work.
Steps:
1. Check if HANDOFF.md already exists in the project
2. If it exists, read it first to understand prior context before updating
3. Create or update the document with:
- **Goal**: What we're trying to accomplish
- **Current Progress**: What's been done so far
- **What Worked**: Approaches that succeeded
- **What Didn't Work**: Approaches that failed (so they're not repeated)
- **Next Steps**: Clear action items for continuing
Save as HANDOFF.md in the project root and tell the user the file path so they can start a fresh conversation with just that path.文章:https://annas-archive.gl/blog/physical-destruction.html
核心就一句话:AI 公司在大批买二手书,拆脊扫描后再毁掉纸本,把 2022 年前「没被机器污染」的文字锁进私有服务器;Anna’s Archive 呼吁全球志愿者抢先扫书上传。
Anthropic 的 Project Panama 在 15 亿美元版权和解里被曝光:花几千万买几百万本纸书,训练 Claude,再全部销毁。法官认定合法买书、扫完毁原件算合理使用,破坏性扫描因此比无损扫描更便宜、更能挡住对手、法律风险也更小。纸书没了,数字副本只留公司内部,知识就被永久垄断。作者说这是跟时间赛跑:每人扫一本,一千万志愿者就是一千万份遗产。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。