MX Linux Forum

Are there all ready plans for a new version nl. MX-18?
And if not, when it is gonna be released?

Hello,

Probably not before Debian Buster release. But maybe a 17.2 release is planned.

generally, any new release is typically sometime around the middle of December.
- at least the last few releases have been.

Buster won't be released at least until deep into 2019, so we won't have one based on that before then.

We are going to test how well in-place upgrades instead of reinstalls to the new base go, too.

We'll have something sooner, it's not clear what the name will be, most likely 17.2 since that's what the devs talked (I personally was advocating for 18 since we are in 2018).

I agree that numbering using calendar base is more informative.
18.11, 18.12, etc just seems simpler and you don't have to wonder when was it released.

For example, 17.1 could have been 18.3_Horizon. It's just numbers. :) But people remember them.

"For example, 17.1 could have been 18.3_Horizon. It's just numbers."

Could be an effective marketing tool that would increase the popularity of MX beyond the Distrowatch domain (where it has climbed to 4). I used the September 2018 snapshot on this smooth Core2-E7500 installation (2gbDDR2, int.Nvidia7100). I think newbies would be more eager to try it if it was named MX 18.09.

Richard wrote: Thu Oct 18, 2018 9:49 pm I agree that numbering using calendar base is more informative.
18.11, 18.12, etc just seems simpler and you don't have to wonder when was it released.

For example, 17.1 could have been 18.3_Horizon. It's just numbers. :) But people remember them.

Yes, why not: MX18.03_Horizon (like Ubuntu versioning), MX18.12_Horizon, etc

Yep, that was my proposal, the only downside that I could think of: it might be confusing to have the same major version like 19.3 and 19.12 for example based on different Debian bases (and also having a string of different major release numbers 17.x, 18.x, 19.x all based on Stretch).

Just create a table of releases showing heritage
and place the link everywhere the question might arise in someones mind.

I have noticed that the MX team tends to distribute new features, such as Live USB creator, plymouth support, Flatpak support, Gimp 2.10, updated boot tools and appearance tools, to name a few... whenever they are ready and without triggering a release.
There are very compelling reasons for doing this -- most notably, it spares the dev team a huge amount of overhead, and users get to enjoy new features without having to upgrade. Personally, I love that.

This has proved to be a very successful practice model for MX.

But: <Hahaha, you knew there would be a "but">, from a business POV, there are advantages to managing the MX product a little differently. Three important sacrifices happen when you blend maintenance and feature upgrades (and to the same extent "rolling releases" share these same issues):
1) You miss marketing opportunities and the milestones that showcase the hard work and innovation of your volunteers. MX developers/contributors have a lot to be proud of, and deserve frequent recognition. Releases strengthen your curriculum vitae (resumes).
2) Product critics don't see that you're meeting any roadmap fundamentals, so new features since the last release resonate as maintenance rather than progress. So, reviews often focus on new artwork and cosmetics at release time.
3) Most importantly, you lose the "trigger" for contributions. People are very accustomed to paying at upgrade time. So, the timing of a coincident donation campaign seems natural after new releases.

I'm not suggesting you change anything. I'm simply offering up some past key learnings from my own experience.

MX is not a business.

There's another benefit of releasing new features when they are ready: we get bug reports and we can fix those immediately instead of waiting for a new release making MX a continuously improving product.

Also, as somebody who writes code I want it available to users as soon as possible, what's the point of coding a new feature if you have to wait half a year to deploy it. I don't think I would ever hold back code and features just for marketing purposes.

as somebody who writes code I want it available to users as soon as possible, what's the point of coding a new feature if you have to wait half a year to deploy it. I don't think I would ever hold back code and features just for marketing purposes.

And that difference in viewpoint comes from the fact that MX is made by fellow members of a community that pre-dates MX, not a team of devs creating a product from the top down and hoping to market it. The devs just stepped forward from the Mepis/antiX community because Mepis had been discontinued.

I admit I had early on - as a newcomer to the team - suggested that certain new features (not all of them) could be released with more fanfare with the next MX release, but the team explained why they did not think it was appropriate for MX.

I'm fine either way, as I was just bringing up something for consideration by the team.

It makes sense to hold up for technical reasons (like Debian builds Buster now as Testing and will release when they are ready) but for adding some feature in apps that don't bother other things I don't think we'll wait for the next release.

Adrian wrote: Fri Oct 19, 2018 12:06 pm Also, as somebody who writes code I want it available to users as soon as possible, what's the point of coding a new feature if you have to wait half a year to deploy it.

As it should be. In scaled Agile dev (SAFe), and its DevOps companion CICD pipeline, feature development is "everything" and they are simply activated when they're tested. Many modern shops have no such thing as a release. Even for documentation. It works really well. And external releases are fast becoming artificial constructs to help users and customers understand what's going on (and what they're buying - lol). Even kernel dev seems headed this way.

I'm just pointing out that as you move further this direction, there may be issues that pop up.
But , as Jerry mentioned, they may not apply to MX at all.

Adrian wrote: Fri Oct 19, 2018 12:06 pm There's another benefit of releasing new features when they are ready: we get bug reports and we can fix those immediately instead of waiting for a new release making MX a continuously improving product.

Yeah, on the forum of a major distro there are tons of bug complaints after a new release.
And the response is normally "what do you expect from a new release?"
Never thought of this. I like our paradigm.

I like how MX has done it: the year being in the name/number; I look at MX as being the best of that year -- i.e., at end of 2017 MX-17 comes out with the best Linux 2017 has to offer!

MX-18 at the end of 2018 matches the history of releases. MX-15 and 16 were both Debian 8 Jessie and end-of-year releases; So, having MX 17 and 18 be likewise would match nicely, and when Debian10/Buster version comes out make that MX-19.

It would be nice to have a new release that would support 2018 hardware out of the box (Ryzen and Intel Coffee Lake), with an updated kernel, Mesa stack, and firmware.

Stevo wrote: Fri Oct 19, 2018 4:16 pm It would be nice to have a new release that would support 2018 hardware out of the box (Ryzen and Intel Coffee Lake), with an updated kernel, Mesa stack, and firmware.

The october monthly upgrade version seems to work fine on my 1950x. The debian backports 4.18.x kernel seems to work fine in the two days I've had it, with the exception being that during boot, it'll sit around for a few minutes "waiting for devs to fully populate" (I first thought it was freezing. Nope, it's just slow), whereas the 4.15 kernel just plows straight to the login screen.

What hardware are you having issues with?

Richard wrote: Fri Oct 19, 2018 10:37 am Just create a table of releases showing heritage
and place the link everywhere the question might arise in someones mind.

Richard,

Below is a link with MX heritage posted.
https://distrowatch.com/table.php?distribution=mx

JR

log wrote: Fri Oct 19, 2018 4:57 pm

Stevo wrote: Fri Oct 19, 2018 4:16 pm It would be nice to have a new release that would support 2018 hardware out of the box (Ryzen and Intel Coffee Lake), with an updated kernel, Mesa stack, and firmware.

The october monthly upgrade version seems to work fine on my 1950x. The debian backports 4.18.x kernel seems to work fine in the two days I've had it, with the exception being that during boot, it'll sit around for a few minutes "waiting for devs to fully populate" (I first thought it was freezing. Nope, it's just slow), whereas the 4.15 kernel just plows straight to the login screen.

What hardware are you having issues with?

Not any problems at the moment, it's just that I know that Intel Coffee Lake graphics does require an updated kernel and Mesa to work correctly. If you want to use the Intel driver for it instead of the kernel's modesetting driver, that also needs an update.

You guys all have a lot of history together. Release aspects and preferences aside, consider my original points as questions:

1) Do all the volunteers feel they get enough timely recognition, respect, reward and appreciation for their contributions to the MX product?
2) Are you proud of the target position of MX and how the critics and public focus on the innovations you've delivered?
3) Are the donations to the MX project generating the revenue to finance the product and your vision for it?

These goals are often found in an org's top 5, and if you've answered "yes" to all, you get the gold star of perfection. You'd be crazy to change anything.

Adrian wrote: Fri Oct 19, 2018 9:49 am Yep, that was my proposal, the only downside that I could think of: it might be confusing to have the same major version like 19.3 and 19.12 for example based on different Debian bases (and also having a string of different major release numbers 17.x, 18.x, 19.x all based on Stretch).

No if you have : 17.03_H (H for Horizon), 18.03_I (I for what you want), .._J, etc

I think the numbering system is fine as is.

Yes, the number system actually doesn't matter
so long as the numbers keep increasing. :)

@namida12,
Thanks for the link.
That really seems to be a complete history,
coupled with the More Info button that goes back to the beginning version 14.0.

boys ... I only asked when mx18 started to see the light of day and did not expect a discussion about the numbering, this is something that the developers have to determine imo.

darknetmatrix wrote: Fri Oct 19, 2018 10:43 pm boys ... I only asked when mx18 started to see the light of day and did not expect a discussion about the numbering, this is something that the developers have to determine imo.

I'm curious though what you'd want to see in MX-18 that is different than the monthly snapshot (MX-17.1 + all pool updates)?

Adrian wrote: Fri Oct 19, 2018 11:57 pm

darknetmatrix wrote: Fri Oct 19, 2018 10:43 pm boys ... I only asked when mx18 started to see the light of day and did not expect a discussion about the numbering, this is something that the developers have to determine imo.

I'm curious though what you'd want to see in MX-18 that is different than the monthly snapshot (MX-17.1 + all pool updates)?

Maybe if it's possible to add the deepin desktop environment to the Mx-package installer?

That doesn't need a new release, to be frank.

Sorry to say, but I don't see it:

I think asqwerth meant that we don't need a MX new release for that, just a simple MX Package Installer update (if that is available somewhere in Debian sources or compilable to Stretch)

Ok, tnx. for the answer

Yes.

Adrian asked what you would like to see in MX18 that isn't already in the monthly snapshots for MX17. MX18, if there is one coming out end of the year, will still be Debian Stretch, just like MX17. Whatever packages and tools are updated in MX17 will be seen in any MX18.

It's just a matter of what you think should be installed by default (or removed from default) on the iso image, whether you want new artwork, having a new default kernel (that's probably the main and most important reason for a release right now I think, due to security reasons).

For a request to add to the Popular Apps list in MXPI, just post a request in the Bug reports and non-Package requests subforum for the Dev Team to consider. But like Adrian said, the first question is whether Deepin is already in the Debian repos and if not, whether it can be packaged to work in Debian Stretch/MX17.

asqwerth wrote: Sat Oct 20, 2018 10:36 am But like Adrian said, the first question is whether Deepin is already in the Debian repos and if not, whether it can be packaged to work in Debian Stretch/MX17.

I see Deepin packages in Sid and Buster when searching at packages.debian.org: https://packages.debian.org/search?suit ... rds=deepin
There's also this ppa here: https://launchpad.net/~leaeasy/+archive/ubuntu/dde

Don't know how many them would actually need to be built to provide a complete Deepin environment. It looks like it would be a good deal more work than the usual package request, more like backporting KDE, XFCE, etc.

I hope to see full disk encryption in MX-18 and fix the window size inconsistency with some applications.

darknetmatrix wrote: Sat Oct 20, 2018 8:57 am

Adrian wrote: Fri Oct 19, 2018 11:57 pm

darknetmatrix wrote: Fri Oct 19, 2018 10:43 pm boys ... I only asked when mx18 started to see the light of day and did not expect a discussion about the numbering, this is something that the developers have to determine imo.

I'm curious though what you'd want to see in MX-18 that is different than the monthly snapshot (MX-17.1 + all pool updates)?

Maybe if it's possible to add the deepin desktop environment to the Mx-package installer?

The last that I looked at the Debian deepin porting project, it was only being ported to upstream Debian, and needed a newer Qt 5 to build than we have in MX 17. If it's in Debian 10, we can add it when are based on that version.

Adrian wrote: Fri Oct 19, 2018 11:57 pm

darknetmatrix wrote: Fri Oct 19, 2018 10:43 pm boys ... I only asked when mx18 started to see the light of day and did not expect a discussion about the numbering, this is something that the developers have to determine imo.

I'm curious though what you'd want to see in MX-18 that is different than the monthly snapshot (MX-17.1 + all pool updates)?

If you are generally curious about oddball stuff people might be trying to use with MX then with me it's ZFS, Looking Glass and the various virtualization utilities. It's the latter that benefit from that latest and greatest kernel stuff.

Windows has always been my primary operating system, but for the last few years I've had great and mostly easy success using Openmediavault (also debian based) and ZFS to store my files, slowly picking up capability on the way. My ultimate goal is set up MX17/18 on zfs and to be able to boot straight to it. It's possible to install debian straight onto ZFS thanks to some guides and a script, but I'm going to be doing it backwards, which will be less prone to the need for nested problem solving. I'm going to install MX as normal, create a zfs partition, duplicate the files over, redirect the boot "stuff", and it should work out fine. This has an added bonus of having a fallback os in case things break. ZFS seems to work fine in MX from my limited tests, which makes sense due to the debian base.

The other piece of the puzzle is virtualization of a windows machine with pcie passthrough and using looking glass instead of a second monitor and keyboard/mouse. This is gonna take a while for me to get right, there's a lot of variables involved and fixes/updates are constantly happening, creating significant changes for the better. Here's a good example of something that was recently discovered in qemu.

I'm busy with some benchmarks right now since the topic came up and now is an ideal time for them, but after that I'm gonna get back to trying to rig things into working, make a huge mess, blow it all up and do it all again. I'm taking notes along the way, both about my setup, as well as various MX specific usability wishes or issues, and once I have everything finally figured out, I'll blow it up and redo everything a final time and create a guide to follow along in the footsteps of my questionable life choices.

Good job with this distro by the way, used it for about 3 weeks and it's been much better than other distros I've tested in the past. It's especially nice after I attempted to use debian (stable and testing) while benchmarking. Frankly it's a pain, way too much stuff to have to fix right at the bat.

I think it is more confusing to change the way you have been doing things.
I would like things to remain as they are for the sake of continuity.
This way the release based on buster would be MX19.
That makes the most sense to me.
Just my two cents.

I don't think MX Linux is changing their plan.

Some people like to try out things.
A stable base is appreciated when doing things that might break it.
It is easier to return to a stable base --via a snapshot from a known good state.

It's all interesting even though I have no plans to use anything but Xfce.

Richard wrote: Mon Oct 22, 2018 7:48 pm A stable base is appreciated when doing things that might break it.
It is easier to return to a stable base --via a snapshot from a know good state.

You hit the nail on the head for why I find it so appealing, despite preferring the kde ecosystem over gnome.

yet, most folks would be expecting an MX-18 release, this year,
& rather than an extension of the existing MX-17 snapshot.

those of us, in the know, would simply just download an later snapshot,
where some other users, would be looking for an MX-18 to be the later release.

it may just be a numbers thing, but that is what would be expected, in the wider Linux community.

Two things must be considered here:
1. Is there s genuine need to release a version 18 this year? Have been enough changes to warrant a new version ?

2. More important. MX is developed by unpaid volunteers for the benefit of many. They have also to live their private, family lives. Which has priority??

Blessed is he who expecteth nothing.

Pierre wrote: Thu Oct 25, 2018 12:21 am yet, most folks would be expecting an MX-18 release, this year,
& rather than an extension of the existing MX-17 snapshot.

those of us, in the know, would simply just download an later snapshot,
where some other users, would be looking for an MX-18 to be the later release.

it may just be a numbers thing, but that is what would be expected, in the wider Linux community.

So how does it work? Can you update to a later snapshot? Or do you install from scratch?

marlowe221 wrote: Wed Oct 31, 2018 11:27 am So how does it work? Can you update to a later snapshot? Or do you install from scratch?

Snapshots are the current release with all the updates added. If you update the current version, you will already be aligned with the latest snapshot.

There will be an upgrade path across versions unless the Debian version has changed.

Chris

Maybe providing GIMP 2.10.6 by default could be a feature of a new point release, since it updates a couple of important system libraries used by many other applications. We need to make sure it doesn't break font rendering for anyone, though.

Stevo wrote: Wed Oct 31, 2018 4:12 pm Maybe providing GIMP 2.10.6 by default could be a feature of a new point release, since it updates a couple of important system libraries used by many other applications. We need to make sure it doesn't break font rendering for anyone, though.

I'm ok as long as it goes OK with a regular dist-upgrade.

Why not providing a newer kernel in a potential 17.2 release ? Kernel 4.15 looks outdated in terms of security.

I trust Debian for security. Stretch now uses 4.9.0-7 4.9.0-8 and it is current with all security patches.
https://packages.debian.org/stretch/linux-image-amd64

typo edited

the Debian backport kernel: 4.18.0-0.bpo.1-amd64 gives the following summary result of mitigations from the spectre-meltdown-checker, on the T430 : And it runs fine without problems. I don't use Suspension on my SSD so don't know about that.

Debian Stretch
spectre-meltdown-checker looks OK to me

Why not just repackage 17.1_November as "18" (or maybe even "19") for the "greater Linux community" and MX newbies, and continue to field 17.1 monthly updates for the rest of us?

zorzi wrote: Wed Oct 31, 2018 4:33 pm Why not providing a newer kernel in a potential 17.2 release ? Kernel 4.15 looks outdated in terms of security.

We've been doing that for the past releases, so I don't see any reason why we would stop now.

Though the Debian stable kernel is great for security reasons, it's getting old and most new hardware is going to have trouble with it...even some 2018 hardware doesn't run quite right on stock MX 17.1 with its 4.15 kernel and 2016 vintage Mesa ( like the MSI GP63 I'm typing this on. But a newer kernel plus newer Mesa=near perfection...haven't even been any glitches at all with suspend or hibernation for quite a while)

We don't want users or reviewers to try using MX on their hot new laptop and not be able to boot or have a lot of issues.

Or just put the newer kernels in the next update for MX-17.1 to make it easy. Will MX-18 come out in December like previous new versions of MX usually do?

the thing is, that I'm intending to give a couple of PCs an re-birthing next month,
& ideally, that would be with MX-18.

but - that's starting to look more liker it'll be MX-17x instead.

that's not an issue in itself, as there seems to be no real reason to upgrade the current MX-17 series,
but I'm intending to do an upgrade anyway.

let's clear up a little confusion

there will be a release.

it will be exactly the same whether its called MX-18 or MX-17.2, because we are supporting direct upgrades at least inside the same debian release (in this case stretch).

as the Bard says

What's in a name? That which we call a rose
By any other word would smell as sweet

IMHO,
it would smell sweeter as MX-18, since we'll soon be in 2019.
People prefer a One year old release over a Two year old version?
If you don't know what's behind them, the numbers have meaning.

It's becoming more prevalent on this forum with the new arrivals.

This will be a discussion topic for the Devs in the near future, I am quite confident.

MX-18 for a next release makes sense to me, especially if if has a new kernel. In a few months (in 2019) MX 18 will sound a lot more up to date than 17.2.

But MX-19, NO, I would reserve that for the next Debian stable (buster?). And that will be in 2019.

just my 0.02$ worth.

Richard wrote: Thu Nov 01, 2018 8:03 am IMHO,
it would smell sweeter as MX-18, since we'll soon be in 2019.
People prefer a One year old release over a Two year old version?
If you don't know what's behind them, the numbers have meaning.

It's becoming more prevalent on this forum with the new arrivals.

There is always a balance... Maybe the goal isn't users, but a functional distro that will attract the right people. I think "MX Horizon 19.01" would make sense for a Stretch based release in January 2019.
(All Stretch based releases being called Horizon with release date added)

A logical name is the most important I think so MX 17.2 also makes a lot of sense. I find MX 18 a bit confusing if it is Stretch based, but not more confusing than I am able to learn it in two seconds.

So in the end lots of good names to choose from!

Some new hardware also requires a newer Mesa, which is simple to backport with a few extra build-deps since we already have llvm-6.0 in the test repo. We already have Mesa 18.1.7 in the Experimental repo. There's also already one in stretch-backports, and we released the last version of Jessie-based MX 16 with the backported Stretch Mesa 13.0.6, so I think that would also be a worthy update if we get enough positive testing.

"MX 18" or "MX 19" might make some think "reinstall probably needed".

I prefer simple "point releases" (17.2, 17.3, etc.) ... "Update and continue" is the mindset most of us are accustomed to with Debian.

I'm certain I must have missed what the next release will contain somewhere in the discussion about the release name(s). If I didn't, would someone point me to where the 'content' of the next release is being discussed? Sorry to be so dense.

"I'm never lost... everyone tells me where to go."

Sticking with what the developers have it at would be easier for them. I personally don't care which number it's given. What's the most important thing is what will be new in it and when roughly will the newer version of MX Linux be released?

I agree @Mauser. Is there a place (thread) where the content is being 'fought over'--- I mean discussed.

The development team has a private subforum here where we discuss those matters. So far, some ideas that have been floated include a newer kernel and Mesa for recent hardware, and maybe gimp-2.10.X. We've just added a new llvm-6.0 toolchain backport to main to support a new Mesa if it comes to that.

Stevo wrote: Mon Nov 05, 2018 6:57 pm The development team has a private subforum here where we discuss those matters. So far, some ideas that have been floated include a newer kernel and Mesa for recent hardware, and maybe gimp-2.10.X. We've just added a new llvm-6.0 toolchain backport to main to support a new Mesa if it comes to that.

Thanks. Any word on full disk encryption?

Dolphin_Oracle tweeted about that a week ago:

@dolphin_oracle: @MX_Linux started working on adding encryption to the installer. Long way to go but in progress!

Jerry3904 wrote: Mon Nov 05, 2018 8:02 pm Dolphin_Oracle tweeted about that a week ago:

@dolphin_oracle: @MX_Linux started working on adding encryption to the installer. Long way to go but in progress!

O.K.