翻译一下：“经验太少” = “我们需要能直接接手烂摊子入职开始 996 的熟练工”

升 libc 是本末倒置，最早我也试图升过，后来想想，为了一个程序的依赖去破坏其它所有程序的依赖，问题不是很大嘛

docker 正解。linux docker 开销很小的

“歧视 svn ”的原因在于 互联网行业开发特性就是迭代快，版本多，分工细，模块上线时间不同步，这些因素迫使大家去选择“倾向于多人协作”的 git

你可以想象一下用 SVN 得撕逼撕成啥样：
“哎卧槽说了这个 pipeline 没跑完之前不要 push 啊，没测完就加个新版本进来到时候怎么合啊”
“哪个傻逼往公共主线上推了一个没写完的微服务，赶快出来挨打，我 tm 删构建代码都删了半天”
“什么？ 分支 1 上这个特性在 r305 就有了啊，怎么分支 5 都滚到 r378 了还没加上……什么？代码结构变了没法合并？那你赶快给我重写一个一样的，今晚搞定可以吧？”
“ A 你跟 B 的模块对接完成了吗？ 啥还没搞定？赶紧搞完，别的同事都没法上传代码了”

两个工具的倾向很不一样

svn 主要作用在于控制版本历史
git 的目的在于多人协作


违背设计倾向去使用无论哪个都会寸步难行
SVN 你想在多人合作下细粒度地分工并行简直是噩梦，带薪开分支我笑了了一下，而且其他人是无法容忍分支上有 wip 节点的，他得从过去的某个 full-featured 节点分支出去再 merge 回来，这对于 svn 来说简直相当于上刑
GIT 的话首先它的历史系统真的太复杂了，一个 merge 节点包含过去两条并行的历史，一个复杂的多人协作项目，用可视化界面一眼看上去 5 条竖线顿时头大，更别说没 GUI 的话翻 commit 能翻成傻逼，这很大程度也是为什么几乎所有用 git 的项目都要强调“在 merge 到主线前必须 rebase ”，目的就是减少并行历史，节点逻辑相对清晰。而 SVN 的特性决定了没法搞出来这么复杂的节点历史树，每一个分支都是源码副本的单线历史，非常清晰

“我在准备告诉你关于未来的信息时设想了一下我是否会接受以后的我向自己传递信息，答案是——并不怎么接受。鉴于我清楚我的人格和思维体系在从你到我的时期一直保持稳定，所以我能确信你也不会接受我直接告诉你未来的事。但我也知道我必定会十分惋惜并骂这么好一个机会我怎么这么傻逼啥都不说，所以我唯一能向你透露的是，在你的时期所担心的事都没发生，未来的情况大体上还是向着你梦想的偏好的方向发展的”

哎。。。 建议别把自己不熟悉的领域想象得太简单。。做媒体还是很难的
据我的观察，全职 up 的主要收入来源在于与平台的协议和直播分成，在 B 站单集播放 6 位数充电打赏收入可能连 3 位数都难
然后 5 位数以下粉的 up 都还是透明人，能带来收入的期望为 0，要到 6 位数粉才能获得足够的可变现流量，而运营出这样一个账号就算是专业运营也得差不多一年，纯个人势慢慢累积观众的话甚至做
100 期视频能收回不到 1w 个 follow，这还是在人气相对较高的游戏区


首先投视频赚零花钱本来就不是个好主意，说难听点有点吃力不讨好
其次入门向的东西很容易泛滥，做从 0 到 0.1 也不是个好主意
最后，在 B 站投视频妄图带来收入是最差的主意，任何分区都一样

不知道你怎么给一种 featured class 定义“表达能力”以及“上界”的

用 shared ptr 完全可以连出环，只是不能自动析构而已，手动断连一个指针后剩下的链完全可以正常自动全部析构


如果你想问适用场景的话另说

v2 网友脑子中的软件工程：
设计模式，框架，应用容器，敏捷，devops，协作效率工具，方法论
你老师脑子中的软件工程：
用 c# winform 或者 c++mfc 开发连接数据库的 xx 管理桌面程序

哈哈看到这贴特意去翻了一下我的 foobar 目录

<dreamix 说明.txt> 2012/9/22

从好多台电脑间辗转腾挪直到现在了

不是自己的原因离职只要写清原因应该问题不大吧

其实我说 yy 这个功能的意思是 就语音通话来说并没有双声道的需求所以不奇怪，有需求的时候比如要唱 k 直播，那么麦序模式就有符合需求的功能

fake gear
rust gear
super gear
hyper gear

中二系 233333

@dxgfalcongbit 高音质麦序是双声道的，我记得是这样

yy 开高音质上麦序


聊天通话为啥要立体声？ 你的麦单声道的

100 年后整个计算机科学界最重大的变革：

C 语言终于成为历史

人们终于可以直接从可视化设计工具直接生成汇编和机器码了！
可喜可贺！