#吃啥 #MTV #乌冬面 麦藏 Udon Mugizo
(650) 961-8880
https://goo.gl/maps/WQs3AFTr6Cq9LLFm9

地址 180 Castro St, Mountain View, CA 94041

点餐地址 https://www.mugizo-us.com/mountainview

可堂食或外带。

汤明显不是那种常见的用酱油强行勾兑的，用料很足。味道正宗。

点餐系统支持ApplePay。

我刚才琢磨半天HIL REN是什么，为什么需要have adult supervision，再仔细一看原来是CHILDREN被熊孩子抠掉了C和D。

提醒本频道在美国并且使用 TurboTax Premier 报税的读者注意：Amazon现在有一项 Amazon $10礼卡bundle活动，总价为 $54.98（建议配合 Chase Amazon 或 Discover 卡使用）。该优惠活动是因应 Costco 今天开始的减价（件号 1605024 ），但价格便宜 $0.01 并且附送一张 $10 的 Amazon 礼卡。

https://smile.amazon.com/TurboTax-Premier-Exclusive-Software-Download/dp/B09L5SMFX2?th=1

注意并非推荐该特定产品；对于更简单或更复杂的报税问题可能需要使用其他产品或咨询CPA。

后续：

截至2021年12月30日为止，相关医疗服务已处理完5笔理赔申请（其中4笔为网外费用，但由于属于急诊的预授权服务因此按网内理赔，这些费用按最终理赔金额从多到少的顺序分别是麻醉师、手术医师，以及病理实验室对血样和鼻拭子的化验费用；1笔为网内费用，来自急诊室的消化内科医师）。

由于输液、各类X光、核磁共振、B超、住院等服务仍未在保险公司理赔中体现，因此目测还将有后续的理赔申请。

目前为止医疗机构及医师共请款合计 $9,139.00，保险公司砍价$6,723.06，保险公司共支付$2,415.94。

网内的消化内科医师的费用报销率较高（接近80%），并且处理迅速。
手术医师的报销率不到25%。
麻醉师的报销率略高于26%。
病理实验室的化验服务报销率很低，仅仅8%强。

Good bye, 2021

激动人心的时刻到了！本次医院请款金额为十四万三千六百九十六美元五十五美分。保险砍价后的价格我将在保险系统数据出来之后追踪报道。

最终保险认可了 $18,274.00 的费用。

医院的账单分了20项，包括了住院、手术室、急诊室、急诊药物、药房、B超、静脉注射、医用手术器材、麻醉（这个和之前已经理赔的麻醉师费用有所重复，不知道具体是什么）、一系列化验（和之前已经完成理赔的重复）、胸透、心电图、无菌耗材、核磁共振检查、恢复室的费用。其中最多的三项分别是手术室 $25,327.00，无菌耗材 $21,909.00 和 住院费用 $14,886.00。

保险公司大笔一挥，删掉了其中的19项，把余下的一项（借用了住院费用的位置）价格从 $14,886.00 改为 $18,274.00，完成了理赔。

目前为止，包括手术医师、麻醉医师、病房消化内科医师、化验，以及医院产生的费用，保险总共实际认可了 $20,934.17（相关医疗人员总共请款$154,226.55）。预计还会有一个拆钉费用，但应该不会太贵（这是在门诊进行的，实际花费了一位外科医师助理几分钟的时间）。

https://lists.freebsd.org/archives/freebsd-net/2022-January/001203.html

TL;DR: 每个TIME_WAIT状态的TCP连接的内存消耗将从496字节（压缩状态）增加到1488字节（完整socket），好处是每socket生命周期内永久性地少一次分配/释放、同时inpcb不再包含只用于TCP的数据，这会让非TCP socket使用的内核内存减少，并简化相关的代码。

目前的TIME_WAIT压缩状态是2003年由DARPA/NAI Labs赞助，由jlemon@实现的。当时32位的i386架构的内核地址空间只有2GB，而当时配备4GB内存的服务器还不多见，而内存在现时已经不再是一个严重的问题。

此外，通过减少MSL（net.inet.tcp.msl）也可以缩短TIME_WAIT的时间（2倍MSL，这是 RFC 793 section 3.5要求的；更详细的解释在 RFC 1122 Section 4.2.2.13)，从而减少TIME_WAIT状态的TCP socket数量来达到减少内存占用的目的。

我个人的服务器通常将MSL设置为5秒(系统默认值为30秒，注意这个值需要*hz)。注意这个值太小会导致延迟较大的网络无法建立TCP连接。早期RFC定义的120秒是拍脑门定的，*BSD以及后来的其他系统默认的30秒这个值其实仍然是拍脑门定的（这个脑门是40年前，1981年12月12日由Bill Joy亲自拍的，参见 https://svnweb.freebsd.org/csrg?view=revision&revision=5245 ，然后他老人家当时没有切换用户，于是该commit签上了root的名字🤣）

前几天申请新的CVE编号块，结果收到的是两万多号以后的了，当时第一反应是卧槽今年第一个月还没过去一半呢怎么就直接两万多了？

我还怀疑自己看错了，结果前天微软发布了一个 CVE-2022-21907，所以这些号确实已经开始用了。

有没有可能是直接从20000号开始分配的呢？出于好奇，今天晚上找时间下载了一份最新的CVE编号表，发现如下：

1. 今年第一号 CVE-2022-0001 并非空白，已经有人保留了这个位置，但看起来是去年10月15日预留的一组5个，目测应该是某个比较小的CNA。
2. 目前已经公开的第一个2022年的 CVE 编号是 CVE-2022-0012。但奇怪的是0011是同一天申请的，并且接下来几条都是同一家（平底锅）的在同一天申请的，这样看来0011很可能也是他们的，为什么没有公开呢？这里说不定会有些瓜。
3. 最后一个20000号之前的CVE编号目前是 CVE-2022-0227（2022年1月14日分配）。
4. 第一个20000号以后的CVE (CVE-2022-20001) 竟然是去年2021年6月8日分配的。之后的10个看起来是某个CNA预留的，申请时间是2021年10月6日。
5. 20000号以后的CVE已经公布的最早的一个是CVE-2022-20012，来自联发科。他们是2021年10月12日申请的一个block。
6. 目前最后一个CVE是 CVE-2022-23219，已经公开，这是一个 glibc 的缓冲区溢出问题。

总之今年的CVE编号略微有些混乱。目前为止2022年总共有3346个CVE编号（这些未必最终真的会分配给漏洞），今年还没过去半个月，值得期待一下。

早上这雾有点大。

https://m.weibo.cn/5992829552/4725888945751899

事实上，每当一个沉淀多年的BBS关闭时，也就意味着一些曾经积累在其中的优质内容永远地消失，而创作那些优秀内容的高手们可能也就从此消失于人海，我们当初没有对那些珍贵内容有所整理和继承，我们满不在乎地放任了它们的消失，就好像在燃烧的图书馆前哼着曲儿围坐打牌一样。

我们当初之所以会那么淡然，是因为我们相信消失的东西将来还能找回来，然而，当我们走进青烟缕缕的废墟后才发现，大火带走了太多的孤本。

经 sunpoet@ 提醒，免费版的 G Suite (G Suite legacy free edition）即将在今年晚些时候停止提供。我现在还有一个域名在 G Suite 上，不过利用率不高，看看需要找时间把它搬到自己的服务器上了。

If you have the G Suite legacy free edition, you need to upgrade to a paid Google Workspace subscription to keep your services. The G Suite legacy free edition will no longer be available starting July 1, 2022.

https://support.google.com/a/answer/60217?fl=1