顺便说一下当下这台机器的作用：

1. 在家里，这台基本就是开 Moonlight 串流台式机操作，除了玩 FPS 游戏之外，多媒体效果都可以接受。不用 RDP 是因为在多媒体方面，Moonlight 效果还是略胜一筹，而且有些人遇到的会被弹窗弹出的情况，我基本没遇到。

2. 在外面，轻量工作自己用 Win11+WSL2 去做，遇到一些 Linux UI 相关的协助就重启到 Linux 桌面去做；重度工作远程打开家里台式机工作，台式机会用 frp 之类的把服务穿透出来让我本机调用。

3. 要测试 Audio ASR 相关的，串流或者远程，都可以通过 AudioRelay 这样的工具实现这台机器和台式机的打通，不会有任何问题。

@waahii 正好也在这里回复一下，原计划可能今年十月份显卡虚拟化能够内核启用，目前从朋友的消息，当下 Intel XE 显卡 Linux 虚拟化驱动已经在 6.11 内核可以用了（之前是 i1915 ），只是启动虚拟化的开关没打开，这个开关在 6.13 的 CI 测试有，所以目测明年 2 月份 6.13 上线就能直接用了，commit 的记录是 Intel 在上线的时候支持全系列显卡平台，目前只是测试了 11/12 ，而 13 和我这 Ultra 还在测试。
所以大概率还是要等明年 2 月份以后再测试了。
不过我这台 Linux 和 Win 是装在不同的 SSD 的，所以真的要用 Win ，用另外一个 SSD 的 Win 也不影响啥。

@Godjack 哈哈，可以见我上一层的发言
这台的问题其实音频修改内核参数就解决了，显卡虚拟化要等明年 2 月份 6.13 内核上线应该就能解决。
要说我唯一不满意的，是因为为了全平台我浏览器选择的是 Edge ，Edge 的显卡硬件加速还是不让人满意
总体来说没有什么问题，要说嫌弃大概就是雷电口少了，其他挺好。

@ijk 时间一下子就到了十月，感谢还在惦记。这台机器使用经过了几个阶段

阶段一：
Fedora 40 使用外接雷电 3 显卡进行 AI 的开发，比起 Ubuntu 的资料多，Fedora 的协助更多的话爱是依靠官方的资料和大神朋友的协助，不过整体来说没什么大问题。同时 asdf 这个版本控制在 AI 开发很舒服，推荐一下。

阶段二：
AI 涉及一些 ASR 和 TTS 相关，尤其是 ASR 和麦克风拾音的搭配，Win 驱动丰富的优势就多起来了，另外笔记本带着外接雷电 3 显卡主要是经常出差，最近不出差了，所以玩法变成了办公室连回家远程台式机，那样台式机的显卡做 AI 效果更好。这里我用的是台式机配合 WiFi 插座自动上电开机，有效的节约电。如今的模式就成了一台 16 寸笔记本每次远程 Win11+WSL2 Linux 的过程。由于不用桌面，WSL2 Linux 我换成了 Ubuntu2204 ，资源方便很多。
16 寸笔记本大部分开发变成远程，而正好碰到了黑猴流行，于是这台笔记本我又回到了 Win11+WSL2 ，这个时候用 Win 主要是玩玩游戏和远程了。顺便 WSL2 的 AI 验证也方便。

阶段三：
当 16 寸笔记本沦为远程工具时，我就在想为啥不是一台 16 寸 Mac 或者 13 寸 MBA 需要外接 16 寸便携屏之类的，经过一些尝试，发现 macOS 的 AI 工具的组件还是比 Linux 少很多，而且黑猴时间也过去了，于是我我又怀念 Linux 的方便了。
毕竟我本机 Win11+WSL2 ，再远程 Win11+WSL2 ，有点浪费。
正好朋友和我说，目前 Intel XE 显卡 Linux 虚拟化驱动已经在 6.11 内核可以用了（之前是 i1915 ），只是启动虚拟化的开关没打开，这个开关在 6.13 的 CI 测试有，所以目测明年 2 月份 6.13 上线就能直接用了。
朋友说看 commit 的记录是 Intel 在上线的时候支持全系列显卡平台，目前只是测试了 11/12 ，而 13 和我这 Ultra 还在测试。
所以我得计划是
这台笔记本 SSD1 还是 Win11+WSL2 ，应付一些游戏和 AI 简单测试
SSD2 继续回到 Fedora Linux ，等待明年 2 月份的显卡虚拟化正式使用。
日常会用 Fedora ，我还是超怀念 Linux 的窗口管理，Win 用多了还是不习惯，macOS 则有点不伦不类。

PS：我出门一般还是带 13 寸的 M 芯片的 Macbook Air 和这台笔记本，这台笔记本当下主要还是远程，远程，远程。。。

另外更新一下配件进度：
我海鲜市场新购了一个 JHL6540 主控的显卡坞，自带 550W 电源，价格 4XX 。这样搭配我的 3060 显卡，雷电 4 直接接到红米笔记本，即在 Linux 和 Win 扩展了 AI 能力，又实现了供电，一根线一体化还是很舒服的，而且还便携。相比 M 芯片的 Mac 就。。。

当然我那台 2019 年的 16 寸的 Macbook Pro ，是可以在特定的 Win10 版本如 1903 ，通过一些手段实现外接这个 eGPU 的。但是这台红米啥都不需要 hack 就能直接用雷电 4 扩展坞了。
还是很舒服的。

@dwSun 补充一下，和 Mac 相比的话，我现在已经不用 2019 年 16 寸的 Intel Macbook Pro 了，但是还是在用 2020 年 M1 的 MacBook Air ，这也是我这篇文章的说法，红米笔记本可以是主力，但是 Mac 还是很难不用的，对我来说主要有几个地方：
1. 微信记录：Linux 虽然有原生版本了，但是 Linux 原生版本的微信不支持聊天记录的迁移和合并，我基本上每隔一阵子会把手机的记录和电脑的记录合并同步，这样就可以保持更新（主要是因为移动版本的微信自动删文件和图片）。如果微信的桌面端的聊天记录能够互相同步的话，其实就没这个烦恼了，但是目前来说，微信只能用 Win 或者 Mac 版本。但是 Win 下的续航真的还不够理想，所以目前微信记录还是主力在 M1 的 Macbook Air 同步
2. iCloud 照片同步：作为买了 2T iCloud 空间的我来说，iCloud 云盘并没有多好用，但是 iCloud 照片太方便，这个其实是全家桶的问题，但是如果红米电脑是 Linux ，那还是照片同步是 Mac 就好，Mac 选择优化版本就行，也当成一个备份
这两个问题 Linux 桌面还是很不容易解决的

最后，红米这台笔记本我还是被迫用上了鼠标，触摸板无论是 Win 还是 Linux 真的和 Mac 使用体验差太远太远了。用的经典的罗技 G304 ，优点是可以在 Win 上用罗技的 G Hub 把 DPI 配置写入鼠标的固件，这样在 Linux 和 Mac 使用的体验就会很舒服了。

@dwSun 嗯，现在我因为要玩玩魔兽世界国服，所以切换到 Win 的机会多一些，基本上 Win 和 Linux 是按需在用。至于 Dummy Output 的内容，可以参考 97 楼，我更推荐使用内核参数“snd-intel-dspcfg.dsp_driver”取代你贴的文章的做法，虽然使用内核参数会在每次内核更新和切换的时候都需要做一次，但是如果发生问题，至少可以通过修改参数改回来，但是 CSDN 文章的做法可能侵入性更强一些。
目前我就等十月尝试一下显卡直通，其他其实能做的也有限了。

今天简单更新以下目前使用过程的一些发现：
1. 从 macOS 开始，我就比较依赖从终端打开当前目录，当前自带的 xdg-open 这个命令很好用，在 macOS 上对应的命令是 open.
2. 另外一个终端上我喜欢用的是 ` man -t $1 | open -f -a Preview ` , 这句命令是可以让 man 输出 postscript 然后让系统自带预览打开 PDF 。而在 Fedora 下就略复杂，要通过额外安装 groff 和延伸的 groff-perl 包来搭配(Ubuntu 下则是 gropdf 这个包)，另外也没有预览 app 这种特别方便查看 PDF 的工具用于输入 ppstscript ，这块看大家有没有更好的推荐，我也持续再寻找更舒服的方式。
3. 邮箱使用雷鸟，正在从 macOS 导入十几万封邮件，目前一些细节还是不能和 macOS 自带的 mail 比（当然 macOS 自带的 mail 也有很多 bug ，不过搜索，智能排序，预览，回复重复内容折叠等方面，还是比 Foxmail,Outlook 之类的舒服多了），雷鸟目前的一个问题是邮件内嵌 Tiff 不能预览

正在做的事情：
我这一代是 Intel 14 的 Meteor Lake,自带 NPU,虽然从 Intel 的官方信息来看，使用 NPU 只能使用 Win11 或者 Ubuntu 22.04 之后的版本才有驱动，不过和朋友研究发现，在 Kernel 6.8 之后其实 intel_vpu 驱动已经并入了，所以就打算直接使用 Fedora 来尝试 NPU 的可能性了。
当前的进展是驱动不需额外安装，固件已经可以启动载入，剩下就是 runtime 和应用的事情了。

https://i.imgur.com/rPhGI8o.png

就更新到这里了。

@waahii #124 好的，最近在做一些 macOS 的应用资料的迁移，就日常使用其实也没太多影响，反正 Fedora 就是持续等，等到内核更新和应用支持大概就差不多了。接下来的确就是 Intel 显卡直通了，不过估计要 10 月份了。至于触摸板，其实目前 Fedora 下触摸板的玩法暂时没太多精力去弄，因为习惯窗口平铺之后可能更多的需要的只是焦点自动切换就好了，晚点我在学习学习～

@LakuaLakua #122 好的，我记下来，慢慢研究，多谢～

@cluefly #119 主要还是 X11 应用的字体渲染，在非整数倍的缩放下的效果差距还是很大，整数倍勉强用。不过当然可能和桌面环境配置也有关系。我不用 Linux 微信是因为我重度依赖微信的聊天记录搜索（我微信聊天记录超过 100G ），而 Linux 微信没有 Win/Mac 版本的聊天记录迁移，所以。。。

@cluefly @waahii Dropbox 图床可能不方便预览，我换到 Imgur 了

https://i.imgur.com/lmYcLLV.png

@w568w 哎，我觉得重复回复人也累，哈哈, 参考我 10 楼的回复吧，就这样了。

上面说的 “但是自己觉得 UI 和协议都是我自己写的” -> "，但是作者肯定自己觉得 UI 和协议都是我自己写的"

@body007 我个人看法：

1. 代码结构和思路肯定是借鉴 LocalSend 的，多加一个 致敬声明 就没事了，但是自己觉得 UI 和协议都是我自己写的，我只是借鉴了思路和代码框架，为啥要声明，哈哈

2. 具体协议层，就 macOS 上来说，LocalSend 自己用 Pod 的一些现成轮子组成的私有协议，和作者用另外一组 Pod 的的一些现成轮子组成的自己的另外的标准协议实现，后者算不算抄袭或借鉴，我觉得很难。

3. 我个人来说，LocalSend ，除了在雷电 3 ，4 组雷雳网桥的性能极差（可能是一些变量没考虑 20Gbps 的传输带宽之外），其他层面 LocalSend 就够了。毕竟用一直用 SSDP 真的会比目前 LocalSend 这个协议耗电。

@w568w

> 例如，LocalSend 的协议实现就是纯 Dart 编写的。

是啊，都能看到 LocalSend 的协议实现是纯 Dart 编写了，其实也可以大概判断出如果不用这些协议，使用其他 SSDP 到底是自己造轮子方便，还是借鉴代码方便了吧。

> 协议层可以就在这里。请不要把 Flutter 当成 HTML 那样的前端标记语言，它没有什么「主程序」、「前端」、「后端」的概念，编写一个操作系统模拟器都不在话下，实现一个网络协议还是非常容易的。

我说的协议层指的是 cocoapods 包这些东西，核心在这里，而不是 LocalSend 代码。简单来说，我 WireShark 抓包的内容，并不在 LocalSend 主程序实现，而是在 cocoapods 里面实现的
具体而言，可能是 https://github.com/localsend/localsend/blob/main/app/macos/Podfile.lock 这里面的

```
Reachability
network_info_plus
connectivity_plus
```

等等。

如果这些东西两者调用实现都不同，而仅仅是中间层调用 API 相似，这。。。

@w568w 补充一点我自己个人的猜测，仅仅是猜测：

作者是基于 LocalSend 的代码结构还有设计思路，自己修改了 UI ，同时自己实现了他描述当中的核心功能协议替换。

另外大家逆向的看到的主要还是基于 Flutter 打包的结构，这个结构可能写的规范的人都差不多，很难证明什么。

@w568w 没有打烟雾弹，只是描述一个事实。因为 Flutter UI 实在太好替换和借鉴，而 LocalSend 的代码结构说实话因为写的太规范，所以也可以认为有规范的人都可以写的相似。

目录结构现在我只看到大家借鉴的是主程序部分，但是主程序说老实话，只有 UI ，因为协议层都不在这里。

因此这部分我仔细看了一下引用的几个核心网络层面 Framework 的实现，其实有很多和 LocalSend 引用的不同，当然因为闭源很难证明，我也没精力和兴趣去证明。

我只想表达，协议层面自己造轮子实现，如果用 LocalSend 的代码二次开发，可能会更痛苦。

@Goooooos 所以我只是说关键代码不是基于 LocalSend 修改，因为协议层实现比 UI 还是要复杂得多（当然不一定比 LocalSend 更优雅或者安全）

我相信通过替换 Framework 可以直接使用，应该是有借鉴 Flutter 层面相关代码的，但是由于关键功能的协议层自己有实现，因此作者认为自己没有抄袭可能也有他自己的道理。