Language Selection

English French German Italian Portuguese Spanish

better stability & security

Rolling release/repo
73% (183 votes)
Static release/repo
27% (67 votes)
Total votes: 250

Rolling release is good for

Rolling release is good for one reason. You get the full security and bug fix updates as intended by upstream.

No amount of backporting fixes is enough to keep a system secure and bug free. It's as simple as that. If I backport fixes from kernel git tree to a stable kernel 2.6.2x release, I'm most likely going to miss a lot of fixes. Cherry picking fixes for popular bugs only isn't a solution and causes weakness in Static release distributions.

The only requirement for a rolling release to work is to keep the base system as simple as possible. Theoretically, no downstream patching should be done in packages such as glibc, gcc or kernel unless it is a patch waiting to be eventually merged in a future upstream release.

re: poll

For servers - Static release/repo.

The "theory" of rolling releases is great, but the real world application, not so much.

Servers MUST be stable and secure. With a rolling release, you rely too much on the upstream vendor not to fubar something your system must have (not that it can't be done - mainframes have been doing rolling upgrades for decades - it's just EXPENSIVE to do it right).

RHEL/CENTOS has the right business model. Forget the fluff (and or bleeding edge stuff), only put well tested software into their repo's, backport security as needed, and support the whole thing for 5 years (or longer for security patches)

Of course it doesn't really matter what method the upstream vendor uses, you still need to run a parallel test environment along side your production environment, and test everything (and I mean EVERYTHING) in the first before rolling it out on the second.

It's just easier (for me anyways) to plan your server environments (and their future) if you have static (but not the ridiculously short 6 month timeframe) releases.

Which would you say is better for a linux server?

I have heard the topic discussed in various forums and points of view.

Which would you say is the better choice for a linux based server?

Please give reasoning for your answers and not post "sux" or "rules" nonsense.

Big Bear

More in Tux Machines

Red Hat News

  • An Open Source Load Balancer for OpenShift
    A highly-available deployment of OpenShift needs at least two load balancers: One to load balance the control plane (the master API endpoints) and one for the data plane (the application routers). In most on-premise deployments, we use appliance-based load balancers (such as F5 or Netscaler).
  • Red Hat Beefs Up Platform as a Service Suite
    Red Hat has begun shipping Red Hat Fuse 7, the next major release of its distributed, cloud-native integration solution, and introduced a new fully hosted low-code integration platform as a service (iPaaS) offering, Fuse Online. With Fuse 7, the vendor says expanding its integration capabilities natively to Red Hat OpenShift Container Platform, an enterprise Kubernetes platform. Fuse gives customers a unified solution for creating, extending and deploying containerized integration services across hybrid cloud environments.
  • Red Hat ‘Fuses’ Low Code Development and Data Integration
    Red Hat, a provider of open source solutions, has announced Red Hat Fuse 7, the next major release of its distributed, cloud-native integration solution, and introduced a new fully hosted low-code integration platform as a service offering, Fuse Online. With Fuse 7, Red Hat is expanding its integration capabilities natively to Red Hat OpenShift Container Platform, a comprehensive enterprise Kubernetes platform. Fuse gives customers a unified solution for creating, extending and deploying containerized integration services across hybrid cloud environments.
  • The GPL cooperation commitment and Red Hat projects
    As of today, all new Red Hat-initiated open source projects that opt to use GPLv2 or LGPLv2.1 will be expected to supplement the license with the cure commitment language of GPLv3. The cure language will live in a file in the project source tree and will function as an additional permission extended to users from the start. This is the latest development in an ongoing initiative within the open source community to promote predictability and stability in enforcement of GPL-family licenses. The “automatic termination” provision in GPLv2 and LGPLv2.x is often interpreted as terminating the license upon noncompliance without a grace period or other opportunity to correct the error in compliance. When the Free Software Foundation released GPLv2 in 1991, it held nearly all GPL-licensed copyrights, in part a consequence of the copyright assignment policy then in place for GNU project contributions. Long after the Linux kernel and many other non-GNU projects began to adopt the GPL and LGPL, the FSF was still the only copyright holder regularly engaged in license enforcement. Under those conditions, the automatic termination feature of GPLv2 section 4 may have seemed an appropriate means of encouraging license compliance.
  • Monness Believes Red Hat (NYSE: RHT) Still Has Room to Grow
  • Comparing Red Hat (RHT) & Autoweb (AUTO)
  • As Red Hat (RHT) Share Value Rose, Calamos Advisors Upped Its Position by $300,831; Chilton Capital Management Increases Stake in Equinix (EQIX)
  • Blair William & Co. IL Buys 23,279 Shares of Red Hat Inc (RHT)

Total War: WARHAMMER

Red Hat changes its open-source licensing rules

From outside programming circles, software licensing may not seem important. In open-source, though, licensing is all important. So, when leading Linux company Red Hat announces that -- from here on out -- all new Red Hat-initiated open-source projects that use the GNU General Public License(GPLv2) or GNU Lesser General Public License (LGPL)v2.1 licenses will be expected to supplement the license with GPL version 3 (GPLv3)'s cure commitment language, it's a big deal. Read more

Android Leftovers