V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  v2tudnew  ›  全部回复第 1 页 / 共 73 页
回复总数  1446
1  2  3  4  5  6  7  8  9  10 ... 73  
1 天前
回复了 198plus 创建的主题 信息安全 关于 2FA 和密码
目前大部分的 2FA 都可以用邮箱、手机号解除,密码保管类软件也可以存储。
纯手机号登录倒是方便了,别人捡到也方便登录账户(不管有没有价值,反正挺恶心)。
10 天前
回复了 jedeft 创建的主题 编程 有了 AI,编程语言也要消失了
你说的可能是汇编?
16 天前
回复了 NevadaLi 创建的主题 问与答 rdp 机器暴露公网实验结果
这种是测试脚本攻击能否攻破 RDP ,互联网上 99.99%的个人机器都是无法确定具体价值,有一定参考价值。
19 天前
回复了 zuotun 创建的主题 问与答 宽带没有 IPv6 应该怎么解决?
IPv6 拨号失败?那大概率是运营商给关了。
投诉把工信部的 IPv6 推广信息塞进去,不行再工信部投诉。

如果是为了整治 PCDN ,可能比较难。
19 天前
回复了 v2tudnew 创建的主题 问与答 DDNS 解析同步问题
@blackeeper
你俩都盯着 TTL 作甚,这个和 TTL 没关系知道吧?你域名设置 1s TTL 阿里也会缓存,建议你搜下“乐观缓存”

谷歌、CF 、Open 这些都正常,你域名 TTL 过期了就是过期了,不会擅自修改你的 TTL 。这和收费不收费无关。

域名这个我在上面已经回答了,因为没有这厂商方便,不是不会。
19 天前
回复了 v2tudnew 创建的主题 问与答 DDNS 解析同步问题
@flynaj 前提是 DNS 服务器遵守 TTL 规范
19 天前
回复了 v2tudnew 创建的主题 问与答 DDNS 解析同步问题
@yinmin
谢谢,但我不想换厂商,dynv6 的 IPv6 更改方式很好用。
而且阿里 DNS 那个乐观缓存是 DDNS 的天敌,加 200ms 解析延时都不想用它家的。
19 天前
回复了 v2tudnew 创建的主题 问与答 DDNS 解析同步问题
@yinmin 类似换家 DDNS 服务商,但并不能防止阿里云 NS 服务器也抽风。
22 天前
回复了 lengchenyang 创建的主题 宽带症候群 公网 ip 不是随机分配的吗
@bn
烦,而且不支持调整拨号时长,不过可以缓解。
1. 用专业 DDNS 厂商服务,一般都是 60s TTL ,你的域名添加 CNAME 解析就行。
2. 把拨号设置定时在不用的时段,比如半夜 3 点。
24 天前
回复了 CodeAllen 创建的主题 程序员 高压缩率的归档工具求推荐
@2067
速度慢是它只用单线程,但遗憾得是,它压缩后的体积和 LZMA2 差不多:
UHA 1,328,559,204 字节 7z 1,324,688,260 字节
可能是比 LZMA 的 7z 压缩率高,所以当时是世界第一吧。

像我说的游戏高压版,那是相当离谱,我举个例子:
原文件:26.7GB 7z:23.1GB 高压版:8.3GB ,没错 8.3GB😅
24 天前
回复了 CodeAllen 创建的主题 程序员 高压缩率的归档工具求推荐
@2067 谢谢,不清楚是不是,我试试这个。
24 天前
回复了 CodeAllen 创建的主题 程序员 高压缩率的归档工具求推荐
@CodeAllen 之前有人建议 7z 开发者支持,对方的大概意思是 7z 得保持高压缩比,加了恢复记录体积变大了,反正也不影响第三方搞。😅
有第三方中继 100%,没有得具体情况具体分析。
24 天前
回复了 CodeAllen 创建的主题 程序员 高压缩率的归档工具求推荐
@RecursiveG 已经支持内嵌 7z 压缩文件,不过我觉得这种和 RAR 恢复一样,恢复后压缩包就失去恢复能力又要折腾,不喜欢。
24 天前
回复了 CodeAllen 创建的主题 程序员 高压缩率的归档工具求推荐
@2067 #5 “少量误码”这个评价我觉得有失公允,你拉到 100%别说损坏个几十%,文件丢了也能完整恢复,当然正常情况也就是位衰减几个比特,不需要太多。
24 天前
回复了 CodeAllen 创建的主题 程序员 高压缩率的归档工具求推荐
我也想知道哪个工具压缩率高,好像游戏高压版这类工具压缩率就可以。
7z 是没有恢复记录的,你可以用独立的 PAR2 软件生成恢复记录。
不推荐 RAR 恢复记录,恢复效果很玄幻。

如果你是两块硬盘互相备份,恢复记录有 1%都够用了,毕竟两个副本同时损坏一个分块的概率不比彩票头等奖大。
@epiphyllum

1.
>图上并不是虚拟内存占满了

你提交内存都 61.9/62.6GB 还说没满,你这个工具我不懂,但 Windows 只认这个提交(虚拟)内存。
你要是搞个 40/62 GB 崩了还有点说服力

2.
>overcommit 是灵活的变通手段

我反正不能接受 100/20 GB 这种奇怪的虚拟内存使用量,而且没有杀死进程的手段情况下崩溃的风险很大。

3.
>Windows 上离极端情况还差得远的时候

你这前提条件就不成立,至于要选择权你得找微软。

4.
你不想比反正手机杀进程的事实也在那

5.
> Windows 并不会默认在所有分区上创建 pagefile.sys 。

这点确实是我的失误,默认只分配系统盘。
@epiphyllum
你那张图无非是虚拟内存占满了,肯定是崩溃的,我上面已经说了你可以调大页面文件,实际它不会立即写入。
这种情况不是和 overcommit 一样的效果,没有 oom-killer 的情况下 Linux 内存占满它就不会崩了?
所以关键的还是 oom-killer 杀死进程,但普通人如何配置哪些进程被杀死?
像手机游戏就经常被杀,加大学习成本研究守护方法。
默认 Windows 是所有分区分配页面文件的,自己不调没这个问题。
1  2  3  4  5  6  7  8  9  10 ... 73  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   990 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 57ms · UTC 20:05 · PVG 04:05 · LAX 12:05 · JFK 15:05
Developed with CodeLauncher
♥ Do have faith in what you're doing.