3 ms·
> 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 interac
by chronid 11y ago
> 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. :)
- Nullabillity 11y ago> 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.