4. Struggle to come to a conclusion on what to do with the EOL OS because of internal political factors and the reality of how enterprise works.

This is the involuntary choice. If you cannot choose from the first three, you end up implicitly choosing the fourth.

I understand how it feels.

The only way that will work is to somehow quit and rejoin as a much more highly paid consultant and enable them to upgrade EOL software in prod. I am actually considering this.

There is something you need to know about collective wisdom; the larger the org is, the lower it gets. Yes the application works on Alma 8 and 9, but the management says ‘no’.

Any large enterprise still running RHEL 5 in Prod (or even, yes, older RHEL versions) has fully accepted the risks

It is more like ‘involuntarily end up riding the risks of using unsupported old software’. RHEL 7 and RHEL 5 are in the right order.

RHEL sells an unrealistic expectation that you don’t need to worry about the OS for another 10 years, so the enterprise gets designed around it and becomes unable to handle an OS upgrade, ever.

I am not. I worked hard to make our application support RHEL 8 and then RHEL 9. And then the politics takes over and the big wigs start an extended bickering over who should pay for the OS upgrade… which never happens. Sometimes hardware partners don’t support the upgrades, which means OS upgrades also end up requiring new hardware.

I blame Redhat.

…hope…

We test our code locally, but we cannot test the workflow. By definition, testing the workflow has to be done on a CI-like system.

There is nektos/act for running github actions locally, it works for simple cases. There still are many differences between act and github actions.

It might be possible for a CI to define workflow steps using Containerfile/Dockerfile. Such workflows would be reproducible locally.

Time for the yearly barrage of “Setup CI”…“Fix CI” commits.

That is my experience with basically every CI service out there.

Never tried that, though a quick search got me this: https://superuser.com/questions/1471937/how-can-i-add-a-bcd-boot-entry-for-linux-in-windows-boot-manager-in-efi

Windows will not boot with this method. By renaming the file back to bootmgfw.efi windows will boot again but now linux won’t boot. There is no clean solution, other than switch to different computer that doesn’t have this issue. Because of issues like this I don’t recommend dual booting. Installing only Windows or only Linux is more manageable for not-tech-savvy people.

In windows EFI partition, there will be an EFI/Microsoft/bootmgfw.efi file, I usually rename it to bootmgfw.efi.bak and that allows grub to load.

I have observed that many laptops are hard-coded to boot windows whenever possible. Even with windows bootentry missing, firmware will skip Grub set to first priority and start windows. Only way to make them start Grub is to rename bootmgfw.efi to a different name.

1. It might be a card grabber.
2. Don’t put real card details of course.

It wants you to put dummy details as fast as you can.

It is a game, but it might also be a card grabber.

I did not make this, and you’re supposed to put dummy details there. Don’t put actual credit card information.

For me the value of podman is how easily it works without root. Just install and run, no need for sudo or adding myself to docker group.

I use it for testing and dev work, not for running any services.

No… too hard.