百度系产品的产品经理，大概率是脑子有坑
包括不限于搜索、网盘等等

真的为了推自家的百度 app，无所不用其极

纯软件的产品，从运营的角度来说，技术都不会是问题（极少部分除外）

@laravel #18
有没延迟，跟是否 5g 时代，确实没有关系。比如 rtmp/hls 这些延迟，是其方案就决定的

很多人说到 5g，必说低延迟。但是没有一个人意识到，理论值与实际值的差距究竟有多大
我就问一个问题，

wifi/以太网 /光纤理论延迟是多少？而且实际应用场景，假设延迟为 t，那么 t 的范围是
t_min < t < t_max

我就是想知道，5g 是否能够保证各种场景各种环境下，t_max 的值。如果不能，那又有多大意义

@cnkuner #45
1.灾难预警系统全面铺开（比如地震预警之类的）且效率更好。
2.交通信息快速收集传输播报，以适应更加智慧的交通出行。比如基于位置和目的地的实时公交规划与调整、车辆疏导、事故处理、车联网等。
-------------------------------------------------------------------------------
为什么你会以为灾难预警与你说的各种收集，是差了那几百毫秒的地方？

3.高铁、铁路 WiFi 带宽更高。
-------------------------------------------------------------------------------
高铁铁路缺的不是带宽，是覆盖率

4.以多组摄像头视频实时合成场景，催生新的购物类体验（快速构建商场实景，单身狗在家逛商场）。
-------------------------------------------------------------------------------
好奇怪，商场了为什么不用光纤＋ wifi，家里也是一样的道理。是家里的光纤不够快么？还是商场的光纤不够快

5.无人机采用 5g 信号操控，实现更远的飞行操控距离。
-------------------------------------------------------------------------------
无人机操控距离，缺的是覆盖率——不是你说的延迟。你觉得 5g 覆盖率，会比 3g/4g 大？还是说 5g 基站成本更低

１．若是系统原因导致的重启（包括不限于应用、内核模块或驱动等，及内存泄露或溢出）
基本是可以通过系统日志可以看到端倪。系统或内核日志一般都在 /var/log 下

２．对于可能的内核 crash，建议开启 kdump
其实对于这个，#1 中的日志是可以获取到蛛丝马迹的

通过系统的 uptime 可以初步确定系统重启的时间点，然后结合系统日志，可以初步确定是软件原因（上述的#1/2 ）导致的重启

若日志都很正常，那基本是可以确定是硬件的原因，比如电源或别的

对于音视频方案呢，若处于商业模式验证阶段，用第三方是最适合的；毕竟相对各方面都好控制
验证模式可行，再逐步组建自己的团队，采用自研方案（毕竟定制化与成本更好控制）

第三方的方案，目前来说声网是最好的。对于视频，收费都是按照流量来收费的；对于大规模运营，最终都会转用自己的视频方案——因为最大的成本就是流量

对于其它（如自研视频），
1. 1 对 1 的
p2p 现在成功率还是很高的，基本可以达到 95%以上；所以一般采取是 p2p+sfu 这样的方式
若要跨国家或地区，还需要搭建自己的流媒体分发网络，就是类似 cdn 那样的东西。要在不同国家地区部署服务器

2. 1 对多（就是直播）
若对延迟要求不高，都会推流到 cdn 那边；若对延迟要求高，那就要做自己的 cdn （如基于 webrtc 的方案）
当然，对于此种情况，也是可以采取多种不同的策略优化体验与减少流量；

因为流量成本是大头。只要用户数上来了，用第三方都是不太适合的（因为成本就是流量的成本）

3. 点播
都是非常成熟的方案

4. 多对多？
其实就是多人互动连麦+直播的方式。一般是 mcu + cdn （私有-webrtc 或别的）


其实若要自己研发视频方案，最大的难点是流媒体分发网络的开发（私有 cdn-要支持 rtp/webrtc ）

@lersh #12 对于都玩 rpi 或 jetson nano 的人，udev 要写规则文件，这不是常识吗？

@hantsy #159
１． delete/put 很多时候理解起来是比较让人费解
因为 delete/put 可以实现的，get/post 都可以实现——那为什么还要另外搞一套
这也是为什么实际应用中 delete/put 用的是越来越少

２． Proto 并不只是你说的在传输格方式上做文章
Proto 其实要做的就是将数据序列化这部分工作省下来，特别是内部多端(grpc 就是非常典型的应用）或提供 sdk 的方式

３．关于对外提供 API
实际应用中主流的，应该是一种简化的 REST 风格的。其实做法就如本文标题所描的，就是只用 get/post，url 不传递参数。这样使用的确实是越来越多

４．对于 url 不传递参数——这样场景是越来越多
因为很多时候有各种需求，比如，
ａ）换传输层
http 换成 ws/wss，或者 mqtt 等类似

ｂ）协议对接
简单点就是各种针对性的 bridge （比如协议、ｄｂ或第三方等等）

长远来说，飞行员方向自然是最适合的。因为对于飞行技术，属于越老越吃香的那种
不会有所谓的中年危机

另外，对于 IT 相关技术，作为一种兴趣爱好就可以；没必要作为职业生涯

优势与语言与文案功底，若要选择 it 相关行业，转产品是毕竟适合的
其实，市场也是可以

不建议转技术，因为没有任何优势

@qqxx520 　#58 比较认同你这个看法，就是 30+之后侧重是将自己所拥有的资源（经验、阅历、人脉、资源或产品）充分利用起来，以期最大化已有资源的利益

只是技术出身的相较市场或产品的人，想法不够活跃，绝大多数人都没有能够很好的提前做好规划；当然，这也与所处的环境或拥有的人脉有关，也有部分是从大学或毕业之后就一直有个指引着方向，做好规划

若是可以，还是建议大家及早规划好，对市场或产品还是要做一定的深入了解与学习。只有这样，在机遇到来的时候，才有可能把握住

@lewis89 #57 分布式属于第一代，微服务是第二代，服务网格则是第三代。。

@ruidoBlanco #18
1. 关于天时
这个感觉纯粹是一个运气的问题。比如淘宝，可以发展起来是综合各方面的因素的，包括近几年的 pdd 等
为什么说是运气，比如前几年非常火的互金行业，但这两年大部分都破产清算了

2. 关于地利
这个在国内的，基本是没得选

3. profit center
这个就要选择合适的公司与业务线。或许，我们能够唯一可以努力的方向就是这个

@classyk #20 说的很实在，只是这些都是类似软实力方面的，很多人并不见得愿意过多关注，毕竟无法带来直接的利益——特别是短期内都看不到效果。

其实如你说的管理职责或者带 team，但是要知道架构或管理岗的，基本都是一个萝卜一个坑

@lewis89 这个我认同——要关心技术之外的事情，只有这样方可以长久