用于开发环境绝对还是选一个折腾少 DE 完善的版本
一个 bundled IDE 绝对比花大量时间和心机浪费在配编辑器配环境上省心太多，而且某个版本用久了会产生强烈依赖感……
个人是从不参与党争的 lowb ubuntu+gnome3 党，一个是比较习惯并且习惯 gnome3 的桌面，另一个，足够稳定幺蛾子不会太多，还有就是当要装什么 [显卡驱动] 啊，什么输入法啊，杂七杂八的国产半成品啊，的时候，ubuntu 已经是最不麻烦的发行版了。
ps.自从一个月前我的 win10 insider preview 莫名死于一次正常重启一次以后更坚定了只用 stable 的信念，非要用实验版本反正再拖源码编译嘛，但滚动 experimental 绝对，绝对要慎重考虑有没有必要

个人比较看好虚拟化
特别是自研的虚拟化，跟自研芯片结合的那种。lz 是研究云计算的，也比较适合继续研究下去
未来 10 年会有相当多的基础设施技术要国产化，云技术方面也还有相当多东西要挖，绝不是 hadoop 怎么用的层次，而肯定是要达到国产自研超越 hadoop 的程度。之前看阿里的软文说他们已经有了整套的自研大规模分布式虚拟化方案，别的大厂肯定也很快要跟上并出台国产业界标准框架 /平台的。
现在软件层面的自研技术 BAT 已经能达到国际顶尖水准，但硬件方向还早，这一轮芯片门和贸易冲突有望推动国家真正把重心往高精尖上转移
希望未来能看到基于国产芯片的国产云技术栈
.
以前学的少，觉得硕士博士傻读了那么多年还不如早点赚钱
现在见识多了一点之后发现，深层次的东西我们普通人真的是心有余力不足的
于是我只能寄希望与其他人去研究自己想研究但研究不来的东西

@haxiwa 反而让我意想不到的是，虽然区块链本身没啥可盼的，但面向区块链的安全却确实有不少东西值得挖，如何保证签名安全，如何防护利用智能合约注入恶意代码，如何防止由于某些意想不到的设计问题使某些恶意攻击（如签名碰撞之类的）扩散到全网，这些是之前没想到看人在搞才发现的

@haxiwa 个人真的觉得区块链没什么革命性的，甚至新的，东西，都没有，说到底区块链就只是内容+上一块的签名
真正有意思的恰恰是更没用的[链→币]的部分，用挖矿来解决记账权和共识问题是一石二鸟双关又鸡贼的方式，然而整套系统还是玩具，只有[币]这一种玩法，脱离了挖矿这一奇技淫巧剩下的“内容+签名(内容+签名)”就是十分普通的标准公私钥体系的东西，区块链=历史签名，凡是要记录历史，那么都可以用区块链，凡是区块链，唯一用处就只有记录历史。

。。。。。。。。。。。。。我才发现我是
nue lue lv nv

如果对这个都不了解换我我可能直接拒了

。。。。。。。。。。。任何一本 python 入门数都会讲的东西

情商这东西。。。我觉得绑定性格的
情商高首先对人关系的感觉要足够敏锐，第二你要肯花心思去维护人与人之间的关系
有些情商低纯粹是因为木头感觉不出气氛察觉不到情感
有些情商不怎么高的人比如我自认我自己就是感觉很敏锐但懒得花心思去维护
我很多时候会，“啊，这气氛，哦你是这意思，那其实这时候应该这样说比较好，但我不喜欢这么说，所以我还是这么说正面怼虽然你可能不舒服但抱歉了这是我风格”
察言观色读空气是可以训练的，但我觉得之后的这步才比较难

问辅导员问上一届 ×
上 v2 发帖 √

很快会腻
纯命令行根本就不符合当下流行的交互方式，反正我折腾完一圈发现最喜欢的竟然还是原版 Gnome3
要达到这种效果放多个显示屏开个能划分窗口的 terminal 就行，没啥必要费劲巴力去折腾又难配又难交互的 CLI 环境

标准里就没规定 string 必须\0 结尾
std 的 string 就是跟结尾 0 无关的，可以当做普通 buffer 来用（甚至还加了 data()成员函数）
而且不规定 string 必须 const
c_str 只是为了与 c 兼容

没见有 reserve 和 capacity 嘛，在[size]处预留个 0 呗

鱼眼镜头 xN + 拼接融合算法，回放的时候把拍摄图像映射到包围盒 /球 上

其实用任意镜头都可以拍，但拼接算法比较难出好的效果，所以尽量都用视场角大的镜头减少拼接边缘

最简单的设备，比如 insta360

看报错 F.function 应该是个 callable，比如 std::function<double(double,void*)>之类的东西，构造这种东西要么就用 lambda，要么就 functor （重载了()运算符的类），bind 就是用模板构造一个 functor 的方法，但其实现原理相当相当复杂，特别是，如何使 functor 绑定到类成员函数上。用 lambda 就容易理解得多，闭包捕获是世界上所有能进行 functional programing 的语言都通用的语义，把 this 指针捕获进闭包中，然后返回这个闭包。虽说会多出一层显式的调用 wrapping，不过这个 lambda 几乎一定会被优化掉，所以也不用担心这个问题

F.function = [this](double x,void *param){return f(x,param);};
或者
F.function = std::bind(f,this,std::placeholders::_1,std::placeholders::_2);

@XIVN1987 emmmmm 好像的确是这样，但属于 qt 框架本身的东西可以绕开 python 封装，worker 线程间可能会被 gil 影响，但 gui 的部分应该影响不着

当然了我也是猜的，确实没细想过这种问题

@XIVN1987 qt 的 runtime 都是 c++封装的，不必担心

类似于 run1(){PyEval_CallObject(run)}