Discussion on LTS OSes
-
@stacksofplates said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
Security - Hackers | More time to find holes | Less time to find holesThis is a joke right? FIPS mode is validated on the non upstream projects (RHEL/CentOS) and not validated on the upstream. And again, the downstream projects still get patches, security fixes, and actual package updates.
here's all of what FIPS mode does with dm-crypt (this is for 6.2 but it's still valid, I couldn't quickly find the new pdf):
Upstream/Downstream is RH/Suse only. Ubuntu doesn't have this concept. Nor does Windows.
-
@Dashrender said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
The thing about LTS isn't the concept of locking versions, that alone is fine. The issue with LTS is why people lock versions. It's done almost exclusively for two reasons:
- So that software vendors don't have to maintain their software at a reasonable pace.
- So that IT departments don't have to maintain their OSes at a reasonable pace.
Both major reasons, are quite bad. Software vendors like to claim that it is hard to keep software working, and that was the case in the 1980s and 1990s. WIth modern software that is realistically not an issue. But people still think that it is, so they get away with it. Modern software running on Java, .NET, PHP, Python, Go, NodeJS, etc. don't have these problems. Abstractions have made this a moot point. So when vendors don't support current OSes, this tells us that they are avoiding trivial amounts of testing that we would hope that they were doing all of the time anyway.
I'd like to agree with you, but time and time again, we see vendors having a hell of a time keeping up with updates - my EHR can't keep up with Chrome making updates to their browser... it was so bad the vendor started a major project to make their own browser based on Chromium, though undoubtedly they were going to update it only yearly... Luckily their new owners killed that madness!
To bad there's no Chrome ESR like Firefox provides.
-
@stacksofplates said in Linux OS Thoughts?:
FIPS mode is validated on the non upstream projects (RHEL/CentOS) and not validated on the upstream.
That's politics and government. The textbook example of bad IT and bad security. We've covered that they do things badly. That they skip current releases is in no way an indicator of what is good. No one is arguing that LTSs aren't mandated by politics at times, or that bad IT is a thing that people do. The question is "what makes current better" and being better at security, most of the time, is part of that. LTS is stagnant. If you work in software engineering, this is one of those well known principles of how the real world applies to design. Later software is more mature, it's had more developer time. LTS is more time to age, but less time with coders working on it.
-
@Dashrender said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
The thing about LTS isn't the concept of locking versions, that alone is fine. The issue with LTS is why people lock versions. It's done almost exclusively for two reasons:
- So that software vendors don't have to maintain their software at a reasonable pace.
- So that IT departments don't have to maintain their OSes at a reasonable pace.
Both major reasons, are quite bad. Software vendors like to claim that it is hard to keep software working, and that was the case in the 1980s and 1990s. WIth modern software that is realistically not an issue. But people still think that it is, so they get away with it. Modern software running on Java, .NET, PHP, Python, Go, NodeJS, etc. don't have these problems. Abstractions have made this a moot point. So when vendors don't support current OSes, this tells us that they are avoiding trivial amounts of testing that we would hope that they were doing all of the time anyway.
I'd like to agree with you, but time and time again, we see vendors having a hell of a time keeping up with updates - my EHR can't keep up with Chrome making updates to their browser... it was so bad the vendor started a major project to make their own browser based on Chromium, though undoubtedly they were going to update it only yearly... Luckily their new owners killed that madness!
What I don't understand is how that isn't agreeing with me?
-
@Dashrender said in Linux OS Thoughts?:
I'd like to agree with you, but time and time again, we see vendors having a hell of a time keeping up with updates - my EHR can't keep up with Chrome making updates to their browser... it was so bad the vendor started a major project to make their own browser based on Chromium, though undoubtedly they were going to update it only yearly... Luckily their new owners killed that madness!
So it's your EHRs fault for not hiring competent programers to develop their software. Instead someone (or maybe a handful) developed the software who knows how long ago, and an intern has been tasked with updating it every so often.
I'd blame your EHR, not chrome. Would you still be deploying Windows 98 if your EHR said it was the only supported OS?
-
@IRJ said in Linux OS Thoughts?:
The hackers finding holes goes two ways. More time to find holes means better review. Which is the concept of Open Source Software.
That's why I made two line items for that. One shows that hackers have an advantage. One shows that code reviewers have an advantage.
However it is extremely important to remember that having more time to fix holes isn't anywhere close to on par as time to exploit them. It sounds way better than it is in practice. And the biggest holes tend to exist in both LTS and current releases, with current more likely to close them than to open new ones. New ones get opened, for sure, but generally make it into LTS as well.
Refactoring can often close holes that were not known. And in modern software there is often so many layers of this that it might sound like this is unlikely, but when you consider all of the libraries involved and adjunct packages, it's a decently big deal for security.
One of the advantages of open source across the board is a chance to review the code before deployment regardless of current or LTS. LTS does get more review, but not 400% as we might picture. It's more like 50% more, and over a long period of time where it has been already exposed. So the additional review, while good, isn't the huge deal it might sound like.
-
@IRJ said in Linux OS Thoughts?:
S is EoL'd very few people are going to be going back to check for things they've missed in those releases.
I get the point Scott is making with this one"What if we created a new release cycle between LTS and upstream ?"
And that is how a failure gets born, introducing Centos Stream.
Listen if you want latest and greatest you need to have ton of coders working on it.
Btw debian latest stable has php 7.3
and ubuntu only recently got 7.3 in there eoan release, yes debian actually moved faster with version 10 than of Ubuntu 18.04 LTS.So it all depends on the OS vendor and mythodology. which is something you will pick on after you follow the managment of those distros
RHEL = enterprise market, slow and steady and low update releases.
SUSE = SAP focused with enterprise options and wants to be one stop shop for everything
Ubuntu= reinvent all technolgoies the "CANONICAL" wayDebian = sitting idle and silent the quiet guy that has been stable and maybe the best OS ever really, cause the idea and focus of it have not changed for 20 years, it is FOSS OS with sophisticaed package managment and many packages no bloat or marketing.
-
@Emad-R said in Linux OS Thoughts?:
Btw debian latest stable has php 7.3
Debian is an odd duck, though, because it has releases, but no support. So it has nothing like an LTS as it has no support.
-
@scottalanmiller said in Linux OS Thoughts?:
@Emad-R said in Linux OS Thoughts?:
Btw debian latest stable has php 7.3
Debian is an odd duck, though, because it has releases, but no support. So it has nothing like an LTS as it has no support.
Quantify support. I would argue that if I can run something like
apt update -ythat there is support. I know you mean that support can include things like "I can call someone and have them fix it" type options.But you have to quantify these when discussing this sort of thing.
Also fork the thread.
-
@scottalanmiller said in Linux OS Thoughts?:
@Emad-R said in Linux OS Thoughts?:
Btw debian latest stable has php 7.3
Debian is an odd duck, though, because it has releases, but no support. So it has nothing like an LTS as it has no support.
You dont need support when the the distro is focused on one thing to be free and libre and add packages, in Debian there is no agendas, no goals , it is just distro with apt-get that it. I will never use it for desktop (cause it is too plain and basic for that), but for servers that is another story.
-
@DustinB3403 said in Linux OS Thoughts?:
Quantify support. I would argue that if I can run something like apt update -y that there is support. I know you mean that support can include things like "I can call someone and have them fix it" type options.
That's a problem across the board. Support tends to mean certain things to certain people. But Ubuntu LTS I don't actually considered supported at all, what they call "support" isn't enough to qualify for any IT manager I know. LTS is the name, but not what it actually is. It's a middle ground of support considered enough to seem useful, but not enough to be worth the risk if people understood how it worked when something actually fails.
-
@Emad-R said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@Emad-R said in Linux OS Thoughts?:
Btw debian latest stable has php 7.3
Debian is an odd duck, though, because it has releases, but no support. So it has nothing like an LTS as it has no support.
You dont need support when the the distro is focused on one thing to be free and libre and add packages, in Debian there is no agendas, no goals , it is just distro with apt-get that it. I will never use it for desktop, but for servers that is another story.
The argument that scott is making is that Debian isn't in the same category as the others as Debian, itself has never been a focused product like RHEL or Ubuntu focus on their target demographic audience.
-
@DustinB3403 said in Linux OS Thoughts?:
@Emad-R said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@Emad-R said in Linux OS Thoughts?:
Btw debian latest stable has php 7.3
Debian is an odd duck, though, because it has releases, but no support. So it has nothing like an LTS as it has no support.
You dont need support when the the distro is focused on one thing to be free and libre and add packages, in Debian there is no agendas, no goals , it is just distro with apt-get that it. I will never use it for desktop, but for servers that is another story.
The argument that scott is making is that Debian isn't in the same category as the others as Debian, itself has never been a focused product like RHEL or Ubuntu focus on their target demographic audience.
Right, it's an upstream for Ubuntu. A good upstream, but an upstream nontheless.
-
@scottalanmiller said in Linux OS Thoughts?:
@Dashrender said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
The thing about LTS isn't the concept of locking versions, that alone is fine. The issue with LTS is why people lock versions. It's done almost exclusively for two reasons:
- So that software vendors don't have to maintain their software at a reasonable pace.
- So that IT departments don't have to maintain their OSes at a reasonable pace.
Both major reasons, are quite bad. Software vendors like to claim that it is hard to keep software working, and that was the case in the 1980s and 1990s. WIth modern software that is realistically not an issue. But people still think that it is, so they get away with it. Modern software running on Java, .NET, PHP, Python, Go, NodeJS, etc. don't have these problems. Abstractions have made this a moot point. So when vendors don't support current OSes, this tells us that they are avoiding trivial amounts of testing that we would hope that they were doing all of the time anyway.
I'd like to agree with you, but time and time again, we see vendors having a hell of a time keeping up with updates - my EHR can't keep up with Chrome making updates to their browser... it was so bad the vendor started a major project to make their own browser based on Chromium, though undoubtedly they were going to update it only yearly... Luckily their new owners killed that madness!
What I don't understand is how that isn't agreeing with me?
Oh, OK perhaps it is, but my point was - most - MOST vendors suffer this lagging behind issue.... it would be different is most were on the current and always ready to move to current, but that simply isn't the case. At least not for purchased software... All you have to do is look over SW and you'll see all kinds of threads about how xyz isn't supported on Windows Server 2019 yet, etc.. I'm sure the same goes for some software on different Linux OSes.
and I don't mean not supported because they didn't try - but not supported because something is broken. -
@Dashrender said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@Dashrender said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
The thing about LTS isn't the concept of locking versions, that alone is fine. The issue with LTS is why people lock versions. It's done almost exclusively for two reasons:
- So that software vendors don't have to maintain their software at a reasonable pace.
- So that IT departments don't have to maintain their OSes at a reasonable pace.
Both major reasons, are quite bad. Software vendors like to claim that it is hard to keep software working, and that was the case in the 1980s and 1990s. WIth modern software that is realistically not an issue. But people still think that it is, so they get away with it. Modern software running on Java, .NET, PHP, Python, Go, NodeJS, etc. don't have these problems. Abstractions have made this a moot point. So when vendors don't support current OSes, this tells us that they are avoiding trivial amounts of testing that we would hope that they were doing all of the time anyway.
I'd like to agree with you, but time and time again, we see vendors having a hell of a time keeping up with updates - my EHR can't keep up with Chrome making updates to their browser... it was so bad the vendor started a major project to make their own browser based on Chromium, though undoubtedly they were going to update it only yearly... Luckily their new owners killed that madness!
What I don't understand is how that isn't agreeing with me?
Oh, OK perhaps it is, but my point was - most - MOST vendors suffer this lagging behind issue.... it would be different is most were on the current and always ready to move to current, but that simply isn't the case. At least not for purchased software... All you have to do is look over SW and you'll see all kinds of threads about how xyz isn't supported on Windows Server 2019 yet, etc.. I'm sure the same goes for some software on different Linux OSes.
and I don't mean not supported because they didn't try - but not supported because something is broken.This is generally the cause of a dependency software rather than a mind shattering change of the underlying OS. So this is still an issue that the vendor needs to correct, not the OS supplier.
-
@Emad-R said in Linux OS Thoughts?:
You dont need support
While you "almost never need support" with any enterprise OS today. No business will buy the "supportless" model.
-
@Dashrender said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@Dashrender said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
The thing about LTS isn't the concept of locking versions, that alone is fine. The issue with LTS is why people lock versions. It's done almost exclusively for two reasons:
- So that software vendors don't have to maintain their software at a reasonable pace.
- So that IT departments don't have to maintain their OSes at a reasonable pace.
Both major reasons, are quite bad. Software vendors like to claim that it is hard to keep software working, and that was the case in the 1980s and 1990s. WIth modern software that is realistically not an issue. But people still think that it is, so they get away with it. Modern software running on Java, .NET, PHP, Python, Go, NodeJS, etc. don't have these problems. Abstractions have made this a moot point. So when vendors don't support current OSes, this tells us that they are avoiding trivial amounts of testing that we would hope that they were doing all of the time anyway.
I'd like to agree with you, but time and time again, we see vendors having a hell of a time keeping up with updates - my EHR can't keep up with Chrome making updates to their browser... it was so bad the vendor started a major project to make their own browser based on Chromium, though undoubtedly they were going to update it only yearly... Luckily their new owners killed that madness!
What I don't understand is how that isn't agreeing with me?
Oh, OK perhaps it is, but my point was - most - MOST vendors suffer this lagging behind issue.... it would be different is most were on the current and always ready to move to current, but that simply isn't the case. At least not for purchased software... All you have to do is look over SW and you'll see all kinds of threads about how xyz isn't supported on Windows Server 2019 yet, etc.. I'm sure the same goes for some software on different Linux OSes.
and I don't mean not supported because they didn't try - but not supported because something is broken.Right, but what does that matter? That's been covered... LTS exists for software vendors that can't support their own software. We've covered this, it's the foundation of the conversation.
You are missing the conversation that we had, and using the "one problem justifies another" argument. "We chose bad software because we didn't consider whether the vendor could support it" therefore "this makes bad IT practices justified because we ignored that we made the bad decision that got us here."
-
@DustinB3403 said in Linux OS Thoughts?:
@Dashrender said in Linux OS Thoughts?:
I'd like to agree with you, but time and time again, we see vendors having a hell of a time keeping up with updates - my EHR can't keep up with Chrome making updates to their browser... it was so bad the vendor started a major project to make their own browser based on Chromium, though undoubtedly they were going to update it only yearly... Luckily their new owners killed that madness!
So it's your EHRs fault for not hiring competent programers to develop their software. Instead someone (or maybe a handful) developed the software who knows how long ago, and an intern has been tasked with updating it every so often.
I'd blame your EHR, not chrome. Would you still be deploying Windows 98 if your EHR said it was the only supported OS?
You and Scott both missed my point entirely -
I wasn't blaming Chrome - I was simply stating how bad my EHR vendor is - along with most of the environment out there deving software.
As to your 98 question - sadly, if my boss told me to - yep.. but I also likely wouldn't be here is that was the case either.
-
@Dashrender said in Linux OS Thoughts?:
I wasn't blaming Chrome - I was simply stating how bad my EHR vendor is - along with most of the environment out there deving software.
Okay, but how does that work in the conversation? Yes, they are bad. And LTS releases exist to make it easier for them to be bad. And being bad while helping others justify being bad, is bad
-
@scottalanmiller said in Linux OS Thoughts?:
@Dashrender said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@Dashrender said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
The thing about LTS isn't the concept of locking versions, that alone is fine. The issue with LTS is why people lock versions. It's done almost exclusively for two reasons:
- So that software vendors don't have to maintain their software at a reasonable pace.
- So that IT departments don't have to maintain their OSes at a reasonable pace.
Both major reasons, are quite bad. Software vendors like to claim that it is hard to keep software working, and that was the case in the 1980s and 1990s. WIth modern software that is realistically not an issue. But people still think that it is, so they get away with it. Modern software running on Java, .NET, PHP, Python, Go, NodeJS, etc. don't have these problems. Abstractions have made this a moot point. So when vendors don't support current OSes, this tells us that they are avoiding trivial amounts of testing that we would hope that they were doing all of the time anyway.
I'd like to agree with you, but time and time again, we see vendors having a hell of a time keeping up with updates - my EHR can't keep up with Chrome making updates to their browser... it was so bad the vendor started a major project to make their own browser based on Chromium, though undoubtedly they were going to update it only yearly... Luckily their new owners killed that madness!
What I don't understand is how that isn't agreeing with me?
Oh, OK perhaps it is, but my point was - most - MOST vendors suffer this lagging behind issue.... it would be different is most were on the current and always ready to move to current, but that simply isn't the case. At least not for purchased software... All you have to do is look over SW and you'll see all kinds of threads about how xyz isn't supported on Windows Server 2019 yet, etc.. I'm sure the same goes for some software on different Linux OSes.
and I don't mean not supported because they didn't try - but not supported because something is broken.Right, but what does that matter? That's been covered... LTS exists for software vendors that can't support their own software. We've covered this, it's the foundation of the conversation.
You are missing the conversation that we had, and using the "one problem justifies another" argument. "We chose bad software because we didn't consider whether the vendor could support it" therefore "this makes bad IT practices justified because we ignored that we made the bad decision that got us here."
IT in my case was completely not involved in the decision...
