九维我操你爹
年年都在想要不要去韩国转转,年年都被劝退。去年是两起空难,今年是数不清的车祸
我也没有特别去收集这方面的新闻来自己吓自己,但是这个月才刚开头就看到了三起车祸的新闻,而且每场车祸都很严重
给我一种连台湾的交通都比韩国好得多的感觉……至少台湾对我来说还是想去但去不了的地方,不是韩国这种想赌但赌不起的地方(
我也没有特别去收集这方面的新闻来自己吓自己,但是这个月才刚开头就看到了三起车祸的新闻,而且每场车祸都很严重
给我一种连台湾的交通都比韩国好得多的感觉……至少台湾对我来说还是想去但去不了的地方,不是韩国这种想赌但赌不起的地方(
https://news.ycombinator.com/item?id=45903598
Users Stuck in YubiKey Re-Enrollment Loop on X (Twitter)
招笑公司又在生产环境上测试变更了(害我把梯子和浏览器的问题都排除了一遍,浪费时间
Users Stuck in YubiKey Re-Enrollment Loop on X (Twitter)
招笑公司又在生产环境上测试变更了(害我把梯子和浏览器的问题都排除了一遍,浪费时间
本来一切都已经步入正轨,谁想到今天无聊查了下收费规则,发现 macOS runners 的收费是 Linux runners 的十倍。这下睡不着了
哎,这个不难,不就是交叉编译一下嘛,看我两三下改完——然后就从十点搞到了现在🤡
比起这种望山跑死马的折磨,我更宁愿面对根本无解的问题,这样至少我可以爽快地放弃
但是 macOS 上开发的体验一直都是:行进的方向非常明确,但就是寸步难行
复杂的技术问题不说,举个简单的例子:我把已经调通的流水线复制一份出来给 macOS runner 用,提前查好了上面软件栈,把缺少的包提前装好,还注意到镜像里装的 bash 是 3.x 的版本,特意去检查了一下我写的脚本是否兼容这么老的版本(bash 7 年前就发了 5.0 版本,3.x 版本粗略搜了下是 14 年前的古董😅)
按理说我这样已经算是有很强的意识了,但是丢上去跑了半个多小时以后我发现流水线挂了,一看是 BSD install 不兼容我给 POSIX install 传的参数
哦,忘了还有这茬——几乎每次迁移什么东西到 macOS 上我都会因为这种一时间没想到的坑鬼打墙。我实在不是什么超级大脑,没法在念头一转之间把这辈子踩过的所有坑都想一遍
当然了这种问题都是情有可原的嘛,谁让 Unix 的「霸王条款」让苹果没法站在开源项目的肩头吸血呢。我不爽的是专有系统又不止你一个,在 Windows 上交叉编译我花的时间踩的坑都要多得多,但至少从来没浪费过时间在什么 BSD/Unix 之争呀 SDK 不许再分发所以干正事之前需要先花数倍的时间在本地把编译环境搞起来之类的问题😅
你不愿意开放你那个狗屎代码没问题,至少为了替你完善生态的开发者着想,替他们行点方便💩
uutils 坑完 ubuntu 换 sudo-rs 了😂
https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10
https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10
https://t.me/xixihealth/17666
https://t.me/c/1459082815/946
作为一个有段时间没活跃的 nerdctl maintainer 出来说两句
nerdctl 实际上是作为 containerd 一个 CTL 来作为初始化的开发。定位改为 Docker 的替代实际上是很后面的事情了
而要做兼容的事情实际上要考虑的就很多了,我自己做过很多很 dirty 的活包括不仅限于
1. 兼容 Docker 随机 port 的行为
2. 清理环境
3. 处理 DNS 相关的问题
4. 修 registry 的行为
而 nerdctl 很多东西实际上受限于无法有 Docker 一样的 daemon ,搞个 bridge ,再搞个 DNS 会导致很多东西很难做
比如我之前想做的参考 podman 一样做一个 DNS CNI(
同时 nerdctl 很多机制需要依赖 containerd 的 plugin 来做回调,比如 logger driver 就是如此实现的,所以会有人吐槽为什么我记录个日志还得在内存里 load 一个 nerdctl 233333
而局限于 CNI 做事是主观+客观因素双重因素导致的。nerdctl 试图在 ctd 以及 OS 这一层做的尽可能的兼容(PS nerdctl 是支持 freebsd 的东西的(XDD),而且要考虑 rootless 以及nerdctl 被各种工具开箱集成这一事实(比如 mac 上的虚拟机,第三方集成等),最后 CNI 可能是带着镣铐下的最优解
所以 nerdctl 并不是 docker 的完全替代品我是完全赞成的。但是这个局面只能说是多种因素共同作用
等我有时间我再想想网络这块能怎么样做的更好.jpg
https://t.me/c/1459082815/946
作为一个有段时间没活跃的 nerdctl maintainer 出来说两句
nerdctl 实际上是作为 containerd 一个 CTL 来作为初始化的开发。定位改为 Docker 的替代实际上是很后面的事情了
而要做兼容的事情实际上要考虑的就很多了,我自己做过很多很 dirty 的活包括不仅限于
1. 兼容 Docker 随机 port 的行为
2. 清理环境
3. 处理 DNS 相关的问题
4. 修 registry 的行为
而 nerdctl 很多东西实际上受限于无法有 Docker 一样的 daemon ,搞个 bridge ,再搞个 DNS 会导致很多东西很难做
比如我之前想做的参考 podman 一样做一个 DNS CNI(
同时 nerdctl 很多机制需要依赖 containerd 的 plugin 来做回调,比如 logger driver 就是如此实现的,所以会有人吐槽为什么我记录个日志还得在内存里 load 一个 nerdctl 233333
而局限于 CNI 做事是主观+客观因素双重因素导致的。nerdctl 试图在 ctd 以及 OS 这一层做的尽可能的兼容(PS nerdctl 是支持 freebsd 的东西的(XDD),而且要考虑 rootless 以及nerdctl 被各种工具开箱集成这一事实(比如 mac 上的虚拟机,第三方集成等),最后 CNI 可能是带着镣铐下的最优解
所以 nerdctl 并不是 docker 的完全替代品我是完全赞成的。但是这个局面只能说是多种因素共同作用
等我有时间我再想想网络这块能怎么样做的更好.jpg
