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

Rocky Linux 8.4 RC1

rockylinux.org

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Rocky Linux 8.4 RC1

#31

Post by mrweasel »

fragbait65 wrote: post #16
mekster wrote: post #15

Earlier quoted context omitted.

And yet, ironically people like it better than CentOS stream? People are making such a big fuss about CentOS getting slightly closer to Fedora.

That's not what this is about. The scientific community cannot run a distribution with "unneeded" updates to libraries. That goes for other organizations as well.

I always found that to be a little weird. Why is scientific projects that dependent on even minor version changes?

Isn’t that normally an indication that there’s something horribly wrong in your code?

Re: Rocky Linux 8.4 RC1

#33

Post by spinax »

spapas82 wrote: post #17

Two questions pop into my mind: A. How easy will it be for the unlucky people that have installed Centos 8 to convert it to rocky Linux? B. Will rocky Linux fulfill its promises? I mean if I install rocky Linux 8.4 will I still have a supported OS at 2029?

> A. How easy will it be for the unlucky people that have installed Centos 8 to convert it to rocky Linux?

The AlmaLinux team (another RHEL8 clone created by CloudLinux in the wake of the CentOS news, already released/available) has created a tool to do the conversion. Rocky should have no problem, if Alma can do it Rocky can do it.

https://github.com/AlmaLinux/almalinux-deploy

Re: Rocky Linux 8.4 RC1

#34

Post by fragbait65 »

mrweasel wrote: post #31
fragbait65 wrote: post #16

Earlier quoted context omitted.

That's not what this is about. The scientific community cannot run a distribution with "unneeded" updates to libraries. That goes for other organizations as well.

I always found that to be a little weird. Why is scientific projects that dependent on even minor version changes? Isn’t that normally an indication that there’s something horribly wrong in your code?

The reason they don't want to do anything other than security updates, and sometimes not even that, is because they need consistency across calculations over time.

This might be a poor example, but lets say an error was found in a computation in a library, for example a rounding error or something, in that case, more often than not, the community will rather live with the known error and have consistency instead.

Re: Rocky Linux 8.4 RC1

#35

Post by mrweasel »

fragbait65 wrote: post #34
mrweasel wrote: post #31

Earlier quoted context omitted.

I always found that to be a little weird. Why is scientific projects that dependent on even minor version changes? Isn’t that normally an indication that there’s something horribly wrong in your code?

The reason they don't want to do anything other than security updates, and sometimes not even that, is because they need consistency across calculations over time. This might be a poor example, but lets say an error was found in a computation in a library, for example a rounding error or something, in that case, more often than not, the community will rather live with the known error and have consistency instead.

Won’t that make reproducing results difficult? I mean it seems like a result won’t be worth much if it’s only reproducable with a specific version of say glibc from five years ago.

Over the cause of one experiment sure, I can see why you’d like to know the calculation are done identically. I just question the validity/usefulness of a calculation that can only be repeated on one version of some library. Surely the overall result should remain the same.

Re: Rocky Linux 8.4 RC1

#36

Post by jabl »

mekster wrote: post #28
fragbait65 wrote: post #16

Earlier quoted context omitted.

That's not what this is about. The scientific community cannot run a distribution with "unneeded" updates to libraries. That goes for other organizations as well.

That's for those who can't pay for RHEL subscriptions and they have such critical experiments going on that getting updates earlier than RedHat screws them up? They can surely opt out of updating automatically and only apply updates after reading the changelogs.

In many cases systems run out-of-tree drivers like Lustre, MOFED, NVIDIA etc. that tend to break due to kernel internal API changes. Yes, also for changes incorporated into minor RHEL releases like X.Y -> X.(Y+1), though not for kernel security updates within a minor X.Y release. At the same time they might need to keep up to date wrt security updates. So if CentOS stream implies that the kernel will randomly get an API-breaking update, with no security support for the previous version, that is not workable.

Re: Rocky Linux 8.4 RC1

#37

Post by nix23 »

viraptor wrote: post #24
nix23 wrote: post #22

Earlier quoted context omitted.

>But I feel for those that don’t want or can’t use Debian based distros. Why? CentOS was already a terrible choice, artificially slow release compared to RHEL, now you can choose from: -OracleLinux (pretty good..and no i don't like oracle itself...but the Wallpaper is extremely beautiful..UEK is cool too) -RHEL (free for up to 16 instances) -That new one with A -That Chinese one with the UNIX certification .....and s…

It's healthy for everyone to have a competition. I want successful Debian even though I'm running CentOS these days. But really, it doesn't look like you're in the market for it. Some solutions welcome slow releases - many users will list that as a benefit. Even more these days with containerised apps.

>It's healthy for everyone to have a competition

Recompile src-files and exchange a branding is not really what i call "competition"

>I want successful Debian

Debian IS successful.

>But really, it doesn't look like you're in the market for it. Some solutions welcome slow releases

That's not what is said nor meant, if for example RHEL 8.2 was released it took CentOS sometimes up to 6 month to release their 8.2 counterpart, in the meantime the newest patch (let's say for OracleDB) is just compatible/certified for 8.2, but you sit for 6 month on a centos 8.1.

But maybe your not in the market of having the latest patch for 3rd party software.

Re: Rocky Linux 8.4 RC1

#38

Post by bluedino »

tambourine_man wrote: post #13

Some vendors that didn’t support Ubuntu now do after the CentOS disaster and I’m much happier now. But I feel for those that don’t want or can’t use Debian based distros.

I would love for my vendors to support Debian but they won’t. Hell, it was hard enough to get them to update their systems to RHEL7 much less move to a totally different distro.

Re: Rocky Linux 8.4 RC1

#39

Post by jabl »

fragbait65 wrote: post #34
mrweasel wrote: post #31

Earlier quoted context omitted.

I always found that to be a little weird. Why is scientific projects that dependent on even minor version changes? Isn’t that normally an indication that there’s something horribly wrong in your code?

The reason they don't want to do anything other than security updates, and sometimes not even that, is because they need consistency across calculations over time. This might be a poor example, but lets say an error was found in a computation in a library, for example a rounding error or something, in that case, more often than not, the community will rather live with the known error and have consistency instead.

Ideally, yes, but in my experience it's more often due to software management processes being, well, non-existent, and whatever exact version that is 'required' is the version that the original developer used and no attention whatsoever has been given to portability or even testing on other versions.

Luckily containers have become quite popular in the HPC world, to isolate such 'tricky' applications from the host OS.

Re: Rocky Linux 8.4 RC1

#40

Post by throw0101a »

mrweasel wrote: post #35
fragbait65 wrote: post #34

Earlier quoted context omitted.

The reason they don't want to do anything other than security updates, and sometimes not even that, is because they need consistency across calculations over time. This might be a poor example, but lets say an error was found in a computation in a library, for example a rounding error or something, in that case, more often than not, the community will rather live with the known error and have consistency instead.

Won’t that make reproducing results difficult? I mean it seems like a result won’t be worth much if it’s only reproducable with a specific version of say glibc from five years ago. Over the cause of one experiment sure, I can see why you’d like to know the calculation are done identically. I just question the validity/usefulness of a calculation that can only be repeated on one version of some library. Surely the ove…

There are always inconsistencies in the scientific world:

* https://en.wikipedia.org/wiki/Fudge_factor

A good portion of experimentalists' time is probably spent in trying to figure just how badly they've messed their experiments as compared to reality. Major discoveries are sometimes based on teasing apart those differences:

* https://en.wikipedia.org/wiki/Muon_g-2

In my EE studies we had a specific course just in examining the limitations of (digital) numbers:

* https://en.wikipedia.org/wiki/Numerical_analysis

* https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...

Post reply on HN