无头进程可能还真给跑到小核心上了，任务管理器设置一下线程亲和性吧，绑定大核心

只是删/Library/Developer/CommandLineTools/里的东西的话不需要关闭 SIP ，深度强迫症要删 Receipts 才需要关掉 SIP 。

本人学生，M2 Air 13inch 用户，计算机专业。对于学生还是建议有个高性能 Windows 机器，Macbook 作为便携/长续航的搭配。JB 全家桶是跨平台的，应该问题不大（我没用过）； Office 已经比较稳定了，我的毕业论文的格式有不少是在 Mac 上调的； Air 的散热问题不好解决，不建议长时间重度使用

我觉得算是达到了这个 8GPU M1 理论上该有的表现。
别忘了这是台被动散热的轻薄本。。。

控制中心一堆 bug ，一打开控制中心，日志里打一堆错误和崩溃，笑死

@gzlock 提到 AMD 也要加大小核这个事，关于桌面级核战，我比较认同这个文章的说法： https://www.zhihu.com/question/562154918/answer/2734093498
无限制搞核战的结果是消费者没法买到合适的产品了。
不过我个人对大小核异构设计本身还是持开放态度的，半导体在制程工艺和单一架构的 PPAC 方面很难再榨出大的潜力了，桌面端也早晚要走向异构设计，只是无限制核战导致进度大大提前，现在太不成熟

大小核心调度的一大问题是，调度器很难准确知道用户的意图。在桌面级操作系统上用移动端那一套的区分前后台分配核心逻辑去做是不行的，就会遇到你这样的情况，后台任务才是你想要保证性能的。
macOS 当然也会遇到这个问题，比如这个：软件安装进程被 Apple“优化”成绑死在小核心上，结果安装或者更新 xcode 等贼久，直接开骂。

Mixplorer https://mixplorer.com/
启用 http 服务器

CPython 应该不太可能移除 GIL 了

@gezimonkey 那以群晖官网为准吧。
吐槽一下 AMD 官网，产品信息提供的很少，和 Intel 的 ARK 没得比。。。

@crysislinux 抱歉看错了，R1600 不支持 ECC RAM

@crysislinux R1600 是 zen1 APU 屏蔽出来的，techpowerup 上的信息表示支持 AVX2 ，指令集没有阉割
https://www.techpowerup.com/cpu-specs/ryzen-embedded-r1600.c2845
和 Atom 出身的 J4125 比更像是低压 i3 一般的存在，还支持 ECC RAM

powershell core 在 macOS/Linux 上是支持 shebang 的，不知道 Windows 下还支不支持

一直在用 monknow
https://microsoftedge.microsoft.com/addons/detail/monknow-%E6%96%B0%E6%A0%87%E7%AD%BE%E9%A1%B5-%E4%B8%AA%E6%80%A7%E5%8C%96%E9%9D%A2%E6%9D%BF/ekpbeboofmnpohcmdnfkhjameokgffde?hl=zh-CN

printenv 是 jb 家软件都有的用来获取环境变量的东西，每次启动 jb 家的软件的时候都会执行一下。一般是瞬间就完成了，我没遇到过这种 100%卡在后台的情况

你发的这两个链接是关于 JIT 编译器需要注意的 Apple Silicon 内存写保护特性，感觉和你这个软件以及这个错误没什么关系。错误报告里看起来是在试图访问空指针

这图应该不是近照了