News for hackers. Stuff that matters.
Re:Knoppix 8.6 abandons systemd by nickserv on Sunday September 01, 2019 @06:52AM (#20851580)
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.

Re:Knoppix 8.6 abandons systemd by brianpgordon on Sunday September 01, 2019 @07:30AM (#20851710)
> 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.

Re:Knoppix 8.6 abandons systemd by pdkl95 on Sunday September 01, 2019 @07:02AM (#20851606)
Re:Knoppix 8.6 abandons systemd by nickik on Sunday September 01, 2019 @08:22AM (#20851883)
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.

Re:Knoppix 8.6 abandons systemd by labawi on Sunday September 01, 2019 @07:12AM (#20851634)
Unification wouldn't be a such an issue, if it was done with forethought, design and consistency, like BSDs tend to have.
Re:Knoppix 8.6 abandons systemd by einpoklum on Sunday September 01, 2019 @07:31AM (#20851714)
> 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.

Re:Knoppix 8.6 abandons systemd by nickik on Sunday September 01, 2019 @08:26AM (#20851895)
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.

Re:Knoppix 8.6 abandons systemd by ddalex on Sunday September 01, 2019 @09:13AM (#20852104)
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

Re:Knoppix 8.6 abandons systemd by inimino on Sunday September 01, 2019 @09:00AM (#20852042)
Inventing a message-passing API is not the way to make a replaceable component.