@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. 兼容性较差，楼上不考虑兼容性问题的是没被坑过吗。。有些玩意不是你能决定的，遇上了那就算是倒霉，现改业务代码和网关麻烦的要死。

想问下，这个与 1password 等软件相比有什么明显的优势呢？

UI 这边捉个虫：

https://hk.dash.fastblob.com/billing 的 Add Bandwidth 可输入负数。。

希望楼主能加个扬声器来支持语音播放。

蜂鸣器和 LED 能传递的信息还是太局限了。。

感谢分享，第一眼看成了噶山。。