Thanks! I wonder who will reach the finish line first between Cinnamon and Xfce.

Does anyone happen to know the state of Wayland on Linux Mint?

I was actually seriously considering to just write “Freedom” and call it a day. Apologies for making it more wordy than it has to be.

They do not have centralized configuration as far as I am aware so they do not go as far as Nix.

Which is why it’s (only) their ambition 😜. But thanks for prompting me to clarify!

Furthermore, their wording would suggest that configuration is not part of what’s declared. Which -at best- would make it relatively light on how declarative it is.

Domain-Specific Language. In the context of NixOS, that would be the Nix language.

Let’s hope places like Lemmy stay relevant, vivid and slop-proof.

Freedom, it’s that simple. Any other reason is a derivative of said freedom.

The article unfortunately does a horrendous job at highlighting AerynOS’ unique features by only giving vague descriptions without going into any technicality that matters.

FWIW, my two cents on AerynOS:

• It offers (yet) a(nother) novel approach to atomic distros. The gist for its ambition (or, at least, my understanding of it) would be NixOS, but with FHS intact and without a DSL.

The article unfortunately does a horrendous job at highlighting AerynOS’ unique features by only giving vague descriptions without going into any technicality that matters.

FWIW, my two cents on AerynOS:

• It offers (yet) a(nother) novel approach to atomic distros. The gist for its ambition (or, at least, my understanding of it) would be NixOS, but with FHS intact and without a DSL.

Not the one you asked, but here’s my two cents.

Arch, by virtue of its DIY nature, has little to no defaults. As such, common security measures are not pre-configured either. Thankfully, it makes up for that with its excellent wiki entry on security. Unfortunately, I don’t think most users ever seriously implement what’s found within.

As for Debian, it actually does come with plenty of relatively sane defaults, including security. And Debian has shown to take security rather seriously. However, (most) Debian repositories are not great at providing up-to-date versions of the software they package:

• The stable branch has outdated packages for the sake of providing a ‘boring’ (but reliable) experience. While security updates are backported, it is not the preferred way of keeping software safe and secure.
• The testing branch is in a disturbing condition in which it holds software that is a bit more stable than the unstable branch. However, it does not enjoy the security updates backported to the stable branch. Nor does it immediately receive the security updates as they come to the unstable branch. A rather unsettling middle ground, if you will. Definitely not recommended for the security-conscious.
• Finally, the unstable branch. Intuitively, this should provide the fix for the above problems. It should provide current software, which should mean that it receives updates as they’re released, security included. But, anecdotally, the likes of Arch, Fedora and openSUSE seem to be doing a better job at offering a (semi-)rolling release distro. But, please be my guest, and prove them wrong.

There are already many good answers in the comments, so I don’t feel the need to add much to it. But perhaps the following is worth mentioning:

• Fedora has got enough agency to continue efforts in what has been abandoned by Red Hat. Or, vice versa.
  • For example: it has continued to offer Btrfs as the default file system, while Red Hat has long since deprecated it.
  • Or, conversely, Red Hat has big plans for bootc. And while Fedora has done a decent job with Fedora Atomic, it certainly does not enjoy the resources and commitment it deserves; a pretty bad regression for (at least one of) the Fedora Atomic images was not considered a blocker for one of the more recent major release updates. Heck, it has become so bad that even the likes of both CentOS Stream and GNOME OS have shown to be more receptive when it comes to addressing problems and whatnot.
• It has been pointed out that Fedora would probably not survive in the event that Red Hat would cease ‘its support’.

Glad to help out 😊!

Thankfully the model forces upon the system to keep a pristine copy around. Which enabled us to fix this rather easy :P .

Did you try rpm-ostree reset ?

EDIT: The solution provided above ‘could’ perhaps work, but perhaps it’s way too radical of a solution 😅 …, so I understand if you don’t wanna go down that route. Instead, consider

sudo cp -a /usr/etc/containers/policy.json /etc/containers

as per this comment on github.