1989年Steve Jobs试图从Apple把David Nagy挖到NeXT时开出的offer letter（最后没挖到）。帮主认为这是「insanely great offer」（经通胀调整后$80,000大约相当于今天的$200,000）。
当事人并未接受此offer，这封信于去年以$27k的价格卖出。
不过帮主居然用了三个叹号，并且在第一个叹号前加了空格这件事，实在是让人觉得如鲠在喉啊。
当事人并未接受此offer，这封信于去年以$27k的价格卖出。
不过帮主居然用了三个叹号，并且在第一个叹号前加了空格这件事，实在是让人觉得如鲠在喉啊。
收到邮件通知，我目前的YouTube Red的老爷爷套餐即将消失，一口气涨40%，统一到YouTube Premium了，年付费折扣只能用于individual plan且需要手工renew，真是 #地主家也没有余粮 了啊
老刘家烤鱼烤串连锁店。位于Milpitas李连贵遗址。 550 Barber Ln, Milpitas, CA 95035
这是一家新开的店，现在还在soft opening。测试了烤清江鱼（十三香），味道不错。堂食可使用信用卡NFC结账。
因为特意点的不辣的版本，因此单要了一份辣椒粉，很辣，辣到我一个从小吃川菜的觉得辣的地步，慎用。
店主可能是周杰伦粉丝，不过门口音响的音量略大，选择座位时建议选一个靠里的位置。
https://maps.app.goo.gl/BSsxpnh8YWfrt96NA
#吃啥 #南湾
这是一家新开的店，现在还在soft opening。测试了烤清江鱼（十三香），味道不错。堂食可使用信用卡NFC结账。
因为特意点的不辣的版本，因此单要了一份辣椒粉，很辣，辣到我一个从小吃川菜的觉得辣的地步，慎用。
店主可能是周杰伦粉丝，不过门口音响的音量略大，选择座位时建议选一个靠里的位置。
https://maps.app.goo.gl/BSsxpnh8YWfrt96NA
#吃啥 #南湾
Liu Roast Fish 老劉家烤鱼烤串 · 3.7★(85) · Chinese restaurant
550 Barber Ln, Milpitas, CA 95035
今天份的自己挖坑自己跳：
两个月前我家的路由器突然挂掉了，原来的机器用的是一张超微的主板，处理器是Intel Atom C2358，从现象上来看大概率是中了C2000系列LPC的信号衰竭问题，琢磨已经用了多年了，索性换一台新的，于是订了一套基于Atom C3758的系统，这次用了NVMe。
出现故障当天，我趁着早上上班前的时间画了一个小时把家里的NAS上的系统稍微改了改来跑网关服务。这套系统因为是临时放上去的，因此弄得也比较潦草。
这段时间一直非常忙，所以新机器到货以后也只是把新机器连到网络上零敲碎打地配置。今天周四，琢磨这都几个星期了不应该再拖了，于是切换了一下。
NAS立即挂掉了，而新的网关则不转发数据。
NAS这边挂掉是因为 https://reviews.freebsd.org/D41154 ，虽然这一变动很快revert了但我不幸抽中了这张彩票。
网关这边的问题则更令人头秃。tcpdump发现只有VLAN parent（VLAN设备所在的物理网卡）上能看到流量，这些以太网帧可以看到包含了802.1Q tag，但对应的VLAN设备上看不到任何流量，更不要说其上的网桥设备了。
我家的网络采用了许多VLAN，同时为了支持多个AP，这些VLAN又接了三组网桥。这样在ifconfig里看到的是数十个物理的和虚拟的接口。由于采用的结构是物理网卡上创建若干vlan虚拟设备，然后再把同一个vlan id的虚拟设备加到一个网桥上，最后把IP地址指定到网桥上，因此这个结构改起来相当麻烦，而网络断了又只能插上键盘显示器在旁边调而不太容易查资料，听包时滚动的又比较快，因此只能写到文件里再tcpdump -r。
寻找了若干可能的原因，甚至连网卡的VLAN硬件加速都关闭了一圈依然没什么变化。曾经怀疑过网桥的实现有问题，但git log -p看看最近的变动基本上都是很正常的bug修正。
而NAS上因为运行了primary DNS因此也不能停机太久，最后只好逐个比对新旧配置文件（为了避免把历史包袱也搬到新机器上，我大致上是按照旧的配置的样式按新的最佳实践重新搞了一套），最后总算发现了原因：旧系统的配置中有一组ipv4_addrs_igbX.Y="up", 而新系统只是启用了物理网卡。
严格来讲这个写法是不太对的，但最终它会导致一次ifconfig igbX.Y up。这样一来就很容易修了。
最后果然是vlan设备没做ifconfig up导致的🤦
修好网关以后下载了一份mini memstick（手头的13.2-R无法挂载NAS的CURRENT存储池），把引导的存储池挂上，替换掉kernel，总算是修好了。再一看表已经凌晨一点半了。
总结教训：
1. 不要在睡前上线系统。这次有相当多的时间是用在了通过测试验证FreeBSD的实现是不是有问题，而不是按照传统的逐层排查的方法，走了一些弯路。如果将系统直接削至最简状态然后逐层启动并在每一层验证状态是否符合预期，预料会很快发现vlan设备位启动这样的问题。
2. 确保系统上的备份内核足够新。这次kernel.old是坏的，而上次备份的kernel.good是半年多以前的，也不支持新的存储池。kernel.good应该在uptime达到7天时由正在运行的内核提拔上来，而不是手工进行。
3. 预案不足。NAS运行的是CURRENT，而手头的U盘没有及时更新。NAS突然无法启动增加了解决问题的精神压力，因为这把回滚的路也给堵上了一块大石头。
4. 家里现有的网络拓扑过于复杂，简化它是势在必行的了。看看最近这段忙过了再来吧。
两个月前我家的路由器突然挂掉了，原来的机器用的是一张超微的主板，处理器是Intel Atom C2358，从现象上来看大概率是中了C2000系列LPC的信号衰竭问题，琢磨已经用了多年了，索性换一台新的，于是订了一套基于Atom C3758的系统，这次用了NVMe。
出现故障当天，我趁着早上上班前的时间画了一个小时把家里的NAS上的系统稍微改了改来跑网关服务。这套系统因为是临时放上去的，因此弄得也比较潦草。
这段时间一直非常忙，所以新机器到货以后也只是把新机器连到网络上零敲碎打地配置。今天周四，琢磨这都几个星期了不应该再拖了，于是切换了一下。
NAS立即挂掉了，而新的网关则不转发数据。
NAS这边挂掉是因为 https://reviews.freebsd.org/D41154 ，虽然这一变动很快revert了但我不幸抽中了这张彩票。
网关这边的问题则更令人头秃。tcpdump发现只有VLAN parent（VLAN设备所在的物理网卡）上能看到流量，这些以太网帧可以看到包含了802.1Q tag，但对应的VLAN设备上看不到任何流量，更不要说其上的网桥设备了。
我家的网络采用了许多VLAN，同时为了支持多个AP，这些VLAN又接了三组网桥。这样在ifconfig里看到的是数十个物理的和虚拟的接口。由于采用的结构是物理网卡上创建若干vlan虚拟设备，然后再把同一个vlan id的虚拟设备加到一个网桥上，最后把IP地址指定到网桥上，因此这个结构改起来相当麻烦，而网络断了又只能插上键盘显示器在旁边调而不太容易查资料，听包时滚动的又比较快，因此只能写到文件里再tcpdump -r。
寻找了若干可能的原因，甚至连网卡的VLAN硬件加速都关闭了一圈依然没什么变化。曾经怀疑过网桥的实现有问题，但git log -p看看最近的变动基本上都是很正常的bug修正。
而NAS上因为运行了primary DNS因此也不能停机太久，最后只好逐个比对新旧配置文件（为了避免把历史包袱也搬到新机器上，我大致上是按照旧的配置的样式按新的最佳实践重新搞了一套），最后总算发现了原因：旧系统的配置中有一组ipv4_addrs_igbX.Y="up", 而新系统只是启用了物理网卡。
严格来讲这个写法是不太对的，但最终它会导致一次ifconfig igbX.Y up。这样一来就很容易修了。
最后果然是vlan设备没做ifconfig up导致的🤦
修好网关以后下载了一份mini memstick（手头的13.2-R无法挂载NAS的CURRENT存储池），把引导的存储池挂上，替换掉kernel，总算是修好了。再一看表已经凌晨一点半了。
总结教训：
1. 不要在睡前上线系统。这次有相当多的时间是用在了通过测试验证FreeBSD的实现是不是有问题，而不是按照传统的逐层排查的方法，走了一些弯路。如果将系统直接削至最简状态然后逐层启动并在每一层验证状态是否符合预期，预料会很快发现vlan设备位启动这样的问题。
2. 确保系统上的备份内核足够新。这次kernel.old是坏的，而上次备份的kernel.good是半年多以前的，也不支持新的存储池。kernel.good应该在uptime达到7天时由正在运行的内核提拔上来，而不是手工进行。
3. 预案不足。NAS运行的是CURRENT，而手头的U盘没有及时更新。NAS突然无法启动增加了解决问题的精神压力，因为这把回滚的路也给堵上了一块大石头。
4. 家里现有的网络拓扑过于复杂，简化它是势在必行的了。看看最近这段忙过了再来吧。
https://groups.google.com/g/vim_announce/c/tWahca9zkt4
It is with a heavy heart that we have to inform you that Bram Moolenaar passed away on 3 August 2023.
Bram was suffering from a medical condition that progressed quickly over the last few weeks.
It is with a heavy heart that we have to inform you that Bram Moolenaar passed away on 3 August 2023.
Bram was suffering from a medical condition that progressed quickly over the last few weeks.