What are your experiences related to stability of Manjaro ecosystem?

The contradiction is the words stable vs unstable.

In reality the only difference between unstable and stable is the time taken when the core team decides to do the snap.

And because of that updates are much more frequent on unstable and as such much less prone to weird - hard to find issues - because you have a fairly short log of what happened and the troubleshooting process - in case of accidents - is much easier to handle.

The users using unstable are known capable and informed and able to fix small issues in a snap while many users on stable are #newbies - so when the packages are snapped to stable - the #newbies who have filled their system with interesting and 'useful' packages build from AUR - clicks the update icon and because there - most likely - is updates to kernels, drivers and x - the whole #! becomes unresponsive - user forcefully restart and the song begin.

without knowing that adding them adds a boatload of possible conflicts and required rebuilds -

1 Like

I've been thinking of switching to testing for this very reason. Smaller updates, less to troubleshoot if and when unexpected behaviour does manifest.

The main issues I've had were the releases of the Ryzen 7 1700x and RX 5700 XT. It took quite a while before either of those became stable on Linux. Other than those 2 instances, haven't really had issues with Manjaro.

Basically, so far it seems there are two main groups of issues you could face whilst using Manjaro:

A) drivers, kernel and grub - this particular group of issues may lead you to live shorter on this Earth, if you dare to play with "forbidden fruit" like nVidia, some brand new GPUs, dual boot with other OS like Windows, if you get too funky with your high hopes on brand new kernels etc.

B) AUR packages - depending on your habits aka. rtfm before you change any single bit on your system

Don't know about Linux, but users surely can do something about it.

Dual/multi -booting Manjaro with other GNU/Linux systems and Windows has never caused me any trouble with Grub. I guess it depends on the setup. My systems are all UEFI/GPT with each OS having it's own ESP.

I have the exact same setup as you mentioned above. There are many reports on how Windows completely messes up grub. Here's just one example:

Windows 10 - Update 1809 breaking grub

I am not saying that that won't happen. There is a possibility that major upgrades (not regular updates) to Windows might overwrite the Grub if one shares the same ESP between windows and some Linux OS. Having separate ESPs eliminate that risk. I can only speak from my own experience. With separate ESPs, no torubles with Grub on any of my systems.

The only thing I've found really annoying about ''Manjaro stability'', is Nvidia HDMI audio, surround receiver, dual monitor setup.

With each Nvidia update, and sometimes kernel update, something changes. Some quirks get fixed, others introduced.

Surround audio disappears when resume from sleep, apps don't stay on 100% volume, etc etc, in countless combinations of quirks.

Which makes me constantly debate if I should have Manjaro on the entertainment system and Debian on all other computers, or the other way around. Which is a dilemma, as the entertainment system is also usually where I play around with Linux, experiment and learn stuff, and Manjaro is my OS of choice to do that with.

1 Like

Try jack / jack2, you can route pulseaudio through it or if program support jack directly (like vlc for example) - completely bypass pulseaudio part.

It's little bit complicated to get into, but much more flexible in routing and have way less latency for professional audio needs.

P.S. At least for me it solved a lot of problems and quirks of pulseaudio like jumping volumes etc..

1 Like

Forgive my ignorance, but are you talking about Jack connection, as in Jack connection??

From my Windows/semi-audiophile days, I always go for ''bit-perfect'' digital audio output. Any coloring done to the audio I want to be done post computer, by the hi-fi components of my choosing (also got a tube stereo exclusive setup, for music).

Just so it's been said, I'm not a ''real'' audiophile, it is all about the music. But I want the computer, which is my main source, to not play a part in the chain, just to do ''bit perfect'' output.

1 Like

No no, of course i'm talking about JACK as in Linux program :slight_smile:

Here's basic setup...

Install those packages:


Launch Cadence and do it's most basic settings (to route all audio through JACK):

JACK Settings
[x] Auto-start JACK or LADISH at login

ALSA Audio
Alsa -> PulseAudio -> JACK (plugin)

[ ] Auto-start at login

[x] Realtime !
Realtime priority ?
Temporary ?

[x] ALSA
    [x] Duplex Mode !
    Device/Interface - your audio card
    Sample rate - 44100 kHz
    Buffer size - 512
    Period/Buffer - 2

System settings - Audio
[x] JACK sink (PulseAudio JACK Sink)

Smaller buffer size - obviously smaller will be latency, but if you just listen and don't create music - it should be safe starting value (although outcome heavily depends on Audio hardware, usually you should aim for as small value as possible, which doesn't introduce crackles / xruns)

Inside Cadence there is Tools - Catia - here you can route anything to any connection like an octopus :slight_smile:

Also for realtime privileges (minimal latency) i'd recommend to follow this:

Launch script as

perl "realTimeConfigQuickScan.pl"

And follow those recommendations, usually it's good idea to follow all of them, except maybe:

  • CPU Governors
  • Kernel with Real-Time Preemption...

Those couple makes sense only if you have some problems like heavy crackles or xruns...

Enjoy this rabbit hole, for quick start i think it should be fine! :slight_smile:
And if your program can directly use JACK - it's preferably to set in audio output settings :yum:

But I want the computer, which is my main source, to not play a part in the chain, just to do ''bit perfect'' output.

Makes total sense though :wink:

1 Like


Hey, thanks for that! I do my Linux learning in bursts, a month or two of discovery and experimentation, then a month or two just using the system, and then repeat. Audio is always a priority, but it hasn't been top priority at this beginner stage.

I'll be certain to bookmark your post for future reference, when I'm comfortable enough to fine tune and learn Linux audio Voodoo!

1 Like

In short, my answer to the question in the title of the topics is that after two years of daily use, I have a good experience with the stability of the Manjaro ecosystem. I use a triple boot. Other systems are Windows and Linux Mint. I use Manjaro's own grub.After package updates, I very rarely experience package .broken packages


Probably the biggest threat to my stability is KDE - specifically settings - but that's not a Manjaro issue, so much as a plasma/latte bugs issue.

Generally stability is close to Mint, which is good enough. Slight housekeeping after the updates - rebuild Plex etc - is to be expected and better than being stuck with the appimage on Mint.


So if I don't understand stuff like C, Python, or whatever the program may be written in, I should just avoid the AUR?

If I do I may go back to Ubuntu where pre-compiled stuff is more common

If you dont understand whats going on then something like a PPA isnt any better.
For what its worth tons of people use the AUR without even looking, let alone understanding ... but it isnt recommended.

1 Like

I'm guilty of just building without looking, I never even knew the AUR could have malware, though as a previous point mentioned, it would likely be gone soon enough.
I'll look into PKGBUILD files, not really sure atm what they do or anything. This is all a big :exploding_head:to me, again, didn't even know the AUR could contain stuff like malware.

its open for folks to sign up and post ... aside from volunteers or the community auditing it .. technically anything could go up (for a time).
Again .. if you do something like download a file off the web or add a PPA then you run the same risks .. except worse because they dont have checksums to validate, and it isnt as transparent for you to inspect, or have the community oversight to catch and flag bad packages.


Great point, It'll take a minute to digest this all. I'll be looking into properly checking AUR packages.

They are just shell scripts, but they will tell you what other packages are being pulled in for the build, and from where they are being pulled in. This is significant with regard to assessing whether the package could be drawing in malware.

1 Like

Forum kindly sponsored by