Products > Computers

Devuan 4.0 Released As Debian 11 Without Systemd

<< < (13/13)


--- Quote from: Nominal Animal on October 26, 2021, 12:57:16 am ---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.
--- End quote ---

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.

--- Quote ---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.)
--- End quote ---

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.

--- Quote ---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.
--- End quote ---

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.

--- Quote ---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.
--- End quote ---

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.

--- Quote ---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.
--- End quote ---

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.

--- Quote ---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).
--- End quote ---

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.

--- Quote ---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).
--- End quote ---

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.

--- Quote ---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.
--- End quote ---

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.

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

Agreed, we will see what happens here.

--- Quote from: ve7xen on October 25, 2021, 08:27:12 pm ---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.
--- End quote ---

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.

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

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.

--- Quote ---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?
--- End quote ---

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.

--- Quote ---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.
--- End quote ---

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.

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

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.

--- Quote ---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.
--- End quote ---

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.

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.


[0] Message Index

[*] Previous page

There was an error while thanking
Go to full version