That is not really the case from what I can read there.
It is indeed common practice to run a server on LTS as you do mostly need no latest features and instead stay on Long Term Supported feature sets.
And caused by that it will be that LTS Arch Linux package have stuff added related to server usage…
But in the end, Arch Linux itself is not a dedicated Desktop Distribution, it is open to be used as you set up on your end.
And we do not set LTS to be the default inside bootloader, this is simply the default if you install it second after the main kernel.
EndeavourOS is also not a full-blown handholding setting up every bit for Desktop usage Distribution, we do follow the strict principle of doing only minimal configurations to provide a starting point to set up the OS as you want.
Also, I find the title a bit confusing as it is not general about the LTS Kernel and instead related to the packaging downstream at Archlinux.
I have read the thread in entirety - I can’t say all of the links though although I don’t know which one I’m missing.
The way this still reads to me is that the lts kernel is targeted for servers. Maybe it could be written better then. It doesn’t say only intended, but as it’s worded it would lead me and I’m sure others to believe it’s intended for server use primarily, and not desktop use. Not saying it couldn’t be used, just that it’s not really intended for it.
I read that too. His reply was very vague at best, and said that “The mainline kernel doesn’t tell you it’s better suited for desktop use as well.” Which implies (to me) that the lts isn’t specifically targeting server use either. But that it is implied a longer term kernel would be better for servers, and said to ad hints to wiki as such. Both kernels would be more than sufficient for desktops, with lts release more geared towards servers would seem to make common sense anyways, I don’t know why that would need to be written in, but if you’re going to hint at it using the verbage “targeting” is very direct where it could be much better worded.
Understood. I definitely agree with you there. That part doesn’t make sense, and there’s a LOT of folks who want to and are happily running the latest stable kernel. The only caveat I could say to that is Mint and Debian I believe are both on kernel 6.1, and a lot of others are even still in the 5’s. Arch LTS is 6.6. . . so it’s not that far in the past. Most people that are strongly performance oriented are willing to have less stability. Average users generally value stability over a little more performance (its’ true with many things in life. I can’t imagine most people buy a Camry for performance over stability). But Arch LTS is still far newer than most of the LTS distros. They all have their pros and cons, none of which are right or wrong necessarily. But picking an LTS and complaining it’s old doesn’t make a lot of sense either way you try to dice it. I don’t get that either.
What makes that specific point release special and delineates “desktop focused” usage from “server focused” usage?
Nothing. There are two independent dimensions: a) stable vs LTS and b) server vs desktop.
Stable receives more development and new features, LTS only receives bugfixes. That’s it, it has in itself nothing to do with server or desktop.
Then you can tweak either of them for scenarios that are more suited for a server or a desktop.
You can easily imagine a 2x2 matrix covering all four cases. But that’s not what Arch offers, Arch decided to have one LTS version and that is leaning towards servers. You can run a desktop-LTS version too: some are in the AUR, or you compile it yourself.
If I have understood the kernel branches and releases not that wrongly, at the time of the release of a stable kernel, it has already undergone 7 weeks of bugfixes (when still in mainline: rc1-rc7).
After the release, the stable kernel will only receives bug fixes backported from the current mainline in development. No new features.
So my question is how probable in reality is that a patch intended to fix a bug, would in fact introduce a new bug or cause a kernel regression?
My uneducated guess is that it is quite improbable. Not saying it is not possible but the probability should be quite low.
More, the bugfixes are backported to LTS kernel series as well, so what prevents the same bug fix causing issues in the latest stable won’t be causing issues in the LTS series as well?
I’ll just note that I have never had an issue with the stable kernel.
I don’t give a shit what kernel anyone runs, but if someone were to specifically ask me, I’d say run the latest stable kernel and install the lts as a “just-in-case” backup.
I have had issues - which is why I recommend LTS first with latest as backup. Caveat for people who know they specifically want latest.
At the end of the day, people should run the kernel they want to. That’s the whole point of being in this specific Linux arena. It’s your computer, make it so.
I think we should forget about the intend and look at the differences, pick the one that suits our needs most. This reminds me my previous desktop CPU Xeon E3-1230 (from 2013/14). The Xeons are intended to be used on servers, but this particular one was excellent choice for desktop as well, as I did not want to overclock and did not need the integrated gpu, but otherwise it is almost identical to the desktop versions. I see the LTS and current version of the Linux Kernel in a similar light.
Jesus Christ, it’s not rocket soyence guys, are you running Arch or just using Arch?!
Haven’t you ever compiled a kernel?
There’s Kernel config…just compare between linux and linux-lts config sources.
linux-ltsIS clearly targeted to servers, it’s not a secret, by it’s own maintainer.
It’s configured in a different way.
For the most part it doesn’t matter for desktop users at all…except preempt which was changed recently.
Decision of being more server targeted comes from Arch linux-lts maintainer, as far as i understand…
It happens more often than you think. However, that isn’t what makes the LTS kernel more reliable.
The problem with any new kernel version is that during the RC period there are a really limited number of people using it. Almost all new kernels ship with significant bugs for some hardware configurations and/or use cases. Sometimes, they only impact a small number of users, other times a large number of users.
The stable kernel also has a short lifecycle. By the time a new stable kernel actually reaches a point where it is solid, it is nearly EOL.
But even that isn’t the only issue. If you run any dkms modules either for hardware or software support, they often don’t work with brand-new kernels. Using the LTS kernel is often the only way to keep your system working.
I just can refer to my personal experience from my specific use case and specific hardware (several Intel and AMD -based machines, no Nvidia), under the past few years and almost exclusively on the latest stable that I cannot recall to have had any issues with the said kernel for me to use LTS even as a backup.
I must have been lucky not having been hit by any issue, not yet anyway.
But also at least during my almost four years on this forum, I cant remember having witnessed any issues with the latest kernel affecting a large number of users. I am not saying it may not happen but I haven’t seen it. What I have seen, it has only been individual cases, specific hardware, specific users etc.
Honestly unless we have some statistics, some figures to show how often and how many people are hit by a kernel regression introduced in the latest stable, we are in the realm of what is possible and not what happens in actuality and how probable is that.
How come the LTS maintainer(s) change configurations, that affect users setup? I always thought this was avoided as much as possible in the Linux sphere. Windows is infamous for this. Wouldn’t it be better if they just made public the new options, and let users decide to use it or not?
LTS was on the Linux “default” setting until an easy, public option became available.
But “default” often only means is has to be set to something. Maintainer decide the configuration for packages all the time. That’s essentially in the job description: put together a script that builds the package according to what’s most appropriate for the audience.
