另外感觉上面被迫害妄想症的人太多了。
我能统管三大运营商的话，我为什么要反对 eSIM ？实操的活又不是我做。而且中国本来也是标准的参与者啊。再说我有这权力，我直接就能否了 eSIM ，那现在为啥还让它通过？欧盟都能逼苹果开放侧载，我就不行？
什么有点权力就要恶心人民啦，什么故意让 eSIM 不好用啦？等等。搞不明白楼上都在想些什么东西

如果我是领导，这是很简单的一件事：
首先标准制定好了，国外也做了，手机制造商也需要这个功能。那顺势跟进一下就好了。
过程无非就是技术和安全人员出几个方案，找运营商、手机厂商等相关人员讨论一下，拍板。然后开做。完事了。

没有那么多勾心斗角、权力斗争和阴谋论，纯粹就是日常工作罢了。想那么复杂干啥了。。。

针对楼上的说几句

首先，eSIM 有标准。标准中也允许用户通过扫描二维码、App 、或运营商推送的方式下载配置文件。
但是，它没有规定必须给用户多少操作权限（例如：是否能自由下载多个运营商的配置文件、是否允许随意切换）。这些由运营商策略和国家监管来决定。所以 eSIM 本来就没有说要做到怎样怎样？如果说有中特色 eSIM 的话，那也会有美特色 eSIM 、日特色 eSIM 等等。只是中确实更谨慎些。


另外安全性和便利性本来就需要平衡，所谓国外的 eSIM 更便捷，那肯定也相对更不安全。在国内很多平台依赖手机号（也就是运营商）来确认你的身份的，也有反诈需求。这种时候你贸然降低安全性肯定是不合适的。
而且这只是刚刚接入阶段，以后又不知道怎么发展。拿小额支付举例子，从最开始的现金，到扫码支付，到现在的手环、碰一碰支付等，难道整个过程就是一蹴而就的吗？

装 Windows ，用不来还能上网吐槽微软
装 Linux ，调不好上网问还得被人说技术不行

摄像头？

[img]https://i.imgur.com/cTpQzia.jpeg[/img]

不说沟通流程，解决这个事的方法就是公司再买一台就行。这个估计谁都能能想到，但人事只是不想去干。

你没错，但沟通很成问题。
先和同事讨论，猜想，然后去找人事验证。这个过程中你已经对大概的情况有所了解，也会有一定的心理建设。这就导致变成你有全局观，强迫你接受现状就更容易。你会自然地换位思考，如果作为人事，你会怎么说服你自己接受。所以就搞得你很被动。


如果是我，看到同事的新电脑，有猜想，那绝对不能问。让自己“蠢”一点。我只需要知道我按流程走了，人事也承诺了给我。我就直接去拿就行。拿不出来，那不是我的问题，让人事去解决。
1 、如果人事向我解释来龙去脉，我就直接要求公司再买一台。而且要人事来处理其他的杂事，因为她跟我承诺的可以拿。因为我是工作需要、走完全流程，所以合理合规。
2 、如果人事提出让我用 m2 ，那我直接拒绝，理由就是性能不够+与流程不匹配
从始至终你都要强调流程没错，把问题甩给别人。不换位思考，不让自己接受现状，掌握主动权。


另外你有注意到吗？人事想把你和她之间的矛盾转换成你和你同事的矛盾。这时候要非常警惕，正确的做法就是强调“我们”，不要内斗。
你应该说：既然我和 iOS 同事都是走正规流程进行审批报备了，那我们俩都应该拿到对应的电脑。这样就仍然把问题抛回去。

限制三方硬盘的主意没十年脑血栓真想不出来

pitaka 的感觉还行

赞成。我觉得 Java 是最值得学习的后端语言。
Java 有不少缺点，语法非常啰嗦（写个 http 请求巨麻烦），入门简单、深入困难、生态非常大，启用慢占用大，函数式（.stream()）和异步编程（ async/await ）非常弱、语法糖少等。
最主要是上手慢，我感觉初学者估计要 4~6 个月的学习才行

但是 Java 其实属于企业稳健派，强大而且啥都有。生态库全、跨平台且稳定性强、自带多线程机制、也非常适合大型团队。反正我自己的经验，Spring Boot 里的屁大点事在其他语言的框架里都很麻烦。


说几个适合你的：
1 、Java 和 Js 的风格接近，都是小驼峰，相比而言 C#是大驼峰，Python 是 snake_case ，当然 Node.js 另说
2 、就按你说的，课程多，学习资料多。而且 GitHub 上 Web 项目中前端 Vue+Spring Boot+MySQL 这种架构频率极高，可以参考
3 、Java 后端人多，如果你以后还是前端为主的话，那和你合作的后端极大概率是写 Java 的
4 、你们公司如果现在就是 Java 后端的话，直接就可以参考学一学（可选，因为公司的代码大概率质量不咋样）

建议改个名字，听起来像周鸿伟搞出来的

我没遇到过，另外可以点一下右下角的 vue 或 ts 重启一下服务，可能就正常了

群晖如果是内存不足的话，可能会出问题
我上次在 4G 内存的群晖上装虚拟机，基本卡死。其他没遇到过问题

@xiafengjieying
如果你说的是在本地局域网的一台主机上配置一个客户端是可以的（我目前这么干的），但在上面搭建一个服务端应该是不行的。你应该还是需要一个云服务器

另外 WireGuard 的 endpoint 应该是可以用域名的，但是只会在 WireGuard 启动时解析一次，所以 DDNS 中途 IP 变了就麻烦了

如果是接触手柄时间不长的玩家不习惯打不好是正常的，但 op 有 switch 又有 xbox 那应该不是新接触了

应该不太适合
魂系都是反应时间够，但是容错率很低，还有快慢刀

不过主要还是你的心态，你是屡败屡战愈战愈勇还是非常厌恶挫败感，前者适合后者不行

@xiafengjieying 挺稳定的，不管怎样至少比纯 WireGuard+ddns 脚本稳定多了，不太用操心
速度上倒没啥感知，因为我更多还是应急取 NAS 数据用，所以用的也不太多，正常就是可以跑到家里的上传带宽

@Jacksu 群晖的缓存策略完全可以跟我想的不一样，这没问题
问题是缺少数据的佐证说明至少在什么场景下能提升多少，这个很少有人做

我体感上没差别，CrystalDiskMark 或直接读写也没差别，我也找不到提升的数据，找不到留着它的理由

@Jacksu
就拿普通的 TLC 固态硬盘来说，往往有一块 SLC 缓存，写入时，数据先写到这块 SLC 缓存，速度非常快。等待系统空闲时，控制器再把缓存里的数据搬到真正的 TLC 区域。
我期望的是类似的写入时先写入 SSD ，然后慢慢移到机械硬盘。
而且根据时间局部性原理，刚写入的数据往往是更有用的，所以我在先向 NAS 写数据再读取应该更容易命中缓存
只是很明显群晖不是这种策略，鬼知道它什么策略

再者说，命中率系统里就有显示，但如果我从速度上没法感知到缓存盘如何加速，那缓存命中率 100%有啥用？

如果微服务往单体收敛，云原生的需求会减少，另外对资源的占用是不是就相对不那么突出。成熟的后台类库和框架会重新成为技术选型的主要因素。进而导致 Spring Boot 赢麻了。完美