Skip to main content ↑ ↓
Topic: kernel update policy (Read 3253 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

kernel update policy

How does artix handle kernel updates? Since every patch-level release should be treated as a security update, I'd like to know, if artix trys to keep the delay from source release to publishing the build at minimum. Is there a maximum duration, that artix trys to stay below?

When does the lts kernel jump to the next stable? After EOL?

It would be nice to have this info on the wiki.

Re: kernel update policy

Reply #1 –
My lack of spare time forces to only do even linux kernel numbers.
On top of that, I am actually not so keen on such rapidly moving kernel versions as on arch.
Effectively, kernels on artix follow a more "semi rolling" release.

There is currently a linux-5.1.7 in goblins built against gcc-9.1 and added bcache fix patch.
https://bugs.archlinux.org/task/62730?project=1&string=gcc

If someone in here uses bcache, I would be interested in feedback.

I certainly would not opppose a dedicated artix kernel maintainer, which gave me more time for other stuff.

Re: kernel update policy

Reply #2 –
The only thing I would recommend is that when a certain kernel is followed for sometime and it is not lts that the last issued version is built as well.  I don't necessarily think that even every three editions would be bad, and I think if there is a major fix it should take priority over many little fixes, like if the first is 5.2.3 and the next is 5.2.7 but a major fix was on 5.2.8 then it should be applied.

For some reason my machine run really well with 4.20, I have no idea what it is, 4.19 is good, 5.0 it felt like it was choking on something booting up, 5.1 is a little better.  I wish I had a more final version of 4.20 but you guys left it 3 versions back I think and jumped into 5.0.  I know that major security fixes are not applied on abandoned non-lts kernels.

I guess for more specific versions we can trust arch (it became a little worrisome for a while with their commitment to enable speck).

Re: kernel update policy

Reply #3 –
@artoo since you were there in the past, Manjaro seems to do alot of kernel work, they built versions and follow each kernel exhaustively and also built variations of the same kernel with different patches, would you recommend borrowing kernels from them?  The only other distribution that is doing day to day kernel work is void.  You can get sick and tired of constantly downloading new versions of kernels, especially if you have a slow connection.

Re: kernel update policy

Reply #4 –
@artoo
That bcache sounds like something you would implement into one of those sshd hybrid drives. But then again i suppose with todays needs having the system run on ssd with storage on rust/spin drives is a thing, even separate drives not hybrid drives. Interesting anyhow.

Re: kernel update policy

Reply #5 –
Quote from: fungalnet – on
@artoo since you were there in the past, Manjaro seems to do alot of kernel work, they built versions and follow each kernel exhaustively and also built variations of the same kernel with different patches, would you recommend borrowing kernels from them?  The only other distribution that is doing day to day kernel work is void.  You can get sick and tired of constantly downloading new versions of kernels, especially if you have a slow connection.
I would not recommend Manjaro Kernels they are very buggy some are just alpha, Arch kernels are solid released when they are announced stable and very vanilla.
 Remember every patch has a downside so you have to start patching other parts then start patching the patches then you have Ubuntu

Re: kernel update policy

Reply #6 –
This is why I asked, I thought @artoo would know from the inside of M' what went on.
I didn't know, I briefly used them when I was using M-OpenRc.   I can't remember whether it was 4.13 or 4.15 when it came out, for at least 3 or 4 versions it didn't work for me at all, and all the reporting I did met no-response what so ever.  It was the only kernel I used in any linux ever that screwed up so bad.  But they had variety, including many RT kernels, which I tried but had no real need for them.

Thanks for the clarification @mandog

Re: kernel update policy

Reply #7 –
Personally, I would rather stay on a stable kernel release for a longer period of time.  I am sick of rebooting boxes.
 

Re: kernel update policy

Reply #8 –
I know that this post been inactive for a good while, but as we tend to get a bit sad about reboots, so why shouldn't Artix start to look at having the LTS kernel with kGraft updates, then we could have kernel updates without rebooting the computer at all (in most cases), but that would also require that kernel modules would be prebuilt for the LTS like virtualbox.

I think this would make Artix also more attractive for more users as this is a service that mainly been offered only to enterprise users.