<isd>
I would hazard a guess you can't grab low ports with that, but it might be a decent way to set up a box automatically, if the user is okay with having to put a port number after the domain...
<ocdtrekkie>
Arguably, home users need to anyways.
<ocdtrekkie>
Comcast (and several other home ISPs) prohibit use of well-known ports to serve content.
<isd>
Yeah, so grabbing 80/443 is not necessarily the right default anyway; don't want to get our users in trouble without them knowing what they're getting into.
<isd>
xet7: I think the situation has not really changed re: building Sandstorm for arm. There's an issue open about it if you want to read the latest.
<isd>
The seccomp filter requires architecture-specific work, so I don't think we'll ever support whatever you can find a compiler for, the way many applications can.
<isd>
...and I'm hesitant to add new architectures just because. I think there's a strong case for ARM specifically, and if the landscape changes I'd be open to other archs if there's a compelling case. Maybe RISC-V will become big and there will be something really worth it, but we'll wait until there's a reason.
<isd>
I wouldn't mind getting rid of fibers. If we could kill both that and ndoe-capnp, that would simplify the build, since the meteor app would be entirely separate from the C++ code
<isd>
(actually, I'm not sure we need to kill fibers for that, since meteor pulls it in. But there are some hacks in bundle.sh to support it...)
<isd>
But, also, as discussed, having a story for portable apps is probably the hard part.