@aa5b22d9 you can use nix-channel to add user repositories 

 @c2f9cd0a Right, I agree also with that. I called it a gimmick because honestly, when you forward Gitea and you rollback NixOS, Gitea is down because programs are not forward-compatible with their potentially new database schema.
Therefore, there is a whole class of issues that rollbacks will just add to your problems. 

 @c2f9cd0a And I completely agree with you on this, nevertheless, I am interested into seeing how to push the boundaries and better use of the existing capabilities and steer future developments to not make rollback a nice "gimmick", but a theoretically understood concept which may end up being completely useless due to too many blockers (impossible to track data dependencies between a service and his database, etc.) 

 @c2f9cd0a I would not say you are wrong, I'd rather say this is important that we figure out what is truth on that matter and put words on the class of situations out there.
Already being able to say : this set of particular services fulfilling those conditions can be reasonably handled is already a very interesting statement because it helps understanding how to design such systems. 

 @c2f9cd0a Fast recovery is subjective I'd say, surely, if the recovery cost you 1 week but you are getting all the data back, some organizations may accept it and setup an alternative on the side.
In general, there's plenty of ways to make recovery fast by preparing for recovery (filesystem snapshots, large networking pipes, etc.) 

 @c2f9cd0a Note that I am not arguing against roll forward. Also, I am not sure why you are convinced we do not have the right primitives to execute such operations to a large set of services (maybe not all of them, but most of them?), finally, analysis of the NixOS expressions can be performed *automatically*, this is why I am framing this as a research problem. I am not saying "maybe", I am saying there are ways to frame the problem as a theoretical computer science statement. 

 @2708d30e not really, the best thing you can do is to get efibootguard (https://github.com/siemens/efibootguard) a first stage bootloader or use an EFI filesystem driver that knows how to do RAID 

 @c2f9cd0a Agreed, the interesting question to me is that if you live a NixOS universe and can analyze your whole infrastructure with NixOS expressions, can you derive the right magic recipes to synchronize, snapshot and perform recovery? Though, for many people, being able to rollback single systems separately is already pretty good. Distributed systems is probably a research question, albeit a solvable one IMHO. 

 @c2f9cd0a I feel like rollback (in NixOS I suppose) would be less deceptive if they took into account *data rollbacks* and not only *code rollbacks*, which is possible, albeit very hard. 

 @96f216d0 (and our awesome contributors working hard and contributing awesome tests!) 

 @96f216d0 hah, awesome to hear it 🙂 
this is all thanks to our awesome CI! 

 @96f216d0 The next nixos-unstable-small will work, we merged yesterday a PR to fix that 

 @96f216d0 I fixed this but you will have to fix your repos if you are vulnerable to TAM issues… 

 @033b744f 

> So where's the FUD in terms of reasoning?

> It *doesn't look like* MS is going to setup major parts of their infrastructure to introduce trustworthy hosts again.

I think you answered yourself very well.

In IT security, lucky guess are not primitives to build threat models. Hypotheses, assumptions, economics, politics, technical measures and careful analyses are.

What you are doing is just lucky guessing that MSFT didn't do any form of "reasonable" due diligence. 

 @033b744f 

You are jumping from MSFT got compromised at time T to MSFT is still compromised and all GH repos are compromised with full capabilities for attackers. This is one of my accusation.

> As far as I know, you can't protect yourself from a bad actor that has more or less full access to the GH infrastructure and backends.

Assuming this without proof is, to be honest, conspiracy.
I don't like Microsoft neither, but this is ridiculous. 

 @033b744f While I agree with you, there are issues, I worry that your framing is flirting with baseless conspiracies as you seems to be ignoring that there are many safeguards in place to avoid letting GitHub corrupt the whole project.

Even if we didn't use GitHub, you have to understand that NixOS / Nixpkgs cannot force anyone we are consuming packages of to migrate somewhere else.

Either case, I think this is kinda FUD… 

 @726c215a @ba157608 yes but those are solved by systemd :P 

 @d5d21d6b @422a54fb @5ab1ecd9 so cool 

 @2708d30e don't worry! 

 @2708d30e though I opened the conference :p ! But I have been running around indeed 

 @2708d30e if you see me, hit me up! 

 @2976feaa broot? :p 

 @a6c88084 nix-shell -p cargo -p rustc