ETiV

yt-dlp 直接导入浏览器里导出的 cookies.txt 即可，或者 --cookies-from-browser 让它自己去取

小兄弟，你要不要看看咱俩注册时间差多久 🤣

那许愿就变成了：🙏 祝福你的产出虽然广受认可及好评，但满街盗版、白嫖，没人愿意付费 🌠

你这么一说，倒是提醒到我了！我手里的 DGX Spark 还真就是老板送的…
要不你让你老板也送你一个吧，这个是真零成本了，只需付个电费

目前一个就在用 unsloth studio 跑 DeekSeek V4 Flash ↓

> 自己花钱用东西不是越便宜越好吗？

希望你的老板不要给你发工资 🙏

我们有一套成熟的架构

监控告警部分：

1. 证书的核心是域名，我们的域名配置存在 GitHub 上，通过 Terraform + Atlantis 服务，经 PR 审批后才能由其他人交叉验证后再执行 apply ，最终生效
2. 每三个小时，会有自动化的 Action 拉取 Terraform state 里的 DNS 记录，连接每一个域名的 443 端口，如果可连通且不超时，则加入到待探测的列表中（域名、解析值都要放进去）；对于例外的，比如非 443 端口的、或者与业务相关但非我公司域名的，也支持额外配置
3. 根据列表生成一套 telegraf 配置文件，配合使用它的 x509_cert 插件，拉起 telegraf --once 后，就能拿到这些域名的 HTTPS 证书的过期情况，并且写入到远程时序库里
4. 监控、告警配置在了 Grafana 里，取同一个域名的最小值（因为需要包含域名本身的过期时间、上游签发商的过期时间），过期前 10 天会发出告警


证书申请部分：

1. acme.sh 专门跑在一台机器上，新域名证书首次申请签发需手动执行 --issue ，后续会有 cron 自动跑续期
2. 申请证书也是用了 DNS 验证，DNS API 用了一套基于 Terraform 的，但是一个独立的仓库，没有 Atlantis 人肉参与审批。直接通过 Actions 自动化运行，所以约束了一下：提交的内容只有 json 的 [{name,value}, {...}] ，收到 push 后立即跑 Action：检查是否是 `_acme-challange` 的 name 、套模板，模板里写死 type=TXT ，避免出现意外情况。而后就是 tf init / tf apply -auto-approve
3. 而后过个 2 、3 分钟，新的解析就会生效，域名证书的签发在正常情况下都会跑完
4. 签发完后，执行 --deploy ，会把证书、私钥存到我们的 Vault 里。因此我们的 Vault 里会持续有最新的 HTTPS 证书文件

证书更新部分：

这一趴搞法比较多，主要分三种情况：
1. 证书直接配在云服务商的实例里：由我们直接通过预先配置在 Vault 里的 RAM 管理员角色，以 STS Token 的形式，通过各云的 cli 命令行程序执行配置的更新（也是跑在 acme.sh 那台机器上，随 cron 一起更新）
2. 证书被配在了不支持 API 更新的服务商那里，人肉处理
3. 被配在了某些业务团队自己的 Nginx 里：给业务团队配置 Vault 的 AppRole ，他们自己来获取自己该拿的证书文件，自己更新

中文还是博大精深…
死人了不能叫“送礼”，顶多“随份子”

显示器缩放是多少？
这个设置那里有一行文字，大概就是说调整缩放会影响性能