!zghijEASpYQWYFzriI:nixos.org

Hydra

343 Members
99 Servers

Load older messages


SenderMessageTime
4 Apr 2024
@k900:0upti.meK900I don't care about the philosophical implications of naming things here09:04:56
@k900:0upti.meK900We already have a thing called Hydra and that thing can't do what you want, and probably won't ever be able to09:05:10
@k900:0upti.meK900If you make a new thing, you're free to call it whatever you want, including Hydra09:05:20
@k900:0upti.meK900(though it would be confusing for everyone involved)09:05:26
@darkwater4213:matrix.orgdarkwater4213

It's still a fascinating prospect.

I've been toying with the idea of NixOS-as-MDM for some time now. It just occurred to me as I was brushing my teeth that most MDM solutions require a central server (if not all) and that can get expensive and inconvenient. Decentralizing the entire thing makes it more portable, flexible, and frankly, way cooler.

I was thinking of a guy who installed some distributed-computation software on all his school's computers, so he could build an entire Gentoo system, DE and all, in ninety seconds flat (not counting transfer times). Then it occurred to me that if all those machines were the same architecture, there's no reason those compiled objects could not be reused with the exact same optimizations. And since there's already no "central server" (because all of them are servers), you could unify this entire mess into a NixOS config, and you've got yourself a hype train straight out of 2014.

I need sleep.

09:10:17
@k900:0upti.meK900MDM has absolutely nothing to do with Hydra09:10:48
@k900:0upti.meK900And honestly you're just describing distcc09:11:06
@k900:0upti.meK900(though it's still not entirely Decentralized(tm), not that it needs to be)09:11:26
@delroth:delroth.net@delroth:delroth.netany time someone suggests using IPFS I just assume they have no clue about anything related to distributed computing, so far the heuristic has always worked09:12:41
@k900:0upti.meK900Also, MDM and Decentralized(tm) don't go together09:12:45
@k900:0upti.meK900For reasons that should hopefully be obvious09:12:59
@rick:matrix.ciphernetics.nl@rick:matrix.ciphernetics.nl
In reply to @k900:0upti.me
Without effectively rewriting Hydra entirely
And nix too, since eval is quite memory hungry. Distribution of that will add a lot of transfer overhead and complication to evaluation, I feel.
12:11:32
@janne.hess:helsinki-systems.de@janne.hess:helsinki-systems.deRedacted or Malformed Event13:18:03
@mrtrk:matrix.orgMarco TurchettoHas anyone ever tried to deploy all the hydra components separately? from what I understood hydra architecture is meant to be distributed and use postgresql as a message bus13:48:12
@janne.hess:helsinki-systems.de@janne.hess:helsinki-systems.de
In reply to @mrtrk:matrix.org
Has anyone ever tried to deploy all the hydra components separately? from what I understood hydra architecture is meant to be distributed and use postgresql as a message bus
That's mostly true but I think (although I am not sure) that the queue runner expects the drvs from the evaluator in its store
13:51:47
@ma27:nicht-so.sexyma27
In reply to @janne.hess:helsinki-systems.de
That's mostly true but I think (although I am not sure) that the queue runner expects the drvs from the evaluator in its store
That should be solvable by instructing the evaluator to write into a remote store I guess.
13:53:45
9 Apr 2024
@5m5z3q888q5prxkg:chat.lightnovel-dungeon.de@5m5z3q888q5prxkg:chat.lightnovel-dungeon.de changed their profile picture.23:12:30
11 Apr 2024
@anthonyrsl:matrix.orgAnthony Rsl set a profile picture.21:59:20
@anthonyrsl:matrix.orgAnthony Rsl removed their profile picture.22:12:55
12 Apr 2024
@hexa:lossy.networkhexa joined the room.16:46:26
14 Apr 2024
@bootstrapper:matrix.org@bootstrapper:matrix.org changed their profile picture.04:54:39
17 Apr 2024
@k900:0upti.meK900 changed their display name from K900 ⚡️ to K9Ö0.17:16:44
@k900:0upti.meK900 changed their display name from K9Ö0 to K900.17:21:55
@k900:0upti.meK900 17:21:55
18 Apr 2024
@stablejoy:matrix.org@stablejoy:matrix.org I'm trying to determine the duration of a build for a single package. However, when parsing the JSON with start and stop times, curl -H 'Accept: application/json' <https://hydra.nixos.org/build/255062383> | jq '.starttime, .stoptime', it shows the same start and stop time while the build duration at https://hydra.nixos.org/build/255062383#tabs-summary shows it took 45 seconds. 06:59:38
19 Apr 2024
@casey:hubns.net@casey:hubns.netthe key part there is that the build was cached from another build. you'll need to grab the build info from that original build.15:54:32
@belak:matrix.org@belak:matrix.org left the room.19:53:58
21 Apr 2024
@stablejoy:matrix.org@stablejoy:matrix.org
In reply to @casey:hubns.net
the key part there is that the build was cached from another build. you'll need to grab the build info from that original build.
Ooh I see, thanks
07:51:39
@mlyx:matrix.org@mlyx:matrix.org left the room.15:47:35
@cole-h:matrix.org@cole-h:matrix.org left the room.23:46:03

Show newer messages


Back to Room ListRoom Version: 6