I'm sorry but I do not understand. Should I add some repository or ppa?

1 members found this post helpful.

The OP and others are discussing a theoretical replacement for systemd, called SystemFree. It doesn't actually exist.

1 members found this post helpful.

Open a github project, & ask for support. The opinions of contributors should carry weight, since they will be coding it. People may get behind the idea. It's all fine what we're doing here, but talk is cheap. There is an appetite for a systemd alternative. That's what we know. You've racked up nearly 50 posts in a few days, heavy stuff too - some weighty contributions.

There's also the idea of getting CS University projects behind it. There's CS Batchelors, Masters, & Phds being graduated every year. I was in hardware and I had my own idea. A lot are clueless. You could do worse than try a few Universities to see if they offer projects on this. It would be good CV floss for prospective sysadmins.

1 members found this post helpful.

Thanks business_kid, but I think nothing like this can be done without a proper plan, and I'm not smart enough or have knowledge enough to come up with everything myself. I think something like this would have to be planned out in detail for everyone to have an idea of how it looks and works before actually making it. The full scope of the situation needs to be mapped out to know the extent of what we are dealing with, and part of that is a detailed mapping of systemd to see how it is possible to replace it in a running system using systemd already.

Personally I think it is essential that an installation that already features systemd can swap to another init. Currently this is only possible with the efforts of distroes and a bunch of supporting packages and fixes etc, and I think that's ok, but not quite what is needed for an init that can replace systemd. Such an init probably will depend on several other somewhat big projects and some small ones, and that also needs to be mapped out.

And how does an ideal init actually look anyways? In detail, how is the design? This also need to be mapped out before starting anything, else things will turn out too random and with no set goals, disagreements and difficult decisions along the way. So, we already have another init, we have SysV, it's a viable alternative and many people use that. But why are there so many init projects and why was systemd created in the first place?

I think a well planned out init needs to be a bridge between sysvinit and systemd, and also try to provide some compatibility between these with the necessary independent packages. So a systemfree init is not only an init project, it is also the projects to accomodate systemfree, but also sysvinit. Also for a systemfree init, it needs to be able to address the "problems" of sysvinit and the reasons that other inits have been created in the first place, including systemd. It needs to be minimalistic, but at the same time feature rich, in my mind somewhat modular.

At least that is the way I'm thinking about it.

What I want most of all is that other people input their ideas into this place, both what should and should not, but also details and agreement or criticism of specific points of other ideas. Viability analytics for individual details would also be nice.

I gather that people were not happy with the way sysvinit handles daemons. I don't know why, but certainly systemd and runit both handle them quite differently so there seems to be a felt need for this. And sysvinit is often paired these days with a daemon manager called start-stop-daemon. Even Crux (very much a KISS distro) has adopted start-stop-daemon.

That's why I thought cutting systemd back to its original function as a daemon manager might be a good idea.

I have been thinking about this exactly, and I don't know the solution, but I've mentioned both modules and input/output, and I think one idea was that systemfree init spawns a systemfree daemon or sysfd which is absolutely voluntary and on a needs base only. But this sysfd could handle input/output and daemons, but could also provide the modular interface or spawn a daemon of the "systemd compatibility layer".

I think this is what I meant by modular and daemon handling and input/output etc.

Perhaps systemfree init is just a "dumb" init system with a clever way to message with it's own main daemon (only) and thus make it modular with sysfd part of the systemfree init system, but not a depdendency. And systemd emulation daemon just a compatibility daemon which communicates (like all other daemons) with sysfd. I'm not an expert, but I think sysfd would need to spawn before udev in that case and be a kind of pid 101.

This daemon could then handle things such as cgroups, udev, login etc. But perhaps that's also wrong. Perhaps it would need a helper daemon to make it more modular and avoid it becoming huge and over complex.

I was thinking modular as an inverted mini pyramid at one point, but I think maximum 7 in a modular design would be enough to provide anything from a dumb init to a systemd compatibility layer, daemon handling in a modular and uncomplex way. Perhaps sysfd would spawn one security daemon and one module/i&o daemon. But perhaps 1-3 would be a better maximum than an inverted pyramid of 7. All good things are 3, but the lucky number is 7?

Sys7 init?

In any case sysfd and systemfree init would only need to be able to handle very primitive messaging.

Another alternative is that sysfd could be compiled in different ways for size and needs or that people could provide their own replacement xyzd.

So, I think it's worth mentioning already existing forks or projects that are related:
-eudev
-elogind
-uselessd
-systembsd
-consolekit2
-loginkit
-notsystemd

as taken from this page:
https://en.wikipedia.org/wiki/Eudev#eudev

Adding to that the mention of hazel as noteworthy existing software:
-start-stop-daemon

I think consolekit is on the way out. elogind will replace it. blfs now includes elogind and I think this is a way to avoid systemd dependencies in X.

Have a look at runit, s6, OpenRC and others - no need to reinvent the wheel.

1 members found this post helpful.

You install OpenRC on a debian system then please with ./configure, make and make install and then remove systemd and tell me how that works.

Actually, I was looking at start-stop-daemon during some further research, but not really looking into it that much, I do wonder exactly how it works with SysV. I'd hate to steal and integrated other projects into sysfd (systemfree daemon), but start-stop-daemon would be one of the core things to have in sysfd. I think elogind would just be the kind of type of daemon that would (by choice) often be started by sysfd and provide an interface between it and other daemons and processes, including the "security daemon" I was talking about which can handle things like cgroups etc.

The goal would be to integrate as few other things as possible into sysfs but generally just provide a manager or a supervisor as part of systemfree init, and allow everything else to run as independent daemons quite like with SysV, but better manage everything.

With modular design, for example a systemfree project syssecd (systemsecurity daemon) depending on and implemented through sysfd, and things like sysd (systemd emulation daemon) also implemented through sysfd, I think we are looking at a trio of demons that can handle most things. The main task is to avoid making sysfd too complex and large, and this perhaps would require a fourth daemon as well to make up a 1-3 modular structure of daemons to handle everything.

Each of those can be configured with or without different services or be removed alltogether. So at minimum you could run just a systemfree init with nothing else or you could add pid 101 sysfd, if you wanted security stuff (pam, cgroups etc) you could add syssecd and if you wanted full replacement for systemd you could add sysd as well.

Perhaps it is a bad idea. But the point of it is to minimize sysfd to encourage people to run a systemfree init with input/output and modular functions and make the most used init sysf with sysfd, but yet be very lightweight and minimal.

Regarding names it seems that the "working name" or "concept name" systemfree would either become "Sys7" or "SysF" standing for system7 and systemfree. A main daemon could simply be named "sys7d" or "sysfd" depending on the eventual name. I think SysF makes more sense. I don't even know if 7 is possible to have in the name, and it also referred not only to SysV, but also the inverted 7 pyramid daemons which I now think would be an overkill. 1-3 daemons would be a better choice for a modular init, not 1-2-3.

SysF init would just be short for SystemFree init, "sysfd" would be short for SystemFreeDaemon, "syssecd" could be shortened to "sysecd" and would be short for system security daemon while "sysd" would be short for "systemd emulation daemon". Another option is to make a SystemFree Daemon+ to add functions not wanted in sysfd into a third module to make a 1-3 structure. This module could be named syspd and would stand for system+ daemon. Probably it would not be needed to replace systemd, but could just add some functions to sysfd.

"SysF" could then run "sysfd", "sysecd" and "sysd", and "syspd".

SystemFree should be POSIX compliant. With modular design and no dependencies, how can it not become compliant?

Furthermore it should not break compatibility with other init systems. This need to be assured in sysfd mostly but also make other project daemons "standalone". This would probably also help with making it POSIX compliant.

http://man7.org/linux/man-pages/man7/signal.7.html

Additionally I found this:

Minimum system dependencies for systemd:

acl dbus glib2 hwids kmod libcap libgcrypt pam attr glibc expat libcap openssl pam perl cracklib db libtirpc libgssglue

On this page:
https://wiki.debian.org/Debate/initsystem/sysvinit

I expect I'd have to do some research in order to get it working? i.e. it would take time and effort on my part... especially seeing as I would be choosing to build from upstream source rather than installing from the package repositories.

But why would you install OpenRC on a Debian system specifically?

What about runit, s6, others?