我在用这个 https://item.m.jd.com/product/6737058.html 用着挺稳定的.3.0 的口传输速度正常.设备上去 300-400MB 没问题.hdmi 不支持 4K@60Hz.但是除此之外使用很稳定.不过同时插上 hdmi+pd+usb*2 的话发热会比较明显一些.
4K@60Hz 的话刚好捡漏了一个小米 typec 转 minidp+minidp 转 dp 线材.加起来 88 包邮哈哈

这样的话,编译环境和编译操作可以达成解耦,分开维护非常方便

或者如果准备环境以及编译同时是两个不同的步骤,完全可以首先维护一份准备环境的基底镜像,比如 sample/debian-with-gcc 这样.然后在开始编译的镜像中直接使用 FROM sample/debian-with-gcc 然后再进一步的书写需要的编译步骤.最终 docker build 完成编译.

就我个人用 docker 差不多两年的经验来理解的话,因为我自己也有在维护一份私人的 openwrt 编译环境,所以我觉得相对来说比较方便的实践是这样的.
1.使用多阶段构建,在第一阶段中使用 dockerfile 中的 RUN 指令来构建出完整的所需二进制文件(whatever)
2.在第二阶段构建中提取出所需的二进制文件到新容器(多阶段构建的本质是不同的容器)中
3.在第二阶段的构建最后使用 COMMAND/ENTRYPOINT 等运行一个文件服务器进行分发
4.docker run 这个最终容器,然后直接在别的渠道直接提取即可.当然如果不需要 remote wget/curl 的情况下.我个人认为第二阶段构建完全不需要指定 COMMAND/ENTRYPOINT.直接使用 cp 来复制也可以.
我个人在使用的自动化编译流程基本上就是这样构成的,我理解是应该放在 COMMAND/ENTRYPOINT 的,也就是楼主你说的 run 的这个部分的应该有以下的特性:
1.幂等的,无论是重建容器,还是失败后自动重启容器,都应该完成相同的工作,输出相同或者类似的结果
2.轻量的,放在 run 的这个步骤的部分不应该阻塞启动时间,因为过长的启动时间会直接导致 docker 判断他启动失败.也不便于管理操作
3.提供服务的,这个 run 基本上是面对使用者的最前面的内容,应该足够一目了然可以让使用者明白这个 run 直接的提供我需要的服务

@635614874 你看视频也能用得到.硬件加速还是很有必要的.省电流畅这些优点很明显.你也不想看个视频 CPU 风扇起飞还一卡一卡的吧.我个人推荐就是够预算用 Z 系列不要用 B 系列主板.Z 系列厂商的 BIOS 完善程度更高.可调节选项也更多.诸如 CFG Lock 等 Hackintosh 必备解锁基本都会在.然后可以考虑选择没有 iGPU 的 KF 系列 CPU 搭配 RX 580 的矿卡来用就行.咸鱼价格稳定的 8G 版 2304 在 700-800.4G 版 2304 可以用 ITX 作为关键词来找.我就买了一张 400 出头的 2304 4G 版

@635614874
@avrillavigne
在 10.14.4 及其以下的 macOS Release Version 中,只有使用 iGPU 或者单 VEGA 系列的显卡并且本身支持硬件解码 /编码,才可以实现硬件加速.
在 10.14.5 及其以上的版本中可以直接使用单 eGPU 而无需 iGPU 直接进行硬件加速.并且扩展范围到大量 A 卡都支持(甚至包括 R9 Nano / Fury X 等等)