Devuan: Debian Without Systemd

[ryao]

I don't think the beef is how many understand Right Now but rather whether its documentation is high enough quality that it can be understood by new developers with reasonable amount of effort. I'm under the impression sysvinit has the worst documentation out of the bunch (sysvinit vs Upstart vs systemd). I hope I'm wrong since otherwise people would be advocating an init system whose learning was mainly based on trial and error

The ratio of lines of documentation to lines of code is probably in favor of sysvinit by the virtue of it being so small. A similar case could be made for files containing documentation to files included in the package:

/usr/share/doc/sysvinit-2.88-r7/Changelog.bz2
/usr/share/doc/sysvinit-2.88-r7/Install.bz2
/usr/share/doc/sysvinit-2.88-r7/Propaganda.bz2
/usr/share/doc/sysvinit-2.88-r7/README.bz2
/usr/share/doc/sysvinit-2.88-r7/bootlogd.README.bz2
/usr/share/doc/sysvinit-2.88-r7/sysvinit-2.86.lsm.bz2
/usr/share/man/man5/initscript.5.bz2
/usr/share/man/man5/inittab.5.bz2
/usr/share/man/man8/bootlogd.8.bz2
/usr/share/man/man8/fstab-decode.8.bz2
/usr/share/man/man8/halt.8.bz2
/usr/share/man/man8/init.8.bz2
/usr/share/man/man8/killall5.8.bz2
/usr/share/man/man8/poweroff.8
/usr/share/man/man8/reboot.8
/usr/share/man/man8/runlevel.8.bz2
/usr/share/man/man8/shutdown.8.bz2
/usr/share/man/man8/telinit.8

Various RC implementations could have better documentation. This is something that needs improvement. I forwarded that concern to one of the OpenRC developers.

I would suggest you practice what you preach Ryao. he gave valid arguments and hiding behind the "it's my opinion and you have to respect it or you're a bad person" card is childish.

He twisted my words when I stated my perspective and then expected me to defend something that I did not say. That is bullying via strawman arguments, not a productive conversation.

What makes you think that? So far the adoption of systemd has been driven by distribution developers (who decide to ship/default to sytemd) and other upstream developers (who decide to make use of / depend on systemd). Notice that of all the major (i.e., all the ones big enough that I know their name) distributions that changed init systems since systemd was introduced, every single one changed to systemd, and whilst a lot of projects now come with upstream systemd integration, the same is not the case for alternative init systems.

There are a significant number of distribution developers who think that systemd is the only way to start software because of GNOME's dependence on it. There are also a significant number who think that systemd will be the only way to start all of their present software in the future. I also hear from people developing new Linux distributions that they are concerned about these things. These are concerns of inexperienced developers. Starting a daemon is not rocket science.

Unless you want to claim that the vast majority of distribution and upstream developers are "less experienced", I don't understand how this claim makes any sense.

They are less experienced compared to developers such as Robert Leigh and Ted T'so. The same could be said about system administrators adopting Windows versus those with UNIX beads who refer other systems. Many of them felt coerced into adopting it. There are people developing distributions who speak to me and say "I don't like systemd, but people say that I cannot develop a Linux distribution going forward without it.".

I disagree. This would come at significant cost. However, my opinion is not important. If it is so easy to do, then it would also be easy to keep a downstream patchset until upstream has been convinced.

Only a masochist would do this. I would rather just refuse to put systemd on my computers than engage in such a one-sided relationship. Consequently, that is what I do.

He made precisely one claim related to systemd (the rest wast about polkit/NetworkManager/Gnome/...): "I do find it very difficult sometimes to figure out why a particular systemd service gets started". This was _not_ ignored, but discussed at great length in the comments (also by yours truly). Several suggestions were made there, but patches are certainly welcome if things can be improved further.

I have sent patches to fix things in systemd-udev in the past and they were rejected because my use cases were considered stupid, despite the enterprise distributions getting patches for similar things. I have no interest in trying again. That was part of the reason eudev was founded.

Where do you get this idea from?

I consider those that claim that /etc/rc?.d is part of sysvinit to lack understanding at such a fundamental level that they have no idea what they are discussing.

I think this distinction is clear to most people who take part in these discussions (at least that's my impression).

The discussions in which you have taken part are *much* better than the ones in which I have taken part.

I think this is really missing the point of systemd. Much more important are things like race-free dbus/socket/time/path/device activation, and hence moving from explicit to implicit dependencies. Until OpenRC addresses these basic things it is just a minor improvement over sysvinit+sysvrc.

You are going to have to be more explicit. The way that OpenRC scripts work is to block until something is up and things are allowed to run in parallel provided that they do not depend on one another. I am not familiar with any races under this model.

As to the split between sysvint and sysvrc, this is, I belive, entirely due to sysvinit's deficiencies. In principle you don't need sysvrc at all, as sysvinit's inittab file allows you to define how/when to start/stop/restart services. However, inittab is not powerful enough to manage more than a very basic system, so therefore things like OpenRC/sysvrc had to be bolted on top (rendering sysvinit essentially useless as its most prominent feature is largely unused).

I recall reading the release notes from the 1990s said that it was intentional.

What systemd essentially did was to beef up the inittab format (each inittab line corresponds to a .service file) to the extent that things like sysvrc/OpenRC are redundant.

The purpose of the redundancy is to enable updates to be done without restarting the system. I understand that systemd can do execve, although this is much more dangerous than just changing things outside of PID 1.

Nope, systemd did not have that idea first. The most obvious predecessor is launchd, but even inetd, dbus and other projects had similar concepts.

Thanks for letting me know. I did not know that.

How are we not "playing nice with others"? Sure there is a very vocal minority who simply don't want to use systemd, but apart from "going away", there is nothing we can do to placate them. We do however, have great collaborations with all the other upstream projects that we interact with (yes, even the kernel, despite the occasionall flamefest), and also with the various downsrteam distributions. I believe all the major distributions have committ access to the systemd git repositor, we have open hack-fests several times a year that anyone may join (and lots of people do), and we have a very friendly and open mailinglist where all contributions are welcome, and most are merged (but obviously not all).

Add support for other libc libraries, add compatibility shims for older kernels, document things like XDG_RUNTIME_DIR so that you do not get maintainers of alternative systems like Roger Leigh complaining about how poorly documented things are, actually offer suggestions on how use other distributions' existing cases can be handled without telling them that they are stupid, stop making backward incompatible changes to long established code (e.g. network device naming) without leaving compatibility code to avoid breaking system services. I am sure there are many more, but these are things that come to my mind.

Hm, in what way could we be more successful? It seems that in all the ways that matter, we are achieving what we set out to do (and more)...

If marketshare is your only measure of success, then there is nothing that could make systemd more successful. The same can be said for the Windows operating system. That said, there are other metrics, such as not breaking systems when package upgrades are done and keeping an always releasable HEAD. Commits to the systemd repository have historically failed these metrics so horribly that I no longer bother to look.

Where do you get this from? It is quite a strong claim to make that all the distros and upstream who default to/integrate with systemd did so merely based on hype, and not on technical merit. Just see the very detailed analysis done by the Debian technical committee. All the peolpe involved there obviously did their homework very well, and whatever they voted and however they acted, it certainly did not have the appearance of anything being motivated by 'hype'. The same holds (but less publicly) for the other distributions, and in particular in the case of Arch Linux (where I was involved with moving to systemd) we also studied OpenRC before making the decision (in addition to our own initscripts which I was the maintainer of).

There are a significant number of distribution developers who think that systemd is the only way to start software because of GNOME's dependence on it. There are also a significant number who think that systemd will be the only way to start all of their present software in the future. I call that buying into hype.

Not every patch is accepted. However, you hopefully got a detailed explanation as to why your patch was not accepted (I could not find your patch in the ML archives, but I see that you have had at least one patch accepted). There are a few design decisions that preclude a certain type of patches, but what this applies to should be pretty obvious if you follow the development for some time. Even if your patch is not accepted, you could always keep it locally/downstream if you believe in it strongly (I mean that is what these crazy uselessd/eudev people should be doing rather than hacking the codebase to pieces before they even get started, just keep a minimal patch-set with the things they could not get accepted upstream).

The explanation that I got from Kay Sievers was along the lines of "Your use case is stupid".

Doing socket-activation in pure shell does not seem all that easy, but you could probably hack something together using systemd-activate as a wrapper. Not something I would consider pretty, but it certainly should be possible.

Agreed

I do not believe your interpretation of the principles of free software is a commonly accepted one. That said, systemd is not about coercing anyone to do anything, so any unification that we achieved was not done by force. It was done by collaboration and technical pursuation (playing well with others).

Telling people that they are the equivalent to members of a terrorist groups for not using systemd with Linux as someone did in this thread and other remarks like it are contrary to the principles of free software. Do you mean to say that this is not the case?

Diversity and competition can be good. But meaningless diversity is not. I.e., if you have two isomorphic ways of doing the same thing that are different for no purpose (i.e., in what file you store your hostname, or your locale settings, ...) it is simply a waste of time. Moreover, competition where one part is vastly superior to the other is not helpful to anyone and also I would claim a waste of time (as there is nothing to learn from eachother). Early upstart was an interesting 'competitor' to systemd, SMF is interesting, launchd is interesting, Lennart is very excited about procd (but I haven't looked myself). sysvinit is not interesting, nor is OpenRC.

I disagree. OpenRC handles people's use cases and incrementally improves as time passes. We do not have to deal with inoperable systems because of the latest experiment that the OpenRC developers decided to do. To me, that is very exciting.

[mmstick]

yep getting pretty annoying, though not as bad as stuff like "Ubuntu Christian Edition", where it's basically just ubuntu with some additional software slapped on.


Seriously there needs to be a new way of setting up distributions. I propose that instead of making entire distros, people create meta packages that install everything you want that differs from the core install of the base distro, and configures everything for you. By doing this, we could wipe out 90% of all distros.

The problem with linux being so easily redistributable is people just do it regardless of how redundant or useless their distro is.

Antergos does this with their installer. You simply toggle what features you want during install after selecting the desktop environment of choice.

[anda_skoa]

if userspace software uses systemd specific features and doesn't make that code optional, it effectively depends on systemd, (or at least the APIs it provides, which nobody else currently implements)

Even in this case, at least in my understanding, this does not mean that the software depends on systemd being use as the init process.
Only that systemd is present.

Any other init could have started systemd for that, along side other system services.

Cheers,
_

[psychoticmeow]

There are a significant number of distribution developers who think that systemd is the only way to start software because of GNOME's dependence on it. There are also a significant number who think that systemd will be the only way to start all of their present software in the future. I also hear from people developing new Linux distributions that they are concerned about these things. These are concerns of inexperienced developers. Starting a daemon is not rocket science.

...

There are a significant number of distribution developers who think that systemd is the only way to start software because of GNOME's dependence on it. There are also a significant number who think that systemd will be the only way to start all of their present software in the future. I call that buying into hype.

What exactly do you mean by this?

[ryao]

What exactly do you mean by this?

I mean that I have encountered distribution developers who think such absurd things and they advocate for systemd adoption under such premises. To be fair, my recollection of the distinction between developer and user is a bit blurry in the first case, but not in the second.

[psychoticmeow]

This attitude is a perfect example of peer pressure meant to prevent people from taking, modifying and redistributing F/OSS software for any purpose. It has no place in the community.

Peer pressure is not something that you can perscribe intent to, it doesn't ever "mean" to do anything. However that being said, there is a natural resistance to forking in the community because if a fork is going to be sucessfull it does mean taking resources away from the original project. Developers are not infinite.

[psychoticmeow]

I mean that I have encountered distribution developers who think such absurd things and they advocate for systemd adoption under such premises. To be fair, my recollection of the distinction between developer and user is a bit blurry in the first case, but not in the second.

Can you provide examples to establish this as a "significant number"? And what do you mean by significant?

[YoungManKlaus]

ok, have fun, call me when you are in the top-100 list on distrowatch.

[ryao]

Can you provide examples to establish this as a "significant number"? And what do you mean by significant?

Probably not. I don't keep a log of such misunderstandngs. I just know have I encountered such attitudes from multiple people in the past. I do recall a few names for the latter case, but I will decline to state them because I believe such people should remain anonymous. Failing to do that is to subject them to a witch hunt and I will have no part in that. I will say that there has been far more of that mentality than I thought was reasonable. Hence why it is significant in my mind.

[psychoticmeow]

Probably not. I don't keep a log of such misunderstandngs. I just know have I encountered such attitudes from multiple people in the past. I do recall a few names, but I will decline to state them because I believe such people should remain anonymous. Failing to do that is to subject them to a witch hunt and I will have no part of that.

I'm still unclear on what exactly you say these people were saying, I don't see why you'd bring this up if you're not willing to it up with examples. I'm not willing to take it as true on face value, and nobody else should either.