[HN Gopher] LXQt 2.0.0
___________________________________________________________________
LXQt 2.0.0
Author : jrepinc
Score : 168 points
Date : 2024-04-17 12:52 UTC (10 hours ago)
(HTM) web link (lxqt-project.org)
(TXT) w3m dump (lxqt-project.org)
| fullstop wrote:
| Congrats to the team. I ran this for quite a while and it's a
| great desktop, especially for older PCs.
| mikae1 wrote:
| This is really an amazing and underappreciated desktop
| environment.
|
| If you're looking to save some RAM, this ain't it. Not because
| LXQt is memory hungry, but because Plasma is so damn efficient
| these days.
|
| I use Plasma but I can really recommend the LXQt file manager
| PCManFM-Qt (catchy name ha?). It's a really snappy and no
| nonsense file manager that feels right at home in Plasma. I
| prefer it over Dolphin.
| HKH2 wrote:
| > If you're looking to save some RAM, this ain't it. Not
| because LXQt is memory hungry, but because Plasma is so damn
| efficient these days.
|
| I doubt it. Have you got any benchmarks?
| generalizations wrote:
| Eh. If you want to save RAM & CPU, i3 is where it's at.
| exe34 wrote:
| xmonad
| Rinzler89 wrote:
| Can confirm. A fresh boot of plasma eats up around 666MB of
| RAM. Not much more than the so called lightweight distros,
| sometimes even less than them, and plasma is a full on DE not
| a gimped WM.
|
| For benchmarks, just Google them yourself or spin up a VM
| yourself.
| planede wrote:
| I don't think a fresh boot is the best benchmark for this.
| I do use plasma and in my experience memory usage tends to
| go quite a bit higher with use, even if you close
| everything. I don't think they have leaks and it's probably
| just memory some data structures and the allocator hold
| onto for various reasons.
| bscphil wrote:
| > around 666MB of RAM
|
| A decade ago, that was a _lot_ of RAM for a desktop
| environment. In the late '00s, I remember Ubuntu with
| Gnome 2 using around ~128 MB of RAM right after boot.
|
| What happened? Most DEs aren't that much more complicated
| than they were a decade+ ago. Is it the array of supporting
| libraries (Qt and Gtk) that get loaded into memory? I could
| see that being a problem since even the "lightweight" DEs
| like XFCE and LXQt rely on them heavily.
| IshKebab wrote:
| I haven't checked but I bet a significant part of that is
| just increased image sizes. Icons and everything are
| going to be uncompressed in memory and if they're now
| 256x256 where they used to be 32x32 or whatever, it
| probably adds up.
|
| There's probably also things like unicode data (ICU is
| like 20MB), more daemons (WiFi, rendezvous, Bluetooth,
| etc.), and I think C compilers have generally optimised
| for speed at the cost of code size over time.
| p4bl0 wrote:
| Let's not forget that nowadays each pointers takes 8
| bytes (64 bits) instead of 4 bytes like it was the case
| on 32 bits systems most of us grew up using, and often
| have the numbers for in mind. Executables are bigger
| because of that, and so are their stack and heap
| (probably not twice as big but probably not too far from
| that!).
| GrumpySloth wrote:
| Around 2012 XFCE would use around 448MB. That's more than
| a decade ago.
| ndiddy wrote:
| XFCE's resource consumption went up significantly after
| it got ported from GTK2 to GTK3, the same thing also
| happened with MATE.
| foresto wrote:
| > A fresh boot of plasma eats up around 666MB of RAM. Not
| much more than the so called lightweight distros,
|
| I used Xfce for well over a decade; maybe closer to two. It
| has long been one of the so-called lightweight
| environments, and it deserved that reputation when I
| started with it, but its memory footprint has grown
| significantly over the years. I don't think it makes a good
| benchmark for "lightweight" any more.
|
| I'm on Plasma now. It has definitely improved in this
| department over the same period of time, but it's not what
| I would consider light. More like middleweight. To be fair,
| it also seems to be doing more than old Xfce did, with
| things like QtWebEngine presumably offering GUI
| functionality of some kind. (Akonadi was another memory
| eater when I last did a default install, though I think
| that one is easier to avoid these days.) If wonder if LXQt
| shuns components like that, or loads them only when needed.
| brnt wrote:
| Plasma generally scores in the best quartile in Phoronix
| benches.
| wredue wrote:
| I used LXQT for a week or so as a daily driver while I was
| picking envs (eventually landing on i3), and I found LXQT to be
| buggy and lacking. That was, oh maybe 3 years ago though. So
| assuming steady development, I hope it's gotten better.
|
| It's also maybe not fair that this was on a dell laptop that
| didn't play particularly nicely with Linux.
| doubled112 wrote:
| > PCManFM-Qt (catchy name ha?)
|
| I believe PCMan was the original developer, and FM for "file
| manager" made sense. Then it was ported to Qt, so add -qt?
|
| That's kind of a mess, isn't it?
| NewJazz wrote:
| Still, it makes a bit more sense than "Dolphin" or "Nemo",
| and you'll probably never actually see these names if the
| desktop file is configured to show a generic name for your
| desktop environment.
| j1elo wrote:
| Wait for the release for VR
| kstenerud wrote:
| > If you're looking to save some RAM, this ain't it. Not
| because LXQt is memory hungry, but because Plasma is so damn
| efficient these days.
|
| Not according to these benchmarks:
|
| https://itvision.altervista.org/linux-desktop-environments-s...
|
| https://vermaden.wordpress.com/2022/07/12/desktop-environmen...
| doubled112 wrote:
| Typically on lower end machines I disable Akonadi (the PIM
| data storage service) and Baloo (file indexer). Some systems
| don't enable them by default.
|
| I'd be interested to know how much of an effect that has.
| SomeoneFromCA wrote:
| yeah, baloo would crash anyway lol, as it always does.
| krylon wrote:
| I use MATE, but I prefer PcManFM-Qt over Caja most of the time.
| It is really good.
| lupusreal wrote:
| I switched to LXQt because it's power management, e.g. suspend
| the laptop if the battery goes below whatever percent, actually
| worked whereas KDE's wasn't and such a basic feature breaking
| (and causing me to lose work) made me too mad to debug it. I'm
| sure it's fixed now, but that was only the final straw for me.
| KDE tries to be too fancy and ends up buggy, whereas LXQt is
| simple and just werks.
| userabchn wrote:
| If you like LXQt but would prefer lower RAM usage, then
| consider LXDE. Even with NetworkManager and PulseAudio, mine
| only uses 300MB.
| uncletaco wrote:
| Looks cute.
| NewJazz wrote:
| I have my grandparents using lxqt (on Debian). I use sway myself,
| but I knew they needed something familiar to their Windows XP-era
| customs and without any frills.
|
| The only tech issue I had to debug for them in the last year was
| when one of the housekeepers pulled a wire while cleaning.
|
| Before Debian LXQt, they were using Lubuntu 18.04 (which was
| still on LXDE at the time).
| mdaniel wrote:
| Don't overlook https://github.com/lxqt/qterminal no matter your
| distro: I used it on Ubuntu because it was the closest I had
| found (thus far) to iTerm2 on Linux. I still have the lust to
| teach it about https://github.com/tmux/tmux/wiki/Control-Mode
| bbkane wrote:
| I'd also recommend https://wezfurlong.org/wezterm/index.html .
| I switched to it from iTerm2 for the reasons in
| https://github.com/bbkane/dotfiles/tree/master/wezterm#iterm...
| (primarily a simpler Lua config to reason about and version
| control)
| atan2 wrote:
| I have been running LXQt for years. A really great desktop
| environment!
| cies wrote:
| With software bloat being rampant, this is a medicine.
|
| Qt keeps the overhead down enormously compared to GTK-based, or
| even (but to a lesser extend) KDE-based (which itself is Qt-
| based).
|
| With good Wayland support.
|
| I think this is replacing XFCE as goto low resource desktop on
| Linux.
| 29athrowaway wrote:
| Qt could be much larger if the licensing terms were not 5d chess
| for over a decade.
___________________________________________________________________
(page generated 2024-04-17 23:01 UTC)