Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rocky Linux 10 Will Support RISC-V

rockylinux.org

Post reply on HN
Print view View original

121–130 of 138 posts

Re: Rocky Linux 10 Will Support RISC-V

#121

Post by LeFantome »

inejge wrote: post #90
pjmlp wrote: 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.

You do not believe that what happened from 1991 to 1995 explains anything about how we got here?

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?

Re: Rocky Linux 10 Will Support RISC-V

#122

Post by LeFantome »

microtonal wrote: post #59
rubitxxx10 wrote: post #18

Earlier quoted context omitted.

I’m old. I used one of the original boxed RH distros. It was cool then. That was almost 30 years ago. 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,…

I’m old. I used one of the original boxed RH distros. It was cool then. That was almost 30 years ago. Does anyone remember glint (graphical UI for RPM) that was part of Red Hat? Must have been Red Hat 4.x or thereabout.

Yes indeed. How about AwesomeWM? Not the one that exists now. The one from Red Hat 4.x or so.

Re: Rocky Linux 10 Will Support RISC-V

#123

Post by LeFantome »

anticodon wrote: post #69
homebrewer wrote: post #60

Earlier quoted context omitted.

This is a very outdated view. dnf runs circles around apt. Try it out, or at least find man pages on the ole 'net and see what it can do. 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 transac…

I had the same experience as the OP in the beginning of the century. I've built a lot of RPM packages back then and it was clear that system of dependencies built into RPM format itself (not apt or dnf, this is dpkg level in terms of Debian) was poorly thought out and clearly insufficient for any complex system. I've also migrated to Debian and it felt like a huge step forward. I'm on Arch now, BTW.

The equivalent of RPM on Debian is the .deb package format. The equivalent of apt is dbf (or yum before it or up2date before that).

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.

Re: Rocky Linux 10 Will Support RISC-V

#124

Post by LeFantome »

speakspokespok wrote: post #37
copperx wrote: post #15

Earlier quoted context omitted.

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…

You are mixing a lot of history there.

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

Re: Rocky Linux 10 Will Support RISC-V

#125

Post by lustre-fan »

jabl wrote: post #45
worthless-trash wrote: post #39

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…

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, especially for something open source like Lustre.

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.

Re: Rocky Linux 10 Will Support RISC-V

#126

Post by lustre-fan »

pabs3 wrote: post #51
jabl wrote: 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.

Is anyone trying to get those drivers upstreamed?

[dead]

Re: Rocky Linux 10 Will Support RISC-V

#127

Post by dismalaf »

dgfitz wrote: post #118
dismalaf wrote: post #115

Earlier quoted context omitted.

Anyhow someone else showed they do indeed host old repos, just in a different place. Also, why can't you update? Who the hell made that contract? And is it the client the said you can't update or Canonical? Because the latter seems sus...

I can see that you’re now realizing, I didn’t have a say in the constraints. I also hate said constraints. Hand I was dealt. Ubuntu is a cancer on the gnu/linux/open source community.

[flagged]

Re: Rocky Linux 10 Will Support RISC-V

#128

Post by icedchai »

bigstrat2003 wrote: post #16
gerdesj wrote: post #10

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.

Many companies never upgrade anything anyway. I once got a job at a startup only to discover they were running Ubuntu 16.04 and python 2.7, in 2022. The dependency situation was also bad. Basically, their stack was so old it had gone past tech debt and into bankruptcy.

Re: Rocky Linux 10 Will Support RISC-V

#130

Post by tucnak »

rwmj wrote: post #97
tucnak wrote: post #73

Earlier quoted context omitted.

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.

Precursor just happens to use Xilinx Spartan 7-class, a 100 MHz VexRISC-V, RV32IMAC + MMU, 4k L1 I/D cache. But these days you could buy Versal devices with 1M+ LUT, and up to 100K DSP slices, in under a thou. However, integrating it—would be the real challenge. The FPGA hardware is sufficient for many non-toy Linux applications; open hardware isn't. This is a gateware limitation, not a hardware one.
Post reply on HN