> Am 04.12.2020 um 23:16 schrieb Japheth Cleaver <clea...@terabithia.org>: > > On 12/4/2020 12:35 PM, Stephen John Smoogen wrote: >> >> ... >> >> For the people who were using it as servers, it was split between getting >> ready for the next RHEL/CentOS they would be deploying, they needed packages >> which were not in EPEL, or things like python/nodejs/etc was new enough for >> what they needed to run but wasn't in EL8. >> > It would be interesting to consider how Fedora Server use cases change over > time during an EL release cycle. > > For many server use cases where the box is NOT ephemeral, when CentOS and > Fedora are similar, it's likely that CentOS is going to be a > better-engineered and tested option. But as time goes on and the next EL > release isn't either isn't announced or isn't stable enough to rely on, > Fedora Server probably sees more use as a quasi-stable release base.. This > fills a real need when your users are absolutely clamoring for things that > aren't likely to be backported into the stable EL release and you don't > want to have to send them into Ubuntu/Debian land (or have them grab an > un-administered container off the shelf).
Fedora has advantages not only when RHELx / CentOSx is matured, but in some cases already at release time, when some important components are already „behind“, e.g. postfix / dovecot with CentOS 8 regarding SNI and submission (which are quite important features in a containerised world). And with the current rapid development, even small version differences can be important. > In fact, Fedora Server as a "not EL, but better than nothing as a temporarily > stable platform" during these later periods could be a useful niche to fill. > Bonus points for some of those extended support duration/stable discussions > from a few years ago. I see advantages sui generis in Fedora Server over CentOS, not "just" an interim solution or workaround until the next CentOS version is released. You get (almost) all the positive features that make CentOS /RHEL stand out (well thought-out architecture and workflows, security, systematic tools, etc.) and additionally - more up-to-date application software, which often enables a better response to current developments and changing requirements - easier administration due to a greater variety of available packages - shorter release jumps, which are therefore less disruptive - easier (quasi rolling) updates (dnf update), which save a lot of time - Freedom from strict RH feature management (example BTRFS, XEN some years ago) - greater backwards hardware compatibility (e.g. exclusion of drivers in el 8, which make some older hardware unusable or only very difficult to use) The list can easily be extended. -- Dr. Peter Boy p...@boy-digital.de p...@uni-bremen.de _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
