@RLado
@fanrong
知道国内为什么一直都是讲人情么，不外乎就是你们这样的人多了，
１．要裁员，那按照劳动法 /合同法规则操作就可以
国内这么多这样的公司，明明就是选择做婊子，还非要立牌坊；没有契约精神，为了丝丝利益随意违法
要裁员要优化，说明公司经营出现问题——这本就是公司高层的锅，只是大家都比较擅长甩锅给没有话语权的普通员工

２．不要把没有关联的搅浑一起
转移话题把水搅浑，然后刻意引导，不就是某些人所擅长的
裁员与自己是否要有目标，要做好规划与促进自我成长，有一毛钱关系么？！

３．若一个公司连裁员都要通过各种手段来实施，只是说明公司业务在走下坡路罢了
这样的公司，大概率是已有的商业模式出现问题，而高层又无能为力

若非给钱非常大方或福利待遇好
这样还能忍下来继续做的，大概率是属于走不了的人

优化的方向，其实一个是流量，一个就是延迟。流量是节省成本，延迟是提高体验
也有会结合类似超分辨率的

@puzzle9 #48
很多，据我说知道的，相当部分一二线的大中厂，都基于 webrtc 做自己的直播系统，应该说是视频云——因为搭建起来之后，直播、点播、安防、教育与视频会议等，都是支持的

当然，这个核心是全球布点的 cdn 网络，加上基础设施。当然，也会投入人力物力，对延迟做优化。方向呢，比如编码算法、带宽预测（如引入深度学习预测带宽）、优化 qos 机制与算法等

@laravel #43
若要低延迟的话，要用 webrtc 的方案。基本可以保证可以做到 1 秒以内，网络状况好的话，500ms 也可以达到

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

真的为了推自家的百度 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 相关行业，转产品是毕竟适合的
其实，市场也是可以

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