Manjaro Linux 21.1.0 Pahvo is out with installer improvements, new desktop upgrades

Quoting: NociferYeah, btrfs is certainly one of the best unknown gems of the Linux world, and implementing first-class support for it is certainly welcome. I expect and hope that now with Valve selecting it as the filesystem for the Steam Deck, more people will get to install it on their own systems (in an attempt to enjoy the full benefit of Valve's efforts on Linux gaming, which will probably include btrfs features like reflinks) and find out just how awesome it is.

What are the advantages of btrfs over ext4 (despite the RAID ones)? Any kind of performance improvements?

Quoting: STiATWhile I love Arch (was TU there for some years), and later switched to Manjaro, my real issue with it is actually the KISS approach and their approach to optional depends.

Like, if you require a package so MTP and Bluetooth actually work with phones and results in cryptic errors if they are not, they should be a dependency.

Since they are not required compile time, Arch will put them optional and you've to search why certain functions in your desktop don't work as expected. As Manjaro pulls from arch, you have the same issue there.

And that drove me away from it, though, my love for its general approach and flexibility I really like, it's not what I prefer on a daily base.

So I'm on Solus since 2017, and did not even try other distros since then. Though, Solus is rough around the edges too with snap and flatpak support not being in the solus-sc and similar, it's a much more curated approach to a desktop for daily used.

Which is not the intention of Arch, and that's fine.

Actually, what you describe was going to be my second example of where Arch lacks somewhat for me, but I deleted it in order to keep my comment from becoming too long:

"Another example is the concept of optional dependencies: e.g., in order to see WebP thumbnails in KDE's Dolphin one must know to install qt5-imageformats, which is an optional dependency not of Dolphin itself but rather of Dolphin's dependency kio-extras, and also is part of the Qt5 group but not of the kf5 group, so one can't even get it by bulk-installing the KDE components; rather, they must manually check the optional dependencies of this specific KDE package, find out about this optional dependency, and then manually install the required package to satisfy it.

At first this irked me to no end ("but how can such major functionality be hidden away in an unrelated optional dependency!"), until I realized that it kind of made sense, because Arch is very much a DIY Linux OS - with the exception of the kernel and the core userspace utilities, this isn't some preassembled ready-to-use distro but rather a collection of components that you can mix and match however you like to basically create your own custom distro."

And there is your answer: despite being a mainstream distro, Arch has more things in common with the likes of Gentoo and LFS than with the likes of Fedora or Ubuntu. The user is expected to actively participate in the building of their system, which translates into manually checking and verifying non-essential packages, manually setting things up (there is no "sane defaults" because you're building things from the ground up), manually enabling/configuring services (contrast this with how a distro like e.g. Fedora does it, where the package manager is expected to take care of restarting services on its own, per the Phoronix article from just the other day, whereas on Arch such practice is generally frowned upon), etc.

Anyway, all of the above is just a convoluted way to say that I do get what irks you about Arch's KISS attitude, to the point that if I ever decide to move on from Arch, this will be what will have motivated me to do so as well. But I don't see myself moving on anytime soon, because one thing is indisputable: passing through all these hurdles (which is really required only once, i.e. on first install) will end up with you having built one of the best and most solid Linux systems you can get, and with the added bonus that during the process you will have acquired a more than vague idea of how this system actually works, which means you'll have made your first step(s) towards transitioning from computer n00b to an actual computer user :)

Quoting: BielFPs

Quoting: NociferYeah, btrfs is certainly one of the best unknown gems of the Linux world, and implementing first-class support for it is certainly welcome. I expect and hope that now with Valve selecting it as the filesystem for the Steam Deck, more people will get to install it on their own systems (in an attempt to enjoy the full benefit of Valve's efforts on Linux gaming, which will probably include btrfs features like reflinks) and find out just how awesome it is.

What are the advantages of btrfs over ext4 (despite the RAID ones)? Any kind of performance improvements?

For me it's:

- the transparent filesystem compression (everything is configurably compressed on the fly, so you get less used space for the exact same contents)

- the integrated volume manager (I no longer need to partition my hard disk into /boot, /home, / or whatever else and then juggle with the free space between them; I just format the whole thing as one single btrfs partition, create a separate subvolume for each former partition, and there you have it: totally separate partitions in every sense of the term, but sharing the whole of the disk space between them as they/you see fit; it's like LVM on steroids but more performant, because it's tightly integrated with the filesystem itself, and also without the many usability headaches that come with LVM)

- the snapshots (the ability to instantly "capture" the state of a subvolume and store it as a backup, into which you can either return to should things go south - like the System Restore functionality in Windows but actually working - or treat it as a normal backup and selectively restore files from it when you need to)

- the integrated RAID support (the RAID 5/6 writing hole does not prevent you from using RAID 0 or 1, which AFAIK both work like a charm - never tried them myself though because my mdadm array is impossible to rebuild unless I spend a fortune on additional hard disks)

Quoting: Nocifer- the transparent filesystem compression (everything is configurably compressed on the fly, so you get less used space for the exact same contents)

Wouldn't this have impact on performance? Since it sounds like the file would need to be "decompressed" before its use.

I mean it sounds very good for storage disks, but I have doubts with something dynamic like games (of course I'm not expert on this subject)

Quoting: BielFPs

Quoting: Nocifer- the transparent filesystem compression (everything is configurably compressed on the fly, so you get less used space for the exact same contents)

Wouldn't this have impact on performance? Since it sounds like the file would need to be "decompressed" before its use.

I mean it sounds very good for storage disks, but I have doubts with something dynamic like games (of course I'm not expert on this subject)

Well, the thing is that modern games already work by loading the whole bunch of stuff they use into memory and using it from there, which is why most all games you see today come with their resources compressed into a small number of huge binary chunks instead of lots of separate files like it used to be. This is because your CPU and RAM are both orders of magnitude faster at I/O than even the fastest SSD, so it's much quicker to load these huge binary files into the RAM and decompress their contents on the fly than it is to load lots of smaller separate files from the disk as and when the game needs them. That's part of why modern games require so much more memory than before, it's because they're trying to eliminate the slowest part of your system from the equation, which would be the HDD (don't forget that consoles up to now only had HDDs, and most modern games are optimized for consoles first).

So the same is true for btrfs compression: in general, on an average modern system the CPU and RAM will be able to compress/decompress files much faster than they could be written on or read from the disk, so there will be no perceptible overhead. And there is also the "configurable" part, which allows you to configure the compression level and/or algorithm according to your specific needs and system capabilities. E.g., on a hard disk meant for storage you could increase the compression (because the speeds on HDDs are lower by definition so the overhead can also be larger without impacting performance) and on an SSD meant for everyday use you could decrease it to get higher speeds.

There's lots of benchmarks about this online, but a quick test on my system (with ZSTD level 3 compression) gives me the following:

Spoiler, click me

$ btrfs filesystem usage /
    Device size:                 465.26GiB
    Used:                        285.38GiB
    Free (estimated):            179.52GiB      (min: 179.52GiB))
    Free (statfs, df):           179.52GiB


$ dd if=/dev/zero of=benchmark bs=1M count=20000 && sync
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB, 20 GiB) copied, 8,64825 s, 2,4 GB/s


$ dd if=benchmark of=/dev/zero bs=1M count=20000 && sync 
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB, 20 GiB) copied, 7,38954 s, 2,8 GB/s


$ btrfs filesystem usage /
    Device size:                 465.26GiB
    Used:                        286.02GiB
    Free (estimated):            178.91GiB      (min: 178.91GiB)
    Free (statfs, df):           178.91GiB


$ compsize benchmark                               
Processed 1 file, 160169 regular extents (160169 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL        3%      625M          19G          19G       
zstd         3%      625M          19G          19G  


And as a bonus:

$ compsize /usr
Processed 409197 files, 268591 regular extents (274089 refs), 198321 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       49%      7.6G          15G          16G       
none       100%      3.6G         3.6G         3.7G       
zstd        34%      4.0G          11G          12G

Take these test results with as many grains of salt as you want, but I do believe they show that the compression more than benefits me and my system :)

Quoting: NociferBut I don't see myself moving on anytime soon, because one thing is indisputable: passing through all these hurdles (which is really required only once, i.e. on first install) will end up with you having built one of the best and most solid Linux systems you can get, and with the added bonus that during the process you will have acquired a more than vague idea of how this system actually works, which means you'll have made your first step(s) towards transitioning from computer n00b to an actual computer user :)

That first point is actually quite disputable. You assume that the person doing all this stuff is fundamentally competent at technical stuff--no doubt because you yourself are. If they suck, they could go through all that and end up making themselves a wonky piece of crap Linux system. I mean, there's been plenty of lousy distros, and those are put together by people with pretensions to technical knowledge; I don't see why many users couldn't similarly do a poor job configuring their own system.

The learning part is fundamentally good . . . but for many, not an important enough good to repay the time spent. I'd be in that camp. The world is big and complicated and there are many, many things to know about. I can't possibly know about them all. There is not enough time. And it so happens that on my list of priorities of things to know about, any more than a pretty dashed basic understanding of the nuts-and-bolts of my computers' operating systems is quite far down, well past quite a few other things that I will also never take the time to learn.


Last edited by Purple Library Guy on 19 August 2021 at 5:28 pm UTC

Quoting: Nociferpassing through all these hurdles (which is really required only once, i.e. on first install) will end up with you having built one of the best and most solid Linux systems you can get, and with the added bonus that during the process you will have acquired a more than vague idea of how this system actually works, which means you'll have made your first step(s) towards transitioning from computer n00b to an actual computer user :)

Well, I was TU in Arch and used it 2003-2017. Besides that I'm software developer and know my way around well enough.

That said, I switched from having to know the system exactly to I actually just want it to work and do my work with it than working on my own system.

It's a matter of perspective I'd say. But since I do not want to waste my time on finding out which optional depends got added if something stops working after an upgrade... not worth my time.

Quoting: Purple Library Guy

Quoting: NociferBut I don't see myself moving on anytime soon, because one thing is indisputable: passing through all these hurdles (which is really required only once, i.e. on first install) will end up with you having built one of the best and most solid Linux systems you can get, and with the added bonus that during the process you will have acquired a more than vague idea of how this system actually works, which means you'll have made your first step(s) towards transitioning from computer n00b to an actual computer user :)

That first point is actually quite disputable. You assume that the person doing all this stuff is fundamentally competent at technical stuff--no doubt because you yourself are. If they suck, they could go through all that and end up making themselves a wonky piece of crap Linux system. I mean, there's been plenty of lousy distros, and those are put together by people with pretensions to technical knowledge; I don't see why many users couldn't similarly do a poor job configuring their own system.

The learning part is fundamentally good . . . but for many, not an important enough good to repay the time spent. I'd be in that camp. The world is big and complicated and there are many, many things to know about. I can't possibly know about them all. There is not enough time. And it so happens that on my list of priorities of things to know about, any more than a pretty dashed basic understanding of the nuts-and-bolts of my computers' operating systems is quite far down, well past quite a few other things that I will also never take the time to learn.

Regarding the first point, touché. Re-reading what I wrote, I realize that I ended up seemingly painting Arch as some kind of special Linux system that's inherently better and more solid than the rest of the Linux ecosystem due to some kind of secret special sauce.

The point I was trying to make is more like this: Arch is potentially one of the most solid Linux systems you can have, exactly because you don't have to worry about random tweaks and/or misconfigurations by "technologically pretentious" third parties that could produce instability and/or undocumented behaviors that may result in messing up your system (i.e. the bane of most distros), due to the fact that your system is built by you.

The above comes with the caveats that a) this is valid only if you either already know what you're doing or you consciously treat the experience as a learning process, and b) if you know what you're doing, ALL Linux systems have the same potential for stability because you have the ability to tweak them yourself and reverse any unwanted changes.

That's why Arch is "one of the best" in my eyes: because a) due to its transparent DIY nature it give you the option to delve into the internals and treat the experience as a learning process, whereas most other distros provide you with an opaque system that you have no idea how it's built, and b) it gives you the potential to tailor it to your tastes right from the get-go instead of having to "debloat" your distro of choice post-install to bring it down to where you want it.

Which brings me to your second point: though of course I agree, that's not specific to Arch or Linux or computers in general but rather applies to every kind of skill or knowledge. As you say, there are more than many things one could learn, and not enough time or motivation for a single person to learn them all in one lifetime. So, the learning part comes with its own caveat: if you have an interest in learning more about how computers in general and Linux specifically work, then Arch is one of the best ways to go about it. If not, then of course Arch is not worth the trouble and you'd be better off using some other distro.

In my case technology and computers have always interested me, and before Arch I always hated the fact that I was using Linux but was not able to really tweak it or fix it (I'm the type who likes DIY in general, from fixing up a leaking faucet to maintaining a bike to building a backyard shed), so Arch was a natural next step. But of course while I was learning about Arch and Linux system administration, I postponed learning some other stuff that I will either have to learn later in my life than originally planned, or will never learn because they're too low on my To Do list. But, that's life priorities for you :)

Quoting: STiAT

Quoting: Nociferpassing through all these hurdles (which is really required only once, i.e. on first install) will end up with you having built one of the best and most solid Linux systems you can get, and with the added bonus that during the process you will have acquired a more than vague idea of how this system actually works, which means you'll have made your first step(s) towards transitioning from computer n00b to an actual computer user :)

Well, I was TU in Arch and used it 2003-2017. Besides that I'm software developer and know my way around well enough.

That said, I switched from having to know the system exactly to I actually just want it to work and do my work with it than working on my own system.

It's a matter of perspective I'd say. But since I do not want to waste my time on finding out which optional depends got added if something stops working after an upgrade... not worth my time.

And again, I mostly agree with the sentiment. Judging by that usage period I'm probably a bit younger than you, and I'm treading a similar vector: I'm also a software developer, which is why I originally loved the nuts and bolts approach of Linux and later of Arch, but nowadays I know enough about Linux and computers to satisfy my thirst, and also my work priorities have shifted to other, non-tech ventures (got bored with computers in general tbh), so I'm very much in favor of having a system that gets out of my way and allows me to simply do my work.

This means that, as I said in my previous comment, at some point down the road I'll probably switch to a more curated distro. But I can't overlook the fact that this is me speaking only after I've already cut my teeth on Arch and accumulated enough knowledge and experience with it to confidently know I'm able to administer any distro out there and tailor it to my requirements, even if it's not as DIY as Arch. In other words, probably like you're also doing with Solus.

I also can't overlook the fact that this only after Flatpak and Snap and Appimage (not to mention containers) have risen in prevalence and efficiency, which means that the Arch advantage of a rolling system + AUR is beginning to diminish in favor of a stable system + Flatpak/Snap/Appimage/container userland.

In other words, me using Arch nowadays is more a matter of momentum, yes, but switching from it will not so much be a result of Arch being especially tedious for me to maintain (e.g., as far as optional dependencies are concerned, pacman and the various AUR helpers, and even the GUI tools like Manjaro's Pamac, do inform you of any optional dependencies of any packages you're installing or updating) as it will be a result of other distros having caught up with it (again, very much due to Flatpak - I would never be able to go back to a fixed release distro as far as userland is concerned).

But again, I do understand the sentiment.

Quoting: LinuxScouserManjaro was my first taste of what it was like on an Arch based distro. I still haven't quite figured out how to run pure Arch as setting up my various installed drives and partitions purely by command line still terrifies me to this day.

I might have stuck with Manjaro if it wasn't for various issues like the author mentioned. The thing that decided it for me was the constant breakages of packages from the AUR which relied on dependencies from the Arch repositories which Manjaro always lagged behind on due to what seems like a good idea on paper. However, in reality there were still issues that occurred with updates for me which is what made me move on to the likes of Endeavour and Archcraft.

This is still a nice distro to help dip your toe into what an Arch-like environment feels like for those who've mostly been used to Debian-based derivatives.

Well most of those things layout maker does is only a a couple of clicks away with extensions, so its not really needed.

Quoting: NociferI also can't overlook the fact that this only after Flatpak and Snap and Appimage (not to mention containers) have risen in prevalence and efficiency, which means that the Arch advantage of a rolling system + AUR is beginning to diminish in favor of a stable system + Flatpak/Snap/Appimage/container userland.

Actually, that's something I hope Solus will integrate well. This works a lot better on other distributions already, and I do use snaps (for Spotify in example .. well, that's actually the only example :D).


Last edited by STiAT on 4 September 2021 at 3:38 pm UTC