国内绝大多数公司，都不存在对员工的信任，这个从钉钉的流行自然就可以看得出来

@chitanda
@mugglezzz
谢谢推荐，刚给爸妈一人买了一台

@testver 嘴炮一下赌什么，一点意义都没有
若真要赌，开个盘——然后根据不同年退出，给赔率，一赔十还是一赔百。你要敢，就陪你玩一把

若有资源或门路的话，做外包相关是可以的
或者，有会员卡类似系统（加小商场或小程序这些），地推也是有空间

广氏菠萝啤

@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 ）导致的重启

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