@Esay https://developer.apple.com/reference/networkextension/netunnelprovider

@chaucerling 我也不知道，没有研究过 cask

@chaucerling 最大的问题就是 cask 和自带更新很难协作

其实看到从 11 月 1 号开始我就明白这个计划的结局了。

基础如何，学习能力如何，市场环境如何都还可以放一放，我相信努力学习自然有回报，机会总是会有的。

但是楼主 11 月 1 号之前要干嘛呢？好好享受这魔鬼学习计划开始前的闲暇？

认清自己吧，你不会有毅力学的，你连从今天开始的毅力都没有。

虽然在 Rails 之前的框架基本都是一坨，但是 Rails 之后的模仿者还是很多的，很难说那些模仿的框架比 Rails 的开发速度更低，当然 php 做为最好的语言我不想评价。我理解第一次看到 Rails 的震惊，不过今天其它语言也已经有类似的框架了。

@lzs5240 不能

@iWill 嗯。谢谢建议

耳机这个东西未来一定是无线的，至于 lighting 的耳机，都只是过渡方案而已
有人说这是不 macbook 一个耳机， iPhone 一个耳机了，但事实上苹果的设计是大家都是蓝牙耳机（注意到 airpod 的网页还专门说了这个耳机同时在所有设备上使用是多么方便），就使用场景而言自然就没有任何的问题了。
当然，你说买不买得起耳机（蓝牙耳机现在真的不贵了，尤其是如果 iPhone 能够带起一大波销售的话价格更低），已经有了的耳机怎么办，就如同光驱／不能换电池一样，苹果在这些问题上一向很激进

@chztv 其实 SpechtLite 都不是我的本意，而是 NEKit 的副产品，我本身只是把它作为一个 demo 而已。
NEKit 的文档明确指出不建议使用自带的配置文件， NEKit 提供的是功能，配置方式应该由 App 自行处理。 SpechtLite 当前使用的配置文件其实只是 NEKit 提供来快速构建原型用的。
当然我可以直接去支持 gfwlist ，第一我本人不用这种体验不好的方式，毕竟被封的很多网站并不再列表中，还有很多基本无法正常访问的未被封网站，第二支持 gfwlist 本身不符合 NEKit 的设计理念，一个构建原型的组件为何要支持如此复杂的功能？如果 App 想要支持 gfwlist ，那么应当由它自行完成，如果处理过程中需要 NEKit 提供一些通用的基本功能，那么 NEKit 可以实现。
但支持 gfwlist 就意味着 SpechtLite 开始提供超越了 demo 的功能了，这样的话 SpechtLite 需要的改进就太多了， NEKit 本身就有很多的事情还要做，外加我还有很多其他的事情，所以……

@iWill 格式有点乱了，你理解一下就好

@iWill 我随便写一下，你自己理解下：
大致上你需要先定义两个 adapter ：
- id: proxy
type: http/ss 你自己看
- id: reject
type: reject

然后定义两个 rule
- type: list
file: reject_list
adapter: reject
- type: list
file: whitelist
adapter: proxy

然后在 reject_list 里：
cnzz
3600\.com$

在 whitelist 里：
youtube

要是有人愿意写教程就好了，我真的没这个心情和时间

@iWill 规则不通用，想屏蔽广告的话建个广告域名的 list 转发到 reject 这个类型的 adapter 去。

@chztv ……你自己写啊，不需要可以直接把 rule 删掉，说明里也有写这两个文件应该怎么写的，就是一行一个 ip 或者正则

等于说每年花 988*0.5+5288*0.5 可以一直用新机器？不供起来正常使用一年的机器能卖多少钱？

@WildCat BSD

@blankwonder 我想过这个问题，除了 UDP 和 TCP 所有的包都要丢， ipv6 的话可能有更多问题，但是就个人角度完全没有影响。

@Sequencer 并没有， NEKit 是 BSD 3 ， Specht 是 GPLv3 ，没有改过