0

the following command used to work in CentOS 7 for installing LxQT. It seems on CentOS 8 system, this isn't working anymore. It shows some errors. If anybody got any clue about this and likes to mention, will appreciates...

dnf install lxqt-about lxqt-common lxqt-config lxqt-globalkeys \
lxqt-notificationd lxqt-openssh-askpass lxqt-panel lxqt-policykit \
lxqt-powermanagement lxqt-qtplugin lxqt-runner lxqt-session \
network-manager-applet nm-connection-editor pcmanfm-qt qterminal-qt5

from this page on Installing LXQt on Centos 7 (from EPEL)

Throws this error now ->

Last metadata expiration check: 1:47:47 ago on Mon 13 Dec 2021 11:48:56 AM EST.
No match for argument: lxqt-about
No match for argument: lxqt-common
No match for argument: lxqt-config
No match for argument: lxqt-globalkeys
No match for argument: lxqt-notificationd
No match for argument: lxqt-openssh-askpass
No match for argument: lxqt-panel
No match for argument: lxqt-policykit
No match for argument: lxqt-powermanagement
No match for argument: lxqt-qtplugin
No match for argument: lxqt-runner
No match for argument: lxqt-session
No match for argument: pcmanfm-qt
No match for argument: qterminal-qt5
Error: Unable to find a match: lxqt-about lxqt-common lxqt-config lxqt-globalkeys lxqt-notificationd lxqt-openssh-askpass lxqt-panel lxqt-policykit lxqt-powermanagement lxqt-qtplugin lxqt-runner lxqt-session pcmanfm-qt qterminal-qt5
Marcus Müller
  • 21,602
  • 2
  • 39
  • 54
SS891
  • 1
  • 2

1 Answers1

1

The answer you linked is for CentOS 7 and won't work for CentOS 8 because LXQt is not available in EPEL 8 (there is no guarantee that packages that were available in EPEL for CentOS 7 will be available for 8 or 9). There is a bug requesting it for EPEL 8 but there was not activity for two years so it probably won't happen unless someone volunteers to help with the build.

There is an unofficial snap package available and snapd is available in EPEL 8 so you might try that but I'm not sure how well snap packages work on CentOS.

Vojtech Trefny
  • 16,922
  • 6
  • 24
  • 48
  • 1
    not really sure whether a snap of a whole desktop environment is very useful (that does a lot of things that the snap separation is designed to make impossible, what with all the interaction with thumb drives etc.)! Otherwise, very good answer, +1! – Marcus Müller Dec 13 '21 at 20:13
  • Thanks @Vojtech. I will try the snap. Also - do you recommend going back to CentOS 7 for this. Our goal is to have a very lightweigth desktop environment so that desktop movement is agile and LxQT helps us a lot. – SS891 Dec 13 '21 at 20:23
  • It looks like for AMD64, we don't have it. "error: snap "lxqt-snap" is not available on edge for this architecture (amd64) but exists on other architectures (arm64, armhf, s390x). " – SS891 Dec 13 '21 at 20:28
  • If you really want LXQt and don't want anything else from CentOS 8 then staying with CentOS 7 might be a good solution, the [EOL is similar for both](https://wiki.centos.org/About/Product). But you also might consider Xfce, I don't think it's worse than LXQt when it comes to resource usage. Weird the snap is not available for x86_64 but is for ARM64 and S390? I also agree with @MarcusMüller, snap for desktop environment could be problematic. – Vojtech Trefny Dec 13 '21 at 20:41
  • seconding that, LXQt was nice, but Xfce might simply be more alive (on CentOS, not generally). Also, honestly, cinnamon doesn't perform badly, either. – Marcus Müller Dec 13 '21 at 20:44
  • @VojtechTrefny - thank you a bunch. Yes I moved back to CentOS 7. We access servers half-way around the world sometimes (US-India) and work in desktop. The LxQT has been really fast, in terms of responsiveness, so want to stick to it now. We will hv to verify Xfce sometimes for our use case and then decide a migration. CentOS 7 does the job for us, however migrated to CentOS 8 this time if it gives usual benefits (speed one thing) - and I am not any expert here. Thanks a bunch for your help and thoughts. – SS891 Dec 14 '21 at 17:20
  • We will try Cinnamon and Xfce a bit, see responsiveness and then will take the call. Thanks @MarcusMüller for your thoughts. – SS891 Dec 14 '21 at 17:21
  • 1
    @Ad891 if remote desktop is your problem, then the answer is not picking a different desktop environment, but picking a smarter way of working on a remote desktop. How are you accessing the remote server? **Why** are you accessing the remote server? This really sounds like an X/Y problem where you have an interesting solution Y that you ask about, which you think is a solution to problem X, but you don't ask about X, but if you did, people might actually help you solve X. – Marcus Müller Dec 14 '21 at 17:23
  • @MarcusMüller - 1) Why access remote server -> primarily because of cost as the particular DC offers much cheaper server and also due to geography -> some folks in North America can access them faster. How we are accessing -> We use LXQt + XRDP. We tried with KDE/GNOME (desktop) + VNC/Guacamole/Nomachine (Access). But those were way slower than LXQt + XRDP. This one working reasonable till now. The other option is to have a dedicated leased line that offers lower constant latency (latency is the key here ). But details of that is sketchy in net/stackoverflow. We have crunch of time. – SS891 Dec 14 '21 at 19:26
  • @SS891 India->US east coast (Hyderabad->New York) is some > 13000 km. Even with a straight fiberoptical cable and no switches, routers, repeaters, buffers in between (not realistic), that's a roundtrip time of 130 ms. Because speed of light is finite. The question that bugs me is why you'd want to run a graphical command on a datacenter > 13000 km away. Isn't there a more elegant way, such as running the GUI locally, and only exchanging the data of interest over network? – Marcus Müller Dec 14 '21 at 19:32
  • @MarcusMüller - like I said, the cost and availability of readymade solution. We aren't experts in sys-admin front and after some research and queries in internet, we couldn't find a better solution. The works are primarily in editors (gvim/emac/notepadplusplus) or some custom tool GUIs, so while the latencies can be better, we manage them. Yes, aware of the SOL (High School Physics). You will be interested to know that folks in MNCs work from India to US servers directly many times ( and the MNCs mostly have leased line with guaranteed latency) even though MNCs keep an India data center. – SS891 Dec 15 '21 at 07:04
  • @MarcusMüller , For countries such as China, the distance is less and they don't keep a dedicated data-center sometimes and folks from China can work comfortably on US servers ( there are other reasons). But folks in India can work on US servers too. I don't know if there's a better way where these apps/desktop holds some data locally and can be more snappy, so we have go with present method. And hardware cost in US is way less than in India due to higher import duties, so renting a server becomes way cheaper in US. If you know of better desktop, please suggest us. – SS891 Dec 15 '21 at 07:08
  • Also, we hv local servers, but this one is for heavy duty simulations. FYI. – SS891 Dec 15 '21 at 12:53
  • If they work in editors, you should have a development mechanism that works for globally distributed teams. You don't need to work on the same server to have distributed source code control – that's why people use git. – Marcus Müller Dec 15 '21 at 13:52
  • It's more than that. Local machine has usage, we can't a built tree in git and dispatch across servers all the time. Thanks for all the help!. – SS891 Dec 15 '21 at 19:14