4 ms·

They're separate binaries, and can be easily unbundled. That they're part of the same project is actually a win for me, it helps to make the various components

They're separate binaries, and can be easily unbundled. That they're part of the same project is actually a win for me, it helps to make the various components work well together. Also there is a common thread or philosophy in how things are built, making learning easier. In fact "the system is a single project" approach reminds me of the BSDs, which is arguably better than Linux as far as usability and security is concerned.

pdkl95 7y ago
> They're separate binaries https://news.ycombinator.com/item?id=19024256 https://news.ycombinator.com/item?id=19024256
- nickik 7y ago
  When you design a library you have to design a way to interact with it. Complaining about systemd because of that is basically saying 'I don't like the api you provide'. People who hate systemd want traditional C API, systemd wants message passing. If you don't like some of binaries, you can remove them and make your own package. If you don't like a particular implementation you can write your own subsystem that uses the same API (as many projects have done). Basically its just people complaining that it does work exactly as they want, when in reality message passing is the exact right way to make system like that.
labawi 7y ago
Unification wouldn't be a such an issue, if it was done with forethought, design and consistency, like BSDs tend to have.
brianpgordon 7y ago
> In fact "the system is a single project" approach reminds me of the BSDs, which is arguably better than Linux as far as usability and security is concerned. I've had this thought as well. The BSDs aren't afraid to go off and do their own thing, and it works for them. I feel like generally the Linux ecosystem is held back by reluctance to break free from ancient conventions and standards like POSIX and such, so I come into this systemd debate skeptical of arguments that it's not "the UNIX way" or that it's too Linux-specific or that it's stepping on other projects' toes, or that it's not the way things have been done before. The systemd critics have legitimate criticisms which can be addressed through evolutionary improvements, but I don't buy the philosophical arguments that systemd is fundamentally flawed.
- sittingnut 7y ago
  "Linux ecosystem is held back", compared to BSDs'? what world are you on?
einpoklum 7y ago
> They're separate binaries, and can be easily unbundled. No, they can't. The fact that they're compiled into separate binaries doesn't mean they're independent - they're completely dependent.
- nickik 7y ago
  That is in fact simply wrong. First of all, most of these systems are totally voluntary. You can simply not use them. And if you use them, you can replace them with other components that speak the same API if you want. The binaries talk to each other with a message passing API and that is actually the proper way to make a replaceable component. This has been done quite a few times before for many different reasons.
  - inimino 7y ago
    Inventing a message-passing API is not the way to make a replaceable component.
  - ddalex 7y ago
    1. you cannot not use them - the init binary doesn't gracefully degrade in the absence of the services provided by these APIs 2. the APIs are very complex and convoluted, with deep state maintained throughout the message exchanges; so complex it's effectively impossible to redo them without basically implementing everything exactly the same way the fact that some binaries communicate through APIs doesn't mean the system is modular, if the "modules" of the system cannot be used independently for other purposes

pdkl95 7y ago

> They're separate binaries https://news.ycombinator.com/item?id=19024256 https://news.ycombinator.com/item?id=19024256

nickik 7y ago
When you design a library you have to design a way to interact with it. Complaining about systemd because of that is basically saying 'I don't like the api you provide'. People who hate systemd want traditional C API, systemd wants message passing. If you don't like some of binaries, you can remove them and make your own package. If you don't like a particular implementation you can write your own subsystem that uses the same API (as many projects have done). Basically its just people complaining that it does work exactly as they want, when in reality message passing is the exact right way to make system like that.

labawi 7y ago

Unification wouldn't be a such an issue, if it was done with forethought, design and consistency, like BSDs tend to have.

brianpgordon 7y ago

> In fact "the system is a single project" approach reminds me of the BSDs, which is arguably better than Linux as far as usability and security is concerned. I've had this thought as well. The BSDs aren't afraid to go off and do their own thing, and it works for them. I feel like generally the Linux ecosystem is held back by reluctance to break free from ancient conventions and standards like POSIX and such, so I come into this systemd debate skeptical of arguments that it's not "the UNIX way" or that it's too Linux-specific or that it's stepping on other projects' toes, or that it's not the way things have been done before. The systemd critics have legitimate criticisms which can be addressed through evolutionary improvements, but I don't buy the philosophical arguments that systemd is fundamentally flawed.

sittingnut 7y ago
"Linux ecosystem is held back", compared to BSDs'? what world are you on?

einpoklum 7y ago

> They're separate binaries, and can be easily unbundled. No, they can't. The fact that they're compiled into separate binaries doesn't mean they're independent - they're completely dependent.

nickik 7y ago
That is in fact simply wrong. First of all, most of these systems are totally voluntary. You can simply not use them. And if you use them, you can replace them with other components that speak the same API if you want. The binaries talk to each other with a message passing API and that is actually the proper way to make a replaceable component. This has been done quite a few times before for many different reasons.
- inimino 7y ago
  Inventing a message-passing API is not the way to make a replaceable component.
- ddalex 7y ago
  1. you cannot not use them - the init binary doesn't gracefully degrade in the absence of the services provided by these APIs 2. the APIs are very complex and convoluted, with deep state maintained throughout the message exchanges; so complex it's effectively impossible to redo them without basically implementing everything exactly the same way the fact that some binaries communicate through APIs doesn't mean the system is modular, if the "modules" of the system cannot be used independently for other purposes