MX > stock
MX > stock
The point is that LXQT and LXDE use half as much ram as Xfce. I’m not saying OP should use KDE.
It’s about 300mb lighter than KDE in my experiences. On 2gb of RAM, that makes a difference.
And both LXDE and LXQT use half as much RAM as Xfce.
LXDE is gonna be fine too; but it lacks a lot of the polish that XFCE has. I honestly like both for different things.
I’d rather be able to open more than 5 tabs than have a fancy UI. That’s why Xfce is on my newer devices, and I install those 2 whenever someone needs an ancient laptop revived.
Just install a few of them, see what works, how much resources they use up, and what allows you to open more than one browser tab. Hell do it in a VM, Arco-B has a wide range of DE’s to choose from in the installer.
From my experience it’s barely lighter than KDE. LXQT/LXDE destroy it in every benchmark and in every test I’ve tried.
XFCE I find a little tricky to get tiling working right
Just replace xfwm4 with i3wm for example. That and the fact you can use most Xfce tools outside of Xfce is why it’s my favourite.
WAAAAAAAAAA…
I MEAN, LONG LIVE ROWBOAT GIRLYMAN!!!
FOR THE EMPEROR!?!!
Also, different solutions have different benefits and downsides, and are better in different scenarios.
deleted by creator
That’s because of users, not OS… right?
It’s a factor, but constantly upgrading to the newest version of software does come with risks. I’ve had Arch and derivatives fail to boot on multiple devices plenty of times after an update.
Some people say that they run arch for years without having any issues, but that’s either extreme luck or bs.
I love to deal with problems but I don’t want to waste my time.
You can usually just use a btrfs snapshot to rollback, boot, and try to update later. But there were situations when I had to use arch-chroot, and it can be problematic to install new packages in that situation.
All setups have tradeoffs, but I’d wholeheartedly suggest a stable distro like MX and nix + home-manager. It avoids all of the previously mentioned issues, and comes with other benefits. Do note that you might need to make or copy a hyprland.desktop file because home-manager can only alter files in your ~.
Sure, but if you do that, and then follow it up with often outage and security issues, I’m going to seriously rethink using your services.
Oh, yes we have. Gitlab, Codeberg, Notabug, etc. You can even host your own Gitea or Forgejo instance if you want.
Self-hosting is right out for most people. It’s pretty expensive to even get started without compromising your home network (router with VLAN, switch, multiple servers (at least thinclients)), and then on top of that you need to maintain it, and can’t really ever max out your download/upload speeds because people are depending on your internet to interact with the repo.
Gitlab is also for-profit, but also has blackouts and devs going rm -rf
on the production DB. It’s often in the news for bad things, so I’ve generally avoided it.
Codeberg is great for personal repos, but most smaller git hosting services have horrible SEO. Like I’ve had issues finding repos when searching for their exact name, if I had to use general search terms I’d only see github repos.
Gitlab: For profit (wouldn’t say it’s much better than github)
It’s got that added excitement that comes with a risk of someone doing a rm -rf
on the production DB
declarative > imperative all day, every day
I’m going to have to come back to Nix/NixOS in a bit.
Use nix + home-manager first for sure. It’s far easier, and you can slowly get into it while making a list of bleeding edge packages.
I’ll probably wait until the official docs catch up as it appears that they are quite a bit behind
Skip them altogether when you’re starting out. I gave up on trying nix the first few times due to how bad they are. zero-to-nix.com is better for learning the basics of nix.
That and I’m not sure how I feel about a DSL for package management. I’d much rather use JSON or YAML, or even INI or TOML.
The closest you can get is home-manager with a list of packages in a json-like format. It’s really not practical to develop a declarative system without a programming language. A basic example would be variables, more advanced would be to write a wrapper that modifies the package so it automatically runs the required cli commands to use your dediated gpu and nixGL with specific packages (nvidia-run-mx nixVulkanNvidia-525.147.05 obs
for example).
It’s sort of like IaC where you’ve got terraform (dsl), pulumi (various languages), and cloudformation (json/yaml). Can you guess which one is universally despised?
Maybe if I were a LISP or Haskell guy.
Then you’d use guix and a dsl made within an actual programming language (much better approach IMO).
That’s such a bad name, I only see lixmaballs.
How do you like it, that’s one of the earlier forks, right?
In case you missed topic of the whole discussion:
Nix has the same mix of conceptual simplicity and atrocious user interface as git,
Nobody at any point compared the difficulty of learning the entirety of each of those systems, and my entire point is that the complexity of nix is not in the cli commands…
You’re not using KDE connect perhaps?
sysVinit is only the default, it comes with systemd as well.
The tools are useful no matter the init system, and make life easier, especially for beginners.
In essence MX is just Debian with tools to make desktop use easier.