It's true that since we've had a usable build root since last 2024, it gives our AltArch group the opportunity to build different kernels to support other SBC's or boards like they already do for ARM SBC's (rasperry pi for example, since that support isn't native to the EL kernel). So while we support the VF2's and QEMU out of the box, that group will handle the additional kernels for more hardware support.
I'm actually looking forward to seeing what other boards the AltArch group will happen to add support for.
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.
https://store.deepcomputing.io/products/dc-roma-ai-pc-risc-v...
I especially like the idea of getting a framework version in this case I want to swap in a different mainboard. By their own admission, the risc-v board is targeting developers and not ready for prime time. Also coming from the US, not sure how the tariff thing will workout…
Better to buy a SBC for now (I can recommend the OrangePi RV2 - it's fantastic!) and wait until actually desktop/laptop-class hardware is ready :)
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 security back port effort but why on earth start off with a kernel that is using a walking stick.
Perhaps I am being unkind but for me the RH efforts are (probably) very stable and a bit old.
It's not the distro itself either. The users seem to have snags with updating it.
I (very generally) find that RH shops are the worst at [redacted]
Try do-release-upgrade.
You also mention "OS supplied from a vendor with extensive customization. Apt was dead."
How on earth is that Ubuntu's problem?
My Ubuntu became unusable because it kept insisting on installing a snap version of Firefox breaking a whole bunch of workflows.
I do want to try a RH based OS (maybe Fedora) so they don’t keep changing things on me, but just where I am in life right now I don’t have the time/energy to do so, so for now I’m relying on my Mac.
Hopefully I can try a new Linux distro in a few months, because I can’t figure it out yet, but something about macOS simply doesn’t work for me from a getting work done perspective.
(I run Void myself, and stay merrily away from all these complications.)
But it is Ubuntu?
https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-d...
I know it's not the best but at least it can be done with little effort.
It’s Ubuntu’s problem because they decide they’re smarter than their users and nuke their repos.
Fuck all of that.
Fedora does the same. No corporate vendor supports 6 month cycle distros for more than a year. RHEL releases come super slowly, for example.
C’mon, that’s such a weak argument I think you know it.
Or just use an LTS distro like literally every single other organization that depends on Ubuntu for their business SMH. Like, it's absurd to even think about...
Ubuntu is a cancer on the gnu/linux/open source community.
You opt into it by changing your repositories to the https://old-releases.ubuntu.com archive mirror. You can install and use Ubuntu 6.10 if you want.
Your contract is with the vendor if you have one. Unless you have a contract with Canonical and then you can ask them for support.
23.10 is not an LTS version and Ubuntu only provide updates for a short period of time (6 months or so after the next version is released), so the vendor should have upgraded it to 24.04 which IS an LTS version.
It's like you're complaining to Microsoft about a vendor giving you an old XP machine and that you can't update it.
Windows from that era still updates. Though up next will be expiration of Windows UEFI CA 2011 which will certainly lead to boot problems for some.
I assume they have a package manager that resolves dependencies well now? Is that what an RPM wrangler is?
There was a lot of competition around package managers back then. For RPM, there were also urpmi, apt-rpm, etc.
Many of us were running on 28.8 dial-up. Internet search was not even close to a solved problem. Compiling a new kernel was an overnight or even weekend process. Finding and manually downloading rpm dependencies was slow and hard. Same era when compiling a kernel went overnight or over the weekend. You didn't download an ISO you bought a CD or soon a DVD that you could booted off of.
Compare that to Debian's apt-get or Suse's yast/yast2 of the time, both just handled all that for you.
Debian and Suse were fun and fit perfectly into the Web 1.0 world; RedHat was corporate. SystemD was pushed by RedHat.
One friend and I had a competition who could make the smallest kernel configuration still functional on their hardware. I remember that at some point we could build it in ten minutes or so. This was somewhere in the nineties, I was envious of his DX2-50.
Compare that to Debian's apt-get or Suse's yast/yast2 of the time, both just handled all that for you.
One of the really huge benefits of S.u.S.E. in Europe in the nineties was that you could buy it in nearly every book shop and it came with an installation/administration book and multiple CD-ROMs with pretty much all packages. Since many people did not have internet at all or at most dial-up, it gave you everything to have a complete system.
Red Hat had packages but not package management at first. However, the same is true of Debian. It depends when you used them.
Red Hat Linux branched into RHEL (corporate) and Fedora (community).
SuSE went down a similar road to Red Hat and has both OpenSUSE and SLE these days. Fedora is less corporate than OpenSUSE is.
Debian is still Debian but a bit more pragmatic and a bit less GNU these days (eg. non-free firmware).
Probably the thing I like the most is transactional installation (or upgrades/downgrades/removals) of packages with proper structured history of all package operations (not just a bunch of log records which you have to parse yourself), and the ability to revert any of those transactions with a single command.
I've also migrated to Debian and it felt like a huge step forward.
I'm on Arch now, BTW.
Red Hat is just old enough to exist before package managers existed on Linux. It was not there at first on Debian either.
Slackware still has not package manager really.
Side-note, the other difference I've noticed is Debian (and presumably its derivatives) has better defaults (and debconf) for packages, so whereas stock config would work on Debian, on Rocky I have to change config files, install missing packages etc.
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.
I know they give back to Linux, and I’m thankful for the enterprises that pay for it because of that.
It’s not a bad company, though it’s strange that you could be a great developer and lose your position there if your project gets cut, unless another team picks you up, from what I hear.
But when Linus created Linux, he didn’t do it for money, and RH just seems corporate to me like the Microsoft of Linux, way back before Microsoft had their own Linux. I want my Linux free-range not cooped.
They don’t do anything wrong. They just don’t give the vibe. Anyone asking for money for it doesn’t “get it” to me.
Does anyone remember glint (graphical UI for RPM) that was part of Red Hat? Must have been Red Hat 4.x or thereabout.
You seem to forget that Red Hat has funded a lot of the development of the Linux ecosystem. There would be essentially no modern linux environment without Red Hat.
I wouldn't use their products for much though, too enterprisey. Their projects are great and I'm happy someone else buys their packages.
If you ask random dev on the street about .NET, there is an high probability they will answer it is Windows only and requires Visual Studio.
Red Hat was founded in 1993. When do you think they got the idea? When do you think companies like Red Hat decided to bet on Linux instead of BSD? Debian was founded in 1993 as well. When was that lawsuit settled again?
An awful lot of the Linux momentum that carries us to this very day appeared after the BSD lawsuit was filed and before it was settled.
What about the other “big and professional” competitor to Linux?
GNU HURD was started in 1990. The original plan was to base it off the BSD kernel. The Linux kernel appeared in 1991. BSD fell under legal threat in 1992. Debian appeared in 1993. RMS lost interest in HURD. None of these dates had much impact you don’t think?
They did not want to pay for big iron for sure, preferring commodity hardware. Even then though, many Linux boxes can get pretty expensive.
I think it is more about openness and control than it is about cost. Linux brings flexibility and freedom.
So does BSD of course. The timing of that lawsuit changed the world.
https://docs.redhat.com/en/documentation/red_hat_enterprise_...
For me it always felt like the system administrators externalizing the cost on the users and developers (which are the same in many cases).
Despite my dislike of enterprise Linux, Red Hat is doing a lot of awesome work all around the stack. IMO Fedora and the immutable distros are the real showcase of all the things they do.
> Despite my dislike of enterprise Linux, Red Hat is doing a lot of awesome work all around the stack. IMO Fedora and the immutable distros are the real showcase of all the things they do.
Fedora today is what RHEL will be tomorrow. They quite literally freeze a Fedora release to use as a base for RHEL's next release. If you like Fedora today you're gonna like Fedora tomorrow.
It's really really great, even if you don't use or plan to use NixOS (Nix was born long before NixOS).
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
I do say my genuine thanks for your earnest expression. The version and ABI guarantee is not for everyone. At the same time some folks around these parts know that I'm "not an apologist for running an out of date kernel". I can assure you that everything shipped in the forthcoming P550 image is fresh. GCC 15. LLVM 19, etc. It's intended for development to get more software over the finish line for RISC-V.
Conflict of interest statement: I work for Red Hat (Formerly CoreOS), and I'm also the working group lead for the distro integration group within RISE (RISC-V Software Ecosystem).
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.
The kernel parts of MOFED are largely backports of the latest and greatest upstream kernel drivers to the various distro kernels their customers actually run. (The non-kernel parts of MOFED is mostly open source but does contain some proprietary special sauce on top, like IIRC SHARP support isn't available in FOSS.). The HPC community does tend to want to use the latest RDMA drivers as those are critical for at scale performance.
For Lustre, the client driver was upstreamed into staging, where it sat AFAIU largely unused for a few years until it was ripped out again. The problem was that Lustre developers didn't adopt an upstream-first development approach, and thus the in-kernel driver was basically a throw over the fence fork that nobody cared about. I think there is an effort to try again and hopefully adopt an upstream-first approach, remains to be seen whether it'll succeed.
- Lustre releases target distro kernels, upstream would likely break.
- Distro stays on top of CVE's etc. and provide updates when needed.
- HW likely certified for a few supported distros only, use anything else and you're on your own.
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 first problem of 'running old kernels' is exacerbated by the kernel version string not matching code reality.
The second probelm is many companies don't start moving to newer rhels when its out, they often stick to current -1, which is a bit of a problem because by the time they roll out a release, n-1 is likely entering its first stage of "maintenance" so fixes are more difficult to include. If you can think of a solution to this, I'm all ears.
The original reason behind not continually shipping newer kernel versions is to ensure stability by providing a stable whitelisted kABI that third party vendors can build on top of. This is not something that upstream and many OS vendors support, but with the "promise" of not breaking kabi, updates should happen smoothly without third party needing to update their drivers.
The kabi maintenance happens behind the scenes while ensuring that CVE fixes and new features are delivered during the relevant stage of the product lifecycle.
The kernel version is usually very close to the previous release, in the case of rhel10 its 6.13 and already with zero day fixes it has parts of newer code backported, tested, etc in the first errata release.
The security landscape is changing, maybe sometime Red Hat Business Unit may wake up and decide to ship a rolling better tested kernel (Red Hat DOES have an internal/tested https://cki-project.gitlab.io/kernel-ark/ which is functionally this ). Shipping this has the downside is that the third party vendors would not have the same KABI stability guarantees that RHEL currently provides, muddy the waters of rhels value and confuse people on which kernel they should be running.
I believe there are two customer types, ones who would love to see this, and get the newest features for their full lifecycle, and ones who would hate it, because the churn and change would be too much introducing risk and problems for them down the line.
Its hard, and likely impossible to keep everyone happy.
> 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 sure what the underlying problem here is, is the kABI guarantee worthless generally or is it just that MOFED and Lustre drivers need to use features not covered by some kind of "kABI stability guarantee"?
Honestly, I'm not sure who kABI is even designed for. All of the drivers I've interacted with the HPC space (NVIDIA, Lustre, vendor network drivers, etc.) don't seem to adhere to kABI. DKMS is far more standard. I'd be interested to know which vendors are making heavy use of it.
> 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.
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.
Linux longterm often is missing stuff the RHEL kernel has, because RHEL backports subsystems from mainline with features and hardware support.
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 want to reiterate that this is not a super strong pain point for me.
Overall i still like RHEL very much!
It's 2025, you can run whatever version you need in containers.
Core system stays static and you do not get blindsided by changes in packages you do not care about. At the same time, you can easily install very up-to-date apps and dependencies if you need them.
We use u-boot and it's EFI capabilities to init grub (instead of another instance of u-boot)
ARM Windows laptops only use ACPI because Windows has no interest in DTs, but under Linux these devices are still booted using DT. I don't know for sure, but the usual reason is that these ACPI implementations are hacked up by the manufacturer to be good enough to work with Windows, so supporting them on Linux requires more effort than just writing up the DT.
More effort then producing unique images for every board?
Then you wouldn't need a unique kernel/OS image. For devices that have u-boot in ROM the DT is usually there (fdt).
ARM servers do the same with SBSA (a spec that mandates things like UEFI, ACPI etc. support) etc. I think there's some effort in RISC-V land to do the same, also using UEFI and ACPI.
[0] Supervisor Binary Interface
https://www.theregister.com/2023/07/10/oracle_ibm_rhel_code/...
A lot of RISC-V support was already in F40 (which EL10 is cut from), so the rest was largely backporting and integrating into RHEL, which again, we've been tracking since CentOS Stream 10 was branched from Fedora last year.
audidude•6mo ago
https://www.redhat.com/en/blog/red-hat-partners-with-sifive-...
teleforce•6mo ago
[1] What's new in Debian 13:
https://www.debian.org/releases/trixie/release-notes/whats-n...