@Takuron 还比烂都出来了。我的第一句话就是质疑原推的逻辑。我的后续是在反驳“花钱被强奸”的理由。

我回复的原推喜欢到处下别人的软件直接装，macOS not an option 可以。我的桌面需求除了 macOS 都不行就不可以？原推直接骂人斯德哥尔摩综合症，你骂人蛆，我甚至都没有正话反说，句句事实。

@fiveelementgid

用户绕过限制强行装开发者不提供在 Mac App Store 上上架 iOS app，现在苹果堵住这条路了居然叫强奸，逻辑 100 分。

为什么要花钱被公司强奸？我买什么电脑不是电脑？

我就是不愿意看 hinted 后的字体，我就是有 180ppi 以上的屏幕，不需要系统再多此一举，Windows 不行吧。看看左边多平滑，右边多粗糙，都是 200% 缩放。https://imgur.com/SfWaDxF
我要两台显示器不同时显示同一个虚拟桌面，Windows 不行吧。
我要在 Task View 的时候重新排序虚拟桌面，Windows 不行吧。
我要在 Task View 的时候把程序窗口从左边的桌面拖到右边的桌面，Windows 不行吧。
我要在进入 Task View 的时候窗口不会在动画结束的时候位置不对而突然跳一下，Windows 还没改好吧。这一点在 Windows 10X 进入 2 个程序 side by side 的时候问题居然还存在。

为什么不用 Linux 桌面？试过了啊，我要的是正常使用且美观的 UI 界面，没有时间折腾，也有太多程序不工作。

@discrete M1 机器也不支持 Thunderbolt DC 多台显示器。

补充，虽然 YouTube Music 也有上传自己音乐的功能，但是无论源质量如何，都会进行二压，以保证会员才能收听 format code 141 的 256 Kbps AAC，非会员收听 format code 140 的 128 Kbps AAC 。同时不能编辑资料库的元数据。

Apple Music 的上传策略是 320 Kbps 以下的 AAC 、MP3 都不二压，在收听的时候直接下载源文件。如果是无损的 WAV 或 Apple Lossless 则在上传前用自带的 CoreAudio AAC 编码器压制成 256 Kbps 的 AAC 。

@AdrianZhangX 同。还有一点 Apple Music 独家的就是可以自行编辑库里音乐的元数据，并且元数据还全平台同步。

例子 1
一首 Apple Music 服务里有的日文歌，在英文国家区是以罗马字显示的一长串拉丁字母（如“薔薇のように咲いて 桜のように散って”会显示为“Baranoyounisaite Sakuranoyounichitte”），在电脑端 iTunes 或 Music.app 修改后手机、电脑和网页版都是以修改后的元数据显示。对于在 Apple ID 在英文区且同时听 CJK 歌曲的用户而言非常实用。

例子 2
一首 Apple Music 服务没有的歌曲，可以从其他渠道下载，然后添加到自己的 iCloud 云端资料库里。如果能匹配到已有的歌曲，比如 Apple Music 不提供但是 iTunes Store 提供，或本区 Apple Music 提供但外区有的，则以 Apple Music 里的 iTunes+ AAC 音质提供*。如果没有的，就上传。且已匹配 /上传的歌曲全平台都可以收听。还可以像例子 1 一样，打理从其他渠道获取的元数据杂乱的歌曲。

* 此条现行规则不太明确。前几年经常能匹配，现在基本都是上传。

@kid740246048 不是软件。
https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows

macOS 不支持类似 iOS 的动态字体大小调整。
临时使用可以按住 Control 键滚动鼠标滚轮 /双指上下滑动打开全局放大镜并调整。
至于嘲讽 macOS Hi-DPI 支持的，先让 Windows 在缩放下以“逻辑分辨率”渲染再说吧，否则 DPI Per Monitor Awareness 出到 V100 都没用。

6c/5300m/16G 换了 M1/16G

Chrome 闪退是因为 32 位。
补充 4 个 Firestorm 大核的 Geekbench v5 跑分 1607/5127 https://browser.geekbench.com/v5/cpu/5502746

@CastleBUPT insecurity

@hjc4869 对不起，没有注意到 10 ~ 20W 是 12nm 的 IO Die 吃了。那么忽略周边的耗电，仅考虑 Zen 3 核心的话，3.2 GHz 下确实会比 M1 更加省电，但是同频绝对性能就下来了。CBr23 1500 左右的 Zen 3 单核分数是至少是 4+ GHz 的频率，降到 3.2 也只能是 1200 左右。

@wydinhk Anandtech 是测的 Mac mini 插座功耗。老款 150W 电源，这个载荷下效能只有 55%。实际体验见 https://www.v2ex.com/t/733413#reply10

每次遇到谈 M1 的帖子必然会有 4800U 默秒全，5800U 暴打的回帖出现。
大核 Firestorm 单核下 3.2 GHz 耗电 5W，而且没有类似 Intel 睿频或 AMD Precision Boost 之类的“超频”机制。Zen 3 桌面 CPU 能和 M1 3.2 GHz 单核比肩的都是频率 4.0+ GHz 、单核场景下耗电 20+ 瓦。就算 Zen 3 笔记本 SKU 有更好的 binning，也不可能突然一下子从 20+W 降到个位数级别。更别说 Zen 2 了，我的 3300X 单核 4.3 GHz 就耗电 30+W，单核 CBr23 还只有 1200+。
况且真正跑长时间多线程负载 M1 耗电是顶天 18W，4800U 至少都是 15W，根据厂商设置最高可以吃到 25W 。再加上为了突发性能需求，比如打开程序等耗时很短但是用户感知明显的地方，CPU boost 到 4+ GHz，20 瓦就吃完了，而 M1 单核不管怎么跑都不会超过 5W 。
归根结底就是你谈性能，他用 4+ GHz 的频率跟 3.2 GHz 的比。你谈功耗，他就说 Zen 3 降频下来也一样省电。
M1 在暴力多线程工作上是比较拉垮，还没有超线程，理论性能确实比不上这些真 8 核 16 线程的 U，4 个 Icestorm 小核加起来也就一个 Firestorm 大核的性能。但就一些多线程测试来看，如 ffmpeg x264 软编、vp9 软解等至少也没有弱到哪里去。


@cwbsw 这根“单”热管可以散 CPU 45W + GPU 50W 的热。轻薄的同时留出空间给 100WHr 大电池。
@breaker911 降频是 Air，而且性能损失在 10% 左右。Pro/mini 的表现不是 thermal throttle 而是 TDP throttle，从 3.2 GHz 到 3.0 GHz，尽管散热能力还有很大空间。要是把 Zen 3 限制到 3.2 GHz，单核不知道菜到哪去了，耗电也绝对不会低于 5W 。
@icyalala 实际使用 M1 的功耗令人发指。我后台开了一堆 IM，还开了战网放前台，现在还在打字，瞄了一眼 `sudo powermetrics`，M1 整片功耗 283 毫瓦。Twitter Catalyst app，滚动页面 Intel 9750H 耗电 30W，M1 耗电 1.2 瓦（当然可以说 Apple “劣化” x86 Catalyst ）。MS Teams 臃肿无比的 Electron (Rosetta 2)，多人会议 Intel 9750H 耗电 35W，M1 耗电 1.5 瓦，而且响应还更快。M1 上超过 10W 运行的都是非常非常重的负载了。比如视频软件编码、多线程批量导图等。就搭载 M1 的三款机器来看，目标都是中、轻量用户。Linus Tech Tips 的续航测试就是连续放硬解的视频，已经对其他笔记本很仁慈了，真要做点事情，x86 笔记本的耗电不知道要高到哪里去，M1 笔记本的续航和体验在所有“同类”笔记本还会更出众。

[email protected] 都已经有编译好的 arm64 Big Sur bottle 了。https://formulae.brew.sh/formula/[email protected]

雷电硬盘盒直通 PCIe 的只能是 NVMe SSD，且直接挂载在 NVMe 树上。标 5 Gbps 就说明是硬盘是走 USB 协议，大概率不支持 TRIM 。

雷电 NVMe 硬盘盒有许多。我买的便宜的 Orico 加便宜的 A2000 。在 Intel Mac 下确实烫手，接到 M1 Mac 之后就温温的了。本来 NVMe 硬盘发热就大，散热不好六七十度常有的事，不用太在意。

@shyling bat 编译依赖 rust，Rust 无 Big Sur arm64 bottle 。编译 rust 依赖 cmake 。cmake 目前已经有 Big Sur arm64 bottle 了。

@starix 争议其实是对于不改变现状的生产力用户，all-in M1 风险太大；而技术追新的用户眼里 M1 或者整个 Apple Silicon 而言前景是非常好的，而且当前绝大多数使用场景也有解决办法。你本意是把 M1 用于生产力，且一定要适应 brew 包管理，即不改变现有工作流也不愿意考虑兼容问题，只是贴里的“爱好折腾”表达出的观点会被误认为是追新派。建议网上发言谨言慎行。

@starix x86 的 bat 是有 Big Sur 的 bottle 的。ASi 的 bat 需要从源码编译，依赖 rust 。Rust 本身还没有 ASi ready 。而且你既然喜欢折腾，为什么找不到这么明显的用 Rosetta 2 的解决办法，要么直接从 Github 下载编译好的 x86 bat，要么用 arch -x86_64 来运行 Intel brew 来安装编译好的 bottle 。是 M1 的机器跑不起来 bat 吗？不是吧。能正常跑绝大多数 x86 软件正好和你贴里的“软件生态需要磨合”相违背。

@unijiang
说明你的机器不支持 DisplayPort 1.4 。那就没有办法了，4K60 和 USB 3.0 自己取舍。
大多数 Windows 笔记本的 USB-C 输出都是 DisplayPort 1.2 的。
Mac 机型需要： https://support.apple.com/zh-cn/HT207806
· 2019 年推出的 16 英寸 MacBook Pro
· 2017 年或之后推出的 15 英寸 MacBook Pro
· 2020 年推出的 13 英寸 MacBook Pro （四个雷雳 3 端口）
· 2020 年推出的 MacBook Air
· 2017 年或之后推出的 iMac （视网膜显示屏）