How does Manjaro behave on the long term?

Hi all!
TL;DR, I’m interested into switching to Manjaro from MX, but I’m concerned about stability of the system on the long term.
I’m into software development and I’m using Linux based OSs since a few years, I’m not a newbie, but also I’m not a ninja. Due to requirements on software I use regularly, I always preferred Debian-based distros due to stability. I’m not new to Arch. I’ve used it in the past, but after some time, I always ended walking away because something broke and I didn’t had enough time to tinker with the system to fix the problem. Despite this, I love the community-based model behind the distro and the way some tools, like pacman, are just simpler to use wrt Debian distros. Another concern is about software availability. I usually use tools that are delivered as ‘.deb’ packages. I know there are ways to install '.deb’s on Arch distros too, but they are always been somewhat troublesome to me.
So, long story short, I’m tempted to install Manjaro, but I can’t evaluate if it would be a good move to trade stability for other goodies. What do you think? What is your experience with the system on the long term? Any impression on other kind of usages, beyond personal one? Any experience on using ‘dpkg’ and similar tools on Arch distros?
Thank you very much,

Mnajaro stable branch is quite stable in my opinion. Manjaro unstable inherit the packages from Arch Linux stable, and the packages are passed to testing branch and eventually to stable about 2 weeks later. Therefore, the chance of a broken system is slight. I won’t deny there might be still chances, but Ubuntu also broke to me before so I guess that’s a generic issue of Linux world :sweat_smile: Too many projects work together so that sometimes a faulty component of the toolchain will cause the comprehensive failure.
Before you start your migration, I suggest you can install a stable branch on a virtual machine first and observe how it works in your case. It seems that the stability varies depending on user cases.


Hi @Gabbo,

Manjaro is a curated rolling release. Meaning it gets tested and ironed out before being rolled out as stable. Also, it has 3 branched, Stable, Testing and Unstable, of which Unstable is the closest to Arch Stable.

You can check on Packages | manjaro for availability of the software you’re looking for and if all else fails, there’s always the AUR. If you’re even more desperate, there’s always debtap.

And, always remember, even though Manjaro has its roots in Arch, always remember that Manjaro != Arch

Otherwise, install and test it in a VM, see if it’s for you without breaking anything. I can tell you, though, that Manjaro is the only OS until now that’s lasted me more than 6 months.

Update, and keep Manjaro updated the Smart way and she’ll give you a lot of love and long service.


While I’ve never used it, dpkg is installed and available by default:

Never mind this, what @Yochanan said.
$ dpkg --help      
Usage: dpkg [<option>...] <command>

-i|--install       <.deb file name>... | -R|--recursive <directory>...
--unpack           <.deb file name>... | -R|--recursive <directory>...
-A|--record-avail  <.deb file name>... | -R|--recursive <directory>...
--configure        <package>... | -a|--pending
--triggers-only    <package>... | -a|--pending
-r|--remove        <package>... | -a|--pending
-P|--purge         <package>... | -a|--pending
-V|--verify [<package>...]       Verify the integrity of package(s).
--get-selections [<pattern>...]  Get list of selections to stdout.
--set-selections                 Set package selections from stdin.
--clear-selections               Deselect every non-essential package.
--update-avail [<Packages-file>] Replace available packages info.
--merge-avail [<Packages-file>]  Merge with info from file.
--clear-avail                    Erase existing available info.
--forget-old-unavail             Forget uninstalled unavailable pkgs.
-s|--status [<package>...]       Display package status details.
-p|--print-avail [<package>...]  Display available version details.
-L|--listfiles <package>...      List files 'owned' by package(s).
-l|--list [<pattern>...]         List packages concisely.
-S|--search <pattern>...         Find package(s) owning file(s).
-C|--audit [<package>...]        Check for broken package(s).
--yet-to-unpack                  Print packages selected for installation.
--predep-package                 Print pre-dependencies to unpack.
--add-architecture <arch>        Add <arch> to the list of architectures.
--remove-architecture <arch>     Remove <arch> from the list of architectures.
--print-architecture             Print dpkg architecture.
--print-foreign-architectures    Print allowed foreign architectures.
--assert-help                    Show help on assertions.
--assert-<feature>               Assert support for the specified feature.
--validate-<thing> <string>      Validate a <thing>'s <string>.
--compare-versions <a> <op> <b>  Compare version numbers - see below.
--force-help                     Show help on forcing.
-Dh|--debug=help                 Show help on debugging.

-?, --help                       Show this help message.
--version                    Show the version.

Validatable things: pkgname, archname, trigname, version.

Use dpkg with -b, --build, -c, --contents, -e, --control, -I, --info,
-f, --field, -x, --extract, -X, --vextract, --ctrl-tarfile, --fsys-tarfile
on archives (type dpkg-deb --help).

--admindir=<directory>     Use <directory> instead of /var/lib/dpkg.
--root=<directory>         Install on a different root directory.
--instdir=<directory>      Change installation dir without changing admin dir.
--pre-invoke=<command>     Set a pre-invoke hook.
--post-invoke=<command>    Set a post-invoke hook.
--path-exclude=<pattern>   Do not install paths which match a shell pattern.
--path-include=<pattern>   Re-include a pattern after a previous exclusion.
-O|--selected-only         Skip packages not selected for install/upgrade.
-E|--skip-same-version     Skip packages whose same version is installed.
-G|--refuse-downgrade      Skip packages with earlier version than installed.
-B|--auto-deconfigure      Install even if it would break some other package.
--[no-]triggers            Skip or force consequential trigger processing.
--verify-format=<format>   Verify output format (supported: 'rpm').
--no-pager                 Disables the use of any pager.
--no-debsig                Do not try to verify package signatures.
Just say what we would do - don't do it.
-D|--debug=<octal>         Enable debugging (see -Dhelp or --debug=help).
--status-fd <n>            Send status change updates to file descriptor <n>.
--status-logger=<command>  Send status change updates to <command>'s stdin.
--log=<filename>           Log status changes and actions to <filename>.
Ignore dependencies involving <package>.
--force-<thing>[,...]      Override problems (see --force-help).
--no-force-<thing>[,...]   Stop when problems encountered.
--refuse-<thing>[,...]     Ditto.
--abort-after <n>          Abort after encountering <n> errors.
--robot                    Use machine-readable output on some commands.

Comparison operators for --compare-versions are:
lt le eq ne ge gt       (treat empty version as earlier than any version);
lt-nl le-nl ge-nl gt-nl (treat empty version as later than any version);
< << <= = >= >> >       (only for compatibility with control file syntax).

Use 'apt' or 'aptitude' for user-friendly package management.

This kind of topic usually attracts system critics - users which wants to air their dissatisfaction with Manjaro. If I see such trend - as moderator - I will close the thread.

That warning aside …

If you are satisfied with MX then why change it?

You don’t have to - just follow some basic rules - Manjaro is as stable as you make it.

I have been using first Arch then moved to Manjaro (ease of installation) and been there for the past 6-7 years.

Don’t tinker (too much) with the desktop - especially if you are into Gnome or Plasma - stay as close to upstream as possible - this will steer away 95% of your issues.

Choose your hardware based on knowledge of the device or components and their compatibility (never use the latest and greatest) - avoid dual graphic laptops (prefer Intel GPU) - on workstation prefer AMD or Intel.

If your workflow demands the utmost stability then an Arch based system is likely not for you.

I am a developer and I depend on my system - but I am also a breaker - and I have deliberately broken my system so many times and early in my Linux journey - I realised I needed a procedure which allows me to quickly restore my workstation.

I took a few crashes until I got my reinstall procedures right - so when I need it I can rebuild my system and be backup up within 15 minutes - I only depend on a few packages so another 30 minutes


  • virtualbox (windows 10 ltsb for visual studio)
  • vivaldi
  • chromium
  • firefox

3rd party repo

  • sublime merge
  • sublime text

Prebuilt packages (before reinstall)

  • virtualbox-ext-oracle
  • chrome
  • postman
  • edge-dev


  • jetbrains toolbox

Over the past years I have seen the timeshift and the btrfs maintenance tools getting increasingly better and I am now testing btrfs with encryption on a laptop.


Thank you all for the answers.
@linux-aarhus about MX, personally, in the past, I’ve enjoyed more Arch based distros then other ones, despite all the troubles. Maybe it’s just a personal kink, but it annoys me the fact that I can’t use some Arch distro that fits my current workflow.

@Mirdarthos and @dobedobedo thank you for the tips, I’ll give a try on a VM.


If you can’t find software in the official repositories, as Flatpak or Snap search the AUR (Arch User Repository).

You don’t. This is the warning displayed when installing dpkg:

dpkg installs Debian package manager.
This is useful for those who want to create/modify DEB files.
However, *do not* use dpkg to install Debian packages in your ArchLinux machine.
This will break your system!
You will need to go back to Arch wiki and read the installation guide again.
You've been warned!

I used to use Debian before. About a year ago, I use manjaro. Maybe I fell in love with manjaro because I couldn’t stand the speed of Debian package update. The premise of stability is to be prepared to update once a week. Otherwise, the probability of bad update is a little higher than that of Debian. Naturally, you can use the Pacman GUI tool he brought to deal with it. For the DEB package you said, usually AUR will be ready-made, and you can install it directly.

Manjaro stable has been a rock of stability since I started using it. No other Arch based distro has come close. That being said, it depends on what you do after install. Heavly using the AUR especially for system components and graphics drivers will make a very unstable install in no time.
Another good thing to do if your worried about stability is to use timeshift and timeshift-autosnap. That way whenever you upgrade the system it creates a restore point. If by some chance you get a bad update, its easily reverted.

1 Like

As a four years user, the last one in unstable branch I can confirm Manjaro is rock solid. I have even made disruptive tests (kernel compilations, kernel testing, device testing, etc) and Manjaro recovers fine after Timeshift backup.

Yes, don’t even try to make changes without Timeshift!! In a safe disk!! other than root installation!!


I have been using Manjaro now for several years (5+) on a laptop and a desktop pc. So far it was very stable for me. I never had any issues that broke my system or left it unbootable.
There are some minor things every now and then like an AUR package I couldn’t compile due to some incompatible settings, which took a while to solve, or some coredumps in my journal, that apparently don’t have any detrimental effects and that I haven’t been able to trace back to their cause, but nothing serious.

So long story short, I am very happy with Manjaro and would recommend it

Thank you for the link to the smart way post. I missed that one, good info there.

1 Like

Thank you all.

I tried to setup Manjaro xfce on a spare disk to test performance on native hardware. It seems to work flawlessly, except for a bug with touchpad, wich sometimes is not detected, but it’s something I’ve been struggling almost with all distros I’ve used in the past, so, I think it’s not relevant. I think I will consider seriously to migrate.

A last question about updates: as far as I know, for Arch, it’s a good practice not to update very often. Personally, I prefer doing it using pacman. When should I update? Once a month, twice…? What is a reasonable period of time? And, about kernel, is it safe to use older kernels other then the stock one (of course, among the LTS ones)? When it is adviced to do this?

EDIT: Oh, sorry, I forgot this: I usually like to try new DEs from time to time. Is it safe to switch DE often? Any risk to break something by adding or removing packages or dependencies?

Again, thank you all for the support.

I recommend rather using pamac because it just takes care of more things for you. This is the command I recommend and use:

pamac upgrade --enable-downgrade --aur --devel

And pamac is built using libpacman libalpm, so it’s close to the same thing. AFAIK, anyway.

This isn’t true. At all. It’ll cause things to break.

Keep an eye on the update #announcements for your preferred fork, and update when the updates are released. You can also use matray to keep informed of update announcements.

Well, this can be interesting, I think. If you want a solid, reliable, stable system, you can’t go wrong with the LTS ones. That said, I have never had one (1) single crash on the latest one.

If you like to use the latest one, keep an LTS one installed as backup for use if something goes wrong with the latest one, then.

I recommend, and I’ve heard it’s recommended to use only one DE per user, although I’m sure it can work with multiple DEs as well. The reason for this is because every DE handles its configuration its own way. So files can easily become cluttered, confusing. It would’ve been awesome if every DE used a dedicated directory for its configuration, example ~/.config/kde, ~/.config/gnome and so on, but unfortunately that is not the case.

1 Like

recommend rather using pamac because it just takes care of more things for you

Just want to second this, Pamac is great and just has better commands than pacman (though I always enable ILoveCandy in the config)

Also yes, use the matray app to know when new updates are released and enable timeshift. Definitely don’t let Manjaro (or any rolling release distro) go too long without an update. I typically get my systems updated within a few days of a release.

No - it’s not. It’s possible but you will run weird hard to resolve issues especially when mixing Plasma and Gnome.

Permit me to doubt it :rofl:

//EDIT: cat /var/log/pacman.log | grep dpkg ?

Permission granted.

Feel free to doubt all you like. I take care of what I do on my PC, and I can’t remember installing it myself and it’s there. But I might have. Stranger things have happened.

It is safe to use older kernels. LTS kernels work for me. The main reason to move to a newer kernel is for hardware support of newer hardware. Thats a two edged sword at times. Newer kernels that try to make newer hardware work sometimes introduce problems with older hardware. If your hardware is working with the newest LTS kernel I would stick with it.
I usually have at least two kernels installed, mainly from long ago experiences. Its possible to get a bad kernel upgrade. If you only have one there is nothing else to boot into for easier troubleshooting. This is also a good idea if you are installing the latest and greatest, it leaves a known working setup to boot into if problems happen.


For the touchpad issue, does this occur after resuming from suspend? If so,
sudo modprobe -r psmouse && sudo modprobe -a psmouse
might fix it for this and subsequent suspend/resume cycles (until next reboot anyway).

It’s been 9 years since I installed Manjaro on my computer. So I can say that Manjaro is stable in the long term.

I have had several problems, but I have solved all of them thanks to the collaboration of the friends of the forums.

About the software, if you find it on AUR it will most likely work. Although it has happened to me that some things stop working between updates.

In spanish Nueve años han pasado desde que instalé Manjaro ¡Y lo que falta!