Devuan 4.0 Released As Debian 11 Without Systemd

[nctnico]

In my particular case systemd doesn't start the application program until Wayland is up & running. With the systemV init scripts from the old days, this would be a lot harder to accomplish because you'd need to take care of the dependancies yourself.

Eh?  With my example, all you'd need is add a single shell command to your script, blocking the execution until you have X11 or Wayland available.

If you wanted a timeout with that, then it would be a shell if ! utility... --timeout seconds ; then fail ; fi clause.

But why should I bother if I can let systemd deal with that? And what if Wayland stops? systemd will restart both! The big picture is that systemd makes things like these easier compared to using scripts or messing with inter process APIs.

The core idea is that instead of init determining dependencies, the core services would all be started in parallel, and they themselves handle the dependencies.  The code needed to do that should be simple, as shown by the API example above, if designed to cater to the needs of the daemons, as opposed to init system developers.

Wanting applications/daemons to deal with dependancies themselves is putting functionality in the most worst wrong place possible as applications have very limited knowledge of their surroundings. Doing it right would mean that every application would need dependency configuration. Think about this a bit longer because you are on the wrong track here; your approach will create a huge convoluted mess. In the end won't be simple at all because so many different cases need to be catered for. The devil is in the details. If a truly simple approach is possible then someone would have made it already and systemd wouldn't be used.

Handling dependencies in a single place is a much better approach because it has the necessary oversight and gives users flexibility to configure dependencies (if necessary) in a uniform way. They only need to know how to deal with the configuration of the application that handles the dependencies / startup order.

[madires]

At the same time you can run into problems with systemd based services if you need a special setup/init for a daemon. Easy to implement with an init.d script, while the systemd service file is too limited. There are pros and cons for systemd, It ain't only sunshine.

[nctnico]

At the same time you can run into problems with systemd based services if you need a special setup/init for a daemon. Easy to implement with an init.d script, while the systemd service file is too limited. There are pros and cons for systemd, It ain't only sunshine.

Nothing stops you from running such a daemon/application from a shell script which does some setup. Been there, done that.

[Nominal Animal]

But why should I bother if I can let systemd deal with that?

You shouldn't.  Nothing I've suggested would change anything user-visible in systemd.  Even if my wildest dreams were accepted, systemd would still provide all the functionality it now does, and might even be a bit more stable and robust, too.  Systemd development would continue just as it has thus far, with the exception that they'd have to support a small C API at the lowest level, instead of subsuming it into an internal project, or doing an embrace-extend-extinguish trick on it.  Very little effort involved in total, for major gains across the entire Linux and POSIX system scape.

If you're happy with systemd, go ahead and be productive!  The same goes with any other tool or operating system –– yes, even Windows and Macs.

What I do not understand, is why you are so adamant that systemd caters all possible needs, when people like I are complaining it doesn't and therefore desire alternatives.
I would never suggest alternatives that make systemd impossible, exactly because it is useful to many users.

However, people like you are a big part of the reason why systemd developers can block any suggestions or patches –– not just to systemd, but socially among developer communities when talking about individual service daemons ––: you insist systemd can do everything a reasonable person can expect, and therefore any suggestions for allowing alternatives is by definition unreasonable.  Using you as the example of "users voice" gives them a powerful emotional weapon to avoid discussing technical matters: "there is no need to do any of that, because users say thus; see e.g. here".  We never even get to the technical merits of the issues!

Fuck that, and fuck your opinion: it is based only on your own experience, and you're trying to claim any other experience must be wrong because yours differs.

I'm pretty sure that you and ve7xen are perfectly good people –– there will never be any animosity from my part towards you, or anyone else here (or elsewhere); only towards some of your opinions, because the effects of spreading those opinions that I see are misinformed and not supported by verifiable facts, are making users less powerful than they were, and subject to increased risk and worse tools.  From my viewpoint, those opinions hinder development, and cause serious stagnation.  The results of such innocuous-seeming opinions are horrible.
Your attitudes are extremely common, very human, really; but the fact that you cannot even notice yourself doing it, is a huge part of the problem.  Yes, it is a pet peeve of mine.

[nctnico]

But why should I bother if I can let systemd deal with that?

Fuck that, and fuck your opinion: it is based only on your own experience, and you're trying to claim any other experience must be wrong because yours differs.

I'm pretty sure that you and ve7xen are perfectly good people –– there will never be any animosity from my part towards you, or anyone else here (or elsewhere); only towards some of your opinions, because the effects of spreading those opinions that I see are misinformed and not supported by verifiable facts, are making users less powerful than they were, and subject to increased risk and worse tools.  From my viewpoint, those opinions hinder development, and cause serious stagnation.  The results of such innocuous-seeming opinions are horrible.
Your attitudes are extremely common, very human, really; but the fact that you cannot even notice yourself doing it, is a huge part of the problem.  Yes, it is a pet peeve of mine.

Well, the pattern I'm spotting at your side (with the thread you started about alternative string functions in mind) is that you focus very much on technical details but completely lose sight of the big picture. I'm quite sure I have been around working on software for much longer than you have. For example: in the past few decades I have seen your improved string handling functions (made by other software engineers) pass by several times already. Your idea is not new and you probably won't be the last. And yet the majority of the C programmers continue to use the standard C library string functions.

Bottom line: One of the things I have learned is to very carefully look at why people are using certain software libraries / routines and why they discard others. The reasons are not always technical or even quantifiable. There are more variables to the equation than you are aware off and that makes you arrive at the wrong conclusion. My advise: a good experience for you would be to become part of a group of software engineers (preferably ones that are not like minded) and work on a project together. Sure this will create a lot of debate but it will also teach every one in the group to think beyond their own horizon.

[Nominal Animal]

Well, the pattern I'm spotting at your side (with the thread you started about alternative string functions in mind) is that you focus very much on technical details but completely lose sight of the big picture.

No, I'm completely aware of the human side (what you call "the big picture"); I just choose to ignore it (other than acknowledging it exists, and describing the technical hindrances it causes), for personal reasons.

I did not participate in SiliconWizard's Design a better "C" discussion exactly because such an undertaking is really more social than technical: programming languages need to be designed for humans.

I do like designing and creating tools, but I do that by observing the task at hand first, the ways the humans go about it, and then implement a tool that I believe lets them perform the task and achieve desired results with less resources and time spent.  I do not discuss what the tool should be like with them; I only discuss how they believe the task is best performed, what the bottlenecks and issues are, and so on.  I rely on others to do that squishy human negotiation stuff; the irrationality of it burns me out.  The stuff I do in user testing is observing and measuring what is happening, and recording why the user thinks that is happening. I use those, and not the opinions and beliefs of the user (or indeed myself as an user –– one sample is way too small a set to base anything on) to base my designs on.

Perhaps the best demonstration of my stance is the fact that I am completely uninterested in the popularity of Linux, or any specific Linux distribution.

My advise: a good experience for you would be to become part of a group of software engineers (preferably ones that are not like minded) and work on a project together.

I've mentioned before (here and elsewhere) that I've done my best work in a team with very different members, each one with their own domain of expertise.  Don't make the mistake of believing that I am (or anyone else here is) only what you can infer from my output here.  I do not have as much experience as some of the older guys here, but I have worked on every rung of the ladder from code monkey to CEO since 1991, in different environments (commercial, military, scientific, and visual arts), in different sized teams, and in half a dozen to a dozen different programming languages.  I used to do cross-platform development and support, but switched to Linux-only in 2005 or so, after switching career from business to research.

There are very valid technical reasons to avoid systemd.  You've ignored all of them: "because it works for me, you are wrong, and it is useless to even discuss this" and "changing any of this involves so many people, that you should first concentrate on the human non-technical stuff, and work with other developers".
I'm not interested in discussing the social reasons (except to describe actual real-world observations), nor working in the various communities to change the social stance on systemd.

As to e.g. the Constructing short C strings in limited or constrained situations, I hopefully sufficiently expressed that these are not "new" nor "my inventions"; what was mine was the division into two categories, and the attempt to describe these in a way that would help others who needed such tools, especially those now/recently entering into the embedded programming field.  Everything else is known, and has been rediscovered over and over again.  I specifically invited others to comment, if they had discovered something different/better.

Even in the Mind over bugs: C pointer edition, you hopefully saw that my only goal was to help those who find using C pointers difficult/bug-ridden/problematic/more effort than they're worth, to better understand them, and that way, better utilize them as a tool.  The only thing in it I consider truly "mine" is the way I attempted to describe and explain stuff; all the facts and model are well known (although not agreed to by everyone).

In no case am I trying to sway anyone to align their opinion with mine, only that they acknowledge the facts instead of ignore them because they appreciate their own opinions over observable facts.  I like that others disagree, and although I am not interested in their opinions, I'm very interested in the reasons and experience that opinion is based on.  Similarly, I want to show the reasons and experience behind my own opinions, not my opinions per se.  I do get quite angry when someone declares their opinion as fact, or acts as if they were already accepted as facts, without going into the basis.

[Siwastaja]

It appears to me that nctnico is very experienced above-average but not genius-level engineer who has seen a lot of technical failures from others and also seen his own limitations. As a result, his default suggestion, in every possible instance, is to rely on something he personally have good experience on, and wary of anything he has seen someone (including himself, and others in teams he has worked with) struggle with.

Even just the possibility that someone could well manage to do something he has seen someone else struggle with doesn't even seem to cross his mind, as evidenced by all those times things like utilizing multi-MCU solutions being sometimes the right tool for the job are discussed. No, because nctnico has seen some problems, and he knows he is right about those problems (which is usually 100% true) means it can never work in any case.

He is also ignoring the fact that someone can be more capable or productive than him, or have different kind of skill set, this bias is likely because he is clearly above average himself and has seen a lot of average work, working in teams.

As a result, I'm sure nctnico is an exceptionally good consultant for businesses involved in technology because he can immediately say which technical decisions carry higher-than-average business risk, and suggest more failsafe / idiot proof alternatives. I'd definitely hire him if he said he can do the job and I wanted to have it delivered on time.

Following this same logic, I think nctnico completely missed your point about standardized interfaces giving options to do things differently, because nctnico thinks about the least-risky way of forcing one single solution. And indeed, if company X wanted to start using linux on their desktops for development work, and no one there would have any experience on linux, then the right solution would be to just download some recent distro, which runs systemd, and get it running and start doing work on it. Suggesting Devuan "because it doesn't use systemd" would be a more risky movement, likely, in that "big picture". It's obvious to me that's not what you mr. Nominal suggested but this kind of simplification is the result of nctnico being "practical".

[Nominal Animal]

I was trying explicitly to avoid giving that kind of impression, by mentioning that even the machine I currently use does have systemd.

It is only a tool for me, and I like the idea of people having lots of tools to pick from based on their particular needs.
I myself have observed that the quality of this tool is in certain ways degrading, I'm losing options I used to have, and only gaining new (security) risks.
Although some parts of this tool – Linux as a desktop environment – are becoming better, some are degrading too fast to make up the difference.

I am, fundamentally, a tool developer, and problem solver.  I see problem, I look at, observe and analyze, and talk about problem.  I don't make it my business, because in the business world, giving a solution is not as good business as providing a service to work with the problem.

In my opinion, just as important as Devuan is to Linux distributions, FreeBSD and OpenBSD are to open source operating systems in general; and Linux is to desktop operating systems.  Just because most desktop users are satisfied with Windows, does not mean it should be only one, or that it is even the best tool for the job.

I see people also often complain about Linux having many different distributions, and that they only want there to be one so that development costs are minimized.

I do not understand that either, because I've never had any trouble packaging anything, even proprietary software, to run on most if not all Linux distributions.  Even dynamic library dependencies are easily fixed using a wrapper shell script (to prep the execution environment, including library paths), and is what e.g. Firefox and Chromium do.  I can only imagine that it stems from a culture of targeting a specific version of Windows, without any idea how to create real-world portable code.  (And that does not mean following the standards religiously; it is a much more practical approach, which acknowledges that nothing is perfect, only something that can be worked with.)

The demands that Linux developers need to do X "for Linux to become more popular on the desktop" are utterly silly to me, because it is a tool I use and develop for myself, my colleagues, and my users; and its popularity among others is absolutely irrelevant to me.  It only matters in the psychological sense, and if I wanted to do something about that sort of stuff, I'd become a therapist instead.

It does annoy me to no end to have opposition against developing this tool further, to make it provably better.  It feels, I dunno, medieval?  Like suddenly encountering the inquisition, because I uncovered an uncomfortable set of facts.  The first thing is always being labeled as "unreasonable" or "conspiracy theorist".  Here, "you need to work with others, to learn how to be reasonable".

[ve7xen]

I wrote "reboot", then explained that *it used to suffice* to restart ones desktop session, for example logging in and logging out, but no longer does (as it leads to instability).

Perhaps you should read some tutorials to understand the difference between rebooting a machine and restarting a desktop session.

I do not believe that that anyone can say or show you anything that will affect your opinions, which you state as facts without any basis, so discussing any of this with you is objectively worthless.

Perhaps you should actually read my post, where I explain to you in baby steps why systemd has nothing to do with updates 'requiring' reboots. If you aren't even going to bother reading my posts, then discussing with you is, indeed, worthless.

But perhaps my pointing the untruths that you are claiming is worthwhile to other readers, because you have made many dubious and several completely untrue statements here. That is really my only desire to be involved here, to correct the falsehoods you are claiming.

If you wanted a timeout with that, then it would be a shell if ! utility... --timeout seconds ; then fail ; fi clause.

While this approach is viable, the elimination of boilerplate like this is a big advantage to modern systems like systemd. As dependencies get more complicated, you end up with spaghetti shell code a la SysV init. Putting this code in one place and describing it in meta-fashion is much more sensible.

Your model leads to much more coupling to a particular approach than systemd does; you're talking about modifications to POSIX and changes to every service in existence (at least every one that has dependencies), ffs. You also need some system-agnostic standard way to actually describe those dependencies (since dependency control now moves to the application instead of the system), which is yet another thing that would be difficult about this approach and require at the least an ad-hoc standard if not some body managing this. Not to mention that you are creating a whole new area of portability problems for application developers.

Your attitudes are extremely common, very human, really; but the fact that you cannot even notice yourself doing it, is a huge part of the problem.  Yes, it is a pet peeve of mine.

In no case am I trying to sway anyone to align their opinion with mine, only that they acknowledge the facts instead of ignore them because they appreciate their own opinions over observable facts.  I like that others disagree, and although I am not interested in their opinions, I'm very interested in the reasons and experience that opinion is based on.  Similarly, I want to show the reasons and experience behind my own opinions, not my opinions per se.  I do get quite angry when someone declares their opinion as fact, or acts as if they were already accepted as facts, without going into the basis.

I will continue to correct the factual inaccuracies that you present, but I'm not interested in discussing further with you, this attitude from someone spouting so much that is either wilfully misunderstanding the situation or outright untrue is too for me. Never mind your abject dismissal of alternative models to solve this problem that have different tradeoffs, you don't even seem to understand the difference between systemd and dbus. You are not qualified to speak on this, yet you are convinced you know better than the vast majority of actual system administrators and distribution developers, and that you're so much smarter than everyone else that is blocking your brilliant ideas.

[Nominal Animal]

That is really my only desire to be involved here, to correct the falsehoods you are claiming.

Then prove your counterclaims, and stop making this personal.  Declaring something a 'falsehood' has zero value, if you provide zero verifiable facts, only your own opinions.

To make my own basis for my opinons clear, not just for you but any other member who has slogged through this thread thus far:

D-Bus is a message bus designed for communication between desktop processes.  The protocol spec is frozen since 2006.  There was an abortive attempt to push dbus implementation into the Linux kernel in 2015, but it failed, because the bus is more properly implemented in userspace, as discussed in the kdbus: to merge or not to merge thread.  (That thread also shows the kind of social pressure set upon the kernel developers by the systemd developers to include kdbus, for non-technical reasons.  I claim that that kind of pressure is the main reason for friction between systemd developers and 'competing' projects, and causes technically inferior solutions to be accepted simply to avoid the social repercussions a rejection would cause.)

D-Bus originally had nothing to do with systemd.  The current reference implementation at dbus.freedesktop.org has a lot of systemd-specific behaviours, as can be seen e.g. from the NEWS.  Its gitlab membership list shows that among the two owners and six maintainers are Lennart Poettering (systemd lead) and Colin Walters (systemd contributor).  By "subsumption", I refer to how systemd has a special status in the project, and how Lennart Poettering was granted maintainer status in the dbus source repository.

dbus is the software package based on this in Debian and RHEL derivatives, and has a direct dependency on systemd (specifically, a build dependency on libsystemd-dev), and cannot be built or used in Debian or RHEL without systemd.

Devuan uses a fork of the freedesktop Git repo, so that any changes can be backported while removing any added systemd dependencies.  The reason for the Devuan fork from Debian is clearly stated in the announcement, and is centered on two things: the behaviour of the systemd developers, and the design and central/monolithic role of systemd in a Linux system.  The first one is subjective; but the latter is contrary to the Unix philosophy and modular design, both found reliable and useful for several decades now.  Even more importantly, the more I view systemd sources or get notified of its issues, the more I am convinced that its developers do not have the necessary skill to even implement their own design without critical security issues and creating new single-point failure modes.

More about this further below.

Your model leads to

It is just one of the examples discussed a couple of decades ago how the bootup problem (completely sequential in SysV init) could be fixed.

The other approach to dependency-based inits was describing the conditions a process has before it is launched, but that approach does not include any way for the process to report service availability, and it makes a faulty assumption that just because a service daemon was started, its service should be available.

For booting, the description method kinda-sorta works –– a delay is assumed between starting a process and the service it provides being available ––, but for a true dependency-based service manager, it doesn't work at all.  Systemd relies on such descriptions, with the end result that just like Windows, from a cold boot, it takes a while before the system is truly usable.  Since users can however log in faster, they perceive the systems to boot faster.  A true dependency-based init and service manager would yield even faster startup, yet know exactly which services are active, and not guess based on which binaries are running already.  (Subsecond boot times are achievable with embedded hardware, and have been for well over a decade now.)
However, true dependency-based service management does require source-level changes.

The reason I showed the API needed for true dependency-based init and service management, was to show how minimal the source-level changes are.

The changes made to various core services due to systemd are much more extensive, and make those services dependent on systemd: to use that same source in a system without systemd, you need to do changes.  At best, those are just build configuration, but often require patching.  udev, the device manager used in Linux is an excellent example of this.  It was initially designed by Greg KH and Kay Sievers as part of the kernel, but was later subsumed/incorporated into systemd.  udev is an excellent design, but because of its subsumption to systemd, users who don't want to use systemd have to use something else; typically eudev (which is to udev what Devuan is to Debian: tries to keep up with the good stuff, but drop the systemd dependency).

So, in the case of dbus and udev –– in my opinion, very important core services! ––, the choice is currently whether you use them with systemd, or with anything else except systemd (like OpenRC, runit, SysV, or something else).
The API approach I described does not make that distinction at all.  The reason for incorporating it into POSIX would be the same why the GNU getline()/getdelim() got incorporated into POSIX: because it is something that is needed and useful in systems programming.
In the cases where you'd run a daemon that relies on that API on a system without dependency support, the API calls would do-nothing, and the service would still work as it would under SysV init or systemd.

However, only the core services that other services depend on need to report their running, status to enable the true dependency-based init and service management. But like I said, that API is just a rough sketch of what I remember talked about, and not something I'd even propose as-is.

To have something I would be willing to propose, I would first have to go through all core services not just in Linux, but on the *BSDs as well, to form a good picture of what exactly do the services need, how they are structured (so that the API could cater to all), and talk to some security-hats about the possible exploitation scenarios.

The only true kernel-imposed task an init –– technically, the process running as PID 1, responsible for starting the rest of the userspace –– is to never exit, and to reap any zombie processes.  Failure to reap zombie processes will lead to resource starvation, but having the init exit or die will halt the system with a kernel panic.

Having more and more features in that process makes it fragile, and the vast number of reported issues indicates it is not getting any better.  In other words, I see no way to "fix" systemd, but by replacing it with something else that does not require core services to be exclusively connected to it, and instead uses the Unix philosophy and modular design to let the users choose.  The competition alone between software projects will drive "evolution".
The history of free/open source computing is replete with examples.

Never mind your abject dismissal of alternative models to solve this problem that have different tradeoffs, you don't even seem to understand the difference between systemd and dbus.

The 'abject dismissal' is 'that has been tried, and does not work well/reliably enough'.  Your counterclaim is "but it does for me, so you're wrong", and makes no sense.

The difference you seem to insist on, to me, looks semantical.  What matters, is the practical relationship.

D-Bus –– the protocol –– is not inherently systemd, and since it has been "locked" years ago, is not in danger of being subsumed by any project, unless someone does an Embrace-Extend-Extinguish on it.  The lack of documentation on how exactly systemd uses dbus makes me a bit suspicious that it might happen, but I don't think it is likely.  However, as I've shown above, dbus the project, the reference implementation, definitely has a special relationship with systemd.

Have you considered whether you understand their relationship?  Or have you just assumed that because they use separate git trees, and don't share too many maintainers and members, is proof enough that my characterization must be incorrect?

you are convinced you know better than the vast majority of actual system administrators and distribution developers

No, that is just a side effect of my peculiar deficiencies in writing English.  I only do technical English, and nowadays neither speak nor listen to it socially, so any such subtext anyone assigns to my output is incorrect: there should be none (except for self-deprecating dad jokes when emoticons are used), and the text interpreted with as little emotional content as possible.  Any observable subtext otherwise is an error on my part, but I assure you, it is NOT INTENTIONAL.  If you care to, you can find posts on this forum where I discuss exactly this problem a year or two ago.

The only fraction of system administrators and distribution developers that 'I think I know better', is the fraction that says "but it works for me, so you're wrong".  And the reason there is that they don't seem to know anything to back their opinions, just personal beliefs.

I do think I know a lot, because I've done a lot (again, if you use Linux, you almost certainly run something I've contributed to), but I do not think I know better.  As I've explained, to compare opinions, I use the basis behind those opinions, not the opinions themselves; and do not place much weight on my own opinions either.  Only the observables really matter, as opinions cannot be rationally argued about otherwise.
You have provided nothing but your own opinion, no reason to consider your opinions valid or even relevant.

I've described to you that I've observed that when installing updates to systemd or dbus, the update manager requests a system reboot, and if one declines, sometimes the desktop session (gnome or cinnamon on the machines I've looked at) crashes: first you see glitches, then it becomes unresponsive, and either just spins or crashes.  Because of the dependencies of these system components, logging out and logging back in is not sufficient to avoid the effect; a reboot is needed.
To me, this indicates a clear relationship between the three components: the desktop environment (various services running as the user, connected using dbus), dbus itself, and systemd.  In my experience, this is a serious step backwards in the system reliability, and something I would like to correct or avoid.

On Debian derivatives, kpatch can still be used to patch kernels, but why bother if you have to reboot your desktop/laptop every week or so anyway.

As to how the init system saga on Debian actually occurred, I recommend looking at the Debian-ctte (Debian Technical Committee) mailing list from Oct 2014 onwards; starting at the bug #765803 report, and on following months sampling the posts with 'systemd' or 'init' in the title.  These are the actual discussions among Debian maintainers at the time, and the proper source to use for facts.  You can also use the search facility on the list page to look up how often systemd dependency or developer issues are raised at the Technical Committee compared to other projects.

[ve7xen]

Then prove your counterclaims, and stop making this personal.  Declaring something a 'falsehood' has zero value, if you provide zero verifiable facts, only your own opinions.

I refuted most of them in my second-last post, and you responded to only one of them. I am not making this personal, I am presenting the facts as I am aware of them, and expect you to either counter my refutations, or by not responding, admit that you are have no response and were wrong.

I claim that that kind of pressure is the main reason for friction between systemd developers and 'competing' projects, and causes technically inferior solutions to be accepted simply to avoid the social repercussions a rejection would cause.)

Okay, I have said, I don't care about the politics, and don't care to learn the history. However engineers tend to be strongheaded people. There are more than a few democratic technical selection committees that have chosen this path, and I think your assertion that the same inferior solution has become accepted among so many separate communities of such people is dubious at best. The corollary of course is that these people must be either incompetent or malicious, and you have repeatedly alluded to that being your point here.

By "subsumption", I refer to how systemd has a special status in the project, and how Lennart Poettering was granted maintainer status in the dbus source repository.

dbus is the software package based on this in Debian and RHEL derivatives, and has a direct dependency on systemd (specifically, a build dependency on libsystemd-dev), and cannot be built or used in Debian or RHEL without systemd.

It is rather common for maintainers of ports to be granted maintainer status. The systemd functionality is there for effective use on systemd systems. There is also Windows-specific code in dbus, so that it can be built and used effectively there. Do you object to that? How about the optional X11 code? dbus does not require systemd as a build dependency, though it can integrate with it on systems where it is present, such as Debian and RHEL, and when built as such, it will obviously be a runtime dependency. You can easily see in the Gentoo ebuild for example that it can be built without systemd and works just fine that way.

This should be pretty obvious because lots of *nix-y stuff, especially for the desktop, uses dbus, yet works just fine on *BSD or even Windows where systemd is obviously absent. Your claim that systemd has 'subsumed' dbus is just categorically incorrect; at best the two are loosely coupled.

Devuan uses a fork of the freedesktop Git repo, so that any changes can be backported while removing any added systemd dependencies.  The reason for the Devuan fork from Debian is clearly stated in the announcement, and is centered on two things: the behaviour of the systemd developers, and the design and central/monolithic role of systemd in a Linux system.  The first one is subjective; but the latter is contrary to the Unix philosophy and modular design, both found reliable and useful for several decades now.  Even more importantly, the more I view systemd sources or get notified of its issues, the more I am convinced that its developers do not have the necessary skill to even implement their own design without critical security issues and creating new single-point failure modes.

Great, the more ports the merrier. If it has technical merit, it will succeed and displace Debian and other distributions that have been taken over by these malicious and incompetent actors. I'm all for that, this is what open source is all about. But don't promote it with false claims and drama.

However, true dependency-based service management does require source-level changes.

The reason I showed the API needed for true dependency-based init and service management, was to show how minimal the source-level changes are.

A way to advertise more granular service availability would be nice, but I don't think it displaces the need for a meta-description of the dependencies (in other words, decoupling the application and the system setup). I would like to see the advertisements side of this, but consumed by systemd or similar as part of the dependency graph. It would be pretty straightforward to implement on top of dbus, and I'm kind of surprised it doesn't exist. Nothing stopping someone from working on this, of course.

As I described, if you want the dependencies described within the application, that means that we need some kind of central authority to enumerate how particular 'abstract' dependencies are to be described in this system (e.g. how does 'the X11 server is ready' get described in a system-agnostic way, allowing for different implementations of X11, different locations of its unix or network sockets etc). This creates a lot of management overhead and friction, and seems needlessly...bureaucratic and centralized. I think it is a lot less flexible if all your dependency nodes ultimately trace back to some central management authority.

Or you do it in an ad-hoc way that would be very fragile, tightly coupled between applications, and not very portable. As nctnico outlined, this depdendency resolution really needs to be managed by the packagers / system administrators, it's not practical to push it into the hands of the application developers that should not need to know much or care about the configuration of the system they are running on and creates a bunch of new problems and makes this opaque and rigid to the user.

There are a lot of other technical tradeoffs here too. You end up with a ton of long-lived processes that sit with their code in RAM indefinitely. It makes dependency loops and race conditions impossible to catch without a supervisor that is aware of the entire dependency state of the system - and then we are back where we...well...are. It puts the dependencies and services opaquely behind the binary, and not in an easily administrator-viewable fashion. Current state is difficult to interrogate without a supervisor. It leads to a lot of boilerplate code in applications. It doesn't help at all with managing things like network/mount namespaces, capabilities, permissions and the like. It's certainly a viable approach as part of a larger system, but to claim that it is *the* approach is arrogant as all get out. There are good reasons that this has not been widely adopted as the primary way of solving these problems, despite it being an old idea.

The changes made to various core services due to systemd are much more extensive, and make those services dependent on systemd: to use that same source in a system without systemd, you need to do changes.  At best, those are just build configuration, but often require patching.  udev, the device manager used in Linux is an excellent example of this.  It was initially designed by Greg KH and Kay Sievers as part of the kernel, but was later subsumed/incorporated into systemd.  udev is an excellent design, but because of its subsumption to systemd, users who don't want to use systemd have to use something else; typically eudev (which is to udev what Devuan is to Debian: tries to keep up with the good stuff, but drop the systemd dependency).

It's the *only* example of this, and I'm not happy about it either, but it is not really a technical problem. There's no reason for packaging it with systemd, but it can still be built and used without systemd on the system, as far as I know, and Gentoo offers this and no patches are required to do it. But yeah, this is not very cool.

So, in the case of dbus and udev –– in my opinion, very important core services! ––, the choice is currently whether you use them with systemd, or with anything else except systemd (like OpenRC, runit, SysV, or something else).

If someone wanted to maintain it, it would not be difficult to provide alternate builds of dbus and udev (and likely some others) that do not have a runtime dependency on systemd, for use on such systems. The issue here is that nobody wants to maintain an alternate init on these distributions, not that it would be difficult to implement or that systemd is blocking it. On a dynamically built system like Gentoo it is more or less trivial, and lo and behold, it's a 'supported' (as it goes on Gentoo) option there.

The API approach I described does not make that distinction at all.  The reason for incorporating it into POSIX would be the same why the GNU getline()/getdelim() got incorporated into POSIX: because it is something that is needed and useful in systems programming.
In the cases where you'd run a daemon that relies on that API on a system without dependency support, the API calls would do-nothing, and the service would still work as it would under SysV init or systemd.

I think you're missing the big picture here. Yes, implementing the advertising of services this way would not be difficult or a big change, but for it to actually be useful for system management, there would be a ton of infrastructure that would need to be built up around it *and actively managed* which is not really something that POSIX does, it gets updated what every 10 years or so? I'm not opposed to adding something like this to what we have today in a holistic manner, used where it makes sense for things like 'network is up' or 'X server is running', but we already have all the pieces in place. All that is needed is a standardized dbus interface to pass these messages.

The competition alone between software projects will drive "evolution". The history of free/open source computing is replete with examples.

Agreed, we will see what happens here.

The 'abject dismissal' is 'that has been tried, and does not work well/reliably enough'.  Your counterclaim is "but it does for me, so you're wrong", and makes no sense.

In your view your solution is perfect, and the solution that the vast majority of people have settled on (it is not just me that it works for, clearly) is suitable to be dismissed without due consideration. You will need a much stronger argument than 'I don't like it' or 'I don't like how it is managed' or even 'it is limited in this way' to dismiss it as you have. And part of that will include addressing the shortcomings of your own proposals and how the tradeoff favours your solution. You have not acknowledged that your solution is limited in any way.

The difference you seem to insist on, to me, looks semantical.  What matters, is the practical relationship.

Precisely, and practically speaking, dbus is completely independent from systemd. It can build and work fine on any *nix, as well as Windows, whether or not systemd is present. It is a clear refutation of your claim that it has been 'subsumed' by systemd. Yes, it has systemd-specific code, as it does for Windows, or as glibc does for FreeBSD.

Have you considered whether you understand their relationship?  Or have you just assumed that because they use separate git trees, and don't share too many maintainers and members, is proof enough that my characterization must be incorrect?

Your claim can be dismissed on its face, because there is ample evidence of dbus-daemon working as designed on systems without systemd. Ergo, it must not depend on systemd.

No, that is just a side effect of my peculiar deficiencies in writing English.  I only do technical English, and nowadays neither speak nor listen to it socially, so any such subtext anyone assigns to my output is incorrect: there should be none (except for self-deprecating dad jokes when emoticons are used), and the text interpreted with as little emotional content as possible.  Any observable subtext otherwise is an error on my part, but I assure you, it is NOT INTENTIONAL.  If you care to, you can find posts on this forum where I discuss exactly this problem a year or two ago.

The only fraction of system administrators and distribution developers that 'I think I know better', is the fraction that says "but it works for me, so you're wrong".  And the reason there is that they don't seem to know anything to back their opinions, just personal beliefs.

No, this is not a language deficiency. It follows directly from your assertions that systemd is not appropriate and that better solutions should be chosen, and that distributions should not have allowed systemd to become integral to their systems. By making those claims, you are calling the decisions of the vast majority of distribution maintainers and system administrators that actively chose to use or implement systemd in their systems into question. Sure, you are only directly deriding the systemd team, as far as I can tell, but you are also insisting that their approach is incorrect and that anyone supporting it is also incorrect in choosing it.

You have provided nothing but your own opinion, no reason to consider your opinions valid or even relevant.

We are starting to get to a point where you are admitting that the technical assertions you have made are mostly untrue. I have described how what much of you are saying about systemd's architecture is untrue or at least misrepresented. I have described limitations of your proposed approach, and problems it creates. Your posts however have been full of opinion, accusation, and descriptions of 'your way' but little (and many factual inaccuracies) to back up your opinion.

I've described to you that I've observed that when installing updates to systemd or dbus, the update manager requests a system reboot, and if one declines, sometimes the desktop session (gnome or cinnamon on the machines I've looked at) crashes: first you see glitches, then it becomes unresponsive, and either just spins or crashes.  Because of the dependencies of these system components, logging out and logging back in is not sufficient to avoid the effect; a reboot is needed.
To me, this indicates a clear relationship between the three components: the desktop environment (various services running as the user, connected using dbus), dbus itself, and systemd.  In my experience, this is a serious step backwards in the system reliability, and something I would like to correct or avoid.

On Debian derivatives, kpatch can still be used to patch kernels, but why bother if you have to reboot your desktop/laptop every week or so anyway.

And you didn't read my response, where I described why this dependency exists, and how to address it, but you ignored that. You should not have to reboot after a systemd or dbus update, but you will have to restart many processes, as you would when updating any other system-level package like libc. If the package manager is prompting a reboot, it is a limitation of the package manager (or a choice by its maintainers to err on the side of caution), and has nothing to do with systemd. In most cases this requirement is based on dbus anyway (almost all of a typical desktop userland does not depend on systemd directly), and as we have already discussed, dbus != systemd and you will run into the exact same thing on a non-systemd system.

[madires]

I think the big issue with systemd is that it's the opposite of the UNIX philosophy and users are afraid that it will take their freedom away. And it does that already to some extend.