Discussion on LTS OSes
-
@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...
-
@Dashrender said in Linux OS Thoughts?:
@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...
Whoever makes the decision, is IT. IT isn't a title, it's an action.
-
Think of it like driving a car. You can call the passenger a chauffeur. But the driver is the one turning the wheel, regardless of their title.
-
@scottalanmiller said in Linux OS Thoughts?:
@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.
Yeah see you say that but literally everyone else views SCAP settings as good security. Even the people who make the software....
The proof is in the pudding. Red Hats own hardening guide for Fedora is about 5% as large as RHEL/CentOS. And it's not because they are that drastically different.
-
@scottalanmiller said in Linux OS Thoughts?:
@stacksofplates said in Linux OS Thoughts?:
LTS, by definition, gets patched. But as we've proven with Ubuntu, not fully patched.
So you picked one bad vendor to try to prove your point. That doesn't invalidate all of the others that do patch. And no you never proves that. You only stated it, which is obviously not proof.
-
@stacksofplates said in Linux OS Thoughts?:
Yeah see you say that but literally everyone else views SCAP settings as good security. Even the people who make the software....
But I'm unclear how that goes against what I said. That's not a counter argument. That the government "can" sometimes produce something good or "seen as good" isn't in dispute.
SCAP could be pure gold, but if applied to a bad product, not be the best decision. SCAP being good, great, even amazing, doesn't logically have anything to do with LTS vs current support or release models.
@stacksofplates said in Linux OS Thoughts?:
The proof is in the pudding. Red Hats own hardening guide for Fedora is about 5% as large as RHEL/CentOS. And it's not because they are that drastically different.
That's not pudding, though. RH makes money only on RHEL, RH is a business. That RH chooses to do what is profitable doesn't even begin to suggest where good models for end users is.
This is like saying that McDonald's sells Big Macs, McD's is a big company, therefore Big Macs are healthy food. It's not logical. McD's sells what people want to buy. That's their job. RH sells the software people want to buy. Neither action is suggestive of what is good for us to purchase or use.
-
@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?:
@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...
Whoever makes the decision, is IT. IT isn't a title, it's an action.
yeah yeah -
-
@stacksofplates said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@stacksofplates said in Linux OS Thoughts?:
LTS, by definition, gets patched. But as we've proven with Ubuntu, not fully patched.
So you picked one bad vendor to try to prove your point. That doesn't invalidate all of the others that do patch. And no you never proves that. You only stated it, which is obviously not proof.
I proved it to the point that it's Canonical's official stance. If it comes to that, you can't prove anything else. I at least got to the point of the vendor making it their support position. It's the most official thing that there could be.
-
@scottalanmiller said in Linux OS Thoughts?:
@stacksofplates said in Linux OS Thoughts?:
Yeah see you say that but literally everyone else views SCAP settings as good security. Even the people who make the software....
But I'm unclear how that goes against what I said. That's not a counter argument. That the government "can" sometimes produce something good or "seen as good" isn't in dispute.
SCAP could be pure gold, but if applied to a bad product, not be the best decision. SCAP being good, great, even amazing, doesn't logically have anything to do with LTS vs current support or release models.
@stacksofplates said in Linux OS Thoughts?:
The proof is in the pudding. Red Hats own hardening guide for Fedora is about 5% as large as RHEL/CentOS. And it's not because they are that drastically different.
That's not pudding, though. RH makes money only on RHEL, RH is a business. That RH chooses to do what is profitable doesn't even begin to suggest where good models for end users is.
This is like saying that McDonald's sells Big Macs, McD's is a big company, therefore Big Macs are healthy food. It's not logical. McD's sells what people want to buy. That's their job. RH sells the software people want to buy. Neither action is suggestive of what is good for us to purchase or use.
No because it applies to CentOS as well. It's not the same at all.
-
@scottalanmiller said in Linux OS Thoughts?:
@stacksofplates said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@stacksofplates said in Linux OS Thoughts?:
LTS, by definition, gets patched. But as we've proven with Ubuntu, not fully patched.
So you picked one bad vendor to try to prove your point. That doesn't invalidate all of the others that do patch. And no you never proves that. You only stated it, which is obviously not proof.
I proved it to the point that it's Canonical's official stance. If it comes to that, you can't prove anything else. I at least got to the point of the vendor making it their support position. It's the most official thing that there could be.
Yeah except that's not proof. That's just you telling us that's what they said. That doesn't prove that a vendor doesn't support their releases.
-
@Dashrender said in Linux OS Thoughts?:
@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?:
@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...
Whoever makes the decision, is IT. IT isn't a title, it's an action.
yeah yeah -
Well, you ignore this a lot. But it's a consistent thing. You can't constantly claim IT doesn't do any of the IT. He would does IT, is IT. Maybe it's shadow IT, but really, it's from the top down, so it's not even that. It's just IT in your organization isn't a labeled department. But you know that the owners and managers who refuse IT titles consistently demand IT decision making and are the IT managers.
-
@stacksofplates said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@stacksofplates said in Linux OS Thoughts?:
Yeah see you say that but literally everyone else views SCAP settings as good security. Even the people who make the software....
But I'm unclear how that goes against what I said. That's not a counter argument. That the government "can" sometimes produce something good or "seen as good" isn't in dispute.
SCAP could be pure gold, but if applied to a bad product, not be the best decision. SCAP being good, great, even amazing, doesn't logically have anything to do with LTS vs current support or release models.
@stacksofplates said in Linux OS Thoughts?:
The proof is in the pudding. Red Hats own hardening guide for Fedora is about 5% as large as RHEL/CentOS. And it's not because they are that drastically different.
That's not pudding, though. RH makes money only on RHEL, RH is a business. That RH chooses to do what is profitable doesn't even begin to suggest where good models for end users is.
This is like saying that McDonald's sells Big Macs, McD's is a big company, therefore Big Macs are healthy food. It's not logical. McD's sells what people want to buy. That's their job. RH sells the software people want to buy. Neither action is suggestive of what is good for us to purchase or use.
No because it applies to CentOS as well. It's not the same at all.
It has to apply to CentOS, that it automatically applies there is neither here nor there. I'm not sure how you feel that relates to my point.
-
@stacksofplates said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@stacksofplates said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@stacksofplates said in Linux OS Thoughts?:
LTS, by definition, gets patched. But as we've proven with Ubuntu, not fully patched.
So you picked one bad vendor to try to prove your point. That doesn't invalidate all of the others that do patch. And no you never proves that. You only stated it, which is obviously not proof.
I proved it to the point that it's Canonical's official stance. If it comes to that, you can't prove anything else. I at least got to the point of the vendor making it their support position. It's the most official thing that there could be.
Yeah except that's not proof. That's just you telling us that's what they said. That doesn't prove that a vendor doesn't support their releases.
It does, that's precisely what it does. When called on to support LTS, that was the only way to continue support. What else could it mean?
It's more than what they said, it's also what they did. They didn't support LTS, but offered to update to current where there was support.
