16G 如果开发的话 肯定不够， 我都后悔没上 32 的了，日常就是这个样子，虽说没有卡顿但是整天看着交换空间 3 个 G 起步很难受啊 https://imgur.com/a/jc7FBEn

做 ChatGLM 的迭代更新的吗？

@polobug 都 [大陆] 了

如果你有一个闲置的 iso 设备，可以用打码平台注册一个美版的 AppleID ，然后下载 Paypal ， 绑定招商银行的信用卡

op 怕不是有什么把柄在公司手上吧，不然很难想象这么怂，搁我现在整个园区都知道发生了什么

@Hudiebbk 梅花山庄就是深圳土著自建的别墅区呀，我散步都是去里面的， 晚上很舒服

@mx3y 哈哈 梅花山庄，OP 去别野里租个整栋

现在年轻人脾气的真的好好啊，这放到我身上仲裁 上法庭都是基本的，每天在公司下面拉横幅，哎， 横幅上必须指名道姓，谁谁谁谁怎么怎么恶心我，尽量不写公司名称，一定要具体到个人，包括不限于直接跟你谈话的人事，恶心你的所有人员。 都这么对你了，不蒸馒头争口气。。

另外，还在还有某位前老板被我挂在征信上

你们挺快的啊，四月份还在招研发，现在就开始 devops 了

你提到的这个问题非常有意义。Uvicorn 确实可以单独作为 ASGI 服务器运行，而 Gunicorn 通常用于运行 WSGI 应用程序。但是，当你将它们结合在一起使用时，会有一些特定的好处：

1. **稳定性**：Gunicorn 作为一个长期存在且经过良好测试的项目，它的稳定性和健壮性是有保障的。通过将 Gunicorn 与 Uvicorn 结合使用，可以利用 Gunicorn 的管理能力和稳定性，以及 Uvicorn 的异步性能。

2. **进程管理**：Gunicorn 提供了一些强大的进程管理功能，例如工作进程的启动、停止和重启。当系统负载增加时，它可以更好地管理资源，而 Uvicorn 单独运行时可能没有这些特性。

3. **部署的简化**：对于那些已经习惯使用 Gunicorn 来部署 WSGI 应用程序的组织来说，将 Gunicorn 与 Uvicorn 结合使用可以简化迁移到 ASGI 的过程。团队可以利用现有的 Gunicorn 部署、监控和日志记录基础设施。

4. **配置灵活性**：Gunicorn 提供了许多配置选项和插件，可以方便地自定义应用程序的行为。与 Uvicorn 结合使用时，你可以利用这些灵活性，并允许在同一台机器上同时运行 WSGI 和 ASGI 应用程序。

5. **负载均衡**：Gunicorn 能够在多个工作进程之间进行负载均衡。这不仅能够更好地利用多核 CPU ，还可以增加系统的可扩展性和冗余性。

总而言之，尽管 Uvicorn 单独使用具有优势，但将 Gunicorn 与 Uvicorn 结合使用可以提供额外的稳定性、灵活性和管理功能。这种组合在具有大量流量和需要高可用性的生产环境中可能尤为有用。


by GPT

兄弟，这么跟你说吧，出了敏感问题跟阿里腾讯华为这样的公司还能谈，罚酒三杯了事。对你， 对接的就是国家暴力机器

你疯了？ 下班了还想接着上班是吧？ 好不容易跑了还想着回去

EventStream 传输, 网络抖动, 服务器 抖动 都可能会造成传输断开

@mariljacksoa 兄弟牛逼啊, 大道至简

兄弟你这个让我想起了抖音上卖爬虫的, 爬一个 B 站的视频, 然后卖课程, 点进去一看, 我擦, 竟然售出了 50 多份, 一份 899.....

你现在是一个 NAS 使用专家, 请帮我解决如下问题

目前在 NAS 上用 joplin+Nginx Proxy Manager(NPM),路由 OPENWRT

joplin APP_BASE_URL https://joplin.XXXX.top
openwrt 上将 7788 端口映射到 npm,npm 反代到局域网 ip:80 端口

目前客户端使用 https://joplin.XXXX.top:7788 正常
但网页想进 joplin 后台会发现所有 css,js,跳转全部指向了 joplin.XXXX.top,默认端口 80,导致无法登录(以前没用 npm 时是 openwrt+nas 自带的反代,那时候可以正常进)

尝试将 APP_BASE_URL 改为 https://joplin.XXXX.top:7788 或者 7520,客户端也无法访问,网页报 invalid origin https://joplin.XXXX.top(注意,报错没有端口号)



看起来你需要更改 Joplin 的配置，使其正确地反向代理通过 Nginx Proxy Manager 访问。下面是一些可能的解决方案：

1. 在 Nginx Proxy Manager 中创建一个新的主机，并将其指向 Joplin 的 IP 地址和端口号（ 80 或 7788 或 7520 ）。在该主机的设置中，启用 WebSocket 和 SSL ，并配置正确的证书。接下来，在你的 Joplin 客户端中将 APP_BASE_URL 设置为 https://你新创建的主机的域名或 IP 地址（包括协议和端口号）。然后重启 Nginx Proxy Manager 和 Joplin ，看看是否能正常访问。

2. 在 Nginx Proxy Manager 中创建一个新的位置，指向 Joplin 的 IP 地址和端口号（ 80 或 7788 或 7520 ），然后将该位置添加到你现有的主机中。在该位置的设置中，启用 WebSocket 和 SSL ，并配置正确的证书。接下来，在你的 Joplin 客户端中将 APP_BASE_URL 设置为 https://你现有主机的域名或 IP 地址（包括协议和端口号）和新创建位置的路径。然后重启 Nginx Proxy Manager 和 Joplin ，看看是否能正常访问。

3. 如果上述方法都不起作用，你可以尝试修改 Joplin 的源代码。在 `WebApplication.js` 文件中，找到以下代码行：

```
this.app.use((req, res, next) => {
if (!this.api.config().clientWeb.packaged) {
res.header("Content-Security-Policy", "default-src 'self'");
}
next();
});
```

将其替换为以下代码：

```
this.app.use((req, res, next) => {
res.setHeader('Content-Security-Policy', "default-src 'self' 'unsafe-inline' 'unsafe-eval'");
next();
});
```

然后重启 Joplin ，看看是否能正常访问。

希望这些方法能够帮助你解决问题。如果你有任何疑问或需要更多帮助，请随时问我。

这玩意现在我都交给 gpt4 去做, 效率很高

@brader 👍👍👍👍