unix shell 也是这样的习惯

同意#3
1. 没有存量负担时，坚持用 timestamp with timezone 类型
2. 自己用客户端人肉查询处理问题时，可以先 set timezone 指定时区
3. 如果涉及到索引，可以针对业务上常用的时区做基于函数的索引，或者用触发器弄一个索引列

这不是项目跨不跨国的问题，而是 timestamp without timezone 的读写是直接吞掉时区的，指不定哪个环节配置不对或者哪个库处理不对就不可控了，用 with timezone ，跟外部交换时根据客户端的时区做转换，内部存储则用 UTC ，这是确定的

Powershell 大致可以理解为“Shell 夏普”language ，就是 C 夏普、F 夏普里那个夏普

所以呢，对于玩夏普的那帮人，有时候需要一个不那么软工味的脚本语言来干点运维自动化之类的活是很顺手的，比如知乎三大软狗温赵轮之一的轮子哥 vczh 。

而对老派 Unix 用户来说就没那么大吸引力了，跟这些人讲 Powershell 是跨平台的可以在 Unix 上跑、能在管道里传对象，人家只会觉得这是夏普帮的自我感动。

最终你会想通的。

花钱在 B 拉一条新宽带是最简单可行的办法。

你家 LAN 的网关（ 192.168.xx.1 ）虚拟化到 ISP 机房里了。
潜在的好处是将来有可能跟你套餐里的手机网络互通，就是说你在外面用手机流量也能跟家里直连，不用再想办法搞穿透了，也不排除将来有更多的产品可以直接用这种办法打通，比如一人多处的同名宽带直连。当然，实际能不能用取决于运营商远不愿意做这些产品。
直接可见的坏处是必然失去对网关的配置能力，各种花样的玩法（比如做在网关上的合法 VPN 、端口映射）能不能玩取决于运营商是否恩赐。。

如果文件系统做在 LVM 上，容量有富余，是可以先建一个新 LV 在上面 bootstrap 一个目标发行版，然后设置好 boot 项，切过去的，不过如果没有远程带外 console 的话风险还是挺大的，写错一点就启不来了

iTunes ?

PEAKDO 毫米波无线 HDMI 试试

@murmur 但是墙内公子哥的企业套皮发行出来的大概率跟不上 upstream 的修 bug 进度

他甚至都懒得换一套有区别度的 default theme colors

计算机行业才多少年。越老越吃香的是已经高度成熟的行业，经验值钱。

如果对数据一致性有强要求的话，第一种可能不太靠谱

从 Windows 7 开始就不「必要」了。反正干净重装也可以不格盘，装完把 old 目录删光就好。

但是个人习惯还是分开，重装时格盘。

所以还是学点单片机自己做吧。我记得不久之前看 V 友用 ESP32-C3 自己做了个硬件的 SSH key agent 设备。

为啥国内没有？因为连在 V2 这种开发/运维人员密度很高的社区里都会有很多 V 友针对你喜欢 TOTP 硬件而不喜欢手机的执念劈头盖脸教育你矫情……可见对个人用户来说这玩意真的不符合天朝国情。

还有不支持 agent forwording ，这一点我是完全不能接受的

如果盯住 OP 字面上说的"一线业务人员可以直接配置"，拿一线业务人员连真正的脚本也不可能用，是会得出 OP 才可笑的结论。但是如果真要你们这么非黑即白，一头是纯业务的，另一头是用 Java 这种产业级软工语言吭哧吭哧硬写代码的，那不妨更极端一点，业务这头，「真正」的「甲方」味的「业务人员」，别说脚本语言了，甚至可以拖拉的编排系统都不要去用呢，有啥需求用颠三倒四错误百出的文字描述出来让乙方返工 10 编去给搞出来不更好？

去除 OP 表达的问题或者某些思维误区，咱不谈给一线业务人员用脚本这个搞笑想法，只说在一个用 Java 开写核心引擎的平台里引入脚本语言来做开放能力，这样做是为了什么，还不是因为业务的多变性高于基础设施，让写引擎的人去用同样的语言写业务规则是资源错位，引入脚本语言了，可以更好地做对人员分工，不论是招聘还是培养，都可以细化出一批专门写业务规则的人。那么，Java 写的平台里再引入 Java 写的脚本，真的一点也不可笑吗？有技术解决方案能做到，就是合理的选择吗？

@bao3 本意非杠，只是好奇，究竟是什么情况下出现的。按我的理解，在现代 Windows 的 CMD （而非 9X 的 COMMAND.COM ）里，Win32 PE console 程序（而非 DOS COM/MZ 和 Win16 NE ），普通使用（没有自己写程序调用底层 API 或直接操作文件系统结构），要出现 8.3 根本根本是不可能的。