• 0 posts
  • 47 comments
Joined 2 months ago
Cake day: July 7th, 2026
  • 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 for reply.

    It has been my pleasure! Thank you for replying back :) .

    Yes, I would be ok with A as well, but I am learning things slowly to get to that point.

    While I absolutely respect that attitude, it’s worth noting that literally none of the hardened and respected distros are a one-man show. Which is my way of saying that unless you pursuit a career in cyber security, you’re probably better served elsewhere.

    So B for now would be great.

    Aight. Excellent.

    But it seems like OpenBSD might not be great for running VMs

    IIRC, it depends. If a TTY/terminal-interface is all you need, then vmm handles that pretty well. But if you’d like to run applications that have their own graphical interfaces, then OpenBSD’s solution might not be adequate. At least, it wasn’t the last time I did a thorough check on the distro.

    Could not find much info for virtualization support on HardenedBSD though. Not sure how well bhyve work there, but it seems like VMs might not work well or be performant enough on either of them.

    IIRC, bhyve is pretty good actually. Performance-wise, it is good enough to do gaming even. As HardenedBSD is simply hardened FreeBSD, I don’t have a serious reason to assume it ain’t able to do that.

    On that note, I want to mention quBSD as an interesting project. It kinda aims to bridge the gap between Qubes OS and FreeBSD. Its developer hasn’t released anything yet, but it’s worth keeping in mind.


    Having said all of that, I want to state clearly that there is a disconnect between what’s out there and what you want:

    • Alpine is pretty decent security-wise, but -like literally most other distros out there- security is somewhat of an afterthought. Like, unless it is a platform-wide accepted ordeal, it will not consider pro-active hardening. This also more-or-less applies to the likes of Artix, Gentoo and Void. So, it relies on your expertise for serious hardening.
    • OpenBSD’s vmm doesn’t do GUIs.
    • Kicksecure and secureblue while being Linux’ finest security-wise, do rely on systemd. Same applies to NixOS derivatives like SécurixOS and Spectrum OS.
    • HardenedBSD. Which, actually looks pretty fabulous otherwise, may not support flatpak. Don’t quote me on this, though*.
    • Qubes OS’ system requirements are too high, as you point out elsewhere.

    So…, what does that leave us with :P ?

    Is an amalgamation between sixos and nix-mineral in which you try to port all systemd-related hardenings the best we can do?


    However, I’d argue that a possible eventuality might yield us an actual winner.

    Recently, Flatpak’s maintainers/developers noted work on Flatpak Next; a successor to Flatpak, if you will. The hope is that it’ll eliminate some of Flatpak’s glaring issues. However, they also announced that it will depend on systemd.

    Granted, the eventual thing we’ll receive might not depend on systemd at all. Heck, even if it will, perhaps some distro maintainers will provide a workaround OR just keep on relying on the old flatpak that might get new maintainers. So, there’s absolutely no reason to go full-on FUD right now.

    Yet, an out does exist that doesn’t depend on anything of the above; simply by not requiring flatpak support. In which case, HardenedBSD it is. FWIW, with access to VMs, you can also continue to enjoy your flatpaks through a VM. Which, literally happens to be the simplest fix to salvage an “almost”.


    P.S. if you didn’t figure it out yet, your query is something I asked myself a couple of years ago 😅.

    P.P.S. I forgot about Chimera Linux. I’m not well-versed into it, but perhaps another interesting one to consider. At least alongside Alpine, Artix, Gentoo and Void.

  • I suppose it’s a good time as any to try it out :) .

    FWIW, I’ve been on (a derivative of) Fedora Atomic for over four years now. There’s a learning curve if you’d like to translate some of your existing workflows, but it has overall been a very smooth experience. Like, the last time something broke was with the mesa mess-ups over three years ago. And the beautiful thing with Bazzite is that it can protect its user base from such instances. The how-part would dwarf the existing text, so I digress (for now 😜).

  • I don’t agree with the sentiment that Linux Mint is underrated either. As you note, it is quite popular and is mentioned a lot in the discourse.

    However, I don’t think that CachyOS and Linux Mint are the most popular distros; that undoubtedly goes to Ubuntu. And, if anything, I’d think that Linux Mint is more popular than CachyOS.

    Yet, if we’d limit it to the distros used by gamers, then CachyOS probably does take the crown for most used distro (aside from SteamOS). At least, there are metrics that suggest as such.

  • Sorry for the late reply

    No worries fam 🙂.

    thank you for taking your time!

    It has been my pleasure 🙂.

    I have “defaulted” back to Artix, having fixed the NIC issue.

    Glad to hear that you were able to return back to your home.

    And I agree, Gentoo is what I dream of being able to handle, but all the USE flags KILLED me when I set it up for the first time a month or so ago. xD I do want to get back to it at some point though.

    Good mindset! I’m sure you’ll manage whenever you get back to it 😉.

  • If it isn’t broken and does what you need, why update, you know what I mean? Especially if it isn’t connected to the internet in some cases. 😁

    I agree with that assessment whenever it’s not connected to the internet. But, if it is, I actually find it hard to justify for myself to not (at least) receive the security updates. Which, in the case of non-frozen packages, suggests applying regular updates.

    But yeah, more than anything, I think this touches on threat models. Which are very subjective by themselves and thus probably not very interesting to discuss 😜.

    Regarding what you linked to paccache, which setting(s) were you referring to specifically? I don’t think I was able to understand that it is directly suggesting or indirectly insinuating any type of update frequency. But I probably am just too tired to process. 😅

    My apologies, perhaps I should have been more elaborate. So, paccache’s man page mentions a systemd timer it refers to as paccache.timer. With it, package cache can be cleaned periodically. And, by default, it does so weekly.

    As to why this suggests weekly updates as a lower bound, paccache removes old packages. Thus, from my understanding, paccache goes hand in hand with updates; updates yield the old packages which will be deleted by paccache. As such, for two consecutive paccaches to do anything, an update has to have occurred in between. Thus, if paccache.timer defaults to weekly cleanups, then it has to be accompanied with at least a weekly update.

    Of course, paccache will handle higher update frequencies without any problem. Thus, updating only once a week becomes a lower bound for paccache.timer’s default functionality.

    To be clear, I only said “suggest” :P . I can’t do any stronger claims 😅.

  • Thank you for sharing that!

    Your approach to updating contains only a subset of what was found on the wiki, but I’m glad to hear that it has proven to be sufficient 🙂.

    Ubuntu broke loads of times for me back in the day. Had to reinstall it several times. And all I did was issue the command for upgrading to a new Ubuntu point release. 😅

    I’ve heard many horror stories of upgrading on Ubuntu 🤣🤣🤣. Thankfully, Arch has been good to ya 🙂.

  • If I see an Arch user recommend updating daily, I would definitely question their experience. 😅

    Interesting.

    So, as I kinda alluded to elsewhere, I don’t daily Arch nor have I ever done so in the past. I did have it as a dual boot earlier in my Linux journey. However, after breaking it for the second time, I just called it quits 😅.

    Anyhow, with that out of the way, I am interested in your perspective w.r.t update frequency on Arch.

    It has basically been my head canon that updating daily is (at least) reasonable on Arch. And while its excellent wiki doesn’t dictate any number, I’m inclined to believe that -by updating once a week- one is acting by the lower bound in terms of frequency; I’d argue the default settings of paccache suggest as such.

  • not if you just postpone updating to the same schedule as Debian, lol.

    LOL, indeed.

    About the breaking part, kudos to you for doing a great job at maintaining Arch. But I assume/think[1] most people don’t enjoy ‘babysitting’[2] their OS 😅.


    1. Please feel free to push back on this. ↩︎

    2. This term isn’t meant derogatory or anything. But it’s what comes up to me whenever I see how involved this is. By contrast, I actually do apply daily updates on my semi-rolling daily driver. But I never have to give it any thought. Heck, it even happens automatically. ↩︎

  • Arch is an OS that’s quite fully featured

    Not entirely sure what you mean with that.

    suited to veteran/power users

    The gist is that Arch pretty much comes with little to no defaults. So, you are literally put into the position to make all the important decisions. Which, as you might have imagined already, basically requires you to be pretty knowledgeable on Linux in the first place. Thus making it mostly unsuitable for new users. Though, I won’t dismiss a special breed of newb that somehow manages to rawdog it quite ‘successfully’.

    because it has regular updates

    We refer to its release cycle as rolling release. Which basically alludes to the absence of a point release.

    The version of Linux Mint you were on is 21.2 and you’ll soon be on 22.3. After some time, you’ll be on 23.x etc. These are referred to as point releases. So, whenever a new point release update hits, you’ll receive a couple of months’ worth of updates. And between two consecutive point releases, you’ll receive little to no updates. So, basically, Linux Mint deliberately chooses to hold updates of. By doing so, it ensures you’ll only receive updates that have undergone thorough testing.

    Arch, on the other hand, has a much leaner testing phase. Heck, as pointed out earlier, it doesn’t even wait for a certain moment to reach before it outputs an update. Instead, after the packages have had some testing, it pushes the updates out for its users to receive it. As such, you’ll receive constant updates. And you’re somewhat expected to at least perform daily updates. By doing so, it ensures you’ll always have access to the latest and greatest.

    Note that Arch is not the only rolling release distro. But, out of the ‘Big 3’[1], it’s the only one that is rolling release by default.

    Its release cycle does indirectly contribute to Arch being less newbie-friendly. Basically, any update comes with the risk of causing breakage. On Debian, this risk is partly mitigated by the infrequency of updates and by pushing out very well-tested updates to begin with. On Arch, you just have to deal with it every once in a while.

    Note, however, that it’s most often your fault and not Arch’s. Secondly, after dealing with this a couple of times, you’d have acquired some excellent skills in troubleshooting.

    highly mutable

    Traditional distros are basically equally mutable. So, Arch doesn’t (necessarily) outdo e.g. Debian or Fedora in this regard.

    It has its own repo too by the looks of it?

    It does. But that’s a thing with independent distros. Linux Mint is a derivative of Ubuntu. Which, itself is a derivative of Debian. Debian, however, is independent. Similarly, Arch isn’t derived from anything else; hence, it’s an independent distro.

    The list of independent distros isn’t huge or anything, but I suppose there are at least a couple of dozens of 'm.

    As for the own repository part, both pkgs.org and repology.org feature some resources on that.


    1. The others being Debian and Fedora*. ↩︎

  • hardened

    This is an important keyword but perhaps not sufficiently discussed. I’d reckon focusing on it will be pretty helpful.

    So…, what is it you want? Is it

    • A. Make a fortress out of a very decent starting point? To daily drive it afterwards*.
    • Or B. Daily drive a fortress built by someone else?
    • Or perhaps even C. Something else entirely?

    By the rest of your post, I’d bet on B. Which, puts us into an interesting situation…

    systemd free

    Assuming[1] DistroWatch does a decent job at tagging/categorizing, there are only a handful of distros that are both systemd-free and tagged with “security”. Note that half of these don’t survive it upon closer inspection, which leaves us with Alpine, HardenedBSD and OpenBSD.

    If you’re well-versed into hardened distros, you’ll note the absence of Linux’ finest in this category; namely Kicksecure and secureblue. Their absence is due to their (heavy) reliance on systemd for additional hardening.

    Furthermore, note that DistroWatch doesn’t mention how well the likes of Artix, Gentoo and Void (among others) would function as excellent starting points to build your own fortress from.


    1. To be honest, I don’t see any reason to not grant them the benefit of doubt. As far as I can tell, their lists look complete. ↩︎

  • Others have basically already pointed out how you should go about diagnosing the problem. Which, by itself, is already very valuable.

    Below, I will try to touch upon some tips and tricks that are worth noting in this context, assuming Bazzite*.

    • Pinning a specific deployment to return back to. As we’ll be doing some time traveling in a bit, it’s definitely recommended to pin your latest deployment (just in case) before you do anything else. See this entry in Bazzite’s documentation on that.
    • Rolling back to images from a certain day. So, IIRC, all of the uBlue products keep around 90 days worth of images you can rollback to. See Bazzite’s documentation on brh for more information. With this (and some effort), you can literally pinpoint the exact date from which you started to have problems with gamescope/game mode.
    • Looking into the exact changes between two deployments. So, after you’ve identified the last properly working deployment and the first deployment that started misbehaving, you can invoke the rpm-ostree db diff command to see what has changed between the two deployments. Note two things on this:
      • That the hashes coincide with the ones you actually want to compare.
      • The command catches only changes in packages. However, a config diff applied by Bazzite’s maintainers will not be shown here.
    • Asking help from community channels. You can even start here. But basically, a project’s discord/discourse is undoubtedly better equipped in helping you out. See this entry on Bazzite’s documentation for links.

    Wish ya good luck fam 😉!