The more packages you install rpm-ostree, the likelier your system will break. You effectively turn back to a traditional distro that relies on a package manager, so all the things that can go wrong with a package manager are bound to go wrong. The whole point of fedora atomic is to offload the OS composition (so all the complicated packages stuff) higher up the chain. So that not everyone mixes up their own combination of packages installed, but instead you get a (semi-) fixed combination of packages that has been tested to work already before it lands on your computer.

The uBlue images are just different package combinations - but still you're not the only one rocking the packages combination of bazzite for example, so it is rather unlikely you'll run into a problem that only you and nobody else has.

This to me is also what sets fedora atomic apart from Suse MicroOS for example. With MicroOS you still have a package manager messing about with the system, and once it makes a mistake that gets buried in your system forever, except if you notice, roll back and fix it. As where with fedora atomic the mechanism how your system layout comes to your computer is similar to how git works (ostree) or images (like docker, which is what ublue ships). So if there's a mistake in how your system is layed out, the next time you rebase/update you are guaranteed to end up with a the intended system layout.

One possibility would be Huginn I guess https://github.com/huginn/huginn

You have this view because your hardware is from an era where fingerprint reader largely weren't a thing and webcams were connected via internal usb. The issue is not that the Linux kernel drops anything (between you and op, you're the one with the old hardware). The issue is, that fingerprint readers became a commodity without ever gaining universal driver support, and shengians like Intel pushing its stupid IPU6 webcam stuff without paving the way upstream beforehand

Why do you prefer it over syncthing?

I don't have one, I can only tell you that you can change the keyboard layout. The Readme of the firmware sourcecode says:

To change the keyboard layout, adjust the matrix arrays in keyboard.c.

https://source.mnt.re/reform/reform/-/tree/master/reform2-keyboard-fw

You might find more information in the mnt forum, it is here: https://community.mnt.re/

This covers just the basic cpu instructions, no proprietary extensions, no architecture of additional necessities like a gpu, no proprietary firmare for the gpu or anything else. The instruction set of Arm, x86 or whatever is not a secret though. The freedoms in risc-v are mostly concerning the manufacturers, which can build chips using this instruction set without paying any royalties. From a consumer point of view, that at most means one can at most choose from a more organically grown landscape of risc-v chips. Which in turn bears the risk of ending up in a situation, where all we have is a vast jingle of cluttered proprietary extensions, that make it harder to write libre drivers for than it is for Arm today.

Don't get me wrong, risc-v is absolutely amazing! But in terms of freedomness, it would take a manufacturer to extend the spirit of open hardware to the complete SOC - and the basic instruction set is pretty much the smallest piece in that.

La Pavoni Handhebel-Siebträger von 1996 ist täglich im Gebrauch ☕

You can install silverblue, and then rebase to ublue ( https://universal-blue.org/ ). Specifically to the "silverblue-nvidia" variant, and you should get a nice silverblue experience without any of the nvidia struggles, as people at the ublue project take care of that stuff for you.

And yes, distrobox is the goto solution to run stuff that is basically ubuntu-only, or by extension bound to any distro variant / version and not flatpak. This includes graphical applications. Distrobox works great, I do all my work in it.

How do you handle residual filament on the nozzle from previous prints? Or if you heat it up to get to nozzle itself to touch the bed, do you get dabs of plastic distributed around your bed?

Do you do some sort of versioning/snapshotting of your services? I'm on the compose route as well, and have one btrfs subvolume per service that holds the compose.yml and all bind-mounted folders for perstistent data. That again gets regularly snapshotted by snapper.

What leaves me a bit astounded is, that nobody seems to version the containers they are running. But without that, rolling back if something breaks might become a game of guessing the correct container version. I started building a tool that snapshots a service, then rewrites the image: in compose.yml to reflect what ever the current :latest tag resolves to. Surprisingly, there doesn't seem to be an off-the-shelf solution for that...

In my experience, not pushing it makes them want to try it themselves at some point. I guess you need to take care of their computer frequently enough, and are probably annoyed by Windows shitting its pants every time again. Don't make any drama out of it, just point out how ridiculous it is that Microsoft cannot manage to build something that allows running two simple programs without breaking or nagging the user so often. They know that you use something else with which you're happy with, and at some point they will become curious and ask wheter they can have it too. At that point do not promise much, say that it works a lot better but is also a lot different and sometimes a bit quirky. Do not rush it now, let them simmer in their curiousity. At a fitting occasion tell them very briefly about foss and how it is not a closed thing pushed by a corporation onto individuals to funnel data. When they ask if they can try it, tell them they can but it takes a bit of getting used to. Buy a new SSD, and safely store the previous storage in a anti static bag, exclaiming that everything is on there and cannot get lost due to linux. Set everything up with a dead easy DE, give clear tour of how stuff works. With this tactic, they want to get it to work by themselves, and are prepared to learn that some things work differently. It becomes an adventure that is totally revertable if it doesn't work out. In contrast to when you want to force the change and they use everything as a reason to be unhappy about it.

Even if they were invisible: why would anybody want to date someone that is literally incapable of even just talking to them?