建议在窗子不起眼的藏在窗帘后面的边角上，钻小孔通网线，然后上胶水密封
或者可以的的话网线从空调室外机连接孔穿出去

一加 12
选择因素，到手 root 过段时间海外发售可能可以刷氧 OS

Obsidian 要同步建议直接氪金上官方同步
自建同步体验非常差

因为 obsidian 确实做得不够好
细节欠打磨说毛糙已经是抬举了，不用官方同步的话同步功能一言难尽，所见即所得一堆 bug ，什么功能都动不动让你装插件折腾成本很高等等

obsidian 确实会很符合程序员胃口，因为可以折腾，md 天生符合程序员口味。但是除了喜欢折腾的特定人群之外，obsidian 是不太好的

作为在国外生活的可以太有发言权了。国内手机 rom 挺多都内置了残疾谷歌框架，你要用一些基本功能倒是能用用，但是想在国外生活中正常使用是不可能的，根本没法正常用

谷歌地图 timeline 不能用，谷歌助手没法正常用，没法滑动屏幕左下角右下角呼出谷歌助手，gogole lens 功能残缺，google play 商店无法更新自己等等等等。这些功能都是你不去用根本注意不到

国外几乎所有 app 的推送基本全是基于 fcm 的，而国产手机内置的 fcm 是无法正常拉起无后台 app 的，再加上国产 rom 那疯狂的杀后台，导致你收不到所有基于 fcm 的 app 通知。Gmail,line,discord, twitter, teams, slack,谷歌地图，谷歌 Photo 等等等等这些 app 都是国外工作生活天天用的 app ，没一个能收到推送。为了解决这一问题，你必须让 app 跑在后台。然后我手上是一加 12 ，预装的 coloros 限制你只能指定 5 个 app 跑在后台，简直 zz 。

当然上面一小部分问题可以通过 root+msgisk 模块+xposed 插件解决。我在折腾了几天之后，至少 fcm 推送能正常接收了，但剩下的 google 地图 timeline 无法启用，谷歌助手之类的都搜了半天没解决办法。现在我只能熬着等海外的一加 12 发售到时候刷氧 os ，虽然现在氧 os 也是 coloros 了，但至少 gms 是能正常使用的

选任何东西都不要无视价格来比较。LCD 和 OLED 之间整整$200 差价就已经足够做区分了
这东西预算够了上 OLED ，不够就 LCD 没什么好纠结的

日本快递，比如 yamato ，你可以精确指定快递到达的日期和派件时间段，快递员准时送到门口，而且时效性也好，无可挑剔。但是相应的，东京发九州，三边合计 60cm 重量 2kg 的快递，就要近 100 rmb 。

虽然国内人力便宜，但国内这快递费用，说真的不送上门我也无所谓了

megre --squash 就是这样的
除非你每次 megre --squash 后，再把 develop 给 rebase 或者 hard reset 到最新的 master 上

@BeautifulSoap 说错了，“我之前就是靠着这个方法 wifi 转有线的”

随便几十块钱的那种专门做这个的小路由就能做到，只不过要性能的话得加钱

如果喜欢折腾，openwrt 跟着官方这个文档就行，我之前就是靠着这个方法 wifi 转无线的，稳定用了好几年了
https://openwrt.org/docs/guide-user/network/wifi/relay_configuration#wi-fi_extenderrepeaterbridge_configuration

我上一个帖子了解下？
https://v2ex.com/t/996640
顺便提一下，那位应聘者已经过了二面了，虽然还有最终的领导面，但领导不太挂人很大概率入职

so ，lz 理解了日本 it 行业了吗
想过得相对轻松，躺下来，不求人上人的收入，日本是个不错的选择

一本 300kb 的 txt 文字量的话，20w 本共 57gb 的文字量，es 可以处理
或者本地跑个大语言模型，只不过对显卡要求有点高

@lvhuiyang 原来如此。其实不光是 ssm ，aws 的其他服务比如 dynamodb 之类通过 https 提供服务的都会出现可能性的超时。之前生产环境每几小时报错，查到后来发现是和 dynamodb 的通信超时了。

Lambda
整个项目 zip 打包后传上去就行，太大的话 webpack 之类的 bundle 一下

lz 你的 Lambda 的负载难道只有 1rps ？ 如果大于 1rps 你这做法当然会出现冷启动的问题

但再冷启动，11s 也太长了，Lambda 的冷启动时间撑死也就 2s~3s ，而 11s 的处理时间明显是程序内部哪里的问题，建议打 log 或者启用 xray 看看内部发生了什么

@nothingistrue 我十分怀疑你有没有用过 Github

rebase 尤其是 rebase quash 经常动不动引发冲突，甚至还经常导致 github 在 PR 里无法显示正确的 file changed 。所以我管的项目直接在 github 的 repo 设置里禁止 rebase 和 rebase squash
分支你看得乱就乱吧，反正只要保证几个重要不然分支不乱就行，剩下随便你们来。总比动不动 PR 合并出问题舒心

largefile 。。。。这参数我只有在我 nas 的硬盘上格式化时才会用。。。因为 nas 里存的文件平均都是几十 mb ，几 gb