我有一台联通的物理服务器和一台法国的物理服务器，也有很多云主机。

至于哪个划算，得看你是做什么。如果跑的东西很轻量，那么云主机就够；当配置要求上到 8c16g 的时候就可以考虑用物理服务器了，长期下来价格便宜不少。但是记得要考虑网络问题，不知道你是国内还是国外，国外不需要考虑带宽（最低都是无限流量的 Gbps 口），但需要考虑电费；国内反过来的。

至于托管商方面，国内如果在意延迟，那就得放在一二线城市运营商机房，如果在乎费用，就托管到三四线城市的。国外得看你位置，每个国家都有本地的 colocation 供应商，就和我们的腾讯阿里一样，得谷歌找找

@gowk 封禁就代表公司明确不允许这种事情发生，任何通过技术手段绕过该限制都属于故意违规。

@jedeft 作为公司的运维一员，可以明确的说，任何除公司提供的远程方案以外都属于违规，开掉你不用赔钱，尤其是万一出事之后。

尤其是 tailscale 组网，相当于你的机器作为网关，允许外部网络连接。我不知道你们公司什么性质，如果有合规要求，那么你的操作导致公司涉及向境外传输数据（因为 tailscal 是境外的）。

至于其他的向日葵，仍然是允许了国内其他企业访问你的机器。如果密码一旦泄漏，或者第三方有漏洞（参考宝塔面板事件），你的机器则会变成公司内部的肉鸡，进而将整个公司内网搞瘫痪。

请找你们的 IT 部门确认方案。

我对产品本身没什么兴趣，但是对维护、搭建这个产品有兴趣。。。

（我是 ops ）

linux nvdia 驱动装了么？是说 nvdia-smi 识别不到第二张卡还是系统的 lspci 也没有？

@8355 哦哦，我们倒是无所谓，不存在掉链子什么的，没来就没来了。

@lshero #10 经常见，无所谓。

@DejavuMoe #16 一个是自建的 SLA 达不到，而邮箱又是个关键的服务，哪天掉了影响很大；另一个是邮件在很多时候都可以用来当作证据的，但如果这服务是你自己搭的，那么就没办法作为证据了。

谁家好人 linux 用中文呀。。（ bushi ）

对于 k8s 和 docker ，发展过程大致是这样的：

1. 起初，dev 编写代码，编译成可执行程序传给 ops ，然后 ops 手动将程序 scp 上传至 Linux 服务器，并且安装所需的各种依赖环境，比如 jdk 1.7, nodejs 14 。对于一台新上线的机器，程序要部署上去还得考虑什么运行用户组、文件夹权限等问题。更恶心的在于，app A 的运行依赖 jdk1.7,app B 依赖 jdk 1.8,两者有冲突，得想办法解冲突。

2. 后来人们想，我们需要一种方式，把某个 app 和它运行所需要的环境全部打包起来，和外部隔离，这样不管里面要 jdk 1.7 还是 1.8,都能跑在任意 linux 环境中。于是，docker 诞生了，他不但做到了环境的隔离，还实现了环境的精简，——如果某个 app 只依赖 jdk1.7,那么这个 image 中只有 jdk1.7 这个依赖，其他什么都没有。

3. docker 发展到一定程度后人们发现，很多时候一套系统会依赖多个 container,比如前端一个容器，后端一个容器，还有个 mysql 数据库。此时，docker compose 诞生了，他可以让你在机器内部虚空创建一个网络，将这三个容器放在同一内部网络下连接在一起，运行时只需要 docker compose up 就可以启动一组 app.

4. 当 docker compose 里面的容器足够多且功能完善，比如，有的提供存储服务，有的提供监控服务，有的提供网络服务。那么此时，compose 的这些 app 内部，形成了一个功能完善的自治系统，内部和外部完全没关系。但遇到了另一个麻烦，这些儿容器太多了，compose 已经乱如麻绳了，此时 k8s 出现了。

5. k8s 的内部就是由多个容器为基础，组成的一个独立的自治系统，并且具有高可用、分布式等各种特点。需要 nfs ？ pod 来提供；需要 metrics ？ sidecar 进去监控每一个 pod ；你可以通过 yaml 文件定义各种配置，比如哪个 app 需要运行在所有节点上，比如 prometheus ；也可以定义 app A 和 B 跑在不同节点上，比如数据服务和业务；之前在 compose 的各种环境变量都可以放入 configmap 的一种 yaml 里，从这里加载进去。需要 ssl 证书也可以起个 k8s 版的 cerbot,给内部所有的 app 共享这个证书。

---

对于 devops：

devops 是用来解决传统开发模式上 dev 和运维协作问题的，比如 dev 开发完代码，本地编译，部署到生产环境。devops 将这一系列操作用 pipeline 连接起来，标准化的同时解决了安全性问题（比如谁手欠改错环境了。。。）


对于上面的 k8s 阶段，意味着会产生大量的 image,这些 image 有些是后端，有些是中间件，有些是前端。一个完整的对外服务可能后面有十来个微服务来提供的。此时如果再按照传统模式手动编译、制作 image 、上传到 harbor （自建的 docker hub ）太麻烦了，根本来不及。

此时 pipeline 派上用场了，比如 jenkins ，和 github 对接，当某个 pr 合并后，自动触发 jenkins pipeline 启动这个流程，他会按照你定义的流程去打包并分发这个 image. devops 就是去用来实现这个流程的。

试试安装一个新版本微信

https://chromewebstore.google.com/detail/ai-exporter-save-chatgpt/kagjkiiecagemklhmhkabbalfpbianbe

已经有了，并且不只支持 gemini 和 md 这一种。这个插件 4.7 评分，是经过认证的。

“之前有一段时间甚至出现过在跟别人实时聊天，已打开微信的具体的某个聊天界面，但发消息和收消息都延迟”

我感觉可能是你黑域把系统的某些进程干掉了，而微信消息是走 oppo 服务器发送消息的，手机端也是靠内置的某些服务去接受，所以才会导致你这个问题

@vonfry ＃ 27 没有 bot 。树莓派配置一般是 4-8gb 内存，已经很高了。对于 dmit 这种 cn2gia 线路的机器，cpu 是 9004 或者 9005,但内存只有 1gb.

@Honye signal 貌似要求自己编译客户端？不像 matrix 那样可以官方 app 填写其他地址

@yxhyw1799 不算低，1c1g 不够，需要 2c2g,他是微服务，会有超级多的组件。

我有很多的自部署服务，包括 cloudreve ，、wiki 、immich 、etc.

唯一不敢自部署的就是邮箱服务。

cdn ？

各位，不如试试把系统换成原生 ubuntu 如何？