[CentOS] How to install XFCE on CentOS 8?

Thu Feb 25 22:26:38 UTC 2021
Gionatan Danti <g.danti at assyoma.it>

Il 2021-02-25 22:35 Stephen John Smoogen ha scritto:
> Mainly because customers don't want to pay for that work which is
> considerable. If Red Hat builds it, it is expected to have all kinds of
> 'promises' equivalent to its other products and that is expensive in 
> terms
> of QA, engineering, documentation, various certifications, etc. Package
> growth goes up quickly so if people are complaining about the cost of a
> RHEL license for 4000 src rpms, then what would it be at 20,000 to 
> 30,000.
> It is easier to allow the community to choose to do the work it wants 
> and
> then 'consumers' of said repository get what they can.

[Including Valeri] I doubt it. Price is mainly defined by offer and 
demand (which is, in turn, driven by how much value the customer put 
behind the product). While production/support cost can put a lower bound 
on it, I don't think this is the case for Red Hat.

Anyway, Red Hat did not have to supporto EPEL packages the same as core 
one - even a best effort support would be enough in many cases. The 
point is that EPEL does not only contains nice-to-have packages, but 
sometimes provide really important packages.

As an (outdated) example, a decade ago Cyrus with mysql backend was only 
provided by EPEL. For a more up-to-date example, consider how difficult 
is to run a "plain" CentOS 7 system - it misses monit, mbuffer, smem, 
x2go, various Perl modules, etc.

You EPEL volunteers do an outstanding works - I would really than for 
all you did (free of charge) for the CentOS community. Red Hat should 
recognize and support your works.

> I think the industry is entering another crux point where 'classical'
> system administration will be in the same class as mainframe/miniframe
> system administration were in the late 1980's and early 1990's with 
> Unix
> systems and then Linux. Our wor will remain incredibly important to 
> various
> industries but it will increasingly be a smaller amount of 'total
> deployments'.  Which is why so many of our conversations echo so much 
> of
> the USEnet in the early-1990s, where mainframes/miniframes admins 
> wondered
> why companies were not focusing on their industries anymore.

Well, in a sense, the new cloud frenzy is something similar to a "remote 
mainframe" used with a new type of thin client (the browser). Yeah, I 
know this is a very stretched analogy...

I should say that I saw so many services deployed "to the cloud" that 
are plain broken/misbehaving that it sometime worries me. My (naive?) 
impression is that we are switching from "few specific services which 
correctly work unless something bad happen" to a 
"mess-which-more-or-happens-to-works but nobody know what to do if it 
does not" model.

I recently debugged an IPSec tunnel between an on-premise appliace and a 
Azure VPN services. The on premise appliance has extensive log and 
inspection tools, while on the Azure side we had litelly *nothing*. An 
Azure consultant was taken on board to help with specifig Powershell 
sniplet, to no avail. After 7+ days, a 3rd level Microsoft support 
engineer change a *private* setting on that VPN gateway service and the 
tunnel started working correctly.

On another case, a Win2008R2 machine stopped working in a AWS instance. 
No console, no logs. After 2+ weeks of paid "gold/premium" support from 
an Amazon enginer, my customer simply decided to detach the virtual disk 
and to attach it to another machine, reinstallaing the server.

Are we sure this is the way to go?

Don't get me wrong - "the cloud" is the natural places for things as web 
and mail server. A virtualized domain controller? Mmm... not so much.

But hey - I understand this is not going to change. The very same CentOS 
switch was done to please the cloud vendors, which will have a more 
"dynamic" base to rebuild. But I don't like how Red Hat does not simply 
produce a different product or profile for the cloud needs, rather than 
actively adding complexity at every layer.


Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8