有的问题思考起来别太情绪化
现在离婚难本质上是政府面对传统小家庭（虽然中国传统小家庭诞生历史也才不过几十年）的瓦解，恐慌性地试图增加婚姻的退出门槛来阻止小家庭瓦解罢了。和维稳没多大关系（当然你硬要把它归类为广义的“维稳”那也行）
但是时代的进程是无法阻止的，很多时候最终证明政府越是逆着潮流干，就越会加速这种趋势。就现在中国这版本更新速度，我认为不出十年小家庭就要瓦解得差不多了。到时候自然政府和躺平放弃

至于发达国家为什么离婚不难，那是因为欧美它们早就干过妄图增加离婚难度来遏制传统婚姻瓦解的事了。最终结果是他们完全失败。最终我们看到的就是现在欧美现在的婚姻观念。而不用多怀疑，欧美虽然版本太新我们追不上，但日本现在的版本我们估计十年内就能追上了

有的问题你得先问是不是,OK?别上来就预设结论

隐形守护者才几年你就忘了?

wslg 的那窗口难用的一批，用过一次就懒得碰了，所以我直接禁用 wslg ，然后在 wsl2 里装 xserver 然后配合 VcXsrv 就好了，这样是体验最好的，我已经这样主力开发好几年了，没有任何大问题


随便找了个教程，这是 wsl 的，
https://zhuanlan.zhihu.com/p/128507562

对于 wsl2 设置 DISPLAY 变量的时候需要指定宿主的 ip ，我用的这个
export DISPLAY=$(ip route | grep default | awk '{print $3}'):0.0

这类播放软件分专辑不是看在不在一个文件夹下，而是看音乐的元数据的
分裂成两张往往是因为专辑标题不同或者专辑的 performaer 之类的信息设置设 or 不同，导致软件将其分成了两张专辑

比如你第 1 第 2 张图很明显专辑名都不一样

生产环境一律用 aws fargate 后端的 ecs ，主要是真简单，而不用去折腾 k8s 那堆东西。现在更是生产环境能用 lamda 就用 lamda ，连 ecs 都不想折腾了
我个人反倒有个 k3s 集群管理各种 vps

@tamshy 近视从来都和睫状肌调节能力没关系，睫状肌调节最多导致可以恢复的假性近视。你对近视的理解过于陈旧了

kindle scribe 啊
倒不是护眼什么的，毕竟小孩近视和用不用电子产品关系不大
主要还是 kindle scribe 它只能看 pdf ，而不需要你新办法和孩子斗智斗勇

我反倒更加好奇哪个有点发展水平的国家办宽带是不用实名的？🤦‍♂️

「宽带只能上网也没办法干什么」这句我希望能入选 V2EX 年度名言

2025 年了，copilot 也更新 agent 模式了，上面很多老哥估计早在 copilot 模式之前就迁移到 cursor 导致对 copilot 的认知非常旧

但是，当然 copilot 的 agent 你说和 cursor 那样好用那的确没有，主要是它上下文不够长，但智能程度也够用了，我最近用 copilot 的 agent 模式开发了 n 个项目，没有你们想得那么不堪，主要是 copilot 价格是真便宜啊

熊猫蛋白粉的黑糖牛奶口味，谁喝谁知道，t0 级别的味道
但可惜国内没得卖。。。。。

@murmur 我只是吐槽买整机也能叫 DIY 的没有吐槽价格。说到价格买配件只看龟东贵了也正常。而且，羊毛出在羊身上，真以为整机便宜的地方就只便宜在散片上么

头一次听说买整机的也能称 DIY 主机

新手总要氧化几个头才能熟练的
烙铁头你得时刻保持沾焊锡在上面防止干烧，然后每放一段时间就要用海绵等去掉之前上在烙铁头上的氧化焊锡再上新的。长时间不用还要把温度调低
这些操作都很细碎的

还有上面还多人没想到（跟没有相关经验也有关）的一点，电商这东西作为一个通用的平台，为了兼顾各种复杂奇怪的业务逻辑，存储各种千奇百怪的商品信息等，整个系统的性能其实没你想得那么好，尤其在当年云服务概念都没的时代
这方面稍微做过通用 cms 的人都能明白。一个依赖 rds 的 cms 系统，你要追求通用性那么必定要牺牲性能，要性能通用性必定做不好。我曾写过一个完全基于 mysql 的通用 cms ，通用是真通用，但纯 sql 查询那性能差也是真差

每年年末商战庞大的流量加上业务逻辑复杂的一批还性能不高的系统，结果就是亚马逊那可不得死命堆机器么。而且堆的机器数量还要比其他行业更多，然后年底商战一结束这些又用不上了。这才是为什么电商平台容易出云平台

@drymonfidelia 商品详情能缓存，用户的下单付款请求这些也能缓存？而且电商在整个 sale 期间都要承受一直不降低的超高流量，同时在这些基础上还要加上各种商品品牌不间断的抢购流量等等等等。电商平台本来就业务逻辑极其复杂，怎么可能是 Google 微软这些当年在线业务相对简单的厂商能比的