So, let's imagine for a time that we need to write a replacement for SystemD, a replacement called SystemFree, which is really just a "better" alternative to SysV, but really an alternative to SystemD, but an init system that makes your system free and gives you the best possible init system but at the same time the maximum amount of freedom and choice and the minimum of dependencies, but at the same time able to replace SystemD in regards to forking and making independent again such services as Udev.

This is the "function" of SystemFree, but the purpose of SystemFree is to free and fork all the SystemD prisoner services and make these work with SystemFree without depending on it, also making sure they remain compatible with SysV. I am no expert, but I think it is worth mentioning things like Dbus, Cgroups, PAM, Udev and so fourth. But I'm not the one who is going to say and speculate how everything should be, I don't have the knowledge for that and I don't know how it could/should ideally be done.

So, let's make a theoretical scenario in addition. The GNU/Linux community has split, those who acccept SystemD and those who reject it. This split also includes the Kernel which has now been forked. There are now two communities, the free/Linux (GNU etc) community and the non-free/Linux (SystemD etc) community, generally those who care about freedom and choice and those who don't care about freedom and choice, including Kernel developers. For the sake of it, the non-free/Linux community is much larger and supported by various corporations, Thorvalds has taken their side let's say. GNU and Stallman has ofcourse taken the side of the freedom and choice respecting people. Two parallell Linux communities now exist and we are writing the SystemFree init system to replace SystemD and fork the necessary components. The Kernel developers track the SystemD kernel and implement new things into the free-kernel whenever they can, but they also have options to change the free-kernel as they want. Any necessary changes to SystemFree, SysV and the relevant components free-udev etc can be requested implemented in the free-kernel and vice-versa. We have total freedom and everything SystemD and related services have been forked. The Linux Kernel has also been forked.

Now we need to rewrite the init system and the core services in a freedom a choice respecting way, a do one thing and do it well kind of environment where everything is interchangable and independent of each others and where alternatives exist to most core software.

Anyways, when writing SystemFree there are MANY considerations to take into account, including being able to switch SystemFree for SysV or any other init system easily. We need to keep some compatibility with SystemD systems to allow people to switch from SystemD to SystemFree if they want. This could be done with SystemFree plus Service X or something similar. We need to make all part of the GNU/Linux system independent and free from each others and minimize any dependencies on one part of the system on another part, as far as possible. Alike to what it used to be in the GNU/Linux world, multiple components making up one system, not a monolithic system or some monolithic program (ex. registry).

Taken all this into account. How do we write SystemFree? How does it work? What does it do and what does it not do? How about all the related services now currently under SystemD or thereabouts, what are they and how are those rewritten?

Etc etc.

Roll the talk, let's make our philosophical SystemFree here on the forum in as much detail as possible.

There was init-ng, initNG, or something, although they seem to have retired to the boozer, and not recently either. It was really a fork of sysvinit.

I tried it once; it was good; you added "init=/sbin/initng" to your kernel command line and it booted faster.

Thanks for your comment; it started with proposing a fork of systemd, always a good idea imho. Your comment journeyed on somewhat and ended with what could be an appeal for devs.

Sadly, I am no dev. But I offer this advice: The unix philosophy of doing one thing and doing it well was abandoned by systemd. If you are proposing yourself as the BDFL of the project, develop a vision, start the work, and look for collaborators. Your work and your code will be your credentials. I would

• Fork the boot/restart/shutdown secftion - 1 project.
• Fork the udev/dbus elements if there's an appetite - 1 or 2 projects
• Scrap whatever else systemd does unless folks claim it's invaluable.

Don't write in Perl or Python but in C/C++ as those 'scripting' type languages are very difficult to shrink. Use the Posix stuff as dependencies only. If you cannot police it, resign and appoint a new BDFL

1 members found this post helpful.

The premise is wrong. Systemd is not an init system. Get past that and there are maybe a dozen options to choose from, but only if you limit the scope to init systems. If systemd were an init system, there would be relatively little trouble.

But it is not. systemd is a blob consisting of some three dozen half-baked implementations of important, basic system components. Thus the troubles. So if you are looking to replace systemd, turn to BusyBox instead.

2 members found this post helpful.

I don't like busybox, and that's not what I am looking for here. I'm looking for a new generation SysV or a split up SystemD which keeps compatibility somewhat with both SystemD and SysV and can thus replace either in a somewhat easy fashion. I think to do that, one needs to also rewrite all those SystemD'ish things that are worth keeping in a GNU/Linux distro, or at least keep backport versions of software which should rather be scrapped (journal etc- we have the perfectly working rsyslog).

Anyways, to write a SystemFree at this time, one needs to map out SystemD and what it does exactly, which tools are important, and which ones are worthy of the dustbin. A replacement SystemFree needs to be able to replace SystemD in some way, which require that it in some way at least emulates some SystemD functions with a kind of service that can be added on top of SystemFree the Init system. But let's face it, we can't just write an init system and expect that to work, we also need to reclaim all the essential pieces of software that SystemD has monopolized. I'm not saying that in a way that it would be integrated into SystemFree, but become free and independent projects (forks) that SystemFree can work well together with. As things were before, but updated versions of those systems.

This is a good time to mention the neo-Linux kernel fork as well, especially in regards to writing a replacement for HAL/Udev. I don't know if Udev needs a full replacement or if a fork will work, I don't know the quality of the Udev code.

Let's also be honest. SysV is good, but there are reasons there are so many new init systems, it's because SysV is not satisfactory. SystemFree should be more like SysV but with some real clever solutions built into it. It should ONLY be an init system, but in some way it needs to be able to accept a module or two to be able to replace SystemD and create an emulation layer for those systems which are dependent on SystemD but wants to move away. Moving away from SystemD is not a one step process, one cannot just delete SystemD and all the software of the blob and replace it with only an init system. One can remove SystemD and replace it with SystemFree, but this would require an emulation module to work with the SystemD Udev and so fourth. After that one can replace Udev and other software from the systemD blob with forked replacements. The whole point is to split SystemD into independent pieces again, to deblob the blob.

Do one thing and do it well. SystemFree should work on such a principle, which means it is basically just an init system. But do it well, I think there can be some kind of interactive interface/aspect to the init system.

Haven't the gentoo folks already done all the legwork with OpenRC ?. And yes, it now apparently includes an init ...

Never looked at it as I'm quite happy with the way the world has moved on.

1 members found this post helpful.

The trouble is not just replacing systemd but having to patch/fork all the other bits of software that have systemd as a dependancy.

If systemd were just an init system I would almost certainly still be using it, and not worrying unless it caused me problems.

3 members found this post helpful.

I agree with the removal of systemd, which is not an init system, but will note that you're still looking at it wrong. Among other things integrating component into a monolith is just plain bad design.

systemd does not need replacing with a clone, just removing, rolling back to the earlier state as it were. It has been incorporating partial functionality from a plethora of established and mature pre-existing tools. "Just" roll back to the earlier state. However, as fido_dogstoyevsky points out, gratuitous systemd dependencies have been spreading through many unrelated projects. There are so many that a fairly large team is now needed for removing the crap and restoring the old tools. Setting things as they were before has, for an individual or even a small team, become a Sisyphean task. Or maybe the Lernaean Hydra is a more apt metaphor -- the original Whac-A-Mole but with poison. Whole desktop environments are being ruined on the one end and the other end I saw a distro starting to introduce a systemd dependecy into OpenSSH. That's unlikely to infect upstream but other projects are not so resilient.

About the components within systemd, some of the components look simple but aren't. DNS is one. Other components require great skill and knowledge in two or more highly specialized fields to accomplish with a minimum level of adequacy, let alone success. Time is one example, and there are only a few people in the whole world who could even begin to do it correctly. That brings up the idea of updating. Time management, NTP, is a prime example. PHK, one of the few people in the world with the right skill set, has taken a look and found that a much as he wants to, the code cannot be refactored, it is too large a task. Instead it would be a much smaller task to have it rewritten from scratch and even that is a larger task than he currently has time for.

Then there is the non-technical side of things. systemd spread through two key distros (Fedora and Debian) by being backed with Red Hat's money using only two simple methods, both of which are non-technical: ruthlessly attacking any who questioned systemd, and appealing to the novelty of systemd. Even people here on LQ fell for both, though I won't call them out by name. Once those two strategic distros were broken, the others fell like dominos. They had to, if they wished to follow the path of least resistance.

Ultimately the business goal seems to be the decommodification of Linux as M$ has been trying since described in the Halloween Documents. The stakes are high. Close to 20 years ago IBM invested $1 billion USD in the kernel. They recovered their investment in about 9 months. Now they have bought Red Hat for $34 billion. It will take a bit longer than 9 months to recover that. Problematically, the old guard at IBM, the one that saw the value in Software Freedom, is dead or retired and the new crowd has seen only the M$ way, and decades of M$ propaganda. So if you want to expound on the economical and technical benefits of Software Freedom, it will either fall on deaf ears or require starting from square one.

tldr; yay Devuan

I very much resent this statement.

However people might disagree on init systems, systemd is still opensource software.

There's also more than 2 positions available on that particular topic, and in most communities pro/contra/neutral-systemd people coexist (more or less) happily. You don't like that?

4 members found this post helpful.

(Again, systemd is not an init system. Let's put that lie to bed once and for all. You may like it, you may hate it, you may ignore it, but it is not an init system and hasn't been for quite a few years. )

Not really, while it technically fulfills the letter of the license, it is very far from the spirit of the license. Only on a technicality does the code seem available. In practice it is not: it is an extensive code base yet sparsely documented with poor documentation where the developers deigned to make annotations. The size of the code base is probelm since it is a monolithic rats' nest of interdependencies making it unapproachable by any casual developer, too much of a time commitment is needed to even begin with it.

So if you take either of the following to heart,

or

You'll see that systemd does not, in pracice, actually allow modifications or proper (intellectual) access to the source code. systemd is not the only project to have a large, complicated code base. ntpd and openssl are two infamous examples. It does seem to be the only one intentionally designed that way, and in a non-modular way to boot. The others just grew that way organically. Nowadays we know better than to do that.

1 members found this post helpful.

In essence, yes. This is the main thing.

A secondary concern is to make those bits and SystemFree an easy replacement for SystemD on a user SystemD distro and to "improve SysV" and the concerns regarding SysV.

This is actually what I mean by what I said. Perhaps I just worded it badly. We are the ones saying how it should be done and mapping out the process, not me. I'm just taking part in that. Wordings need to be precise, intentions, goals etc, and I think others can do that much better than I can.

That sounds devastating indeed, but these kind of things are the ones that need to be mapped out and plans made how to replace SystemD. Everything needs to be clearly visible on the table. Only then can solutions be proposed. If things are not realistic, they need to be scrapped in favour of realistic proposals.

SystemFree needs to be as easy as possible to implement, yet it need to be as complex as a "do one thing and do it well" init system can be. Additionally, the rest of the software blob of SystemD needs to be replaced with forks, and that which is not needed can be scrapped or emulated in a SystemD "compatibility module" or something like that to make it possible for an individual to replace SystemD and that blob with SystemFree and the forked software packages.

And I think your post is exactly describing what I am talking about. There IS already a split in the GNU/Linux software community. Those who care about freedom and choice and those who care about "open source". The idealists versus the pragmatics. These have worked well together until now.

I'm just taking that "split" and remaking it in this discussion about SystemD. It's not the same freedom I am talking about, but freedom or lack of freedom is absolutely a very relevant point in the SystemD discussion as well. The less choice you have, the less freedom you have, and the more overreach and blob SystemD is and the less you can change anything in the System due to the way SystemD works, the less choice you get, ergo, you get less freedom.

If you HAVE to install software X Y and Z just due to having SystemD as an init System, this starts eroding on your freedom. With SystemD it's sadly not just XYZ but the whole Alphabeth, no pun intended. It's a serious freedom restricting software. Thus I made the groupings that I did, with exact intention. If things go on as now, a split between freedom loving people who want choice and customization in everything and those who just want to use a "Linux" system is inevitable. I've heard nobody ever from the Ubuntu camp ever talk about the importance of software freedom, most newbies don't even know what software freedom is.

Let's invert it. Nowadays I can no longer use the Enlightenment desktop environment without having SystemD. Let's say I wanted a tiny System with just the essentials, and then add enlightenment on top of that, I can't do that any longer. Enlightenment is no longer self contained with its own libs but have made itself depend on SystemD. SystemD is creating restrictions across the board. Some people don't know about it or don't care about it, but alot of people care about those types of choices, the design, the freedom and so fourth.

The original idea behind systemd was a good one. It was supposed to work like xinetd but for system services rather than internet ones. A single program would listen on all the relevant sockets; whenever a message arrived at one of these sockets, the appropriate daemon would launched to handle it. So you wouldn't need to have daemons running when they weren't being used. Then Poettering saw that a program like that could be used as an init system because that's part of what an init system does: it launches daemons.

It also launches one-off configuration tasks. Personally I think those should have been left to scripts as before rather than creating a sheaf of new programs like consoled and timed.

So we would have the new systemd daemon launcher (which could be quite small), a partner program similar to the present init (and perhaps forked from it), which would create userland by launching one-off scripts, a udev fork to handle devices and a shim to provide an interface for programs that need to believe they are running under systemd. If anyone wanted a binary journal (which is often touted as a way of making logging program-selective) that could be a completely separate service.

2 members found this post helpful.

That was the whole point of writing systemd; to replace SYSVINIT. There already are alternatives to systemd; runit is one such example, but certainly not limited to. So why do we need yet another "choice" ? And that's "systemd", it's not spelt "SystemD", or even "systemD".

Furthermore, there are a number of distros that don't use systemd, so you still DO have a choice not to use systemd. Isn't there a fork of Debian by former Debian developers that didn't agree with the move to systemd ? Does Slackware use systemd as it's init system ? Not as far as I know. In fact there's a whole list of distro's that DON'T use systemd if you bother to look hard enough.

I also agree that the above statement is total nonsense. I'm not a "fan" nor a "hater" of systemd, and I certainly DO believe in the user retaining the "choice" and "freedom" to "choose" what they wish to use - init system or otherwise. Furthermore, it's still a "choice" not to use systemd as much as it's still a "choice" to use systemd.

1 members found this post helpful.

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.