Discussion on LTS OSes
-
@IRJ said in Linux OS Thoughts?:
Also more features? Like what in Ubuntu 19x that isn't in 18.04 LTS? Very minor things
I can only assume more features when using a desktop environment. And maybe new kernel but that's fixed by using HWE when using the LTS.
-
@stacksofplates said in Linux OS Thoughts?:
Except things like bug fixes are still done in LTS, as I just pointed out above. So I don't know what you're pointing at with things like bugs and support...
Doing fixes and doing as much isn't the same. Developers loath working on dead software and regardless of claims, LTS is dead as far as devs are concerned. It's old and they've moved on. Senior devs will not work on patching old stuff when there is current stuff to work on. The good people are always on the new, the interns and juniors are on the old. Some stuff from current gets back ported, by juniors mostly. Some gets missed. But the "real work" is always going on on the current stuff.
Software vendors know this. LTS is a time sink and they hate it. SaaS changes this game by eliminating LTS. This is a huge piece of why SaaS grabs better, higher paid people. Because they waste less time on stuff that shouldn't matter (patching old versions of things people could have kept current) and get to do more fun and challenging things that make them happy.
LTS, by definition, gets patched. But as we've proven with Ubuntu, not fully patched. When we needed stability patches, Canonical said that the "support" for LTS stability was to move to "fully supported current" because things like stability were only back ported when they were low hanging fruit. So the level of patching is higher in Ubuntu Current than in LTS. Security patches probably more even, but stability, performance, and similar there's no question, current gets more love.
-
@black3dynamite said in Linux OS Thoughts?:
@IRJ said in Linux OS Thoughts?:
Also more features? Like what in Ubuntu 19x that isn't in 18.04 LTS? Very minor things
I can only assume more features when using a desktop environment. And maybe new kernel but that's fixed by using HWE when using the LTS.
Desktop for sure, that's much more apparently. But server OSes get more platform features and such, too. Anything that LTS gets, goes to current first. Maybe only a little bit, maybe a lot, it varies. Can be simple things, like the newest version of PHP. There are features in that, features that current gets before LTS.
-
@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."
