还可以用虚拟机

infuse

不下赛道的话，上 3p 。
要相亲的话，还是保时捷吧

能躺就躺吧....

@ilovey482i 感觉最新的 i3 都够了...

@imHarveyy 我不咋听音乐，我主要是电影，然后 Infuse + ATV 看

音乐的话可以试试这个 https://www.stratospherix.com/products/musicstreamer/

@chocolate518 #3 如果不想自己折腾，那几直接上群辉。

@SenLief tailscale 解决烦恼

试试阿里云盘 + webdav?

@unt #25 不客气，毕竟这是 GPT4 给的答案..

MQTT 的劣势：

协议开销：MQTT 是基于 TCP 的协议，它在 TCP 基础上增加了一些特性，例如发布 /订阅模式、消息质量等。由于这些额外的特性，MQTT 协议可能会比纯 TCP 透传协议增加一些额外的开销。
依赖中间代理：MQTT 需要一个中间代理（ MQTT Broker ），它负责转发客户端之间的消息。这增加了一个潜在的故障点，如果代理出现问题，那么整个系统可能会受到影响。
TCP 透传的优势：

简单：TCP 透传协议相对简单，易于理解和实现。它不需要额外的代理服务器，客户端可以直接与服务器进行通信。
更低的延迟：TCP 透传协议由于缺少额外的特性和中间代理，可能具有更低的延迟。这在某些对实时性要求较高的场景中可能是一个优势。
更好的控制：使用 TCP 透传协议时，可以直接处理原始的字节流，这意味着对数据传输的控制更加灵活，可能更容易满足特定的应用需求。
关于您的第二个问题，采用 MQTT 协议时，通常会将数据解析放在设备端。MQTT 协议支持发布 /订阅模式，客户端（设备）会向代理发布主题（ Topic ）和消息（ Payload ），这些消息通常是结构化的数据（如 JSON ）。

这意味着，使用 MQTT 时，设备端会将数据解析和封装成结构化数据，然后通过 MQTT 发送给代理。代理收到数据后，会将其转发给订阅了相应主题的其他客户端。在这个过程中，数据已经是结构化的，因此服务端无需再进行额外的数据解析层。

但是，在某些情况下，设备端可能仍然会发送二进制数据（如字节码）。在这种情况下，服务端需要对这些数据进行解析。不过，这并不是 MQTT 协议的限制，而是设备端实现的选择。

听你老婆的

@kaiger 这个时候 可以 gpt

是不是可以把每天的交流，问的一些问题丢给类似 chatGPT 这样的 AI 通过 chatGPT 自动回答过滤一部分

@brader VMware 应该是有个人 License 的。可以直接免费申请 https://customerconnect.vmware.com/en/evalcenter?p=fusion-player-personal-13

CDN 用的是哪家？

想起来的时候