@gadsavesme #42
你这个是谣言。实际执行的时候，并不需要房东备案，而且也不会因为申报租金抵税就要房东额外交税

#41
实际上，房产税、空置税与遗产税自然会中长期增加二手房供给，这个是事实。目前 zf 就是骑虎难下，怕因为对房地产行业造成过大的波动与冲击，所以这几个税一直出不来——毕竟利益集团那么强大

但是你要知道，zf 也意识到，以往靠买地这种方式难以继续持续

@xuanbg 这个我认同。确实相当部分搞 IT 的缺乏足够的逻辑与工程能力

提 Ticket 给 Google 是最合适的做法，也最保险。数据最重要

不过导致的原因呢，大致有如下几个，
1. 中间内核或驱动有升级，导致 panic
若确认是内核升级导致，可以进入 grub 修改引导，用原先的内核就可以

2. 硬盘损坏
某个分区或分区的某部分损坏。这个的话，可以创建新的实例，常识把这个硬盘（分区）挂靠到新的系统，若可以正常访问，则可以把数据备份出来

3. 其他
暂时没遇到过别的情况

@newtype0092 #35
1. 你说的这些，广义来说是属于算法范畴
简单点算法就是解决问题的一系列步骤；但你要知道，楼主所说的，我们一般意义上讨论的不是这种广义的算法，因为诸多语言或公共库都已然有实现，且效率不低

我们一般说的算法，属于没有通用解决方案的算法；都是针对特定的场景，比如推荐、海量数据、图像或图形等

2. 关于工程能力
简单点就是对算法的实现。但实际工作中会广泛很多。比如要考虑高性能高并发、维护、扩展、运维等等诸多方面；也包括代码的实现、理解等。其实就是除算法之外的所有，都属于工程的范畴

@newtype0092 你说的这些确实不属于数学或算法层面的。至多只是工程能力

总感觉，相当的一部分人连简单的逻辑思维都没有

建议还是改下标题，你这个因果是一毛钱关系都没有

你所谓的技术下降与所谓的人品，都是结果。没有互为因果关系

楼上绝大数人都不适合做老板，也不适合做管理岗

1. 每个岗位若可能，都需要有 backup
对于题主所示，一个相对资深的后端为主（熟悉一定的前端或有意愿学习）+一个前端（ p5 都不一定需要）

对于前端要求，需要有对后端技术学习的意向。最终要形成的是每个岗位（前后端）都有一个主要的，一个次要的
这样效率与风险都是最好的

2. 两个人的产出最终都会大于一个人的产出，风险也可控

微服务最大的两个优点呢，就是
1. 解耦
包括不限于技术栈、开发、运维、数据库等，就是每个服务这些都是独立的，彼此之间不会相互影响

2. 业务集群动态扩展

而你非要搞个数据库服务；那么，就通过数据库服务把所有服务都耦合到一起
而对于采用微服务框架的，还引入一个数据库服务的系统来说，就是数据库服务是修改最频繁的服务——那么，就会影响到所有的其它服务，给所有服务引入不可预知的问题

一句话，决定这么搞的确实是脑子进水了

当然，真要搞，那就更彻底点——可以参照 TiDB 那样，把所有的 crud 还是在各个服务；做个代理，实现标准的 DB 协议（比如 SQL 等）

对于 Qt，只要不修改源代码并且动态链接，是完全可以发布编译好的库的，也可以和闭源软件一同发布，这是没有问题的。

在这个用例之下，LGPL 的重点在于：
1、不修改源码
2、动态链接
3、不修改 Qt 库的分发版权，并提供原有的版权声明

是否秒开，跟采用的语言，是不是 h5 没有关系。关键是流媒体传输的方式，若是传统的直播类协议，如 hls、rtmp 这些，延迟 2-3s 是正常的情况

若要秒开，可以直接基于 rtp/rtcp 进行传输，或者采用 webrtc 这样的方式

若是 C++做后台服务器开发，那可以转；对后端多做些了解，对以后是加成
若是做客户端，就不要考虑

升级使用 go mod 之后，vscode 折腾老半天还是没正常过
还是 goland 省心，一次配置没有任何问题，一切正常

好聚好散，及时止损。若花的不是自己的钱，那无所谓，继续撑就是

１．评估工期极可能长
各种可能都要考虑到

２．把自动化测试都自己搞起来
开发个小模块小功能，没事慢慢把所有用例过一遍＼两遍＼三遍，确认没问题再提交测试


其实一句话就是，把测试的工作顺手就做了，而且要反复多做．测试会轻松很多，建议内部转岗测试

其实你就是把简单的问题复杂化了

用户态，由于无法一次处理完数据，基于性能考虑（避免不必要拷贝）。其实，你需要做的不就是要记录读写两个位置的地址而已

比较通用的，就是环形缓存，数据结构选择你喜欢的都可以，比如数组

@goldenalex #121
更大的压力是边缘节点或服务器端的带宽压力，大概率短期是无解
现在所谓的云游戏，通过类似 rdp 或 vnc 效果是不会好的。真正体验好，就是服务器端根据模型与数据，生成视频流，然后客户端就是类似现在看视频网站差不多——体验自然可以好很多

有人说小公司不要用微服务，恰恰相反，小公司更应该用微服务。因为这样整套框架搭建起来之后，在招人用人及运维方面，都是极其节省各种成本，提高开发维护效率

微服务，火了好几年的东西。曾经我们看中的是微服务拆分之后，每个项目变得更小，对团队的每个人来说维护成本降低，因为需要了解 的东西局限于一个更小的服务。第二是加强了技术选型的灵活性。但是由于没有实践，并不知道微服务会带来什么大的问题。 当我们大规模应用微服务之后，问题才开始慢慢显现出来。

网络调用过多
-----------------------------------------------------------------
不知道是如何评判过多？是影响到带来额外的处理延迟，还是性能瓶颈，或是带来额外的运维

技术栈太过灵活
-----------------------------------------------------------------
有很多选择又不是以为着所有的都会使用。若出现混乱（如随意选用技术栈等），这是管理的问题
选用特定技术栈，自然是有响应的好处

难于应对连表查询的需求
-----------------------------------------------------------------
这是架构或管理要背的锅

核心应用崩溃会导致大面积瘫痪
-----------------------------------------------------------------
降级，限流就是来做这个的

运维成本增加
-----------------------------------------------------------------
短期看是带来运维成本增加，但若真的把 devops 用起来；就算是简单的把 docker 用起来，看到的都是节省运维成本

接口风格不一致
-----------------------------------------------------------------
管理要背的锅

上面就是个人总结的一些微服务所带来的问题。对每个缺点的详细说明请看原文 :)