That power efficiency is a direct result of the instructions. Namely smaller chips due to the reduced instructions set, in contrast to x86's (legacy bearing) complex instruction set.

I think I read somewhere that it just sends shift+super. So you may be able to bind it to whatever. At the same time its a dumb decision because now there's wasted space for a key combo you can easily press on a normal keyboard too

With something like this, how do you handle the period of time while copying? I mean you can't really leave it running as it wouldn't be in a consistent state. A "under maintenance" page instead? Copy to a fresh folder and when done tell the webserver to serve the new location?

"almost all of the most technical employees in framework are using either ubuntu, fedora or nixos. I'm mostly on Windows because we need actually people that are using Windows because our employee base in framework is all Linux users"

• Nirav Patel

https://m.youtube.com/watch?v=EIEc43CxIvY

That is not the case for every country though. In France and Germany for example almost 3/4 of google requests are via IPv6.

If you have a working config, thats exactly the point. Before you built your config, you don't know. If you deploy silverblue, you know it will work beforehand because exactly this config, including /etc, has been tested upstream before. What you are to your buddy, Fedora Atomic is to me. The difference is, it is not just one person that tested some config they decided on on their single piece of hardware, it is the effort of a full blown distro team.

No, just because it is reproducible doesn't mean you are able to (re)produce something that works. With something like fedora silverblue you know that this specific composition of packages and their versions has been tested, and that all the other users run this exact composition as well.

When you roll your own composition, where you install whatever stuff, you may be the one finding out that there's some conflict between package a version u.v.w and package b version x.y.z.

I encourage you to go to town with whatever crazy setup you come up.

I just want to note that the reboot-to-update mechanism also has its positive sides, as ancient as it may seem (we do not succumb to windows level backwardness, because that fails to reap the benefits despite requiring so many reboots). Namely, you get atomic updates, hence the name "fedora atomic" for example. That means you have no transient periods where your OS is running in an inconsistent state. Like when you update a traditional distro, the new files/libraries/binaries/kernel-modules do not match anymore what is in RAM, including the currently running kernel. That leads to stuff like the nvidia driver / cuda not working until reboot, running applications failing to load a library they need now etc.. The vast majority of times this is no huge problem, but in theory the only way of maintaining a system with it never running in basically undefined state is with atomic udpates.

And the firmware inside that rp2040 is stored on plain old flash memory. So while the data may still be on the memory chip, the controller chip dies at just the same pace than every other usb drive - and then you can't access it.

My Linux journey started when Ubuntu was in its single digit versions. I don't remember the exact version I used first, but it was >15 years ago.

Of course I had a long distro hopping phase, that got finally ended by Arch. Because Arch breaks less, at least if you don't molest it. Upgrades of versioned distros always had hickups or problems, and I grew tired of having to do a larger troubleshoot session once or twice a year. Arch has only very minor hiccups once in a while, and they're typically always the same. 99% when the update doesn't run through the keyring changed and you have to update it first, .9% is a bug with like a new release of the DE or something that gets fixed upstream in a couple days. And .1% is you have to look at the news because some manual intervention is required, like removing a package and going for something else or whatever. That is when you keep your system free of cruft and go with a popular DE.

Just 1.5 years ago I finally left Arch after a loong time. For something that is very new and different: fedora atomic (silverblue). Technology wise it is superior in my mind, and in my last years of using Arch I had most things in Flatpaks and containers anyways. But if you want a classical distro, Arch is definitely amongst the very well working ones.

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.

Hab ich mir auch mal gedacht, und habs bereut.

Ich vermute bei einer solchen Frage lebst du in einer Stadt, und nicht iwo auf dem Land mit Haus und Hof. Suche mal nach Rad-Waschboxen/-Waschanlagen in deiner Umgebung, so Zeug gibt's. Es gibt sogar Tankstellen die in den Waschboxen für Autos ausklappbare Fahrradständer haben. Und zur Not würd ich es einfach in ner Auto-Waschbox auf den Boden legen und fertig.