Hacker News new | ask | show | jobs
by gruturo 707 days ago
Enterprises don't go for RHEL because it's free software, yay freedom!

They go for it because it gives a very stable, solid foundation. They don't want a fragile base layer prone to breaking every day of the week.

This involves backporting a lot of stuff (primarily security fixes) because you can't just upgrade any package to its latest version, it will have entirely new dependencies, potentially breaking changes etc.

What should RedHat do, which does not:

1) make them lose their enterprise customers wanting a stable base

2) have unpatched security holes all over their distros

3) not cause them to backport stuff (we are here at the moment) ?

2 comments

Compagnies I've worked for that uses redhat do so because they think paying will prevent them from working. As if, sudenly, running a nearly 10y-old code was no longer stupid, because you paid for it.
> As if, suddenly, running a nearly 10y-old code was no longer stupid, because you paid for it.

I love this

Of course it is stupid, the question is whether you have an alternative that isn't stupid and respects all the regulation/certification requirements.
I wish the places I worked made such principled decisions.

Some places did, but not most. In my 2 decades of contracting I have seen plenty of shops with a real fear of upgrading and no plan for modernizing. They are trapped in decades old tech and prefer it that way for no discernible reason. Worse, they often have no recovery plan if there is a problem. There is a huge amount of maintaining the status quo and trying not to make waves.

For some of these projects a team of like dozen devs could recreate the core product in some new tech in less than a year with the right institutional knowledge. But they don't for a myriad of excuses and reasons.

To be fair, if they couldn't make the decision to use a non-paid distro, would you trust them to be able to manage the updates, the ABI compatibility breakages, and so on once every year or two?
Of course not

But again, paying for the distribution does not free you from the sysadmin duties

Even worse: because of the long "supported" duration, the common mindset is "fire and forget". After all, why would we care ? That stuff will be "supported" for 10 years, we'll be long gone by then. And when you have high turn-over rate, you hit the champion's title : every thing is legacy, nothing is managed, every thing is crap

You give so many good reasons to use RHEL. Less noble, but still good :)
Said compagnies have no regulations nor certifications requirements.
I work in the kernel maintenance group, the "10 year old code" is having select important and critical flaws applied.

If you think about it, all maintained projects of old code has this same mechanism, just has more frequent updates.

How does the age metric now work once you know this ?

I understand the business logic behind that. The point is, maybe they should consider paying the upstream developers to backport the stuff themselves instead of dabbling with C code they somewhat understand?
C isn't magic, plenty of people understand it and lots of these projects move quite slow. That these things CVEs on ssh are so rare shows how well this process normally works. These past couple of weeks have had 3(?) ssh vulnerabilities? We often go years with one, and not all are a result of packaging some come from upstream.

Any new process needs to not just fix this problem, but also all or at least most of the problems that the existing processes fixes.

Tracing thousands of developers across the planet and drafting contracts in hundreds of jurisdictions, including some where you don't even have a branch office or any kind of legal presence? Ugh. And what if one's from an embargoed country? What if a primadonna asks for a million a day, or half of them don't deliver in time, go on holiday, win the lottery, fall in love, get into a dispute, refuse to work with you, don't have access to all the architectures for comprehensive testing, lose interest, change employer (and can't work with you anymore), or sell to some dodgy entity preparing the next sBoM attack.

....better to pay your own people. Hire them if they're available, sure, otherwise task an engineer with this.