Hi. I'm not related to either of the two fighters. I do, however, admire your curiosity. Still, I feel a particular sentence made in this comment of yours has to be nuanced. If this endeavor of mine is not appreciated, then please feel free to notify me however you please.

So, without further a due.

If I were to go immutable there are some limits on what I can do

Strictly speaking, yes.

However, we can categorize these as follows:

• Absolutely impossible to accomplish on some 'immutable' distros
• Currently impossible to accomplish on some 'immutable' distros. However, it will be fixed eventually.
• Currently impossible to accomplish through conventional methods on some 'immutable' distros. However, some experimental features do allow these to be accomplished. But, you might have to learn how.

Furthermore, depending on your needs, you may not even have to deal with anything that's either not or less supported.

Finally, as the use of "some 'immutable' distros" suggests, not all immutable distros are created equally. Therefore, it's actually uninformed to lump all of them in the same category. True; they're referred to as 'immutable'. However, descriptions like atomic, reproducible and declarative are perhaps more useful when comparing one 'immutable' distro to the other.

I'm personally a big fan of 'immutable' distros. However, please don't feel compelled to delve into it as long as you're satisfied with your system.

My two cents. Enjoy!

Thank you for the answer and for your time! I wish you a nice day!

You seem to be ignorant; the use of this word is not meant derogatory. In all fairness, it's perfectly fine; we all gotta start out somewhere. So, please allow me to elaborate.

Being the first distro on which new technologies are introduced

Consider checking up on where Wayland, systemd, PipeWire, PulseAudio etc first appeared; so on which particular distro.

Also atomic branch?

Fedora Atomic, i.e. the first attempt to Nix'ify an established distro. Most commonly known through Fedora Silverblue or Fedora Kinoite. Peeps formerly referred to these as immutable. However, atomic (i.e. updates either happen or don't; so no in-between state even with power outage) is more descriptive. It's also the most mature attempt. Derivatives like Bazzite are the product of this endeavour. From the OG distros, only openSUSE (with its Aeon) has released an attempt. However, it seems to be less ambitious in scope and vision. I wish it the best, but I find it hard to justify it over Fedora Atomic.

SELinux might be a fair point, but I doubt that ss unique to Fedora tbh.

OOTB, apart from Fedora (Atomic), it's only found on (some) Fedora derivatives and openSUSE Aeon (which forces you to use GNOME and Aeon's specific container-focused workflow). Arch, Gentoo and openSUSE (perhaps even Debian) do 'support' SELinux, but it can be a real hassle do deal with. And it's not OOTB.

If you make claims, you better substantiate it. I just did your homework 😂. Regardless, I'm still interested to hear a distro with more impressive USPs. Let me know 😉.

What’s your end goal here?

Incoming XY problem.

I want to prevent myself from reinstalling my system. The trick I came up with involved the use of files that couldn’t be disk cloned. However, if it’s far far easier to accomplish it through other means, then please feel free to enlighten me on this.

You try to keep files just on that one media without any options to make copies of them?

Yes.

Or maintain an image which has enforced files at their directories?

No, not necessarily.

And against what kind of scenarios?

Protecting myself from myself. That's where the password requirement comes in: I can send a delayed message to myself that holds the password. The end result shouldn't in the absolute sense prevent full access for always. Unlocking the protection should be possible and should require the involvement of the earlier mentioned password that is received through a delayed message. That way, those files can be accessed eventually, but only after I had intended to.

ACLs and SELinux aren’t useful as they can be simply bypassed by using another installation and overriding those as root

Excellent! I didn't know this. Thank you for clarifying this for me!

Only thing I can think of, up to a degree, is to use immutable media, like CD-R, where it’s physically impossible to move files once they’re in place and even that doesn’t prevent copying anything.

The files should remain on the same disk that I run my OS from. So, unfortunately, this doesn't quite help me. Thank you regardless!

Seems interesting. Got any sources to read up on? Thanks in advance!

I'm not the one you asked your question, but I think I understood what they meant.

First of all, technically MicroOS is the non-desktop version of openSUSE's take on an atomic/immutable distro. The desktop variants are referred to as Aeon (for GNOME) and Kalpa (for KDE).

Secondly, while Aeon/Kalpa definitely is to openSUSE what Silverblue/Kinoite is to Fedora, there's a clear difference in vision and maturity.

Vision

Fedora Atomic is a very ambitious project; everything points toward it being Fedora's take on NixOS. But, unlike NixOS, it couldn't start from scratch nor did they intend to. Instead, it's the process of evolving their existing products into something special. As such, it has been over two years since Fedora has even explicitly stated that they intend for Fedora Atomic to become the default eventually (without saying anything about sunsetting the old). While, AFAIK, openSUSE has yet to make similar statements regarding Aeon/Kalpa.

Maturity

Everything points towards Fedora Atomic being more mature than openSUSE MicroOS; work on the project has started earlier, Fedora Atomic is almost done with their transition (from image-based) to OCI while I don't recall openSUSE mention anything regarding their transition (from 'snapshots') to image-based since they mentioned it briefly last year. Furthermore, Bazzite (based on Fedora Atomic) has become the face of Gaming Linux while openSUSE' MicroOS fails to deliver on anything but Aeon. Which, to be fair, is absolutely fine. But not everyone is fan of GNOME.

So, use Tumbleweed if:

• You prefer the traditional model
• You like YaST
• You like the rolling release model and not being tied to GNOME

Use Aeon if:

• You like GNOME and an atomic distro on a rolling release distro
• You prefer the opinionated, hands off, little to no customization path that openSUSE has currently chosen for its Aeon
• You like a containerized future

Use Fedora Atomic if:

• You want an atomic distro, but don't like any of the decisions made for Aeon; i.e.
  • prefer to use KDE, Budgie or Sway (or any other desktop environment through uBlue)
  • aren't that big of a fan of container workloads
  • prefer having the choice of installing native packages
• Prefer atomic on top of a point release distro

Finally, regarding containers specifically; let's say you want to install package X.

• On Tumbleweed, you just do sudo zypper install X and you're done with it.
• On Aeon, if it's available as a Flatpak, you do flatpak install X. If there's no Flatpak of it, you install it within a container that you access through Distrobox. Within the container, use the package manager corresponding to the container. Technically, while inside the container, the environment is very similar to Tumbleweed. So, say you got a Tumbleweed container, then you can continue using sudo zypper install X.
• On Fedora Atomic, you can layer onto the system through rpm-ostree install X; this is very close to how installing packages work on Tumbleweed. And, you can continue using both Flatpak and Distrobox; like how it's done on Aeon. Note that Tumbleweed also allows access to Flatpak and Distrobox. So, Aeon is most restricted as it can't install packages onto the base system. Btw, Fedora Atomic accomplishes this through layers that can also be peeled off later on (through uninstalling for example). With this, the base system actually isn't affected, but the end user doesn't notice it.

Solutions found on either of these wikis may work perfectly fine on other distros, but it's not a guarantee. 'Seasoned' users should be able to distinguish this.

Thank you for the response!

Current mode: enforcing

This is pretty interesting. If I recall correctly, installing Nix onto Silverblue came with the caveat that SELinux' enforcing mode had to be turned off. But, your terminal output tells another story. I wonder what's up.

FWIW, I had lost interest in installing Nix on Fedora Silverblue for this very reason. However, I might have to revisit my stance on this. Once again, thank you (for reinvigorating my interest in Nix)!

Do you mean SecBSD?

But BSDs and Linux are very similar in design philosophy and are dependent on each other.

Interesting. Would you mind elaborating on the bold parts? Thank you in advance :D !

Thanks!

It has been my pleasure 😊.

Is there anything to be expected when updating the system to a new version?

The write-up found above ensures that the two systems don't share any space within the same drive. Therefore, there's nothing to worry about.

For example, I've upgraded Fedora from 39 to 40 about two months ago without any troubles. Heck, I'm on Bluefin's :latest. So, the update to 40 happened automatically in the background without notifying me. So, with the very next reboot I suddenly found myself on 40 😅. I probably wouldn't even have noticed any difference were it not that some GNOME extensions didn't work right away. Otherwise, it was a perfectly smooth update.

model is a MacBook Pro, Intel Core i5-4278U @ 2.60GHz, model A1502 (EMC 2875), Retina Mid-2014 13" with an embedded SSD

Unfortunately, I don't have any first-hand experience with this device. But, I do own the following potato; an Acer laptop with Intel Celeron, 2GB of RAM and no SSD from 2014-2016. And while the experience is pretty bad (on Zorin OS lite), it does its job as a backup laptop every once in a while. Compared to this potato, your device should be a lot more capable. So, either your expectations are off. Or, there's something legitimately wrong with the hardware found on the device. Have you done any benchmarks to see if they work as expected?

Some mac OS users mean this company deliberately slows down old computers so users feel compelled to buy something newer. Can it be that’s why this notebook is so slow?

Slowing down of devices is AFAIK done (un)intentionally through updates. In a lot of cases either some functionality is removed post release for security reasons or (through technological advancements) more is expected from your average device and hence older devices fail to compete. I don't think you should suspect anything else. Nonetheless, as previously alluded to, maybe some hardware failure is the cause.

I didn’t do anything fancy to install xubuntu, just used the whole space to install from a usb stick so I wonder if some residual software is still present.

This description of the installation seems fine. If it makes you feel better, you could consider deleting all partitions through something like GParted. But, usually, no residual software should be left behind.