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.
Yes, the updates treated like a DB transaction are the main draw of Nix and I agree they're nice. However, Fedora and recently Manjaro started offering the so-called "immutable" versions that do nearly the same: you can install and delete and do whatever you like but you also have to explicitly opt in to commit those changes to your bootable image. If you don't do it they're just discarded after you reboot.
That's quite awesome and saves me from 99% of the problem you described... without having to learn the Nix's weird language or be willing to read cryptic error messages and get roasted on Reddit for not knowing them by heart.
The release notes for each version has the detailed instructions for how to upgrade from the previous version. They very strongly emphasize backing up the entire system, because the upgrade process is absolutely not guaranteed to leave the computer in a state that works correctly or boots at all, and there is no way to undo it.
That's what's different about NixOS: if the new configuration doesn't work properly, you can just choose the previous configuration in the bootloader menu. It's as straightforward and foolproof as switching to another branch in a Git repository. The whole point of NixOS is that you can have any number of system configurations in the Nix store and switch between them in a way that's atomic in the transactional sense.
If you know how Nix works, you can feel safe turning off the power supply at any point during a full system upgrade. You'll never end up in a state where half of the packages are upgraded. It's either upgraded or not. As far as I know there's no other distribution that works like this other than GuixSD.
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].
Why would that be the rarest chess move? It's a pretty common way to try to start a chess game, so much so that kids have to be taught not to do it because it's flat-out terrible.
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 not using Expo but I do use Capacitor+Quasar to build cross platform apps to great success. I use it for my job and for my side business. Without it I doubt I could run my side business because I just don’t have the time as just 1 person to maintain 3 codebases.
I’ve never used Expo, React Native, or Flutter so can’t speak to those but I’m pretty happy with my setup. Yes I have to put a tiny bit of logic behind checks for if I’m on the web or if I’m in an app but it works surprisingly well overall IMHO.
It has become very practical / doable in the recent year or so. In my experience, if you have lot of frontend web experience, the easiest way to ship a RN app is by using Solito [0]. Also check out Nativewind [1] which allows you to style native apps the same way like you would on web. I was able to ship the first version of our app in about 1.5 weeks with this stack. Also checkout Tamagui [2].
Solito seems to let you share component code, but I assume that it does not share data fetching code? It doesn't do SSR for the native app? And in expo you'd be expected to `fetch` or otherwise get the data yourself (compared to next land where you can just use the next data loading stuff)?
Using Expo and React Native for web is not really practical. But simply having your mobile and web applications both in TypeScript you can share bits and parts of code, most notably the types & data models, application logic code, and assets (from simple image files, through lottie animations, to strings & their translations), but also potentially run some parts of your web application in a webview, ...
I have never attempted to use the web target of Expo, and probably would never try, not the least because so many dependencies assume that the target of a React Native app is either iOS or Android with the web having such different APIs, and the plethora of alternative options for the web.
The ‘and web’ bit I’ve never found to work well. There’s too many things that work differently on the web
As for the CSS part - yes, React Native uses order for priority, web CSS uses specificity. None of the attempts to get the RN way working on web were amazing
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?
Lol Forever Voices seems like it's 3 dudes in a basement who just use a OpenAI API to train and deploy this stuff. There was not an ounce of real development that went into this.
If you had a the subtitles to your favorite YouTubers videos you could spit this out in minutes. Hell you could take your text messages with your real girlfriend and make a shallow clone of her if you wanted.
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.