I'm so looking forward to a RISC future!
I miss my RISC past.
Rocky Linux 10 Will Support RISC-V
31–40 of 138 posts
Re: Rocky Linux 10 Will Support RISC-V
#32Earlier quoted context omitted.
I cannot update the OS per the contract. It’s Ubuntu’s problem because they decide they’re smarter than their users and nuke their repos. Fuck all of that.
It's well publicized that they don't maintain support for old, non-LTS distros. They literally delivered what they promised. Could have been avoided by using an LTS distro. Fedora does the same. No corporate vendor supports 6 month cycle distros for more than a year. RHEL releases come super slowly, for example.
I didn’t have a say in the matter of OS choice, it doesn’t matter how well-publicized Ubuntu’s stance is, it’s wrong. I don’t care if it’s not an LTS, keep the fucking repos open and advertise you’re using an insecure OS. Let me, the user, make that choice. Don’t pretend I’m stupid and need some kind of benevolent dictator to make choices for me, or handicap me because they’re smarter than me. They’re not.
Re: Rocky Linux 10 Will Support RISC-V
#33I 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…
Hi! I'm sorry this has been your experience. I'm one of the Red Hatters who's been working behind the scenes to get this over the finish line.
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).
Re: Rocky Linux 10 Will Support RISC-V
#34Maybe a dumb question but how do non x86 boards normally boot Linux images in a generic way? When I was in the embedded space, our boards all relied on very specific device tree blobs. Is the same strategy used for these or does it use ACPI or something?
All RISC-V consumer boards running Linux also use DT. RISC-V is also working on getting ACPI but primarily for the sake of servers, just like with ARM where ACPI is primarily used for servers (ARM SBBR / ServerReady).
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.
Re: Rocky Linux 10 Will Support RISC-V
#35Earlier quoted context omitted.
It's well publicized that they don't maintain support for old, non-LTS distros. They literally delivered what they promised. Could have been avoided by using an LTS distro. Fedora does the same. No corporate vendor supports 6 month cycle distros for more than a year. RHEL releases come super slowly, for example.
I didn’t have a say in the matter of OS choice, it doesn’t matter how well-publicized Ubuntu’s stance is, it’s wrong. I don’t care if it’s not an LTS, keep the fucking repos open and advertise you’re using an insecure OS. Let me, the user, make that choice. Don’t pretend I’m stupid and need some kind of benevolent dictator to make choices for me, or handicap me because they’re smarter than me. They’re not.
"Keeping the repos open" has a cost on their part. Servers aren't free. If you think you're smart then mirror your own repos.
Re: Rocky Linux 10 Will Support RISC-V
#36Earlier quoted context omitted.
I didn’t have a say in the matter of OS choice, it doesn’t matter how well-publicized Ubuntu’s stance is, it’s wrong. I don’t care if it’s not an LTS, keep the fucking repos open and advertise you’re using an insecure OS. Let me, the user, make that choice. Don’t pretend I’m stupid and need some kind of benevolent dictator to make choices for me, or handicap me because they’re smarter than me. They’re not.
"Keeping the repos open" has a cost on their part. Servers aren't free. If you think you're smart then mirror your own repos.
Really? How much more can it cost to host their LTS and non LTS repos open at the same time?
C’mon, that’s such a weak argument I think you know it.
Re: Rocky Linux 10 Will Support RISC-V
#37I 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…
I have to confess that my early experiences with RedHat as a teenager and dealing with the nightmareish RPM dependencies soured me from the distribution. I went to Debian and then its many descendants and never looked back; APT seemed magical in comparison. I assume they have a package manager that resolves dependencies well now? Is that what an RPM wrangler is?
First impressions really matter. This is also why I went Debian. You shouldn't be getting marked down for saying it.
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.
Re: Rocky Linux 10 Will Support RISC-V
#38Earlier quoted context omitted.
"Keeping the repos open" has a cost on their part. Servers aren't free. If you think you're smart then mirror your own repos.
Really? How much more can it cost to host their LTS and non LTS repos open at the same time? C’mon, that’s such a weak argument I think you know it.
If there's no cost in time, effort or equipment then mirror it yourself. It's easy, right?
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...
Re: Rocky Linux 10 Will Support RISC-V
#39I 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…
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 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.
Re: Rocky Linux 10 Will Support RISC-V
#40Maybe a dumb question but how do non x86 boards normally boot Linux images in a generic way? When I was in the embedded space, our boards all relied on very specific device tree blobs. Is the same strategy used for these or does it use ACPI or something?
The x86 platform uses a plethora of platforms services under different names like UEFI/ACPI/PCI/(ISA plug-n-play back in the day)/APIC (programmable interrupt controller and evolved variants thereof)/etc. that allows the generic kernel to discover what's available when it boots and load the correct drivers.
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.