> - It requires a central registry of all the sockets you need, for all your services. Like a Microsoft Windows registry. It's a database of everything that's running on your system; this defeats the essence of modularity.
So central repositories are now a tool of the devil, no matter what? If anything, this seems like a great win for modularity: from the outside you can interact with it as if it was all part of one whole, while the actual implementation can be replaced piecemeal without shattering the illusion.
> - systemd claims this makes the boot time faster: since all the sockets are already created, every service can connect to every other one and start at the same time. But this is not true, or true to a very little extent: if service A depends on service B and they start in parallel, A will only be able to run as long as it writes to B (and the buffer is not full); as soon as it needs to read from B, it will hang until B is up and capable of writing to A. Parallel start-up of services via pre-opened sockets is only able to perform the first writes in parallel; contrary to what Lennart says, this is not where you gain the most booting time. You gain a little time, for a major decrease in reliability.
Looks like he's misunderstood the point of parallel boot. The aim isn't to make A+B, where B depends on A, boot quicker. The big win is that you can now safely also start C at the same time, which is from a different dependency tree.
> So central repositories are now a tool of the devil, no matter what? If anything, this seems like a great win for modularity: from the outside you can interact with it as if it was all part of one whole, while the actual implementation can be replaced piecemeal without shattering the illusion.
Central repositories are a dangerous thing. A great win for modularity? I'm not so sure - the bigger the repository the less replaceable it is at the end of the day.
I'm not really sure why skarnet makes this argument anyway, since (x)inetd or its replacements also work as a "central repository" of sockets for socket activated services.
> Looks like he's misunderstood the point of parallel boot. The aim isn't to make A+B, where B depends on A, boot quicker. The big win is that you can now safely also start C at the same time, which is from a different dependency tree.
He's not talking about parallel boot, he is talking about what advantages socket activation (supposedly) brings to the table while parallel booting. :)
> Central repositories are a dangerous thing. A great win for modularity? I'm not so sure - the bigger the repository the less replaceable it is at the end of the day.
As long as the repository has a well-defined API then that can be replaced just as easily as any other single piece, right?
> I'm not really sure why skarnet makes this argument anyway, since (x)inetd or its replacements also work as a "central repository" of sockets for socket activated services.
Same for me on that one.
> He's not talking about parallel boot, he is talking about what advantages socket activation (supposedly) brings to the table while parallel booting. :)
Is this really all that different? My understanding was that the point of socket activation was that you'd no longer need to explicitly order when services would start.
So central repositories are now a tool of the devil, no matter what? If anything, this seems like a great win for modularity: from the outside you can interact with it as if it was all part of one whole, while the actual implementation can be replaced piecemeal without shattering the illusion.
> - systemd claims this makes the boot time faster: since all the sockets are already created, every service can connect to every other one and start at the same time. But this is not true, or true to a very little extent: if service A depends on service B and they start in parallel, A will only be able to run as long as it writes to B (and the buffer is not full); as soon as it needs to read from B, it will hang until B is up and capable of writing to A. Parallel start-up of services via pre-opened sockets is only able to perform the first writes in parallel; contrary to what Lennart says, this is not where you gain the most booting time. You gain a little time, for a major decrease in reliability.
Looks like he's misunderstood the point of parallel boot. The aim isn't to make A+B, where B depends on A, boot quicker. The big win is that you can now safely also start C at the same time, which is from a different dependency tree.