毕业后就进入一家公司，缺少对社会的基本认知，这个倒是实情。
且不说你一直强调狗屎运拆迁 300W 现金流，仅杭州有房无贷这一点，你怎么敢把自己定位在普通人偏下？让其他站友如何自处？只能吐槽你炫耀了。
人要不断完善自我认知，你一边强调自己不求上进，一边又厌烦当前安逸的环境，这种认知失调，对于人这种不安分的动物来说太常见了。人生旅途有太多这样吃着碗里看着锅里的场景了，35 岁的人应该能理解这更多是一种皮痒了的表现。
严肃的认识自己，到底希望安逸过一生还是希望更刺激充沛的人生体验。35 岁的人应该对眼皮浅、脑子一热的场景有一定的免疫力，应该尝试更长远和更有深度的思考问题。

@xinchao 我的烘干机放在通铺的阳台，使用时有些噪音，另外比较喜欢开窗通风，所以烘干机用了几次就吃灰了。迷瞪团购我主要买的实木家具，优惠力度和渠道信任度整体上比较合适。

2 年前买过几个大件家电的经验：
- 大家电一般都可以约定半年到一年的发货时间。建议尽早关注各个渠道价格，建立心理价位。没有建立心理价位的话，容易错过合适的下单时机。同时，关注各个渠道是否方便退单，适时锁单。因为都是半年到一年的发货时间，锁单退单都算正常操作。
- 大家电建议线下，或者 PDD 、咸鱼、团购群。JD 的售后服务在大家电品类优势不明显，但价格会高很多。首推线下渠道，信息源一般来自小区业主群，特别是新小区，采购量比较大，会有很多卖场销售特别渠道，优势是可以现场看再预定，正规渠道，有时叠加政府消费券会拿到很低的价格。其它线上渠道价格有优势，但信任度可能需要自行斟酌，一般都不会翻车，但也有被骗的案例。有的团购比如迷瞪，本身就是天猫京东，如果符合预期价位，可以提前锁单，后续有更合适的再退单也比较方便。
- 坐标杭州。烘干机吃灰中，如果没有新风系统，不建议购买。个人觉得烘干机主要有 2 个应用场景，一是应对梅雨天气，二是应对衣物绒毛带来的屋内浮尘。杭州的梅雨天气个人觉得不严重，持续时间也不长。全屋没有安装新风的话就要经常开窗通风，这样屋内浮尘的主要来源就不是衣物绒毛了，烘干机过滤绒毛也就可有可无了。另外，烘干机非常吵，使用时最好有一个可以隔音的环境。

@A01514035 感谢分享。
- 终端使用公共 dns 但仍命中了透明网关的 dns 分流，应该是透明网关劫持了 udp 53 流量，透明网关一般会默认配置。
- macvlan 这个解决方法有点印象，应该就是这样的。使用 docker 本意是尽量降低对宿主机的操作和依赖，有点抗拒这个解决方法。

内网 dns 仍是一个问题，主要有内部 dns 解析重写、终端 dns 请求管控分析、基于域名的分流这 3 个需求，需要探索一个合理的网络拓扑。

最近也在折腾家庭网络，更倾向透明网关的叫法。也用过 macvlan 网络跑 clash 容器，目前暂时用虚拟机跑 dae 做透明网关。折腾起来还是有不少细节：
- 透明网关多了一跳，导致去程和回程路由不一致。有些应用可能会有奇怪问题。
- 内网有自建 dns 服务，希望管控和分析所有终端的 dns 请求。终端的 dns 指向透明网关就无法识别分析了，不指向透明网关就失去了 dns 分流作用，只能基于 IP 分流。另外，为了对抗 dns 污染和泄露，dns 服务器的上游也需要借助透明网关。拓扑上似乎很难梳理通顺。
- 透明网关容器使用 macvlan ，所在宿主机却无法联通透明网关。似乎是 docker iptables 相关的一些配置问题。即如果仅用一台 docker 主机跑所有服务，包括透明网关，宿主机上的其他容器无法简单的使用该透明网关。所以使用独立虚拟机跑透明网关服务也是一个选择，有可能的话，还是希望能把 dns 管控分析和透明网关打包成一个镜像，一键部署。
- PT 下载问题，透明网关场景需要对 PT 下载有一些调整和适配。
- 其他拓扑尝试，有看到把透明网关放到主路由上游的拓扑，即主路由多 wan 上联的逻辑。似乎也可以试试看。

2 年前选型的时候主要关注的是无桶、净水即热分离结构。这种产品迭代挺快的，如果现在选净水即热一体结构，除了常规参数、耗材成本之外，最好留意一下首杯直饮、零陈水相关说明。

能 ping 通是个好现象，可能是 gitlab 本身有 IP 限制。参考官方文档： https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#configure-globally-allowed-ip-address-ranges

另外，私接路由的行为容易招公司网管痛恨。

每个人使用习惯不同，个人体验，海报墙和 kodi 都不好用。电视自带播放器挂 SMB 或 NFS ，直接目录浏览播放最好用。没那么高大上，贵在实用。主要看国内剧集，看完就删，折腾那一套不值当。

这两天刚好在调 MaxRAMPercentage 这个参数，在 JVM 没有 OOM 时 Pods 频繁 OOMKilled ，一般都是 MaxRAMPercentage 配置过高，需要根据自己的场景简单压测一下，目前配置在 65 左右比较合适。

limit 还是要限制一下，配置太大就没意义了，不好计算集群内存超配情况，也增加了不稳定性。超配太多争用的概率就高，驱逐就容易发生。驱逐还有滞后性，很多时候驱逐还没开始，因为节点内存不足，负载就拉上天了，然后就节点瘫了。

其实是个标准定义问题，如果标准是“以我为准”“以我的利益为准”“以我想怎么说怎么说为准”，那就没有双标了。诡辩一说。

网络对喷时，“脑臀分离”是用来攻击别人发表了背叛自己利益的言论，“屁股决定脑袋”是用来攻击别人发表了以自己利益为准的言论。这种怎么说都可以的词汇还是挺多的。词汇使用还是要看场景，看上下文的。

“双标”这个词应该是拿来攻击别人的，不是拿来自省的，OP 似乎用错了地方。

就自省来说，一个合理的标准应该是自洽，符合自己价值观的自洽。不用太关心表面的标准是什么样的，如果不能让你的价值观自洽，就会一直很难受。如果让你自洽的标准在表面上是如此明显的“双标”，要么自省修正，要么表面上包装一下，都算是解决方案。

云服务器有停机不计费，就是停机了计算资源不收费，存储继续计费。但并不影响其它收费模式。
云桌面应该支持按量计费以及停机不计费，但肯定不能取消包年包月，因为从时长单价来看，包年包月肯定比按量便宜的，最终是要看总体成本以及对弹性的需求来选择包月还是按量。

关键词：pull-through cache
官方文档： https://docs.docker.com/docker-hub/mirror/

@Masoud2023 明白了，感谢分享。

@Masoud2023 可能太久没折腾 docker 环境了，请教一下最新的使用 docker 拉取 ghcr.io 仓库镜像的方法。现在已经改一下 JSON 就可以拉取了吗？以前还是要在 daemon 上挂代理才可以。

很久没用了，印象中没有特别好用的。

就拉取镜像来说，docker 的 registry mirror 算不上好的实践。因为仅支持 docker.io ，就算配置了好的 mirror ，gcr\ghcr\mcr\quay 等仓库还是拉取不到。只用 dockerhub 镜像的话应该还能接受。
使用代理是一个选择，但 docker 的代理稍微复杂，要先理清楚 docker client 、docker daemon 、docker container 代理的区别和配置方法。