xylan

@xylan@kbin.social

Este perfil es de un servidor federado y podría estar incompleto. Explorar más contenido en la instancia original.

xylan,

I'm always amazed that any foreign government handling sensitive information or dealing with defence would consider using windows. Linux has been competent for all common tasks for a long time now and won't hold any hidden surprises.

AlmaLinux gives up being 1:1 RHEL compatible (almalinux.org) en

In case you missed it, Red Hat announced they will no longer be providing the means for downstream clones to continue to be 1:1 binary copies of Red Hat Enterprise Linux (RHEL). Very quickly, both Jack and I shared some initial thoughts, but we intentionally took our time deciding the next right step for AlmaLinux OS. After much...

xylan,

I don't think this will be viable for the people who really are looking for direct RHEL compatibility, but lots of people like me just use the basic structure of RHEL because we're familiar with the config locations and tooling, and we like the stability over time. If Alma can replicate that aspect then it's still good for me even if they're not bug for bug compatible. Rocky still seem to be going for 100% compatibility and I think that will be harder to maintain over time if RedHat actively fight it.

xylan,

To be fair, the transfer from Cebtos8 to Alma couldn't have been easier. Just ran a script to update the RPM sources and a dnf update and we were done.

Moving to a different distro with different package managers and filesystem layout is a whole other level of hurt.

xylan,

Indeed - the test seemed to be largely determined by our susceptibility to headline grabbing language rather than by being able to judge the content of the article. People are always going to try to have enticing headlines, but you can only really judge the quality of the information by reading the article itself.

Open source developers - have the recent moves by RedHat changed your opinion of using non-GPL licenses? (kbin.social) en

The new license terms for RHEL are structured to stop subscribers from exercising their rights under the GPL. For now they are still providing source code albeit in a less convenient form, but technically they only need to do this for GPL licenses packages and they could remove code for BSD /MIT / Apache licensed packages....

xylan,

The legal loophole RedHat found I'm guessing is something that might trigger GPLv4 to stop this behaviour (effectively punishing someone for exercising their GPL rights).

You're right that most use of OSS doesn't involve modification so it doesn't really matter, but packaging changes are still useful.

I know Stallman was the strongest advocate of the GPL but personally I like the principle of reciprocity which it enshrines. For all of their contributions it's important to realise that companies like RedHat are very much building on the work of OSS developers.

xylan,

I'm still in two minds about this. We have a lot of infrastructure build on RHEL rebuilds and there's no way we're buying enough RHEL licenses to cover it.

I can look at Devian based alternatives but switching is going to be a time consuming process. If Alma and Rocky get this figured out then I'm still tempted to stick where I am. These distributions have been very stable, and I don't need support for them. Even if RedHat don't like this I'm fine with doing it on the basis that they have an obligation to release the source (at least for GPL code).

xylan,

It's a bit more than that unfortunately. Changes in conf file location, selinux Vs apparmour etc. There are a lot of little things which can catch you out if you're building something relatively complex.

CentOS Stream for HPC work? (kbin.social) en

I've been running an HPC system for a science group for a while now and have built a couple of different systems based on common HPC infrastructures (ROCKS or Open HPC). These have been built on top of the rebuilt RHEL distros (mostly CentOS), but I don't really need the level of stability that these provide and would actually...

xylan,

The lack of stability is actually quite attractive to me. In a scientific environment we're normally running fairly new, often unstable code, and we often hit problems because of using older versions of libraries / packages / compilers, so somthing which stays a bit more current would be good and we can deal with breakage if it happens. The trouble is the management systems around HPC assume you're working on enterprise systems, which isn't really true in our case.

I've looked at things like OpenHPC but they're still on RHEL8 (RHEL9 is in testing but not released yet), and even lower level tools like warewulf is still only supporting RHEL8 at the moment which is getting too old for me to want to build a new system from it.

I've looked at more generic tools like Ansible and Chef / Puppet but before I go down that rabbit hole I'd like a sanity check that there isn't something more suited that I'm missing.

xylan,

Yeah, conceptually I like it. A while back I used to run my systems on Fedora which was great in that I always had the latest of everything, but doing updates every 6 months got tedious. Stream seems like a good compromise on the way to that.

xylan,

I'm not clear what this means for distros like Alma or Rocky which used to rebuild the SRPMs that RedHat made available. Are they now dead in the water, or is there a more indirect way for them to get to the code. It looks like the CentOS Stream repository will have all of the code released by RHEL but it's going to take a lot of work to find and extract those packages from the ongoing development, so that's likely going to difficult if not unfeasible.

This is going to be a huge pain to anyone using these distros - it's fine to say we should all move to Debian based distributions, but that sort of migration takes time and planning. If this is implemented immediately then you're going to see a ton of unpatched systems around as existing distros lose support.

xylan,

It looks like the downstream rebuilders are already working on this and are able to extract (with a bit more work) the information they need from the stream repo. How much Redhat tries to block these approaches remains to be seen, but if they can work around this so quickly then it seems a pretty petty stunt to pull.

https://almalinux.org/blog/impact-of-rhel-changes/

https://rockylinux.org/news/brave-new-world-path-forward/

xylan,

Snaps are a nightmare. I've been using a VNC based remote setup for ages for our online training. In the latest ubuntu LTS there's a bug where applications installed via snaps don't trigger the appropriate cgroup permissions when running under VNC so you can't launch any of those applications. The bug is reported, verified and well described but no one from Canonical seems to be interested in applying a fix. I've ended up having to install a browser from the main Firefox site because I literally can't get the snap installed version to run any more.

xylan,

Does this mean that X11 builds will work better than they currently do? Firefox has been unusable over remote X11 for quite a while now due to the way it renders its main display. The amount of traffic it generates when sending remote X events is so large that the interface is practically unusable. If they're now partitioning Wayland support from X11 and are making the X support compatible with remote X then I'm all for this!

  • Todo
  • Suscrito
  • Moderado
  • Favoritos
  • •
  • random
  • noticiascr
  • CostaRica
  • Todos las revistas
    •