@mrfox

没有利益相关因素
我自己在用这两个 ASM2362 的盒子

便宜的选这个
https://item.jd.com/10040267150493.html
贵一些的选这个(记得选 ASM2362 的!)
https://item.taobao.com/item.htm?id=651360115430

我就这么干的 用 nvme 转 c 口盒子 上班带 u 盘 主要是图个上下班不用带笔记本回来
公司笔记本里装了个 windows+bitlocker 做应急用
上下班带个 u 盘就行 很方便 所有环境和代码都跟着走 回家直接挂虚拟机里从这个物理盘启动 可以继续用

不过要提的建议就是 尽量避免加密文件系统 虽然被人偷走 /捡到会很惨 但盘坏了自己盘不好恢复数据更惨
ext4 可能恢复软件支持的多一些
zfs 考虑到有 copy on write, 对于容易掉线的 u 盘来说更不容易丢数据一些
当然还有最重要的 定期备份数据
热备份还没找到什么太稳妥的方法 就不推荐了

300 都不如捡个老电脑用

@secondwtq

"我觉得你有点小家子气不是针对你明面上在 PR 中后半部分的回复，而是你在 PR 之外，背后针对 dissent1 的言论。"

pr 之外评论当事人不是很正常的吗? 我向来都是难听的话不管是当面还是背后都要说 而且是要大声的说 说不定当面说的比背后说的还难听 这都是我的观点 有问题就是要指出来 不行吗? 另外是 op 的 forum 还是 v2 不让 dissent1 看还是怎么? 我还在 forum 里专门带上了 bugtrace 和 pr 的连接 在网上发表公开言论和看法是怎么被算作背后针对的? 我实在是无法理解这个物理逻辑 我背对显示器算吗?

至于你后面说的实效性问题, 我前面已经说的很明确了, 这个 commit 本身就是一个自作聪明的优化, 不但结果是错误的, 连方向也不对, 所以没有任何保留的价值. 基于上述情况, 不管你是要立刻修复发版, 还是不着急发版要尝试其他思路来优化, 这个 commit 是无论如何都是要 revert 的. 尽快处理有益无害才是我催他们的根本原因.
退一步说, openwrt 是有 snapshot 的(别告诉我你不知道), 日常构建, 如果能作为 hotfix 用, 用户为什么不能用?

至于问题严重性界定上, 这个问题导致路由器软重启失效, 重启必定掉线, 没有任何解决办法除非物理断电重新开机, 如果你的电脑重启就死机你觉得这个问题严重吗?
另外不知道你是否知道很多地方路由器都是装在天棚上 /隔层上 /和一些不是那么容易够到的地方(老外家里很多都这么干的), 想要够到他都要弄个梯子上去, 很麻烦的.

==========================================

实话实说, 你的所作所为让我觉得你不是想要坐下来认真讨论问题, 而是想扮演理中客找一些存在感和成就感
真心建议你做点什么更有意义的事情, 一定要讨论的话至少看完双方对话, 对相关项目有个最基本的了解
一味的给人套帽子和强行理中客其实并不 cool
我的娱乐时间比较有限, 可能不会再回复你的帖子了, 因为实在是没有意义, 我相信每位路人都会在思考之后得到自己的观点

@secondwtq 不小心手滑按出去了

看你写这么长 但是我想说你的观点是不太正确的 既然做阅读理解就要做彻底

openwrt 这个事情, 我做找问题提 pr 这个事情的初衷是, 我作为一个用户在使用 stable/release 版本的时候遇到了这个问题, 导致我的设备无法正确重启, 你漏读了这个关键信息, 这不是一个简单的开发观念不同, 而是 bug 被直送用户端让设备无法正常工作
这个 bug 会导致设备无法正确重启, 必须手动关闭再打开电源(恶性问题). 而且这个 bug 并不是仅在 dev 分支, 而是已经在没有测试的情况下成为 stable 的一部分提供给用户(所以需要尽快解决)
我坚持自己观点提出他们应该 revert 掉这个 commit 的理由也说的非常清楚了, 这里是英文原文
写英文和写中文本来就逻辑不太一样, 没什么时间润色, 就不要挑一些说法比较奇怪的地方了

```
In my commonsense:
在我的基本常识中:
If it's an optimize, and it's failed, revert it no matter how old it is (if no major conflicts). Then we go from there to find a new way to optimize it.
如果这是一个优化项, 而且是一个失败的尝试, 不管多久也应该撤掉. 然后我们重新从这里寻找新的途径来优化
If it's a feature or driver that is needed for the device to function, we keep try to fix it until we find a way.
如果这是一个必要功能 /驱动项, 那不管多久都值得尝试

In this case, the code in dts is clearly a "smart" workaround attempt to OPTIMIZE something have no relationship to performance. And most importantly, it's NOT work. Therefore I didn't see the point of keep the patch in source tree, not only it's wrong but also not lead a way to proper fix.
这个 case 里, dts 代码改动明显是一个自作聪明的优化, 没有任何性能相关提升. 而且更重要的是, 这东西不工作. 所以我看不到一个合理的理由留着这个改动, 不但因为他是错误的实现方式, 也不会导向任何正确的结果

We should just revert the patch, let end user have a working code/bin, then open a new issue/ticket to do research.
我们应该撤回这个修改, 让用户有一个正常功能可用的代码和二进制, 然后开一个新的 issue 来研究这个事情的优化.
I'm at the edge of losing hope of the Openwrt project by this kind of project/code management philosophy.
因为(上面讨论里的)这种(放着恶性 bug 在 release 里不管, 慢慢研究怎么 proper fix 的)管理哲学, 我已经在对 Openwrt 项目失望的边缘了

I hope my commonsense is common.
我希望我的常识是[常]识
```

"我觉得这个事情就是不同的社区的规矩和习惯不一样而已。倒是 #19 难以接受其他人与其观点不同，先是在 forum 里，又在 V 站阴阳怪气人家，真心显得有点小家子气。"

我在这个 pr 的讨论可能不是那么端庄和礼貌, 但也始终保持了友善的表达不满, 基于事实, 和以理服人的原则.
"难以接受其他人与其观点不同", 换一种说法其实是 "希望他人接受我的观点".
这种 pr 讨论本来就是要选一个最合理的方案来解决问题. 我相信自己的方案是合理的, 所以通过摆事实讲道理的方式希望大家能够接受我的方案, 这有什么错误吗?
而且明显是有人理解和支持我的想法的, 我上面那段英文原文也是有人点赞的, 你是选择性脑内屏蔽了吗?

如果在开源项目里用合理的方式表达自己不满和在辩论中希望他人接受自己的解决方案方案 /观点, 也能算作是"阴阳怪气人家，真心显得有点小家子气", 那我只能说, 对你说的太对了 (只要微笑就好.jpg)

@secondwtq

设置-搜索设置-搜索语言范围-全部语言

@opengg clash 的 fakeip 方式有 dns 污染 并不是很理想

这个问题最好的解决办法就是弃用 vmbox 换 vmware workstation, 有钱推荐买个人正版 其实并不贵了
mac 下我依然推荐 vmware fusion, 比 pd 自由性和性能都好很多

@dragondove 我说的主要是二进制一致性 用 ubuntu 的话 github 容器和本地都是同样版本的包 生成的二进制是一样的 但一个用 arch 一个用 ubuntu 里面的 arm-gcc 版本肯定是不一样的 所以二进制差异会比较大 就算是同版本 也不都是发行版自己编译的 编译编译器的参数和默认带的库和行为未必一样 所以是会导致二进制差异

arch 好处有很多 我之前自己电脑也用 但开发为了方便还是要用 ubuntu 的

@ohwind 我帖子里也说了 也叠甲了 你非要举极端例子我也没办法 我只能说我说的两个 case 都提供了 bugtrace 和 pr 连接
我相信骚扰社区的伸手党绝对不少 但社区不能因为问题 a 就忽略问题 b 这是两码事
正如你所说 互相尊重才是社区的根本 但是问题明确修复明确 pr 都提出了就是不合 这是社区对同时作为用户和开发者的我的尊重方式吗?

经常看到 v2 上这种吐槽 win 强制更新的问题
重点在这里 很多服务 策略组 注册表 电源方案配置 其实都是没有意义的
微软并不保证尊重这些配置 更新有时候会"修复"这些东西 或者是干脆连这个注册表项目都没了
解决强制重启问题最重要的地方在于一开始就不要让他下 而不是下了不让他装
所以正确的姿势是 平时彻底禁用掉服务 定期手动打开服务 更新重启 (单纯的在 Service.msc 里禁用没用 他会"修复")
https://www.sordum.org/9470/windows-update-blocker-v1-7/
可以使用这个小工具来实现 但这东西好像不开源 如果不放心安全性 的话那就反编译一下看他干嘛了吧

@dragondove 我之前非工作机是用 arch 的 也是不用 grub 用 systemd-boot 这套方案日常还好 但是如果涉及到要把开发的东西放 github actions 就不好搞了
ubuntu 系我可以直接用 github 的 ubuntu 镜像然后自动安装几个包就可以编译了
arch 的话不好保证一致性

@mrzx 用 ubuntu 是想图方便 并没说错 不过原因倒是比较现实 因为开发相关的包比较全而且比较跟得上版本
什么都要从源码编译实在是太浪费时间了 或者说官方有二进制也要下载 /解压 /配置路径 /etc.
除非有特殊版本需求 不然直接 apt 装还挺方便的
另外 ubuntu 有 arm 工具链和比较齐全的库的包 交叉编译也不用手动装各种东西

手动装东西多了之后系统很脏的 毕竟人没法记得所有东西

好像 markdown 插入连接失败了 大家手动复制一下吧...

作为一个日常跑 Linux(工作全部时间)的人 真的不觉得 Linux 桌面有多么值得赞扬的改进 依旧是仅仅能用
这个问题的原因是比较复杂的 有上层设计问题 也有底层问题

先说设计问题 用过 Gnome 和 Xfce 各有各的好处 Gnome 炫酷一些 Xfce 占用资源少 但是每个都有各种各样的缺点

Gnome 首先是效率问题, dock 里如果你同一个程序开多个 就一定要多点一下才能找到你要的那个实例 就跟 win 的自动合并一样 这个设计是非常反人类的 尤其是你工作时候要开一大堆东西 比如说不同目录 非常非常耽误效率
Gnome 还有一些程序状态栏图标显示问题 有的显示不出来 还有一些杂七杂八的小问题 都列出来也不现实

Xfce 对于效率厨没有上面说的合并实例问题 但其他方面尤其是多屏情况下有很多问题
首先是自动停靠窗口(就是你托窗口到屏幕边上自动给你 1/2 或者 1/4 停靠) 如果我有两个 4k 屏幕 此时在笔记本的 1080p 的屏幕上就只能 1/4 不能 1/2 这个肯定是一个比例计算的问题导致的
其次是多屏幕配置问题(就屏幕排列 缩放等等) 每次改排列 就要卡很久 导致 10 秒还是多少秒内无法二次确认导致退回 非常恼火 还有就是概率性在配置排列那里 三个屏幕重叠在一起 拽不开(估计边缘检测设计问题)
另外还是多屏配置问题 更换显示器(或者是仅仅断开一个显示) 布局保留还是重置的规则非常迷 因为我是笔记本 经常是重新插一下显示器 布局就重置了(两个显示器都是正规厂家产品 edid 肯定合规也有序列号区分) 又要重新调 重新调有时候又会碰到上条的问题 叠在一起 拽不出来 只能先禁用一个然后它就会自动出来之后再启用 但又会碰到上上条问题 每次切换卡的比较久 导致没法确定又自动还原回去 血压++++++++++++++++++
其他还有就是那个程序菜单(就像 win 的开始菜单一样那个东西) 多个显示器的话 每个显示器都放一个的话 三个竟然 [不 同 步] 就是你在这个显示器的菜单里 pin 了一个程序 另一个里你也要 pin 一遍 why??? 为什么要分开保存???

这里我让我叠个甲 是的 我非常清楚上面的问题是可以通过 gui 配置 /手写配置 /魔改来解决的 或者说干脆换一个插件也可以(但能不能找到一个跟你现在版本兼容又不跟其他插件冲突的就不好说了) 但如此常用且关键的问题都做不到开箱即用 我只能说就设计和实现上 Linux 桌面距离成熟二字还很远 大家工作和生活都很忙的 正经干活的人(我想)大概都不希望在配(Xiu)置(Li)环境上精(Lang)雕(Fei)细(Shi)琢(Jian)

剩下来说说底层问题

笔记本是 3050ti 显卡 不管是 ubuntu 还是 xubuntu 最新版还是 LTS 驱动都有概率性卡住 最近几个版本稳定一些了 其他发行版没有具体测试 但估计都差不多 因为 dmesg 能看到真的是老黄的驱动 hang 了 这也许不是社区的锅 但真的很影响使用

下面要说的就是社区的锅了 坑爹的 grub bug 启动时候显示"error: out of memory." 之后 Kernel panic 无法启动
具体可以看[这个连接]( https://bugs.launchpad.net/oem-priority/+bug/1842320?comments=all) 注意 这是一个 2019 年提出的 issue 直到今年 3 月末才解决 这个问题本质上是 grub 默认利用的内存太小了(或者说从一开始就没好好搞内存分配导致后面碎片化太多无法找到足够大的区域) 而现在的 initramfs 又越来越大(尤其是塞进 nv 驱动之类的东西之后) 导致 kernel 载入之后 没地方放 initramfs 了 所以报错 如果任意键继续 kernel 会因为找不到 initiramfs 于是 panic
这个问题受影响的配置很多 尤其是老黄驱动模块变大之后受影响的就更多了 然后这个也不是很复杂且严重影响用户使用的问题拖了 3 年多才修好 我该说点啥?(只要微笑就好了.jpg)

再额外叠个甲 是的 我同样清楚社区都是自发自愿贡献的 贡献者不亏欠用户什么 但我同时也觉得现在这类开源社区对用户的态度和做事的实效性并不比老国企好哪里去
之前 Linus(LTT 的那个 不是给 NV 竖中指的那个)体验 Linux 之后也是这类观点 社区的态度很不友好 比如"我干这个的时候遇到了这个问题 请问是怎么回事?" "你为什么要干这个?/你为什么要这么干?/用我们 Linux 就要 xxx 的的方式来做!" 而不是真正去思考为为什么用户遇到这样的问题我们有没有什么地方可以改进一下
之前也给 OpenWrt 提交过代码 背景是一个 commit 导致 EA8500 的设备数不正确 重启无法复位交换机导致必须手动断电重启 我叫了个 pr 说明了原因并且 reverse 掉他的修改 刚提交 pr 原作者就"你干嘛碰我代码? This is a war over a war!" 这个后来在坚持不懈的沟通下也卡了很久才通过 可以点[这里]( https://github.com/openwrt/openwrt/pull/2047)看 pr 也可以点[这里]( https://forum.openwrt.org/t/ea8500-reboot-fails-only-with-power-switch-on-off-successful/18234)看论坛

这两个例子可以看出 大型开源项目修复一个导致产品不可用 同时问题和解决办法都非常明确的严重问题 实效性有多差

最简单的方法难道不是卖掉闲置旧手机然后买个正经的 usb 摄像头吗...

@whileFalse esxi 这么显示是为了直观表示服务器容量 但不应该拿去说 "我这 cpu 能跑 8G"
另外抛开架构不谈 单论核心数和频率 没有任何意义 奔四还能跑 3.0G 呢 性能跟新款 CPU 跑 1.0G 有的比吗? 不然各大公司研发新架构是图什么?

@xiajiebuhui 树莓派 4 用的是 BCM2711, 标准频率 1.8G, 你是怎么超到 8G 的? 没有冒犯的意思...但楼主是否考虑去 intel/高通高就?