现在 go 错误处理比刚出来的时候好多了，繁琐是有点，但是没啥心智负担（对写应用来说），只是和 rust 比起来显得有点草率，基本和 rust 无脑 anyhow::Error 一样

@sadfQED2 依赖注入多好啊，刚改了，极大解放

不过我不喜欢 一堆 do vo dto 单纯不喜欢这个名字，有必要还是会用类似的分层方式

1. 先找个能满足你需求的 kv store, 不限制语言，看看你需要的 feature , 需不需要 事物, 快照 等, 比如 rocksdb
2. 看看这个库有不有 python 的 bind
3. 如果没有，可以考虑 PyO3 自己简单撸一个

而对于那些已经编译过的产品的漏洞发现 并不像你想的那么难，开源软件的漏洞挖掘也没有你以为的 看源代码那么简单, 有几个问题会导致这个情况, 1) 代码量太大，即使开源软件也不太可能一行行去看代码, 往往会带有一定目的性 2) 肉眼可见的漏洞往往是少数，这种漏洞基本上通过一些 代码质量工具 就能有提示, 3) 更多的需要你对 计算机\目标平台\目标软件业务 有或多或少的了解, 简单说既要全局又要细节, 思维模式上和正向开发的思维是不太一样,

-- 需要反汇编去分析吗？某些时候需求，某些时候也确实是要分析一些详细逻辑的，但会带有一定的针对性，下面说
-- 有哪些套路: a) fuzz, 这是现在漏洞发掘主要的手段之一, b) 总结历史一些漏洞出现的 pattern ，再依据这些 pattern 或依据人工或依靠工具 去发现类似的漏洞, c) 某些时候也可能要开一些脑动, 整体就是，搜索空间无比巨大, 要用一些方式来提高效率


漏洞的详细情况，产品方一般是不会说的，一方面，有确实延缓传播的意图，二一方面有法律法规上的限制，如果只是修复，看产品商就可以了

一些历史的有利用价值、有启发性、有意思的漏洞, 你 google 一下还是有的，应该不难
比较新的，或者比较鸡肋的，利用有难度的（很多漏洞只在理论上存在利用可能），影响范围小的 可能就没有了

不好吗，感觉挺好啊，我用 win10 也开了合并，可以搭配下三方的窗口管理器

怎么就得出`不会有什么好处` 的结论呢？最多就是他解决的不是你的问题而已

@thevita 是指 golang 的 sql 包

真要说起来,
@hxtheone 是的，就是 type system 不一致的原因，类似的情况其他语言也一样会存在，同样的问题 sql 也一样存在，完全可以参考 sql 的解决方案呗，扯半天扯不到点上。

问题还是 go 的 部分 value type 没有 null, 这点与 json 不一致，要弥合这点，

1. 让 go type 去 match json ，可以引入 Null* 的 type, NullString, NullNumber 什么的,
2. 让 json match go type, 依然通过 NewType 实现 UnmarshalJSON 来验证数据呗

@unco020511 mr/pr 不是 gitlab/github 的功能么, 这还用插件?
---
感觉没必要完全 gui/cli, 这两者对 git 来说又不是互斥的选项, 我都是一起用的，那个顺手用哪个， 比如解决冲突就会选择切换到 gui 来

国内环境，服务行业节假日不放假不算什么吧，（如果你是后端，那确实福报）

@Morgan2 因为他故事框架没啥敏感的吧？是 R 级片 是不是因为有少量情欲描写？，这部分事实上 在部分国家上映的时候都有调整

《奥本海默》不难懂吧，不需要什么 物理/量子力学 的背景知识，毕竟纪实电影嘛，无非叙事方法上 显得可能有点乱？，但也还好，我是开幕了几分钟才进去的，经历 几分钟 懵逼也能掌握的叙事的方式，后面看起来就没压力了，不过我确实不怎么喜欢，对这种纪实类型比较无感，但并没有让我昏昏欲睡，诺兰还是 nb 的

aws 国内可以用吧？我就用国内信用卡啊，还有电话推销呢

看业务需求，不要被“脚本”二字束缚住了手脚，关键是业务需求是如何的，并不是一定要是一个 script, 因为 `脚本` 本身还是个技术 term, 因为这限制业务分析舍本逐末了

作为一个 平台，对外的提供可扩展能力, 其实目的也不一样啊

是需要 一个 glue lang 来调用平台 api, 实现灵活的逻辑呢？ ( 这可能比较符合传统很多 script 的定位, 比如 lua 定位就是作为 glue lang 存在)

还是需要接入其他三方生态（ 比如允许加载 自定义 jvm class 很多 jvm 生态里的东西也许有可能接入）

等等...

总的来说，具体问题具体看，心态开放点呗，尽量不用自己领域的知识向外，不然很累。

我很喜欢
--
如何反馈:

Help-> Submit Feedback...

or

取消订阅，这样你的意见就反应在他们的营收上了 QAQ

title 和 content 描述的没啥关系啊,

路由的过程就是查表: 依据 packet dip 查找下一跳地址

NAT 也是查表: 会 记录 intra ip, sport, dip, nat port 的对应关系,(表中项不一定，实现会不一样）, 这样 回包的时候，就能找到 原来发包的 intra ip 和 sport

obs, 不过就像上面说的, 根据你要露的内容调整下 分辨率, 码率, 帧率 等参数

我 5 月份被拖去顶了个项目，甲方要求录屏留档，第一天用 macos QuickTime 录一天 8 小时 结果 20G, 换 obs ，1920x1080 10Hz 就两造出头

唯一问题就是在我的电脑上没有硬件编码

@thevita

文件同步的方案我觉得不一定不行，如果规模就是这么大，存储又能接受，是可以的，关键是简单
至于以上说的弱点:
a) 带宽问题，目前也不大吧，完全用不着 rsync 这样的，搞个什么简单的单向同步就行了（反正也需要保证不会冲突），带宽利用率还是很高的，rsync 需要 diff 完全没必要嘛
b) 巨量小文件是个问题，但是还是看场景的，况且也不是不能优化