Discussion on LTS OSes
-
-
@IRJ said in Linux OS Thoughts?:
@scottalanmiller said in Linux OS Thoughts?:
@IRJ said in Linux OS Thoughts?:
Negatives about bleeding edge:
Often not supported
No available benchmarks
Higher chance for bugs as it gets untested releases
What are the tangible negatives for LTS?Issue LTS Current Latest Technology (including security) Stagnant Updates Much Sooner Bugs More Time to View Code More Updated Code and Refactoring Support - Official Better from HR and Suse Better from Microsoft and Canonical Support - Devs Hated Focused Support - Products Better for Badly Supported Products Better for Well Supported Products In the Interest of the Vendor Low High Security Reviews More Time to Benchmark Less Time to Benchmark Security - Hackers More time to find holes Less time to find holes Features Fewer More Patching Consistent Consistent Performance Generally Worse Generally Better Abrubtness of Changes High Low OS Level Version Updates Generally Breaking Generally Painless Encourages Proper Maintenance Discourages Encourages Third Party Library Support Often Requires Leaving LTS Status to Work Less Likely Requires Leaving Supported Conf More Support for Components (DB) Higher Lower Lots of the things about one versus the other is "tends to". LTS tends to encourage bad behaviour. Current tends to see bugs first. Of hard and fast things it's less clear, which is why traditionally LTS was considered better in the 90s and 2000s, but isn't seen that way today. How software is delivered, maintained, used and supported is very different. DevOps, for example, has removed many of the arguments for LTS.
I bolded the winners in a category when there was one.
Where did you get this chart? lol
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...
-
@scottalanmiller said in Linux OS Thoughts?:
@IRJ said in Linux OS Thoughts?:
Where did you get this chart? lol
I just made it! Like on the spot.
I have to admit the wording is quite amusing, but that not of it tangible.
-
Also more features? Like what in Ubuntu 19x that isn't in 18.04 LTS? Very minor things
-
The hackers finding holes goes two ways. More time to find holes means better review. Which is the concept of Open Source Software.
-
@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?
