It's more like the whole upgrade is either successful, or it is not, and you are not left in an indeterminate state.
E.g. A depends on B. In a large update, B updates, something unrelated fails to install and the update fails, and now A doesn't run because it wasn't upgraded and the still installed old version of A depends on the no longer available previous version of B.
In NixOS, you either enter the new environment with all packages updated, or you don't. In the situation where you discover run-time - not install-time - errors, you can simply roll back to the previous set of packages. If the new packages cause a system crash, you can enter previous states from the bootloader.
Now none of this magically solves the software defects themselves. But it gives you a consistent system state that can be transactionally upgraded, or reentered at any time. And then you can raise the appropriate bug tickets.
Your system configuration is in a single file and the need to reconfigure different services in a particular order is gone.
Also your dependencies are all nicely pinned with Flakes. This makes importing arbitrary dependencies - open-source or proprietary - a breeze. This has removed any previous appetite we had for a monorepo, which was primarily to ease access to our other libraries.
It's all very nice, once you are over the not insubstantial learning curve that is.
Interesting, but I initially expected this to be about the unusual opening employed to victory by Magnus Carlson against Kacper Piorun on May 7, 2024[1] (1. a4 e5 2. Ra3).
It's even more interesting because an unknown IRL Chess.com player named Viih_Sou (since revealed to be Brandon Jacobson[2][3]) used this opening to defeat Daniel Naroditsky on May 2, 2024[4] only to be subsequently banned for violating the Fair Play Policy[5].
Slightly off-topic: how practical is it really to build devices (iOS and Android) and web from the same code base?
My poor understanding is that React Native, and hence Expo, doesn't use the same CSS frameworks as web development. I'm curious how that works from the same code base, or perhaps that's one of the major difficulties.
Also I see Expo as a fancy build framework but it's still fundamentally a RN application. Is this correct?
(My front-end colleagues are on another continent and we don't get any water-cooler time. Sorry for the possibly awful questions.)
I'm curious whether the developers were pitched this by management as some lofty social goal like democratizing digital relationships or perhaps disrupting OnlyFans DMs?
We'll find out why when the new CTO is publicly announced. I suspect they simply found someone else. Doesn't help that the CEO is quick to make promises verbally, but I'm sure this is common.
What's your preferred CI/CD system to pair with Gitea? I tried Drone once and found the configuration to be nasty, specifically OAuth2 under Docker Compose. Also the Drone UI left a lot to be desired. This was a while ago so grain of salt etc.
I don't get Raspberry Pi. The $35 computer that's often out of stock, doesn't include a USB adapter or case, and is rarely found below $70. And the unfortunately complex boot process involving binary blobs. It's not as cheap & open as originally implied.
Recovering Gentoo user here. I have lost so many hours to the time sink that is incomplete system package updates on Gentoo. Moved to Nix and never looked back.
On Nix either the install - and occasional build - succeeds and I enter the new environment, or it fails and I don't. In the worst case scenario where the build succeeds but something is funky I can just roll it back.
Now I have all this free time to lose to the time sink that is learning how to package applications in the Nix language.
E.g. A depends on B. In a large update, B updates, something unrelated fails to install and the update fails, and now A doesn't run because it wasn't upgraded and the still installed old version of A depends on the no longer available previous version of B.
In NixOS, you either enter the new environment with all packages updated, or you don't. In the situation where you discover run-time - not install-time - errors, you can simply roll back to the previous set of packages. If the new packages cause a system crash, you can enter previous states from the bootloader.
Now none of this magically solves the software defects themselves. But it gives you a consistent system state that can be transactionally upgraded, or reentered at any time. And then you can raise the appropriate bug tickets.
Your system configuration is in a single file and the need to reconfigure different services in a particular order is gone.
Also your dependencies are all nicely pinned with Flakes. This makes importing arbitrary dependencies - open-source or proprietary - a breeze. This has removed any previous appetite we had for a monorepo, which was primarily to ease access to our other libraries.
It's all very nice, once you are over the not insubstantial learning curve that is.