| 30 Mar 2024 |
 magic_rb | i also got to do something to speed up the DB because clicking on one of my systems takes 20 seconds to load, its 6.5k store paths | 21:26:28 |
| magic_rb | * i also got to do something to speed up the DB because clicking on one of my systems takes 20 seconds to load, its 6.5k build steps | 21:27:24 |
| 31 Mar 2024 |
|  @fack:cyberia.club left the room. | 00:05:01 |
| 2 Apr 2024 |
|  @lotte:chir.rs changed their profile picture. | 06:58:30 |
| @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 |
| K900 | What do you actually want to do? | 09:00:15 |
| darkwater4213 | In reply to @k900:0upti.me
Hydra is not a generic orchestrator like k8s I think you misunderstand. I'm not trying to treat Hydra as an orchestration tool. I'm asking how feasible it would be to orchestrate a large fleet of relatively low-resource clients (think along the lines of a generic tablet) to effectively function as a single Hydra instance or, barring that, multiple Hydra instances orchestrated by some distributed system I haven't come up with yet. | 09:01:40 |
| K900 | What do you mean by "single Hydra instance"? | 09:01:55 |
| K900 | Do you want to use a bunch of shitty machines as builders? | 09:02:11 |
| K900 | That can be done easily | 09:02:18 |
| K900 | But you will need a central Hydra server | 09:02:23 |
| K900 | The actual build workers just need Nix | 09:02:50 |
| K900 | They don't run any Hydra | 09:02:54 |
| darkwater4213 | In reply to @k900:0upti.me
But you will need a central Hydra server No. A bunch of kinda okay machines.
The key here is no central server. Has that been done before? If not, how feasible is it? | 09:02:58 |
| K900 | No | 09:03:02 |
| K900 | No central server will not happen | 09:03:05 |
| K900 | Without effectively rewriting Hydra entirely | 09:03:14 |
| K900 | And realistically it's just not a thing most people will want or need | 09:03:33 |
