Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's wrong with enterprise Linux

unix.foo

Post reply on HN
Print view View original

21–30 of 235 posts

Re: What's wrong with enterprise Linux

#21

Post by Tainnor »

gjsman-1000 wrote: post #6
CrampusDestrus wrote: post #4

Holy.... that Oracle linux page is so friendly it almost makes me puke. I can't believe anyone would fall for them

The same company that just two weeks ago was sending out unsolicited emails asking companies about Java licensing - a friendly shakedown for using the official JRE... https://news.ycombinator.com/item?id=36599118 Frankly, I don't get it Oracle. I would say the priorities are backwards - JRE free, Oracle Linux paid would make more objective sense (especially because the JRE used to be free... and there's a lot of free…

> Also, don't be stupid enough to download the VirtualBox Extensions package at work; or your work will probably get an email from a licensing agent.

Place I used to work blocked the virtualbox home page because exactly this had happened.

Re: What's wrong with enterprise Linux

#22

Post by picozeta »

darkhelmet wrote: post #7

There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to b…

How is the problem of TLS certificates related to Redhat Linux or Enterprise Linux? I think these are orthogonal problems.

Re: What's wrong with enterprise Linux

#23

Post by bonzini »

derekp7 wrote: post #13
darkhelmet wrote: post #7

There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to b…

Don't you end up with the same problem with the automation that has been running fine for 5 years, then suddenly breaks? And the person that set it up is either gone, or has no clue how they did it 5 years ago.

The idea is that you deploy from scratch all the infrastructure every 6 months, first to testing and then to production.

Re: What's wrong with enterprise Linux

#24

Post by U2EF1 »

derekp7 wrote: post #13
darkhelmet wrote: post #7

There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to b…

Don't you end up with the same problem with the automation that has been running fine for 5 years, then suddenly breaks? And the person that set it up is either gone, or has no clue how they did it 5 years ago.

LE by default successfully ran 2 months prior. 2 months and 5 years are two completely different worlds in terms of bit rot. That and there are many generic tutorials and scripts and knowledgeable devs for configuring LE fresh.

Re: What's wrong with enterprise Linux

#25

Post by myself248 »

darkhelmet wrote: post #7

There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to b…

Likewise, it's been suggested that the 19.6-year (1024-week) GPS epoch is pessimal. Rollover is infrequent enough to be ignored, but frequent enough to actually happen and cause problems.

Folks who know such things better than I do, have suggested that it would've been far better at like a 64-week rollover (or just chop it to 52 and leave part of the code space unused), that way everyone would have to have a plan for it. Nobody could claim they don't expect their hardware to be in use 64 weeks in the future therefore they can ignore rollover.

Re: What's wrong with enterprise Linux

#26

Post by picozeta »

gjsman-1000 wrote: post #3
mbreese wrote: post #2

> The Case for Oracle Linux I did not see that twist coming. Strangely, the author makes a good point. Oracle or not, sticking closer to the upstream kernel is not a bad way to manage an “enterprise” kernel. Maybe we’ve all been too willing to sit back and accept how RHEL does kernels as “the way”.

I actually did really like the point; but I would be very interested in hearing a rebuttal or counterargument from Red Hat. Linus' "security problems are just bugs" approach has been worrisome.

> Linus' "security problems are just bugs" approach has been worrisome.

Aren't they?

Re: What's wrong with enterprise Linux

#27

Post by secabeen »

TheIronMark wrote: post #18

If you have to run an "Enterprise Linux", you are probably required by regulations or compliance to have a support agreement in place. Whether it's RedHat or Oracle or something else, security is going take third place to compliance and stability.

Not necessarily. RHEL-clones are ubiquitous in high-performance computing. Clusters and super-computers are hard to setup, consist of hundreds or thousands of nodes, and are used by scientists who are not programmers by trade. The RHEL-clone model works well for them, as they can't expect their users to keep code up to date with changes in the OS, they are used by known, mostly-trusted users, and the systems they run on usually stay fixed their 5-10 year lifespan. Having a single supported OS for the entire lifetime of the system saves a lot of work.

Re: What's wrong with enterprise Linux

#28

Post by dboreham »

azlev wrote: post #8

What's not clear to me is that newer software is safer or just less tested. Although it's possible that newer versions are more secure, I couldn't find evidence of it yet. (Links are welcome).

Probably more of an ass-covering situation: bugs are known in older software and not doing something about a known risk is obviously bad. otoh not mitigating an unknown and unidentified risk (bugs in new software) is ok.

Re: What's wrong with enterprise Linux

#29

Post by thesuperbigfrog »

darkhelmet wrote: post #7

There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to b…

>> I'd like to see the RHEL stability model go away too and force people to complete their automation and solve the problems of being able to rebuilding on demand - and actually doing it.

So how could this be accomplished?

A Nix-OS style approach coupled with an immutable OS core?

It is much harder to offer stability guarantees than to just publish updates in a rolling release fashion. And yet big organizations pay big money for that stability or the support to poke an enterprise software provider to get stuff working for their needs.

Re: What's wrong with enterprise Linux

#30

Post by [deleted] »

indymike wrote: post #5
mbreese wrote: post #2

> The Case for Oracle Linux I did not see that twist coming. Strangely, the author makes a good point. Oracle or not, sticking closer to the upstream kernel is not a bad way to manage an “enterprise” kernel. Maybe we’ve all been too willing to sit back and accept how RHEL does kernels as “the way”.

> Oracle or not, sticking closer to the upstream kernel is not a bad way to manage an “enterprise” kernel. This is probably a lot better than expecting it to be possible to maintain a secure release with a level of compatibility guarantee for 10+ years.

[deleted]
Post reply on HN