2作者: onyks3 个月前
您好,我制作了这个透明代理,因为它想做一个用起来顺手的工具。你只需要打开它,然后就可以忘记它的存在了,当你关闭它时,你的电脑就会恢复到之前的状态。 简而言之,TTP 拦截所有 TCP 流量和 DNS 查询(使用 nftables),并将它们分别重定向到 Tor 的 TransPort 和 DNSPort。关闭时,它会原子性地销毁其专用表,而不会破坏你机器上的网络配置。 它还实现了针对 TTP 启动前已建立的连接的“紧急停止开关”(拒绝传出流量,从而使用安全连接自动重新建立连接)。 最后,它提供了 SELinux 自定义策略,并且具有崩溃安全保护(使用 /var/lib/ttp 中的锁文件)。 免责声明:此工具并非用于高风险活动。我不建议将其用于隐私和/或测试/开发以外的任何目的。 最后,这只是一个本科生 CS 学生开发的 v0.1.0 版本。我制作这个是为了学习,所以,请大家帮帮我!谢谢大家。 Github 链接:<a href="https://github.com/onyks-os/TransparentTorProxy" rel="nofollow">https://github.com/onyks-os/TransparentTorProxy</a> 文档:<a href="https://onyks-os.github.io/ttp/" rel="nofollow">https://onyks-os.github.io/ttp/</a>
3作者: electricant3 个月前
Firefox 149 版本中,内置了 adblock-rust (Brave 的 Rust 引擎,MPL-2.0 协议),但默认完全禁用且没有用户界面。它由两个 about:config 配置项控制,并且没有 WebExtension API,因此无法通过标准扩展程序以编程方式进行修改。 这个扩展程序为其提供了用户界面:ETP 切换开关(通过 browser.privacy API,即时生效),过滤器列表管理器,带有剪贴板辅助功能,方便手动修改 about:config 设置,以及 8 个预设列表。你也可以根据需要添加自己的列表。
1作者: wilbur_whateley3 个月前
大家好,我一直在制作一款类似国际象棋的游戏,其中的棋子拥有特殊能力和生命值。这使得游戏在平衡性方面可以做得更好,并且可以衍生出比普通国际象棋更多的变体。例如,棋子可以推或拉其他棋子,造成范围伤害(AOE),拥有大量生命值且难以摧毁,使用远程攻击等等。<p>目前没有视频解释所有规则,但当前版本与国际象棋非常相似。以下是您需要了解的主要内容:<p>1) 标准攻击 - <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=OhGNNlnM7K8" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=OhGNNlnM7K8</a><p>2) 特殊能力 - <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=XbE_jL7RB0E" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=XbE_jL7RB0E</a><p>这是链接 - <a href="https:&#x2F;&#x2F;www.nichess.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.nichess.org&#x2F;</a>(您无需注册即可试玩,只需开始一个新游戏)。<p>如果有人有任何想法或建议,我很乐意听取。
2作者: karlosh3 个月前
如果编码速度加快,架构应该在哪里进行? 一个功能可以运行。测试通过。PR 也不大。业务希望进行实时测试。没有人希望因为在当时听起来可能很抽象的架构问题而阻碍价值交付。 但这种情况似乎变得越来越难。 AI 辅助开发、氛围编码、内部工具和更好的框架都降低了生成代码的摩擦。这很有用。团队可以更快地进行原型设计并尽早发布实验。 问题是架构判断并没有变得同样廉价。 代码可能可以运行,但仍然会使系统变得更糟:逻辑重复、所有权不明确、模式不一致、安全漏洞、糟糕的边界、本应可重用的一次性组件,或者以后难以删除的功能。 一种选择是在代码审查中强制进行更多架构设计。但这样一来,PR 就会变得缓慢、令人沮丧,并且充满了设计争论,而这些争论在代码已经存在之后就很难解决了。 另一种选择是更快地合并,同时使合并后的架构反馈循环更加明确。架构应该已经是持续的,但更快的代码创建可能需要更强大的合并后机制:审查系统级别的更改、检查重用机会、重新评估安全假设、安排重构、将功能置于标志之后,并愿意禁用或重写内容。 这只有在“稍后重构”成为一个实际过程而不是一个愿望时才有效。 随着代码变得更容易生成,您的团队是否改变了处理架构的方式?您是在合并之前、合并之后还是通过某种持续审查过程来处理这个问题?