[CentOS] CentOS Stream suitability as a production webserver

Wed Jan 6 17:13:36 UTC 2021
Stephen John Smoogen <smooge at gmail.com>

On Wed, 6 Jan 2021 at 11:17, Simon Matter <simon.matter at invoca.ch> wrote:

> > On Wed, 6 Jan 2021 at 07:50, Simon Matter <simon.matter at invoca.ch>
> wrote:
> >
> >> > Am 06.01.21 um 03:01 schrieb Scott Robbins:
> >> >> On Tue, Jan 05, 2021 at 11:31:34PM +0000, Jamie Burchell wrote:
> >> >>> Off topic for sure, but it's a shame this has to be a manual process
> >> of
> >> >>> destroying and rebuilding every X years. Even Microsoft has gone the
> >> >>> Apple
> >> >>> way and just perpetually updates Windows 10 now.
> >> >>
> >> >> I'm not sure how it will go. Fedora now has a very good upgrade tool
> >> >> that
> >> >> has worked for me through a few versions.  So, hopefully, RH, and
> >> CentOS
> >> >> will have one too, who knows, maybe in time to migrate to Stream-9.
> >> >>
> >> >
> >> > Fedora's package set is quite "stable". You can expect that a package
> >> is
> >> > in the next release. This is not so valid for EL. Deprecated packages
> >> > (ImageMagick in EL7 but not in EL8) make such upgrade path difficult
> >> ...
> >>
> >> It's anyway hard to understand how an enterprise grade Linux can be
> >> shipped without things like ImageMagick or Tomcat. For quite some time
> >> now
> >> it gives me the impression that we're not the targeted audience anymore.
> >>
> >>
> > The issue is that 'Enterprise' is an overloaded term without the nuance
> it
> > needs. In the 'small' enterprise you have a lot of use of ImageMagick and
> > TomCat. In the large enterprise of 100,000+ servers.. it isn't. As more
> of
> > the large enterprises moved into RHEL, the amount of usage for a lot of
> > 'leaf' programs became rounding errors without enough usage to justify
> the
> > bug-fixing needed when compared to the load of bugfixing/enhancements/etc
> > in the 100k customers.
>
> Thanks for confirming that RHEL is the wrong OS for SME businesses these
> days. It's not really good for SME servers and not really good for SME
> clients. Something between Fedora and RHEL could be it but it doesn't
> exist.
>
>
I didn't say or mean that. My answer is that it is complicated and more
meant that the software you expect requires more than the industry in
general is willing to pay to keep going. 10-20 years ago they were and so
the software was able to be 'mainstream'. As less people use it, and less
people are willing to pay for its maintenance the harder it is to keep
'running safely'. Tomcat and Imagemagick have had a LOT of severe security
problems over the years and the general way the software is written makes
anyone who does work on them say it will have it for years in the future.
As less of the industry uses that software, the cost to keep the software
running is going to cost more.

So please don't take my statement to confirm your preconceived notion.


> BTW, servers? Who needs servers in the days of clouds and serverless
> computing :-)
>
>
Simon
>
> >
> >
> >> That's really sad because the competitors still include such important
> >> software as first class citizens. Maybe our requirements are just too
> >> old
> >> school?
> >>
> >>
> > An additional problem is a generational one. We have a lot of programs
> > which do various things 'well' enough written 10-30 years ago, and we of
> a
> > certain age use them for the hammers to every nail problem. However, the
> > problems fleets of 100k systems have are more welding versus hammering.
> So
> > we are in a situation where we do need to retrain some of our hammers to
> > be
> > rivet guns. There is also a similar industry problem that anything older
> > than 2 years ago is not sexy anymore because VC and investors aren't
> going
> > to dump money into it. [You see a similar issue in the various 'popular
> > mechanics' press that all homes in the next generation will only be built
> > with metal and hammers and wood are a thing of the past. What you see
> > instead is a wave of it and then a realization that you end up needing to
> > do a little of each.]
> >
> >
> >
> >> Simon
> >>
> >> _______________________________________________
> >> CentOS mailing list
> >> CentOS at centos.org
> >> https://lists.centos.org/mailman/listinfo/centos
> >>
> >
> >
> > --
> > Stephen J Smoogen.
> > _______________________________________________
> > CentOS mailing list
> > CentOS at centos.org
> > https://lists.centos.org/mailman/listinfo/centos
> >
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Stephen J Smoogen.