Any all-you-can-eat policy is going to attract people who abuse it, and storage isn’t cheap so this isn’t really a surprise. Looking at the limits they’re pretty generous for any real use case and people who need more than that should probably just accept that big storage is going to cost money.
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.
That’s amazing that they would consider auto-generated responses to be appropriate in something which is supposed to be reference documentation. We are a good way from that type of querying and explanation being reliable.
This isn’t what it sounds like. If you go through to the original article then the AI usage is for generative AI which you can add to your meetings (eg generating subtitles). It’s an opt-in service and you’re notified on the call if someone enables it. They’re not just collecting your call data.
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.
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.
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.
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.
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).
Maybe it’s different on Lemmy, but signing up to the fediverse via kbin couldn’t have been easier. Pretty much the same as signing up for any other web site and the federated servers just show up automatically in the search. Once you’re subscribed local and federated communities look pretty much identical.
This is the bottom line. People will go where the content is. A concerted push to populate the fediverse with good content will give people and incentive to migrate. It will be a gradual process but I’m very confident in building a community here.
I mean honestly, those are probably here already - it’s just the scale which will increase. AI is going to mess up a lot of systems where we judge the quality and length of the language to decide how much we trust / believe something.
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.
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.
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!
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.
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.
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.
This has some nice examples of how well large language models do with some fairly basic programming requests
Great to see that there’s an increasing focus on performance.