
Re: Simple fix...
Good one, from Acorn RISC Machine, to: Acorn RISC Silicon Engineering.
553 publicly visible posts • joined 30 Aug 2007
Have something that automatically sucks down all CentOS Stream source packages, and with a developer account grab the RHEL sources, but instead of building them, use them to compare patches with Stream ones. Hopefully if an RPM build version tag matches between Stream and RHEL the patch set is identical so use those version tags to choose which Stream source packages to pick up.
Given their predatory practices I would not touch their Linux with a bargepole, especially at work.
I did experiment with their OEL 8 release on an old Atom box. It ran okay (slow, but it was an Atom), so I tried their Unbreakable kernel. This fell over regularly with illegal instructions, and utterly hosed the RPM database.
Nuked the installation, and installed AlmaLinux 8, and haven't looked back.
At my new employer, we have standardised on AlmaLinux 9.
At my previous employer, Oracle were attempting to shake us down for Java licensing. We screenshotted their slide which showed the cut-off versions of Java, newer versions were chargeable, older ones weren't. Our Linux estate was already OpenJDK as switching to that resolved an issue with the Oracle versions, and Windows was running older versions being compliant with not needing a subscription (and the slide showed us how far we could update to without needing to subscribe). When they then decided to audit us, they were unhappy, as every single Java instance was outside their licensing scheme and they had to admit that we were fine to carry on as we were.
How did that even work? Didn't remap the RAM into the bottom 48K of the machine? Normally on the Spectrum the first 16K is the ROM, and most CP/M (Z80) programs assumed a start address if 0x0100. Unless CP/M programs intended for the Spectrum had to be rebuilt for the odd memory layout.
There is a client (open source, cross-platform) available from the Matrix Brandy developers, which can access some online Viewdata/Videotex and a Teletext service based on Teefax but with additional content not part of the main Teefax service. They also supply standalone builds of the client for Windows and RISC OS, Linux users are expected to build it themselves (or build Brandy and run it from the examples directory!)
It may be useful to know that AlmaLinux's migration script can migrate from Rocky in addition to CentOS and the other RHEL clones, and similarly Rocky's migration script can migrate from Alma in addition to the others.
I don't see that as squabbling over each other's user base but instead a very sensible insurance policy for the users should one or the other go to the wall.
I forward my work phone into a VoIP-in number on my own voip box. On there I have rules that permit calls when on call and during office hours. Out of hours calls route to a dedicated voicemail box with a suitable outgoing message. The big exception is when I am on leave, the calls go to a message telling the caller I'm on leave and to contact my manager if it's important, before dropping the call (no voicemail).
That's a bit mad, they managed to create a yum repo for their Teams on Linux stuff, you'd have thought they could do the same for this, and drop the entry in /etc/yum.repos.d so it would be kept up to date when you patch your OS.
But no, they didn't.
I evaluated the Paragon driver for my then employer, and back then I wasn't entirely impressed. Sure, it was faster than NTFS-3G but it's error checking left a lot to be desired. Point it at a non-NTFS partition? Kernel panic. Hit a bad sector on your hard disc? Kernel panic. We ended up running with NTFS-3G as running slower was preferable to collapsing in a heap at the slightest hint of trouble.
Been there, I typoed the default gateway when remote configuring a new physical server. No ILO or iDrac either. Oops... (Though it wasn't yet live, thank $DEITY).
I was preparing myself to have to take that long journey to the data centre to fix it at the console, when it dawned on me that I had access to another box on the same subnet. Thankfully this worked and I was able to SSH in and sort it from my desk, but that was a really close shave. Almost too close.