The review itself speaks volumes about the author's misconfigurations and lack of Linux experience.
As everyone has stated, Firefox, and all major browsers at this point, are resource hogs. On a low powered system, trying to run a huge and inefficient webpage like Slack will always bog down the system. It will frequently cause my browser to use upwards of 15 GB of additional RAM on my 64GB workstations, regardless of the browser and OS involved. However it sounds like it's especially bad on the author's system because he doesn't have any swap enabled (more on that later).
HiDPI is a known weakness in Linux for all versions of Linux. The complaint here seems to be that the screen is too good, and the author is slightly uncomfortable with how small 1x scaling is. There is a solution in XWindows that can partially solve that (see other comments), but no version of Linux solutions using XWindows really exist for it that don't murder your CPU.
The console problem with zsh being slow is straight out of the beginner's zsh configuration problems "handbook". Every beginner starting to play with their prompts loads up the add ons and bogs it down. Not adding asynchronous plugins, especially for git, makes the prompt on all systems slow, but is especially noticeable on low-RAM systems that can't keep the entire git folder cached for faster lookups.
This is obviously exacerbated by the fact that the author has swap disabled. In his first step of the clang build, he says to enable swap. On a low-RAM system, swap is especially important since you're going to run out of space in RAM very frequently. Swap is how you help mitigate that problem, by allowing some of your disk to be used as ultra-low-speed volatile storage. If the author manually disabled his swap (which would be required if he actually used the default install configurations claimed), it's no wonder the system is slow to respond and slow for resource intensive tasks. It's only been recently with the very high memory volumes available that there's been discussions about disabling swap completely.
Related, I'm not sure if the sleep mechanism problems from the Pinebook Pro are driver problems, but if your don't have swap configured then virtually none of the Linux sleep mechanisms work. When the device sleeps, it stores the RAM contents in swap. If you don't have swap, you can't sleep.
Slow build speeds are pretty much expected. Builds of large codebases are one of the most taxing things you can do to a system. Having a slower CPU and small RAM are the worst things for build times because CPU is frequently a bottleneck on even the most powerful systems, and disk io (the other major bottleneck) is usually mitigated by RAM caching. If the project is C++ you also get crushed by the linking process on large projects, which can require huge amounts of RAM. It's no wonder the author said to add swap since a lack of swap and small RAM can cause a literal crash during linking due to failure to provide minimum required volatile storage.
The complaints about the "lack of support for..." are really trite too. It's Manjaro, even a cursory look up on it tells you it's a more stable and slightly more user friendly version of Arch. Both still require you to be comfortable with configuring your system manually, it doesn't come perfectly configured out of the box, that's part of it's draw. Something like disk encryption is a good example where they user is expected to configure their own system. Similarly, Manjaro will perform more poorly than other distros on some hardware if you don't configure it, because unconfigured systems are always less performant than configured systems.
tl;dr
The author seems to have wiped and reinstalled the Manjaro OS, skipped configuring it or explicitly configured it in a way that makes it perform worse, then complains about the low-spec device performing badly.
How are you measuring the memory usage? 15 GB sounds like a count of virtual memory that includes lots of mappings that aren't physical memory.
On my FreeBSD desktop box right now, the main Firefox process has 1890MB RSS, and the content processes have anywhere from 248MB to 675MB. (Swap is completely unused.)
> if your don't have swap configured then virtually none of the Linux sleep mechanisms work. When the device sleeps, it stores the RAM contents in swap. If you don't have swap, you can't sleep.
???
Suspend-to-disk / "hibernation" (S4 in ACPI terms) is a really unpopular way of "sleeping" these days. FreeBSD outright does not support S4 (except S4BIOS).
The usual sleep is suspend-to-RAM. These days there's also S0ix which means turning as much as possible off but not changing system power state. Mobile phones are probably doing something like that.
> on low-RAM systems that can't keep the entire git folder cached for faster lookups
If you rely on caching for the git directory, the first time you navigate to a repo would be very frustrating too. You can't always rely on caching. Sometimes you have huge repos. Sometimes they are mounted over NFS and git status takes >10s. :D
IMO git status shell plugins are unnecessary and not worth it.
> HiDPI is a known weakness in Linux
Maybe stop using the ancient terrible windowing server ;) It's a non-issue with Wayland.
As everyone has stated, Firefox, and all major browsers at this point, are resource hogs. On a low powered system, trying to run a huge and inefficient webpage like Slack will always bog down the system. It will frequently cause my browser to use upwards of 15 GB of additional RAM on my 64GB workstations, regardless of the browser and OS involved. However it sounds like it's especially bad on the author's system because he doesn't have any swap enabled (more on that later).
HiDPI is a known weakness in Linux for all versions of Linux. The complaint here seems to be that the screen is too good, and the author is slightly uncomfortable with how small 1x scaling is. There is a solution in XWindows that can partially solve that (see other comments), but no version of Linux solutions using XWindows really exist for it that don't murder your CPU.
The console problem with zsh being slow is straight out of the beginner's zsh configuration problems "handbook". Every beginner starting to play with their prompts loads up the add ons and bogs it down. Not adding asynchronous plugins, especially for git, makes the prompt on all systems slow, but is especially noticeable on low-RAM systems that can't keep the entire git folder cached for faster lookups.
This is obviously exacerbated by the fact that the author has swap disabled. In his first step of the clang build, he says to enable swap. On a low-RAM system, swap is especially important since you're going to run out of space in RAM very frequently. Swap is how you help mitigate that problem, by allowing some of your disk to be used as ultra-low-speed volatile storage. If the author manually disabled his swap (which would be required if he actually used the default install configurations claimed), it's no wonder the system is slow to respond and slow for resource intensive tasks. It's only been recently with the very high memory volumes available that there's been discussions about disabling swap completely.
Related, I'm not sure if the sleep mechanism problems from the Pinebook Pro are driver problems, but if your don't have swap configured then virtually none of the Linux sleep mechanisms work. When the device sleeps, it stores the RAM contents in swap. If you don't have swap, you can't sleep.
Slow build speeds are pretty much expected. Builds of large codebases are one of the most taxing things you can do to a system. Having a slower CPU and small RAM are the worst things for build times because CPU is frequently a bottleneck on even the most powerful systems, and disk io (the other major bottleneck) is usually mitigated by RAM caching. If the project is C++ you also get crushed by the linking process on large projects, which can require huge amounts of RAM. It's no wonder the author said to add swap since a lack of swap and small RAM can cause a literal crash during linking due to failure to provide minimum required volatile storage.
The complaints about the "lack of support for..." are really trite too. It's Manjaro, even a cursory look up on it tells you it's a more stable and slightly more user friendly version of Arch. Both still require you to be comfortable with configuring your system manually, it doesn't come perfectly configured out of the box, that's part of it's draw. Something like disk encryption is a good example where they user is expected to configure their own system. Similarly, Manjaro will perform more poorly than other distros on some hardware if you don't configure it, because unconfigured systems are always less performant than configured systems.
tl;dr
The author seems to have wiped and reinstalled the Manjaro OS, skipped configuring it or explicitly configured it in a way that makes it perform worse, then complains about the low-spec device performing badly.