卷不卷不知道，反正我现在首页 49 个贴子，算上楼主这个有仨 Java 的

@MiracleKagari 前两天的新闻，高通完成对 NUVIA 的收购，之后可能会出笔记本的芯片
说起来 NUVIA 这公司本来是 Apple 芯片团队的人为了做服务器来出来搞的（ Apple 不搞服务器），结果一圈下来还是去做了 client ...

VS 能不能把里面那个 main.cpp 在工程里面无视掉 ... 貌似有个叫“Exclude from Project”的功能？
其实一般来讲直接引入 C++ 项目的都是库，不会编译出可执行文件，有的项目既会编译出库也会编译出可执行文件，这种项目一般已经使用了 CMake 之类的工具管理 build 过程

感觉像是 push 和 poll 的区别
说起来最近 ECS 好像 hype 蛮多，楼主怎么看 ECS 和事件之间的关系？

从主题内容来看，楼主看来说的不是马克思的“生产力”（ force of production ）而是 tech 里的“生产力”（ productivity ）
这么说吧，tech 里的“productivity”自身产生的多义性，是和计算机的广泛应用相关的，各行各业都要用到计算机，而各行各业的具体“生产力”是不一样的。就像楼主提到的，做视频的和做设计的“生产力”是不一样的。才会出现该主题这样的问题。
各行各业内部可以继续细分，写程序的至少语言不一样。做炼丹的有人拿游戏卡炼丹有人拿超算炼丹，做视频的有的做游戏视频有的做三次元现充 vlog
还可以继续细分，每个公司每个部门的具体环境都不一样 ...
tech 里的“生产力”这个词，其实就是试图用有限的 bit，概括不可穷举的具体情况的无谓尝试

既然人类个个都是傻 x，那么人类存在的意义在哪？

我对（我认为的）楼主对所谓“伪开源”的理解有不同意见。
在一般语境里，“开源软件”广义上指一种软件的属性，即软件的源代码可以自由地被查看、使用、修改和共享等。只要符合这一特点就是开源。狭义上指一种新兴的软件开发流程，即软件不再在企业内部黑箱开发，而是通过全球化、公开化和大众化的的协作开发。很多开源软件（如楼主所说的“用户量不大”的一些软件）套这个狭义的定义的话，是不算“开源软件”的。

单纯讨论“开源软件”的话，和是不是“为了钱”是没有关系的。只有讨论到“自由软件”之类的词的时候，才具有更重的政治和意识形态色彩。而即使是“自由软件”，是不是为了钱也没有什么关系（ RMS 自己钦定的规矩）。

@pkookp8 理论上是这样，但是实际做起来不仅要在多个平台上编译，还要在多个平台上测试。
这样就必然会有多个平台的环境。

然后“来都来了”，测试平台都有了，再弄个编译平台也不多。

@murmur #46 你觉得会让你玩小黄油么 :)
这其实也是我不喜欢云游戏的最大原因，貌似很多厂家按照主机的套路来搞云游戏，搞得一点意思都没有。

这么说吧，这个所谓的“thread”，概念上并不是“操作系统”实现的，而是由语言规范定义的，语言规范可以用“thread”这个名字指代与操作系统线程完全不同的抽象（比如 CUDA 也有“thread”这种东西 ...），操作系统或者语言的 RTS 仅仅是个实现细节。

而“thread local”同样也是语言规范定义的抽象，同样和操作系统线程没有直接关系。

我本来应该说一句“这个回复假设问题里的‘thread’和‘thread local’指编程语言或其标准库提供的设施”，但我发现没法说，因为这个问题的存在就已经说明楼主已经把编程语言的抽象和操作系统的抽象搞混了。这是两个不同的命名空间，混用不同命名空间中的概念，就可能出现楼主担心的问题。

而“thread local”之所以叫这个名字，他就应该是对应（同一个命名空间里的）“thread”概念的。所以一个正常的编程语言里面，“thread local”配合“thread”使用是没有问题的。如果这么做不安全，你可以给设计者发个 Email，问他“你也喜欢肖战吗？”

不知道你想要的到底是啥。
看起来是想要个 trace，Intel SDE 有个 trace 功能，虽然貌似不是开源的

这咋能是无要点呢 ... 大多数人们习以为常的东西都不是天经地义的，都是有历史和原因的，而研究这些历史和原因，本来就是一个 discipline 。我发一个问题 世界上有哪些现存书写系统不是从腓尼基字母衍生的 是不是也是无要点？有时间质疑这种问题的意义，不如研究一下挖矿如何加速了全球变暖进程

目前资料对于这两者的起源并不是特别清楚，不过 backslash 应该是从 slash derive 过来的，比 slash 应该要晚得多。
至于 slash 是怎么来的就更不清楚了，我个人猜测 slash 应该是从 | 竖线变来的，竖线用斜体，就是斜杠了，一般拉丁字母斜体字（手写体字）就是这个方向的。

@ClassicOldSong
#44 他的意思是虽然很多人“平庸”，但是：
a. 你不能强迫人家来舔你
b. “平庸”的人确实占大多数
这样的现实决定了你的东西要真想有人用，那就得是你去舔“平庸”的人，而不是“平庸”的人来舔你。也就是“平庸”确实有理。

阿拉里克洗劫罗马，旭烈兀洗劫巴格达的时候，城里的人大概也是“你野蛮你还有理了”这样的想法吧。不过他们怎么想都无所谓了，反正当时人直接就没了。
要想在现实中胜利就得承认现实并面对现实，或者就像 #42 说的一样精神胜利。你开公司你应该懂，不需要发这个贴子。

前两天刚处理了类似的问题，Linux 下打 mod 玩文明 6，有些 mod 就是没办法跑，开始还以为是 mod 没兼容新 patch，结果发现是文件名大小写问题，需要给 mod 文件创建一堆全小写的 symlink ...

一般确实是在窗口管理器里做。

比如我用的是 xmonad，这是 Haskell 写的一个非常 primitive 的窗口管理器，稍微熟悉 Haskell 的话，一下午就可以看完核心部分的代码（而如果你想学 Haskell，xmonad 又是非常不错的入门项目）。它本身功能很少，但是非常的简单和稳定。它的特点是完全的 hackable——核心代码只提供很少的功能，而配置文件由用户用 Haskell 自己写，这个配置文件也并非通常意义上的“配置”——它就是一个 Haskell 程序，而窗口管理器的 main 函数，是在这个配置文件里面的！

比如说这是我的 xmonad 配置文件中的 main 函数：

> main = do
> xmonad $ ewmh $ defaultConfig {
> workspaces = ["pri", "2", "3", "4", "misc"],
> modMask = mod4Mask,
> terminal = "xfce4-terminal",
> normalBorderColor = "#000000",
> focusedBorderColor = "#e63312",
> focusFollowsMouse = False,
> clickJustFocuses = False,
> borderWidth = 0,
> layoutHook =
> logModifier (gaps [(U, 32)] (
> windowSwitcherDecorationWithButtons shrinkText decorationTheme
> (
> smartBorders (spacingRaw True (Border 0 0 0 0) False (Border 0 0 0 0) False (
> draggingVisualizer (
> boringWindows (
> maximizeWithPadding 0 (
> minimize (
> layoutHook defaultConfig))))))))),
> manageHook = myManageHook,
> handleEventHook = handleEventHook def <+>
> -- fullscreenEventHook <+>
> fullscreenEventHook2 <+>
> minimizeEventHook,
> -- testEventHook,
> keys = myKeys
> }

这里面需要注意的是几个 hook，比如 layoutHook 中，minimize 和 maximizeWithPadding 负责最小化和最大化功能，boringWindows 可以在切换窗口时无视掉最小化的窗口，draggingVisualizer 和 windowSwitcherDecorationWithButtons 添加了窗口拖动和标题栏等 stacking WM 的功能，smartBorders 可以在窗口最大化时禁用边框的绘制（当然我现在把边框整个禁用了）——这些都是 Haskell 函数，而这些函数一个个嵌套组合起来传进 layoutHook 这个配置项，再调用 xmonad 提供的 xmonad 函数，就是 main 函数。
layoutHook 中的这些函数不属于 xmonad 核心，而是外部插件，比如这里的 windowSwitcherDecorationWithButtons 我用的是我自己在官方仓库提供的插件的基础上修改过的版本，改出了这么一个标题栏： https://i.loli.net/2021/02/10/aUAFmL7DJOHd54C.png

注意 Chrome 和 Emacs 的标题栏使用的是不同的背景和字体颜色，实现这个区别的代码就在上面的 Emacs 窗口里。

... 但是本回复的目的并非安利 yet another window manager 。说上面这一大堆只是因为貌似推荐 WM 是本贴的标准格式而已 ... 上面 layoutHook 有一个没提就是 gaps，这个可以禁止 xmonad 使用屏幕边框的区域，比如我这个配置中就保留了屏幕上方 32 像素高的位置放状态栏——这是我看到楼主的问题时的本能反应。但是仔细想来，其他窗口管理器也能处理各种 bar 和 dock 的占位，而它们 99% 没有 xmonad 这么强的定制性，这是什么原理呢？
Gaps 模块的文档（ https://hackage.haskell.org/package/xmonad-contrib-0.16/docs/XMonad-Layout-Gaps.html ）给出了线索：Gaps 仅仅是一个 workaround，处理“dock-type applications”的占位推荐使用 ManageDocks 提供的功能，这是因为这类窗口一般都设置了“STRUTS”属性。

xmonad 这个名字中的 X 来自于 X Window，X Window 本身是应用和系统之间通信的一套协议（至于 Monad 嘛，自然是“a monoid in the category of endofunctors”咯）。其中规定窗口和窗口管理器之间通信的主要是 ICCCM (Inter-Client Communication Conventions Manual, https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html ) 和 EWMH (Extended Window Manager Hints, https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html )，这个 STRUTS，以及“dock-type applications”，属于 EWMH 的范畴。
xmonad 的 ManageDocks 模块就是通过检查 EWMH 规定的这些属性来实现保留 dock 空间功能的： https://hackage.haskell.org/package/xmonad-contrib-0.16/docs/src/XMonad.Hooks.ManageDocks.html
类似的处理也出现在 Cinnamon 的默认窗口管理器 muffin 中： https://github.com/linuxmint/muffin/blob/46b555c27a9abf6b4a05f711770786bf4f6a2361/src/core/constraints.c#L863

所以楼主这个问题，可以考虑的标准解决方案是想办法给任务栏窗口设置 EWMH 相关的属性，之后的布局问题，窗口管理器应该会自动处理。