Feedback from a relatively new user to Manjaro

Feedback
1

I’m a relatively new user to Manjaro. I started using it as my primary system a few months ago, though I’ve had it installed for over a year now. I’d like to weigh in on this discussion that’s been had a thousand times before and will continue to plague Linux forums for the foreseeable future.

I’ve been learning quite a bit to maximize my Linux experience, expanding my knowledge on things like terminal commands, file structures, and customizations. I understand the importance of having un-ignorant users, but I also think that currently Manjaro leans slightly too far into the “inconvenient for common users” category for me to actually recommend it to my friends and family. I think simple things like app updates (especially official packages) should be automated. Most of us simply run something like
pamac upgrade -a
and approve the updates without too much scrutiny. We only verify the packages when errors pop up. An automated system can do the same, just run the updates and then notify the user only if errors occur.

On a related note, this is my first time hearing about a .pacnew file that needs to be checked and merged. I understand the concerns about conflicting merges, but the bare minimum would be to have some kind of notification alerting me that something needs to be done.

Basically, anything that can be generally safely done automatically, should be automatic. Any errors that occur or problematic changes should notify the user, maybe even including a prompt to automatically fix it if it’s a simple error. For example today I ran into an error because several files couldn’t update because obsolete versions of electron depended on them. The error said I should remove the obsolete versions of electron, so I did and now everything is able to update without any issues (with a side note that I am getting an error that says
cp: cannot access '/var/lib/pacman/sync/download-KybrPN': Permission denied ).

Edit: I’m pretty sure that KybrPN thing was just a locked temporary directory that somehow got stuck, so I deleted it and have no issues

2 Likes
2

It is common misconception that Manjaro Linux is the maintainer of your system.

Manjaro Linux provides the package you are using but you are the system administrator, how you apply them is on you.

Read more in → Update - error: failed retrieving file 'community.db' from

The pacman.conf was updated 2023-05-21T15:55:00Z to remove the deprecated community repo - see the above link.

There is always a message on the console informing if a <pkg>.conf.pacnew has been created.

The same messages can be found in pamac - use the lower right arrow button to see the output.

If in doubt run pacdiff with the -o argument - as this will simply list if any changes need to be addressed

pacdiff -o
7 Likes
3

You have this backwards.

Whatever packages were concerned actually depended on updated Electron version(s) – an important distinction.

Removing the old electron<version> packages was the right thing to do in this context. This would allow the sync to be performed successfully, and the updated Electron dependencies to be included with the update.

Alternately, one could install the electron meta-package which automatically installs the current (latest) Electron version from the official Manjaro repository; in this case electron34.

2 Likes
4

How do you propose that would be accomplished? Even Microsoft can’t do that reliably–no matter how many times they’ve tried in the last 40 years.

Please see:

8 Likes
5

I’m also new to Manjaro—ten months since beginning the testing and messing around phases, and only five months as a daily driver. It’s been an eye-opening experience for me. And a satisfying one.

It’s cliché to compare computers to automobiles, but at the end of a busy weekend, you’re stuck with cliché.

Just because someone learns to drive in a Kia automatic doesn’t mean it’s the only—or even proper—way to do things.

First, Kias are terribly insecure. The rate at which they’re stolen (At least here in the U.S.) is astonishing. Not unlike compromised Windows computers, come to think of it.

(I was once asked why I carry a USB-A drive on my keyring. I replied, “In case I need to steal a Kia.” I’ve been thinking of changing to a USB-C on my keyring, but then it wouldn’t start a Kia.)

Second, automatics are not the be-all, end-all. Some people prefer the stir-it-yourself method and choose standard transmissions. This does not mean they are wrong or that it’s a bad choice. It’s simply a different preference.

Say you want to move on from a Kia automatic to say, a Porsche 911 or at the other end, a dump truck. Would it be reasonable to assume the 911 or the dump truck should behave exactly as a Kia automatic does? Or that they be the same as each other? Air brakes? WTF are air brakes? Or the case of the 911, why the hell is the motor in the back?

Then why make the assertion that Manjaro should be like other Linux distros?

You state, “Basically, anything that can be generally safely done automatically, should be automatic” which is a valid viewpoint. Not arguing that. It is also the viewpoint of Microsoft and a great many other Linux distros.

You may think that because all those other people do it that way that it’s the right way to do it. I say, misery loves company.

The equally valid viewpoint here is that the system administrator needs to take direct and personal responsibility for maintaining their system. Which is the opposite of automation. Automation is sidestepping responsibility and letting someone else take the helm. Remember, when it goes off the rails and you point the finger of blame, there are three more pointing back at you, the person who shirked their responsibility.

I’m guessing—remember, I’m new here too—that it comes from a position of suspicion. The open source community as a whole is extremely vulnerable to miscreants precisely because it is open. (Not unlike Kias.) Thus, the people who work within it are a suspicious lot, on the lookout for maliciousness buried in someone else’s code. You may want to read up on Software Supply Chain Attacks.

That’s where things like pacnew files come from. Did the installer maliciously overwrite a file? (Or perhaps only unwisely, stupidly or impolitely.) Better to have a look and compare than to let it go by. Simply because other distros let a user’s files be overwritten doesn’t make it right. Bear in mind that you’re also welcome to ignore pacnew files. No one has a gun to your head. But when you want to point the finger of blame…

So yes, things are done differently here. Isn’t that why you’re exploring? Looking for something different from where you were?

“Different” does not equal bad or wrong. It simply means another way of doing things. And in the case here, “different” means asking for a bit more user responsibility, knowledge and involvement rather than behaving as an automaton.

That works for me. Maybe after some thought you’ll find it works for you too.

7 Likes
6

Remind me of the essay I found some time ago - reproduced at

→ Essay "Linux is Not Windows"

2 Likes
7

Yes, I liked that and bookmarked it. Along with another you posted, Essay "The Real Reason We Use Linux"

2 Likes
8

I came across this thread now…
The notion of mostly automatic operations is - to my opinion - very important. It’s related to the reversed reasoning on the end of the 2006-essay: Why should Linux want me?
That should be one of the most important questions for Linux advocates (and developers) that should be kept in mind as if they were users without the curse of knowledge (I encountered the term in Made to Stick by Heath & Heath).

That Microsoft has buried the commandline interface under the hood, is - of course - intentional, considering deep wishes by users of selfexplanatory system handling. A GUI with tooltips is almost unbeatable in this respect.

But one can “sell” the virtue of the CLI in the context of seeking help in the internet. Windows users are confronted with numerous screenshots that show them how to do the given operations that must be executed. In Linux marketing, the CLI should be presented as a far more efficient alternative that’s commonly used in the web and e.g in stackoverflow flavored pages: CLI text snippets that the solution seeking user only has to copy & paste. “uh, is it that simple?”
But “that simple” to enter a command sequence out of my own is of course a totally different thing, because you must then understand what you do. That’s also a main reason why package management (Software, apps install!) must provide an intuitive GUI frontend - a weak point in the majority of Arch-based distros.

Referring to the Automobile comparison in the 2006 essay:
I’d see that a different way. It’s not about automobiles or motorcycles, but to my opinion very well inside the category of automobiles.
There has been an era before 1989 that buyers in East-Europe have had very little choice. The widespread “default” automobile in the GDR was Trabant. In the analogy I’d compare Windows and Trabant (and indeed, in early days, Windows were as prone to technical issues as Trabant).
Having said that, the Linux ecosystem is represented by the sheer choice of different models and designs, including motorizing options). You know: the sheer choice in automobiles is a terrific success story! Why the hell fails any Linux marketing to point out that the sheer choice is also expression of freedom, etc! Contrary to Trabant/Windows: both are like autocracy. You have to take what we offer! (this is truly a driver of many people in the desire to find an alternative)

I believe I know why the sheer diversity in automobile models is a success factor and sheer Linux choice not: Cars are on the street. Computers are at home. Simply stated: There is no such thing as falling in love with that one car model that I saw. Yes, you could have some luck. When you’re visiting a friend at home and he is truly proud to show his Linux system with KDE (I mentioned KDE because its recent state is sooo eye candy that you could fall in love with it, especially when you like sophisticated features and tiny but nice details (high end automobile). Another guy would proudly present his GNOME with its innovative paradigm (small “concept” car).
But in one-to-one meetings you can hardly push market share forward. After all: this is sort of missionary. Falling in love with an automobile model is not.
It’s not why should I want Linux; or Why should Linux want me?, but how can Linux (Distro) attract me? Attract is more related to emotion than want. And emotions are often more powerful than rationality.

9

That’s only an important question for the Distro builders/marketers. Which has absolutely nothing to do with Linux, except using the Linux kernel. Again bringing it all back to “Why should Linux want me?” Because Linux is not a/the distribution.

1 Like
10

I really don’t understand how some people find Manjaro to be a difficult system to operate and maintain. It really isn’t that hard:

  1. Read update announcements before updating
  2. Maintain immediately any .pacnew or .pacsave files created by an update
  3. If a problem is encountered, search the Manjaro Linux Forum and open a support topic if necessary. Also, the Manjaro Wiki is full of useful information/instructions.
  4. Avoid asking AI for help if an issue is encountered as LLMs are usually a year or more out-of-date - a long time for a rolling release. Plus LLMs know nothing - they are just an advanced form of predictive text. The Manjaro Linux Forum should always be the first option when you encounter an issue, not the last option.
  5. If that is too hard or too time-consuming, then you have other options: [Consideration] Is Manjaro the right distribution for you?
3 Likes
11

IMHO these two are the most important. That, and not being afraid to roll your sleeves up and get your hands dirty.

1 Like
12

You really picked the most (the only?) Linux-like car ever for your analogy.

A whole lotta love.

13

Please, many of the people who ask questions here can’t be bothered to learn how to edit config files as root.

14

As other posters have alluded to, Linux is not a single operating system unlike Microsoft Windows or MacOS. Different communities/organisations create their own Linux distributions using the Linux kernel. And if you generally divide these different distros into 3 categories: fixed release, fast rolling, and slow rolling, they all have their distinct characteristics.

In general, if you want more “brainless” one-click updates with graphical package managers, you would go for fixed release distros [eg Debian, Ubuntu, Fedora] because they don’t change their base or foundational packages/libraries. Any updates are minor [in comparison to, say, Arch-based rolling distros] and don’t affect the base, which is why it’s easier to have one-click updates. They have a limited support life - between every 13 months to 5 years - after which the user either has to do a fresh install of the latest release version of the distro, or they have to replace the repo sources of their distro with the repos that point to the latest release version of the distro and then carry out a HUGE system upgrade [and the latter method may often require manual intervention along the way].

If you choose fast rolling distros like Arch-based distros, you have to take ownership of your own system and carry out maintenance, check update notes before installing updates, occasionally carry out manual interventions. That is the price for having the newest packages, not having to reinstall your system, and having the packages and config files on your system live there indefinitely. If there are significant changes in an application or desktop environment or even the distro’s repo sources or how the package manager works, you may have to review and edit your config files accordingly. If an app is no longer maintained, you have to remove it and find a replacement.

For slower rolling distros [eg Solus, PCLinuxOS, Void], perhaps you can get away with mostly not maintaining your system. But do they have the software you need, which you can find in Arch/AUR ? Are you ok if they use non- systemd init systems [PCLOS, Void]? Are you ok with mostly using CLI for installation of distro and updating your system [Void - yes , there is octoxbps graphical package manager but generally it’s still better to do system updates, remove orphans and old kernels, in the terminal]. If the answer is yes to those questions, maybe you can consider those other distros.

You have to weigh the pros and cons before choosing the type of Linux distro you want to run. They are not the same.

If we return to the car analogy, you could think of fixed release distros as a car that you totally don’t maintain at all and which you are willing to run to the ground, since you are going to scrap it and get a new car after 13 months to 5 years anyway. For fast rolling distros, these are like a car you will use FOREVER. So you have to keep maintaining it, changing parts once in a while etc, in order to keep it running.

Note: KDE or Gnome are just desktop environments, ie part of the software. That is not the distro itself. Different categories of distros treat the desktop environments differently. For instance, in Debian Stable (currently Bookworm release), KDE plasma is still version 5+, since it’s not a rolling distro. Plasma 6 isn’t going to come until the next Debian Stable release (trixie). The plasmoids that no longer work in Plasma 6, are still happily working for Debian Bookworm users, and if they don’t care for having the latest version of Plasma, they can continue using Bookworm and plasma 5 until end of support in mid 2028 [they could use it even after that date; they just won’t get any more updates]. Things don’t work like that in Arch/Manjaro.

4 Likes
15

That’s the single hardest thing for many people today. We’ve somehow created a society where one can assume everything will work okay despite one’s ignorance. Therefore, reading is unneccessary.

Excellent. Far better than mine. I may steal it. (As one might a Kia.)

3 Likes