借地方顺便问一下，Clion 你们怎么搞定环境变量的问题？
比如我的 cmake 会根据环境变量，加载不同目录的不同代码，这些代码实现了相同的接口，比如驱动的封装。
碰到这样的代码，我的 Clion 好像什么提示都给不出来

为何楼上各位都不考虑前后端分离呢？这样后端要做的，与 C 的交互，不就仅仅保留了一些简单的数据或者说设备状态。比如用 RPC 来查询主工作进程。

至于一个静态的 HTTP Sever 部分，那个简单的开源版本，几本可以直接用了。

看起来关键分歧在如何理解“配置了节点 机器 b 的信息”，如果这里指的是 jenkins 的 slave 节点，那么在 B 上运行 1 和 2.
但后面提到只是在 B 上运行，那边 B 就仅仅是部署机，1 和 2 在 A 上运行。
所有关键是，“配置了节点 机器 b 的信息”具体指什么

“听说”一词，说明在技术选择和方案设计上，你是被动的。为什么不是我们做了 xxx 分析以后认为应该改到 websocket ？

@dangyuluo 其实不要以为这里把顺序调整对了就好了，你会发现后面还有别的顺序问题。只有 group 最可靠

target_link_libraries(main
-Wl,--start-group
c++
c++abi
m
c
gcc_s
-Wl,--end-group
)

好用的定义是什么？

@47042 思路类似，原厂是怎么防止你刷 Recovery 的，你就怎么防止别人刷。不过你可能需要 fastboot 或者更底层 boot 的源码，这可能有点困难。

自己编个 Recovery，验证自己的签名。原厂的 Recovery 就是这么玩的，只不过你没有它签名的私钥而已。

第一感觉这个方案很奇怪，关注一下听听大家的说法

你这应该是无用户概念的场景，这种场景下只能尽力而为的做认证，常规的方法从安全到不安全：
1. 设备出厂时加密预制证书，服务端校验证书（这个应该不适合你）
2. 设备出厂时加密预制唯一 ID，服务端从数据库查 ID 校验+TLS，换取 token （这个应该也不适合你）
3. 直接使用设备的唯一 ID，如 UUID 加一个签名校验+TLS+服务端监控异常的 UUID
4. 在 3 的基础上，不换 token 了，直接使用 UUID+签名校验+TLS+服务端监控异常的 UUID

另外，顺便问一下大家 3 和 4 的安全性到底差异在哪里？
虽然 token 能改但 UUID 不能改，但 UUID 换 token 的过程如果被抓，结果是一样的，偶尔使用一次比经常使用安全多少？类似 RefreshToken + AccessToken 的方法，究竟比只有一个 AccessToken （过期等于 RefreshToken ）安全在哪里？

这道题，感觉怪怪的。开 3 个线程，然后居然没有一点并行的需求

这个场景下，你们把 key 翻译成密钥?

按合同赔 1 个月，这不算被坑。只能说你中介费给高了，以及违约金（一般等于押金）约定少了。

几百 G 了，不想使用数据库的原因是什么？感觉自己实现个索引肯定不如数据库做的好。还是说你想搞明白数据库建索引的实现。

之前米粉卡有一种可以取消来电显，0 月租，6 个月发一条短信 1 毛钱就行了。现在不知道还有没有。

不是一个价位的怎么比+1