Let me quote some users:
"True, systemd consists of 69 [edit: 119] binaries. But they are so tightly coupled that to my knowledge nobody so far was able to provide a fully compatible alternative implementation for any of them. Besides, since the APIs internal to those systemd binaries are not only undocumented but also constantly changing, providing a compatible alternative implementation means aiming for a moving target.
Even if LP holds the 69 [edit: 119] binaries as proof that systemd isn't monolithic, to me that's BS. The strong coupling is what makes for a monolith."
" ... the problem seems to be that the systemd people aren't coding to interfaces. If they were, then dependencies wouldn't be on specific code, i.e. the implementations."
What outside devs need are stable external interfaces.
Many devs see it as a serious problem for them. They would have to "import" systemd's design, for good or bad.
Even some systemd supporters see it and ask for reconsideration of how systemd is developed, packaged, and offered to outside users/devs/integrators/etc.
Just imagine the BusyBox maintainers confronting integration of systemd into their limited and compressed environment.
"True, systemd consists of 69 [edit: 119] binaries. But they are so tightly coupled that to my knowledge nobody so far was able to provide a fully compatible alternative implementation for any of them. Besides, since the APIs internal to those systemd binaries are not only undocumented but also constantly changing, providing a compatible alternative implementation means aiming for a moving target.
Even if LP holds the 69 [edit: 119] binaries as proof that systemd isn't monolithic, to me that's BS. The strong coupling is what makes for a monolith."
" ... the problem seems to be that the systemd people aren't coding to interfaces. If they were, then dependencies wouldn't be on specific code, i.e. the implementations."
What outside devs need are stable external interfaces.
Many devs see it as a serious problem for them. They would have to "import" systemd's design, for good or bad.
Even some systemd supporters see it and ask for reconsideration of how systemd is developed, packaged, and offered to outside users/devs/integrators/etc.
Just imagine the BusyBox maintainers confronting integration of systemd into their limited and compressed environment.
Comment