Much like Fedora Silverblue, Fedora Kinoite, and Fedora Sericea there's going to be a new immutable version of Fedora coming called Fedora Onyx.
These immutable versions of Fedora Linux work like SteamOS on Steam Deck, with the main system being the same across every installation, and it doesn't change. Upgrades are done over the whole thing, it's supposed to be faster and more stable and it's an increasingly popular way to use Linux.
Fedora Onyx comes with the Budgie desktop, and the proposal from developer Joshua Strobl has now been approved, and so with Fedora 39 we should hopefully see its first release.
More about it:
Fedora Onyx is an immutable desktop operating system, featuring the Budgie Desktop environment. Fedora Onyx leverages the same foundational technologies as other Fedora immutable variants such as Fedora Silverblue, Fedora Kinoite, and Fedora Sericea (flatpak, rpm-ostree, podman, toolbx). Fedora Onyx is built for people that are attracted to / find value in the Fedora computing platform and Budgie Desktop environment, but need the robust immutability and atomic capabilities that rpm-ostree provides, which are not be offered through traditional Fedora spins (e.g. Fedora Budgie Spin).
Quoting: fenglengshunThanks for that explanation! I'm somewhat familiar with Ansible, so that shouldn't be a problem.Quoting: pleasereadthemanualIs this different from including Firefox as an overlay?Alright, long post incoming as I try to explain everything:
You can use overlay, but when I tried to do `rpm-ostree install --dry-run` in my Kinoite image to test things, whenever there's an already installed package, it will exit saying the package is already installed, instead of continuing with installing the other packages I listed in the comment.
By contrast, the ublue builder seems to take care of duplicates easily, unless you have a version conflict due to trying to install something using COPR (tried to install steam but I think the Nobara COPR and packages I enabled caused a conflict of mesa version). Also, they automatically build things in a single layer, I think, which prevents the issue of having too many overlays due to not doing a single `rpm-ostree install`.
In addition, when I asked around, having overlays may make it hard if you want to switch base to a different system image (say, Silverblue to Kinoite, or Kinoite to Onyx, or Kinoite to Kinoite-Nvidia).
If your worry are Firefox and codecs, I believe that uBlue base images currently have firefox and the freeworld codecs installed. I think they only added the firefox and firefox-langpacks on remove list of recipe.yml as an example of how to remove package from the image and probably under the assumption people be installing Firefox through Flatpak via the yafti flatpak installer. But if anyone worries about upstream removing firefox eventually, they can just add it to the install list to make sure it remains installed.
This is the list of the packages they overlay by default on their images which you can use as your base image, this is the template recipe.yml which is applied based on the base image you chose, and this is my recipe.yml and yafti.yml for an example of how I'm doing things (sorry about the mess though, still experimenting here -- check Actions if you want to see how messy installing Teamviewer is).
I still don't know everything yet, I've only been using it for a week, but it was easy enough to understand due to the playbook-like format. Getting started was surprisingly easy, with the automated setup.
I think it'll be some time until I install Sericea on that system to test it out, but I'll keep this in mind for that occasion.
For anyone interested, I found this to be a very informative guide for Fedora's immutable operating systems: https://www.dvlv.co.uk/pages/a-beginners-guide-to-fedora-silverblue.html
Quoting: SamsaiIt all comes back to non-free codecs, which Fedora won't ship because of patents and license fees.
Eventually the codec problem will solve itself as platforms abandon H.264/H.265 and move to AV1.
I honestly believe H.264 patents will expire (2028) before platforms abandon H.264. I suppose Windows 11 is helping in that department by obsoleting fairly recent hardware and Windows 10 being 2 years from EOL, forcing people to buy newer hardware that likely has AV1 support, but I think platforms will be hanging onto H.264 for a long time. It's the most widely-used video codec in the world, after all. mp3 still won't die and it's 32 years old! Even though Opus does its job better in every way, because companies like Apple still don't support it.
One would hope Apple being a part of AOM would mean they adopt AV1 more quickly, but time will tell. Another point is iPhones are supported for an average of 6 years, and iOS 16 has no support for decoding AV1 (let alone hardware)...and that's a large portion of web traffic these days. I don't think AV1 adoption will beat H.264 patent expiry. Amazingly, Safari still doesn't support AV1, though Chrome and Firefox have supported it since 2018. So macOS is failing in the AV1 decoding department, too.
H.265 was not supported in major web browsers until about half a year ago (why now?), and adoption of this codec otherwise was low anyway, so I would declare it deceased. Windows 10 doesn't support it in its default video player, after all, asking users to purchase the codec. If that's not a stamp of irrelevance, I don't know what is. I seriously doubt H.266 will get anywhere on most platforms, either. The patent pool situation is the same. Well...I certainly hope it won't get anywhere.
Oh, and do you know anything about AAC? I can't find much information on the patents for this codec or the expiry dates, but I would like to know. I really, really hope AV1 gets wide adoption soon so I don't have to care about either of these codecs ever again, but it looks like Apple will be holding us back for a few years yet. DaVinci Resolve already supports AV1 encode/decode with NVIDIA on CentOS.
Quoting: 14My impression so far is that Flatpak for everything adds annoyance to the user experience. It seems there are assumptions made of which people new to dealing with Flatpaks are ignorantI feel the opposite -- I think that currently Flatpak kinda assumes the user either shouldn't care with the defaults (which, in some cases, often errs on being more restrictive than necessary) or they know enough to find out how to fine-tune them (Flatseal and even KDE's built-in permission management isn't even descriptive enough IMHO).
That said, I do find it to be a decent solution in order to not care about dependency anymore. I was trying to work out how to use Nobara's COPR to get a few stuff including Steam and it is actually a mountain of dependency hell. Nix, Conty, and Flatpak each have their own issues, but I honestly would rather not have to deal with managing whatever specific thing the distro needs and have something that works in any distribution.
Also, using uBlue's Kinoite base, I do find update to be more convenient. Every day, GitHub Actions will compile a new image, and uBlue's Kinoite comes with auto-update turned on AFAICT, so everything is just applied in the background and if there's an issue, I'd either get an email about how the GH Actions failed and/or I'd just be booted to the last working image.
And personally, I think the average home user is alright with any device that has a browser to connect to the internet, can open documents, and can run games. And for the most part, you can already do that with Flatpak.
See more from me