V2EX › jim9606 的所有回复 › 第 1 页 / 共 100 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 100

❮

❯

4 天前

回复了 fake23 创建的主题 › 宽带症候群 › 旧手机的安卓系统如果升级安全证书？

你可以去 Mozilla's CA Certificate Program 自行下载证书在手机上安装为用户 CA （安装后系统会提示网络被监控）
不过现代 Target API 的 APP 可能不认，因为默认只信任系统根，这种你得 root 改系统的证书库了。

最重要的是目前 Let's Encrypt 使用的 ISRG Root X1/X2 根，其余的像 Amazon 、GeoTrust 、Microsoft 、GTS 、Hongkong Post 的看心情吧。

6 天前

回复了 libasten 创建的主题 › 问与答 › 在颜色失真的显示器上用工具截图（QQ 微信）截图，发到其他显示正常的电脑上，显示正常吗？

目前会出问题的是开了系统 HDR 的时候，QQ 截取使用非 sRGB 应用的内容是颜色会偏，目前只有 Xbox Gamebar 的 HDR 截图是正确的。
不然你怎么调都不影响。

7 天前

回复了 jimmyczm 创建的主题 › 问与答 › PKI 体系中，由 SSL/TSL 实现 HTTPS 应用，浏览器和服务器之间用于加密 HTTP 消息的方式是？

B
TLS 握手的目的是得到双端共享但对第三者保密的 session key ，目前使用的对称加密主要是 AES-128/196/256-GCM 和 CHACHA20-POLY1305
公钥加密速度很慢，所以通常只会用来加密少量数据，例如握手阶段可能会用 RSA 加密/签名用于协商的参数（例如 client dh parameter 或者 premaster secret ，数据量非常小），大批量的数据加密交由更快的对称加密完成。

12 天前

回复了 wildlynx 创建的主题 › 分享发现 › 微软 Windows 11 24H2 屏蔽第三方 UI 自定义工具

这些软件是通过未文档化的方式注入 explorer 来实现的，等于是依赖不公开的 api ，实际上每次系统更新都需要手动适配和测试，没有兼容性保证。
作为开源软件基本要等系统发布之后才会适配的。微软只是用这种方法提醒用户需要留意软件更新，在适配前暂时停用软件，别把锅扔到微软头上。
当然你也可以说微软歧视非商业软件,因为之前 360 惹事的时候微软可没建议用户卸载 360 。

12 天前

回复了 liuzhengdong666 创建的主题 › 分享发现 › 为什么 usb 不做一个无线的标准？

有啊，Wireless USB ，可惜已经挂了。
现在有这需求的会考虑用兼容以太网的协议栈来搞，例如 wifi 或者雷电网桥。
实际上 BT3.0+HS 标准就是借 Wifi 设施做传输的，不过一样挂了。
个人感觉还是商业竞争的考量吧，这种纯应用层的标准现在都不太好推统一的。

13 天前

回复了 bclerdx 创建的主题 › 硬件 › 关于电脑或手机总说的性能不行了，于是就各种卡顿，这个性能到底说的都是哪些？

对非游戏应用的话就是响应速度，就是点一个按钮之后提供视觉反馈的时间。以前这个瓶颈通常是硬盘，现在普及 nvme ssd 后有些情况压力就来到 cpu 上了。例如你可以试下在 tdp 15w 以下的低压 u 上禁用睿频，浏览器的响应速度是会有一定程度下降的。

14 天前

回复了 Lach 创建的主题 › 微信 › 微信数据迁移也太烂了！求替代方案！

@kome
只能说微信的 PM 都只用无线网络的，符合 TX 的办公环境。
可以试下备份时把手机微信的定位/附近设备权限 ban 了，就不会问这个了。

14 天前

回复了 Lach 创建的主题 › 微信 › 微信数据迁移也太烂了！求替代方案！

先行做记录清理，例如什么水群广告群就别备份了。
可以试下分批备份，而且务必使用稳定的网络，备份时不要锁屏保证微信前台运行。

14 天前

回复了 rookiemaster 创建的主题 › C › 用 riscv64- Linux -gnu-gcc 编译的 c 文件为啥能在 x8664 下运行？

可能是利用了内核的 binfmt_misc 机制自动调用 qemu 运行了。

14 天前

回复了 studyingss 创建的主题 › NAS › 为了应对运营商考核上下行比率，恩山无线论坛用户和某云盘使用恶意软件从 Bittorrent 网络无限吸血以提高下载量

我也不明白，咋不去找 CDN 接刷单生意呢，考虑到现在 CDN 价格战的问题，应该有厂商愿意搞。

14 天前

回复了 efsg 创建的主题 › Android › 安卓备用机怎么去除 72 小时就要输入密码的限制？

防这个的正确设置是设置 SIM 卡开机 PIN （十几年前就有的功能），不然人家可以拆卡换机。
不过具体到微信倒不用担心这个，微信在新设备上不能只靠验证码登录。
SIM 卡 PIN 只有重启时要输，但输错三次锁卡需要 PUK 解锁（透过运营商查或者大卡套上印着），PUK 错 10 次会导致 SIM 卡自毁，换机无法绕过，所以用这功能的话不要让熊孩子乱摸。

SIM 卡 PIN 可以有效防止社工攻击

https://mp.weixin.qq.com/s/GkznuJlyu6NjwqwiJgBtTg

14 天前

回复了 drymonfidelia 创建的主题 › 宽带症候群 › 家用路由器的 IP 地址设置在 .1 还是 .254 更好？用哪个网段最合适？为什么？

我建议.1 ，因为短，但第三位建议除 0/1 外随便选个，因为 1 被光猫占了，0 太容易跟别的路由冲突。

16 天前

回复了 yyzh 创建的主题 › 全球工单系统 › 阿里云又裁员裁到大动脉了?

起草估计都是委托外部企业咨询机构的，自家法务就负责 review 一下。
特别是这种针对所有用户的格式条款，至少我觉得审核态度就没那些商务大单合同那么认真，因为就算有些小错误也没啥实际影响。

18 天前

回复了 hello267015 创建的主题 › 随想 › 瞎琢磨：迷信是个体问题吗

OP 说的这种人，如果做到中高层管理，还算合理，因为知道自己的事业走向就是无法掌控的，所以寄希望一些你认为迷信的方式“行善积德”，以求关键节点发挥作用。
宗教很吸引人的一点就是能解释一切而且逻辑自洽，如果科学无法给出答案，寻求宗教解释也算合理。

18 天前

回复了 hello267015 创建的主题 › 随想 › 瞎琢磨：迷信是个体问题吗

如果当一个人意识到它做的事情的发展就是不可控的，就会通过迷信行为获取**虚假的掌控感**，毕竟认知里也没有更好的手段了。
认知水平低的人容易迷信，因为他不知道问题已经有成熟的解决方法。
认知水平高的人容易迷信，因为他知道问题已经不是靠努力和现有理论就能解决的。
你看那些站在行业顶端大佬，多多少少都会有这种行为，可能还会把这玩意包装成成功经验，毕竟，做到顶端只靠能力是不行的，但怎么可能公开承认自己是靠走狗屎运/灰色地带赚钱呢。

18 天前

回复了 xinbaoCode 创建的主题 › 程序员 › [讨论] 如何减少 Xz Backdoor 类似问题的发生

用闭源软件方便啥都不懂的用户获得虚假的安全感，不知道就是不存在。大团队的产品可能愿意公开透明做安全通报也有内部审计内部质控，小团队的你猜会不会否认三连+堵用户口。

我是个人用户，我就是穷，我相信 review 和使用的人越多的开源软件越可靠，因为更好的安全审计我请不起。而且，能看到公开复盘，那不就说明这套审查机制有用嘛。

18 天前

回复了 hope7 创建的主题 › 问与答 › vue 中文名威优易

名字取得还可以。
unity 引擎中文名团结引擎，你就说团不团结吧？

18 天前

回复了 ing995683 创建的主题 › 程序员 › xz-utils 后门事件

@AoEiuV020JP
受影响的是属于 xz-utils 项目的 liblzma,后者只要用到 lzma 就有可能中招，只是这次攻击代码只针对 systemd+openssh ，分别用来压缩日志和 ssh 流量。
lzma 作为目前最高压缩率的无损压缩算法，应用范围就广了，只是使用方可能选择自己实现而不是链接 liblzma 罢了

@NewYear 5.6.0/5.6.1 ，不是滚动发行版基本碰不到，太新了。

18 天前

回复了 sankooc 创建的主题 › 程序员 › HSTS 诡异的问题

@rrfeng
这个 preload list 是要申请的,审核要求整个域名响应都要带 HSTS includesubdomains 、preload 和足够长的 maxage ，目的是防止首次访问的 http->https 跳转就被劫持。因为很难撤回，所以只建议在 https 部署稳定可靠后再申请 preload 。

https://hstspreload.org/

@shierji 是不是 HSTS 头配错了(添加了 preload 属性，不打算预置的绝对不要加)，然后被第三者申请 preload 了。

18 天前

回复了 jeesk 创建的主题 › Android › 有什么办法压缩 android ndk .so

打分架构包，例如纯 arm64-v8a 包，这种大部分应用都做了。

还有，你先搞清楚你在乎的是 apk 大小还是传输大小。
google 推荐不要压缩 apk 内的 so ，因为系统可以直接从 apk 加载 so,否则需要额外先用一份空间存放解压的 so 。
google play 分发 apk 会使用 http 传输层压缩，所以实际传输大小并没有显著变化的。
动态下载 so 先不说合规和安全问题，你的 cdn 只要支持传输层压缩(不会还有不支持的吧？)，最终传输大小应该是跟整包 apk 差不多的，除非动态加载的逻辑很大。
当然我知道没多少人知道这些。可能国内的应用商店都把这搞错了，开发者都知之甚少的何况用户了。

1 2 3 4 5 6 7 8 9 10 ... 100

❮

❯