| 1 Aug 2021 |
 @kraftnix:matrix.org | wait, you can currently use deploy-rs to install nixos first time onto a remote system? | 21:28:52 |
 David Arnold (blaggacao) | Hm, it has been a while, and my brain is forgiving with the details. Has advantages and disadvantages. But since I'm rowing in the same boat, I guess I'll find out within the next few days. | 21:29:53 |
| David Arnold (blaggacao) | BUt that would be the target workflow, if possible:
- plug in the USB stick (or have it bplugged in by a local operator)
- get bakc to your main machine
| 21:30:30 |
| David Arnold (blaggacao) | * But that would be the target workflow, if possible:
- plug in the USB stick (or have it plugged in by a local operator)
- get back to your main machine
| 21:30:42 |
 @timdeh:matrix.org | I dunno if deploy-rs can install, but the devs did inform me that it can target even non-nixos systems so maybe it can/ | 21:30:46 |
| @timdeh:matrix.org | * I dunno if deploy-rs can install, but the devs did inform me that it can target even non-nixos systems so maybe it can? | 21:30:51 |
| David Arnold (blaggacao) | I guess it really comes down to this /mnt thing, if any. | 21:31:28 |
| David Arnold (blaggacao) | because while the iso is running, that's the target path. Maybe deploy-rs has an easy enough way to modify the target paths | 21:31:51 |
| @kraftnix:matrix.org | In reply to @blaggacao:matrix.org
But that would be the target workflow, if possible:
- plug in the USB stick (or have it plugged in by a local operator)
- get back to your main machine
I do this already, but I have to do the cp -r /iso/devos ~/devos workaround currently after ssh-ing into the machine to install on | 21:32:19 |
| David Arnold (blaggacao) | Ah, yeah the idea is to employ deploy-rs / yeet at step 2. | 21:32:53 |
| @kraftnix:matrix.org | that would be sweet | 21:33:05 |
| David Arnold (blaggacao) | * Ah, yeah the idea is to employ deploy-rs / yeet at step 2. after some formatting via ssh of course. | 21:33:15 |
| David Arnold (blaggacao) | In reply to @kraftnix:matrix.org
that would be sweet I'm learning rust for it đ | 21:34:19 |
| David Arnold (blaggacao) | In reply to @kraftnix:matrix.org
that would be sweet * I'm learning rust for it đ đ | 21:34:38 |
| David Arnold (blaggacao) | CAVE canem! not quite: but a devos/develop -> devos/main is incoming. core standing on the siding going forward | 21:36:15 |
| David Arnold (blaggacao) | Docs are already updated: https://devos.divnix.com/bud/index.html đ | 21:41:51 |
| David Arnold (blaggacao) | kraftnix: https://github.com/divnix/bud/commit/612228a68d404d559405225427a5d8b3cef9d27c | 22:08:21 |
| David Arnold (blaggacao) | * kraftnix: https://github.com/divnix/bud/commit/612228a68d404d559405225427a5d8b3cef9d27c (impacience won) đ | 22:08:32 |
| David Arnold (blaggacao) | And here is the yeet branch: https://github.com/divnix/bud/tree/yeet | 22:10:52 |
| @kraftnix:matrix.org | In reply to @blaggacao:matrix.org
I'm not sure if sharing profiles would be really a good idea, in theory. Modules are the "generics" and profiles the concrete implementation. I find it to be a good balance between convenience and responsibility to pass "ownership" of any concrete implementation to the user. btw, regarding this discussion above, I would vote for being able to share profiles. while i agree that profiles tend to be a concrete implementation of something, it is still very useful for sharing. I often build profiles in a layered / more abstract fashion where nearly everything except host specific configuration is set in profiles.
i think profile sharing definitely aligns with devos' goals to allow quick bootstrapping and sharing of configurations. e.g. I could take nrdxp steam-compositor profile and mkForce whatever I want after that if I don't like it (or alternatively rewrite it all if theres too much), I could even have my own profiles which rely on "upstream" profiles.
it also aligns with goals such as, "use this profile, it's a perfect neovim/zsh/nix/python environment that builds in a language server with nice mappings etc.", a proper fully featured portable shell, i don't know who you would easily share that without the ability to export profiles
| 22:15:49 |
| @kraftnix:matrix.org | In reply to @blaggacao:matrix.org
I'm not sure if sharing profiles would be really a good idea, in theory. Modules are the "generics" and profiles the concrete implementation. I find it to be a good balance between convenience and responsibility to pass "ownership" of any concrete implementation to the user. * btw, regarding this discussion above, I would vote for being able to share profiles. while i agree that profiles tend to be a concrete implementation of something, it is still very useful for sharing. I often build profiles in a layered / more abstract fashion where nearly everything except host specific configuration is set in profiles.
i think profile sharing definitely aligns with devos' goals to allow quick bootstrapping and sharing of configurations. e.g. I could take nrdxp steam-compositor profile and mkForce whatever I want after that if I don't like it (or alternatively rewrite it all if theres too much), I could even have my own profiles which rely on "upstream" profiles.
it also aligns with goals such as, "use this profile, it's a perfect neovim/zsh/nix/python environment that builds in a language server with nice mappings etc.", a proper fully featured portable shell, i don't know how you would easily share that without the ability to export profiles
| 22:16:48 |
| @timdeh:matrix.org | I only advocate for this because it was my original goal for DevOS, though the community branch unfortunately never took off âšī¸ | 22:17:18 |
| @kraftnix:matrix.org | i think the community branch is too centralised of a solution, we should be leveraging flakes :) | 22:17:44 |
| David Arnold (blaggacao) | I think walking the config tree and replace values by mkDefault would be actually a good thing, i possible, before exporting profiles. | 22:17:59 |
| David Arnold (blaggacao) | Can wee peek if that's possible? | 22:18:25 |
| @timdeh:matrix.org | In reply to @kraftnix:matrix.org
i think the community branch is too centralised of a solution, we should be leveraging flakes :) exactly my thinking | 22:22:16 |
| @timdeh:matrix.org | I mean couldn't we just mapAttrs over a profile? | 22:30:45 |
| @timdeh:matrix.org | nvm, I guess that wouldn't work in the case of a lambda | 22:38:37 |
| 2 Aug 2021 |
| David Arnold (blaggacao) | We could also just export them and see how it goes and what the problems are đ | 13:23:29 |
|  @yuu:matrix.org joined the room. | 14:11:03 |
