So I’ve been iso live testing Manjaro KDE Plasma lately and it looks very polished.
On the other hand, there is a negative vibe towards it.
Why the hate?
I used Manjaro for about 3 years
Its great but packages tend to break over time with it being a “stable” arch build
Over that 3 year period updates managed to break my install at least 30 times
Switched to Endeavour over a year ago and haven’t had an update break my install yet
EndeavourOS is such a good replacement for manjaro
Wow. 30 times in 3 years? I wonder if that’s specific packages or hardware you had. I had 5 computers (2 desktops, 3 laptops) running Manjaro for so many years, and still haven’t had a single system break. Including using a lot of AUR packages.
Though last year, I’ve moved all of my computers to Arch, Debian, and Proxmox. Arch mainly because I wanted to fully configure my systems more.
I used to be a huge Manjaro fan. There were many ways it let me down, some of which were just bad governance.
The biggest problem though is the AUR. Manjaro uses packages that are older than Arch. The AUR assumes the Arch packages. This, if your use the AUR with Manjaro, your system will break.
It is not a question of if Manjaro will break but when. Every ex-Manjaro user has the same story.
For me, EndeavourOS is everything that Manjaro should be.
I am not the most technically astute person, using Manjaro and the AUR for like five years and never had my system break. Yes, some package problems here and there, but where do you not have them ever? And so far nothing an internet search couldn’t fix. I found it very stable both in the XFCE and the KDE spin.
The AUR doesn’t assume arch packages, if the package your aur script wants isn’t in your repo then the package simply fails to update/install.
Edit: This is true even for Arch linux, as the Aur package might be out of date.
The AUR doesn’t assume arch packages, if the package your aur script wants isn’t in your repo then the package simply fails to update/install.
Edit: This is true even for Arch linux, as the Aur package might be out of date.
The problem is not the package. It is the packages Version. If you have for example an application that depends on .net 7.0 and arch updates it to the latest 8.0 then the AUR usually gets updated soon as well. Now the AUR pqckage depends on the newer 8.0 Version while manjaro still has the 7.0 version. The programm now does no longer start on manjaro.
There are many cases where Manjaro causes problems. For example, a package mag already be in Arch but not yet in Manjaro. Or perhaps the Manjaro package is not a high enough version number. If another Arch package requires this first package, in Arch it would grab the Arch package. The Arch package will be maintained over time. In Manajaro, the package is not there and so the AUR grabs it from the AUR as well. Perhaps it is even the Git version with an unclear version number. Over time, the AUR dependency breaks or becomes unmaintained. Even once Manjaro has the package, it may not migrate it because of the version numbers. Now things are broken. This exact thing happened to me on Manjaro where my GIMP ended up using GEGL from the AUR. My system was broken for months.
An even worse problem can happen when there are alternate dependencies. Sometimes in the AUR you will have multiple packages that fulfill a dependency. In Arch, you can see if one is from the actual repos and one is itself from the AUR. Again, if you choose the one in the repos, it will work and stay supports. In Manjaro, neither may be coming from the actual repos in which case it is easy to choose the wrong one. This sets you up to have package conflicts. In Manjaro, I would never know that the other option had now been added to the repos. More than once, I had the dependency that I had chosen break when the other would still have been fine.
Ok, this is getting long and that was just a couple of scenarios.
Suffice it to say, when I used Manjaro, I got the impression that the AUR broke all the time and that using the AUR broke my install from time to time. Now that I use Arch, I do not have those issues and I realize that it was Manjaro all along.
That’s not how source packages work. The only way they’d break is in case of major upstream changes. Which do happen, but the only inconvenience would be recompiling the package. Which you’re supposed to do anyway.
Do you reinstall your AUR packages after an update? If yes, you will never see them break on Manjaro or Arch. If you don’t, they will break on both Manjaro and Arch.
I am not theorizing. And I am not taking about source code not compiling. I am talking about dependencies which includes the reports version numbers and version number expectations of packages maintained by different parties. Those broke all the time for me on Manjaro and it was often because of the differences between what was in the Arch repos vs the Manjaro repos.
When Manjaro fell behind at one point, I ended up with a version of GEGL ( labeled - git ) being pulled from the AUR. Later releases of GIMP refused to upgrade over that version of GEGL. I just lived with it for a few months hoping it would clear itself up but it never did. I basically had to back everything my out and install again. Not that it was hard but these kinds of annoyances happened for me all the time on Mnajaro and basically never on EbdeavourOS or Arch.
What made me move away from Manjaro to begin with were all the problems it had with the dotnet packages at the time. I blamed dotnet and the AUR and was amazed that the problems went away when I used EndeavourOS instead.
If what you describe were true it would make AUR packages fail (on any Arch distro) if the user failed to upgrade their system each time, every time an update came out. The two week delay practiced by Manjaro is a completely arbitrary period of timen in the grand scheme of things. There are users who only upgrade once a month or even more seldom and nothing like this happens to them.
the package is not there and so the AUR grabs it from the AUR as well. Perhaps it is even the Git version with an unclear version number
You will see that the aur package will use a git version and you will also be asked to remove the conflicting package when you are installing a git version.
And once again, this isn’t unique to manjaro, on my arch install yuzu broke because they were using dynarmic from the aur instead of using the one provided by yuzu itself.
Also gimp and gegl are already on both the arch and manjaro official repos, If you are using git packages and you don’t update them lots of things will break regardless if you are on any arch distro.
Now I wonder if pamac checks for updates of git packages by default, because your git packages will not be updated unless you explicitly tell yay to do so (yay --devel) I think paru every does it automatically with every update but then again most people will use yay instead.
Suffice it to say, when I used Manjaro, I got the impression that the AUR broke all the time and that using the AUR broke my install from time to time. Now that I use Arch, I do not have those issues and I realize that it was Manjaro all along.
My experience has been quite the opposite, a few months ago my install broke to the point that I could not update the system, turns out it was because of the arch migration and my system wasn’t incorporating the new pacman.conf.new.
Endeavour is basically Arch but with bling out of the box & an easier installer…
What bling¿? I thought endeavorOS was very minimalist as well. Just arch with an easier installer
Bling as in pre-installed themes…
if your use the AUR with Manjaro, your system will break
Oh, bullshit.
Yeah. Notice how he doesn’t mention how Manjaro holding back packages can actually prevent breakage that Arch users have to deal with.
The manjaro hate-boner is just tribalism and elitism. Every one of these threads reinforces that.
if your use the AUR with Manjaro, your system will break.
If your system breaks because of AUR it means you’re using AUR wrong… you’re not supposed to use AUR packages for critical system functions. It will break on Arch too if you do that.
This, if your use the AUR with Manjaro, your system will break.
Been using Manjaro with the AUR for 3 years, never had the breakage you described.
Most of the hate is because of the maintainers not maintaining their security certificates. Another similar distro is EndeavourOS, which I personally prefer. But either way, find what works for you.
Just out of curiosity I’ve looked for that a couple of months ago and I found that it’s relatively easy to transform a Manjaro installation to Arch and Endeavor. IIRC it was just adding new repo keys and changing the repos. People attempting that would have to look the guide up for details.
There’s not really any benefit of running Manjaro over Arch, it will only introduce problems over time. If you want a “pre-configured” Arch with a nice installer, go for EndeavourOS, it’s great!
Manjaro has graphical tools that make it super easy to manage packages, drivers and kernel versions.
I‘m pretty sure you can install a GUI for pacman on Arch/Endeavour.
You can but there isn’t a lot of choice, Octopi is pretty much the only other pacman GUI besides Pamac that’s sufficiently fleshed out. All the others are either just package searchers or CLI-only.
And Manjaro also has the Manjaro Settings Manager, which includes the kernel management module and the hardware drivers management module.
I just wanna point out, people were using this exact same rhetoric when Antergos was a thing.
Antergos is no longer a thing. Just saying. Manjaro still is though! I believe it’s older than endeavor OS.
Even if Endeavour stopped development tomorrow, I could still use and update my system normally because it’s using the regular Arch repos.
Just give it a go. I used it for years, and had relatively little issues tbh. Most of them I think are hardware related as I’ll have similar issues in other distros and even windows.
The devs have done some goofs yes. Things like letting certs expire, and as mentioned already, potential issues with aur. But, I remember having aur issues even with vanilla arch in the past.
Using fedora currently though, and I don’t think I’ll switch anytime soon.
Fedora is great, very leading edge but stable AF
Manjaro for some reason can’t stop breaking crap, and when they do break crap, they aren’t exactly elegant about it
Been using it exclusively for 3 years, never had breakage.
I wish I was that lucky, the final straw for me was the grub-customizer shenanigans, manjaro pushed an update that broke grub customizer boot entries, then when users were trying to figure it out, they removed grub customizer, and then they even went so far as to make grub conflict with grub-customizer which was really asinine. IIRC they even wound up locking the forum thread on it
It’s not all “purists” and “tribalism”, Manjaro actually has issues. Besides the well known certificate issues and older packages, I have the following anecdote which made me really dislike it.
A friend has Manjaro and one day his nvidia drivers stopped working after an update. I helped troubleshoot over the phone, while looking over the wiki. For nvidia drivers they have their own wrapper around pacman.
Turns out there’s a different nvidia driver for each kernel version. Already a stupid design. So unlike arch where there’s 1 kernel package (the latest the distro offers) and 1 matching nvidia driver, Manjaro has dozens…
The wiki never mentions how to install or update the drivers manually with pacman or anything like that. It pushes their own tool, a stupid wrapper around pacman, which is supposed to manage this for you.
In my friend’s case, the tool failed. It was trying to run pacman but there was a conflict issue. But the tool didn’t show the pacman output, so we couldn’t figure out what the tool is trying to do, and why it doesn’t work. We tried removing the tool and re-installing, and all kinds of messing around with it. It failed to install the drivers, it failed to remove the drivers, it kept failing whatever we tried.
Eventually we figured out the naming convention they used for the packages (again not mentioned in the wiki), and manage to install the correct kernel - driver pair manually, using pacman.
Tl;dr: poor design, bad documentation, and they push their own crappy tools which hinder instead of helping
there’s a different nvidia driver for each kernel version. Already a stupid design
That’s not a stupid design at all. A nvidia kernel module artifact is only compatible with exactly one kernel ABI. Thus you need one binary nvidia package for each kernel you ship.
Arch also has one package for every kernel ABI they ship:
nvidiaandnvidia-lts.
Though it should be noted that their design assumes that these two ABIs are the only possible ABIs which isn’t strictly the case as the zen, hardened or RT variants may sometimes lag behind their regular counterpart. That’s a stupid design if anything as it increases the friction of kernel ABI upgrades as a kernel package maintainer.We at NixOS also ship the nvidia module for each of our ~50 kernel variants; all major versions of the Nvidia module compatible with that kernel in fact.
The only possible way to access these nvidia kernel modules is via a certain kernel’slinuxPackagesattribute set that contains all packages that rely on a kernel ABI such as kernel modules or packages likeperf. That’s good design if you ask me but I’m obviously biased ;)I know you need a new nvidia driver every time the kernel updates, but why keep 50 kernel versions? My beef was them offering so many (outdated) versions instead of keeping the latest one which would make things very simple for users (imo).
These aren’t all versions per se but mostly variants, versions and versions of variants. For example, we have packaged the xanmod kernel which is a modified kernel optimised for desktop use but it has two variants: Main and LTS. We have packaged both.
Here are the names of all of our kernels currently to give you an idea (as a JSON list):
[ "linuxPackages", "linuxPackages-libre", "linuxPackages-rt", "linuxPackages-rt_latest", "linuxPackages_4_14", "linuxPackages_4_19", "linuxPackages_4_19_hardened", "linuxPackages_4_9", "linuxPackages_5_10", "linuxPackages_5_10_hardened", "linuxPackages_5_15", "linuxPackages_5_15_hardened", "linuxPackages_5_18", "linuxPackages_5_19", "linuxPackages_5_4", "linuxPackages_5_4_hardened", "linuxPackages_6_0", "linuxPackages_6_1", "linuxPackages_6_1_hardened", "linuxPackages_6_2", "linuxPackages_6_3", "linuxPackages_6_4", "linuxPackages_6_5", "linuxPackages_6_5_hardened", "linuxPackages_6_6", "linuxPackages_custom", "linuxPackages_custom_tinyconfig_kernel", "linuxPackages_hardened", "linuxPackages_latest", "linuxPackages_latest-libre", "linuxPackages_latest_hardened", "linuxPackages_latest_xen_dom0", "linuxPackages_latest_xen_dom0_hardened", "linuxPackages_lqx", "linuxPackages_rpi0", "linuxPackages_rpi02w", "linuxPackages_rpi1", "linuxPackages_rpi2", "linuxPackages_rpi3", "linuxPackages_rpi4", "linuxPackages_rt_5_10", "linuxPackages_rt_5_15", "linuxPackages_rt_5_4", "linuxPackages_rt_6_1", "linuxPackages_testing", "linuxPackages_testing_bcachefs", "linuxPackages_xanmod", "linuxPackages_xanmod_latest", "linuxPackages_xanmod_stable", "linuxPackages_xen_dom0", "linuxPackages_xen_dom0_hardened", "linuxPackages_zen" ](Note that some of these are aliases;
linuxPackages_latestis currentlylinuxPackages_6_6for example.)Each of these has the following
nvidiaPackages(modulo incompatibilities):[ "beta", "dc", "dc_520", "latest", "legacy_340", "legacy_390", "legacy_470", "production", "stable", "vulkan_beta" ](Again, some of these are aliases.)
This is useful to have because users might have hardware constraints. It’s not hard to imagine a scenario where a user might have a WiFi chip that only works with kernel ABIs < 5.4 and require the 470 nvidia driver for their old GPU. Packaging just the latest kernel and just the latest Nvidia driver would make this user unable to use their system.
Turns out there’s a different nvidia driver for each kernel version
That is literally every version of Linux out there. IDK what you think was different about Manjaro in that respect. Nvidia hates linux and it’s a tough thing to keep it running, especially on a rolling release. Use the DKMS driver if you’re going to update kernels a lot. At least manjaro seperates the kernel installs from the general updates to minimize this disruption.
I know that these packages are “linked”, and for every kernel update you need a new nvidia driver, I don’t understand though why they keep so many kernel versions in the repo (and their respective nvidia drivers ofc). Just makes things confusing, I assume people generally want the latest kernel the distro has to offer, or if they want something else it’s a different kernel “flavor” like lts, zen, rt, etc.
It’s not all “purists” and “tribalism”
I disagree.
I’ll keep it short and sweet.
I’ve been using Manjaro for about 6 years now.
When I had an Nvidia GPU, it would break after quite a few updates and need a rollback.
Then I moved to an AMD card, and I haven’t had any issues at all.
Like…at all.
The End.
I have manjaro running on six machines. No problems that were not Just part of learning. Two of those computers were for testing different distros… All ended up with Manjaro.
Hate is for people that don’t create, or improve their own world.
While on one hand Manjaro is very polished. Some things they do is questionable. Like the time they suggested to change your date and time because they let their repo keys expire. Or accidentally DDOS the AUR. Just to name some. The Manjaro team has a rather bad track record of these things.
That stuff is negligible compared to Mint getting hacked and hosting a malicious ISO.
But for some reason you never hear people mention that about Mint 🤷
deleted by creator
I am currently using Manjaro as my main Laptop OS.
Most of the hate is philosophical based in small often overlookable facts. And how Manjaro uses/is compatible with the AUR. There’s a whole github dedicated to the communities complaints here: https://github.com/arindas/manjarno
While I can see why many don’t like manjaro, I personally see these complaints as a way to evaluate the company to see if they improve.
My experience with Manjaro is about 1-2 years now. And the OS is very stable, honestly more stable than my brief time with Fedora.
But I did break a lot during that time including my DE. However as long as you are careful on where you install from, the distro will be stable.
Install order
-
Official Repo - this is delayed by a few weeks to “validate stability”, one of the sticking points for the community
-
Flatpak
-
AUR - due to the delayed official packages some AUR packages won’t update immediately, or will cause conflict when they are.
AUR support is honestly the only valid issue with Manjaro. Due to the delay AUR packages will break as older dependencies aren’t being updated causing a large string of removals which can cause stability issued in Manjaro.
My recommendation is to avoid the AUR unless the package isn’t found elsewhere. Which is a problem if you installed Arch for AUR. Thus EndeavorOS is preferred.
But for my usage I prefer the graphical interfaces for all setting. With the exception of GRUB, there is a GUI for everything and you won’t need to touch a terminal.
With that said, you may want to look into OpenSUSE or Fedora/CentOS, and they are similar in terms of GUI settings. And are a little safer since OS level packages are behind another package manager.
But at the cost of less software. For me I’m stuck with Manjaro for now, and as soon as Slimbook battery is officially on Fedora trying that out again.
I have something like 70 AUR packages on Manjaro and doing fine. Yes, they break every once in a while. They break on Arch too.
The thing is, you have to update AUR packages. They’re compiled against a certain system state and they will break eventually as the system updates. This will happen with source packages on any distro. It has nothing to do with Manjaro.
Agreed.
Are you saying that as an Arch user or a Manjaro user? Have you ever used a different Arch distro? I am just wondering how many of the “other Arch distros are just as broken” people have actually used both. I have used several. In my experience, Manjaro stands alone in terms of the number of problems I have had. I guess I am just unlucky.
I’m saying that your problems are with AUR not Manjaro. It’s entirely possible you stumbled across some AUR packages that at a given time didn’t play nice with the official packages. The AUR is huge, it can happen.
But it could have also happened on Arch proper, two weeks earlier, no? The official packages were the same at that time.
I think you were put off Manjaro because it happened while you were on it and if you were to try again it could be different. But once we catch a bias against something it’s hard to revisit it.
I’m biased against Ubuntu and love Debian, for example, even though I realize that my issues with Ubuntu had to do with the way .deb repositories work and could happen with Debian, or that done of the things I disliked were just defaults that I could (and did) change.
Ultimately it’s as much a question of chemistry or vibing with a distro as with anything, and sometimes it helps to move to another distro even if they’re closely related under the hood.
-
I have almost a dozen installs of it in the wild for a few years now, with friends and relatives that aren’t very computer literate. It has been virtually maintenance free. This is on wildly disparate hardware as well, and it’s always installed nicely and with little messing around after to get things working.
People like to hate on it; it’s been by far the most reliable distro I’ve used, far better than "just works^TM " distros like Fedora and Ubuntu. I’d ignore the naysayers and use if it works for you.
Besides the points made - using their own repos. It kind of defeats an important point of using Arch, if you don’t use the official repos as your main source of packages imo.
It’s a rolling release. You have to let it roll. Arch already has testing repos, there is zero need to test outside of them.
there is zero need to test outside of them.
Then how do you explain Arch users have to deal with breakages Manjaro users do not because the Manjaro team doesn’t push updates as quickly?
Because they don’t push updates as quickly, which reduces the chances of something slipping through, be it their merit or not. This comes at the expense that it sometimes breaks dependencies and still has close to zero real benefits:
-
You are better off simply using snapshots. Then you don’t depend on the testing of either party.
-
Even if the Manjaro devs do to find bugs, they could have found them in Arch Testing as well, which benefits everyone.
I stand by my point that the update strategy is not a feature.
- I have snapshots included as well.
- Bugs found even in Testing and Stable can be prevented from entering Manjaro repos!
I stand by my point that the update strategy is a feature. You might not understand this, but my experience speaks for itself!
-
I’ve been using Manjaro for about 7 years at this point. I’ve had issues maybe 5 times, and nothing I couldn’t fix.
