@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 相关的属性，之后的布局问题，窗口管理器应该会自动处理。

苹果变质了
苹果失去了灵魂

@fiveelementgid 你取得有关部门许可了吗？你背后是谁，发这些想干什么？你想颠覆什么、破坏什么？

https://i.loli.net/2021/02/04/94hQRUBHKbsXVra.png

@echo1937 其实要真是新 ISA，还得折腾 gcc, glibc, kernel 一套全家桶……
然后人家 ARM 能跑 Windows，你不行

第三，你有本事做 ISA，你有本事做 uArch，你有本事做 Rosetta 么？

第二，uArch 也不是你想的这么简单的事情。
高通在十年前是自己的微架构，但是被 64 位的 A7 偷袭了，来不及搞新架构，就公版架构套了一个出来，你猜那代产品叫啥？就是大名鼎鼎的骁龙 810
后来 820 又整出了个新架构，但是表现一般，再往后就接着用公版了
三星的自研架构前段时间刚黄。就算在的时候，貌似也是骁龙版比猎户座版更好，你猜是为啥……
海思也是小改公版
联发科更逗，公版做的都不算太好
你想想为啥手机处理器除了苹果之外没人做 uArch

第一，ISA 不是你想的这么简单的事情
你可以去了解下最近的新星 RISC-V，然后思考下，为啥这么多资源投在里面，这东西进展还是这么慢
其实 WebAssembly，以及很多标准化的东西都是类似的道理

xmonad 其实有做 window decoration 的插件…… 不过貌似是单独创建的窗口
还有个鼠标拖动交换窗口的插件，再加个 bar 的插件切换 workspace，就可以脱离键盘使用了……

多线程写入，结果就是写入的数据不可靠，不是直接给你报错。
只有你再使用写入的数据时才会把问题暴露出来，而在实际程序中很难知道是谁什么时候写入的数据，这是并发错误难调试的原因之一，报错的点不一定是 data race 发生的点。

有时候也会故意这么做，性能会好一些，

@agagega 很不幸"基于正则的语法高亮"在我这也是要淘汰的 ...

我举两个类似的例子：

引用 https://v2ex.com/t/612874#r_8089400 这里面的：
> LLVM 一开始用了以 camelcase 为主的命名方案，具体来说是类型名，变量名（包括局部变量和成员变量），用 UpperCamelCase，函数名是 lowerCamelCase 。
> 但是后来发现一个问题，比如我有一个变量的类型是 MemorySSAUpdater，那么按照命名规范，我不能把它命名成 MemorySSAUpdater，因为会和类型名冲突，现在的解决方案是取首字母 acronym 命名成 MSSAU 。这种情况在整个仓库里十分广泛： https://github.com/llvm/llvm-project/blob/734c74ba14be0f4421ccd9f720e5b9309248e0f7/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp#L709 感受一下
> 但是这种命名多了就会十分奇怪，看代码必须先要熟悉这些奇怪的缩写才能看得下去

> 于是现在有个 proposal 就是把变量命名从 UpperCamelCase 变成 lowerCamelCase，这样我就直接命名成 memorySSAUpdater 就行了： https://llvm.org/docs/Proposals/VariableNames.html

当时这个事在邮件列表里面吵了半天 ...

同一帖子上一楼提到，一些函数式编程语言强制要求某些结构使用特定的命名规范，比如在 OCaml 中，constructor 和 module 的名称必须以大写开头，而 Haskell 中类型和 constructor 必须以大写开头。刚开始学的时候感觉有点奇怪不过没太在意，后来也就习惯了。
但是后来我自己写语言抄 OCaml 的时候就发现问题了，通过这种语言设计上的小动作，编译器实际省下了很多工作——正则一匹配就知道这个标识符到底是个值还是个 module，同样是命名空间的访问，value.field 肯定是访问一个 record 中的值，Module.value 肯定是访问模块中的值，Module.Submodule.value.field 肯定是嵌套模块访问 + record 访问。
而类似的问题在 C++ 中的解决方案是引入两种语法结构： "::" 用于静态命名空间的访问，"." 用于实例命名空间的访问。
现在我自己要解决这个问题，要么抄 OCaml 的，把命名规范搞得不像个“正常语言”，要么学 C++ 的，多占几个符号，多加几条规则，还有一种方法是我 parser 开洞，不通过任何语法层级的东西来 disambiguate，不过那样 parser 跟 C++ 的就差不多屎了。
现在我已经放弃在文本层面解决这个问题了 ...

@Mithril 哪个蠢驴
是瑞典的那个么，那个主要应该是祖宗之法不可变的问题
还是波兰的那个，那个主要应该是管理的问题
这种优化手段应该对这种大量重复元素的场景是比较适合的，其他的效果不一定好，期待后续文章。

另外还有一个思路是分流，因为一般意义上的“群”从概念上来说是一群人围绕某个主题集合在一起（这种事情貌似是要有关部门批准的？），但是由于群不是职业性的，所以一般”人”要比”主题”更突出。到最后就变成二选一，要么人要么主题，但是人明显是最根本的，所以选择“主题”的，一般我们称为”死了”。
Discord 在这方面做得就不错，Discord 中的群是”人+弱主题”，在群中再细分”频道”(貌似是这么叫的)，也就是强主题，但是同一个群中的频道共享一群人。一般 IM 是群=>聊天窗口二级 UI，Discord 是群=>频道=>聊天窗口三级。比如搞一个 V2EX 群，就可以有 C++频道，Java 频道，找工作频道 etc. 这样缺点是频道多了之后一个个关注会比较费劲，但是几乎所有群都会有一个”offtopic”频道。这样吹水也不误，正事也不误。存人失地，人地皆存。
（频道多的自然解决方法也很简单，就是搞一个聚合频道，然后你会发现这特么不就是 V2EX 的 IM 版么……）

如果你想做到”干货比例大概在 70%以上”，同时还想有人说话的话，至少有两种方式：第一是做梦，第二是研究时间机器——总之就是想办法穿越到另外一个世界去
如果想做到干货比例 60%以上的话，在本世界线倒是可能的——从把每一个撤回消息的人禁言一天开始