看到楼主的 append，来联动一下隔壁 https://v2ex.com/t/643161

我小时候家里订了 2004 年到 07 年的电脑爱好者。当时这个杂志有个论坛，人还不算少，我没事就上去水水（跟 V 站似的），里面有个编程区，没事讨论些 Win32 编程之类的东西。现在看起来平均年龄和 V 站也差不多。
我当时只会 VB6，于是只能喊 666。有次问了个也不知道什么问题（好像是类似“怎么学编程”之类的），被人问了“你不是科班出身的？”，我当时还不知道“科班”是啥意思 ...

楼主链的这个博主 KingsamChen，当时好像是这个区的版主。
后来过了几年，论坛这个东西彻底过气了，再去看原来的站已经没了。没想到人还能找到。

这东西本质上是个 integration 问题

第一方和第三方都是同一个东西的不同实现，其实没有本质区别。“第一方比第三方要好”这个 assumption 直接就是错的。

值得一提的区别仅仅有两点：
第一：第一方唯一的优势在 vertical integration 方面。integration 就是我有什么东西，我就加进去，离我近的东西就 integrate 得好一些，离我远的东西就做得差一些或者不做。比如各家手机都会装一套出厂 App，很多出厂 App 是硬件厂商自己做的。vertical integration 就是同一个实体控制的东西 integrate 在一起，原则上效果会更好，比如 Google 和 Apple 的出厂 app 和他们自家手机更配，因为 OS 和硬件都是他们自家的。Pixel 和 Surface 在 vertical integration 方面比第三方方案要好。这方面的极端例子是 Apple。

但是如果大家把自己的东西都 integrate 进来，那最后产品不仅会继承好的东西，还会有坏的东西。比如微博和知乎的官方 App 都 integrate 了它们的广告业务，而 Chrome 也不可避免的 integrate 了 Google 的账户、数据收集和强奸用户的传统。

第二：By definition，第一方只有一个，第三方可以有无穷多个，第三方之间的竞争远比第一方要激烈。

而第一方除了 vertical integration 方面的优势之外，并不保证有其他方面的优势。第一方在非 vertical integration 方面的水平一般只是该第一方的平均水平，术业有专攻，很有可能被市场上其他选手超越。例如：

* 某些第三方有自己独特的优势，比如 Chrome 等 evergreen browser 在 IE11 之前相对于 IE 有速度更快、功能和扩展性更丰富、标准支持更及时的优势，最近本站讨论很多的笔记软件也是百花(shi)齐放，而不是都去用 Apple Note 或 OneNote，因为各家都有自己的特色，vertical integration 反而不是那么重要。
* 某些第三方有强大的自家产品同样可以做到优秀的 vertical integration （比如米家生态和小米手机更配，Office 和 Mac 显然 integrate 的并不好但是依然很多人用，Windows 上某些开发者不用 cmd/PowerShell 而使用 UNIX 的 CLI，而 UNIX 上某些开发者不用 Java 和 PHP 用 .Net Core ）。
* 甚至 vertical integration 也不一定是优势——某些是优势，而某些同样可以是劣势。比如上面提到的广告（并不是“第三方没有广告”，而是“你钦定的那个第三方没有广告”）。

楼主的观察更准确的说应该是“发现 vertical integration 并没有绝对的优势”。

因为 personal computing 更倾向于这种“易学易用”的傻逼方案，所以这类问题在 personal computing 上尤其突出。很多 personal computing 上很明显的问题都是同一性质的。

拿 Pixel 举例子是不知道 Nexus ？

1. 一般改配置就可以直接修改高度
2. 你想要的是 panel 不要显示 Task Bar，还是要做成 Mac/Ubuntu 里面 Menu Bar 的效果（ Ubuntu 之前有和 Mac 差不多的 Menu Bar，但是后来好像没了，和 GNOME 统一了，应该是和 Unity 有关）？前者可以想办法把 Task Bar 这个组件删掉（配置里删掉，如果不行的话代码里删掉），这样就能做到“一个打开的应用同时显示在 dock 和 bar 里面”。
后者稍微麻烦一点，需要类似 #2 的东西，但是这个东西在 Linux 下并不完美（应该也是和 Unity 退潮有关）。

当然我会考虑你把 Task Bar 干掉之后用什么来填充这个空间（绝大多数情况下 Menu Bar 不能完全填满 1366 以上宽度的显示器，#2 那个 GNOME 截图到处都是反生产力的设计，还填不满 1920 屏幕的一半）。可以不填充就留着空白，但是对于我来说这是空间的浪费。如果是 /r/unixporn 的话，可能会考虑显示个网速，音乐播放控制之类的。
哦，我的选择是不用 Dock，因为 Dock 也是反生产力的（尤其在“同一应用的多个实例同时存在”的情况下）。把 Menu Bar，Task Bar 和 Status Bar 放到一起，最大限度节省空间。

3. Workspace Switcher 以文本方式显示，在 tiling 向的 panel 里面比较多见。原因可能是此类 panel 避免了一般客户端软件“把用户当傻逼”的设计思路（但是依然无法避免固有思维的影响，比如绝大多数此类 panel 也并没有啥图形能力）。而在主流偏向于“把用户当傻逼”的软件中做到可能比较难。我没用过 Cinnamon，楼主可能要做好改源码的准备（ https://old.reddit.com/r/gnome/comments/a6hjdp/display_workspace_names，对应到 Cinnamon 好像应该是 https://github.com/linuxmint/cinnamon/blob/8fbdd45740e09448f266a567f32037d2497f4752/files/usr/share/cinnamon/applets/workspace-switcher%40cinnamon.org/applet.js#L223 ）。

有趣的是，在非 tiling WM 的 panel 中更流行的好像是 graph 形式的显示，比如这个 fvwm 的截图（ http://www.xwinman.org/screenshots/fvwm2-taviso.png ，http://www.xwinman.org/screenshots/fvwm2-karl.jpg ），Cinnamon 和 xfce 也有类似功能。但是好像很少有把两者结合的（上面说了，tiling WM 用的 panel 基本没有图形能力），虽然我用 tiling WM，但是和 tiling WM 的典型目标用户不同，我目前没有给 workspace 设定特定的用途，因此 graph 对我更有用。

@KentY 这个其实不能叫“美化”，因为直接和交互逻辑相关，不是纯样式的东西。

说起来，今年又是 Linux 桌面元年呢

理论上，这些死宅用的东西在这时候应该是涨价的

你问对时候了，新鲜出炉的： http://www.yinwang.org/blog-cn/2020/02/05/how-to-read-code

Org 有个硬伤文章里面好像没提：只能 PC 用

当然这个并不是绝对的，比如 WebKit 这种项目分成 WTF、WebCore、JavaScriptCore、WebKit 等很多子项目，子项目之间依赖非常紧密（假设把这些项目单独分成几个 repo 的话，某开发者放假回来忘记 pull 其中一个项目，就可能 build 不过），一个 CMake 全都 add_subdirectory 进来就得了。

但是 WebKit 用了 sqlite，这个就用系统的就行。

没用过 Travis CI，但是 CMake 没见过 FetchContent 用得多的。一般 CMake 是假设你系统（或者你的配置里）已经有了现成的依赖，然后再去 find。CMake 是个 build system，不是 package manager。

感觉楼主需要做的是把依赖从 CMake 的 build 中剥离出来单独 build，这样就可以满足“在一个独立的目录中”的条件了。

我倾向于避免把依赖都放在一起 build，因为我用这类工具的经验是如果用得频繁，它们（大多数）都会日常抽风，抽风的最简单解法就是删掉所有 cache 重来，这样我就必须最小化每次 full build 的时间。

亲你好可以的，只是需要多用两年才能解锁哦

一般课程应该不会讲到 Monad Transformer 以后

老实用 Promise 不好么……

@lzwt806 你直接搜 gelf.h 呗，应该是 libelf 的

如果你主要是偏展示和交互而不是复杂 geometry 的编辑的话，游戏引擎应该会更适合

大多数 DCC 都是给你一个现成的应用，然后你想办法 integrate 进你的 workflow。游戏引擎灵活得多

@matafu 这不是一个算法么怎么画 …

该不会你要把软件 script 成你想要的样子吧

@lzwt806 你是 4.0.0 啊 … 那就不知道了，现在早就 CMake 一把梭了，除了 CMake 没别的依赖。
另外 LLVM 本身不直接依赖任何驱动。
“—enable-llvm is required when building r300”是说你编译 mesa 的时候要把 —enable-llvm 这个 flag 加进去。r300 和 r600 应该是不同的驱动

llvm-config 是 LLVM 的编译产物之一，属于 LLVM 库，不是单独下载的。单独的 llvm-config 没有意义

楼主到底要画啥？