父母把你养到这么大已经很不容易了吧？他们没有必须帮你买房的法律义务，他们愿意提供经济支持更多是出于爱和情感上的考虑，而不该被视为一种理所当然的责任。 源贴 https://www.v2ex.com/t/1083248#reply64

动机 最近在开发 WebRTC 服务，但是浏览器只允许本机 ip 和 https 域名开启 WebRTC 服务，因此难以在局域网内进行真机调试。 如果有个本地 https 调试服务就好了，但是自己生成证书安装很麻烦，而且不适用于移动端。 所以就想，如果搭建一个能解析到任意本地地址的 https 域名服务，也许能帮助到与我有同样困境的人（也许有吧！） 实现 域名方面，打算注册一个域名（如 localhttps.top 或者 httpsdns.top ），有无更好的域名建议？ 局域网 IP 段主要有以下网段： 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 楼主认为可行的操作形式是： 用户首先通过 cli 或者网页登记，然后得到 usr 识别码和 *.usr.localhttps.top 的泛域名证书（识别码是为了预防潜在的滥用行为）。 用户访问 xxx-xxx-xxx-xxx.usr.localhttps.top，DNS 服务器将自动解析到对应的局域网 IP ，如 xxx.xxx.xxx.xxx 。 将所有局域网 IP 段填充到 DNS 解析中并不现实，因此想到了两种解决方案： 通过 namesilo 的 DNS API 实时登记请求解析的 IP 。 搭建自己的 NameServer （如 ns1.localhttps.top），实现自动解析和权鉴。 手动管理证书是及其不健康的，楼主的主要工作语言是 Python 和 NodeJS ，计划开发能自动下载证书、提供证书、维护证书的包。 疑问 是否有更好的方法？ 请问这套流程是否可行？ 如果可行，这套流程是否有安全漏洞？ 最重要的，大家认为这套系统有必要存在吗？ 欢迎任何建议！

之前写的一个项目服务器被攻击了，想到了一个思路，不知道是否可行。 项目有个前端有个 java 后端。我可以把前端部署到服务器 A ，后端部署服务器 B 。我在前端服务器 A 上反代我后端的接口地址，然后前端项目里的后端地址填我的反代地址。 如果服务器 A 被攻击了，那我就换个前端服务器 C 域名再套上 cf ，虽然减速了，但是至少部分人还能用。对吧

Anaconda3 导航器 界面 Navigator,可不可以汉化，或者设置为中文？ https://pic.imgdb.cn/item/6719f38ad29ded1a8cbd9617.png

一个是电话访问机器人，就是根据客户列表挨个打电话，根据预设的脚本提问，用按键接受客户的反馈。然后把所有客户的反馈记录下来形成一张报表。 二是一个微信机器人，客户和服务人员的群聊把这个机器人拉进去，机器人就可以基于预设的 Q&A 回答客户提出的一些常见问题。 感觉这两个功能应该是比较常见的，应该有现成的轮子吧？ 有大佬指点一下吗？

来源： https://lwn.net/Articles/995186/ 日前，Linux 内核主要维护者之一 Greg Kroah-Hartman (Greg K-H) 提交了一项不寻常的“文档”更新，将数名具有 <.ru> 顶级域名邮箱的维护者，和一名明确为俄罗斯身份的维护者从 MAINTAINERS （维护者名录）文件除名。 这一提交已于上周日被 Linus Torvalds 拉取并包含于 6.12-rc4 版本的代码中。 Greg K-H 并未详述这项更新的具体原因，仅含糊其辞地表示该更改是“由于某些合规性要求”，并指出“（相关人员）提供充足文档后，方可回归（维护者名录）”。 相关的维护者移除方式相当暴力，其中部分子系统由于唯一维护者使用 <.ru> 顶级域名邮箱，整个子系统都被从 MAINTAINERS 文件中移除，这之中不乏诸如 UFS 文件系统和 PPTP 驱动等重要且被广泛使用的子系统。由于 Linux 内核开发流程完全基于邮件列表进行，当 MAINTAINERS 文件中移除相关维护者后，也就意味着与相关子系统的补丁或沟通将不再被发送至维护者的邮箱，乃至相关的邮件列表。这很可能会造成许多补丁“石沉大海”；而如果某个子系统未得到充分维护，那么其被从内核中移除也只是时间问题了。 通常而言，Linux 内核补丁除了发送至邮件列表外，还需要抄送与之相关的人士（如子系统维护者和活跃贡献者），并且经过讨论和审阅后才会被拉取合并。然而，Greg K-H 似乎刻意绕过了这部分流程，仅仅将补丁发送至流量最大、几乎不会有人认真阅读每封邮件的 patches@lists.linux.dev 列表，并于仅仅两天后就向 Linus Torvalds 发起拉取请求，而 Torvalds 亦未对相关修改提出质疑和意见便拉取合并这笔更改了。 考虑到 Linus Torvalds 与 Gre...

讨论一个问题，是否要在局域网中使用真实 IPv6 地址？ 所谓真实 IPv6 地址，比如运营商 PD 给我 2001:db8:aaaa::/60 ，下游可以从路由器得到 2001:db8:aaaa::1234:5678:9abc:def0/64 （通过 slaac 或者 dhcpv6 ）的地址。 所以现实考虑，如果启用 IPv6 的话，下发的地址有以下几种： a. 真实 IPv6 地址。如前所述。 　　隐私有问题。 　　容易被 P2P 利用。 　　在复杂的网络中实现稍有困难。 b. fd 开头的地址。 　　可能会被认为没有 IPv6 连接，或者优先使用 IPv4 。 　　需要 SNPT/DNPT 或者 IPMAP 。 　　对于 DDNS 等场景，可能需要单独获取 IPv6 地址，通过外部接口或者计算。 c. 随便偷一段公网，比如 2b2b:250::/64 。 　　不标准。 　　其他同(b)。 各位是如何选择的，有什么想法？ p.s. 当然还有其他的方案，这里就不拿出来说了，如 d. 关掉立刻解决烦恼 e. nat66 才是最 666 的

经常出现感叹号⚠️ 连接 smtp 服务器失败 平时就用 outlook gmail icloud 感觉 gmail 连接还算正常、icloud 出现的最多 代理正常开启、不知道怎么搞的 出现⚠️的时候基本上重新连接都会失败、可是退出 APP 再重新打开又能正常连接