Thank you OP for that, but... why should we prefer this over uBlue's work on streamlining this process?

Why ublue over fedora’s images?

Personally, I've been enjoying uBlue over vanilla Fedora Atomic for what they offer in terms of system management.

To give you a better idea on what I mean; just a month ago an update to Podman caused breakage and people weren't able to use their containers created with Distrobox/Toolbx^[1]^. Sure; a rollback is accomplished relatively easy and I'm sure some would even be able to fix it themselves. Regardless, every Fedora Atomic user that relied on Podman would have been interrupted to some capacity.

Which, of course, begs the following questions... Isn't it very inefficient for everyone to fix this issue themselves? Wouldn't it be easier if somehow Fedora forced some fix upon all of us so that just one entity is burdened instead of all of us? Heck, wouldn't it be better if Fedora just withhold the update until it's fixed? Is this perhaps some pipe dream that will never see the light of day? etc...

The interesting part, though, would be how I (a 'uBlue-user') didn't even notice Podman was causing issues in the first place. "How?" you might ask, well... The uBlue devs noticed the issue, applied some magic so that I and many other uBlue users like me just went on with their day like they would otherwise; without being interrupted because Podman just had a bad update. (Did the supposed pipe dream actually already exist in some form or fashion?)

This is just the most recent example of this. But in the last year or so, out of the top of my head, there have been a few more times in which uBlue users didn't even notice a thing while the others either had to rollback or fix their issues themselves. If you enjoy this interruption and/or are willing to deal with it for the sake of whatever, then please feel to continue to do so. However, I prefer to have a system I can rely on at all times and uBlue offers me just that while remaining very close to vanilla Fedora Atomic.

You won’t have fedoras signatures anymore.

It depends if you have the luxury to rely on them in the first place.

If setting up your workflow (or whatever) requires you to get to the nitty gritty of things and change those parts of the system that strictly speaking isn't well supported by just rpm-ostree, then -for almost a year now- your best bet would have been to (instead) experiment with (what's been referred in Fedora's Wiki as) Ostree Native Containers.

And the truth is, unless you really know what you're doing, that uBlue offers the best platform to engage with this system. Heck, within a week after Kinoite's very own maintainer blogged about how to sign container images via Github actions, one of uBlue's maintainers tried to implement this for uBlue to improve their own platform and succeeded.

Finally, let's not forget that uBlue is even endorsed by Fedora (or at least by whoever maintains its documentation). Heck, even the inception of uBlue was due to an interaction between Jorge Castro (one of uBlue's maintainers) and Colin Walters (one of the masterminds behind the whole rpm-ostree-ecosystem).

P.S. If I hadn't made it clear, it's totally fine to continue to rely on Fedora Atomic directly without any interventions from third parties for system management or whatsoever. I just wanted to elaborate why I, personally, prefer to use images provided by uBlue.

1. Source to a thread in which this is discussed.

Hmm, one I guess is that it is not “permanent” and deactivates after one command (in Kakoune, you have to explicitly do ‘;’ to collapse the selection to its end (which you can flip with the start using ‘alt+;’) or move around without extending the selection). That’s really the only thing I can think of at the moment and I feel like often it really doesn’t matter tbh, so maybe I was just talking out of my ass there a bit lmao.

Regardless; thank you for mentioning this!

Apparently you can quickly reselect it in vim with ‘gv’ though, which I never checked until now. That’s useful to know.

Hehe, thanks for sharing that; might become useful soon 😅.

One thing I’m really missing from vim though is that it can list directories, has a hex editor, and can read a bunch of other file formats. I think it can even edit remote files over sftp, but maybe I’m confusing that with Emacs. Kakoune just does local text files (though you can of course do stuff like ‘%|xxd’ to pipe the file through xxd to get a hex view, edit and then ‘%|xxd -r’ and save but that feels very very sketchy).

Until yesterday I knew almost nothing about Kakoune. But I've since tried to do some reading; while there's still a lot to uncover and/or explore, I feel as if it tries to offer a more focused experience (for better or worse).

I'm not surprised to hear that you preferred Fedora Silverblue over openSUSE MicroOS. Don't get me wrong, I think that openSUSE Aeon/Kalpa (current names for openSUSE MicroOS Desktop) have a lot of potential. However, as it stands, Fedora's Atomic Desktops are just more mature.

Btw, you make excellent points! Thank you for that. Much appreciated!

I’ve found that it is FOSS vs proprietary that causes beloved tech to die

There's definitely truth in that.

VSCode is, by a wide margin, now the most popular IDE. If MS abandons it, there’s a fleet of us ready to continue using VSCodium.

I can definitely see that happen.

Edit: The usual issue with plugins on VSCodium, out of the box, is that it defaults to a completely different plugin set, due to MS license rules about their plugin repository. It’s trivial to switch it back with a config file edit, which is, admittedly, a little buried, in the project FAQ. The VSCodium plugin repository is growing better over time, but there’s not good awareness of it yet by most plugin developers.

Wow! Thank you so much! At the time I just needed something that works, so the path of least resistance (read: go back to VS Code) was preferred. So, I probably didn't even bother finding a way to resolve the issue at the time. But this paragraph has provided a great amount of pointers that will surely help solving it.

Perhaps I should include VSCodium as another viable alternative 😜. So that it becomes -at the very least- the path of least resistance to Emacs and/or (Neo)Vim.

That's good to know! And I'm sure it's beneficial information for those that were unaware of that. However, (unless I'm wrong) the method you described requires you to be deliberate and precise in the placement of your own bang; i.e. bag of d holding or bag of holding d wouldn't work. As I often just start typing whatever I want to search/look for and only notice midway/afterwards that I hadn't specified where I would like to search, the built-in 'bangs' in Firefox/Chrome just wouldn't cut it unless I would try to rewire my behavior.

Perhaps consider watching this excellent video guide on dualbooting and multibooting by DorianDotSlash. It was what I used as a reference the first few times I engaged in dualbooting and/or multibooting.

That's unfortunate indeed. Currently I gravitate towards installing something like Endless OS for either elderly people or children. Automatic atomic updates from the get go on an immutable distro based on Debian Stable; just good stuff. FWIW, it allows updates between major versions as well 😉.

That is most likely an Arch-thing rather than a Manjaro-thing.

It has been my pleasure! I'm curious on what you'll end up doing. So please consider to report back if it isn't too much to ask :blush: !

Good questions!

I assume getting a persistent environment in a USB recovery stick is a bigger task?

I actually don't know if penguins-eggs allows persistent environments 🤔 . Though, other tools might be better fit for the job. Personally I'd recommend you to follow this guide for openSUSE Leap. A similarly good guide/documentation for Debian is absent, and openSUSE Leap is likewise a good fit due to it being supported over a longer time period as well. The steps outlined in the guide might be a bit more involved, but the team behind openSUSE have done a wonderful job to ensure accessibility.

I’m imagining that, with your method, I would need to repeat this process any time I wanted to update the image or load specific new kernel modules/drivers?

With the method outlined in my previous comment, you only have to repeat the process from scratch if you didn't save the Debian install some way or another. If you did keep the Debian install around, then you could just; open it up, apply some updates/changes or (un)install additional packages and make yet another live image out of it. Granted, the openSUSE Leap persistent Live USB that has been previously mentioned in this comment is easier to change later down the line regardless.

Btw, -to my knowledge- the persistent Live USB environment is also possible on other distros like Debian, Fedora, Ubuntu etc. So arguably it's best to first look at which distro satisfies your needs in regards to package availability. After which, in my opinion, LTS/Stable releases ought to be preferred over the others.

Thanks for the detailed reply!

Thank you for being appreciative!

Though, I couldn't help but wonder the motivation behind your inquiry. Are you just exploring the waters beyond Ubuntu? Are you interested in rolling release and got curious when you learned what openSUSE Tumbleweed had to offer in that space? Were you perhaps looking for a distro well-suited for gaming and did you perhaps come across someone mentioning openSUSE Tumbleweed which subsequently peaked your interest? Are you perhaps unhappy for some reason with Ubuntu and looking for something to replace it with?

Lots of questions, of which I don't expect you to answer more than a couple (if at all). I would already be more than happy if you could provide us a bit more insight regarding the motivation behind your inquiry.