@anUglyDog 3700U 的性能跟 N100 差不多，单核几乎一样，多核有一点优势，超线程给的优势。

好处是核显图形渲染性能更强，如果有游戏需求的话。
但 N100 的视频硬件编码性能强，质量好，功耗也低，适合作为服务器（尤其是流媒体服务器）用途。

但是 3700U 待机功耗比 N100 高，Ryzen 处理器只有 4xxx 以后的功耗才开始变低。

3700U 有一个优势是 PCIe 通道多了 4 条，但最终有没有用上还得看主板……

我甚至用来作为主力机……

@daveh 对了，至于换 JBR17 跑一下这个事情，因为我已经第一时间升级到 14.4.1 了，所以已经没有必要测了。

@daveh
我确实看不懂，得向你请教一下

> 一些恶意程序、poc 程序最喜欢在进程全地址空间扫描
能不能具体说明是哪个恶意程序或者 poc 程序，利用的是哪个漏洞。如果只是漫无目的地扫描，那么它接下来该做什么？

> 触发提权漏洞
看来范围更小了，能更详细一些吗？

现代的操作系统进程的地址空间都是虚拟地址，程序获取自己申请的内存和加载的动态链接库的内存地址不需要通过一个个扫描地址的方式来探测，一般都可以通过操作系统提供的接口来得到。

为什么会存在需要全地址扫描才能得知的内存地址，而且这个应用程序居然还能有权访问（即不会触发 SIGSEGV 、SIGBUS ，因此程序能够通过是否收到信号的方式来找到它）。我对 macOS 的内核完全不了解，如果这是 macOS 特有机制，可以简单介绍一下，或者给我相关信息供我检索吗？


你的说法听起来也适用于 Linux 。为何从未听说过有云服务厂商担心这个问题，尤其是提供 Docker 容器服务、云函数等功能的厂商

@daveh
公司的项目并不会崩溃，开发工具（例如 DBeaver ）之类的偶尔会崩溃。而且不是升级 JDK 就能解决，大多数软件只兼容 JDK 17 ，兼容不同版本的 JDK 得改代码适配。而且非 LTS 版本能用的第三方库不全，大家都不会花时间精力在这种版本上。

这种事情都是说起来轻松，实际做起来，还不如直接抛弃 macOS 改用 Windows ，省下的时间活都干完了。

这和安全也没有什么关系，我没见过有任何有信服力的说法能证明这个改动提升了安全性，只见过果粉用这个说法来给苹果的行为辩护。

@daveh 还有，如果是苹果故意这么做的，那给我的印象就更糟糕了，比工程师改代码测试忘记改回来还合并进去了的情况糟糕。

这意味着，当苹果想更改系统行为的时候，有这些选择：
1. 发布公告说明 macOS 即将发生重大改变，可能会对应用兼容性产生影响。在公告里说明为什么要作出这项更改，有什么好处，让各大开发商尽快完成适配工作（或选择放弃兼容 macOS ）。

2. 偷偷发布正式版更新，直接对最终消费者进行惩罚，通过引发严重故障让他们来倒逼软件开发商适配。像 Java 这种有人买了商业支持，客户有要求，不能不做。

苹果觉得 2 比 1 好。

@daveh 我根本享受不到这些，只有忍受每天不定时崩溃……

不升级不行，我在 14.4 天天忍受折磨，Java 应用随机崩溃

@niunaisuan93 这模型的效果其实很差，大多数时候都会乱讲……我已经放弃了
之前找的网上的开源代码，简单改了改

@WilsonGGG 然而这个问题对比的是 macOS 和 Windows 。

低分屏上 Ubuntu 还真比 macOS 好，至少 hinting 管用，也可以开次像素渲染。
我现在正在用低分屏+macOS ，字体渲染真的跟果粉说的一样，就像印刷出来的……
只是他们少了一个定语，像非法出版物的印刷。

我还给 macOS 装了一个点阵字体（字体名 Unifont ），现在的 macOS 渲染点阵字体也有一圈阴影了，虽然总体上看起来还是锐利的，能对齐到像素。不过旧版 macOS 和 Ubuntu 都没有这个问题。

Ubuntu 的字体渲染不是没有缺点，有些字体会有间距不一致的问题，同样的字体放到 Windows 和 macOS 下都挺好。

只能说各有优缺点吧。

也许是微软保留了各种曾经出现过的 API ，不少软件底层代码历史悠久能用就不改，所以整体看起来比较差。

比如获取系统默认字体就有一套 API 能拿到宋体，一套能拿到微软雅黑……

Windows 里面也有字体渲染看起来比较好的东西。

在 Windows 版 IDEA 里，把抗锯齿改成灰度，字体不用微软雅黑，看起来就挺好的。

Windows 10 的开始菜单界面字体效果也还可以。

Windows Terminal 不显示微软雅黑字体的时候也不错。

@nrtEBH 我突然想起了什么用隐私换便利之类的……

@jfv 求指路，顺便问一下，docker 最低给多少内存能跑

@NavilleZhang 简单看了看，感觉这玩意像 SELinux 而不是 Sandboxie……
Sandboxie 并不会让 API 调用失败，只是会让文件、注册表等读写操作都重定向到沙盒目录下，或者让程序读不到剪贴板之类的。基本上是开箱即用的，就好像装虚拟机来跑软件一样。
sandbox-exec 像是要么应用得改造适配，要么手动找出应用所需的权限一个个放行。
相比起来，虚拟机更接近我的需求，只是虚拟机占用的资源实在太多了。

WSL 能用，内存不要太小就好。建议 32GB 起，64GB 更好。
WSL2 刚出那会可能有点坑，如今基本上什么都不用折腾，装好就能用，VSCode 连接上去体验比直接用 Linux 桌面还要好。网络也可以改成 mirror 模式，Linux 程序可以用 Windows 下的 VPN ，Windows 的浏览器或者其他工具也可以直连 Linux 程序。

换电脑也可以直接把 WSL 环境导出，到新电脑上导入。只需要非常少量的配置就能进入开发状态。
然后还能享受 Windows 的桌面应用生态。

比起处理 Linux 桌面的种种问题，我觉得 WSL 已经相当友好了，只要你对 Windows 本身没有什么偏见的话。


如果是 Windows 7 、或者 2017 年以前的 Windows 10 ，没有能用的 WSL 的时代（ 2017 年以前有很多大 bug ），开发体验确实不是很好。

如果生成式 AI 会运用于对用户数据的加工整理，例如帮你找出你最近浏览过的某个网站，或者你的某一篇笔记之类的，是不是意味着不少个人隐私数据会上传给百度？

我用 8GB 内存的 Mac 跑 Xcode+模拟器，模拟器偶尔都会黑屏卡出 bug……

@jonsmith WSL 上的 Ubuntu 也是 Canonical 出的，不是盗版……

另外我又想起了这个 WSL 没有而 Mac Docker 才有的问题……
https://github.com/pnpm/pnpm/issues/5803

不过后来 Docker Desktop 更新后有办法绕过了，OrbStack 之类的没办法

另外，至于 Mac 版 Docker Desktop 的 IO 性能，还有个 issue：
https://github.com/docker/for-mac/issues/6667