没有设备，看了下文档。

猜测可能是没加 CA 导致的证书不信任？

在线会议最好还是上 mcu/sfu 吧。

直接在前端维护 peer 列表有点难受啊。

@ShinichiYao

这位老哥这个月好像没上线？

不知道能不能看到你的帖子。。

@litmxs #6

萌娘百科前段时间开始整改了吧。

也不知道还能挺多久。

@whileFalse #69

之前的回复没写全，想表达的是 控控这个产品真正牛逼的地方不是技术而是商业化。

家里有相关东西的话 DIY 出来一个 ikvm 的成本和难度(不是复杂度)不高，但是做成一个开箱即用适合大众使用的产品却很难。

这点才是我觉得他真的牛逼的地方，把这一整套组合成一个开箱即用的方案，不容易。

@whileFalse #42

向日葵那个硬件说白了就是个 ikvm 。

有好几个类似的成品开源 DIY 方案，可以去 github 搜一下。

技术门槛不高，hdmi 转换 + usb otg 。

@Al0rid4l #2

包作者哪怕相似也可以避免很多问题啊。

一般来说包的升级不会影响其所属作者，这样相对来说能够比较明确的区分该包是否由原作者发布。

@HuskyYellow #176

如 twitter 上所说，确实应该提个 pr 修一下删除不了文件的 bug ，不然很影响这个包的效果啊~

作者也是牛逼，想害人都因为自己疏忽没害成，服了服了。

sysprop 太自由了，没有这种东西。。

请自己翻代码。。

想省事可以上 electron 。

想提升 c++可以选 qt 。

你先说清楚，你指的驱动，是 source code 还是 binary ？

保质期不等于可食用期限。。

保质期其实就是你吃这个玩意出现问题了厂家在此期间内予以负责，仅此而已。

技术上可以。

用 webrtc ，不要用 vnc 。

vnc 不适合这个场景，实际用起来体验极其糟糕。

https://github.com/scottyab/rootbeer/blob/master/rootbeerlib/src/main/java/com/scottyab/rootbeer/util/Utils.java#L17

自己看吧

搞不懂楼主的逻辑。

1. 代码里的 key 不存在需要模糊检索对应用户的可能性，有就是有没有就是没有。

2. 微信的 key 想要撞出来是比较难的，微信开发团队没那么傻逼。

3. 要是幸运的撞出来了，那你扔到 public 本身也就是泄露，不存在误伤，因为确实有恶意用户专门盯着 public 扫然后尝试利用，扫描范围自然也包括你上传的那个 public 项目。

@fregie #3

各有所爱吧，我个人倒是觉得这个项目不错。

看了下楼主的 github ，似乎主力 java ？

建议稍微瞅瞅 php 官方文档，这玩意不难。

@edis0n0 #52

将技术方案绑定到平台来做比较其实是不太合理的。

1. 不同公司基础设施架构是不一样的。
2. 某些时候技术方案不一定是靠全局优势，还可能仅靠个人喜好或业务优势而被采用。
3.兼容性是根据业务而变的，如果已经完全确认不需要，那当然可以抛弃掉无用的那些兼容性。

归根到底，这其实并不是一个纯技术问题，跟业务和人有分不开的关系。

就从我自己开发中得出的经验来看，200 + post + json 是在大陆(港澳台没深入了解过)普通项目中最有兼容性也最省事的方案，但具体落实哪个还得看实际。

个人倾向于使用 200 + post + json ，不支持采用 http status code 来同时判断业务和协议的做法。

1. 与 http 协议耦合度较高
2. 不利于错误码拆分
3. 不利于排查，无法直观查看到底是业务还是基础设施问题。
4. 兼容性较差，楼上不考虑兼容性问题的是没被坑过吗。。有些玩意不是你能决定的，遇上了那就算是倒霉，现改业务代码和网关麻烦的要死。