Discussion on LTS OSes
-
@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.
Except if an OS 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.
-
@scottalanmiller said in Linux OS Thoughts?:
@Dashrender said in Linux OS Thoughts?:
Actually 1909 has been released officially.
ANd that's an LTSB? Or just current? I thought it was slated for LTSB but was breaking and they held it off?
I have no idea if 1909 will be LTSB or just current.. but you said current was 1903, and it's not.. 1909 is current (and maybe LTSB as well)
-
@DustinB3403 said in Linux OS Thoughts?:
@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.
Except if an OS 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.
LTS isnt EOL.....
-
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.
This increases our risks, a lot. First it's "we only support LTS", then it is "we only support every other LTS release." Suddenly we have software that's gone a decade without there being a code update, operational test, or any idea how to keep it working. This is how ghost ship software manages to exist - once you've convince customers that not testing for a decade is acceptable, you are home free to ride out software until the end of time. No actual developers, no documentation, no actual support... just make money selling the software as if it was maintained and hope for the best. When things fail, cash out and walk away. Customers are left holding the bag. The risk increases every step of the way, but LTS allows a "frog in the boiling water" technique to make customers ignore their pain until disaster strikes.
IT departments like to delay updates for similar reasons. For them it's generally the hope that the issues with future updates will not bite them until either they have moved on to another company or to another role within the company. Delaying is a powerful tool for internal IT because most people move on quickly and can leave problems for those that follow and blame them for any issues.
-
@WrCombs said in Linux OS Thoughts?:
@Dashrender said in Linux OS Thoughts?:
Back to the OP.
@WrCombs wants to things most likely...
a desktop environment to run in - So Fedora or Ubuntu most likely... and then a separate "server" box to install Linux Server OSes on to experiment with to do things like - setup FreePBX, setup NC, setup file server, etc.
yes.
I could even VM those, right? or no? - Forgive the newbness, but I'm thinking a Desktop and then run a VM Boxes with server OS's to do what @Dashrender is saying and thoughts on which ones to try.yes... personally - I'd have only a Desktop OS on my laptop/desktop machine.... and I would use something like KVM or Hyper-V on the 'server' to run VMs of whatever you want.
As for what to do first - whatever floats your boat.
Maybe - file server first - for windows boxes but using a Linux OS to share the files
then move onto NextCloud - a file sharing platform
then perhaps onto FreePBX, make your own phone system.If you think of somethign else that interests you - go that way instead.
Coming up with the project is perhaps one of the harder things... and I just gave you three. -
@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!
-
@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):
-
@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.
