AMEN!
A rolling release is just that to have the latest and the greatest. If one is not going to keep it updated or do not know how to handle small problems, then there is other Linux based operating systems that are not rolling releases that are very stable.
As Dalto and other advanced members would say, Arch is stable. This is true.
So we should start saying, âthere are other distros that are very staticâ.
Worded well I wanted to say something along these lines but everything I typed just sounded like I was being a bit mean when I read it back to myself.
That is the how those releases should be labelled over rolling vs stable. Iâve had more stability on rolling than static releases when it comes to updates
âOut of the boxâ, before you install and configure everything you need ? Yes.
The terms I use when people ask about the difference is: cyclic releases (say Ubuntu, with a release cycle of 6 months), and rolling releases (like arch, with continuous updates).
Just my 2 cents, though.
Edit: typo.
Although that term
would make me ask what you are talking about it is much better than stable as that is not really what it is it is just âfrozenâ in a manner of speaking
Thinking an extra 2 seconds that is probably better as it would be explained to me what the difference is between these in a way that makes more sense with wording like this
The UI/UX for updating Arch has been discussed at length in several other threads. Letâs not get into that here.
Which threads?
I should have known this would be taken as an opportunity for a snarky response. I imagined it apparent that any forum user is aware the search function exists. I searched, and there are threads that are all over the map in terms of actual topic, and mostly just mention a keyword but donât really align with your description of âdiscussed at length.â Do let me know what search terms you might suggest beyond the obvious but generally unhelpful âuiâ and âuxâ, which are in fact not allowed as a search term due to length, and âlinux uxâ, which is all too vague to find specific discussions.
You wrote as if you had read or participated in various threads that were focused on this aspect. One could give the benefit of the doubt that I, directing my message at you, was asking for what threads you are specifically referring to. I was genuinely curious to see what âlengthyâ discussions were had.
I respectfully disagree.
One of Arch Linuxâs core philosophies is simplicity, which can be understood as âwithout unnecessary additions or modifications.â The whole point of the distro is to provide a minimal installation so that the user can make their own customizations. It is catered to DIY users, which means that if there are certain tasks that youâd like to automate, youâd have to do it yourself. And since Endeavour endeavours (no pun intended) to be as close to Arch as possible, this philosophy is applicable (at least to some degree) here as well.
How would you define âpoor designâ in this case? Does that pertain to the rolling-release model or are you referring to something else? If you donât update frequently, signing errors are inevitable because the keyrings are out of date. Therefore, you would need to manually sync the package database, update the keyring package, and then perform the system update.
Iâd also like to point out that whatâs âintuitiveâ is highly subjective. Sure, the user can build a GUI with a âfix keyringâ button if they want to. Or they could just add the following alias into their .bashrc
:
alias fix-keyring="sudo pacman -Sy --needed archlinux-keyring && pacman -Su"
In my view, there really isnât much of a difference between the two. But since I spend 80% of my computing time on a terminal emulator, I honestly find doing things via the command line much more intuitive. The same cannot be said for all users, of course. In which case, Iâd like to point out the fact that EndeavourOS is a terminal-centric distro with significant emphases placed on terminal-centric workflows.
This brings us to another point. Sometimes, the issues that require manual intervention are highly specific and designing a âsilver-bulletâ type UX to resolve them is simply not feasible. The most you can do is to have the âupdateâ button refresh your mirrors and update your keyring if youâve gone a long time without updating, but that doesnât guarantee that manual intervention is not required. Maybe the mirrors are out of sync. Or maybe thereâs a packaging issue with an AUR package, and so on and so forth. Thatâs just due to the nature of the rolling-release model. It is recommended to update frequently so that you donât have to deal with stuff that requires manual intervention all at once, which often results in the user getting overwhelmed with a barrage of seemingly impenetrable issues. If updating frequently isnât an option, then the best bet would be to use a point-release distro.
The point here is that each distro is build for a specific purpose. And obviously, that purpose will directly influence many of the design choices made. If we want the maintainers of a terminal-centric, DIY, KISS distro to constantly add a bunch of fancy UX, then what would be the whole point of having that distro to begin with? Itâs strayed so much from its original purpose that we might as well fork it and create another distro entirely.
For instance, we donât walk up to the designers of submarines and complain about a design flaw because submarines have no wheels; weâd recognize that submarines are designed to travel underwater and start looking for a car vendor instead.
Just my two cents.
Nothing.
Nobody can remember all the commands. Thatâs why there is such a thing called âshell historyâ. Maybe use a decent shell, instead of fish? Bash is pretty good, and Zsh is excellent.
Fish is quite perfect for me, actually. As I said, I used it to figure out what the command was. Its shell history is perfect IMHO.
Works pretty well.
Wasnât trying to be snarky. I just didnât feel the need to go searching for all of the threads that bring up that exhausting topic on your behalf. tired emoji
Some replies in this very post would give you an idea of what those threads contain. finger pointing up emoji
As far as search terms are concerned, I imagine âterminalâ would be a good one. thinking emoji
And finally, @anthony93 has said pretty much everything you need to read which I did not feel like retyping. So, thank you @anthony93 clapping emoji
I donât expect or want a silver bullet solution, or a fancy GUI that does everything for me. But, if these issues are unavoidable, then when it happens, I want to see error messages that are descriptive enough to understand the real problem. Maybe include a link to a documentation page that thoroughly describes the context, the problem, and how it needs to be fixed.
The sudo pacman -Sy --needed archlinux-keyring && pacman -Su
solution has not always been a complete solution for me, and Iâve had to run various other commands as well to clear the cache, reset the keyring, etc. Even so, it seems like everytime I fix the problem, it takes a different sequence of commands to finally resolve it. I see that https://wiki.archlinux.org/title/Pacman/Package_signing#Upgrade_system_regularly includes most of these suggestions. It seems expanded from times that Iâve previously looked at the page when troubleshooting this problem before.
I donât believe DIY / KISS philosophy is entirely at odds with an idea such as this:
If a pacman update sees that everything fails due to signatures / keys, add an informative message at the end along the lines of âIt appears your keyring is outdated. You may need to update or reset your keys. See .â
This sounds like an excellent idea.
Iâm afraid that if you want to see it becoming a reality, you will need to present your idea to the people in charge of the development of pacman.
Neither EnOSâ developers (unless they want to maintain a fork of pacman) nor EnOS forum can help you with that.
I strongly suggest to discuss this idea at Arch Linux forum and/or at pacmanâs Gitlab.
You give the impression to be passionate about it and most probably you could persuade the people in charge of pacman to incorporate your ideas in its future releases for the benefit of the whole community.
Go electrify them! Go!
Fish is the cause of the only reason Iâve ever needed a backup ever. Back when I still actually did them too. It broke tty and I couldnât use a terminal at all. So I complete lost the ability to update and install things. Everything else worked, my computer was just a time capsule at that point.
Just be careful. Good backups if youâre going to use fish.