你没听说要处理加密货币了吗？
听你这么一说，我猜上面决定将一切炒币直接定性诈骗了

哪有人刚上手就服从性测试的？（哦想了想大概还真有，而且是个我嫌他傻的人

只要我自己也不知道我是哪里人，别人就问不出我是哪里人。

不看视频，看书，性价比最高（当你的价格=0 的时候只要一点点性能性价比就直上云霄）

@no1xsyzy 这就要问是先有鸡还是先有蛋了 —— 是先有人用 Google 才转还是 Google 强推才有人用？
同样 JVM 语言，Google 为什么不推 Scala 、Clojure 呢？

TypeScript 是 JavaScript 超集，71k star，比 CPython 38k star 多（

@1002xin @Limius 不，别碰任何流媒体。技术手段比较难，建议直接住深山。

@fredli Kotlin 不是 JB 的吗，只不过 Google 转过去了

MS 搞了 TypeScript，倒是算不得什么新语言

@AkideLiu @hitmanx cache lookup 也可能是在 callee wrapper
比如 Python 可以直接拿 functools.lru_cache() 修饰符，SICP 3.5 也随便地写了一个 memo-proc
这提倡了一种正交性。

发现其实没理解问题，现明晰一下：

输入样例：
```
1 /abc/empty1
2 /abc/empty1/empty2
3 /abc/empty1/empty2/empty3
4 /abc/file.ext
```
输出样例：
```
5 /abc/empty1
6 /abc/empty1/empty2
7 /abc/empty1/empty2/empty3
```

输入是否是整个层级？还是末端层级？（即，输入是否包含 L1-2 ？）
输出是否要包含子目录？（即，输出是否包含 L6-7 ？）

因为「有序」，可知上层目录必定出现在下层目录之前
搞个 set，遍历列表，添加自己，删掉上层。
或者也不用搞 set，新建一个 list，反正能删的肯定是最后一个，检测一下最后一个是上层就 pop 掉就成。

@loop00 最后 9 秒眨 13 次眼，是正常人能做出来的吗？

@RyuZheng 原论文： https://doi.org/10.1016/j.cmet.2020.01.014
在经过两周的暴露以后，三氯蔗糖与糖的混合物降低了胰岛素敏感度，这一现象与对甜味的神经反应减弱有关，但甜味感官并未发生变化。单独的三氯蔗糖和糖均不受此影响。
血糖水平不稳定和肥胖发生有关吗？是容易诱发二型糖尿病吧。

@KanVivii 要警惕一下磷酸。一般汽水会为了避免二氧化碳析出添加磷酸，在配料表上可以看到。磷酸是足以腐蚀牙齿的强酸。
（现场充气的应不受影响，确实经验上气跑起来也比预包装的要快）

@EasonC V 站可以重名吗？
https://i.imgur.com/QJDQv8F.png

DCT 会有个问题，在维持总体平均码率的情况下，亮场码率高，暗场码率低
你可以看看一些画面变动频繁的游戏，比如各种 FPS，或者我刚听说这个的时候正好老菊在更骑砍 2，也是非常明显。
现在一个技巧就是，在上传时候的视频把亮度直接调高，压制效果就好不少。

根据 #3，https://nixos.org/ ？
podman ？

@silk 完全 ok 的，JSON 就是 JS 里面的「对象」(O)的「表示方式」(N)

@AndyAO `man bash` ，搜索 「 Pathname Expansion 」
传入了以后如何看待这个 '*' 是被调用的程序本身的想法，说不定被认为是正则的一部分，或者 python -c "print(*range(100))"
请亲手试试以下代码在不同系统下的行为：

python -c "import sys; print(sys.argv)" *

瘦客户机 = 一台运行，多台远程
或者 PXE 定期更新镜像，一般不会这么玩……
或者想办法搞定自动更新（包管理器+定时任务）和远程 home （ Roaming 或者 NFS 挂 /home ）。

@undefine2020 不好意思，文字组织不够清晰，我 #28 分三段
第一段是说明 #27 的问题，其实起诉并不一定要先发律师函，有时为了保证可执行财产甚至会对方不知情的情况下直接请求冻结（参考 TX 和老干妈的事情，实施过程完全符合程序，当时反映出来的问题倒不是这方面）。
第二段是在解释 @efaun #8 为什么会发生且为什么这其中其实没有 #23 所谓「特色」（当然， #8 和 #23 未必有关）。
第三段是在回答 #21，这个问题其实是敌在暗我在明的问题。

See also: <https://jhuo.ca/post/stock_and_image_license/>

我直觉地认为其实贵团队只是遭遇了常规的「软件开发焦油坑」，此概念由 FPB 在《人月神话》中提出。
你可以试试 svn，多半是没有解决。

至于 git，自身确实有些问题，但多半跟你遇到的问题没关系：
0. 各种 workflow 就是在解决 git 本身的问题，其存在本身即可论证 git 有问题；
1. git 是为了分布式开发设计的，每个人各自管理 branch 各自 merge 是 feature ；
2. git 是为了 C 语言设计的，更精确地说，是为了 LBT 的代码格式风格的 C 设计的；
3. 实际上最优情况下每个团队（包括一人团队）应当自己构建自己的版本管理系统，而不是用一个现成的版本管理系统（比如 SQLite 就自己造了一个版本管理系统），但因为时间或成本或能力或安于现状或多种因素融合的问题，大部分团队没能造罢了。