I’m sorry, but what exactly do you mean by backwards compatibility? Like if I installed the latest version of say Ubuntu, it will automatically scale back the kernel to one that fits the specs of my computer?
Post says it’s ready as a daily driver. I want to help with bug reporting, is it good enough to replace current fedora plasma or should I wait for a beta?
I’ve gone back to using packages from my repo. I was all-in with flatpaks for a while because they tend to be more up to date than my distro’s packages and I liked the idea of the sandboxing but in practice I’ve found it a nuisance getting applications to speak to each other and I don’t like all the redundant code bloating my internal drive. The thing that really did it for me though was the other day when I had to restore my system from a Timeshift backup. It took an hour and a half to restore a recent backup, with well over 90% of that time showing as flatpak stuff.
The file could be digitally signed. By editing you change the hash value that will be computed when the file is checked for integrity. Just a wild guess.
Immutability is useful from a sysadmin standpoint because it solves a couple problems. It’s a little easier to secure a system if you can know that, in fact, files outside the home directory have not been modified, and also, it’s a little easier to keep systems running because programs can’t just shit on each other’s files etc.
Unless these two are problems for you, you’re signing up to re-learn how to use Linux, and tbh not very elegantly, for basically no real gains at this time. Immutability has potential as a concept, but Red Hat’s approach is super weird and not very efficient. They have a tool that allows you to manage filesystem trees, and then they extended this tool with RPM to allow you to compose custom filesystem trees at install/upgrade time. This approach, in my experience, is shockingly inefficient if you need to add any custom packages to your base tree and you install updates with any frequency.
If you’re a sysadmin rolling out updates to workstations maybe once a month, these aren’t really issues, but for daily use, it didn’t seem worth it to me just yet, especially since we don’t really have any neat separation of code and config like you get with Docker. You can’t just zip up your home directory and move it to a new Silverblue installation and have your user back yet (there’s work in this direction with systemd-homed, likely once it’s good enough this will become standard, but also, that’s not an “immutability” feature). I believe /etc is mounted rw, which is a step in this direction, but until lots of stateful stuff gets moved out of /etc that isn’t going to be portable in the same way a Docker config is.
EDIT For a comparison of a different approach to immutability that includes a different bundle of tradeoffs, you can also look at OpenSUSE’s MicroOS. The TL;DR is that it’s easier to customize the base system, but it locks you into btrfs and it’s not as robust overall – ypsidanger.com/comparing-opensuse-microos-to-fedo…discussion.fedoraproject.org/t/…/3
I just wanted to point out that you pretty much can just tarball your user directory and drop it into a fresh system. If you embrace the Flatpak and container-based workflow, it’s incredibly easy to be up and running in no time. Obviously, containers and flatpaks aren’t unique to image-based distros, but are perhaps less common in traditional distros.
Sure, you’ll need to add a printer back, or reconnect to wifi networks, but your user and/or dev environment will carry over, and with a couple of commands, any package overlays and flatpaks will be reinstalled and ready to go.
I found flatpaks and containerization to be the only real learning curve with Silverblue, and only because I hadn’t used them previously. Compared to the learning curve and unorthodox approach of NixOS, Silverblue itself is as easy as using vanilla Fedora Workstation.
I mean, is this true in any way that hasn’t been true of Linux since nearly forever? You can always put your /home folder on a separate partition, install a new system, and as long as you make sure the UID of your new user matches the UID of the old user, the process is exactly the same. Just reinstall your apps and you’re good to go. I used to do this to keep configuration/data between reinstalls. EDIT – as opposed to a genuinely stateless user config, as systemd-homed is working towards
There difference is, to flatpaks and containers are in home, so you keep those even after a fresh install of you keep home.
It’s freaking great, specially in a work machine, to reinstall after breaking something and be able to just continue almost as if nothing had happened.
I’ve tried basically every mainstream-ish distro there is, I just want some outside opinions because I’m bad at picking stuff and I want to stick with something for a while
Hi there. I know what is a meta distro (Gentoo, bedrock, LFS), and an immutable distro (NixOS, Fedora Silverblue, MicroOS, VanillaOS) but what is a transactional distro?
For a home user with recent hardware in my opinion the system to beat is openSUSE Tumbleweed. It is a stable and rolling distribution, that is, it has the best of both worlds.
If you wanna switch to Silverblue, i would highly recommend the universal blue images, they have a whole bunch of different DE version, specialized versions for example: bazzite for gaming, and they also have framework specific images for most of them.
with ublue i dont have to layer a single package over my basic image (silverblue-nvidia).
All the apps are installed as Flatpak, except the ones that dont have one run on Distroboxes (distrobox is included in ublue images and highly recommended over the default toolbox in silverblue)
I had similar frustrations with a game. It’s very easy to make mistakes while you’re a beginner in editing such files (I don’t know if you are).
One advice is to make sure to keep the data the same length.
If that doesn’t help, observe the file’s structure a bit more. Maybe it uses a checksum somewhere for the data you want to edit, or it is just stored elsewhere and you were editing the wrong thing.
Make a save. Make the data to change (in the shortest time possible) and make a new save. Compare these for what have changed.
But also, what is your problem?
Does the value just don’t change, or the save becomes corrupted?
Do you obtain this file from the file system, or do you need to extract it from some kind of a container file, and then implant back the modified version?
SnowRunner’s asset files cannot be edited unless you unpack and repack them with winrar. Anything else (as far as I tried, windows tools at the time) and it won’t work.
If Fedora runs fine, I see no reason why openSUSE wouldn’t. Friends of mine use regular Manjaro with the same Framework. Just keep using openSUSE if that’s what you feel most comfortable with.
I used Silverblue for a bit but got very annoyed by its rpm-ostree command. I think it’s too complicated for a simple single user setup.
Why did you find the need to use the rpm-ostree command¿? Isn’t the purpose of immutability to use flatpaks and containers to get all your apps/software
Well for me it auto updates and stages in the background. There is config file /etc/rpm-ostreed.conf in which you can set the AutomaticUpdatePolicy to stage. Then it will automatically check for updates once a day(I think) and will download and stage it. The update is then applied when you shutdown or reboot
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.