为啥还用 tensorflow, 现在学不是该用 pytorch 么

现在 Go 的错误处理方便了么?
还是得写满屏幕的 if err != nil 么? 主要就是这个难受

看着不错, 问题:
1. cursor 能兼容所有 VSCode 的查件么?
2. cursor 那个每月 $20 都包括了啥? 无限用它自家的 LLM 么? 我看到里面还可以选 ChatGPT 或者 Claude, 自己再付费买它们的 API 么?

@hh54188 作为个人开发者, 就不应该去研究使用 K8S, NextJS

@iovekkk 高配 Mac 多半是割韭菜, M 系 Mac mini 16G 内存就够用了.

这个 YouTuber 还有自己重做 Doom 的视频，不错不错

要网络好, 远程的机器也要好才行

说的很多遍了, Flutter Dart 这一套是邪道, 迟早完蛋. 别浪费时间了.

@keyboardCat 如果你是"各种 npm 安装或者构建的问题卡住", 这个不是前端的问题，是不擅长折腾配置环境的问题. 解决方法只有 2 个.

1. 多折腾配置环境，多练习 troubleshooting. 至少总结出几套靠谱的配置方法, 比如学会自己从 0 构建 node 项目，并使用 lock, 让自己的项目处于可靠的各个 checkpoints 上, 一旦折腾坏了, 马上退回上个能用的 checkpoint.

2. 实在不会自己配置环境. 那就不要自己做小项目了, 只能刷题去大厂让别人给你配置, 或者干脆不干程序员啦.

HTML files + JQuery -> SPA -> Angular/React/Vue
-> 哎呀没有 SSR 来做好 delivery HTML files (e.g. for SEO)
-> 新造"前端框架"来解决传统 file delivery 问题
-> Next.js (真的能解决吗? 不该自己控制 HTML files 生成和发布到 CDN 吗...?)

作为后端, 你可以遇见, 这类"新的前端知识"会一直增长下去的...
如果不是"面向前端主流编程", 比如要找前端工作的,
建议保持在类 HTML files + JQuery 的设计上, 相对稳定. 可以用 alpinejs.dev + HTML files

从 k8s 开始宣传画的饼, k8s 自己的复杂度, k8s 的运行效率.
作为 dev, 对于其他 dev, 我想说: k8s 真的不行, 研究 k8s 没有性价比, 浪费时间. 省省精力研究点有用的.
多的不说了, 最后说一句: 不浪费智力, 去研究没有性价比的技术, 是 dev 需要的智慧.

@sampeng 一层层的 pull docker image 的 binary data 应该是最慢的部分, 回到我 19 楼说的基本问题上，这个在 k8s+docker 生态里是难以解决的. 另外, 你说的安全部分也可以搞得特别慢, 如果公司在这方面龟毛的话, 龟毛的安全要+k8s 那就是更加的慢.

@sampeng
刚刚问了负责的 DevOps, 说优化到 6 分钟了, 他们还在搞. 我作为 dev 不想搞 ops 事情, 只是用起来偶尔非常闹心...
按照你提前 3~5 分钟的说法, 所以最后能优化到 3 分钟上下. 但是我还是觉得好慢. 因为我们始终是在讨论分钟级别的延迟, 实际上, 广义上看, 如果底层实现够优化的话, 应该是秒级别的事情. 不知道底层在干啥, 需要达到分钟级别... @_@

@sampeng 我说的是 EC2 VM 起来之后, register 进入 EKS cluster 的时间. 不是 k8s replica scale 的时间(这个很快). 你决赛的瞬时流量不应该依赖这个, 因为启动 VM(甚至是启动物理机器)的是瓶颈. 你瞬时的 busty 流量要抗住的话，得实现至少把底下 VM(or 动物理机器)预先启动起来. 当然, VM register 进入一个 computing cluster 的时间确实应该很快. 不该是 5 分钟，或者 10 分钟这么慢. 所以我说 EKS k8s 慢.

@huangzongzhuan
Google 看着其它云厂商赚钱太眼红了, 就按照自家的 Borg, 做了个劣质简化的版本: Kubernetes
然后投入大量资源宣发 k8s. Amazon 一看, 开源的啊, 快加入我家 AWS 产品线: 结果 ECS, EKS 就出来了.
然后 AWS 用 k8s 继续挣钱，还省去了宣发费用. Google: ... ...

@kennylam777 你到底看懂我的回帖没...
什么叫我只考虑开发的日常, 我说的是 k8s EKS 的 scale 竟这么慢, 竟然影响到了实际业务 -- 竟然需要额外优化!? 我在硅谷这边工作, 不只一个 DevOps 组跟我说过这个问题, 也许是我认识的 DevOps 都很烂. 就你司 DevOps 厉害...

然后, 我说的根本问题 1 2, 你是不是一个没看懂.
"甚麼自己寫 Cluster manager 的出了 AWS 也是一團廢物" -- 做个最简单的 cluster manager 跟 AWS 实现屁关系没有, 只要能通过 VM image 构建 VM 就行. 用不用 AWS/Azure 都没关系. 只能用现成的"主流"工具的人, 是不是完全理解不了...
最简单 stateless computing cluster managing 是 k8s 最常用使用场景, 这个都做不好(竟然需要额外优化!?), 更复杂场景还需要看吗? 地基就是歪的. 你可以在上面加一堆更复杂更全面的功能，但是不能掩盖楼是歪的. 还"处理 BGP", 简单场景都这么费劲... k8s networking 部分几年前我看过一下, shit show 的复杂程度. 费老大劲糊上一堆 legacy 的 protocols... 我怀疑他们设计这块的人没有认真理解最近这些年 SDN(Software Defined Network)的主要成果. 至于你 EBS, NFS 我是看不懂你想说啥. 堆 GPU 搞 LLM 的话, 有些团队/组当然不是用 k8s 的!

对于那种只能用 k8s 的团队/组，我是会用 k8s 的跟他们干活的，但是破玩意儿真的不用浪费时间研究.
对于不用 k8s 的团队/组, 我也很乐意使用/改进他们自己的 infra.
在工作中, 上面两种情况都常见. 不要以为全世界都只会用 k8s @_@

注册 5 分钟也够慢的了... 启动个 EC2 VM 都只需要 1~2 分钟. 这个只能是 k8s 的设计问题, 没得救了.
为啥注册个 VM 还需要额外再加个"ECI 虚拟节点"来加速...

docker+k8s 我上班天天用，自己做项目是绝对不会用的.
我只简单说下这套东西为啥是复杂的工业垃圾:

1. 各个新老语言的 package/dependency/build 工具进步了, 可以在 dependency hash 层面实现 reproducible build. 根
本不需要用 docker 做那种非常重非常笨非常慢的 binary 级别的 reproducible build.

2. docker 本来应该被淘汰的, k8s 基于 docker 所以会继承 docker 的低效, 但是没想到会这么低效. 如果只是实现 stateless computing cluster 这么简单的东西, 你自己写个 cluster manager 就实现了. 那么对于一个 running cluster, new VM registering 就应该是秒级的速度 -- 我 10 年前就写过这样的东西, 在 AWS 上管理几十个 EC2 VMs. 不要轻易说 "那就相当于你实现了一个 k8s", k8s 的情况属于: 拥有大量宣发资源的人, 忽悠出的"主流"技术栈, 最终点错了科技树的情况.

docker + k8s 这帮人, 设计这么一大坨复杂玩意, 面相 yaml 编程, 折腾半天, 只能做个 stateless computing cluster. scale 的速度居然还奇慢... 上周公司开会，讨论说往 AWS EKS cluster 加个 EC2 node 要 10 分钟以上, 我都听懵逼了, 我说 EC2 instance 启动瓶颈不是 2 分钟上下吗? DevOps 说是的, 但是 EC2 node 起来后, 往 EKS cluster 里注册非常慢. 我上网搜了下, 确实要加个 EC2 node 要 10 分钟上下... 好烂, 我真的惊了...
所以工作需要的话, 会用常用命令行就行. "研究" 这坨"主流"并"流行"的垃圾, 属于浪费时间.

你们抱怨归抱怨, 但是用微服务的组, 本地项目跑不起来的情况很多...