返回首页
最新
Linux桌面已经花费了十多年时间在新的图形栈上进行过渡。Wayland带来了许多优势，尤其是在移动设备风格的安全性和简洁性方面。但在这个过程中，我们悄然失去了一些宝贵的东西：曾经使Linux图形模型独特的分布式、基于协议、与传输无关的理念。
这并不是怀旧。这些能力对于远程工作、自动化、多机器工作流、瘦客户端、云桌面以及未来的分布式系统至关重要。它们并不是“遗留特性”；而是可能再次变得重要的架构优势。
问题不在于Wayland本身，而在于它从未被设计来支持这些用例。它的理念是故意局限于本地、单用户和以合成器为中心。这对于移动设备来说是完全合理的，但对于桌面和分布式环境来说却留下了空白。
另一方面，Xorg面临的是一个老化的实现，而不是过时的理念。它的核心思想——基于协议的渲染、远程执行、可组合性和传输独立性——依然相关。我们缺乏的是一个现代的、简约的、仅基于协议的继任者，能够保留这些优势而不带有Xorg的历史包袱。
这样的项目不需要复制Xorg的全部功能集。它不需要服务器端渲染、字体、输入法、窗口管理或安全策略。它只需定义一个干净、现代的协议和一个稳定的抽象层。现有的合成器可以实现它，现有的驱动程序无需更改，Mesa也不需要进行重大重设计。工程工作量远小于重写整个图形栈。
这并不是呼吁取代Wayland，而是呼吁承认Linux桌面可能需要不止一种图形模型。一个以协议为先、与实现无关的层可以与Wayland共存，互为补充，并保留那些否则会消失的能力。
如果没有人开始这项工作，行业将自然趋向于移动风格的图形架构，而过去的分布式能力可能会被遗忘很长时间。但如果有人开始一个现代的、仅基于协议的Xorg继任者，社区或许最终会找到一种平衡简洁性与桌面曾经拥有的灵活性——而这种灵活性可能再次变得必要。
我创建了 GRSH，因为我想要一个现代的、内存安全的 shell，它在 FreeBSD 上感觉原生，但在 macOS 上也能无缝运行。
虽然市面上有很多 shell，但 GRSH 是我对一个简约、快速且安全的命令解释器的理解，它完全用 Rust 编写。它的设计旨在为那些希望享受 Rust 安全保障的用户提供服务，而不需要承受更臃肿替代品的负担。
我目前正在开发官方的 FreeBSD 移植版。希望能从社区获得关于 shell 行为和性能的反馈。
Github: [https://github.com/antoniomalara301289/grsh](https://github.com/antoniomalara301289/grsh)
你好，HN！我正在整理一个由社区维护的个人网站目录，网址为 <https://hnpwd.github.io/>。关于该项目的更多细节可以在 <https://github.com/hnpwd/hnpwd.github.io#readme> 的自述文件中找到。
如你所见，目录目前只有少数条目。我需要你的帮助来扩展它。如果你有个人网站，我很高兴你能在这里分享。如果你的网站托管在你可以完全控制其设计和内容的空间上，并且在过去的HN讨论中获得了良好的反馈，我可能会将其添加到目录中。只需在评论中留下链接即可。如果你不希望你的个人网站被包含在目录中，请告诉我。
此外，我希望这个资源能够由社区共同维护，因此如果你想作为维护者加入GitHub项目，请在这里或通过自述文件中的IRC链接告诉我。
顺便提一下，看看“Ask HN: Could you share your personal blog here?” - https://news.ycombinator.com/item?id=36575081 - 2023年7月 - （1014分，1940条评论）。不过在这篇帖子中，范围并不限于博客。任何个人网站都欢迎提交，无论是博客、数字花园、个人维基还是其他任何形式的网站。
“我修复了Microsoft AutoGen中的‘僵尸状态’错误。
问题：操作性缺血。在原子转换期间的进程中断使得代理处于一种矛盾状态：工作量大于0，但队列为空。工作流停滞，错误地报告完成。
解决方案：主权图守护。
铁封协议：用原子fsync + 重命名（POSIX持久性保证）替代标准文件写入。这确保了零妥协状态的持久性。
缺血修复：实现了一种自愈逻辑（load_and_heal），在状态加载时扫描并重新注入待处理的代理。
零分配序列化：将我在优化谷歌的Go-GitHub库时的经验（通过缓冲池实现了3倍的速度提升）移植到Python的序列化逻辑中。
结果：维护者称其为‘典范’和‘杰出’。不再有僵尸工作流。
理论：这实现了我在黎曼假设论文中证明的相同‘拓扑稳定性’原则——系统必须在同调结构上是健全的，才能抵御熵的影响。
<a href="https://www.academia.edu/145999987/The_Spectral_Geometric_Proof_of_the_Riemann_Hypothesis_An_Isomorphic_Mapping_of_Computational_Complexity_to_Arithmetic" rel="nofollow">https://www.academia.edu/145999987/The_Spectral_Geometric_Proof_of_the_Riemann_Hypothesis_An_Isomorphic_Mapping_of_Computational_Complexity_to_Arithmetic</a>”
<i>wxpath</i> 是一个声明式的网络爬虫，网络爬取和数据提取直接通过 XPath 表达。<p>与其编写命令式的爬取循环，不如在一个表达式中描述要跟随的内容和要提取的内容：<p><pre><code> import wxpath
# 爬取、提取字段，构建维基百科知识图谱
path_expr = """
url('https://en.wikipedia.org/wiki/Expression_language')
///url(//main//a/@href[starts-with(., '/wiki/') and not(contains(., ':'))])
/map{
'title': (//span[contains(@class, "mw-page-title-main")]/text())[1] ! string(.),
'url': string(base-uri(.)),
'short_description': //div[contains(@class, 'shortdescription')]/text() ! string(.),
'forward_links': //div[@id="mw-content-text"]//a/@href ! string(.)
}
"""
for item in wxpath.wxpath_async_blocking_iter(path_expr, max_depth=1):
print(item)
</code></pre>
关键的新增功能是 `url(...)` 操作符，它获取并返回 HTML 以供进一步的 XPath 处理，以及 `///url(...)` 用于深度（或分页）遍历。其他部分都是标准的 XPath 3.1（映射/数组/函数）。<p>特点：<p>- 异步/并发爬取，结果流式输出<p>- 受 Scrapy 启发的自动限速和礼貌爬取<p>- 自定义处理的钩子系统<p>- 快速实验的命令行界面<p>另一个示例，通过 HN 评论（通过 "follow=" 参数）分页并提取数据：<p><pre><code> url('https://news.ycombinator.com',
follow=//a[text()='comments']/@href | //a[@class='morelink']/@href)
//tr[@class='athing']
/map {
'text': .//div[@class='comment']//text(),
'user': .//a[@class='hnuser']/@href,
'parent_post': .//span[@class='onstory']/a/@href
}
</code></pre>
限制：仅支持 HTTP（尚不支持 JS 渲染），不支持爬取持久性。如果有需求，这两项功能都在开发计划中。<p>GitHub: <a href="https://github.com/rodricios/wxpath" rel="nofollow">https://github.com/rodricios/wxpath</a><p>PyPI: pip install wxpath<p>欢迎对表达式语法和可能解锁的任何用例提供反馈。<p>谢谢！