31–40 of 78 posts
Earlier quoted context omitted.
No, you can't do that in RHEL. It would invalidate support.
Seems sad that the modularity of Linux is not allowed due to issues with support. That, in my opinion, is the best part of Linux - which is finding solutions to problems that exists outside of the scope of what is designed by the vendors.
Earlier quoted context omitted.
They feel like they know better and do not want all of the fixes that the LTS kernels provide for some crazy reason. I suggest you contact them if you rely on a RHEL kernel to ask them why they do this, it's always seemed crazy. Note, I'm the person who does the LTS kernel releases, maybe they just don't like me :)
> They feel like they know better and do not want all of the fixes that the LTS kernels provide for some crazy reason. It's even crazier; they sometimes backport changes to their kernel that the LTS kernels don't get. We use a custom kernel module that contains a bunch of #if #endif blocks that check the kernel version for stuff that changed. Doesn't work on RedHat since you actually need the branch that's for more r…
I really hate the fact that RHEL updates kernels so slowly. This becomes very painful when your product cannot take advantage of some advanced kernel features just because you have customers running RHEL :(.
I have my own anecdote: I have serveral home servers running CentOS 7 (set up nearly 6 years ago). I update all the time and I've had zero issues. Literally nothing has ever broken. My previous servers ran CentOS 6, and were equally reliable.
My desktop runs Arch Linux, and gets ever kernel dot release. I've had an unbootable system at least 5 times over the last 5 years, requiring me to boot from a flash drive to downgrade a package, or edit a grub config. As you can imagine, it's bitten me at the worst possible time (when I really don't have time to troubleshoot).
I know some people advocate for Arch on the server, but to me that seems crazy. Nothing against Arch. It's great for a desktop, and I knowingly trade off some reliability/stability for the latest stuff. I wouldn't make that trade on a server that hosted important stuff.
Earlier quoted context omitted.
It could also be motivated by the fact that it's not entirely wise to base an entire multibillion dollar business around whatever text a non-employee happens to push to a repo you don't control.
Android doesn't seem to mind, they require the LTS updates to be taken for their devices (well, "require" is a strong word, they are pushing harder now than they were in the past, "required" will be happening in the future, hopefully...) As the number of systems running RHEL is really just a rounding error compared to the number of Android systems out there, maybe it doesn't really matter :)
Earlier quoted context omitted.
> They feel like they know better and do not want all of the fixes that the LTS kernels provide for some crazy reason. It's even crazier; they sometimes backport changes to their kernel that the LTS kernels don't get. We use a custom kernel module that contains a bunch of #if #endif blocks that check the kernel version for stuff that changed. Doesn't work on RedHat since you actually need the branch that's for more r…
Isn’t the whole autoconf stuff supposed to avoid the need for if macro soup, by using feature detection?
Macros are convenient to quickly check the version in your code without adding another layer of tooling... Until you end up with said macro soup of course.
It's actually a legacy module we're about to phase out for 5.x so don't worry too much. The new and shiny replacement will probably use git branches for whenever something changes.
Earlier quoted context omitted.
It could also be motivated by the fact that it's not entirely wise to base an entire multibillion dollar business around whatever text a non-employee happens to push to a repo you don't control.
Android doesn't seem to mind, they require the LTS updates to be taken for their devices (well, "require" is a strong word, they are pushing harder now than they were in the past, "required" will be happening in the future, hopefully...) As the number of systems running RHEL is really just a rounding error compared to the number of Android systems out there, maybe it doesn't really matter :)
Earlier quoted context omitted.
No, you can't do that in RHEL. It would invalidate support.
Seems sad that the modularity of Linux is not allowed due to issues with support. That, in my opinion, is the best part of Linux - which is finding solutions to problems that exists outside of the scope of what is designed by the vendors.
I really hate the fact that RHEL updates kernels so slowly. This becomes very painful when your product cannot take advantage of some advanced kernel features just because you have customers running RHEL :(.
It can be frustrating, but it's almost always worth it in a serious production environment. I have my own anecdote: I have serveral home servers running CentOS 7 (set up nearly 6 years ago). I update all the time and I've had zero issues. Literally nothing has ever broken. My previous servers ran CentOS 6, and were equally reliable. My desktop runs Arch Linux, and gets ever kernel dot release. I've had an unbootable…
It's understandable that almost every piece of kernel code could potentially be a bad actor thus it would be tough to identify if every fix has security implications or not.
Still there must be a middle ground around common exploitation methods.
Earlier quoted context omitted.
Seems like even Arch maintains it's own kernel. Not uncommon for distros to do it at all.
Wrong, or at the least misleading. What do you mean by 'maintain' here? Because Arch is trying to stay on the bleeding edge side of things in a reasonable manner and is rolling release, they almost stay 1:1 with upstream, "maintains its own kernel" makes it sound like they would do some heavy patching and do active maintenance with certain kernel versions, et cetera. You can have a look yourself if you want to https:…
https://i.imgur.com/jP6Pdvq.png
Also if you look at the diffstat you can see that there were a number of changes here:
https://i.imgur.com/J2em78v.png
It may be align with the majority of the kernel, but these patches exist in every version of the kernel that is released by Arch.
What else could that be called aside from maintaining your own kernel?
These changes are extremely small within scope which is the nature of Arch, but they still exist. A more hands-on distro will see many more changes than Arch, naturally. However, as evidenced from the above you can see that Arch does have it's own kernel and I cited Arch as an example because it strives so hard to maintain 1:1 with upstream.
Btw, I use Arch.
