IceCodeNew

PKU Beijing 北京大学渣

Results 119 comments of


                                            IceCodeNew

trafficstars

`Name or service not known` Error when querying a DoH service at a non-standard port.

Sadly the DoH service I would like to test does not serve on 443 port. I have to specify the port someway.

关于 @attr 的语法扩展

> 其实主要有利于开发者进行维护，对于用户的实际使用，作用并不大。绝大多数用户是直接geosite:cn, geolocation-!cn这样用的。很多用户都是小白，连设置都不会，都是使用app/模板/脚本预设的规则。关于前半句话我并不同意。直接 geosite:cn, geolocation-!cn 这样用就是预期内的用法，并没有错误 > 我认为@attr应该按照特定地域用户能否连接这个域名、能否快速稳定的连接访问为基础分类。以大陆用户访问A域名举例：能够在大陆地区快速稳定访问A域名的，设一个@attr，如@cn-L1；能稳定访问，但因接入点在境外，并且CDN较差，导致实际访问速度慢的，设@cn-L2；不能稳定访问，时灵时不灵，根据用户需求，不设@attr或设@cn-L3。其他的国家，比如伊朗，也是一样，比如@ir-L1, @ir-L2。对于在全世界都有接入点的，可以用前面提到的anycast的思路，设@all-L1, @all-L2. attr 本身算是用户根据个人需要对项目的衍生。怎么设计 attr 是没有绝对的规范的。你的设想没有问题。但是从本项目维护的角度出发，这么多的 attr，没有量化的标准能够确定一个域名应该给什么 attr，而且给出的属性只能反映维护者个人的网络环境，并不适合做到这个项目里。前半部分导致维护成本高得离谱，难以落实；后半部分直接违背了这个项目的内容应该适合所有人使用的原则。所以我十分不建议在这个项目里这样做，你可以在自己 fork 的项目里这么做。 > 让各个国家需要此列表的网友自发为列表提交更新。不要想着几个开发者就把所有的事情搞定本身这个项目也是接受任何人为列表提交更新的。开发者的工作不体现在列表维护上，在于生成各类型数据库的代码维护上。你的理解有误。假设你后半句话指的是维护者，那么维护者的工作在于把关，确保每个共享者的提交都符合这个项目的维护原则，不能每个人都按照自己的理解和对自己方便的样子来改。 > 目前的编辑/架构方式，是不是需要改一改？我提一个思路：数据采用数据库的方式存放，外部接一个webhost，用于提交、审核修改。相当于，category是一个分类的（树状）维度，@attr是一个维度体系，内涵可交叉的多（树状）维度。多维度并存，可能还是数据库的方式更好一些？考虑你这个想法落实起来的工作量，可能在这个项目上做修改还不如直接开新的项目。我不评价你这个思路的好坏，因为只有做了才知道。但是我建议你先多从更新列表的贡献做起，加深对这个项目的了解。等积累一定的经验以后再重新构思这个项目应该如何改进。

关于 @attr 的语法扩展

> 是的，开发者和维护者应该被分为两个群体；开发者做架构，维护者做内容维护，这样思路就清晰了。我提出的其实主要就是关于“应该适合所有人使用的原则”这个问题。这方面，我认为应该从用户需求、群体、需求群体出发，去考虑和设计。要看现实中哪些用户在用。做一个项目，一个功能，一种架构思路，没有真正的用户在用，那就没意义。从用户的角度出发，事情就简单了：有一批大陆需要翻墙的用户；有一批伊朗要翻墙的用户；有一批要使用境外企业服务、玩外服游戏的用户；有一批境外想要看大陆视频的用户。可能还有一些需求群体。那么除了这个列表的需求群体，可以说就没有人再去使用这个列表了，也因此没必要为更宽广的使用场景设计列表结构。关于attr的标准，以及“只能反映维护者个人的网络环境”，我不同意你的看法。我的想法是，按照用户群体，由用户自发进行维护。把维护分成审核和提交（其实现在就是）。维护群组可以采取树状结构，上层级对应更广的地域/领域，具备更多的审核权限，下级的群组更具体，比如专门维护海外用户访问大陆视频。那么大陆用户的维护审核群组很容易去判断，哪个域名在大陆有接入点，应该作为cn-L1，哪个外部有接入点、并且大陆用户愿意去直连，作为cn-L2，哪个能直连，但代理更快，作为cn-L3。上层级的审核维护也许难以为全部人做出好规则，但是可以有下层级的审核维护群组代表更具体的用户群，做出的维护就能更好。从这个思路延展，甚至可以发展出“适合河南移动直连的域名”之类的细分类别----是否发展出，就可以全凭用户是否有需求，进而是否有人愿意主动去维护来决定了。开发者更省心，上层级的审核维护也更省心。从这个角度讲，其实也“适合所有人了”：有需求的用户按需求群组自发贡献规则；没有需求、不需要使用这个列表的，自然也不用去管。从这个角度讲，可能确实新开一个项目更合适；但是这里我想是与大家讨论。是否去做、是否开新项目这些，想好了考虑周全了再行动。我们还是没聊到一个频道上。而且我很久没在看母语写的文章时看得这么辛苦了。我觉得我之前的说明已经很明确了，所以我不会再补充别的废话。我只写一下我觉得你接下来可以采取的行动，你可以作为参考。觉得没道理的话，也可以不用照着做。但是我把我会采取的行动讲在前面，免得你浪费时间。 1. 解决你提议的 xx-Ln 属性没有量化标准的问题，确保任何人遵照这个规则都能给出一致的属性标注 2. 落实你的想法。如果你现在就在这个项目上做类似的事情，我会直接关闭相关的 issue 或者 pr。你可以先自己 fork 一个项目实践你的想法，如果我觉得新的项目完善得足够好了，我会来求你把你的成果 backport 回来。谢谢你为这个项目付出的时间和思考。

IceCodeNew

`Name or service not known` Error when querying a DoH service at a non-standard port.

关于 @attr 的语法扩展

关于 @attr 的语法扩展

v2ray 4.40.1 /usr/local/bin/v2ray Failed to execute command: No such file or directory

pin quic-go version

pin quic-go version

pin quic-go version

pin quic-go version

Add Information Disclosure and use only secure HostKeys

Add Information Disclosure and use only secure HostKeys