@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
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.