Hello you all. I'm new here. Just curious, based on your own experiences, what are the greatest ways in which Manjaro has been better (or worse) than Arch Linux for you?
EDIT: I saw Why are you using Manjaro?, but I'd like to specifically know about Manjaro compared to vanilla Arch Linux, and the other thread has many replies that may have nothing to do with Arch Linux.
That's interesting. I recently moved from Arch Linux to NixOS, and one of the best parts was Nix's automatic hardware configurator which led to everything just working smoothly, so I can see how beneficial MHWD would be.
Yeah, I agree, all the modern projects are using Discourse now!
Gotcha! So it's easy, with the GUI, and just works without thinking about hardware (for most cases). Good to know. I think I'm already sold. I'll have to try it the next time I need a new distro on a personal computer.
How does it compare to Arch Linux for things like servers for long-running services? From my experience with Arch, I wouldn't recommend it for web services/apps. The biggest downside was no partial-upgrade support; because versions are always being updated so installing some new binary meant needing to upgrade everything, and therefore risking the system breaking.
Does Manjaro have options that are stable enough for that purpose? Does it support partial updates?
I agree with everything on your larger list but want to emphasize that pamac is (among other things) an AUR helper. In addition, yay and trizen are in the Manjaro repos. As far as I know, Arch has the AUR helpers only in the AUR; not in its repos, so you have a bootstrapping problem. So, if you must use the AUR, Manjaro makes it easier much easier for a newbie to use the AUR than Arch.
You can downgrade packages or keep packages from upgrading the same as in Arch. But that's just a temporary solution. (The whole system is built against the current libraries and in genral you can't keep two versions of libraries.)
Despite Manjaro being based on Arch, there are many differences between them and they do not target the same public to begin with. Manjaro has a more broad target and tries to appeal more to casual users, whereas Arch Linux targets more advanced users.
On Manjaro, you have a out-of-the box experience, with a graphical installer that can install you a entire system that will be ready to be used in several clicks, with a lot of automation and stuff chosen by default. Arch Linux is very DIY-oriented (Do It Youself), and you have to get through a manual installation and install the components you want yourself, from the most basic and core components (kernel, init system, shell) to the various applications available, steps by steps. Therefore, you have many steps to follow to even get a basic system.
As such, on Manjaro, the out-of-the-box experience has a price: you will have a more "bloated" system by default. On Arch, since you build your system yourself, the bloat should be very limited, or even non existent, since everything that will be installed should be (in theory) stuff that you actually want.
On Manjaro, there is many graphical tools that will help you configure your system and install applications. They are not mandatory (you may use the CLI if you want instead), but they are there by default. Arch Linux, on the other hand, relies solely by default on CLI tools by default and encourages users to use CLI tools as much as possible (although they do not force them to do so, as the users is free to install what he/she wants on his system, of course).
That is not a downside - it is a strength - at least in my opinion.
I have taken rounds with Debian systems and the package manager apt which should resolve dependencies easy some times made me pull hair.
It was when I started using Arch around 2012-13 things started to stabilize for me.
A couple of years back I would have said - no Arch for servers - but now I am running a server on Arch - a linode Nano (€5/month) hosting a couple websites.
The only reason not running Manjaro is Linode not having a Manjaro image. It would likely be and easy task converting it from Arch to Manjaro but there is no incentive.
Compared to other sites I use this linode Nano instance serves faster than my preferred danish hosting provider - which is known in Denmark for its fast hosting service which runs using Slackware or Gentoo - what I do know is - they compile the whole #! themselves.
The apache webservice works much faster on Arch than anything I have worked with before - typically based on Debian or Ubuntu.
Even a Wordpress site worked better than I imagined and even the grav cms (php based) flies.
I would probably use arch over manjaro for a server. Easier installation (for a server), and arch is a general purpose distro, while manjaro is optimized for the desktop.
What I like about both manjaro and arch is the ease of use. Documentation is good, software is up to date, repos are rich and most everything is easy to setup. I think manjaro takes this aspect even further in the desktop installations.
Btw, as tools not included in vanilla arch, check out bmenu, manjaro-ranger-settings and micro.
I think everyone should build arch from the wiki at least once. You learn so much doing that especially if you are pretty new to linux. You get a very good understanding of how the system goes together and why things are installed they way are.
Things that I like more with manjaro.
Driver management thanks to MHWD
Out of the box gaming, with little set up. When you download lutris it automatically selects the wine packages you will need.
Manjaro-Architect-even though I have some learning to do with it still. I prefer that way over the GUI.
The thing I like the most is the community here on the forums. I see a lot of the same people answering questions and helping trouble shoot on a daily basis.
I agree that rolling release may be better in many cases, like on personal computers. But for servers I don't think it is the best option.
For example, a strength on personal computers, but maybe not on servers (depending on your use cases).
Funny, I was doing the same thing (Arch + Linode), but once I found that I didn't have the time to focus on continual updates (and managing the manual interventions that are required), I realized it wasn't a good fit for me because I wanted to focus on the products that I started to build on top of my server stack. With a stable distribution, I can go in a year later and add a database software without risk of bricking the machine, and without having to update everything.
Updates are good, but not always necessary, in my opinion.
As for a "stable" Arch-based distribution it wouldn't require much manpower (off topic)...
What I am imagining is that, if Manjaro or any Arch derivative had frozen mirrors, it would be totally optional for the end user, and it wouldn't require a whole new team to manage:
Some of us would keep the default rolling-release model on our personal computers simply by pointing mirrorlist to rolling mirrors
Others of us would simply point mirrorlist to frozen mirrors.
People who volunteer to host mirrors would choose to host rolling mirrors, stable mirrors, or both. The overhead would be the same for either type of mirror, except that stable mirrors would simply not be updated as often as rolling mirrors. pacman -Syu for a frozen mirror user would do nothing for 6 months (or whatever the time frame is).
This would not take any more man power than the existing mirror system does. the mirrors are still "rolling", just not as fast; a longer time between mirror updates.
This would mean that previous snapshot mirror states are lost (just like the current rolling release) as soon as a mirror updates. So this isn't quite like Ubuntu where old snapshots are maintained.
It's simply a matter of a mirror maintainer flipping a boolean to make a mirror stable.
There would be some centralized machine(s) that tell(s) stable mirrors when to update. Maintainers of current packages would not need to do anything extra. The only extra manpower is in adding the update signal to the centralized machine(s), which is quite a small amount of extra man power.
I'm getting a little off topic now though, but it could be an interesting idea for another thread.