这个配置怎么看都是一种 /r/unixporn 里面折腾 bar 那群人的既视感 ...

我正好搞过这个，需求是给 B 站直播 up 主录回放。方案是在一个 tmux pane 里面起一个循环轮询 B 站 API，检测到状态在直播就再开一个 pane 用 you-get 下载，完后 ffmpeg 转一遍： https://github.com/secondwtq/bmon

用不着 send-keys，直接东西写进一脚本里面 split-pane/new-window/split-window 就行，不然你开的 shell 还得手动关

你这个不是 “C/C++ 的装机历程”，你这个是“巨硬家 C/C++ 的装机历程”
其实你装 Xcode 也是一堆烂事（ XcodeGhost 还记得么），不过只装 Command Line Tools 的话貌似还凑合

“怎么就不能即装即用”
Dev-C++ 就是即装即用的，MSVC 勉强算吧（ MSVC 是安装容易卸载难）。VSCode 是前端编辑器，VSCode + MSVC 的缝合怪没有即装即用的道理。
另外很不幸的是，C/C++ 是大爷，本来就没有“即装即用”的道理（虽然 Dev-C++ 和 Linux 下基本都做到了，但是这是情分，不是本分）。从产品经理的思维考虑，当你的东西需要吸引用户时，你才屑于去做“即装即用”。因此 安卓 App 需要即装即用，还得塞你个红包。MSVC 和 Xcode 这种垄断的第一方专有软件不需要即装即用。C/C++ 这种事实行业标准也不需要即装即用。只有妄图“取代 C/C++”的逆贼才会标榜“即装即用”。

reduce 了半天 case，好像删了 using VariantChoice<Types, Types...>::VariantChoice... 这句就没事了

然后找到了俩 GCC 的 bug report：
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79094

瞎改了下把 GCC 改过了 ...
报错的地方全加个 :: ，变成 ::VariantChoice<Types, Types...> 就行了

假设楼主说的”开发者“是指苹果最喜欢拿出来吹的”靠 App Store 生态走上人生巅峰的独立开发者“。那我倒觉得分成不是什么问题。这种开发者要收费的话得在各市场自建渠道，成本可能不比 30% 低。App Store 把这些工作全都集中起来，算是提高了效率。
（当然你要是去做个匿名调查，问这些开发者 App Store 分成高不高啊？要是能降低一点吼不吼啊？当然大部分人会说”吼啊，当然啦！你问我资瓷不资瓷，我说资瓷，我就明确可以告诉你“，毕竟打个嘴炮又不用负泽任，谁还不想多赚点，信不信就算分一点比如 1.9260817% 这么微小的成也肯定会有人时不时把苹果批判一番）

最近这事问题明显是出在有能力自建渠道的带厂。Steam 看得很透，但是解决方法太简单粗暴了，搞了个分级累进税，卖的越多交税越少，好像确实有点用？但是吃相就更难看了 ... iOS 能闹这么大主要还是库克特首和人民首富通过气了，只许淘系的快递过关，京东物流不让。

还有就是这东西和开源天然不兼容。我不管是给自己用还是给别人用，都得交税。一次性的也就算了（一次性费用我都能接受，就当是手机又涨了一百刀罢），还是订阅的。本来开源就不怎么赚钱，开源协议又赋予用户又有不付费使用开源软件的自由（实际这个自由在 iOS 上并不存在 ...），这个税谁来交呢。

这个不是什么新鲜玩意。
”界面多语言“和”符号多语言“，以及”编程语言多语言“其实可以统一起来。

现在 DCC 工具流行使用节点网络，你把软件汉化了，那些节点也汉化了。这就同时实现了界面、符号和编程语言的多语言。
推而广之，编程语言和库本身也是一种”界面“，可以应用界面多语言的实践。节点网络或可视化的好处在于，因为键盘主要只需要输入一些数字（其实数字一般都是拖出来的 ...），没有输入方面的破事。不过我觉得这是现有实现的不足，可能不是特别大的问题。

这里指的是接口部分，至于实现我倾向于保持简单直接。这里的问题是实现一般只是维护者在折腾，变动又比接口更频繁。折腾的性价比远不如接口高。

X 里面有俩 buffer，一个是 primary，一个是 clipboard （可以自己加但是平常就用这俩），都叫 Selection 。Primary 是你选中了就自动给你复制一份。Clipboard 是你明确执行复制 /粘贴时才会涉及到，就是传统意义上的剪贴板。
xclip 是对 X selection 操作，默认操作的是 primary，你粘贴用的是 clipboard 的数据。可以试试中键行不行。
Shift+Insert 的行为很神秘，我一般不用。

VS 用的少，你说的具体是哪个功能
Mac 对应的应该是 Instruments （其实你用 Xcode 跑就有的 ...），应该是基于 DTrace 的，Sun 的遗产之一。
跨平台的 VTune，不过用 Electron 做了之后就有点蛋疼。对应 AMD 是 uProf，不过没用过。命令行 perf 就不错。
专门的应用可能有专门的工具。最近流行采了数据之后放在 Chrome/Firefox 的 Developer Tools 界面里面看。Firefox 甚至有官方的文档教你干这个。
Linux 最近在搞 BPF，很神奇的一个东西，直接在 kernel 里面放了一个 JIT 编译器。想到 HN 上面看的一句话：

Ah Linux, in which a thread is a process, a semantic patch is a lint rule, and a packet filter is a system profiler.

吉大计算机印象中还行，反正大陆计算机教育能说得上凑合的就三所，拿个学历就业不会有太大问题。转不转得过去就两说了。
再一看回复是想去游戏公司，那建议冷静。

ImageMagick

我感觉你去 B 站去微博都比来这靠谱
来这也就只能找找工具推荐了

一方面是这块内存的内容允不允许被执行的问题
另一方面是这块内存的内容里面有没有对非局部地址的引用

如果有 RIP relative addressing 的话就比较麻烦

文本形式的“代码”仅仅是“程序”的一种编码形式而已。我倒是觉得不应该太局限在单一的编码形式上。

楼主的代码字体居然不是等宽字体 ...（意思是这个选择很有意思，不是说代码一定要用等宽字体（这算是一种 stereotype 了））

另外禁用 JavaScript 之后效果意外的好（特别是图都不会自动载入，which 是摸鱼的时候绝对需要的）

另外无聊的可以揣摩一下我为何要用“臺”一字 ...

其实平臺独占本身也不是不能接受。这里的历史原因是 PC/Steam 等平台并不是天经地义的，现在很多“科技”行业的根子在好多年前已经扎下来了。最早不仅仅是游戏，几乎所有的软件都是针对特定平台开发的，并没有全平台的道理。这个遗留问题其实到现在都没有解决，现在看起来情况好一点只是因为第一，软件开发的工具进步了，第二，开源软件多了，第三，平台碎片化没那么严重了（意思就是其他平台的独占少了，但是 x86 又在一个其他的层面垄断了）。专有软件如果是跑 native 代码的话，依然是只发布到特定平台上，游戏只是因为恰好全是专有软件，又全是 native 代码，所以看上去这种情况非常严重。

这个不仅适用于硬件，也适用于软件。并且不是说技术进步就能解决的。RimWorld 和 Homeworld: Deserts of Kharak 都是 Unity 做的，一个在 Windows/Mac/Linux 上都能跑，一个只能在 Windows/Mac 上跑。这锅能让 Unity 背么。我对主机的最大怨念和 iOS 差不多，还是不能跑自己的代码。主机如果支持编程我首发就买，不支持的话二手白菜价大概都不会买。可惜主机历史上就是“专门拿来玩（部分类型）游戏的”，所谓三神教也就微软沾点边，其他两神并不像苹果谷歌一样要搞什么乱七八糟从小培养码农的项目。


当然游戏玩家作为一个个人消费者群体，版权法是很难有效管辖的。所以对于不合理的独占自然也有其对策。最典型的就是模拟器（哪怕现在 PC 这么强，模拟器效果还是不好 ...），GDC 上就有人去讲自己是怎么把倒卖用模拟器跑的老主机游戏做成一门生意的。对于 Epic 这个独占理论上也好说，独占的时候想玩就玩石皮解，之后别的渠道有了再补票就是了（最好等打折买 ...）。当然我 Steam 上不缺游戏玩，所以现在游戏石皮解效果怎么样我就不清楚了。

这些行为算不算垄断我不了解不好评价，不过就实际效果来说，我觉得现在对于“垄断”的定义是有问题的 ...