Devuan 1.0 Officially Released - Letting Debian Live Without Systemd

[cj.wijtmans]

i found systemd take up a lot of resources compared to other init systems on servers. mostly by journald.

[ldo17]

i found systemd take up a lot of resources compared to other init systems on servers. mostly by journald.

I just checked a top listing on my machine, and I can see systemd (pid 1) a bit of the way down at “0.0%”, no sign of journald.

[oiaohm]

i found systemd take up a lot of resources compared to other init systems on servers. mostly by journald.

One of the funny facts about this is parties using systemd in embedded systems build systemd without journald so resulting in it failsafe back to old syslog. So if journald is too much problem it possible to run without it. Work does need to be done to allow that to be chosen at runtime instead of build time.

Thing to consider as well compared to what other init systems. Are those all init systems that cannot to the basic of reporting service status correctly and killing a service correctly? Of course there is no such thing as a free lunch. You can say these older broken init systems are like driving a front wheel 4 wheel car with only 1 wheel on the back by having everyone sit in the right place. That works fine until you hit a major bump and is lighter.

[timtas]

One of the funny facts about this is parties using systemd in embedded systems build systemd without journald so resulting in it failsafe back to old syslog. So if journald is too much problem it possible to run without it. Work does need to be done to allow that to be chosen at runtime instead of build time.

Didn't know that's possilbe now, Lennarts flat-out refusal to make it an optional component for systemd was always one of my main reasons to not even consider having a look at it.

[oiaohm]

Didn't know that's possilbe now, Lennarts flat-out refusal to make it an optional component for systemd was always one of my main reasons to not even consider having a look at it.

http://events.linuxfoundation.org/si...dded%20Systems. pdf

Really wrong presume. Even the developer who stripped out journald in 2016 was surprised that the had been designed exactly to-do that from the build process.

Timtas so anti-systemd with even known how it assembled. Reality is from the first version dropping out journald was possible if you build from source. Lennarts has built a lot of optional in systemd build process bit lacking in the runtime department. Of course this stuffs up requests of course asking for something to be made optional when it is optional in the build process leaving Lennarts scratching head because what you wanted was runtime optional.

[ldo17]

... Lennarts flat-out refusal to make it an optional component for systemd was always one of my main reasons to not even consider having a look at it.

systemd was always designed to be modular from the beginning.

[cj.wijtmans]

systemd was always designed to be modular from the beginning.

it may be true but it doesnt take away that its source tree and functionality is very monolithic. There were attempts to make it more modular but they stopped.

[oiaohm]

it may be true but it doesnt take away that its source tree and functionality is very monolithic. There were attempts to make it more modular but they stopped.

Again another false statement. There have been patches coming in from developers embedded world working on allowing the functionality of systemd to be broken down even more almost the complete time systemd has been developing. Of course those normally focus on doing at systemd build not a runtime.

There are really not been any major submissions to expand runtime customisation. Its not that patches have been blocked it that there have not been patches to-do this. I like how people talk about attempted but then don't check out what patches were submitted.

Some of the problem with systemd a stack of things that are not based on the facts of the commit log being reported as fact. So attempt allow more modular have not ended. Are they in the form of modular general distributions that want to ship a general assembled systemd will want the answer is no. There have been no patches submitted focusing on that.

https://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

Please read point 1 here. For parts that are not optional in the build system package up without them and test if it runs. So systemd is highly modular include in ways you don't quite expect. As the what the pdf reference before did to disable journald is obey instructions of MinimalBuilds and just not bundle journald up. This is build time modification obey the instructions provided with the source.

Systemd is not runtime effectively modular configurable by config files so that the complete thing can be installed and then you can choose to use part of it. Systemd will use all parts is finds installed. Systemd is absolutely modular and not monolithic if you are building from source and packaging yourself.

[cj.wijtmans]

Again another false statement. There have been patches coming in from developers embedded world working on allowing the functionality of systemd to be broken down even more almost the complete time systemd has been developing. Of course those normally focus on doing at systemd build not a runtime.

There are really not been any major submissions to expand runtime customisation. Its not that patches have been blocked it that there have not been patches to-do this. I like how people talk about attempted but then don't check out what patches were submitted.

Some of the problem with systemd a stack of things that are not based on the facts of the commit log being reported as fact. So attempt allow more modular have not ended. Are they in the form of modular general distributions that want to ship a general assembled systemd will want the answer is no. There have been no patches submitted focusing on that.

https://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

Please read point 1 here. For parts that are not optional in the build system package up without them and test if it runs. So systemd is highly modular include in ways you don't quite expect. As the what the pdf reference before did to disable journald is obey instructions of MinimalBuilds and just not bundle journald up. This is build time modification obey the instructions provided with the source.

Systemd is not runtime effectively modular configurable by config files so that the complete thing can be installed and then you can choose to use part of it. Systemd will use all parts is finds installed. Systemd is absolutely modular and not monolithic if you are building from source and packaging yourself.

integrated journald. integrated udev, integrated dbus. not monolithic you say?

[oiaohm]

integrated journald. integrated udev, integrated dbus. not monolithic you say?

Shock horror systemd will work with mdev and with dbus and journald missing. Systemd is in fact modular. Embedded developers have proven that without question.

Monolithic claim against systemd has always been bogus. It is like calling sysvinit monolithic because all it tools work with each other. Systemd is just a bigger collection of tools.

Systemd is lacking runtime customisation options so then auto configures self in ways users don't always want.

Is journald/udev/dbus in fact integrated not exactly. Does systemd configure it self particular ways when it detects their presence yes.

Integrated says not removable and embedded developers proved the 3 your point to as removable. So another bogus claim. Systemd includes journald/udev/dbus in the same tree but they are not integrated to the point of not being split-able.

Interesting enough if you look at the changes in udev in eudev you find a few very interesting things. Most of the changes in eudev are nothing todo with systemd they are to do with glibc features. The few systemd dependant changes are removing usage of a systemd library. A library that does not require systemd to be PID1 and was done to reduce code duplication between many parts.

Again most of the yell is because systemd is modular not monolithic. With the interdependency between modules mean if you had cut out udev you would have libraries starting with the name systemd because they contain shared parts used in different programs in systemd collection same thing exists in gnu core utils and people don't go around calling that monolithic.