采访 Systemd 和 PulseAudio 创始人 Lennart

[陽光院景仁]

LinuxFR.org 近日对 Systemd 和 PulseAudio 的创始人 Lennart 进行了采访，其中有一些颇有意思的内容值得分享。
下文是采访内容的简要翻译。
首先是 Avahi，然后 PulseAudio，现在是 Systemd，你是如何在如此多个几乎不相关的领域做出这么大的贡献的？
实现 Avahi 的想法上是在研究 PulseAudio 的过程中出现的。在学习 mDNS/DNS-SD 网络协议过程中，我注意到现有的 Howl 实现有一些缺点和协议上的问题，于是打算重新由零开始实现它，Avahi 就是这样诞生的。
目前 Avahi 是 Linux 安装中唯一默认使用 chroot() 的守护进程（现在有另外一个 RealtimeKit 了，不过那个也是我编写的）。
在此之后我一直应该有初始化系统去解决这些问题，于是最终 Kay 和我提出并实现了 systemd 。
早期 PulseAudio 收到了很多批评。你认为这是由于 PulseAudio 还不够成熟，还是认为这些批评是不理智的？
PulseAudio 当然不是没有问题的，但当时发行版开始使用它的时候，很多问题是由于音频驱动而不是 PulseAudio 造成的。PulseAudio 基于时序的调度需要从音频驱动获得正确时序信息，而那时候的不少音频驱动并没有正确提供这些信息。而驱动没法提供正确信息的根本原因在于硬件的问题，导致在驱动层面难以找出合适的解决方法。
另外，请不要忘记在 Linux 音频通用堆栈方面只有 3.5 位全职开发人员。在如此少的人力投入下，目前成果相当不容易。当然距离 CoreAudio 还有差距，但已经相当接近了。所以在此希望那些不断抱怨的人可以更宽容些。
目前大多数硬件厂商已经意识到这个问题了，从某种程度上讲 PulseAudio 已经成为厂商驱动检查标准中的一部分了。当然，在较新的 USB 或者 HD 音频上设备依然可能出现问题。
另一方面，当时的选择也是迫不得已。在如此紧张的人力条件下，只能借助发布后的反馈来找出并修复错误。别忘记当年 CoreAudio 推出的时候，也是经历了类似的过程，而它现今已经成为音频堆栈的测试标准（现在也不是毫无问题，我上次尝试一个 USB 声卡时就出现了内核问题）。实现基于时序调度的音频堆栈是件相当复杂的工作，需要一段时间来达到稳定。
现在 Linux 平台上的音频堆栈和 Win 以及 OS X 平台上的相比如何呢？
Win 和 OS X 平台上音频堆栈的整合工作都比 Linux 平台的要好，但我们拥有一些独特的功能它们难以匹敌，比如网络传输、低延迟模式和无浮点音频管道(float-less audio pipelines)。
总体上 CoreAudio 是要比我们强，但是现在差距缩小。Win 平台上的无法像 CoreAudio 一样成为测试标准，但是它的整合性带来了比我们更好的开发体验。
相比 OSSv4 来说 ALSA/PulseAudio 有什么优势？你认为为什么 BSD 依然坚守 OSS 而不是去实现 ALSA/PulseAudio ？
OSS 是90年代风格的简化设计，它跟现代的桌面使用并没有太大关系。BSD 关注点在服务器，所以对于声音并不在意。另外一个也是更重要的原因是，BSD 和 Solaris 也没有别的选择。
OSS 的模式过于简化而无法实现基于时序的调度策略（这对于当前要求以节能的方式处理多种不同延迟设备十分重要），而在内核实现混音和采样率转换也是存有争议的。混音器的接口也过于简单，不能适应现代硬件的需求。
音频设备已经和过去不同了，现在有蓝牙、UPnP 设备、USB 声卡等。OSS 的模式适用于经典的声霸卡年代，现在并不适用了。
OpenBSD 使用了称为 aucat 的音频服务器，你认为它怎么样？
如果一个音频堆栈没有实现基于时序的调度，那么和消费级别音频设备就没有大多关系。据我所知，PulseAudio 是唯一实现源自 CoreAudio 的基于时序调度设计的开源音频堆栈。同时，PulseAudio 的零拷贝设计（在内存中交换音频数据的引用对象，而不是在应用程序和音频堆栈间交换音频数据本身）也是难以匹敌的。
具有讽刺意味的是，实现针对专业设备的音频堆栈要比消费音频设备及移动设备的音频堆栈简单的多。在专业设备上，低延迟是唯一需要考虑的因素，而节能并不重要。于是说基于时序的调度和零拷贝也就没有必要了。这也是将 Jack 和 PulseAudio 进行比较时需要注意的方面。
除了 Ubuntu，似乎 systemd 将成为未来主要 Linux 发行版的初始化系统，你是否预料到了如此快的接受速度？
我们从一开始就知道我们创造了一个很好的东西，但是将其这么快就推广开来比预先料想的要容易。另外我认为最终 Ubuntu 也会接受 systemd 的，因为现在它已经无法和 systemd 相比了。另外 Scott 也不再是 Upstart 项目的领导人，项目前景难料。当然，这只是我的一面之词，毕竟我不在 Canonical 工作。
你介绍 systemd 的博文相当出色，不知道你是否觉得出色的社区沟通技巧也是你工作的一部分呢？
是的，我被要求将自己的工作通过博客的形式表现出来。
systemd 相比 upstart 有什么技术优势？你认为 Ubuntu 会逐渐接受 systemd 么？
具体优势可以在这篇博文中找到（译注：可以参加本站先前报道）。
我觉得会 Canonical 会接受的，理由如上。
可以解释这句话么：systemd 是首个能正确的杀死一个服务的 Linux 初始化系统。
一个像 Apache 那样的服务可能会有很多个子进程，比如 CGI 脚本。这些子进程可能是由第三方创建的所以对其只有极为有限的控制。所以他们极为可能从 Apache 主服务中剥离出来，而这在现实中很常见。
而这在 systemd 中将不再可能，子进程将无法逃出监控。这将是我们第一次可以完全的结束一个服务及其它的全部子进程，于是我们可以确保没有遗留的 CGI 脚本。详情可以参看这篇博文。
我听说你计划使用 systemd 补充或取代桌面进程管理器，在这个领域 systemd 有什么优势么？
登录后的用户服务启动过程和整个系统的启动有着很多相似的地方，systemd 引入的那些提升系统服务启动速度的特性对于用户服务同样适用。实际上 OS X 上的 launchd 在启动系统服务之外也被用来启动用户服务。
为了达到这个目的，我们计划将用户服务进程也像系统进程那样并入不同 cgroups 分区，同时要保证多用户情况下的支持。
在 FOSDEM 采访中你这样说道：“我推荐黑客们只考虑 Linux 系统并享受它所带来的自由和机遇”。你知道 BSD 开发者们看到这番话时有多愤怒么？
我当然知道，他们看到我这番话感到愤怒，再正常不过了。
systemd 使用了大量 Linux 特用的 API，你是否认为 Linux API 已经取代了 POSIX API 的地位并且其他操作系统已经不再重要了？
是的，我的确认为 BSD 已经不再重要了。而在社区软件开发中为了 POSIX 兼容性的让步对发展的阻碍远远大于其带来的益处。
当然我也肯定像 BSD 这类系统不是对所有人都不再重要了，毕竟还有人在维护他们。但是对于希望将 Linux 带入主流的人们来说，不应该由于跟它们的兼容性而束缚了自身的脚步。 我们的目标是将 Free Software 带给每个人，在这一点上，BSD 的确不再重要了。
这只是我的个人想法。肯定每个做 Free Software 的人都有自己的想法，我有我的，其他人也有他们自己的。
可能 Debian 将不会使用 systemd 因为它需要考虑和 Debian GNU/kFreeBSD 的兼容性，你怎么看？
如果是那样的话，那么无疑是它们的损失。不要忘记 Debian kFreeBSD 是个试验性质的玩具系统。创建玩具系统没什么问题，毕竟所有人都喜欢玩具。但是如果 Debian 为了符合几个玩具操作系统开发者的想法而限制了其自身的发展，那么就是 Debian 自身的问题了。
如果我是 Debian 项目领导者的话，我会努力让 Debian 变得更具专业性，而忘掉 Debian kFreeBSD 玩具系统，不过我并不是 Debian 开发者。
另一方面，我没有觉得在 Debian kFreeBSD 中使用一个 BSD 的初始化系统而在 Debian Linux 版本中使用 systmed 有何不可。软件包只需要同时携带一份 systemd 的单元文件和 SysV 标准的脚本即可，systemd 可以很好的处理这种情况。所以我认为由于 Debian kFreeBSD 的原因而拒绝 systemd 的说法可能并不是真的。
通过阅读你在 LWN 及其他地方的文章，我发现你并不害怕激烈的争执和口水战。你喜欢这个过程，还是觉得很无聊？
我并不害怕。应对恶毒的评论是在开源软件社区推行巨大变革中必经之路。实际上，我怀疑我在这方面做的是否足够好。很多时候，我应该在讨论演变成口水战之前更早的回复，比如说句“无论怎样，我们要不同意 A 同意 B”， 从而阻止口水战的恶化。
为什么桌面 Linux 没有被主流用户所接纳？Linus 大神认为这是一个文化问题而不是技术问题，你同意他的观点么？
我认为我们原先在用户界面方面还不够创新，同时也没有传达出一个明确的信息和清晰的平台。如果你认同 OS X 是用户界面领域的参照标准的话，我们只是在复制它，但没有比上它。现在情况正在改观，GNOME 3 是首个严格遵循 UI 设计原则执行桌面环境，对于 Linux 桌面界面来讲是一个巨大的进步。
现在界面方面得到改观了，剩下就是明确的信息和清晰的平台了。Linux 平台还是过于零碎，一个希望为 Linux 平台制作软件的作者需要在一堆 API 中做出选择，它们很多看起来貌似很相近但其实是极度混乱，选择一个 API 可能意味着在一些系统上能工作而在另外一些不能。所以我认为我们应该从上到下简化整个平台，传递出一个明确的信息告诉人们桌面 Linux 操作系统是什么。 当然，我认为我在用户底层做的这些改善是在朝简化平台这个方向努力的。
最后，你对自己在 Linux 桌面领域做出的改变感到自豪么？你最开始的动机是什么呢？
当然咯~
动机嘛，最开始只有由于我喜欢折腾，很自然的发现闭源软件是没法折腾的。我希望在缔造一个可以和现有闭源产品的开源操作系统方面做出自己的小小贡献。

[陽光院景仁]

Original version

LinuxFr.org : First Avahi then PulseAudio and now systemd. You seem to be very versatile isn't it ? How is it possible to contribute like this in different and unrelated fields ?

Lennart : Well, they are more related than people might think. For example, I ended up writing Avahi when I was looking for a nice way to discover audio devices on the network while hacking on PulseAudio. I learned about mDNS/DNS-SD (i.e. the network discovery protocol stack Avahi implements), and back then an implementation called Howl was the most used mDNS/DNS-SD implementation, so I had a closer look on it hoping to add support for it in PulseAudio. However, I quickly noticed its shortcomings and its broken licensing, and after reading the RFCs of mDNS/DNS-SD I decided this was simple enough to implement and I could do a clean reimplementation in a few days. (It wasn't quite that simple after all, but that's another story...)

When working on Avahi I learned a lot about the complexities of safely and reliably running and maintaining system services, and about securing them as much as possible, which is particularly important for network facing services like Avahi. I implemented a lot of pretty nifty features in this area in Avahi. For example, Avahi is still pretty much the only daemon on a standard Linux install that chroot()s itself by default. (Well, there's another one now, the RealtimeKit daemon -- but I wrote that one too...). Also, it was one of the first daemons around which dropped process capabilities by default.
Back then I first started to think about how an init systemd should really handle all these things, so that the complexities needed to implement things like this go away. And yeah, I always kept thinking about this, and then ultimately Kay and I decided we really needed to something about this, and finally we did.

LinuxFr.org : During the early days of PulseAudio there was a lot of criticisms. Do you think PA deserved them because it was a bit immature or do you think the criticisms were irrational and/or misguided ?

Lennart : I can understand why people were upset, but quite frankly we didn't really have another option than to push it into the distributions when we did. While PulseAudio certainly wasn't bug-free when the distributions picked it up the majority of issues were actually not in PulseAudio itself but simply in the audio drivers. PulseAudio's timer-based scheduling requires correct timing information supplied by the audio driver, and back then the drivers weren't really providing that. And that not because the drivers were really broken, but more because the hardware was, and the drivers just lacked the right set of work-arounds, quirks and fixes to compensate for it.

You should never forget that in the whole industry there are about 3.5 people paid full-time for doing generic maintainance work of the Linux audio stack (which I consider consisting primarily of ALSA and PulseAudio and a few things around it). With this little manpower I can only say that what has been achieved is pretty good. While we still can't fully match competing audio stacks like CoreAudio, we are a lot closer than we ever were. I do hope that the folks who kept constantly complaining would be a lot more appreciative if they understood that.
Most of this is a think of the past. Hardware vendors these days tend to understand that when PulseAudio doesn't work properly on their hardware it's most likely their fault, not PulseAudio's, and to some extent PulseAudio has advanced to become a standardized test hardware vendors check their drivers against. Of course, especially on new hardware you might still run into problems, simply because even though there are somewhat standardized specifications for sound card designs like HDA or USB Audio hardware designers always find new and creative ways to implement them badly and incorrectly.

Also, what other option would there have been? It's pretty 囗囗囗囗囗 to believe that if we had waited any longer with pushing PulseAudio into the distributions things would have gone any different: you cannot fix bugs you don't know about, and the incentive and manpower is too small to get them fixed without having the pressure that the stuff is shipped.
And finally, CoreAudio on MacOS required a few iterations to get everything into shape too. Nowadays CoreAudio is pretty good as a benchmark for audio stacks, but you'll find a lot of folks who will tell you how it was when it was first introduced, and those aren't stories full of love. (Oh, and it still isn't all unicorns and rainbows yet, the last time when I tried to combine a USB with a built-in audio card on MacOS the kernel didn't really like that so much). An audio stack that can do timer based scheduling is necessarily complex, and hence difficult to get right. I am pretty sure most folks will notice that when they try to implement one and need to while to fully stabilize it.

LinuxFr.org : If you compare the audio landscape in MacOSX or Windows and the situation in Linux do you think we are on par with the proprietary systems ?

Lennart : Both Windows and MacOS have much better integrated audio stacks then we have. We have a couple of unique features they can't match, like networking support, lower latency behaviour, or float-less audio pipelines, but in general the CoreAudio stack is definitely more advanced than ours. The distance, however, is much smaller than it used to be.
The Windows stack is much less suitable as a benchnmark, and we are matching its features much better than CoreAudio's, but there's no doubt that it is probably still a better integrated audio hacking experience to develop for Windows.

LinuxFr.org : What are the advantages of ALSA/PA versus OSSv4 ? Why do you think the BSDs still use OSS instead of reimplementing ALSA/PA ?

Lennart : OSS is a simplistic 90's style audio stack. I doesn't really have any relevance for what you need for a modern desktop. But that's fine, the BSDs don't focus on the desktop, and on the server you don't need any kind of audio. Also, and this key: one of the reasons the BSDs and Solaris are stuck with OSS is that they don't really have any other options.
The OSS model is too simple to expose properly what modern hardware is like. You cannot implement logic like timer-based scheduling on it (whih is mandatory to properly handle more than one client with different latency constraints or latency at all, and all that in a power consumption friendly way), and doing mixing and sample conversion in the kernel is pretty questionnable too. The mixer interface is simplistic, and not useful really for modern devices.
Audio devices have changed, you nowadays have Bluetooth audio, UPnP audio, USB audio, and other complex audio technology. The OSS model was pretty much designed for cards like the classic SoundBlaster series, but having the device node as the primary interface to the audio devices is not really suitable if you are interested in the more advanced technologies.

LinuxFr.org : OpenBSD use the aucat sound server (http://openbsd.das.ufsc.br/papers/asiab ... _sndio.pdf). Do you know it ? What do you think about this server ? More generally are you interested by the other systems in order to discover new ideas ?

Lennart : An audio stack that is not capable of timer-based scheduling and dynamic latency control based on that is not useful on consumer devices. To my knowledge PulseAudio is the only free implementation of that design which was originally made popular by CoreAudio. Also, a zero-copy design like the one PulseAudio has (where you exchange references to audio data in memory instead of audio data itself between applications and the stack) is pretty much unmatched too.
The irony is that audio stacks for pro audio can generally be implemented much simpler than those for consumer audio and mobile devices. On pro audio power consumption is irrelevant, and latency is key. Due to that latency control becomes very simple (you just want it as low as possible) and technologies like zero-copy are not interesting (since audio frames become as short as the references they could be described in). Coming up with an audio stack that was useful for consumer PCM uses is hence much harder than one for pro audio PCM. And any audio stack not implementing timer-based scheduling or zero-copy design is simply of very little relevance to consumer devices. It's the same reason why Jack and PulseAudio don't really compete.

All free audio stacks (except PA+ALSA) I have seen so far do not cover timer-based scheduling or zero-copy data transfer at all. And as long as that is the case you'll always compare apples and oranges when you wonder whether projects like the OpenBSD audio stack or PulseAudio are better.

LinuxFr.org : Except Ubuntu it seems that systemd will be the future init system for most of the major distributions. Did you expect this quick success ?

Lennart : We quickly knew we had created something really good, but it was much easier to push this through than we anticipated. It took as one year from announcement to get it shipped in f15, and afaics it has been quite sucessful in it. In many ways it was like running along a long corridor and kicking in open doors.

And I am pretty sure we'll eventually make it into Ubuntu too. Already Upstart can't really keep up with systemd, and I figure Canonical will notice that one day too. Since Scott stepped down as maintainer the project lost its visionary, so I figure they'll eventually notice that Upstart is leading nowhere, and as the gap widens they'll eventually let it go. -- But hey, that's just my guess, and I don't work for Canonical, so I don't really know and only time will tell. Maybe it's all just wishful thinking on my side...

LinuxFr.org : Besides being a great hacker you are able to promote systemd very well with detailled posts on your blog. Do you think it's part of your job to do this "communication" task ?

Lennart : It is. We are supposed to blog about our work. It's one of the great things working for Red Hat: they encourage you to be open and blog about the tech you work on.

LinuxFr.org : What are the technical advantages of systemd versus upstart ? Do you think Canonical will change the Ubuntu's init system eventually ?

Lennart : There are so many technical advantages of systemd vs. Upstart! I think this blog story I posted a while back tells it all.
And yupp, I think they'll eventually switch too, see above. But I can only speculate.

LinuxFr.org : Could explain a little bit your sentence: "Systemd is the first Linux init system which allows you to properly kill a service" ?

Lennart : A service like Apache might have a number of subprocesses running, like CGI scripts, which might have been written by 3rd parties and hence are very lightly controlled only. This gives them the power to detach themselves almost completely from the main Apache service, and this actually happens in real life.
In systemd this is not possible anymore, and processes can no longer escape the supervision. That enables us -- for the first time -- to fully kill a service and all its helper processes, in a way that we can be sure no CGI script can escape us.
For details see this blog story I posted a while back.

It's kinda ironic that the job of killing a service which appears to simple at first is actually quite hard to get right, and only now we could fix this properly. One might have hoped this issue would have been fixed much earlier on Linux.

LinuxFr.org : I heard that you plan to use systemd to replace and/or extend the existing desktop sessions managers. Could you elaborate ? What are the selling points of systemd for this task ?

Lennart : The task of starting a number of services quickly and reliably is not unique to system boot-up. Pretty much the same is done when a user logs in and the user services are spawned. The same technologies systemd offers you to speed up the boot are useful to speed up session startup, and hence we'd want to make systemd useful for that job too. This is not a completely new idea though. For example on MacOS launchd is used in a similar way to start up both the system and the session.
That all said, along the way we'll fix a couple of other things too. For example, we want to make sure that ordering system services into cgroups is complemented by doing so for user services. Also we want to fix multi-seat support for good.
For more details see this google doc.

LinuxFr.org : In your FOSDEM interview you said: "I recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you". Do you understand the uproar of BSDs developpers when they see this recommendation ?

Lennart : Sure I understand that. It's not particulary surprising if they don't like recommendations like that, is it?

LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups, udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux API has been taking the role of the POSIX API and the other systems are irrelevant ?

Lennart : Yes, I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit.
I am pretty sure those other systems are not irrelevant for everbody, after all there are people hacking on them. I just don't think it's really in our interest to let us being held back by them if we want to make sure Linux enters the mainstream all across the board (and not just on servers and mobile phones, and not in reduced ways like Android). They are irrelevant to get Free Software into everybody's hand, and I think that is and should be our goal.
But hey, that's just me saying this. I am sure people do Free Software for a number of reasons. I have mine, and others have others.

LinuxFr.org : Perhaps Debian will be unable to switch to systemd due to the necessity to support the alternative Debian GNU/kFreeBSD system. What do you think about this situation ?

Lennart : Well, it's a loss for them, I guess.
Debian kFreeBSD is a toy OS, people really shouldn't misunderstand that. It's fine if people do toy OSes, everybody loves toys after all. But if Debian thinks it should limit its development by the dreamy interest in toy OSes of some of its developers, then this is their problem. If Debian was my project I'd try to focus on making (or keeping) it professionally relevant, and just forget about kFreeBSD, but I am not a Debian Developer.
That said, I see no reason why it shouldn't be possible to ship some BSD init system on kFreeBSD, and systemd on Debian's Linux version. A package shipping both a systemd unit file and a SysV init script is a workable solution and systemd will handle that just fine.
I think the claim that the need to support kFreeBSD on Debian was a blocker for adopting systemd by default is simply not true.

LinuxFr.org : After reading your posts at LWN and elsewhere I've seen that you're not afraid of heated debates and flamewars. Do you enjoy this as part of the FLOSS folklore or is it really annoying ?

Lennart : Not really, no. Being able to deal with poisonous people is part of being able to push big changes through in the Free Software world. And actually I doubt I am really that good in it, since I probably should stop much quicker replying to flamewars than I actually do. Most likely one should say "We have to agree to disagree on this" and shut up much earlier when a thread you are involved in turns into a flamewar.

LinuxFr.org : Why Linux desktop hasn’t been adopted by the mainstream users ? Linus Torvalds seems to think it's mostly a social issue and not a technical one. Do you agree with him ?

Lennart : I think we weren't innovative enough in the interface, and we didn't have a convincing message and clear platform. If you accept MacOS as benchmark for user interfaces, then we weren't really matching it, at best copying it. I think this is changing now, with GNOME 3 which is a big step forward as an interface for Linux and for the first time is something that has been strictly designed under UI design guidelines.
So we now have a better interface, leaves the message and the clear platform. Linux is still too fragmented, and a developer targeting Linux will have to choose from a variety of APIs, a bazaar of somewhat matching but mostly just chaotic choices that will work on some systems but not on others. I think it would be in our greatest interest to streamline the platform top to bottom, and thus have a clear message what the Linux OS is. And of course, I believe my work in cleaning up the lower levels of our userspace stack is helping to work in that direction.
Getting a clear message out what Linux is supposed to be is definitely a social issue, but to make that happen the Linux platform needs to be streamlined first, and that's a technical task, and not done yet.

LinuxFr.org : After all your projects are you proud of having changed the landscape of free software desktops ? Was it your motivation at the beginning ?

Lennart : Sure I am proud.
Wel, I simply like to hack, and I find closed software generally unpractical, so I do hope to play a small role in creating a competitive Free OS that can rival the existing ones in all and not just a few areas. And I am sure we'll get there.

[nmsfan]

有点意思

[ubuntu1023]

linuxtoy转过来的吧

[长头发的和尚]

呀呀的，我竟然看完了。

[qy117121]

为啥放pk版？

[长头发的和尚]

为啥放pk版？

估计有人有不同意见

[qy117121]

为啥放pk版？

估计有人有不同意见

[长头发的和尚]

支持百花齐放

[fnan]

这种人有能力让linux出现奇迹，适合领导linux，为此发动第三次世界大战也值得的，不过估计要实现比发动第三次世界大战还要难。

[kkspeed]

话说systemd目前还在开发中吧。。
bug真心不少，试用一段时间，在我的笔记本AC切电池后，X无法继续捕捉徽标键，会被escape到tty轮转上去。。偏偏我又用的是awsome...

同时支持它的套件也偏少，例如cpufreqd、lm_sensors默认都没有支持

还缺乏一个baselayout来存放配置文件。。

暂时没感觉它比开了并行的openrc快多少（大概快1-2s）。不知道是不是没有配置好。。。

[eexpress]

估计这作者，蛮熟悉水果机制的。
把好机制都搬家过来。

[sahack]

为啥放pk版？

估计有人有不同意见