@kip93 there was no good place for after event QA or I missed it.
How many spare machines you have in space?
I misread this as NixCon in space, which would have been an interesting choice for next yearâs conference.
But this is rather cool too! Didnât think just hand-rolling switch
and some of the upload mechanisms would be sufficient to actually get a working low-bandwidth update
@kip93 How closely does the resulting system match what you would get from a configuration.nix
? Are you allowed to say how often you actually run this workflow?
I misread this as NixCon in space,
If thatâs what it takes to have a NixCon without visas and border controlâŚ
There wasnât much opportunity for QA unfortunately. Specially since the only nice moment that I had 5-6 people came with questions right up until the next talk.
Donât know what you mean by âspare machinesâ here, itâs not like launching a satellite is cheap enough that we can have spare ones.
We have 2 satellites in space rn, only one of which has nix. Next year weâll be launching many more. We also have testing hardware on ground for validating that nothing gets broken, to avoid any issues on the real satellite; we donât want to end up with a very expensive space brick after all.
Not sure if that answered your question?
I misread this as NixCon in space
Thatâs probably the only way to top this yearâs NixCon.
How closely does the resulting system match what you would get from a
configuration.nix
?
Weâre building the configuration.nix file, so itâs exactly(-ish*) the same as built locally. You just need to access system.build.toplevel
and build that. Itâs something that NixOS just provides for you to toy with.
*Only change is that weâre cross compiling, so the hashes are different; but we could build natively and get the exact same thing.
Are you allowed to say how often you actually run this workflow?
Only a couple times a year, since we are quite focusing on testing (and the many many satellites we want to launch in the next few years).
I saw once the first missions of Apollo had 5 computers, 4 to make sure each other are correct and one in case of total failure of others (not sure about those numbers)
At that time, computers are huge (more mass) and expensive, but âmissionsâ are so expensive that redundancy payoff.
Then they run out of money and reduced the number of computers.
For today computer price/mass, you could send one entire AWS Region as redundancy.
I must have misunderstood the talk a bit then, as I was under the impression you only upload a subset of the top-level, but I guess thatâs just the subset of all the changes, which is what nixos-rebuildâs ssh things do too. Guess youâre not planning on doing full OS upgrades then, considering how much data that would be?
Iâm still in awe with how incredibly cool this is, I always imagined this kind of thing would be the best use case for NixOS I think you may be my elevator pitch in the future when someone asks me why I think NixOS is cool, and why reproducibility even matters.
Oh, we donât have any sort of redundancy of that sort. We try to keep prices down so we can launch more satellites, since that provides us with better ground coverage.
I must have misunderstood the talk a bit then, as I was under the impression you only upload a subset of the top-level, but I guess thatâs just the subset of all the changes, which is what nixos-rebuildâs ssh things do too.
Right, we do our own delta of the changes and upload only that. Currently, it looks similar to the SSH copy but all is computed on ground. In the future, we could optimize things even further by doing bit by bit differences between the old and new paths and only upload the difference and get crazy small update packages. But, since we only update a few times a year if the upload size is not perfectly optimized, it still is good enough and weâve put efforts elsewhere for now.
Guess youâre not planning on doing full OS upgrades then, considering how much data that would be?
We are definitely not going to upgrade the NixOS version, for each satellite weâre planning of having a pinned version of nixpkgs so that we avoid unexpected changes, and we can backport things as needed.