The major tradeoff with zRAM is that programs are much more likely to crash due to running out of memory, but will run faster when memory is running low and freezes are less likely. You can think of it as offloading the pressure that traditional swap puts onto your disk, onto the (much faster) CPU. There will be an impact on CPU usage, but not enough to cause noticeable slowdown; in my experience running Linux, the CPU is almost never the reason something is slow, and is only going to be under significant pressure if you're running a 3D game in software rendering, compiling a large program, or another complex CPU-bound task.
I wouldn't recommend making the switch unless you often encounter system freezes or slowness while running tasks that use a lot of RAM (like web browsing on certain sites, or gaming), but it will improve things in that case.
I'm gonna give it a try in my current session and if it works I'll make it permanent.
One more thing I'd like to ask though is what would be an appropriate size for zram? Considering it
grows dynamically 50% would probably be a good amount right?
Btrfs snapshots are already used in openSUSE microOS which is branded as immutable. And AshOS generalizes it for any kind of distro: https://github.com/ashos/ashos . I think it is nice middle-ground for regular distros, which does them more reliable.
But for me, immutables are more about separation between the base system and the apps, where the base is not only immutable, but image-based: ostree, A/B partitions, systemd-sysupdate. And the apps are distro-independent: flatpak, containers, and so on. So apps are upgraded independently from the system, and one doesn't need to upgrade the system just to have apps updated or vice versa. Btrfs snapshots doesn't solve anything here by itself.
Depending on how it's done they aren't really comparable.
I'm not familiar with openSUSE's immutable distro, but Fedora bases their atomic variants on what are essentially glorified container images (meaning they include a kernel for example). Every single deployment of a given image will be identical to each other. Only certain directories are writeable so that configuration and user data can be modified independently of the base image.
You can also "overlay" your own/custom packages, which essentially installs them into the image. When updating, a new base image is pulled and your overlayed packages are installed into the base image again. With a "regular" distro, you are deriving from the default install as soon as you install packages or even uninstall default packages (which also works with atomic distros, but the package removal is overlayed).
It's not so much about the ability to rollback as it is about reproducibility across several machines. It's comparable to how iOS (and recently also macOS) and most Android variants work.
Btrfs snapshots + Snapper have been (somewhat) pioneered by openSUSE Tumbleweed. Yet, they see value in developing openSUSE Aeon (i.e. their attempt at an 'immutable' distro); otherwise they wouldn't be putting resources into it.
Hence, Btrfs snapshots is (at best) only able to fulfil some aspects we've come to expect from 'immutable' distros. But there's more to it than that.
One of the most simple (and, yet, perhaps most defining) feature that 'immutable' distros come with is atomic updates; i.e. updates either occur or not, there's no in-between messed up state caused by energy outage or whatsoever.
There's a lot more to it than that. To mention a few more:
reproducibility
declariative system management
(some) prevention of cruft accumulation, bit rot and configuration drift
better security related to read-only part of OS
a lot less undefined/hidden/unknown state
Not all 'immutable' distros possess these qualities. Nor are they aspired by all of them. Hence, lumping them up together is actually a blatant oversight that's been committed way too frequently.
Regardless, if you're interested, consider trying out Fedora Atomic^[1]^, NixOS or openSUSE Aeon for yourself and see what it's all about.
Either through Fedora's own images or the ones provided by uBlue.
This is what I did, and it did its goal in making me comfortable using Linux. However, like what others suggest, live USB is probably much more easier honestly.
I like yadm - yet another dotfile manager. It uses a Git repository in the background, which you can sync with GitHub, GitLab, Codeberg or a selfhosted Git server like Forgejo.
This interests me. I may have to check this one out specifically for my configuration files. And I will definitely go the self hosting route if I do this. Thank you!
My preference is „bare metal” approach, then I really know if everything is working as it should, so I had a separate drive for Linux installation at the beginning and got to my other drives by just mounting them as NTFS.
But, finally I am at the point of no return for some time now, the old Windows drive is not even inside of my PC and the other drives are ext4 already.
For a quick check Live CDs/USBs are totally fine but not fully representative.
I use VBox to run my PiHole for now and have used it to play with a couple distros side by side. I also have a sup'd up tower built from spare parts from work, so resources aren't a constraint.
what partitions do linux distros need to function ?
Many guides will suggest setting up separate partitions for a bunch of different Linux directories. It's not strictly necessary to make things work properly. You can totally do it all on one partition (in addition to your windows one I mean). If you want to try something more fancy then keep a separate home partition, but honestly don't worry about it much unless a guide or installer is suggesting it.
is it bad idea to install linux on a single drive in its own partition ?
Nah. One big Linux partition isnt a bad thing and is a lot easier to grasp when starting out. (Though for dual boot you'll need the windows partition somewhere still)
what precautions should I take other than backing up my hard drive before doing dual boot ?
Backups are the main thing. Maybe a list of useful Windows software you have installed, just in case you accidentally break your install and can't boot in to check what you had installed.
Make Windows recovery media and a windows install disk if you don't have one. Just in case you need to go back and reinstall it can help avoid trying to do that without a working machine.
Test with a live usb first too. That way you can at least boot into the live Usb if things fail. And you will already have it prepared.
How can I ensure my dual boot linux install won't touch my windows partition at all if I install dual boot linux ?
I think you could mount your windows partition as read only if that's a concern. I don't expect any Linux distros to mess with anything though unless you're reckless about running install scripts.
Is there anything else I should be aware about ?
Linux guides vary between "here's a hack to just make it work" all the way to "here's a perfect Torvalds-Approved perfect bomb proof 100page configuration guide". Make sure you know what you're looking for first and don't get too caught up on making everything perfect. Focus on keeping good backups so you can restart from scratch if you ever need to. You'll probably end up trying a few Linux distros over the next few years anyway.
This - but I’d take it a step further and use a small-ish USB 3.2 SSD with Ventoy instead. That way, your live Linux experience isn’t kneecapped by having to load programs off a slow USB stick. In a pinch you can use a SATA SSD with a USB-SATA adapter too, that way you can cram a ton of ISOs on there and go to town.
Linux
Active
This magazine is not receiving updates (last activity 0 day(s) ago).