除非是把 bootloader 搞炸了是可以实现一键回滚的（我记得 suse 可以在 grub 里面选择启动到某个快照）

不过想要避免更新导致爆炸真正的银弹是 Transactional Update ，比如 Fedora 的 silverblue 之类的 ostree 变种和 suse 的 micro os 版本。

0.0.0.0:53 就算被占领了你大概也能监听 host-ip:53 (host ip 就是你的 nas 的 ip 地址）

@BRS5672023 #8 一般我也不会太细究为什么，毕竟研究 iobuffer 行为大概率会变成无用功（这方面折腾不如用现成的 TUI 库），但是原因大概是 cin 的流操作会留一个\n 在 buffer 里面（对应的 getline 不会）

可能有些路径没有最后一个(输入的)换行之前用的 cin >>， 然后\n 就留给了最后的 cin.get();然后退出了。

general: cin.eof 除非我按 Ctrl+D ，或者 pipe 进来个文件，否则始终是 false ，所以有那个判断大概就是等价于删掉它包起来的代码。（并且一般交互式程序遇到 end of cin 大概就该结束了）

> 特别是如果我把 getValidInput 函数的这个判断给注释掉的话，那么在我输入 "2" 使用 "显示联系人" 这个功能时，需要再输入一个回车才会显示 "请按回车键继续" 的字符

cin.ignore(numeric_limits<streamsize>::max(), '\n'); 会一直等输入（堵塞）直到遇到回车，要是缓冲区里面没有回车的话。

> 而如果我仍然注释 getValidInput 中的这个判断，但取消 pause 函数定义中关于 cin.eof() 的注释（见上面的代码），那么在我输入 "1" 使用 "添加联系人" 的功能的时候，在我输入完联系人信息之后，pause() 似乎不会起作用，system("clear") 会直接清屏。。

那大概是缓冲区里面 somehow 留了一个\n...要是没有前面的 ignore 把它耗掉它就把那个 std::cin.get() pass 掉了

最差的情况：这类脚本服务器可以精心设计保证在 shell 执行和浏览器下载给你不同的输出。

建议重装系统

新手其实可以试一试 fedora 的 immutable 变种，https://universal-blue.org/ 甚至有配好了 nvidia 驱动的版本。不可变系统也不容易搞坏。软件也可以 flatpak/toolbox/distrobox 来安装，就无所谓软件什么来头了

个人体验，vscode 运行在 xwayland 下窗口开多了就会卡，用 ozone 跑在 wayland 下能解决问题，虽然代价是干掉了中文输入法

@EVANGELIONAir #62 > 我看不少人还喷 explorer patch 和 Windows 八字不合会蓝屏然后喷 MS 的

我到觉得 Windows 和 patch 开发商都有责任，Windows 提供了 patch explorer 的方法，但是没有提供“在这个版本的 explorer 的某些东西变了所以没有明确标示为可用的扩展都会被禁用”的方法或者特性。

结果就是在 Windows 上经常出现右键菜单莫名卡住之类的问题。然而想要列出有哪些扩展注册了又得用专门的程序（注册表的一堆 uuid 太反人类了），至少解决这些问题的门槛比 Linux 用户倒腾扩展要求高。

从本科开始就几乎只用 Linux 桌面（除了玩 3A 大作或者有反作弊的游戏会用 windows 设备之外），用 Linux 桌面的原因不是因为快之类的，而是因为方便和控制感。方便当然是开发工具链方便，都说 C++没有包管理，但是 Linux 系统包的各种 xxx-devel 就是 C++的开发的包管理。Linux 工具链也比 Windows 上面的 VS+windows SDK 来的要轻便

不过这么长时间用 Linux 也有 Linux 的问题，比如我很久之前用 beta 的时候就闹过笑话，同学叫我给他传文件，但是 xdg-portal 的一个 bug 导致我浏览器上传文件的窗口弹不出来。

但是换个角度，我发现浏览器选文件的窗口弹不出来之后我能立刻根据对于 Linux 桌面的了解知道挂个 dbus-monitor 、检查前后的系统日志和 coredumpctl 看谁的锅、看出来谁的锅了之后可以给对应的程序挂个调试器。定位到 bug 之后上 GitLab 一看，虽然发现 bug 已经被报告了，没有什么可以做的。但是在这个时间点，我可以选择忍耐 bug 等更新，或者回退到 bug 之前的版本，我就有了解决方案了。就这几天 dash-to-dock 和 gnome47 beta 闹毛病也是，简单观察下日志，定位问题，给 dash-to-dock 的 issue 评论，他也很快的帮我定位了卡顿的原因，就算有问题，都是在我的控制之下的。

Linux 给了这个自由和能力来解决问题。相对的，曾经一直服役的 Windows 游戏本，想拿出来玩玩黑猴，前几天拿出来发现触控板不灵了。检查了设置、厂商的私有 app 的设置、键盘组合键开关都无果，更新了系统也无果(不是硬件故障，UEFI 的图形界面里面能用)。然后我就没办法了。我也找不到资料告诉我应该怎么修，Windows 在丢了备份之后也没办法不丢数据的回滚（反观 Linux ，我可以精确的回滚我的/usr 到任意给定的某天的版本）。不过玩黑猴，也无所谓触控板了，插上鼠标玩玩，玩过了笔记本又放到角落吃灰了。

并且我也很少遇到 Linux 桌面恶性 bug ，最糟糕的也就是 Gnome 可能锁屏就整个 crash 这种，但是也没因此丢过文件所以无所谓了。但是 Gnome 有些很贴心的功能我很喜欢，最在意的就是 gnome 在线账号可以配置 krb5 账号，然后 gnome 就会自动更新 ticket 云云，对于集群用户很方便。以及容器允许我在自己电脑上搭建和集群几乎完全一致的环境，可以在网络不理想的时候测试更改。

@wxf666 是，除非是 mmap 的 shared 这种情况，之外父子进程都会看到 ro 的页面，等写入的时候中断介入复制

其实出于好奇我也下载了，丢到容器解压一看一个 exe 几个 dll
甚至还是 libstdc++的 dll
非常失望，开源供应链攻击都瞧不上了 linux 用户

@Pointless 我也遇到个，顺手举报了然后还评论了个 “The reply from @PiaoR in this issue seems to be a spam or an attacking attempt, please don't follow its guidance.”

GitHub 过了一个小时就删回复封号了

@skyrim61 这是 systemd 自己的 manpage

@freedom2030 #55 所以我隔了一层 wireguard ，还好机器只有我一个人用所以不应考虑这东西可能打穿用户之间的隔离之类的问题

我在自己的 homelab 的开发机上搭了 code server
效果基本上和原生一致

唯一的担忧就是这东西要是被黑走了 token 那就是一个完整的 shell 权限了

问题不是“输入法有特权”，而是启动输入法的整个环境就是个特权和完整性拉满的环境。Windows 在启动输入法的时候也没做特殊处理，输入法也没特别的实现发现权限太高就 drop 权限或者 lockdown 的逻辑，于是就留下一个和登录界面整个有同等权限的输入法了。

@EVANGELIONAir #9 至少 gdm 是做了权限隔离的，root 下的 gdm 会 fork 出来一个 gdm 进程运行在非特权用户下，整个登录界面的 ui 和进一步启动的程序（辅助功能之类的）也在这个非特权用户下。在 gdm 界面 ssh 上去看进程树就能看出来。这种情况下想要提权就得先控制非特权的 gdm ，然后想办法借由它们之间的 ipc 来破坏特权的 gdm ，没那么容易。

这种思维很常见，sshd 也会 fork 出来一个无特权（甚至受限）的子进程来负责网络通信之类的服务，不知道为啥 Windows 登录界面设计就这么简单，还是说 Linux 的思路在 Windows 不适用？

@HFX3389 #10 我倒觉得不能全怪搜狗，这更接近于搜狗没有特殊处理“输入法被运行在登录界面”这种情况导致的漏洞，Windows 远古时期貌似微软自己也犯过类似的错误。不过换个角度，其实输入法这种程序 per-user 安装就行了，一开始安装到所有用户就是不那么正确的决定。（当然大多数情况没得选....直接弹个 UAC ）

@Makerlife #11 那些是用户身份运行的，或者说是用户的启动项，当然是在用户名下的。不过还有一类启动项是“服务”，这些东西可以是 system 权限的，不过大概率不是你在任务管理器看见的那些。

是登录界面运行在 system 用户下的，搜狗输入法是作为登录界面的输入法于是就有了同等权限。至于为什么登录界面要这么高权限自然是因为鉴权和登陆本身就是特权行为。

操作上不是完全没办法规避，比如登录界面可以设计成由特权的鉴权程序+非特权的 UI 组成，特权程序自从非特权 UI 拿鉴权需要的信息（用户名/密码等等）。但是 Windows 没这么做，我也不知道为啥。

常年 silverblue 用户，silverblue 用的是 ostree ，原理是所有系统文件（/usr 下面的文件）都用 content addressable storage 的方式存储。设计上类似于 git ，每个镜像是上游服务器构建的一个 commit ，然后用户拉取，然后用 hardlink 构造一个传统的（看起来很 fhs 的）文件系统树。系统启动的时候 initrd 阶段会做 bindmount+remount-ro 保证所有程序行为和传统系统一样。
在此之上 rpm-ostree 提供从 rpm 构建 ostree commit 以及再已有的 commit 上修改的能力，每次更新都拉取新的镜像+重新应用变更。
ostree 不管依赖，只管文件树，然后 rpm-ostree 是基于 rpm 的。

nix 是完全不同的设计，同时管理文件树和依赖关系，文件系统不是 fhs ，程序可能需要修改才能运行（然后随便下载的二进制大概需要容器或者 patchelf ），某种程度上更完整（比如程序运行的环境和编译的环境可以保证一致，因为 nix 在追踪这种信息； rpm 虽然可以但是操作上可以，但是大家只要 soname 不变都无所谓）。以及更加可定制，整个系统都所有细节都是用 nix 文件描述的。

我选 silverblue 的原因是常年 fedora 用户，没心情换发行版。