Debian User Forums

And we got a really nice review of MX Linux from a notably picky reviewer: https://www.dedoimedo.com/computers/mx-17.html

Thanks to all the Debian developers that do the really hard work underpinning the distro. We are waiting for the agents and scouts to call with limos full of cash before we "go pro", though.

Congrats, great review.

Just a quick question, what is ram usage like running firefox or chromium? I wouldnt mind using MX for my media centre PC and would be ok with ram usage up around 1G watching youtube/vlc as that is all i mostly do with it.

Seventh wrote:what is ram usage like running firefox or chromium?

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

debiman wrote:

Seventh wrote:what is ram usage like running firefox or chromium?

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

I wasnt asking you. But i suspect you maybe right, ram usage on most linux distros fluctuate between 500 mb and 1G or more. In the past i have found xfce4 with web browsing/multimedia to hover around 1.2 GB ram usage, sometimes climbing as high as 1.7G.

My devuan openbox distro that i created is hovering around 700 mb and i have been watching 1080p youtube videos for over 2 hours.

by Seventh »I wasnt asking you.

In case you didn't notice, this is a public board, when you ask something ,
everybody reads it, and anybody may answer.

Post by stevepusser » 2018-01-13 19:44
And we got a really nice review of MX Linux from a notably picky reviewer:

Congratulations, I have all ways been happy with the previous MX versions,
haven't tried 17 yet though.

Specifically i asked for steves input, i dont care for debimans.

Seventh wrote:Specifically i asked for steves input, i dont care for debimans.

@Seventh
I don't want to pick a fight with you Seventh or to annoy you but it wasn't clear to me that you "specifically" only wanted an answer from Steve. Even if it had been, Garry's point is still correct. Public forum.

There is a method to not see the posts of any specific poster if you so choose or you could just choose to pass over them and move on.

@stevepusser
My congratulations to you and the MX team also. I haven't tried MX17 yet but I am very impressed with MX16, nicely polished, attractive and easy to use. It makes a great live distro too, for fixing installs that won't boot for some reason. Your forum does not seem to attract some of the toxic posters that often appear here and posters get answers to their questions very quickly and often from actual developers.

A lot of the posters who post here on DUF and aren't willing or able to read documentation or study anything or even learn how to ask smart questions would likely be happier using MX.

Very nice. Kudos to the MX-ers! I'll be using this on an old server I'm presently recycling for re-purpose.

Congratulation MX devs, MX(Mepis/Antix) been most known best among Debian based built.
But I'm kind of a bit vexed that you didn't join Xfce team project otherwise you'd boost up Xfce project super faster.
Since you've a lots of Xfce tweaks apps that you can't find on other Xfce distros.
Similar to Q4OS case that had a lots of TDE tweak apps.

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 wrote: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.

Congratulations Steve, anti and MX/antix team. applauds and round of drinks for all.

debiman wrote:

Seventh wrote: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.

HuangLao wrote:

golinux wrote: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.

Innovate wrote:Congratulation MX devs, MX(Mepis/Antix) been most known best among Debian based built.
But I'm kind of a bit vexed that you didn't join Xfce team project otherwise you'd boost up Xfce project super faster.
Since you've a lots of Xfce tweaks apps that you can't find on other Xfce distros.
Similar to Q4OS case that had a lots of TDE tweak apps.

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.

golinux wrote:

HuangLao wrote:

golinux wrote: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.

stevepusser wrote:

golinux wrote: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.

golinux wrote:

stevepusser wrote:

golinux wrote: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?

HuangLao wrote:

golinux wrote:

stevepusser wrote: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.

golinux wrote: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.