Yup! It’s basically a slimmed down version of how Bazzite achieves ‘immutability’ - allowing it be very robust and pleasant to work with. And while it does sport GNOME, their optimizations enable it to run gracefully on a laptop with just 4 GB of RAM.

I’d argue it’s mostly polarizing; proponents love it, while detractors hate it. A nuanced discussion is what we’re missing…

It looks like the best options for immutable have a learning curve or time commitment attached (e.g. NixOS). For a daily driver computer it might be worth the trouble to learn, but in this case I decided to just go with standard Fedora XFCE for now.

Fam, don’t sleep on Endless OS.

VanillaOS and OpenSUSE immutable ones use BTRFS snapshots dont they?

For openSUSE’s atomic offerings, you’re correct. Vanilla OS is a bit more nuanced, though. I don’t quite recall how they did it on their original images. But since Orchid, there is a reliance on OCI images for its updates. Note that bootc is also contingent upon OCI images, which is why I made the comparison earlier. They behave so similar to one another, that Vanilla OS’ Vib can be used (without too much trouble) to create Fedora Atomic images.

As for the usage of Btrfs snapshots on Vanilla OS, I think it doesn’t quite need it because it relies on lvm thin provisioning instead for its ABRoot. However, an attempt to verify this by installing it within a VM failed spectacularly and I don’t think the blame is on me 😅…

Sorry, perhaps I should have been more clear.

It was meant strictly in the sense of how much it burdens the system performance-wise. So, in other words, using nix is easier on your system’s resources than rpm-ostree (or bootc) is; at least, that has been my experience.

In regards to breaking, I’m not sure whether one outdoes the other. Though, I suppose that nix -by design- would inch this out. But this is basically an ‘internal dispute’ between the crème de la crème; as rpm-ostree/bootc basically outdoes any other distro package manager that’s not named nix or guix.

While I absolutely adore everything rpm-ostree/bootc, I do think operations involving it are relatively heavy; at least compared to what else is out there.

Depending on your (in)tolerance, you might therefore consider opting for something else, instead. Assuming that this list does a considerable job at presenting your options, I’ll try to provide input on some of the more mainstream ones:

• openSUSE’s offerings. AFAIK, it is lighter. Heck, I’d reckon you might not even be able to distinguish it from its traditional counterpart; Tumbleweed. However, its ecosystem is still very much in its infancy. Hence, I don’t recall any of their offerings that don’t rely on GNOME/KDE-Plasma. There used to be Project Greybeard, but it’s far from lively… As for Aeon (i.e. GNOME version) and Kalpa (i.e. KDE Plasma version), they haven’t had a general availability release yet.
• NixOS. I have heard good things regarding how well it does on low-end PCs. However, FWIW, my own testing portrays a different story: I once had an update that resulted in a lot of compilation and my machine was struggling quite a bit. The same machine that handles Fedora Atomic quite gracefully*. Perhaps that was a fluke, but I wanted to point it out. I’d argue nix does handle operations more gracefully than rpm-ostree/bootc on average, though.
• Guix System. Perhaps I’m wrong, but I wouldn’t be surprised if this outdoes NixOS in terms of how gracefully it operates on a low-end system. This is mostly on vibes, though.
• Endless OS. If you liked Bazzite, but want something lighter, then this might be just that. It relies on ostree only and thus doesn’t have the heavier operations from rpm-ostree/bootc. The goals of the foundation behind it align with enabling low-end hardware. This is reflected in their system reqs. Note that GNOME is still relatively heavy, but you should be served well even on just 4 GB of RAM.
• ChromeOS Flex. For completeness’ sake, if you’re otherwise okay with this, then I suppose it’s another option worth considering. FWIW, there’s also FydeOS (and perhaps others).
• VanillaOS. Does something similar to bootc ever since its Orchid release. So, it’s probably not that light. Furthermore, I got many questions regarding the health of its ecosystem. This used to be another serious contender, but I’m afraid it might have missed the boat…
• GNOME OS and KDE Linux. While not production-ready yet, these will definitely be interesting in the long run.
• aerynOS. Another project that’s not production-ready yet.
• Nitrux. Definitely one of the more interesting ones. It has been around for quite a while now, but I’ve yet to come across someone that dailies it.

Having said all of that, the gist is basically that atomic distros are still relatively new. As such, I can only recommend Endless OS, Guix System and NixOS. Note that the latter two are rabbit holes, though.

A couple of years ago, I used both of them briefly and GNOME simply provided the more polished experience back then.

In time, I came to dislike the look/design of KDE apps.

So when the time came I wanted to ditch GNOME because I was sick of its extensions ecosystem, I didn’t even consider KDE Plasma. Instead, I tried out Sway and eventually settled on COSMIC.

Thank you! This is actually very helpful! And we can definitely reverse some of their doing 😉. Below I will repeat the invoked commands and provide some context/explanation. So, without further ado.

sudo rpm-ostree kargs --append-if-missing=zswap.enabled=1
sudo rpm-ostree kargs --append-if-missing=zswap.max_pool_percent=25
sudo rpm-ostree kargs --append-if-missing=zswap.compressor=lz4
sudo rpm-ostree kargs --append-if-missing=systemd.zram=0

The commands found above were used to change the kernel arguments through rpm-ostree. You can still find these back with rpm-ostree kargs --editor. You can even outright remove them, then and there. It’s also possible to literally revert those commands by invoking the following:

sudo rpm-ostree kargs --delete-if-present=zswap.enabled=1
sudo rpm-ostree kargs --delete-if-present=zswap.max_pool_percent=25
sudo rpm-ostree kargs --delete-if-present=zswap.compressor=lz4
sudo rpm-ostree kargs --delete-if-present=systemd.zram=0

sudo rpm-ostree initramfs --enable --arg=--add-drivers --arg=lz4

Unfortunately, I don’t have any experience with this.

sudo swapoff -a
sudo rm -rf /var/swap
sudo semanage fcontext -a -t var_t "/var/swap(/.*)?"
sudo restorecon -Rv /var/swap
sudo btrfs filesystem mkswapfile --size 32G /var/swap/swapfile
sudo semanage fcontext -a -t swapfile_t "/var/swap/swapfile"
sudo restorecon -v /var/swap/swapfile
sudo swapon -a

Basically, the commands found literally above affect the contents of /var. As such, they’re outside of the ‘jurisdiction’ of rpm-ostree. Reverting these is the same as on any other Linux system.

The following commands change the contents of /etc. As such, they’re being tracked and can be reverted to their original states. Though, I’m not sure if it’s possible to revert them back to their respective versions without those changes.

sudo sed -i '\|/var/swap/swapfile|d' /etc/fstab

I’ll be honest with ya. I don’t know what this one does 😅. I have used sed in the past but wasn’t able to decipher this one. FWIW, it tries to make some changes to /etc/fstab . And, if I’d have to make a guess, I think it deletes any lines that contain /var/swap/swapfile.

echo "/var/swap/swapfile none swap defaults,nofail 0 0" | sudo tee -a /etc/fstab

This added some text to /etc/fstab. To revert it, go to /etc/fstab, and remove /var/swap/swapfile none swap defaults,nofail 0 0

echo "vm.swappiness=120" | sudo tee /etc/sysctl.d/99-swappiness.conf

This created a file named 99-swappiness.conf and placed it to /etc/sysctl.d/. As such, a simple sudo rm -rf /etc/sysctl.d/99-swappiness.conf suffices.

sudo rpm-ostree install policycoreutils-python-utils

This was an optional command. If you did have to invoke it, then you should find policycoreutils-python-utils when invoking rpm-ostree status. It should be mentioned as a layered package.

To undo it, simply invoke rpm-ostree uninstall policycoreutils-python-utils.

Bazzite’s messaging has merit, but we’d be making a mistake by regarding it as absolute. It makes more sense to take them as carefully written guide lines for a specific audience.

Furthermore. with all due respect, but OP’s writing doesn’t imply installing/managing software with rpm-ostree. Which, is actually the subject of the documentation entry you quoted. As such, I think you might have misunderstood them.

Youre breaking a core tenant of immutable distros by installing system level packages.

Finally, FWIW, I absolutely disagree with the above. The page you quoted from seems to agree with me on this: “Layering packages are mostly intended for system-level applications, libraries, and other dependencies.”

I made some changes using rpm-ostree related to zram and swap

Could you be more transparent and/or elaborate in this regard? Like, what did you actually do?

FWIW, I’ve been on Fedora Atomic since before Bazzite’s existence, but I’ve never once considered using rpm-ostree to make changes to zram and swap. So, I’m a bit confused. To be clear, it’s perfectly possible that what you did is 100% legit, but that it just happened to expose a gap in my knowledge.

I had assumed that, because I used rpm-ostree, the changes would become part of the “tree” and I could rollback to the original settings. But when I went to look at Bazzite’s rollback tools, it seemed solely focused on rolling back to previous official releases, and I couldn’t find any reference to the specific changes I made.

Basically, while rpm-ostree does offer git-like control on your base system; hence, why it’s so powerful to begin with. It does not keep more than two deployments around; at least, by default.

If you would like to keep around a specific deployment (for whatever reason), you can do so with the ostree admin pin <insert number> command. The git-like control also enables you to keep track of:

• the changes applied to /etc; invoke ostree admin config-diff to see what files have been added or modified since installation
• layered packages; simply invoke rpm-ostree status

Keeping track is cool and all, but its usefulness is in full display with powerful applications such as:

• rpm-ostree reset; this basically removes all permutations. That is, two people on the same image, will have the identical base system after this. (Note that this still isn’t as powerful as a factory reset. For that, refer to this issue tracker on bootc^[1].)

Finally, the git-like structure ensures actual reversibility. On most other systems, installing A -> installing B -> uninstalling A will yield a different state than just installing B. With rpm-ostree, the base system between the two will be identical.

For completeness’ sake, I’ve used “base system” above to just mean the contents of /usr and /etc (and maybe some other subdirectories of /). Crucially, the contents of /var are not part of the “base system”.

Thanks! Much appreciated 🙂!

Can someone please provide a TL;DW? Much appreciated!

For posterity’s sake:

• I’d like to thank everyone. However, I didn’t quite get the feedback I was hoping for. Perhaps these wallets are too niche. I don’t know…

In the end, the reqs found below only yielded Frenchie Co.'s Speed Wallet Mini - Aroma Collection (with Essentials Pocket). So, it became the wallet I ultimately decided upon.

• Semi-perimeter ≤ 163mm and Depth ≤ 30mm (Both of these values are data-informed to justify the wallet as compact)
• Capacity floor of:
  • 7 cards
  • some amount of 160 x 77 (in mm) bills - which will be straight inserted without requiring pre-folds or causing wrinkles
  • some amount of coins
• Still in production
• Presence of third party clout. Basically; do people talk about it on the internet
• Contained bills shouldn’t be exposed when handling cards or coins
• Sane handling only; for reference, both TROVE Cash Wrap and Slimpuro Znap fail this
• No prone-to-yellowing ID windows
• At least one premium/quick access slot from where a card can be pulled (and reinserted) with the wallet closed
• Offers Selective RFID while shut/closed; shields the bank card, lets a transit card tap through a closed wallet. Full RFID kills the tap; zero RFID forces sleeves on the cards you do want shielded

FWIW, I wouldn’t be surprised if a subset of the above would already be sufficient to single out Frenchie.

No worries, fam. Thanks for chiming in!

Do your pants have a change pocket?

Hehe, most of them do. So, I suppose I got my answer. I’m not sure how robust it is, though. Perhaps I should buy pants that do a better job at keeping it shut.

I hadn’t heard of them yet. Looks cool. Thanks for mentioning it.

Though, I wasn’t able to find any of their offering that provides a solution to both:

• carrying coins
• fitting/inserting bills unfolded

Do you happen to know if they sell any wallets that satisfy both requirements?

Yeah you’re right, don’t think they do because of the unfolded requirements,

Yup, I believe that’s the primary culprit.

The push towards minimalist wallets has produced plenty of innovation and I’d say has been great overall. But it’s a pity that folding bills has pretty much become a given across the board 😭. Which, I suppose is somewhat expected as it’s quite straining on the design space.

Thank you for your thoughts!

Coin capacity is highly overrated.

I personally agree with this.

You put your wallet in a pocket. Coins can also go in the pocket. You still have to dig around to find the right number of coins for the task, regardless of which method you choose.

But the idea of loose objects in my pocket doesn’t sit well with me. Perhaps it’s a me-issue; I only use my front pockets. Ever. So, the coins would (probably) reside together with other objects: could be phone, keys, or wallet. The thought that coins may slip/come out of my pocket whenever I’m grabbing something else horrifies me. It’s not even about the unnecessary loss of money, but the fact that my EDC doesn’t provide a robust solution to it.

I’m somewhat of a perfectionist. Hence, I’d rather be over-prepared instead of under-prepared. Even if this causes friction with minimalism. Thankfully, a wallet like say Frenchie Co.'s Speed Wallet Mini proves to me that a minimal coin pocket shouldn’t be too much to ask.

Don’t underestimate the value of RFID blocking.

I used to be a die-hard RFID fan. But Walletopia’s videos on the topic led me to believe it’s more nuanced. However, I wouldn’t be surprised if my understanding is still severely lacking. So please feel free to educate me 🙂.

FWIW, all the wallets mentioned in the post offer RFID in some capacity.

Regarding your thoughts on card storage areas, they do resonate with me. I believe this is somewhat reflected in the shortlist:

• STUDIUM timik basically has two pockets/slots for cards. One of which is supposed to work as a quick access slot, the other is larger and is able to contain like half a dozen cards or so.
• The Frenchie Co.'s Speed Wallet Mini doesn’t even have single-card pockets/slots. Instead, it has two high-duty pockets/slots that demand three cards each.

I believe this is the primary reason why they can have such a small footprint while being very thin still. (The EXENTRI Multiwallet has a considerably larger footprint than both. Allett Coin Wallet 2.0’s footprint is even massive.)

The bigger the wallet capacity the more you will fill it. You really don’t need all those cards.

I agree. Currently, there are only 4 (type of) cards I’d like to carry:

• Bank cards
• Public transit cards
• Identification cards
• Tracker cards

And it’s very much possible that I’ll only carry one of each. Tracker cards are thicker than regular cards, though. So, effectively, even with just one of each, it’ll be as if I’m carrying ~5-6 cards.

The one downside of this is that your basic two panel elastic wallet kind of sucks for cash. But I don’t use a lot of cash anymore.

I still need my cash 😜. But thanks for mentioning it!

You can’t however make it use other init system or other DE/WM.

You’re AFAIK correct on the bold part. But definitely not on the strike-through part. You’re probably only limited by your creativity and the effort you’re willing to put into it:

• Bazzite, but with Hyprland
• Bazzite, but with niri
• Bazzite, but Windows-themed | It’s basically KDE Plasma, but you get the point.

I have snapper and pika backing up, so in a few minutes all is back to normal, so the main selling point of atomic/immutable distro is kind of irrelevant to me

FWIW, openSUSE literally pioneered the above workflow with Tumbleweed. But that didn’t prevent them from developing openSUSE MicroOS (and its desktop-adjacent siblings). So, unless openSUSE has absolutely no clue on what they’re doing, there is more to it than that. Even if ‘that something’ isn’t relevant for you (yet).