@seers #28

在 Go 的生态里 Cgo 的意义非常重要。做个不那么恰当的类比，游戏行业 Unity/C#/Lua 生态很大程度上就是因为 Lua 和 C 互通能力。

还是回到我正文里提到的 OpenCV 的例子，在 CV 领域几乎没有完全的替代。不得不用的情况下，除非用 C++ 开发，其他语言想要使用 OpenCV 都要有相应的 bindings 。

开发这种 bindings 本身就是很复杂的事情，这里 Cgo 的优势就显现出来了。简单的项目不用写 bindings 就可以直接用，复杂的项目通过 Cgo 可以高度自动化 bindings 的生成过程。

某种程度上可以认为，C 生态完全可以为 Go 所用。正文里提到过，Go 欠缺的恰恰就是这一类的轮子。

@jackmod #25

实时性要求高的场景，无 GC 永远都比有 GC 优秀。对于 GC 来说，最难处理的情形要么是碎片化分配，要么是海量引用。我的贴子里提到的技巧主要是解决前者，后者是很难在代码层面上有所改善的，也是 Go 原理上做不到的。

还是那句话，技术栈该换就换。

~~虽然 discord 技术博客写得很好，但是软件体验仍旧是一坨……~~

@GeekGao #19

确实是这个意思，Go 的性价比很高。另外 cNk 这个说法我感觉好多年没见过了，N=1 的时候算是个硬件问题，N=10 的时候算是技术问题，N=100 大概更接近于工程问题了。

我在正文没有提到 Go 带来的另一个好处，主要原因是这个体验比较主观。我确实认为 Go 的项目很有利于长期维护。

最明显的一点是，即使我现在回看两年前的项目，不管文档、注释写得如何，几乎很快都能回顾起来。看 GitHub 的开源项目也有同感，几乎都能非常快地定位到关键代码。

核心原因应该是得益于 Go 的两个优秀设计，一个是 `share by communicating` 的 concurrency 模型，另一个是 `accepting interfaces, return structs` 的解耦机制。

在 Go 之前，想要轻松写出正确的多线程代码是非常困难的事情，想轻松写出扩展性强的代码也需要有深厚的功底。

@mainjzb #16

Windows API 难用某种程度上说是微软故意的。我没做过特别专业的 Windows 开发，这是我个人的推测。

@root71370 #12

对于去掉符号表、字符串混淆之后的 go 二进制，基本只能硬怼汇编，参考对应版本 runtime 的实现来逆向。不是专门做这个的，可能连 main 入口都找不到。基本上黑产都喜欢拿 go 过免杀。

常规没有防逆向措施的 go 二进制就和 c 逆向差不多。

@sadfQED2 #11

文章里逆向那段主要是想表达一个意思：防破解本质上是个投入产出比的事情。Go 加上十分钟就能学会的小技巧，只需要几行代码和一点点自动化工具，足以为价值几万元的业务提供防御。

我给这个十分钟小技巧，其实包含了动态、静态、控制流和混淆多个层面的防护手段。强度差不多等同于各类动态语言的 vmp 水平。

对于绝大多数开发者来说，如果不是有丰富的对抗经验，是很难写出来真正有效的防破解逻辑的。从专业逆向者的角度上说，过高的门槛本就拦住了绝大部分人，甚至轮不到考虑投入产出比的事情。

如果这个请求不是特定的，指定 upstream 代理。如果是特定的，再写 python 脚本过滤一下。

我觉得这个事情的思路有点跑偏了，Linux 内核网络栈的抽象还是比较难的。

首先“端口”是个协议层面的概念，假如 tcp 只有二元组（源 IP ，目标 IP ）局限就太大了。

所以内核网络栈不会对“端口”做抽象的，因为没有必要。有必要的是对四元组（源 IP ，源端口，目标 IP ，目标端口）做抽象，这个完整的四元组可以唯一确定一个 tcp 连接。这个抽象在 Linux 里就是 socket 。

因此内核里也就不会有端口号的映射关系，如果你去看 netstat/ss 的代码，我猜测都是曲线救国。

由于网络栈是内核实现，为了方便用户态的程序使用，就通过 socketfs 抽象成一般 fd ，这样应用程序只需要确定 socket fd 就能直接在连接层面上完成网络功能了。

前面铺垫这么多，就是为了引出结论，你这个问题的本质是“如何确定 socket fd 和 pid 的映射关系”。

问题在于 fd 这个东西是可以复制或者转移的，于是最终还要回到 /proc/*/fd/* 去遍历才能确认。


PS

“限制进程可绑定端口”的标准操作是 ACL 机制，selinux 比较方便。自己造这个轮子非常不理智。

@nullcache #3

“webview 依赖的问题”说起来比较复杂，我觉得 webview 是个很好的技术，“问题”只是在于合不合适。

笼统地说，浏览器套壳方案的缺点在于性能和打包。性能就是渲染延迟，瓶颈在于 JS 引擎，很难优化到原生水平，所以几乎所有的 webview 应用用户体感迟滞都比较明显。具体到 wails 它在 Windows 上的渲染后端是 WebView2 ，轻微改善了性能和打包问题，但非常有限。

具体到需求，webview 方案会有一些不适合的场景。

一个是它不适合开发 Immediate 模式的 GUI 应用，比如需要实时按帧渲染的游戏。二是它不适合开发重度依赖系统 API 的平台应用（理论上所有的原生 API 都能调用，但是写那个 COM 接口实在是太恶心了）。

反过来，如果这个需求不在乎打包体积，不关注用户体验，也不属于前面说的场景，而你的技术栈恰好又是 Go 和前端，那 wails 其实是非常好的选择。

这种情况我更喜欢的方案其实是用 Svelte 糊一个 SPA 出来，然后用 Go 写服务端和业务逻辑。

@nullcache #1

wails 也是很好的方案。我觉得用不用取决于两点，一看否有意愿去学习，二看能不能接受 webview 作为依赖。

逆向神器，牛逼

Go 几乎是对跨平台协作最友好的了，实际应用里几乎只需要注意 `CRLF` 这一个问题就好了，正常的 git 工作流当中甚至都不会有感知。

说起来大家可能不信，我很早就在 Linux 平台用 Go 开发 Win32/Cocoa GUI 应用，所用到的技术无非就是 CGO 交叉编译。

硬件选择楼上已经说了，显存要够大才能跑大模型。

如果你在生产机器之外需要一个开发验证平台，现在 4060 移动版的笔记本非常合适。相对台式显卡溢价低，8GB 对于验证程序来说够用了。关键是 40 系的能效比很高，而且价格非常卷。

NO

Chromebook 最大的优势是它内置了 Android 系统，同时有着非常长的官方支持。

至于 Linux 的硬件选择，同价格的笔记本选择要多得多。

“接收端做不到有能力处理重复消息或保证消息幂等”

换个表述方式，意思是不是

"接收端只接收，不响应"？

很多工控系统是这样设计的，设计的时候就没有“协议”这个概念，接收端“无脑”执行所有指令，默认输入信令永远正确且实时。（因为它可能就是一台单独的设备，从来没考虑过远程控制）

即使有响应，也不代表能正确处理“重复”指令。很多“响应”的意思是收到指令而已，并不代表指令的执行结果。（因为这类工控系统的指令执行结果是肉眼可见的）

建议用 wireshark/tcpdump 这种先看一眼，看看走了哪些流量，是不是 udp 协议的。

对于 tcp 来说，抓不到一般是两个方向，一个是非 http/https 这种，另一个是流量没走代理。

一端是 Ai 帮人写简历润色，一端是 Ai 帮人自动打分，突出一个赛博朋克。

反正对抗都上强度了，应该很快就能迭代到人机验证码水平，想想都觉得酸爽。

咸鱼上的秒解锁挺离谱的，连账号都不用登录，新机器激活完就能直接解了。

不过客户这边看不到是怎么做的，就是通过一个软件把本地 usb 挂载到商家的机器上了，大概率是售后渠道才能这么干。

Linux/Windows/macOS 上都有软件实现 QMK/via 的方案。原理都是在内核/驱动层拦截设备输入事件，根据用户规则重映射后再传递给对应的窗口管理器。甚至可以做到重映射 Win+L 这样硬编码的按键组合，和类似 AHK 可以判断输入焦点所在应用来切换配置的功能。

Linux 上早期基于 x11 的改键方案可以全淘汰了，基于 evdev/uinput 的方案可以提供对 wayland 的支持。相关的开源项目很多，比如 hawck/kbct/keyd 等等。

Windows 和 macOS 涉及到加载（未签名）内核驱动的问题，相关实现会比较少。Windows 可以考虑 interception+capsicain 组合，macOS 似乎 Karabiner 比较成熟。