71–80 of 138 posts
Earlier quoted context omitted.
I think windows ARM laptops use UEFI?
publicmail was asking about ACPI vs DT, not UEFI. Using UEFI and ACPI/DT are orthogonal; DT-using devices can also boot from UEFI if the firmware provides it. See https://github.com/TravMurav/dtbloader for example.
We use u-boot and it's EFI capabilities to init grub (instead of another instance of u-boot)
Earlier quoted context omitted.
publicmail was asking about ACPI vs DT, not UEFI. Using UEFI and ACPI/DT are orthogonal; DT-using devices can also boot from UEFI if the firmware provides it. See https://github.com/TravMurav/dtbloader for example.
This is explicitly what we're doing in RHEL with the P550. We use u-boot and it's EFI capabilities to init grub (instead of another instance of u-boot)
Earlier quoted context omitted.
Ditto! I haven’t found any hardware that’s daily-driver ready, but I keep looking. 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 workou…
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 :)
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…
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.
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.
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?
Earlier quoted context omitted.
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 implemen…
> 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).
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…
How much of the RHEL kernels is stuff that isn't in Linux mainline or LTS?
Linux longterm often is missing stuff the RHEL kernel has, because RHEL backports subsystems from mainline with features and hardware support.
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?
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.
Earlier quoted context omitted.
Is anyone trying to get those drivers upstreamed?
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…
Earlier quoted context omitted.
> 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.
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,…