SystemFree, the SystemD init replacement, what does it look like? What needs does it take into consideration?

zeebra · 08-19-2019, 09:22 AM

Quote:

Originally Posted by jsbjsb001

Again, just "thinking about it" doesn't make it happen. Many people "think about" world peace... has it happened yet? No, it hasn't.

And for the last time, there already ARE other init systems available. So again, what's yet another "alternative" going to solve? If it were going to solve anything, then we likely wouldn't even be talking about system bloody d. Again, if you're interested in doing something about it, then either learn programming or use something else. Otherwise "just talking about it" is just as pointless as just whingeing about systemd...

Any in case, I've wasted enough time with this pointless discussion...

If you want to discuss the discussion and tell people what they can and cannot discuss I suggest you stay away and keep it to yourself. Otherwise, please stay on topic.

cynwulf · 08-19-2019, 09:55 AM

Quote:

Originally Posted by zeebra

Yet we could easily choose between Xfree86 and Xorg back in the days.

One also had to configure the X server entirely from scratch back in those days - whether it was Xfree86 or X.org. Only X.org really survived, so while there was a choice of sorts, one of the two options declined into irrelevance. But the point being there was a choice - but it involved some work on the part of the end user.

ChuangTzu · 08-19-2019, 03:20 PM

Quote:

Originally Posted by zeebra

That's quite on the point and very useful. What I gather from this post:

- SystemFree is only an init system
- SystemFree can run some modules for various task
- One module of SystemFree is a daemon launcher (+ i/o?) or is this "module" part of the init system itself?
- One module of SystemFree is a "shim" or interactive interface (SystemD emulation module)
- Udev definetely needs a fork

Regarding the journal, we have rsyslog and even syslog-ng and other alternatives, there is absolutely no need for journald. Perhaps adding some logging tools to rsyslog instead.

I don't know about Udev as I said earlier. Does it need a fork or a replacement? Is there anyway to easily make Udev independent again? Perhaps roll it back to version x.y and fork that?

So, what do we actually need aside from just the Init (SystemFree) from the SystemD blob? Clearly Udev seems high up the list. But what about security modules? I think the current situation is a bit problematic. PAM, polkit, dbus, consolkit and even things like security modules (SELinux), what do we do about those? Ofcourse they need to be optional, but don't they need a more elegant solution or replacement? I mean, they can live alone, but eventually they will probably be swallowed into the SystemD blob as well. These kind of solutions are attractive, there is a demand for these kind of services, and a SystemFree init system needs to be able to on demand provide some of these same solutions.

From the Kernel side, this is all clear and working with the security module, but I think from the software side (coreutils/GNU etc) we're sorely missing updated system wide security parameters, and in one way or another, these have been attempted patched with various solutions like ACL. Just adding one or two permission parameters to the default GNU DAC could almost make it MAC, and together with a polkit/PAM/dbus/cgroups singular replacement solution, we would have a good security core to offer people to move away from SystemD (and pam, sudo, dbus, polkit, cgroups) without any concerns. Ofcourse, it's unrealistic to believe anyone would touch the old DAC and update it, but if not, the security service could do that in a more simple and elegant way, without having to implement something like SeLinux.

There is a demand for these things above, and if they all become baked into the SystemD blob, we also need solutions for them. Not in SystemFree itself, but in some of the forked packages to go along with it.

As mentioned by someone a few posts earlier, what does your SystemFree offer that openRC does not? Wouldn't your efforts be more focused helping an already established and viable alternative, rather then starting from scratch?
benefits of openRC:
https://wiki.gentoo.org/wiki/OpenRC
https://www.freebsdnews.com/2017/02/...trueos-openrc/
https://www.reddit.com/r/Gentoo/comm...e_openrc_over/

ChuangTzu · 08-19-2019, 03:22 PM

Quote:

Originally Posted by zeebra

I don't care how it is written really. And there aren't any alternatives to systemD aside from SysV OR independent init systems like found in Slackware or OpenRC. I don't know about OpenRC to be honest, but clearly it is not an alternative to SystemD since almost nobody is using it.

This statement has me question your ability and intent. Thank you, this thread is over for me now.

zeebra · 08-19-2019, 04:12 PM

Quote:

Originally Posted by ChuangTzu

As mentioned by someone a few posts earlier, what does your SystemFree offer that openRC does not? Wouldn't your efforts be more focused helping an already established and viable alternative, rather then starting from scratch?
benefits of openRC:
https://wiki.gentoo.org/wiki/OpenRC
https://www.freebsdnews.com/2017/02/...trueos-openrc/
https://www.reddit.com/r/Gentoo/comm...e_openrc_over/

What it offers that openrc don't?
A replacement for SystemD? I don't know if SystemFree would be much different than OpenRc, but one of the main points of SystemFree would be to fork the necessary parts of SystemD into independent projects again, ie deblob the blob.

I would think it's not possible to run any type of SystemD distro, remove SystemD and replace it with OpenRC and expect to have a running system, or am I wrong?

Christopher Wylie · 08-20-2019, 01:53 AM

Hello zeebra and others,
I would like to test this SystemFree.
How can I install it?

zeebra · 08-20-2019, 02:15 AM

Quote:

Originally Posted by Christopher Wylie

Hello zeebra and others,
I would like to test this SystemFree.
How can I install it?

It's not ready yet, but that is a good question. I'd think "make" and "make install" would be a good way.

But for those with package managers it should become available there.

Perhaps the final name would be SysF or sysfree.

zeebra · 08-20-2019, 02:39 AM

What have we found out thus far:

- Systemfree is ONLY an init (it does one thing and does it well)
- It's written in C (what else?)
- It has no dependencies (taken from SysV)
- It has some clever input/output built into (which can among other handle daemons and modules)
- It has a close relationship with other forked projects
- Together with the forked projects and a "SystemD emulation module" it can replace SystemD with install & remove
- The project supplies a "remove SystemD" script
- Make and make install && pre-packaged for the biggest distroes (sysf+remove script+forks)

zeebra · 08-20-2019, 04:37 AM

I think one good way to separate useful and non-useful forks is to separate those who are implemented in the kernel vs those who are not.

So say, cgroups, it needs a fork, udev needs a fork as they both have something to do with the kernel or are implemented in the kernel. they don't HAVE to be started by SystemFree, but they should be forked into independent projects.

business_kid · 08-20-2019, 05:20 AM

Sounds very promising. Does it reduce boot times over sysvinit? You can't help noticing that this much was achieved by initNG, and development there seems to have slowed/stopped. I'm not aware of what walls it ran into, but you may want to learn from their experience.
Also how you configure this will be important. With sysvinit, you can use config files or Distros are inclined to add great bloat to what was a simple system trying to handle every conceivable system, & setup.

Quote:

Originally Posted by zeebra

So say, cgroups, it needs a fork, udev needs a fork as they both have something to do with the kernel or are implemented in the kernel. they don't HAVE to be started by SystemFree, but they should be forked into independent projects

Frankly, I don't know the area, but I don't understand. This may be an ignorant question, but why fork what the kernel starts? Is there configuring to be done?
And if that's the split, could the kernel-booted apps be forked together?

I wish you success.

zeebra · 08-20-2019, 05:37 AM

Some relevant services that exist or need to be forked (or not, just considered), or has something to do with systemd, worth mentioning:
- inetd
- readahead
- consolekit
- syslog
- watchdog
- acpid
- autofs
- pm-utils
- udev
- cryptsetup
- tmpfiles
- auditd
- networkd
- d-bus
- pam
- namespace

Ps. list is taken from https://www.youtube.com/watch?v=_2aa34Uzr3c

SystemFree needs and relies on good daemons and some of these could be merged, but would not be part of SystemFree. Some of them need some improvement to live independent and useful lives, some of them already exist and do their thing well, and some do not exist anymore but has been swallowed up by SystemD and needs to be forked.

zeebra · 08-20-2019, 05:56 AM

Quote:

Originally Posted by business_kid

Sounds very promising. Does it reduce boot times over sysvinit? You can't help noticing that this much was achieved by initNG, and development there seems to have slowed/stopped. I'm not aware of what walls it ran into, but you may want to learn from their experience.
Also how you configure this will be important. With sysvinit, you can use config files or Distros are inclined to add great bloat to what was a simple system trying to handle every conceivable system, & setup.

Frankly, I don't know the area, but I don't understand. This may be an ignorant question, but why fork what the kernel starts? Is there configuring to be done?
And if that's the split, could the kernel-booted apps be forked together?

I wish you success.

SystemFree would not be procedural, structural or concurrent, but an ideal mix. The aim is to boot whatever environment as fast as possible, but in a structured way with some procedural waiting time to make sure once you're in the system, everything is booted fast, in the right order and complete. The boot priority as far as possible in the init system itself and details about it should be user configurable as well, unless it breaks something, but ofcourse even then if the user insist (experts).

Every boot item should be configurable in scripts alike to sysvinit, and SystemFree should look as much as possible like SysV in /etc with very similar functions, configurations etc. But it should not really be only script based, in essence.

SystemFree will be a lightweight but modular init system with a good structure. So alot of needs should be covered without distroes having to come up with their own solutions. But at it's core it's only an advanced but simple init. As many init functions as possible should be built into it to make it as efficient and complex as it can be as an INIT ONLY piece of software.

I think it makes sense to be able to split system critical things and non-system critical things and group these in two or 3 different init procedures. That way you can boot real fast without starting daemons and software that the system does not need to boot, but rather continue to start these after boot or possibly in between. The user should be able to structure these things as they see fit. If they want make the boot dependent on the network manager and wait for boot to start network manager, then they can do that, or they can structure is to start after boot or at the very end of the boot to see how much extra time that adds to the boot.

SystemFree would not decide how that should look, but would make some suggestions as to how everything is structured, but all except the critical things should be configurable by the user or distro. SystemFree could provide different standard configuration options for different types of system which users could accept or change.

Regarding the Kernel. I meant that software IN systemd which just offers services to Kernel functions. Cgroups is a Kernel function, systemd implements that with software. I think it makes sense to at least likely fork software for SystemFree (as independent projects) from SystemD which has Kernel functions or references (udev). Or better said is Kernel relevant.

zeebra · 08-20-2019, 06:17 AM

Things like cgroupsd need to be able to interface with SystemFree init in some way. This is where the input/output part of SystemFree becomes relevant. That way cgroups is not part of the init, but it's own independent software (daemon) and is something a user can choose to start/install or not.

hazel · 08-20-2019, 06:36 AM

Isn't it easy to design systems when you don't actually need to program them!

zeebra · 08-20-2019, 07:31 AM

Who said that? Perhaps I do have to program it all alone