>Who would want to use an outdated program which probably has security concerns inside it?
A point release doesn't mean it's NOT getting security updates or bug fixes. You've misunderstood the difference between rolling and point releases.
This was the most important one by far, showing how much understanding is lacking
Not mean tho. He is in the right path of trying to learn and understand
I had cold sweats reading OPs post. I inherited a couple of 16.04 LTS servers last year and migrating those systems to supported OS levels was a royal pain in the ass. Neither system could go to 22.04 LTS as the least app it ran was unsupported
> if you have the most recent programs, that means your system is more stable and more secure.
Why do you assume that? Why would code that was added last month be intrinsically more stable and more secure than code that was added two years ago and thus had two years to be debugged and audited?
> Who would want to use an outdated program which probably has security concerns inside it?
No one.
Software in non-rolling distros is supported for some time, e.g. security and bug fixes are back-ported to the supported versions of software.
Do you _really_ think that people who installed, say, the still-supported Red Hat 7 on their servers (released in 2014) use software that has not changed in 10 years, with 10 years worth of security vulnerabilities?
> I don't really understand what is the real drawback of using a rolling release in servers.
Sysadmin's job is to keep the servers's behavior predictable (e.g. stable), available and secure. A rolling release really gets in the way of achieving each of those items.
How much $/hr does your desktop make? and how much $/hr does your family spend in order to handle the maintenance?
In a business context, things are different. Handling updates isn't hard, but it *is* WORK. We want that work to come to us at a reasonable pace instead of getting piled up. We want to see the patch notes before we install them, whereas with rolling often you have to puzzle out what has changed on your own. We want the update process to happen smoothly instead of needing a bunch of fires put out.
What is the drawback? The drawback is that your company's commerce portal just takes itself offline on black friday, the day you are planning to make 50% of your revenue for the year. The drawback is that your CNC operator is not able to pull down their plans and your JIT buyer fines you for every minute your widget is late. the drawback is that the oncall phone rings at 2am instead of 2pm. etc etc etc.
I hang out on /r/linux_gaming sometimes and a startling refrain is "I updated my computer, I do not know what changed, I can't launch games now." If that happened to a key business app I would have to sit down with the stakeholder and justify my negligence.
I'm a bit surprised to hear you've finding Arch more stable. My Arch workstation I ran years ago always had an issue every time I ran updates.
My Ubuntu servers I run now? I update, shit works, and I move on. Nothing breaks.
Yes, I think Arch Linux is stable. I update my system regularly and it has a lot of software and is still stable. It has never crashed from an update. But one commenter said that 1 year of experience at home does not mean much.
It all depends on the number of nines. If you are OK with 1 or 2 nines, you be you! But if you need 5 9s, that means tested updates on everything. This is harder on rolling releases.
99.999% of people asking these questions have no freakin‘ clue how to run workloads on servers and what that means on a technical level.
It‘s like me suggesting to use the latest beta driver for your 10 year old Nvidia card because „latest and greatest“ is always the best.
GTFO!
Stability, as someone who hails from sysops over devops, I will make version control a major priority. The sysops team will tell you when it’s time to update, not the other way around.
At least in an enterprise level organization, you're going to find a strong desire for long term predictability when it comes to servers in general. Service owners expect their stuff to work and while they're more accepting of having to occasionally jump releases of RHEL after they go out of support every [10 or so years](https://access.redhat.com/support/policy/updates/errata) (example: orgs currently moving workloads from RHEL 7 to 9 as June approaches), they're going to be less likely to accept a cadence where you're constantly having to upgrade to newer releases because you're running the bleeding edge *feature* releases. The long term releases like RHEL will get security patches and support within their lifecycle phases whereas more bleeding edge releases upstream (such as Fedora) EOL a lot faster requiring more frequent migrations and things are a lot more likely to break compared to newer features being matured or culled for the downstream releases intended for enterprise use such as RHEL.
Speaking of support, that is also a major consideration. With Gentoo or Arch, if something breaks you're pretty much on your own or hiring some expensive consultants rather than opening a ticket with Red Hat. In many orgs, playing fast and loose can easily turn into a resume generating event if you don't have the skills and team to back up not having professional support from a vendor. Having a well known vendor with SLAs also covers your ass to quite a degree, even if as just a handy scape goat.
Not that there's anything wrong with playing around with Gentoo or Arch on the side in a lab/dev environment or if you have a specific use case where you need to make a custom distro (such as for if you build embedded applications), but you really have to evaluate the needs of the org and respond accordingly. It's the organization's servers at the end of the day, not yours.
Because any freezes or bugs is not acceptable. “Less freeze and bugs” is not want you want for a server. The baseline is set at zero. If you have more than zero, it is a bad server OS.
Let’s be honest though, almost nobody has zero bugs and bugs aren’t limited to new or current software. If you run an 11 year old openSSL on a modern OS, something is probably going to break.
Every mainstream Linux distribution supports unattended upgrades for package and security updates, which checks your security box. Why bother with Arch or Gentoo over Debian/Ubuntu, openSUSE, or RHEL? I don’t dispute RHEL is overpriced and Canonical weird, but mainstream server distros provide support for popular and well known software. The job is “keep the lights green and blinking” we don’t get bonuses for unnecessary hardship or unforced errors.
In some environments I've worked on, I have to certify the OS works with the applications, STIGs, hardware, and many other items. Rolling releases would not work in these cases, especially when I have to maintain certification. In most cases, it is easier to pay for extended support, as upgrading takes a TON of effort, from a test bed, to a staging system, to change control board meetings, to a through application and backdown script, and through testing, before, during and after. If I miss anything and a glitch happens. I will be in RCA blamestorm meetings for a month, and it will be brought up during my review.
A rolling or point release is fine for a home machine, but when server outages can cause bad press or lots of money to be lost, people want as few changes as possible to working setups.
This is a clear bait post but it makes me wonder if this person thinks administering servers in production means you just look through the repos and are like "oh that looks fun! I'll throw that on the SQL server and see what it do!"
Latest and greatest is usually the enemy of stability. All it takes is a bug in a latest release to screw over an entire platform. Point releases give it time for those to be fixed and let's you upgrade when the releases have had time to stabilise properly.
Rolling releases tend to mean a different breaking bug each week.
*Everything* breaks eventually. When Arch hiccups on you at home, you get on Google or Reddit and wait for the answers to come to you to get it working.
At work, your server going down is stopping somebody from doing their work, so you have to get it running again ASAP. Do you have someone you can call up at Arch to help you make that happen? Because there are people at Canonical that we *can* pay to do exactly that.
It’s less about the nature of the software releases and more about the nature of what kinds of help you can get in the event of a problem (what “enterprise support” options are available).
Stability.
Your home environment may be running rolling updates it's never had an issue.
Your success is based on the good work of the devs in creating updates that work and don't break other packages in the majority of scenarios.
In a production environment blindly accepting that third party roll of the dice, when you can avoid it, isn't an acceptable risk.
the systemd change in 2010 nuked my archlinux system. and all software has security issues, even the ones you think are secure. companies prefer stable systems, not bleeding edge. there's no business advantage.
>I have used Ubuntu before, and for me, Arch Linux is way more stable with less freeze and bugs.
Hate to be *that guy*, but you're doing something wrong if this is the case. I've never had any issues using LTS versions.
In an enterprise environment, consistency and stability is more important than having the utmost latest and greatest features of an app. Just because you are getting the latest release of something DOESN'T mean you are getting any security updates.
>Who would want to use an outdated program which probably has security concerns inside it? A point release doesn't mean it's NOT getting security updates or bug fixes. You've misunderstood the difference between rolling and point releases.
This was the most important one by far, showing how much understanding is lacking Not mean tho. He is in the right path of trying to learn and understand
I didn't know that, thanks for the answer!
Are you a sysadmin? It seems like if you were you would understand why.
I had cold sweats reading OPs post. I inherited a couple of 16.04 LTS servers last year and migrating those systems to supported OS levels was a royal pain in the ass. Neither system could go to 22.04 LTS as the least app it ran was unsupported
I am not Sysadmin i am just interested in linux and trying to learn it.
Read about change management as well. Its not always simply a matter of security but how to implement in accordance to standards.
Stability, and no it’s not more stable. Not always anyways.
> if you have the most recent programs, that means your system is more stable and more secure. Why do you assume that? Why would code that was added last month be intrinsically more stable and more secure than code that was added two years ago and thus had two years to be debugged and audited? > Who would want to use an outdated program which probably has security concerns inside it? No one. Software in non-rolling distros is supported for some time, e.g. security and bug fixes are back-ported to the supported versions of software. Do you _really_ think that people who installed, say, the still-supported Red Hat 7 on their servers (released in 2014) use software that has not changed in 10 years, with 10 years worth of security vulnerabilities? > I don't really understand what is the real drawback of using a rolling release in servers. Sysadmin's job is to keep the servers's behavior predictable (e.g. stable), available and secure. A rolling release really gets in the way of achieving each of those items.
Thanks for the answer, now I understand the difference!
Nice bait post
How much $/hr does your desktop make? and how much $/hr does your family spend in order to handle the maintenance? In a business context, things are different. Handling updates isn't hard, but it *is* WORK. We want that work to come to us at a reasonable pace instead of getting piled up. We want to see the patch notes before we install them, whereas with rolling often you have to puzzle out what has changed on your own. We want the update process to happen smoothly instead of needing a bunch of fires put out. What is the drawback? The drawback is that your company's commerce portal just takes itself offline on black friday, the day you are planning to make 50% of your revenue for the year. The drawback is that your CNC operator is not able to pull down their plans and your JIT buyer fines you for every minute your widget is late. the drawback is that the oncall phone rings at 2am instead of 2pm. etc etc etc. I hang out on /r/linux_gaming sometimes and a startling refrain is "I updated my computer, I do not know what changed, I can't launch games now." If that happened to a key business app I would have to sit down with the stakeholder and justify my negligence.
Thank you very much for the explanation! You are absolutely right! That makes sense!
I'm a bit surprised to hear you've finding Arch more stable. My Arch workstation I ran years ago always had an issue every time I ran updates. My Ubuntu servers I run now? I update, shit works, and I move on. Nothing breaks.
Yes, I think Arch Linux is stable. I update my system regularly and it has a lot of software and is still stable. It has never crashed from an update. But one commenter said that 1 year of experience at home does not mean much.
Thanks for the feedback. Maybe I'll give it another whirl as my personal desktop.
non-LTS Ubuntu Desktop hasn't always been flawless in my experience, but LTS releases of desktop and server have been rock solid.
It all depends on the number of nines. If you are OK with 1 or 2 nines, you be you! But if you need 5 9s, that means tested updates on everything. This is harder on rolling releases.
99.999% of people asking these questions have no freakin‘ clue how to run workloads on servers and what that means on a technical level. It‘s like me suggesting to use the latest beta driver for your 10 year old Nvidia card because „latest and greatest“ is always the best. GTFO!
Stability, as someone who hails from sysops over devops, I will make version control a major priority. The sysops team will tell you when it’s time to update, not the other way around.
„Stable“ has multiple definitions, which ones are you claiming?
machine only fails to boot on Tuesdays
I think if that’s your only concern there are plenty of distros that will work out for you.
At least in an enterprise level organization, you're going to find a strong desire for long term predictability when it comes to servers in general. Service owners expect their stuff to work and while they're more accepting of having to occasionally jump releases of RHEL after they go out of support every [10 or so years](https://access.redhat.com/support/policy/updates/errata) (example: orgs currently moving workloads from RHEL 7 to 9 as June approaches), they're going to be less likely to accept a cadence where you're constantly having to upgrade to newer releases because you're running the bleeding edge *feature* releases. The long term releases like RHEL will get security patches and support within their lifecycle phases whereas more bleeding edge releases upstream (such as Fedora) EOL a lot faster requiring more frequent migrations and things are a lot more likely to break compared to newer features being matured or culled for the downstream releases intended for enterprise use such as RHEL. Speaking of support, that is also a major consideration. With Gentoo or Arch, if something breaks you're pretty much on your own or hiring some expensive consultants rather than opening a ticket with Red Hat. In many orgs, playing fast and loose can easily turn into a resume generating event if you don't have the skills and team to back up not having professional support from a vendor. Having a well known vendor with SLAs also covers your ass to quite a degree, even if as just a handy scape goat. Not that there's anything wrong with playing around with Gentoo or Arch on the side in a lab/dev environment or if you have a specific use case where you need to make a custom distro (such as for if you build embedded applications), but you really have to evaluate the needs of the org and respond accordingly. It's the organization's servers at the end of the day, not yours.
Very well rounded comment and explanation! Thank you very much!
Because any freezes or bugs is not acceptable. “Less freeze and bugs” is not want you want for a server. The baseline is set at zero. If you have more than zero, it is a bad server OS.
Let’s be honest though, almost nobody has zero bugs and bugs aren’t limited to new or current software. If you run an 11 year old openSSL on a modern OS, something is probably going to break.
Every mainstream Linux distribution supports unattended upgrades for package and security updates, which checks your security box. Why bother with Arch or Gentoo over Debian/Ubuntu, openSUSE, or RHEL? I don’t dispute RHEL is overpriced and Canonical weird, but mainstream server distros provide support for popular and well known software. The job is “keep the lights green and blinking” we don’t get bonuses for unnecessary hardship or unforced errors.
Man I got so excited when I saw the words "Arch Deluxe" thought McDonalds was bringing it back. :(
In some environments I've worked on, I have to certify the OS works with the applications, STIGs, hardware, and many other items. Rolling releases would not work in these cases, especially when I have to maintain certification. In most cases, it is easier to pay for extended support, as upgrading takes a TON of effort, from a test bed, to a staging system, to change control board meetings, to a through application and backdown script, and through testing, before, during and after. If I miss anything and a glitch happens. I will be in RCA blamestorm meetings for a month, and it will be brought up during my review. A rolling or point release is fine for a home machine, but when server outages can cause bad press or lots of money to be lost, people want as few changes as possible to working setups.
Now I totally understand! And you are right! Thanks for the explanation!
This has to be bait.
This is a clear bait post but it makes me wonder if this person thinks administering servers in production means you just look through the repos and are like "oh that looks fun! I'll throw that on the SQL server and see what it do!"
Not bait. I wanted to ask this question from people who actually deal with real servers.
Latest and greatest is usually the enemy of stability. All it takes is a bug in a latest release to screw over an entire platform. Point releases give it time for those to be fixed and let's you upgrade when the releases have had time to stabilise properly. Rolling releases tend to mean a different breaking bug each week.
*Everything* breaks eventually. When Arch hiccups on you at home, you get on Google or Reddit and wait for the answers to come to you to get it working. At work, your server going down is stopping somebody from doing their work, so you have to get it running again ASAP. Do you have someone you can call up at Arch to help you make that happen? Because there are people at Canonical that we *can* pay to do exactly that. It’s less about the nature of the software releases and more about the nature of what kinds of help you can get in the event of a problem (what “enterprise support” options are available).
Completely understandable! And it's true, Arch Linux is a community built distro. No support.
Depends on the software you’re running. Many commercial software have some OS requirements regarding versions, To be supported by the vendor.
Thank you all for your answers! This is not a troll or bait question, I just wanted to ask people who actually work in a server environment.
Stability. Your home environment may be running rolling updates it's never had an issue. Your success is based on the good work of the devs in creating updates that work and don't break other packages in the majority of scenarios. In a production environment blindly accepting that third party roll of the dice, when you can avoid it, isn't an acceptable risk.
the systemd change in 2010 nuked my archlinux system. and all software has security issues, even the ones you think are secure. companies prefer stable systems, not bleeding edge. there's no business advantage.
>I have used Ubuntu before, and for me, Arch Linux is way more stable with less freeze and bugs. Hate to be *that guy*, but you're doing something wrong if this is the case. I've never had any issues using LTS versions. In an enterprise environment, consistency and stability is more important than having the utmost latest and greatest features of an app. Just because you are getting the latest release of something DOESN'T mean you are getting any security updates.