Something that tends to get lost in these discussions: it's not a question of systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's absolutely no question that the vast majority of Linux users would rather sysvinit disappear entirely.
But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependency management and speed gains of systemd without the monolithic architecture and without the complicated shell scripts of sysvinit, as well as cool features like service management trees for non-root users. (In fact, runit doesn't need to be run as init—you can run it as a non-root user and provide service management even if you use another init. It just happens to make a nice init.)
The tests I've seen show that a minimal system with runit boots roughly as fast as than a minimal system with systemd. That doesn't mean runit is the end-all solution to "which init"—it's perfect for my needs, but maybe not yours—but it does mean that the choice is not a choice between systemd-but-fast versus sysvinit-but-slow. The field of choices is much, much broader.
What mystifies me in these systemd discussions is that people constantly seem to attack a caricature of systemd that has little in common with its actual implementation. Take for instance the perpetual "monolithic architecture" argument. What monolithic architecture? Systemd is in fact highly modular. For instance, PID 1 concerns itself with starting and monitoring units, and not much more. Other functions are implemented in other programs, such as journald, udevd, logind and so on. Of course, some of the components sometimes need to talk to each other, but generally via well-defined (D-Bus) interfaces - e.g., pam_systemd registers user sessions with logind via a D-Bus call, and loginctl asks logind about current user sessions, also via a D-Bus call. What's wrong about that architecture?
Now, systemd the package is getting pretty bloated. For instance, there is no reason why stuff like networkd couldn't be in a separate package that depends on systemd. But that's not really an architectural issue, and not much of a problem for users. (For instance, you can disable networkd just fine.)
What mystifies me in these systemd discussions is that systemd proponents always seem to think that "modular" is somehow the opposite of "monolithic," when it is entirely possible for a system to be both.
"Modular" only means that a system is factored into components that address logically separate concerns. "Monolithic" means that your modules are tightly coupled.
For example, the Linux kernel and X.org are both modular and monolithic, as is systemd. Coreutils, by contrast, is modular and NOT monolithic.
The Linux kernel is considered monolithic because all those modules run in the same kernel space, where they can all walk over each other and bring down the system. Systemd is not like that: its components run in separate processes.
By your line of reasoning, the GNU Hurd is a monolithic OS, because most Hurd servers live in the same source tree and send messages to each other at runtime.
systemd's modules are interdependent and all require systemd to be PID1 in order to function. You cannot, e.g. strip out logind only and use it as a ConsoleKit replacement. Contrast this with a toolkit based approach like s6, which can run as init, process supervisor or both, and can have its tools that operate on process state be used independently.
Another criteria is whether you can swap out one component without breaking the whole. You can't do this for journald, for example. You're forced to keep it by reducing it to a sink that redirects to your syslogd of choice. On the other hand, replacing parts of the GNU coreutils with those of 9base or sbase, for instance, won't break the rest (though it will break programs that depend on the GNU coreutils' extended options, of course).
The journal is a bit of a contrived example though, it is pretty much the only mandatory part of systemd outside of pid 1 and you can still replace it, you just need something to fill the place of it and no one wants to put forth the effort to create some journald compatible rsyslog daemon because it would be mostly pointless. Also, if you really hate it you can still configure it to not even store run time logs by throwing Storage=None into the config file.
So by your definition, Linux, is in fact, not a monolithic kernel. And neither is Busybox monolithic, then.
There seems to be a distressingly high amount of people lately who can't seem to tell that monolithic and modular software aren't mutually exclusive, and that you can be both. Lennart seems to propagate this idea lot that being modular automatically makes you non-monolithic.
One (minor) problem with runit is that runsv maintains the pipe between the command and the logger. If runsv dies then the pipe is lost and logs are potentially lost.
Unintegrated desktop linux is painful, and the fixes for it so far have mostly been hacks. Systemd actually attempts to create some kind of modern cohesive system which is a good thing.
Maybe you don't see the downsides to the lack of integration because you're just used to putting up with them.
I think mostly people adopted Linux to get away from paying a lot of per-seat license fees for everything, and to get away from having to buy some vendor's medium iron hardware rather than just using commodity x86 chips.
I don't agree with everything he says (the invasion of desktop linux seems completely unsubstantiated) but there are a couple of problems he points out that worry me, and I think we should pay attention.
Maturity: it certainly feels rushed that in less than four years systemd went from nothing to the default init system in most Linux distributions (if I'm not mistaken). For something so basic and important you'd think a good amount of testing and bugfixing should happen before that. We are taking our time with btrfs and Wayland, so why the rush with systemd? We certainly could endure some more years with the previous init systems. And this comes from an Arch Linux user, I like my software as fresh as I can I get away with, but it still seems odd.
Compatibility: this troubles me the most, you see hard dependencies appearing like what we currently get with Linux, systemd and GNOME. When people talk about this they are usually referring to the BSD family. That's a legitimate concern, but think about this: if in the future appears a brilliant programmer who designed a free kernel which runs circles around Linux, what will we do if everything is so tightly coupled? We have to consider the possibility that we won't be running the Linux kernel forever and be prepared to switch if something better appears.
>Maturity: it certainly feels rushed that in less than four years systemd went from nothing to the default init system in most Linux distributions (if I'm not mistaken). For something so basic and important you'd think a good amount of testing and bugfixing should happen before that
Maturity should not be confused with age. There is certainly positive correlation between the two, but it's not necessarily that strong. A piece of software that has been around for four years and been used by everybody will be more mature than software that has been around for ten but was only used by a small community.
There is also a chicken-and-egg problem here: software needs get widely adopted _before_ it can become mature.
Lol no. On many levels. MacOS does implement separate daemons, but they're all very tightly integrated, communicating over a common protocol. The core components hardly run in isolation, nor are they interchangeable. You don't, for example, just replace launchd with some other init system. You don't just say "hey, screw Aqua I want to use something else." (You can run other WMs through X11, but only on top of Aqua) Darwin is a bit more BSD-like, but nobody actually uses Darwin without the rest of MacOS.
And seriously, systemd isn't one single daemon either. It's a collection of daemons running that communicate over a common protocol. It isn't all-or-nothing, either. Only a few of the daemons are considered "core" and the rest are optional. And, because they use a common documented protocol, even the core components can be replaced. You don't hear about alternatives because nobody has really written any, but it doesn't in any way prevent you from doing it.
I think the legitimate concerns about systemd are things like losing portability of stuff like Gnome to BSD and systemd's short history, but it isn't one giant monolith executable or anything like people say.
> Lol no. On many levels. MacOS does implement separate daemons, but they're all very tightly integrated, communicating over a common protocol.
What common protocol? Mac OS X doesn't have dbus. It recently acquired XPC, but XPC is NOT a system bus -- it's simply an IPC library. It's neither required, nor universally used, nor is it terminally glued to the remainder of the OS.
> You don't, for example, just replace launchd with some other init system.
You don't? Says who? All launchd does is serve as an inetd/cron-esque daemon. The system daemons themselves continue to vend standard sockets and mach ports, and launchd itself does not pervade their externally vended interface.
> You don't just say "hey, screw Aqua I want to use something else."
Actually, you can. The display stack is driven by IOKit; XDarwin can run directly atop said stack.
Likewise, none of the "Mac-like" features that you want -- for example, automatic network configuration -- rely on any sort of centralized entity that pervades all daemons. There's a seperate system -- SystemConfiguration -- that provides that functionality, abstracted through a set of well-defined APIs and modular and distinct from the remainder of the system.
> * It's a collection of daemons running that communicate over a common protocol.*
Hence it's really rather monolithic, because to play in the systemd universe, everything has to conform to systemd's tightly coupled design.
What you're describing is all quite similar to how systemd operates. Your definition of "monolithic" seems to be that the components communicate with each other. My definition is that the components are difficult to replace. Systemd makes it easier to replace components, because the requisite interfaces are clearly defined.
MacOS is quite tightly integrated, it's what Apple does. Darwin is a bit different, as it's much more BSD-ish; with that I agree. But MacOS is a lot of stuff on top of Darwin and replacing any part of that would require tons of very MacOS specific code to do. Apple most definitely does not intend for their users to be able to replace logind or Aqua or pretty much any core service.
Probably a better way to phrase it would be to consided how much effort it'd take to run Aqua on BSD. You'd have to port basically everything that is MacOS. To me, that is what a monolithic system means.
Oh man no, go take a look at the launchd sources and see how much is hard coded in for how Apple wanted it - likely when you run into something unexpectedly not working how you wanted or expected.
Yes and no. It's true that OSX uses a variety of separate daemons, that run in different pids.
However they are all "required", "packaged together", "part of one source tree" and "shipped by a single vendor". In this respect they are a lot like systemd.
In fact it is arguably a lot more integrated. Both Python and Ruby are OSX dependencies. systemd isn't even close to that much of a power-grab.
GNU/Linux requires vi, perl, python... also as dependencies, but they're separate programs, the thing with systemd is that nothing can be separated, you use ALL components at the same time or change OS. Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd.
> Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd.
I'm just feeding a troll or someone who is really ignorant, but here I go.
No it isn't, and no you don't. Systemd is closely tied to some Linux-specific features, but it generally isn't part of the kernel. And you don't have to update the kernel in sync with systemd. Systemd lives in userland, by definition.
It does impose a minimum kernel version in order for systemd to work, which is something like 2.6.39 (May 2011 vintage). They have bumped up the minimum version a couple times as they needed new features, but you don't have to upgrade both together. I routinely upgrade one or the other separately on multiple systems and distros.
And it bears repeating again... systemd is not one single executable or process. And not all of the components are required, you can turn all but a few core ones off. And the core ones could be replaced if you wanted to, because there's a documented interface that you can implement.
Also, Vi, Python and Perl aren't "required" for GNU/Linux. They're common, but definitely not required. Vi is required if you want to comply with the Single Unix standard, but that is not the same thing. GNU/Linux just refers to pairing the Linux kernel with GNU userspace utilities; it doesn't necessarily dictate any specifics. There are further standards like LSB that attempt to do so but again not relevant. On top of that, Vi, Python and Perl aren't even GNU projects, which is true of a ton of other programs common in Linux distros, which is one reason I personally find the term "GNU/Linux" a bit onerous.
Also, Vi, Python and Perl aren't "required" for GNU/Linux.
By that definition nothing is ever required. There's the same argument in my comment history, someone said, udev is not required for GNU/Linux. technically, chromium doesn't "require" blink. It's not required, you can use chromium and receive raw html, right? But in that case OSX doesn't "require" Python either, just delete the files, done :)
So again, I'm saying, I want a GNU/Linux system. (Yes, it's not required, I can install MS-DOS, HURD, HP-UX or Android.) That means POSIX, LSB... That's what 99%+ of programs targeting GNU/Linux expect.
Tell me, have you actually used systemd? Because you're completely misunderstanding the first two points as they're overtly not the case. Particularly the first point, as what it is saying is that they are willing to use newish features in the kernel, not that you are forced to always be running the latest bleeding edge kernel to have an up to date systemd.
The second point has some validity, but is a distortion. Of course you couldn't plug ConsoleKit in as a replacement for logind, because ConsoleKit was never designed for that. What you can do with logind is implement a simple compatibility layer with the standard systemd interfaces and then use it; this is what Ubuntu is doing. What is mandatory to use systemd's services is to implement its protocol for communicating between the services. This is why some of the services are "core" ones- because they're implementing the basic functionality common to the other modules. They can still be replaced, as long as the replacement obeys the same interfaces. This is however a problem for BSD, as the easiest way to use the systemd components is to implement the interface, but that does require features that are only present on Linux.
> By that definition nothing is ever required.
And yes, that was exactly my point. The term "GNU/Linux" is meaningless and doesn't require anything specific. What you might want out of a GNU/Linux system is probably totally different than what I do. You might want Emacs, but I'm a Vi guy. I don't want Emacs and you might not want Vi. How do we settle this? Committee vote? Mud wrestling?
They're saying that after the kernel release with those features comes out they will make a release that depends on those features, not that the kernel and systemd must always be updated together.
networkd is still under development but if you're running a version of systemd that has it, it's already very nice so long as you don't need wifi. Right now I'd recommend it over NetworkManager for users who don't mind config files instead of using a GUI if they have access to it. It just works and it's automatically triggered by udev right when the hardware appears on the bus and sets everything up without the pile of shell scripts that is the status quo right now.
As a user of linux on the desktop, I've never felt a moment of concern over the fact that it takes longer to boot than did Windows. I'm not sure who is panicked by this and I'm distressed that we would solve all of our problems with init by embracing systemd.
I wonder why booting a computer may be a concern for a desktop user at all. With hibernation being polished enough (on Linux and elsewhere), one mostly puts a computer to sleep, then continues exactly where left.
Boot times may be important for cloud instances, though; the faster you can spawn more nodes to accommodate a load spike, the better. But cloud instances are usually pretty stripped-down, and often get spawned form pre-configured images where much of the discoverable stuff is hardcoded.
My rMBP is the first device that I have used yet that I feel boots quickly enough. I mean, it's a few seconds. And that's on top of the fact that I rarely actually turn it off. SSDs are really necessary to have tolerable boot times.
As another user of computers, it's pouring if I have to boot up more than one or two groups of things a week. If it ever takes more than 3 minutes, there's something wrong with the hardware.
I'm a beginner sysadmin, and therefore not really knowledgeable about the recent changes in Linux -- however I've seen FreeBSD in production(ish), and it was indeed a more pleasent experience. Paths, configuration, the package system, the documentation (!) all felt nicer.
I believe it's more about tight vs loose coupling, not integration. The contrast is, systemd's parts are relatively tightly coupled together (in a way one can't easily pull, say, journald and use it autonomously, with other init), while, traditional init systems are bunch of loosely coupled mostly autonomous modules that happen to reliably work together thanks to standards' glue (so, they're integrated as well).
I could be wrong on this, though. Just my thoughts.
I suspect the 'standards glue' is an important aspect of all this. With loosely coupled modules and standardised glue you can update components separately on different time scales and be reasonably confident that they will still integrate with other components.
Tighter coupling with rapid integration in functions and therefore changes in glue makes it harder to work piecemeal. Distributions have very different time lines. Pity the packager stuck trying to back port patches to an earlier version of the system when the upstream project(s) is(are) pushing out security updates based on the current versions and their current glue/api.
Of course it will work and work well. Redhat are betting their major product on this set of modules. The problem will be the load on other projects working around this.
He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment:
"I have to provide a system that runs reliably and can easily be reasoned about and yet I have to build it on distributions created by people who consider how long it takes to get to the fucking GDM login screen and if shutting the laptop lid will cause the system to hibernate properly or not."
I'm in the same boat - I wind up in a situation where I find myself missing the features, stability, coherance, and integration of systemd at least once a week in my day job, where we currently use Ubuntu with upstart.
For me, it's a combination of things:
1. Proper dependency management, where I specify dependencies as they are, rather than flattening the dependency graph.
2. Proper service supervision. I've had upstart lose track of running processes, which is silly - you had one job!
3. Ability to decouple the init system's view of "process is running" from "process is ready/live". This is nice if you want to await liveness by letting the system supervisor tell you if the service is live or not, rather than writing a bunch of external scripts or checks.
4. A single place to modify the way system services are run, and unified config for e.g. resource limits, and tools for working with them.
5. Simple exploration and interleaving of logs from various communicating services via journalctl, which is insanely helpful for debugging things in a distributed system. You can see the calls come in from the network and bounce between services, and see exactly where something goes wrong. You could do this with other solutions, but I get this out of the box with journalctl, and I can look in more detail at any of the services, or when I'm checking a service's status.
It's true that many of these things could perhaps have been done in other ways, but the fact is that the systemd developers did the work to make it happen and now I can focus on my product, rather than on learning a bazillion pieces of plumbing to enable me to ship product. I'm fine adapting a few things to run via unit files instead of shell scripts if it means I can ship more correct and more reliable product in less time.
systemd is less stable than upstart (and sysvinit, obviusly), "it lacks maturity" says the author. You've had several problems with upstart, but count yourself lucky, certain problems with systemd will take down the whole system, and make it unbootable too!
systemd is not reliable, unlike eg daemontools, the developers are busy adding new features and don't care at all about old bugs. They say if you're not using one of the latest kernels, tough luck. So you're continuously debugging systemd "modern innovations" instead of focusing on your product.
If you're using Ubuntu, let's hope that by the time it gets adopted, systemd has evolved into a functional, dependable component. I wouldn't bet my product on that, though..
I've been also using systemd since Arch switched over, I've discovered bugs and vulnerabilities. But the thing is, if you're happy with systemd and works well for you, great! I've seen this very prevalent attitude in systemd users, the less they know, more fervently defend systemd, even if they think it sucks, they tell you it's the best thing ever because they're using it, and they always have to use the best.
Arch is bleeding edge, if you've never seen a bug, you haven't been paying attention. So, again, you've never suffered a problem with systemd. Now do a web search, and in less time it takes to write "[citation needed]", you'll see that this is real. Sorry, but systemd has bugs, just like every other program, but by being so intermingled with the kernel, the consequences are much worse.
If you know of some old neglected bugs like you keep saying then point some out. I would love to see an actual source on something other than the constant made up retorts of "PID 1 now has an HTTP server" or "Now kernel panics display a QR code".
I definitely don't want to hide problems with my init systems behind a supervisor that has its own host of problems. The union of those two products does not make a more stable, easy-to-reason-about system.
Granted I could choose something better than monit, but then why add another layer to hide brokenness, when we have the capability of doing it correctly in the first place.
Being able to see what started what, cgroups, which binary produced what output, automatic process restarting is what I like for using on a server. I also like the nice timers output and that I don't need an additional cron or network configuration utility.
The problem is that in many server environments, particularly at scale, the speed of the bootstrap processes of the OS doesn't matter. One of the goals of systemd is to make the bootstrap process faster, which is irrelevant for those (non-desktop) use cases. So you see, systemd is solving problems, and making trade-offs to do it, that just don't matter for the non-desktop use case. I can of course choose not to install gdm, but that doesn't change the fact that systemd was designed (you might say over-designed) with the desktop use case in mind. Because of that, I have to live with those trade offs, even though my use case does not benefit. Since all major Linux distros are deciding to adopt systemd, it will be very difficult to "roll your own" and use something else, especially since the rest of the userland will assume that everyone is doing things the systemd way, this making it even harder to go against the flow.
If you're spinning up a lot of VMs, or paying by the hour or watt, you might care about how fast a server boots. Anyway lots of other init systems do parallel boot, not just systemd. So you don't have to use systemd just to get a fast boot time.
> Since all major Linux distros are deciding to adopt systemd...
Slackware is a major distro. So I expect everyone who opposes systemd to migrate to Slackware, and I'll get even more slackbuilds to browse through on SBO, right?
The idea that you should artificially separate OS into server and desktop, solely so you can charge more for the license for server OS, is a false dichotomy that needs to go away and only exists in proprietary commercial OS. It exists solely in the marketing sphere, and only intersects with the technical sphere WRT including artificial limits to ruin performance on a system that has a workload marketing doesn't approve of.
I do not want parallel non-deterministic booting on a server. If it works I don't care because I don't reboot daily/hourly/for fun. Its a linux box not Windows. If it doesn't work then non-deterministic behavior makes race conditions and error messages very confusing.
There is an inherent architectural / philosophical violation where flexibility is considered "unix"ish yet it is forbidden under systemd domination. If you disagree with the above paragraph for init system on a server, thats OK, I think someone with that has the wrong opinion but I respect an honest disagreement. Under a unix-ish philosophy there have been about ten alt-inits over the past couple decades that'll parallel / non-deterministic init, so go ahead friend, more power to you, give one a try until your fingers get burnt. Sysvinit (or BSDs init) will be waiting for you when you return. This flexibility, this compatibility, is philosophically forbidden under systemd.
You will do it the systemd way, because we won the political battle, not for technical reasons (god knows systemd is not the first attempt at this architecture). Or you will be forced to leave. Well OK then. The future is looking very freebsd to me. So long and thanks for all the fish!
Was there even an argument presented in the section titled 'The invasion of “desktop linux”'? I couldn't find it. Where's the evidence that systemd is making design choices that are driven by desktop linux and detrimental to usage on servers?
"I’m going to state up front (and people are free to disagree with me) that I believe you cannot provide a distribution of Linux that is both designed for the 'server' and the 'desktop' and provide a product that is worth using on either."
I, uh, what? Someone let everybody know that, as I'm pretty sure all the popular server distros (I guess not CoreOS, but that's pretty new) work just fine as desktops. Heck, Ubuntu is a very popular server distro[1], and it's certainly a desktop distro. And it's not like sysvinit wasn't used on both the server and the desktop.
Why weren't any of these objections heard back before Canonical knuckled under? Was upstart even worse? I really enjoyed the "impotent rage" piece linked in TFA's comments.
There have been "better init" options for many years, none of which gained much traction. So most of us figured the community as a whole wasn't very bothered. IMO systemd has only achieved "popularity" by using some very underhanded tactics.
It's not really a "Poettering" thing.
More like a "Red Hat" thing. They control (= their employee are mantainers and developers of) most linux core userspace programs/libraries, starting from Udev and Dbus and Upower, they/their developers make the choices that matters in that regard.
It's how OSS operates.
upstart is terrible in its own special way. Beside that it loses track of anything with a more complicated structure than, say, fingerd, its "dependency" system is wholly back-asswards: a job specifies which other jobs to start when it is ready (as opposed to a job specifying which jobs should be ready before it starts).
Whatever happened to the old unix philosophies of KISS, and if it isn't broken, don't fix it.
Granted, as many other have pointed out, SysVinit definitely has its pain points and could use improvements, but there are some other init systems people can use without having systemd shoved down our throats. It's been a while since I've played with *BSD, but it might be the time to start seriously looking at it again. Or switch to slack/debian and keep my old-fashioned init system.
Assuming that everything the author says turns out true - such as the "big one" exploit - in say an year from now, does anybody know any active popular open source distro that aims to keep systemd away from servers?
Debian has only made systemd the default, and getting sysvinit back is as simple as running `apt-get install sysvinit-core`.
Removing systemd might have consequences for GNOME, but that's not a concern on servers. There is a significant enough anti-systemd contingent in Debian (not to mention Debian also supports kfreebsd, where systemd doesn't run) that I'm confident sysvinit will remain a viable option for servers and non-GNOME desktops on Debian. Even GNOME desktops may work on Debian without systemd thanks to the work being done on systemd-shim.
"...and getting sysvinit back is as simple as running `apt-get install sysvinit-core`"
Well I gather that is the intention but there are a few bugs at present around that and an ongoing issue about upgrade from Wheezy to Jessie changing the init system silently. See Debian-devel for gory details.
Patrick has not ruled out using systemd. But if that does happen, I will personally write a tool to drop-in replace all of systemd and return the original sysvinit functionality, and make it work for every distro.
You are referring to systemd-journal-gatewayd, which has a dependency on libmicrohttpd, a 93 KB web server. You don't have to run it - it's an optional unit, that even when enabled is activated on demand. You don't even need to build it, since it can be disabled with a configure flag. If systemd-journal-gatewayd were a separate package, nobody would complain about it. So why is it such a big deal that it comes included in the systemd source tree?
QR codes for kernel panics is actually brilliant, because it encodes the data which would otherwise just be serialized to screen in a manner that makes it portable.
That actually might be nice but don't get your hopes up, systemd isn't actually part of the linux kernel as some conspiracy nuts would have you believe. The systemd project can't possibly just add random stuff to kernel panics, all of that code is in the kernel, not userspace.
I think a little while ago there actually was some work done on making kernel panics display a QR code but I doubt it'll ever be merged in if it's even done.
I think you're right, but if that's so, then apparently all of the features the OP claims to be bloat in systemd are questionably in systemd at all, and the entire discussion is moot.
But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependency management and speed gains of systemd without the monolithic architecture and without the complicated shell scripts of sysvinit, as well as cool features like service management trees for non-root users. (In fact, runit doesn't need to be run as init—you can run it as a non-root user and provide service management even if you use another init. It just happens to make a nice init.)
The tests I've seen show that a minimal system with runit boots roughly as fast as than a minimal system with systemd. That doesn't mean runit is the end-all solution to "which init"—it's perfect for my needs, but maybe not yours—but it does mean that the choice is not a choice between systemd-but-fast versus sysvinit-but-slow. The field of choices is much, much broader.
[1]: http://smarden.org/runit/
[2]: http://cr.yp.to/daemontools.html