MX Linux Forum

Hello everyone.
MX is a very good distro nowadays but I still have a few pretty major wishes for improvement.
Please take them as constructive criticism from a user who would like to have strong alternative to the "well-known-Debian-fork".

1) Stick to the latest LTS kernel (for security and hardware support)
(It's sad to know that MX16 was with backported kernel 4.7 for the whole life-cycle)
Some Debian users want to have stable secure system which works well on modern hardware. They're forced to use backports but this solution has a few flaws: you sacrifice security patches, it's never-ending process. I quite like Canonical's approach (supported point releases with updated kernel, Mesa, xOrg) but the problem is that they have non-LTS, so they reach End-of-life, the have to maintain themselves (not an option for MX I presume). Mageia's approach sounds great to me - jump to kernel 4.14 and updgrade Mesa for latest hardware support, monitor & patch security issues. That (at least partly, with kernel) I'd like to see in MX.
Idea: take latest backported Debian kernel (with config and patches), apply upstream kernel updates, maintain kernel this way as long as possible.
(go even further with) Optimized kernel (branch): all above + CK & BFQ patchset (I can update that instruction for current BFQ-SQ if you're interested)
Actually I wouldn't mind maintaining such kernel but I'm not a coder (to fix possible FTBFS with patches) and can't package properly.
2) Apply patch to xorg-core to allow combinations with Ctrl+Shift when it's binded to keyboard switching shortcut
3) Make LibreOffice Standard Filter resizeable (simple config edit)
4) Disable NetworkManager MAC address randomizer (simple config edit)
5) Get rid of some Thunar custom actions.
Some custom action (such as "Ownership to user/root") are useless for most users and could be dangerous for newbies. Besides, they complement the "wall of menu items". This "wall" wouldn't be that big and confusing with KDE-like cascade menus but unfortunately it's impossible (hard?) to group them in Thunar. So I'd just leave only important ones (Catfish, Terminal).

Sorry for my English and hope that at least something of this will help you to make MX better.

4) Disable NetworkManager MAC address randomizer (simple config edit)

I don't think that's enabled by default.

Otherwise you make some good points, developers are already talking about some of these issues.

5) Get rid of some Thunar custom actions.
Some custom action (such as "Ownership to user/root") are useless for most users and could be dangerous for newbies....

Welcome! Lots of food for thought.

For myself, the ownership to user/root action is the only one I would really want to get rid of. It's easy to confuse with another action close to it in the right click menu, i.e. Open as Root.

But I like having the rest. For me especially, these 2: Open as Root, Edit as Root, are must-haves.

asqwerth wrote:

For myself, the ownership to user/root action is the only one I would really want to get rid of. It's easy to confuse with another action close to it in the right click menu, i.e. Open as Root.

But I like having the rest. For me especially, these 2: Open as Root, Edit as Root, are must-haves.

I agree, ownership as root should not be something that people use a lot and if they did they should be able to do it in other ways.

I think most of these suggestions make sense but this one is especially dear to my heart:

Alt wrote:2) Apply patch to xorg-core to allow combinations with Ctrl+Shift when it's binded to keyboard switching shortcut

Thanks for bringing that up! I miss this sorely as many of my old Windows shortcuts are Ctrl+Shift based.

asqwerth wrote:

5) Get rid of some Thunar custom actions.
custom action

these 2: Open as Root, Edit as Root, are must-haves.

Speaking of "Edit as Root" there's more safe and future/Wayland-proof solution (see KDE developer post) with sudoedit.
You can try it in terminal It's possible to skip the first command by adding it to your ~/.profile file (notice that after that it will be impossible to execute 2nd command in gui-less session (by default Debian uses nano for it) though direct "evaluated" nano is still an option).
But I guess you guys will implement it properly.