sambigeara

9 ms·

1. 1.▲
   by sambigeara 4mo ago

   Author here. Happy to answer any questions, vague or intricate! I love bitmap indexes and can talk about them all day.
2. 2.▲
   From maps to bitmaps (and from bitmaps to bitmaps): A faster decision engine(cerbos.dev)

   9 points by sambigeara 4mo ago|1 comments
3. 3.▲
   by sambigeara 4mo ago

   From a conceptual, workload-deployment perspective, I'd say yes--this is largely what I'm trying to achieve with Pollen. In fact I'd go so far as to say that it would be the recommended way of deploying workloads. Pollen&#x27
4. 4.▲
   by sambigeara 5mo ago

   Thanks. Definitely crossed my mind, but it's in the "distant future" bucket, for now at least.
5. 5.▲
   by sambigeara 5mo ago

   Thanks! It's just Wazero's default config[1] right now, so it implements (and is constrained to) those capabilities--WASI p1 is supported, WASI p2 isn't (Wazero yet to implement). Yes to SIMD, no to GC and tail calls (I think
6. 6.▲
   by sambigeara 5mo ago

   Yes! I host pln.sh (and subdomains) as assets on my prod cluster. I have a couple of nodes hosted in EU/US, but do rely on a Cloudflare and a couple of A records to land traffic on them.
7. 7.▲
   by sambigeara 5mo ago

   Ha, thanks! I'll ping you an email. > And what's the public API/stdlib/bindings inside the WASM workers? Wazero (via Extism) carries the load here. As it stands, the runtime lifts three basic host functions into guest
8. 8.▲
   by sambigeara 5mo ago

   Wow! This is seriously cool. And certainly not bad form, there is a level of convergence here and it's always interesting to see what else is being built out in the ecosystem. I'd agree that Pollen's current cap-enforcement s
9. 9.▲
   by sambigeara 5mo ago

   Absolutely! What's _really_ cool is that if you have disjoint computational steps that don't necessarily scale together linearly, you could split them into separately deployed `pln seeds` and let the cluster organically balance th
10. 10.▲
    by sambigeara 5mo ago

    Hypothetically, yes! If your workloads are bounded and can compile to WASM, break them into logical units which would benefit from individual scalability, and `pln seed` them into the cluster. Ingress can be from any node. Any workload that
11. 11.▲
    by sambigeara 5mo ago

    Thank you. Me too!
12. 12.▲
    by sambigeara 5mo ago

    This is a cool idea!
13. 13.▲
    by sambigeara 5mo ago

    Oo good question. I'd prefer to keep external storage solutions as an exercise for the reader. I've touched on this in other comments, but I am looking to introduce state to the cluster internally, but for more sophisticated stora
14. 14.▲
    by sambigeara 5mo ago

    So, the moment a partition occurs, nodes within their resultant partitions then view the remaining peers as the full view of the world. There is _no_ concept of a split brain scenario. ANY decision around network topography or workload plac
15. 15.▲
    by sambigeara 5mo ago

    Fair comment that I'm hearing in a lot of places. I'll work on trying to land some concrete examples.
16. 16.▲
    by sambigeara 5mo ago

    Thank you! I suspect there'll be a fair few dragons to uncover (memory constrained nodes and partial views, disk storage, startup/shutdown patterns, etc etc), if it's worthy of a write-up then I shall certainly post it here.
17. 17.▲
    by sambigeara 5mo ago

    Well, I have a lot to thank you for. The single binary, heterogeneous story would have fallen flat on it's face if it wasn't for the brill work you lot are doing, so, thanks!
18. 18.▲
    by sambigeara 5mo ago

    Thank you!
19. 19.▲
    by sambigeara 5mo ago

    Honestly, not really. It started as an experiment in local-first, convergent state (I have a historical fascination of this: https://news.ycombinator.com/item?id=27606604 , https://news.ycombinator.com/item?i
20. 20.▲
    by sambigeara 5mo ago

    Failed to mention in my other reply: a "seed" because I envisioned, perhaps too poetically, "seeding" some generic computational unit into the cluster only for it to organically spread to other nodes in the cluster... so
21. 21.▲
    by sambigeara 5mo ago

    Ha, thanks! The routing is all Pollen. You reach the workloads through the gRPC control API (exposed on a socket on the host) via a `pln call seed_name function_name payload` or with a more traditional gRPC client. But once they're in,
22. 22.▲
    by sambigeara 5mo ago

    OK bear with me on this, it'll probably be a idle thought-stream because I don't have a concrete answer right now. My intention is for Pollen to become a "generic blob of computational capability" into which you idly `pl
23. 23.▲
    by sambigeara 5mo ago

    Ha, at a hand-wavey level, yes? Like you say, there's no IPv6 overlay, each node just exposes it's own primary UDP port which talks Pollen's mesh protocol. It uses a single QUIC transport, one QUIC connection per peer, and a
24. 24.▲
    by sambigeara 5mo ago

    Feel free to message here or privately if you wanted to discuss your actual use-case, would be keen to understand how people might try to use it!
25. 25.▲
    by sambigeara 5mo ago

    Thanks! I think the classic answer: "it depends" applies here. It currently only supports stateless workloads (for now, see below), so if you have nice, isolated, functional workloads, the WASM seeds could be a good fit! My origin
26. 26.▲
    by sambigeara 5mo ago

    Ah! Makes sense.
27. 27.▲
    by sambigeara 5mo ago

    Yes, definitely.
28. 28.▲
    by sambigeara 5mo ago

    It’s a really interesting question. The real challenge is gating and reserving “slots” for downstream calls. If seed A on one node calls seed B on another, as it stands, Pollen holds that seed A instance up and waiting (with the memory over
29. 29.▲
    by sambigeara 5mo ago

    Thanks! That’s certainly crossed my mind!
30. 30.▲
    by sambigeara 5mo ago

    Well, that’s a good question. I think the best answer for now is “we’ll see”? I use it in place of Tailscale for some homelab applications. I’ve started to deploy other experiments on a “prod” cluster. The demo I showed shows how Pollen res