Please read through the content of this thread before commenting so that you can stay on topic and make positive contributions. Your question have been answered both in the original post and several posts in this thread already.

I assumed you had read it, thus I answered what I did, assuming you'd understood what I meant by my answer.

But to state it clearly:
One of the main purposes of SystemFree is to be able to replace any SystemD with relative ease. To further info that, it means not that a newbie would be able to take the source, compile it and remove systemd and have a running system, but a more advanced user would. A newbie would be able to do this with precompiled distro specific package manager. The SystemFree project would package these and ship them ourselves (with our own repository, and to deb, rpm etc) for various distroes until distroes themselves would package and offer these "newbie" packages. The main target is not newbies though, but people who could compile from source and use a "remove-SystemD" script to properly remove SystemD and start up the new system with SystemFree instead of SystemD, but yet have full compatbility.

This would mean SystemFree Init, SystemFree Daemon, System Security Daemon and SystemD Emulation Daemon, or in other words, the full modular version of SystemFree, not just the init system. As a project we'd also need to offer replacement for software which is currently included in SystemD, among others udev, or possibly eudev. So no worry, I think a good goal of such a project as this would be to contribute to Gentoo development as well, elogind and eudev possibly, and make sure that SystemFree is a bridge between among others OpenRC and SystemD and prevent SystemD from making SystemD systems incompatible with other init systems.

We'd need to draw in all dependencies as well to replace a systemd system and offer these from a single location as source. A kind of multi project single project. Otherwise it is not possible to replace SystemD. That was my point in telling you to install OpenRC on Debian and remove SystemD, because that's not possible.

If SystemFree works as planned, you could use SystemFree resources and also just replace the SystemFree init with OpenRC or SysV if you wanted. The rest of the compatibility would be offered by forked projects, sysfd, sysecd and sysd. Or any bootloader (openRC, SysV) could implement ANY of these resources at their own choice.

It would be a grand cooperation, and inclusive by nature, that is the whole point. The more the merrier, and maximise choice and freedom. OpenRC is absolutely a part of that.

My main feeling is that SysF will start with an extensive rewrite of SysV and just develop into something quite different, possibly even a fork.

This would require that SysF would be published under GPLv2 or GPLv3.

Well, of course. How would it be free software if it didn't have a free licence? And GPL is the best licence for keeping things free.

1 members found this post helpful.

Sure, but since sysvinit is licenced uner GPLv2 with the clause "or later", it can be either GPLv2 or GPLv3 if it is indeed forked.

Well I said I was bowing out of this thread because it appears you are trolling and in way over your head yet trying to appear to be swimming.

Regarding your comment above to cynwulf, that is your job noone else's, if this is "your project" then you test what others are asserting and see if they are right. Several people have mentioned (myself included), why reinvent the wheel when other viable options already exist. Go test those options, if they are not viable then right up a blog or white paper listing why they are not, and how your systemfree is a viable option since it offers these features...that the others do not or cannot offer.

Now I will attempt to bow out again.

1 members found this post helpful.

and who is going to fork all of those projects? That is the same methodology that systemd used, we will just absorb what is necessary and we will determine what is necessary.

Saying that about SysV, it is just one possible development path to have an initial working init and rewrite it to work with the goals of SystemFree. With a forked version, the goals of SystemFree are entirely different than those of SysVinit and it would be a completely different end product. I would hope SysV neither would nor want to use any SysF code and just remain SysV init as it is and has been.

Another alternative is just to write an init from scratch and/or use some code from other projects.

I don't know, all distroes that does not use systemd will still need udev, so it might make sense to cooperate. The same goes for alot of projects, for example elogind or almost any fork that systemfree needs as well, really. I don't know who will maintain all the projects, but many people and many groups have common interests.

Perhaps eventually some distroes will move away from SystemD again when they see there is a viable alternative that is not SysV. One of the "good" things about SystemD is that it actually offers some services and function which many distroes and users are interested in, they just do it the wrong way. If the alternative is SysV and it doesn't offer those "important" things, then there are no alternatives to systemd for those distroes and users. The alternative also cannot be just an init. Sadly that is impossible. But that's not to say inits will not thrive in a world of systemfree. If systemfree organise all the tools to be independent, those same tools can be used by other inits as well (if they want). So take the example like eudev, sure, it is possible for everyone not dependent on systemd to rally around eudev as a proper fork for "everyone".

Take cgroups for example. I don't know of another implementation of cgroups in userland other than that of SystemD, and it's a perfectly legit function to want to implement, it's even a Kernel land function, so someone other than SystemD should have interests in implementing things like that.

SystemFree is anti systemd, so it's all about NOT absorbing any of those things INTO SystemFree, but rather take organisational "ownership" of them to make sure SystemFree has everything it needs. All those forks can be maintained by various projects and live their own life and do one thing and do it well, it's not part of systemfree, but systemfree is modular and will use many of them. The systemfree full version replacement for systemd will need to use all of them.

So if nobody else will do it, SystemFree will maintain all those projects as independent projects under a single umbrella.

Try to re-read the thread and come back when you understand what I am talking about. You don't seem to get the point of SystemFree at all. You don't understand why it is needed.

That's not my fault. There is alot to read about it right here on this thread, so feel free to do so, or feel free to leave if you have nothing productive to add and just want to try to dictate what others should discuss. It's not a thread about systemfre vs systemd or init vs init. it's exclusively about systemfree. So please stay on topic.

You do realize that your last sentence/point just summed up systemd?

1 members found this post helpful.

No, not as independent projects. You're just trying to argue semantics or trying to argue just to argue.

Just read the content of the thread again, that's my advice to you. If you can't even do that and understand the topic at hand I suggest you leave the thread. Nobody is forcing you to partake here.

This thread is like reading a script kiddie describe how they will fork the kernel and create the bestest kernel ever.
再见，祝你好运，现在呆在远处。谢谢你的笑声。
zài jiàn ， zhù nǐ hǎo yùn ， xiàn zài dāi zài yuǎn chù 。xiè xiè nǐ de xiào shēng。

1 members found this post helpful.

Some additional resources:

https://felipec.wordpress.com/2013/11/04/init/

I have a few sincere and salient points:

• It's written systemd not SystemD. The author(s) are particularly passionate about this and make it quite clear in the documentation.
• If you haven't at least had a poke around the source code and the documentation (proven by the above point) then how can you be sure that you're not going to make the same mistakes and have the same problems that you claim of systemd? Also, if you haven't looked at the source code and documentation then are these even your opinions, or are you simply repeating what you've read in random blog posts and articles?
• Have you attempted to determine how and why systemd has become popular and in common use where other init systems (in particular upstart) have failed?
• Have you determined Poettering's reasons and motives for writing systemd and what problems he thought he was setting out to solve? What he thought the shortcomings where in the existing systems? I think you need to understand systemd and the rationale and reasons behind it in order to successfully implement a replacement.
• Have you attempted to understand what the systemd roadmap looks like, what the developers of it feel are problems and issues and what they want to improve upon?
• The kernel is monolithic, monolithic isn't necessarily bad, however:
  Quote:

  Originally Posted by Poettering A package involving 69 individual binaries can hardly be called monolithic.

• There have been over 1100 contributors to systemd. There are a significant number of developers that are willing to work on it and can understand it.

I haven't seen evidence of any of the above in this thread, and I can't see how a replacement would be successful with no more than superficial knowledge about what is being replaced.

I understand that Poettering favours pragmatism over POSIX and the unix philosophy and that causes controversy, however I'm not convinced he is going out of his way to harm the open source community and generally mislead it.

Disclaimer: Not a systemd developer and not attached to it. I had a cursory glance at the source code and documentation for the purposes of writing this post

2 members found this post helpful.

Yes, exactly. Perhaps putting it another way: why am I going to download a "new init system", that maybe as buggy as hell, when I can just use an existing "alternative", that HAS been tested and proven to work (and addresses the complaints about systemd)?

Chances are; most people are just going to use an existing "alternative" instead, rather than enter the unknown.

But try telling that to the OP...

The OP "doesn't care"

Precisely - as has been pointed out to the OP by myself and other some posts ago now.

Agree, but again, good luck convincing the OP...