181–190 of 235 posts
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).
Isn't an unknown vulnerability preferrable to a known vulnerabilty?
>This collection of software will remain locked at its specific version throughout the lifespan of that Enterprise Linux distribution release – which is often 10 years or more. Is this 10 year assumption true? Are people running 10 year old versions of operating systems today in non-safety or non-high security aspects? 10 years ago today is when the following were roughly released: - Linux 3.8. - RHEL 6.4 with Linux…
This whole model is in decline. Most companies have moved to the cloud and are using kubernetes. If you're running servers a datacenter then you might use enterprise linux. You are probably using some kind of virtualization like ESX or Nutanix. You might be using k8s there too. The age of running your own linux servers is ending in a way.
Earlier quoted context omitted.
I didn’t see a particular appeal for trust in the OP. Not mentioning anything about non association would have seemed weirder. Sometimes it’s interesting to read or hear from someone with a high trust score. Other times it’s interesting to read or hear a line of reasoning without - or even negative - trust score. Only going by trust arguably is one of the fundamental problems with tribalism and echo chambers.
You deleted your other comment replying to me, I'm not sure why-- there was nothing wrong with questioning how I initially chose to respond, so I'll paste what I was writing back to you on that topic here: Your original comment said 1) you didn't see an appeal for trust and 2) went on to make broader statements that trust isn't necessarily required when considering an opinion (on it's merits, independently of high/lo…
In friendly dialog, it's quite common to make agreements equally clear to disagreements.
In addition, ghosting your conversation partner's agreed to points is indistinguishable from ignoring points you simply don't have a good retort to. If you were profusely nodding in agreement while reading parts of my comment, that was unfortunately invisible to me.
In addition, my original post had the phrase "particular appeal for trust", followed by the very relevant sentence "Not mentioning anything about non association would have seemed weirder." You also ghosted that in your response.
So you simply ignored my entire larger implication that it's not worth talking about the trustworthiness of the author of the OP, since there's no tangible evidence one way or the other.
That's why I gave up and deleted my prior post.
However I think this is in itself a false premise. The obvious counterargument is that it is newer releases in which new security vulnerabilities are introduced, so after a while, an older release with backported security fixes is more secure.
Which argument is true depends on the relative rates of fixes vs. vulnerability introductions. This will differ per project, and therefore the balance may tip both ways too, depending.
But the article fails to make any assessment of this at all.
Earlier quoted context omitted.
Think of all the places Linux runs. Planes, trains, and automobiles. Medical equipment. So many other places. Many places that don't have readily available network access. Yet, many "enterprises" need support here. If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Considering just the m…
> If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network,…
If you bought a product and the vendor said it will be supported for X years with updates — that’s all you get — X years. If you want to keep using a product for X+1 years, that’s fine, but that’s on you. I agree with your sentiment that hardware shouldn’t be disabled, but I don’t expect security updates past EOL. You can’t expect a business to keep supporting a product longer than they originally said they would (without compensation).
But these are enterprise products… support contracts last a long time. More than enough time to migrate (or past the time when you should be migrating). That’s part of why the long term support exists in the first place.
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…
Think of all the places Linux runs. Planes, trains, and automobiles. Medical equipment. So many other places. Many places that don't have readily available network access. Yet, many "enterprises" need support here. If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Considering just the m…
> 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”.
Earlier quoted context omitted.
But what stops Oracle from just pulling a Red Hat when people switch over to Oracle Linux? Oracle hasn't exactly proven itself to be trustworthy over the years and that's putting it lightly. I think we need a fully open source alternative to RHEL not bound to any company. Something akin to the Debian project that can serve as an upstream reference distro and repository.
Oracle Linux, Red Hat, and Debian are all “fully open source”. What you mean is “not maintained by a corporation.”
Earlier quoted context omitted.
> Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities Ok, I'll be the unpopular person here. Some bugs, even security ones: are ok. I know that a very significant amount of software is mature these days, but sometimes upgrading causes different bugs, which are either harder to diagnose or even potenti…
A known bug beats an unknown update in a whole lot of enterprise use cases. This drives devs insane but it is true.