0 Followers
0 Following
6 Posts
  • 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…
    Enterprise misery - Lemmy.World

    Lemmy

    There is no way legacy projects are going to switch to Deno. Even when Deno is 100% compatible, the only advantage Deno provides is slightly higher performance. Node’s complexity problem? All those configs needs to be supported for compatibility anyway. Typescript? The project already has tsconfig.json set up, so they might as well continue to use tsx. Security? I bet users will just get tired and use -A all the time.

    To benefit from Deno, Node’s legacy needs to be shed.

    Wine is a different case. The reason Wine makes sense is because Windows is so much worse than Linux that even with scrappy game compatibility, Linux offers a better experience. For Linux users, the alternative to Wine is not switching to Windows, it is not being able to play games. On the other hand, legacy Node projects have a very easy alternative… just continue to use Node.

    And btw Bun is making the same mistake.

    Can Bun Eat Node.js’s Lunch? Testing the Trendy Toolkit

    We tried migrating our trusty Lunch codebase from Node to Bun. Was the transition as smooth as advertised?

    Lab Zero
    Check if there’s any large file in /tmp and /run/user/*?