4 ms·

None of that makes any sense to me. It's all open source. It's laughable to worry about Gnome taking a hard dependency on an API when hundreds of software pro

None of that makes any sense to me. It's all open source. It's laughable to worry about Gnome taking a hard dependency on an API when hundreds of software programs take a hard dependency on Gnome. Hypocrisy, much? Meanwhile if the maintainers of GNOME betray your trust, it sounds like you should hate this hypothetical GNOME for the same reasons you apparently hate systemd. Or rather than hating it, you could just fork it. If enough people agree with you, a disentangled fork will inevitably be maintained. Hell, people maintain forks of GNOME for BSD—and that's even more impressive since there is no open source monoculture more monolithic than the Linux kernel API dependency. You could quite possibly be right that the open source movement couldn't have have started with the design principles of systemd[0] but it's naive to assume that what was good for open source in its infancy is still what's best for open source in its coming maturity. [0] Given that the open source movement has monumentally benefited from monolithic design principles in the form of the Linux kernel, I think that hypothesis is demonstrably absurd and easily rejected.

lmm 7y ago
> If the maintainers of GNOME betray your trust, it sounds like you should hate this hypothetical GNOME for the same reasons you apparently hate systemd. Or just fork it. If enough people agree with you, a disentangled fork will inevitably be maintained. And then they move on to the next project and introduce a hard-dependency on systemd there. RedHat has more programmers than me, they're always going to be able to add systemd dependencies faster than I can fork things. The only way users will ever be able to have a choice of init system is if the community can agree that hard-depending on systemd is indeed a betrayal, and publicise this. > it's naive to assume that what was good for open source in its infancy is still what's best for open source in its coming maturity. Open source succeeded because it was easy to improve and replace things piecemeal. That's still as important as ever. > [0] Given that the open source movement has monumentally benefited from monolithic design principles in the form of the Linux kernel, I think that hypothesis is demonstrably absurd and easily rejected. Linux has suffered from its monolithic approach to kernel-space development, but the damage was mitigated by an extreme commitment to providing a solid API to userspace that never gets broken. So most progress took place in userspace and wasn't affected. There's no analogous boundary for systemd.
- sjwright 7y ago
  None of that makes any sense to me. It's all open source. Your last paragraph is absurd and internally inconsistent. Linux (the larger operating system environment) exists only because of its monolithic approach to kernel-space development. Far from suffering from it, it made it all possible when the utopia of the GNU kernel flat-lined. Open source has succeeded because it was easy to improve and replace things piecemeal. But deciding that the individual pieces must begin and end at the process level is blinkered. You can perform "piecemeal improvements" to the scheduling component in systemd just as easily as you can to, say, cron.
  - lmm 7y ago
    > Linux (the larger operating system environment) exists only because of its monolithic approach to kernel-space development. Far from suffering from it, it made it all possible when the utopia of the GNU kernel flat-lined. Linux-the-kernel was largely just in the right place at the right time, but to the extent that it had development advantages they were an openness to contributions and the absence of an imposed top-down design. > Open source has succeeded because it was easy to improve and replace things piecemeal. But deciding that the individual pieces must begin and end at the process level is blinkered. You can perform "piecemeal improvements" to the scheduling component in systemd just as easily as you can to, say, cron. You can submit changes and improvements to a given cron implementation. But if there's a really hard tradeoff or a disagreement, you can also fork off your own cron implementation, and in fact there are three or four different cron implementations in common use on linux. This is really important and not just in the cases where a fork actually occurs: the possibility of a fork encourages maintainers to be reasonable and come to a consensus. Systemd's tightly coupled design makes that impossible - it's not about process boundaries but about having any kind of boundary where there's a stable interface between different components. E.g. reasonable people can disagree over whether the advantages of a binary logging format outweigh the disadvantages. But the systemd maintainers have taken a particular position, and, crucially, people who disagree can't just fork the logging component and swap it out for their piece, because there's no stable interface between that and the rest of the system.
    - 7y ago

lmm 7y ago

> If the maintainers of GNOME betray your trust, it sounds like you should hate this hypothetical GNOME for the same reasons you apparently hate systemd. Or just fork it. If enough people agree with you, a disentangled fork will inevitably be maintained. And then they move on to the next project and introduce a hard-dependency on systemd there. RedHat has more programmers than me, they're always going to be able to add systemd dependencies faster than I can fork things. The only way users will ever be able to have a choice of init system is if the community can agree that hard-depending on systemd is indeed a betrayal, and publicise this. > it's naive to assume that what was good for open source in its infancy is still what's best for open source in its coming maturity. Open source succeeded because it was easy to improve and replace things piecemeal. That's still as important as ever. > [0] Given that the open source movement has monumentally benefited from monolithic design principles in the form of the Linux kernel, I think that hypothesis is demonstrably absurd and easily rejected. Linux has suffered from its monolithic approach to kernel-space development, but the damage was mitigated by an extreme commitment to providing a solid API to userspace that never gets broken. So most progress took place in userspace and wasn't affected. There's no analogous boundary for systemd.

sjwright 7y ago
None of that makes any sense to me. It's all open source. Your last paragraph is absurd and internally inconsistent. Linux (the larger operating system environment) exists only because of its monolithic approach to kernel-space development. Far from suffering from it, it made it all possible when the utopia of the GNU kernel flat-lined. Open source has succeeded because it was easy to improve and replace things piecemeal. But deciding that the individual pieces must begin and end at the process level is blinkered. You can perform "piecemeal improvements" to the scheduling component in systemd just as easily as you can to, say, cron.
- lmm 7y ago
  > Linux (the larger operating system environment) exists only because of its monolithic approach to kernel-space development. Far from suffering from it, it made it all possible when the utopia of the GNU kernel flat-lined. Linux-the-kernel was largely just in the right place at the right time, but to the extent that it had development advantages they were an openness to contributions and the absence of an imposed top-down design. > Open source has succeeded because it was easy to improve and replace things piecemeal. But deciding that the individual pieces must begin and end at the process level is blinkered. You can perform "piecemeal improvements" to the scheduling component in systemd just as easily as you can to, say, cron. You can submit changes and improvements to a given cron implementation. But if there's a really hard tradeoff or a disagreement, you can also fork off your own cron implementation, and in fact there are three or four different cron implementations in common use on linux. This is really important and not just in the cases where a fork actually occurs: the possibility of a fork encourages maintainers to be reasonable and come to a consensus. Systemd's tightly coupled design makes that impossible - it's not about process boundaries but about having any kind of boundary where there's a stable interface between different components. E.g. reasonable people can disagree over whether the advantages of a binary logging format outweigh the disadvantages. But the systemd maintainers have taken a particular position, and, crucially, people who disagree can't just fork the logging component and swap it out for their piece, because there's no stable interface between that and the rest of the system.
  - 7y ago