@ysc3839 上下行不对等，应该就是家宽 pppoe
ipv6 的 ppp 协议是 rfc5072，是在 ipv4 的 pppoe 上进行扩展。可能是因为 ipv6cp 配置比 ncp 复杂太多，我遇到好多局端 ipv6 不限速或者 ipv6 和 ipv4 各自单独限速的案例了。

楼主说的也不是不可能。很多地方的运营商限速落地实施方案是用计费网关。如果 ipv4 和 ipv6 用的不是同一套计费网关，那么确有可能是双倍带宽上限。

没有躺着办公的方案？比久坐和久站都好一些吧。
久站不累颈椎，但是累脚。

这个楼里有些人的建议出发点是投资而不是住房需求。因此他们建议贷最大的额度，买最大的房子，等升值。
这在我看来是一种赌博。虽然按照市场规律来看，一线城市将来一定是升值的。但是房地产和金融受政策影响大，未来如何并不好估计。大城市不会调控人口吗？既然现在能 LPR 改革，难道将来政策不会变吗？

我能接受显式地申请用户信息，比如要求用户填写身份信息，在网页中声明会追踪用户以投放广告（海外网页的 cookie 提醒）。这样起码我透漏出去的信息是已知的、透明的、可控的。
需要防范的就是在用户不知道的情况下偷取隐私。因为这样泄露的隐私是未知的、黑箱的、不可控的。我不知道你都拿了什么信息，也不知道你拿这些信息干什么。比如，为什么要在后台调用摄像头、麦克风？想象一下这些信息被泄露或者卖给黑产、诈骗。他们盗取你的财产、根据你的生活细节设计诈骗。为什么会有人认为偷取隐私是无关紧要的？在社会无所作为的情况下，交流如何自我保护难道不应该吗？

@ThreeBody 我回复的时候还没看到楼主说是新生儿。以为是需要调整节律的幼儿。

我的话，只推荐用公积金贷款。除此以外，都是在给银行送钱。
很多人以为贷款利率是一成不变的，且不说现在已经 lpr 挂钩的，以前的利率也不是固定的啊。以前贷款的可以看看你们的合同，里面对利率的描述肯定是“基准利率打几折”。所以这个利率是有可能会涨的，只要央行点头。银行面对我们普通消费者肯定不会赔本的。如果房贷是一个大羊毛，人人还都能来薅，银行岂不是太冤大头？

@INTEL2333 南方移动的 ipv4 去香港以前是直连，现在是绕路。南方移动的 ipv6 现在是直连香港。不过好像去美国不是走香港。所以也就只比较适合用香港的主机或 cdn

白天不要让他睡。除非你想熬夜。

@nuk 所以，你们认为现代系统应该抛弃 so 、dll 库，崇尚发行更多的静态软件？
（不过刚才去查了一下还真有这种东西，stali 和 suckless，不知道实际体验怎么样）

@cmostuor
动态静态不止是性能的问题，还有可维护性的考虑。主楼我就已经阐述了静态编译的其中一种维护灾难。
那个例子还可以再发散一下，如果当前所使用的静态应用没人维护了。那么它所包含的库的漏洞也就没法修复了。

一个程序只做一件事，可能有人会鄙夷这种 unix 哲学。不过在我看来，这是提升一个信息系统整体鲁棒性、安全性的很好的原则。各司其职可能在执行上效率不是最高的，但是当有问题发生时，能更好地处理。

动态静态其实还有一个授权协议的问题，不过这个问题不是十分紧要，foss 软件一般都不会触犯这个问题。

@hronro 是近几年 cargo 出来后才慢慢改为默认动态编译。不过一大批古早的 rust 项目都还保留着静态编译的习惯没变。甚至我看到很多 rust 教程都会教人改成静态编译，理由是“没有依赖的问题”。

@terence4444 我查了一下移动在上海有光缆出口，那么可能上海移动的 ipv6 不是直连 cmhk，不过我还是建议试一试。

@terence4444 有没有试过 ipv6 出国？南方移动 ipv6 出国有时候比国内跨网还快。
我没试过北方移动，不知道是不是也是 cmi 出口。

不过虽然动态编译 helloworld 只有 16kb，但是动态链接编译 go 标准库有 32mb 大小。如果应用少的话，可能还不如静态编译应用省空间。
http://z-rui.github.io/post/2016/07/golang-shared-library/
不知道有没有分模块编译动态库的方式，类似 python 那样。

@CrazyBoyFeng 我查到 go 已经有动态链接编译的模式了，出来的 helloworld 只有 22kb，但是因为 go 几乎没有二进制依赖库管理机制，至今极难面向用户推行这种模式。

减少体积这条现在意义不大，-s 和-w 参数能省的空间并不多。比较有效的就是 upx，但在启动时解压缩会多消耗 cpu 和内存。
不知道 golang 官方有没有出动态链接编译的计划。搭配发行 runtime environment 或者发行模块化动态链接库。做到一库多用。只有这样才能节省硬盘和内存。不过如此一来，就需要处理依赖问题。
现在这样静态编译挺不适合低端硬件的嵌入式编程的。ram 和 rom 都较小的情况下，一库多用才是经济合理的。

这是工信部信通院的分析报告： http://www.caict.ac.cn/kxyj/qwfb/bps/201912/P020191219401564573602.pdf
> 测试发现某些产品上传用户在该 APP 的任何操作、用户详细地理位置以及用户同音箱的详细对话内容。

音箱偷听这难道还有疑问？它肯定无时无刻都在录音啊，否则咋知道有人唤醒它。
至于监听，这内部的事谁能确切知道。代码不公开，数据加密了。但我倾向于认为资本都是 evil 的。
它能匹配指令的前提是，它已经把录到的话语都转换成了文字，然后才能判断是否匹配关键词。也就是说它已经记录了你的日常话语，上不上传全看厂商的操守。
连亚马逊都靠不住，都能看到“监听”的新闻。