It’s more than you think. I work with the MSP430 microcontroller, which is capable of a sleep current of 40nA @ 2V, full active mode at 140uA/MHz with all onboard peripherals turned on. With this you could achieve almost a 20% on-off ratio with a 1MHz clock, or keep it in active mode all the time at ~150kHz, which is sufficient for many embedded sensor applications.
My DE broke because Manjaro added untested/beta patches from upstream, sometimes even against the developer’s word. This is something that Manjaro is known for. Guess who inspired dont-ship.it?
Also I would appreciate you not calling my statements on the AUR false. I have personal experience on the matter so we can play my experiences against yours if you like, or we can listen to the official Manjaro maintainers reccommending that it not be used, as it is incompatible with the Manjaro repos. By design Manjaro holds back Arch packages, which means AUR package dependencies often do not match what is expected. This is not false. Can you use the AUR? Sure, but you must keep in mind that Manjaro was not designed for it and it will break AUR packages sometimes. Sometimes it’s as simple as waiting a couple weeks for Manjaro to let new packages through, but sometimes you can’t just wait several weeks and you need to fix it yourself.
And yes, Manjaro does hold kernels back because you have to specify when you want to move off a major release. You can accidentally be using an unsupported kernel and not even notice. Ask me how I know. Manjaro literally requires more maintenance than Arch on this front.
I can’t comment on what maintenance Arch requires that Manjaro doesn’t, as I run EndeavourOS. I’ve found it to be everything Manjaro wishes it was - a thin, user-friendly wrapper around Arch.
Just remember that Manjaro’s official response to them forgetting to update their SSL certs was to roll back your clock, putting everyone at risk of accepting invalid certs in the process.
During my six month usage of Manjaro (my introduction to Arch-based distros), my desktop broke four times and booted me to the terminal. Almost once a month. I told myself this was the price you paid for living on the edge, using a rolling release. I switched to EndeavourOS and have not had a broken desktop in two whole years.
Manjaro’s handling of AUR packages is fundamentally wrong and with their design decisions it cannot be fixed. You either give up the AUR entirely, or resign yourself to constantly breaking AUR packages and having to try and fix them.
Manjaro’s handling of kernels via a GUI sounds good until you realise it’s entirely manual and if you don’t keep checking you will end up running an unsupported, out of date kernel with Arch packages that expect a newer one. Again, Manjaro violates Arch’s golden rule of avoiding partial upgrades by holding your kernels back until you manually update them in their GUI. If you’re running an Arch-based distro 99% of the time you want the latest kernel and an LTS kernel as a backup, but these are already in Arch as packages (and are thus updated in lockstep with your packages, as designed) so you don’t need Manjaro’s special GUI. Now if you wanted a particular kernel for some reason then sure, but Manjaro’s GUI doesn’t even let you pick the exact version you want anyway! All you can pick is the latest version of each major release.
If you’re anything like I was at the time, you think you like Manjaro but what you actually like is Arch. Manjaro just gets in the way.
The MSP430 is just the chip I happen to use at work, if you’re not convinced you could try looking for an actual ultra low power chip, I found the STM32U0 at 70uA/MHz and the STM32U5 at 16uA/MHz in the first result.
Even ignoring selecting a more efficient micro, a smattering of tiny ceramic caps will buy you a few hundred microjoules for bursts. If you’re already operating at 2V you can get a 6V rated 100uF cap in a 1210 package - and that’s after considering the capacitance drop with DC biasing. Each one of those would buy you 200 microjoules, even just one ought to be plenty to wake up for a few tens of milliseconds every second to get a reading from some onboard peripheral (as an example) then go to sleep again.
For sure, you’re not going to be doing any heavy lifting and external peripherals could be tricky, but there are certainly embedded sensor use cases where this could be sufficient.