https://youtu.be/RFjAqth-EQk?si=2t6n0ybkfgkNrh6s
看了部关于 Nord Stream pipelines 爆炸案的纪录片,制作方是德国的 DW。
可以很明显地感受到,制片人基本上已经主观认定是乌克兰所为了。一个贴有乌克兰军人照片的护照持有者,租了一辆小游艇两个星期,这艘游艇足以实施这次袭击。而且,租借游艇的机构和金钱都来自于乌克兰。
但是,也有安全专家提示,你们这么轻易地调查就得出了这些线索,很可能是对方设下的圈套。比如故意留下乌克兰的蛛丝马迹,让你以为这是乌克兰所为。
而德国政府对北溪案件持严格保密态度,更让人怀疑是在故意隐瞒一些信息。
不过这案子难查的一个主要因素是,北溪管道实在太容易破坏了,甚至可以说任何一个有意向的组织,投入很少的资金,就可以完成。家庭作坊制造炸弹,能搞定 70 米海水的潜水员,租借一艘小游艇,足矣。
看了部关于 Nord Stream pipelines 爆炸案的纪录片,制作方是德国的 DW。
可以很明显地感受到,制片人基本上已经主观认定是乌克兰所为了。一个贴有乌克兰军人照片的护照持有者,租了一辆小游艇两个星期,这艘游艇足以实施这次袭击。而且,租借游艇的机构和金钱都来自于乌克兰。
但是,也有安全专家提示,你们这么轻易地调查就得出了这些线索,很可能是对方设下的圈套。比如故意留下乌克兰的蛛丝马迹,让你以为这是乌克兰所为。
而德国政府对北溪案件持严格保密态度,更让人怀疑是在故意隐瞒一些信息。
不过这案子难查的一个主要因素是,北溪管道实在太容易破坏了,甚至可以说任何一个有意向的组织,投入很少的资金,就可以完成。家庭作坊制造炸弹,能搞定 70 米海水的潜水员,租借一艘小游艇,足矣。
https://laisky.notion.site/What-We-Got-Right-What-We-Got-Wrong-4a44534fca40489eb2302161512e662b?pvs=4
Rob Pike 在 2023 年 11 月的一次内部演讲稿,回顾 Golang 14 年的历程,没什么技术内容,热爱 Golang 的人可以读一读。
Pike 强调发明 Go 是为了解决 Google 所面临的超大规模团队的工程问题。而在今天看来,有很多人批评 Go 的语法,却几乎没人批评 Go 的工程化能力,这可以看作初创者们的初衷已经圆满实现了。
因为 Google 内部使用 monorepo,导致初创团队对于依赖管理经验不足,也严重低估了其复杂性,所以早期 Go 是没有多版本依赖管理的,直到后来实现了 gomodule。
在并发问题上,Pike 再次推荐了经典论文 CSP,并且认为 async/await 的写法实际上是把复杂性交给了程序员。(我倒是觉得 async/await 在手写调度时实际上比 CSP 简单)
还有就是作者认为 interface 已经足够了,但是迫于社区压力引入了范型,范型和 interface 的兼容很成问题,为此付出了大量的努力。
关于 Golang 和 Google 的关系,Pike 总结为:the core Go team is paid by Google but they are independent。Google 付钱,但并不干涉,Golang 是完全由社区主导的。
BTW,Rob Pike 已经 68 岁了,据说已经退休,近年来已经很少露面。
Rob Pike 在 2023 年 11 月的一次内部演讲稿,回顾 Golang 14 年的历程,没什么技术内容,热爱 Golang 的人可以读一读。
Pike 强调发明 Go 是为了解决 Google 所面临的超大规模团队的工程问题。而在今天看来,有很多人批评 Go 的语法,却几乎没人批评 Go 的工程化能力,这可以看作初创者们的初衷已经圆满实现了。
因为 Google 内部使用 monorepo,导致初创团队对于依赖管理经验不足,也严重低估了其复杂性,所以早期 Go 是没有多版本依赖管理的,直到后来实现了 gomodule。
在并发问题上,Pike 再次推荐了经典论文 CSP,并且认为 async/await 的写法实际上是把复杂性交给了程序员。(我倒是觉得 async/await 在手写调度时实际上比 CSP 简单)
还有就是作者认为 interface 已经足够了,但是迫于社区压力引入了范型,范型和 interface 的兼容很成问题,为此付出了大量的努力。
关于 Golang 和 Google 的关系,Pike 总结为:the core Go team is paid by Google but they are independent。Google 付钱,但并不干涉,Golang 是完全由社区主导的。
BTW,Rob Pike 已经 68 岁了,据说已经退休,近年来已经很少露面。
https://chat.laisky.com/ 狗屁通套皮站可以跨设备同步所有的配置和对话记录了。
之前支持了各个会话保存独立的设置,这样就可以开一堆会话,然后通过 system prompt 给每个会话定义不同的角色。用起来虽然很爽,但是每个设备都得这么设置一次很烦,所以同步设置成了必要的。
现在可以通过 sync key 同步记录和设置,使用相同的 sync key 就可以拉取相同的记录,所有的记录在云上都使用 AES-256 加密,密钥就是 sync key,无需担心隐私。
Ps. 视频里出现的 sync key 我已经销毁了,不用费劲黑我了。
之前支持了各个会话保存独立的设置,这样就可以开一堆会话,然后通过 system prompt 给每个会话定义不同的角色。用起来虽然很爽,但是每个设备都得这么设置一次很烦,所以同步设置成了必要的。
现在可以通过 sync key 同步记录和设置,使用相同的 sync key 就可以拉取相同的记录,所有的记录在云上都使用 AES-256 加密,密钥就是 sync key,无需担心隐私。
Ps. 视频里出现的 sync key 我已经销毁了,不用费劲黑我了。
https://free-for.dev/#/ 免费 SaaS 服务索引,独立开发者的省钱宝典。
https://chat.laisky.com/# 套皮站支持自定义 session 名了,而且在左侧会显示快速切换按钮。每个 session 都可以有独立的模型选择和配置(比如 system prompt),你可以给不同的会话设置不同的角色,这样在不同的任务间切换会更方便。
这站现在成我的日常娱乐了,有空就写几行垃圾代码,我自己用着舒服就行,缺啥加啥,哈哈哈哈。
next: https://t.me/laiskynotes/135
这站现在成我的日常娱乐了,有空就写几行垃圾代码,我自己用着舒服就行,缺啥加啥,哈哈哈哈。
next: https://t.me/laiskynotes/135
具体情况是,我修好后用了一天都没问题,让我以为修好了。但后来发现只要待机个五分钟后就会卡死。再后来发现不仅仅是待机,我在桌面上做一些轻度操作也会卡死,而我做一些需要大量 CPU 和磁盘 I/O 的操作就没事儿。然后我猜想是 win11 存在一些隐藏的省电策略,发现你负载低时就会触发,然后这个功能有致命 bug,会导致系统卡死。
基于这个猜想,我在 terminal 里跑了一个死循环,会稳定地吃掉一个核。然后奇迹发生了,这台 PC 从昨晚放置到现在都没死!
Ps. 我已经关闭了系统设置里所有的节能选项,sleep 全部设置为 never,power mode 为 best performance,但都没用。
补充:不是 win 的问题,是 CPU + 主板的问题。主板会自动调整 CPU 的电压,然后 CPU 在低电压时会卡死。
不知道为什么升级 win11 后立刻就出现了这个问题,可能是 win11 把我的主板 or CPU 驱动给静默升级了。
在 BIOS 设置里把 CPU 频率的 Auto 改成一个固定值就没问题了。
最近几天都在折腾修电脑。
我家里有一台不关机的 win10 服务器,上面用 vmware player 跑了一台 ubuntu 作为我的主开发机。平时我随身带一台 macbook air,可以用 tailscale 连到这台 ubuntu 上远程开发。
前阵子我手贱点了升级到 win11。自从升级完成后,每天半夜这台 win11 都会完全卡死(freeze),只能长按电源强制关机再重启。后来忍无可忍用 win10 的启动盘重装了,但是自从重装了 win10 起,死机变得越来越频繁,逐渐从刚开始的一天一次变成了几分钟一次,最后连系统启动过程中都可能卡死,最夸张的时候 UEFI 一加载 OS 开始转圈就死了。
我琢磨着估计是 win11 把我硬件损坏了,中间略去无数插拔、更换硬件寻找问题的过程。直到今天,我用 win11 启动盘重装了 win11 后,一切问题突然自动消失了。
没能最终定位到问题,盲猜是初次升级时出现不兼容问题,同时 win11 修改了 UEFI 里的一些配置,让硬件无法再兼容 win10 ,重装 win11 后就好了。(我把老硬件全装回去了也没问题,看来硬件都没坏)
顺带推荐一个在 mac 下制作 windows 启动 U 盘的工具:
https://github.com/TechUnRestricted/windiskwriter
只要从 MS 官网下载系统镜像 iso 文件,就可以直接在 mac 上用 U 盘制作 window 启动盘了,U 盘可以使用 FAT32 格式。
next: https://t.me/laiskynotes/130
我家里有一台不关机的 win10 服务器,上面用 vmware player 跑了一台 ubuntu 作为我的主开发机。平时我随身带一台 macbook air,可以用 tailscale 连到这台 ubuntu 上远程开发。
前阵子我手贱点了升级到 win11。自从升级完成后,每天半夜这台 win11 都会完全卡死(freeze),只能长按电源强制关机再重启。后来忍无可忍用 win10 的启动盘重装了,但是自从重装了 win10 起,死机变得越来越频繁,逐渐从刚开始的一天一次变成了几分钟一次,最后连系统启动过程中都可能卡死,最夸张的时候 UEFI 一加载 OS 开始转圈就死了。
我琢磨着估计是 win11 把我硬件损坏了,中间略去无数插拔、更换硬件寻找问题的过程。直到今天,我用 win11 启动盘重装了 win11 后,一切问题突然自动消失了。
没能最终定位到问题,盲猜是初次升级时出现不兼容问题,同时 win11 修改了 UEFI 里的一些配置,让硬件无法再兼容 win10 ,重装 win11 后就好了。(我把老硬件全装回去了也没问题,看来硬件都没坏)
顺带推荐一个在 mac 下制作 windows 启动 U 盘的工具:
https://github.com/TechUnRestricted/windiskwriter
只要从 MS 官网下载系统镜像 iso 文件,就可以直接在 mac 上用 U 盘制作 window 启动盘了,U 盘可以使用 FAT32 格式。
next: https://t.me/laiskynotes/130
https://laisky.notion.site/The-Pulse-Will-US-companies-hire-fewer-engineers-due-to-Section-174-5082d31da80245e5889c218769f16262?pvs=4
关于美国税法新规 Section 174 对科技公司带来灭顶之灾。
川普在 2017 年提出的减税法案,使得税务局修订了征税标准,要求严格执行 S174。这一修订于 5 年后的 2022 年生效,而 2022 财年于 2023 年结算,导致很多公司在 2023 年收到了巨额税单,这也是造成 2023 裁员潮的一大原因。
S174 的最重要内容就是研发成本摊销,要求将美国内研发成本平摊到未来 5 年,美国以外地区的研发成本平摊到 15 年。简而言之,一家在年度内收支相抵零利润的公司,在税表上会表现为盈利,盈利额为 80% 的研发成本,这是因为当年的研发成本在每年只计算 20%。
S174 事实上给科创公司造成了财务重负,美国很可能会迎来一波出海潮,将科创公司主体设置在海外,从而规避 S174。
关于美国税法新规 Section 174 对科技公司带来灭顶之灾。
川普在 2017 年提出的减税法案,使得税务局修订了征税标准,要求严格执行 S174。这一修订于 5 年后的 2022 年生效,而 2022 财年于 2023 年结算,导致很多公司在 2023 年收到了巨额税单,这也是造成 2023 裁员潮的一大原因。
S174 的最重要内容就是研发成本摊销,要求将美国内研发成本平摊到未来 5 年,美国以外地区的研发成本平摊到 15 年。简而言之,一家在年度内收支相抵零利润的公司,在税表上会表现为盈利,盈利额为 80% 的研发成本,这是因为当年的研发成本在每年只计算 20%。
S174 事实上给科创公司造成了财务重负,美国很可能会迎来一波出海潮,将科创公司主体设置在海外,从而规避 S174。
优化了一下 github action
设置 commit 的 7 位短 hash 作为 docker image tag:
将 docker layers 在 github action cache 里缓存:
设置 commit 的 7 位短 hash 作为 docker image tag:
- name: Add SHORT_SHA env property with commit short sha
run: echo "SHORT_SHA=`echo ${GITHUB_SHA} | cut -c1-7`" >> $GITHUB_ENV
将 docker layers 在 github action cache 里缓存:
-
name: Build and push hash label
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: YOUR_IMAGE_NAME:${{ env.SHORT_SHA }}
cache-from: type=gha
cache-to: type=gha,mode=max
又学到一个 python 的 trick,finally 始终会执行,甚至能重写 return。
今天学到一个 Go 的
如果要进行时间比较,
已加入到合集本:https://blog.laisky.com/p/golang-race/
time.Parse
坑。虽然 time.RFC3339
里并没有定义毫秒,但如果被解析的字符串包含毫秒,那么解析结果实际上也会包含毫秒。带毫秒的解析结果和不带毫秒的解析结果是不相等的。如果要进行时间比较,
Parse
后需要手动通过 Truncate
来修订精度ts2 = ts2.Truncate(time.Second)
已加入到合集本:https://blog.laisky.com/p/golang-race/
学到一个前端 UX 小知识,绑定 SHIFT+ENTER 触发在 input 里是一个非常糟糕的设计。因为英文键盘里,按一次换行就会自动激活 SHIFT,此时如果再按一次换行就成了 SHIFT+ENTER。如果你绑定了这个按键组合,就会导致用户误触。
1. cost management 会滞后 billing period 5 天,budget 同理。所以你没看到花钱,不代表不扣你钱。(和之前的结论一致)
上次我的结论中有一些需要修订的地方:
1. 目前 Azure OpenAI 的服务价格列表参见 https://azure.microsoft.com/en-us/pricing/details/cognitive-services/openai-service/
2. gpt-3.5-turbo 升级最新版本 1106 后,默认 context 就是 16K,而且价格比此前的 gpt-3.5-turbo 和 gpt-3.5-turbo-16k 都更便宜。
经过我“吹毛求疵”的争论后,Azure 反馈承认他们不但搞错了计价,还搞错了 invoice 中的模型名称,所以此前产生了很多误解。
记了一篇博文:https://blog.laisky.com/p/azure-billing/
就目前最常用的 gpt-3.5 和 gpt-4 而言,实际上只需要使用三个模型就足够了:
1.
gpt-4-1106-preview
: 支持 128K context,而且是最便宜的 gpt-42.
gpt-4-vison-preview
: 价格同 gpt-4-1106-preview3.
gpt-3.5-turbo-1106
: 支持 16K context,而且是最便宜的 gpt-3.5Ps. 我套皮站上也做了更新,openai 目前只支持这三个模型了。我的 oneapi 网关上还另外支持 text-embedding-ada-002、dall-e-3、gemini-pro 和 gemini-pro-vision。顺带一提,如果你使用 gpt-3.5-turbo-16k-0613 或 gpt-3.5-turbo-0301 实际上会被自动转发给 gemini-pro,这是为了可以免费使用如 gptcommit 这种仅支持 gpt 的工具。
https://devv.ai/
正好这篇文章在 devv.ai 上遇到了很经典的 RAG 幻觉。
devv.ai 是基于网页抓取的 RAG 应用。我问他“什么是 ROG”,它很正确地抓取到了这个网页。但是这个网页中大篇幅都是描写 RAG 和 RCG 的内容,仅有两句话提到了 ROG。而 devv.ai 显然被误导了,它使用 RCG 的内容来描述 ROG,生成了完全错误的答复。
虽然 devv.ai 是一个很好用的平台,但是通过这个案例可以了解到,基于 RAG 是无法避免幻觉的。好在 RAG 提供了透明性,你还是要自己去查阅一下来源,自行判断真伪。
正好这篇文章在 devv.ai 上遇到了很经典的 RAG 幻觉。
devv.ai 是基于网页抓取的 RAG 应用。我问他“什么是 ROG”,它很正确地抓取到了这个网页。但是这个网页中大篇幅都是描写 RAG 和 RCG 的内容,仅有两句话提到了 ROG。而 devv.ai 显然被误导了,它使用 RCG 的内容来描述 ROG,生成了完全错误的答复。
虽然 devv.ai 是一个很好用的平台,但是通过这个案例可以了解到,基于 RAG 是无法避免幻觉的。好在 RAG 提供了透明性,你还是要自己去查阅一下来源,自行判断真伪。
https://laisky.notion.site/Knowledge-Retrieval-Takes-Center-Stage-0583843afb0940cbafc4ce34805a761c?pvs=4
之前分享的那篇论文是对 RAG 的综述。而目前的一个研究方向则是更进了一步,提出了 RCG 的概念。
RAG 是利用 retrieval data 增强 LLM 的能力。而 RCG 则是摒弃 LLM 的内生知识,完全使用 retrieval data 来生成答复。
在 RAG 时代,人们认为 LLM 越大越好,内嵌的知识越全面,对 retrieval data 的利用也就越充分。
但是在 RCG 时代,小型 LLM 也能够取得和大模型相媲美的性能,甚至更好。小模型不再专注于大而全的信息原文,而是专注于对信息抽象认知模式的学习和推理。对于 retrieval data,RAG 的理解能力依赖于 pre-training 数据集和外部数据的重叠。而 RCG 更强调于对未知数据(unseen data)的抽象认知能力。
用人来打比喻,RAG 时代就是一个能力平平但是善用网络的懂王,而 RCG 则是试图塑造一位天资聪颖的人才。
之前分享的那篇论文是对 RAG 的综述。而目前的一个研究方向则是更进了一步,提出了 RCG 的概念。
RAG 是利用 retrieval data 增强 LLM 的能力。而 RCG 则是摒弃 LLM 的内生知识,完全使用 retrieval data 来生成答复。
在 RAG 时代,人们认为 LLM 越大越好,内嵌的知识越全面,对 retrieval data 的利用也就越充分。
但是在 RCG 时代,小型 LLM 也能够取得和大模型相媲美的性能,甚至更好。小模型不再专注于大而全的信息原文,而是专注于对信息抽象认知模式的学习和推理。对于 retrieval data,RAG 的理解能力依赖于 pre-training 数据集和外部数据的重叠。而 RCG 更强调于对未知数据(unseen data)的抽象认知能力。
用人来打比喻,RAG 时代就是一个能力平平但是善用网络的懂王,而 RCG 则是试图塑造一位天资聪颖的人才。