V2EX › v2tudnew 的所有回复 › 第 1 页 / 共 73 页

V2EX = way to explore

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

现在注册

已注册用户请登录

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

❮

❯

1 天前

回复了 NevadaLi 创建的主题 › 问与答 › rdp 机器暴露公网实验结果

这种是测试脚本攻击能否攻破 RDP ，互联网上 99.99%的个人机器都是无法确定具体价值，有一定参考价值。

3 天前

回复了 zuotun 创建的主题 › 问与答 › 宽带没有 IPv6 应该怎么解决？

IPv6 拨号失败？那大概率是运营商给关了。
投诉把工信部的 IPv6 推广信息塞进去，不行再工信部投诉。

如果是为了整治 PCDN ，可能比较难。

4 天前

回复了 v2tudnew 创建的主题 › 问与答 › DDNS 解析同步问题

@blackeeper
你俩都盯着 TTL 作甚，这个和 TTL 没关系知道吧？你域名设置 1s TTL 阿里也会缓存，建议你搜下“乐观缓存”

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

域名这个我在上面已经回答了，因为没有这厂商方便，不是不会。

4 天前

回复了 v2tudnew 创建的主题 › 问与答 › DDNS 解析同步问题

@flynaj 前提是 DNS 服务器遵守 TTL 规范

4 天前

回复了 v2tudnew 创建的主题 › 问与答 › DDNS 解析同步问题

@yinmin
谢谢，但我不想换厂商，dynv6 的 IPv6 更改方式很好用。
而且阿里 DNS 那个乐观缓存是 DDNS 的天敌，加 200ms 解析延时都不想用它家的。

4 天前

回复了 v2tudnew 创建的主题 › 问与答 › DDNS 解析同步问题

@yinmin 类似换家 DDNS 服务商，但并不能防止阿里云 NS 服务器也抽风。

6 天前

回复了 lengchenyang 创建的主题 › 宽带症候群 › 公网 ip 不是随机分配的吗

@bn
烦，而且不支持调整拨号时长，不过可以缓解。
1. 用专业 DDNS 厂商服务，一般都是 60s TTL ，你的域名添加 CNAME 解析就行。
2. 把拨号设置定时在不用的时段，比如半夜 3 点。

9 天前

回复了 CodeAllen 创建的主题 › 程序员 › 高压缩率的归档工具求推荐

@2067
速度慢是它只用单线程，但遗憾得是，它压缩后的体积和 LZMA2 差不多：
UHA 1,328,559,204 字节 7z 1,324,688,260 字节
可能是比 LZMA 的 7z 压缩率高，所以当时是世界第一吧。

像我说的游戏高压版，那是相当离谱，我举个例子：
原文件：26.7GB 7z：23.1GB 高压版：8.3GB ，没错 8.3GB😅

9 天前

回复了 CodeAllen 创建的主题 › 程序员 › 高压缩率的归档工具求推荐

@2067 谢谢，不清楚是不是，我试试这个。

9 天前

回复了 CodeAllen 创建的主题 › 程序员 › 高压缩率的归档工具求推荐

@CodeAllen 之前有人建议 7z 开发者支持，对方的大概意思是 7z 得保持高压缩比，加了恢复记录体积变大了，反正也不影响第三方搞。😅

9 天前

回复了 qazwsxkevin 创建的主题 › 宽带症候群 › （关于打洞) ， A 在电信宽带的大 NAT 内(100.*.*.*)， B 在不知 NAT 了多少层的园区网内， B 要访问 A 的一些 TCP Port，不想用商业性的远程服务，先决条件，是不是必须自有一个公网服务器(C)做支撑辅助？

有第三方中继 100%，没有得具体情况具体分析。

9 天前

回复了 CodeAllen 创建的主题 › 程序员 › 高压缩率的归档工具求推荐

@RecursiveG 已经支持内嵌 7z 压缩文件，不过我觉得这种和 RAR 恢复一样，恢复后压缩包就失去恢复能力又要折腾，不喜欢。

9 天前

回复了 CodeAllen 创建的主题 › 程序员 › 高压缩率的归档工具求推荐

@2067 #5 “少量误码”这个评价我觉得有失公允，你拉到 100%别说损坏个几十%，文件丢了也能完整恢复，当然正常情况也就是位衰减几个比特，不需要太多。

9 天前

回复了 CodeAllen 创建的主题 › 程序员 › 高压缩率的归档工具求推荐

我也想知道哪个工具压缩率高，好像游戏高压版这类工具压缩率就可以。
7z 是没有恢复记录的，你可以用独立的 PAR2 软件生成恢复记录。
不推荐 RAR 恢复记录，恢复效果很玄幻。

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

10 天前

回复了 liuhaitaoSB 创建的主题 › 分享发现 › [分享发现] B 站这个不想看此 up 和内容不感兴趣不太行

https://greasyfork.org/zh-CN/scripts/465675-b 站用户屏蔽

26 天前

回复了 korvin 创建的主题 › 问与答 › Windows 还有 1/3 内存可用， Chrome 经常报内存不足（Out of Memory）

@epiphyllum

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

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

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

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

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

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

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

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

这点确实是我的失误，默认只分配系统盘。

26 天前

回复了 korvin 创建的主题 › 问与答 › Windows 还有 1/3 内存可用， Chrome 经常报内存不足（Out of Memory）

@epiphyllum
你那张图无非是虚拟内存占满了，肯定是崩溃的，我上面已经说了你可以调大页面文件，实际它不会立即写入。
这种情况不是和 overcommit 一样的效果，没有 oom-killer 的情况下 Linux 内存占满它就不会崩了？
所以关键的还是 oom-killer 杀死进程，但普通人如何配置哪些进程被杀死？
像手机游戏就经常被杀，加大学习成本研究守护方法。
默认 Windows 是所有分区分配页面文件的，自己不调没这个问题。

26 天前

回复了 punish19 创建的主题 › 哔哩哔哩 › 一打开 B 站，电脑风扇狂转

大概率是插件和脚本的问题，不要只说风扇，看看是 CPU 还是 GPU 问题。
之前播放一段时间，Chrome 任务管理器 CPU 持续 100%，后来把几个油猴脚本关了就正常了。

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

❮

❯