zek
Joined 14 years ago
Karma
218
Submissions
38
Member since
Dec 13
Recent submissions
Comment · 4 months ago
it’s great to see this stuff moving forward, I’m just impatient for it to all land! Plus one of the challenges IMO is that you also still need support in the runtimes, which takes time. Hopefully the state of the world will look better for WASI in a few months/years.
Comment · 4 months ago
I've been working on a server-side wasm impl of cpython called boomslang [1] and have been thinking a lot lately about packaging, one of the downsides of my current impl is the need to statically link all c/rust extensions. Its too bad IMO how much of the wasm ecosystem targets/depends on emscripten directly. It'd be interesting to see if a more generic ABI could be provided for non emscripten/js based wasm runtimes.
Comment · 4 months ago
if it’s of interest I’ve been working on https://github.com/HubSpot/boomslang
Which has a full build of python to WASM with a bunch of static libs built in already.
I will say I built this pre fable and actually the first build of the interpreter to WASM opus pretty much nailed, cpython has secondary support for WASM as a target since like 3.9 or something and it just pulled from that.
I’ve been meaning to write up a blog post about this sometime, building this has been pretty interesting, including using opus to run a full auto research like loop for days to hyper optimize it’s performance.
I’m hoping to use fable to power some even crazier WASM adventures tho.
Comment · 1 year ago
This was just our first post FWIW, and we definitely want to follow up with more concrete demos/details/etc here. I am working on another post specifically about how we leverage our internal RPC system to make adding AI tools super easy so expect more from us.
Comment · 6 years ago
I work at HubSpot (on Kafka) and so I was a "user" of this migration because kafka uses Zookeeper for coordination. Its pretty amazing how convenient Kube services made this whole transition and we actually learned a lot from this that we will likely end up applying similar strategies for migrating other services onto Kube. Allowing kube services to point to either external resources or pods/internal ones is a probably the best feature I have found in Kube so far (and there are a lot of great features)
Comment · 6 years ago
kinda a late response (sorry) but I run it standalone, setup via ansible. I have ansible scripts that bootstrap everything "below" nomad so it sets up zerotier, then vault, then consul, then dnsmasq (pointing to consul) and then nomad. You could probably run gluster in nomad but given that I give most nomad tasks a gluster directory that feels odd.
The only thing I still need to figure out about this setup is that I currently use a single glusterfs volume for most of my nomad tasks, I would love to have a nomad integration that could provision and mount the gluster volume when I specify a volume for a docker task in nomad.
Comment · 6 years ago
I have this exact setup (vault/consul/nomad + glusterfs and zerotier for networking) and its pretty awesome. Still dependent on letsencrypt for SSL certificates. It runs plex amazingly well (though I am using some machines which are probably overkill for this purpose), even with the data coming from a glusterfs drive. Most of my nomad tasks can just launch anywhere because of gluster.
For internal DNS at least, you can just use consul. I set up dnsmasq to forward to consul on all of my machines which is super convenient (esp when that DNS just points to a docker container ipv6 address on the zerotier network, not port remapping on networking insanity needed)
Comment · 7 years ago
I think the generally accepted solution to this is to set the allowed origin dynamically (IIRC nginx can do this) by looking at the request host header on the options request. If the origin is in some allowed list then you return that origin in `Access-Control-Allow-Origin`
Comment · 9 years ago
Yes! there is an interesting paper on this subject: https://arxiv.org/abs/1609.02943