首页   注册   登录
 Jirajine 最近的时间轴更新

Jirajine

V2EX 第 417035 号会员,加入于 2019-05-30 22:57:00 +08:00
今日活跃度排名 1253
Jirajine 最近回复了
15 分钟前
回复了 qdwang 创建的主题 分享发现 关于国内外通讯工具 [已阅读] 的发现
这个功能应该允许用户选择,开了增加沟通效率,关闭的作用不必多说。
2 小时 52 分钟前
回复了 Kamitora 创建的主题 硬件 大容量机械硬盘 & 硬盘盒, V 友有推荐的吗?
@imn1 想问 hgst 现在怎么买?
随便一搜个个自称全新,我一查果然可以改通电时间。
@lcdxiangzi 抱歉,这个博主名头太大,属实不敢墙内传播。你可以试试他推荐的 btsync 免翻墙同步,好像也有一些免翻解析 onedrive 链接的工具。
同推荐 https://github.com/programthink/books
基本上都打包好了,挑你喜欢的看。
@lalalakakaka
2. 是从大部分地区下个 bt 就喝茶,大部分 vps 下 bt 就封号得来的,这是协议缺陷导致,“勉强维持”,“显得好些”是事实。
3. ed2k 不了解,这个确实是已经死了,不过我认为死因也是与协议有关(很多客户端都有 bt 的实现但支持 ed2k 的极其少见)。
4. pt 显然不是发布资源的方式,可能有些 pt 团体有部分自制内容,但大部分还是收集于网络,称为 bt 的上游并不妥当。
5. 看下 bt 协议的文档,你试试动手做一个只下载不上传的实现试试能否做到。(如果能的话只下载不上传免于 dcma 岂不美哉?早就会泛滥成灾了。)也许迅雷有非标准的实现偏担自家客户端(当然这也是协议的漏洞之一),但更多的是自家私有的 p2p 网络,这点和 pt 一致。还是那句话,真要吸血迅雷不会保持使用自己的 UA。
6. 可以通过迅雷发布资源,只需开一个 http 服务用迅雷下载一遍理论上就被其缓存,下线后其他用户也可以通过迅雷下载。同理发布种子时可以把文件上传到网盘再发布,这样其他用户就可以“秒离线”。
7. 不是积分的问题,是一段时间不下载就封,我觉得要下载先上传可以,但你没有我需要的东西我即不下载也不上传行吗?强制用户当 CDN 与迅雷后台偷偷挂 p2p 进程的流氓行径无异。
8. 缺陷是导致 bt 衰落的最主要原因,国内则是缺 ip,tracker,天价宽带,gfw 隔绝世界是主要因素。
现行的这些无论是离线网盘,pt,迅雷都是用中心化的方式,与 p2p 开放共享的初衷背道而驰,恰着灰色地带的烂钱。你说迅雷用非标准实现吸 bt 的血,我也可以说 pt 占用共享宽带吸其他用户的血,这些都是一丘之貉,谁也别说谁黑。然而这些因素的影响都不算什么,bt 衰落最根本的原因,还是协议的缺陷,或者说协议的“滥用”,别忘了,这协议原本设计是用来 C/S 下载加速的,结果被玩臭了。
起一个 usb live 的 Linux 发行版,
#dd if=/dev/(你的旧固态) of=/path/to/xx.img
在你的机械硬盘上生成 128gb 大小的镜像文件
然后换上新固态,
#dd if=/path/to/xx.img of=/dev/(你的新固态)
@billlee 没那么多,据我所知 sysfs 的已经封了,不过依然有漏洞广泛使用还一直不修,Google 当初搞阻止获取 mac 返回 02:00..就像是笑话。
@lalalakakaka #35
1. 你也知道那些花花绿绿的小国旗,那是很多国家啊,你把这些国家单拉出来就不一定了。所以不是国内环境不好,而是国内与世界隔离,所以显得更为贫瘠,这个锅还是 GFW。
3. 同上,不是国内活得不好,是全世界都活的不好,只是除了国内和世界互联网隔绝,全世界其他地方都聚在一起显得好了一些。而且国内商宽那天价比什么打击都有用。。
4. 如果我要发布共享一个文件不去上传网盘或 bt 却用什么 pt,那显然是很荒谬的。pt 本就不是发布共享的方式,“上游”的说法不敢苟同,你说某些内容被搬到里面下载的快确实是,这种搬运帮助了传播也是事实,但因其封闭的缺陷,这种帮助并不大。同样的,你把资源搬到网盘,bt 解析,离线下载的服务器,这样后来者直接“秒离线”,也是同样的道理。
国内 ip 被反向墙?这种情况不多,被 gfw 干扰出境连接的概率更大一些。

迅雷吸血的说法被夸大又以讹传讹,bt 协议实现就把上传下载挂钩起来,迅雷没有理由阻止用户上传,最多偏向自家客户端权重高一些,而国内迅雷用户数量庞大,也就造成了迅雷“只今不出”的错觉。迅雷若是真要吸血,何不直接把 UA 直接伪造成其他客户端的呢。到是现在普遍拉黑迅雷的 UA,倒是让迅雷自家自个玩,自己用自己的节点,自己用自己的 tracker,和 PT 是越发相似了。

两者区别只是一个更开放,资源丰富但树大招风将死不远。一个小众封闭不易被审查但内容贫瘠(资源丰富度只与用户量有关,不过 pt 资源健康度较高),只能他推什么你下什么,主动寻找什么资源并不容易(更坑的是长时间不下还不行,会被封,不想要也帮他“缓存”,迫真 CDN 啊)
对比危害一样能列一堆:大流量滥用家宽(加剧超售,占用共享资源),滥用打洞(加剧严格 nat 类型,公网 ip ),加剧上下行不对等等。

实际上这都是用中心化解决部分去中心化的问题的方式,本质上要么用户出流量滥用家宽,要么掏钱买在线服务,羊毛出在羊身上,协议不改进,这些灰色地带迟早药丸。
@Baymaxbowen #2 如果你指的是这个:
In Android P, Google rolled out a developer option to enable MAC address randomization, but it was turned off by default. With the first beta of Android Q, the option became the default.
那么没有效果,这个开启之后会为每个 ssid 使用一个随机的 mac,不换 wifi 不会变,并且所有应用读取到的值也一致。

Q 确实额外提供了仅有 device onwer 可访问的 api 来获取 mac 地址,但 native 层的这个漏洞确是一点都没提。
估计 Google 也不打算修了,只能去给 lineageOS 提 issue 看看能不能解决这个问题。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4127 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 32ms · UTC 08:42 · PVG 16:42 · LAX 01:42 · JFK 04:42
♥ Do have faith in what you're doing.