Let’s see, 10 years ago (2012) I was suffering Windows 8, and used Windows 2000 Server as a GUI for a BBS running FreeBSD, so it would have been an unfair comparison with pure CLI. Ubuntu was looking pretty clunky with their attempts to do a GUI, but it worked.
I would agree that MS won the user friendliness and good looks stakes back then. But Linux in general has come a long way in 10 years. and Arch just celebrated its 20th birthday this week.
Depends what you expect from it. You said you are doing dev work, so with Arch-based, the sky is the limit. EOS may be a better introduction to Arch-based with “an easy start but with infinite configurability” as you say. SInce you want to try your candidate on KVM, you can only really lose time, and may come out loving EOS, as I do.
If you are comfortable with operating systems and don’t mind a command line interface for some things, I would say ANY Linux distro is as good as the next. If you want a rolling release, then Arch based distros are a great choice. If you want fixed release distros, I would suggest Fedora. Every Linux distro will come with its learning curve, so “easy start” is very relative. If by easy start, you mean easy installation, then most distros fit that bill with a gui installer. If you mean easy start as in everything configured out of the box with little tinkering required, then no distro fits that requirement, except maybe Ubuntu or Mint, and even then, that’s a stretch. By infinite configurability you want to customize your system, again, any Linux system will give you that. Since you are doing this in a VM, just go for it and try one. It’s no risk to try a few and see what fits you the best.
I would argue that MX is more configurable in a few ways. MX gives the user choice of init systems, on the fly change from SysVinit to Systemd and back again. Try that with Arch! MX gives easy access to newer software with testing branch available or stick with tried and tested stable, or mix and match. This can be done with Arch, but MX makes it much easier. I am not an MX user or fanboy, but it does have some significant advantages over many other distros.
thanks to everyone who responded. i’m now posting this from endeavour os running on virtual machine. the test drive is on.
i went with the xfce desktop since the installer said it was light weight and i want to keep resources low, my machine is pretty beefy and the performance is at an acceptable level.
install was pretty easy, and surprisingly quick (installing it on an external usb3 hd). i can predict this system will be zooming if i decide to install it native on my #2.
this might happen sooner than you think. heh. i can’t update the system. get a slew of PGP errors. i don’t know if this a vm thing or something else is going on with the repos.
downloading required keys...
:: Import PGP key E85B8683EB48BC95, "Daniel Bermond <dbermond@archlinux.org>"? [Y/n]
:: Import PGP key 6E7CE0B0A36DA2AE, "Brett Cornwall <brett@i--b.com>"? [Y/n]
(337/337) checking package integrity [--------------------------------] 100%
error: libmfx: key "80247D99EABD3A4D1E3A1836E85B8683EB48BC95" is unknown
:: Import PGP key 80247D99EABD3A4D1E3A1836E85B8683EB48BC95? [Y/n]
error: key "80247D99EABD3A4D1E3A1836E85B8683EB48BC95" could not be looked up remotely
:: File /var/cache/pacman/pkg/libmfx-22.1.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: vmaf: key "80247D99EABD3A4D1E3A1836E85B8683EB48BC95" is unknown
:: Import PGP key 80247D99EABD3A4D1E3A1836E85B8683EB48BC95? [Y/n]
error: key "80247D99EABD3A4D1E3A1836E85B8683EB48BC95" could not be looked up remotely
:: File /var/cache/pacman/pkg/vmaf-2.3.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: lightdm-slick-greeter: signature from "Alexander Epaneshnikov <email@alex19ep.me>" is unknown trust
:: File /var/cache/pacman/pkg/lightdm-slick-greeter-1.5.6-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: spice-vdagent: key "35BAE1BF9A6B317021E690C26E7CE0B0A36DA2AE" is unknown
:: Import PGP key 35BAE1BF9A6B317021E690C26E7CE0B0A36DA2AE? [Y/n]
error: key "35BAE1BF9A6B317021E690C26E7CE0B0A36DA2AE" could not be looked up remotely
:: File /var/cache/pacman/pkg/spice-vdagent-0.22.1-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: tldr: key "35BAE1BF9A6B317021E690C26E7CE0B0A36DA2AE" is unknown
:: Import PGP key 35BAE1BF9A6B317021E690C26E7CE0B0A36DA2AE? [Y/n]
error: key "35BAE1BF9A6B317021E690C26E7CE0B0A36DA2AE" could not be looked up remotely
:: File /var/cache/pacman/pkg/tldr-3.1.0-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.
AUR update check:
:: Searching AUR for updates...
-> Missing AUR Packages: hwids
there is nothing to do
sorry, didn’t get notification of this reply and just noticed it now.
your solution worked, thanks. i now have an updated OS and have put EOS as a primary candidate for moving to physical hardware. it’s between this and manjaro at this point. both seem very similar and offer the kind of workflow environment i’m familiar with on windows.
i was a bit perplexed. as a noob, i would never have thought of syncing archlinux-keyring first (i also had to remove pipewire-jack because it was in conflict with jack2). an OS should be able to update out of the box and a problem like this might dissuade other new users from considering EOS…unless this is only a VM problem, in which case disregard everything i said. lol.
also, should i not use yay and stick with pacman? i’ve only encountered yay on EOS thus far.
Doesn’t matter whether you use pacman or yay they do the same thing. pacman is the official package manager on EndeavourOS (and Arch) and only works with packages in the repos.
yay, in addition to doing everything pacman does, is also an AUR helper, which means it helps you locally build packages from the AUR and install them, and it also keeps track of them so it can update them.
If you are not using the AUR, the only advantage of yay is that it’s less typing. For updating, yay is only 4 key presses, while sudo pacman -Syu is 17. You never run yay with sudo.
Also Windows and Linux are in general are two very different OS. And not just in the structure, package management etc. I mean philosophically different. Very little or in case of Arch - no hand holding. Doing things the easy way isn’t the point. Some Windows users feel Linux goes out of its way to make things difficult. That isn’t the point. Point is the user should know the system he/she is using like the back of his/her hand. In short:
YAY is used to install packages from the AUR like google-chrome where pacman is used system wide without the AUR. I use both even though YAY can also update the system including AUR where pacman can not however I used to use yoart (whatever it’s spelt) before YAY came along which didn’t support system wide updating if I remmber correctly haha
This is where the mindset behind linux distributions, and especially behind arch-based rolling distributions is significantly different from Windows. There is no ‘box’ so to speak for the rolling release linux distributions.
Win 11 gives you a small set of changes you can make to themes and simple UI elements - so in trade for giving up configurability and infinite choice, you get to expect/demand that MS provide flawless updates with no blips or issue … after all, they control everything end-to-end. Even in this best case scenario, MS still has occasional problems and issues.
Linux distros, and particularly rolling distros, are another beast altogether. You get infinite configurability and choice - pick your window manager or desktop, compile the kernel with custom performance tweaks if you want, use any of a number of different applications … However, the tradeoff for this flexibility is that it is quite impossible for every permutation of options, settings and software to be tested for every possible defect. This is part of the realistic trade off for flexibilty … some responsibility or willingness to run an extra command to take an extra step or two every now and then to keep things running smoothly.
My only recommendation would be that if you really need/desire the flexibility enough … stick with things for a bit. You will quickly pick up on the ‘usual nuances’ of updating. You will become adept at getting help on forums like this (if you really stick with it you will end up providing help to others on forums like this! ) With a little bit of time and effort it all becomes second nature and isn’t even ‘extra effort’ in the big picture.
it wasn’t a matter of me not understanding how to update, it’s a matter of the update tool failing due to conflicts and unknown keys.
using the latest ISO in offline mode (xfce), a system installed in which the update fails. i had to apply a fix suggested in this thread to work around the problem
when i reinstalled the system using the online option (xfce again), the errors were not there. this suggests to me that the problem was fixed, but the raw data on the ISO still has them.
On any Arch-based system, updating your system sometimes requires manual intervention. The chance of this occurring is greatly increased the longer you go between updates. The current ISO is quite old so when you do an offline install right now, you are getting 4 months worth of updates at the same time. That will almost always require the keyring be updated prior to updating the system.
This isn’t a bug or a problem with the data. The online option installs the latest packages so you weren’t doing 4 months of updates at the same time and thus had no problems with keyring.
That isn’t the point. Point is the user should know the system he/she is using like the back of his/her hand. In short:
) With a little bit of time and effort it all becomes second nature and isn’t even ‘extra effort’ in the big picture.