@v2tudnew #26
1.
> 你那张图无非是虚拟内存占满了，肯定是崩溃的，我上面已经说了你可以调大页面文件，实际它不会立即写入。
图上并不是虚拟内存占满了。程序要操作系统承诺(commit)大量内存≠进程真的要利用那么多内存（包括物理 RAM 和各种形式的虚拟内存）
例如：
https://i.imgur.com/UMWzUu9.png

2.
> 这种情况不是和 overcommit 一样的效果，没有 oom-killer 的情况下 Linux 内存占满它就不会崩了？
“Linux 内存占满后会不会崩”我不敢打包票，毕竟哪怕我是神仙我也不能超过物理限制；但这里的多个例子已经展示了 Windows 上物理 RAM 和虚拟内存两个都没占满甚至还有大量空闲的情况下就有进程崩了。overcommit 是灵活的变通手段不是死板杀进程的限制。

3.
> 所以关键的还是 oom-killer 杀死进程，但普通人如何配置哪些进程被杀死？
同上，Linux 出现 oom-killer 是「内存真占满了」的极端情况，Windows 上离极端情况还差得远的时候就开始拒绝内存申请。保不住后台的“小工具”，更不一定能保住高资源占用率的关键应用。
况且能给用户更大的选择权总归是好的。


4.
> 像手机游戏就经常被杀，加大学习成本研究守护方法。

拿移动端来比就没意思了。手机为了便携就必须在硬件规格上妥协（有限得多的电源供应、算力和内存大小），必须在续航能力/流畅度上想办法优化，这是操作系统有意而为之的设计。

以 Android 为例：当年 Android 2.3/4.x/5.x 的年代用户还得自己开黑阈/阻止运行/绿色守护主动关闭杀后台进程，要不然 xx 手机卫士/xx 手机管家/某宝/某些即时通讯软件/xx 手机助手怕是得在手机里闹翻天。
如今 Google 和国产手机厂商都学聪明了，手机硬件配置不断升级的今天，各种 XXUI/XXOS 的后台进程策略反而比当年严格得多。某三字购物软件更是靠“挖 CVE”来给自己提权保活。如今杀后台的可能不是 oom-killer ，更可能是手机自带的“系统管家”和操作系统的电池优化特性。


5.
> 默认 Windows 是所有分区分配页面文件的，自己不调没这个问题。
Windows 并不会默认在所有分区上创建 pagefile.sys 。
https://i.imgur.com/QkLnX2y.png

@v2tudnew #24

1. overcommit 在这篇帖子的场景下其实恰恰反而可以让操作系统上的进程更稳定，允许程序向操作系统“提交”多于虚拟内存+物理 RAM 大小的内存更像是一种宽恕，而不是严格的限制。
（要不然掌管服务器操作系统半壁江山的 Linux 上若是经常让关键业务和后台进程经常挂掉的话，那老板/员工/客户都得难受了）
（而且 Linux 上 overcommit 、oom 行为、swap/zram 都是有很多选项可以按自己需求灵活调整的）


2. 以 Linux 为例，杀死进程的并不是 overcommit 特性本身，而是 oom-killer 和内存分配失败导致的程序崩溃。

此外，假如真到了像是内存被占满必须得靠 oom-killer 出马杀几个进程祭天的场景，Windows 上“严格的限制”并不一定能保证后台挂着的游戏和大型任务能安稳地运行。
例如我在#16 楼发的截图：在“已提交”紧缺的时候，"System Informer"这种在后台挂着当资源监视器的小工具也会崩溃、Windows 控制面板也逃不过卡死。关键是它们崩溃时物理内存根本没占满甚至还有大量空闲。对于内存释放分配更频繁、空间请求和占用都更多的游戏和大型任务这很可能会更糟，毕竟进程的 Commit Charge 是不会小于实际内存用量的。

@ysc3839 #20
我觉得依赖虚拟内存技术（内存压缩/分页文件/SWAP ）本身没问题，毕竟像 提高多任务能力/保留兼容性/压缩硬件成本 之类的好处都能给用户带来实实在在的收益。

问题其实还是操作系统在“依赖虚拟内存”的过程中容易出差错（依赖 SWAP/页面文件时没好好设计导致的），就像这里因为 Windows 缺乏灵活的"overcommit"设计导致了用户的程序在 RAM 仍有空闲的情况下崩溃； 系统没管理好类似"swappiness"这样的参数在当年让 macOS 用户的硬盘被大量异常写入、让 Windows 的分页文件占着大量存储空间却实际只有很一小部分被利用…

但是 Chrome 确实是真的出了名的吃内存（

进程“已提交”的内存超过“页面文件”和物理 RAM 大小的总和时就会出现这种情况（例如下图），这个问题是 Windows NT 的历史遗留问题造成的。
（很难想象 2024 年了 Windows 还在高度依赖虚拟内存，而且为了性能实际被 swap 进磁盘的页面其实很少，实在是浪费磁盘空间）

解决方法：

1. 在任务管理器里面找到“详细信息”选项卡，右键点击列标题区域（例如“名称”列），选择“选择列”。
把“已提交大小”勾上，排查一下哪些进程的已提交大小过高。

2. 还有一种情况是：楼主的系统分区可能空间不足，或者楼主修改了系统的虚拟内存相关设置。
（因为 Windows 默认会自动管理虚拟内存/页面文件的大小。当系统“已提交”大小达到系统提交限制的 90% 时，系统管理的页面文件会自动扩展到物理内存的 3 倍，但不会超过卷大小的 1/8 ）

- 如果是这种情况并且磁盘空间足够的话，可以 Win+R 运行`sysdm.cpl`（控制面板->系统属性），修改系统设置让 Windows 多分配些虚拟内存（或者设为系统自动管理）

https://i.v2ex.co/j2bJj305.png
https://i.v2ex.co/Y9CTd73L.png

v2ex 启用了 Encrypted Client Hello 之后理论上一直都可以直连（需要 DNS 和浏览器支持）
https://www.v2ex.com/cdn-cgi/trace
https://i.imgur.com/OqzdKwl.png

在 Public Suffix 列表中的“域名后缀”可以被添加到 Cloudflare：
（ https://publicsuffix.org/learn/
（列表见 https://publicsuffix.org/list/public_suffix_list.dat

1. 一些从业较久、声誉良好的付费证书提供商可针对老旧系统或设备提供更广泛的兼容性。

2. 付费证书提供商多年以来的宣传会无形中培养一些关于证书产品的刻板印象，改变了一些公司或人员的消费习惯。

3. 付费证书提供商开出的高价中往往包含“赔付”或“保障”等服务，可以帮助开发人员和管理者分担出现事故时的责任与风险（而且反正又不需要我们打工的出钱）

4. 价格更高的 EV 、OV 证书在某些场景下是一种身份证明和财力/实力象征，能一定程度上博取用户/客户信任。
（例如 Google 直接自建 CA ）（例如“我可能用不上，但我不能没有”，就像工商银行可以砸钱去 ICANN 买一个 *.icbc 的域名后缀那样，哪怕并没有实际业务用也无所谓）

5. 一些历史包袱较重的服务，以及维护它们的公司/政⁡府难以轻松地为系统添加自动化证书更新。哪怕一些全球知名的大公司也逃不过偶尔的“证书过期”事故。
（相关新闻可搜索关键词：淘宝 证书过期、Apple Music 证书过期）

谢谢楼主！我的会员 ID 是：869

话说为什么“奖励数量：20”也有 50% 的概率中奖（是仅前 40 楼才参与抽奖吗？

一个解决方法：使用 NoScript 浏览器扩展屏蔽网页对本地网络发起的请求

1. 网站或域名的所有权可以通过非常简单的方式即时验证，而应用程序发布者的个人或企业身份验证过程+密钥存储/分发会繁琐得多。（额外的麻烦=额外的费用）

2. 代码签名证书泄露危害大，容易让发布者背大锅。（影响公司商誉）

3. TLS 证书使用量/签发量大，应用范围广（各种设备/各种应用/各种操作系统都在用）；而代码签名证书往往应用范围有限（例如 Windows/MacOS/Android 都有各自不同的代码签名方式）

4. 保障通过 HTTP(S)/TLS 在网络上传输的数据的私密性非常重要（ TLS 的重要性几乎无可替代），大家更愿意投钱出力推动这样保障基础安全的东西普及。

5. 对于保障发布者来源+程序完整性这些需求而言，付费代码签名证书的替代较多。例如：实际应用中往往还可以用 GPG/PGP （验证发布者&完整性）或者发布时附带 Hash （验证完整性）来解决一些信任问题。

6. 在 Windows 上付费的代码签名证书很多时候是为了过杀软，个人开发者或者小企业可能不在意这些事，而大公司在这种事情上就难受了。CA 对大公司开刀符合经济规律。

“对宝塔嗤之以鼻”可能和“孔乙己的长衫”这种心态真没啥关系，毕竟 1Panel/AMH/AppNode/cPanel/Pleak/VestaCP 也没见得有那么多人黑。

以前叫它“删库塔”可能是少数恶性 bug ，结果宝塔自己真爆了几次利用难度比 log4j 还低的漏洞（ phpmyadmin 未授权访问以及不止一次 xss2rce ），还全是低级错误导致的，这只能怪它草台班子自己不争气。

年初宝塔被挖出来他们家官网的防火墙演示站自带 SQL 注入/未授权访问（ https://v2ex.com/t/1015934 ），前几天又出了事故让官网和 API 全部离线。
作为卖安全产品的公司，自家防火墙还能给客户引入新漏洞；作为卖运维服务的公司，自家官网遇到单点故障连个灾备都没有。只能说实在是太丢人了。

之前宝塔面板的代码质量也是一言难尽：Python 能做的文件操作它非要去拼字符串调 Shell （有时输入内容还过滤不干净）、分发二进制软件包用明文 http 还不带校验……

总之，宝塔的声誉纯粹是他们一次又一次自己丢掉的，虽然靠着产品简单方便吸引了不少用户，但卖了那么多做不好确实该挨骂。（不过现在宝塔在出了这么多事挨了这么多骂以后的确也有长进。

当你配置的代理以`https://`开头时，git 会首先使用 TLS 连接这个代理服务器。
例如，假设我使用了以下命令配置代理：
`export HTTPS_PROXY=https://127.0.0.1:10809`
`git config --global https.proxy https://127.0.0.1:10809`
在 git 发起请求时抓包看一下，可见 git 给 HTTP 代理发了一个 TLS Client Hello 。v2rayn 日志也提示收到一堆非 HTTP/1.1 的二进制，Git 也返回楼主遇到的同款错误。
https://i.imgur.com/LgTv19j.png
而 v2rayn （包括 xray/v2fly/sing-box 等）代理软件显然不会自己给 127.0.0.1 签一个 TLS 证书（毕竟麻烦&没必要），它们开放出来的、用于本地访问的 HTTP 代理是不支持像各种网站服务器那样接收 HTTPS/TLS 连接的。


解决方法：
将"https://"替换成"http://"，或者配置 socks5 代理。


这里有几个容易混淆的点：

1. HTTPS_PROXY 或 https.proxy 并不是说这里必须要填一个 HTTPS 代理，它的意思是“指定访问 HTTPS 的服务时所用的代理”。
同理，HTTP_PROXY 或 http.proxy 的意思是“访问未加密的 HTTP 服务时所用的代理”

2. 在此场景中"https://"开头的代理和另一个概念（例如：“xx 免费代理”“全球开放代理”那些网站/场景下所说的“HTTPS 代理”）是不一样的：
- 这里提到的"https://"开头的代理需要客户端用 TLS 连接
- 那些 xx 网站等场景下经常说的 HTTPS 代理指的是：支持"CONNECT"这一 HTTP 请求方法的、基于 HTTP 协议的代理；
- （因为当年有好些“普通 HTTP 代理”只支持或开放 GET 、POST 等方法，访问"https://"网站时 TLS/SSL 加密解密由代理服务器处理，代理服务器能看到全部明文
-（ “CONNECT 方法可用于访问使用 TLS/HTTPS 的网站，它实际上提供了一个中继 TCP 流的隧道”

很好看！换掉 VSCode 左上角的蓝色默认图标后简直完美
https://i.imgur.com/79Qs0t5.png

不过拆分编辑器区域时标签栏似乎有点小 bug：
（当某一编辑器区域未在焦点时，其当前标签的背景色会变成与字体相同的颜色）
https://i.imgur.com/vO13s39.png