We already have container images for use with bootc of many non-Fedora distros (including Debian). This is (part of) the groundwork I alluded to earlier. So it’s definitely possible. But I agree with you: it will only happen after the people in charge are interested in solving this.

And even if I’m being (very) optimistic, I can only see an officially supported bootc-variant of Debian come into fruition if it’s necessarily better than the alternative; kinda like how systemd replaced the default init on most distros. And, even then, I only expect it to live alongside traditional Debian. As I’m simply unsure whether all of its kinks will eventually be ironed out. Only time will tell…

Fedora Atomic and its derivatives (like Bazzite and its uBlue-siblings). I wouldn’t be surprised if the same applies to NixOS and other (paradigm-wise/philosophically-)related projects.

But that’s the thing, I (and together with me many others) have already been doing this for a couple of years now. Granted, this is on another distro*. But I honestly don’t know why it wouldn’t be possible on Debian; perhaps (some of) the groundwork has already been put into place 😉.

The possibility of unattended major upgrades would without a doubt be an upgrade over this mess. Even if it becomes possible, it doesn’t have to be enabled by default anyways. So, if you don’t like it, then you should be able to only make use of UnattendedUpgrades for minor upgrades; if at all*.

Besides, I don’t think the crowds that use Fedora or Ubuntu Interim are necessarily opposed to it. Especially not if it’s just seamless. Like, what would be even there to oppose if it doesn’t introduce any troubles?

?

You can easily disable or uninstall unattended upgrades, and I would definitely have noticed if Debian’s unattended upgrades automatically did major release upgrades on its own …

To be clear, the automatic major release updates in the background does not happen on Debian. I was describing the experience on my daily driver; which happens to be another distro. That’s why I wish to see the day in which Debian does receive this. I’m aware of UnattendedUpgrades doing minor upgrades only; so no major upgrades*.

IMO that’s not an issue at all, both Debian and Ubuntu are very good about providing security updates for their oldstable releases. Maybe your desktop environment or text editor isn’t going to receive updates anymore, but I have a really hard time imagining a relevant scenario where that makes a difference for security.

I absolutely love the effort put in by Debian’s Security Team. But as they only provide it for three years after release, I don’t feel confident to continue using it, even if I value the work of the group of volunteers that make Debian LTS possible. Note that “too paranoid” were keywords in my previous message.

I did maybe half of these steps and it still went without issue.

That’s cool and all. But, to give some context as to where I’m coming from: for the last 2-3 years or so, I receive automatic major release updates in the background. Sometimes, it takes me up to a week before I even notice it. I wish to see the day that Debian is released from its UnattendedUpgrades shackles and can ascend into pure bliss.

I’m a big fan of skipping over one major release when upgrading

I’m too paranoid on security to consider that 😅. But I’m glad it works out for you.

Upvoted for Topgrade. It’s honestly so good on any system that employs more than one ‘updatable microcosm’,

That’s definitely off-putting. Though, I do feel Debian can learn a thing or two for making major release updates more seamless. Perhaps it’s the doing of the law of equivalent exchange; after two^[1] years of bliss (read: easy updates), we just have to accept a brief moment of intense suffering (read: way more involved update).

I suppose COSMIC technically never migrated/transitioned from X11 to Wayland, because it’s been Wayland-only from inception.

AFAIK Cinnamon is on track to be the first smaller DE with full wayland support.

I think Budgie just beat them to it. To be clear, Budgie 10.10 is literally Wayland-only.

Are you on systemd or sysVinit? If you’re on the latter, could you tell if you’ve even noticed any difference so far? Thanks in advance!

I definitely agree with you on GNOME being rather opinionated. Perhaps more so than most other DEs.

Anyhow, thanks again for appreciating my input and compliments!

That’s pretty cool! Where did you find it?

Great write-up! Thank you for the effort!

Though, if I may: Regarding GNOME, you said:

Not particularly customisable

I would rather rephrase this to “Does not expose many knobs for customization by default.”. Because -frankly- between dconf, extensions and CSS; the possibilities are actually quite expansive. So much so, even, that a KDE dev said regarding GNOME: “sometimes it (read: GNOME) can be customized better than KDE”. (They say this literally in the first 10 seconds or so.)

Another striking example of the breadth of GNOME’s customization would be how Niri was heavily inspired by GNOME’s PaperWM extension. (Source) So, GNOME’s customizability has allowed the creation of a new workflow that eventually served as a direct inspiration for one of the most exciting WMs we’ve got.

Do you mean Desktop Environments?

EDIT: OP has changed the title of the post since. Regardless, thank you OP for the confirmation/clarification! FWIW, I really like Eylenburg’s resource on this.

I’m glad to hear that you found the most egregious culprit. Hopefully you’ll be able to get it to work after your subscription list ‘functions’ (again). (I’m honestly completely oblivious of what this software is or how it works.)

Though, if you allow me, I would like to give some comments. So, without further ado.

Throne came up with another error, it was unable to change file ownership in /usr directory

Hmm…, curious. I would think that it shouldn’t even (necessarily) require anything like that. And, if it does, perhaps the maintainer/contributor should be addressed in hopes of resolving the issue; I’m sure they can figure out a workaround (or so).

(of course it couldn’t, it’s an immutable system)

😅. This is actually a very nuanced topic:

• Bazzite has for example made plenty of changes to /usr compared to its upstream; i.e. Fedora Atomic. So, there is a supported way of doing this in order to create an image with the desired changes to /usr. If you got any such needs, consider taking a look at this page of Bazzite’s documentation.
• Furthermore, instead of making changes to the content of folders like /usr/etc, /usr/share et cetera; one could instead make changes to the content of folders like /etc ~/.local/share et cetera.
• If you only want to write to /usr once and would like for said changes to not persist after a reboot, then commands like rpm-ostree usroverlay and bootc usr-overlay are worth mentioning.

So, to be clear: while it is true that Fedora Atomic does not like/support making changes to /usr at runtime, it’s not like it’s necessarily limiting you if you really desire to make changes to /usr. Even if non of the methods 100% function like how sudo <input change> /usr/<some content> would on a traditional distro*.

Thanks a lot for so much effort figuring things out!

It has been my pleasure 😊!

Bazzite shows that terra-release is indeed installed

Assuming it is disabled (as happened in https://github.com/ublue-os/bazzite/issues/2580)

Interesting conflict; as these seem to be at odds with each other. I wonder what’s up. If it’s indeed disabled, then I would like to apologize for causing any confusion. FWIW, I may have been mislead by Terra’s own documentation. I suppose it might be outdated.

Anyhow, perhaps we can undertake the steps to uninstall terra-release (even if it’s not there) and (re)install it.

Uninstalling terra-release

If terra-release is layered^[1], then we’d have to start with rpm-ostree uninstall terra-release. Afterwards, to delete the Terra repository, even if it’s not even there^[2]: sudo rm -rf /etc/yum.repos.d/terra.repo

(Re)installing terra-release

To (re)install terra-release (as per its own instructions):

First evoke the following command:

curl -fsSL https://github.com/terrapkg/subatomic-repos/raw/main/terra.repo | pkexec tee /etc/yum.repos.d/terra.repo

And then, evoke this one: sudo rpm-ostree install terra-release . I’m unsure if sudo is required. Personally, first I’ll do is without sudo. Only after it fails due to permissions will I do it with sudo.

A reboot is probably required for it to take effect. Hence, try evoking rpm-ostree install throne only after performing a reboot.

Nekoray in particular doesn’t have .rpm

Perhaps they don’t provide any themselves. But installing it from a repository is preferred anyways. To be clear, it’s found within Terra’s repository. The very same Terra repository that’s enabled by default on Bazzite. So, as I see it, there’s nothing that would prevent rpm-ostree install nekoray from working. Have you even tried this?

I don’t know why V2RayN doesn’t work though. Try Nekoray and let us know how it goes.

EDIT: I just noticed how Nekoray has seemingly lost its maintainer. Thankfully, someone forked it and renamed it to Throne. And, with it, we find ourselves an RPM repository to install from. Thankfully, you don’t even have to go through any hoops, as it’s also found in the Terra repository. So you’re simply one rpm-ostree install throne removed from installing it.

What have you tried? Why doesn’t rpm-ostree install nekoray work for you?