131–138 of 138 posts
Red Hat announced RISC-V yesterday with RHEL 10. So this seems rather expected. https://www.redhat.com/en/blog/red-hat-partners-with-sifive-...
[1] What's new in Debian 13:
https://www.debian.org/releases/trixie/release-notes/whats-n...
Earlier quoted context omitted.
We've actually been working with Fedora and RH on RISC-V for over a year now :)
Still, past sins and all that. Not too mention the model and the directions from those at the top. Great I always applaud contributions and I want to encourage it. But please see the damage done by some quite senior persons on the project and please distance yourselves from them.
As one of the founders of the project, I don't think I'll distance myself from myself.
Earlier quoted context omitted.
As I mentioned in another comment on this thread: > As an aside, that kABI guarantee only goes so far. I work in HPC/AI, and the out-of-tree drivers we use like MOFED and Lustre drivers would break with EVERY SINGLE RHEL minor update (like RHEL X.Y -> X.(Y+1) ). Using past form here because I haven't been using RHEL for this purpose for the past ~5 years, so maybe it has changed since although I doubt it. I'm not sur…
I work on Lustre development. Lustre uses a lot of kernel symbols not covered by the kABI stability guarantee and we already need to maintain configure checks for all of the other kernels (SuSe, Ubuntu, mainline, etc) that don't offer kABI anyway. So in my opinion, it's not worth the effort to adhere to kABI just for RHEL. Especially when RHEL derivatives might not offer the same guarantees. DKMS works well enough, e…
> Especially when RHEL derivatives might not offer the same guarantees.
They do not, as you likely have experienced.
> Honestly, I'm not sure who kABI is even designed for.
You make it work once, using the accepted kabi's and then not have to worry about updating your drivers (You likely know this).
Some customers and systems are very change adverse, almost any change is too much for them.
Earlier quoted context omitted.
Disclaimer: I'm very involved in the kernel part of this for $company. The RHEL kernels themselves do see many improvements over time, the code that you'll see when the product goes end of life is considerably updated compared to the original version string that you see in the package name / uname -a. There are customer and partner feature requests, cve fixes and general bug fixes that go in almost every day. The fir…
What if, more than a rolling kernel, we get a new kernel every two years or so? Or maybe one in the middle of the (expected) lifetime of the major release ? Just thinking out loud, but I acknowledge that maintaining a kernel version is no small task (probably takes a lot of engineering time)
This idea has been floated internally, thank you voicing this idea from the customers perspective.
It seems like the business unit believes the better idea is to just release another version. I'm not sold on more frequent releases, but I'm not in a decision maker in that area.
I understand why people use RH and Rocky and even Oracle: the rpm wranglers. However its not for me. My earliest mainstream distro was RH when they did it just for fun (pre IBM) and then I slid slightly sideways towards Mandrake. I started off with Yggdrassil. I have to do jobs involving RH and co and its just a bit of a pain dealing with elderly stuff. Tomcat ... OK you can have one from 1863. There is a really good…
> Tomcat ... OK you can have one from 1863. There is a really good security back port effort but why on earth start off with a kernel that is using a walking stick. Because old software is battle-tested and reliable. Moreover, upgrading software is ever a pain so it's best to minimize how often you have to do it. With a support policy of 10 years, you just can't beat RHEL (and derivatives) for stability.
But the world around you does not wait for you, and keeps moving
Want it or not, you move with it
And thus, you are not stable
10y operating system is a joke
Earlier quoted context omitted.
Even better title: Rocky will take the RHEL work and rebrand and sell the boards at a discount from China and claim a win and that they're being attacked by IBM.
We've actually been working with Fedora and RH on RISC-V for over a year now :)
Earlier quoted context omitted.
What if, more than a rolling kernel, we get a new kernel every two years or so? Or maybe one in the middle of the (expected) lifetime of the major release ? Just thinking out loud, but I acknowledge that maintaining a kernel version is no small task (probably takes a lot of engineering time)
> Or maybe one in the middle of the (expected) lifetime of the major release ? This idea has been floated internally, thank you voicing this idea from the customers perspective. It seems like the business unit believes the better idea is to just release another version. I'm not sold on more frequent releases, but I'm not in a decision maker in that area.
I want to reiterate that this is not a super strong pain point for me.
Overall i still like RHEL very much!
Earlier quoted context omitted.
Disclaimer: I'm very involved in the kernel part of this for $company. The RHEL kernels themselves do see many improvements over time, the code that you'll see when the product goes end of life is considerably updated compared to the original version string that you see in the package name / uname -a. There are customer and partner feature requests, cve fixes and general bug fixes that go in almost every day. The fir…
As I mentioned in another comment on this thread: > As an aside, that kABI guarantee only goes so far. I work in HPC/AI, and the out-of-tree drivers we use like MOFED and Lustre drivers would break with EVERY SINGLE RHEL minor update (like RHEL X.Y -> X.(Y+1) ). Using past form here because I haven't been using RHEL for this purpose for the past ~5 years, so maybe it has changed since although I doubt it. I'm not sur…
If companies talked to partner engineering about their kABI requirements, I think there would be a lot less breaking however I'm sure that i'm oversimplifying the reason that they cant or wont do this.
I completely understand that the work is non-trivial and that they have many environmental pressures that affect their choices. The KABI is the olive leaf, they can take it or not.