引进白额高脚蛛

个人还是非常希望这类项目能成功的，但可能需要和一些既有算法背景又有底层背景的人多交流，才能知道真正的痛点在什么地方。这一类用户的痛点显然能覆盖只有算法背景的人的痛点，并且是更为本质的。

我认为最头疼的是当前整个生态中各种上层软件和底层软件乃至硬件强耦合，从而有“只有特定版本组合的库能跑”、“我要重新编译这个库”、“我编译时遇到各种坑”等一系列问题。如果有人想在中间加一层，使得上层用户无需关注底层细节，这个中间层必须尽可能梳理好各种各样的耦合关系。否则用户一定会在某个时候想越过中间层去调整底层的细节，此时中间层反而是个累赘。

比如像我比较熟悉和习惯构建容器，在我看来这就是借 Python 语法实现的一个 DSL ，并没有解决我太多的痛点，反而在遇到问题时这个 DSL 会显得特别蹩脚。当然我可能不是你们的目标用户~

还有一类问题是 在 build 镜像阶段装包需要采用与 本地调试 /容器内调试 时不同的指令。

比如如果在 build 镜像阶段想要编译一个 torch extension ，那你需要类似这样指定特殊的环境变量 TORCH_CUDA_ARCH_LIST="3.5 5.2 6.0 6.1 7.0+PTX 8.0" TORCH_NVCC_FLAGS="-Xfatbin -compress-all"。否则会报找不到驱动的错误，因为 build 镜像阶段不会挂载 GPU 驱动。

我见过很多人在这个问题上卡了很长的时间，因为这个问题在 本地调试 /容器内调试 时均不会出现，只有在 build 镜像时才出现，同时理解这个问题需要足够的底层知识储备。

类似这样的问题还存在不少。我觉得如果有可能的话，可以把这类 heuristics 都收集起来集成在这个项目内部，这会在特定时候帮用户大忙。

@gaocegege #11 比如 nvidia/cuda:11.7.1-devel-ubuntu20.04 带有 devel 的

分享一个竞品 https://github.com/replicate/cog ，我觉得它提到了一个很常见的痛点：

> No more CUDA hell. Cog knows which CUDA/cuDNN/PyTorch/Tensorflow/Python combos are compatible and will set it all up correctly for you.

即一些包需要特定版本组合的环境下才能正常工作，并且这些知识通常鲜为人知，用一般的工具也难以梳理出其中的依赖。能把这些自动处理好无疑会有更大的帮助。

如果要编译 CUDA 算子，如何指定 devel 版本的镜像以使用 nvcc?

opencv 不应该依赖 libg1 ，如果要在无头环境使用，应该装 opencv-python-headless 而不是 opencv-python ，这是官方推荐做法

多写几个字，形成一句话

拉长没有，倒是有几次被压扁😂

@a33291 咦，这是我个人搭的 freshrss ，然后我把聚合后的源公开出来。链接就是个 xml ，没有别的

怀疑是 vpn 配置有问题，我自带浏览器都可以上

用 prolog ？

改下 includePath 就好了

偶尔一张会

这个为啥这么高。。。分辨率太低了？