3 ms·

> 4. Libsystemd is a problem for the ecosystem. People get dismissed as systemd haters for pointing this out but it's big, complicated, has a lot of dependencie

by binkHN 3y ago

> 4. Libsystemd is a problem for the ecosystem. People get dismissed as systemd haters for pointing this out but it's big, complicated, has a lot of dependencies and most programs use a tiny fraction of it. Encouraging every service to depend on it for initialization notifications is insane. I couldn't agree more. Coming from the BSD world, systemd is a shock to the system; it's monstrous and has tendrils everywhere.

growse 3y ago
If you actually come from BSD, you'd hopefully recognize a set of different utilities combined to form a holistic system released under a single name. It's not a new idea. Besides, the gpp is incorrect: systemd dependencies are not needed for initialisation notifications.
- deleted 3y ago
  [deleted]
- 01HNNWZ0MV43FF 3y ago
  I think there's a low-effort solution to GP: Just split off the notification function for now. There's a dilemma here: Make a huge number of tiny libraries and people complain about left-pad. Make a monolith and this type of attack can happen. If left-pad is more preventable, let's go that way. The fact that C and C++ have tons of overhead in producing a package is their problem to deal with through better tooling.
  - growse 3y ago
    > I think there's a low-effort solution to GP: Just split off the notification function for now. 100% agree that some of the functionality could be decoupled, and either the project should provide independent helper libs or at least do a better job of documenting the interfaces. In this specific case, the notification interface is documented (and there's client implementations in a bunch of languages).
  - to11mtm 3y ago
    > Make a huge number of tiny libraries and people complain about left-pad. Making a number of similar libraries that would be better served as some sort of common set (i.e. even at the most basic level, right pad and left pad can be in one thing, RIGHT?)... but at the same time it's a particularly bad example because the overall behavior of that tread was a form of influencer growth hacking. that said, I think something like a 'notification function' falls into the category of 'boundary API' and those should always be segregated where possible for security as well as maintenance purposes for all parties.
belthesar 3y ago
I read recently that systemd does not recommend that you link to libsystemd to participate in systemd-notify message passing. The API for talking to it is quite simple, and vendors are encouraged to implement a compliant interface rather than loading all of libsystemd into your program to manage this. This of course would mean maintaining your own compliant interface as API changes happen, which is likely why it isn't done more frequently. It seems to me that there would be a lot of value in systemd stubbing out libraries for the various functions so that dependent projects could link to the specific parts of systemd it needs. That, or some other way to configure what code gets load when linking libsystemd. Full disclosure, I've not looked at libsystemd to see if this is already possible or if there are other recommendations by the project.

by binkHN 3y ago

growse 3y ago

If you actually come from BSD, you'd hopefully recognize a set of different utilities combined to form a holistic system released under a single name. It's not a new idea. Besides, the gpp is incorrect: systemd dependencies are not needed for initialisation notifications.

deleted 3y ago
[deleted]
01HNNWZ0MV43FF 3y ago
I think there's a low-effort solution to GP: Just split off the notification function for now. There's a dilemma here: Make a huge number of tiny libraries and people complain about left-pad. Make a monolith and this type of attack can happen. If left-pad is more preventable, let's go that way. The fact that C and C++ have tons of overhead in producing a package is their problem to deal with through better tooling.
- growse 3y ago
  > I think there's a low-effort solution to GP: Just split off the notification function for now. 100% agree that some of the functionality could be decoupled, and either the project should provide independent helper libs or at least do a better job of documenting the interfaces. In this specific case, the notification interface is documented (and there's client implementations in a bunch of languages).
- to11mtm 3y ago
  > Make a huge number of tiny libraries and people complain about left-pad. Making a number of similar libraries that would be better served as some sort of common set (i.e. even at the most basic level, right pad and left pad can be in one thing, RIGHT?)... but at the same time it's a particularly bad example because the overall behavior of that tread was a form of influencer growth hacking. that said, I think something like a 'notification function' falls into the category of 'boundary API' and those should always be segregated where possible for security as well as maintenance purposes for all parties.

belthesar 3y ago

I read recently that systemd does not recommend that you link to libsystemd to participate in systemd-notify message passing. The API for talking to it is quite simple, and vendors are encouraged to implement a compliant interface rather than loading all of libsystemd into your program to manage this. This of course would mean maintaining your own compliant interface as API changes happen, which is likely why it isn't done more frequently. It seems to me that there would be a lot of value in systemd stubbing out libraries for the various functions so that dependent projects could link to the specific parts of systemd it needs. That, or some other way to configure what code gets load when linking libsystemd. Full disclosure, I've not looked at libsystemd to see if this is already possible or if there are other recommendations by the project.