Split systemd into his functionality


(tom) #1

salve,

years ago systemd comes to chakra as init replacement for the old, well tested and reliable init process because systemd has some fancy features.

and now?
systemd is growing in his functionality and brought some “features” to our system…silent with the behaviour of an trojan horse.
do you know the story about the trojan horse? no? i will tell you in a short version

so have systemd some “surprises” in his belly… some handy and some useless and some dangerous and all without my permission.
yes dangerous, a view weeks ago i had a unbootable system and other time systemd-fsck deleted booth filsystem checkpoints and i lost all my data.

my thought is: split systemd into his functionality to make it more KISS like and bring back the control of your systems
you know “divide et impera”

i think it should be splinted in to the:

  1. init daemon
  2. a package group for network with systemd-network, systemd-resolv, systemd-rfkill
  3. a package fo systemd-nspawn
  4. a package group for journal-remote, journal-upload
  5. a package for systemd-sysusers
  6. a package for systemd-cryptsetup
  7. a package for systemd-quotacheck
  8. a package for systemd-machined

i think systemd filthy fingers shouldn’t touch my system less it is possible.
what do you think?


(brli) #2

tl;dr

you can try to post this on Fedora/Debian/Ubuntu/Arch’s forum or ML and see what that would reply

  1. From the operational facts (of my knowledge), there is currently no distribution seperate systemd package into this way, what have done is a systemd and libsystemd divergence, or plus a doc and/or example if the package guideline requires the distribution to do so.

  2. if you’d really think of systemd being offensive in a way that it is too obese, please try to tear it down whereas maintains its functionality of being a good initial system and keeping other softwares communicate well with the provided dbus system. (ofc, contribution welcome, you can share your work and pkgbuild here)

  3. from what I know, yes, they don’t provide well-through written documents where every behavior is expected and the consequences are all known, but there isn’t much that is done without your permission. And, by reading the manuals, supposely you can manage those things well. (like fsck things, automatically generate and throw logs and so on)


(tom) #3

we where the first and this problem should be a small one because systemd design is modular perhaps it gives warnings in the journal like masked services i think.

in this moment i see the michelin man :smiley:
i am not sure if i understand you correct: systemd is serving a wide range of functionality and this cause a big binary but these binaries can be splinted to his functionality because systemd isn’t a monolithic block.

sure?^^
do you know systemd-sysuser? with it comes some new groups inclusive udev rules.
or blkid is located in /usr/sbin/, right? i compiled systemd without the most options and i become this errors

[    1.586013] frija systemd-udevd[196]: failed to execute '/usr/lib/udev/blkid' 'blkid': No such file or directory
[    1.594258] frija systemd-udevd[198]: failed to execute '/usr/lib/udev/blkid' 'blkid': No such file or directory
[    1.595570] frija systemd-udevd[197]: failed to execute '/usr/lib/udev/blkid' 'blkid': No such file or directory
[    1.595649] frija systemd-udevd[199]: failed to execute '/usr/lib/udev/blkid' 'blkid': No such file or directory
[    1.596606] frija systemd-udevd[200]: failed to execute '/usr/lib/udev/blkid' 'blkid': No such file or directory

is this move a change on my system? with my permission? i think not.

the major problem is systemd was introduced as init daemon.
only as init daemon and it could be used so if it so compiled but in every distribution where the complete software collection compiled and this collection is still growing…

edit
to make more clear what i want is these suggested new packages can be done by editing the PKGBUILD because every exists as a program with service in the systemd suit for system management please have a look at

ls /usr/lib/systemd

…and you will see it isn’t a big deal to do this :slight_smile:


(system) #6

This topic was automatically closed 170 days after the last reply. New replies are no longer allowed.