Howard, the ComputingForGeeks quote you shared describes the *post‑release*
policy, which is correct: once Debian Stable ships, it only receives security and
bugfix updates.
My point was about the *pre‑release* phase. Before Debian Stable is published,
the Debian Kernel Team takes the upstream LTS kernel and applies its own patch
series, including safe driver and hardware-support backports. This is documented
in the Debian Kernel Handbook under “Changes to the pristine kernel source”:
https://kernel-team.pages.debian.net/kernel-handbook/ch-source.html#changes-to-the-pristine-kernel-source
So yes — after release it’s frozen. But the kernel shipped *with* Stable is
already a modified, modernized kernel, not the vanilla upstream one.
I do think MXLinux as a better debian than debian could ever be. New kernel support, mx-tools utilities, and disconnect from hard-dependencies to systemd and all of those other little extras that distros are binding into eg: snap/rust/kde/gnome.
Welcome to the Forum Sammy.
We look forward to your continued input. BTW, I like MX also..
First of all thank you for your reply and a warm welcome to our comunity !! As for your point mx linux is a fantastik distro for people who like sysvinit and the mxtools suites . However it is not debian but better the two distros have two very different missions . Debian is meant to be a base you build your system on : your choices of init,file systems, kernels, debian branches and workflows . Mx linux while amazing is meant to be ready made and user friendly . And just to clarify one point mx linux ships with the exact same kernel as debian stable .So the kernel support you get in MX is
the kernel support Debian already engineered before release — which was the
discovery I wanted to share.
Hi and welcome to our community thanks for your contribution, look forward to hearing more from you. Many of our members would agree with you on mxlinux, personally I go for linux mint debian édition
I think MX does update kernels post-release… not sure … maybe only in MXahs?
That may be why it is called semi-rolling… it has a lot of updates like a rolling release… not just security updates.
Also, the latest MX allows booting with either sysVinit or systemd … you can choose in the grub menu.
The ahs variant yes but i don’t know where they get there kernel from whether its from the debian backport repos or whether its somethink like the zen kernel . You re going to have to ask a an mxlinux ahs user . However the regular mxlinux version ships with the debian stable kernel the 6.12 by default .
I found this
“MX Linux does not automatically update the kernel during regular package upgrades. Users need to manually select and install kernel updates through the MX upgrade GUI. This approach differs from some other Linux distributions that treat the kernel as just another package to be updated automatically.”
So it offers kernel upgrades or downgrades, but you have to manually initiate them.
I remember now, I have done that.
Also this for LMDE
“LMDE (Linux Mint Debian Edition) does not include a built-in kernel selector in its Update Manager. This is because the option is disabled by default to maintain system stability. Mixing kernels from outside the Debian stable repositories can lead to compatibility issues and system instability.”
So LMDE is tied to the Debian philosophy.
True rolling release distros like Void Linux include kernel updates with their package updates. Kernels accumulate in /boot and have to be cleaned out occasionally.
Gentoo leaves it to the user to decide when and if to compile another kernel.
FreeBSD bundles the kernel with utilities and you can roll the bundle forward or back across several versions whenever you choose. Packages in FreeBSD are a separate system.
Not necessarily…
e.g. Oracle take the kernel that Red Hat maintain - and create the UEK (unbreakable enterprise kernel - it’s anything but “unbreakable” i.e.: an oxymoron)…
Sure - they both leverage the same Linux Kernel source code maintained by the kernel team and Linus - but - in different ways…
And you’ll find that all those enterprisey distros - like RHEL and OEL (Oracle) are whole version behind on their currently supported environments…
Kernel 5 is the default in RHEL 9… None of my customers run RHEL 10 - but - I have a couple of KVM vms and RHEL10.0 is on kernel 6.12 (so it’s not as conservative as RHEL 9)…
And my biggest customer is only just starting out on RHEL 9 - most of their other stuff is RHEL 7 or 8 or OEL 7 (now end of life) and 8… I think they might even still have some RHEL6…
I have one system at one customer - I’ve been hassling for 3 years to replace, running Oracle Linux 5 - which is running kernel 2.6.32-uek!!!
Anyway :
RHEL 10.0 (no patches - a VM in KVM) :
6.12.0-55.38.1.el10_0.x86_64
Debian 13 (somewhat patched but not latest - bare metal “headless”) :
6.12.94+deb13-amd64
Yeah, I think most linux distros do a bit of that. … there are zillions of kernel config settings.
What is really a problem for the BSD’s is that their kernel API’s are all different. You cant take a driver from Freebsd and use it in Netbsd … you cant write a program with system calls for FreeBSD and expect it to work in other BSD’s.
The various BSD’s are not distros, they are separate OS’s.
Thats fascinating to learn thanks . I wonder how redhat modifies the kernel used in rhel and if its similar to what debian does with there own . Do you have epxerience with rhel personally with work ?
They probably change some config settings and recompile it.
I bet they dont touch the source code.
I don’t know anything about rhel myself but i started looking into it and according to the website What is backporting and how does it affect Red Hat Enterprise Linux? - Red Hat Customer Portal it would seem that redhat does the same thing as debian with the backporting only on an enterprise scale . That being said i repeat i don’t know the first thing about redhat i just reported what i read .
Too easily. Be warned… changing your kernel from the default can lead to irrecoverable errors.
Only do it if needed, eg to get newer drivers.
I once changed from an AHS kernel to a normal one, and it trashed the whole package system … had to reinstall from scratch.
MX in normally reliable, but there are no guarantees if you change a kernel.
MX does automatic kernel updates within a release
"Kernel Updates in MX Linux
MX Linux updates kernel versions through various methods, ensuring users have access to the latest features and improvements.
Methods of Kernel Updates
Regular Package Updates: Users receive kernel updates as part of the standard package management system.
ISO Refreshes: Periodic ISO refreshes are released, which include newer kernels along with other system updates.
AHS (Advanced Hardware Support) Kernel Updates: These updates are specifically designed to enhance support for newer hardware."
You will sometimes notice that a package update includes a kernel and firmware. It will reconfigure grub if the package update installs a kernel . These automatic kernel changes are safe… because they are compatability checked.
And Google do that with the kernel they use in Android - they strip a whole bunch of stuff out - e.g. NFS support…
Meanwhile - 'cause Apple leverage BSD and mostly FreeBSD - even on iPhone and iPad - you can do NFS client on iPad… Nearly impossible on an Android tablet…
It’s a filesystem object in the kernel source… it’s not there in the Android version of the Linux kernel…
There is a challenge. Who can edit the android kernel binary and insert it?
People used to do things like that… its called ‘job security’ … noone else could either fix it or update it.
I have changes the kernel in MX a couple times and did not have a problem. I was not going to or coming from an AHS kernel tho.
You will generally get away with it.
MX would not put those kernels there in the repo if they expected trouble.
I did not mean to scare people.
Do a current backup if you are changing a kernel.
You can get the source and do it yourself I suppose - it’s allegedly open source…
git clone https://android.googlesource.com/kernel/common
Other vendors (Samsung) plonk a bunch of proprietary blobs on top, or even in it? Good luck building your own Android kernel with a vendor locked down bootloader - e.g. Knox on Samsung (the splash screen on boot says “Secured by KNOX” I prefer to think of it as “hamstrung by KNOX” or “crippled by KNOX”… Samsung are pretty shit at the marketing side of their IT stuff - like their lame “Bixby” for Android… But DeX is pretty neat…
Bizarrely - the most “open source” Android phone, the easiest to load an alternative Android on (e.g. LineageOS) are Google’s own Pixel phones… And before that their “Nexus” range (which were mostly rebadged / re-engineered LG phones)…
I’ve figured the only way to avoid Google killing “side-loading” (and thus killing F-Droid and TermUX) is to NEVER update again! It’s annoying though - daily reminder nags “UPDATE!” No! To paraphase Zach de la Rocha and Rage Against The Machine :
