MX Linux is standing on the shoulders of the Debian giant

[stevepusser]

I applaud any distro rejecting systemd and I find it interesting that this review completely ignores what init MX uses. MX is advertised as systemd-free but according to this page systemd is only disabled as init. From that I assume that all the 'tentacles'/dependencies in user space applications still remain. This is not systemd-free IMO. It does look very well put together though. Well done all!

Devuan has taken a different approach. Devuan is removing those hard dependencies which severs ties with anything systemd. Some libsystemd deps which require libsystemd0 and are (for the moment) benign, are present but not a priority until the hard dependencies are removed. We are hoping that a lot of automation will eventually be able to do some of this tedious work.

golinux, why take the opportunity to advertise, just congratulate the effort as you did and carry on. However, since you did.... antiX is systemd free and Slackware/Salix is as well and has no intention of ever using it.

I belabored the point not to advertise but to clarify that systemd-free can mean different things - free of systemd as init or free of systemd as init AND free of gratuitous systemd dependencies in user space also. There is a HUGE difference. If all of those dependencies - and there are a LOT of them - have indeed been stripped out of MX, I owe Steve et al a huge apology! I can't speak to Slackware/Salix.

No, we leave the systemd hooks in the applications, along with the option to boot using systemd, in case some one wants to install some outside application that really needs it. Plex straight from the developer, for example, only starts its service with systemd, though I think the MX devs have come up with a sysvinit script for it and added it to the Plex install script.

[golinux]

I belabored the point not to advertise but to clarify that systemd-free can mean different things - free of systemd as init or free of systemd as init AND free of gratuitous systemd dependencies in user space also. There is a HUGE difference. If all of those dependencies - and there are a LOT of them - have indeed been stripped out of MX, I owe Steve et al a huge apology! I can't speak to Slackware/Salix.

No, we leave the systemd hooks in the applications, along with the option to boot using systemd, in case some one wants to install some outside application that really needs it. Plex straight from the developer, for example, only starts its service with systemd, though I think the MX devs have come up with a sysvinit script for it and added it to the Plex install script.

Thanks Steve. The clarification is greatly appreciated. But that leads to another question . . .

Does MX have a Plan B if Debian should decide to remove support for sysvinit? This is a possibility that many of us have envisioned and considering what has already happened is not that far-fetched . . .

And one more . . . have you tried to submit the patch for sysvinit compatibility to Debian or Plex? And was it accepted or rejected? Just wondering what the climate of inclusiveness is in the wild. We have found some packages where there was sysvinit support upstream but stripped out by Debian. That does not bode well for the future IMO.

[HuangLao]

I belabored the point not to advertise but to clarify that systemd-free can mean different things - free of systemd as init or free of systemd as init AND free of gratuitous systemd dependencies in user space also. There is a HUGE difference. If all of those dependencies - and there are a LOT of them - have indeed been stripped out of MX, I owe Steve et al a huge apology! I can't speak to Slackware/Salix.

No, we leave the systemd hooks in the applications, along with the option to boot using systemd, in case some one wants to install some outside application that really needs it. Plex straight from the developer, for example, only starts its service with systemd, though I think the MX devs have come up with a sysvinit script for it and added it to the Plex install script.

Thanks Steve. The clarification is greatly appreciated. But that leads to another question . . .

Does MX have a Plan B if Debian should decide to remove support for sysvinit? This is a possibility that many of us have envisioned and considering what has already happened is not that far-fetched . . .

And one more . . . have you tried to submit the patch for sysvinit compatibility to Debian or Plex? And was it accepted or rejected? Just wondering what the climate of inclusiveness is in the wild.

Does Devuan have the infrastructure/build system to build all binaries from source?

[golinux]

No, we leave the systemd hooks in the applications, along with the option to boot using systemd, in case some one wants to install some outside application that really needs it. Plex straight from the developer, for example, only starts its service with systemd, though I think the MX devs have come up with a sysvinit script for it and added it to the Plex install script.

Thanks Steve. The clarification is greatly appreciated. But that leads to another question . . .

Does MX have a Plan B if Debian should decide to remove support for sysvinit? This is a possibility that many of us have envisioned and considering what has already happened is not that far-fetched . . .

And one more . . . have you tried to submit the patch for sysvinit compatibility to Debian or Plex? And was it accepted or rejected? Just wondering what the climate of inclusiveness is in the wild. We have found some packages where there was sysvinit support upstream but stripped out by Debian. That does not bode well for the future IMO.

Does Devuan have the infrastructure/build system to build all binaries from source?

YES we do! We are removing systemd dependencies and/or providing viable alternatives built on our infrastructure. That is really the point of what we are doing.

Note that the last para of my previous post has been expanded a bit.

[HuangLao]

YES we do! We are removing systemd dependencies and/or providing viable alternatives built on our infrastructure. That is really the point of what we are doing.

Note that the last para of my previous post has been expanded a bit.

That is great to hear. Unfortunately, I think it may be the only or at least best solution in the future. That is how Slackware has been able to avoid things like this in the past and present.

[Seventh]

what is ram usage like running firefox or chromium?

i suspect it's the same as on any other distro.

It depends on how many tabs you have open and how much junk the web pages throw at you. So it has no magic to reduce that, the desktop just starts out at a certain RAM use and you load the browser/media player on top of it. A window manager only will be lighter than xfce.

Ok thanks, i just thought you may have has some average figures. I suppose one just has to suck it and see.

[Head_on_a_Stick]

Congratulations to the MX Team for a fantastic release!

And very well done for pleasing that Domeido bloke, he didn't like us anywhere near as much

[Innovate]

The MX tool developers really only know how to program in Qt, so that's what most of the tools are written in. I don't think that would go over great at the GTK-based XFCE. Bringing in the Qt 5 runtime libraries no doubt makes the RAM use higher...think what it would be if the tools were using the libraries that XFCE already loads. For the most part, they just manipulate scripts and text files, so would probably port over to GTK easily.

I see, fair enough. That's very strong reason indeed, I'd respect MX team decisions I won't rush.
I've saw something similar on Lite as well they're all pythons but Xfce is whole GTK2+3.
I was wondered why each Xfce distros they keep their own tech away from official Xfce
rather than submit contribute their tech. Seems they've their own specific & incompatibility reasons.

I've did quite research & study many special Xfce distros that I go they've have their own interesting Xfce utilities.
Some generously distribute their code on github, some were hide in launchpad. Some keep their stuff to themselves 0 code release.
They've scattered around everywhere like lost tech, relic & artifacts which valuable with Xfce developments.

[anticapitalista]

golinux is (deliberately) confusing MX Linux and antiX. As has already been stated numerous times, antiX DOES NOT use systemd at all!
We have nosystemd packages for stretch/testing and sid. Thanks to work done by Devuan, we also ship with eudev.

http://repo.antixlinux.com/stretch/pool/nosystemd/
http://repo.antixlinux.com/testing/pool/nosystemd/
http://repo.antixlinux.com/sid/pool/nosystemd/

MX Linux chose a different path (like Knoppix) to use systemd-shim

[golinux]

golinux is (deliberately) confusing MX Linux and antiX.

No I am not. I have not once mentioned antiX in this thread. In fact, I had not given a thought to antiX for quite a while until you brought it up just now.

As has already been stated numerous times, antiX DOES NOT use systemd at all!

That is fantastic!

We have nosystemd packages for stretch/testing and sid.
Thanks to work done by Devuan, we also ship with eudev.

http://repo.antixlinux.com/stretch/pool/nosystemd/
http://repo.antixlinux.com/testing/pool/nosystemd/
http://repo.antixlinux.com/sid/pool/nosystemd/

I would be curious to know how you achieved that. By elimination or by rebuilding of all the 'infected' packages.

MX Linux chose a different path (like Knoppix) to use systemd-shim

Unfortunately that association could be a bit of an albatross for you then. Though as I said earlier, I haven't given much of a thought to anitX lately. I used to be reminded of it when you'd visit the refracta forum (before tapatalk destroyed it after the freeforums sellout).

I'm really not trying to pick a fight; just trying to clear some possible confusion.

[anticapitalista]

golinux - I'm not here to pick a fight either. I just wanted to make it clear that antiX and MX are 2 different beasts when it comes to avoiding systemd as an init system.

antiX nosystemd debs are rebuilt from source, just as Angband does it. (We use some of their debs for sid and testing if they beat us to it in packaging).

We have also found that we have had to rebuild some other Debian stretch packages that nominally do not require systemd/libsystemd0 in order to work correctly on sysvinit eg ifplugd, ifupdown (stretch onwards).

Jessie was relatively easy to make a totally systemd-free including no libsystemd0 Debian based distro (antiX-16). Stretch and beyond is much more difficult and time consuming.

[anticapitalista]

golinux - I have a question for you.

Does Devuan build its own kernel or use a Debian one?

[HuangLao]

anti, good points. This brings up a valid question for Debian derivatives....Could (if ever needed) antiX, MX and Devuan, exist independently of Debian by either rebasing on another distro or building all packages from source?

[golinux]

golinux - I have a question for you.

Does Devuan build its own kernel or use a Debian one?

Default Debian kernels.

[golinux]

anti, good points. This brings up a valid question for Debian derivatives....Could (if ever needed) antiX, MX and Devuan, exist independently of Debian by either re-basing on another distro or building all packages from source?

If things continue down the current path of you-know-what continuing to tie itself to more and more packages/functions, it is likely that Devuan will of necessity have to stop using the Debian repos directly and instead fork them to Devuan infrastructure to preserve them.

We are already building/maintaining these packages from source for Devuan. There are others in testing and experimental.

Devuan's goal is to provide ALL Debian packages (and there are about 52000+ in
Ascii) for installation. Devuan also builds for many different architectures in an effort to be a "universal operating system".

[anticapitalista]

anti, good points. This brings up a valid question for Debian derivatives....Could (if ever needed) antiX, MX and Devuan, exist independently of Debian by either rebasing on another distro or building all packages from source?

Unlike Devuan, we couldn't. We (I'm speaking for antiX not MX) simply do not have the resources to do so. Instead we would probably rebase off Devuan if Debian became impossible to manage without systemd.

golinux - I have a question for you.

Does Devuan build its own kernel or use a Debian one?

Default Debian kernels.

Thanks

[golinux]

Unlike Devuan, we couldn't. We (I'm speaking for antiX not MX) simply do not have the resources to do so. Instead we would probably rebase off Devuan if Debian became impossible to manage without systemd.

If it comes to that you and your formidable talents would be most welcome. You will find familiar faces there so a bit of a homecoming.