@Love4Taylor 这个不错，要是能显示实时 IO 就更好了。

@ipwx 给用户部署的话当然是单程序集成了更“容易”。IPC 具体要看情况，比如给一个服务实现一个动态加载配置文件的 post 接口，直接把内容写到配置文件然后 SIGHUP 就可以；比如给 redis-server 实现统计 API ，直接用 redis client 就可以；比如给内核模块写个监控 API ，暴露个 procfs 就可以；再比如写个运维面板，和 systemd 等服务直接通过 dbus 就可以。总之很多情况，用 signal 、文件、pipe 、socket 等简单方式，或易集成的或已有的专用协议、rpc 、message pass 等，都可以避免在主程序中引入 Web 相关的一系列复杂度的前提下满足需求。

@hutoer return 和 throw 是不同的控制流，需要用不同的方式处理，但本质上都是返回数据给调用方，无论通过 return 还是 throw 。实际“返回”的数据类型是不一样的。
如果签名写了 ParseError ，自然是表明该函数只可能返回这一种错误类型，如果还可以返回其他类型那自然要写成所有可能类型的 super type ，这个和 checked exception 本质是一样的。
参数个数不一样可以用 vararg ，或者包装到一个 collection literal 里，或者写成 macro 。如果只需要几种特定数量的参数，可以分别写成 add2 、add3 等不同函数，比起导致的问题重载并不能提供足够的好处。

@hutoer 上面没打完，constructor 没有提供额外的好处，限制了初始化函数的命名（这也是需要重载的一个主要原因），不能为不同的情况使用不同有意义的命名。至于命名有静态检查，并且一般都有特定的 convention,没什么混乱的。另外不要只从 OOP 的角度观察，简单的函数其实更好理解。

@hutoer 异常只不过是一种不同的控制流，返回 Color throws ParseError 和返回 Result<Color,ParseError>本质上是一样的，都是返回数据，而这两者返回的数据“类型不同”。

你这个例子是完全可以用泛型的：
fn add<A: IAddable<Output=A>>(a:A,b:A,c:A)->A{

}

要想从网页发送 intent 拉起 activity 话，需要对应的 activity 注册了 intent filter 。比如说打开特定的链接地址、URL scheme 等。

@hutoer 因为后者可能会失败。粗略地说，前者返回 Color ，后者返回 Color | ParseError 。异常的语言可能会隐藏这一点，但用了 checked exception 同样可以体现出来。
泛型就是达到“重载”的效果最合适的方式，泛型代替不了重载的地方就不该用重载。

constructor 完全是多余的复杂度，这个概念根本就没有必要。new FancyClassName(params) 比 FancyClassName.new(params) 没有任何优势。反而让代码难读又难写。如：
FancyClassName FancyClassName::FancyClassName(params){
blabla...
}

@Maskeney 这是没办法的事情，某国人的自我审查已经深入骨髓、无处不在了。使用 adghome 等能够容易地加白的客户端，遇到被“误杀”的手动加白就是了。
另外这些内容还是有积极意义的，因为审查的无处不在，很多代理提供商也在做同样的事。本机屏蔽这些内容可以防止“非法”流量的泄漏导致封号或记录到日志里日后拉清单。需要访问的话戴 Tor ，这样也能最大程度确保人身安全。

@hutoer go 的 make 只是缺乏泛型的 trick ，没啥好说的。
另外不要被 OOP 荼毒太深，constructor 本身就是糟粕，可读性简洁性都不如直接用函数。
Color::from_rgb(u8,u8,u8)和 Color::from_hex(String)返回类型都不一样，后者是可失败的（虽然在异常的语言中被隐藏了），难道该用同一个名字吗？
另外就算需要所谓的“重载”效果，用泛型是更好的选择。Color::from<T: Into<Color>>(t:T)->Color 甚至比你写多个重载的函数更“OOP”。

@ipwx CGI 启动的进程当然不是 damon 主程序，这还用说吗，需要啥数据通过 IPC 拿。关键是这样能把 Web 相关的一系列复杂度都抽离出去，程序里不用引入协议、路由、tls 等等一堆东西，每连接一个进程也不用关心锁、内存泄漏等问题。这个库看起来“容易”并不代表“简单”，依赖庞大，出了问题 backtrace 加长一截，都是不必要的复杂度。
至于 nginx 那些怎么能一概而论，我回复的一直都是“碰巧有一个 c/cpp 服务需要暴露简单的 HTTP API”这个问题，像是提供 metrics 统计信息、提供 API 给前端面板等简单需求，不值当引入这些复杂度。

照着官方的示例文件改就行了，注释很丰富。
https://git.samba.org/samba.git/?p=samba.git;a=blob_plain;f=examples/smb.conf.default;hb=HEAD
用户需要手动添加。

@qingzhan 提示 lla 地址没有路由的话，那就是链路层问题了，看一下 neighbor discovery table 。

@qingzhan 如果网关地址不是 lla （ fe80 开头），那检查是否有到该地址的路由。如果是 lla ，那就是本机防火墙之类的问题，换设备或抓包排查。

btrfs send

@qingzhan 你要从本机 traceroute 而不是从光猫上。光猫上通而你本机不通显然正符合我上面说的本机的问题。
那两个一个是路由器通过 slaac 获得的单个地址，一个是通过 dhcp-pd 获得的地址段。（光猫拨号时光猫===光猫+路由器）
@jousca 前缀变不变是运营商决定的，至于后缀，其实你用 slaac eui64 或 stable address 得到的后缀也是固定的。不过 dhcpv6 的作用就是配置 managed address ，通常手动设定，自动分配不变可能是光猫缓存了记录，或设备加入网络的顺序恰好相同。

@jousca 包括你图里的在内，国内家宽的策略基本都是一样的：PPPoE 拨号建立虚拟链路，在该链路上存在 ra slaac （你的路由器 /光猫自身可以通过 ra 获得一个地址）和 dhcp-pd 服务，你的路由器 /光猫可以通过该服务取得一个至少 /64 的地址段，然后通过 ra slaac 或 dhcpv6 向下分配。如果地址段大于 /64 ，可以继续运行 dhcp-pd 服务向更下级路由分配地址段。
另外你改 dhcpv6 分配的地址段其实没啥意义，因为 slaac 总是会无状态地设置地址，如果要禁用 slaac 仅使用有状态 dhcpv6 的话，一般路由器 /光猫和 Android 系统的手机都不支持。

@qingzhan 按照我说的顺序排查。直接 ping 地址而非域名通不通？不通的话再查路由，ping 网关地址通不通？通的话说明是外部问题，不通那就是你内网 /本机的问题。