| 2 Apr 2024 |
| @lotte:chir.rs changed their profile picture. | 07:36:25 |
| 3 Apr 2024 |
Rick (Mindavi) | Managed to fix a ca-derivations issue with hydra: https://github.com/NixOS/hydra/pull/1374 | 21:08:45 |
| 4 Apr 2024 |
| @stablejoy:matrix.org joined the room. | 06:09:42 |
| fabaff changed their display name from Fabian Affolter to fabaff. | 08:40:33 |
darkwater4213 | How feasible would it be to run Hydra as a distributed system? Say I had a few dozen or maybe even a hundred or more thin clients (ARM or RISC-V or whatever). Is it theoretically possible for Hydra to be distributed among those clients (assuming they're all on the same overarching network, of course) so none of them is doing much work or for long, but the whole thing is entirely bootstrapped (reminiscent of IPFS)?
And because this is distributed across an entire fleet, you can do some crazy Gentoo-level optimization... the prospect is very exciting indeed. | 08:56:09 |
darkwater4213 | Imagine: serverless fleet management. MDM... without a manager. | 08:56:34 |
K900 | What do you even mean by "distributed system"? | 08:56:41 |
K900 | Hydra is not a generic orchestrator like k8s | 08:56:49 |
K900 | It builds stuff | 08:56:51 |
K900 | If you don't need to build stuff, or need more than to build stuff, Hydra will not solve your problem | 08:57:03 |
darkwater4213 | Distributed computation has been around since the 90's (at least). I'm asking how feasible it would be to distribute the computation necessary for Hydra. My theorycrafting brain says that the compilation would be the easy part, the orchestration and delivery would be more difficult. Delivery (that is, finding what unit in the fleet has a given resource and then pushing it out to all the units) seems like it'd be a good job for IPFS, but orchestration seems more difficult. Any ideas? | 08:59:39 |
K900 | You are saying long words that don't mean things | 09:00:06 |
K900 | What "computation necessary"? | 09:00:11 |