我很多网站登陆都用这个, 随身携带放钥匙扣上
就是价格有点太贵了, 5c nfc 要四五百, 闲鱼上最近也没有太便宜的了

宁有种乎

不小心按出去了

'树莓派性能太差了，我有树莓派 4b 4g ，树莓派装 fedora 启动一次都要好几分钟，dnf 安装个软件包也也很慢，qemu 模拟的 aarch64 同样有性能差的问题。'

暴雪: 你没有手机吗?
手机是 aarch64 吧...跑的是 Linux 吧(安卓勉强算)...

问这种问题你最好写清楚你最终目的是什么, 建议阅读[提问的智慧]( https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md)

@wniming

+1 你这多半是内存炸了

你要找的是不是 buildroot

@lanxinyuchs 这才是看透本质的观点

可读性不是一个绝对值, 而是以需要看懂代码的受众作为木桶, 里面技能最差的人的水平来定的
大神+普通人+实习生的团队, 就要以能让实习生努努力就可以理解的水平来作为可读性的下限标准
可读性大多数情况下还是为了让人快速上手和提高可维护性服务的, 所以要以大多数人的水平来定一个合适的下限

奇技淫巧总是有的, 但用还是不用终究是取决于能带来什么好处, 是一时的方便, 还是能提高代码效率
就拿 op 原贴中 magic header 例子来说, 确实省去了 strcmp 之类的比较字符串的操作提高了效率, 但如果我用的 hex 并不能表示可读字符或者表示的是特殊字符呢? 或者我大于 4 个字符呢?
奇技淫巧脱离了上下文和实际场景是无法评判是用得好还是用的傻的, 所以拿这来体现不同段位程序员对可读性的认知是不合理的

我自己也喜欢用这类强转类型引用之类的操作避免大量的内存拷贝, 也喜欢 casting 之类的操作, 但我一般都会至少写一句注释这是在干什么

可以看这个
https://www.v2ex.com/t/938092?p=1

虽然是旧闻 但我还是看完了
整体并不是 bitlocker 加密机制破解, 而是在不严格甚至是错误的配置下被绕过
说实话现在消费级笔记本的 tpm 意义不大, 有的可能实现上不安全, 有的可能芯片本身实现是安全的但电路不安全, 有的可能前面都好了但软件上不安全, 所以不如不用
我目前用的 bitlocker 都是用 password protector 的, 这个是不使用 tpm 的, 没有用户密码是无法解密的

@dsgdsfh
vmware workstation 是可以控制剪切板共享的, 虚拟机设置里面就有 https://docs.vmware.com/en/VMware-Workstation-Pro/17/com.vmware.ws.using.doc/GUID-F5666A8A-78CC-4005-A8B1-72F0EA5D76C5.html
gui 没有单独控制复制还是粘贴, 但其实可以改 vmx 文件来实现, 那个 gui 选项本质上也是添加了这两条而已
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-367D02C1-B71F-4AC3-AA05-85033136A667.html

snipaste 确实很好用, 感谢推荐

nas 本来就是买软件送机器, 你买个软件垃圾的不如干脆不要买

@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

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