Live data from Hacker News

Rocky Linux 10 Will Support RISC-V

rockylinux.org

91–100 of 138 posts

Re: Rocky Linux 10 Will Support RISC-V

#91
post #79
post #78

Earlier quoted context omitted.

Yes, and yes. 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 critica…

For MOFED, why not just wholesale use a newer Linux kernel version?

Perhaps the cure is worse than the disease? There are several reasons to stay with a distro kernel:

- 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.

Re: Rocky Linux 10 Will Support RISC-V

#92
post #90
post #80

Earlier quoted context omitted.

Except Linux only took off thanks to those that didn't want to pay for UNIX, and the UNIX vendors that wanted to cut down R&D costs from their own in-house UNIX clones, and were uncertain if BSD was still safe to use with the ongoing AT&T lawsuit.

Re the last part: USL vs BSDi was filed in 1992 and settled in 1994, long before any sizeable vendor paid attention to Linux. (Version 1.0 of the Linux kernel was released at about the same time that lawsuit was settled.) So you shouldn't use that argument as part of your rationale.

I should because perceptions take a very long time to change.

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.

Re: Rocky Linux 10 Will Support RISC-V

#93
post #88
post #41

Earlier quoted context omitted.

> The version and ABI guarantee is not for everyone. 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.

In that boat now, weak-modules means you sometimes get lucky, and can reuse. However, since it's more effort to determine if a rebuild is needed than just slap the "build all the vendor kmods and slurm" button, we tend to build for each kernel. IIRC el8 added kernel symbol signature hashes as Provide/Requires, with automation to extract them at build time, so kmods got a lot easier to deal with.

Sorry, I was being imprecise. Rebuilds per se are no problem, as both MOFED and Lustre provide sources, and DKMS nicely automates rebuilding when installing a new kernel image. The actual problem is that RHEL minor releases would also break kernel internal API's, and thus building the kernel modules would fail.

Re: Rocky Linux 10 Will Support RISC-V

#94
post #21

Earlier quoted context omitted.

Isn’t Ubuntu basically killing apt? 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,…

I've heard many good things about Pop OS. It's like Ubuntu done right, and it does have an apt package for Firefox. (I run Void myself, and stay merrily away from all these complications.)

In Ubuntu, it's also possible to ditch Firefox from the snap store and install it using apt-get. Not from Ubuntu's repo, but from the official Firefox Debian repository:

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.

Re: Rocky Linux 10 Will Support RISC-V

#95
post #30

Maybe 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?

I think windows ARM laptops use UEFI?

looks like they still require a custom device tree to boot Linux

Re: Rocky Linux 10 Will Support RISC-V

#96
post #89

How do they get access to the source code? I read some time ago that RH has changed how they provided the source code and that it was (almost) impossible to get it now?

I don't know where you heard that? The source code for Red Hat's RISC-V developer preview will be released alongside the binaries, on 1st June. However almost all of it is already in CentOS Stream 10 and you can browse it here: https://gitlab.com/redhat/centos-stream There are a few patched packages (and quite a large kernel patch), which is what we'll be releasing into a separate git repo when the developer preview is actually released.

Re: Rocky Linux 10 Will Support RISC-V

#97
post #73

Earlier quoted context omitted.

RISC-V software ecosystem is really good already. It feels like everybody is just waiting for high performance CPU cores now. Sadly silicon cannot be built and released within seconds like software... 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 :)

Or best buy something like https://www.crowdsupply.com/sutajio-kosagi/precursor or some other FPGA-based platform to retain the programmable logic capability, you never know whether you're going to need it, and should you need it after all, it helps knowing it's there.

Love FPGAs, but they're not very practical if you need to run a non-toy Linux on RISC-V. They will typically top out at 100 MHz for the kind of FPGAs that you and I can afford to buy, and have other problems like limited RAM.

Re: Rocky Linux 10 Will Support RISC-V

#98

Earlier quoted context omitted.

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…

Compiling a new kernel was an overnight or even weekend process 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…

Yes, I remember that too. I about a 3 DVD set of Debian Sarge. 2 DVD with everything and the 3rd was about source packages.

Re: Rocky Linux 10 Will Support RISC-V

#99
post #96
post #89

How do they get access to the source code? I read some time ago that RH has changed how they provided the source code and that it was (almost) impossible to get it now?

I don't know where you heard that? The source code for Red Hat's RISC-V developer preview will be released alongside the binaries, on 1st June. However almost all of it is already in CentOS Stream 10 and you can browse it here: https://gitlab.com/redhat/centos-stream There are a few patched packages (and quite a large kernel patch), which is what we'll be releasing into a separate git repo when the developer preview…

I mean in general, you can read it here for example:

https://www.theregister.com/2023/07/10/oracle_ibm_rhel_code/...

Re: Rocky Linux 10 Will Support RISC-V

#100
post #11

Earlier quoted context omitted.

I’d rather use redhat than Ubuntu. I was handed a machine the other week with Ubuntu 23.10 on it, OS supplied from a vendor with extensive customization. Apt was dead. Fuck that. At least RH doesn’t kill their repos.

Well that's just plain incompetent on the part of your vendor. 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.

I think the more apt (pun not intended) comparison would be to macOS? Trying to install macOS High Sierra from the Internet without hackery will lead to "the recovery server could not be contacted" error message, because certificates have expired. Like if your Mac came with High Sierra and you want to do a factory reset.

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.

Post reply on HN