| 27 Feb 2020 |
| *  emily waves at vup | 01:37:25 |
 Yana | today i learned:
- https://www.gnu.org/software/mes/
- https://lists.gnu.org/archive/html/info-gnu/2018-08/msg00006.html
| 21:25:26 |
| Yana | it's amazing how much effort guix puts into bootstrapping (ahem) | 21:26:38 |
| emily | yeah, it's cool! | 21:28:51 |
| emily | see e.g. https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ | 21:29:01 |
| emily | the mutually bootstrapping Scheme <-> C thing is really nice | 21:30:58 |
| emily | I'd like to incorporate a lot of that work (though of course even thinking about that stuff is a long way off) | 21:32:00 |
| 29 Feb 2020 |
| Yana | https://github.com/tweag/funflow
Funflow's caching is based around the content store. This stores all artifacts according to the hash of the inputs and computations which produced them. Funflow uses this to know when exactly a computation must be rerun and when previous results can be re-used.
| 15:31:35 |
 arc | mew o: | 15:38:43 |
| Yana | (you all have probably already seen that... metadata is stored in sqlite, blobs are plain fs files, they model deps as lists: https://git.io/JvgVo) | 15:43:40 |
| Yana | * (you all have probably already seen that >_> metadata is stored in sqlite, blobs are plain fs files, they model deps as lists: https://git.io/JvgVo) | 15:44:03 |
| Yana | * (you all have probably already seen that >_> metadata is stored in sqlite, blobs are plain fs files, they model deps as lists) | 15:45:47 |
| Yana | * (you all have probably already seen that >_> metadata is stored in sqlite, blobs are plain fs files, deps are modeled as lists) | 15:46:50 |
| emily | I don't think I actually had seen this | 15:59:48 |
| emily | (though I have seen similar stuff) | 15:59:55 |
| emily | reminds me of https://github.com/salsa-rs/salsa | 16:00:31 |
| emily | though more elaborate (in a good way!) | 16:00:36 |
| emily | one of these days I'm going to have to get over my aversion for arrow notation I guess | 16:02:34 |
| 1 Mar 2020 |
|  energizer` joined the room. | 21:17:38 |
| energizer` | hello. i saw mew docs emphasize object capabilities. i am curious if something like https://github.com/NixOS/nix/issues/8#issuecomment-145911503 is in scope for mew | 21:25:20 |
| emily | I've definitely thought about whether it would be practical to make the store not world-readable, yeah | 21:25:57 |
| emily | I'm not sure it's ultimately the correct approach to take for secrets but it's something I'm interested in exploring | 21:26:10 |
| emily | the plan is to not use the filesystem as backing storage so there'll need to be some amount of filesystem namespacing / FUSE / ... going on to begin with | 21:26:42 |
| emily | (there are some uses outside of general secrets -- e.g. if part of your code is trade secret and you want to restrict access while still allowing general builds, google actually has this -- though admittedly I don't know of any examples I'd consider particularly compelling) | 21:27:58 |
| energizer` | meaning someone else is allowed to build my code but doesn't get access to its source? | 21:34:30 |
| energizer` | or just that someone else is not allowed to see my stuff even though we share the same bash | 21:38:25 |
| energizer` | (and libc, etc) | 21:38:41 |
| emily | yeah, along the lines of the former, secret libraries that get linked to. but it's kind of marginal and of course you can't defend against decompilation, hence why I said I don't feel like it's a particularly compelling usecase | 21:40:19 |
| energizer` | mhmm | 21:41:32 |
| emily | (also, hi! I'm curious how you found the repo since I haven't really advertised it around anywhere ^^ ) | 21:44:28 |
