Author Topic: Devuan 4.0 Released As Debian 11 Without Systemd  (Read 8202 times)

0 Members and 1 Guest are viewing this topic.

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6173
  • Country: fi
    • My home page and email address
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #25 on: October 19, 2021, 02:01:03 pm »
Most developers working on systemd components do not have any nefarious intent at all.  It is therefore natural, albeit incorrect, to infer that there is nothing nefarious in the entire project either.

The problem is, no pun intended, systemic.  Let me give an example.

A lot of users "know" that sudo and su are security-sensitive, and know to be suspicious about changes to related packages.
Very few users know that PolicyKit package is even more security sensitive, because it allows privilege escalation without user intervention.  Compare to sudo, which is configured to ask the users own password unless recently executed in the same session (terminal connection) exactly to avoid such from happening, and stops compromised user processes from escalating their privileges automatically.
Many of those reading this have checked and modified their /etc/sudoers policies to suit their needs, but how many have ever looked at PolicyKit policy files?  Or even know where to look for them?  And know that there is *more than one* set of those, both used?  (In Debian derivatives, /etc/polkit-1/ and /var/lib/polkit-1/; this kind of configuration file sleight-of-hand being rather typical of systemd components, especially when compared to traditional Unix, which kept system service configuration under /etc/.)

There is a reason why even the Debian Wiki page for PolicyKit has a "ToDo: explain how it works." and it is not that it is so obvious everyone knows.  By controlling the component and keeping it within a small circle of developers, those developers are essential to system security.  Job security for subpar developers.  It is in their best interest for the component to stay quiet, and keep the developer count small.

I'm not convinced there is anything more evil than "by doing things this way, we ensure we'll have good jobs for ourselves for the foreseeable future" by programmers who really do not understand security at all, but I do believe systemd is a bigger turd than even PHP.  Like PHP, systemd gets used because it is popular and available.  Like PHP, it is at its core an insecure, impossible to secure or make robust, "design" –– and it isn't even designed properly, just agglomerated together like a dirty snowball.

At least it is a known issue that core security services like OpenSSH and core security libraries like OpenSSL and other TLS implementations, need more resources, especially eyeballs, for the free/libre software stacks to remain viable.  But, almost nobody looks at the systemd security components, because its a socially closed domain governed by subpar developers (who have been rejected from other projects due to the low quality of their submissions).

(And I do fear, without any proof, that that might be one of the reasons the companies behind largest Linux distros are so keen to back systemd, including paying the developers well.)

TL;DR: I don't believe there is any conspiracy that hopes to get their hands in everybodys Linux systems.  I think systemd subsumes other components, because their developers want to be the ones everyone has to rely on; they want to be as indispensable as the Linux kernel is to Linux distributions.  My problem with that is that not only are those developers not very skilled, but the structure of their design is horribly bad, unfixable; and that that much power in the hands of a few cloistered fringe developers is easily exploitable at the human level via money, extortion, manipulation.

And don't tell me I should just gather more people to expose these security risks by looking at the code in the public repositories.  That is useless, because the fundamental design, the ways the components interact and work together, is impossible to make as secure and robust as the alternatives.  A turd is a turd, no matter how hard you polish it.  And, as long as the largest distros back systemd with hard money for unclear reasons, it is not possible to compete with it on purely technical terms: there are business and politics involved.

Devuan avoids systemd, and for the subsumed components, uses non-systemd forks.

Do not think that FreeBSD and OpenBSD are completely untouchable wrt. these issues, either.  Just like in Linux initially, there is now an "init-only" systemd (fork), InitWare, that is reported to run on the *BSDs.  It is being touted with exactly the same key points as were used when systemd-init was introduced to various Linux distros.  Nothing new here, yet almost nobody notices when the history keeps repeating itself...  "Oh, nobody could have predicted it would come to this!"
« Last Edit: October 19, 2021, 02:05:39 pm by Nominal Animal »
 
The following users thanked this post: BradC

Offline PKTKSTopic starter

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #26 on: October 19, 2021, 03:45:13 pm »
I don't think of some sort of conspiracy...  ::)

Business with that kind of budgets are not mindless.
There is a strategy although hidden ... it may be seen clearly ahead

The only possible way to "absorb" (BORG style) all *NIX into the already establishment is to boot a summary kernel into a simple VM as fast as possible to run whatever "applet" as a "subthing"

Things in place:
- a systemd style fast boot
- all services asasp no security no hassles of admin. setups..
- a compatible layer of pipelines audio and video..

PUFF!!  you have assimilated all *NIX into a crap VM with a single click
No conspiracy - but a hell damn nasty strategy. 

All CLOUD services (already provided that systemd uses now USER Daemon)
will charge or rent you monthly fees..

to rent space.. CPU power.. ..

All already based "services" of adverts. profiling your life will continue.

As soon as the business ditch all PCs into that business..

As said..
systemd is a clever entry port..

Will gradually obliterate the PC as we know.
For these account based point click and pay for as you go

Things are in place..
Paul
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6173
  • Country: fi
    • My home page and email address
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #27 on: October 19, 2021, 07:47:34 pm »
Things in place:
You missed Snap packages, which are essentially filesystem images mounted on loopback devices as needed, making them almost independent of the installed libraries on the system; relying on PolicyKit configs to get proper low-level access, and other systemd provided services only.  Unlike e.g. Debian packages, Snap packages are designed to work across distributions.

Essentially, because snap packages can be used across distributions, they by default avoid any scrutiny by distro maintainers.

No conspiracy - but a hell damn nasty strategy.
Very good for the provider companies, and fully backed by huge international organizations like World Economic Forum, who profess their purpose is to merge governments/governance and enterprises.  As WEF's own Agenda 2030 says, "You'll own nothing, and you'll be happy."
 

Offline Ed.Kloonk

  • Super Contributor
  • ***
  • Posts: 4000
  • Country: au
  • Cat video aficionado
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #28 on: October 19, 2021, 08:22:12 pm »
My dim view of it was the way that it was touted and hyped among the distro maintainers. Here is this shiny new thing that will once and for all tidy up the problems(?) with the existing init systems. Upon closer inspection, it seemed to be implemented like every other project with that same goal. It begins by sitting on top and wraps the commands though the existing mechanism until someone gets around to actually writing the stand alone code.
iratus parum formica
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14301
  • Country: fr
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #29 on: October 20, 2021, 12:51:26 am »
It's always fun to read discussions about systemd. Almost triggers religious opinions in some way.
systemd has the merit of existing, and quite frankly, from my part, it has worked well enough. I'm no Linux guru nor some kind of warrior, so bear with me. But there's a reason why most distros adopted it: there just wasn't anything equivalent available.

I rather like this talk, which goes into some details while trying to be balanced and honest:

 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6173
  • Country: fi
    • My home page and email address
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #30 on: October 20, 2021, 05:13:23 am »
But there's a reason why most distros adopted it: there just wasn't anything equivalent available.
Not true at all.  Even today, if you bothered to go look at the Debian bugzilla or older CTTE discussions, you'd see the systemd developers consistently pushed that view, and now religiously object to any kind of interoperability with non-systemd alternatives.  Even going as far as actively removing features used for interoperability, changing package dependencies from virtual packages to systemd implementations of those virtual packages, and so on.

Yeah, there is "balanced and honest", and then there is factual.

In Devuan, the init system is indeed up to the user to decide, as the later-subsumed subsystems are implemented using non-systemd alternatives.  In Debian, systemd is the only choice, because if you allow eg. automatic package updates (because of aforementioned changes in package dependencies) sooner or later everything will be replaced by systemd anyway.

Users don't care, because they don't see the downsides.  I remember a time when I didn't have to reboot my system due to updates, and when my desktop environment didn't crash just because the messaging bus (now dbus) daemons were updated and changed the protocol.

You do you, though.  I would like to point out how objections to systemd even in this thread are insinuated to be unreasonable, even in the face of easily obtained evidence (debian bugzilla and debian-ctte mailing list about init system "freedom").  This kind of effective community management is enviable, and isn't free.
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #31 on: October 20, 2021, 11:44:58 am »
I rather like this talk, which goes into some details while trying to be balanced and honest:


I'll qualify that video as propaganda.  Dude finds excuses for all the pitfalls of systemd, his argument over the entire video is "there was no other way than systemd to solve all these problems", which is not true.  And the title suggest something tragic about systemd.  And the comments and youtube ratings are disabled.  That's propaganda to me.
« Last Edit: October 20, 2021, 11:50:07 am by RoGeorge »
 

Online tatel

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: es
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #32 on: October 20, 2021, 05:14:46 pm »
Linux user since 1998. YellowDog Linux for my PowerBook G3. Fine if you had an english keyboard. Not my case. Then I bought my first PC to have an easier Linux ride with it. Following the advice on all computing publications, tried RedHat first, 6.x

I replaced Debian for RedHat 7.0 when it came out, then realized that all the hype on computing publications about Debian being "difficult" against "easy" RedHat was bullshit. I have never bought any computing publication since.

Never had any problems with SysV init, so i never, ever felt any need to change it. However, since Debian migrated to it (and PulseAudio  :-- ), and realizing that expurgating systemd from Debian would be such a huge task, I resigned myself to use it, and lost track of any possible alternatives. So thank you guys for the notice about Devuan

Systemd looks the same shit to me.  It could be that it gives some advantages. Certainly my machines seem to turn on and off faster. But I don't like it rammed down my throat, and while it could be a bona fides effort, I somewhat doubt it. So I think it's time to install Devuan on a spare machine to see how it does.
« Last Edit: October 20, 2021, 05:19:12 pm by tatel »
 

Offline BradC

  • Super Contributor
  • ***
  • Posts: 2104
  • Country: au
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #33 on: October 21, 2021, 12:33:16 am »
Certainly my machines seem to turn on and off faster.

I find the system boots to a prompt much faster with systemd, but it takes the same amount of time to actually do anything useful as it's still starting services in the background. I have a hell of a time getting the system to shutdown properly with systemd. It's always waiting for something for minutes.

Thankfully I only have it on a couple of VMs for specific software that requires specific operating system versions (usually Ubuntu). My experiences with it on the bare metal have been woeful.

To me it just feels like an answer to a question nobody really ever asked.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6173
  • Country: fi
    • My home page and email address
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #34 on: October 21, 2021, 05:14:37 am »
Before systemd, Ubuntu used upstart, which booted just as fast as systemd does.  Some non-systemd distros use OpenRC, which is older than systemd, and is still actively in development.  SysV init was never the only choice, only the most popular choice.

On servers, since the turn of the century, I used a mix of SysV and daemontools or runit to manage services.  (The servers tend to have very slow BIOS bootup times anyway, on the order of half a minute to a minute, so speeding up the boot is not that important.)  Both daemontools and runit will auto-restart a crashed service, and can detect a repeatedly crashing service (instead of looping forever).

Customization was always the key feature I loved about Linux.  It never imposed an approach on me; instead, I could always adapt it to my own needs and workflow.
At the user level, systemd is a serious block to that: it does not allow you to customize the core services much anymore.  You can change their configuration, but you cannot swap a core service to another, since systemd won't allow you to, unless you reimplement a systemd component yourself.  Which is kinda silly, as it is exactly the reason why the Linux kernel does not have a stable internal API: to truly redesign a component, you must be able to adjust its internal APIs accordingly, otherwise you're tied to the same design.

Users who do not do nor need that kind of deep customization, will probably be quite happy with systemd.  They'll have to reboot their machines more often, they have more security issues (especially so in the future, when the extent of systemd security holes finally reveals itself), but nothing that really impacts their day-to-day stuff.
I know, because the machine I'm typing this does have systemd.  So I'm not being paranoid, just realistic about the tools I use.

How many of you do not complain when the tools you used to rely on switch to inferior quality materials?  They still work; it's just annoying, and risky.
 

Offline ve7xen

  • Super Contributor
  • ***
  • Posts: 1192
  • Country: ca
    • VE7XEN Blog
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #35 on: October 21, 2021, 07:04:45 am »
What's this about systemd requiring more reboots? All my multiple desktops are systemd systems and I reboot exclusively for kernel updates, I've never had a need to reboot for anything else that I can recall, and I don't see why systemd would require that any more than any other service manager would. Ditto for the fleet of servers I manage.

That said, none of them are using systemd out of any intent of mine, as this thread goes into. However I'm not even the least bit upset about it. It's far more convenient as a user / administrator than any of its predecessors that I have experience with (Debian's SysV init scripts, upstart, BSD rc.d). It does away with a ton of boilerplate repeated all over the place and is much more featureful, flexible, and easy to use. I don't believe there is any conspiracy. It's convenient for distro maintainers, it's convenient for users, it's popular, it's a significant improvement on the previous situations, and it works reasonably well. The choice should not be surprising.

And since it keeps coming up, the same is true of PulseAudio. There were some teething pains, but there's no way in hell I'd go back to pure ALSA, it's just plain better in every way, and JACK cannot fit the role of system audio server well. Frankly, Linux on the desktop wouldn't really be usable for me without it having come around and gotten integrated. Using pipewire these days, but that's only possible because of PA, and both work fine, just trying out the new hotness.

I'm not super happy about systemd subsuming a bunch of random stuff, as it seems to be antithetical to the UNIX philosophy, but most of it is not really 'rammed down your throat'. Don't like systemd-resolved or systemd-timesyncd or systemd-networkd, then replace them with your preferred alternative (I have for all of these), no big deal at all, and no reason to expect the alternatives are going anywhere.

If one distribution is making 'political' decisions that exclude alternatives, then fork it, that is the open source way, but I don't see that being systemd's fault. I also don't see any reason that it's reasonable to expect Debian to maintain parallel options for something that is so integral to the system. The choice and setup of init, service manager, and package manager is a big part of what makes one distro different from another. You may not like their choices, and that is what is great about open source - choose a different distribution more closely aligned with you and move on.
73 de VE7XEN
He/Him
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6173
  • Country: fi
    • My home page and email address
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #36 on: October 21, 2021, 11:48:17 am »
What's this about systemd requiring more reboots? All my multiple desktops are systemd systems and I reboot exclusively for kernel updates, I've never had a need to reboot for anything else that I can recall, and I don't see why systemd would require that any more than any other service manager would. Ditto for the fleet of servers I manage.
Prior to systemd, I applied even kernel updates without having to reboot.  I had uptimes on the order of a year, but still running completely up to date kernels.  I even did a few local hotfixes for bugs without an immediate accepted fix.

Any update to core systemd components also requires a system reboot.  Without the reboot, you'll risk crashes, because those core components assume all of them run the same version, and have basically no error checking.  A typical symptom is your desktop environment crashing, because your (user) dbus-daemon process has crashed.

While systemd began as an init system and a service manager, it is a helluva lot more than that today.  Perhaps you should actually go and have a look at all the things it has incorporated, from service management to privilege separation to interprocess communication, before you assume you know the facts – even if you are a system administrator, and believe you already know all you ever need to know.
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 7695
  • Country: de
  • A qualified hobbyist ;)
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #37 on: October 21, 2021, 01:10:19 pm »
My problem with systemd is that its developers are reinventing the wheel the Microsoft way and also have strange ideas how things should be done. It has some neat little features, but also makes some things more complicated and cumbersome at the same time. Summa summarum I don't see any real benefits. And I'm annoyed that many linux distros forced systemd upon users (quite Microsoft-like).
 

Offline ve7xen

  • Super Contributor
  • ***
  • Posts: 1192
  • Country: ca
    • VE7XEN Blog
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #38 on: October 21, 2021, 07:10:07 pm »
Prior to systemd, I applied even kernel updates without having to reboot.  I had uptimes on the order of a year, but still running completely up to date kernels.  I even did a few local hotfixes for bugs without an immediate accepted fix.

If you're doing live patching using kpatch or ksplice or similar, I'm not sure why systemd comes into it, both work fine on systemd systems, and systemd shouldn't care about the kernel, it is completely userland. Care to elaborate?

Quote
Any update to core systemd components also requires a system reboot.  Without the reboot, you'll risk crashes, because those core components assume all of them run the same version, and have basically no error checking.  A typical symptom is your desktop environment crashing, because your (user) dbus-daemon process has crashed.

The only one that could be problematic to restart is init, PID 1, which can be restarted with systemctl daemon-reexec. What am I missing?

Quote
While systemd began as an init system and a service manager, it is a helluva lot more than that today.  Perhaps you should actually go and have a look at all the things it has incorporated, from service management to privilege separation to interprocess communication, before you assume you know the facts – even if you are a system administrator, and believe you already know all you ever need to know.

I guess you are referring to polkit as 'privilege separation' (of course the kernel is, as ever, managing privilege separation)? This isn't part of systemd, though systemd does depend on it, so I guess the confusion makes sense, and of course if you don't trust polkit or systemd that offers some system-level actions, you will see this as an issue. However it does provide much more granular and specific permissions, enforced by the kernel's privilege separation, than sudo (which also was not trusted by recalcitrant admins for a long time, but most have come around by now). This allows more things to run as a user and never escalate, which is ultimately a better situation. I'm not sure how difficult it is to replace this with the old way of just running things as root either through setuid or sudo as a practical matter, but something *like* polkit was definitely needed and it makes sense for the community to pick one as it requires integration on the application side.

dbus is used for IPC, which has been around much longer than systemd, and was already all-but-required on a modern Linux system when it was chosen for systemd. I believe systemd may provide an implementation of the service side, but there are at least 3 viable options, and the distributions I use are using the standard dbus-daemon as ever.

I think I have a pretty good understanding of what systemd does and does not do, and it is clear to me that the 'old way' needed to go. Is systemd and its pulled-in dependencies the best way forward? Eh, maybe not, but it is an improvement and there tends to be, even in the Linux community, a 'default' option for everything that is chosen by most distributions and users. I'm sure if that was OpenRC+polkit+something (what is the replacement to dbus, I don't think there really is one), there would be people complaining when distros switched, and others forking things to run on systemd. There's nothing wrong with that, and nothing stopping alternative implementations and distributions using them, but man the zealotry, accusations of malfeasance, and intentional or conveniently accidental conflation of ideas gets tiresome.

What the hell incentive does the Debian team have to choose systemd for vendor lock-in or whatever it is being accused of here?? It's one of the most legitimately-open distributions out there and has virtually no commercial footprint, and stuck to SysV init for longer than most.
« Last Edit: October 21, 2021, 07:12:31 pm by ve7xen »
73 de VE7XEN
He/Him
 
The following users thanked this post: nctnico

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6173
  • Country: fi
    • My home page and email address
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #39 on: October 22, 2021, 06:58:04 am »
Any update to core systemd components also requires a system reboot.  Without the reboot, you'll risk crashes, because those core components assume all of them run the same version, and have basically no error checking.  A typical symptom is your desktop environment crashing, because your (user) dbus-daemon process has crashed.

The only one that could be problematic to restart is init, PID 1, which can be restarted with systemctl daemon-reexec. What am I missing?
You're missing the fact that desktop update managers do ask/require reboots whenever a systemd-subsumed core service package is updated.  If you do not reboot, and e.g. dbus-daemon binaries are updated, it is common for the desktop manager (gnome or cinnamon for example) to crash at some point.

Quote
If you're doing live patching using kpatch or ksplice or similar, I'm not sure why systemd comes into it, both work fine on systemd systems, and systemd shouldn't care about the kernel, it is completely userland. Care to elaborate?
Prior to systemd, when e.g. dbus-daemon was updated, it sufficed to restart just the updated daemon (or for nontechnical users, to log out and back in achieved the same) to ensure the updated binaries were being executed.  It no longer works, because of the tight integration of the daemons to the root systemd.

(After updating core system packages, it used to suffice to restart the affected binaries; I did this in a staggered manner, to minimize the effect on provided services, but for users, told them to simply log out and back in, to ensure they were using the updated binaries and applications.  This often still works on server machines without desktop environments, but isn't anymore what the developers recommend: they assume everyone reboots the machines after core system updates.)

As an example, after a few days of uptime, log out of your desktop session, then observe the process list.  Very often, say 10-25% of the time, some of your user service processes (dbus-daemon etc.) are still running.  This is a problem, and instead of fixing it, distro maintainers decided just to set the update managers to asking the user whether they wanted to reboot; and changed the documentation to recommend rebooting as the first "fix" to everything.

Quote
I guess you are referring to polkit as 'privilege separation' (of course the kernel is, as ever, managing privilege separation)? This isn't part of systemd
Yes, it is.

polkit manages privilege escalation to user services that need it.  In practice, it means that an application can use polkit to elevate its privileges without user intervention.
I'm sure you want to quibble about "privilege escalation service is not 'privilege separation'", but I disagree.

Its freedesktop gitlab README describes itself as "polkit is a toolkit for defining and handling authorizations".

The problem with polkit is not exactly what it does –– the problem, fine-grained permission/privilege control, is real and sudo is designed for human users, not to be used by services –– but its implementation and how the developers try to avoid being noticed by users.  Consider polkits Changelog (it's empty), or a typical comment by one of the polkit contributors (Simon McVittie): "It should generally not be necessary for users to contact the original maintainer."

Quote
dbus is used for IPC
and has been subsumed by systemd.  There are still non-systemd dbus implementations (that e.g. Devuan uses).

The core issue with the standard dbus-daemon is that it no longer forks processes itself, it only tells systemd to fork and execute them.  Don't you see that no matter what you say about project organization, that is by definition subsumption of functionality: the dbus-daemon no longer performs the action, only delegates it to systemd.

Quote
it is clear to me that the 'old way' needed to go.
Sure, that I do completely agree with.  I personally only used the 'old way' for the initial bootup, not for runtime service management, on servers I maintained, since 2001 or so.  On desktops, I wasn't happy with the service IPC (what is essentially now dbus) approaches, because of their complexity.

(I also loved to use LDAP for larger organizations, as its configuration and inter-server-operability suited my needs very well.  Then, Active Directory came along, and skewed everything so that now everything is Windows-oriented, and Unix/POSIX support is a second-tier citizen.  Annoying as hell for someone who only uses Linux and BSDs, and not Windows at all.)

However, the service management side was already a solved problem (as shown by runit, daemontools, and other service managers), as was init (as shown by e.g. upstart).

There is absolutely no sane reason to require system services to use dbus to report their status –– neither the protocol or its implementation is at all robust.  Do you recall the kdbus debacle, when they (well, Greg KH, who is a reliable and responsible developer, but really didn't think before submitting it) tried to push it into the kernel?  Even then, a lot of people pointed out much better ways to implement the same in user space.  The dbus developers main objection was that it was too much work, and what they have now works fine for them.

It would have been much better to simply continue forward with the dependency-based inits, with a very simple sub-init service manager using Unix Domain sockets to maintain connections to each service.  This would have required adding a library and library status calls for every daemon, but at that point it was seen as "too much work" or "infeasible".  Yet, that's what eventually did happen with dbus anyway.

(Why Unix Domain?  Because on Linux and BSDs, it provides a way to both authenticate the communicating processes (PID, UID, GID), as well as pass new descriptors.  Why not?  Because it is not supported in Windows.  I wonder why that would matter to dbus developers?  I do not know.)

As shown by daemontools and runit in practice, they were much more robust in managing long-running services.

Quote
nothing stopping alternative implementations
Except systemd developers in e.g. Debian.  They very actively object to any kind of interoperability with non-systemd components.
Just go look at debian-ctte mailing list and the bugzilla; such discussions are extremely common.

Quote
What the hell incentive does the Debian team have to choose systemd for vendor lock-in or whatever it is being accused of here??
There is no "Debian team".  It is a community with extremely well defined rules, including very strict voting.

One of the core principles there is that maintainers are assumed to know what they're doing.  In case of disputes and problems, the Debian Technical Committee (CTTE) can be asked to provide an opinion.

When Debian switched from SysV init to systemd, the idea was that maintainers would work together to ensure "init freedom".  In 2014, Ian Jackson called for a general resolution (basically a vote by all Debian maintainers), to preserve the choice of init systems for the users.  This kinda-sorta failed, because most maintainers felt it would have forced maintainers to maintain stuff they weren't interested in.

The systemd component maintainers took that as a carte blanche for rejecting all interoperability between init systems, and started actively blocking contributions to allow users to switch from systemd to another init system.  Such actions have been taken to Debian CTTE many, many times now, but they're unwilling to override a specific maintainer exactly because they do not want to force maintainers to maintain code only others need (compare to e.g. out-of-kernel drivers, for example).

I understand the viewpoint, but I disagree, because I consider respecting the user freedom and interoperability more important than maintainer freedom, for core components of the system.  I do systems level programming myself, and have contributed fixes and patches to everything from the Linux kernel to glibc and gcc, so I'm not saying here what others should do; I'm describing how I see our responsibilities and freedoms as core system developers/contributors.

Quote
stuck to SysV init for longer than most.
Do not forget, that the question in Debian was NOT whether to stay with SysV or switch to systemd.
It was whether to switch from SysV to upstart or systemd.  The competition was between upstart and systemd, not between SysV and systemd.
 
The following users thanked this post: madires

Offline ve7xen

  • Super Contributor
  • ***
  • Posts: 1192
  • Country: ca
    • VE7XEN Blog
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #40 on: October 22, 2021, 08:07:44 pm »
You're missing the fact that desktop update managers do ask/require reboots whenever a systemd-subsumed core service package is updated.  If you do not reboot, and e.g. dbus-daemon binaries are updated, it is common for the desktop manager (gnome or cinnamon for example) to crash at some point.

Of course you need to restart your desktop session when the underlying services are affected. This is the case regardless of whether you are updating dbus-daemon in a systemd system or one that does not use systemd. Restarting dbus-daemon may require a lot of services to be restarted, up to and including init, but it does not require a reboot.

Again, of course, package managers trying to resolve runtime dependencies and determine what actually needs to be restarted is nontrivial, and rebooting is always going to be safe, so that is what they recommend. Many systems also recommend rebooting after a glibc or other core library updates, for similar reasons; it's not required, it's just guaranteed to work and simple. This has nothing to do with systemd. dbus-daemon is not a part of systemd, and has been a dependency of desktop Linux systems since well before systemd even existed. This is not new. I don't know why restarting it doesn't work for you, but it works fine for me.

Quote
polkit manages privilege escalation to user services that need it.  In practice, it means that an application can use polkit to elevate its privileges without user intervention.
I'm sure you want to quibble about "privilege escalation service is not 'privilege separation'", but I disagree.

That is not what polkit does. It provides a framework for describing and evaluating access policies to services offered by other processes, as the name and project description suggests. An unprivileged process accessing services offered by a privileged process is not escalation, and in fact it is exactly the point of privilege separation - to separate the privileged and unprivileged elements of the system with a clean interface between them. The unprivileged process never gains privileges, it accesses the services of another process. You may take issue with the privileged services that systemd offers this way or something, and indeed that may extend to process escalation, but it is not the only way to do that.

Privilege management itself, ie. what an individual process is actually allowed to do on the system) remains handled by the kernel's privilege system / cgroups.

Quote
Consider polkits Changelog (it's empty)

The changelog appears in the NEWS file, from the git history it seems reasonably complete.

Quote
and has been subsumed by systemd.  There are still non-systemd dbus implementations (that e.g. Devuan uses).

It seems like maybe you consider any project managed by freedesktop.org to be 'part of systemd' or something? As far as I know nothing has changed in the management of the dbus project, and it predates systemd by many years. It remains a separate project and separate system process that is not dependent on systemd. systemd, of course, requires dbus, though not specifically the freedesktop.org implementation (it can also use the in-kernel kdbus for example). This seems like fine separation of responsibility, compatible with the unix philosophy to me.

Quote
The core issue with the standard dbus-daemon is that it no longer forks processes itself, it only tells systemd to fork and execute them.  Don't you see that no matter what you say about project organization, that is by definition subsumption of functionality: the dbus-daemon no longer performs the action, only delegates it to systemd.

dbus is a message bus. I don't have any idea what you mean by 'telling systemd to fork and execute processes'. It shouldn't be forking and executing processes or doing any actions at all, it's a daemon that passes messages. If it once did (though I don't think so, this would normally be started as part of your user session setup by your desktop environment or whatever), to aid session management, I would consider that is not its job, and systemd or something else with that purpose is the correct place to be doing that.

Quote
However, the service management side was already a solved problem (as shown by runit, daemontools, and other service managers), as was init (as shown by e.g. upstart).

Kind of 'solved' but not in a holistic and elegant manner. I know you don't like the fundamental idea of 'holistic', but it is IMO the cleanest and most flexible solution of any of these for process management.

Quote
There is absolutely no sane reason to require system services to use dbus to report their status –– neither the protocol or its implementation is at all robust.  Do you recall the kdbus debacle, when they (well, Greg KH, who is a reliable and responsible developer, but really didn't think before submitting it) tried to push it into the kernel?  Even then, a lot of people pointed out much better ways to implement the same in user space.  The dbus developers main objection was that it was too much work, and what they have now works fine for them.

On the one hand you are complaining about a particular implementation being dominant, and on the other you are dismissing attempts to create diverse implementations. Which is it?

And systemd does not require services to do anything at all with dbus, it works with simple shell-scripts, or whatever other unmodified process just fine.

Quote
It would have been much better to simply continue forward with the dependency-based inits, with a very simple sub-init service manager using Unix Domain sockets to maintain connections to each service.  This would have required adding a library and library status calls for every daemon, but at that point it was seen as "too much work" or "infeasible".  Yet, that's what eventually did happen with dbus anyway.

I strongly disagree. Tracking the actual state of the processes is a huge improvement, and another process' state is not the only thing that you may want to depend on. Having dependencies actively managed is a big step forward over a bunch of shell nearly-but-not-quite-identical scripts returning their execution status (maybe).

On the one hand you complain about systemd requiring services to implement something in dbus (which it simply does not), and then in the other you are suggesting that services that are unmodified simply won't work with your system, which is both worse and the same kind of tight coupling that you are railing against. This is just plain inconsistent.

Quote
(Why Unix Domain?  Because on Linux and BSDs, it provides a way to both authenticate the communicating processes (PID, UID, GID), as well as pass new descriptors.  Why not?  Because it is not supported in Windows.  I wonder why that would matter to dbus developers?  I do not know.)
Railing against attempts at improving portability are not going to win me over.

Quote
Except systemd developers in e.g. Debian.  They very actively object to any kind of interoperability with non-systemd components.
Just go look at debian-ctte mailing list and the bugzilla; such discussions are extremely common.

Trying to keep this technical, because the political aspects just don't interest me and I really don't care. This is part of what makes open-source great. If you don't like the decisions of the project, you fork, and either continue in obscurity, or the community agrees and adopts the new project. IMO the system init and process management is core to the system, and I see no reason that Debian should be expected to support multiple solutions. You would never expect Debian to have proper support for RPM packages in the core system, why do you expect it to include multiple init options? Maybe if someone wanted to take it on it could be a different operating system a la Debian GNU/HURD.

Quote
There is no "Debian team".  It is a community with extremely well defined rules, including very strict voting.

Yes, that is my point.

You have made a lot of accusations about people having malicious intent in pushing systemd, and that is what I am pushing back on when I am even willing to get into the politics here. What is their motivation? It just sounds like everyone involved is making sensible decisions for the project and themselves, and the overseers don't see any real problems with those decisions, which is more or less where I am sitting. But like I said, I don't really care to get into the politics.

Quote

I understand the viewpoint, but I disagree, because I consider respecting the user freedom and interoperability more important than maintainer freedom, for core components of the system.  I do systems level programming myself, and have contributed fixes and patches to everything from the Linux kernel to glibc and gcc, so I'm not saying here what others should do; I'm describing how I see our responsibilities and freedoms as core system developers/contributors.

Core components of the system are the ones that are least likely to be interoperable and interchangeable. This shouldn't really be surprising. Those core parts of the system are what makes the system what it is.

Quote
Do not forget, that the question in Debian was NOT whether to stay with SysV or switch to systemd.
It was whether to switch from SysV to upstart or systemd.  The competition was between upstart and systemd, not between SysV and systemd.

Upstart is objectively terrible, and is now basically abandoned. Canonical developed it, were the only notable distro to ever use it, and even they quickly migrated away. If that was what the Debian team was evaluating as an alternative, they made the right decision.
« Last Edit: October 22, 2021, 08:10:32 pm by ve7xen »
73 de VE7XEN
He/Him
 
The following users thanked this post: nctnico

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6173
  • Country: fi
    • My home page and email address
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #41 on: October 22, 2021, 09:57:47 pm »
You're missing the fact that desktop update managers do ask/require reboots whenever a systemd-subsumed core service package is updated.  If you do not reboot, and e.g. dbus-daemon binaries are updated, it is common for the desktop manager (gnome or cinnamon for example) to crash at some point.

Of course you need to restart your desktop session when the underlying services are affected.
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.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #42 on: October 22, 2021, 10:53:26 pm »
It would have been much better to simply continue forward with the dependency-based inits, with a very simple sub-init service manager using Unix Domain sockets to maintain connections to each service.  This would have required adding a library and library status calls for every daemon, but at that point it was seen as "too much work" or "infeasible".  Yet, that's what eventually did happen with dbus anyway.

I strongly disagree. Tracking the actual state of the processes is a huge improvement, and another process' state is not the only thing that you may want to depend on. Having dependencies actively managed is a big step forward over a bunch of shell nearly-but-not-quite-identical scripts returning their execution status (maybe).

On the one hand you complain about systemd requiring services to implement something in dbus (which it simply does not), and then in the other you are suggesting that services that are unmodified simply won't work with your system, which is both worse and the same kind of tight coupling that you are railing against. This is just plain inconsistent.
I agree. The old init scripts are no good for a modern day system where services can start / stop at any time and have strong dependancies (for example: don't start an application before Wayland is up & running as it needs Wayland for output). From an operational perspective systemd makes life a lot easier. For starters: Being able to query the status of a service (which can be totally unaware of being run from systemd) using systemctl status <service name> makes life a lot easier compared to digging through one of the many system log files and filtering out the messages you are interested in. As a user I really don't care about politics are how something is built. As long as it does what it should. Given the fact that most distros have switched to systemd shows that it is better than 1) what was before 2) what else is out there. And likely it will be replaced by something else at some point.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6173
  • Country: fi
    • My home page and email address
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #43 on: October 23, 2021, 12:28:57 am »
I agree. The old init scripts are no good for a modern day system where services can start / stop at any time and have strong dependancies (for example: don't start an application before Wayland is up & running as it needs Wayland for output).
That only applies to SysV init, and I didn't use it for service management after 2001 or so; I used daemontools and runit.

Both daemontools and runit track the state of the daemon (primary process, in particular).

The system level interface for dependency tracking should be implemented as a library interface; for example,
    int  service_report(const char *svc, const int state);
could be a thread-safe, async-signal safe interface to report the service daemon facilities and state to the service manager (which does not need to be the init), and something like
    int  service_provide(const char *svclist, const double timeout);
could be a thread-safe but not async-signal safe interface to wait for a specific set of services to become available, and
    int  service_query(const char *svc);
a thread-safe but not async-signal safe blocking (but fast) interface to query the state of some specific service.

The underlying mechanism is similar to how the C library implements PAM and resolver support for even static binaries.  Essentially, even static binaries support overriding the above at runtime, using one of the libraries (depending on the init and service manager used) that all provide the same API.  The binaries themselves are compiled with do-nothing stubs of the above.  How the library communicates with its init and/or service manager is up to the library; only the API is important here, because the same API must work across all sort of service daemons.  A particularly large difference is between multiprocess and multithreaded single-process daemons.

The idea is that instead of the service manager trying to decide when to start each service, the service daemons can manage the dependencies themselves, and report all state changes (knowing that the library calls are expected to be extremely lightweight, robust, and available in different contexts, including signal handlers).  The API matters most to service developers, so init system and service manager developers would have to just deal with the interface, even if they "know" some specific interface most assuredly suffices for everybody.  You know, like 640k of RAM.

To even suggest a proper API, I would have to do a lot of preliminary work, and examine say the hundred most used base service daemons, to suss out the different needs.  The above are just the simplest possible examples I can think of, that should give one an idea how simple the interface could be, and how easy the changes to existing daemons.

Note how the other direction, the way a service manager tells a service daemon to change state, is a completely separate facility.  It will annoy the framework-oriented people to even think of keeping the above service state reporting separate from service state controls, but exactly this kind of modularity (per Unix philosophy and the KISS principle) has been proven since the origins of Unix to just work better.  Fewer single point failures, for one.

All this kind of development or experimentation is essentially killed from entering Debian (including Ubuntu) and RedHat derivatives, because the init system maintainers absolutely reject any patches to allow interoperability with non-systemd core components.  It is not a technical discussion, but a social one: you'd need community managers and human-oriented public relations tech people (the kind that write articles and blogs and talk to the devs regularly over social media and/or email) to change that, before there could be any development along this track.  Even just getting the state-tracking hooks into the code is near impossible, because of lack of interest in supporting anything except systemd.

With Devuan, this kind of experimentation is possible, but only if you patch and recompile all the affected services yourself, and even if accepted as Devuan, the full changeset is likely outside the maintainer resources of the Devuan community.  For the above reason, many upstream service developers and maintainers will not be interested in accepting any such patches, because any code change is a maintenance burden, and there must be a net positive for the maintainers to accept a patch; all that work would be limited to Devuan only.  I'm not sure it is worth that much effort.

Perhaps the saddest fact is that when Debian adopted systemd, basically all modular init and service management work outside systemd was killed.  Not by design, but by fiat: it just happened that way.  Yes, there are still projects like OpenRC, and even Runit hasn't bit-rotted too badly yet, but there is absolutely no interest in companies to support such development, and this kind of widely-affecting changes requires support and money; that's why upstart development was dropped like a hot potato when Debian (and therefore Ubuntu and derivatives) switched to systemd.

Fact is, systemd does not give anything that I didn't have already in 2005 or so.  I only lost modularity, options, and choice.  None of what I wrote in this is new, and was known and discussed before the turn of the century.  Yet, we're still stuck at the same state, except with a single-point failure-prone monolithic subsuming glob, instead of the modularity we used to have.  To me, that is a net loss.

In another thread I've mentioned that there hasn't been any serious software engineering developments in the last two decades or so, either.  Yes, GCC and Clang for example are much better at optimizing code; we have much better algorithms for e.g. video compression; we even have a couple of new programming languages, and definitely a lot of new libraries; but nothing big, only small incremental developments.  Which means I'm not surprised at all that systems development has stagnated.  I've looked at the sources of quite a few Linux appliances, and to me, it seems like the quality is definitely not going up there either.
« Last Edit: October 23, 2021, 12:34:59 am by Nominal Animal »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #44 on: October 23, 2021, 06:19:06 am »
I agree. The old init scripts are no good for a modern day system where services can start / stop at any time and have strong dependancies (for example: don't start an application before Wayland is up & running as it needs Wayland for output).
That only applies to SysV init, and I didn't use it for service management after 2001 or so; I used daemontools and runit.

Both daemontools and runit track the state of the daemon (primary process, in particular).

The system level interface for dependency tracking should be implemented as a library interface; for example,
    int  service_report(const char *svc, const int state);
could be a thread-safe, async-signal safe interface to report the service daemon facilities and state to the service manager (which does not need to be the init), and something like
    int  service_provide(const char *svclist, const double timeout);
could be a thread-safe but not async-signal safe interface to wait for a specific set of services to become available, and
    int  service_query(const char *svc);
a thread-safe but not async-signal safe blocking (but fast) interface to query the state of some specific service.

The underlying mechanism is similar to how the C library implements PAM and resolver support for even static binaries.  Essentially, even static binaries support overriding the above at runtime, using one of the libraries (depending on the init and service manager used) that all provide the same API.  The binaries themselves are compiled with do-nothing stubs of the above.  How the library communicates with its init and/or service manager is up to the library; only the API is important here, because the same API must work across all sort of service daemons.  A particularly large difference is between multiprocess and multithreaded single-process daemons.
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case. In my particular case I start a regular program from a shell script on a bare bones Linux system (which doesn't even have a Window manager) using systemd to manage the dependancies.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline BradC

  • Super Contributor
  • ***
  • Posts: 2104
  • Country: au
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #45 on: October 23, 2021, 07:15:57 am »
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case.

So does pretty much every *nix and init variant since time began.
 

Offline PKTKSTopic starter

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #46 on: October 23, 2021, 08:25:09 am »
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case.

So does pretty much every *nix and init variant since time began.
 

Yep

And judging by some comments i think some folks have no clue how SysV can do anything  systemd can... plus safer and 1000x lighter faster

Systemd is a tragic business made to remove users and sys admins from real boot control

Master piece of it putting a resolver and home user daemon in init..  wtf

Paul
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #47 on: October 23, 2021, 08:30:31 am »
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case.

So does pretty much every *nix and init variant since time began.
Yes and no. What Nominal Animal is aiming at is that automatically started daemons comply to a specific C style software API (like Windows services have to do) which is a much less flexible solution.

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.
« Last Edit: October 23, 2021, 12:40:27 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6173
  • Country: fi
    • My home page and email address
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #48 on: October 23, 2021, 01:38:36 pm »
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case.

So does pretty much every *nix and init variant since time began.
Yes and no. What Nominal Animal is aiming at is that automatically started daemons comply to a specific C style software API (like Windows services have to do) which is a much less flexible solution.
Fuck no!

I said that is what suffices to provide both dependency-based inits, and service tracking, for C-based service daemons.  I picked C as the example, because most service daemons are written in C.  The C API is the only "fixed" part of competing/alternate implementations, and is dictated by the service daemons, NOT service managers or init systems.  Don't you see how this is exactly opposite to what Windows and systemd does?

With such an API for C-based daemons, the same additions to the code base would cater to ALL init systems.  No dependency on any specific one, not systemd, nor "mine"; even the API would be dictated based on the needs of those daemons, and not init systems.  You would not even need to recompile anything to switch inits or service managers.  The maintenance burden on everybody is minimal, almost zero, after the API stabilizes.  I know me fail English, but how hard is this to understand?

Optimally, this API would be incorporated into POSIX, similar to say syslog() interface.  Instead of logging errors and warnings, this API would just report service status changes, and query other service statuses.  It would solve the whole fucking init mess in one stroke, and allow robust dependency-based automatics.

At the desktop, the same interface could be used for user-specific services (desktop services et cetera), using a per-user service/application manager.

This kind of standardization track is not unprecedented, either.  Cairo, for example, got adopted into the C++ standard, and its development history is rather similar, except that it never encountered the kind of opposition that systemd developers pose for init system and service manager development.

Obviously, a C API alone would not suffice.  However, every single ELF binary you run in a standard Linux distribution, already has a dependency on the standard C library (that includes binaries compiled from C++, Rust, Go, and others).  The C API would only be the common denominator.  I'd expect bindings to all programming languages, as well as shell utilities (perhaps even Bash built-ins for efficiency?).  This stuff was extensively discussed before and around the turn of the century, but since then, all development has stalled due to everyone shifting to systemd, which itself has not provided anything new that did not already exist in use in 2005 or so.  Nothing in this is my "invention", although any mistakes are mine since it has been a couple of decades since I was heavily invested in this kind of development.

(For example, daemontools and runit both use a pipe or socket in a high-numbered descriptor to track if the service daemon process –– be it single-process or multi-process –– completely dies.  There is absolutely zero action or code or code changes on the part of the tracked process; they are completely unaware of the existence of the descriptor.  When the last process that has that descriptor open exits, the service manager immediately sees an end-of-input on the other end of the pipe or socket, so the service crash is immediately detected.  No polling of /proc etc. needed.  This all is well known stuff among us non-systemd init developers and tinkerers.  At the time, the main question was whether daemons do, or should, close all "unknown" descriptors when they start.  Hah, times were so much simpler then.)

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.

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.

If you wanted applications to be started when a specific service or another application is started, then you use a service or application manager for that stuff.  You'd configure that manager to do what you want it to.  I'm only describing here an example of the very simple API that would suffice for the interprocess communication between monitored services and daemons and such application/service managers; you don't need the kind of obscure spaghetti mess that systemd+dbus is to achieve this.

Systemd is imposing a dependency on either itself or dbus to system services, and I consider that a bigger problem than attempting to standardize an API consisting of just a few functions (that compile to do-nothing stubs, that are replaced at run time like standard C resolver or Linux PAM functionality; ordinary, reliable, already well known approach) designed based on daemon developers needs.  I am frankly amazed and horrified that you think such an API – that lets anyone write their own implementation to work best with their own init and/or service management – is somehow a step backward compared to systemd.  Even though it would mean that service daemons currently dependent on a specific dbus implementation could drop that dependency, without losing any functionality, and possibly even gain better portability to non-Linux systems (like *BSDs).
« Last Edit: October 23, 2021, 01:42:15 pm by Nominal Animal »
 

Online tatel

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: es
Re: Devuan 4.0 Released As Debian 11 Without Systemd
« Reply #49 on: October 23, 2021, 01:51:30 pm »
What the hell incentive does the Debian team have to choose systemd for vendor lock-in or whatever it is being accused of here?? It's one of the most legitimately-open distributions out there and has virtually no commercial footprint, and stuck to SysV init for longer than most.

Sorry man. I'm not accusing Debian, but systemd. I like Debian almost as much as I like my girlfriend, for the very same reasons you mention. That's why I didn't change to another distro without systemd at the time.

However, after reading about how Poettering admitted that the borg-like approach in systemd is there by design, I can't like that. If somebody need to do this way to succeed in the competition, probably there's something bad somewhere (I think). What that bad thing could be is everybody's guess. However, I didn't switched from MacOS to Linux to get locked in again, if at all possible. Unfortunately, it looks like the borg approach succeded, or is close to success. So much for the better, fairer darwinist approach.

I bet that, should systemd not require such by-design extensive integration, Debian probably would have continued to support some alternative. Obviously, there were developers interested in that alternative, or Devuan wouldn't exist. I guess that would have implied doubling infrastructure, etc, and, being non-commercial, probably Debian does not have the resources to do that. Just my thought, and I'm sure I could probably be proven wrong. Or maybe not.

That systemd borg-like approach is a bad idea in itself, that there weren't so-urgent reasons to switch from SysV to systemd, and that we would be better by making sure there is a not so intrusive alternative, remains just my personal opinion, and opinion is like the anus: we all have our own. However, opinion is the base of politics, and that init war is all about politics. No need to argue interminably about any advantage systemd could give: some of us are worried about what it takes. I think we all agree that linux init could be better than SysV. But we don't all agree that systemd is the way to go.

Now, having Devuan at hand, I think it's worth the hassle  to give it a try on some spare machine, and possibly give the pure darwinist approach some air to breath.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf