A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
Works, fedora atomic desktops with ostree and no changes. If you want changes using rpm-ostree that will become really slow.
NixOS is also immutable and if you dont stumble over something that needs compilation as it is not in the binary caches, it runs very fine on lower end hardware like my Chromebook. Not a potato but pretty damn slow
I personally am using Fedora KDE on a old chromebook with 4GB of ram but I'm thinking about switching to Fedora Kinoite. From my experience 4GB is plenty for a Linux machine as long as you aren't using things that are ram heavy. Firefox based browsers do especially well as Firefox writes inactive tabs to disk
I can recommend universal blues base kinoite image as it includes distrobox, all video codecs and has an nvidia variant for the poor nvidia users
I don't actually need any of that but I am thinking about using Forgejo actions to build a custom image
Yeah that would be the "cloud native" way XD
I have used Gitea actions and container registry before, it is okay.
You could give Fedora Sway Atomic a try, it's basically Fedora immutable (same as Bazzite), but with Sway (tileable, keyboard centric window manager) desktop. It's low on resources but I'd say it's not for everyone.
Or you could build your own Fedora bootc version with whatever desktop environment you like. The syntax is that of Containerfiles and even if you've never build a container image before, it's extremely easy to do.
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:
nix does handle operations more gracefully than rpm-ostree/bootc on average, though.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.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...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.
VanillaOS and OpenSUSE immutable ones use BTRFS snapshots dont they? Not sure how VanillaOS does their A/B root.
These systems always involve copying things around and deduplicating them.
Filesystem snapshots are well deduplicated, nixos does that well too though.
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 😅...
I'd argue
nixdoes handle operations more gracefully thanrpm-ostree/bootcon average, though.
What do you mean by this? Did rpm-ostree break something?
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.
Fair enough, I never bothered to do any perf benchmarking myself. It's as you said, at that level, it just comes down to personal preference
Depending on your drivers, you could give Guix a go. It's not for everyone; but it's decent, solid, and I used to run it on a 32-bit machine with 3GB of RAM.
If you do require nonfree drivers, there are guides to set it up using Nonguix; but I don't know how well that works (I am yet to try it).
NixOS. you get out of it what you put into. the initial setup might take a bit but once you have it set up to your liking then that's it, you can just leave it alone until you want to update it whenever that may be. it's extremely re-producible, you can git repo your config, install it where ever or on whatever machine so if you ever do upgarde then you can take your system with you. with the generations if you happen to break something or mess up a config it's just a matter of going back to the previous generation and undoing whatever you did.
you can configure it in a way that it will work well on your machine. easy to change kernel params via the nix config, ssd/hdd settings, cpu settings, etc. the only time it gets heavy is when you update it but like I said you update it whenever you feel like updating it. you could leave it alone for a year if you really wanted to. it's still going to work.
NixOS is like the opposite of Bazzite. On Bazzite you don't configure anything, so no need for a git repo or anything. Just install the OS and start using it. (Bazzite also supports rollbacks btw).
Having to configure and manage every little thing, is like the opposite of the ethos behind Universal Blue distros like Bazzite.
On fedora atomic desktops /etc is completely writable so you can configure some things. And using rpm-ostree it is possible to do weird things too
But you should have a look at how Bazzite is actually built. A bunch of containerfiles, scripts, ujust files, ... not hard to understand but kinda messy. And you kinda need a server. On NixOS you do this on your machine.
And do note that there are presets online and people help you set things up.
I'm aware of how fedora atomic distros work, and that some things are configurable. My point is that a Bazzite user doesn't need to touch the cli or any config file, to just start using their desktop. I think those of us that have been using Linux for years, forget how rare it is for Windows and Mac users to touch the cli or config files. That's the experience that the Universal Blue ecosystem seeks to provide.
A bunch of containerfiles, scripts, ujust files, ... not hard to understand but kinda messy.
I prefer containerfiles tbh, because I use them for my server too.
And you kinda need a server. On NixOS you do this on your machine.
Technically you could set up the ublue infra on your own machine. Building and serving container images inside a container on your own host. Though it's more overhead than NixOS I'm sure.
do note that there are presets online and people help you set things up.
I'm aware but from what I've heard it's similar to docker compose configs. You can't just paste them in and expect everything to work. You'd have to copy one person's config for their entire desktop, and never deviate. At that point you may as well just use rpm-ostree, which is designed for this sort of workflow.
Why is immutable a requirement?
Not a requirement, just my preference.
I got lubuntu running on an apollo lake celeron Chromebook from 2020 with 4GB of ram and a 32GB eMMC drive. For the most part it does pretty well with web surfing, email, document/spreadsheets etc. There is quite a bit of delay (on the order of a minute or two) when using Discover to update anything, or to even browse the store. I don't know if that's due to lubuntu not loading discover when the Chromebook boots up for some reason or that the eMMC drive is really that slow.
I have a 128GB micro SD card in it as well that I am trying to set up as the main drive location for Discover to install things to, but it's giving me some issues.
I haven't tried any gaming yet, because of the micro SD card issues, but once I get that figured out, I plan on installing Heroic Games Launcher, and then installing some lighter weight games, I have RCT3 and SimCity 2000 in my GOG library, as well as the original 1993 Myst and 1997 Riven games. I think all four of those should run okay, but I'm not sure what overhead WINE/Proton will add to the mix.
Immutable uses more memory during many operations. You're probably not going to find anything stable, with a desktop, and all the other bits you'd expect running at under 4G. Safely.
That being said, any other traditional distro is lower maintenance anyway. Not sure why you think immutable is special in that regard.
Why do you think immutable distros use more memory?
Change management on a layered FS, containers everywhere...etc.
Depending on what you're doing, it can make a big difference. Especially when you're talking about a 4GB machine with little to no margin of extra working space. Updates will certainly be problematic.
I think updates depend on the system itself, I can only speak about the one I know, bootc and it has no additional overhead in comparison to a regular rpm system. In fact, all that it does in the background is run dnf/rpm in a container and then simply dump that container in a separate partition. Nothing memory heavy happening there.
As for running containers, the memory overhead is negligible, at the order of a couple of megabytes per container at most.
The only strained resource on a immutsble system is arguably disk space, but usually that is mitigated by deduplication.
Yes, but as I said, on a 4GB budget, this matters quite a bit. I run thousands of edge devices on a custom distro with similar constraints, and it adds up quickly. It's not that it's insurmountable or anything, but I'm answering the question asked and not getting into the particulars. It's just a known fact.
FWIW I switched over to Nix recently, and discovered that deploying builds over SSH is a first-class feature.
I wired up remote build pushes from my workstation to my underpowered VPS + antique thinkpad, and it’s been 100% painless. You can definitely make immutable work on <1 GB memory without much fuss if you’re not locked into a single-device model.
Adding a few 100mb of ram usage won't impact something with 4GB of ram