https://copilot.microsoft.com/ 微软把 Bing Chat 和 Bing dall-e-3 都集成到这个页面了。虽然名义上是“免费”,但实际上在这里画图会同步消耗 dall-e-3 页面上的 boost 配额。而且目前 bug 还挺多的,vision 功能显然是挂掉的,chat 看上去也仅仅集成了 web-search 的 function。
https://laisky.notion.site/Go-Containers-and-the-Linux-Scheduler-f4be286e0550474fbc04814bca4f43ec?pvs=4 #TIL #Golang
老生常谈了,go 不识别 cgroup 的 cpu limit,当 cgroup 给的 cpu 数目小于实际 CPU 数时,会导致 go 创建过多 threads 带来更多的切换开销。一般都会用 uber 的库 https://github.com/uber-go/automaxprocs ,加一行就完事儿:
老生常谈了,go 不识别 cgroup 的 cpu limit,当 cgroup 给的 cpu 数目小于实际 CPU 数时,会导致 go 创建过多 threads 带来更多的切换开销。一般都会用 uber 的库 https://github.com/uber-go/automaxprocs ,加一行就完事儿:
import _ "go.uber.org/automaxprocs"
各位如果最近抢了国内的廉价 VPS 不知道拿来干嘛,可以考虑跑一个 tailscale derper 做境内中转。
参考资料:
- https://blog.laisky.com/p/tailscale/ 容器安装 derper 一节
具体步骤:
1. 首先你已经有了 tailscale 账号
2. 你有自己的域名,然后拿到 dns server(如 cloudflare)的 access token
3. 服务器上装好 docker,域名指向这个服务器,用子域名也 ok
4. 在服务器上运行 swag + derper 的 docker compose
5. 编辑 swag 的 dns-conf,填入你的 dns access token,重启 swag
6. 等待 swag 成功申请到证书,重启一下 derper,检查一下 derper 成功加载了 TLS(derper 的日志里有这么一行
7. 去 tailscale ACL 把你的 derper 地址和端口配置好
注意:derper 可以挂在子域名和自定义端口,这样不会和你的既有服务冲突。
注意:如果你的域名没有备案,而且部署的服务器是境内的,那么不要用 443 端口!部署好后不要手贱用浏览器去访问!
实测腾讯云是不会阻断非 443 端口的未备案 HTTPS 流量的,当 derper 完全可以!
docker-compose 和 acl 配置可以参考附件
参考资料:
- https://blog.laisky.com/p/tailscale/ 容器安装 derper 一节
具体步骤:
1. 首先你已经有了 tailscale 账号
2. 你有自己的域名,然后拿到 dns server(如 cloudflare)的 access token
3. 服务器上装好 docker,域名指向这个服务器,用子域名也 ok
4. 在服务器上运行 swag + derper 的 docker compose
5. 编辑 swag 的 dns-conf,填入你的 dns access token,重启 swag
6. 等待 swag 成功申请到证书,重启一下 derper,检查一下 derper 成功加载了 TLS(derper 的日志里有这么一行
derper: serving on :YOUR_PORT with TLS
)7. 去 tailscale ACL 把你的 derper 地址和端口配置好
注意:derper 可以挂在子域名和自定义端口,这样不会和你的既有服务冲突。
注意:如果你的域名没有备案,而且部署的服务器是境内的,那么不要用 443 端口!部署好后不要手贱用浏览器去访问!
实测腾讯云是不会阻断非 443 端口的未备案 HTTPS 流量的,当 derper 完全可以!
docker-compose 和 acl 配置可以参考附件
我的 macbook 是通过一根 usb-c 连接到显示器供电的(线材是青州小熊那买的廉价 4K 线),以前每次拔掉再插上,macbook 都需要很长时间才能正确识别到显示器,表现为反复闪屏。后来发现是 usb-c 线离对面同事的 usb-c 线太近了,我用笔筒把两根线隔开后就解决了。有遇到类似问题的可以检查下自己的排线…
感觉 DDIA 这书对一致性的理解是有点弱的。read-after-write 是一致性中的 realtime 特性,而且也没区别讨论当前节点和多节点情形。在多节点情形的可选解决方案中,居然完全没提到最经典多读多写 R+W>N 方案来实现一致性。
—-
fix:作者在后面的无主 quorum 里提到了。其实在有主里这也是常见做法。
—-
fix:作者在后面的无主 quorum 里提到了。其实在有主里这也是常见做法。
在GitHub的一个事故中,某个数据并非完全同步的MySQL从节点被提升为主副本,数据库使用了自增计数器将主键分配给新创建的行,但是因为新的主节点计数器落后于原主节点(即二者并非完全同步),它重新使用了已被原主节点分配出去的某些主键,而恰好这些主键已被外部Redis所引用,结果出现MySQL和Redis之间的不一致,最后导致了某些私有数据被错误地泄露给了其他用户。
—-
《DDIA》第五章的例子,使用分布式 ID 可避免此类问题。至于分布式 ID 的局部性问题,可参考 UUID7 的思路,以时间戳为前缀。
—-
《DDIA》第五章的例子,使用分布式 ID 可避免此类问题。至于分布式 ID 的局部性问题,可参考 UUID7 的思路,以时间戳为前缀。
sudo docker system prune -a
/var/lib/docker 莫名占用太多空间的话,可以考虑试试这个命令,没准有惊喜。
看来 docker rmi 也有很多东西删不干净。
hello,world