MX Linux Forum

Something rather interesting approached me the other day. One of my 'people' that I turned onto Linux and setup with MX Linux asked about systemd and it if was something they needed to learn.

Having really only read about systemd, and only ever worked with sysvinit, my initial reaction was 'well, MX has both, you can check them both out.'

And then, attempting to live as I speak, I decided that I should learn more about it and give it more than a quick look. As I work with it more and more, I am kind of baffled by why people really like it. It seems to be moving / moved to a more 'monolithic OS approach' and away from the smaller, more precise control that I have always appreciated with Linux. (At least in my opinion, and my tinkering so far - I see what people are writing about when they say 'large'.)

But what really hit me was it *does* seem like more and more distro's are moving to it... and so my real question ... (and yes, I DO realize this is a VERY loaded question :-) )

Should we be planning on a future of sytemd?

I think MX ships with systemd-shim which isn't the full systemd package one would get by running e.g. vanilla Debian. It's just an additional layer that allows programs that depend on systemd to run. @Devs: please correct me if I'm wrong here.

One of the many reasons I use MX on my main computer is that it doesn't use systemd, so I'd favor against a switch to that. I like having this alternative to all the mainstream distros.

All that said I think it will become more and more difficult to sustain a systemd-free environment. It gets baked deeper and deeper into the system with time going forword. At work, for example, we run RHEL servers that just use systemd - no other options provided. As one of the admins I have to know systemd-related commands (systemctl, journalctl ...) and how to manage systemd units (i.e. services) or else I will be getting in trouble pretty quickly. So I think knowing systemd *IS* an important skill.

@CharlesV You know that my linux knowledge is very limited, so….

But from basic linux sites and such, I was under the impression that there is a slow trend to move away form systemd because it's so huge and complex, but maybe it's the "Der Baader Meinhof Komplex", or Baader-Meinhof Phenomenon/effect (frequency bias), although the former wasn't a horrible movie.
++EDIT- I guess my impression was incorrect - sorry. End Edit

And IIRC, MX does use the systemd-shim, and D.O. says use systemd if you want to, like for snaps, etc. - all basic statements of course.

Cheers!

It depends in part on what the systemd developers do.
Debian, our base, uses systemd by default and systemd library packages are dependencies for a lot of the system, so we need to include (a patched version of) systemd in our packages (just not allow it to control everything if we wish to run sysvinit instead).

Systemd-shim requires a few patches to systemd to allow it to run the libraries without systemd controlling the boot. If the systemd devs change things enough that those can't be updated to work we'll have a tough choice to make. But we won't know for some time yet what version of systemd the next debian stable release will use and whether or not we can maintain the status quo.

CharlesV wrote: Sat Jul 27, 2024 12:15 pm But what really hit me was it *does* seem like more and more distro's are moving to it... and so my real question ... (and yes, I DO realize this is a VERY loaded question :-) )

Should we be planning on a future of sytemd?

I sure hope not. DistoWatch maintains "not systemd" as a specific init option in their search so you can still find decent distributions. Even the vote for Debian to adopt systemd was contentious, shady, and unwelcome, and as I recall there are plans for restoring multiple inits in Debian as first-class citizens.

The DistroWatch list currently contains 96 entries, many of which are, or are based on, stable and mature codebases like Slackware and Gentoo. It also contains non-Linux projects like BSD- and Solaris-derived operating systems. In some cases, these OSes don't just not include systemd, they just plain old don't support it. In others, they can't run systemd and never will.

A bunch of these distros existed long before Lennart's blog post. And they will exist long after that blog post is taken down. There is a culture of UNIX that systemd is systematically attempting to bulldoze, and its attempts to rearchitect Linux into a monolithic Windows-like jumble of interdependencies is completely opposite to that culture. When you get so upset over "Do one thing and do it well" that you end up rewriting dozens of other subsystems -- poorly -- it becomes clear that it's no longer being done for any technical benefit. It's just a political power grab.

CharlesV wrote: Sat Jul 27, 2024 12:15 pmAnd then, attempting to live as I speak, I decided that I should learn more about it and give it more than a quick look. As I work with it more and more, I am kind of baffled by why people really like it. It seems to be moving / moved to a more 'monolithic OS approach' and away from the smaller, more precise control that I have always appreciated with Linux. (At least in my opinion, and my tinkering so far - I see what people are writing about when they say 'large'.)

I think systemd is OK as an init system, but not a great DNS resolver, session manager, NTP client, etc. I think the approach they are trying is to create a system layer for Linux that can adapt to modern hardware, but in doing so they have accidentally (or on purpose?) increased the scope well beyond that. Could be why their version numbering is beyond 255.

At least Linux wasn't stupid enough to adopt wonders such as svchost, rundll32 or the registry... yet!

Technical issues and what is behind the scenes aside, as a regular daily user of MX 23, how does this affect me?
I boot to sysvinit or systemd and I can detect no difference.

@richb So... the 'biggie' in my head is relearning how to work through issues. (I *still* consider myself a Linux noob and while I think some of my Linux tech is pretty good, some is still gaining ground, there is A LOT more that I still need to work on.)

Everyone else - thank you for your contribution here! I *think* DukeComposed is roughly where I am at in thought of this ( ie "I sure hope not")... but think the handwriting on the wall is closer to what Tim said and as such as reinforces my question. (At least in my head).

@CharlesV I have had very few issues. Perhaps because I stay within the MX repos and do not install "exotic" stuff. Browser, security camera application, texting, email, LibreOffice Suite ,Dolphin File manager, and the Mx Tools, standard stuff MX is a tool for me not an experimental platform.

richb wrote: Sat Jul 27, 2024 9:25 pm @CharlesV I have had very few issues. Perhaps because I stay within the MX repos and do not install "exotic" stuff. Browser, security camera application, texting, email, LibreOffice Suite ,Dolphin File manager, and the Mx Tools, standard stuff MX is a tool for me not an experimental platform.

And that definitely makes a big difference too. I have had a few oddities, but I push my machines pretty hard and while I tend to stay off problem software, I do bend things around a bit sometimes :()

It is *always* interesting to me what a 'standard users' machine is. Many people stay within a set of guidelines... but quite a few are just over that line and not really 'power users' ... just working it more.

@CharlesV
And that definitely makes a big difference too. I have had a few oddities, but I push my machines pretty hard and while I tend to stay off problem software, I do bend things around a bit sometimes :()

It is *always* interesting to me what a 'standard users' machine is. Many people stay within a set of guidelines... but quite a few are just over that line and not really 'power users' ... just working it more.

Very true. We see it on the Forum. New users need guidance even when staying with standard stuff. But many wander off the reservation and cause serious problems for themselves.

The problem with systemd is that we still have some stuff with the Live system that doesn't work well with systemd. If everything would work then there would be a good case that we'd have better support and compatibility if we were defaulting on systemd, I would still like to be able to offer an alternative for ideological people who would not touch systemd with a 10 foot pole.

Adrian wrote: Sat Jul 27, 2024 10:23 pm The problem with systemd is that we still have some stuff with the Live system that doesn't work well with systemd. If everything would work then there would be a good case that we'd have better support and compatibility if we were defaulting on systemd, I would still like to be able to offer an alternative for ideological people who would not touch systemd with a 10 foot pole.

But if the shim's are basically coming from Debian... will they continue ? I would think at some point they would just say enough and move to 100% systemD . .. and then what?

While I have systemd distros (Fedora, Manjaro, Solus) in my distro collection, I am all for choice and am very happy using sysV in MX (also in PCLinuxOS). Choice is why my collection has different desktop environments, package management systems and inits.

Since I am a normal user with no unusual usage requirements needed of my computer systems, using systemd if it's baked into a distro is not a problem. But I also like to look at the big picture.

I just don't want systemd to squeeze other inits out. Because if they do and we are left with only systemd, who knows what else will be made a hard dependency/requirement of systemd. Will we have to use their homed /home directory? their systemd bootloader?. Right now these are only optional functionality parts of systemd.

Just how safe is systemd to attacks when it is such a big program, and it wants to take over more and more tasks?

CharlesV wrote: Sat Jul 27, 2024 11:13 pm
But if the shim's are basically coming from Debian... will they continue ? I would think at some point they would just say enough and move to 100% systemD . .. and then what?

They haven't come from Debian for a long time. MX appointed a programmer to keep it patched and up-to-date with the latest systemd in Debian Stable. So we won't know what needs to be done for the shim in Debian Trixie until we know what version of systemd will land in the next Debian Stable.

@asqwerth AH.. thank you for all that excellent info!

DukeComposed wrote: Sat Jul 27, 2024 4:42 pm
....... and as I recall there are plans for restoring multiple inits in Debian as first-class citizens.

I think that any steps taken by Debian in that direction [if at all] might be focused on how one might replace systemd with another init, rather than allowing many inits to co-exist on the same installation and accessible from the boot menu.

One certain thing is need for systemd will not become less.. Right now for MX, all three of their supported DE's still work well with both inits (not without some intervention). I would be extremely (and pleasantly) surprised if KDE didn't tilt further toward requiring systemd like Gnome and some others now have...

The systemd will be more and more unavoidable, which also means that in the future AI by itself will run it, a small example which still needs humans: https://medium.com/@david.franko1998/au ... 0a143c31e5

One more data point:
As a fairly new convert to MX, I used Ubuntu since the Warty version (circa 1995, IIRC), still not a Linux maven I found that the switch to systemD left me in "a maze of twisty passages..."
The smallest problem in point A led to point B ,... C ... etc. There seems no way for a non-expert user to sufficiently master systemD.
I feel sure that if it is forced on us we (you) will see an exodus of all those satisfied to stay with their "noob" status.

Meanwhile, thanks for all the effort put into MX Linux, and for the excellent support provided in this forum.

Mike

asqwerth wrote: Sat Jul 27, 2024 11:52 pm I think that any steps taken by Debian in that direction [if at all] might be focused on how one might replace systemd with another init, rather than allowing many inits to co-exist on the same installation and accessible from the boot menu.

I don't think Debian has ever been big on managing a plurality of init systems. The vote I was thinking of occurred in 2019 and concluded with the decision "B: systemd but we support exploring alternatives".

And that in itself is a victory, since it means that Debian will not take such a hostile stance towards existing userbases as, say, Fedora. Personally I don't see a point in supporting several different concurrent init systems, as the feature sets always vary. Just make it so that a user isn't obligated to depend only on systemd. (Nothing ticks me off quite like the fanboys who insist that systemd isn't that bad and if you don't like something you can "just disable it". OK, bro. Now, if I just want my init system to just be an init system I need to go in and (a) turn off hardware device naming as a kernel argument in the bootloader, (b) switch off the DNS resolver, (c) fix the broken time synchronization issue, (d) move other core services over to a real process management utiilty because systemd also handles local and network daemons, et cetera, et cetera. Cool, bro. Now half of my new-PC-setup activities I run every time I build a new machine are turning off things I don't want and never asked for, and now my box is hamstringed because they pulled out all the perfectly functional tools that ran things normally before 2014. Cool. That is a cool and normal way to distribute a serious operating system.) The advantage to Debian taking this Option B path is that at a minimum they will acknowledge that other init systems exist and their OS should still be able to boot with what it's been given.

This means that Debian, in some small way, can still function outside of the narrow purview of how Lennart Poettering thinks you should run your box, even if you have to mix the malt and the yeast yourself at home. It's becoming increasingly common, expected even, that a distro will switch to systemd and watch everything start breaking, and as we've seen, the only way to keep systemd working on your distro is to keep adding more systemd. Not even Linus trusts it and that was back in 2017.

asqwerth wrote: Sat Jul 27, 2024 11:36 pmI just don't want systemd to squeeze other inits out. Because if they do and we are left with only systemd, who knows what else will be made a hard dependency/requirement of systemd. Will we have to use their homed /home directory? their systemd bootloader?. Right now these are only optional functionality parts of systemd.

In this case it's not so much whether or not a distro adopts it that's the problem, but what applications will be available that don't rely on it. As a dev I can appreciate why an application developer would go, screw this systemd is the popular one we'll only bother with this. There is more than enough fragmentation (under the guise of choice) for the fundamentals as is which is why it's difficult for applications to support Linux, and now they have to worry about the myriad number of ways in which to do basic things which should have a set standard, such as service management and, well, starting the bloody operating system.

So this isn't really as much as a debian thing as it is a matter of application compatibility, it's a shame the winner is a pile of scope-creep galore, but it goes to show that luck, support, marketing and working with others beats mere technical superiority. I have heard (but have not confirmed) that Debian may be working on a scheme to support multiple inits. In essence, while distros started it, the consensus of the loudest and most prominent of the Linux software ecosystem have forged this path.

asqwerth wrote: Sat Jul 27, 2024 11:36 pmJust how safe is systemd to attacks when it is such a big program, and it wants to take over more and more tasks?

There's enough stuffed into the kernel (for instance, kSMBd) that should make any security conscious person quit their job in a heartbeat and turn into a monk. I think systemd will either turn out to be the least of one's problems, or it will be equally as bad as the kernel's problems.

We're fans of solid simple MX.
MX way is not same as Ubuntu way... At the very least, I think SysVinit default is a must.
(above saying as a MX User)

Right Freja ... The Unix/Linux philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Expect the output of every program to become the input to another, as yet unknown, program.

oops wrote: Sun Jul 28, 2024 7:16 am Right Freja ... The Unix/Linux philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Expect the output of every program to become the input to another, as yet unknown, program.

Lest we forget, Doug McIlroy is the UNIX co-founder no one remembers, and the one who encouraged Ritchie, Thompson, and Kernighan to implement pipes.

In 1986 Jon Bentley asked Don Knuth -- yes, that Don Knuth -- to solve a problem about taking arbitrary text input and output a word frequency count. Knuth wrote a custom program in a custom programming system he called WEB, using a custom data structure. Doug McIlroy complimented the sophistication of his approach, pointed out its flaws, and then solved the same problem in a short and sweet UNIX one-liner. Keep in mind that the only reason McIlroy's solution calls "sed" is because the "head" utility hadn't been written yet.

EDIT: typo

I'm curious about how antiX is able to be completely free of systemd (without any need for "shim"). Adding a desktop environment adds elogind, which I think is a component of systemd, but on my SalixOS machine (Slackware-based) I can use Xfce without any of the shims, elogind, or other work-arounds.

I'm not knowledgeable enough about any of this to know how or why one distro compared to another is able to get around the systemd issue completely or partially. But I trust the developers to know what's important and how to implement it.

The only way I know to completely avoid systemd - I think - is to get away from the Debian base and use one that doesn't "compromise" by adding bits and pieces of systemd to accomplish the goal of a fantastic OS like MX. Could it be that the future of systemd-free OSes is a Slackware base or a Devuan base? Does PCLinuxOS have these "bits and pieces" of systemd as well?

Both Slackware and Devuan use elogind, while PCLOS uses consolekit.
elogind is systemd without systemd being the init system.

It's not just about systemd or even elogind.
Debian's version of udev is packaged to include dependency on components of either systemd or elogind (ie libsystemd0 or libelogind0) so it is impossible to be systemd/elogind-free using pure Debian.

As for MX, the devs have said that in the worse case scenario, they will build separate isos - one with systemd and the other with sysVinit.
From what I understand, MX devs are not interested in supporting other init systems.

AK-47 wrote: Sun Jul 28, 2024 5:10 am As a dev I can appreciate why an application developer would go, screw this systemd is the popular one we'll only bother with this. There is more than enough fragmentation (under the guise of choice) for the fundamentals as is which is why it's difficult for applications to support Linux, and now they have to worry about the myriad number of ways in which to do basic things which should have a set standard, such as service management and, well, starting the bloody operating system.

This is an extremely good point and the core of a lot of issues in Linux, an inconvenient truth for sure...

AVLinux wrote: Sun Jul 28, 2024 11:31 am

AK-47 wrote: Sun Jul 28, 2024 5:10 am As a dev I can appreciate why an application developer would go, screw this systemd is the popular one we'll only bother with this. There is more than enough fragmentation (under the guise of choice) for the fundamentals as is which is why it's difficult for applications to support Linux, and now they have to worry about the myriad number of ways in which to do basic things which should have a set standard, such as service management and, well, starting the bloody operating system.

This is an extremely good point and the core of a lot of issues in Linux, an inconvenient truth for sure...

I disagree with this point.
The vast majority of software is init agnostic - it simply does not care what init is running.
The problem is that Debian packagers add systemd/libsystemd0 as a hard dependency even if the app does not require it at all

anticapitalista wrote: Sun Jul 28, 2024 12:17 pm I disagree with this point.
The vast majority of software is init agnostic - it simply does not care what init is running.
The problem is that Debian packagers add systemd/libsystemd0 as a hard dependency even if the app does not require it at all

Since you are one of last Mohicans that fight the beast, what other alternatives are away of Debian which could be user-friendly?

anticapitalista wrote: Sun Jul 28, 2024 12:17 pm... Debian packagers add systemd/libsystemd0 as a hard dependency even if the app does not require it at all

asinoro wrote: Sun Jul 28, 2024 12:32 pm

anticapitalista wrote: Sun Jul 28, 2024 12:17 pm I disagree with this point.
The vast majority of software is init agnostic - it simply does not care what init is running.
The problem is that Debian packagers add systemd/libsystemd0 as a hard dependency even if the app does not require it at all

Since you are one of last Mohicans that fight the beast, what other alternatives are away of Debian which could be user-friendly?

MX has never claimed to be free of systemd so as long as their sytemd-shim keeps on working, there is no issue at all and MX-24/25 won't be any different under the hood as present or previous versions. ie it offers sysVinit and systemd boot on one iso.

FWIW I doubt wayland will work very well without systemd by the time wayland is pervasive. Personally I already am finding a number of linux components aging out (pretty much like me). I have moved to using systemd and find it actually seems to be more stable on Debian (given the stuff I use). But keep in mind, nothing moves very fast in the Debian world. But Linux will eventually move from x11 to wayland and when it does things will be different (not to be confused with better or with worse either for that matter).

@manyroads ... Linux will probably move from x11 to wayland (and a lot of DE and WMs) , but an other init system will not be, and must not be, an obstacle.

oops wrote: Sun Jul 28, 2024 2:59 pm @manyroads ... Linux will probably move from x11 to wayland (and a lot of DE and WMs) , but an other init system will not be, and must not be, an obstacle.

I guarantee you it is and will be a pain. It already is. I gathered some info that may help get you started in solving the situation for yourself...

Wayland Items to follow

If you use these DEs here is where they are headed:
-- KDE Plasma 6: Wayland by Default: https://news.itsfoss.com/kde-plasma-6-dev/
-- Xfce 4.20 Aiming For Usable Wayland Support While Maintaining X11 Compatibility: https://www.phoronix.com/news/Xfce-4.20-Wayland-Roadmap
-- Gnome Wayand is used by default in Debian 10: https://wiki.debian.org/Wayland

Does Wayland require systemd?
-- Here's a response/ discussion from the BSD world. https://forums.freebsd.org/threads/kde- ... emd.77776/
-- You may use internet search and find more, what I have gathered from reading discussions is that there are ways to make wayland work on other inits such as OpenRC but that they are not always trivial or stable.

manyroads wrote: Sun Jul 28, 2024 2:43 pm FWIW I doubt wayland will work very well without systemd by the time wayland is pervasive.

Wayland is a protocol and essentially an IPC specification for a very specific use case (graphics, display and window management), so it doesn't have anything to do with systemd. That is like saying, Gopher won't work very well without Solaris.
There are a several compositors such as Wayfire and Labwc that have nothing to do with systemd.

manyroads wrote: Sun Jul 28, 2024 3:18 pmI guarantee you it is and will be a pain. It already is.

That depends on your device. In my case, switching KDE to the Wayland session solved a lot of problems, such as input lag, screen tearing and high CPU usage. So Wayland has the potential to solve a lot of issues that X11 has, but it's up to the compositors.

AK-47 wrote: Sun Jul 28, 2024 4:45 pm There are a several compositors such as Wayfire and Labwc that have nothing to do with systemd.
I was unclear above. What I was referring to is that there are many tools that run on DEs and wms that will not have x11 equivalents on Wayland and those that do offer Wayland support will those which work and require systemd. Things like conky have a history of exhibiting problems (though they are now largely fixed, at least when I last used conky on Wayland.

As for Labwc and Wayfire, they are both very tough to use. I found them rough and low in functionality (again last I used them).

manyroads wrote: Sun Jul 28, 2024 3:18 pmI guarantee you it is and will be a pain. It already is.

That depends on your device. In my case, switching KDE to the Wayland session solved a lot of problems, such as input lag, screen tearing and high CPU usage. So Wayland has the potential to solve a lot of issues that X11 has, but it's up to the compositors.

Yes KDE is going to work just fine, they have a lot of resources devoted to the transition.

AK-47 wrote: Sun Jul 28, 2024 4:45 pm That depends on your device. In my case, switching KDE to the Wayland session solved a lot of problems, such as input lag, screen tearing and high CPU usage. So Wayland has the potential to solve a lot of issues that X11 has, but it's up to the compositors.

Kwin has a history of lag and CPU utilization on X.org, which can often be seen on low-end hardware. I haven't noticed the same thing with other window managers on X.org. X.org even worked well back when computers were single core. Screen tearing might be related to X.org, but I haven't really seen that either. From a gaming/framerate perspective it depends on game, driver and compositor, but generally I believe X.org and Wayland are comparable in performance at least when I looked at phoronix.com last time. No doubt Wayland is the future for desktop Linux since this is what is being worked on.

The Wayland discussion is similar to the systemd discussion. One may like one or the other. Ultimately, the "industry" (X.org, Red Hat, Valve etc.) decided that systemd and Wayland are the future. This is probably how it will turn out in the long run for mainstream desktop Linux.

I like SysVinit and X.org, but they are becoming more niche. I also think KDE is the future, while smaller desktops might disappear or become more niche. In the end it's manpower that decides and every deviation from "mainstream" has a cost associated with it. From a casual user (application user) perspective the underlying tech doesn't matter that much.

On the other hand the vast scope of MX Linux (live/installed, SysVinit/systemd, multiple DEs and now X.org/Wayland) might have been what brought MX Linux to Distrowatch number 1 and kept it there.

I see systemd as dependency hell in the init world. One service automatically starts another etc. However, if the MX live system can be brought to systemd I personally don't think SysVinit is that important. On the other hand SysVinit was the core reason I started using MX Linux (systemd didn't give me a good feeling). Systemd works well on MX Linux and I could switch to it without much thought.

Since I see myself as something in-between a casual user (application user) and a tinkerer I don't really know what foot to stand on. For tinkerers SysVinit might be crucial, otherwise soul is lost so to speak. These days I mostly see desktop Linux as an application platform.

Things like Wayland (compositors), desktop environments (KDE, Gnome, Enlightenment etc.), Pipewire and Flatpaks could tip the scales in favor of systemd. If you don't need "big software" then several systemd-free options exist.

@dreamer ... SysVinit versus Systemd , and X.org versus Wayland , are two separate and independent things. (Wayland is more secure for the fishing than Xorg)

One of the reasons for choosing of MX Linux was its use of SysVInit. Nothing against systemd. However systemd has some very valid concerns raised against its use. As far as moving to systemd, it will become inevitable by the time this decade is up. For example it is almost impossible for GNOME to work without systemd. Even KDE has certain applications, like KDE System Monitor, which do not work fully with SysVInit. This will increase as we go ahead.

Additionally even systemd documentation says that it will stop supporting SysVInit scripts somewhere down the future.

Debian might have had other init systems and support for them in the past, but it is no longer the case. And it will no longer be supported in the future. Most of the significant financial support for Debian comes from people running Debian on servers. These guys would prefer systemd and not SysVInit. Also we should not overlook the power of conformity. For maintainers, having systemd controlling the bootup and services means having less of scripts to be maintained and tested per release. That is a very powerfull pull for distros. Do not underestimate it.

Like the wise Borg said, it is futile to resist. All will be assimilated.

LinuxSpring1 wrote: Wed Jul 31, 2024 7:55 am As far as moving to systemd, it will become inevitable by the time this decade is up.

What a sad and defeatist attitude to have about the future.

DukeComposed wrote: Wed Jul 31, 2024 8:40 am

LinuxSpring1 wrote: Wed Jul 31, 2024 7:55 am As far as moving to systemd, it will become inevitable by the time this decade is up.

What a sad and defeatist attitude to have about the future.

lol ...This defeatist resigned news is not from LinuxSpring1 but from LinuxWinter1 ;-)

Sad yes. Defeatist No. Maybe realistic is the word.

LinuxSpring1 wrote: Thu Aug 01, 2024 1:46 am Sad yes. Defeatist No. Maybe realistic is the word.

I am suggesting that when reading this article (link) https://distrowatch.com/weekly.php?issue=20240617#qa , that where it reads wayland replace that with systemd, then say no that won't happen unless systemd falls flat on itself then yeah systemd could very likely happen, does that seem realistic that it could happen, I tend to think it could, sad oh definitely it's yes, defeatist no the support we give now to non systemd Linux distros will encourage more developers and creatives to the Tux-side just because systemd have the excess $$$ to push the agenda to better suit Windows who all of a sudden really likes Linux, bit suss.

Maybe it will take that the non-sysd distros work together as a collective of communities to develop software.

Don't know where it's all going be assured thou it will be interesting, minorities always find a way.

artytux wrote: Thu Aug 01, 2024 7:14 am just because systemd have the excess $$$ to push the agenda to better suit Windows who all of a sudden really likes Linux, bit suss.

You realize who pays Lennart Poettering's salary, right?

DukeComposed wrote: Thu Aug 01, 2024 7:40 am

artytux wrote: Thu Aug 01, 2024 7:14 am just because systemd have the excess $$$ to push the agenda to better suit Windows who all of a sudden really likes Linux, bit suss.

You realize who pays Lennart Poettering's salary, right?

I knew the of the name Lennart Poettering and systemd together but never went in-depth about him the who what etc etc just had a quick read about him now, ugh , seems I'm good at keeping my feet warm out in the cow paddock.

The ship has sailed as far as replacement to SysVInit and SystemD is concerned. It is not going to happen. Many of us, myself included, are clinging to the past, i.e. SysVInit. Maybe out of nostalgia. Maybe out of an obstinate urge against change. And yeah I agree that SystemD has ended up making Linux more like Windows. The issue has been that SystemD might follow the Microsoft policy to embrace and extinguish. No offense to Windows, it does what it does pretty decently. If there has to be an alternative to SystemD, like RunIt, OpenRC, S6, etc. then it will have to compete to ability and features.

The pull of conformity cannot be denied. Debian adopted SystemD because of conformity. Debian went for /usr merge, championed by SystemD, because of conformity. And MX Linux is based on Debian.

LinuxSpring1 wrote: Fri Aug 02, 2024 2:35 am If there has to be an alternative to SystemD, like RunIt, OpenRC, S6, etc. then it will have to compete to ability and features.

The pull of conformity cannot be denied. Debian adopted SystemD because of conformity.

Debian adopted systemd because of a fairly shady and contentious vote by its technical committee.There are plenty of other Linux distros that do not support systemd and have no intention of migrating. Every Solaris-based and BSD operating system does not run systemd and has no ability to port it.

One could even say that to compete with systemd, the advantage lies in not matching its features. The UNIX space existed and thrived for 40 years before Lennart's blog post. It's gonna be just fine. No question that damage has been done and Lennart's harm continues to accrue, but UNIX as a concept and as an implementation is going to survive this, too.

I wonder if MX will have to switch from a Debian base to something else (Devuan, Slackware, BSD) or become like antiX but necessarily include elogind and stuff. For now the shim works, but perhaps not in the long run.

@Artim Actually, I created Devuan based "Storyboard" test edition in the few month ago,
But couldn't porting MX tools (especially MX installer) by my technical ability, That project aborted.

Devuan base MX? I think that's great idea!

Except MX tool porting, "Devuan based Storyboard" is can have a great (similar to MX) experience,
I feel little better performance than MX based storyboard.

But Devuan is built-in SLIM instaed LightDM, and of course have some differences,
A long development time is required to absorb the each differences.

Is it even possible? Devuan base MX? If Mint can have LMDE then maybe, just maybe MX can have Devuan based distro too.

Very simply summary says, It's SELECT of "Common people oriented OS (systemd line)" OR "Expert and Computer Fans oriented OS (none-systemd line)".
Maybe it's time to select direction by Dev team?
More simple says, Generality or Quality? Need user voting?

I guess I am a common person as I generally use systemd

Or, How much do we cherish neatness at MX.

That is probably "neatness priority's problem" I think.

I think it is more a "what do the main devs want to do, and we'll all just have to follow" thing

Ah, That's true.

I think that we need to remember that planning and implementing are two different things. We already have SystemD as a fall back and I see no reason to change this approach.

"We will cross that bridge when we get there"

As long as all programs work with SysV and the systemd-shim patches are possible and in working order, no need to change anything. It's way (like in years) too early go get as specific as a user poll.

I think we are all tempted to not only be careful and skeptical of new ideas but also we often ascribe either ill intent or a lack or reasoning to the people behind those ideas and often we make emotional judgements without (a) knowing what their intent actually is and (b) not being able to comprehend what the technical details are. In my own recent experience in working with and deploying the Enlightenment Desktop Environment I could get extremely annoyed about what I perceived to be illogical decisions but when I went to ask (or complain) to the actual developer on his IRC channel I have often felt quite foolish as he has painstakingly explained how his design intentions were not only logical but necessary to work properly and efficiently and were simply him doing the best he knows how in keeping with a completely rational larger design philosophy, no ill intent, plenty of intelligence and even the patience to explain to an uniformed User. At the end of the day Poettering and these people are making decisions based on how best to achieve the personal goals they have and to best solve the current bug or problem that they are tasked with untangling at any given moment and hopefully preventing from happening again. Perhaps these moment by moment decisions unfold in a better direction and perhaps they simply unfold in yet another way of doing the same thing, in Linux we don't have a top-level Project Manager to separate the wheat from the chaff so to speak so when you use Linux you are kind of signing up for the benefits and deficits of anarchy simply by the unrestrained nature of it's development. There doesn't have to be ill intent involved at all for this to be occasionally frustrating but at least I try now to take a breath and give the designer/developer the benefit of the doubt for simply problem solving the best they know how with skills that I'm not qualified to question or judge..

@AVLinux So well said!!

Back in 1995 I was working in a software company where the raging debate was " Heavy Design vs Nimble Coding " and as we were a windows shop, with MANY processes moving over to linux to do 'stuff that couldnt be done' in windows... it was VERY interesting to watch the entire dev crew twist around that one!

It has been VERY interesting to read and and see this topics posts! I love the community here, varied, intelligent, some very good concepts and some very good points!

@AVLinux There are several init systems around that have been recently developed to try and move on from the weaknesses of sysVinit (which was almost 100% universal on all linux). Why do they not get any 'press coverage' let alone corporate backing?

anticapitalista wrote: Mon Aug 05, 2024 3:49 pm @AVLinux There are several init systems around that have been recently developed to try and move on from the weaknesses of sysVinit (which was almost 100% universal on all linux). Why do they not get any 'press coverage' let alone corporate backing?

For best practice. A hegemonic solution is never a good solution. It is an empirical rule. especially at a low level that centralizes everything.

anticapitalista wrote: Mon Aug 05, 2024 3:49 pm @AVLinux There are several init systems around that have been recently developed to try and move on from the weaknesses of sysVinit (which was almost 100% universal on all linux). Why do they not get any 'press coverage' let alone corporate backing?

Hi @anticapitalista ,

I'm getting the feeling that I may be getting on your nerves in your responses to me earlier in this thread and currently... Nothing I've said is intended to convey that systemd is superior in any way or that I'm a particular fan of it over anything else. Yes, I need it to support Enlightenment and to be fair I also have nothing against it but my post above is was after observing and getting drawn in to some more or less "tribal" types of comments I remembered I should try to be neutral about it (until better informed of it and the other init systems) because I don't personally have direct insight or knowledge as to the intentions of the developer nor do I have full understanding of it's technical details (I would assume that you do..). To clarify earlier on when I agreed with @AK-47 that "There is more than enough fragmentation (under the guise of choice)" I was agreeing that this is an undesirable reality of competitive ideas without a clear mediator, that comment had absolutely nothing to do with inits directly, it was simply agreement of his assertion that we indeed often have fragmentation under the guise of choice, I don't know how anybody who has used Linux for more than a few weeks hasn't bumped into that reality, it's baked into the cake and yet most of us love it anyway..

As far as getting coverage, it's a rhetorical question, yes many things of true merit are suppressed by those in power, I'm looking southward (as an observer) at an election with 3 candidates yet one of them is completely not covered by the mainstream media sources so I fully get what you're saying. I'm also certainly not saying the promotion of systemd is all for altruistic reasons, I don't know, and if I don't know I shouldn't pile up on one team or the other and I feel casting uninformed judgements about what we are actually talking about isn't doing the conversation any good whether it's myself or anyone else..

AVLinux wrote: Mon Aug 05, 2024 2:53 pm At the end of the day Poettering and these people are making decisions based on how best to achieve the personal goals they have and to best solve the current bug or problem that they are tasked with untangling at any given moment and hopefully preventing from happening again. Perhaps these moment by moment decisions unfold in a better direction and perhaps they simply unfold in yet another way of doing the same thing, in Linux we don't have a top-level Project Manager to separate the wheat from the chaff so to speak so when you use Linux you are kind of signing up for the benefits and deficits of anarchy simply by the unrestrained nature of it's development. There doesn't have to be ill intent involved at all for this to be occasionally frustrating but at least I try now to take a breath and give the designer/developer the benefit of the doubt for simply problem solving the best they know how with skills that I'm not qualified to question or judge..

The issue/concerns with Poettering and SystemD have been borne out by the actions and directions taken since then. SystemD was meant to solve the following three problems
1) Dependencies during services/daemon startup
2) Parallel start of services leading to faster boot time
3) Tracking of services crashes and restarting them.
The issue was that the approach taken was very similar to what Windows does and did not adhere to the Unix/Linux philosophy of excelling in doing one thing and one thing alone. In Software architecture there is a concept of separation of concern. In simple terms it means do the thing that you are meant to do and do not step on someone else toes. Since then SystemD has morphed into something else entirely
1) Jornaling of events, aka similar to Windows Event Manager
2) User Login and Session login
3) /usr merge where the solution was said that certain Unix OS have done it so should be done by Linux too and dubious benefits were laid out for its need
4) Creating unnecessary dependencies where none needed to be exist. GNOME, udev, etc. The list keeps on growing
5) Creating an alternative of SUDO
6) etc, etc. etc. The list goes on and on

What Poettering and his supporters have managed to achieve is a level of unparalleled homogeneity in the Linux ecosystem which had thrived on diversity. And that too for little benefit. Ask any genetics expert he will tell you the benefits of diversity and perils of lack of genetic diversity among a species. Ask any political science student and they will tell you the healthy need for variety in approach and implementation. Ask any biologist which forest is more strong and resilient, one which has a single type of vegetation or which has numerous different types and species of vegetation.

The issue with SystemD is that in its guise it is converting everything in Linux similar to a single distro, RedHat and bringing it way close to Windows. I am against things being forced down just because it has to be done a certain way. And especially when the decision to go with SystemD was taken in a vote which till date is contested.

Disclaimer: I have nothing against SystemD. Or using it. Or against Windows. Nor do I have them being used. Nor do I have against the corporate backing of SystemD.

AVLinux wrote: Mon Aug 05, 2024 2:53 pm in Linux we don't have a top-level Project Manager to separate the wheat from the chaff so to speak so when you use Linux you are kind of signing up for the benefits and deficits of anarchy simply by the unrestrained nature of it's development.

That's not true. We have a top-level project manager in Linux and his name is Linus. It's his project. It's his kernel. If Linus decides your code doesn't belong in his kernel, it doesn't go in. If he decides he doesn't like your code being in his kernel, it comes out. systemd, largely, does not modify the Linux kernel purely because Linus won't let it. This means that systemd is relegated to living above the kernel level, where it is actively consuming everything it can. You're free to build Linux without a dependency on systemd. The kernel source code is free. Even the major distros like Fedora and Debian offer their codebases for free so you can remove systemd from it as some distros have done, or fork the code from a point in the project's history before systemd began to metastasize. Linux is not, precisely, an anarchy as there is no clear indication of self-rule. Power in the Linux ecosystem exists among Linus, who acts as a largely aloof philosopher king, and a Landsraad of fiefdoms who act as the great houses of muscle in the realm making the real decisions that affect their users every day. There's no way for Linus to kill off a major project like, oh, say, CentOS, so the other major corporations more or less prey on each other like junior high school bullies looking for attacks of opportunity as well as popularity and acceptance. The tech world these days is less about killing companies like it was in the 1980s and 1990s and more about killing off specific ideas. Remember Mir? Remember Upstart?

LinuxSpring1 wrote: Tue Aug 06, 2024 1:22 am The issue/concerns with Poettering and SystemD have been borne out by the actions and directions taken since then. SystemD was meant to solve the following three problems

systemd was borne out of one problem to solve: Poettering's dissatisfaction with init. As is his standard modus operandi, he disliked the previous software's design, half-baked his own solution, and then turned it loose upon the world and called it good. He's repeatedly done this with zeroconf (Avahi) and audio (PulseAudio), to name a few. He is a programmer of moderate skill who is young and brash and gravely misjudged the complexity of system service management and is now trying to code his way out of an intractable problem. There is no logical path you can take to start with "startup should be faster" and end up at "I re-wrote sudo" with a detour through "I also wrote a DNS resolver from scratch and my own version of cp". He is clearly in over his head and chose a long time ago to just keep going. Gotta admire his chutzpah.

LinuxSpring1 wrote: Tue Aug 06, 2024 1:22 am The issue with SystemD is that in its guise it is converting everything in Linux similar to a single distro

Poettering pivoted long ago to calling systemd his attempt at providing Linux standardization. And wanting consistency among distros is a laudable goal, but only if the code that provides it is sane, safe, and doesn't have 2.2 thousand open issues on GitHub and produce about a dozen full-blown CVEs a year. Poettering built a new DNS resolver. It's buggy and insecure. He decided on a new binary logging format. It's buggy and insecure. He built a user management infrastructure that gives UIDs root privileges if the username starts with a digit. He wrote a replacement for sudo. It's buggy. And insecure.

What do you gain from systemd? A slightly faster startup (sometimes), your machine will hang trying to shut something down (sometimes), you can't grep or tail -F anything in /var/log anymore, time synchronization problems, and you can start services with a bespoke unit file if you know how to format one. This last one is oddly similar to how daemontools works, only daemontools just needs a shell script. A lot of the daemontools approach was reimplemented, poorly, in systemd. A better replacement would be something like s6, which can also run as PID 1 if you really, really want it to be. The advantage of s6 over systemd is that it's (a) far less buggy and (b) if you use it you never have to deal with Lennart Poettering.

systemd isn't just "converting everything in Linux". It's actively making Linux a less stable, less secure platform and as an unapologetically crass power grab by a spoiled brat who thinks that calling his releases "Now with 42% less UNIX philosophy!" is a huge slam dunk.

DukeComposed wrote: Tue Aug 06, 2024 3:30 am

AVLinux wrote: Mon Aug 05, 2024 2:53 pm in Linux we don't have a top-level Project Manager to separate the wheat from the chaff so to speak so when you use Linux you are kind of signing up for the benefits and deficits of anarchy simply by the unrestrained nature of it's development.

...
Power in the Linux ecosystem exists among Linus, who acts as a largely aloof philosopher king, and a Landsraad of fiefdoms who act as the great houses of muscle in the realm making the real decisions that affect their users every day.

Landsraad ??? Are you a fan of Dune or Dune messiah or Children of Dune? So does that make Linus equivalent to Shaddam Corrino IV?

About the comment on S6. From what I have read S6 had two processes. PID1 and PID2. PID 1 was responsible for starting PID 2. Thats all. Nothing more. Most of the grunt work was done by PID 2. And that is what was questionable. Why have this hierarchy of processes? If unnecessary complicates things. Typically in Unix/Linux world the purpose of PID 1 is to start the system and services. Thats it. Nothing more. Once that is done, it simply goes to sleep or gets out of the way.

LinuxSpring1 wrote: Tue Aug 06, 2024 3:51 am From what I have read S6 had two processes. PID1 and PID2. PID 1 was responsible for starting PID 2. Thats all. Nothing more.

What you're thinking of is s6-supervise, which is what does the monitoring of a process to make sure that it starts if it can and restarts it if it stops without permission. s6 is a complete process supervision framework. It maintains a service tree, starts and stops those services, monitors them, restarts them if they die, handles signals, and writes, rotates and filters log files. It does not insist on replacing /etc/resolv.conf or sudo or mount.

LinuxSpring1 wrote: Tue Aug 06, 2024 3:51 am
Landsraad ??? Are you a fan of Dune or Dune messiah or Children of Dune? So does that make Linus equivalent to Shaddam Corrino IV?

Ah.. so fun to see the Dutch language put to use

anticapitalista wrote: Mon Aug 05, 2024 3:49 pm @AVLinux There are several init systems around that have been recently developed to try and move on from the weaknesses of sysVinit (which was almost 100% universal on all linux). Why do they not get any 'press coverage' let alone corporate backing?

Unfortunately people who develop good solutions to real problems don't always get this backing because they fail to seek out and convince people to be invested in it. This isn't because these engineers are flawed in any way, but those who scream the loudest are the most likely to be noticed, even if they are mad. It is for similar reasons, DOS and early Windows got by despite superior operating systems (such as OS/2 or MacOS) existing at the time. Poor OS/2 barely made a dent in Windows' market share. Same with Intel and their take on ECC RAM, which Linus Torvalds even had a go at them for.

Eadwine Rose wrote: Tue Aug 06, 2024 5:34 am

LinuxSpring1 wrote: Tue Aug 06, 2024 3:51 am
Landsraad ??? Are you a fan of Dune or Dune messiah or Children of Dune? So does that make Linus equivalent to Shaddam Corrino IV?

Ah.. so fun to see the Dutch language put to use

Dutch language? wdym?

Land(s)raad is a Dutch word.

"One Ring to Rule them All" is what systemd looks like from us non-technical ordinary users, and "standardization" is probably seen as a good thing by uninformed non-techy types as well, confused by the sheer number of Linux distributions, desktops, package managers, and other options.

I think the choices are wonderful, and that full "standardization" would be a great loss to Linuxland. That's why I resist systemd and why I hope that if Linux does become "standardized" to that degree, that BSD will be more desktop-ready by then.

I too resist systemd , though the original Idea to Update boot software was a good one It's became an invasive program that wants to control every part of the system. I too believe one of the great benefits of linux is choice. So There are other boot systems that could be adopted when system V is no longer viable. Not to mention systemd will become a security risk at some point. Jesse Smith of Distrowatch wrote a good article a few weeks back comparing the different init options.
found here https://distrowatch.com/weekly.php?issue=20240527#qa

Artim wrote: Wed Aug 07, 2024 6:02 am"One Ring to Rule them All" is what systemd looks like from us non-technical ordinary users, and "standardization" is probably seen as a good thing by uninformed non-techy types as well, confused by the sheer number of Linux distributions, desktops, package managers, and other options.

I think the choices are wonderful, and that full "standardization" would be a great loss to Linuxland. That's why I resist systemd and why I hope that if Linux does become "standardized" to that degree, that BSD will be more desktop-ready by then.

Well, I've always thought of myself as an informed techy guy and I think standardisation is (mostly) a good thing. No standards, no TCP/IP. No USB. No WiFi. No Linux kernel. Heck, no APIs at all: every API, whether a small web API or a huge OS API, like Win32 or indeed the Linux kernel , is an attempt at standardising access.

The problem is not standardisation. The problem is simply bad/sloppy engineering, both in the design and the implementation phases.

thomasl wrote: Wed Aug 07, 2024 9:23 am ...
Well, I've always thought of myself as an informed techy guy and I think standardisation is (mostly) a good thing. No standards, no TCP/IP. No USB. No WiFi. No Linux kernel. Heck, no APIs at all: every API, whether a small web API or a huge OS API, like Win32 or indeed the Linux kernel , is an attempt at standardising access.

The problem is not standardisation. The problem is simply bad/sloppy engineering, both in the design and the implementation phases.

We should not confuse protocol standardization with application standardization ... for protocols it is relevant (speaking the same language, TCP, etc...), for low-level applications it is a monopoly in the long term leading to a lack of diversity (a lack of resilience and/or simplicity). So it is also a problem of standardisation (even for the kernel).

oops wrote: Wed Aug 07, 2024 11:55 am... for low-level applications it is a monopoly in the long term leading to a lack of diversity (a lack of resilience and/or simplicity)...

Eh? The Linux kernel is the best example that this is not necessarily the case. The kernel (or rather Linus) has put standardisation on a pedestal when he said "We do not break user-space". The API is fixed and any not backward-compatible change in user space is an automatic bug. And yet... I can't see any evidence of this "leading to a lack of diversity"... actually quite the opposite. Not least because IMO the more stable an API behaves the more people will be tempted to use it.

In fact, an API in itself is not much more than an (often very complex) protocol specification. One could easily (big understatement here) re-implement the kernel in 100% Rust or 100% <insert favourite language> without any user space apps seeing a change.

oops wrote: Wed Aug 07, 2024 11:55 am We should not confuse protocol standardization with application standardization ... for protocols it is relevant (speaking the same language, TCP, etc...), for low-level applications it is a monopoly

It's not unheard of for someone to claim the tool is the standard. ISC BIND touted itself for the longest time as the de facto "reference implementation" for the DNS specification and effectively tried to steamroll people online by telling folks that whatever BIND did to implement a feature was how that feature was meant to be interpreted universally. The innumerable bugs in the designs of BIND 4 and BIND 8 that required yet another rewrite later on as BIND 9 didn't seem to change their argument.

DukeComposed wrote: Wed Aug 07, 2024 12:29 pm ...
It's not unheard of for someone to claim the tool is the standard. ISC BIND touted itself for the longest time as the de facto "reference implementation" for the DNS specification and effectively tried to steamroll people online by telling folks that whatever BIND did to implement a feature was how that feature was meant to be interpreted universally. The innumerable bugs in the designs of BIND 4 and BIND 8 that required yet another rewrite later on as BIND 9 didn't seem to change their argument.

Yes, it is bluff and the Coué method... an attempt at tactical self-fulfilling phophesis. ;-)

thomasl wrote: Wed Aug 07, 2024 12:23 pm Eh? The Linux kernel is the best example that this is not necessarily the case. The kernel (or rather Linus) has put standardisation on a pedestal when he said "We do not break user-space"....

In this case it is not the same thing, it is its own standardization (for its own project) ... but like a kernel it is very very complicated and big in lines of code, there is no competition or diversity, it has a quasi monopoly that many want to get into to act from the inside and change or influence the course of its governance.

oops wrote: Wed Aug 07, 2024 12:40 pm

Yes, it is bluff and the Coué method... an attempt at tactical self-fulfilling phophesis. ;-)
[/quote]
Theological discussions are frowned upon in the forum.

@MXRobo ... Not here theological but tactical.

I think funnily enough one of the big problems with SysVInit is simply general accessibility for the standard IT user. I've used systemd's systemctl in both home user and web server contexts, and I gotta say, man... It's pretty damn convenient and self-explanatory. "systemctl status", "systemctl start", "systemctl stop", and boom. You can now manage all services on a basic level on the system with just those three commands. With SysVInit, maybe I'm just being dumb here, but I don't think SysVInit has any equivalent to systemctl, or if it does, not one that is as accessible to us IT normies. Or maybe it's simply a documentation/learning issue. I dunno, but when I try to read up on SysVInit, I quickly start getting confused. Now don't get me wrong. I'm sure I could understand it if I tried, but as an end user, I don't quite understand why I should invest the time if I'm not a developer at all.

service --status-all
service service_name {start|stop|reload|restart|force-reload|status}

and with the AMAZING MX Service Manager ... is wonderful !

not *everything * happens in service ( same as systemd ) ... but its close. and if you have to ... you can drop it into one of the proper init.d folders and away you go :-)

As just an end user and not an IT person, I have used SystemD distros. About the only thing I liked about systemd was with CLI statement " systemd-analyze blame " was to find out what services were bogging down my PC on bootup. I could then stop those services to get quicker boot up times. other than that, I do prefer to run Linux with sysVinit.

So in your mindset, your original Q
@CharlesV
Should we be planning on a future of sytemd?

I know that the years can move on so quickly and what we thought was a long way off now is staring back at us because tomorrow/next week is that moment years into the future and going back to the original Q that took my interest what do you reckon ? of all these things.

In the short time I've used Linux I know it was/is the best thing I ever did moving to, I know from using systemd it has many tools for a user, I know that I would like to see in the far future a non systemd option still available because meh dunno this all too many eggs in the one basket and it seems to drift away from the easy going, do one thing and just Be ! Linux . Naive yeah.

In the rapidly evolving times we live in, which init will prevail depends on how compatible it will be with artificial intelligence, because artificial intelligence will be the one that will manage and maintain operating systems in the future!

AI well it isn't all terrible an article in FOSS Force

https://fossforce.com/2024/08/ibm-repor ... -the-bill/

Arnox wrote: Wed Aug 07, 2024 6:28 pm I've used systemd's systemctl in both home user and web server contexts, and I gotta say, man... It's pretty damn convenient and self-explanatory.

This isn't true. systemd is most certainly not explanatory and, in fact, it considers abstracting away its functionality from users to be a feature. Convenient? Perhaps, but it's not helping you learn or grow or making you better equipped to run your system. Convenient is dangerous.

We've already had forum posts complaining about a systemctl command failing in a sysvinit environment and what really scares me is the sentiment that "I want to run a service called foo, why should I have to learn the name of foo's config file first?"

systemctl is convenient. So convenient, in fact, that now you don't have to worry about where your service is. This is actually bad. We've been seeing college students enter their adult years with literally no idea what directories are:

[A]round the fall of 2017... a lecturer in the psychology department at the University of Sussex told a class full of research students to pull a file out of a specific directory and was met with blank stares.

Call this a Googling of the mind if you want. "I don't know what the best website is for checking the weather, I just know to type 'weather' into the search bar and click the first link." You might wind up on a reputable site. You might wind up on weather-is-controlled-by-space-lizards.conspiracy. If you don't have enough wit about you to know the difference between, say, NOAA and Accuweather, you are screwed.

This matters. It is important for users of their machine to know enough about it to be able to fix it when it breaks. Yes, I know, 99.9% of the time systemctl will just do what you want it to do. But it's going to break. It's systemd. It's not good code. Something will always go wrong eventually, especially as its growing functionally outpaces its regression testing framework. Driving a car is a fairly simple operation, too. Especially with power steering and anti-lock brakes and backup cameras. All of that is great, but it's still important that teenagers with a driver's permit learn how to refill a tank of fuel, check the oil and understand what the lines on the dipstick mean, check tire tread with a penny, pump the brakes in case ABS fails, and use a tire pressure gauge. To not have new drivers even know about these things is negligent. The annals of tow truck drivers everywhere are full of stories of kids complaining about how "Dad said I could use the car this weekend, what do you mean I have to put gasoline in it?!" Or my favorite, "Well now that you're here, can't you do it for me?"

You don't always have the luxury of taking your car into the shop and having a professional do a 7-point inspection for you. Sometimes your tire starts losing pressure when you're a hundred miles from home and you need to figure out what you're gonna do. You never want to be so dependent on your car's decision-making status quo that you end up locked inside it.

Just as letting the Jiffy Lube folks always maintain your vehicle isn't going to make you a better driver, systemctl sure as hell isn't going to make you a better system administrator. You might not care. You might not want to be a better system administrator, but bear in mind that ignorance of how broken your machine is impacts other people online, just as driving an unsafe car impacts other motorists on the road. The only difference is that there are laws against unsafe driving and making unsafe vehicles. "I made system administration so convenient that when my thing breaks no one knows how to fix it" isn't the slam dunk you might think it is.

kc1di wrote: Wed Aug 07, 2024 8:21 am I too resist systemd , though the original Idea to Update boot software was a good one It's became an invasive program that wants to control every part of the system. I too believe one of the great benefits of linux is choice. So There are other boot systems that could be adopted when system V is no longer viable. Not to mention systemd will become a security risk at some point. Jesse Smith of Distrowatch wrote a good article a few weeks back comparing the different init options.
found here https://distrowatch.com/weekly.php?issue=20240527#qa

Amen to that. The tendency of SystemD to control and drive changes into Linux which were not part of its original statement has left many of us wondering on the end state and motives. Especially if those are going to be beneficial to Linux Ecosystem. One of the way that SystemD will harm linux is the rigid straight jacket that it has forced upon Linux. If there is a change that is required to be made in Linux somewhere down the line, SystemD may become an impediment. And inability to change with circumstances is a sure shot way to irrelevance.

oops wrote: Wed Aug 07, 2024 11:55 am

thomasl wrote: Wed Aug 07, 2024 9:23 am ...
Well, I've always thought of myself as an informed techy guy and I think standardisation is (mostly) a good thing. No standards, no TCP/IP. No USB. No WiFi. No Linux kernel. Heck, no APIs at all: every API, whether a small web API or a huge OS API, like Win32 or indeed the Linux kernel , is an attempt at standardising access.

The problem is not standardisation. The problem is simply bad/sloppy engineering, both in the design and the implementation phases.

We should not confuse protocol standardization with application standardization ... for protocols it is relevant (speaking the same language, TCP, etc...), for low-level applications it is a monopoly in the long term leading to a lack of diversity (a lack of resilience and/or simplicity). So it is also a problem of standardisation (even for the kernel).

That is a very valid point. Standardization when it is focused on protocols and text is fine. Imagine if the TCP/IP protocol that won over its ISO counterpart had taken upon itself to define how firewalls should operate or switches should work or type of medium where it should be used or clock speed and so on. It would not have been success. It succeeded because it kept it Simple and restricted itself to the problem definition solution, i.e. boot process.

From Website description
“MX Linux – Midweight Simple Stable Desktop OS”

So simply, “MX of systemd only”will breaks Important Concept of MX?

We awaiting for Main development members action…

Would it be fair to say 'Is systemd trying to make Linux evolve into a Microscoft wannabe' ? similar to what some people say, Ubuntu already is on that road being the Microsoft of Linux, I don't know enough about Ubuntu only what i read and what they did years ago (phoning home). No not Ubuntu bashing just stating the fact that sly of hand from them is similar to what all the other big tech Co's do, they don't get nicer they just get greedier.
I'm guessing that M$ is utilizing that ideal of 'Keep you friends and you enemies closer' as it moves into the Linux landscape, I could never buy into that 'Oh no M$ loves Linux', yeah right, when money is the driver there are no friends.

Looks there are already a lot of opposing view for systemd.

(In my lotus sutra teaching says, It's a bit extreme, "Cut off root of one evil. Don't tolerate it. Stand boldly."
So "tolerate or cut off". It seems like our hopes are pretty much the same.)

Needless to say, future MX style will very differ depending on main Dev selects.

The question is, can be completely free of systemd and reliable the following basic?
Browser
Sound server
Network Manager
If not, then this discussion is useless.

asinoro wrote: Thu Aug 08, 2024 5:05 am The question is, can be completely free of systemd and reliable the following basic?
Browser
Sound server
Network Manager
If not, then this discussion is useless.

+ 1

artytux wrote: Thu Aug 08, 2024 4:06 am I could never buy into that 'Oh no M$ loves Linux', yeah right, when money is the driver there are no friends.

Microsoft's attitude towards Linux has evolved from where it was just a decade or two ago.

That being said, Linux is the most popular OS running on Azure these days. I've heard the ratio of Linux to other is 2:1 but I don't have concrete data to prove it.

asinoro wrote: Thu Aug 08, 2024 5:05 am The question is, can be completely free of systemd and reliable the following basic?
Browser
Sound server
Network Manager
If not, then this discussion is useless.

Linux wasn't exactly hurting for a better reputation regarding stability before 2011.

After reading many many of your posts I never ever thought of you as easily tricked because of being too trusting.
Time will tell about M$.

Network manager is not free from systemd already, in MX. Dolphin always has to make some tweaks so it works with sysV, from what I understand.

The original question has been answered. And endless opinions have been given. Topic is closed