how unstable is unstable?

Non-technical Questions
1

in my childhood i once heard the saying somewhere on irc: ‘i don’t care if the software i use is unstable ■■■■■ as long as it’s the latest ■■■■■■ I used to say that for a long time :smiley: and somehow the idea never really got out of me. I’ve been using manjaro stable for a few years now and I’m very satisfied, but my fingers are itching to switch to unstable, unfortunately I need the notebook for my work and I’m reluctant to do so, so I wonder how unstable unstable really is? do i crash a package here and there or does it happen to me that the system doesn’t get back on its feet and i have to save it (which i’m too incompetent to do)?

2

Issues are rare but they occur - even in stable.
If you have trouble dealing with those - don’t do it.
Solutions will usually be quickly available - testing is basically the same as Arch and any issues there get quickly solved and the way to the solution published.

It’s rare, but if you don’t have the knowledge … not recommended.
As an anecdote: I have used Arch for years without any issue.
Now I use Mint, because the chance for any issue there is even smaller and the system stays the very same for years, which has value (to me).

1 Like
3

It all comes down to preference - and knowledge - the more knowledge the better.

People keep saying Linux for the desktop - but the truth is - free and opensource will never beat Windows and Apple and as such LInux will always be the place where tech minded individuals - which do not mind the occasional troubleshooting - is home.

unstable is just a name in the chain - I often refer to it as Edge - just because

source → arch binaries → select arch → unstable → testing → stable

I have been using the Edge branch for 8 years but if you do not need anything fancy on consumer pc - no techie - nothing fancy - no gaming - basic theming - stable is good.

I prefer the short update frequency - makes it easier to troubleshoot - should anything do awry.

3 Likes
4

Manjaro:A Different Kind of Beast - Unstable branch
Unstable branch is synced several times daily from Arch stable and the packages from Arch repo is generally considered stable as they have been vetted by the Archlinux QA and the Archlinux community.
Manjaro maintainers build kernels, kernel modules and nvidia graphic drivers from kernel source.
This branch is also the entry point for Manjaro’s in-house applications. The latest available versions of software will be located here and using the unstable branch may cause issues on your system but you are proficient, motivated and have no problem solving minor issues on your own.

Unstable branch is not “curated” like stable branch so partial updates are more likely to happen – user may need to wait for a missing dependency from Arch
For Manjaro packages, unstable branch users are the first responders in Manjaro testing process
But if the repository packages are up to date, AUR packages are unlikely to have problems with a missing dependency

5

Perhaps you need to think a new strategy. I mean - people drive cars, 4 wheels, because they’re stable. I ride bikes because they’re unstable but have incredible advantages.

  • Run snapshots, backups, work out your strategy
  • What if my computer falls in the bathtub?
  • What if my main SSD fails?
  • What if my main storage HDD fails?

Think about what you have to lose, and prioritise what you need to protect.

I say this because I’m relatively incompetent… but the main driver that brought me to Manjaro is that it’s better for me - for the software I use - meaning I can install pretty much everything that I need and the AUR is more amazing than it is dangerous… With other systems/stable systems I always needed repos, and they caused me lots of serious headaches.

So now, this is how I roll… and crash and burn :rofl:

You say you’re incompetent to get it back on it’s feet? Then I can’t disagree.

Getting back on your feet:

Case in point - PSU failure, required a rebuild - Starting in the shop with a new PSU, new architecture APU and Motherboard, CPU, RAM.

It takes me 5-6 minutes to do a clean/fresh install to SSD after a complete system failure.

It takes me a few minutes longer to restore a snapshot - but for new hardware, this isn’t a good plan so we go with install and rebuild…

It takes me a few hours longer to clean install, then copy back configurations from backups to get my system 95% the way it was before total system failure… Most of that time goes into setting up Prowlarr, Sonarr, Plex, qBit etc - all need setting up to talk with each other and Storage disks need to be mounted up in identical fashion.

Then it might take me a few days to finish the job and get it fully back to the way I want… edit broken scripts etc.

REASONS

I went from Stable to Testing was more related to reducing the delay with AUR whilst still having a layer of safety (not really sure how real it is, but I’ve done okay over the last 8 years.

This is really the only valid reason to need to stay away from stable… a few of my core softwares are installed via AUR and they are as important to me as anything installed via repos, and not available in flathub.

I had interesting symptoms of Plasma being pushed ahead of it’s time, for example, which put me firmly in the Stable camp a while back… but switching and fixing issues (or completely winding back and just avoiding issues) is so easy.

I get childishly excited when new stuff comes out, but quite often (and more often than not) the best result is ‘oh, that’s all?’ but the worst is ‘oh, ■■■■ - I’m gonna waste 3-4 hours sorting out this mess’ - and waiting as patiently as I can for files to copy, backups to be restored…

Notebook

Hardware is possibly a limiting factor… like - how many drives are in your notebook?

Do you have backups/snapshots set up only internally, or also externally?

Competence

Use the system until you’re confident enough to say ‘I don’t care if it’s stable or not - I can fix it and it’s not going to stop me doing what I need’.

Then choose what you like - not before.

TL;DR

Unstable is as stable as you are. If you don’t know what that means, then stay stable until you do.

4 Likes
6

In general, I think much of the packager’s caution is to keep issues to a minimum because there’s no separate support department at Manjaro. The same people who package stuff, have to support it. It reduces their workload to have stable be rock solid.

To give you an idea of how cautious I can be, I began trying Manjaro in May last year, before formally moving everything over in October.

However, for my daily drivers, I’ve found my home in Testing Branch. It seems, generally, to be just a couple of weeks behind Arch, and has any Manjaro-specific kinks ironed out.

I’m also not out on the edge with my primary applications–browsers, email, LibreOffice (fresh), music player and music editor. Nothing that isn’t already tested at the source level long before it even gets to Arch.

BTW, if you’re on LibreOffice-stable, perhaps you could test the waters by switching to LibreOffice-fresh.

In any event, looking at the chain given by @linux-aarhus above, I’ve recently begun exploring upstream and have moved my testing laptop from Manjaro directly to Arch. (Yes, I “cheated” and used archinstall. It may not be “The” Arch Way, but it’s on the ISO so it is “An” Arch Way.)

Still no issues whatsoever, except one I caused myself. Now I have time to test new stuff myself in a separate, confined environment, so I know what to expect when it shows up in Manjaro’s Testing Branch. Which is usually, big whoop.

So IMHO, even Unstable Branch is hardly throwing caution to the wind.

Finally, like you and @Ben , I have no skilz. So instead, I have a good, rigorous and tested backup plan. As a result, I still have email, documents, spreadsheets, photos and the like from 1991. It’s not hard. I just made a committment.

4 Likes
7

Just pointing out that there is nothing inherently unstable about the software in Manjaro’s unstable branch.

8

@AlexanderPCT

To answer the question you seem to be asking;

If you feel competent enough to use the Unstable branch, and make whatever repairs you might be called upon to perform during your journey, then by all means switch to Unstable.

For those with sufficient knowledge and experience, and used to getting their hands dirty, Unstable is rather straightforward.

However, if you’re already satisfied with Stable, and are able to deal with most issues that may arise, then stick with what you know best.

It’s only a question of confidence, when you think about it.

This is the best non-technical response I could muster at short notice. I hope it was helpful to some extent. :smile_cat:

Regards.

2 Likes
9

One way to look at things is how often updates are rolled out. The more frequent the updates, the more cutting edge your system will be, but also the higher the chance that something may not work properly after an update:

Branch Update frequency (approximate)
Unstable daily
Testing weekly
Stable monthly

I switched to Testing branch in May last year for a couple of reasons. The first was to make it easier to build mesa-git from the AUR (it was during the time when patented codecs for AMD GPUs were disabled on Manjaro’s version of mesa), as Stable was too far behind on mesa-git’s required dependencies. At the same time, my system got upgraded to Plasma 6, with only one issue (I forgot I was using a custom SDDM screen that didn’t work on Plasma 6).

Apart from that minor issue with the Plasma upgrade, I have not had a single minute’s downtime on my system since I moved to Testing branch 9 months ago.

So, maybe switch to Testing branch first. See how comfortable you are with Testing. You might then decide to switch to Unstable, or go back to Stable, or just stay with Testing (as I have done).

4 Likes
10

From a developer point of view the concept we came up almost 13 years by now was:

  • Arch is super nice and easy to add new software to
  • Their PKGBUILD format is was easy to understand as they are more or less bash scripts
  • creating a customized package via makepkg was easy

Then we had the issue that if we provide our own packages in a repository, like some of us did in the KDEmod project, you always had to chase after Arch changes. Hence the idea of doing snapshots of the whole Arch binary repository.

This gave us the following:

  • We decide when we have time to do things and get a copy of Arch which doesn’t change
  • Then we check what is broken, updated or need rebuilds on our end
  • When done, we moved that new stack of packages to a branch. In this case testing
  • Users and us will then test and see if we missed anyting
  • When we are happy we moved that corrected stack of packages to another branch: stable

So whenever we do a sync from Arch binaries there might be issues. You can simply check which packages are added to Arch: Arch Linux - Package Search. Also check their Arch Linux - Todo Lists.

As a Manjaro developer you normally check what is new to been pulled in and if you have to follow their todo’s next to ours as needed: rebuilds.md · main · Release plan / Packaging · GitLab

When you are as a user on the unstable branch you can simply follow the monthly thread to see what gets added: Unstable Updates - Manjaro Linux Forum. Also users of that branch mostly post about issues they may have. You can also monitor our Packages Mailing List: The manjaro-packages Archives. If you see a lot of emails added there, you know we are very busy as maintainers and an update might need to be avoided on your end.

Cos after all, you are your captain of your own vessel and you decide when you update your system. Even I don’t update daily, only when I feel like it.

8 Likes
11

to some of us it is stable than it is in ‘stable’ branch, atleast from the constant rants being thrown around in those announcement threads.

not mocking the stable branch’s existence or manjaro’s curated package release system, but sometimes i think given the appropriate circumstances; frequent, atomic releases/updates avoids major issues, and only get minor ones. especially if the said working notebook is older and you have no linux-problem prone hardware i.e.: nvidia, realtek, mediatek, etc. then you should absolutely try “unstable” branch.

TBH the worst that i had to do was to downgrade a package or two get going in my personal experience. backtracking to find problematic updates is far easier when you update often due to each update cycle only affecting minimal number of packages. you can also elevate to a higher curated branch (unstable → testing or testing → stable) and then bulk downgrade all packages to that of that branch.

of course it goes without saying that, you should have backups of one form or another to cover an absolute show-stopper, as much as you fancy having none to have this functional at-all-times.