macOS 上的坑和一些 tips

凉凉

如何压榨远程服务器

ssh:

最简单的用法: ssh user@ADDR
可以在远程服务器添加自己电脑的公钥来无密码登陆: ssh-copy-id user@ADDR

可以在 ~/.ssh/config 中写入信息来实现快速一键登录:

Host <一个名字>
  HostName <ADDR>
  User <user>

这样就可以做到 ssh <一个名字> 这样的方式快速登录, 配合无密码登陆食用极佳 (更多的设置可以去查 ssh config 的关键词.

screen: 远程服务器装一个这个, 用来防止跑那种大的程序因为抽象校园网断连而导致的被迫中断 (当然, 以 job 的形式提交作业也不是不行, 但是类似于 Jupyter, Lisp REPL 这种就不太方便用 job, daemon 的话不会用)
- screen -S <一个名字>: 用 <一个名字> 来打开一个终端 (大概这么理解就行)
- 然后提交上/运行一些程序
- Ctrl-a d 快捷键让 screen 的终端在后台运行
- screen -ls 可以列出后台的 screen
- screen -r <一个名字> 切回到名字对应的 screen.
tmux: screen 的一个平替 ( 冻猫 ), 可以参考 A Quick and Easy Guide to Tmux. 或者问 GPT.
top: 来看看压榨得足不足够
- load average: xxx, xxx, xxx 分别对应 1/5/15 分钟的负载, 如果太小的话建议调高你的程序的吃负载能力, (否则不是很亏嘛)
- top 可以用 glances 替代, 虽然好看, 但是可能会稍微多吃点内存.

冻猫

凉凉 screen的一个平替：tmux
据说优化了screen的一些不便之处，不过仅对于我单纯的用法来说，两者应该没什么区别

邱瑟夫

凉凉借楼安利 Rime 鼠须管输入法

凉凉

中文输入法

貌似 mac 的中文输入法有一个 bug 就是会在超长时间运行之后开始把电脑卡死. 具体表现就是在你使用中文输入法时电脑响应迟缓, 切换窗口聚焦会卡很久 (如果你有幸能打开进程监视器的话, 并且用中文输入法试试, 可以看到 CPU 占用上有脉冲函数 ~~bushi~~), 但是可以通过切回英文输入法来暂时性避免卡死 (虽然切回中文输入法就会继续开始卡机).

一个解决方案: 杀

解决方法就是打开终端然后把 SCIM 进程 (中文输入法进程) 给干掉: (切到英文输入法)

> pgrep SCIM
90616
> kill -9 `pgrep SCIM`
> pgrep SCIM
> pgrep SCIM
3390

命令解释:

第一个先看看 SCIM 的进程号 (这里是 90616)
第二个是干掉 SCIM 进程 (你也可以输入 kill -9 90616)
第三个和第四个是确认 SCIM 进程被干掉了 (第三个没有返回, 因为进程死掉了); 以及第四个是切换回中文输入法后 SCIM 自动重启会得到一个新的进程号

另一个解决方案: 换

换掉原生的输入法, 使用 RIME 鼠须管输入法. ( 邱瑟夫 )

注: 在 Emacs 中可以通过编译 librime 并以动态库的方式载入 (见 DogLooksGood/emacs-rime:INSTALLATION.org).

好处是 RIME 的配置是可以通过 Github 进行同步的, 这样你的不同电脑/系统的词库也都可以无缝衔接 (只需要 git pull 或者 git push). 坏处是需要自己了解一下如何配置, 好消息是有现成的配置可以照抄 (如 iDvel/rime-ice 等等).

加一个 Squirrel 的皮肤配置, 之前一直因为默认的皮肤实在是太丑了所以没有用:

亮色效果如下:

Image description

暗色效果如下:

Image description

配置皮肤可以用 Squirrel Designer, 然后选择颜色的时候利用 Apple Developer 的色彩, 这样可以方便做亮色和暗色主题 (虽然没什么鸟用).

patch:
  style/color_scheme: ryo_light
  style/color_scheme_dark: ryo_dark

  preset_color_schemes:
    ryo_light:
      name: "ryo_light"
      author: "凉凉"
      
      font_face: "Unifont"
      font_point: 16.0
      label_font_face: "Unifont"
      label_font_point: 12.0
      comment_font_face: "Unifont"
      comment_font_point: 14.0
      
      candidate_list_layout: linear
      text_orientation: horizontal
      inline_preedit: true
      
      translucency: true
      alpha: 0.9
      
      corner_radius: 4.0
      hilited_corner_radius: 2.0
      border_height: 2.0
      border_width: 2.0
      line_spacing: 4.0
      
      shadow_size: 0.5
      color_space: srgb
      
      back_color: 0x02FFFFFF
      candidate_text_color: 0x1E1E1E
      comment_text_color: 0x8CFFFFFF
      label_color: 0xD8FFFFFF
      hilited_candidate_back_color: 0x7FFFA91A
      hilited_candidate_text_color: 0xFFFFFF
      hilited_comment_text_color: 0x1A1A1A
      hilited_candidate_label_color: 0x8CFFFFFF
      text_color: 0x0CFFFFFF
      hilited_text_color: 0xD8FFFFFF
            
    ryo_dark:
      name: "ryo_dark"
      author: "凉凉"
      
      font_face: "Unifont"
      font_point: 16.0
      label_font_face: "Unifont"
      label_font_point: 12.0
      comment_font_face: "Unifont"
      comment_font_point: 14.0
      
      candidate_list_layout: linear
      text_orientation: horizontal
      inline_preedit: true
      
      translucency: true
      alpha: 0.9
      
      corner_radius: 4.0
      hilited_corner_radius: 2.0
      border_height: 2.0
      border_width: 2.0
      line_spacing: 4.0
      shadow_size: 0.5
      
      color_space: display_p3
      
      back_color: 0x19FFFFFF
      candidate_text_color: 0xD8FFFFFF
      comment_text_color: 0x3FFFFFFF
      label_color: 0x8CFFFFFF
      hilited_candidate_back_color: 0x7FF8A74F
      hilited_candidate_text_color: 0xFFFFFF
      hilited_candidate_label_color: 0xD4FCE1BC
      text_color: 0xD8FFFFFF
      hilited_text_color: 0xD8FFFFFF

凉凉

macOS 上的 GUI 进程 (一些没什么必要了解的坑)

质疑 Electron, 理解 Electron, 成为 Electron.

省流版: macOS 上的图形进程必须以 UI Thread 为主线程 (main thread), 本文对于调库, 使用 SwiftUI (或者老一点的 Storyboard Layout) 的同学估计没什么用; 对于没有辅助进程, 不需要动态调试的程序估计也没有这个需求.

(好像这么说就够了, 毕竟又不是写底层, 给一个底层的思路: 做一个主进程用来维护绘制请求, 然后新建窗口这样的命令发送过来的时候就像是提交一个计算任务/系统中断, 然后在主进程中切换到 main thread 中去执行窗体相关的代码. 然后绘制时更换不同的激活的窗体来实现多窗口. )

Aluria

凉凉做一个主进程用来维护绘制请求, 然后新建窗口这样的命令发送过来的时候就像是提交一个计算任务/系统中断, 然后在主进程中切换到 main thread 中去执行窗体相关的代码. 然后绘制时更换不同的激活的窗体来实现多窗口.

对，应当说这种模式是非常普遍和通用的，一般而言主线程只负责绘制图形（以及与界面元素的交互，如果库中有提供），在初始化的时候创建其它线程负责运算。各个线程间通过消息机制来控制程序流程（比如，我按下一个按钮后，主线程向command loop 发送消息 ButtonClicked(i) ）；当我们需要主线程更改绘制内容时，从其它线程发送消息通知主线程。
而主线程的消息接受是非阻塞的，这就保证了它可以专注于绘图而不会有耗时计算干扰帧率。

而对于大多数图形库，都是要求你在主线程上和绘图的，比如 Opengl ，GPT 的解释是如下的几个因素

图形库通常与底层窗口系统（如 Windows 的 Win32 API 或 macOS 的 Cocoa）紧密集成。这些窗口系统通常要求所有窗口和 UI 相关操作都在主线程中执行，以避免线程安全问题和数据竞争。不同线程之间进行复杂的图形操作可能会导致状态不一致和崩溃。
UI 事件循环（如鼠标点击、键盘输入等）通常运行在主线程中。如果图形渲染也需要响应这些事件，则将它们放在同一个线程中可以减少上下文切换的开销和复杂性。
线程安全性、平台要求、性能考虑等等

很多库也提供了可在的线程中操作图形的设计，但大多数是库显式或隐式地将命令和数据发送到主线程统一处理，比如 Direct3D 12，Metal (Apple) 等。
而还真有一个可以多线程操作GPU的库，（我没查它是怎么处理数据竞争问题的，有可能是给函数操作加个锁）：Vulkan 的设计使得它可以在多个线程中并行地提交命令到 GPU。应用程序可以在不同的线程中创建和管理 Vulkan 资源，这为复杂的渲染工作负载提供了更高的性能和灵活性。

话说回来，在主线程绘图，其它线程计算的设计理念尤为重要。比如，以只有一个线程而闻名的 Javascript ，它也需要考虑大规模运算的问题。一个长耗时的计算如果不结束，所有其它事件监听器都会排队等待，也就造成了用户界面完全失去响应，也就是页面卡死不动了。诚然，你可以通过在异步函数中反复调用中断来让事件监听器插队到前面来执行，可是中断的位置需要仔细设计，而且还会影响计算效率。
为解决这个问题， js 也提供了多线程的解决方案，如 Web Worker. 你可以创建多个 Web Worker ，它们是跑在不同的线程上的，而 Web Worker 与主线程的通信只能依赖消息机制，且传递的都是对象的拷贝，此外无法访问 document windows 等对象。这样完全保证了这个小线程内存的独立性，只能用来运算，不需要引入自旋锁等多线程的产物。
一个包含复杂运算处理的网页的设计思路可以如下：
主线程创建 Web Worker --> 绘图循环 --> (如果需要计算) 向 Web Worker 发送消息 --> 绘图循环 --> (worker.onMessage 回调) 将新的内容加入绘图循环 --> 绘图循环 --> ....
最典型的例子就是在网页上运行的计算器和图形计算器，比如 Math Studio 和 Desmos. 如果你在里面进行非常复杂的含时间绘图，你会发现绘图动画很卡但网页不卡。

这种模式比较常见，比如，我这几天在写的 Rust 代码中就用了：

impl eframe::App for MyApplication {
    fn update(&mut self, ctx: &eframe::egui::Context, _frame: &mut eframe::Frame) {
        // ...
        // draw ui
        // ...

        match self.msg.try_recv() {
            Err(std::sync::mpsc::TryRecvError::Empty) => (),  // no message to recv
            Ok(MyMessage::Text(t)) => self.info = t,
            Ok(MyMessage::ConnectInterrupt(is_host))=>{
                //...
            }
            // ...
            e => println!("{:#?}", e),                        // unexpected case
        }

        ctx.request_repaint();
    }
}

凉凉

Aluria 太强了...

凉凉

凉凉 Homebrew

清理 Homebrew

众所周知, Macbook 的内存是金子. 而如果你恰好为了上课/为了折腾/为了照抄网上的一些可能不一定对的操作等, 莫名其妙地在自己的主环境里面安装了一堆莫名奇妙的包, 还是很占空间的. 这里提供一个最近用来清理的一些记录:

最简单的清理是 brew cleanup, 用于删去下载的缓存. (但是建议在 brew update 和 brew upgrade 更新包之后清理)

另一个竟然有用的清理方式是更新包 (brew upgrade), 期望是新的包能够不要在依赖 Python 3.8, Python 3.9 这样的老版本 (Python 一个版本在我这里就比我平时用的大多数软件要大了), 然后使用 brew cleanup 来清理掉下载的缓存.

注: 接下来的一些操作不保真, 也不一定简单.

参考 reddit 上的帖子:

brew bundle dump
brew bundle --force cleanup

第一行是导出已经安装的包到一个 Brewfile 里面; 第二行是根据这个 Brewfile 去删除没有列在 Brewfile 中的依赖.

更加极端一点的方法 (参考 Untangling Your Homebrew Dependencies):

brew graph --installed | fdp -T png -o deps.png # 假设已经安装过 graphviz

会生成一个 deps.png 的依赖图, 可以根据依赖图去找里面的孤立节点, 配合 brew info 识别是否是自己有用的来去删除.

注: 貌似有 bug? 可能是我的包太多了导致处理不过来? 还是什么原因, 貌似一些孤立节点并不是真的无依赖的节点. 不过今天试的时候貌似又正常了.

一个示意图 (做了模糊处理):

Image description

凉凉

VMWare Fusion Pro on macOS

貌似被收购了之后, VMWare Fusion Pro 的个人版现在是免费的, 可以参考如下方式获得:

注册一个 "母公司" 的账号: https://support.broadcom.com/ (选择 Register, 然后注册);
用这个账号去下载 VMWare Fusion Pro (其实到 VWMare 官网上用账号下载是一样的), 记得选择个人版本即可.

(注: 这里吐槽另外一个 macOS 的坑: 你也不想自己申请不了基金吧... 还是老老实实给我用 Windows 吧... )

凉凉

DjVu $\rightarrow$ PDF

建议配合 DjVuLibre 食用:

安装

brew install djvulibre

使用

ddjvu -format=pdf -mode=black <from.djvu> <output.pdf>

Why

下 ~~盗版书~~ 学习版书的时候也许会遇到 djvu 格式的书 (常见于老书), 虽然你也可以使用 Emacs 来直接阅读, 但是要发到 iPad 或者别的地方来读的话还是会有些不方便.

凉凉

我是英语听力残障人士 (bushi

在 macOS 上有一个叫作 LiveCaption 的辅助功能 (实时字幕).

可以通过: 设置 - 辅助功能 - LiveCaption 的方式进行打开.

好处就是可以在一些比较抽象的英文听力环境 (且没有英文字幕) 的情况下使用 (比如网络会议, 报告, 讲座);
坏处就是如果背景比较吵闹 (比如歌曲, 背景音, 噪声超大) 的情况下, 识别并不是很准确. 只能是提供一个参考.

凉凉

NO LOCAL TimeMachine!!!

假如你的 mac 内存告急, 但是你恰好又要下载一些比较大的游戏, 可以考虑把本地的 Time Machine 备份给删掉:

列出本地备份

tmutil listlocalsnapshots /

删除备份

sudo tmutil deletelocalsnapshots <yyyy-mm-dd-hhmmss>

(注: 刚刚删掉的那个大概有 100+ GB 大小, Time Machine 还得是外部磁盘来干吧... 金子内存备份不了一点 💦

ArosƎ

凉凉查询lz的tm备份频率

凉凉

ArosƎ 大约是 1-3 个月. 因为还有另外一块硬盘用来塞其他垃圾文件冷备份, 所以一般是储存不够用需要腾空间备份/删除前会做一次 Time Machine 备份 (还有就是 brew upgrade && brew update 前会来一次), 虽然没有实际意义上地回滚过, 只是偶尔一些小文件找不到了用过 Time Machine.

ArosƎ

凉凉难怪了。我这边是一天一次（但是经常忘记，所以实际上是一个月几次）

凉凉

无用邮件的自动化归档

在苹果 macOS 上的 Mail 程序的设置 (Cmd-,) 中可以设定 Rules 来设置邮件规则来去掉一些比较恼人的邮件:

Image description

可以参考以下的规则:

Image description

注: 这里写得比较保守了, 其实也可以完全去掉所有的来自 cstcloud@cnic.cn 这个发件人的邮件.

Image description

凉凉

穷人的 Screen Rotation

使用背景

iPad 和 mac 可以通过 SideCar 来拓展屏幕, 你可以通过把 iPad 竖起来以实现阅读一些 PDF 或者预览 Overleaf 编译结果之类的东西
或者你干脆就是想要旋转 macOS 的屏幕输出

注: 如果你比较富有, 可以考虑直接使用 BatterDisplay Pro 并忽视下文中的所有的 hack.

全部应用

按住 Option 键打开设置 - 显示, 会看到旋转设置 (但这是应用到整个系统的)

Rotate Web

右键 Inspect Element
给 body 添加如下的 CSS style

transform: rotate(90deg);
width: 100vh;
height: 100vw;
top: 0;
left: 20vw;
padding: 0;
margin: 0;

缺点:

光标操作比较尴尬, 但是你可以通过 Apple Pencil 来解决这一点. (由于我只需要滚动预览, 所以并没有太麻烦)
可以自己编写一个油猴插件来实现

凉凉

没错, 还是给 Overleaf 用的 hack

有一个游览器插件叫作 GhostText, 可以让网页上的编辑和本地编辑器上的编辑进行一个同步, 于是你就可以实现在本地用 VSCode 或者 Emacs 进行编辑 LaTeX (你可以使用所有你自己的快速插件和补全了).

效果演示:

Image description

注: VSCode 或者其他的编辑器也同样支持.

注: 配合上文的 iPad SideCar 算是一个合理的工作流.

注: 貌似 GIF 没法显示? 替换成了静态的图片 (正常是会把游览器隐藏扔到一边不管的)

9426942942

凉凉 VSCode 有个 Overleaf Workshop 插件。

凉凉

9426942942 那应该很方便了, 平时 LaTeX 用的不太多, 这个做法估计会很好

« 上一页