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 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.
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.
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> Commands: -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). Options: --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. --no-act|--dry-run|--simulate 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-depends=<package>[,...] 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)
3rd party repo
- sublime merge
- sublime text
Prebuilt packages (before reinstall)
- 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.
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 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.
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.
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
pamac is built using
libalpm, so it’s close to the same thing. AFAIK, anyway.
This isn’t true. At all. It’ll cause things to break.
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/gnome and so on, but unfortunately that is not the case.
recommend rather using
pamacbecause 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
cat /var/log/pacman.log | grep dpkg ?
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.