@james122333 #111 我只是想说 TUI 本质上和 GUI 就是一个东西。功能上，使用逻辑上，都类似，只因一个用 ncurses 生成窗口、菜单、状态栏，处理键盘鼠标事件，而另一个用 GTK/QT/Win32API 生成窗口、菜单、状态栏，处理键盘鼠标事件，而莫名其妙弄出一种鄙视链来。

PVE 不适合放这种存储。ESXi 可以的，我记得需要把日志搬到主硬盘上。
不过说实话意义不大，不如直接 ESXi 装在硬盘上，也不占多少空间。

@ShikiSuen #11 这边建议改改环境变量 GIT_AUTHOR_DATE GIT_COMMITTER_DATE 直接平移日期。
开虚拟机改系统日期太麻烦了。

「命令行」工具与「图形化」工具对比：
https://i.imgur.com/Hxnm7Wh.jpg

@kiwi95 tmux 本来就可以算一个图形化的工具。
我在几年前的讨论里就说过了，很多人魔怔地反对 GUI ，但却自己用着和 GUI 差不多的东西，比如 tig ，比如 vim/emacs ，比如 tmux 。所以我上面说了，真当字符画出来的窗口不算窗口啊。

至于「 cli 用不明白就觉得 cli 做不了吗」我可没有这么说过哦？你是不是有点魔怔为了反对而替我发表观点了？
我自始至终说的都是 GUI 在做很多操作的时候可以省下时间，我什么时候说过 CLI 做不了了？特别是我第一句话就是 GUI 下层还是会调用命令行，你都选择性不看的是吗。

抛开事实不谈，你说得还挺好的。

@LonnyWong VIM 就是一个图形界面的编辑器啊？
能用鼠标能用上下左右光标，主窗口区是所见即所得的内容面板，最下面还有状态栏，这不叫图形界面？
我认为只有 sed 之类的才配叫命令行工具。

至于 git add -p ，这东西不太好做太细的局部 stage 。他最小单位是代码块，遇到比代码块更小的操作单位你怎么办？比如说你加了两行，一行 call func1 一行 call func2 ，现在要把 func1 和 func2 放在两个提交里做。当然你可以用 e 选项手动编辑，但这你还要和 GUI 比性能么。

而且 GUI 里是 3-way merge ，编辑任何一个代码块都能看到 HEAD 和 stage 和 working dir 三份代码。你不会说 diff 比 3-way 更直观更不容易出错吧……

学 C++是要学到什么程度？上模板吗？学 Intrinsics 汇编吗？多线程和异步？
学 C++的目的是什么你得先搞清楚。

提醒一个现在的 MX500 和以前的 MX500 已经不太一样了。
以前 MX500 可以无脑买，稳得一批，现在 MX500 翻车的不少。

@troywinter GUI 下层还是会调用命令行，但是 GUI 会把常用的复杂操作自动化。你可以把 GUI 等效看做一个 CLI 的半自动化脚本。

我举个例子，把一个分支下的提交 rebase 到另一个 tag 下并做 3-way 冲突处理。这个过程不管用 GUI 还是用 CLI 都必须手动做，完全不会享受到命令行批量处理的好处，而 GUI 下只要点点鼠标就可以从不同的分支里选出不同的代码行。用 CLI 你最后不还要打开 VIM 这个图形界面工具。

所以光这个操作就省下 GUI 用户大量的时间，而这个操作又正好是大流量开源软件和 modder 必须要用到的。

还有一个操作，是局部 stage ，可以把一个修改过的文件中的少部分行 stage ，剩下的留在 working dir 里，又或者是像做 3-way 合并一样选择性地把一些行或者一些字 revert 。你用命令行当然也可以这么做，先把文件复制出来备份，然后把部分行改回去，然后 add 提交，再把备份文件移动回来。

-----

当人们对这些操作没有需求的时候，总会觉得命令行效率高。等没法满足的时候，再去写一下半自动化脚本，重新实现一些 GUI 已经实现的功能，然后再把 GUI 批判一番。就，很没有意思的争论。类似的争论我好几年前就在隔壁 ruby-china 论坛参与过了，一堆坚持不用 GUI 但照样用着命令行版 GUI 的人在跟我争。真当字符画出来的窗口不算窗口啊。

@sun4076 我用 dailyroads 录的。录完可得一个 mp4 一个 srt 字幕文件。字幕文件是按秒记录经纬度之类的信息。

啊？我行车记录仪就是手机安卓 app 。
录完以后还有包含时间，车速，经纬度坐标的字幕文件。配合视频一起跑一下不就什么都有了。

HDMI 跑 4K144 8BPC 需要跑到 40G 带宽，最少也要 HDMI 2.1 。
DP 跑需要 UHBR 10 的 39G 带宽，最少也要 DP 2.0 。
你 HDMI 2.0 就只能跑到 2560x1440 144 或者 3440x1440 120 。你如果输出 2560x1440 144 然后让显示器做 upscale ，理论上是可行的，但是画面可能会一点点糊。

用着 Vivaldi ，毕竟是纯正的 Opera 血统。

我做开源基本都是纯粹抛砖引玉。我起个头，实现从 0 到 1 ，满足我自己的要求。接下来如果你想要改进或者要加功能，自己 fork 出去，提 PR ，又或者你觉得你有能力维护的，我把我的项目 archive 然后指向你的 fork 。

16G 内存也只不过是少吃点虚拟内存罢了。
比如像我现在开了浏览器和各种常用软件，吃了 35G 内存。你配 8G 就是开 27G 虚拟内存。配 16G 就是开 19G 虚拟内存。我觉得好像倒也不是差得很多。

不过你这个 2019 年花 3100 买 8G 内存的本，真的谈不上性价比。3300 16G 性价比倒是就上来了。如果能 3600 32G 那性价比才叫爆表，还能再战好几年。8G 内存的本就是给轻度使用用户的。

（不在国内）
Costco 买的冷冻养殖三文鱼，想吃了就解冻出来自己切一下吃。

淡水养殖如果对水质饲料都控制好的话应该问题不大。
实在不放心就真空抽好丢进冷冻里放一个月再吃呗。

@Donahue 计算密集型项目会大量用到汇编指令集。用 C 然后让编译器去优化，那就不知道慢到哪里去了。
你有兴趣的话可以试试看跑 x265 ，用--no-asm 路径跑（纯 C+编译器优化），看看比 AVX2 要慢多少。

如果只是跑跑 php python 之类的，不追求性能的，那当然怎么搞都无所谓了。但是企业环境下对指令集的依赖是很大的。适配 NEON 是硬性成本，不适配就是性能狂掉。

别的我先不说，就说这项目是「 Apache License 」与「软件仅供个人学习与交流使用，严禁用于商业以及不良用途。如有发现任何商业行为以及不良用途，软件作者有权撤销使用权。」双许可证吗？