性能是一方面。还要考虑生态成熟度和运维难度。

性能再好一出问题两手一滩搞不定，温度有付费的支持服务，属于神仙难救

没看懂这个需求。话说静态页面不就是这样的吗？每个页面就是个 HTML+js 的独立文件。

> 不是很容易找到靠谱的 operator

那就不如写个 Operator 来解决你部署时候碰到的问题吧

@suixn 恩这个是在 kubeflow 的多个组件上进行了定制和二次开发吗？

各位老铁收藏很热情，回答的热情也走起来把

ES 后面是 elastic ，kafka 后面是 confluent ，spring 后面是 pivotal ，hadoop 有点昨日黄花，但是曾经也是有 cloudera ，hortonwork, mapr 这些明星创业企业在做。

这几个企业都符合 Lz 的需求，就是可惜都在国外。

如果想做 Infrastructure ，基本只能去大厂，或者上述这些来源商业化公司了。

@0x4F5DA2 Jupyter 带 terminal 的环境，可以要一个带 GPU 的 lab 容器，然后 gitclone 开源代码到容器里调试运行，是否可以满足需要？

vscode 也可以作为开发环境提供。容器里面运行一个 coder 的进程，然后暴露给用户。

美西的线路质量不知道怎么样？

AWS us-west-2

借问一下，gcr.io ，quay.io 这类容器 image 有什么镜像站吗？

下载个 virtualbox 镜像吧。或者用 vagrant 直接拉

国外的话可以用 aws batch 。按使用量收费的。很多做电影搞动画的渲染工作，都是扔到上面搞得。

很多时候感觉是 toolchain 没有配好。写个复杂的 cmake 或者 makefile 得花半天。程序迟迟跑不起来，没有收到正反馈，感觉沮丧。

Go 这种保姆式 toolchain ，啥都不用安装就能编译起来了。

这个是个 bin packing problem ，https://en.wikipedia.org/wiki/Bin_packing_problem

Np hard ，没有线性时间精确解。但是有不少 heuristic, 例如 first fit https://en.wikipedia.org/wiki/First-fit_bin_packing#:~:text=First%2Dfit%20(FF)%20is,is%20at%20most%20the%20capacity.

具体就是对每一个商品，遍历发票列表，找到有剩余金额可以容纳该商品的发票。如果找不到就新开一张发票。如此知道所有商品都被分配给某张发票。

复杂度 Nk ，其中，N 为商品数量，k 为发票数量级。

这个算法可以被理论证明不会使用超过 1.7 * 最少的发票数量。但实际使用中效果很好，一般远好于这个上界。

工作职位和企业还是比较少，找工作有点难。

房子和收入比起来还是有点贵啊。
感觉和其他一些移民国家相比没有啥性价比的优势啊。

比如去美国大农村做个程序员，一年赚个 10 万，关键是房子才 40 50 万。

但是自然风光和生活节奏肯定是棒棒的。移民难度肯定也是有优势的。

Numpy 底层也都是调用各种矩阵运算库来加速的，例如 blas lapack 。这些矩阵运算库为了性能，需要专门针对不同的 CPU 架构的指令集进行实现。所以 arm 架构需要专门编译这些底层库。

这些库还有商用实现，例如 Intel mkl ，由于 intel 是专门卖 x86 处理器的，所以可想而知不会主动去支持 arm 。

但一般用户使用可能不会接触这些细节，一些包管理软件例如 conda 已经可以很好的管理不同架构下的包，这些编译工作也已经有人做好了。

你需要 cache 。如果不想额外引入服务，例如 redis ，就用数据库做 cache 好了。服务量不大的话没问题的

这是找做系统底层的程序员，和 go 没关系。lz 不是你的问题，他们问的问题也没太大问题，面试官态度不太耐心是真的。面试就是来发现大家是不是适合一起工作的，其实是好事

这个公司没有 artifacts repository 的吗？
多版本号共存应该也不影响使用才对，各个项目依赖不同版本是可以的。