rdp 不支持你这种需求，换其他的远程工具

对了，现在一加还有激活锁，必须在国内用国内电话卡激活一次才行，直接一加寄到有一加正规代理的国家再激活会报错无法使用。已经报激活锁的话，root 后装个模块能解决。现在一加比起以前越来越封闭是真的

现在的氧 os 就是 coloros 换名，氧 os 早没了

一加 11 开始国内版手机刷氧 os 开始出现一堆问题了，虽说后来大部分问题都能解决，但还是有少部分问题。明显一加开始故意给给国内版手机刷氧 os 制造障碍

国内版 coloros 无法正常使用 google pay （ 7t 测试的）。听说 google timeline 似乎也有点问题。Google auto 因为不在 system 分区会导致能启动但无法正常工作。以前试的时候，甚至谷歌联系人都没法正常同步因为缺少相关组件，我所有通讯录可都是存谷歌联系人上的，不能同步基本没法用，但最近又装了一次 coloros ，试了试似乎又能正常同步了。

虽然但是，如果算上 wslg 之前的 xserver 时期，wsl 可以跑 gui 这已经支持超过三四年了

wsl2 都能调用宿主的显卡直接在里面炼丹，没什么好惊奇的

手上虽然只有十几台 vps ，但实在管不过来了
于是学了 k8s

每个 vps 自动部署梯子节点，nextcloud ，tailscale derp 节点之类。剩下的大部分服务还是跑在家里 vps 用 tailscale 连回去。那些服务让我放公网说真的我并不放心

住日本，今年买的最满意的 日版 Galaxy Watch 6
当然 Galaxy Watch 6 本身也是一堆槽点，但日版 Galaxy Watch 6 和其他区不一样，内置 felica ，可以用 suica ，iD ，QuickPay 这些日本常用的 nfc 支付方式。

买了这手表后我终于不用在日本买那些低配高价的手机了。在日本安卓机机又贵又低配，还在日本买手机的唯一一个理由就是 felica 。习惯了无现金，不用二维码的生活是真吉尔爽

只是路过日本的话去能退税的店买就行
但是有没有货随缘，有没有货基本只能现场确认或打电话

比起这感谢，我更希望发出的评论至少在一两分钟内是可以编辑的
打错字，或者打一半点错发出来的时候是真的难受

一加 11 海外版，双 nano 卡槽+1 个 esim ，总共三个卡。
不过不能三卡三待，同时只能启用两个。应该是非常灵活了，而且一加海外版信道没有阉割

D 人成本很低的，比如攻击者手下有个控制着很多台肉鸡的僵尸网络的话，发出攻击也不过是几个命令的事情

虽然但是，，，，，，，，，我试了下，用 go 生成了包含 100 万个随机字符串的数组，然后直接简单粗暴地用 for 遍历整个数组，然后对每个成员做 strings.Contains() 搜索，遍历完成都才花了 11ms

lz 你是不是对现代计算机的性能有误解。。。。。

"如果把 json.Unmarshal() 之后的 object 保存在内存中，减少 json.Unmarhsal() 的操作。不同 goroutine 拿到的 object 就是浅拷贝的，并发不安全。"

你这 json 配置难道解析后还要修改？不修改的话解析完成设置变量的时候上锁写个 singleton 不就好了，怎么会并发不安全

这帖子令人绷不住，2L 都基本把正确答案写出来了。。。。。

建议 lz 多试试更加现代化的笔记，而不是单纯的用 markdown 记笔记

热知识：所有规格网线，在网线质量 OK+打水晶头手艺没问题+短距离信号干扰不强的环境下，都能跑出比它等级高一两阶的速度。只是这种速度往往没有特别强的保证

@ylc
“既然有可能在不同的 CPU 执行的情况，那为啥这个假设又是错误的？” 因为你搞错了 go 线程啊，我在指正你的知识错误。
go 协程之所以叫“go 协程”而不是单纯的线程、协程，那是因为它就不是单纯的多线程，而是多线程+自动协程调度。上面我有段没说清楚，“当执行 c <- 0 将 main 阻塞之后，go 调度器可能会将 main 的执行挂起然后用同一个核心去执行 f()” ，这里我用了用同一个核心去执行这话容易可能引起误会，更准确的是 ”go 调度器可能会在当前线程中将 main() 的执行挂起，然后用同一个线程去执行 f() ，然后等 f() 阻塞后将 f() 的执行挂起回去执行 main() “。这里的任务调度都是 go 内部完成的而且自始至终都只有一个线程，而不是 go 在调度 main() 和 f() 两个线程，这点要搞清楚


"main 挂起之前 f 已经在执行了" 你这假设也是有问题的。Go 协程你是没法确保它什么时候被执行的，这在学 go 协程的时候对应教程应该都有说明的。f()有可能是在 main 挂起之前执行了，也有可能是在 main 挂起之后才执行，所有调度都是 go 调度器在控制。

“main 挂起了之后去抢 f 过来执行吗” 是的，你猜对了，Go 的线程调度模型就是一个线程空下来(或阻塞)的话，就挂起当前阻塞的任务，然后从待处理的任务里“偷”个任务过来在当前线程里执行。有兴趣可以找找 Go 协程的 G-M-P 模型，官方形容这种模型就是”鼹鼠从其他工人的推车上偷砖块”

看下来，这个帖子暴露出了两个严重问题，lz 表达能力和回帖的理解能力不足导致的交流效率低下，以及那么多人对并发编程最基本知识理解的匮乏，居然那么多人不知道并发的可见性问题，拜托这可是多线程/并发开发的基础知识

对于 lz 的疑问，要回答全面涉及几个方面知识
1. 首先 lz 假设的两个 go 协程分别跑在 cpu0 和 cpu1 上的前提是不正确的。他们可能会跑在同一个核心上，也可能跑在不同的核心上。当执行 c <- 0 将 main 阻塞之后，go 调度器可能会将 main 的执行挂起然后用同一个核心去执行 f() ，这时候程序的执行是完全单核的。当然也可能会开另一个线程执行 f()。具体行为由 go 来调度，用户层面没有感知

2. Go 协程自然会遇到内存可见性问题，但是 go 帮你解决了很多可见性问题，其中就包括 channel
https://juejin.cn/post/6911126210340716558